IRC channel logs


back to list of logs

<wingo>mark_weaver: you remember those spurious segfaults you'd sometimes see compiling master?
<wingo>dunno if you remember
<wingo>usually you'd just have to re-make and things would be fine
<wingo>turns out it was a write beyond the mapped stack region
<wingo>hard to track down because almost any change you make changes stack frame sizes, so you change something and it goes away and you think you fixed it
<wingo>anyway, finally got it.
<ArneBab>wingo: that sounds like a really nasty bug… great catch!
<mark_weaver>wingo: ah, that's good news!
<civodul>Hello Guilers!
***michel_mno_afk is now known as michel_mno
<nilg>Hi, if I use (load <filepath>) in a file, it assumes <filepath> is relative from that caller file. But if I use (load-from-path <filepath>) it doesn't. Anybody knows how to get that behavior back in load-from-path?
<nilg>OK, I got it, I would have to add (add-to-load-path (dirname (current-filename)))
<civodul>nilg: alternately you can use primitive-load, which doesn't search in %load-path
<civodul>however, it evaluates the code instead of auto-compiling etc.
<civodul>but really, this is a bug in 'load'
<nilg>civodul: Aha, I started to kinda guess that based on how it behaves, thanks!!!
<mark_weaver>hmm, looks like we can't have libreoffice on i686 until vigra is fixed on i686
<mark_weaver>and libreoffice also depends on numpy, which fails to build more often than it works, so the libreoffice substitutes are going to be spotty until that's fixed
<davexunit>I think this conversation was mean for #guix :)
<mark_weaver>oh, right, oops :)
<civodul>oops indeed :-)
<civodul>people will think we're spamming them about vigra
<mark_weaver>daviid: from its Guix package description: "VIGRA stands for Vision with Generic Algorithms. It is an image processing and analysis library that puts its main emphasis on customizable algorithms and data structures. It is particularly strong for multi-dimensional image processing."
<mark_weaver>(I'd never heard of it until just now)
<daviid>mark_weaver: tx. i'm trying to get some funding to link guile to vigra by the way, but project onb hold, no money yet
<daviid>it is 1 of the 2 candidates i selected [preselected]. the other being opencv
<mark_weaver>daviid: what do you mean by "link" guile to it? bindings?
<daviid>binding yes, sorry
<ijp>so I want to change language/ecmascript to use a record representation and use that as the target for cps
<ijp>would this "circularity" going to be a problem in the future?
<ijp>s/going to//
<mark_weaver>I think that's a question for wingo
<ijp>it may be an idea to separate it for now anyway, as I don't want to touch the reader or compiler for ecmascript at the moment
<dsmith-work>Happy Friday, Guilers!!
<wingo>ijp: yes probably that would be a problem
<wingo>best to separate and then join later if it's possible / a good idea
***petercommand is now known as petercommand1
***petercommand1 is now known as petercommand
<wingo>damn, i seem to have broken contification. shoot.
<wingo>or only outside a lambda? weird.
<wingo>ok, fixed it.
<wingo>wasn't really a bug but a failure to optimize where we should.
***michel_mno is now known as michel_mno_afk
***dje is now known as xdje
<paroneayea>hello, *
<daviid>i'm plaing with the test-suite, in general and wrt guile-gnome in particular, but i've got a problem, wrt this and geiser: setenv won't/doesn't work for LTDL_LIBRARY_PATH, wonder if there is a solution?
<ijp>bug of the day: misspelling "symbol" as "unspecified"
<mark_weaver>daviid: can you be more specific about what exactly you did, what you expected, and what actually happened?
<daviid>mark_weaver: i solved by launching a terminal where i define LTDL_LIBRARY_PATH=... [tons of paths] then launch an emacs from their, then geiser, then it's ok ...
<daviid>mark_weaver: the other 3 vars required to run any guile-gnome's module test-suite, you can use setenv, but LTDL_LIBRARY_PATH must be set before launching geiser
<daviid>mark_weaver: don't waste your time, it's not important, but tx of course