***ijp is now known as ghost_of_robin_m
***ghost_of_robin_m is now known as robinmilnerghost
***robinmilnerghost is now known as ijp
<nalaginrut>maybe I should build a new project named 'nala-repl', and include src and colorized-REPL as extended plugins... *civodul dives into {Web,Open}GL, with fear of drowning *dsmith-work tosses civodul a beautifully rendered 3D virtual lifesver <wingo>i keep being surprised by the rtl branch <wingo>things working that i wouldn't expect to work <stis>yeah that was my impression as well, it behaved much more solid than I thought it should! <wingo>not trying to boast fwiw; honestly surprised :P <wingo>i am trying to figure out how to lazily load debug info <wingo>i am thinking we can only do that for mmap; and in that case, is it worth it at all i wonder? you would think the VM could prevent some things from being paged in <stis>do you mean that debug info is in an area of it's own and that the system VM does not page that in untill it is explicitly referenced? <wingo>we already have to align the ELF file on page boundaries for mmap <wingo>so that we can share read-only pages but not writable pages <wingo>yeah we will have to do that either way <wingo>yes it really seems the kernel is the place to do this <stis>wingo this looks prommising, btw, have you thought about getting generatores and accumulators to work nicely with the rtl VM? <wingo>it can do proper cache invalidation & such <wingo>are generators the same as one-shot continuations? <wingo>delimited continuations that can only go forwards? <wingo>so many words, so many meanings ;) <stis>Well, you save the k but only reuses it once, is that what you mean? <stis>yes, for that use case we should be able to take advantage of RTL <wingo>we need an additional primitive to save a delimited continuation without returning to the handler <wingo>that's needed for delimiting call/cc <stis>named goto's if we can inline it in the function! <wingo>one can imagine an extension or so that allows that primitive to also pass in a continuation to re-use <wingo>so that you're not allocating every time you stop <wingo>and something can wrap that all in a "generator" abstraction <wingo>there is a lot more you can do <stis>But this means that probably the stack get's shoped up right? <wingo>i think i would still copy the stack into the generator object, and copy it back when resuming <wingo>if that's what you're asking <stis> you can have a 'generator object' with code ansd some data and just call the function calls on the ordinary stack .... <stis>but that means that the stack will be shoped up and demands qute a lot of work to be implemented <wingo>we will need segmented stacks in any case <wingo>because the current situation of having to allocate big stacks just because we don't grow and shrink stacks is silly <stis>But for the case when you inline a generator in code e.g. macro expansion of a looping construct ... <wingo>and surely that same mechanism can be used for generators (and i think heib and dybvig did something like this) <stis>you can have it in the function frame and jsut make sure to call the functions at the end of the stack. <wingo>stis: if you inline a generator you can probably remove it with cps :) <stis>That would be good ndeed! :-) <wingo>all idle thoughts to a degree <stis>Anyhow, RTL opens ups many possibilities in this arena and if we go the road to have segmented stacks then just bloody cool! <stis>step by step is the word, fitrs some debug info handling. Wingo I think you nailed that one right! <stis>Anyhow I'm back trying to fighure out a sane implementation of redo-safeness. CU!