Re: [PD-dev] missing file from pd-MAIN and fftw version
On Tue, 26 Sep 2006, Hans-Christoph Steiner wrote: I should add, the next key step is to remove as many classes as possible from the root namespace (i.e. compiled into Pd). I should add, that it should be possible to achieve proper namespacing without moving anything out of the root namespace. BTW, here's an idea that I consider interesting regarding namespaces. Currently, the objectmaker of pd holds all classnames of pd and maps them to creators using its methodtable. Now what if the objectmaker was just an objectmaker among others? Think: namespace = objectmaker. For example, each patch gets its own objectmaker, and each objectmaker has a class_addanything which causes a fallback of any unknown classname to a parent namespace. Eventually, asking for creation of a [+] box crawls up a chain that leads back to the root namespace, if none of the objectmakers in the chain defines a + method. That way, we avoid coding extra namespace-handling features and avoid creating a bunch of symbols with slashes in them and we reuse the features already in pd. This idea should raise a few questions and a few eyebrows but I believe that it's an idea worth considering and which could pay off. For many, it would be trivial to do, just compile them as individual objects in a libdir. I've already done this for x_list.c, x_net.c, and a couple others. Things like x_arithmatic.c will be trickier, but this does not have to happen at once. It can happen incrementally. I can't think of why x_arithmetic.c would be trickier, maybe you can explain. What I believe will be really trickier are things that are even more elementary to the pd language: [pd] [inlet] [outlet] [objectmaker] [canvasmaker] [struct] [loadbang]. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
On Tue, 26 Sep 2006, Tim Blechmann wrote: On Tue, 2006-09-26 at 23:21 +0200, Frank Barknecht wrote: IMO this step should wait until we have the equivalent to Python's from pdcore import * or C++'s using namespace std sorry for some 'implementation details', but this is not as trivial as it would be in a script language. 1. It's not that trivial in a script language 2. It's exactly as difficult in a script languages as in pd. (pd isn't as special as we may believe it is) the first solution would be a contrary to pd's design principle (as written by miller in the pd docs, §2.6.2. persistence of data). in practice, a pd canvas may have all of those persistent states which are not part of the canvas' contents per se: (x,y) origin of the canvas window (x,y) size of the canvas window (x,y) size of the gop (x,y) margin for gop (x1,y1,x2,y2) range for graphing font size gop flag gop rectangle flag and in practice, IEMGUI has been integrated to pd itself 5 years ago, everybody takes them for granted, and they're full of violations of 2.6.2; it could even be argued that the nature and the goal of IEMGUI is to violate 2.6.2. for the second solution the creation time of the import object would be crucial (which would also be a contrary to §2.6.2), the creation time would be also important in the case of the first solution. (i don't see why it wouldn't.) or objects will have to be reloaded when import objects are created/destroyed, which would increase the complexity of the implementation quite a bit... this can be made in a semi-automatic way, e.g. an item in the Edit menu which would recreate all objects as if the patch had been reloaded from a file. This is roughly equivalent to Ctrl+A Ctrl+X Ctrl+V, but now the second solution is different in the sense that Ctrl+V would have to figure out namespaces in order to create its objects properly (!!). _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how does a loader get loaded?
Am 25.09.2006 um 00:32 schrieb Hans-Christoph Steiner: Weee a tongue twister! So I am working on making a loader for libdirs. I get sys_register_loader(), which submits a pointer to classloader() (or whatever). But what makes Pd load that loader first? For example, something needs to load clr.dll, so that is calls sys_register_loader() to register its classloader() function. yes, it's the good old -lib clr command line option! greetings, Thomas ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
On Wed, 2006-09-27 at 03:05 -0400, Mathieu Bouchard wrote: On Tue, 26 Sep 2006, Tim Blechmann wrote: On Tue, 2006-09-26 at 23:21 +0200, Frank Barknecht wrote: IMO this step should wait until we have the equivalent to Python's from pdcore import * or C++'s using namespace std sorry for some 'implementation details', but this is not as trivial as it would be in a script language. 1. It's not that trivial in a script language 2. It's exactly as difficult in a script languages as in pd. (pd isn't as special as we may believe it is) well, it is in one term ... scripting languages are written in a text file, that's parsed from the top to the bottom. _this_ is absolutely the same as with pd ... the difference is, pd patches are not written in a text editor (at least, this is the usual case, i know, it's possible) and the parsing order is not transparent to the user ... unlike other interpreted languages, changes to the patch are done immediately, i.e. after changing something in the patch, there is no need to reload the patch file (compared with python's 'reload' or recompiling with a langugage like c/c++). what makes you think, that this is similar in text-based languages? tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Which is more musical, a truck passing by a factory or a truck passing by a music school? John Cage signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
Tim Blechmann wrote: what makes you think, that this is similar in text-based languages? i think script language here did not mean text-based language (ignoring the etymology of script), but rather interpreted language. mfg.adsr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Re: [PD] Pd 0.40-0 test 08
Hallo, Ed Kelly hat gesagt: // Ed Kelly wrote: Just to let you know that the rmstopow~ and powtorms~ objects do not get created on 0.40test8 on OSX. I've never heard of these objects. Where did you get them from in the past? Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
It's probably all the same if there's one objectmaker that changes its behavior or if there are several (just an inplementation question). Perhaps the new declare object (designed to be visible :) could get new flags to manipulate the way object names are mapped to creators. Just an idea... cheers Miller On Wed, Sep 27, 2006 at 01:52:52AM -0400, Mathieu Bouchard wrote: On Tue, 26 Sep 2006, Miller Puckette wrote: Yes indeed. I'm thinking of automatically having new classes shadow old ones, so that anything in Pd could simpy be externed over. Not sure of all the long-term ramifications, but I like the idea. How about having several objectmakers with different methods defined in them? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - t?l:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montr?al QC Canada ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
On Wed, 27 Sep 2006, Miller Puckette wrote: It's probably all the same if there's one objectmaker that changes its behavior or if there are several (just an inplementation question). I'm talking about the implementation because implementations suggest certain interfaces just like interfaces suggest certain implementations. I don't consider that interface design is something that strictly precedes implementation design; rather, both are interacting in a feedback loop, if the people involved are willing to make both the interface and implementation evolve. (that's like, the top principle of extreme programming, though not said like that) If the implementation involves a network of objectmakers, this is an opportunity to later add more namespace features that are logical consequences of how that style of implementation. Perhaps the new declare object (designed to be visible :) How do you make Ctrl+V, [declare], namespaces and principle 2.6.2 work together? could get new flags to manipulate the way object names are mapped to creators. Just an idea... what do you mean? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
On Wed, 27 Sep 2006, Mathieu Bouchard wrote: If the implementation involves a network of objectmakers, this is an opportunity to later add more namespace features that are logical consequences of how that style of implementation. typo, remove the how. what i mean by logical consequences is features that you get for free in the sense that the amount of code that you have to write to get them is nearly zero, and sometimes exactly zero. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
On Wed, 27 Sep 2006, Tim Blechmann wrote: the difference is, pd patches are not written in a text editor (at least, this is the usual case, i know, it's possible) and the parsing order is not transparent to the user ... Right, that's it. There are interactive interpreters/compilers, for most languages (except mainly C, C++, ObjC, Java, C#, VB). However those usually don't result in things that get dumped to files (with the notable exceptions of Smalltalk and SELF). unlike other interpreted languages, changes to the patch are done immediately, Smalltalk and SELF make changes effective immediately on a per-method basis. However, those languages don't really have a top-to-bottom parsing order unless you really insist to load the code from text files (which is not usual for Smalltalk and SELF). i.e. after changing something in the patch, there is no need to reload the patch file (compared with python's 'reload' or recompiling with a langugage like c/c++). What pd needs here is the decoupling of creators from the classname-table, in such a way that it is possible to know what is the t_class associated to a given name, so that pd can know whether an object needs to be recreated or not, depending on whether the t_class associated with a name has changed or not. what makes you think, that this is similar in text-based languages? What you just said clarifies the distinction that you wanted to make. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Re: [PD] Pd 0.40-0 test 08
On Wed, 27 Sep 2006, Ed Kelly wrote: Just to let you know that the rmstopow~ and powtorms~ objects do not get created on 0.40test8 on OSX. aren't those just [pow~ 2] and [pow~ 0.5] ? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] corelibs, build system
On Sep 27, 2006, at 4:27 AM, IOhannes m zmoelnig wrote: Hans-Christoph Steiner wrote: a lot of time setting up. I really don't want to have to use ACLs in CVS, but you are leaving me no other choice. why don't you want to use ACLs if you want ACLs? Because I thought I could trust the Pd developers to ask before the mess with anything that's not theirs. So far, you are really the only violator. corelibs is a section that I set up and only I have worked on so far. You did not ask at all. d_mayer_fft.c is the name of the file in 0.39.2. You have broken compilation for Pd-extended. because corelibs IS broken, even without my changes (which tried to fix what was going on) Check the build logs from the auto-build farm for the past 2 months. I had been building fine on every platform. This is really, really inappropriate. Now its time to do the right thing and reverse your changes. .hc ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
On Sep 26, 2006, at 5:46 PM, Tim Blechmann wrote: On Tue, 2006-09-26 at 23:21 +0200, Frank Barknecht wrote: I should add, the next key step is to remove as many classes as possible from the root namespace (i.e. compiled into Pd). IMO this step should wait until we have the equivalent to Python's from pdcore import * or C++'s using namespace std sorry for some 'implementation details', but this is not as trivial as it would be in a script language. i can think of two ways to implement a namespace: - a property of the canvas - a |using| or |import| object the first solution would be a contrary to pd's design principle (as written by miller in the pd docs, §2.6.2. persistence of data). for the second solution the creation time of the import object would be crucial (which would also be a contrary to §2.6.2), or objects will have to be reloaded when import objects are created/destroyed, which would increase the complexity of the implementation quite a bit... Yes, that is a good principle, but its already violated in a number of places, like properties panels on GUI objects. Properties on a canvas probably makes sense for a namespace. Loading from a file shouldn't be too hard, the file could be loaded into memory, reordered as necessary, then executed. The hard part would be when inserting an [import] statement into a patch, if that is going to take effect immediately and reload objects based on that [import]. For the next step, it could just change the loading statement, only affecting the load. Then we can test the idea out, and see whether its worth the effort of making it take effect immediately. I guess realtime languages don't usually have namespaces. Anyone know of some examples? .hc ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file in CVS: d_fft_mayer.c and problems building pd.app under osx (mac intel)
On Sep 27, 2006, at 5:55 PM, Kilian Koepsell wrote: hi, what is the recommended way to build pd.app under osx for mac intel? i was happy to see that the binary on miller puckette's web site (http://crca.ucsd.edu/~msp/software.html) for the experimental version 0.40-0.test.08 runs just fine. however, i didn't manage to compile it using the source code from the sam site. i also tried to follow the instructions on the osx howto (http:// puredata.info/dev/darwin) using each of the three versions rsync -av --delete rsync://128.238.56.50/distros/pd-devel/ pd- devel/ rsync -av --delete rsync://128.238.56.50/distros/pd-extended/ pd- extended/ rsync -av --delete rsync://128.238.56.50/distros/pd-main/ pd-main/ i did make patch_pd inside the package directory and then, inside the package/darwin_app directory, i did make darwin_app_wrapper make with little success: pd-main fails compiling s_loader.c That builds for me ok on a G5. Perhaps try to update the source? pd-extended fails because it is missing the file pd/src/ d_fft_mayer.c needed by externals/corelibs/lib_d_fft.c IOhannes reverted those changes, so that should work again (thank you IOhannes). Try a new rsync. pd-devel failed for some of the patches I haven't gotten that building myself... i also tried to get the source directly from cvs but didn't succeed in compiling it. here again the problem was the missing file d_fft_mayer.c. FYI: Those rsyncs are updated every night at midnight/ 0.00 Eastern Time, so they are quite current. .hc any help is highly appreciated, k. ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
On Sep 27, 2006, at 3:53 AM, Frank Barknecht wrote: Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: On Wed, 27 Sep 2006, Frank Barknecht wrote: But, yes: This would be worse, if you wouldn't even know, which [+ ] object is used, depending on which namespace is active. The decoupling of the name and the thing that the name refers to, is called late binding. I was referring only to the printed form of a patch: If the printout doesn't include any information about active namespaces, it will become very hard to read a patch. The namespaces could be stored as a property of the canvas, while [import] objects or [;pd-patch.pd import( messages would be the way to manipulate those stored properties. .hc However I don't want to be forced to write patches like: [pdcore/float] If namespaces force you to write complete names all of the time, then there is no difference between that and just considering slashes as part of the name and not thinking about namespaces. Exactly. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [once] default closed...
On Sep 16, 2006, at 6:38 AM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Arg... another example of the limitations of email, its so hard to communicate anything where nuance is essential. This discussion would take 10 minutes in person and no one would be annoyed. Ah, yes, that's so very true... ;) - I do not care about strict adherence to backwards compatibility - I do care about finding broad standards that make sense in the overall - I did not know that [once] already exists elsewhere outside of purepd A name - of an object or a funicton - always carries some meaning of its own, which should be related to its behaviour. That is my main point against having [once] closed as default: A closed [once] to me more seems like a [never]. Viewing it from this point was what made me come up with [countdown]. Maybe [countdown] isn't the best name, either. Alternatives could be [manyshot], [someshot], [passmany], [passcount] etc. What do you think? I can say a [never] object makes no sense, while a [once] object that is default closed would be like When I tell you to, then let something past just once. In Pd: | [bang( | | [once 0] | The question of consistency is a tough one here. Linguistic consistency is what you are outlining. From what I know most programming languages are more likely to adhere consistency of function arguments. But its tough to say what would work better in Pd. Words can be very vague, especially when you consider that many programmers will be programming in a language that is not their native tongue. So it seems quite difficult to be strictly adherent to the words. Of course, it should be close as possible. But words are how humans communicate with each other, so the meaning of the language should be given attention. So the other kind of consistency in question here is consistency of usage. All similar functions should have the same arguments, for example. Which type of consistency trumps the other? That's the question at hand. I personally feel that its not more linguistically consistent to have [once] default open when it has no argument. But this is inconsistent in usage with similar objects ([spigot]...). .hc ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
