Hey all,
I've been fixing quite a lot of bugs in preparation of making the Pd-
extended 0.40.3 release. It's getting pretty much ready, so please
test it heavily so we can find any outstanding bugs!
Jack just pointed out that pdp on Mac OS X/PowerPC is having problems
loading videos, and is crashing, so I am working on that now.
.hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
I just tried installing Pd-0.40.3-extended-20080512-ubuntu-hardy-i386.debhttp://autobuild.puredata.info/auto-build/latest/Pd-0.40.3-extended-20080512-ubuntu-hardy-i386.debon a fresh install of Ubuntu Hardy, running the rt kernel. Well, almost fresh; I installed all the packages for compiling Ardour 3.0, which includes the latest jack stuff.
Not good results; pd terminates immediately as fallows:
r@r:~/pd/bugs$ pd tk scaling is 1.79053373615 *** stack smashing detected ***: pd terminated ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7e10138] /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7e100f0] pd[0x80c0642] ======= Memory map: ======== 08048000-0811b000 r-xp 00000000 08:01 395096 /usr/bin/pd 0811b000-0811d000 rw-p 000d2000 08:01 395096 /usr/bin/pd 0811d000-0a150000 rw-p 0811d000 00:00 0 [heap] b7d21000-b7d23000 rw-p b7d21000 00:00 0 b7d23000-b7e6c000 r-xp 00000000 08:01 523578 /lib/tls/i686/cmov/ libc-2.7.so b7e6c000-b7e6d000 r--p 00149000 08:01 523578 /lib/tls/i686/cmov/ libc-2.7.so b7e6d000-b7e6f000 rw-p 0014a000 08:01 523578 /lib/tls/i686/cmov/ libc-2.7.so b7e6f000-b7e72000 rw-p b7e6f000 00:00 0 b7e72000-b7e86000 r-xp 00000000 08:01 523604 /lib/tls/i686/cmov/ libpthread-2.7.so b7e86000-b7e88000 rw-p 00013000 08:01 523604 /lib/tls/i686/cmov/ libpthread-2.7.so b7e88000-b7e8a000 rw-p b7e88000 00:00 0 b7e8a000-b7ead000 r-xp 00000000 08:01 523586 /lib/tls/i686/cmov/ libm-2.7.so b7ead000-b7eaf000 rw-p 00023000 08:01 523586 /lib/tls/i686/cmov/ libm-2.7.so b7eaf000-b7eb1000 r-xp 00000000 08:01 523584 /lib/tls/i686/cmov/ libdl-2.7.so b7eb1000-b7eb3000 rw-p 00001000 08:01 523584 /lib/tls/i686/cmov/ libdl-2.7.so b7eb3000-b7ec2000 r-xp 00000000 08:01 394059 /usr/lib/libjack.so.0.0.28 b7ec2000-b7ec4000 rw-p 0000f000 08:01 394059 /usr/lib/libjack.so.0.0.28 b7ec4000-b7ecd000 rw-p b7ec4000 00:00 0 b7ecd000-b7ed4000 r-xp 00000000 08:01 523608 /lib/tls/i686/cmov/ librt-2.7.so b7ed4000-b7ed6000 rw-p 00006000 08:01 523608 /lib/tls/i686/cmov/ librt-2.7.so b7ed6000-b7f95000 r-xp 00000000 08:01 393080 /usr/lib/libasound.so.2.0.0 b7f95000-b7f99000 rw-p 000be000 08:01 393080 /usr/lib/libasound.so.2.0.0 b7f9d000-b7fa7000 r-xp 00000000 08:01 505984 /lib/libgcc_s.so.1 b7fa7000-b7fa8000 rw-p 0000a000 08:01 505984 /lib/libgcc_s.so.1 b7fa8000-b7fa9000 r-xp 00000000 08:01 752586 /usr/lib/pd/extra/libdir.pd_linux b7fa9000-b7faa000 rw-p 00000000 08:01 752586 /usr/lib/pd/extra/libdir.pd_linux b7faa000-b7fac000 rw-p b7faa000 00:00 0 b7fac000-b7fad000 r-xp b7fac000 00:00 0 [vdso] b7fad000-b7fc7000 r-xp 00000000 08:01 505939 /lib/ld-2.7.so b7fc7000-b7fc9000 rw-p 00019000 08:01 505939 /lib/ld-2.7.so bfd36000-bfd4b000 rw-p bffeb000 00:00 0 [stack] Pd: signal 6 pd_gui: pd process exited
I hope it is something obvious. I also tried all the other debian-related packages (stable, unstable, ubuntu gutsy, for 0.41-4 as well), but gdeb doesnt detect libgsl0 and I am stuck there. I have installed the apt packages for libgsl0 and have also installed it from source, so I don't know what it is really looking for.
regards, rich
On Mon, May 12, 2008 at 12:52 PM, Hans-Christoph Steiner hans@eds.org wrote:
Hey all,
I've been fixing quite a lot of bugs in preparation of making the Pd- extended 0.40.3 release. It's getting pretty much ready, so please test it heavily so we can find any outstanding bugs!
Jack just pointed out that pdp on Mac OS X/PowerPC is having problems loading videos, and is crashing, so I am working on that now.
.hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hmm, does it work if you start it with "pd -noprefs"? i would suspect the problem to be in the "libdir" loader.
Pd will start this way, but if I do just about anything, it will show similar errors. For instance, I got this error message when I rightclicked-help on the number box (and might I add, what a nice looking number box) in the first control example. This also happens when I try to get help on [osc~] in the first audio example. The error messages are almost identical (may even be, although I haven't looked too close at the hex numbers).
*** stack smashing detected ***: pd terminated ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7db8138] /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7db80f0] pd[0x80c2698] ======= Memory map: ======== 08048000-0811b000 r-xp 00000000 08:01 395201 /usr/bin/pd 0811b000-0811d000 rw-p 000d2000 08:01 395201 /usr/bin/pd 0811d000-0a150000 rw-p 0811d000 00:00 0 [heap] b7cbe000-b7cc8000 r-xp 00000000 08:01 505984 /lib/libgcc_s.so.1 b7cc8000-b7cc9000 rw-p 0000a000 08:01 505984 /lib/libgcc_s.so.1 b7cc9000-b7ccb000 rw-p b7cc9000 00:00 0 b7ccb000-b7e14000 r-xp 00000000 08:01 523578 /lib/tls/i686/cmov/ libc-2.7.so b7e14000-b7e15000 r--p 00149000 08:01 523578 /lib/tls/i686/cmov/ libc-2.7.so b7e15000-b7e17000 rw-p 0014a000 08:01 523578 /lib/tls/i686/cmov/ libc-2.7.so b7e17000-b7e1a000 rw-p b7e17000 00:00 0 b7e1a000-b7e2e000 r-xp 00000000 08:01 523604 /lib/tls/i686/cmov/ libpthread-2.7.so b7e2e000-b7e30000 rw-p 00013000 08:01 523604 /lib/tls/i686/cmov/ libpthread-2.7.so b7e30000-b7e32000 rw-p b7e30000 00:00 0 b7e32000-b7e55000 r-xp 00000000 08:01 523586 /lib/tls/i686/cmov/ libm-2.7.so b7e55000-b7e57000 rw-p 00023000 08:01 523586 /lib/tls/i686/cmov/ libm-2.7.so b7e57000-b7e59000 r-xp 00000000 08:01 523584 /lib/tls/i686/cmov/ libdl-2.7.so b7e59000-b7e5b000 rw-p 00001000 08:01 523584 /lib/tls/i686/cmov/ libdl-2.7.so b7e5b000-b7e6a000 r-xp 00000000 08:01 394059 /usr/lib/libjack.so.0.0.28 b7e6a000-b7e6c000 rw-p 0000f000 08:01 394059 /usr/lib/libjack.so.0.0.28 b7e6c000-b7e75000 rw-p b7e6c000 00:00 0 b7e75000-b7e7c000 r-xp 00000000 08:01 523608 /lib/tls/i686/cmov/ librt-2.7.so b7e7c000-b7e7e000 rw-p 00006000 08:01 523608 /lib/tls/i686/cmov/ librt-2.7.so b7e7e000-b7f3d000 r-xp 00000000 08:01 393080 /usr/lib/libasound.so.2.0.0 b7f3d000-b7f41000 rw-p 000be000 08:01 393080 /usr/lib/libasound.so.2.0.0 b7f53000-b7f55000 rw-p b7f53000 00:00 0 b7f55000-b7f56000 r-xp b7f55000 00:00 0 [vdso] b7f56000-b7f70000 r-xp 00000000 08:01 505939 /lib/ld-2.7.so b7f70000-b7f72000 rw-p 00019000 08:01 505939 /lib/ld-2.7.so bf8c7000-bf8dc000 rw-p bffeb000 00:00 0 [stack] Pd: signal 6 pd_gui: pd process exited
Just my luck, I made an announcement and break things at the same
time :D. I was only testing builds on my own machine. I did some
testing, this build seems to work for me, and I'll work on fixing
this crash now:
http://autobuild.puredata.info/auto-build/2008-05-09/
.hc
On May 13, 2008, at 9:57 AM, Rich E wrote:
hmm, does it work if you start it with "pd -noprefs"? i would suspect the problem to be in the "libdir" loader.
Pd will start this way, but if I do just about anything, it will
show similar errors. For instance, I got this error message when I
rightclicked-help on the number box (and might I add, what a nice
looking number box) in the first control example. This also
happens when I try to get help on [osc~] in the first audio
example. The error messages are almost identical (may even be,
although I haven't looked too close at the hex numbers).*** stack smashing detected ***: pd terminated ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7db8138] /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7db80f0] pd[0x80c2698] ======= Memory map: ======== 08048000-0811b000 r-xp 00000000 08:01 395201 /usr/bin/pd 0811b000-0811d000 rw-p 000d2000 08:01 395201 /usr/bin/pd 0811d000-0a150000 rw-p 0811d000 00:00 0 [heap] b7cbe000-b7cc8000 r-xp 00000000 08:01 505984 /lib/libgcc_s.so.1 b7cc8000-b7cc9000 rw-p 0000a000 08:01 505984 /lib/libgcc_s.so.1 b7cc9000-b7ccb000 rw-p b7cc9000 00:00 0 b7ccb000-b7e14000 r-xp 00000000 08:01 523578 /lib/tls/i686/cmov/ libc-2.7.so b7e14000-b7e15000 r--p 00149000 08:01 523578 /lib/tls/i686/cmov/ libc-2.7.so b7e15000-b7e17000 rw-p 0014a000 08:01 523578 /lib/tls/i686/cmov/ libc-2.7.so b7e17000-b7e1a000 rw-p b7e17000 00:00 0 b7e1a000-b7e2e000 r-xp 00000000 08:01 523604 /lib/tls/i686/cmov/ libpthread-2.7.so b7e2e000-b7e30000 rw-p 00013000 08:01 523604 /lib/tls/i686/cmov/ libpthread-2.7.so b7e30000-b7e32000 rw-p b7e30000 00:00 0 b7e32000-b7e55000 r-xp 00000000 08:01 523586 /lib/tls/i686/cmov/ libm-2.7.so b7e55000-b7e57000 rw-p 00023000 08:01 523586 /lib/tls/i686/cmov/ libm-2.7.so b7e57000-b7e59000 r-xp 00000000 08:01 523584 /lib/tls/i686/cmov/ libdl-2.7.so b7e59000-b7e5b000 rw-p 00001000 08:01 523584 /lib/tls/i686/cmov/ libdl-2.7.so b7e5b000-b7e6a000 r-xp 00000000 08:01 394059 /usr/lib/ libjack.so.0.0.28 b7e6a000-b7e6c000 rw-p 0000f000 08:01 394059 /usr/lib/ libjack.so.0.0.28 b7e6c000-b7e75000 rw-p b7e6c000 00:00 0 b7e75000-b7e7c000 r-xp 00000000 08:01 523608 /lib/tls/i686/cmov/ librt-2.7.so b7e7c000-b7e7e000 rw-p 00006000 08:01 523608 /lib/tls/i686/cmov/ librt-2.7.so b7e7e000-b7f3d000 r-xp 00000000 08:01 393080 /usr/lib/ libasound.so.2.0.0 b7f3d000-b7f41000 rw-p 000be000 08:01 393080 /usr/lib/ libasound.so.2.0.0 b7f53000-b7f55000 rw-p b7f53000 00:00 0 b7f55000-b7f56000 r-xp b7f55000 00:00 0 [vdso] b7f56000-b7f70000 r-xp 00000000 08:01 505939 /lib/ld-2.7.so b7f70000-b7f72000 rw-p 00019000 08:01 505939 /lib/ld-2.7.so bf8c7000-bf8dc000 rw-p bffeb000 00:00 0 [stack] Pd: signal 6 pd_gui: pd process exited
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
http://at.or.at/hans/
Hans-Christoph Steiner wrote:
Hey all,
I've been fixing quite a lot of bugs in preparation of making the Pd- extended 0.40.3 release. It's getting pretty much ready, so please
test it heavily so we can find any outstanding bugs!Jack just pointed out that pdp on Mac OS X/PowerPC is having problems
loading videos, and is crashing, so I am working on that now..hc
hi Hans
i have been happily working with pd-0.40-extended (20080222) for quite a while. there are some issues though.
Pd-0.40.3-extended-20080504-macosx104-i386 on a osx 10.5.2
pd-extended looses all path and startup preferences (this is on osx i don't know about win or linux).
i would like to propose that ~/Library/Preferences/org.puredata.pd.plist will be completely ignored by pd-extended. instead only the org.puredata.pd.plist inside the pd-extended app should be used. this way one could have different working setups. what do you think?
http://lists.puredata.info/pipermail/pd-list/2008-01/058787.html some objects can't create. i think that all of them are know problems. for me not be able to use <~ and >~ is _most_ annoying (hexloader-something?). i know there are workarounds with expr. not including iem-t3 lib is a loss but i can live without it. thou it makes around 5 nice netpd patches not usable anymore.
most help files worked (could create) but some:
iemmatrix/matrix-help.pd mtx ... couldn't create
mrpeach/packOSC-help.pd packOSC ... couldn't create
sssad/sssad-help.pd sssad key ... couldn't create libdir_loader: added sssad to the canvas-local path sssad key ... couldn't create
i wondered why some help files worked and some not. i thought it was done by org.puredata.pd.plist settings. so i added sssad <key>loadlib40</key> <string>sssad</string> restarted pd, but the help files still couldn't create.
[curve] Gem vs. mapping probably some more
what are the goals? which externals are supposed to work on default? are that the ones in the plist? maybe we should focus on them (before i start to open all help files :) )
thanks for all your work and thanks to all the other devs too!
eni
On May 13, 2008, at 10:06 AM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
Hey all, I've been fixing quite a lot of bugs in preparation of making the
Pd- extended 0.40.3 release. It's getting pretty much ready, so
please test it heavily so we can find any outstanding bugs! Jack just pointed out that pdp on Mac OS X/PowerPC is having
problems loading videos, and is crashing, so I am working on that
now. .hchi Hans
i have been happily working with pd-0.40-extended (20080222) for
quite a while. there are some issues though.Pd-0.40.3-extended-20080504-macosx104-i386 on a osx 10.5.2
- at the moment if one modifies the preferences of i.e. vanilla pd
the pd-extended looses all path and startup preferences (this is on
osx i don't know about win or linux).i would like to propose that ~/Library/Preferences/ org.puredata.pd.plist will be completely ignored by pd-extended.
instead only the org.puredata.pd.plist inside the pd-extended app
should be used. this way one could have different working setups. what do you think?
I think people want to save preferences for Pd-extended too. The
current situation isn't great, that's true. If people want separate
preferences, that might be a possibility in a future Pd-extended
release.
- as i reported earlier
http://lists.puredata.info/pipermail/pd-list/2008-01/058787.html some objects can't create. i think that all of them are know
problems. for me not be able to use <~ and >~ is _most_ annoying
(hexloader-something?). i know there are workarounds with expr. not including iem-t3 lib is a loss but i can live without it. thou
it makes around 5 nice netpd patches not usable anymore.
You can now file bug reports from the Help menu in Pd-extended.
Please file a bug report for this.
- help files
most help files worked (could create) but some:
iemmatrix/matrix-help.pd mtx ... couldn't create
mrpeach/packOSC-help.pd packOSC ... couldn't create
sssad/sssad-help.pd sssad key ... couldn't create libdir_loader: added sssad to the canvas-local path sssad key ... couldn't create
i wondered why some help files worked and some not. i thought it
was done by org.puredata.pd.plist settings. so i added sssad <key>loadlib40</key> <string>sssad</string> restarted pd, but the help files still couldn't create.
please file bug reports for each of these.
- name clash
[curve] Gem vs. mapping probably some more
Yeah, that's been around a lot time.
what are the goals? which externals are supposed to work on
default? are that the ones in the plist? maybe we should focus on
them (before i start to open all help files :) )
The goal is to fine bugs and fix them :). Some of the bigger well-
known problems will have to wait until the next release. The
externals in the plist should work without a namespace prefix. All
included externals should work.
thanks for all your work and thanks to all the other devs too!
Thanks for your bug reports and your work with Pd!
.hc
eni
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 13/05/2008, at 20.09, Hans-Christoph Steiner wrote:
On May 13, 2008, at 10:06 AM, Enrique Erne wrote:
- at the moment if one modifies the preferences of i.e. vanilla pd
the pd-extended looses all path and startup preferences (this is on osx i don't know about win or linux).
i would like to propose that ~/Library/Preferences/ org.puredata.pd.plist will be completely ignored by pd-extended. instead only the org.puredata.pd.plist inside the pd-extended app should be used. this way one could have different working setups. what do you think?
This resembles a feature request i made, cf. <http://sourceforge.net/
tracker/index.php?
func=detail&aid=1818177&group_id=55736&atid=478073>. (So I encourage
this.)
I think people want to save preferences for Pd-extended too.
If there was such option in Pd-extended then people could do either
of two to save preferences for Pd-extended:
It should properly be disabled as standard to suit most users need.
On May 13, 2008, at 8:33 PM, Steffen Juul wrote:
On 13/05/2008, at 20.09, Hans-Christoph Steiner wrote:
On May 13, 2008, at 10:06 AM, Enrique Erne wrote:
- at the moment if one modifies the preferences of i.e. vanilla pd
the pd-extended looses all path and startup preferences (this is on osx i don't know about win or linux).
i would like to propose that ~/Library/Preferences/ org.puredata.pd.plist will be completely ignored by pd-extended. instead only the org.puredata.pd.plist inside the pd-extended app should be used. this way one could have different working setups. what do you think?
This resembles a feature request i made, cf. <http:// sourceforge.net/tracker/index.php? func=detail&aid=1818177&group_id=55736&atid=478073>. (So I
encourage this.)I think people want to save preferences for Pd-extended too.
If there was such option in Pd-extended then people could do either
of two to save preferences for Pd-extended:
- Enable 'use "internal preferences"' and edit those.
- Disable 'use "internal preferences"' and edit the normal
preferences.
It should properly be disabled as standard to suit most users need.
I was thinking that is might be nice to have multiple settings
"profiles" that you could load and save from the prefs pane with it's
own GUI like David Golighty's path/startup panes.
.hc
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Hans-Christoph Steiner wrote:
You can now file bug reports from the Help menu in Pd-extended.
Please file a bug report for this.
i cannot: "/usr/bin/gnome-open 'http://sourceforge.net/tracker/?func=add&group_id=55736&atid=478070' Error showing url: There was an error launching the default action command associated with this location."
i guess i should file a bug-report :-)
fgmasdr IOhannes
The May 9th build doesn't have the same problem. I've also tried the newest nightly build on both Gutsy and Hardy, they have the same "stacksmashing" error.
So now that I've ben searching around in the new Pd-extended, here are some things I noticed:
too, even if it is already big enough (which it is by default
path isn't added by libdir (the rest of the externals in the folder appear to be in extra/flatspace, so they can be found. adding /usr/local/lib/pd/extra/bsaylor to the paths list fixes this.
That is as far as I've looked.. time to start messing around more. It looks great, by the way!
Also, I would like to learn how to commit the changes that I know how to do so Hans doesn't have to bother, but I am having problems with svn right now. I posted another message about this.
regards, rich
On Wed, May 14, 2008 at 12:52 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Hans-Christoph Steiner wrote:
You can now file bug reports from the Help menu in Pd-extended. Please file a bug report for this.
i cannot: "/usr/bin/gnome-open 'http://sourceforge.net/tracker/?func=add&group_id=55736&atid=478070' Error showing url: There was an error launching the default action command associated with this location."
i guess i should file a bug-report :-)
fgmasdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I also noticed that [fluid~] and [pool] are missing. Is this because of flext? These are two of the most used externals that a regularly have to make from source, yet they are built fairly easily. Just wondering why they aren't in pd-extended (but the help files are).
On Wed, May 14, 2008 at 8:37 PM, Rich E reakinator@gmail.com wrote:
The May 9th build doesn't have the same problem. I've also tried the newest nightly build on both Gutsy and Hardy, they have the same "stacksmashing" error.
So now that I've ben searching around in the new Pd-extended, here are some things I noticed:
- The new hotkeys (clear console, open help browser) don't work.
- dragging the pd console window (making it longer) makes the panel longer
too, even if it is already big enough (which it is by default
- bsaylor's [pvoc~] and [partconv~] externals cannot be found because the
path isn't added by libdir (the rest of the externals in the folder appear to be in extra/flatspace, so they can be found. adding /usr/local/lib/pd/extra/bsaylor to the paths list fixes this.
That is as far as I've looked.. time to start messing around more. It looks great, by the way!
Also, I would like to learn how to commit the changes that I know how to do so Hans doesn't have to bother, but I am having problems with svn right now. I posted another message about this.
regards, rich
On Wed, May 14, 2008 at 12:52 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Hans-Christoph Steiner wrote:
You can now file bug reports from the Help menu in Pd-extended. Please file a bug report for this.
i cannot: "/usr/bin/gnome-open 'http://sourceforge.net/tracker/?func=add&group_id=55736&atid=478070' Error showing url: There was an error launching the default action command associated with this location."
i guess i should file a bug-report :-)
fgmasdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
So I have my svn copy fixed now, but I can't commit any changes. I requested/received dev privileges, but I don't know if that carried over to the svn switch.
Anywho, I found a couple more libraries that aren't included in the loadlib section of the default.pdsettings and for now I am just listing them on the bugtracker.
Hans, is the file at trunk/packages/linux_make/default.pdsettings the one that goes into pd-extended?
On Wed, May 14, 2008 at 11:54 PM, Rich E reakinator@gmail.com wrote:
I also noticed that [fluid~] and [pool] are missing. Is this because of flext? These are two of the most used externals that a regularly have to make from source, yet they are built fairly easily. Just wondering why they aren't in pd-extended (but the help files are).
On Wed, May 14, 2008 at 8:37 PM, Rich E reakinator@gmail.com wrote:
The May 9th build doesn't have the same problem. I've also tried the newest nightly build on both Gutsy and Hardy, they have the same "stacksmashing" error.
So now that I've ben searching around in the new Pd-extended, here are some things I noticed:
- The new hotkeys (clear console, open help browser) don't work.
- dragging the pd console window (making it longer) makes the panel longer
too, even if it is already big enough (which it is by default
- bsaylor's [pvoc~] and [partconv~] externals cannot be found because the
path isn't added by libdir (the rest of the externals in the folder appear to be in extra/flatspace, so they can be found. adding /usr/local/lib/pd/extra/bsaylor to the paths list fixes this.
That is as far as I've looked.. time to start messing around more. It looks great, by the way!
Also, I would like to learn how to commit the changes that I know how to do so Hans doesn't have to bother, but I am having problems with svn right now. I posted another message about this.
regards, rich
On Wed, May 14, 2008 at 12:52 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Hans-Christoph Steiner wrote:
You can now file bug reports from the Help menu in Pd-extended. Please file a bug report for this.
i cannot: "/usr/bin/gnome-open 'http://sourceforge.net/tracker/?func=add&group_id=55736&atid=478070' Error showing url: There was an error launching the default action command associated with this location."
i guess i should file a bug-report :-)
fgmasdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Rich E wrote:
Anywho, I found a couple more libraries that aren't included in the loadlib section of the default.pdsettings and for now I am just listing them on the bugtracker.
Hans, is the file at trunk/packages/linux_make/default.pdsettings the one that goes into pd-extended?
i thought this was by intention: remove as many possible libraries from the default settings in pdext as possible and encourage the people to use [import] in their patches.
i might be mistaken however
fgmasdr IOhannes
On May 15, 2008, at 9:46 AM, IOhannes m zmoelnig wrote:
Rich E wrote:
Anywho, I found a couple more libraries that aren't included in the loadlib section of the default.pdsettings and for now I am just
listing them on the bugtracker.Hans, is the file at trunk/packages/linux_make/default.pdsettings the one that goes into pd-extended?
i thought this was by intention: remove as many possible libraries
from the default settings in pdext as possible and encourage the people to use [import] in their patches.i might be mistaken however
You are correct. Though I think we should not remove anything from
those files for now, for the sake of backwards compatibility.
.hc
fgmasdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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
Hey,
It's great that you are stepping up and starting to work in the SVN.
There is a very important rule to observe when doing this: if you
are going to commit a file that you are not the original creator of,
always ask the original creator if that is ok! This is essential to
preventing us from stepping on each others toes.
For example, please do not commit any changes to the
default.pdsettings and related files without asking (pd-dev is a good
place to ask). Those files need to stay as they are until we work
out a better solution.
.hc
On May 15, 2008, at 9:30 AM, Rich E wrote:
So I have my svn copy fixed now, but I can't commit any changes. I
requested/received dev privileges, but I don't know if that carried
over to the svn switch.Anywho, I found a couple more libraries that aren't included in the
loadlib section of the default.pdsettings and for now I am just
listing them on the bugtracker.Hans, is the file at trunk/packages/linux_make/default.pdsettings
the one that goes into pd-extended?On Wed, May 14, 2008 at 11:54 PM, Rich E reakinator@gmail.com wrote: I also noticed that [fluid~] and [pool] are missing. Is this
because of flext? These are two of the most used externals that a
regularly have to make from source, yet they are built fairly
easily. Just wondering why they aren't in pd-extended (but the
help files are).On Wed, May 14, 2008 at 8:37 PM, Rich E reakinator@gmail.com wrote: The May 9th build doesn't have the same problem. I've also tried
the newest nightly build on both Gutsy and Hardy, they have the
same "stacksmashing" error.So now that I've ben searching around in the new Pd-extended, here
are some things I noticed:
- The new hotkeys (clear console, open help browser) don't work.
- dragging the pd console window (making it longer) makes the panel
longer too, even if it is already big enough (which it is by default
- bsaylor's [pvoc~] and [partconv~] externals cannot be found
because the path isn't added by libdir (the rest of the externals
in the folder appear to be in extra/flatspace, so they can be
found. adding /usr/local/lib/pd/extra/bsaylor to the paths list
fixes this.That is as far as I've looked.. time to start messing around more.
It looks great, by the way!Also, I would like to learn how to commit the changes that I know
how to do so Hans doesn't have to bother, but I am having problems
with svn right now. I posted another message about this.regards, rich
On Wed, May 14, 2008 at 12:52 AM, IOhannes m zmoelnig
zmoelnig@iem.at wrote: Hans-Christoph Steiner wrote:You can now file bug reports from the Help menu in Pd-extended. Please file a bug report for this.
i cannot: "/usr/bin/gnome-open 'http://sourceforge.net/tracker/?func=add&group_id=55736&atid=478070' Error showing url: There was an error launching the default action command associated with this location."
i guess i should file a bug-report :-)
fgmasdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
Flext isn't part of the automatic builds, that is why they are not
included.
.hc
On May 15, 2008, at 8:54 AM, Rich E wrote:
I also noticed that [fluid~] and [pool] are missing. Is this
because of flext? These are two of the most used externals that a
regularly have to make from source, yet they are built fairly
easily. Just wondering why they aren't in pd-extended (but the
help files are).On Wed, May 14, 2008 at 8:37 PM, Rich E reakinator@gmail.com wrote: The May 9th build doesn't have the same problem. I've also tried
the newest nightly build on both Gutsy and Hardy, they have the
same "stacksmashing" error.So now that I've ben searching around in the new Pd-extended, here
are some things I noticed:
- The new hotkeys (clear console, open help browser) don't work.
- dragging the pd console window (making it longer) makes the panel
longer too, even if it is already big enough (which it is by default
- bsaylor's [pvoc~] and [partconv~] externals cannot be found
because the path isn't added by libdir (the rest of the externals
in the folder appear to be in extra/flatspace, so they can be
found. adding /usr/local/lib/pd/extra/bsaylor to the paths list
fixes this.That is as far as I've looked.. time to start messing around more.
It looks great, by the way!Also, I would like to learn how to commit the changes that I know
how to do so Hans doesn't have to bother, but I am having problems
with svn right now. I posted another message about this.regards, rich
On Wed, May 14, 2008 at 12:52 AM, IOhannes m zmoelnig
zmoelnig@iem.at wrote: Hans-Christoph Steiner wrote:You can now file bug reports from the Help menu in Pd-extended. Please file a bug report for this.
i cannot: "/usr/bin/gnome-open 'http://sourceforge.net/tracker/?func=add&group_id=55736&atid=478070' Error showing url: There was an error launching the default action command associated with this location."
i guess i should file a bug-report :-)
fgmasdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[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
On May 15, 2008, at 5:37 AM, Rich E wrote:
The May 9th build doesn't have the same problem. I've also tried
the newest nightly build on both Gutsy and Hardy, they have the
same "stacksmashing" error.
Today's build gets rid of the stacksmashing error (for me at least).
Please test! :D
http://autobuild.puredata.info/auto-build/2008-05-15/
So now that I've ben searching around in the new Pd-extended, here
are some things I noticed:
- The new hotkeys (clear console, open help browser) don't work.
Fixed.
- dragging the pd console window (making it longer) makes the panel
longer too, even if it is already big enough (which it is by default
Yeah, that could be a lot nicer...
.hc
- bsaylor's [pvoc~] and [partconv~] externals cannot be found
because the path isn't added by libdir (the rest of the externals
in the folder appear to be in extra/flatspace, so they can be
found. adding /usr/local/lib/pd/extra/bsaylor to the paths list
fixes this.That is as far as I've looked.. time to start messing around more.
It looks great, by the way!Also, I would like to learn how to commit the changes that I know
how to do so Hans doesn't have to bother, but I am having problems
with svn right now. I posted another message about this.regards, rich
On Wed, May 14, 2008 at 12:52 AM, IOhannes m zmoelnig
zmoelnig@iem.at wrote: Hans-Christoph Steiner wrote:You can now file bug reports from the Help menu in Pd-extended. Please file a bug report for this.
i cannot: "/usr/bin/gnome-open 'http://sourceforge.net/tracker/?func=add&group_id=55736&atid=478070' Error showing url: There was an error launching the default action command associated with this location."
i guess i should file a bug-report :-)
fgmasdr IOhannes
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
Working here too. Thanks, again it looks great!
I wanted to mention that one of the most intimidating things for me when I was first learning about all the externals in pd is that nothing was working by default and I didn't know how to get it working. Pd-extended has come a long way since then, and now I know how to look for missing paths, where to find sources and compile, etc., but I am sure there are many others that give up on pd-extended when things seem 'broken'.
I guess what I am suggesting is that something, anything, be one so that the help files can find the externals and the externals can find the help files, by default. If there are issues about organization that are later to be sought out, maybe externals like [pvoc~] should be moved into flatspace until a better solution is committed?
rich
On Thu, May 15, 2008 at 6:58 AM, Hans-Christoph Steiner hans@eds.org wrote:
On May 15, 2008, at 5:37 AM, Rich E wrote:
The May 9th build doesn't have the same problem. I've also tried the newest nightly build on both Gutsy and Hardy, they have the same "stacksmashing" error.
Today's build gets rid of the stacksmashing error (for me at least). Please test! :D
http://autobuild.puredata.info/auto-build/2008-05-15/
So now that I've ben searching around in the new Pd-extended, here are some things I noticed:
- The new hotkeys (clear console, open help browser) don't work.
Fixed.
- dragging the pd console window (making it longer) makes the panel longer
too, even if it is already big enough (which it is by default
Yeah, that could be a lot nicer...
.hc
- bsaylor's [pvoc~] and [partconv~] externals cannot be found because the
path isn't added by libdir (the rest of the externals in the folder appear to be in extra/flatspace, so they can be found. adding /usr/local/lib/pd/extra/bsaylor to the paths list fixes this.
That is as far as I've looked.. time to start messing around more. It looks great, by the way!
Also, I would like to learn how to commit the changes that I know how to do so Hans doesn't have to bother, but I am having problems with svn right now. I posted another message about this.
regards, rich
On Wed, May 14, 2008 at 12:52 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Hans-Christoph Steiner wrote:
You can now file bug reports from the Help menu in Pd-extended. Please file a bug report for this.
i cannot: "/usr/bin/gnome-open 'http://sourceforge.net/tracker/?func=add&group_id=55736&atid=478070' Error showing url: There was an error launching the default action command associated with this location."
i guess i should file a bug-report :-)
fgmasdr IOhannes
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
There is much that can and should be done. Here's some ideas ranked
into of difficulty:
helpfiles, manuals, examples, etc then write code to index it all,
and create a GUI to navigate that content
At this point, I think it is mostly a waste of time to do constant
little workarounds like moving around objects. We should be putting
our scarce resources towards real improvements, not temporary fixes,
IMHO.
.hc
On May 17, 2008, at 12:54 PM, Rich E wrote:
Working here too. Thanks, again it looks great!
I wanted to mention that one of the most intimidating things for me
when I was first learning about all the externals in pd is that
nothing was working by default and I didn't know how to get it
working. Pd-extended has come a long way since then, and now I
know how to look for missing paths, where to find sources and
compile, etc., but I am sure there are many others that give up on
pd-extended when things seem 'broken'.I guess what I am suggesting is that something, anything, be one so
that the help files can find the externals and the externals can
find the help files, by default. If there are issues about
organization that are later to be sought out, maybe externals like
[pvoc~] should be moved into flatspace until a better solution is
committed?rich
On Thu, May 15, 2008 at 6:58 AM, Hans-Christoph Steiner
hans@eds.org wrote:On May 15, 2008, at 5:37 AM, Rich E wrote:
The May 9th build doesn't have the same problem. I've also tried
the newest nightly build on both Gutsy and Hardy, they have the
same "stacksmashing" error.Today's build gets rid of the stacksmashing error (for me at
least). Please test! :Dhttp://autobuild.puredata.info/auto-build/2008-05-15/
So now that I've ben searching around in the new Pd-extended, here
are some things I noticed:
- The new hotkeys (clear console, open help browser) don't work.
Fixed.
- dragging the pd console window (making it longer) makes the
panel longer too, even if it is already big enough (which it is by
defaultYeah, that could be a lot nicer...
.hc
- bsaylor's [pvoc~] and [partconv~] externals cannot be found
because the path isn't added by libdir (the rest of the externals
in the folder appear to be in extra/flatspace, so they can be
found. adding /usr/local/lib/pd/extra/bsaylor to the paths list
fixes this.That is as far as I've looked.. time to start messing around
more. It looks great, by the way!Also, I would like to learn how to commit the changes that I know
how to do so Hans doesn't have to bother, but I am having problems
with svn right now. I posted another message about this.regards, rich
On Wed, May 14, 2008 at 12:52 AM, IOhannes m zmoelnig
zmoelnig@iem.at wrote: Hans-Christoph Steiner wrote:You can now file bug reports from the Help menu in Pd-extended. Please file a bug report for this.
i cannot: "/usr/bin/gnome-open 'http://sourceforge.net/tracker/?func=add&group_id=55736&atid=478070' Error showing url: There was an error launching the default action command associated with this location."
i guess i should file a bug-report :-)
fgmasdr IOhannes
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
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
Hans-Christoph Steiner wrote:
There is much that can and should be done. Here's some ideas ranked into of difficulty:
- file a bug report when a help patch is not working
- write and improve help patches, and submit them to the patch tracker
is there a convention about how to make it work? i.e. should one use declare, import or namespace prefix?
i guess all help-files that are not loaded on default would need a declare/import/or-namespace in order to work...
i want to contribute and help to make "all"/more helpfiles work. i know there is pddp but afaik it does not solve the declare/import/or-namespace problem.
could all developers express their opinion and agree on how to make all helpfiles work? :)
i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too.
- add a search pane to the help panel
is this done in tcl/tk? is there any documentation about that on puredata.info?
- help design and code a library format that bundles objectclasses,
helpfiles, manuals, examples, etc then write code to index it all, and create a GUI to navigate that content
At this point, I think it is mostly a waste of time to do constant little workarounds like moving around objects. We should be putting our scarce resources towards real improvements, not temporary fixes, IMHO.
.hc
On May 17, 2008, at 5:50 PM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
There is much that can and should be done. Here's some ideas
ranked into of difficulty:
- file a bug report when a help patch is not working
- write and improve help patches, and submit them to the patch
tracker
is there a convention about how to make it work? i.e. should one
use declare, import or namespace prefix?i guess all help-files that are not loaded on default would need a
declare/import/or-namespace in order to work...i want to contribute and help to make "all"/more helpfiles work. i
know there is pddp but afaik it does not solve the declare/import/ or-namespace problem.could all developers express their opinion and agree on how to make
all helpfiles work? :)
Starting with the PDDP template is a good place to start:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/pddp/ templates/
i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too.
The declare/namespace/import stuff is still very undefined, so I
think some experiementation would be good. I think you should go
ahead and try it using what you propose. That will be a good test
case. Then we'll figure out what works best.
Personally, I would use namespace prefixes: [mrpeach/packOSC].
This will make more sense when there are libraries organized around
concepts rather than authors. So something like [osc/packOSC]
- add a search pane to the help panel
is this done in tcl/tk? is there any documentation about that on
puredata.info?
It is done however you want to, more or less, but I think a pure Tcl
solution would be possible, and perhaps easiest.
.hc
- help design and code a library format that bundles
objectclasses, helpfiles, manuals, examples, etc then write code
to index it all, and create a GUI to navigate that content At this point, I think it is mostly a waste of time to do constant
little workarounds like moving around objects. We should be
putting our scarce resources towards real improvements, not
temporary fixes, IMHO. .hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
Hans-Christoph Steiner wrote:
i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too.
The declare/namespace/import stuff is still very undefined, so I
think some experiementation would be good. I think you should go
ahead and try it using what you propose. That will be a good test
case. Then we'll figure out what works best.
putting the helppatches besides the objects should fix most of the problems, no? no need for [declare] orgies and such
fgmasdr IOhannes
On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too.
The declare/namespace/import stuff is still very undefined, so I
think some experiementation would be good. I think you should go
ahead and try it using what you propose. That will be a good test
case. Then we'll figure out what works best.putting the helppatches besides the objects should fix most of the problems, no? no need for [declare] orgies and such
yo.. it would seem strange having to put [declare]s into help-patches in order to load the the objects, that they are explaining, IMO.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too.
The declare/namespace/import stuff is still very undefined, so I
think some experiementation would be good. I think you should go
ahead and try it using what you propose. That will be a good test
case. Then we'll figure out what works best.putting the helppatches besides the objects should fix most of the problems, no? no need for [declare] orgies and such
yo.. it would seem strange having to put [declare]s into help-patches in order to load the the objects, that they are explaining, IMO.
maybe i miss something:
to it seems _not_ strange to have a working help patch. the declare is documenting how one can use the object-class of the external (one of the 4, 5... 6 ways).
or do you think a user should configure the plist/pdrc/registry first and restart Pd before he can use the documentation/helpfile?
On Sun, 2008-05-18 at 05:40 -0400, Enrique Erne wrote:
Roman Haefeli wrote:
On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too.
The declare/namespace/import stuff is still very undefined, so I
think some experiementation would be good. I think you should go
ahead and try it using what you propose. That will be a good test
case. Then we'll figure out what works best.putting the helppatches besides the objects should fix most of the problems, no? no need for [declare] orgies and such
yo.. it would seem strange having to put [declare]s into help-patches in order to load the the objects, that they are explaining, IMO.
maybe i miss something:
to it seems _not_ strange to have a working help patch. the declare is documenting how one can use the object-class of the external (one of the 4, 5... 6 ways).
there are only so many in pd-extended, there aren't that many in pd-vanilla ( i can think of [declare] and pd-settings file only).
or do you think a user should configure the plist/pdrc/registry first and restart Pd before he can use the documentation/helpfile?
i think, as IOhannes said, that it would make sense to put classes (libraries, abstractions, single-object files) and their help-files at the same place. i don't see a benefit in having to tell a help-file where to find the class.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Sun, 2008-05-18 at 12:09 +0200, Roman Haefeli wrote:
On Sun, 2008-05-18 at 05:40 -0400, Enrique Erne wrote:
Roman Haefeli wrote:
On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too.
The declare/namespace/import stuff is still very undefined, so I
think some experiementation would be good. I think you should go
ahead and try it using what you propose. That will be a good test
case. Then we'll figure out what works best.putting the helppatches besides the objects should fix most of the problems, no? no need for [declare] orgies and such
yo.. it would seem strange having to put [declare]s into help-patches in order to load the the objects, that they are explaining, IMO.
maybe i miss something:
to it seems _not_ strange to have a working help patch. the declare is documenting how one can use the object-class of the external (one of the 4, 5... 6 ways).
there are only so many in pd-extended, there aren't that many in pd-vanilla ( i can think of [declare] and pd-settings file only).
or do you think a user should configure the plist/pdrc/registry first and restart Pd before he can use the documentation/helpfile?
i think, as IOhannes said, that it would make sense to put classes (libraries, abstractions, single-object files) and their help-files at the same place. i don't see a benefit in having to tell a help-file where to find the class.
i meant: i don't see a benefit in having to tell _in_ a help-file where to find the class.
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On 18/05/2008, at 12.16, Roman Haefeli wrote:
i don't see a benefit in having to tell _in_ a help-file where to find the class.
I agree.
And the same goes for the other way around. That would be very good
for giving the help browser a bash, especially (dynamically creation
of) the reference section (based on path settings). If they (the
helpfiles/classes/libs) are in the same dir going the route HCS
surest, that is to do it in TCL, might also make auto/tab-completion
in object-boxes within reach. - Humble ideas.
On May 18, 2008, at 12:09 PM, Roman Haefeli wrote:
On Sun, 2008-05-18 at 05:40 -0400, Enrique Erne wrote:
Roman Haefeli wrote:
On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too.
The declare/namespace/import stuff is still very undefined, so I think some experiementation would be good. I think you should go ahead and try it using what you propose. That will be a good test case. Then we'll figure out what works best.
putting the helppatches besides the objects should fix most of the problems, no? no need for [declare] orgies and such
yo.. it would seem strange having to put [declare]s into help- patches in order to load the the objects, that they are explaining, IMO.
maybe i miss something:
to it seems _not_ strange to have a working help patch. the
declare is documenting how one can use the object-class of the external (one
of the 4, 5... 6 ways).there are only so many in pd-extended, there aren't that many in pd-vanilla ( i can think of [declare] and pd-settings file only).
or do you think a user should configure the plist/pdrc/registry first and restart Pd before he can use the documentation/helpfile?
i think, as IOhannes said, that it would make sense to put classes (libraries, abstractions, single-object files) and their help-files at the same place. i don't see a benefit in having to tell a help-file where to find the class.
Yeah, that's the idea of libdirs. It just needs to be implemented
fully. It's pretty close.
.hc
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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
Hans-Christoph Steiner wrote:
On May 18, 2008, at 12:09 PM, Roman Haefeli wrote:
On Sun, 2008-05-18 at 05:40 -0400, Enrique Erne wrote:
Roman Haefeli wrote:
On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
> i'm not a developer but i would vote for declare > i.e. [declare -stdlib mrpeach] to packOSC-help.pd > then it would work with pd vanilla too. The declare/namespace/import stuff is still very undefined, so I think some experiementation would be good. I think you should go ahead and try it using what you propose. That will be a good test case. Then we'll figure out what works best.
putting the helppatches besides the objects should fix most of the problems, no? no need for [declare] orgies and such
yo.. it would seem strange having to put [declare]s into help- patches in order to load the the objects, that they are explaining, IMO.
maybe i miss something:
to it seems _not_ strange to have a working help patch. the
declare is documenting how one can use the object-class of the external (one
of the 4, 5... 6 ways).there are only so many in pd-extended, there aren't that many in pd-vanilla ( i can think of [declare] and pd-settings file only).
or do you think a user should configure the plist/pdrc/registry first and restart Pd before he can use the documentation/helpfile?
i think, as IOhannes said, that it would make sense to put classes (libraries, abstractions, single-object files) and their help-files at the same place. i don't see a benefit in having to tell a help-file where to find the class.
Yeah, that's the idea of libdirs. It just needs to be implemented
fully. It's pretty close.
I have all my help files in the same place as the source code in the svn repository but they end up separated in pd-extended (the binaries go to extra/mrpeach and the help files are in doc/5.reference/mrpeach). As has already been remarked, I can instantiate for example [mrpeach/tcpclient] but not [tcpclient] but in either case the help file isn't found and if I open it manually it won't make [tcpclient] either. So I'm just wondering what I can do about that... If I put [mrpeach/tcpclient] in the help file it will work but it doesn't do anything to make the help file findable. Is there some make file I need to edit or does the libdir thing fix this?
Martin
On May 19, 2008, at 6:55 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
On May 18, 2008, at 12:09 PM, Roman Haefeli wrote:
On Sun, 2008-05-18 at 05:40 -0400, Enrique Erne wrote:
Roman Haefeli wrote:
On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote: >> i'm not a developer but i would vote for declare >> i.e. [declare -stdlib mrpeach] to packOSC-help.pd >> then it would work with pd vanilla too. > The declare/namespace/import stuff is still very undefined, so I > think some experiementation would be good. I think you
> should go > ahead and try it using what you propose. That will be a good
> test > case. Then we'll figure out what works best. putting the helppatches besides the objects should fix most of
the problems, no? no need for [declare] orgies and suchyo.. it would seem strange having to put [declare]s into help-
patches in order to load the the objects, that they are explaining, IMO.maybe i miss something:
to it seems _not_ strange to have a working help patch. the
declare is documenting how one can use the object-class of the external
(one of the 4, 5... 6 ways).there are only so many in pd-extended, there aren't that many in pd-vanilla ( i can think of [declare] and pd-settings file only).
or do you think a user should configure the plist/pdrc/registry
first and restart Pd before he can use the documentation/helpfile?i think, as IOhannes said, that it would make sense to put classes (libraries, abstractions, single-object files) and their help- files at the same place. i don't see a benefit in having to tell a help-file where to find the class.
Yeah, that's the idea of libdirs. It just needs to be
implemented fully. It's pretty close.I have all my help files in the same place as the source code in
the svn repository but they end up separated in pd-extended (the
binaries go to extra/mrpeach and the help files are in doc/ 5.reference/mrpeach). As has already been remarked, I can
instantiate for example [mrpeach/tcpclient] but not [tcpclient] but
in either case the help file isn't found and if I open it manually
it won't make [tcpclient] either. So I'm just wondering what I can
do about that... If I put [mrpeach/tcpclient] in the help file it will work but it
doesn't do anything to make the help file findable. Is there some
make file I need to edit or does the libdir thing fix this?
What would fix this well is a completed libdir format. If the help
files are included in the same folder as the objectclasses, then the
help files will be found either way, AFAIK. But since 0.41-4 is out,
and Pd-extended 0.40 has a lot of changes that are pretty well
tested, I think it makes sense to release 0.40, then work on the
whole libdir/import/declare issue in 0.41 (though I really hoped to
do it for 0.40).
I am fine with leaving this how it is for this release, then fixing
it properly for the next release.
.hc
¡El pueblo unido jamás será vencido!
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
I open it manually it won't make [tcpclient] either. So I'm just wondering what I can do about that...
It's a packaging problem, you can do nothing about it.
Frank Barknecht _ ______footils.org__
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
It's a packaging problem, you can do nothing about it.
you can help the packager solve the problem.
But not by changing the help file or the object itself, only by changing the packaging or finding a good way to deal with modules/aliases/namespaces. The reason for help-file breakage are the custom alias-names for objects that pd-extended introduces, e.g. the alias [mrpeach/tcpclient] for [tcpclient]. Didn't someone say aliases are bad? ;)
Frank Barknecht _ ______footils.org__
On May 20, 2008, at 10:53 AM, Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
It's a packaging problem, you can do nothing about it.
you can help the packager solve the problem.
But not by changing the help file or the object itself, only by changing the packaging or finding a good way to deal with modules/aliases/namespaces. The reason for help-file breakage are the custom alias-names for objects that pd-extended introduces, e.g. the alias [mrpeach/tcpclient] for [tcpclient]. Didn't someone say aliases are bad? ;)
Pd-extended did not introduce namespace prefixes, Miller did that
probably before I even heard of Pd. Pd-extended is just organized
around that idea. Pd-vanilla fully supports namespace prefixes. I
don't know how many times I have to say this, but it hasn't changed
since the beginning. I guess its just part of the ebb and flow of
this list to have this discussion every 6 months. ;)
.hc
Ciao
Frank Barknecht _
______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Pd-extended did not introduce namespace prefixes, Miller did that
probably before I even heard of Pd. Pd-extended is just organized
around that idea. Pd-vanilla fully supports namespace prefixes. I
don't know how many times I have to say this, but it hasn't changed
since the beginning. I guess its just part of the ebb and flow of
this list to have this discussion every 6 months. ;)
I also have a strong Deja vu. ;)
Anyway, to reiterate the problem for others: *-help.pd files that are in the same directory as the abstractions that they document work everywhere:
Directory layout 1:
extra/prefix/abst.pd
extra/prefix/abst-help.pd <= uses [abst]
Start Pd:
$ pd -path extra -helppath extra
Create [prefix/abst], select Help on it, "prefix/abst-help.pd" is
opened and shows [abst]
But this doesn't work:
Directory layout 2:
extra/prefix/abst.pd
doc/prefix/abst-help.pd <= uses [abst]
Start Pd as:
$ pd -path extra -helppath doc
Create [prefix/abst], select Help on it, "prefix/abst-help.pd" is
opened, but [abst] is broken.
This is a well-known issue and as far as I see it has two fixes
a simple one: Use "Directory layout 1" or
and a complex one: Make a [declare]/[import] for Pd-vanilla that "works", agree on "prefix"es and add [declare]/[import] to the help file to load "prefix" locally.
There also is a bad (IMO) third fix: Make abst-help.pd use [prefix/abst], which is bad because it breaks, if you're not using "Directory layout 2" exactly, for example, if you make a copy of abst.pd and abst-help.pd in your working/project directory and don't install it globally.
Deja vu end.
Frank Barknecht
Both layout 1 and 2 would be nice to have, for different situations. Concerning patches that are included in pd extended, it seems best to use layout 1 that you mention, which is compatible on everyone's system, as of right now. [declare]/[import] seems like something for personal patches, where someone knows what obects they use, and there are no namespace conflicts that are effecting their setup. This system is still in flux, but it can wait, as it is only a system to make things easier.
regards,
rich
On Tue, May 20, 2008 at 5:34 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Pd-extended did not introduce namespace prefixes, Miller did that probably before I even heard of Pd. Pd-extended is just organized around that idea. Pd-vanilla fully supports namespace prefixes. I don't know how many times I have to say this, but it hasn't changed since the beginning. I guess its just part of the ebb and flow of this list to have this discussion every 6 months. ;)
I also have a strong Deja vu. ;)
Anyway, to reiterate the problem for others: *-help.pd files that are in the same directory as the abstractions that they document work everywhere:
Directory layout 1: extra/prefix/abst.pd extra/prefix/abst-help.pd <= uses [abst]
Start Pd: $ pd -path extra -helppath extra
Create [prefix/abst], select Help on it, "prefix/abst-help.pd" is opened and shows [abst]
But this doesn't work:
Directory layout 2: extra/prefix/abst.pd doc/prefix/abst-help.pd <= uses [abst]
Start Pd as: $ pd -path extra -helppath doc
Create [prefix/abst], select Help on it, "prefix/abst-help.pd" is opened, but [abst] is broken.
This is a well-known issue and as far as I see it has two fixes
a simple one: Use "Directory layout 1" or
and a complex one: Make a [declare]/[import] for Pd-vanilla that "works", agree on "prefix"es and add [declare]/[import] to the help file to load "prefix" locally.
There also is a bad (IMO) third fix: Make abst-help.pd use [prefix/abst], which is bad because it breaks, if you're not using "Directory layout 2" exactly, for example, if you make a copy of abst.pd and abst-help.pd in your working/project directory and don't install it globally.
Deja vu end.
Ciao
Frank Barknecht
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, May 22, 2008 at 12:58 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Rich E wrote:
Both layout 1 and 2 would be nice to have, for different situations.
i would be interested in the situations where layout 2 would be nice to have. i don't see any.
For the same reason "from x import *" is in python: so you don't have to type as much. I guess that is it.
mgsdf IOhannes
Hallo, Rich E hat gesagt: // Rich E wrote:
On Thu, May 22, 2008 at 12:58 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Rich E wrote:
Both layout 1 and 2 would be nice to have, for different situations.
i would be interested in the situations where layout 2 would be nice to have. i don't see any.
For the same reason "from x import *" is in python: so you don't have to type as much. I guess that is it.
But you type the same with both layouts. To not have to type the prefix, you just add the "prefix" directory directly to your path with a pd-path setting, declare, import or whatever. The issue of help files not being found is not related to that. Which brings to my mind: I think, Pd may benefit from an option to set the -helppath dynamically, too, e.g. in [declare] or somewhere else.
Frank Barknecht
Quoting Frank Barknecht fbar@footils.org:
But you type the same with both layouts. To not have to type the prefix, you just add the "prefix" directory directly to your path with a pd-path setting, declare, import or whatever. The issue of help files not being found is not related to that.
frank, i agree with you (surprise:-))
rich, i don't see how putting the help-patches into doc/ relates to
what you have described. (but probably i have just lost track of what
you are saying)
Which brings to my mind: I think, Pd may benefit from an option to set the -helppath dynamically, too, e.g. in [declare] or somewhere else.
i think the entire helppath-thing was a _very_ ugly klugde and it
should not be mentioned any more...seriously, it tries to provide
workarounds for things that should be solved straightforward; it
created more confusion within me than i would have thought is proper
for the topic of help-patches.
mfg.da IOhannes
Ciao
Frank Barknecht
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
This message was sent using IMP, the Internet Messaging Program.
On Sat, May 17, 2008 at 9:03 AM, Hans-Christoph Steiner hans@eds.org wrote:
On May 17, 2008, at 5:50 PM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
There is much that can and should be done. Here's some ideas ranked into of difficulty:
- file a bug report when a help patch is not working
- write and improve help patches, and submit them to the patch
tracker
is there a convention about how to make it work? i.e. should one use declare, import or namespace prefix?
i guess all help-files that are not loaded on default would need a declare/import/or-namespace in order to work...
i want to contribute and help to make "all"/more helpfiles work. i know there is pddp but afaik it does not solve the declare/import/ or-namespace problem.
could all developers express their opinion and agree on how to make all helpfiles work? :)
Starting with the PDDP template is a good place to start:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/pddp/ templates/
i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too.
This isn't working for me, using the latest pd-extended. When I start pd with the '-verbose' flag and then use a [declare] statement, what I am declaring is not getting searched (or at least it isn't posting that it is. Anyways, the object in that directory isn't found).
I think this would be a good approach, similar to python's "from x import *" mechanism, but probably not good for help files, as they could introduce nameclashes that are avoided with namespaces.
Personally, I would use namespace prefixes: [mrpeach/packOSC].
This will make more sense when there are libraries organized around concepts rather than authors. So something like [osc/packOSC]
This seems appropriate for help files, as it also tells you where to find the object within the extra folder. Sort of self-documenting.
- add a search pane to the help panel
is this done in tcl/tk? is there any documentation about that on puredata.info?
It is done however you want to, more or less, but I think a pure Tcl solution would be possible, and perhaps easiest.
.hc
- help design and code a library format that bundles
objectclasses, helpfiles, manuals, examples, etc then write code to index it all, and create a GUI to navigate that content At this point, I think it is mostly a waste of time to do constant little workarounds like moving around objects. We should be putting our scarce resources towards real improvements, not temporary fixes, IMHO. .hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 2008-05-18 at 02:30 -0700, Rich E wrote:
Personally, I would use namespace prefixes: [mrpeach/packOSC]. This will make more sense when there are libraries organized around concepts rather than authors. So something like [osc/packOSC]
This seems appropriate for help files, as it also tells you where to find the object within the extra folder. Sort of self-documenting.
personally, i don't think, that is the way to go, since it basically means having to write different help-files for pd-vanilla (with libraries installed as bundles) and pd-extended (which has most libraries as directories with single-object-files).
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On May 18, 2008, at 11:30 AM, Rich E wrote:
On Sat, May 17, 2008 at 9:03 AM, Hans-Christoph Steiner
hans@eds.org wrote:On May 17, 2008, at 5:50 PM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
There is much that can and should be done. Here's some ideas ranked into of difficulty:
- file a bug report when a help patch is not working
- write and improve help patches, and submit them to the patch
tracker
is there a convention about how to make it work? i.e. should one use declare, import or namespace prefix?
i guess all help-files that are not loaded on default would need a declare/import/or-namespace in order to work...
i want to contribute and help to make "all"/more helpfiles work. i know there is pddp but afaik it does not solve the declare/import/ or-namespace problem.
could all developers express their opinion and agree on how to make all helpfiles work? :)
Starting with the PDDP template is a good place to start:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/pddp/ templates/
i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too.
This isn't working for me, using the latest pd-extended. When I
start pd with the '-verbose' flag and then use a [declare]
statement, what I am declaring is not getting searched (or at least
it isn't posting that it is. Anyways, the object in that directory
isn't found).
With the current [declare], you would need to do
[declare -stdlib /full/path/to/mrpeach] [declare -stdpath /full/path/to/mrpeach]
.hc
I think this would be a good approach, similar to python's "from x
import *" mechanism, but probably not good for help files, as they
could introduce nameclashes that are avoided with namespaces.Personally, I would use namespace prefixes: [mrpeach/packOSC]. This will make more sense when there are libraries organized around concepts rather than authors. So something like [osc/packOSC]
This seems appropriate for help files, as it also tells you where
to find the object within the extra folder. Sort of self-documenting.
- add a search pane to the help panel
is this done in tcl/tk? is there any documentation about that on puredata.info?
It is done however you want to, more or less, but I think a pure Tcl solution would be possible, and perhaps easiest.
.hc
- help design and code a library format that bundles
objectclasses, helpfiles, manuals, examples, etc then write code to index it all, and create a GUI to navigate that content At this point, I think it is mostly a waste of time to do constant little workarounds like moving around objects. We should be putting our scarce resources towards real improvements, not temporary fixes, IMHO. .hc
--
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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
Hans-Christoph Steiner wrote:
On May 17, 2008, at 5:50 PM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
There is much that can and should be done. Here's some ideas ranked into of difficulty:
- file a bug report when a help patch is not working
- write and improve help patches, and submit them to the patch tracker
is there a convention about how to make it work? i.e. should one use declare, import or namespace prefix?
i guess all help-files that are not loaded on default would need a declare/import/or-namespace in order to work...
i want to contribute and help to make "all"/more helpfiles work. i know there is pddp but afaik it does not solve the declare/import/or-namespace problem.
could all developers express their opinion and agree on how to make all helpfiles work? :)
Starting with the PDDP template is a good place to start:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/pddp/templat...
i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too.
The declare/namespace/import stuff is still very undefined, so I think some experiementation would be good. I think you should go ahead and try it using what you propose. That will be a good test case. Then we'll figure out what works best.
Personally, I would use namespace prefixes: [mrpeach/packOSC]. This will make more sense when there are libraries organized around concepts rather than authors. So something like [osc/packOSC]
from a user point of view organizing libraries around concepts would be a huge gain. but let's face it: will that every be the case? (rhetorical, but still i would be very happy if somebody has an answer:) )
i just found that: http://puredata.info/dev/PdLibraries http://puredata.info/dev/PdNamespaces
for now i don't know how to help and make the helpfiles work. :(
- add a search pane to the help panel
is this done in tcl/tk? is there any documentation about that on puredata.info?
It is done however you want to, more or less, but I think a pure Tcl solution would be possible, and perhaps easiest.
.hc
- help design and code a library format that bundles objectclasses,
helpfiles, manuals, examples, etc then write code to index it all, and create a GUI to navigate that content At this point, I think it is mostly a waste of time to do constant little workarounds like moving around objects. We should be putting our scarce resources towards real improvements, not temporary fixes, IMHO. .hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
On May 18, 2008, at 11:39 AM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
On May 17, 2008, at 5:50 PM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
There is much that can and should be done. Here's some ideas
ranked into of difficulty:
- file a bug report when a help patch is not working
- write and improve help patches, and submit them to the patch
tracker
is there a convention about how to make it work? i.e. should one
use declare, import or namespace prefix?i guess all help-files that are not loaded on default would need
a declare/import/or-namespace in order to work...i want to contribute and help to make "all"/more helpfiles work.
i know there is pddp but afaik it does not solve the declare/ import/or-namespace problem.could all developers express their opinion and agree on how to
make all helpfiles work? :)Starting with the PDDP template is a good place to start: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/ pddp/templates/
i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too.
The declare/namespace/import stuff is still very undefined, so I
think some experiementation would be good. I think you should go
ahead and try it using what you propose. That will be a good test
case. Then we'll figure out what works best. Personally, I would use namespace prefixes: [mrpeach/packOSC].
This will make more sense when there are libraries organized
around concepts rather than authors. So something like [osc/packOSC]from a user point of view organizing libraries around concepts
would be a huge gain. but let's face it: will that every be the case? (rhetorical, but still i would be very happy if somebody has an
answer:) )
It will be the case if we make it happen. I have already started the
tkwidgets library, which you might guess from the title, is a set of
Tk widgets. ;) I also wrote the "pan" library, which is some
techniques for stereo panning.
.hc
i just found that: http://puredata.info/dev/PdLibraries http://puredata.info/dev/PdNamespaces
for now i don't know how to help and make the helpfiles work. :(
- add a search pane to the help panel
is this done in tcl/tk? is there any documentation about that on
puredata.info?It is done however you want to, more or less, but I think a pure
Tcl solution would be possible, and perhaps easiest. .hc
- help design and code a library format that bundles
objectclasses, helpfiles, manuals, examples, etc then write code
to index it all, and create a GUI to navigate that content At this point, I think it is mostly a waste of time to do
constant little workarounds like moving around objects. We
should be putting our scarce resources towards real
improvements, not temporary fixes, IMHO. .hc
------- News is what people want to keep hidden and everything
else is publicity. - Bill Moyers
Access to computers should be unlimited and total. - the hacker ethic
Hans-Christoph Steiner wrote:
On May 13, 2008, at 10:06 AM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
Hey all, I've been fixing quite a lot of bugs in preparation of making the Pd- extended 0.40.3 release. It's getting pretty much ready, so please
test it heavily so we can find any outstanding bugs! Jack just pointed out that pdp on Mac OS X/PowerPC is having problems loading videos, and is crashing, so I am working on that now. .hchi Hans
i have been happily working with pd-0.40-extended (20080222) for quite a while. there are some issues though.
Pd-0.40.3-extended-20080504-macosx104-i386 on a osx 10.5.2
- at the moment if one modifies the preferences of i.e. vanilla pd
the pd-extended looses all path and startup preferences (this is on osx i don't know about win or linux).
i would like to propose that ~/Library/Preferences/org.puredata.pd.plist will be completely ignored by pd-extended. instead only the org.puredata.pd.plist inside the pd-extended app should be used. this way one could have different working setups. what do you think?
I think people want to save preferences for Pd-extended too. The current situation isn't great, that's true. If people want separate preferences, that might be a possibility in a future Pd-extended release.
ah i forgot that the file inside the app is not save-able
- as i reported earlier
http://lists.puredata.info/pipermail/pd-list/2008-01/058787.html some objects can't create. i think that all of them are know problems. for me not be able to use <~ and >~ is _most_ annoying (hexloader-something?). i know there are workarounds with expr. not including iem-t3 lib is a loss but i can live without it. thou it makes around 5 nice netpd patches not usable anymore.
You can now file bug reports from the Help menu in Pd-extended. Please file a bug report for this.
i wrote a bug report for iem_t3
i'm not sure about the hexloader. i found this: http://sourceforge.net/tracker/index.php?func=detail&aid=1637460&gro... should i file a new bug report?
- help files
most help files worked (could create) but some:
iemmatrix/matrix-help.pd mtx ... couldn't create
mrpeach/packOSC-help.pd packOSC ... couldn't create
sssad/sssad-help.pd sssad key ... couldn't create libdir_loader: added sssad to the canvas-local path sssad key ... couldn't create
i wondered why some help files worked and some not. i thought it was done by org.puredata.pd.plist settings. so i added sssad <key>loadlib40</key> <string>sssad</string> restarted pd, but the help files still couldn't create.
please file bug reports for each of these.
done
- name clash
[curve] Gem vs. mapping probably some more
Yeah, that's been around a lot time.
what are the goals? which externals are supposed to work on default? are that the ones in the plist? maybe we should focus on them (before i start to open all help files :) )
The goal is to fine bugs and fix them :). Some of the bigger well-known problems will have to wait until the next release. The externals in the plist should work without a namespace prefix. All included externals should work.
uhm . now i filed bug reports for helpfiles of externals that are not on the plist. but they work with namespace prefix (except iem_t3)
thanks for all your work and thanks to all the other devs too!
Thanks for your bug reports and your work with Pd!
.hc
eni
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 May 17, 2008, at 12:02 PM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
On May 13, 2008, at 10:06 AM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
Hey all, I've been fixing quite a lot of bugs in preparation of making
the Pd- extended 0.40.3 release. It's getting pretty much
ready, so please test it heavily so we can find any outstanding
bugs! Jack just pointed out that pdp on Mac OS X/PowerPC is having
problems loading videos, and is crashing, so I am working on
that now. .hchi Hans
i have been happily working with pd-0.40-extended (20080222) for
quite a while. there are some issues though.Pd-0.40.3-extended-20080504-macosx104-i386 on a osx 10.5.2
- at the moment if one modifies the preferences of i.e. vanilla
pd the pd-extended looses all path and startup preferences (this
is on osx i don't know about win or linux).i would like to propose that ~/Library/Preferences/ org.puredata.pd.plist will be completely ignored by pd-extended.
instead only the org.puredata.pd.plist inside the pd-extended app
should be used. this way one could have different working setups. what do you think?I think people want to save preferences for Pd-extended too. The
current situation isn't great, that's true. If people want
separate preferences, that might be a possibility in a future Pd- extended release.ah i forgot that the file inside the app is not save-able
- as i reported earlier
http://lists.puredata.info/pipermail/pd-list/2008-01/058787.html some objects can't create. i think that all of them are know
problems. for me not be able to use <~ and >~ is _most_ annoying
(hexloader-something?). i know there are workarounds with expr. not including iem-t3 lib is a loss but i can live without it.
thou it makes around 5 nice netpd patches not usable anymore.You can now file bug reports from the Help menu in Pd-extended.
Please file a bug report for this.i wrote a bug report for iem_t3
i'm not sure about the hexloader. i found this: http://sourceforge.net/tracker/index.php? func=detail&aid=1637460&group_id=55736&atid=478070 should i file a new bug report?
hexloader should be included in tomorrow's build. Please test it.
The t3 stuff should be in today's build.
.hc
- help files
most help files worked (could create) but some:
iemmatrix/matrix-help.pd mtx ... couldn't create
mrpeach/packOSC-help.pd packOSC ... couldn't create
sssad/sssad-help.pd sssad key ... couldn't create libdir_loader: added sssad to the canvas-local path sssad key ... couldn't create
i wondered why some help files worked and some not. i thought it
was done by org.puredata.pd.plist settings. so i added sssad <key>loadlib40</key> <string>sssad</string> restarted pd, but the help files still couldn't create.please file bug reports for each of these.
done
- name clash
[curve] Gem vs. mapping probably some more
Yeah, that's been around a lot time.
what are the goals? which externals are supposed to work on
default? are that the ones in the plist? maybe we should focus on
them (before i start to open all help files :) )The goal is to fine bugs and fix them :). Some of the bigger well- known problems will have to wait until the next release. The
externals in the plist should work without a namespace prefix.
All included externals should work.uhm . now i filed bug reports for helpfiles of externals that are
not on the plist. but they work with namespace prefix (except iem_t3)
thanks for all your work and thanks to all the other devs too!
Thanks for your bug reports and your work with Pd! .hc
eni
------- 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
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
on my 10.4 intel mac, the zexy [>~ ], [<~ ], [&&~ ], [||~],[==~] objects aren't working.
other objects in zexy (such as [abs~], [msgfile], etc) work fine.
more zexy troubles:
[l2s] doesn't work, unless a [list2symbol] object is created first.
i made a patch with a single l2s object in it, and the object cannot be created when i load the patch.
a patch with a single [list2symbol] object loads fine.
a patch with a single [list2symbol] object created first, and then a [l2s] object created second loads fine.
but a patch with the [l2s] created first and the [list2symbol] created second won't load the [l2s]
same thing with [s2l]
seems to be general trouble with the naming of the zexy objects that have more than one name.
next error:
i keep getting messages "pd_vmess: only 5 allowed" when opening subpatches
Yeah, I get that too, but I haven't found the source, and it doesn't
seem to cause any problems.
.hc
On May 18, 2008, at 8:34 PM, hard off wrote:
next error:
i keep getting messages "pd_vmess: only 5 allowed" when opening
subpatches
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
Aliases currently aren't supported in Pd-extended. You have to use
the real objectclass name, in this case "list2symbol".
.hc
On May 18, 2008, at 8:31 PM, hard off wrote:
more zexy troubles:
[l2s] doesn't work, unless a [list2symbol] object is created first.
i made a patch with a single l2s object in it, and the object
cannot be created when i load the patch.a patch with a single [list2symbol] object loads fine.
a patch with a single [list2symbol] object created first, and then
a [l2s] object created second loads fine.but a patch with the [l2s] created first and the [list2symbol]
created second won't load the [l2s]same thing with [s2l]
seems to be general trouble with the naming of the zexy objects
that have more than one name.
"[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
I have noticed this in older patches using mux as well. When I upgraded to 0.40.3 those objects were borken, although once I renamed them to multiplex, everything is fine.
On Mon, 2008-05-19 at 03:31 +0900, hard off wrote:
more zexy troubles:
[l2s] doesn't work, unless a [list2symbol] object is created first.
i made a patch with a single l2s object in it, and the object cannot be created when i load the patch.
a patch with a single [list2symbol] object loads fine.
a patch with a single [list2symbol] object created first, and then a [l2s] object created second loads fine.
but a patch with the [l2s] created first and the [list2symbol] created second won't load the [l2s]
same thing with [s2l]
seems to be general trouble with the naming of the zexy objects that have more than one name.
Dan Wilcox robotcowboy.com
Le 18 mai 08 à 19:57, hard off a écrit :
on my 10.4 intel mac, the zexy [>~ ], [<~ ], [&&~ ], [||~],[==~]
objects aren't working.
Same thing here on 10.4.11 PowerBook G4. Enter 'zexy' before like
[zexy/>~] doesn't work too.
++
Jack
other objects in zexy (such as [abs~], [msgfile], etc) work fine.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
by the way, it looks really fantastic now. hans, the work you did on the fonts etc, has been really worthwhile.
big ups!
Thanks, I am glad you like it. The design was a group effort, though
I suppose I did almost all of the coding. My aim was to make it
easier to read patches. Hopefully I acheived that goal without
breaking things in the process.
.hc
On May 19, 2008, at 2:27 PM, hard off wrote:
by the way, it looks really fantastic now. hans, the work you did
on the fonts etc, has been really worthwhile.big ups!
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
That's due to the troubles with the hexloader. I just reopened the
bug report:
http://sourceforge.net/tracker/index.php? func=detail&aid=1637460&group_id=55736&atid=478070
http://lists.puredata.info/pipermail/pd-dev/2008-05/011653.html
.hc
On May 18, 2008, at 7:57 PM, hard off wrote:
on my 10.4 intel mac, the zexy [>~ ], [<~ ], [&&~ ], [||~],[==~]
objects aren't working.other objects in zexy (such as [abs~], [msgfile], etc) work fine.
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
Hans-Christoph Steiner wrote:
On May 17, 2008, at 12:02 PM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
On May 13, 2008, at 10:06 AM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
Hey all, I've been fixing quite a lot of bugs in preparation of making the Pd- extended 0.40.3 release. It's getting pretty much ready, so please test it heavily so we can find any outstanding bugs! Jack just pointed out that pdp on Mac OS X/PowerPC is having problems loading videos, and is crashing, so I am working on that now.
some objects can't create. i think that all of them are know problems. for me not be able to use <~ and >~ is _most_ annoying (hexloader-something?). i know there are workarounds with expr. not including iem-t3 lib is a loss but i can live without it. thou it makes around 5 nice netpd patches not usable anymore.
You can now file bug reports from the Help menu in Pd-extended. Please file a bug report for this.
i wrote a bug report for iem_t3 i'm not sure about the hexloader. i found this: http://sourceforge.net/tracker/index.php?func=detail&aid=1637460&gro... should i file a new bug report?
hexloader should be included in tomorrow's build. Please test it. The t3 stuff should be in today's build.
for some reason the osx i386 didn't build. http://autobuild.puredata.info/auto-build/2008-05-19/logs/2008-05-19_03.15.0...
so i tested with Pd-0.40.3-extended-20080519-macosx104-powerpc in Rosetta mode.
it3_delay and the other t3's work!
the hexloader seems to work too
but [<~] is now doing a:
load_object: Symbol "0x3e0x7e_setup" not found expr~ $v1 > $v2 ... couldn't create
i don't understand the issue here. it seems to load an abstraction 0x3c0x7e.pd with [expr~ $v1 > $v2] and expr~ somehow doesn't create.
when i load a plain [expr~] it _can_ create. and after doing so [<~] is working as well...
should i file a bugreport for... uhm.. expr or 0x3c0x7e.pd ?
i found a new one in the Help/Search input field i can't write anything. should i file a bug report for this?
eni
On May 19, 2008, at 6:04 PM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
On May 17, 2008, at 12:02 PM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
On May 13, 2008, at 10:06 AM, Enrique Erne wrote:
Hans-Christoph Steiner wrote:
Hey all, I've been fixing quite a lot of bugs in preparation of making
the Pd- extended 0.40.3 release. It's getting pretty much
ready, so please test it heavily so we can find any
outstanding bugs! Jack just pointed out that pdp on Mac OS X/PowerPC is having
problems loading videos, and is crashing, so I am working on
that now.some objects can't create. i think that all of them are know
problems. for me not be able to use <~ and >~ is _most_
annoying (hexloader-something?). i know there are workarounds
with expr. not including iem-t3 lib is a loss but i can live without it.
thou it makes around 5 nice netpd patches not usable anymore.You can now file bug reports from the Help menu in Pd-extended.
Please file a bug report for this.i wrote a bug report for iem_t3 i'm not sure about the hexloader. i found this: http://sourceforge.net/tracker/index.php? func=detail&aid=1637460&group_id=55736&atid=478070 should i file
a new bug report?hexloader should be included in tomorrow's build. Please test
it. The t3 stuff should be in today's build.for some reason the osx i386 didn't build. http://autobuild.puredata.info/auto-build/2008-05-19/logs/ 2008-05-19_03.15.00_darwin_macosx104-i386_pd-extended_run-automated- builder.txt
so i tested with Pd-0.40.3-extended-20080519-macosx104-powerpc in
Rosetta mode.it3_delay and the other t3's work!
the hexloader seems to work too
but [<~] is now doing a:
load_object: Symbol "0x3e0x7e_setup" not found expr~ $v1 > $v2 ... couldn't create
i don't understand the issue here. it seems to load an abstraction
0x3c0x7e.pd with [expr~ $v1 > $v2] and expr~ somehow doesn't create.when i load a plain [expr~] it _can_ create. and after doing so
[<~] is working as well...should i file a bugreport for... uhm.. expr or 0x3c0x7e.pd ?
http://sourceforge.net/tracker/index.php? func=detail&aid=1637460&group_id=55736&atid=478070
i found a new one in the Help/Search input field i can't write
anything. should i file a bug report for this?
Is the leopard? Feel free to file bug reports.
.hc
eni
http://at.or.at/hans/
[l2s] used to work fine in 0.39 extended, you sure it's not possible to get alias's working?
I am sure it's possible, it is just that no one has done the work to
make it possible. I don't use aliases myself, so I couldn't tell you
what might have changed there.
.hc
On May 20, 2008, at 12:38 AM, hard off wrote:
[l2s] used to work fine in 0.39 extended, you sure it's not
possible to get alias's working?
If you are not part of the solution, you are part of the problem.
well, if alias's and the zexy objects don't work, then i don't think you should release this, because it will break compatibility with a lot of old patches created in 0.39
i dont know how to fix those things, but recently i was given 30 uk pounds for helping someone with pd university homework so i can donate that to the cause if both those things get fixed.
It turns out that IOhannes deleted these aliases, they were in the
flatspace library. I restored them:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9858
.hc
On May 20, 2008, at 1:48 PM, hard off wrote:
well, if alias's and the zexy objects don't work, then i don't
think you should release this, because it will break compatibility
with a lot of old patches created in 0.39i dont know how to fix those things, but recently i was given 30 uk
pounds for helping someone with pd university homework so i can
donate that to the cause if both those things get fixed.
All information should be free. - the hacker ethic
Hans-Christoph Steiner wrote:
It turns out that IOhannes deleted these aliases, they were in the flatspace library.
it turns out that georg has implemented an alias system which should be used with zexy.
I restored them:
i thought flatspace was abandoned?
having zexy's [list2symbol] in zexy/ and zexy's [l2s] in flatspace/ is surely a good way to confuse everybody.
fgmasdr IOhannes
On May 20, 2008, at 7:33 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
It turns out that IOhannes deleted these aliases, they were in the
flatspace library.it turns out that georg has implemented an alias system which
should be used with zexy.
Hmm, I guess it wasn't implemented in Pd-extended. In any case,
let's leave flatspace like this for backwards compatibility.
I restored them:
i thought flatspace was abandoned?
having zexy's [list2symbol] in zexy/ and zexy's [l2s] in flatspace/
is surely a good way to confuse everybody.
flatspace is deprecated, but for backwards compatibility, it should
be left alone.
.hc
fgmasdr IOhannes
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
now i have a completely different problem:
there have been no autobuilds for intel mac in the last couple of days. the last one was on the 18th of may.
There is one now, the Mac/Intel machine seems to be a little testy,
so I need to massage it now and then.
http://autobuild.puredata.info/auto-build/2008-05-21/
I think I sorted out the import/declare stuff, I am committing that
now. So I hope people will test it tomorrow.
.hc
On May 21, 2008, at 12:38 AM, hard off wrote:
now i have a completely different problem:
there have been no autobuilds for intel mac in the last couple of
days. the last one was on the 18th of may.
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
I had to switch to a current nightly-build because the pd-extended 0.39.3 is not willing ot work without clicks with jack and my old mbox under os 10.4.8. Compared to the older release all movements and draggings of objects (especially GUI an GOP objects) are clearly slower. When the CPU load exceeds ca. 35-40% on my Powerbook G4 these visual delays are growing increasingly. Is this only the weakness of my computer?
Achim
Hans-Christoph Steiner schrieb:
Hey all,
I've been fixing quite a lot of bugs in preparation of making the Pd- extended 0.40.3 release. It's getting pretty much ready, so please
test it heavily so we can find any outstanding bugs!Jack just pointed out that pdp on Mac OS X/PowerPC is having problems
loading videos, and is crashing, so I am working on that now..hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Well, it seems that the new look is slower. I think it should be
possible to speed things up, but not for this release. I've used
this version a bit on a G4 867 and didn't see a big difference, do
you have any specific details?
.hc
On May 21, 2008, at 11:09 PM, Achim Bornhoeft wrote:
I had to switch to a current nightly-build because the pd-extended
0.39.3 is not willing ot work without clicks with jack and my old
mbox under os 10.4.8. Compared to the older release all movements and draggings of
objects (especially GUI an GOP objects) are clearly slower. When
the CPU load exceeds ca. 35-40% on my Powerbook G4 these visual
delays are growing increasingly. Is this only the weakness of my computer?Achim
Hans-Christoph Steiner schrieb:
Hey all, I've been fixing quite a lot of bugs in preparation of making the
Pd- extended 0.40.3 release. It's getting pretty much ready, so
please test it heavily so we can find any outstanding bugs! Jack just pointed out that pdp on Mac OS X/PowerPC is having
problems loading videos, and is crashing, so I am working on that
now. .hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list-- Achim Bornhoeft .- Neckarhalde 38, D-72070 Tuebingen -.-. tel/fax +49 (0)7071 942745 -... mobil +49 (0)179 6936930 skype:achim.bornhoeft?call --
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
I forgot to mention, on my old G4 800 PowerBook, everything ran much
faster and smoother running Debian than running Mac OS X. It was
really a big difference between the two. I recommend trying Ubuntu
or Debian on your old G4. Pd runs better on GNU/Linux anyhow.
.hc
On May 21, 2008, at 11:09 PM, Achim Bornhoeft wrote:
I had to switch to a current nightly-build because the pd-extended
0.39.3 is not willing ot work without clicks with jack and my old
mbox under os 10.4.8. Compared to the older release all movements and draggings of
objects (especially GUI an GOP objects) are clearly slower. When
the CPU load exceeds ca. 35-40% on my Powerbook G4 these visual
delays are growing increasingly. Is this only the weakness of my computer?Achim
Hans-Christoph Steiner schrieb:
Hey all, I've been fixing quite a lot of bugs in preparation of making the
Pd- extended 0.40.3 release. It's getting pretty much ready, so
please test it heavily so we can find any outstanding bugs! Jack just pointed out that pdp on Mac OS X/PowerPC is having
problems loading videos, and is crashing, so I am working on that
now. .hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list-- Achim Bornhoeft .- Neckarhalde 38, D-72070 Tuebingen -.-. tel/fax +49 (0)7071 942745 -... mobil +49 (0)179 6936930 skype:achim.bornhoeft?call --
All information should be free. - the hacker ethic
another small glitch on macintel,
'quit pd extended' only works by closing the console window, but doesn't work from the menu at the top of the screen.
On Mac OS X 10.4.11 using Pd-extended v 0.40.3-20080522, I cannot
reproduce that. All of the various ways to quit Pd-extended worked
for me.
.hc
On May 22, 2008, at 4:08 PM, hard off wrote:
another small glitch on macintel,
'quit pd extended' only works by closing the console window, but
doesn't work from the menu at the top of the screen.
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
On 22/05/2008, at 17.19, Hans-Christoph Steiner wrote:
On Mac OS X 10.4.11 using Pd-extended v 0.40.3-20080522, I cannot
reproduce that.
same here.
But i got:
/path/to/pdlua/src/lua.pd_darwin: dlopen(/path/to/pdlua/src/ lua.pd_darwin, 10): Symbol not found: _garray_getfloatwords Referenced from: /path/to/pdlua/src/lua.pd_darwin Expected in: flat namespace
It loads fine in Pd-0.41-4 with the same prefs where "Startup..."
contains 'lua' and "Path..." contains '/path/to/pdlua/src'. The Pdlua
binaries lives in '/path/to/pdlua/src'.
Submitted as bug #1969695
ok, tracked down where i am getting that error,
if you have a nested abstraction, and edit that abstraction,
then closing the parent window without saving disables the 'quit pd-extended' option in the menubar.
example is attached.
On May 23, 2008, at 11:05 AM, Steffen Juul wrote:
On 23/05/2008, at 10.30, hard off wrote:
if you have a nested abstraction, and edit that abstraction, then closing the parent window without saving disables the 'quit pd- extended' option in the menubar.
Hmm. I can't reproduce. Pd-extended 0.40.3 22th of May edition.
Guess it's a tricky one. I can't reproduce this on Pd-extended
0.40.3-20080522 on Ubuntu/Hardy or Mac OS X 10.4.11/Intel.
.hc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
hmm, still happens here.
no big problem though, i guess.
it would be better to find the source of that pd_vmess error, even though it doesn't really seem to do anything much,.