On Sun, 28 Aug 2011, Peter Brinkmann wrote:
One major simplification is the use of built-in data types vs custom structs and unions.
You mean you simplify by making things more low-level ?
const char * is rarely ever called high-level...
With this transition to built-in data types, you can simply run SWIG on the header file and automatically create bindings for a significant part of libpd for lots of target languages; only the callbacks will require some additional work. Without this conversion, you would have to descend into the netherworld of custom typemaps and such.
When you are using typemaps, do you have the impression that you're using SWIG in a high-level way ? Isn't the lack of typemaps a sign that your API isn't very abstract ?
Incidentally, I've also gotten flak for not baking any multi-instance support into the initial version of libpd (I did consider it, but it seemed pointless because with the current version of Pd it would still have just one single instance).
The point would be to make all the backward-compat and forward-compat you need for supporting a future version of pd that will include features that you're already thinking about.
But you don't have to add an argument everywhere. I bet that you'll add a libpd_set_current_pd_instance(t_pd_interpreter *) function that will set a global variable used by the rest of the pd api. That would be consistent with the stateful message-passing in many small steps using a hidden global array. Later you can make all of that thread-safe by making all of those functions call pthread_self() to figure out which thread they're in, and replace the globals by threadwise-locals.
I figure that as long as I'm drawing fire from both low-level C hackers and high-level OOP types, I must be doing something right;)
It's bad to insist on a low-level vs high-level dichotomy. It's been quite a while that those words cause confusion because they give the impression that those levels are all stacked in top of each other along one axis of highness. The truth is a lot more complicated, in which levels aren't well-defined, more abstract isn't necessarily better, more concrete isn't necessarily better either, it depends a lot on what you want to achieve, and what you expect for the future, etc. ; I still use expressions like low-level or high-level sometimes, but it isn't as seriously as when people first invented the term.
So, it's possible that you're doing something right, but drawing fire from people that you categorise in two bins is probably not a good sign of what you think it is.
It's more of a general consideration, and I don't have any road map in mind. Right now I'm just hoping to have a conversation about this.
Well, does that involve multiple interpreters, with one interpreter per core, but still in the same process, with a way to pass messages quickly from one interpreter to the other ?
Would they be sharing the same gensym, or would they need to re-gensym everything when talking from one interpreter to the other ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC