<daviid>mark_weaver: I had to leave, but did read the log just now and what you suggested works, downloading now, thanks <Marex>I have a small patch adding nios2 architecture support into guile , which list do I submit that to ? <Marex>mark_weaver: so it's the bug list, I see ... thanks! <sapienTech>getting fatal error: libguile.h: No such file or directory when trying to embed guile in c code. I ran apt-get install guile-2.0 <sapienTech>is there something else i should do to allow embedding? <taylan>sapienTech: you probably need to apt-get install guile-2.0-dev <civodul>i think we should Do Something About It :-) <mark_weaver>civodul: I have some thoughts on that, but I have to go afk for a few hours. ttyl! <wingo>ACTION was able to get a prebuilt/ tree working earlier today <wingo>i will push a patch later tonight maybe <wingo>ACTION long train to fosdem tomorrow <davexunit>I'd love to come to fosdem, but I really don't like planes. <wingo>gets beautiful and bucolic around lyon tho <stis>wingo: any chance to get helper funcitons to serialize closures in 2.2? <stis>assuming stable go-files <stis>The serializing needs to survive a restart of guile e.g. be able to persist state with closures in <stis>I can make it work for 2.1 but really it demands groveling into 2.1's internals. <wingo>stis: short answer is yes. it would be a fair amount of work though. <wingo>yeah i don't see myself working on that before 2.2.0 is released <stis>Cool, can we put it into a wishlist? <daviid>ACTION cross fingers for guiler's presentations and workshops @ fosdem! and that it brings more guilers... hope all be taped so I can later watch them <civodul>daviid: normally everything will be recorded and even streamed <ruste>Soooooo... why can't I redefine eval? <wingo>you can. why doesn't it work for you? <fps>oooh, serialized closures - i would like that :) <ruste>I get ;;; ERROR: Unbound variable: eval <ruste>Everything goes smoothly as long as I don't include eval in #:replace <ruste>But then it doesn't get exported. <ruste>I'll try putting an example on a pastebin. <mark_weaver>ruste: please don't use pastebin.com, because it blocks tor users. <ruste>mark_weaver, I wasn't going to use pastebin.com, but I like your suggestion better than what I was going to use. Thanks. <ruste>wingo, I'm assuming I'm doing something dumb, but I can't figure out what. <wingo>it's the let ((old-eval eval)) <ruste>May I ask why? I tried a simpler version of that in a repl and it worked great. <ruste>But it wasn't in the context of a module. <jmd>paste.lisp.org insists on javascript <jmd>so I don't use it anymore. <mark_weaver>ruste: that 'eval' is still referring to the eval in this module, and it refers to it before it's been defined. <mark_weaver>ruste: instead of (let ((old-eval eval)) ...), try this: (let ((old-eval (@ (guile) eval))) ...) <mark_weaver>that (@ (guile) eval) refers to the 'eval' from the (guile) module. <ruste>mark_weaver, So if I define a module and say it #:replaces something the old definition is not exposed to any of the code in the module? (except by referring to it directly?) <mark_weaver>'@' is described in section 6.19.2 (Using Guile Modules) in the Guile manual. <mark_weaver>ruste: it's not the #:replace that causing it, but rather the fact that you are defining 'eval' in this module. <mark_weaver>by defining 'eval' in this module, a fresh binding is allocated for it that shadows that one you would have gotten from the (guile) module. and initially it's unbound, until that 'define' has been done. <ruste>mark_weaver, If I remove the #:replace it compiles fine but doesn't export the new eval. It seems like saying #:replace removes the old definition in the modules environment rather than just replacing it in the new environment? <ruste>mark_weaver, Yup. That makes sense. <mark_weaver>I confess I haven't looked closely at what #:replace does. <ruste>I just assumed that I had access to the old one until I replaced it. <ruste>I'm sure there was a good reason for doing it the way it was done. I'll read through the define-module code. <mark_weaver>ruste: okay, I see. the #:replace causes 'module-ensure-local-variable!' to be called for that variable in this module, so it gets a fresh binding before the 'define' has been done. <mark_weaver>(the procedure that underlies the 'define-module' macro) <mark_weaver>ruste: in standard R6RS or R7RS, you wouldn't even be allowed to define 'eval' in this module without excluding it from the list of imports, which is cleaner than the imperative REPL-like model of things getting rebound while the module is loading. <mark_weaver>actually, the current imperative REPL-like model of module loading currently used in Guile is problematic in a multi-threaded program where multiple threads might try to autoload the same module at nearly the same time. <mark_weaver>so it's best not to rely on these specific details of how things are currently done in guile. <ruste>So should I be avoiding modules entirely? <ruste>I'm not really sure how to avoid the quirks of their implementation though. <mark_weaver>well, it's best to avoid writing code that does something like (define eval (let ((old-eval eval)) ...)) that seems to hope that the 'let' will access a previous binding for 'eval'. <mark_weaver>that idea of how to do things depended on an imperative REPL-like model for how modules are loaded. <mark_weaver>whereas refering to the 'eval' binding in another module doesn't does not make any such assumptions. <ruste>I wrote it knowing it might cause problems if someone else changed eval before me. <ruste>I assume that's the sort of issue you're getting at? <mark_weaver>well, no, I'm talking about a different problem, but I don't have time right now to explain further, sorry. <ruste>Alright. Thanks for all the help. I'll rewrite with @ and see what I run into. <mark_weaver>dsmith-work: greetings! I have a question for you regarding sneek! <mark_weaver>on #guix, I wrote: "civodul: yes, we are making progress, although with 5000+ queued builds there may be more failures yet to be seen.", and sneek responded with "I'll keep that in mind." <mark_weaver>dsmith-work: what did this add to its database, and how do I remove it? <mark_weaver>if you're busy, that's fine, it's not important. just curious :) <dsmith-work>mark_weaver: You can tell it to forget things, but of course you must know what to forget <dsmith-work>It's in an sqlite database. I'll see if I can find that and forget it. Need to be at home though <dsmith-work>mark_weaver: There is no command to dump the list of keys <sneek>civodul: yes, we is making progress, although with 5000+ queued builds there may be more failures yet to be seen. <dsmith-work>I really gotta remove that fuzzy nick matcher when addressing the bot <sneek> 14:33:49 up 212 days, 23:20, 0 users, load average: 0.12, 0.04, 0.05 ***ruste is now known as Guest80515