Re: [PD] Abstractions search path hirarchy (was: pduino-arduino trouble)
On Wed, 18 Jun 2008, Hans-Christoph Steiner wrote: On Jun 18, 2008, at 7:54 PM, Mathieu Bouchard wrote: On Wed, 18 Jun 2008, Hans-Christoph Steiner wrote: and then class-lookup is method-lookup in pd, because it's done through [objectmaker]'s method-list. Do you have a reference in the Pd code to look at this specific stuff? grep -n objectmaker *.c That I can do on my own, I was hoping for some human guidance... :) Well, I didn't think that I'd have to say to have a look at class_addmethod, because we're talking about adding a method to a class. Anyway, the thing doesn't use linked-lists, contrary to almost all other such things in pd, so I was wrong. However, it is true that it appends to the end of the list all of the time. It happens just after the t_resizebytes call. Personally, I wouldn't touch it, and instead I would change the method-lookup order in getfn(), zgetfn() and pd_typedmess(). Then I realise that it is already last-to-first, which is my second mistake. I don't know why I had the impression that it was first-to-last. On top of that, it's an aspect of pd for which dd is identical. So, I should've remembered. You can see that I'm getting a bit rusty ;) Ultimately, for the canvas-local namespaces to be complete, there needs to be a canvas-local method list too. I explained it in detail last year. Got no reply. Link? Ok, I found it, but in the end, it wasn't a full description, and it wasn't last year either. Turns out that I optimised-out the description from the mailing-list, as the description was going to be a reply to a reply that I did not receive. http://lists.puredata.info/pipermail/pd-dev/2006-09/007605.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007607.html http://lists.puredata.info/pipermail/pd-dev/2006-09/007608.html But basically, the idea is that you have a tree of dummy singleton objects that are the objectmakers. They are singleton because each of them has its own class. They are dummy because the object itself is never used and itself contains no data (this exists because pd has no way to define non-object methods, and that's fine with me). Each objectmaker class defines the creators as methods: one per class, one per alias, and one per sub-namespace. Creators for classes and aliases are as usual. Creators for sub-namespaces are forwarders. They replace the selector from the message they get, with the $1 of the arglist. $1 is removed from the arglist. So: [foo bar baz 1 2 3] Might be a real creator for [baz 1 2 3] inside namespace representative [bar] inside namespace representative [foo]. Or it could be something else with less namespace levels and more arguments. If the ambiguïty of it icks you, there are other possibilities of design. Then if you don't want to use Miller namespaces such as in [list ...] classes, then you will have to check for namespace qualifiers in the classname and split the classname accordingly, sort of like [OSCroute] but not really. I used Miller namespaces because it makes less symbols in the symbol-table. I have other ideas as well, such as how to import a namespace without copying the method-table, and how to support a namespace that is being modified so that all its importing namespaces get the update. It's the same solution(s) for both problems. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstractions search path hirarchy (was: pduino-arduino trouble)
On Sun, 15 Jun 2008, Frank Barknecht wrote: Btw.: Miller is working on making shadowing even builtins possible. It can be done by removing some lines from pd's source. Defining a method is done by appending to a linked-list. If it is made to prepend to the linked-list (by removing a for-loop), a new method with the same name as an old method with shadow the old method because of the way method-lookup happens, and then class-lookup is method-lookup in pd, because it's done through [objectmaker]'s method-list. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstractions search path hirarchy (was: pduino-arduino trouble)
On Jun 18, 2008, at 4:52 PM, Mathieu Bouchard wrote: On Sun, 15 Jun 2008, Frank Barknecht wrote: Btw.: Miller is working on making shadowing even builtins possible. It can be done by removing some lines from pd's source. Defining a method is done by appending to a linked-list. If it is made to prepend to the linked-list (by removing a for-loop), a new method with the same name as an old method with shadow the old method because of the way method-lookup happens, and then class-lookup is method-lookup in pd, because it's done through [objectmaker]'s method-list. Do you have a reference in the Pd code to look at this specific stuff? I'd like to see how it works. Ultimately, for the canvas- local namespaces to be complete, there needs to be a canvas-local method list too. .hc kill your television ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstractions search path hirarchy (was: pduino-arduino trouble)
On Wed, 18 Jun 2008, Hans-Christoph Steiner wrote: and then class-lookup is method-lookup in pd, because it's done through [objectmaker]'s method-list. Do you have a reference in the Pd code to look at this specific stuff? grep -n objectmaker *.c Ultimately, for the canvas-local namespaces to be complete, there needs to be a canvas-local method list too. I explained it in detail last year. Got no reply. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstractions search path hirarchy (was: pduino-arduino trouble)
i don't konw if that's related. i was using the release candidate: Pd version 0.40.3-extended-20080603. my question: wouldn't it make sense if Pd would search first in the same directory as the patch is for abstractions? m. Am 2008-06-14 um 23:05 schrieb Hans-Christoph Steiner: Yeah, that was my mistake, I removed hardware/arduino.pd from the nightly builds since it shouldn't be there. Sorry about that... .hc On Jun 14, 2008, at 11:59 AM, Max Neupert wrote: hi list, i found the source of my problem here. the patch was using the [arduino] abstraction. i had it located in the same path than my patch (version 0.3), but another one (version 0.4) is located in /Applications/Pd-extended.app/Contents/Resources/extra/hardware/ i've always assumed that pd searches for abstractions first in the same directory than the patch is found. that doesn't seem to be the case. for some reason pd sometimes choose to prefer the 0.4 version which has a different, non working bitrate set. i've deleted the abstraction and use it now in a subpatch instead, so i am sure no other version is loaded instead. max Am 2008-06-13 um 18:54 schrieb Claude Heiland-Allen: Max Neupert wrote: this is the output when it does work: set_baudrate baudbits: 57600 this is the output when it doesn't: set_baudrate baudbits: 115200 anyone has a clue what's going on? I'm guessing the baudbits has something to do with it. Maybe something along the connection between pd and arduino doesn't support the higher speed. Never used arduino or any other serial devices though. Claude -- http://claudiusmaximus.goto10.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list -- -- The arc of history bends towards justice. - Dr. Martin Luther King, Jr. PGP.sig Description: Signierter Teil der Nachricht ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstractions search path hirarchy (was: pduino-arduino trouble)
It should do that already. I don't remember why it didn't in this case. .hc On Jun 15, 2008, at 9:55 AM, Max Neupert wrote: i don't konw if that's related. i was using the release candidate: Pd version 0.40.3-extended-20080603. my question: wouldn't it make sense if Pd would search first in the same directory as the patch is for abstractions? m. Am 2008-06-14 um 23:05 schrieb Hans-Christoph Steiner: Yeah, that was my mistake, I removed hardware/arduino.pd from the nightly builds since it shouldn't be there. Sorry about that... .hc On Jun 14, 2008, at 11:59 AM, Max Neupert wrote: hi list, i found the source of my problem here. the patch was using the [arduino] abstraction. i had it located in the same path than my patch (version 0.3), but another one (version 0.4) is located in /Applications/Pd-extended.app/Contents/Resources/extra/hardware/ i've always assumed that pd searches for abstractions first in the same directory than the patch is found. that doesn't seem to be the case. for some reason pd sometimes choose to prefer the 0.4 version which has a different, non working bitrate set. i've deleted the abstraction and use it now in a subpatch instead, so i am sure no other version is loaded instead. max Am 2008-06-13 um 18:54 schrieb Claude Heiland-Allen: Max Neupert wrote: this is the output when it does work: set_baudrate baudbits: 57600 this is the output when it doesn't: set_baudrate baudbits: 115200 anyone has a clue what's going on? I'm guessing the baudbits has something to do with it. Maybe something along the connection between pd and arduino doesn't support the higher speed. Never used arduino or any other serial devices though. Claude -- http://claudiusmaximus.goto10.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list - --- The arc of history bends towards justice. - Dr. Martin Luther King, Jr. Access to computers should be unlimited and total. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstractions search path hirarchy (was: pduino-arduino trouble)
On Sun, 2008-06-15 at 15:16 +0200, Hans-Christoph Steiner wrote: It should do that already. I don't remember why it didn't in this case. i am HEAVILY against this. please, before you change that in pd-extended, provide a patch to change the behaviour in pd-vanilla. actually i don't care too much which way it is implemented, but i do care A LOT that it is consistent over all distros. your disciple of the curch of consistency roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstractions search path hirarchy (was: pduino-arduino trouble)
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: the actual behaviour shouldn't be changed. afaik, it is not possible to shadow classes of pd or from binary libraries. changing actual behaviour would lead to many incosistencies, where sometimes an local abstraction would shadow library classes and sometimes not. internal classes couldn't be shadowed anyway. it would make the pd-world definitely more troublesome. unless it is possible to shadow EVERYTHING (classes from binary libraries and internals), this shouldn't be changed, IMO. Btw.: Miller is working on making shadowing even builtins possible. Check pd-dev, unless you've already seen it. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstractions search path hirarchy (was: pduino-arduino trouble)
On Sun, 2008-06-15 at 18:53 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: the actual behaviour shouldn't be changed. afaik, it is not possible to shadow classes of pd or from binary libraries. changing actual behaviour would lead to many incosistencies, where sometimes an local abstraction would shadow library classes and sometimes not. internal classes couldn't be shadowed anyway. it would make the pd-world definitely more troublesome. unless it is possible to shadow EVERYTHING (classes from binary libraries and internals), this shouldn't be changed, IMO. Btw.: Miller is working on making shadowing even builtins possible. Check pd-dev, unless you've already seen it. oh, thanks. i usually read pd-dev, but obviously i missed the point here. hans: it seems you're coming up with this at the right time, so forget my concerns ;-) sorry for the noise. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Abstractions search path hirarchy (was: pduino-arduino trouble)
hi list, i found the source of my problem here. the patch was using the [arduino] abstraction. i had it located in the same path than my patch (version 0.3), but another one (version 0.4) is located in /Applications/Pd-extended.app/Contents/Resources/extra/hardware/ i've always assumed that pd searches for abstractions first in the same directory than the patch is found. that doesn't seem to be the case. for some reason pd sometimes choose to prefer the 0.4 version which has a different, non working bitrate set. i've deleted the abstraction and use it now in a subpatch instead, so i am sure no other version is loaded instead. max Am 2008-06-13 um 18:54 schrieb Claude Heiland-Allen: Max Neupert wrote: this is the output when it does work: set_baudrate baudbits: 57600 this is the output when it doesn't: set_baudrate baudbits: 115200 anyone has a clue what's going on? I'm guessing the baudbits has something to do with it. Maybe something along the connection between pd and arduino doesn't support the higher speed. Never used arduino or any other serial devices though. Claude -- http://claudiusmaximus.goto10.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Abstractions search path hirarchy (was: pduino-arduino trouble)
Yeah, that was my mistake, I removed hardware/arduino.pd from the nightly builds since it shouldn't be there. Sorry about that... .hc On Jun 14, 2008, at 11:59 AM, Max Neupert wrote: hi list, i found the source of my problem here. the patch was using the [arduino] abstraction. i had it located in the same path than my patch (version 0.3), but another one (version 0.4) is located in /Applications/Pd-extended.app/Contents/Resources/extra/hardware/ i've always assumed that pd searches for abstractions first in the same directory than the patch is found. that doesn't seem to be the case. for some reason pd sometimes choose to prefer the 0.4 version which has a different, non working bitrate set. i've deleted the abstraction and use it now in a subpatch instead, so i am sure no other version is loaded instead. max Am 2008-06-13 um 18:54 schrieb Claude Heiland-Allen: Max Neupert wrote: this is the output when it does work: set_baudrate baudbits: 57600 this is the output when it doesn't: set_baudrate baudbits: 115200 anyone has a clue what's going on? I'm guessing the baudbits has something to do with it. Maybe something along the connection between pd and arduino doesn't support the higher speed. Never used arduino or any other serial devices though. Claude -- http://claudiusmaximus.goto10.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
