IRC channel logs


back to list of logs

<ArneBab>ijp: guile-on-js would be cool!
<mario-goulart>ijp: wouldn't it be similar to SPOCK?
<paroneayea>mario-goulart: what's SPOCK
<ijp>mario-goulart: it would
<mario-goulart>paroneayea: a Scheme->js compiler:
<paroneayea>mario-goulart: wowwww nice!
<paroneayea>mario-goulart: does it work in guile?
<mario-goulart>ijp: maybe SPOCK can be ported to guile.
<mario-goulart>paroneayea: I don't think so.
<paroneayea>I think ijp's idea of using guile's compiler tower to do it would be pretty neat
<ijp>mario-goulart: I'd need to gut it anyway
<mario-goulart>I understand. It's a quite big project.
<zacts>ooh that sounds cool
<zacts>I hope it happens
*paroneayea computer crashed, turns back on guilemacs compiling :)
<nalaginrut>morning guiler~
<civodul>Hello Guilers!
***wingo_ is now known as wingo
<wingo>morning :)
<sneek>Welcome back wingo, you have 1 message.
<sneek>wingo, civodul says: would be nice if you could advertise the potluck a bit more (see guile-user) :-)
<wingo>hmm :)
<civodul>howdy wingo :-)
<wingo>heya :)
<nalaginrut>wingo: will Guile use gnu-lightning for JIT or write a pure Scheme one? I ask so because I wonder if lightning could integrate with Guile properly, but just guessing
<wingo>nalaginrut: we need to have an aot before a jit, i think, so i don't think lightning makes sense
<nalaginrut>wingo: personally, I wish we do all the job in Scheme as possible, so this answer is nice to me ;-P
<robertle>hi everyone, I was here yesterday with a few questions. I got pointed to the fine manual, which is truly impressive, and that did answer a lot. but I still have a few points I do not understand:
<robertle>a) in the current (2.1/master) register-based VM, where are the registers? are they the "locals" on the stack?
<robertle>b) continuations: how does creating a continuation work? does it create a new stack?
<robertle>c) and despite the fact that the/one intermediate language is CPS, most calls will "just" be push args on stack and call, right?
<robertle>oh and d) what are cells with four slots good for?
<wingo>hi robertle
<wingo>in the master vm, the registers are just indexed stack slots in the local frame
<wingo>continuations: capturing a continuation actually copies out the active portion of the C stack and the VM stack; reinstating a continuation copies them back
<wingo>there are a couple of other bits of state, but that's the essence
<wingo>robertle: regarding the cps IL, it's just an intermediate language, the target language still uses a stack
<wingo>robertle: and finally :) it used to be that guile implemented its own garbage collector, and that collector used to only support certain sizes of objects
<wingo>those were the cells
<wingo>and double cells are simply objects with four words (though the first word usually has a type tag in some of its bits)
<wingo>these days that's not important, as we can allocate gc-traced memory of any size
<wingo>so the existence of "cells" is a historical artifact
<wingo>objects with four words are of course useful if you have three things that are associated with a value :)
<paroneayea>bipt: woooooo, I have guilemacs running :)
<davexunit>paroneayea: wow!
<paroneayea>I can even play tetris!
<paroneayea>it is a bit slow for some things (tab completion) but it seems fine for editing files.
<davexunit>what was the missing ingredient?
<davexunit>yeah, the elisp implementation needs some optimization.
<paroneayea>davexunit: well, doing it off of the emacswiki "script" on there did work, but
<paroneayea>there was a bug if you already had Guile installed
<paroneayea>the PATH was in the wrong order
<paroneayea>so system guile-snarf went first
<paroneayea>rather than bipt's version
<davexunit>oh I see
<davexunit>makes sense
<paroneayea>it clearly needs optimizations but it seems to run just fine!
<paroneayea>(but that was already known)
<lloda>do we delete in 2.2 the stuff that was deprecated in 2.0?
<davexunit>lloda: the NEWS file has some info about deprecated API deletions.
<lloda>where do you see that in the NEWS file?
<davexunit>I don't remember off the top of my head, and I can't look right now. all I know is that I was looking at the NEWS file in master.
<mark_weaver>lloda: search for "All deprecated code removed" in master's NEWS
<mark_weaver>"All code deprecated in Guile 2.0 has been removed."
<lloda>does 2.0 include any 2.0.x?
<robertle>wingo: great, thanks! the registers as part of the stack is kinda neat, but also a bit surprising! do you have strong opinions on this aspect, or do you think it doesn't really matter much?
<robertle>obviously the benefit of having it on the stack is that you don't actively have to safe your regs before/after making a call, and the drawback is that you may be wasting more of the stack than strictly necessary
<wingo>robertle: for an interpreter you have no other option; registers have to be indexes into an array.
<robertle>wingo: right, but it doesn't have to be the stack
<robertle>could be justa fixed register file somewhere
<wingo>however then you'd have to spill and restore, and that's really the point of a stack
<wingo>we try not to use more stack space than there are live variables, though to avoid shuffling there are some holes
<robertle>one of the reasons why I think thi sis interesting is, of course without having much experience in this, is how this translates into a future jit implementation
<robertle>but the spilling is of course a very good point: having a variable size register file on the stack means you don't need any spilling ever
<robertle>and I guess even your jit'ed code would still use memory regions instead of real registers...
<wingo>jitted code could use registers
<wingo>we can do proper register allocation, you just need to spill around calls
<wingo>and actually i'm more looking towards aot compilation at this point: jit without aot means that your jit is written in c or c++, which is not so nice :)
<wingo>i.e. first aot compilation, then we can experiment with jit things
<robertle>ok, understoood
<robertle>thanks, very interesting!
<lloda>mark_weaver: I'll take that as a yes ---there's some code that was deprecated in 2.0.9 that has not been deleted, that's why I asked
*wingo found an expander bug, whee
<wingo>lloda: i deleted all deprecated things at one point -- but things deprecated since then may or may not be gone in master
<wingo>depends on how cruel it would be :P
<lloda>I want to remove the deprecated block in array-map.[hc]
*wingo looks
<lloda>it was all undocumented, so I don't think anybody should notice, anyway
<wingo>lloda: lgtm
<dsmith-work>Happy Friday, Guilers!!
<paroneayea>hi dsmith-work !
<davexunit>happy friday indeed
<mario-goulart>Happy 13th Friday!
<hellekin>Is there an IRC bot in Guile? If yes, it's not on
<davexunit>hellekin: I don't know of any, there is a guile-irc library though, so someone ought to write one.
<hellekin>davexunit: we could definitely use some on #gnu-webmasters. I'm secretly looking for a way to take the time and learn Guile. But the truth is I already ran out of free time :(
<davexunit>hellekin: what would you like to see a bot do there?
<hellekin>let's move it there
<dsmith-work>Hmm. Bobot++ isn't listed
<hellekin>dsmith-work: mentions Guile 1.6, but it was written in 2006. Latest release is from 2008.
<dsmith-work>sneek: version
<sneek>Sneeky bot running on Guile version 2.0.11 using bobot++ 2.3.0-darcs
<hellekin>aha! Then is obsolete
<dsmith-work>I forget where the current code is.
<dsmith-work>unknown_lamer knows
<dsmith-work>Or should. ;^)
<hellekin>sneek: about
<hellekin>damn bot
<hellekin>thanks unknown_lamer
<unknown_lamer>"Guile 1.9.x" I uh
<unknown_lamer>have not updated bobot++ in a long time
*sneek looks squinty-eyed at unknown_lamer
<unknown_lamer>sneek: it's ok, you have achieved perfection and need no more updated
<hellekin>that's what stable means.
<hellekin>unknown_lamer: are you still using darcs?
<unknown_lamer>usually use git nowadays