IRC channel logs


back to list of logs

<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!
<Marex>ok, done, patch is out
<Marex>sure, np
<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
<sapienTech>taylan: yeah that worked thanks!
<civodul>mark_weaver, wingo: i'm getting pinged about
<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>if it distchecks, that is
<wingo>ACTION long train to fosdem tomorrow
<davexunit>how long of a trip?
<davexunit>I wish I could take a train to FOSDEM.
<wingo>around 8 hours i think
<wingo>long-ish transfer in lyon
<davexunit>pleasant scenery along the way?
<wingo>depends on the weather :)
<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>you mean 2.0 or 2.1?
<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?
<wingo>sure, wishes are free :)
<davexunit>ACTION wishes for a second wingo
<daviid>hello guilers!
<stis>hey daviid!
<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
<daviid>civodul: wow, great!
<ruste>Soooooo... why can't I redefine eval?
<ruste>In a module specifically.
<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, because it blocks tor users.
<mark_weaver> works
<ruste>mark_weaver, I wasn't going to use, 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.
<wingo>ACTION in a meeting, biab
<jmd> 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>or at least that's my guess.
<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?
<mark_weaver>ah, that could be.
<ruste>mark_weaver, Yup. That makes sense.
<mark_weaver>I confess I haven't looked closely at what #:replace does.
<mark_weaver>ACTION looks
<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.
<ruste>Thanks for all the help.
<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 relevant code is in ice-9/boot-9.scm
<mark_weaver>specifically 'module-replace!'
<mark_weaver>which is called from 'define-module*'
<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?
<mark_weaver>oh no, definitely not.
<mark_weaver>modules are a very good thing
<ruste>I agree.
<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'.
<dsmith-work>Thursday Greetings, Guilers
<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>okay, happy hacking!
<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: Heya.
<dsmith-work>"seen" maps to "sneek", unfortunately
<dsmith-work>seen, botsnack
<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
<dsmith-work>sneek help
<dsmith-work>sneek: civodul: yes, we ?
<sneek>civodul: yes, we is making progress, although with 5000+ queued builds there may be more failures yet to be seen.
<dsmith-work>sneek: forget civodul: yes, we ?
<sneek>Consider it forgotten.
<mark_weaver>dsmith-work: grea, thanks!
<dsmith-work>I really gotta remove that fuzzy nick matcher when addressing the bot
<dsmith-work>civodul: BTW: Sheppard. PID 1. Cool!
<dsmith-work> shephurd ?
<sneek> 14:33:49 up 212 days, 23:20, 0 users, load average: 0.12, 0.04, 0.05
<dsmith-work>sneek: uptime
***ruste is now known as Guest80515