IRC channel logs

2014-02-18.log

back to list of logs

<davexunit>FRP is so awesome. :)
<madsy>FRP?
<davexunit>functional reactive programming.
<madsy>FRP is the name of one of our political parties :-p
<davexunit>I've been writing a FRP module for my game engine.
<madsy>They're very opposed to immigration
<davexunit>this FRP is opposed to callback hell.
<madsy>hehe
<davexunit>(define-signal mouse-label
<davexunit> (signal-map (lambda (p)
<davexunit> (let ((text (format #f "Mouse: (~d, ~d)" (vx p) (vy p))))
<davexunit> (make-label font text (vector2 0 20))))
<davexunit> (signal-throttle game-agenda 5 mouse-position)))
<davexunit>This is how you make a text label that displays the current mouse position, throttled to update only every 5 frames.
***bananagram is now known as localhost
***localhost is now known as bananagram
***jao` is now known as jao
<nalaginrut>morning guilers~
<nalaginrut>oops, sneek2 is down?!
***wleslie_ is now known as wleslie
<dje42>One thing I'm finding with the gdb SIGINT thread for Guile is that I have to add a lot of portability goo to configure.ac, et.al. Guile has already had to solve this so it would be nice to take advantage of.
<dje42>I can just copy over the autoconf macros and such, but I'm hoping for something simpler.
<dje42>For Guile 2.0.10, would it be possible to export a simpler API for calling scmsigs.c:install_handler than scm_sigaction_for_thread ?
<dje42>[Plus export a routine to write to the signal pipe.]
<mark_weaver>dje42: can you explain the nature of the portability goo that you hope to avoid?
<dje42>E.g. pthread_sigmask
<mark_weaver>I'd rather not expose the existence of the signal pipe. after all, I hope to remove the signal delivery thread altogether in a future version of guile.
<dje42>Just detecting whether that function exists involves a lot of work. ref: acinclude.m4:ACX_PTHREAD
<dje42>I also notice that libgc wants to intercept that call. If I don't do something similar to what Guile does will I get in trouble?
<mark_weaver>I don't know. This is not my area of expertise.
<mark_weaver>if we did improve things for 2.0.10, would that mean that you'd only support 2.0.10 or later? what versions do you currently support?
<dje42>No worries. There's no rush on any of this.
<dje42>It would mean good SIGINT handling would only exist in 2.0.10 and later.
<dje42>It's not that significant a problem at this point.
<dje42>As for what I support, I've only tested 2.0.9, but the intent is to support 2.0.x if not too hard.
<mark_weaver>2.0.9 is fairly widely deployed at this point, so it would be good to support it, at least.
<dje42>It might be reasonable to just wait for 2.2.
<mark_weaver>2.0.5 is also widely deployed, because it's the version in debian wheezy.
<dje42>Yeah, saw that.
<mark_weaver>(and ubuntu 12.04LTS)
<dje42>I don't mind just sticking with the current SIGINT handling I have (which is basically SIGINT's get deferred until Guile calls return), though they work in the repl because it installs its own handler.
<mark_weaver>but it's not that important.
<mark_weaver>the main thing is that we were hoping to release 2.0.10 quite soon, and I'm nervous about cooking up some new API that might not be that well-thought out.
<dje42>Are the macros in scmconfig.h exported in the sense that apps linking with libguile can use them?
<mark_weaver>really, I'd like to add what Tromey suggested: the ability to schedule an arbitrary async from a signal handler.
<mark_weaver>but that will be harder to do.
<dje42>Re: 2.0.10: No worries, don't hold up 2.0.10 for this.
<mark_weaver>hmm, I don't know that either!
<mark_weaver>if there's resistance to the improved SIGINT handling, it would probably be okay to just punt on it until we have a better interface in guile.
<mark_weaver>can you remind me again, what are the symptoms noticed by users, without the improved SIGINT handling?
<mark_weaver>(apologies for my forgetfulness)
<dje42>Yeah. Plus I do need to make sure that if gdb configures successfully it builds and runs successfully. E.g., at the moment I think the build will break or gdb will break at runtime (if dynamically linked with libguile) if pthread_sigmask is missing.
<dje42>Re: symptoms with improved SIGINT: Suppose gdb calls into guile, guile runs for awhile, user hits ^c, guile prompts user for something, user replies, guile runs for some more, and then returns to gdb (e.g., maybe this is a long running pretty-printer that triggered some input from the user).
<dje42>Processing the ^c will be deferred until after guile returns to gdb.
<mark_weaver>it will be deferred with current gdb git HEAD, you mean?
<dje42>Right.
<mark_weaver>hmm, yeah, that's certainly not great.
<dje42>Sorry, those are the symptoms *without* the improvement.
<mark_weaver>understood.
<mark_weaver>well, let me mull it over a bit. maybe we can get something into 2.0.10.
<dje42>One possibility is for my to call scm_sigaction_for_thread every time gdb calls into guile. It looks a bit heavyweight so I haven't tried it. I could make it configurable though.
<dje42>Plus in order to work nicely with the rest of gdb I need the signal handler to set a global. Though I could install my own SIGINT handler after calling it and chain to the one scm_sigaction_for_thread installs (a bit hacky).
<mark_weaver>can you remind me what kind of API python provides for this? (the one that GDB uses)
<dje42>Python provides a routine that is callable from a signal handler that notifies the interpreter a SIGINT happened. It also provides a routine to check if a SIGINT has been recorded (clearing the flag in the process).
<mark_weaver>what if there are multiple threads running? how does it decide which one to interrupt?
<dje42>I'm guessing at various strategic parts in the interpreter it checks this flag.
<dje42>Good question. I remember finding this. Have to check again.
<dje42>Looking in Python-2.7.5 (haven't looked at 3.x) Modules/signalmodule.c, I see a lot of checks for whether the signal happened on the main thread.
<mark_weaver>afaik, guile doesn't really have a concept of "main thread".
<mark_weaver>I'm really not happy with the way guile currently handles signals. I've been wanting to fix it for a while, but it's a bit too disruptive to do in 2.0.
<dje42>Looks like they queue the equivalent of an async in the signal handler itself.
<dje42>[ref: Python/ceval.c:Py_AddPendingCall]
<mark_weaver>part of the problem is that the SIGINT could be delivered to any thread that's not blocking it. although Guile ends up scheduling an async on the thread specified by the user, if that thread is blocked in a syscall, the syscall won't be interrupted.
<mark_weaver>and even if the SIGINT is delivered to the correct thread, the EINTR causes guile to retry to syscall anyway, often (usually?) before the signal delivery thread schedules the async. so ultimately the user-specified signal handler doesn't get run until the syscall finishes anyway.
<dje42>Yeah. Python lets one set up an fd to write to if there's a signal to unblock select/poll, but that seems to be it (e.g. I don't them trying to handle a blocked read).
<dje42>*see them trying ...
<mark_weaver>guile also uses a wakeup fd for many blocking system calls, but sadly not for 'read' when reading from the file port.
<mark_weaver>(scheduling an async will send a message to the wakeup fd in those cases)
<dje42>Anyways, gotta run. Don't put any extra time into this. It's an interesting problem, but I can imagine there are more interesting ones.
<mark_weaver>the problem is, I don't know how to do non-blocking I/O on posix.
<mark_weaver>O_NONBLOCK can leak outside the process, because it's a property of the underlying ofile instead of the fdes.
<mark_weaver>okay, ttyl!
<dje42>Ditto!
<dje42>[almost gone :-)] If Guile provided a routine like Python's PyErr_SetInterrupt, the implementation details (signal pipe, or whatever) could be an implementation detail, thus you wouldn't have to expose signal_pipe. It doesn't solve all my problems though. Just offered as a (not well thought out) thought.
<mark_weaver>right, and I'm okay with that in principle.
<mark_weaver>the one missing piece for me is: how to decide which thread gets interrupted?
<mark_weaver>and also: since there's no guile-registered SIGINT handler, what should be done exactly?
<mark_weaver>I think there would have to be some other API that specifies which thread to interrupt, and a procedure to call within that thread.
<mark_weaver>but now the API is getting more complex and more questionable.
<mark_weaver>I think it's clear that the API suggested by Tromey is the right thing.
<dje42>As for what thread to interrupt, that's already handle by scm_sigaction_for_thread (right?).
<mark_weaver>yes
<mark_weaver>but I agree with you that it's kind of heavy, and not ideal to call every time you enter scheme code.
<mark_weaver>I worry that it will slow things down.
<dje42>If I had a way to call install_handler directly, that would improve things.
<mark_weaver>I also worry that signals will get lost if they are delivered close to the time when you remove the handler.
<mark_weaver>(switching back from guile into gdb)
<dje42>E.g., split scm_sigaction_for_thread into two: One to let me use my own SIGINT handler, and one to let me install the thread for a signal and its async.
<dje42>The latter I might have to only do once too.
<dje42>I think I have the "don't lose signals when switching from guile -> gdb" covered. I even have a testcase. Hope it's correct. :-)
<mark_weaver>I don't know, this all seems gross to me.
<mark_weaver>I'm trying to think of the long-term.
<mark_weaver>I don't want to be stuck with a poorly thought-out API for 10 years because we were impatient.
<dje42>Actually, so am I. I was thinking this would carry over to the non-signal-pipe case.
<dje42>We don't have to implement this for 2.0.10. I'm just in thinking-things-through mode too. :-)
<dje42>Anyways, reallly gotta run now. Ciao.
<mark_weaver>okay, ttyl! thanks for working on this :)
***wleslie_ is now known as wleslie
<nalaginrut>I found a good site for algorithm http://www.cs.usfca.edu/~galles/visualization/Algorithms.html
<ArneBab_>nalaginrut: thanks for sharing!
<nalaginrut>ArneBab_: I'm writing some basic data structure for myself, so I need it
*nalaginrut love to implement data structure with Scheme~
<ArneBab_>nalaginrut: how to do that performant?
<nalaginrut>With delimited-continuation we don't have to design callback interface, just let user do what ever they want. I'm talking about the tree implementation
<nalaginrut>it's easy to implement tree-slice
<nalaginrut>and a generic meta tree finder, any kind of tree could take advantage to implement add/remove/search, trees become easy to extend
<nalaginrut>anyway, these could be done with callback
<nalaginrut>either
<nalaginrut>I just try another interesting way
<ArneBab_>I think I don’t really understand yet…
<ArneBab_>practical: Do you build on a C-implemented data-structure or just lists or vectors?
*ArneBab_ is trying to expose his ignorance…
<nalaginrut>ArneBab_: sorry , a bit busy now ;-)
<nalaginrut>ArneBab_: you'll understand it when you see the code someday
<ArneBab_>ok - thank you!
***add^_` is now known as add^_
***add^_` is now known as add^_
***wleslie_ is now known as wleslie
*wingo just fixed figl's docs to work with new texinfo
<wingo>well
<wingo>i will have done so when the push completes
<wingo>$%^&* network over 3g...
<taylanub>3G in Germany is rather pleasent .. often amazes me when I think of it, having fast Internet access around all cities and even some rather rural places, on your mobile device. Edge is like 56k though.
<wingo>i forgot how nice figl's docs were
<davexunit>wingo: "Update docs generator to work better with newish makeinfo" - Thank you!
<wingo>np :)
<davexunit>wingo: do you have plans to make a release?
<wingo>davexunit: it should be as guile-opengl i think
<wingo>i don't know the status, i guess i should figure that out
<wingo>do you want to do it?
<wingo>you can be admin on the project if you like
<davexunit>wingo: I could do that.
<davexunit>so, we would need to rename guile-figl to guile-opengl and figure out what features are missing.
<davexunit>I don't know how many others are using figl for their guile applications besides you and I, but figl has had everything that I needed for guile-2d.
<davexunit>I haven't read the code extensively, but it's complete enough to me to warrant releasing it.
<didi>Is there some data structure for thread communication, like mailboxes?
<didi>I'm guessing not. Oh well, I'll have to play with mutexes.
<civodul>Hello Guilers!
<dsmith>hey hey
<dsmith>(snow day for me so far)
<mark_weaver>hi dsmith! btw, I haven't seen sneek here in a couple of weeks. is he okay?
<dsmith>Hmm.
<civodul>BTW, any news from wingo's compiler? :-)
<mark_weaver>civodul: he made it available on gitorious
<mark_weaver> https://gitorious.org/guile-compost
<civodul>oh, nice!
<civodul>he didn't write about it, did he?
<mark_weaver>not that I saw
<civodul>oh
<civodul>i tried Mike's MIDI thing and it's real fun :-)
<mark_weaver>wingo said that with guile-compost, he could manage 400K particles at 60 FPS on his machine.
<mark_weaver>(the figl particles demo)
<civodul>how does that compare to the bytecode version?
<mark_weaver>dunno off-hand, but davexunit implied in his response that he was unable to get 20K in current guile.
<mark_weaver>well, I'm not sure. you'll have to ask davexunit or wingo how it compares.
<cluck>:)
<civodul>ok
<civodul>howdy wingo!
<civodul>what's up with compost? :-)
<wingo>civodul: i have a blog to post later tonight :)
<wingo>all written, just have to edit
<civodul>wingo: aaah, cool!
<davexunit>I haven't run the regular figl demo without compost in awhile, but I vaguely recall ~5k being a good particle size and now I'm running pretty happily with ~50k
<wingo>davexunit: did you get a new machine? the optimizer is a little better than it was, but not that much better :)
<wingo>davexunit: or do you mean that you are doing 50k with compost
<davexunit>50k with compost.
<davexunit>I need run the un-composted particle demo with 2.2
<wingo>cool
<davexunit>then I'll have a better idea of the improvement.
<wingo>davexunit: you can run GUILE_AUTO_COMPILE=fresh NO_COMPOST=1 ./env examples/particle-demo.scm NNNN
<davexunit>oh, wow!
<davexunit>that's awesome
<davexunit>I'm interested in how much performance I could eek out using a GLSL shader with point sprites.
<davexunit>it's not much to look at, but I have a cute little guile-2d screenshot I wanted to share: https://my.owndrive.com/public.php?service=files&t=0ccd462918e25015779b16c31df49f2e
<mark_weaver>haha
***amoe_ is now known as amoe
<ijp>davexunit: a black snake is more traditional
<davexunit>ijp: ;)
<wingo>neat :)
<davexunit>I was just testing out REPL interaction. the little guy could be moved around with the arrow keys.
<davexunit>built entirely from the geiser REPL.
<davexunit>starting to play with ideas for a demo screencast. I'm thinking of making pong or breakout.
<madsy>Is there a function I can call or variable I can read to see if the guile build is 32-bit or 64-bit?
<davexunit>wingo: regarding figl and an eventual release, we need a webpage and a place to host the releases. would nongnu.org be the best place?
<civodul>davexunit: gnu.org actually, because it's GNU now IIRC
<davexunit>civodul: oh! I didn't know that.
<davexunit>great.
<mark_weaver>madsy: in general, it's better to test more fine-grained things, because how do you handle the new x32, for example? but: (use-modules (system foreign)) and then use (sizeof '*)
<mark_weaver>*x32 ABI
<mark_weaver>madsy: out of curiosity, what is this for?
<madsy>mark_weaver: Some weird pointer juggling in the C code. But I might find a workaround.
<madsy>Indeed, the best thing would be not to depend on any architecture-dependent types at all
<mark_weaver>madsy: if you tell me more about what you need to do, I might have a better solution for you.
<madsy>Yep, I'll get back to you if it's still a problem
<davexunit>I'm seeking some advice. In guile-2d, in order to ensure that the opengl context is always available in the main thread without the user having to do anything, I open an SDL window when the (2d window) module is imported. This has the annoying side-effect where an SDL window opens and closes a bunch of time when compiling the scheme files.
<davexunit>is there anyway that I could keep the existing convenient behavior of opening the window automatically, but wrap it in some condition that prevents it from opening during make?
<mark_weaver>I don't think a module import should open a window.
<mark_weaver>gotta go afk for a bit...
<davexunit>later!
<madsy>davexunit: You can perhaps make it less intrusive by creating a window of 1x1 width and height
<davexunit>madsy: I might just make the user call (open-window)
<davexunit>and be done with it.
<madsy>Yeah, why not. It's not an outrageous demand to make
<davexunit>well, there's actually an issue with that haha.
<davexunit>the font and sprite modules load their shaders upon import. I guess I'll have to defer those too.
<davexunit>I guess I need to write some abstraction for delaying things until after the GL context is created.
<madsy>Or make the user responsible for calling everything he/she will use
<davexunit>(define-delayed some-shader (make-shader-program ...))
<madsy>I create my windows and OpenGL context even before guile starts the REPL. So I fortunately don't have this problem.
<davexunit>I wanted some modules to work in an emacs-like way.
<ijp>(use-modules (guile-2d magic))
<davexunit>by including them, you are extending your programming environment.
<ijp>^^ my suggestion
<madsy>The design of OpenGL is kind of stupid that way. A context means a window.
<ijp>and then have a second module called (guile-2d more-magic)
<davexunit>haha ijp
<ijp> http://www.catb.org/jargon/html/magic-story.html
<ijp>on a related matter, if you run "make check" on guile-sdl, you get lets of pretty pictures appear and disappear
<ijp>It's the only part of the guile-sdl experience I recommend
<davexunit>ijp: I depend on guile-sdl
<davexunit>for better or worse.
<davexunit>but god damn it I don't want to write an SDL 2 wrapper.
<davexunit>so maybe importing the module won't open a window or load shaders, but I could write a special form that imports the module *and* runs some initialization routine.
<davexunit>(2d-require (2d window)) or something
<didi>As I understand it, I can't pass a file name to `use-modules', right?
<didi>e.g. (use-modules "/tmp/module.scm")
<davexunit>you would do (use-modules (some module))
<didi>davexunit: Right. Tho (some module) has to be inside my load path, hasn't it?
<didi>I mean, can I arbitrarily point to a module inside my file system?
<davexunit>yes
<davexunit>it needs to be in your load path
<didi>Oh cool.
<didi>...
<davexunit>sorry, was typing "yes" before the next message showed up.
<didi>oic
<davexunit>you can use add-to-load-path
<didi>I see.
<davexunit>you can also pass the -L /path/to/my/module to guile
<didi>davexunit: A nice feature, tho as I work primarily in the REPL, it doesn't help me directly.
<didi>It would be cool with I could point to modules using file system paths.
<didi>(use-modules (file "/tmp/module.scm")) maybe.
<didi>But I think my last expressions wouldn't work as every symbol inside the `cadr' of the `use-modules' expression is interpreted as a path inside the load path.
<stis>evening guilers!
<didi>Maybe if we added a `#:file' keyword to the spec.
<didi>(use-modules ((module) #:file "/tmp/"))
<stis>Are thare any one that have read my proposal to get good gc properties for kanren and prolog in guile?
<stis>Is it a good idea?
<stis>The interesting thing that getting good gc properties speaks against using an assoc for variable binding.
<stis>no? am I wrong? perhaps, just cleaning the current assoc might be enough though.
<wingo_> http://wingolog.org/archives/2014/02/18/compost-a-leaf-function-compiler-for-guile
<stis>\\me cheers over wingo asemblasting the speed barrier
<mark_weaver>wheee!
<davexunit>wingo_: great read, as usual.
<stis>+1
<dsmith-w`>heh. "compost"
***dsmith-w` is now known as dsmith-work
<davexunit>it's a clever name.
<civodul>indeed, excellent intro :-)