subject:"Re\: \[PD\-dev\] pow\~ in Cyclone \[was\: Re\: stripping down Pd\-extended's default libs\]"


Roman Haefeli wrote:

On Wed, 2009-02-18 at 15:21 +0100, IOhannes m zmoelnig wrote:

Martin Peach wrote:
Well isn't it just easier to use something with a different name? If you 
have a backwards [pow] why not just call it [backwardspow] instead of 
letting users guess which [pow] is the right one?

who would object to that?

but which [pow~] _is_ the right one, and which one is backward?


this is so much a rhethoric question, which is practically so easy to
answer and was already answered. i absolutely don't see the point of
this question


hmm, martin suggested (supposedly joking) to call one of the [pow] 
objects [backwardspow] (which i guess would have reversed inlets).
now i guess that cyclones [pow~] is reveresed, should we just 
arbitrarily change it's name?




i think, that the question, why a new object [pack] is named pack is not
rhetoric at all and isn't answered yet. so lets go again: why is [pack]
from zexy called [pack]?



because it is meant as a fully backwards-compatible replacement of 
[pack], with added features.
since i have been repeating this for several times now, i would be 
interested in the precise part of the above sentence that is unclear to you.


fmgasdr.
IOhannes


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]


Roman Haefeli wrote:


the switch from 0.41 to 0.42 did indeed also break at least one of the
netpd patches. this patch is using [unpack] for an incoming message,
that misses the list selector. while this still works with pd's [unpack]
(although it is an undocumented feature, i guess), it doesn't work with
the zexy [unpack]: it complains: no method for 'bla'.

this again raises the question: should zexy's [unpack] mimick the the
funny behaviours of pd's [unpack]? i am undecided here.


yesterday when i went home i was wondering about (i guess) the same 
thing: could sending [foo bar( to [unpack s s] be actually considered a 
bug in the patch (for sending a non-list to [unpack]) and unpack 
itself (for accepting non-lists)?


the help-patch clearly speaks of lists of atoms, but doesn't mention 
other messages at all.


mfgas.dr
IOhannes


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]


Roman Haefeli wrote:

sorry for causing confusion. when i speak about differences in
pd-extended and pd vanilla i usually refer to the way of how libraries
in pd-extended are built and not to any difference in the core of
pd-extended and pd vanilla (which might doesn't exist anyway). so when i
mentioned an 'incompatibility between pd-extended and pd vanilla', i
actually meant to say 'an incompatibility caused by different ways of
how libraries are built'. i'll try to make that more clear in the
future.


but haven't i just illustrated that the way libraries are built in 
Pd-extended are no foolproof way to not override internals?

so there is no incompatibility caused by different ways of
how libraries are built'.
(it is a bit harder to trigger the problem on pdx though)

fmar
IOhannes


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]


Roman Haefeli wrote:


i think, that the question, why a new object [pack] is named pack is not
rhetoric at all and isn't answered yet. so lets go again: why is [pack]
from zexy called [pack]?


apart from the specifics of [pack]:
if a language allows the overriding of built-in methods, then i do not 
see why a social codex (which is what you are asking for, right?) should 
forbid it.
especially, if a language introduces ways to override built-in methods 
after years of existance,  it actually encourages the overriding of 
built-in methods.


i guess miller has spent countless of sleepless hours thinking and 
rethinking how to do this best, so we probably should adapt to it.


fgmasdr
IOhannes


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-19 Thread Damian Stewart

Hans-Christoph Steiner wrote:

 Well, the point of cyclone is to be compatible with Max/MSP and all  
 its warts.  So if you are trying to run a Max patch in Pd, then  
 cyclone's pow~ is correct.

speaking of... how does Max handle the namespaces/overriding/etc problem?

-- 
damian stewart | skype: damiansnz | dam...@frey.co.nz
frey | live art with machines | http://www.frey.co.nz

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-19 Thread Matt Barber

 i think, that the question, why a new object [pack] is named pack is not
 rhetoric at all and isn't answered yet. so lets go again: why is [pack]
 from zexy called [pack]?


 because it is meant as a fully backwards-compatible replacement of [pack],
 with added features.
 since i have been repeating this for several times now, i would be
 interested in the precise part of the above sentence that is unclear to you.



Perhaps there is a conceptual difference between overriding internal
classes for a class with the same behavior but with added methods
(e.g. the [print] and [soundfiler] examples from before), and
overriding with a different object, or one with a different interface
(the [pow~] situation).

For instance I think it would be at least a well-motivated task to
write over [tabread4~] with one that inherited everything vanilla
[tabread4~] could do, did those by default, but added methods for
Hermite interpolation instead of Lagrange.  Meanwhile, it would not be
well-motivated to override it with an object which (to be silly)
indexed tables in reverse, or (to be ridiculous because it's 4:00 AM
here) grabbed a random joke from the web every 64 samples and posted
it to the console.

What's unclear -- and to me probably the most important to solve as a
result of this thread -- is what to do when vanilla adds features
which potentially clash with objects in existing libraries.  After
all, this would be a much shorter thread if the problem were in a new
[rfft~] object from some library that output bins in the order they
appear in SuperCollider, thus breaking vanilla [rfft~] patches every
time that library was loaded -- in the name of gbuzz stop what you're
doing and fix the library!

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-19 Thread Frank Barknecht

Hallo,
Martin Peach hat gesagt: // Martin Peach wrote:

 Well isn't it just easier to use something with a different name? If you 
 have a backwards [pow] why not just call it [backwardspow] instead of 
 letting users guess which [pow] is the right one?

If a former external becomes a builtin in some future Pd version, you
cannot use something with a different name, you can only rename the
old external to something else. And what if the new builtin name was
used by different, conflicting classes? What if Pd gets a [counter]
builtin as is sometimes requested?

Ciao
-- 
 Frank BarknechtDo You RjDj.me?  _ __footils.org__

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-19 Thread Martin Peach

Frank Barknecht wrote:
 Hallo,
 Martin Peach hat gesagt: // Martin Peach wrote:
 
 Well isn't it just easier to use something with a different name? If you 
 have a backwards [pow] why not just call it [backwardspow] instead of 
 letting users guess which [pow] is the right one?
 
 If a former external becomes a builtin in some future Pd version, you
 cannot use something with a different name, you can only rename the
 old external to something else. And what if the new builtin name was
 used by different, conflicting classes? What if Pd gets a [counter]
 builtin as is sometimes requested?
 

I suggest that the first object to use the name 'owns' the name and any 
subsequently invented objects use different names. That's all. If 
there's already a [counter] then Pd's new builtin counter would have to 
be called [pdcounter] or something. The name doesn't affect the 
function, and usually is not much use beyond being a unique identifier.
You still need to look at the help patch to know what any version of 
[counter] actually does.

Martin


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-19 Thread Mathieu Bouchard


On Thu, 19 Feb 2009, IOhannes m zmoelnig wrote:

yesterday when i went home i was wondering about (i guess) the same 
thing: could sending [foo bar( to [unpack s s] be actually considered a 
bug in the patch (for sending a non-list to [unpack]) and unpack 
itself (for accepting non-lists)?


with a circuit-bending attitude and without a spec, features and bugs 
often can't be told apart.


the help-patch clearly speaks of lists of atoms, but doesn't mention other 
messages at all.


So why does the pd source spend 12 lines defining pack_anything ?

 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-19 Thread Mathieu Bouchard


On Thu, 19 Feb 2009, Matt Barber wrote:

Perhaps there is a conceptual difference between overriding internal 
classes for a class with the same behavior but with added methods (e.g. 
the [print] and [soundfiler] examples from before), and overriding with 
a different object, or one with a different interface (the [pow~] 
situation).


Right. It has to do with the Liskov substitution principle, if you 
consider the new interface as a subtype of the old interface: whatever 
holds for the old interface, should hold for the new interface.


This principle defines what's a subtype, but doesn't say what it should be 
applied on. I mean, you can make statements about interfaces, and those 
statements talk about subtypes, but they don't necessarily talk about 
features, or they talk about one man's features which is another man's 
hole or bug. I mean, before worrying about subtypes, we have to figure out 
what's a feature and what's not.


I say that because there's something called pack_anything that is defined 
in pd, which looks pretty deliberate, and yet, it still seems to someone 
like a bug. So, what's a feature?


(Liskov's also has other exceptions such as covariant types, but that's 
another thing)


Meanwhile, it would not be well-motivated to override it with an object 
which (to be silly) indexed tables in reverse, or (to be ridiculous 
because it's 4:00 AM here) grabbed a random joke from the web every 64 
samples and posted it to the console.


Actually, if the spec of the class does not say that nothing will be 
posted to the console, and that there is no rule that says that nothing 
gets posted to the console unless specified explicitly in the spec, then 
it is the right of every subclass to do whatever it wants with the 
console, really... in theory... though it would be quickly reported as an 
annoyance or a bug. I suppose that... if it's really at 64 samples, then 
it would just flood the pd console so bad that it would freeze the 
programme.



in the name of gbuzz stop what you're doing and fix the library!


for a little while I hoped gbuzz would be the name of a Gtk port of 
Jeskola's BuzzTracker.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-19 Thread Roman Haefeli

On Thu, 2009-02-19 at 09:46 +0100, IOhannes m zmoelnig wrote:
 Roman Haefeli wrote:
  i think, that the question, why a new object [pack] is named pack is not
  rhetoric at all and isn't answered yet. so lets go again: why is [pack]
  from zexy called [pack]?
  
 
 because it is meant as a fully backwards-compatible replacement of 
 [pack], with added features.
 since i have been repeating this for several times now, i would be 
 interested in the precise part of the above sentence that is unclear to you.

i think, i understand that sentence, but still cannot see the goal of
calling it the same. i mean, giving it the same name is of no use for
your old (pre-zexy-[unpack]) patches, since they were not aware of the
new features of zexy's [unpack], when they were created, thus they also
would work with the pd's [unpack] today. on the other hand, for new
patches, that potentionally profit from the added features of [unpack],
it wouldn't have been any additional effort to write each time [zunpack]
(or whatsoever) instead of [unpack]. so the only goal of it, that i can
see is, that you deliberately want to confuse yourself, which i believe
wasn't your reason to call it [unpack]. back to the orignal question

roman
 



___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-19 Thread Roman Haefeli

On Wed, 2009-02-18 at 12:59 -0500, Hans-Christoph Steiner wrote:

 Here's how I think this all should work:
 
 - classes of any implementation language are treated the same  
 (i.e. .pd_linux, .pd, .pdlua, etc).
   - single library format for all implementation methods
   - possibility for shared code for objectclasses in library
   - check for objectclasses in paths in same order for any  
 implementation method
   - one objectclass per file
   - help patch in same folder as objectclass file
 
 - search . first, then canvas-local paths, then global paths
 
 - search using registered loaders (i.e. implementation langauges) one  
 dir at a time:
   - first search . for .pd .pd_linux .pdlua etc.
   - then search first dir in canvas-local path for .pd .pd_linux .pdlua  
 etc.
   - then search second dir in canvas-local path  
 for .pd .pd_linux .pdlua etc.
   - ...
   - then search first dir in global path for .pd .pd_linux .pdlua etc.
   - then search second dir in global path for .pd .pd_linux .pdlua etc.
   - ...
 
 - the loaded class names should follow the above rules of loading  
 classes
 
 - namespace prefixes stay as part of classname and do not load basename
   - i.e. [cyclone/pow~] does not claim the name [pow~]
 

i rather don't want this to drip away into the deep ocean of pd list
discussions.

this sounds very reasonable to me and (please correct me) it would
address most problems, that are currently in discussion.  i kind of feel
to be the wrong person to say that, since i haven't contributed
code-wise to all those ideas, but i think it would be good to stick that
on a wikipage (dev section on puredata.info?), if people agree on those
'guidelines'. 

i hope to see more comments on this

roman  




___ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: 
http://mail.yahoo.de


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-19 Thread Hans-Christoph Steiner


On Feb 19, 2009, at 3:53 AM, Damian Stewart wrote:

 Hans-Christoph Steiner wrote:

 Well, the point of cyclone is to be compatible with Max/MSP and  
 all  its warts.  So if you are trying to run a Max patch in Pd,  
 then  cyclone's pow~ is correct.

 speaking of... how does Max handle the namespaces/overriding/etc  
 problem?


One global namespace, the internals are all built-in statically.  I  
doubt you can override built-in names, but I don't know specifically.   
I'd be curious to hear about the search path for Max.

AFAIK, Max/MSP users basically operate under the assumption that if  
there is a name conflict, you need to chuck on of them.

.hc






'You people have such restrictive dress for women,’ she said, hobbling  
away in three inch heels and panty hose to finish out another pink- 
collar temp pool day.  - “Hijab Scene #2, by Mohja Kahf



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-19 Thread Frank Barknecht

Hallo,
Martin Peach hat gesagt: // Martin Peach wrote:

 I suggest that the first object to use the name 'owns' the name and any 
 subsequently invented objects use different names. 

I think, that's good for external and abstraction libraries (in the
repository), but Pd builtins should be free to use any name they want
(within reason) and not be forced to scan every available collection of
externals or abstractions if a name is taken. That's just not
practical, especially not for abstractions (of which I have thousands on my
disk, most of them local to a project of course)

Ciao
-- 
Frank


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]


Roman Haefeli wrote:


correct me, if this is wrong, but i understand, that overriding internal
classes doesn't work with single-file externals. so the feature of
overriding internal classes doesn't and won't work with pd-extended.


not necessarily;
i haven't checked, but imagine:
1.:
[import cyclone]
[pow~] will remain the vanilla version

2.:
using [cyclone/pow~] will force the use of the single-object external, 
and while doing so it will call the class_new() method for pow~ which 
will override the internal [pow~].

[pow~] will become the cyclone version.

this is both with (an imagined) Pd-extended 0.42



please someone correct me, if this is wrong or based on wrong
assumptions.


mfga.sdr
IOhannes


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]


Frank Barknecht wrote:

Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:


do i understand correctly: external classes could override internal
classes also in older ( 0.42) versions of pd, but i just didn't notice
it? so the new feature is 'only' that pd automatically creates aliases
for the overriden internals?


Yes. ;)



they could, but it was an effort to do so.
any ordinary external would not be able to do it.
the only library that i am aware of that did override internal classes 
is cyclone, and krzysztof did some awful work fuddling with the 
classtable of pd_objectmaker.

i think the code is in the  fragile (sic!) part of cyclone.

so in general the answer is no.

fgmasdr
IOhannes


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-18 Thread Frank Barknecht

Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:

 2.:
 using [cyclone/pow~] will force the use of the single-object external,  
 and while doing so it will call the class_new() method for pow~ which  
 will override the internal [pow~].
 [pow~] will become the cyclone version.

This is correct. I made a test whose results you can see in the
attached screenshot and patch. It's weird. :)

Ciao
-- 
 Frank BarknechtDo You RjDj.me?  _ __footils.org__


pow-weirdness.pd
Description: application/puredata
attachment: pow-weirdness.png___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-18 Thread Frank Barknecht

Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:

 they could, but it was an effort to do so.
 any ordinary external would not be able to do it.

So am I understanding it correctly, that Zexy's [pack] is not doing
the fuddling Cyclone does and now suddenly became an object that
overwrites internals by changes in Pd 0.42?

Ciao
-- 
 Frank BarknechtDo You RjDj.me?  _ __footils.org__

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]


Frank Barknecht wrote:

Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:


they could, but it was an effort to do so.
any ordinary external would not be able to do it.


So am I understanding it correctly, that Zexy's [pack] is not doing
the fuddling Cyclone does and now suddenly became an object that
overwrites internals by changes in Pd 0.42?



exactement!

because i didn't do any fudlling (well knowing that zexy's [pack] is not 
ready to replace Pd's [pack]; but stating the intention to become so 
LATER by using class_new(pack) - thinking that this was a safe thing 
to do), i was shocked that suddenly my pack would be used instead of the 
vanilla one.



fmgasdr
IOhannes


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-18 Thread Martin Peach

IOhannes m zmoelnig wrote:
 Frank Barknecht wrote:
 Hallo,
 IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:

 they could, but it was an effort to do so.
 any ordinary external would not be able to do it.

 So am I understanding it correctly, that Zexy's [pack] is not doing
 the fuddling Cyclone does and now suddenly became an object that
 overwrites internals by changes in Pd 0.42?
 
 
 exactement!
 
 because i didn't do any fudlling (well knowing that zexy's [pack] is not 
 ready to replace Pd's [pack]; but stating the intention to become so 
 LATER by using class_new(pack) - thinking that this was a safe thing 
 to do), i was shocked that suddenly my pack would be used instead of the 
 vanilla one.
 

I guess it never occurred to any of you to use objects with different 
names...

Or else why not just call every pd object object and then use paths to 
access them, like [pd/some/library/subdirectory/object]?

Just kidding in a frustrated sort of way.

Martin


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]


Martin Peach wrote:
I guess it never occurred to any of you to use objects with different 
names...


Or else why not just call every pd object object and then use paths to 
access them, like [pd/some/library/subdirectory/object]?


Just kidding in a frustrated sort of way.



i don't get you point.

why it might seem questionable to want to override a given function with 
a supposedly better one, i don't see why i should bully anyone who wants 
to do that...



mfgasrd
IOhannes


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-18 Thread Martin Peach

IOhannes m zmoelnig wrote:
 Martin Peach wrote:
 I guess it never occurred to any of you to use objects with different 
 names...

 Or else why not just call every pd object object and then use paths 
 to access them, like [pd/some/library/subdirectory/object]?

 Just kidding in a frustrated sort of way.

 
 i don't get you point.
 
 why it might seem questionable to want to override a given function with 
 a supposedly better one, i don't see why i should bully anyone who wants 
 to do that...
 

Well isn't it just easier to use something with a different name? If you 
have a backwards [pow] why not just call it [backwardspow] instead of 
letting users guess which [pow] is the right one?

Martin


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]


Martin Peach wrote:


Well isn't it just easier to use something with a different name? If you 
have a backwards [pow] why not just call it [backwardspow] instead of 
letting users guess which [pow] is the right one?


who would object to that?

but which [pow~] _is_ the right one, and which one is backward?

fgmar
IOhannes


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-18 Thread Hans-Christoph Steiner


On Feb 18, 2009, at 8:38 AM, Martin Peach wrote:

 IOhannes m zmoelnig wrote:
 Frank Barknecht wrote:
 Hallo,
 IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:

 they could, but it was an effort to do so.
 any ordinary external would not be able to do it.

 So am I understanding it correctly, that Zexy's [pack] is not doing
 the fuddling Cyclone does and now suddenly became an object that
 overwrites internals by changes in Pd 0.42?


 exactement!

 because i didn't do any fudlling (well knowing that zexy's [pack]  
 is not
 ready to replace Pd's [pack]; but stating the intention to become so
 LATER by using class_new(pack) - thinking that this was a safe  
 thing
 to do), i was shocked that suddenly my pack would be used instead  
 of the
 vanilla one.


 I guess it never occurred to any of you to use objects with different
 names...

 Or else why not just call every pd object object and then use  
 paths to
 access them, like [pd/some/library/subdirectory/object]?

 Just kidding in a frustrated sort of way.

Different names are a good idea, for sure.  But Pd should also not go  
down in flames if someone happens to create an object with a name that  
is already used somewhere.  Its not possible to know every single  
object that has ever been made.

I just ran into this myself trying to create an abstraction called  
beat.  Apparently, there is already a [beat], so I got unexpected  
results.

.hc



 Martin


 ___
 Pd-dev mailing list
 Pd-dev@iem.at
 http://lists.puredata.info/listinfo/pd-dev





I spent 33 years and four months in active military service and during  
that period I spent most of my time as a high class muscle man for Big  
Business, for Wall Street and the bankers.  - General Smedley Butler



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-18 Thread Hans-Christoph Steiner


On Feb 18, 2009, at 3:21 AM, IOhannes m zmoelnig wrote:

 Roman Haefeli wrote:
 correct me, if this is wrong, but i understand, that overriding  
 internal
 classes doesn't work with single-file externals. so the feature of
 overriding internal classes doesn't and won't work with pd-extended.

 not necessarily;
 i haven't checked, but imagine:
 1.:
 [import cyclone]
 [pow~] will remain the vanilla version

 2.:
 using [cyclone/pow~] will force the use of the single-object  
 external, and while doing so it will call the class_new() method for  
 pow~ which will override the internal [pow~].
 [pow~] will become the cyclone version.

 this is both with (an imagined) Pd-extended 0.42

Would this be any different with a Pd-vanilla+libs 0.42?  I don't  
think there is anything particular to the Pd version in Pd-extended  
that would cause this, but instead the way the libraries are built.

.hc





 please someone correct me, if this is wrong or based on wrong
 assumptions.

 mfga.sdr
 IOhannes
 ___
 Pd-dev mailing list
 Pd-dev@iem.at
 http://lists.puredata.info/listinfo/pd-dev





Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war on  
terrorism.- retired U.S. Army general, William Odom



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]


Hans-Christoph Steiner wrote:


this is both with (an imagined) Pd-extended 0.42


Would this be any different with a Pd-vanilla+libs 0.42?  I don't  
think there is anything particular to the Pd version in Pd-extended  
that would cause this, but instead the way the libraries are built.




no of course not.
my entire point was to show that it depends on the version of Pd (prior 
or post 0.42) rather than the flavour (vanilla or extended or whatever)


gfmar
IOhannes


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-18 Thread Andy Farnell

On Wed, 18 Feb 2009 12:40:10 -0500
Hans-Christoph Steiner h...@eds.org wrote:

 Well, the point of cyclone is to be compatible with Max/MSP and all  
 its warts.  So if you are trying to run a Max patch in Pd, then  
 cyclone's pow~ is correct.


I see, that makes sense. 

a.

-- 
Use the source

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-18 Thread Andy Farnell



http://uncyclopedia.wikia.com/wiki/A!

On Wed, 18 Feb 2009 13:55:42 -0500 (EST)
Mathieu Bouchard ma...@artengine.ca wrote:

 On Wed, 18 Feb 2009, Martin Peach wrote:
 
  Or else why not just call every pd object object and then use paths to 
  access them, like [pd/some/library/subdirectory/object]? Just kidding in 
  a frustrated sort of way.
 
 the chicken language:
http://plif.courageunfettered.com/archive/wc072.gif
 
 malkovich malkovich malkovich:
http://www.youtube.com/watch?v=OIUWGQMOVJ4
 
 schtroumpf dialects:
http://damienmarcellin.canalblog.com/images/Schtroumpf_vert_1.JPG
 
   _ _ __ ___ _  _ _ ...
 | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec


-- 
Use the source

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-18 Thread cyrille henry



IOhannes m zmoelnig a écrit :
..
 they could, but it was an effort to do so.
 any ordinary external would not be able to do it.
 the only library that i am aware of that did override internal classes 
 is cyclone,
what about zexy [unpack]?
it is still here, and it is still breaking my patch.

cyrille


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-18 Thread cyrille henry



IOhannes m zmoelnig a écrit :
 cyrille henry wrote:

 IOhannes m zmoelnig a écrit :
 ..
 they could, but it was an effort to do so.
 any ordinary external would not be able to do it.
 the only library that i am aware of that did override internal 
 classes is cyclone,
 what about zexy [unpack]?
 it is still here, 
 
 oops, nobody told me yet :-)
 i have hopefully fixed it now...

hum.
just svn update / make clean / make and i still have this when loading zexy : 

warning: class 'abs~' overwritten\; old one renamed 'abs~_aliased'
matchbox: OSC-pattern matching code (c) Matt Wright, CNMAT
warning: class 'unpack' overwritten\; old one renamed 'unpack_aliased'
warning: class 'wrap' overwritten\; old one renamed 'wrap_aliased'

so, it look like unpack is still here.
c


 
 and it is still breaking my patch.
 
 how's that?
 i would be interested in a patch demonstrating this breakage.
 
 fgamr
 IOhannes
 
 
 
 
 ___
 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] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]


cyrille henry wrote:

here is a patch that work with vanilla, but not with zexy unpack.


ah, another bug to fix :-(


oops, nobody told me yet :-)

don't you use it?


no, there are lots of objects in zexy which i seldomly use...

fgmasdr
IOhannes


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]


cyrille henry wrote:


so, it look like unpack is still here.


indeed. i was wrongly assuming that class_addcreator() will not override 
the default classes (unlike class_new())

should be _really_ fixed now.

fg,asdr
IOhannes


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-18 Thread Matt Barber

On Wed, Feb 18, 2009 at 1:55 PM, Mathieu Bouchard ma...@artengine.ca wrote:
 On Wed, 18 Feb 2009, Martin Peach wrote:

 Or else why not just call every pd object object and then use paths to
 access them, like [pd/some/library/subdirectory/object]? Just kidding in a
 frustrated sort of way.

 the chicken language:
  http://plif.courageunfettered.com/archive/wc072.gif

 malkovich malkovich malkovich:
  http://www.youtube.com/watch?v=OIUWGQMOVJ4

 schtroumpf dialects:
  http://damienmarcellin.canalblog.com/images/Schtroumpf_vert_1.JPG


Chicken put to use
http://isotropic.org/papers/chicken.pdf

Simplify!
http://www.horus.at/~charlie/tuni/simplify.pdf

Menu
On our menu tonight, our special is cooked animal with sauce.

Etc.

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-18 Thread Roman Haefeli

On Wed, 2009-02-18 at 15:21 +0100, IOhannes m zmoelnig wrote:
 Martin Peach wrote:
  
  Well isn't it just easier to use something with a different name? If you 
  have a backwards [pow] why not just call it [backwardspow] instead of 
  letting users guess which [pow] is the right one?
 
 who would object to that?
 
 but which [pow~] _is_ the right one, and which one is backward?

this is so much a rhethoric question, which is practically so easy to
answer and was already answered. i absolutely don't see the point of
this question.

i think, that the question, why a new object [pack] is named pack is not
rhetoric at all and isn't answered yet. so lets go again: why is [pack]
from zexy called [pack]?

roman




___ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: 
http://mail.yahoo.de


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-18 Thread Frank Barknecht

Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:

 Hallo,
 IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
 
  2.:
  using [cyclone/pow~] will force the use of the single-object external,  
  and while doing so it will call the class_new() method for pow~ which  
  will override the internal [pow~].
  [pow~] will become the cyclone version.
 
 This is correct. I made a test whose results you can see in the
 attached screenshot and patch. It's weird. :)

Okay, replying to myself: The attached patch IMO illustrates a severe
bug with the aliasing. It is possible to have the same object in a
patch behave differently depending on opaque circumstances like creation
order. That's not only weird, it's nasty.

Generally from time to time Pd will get new builtins that may use names
of objects, that are already in some library. These internals
should not be overwritten by the old externals by default, but
overwriting may be included as an optional feature. So I would suggest
something like a (gloabl or canvas-local) switch that explicitly enables
builtin-overwriting. That way, Cyclone could still import Max patches,
but zexy-pack wouldn't break anything in the default case. Still
IOhannes would be able to use his pack when developing and RjDj could
overwrite [soundfiler] with a [soundfiler] external that also loads ogg-files.

Cyclone's fragile part probably could even be simplified in the code.

Ciao
-- 
Frank

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:

 On Tue, 2009-02-17 at 07:26 +0100, Frank Barknecht wrote:
 how can someone assume so?  no, that is so not true. i didn't even know,
 that zexy comes with their own version of [pack] and [unpack] until some
 weeks ago. and why the hell to they use the same names as internals?
 no, by no means i don't want to be forced to use the zexy version, just
 because some patches i use need zexy. 

You have been forced to do so for many years, you just haven't been told
about it until 0.42. I just now discovered that something is overwriting
my [wrap]. I don't know yet which library does that. It would be nice if
Pd could report the source library file together with the warning.

  It's a difference between Pd = 0.42 and Pd  0.42.  I don't think,
  overriding builtins ever worked with single-file externals, 
 
 that is what i am saying: this is introducing a _new_ incompatibility
 between pd-extended and pd vanilla.

Huh? The only incompatibility is the new *feature* of alias names for
overwritten objects. 0.42's [pow~] or [abs~] also are a new *feature*
implemented by popular demand. Loading libraries and the overwriting
itself hasn't changed at all AFAIK. If you don't use the alias names,
you don't have any problems. 

  but maybe
  I'm wrong. IOhannes? The overriding with lib-libraries works as before,
  additionally you now can use the builtins with an alias. That may not be
  the most pretty solution, but it doesn't break anything.
 
 i neeed to use an alias when i want to use vanilla objects? this is
 simply insane.

I agree with you that external libraries generally shouldn't overwrite
builtins. When using Cyclone for Max-importing it makes sense, though.

But IMO the aliasing is less insane than not being able to use the
builtins at all, as is the case if you load object-overwriting-libraries
like zexy or cyclone in any Pd version before 0.42, including
pd-extended. 

Note that here I use libraries in the -lib-loading
many-externals-in-one-file sense here, not in the sense where everything
(libs, singles, abstractions, libdirs) is called a library and setting
a path is called loading a library. 

Ciao
-- 
Frank

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:

 now, that pd has its own [pow~], why not just using that? yeah, it takes
 a bit more time to write the abstractions, but then they are more
 vanilla friendly.

But that's exactly why I brought this topic up and asked: What to do
about pow~? 

Because of the reversed inlets you cannot use the buildin pow~ when
importing Max-patches without breaking the patch. 

I think, the smartest thing would be to use the builtin pow~, but
reverse the *connections* made to it. Because that's what I'd have to do
manually now after importing a Max patch with cyclone. 

An alternative would be to rename the pow~ in cyclone to something like
[max_pow~] or [Pow~] and use that instead when importing.

I suppose the connection-mangling is not trivial to write and as only
this one object is affected, it may be easier to just do it manually
when needed. The feature, that Pd now reports overwritten classes is
very useful for spotting such differences.

Ciao
-- 
Frank

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-17 Thread IOhannes m zmoelnig


Hans-Christoph Steiner wrote:

On Feb 16, 2009, at 4:24 AM, Frank Barknecht wrote:




What do you propose?  The built-in stuff is loaded first, so that will  
break patches that rely on [pow~] being the cyclone object.


the implications you make do not necessarily hold true for 0.42.
(does this sentence make sense at all?)

i still think that the loading-order in 0.42 is broken by design.

fgamsr
IOhannes


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:

 i still think that the loading-order in 0.42 is broken by design.

Could you elaborate this a bit? Or point me to the relevant archive
post? How is the loading order in 0.42?

Ciao
-- 
Frank

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-17 Thread IOhannes m zmoelnig


Frank Barknecht wrote:

Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:


On Tue, 2009-02-17 at 07:26 +0100, Frank Barknecht wrote:
how can someone assume so?  no, that is so not true. i didn't even know,
that zexy comes with their own version of [pack] and [unpack] until some
weeks ago. and why the hell to they use the same names as internals?
no, by no means i don't want to be forced to use the zexy version, just
because some patches i use need zexy. 


You have been forced to do so for many years, you just haven't been told
about it until 0.42. I just now discovered that something is overwriting
my [wrap]. I don't know yet which library does that. It would be nice if
Pd could report the source library file together with the warning.


It's a difference between Pd = 0.42 and Pd  0.42.  I don't think,
overriding builtins ever worked with single-file externals, 

that is what i am saying: this is introducing a _new_ incompatibility
between pd-extended and pd vanilla.


this i don't understand; it is an incompatibility between prior and post 
0.42, no matter whether you are using pd-vanilla or pd-ext.
just because pd-ext is still far from 0.42, doesn't mean that it will 
take counter-measures when the time is ripe.




Huh? The only incompatibility is the new *feature* of alias names for
overwritten objects. 0.42's [pow~] or [abs~] also are a new *feature*
implemented by popular demand. Loading libraries and the overwriting
itself hasn't changed at all AFAIK. If you don't use the alias names,
you don't have any problems. 


imo, the entire alias thing does not deserve it's name.
who will ever want to have [pow~_alias] in their patches?

now what happens if we have 2 (multi-object) libraries loaded, both of 
them containing [pow~].
do we get [pow~_alias_alias] or will the internal just vanish from the 
users scope? if so, why is there an arbitrary boundary at 2?


this all brings back the original idea of implicetely adding the 
libraries name somehow for aliases.

e.g. [pow~] in pd, lib1, and lib2 (in this order)
1. Pd's [pow~]
2. lib1 gets loaded; the original [pow~] becomes [pd/pow~]; the lib1's 
one is now known as [pow~]
3. lib1 get's loaded; Pd's [pd/pow~] stays untouched; lib1's one becomes 
[lib1/pow~]; the new one is know as [pow~]


darn, this is all the thing i have written 6 (or so) years ago.
i remember there have been good reasons not to do it like this.

nevertheless, the idea is kind of re-occurant to me; and i firmly 
believe it is a better solution than to add an _alias suffix.






but maybe
I'm wrong. IOhannes? 


overriding with single object externals never worked, because Pd does 
not see a reason to even try and open a library file which could then 
overwrite the internal.



The overriding with lib-libraries works as before,


no it does not.
Pd never (that is: prior to 0.42) provided a way to overwrite existing 
classes. this holds true for multi-object libraries.

cyclone did some very special tricks to override existing objects.

btw, it tried to do so in a quite sensible way: if the new 
cyclone-object failed to create (e.g. because of wron arguments to the 
object), it would fall-back to the original object.




I agree with you that external libraries generally shouldn't overwrite
builtins. When using Cyclone for Max-importing it makes sense, though.


actually i don't see a big problem.
it would be the external's responsibility to maintain full 
compatibility. if it is not compatible (like zexy's [pack] right now), 
then this is just a bug in the external.
the problem with zexy's [pack] overriding the internal was just because 
i was caught on the back foot, believing that i was save for now until 
the incompatibililties were fixed...




But IMO the aliasing is less insane than not being able to use the
builtins at all, as is the case if you load object-overwriting-libraries
like zexy or cyclone in any Pd version before 0.42, including
pd-extended. 


aliasing is not bad.
what is bad is the way the aliases are generated



Note that here I use libraries in the -lib-loading
many-externals-in-one-file sense here, not in the sense where everything
(libs, singles, abstractions, libdirs) is called a library and setting
a path is called loading a library. 


yes, i agree we should not call adding a path loading a library.
expanding the namespace might be better.



mhadft
IOhannes


smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-17 Thread Matt Barber

 I think, the smartest thing would be to use the builtin pow~, but
 reverse the *connections* made to it. Because that's what I'd have to do
 manually now after importing a Max patch with cyclone.

 An alternative would be to rename the pow~ in cyclone to something like
 [max_pow~] or [Pow~] and use that instead when importing.

 I suppose the connection-mangling is not trivial to write and as only
 this one object is affected, it may be easier to just do it manually
 when needed. The feature, that Pd now reports overwritten classes is
 very useful for spotting such differences.


This is now two separate but related issues:

1)  Importing max/MSP into Pd + cyclone

2)  Maintaining backwards compatibility for Pd patches written in Pd + cyclone


The differences are not trivial.  If it were just importing max files,
then the problem is now in the translator, and the obvious solutions
in my opinion are the ones you just mentioned.

But that would break files that were patched in earlier versions of
Pd+cyclone in the first place.  In this case, I think that [pow~]
should throw a warning for a while.  And because Pd has a find
feature it will not be difficult to find instances of pow~ and change
the connections, or to make a little abstraction with crossed inlet~s
called max_pow~ or whatever you like and then find and replace.
Cyclone could even come with another utility to do this automatically
-- anyway I think backward-compatibility is the lib's responsibility,
not Pd's.

Matt

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-17 Thread Hans-Christoph Steiner


On Feb 17, 2009, at 2:20 AM, Roman Haefeli wrote:

 On Tue, 2009-02-17 at 07:30 +0100, Frank Barknecht wrote:
 Hallo,
 Matt Barber hat gesagt: // Matt Barber wrote:

 Getting rid of cyclone's pow~ would break all of the patches that  
 rely
 on cyclone's pow~, and would also make it harder to import Max/MSP
 patches.  Removing it is not a solution.

 Okay.  But I don't see why something that is a rather obvious breach
 of style should be allowed to bully the rest of the application.  I
 have never used Max/MSP, but it seems like its (and cyclone's)  
 [pow~]
 is really something more like an [exp~] with a changeable base.

 Cyclone's overriding is pretty important for importing Max files.

 but it obviously doesn't work on pd extended. so lets just skip that
 one.

it should now, I added the 'cyclone' and 'maxmode' objects to Pd- 
extended last night.  I didn't really test it much though.

.hc



 roman



   
 ___
 Telefonate ohne weitere Kosten vom PC zum PC: http:// 
 messenger.yahoo.de


 ___
 Pd-dev mailing list
 Pd-dev@iem.at
 http://lists.puredata.info/listinfo/pd-dev





   ¡El pueblo unido jamás será vencido!



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-17 Thread Hans-Christoph Steiner

On Feb 17, 2009, at 2:37 AM, Roman Haefeli wrote:

On Tue, 2009-02-17 at 00:36 -0500, Matt Barber wrote:
Getting rid of cyclone's pow~ would break all of the patches that
rely
on cyclone's pow~, and would also make it harder to import Max/MSP
patches. Removing it is not a solution.

Okay. But I don't see why something that is a rather obvious breach
of style should be allowed to bully the rest of the application. I
have never used Max/MSP, but it seems like its (and cyclone's) [pow~]
is really something more like an [exp~] with a changeable base.

In my view -- this is an open-source program which is more or less
guaranteed to evolve. If your patch breaks with a new version, use
an
older version, or find and fix the problems in the patch. To me it
is
a problem to avoid improvements to the language to maintain backward
compatibility at all costs, and much better to throw warnings --
Warning: your patch might be broken: look for all instances of pow~.
Thank you. =o)

The best solution in any of these circumstances is the least worst
solution. As far as I can tell the least worst solution is the one
with the most patch-level control for the libraries. As a user I
would rather do the research to see which externals I needed than to
be forced into accepting one or the other, ESPECIALLY if vanilla
classes are overwritten -- this seems the most egregious to me.
Pd+libs and Pd-extended should support vanilla patching, since many
users insist upon vanilla only -- worrying about cyclone and allowing
vanilla to break seems to me to be putting the cart before the horse
with regard to backward compatibility. Pd is not Max/MSP. Should
you
really have to import vanilla?

Thanks,

yo.. i very much agree with you. isn't it the wrong approach to use so
many tricks and kludges just to keep backwards compatibility? isn't
that
just a too expensive goal?

i mean, there have been so many discussions about how to load
libraries,
extend namespaces and such and then there is much not working yet,
respectively there are still a lot of incompatibilies between
pd-extended and pd vanilla, is it wise to introduce _now_ such a
feature? for me it is clearly another step away from a more consistent
pd world. and i am a bit confused to see, that this is done
deliberately.

roman

I don't know of any incompatibilities between Pd-vanilla and Pd-
extended in this regard. The incompability here is between the old
cyclone pow~ which has been around for a long time, and Pd-vanilla
0.42's pow~. In the bigger sense, the library incompatibilities
between Pd-extended and some builds of Pd-vanilla come from the
different library formats. If you build Pd-vanilla with the same
library format at Pd-extended, then it'll all be compatible. There
isn't a standard way to include libraries in Pd-vanilla, so there are
bound to be incompatibilities between different installations.

Try it yourself:

http://autobuild.puredata.info/auto-build/latest/Pd-0.42.4-vanilla+libs-debian-stable-i386.deb

.hc

Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-17 Thread Hans-Christoph Steiner


On Feb 17, 2009, at 3:45 AM, Frank Barknecht wrote:

 Hallo,
 Roman Haefeli hat gesagt: // Roman Haefeli wrote:

 now, that pd has its own [pow~], why not just using that? yeah, it  
 takes
 a bit more time to write the abstractions, but then they are more
 vanilla friendly.

 But that's exactly why I brought this topic up and asked: What to do
 about pow~?

 Because of the reversed inlets you cannot use the buildin pow~ when
 importing Max-patches without breaking the patch.

 I think, the smartest thing would be to use the builtin pow~, but
 reverse the *connections* made to it. Because that's what I'd have  
 to do
 manually now after importing a Max patch with cyclone.

 An alternative would be to rename the pow~ in cyclone to something  
 like
 [max_pow~] or [Pow~] and use that instead when importing.

This breaks old patches that rely on cyclone's [pow~].  This is a  
problem that many people have addressed in languages like python,  
java, ruby, etc.  The solutions generally look very similar, from what  
I have seen, so I think we should learn from their experience.

The last major piece of the puzzle is making loaded binary objectclass  
names be in the canvas-local namespace, just like abstractions are  
now.  Unfortunately, that's not so easy to write.  But I think its the  
right thing to do.

.hc


 I suppose the connection-mangling is not trivial to write and as only
 this one object is affected, it may be easier to just do it manually
 when needed. The feature, that Pd now reports overwritten classes is
 very useful for spotting such differences.

 Ciao
 -- 
 Frank

 ___
 Pd-dev mailing list
 Pd-dev@iem.at
 http://lists.puredata.info/listinfo/pd-dev





Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.  Now that he can realize them, he must either  
change them, or perish.-William Carlos Williams



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:

 correct me, if this is wrong, but i understand, that overriding internal
 classes doesn't work with single-file externals. so the feature of
 overriding internal classes doesn't and won't work with pd-extended.

I believe that's not quite correct: AFAIK overriding classes requires
that a file is loaded with -lib filename. -lib also works for
single-file-externals and is still supported in Pd-extended for all I
know. :)

Ciao
-- 
Frank

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-17 Thread Steffen Juul


On 17/02/2009, at 10.12, Frank Barknecht wrote:

 Hallo,
 IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:

 i still think that the loading-order in 0.42 is broken by design.

 Could you elaborate this a bit? Or point me to the relevant archive
 post? How is the loading order in 0.42?

I'm guessing he means that the internals are loaded first, then the  
libs (in any meaning Pd-wise). And not the other way around: Libs  
first, then the internals.

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-17 Thread Steffen Juul


On 17/02/2009, at 6.36, Matt Barber wrote:

 If your patch breaks with a new version, use an
 older version (...)

I totally agree.

That's also why i like when things (applications written in Pd or  
libraries for Pd) have a version number and refer to version numbers  
of it's dependencies, such that the user (at any level) actually can  
preform the action 'use an older version'.

(end of rant - i.e. i know freedom will make sure that never happens)

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

2009-02-17 Thread Steffen Juul


On 17/02/2009, at 21.06, Frank Barknecht wrote:

 Hallo,
 Roman Haefeli hat gesagt: // Roman Haefeli wrote:

 correct me, if this is wrong, but i understand, that overriding  
 internal
 classes doesn't work with single-file externals. so the feature of
 overriding internal classes doesn't and won't work with pd-extended.

 I believe that's not quite correct: AFAIK overriding classes requires
 that a file is loaded with -lib filename. -lib also works for
 single-file-externals and is still supported in Pd-extended for all I
 know. :)

So if you load a single-file-external without the -lib flag but just  
having it in the path does not override any internal (object-)classes?

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]