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
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?
>
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
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 i
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
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 i
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 lib
rethinking this again, i came to the conclusion:
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
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 mu
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 f
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, tha
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 ha
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
13 matches
Mail list logo