Now that I have the new build system working smoothly, I'd like to start removing files from externals/build/src, as the are put into externals/Makefile with their own specific Makefile targets. I am not suggesting removing any from the distros, just reorganizing things into individual libdirs so that the namespace works.
Any objections?
.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
Now that I have the new build system working smoothly, I'd like to start removing files from externals/build/src, as the are put into
someone spent a lot of time adding all those "#include ../../this/that.c" files..are you suggesting to undo this entirely? i guess my main question would be, am i now going to have to update the SConscript to check 50 directories instead of one after your changes. if thats the case i vote for leaving it how it is..
externals/Makefile with their own specific Makefile targets. I am not suggesting removing any from the distros, just reorganizing things into individual libdirs so that the namespace works.
i'm not sure what you mean by the 'namespace works'. is this the '[cc/prepend]' type thing? if so, that can be handled at install time for those that want it..
Any objections?
.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-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Dec 7, 2005, at 12:18 PM, ix wrote:
Now that I have the new build system working smoothly, I'd like to start removing files from externals/build/src, as the are put into
someone spent a lot of time adding all those "#include ../../this/that.c" files..are you suggesting to undo this entirely?
Those people in question were mostly Guenter and I (out of 943 commits to externals/build/src, I did 441, Guenter did 369). So yes, I am willing to undo my own work and I hope Guenter will agree. This system has worked well for us for a while, thanks to Guenter for building the foundation. But now there is something better.
I am not suggesting just deleting everything now, but just removing things as they are incorporated into externals/Makefile. Its especially important to remove objects with name conflicts from the root of extra. If, for example, [prepend] is directly in extra, then you won't be able to load a lib to use another [prepend]. Pd will always find the [prepend] in the root dir first.
The idea is to have externals/Makefile build the code right in place in the directory where its stored. Then each developer doesn't need to maintain their own build system. This is now done now for cxc, cyclone, ext13, freeverb~, motex, pddp, smlib, toxy, unauthorized, zexy. So there is no longer a need to create the "#include ../../this/that.c" link files, except for when the more than one file needs to be compiled into one object.
i guess my main question would be, am i now going to have to update the SConscript to check 50 directories instead of one after your changes. if thats the case i vote for leaving it how it is..
Again, I don't see any benefit to maintaining two separate build systems for the same thing, especially if it creates extra work for others who don't use the second build system. I have no problem if you want to use scons, I am sure scons can call "make install". Then scons can use the existing Makefiles and we won't be duplicating efforts.
If you want to have everything in one directory, you can easily do this: "find ~/build/extra -name '*.pd_linux' | xargs -J % cp % ~/build". Its much more work to go the other way once things are compiled and installed into one directory. Then you have to keep a list of what files go where. This list already exists in the form of the directories in "externals", so if the files are built in place, then its obvious where they came from so this structure makes sense on that level too.
.hc
externals/Makefile with their own specific Makefile targets. I am not suggesting removing any from the distros, just reorganizing things into individual libdirs so that the namespace works.
i'm not sure what you mean by the 'namespace works'. is this the '[cc/prepend]' type thing? if so, that can be handled at install time for those that want it..
Any objections?
.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-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
...
as for the deleting, feel free since you created the files in the first place, but keep in mind it will break the completeness of the SCons option if you start removing files...i prefer SCons since it is also used for building devel and actually works for me (see below)
But now there is something better.
ok... bug report then.. :)
(first try)
externals # make Makefile:24: /usr/src/pd/externals/../packages/Makefile.buildlayout: No such file or directory make: *** No rule to make target `/usr/src/pd/externals/../packages/Makefile.buildlayout'. Stop. :
fix: checkout "packages" - since this is a seperate module, perhaps the dep can be moved over since im guessing about 15% of users at most checkout "."..esp with all the weird stuff in it like framestein DLLs and PHP pages
(second try)
gcc -Wl,-export_dynamic -shared -o "/usr/src/pd/externals/../externals/cxc/ENV.pd_linux" "/usr/src/pd/externals/../externals/cxc/ENV.o" -lc -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/src/pd/externals/../externals/cxc/ENV.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/src/pd/externals/../externals/cxc/ENV.o: could not read symbols: Bad value collect2: ld returned 1 exit status
fix: add -fPIC to CFLAGS in /externals/makefile
(third try)
it finished...ok. 'make install' wait...why is it configuring more stuff?!?!?! this should have been done in the make step.
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../x86_64-pc-linux-gnu/bin/ld: sendOSC.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC sendOSC.o: could not read symbols: Bad value collect2: ld returned 1 exit status
fix: uh.. i guess go around to all these other makefiles and add -fPIC since it didnt properly inherit the one in /externals/makefile. imo this is the biggest advantage to the SCons system where you have a parent environment, set the flags once, and you _know_ all the subprojects are going to get the same flags and binary/doc location, since they dont even have their own makefiles.
also, i noticed after various -fPIC failures, it kept going. is it logging these somewhere?
(try four)
/bin/sh: /usr/src/pd/externals/../scripts/generate-libdir-metafile.sh: No such file or directory
fix: checkout "scripts" (see try one)
(try five)
more -fPIC stuff...only 'make clean' is not deleting .o files in the subprojects compiled without -fPIC, so i give up for now, to lazy to do some find . -iregex '.*.o' -exec rm {} ; ;)
.c....sure, 6 thru 10 once we get these figured out, im happy to try again...
.c....sure, 6 thru 10 once we get these figured out, im happy to try again...
(try 6)
sickle/Clip.c:17: error: static declaration of 'clip_perform' follows non-static declaration ../../../pd/src/m_pd.h:586: error: previous declaration of 'clip_perform' was here distcc[24317] ERROR: compile sickle/Clip.c on localhost failed
fix: not sure. what is the proper way to do the equivalent of the previous way to skip bad sources: rm src/Clip.c?
(try 7) (removed cyclone references from makefile since its broken)
"success: externals installed!"
however, typing 'make install' again makes it compile more stuff. this is odd indeed. its mainly unauthorized. it is compiling them over and over....
Feel free to fix things, there is a lot of old and random stuff left in there. unauthorized has a totally separate build system, so the fix would be in externals/unauthorized/Makefile. Since its Yves' stuff, you should probably clear it with him first.
.hc
On Dec 7, 2005, at 11:23 PM, ix wrote:
(try 7) (removed cyclone references from makefile since its broken)
"success: externals installed!"
however, typing 'make install' again makes it compile more stuff. this is odd indeed. its mainly unauthorized. it is compiling them over and over....
________________________________________________________________________ ____
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
ix wrote: ...
sickle/Clip.c:17: error: static declaration of 'clip_perform' follows non-static declaration ../../../pd/src/m_pd.h:586: error: previous declaration of 'clip_perform' was here
clip_perform() in the API? why?
even if there was a reason for adding it, still would be nice to get it prefixed (dsp_clip_perform() or something)
btw, this seems like definite forking...
Krzysztof
sickle/Clip.c:17: error: static declaration of 'clip_perform'
follows non-static declaration ../../../pd/src/m_pd.h:586: error: previous declaration of 'clip_perform' was here
clip_perform() in the API? why?
clipping an audio signal is not only useful for the clip~ object, but signals should also be clipped before sent to the audio driver .
even if there was a reason for adding it, still would be nice to get it prefixed (dsp_clip_perform() or something)
well, clip_perform() isn't really a good name, better would be clip_vec() or clip_vec_scalar() ... i decided to export all functions, that are coded in simd, to give external developers the possibility to use pd's simd functions ...
cheers ... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
i decided to export all functions, that are coded in simd, to give external developers the possibility to use pd's simd functions ...
Wouldn't it be better if devel introduced its own special header instead of changing m_pd.h?
Ciao
Am 08.12.2005 um 15:03 schrieb Frank Barknecht:
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
i decided to export all functions, that are coded in simd, to give external developers the possibility to use pd's simd functions ...
Wouldn't it be better if devel introduced its own special header instead of changing m_pd.h?
Yes, i think so. It would be good to have a separate header for the vector manipulation functions at least.
best, Thomas
Tim Blechmann wrote: ...
clip_perform() in the API? why?
clipping an audio signal is not only useful for the clip~ object, but signals should also be clipped before sent to the audio driver .
this is an internal business of the pd/asio driver, not an api thing
well, clip_perform() isn't really a good name, better would be clip_vec() or clip_vec_scalar() ...
i would prefer all api calls properly prefixed, making it all cleaner and safer
i decided to export all functions, that are coded in simd, to give external developers the possibility to use pd's simd functions ...
to me it is still not clear why an external would want to add clip_perform() to the dsp chain...
Krzysztof
On Dec 7, 2005, at 11:17 PM, ix wrote:
.c....sure, 6 thru 10 once we get these figured out, im happy to try again...
(try 6)
sickle/Clip.c:17: error: static declaration of 'clip_perform' follows non-static declaration ../../../pd/src/m_pd.h:586: error: previous declaration of 'clip_perform' was here distcc[24317] ERROR: compile sickle/Clip.c on localhost failed
I don't receive this error at all, how are you compiling things? Try this to go straight to the source:
cd externals/miXed/cyclone && make
I get no errors or warnings on the three computers I've been building on (probably because some warnings are turned off in the makefile).
fix: not sure. what is the proper way to do the equivalent of the previous way to skip bad sources: rm src/Clip.c?
make -k continues on errors.
.hc ________________________________________________________________________ ____
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
First off, thanks for the bug report.
On Dec 7, 2005, at 11:11 PM, ix wrote:
...
as for the deleting, feel free since you created the files in the first place, but keep in mind it will break the completeness of the SCons option if you start removing files...i prefer SCons since it is also used for building devel and actually works for me (see below)
I am not aiming to break things, I am trying to build as much as possible. What is in externals/build/src is only part of what is in externals/. But I am fine with leaving the files in externals/build/src in place, the only ones that need to be removed are the ones with name clashes, like change, prepend, average, scale, etc. They prevent access to the objects of the same name using the namespace (they'd always be found first in the path).
But now there is something better.
ok... bug report then.. :)
(first try)
externals # make Makefile:24: /usr/src/pd/externals/../packages/Makefile.buildlayout: No such file or directory make: *** No rule to make target `/usr/src/pd/externals/../packages/Makefile.buildlayout'. Stop. :
fix: checkout "packages" - since this is a seperate module, perhaps the dep can be moved over since im guessing about 15% of users at most checkout "."..esp with all the weird stuff in it like framestein DLLs and PHP pages
If its a problem, a copy of Makefile.buildlayout can easily be added to the base of externals. I had it there originally, but then removed it since I was changing it a fair amount and it was a pain to keep them in sync. It could even have different values that packages/Makefile.buildlayout if that would helpful. When the other Makefiles are called from packages/Makefile, they are redirected to packages/Makefile anyhow.
This is the layout that I assume in building this: http://puredata.org/docs/developer/devlayout
(second try)
gcc -Wl,-export_dynamic -shared -o "/usr/src/pd/externals/../externals/cxc/ENV.pd_linux" "/usr/src/pd/externals/../externals/cxc/ENV.o" -lc -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../ x86_64-pc-linux-gnu/bin/ld: /usr/src/pd/externals/../externals/cxc/ENV.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/src/pd/externals/../externals/cxc/ENV.o: could not read symbols: Bad value collect2: ld returned 1 exit status
fix: add -fPIC to CFLAGS in /externals/makefile
Oops, -fPIC was there, but this exposed another bug. I wonder why it was compiling fine for me on Linux...
(third try)
it finished...ok. 'make install' wait...why is it configuring more stuff?!?!?! this should have been done in the make step.
I fixed these two problems. Its a work in progress. When you look into the structure of all the code in externals, you'll see that its is far from clean. There are a number of hacky workarounds in externals/Makefile for sure.
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../ x86_64-pc-linux-gnu/bin/ld: sendOSC.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC sendOSC.o: could not read symbols: Bad value collect2: ld returned 1 exit status
fix: uh.. i guess go around to all these other makefiles and add -fPIC since it didnt properly inherit the one in /externals/makefile. imo this is the biggest advantage to the SCons system where you have a parent environment, set the flags once, and you _know_ all the subprojects are going to get the same flags and binary/doc location, since they dont even have their own makefiles.
This is also possible and preferred with Makefiles, I tried to take advantage of this as much as possible in the work I just did. Its just that there are a lot of legacy Makefiles around, and many of them don't conform to the Makefile standards. OSCx is not a straightforward build, so I haven't really messed with it at all. It would be nice if it worked on MinGW too.
also, i noticed after various -fPIC failures, it kept going. is it logging these somewhere?
This is a byproduct of calling another build system from the command line (i.e. cd blah/blah && make). It would work properly if it was part of the same Makefile.
(try four)
/bin/sh: /usr/src/pd/externals/../scripts/generate-libdir-metafile.sh: No such file or directory
fix: checkout "scripts" (see try one)
(try five)
more -fPIC stuff...only 'make clean' is not deleting .o files in the subprojects compiled without -fPIC, so i give up for now, to lazy to do some find . -iregex '.*.o' -exec rm {} ; ;)
Again a byproduct of using existing Makefiles. The stuff I have recently written all cleans up more or less properly after itself.
.c....sure, 6 thru 10 once we get these figured out, im happy to try again...
Please try again :)
.hc
________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
HI,
I think it is not necessary to delete the files in the src/ folder. It seems to be a cosmetic change only.
From the point of view of the CVS, the nameclash problem should not exist, so its not a good argument for deleting these files.
If the nameclash problem really exists, I propose to delete that in the first place. (We already solved the prepend problem, didn't we ?)
Although I think that "make" should be powerful enough to build the externals and Scons is not really needed, the thought of calling "make" from Scons seems to be everything else but a clean solution.
well, my humble opinion, but I do not want to interfere really, so at the end, personally, I don't care,
Cheers,
Günter
On Fri, 9 Dec 2005, Hans-Christoph Steiner wrote:
First off, thanks for the bug report.
On Dec 7, 2005, at 11:11 PM, ix wrote:
...
as for the deleting, feel free since you created the files in the first place, but keep in mind it will break the completeness of the SCons option if you start removing files...i prefer SCons since it is also used for building devel and actually works for me (see below)
I am not aiming to break things, I am trying to build as much as possible. What is in externals/build/src is only part of what is in externals/. But I am fine with leaving the files in externals/build/src in place, the only ones that need to be removed are the ones with name clashes, like change, prepend, average, scale, etc. They prevent access to the objects of the same name using the namespace (they'd always be found first in the path).
But now there is something better.
ok... bug report then.. :)
(first try)
externals # make Makefile:24: /usr/src/pd/externals/../packages/Makefile.buildlayout: No such file or directory make: *** No rule to make target `/usr/src/pd/externals/../packages/Makefile.buildlayout'. Stop. :
fix: checkout "packages" - since this is a seperate module, perhaps the dep can be moved over since im guessing about 15% of users at most checkout "."..esp with all the weird stuff in it like framestein DLLs and PHP pages
If its a problem, a copy of Makefile.buildlayout can easily be added to the base of externals. I had it there originally, but then removed it since I was changing it a fair amount and it was a pain to keep them in sync. It could even have different values that packages/Makefile.buildlayout if that would helpful. When the other Makefiles are called from packages/Makefile, they are redirected to packages/Makefile anyhow.
This is the layout that I assume in building this: http://puredata.org/docs/developer/devlayout
(second try)
gcc -Wl,-export_dynamic -shared -o "/usr/src/pd/externals/../externals/cxc/ENV.pd_linux" "/usr/src/pd/externals/../externals/cxc/ENV.o" -lc -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../ x86_64-pc-linux-gnu/bin/ld: /usr/src/pd/externals/../externals/cxc/ENV.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/src/pd/externals/../externals/cxc/ENV.o: could not read symbols: Bad value collect2: ld returned 1 exit status
fix: add -fPIC to CFLAGS in /externals/makefile
Oops, -fPIC was there, but this exposed another bug. I wonder why it was compiling fine for me on Linux...
(third try)
it finished...ok. 'make install' wait...why is it configuring more stuff?!?!?! this should have been done in the make step.
I fixed these two problems. Its a work in progress. When you look into the structure of all the code in externals, you'll see that its is far from clean. There are a number of hacky workarounds in externals/Makefile for sure.
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../ x86_64-pc-linux-gnu/bin/ld: sendOSC.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC sendOSC.o: could not read symbols: Bad value collect2: ld returned 1 exit status
fix: uh.. i guess go around to all these other makefiles and add -fPIC since it didnt properly inherit the one in /externals/makefile. imo this is the biggest advantage to the SCons system where you have a parent environment, set the flags once, and you _know_ all the subprojects are going to get the same flags and binary/doc location, since they dont even have their own makefiles.
This is also possible and preferred with Makefiles, I tried to take advantage of this as much as possible in the work I just did. Its just that there are a lot of legacy Makefiles around, and many of them don't conform to the Makefile standards. OSCx is not a straightforward build, so I haven't really messed with it at all. It would be nice if it worked on MinGW too.
also, i noticed after various -fPIC failures, it kept going. is it logging these somewhere?
This is a byproduct of calling another build system from the command line (i.e. cd blah/blah && make). It would work properly if it was part of the same Makefile.
(try four)
/bin/sh: /usr/src/pd/externals/../scripts/generate-libdir-metafile.sh: No such file or directory
fix: checkout "scripts" (see try one)
(try five)
more -fPIC stuff...only 'make clean' is not deleting .o files in the subprojects compiled without -fPIC, so i give up for now, to lazy to do some find . -iregex '.*.o' -exec rm {} ; ;)
Again a byproduct of using existing Makefiles. The stuff I have recently written all cleans up more or less properly after itself.
.c....sure, 6 thru 10 once we get these figured out, im happy to try again...
Please try again :)
.hc
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Dec 9, 2005, at 4:04 AM, geiger wrote:
HI,
I think it is not necessary to delete the files in the src/ folder. It seems to be a cosmetic change only.
From the point of view of the CVS, the nameclash problem should not exist, so its not a good argument for deleting these files.
If the nameclash problem really exists, I propose to delete that in the first place. (We already solved the prepend problem, didn't we ?)
Using a namespace solves it in a more complete way. Then people can write objects using the same name and they can all co-exist. Maybe one day, we can get to the point where using the same name for the same function in different libraries is actually encouraged, like it is in Java, for example.
The files in externals/build/src end up in the root of the namespace, so if there is an object with a name that is also used in a library, then you would not be able to access the libraries' versions using [import]/[using] object. Currently, [import]/[using] use the path, and since extra is first in the path, no matter what you add to the path, the object directly in extra would always be found first.
I could leave the files in place in externals/build/src and then just 'rm' the resulting binaries in externals/Makefile, but that seems to be a kludge. I would not delete anything that is not being built by another part of the Makefile, which now builds using the original source, no longer using the #include "../../cxc/prepend.c" links.
Although I think that "make" should be powerful enough to build the externals and Scons is not really needed, the thought of calling "make" from Scons seems to be everything else but a clean solution.
I just suggested that for those who want to use scons instead of maintaining a separate scons build system in parallel to the make system.
well, my humble opinion, but I do not want to interfere really, so at the end, personally, I don't care,
But your opinion here is important since you originally built the system in question and have a solid understanding of all the issues involved. Thanks for offering it.
.hc
Cheers,
Günter
On Fri, 9 Dec 2005, Hans-Christoph Steiner wrote:
First off, thanks for the bug report.
On Dec 7, 2005, at 11:11 PM, ix wrote:
...
as for the deleting, feel free since you created the files in the first place, but keep in mind it will break the completeness of the SCons option if you start removing files...i prefer SCons since it is also used for building devel and actually works for me (see below)
I am not aiming to break things, I am trying to build as much as possible. What is in externals/build/src is only part of what is in externals/. But I am fine with leaving the files in externals/build/src in place, the only ones that need to be removed are the ones with name clashes, like change, prepend, average, scale, etc. They prevent access to the objects of the same name using the namespace (they'd always be found first in the path).
But now there is something better.
ok... bug report then.. :)
(first try)
externals # make Makefile:24: /usr/src/pd/externals/../packages/Makefile.buildlayout: No such file or directory make: *** No rule to make target `/usr/src/pd/externals/../packages/Makefile.buildlayout'. Stop. :
fix: checkout "packages" - since this is a seperate module, perhaps the dep can be moved over since im guessing about 15% of users at most checkout "."..esp with all the weird stuff in it like framestein DLLs and PHP pages
If its a problem, a copy of Makefile.buildlayout can easily be added to the base of externals. I had it there originally, but then removed it since I was changing it a fair amount and it was a pain to keep them in sync. It could even have different values that packages/Makefile.buildlayout if that would helpful. When the other Makefiles are called from packages/Makefile, they are redirected to packages/Makefile anyhow.
This is the layout that I assume in building this: http://puredata.org/docs/developer/devlayout
(second try)
gcc -Wl,-export_dynamic -shared -o "/usr/src/pd/externals/../externals/cxc/ENV.pd_linux" "/usr/src/pd/externals/../externals/cxc/ENV.o" -lc -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../ x86_64-pc-linux-gnu/bin/ld: /usr/src/pd/externals/../externals/cxc/ENV.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/src/pd/externals/../externals/cxc/ENV.o: could not read symbols: Bad value collect2: ld returned 1 exit status
fix: add -fPIC to CFLAGS in /externals/makefile
Oops, -fPIC was there, but this exposed another bug. I wonder why it was compiling fine for me on Linux...
(third try)
it finished...ok. 'make install' wait...why is it configuring more stuff?!?!?! this should have been done in the make step.
I fixed these two problems. Its a work in progress. When you look into the structure of all the code in externals, you'll see that its is far from clean. There are a number of hacky workarounds in externals/Makefile for sure.
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../ x86_64-pc-linux-gnu/bin/ld: sendOSC.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC sendOSC.o: could not read symbols: Bad value collect2: ld returned 1 exit status
fix: uh.. i guess go around to all these other makefiles and add -fPIC since it didnt properly inherit the one in /externals/makefile. imo this is the biggest advantage to the SCons system where you have a parent environment, set the flags once, and you _know_ all the subprojects are going to get the same flags and binary/doc location, since they dont even have their own makefiles.
This is also possible and preferred with Makefiles, I tried to take advantage of this as much as possible in the work I just did. Its just that there are a lot of legacy Makefiles around, and many of them don't conform to the Makefile standards. OSCx is not a straightforward build, so I haven't really messed with it at all. It would be nice if it worked on MinGW too.
also, i noticed after various -fPIC failures, it kept going. is it logging these somewhere?
This is a byproduct of calling another build system from the command line (i.e. cd blah/blah && make). It would work properly if it was part of the same Makefile.
(try four)
/bin/sh: /usr/src/pd/externals/../scripts/generate-libdir-metafile.sh: No such file or directory
fix: checkout "scripts" (see try one)
(try five)
more -fPIC stuff...only 'make clean' is not deleting .o files in the subprojects compiled without -fPIC, so i give up for now, to lazy to do some find . -iregex '.*.o' -exec rm {} ; ;)
Again a byproduct of using existing Makefiles. The stuff I have recently written all cleans up more or less properly after itself.
.c....sure, 6 thru 10 once we get these figured out, im happy to try again...
Please try again :)
.hc
__ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
On Fri, 9 Dec 2005, Hans-Christoph Steiner wrote:
Using a namespace solves it in a more complete way. Then people can write objects using the same name and they can all co-exist.
But that is what should be avoided IMO. I do not see the usefulness of two implementations of, lets say prepend, counter or whatever.
Maybe one day, we can get to the point where using the same name for the same function in different libraries is actually encouraged, like it is in Java, for example.
Yeah but this is another thing. Most "libraries" in Pd world are not functional entities. They just happen to be written by the same author.
The files in externals/build/src end up in the root of the namespace, so if there is an object with a name that is also used in a library, then you would not be able to access the libraries' versions using [import]/[using] object. Currently, [import]/[using] use the path, and since extra is first in the path, no matter what you add to the path, the object directly in extra would always be found first.
this might depend heavily on the implementation of [import]/[using], and I actually think it should be the other way round. If you use import, everything with the same name gets overwritten. Which implementation are you talking about ? I thought there isn't any.
I could leave the files in place in externals/build/src and then just 'rm' the resulting binaries in externals/Makefile, but that seems to be a kludge.
I don't understand how the files in build/src can influence externals/Makefile. Which resulting binaries have to be removed ? There must be somekind of solution that doesn't destroy the SCons build system.
I would not delete anything that is not being built by another part of the Makefile, which now builds using the original source, no longer using the #include "../../cxc/prepend.c" links.
Although I think that "make" should be powerful enough to build the externals and Scons is not really needed, the thought of calling "make" from Scons seems to be everything else but a clean solution.
I just suggested that for those who want to use scons instead of maintaining a separate scons build system in parallel to the make system.
Who should want to do that ?
well, my humble opinion, but I do not want to interfere really, so at the end, personally, I don't care,
But your opinion here is important since you originally built the system in question and have a solid understanding of all the issues involved. Thanks for offering it.
Well, I think that the real issues we suffer are social, and I am far from understanding those. For the rest, I don't know more, I just ask myself what is it that it is so hard to build externals. And I fear that we have produced the complexity by ourselves.
Cheers, Günter
.hc
Cheers,
Günter
On Fri, 9 Dec 2005, Hans-Christoph Steiner wrote:
First off, thanks for the bug report.
On Dec 7, 2005, at 11:11 PM, ix wrote:
...
as for the deleting, feel free since you created the files in the first place, but keep in mind it will break the completeness of the SCons option if you start removing files...i prefer SCons since it is also used for building devel and actually works for me (see below)
I am not aiming to break things, I am trying to build as much as possible. What is in externals/build/src is only part of what is in externals/. But I am fine with leaving the files in externals/build/src in place, the only ones that need to be removed are the ones with name clashes, like change, prepend, average, scale, etc. They prevent access to the objects of the same name using the namespace (they'd always be found first in the path).
But now there is something better.
ok... bug report then.. :)
(first try)
externals # make Makefile:24: /usr/src/pd/externals/../packages/Makefile.buildlayout: No such file or directory make: *** No rule to make target `/usr/src/pd/externals/../packages/Makefile.buildlayout'. Stop. :
fix: checkout "packages" - since this is a seperate module, perhaps the dep can be moved over since im guessing about 15% of users at most checkout "."..esp with all the weird stuff in it like framestein DLLs and PHP pages
If its a problem, a copy of Makefile.buildlayout can easily be added to the base of externals. I had it there originally, but then removed it since I was changing it a fair amount and it was a pain to keep them in sync. It could even have different values that packages/Makefile.buildlayout if that would helpful. When the other Makefiles are called from packages/Makefile, they are redirected to packages/Makefile anyhow.
This is the layout that I assume in building this: http://puredata.org/docs/developer/devlayout
(second try)
gcc -Wl,-export_dynamic -shared -o "/usr/src/pd/externals/../externals/cxc/ENV.pd_linux" "/usr/src/pd/externals/../externals/cxc/ENV.o" -lc -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../ x86_64-pc-linux-gnu/bin/ld: /usr/src/pd/externals/../externals/cxc/ENV.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/src/pd/externals/../externals/cxc/ENV.o: could not read symbols: Bad value collect2: ld returned 1 exit status
fix: add -fPIC to CFLAGS in /externals/makefile
Oops, -fPIC was there, but this exposed another bug. I wonder why it was compiling fine for me on Linux...
(third try)
it finished...ok. 'make install' wait...why is it configuring more stuff?!?!?! this should have been done in the make step.
I fixed these two problems. Its a work in progress. When you look into the structure of all the code in externals, you'll see that its is far from clean. There are a number of hacky workarounds in externals/Makefile for sure.
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../ x86_64-pc-linux-gnu/bin/ld: sendOSC.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC sendOSC.o: could not read symbols: Bad value collect2: ld returned 1 exit status
fix: uh.. i guess go around to all these other makefiles and add -fPIC since it didnt properly inherit the one in /externals/makefile. imo this is the biggest advantage to the SCons system where you have a parent environment, set the flags once, and you _know_ all the subprojects are going to get the same flags and binary/doc location, since they dont even have their own makefiles.
This is also possible and preferred with Makefiles, I tried to take advantage of this as much as possible in the work I just did. Its just that there are a lot of legacy Makefiles around, and many of them don't conform to the Makefile standards. OSCx is not a straightforward build, so I haven't really messed with it at all. It would be nice if it worked on MinGW too.
also, i noticed after various -fPIC failures, it kept going. is it logging these somewhere?
This is a byproduct of calling another build system from the command line (i.e. cd blah/blah && make). It would work properly if it was part of the same Makefile.
(try four)
/bin/sh: /usr/src/pd/externals/../scripts/generate-libdir-metafile.sh: No such file or directory
fix: checkout "scripts" (see try one)
(try five)
more -fPIC stuff...only 'make clean' is not deleting .o files in the subprojects compiled without -fPIC, so i give up for now, to lazy to do some find . -iregex '.*.o' -exec rm {} ; ;)
Again a byproduct of using existing Makefiles. The stuff I have recently written all cleans up more or less properly after itself.
.c....sure, 6 thru 10 once we get these figured out, im happy to try again...
Please try again :)
.hc
__ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
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
Hallo, geiger hat gesagt: // geiger wrote:
Well, I think that the real issues we suffer are social, and I am far from understanding those. For the rest, I don't know more, I just ask myself what is it that it is so hard to build externals. And I fear that we have produced the complexity by ourselves.
That's a very valid point worth to discuss somehow outside the technical realization of how to build stuff and also only limited to non-library-using, C externals. I'll call these "plain externals" now, so flext, oggamp etc. are left out. Currently these are all in the author's directories, because we were all too frightened to put all our valued stuff together into one big repository.
However the best solution would be, if every plain external in every authors subdirectory would be removed there and moved to a central directory with a central Makefile (or SConstruct, if that was chosen).
You first "build" solution was somehow doing exactly this, without actually moving stuff, just by including the files. Maybe it would be time to *actually move* all plain externals into one single, unified directory? Like a big cleanup. The directory should not be called "build" as this is not really an issue about building, maybe it could be called "base-ext" or something like that, to make it clear, that this is the common ground of the whole developer community.
This would be the place for all plain base externals by all authors. It would require, that some externals get removed in their current libraries and moved over to live as single externals in "base-ext" too. Hans' installer then still would be very useful to "catch the rest" of the externals: library-externals like oggplay, flext, Cyclone in Max-compat mode etc. For the base externals he would just call "make" in "base-ext"
One problem with this of course is: How to avoid conflicts when submitting stuff. Should there be a "base-ext" maintainer? The advantage would be, that the externals could get a real common release cycle. Nameclashes with base-exts wouldn't occur anymore. (Every external in a subdirectory, which clashes, would be hijacked and removed by orks.) We could use a namespace like "base" for these externals, and as default "base" would be available without namespace.
Or am I just dreaming?
On Dec 9, 2005, at 12:15 PM, Frank Barknecht wrote:
Hallo, geiger hat gesagt: // geiger wrote:
Well, I think that the real issues we suffer are social, and I am far from understanding those. For the rest, I don't know more, I just ask myself what is it that it is so hard to build externals. And I fear that we have produced the complexity by ourselves.
That's a very valid point worth to discuss somehow outside the technical realization of how to build stuff and also only limited to non-library-using, C externals. I'll call these "plain externals" now, so flext, oggamp etc. are left out. Currently these are all in the author's directories, because we were all too frightened to put all our valued stuff together into one big repository.
However the best solution would be, if every plain external in every authors subdirectory would be removed there and moved to a central directory with a central Makefile (or SConstruct, if that was chosen).
You first "build" solution was somehow doing exactly this, without actually moving stuff, just by including the files. Maybe it would be time to *actually move* all plain externals into one single, unified directory? Like a big cleanup. The directory should not be called "build" as this is not really an issue about building, maybe it could be called "base-ext" or something like that, to make it clear, that this is the common ground of the whole developer community.
This would be the place for all plain base externals by all authors. It would require, that some externals get removed in their current libraries and moved over to live as single externals in "base-ext" too. Hans' installer then still would be very useful to "catch the rest" of the externals: library-externals like oggplay, flext, Cyclone in Max-compat mode etc. For the base externals he would just call "make" in "base-ext"
One problem with this of course is: How to avoid conflicts when submitting stuff. Should there be a "base-ext" maintainer? The advantage would be, that the externals could get a real common release cycle. Nameclashes with base-exts wouldn't occur anymore. (Every external in a subdirectory, which clashes, would be hijacked and removed by orks.) We could use a namespace like "base" for these externals, and as default "base" would be available without namespace.
I disagree about one big directory, I think that would actually make things more difficult. I think that ideally, all of the code would be organized into libraries/directories with related functionality ("networking", "pan", "synths", etc). Currently, its organized around authors' build systems. But when we use a common build system, then this doesn't need to happen anymore.
externals/Makefile already builds most of the externals files in place, in the authors' directories, and the one Makefile does it for Windows, Mac OS X, and GNU/Linux, no need for separate Makefiles (largely thanks to MinGW). Plus it can (and does) build objects with dependencies (ogg, vorbis, lame, speex, etc.). It should be able to build basically any Pd object written in C without too much hassle. The flext/C++ and Gem stuff currently is separate.
I agree with Thomas Grill in that Pd itself should include just a bare minimum of functionality, stripped down to a Pd kernel of sorts. Pd should be like C or Java, with a small base language, and everything else in libraries, like libc or java.lang.*. Therefore, I think there should be no "base" set of objects.
But it would be good to reorganize things into libraries that cover certain functionality, like I/O or networking or atom conversion. Then we could use externals/build/src-style .c link files to maintain backward compatibility with the old library organization.
.hc
________________________________________________________________________ ____
"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
On Dec 9, 2005, at 11:06 AM, geiger wrote:
On Fri, 9 Dec 2005, Hans-Christoph Steiner wrote:
Using a namespace solves it in a more complete way. Then people can write objects using the same name and they can all co-exist.
But that is what should be avoided IMO. I do not see the usefulness of two implementations of, lets say prepend, counter or whatever.
I agree that this should be avoided. For example, in Java, which I am using as my namespace example, when they made javax.swing to replace java.awt, the objects that did the same thing were named differently (java.awt.MenuItem --> javax.swing.JMenuItem) even though both could have been called MenuItem and it would have worked. Its clearer to have the objects with different yet related names.
But having a namespace means that when people do make objects of the same name, its much easier to deal with. We have inherited multiple prepends, counters, scales, averages, etc. and people prefer different ones. Its not a good design, but its workable with the namespace.
Maybe one day, we can get to the point where using the same name for the same function in different libraries is actually encouraged, like it is in Java, for example.
Yeah but this is another thing. Most "libraries" in Pd world are not functional entities. They just happen to be written by the same author.
I also think that we should start to push to organize libraries along the lines of functionality rather than author. Then it might make sense, differing from Java, to have objects of the same name in different libs, for example:
[pd/send] [pd/receive] [net/send] [net/receive] [osc/send] [osc/receive]
Then if you have a library, and you want want to use its method of sending and receiving, the object name would be obvious. But this would have the disadvantage of becoming unclear when someone does this:
[import net]
| | [receive foo] [send foo] | |
Then it could be unclear which kind of send/receive is being used. I am undecided about this idea.
The files in externals/build/src end up in the root of the namespace, so if there is an object with a name that is also used in a library, then you would not be able to access the libraries' versions using [import]/[using] object. Currently, [import]/[using] use the path, and since extra is first in the path, no matter what you add to the path, the object directly in extra would always be found first.
this might depend heavily on the implementation of [import]/[using], and I actually think it should be the other way round. If you use import, everything with the same name gets overwritten. Which implementation are you talking about ? I thought there isn't any.
I whipped out a version I called [import] which just takes the library names as arguments and loads them using sys_load_lib() and sys_load_lib_dir(). Its in the extended-RC6 builds. I am guessing your [using] was something like that.
I could leave the files in place in externals/build/src and then just 'rm' the resulting binaries in externals/Makefile, but that seems to be a kludge.
I don't understand how the files in build/src can influence externals/Makefile. Which resulting binaries have to be removed ?
I.e. [prepend]. If there is a [prepend] in "extra", "extra" is first in the path, so that [prepend] will always be opened regardless of the path. That makes it impossible to use the other [prepend]s in separate directories without prepending the directory/library name. So even if I did [import cxc] then [prepend], I would still get the [prepend] in "extra" rather than the one in "extra/cxc".
The [prepend] in "externals/build/src" is the old cyclone one anyway, and the new cyclone one does not compile when dropped into "externals/build/src". The new cyclone one is compatible both with the Max [prepend] and the IEM [prepend].
There must be somekind of solution that doesn't destroy the SCons build system.
I still think having two build systems is a lot of extra work and hassle for zero gain. How many build systems does the linux kernel have? Firefox? Ardour? Audacity? Or Max/MSP for that matter.
Yes, make is whacky and old, but it works and everybody knows the basics of make. Its great that people are experimenting with scons. But I am not interested in experimenting with build systems, I want to experiment with Pd. Someday it might make sense to replace all of the make stuff with some other solution, but until that is proven, I really think we should all agree on one build system and combine efforts so all of us can spend less time on build systems, and more on making Pd better.
I would not delete anything that is not being built by another part of the Makefile, which now builds using the original source, no longer using the #include "../../cxc/prepend.c" links.
Although I think that "make" should be powerful enough to build the externals and Scons is not really needed, the thought of calling "make" from Scons seems to be everything else but a clean solution.
I just suggested that for those who want to use scons instead of maintaining a separate scons build system in parallel to the make system.
Who should want to do that ?
well, my humble opinion, but I do not want to interfere really, so at the end, personally, I don't care,
But your opinion here is important since you originally built the system in question and have a solid understanding of all the issues involved. Thanks for offering it.
Well, I think that the real issues we suffer are social, and I am far from understanding those. For the rest, I don't know more, I just ask myself what is it that it is so hard to build externals. And I fear that we have produced the complexity by ourselves.
I do agree those are issues, but if we can build a system that thrives despite our lack of agreement on those issues, we'll all be better off.
.hc
Cheers, Günter
.hc
Cheers,
Günter
On Fri, 9 Dec 2005, Hans-Christoph Steiner wrote:
First off, thanks for the bug report.
On Dec 7, 2005, at 11:11 PM, ix wrote:
...
as for the deleting, feel free since you created the files in the first place, but keep in mind it will break the completeness of the SCons option if you start removing files...i prefer SCons since it is also used for building devel and actually works for me (see below)
I am not aiming to break things, I am trying to build as much as possible. What is in externals/build/src is only part of what is in externals/. But I am fine with leaving the files in externals/build/src in place, the only ones that need to be removed are the ones with name clashes, like change, prepend, average, scale, etc. They prevent access to the objects of the same name using the namespace (they'd always be found first in the path).
But now there is something better.
ok... bug report then.. :)
(first try)
externals # make Makefile:24: /usr/src/pd/externals/../packages/Makefile.buildlayout: No such file or directory make: *** No rule to make target `/usr/src/pd/externals/../packages/Makefile.buildlayout'. Stop. :
fix: checkout "packages" - since this is a seperate module, perhaps the dep can be moved over since im guessing about 15% of users at most checkout "."..esp with all the weird stuff in it like framestein DLLs and PHP pages
If its a problem, a copy of Makefile.buildlayout can easily be added to the base of externals. I had it there originally, but then removed it since I was changing it a fair amount and it was a pain to keep them in sync. It could even have different values that packages/Makefile.buildlayout if that would helpful. When the other Makefiles are called from packages/Makefile, they are redirected to packages/Makefile anyhow.
This is the layout that I assume in building this: http://puredata.org/docs/developer/devlayout
(second try)
gcc -Wl,-export_dynamic -shared -o "/usr/src/pd/externals/../externals/cxc/ENV.pd_linux" "/usr/src/pd/externals/../externals/cxc/ENV.o" -lc -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../ x86_64-pc-linux-gnu/bin/ld: /usr/src/pd/externals/../externals/cxc/ENV.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/src/pd/externals/../externals/cxc/ENV.o: could not read symbols: Bad value collect2: ld returned 1 exit status
fix: add -fPIC to CFLAGS in /externals/makefile
Oops, -fPIC was there, but this exposed another bug. I wonder why it was compiling fine for me on Linux...
(third try)
it finished...ok. 'make install' wait...why is it configuring more stuff?!?!?! this should have been done in the make step.
I fixed these two problems. Its a work in progress. When you look into the structure of all the code in externals, you'll see that its is far from clean. There are a number of hacky workarounds in externals/Makefile for sure.
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../ x86_64-pc-linux-gnu/bin/ld: sendOSC.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC sendOSC.o: could not read symbols: Bad value collect2: ld returned 1 exit status
fix: uh.. i guess go around to all these other makefiles and add -fPIC since it didnt properly inherit the one in /externals/makefile. imo this is the biggest advantage to the SCons system where you have a parent environment, set the flags once, and you _know_ all the subprojects are going to get the same flags and binary/doc location, since they dont even have their own makefiles.
This is also possible and preferred with Makefiles, I tried to take advantage of this as much as possible in the work I just did. Its just that there are a lot of legacy Makefiles around, and many of them don't conform to the Makefile standards. OSCx is not a straightforward build, so I haven't really messed with it at all. It would be nice if it worked on MinGW too.
also, i noticed after various -fPIC failures, it kept going. is it logging these somewhere?
This is a byproduct of calling another build system from the command line (i.e. cd blah/blah && make). It would work properly if it was part of the same Makefile.
(try four)
/bin/sh: /usr/src/pd/externals/../scripts/generate-libdir-metafile.sh: No such file or directory
fix: checkout "scripts" (see try one)
(try five)
more -fPIC stuff...only 'make clean' is not deleting .o files in the subprojects compiled without -fPIC, so i give up for now, to lazy to do some find . -iregex '.*.o' -exec rm {} ; ;)
Again a byproduct of using existing Makefiles. The stuff I have recently written all cleans up more or less properly after itself.
.c....sure, 6 thru 10 once we get these figured out, im happy to try again...
Please try again :)
.hc
__ __ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
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
________________________________________________________________________ ____
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
On Mon, 12 Dec 2005, Hans-Christoph Steiner wrote:
I agree that this should be avoided. For example, in Java, which I am using as my namespace example, when they made javax.swing to replace java.awt, the objects that did the same thing were named differently (java.awt.MenuItem --> javax.swing.JMenuItem) even though both could have been called MenuItem and it would have worked. Its clearer to have the objects with different yet related names.
What happened there? is it that typically people need to import both java.awt and javax.swing in order to do anything with SWING ? In that case it's almost as if they were in the same namespace. However, I figure writing "javax.swing.MenuItem" is as clear to Java programmers, and I can't imagine them trying to come up with shorter identifiers.
What's the psychology behind "J"-prefixing in Java? Really?
Yeah but this is another thing. Most "libraries" in Pd world are not functional entities. They just happen to be written by the same author.
Even libraries that are assumed to have some kind of functional unity normally don't. A lot of C libraries reinvent OOP, dynamic typing, etc.; in Java those features are built-in, but that just moves the phenomenon at another level, though usually to a lesser extent.
Then if you have a library, and you want want to use its method of sending and receiving, the object name would be obvious. But this would have the disadvantage of becoming unclear when someone does this: [import net] | [receive foo] [send foo] |
Without [import net] those would refer to the usual [send] and [receive] that we also know as [s] and [r]. Questions:
1. What would be the way to use a toplevel name like "send", overriding an import directive? [/send] (leading slash) ?
2. Would it be a good idea to have aliases propagate across namespaces, such that [s] in this case would refer to [netsend] ? And then would it be feasible?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Mon, 12 Dec 2005, Hans-Christoph Steiner wrote:
Then if you have a library, and you want want to use its method of sending and receiving, the object name would be obvious. But this would have the disadvantage of becoming unclear when someone does this: [import net] | [receive foo] [send foo] |
Without [import net] those would refer to the usual [send] and [receive] that we also know as [s] and [r].
One further problem here is, that in Pd, which is a graphical language, it is easier to overlook the [import net] object depending on where it is placed (and who placed it).
Ciao
Frank Barknecht wrote:
One further problem here is, that in Pd, which is a graphical language, it is easier to overlook the [import net] object depending on where it is placed (and who placed it).
this is a good point. the [import] needs to be treated in a special way anyhow, since it should be enforced to be "executed" before anything else in the patch (else it would make the patch totally obfuscated, and we would lose more than we gain)
this makes me think of putting "import" into the patch meta-information (like position, size, font,...); probably a "status-field" of the patch would be a good thing to have (directly below the menu)
just thinking aloud
mf.asdr. IOhannes
On Dec 12, 2005, at 6:38 AM, IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
One further problem here is, that in Pd, which is a graphical language, it is easier to overlook the [import net] object depending on where it is placed (and who placed it).
this is a good point. the [import] needs to be treated in a special way anyhow, since it should be enforced to be "executed" before anything else in the patch (else it would make the patch totally obfuscated, and we would lose more than we gain)
this makes me think of putting "import" into the patch meta-information (like position, size, font,...); probably a "status-field" of the patch would be a good thing to have (directly below the menu)
just thinking aloud
That does make sense. But [import] was just so quick and easy ;). The only downside of having the imports in the properties/meta that I can see is that what is being imported is much less obvious.
.hc
________________________________________________________________________ ____
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
Hans-Christoph Steiner wrote:
this makes me think of putting "import" into the patch meta-information (like position, size, font,...); probably a "status-field" of the patch would be a good thing to have (directly below the menu)
just thinking aloud
That does make sense. But [import] was just so quick and easy ;). The only downside of having the imports in the properties/meta that I can see is that what is being imported is much less obvious.
yes of course it is not enough to right click on a patch and define whatever you want to import. i was thinking of a visible field below the menu-bar that could be used for such patch specific things. (at least to display things like the imports,...)
but of course there are already objects in pd that affect the whole patch and can be hidden anywhere, like [block~]
mfg.asdr. IOhannes
On Mon, 12 Dec 2005, Frank Barknecht wrote:
One further problem here is, that in Pd, which is a graphical language, it is easier to overlook the [import net] object depending on where it is placed (and who placed it).
What happens when the [import net] object is created after [send] and/or [receive] get created? And then what happens if you save the file and reload it?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
One further problem here is, that in Pd, which is a graphical language, it is easier to overlook the [import net] object depending on where it is placed (and who placed it).
What happens when the [import net] object is created after [send] and/or [receive] get created? And then what happens if you save the file and reload it?
that's the reason, why an |import| object can't be implemented this way ... the only clean way would be a property of the canvas ...
t
Tim Blechmann wrote: ...
What happens when the [import net] object is created after [send] and/or [receive] get created? And then what happens if you save the file and reload it?
that's the reason, why an |import| object can't be implemented this
that is also the reason why I proposed a two-pass patch saving mechanism (or a two-point glist insertion mechanism as another option). That was according to the general rule: the less Pd logic depends on dialogs, the better. There are exceptions, of course, and this might be one of them? not sure.
Btw, I think that overloading 'send' and 'receive' is a very bad idea.
Krzysztof
On Dec 12, 2005, at 4:46 PM, Krzysztof Czaja wrote:
Tim Blechmann wrote: ...
What happens when the [import net] object is created after [send] and/or [receive] get created? And then what happens if you save the file and reload it?
that's the reason, why an |import| object can't be implemented this
that is also the reason why I proposed a two-pass patch saving mechanism (or a two-point glist insertion mechanism as another option). That was according to the general rule: the less Pd logic depends on dialogs, the better. There are exceptions, of course, and this might be one of them? not sure.
Yeah, I do like the purity of having all of the logic in the patch and not obscured. This file saving does sound intriguing indeed.
Btw, I think that overloading 'send' and 'receive' is a very bad idea.
I am still undecided, I'd like to hear why you think its a bad idea.
.hc
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
On Mon, 12 Dec 2005, Tim Blechmann wrote:
What happens when the [import net] object is created after [send] and/or [receive] get created? And then what happens if you save the file and reload it?
that's the reason, why an |import| object can't be implemented this way ... the only clean way would be a property of the canvas ...
Explain to me how making it a property of the canvas would fix anything at all.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 13, 2005, at 6:43 AM, Mathieu Bouchard wrote:
On Mon, 12 Dec 2005, Tim Blechmann wrote:
What happens when the [import net] object is created after [send] and/or [receive] get created? And then what happens if you save the file and reload it?
that's the reason, why an |import| object can't be implemented this way ... the only clean way would be a property of the canvas ...
Explain to me how making it a property of the canvas would fix anything at all.
It would ensure that it gets read first from the file.
.hc ________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
On Tue, 13 Dec 2005, Hans-Christoph Steiner wrote:
Explain to me how making it a property of the canvas would fix anything at all.
It would ensure that it gets read first from the file.
automatic resolving of namespaces (like import does) is only useful if it is done in a limited scope, like per patch.
The problem with the "using" or "import" external furthermore is that it pulls in a namespace at arbitrary time when loading the patch, this is not very predictable, and setting the path from the beginning would be a better solution in this case.
I have the feeling that implementing "import" correctly is not trivial.
Günter
.hc ________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I have the feeling that implementing "import" correctly is not trivial.
that's the reason, why this feature will never be implemented in pd :-(
t
On Tue, 13 Dec 2005, Hans-Christoph Steiner wrote:
On Dec 13, 2005, at 6:43 AM, Mathieu Bouchard wrote:
Explain to me how making it a property of the canvas would fix anything at all.
It would ensure that it gets read first from the file.
Yeah, but what i meant to ask is: happens with objects that are created in that canvas _before_ the import property got changed in the canvas?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 12, 2005, at 4:56 AM, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Mon, 12 Dec 2005, Hans-Christoph Steiner wrote:
Then if you have a library, and you want want to use its method of sending and receiving, the object name would be obvious. But this would have the disadvantage of becoming unclear when someone does this: [import net] | [receive foo] [send foo] |
Without [import net] those would refer to the usual [send] and [receive] that we also know as [s] and [r].
One further problem here is, that in Pd, which is a graphical language, it is easier to overlook the [import net] object depending on where it is placed (and who placed it).
True. I wonder if its harder than in a text language tho. You could bury your import statements into the code, but Java convention says to put them on the top. A Pd convention to put your [import]s in the upper right could work similarly well.
.hc
________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it." - Thomas Jefferson
On Dec 12, 2005, at 1:41 AM, Mathieu Bouchard wrote:
On Mon, 12 Dec 2005, Hans-Christoph Steiner wrote:
I agree that this should be avoided. For example, in Java, which I am using as my namespace example, when they made javax.swing to replace java.awt, the objects that did the same thing were named differently (java.awt.MenuItem --> javax.swing.JMenuItem) even though both could have been called MenuItem and it would have worked. Its clearer to have the objects with different yet related names.
What happened there? is it that typically people need to import both java.awt and javax.swing in order to do anything with SWING ? In that case it's almost as if they were in the same namespace. However, I figure writing "javax.swing.MenuItem" is as clear to Java programmers, and I can't imagine them trying to come up with shorter identifiers.
AWT and Swing are generally not used together, but can be in a kludgey way.
What's the psychology behind "J"-prefixing in Java? Really?
Yeah but this is another thing. Most "libraries" in Pd world are not functional entities. They just happen to be written by the same author.
Even libraries that are assumed to have some kind of functional unity normally don't. A lot of C libraries reinvent OOP, dynamic typing, etc.; in Java those features are built-in, but that just moves the phenomenon at another level, though usually to a lesser extent.
Then if you have a library, and you want want to use its method of sending and receiving, the object name would be obvious. But this would have the disadvantage of becoming unclear when someone does this: [import net] | [receive foo] [send foo] |
Without [import net] those would refer to the usual [send] and [receive] that we also know as [s] and [r]. Questions:
- What would be the way to use a toplevel name like "send",
overriding an import directive? [/send] (leading slash) ?
Like Java, C, etc., only the bare minimum would be in the "toplevel". So send/receive would be like [pd/send] or [pd/receive] or maybe [core/send], or whatever.
- Would it be a good idea to have aliases propagate across namespaces, such that [s] in this case would refer to [netsend] ? And then
would it be feasible?
Personally, I am not a fan of abbreviations, I think they are messy and provide basically no real benefit. Most programming languages just have one name per function, not a bunch of aliases too.
.hc ________________________________________________________________________ ____
"I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits." - Martin Luther King, Jr.
On Tue, 13 Dec 2005, Hans-Christoph Steiner wrote:
Like Java, C, etc., only the bare minimum would be in the "toplevel". So send/receive would be like [pd/send] or [pd/receive] or maybe [core/send], or whatever.
What do you mean "etc." ? Most other languages I know that have namespaces use the toplevel namespace to hold the core of the language.
Personally, I am not a fan of abbreviations, I think they are messy and provide basically no real benefit.
"may all your [t a a] be replaced by [trigger anything anything]" is an ancient chinese curse.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 13, 2005, at 4:08 AM, Mathieu Bouchard wrote:
On Tue, 13 Dec 2005, Hans-Christoph Steiner wrote:
Like Java, C, etc., only the bare minimum would be in the "toplevel". So send/receive would be like [pd/send] or [pd/receive] or maybe [core/send], or whatever.
What do you mean "etc." ? Most other languages I know that have namespaces use the toplevel namespace to hold the core of the language.
I'd like to see what kind of program you could write without any #includes in C, or without any imports in Java. Not a whole lot. Java, for example, has nothing in the toplevel namespace, even Object is in java.lang.Object.
Personally, I am not a fan of abbreviations, I think they are messy and provide basically no real benefit.
"may all your [t a a] be replaced by [trigger anything anything]" is an ancient chinese curse.
I already often do using [trigger anything anything], it would be a minor change.
.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