<kurohin>mark_weaver: I have reported the problem I have with making my on extension for guile to bug-guile@gnu.org. <civodul>doing robotics stuff with Hop currently <wingo>sheparding a flock of patches into firefox :) <wingo>finally optimizing let-bound variables over there <wingo>but as always, debugging-related things are a constant cost... <civodul>ijp: you've seen davexunit's FRP thing in guile-2d? <ijp>I saw when he posted it here, but I haven't played with it <ijp>right now my project is trying to figure this TECO thing out <civodul>wingo: local variables were not, say, propagated or inlined? <wingo>well before es6 there was no block scope in javascript <wingo>all variables had the entire scope of the function <wingo>with two small exceptions (catch exceptions and the name of a named function expression) <ijp>wingo: is there any ETA for ecmascript modules in firefox & co? <wingo>so it was an odd case and no one thinks to optimize it or to nicely provide debugging things <wingo>ijp: it's almost ready to land i think <ijp>heh, brainfuck patches <ams>anyone seen ludovic? <sneek>I last saw civodul on Dec 03 at 09:58 am UTC, saying: ok. <ijp>we'll see about that *ijp breaks out LudovicTester5000.scm <ijp>it hasn't terminated, probably a bug... ***wingo_ is now known as wingo
<wingo>jao: current emacs uptime? :) <jao>wingo, only "1 day, 1 hour, 33 minutes, 52 seconds" because i updated emacs-snapshot <jao>nothing to bragg about :) <wingo>you should make feature requests^demands to guile <jao>(wingo, but my home server uptime is 392 days!) <wingo>jao: that means it's vulnerable, surely ;) <jao>oops, don't tell anyone! <wingo>jao: seriously i have some vague attention span to look at metadata/introspection things <wingo>if there are things you would want in geiser i'd love to hear about them <wingo>doesn't mean they'll get done ;) <jao>wingo, if you don't break any of the ones already available, we're in pretty good shape, i think <wingo>jao: that is an if, indeed; but i hope not <jao>callers/callees was a bit of hack (of mine!), but it's very difficult to improve <jao>probably impossible in the general case <jao>there was some case when arity names weren't available or something like that <jao>but i'm afraid i forgot about it <jao>wingo, also something similar to racket's macro stepper would be great to have <jao>we could add a nice interface in geiser to it <wingo>i think i have callers and callees working better <wingo>in 2.0 there is a case in which you've already resolved the toplevel to a var and you lose the name of what the var was <jao>i also had in mind providing a function to clean the imports of a module, eliminating those not used anymore, but haven't found the time to implement it. i'm guessing all the necessary functions are already there in 2.0, though. <jao>but at any rate, having a `module-imports' function would be great :) <jao>i'm forgetting my guile! <jao>okay, then i think that'll be a useful function to have, specially in geiser where emacs can clean-up the file for you <davexunit>is there anyway to use introspection to reach within a closure? <davexunit>I want my game library to have good live coding features, but since a lot of things don't work before the SDL window is opened, a lot of stuff gets wrapped in a call to a procedure called with-window. <davexunit>which means that when you want to change something, you have to restart the application because the defines aren't at the top level anymore. :( <civodul>ideally you could have a REPL served from a thread, and from there inspect the other's stack <civodul>but i think that doesn't quite work in 2.0 <davexunit>I would just define everything at the module level, but I can't do things like load an image until the window is opened and an SDL context is established. <wingo>otherwise names of closure vars are not necessarily textual <wingo>some things could get inlined <wingo>but we should record their names, and currently we don't *davexunit looks up local-eval *wingo leads you down a dark, dark path <davexunit>it would just be easier if everything could be kept at the module level for easy evaluation with C-x e <wingo>if you can manage that, sure <davexunit>I mean I *could* by running open-window before all of the defines. <davexunit>but the with-window form I wrote does dynamic-wind and stuff, which is useful. <wingo>surely fluids are the answer then? <davexunit>the problem with parameters is that they are thread-local <wingo>dunno; the parameter is the same across all threads <wingo>it's the result of calling it that's thread-local <wingo>if you are still drawing from only the main thread, it could be a way to have definitions come in on a separate thread, but only invoked on the main thread *wingo doesn't really know your use case :) <davexunit>so the value of a parameter is the same across all threads? <davexunit>this problem is primarily caused by texture loading. maybe I should get smarter with that and delay texture creation until the window has been opened? <davexunit>then I can do all of the top-level defines that I damn well please. :) <civodul>davexunit: parameters (SRFI-39) are per-thread <wingo>davexunit: the value is per-thread <wingo>but the binding usually isn't <wingo>anyways, let's see if i can finish compiler.texi *dsmith-work snags the latest... <civodul>dsmith-work: it fails while initializing the randr module, like this: <civodul> 176: 1 [xcb-connection-send #f 4 #vu8(80 1 0 0 7 0 0 0)] <civodul>where #f should be an xcb connection <civodul>the connection seems to get lost somewhere <dsmith-work>Are you using a different display? (Like xnest or xephyr) Maybe it has a bug when not using the default. <zzach>Sometimes it is necessary to insert (eval-when (compile load eval) ...) to ensure that code is available at expansion time. Is it somehow possible to formulate a macro using this code? Would like to embedit for guile into cond-expand to keep code compatible with other scheme versions. <ijp>what are you trying to do at expansion time? <ijp>there may be something else you can do instead of eval-when <zzach>For example I wrote a macro named try-catch, without eval-when, error messages like ERROR: In procedure #<syntax-transformer try-catch>: ERROR: Wrong type to apply: #<syntax-transformer try-catch> appear. <zzach>I think it is possible to put the code into a module, but this is also not compatible to other Scheme versions.