There is still some work to be done before those can be shed because some of those externals in their original non-aliased format use inconsistent naming schemes. Namely some of them use abbreviated format like a2l (or whatever its name is I cannot remember off top of my head) while others use full name. So I guess what I'm saying is that community needs to decide whether to keep the long or short versions of those objects and convert the ones that arent accordingly. Until that happens I think aliases will have to stay.
Mathieu Bouchard matju@artengine.ca wrote:
On Wed, 15 Dec 2010, Ivica Ico Bukvic wrote:
Ok, so I made a list of flatspace objects missing and I keep wondering if it would not be better to simply do away with all these aliases and start anew thus encouraging all potential users of pd-l2ork to shed their redundant aliases in their patches. Sure, it is a few more chars to type but is that really such a big deal? What do others think here, particularly Hans since he made the call to get rid of flatspace in the first place? Hans?
That's exactly what hcs wants you to do. The missing aliases are not a simple oversight : you can find plenty of mails by him basically saying that aliases are a bad idea.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Wed, 15 Dec 2010, Ivica Ico Bukvic wrote:
So I guess what I'm saying is that community needs to decide whether to keep the long or short versions of those objects and convert the ones that arent accordingly.
Ah, but who is the community, exactly ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Thu, 12/16/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] L2Ork Pd update now available To: "Ivica Ico Bukvic" ico@vt.edu Cc: "Jonathan Wilkes" jancsika@yahoo.com, pd-list@iem.at Date: Thursday, December 16, 2010, 12:17 AM On Wed, 15 Dec 2010, Ivica Ico Bukvic wrote:
So I guess what I'm saying is that community needs to
decide whether to keep the long or short versions of those objects and convert the ones that arent accordingly.
Ah, but who is the community, exactly ?
I can tell you with 100% certainty that the community wants to keep whichever version they are currently using in their patches.
In other words, 100% of the community wants their patches to work, which very likely means you have to keep both long and short versions.
Btw-- other libraries have aliases, like iemlib which has its own workaround "alias" folder. Not sure about the other libraries, though.
-Jonathan
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Hi Ivica, This may just be leftovers from a previous install: When I run pd by typing in '/usr/local/bin/pd-l2ork' it works fine.
When I run it by typing pd-l2ork, I get:
sh: /usr/bin/pd-gui: not found
And it just waits there until I hit <ctrl-c>.
Any hints?
-Jonathan
On Wed, 2010-12-15 at 17:15 -0800, Jonathan Wilkes wrote:
Hi Ivica, This may just be leftovers from a previous install: When I run pd by typing in '/usr/local/bin/pd-l2ork' it works fine.
When I run it by typing pd-l2ork, I get:
sh: /usr/bin/pd-gui: not found
And it just waits there until I hit <ctrl-c>.
Any hints?
-Jonathan
Not sure. The installer is identical to pd-extended (except for renamed binaries), so I've not decided to mess with that. It may be because installer installs into /usr/local instead of /usr/bin but I actually have no idea. I am simply using it with a prefix. Hans?
On Wed, 2010-12-15 at 17:15 -0800, Jonathan Wilkes wrote:
Hi Ivica, This may just be leftovers from a previous install: When I run pd by typing in '/usr/local/bin/pd-l2ork' it works fine.
When I run it by typing pd-l2ork, I get:
sh: /usr/bin/pd-gui: not found
And it just waits there until I hit <ctrl-c>.
Any hints?
-Jonathan
I did some digging on this and found a fix for it. Apparently my s_main.c changes were for whatever reason not registered by the make and thus skipped. Once I retouched s_main.c thing now builds as expected with pd-l2ork binary working globally.
I will be uploading the new version later today.
Many thanks for the report!
Best wishes,
Ico
On Wed, 2010-12-15 at 17:15 -0800, Jonathan Wilkes wrote:
Hi Ivica, This may just be leftovers from a previous install: When I run pd by typing in '/usr/local/bin/pd-l2ork' it works fine.
When I run it by typing pd-l2ork, I get:
sh: /usr/bin/pd-gui: not found
And it just waits there until I hit <ctrl-c>.
Any hints?
-Jonathan
Actually, it seems that the default installer in packages/linux_make/ folder fails to produce sane binary when building a tarbz2 rather than a deb. First of all it keeps running dpkg-shlibdeps even when running make tarbz2 as it has an if statement that changes it to deb (if deb package is present) and then it assumes that binary should be built in /usr/bin directory rather than in /usr/local/bin.
Hans, shouldn't the following code be under the package: part? Otherwise it overrides tarbz2 settings if one has dpkg-deb installed regardless of what the user has input and results in erroneous build, no?
# if machine has dpkg-deb, build a Debian package ifeq ($(shell test -x /usr/bin/dpkg-deb && echo YES),YES) PACKAGE_TYPE = deb else PACKAGE_TYPE = tarbz2 endif
On Thu, 2010-12-16 at 19:12 -0500, Ivica Ico Bukvic wrote:
On Wed, 2010-12-15 at 17:15 -0800, Jonathan Wilkes wrote:
Hi Ivica, This may just be leftovers from a previous install: When I run pd by typing in '/usr/local/bin/pd-l2ork' it works fine.
When I run it by typing pd-l2ork, I get:
sh: /usr/bin/pd-gui: not found
And it just waits there until I hit <ctrl-c>.
Any hints?
-Jonathan
Actually, it seems that the default installer in packages/linux_make/ folder fails to produce sane binary when building a tarbz2 rather than a deb. First of all it keeps running dpkg-shlibdeps even when running make tarbz2 as it has an if statement that changes it to deb (if deb package is present) and then it assumes that binary should be built in /usr/bin directory rather than in /usr/local/bin.
Hans, shouldn't the following code be under the package: part? Otherwise it overrides tarbz2 settings if one has dpkg-deb installed regardless of what the user has input and results in erroneous build, no?
# if machine has dpkg-deb, build a Debian package ifeq ($(shell test -x /usr/bin/dpkg-deb && echo YES),YES) PACKAGE_TYPE = deb else PACKAGE_TYPE = tarbz2 endif
Actually, moving this does not work under package: heading due to the way makefile structure works. That said, I think it is broken and it should simply go away together with package: heading as it is not documented nor does it provide anything useful that "make tarbz2" or "make deb" already don't do. On top of that it breaks the build process. This way even doing a simple "make test_locations" takes forever until the whole thing goes through the shlibdeps mess. OTOH I am not sure how to then force generation of dependencies which depends upon PACKAGE_TYPE variable. Any ideas?
On Dec 16, 2010, at 4:11 PM, Ivica Ico Bukvic wrote:
On Wed, 2010-12-15 at 17:15 -0800, Jonathan Wilkes wrote:
Hi Ivica, This may just be leftovers from a previous install: When I run pd by typing in '/usr/local/bin/pd-l2ork' it works fine.
When I run it by typing pd-l2ork, I get:
sh: /usr/bin/pd-gui: not found
And it just waits there until I hit <ctrl-c>.
Any hints?
-Jonathan
Actually, it seems that the default installer in packages/linux_make/ folder fails to produce sane binary when building a tarbz2 rather
than a deb. First of all it keeps running dpkg-shlibdeps even when running
make tarbz2 as it has an if statement that changes it to deb (if deb
package is present) and then it assumes that binary should be built in /usr/ bin directory rather than in /usr/local/bin.Hans, shouldn't the following code be under the package: part?
Otherwise it overrides tarbz2 settings if one has dpkg-deb installed
regardless of what the user has input and results in erroneous build, no?# if machine has dpkg-deb, build a Debian package ifeq ($(shell test -x /usr/bin/dpkg-deb && echo YES),YES) PACKAGE_TYPE = deb else PACKAGE_TYPE = tarbz2 endif
I recently committed some fixes to the packages/linux_make/Makefile to
fix this. Have you tried the newest version?
.hc
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
FWIW, please see attached Makefile changes that fix:
*uninstall not removing files with $ in their names *default.pdsettings is not included in the installer/uninstaller by the generate_install_makefile because it is copied over after generate script is run *the fact that every make tarbz2 is forcefully changed into make deb
This also means that when issuing make deb, it needs to be followed with a PACKAGE_TYPE=deb. (I am sure there is a better way but I just haven't had a chance to dig any further).
NB: patch uses default.pdl2ork extension so that will have to be changed.
Cheers!
On Fri, 2010-12-17 at 09:14 -0800, Hans-Christoph Steiner wrote:
On Dec 16, 2010, at 4:11 PM, Ivica Ico Bukvic wrote:
On Wed, 2010-12-15 at 17:15 -0800, Jonathan Wilkes wrote:
Hi Ivica, This may just be leftovers from a previous install: When I run pd by typing in '/usr/local/bin/pd-l2ork' it works fine.
When I run it by typing pd-l2ork, I get:
sh: /usr/bin/pd-gui: not found
And it just waits there until I hit <ctrl-c>.
Any hints?
-Jonathan
Actually, it seems that the default installer in packages/linux_make/ folder fails to produce sane binary when building a tarbz2 rather
than a deb. First of all it keeps running dpkg-shlibdeps even when running
make tarbz2 as it has an if statement that changes it to deb (if deb
package is present) and then it assumes that binary should be built in /usr/ bin directory rather than in /usr/local/bin.Hans, shouldn't the following code be under the package: part?
Otherwise it overrides tarbz2 settings if one has dpkg-deb installed
regardless of what the user has input and results in erroneous build, no?# if machine has dpkg-deb, build a Debian package ifeq ($(shell test -x /usr/bin/dpkg-deb && echo YES),YES) PACKAGE_TYPE = deb else PACKAGE_TYPE = tarbz2 endif
I recently committed some fixes to the packages/linux_make/Makefile to
fix this. Have you tried the newest version?.hc
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie