Pd-dev December 2009

pd-dev@lists.iem.at

16 participants
59 discussions

UTF-8 for pd-devel (again)
by Bryan Jurish 20 Jan '10

20 Jan '10

moin folks, I believe I've finally got pd-devel 0.41-4 using UTF-8 across the board. So far, I've tested message boxes & comments (g_rtext), as well as symbol atoms, and all seems good. I think we can still expect goofiness if someone names an abstraction using a multibyte character when the filesystem isn't UTF-8 encoded (raw 8-bit works for me here too), but I really don't want to open that particular can of worms. So I guess I have 2 questions: (1) what should I call the generic UTF-8 source files? (see my other post) (2) shall I commit these changes to pd-devel/0.41-4, or somewhere else, or just post a diff (ca. 33k, ought to be easier to read now; I've tried to follow the indentation conventions of the source files I modified)? marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jurish(a)ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology

5 13

netsend (and more) crash bug
by Ivica Ico Bukvic 20 Jan '10

20 Jan '10

Hi all, In our recent troubleshooting trying to hunt down a mysterious crash at patch closing we uncovered a bug that appears to be present in pd-extended 0.41.4 and 0.42.5, as well as pd vanilla (svn checked out yesterday). Following is reproducible on Linux 9.04 Ubuntu i386. To reproduce the crash if you run the patch included below (pretty much vanilla version of netsend/netreceive) as follows: #N canvas 511 186 450 322 10; #X floatatom 80 -44 0 0 0 0 - - -; #X floatatom 71 32 0 0 0 0 - - -; #X obj 125 -117 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 74 -177 loadbang; #X obj 71 5 netsend 1; #X floatatom 212 -18 5 0 0 0 - - -; #X obj 214 -44 netreceive 3000 1; #X msg 80 -17 send \$1; #X msg 71 -157 connect 192.168.1.8 3000; #X obj 122 -95 metro 2; #X obj 151 -53 +; #X msg 114 -69 1; #X connect 0 0 7 0; #X connect 0 0 10 1; #X connect 2 0 9 0; #X connect 3 0 8 0; #X connect 4 0 1 0; #X connect 6 0 5 0; #X connect 7 0 4 0; #X connect 8 0 4 0; #X connect 9 0 11 0; #X connect 10 0 0 0; #X connect 11 0 10 0; 1) save the patch and click on "connect" message 2) start the metro 3) close the patch *without* stopping the metro 4) reopen it again, and you'll find pd reporting that the old connection still exists (explained below) 5) at this point you can start the metro again (it should work) 6) however, when closing the patch pd will crash Part of the problem: x->x_fd in netsend_disconnect is the same flag used in netsend_send function, so when one tries to close socket but there is still a stream of data coming in, because x->x_fd is reverted to -1 after the attempt to close the socket, the data keeps coming in through netsend_send function potentially (and I speculate here) preventing socket from closing. This leaves a stale open socket and eventually causes the whole thing to crash. Below is the problematic code. static void netsend_disconnect(t_netsend *x) { if (x->x_fd >= 0) { sys_closesocket(x->x_fd); x->x_fd = -1; outlet_float(x->x_obj.ob_outlet, 0); } } Solution is changing the netsend_disconnect to create a temp value from the x->x_fd, change x->x_fd to -1 to prevent other incoming data from being processed, and only then try to close the socket. This has apparently fixed part of the problem on our end here. Please see x_net.c patch below: --- x_net.c.old 2009-11-18 17:45:24.000000000 -0500 +++ x_net.c 2009-11-18 17:41:38.000000000 -0500 @@ -106,8 +106,9 @@ { if (x->x_fd >= 0) { - sys_closesocket(x->x_fd); - x->x_fd = -1; + int tmp = x->x_fd; + x->x_fd = -1; + sys_closesocket(tmp); outlet_float(x->x_obj.ob_outlet, 0); } } The problem is this fixes crashing in a non-rt version of Pd. The rt version however still suffers sporadically from the same problem. It may take several tries to instigate it, but when it finally occurs, in my case the reopening of the patch at first misbehaves in that whatever I do on canvas with a mouse or keyboard, everything is being reported twice (e.g. clicking on the toggle creates an on and an off event, creating a new object creates two, typing into it creates 2 letters per each keypress, etc.). After that closing the patch crashes pd. I've had this occur before as well but now at least the other bug with open socket is not there any more. Any ideas as to why? Ico

2 5

Re: [PD-dev] [flext] Fwd: fixing Flext for 64-bit?
by Spencer Russell 14 Jan '10

14 Jan '10

Attached is a patch that should make flext buffer handling 64-bit compatible. It adds new wrapper functions buffer::Peek(int index) and buffer::Poke(int index, t_sample value) to access a buffer's data. New externals should uses these instead of accessing the data array directly, because with newer PDs that doesn't work. I've also updated the buffer1 example to use the new API wrappers. The issue is that arrays in PD are of type t_word, which is a union that can contain a variety of data, including pointers. In 32-bit architectures you can pretty much ignore that it's a union because floats and pointers are the same size, but on 64-bit architectures it's important to use the w_float member of the union to access stored floats. This patch shouldn't break any old externals unless they're used with PD > 0.41 (but then they'd be broken, anyways). I don't have access to an OS X machine or Max/MSP, so I've so far only tested this on 64-bit linux/PD. YMMV. Can someone explain to me why pd's arrays are arrays of t_word instead of t_sample? -s- On Thu, Oct 1, 2009 at 10:41 AM, dmotd <dmotd(a)gmx.net> wrote: > hi spencer, > > afaik there hasn't been any progress with > the 64bit translation, i was going to > attempt it last time i needed it but got > distracted along the way - and i sent a > similar message to thomas at the time, so > its going to be on his todo list, but > proabably not a priority. > > i'd be happy to test any changes you > make, and collaborate time permitted. > > ciao, > > dmotd > > Spencer Russell wrote: >> Thought this should probably go to the list: >> >> ---------- Forwarded message ---------- >> From: Spencer Russell <spencer.f.russell(a)gmail.com> >> Date: Tue, Sep 29, 2009 at 11:13 AM >> Subject: Re: fixing Flext for 64-bit? >> To: Thomas Grill <gr(a)grrrr.org> >> >> > >> > Am 29.09.2009 um 15:00 schrieb Spencer Russell: >> > >> >> Hi Thomas, >> >> >> >> I'm writing a Flext external to implement Iannis Xenakis's Dynamic >> >> Stochastic Synthesis, and running into some problems with buffer >> >> handling on my 64-bit system. >> >> >> >> It seems that currently flext uses the deprecated >> >> garray_getfloatarray() function and t_sample arrays, instead of the >> >> new garray_getfloatwords() function with t_word unions. >> >> >> >> Changing the code would make flext incompatible with older versions of >> >> PD, but some other external developers are currently using an #ifdef >> >> workaround to change to the newer API call for PD versions that >> >> support it. >> >> >> >> I was going to get in there and see if i can't get it working in the >> >> flext code, but I wanted to check with you first to see if you had >> >> already done any work on that front. I'll of course send you the diffs >> >> if i get it working. Shouldn't be that hard and i think it should >> >> really only effect the buffer-handling code, but I don't know the >> >> flext codebase that well so there might be some hidden gotchas. >> >> >> >> -spencer >> >> On Tue, Sep 29, 2009 at 9:08 AM, Thomas Grill <gr(a)grrrr.org> wrote: >> > Hi Spencer, >> > i know that this is something i should work on, but my schedule is insanely >> > tight and i don't get to it. >> > So, if you can make any contributions and testing on 64-bit systems i'd be >> > very grateful. >> > I'd also go for the Pd API selecton by #ifdef statements. >> > gr~~~ >> > >> >> As far as i can tell, PD since 0.41 changed arrays to be arrays of >> t_words instead of t_samples or t_floats. >> >> On 32-bit architectures they're all the same size, but on 64-bit >> architectures t_word is 64-bit, while t_sample and t_float are still >> 32-bit. >> >> For a normal PD external, it's pretty easy to just modify the external >> to use t_words, but I'm not sure the best way to modify flext to do >> this without breaking compatibility for externals. One problem is that >> when an external calls mybuffer.Data(), what should they receive? if >> the system is PD newer than 0.41, they should receive a pointer to >> t_word, but MAX or older PD should receive a pointer to t_sample. >> >> The other problem is that accessing an element for newer PD requires >> accessing the w_float member of the t_word union, but the others just >> use the element itself. >> >> There could be some sort of GetValue() wrapper for buffer elements >> that could be made cross-platform, but would break compatibility with >> existing flext externals, so that seems seriously sub-optimal. >> >> thoughts? >> >> -s- >> _______________________________________________ >> http://grrrr.org/ext/flext >> >> flext mailing list >> flext(a)grrrr.org >> http://www.parasitaere-kapazitaeten.net/mailman/listinfo/flext >

2 3

t_sample vs t_float in PDa vs vanilla
by Hans-Christoph Steiner 01 Jan '10

01 Jan '10

I am attempting a merge of the PDa integer code with Pd-vanilla 0.43. Vanilla now mostly had the t_sample/t_float stuff ironed out, but there are a few minor differences between the two that I am not sure of. Here's the first that is in a bunch of places, including in d_arithmetic.c: vanilla: t_float g = *(t_float *)(w[2]); PDa: t_sample g = ftofix(*(t_float *)(w[2])); It seems to me that 'g' should be t_sample, not t_float. Any ideas? .hc ---------------------------------------------------------------------------- I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.

2 6

using t_time for clock functions
by Hans-Christoph Steiner 01 Jan '10

01 Jan '10

Another thing Günter did in PDa is introduce t_time for the clock functions instead of using 'double' directly. Any reason not to include t_time in vanilla? +typedef long long t_time; EXTERN t_clock *clock_new(void *owner, t_method fn); -EXTERN void clock_set(t_clock *x, double systime); -EXTERN void clock_delay(t_clock *x, double delaytime); +EXTERN void clock_set(t_clock *x, t_time systime); +EXTERN void clock_delay(t_clock *x, t_time delaytime); EXTERN void clock_unset(t_clock *x); -EXTERN double clock_getlogicaltime(void); -EXTERN double clock_getsystime(void); /* OBSOLETE; use clock_getlogicaltime() */ -EXTERN double clock_gettimesince(double prevsystime); -EXTERN double clock_getsystimeafter(double delaytime); +EXTERN t_time clock_getlogicaltime(void); +EXTERN t_time clock_getsystime(void); /* OBSOLETE; use clock_getlogicaltime() */ +EXTERN t_time clock_gettimesince(t_time prevsystime); +EXTERN t_time clock_getsystimeafter(t_time delaytime); EXTERN void clock_free(t_clock *x); .hc ---------------------------------------------------------------------------- http://at.or.at/hans/

2 1

[ pure-data-Bugs-2921977 ] multiple selections with shift
by SourceForge.net 29 Dec '09

29 Dec '09

Bugs item #2921977, was opened at 2009-12-27 15:17 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2921977&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-devel >Group: v0.43 >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: max (maxn) >Assigned to: Hans-Christoph Steiner (eighthave) Summary: multiple selections with shift Initial Comment: selecting multiple parts of a patch using the shift-key doesn't work any more with the gui-rewrite version ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-12-28 23:43 Message: thanks for reporting, should be fix in this commit: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=128… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2921977&group_…

1 0

[ pure-data-Bugs-2921977 ] multiple selections with shift
by SourceForge.net 27 Dec '09

27 Dec '09

Bugs item #2921977, was opened at 2009-12-27 20:17 Message generated for change (Tracker Item Submitted) made by maxn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2921977&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-devel Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: max (maxn) Assigned to: Nobody/Anonymous (nobody) Summary: multiple selections with shift Initial Comment: selecting multiple parts of a patch using the shift-key doesn't work any more with the gui-rewrite version ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2921977&group_…

1 0

[ pure-data-Bugs-2921711 ] gfsm: incompatible implicit declaration of built-in function
by SourceForge.net 27 Dec '09

27 Dec '09

Bugs item #2921711, was opened at 2009-12-27 03:46 Message generated for change (Settings changed) made by mukau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2921711&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: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Bryan Jurish (mukau) Summary: gfsm: incompatible implicit declaration of built-in function Initial Comment: This warning could cause problems on 64-bit: /bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I./gnulib -Wall -I/usr/include/glib-2.0 -I/usr/lib/glib -2.0/include -O2 -DPD -I/home/pd/auto-build/pd-extended/pd/src -Wall -W -ggdb -I/home/pd/auto-build/pd-extended/Gem/src -I/home/pd/auto-build/pd-extended/externals/pdp/include -DUNIX -Dunix -DDL_OPEN -fPIC -c -o gfsmRegex.tab.lo gfsmRegex.tab.c gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I./gnulib -Wall -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -DPD -I/home/pd/auto-build/pd-ex tended/pd/src -Wall -W -ggdb -I/home/pd/auto-build/pd-extended/Gem/src -I/home/pd/auto-build/pd-extended/externals/pdp/include -DUNIX -Dunix -DDL_OPEN -fPIC -c gfsmRegex.tab.c -o gfsmRegex.tab.ogfsmRegex.tab.c: In function 'yytnamerr': gfsmRegex.tab.c:973: warning: implicit declaration of function 'stpcpy'gfsmRegex.tab.c:973: warning: incompatible implicit declaration of built-in function 'stpcpy'gfsmRegex.tab.c: In function 'yysyntax_error': gfsmRegex.tab.c:1032: warning: incompatible implicit declaration of built-in function 'stpcpy' ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-12-27 19:13 Message: Ok, just letting you know. Sounds like this should be marked as Resolution: Wont Fix, and Closed. Mark it as you feel it should be. ---------------------------------------------------------------------- Comment By: Bryan Jurish (mukau) Date: 2009-12-27 12:42 Message: This is actually a bison bug (occurs in gfsmRegex.tab.c). I've successfully compiled & run the libgfsm utilities on 64-bit linux machines (although the libgfsm packaged with pd-gfsm probably needs an update) despite this warning. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2921711&group_…

1 0

[ pure-data-Bugs-2921711 ] gfsm: incompatible implicit declaration of built-in function
by SourceForge.net 27 Dec '09

27 Dec '09

Bugs item #2921711, was opened at 2009-12-26 21:46 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2921711&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: Hans-Christoph Steiner (eighthave) Assigned to: Bryan Jurish (mukau) Summary: gfsm: incompatible implicit declaration of built-in function Initial Comment: This warning could cause problems on 64-bit: /bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I./gnulib -Wall -I/usr/include/glib-2.0 -I/usr/lib/glib -2.0/include -O2 -DPD -I/home/pd/auto-build/pd-extended/pd/src -Wall -W -ggdb -I/home/pd/auto-build/pd-extended/Gem/src -I/home/pd/auto-build/pd-extended/externals/pdp/include -DUNIX -Dunix -DDL_OPEN -fPIC -c -o gfsmRegex.tab.lo gfsmRegex.tab.c gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I./gnulib -Wall -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -DPD -I/home/pd/auto-build/pd-ex tended/pd/src -Wall -W -ggdb -I/home/pd/auto-build/pd-extended/Gem/src -I/home/pd/auto-build/pd-extended/externals/pdp/include -DUNIX -Dunix -DDL_OPEN -fPIC -c gfsmRegex.tab.c -o gfsmRegex.tab.ogfsmRegex.tab.c: In function 'yytnamerr': gfsmRegex.tab.c:973: warning: implicit declaration of function 'stpcpy'gfsmRegex.tab.c:973: warning: incompatible implicit declaration of built-in function 'stpcpy'gfsmRegex.tab.c: In function 'yysyntax_error': gfsmRegex.tab.c:1032: warning: incompatible implicit declaration of built-in function 'stpcpy' ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-12-27 13:13 Message: Ok, just letting you know. Sounds like this should be marked as Resolution: Wont Fix, and Closed. Mark it as you feel it should be. ---------------------------------------------------------------------- Comment By: Bryan Jurish (mukau) Date: 2009-12-27 06:42 Message: This is actually a bison bug (occurs in gfsmRegex.tab.c). I've successfully compiled & run the libgfsm utilities on 64-bit linux machines (although the libgfsm packaged with pd-gfsm probably needs an update) despite this warning. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2921711&group_…

1 0

[ pure-data-Bugs-2921711 ] gfsm: incompatible implicit declaration of built-in function
by SourceForge.net 27 Dec '09

27 Dec '09

Bugs item #2921711, was opened at 2009-12-27 03:46 Message generated for change (Comment added) made by mukau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2921711&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: Hans-Christoph Steiner (eighthave) Assigned to: Bryan Jurish (mukau) Summary: gfsm: incompatible implicit declaration of built-in function Initial Comment: This warning could cause problems on 64-bit: /bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I./gnulib -Wall -I/usr/include/glib-2.0 -I/usr/lib/glib -2.0/include -O2 -DPD -I/home/pd/auto-build/pd-extended/pd/src -Wall -W -ggdb -I/home/pd/auto-build/pd-extended/Gem/src -I/home/pd/auto-build/pd-extended/externals/pdp/include -DUNIX -Dunix -DDL_OPEN -fPIC -c -o gfsmRegex.tab.lo gfsmRegex.tab.c gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I./gnulib -Wall -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -DPD -I/home/pd/auto-build/pd-ex tended/pd/src -Wall -W -ggdb -I/home/pd/auto-build/pd-extended/Gem/src -I/home/pd/auto-build/pd-extended/externals/pdp/include -DUNIX -Dunix -DDL_OPEN -fPIC -c gfsmRegex.tab.c -o gfsmRegex.tab.ogfsmRegex.tab.c: In function 'yytnamerr': gfsmRegex.tab.c:973: warning: implicit declaration of function 'stpcpy'gfsmRegex.tab.c:973: warning: incompatible implicit declaration of built-in function 'stpcpy'gfsmRegex.tab.c: In function 'yysyntax_error': gfsmRegex.tab.c:1032: warning: incompatible implicit declaration of built-in function 'stpcpy' ---------------------------------------------------------------------- >Comment By: Bryan Jurish (mukau) Date: 2009-12-27 12:42 Message: This is actually a bison bug (occurs in gfsmRegex.tab.c). I've successfully compiled & run the libgfsm utilities on 64-bit linux machines (although the libgfsm packaged with pd-gfsm probably needs an update) despite this warning. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2921711&group_…

1 0

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 December 2009