<davexunit>paroneayea: found the source of the continuation barrier. the hook api :/ <davexunit>but there is no reason why such a simple api should be in C... ugh <davexunit>completely reimplemented hooks in guile... only to find that my program *still* doesn't work. :( <davexunit>not sure exactly but it looks like fibers is making a new thread even when I set parallelism to 1, but I need everything to run in the same thread. ***shinra-chiron_ is now known as shinra-chiron
<amz3`>so the program failed, but not because of wiredtiger, AFAICT <lloda>is there a way to get an absolute path from module-filename? <paroneayea>davexunit: yeah a number of "simple things" still use C... maybe we should send more patches :) <davexunit>paroneayea: I'd like to propose a patch to reimplement hooks in Scheme, but I just know that some ridiculous complication will arise that will increase the work 10x <davexunit>I really need to get fibers to not spawn new threads... my program crashes when it tries to render with OpenGL due to some null pointer exception <davexunit>fibers is a lot better than what I've written in the past, technically speaking, but I'm having so many integration issues. ***shinra-chiron_ is now known as shinra-chiron
<davexunit>wingo: is it possible to make fibers not spawn a new thread at all? i.e. make it fully cooperative <davexunit>looking at the source it seems that it currently isn't possible, but maybe there could be a mode that does this? <wingo>pass #:parallelism 1 and #:hz 0 to run-fibers <wingo>using the fibers / repl integration still does threads tho <davexunit>but the error I end up seeing makes it seem as though that my fiber is running something other than the main thread <davexunit>because of how OpenGL contexts work, I really need to ensure that my program, at least the rendering part, runs in the main thread. maybe something else has gone wrong... <davexunit>wingo: okay, I'll take a deeper dive then. thanks. <davexunit>I think I know a test that will verify this... <davexunit>yup, it is indeed the same thread. problem lies elsewhere, but somehow this problem doesn't reveal itself when fibers is not used. <wingo>could be a concurrency bug that doesn't need actual parallelism to exhibit itself :) <davexunit>yeah, seems to be the case. something related to OpenGL state machine management. <davexunit>this will be fun, as debugging OpenGL code always is. /s <davexunit>wingo: would I be correct in saying that if I want a scheduler that will wake up fibers after a certain number of "ticks" have happened in my game loop then I should implement a new operation? <davexunit>basically writing the equivalent of fibers/timers.scm but the time that passes isn't real time <wingo>i think so, yeah -- i was about to say the same thing <davexunit>will be nice to finally offload all this concurrency stuff to fibers. <davexunit>really weird stuff happens. no errors, but the SDL window doesn't even open yet the game loop is spinning. trying to make sense of it all. <paroneayea>something interesting is happening re: dynamic state in create-fiber but I don't understand it <paroneayea>I wonder why this is done? I guess the dynamic state is not captured as part of its closure <paroneayea>is this to make sure that the dynamic state is the dynamic state from create-fiber rather than when scheduler is run? <wingo>dynamic state is not lexical <wingo>that "growing fibers" article talks about this <paroneayea>wingo: aha, okay, I'm going to re-read and re-think about it :) <paroneayea>wingo: I've been thinking about something you said btw, that maybe actors should inherit the dynamic state from their parents <wingo>if an actor is spawned by a fiber, they do <paroneayea>wingo: originally, I had the hive spawn and run actors, so the dynamic state would be that from the hive, but in the 8sync-on-fibers design I have now this isn't necessary <wingo>er if the parent actor's dynamic state is current when the child actor's fiber is spawned, they do <paroneayea>the main challenge to doing this would be currently actors have a %current-actor parameter so that (<- foo) doesn't require looking up the actor all the time but <paroneayea>maybe I should drop that and pass it in explicitly anyway <paroneayea>the reason it may be a problem is I'm worried about having actors that spawn actors that spawn actors <paroneayea>then having a ton of %current-actor parameters stack up <paroneayea>I guess there would already be a bunch of current-fiber parameters <wingo>e.g. (let ((actor (make-actor))) (spawn-fiber (lambda () (current-actor actor) ...))) <wingo>anyway the (with-dynamic-state ...) thing "cuts the cord", so to speak <paroneayea>I was also doing some things so that if there was a "correspondence chain", where one message handler was "waiting" on another message handler's reply (more or less a reply would be a continuation across messages) <paroneayea>but, I wonder if this means that if the exception catchers will also stack up <paroneayea>if I spawn an actor within a catch, and that spawns an actor within a catch... <paroneayea>will that result in a bunch of catches that maybe don't even point to anything anymore? <paroneayea>sorry, this is a pretty naive question wingo, I don't know how this is implemented in guile's VM <paroneayea>will the spawn-actor, using spawn-fiber, inherit the parent catch and will that keep happening? <paroneayea>> See where the problem is? If we ship this exception handler stack over to a new fiber, then an exception propagating out of the new fiber would be looking up handlers from another fiber, for prompts that probably aren't even on the stack any more. <paroneayea>> The problem here is that if you store a heap-allocated stack of current exception handlers in a dynamic variable, and that dynamic variable is captured somehow (say, by a delimited continuation), then you capture the whole stack of handlers, not (in the case of delimited continuations) the delimited set of handlers that were active within the prompt. To fix this, we had to change Guile's exceptions to instead make catch just rebind <paroneayea> the exception handler parameter to hold the handler installed by the catch. If Guile needs to walk the chain of exception handlers, we introduced a new primitive fluid-ref* to do so, building the chain from the current stack of parameterizations instead of some representation of that stack on the heap. It's O(n), but life is that way sometimes. This way also, delimited continuations capture the right set of exception handlers. <stis>my parser combinators with memoization, backtracking and logical vars <stis>I'll try to write up something nice to document it <catonano>I don't understand the bit about scanner/parser separation, but I think it's cool <stis>well the notion of token is hierakial <stis>you do consider creating objects like numbers strings and symbols in a tokenizer first but it is all in a unified framework and it's functional <stis>in backtracking they are resseted to the value at the junciton <stis>not sure what placeholders are <avoine>stis: I mean in your code, they are the macros <code>, <var>, etc? <stis>they refere to logical constructs <stis>I took th <...> form because they get another collor in emacs <avoine>stis: last question :) what is the meaning of each of those arguments? (lambda (s p cc x xl n m c) they looks like the signature for building a new kind of expression. <stis>s = variable bindings, p backtracking thunk e.g. call (p) to backtrack <stis>cc = continueation e.g. call (cc p s) when yo want to continue <stis>x is the list of the characters at the current line <stis>cl the rest of the loines <stis>S,CC,X,XL,N,M is syntax parameters and you can get their values by using them e.g. (pk N) <stis>you can bind new values through them as well <stis>yes an c is incomming user state <stis><p-lambda> (c) ... hides s,p,cc,x,xl,n,m <avoine>ok, that a lot to process but I think I got it <avoine>never saw syntax-parameterize before <stis>when you use the parser combinators you never think about them <stis>so I've debugged the repository, added the obligatory calc example <OrangeShark>stis: looks like you might have checked in a couple of files created by the editor like `modules/parser/.#stis-parse.scm` and `doc/example.md~` <stis>I uploaded a full python3 parser to the repo have fun digesting that example g'night