<tupi>guilers, it sounds like I succeeded [locally] updating our guile-clutter binding from 1.10 to 1.12.2. wip, far from complete yet, but it runs my previous examples. now, it gives me a weird error on make check, which does not seem related to guile-clutter itself, am I right to think so? note that I still run guile 2.0.9.106-7bc28 [did not have the time to update yet... will do soon]. here is the error: <civodul>tupi: that's because you have a stale .go built with 2.2 <civodul>that's an Automake issue, about TESTS_ENVIRONMENT <civodul>nowadays TESTS_ENVIRONMENT must contain only env. var. settings <civodul>whereas in the past it could contain the name of an interpreter, typically <civodul>the fix is to use AM_TEST_COMPILER instead <tupi>civodul: can you guide me step by step? which file should I update? <tupi>tests/Makefile.amhas 2 lines only <tupi>include ../tests.mk \\ wrapset_stem = clutter <tupi>here is the ../tests.mk [will paste in a sec] <tupi>civodul: maybe you can point a recent change somewhere else, I can try ... <tupi>but this file is really small it would be nice to have your help <civodul>keep: TESTS_ENVIRONMENT=$(WRAPSET_TESTS_ENV) $(DEV_ENV) <tupi>could you rather update the paste? <civodul>add: SCM_LOG_COMPILER = $(GUILE) $(GUILE_FLAGS) -e main -s <civodul>info "(automake) Parallel Test Harness" <tupi>TESTS_ENVIRONMENT=$(WRAPSET_TESTS_ENV) $(DEV_ENV) <tupi>SCM_LOG_COMPILER = $(GUILE) $(GUILE_FLAGS) -e main -s ***linas__ is now known as linas
<tupi>guile-clutter wrapset.scm file starts with these 2 lines: (use-modules (unit-test) (apicheck) ...) it complains it can't find (unit-test), is it not part of guile itself? <tupi>ok, unit-test is part of guile-lib <tupi>great, guile-clutter 1.12.2 make test pass! still a lot to do but this is good news ***wingo_ is now known as wingo
<taylanub>The REPL always drives me insane for not having paredit :( <taylanub>hrm, paredit's support for broken paren balance was better after a pair of glitches I reported to Riastradth, maybe it can work fine in the REPL now (where balance inevitably gets broken) <taylanub>ijp: As the backlog limit is hit, singular parantheses get eaten up <ijp>I have never noticed this <taylanub>At least that's what I remember having experienced when I tried paredit for the Guile REPL back then. <ijp>what do you mean backlog limit? <taylanub>Though even if that were resolved (by only deleting whole s-expressions from the top of the buffer), something can always print arbitrary characters ... <taylanub>ijp: the *Guile REPL* buffer has a size limit, no ? <ijp>well, there is one, the same as the file limit <taylanub>OK, if there is a limit, it's quite big. :P <ijp>640k lines ought to be enough for anyone <taylanub>Well in any case balance can break due to output ... hrm, how about Geiser somehow comments output ? <ijp>yes, it is certainly possible with output <ijp>taylanub: ping jao about it <mark_weaver>If people haven't already seen it, I _highly_ recommend watching Jacob Appelbaum's keynote at 30c3, entitled "To Protect and Infect Part 2". <davexunit>that was a great talk. watched it earlier this week. <civodul>though i wonder why one would ever want to do that <bhattigurjot>for the experimental purposes.. and I didn't compile it... <bhattigurjot>"dpkg: warning: ignoring request to remove guile which isn't installed" <mark_weaver>guile is not the name of the package. use "dpkg -l guile\\* libguile\\*" to find the package names. <bhattigurjot>and the astonishing this that there isnt a guile directory there in /usr/lib/ but it still shows the result when I run "locate guile" <pallagun>bhattigurjot: update your locate database? <ijp>the locate database usually only gets updated once a day <ijp>locales are something completely different <pallagun>I'm trying to follow the smob-example. for some reason I'm getting a seg fault on my first line, which is: point2_type = scm_make_smob_type("point2", sizeof(Point2)); -- GDB won't really step in there to show me what is going wrong. Any advice? <wingo>pallagun: you probably forgot to scm_init_guile <mark_weaver>bhattigurjot: that's because autoconf didn't find guile.m4 in the ACLOCAL_PATH *mark_weaver goes afk for a while <bhattigurjot>and how do I do that?.. AFAIK, aclocal command should have taken care of it.. but it didn't <ijp>if it was built from a tarball, bhattigurjot shouldn't have needed to do an autoreconf, right? <ijp>bhattigurjot: tarball or source checkout? <ijp>if you got from git, run autogen.sh <ijp>bhattigurjot: so you didn't get it from git? <ijp>of course, you were talking about a completely different piece of software <mark_weaver>bhattigurjot: if you installed guile in /usr/local, then you probably want to set ACLOCAL_PATH to /usr/local/share/aclocal before running "autoreconf -vfi" in drgeo <bhattigurjot>yes the result of the command " sudo find /usr -name libguile.h" is "/usr/local/include/guile/2.0/libguile.h" <mark_weaver>ijp: bhattigurjot is working on reviving drgeo, including getting it working with guile-2.0 (it currently requires 1.6) <bhattigurjot>mark_weaver: that worked but now back to the yesterday's error <mark_weaver>maybe you need to set PKG_CONFIG_PATH to /usr/local/lib/pkgconfig before running ./configure <mark_weaver>somehow, the -I option from 'pkg-config --cflags guile-2.0" is not getting to the compiler. <mark_weaver>maybe it's because the Makefile.am's use INCLUDES instead of AM_CPPFLAGS or whatever. <mark_weaver>bhattigurjot: this is probably not related to the problem you're seeing now, but in that build script you posted, I think you should remove the 'aclocal' call, and move 'intltoolize' before 'autoreconf'. 'autoreconf' calls 'aclocal'. <mark_weaver>actually, I see that 'autoreconf' calls libtoolize also. <bhattigurjot>mark_weaver: so "intltoolize --force"-->"autoreconf -vfi"-->"./configure --prefix=/usr"