Pd-dev May 2008

pd-dev@lists.iem.at

20 participants
187 discussions

Re: [PD-dev] the future of [declare] and canvas_savedeclarationsto()
by Hans-Christoph Steiner 23 May '08

23 May '08

If you really want to get into realpath(): https://www.securecoding.cert.org/confluence/display/seccode/FIO02-A. +Canonicalize+path+names+originating+from+untrusted+sources .hc > On May 22, 2008, at 10:06 PM, Hans-Christoph Steiner wrote: > >> >> To quote the whole text: >> >> Avoid using this function. It is broken by design since (unless >> using the non- >> standard resolved_path == NULL feature) it is impossible to >> determine a suitable >> size for the output buffer, resolved_path. According to POSIX a >> buffer of size >> PATH_MAX suffices, but PATH_MAX need not be a defined constant, >> and may have to >> be obtained using pathconf(). And asking pathconf() does not >> really help, since >> on the one hand POSIX warns that the result of pathconf() >> may be huge and >> unsuitable for mallocing memory. And on the other hand pathconf >> () may return -1 >> to signify that PATH_MAX is not bounded. >> >> I think whoever wrote that man page is really splitting hairs >> there, the FreeBSD/Mac OS X man page has no complaints about it. >> They are complaining that PATH_MAX _might_ not be defined. But on >> GNU/Linux, MinGW, and FreeBSD/Mac OS X, FILENAME_MAX _is_ >> defined. So just use FILENAME_MAX to allocate the buffer that >> realpath() uses (which was already happening anyway in s_main.c, >> but with MAXPDSTRING instead). It's a widely implemented POSIX >> function, how much more standard do you want? ;) >> >> I think that Pd should give reliable information in the publically >> defined API (ok, s_stuff.h, but still). For example, it makes >> life easier in a lot of ways if you can count on sys_libdir being >> an absolute path, rather than making every other bit of code that >> might every use a path that is based on sys_libdir check to make >> sure that it is indeed absolute. The vast majority of the time, >> sys_libdir is an absolute path, and AFAIK, on Windows it is always >> an absolute path. >> >> .hc >> >> >> On May 22, 2008, at 9:44 PM, Miller Puckette wrote: >> >>> I finally realized realpath() is a pre-existing function. (I >>> imagined >>> it was sitting in another source file that didn't make it to the >>> patch) >>> >>> but.. "man realpath" says "Avoid using this function. It is >>> broken by design..." >>> so I'm sceptical of the idea. Anyway, why can't [import] just >>> make the >>> call if it needs it? >>> >>> cheers >>> M >>> >>> >>> On Thu, May 22, 2008 at 09:33:14PM +0200, Hans-Christoph Steiner >>> wrote: >>>> >>>> The only real change to s_main.c in that path is the addition of >>>> realpath(). It seems that the function there is just copying the >>>> strings back and forth between sbuf and sbuf2, so I just added one >>>> more iteration of that back and forth for realpath(). >>>> >>>> .hc >>>> >>>> On May 22, 2008, at 9:25 PM, Miller Puckette wrote: >>>> >>>>> I might have missed it, but I didn't see that realpath() itself >>>>> made it into >>>>> the patch... ? >>>>> >>>>> M >>>>> >>>>> On Thu, May 22, 2008 at 09:22:12PM +0200, Hans-Christoph Steiner >>>>> wrote: >>>>>> >>>>>> The realpath() is definitely related. If you start Pd using a >>>>>> relative path, like I do when doing dev work (e.g. make && ../ >>>>>> bin/ >>>>>> pd), then sys_libdir will be a relative path. That means it is >>>>>> impossible to make absolute paths using sys_libdir, which is >>>>>> what I >>>>>> need to do to make [import] work, or loading libdirs with >>>>>> [declare - >>>>>> lib] and the libdir loader. >>>>>> >>>>>> I can't see any problems that realpath() might cause. >>>>>> >>>>>> .hc >>>>>> >>>>>> On May 22, 2008, at 8:45 PM, Miller Puckette wrote: >>>>>> >>>>>>> OK, I took most of the patch (not the "realpath()" call which >>>>>>> seems >>>>>>> unrelated) and uploaded to SVN, unless I'm mistaken. >>>>>>> >>>>>>> cheers >>>>>>> Miller >>>>>>> >>>>>>> On Wed, May 21, 2008 at 08:22:23PM +0200, Hans-Christoph Steiner >>>>>>> wrote: >>>>>>>> >>>>>>>> I was looking into this a bit more, and from what I can >>>>>>>> tell, the >>>>>>>> canvas-local path (ce_path) is always relative to the path >>>>>>>> of the >>>>>>>> parent patch. Here's the commit for pd-extended that adds >>>>>>>> support >>>>>>>> for absolute paths: >>>>>>>> >>>>>>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data? >>>>>>>> view=rev&revision=9862 >>>>>>>> >>>>>>>> Also, I submitted a patch: >>>>>>>> >>>>>>>> http://sourceforge.net/tracker/index.php? >>>>>>>> func=detail&aid=1917574&group_id=55736&atid=478072 >>>>>>>> >>>>>>>> .hc >>>>>>>> >>>>>>>> >>>>>>>> On May 19, 2008, at 9:42 PM, Hans-Christoph Steiner wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> I think I fixed the full paths bug, here's the commit: >>>>>>>>> >>>>>>>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data? >>>>>>>>> view=rev&revision=9856 >>>>>>>>> >>>>>>>>> .hc >>>>>>>>> >>>>>>>>> On May 19, 2008, at 8:03 PM, Hans-Christoph Steiner wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think this issue is pretty clear, and the languages that >>>>>>>>>> I know >>>>>>>>>> would fall along the lines of "each patch/abstraction has >>>>>>>>>> its own >>>>>>>>>> namespace" or in other words "#include only affects the >>>>>>>>>> one .c >>>>>>>>>> file", "import only affects the one .py file", etc. So I >>>>>>>>>> agree >>>>>>>>>> with Frank. Global settings are global, and canvas-local >>>>>>>>>> settings >>>>>>>>>> are local to the original file. >>>>>>>>>> >>>>>>>>>> The "semi-functional" part is the full paths that Marius >>>>>>>>>> mentioned. >>>>>>>>>> >>>>>>>>>> Then the other question is how to use something like "#X >>>>>>>>>> declare"/ >>>>>>>>>> canvas_savedeclarationsto() in externals. I'd like to >>>>>>>>>> create an >>>>>>>>>> [import] modelled after Python's import does, so I'd like >>>>>>>>>> to use >>>>>>>>>> "#X declare"/canvas_savedeclarationsto() with it. >>>>>>>>>> >>>>>>>>>> .hc >>>>>>>>>> >>>>>>>>>> On May 19, 2008, at 6:33 PM, Miller Puckette wrote: >>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I use 'declare' all the time.. don't think it's >>>>>>>>>>> semifunctional at >>>>>>>>>>> all. >>>>>>>>>>> I think the questions about how declares should act inside >>>>>>>>>>> abstractions >>>>>>>>>>> are hard to resolve; in my own usage (and in the way I >>>>>>>>>>> suggest >>>>>>>>>>> others might >>>>>>>>>>> want to use declare) it's always in the main patch, as a >>>>>>>>>>> way to >>>>>>>>>>> show the >>>>>>>>>>> patch what libraries, etc, it needs. >>>>>>>>>>> >>>>>>>>>>> cheers >>>>>>>>>>> Miller >>>>>>>>>>> >>>>>>>>>>> On Mon, May 19, 2008 at 06:28:31PM +0200, Hans-Christoph >>>>>>>>>>> Steiner >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hey, >>>>>>>>>>>> >>>>>>>>>>>> So I am diving into the whole canvas-local namespace and >>>>>>>>>>>> [declare] >>>>>>>>>>>> issue these days. I like the new "#X declare"/ >>>>>>>>>>>> canvas_savedeclarationsto() functionality, I think it >>>>>>>>>>>> could be >>>>>>>>>>>> useful >>>>>>>>>>>> for a lot of things. I was thinking of making an API to >>>>>>>>>>>> use >>>>>>>>>>>> it in >>>>>>>>>>>> externals, something like sys_register_loader(). I have >>>>>>>>>>>> two >>>>>>>>>>>> questions, first, how entrenched is the current behavior of >>>>>>>>>>>> [declare]? It currently is only semi-functional, and I >>>>>>>>>>>> think few >>>>>>>>>>>> people use it. >>>>>>>>>>>> >>>>>>>>>>>> The second is how to structure this for general use. I >>>>>>>>>>>> have >>>>>>>>>>>> thought >>>>>>>>>>>> of two ways: >>>>>>>>>>>> >>>>>>>>>>>> - make "declare" the key word and allow other >>>>>>>>>>>> objectclasses to >>>>>>>>>>>> have >>>>>>>>>>>> their own custom "#X declare" data. >>>>>>>>>>>> >>>>>>>>>>>> - allow objectclasses to register their own declaration key >>>>>>>>>>>> words, >>>>>>>>>>>> like [import] could have "#X import". >>>>>>>>>>>> >>>>>>>>>>>> The first would mean changing the behavior of [declare], >>>>>>>>>>>> the >>>>>>>>>>>> second >>>>>>>>>>>> could lead to a big mess... >>>>>>>>>>>> >>>>>>>>>>>> .hc >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ----------------------------------------------------------- >>>>>>>>>>>> ---- >>>>>>>>>>>> -- >>>>>>>>>>>> -- >>>>>>>>>>>> ----- >>>>>>>>>>>> ---- >>>>>>>>>>>> >>>>>>>>>>>> Man has survived hitherto because he was too ignorant to >>>>>>>>>>>> know >>>>>>>>>>>> how to >>>>>>>>>>>> realize his wishes. Now that he can realize them, he must >>>>>>>>>>>> either >>>>>>>>>>>> change them, or perish. -William Carlos Williams >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> PD-dev mailing list >>>>>>>>>>>> PD-dev(a)iem.at >>>>>>>>>>>> http://lists.puredata.info/listinfo/pd-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>> ---- >>>>>>>>>> -- >>>>>>>>>> -- >>>>>>>>>> ------- >>>>>>>>>> >>>>>>>>>> News is what people want to keep hidden and everything >>>>>>>>>> else is >>>>>>>>>> publicity. - Bill Moyers >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -------------------------------------------------------------- >>>>>>>>> ---- >>>>>>>>> -- >>>>>>>>> -- >>>>>>>>> ------ >>>>>>>>> >>>>>>>>> You can't steal a gift. Bird gave the world his music, and >>>>>>>>> if you >>>>>>>>> can hear it, you can have it. - Dizzy Gillespie >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------- >>>>>>>> ---- >>>>>>>> -- >>>>>>>> --- >>>>>>>> ---- >>>>>>>> >>>>>>>> News is what people want to keep hidden and everything else is >>>>>>>> publicity. - Bill Moyers >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> PD-dev mailing list >>>>>>>> PD-dev(a)iem.at >>>>>>>> http://lists.puredata.info/listinfo/pd-dev >>>>>> >>>>>> >>>>>> >>>>>> ----------------------------------------------------------------- >>>>>> ---- >>>>>> --- >>>>>> ---- >>>>>> >>>>>> News is what people want to keep hidden and everything else is >>>>>> publicity. - Bill Moyers >>>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------- >>>> ----- >>>> ---- >>>> >>>> "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 >>>> >>>> >>>> >> >> >> >> --------------------------------------------------------------------- >> ------- >> >> If you are not part of the solution, you are part of the problem. >> >> > > > > ------------------------------------------------------------------------ ---- You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie

2 2

[ pure-data-Patches-1942258 ] jack fixes and enhancements
by SourceForge.net 23 May '08

23 May '08

Patches item #1942258, was opened at 2008-04-14 10:19 Message generated for change (Comment added) made by reakin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1942258&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix Status: Open Resolution: None Priority: 7 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: jack fixes and enhancements Initial Comment: the jack-implementation in Pd has several flaws: - maximum number of ports = 32 (hardcoded) - Pd crashes when you request more than 32 channels - jackd has to run before Pd is started - Pd doesn't like jackd quitting - maximum of 2 parallel Pd's connecting to jack - ... i believe that the attached patch fixes most of these issues: - raises the maximum number of ports to 1024 (this is the maximum number of ports qjackctl allows me to select for the jackd) - when initializing ports, Pd checks whether a port was successfully created; if not it doesn't add more ports but leaves this as the maximum it could get from jackd (no more crashes with high number of ports) - Pd automatically starts a default jackd if none is running yet - when the jackd quits while Pd is running, it sets the jack_client to 0, efficiently preventing hangs. jackd is restarted automatically when selected via the audio-settings - Pd tests the return status when trying to connect to jackd; if it finds that the name is already given it tries alternative names; if initialization failed for other reasons, it just fails. i have tested this on my debian unstable/testing system that provides libjack-dev 0.109.2-1.1 ---------------------------------------------------------------------- Comment By: Rich E (reakin) Date: 2008-05-23 12:13 Message: Logged In: YES user_id=1586621 Originator: NO This patch makes pd unusable while running jack in realtime with the following system: Ubuntu Gusty, r@pal:~$ uname -a Linux pal 2.6.22-14-rt #1 SMP PREEMPT RT Tue Feb 12 09:57:10 UTC 2008 i686 GNU/Linux any version of pd-extended autobuilds from April 16th onwards. Pd-vanilla does not have the same problem. Exact sound symptons are: Periodic glitches in audio, which is occasionally corrected when another application is attached to jack (probably resetting the audio chain), but the glitches return shortly. It only occurs when running jack in real-time mode. Here is a posting on the pd-list where I was discussing this issue: http://lists.puredata.info/pipermail/pd-list/2008-05/062449.html ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-15 14:29 Message: Logged In: YES user_id=27104 Originator: NO checked this patch into branches/pd-extended/0.40: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=9702 ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2008-04-14 10:21 Message: Logged In: YES user_id=564396 Originator: YES i raised priority a bit, as the current implementation makes Pd unusable with highly multichannel systems (e.g. using 64 channels) and jack ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1942258&group_…

1 0

[ pure-data-Bugs-1970490 ] apple/sms don't work on macbook
by SourceForge.net 23 May '08

23 May '08

Bugs item #1970490, was opened at 2008-05-23 15:42 Message generated for change (Settings changed) made by stffn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1970490&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: externals Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: stffn (stffn) Assigned to: Nobody/Anonymous (nobody) Summary: apple/sms don't work on macbook Initial Comment: This is Mac OS X.4.11. Macbook 1st. gen. It outputs (43,0,93) no matter how i tilt the computer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1970490&group_…

1 0

[ pure-data-Bugs-1970490 ] apple/sms don't work on macbook
by SourceForge.net 23 May '08

23 May '08

Bugs item #1970490, was opened at 2008-05-23 15:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1970490&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: stffn (stffn) Assigned to: Nobody/Anonymous (nobody) Summary: apple/sms don't work on macbook Initial Comment: This is Mac OS X.4.11. Macbook 1st. gen. It outputs (43,0,93) no matter how i tilt the computer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1970490&group_…

1 0

[ pure-data-Bugs-1942204 ] pdpedia Captcha
by SourceForge.net 23 May '08

23 May '08

Bugs item #1942204, was opened at 2008-04-14 11:49 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1942204&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pdpedia Group: None >Status: Pending Resolution: None Priority: 7 Private: No Submitted By: oli44 (oli44) Assigned to: Nobody/Anonymous (nobody) Summary: pdpedia Captcha Initial Comment: Feature request: is it possible to install a captcha system to avoid pdpedia being spammed so outrageously ? maybe useful link : http://wiki.seds.org/index.php/MediaWiki:Captcha ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-23 06:29 Message: Logged In: YES user_id=27104 Originator: NO If you think captchas will stop spam, it is unfortunately not true. Here's one of the many pages about breaking captchas: http://www.cs.sfu.ca/~mori/research/gimpy/ I think we should still follow wikipedia's example and delete spam as it comes. It's really not hard to do. We should just have more people setup and willing to do it. I am setting this bug report to "Pending", so unless someone wants to setup captchas, it'll be closed within two weeks. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-05-23 05:13 Message: Logged In: NO hmm, the last 10days on pdpedia shows 3 different types of activity: - 3 active contributions - 3 spam removals - 48 spams luckily only "active (development status)â" and "Talk:Main Pageâ" were hit. to whom should pdpedia related bugs be assigned? ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2008-04-16 05:00 Message: Logged In: YES user_id=564396 Originator: NO i checked the "recent changes" log now, and i see that the spam is back again :( to whom should pdpedia related bugs be assigned? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-15 13:23 Message: Logged In: YES user_id=27104 Originator: NO Any admin can easily delete those junk posts with the 'delete' tab and also protect problem pages. A captcha might help, I haven't seen one for mediawiki before. Check the "recent changes" log now, and you'll see the spam is gone. :) ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2008-04-15 03:15 Message: Logged In: YES user_id=564396 Originator: NO i agree that pdpedia has lost lots of it's initial charme just because of this: according to the "recent changes" page, of the last 376 changes 361 were garbage. luckily most of these garbage changes are targeted on few pages (Template:vanilla has 257 changes; Template:jmmmp has 99 changes) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1942204&group_…

1 0

[ pure-data-Bugs-1942204 ] pdpedia Captcha
by SourceForge.net 23 May '08

23 May '08

Bugs item #1942204, was opened at 2008-04-14 08:49 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1942204&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pdpedia Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: oli44 (oli44) Assigned to: Nobody/Anonymous (nobody) Summary: pdpedia Captcha Initial Comment: Feature request: is it possible to install a captcha system to avoid pdpedia being spammed so outrageously ? maybe useful link : http://wiki.seds.org/index.php/MediaWiki:Captcha ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-05-23 02:13 Message: Logged In: NO hmm, the last 10days on pdpedia shows 3 different types of activity: - 3 active contributions - 3 spam removals - 48 spams luckily only "active (development status)â" and "Talk:Main Pageâ" were hit. to whom should pdpedia related bugs be assigned? ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2008-04-16 02:00 Message: Logged In: YES user_id=564396 Originator: NO i checked the "recent changes" log now, and i see that the spam is back again :( to whom should pdpedia related bugs be assigned? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-15 10:23 Message: Logged In: YES user_id=27104 Originator: NO Any admin can easily delete those junk posts with the 'delete' tab and also protect problem pages. A captcha might help, I haven't seen one for mediawiki before. Check the "recent changes" log now, and you'll see the spam is gone. :) ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2008-04-15 00:15 Message: Logged In: YES user_id=564396 Originator: NO i agree that pdpedia has lost lots of it's initial charme just because of this: according to the "recent changes" page, of the last 376 changes 361 were garbage. luckily most of these garbage changes are targeted on few pages (Template:vanilla has 257 changes; Template:jmmmp has 99 changes) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1942204&group_…

1 0

the future of [declare] and canvas_savedeclarationsto()
by Hans-Christoph Steiner 22 May '08

22 May '08

Hey, So I am diving into the whole canvas-local namespace and [declare] issue these days. I like the new "#X declare"/ canvas_savedeclarationsto() functionality, I think it could be useful for a lot of things. I was thinking of making an API to use it in externals, something like sys_register_loader(). I have two questions, first, how entrenched is the current behavior of [declare]? It currently is only semi-functional, and I think few people use it. The second is how to structure this for general use. I have thought of two ways: - make "declare" the key word and allow other objectclasses to have their own custom "#X declare" data. - allow objectclasses to register their own declaration key words, like [import] could have "#X import". The first would mean changing the behavior of [declare], the second could lead to a big mess... .hc ------------------------------------------------------------------------ ---- Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams

4 21

[ pure-data-Patches-1917574 ] fix absolute path support for [declare] and #X declare
by SourceForge.net 22 May '08

22 May '08

Patches item #1917574, was opened at 2008-03-17 21:01 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1917574&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: marius schebella (mariusschebella) Assigned to: Miller Puckette (millerpuckette) Summary: fix absolute path support for [declare] and #X declare Initial Comment: I am not sure if declare is working the way it is supposed to on OSX the object I am trying to create is [OSCroute]. I can create [oscx/OSCroute], but what I want to accomplish is to avoid the oscx prefix, so I tried [declare -stdpath extra/oscx] [declare -stdpath oscx] [declare -path extra/oscx] [declare -path oscx] [declare -stdlib extra/oscx] [declare -stdlib oscx] [declare -lib extra/oscx] [declare -lib oscx] I even tried [declare -stdpath extra/oscx] in combination with import oscx. and I get a console printout saying [import] loaded library: oscx, but OSCroute ... couldn't create don't know how to track down the error, or if I am maybe doing something wrong. pd-extended-0.40.3-20080222. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-22 15:26 Message: Logged In: YES user_id=27104 Originator: NO (repost of my pd-dev post) The realpath() is definitely related. If you start Pd using a relative path, like I do when doing dev work (e.g. make && ../bin/pd), then sys_libdir will be a relative path. That means it is impossible to make absolute paths using sys_libdir, which is what I need to do to make [import] work, or loading libdirs with [declare -lib] and the libdir loader. I can't see any problems that realpath() might cause. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2008-05-22 13:21 Message: Logged In: YES user_id=313747 Originator: NO I patched 0.42 with th epart of it that dealt with declare... there's something else in the patch that invokes a "realpath" function I don't know about (and I assume won't compile as is) so I ignored that bit. I think I should also update 0.41 since this is a fairly important bug fix and also a safe-looking one. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-21 14:19 Message: Logged In: YES user_id=27104 Originator: NO This patch should add support for absolute paths in [declare] and the #X declare lines in the .pd files. Here's the related commit for Pd-extended: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=9862 File Added: fix_absolute_paths_for_declare-0.41.4.patch ---------------------------------------------------------------------- Comment By: marius schebella (mariusschebella) Date: 2008-05-06 12:45 Message: Logged In: YES user_id=1856112 Originator: YES that's how -stdpath works on os x. it does not work for absolute paths, and seems to be relative to some directory outside of /Applications. I tried all relations with less ../ and from inside /Applications. declare -stdpath ../../../../../../../../Applications/Pd-0.40.3-extended-20080428.app/Contents/Resources/extra/boids maybe this helps. m. ---------------------------------------------------------------------- Comment By: marius schebella (mariusschebella) Date: 2008-05-04 13:35 Message: Logged In: YES user_id=1856112 Originator: YES I just realized that I made some mistakes in the past and that declare actually is working better than I thought. here is what I forgot: 1) declare only takes effect when you open the patch. stupid, I think I read it, but... Some alleged "bugs" were caused by the assumption that it is enough to create a declare object and paths will be set... 2) no absolute paths! absolute paths work for -lib, but not for -path/-stdpath. at least on OS X it is not possible to set absolute paths (or at least I don't know how), all paths have to be relative to Pd (-stdpath) or to the patch (-path). ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 09:38 Message: Logged In: YES user_id=1895440 Originator: NO oops... from some quick fix from before i accidently still had a symbolic link from /home/roman/extra pointing to /usr/local/lib/pd/extra/, that is why it found [bar] in that funny place: /home/roman/extra/foo/bar.pd tried again without the symlink: -------------------------------- tried /home/roman/declare_test.pd and succeeded tried /home/roman/../extra/foo/bar.l_i386 and failed tried /home/roman/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar.l_i386 and failed tried /home/roman/../extra/foo/bar.pd_linux and failed tried /home/roman/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar.pd_linux and failed tried /home/roman/../extra/foo/bar/bar.l_i386 and failed tried /home/roman/bar/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar/bar.l_i386 and failed tried /home/roman/../extra/foo/bar/bar.pd_linux and failed tried /home/roman/bar/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar/bar.pd_linux and failed tried /home/roman/../extra/foo/bar.pd and failed tried /home/roman/bar.pd and failed tried /usr/local/lib/pd/extra/bar.pd and failed tried /home/roman/../extra/foo/bar.pat and failed tried /home/roman/bar.pat and failed tried /usr/local/lib/pd/extra/bar.pat and failed ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 07:49 Message: Logged In: YES user_id=1895440 Originator: NO i just did the same test again on my box, ubuntu dapper i686: tried /home/roman/declare_test.pd and succeeded tried /home/roman/extra/foo/bar.l_i386 and failed tried /home/roman/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar.l_i386 and failed tried /home/roman/extra/foo/bar.pd_linux and failed tried /home/roman/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar.pd_linux and failed tried /home/roman/extra/foo/bar/bar.l_i386 and failed tried /home/roman/bar/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar/bar.l_i386 and failed tried /home/roman/extra/foo/bar/bar.pd_linux and failed tried /home/roman/bar/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar/bar.pd_linux and failed tried /home/roman/extra/foo/bar.pd and succeeded which means: - there is a difference between linux ppc and linux intel - currently linux intel is the _only_ platform where [declare] works as documented. ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 07:20 Message: Logged In: YES user_id=1895440 Originator: NO could we give this issue a higher priority? the longer [declare] is not working correctly, the more confusion it will cause. also it currently cannot be used to create portable patches, that work on every platform with every pd-distro, which i find would be the strong point in using [declare]. ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 07:11 Message: Logged In: YES user_id=1895440 Originator: NO the same test on a ubuntu ppc machine with pd 0.41-4 compiled from source and installed to the default location gave similar results: output from pd-window: ---------------------- tried /home/olivia/declare_test.pd and succeeded tried /home/olivia/extra/foo/bar.l_i386 and failed tried /home/olivia/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar.l_i386 and failed tried /home/olivia/extra/foo/bar.pd_linux and failed tried /home/olivia/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar.pd_linux and failed tried /home/olivia/extra/foo/bar/bar.l_i386 and failed tried /home/olivia/bar/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar/bar.l_i386 and failed tried /home/olivia/extra/foo/bar/bar.pd_linux and failed tried /home/olivia/bar/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar/bar.pd_linux and failed tried /home/olivia/extra/foo/bar.pd and failed tried /home/olivia/bar.pd and failed tried /usr/local/lib/pd/extra/bar.pd and failed tried /home/olivia/extra/foo/bar.pat and failed tried /home/olivia/bar.pat and failed tried /usr/local/lib/pd/extra/bar.pat and failed bar ... couldn't create instantiating [foo/bar] works fine, which means, that installation of [bar] is correct and pd finds it in extra/foo. ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 06:48 Message: Logged In: YES user_id=1895440 Originator: NO while [declare -stdlib] seems to work, [declare -stdpath] doesn't work on windows as well. i created a folder 'foo' into the extra directory and put a file 'bar.pd' in there. my test setup: -------------- pd installation path: D:\programme\pd-0.41\ pd executable: D:\programme\pd-0.41\bin\pd.exe test-abstraction: D:\programme\pd-0.41\extra\foo\bar.pd test-patch: D:\home\declare_test.pd test-patch contains: [declare -stdpath extra/foo] [bar] pd start command: D:\programme\pd-0.41\bin\pd.exe -verbose -open D:\home\declare_test.pd output from pd-window: ---------------------- tried D:\\home\\declare_test.pd and succeeded tried D:\\home\\..\\extra\\foo\\bar.m_i386 and failed tried D:\\home\\bar.m_i386 and failed tried D:\\programme\\pd-0.41\\extra\\bar.m_i386 and failed tried D:\\home\\..\\extra\\foo\\bar.dll and failed tried D:\\home\\bar.dll and failed tried D:\\programme\\pd-0.41\\extra\\bar.dll and failed tried D:\\home\\..\\extra\\foo\\bar\\bar.m_i386 and failed tried D:\\home\\bar\\bar.m_i386 and failed tried D:\\programme\\pd-0.41\\extra\\bar\\bar.m_i386 and failed tried D:\\home\\..\\extra\\foo\\bar\\bar.dll and failed tried D:\\home\\bar\\bar.dll and failed tried D:\\programme\\pd-0.41\\extra\\bar\\bar.dll and failed tried D:\\home\\..\\extra\\foo\\bar.pd and failed tried D:\\home\\bar.pd and failed tried D:\\programme\\pd-0.41\\extra\\bar.pd and failed tried D:\\home\\..\\extra\\foo\\bar.pat and failed tried D:\\home\\bar.pat and failed tried D:\\programme\\pd-0.41\\extra\\bar.pat and failed bar ... couldn't create it looks like [declare -stdpath] is adding the search path relative to the patch instead of relative to pd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1917574&group_…

1 0

[ pure-data-Bugs-1969695 ] pdlua don't load
by SourceForge.net 22 May '08

22 May '08

Bugs item #1969695, was opened at 2008-05-22 17:42 Message generated for change (Comment added) made by stffn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1969695&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v0.40.2 Status: Closed Resolution: None Priority: 5 Private: No Submitted By: stffn (stffn) Assigned to: Nobody/Anonymous (nobody) Summary: pdlua don't load Initial Comment: This is for: Pd version 0.40.3-extended-20080522 (There is no 0.40.2 group to choose from!) My system is Mac OS X.4.11 intel. --- error: --- /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 lua: can't load library -------------- 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'. ---------------------------------------------------------------------- >Comment By: stffn (stffn) Date: 2008-05-22 19:25 Message: Logged In: YES user_id=1658640 Originator: YES I see. My bad. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-22 18:48 Message: Logged In: YES user_id=27104 Originator: NO also, pdlua isn't included in the Pd-extended 0.40.3 release since it is still changing pretty fast. I'm going to close this, since it is because of an addition to the API in 0.41 ---------------------------------------------------------------------- Comment By: ClaudiusMaximus (claudiusmaximus) Date: 2008-05-22 17:47 Message: Logged In: YES user_id=769033 Originator: NO This is a symptom of pdlua being compiled for pd-0.41 but used with pd-0.40. If you compile for pd-0.40 it will load in pd-0.41, however there may be 64bit/array-related bugs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1969695&group_…

1 0

[ pure-data-Patches-1917574 ] fix absolute path support for [declare] and #X declare
by SourceForge.net 22 May '08

22 May '08

Patches item #1917574, was opened at 2008-03-17 18:01 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1917574&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: marius schebella (mariusschebella) Assigned to: Miller Puckette (millerpuckette) Summary: fix absolute path support for [declare] and #X declare Initial Comment: I am not sure if declare is working the way it is supposed to on OSX the object I am trying to create is [OSCroute]. I can create [oscx/OSCroute], but what I want to accomplish is to avoid the oscx prefix, so I tried [declare -stdpath extra/oscx] [declare -stdpath oscx] [declare -path extra/oscx] [declare -path oscx] [declare -stdlib extra/oscx] [declare -stdlib oscx] [declare -lib extra/oscx] [declare -lib oscx] I even tried [declare -stdpath extra/oscx] in combination with import oscx. and I get a console printout saying [import] loaded library: oscx, but OSCroute ... couldn't create don't know how to track down the error, or if I am maybe doing something wrong. pd-extended-0.40.3-20080222. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2008-05-22 10:21 Message: Logged In: YES user_id=313747 Originator: NO I patched 0.42 with th epart of it that dealt with declare... there's something else in the patch that invokes a "realpath" function I don't know about (and I assume won't compile as is) so I ignored that bit. I think I should also update 0.41 since this is a fairly important bug fix and also a safe-looking one. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-21 11:19 Message: Logged In: YES user_id=27104 Originator: NO This patch should add support for absolute paths in [declare] and the #X declare lines in the .pd files. Here's the related commit for Pd-extended: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=9862 File Added: fix_absolute_paths_for_declare-0.41.4.patch ---------------------------------------------------------------------- Comment By: marius schebella (mariusschebella) Date: 2008-05-06 09:45 Message: Logged In: YES user_id=1856112 Originator: YES that's how -stdpath works on os x. it does not work for absolute paths, and seems to be relative to some directory outside of /Applications. I tried all relations with less ../ and from inside /Applications. declare -stdpath ../../../../../../../../Applications/Pd-0.40.3-extended-20080428.app/Contents/Resources/extra/boids maybe this helps. m. ---------------------------------------------------------------------- Comment By: marius schebella (mariusschebella) Date: 2008-05-04 10:35 Message: Logged In: YES user_id=1856112 Originator: YES I just realized that I made some mistakes in the past and that declare actually is working better than I thought. here is what I forgot: 1) declare only takes effect when you open the patch. stupid, I think I read it, but... Some alleged "bugs" were caused by the assumption that it is enough to create a declare object and paths will be set... 2) no absolute paths! absolute paths work for -lib, but not for -path/-stdpath. at least on OS X it is not possible to set absolute paths (or at least I don't know how), all paths have to be relative to Pd (-stdpath) or to the patch (-path). ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 06:38 Message: Logged In: YES user_id=1895440 Originator: NO oops... from some quick fix from before i accidently still had a symbolic link from /home/roman/extra pointing to /usr/local/lib/pd/extra/, that is why it found [bar] in that funny place: /home/roman/extra/foo/bar.pd tried again without the symlink: -------------------------------- tried /home/roman/declare_test.pd and succeeded tried /home/roman/../extra/foo/bar.l_i386 and failed tried /home/roman/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar.l_i386 and failed tried /home/roman/../extra/foo/bar.pd_linux and failed tried /home/roman/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar.pd_linux and failed tried /home/roman/../extra/foo/bar/bar.l_i386 and failed tried /home/roman/bar/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar/bar.l_i386 and failed tried /home/roman/../extra/foo/bar/bar.pd_linux and failed tried /home/roman/bar/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar/bar.pd_linux and failed tried /home/roman/../extra/foo/bar.pd and failed tried /home/roman/bar.pd and failed tried /usr/local/lib/pd/extra/bar.pd and failed tried /home/roman/../extra/foo/bar.pat and failed tried /home/roman/bar.pat and failed tried /usr/local/lib/pd/extra/bar.pat and failed ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 04:49 Message: Logged In: YES user_id=1895440 Originator: NO i just did the same test again on my box, ubuntu dapper i686: tried /home/roman/declare_test.pd and succeeded tried /home/roman/extra/foo/bar.l_i386 and failed tried /home/roman/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar.l_i386 and failed tried /home/roman/extra/foo/bar.pd_linux and failed tried /home/roman/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar.pd_linux and failed tried /home/roman/extra/foo/bar/bar.l_i386 and failed tried /home/roman/bar/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar/bar.l_i386 and failed tried /home/roman/extra/foo/bar/bar.pd_linux and failed tried /home/roman/bar/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar/bar.pd_linux and failed tried /home/roman/extra/foo/bar.pd and succeeded which means: - there is a difference between linux ppc and linux intel - currently linux intel is the _only_ platform where [declare] works as documented. ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 04:20 Message: Logged In: YES user_id=1895440 Originator: NO could we give this issue a higher priority? the longer [declare] is not working correctly, the more confusion it will cause. also it currently cannot be used to create portable patches, that work on every platform with every pd-distro, which i find would be the strong point in using [declare]. ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 04:11 Message: Logged In: YES user_id=1895440 Originator: NO the same test on a ubuntu ppc machine with pd 0.41-4 compiled from source and installed to the default location gave similar results: output from pd-window: ---------------------- tried /home/olivia/declare_test.pd and succeeded tried /home/olivia/extra/foo/bar.l_i386 and failed tried /home/olivia/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar.l_i386 and failed tried /home/olivia/extra/foo/bar.pd_linux and failed tried /home/olivia/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar.pd_linux and failed tried /home/olivia/extra/foo/bar/bar.l_i386 and failed tried /home/olivia/bar/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar/bar.l_i386 and failed tried /home/olivia/extra/foo/bar/bar.pd_linux and failed tried /home/olivia/bar/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar/bar.pd_linux and failed tried /home/olivia/extra/foo/bar.pd and failed tried /home/olivia/bar.pd and failed tried /usr/local/lib/pd/extra/bar.pd and failed tried /home/olivia/extra/foo/bar.pat and failed tried /home/olivia/bar.pat and failed tried /usr/local/lib/pd/extra/bar.pat and failed bar ... couldn't create instantiating [foo/bar] works fine, which means, that installation of [bar] is correct and pd finds it in extra/foo. ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 03:48 Message: Logged In: YES user_id=1895440 Originator: NO while [declare -stdlib] seems to work, [declare -stdpath] doesn't work on windows as well. i created a folder 'foo' into the extra directory and put a file 'bar.pd' in there. my test setup: -------------- pd installation path: D:\programme\pd-0.41\ pd executable: D:\programme\pd-0.41\bin\pd.exe test-abstraction: D:\programme\pd-0.41\extra\foo\bar.pd test-patch: D:\home\declare_test.pd test-patch contains: [declare -stdpath extra/foo] [bar] pd start command: D:\programme\pd-0.41\bin\pd.exe -verbose -open D:\home\declare_test.pd output from pd-window: ---------------------- tried D:\\home\\declare_test.pd and succeeded tried D:\\home\\..\\extra\\foo\\bar.m_i386 and failed tried D:\\home\\bar.m_i386 and failed tried D:\\programme\\pd-0.41\\extra\\bar.m_i386 and failed tried D:\\home\\..\\extra\\foo\\bar.dll and failed tried D:\\home\\bar.dll and failed tried D:\\programme\\pd-0.41\\extra\\bar.dll and failed tried D:\\home\\..\\extra\\foo\\bar\\bar.m_i386 and failed tried D:\\home\\bar\\bar.m_i386 and failed tried D:\\programme\\pd-0.41\\extra\\bar\\bar.m_i386 and failed tried D:\\home\\..\\extra\\foo\\bar\\bar.dll and failed tried D:\\home\\bar\\bar.dll and failed tried D:\\programme\\pd-0.41\\extra\\bar\\bar.dll and failed tried D:\\home\\..\\extra\\foo\\bar.pd and failed tried D:\\home\\bar.pd and failed tried D:\\programme\\pd-0.41\\extra\\bar.pd and failed tried D:\\home\\..\\extra\\foo\\bar.pat and failed tried D:\\home\\bar.pat and failed tried D:\\programme\\pd-0.41\\extra\\bar.pat and failed bar ... couldn't create it looks like [declare -stdpath] is adding the search path relative to the patch instead of relative to pd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1917574&group_…

1 0

← Newer
1
2
3
4
5
6
7
8
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev May 2008