Has anyone been using pd on a 64 bit GNU/Linux OS?
I have a new laptop and I'm thinking of trying to run Ubuntu 8.10 64bit. If I can't run pd, jack, ardour, etc then I'll stick to 32 bit, but I've read that 32 bit apps will run fine as long as they have the correct libs ...
Dan Wilcox danomatika.com robotcowboy.com
i am currently testing a machine running 64studio 3.0alpha[1], which is based on ubuntu 8.04(hardy) for amd64 (there are 32bit builds too), while the stable 64studio 2.1 is built on debian 4.0etch. 64studio is designed for stable low- latency audio and both versions perform very well. if you require extended you should read the recent thread on deb packages for pd-extended - but I haven't had too much trouble getting the externals i need to build (flext libs are a current exception).
ubuntu 8.10 is generally not recommended for low-latency audio as the realtime kernels provided by ubuntustudio[2] do not run stably. otherwise, planetccrma[3] for fedora is a popular choice, but i can't personally speak for the 64bit builds.
ciao, dmotd
references [1] http://www.64studio.com/node/877 [2] http://ubuntustudio.org/ [3] http://ccrma.stanford.edu/planetccrma/software/
On Sunday 22 February 2009 09:28:52 danomatika wrote:
Has anyone been using pd on a 64 bit GNU/Linux OS?
I have a new laptop and I'm thinking of trying to run Ubuntu 8.10 64bit. If I can't run pd, jack, ardour, etc then I'll stick to 32 bit, but I've read that 32 bit apps will run fine as long as they have the correct libs ...
Dan Wilcox danomatika.com robotcowboy.com
danomatika wrote:
Has anyone been using pd on a 64 bit GNU/Linux OS?
i've been running Pd (vanilla, + zexy,Gem and all myother stuff and some stuff by others) on 64bit debian for some years now, and i havent had any major troubles (related to Pd)
does this mean that the previous problem with tables in PD on 64bit has been resolved?
august wrote:
danomatika wrote:
Has anyone been using pd on a 64 bit GNU/Linux OS?
i've been running Pd (vanilla, + zexy,Gem and all myother stuff and some stuff by others) on 64bit debian for some years now, and i havent had any major troubles (related to Pd)
does this mean that the previous problem with tables in PD on 64bit has been resolved?
yes, since 0.40, iirc
fgmasdr IOhannes
IOhannes m zmoelnig wrote:
august wrote:
danomatika wrote:
Has anyone been using pd on a 64 bit GNU/Linux OS?
i've been running Pd (vanilla, + zexy,Gem and all myother stuff and some stuff by others) on 64bit debian for some years now, and i havent had any major troubles (related to Pd)
does this mean that the previous problem with tables in PD on 64bit has been resolved?
yes, since 0.40, iirc
or 0.41 as roman has suggested. at least, i has been fixed for ages (of Pd-vanilla)
fgmasdr IOhannes
On Sun, 2009-02-22 at 17:24 +0100, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
august wrote:
danomatika wrote:
Has anyone been using pd on a 64 bit GNU/Linux OS?
i've been running Pd (vanilla, + zexy,Gem and all myother stuff and some stuff by others) on 64bit debian for some years now, and i havent had any major troubles (related to Pd)
does this mean that the previous problem with tables in PD on 64bit has been resolved?
yes, since 0.40, iirc
or 0.41 as roman has suggested. at least, i has been fixed for ages (of Pd-vanilla)
I made a 64bit build of pd-extended using the pd core (0.41 I believe) from the pd-extended svn and it has this table bug. It seems to only access half of the table, at least in the C08 and C09 audio example patches. They work fine in my build using pd-vanilla 0.42.4.
This is too bad as I was hoping for some of the gui improvements in the pd-extended core.
Dan Wilcox danomatika.com robotcowboy.com
danomatika wrote:
I made a 64bit build of pd-extended using the pd core (0.41 I believe) from the pd-extended svn and it has this table bug. It seems to only access half of the table, at least in the C08 and C09 audio example patches. They work fine in my build using pd-vanilla 0.42.4.
Wow I am surprised to hear that. I remember seeing this table bug in 0.40 but thought it disappeared on my 64 bit ubuntu Hardy build of 0.41.
On Tue, 2009-02-24 at 00:03 -0600, John Harrison wrote:
danomatika wrote:
I made a 64bit build of pd-extended using the pd core (0.41 I believe) from the pd-extended svn and it has this table bug. It seems to only access half of the table, at least in the C08 and C09 audio example patches. They work fine in my build using pd-vanilla 0.42.4.
Wow I am surprised to hear that. I remember seeing this table bug in 0.40 but thought it disappeared on my 64 bit ubuntu Hardy build of 0.41.
From reading some of the commit lines, it seems not all changes in 0.41 have been merged into pd-extended yet.
Dan Wilcox danomatika.com robotcowboy.com
On Feb 24, 2009, at 1:05 AM, danomatika wrote:
On Tue, 2009-02-24 at 00:03 -0600, John Harrison wrote:
danomatika wrote:
I made a 64bit build of pd-extended using the pd core (0.41 I
believe)
from the pd-extended svn and it has this table bug. It seems to
only
access half of the table, at least in the C08 and C09 audio example patches. They work fine in my build using pd-vanilla 0.42.4.
Wow I am surprised to hear that. I remember seeing this table bug in 0.40 but thought it disappeared on my 64 bit ubuntu Hardy build of
0.41. From reading some of the commit lines, it seems not all changes in0.41 have been merged into pd-extended yet.
There is now pd-0.41.4 extended, you need to work from that branch, or
get the code from rsync via the auto-build server.
http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/0...
Right now, only 'pd' is in the branch, the nightly builds use
everything else from trunk.
.hc
Dan Wilcox danomatika.com robotcowboy.com _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
John Harrison wrote:
danomatika wrote:
I made a 64bit build of pd-extended using the pd core (0.41 I believe) from the pd-extended svn and it has this table bug. It seems to only access half of the table, at least in the C08 and C09 audio example patches. They work fine in my build using pd-vanilla 0.42.4.
Wow I am surprised to hear that. I remember seeing this table bug in 0.40 but thought it disappeared on my 64 bit ubuntu Hardy build of 0.41.
it's definitely fixed in 0.41
there are 2 possibilites, i see:
- dan has (despite his claims) not built a 0.41 version but a prior one
- the bug he is experiencing comes from some externals using
garray_getfloatarray() rather than garray_getfloatwords()
in the latter case, there ought to be some printout in the Pd-console about the illegal use of garray_getfloatarray() on 64bit.
fsmras IOhannes
On Feb 26, 2009, at 3:49 AM, IOhannes m zmoelnig wrote:
John Harrison wrote:
danomatika wrote:
I made a 64bit build of pd-extended using the pd core (0.41 I
believe) from the pd-extended svn and it has this table bug. It seems to
only access half of the table, at least in the C08 and C09 audio example patches. They work fine in my build using pd-vanilla 0.42.4.Wow I am surprised to hear that. I remember seeing this table bug in 0.40 but thought it disappeared on my 64 bit ubuntu Hardy build of
0.41.it's definitely fixed in 0.41
there are 2 possibilites, i see:
- dan has (despite his claims) not built a 0.41 version but a prior
one
- the bug he is experiencing comes from some externals using
garray_getfloatarray() rather than garray_getfloatwords()
in the latter case, there ought to be some printout in the Pd-console about the illegal use of garray_getfloatarray() on 64bit.
I just ran a check of the code in SVN, turns out there are many using
garray_getfloatarray(). What's the conversion path for that? That
would be good to fix, so we can have fully working 64-bit builds of
all this:
hans@palatschinken.at.or.at:trunk > find . -type f -print0 | xargs -0
grep garray_getfloatarray | grep -v desiredata | grep -v svn
./extensions/xgui/xgui-lib/m_pd.h:EXTERN int
garray_getfloatarray(t_garray *x, int *size, t_float **vec);
./externals/algocomp/m_pd.h:EXTERN int garray_getfloatarray(t_garray
*x, int *size, t_float **vec);
./externals/bsaylor/partconv~.c: } else if ( !
garray_getfloatarray(arrayobj, &arraysize, &array)) {
./externals/bsaylor/pvoc~.c: } else if ( ! garray_getfloatarray(x-
arrayobj, &x->arraysize, &x->array)) {
./externals/build/include/m_pd.h:EXTERN int
garray_getfloatarray(t_garray *x, int *size, t_float **vec);
./externals/creb/modules/statwav~.c: else if (!
garray_getfloatarray(a, &x->x_npoints, &x->x_vec))
./externals/creb/modules/tabreadmix~.c: else if (!
garray_getfloatarray(a, &x->x_npoints, &x->x_vec))
./externals/cxc/mean~.c: else if (!garray_getfloatarray(a, &x-
x_nsampsintab, &x->x_vec))
./externals/cxc/mean~.c: garray_getfloatarray(a,&x->x_nsampsintab,&x-
x_vec);
./externals/cxc/mean~.c: else if (!garray_getfloatarray(a, &x-
x_nsampsintab, &x->x_vec))
./externals/cxc/mean~.c: garray_getfloatarray(a,&x->x_nsampsintab,&x-
x_vec);
./externals/cxc/mean~.c: else if (!garray_getfloatarray(a, &x-
x_nsampsintab, &x->x_vec))
./externals/cxc/mean~.c: garray_getfloatarray(a,&x->x_nsampsintab,&x-
x_vec);
./externals/cxc/mean~.c: else if (!garray_getfloatarray(a, &x-
x_nsampsintab, &x->x_vec))
./externals/cxc/mean~.c: garray_getfloatarray(a,&x->x_nsampsintab,&x-
x_vec);
./externals/dfx/transverb/prep.i:extern int
garray_getfloatarray(struct _garray *x, int *size, t_float **vec);
./externals/ekext/framescore~/m_pd.h:EXTERN int
garray_getfloatarray(t_garray *x, int *size, t_float **vec);
./externals/ekext/framespect~/m_pd.h:EXTERN int
garray_getfloatarray(t_garray *x, int *size, t_float **vec);
./externals/ekext/hssc~/m_pd.h:EXTERN int
garray_getfloatarray(t_garray *x, int *size, t_float **vec);
./externals/ekext/listmoses/m_pd.h:EXTERN int
garray_getfloatarray(t_garray *x, int *size, t_float **vec);
./externals/ekext/simile/m_pd.h:EXTERN int
garray_getfloatarray(t_garray *x, int *size, t_float **vec);
./externals/ekext/simile~/m_pd.h:EXTERN int
garray_getfloatarray(t_garray *x, int *size, t_float **vec);
./externals/frankenstein/chord_melo.c: else if (!
garray_getfloatarray(arysrc_note, &vecsize, &(x->vecsrc_note)))
./externals/frankenstein/chord_melo.c: else if (!
garray_getfloatarray(arysrc_octave, &vecsize, &(x->vecsrc_octave)))
./externals/frankenstein/chord_melo.c: else if (!
garray_getfloatarray(arysrc_passing, &vecsize, &(x->vecsrc_passing)))
./externals/frankenstein/chord_melo.c: else if (!
garray_getfloatarray(arysrc_played, &vecsize, &(x->vecsrc_played)))
./externals/frankenstein/chord_melo.c: else if (!
garray_getfloatarray(arydest_note, &vecsize, &(x->vecdest_note)))
./externals/frankenstein/chord_melo.c: else if (!
garray_getfloatarray(arydest_octave, &vecsize, &(x->vecdest_octave)))
./externals/frankenstein/chord_melo.c: else if (!
garray_getfloatarray(arydest_passing, &vecsize, &(x->vecdest_passing)))
./externals/frankenstein/chord_melo.c: else if (!
garray_getfloatarray(arydest_played, &vecsize, &(x->vecdest_played)))
./externals/frankenstein/GArhythm.c: else if (!
garray_getfloatarray(arysrc_strum1, &vecsize, &vecsrc_strum1))
./externals/frankenstein/GArhythm.c: else if (!
garray_getfloatarray(arysrc_strum2, &vecsize, &vecsrc_strum2))
./externals/frankenstein/GArhythm.c: else if (!
garray_getfloatarray(arysrc_strum3, &vecsize, &vecsrc_strum3))
./externals/frankenstein/GArhythm.c: else if (!
garray_getfloatarray(arysrc_strum4, &vecsize, &vecsrc_strum4))
./externals/frankenstein/GArhythm.c: else if (!
garray_getfloatarray(arysrc_strum1, &vecsize, &vecsrc_strum1))
./externals/frankenstein/GArhythm.c: else if (!
garray_getfloatarray(arysrc_strum2, &vecsize, &vecsrc_strum2))
./externals/frankenstein/GArhythm.c: else if (!
garray_getfloatarray(arysrc_strum3, &vecsize, &vecsrc_strum3))
./externals/frankenstein/GArhythm.c: else if (!
garray_getfloatarray(arysrc_strum4, &vecsize, &vecsrc_strum4))
./externals/frankenstein/GArhythm.c: else if (!
garray_getfloatarray(arydest_strum1, &vecsize, &vecdest_strum1))
./externals/frankenstein/GArhythm.c: else if (!
garray_getfloatarray(arydest_strum2, &vecsize, &vecdest_strum2))
./externals/frankenstein/GArhythm.c: else if (!
garray_getfloatarray(arydest_strum3, &vecsize, &vecdest_strum3))
./externals/frankenstein/GArhythm.c: else if (!
garray_getfloatarray(arydest_strum4, &vecsize, &vecdest_strum4))
./externals/frankenstein/ritmo1.c: else if (!
garray_getfloatarray(arysrc, &vecsize, &vecsrc))
./externals/frankenstein/ritmo1.c: else if (!
garray_getfloatarray(arydest, &vecsize, &vecdest))
./externals/ggee/experimental/fofsynth~.c: else if (!
garray_getfloatarray(a,points,vec))
./externals/ggee/experimental/tabwrite4~.c: else if (!
garray_getfloatarray(a, &x->x_npoints, &x->x_vec))
./externals/grill/flext/source/flbuf.cpp: else if(!
garray_getfloatarray(arr, &frames1, &data1))
./externals/grill/flext/source/flbuf.cpp: if(!
garray_getfloatarray(arr, &frames1, &data1)) {
./externals/hcs/TAGS:int garray_getfloatarray(1153,38595
./externals/hcs/usbhid/TAGS:int garray_getfloatarray(1153,38595
./externals/iem/iem_adaptfilt/src/n_CLNLMS~.c: else if(!
garray_getfloatarray(a, &n_points, &vec))
./externals/iem/iem_adaptfilt/src/n_CNLMS~.c: else if(!
garray_getfloatarray(a, &n_points, &vec))
./externals/iem/iem_adaptfilt/src/NLMSCC~.c: else if(!
garray_getfloatarray(a, &n_points, &vec))
./externals/iem/iem_adaptfilt/src/NLMS~.c: else if(!
garray_getfloatarray(a, &n_points, &vec))
./externals/iem/iem_bin_ambi/src/iemlib.h:/* on 64bit systems we
cannot use garray_getfloatarray... */
./externals/iem/iem_bin_ambi/src/iemlib.h:# define iemarray_getarray
garray_getfloatarray
./externals/iem/iem_spec2/src/iemlib.h:/* on 64bit systems we cannot
use garray_getfloatarray... */
./externals/iem/iem_spec2/src/iemlib.h:# define iemarray_getarray
garray_getfloatarray
./externals/iem/iem_tab/src/iemlib.h:/* on 64bit systems we cannot use
garray_getfloatarray... */
./externals/iem/iem_tab/src/iemlib.h:# define iemarray_getarray
garray_getfloatarray
./externals/iem16/src/table16.c: if (!garray_getfloatarray(a,
&npoints, &vec)){
./externals/iemlib/iemlib1/src/FIR~.c: else if(!
garray_getfloatarray(ga, &table_size, &x->x_coef_beg))
./externals/io/hidio/TAGS:int garray_getfloatarray(1153,38595
./externals/loaders/pdj/src/MSPBuffer.c: if ( !
garray_getfloatarray(array, &size, &vec) )
./externals/loaders/pdj/src/MSPBuffer.c: if ( !
garray_getfloatarray(array, &size, &vec) )
./externals/loaders/pdj/src/MSPBuffer.c: if ( !
garray_getfloatarray(array, &size, &vec) )
./externals/loaders/pdj/src/MSPBuffer.c: if ( !
garray_getfloatarray(array, &size, &vec) )
./externals/maxlib/src/arbran.c: if (!garray_getfloatarray(bx, &ix,
&tx))
./externals/maxlib/src/arbran.c: if (!garray_getfloatarray(bp, &ip,
&tp))
./externals/maxlib/src/arbran.c: if (!garray_getfloatarray(bx, &ix,
&tx))
./externals/maxlib/src/arbran.c: if (!garray_getfloatarray(bp, &ip,
&tp))
./externals/maxlib/src/arraycopy.c: if (!garray_getfloatarray(b,
&items, &tab))
./externals/maxlib/src/arraycopy.c: else if (!garray_getfloatarray(A,
&npoints, &vec))
./externals/maxlib/src/score.c: if (!garray_getfloatarray(b, &items,
&tab))
./externals/maxlib/src/subst.c: else if (!garray_getfloatarray(A,
&npoints, &vec))
./externals/maxlib/src/subst.c: if (!garray_getfloatarray(b, &items,
&tab))
./externals/miXed/shared/common/vefl.c: if
(garray_getfloatarray(ap, &vsz, &vec))
./externals/miXed/shared/common/vefl.c: && !garray_getfloatarray(vp-
v_garray, &vp->v_size, &vp->v_data))
./externals/miXed/shared/common/vefl.c: else if (!
garray_getfloatarray(vp->v_garray, &vp->v_size, &vp->v_data))
./externals/moocow/flite/flite.c: if (!garray_getfloatarray(a,
&vecsize, &vec))
./externals/moocow/pdstring/src/array2rawbytes.c: if (!
garray_getfloatarray(a, &fvecsize, &fvec))
./externals/moocow/pdstring/src/pdstringUtils.c: if (!
garray_getfloatarray(fa->fa_garray, &fa->fa_vlen, &fa->fa_vec)) {
./externals/moocow/pdstring/src/pdstringUtils.c: pd_error(x,
"pdstring_floatarray_getvec(): garray_getfloatarray() failed for array
'%s'", fa->fa_name->s_name);
./externals/moocow/pdstring/src/rawbytes2array.c: if (!
garray_getfloatarray(a, &fvecsize, &fvec))
./externals/moonlib/readsfv~.c: else if (!
garray_getfloatarray(garrays[i], &vecsize, &vecs[i]))
./externals/moonlib/readsfv~.c: garray_getfloatarray(garrays[i],
&vecsize, &vecs[i]);
./externals/moonlib/readsfv~.c: garray_getfloatarray(garrays[i],
&vecsize, &vecs[i]);
./externals/moonlib/readsfv~.c: garray_getfloatarray(garrays[i],
&vecsize, &foo);
./externals/moonlib/readsfv~.c: else if (!
garray_getfloatarray(garrays[i], &vecsize, &vecs[i]))
./externals/moonlib/tabdump2.c: else if (!garray_getfloatarray(A,
&npoints, &vec))
./externals/moonlib/tabdump2.c: else if (!garray_getfloatarray(A,
&npoints, &vec))
./externals/moonlib/tabenv.c: else if (!garray_getfloatarray(a, &x-
x_nsampsintab, &x->x_vec))
./externals/moonlib/tabreadl.c: else if (!garray_getfloatarray(a,
&npoints, &vec))
./externals/moonlib/tabsort.c: else if (!garray_getfloatarray(a,
&n1, &vec1))
./externals/moonlib/tabsort.c: else if (!garray_getfloatarray(a,
&n2, &vec2))
./externals/moonlib/tabsort2.c: else if (!garray_getfloatarray(a,
&n1, &vec1))
./externals/moonlib/tabsort2.c: else if (!garray_getfloatarray(a,
&n2, &vec2))
./externals/moonlib/tabsort2.c: else if (!garray_getfloatarray(a,
&n3, &vec3))
./externals/mrpeach/flist2tab/flist2tab.c:/* garray_getfloatarray uses
t_float but is not 64-bit */
./externals/mrpeach/flist2tab/flist2tab.c: else if (!
garray_getfloatarray(a, &npoints, &vec))
./externals/mrpeach/flist2tab/flist2tab.c: if (!
garray_getfloatarray(a, &npoints, &vec))
./externals/mrpeach/flist2tab/flist2tab.c: else if (!
garray_getfloatarray(a, &npoints, &vec))
./externals/mrpeach/flist2tab/flist2tab.c: if (!
garray_getfloatarray(a, &npoints, &vec))
./externals/mrpeach/tab2flist/tab2flist.c:/* garray_getfloatarray uses
t_float but is not 64-bit */
./externals/mrpeach/tab2flist/tab2flist.c: else if (!
garray_getfloatarray(a, &tabpoints, &vec))
./externals/mrpeach/tabfind/tabfind.c:/* garray_getfloatarray uses
t_float but is not 64-bit */
./externals/mrpeach/tabfind/tabfind.c: else if (!
garray_getfloatarray(a, &npoints, &vec))
./externals/mrpeach/tabfind/tabfind.c: else if (!
garray_getfloatarray(a, &npoints, &vec))
./externals/oscbank~/oscbank~.c: else if (!garray_getfloatarray(a,
&x->wavetablesize, &x->wavetable))
./externals/pdp/modules/image_basic/pdp_cheby.c: else if (!
garray_getfloatarray(a, &x->x_nbpoints, &x->x_vec)){
./externals/pdp/modules/image_io/pdp_qt.c: garray_getfloatarray(g,
&vecsize, &f);
./externals/pdp/modules/image_special/pdp_array.c: if (!
garray_getfloatarray(a, &x->x_nbpoints, &x->x_vec)){
./externals/pdp/modules/image_special/pdp_histo.c: else if (!
garray_getfloatarray(a, &nbpoints, &vec)){
./externals/pdp/modules/matrix_basic/clusterstuff.c: else if (!
garray_getfloatarray(a, &nbpoints, &vec)){
./externals/rhythm_estimator/pd_rhythm_ioi_histogram.c: else if (!
garray_getfloatarray (a, &x->array_nsampsintab, &x->array_vec))
./externals/rhythm_estimator/pd_rhythm_ioi_histogram.c: else if (!
garray_getfloatarray (a, &x->array_nsampsintab, &x->array_vec))
./externals/rhythm_estimator/pd_rhythm_quantum.c: else if (!
garray_getfloatarray (a, &x->array_nsampsintab, &x->array_vec))
./externals/rhythm_estimator/pd_rhythm_quantum.c: else if (!
garray_getfloatarray (a, &x->array_nsampsintab, &x->array_vec))
./externals/signal/expr~/vexp_if.c: !garray_getfloatarray(garray,
&size, &vec))
./externals/signal/expr~/vexp_if.c: !garray_getfloatarray(garray,
&size, &vec)) {
./externals/signal/pique/pique.c: !garray_getfloatarray(a, &n,
&fpreal) ||
./externals/signal/pique/pique.c: !garray_getfloatarray(a, &n,
&fpimag) ||
./externals/tb/sndfiler/src/sndfiler.c:
if(garray_getfloatarray(array, &size, &dummy))
./externals/tclpd/tcl_wrap.cxx:_wrap_garray_getfloatarray(ClientData
clientData SWIGUNUSED, Tcl_Interp *interp, int objc, Tcl_Obj *CONST
objv[]) {
./externals/tclpd/tcl_wrap.cxx: if (SWIG_GetArgs(interp, objc,
objv,"ooo:garray_getfloatarray x size vec ",(void *)0,(void *)0,(void
*)0) == TCL_ERROR) SWIG_fail;
./externals/tclpd/tcl_wrap.cxx:
SWIG_exception_fail(SWIG_ArgError(res1), "in method '"
"garray_getfloatarray" "', argument " "1"" of type '" "_garray *""'");
./externals/tclpd/tcl_wrap.cxx:
SWIG_exception_fail(SWIG_ArgError(res2), "in method '"
"garray_getfloatarray" "', argument " "2"" of type '" "int *""'");
./externals/tclpd/tcl_wrap.cxx:
SWIG_exception_fail(SWIG_ArgError(res3), "in method '"
"garray_getfloatarray" "', argument " "3"" of type '" "t_float **""'");
./externals/tclpd/tcl_wrap.cxx: result =
(int)garray_getfloatarray(arg1,arg2,arg3);
./externals/tclpd/tcl_wrap.cxx: { SWIG_prefix
"garray_getfloatarray", (swig_wrapper_func)
_wrap_garray_getfloatarray, NULL},
./externals/zexy/src/zexy.h:# define zarray_getarray
garray_getfloatarray
./Gem/src/Manips/linear_path.cpp: if (!
garray_getfloatarray(m_array, &size, &vec))
./Gem/src/Manips/spline_path.cpp: if (!
garray_getfloatarray(m_array, &size, &vec))
./Gem/src/Pixes/pix_curve.cpp: else if (!garray_getfloatarray(a,
length, &fp))
./Gem/src/Pixes/pix_histo.cpp: else if (!garray_getfloatarray(a,
length, &fp))
./Gem/src/Vertex/vertex_tabread.cpp: } else if (!
garray_getfloatarray(a, length, &fp)) {
Mistrust authority - promote decentralization. - the hacker ethic
Hans-Christoph Steiner wrote:
I just ran a check of the code in SVN, turns out there are many using garray_getfloatarray(). What's the conversion path for that? That would be good to fix, so we can have fully working 64-bit builds of all this:
the conversion path is to make your hands dirty. in zexy (and then: iemlibs) i tried to do a generic approach using some prepocessor magic ;but it doesn't keep you from changing every line of code accessing a table.
hans@palatschinken.at.or.at:trunk > find . -type f -print0 | xargs -0 grep garray_getfloatarray | grep -v desiredata | grep -v svn
not everything you find with grep triggers the problem. e.g. zexy and (most of) iemlibs have been fixed (at least, i hope so), but you still find the g-word in comments...
mgfasd,r IOhannes
IOhannes m zmoelnig wrote:
not everything you find with grep triggers the problem. e.g. zexy and (most of) iemlibs have been fixed (at least, i hope so), but you still find the g-word in comments...
i forgot: nevertheless quite a number of externals has to be fixed.
fgmasr IOhannes
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I just ran a check of the code in SVN, turns out there are many using garray_getfloatarray(). What's the conversion path for that? That would be good to fix, so we can have fully working 64-bit builds of all this:
the conversion path is to make your hands dirty. in zexy (and then: iemlibs) i tried to do a generic approach using some prepocessor magic ;but it doesn't keep you from changing every line of code accessing a table.
In pdlua I used some preprocessor magic similar to this, not sure how it compares to the zexy/iemlibs magic but I guess it's roughly the same:
#if PD_MAJOR_VERSION == 0 # if PD_MINOR_VERSION >= 41 /* use new garray support that is 64-bit safe */ # define PDLUA_ARRAYGRAB garray_getfloatwords # define PDLUA_ARRAYTYPE t_word # define PDLUA_ARRAYELEM(arr,idx) ((arr)[(idx)].w_float) # else /* use old garray support, not 64-bit safe */ # define PDLUA_ARRAYGRAB garray_getfloatarray # define PDLUA_ARRAYTYPE t_float # define PDLUA_ARRAYELEM(arr,idx) ((arr)[(idx)]) # endif #endif
then use the macros instead of direct array access, still needs some work to change all array-related lines as IOhannes says...
I'm not even sure this is correct, works for me on my 32bit system.
Claude
Claude Heiland-Allen wrote:
In pdlua I used some preprocessor magic similar to this, not sure how it compares to the zexy/iemlibs magic but I guess it's roughly the same:
actually it is amazingly the same: #if (defined __x86_64__) && (defined PD_MAJOR_VERSION && defined PD_MINOR_VERSION) && (PD_MAJOR_VERSION > 0 || PD_MINOR_VERSION > 41) # define zarray_t t_word # define zarray_getarray garray_getfloatwords # define zarray_getfloat(pointer, index) (pointer[index].w_float) #else # define zarray_t t_float # define zarray_getarray garray_getfloatarray # define zarray_getfloat(pointer, index) (pointer[index]) #endif
#if PD_MAJOR_VERSION == 0 # if PD_MINOR_VERSION >= 41 /* use new garray support that is 64-bit safe */ # define PDLUA_ARRAYGRAB garray_getfloatwords # define PDLUA_ARRAYTYPE t_word # define PDLUA_ARRAYELEM(arr,idx) ((arr)[(idx)].w_float) # else /* use old garray support, not 64-bit safe */ # define PDLUA_ARRAYGRAB garray_getfloatarray # define PDLUA_ARRAYTYPE t_float # define PDLUA_ARRAYELEM(arr,idx) ((arr)[(idx)]) # endif #endif
it's so strikingly similar that i even wondered whether i had copied the code from you (but honestly, i cannot remember having done so).
apart from that, why do you explicitely not support PD_MAJOR_VERSION!=0?
mgfa.sdr IOhannes
IOhannes m zmoelnig wrote:
#if (defined __x86_64__) && (defined PD_MAJOR_VERSION && defined PD_MINOR_VERSION) && (PD_MAJOR_VERSION > 0 || PD_MINOR_VERSION > 41)
Shouldn't it be >= 41 there?
Also, why checking for 64bit when the new interface is the same in 32bit Pd?
it's so strikingly similar that i even wondered whether i had copied the code from you (but honestly, i cannot remember having done so).
I think it's just the obvious way of doing things...
apart from that, why do you explicitely not support PD_MAJOR_VERSION!=0?
I figure that pd-1.0 is so far away, and that things will probably change a great deal before then, that it's safer. Who knows whether pd-0.41 will compile with TCL/Tk 8.7, so why check for it in configure?
Inspiration for this philosophy comes from the Haskell Package Version Policy, where major numbers indicate incompatible API changes and minor versions indicate bug fixes, and dependencies should be specified using a closed range to avoid massive breakage and confusion when APIs change in the future.
http://haskell.org/haskellwiki/Package_versioning_policy
Claude
On Sun, 2009-02-22 at 16:30 +0100, august wrote:
danomatika wrote:
Has anyone been using pd on a 64 bit GNU/Linux OS?
i've been running Pd (vanilla, + zexy,Gem and all myother stuff and some stuff by others) on 64bit debian for some years now, and i havent had any major troubles (related to Pd)
does this mean that the previous problem with tables in PD on 64bit has been resolved?
i guess, it was solved in 0.41 or so. refer to the list archive for exact details.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Sun, 2009-02-22 at 14:54 +0100, IOhannes m zmoelnig wrote:
danomatika wrote:
Has anyone been using pd on a 64 bit GNU/Linux OS?
i've been running Pd (vanilla, + zexy,Gem and all myother stuff and some stuff by others) on 64bit debian for some years now, and i havent had any major troubles (related to Pd)
Great, thanks. I will give it a go then.
Dan Wilcox danomatika.com robotcowboy.com
-
august -
Claude Heiland-Allen -
danomatika -
dmotd -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
John Harrison -
Roman Haefeli