hi,
trying to debug a patch using gridflow-0.12 on pd-extended-0.42.5 (ubuntu-lucid), I have some issues:
- some tcl errors at pd startup[1]:
(tcl) invalid command name ".xb6cde8.c" while executing ".xb6cde8.c delete gf08c44168"
and then (30 or more):
.x8e3b590 no such object
- then I tried to build gridflow-0.13 but it does not find half of the
headers and I have a couple of gcc errors just with ./configure (libs not found are libdc1394, libmpeg3, quicktime, ... although they are all installed and can all be found in /usr/include)
as updating the OS is not currently an option, I wonder if there is something obvious I'm missing...
sorry for not posting the complete backtrace but this happened on another machine than mine
ps: ruby-1.8.7 and gcc/g++-4.4.3 pps: gridflow-0.12 was installed from a *.deb
any help is appreciated cheers, _y
[1] those errors go away if I remove gridflow/abstractions from the pd-path
On Sun, 17 Apr 2011, yvan volochine wrote:
trying to debug a patch using gridflow-0.12
There's no leading 0 since a year ago. It would have been 0.9.12 but now it's like 9.12. It has never been 0.12.
on pd-extended-0.42.5 (ubuntu-lucid), I have some issues:
- some tcl errors at pd startup[1]:
(tcl) invalid command name ".xb6cde8.c" while executing ".xb6cde8.c delete gf08c44168"
That doesn't look like a pd (0.)42 error message style. Are you sure that you aren't doing it with a pd (0.)43 ?
and then (30 or more): .x8e3b590 no such object
Haven't seen that. I could check with pd (0.)43 again to see whether that's the bug that GridFlow had with it.
- then I tried to build gridflow-0.13 but it does not find half of the
headers and I have a couple of gcc errors just with ./configure (libs not found are libdc1394, libmpeg3, quicktime, ... although they are all installed and can all be found in /usr/include)
Send me your config.log.
ps: ruby-1.8.7 and gcc/g++-4.4.3 pps: gridflow-0.12 was installed from a *.deb [1] those errors go away if I remove gridflow/abstractions from the pd-path
Ah, GridFlow needs add its own path elements to the pd-path, and it doesn't remove any conflicting ones that it may see. This may cause a problem when upgrading to 9.13 from 9.12.
I don't know of any way to automatically fix this. So, you just have to remove the gridflow/abstractions item and... there's a gridflow/deprecated folder to be removed too, and perhaps gridflow/doc/flow_classes (though that's a -helppath instead).
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sun, 17 Apr 2011, Mathieu Bouchard wrote:
Ah, GridFlow needs add its own path elements to the pd-path, and it doesn't remove any conflicting ones that it may see. This may cause a problem when upgrading to 9.13 from 9.12.
I don't know of any way to automatically fix this. So, you just have to remove the gridflow/abstractions item and... there's a gridflow/deprecated folder to be removed too, and perhaps gridflow/doc/flow_classes (though that's a -helppath instead).
Actually, it can also happen when upgrading to 9.12 from 9.11 on Ubuntu. It doesn't happen at all on OSX. In general, it only happens when the location of the gridflow files change, so, there won't be such a problem with any upgrade where gridflow.pd_linux (and related files) just stay in the same place.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On 04/17/2011 04:14 PM, Mathieu Bouchard wrote:
On Sun, 17 Apr 2011, yvan volochine wrote:
trying to debug a patch using gridflow-0.12
There's no leading 0 since a year ago. It would have been 0.9.12 but now it's like 9.12. It has never been 0.12.
yes of course I meant 9.12
on pd-extended-0.42.5 (ubuntu-lucid), I have some issues:
- some tcl errors at pd startup[1]:
(tcl) invalid command name ".xb6cde8.c" while executing ".xb6cde8.c delete gf08c44168"
That doesn't look like a pd (0.)42 error message style. Are you sure that you aren't doing it with a pd (0.)43 ?
indeed, I tried with both and the tcl error is on pd-0.43
and then (30 or more): .x8e3b590 no such object
Haven't seen that. I could check with pd (0.)43 again to see whether that's the bug that GridFlow had with it.
this appears also on pd-extended-0.42.5
- then I tried to build gridflow-0.13 but it does not find half of the
headers and I have a couple of gcc errors just with ./configure (libs not found are libdc1394, libmpeg3, quicktime, ... although they are all installed and can all be found in /usr/include)
Send me your config.log.
here it is: http://pastebin.com/cPKhKSWQ
ps: ruby-1.8.7 and gcc/g++-4.4.3 pps: gridflow-0.12 was installed from a *.deb [1] those errors go away if I remove gridflow/abstractions from the pd-path
Ah, GridFlow needs add its own path elements to the pd-path, and it doesn't remove any conflicting ones that it may see. This may cause a problem when upgrading to 9.13 from 9.12.
I don't know of any way to automatically fix this. So, you just have to remove the gridflow/abstractions item and... there's a gridflow/deprecated folder to be removed too, and perhaps gridflow/doc/flow_classes (though that's a -helppath instead).
it seems that my friend needs those abstractions so I dunno what to do next. that's why I tried to build 9.13, I thought that the bugs in the patch (random freezes, shutdown etc) might be related to those missing canvas/objects but I'm not sure..
cheers, _y
ps: I uploaded to ruby-1.9.1 just in case but same problems with building (and I don't see any new gcc/g++ in the ubuntu repos)
On Sun, 17 Apr 2011, yvan volochine wrote:
and then (30 or more): .x8e3b590 no such object
Haven't seen that. I could check with pd (0.)43 again to see whether that's the bug that GridFlow had with it.
this appears also on pd-extended-0.42.5
With any patch, or only those using [display] or [#see] ?
(libs not found are libdc1394, libmpeg3, quicktime, ... although they are all installed and can all be found in /usr/include)
Send me your config.log.
here it is: http://pastebin.com/cPKhKSWQ
the nasm problem is fixed in 9.14 (it's a ./configure problem ; you can fix it using --force-nasm)
dc1394 is a bigger problem : the API was changed, and thus part of gridflow/src/dc1394.cxx would have to be rewritten, and I have no such camera. In addition, the laptop I just bought doesn't have any FireWire port (but I still have the other laptop).
libmpeg3 says «found» in your config.log.
quicktimehw also says «found» in your config.log (after several attempts to find it).
quicktimeapple can't possibly be found on a Linux OS.
most things listed by ./configure are optional (g++ and libstdc++ are the only mandatory parts).
it seems that my friend needs those abstractions
Can't your friend use the ones bundled in the version of GridFlow that will be loaded ? No functionality got removed, but many patches depend on changes in abstractions, and some abstractions may depend on changes in other externals that are part of GridFlow, so, it's way better to not mix and match parts of different versions.
I thought that the bugs in the patch (random freezes, shutdown etc) might be related to those missing canvas/objects but I'm not sure..
I haven't had random shutdowns for three years now, and I don't remember ever having random freezes. If you think that the problem has to do with GUI objects, try making smaller versions of your patches that use less GUI objects and see whether the error messages and/or the freezes and/or the crashes disappear. You may notice patterns that will narrow down the possibilities, and then perhaps you'll have enough information to be able to write a bug report.
ps: I uploaded
upgraded ?
to ruby-1.9.1 just in case but same problems with building (and I don't see any new gcc/g++ in the ubuntu repos)
Not necessary. I don't run ruby 1.9.x anymore, only 1.8.x, and the GridFlow 9.14 ./configure doesn't trigger the ruby [BUG] anymore.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On 04/17/2011 06:55 PM, Mathieu Bouchard wrote:
On Sun, 17 Apr 2011, yvan volochine wrote:
and then (30 or more): .x8e3b590 no such object
Haven't seen that. I could check with pd (0.)43 again to see whether that's the bug that GridFlow had with it.
this appears also on pd-extended-0.42.5
With any patch, or only those using [display] or [#see] ?
it seems with patches using [display] but she got rid of the errors by cleaning the patch (looks like there were some zombies, like invisible sub-patches that were deleted but somehow were still there... weird)
(libs not found are libdc1394, libmpeg3, quicktime, ... although they are all installed and can all be found in /usr/include)
Send me your config.log.
here it is: http://pastebin.com/cPKhKSWQ
the nasm problem is fixed in 9.14 (it's a ./configure problem ; you can fix it using --force-nasm)
dc1394 is a bigger problem : the API was changed, and thus part of gridflow/src/dc1394.cxx would have to be rewritten, and I have no such camera. In addition, the laptop I just bought doesn't have any FireWire port (but I still have the other laptop).
so that means not building 9.13 for now
it seems that my friend needs those abstractions
Can't your friend use the ones bundled in the version of GridFlow that will be loaded ? No functionality got removed, but many patches depend on changes in abstractions, and some abstractions may depend on changes in other externals that are part of GridFlow, so, it's way better to not mix and match parts of different versions.
I was mentioning gridflow/abstractions from the one installed (9.12, not 9.13)
I thought that the bugs in the patch (random freezes, shutdown etc) might be related to those missing canvas/objects but I'm not sure..
I haven't had random shutdowns for three years now, and I don't remember ever having random freezes. If you think that the problem has to do with GUI objects, try making smaller versions of your patches that use less GUI objects and see whether the error messages and/or the freezes and/or the crashes disappear. You may notice patterns that will narrow down the possibilities, and then perhaps you'll have enough information to be able to write a bug report.
yeah it might come from the patch itself =)
ps: I uploaded
upgraded ?
jawohl
thanks for the infos! cheers, _y
salut Matthieu
another question:
is there a way to force gridflow external to load from a specified path?
ie: I'm trying to setup pd-vanilla wth gridflow-9.13 where the user already has pd-extended with gridflow-9.12.
(don't ask me why =)
gridflow.pd_linux (9.12) is in ~/pd-externals/gridflow gridflow.pd_linux (9.13) is in ~/pd-vanilla-externals/gridflow-9.13
problem is that pd -lib gridflow (with the new path to 9.13) still loads the one from pd-externals (9.12) although ~/pd-externals/gridflow is *not* in his path.
is there any workaround to this ?
cheers, _y
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-26 15:23, yvan volochine wrote:
salut Matthieu
another question:
is there a way to force gridflow external to load from a specified path?
ie: I'm trying to setup pd-vanilla wth gridflow-9.13 where the user already has pd-extended with gridflow-9.12.
(don't ask me why =)
gridflow.pd_linux (9.12) is in ~/pd-externals/gridflow gridflow.pd_linux (9.13) is in ~/pd-vanilla-externals/gridflow-9.13
problem is that pd -lib gridflow (with the new path to 9.13) still loads the one from pd-externals (9.12) although ~/pd-externals/gridflow is *not* in his path.
is there any workaround to this ?
~/pd-externals/ is _always_ in the path. you might be able to turn this off, by specifying "-nostdpath", though this will also turn off searching of .../pd/extra/
anyhow, if you add ~/pd-vanilla-externals/gridflow-9.13 to your search paths (e.g. using the "-path" flag) , then the gridflow found therein should take precedence over the one in ~/pd-externals/
fgmasdr IOhannes
On 04/26/2011 03:42 PM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-26 15:23, yvan volochine wrote:
salut Matthieu
another question:
is there a way to force gridflow external to load from a specified path?
ie: I'm trying to setup pd-vanilla wth gridflow-9.13 where the user already has pd-extended with gridflow-9.12.
(don't ask me why =)
gridflow.pd_linux (9.12) is in ~/pd-externals/gridflow gridflow.pd_linux (9.13) is in ~/pd-vanilla-externals/gridflow-9.13
problem is that pd -lib gridflow (with the new path to 9.13) still loads the one from pd-externals (9.12) although ~/pd-externals/gridflow is *not* in his path.
is there any workaround to this ?
~/pd-externals/ is _always_ in the path. you might be able to turn this off, by specifying "-nostdpath", though this will also turn off searching of .../pd/extra/
anyhow, if you add ~/pd-vanilla-externals/gridflow-9.13 to your search paths (e.g. using the "-path" flag) , then the gridflow found therein should take precedence over the one in ~/pd-externals/
I see.. I find this weird that this does not work if gridflow-9.13 is in my path in .pdsettings) but it does with pd -path xxx
also, `pd -path /path/to/gridflow-9.13' gives me: "GridFlow 9.13... GridFlow was compiled on Apr. 26 2011 [snip] /path/to/griflow-9.12/gridflow_x11.pd_linux undefined symbol... /path/to/griflow-9.12/gridflow_gem_loader.pd_linux undefined symbol... /path/to/griflow-9.12/gridflow_pdp.pd_linux undefined symbol... "
so I guess there is no workaround except removing 9.12 from pd-externals..
cheers, _y
I couldn't get Gridflow to work on any of my computers running different versions of windows (Win 7, 32 or 64 bit) and pd 0.43 (either vanilla or extended) whether or not there is a pd 0.42 install on the same computer and with similar binaries. I think there is some incompatibility at the moment between the pd 0.43 and gridflow. I wrote Mathieu about this a while ago.
pob
On 26/04/2011 15:42, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-26 15:23, yvan volochine wrote:
salut Matthieu
another question:
is there a way to force gridflow external to load from a specified path?
ie: I'm trying to setup pd-vanilla wth gridflow-9.13 where the user already has pd-extended with gridflow-9.12.
(don't ask me why =)
gridflow.pd_linux (9.12) is in ~/pd-externals/gridflow gridflow.pd_linux (9.13) is in ~/pd-vanilla-externals/gridflow-9.13
problem is that pd -lib gridflow (with the new path to 9.13) still loads the one from pd-externals (9.12) although ~/pd-externals/gridflow is *not* in his path.
is there any workaround to this ?
~/pd-externals/ is _always_ in the path. you might be able to turn this off, by specifying "-nostdpath", though this will also turn off searching of .../pd/extra/
anyhow, if you add ~/pd-vanilla-externals/gridflow-9.13 to your search paths (e.g. using the "-path" flag) , then the gridflow found therein should take precedence over the one in ~/pd-externals/
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEUEARECAAYFAk22y9kACgkQkX2Xpv6ydvQlqACg1zVeI++LdMvTsCpQeDupfWIy KaMAlR113eCpUS+k8dVmc6dx+YQMLqI= =tuB1 -----END PGP SIGNATURE-----
On 04/26/2011 03:53 PM, Pierre-Olivier Boulant wrote:
I couldn't get Gridflow to work on any of my computers running different versions of windows (Win 7, 32 or 64 bit) and pd 0.43 (either vanilla or extended) whether or not there is a pd 0.42 install on the same computer and with similar binaries. I think there is some incompatibility at the moment between the pd 0.43 and gridflow. I wrote Mathieu about this a while ago.
just reverted to gridflow-9.12 and so far it seems to work fine on pd-0.43 (vanilla) (& this machine runs ubuntu lucid)
cheers, _y
-
IOhannes m zmoelnig -
Mathieu Bouchard -
Pierre-Olivier Boulant -
yvan volochine