<ijp>mario-goulart: it would <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 *paroneayea computer crashed, turns back on guilemacs compiling :) ***wingo_ is now known as wingo
<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) :-) <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>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>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>it is a bit slow for some things (tab completion) but it seems fine for editing files. <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>it clearly needs optimizations but it seems to run just fine! <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." <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 <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] <lloda>it was all undocumented, so I don't think anybody should notice, anyway <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? <sneek>Sneeky bot running on Guile version 2.0.11 using bobot++ 2.3.0-darcs *sneek looks squinty-eyed at unknown_lamer <unknown_lamer>sneek: it's ok, you have achieved perfection and need no more updated <hellekin>unknown_lamer: are you still using darcs?