IRC channel logs


back to list of logs

<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 [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>hence the "ELF" here
<civodul>aah no, wait
<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 ../ \\ wrapset_stem = clutter
<tupi>here is the ../ [will paste in a sec]
<civodul>lemme see
<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>and then...
<tupi>could you rather update the paste?
<tupi>if I may ask :)
<civodul>add: SCM_LOG_COMPILER = $(GUILE) $(GUILE_FLAGS) -e main -s
<civodul>i was about to leave so ;-)
<tupi>stay 1min please :)
<civodul>info "(automake) Parallel Test Harness"
<tupi>like this?
<tupi>SCM_LOG_COMPILER = $(GUILE) $(GUILE_FLAGS) -e main -s
<tupi>ok, tx good night
<civodul>and: TEST_EXTENSIONS = .scm
<civodul>that should be enough
<tupi>ok tx
<civodul>lemme know tomorrow how it went ;-)
<civodul>good night
<tupi>will do, good night
***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
<civodul>Hello Guilers!
<artyom-poptsov>Hi civodul
<wingo_>heya civodul
<civodul>hey wingo_
***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>I don't think so
<ijp>well, there is one, the same as the file limit
<ijp>but that's huge
*taylanub tests
<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.
<bhattigurjot>how can I completely remove guile from my system?
<civodul>bhattigurjot: "make uninstall"
<civodul>though i wonder why one would ever want to do that
<bhattigurjot>for the experimental purposes.. and I didn't compile it...
<bhattigurjot>I downloaded through apt-get
<bhattigurjot>but purge and remove still leaving a trace
<mark_weaver>bhattigurjot: for that, use "dpkg --purge"
<bhattigurjot>"dpkg: warning: ignoring request to remove guile which isn't installed"
<bhattigurjot>but its still there in /usr/lib/
<bhattigurjot>i can still locate guile
<mark_weaver>guile is not the name of the package. use "dpkg -l guile\\* libguile\\*" to find the package names.
<bhattigurjot>i see there are none
<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"
<bhattigurjot>*thing is
<pallagun>bhattigurjot: update your locate database?
<ijp>the locate database usually only gets updated once a day
<bhattigurjot>"update-locale" ?
<ijp>locales are something completely different
<bhattigurjot>okay.. thanks :-)
<bhattigurjot>also found this while searching to uninstall guile
<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
<bhattigurjot>./configure: line 16703: GUILE_PROGS: command not found
<bhattigurjot>./configure: line 16706: GUILE_FLAGS: command not found
<bhattigurjot>this is the error I'm facing when running ./configure
<bhattigurjot>my guile version ins 2.0.11
<mark_weaver>bhattigurjot: that's because autoconf didn't find guile.m4 in the ACLOCAL_PATH
<mark_weaver>(when you ran autoreconf)
*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
<bhattigurjot>there isn't one
<ijp>bhattigurjot: so you didn't get it from git?
<bhattigurjot>ijp: i did but this one didn't have this script..
<ijp>of course, you were talking about a completely different piece of software
<bhattigurjot>also I'm working on the upgrade branch...
<bhattigurjot>sorry if I didn't made it clear
<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
<bhattigurjot>fatal error: libguile.h: No such file or directory
<mark_weaver>bhattigurjot: we already went through this :-(
<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's use INCLUDES instead of AM_CPPFLAGS or whatever.
<bhattigurjot>mark_weaver: I've already changed INCLUDES and stuff..
<bhattigurjot>probably like you said need to set pkg_config_path
<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>I'm trying to reproduce the problem on my end.
<mark_weaver>actually, I see that 'autoreconf' calls libtoolize also.
<bhattigurjot>okay that's one step less..
<bhattigurjot>mark_weaver: so "intltoolize --force"-->"autoreconf -vfi"-->"./configure --prefix=/usr"
<bhattigurjot>is that it?