Hey IOhannes,
I would like to include the latest version of Gem in Pd-extended 0.43. It currently needs a little work. It builds on GNU/linux, but gives a missing symbol (something like _sync_foo_bar). It doesn't build on Mac OS X 10.5.
Do you think you'll have time to work on this in the near future?
.hc
----------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Hi, Hans,
I don't mean to get in the way here, but I just built Gem using the latest pd extended and its linux_make approach. Some examples don't work, but maybe that's another issue. When are you getting the _sync_foo_bar errors?
Best, Ricardo -- Linux registered user #175401 www.lems.brown.edu/~rfabbri
On Tue, Oct 18, 2011 at 5:47 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Hey IOhannes,
I would like to include the latest version of Gem in Pd-extended 0.43. It currently needs a little work. It builds on GNU/linux, but gives a missing symbol (something like _sync_foo_bar). It doesn't build on Mac OS X 10.5.
Do you think you'll have time to work on this in the near future?
.hc
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
I get it on Ubuntu/natty when Gem is loaded after Pd-extended starts.
/usr/lib/pd-extended/tcl/../extra/Gem/Gem.pd_linux: /usr/lib/pd-extended/tcl/../extra/Gem/Gem.pd_linux: undefined symbol: __sync_fetch_and_add_4 Gem: can't load library
.hc
I don't get that here. GEM loads. excuse my wild newbie-ish guess - perhaps try a make clean? that has rid me of many problems with pd lately.
Ricardo -- Linux registered user #175401 www.lems.brown.edu/~rfabbri
On Tue, Oct 18, 2011 at 7:36 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I get it on Ubuntu/natty when Gem is loaded after Pd-extended starts.
/usr/lib/pd-extended/tcl/../extra/Gem/Gem.pd_linux: /usr/lib/pd-extended/tcl/../extra/Gem/Gem.pd_linux: undefined symbol: __sync_fetch_and_add_4 Gem: can't load library
.hc
-- Hans-Christoph Steiner mobile: +1 347 850 4872 work: +1 718 360 4872
On Tuesday, October 18, 2011 7:32 PM, "Ricardo Fabbri" rfabbri@gmail.com wrote:
Hi, Hans,
I don't mean to get in the way here, but I just built Gem using the latest pd extended and its linux_make approach. Some examples don't work, but maybe that's another issue. When are you getting the _sync_foo_bar errors?
Best, Ricardo -- Linux registered user #175401 www.lems.brown.edu/~rfabbri
On Tue, Oct 18, 2011 at 5:47 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Hey IOhannes,
I would like to include the latest version of Gem in Pd-extended 0.43. It currently needs a little work. It builds on GNU/linux, but gives a missing symbol (something like _sync_foo_bar). It doesn't build on Mac OS X 10.5.
Do you think you'll have time to work on this in the near future?
.hc
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-18 23:46, Ricardo Fabbri wrote:
I don't get that here. GEM loads. excuse my wild newbie-ish guess - perhaps try a make clean? that has
unlikely. i think hans is talking about the nightly builds here, which are always started from "clean".
I get it on Ubuntu/natty when Gem is loaded after Pd-extended starts.
i wanted to try this on the build machine, but unfortunately cannot find it.
i logged into both i386 ubuntu machines listed on [1], and looked for compiled versions of Gem, and all loaded.
the lucid machine seems to have a natty chroot installed, but the Gem.pd_linux therein has been compiled on 2010/06/04 (hugh?) and btw loads fine.
how can i get access to a system with the broken binary?
fgmasdr IOhannes
[1] http://puredata.info/docs/developer/PdLab
On Oct 20, 2011, at 12:05 PM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-18 23:46, Ricardo Fabbri wrote:
I don't get that here. GEM loads. excuse my wild newbie-ish guess - perhaps try a make clean? that has
unlikely. i think hans is talking about the nightly builds here, which are always started from "clean".
I get it on Ubuntu/natty when Gem is loaded after Pd-extended starts.
i wanted to try this on the build machine, but unfortunately cannot find it.
i logged into both i386 ubuntu machines listed on [1], and looked for compiled versions of Gem, and all loaded.
the lucid machine seems to have a natty chroot installed, but the Gem.pd_linux therein has been compiled on 2010/06/04 (hugh?) and btw loads fine.
how can i get access to a system with the broken binary?
The GNU/Linux issue is fixed, with the __sync_bla_bla symbol.
About getting access to the chroots, they are on 128.238.56.50, 128.238.56.53, and 128.238.56.55. YOu can see them in /var/chroot. To use one, run:
dchroot -c wheezy -d
.hc
----------------------------------------------------------------------------
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/21/2011 09:23 PM, Hans-Christoph Steiner wrote:
The GNU/Linux issue is fixed, with the __sync_bla_bla symbol.
when? by whom? how?
you reported that bug, no changes happened on the Gem side, and 3 days lated, magically, the "issue is fixed"?
sorry that i got confused...
fasrd IOhannes
On Oct 23, 2011, at 12:05 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/21/2011 09:23 PM, Hans-Christoph Steiner wrote:
The GNU/Linux issue is fixed, with the __sync_bla_bla symbol.
when? by whom? how?
you reported that bug, no changes happened on the Gem side, and 3 days lated, magically, the "issue is fixed"?
sorry that i got confused...
I caused the problem by adding CPU/optimization flags to Gem's CXXFLAGS in externals/Makefile. I posted on some thread about it, I thought it was this one. To fix it, I just removed that change.
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/Makefi...
.hc
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-23 19:51, Hans-Christoph Steiner wrote:
On Oct 23, 2011, at 12:05 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/21/2011 09:23 PM, Hans-Christoph Steiner wrote:
The GNU/Linux issue is fixed, with the __sync_bla_bla symbol.
when? by whom? how?
you reported that bug, no changes happened on the Gem side, and 3 days lated, magically, the "issue is fixed"?
sorry that i got confused...
I caused the problem by adding CPU/optimization flags to Gem's CXXFLAGS in externals/Makefile. I posted on some thread about it, I thought it was this one. To fix it, I just removed that change.
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/Makefi...
ah, thanks for the clarification.
after re-reading the thread i notice that you mentioned that you "removed that, but haven't tested it again yet".
this was eventually overlooked by me, as it was in the same email with the 2 (then 3) questions for "definitive answers".
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-18 21:47, Hans-Christoph Steiner wrote:
Hey IOhannes,
I would like to include the latest version of Gem in Pd-extended 0.43. It currently needs a little work. It builds on GNU/linux, but gives a missing symbol (something like _sync_foo_bar).
it builds on "GNU/linux" without the missing symbols as well, else i coulldn't use it myself :-) i assume that this is on some ubuntu flavour (which one), with a certain compiler version (which one) and some special C(XX)FLAGS.
according to the internet, adding something like "-march=i486" to the C(XX)FLAGS should help.
It doesn't build on Mac OS X 10.5.
what does "latest Gem" mean here? the git version (which is indeed the 'latest') of Gem has the issue fixed. the 'svn' version (both trunk and branch/0.93) and the releases have it not fixed (yet).
if you want/must stick to the current release (which is fair enough) or svn, a very simple workaround would be to add /sw/bin to the beginning of the PATH before calling Gem's autogen.sh
fgmasdrt IOhannes
On Oct 20, 2011, at 4:09 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-18 21:47, Hans-Christoph Steiner wrote:
Hey IOhannes,
I would like to include the latest version of Gem in Pd-extended 0.43. It currently needs a little work. It builds on GNU/linux, but gives a missing symbol (something like _sync_foo_bar).
it builds on "GNU/linux" without the missing symbols as well, else i coulldn't use it myself :-) i assume that this is on some ubuntu flavour (which one), with a certain compiler version (which one) and some special C(XX)FLAGS.
according to the internet, adding something like "-march=i486" to the C(XX)FLAGS should help.
I think that one might be might fault. I made it so it set CFLAGS for Gem in externals/Makefile. I removed that, but haven't tested it again yet.
It doesn't build on Mac OS X 10.5.
what does "latest Gem" mean here? the git version (which is indeed the 'latest') of Gem has the issue fixed. the 'svn' version (both trunk and branch/0.93) and the releases have it not fixed (yet).
if you want/must stick to the current release (which is fair enough) or svn, a very simple workaround would be to add /sw/bin to the beginning of the PATH before calling Gem's autogen.sh
I am waiting on definitive answers on two questions, until then, I'm sticking to the current setup.
- are you dropping support for the Gem SVN?
- are you dropping support for building on Mac OS X 10.5 without Fink?
.hc
----------------------------------------------------------------------------
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." --Bjarne Stroustrup (creator of C++)
On Oct 20, 2011, at 12:20 PM, Hans-Christoph Steiner wrote:
On Oct 20, 2011, at 4:09 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-18 21:47, Hans-Christoph Steiner wrote:
Hey IOhannes,
I would like to include the latest version of Gem in Pd-extended 0.43. It currently needs a little work. It builds on GNU/linux, but gives a missing symbol (something like _sync_foo_bar).
it builds on "GNU/linux" without the missing symbols as well, else i coulldn't use it myself :-) i assume that this is on some ubuntu flavour (which one), with a certain compiler version (which one) and some special C(XX)FLAGS.
according to the internet, adding something like "-march=i486" to the C(XX)FLAGS should help.
I think that one might be might fault. I made it so it set CFLAGS for Gem in externals/Makefile. I removed that, but haven't tested it again yet.
It doesn't build on Mac OS X 10.5.
what does "latest Gem" mean here? the git version (which is indeed the 'latest') of Gem has the issue fixed. the 'svn' version (both trunk and branch/0.93) and the releases have it not fixed (yet).
if you want/must stick to the current release (which is fair enough) or svn, a very simple workaround would be to add /sw/bin to the beginning of the PATH before calling Gem's autogen.sh
I am waiting on definitive answers on two questions, until then, I'm sticking to the current setup.
are you dropping support for the Gem SVN?
are you dropping support for building on Mac OS X 10.5 without Fink?
Oops, one more question:
- are you planning on making Mac OS X builds?
.hc
----------------------------------------------------------------------------
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." --Bjarne Stroustrup (creator of C++)
I didn't realize there was an active Git repository for Gem. Although it is liked to at the Gem page (bottom-right link), the Pd getting soucres page only mentions the SVN. http://puredata.info/docs/developer/GettingPdSource
Which caused me to write further documentation based on that info.
So I would like to know if developers should abandon SVN so that I can update some docs at puredata.info. I am curious to hear the answers to Hans' questions.
Best, Ricardo Fabbri Linux registered user #175401
On Thu, Oct 20, 2011 at 2:59 PM, Hans-Christoph Steiner hans@at.or.at wrote:
On Oct 20, 2011, at 12:20 PM, Hans-Christoph Steiner wrote:
On Oct 20, 2011, at 4:09 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-18 21:47, Hans-Christoph Steiner wrote:
Hey IOhannes,
I would like to include the latest version of Gem in Pd-extended 0.43. It currently needs a little work. It builds on GNU/linux, but gives a missing symbol (something like _sync_foo_bar).
it builds on "GNU/linux" without the missing symbols as well, else i coulldn't use it myself :-) i assume that this is on some ubuntu flavour (which one), with a certain compiler version (which one) and some special C(XX)FLAGS.
according to the internet, adding something like "-march=i486" to the C(XX)FLAGS should help.
I think that one might be might fault. I made it so it set CFLAGS for Gem in externals/Makefile. I removed that, but haven't tested it again yet.
It doesn't build on Mac OS X 10.5.
what does "latest Gem" mean here? the git version (which is indeed the 'latest') of Gem has the issue fixed. the 'svn' version (both trunk and branch/0.93) and the releases have it not fixed (yet).
if you want/must stick to the current release (which is fair enough) or svn, a very simple workaround would be to add /sw/bin to the beginning of the PATH before calling Gem's autogen.sh
I am waiting on definitive answers on two questions, until then, I'm sticking to the current setup.
are you dropping support for the Gem SVN?
are you dropping support for building on Mac OS X 10.5 without Fink?
Oops, one more question:
- are you planning on making Mac OS X builds?
.hc
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." --Bjarne Stroustrup (creator of C++)
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
I am waiting on definitive answers on two questions, until then, I'm sticking to the current setup.
- are you dropping support for the Gem SVN?
i don't understand that question. what does "support for the SVN" mean?
i announced a switch to git, which means that any future development (and bug fixes) will be done in git. no future development is planned in svn.
as long as the svn is available and i find time, i'd like to sync at least release branches. it is not likely that "quick fixes" will make it (quickly) into svn.
- are you dropping support for building on Mac OS X 10.5 without Fink?
no, why do you think so? when doing my builds, i usually do not have fink installed at all. this also means that my tests are usually done without fink. any problems arising from fink are therefore less likely to get caught.
nevertheless i'm happy to point to quick fixes for given problems (like adding /sw/bin to the beginning of PATH before running Gem's autogen.sh)
Oops, one more question:
- are you planning on making Mac OS X builds?
yes; sorry that this takes so long.
fgnsard IOhannes
Small note:
I will update developer documentation in puredata.info to remove references to the Gem SVN. Moreover, IMHO abandon svn all the way, since having both the svn and the git repos around can be confusing (and has been). Not a big deal anyways.
Thanks. Ricardo Fabbri Linux registered user #175401
On Sat, Oct 22, 2011 at 1:07 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
I am waiting on definitive answers on two questions, until then, I'm sticking to the current setup.
- are you dropping support for the Gem SVN?
i don't understand that question. what does "support for the SVN" mean?
i announced a switch to git, which means that any future development (and bug fixes) will be done in git. no future development is planned in svn.
as long as the svn is available and i find time, i'd like to sync at least release branches. it is not likely that "quick fixes" will make it (quickly) into svn.
- are you dropping support for building on Mac OS X 10.5 without Fink?
no, why do you think so? when doing my builds, i usually do not have fink installed at all. this also means that my tests are usually done without fink. any problems arising from fink are therefore less likely to get caught.
nevertheless i'm happy to point to quick fixes for given problems (like adding /sw/bin to the beginning of PATH before running Gem's autogen.sh)
Oops, one more question:
- are you planning on making Mac OS X builds?
yes; sorry that this takes so long.
fgnsard IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hey Ricardo,
Its great that you are doing that. That reminds me, since you are getting deeper into Pd development, and are working on Gem-related stuff, I think your attention is most needed on Gem itself. Gem is hosted in a separate sourceforge project, so you have to ask IOhannes for commit access, if the new git repo is going to work like that.
A great place to start is the details, like you already have. Then also any deployment details. I've been working on my 'load every help' automated test script and find it very valuable for finding problems. The Gem reference is not included yet because it needs to run in the GUI, and the current script runs 'pd -nogui', but I'll try to get a GUI version running too so we can test the Gem stuff too.
.hc
On Oct 22, 2011, at 12:33 PM, Ricardo Fabbri wrote:
Small note:
I will update developer documentation in puredata.info to remove references to the Gem SVN. Moreover, IMHO abandon svn all the way, since having both the svn and the git repos around can be confusing (and has been). Not a big deal anyways.
Thanks. Ricardo Fabbri Linux registered user #175401
On Sat, Oct 22, 2011 at 1:07 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
I am waiting on definitive answers on two questions, until then, I'm sticking to the current setup.
- are you dropping support for the Gem SVN?
i don't understand that question. what does "support for the SVN" mean?
i announced a switch to git, which means that any future development (and bug fixes) will be done in git. no future development is planned in svn.
as long as the svn is available and i find time, i'd like to sync at least release branches. it is not likely that "quick fixes" will make it (quickly) into svn.
- are you dropping support for building on Mac OS X 10.5 without
Fink?
no, why do you think so? when doing my builds, i usually do not have fink installed at all. this also means that my tests are usually done without fink. any problems arising from fink are therefore less likely to get caught.
nevertheless i'm happy to point to quick fixes for given problems (like adding /sw/bin to the beginning of PATH before running Gem's autogen.sh)
Oops, one more question:
- are you planning on making Mac OS X builds?
yes; sorry that this takes so long.
fgnsard IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Hello Hans and IOhannes,
As far as Pd development goes, I am mostly interested in Gem-related code, yes. So I can be of help. Feel free to ask me for stuff, I will tell you if I have time for it. My colleagues are having build troubles with Gem, so I am motivated to help out on that as well.
Personally I really like the fact that Gem is in Git now. But that's not from a build-maintainer's point of view, but from a developer's.
During my development work, in all projects I participate I don't like to maintain binary packages for any other system than Linux. That's because my help can only be more effective in the environment I use and am familiar with.
If Hans wants to guide me through things, perhaps we could schedule some time in #dataflow to go through these rusty build scripts and I can help with that, as it also helps me get really familiar with the source code. Note, again, that I have little motivation to deal with systems other than Linux (Mac OS, so-so, but for Windows we would need to rely on other voluntaries). But I can think about other systems minimally, of course, such as when writing portable code. It is maintaining binaries that I don't really think I am capable of alone.
Iohannes - I will definitely work on Gem-related developent during this week. I can help you out and, since I already went through a selection process in pd-extended, perhaps you can trust my help. If you need, I can put myself at your disposal, as time permits. Even when you don't have much time to guide me, providing minimal pointers for any task at hand should be enough.
Best regards, Ricardo Fabbri Linux registered user #175401 http://www.lems.brown.edu/~rfabbri/
On Sat, Oct 22, 2011 at 5:23 PM, Hans-Christoph Steiner hans@at.or.at wrote:
hey Ricardo,
Its great that you are doing that. That reminds me, since you are getting deeper into Pd development, and are working on Gem-related stuff, I think your attention is most needed on Gem itself. Gem is hosted in a separate sourceforge project, so you have to ask IOhannes for commit access, if the new git repo is going to work like that.
A great place to start is the details, like you already have. Then also any deployment details. I've been working on my 'load every help' automated test script and find it very valuable for finding problems. The Gem reference is not included yet because it needs to run in the GUI, and the current script runs 'pd -nogui', but I'll try to get a GUI version running too so we can test the Gem stuff too.
.hc
On Oct 22, 2011, at 12:33 PM, Ricardo Fabbri wrote:
Small note:
I will update developer documentation in puredata.info to remove references to the Gem SVN. Moreover, IMHO abandon svn all the way, since having both the svn and the git repos around can be confusing (and has been). Not a big deal anyways.
Thanks. Ricardo Fabbri Linux registered user #175401
On Sat, Oct 22, 2011 at 1:07 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
I am waiting on definitive answers on two questions, until then, I'm sticking to the current setup.
- are you dropping support for the Gem SVN?
i don't understand that question. what does "support for the SVN" mean?
i announced a switch to git, which means that any future development (and bug fixes) will be done in git. no future development is planned in svn.
as long as the svn is available and i find time, i'd like to sync at least release branches. it is not likely that "quick fixes" will make it (quickly) into svn.
- are you dropping support for building on Mac OS X 10.5 without Fink?
no, why do you think so? when doing my builds, i usually do not have fink installed at all. this also means that my tests are usually done without fink. any problems arising from fink are therefore less likely to get caught.
nevertheless i'm happy to point to quick fixes for given problems (like adding /sw/bin to the beginning of PATH before running Gem's autogen.sh)
Oops, one more question:
- are you planning on making Mac OS X builds?
yes; sorry that this takes so long.
fgnsard IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Great to hear, Ricardo! No worries about which platform you work on, most of the dev work is for all platforms. All contributions are helpful. A good place to start is bugs like this:
http://sourceforge.net/tracker/?func=detail&aid=3425455&group_id=643...
Basically, a lot of help patches have paths to the example media, like images and movies, in the old location. Now, Gem is distributed as a all-in-one folder, so the paths can be updated to be relative paths and they'll work on all platforms and installs.
.hc
On Oct 23, 2011, at 5:01 PM, Ricardo Fabbri wrote:
Hello Hans and IOhannes,
As far as Pd development goes, I am mostly interested in Gem-related code, yes. So I can be of help. Feel free to ask me for stuff, I will tell you if I have time for it. My colleagues are having build troubles with Gem, so I am motivated to help out on that as well.
Personally I really like the fact that Gem is in Git now. But that's not from a build-maintainer's point of view, but from a developer's.
During my development work, in all projects I participate I don't like to maintain binary packages for any other system than Linux. That's because my help can only be more effective in the environment I use and am familiar with.
If Hans wants to guide me through things, perhaps we could schedule some time in #dataflow to go through these rusty build scripts and I can help with that, as it also helps me get really familiar with the source code. Note, again, that I have little motivation to deal with systems other than Linux (Mac OS, so-so, but for Windows we would need to rely on other voluntaries). But I can think about other systems minimally, of course, such as when writing portable code. It is maintaining binaries that I don't really think I am capable of alone.
Iohannes - I will definitely work on Gem-related developent during this week. I can help you out and, since I already went through a selection process in pd-extended, perhaps you can trust my help. If you need, I can put myself at your disposal, as time permits. Even when you don't have much time to guide me, providing minimal pointers for any task at hand should be enough.
Best regards, Ricardo Fabbri Linux registered user #175401 http://www.lems.brown.edu/~rfabbri/
On Sat, Oct 22, 2011 at 5:23 PM, Hans-Christoph Steiner hans@at.or.at wrote:
hey Ricardo,
Its great that you are doing that. That reminds me, since you are getting deeper into Pd development, and are working on Gem-related stuff, I think your attention is most needed on Gem itself. Gem is hosted in a separate sourceforge project, so you have to ask IOhannes for commit access, if the new git repo is going to work like that.
A great place to start is the details, like you already have. Then also any deployment details. I've been working on my 'load every help' automated test script and find it very valuable for finding problems. The Gem reference is not included yet because it needs to run in the GUI, and the current script runs 'pd -nogui', but I'll try to get a GUI version running too so we can test the Gem stuff too.
.hc
On Oct 22, 2011, at 12:33 PM, Ricardo Fabbri wrote:
Small note:
I will update developer documentation in puredata.info to remove references to the Gem SVN. Moreover, IMHO abandon svn all the way, since having both the svn and the git repos around can be confusing (and has been). Not a big deal anyways.
Thanks. Ricardo Fabbri Linux registered user #175401
On Sat, Oct 22, 2011 at 1:07 PM, IOhannes m zmoelnig <zmoelnig@iem.at
wrote:
I am waiting on definitive answers on two questions, until then, I'm sticking to the current setup.
- are you dropping support for the Gem SVN?
i don't understand that question. what does "support for the SVN" mean?
i announced a switch to git, which means that any future development (and bug fixes) will be done in git. no future development is planned in svn.
as long as the svn is available and i find time, i'd like to sync at least release branches. it is not likely that "quick fixes" will make it (quickly) into svn.
- are you dropping support for building on Mac OS X 10.5
without Fink?
no, why do you think so? when doing my builds, i usually do not have fink installed at all. this also means that my tests are usually done without fink. any problems arising from fink are therefore less likely to get caught.
nevertheless i'm happy to point to quick fixes for given problems (like adding /sw/bin to the beginning of PATH before running Gem's autogen.sh)
Oops, one more question:
- are you planning on making Mac OS X builds?
yes; sorry that this takes so long.
fgnsard IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
----------------------------------------------------------------------------
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-24 05:31, Hans-Christoph Steiner wrote:
Great to hear, Ricardo!
indeed, thanks for volunteering.
No worries about which platform you work on, most of the dev work is for all platforms. All contributions are helpful. A good place to start is bugs like this:
http://sourceforge.net/tracker/?func=detail&aid=3425455&group_id=643...
Basically, a lot of help patches have paths to the example media, like images and movies, in the old location. Now, Gem is distributed as a all-in-one folder, so the paths can be updated to be relative paths and they'll work on all platforms and installs.
couldn't have said that better :-) check both the bugs and feature-request trackers for a good start...
the big TODO for 0.94 is window management: partly running code can be found in src/Output, but i still :-( have to write a round-up of how i think it should work in the end and how to try out what is already there
mfgR IOhannes
Hi, IOhannes,
That all sounds great. I have been working a lot with Gem this week and will be submitting many patches, many of them small to get started, but important IMHO.
I can push to my own repo online then send you a request to pull from that. However, I guess that depends on how much time you have in your hands. The rw access to the main repo is the fastest way for small changes that you can later review through the commit log at your leisure, so I annoy you less, and so that the community can get the changes quickly. I could even agree with you to commit medium to large changes on a specific branch. We can spend some time building trust, but I have been working fine with Hans and Lluis on pd extended, so you can take their opinion to begin with.
Here is a 1-line patch to Output/Makefile.am, but very significant since it fixes broken Gem builds with newer automake:
https://sourceforge.net/tracker/?func=detail&aid=3429037&group_id=64...
I have already mailed that Makefile.am out to a few people who can't wait for the main repo to be updated (I work on a distributed team).. It would be nice to have a faster track as mentioned above for these sorts of small fixes to reach the community. Hans can testify that I have properly asked him for permission before committing further things to pd-extended, you can bet I will also be acting carefully with the Gem source code.
Best, Ricardo Fabbri -- Linux registered user #175401 labmacambira.sf.net
On Mon, Oct 24, 2011 at 12:03 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-24 05:31, Hans-Christoph Steiner wrote:
Great to hear, Ricardo!
indeed, thanks for volunteering.
No worries about which platform you work on, most of the dev work is for all platforms. All contributions are helpful. A good place to start is bugs like this:
http://sourceforge.net/tracker/?func=detail&aid=3425455&group_id=643...
Basically, a lot of help patches have paths to the example media, like images and movies, in the old location. Now, Gem is distributed as a all-in-one folder, so the paths can be updated to be relative paths and they'll work on all platforms and installs.
couldn't have said that better :-) check both the bugs and feature-request trackers for a good start...
the big TODO for 0.94 is window management: partly running code can be found in src/Output, but i still :-( have to write a round-up of how i think it should work in the end and how to try out what is already there
mfgR IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6lcC8ACgkQkX2Xpv6ydvR0mwCdFTC2MnlLzEIScvkeuepvdTSv AaUAnjngfmL2366B3fjQiz8RKa+hMTJ7 =UwY0 -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Oct 22, 2011, at 11:07 AM, IOhannes m zmoelnig wrote:
I am waiting on definitive answers on two questions, until then, I'm sticking to the current setup.
- are you dropping support for the Gem SVN?
i don't understand that question. what does "support for the SVN" mean?
i announced a switch to git, which means that any future development (and bug fixes) will be done in git. no future development is planned in svn.
as long as the svn is available and i find time, i'd like to sync at least release branches. it is not likely that "quick fixes" will make it (quickly) into svn.
Thanks for answering my questions.
Like I said before, this will unfortunately greatly limit the work that I can do on Gem. I have much less time to spend on Pd dev work these days due to having and supporting a family. Currently I work on gem as part of the Pd-extended releases. I mostly do lots of little fixes like getting the paths to example media right in the help files, and other things like that. Things that mostly newbies and students notice, since teaching intros is the only thing I do with Gem. That's all integrated in the pure-data SVN nicely.
As for the gem git process, I don't really know what it is. I assume its like pure-data.git, so I submitted a patch, and updated it based on your feedback, and its still open with no comment almost a month later.
http://sourceforge.net/tracker/?func=detail&aid=3414731&group_id=643...
We definitely need to get more people involved in Gem dev, I hope that the git will make that easier. My two bits is that this move to git felt to me like a decision made by you, IOhannes, without input from other committers. Yes, you do the vast majority of the work on Gem these days, but I think it would have been good to include other committers in the discussion.
- are you dropping support for building on Mac OS X 10.5 without
Fink?
no, why do you think so? when doing my builds, i usually do not have fink installed at all. this also means that my tests are usually done without fink. any problems arising from fink are therefore less likely to get caught.
nevertheless i'm happy to point to quick fixes for given problems (like adding /sw/bin to the beginning of PATH before running Gem's autogen.sh)
The current setup with the fink paths last has been there a long time, and everything worked fine with it in the past, including Gem. The key idea there, IIRC, is that it provides a way to make sure that builds work with the internal tools, and only get things from Fink that Mac OS X does not provide. I believe this was done to help test things like Gem's support for plain Mac OS X, but I could be wrong.
Oops, one more question:
- are you planning on making Mac OS X builds?
yes; sorry that this takes so long.
I'm thinking that for Gem in Pd-extended, I'll use the Gem binaries then. For Debian/Ubuntu, I'll just make the package depend on 'gem'. Then for Mac OS X and Windows, use the builds posted on gem.iem.at. That's is already the case for Windows and has been for a while. For the 0.43 Pd-extended release, I think I'll do one last cycle of importing the release source into Pd-extended release branch and working from there.
.hc
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/22/2011 09:20 PM, Hans-Christoph Steiner wrote:
As for the gem git process, I don't really know what it is. I assume its like pure-data.git, so I submitted a patch, and updated it based on your feedback, and its still open with no comment almost a month later.
thanks for submitting a patch.
in case you are interested, i have a number of patches in the puredata patch-tracker which have not been answered by miller.
The current setup with the fink paths last has been there a long time, and everything worked fine with it in the past, including Gem. The key
and then something changed: you upgraded the build host to 10.5 and it stopped working. i'm not saying that you are to blame, and indeed the autogen.sh file _is_ buggy; i'm only suggesting how you could generate a build without having to switch to git (which it seems you don't want to do, as it doesn't integrate nicely into the current svn setup)
idea there, IIRC, is that it provides a way to make sure that builds work with the internal tools, and only get things from Fink that Mac OS X does not provide. I believe this was done to help test things like Gem's support for plain Mac OS X, but I could be wrong.
i cannot remember anything about the whys and hows, so i cannot help here. however, your statement makes me a bit confused, as i thought that the pd-extended autobuild process is _not_ about testing things, but rather about getting consistent pd-extended builds.
Oops, one more question:
- are you planning on making Mac OS X builds?
yes; sorry that this takes so long.
I'm thinking that for Gem in Pd-extended, I'll use the Gem binaries then. For Debian/Ubuntu, I'll just make the package depend on 'gem'.
btw, my osx binaries will not be build against gmerlin,... and the like, only OSX internals (QuickTime or whatever); FTGL will be statically linked.
fgmasdr IOhannes
On Oct 23, 2011, at 12:01 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/22/2011 09:20 PM, Hans-Christoph Steiner wrote:
As for the gem git process, I don't really know what it is. I assume its like pure-data.git, so I submitted a patch, and updated it based on your feedback, and its still open with no comment almost a month later.
thanks for submitting a patch.
in case you are interested, i have a number of patches in the puredata patch-tracker which have not been answered by miller.
I'm just trying to get some clarity on what your new process is with Gem, now that its in git.
The current setup with the fink paths last has been there a long time, and everything worked fine with it in the past, including Gem. The key
and then something changed: you upgraded the build host to 10.5 and it stopped working. i'm not saying that you are to blame, and indeed the autogen.sh file _is_ buggy; i'm only suggesting how you could generate a build without having to switch to git (which it seems you don't want to do, as it doesn't integrate nicely into the current svn setup)
I prefer git over svn, sure. I just don't have much time to spend on Pd these days, so I need to prioritize, and switching to managing Gem from git isn't something I have time for. The Pd-extended build setup is old and kludgey, so it is not so flexible. If anyone else want to take that on, I'm open to it. And I'm trying to nail down the core Pd 0.43 bugs before I have to disappear for a bit.
idea there, IIRC, is that it provides a way to make sure that builds work with the internal tools, and only get things from Fink that Mac OS X does not provide. I believe this was done to help test things like Gem's support for plain Mac OS X, but I could be wrong.
i cannot remember anything about the whys and hows, so i cannot help here. however, your statement makes me a bit confused, as i thought that the pd-extended autobuild process is _not_ about testing things, but rather about getting consistent pd-extended builds.
First and foremost, it is about getting consistent Pd-extended builds. But it also clearly serves as a testing platform as well. But that comes second.
Oops, one more question:
- are you planning on making Mac OS X builds?
yes; sorry that this takes so long.
I'm thinking that for Gem in Pd-extended, I'll use the Gem binaries then. For Debian/Ubuntu, I'll just make the package depend on 'gem'.
btw, my osx binaries will not be build against gmerlin,... and the like, only OSX internals (QuickTime or whatever); FTGL will be statically linked.
I can't see any problem with that. I think the only difference between the versions included in Pd-extended is that FTGL is dynamically linked.
.hc
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-23 19:52, Hans-Christoph Steiner wrote:
On Oct 23, 2011, at 12:01 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/22/2011 09:20 PM, Hans-Christoph Steiner wrote:
As for the gem git process, I don't really know what it is. I assume its like pure-data.git, so I submitted a patch, and updated it based on your feedback, and its still open with no comment almost a month later.
thanks for submitting a patch.
in case you are interested, i have a number of patches in the puredata patch-tracker which have not been answered by miller.
I'm just trying to get some clarity on what your new process is with Gem, now that its in git.
ok. for the odd patch every now and then, i do think that the patch tracker is the easiest way to go. for regular patches, i could either grant rw-access, or a contributor publishes their git clone, so i can pull in changes.
gmdsf IOhannes