Re: [PD] mapping: path setting hell
On Apr 9, 2009, at 2:33 AM, cyrille henry wrote: Hans-Christoph Steiner a écrit : On Apr 8, 2009, at 5:59 AM, cyrille henry wrote: Hans-Christoph Steiner a écrit : Inside of the objects themselves, I use always the [mapping/ reverse] form. Only in the help patches do I use the [reverse] form. That convention seemed to make sense at the time, but I am not married to it. since all mapping object are in the same directory, using the [reverse] form inside the object will still work on pd-extended. but it will also make the mapping lib more flexible (you'll be able to move the objects / copy them in your patch directory ). So i see this as a big improvement of the situation. do you agree if i change this? Unfortunately, that's not entirely true, otherwise I would say to change it. Right now, a binary object will trump ANY abstraction, even if it is in the same directory. So if someone loads a binary object called "reverse", then [reverse] will ALWAYS be that binary, so matter where you put reverse.pd or how you load it. [mapping/ reverse] prevents that. name clash are bad. curently it's a fact. things may change in the future, but now nameclash must be avoid. since there already are nameclash, it's important for a user to have a full control of the object used. i do this by copying abstraction in my patch folder. it also allow my patch to work latter, when the abstraction have changed. Copying the abstraction into the same folder as the project will not prevent the problem I described above. As things are, that's not a solution. I think it'll work most of time, like most of these methods we discuss back and forth. The namespace prefix like [mapping/reverse] is also not infallable, but it is a lot less likely to be affected by nameclashes, since there would have to be both a folder and a file named the same. It seems to me a good starting place. In any case, nameclashes are an old issue, many people have tackled it, I think we can learn from them and make a Pd-ish implementation of namespaces/import that is not complicated. I think we can make a solution that always works. I am not satisfied with just using the current situation. I've been burned too many times in projects and while teaching workshops and classes by name conflicts. The output~ one is a recent example. .hc This is a perfect case of why we should change the load order in Pd. ok. change it if you wish. but don't find workaround with solution that work only for you. sorry if i'm rude, but i'm more and more irritated by this problem. c I think it should search for all object types in a given path (i.e. .pd .pd_linux, .pd_lua, etc.) THEN it should search the next path. Currently the opposite happens: it searches .pd_linux in all paths, then the loaders (i.e. .pd_lua) in all paths, then the abstractions in all paths. .hc "[W ]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity."-John Gilmore ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list '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-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
moses 0 filter also negative arguments, they usually are unwanted. but of course sel 0 is used the rest of the time. c IOhannes m zmoelnig a écrit : cyrille henry wrote: Hans-Christoph Steiner a écrit : ... If there is good code out there, I want to use it, not reinvent it. having a complex abstraction to replace this : loadbang $1 moses 0 shouldn't that be [select 0] rather than [moses 0] ? mfgasd.r IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
cyrille henry wrote: Hans-Christoph Steiner a écrit : ... If there is good code out there, I want to use it, not reinvent it. having a complex abstraction to replace this : loadbang $1 moses 0 shouldn't that be [select 0] rather than [moses 0] ? mfgasd.r IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
Hans-Christoph Steiner a écrit : ... If there is good code out there, I want to use it, not reinvent it. having a complex abstraction to replace this : loadbang $1 moses 0 is overkill. it add complexity to a simple patch. If you use mapping in Pd-extended, you never need to know anything about what's happening inside, it just works. if you don't use pd extended, it just don't work. i already explain why i don't use pd-extended, and will not change my mind soon. With a little bit of effort, Pd-vanilla users can also acheive this. That's why I am fixing up libdir.c and these libraries in SVN. i just don't want to add complexity to a simple thing, just because you think it's better. These libraries were a place for me to experiment with ways of handling libraries in Pd easier. for me it was something for everyday use! and i basically can't use it the way i want, and the way i made it. Some of the experiments failed, but I think right now its in a pretty good place. So try it out the way it is now and tell me what doesn't work. to have mapping/reverse in the object break the way i work with pd for the last 8 years. to use [float_argument] that is outside the mapping folder cause problem to. (remember the pm mapping presentation @ hangar?) at least, it could be copy / linked on the mapping directory. the best would be of course to replace it with a more simpler code based on 3 simple object. (well, to revert the change you made to my objects) this are the biggest problem i've got. cyrille ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
Hans-Christoph Steiner a écrit : On Apr 8, 2009, at 5:59 AM, cyrille henry wrote: Hans-Christoph Steiner a écrit : Inside of the objects themselves, I use always the [mapping/reverse] form. Only in the help patches do I use the [reverse] form. That convention seemed to make sense at the time, but I am not married to it. since all mapping object are in the same directory, using the [reverse] form inside the object will still work on pd-extended. but it will also make the mapping lib more flexible (you'll be able to move the objects / copy them in your patch directory ). So i see this as a big improvement of the situation. do you agree if i change this? Unfortunately, that's not entirely true, otherwise I would say to change it. Right now, a binary object will trump ANY abstraction, even if it is in the same directory. So if someone loads a binary object called "reverse", then [reverse] will ALWAYS be that binary, so matter where you put reverse.pd or how you load it. [mapping/reverse] prevents that. name clash are bad. curently it's a fact. things may change in the future, but now nameclash must be avoid. since there already are nameclash, it's important for a user to have a full control of the object used. i do this by copying abstraction in my patch folder. it also allow my patch to work latter, when the abstraction have changed. This is a perfect case of why we should change the load order in Pd. ok. change it if you wish. but don't find workaround with solution that work only for you. sorry if i'm rude, but i'm more and more irritated by this problem. c I think it should search for all object types in a given path (i.e. .pd .pd_linux, .pd_lua, etc.) THEN it should search the next path. Currently the opposite happens: it searches .pd_linux in all paths, then the loaders (i.e. .pd_lua) in all paths, then the abstractions in all paths. .hc "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity."-John Gilmore ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
On Apr 8, 2009, at 3:23 PM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Apr 8, 2009, at 5:35 AM, cyrille henry wrote: i think for this specific lib, any dependency of object outside it's directory can be seen as a bug. I don't understand this at all. Why did every modern operating system spend massive amounts of work to switch from static linking of libraries (i.e. including the library with the program itself) to dynamic, shared libraries (i.e. a single copy of a library shared by all programs that use it)? I think, advantages and disadvantages have to be weighted, and IMO mapping currently is leaning to a not very user friendly side. For example its use of [float_argument], [symbol_argument] and [once] from purepd creates a dependency on purepd that is completely unnecessary: [once] is only used once, [symbol_argument] also, and float_argument very often is used where a simple [f $1] would be enough (its second argument is empty). So I'd say, get rid of it and be more friendly to users. If there is good code out there, I want to use it, not reinvent it. If you use mapping in Pd-extended, you never need to know anything about what's happening inside, it just works. With a little bit of effort, Pd-vanilla users can also acheive this. That's why I am fixing up libdir.c and these libraries in SVN. Another case is the "standardization" to use abstraction names, that require the (sometimes broken) hexloader: Life would be much easier for a lot of people without the "->" convention. Indeed, I fully agree. That's why I fixed it over a year ago :D mapping needs to hexloader tricks. Other cases may not be so easy to fix and some externals are hard to replace, but as it currenly is, mapping looks like a collection that puts some abstract design principles higher than actual user demands. Of course that's just my humble opinion, which is leaning to a much more simplistic side. These libraries were a place for me to experiment with ways of handling libraries in Pd easier. Some of the experiments failed, but I think right now its in a pretty good place. So try it out the way it is now and tell me what doesn't work. .hc Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list All information should be free. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > On Apr 8, 2009, at 5:35 AM, cyrille henry wrote: >> i think for this specific lib, any dependency of object outside it's >> directory can be seen as a bug. > > I don't understand this at all. Why did every modern operating system > spend massive amounts of work to switch from static linking of libraries > (i.e. including the library with the program itself) to dynamic, shared > libraries (i.e. a single copy of a library shared by all programs that > use it)? I think, advantages and disadvantages have to be weighted, and IMO mapping currently is leaning to a not very user friendly side. For example its use of [float_argument], [symbol_argument] and [once] from purepd creates a dependency on purepd that is completely unnecessary: [once] is only used once, [symbol_argument] also, and float_argument very often is used where a simple [f $1] would be enough (its second argument is empty). So I'd say, get rid of it and be more friendly to users. Another case is the "standardization" to use abstraction names, that require the (sometimes broken) hexloader: Life would be much easier for a lot of people without the "->" convention. Other cases may not be so easy to fix and some externals are hard to replace, but as it currenly is, mapping looks like a collection that puts some abstract design principles higher than actual user demands. Of course that's just my humble opinion, which is leaning to a much more simplistic side. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > Luckily the solution is simple: "svn update". Sounds like you are > working with an old copy. The folder "externals/mapping/help" should be > gone, all the help patches in "externals/mapping", and there should be a > "externals/mapping/mapping-meta.pd" file. Otherwise, you're working with > old code. Ah, indeed, I was using the wrong outdated copy, so sorry for the wrong help-file noise. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
On Apr 8, 2009, at 1:54 AM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: You cheat a bit here: "svn co whereverlibdiris; make libdir", and I don't know, if help-files in mapping work then - with just your sets they won't. And you still have the requirement of putting the directories mapping and purepd into a directory in the pd path like "extra", so it's still four paths to set, just like I wrote in my first mail. How about checking whether help files work before reporting the problem? I wrote "I don't know if helpp-files work" - but I've tried it now. You only need to install libdir once. Plus if you use the latest version of libdir, then 'extra' can be any folder in the path. I suggest one of these: http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files-with-pd-extended Okay, here's what I did: $ cp -a SVN/mapping /usr/lib/pd/extra $ cd SVN/loaders $ svn update $ make (to make libdir.pd_linux) $ pd -lib libdir -lib mapping gives this: ... libdir loader $Revision: 1.8 $ compiled on Apr 8 2009 at 07:46:59 compiled against Pd version 0.42.4. mapping: can't load library ... and I still cannot create any mapping object. I was able to fix that by adding a mapping-meta.pd file manually (copied from some pd-extended source on my disk, could find one in SVN's trunk). Help files still don't work. According to http://puredata.info/docs/developer/Libdir help-files have to be either in 5.reference/libname or next to the object in question. Both is not the case the way mapping is laid out and again something, that has to be done manually. That's all pretty complicated for a newbie like me. :) Luckily the solution is simple: "svn update". Sounds like you are working with an old copy. The folder "externals/mapping/help" should be gone, all the help patches in "externals/mapping", and there should be a "externals/mapping/mapping-meta.pd" file. Otherwise, you're working with old code. .hc Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
On Apr 8, 2009, at 5:59 AM, cyrille henry wrote: Hans-Christoph Steiner a écrit : Inside of the objects themselves, I use always the [mapping/ reverse] form. Only in the help patches do I use the [reverse] form. That convention seemed to make sense at the time, but I am not married to it. since all mapping object are in the same directory, using the [reverse] form inside the object will still work on pd-extended. but it will also make the mapping lib more flexible (you'll be able to move the objects / copy them in your patch directory ). So i see this as a big improvement of the situation. do you agree if i change this? Unfortunately, that's not entirely true, otherwise I would say to change it. Right now, a binary object will trump ANY abstraction, even if it is in the same directory. So if someone loads a binary object called "reverse", then [reverse] will ALWAYS be that binary, so matter where you put reverse.pd or how you load it. [mapping/reverse] prevents that. This is a perfect case of why we should change the load order in Pd. I think it should search for all object types in a given path (i.e. .pd .pd_linux, .pd_lua, etc.) THEN it should search the next path. Currently the opposite happens: it searches .pd_linux in all paths, then the loaders (i.e. .pd_lua) in all paths, then the abstractions in all paths. .hc "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity."-John Gilmore ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
On Apr 8, 2009, at 5:35 AM, cyrille henry wrote: Frank Barknecht a écrit : Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Yes, there is some absurdity to this conversation. I guess Frank and I have been doing this for so long, its just part of a game we play ;-) Anyway, I could give the instructions in one step: 1. use Pd-extended ;-) But that's exactly what I mean: "mapping" IMO has become promotion material for pd-extended, but increasingly hard to use for users of newer Pd versions or alternative distributions. specially since it's mainly abstraction, i don't understand why we need to install it. i think for this specific lib, any dependency of object outside it's directory can be seen as a bug. I don't understand this at all. Why did every modern operating system spend massive amounts of work to switch from static linking of libraries (i.e. including the library with the program itself) to dynamic, shared libraries (i.e. a single copy of a library shared by all programs that use it)? .hc c I don't think many newbies really want to get into the nitty- gritty of hand-built Pd installs, but this conversation did make me smooth out the installation process. Before, the 10 steps were for creating a library from scratch. I think its pretty simple considering. Now, the libraries are pre-built in SVN, so you only need to: 1. cd /path/to/your/extra (or wherever you want to install stuff) 2. svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mapping 3. svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/purepd 4. pd -lib libdir -lib purepd -lib mapping You cheat a bit here: "svn co whereverlibdiris; make libdir", and I don't know, if help-files in mapping work then - with just your sets they won't. And you still have the requirement of putting the directories mapping and purepd into a directory in the pd path like "extra", so it's still four paths to set, just like I wrote in my first mail. Ciao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ¡El pueblo unido jamás será vencido! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
Hans-Christoph Steiner a écrit : Inside of the objects themselves, I use always the [mapping/reverse] form. Only in the help patches do I use the [reverse] form. That convention seemed to make sense at the time, but I am not married to it. since all mapping object are in the same directory, using the [reverse] form inside the object will still work on pd-extended. but it will also make the mapping lib more flexible (you'll be able to move the objects / copy them in your patch directory ). So i see this as a big improvement of the situation. do you agree if i change this? Cyrille ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
Frank Barknecht a écrit : Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Yes, there is some absurdity to this conversation. I guess Frank and I have been doing this for so long, its just part of a game we play ;-) Anyway, I could give the instructions in one step: 1. use Pd-extended ;-) But that's exactly what I mean: "mapping" IMO has become promotion material for pd-extended, but increasingly hard to use for users of newer Pd versions or alternative distributions. specially since it's mainly abstraction, i don't understand why we need to install it. i think for this specific lib, any dependency of object outside it's directory can be seen as a bug. c I don't think many newbies really want to get into the nitty-gritty of hand-built Pd installs, but this conversation did make me smooth out the installation process. Before, the 10 steps were for creating a library from scratch. I think its pretty simple considering. Now, the libraries are pre-built in SVN, so you only need to: 1. cd /path/to/your/extra (or wherever you want to install stuff) 2. svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mapping 3. svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/purepd 4. pd -lib libdir -lib purepd -lib mapping You cheat a bit here: "svn co whereverlibdiris; make libdir", and I don't know, if help-files in mapping work then - with just your sets they won't. And you still have the requirement of putting the directories mapping and purepd into a directory in the pd path like "extra", so it's still four paths to set, just like I wrote in my first mail. Ciao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: >> You cheat a bit here: "svn co whereverlibdiris; make libdir", and I don't >> know, if help-files in mapping work then - with just your sets they won't. >> And you still have the requirement of putting the directories mapping and >> purepd into a directory in the pd path like "extra", so it's still four >> paths to set, just like I wrote in my first mail. > > How about checking whether help files work before reporting the problem? I wrote "I don't know if helpp-files work" - but I've tried it now. > You only need to install libdir once. Plus if you use the latest version > of libdir, then 'extra' can be any folder in the path. I suggest one of > these: > > http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files-with-pd-extended Okay, here's what I did: $ cp -a SVN/mapping /usr/lib/pd/extra $ cd SVN/loaders $ svn update $ make (to make libdir.pd_linux) $ pd -lib libdir -lib mapping gives this: ... libdir loader $Revision: 1.8 $ compiled on Apr 8 2009 at 07:46:59 compiled against Pd version 0.42.4. mapping: can't load library ... and I still cannot create any mapping object. I was able to fix that by adding a mapping-meta.pd file manually (copied from some pd-extended source on my disk, could find one in SVN's trunk). Help files still don't work. According to http://puredata.info/docs/developer/Libdir help-files have to be either in 5.reference/libname or next to the object in question. Both is not the case the way mapping is laid out and again something, that has to be done manually. That's all pretty complicated for a newbie like me. :) Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
On Apr 8, 2009, at 1:28 AM, Hans-Christoph Steiner wrote: On Apr 8, 2009, at 1:18 AM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Yes, there is some absurdity to this conversation. I guess Frank and I have been doing this for so long, its just part of a game we play ;-) Anyway, I could give the instructions in one step: 1. use Pd-extended ;-) But that's exactly what I mean: "mapping" IMO has become promotion material for pd-extended, but increasingly hard to use for users of newer Pd versions or alternative distributions. I don't think many newbies really want to get into the nitty- gritty of hand-built Pd installs, but this conversation did make me smooth out the installation process. Before, the 10 steps were for creating a library from scratch. I think its pretty simple considering. Now, the libraries are pre-built in SVN, so you only need to: 1. cd /path/to/your/extra (or wherever you want to install stuff) 2. svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mapping 3. svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/purepd 4. pd -lib libdir -lib purepd -lib mapping You cheat a bit here: "svn co whereverlibdiris; make libdir", and I don't know, if help-files in mapping work then - with just your sets they won't. And you still have the requirement of putting the directories mapping and purepd into a directory in the pd path like "extra", so it's still four paths to set, just like I wrote in my first mail. How about checking whether help files work before reporting the problem? You only need to install libdir once. Plus if you use the latest version of libdir, then 'extra' can be any folder in the path. I suggest one of these: http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files-with-pd-extended Oops, forgot the link to the libdir binary, no compiling necessary. Its the older one, so that still requires installing into 'extra', I am working on a new release: http://at.or.at/hans/pd/objects.html#libdir .hc .hc Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity."-John Gilmore ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
On Apr 8, 2009, at 1:18 AM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Yes, there is some absurdity to this conversation. I guess Frank and I have been doing this for so long, its just part of a game we play ;-) Anyway, I could give the instructions in one step: 1. use Pd-extended ;-) But that's exactly what I mean: "mapping" IMO has become promotion material for pd-extended, but increasingly hard to use for users of newer Pd versions or alternative distributions. I don't think many newbies really want to get into the nitty-gritty of hand-built Pd installs, but this conversation did make me smooth out the installation process. Before, the 10 steps were for creating a library from scratch. I think its pretty simple considering. Now, the libraries are pre-built in SVN, so you only need to: 1. cd /path/to/your/extra (or wherever you want to install stuff) 2. svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mapping 3. svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/purepd 4. pd -lib libdir -lib purepd -lib mapping You cheat a bit here: "svn co whereverlibdiris; make libdir", and I don't know, if help-files in mapping work then - with just your sets they won't. And you still have the requirement of putting the directories mapping and purepd into a directory in the pd path like "extra", so it's still four paths to set, just like I wrote in my first mail. How about checking whether help files work before reporting the problem? You only need to install libdir once. Plus if you use the latest version of libdir, then 'extra' can be any folder in the path. I suggest one of these: http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files-with-pd-extended .hc Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > Yes, there is some absurdity to this conversation. I guess Frank and I > have been doing this for so long, its just part of a game we play ;-) > > Anyway, I could give the instructions in one step: > > 1. use Pd-extended ;-) But that's exactly what I mean: "mapping" IMO has become promotion material for pd-extended, but increasingly hard to use for users of newer Pd versions or alternative distributions. > I don't think many newbies really want to get into the nitty-gritty of > hand-built Pd installs, but this conversation did make me smooth out the > installation process. Before, the 10 steps were for creating a library > from scratch. I think its pretty simple considering. Now, the libraries > are pre-built in SVN, so you only need to: > > 1. cd /path/to/your/extra (or wherever you want to install stuff) > 2. svn co > http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mapping > 3. svn co > http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/purepd > 4. pd -lib libdir -lib purepd -lib mapping You cheat a bit here: "svn co whereverlibdiris; make libdir", and I don't know, if help-files in mapping work then - with just your sets they won't. And you still have the requirement of putting the directories mapping and purepd into a directory in the pd path like "extra", so it's still four paths to set, just like I wrote in my first mail. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
On Apr 6, 2009, at 11:26 AM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote: Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: 1) SVN/externals - otherwise [center_point] isn't found 2) SVN/externals/mapping - to find [mapping/reverse] and [mapping/disjoin] These two were meant to have reversed reasons. Hmm, because you are doing it wrong? I'm not doing it wrong, it works fine. But because mapping is sometimes using prefixes internally, sometimes not (you get [float_argument] and [purepd/float_argument] or [reverse] and [mapping/reverse]) this results in users having to add twice the amount of paths or imports. Inside of the objects themselves, I use always the [mapping/reverse] form. Only in the help patches do I use the [reverse] form. That convention seemed to make sense at the time, but I am not married to it. .hc Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://at.or.at/hans/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
Yes, there is some absurdity to this conversation. I guess Frank and I have been doing this for so long, its just part of a game we play ;-) Anyway, I could give the instructions in one step: 1. use Pd-extended ;-) I don't think many newbies really want to get into the nitty-gritty of hand-built Pd installs, but this conversation did make me smooth out the installation process. Before, the 10 steps were for creating a library from scratch. I think its pretty simple considering. Now, the libraries are pre-built in SVN, so you only need to: 1. cd /path/to/your/extra (or wherever you want to install stuff) 2. svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mapping 3. svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/abstractions/purepd 4. pd -lib libdir -lib purepd -lib mapping If that doesn't work for you, there is a bug. That has been working with Pd-extended for some years now. As for issues with this setup, please elaborate on them so we can fix things. .hc On Apr 6, 2009, at 10:37 AM, Luigi wrote: Hey List. not wanting to offend anybody. But this has some good amount of absurdity in it, i think. And for any Newbie following that its actually quite frightening. Frank calls his way of doing "hell" and it only includes 3 steps. And Hans Christoph calls his way "easy" and it includes 10 steps monster monster-hell.. Another thing i always found strange about tthe mapping-collection. If you want to use the helpfiles in one of your patches and actually use more then one you get into conflicts What needs to be done to restructure mapping ?? I could help maybe, because its a library i used very often and found it very useful. I would be happy to do something good to that library ;-) All the Best Luigi Am 06.04.2009 um 15:58 schrieb Hans-Christoph Steiner: On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote: Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: 1) SVN/externals - otherwise [center_point] isn't found 2) SVN/externals/mapping - to find [mapping/reverse] and [mapping/disjoin] These two were meant to have reversed reasons. Hmm, because you are doing it wrong? Try this: 1. create a single place to store externals, I recommend ~/pd- externals/ 2. add it to your path 3. cd /path/to/pure-data/trunk/abstractions/ 4. cp -a purepd ~/pd-externals (mapping is still poorly organized in SVN, so its a bit harder) 5. cd /path/to/pure-data/trunk/externals/mapping 6. mkdir ~/pd-externals/mapping 7. cp -a *.pd ~/pd-externals/mapping 8. cd help 9. cp -a *-help.pd ~/pd-externals/mapping 10. touch ~/pd-externals/mapping/mapping-meta.pd That's it. Then if you have the libdir.pd_linux loader loaded, you can also load that as a lib using any of the standard methods. (you'll need the libdir.c from SVN). pd -lib libdir -lib mapping declare -lib mapping import mapping .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ¡El pueblo unido jamás será vencido! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
Luigi a écrit : Hey List. not wanting to offend anybody. But this has some good amount of absurdity in it, i think. And for any Newbie following that its actually quite frightening. Frank calls his way of doing "hell" and it only includes 3 steps. it's not the steps the problem, the problem come from what is imply by this step. And Hans Christoph calls his way "easy" and it includes 10 steps ;-) monster monster-hell.. Another thing i always found strange about tthe mapping-collection. If you want to use the helpfiles in one of your patches and actually use more then one you get into conflicts i don't understand what you want to do, can you elaborate? What needs to be done to restructure mapping ?? I could help maybe, because its a library i used very often and found it very useful. I would be happy to do something good to that library ;-) the problem is not human resource for restructuring this lib. it's just that Franck and I did not share the same way of thinking than hans. Cyrille All the Best Luigi Am 06.04.2009 um 15:58 schrieb Hans-Christoph Steiner: On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote: Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: 1) SVN/externals - otherwise [center_point] isn't found 2) SVN/externals/mapping - to find [mapping/reverse] and [mapping/disjoin] These two were meant to have reversed reasons. Hmm, because you are doing it wrong? Try this: 1. create a single place to store externals, I recommend ~/pd-externals/ 2. add it to your path 3. cd /path/to/pure-data/trunk/abstractions/ 4. cp -a purepd ~/pd-externals (mapping is still poorly organized in SVN, so its a bit harder) 5. cd /path/to/pure-data/trunk/externals/mapping 6. mkdir ~/pd-externals/mapping 7. cp -a *.pd ~/pd-externals/mapping 8. cd help 9. cp -a *-help.pd ~/pd-externals/mapping 10. touch ~/pd-externals/mapping/mapping-meta.pd That's it. Then if you have the libdir.pd_linux loader loaded, you can also load that as a lib using any of the standard methods. (you'll need the libdir.c from SVN). pd -lib libdir -lib mapping declare -lib mapping import mapping .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
Hey List. not wanting to offend anybody. But this has some good amount of absurdity in it, i think. And for any Newbie following that its actually quite frightening. Frank calls his way of doing "hell" and it only includes 3 steps. And Hans Christoph calls his way "easy" and it includes 10 steps monster monster-hell.. Another thing i always found strange about tthe mapping-collection. If you want to use the helpfiles in one of your patches and actually use more then one you get into conflicts What needs to be done to restructure mapping ?? I could help maybe, because its a library i used very often and found it very useful. I would be happy to do something good to that library ;-) All the Best Luigi Am 06.04.2009 um 15:58 schrieb Hans-Christoph Steiner: On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote: Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: 1) SVN/externals - otherwise [center_point] isn't found 2) SVN/externals/mapping - to find [mapping/reverse] and [mapping/disjoin] These two were meant to have reversed reasons. Hmm, because you are doing it wrong? Try this: 1. create a single place to store externals, I recommend ~/pd- externals/ 2. add it to your path 3. cd /path/to/pure-data/trunk/abstractions/ 4. cp -a purepd ~/pd-externals (mapping is still poorly organized in SVN, so its a bit harder) 5. cd /path/to/pure-data/trunk/externals/mapping 6. mkdir ~/pd-externals/mapping 7. cp -a *.pd ~/pd-externals/mapping 8. cd help 9. cp -a *-help.pd ~/pd-externals/mapping 10. touch ~/pd-externals/mapping/mapping-meta.pd That's it. Then if you have the libdir.pd_linux loader loaded, you can also load that as a lib using any of the standard methods. (you'll need the libdir.c from SVN). pd -lib libdir -lib mapping declare -lib mapping import mapping .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > > On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote: > >> Hallo, >> Frank Barknecht hat gesagt: // Frank Barknecht wrote: >> >>> 1) SVN/externals - otherwise [center_point] isn't found >>> 2) SVN/externals/mapping - to find [mapping/reverse] and >>> [mapping/disjoin] >> >> These two were meant to have reversed reasons. > > Hmm, because you are doing it wrong? I'm not doing it wrong, it works fine. But because mapping is sometimes using prefixes internally, sometimes not (you get [float_argument] and [purepd/float_argument] or [reverse] and [mapping/reverse]) this results in users having to add twice the amount of paths or imports. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
Hans-Christoph Steiner a écrit : On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote: Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: 1) SVN/externals - otherwise [center_point] isn't found 2) SVN/externals/mapping - to find [mapping/reverse] and [mapping/disjoin] These two were meant to have reversed reasons. Hmm, because you are doing it wrong? no, because mapping is doing it wrong. i'm more and more convinced that the only way i now have to use the object that i write is to fork this lib. it's a bad solution for everybody, but at last i'll be able to profit from my work. Cyrille ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
On Apr 6, 2009, at 8:33 AM, Frank Barknecht wrote: Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: 1) SVN/externals - otherwise [center_point] isn't found 2) SVN/externals/mapping - to find [mapping/reverse] and [mapping/disjoin] These two were meant to have reversed reasons. Hmm, because you are doing it wrong? Try this: 1. create a single place to store externals, I recommend ~/pd-externals/ 2. add it to your path 3. cd /path/to/pure-data/trunk/abstractions/ 4. cp -a purepd ~/pd-externals (mapping is still poorly organized in SVN, so its a bit harder) 5. cd /path/to/pure-data/trunk/externals/mapping 6. mkdir ~/pd-externals/mapping 7. cp -a *.pd ~/pd-externals/mapping 8. cd help 9. cp -a *-help.pd ~/pd-externals/mapping 10. touch ~/pd-externals/mapping/mapping-meta.pd That's it. Then if you have the libdir.pd_linux loader loaded, you can also load that as a lib using any of the standard methods. (you'll need the libdir.c from SVN). pd -lib libdir -lib mapping declare -lib mapping import mapping .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] mapping: path setting hell
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: > 1) SVN/externals - otherwise [center_point] isn't found > 2) SVN/externals/mapping - to find [mapping/reverse] and >[mapping/disjoin] These two were meant to have reversed reasons. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
