Hallo!
this an implementation detail of [linebreak] ;-) (and linebreak shouldn't be part of Gem)
yes, but then you would have to say in each patch "use that external" etc. - now everything would be in one object (okay, it's a little bit more high level - but easy to use - and you can still use it as it was, with linebreak <= 0 ...)
anyway, I don't have the time now to rewrite everything again - so I will leave it as it is for now ...
i'm off for spain now ;-)
good luck and have fun ...
LG Georg
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hi gang,
On Sep 5, 2005, at 9:10 AM, Georg Holzmann wrote:
anyway, I don't have the time now to rewrite everything again - so I will leave it as it is for now ...
i'm off for spain now ;-)
good luck and have fun ...
...while trying to link the latest cvs on osx, I get the following:
/usr/bin/ld: Undefined symbols: _inflate _inflateEnd _inflateInit2_ _inflateReset collect2: ld returned 1 exit status
...the weird thing is that "find" does not find an instance of any of these being called within the GEM project! Also, not being a super stl guy, I'm suspicious that it is somehow related to georg's textbase changes, specifically the following in Base/TextBase.h:
#include <vector> #include <string>
...any ideas on how to fix this?
jamie
Hallo!
...while trying to link the latest cvs on osx, I get the following:
//usr/bin/ld: Undefined symbols:/ /_inflate/ /_inflateEnd/ /_inflateInit2_/ /_inflateReset/ /collect2: ld returned 1 exit status/
hm - don't know - if I search google with _inflate etc. I get a lot of problems with zlib or libz ... ? (don't know where this lib should be used in gem ...)
...the weird thing is that "find" does not find an instance of any of these being called within the GEM project! Also, not being a super stl guy, I'm suspicious that it is somehow related to georg's textbase changes, specifically the following in Base/TextBase.h:
#include <vector> #include <string>
...any ideas on how to fix this?
I don't know if this is related to STL, but STL is also working on mac and is also supported by all major compilers, isn't it? (and I have unfortunately no experience with compiling on os-x ...)
LG Georg
jamie
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Quoting Georg Holzmann grhPD@gmx.at:
Hallo!
...while trying to link the latest cvs on osx, I get the following:
//usr/bin/ld: Undefined symbols:/ /_inflate/ /_inflateEnd/ /_inflateInit2_/ /_inflateReset/ /collect2: ld returned 1 exit status/
hm - don't know - if I search google with _inflate etc. I get a lot of
i did too (but i just searched for inflateReset); and i did a rgrep in my /usr/include
and tata:
problems with zlib or libz ... ? (don't know where this lib should be used in gem ...)
yes it seems to be zlib related. (zib is used by freetype and by png and and and)
jamie: do you have zlib installed (and linking against it) ??
just a funny suggestion: you could try to include the stl-headers (<string> and <vector> _after_ all the other includes (especially the FTFont.h) this might work (but i don't know)
mfg..adsr IOhannes
On Sep 7, 2005, at 10:26 AM, zmoelnig@iem.at wrote:
yes it seems to be zlib related. (zib is used by freetype and by png and and and)
jamie: do you have zlib installed (and linking against it) ??
just a funny suggestion: you could try to include the stl-headers (<string> and <vector> _after_ all the other includes (especially the FTFont.h) this might work (but i don't know)
...well, changing the location of the stl-headers didn't work, but adding -lz to the linking phase did! Now I need to figure out why it's all of a sudden necessary (probably need to recompile FTGL, since I'd been linking it in statically)...
thanx, jamie
james tittle wrote:
...well, changing the location of the stl-headers didn't work, but adding -lz to the linking phase did! Now I need to figure out why it's all of a sudden necessary (probably need to recompile FTGL, since I'd been linking it in statically)...
well, i too link ftgl statically.
but what bothers me a bit is, why configure does not add "-lz" by itself. i see it is checking for "main", probably we should check for something more specific to libz.
mfg.asd.r IOhannes
On Sep 12, 2005, at 6:04 AM, IOhannes m zmoelnig wrote:
james tittle wrote:
...well, changing the location of the stl-headers didn't work, but adding -lz to the linking phase did! Now I need to figure out why it's all of a sudden necessary (probably need to recompile FTGL, since I'd been linking it in statically)...
well, i too link ftgl statically.
but what bothers me a bit is, why configure does not add "-lz" by itself. i see it is checking for "main", probably we should check for something more specific to libz.
...don't worry too much about this, as this "bug" only came up when I started to work with the xcode project file again, so it's probably not an issue with configure/make :-)
...btw, good to see you on the "hackitectura" video talk with miller!
l8r, jamie
hi gem-devs
first of all, sorry for posting on this thread, without reading it ... but it might be related to the recent changes in this class
after updating to todays cvs, i'm not able to run my gem patch any more:
after this error message: terminate called after throwing an instance of 'std::bad_alloc' what(): St9bad_alloc Pd: signal 6
trying to find this with valgrind, i get the following trace:
**25539** new/new[] failed and should throw an exception, but Valgrind cannot throw exceptions and so is aborting instead. Sorry. ==25539== at 0x1B8FC782: VALGRIND_PRINTF_BACKTRACE (in /usr/lib/valgrind/vg_inject.so) ==25539== by 0x1B9046C8: operator new(unsigned) (in /usr/lib/valgrind/vgpreload_memcheck.so) ==25539== by 0x1C1F637B: std::vector<float, std::allocator<float> >::_M_insert_aux(__gnu_cxx::__normal_iterator<float*, std::vector<float, std::allocator<float> > >, float const&) (in /home/tim/pd/extra/Gem.pd_linux) ==25539== by 0x1C1F4801: TextBase::makeLineDist() (in /home/tim/pd/extra/Gem.pd_linux) ==25539== by 0x1C1F4898: TextBase::setJustification(TextBase::JustifyWidth, TextBase::JustifyHeight) (in /home/tim/pd/extra/Gem.pd_linux) ==25539== by 0x1C1F24E1: TextBase::justifyMessCallback(void*, _symbol*, int, _atom*) (in /home/tim/pd/extra/Gem.pd_linux) ==25539== by 0x809CBB1: pd_typedmess (in /usr/local/bin/pd) ==25539== by 0x809EFB4: outlet_anything (in /usr/local/bin/pd) ==25539== by 0x1B90CC54: init_bang (in /home/tim/pd/extra/init.pd_linux) ==25539== by 0x809CB64: pd_typedmess (in /usr/local/bin/pd) ==25539== by 0x809D39B: pd_vmess (in /usr/local/bin/pd) ==25539== by 0x807AFC4: canvas_loadbang (in /usr/local/bin/pd)
i somehow have the feeling, that there is a really bad memory leak in the "justify" method, that eats about all my memory in less than 15 seconds ...
no time to look into it now ... need to get proper commas first ...
cheers ... tim
Hallo!
i somehow have the feeling, that there is a really bad memory leak in the "justify" method, that eats about all my memory in less than 15 seconds ...
hm - I will look into it - it probably depends on my changes ... anyway, I haven't those problems here - but I'm using an other source ...
LG Georg
Georg Holzmann wrote:
Hallo!
i somehow have the feeling, that there is a really bad memory leak in the "justify" method, that eats about all my memory in less than 15 seconds ...
hm - I will look into it - it probably depends on my changes ... anyway, I haven't those problems here - but I'm using an other source ...
the problem was an unsigned integer that was tested for negative values; since it never was, the loop it controlled went crazy.
it is fixed in the CVS (and the bug that stopped compiling Gem @ TextBase.cpp when you don't have FTGL installed)
mfg.asd.r IOhannes
Hallo!
the problem was an unsigned integer that was tested for negative values; since it never was, the loop it controlled went crazy.
it is fixed in the CVS (and the bug that stopped compiling Gem @ TextBase.cpp when you don't have FTGL installed)
thanks - could you say me where (didn't found an unsigned integer in textbase) the problem is (because I have an other source here as you know and also need to fix it ...)
thanks, LG Georg
Georg Holzmann wrote:
Hallo!
the problem was an unsigned integer that was tested for negative values; since it never was, the loop it controlled went crazy.
it is fixed in the CVS (and the bug that stopped compiling Gem @ TextBase.cpp when you don't have FTGL installed)
thanks - could you say me where (didn't found an unsigned integer in textbase) the problem is (because I have an other source here as you know and also need to fix it ...)
in TextBase :: makeLineDist() the "i" was defined "unsigned integer"
it seems like i am guilty for introducing this bug, since i am not able to locate it in your sources (as they are on your homepage)
mfg.a.er IOhannes
thanks, LG Georg
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hallo!
in TextBase :: makeLineDist() the "i" was defined "unsigned integer"
it seems like i am guilty for introducing this bug, since i am not able to locate it in your sources (as they are on your homepage)
thanks for checking - yes, there is no unsigned here ...
LG Georg
-
Georg Holzmann -
IOhannes m zmoelnig -
james tittle -
Tim Blechmann -
zmoelnig＠iem.at