Pd-dev April 2007

pd-dev@lists.iem.at

15 participants
82 discussions

[ pure-data-Bugs-1690125 ] define_build target has invalid bourne shell syntax
by SourceForge.net 20 Apr '07

20 Apr '07

Bugs item #1690125, was opened at 2007-03-28 15:52 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1690125&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: v0.39.2 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Krzysztof Czaja (krzyszcz) Summary: define_build target has invalid bourne shell syntax Initial Comment: In miXed/Makefile.common, in the target define_build, there is some syntax that does not work in a strict bourne shell. It's basically the '[[' syntax that bash uses which is invalid: @if [[ -f build_counter && `id -un` == krzYszcz && \ `date -r build_counter +%j` != `date +%j` ]] ; then \ ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-04-19 22:42 Message: Logged In: YES user_id=27104 Originator: YES AFter banging my head against it a few times, it looks like I managed to fix it in a way that isn't completely ugly. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-03-28 18:24 Message: Logged In: YES user_id=27104 Originator: YES I replaced it with this and it works with strict sh and bash: @if [ -f build_counter ] && [ `id -un` = krzYszcz ] && \ [ `date -r build_counter +%j` != `date +%j` ] ; then \ But now there is a problem in externals/miXed/toxy/Makefile with this line, also not strict sh compatible: @echo -e '// Do not edit this file (edit "$<", and run "make").\ \n//\nputs stderr [concat loading built-in widget definitions]' \ | cat - $< | sed \ -e '1,\|//$$|{p;d;}' \ -e 's/$[\\\"]$/\\\1/g' \ -e 's/^.*$$/\"&\\n\"/' > $@ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1690125&group_…

1 0

[ pure-data-Bugs-1692230 ] compile zexy with regex support in pd-extended
by SourceForge.net 20 Apr '07

20 Apr '07

Bugs item #1692230, was opened at 2007-04-01 02:08 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1692230&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: pd-extended >Group: v0.39.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexandre Quessy (alexandrequessy) >Assigned to: IOhannes m zmölnig (zmoelnig) Summary: compile zexy with regex support in pd-extended Initial Comment: It seems like the default zexy that comes with Pd-extended vanilla is compiled without the regex.h support (for the [regex] object). I saw that on Linux and Mac OS/X 0.39-*. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-04-19 22:41 Message: Logged In: YES user_id=27104 Originator: NO regex.h is installed on all of the auto-build machine. For zexy in Pd-extended, IOhannes replaced the Pd-extended build system that was in place with his own, so I am assigning this to him. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1692230&group_…

1 0

[ pure-data-Bugs-1693284 ] pdp for os x intel
by SourceForge.net 20 Apr '07

20 Apr '07

Bugs item #1693284, was opened at 2007-04-02 19:44 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1693284&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: pd-extended >Group: v0.40.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nobody/Anonymous (nobody) Summary: pdp for os x intel Initial Comment: no objects in the pdp library can be created with nightly build from 04-02-2007. other libraries do not seem to be affected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1693284&group_…

1 0

[ pure-data-Bugs-1701909 ] pidip not included on Mac OS X
by SourceForge.net 20 Apr '07

20 Apr '07

Bugs item #1701909, was opened at 2007-04-16 20:48 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1701909&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: pd-extended Group: v0.39.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) >Assigned to: Nobody/Anonymous (nobody) Summary: pidip not included on Mac OS X Initial Comment: It looks like pidip is not being included in Mac OS X builds, though I can build it manually. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-04-19 22:36 Message: Logged In: YES user_id=27104 Originator: YES Ok, it's getting built and included now, but it dies on libquicktime issues. There is no --disable-quicktime like with PDP... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1701909&group_…

1 0

[ pure-data-Bugs-1702052 ] Gripd example patches wrong location
by SourceForge.net 20 Apr '07

20 Apr '07

Bugs item #1702052, was opened at 2007-04-17 04:51 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1702052&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: pd-extended >Group: v0.39.2 Status: Open >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nobody/Anonymous (nobody) Summary: Gripd example patches wrong location Initial Comment: In the new PD extended 0.39 RC1, when trying to access the "gripd" examples via the browser, the example patches point to /gripd/examples directory Example (gripdExamples.pd): #X msg 21 6 open ../gripd/examples/gripd.gpd; which is a path relative to the pd executable. At the moment the example patches are in the doc/examples/gripd. Two easy solutions are: 1) move the example patches directory to ../gripd/examples/ 2) leave the grips example patches where they are now (../doc/examples/gripd) and edit the patches such that they point to /doc/examples/gripd, like: gripdExamples.pd: #X msg 21 6 open ../doc/examples/gripd.gpd; for all the examples in gripd. Alberto Zin ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-04-19 22:35 Message: Logged In: YES user_id=27104 Originator: NO gripd is currently not maintained by anyone and so it doesn't work so well in newer version. I don't think it would be difficult to get it to work properly in Pd-extended, but I have never used it, so I wouldn't know where to start. I can help anyone with the Pd-extended side of the question. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1702052&group_…

1 0

[ pure-data-Bugs-1702883 ] zexy's >~, <~, ==~ etc objects not loading - OSX
by SourceForge.net 20 Apr '07

20 Apr '07

Bugs item #1702883, was opened at 2007-04-18 08:08 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1702883&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: frey (freynz) Assigned to: Nobody/Anonymous (nobody) Summary: zexy's >~, <~, ==~ etc objects not loading - OSX Initial Comment: On both pd-0.39.2-extended-rc2 and Miller's vanilla pd-0.40-2 under OSX on an Intel MacBook, >~, <~, ==~ objects are not loading, even though the 0x2e0x7e.pd &c. files are present in the path. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-04-19 22:32 Message: Logged In: YES user_id=27104 Originator: NO I can reproduce this on pd-0.39.2-extended-rc1 on Mac/PowerPC with the namespace prefix. But if I use [import zexy], then they work. I attached a patch. File Added: zexy_hexloader.pd ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1702883&group_…

1 0

Re: [PD-dev] [PD] zexy: >~, <~, ==~ not working on osx: hexloader problem?
by IOhannes m zmoelnig 20 Apr '07

20 Apr '07

moved this to pd-dev... Hans-Christoph Steiner wrote: > On Apr 18, 2007, at 11:19 AM, IOhannes m zmoelnig wrote: > >> how should i proceed? > > Hmm, I like the idea of encapsulating the hexloader code, but I think > if the hexloader is a separate loader, then the other loaders won't > benefit from its translation of non-alphanumeric ASCII. I think the > way the loader stuff is implemented, it is just a failover, if the > first loader fails, then the next one tries. I think that the > classname should be the filename not only for objects written in C > and Pd, but also any other language. i agree, but i don't see a way to achieve this. even if the hexloader is in the pd-core there is still no way to use the hex-expansion from within other loaders. > If you are rearchitecting this stuff, I would like to make a > suggestion. What I would also like to see is that the hexloader is > split into two naming schemes: file system, which would translate > only / \ : * ? " < > | and the setup function, which would do the > whole translation. That would make the files a lot more readable. this is basically a good idea. the reason why i did not go the entire way is that i am not sure whether '/ \ : * ? " < > |' is the entire set of forbidden characters on all filesystems. the way i am currently (in the new hexloader loader) doing it, is just trying to expand the classname in several ways and then trying _all_ expansions (including the original classname) as both filenames and setupnames. adding another expansion is just trivial. i don't see any real reason for differentiation between filenames and setup-routines as long as the entire set is tested. (e.g. with class "v*" i am now doing a test for "v*_setup()" in v*.l_i386 and v0x2a.pd_linux even though "v*_setup()" is not a valid functionname in C. i don't think that there is any harm in this. > > If the loader is the route you end up taking, the CVS directory > hierarchy sounds good to me, feel free to move the libdir loader to > it's own folder, or leave it. i think i'll move it and hope to not break things. mfga.sdr IOhanens

2 1

sysloader problem
by IOhannes m zmoelnig 20 Apr '07

20 Apr '07

hi miller, all. i am currently having troubles implementing the hexloader as a system-loader. while things work rather straightforward in external/library land, it stops being trivial when it comes to loading abstractions via a system-loader. (this is needed since the hexloader mainly applies a different objectname<->filename mapping, which should eventually work for abstractions too) the problem is, that in the context of the loader, i have no idea about the arguments for the object instance. unfortunately abstractions do not have the "abstract class" vs "instance" separation like binary objects, so the only way to instantiate them seems to be to directly evaluate them with the arguments available in some "context". ultimately it would be good if patches would be loaded with the same mechanism as other externals within the pd core (this is: with a separate patch_loader() that is registered just like the lib_loader()) a temporary workaround would be some way to access the arguments passed to a yet-unknown object from within the loaders. mfasd.r IOhannes

3 2

d_math.c "break[s] strict-aliasing rules"
by Hans-Christoph Steiner 20 Apr '07

20 Apr '07

So it seems that this bug in d_math.c is triggered by turning on the Apple-recommended optimization flags: http://sourceforge.net/tracker/index.php? func=detail&aid=1692649&group_id=55736&atid=478070 I did notice that there are these warnings in the source. IIRC, optimization generally requires strict aliasing, so it seems that these warnings are probably related to the above bug: d_math.c: In function 'init_rsqrt': d_math.c:79: warning: dereferencing type-punned pointer will break strict-aliasing rules d_math.c: In function 'q8_rsqrt': d_math.c:93: warning: dereferencing type-punned pointer will break strict-aliasing rules d_math.c: In function 'q8_sqrt': d_math.c:101: warning: dereferencing type-punned pointer will break strict-aliasing rules Here are the lines in question: 79: *(long *)(&f) = l; 93: long l = *(long *)(&f); 101: long l = *(long *)(&f); Can anyone speak to what's this for and what it can be replaced with so as to follow "strict-aliasing rules". Maybe we could use something like this instead (from http://www.cs.tut.fi/~jkorpela/ round.html ): #define round(x) ((x) < LONG_MIN-0.5 || (x) > LONG_MAX+0.5 ?\ error() : ((x)>=0?(long)((x)+0.5):(long)((x)-0.5)) This requires that you have #include <limits.h> and that you have an error handling routine called error which is a function of type long. .hc ------------------------------------------------------------------------ ---- kill your television

4 9

pidip on Mac OS X gives Symbol not found: _quicktime_video_length
by Hans-Christoph Steiner 19 Apr '07

19 Apr '07

I am trying to get pidip working in the Mac OS X auto-builds. It is now building beautifully, and automatically including all of the needed dylibs into the Pd.app. But when I try to use it, I get this error /Applications/Pd-0.39.2-extended-rc2.app/Contents/Resources/ Scripts/../extra/pidip.pd_darwin: dlopen(/Applications/Pd-0.39.2- extended-rc2.app/Contents/Resources/Scripts/../extra/pidip.pd_darwin, 10): Symbol not found: _quicktime_video_length Referenced from: /Applications/Pd-0.39.2-extended-rc2.app/Contents/ Resources/Scripts/../extra/pidip.pd_darwin Expected in: dynamic lookup This is using the most recent version of libquicktime that is included in Fink: 0.9.4-1013. My guess is that pidip needs a newer version of libquicktime. Is there any workarounds? .hc ------------------------------------------------------------------------ ---- Access to computers should be unlimited and total. - the hacker ethic

1 0

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

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 April 2007