IRC channel logs


back to list of logs

<ArneBab>sneek: later tell davexunit: fix for examples/coroutines.scm:
<sneek>Will do.
<ArneBab>sneek: later tell davexunit: and for examples/action.scm:
<sneek>Will do.
<ArneBab>sneek: botsnack
<stis>ijp: try using ,exp in stead of ,optimize, shows that the problem is not in peval, perhaps fix-letrec if that is used in ,exp
<davexunit>mark_weaver: hey. I made a working "cooperative" REPL server last night.
<sneek>davexunit, you have 9 messages.
<sneek>davexunit, ArneBab says: that it would be really cool, if guile-2d were installable from guix (along with all dependencies).
<sneek>davexunit, ArneBab says: or at least with all the dependencies which are not in debian.
<sneek>davexunit, ArneBab says: Here’s a patch to include installation instructions for Gentoo:
<sneek>davexunit, ArneBab says: The examples/images folder misses sprite.png (from
<sneek>davexunit, ArneBab says: A patch to get examples/scenes.scm running:
<sneek>davexunit, ArneBab says: How does guile-2d handle it, if it cannot realize a timestep of 1/60th of a second?
<sneek>davexunit, ArneBab says: What I really liked in pyglet was that every step of the game-loop got a dt parameter which contained the time since the last step. That allows for physically realistic behaviour.
<sneek>davexunit, ArneBab says: fix for examples/coroutines.scm:
<sneek>davexunit, ArneBab says: and for examples/action.scm:
<davexunit>holy shit. so many messages.
<davexunit>ArneBab: hey
<davexunit>ArneBab: I screwed up the examples before I released. sprite.png was an asset that I couldn't find the author of, so I ditched it, but forgot to update all of the examples.
<davexunit>ArneBab: they are fixed in master.
<davexunit>ArneBab: the problem with the dt approach is that, in pyglet, dt varies from frame-to-frame, causing non-determinism. I find it much easier to think of time not in seconds, but game ticks.
<davexunit>ArneBab: and finally: thanks for the gentoo instructions. I will apply this patch to master.
<mark_weaver>davexunit: ah yes, I saw that while reading my logs of this channel. that's good news!
<davexunit>mark_weaver: I have on thread-unsafe bit to deal with, still. but overall it's looking good.
<davexunit>mark_weaver: did you happen to see my mailing list post about the repl server?
<davexunit>ArneBab: error when applying your patch :( "fatal: corrupt patch at line 83"
***scmaccal is now known as scmaccal_
***scmaccal_ is now known as scmaccal
<davexunit>ArneBab: your diff is hg format, not git?
<mark_weaver>davexunit: yes, I saw your message. I'm not sure the code is complex enough to warrant generalization, but my first thought is that there could be a 'with-terminal-port' or something like that, which would redirect input+output+error.
<mark_weaver>that alone would simplify it quite a bit
<mark_weaver>though again, I'm not sure if it's a common enough operation to warrant its own procedure.
<mark_weaver>the bit that initializes *repl-stack* to '() is a bit unfortunate though, since it leaks an implementation detail.
<youlysse`>So guile-reader is installed, but when I try to build skribilo on my host-machine -- Fedora 20, it won't find the module '(system reader)'. Ideas?
<mark_weaver>youlysse`: what's the value of %load-path? is there a DIR in that path such that DIR/system/reader.scm exists?
<mark_weaver>(I guess maybe you installed skribilo with prefix /usr/local, and those paths are not in Guile's default load path)
<mark_weaver>if so, you'll need to augment your GUILE_LOAD_PATH (and preferably also GUILE_LOAD_COMPILED_PATH) appropriately, perhaps in your dot files.
*youlysse` loves that he's so apt to ask questions, when he's cognitively not lucid enough to do anything about it appropriately. :^I
<mark_weaver>youlysse`: Don't worry about it. I don't think it's a question of lucidity, as much as knowledge of Guile. I've used Guile enough, and answered enough questions on #guile, that most of the time it's a question that's already cached in my brain :)
<youlysse`>mark_weaver: Well lucid enough, to be able to figure it out more-or-less by myself (and/or with a trivial amount of assistance). :^)
<youlysse`>That being said, yeah -- surely I have a long-way to go. Which is both exciting and scary, but I'm hopeful and excited.
<davexunit>mark_weaver: okay. I suppose I will just maintain my own "fork" of the repl server.
<mark_weaver>davexunit: do you need anything more than your own 'serve-client' procedure?
<davexunit>mark_weaver: no.
<mark_weaver>that's a small enough amount of code that I'm not sure I'd call it a fork.
<davexunit>mark_weaver: well I maintain the module separately, anyway.
<mark_weaver>sounds reasonable, though it should probably have a different module name than (system repl server)
<davexunit>it's (2d repl server) in my project.
<mark_weaver>sounds good
<davexunit>I just thought that it would be cool if the server could start repls other than the default one.
<mark_weaver>I agree that it would be nice. I'm not opposed :)
<mark_weaver>I'm just kind of overwhelmed with things to do right now.
<davexunit>mark_weaver: no worries. :)
<davexunit>thanks as always.
<mark_weaver>you're welcome!
<mark_weaver>here are some ideas of ways to generalize:
<mark_weaver>first, it would be nice is 'start-repl' could accept a keyword argument that specifies custom repl options to use.
<mark_weaver>it would also be nice to have a procedure that handles initializing *repl-stack* to '() before calling 'start-repl', so that you don't have to leak that implementation detail into guile-2d. maybe it could be a different procedure like 'start-top-repl', or perhaps it could be a keyword argument #:top? or something.. dunno.
<mark_weaver>and as you suggest, maybe it would be nice to be able to somehow provide an alternative to 'serve-client' when starting a server.. but I'm not sure how best to do that off hand.
<davexunit>well that gives me some things to think about. thanks.
***sneek_ is now known as sneek
***bananagram is now known as Hi
***Hi is now known as Guest12045