IRC channel logs


back to list of logs

<davexunit>shanecelis: hey. could I pick your brain for a minute?
<davexunit>I'm wondering about how you provide an emacs-like dynamic environment in emacsy. I'm trying to tackle a similar problem for guile-2d.
<davexunit>figuring out how to write something elegant, but easily modifiable via the repl is proving to be quite the challenge.
<gzg`>wingo: Afternoon. o/
*wingo works through a few test suite failures with the rtl vm
<gzg`>wingo: Working towards that 2.2 title? :^)
<wingo>2.2 would be nice, but a merge to master would have to happen first, and for that i need to fix a few tests...
<gzg`>wingo: Understood, just excited. :^)
<davexunit>was anyone around when shanecelis was discussing how to handle key bindings in emacsy?
<davexunit>iirc, he was having dealing with key bindings being bound to procedures, because when he redefined the procedure at the repl, the change would not take effect.
<davexunit>the procedure had to be trampolined.
<davexunit>I'm wondering if he wrote some macro such that the callback procedures were *always* trampolined or if it was left to the user to do that.
*davexunit will be browsing the source, but figured he'd mention this here, too
<wingo>i remember the occasion but i don't remember the conclusion
<wingo>sneek: logs?
<sneek>Someone once said logs is
<wingo>you might try there fwiw
<wingo>ffs, there is code that relies on struct-set! returning a value
<wingo>specifically the object that is being set
<davexunit>I'm facing similar design issues with guile-2d, since I share the goal of emacsy of proving good repl interaction.
<davexunit>thanks, wingo
<davexunit>I'm leaning towards writing macros that will always make a trampoline from the callback
<wingo>38 failures, 6 errors, and one upass
<wingo>that's pretty good
<davexunit>in common lisp, I see a lot of macros in the style of: defvar, defcustom, defgroup, etc. but in the scheme code that I have read, I don't see custom define-* macros often.
<wingo>really? i like custom define macros
<davexunit>is it preferred to use a style like (define foo (make-bar)) instead of (define-bar foo) ?
<davexunit>wingo: okay great. this is exactly the type of thing I'm interested in hearing about.
<davexunit>I'm searching for a "best practice" to follow.
<wingo>davexunit: no real preference, both are fine, but i find that custom define macros are more expressive
<wingo>they read better and they are more succint
<davexunit>I feel that way too.
<davexunit>thanks for the input.
<wingo>np :)
<dsmith>I would think the make-foo style is more flexible. Like it could be used with let, where a define-foo is probably only good a top level.
<dsmith>But then, that may be exactly what is desired.
<dje42>Ok, here's my first pass. The branch is gdb-guile.
<dje42>configure/make as normal, the configure script should find libguile automagically if installed in standard place
<dje42>[If you don't want to build all the binutils pieces, you need to add: --disable-binutils --disable-gas --disable-gprof --disable-ld. We should make that easier.]
<mark_weaver>dje42: what's the git URL to clone it?
<dje42>The one I gave should work. Alas I tried it and it only grabs the master branch. I'm guessing there's a way to grab the desired branch automagically but I don't know what it is.]
<dje42>After I did a simple clone I did,
<dje42>git checkout -b gdb-guile --track origin/gdb-guile
<dje42>e.g. git clone , and then checkout the gdb-guile branch
<mark_weaver>can you give the url to the web page for your project?
<ijp>davexunit: I've seen plenty of define- in my time, but I wouldn't just add them every time
<mark_weaver>okay, so the clone url is
<dje42>Ah, for those that don't have ssh keys on github, righto.
<dje42>mark_weaver: let me know if you can clone that repo ok. thx!
<mark_weaver>yes, it works fine
<mark_weaver>It'll probably be a while before I can take a close look at it, though. This next week is fundraising week at the radio station I work at.
<dje42>No worries. This project is done on my own time - I *completely* understand!
<mark_weaver>you might want to post to about it
<wingo>evening, civodul :)
<civodul>hello shanecelis!
<civodul>what's up with Emacsy?
<shanecelis>I had to put it aside for a little bit while work picked up, but I'm back at it.
<shanecelis>civodul: I owe you that GTK webkit with tiling window manager, I know!
<civodul>heh, work is important too ;-)
<shanecelis>davexunit: I'm around now if you want to chat. (re: to message from long ago)
<shanecelis>civodul: how are things with you? any guix updates?
<civodul>well it's making progress
<civodul>we had that bootable VM image a while back, with dmd on it
<davexunit>shanecelis: I'm wondering if you ended up trampolining everything in things like keybinds so that when the procedure is redefined at the repl, the new procedure is used, not the old one.
*shanecelis looks up dmd
<shanecelis>davexunit: Yes, that's what I ended up doing. If the user provides a symbol for a keybinding, I make a trampoline. If they provide a procedure, I assume they know what they're doing.
<davexunit>shanecelis: I see. I may do something similar. thanks.
<davexunit>if I had a nickel for every time I've done that...
<shanecelis>davexunit: I sent you an email with a few more details and a link to a gist that might be helpful.
<davexunit>shanecelis: much appreciated.
<shanecelis>davexunit: You mentioned that trying to provide a dynamic environment like Emacs was a bit of a stumbling block. Is it the keybindings that are a major stumbling block or other stuff?
<davexunit>shanecelis: currently other things.
<davexunit>I'm implementing a system that you can think of like buffers and modes in emacs, but for game related things, to help break up games into smaller pieces.
<shanecelis>civodul: Daemons-managing Daemon, heh, read it as "daemons managing daemons" as in "kids having kids."
<davexunit>but I face the same basic troubles: when the programmer updates something at the REPL, I want that change to be immediately represented in the game window (in most cases)
<shanecelis>davexunit: [nods] are you thinking like "play-mode", "design-mode", "debug-mode"?
<shanecelis>davexunit: right. and there can be non-trivial dependencies.
<davexunit>shanecelis: more like "main-menu", "stage-select", "gameplay"
<shanecelis>davexunit: oh cool. I like that breakup.
<davexunit>so you define the behavior of a piece of the game: how to draw, how to update, a thunk to create the game state, etc.
<davexunit>and then the "buffer", if you will, is the place in which these things get applied. it has the coroutine scheduler, the game state, the current "mode", and possibly other things in the future.
<davexunit>my goal is to keep the "mode" objects immutable, and keep all of the dynamic stuff in the "buffer".
<shanecelis>Is there just one "buffer"?
<davexunit>there's actually a stack of them.
<davexunit>scenario: from "main-menu", I go to "options" and press the back button. I should be back at "main-menu".
<davexunit>this also means that the same mode can be applied to the different buffers.
<shanecelis>davexunit: So is one of the issues that if you start the app, it works fine, but when you start altering things, it becomes inconsistent?
<davexunit>that's one possible problem, yes.
<shanecelis>what are the other problems?
<davexunit>I was also struggling with how to model game state.
<davexunit>a mode shouldn't just start mutating module level variables or anything, because that mode could be applied many times.
<davexunit>I could use "let" and company, but that creates an environment that is difficult to inspect and modify at runtime.
<shanecelis>davexunit: right. So you're vying for buffer-local variables on some level.
<davexunit>something of that nature, yes.
<davexunit>right now I'm trying this: a mode specifies a thunk whose return value is the game state to use, and that gets passed to every callback (update/draw/etc)
<davexunit>I tried making a buffer-local variable system, but it got ugly.
<shanecelis>davexunit: yeah, there's some code floating around that tries to show how one can implement a buffer-local variables in guile, but I punted on that for a much more simplistic (local-var 'something).
<davexunit>yeah, the way I'm trying now is so much simpler.
<davexunit>which may be for the best.
<davexunit>this way, the callback procedures are at the module level, not buried in a let or something. easy to deal with at the repl.
<shanecelis>So this stack of buffers, can it be accessed out of order?
<davexunit>not in the api that I provided, but the order doesn't *really* matter.
<gzg`>In-regards to a tiling wm via Emacsy, how would it compare and would it be preferable than writing a specified module on-top of guile-wm?
<davexunit>shanecelis: why do you ask?
*ijp rolls eyes at the mention of window managers
<shanecelis>davexunit: just curious. For Emacsy I have a most-recently-used stack that holds the buffer list.
<gzg`>ijp: Well, I just think it'd be an unnecessarily splitting of resources, to have one for each "toolkit". :^P
<gzg`>Assuming both "picked up" in the community.
<davexunit>shanecelis: oh I see.
<shanecelis>gzg`: They're pretty different use cases. Guile-wm is a full-blooded X window manager. This Emacsy thing would just allow one to provide an Emacs-like, single-application windows. Also, Guile-wm only works on X, whereas Emacsy could be used elsewhere.
***add^_` is now known as add^_
<shanecelis>davexunit: I like the idea of breaking the app into buffers and modes, makes me think of how I've seen people use Emacs to do a slideshow.
<shanecelis>davexunit: Having watched /r/gamedev too it seems people do have a bit of difficulty figuring out how to knit all the game elements together.
<davexunit>shanecelis: I've seen other game libraries do similar things. though usually buffers and modes are essentially rolled into one class.
<davexunit>yeah, I think it's a rather tough problem to solve nicely.
<gzg`>shanecelis: To my understanding, guile-wm isn't actually a wm -- but a way to implement one, really even it could be used as a graphical toolkit, from my understanding. But yeah, certainly it;d be easier to get it working on say wayland and the default use-case is much more relevant to me. That being said, it'd be cool if there was a custom compositor for wayland, in guile. :^)
<davexunit>I don't yet know what I want to do for more granular game states.
<gzg`>from my very limited understanding/investigation into guile-wm*
<shanecelis>gzg`: I should take a deeper look into then if it's more abstract than I'm thinking. I have looked into the code somewhat because there was a number of Emacs-like things in it.
<shanecelis>davexunit: for example?
<gzg`>shanecelis: Would you mind if I added Emacsy to my list of things to package for Guix? :^)
<shanecelis>gzg`: This may make Emacsy seem worse to your perspective, but really all Emacsy does is manage a tree of window descriptions. The implementer is tasked with actually realizing them, which is harder (OpenGL) or easier (GTK) depending on your toolkit.
<shanecelis>gzg`: Oh, that'd be great, though we should probably wait on it a little longer.
<gzg`>shanecelis: Second formal release, fine?
<shanecelis>gzg`: Well, it's been pre-released 3 times, so let's shoot for the fourth one. :)
<davexunit>shanecelis: so you have a "rpg-battle" mode. there are several sub-states here. "player-move", "enemy-move", etc.
<davexunit>but I'm unconvinced if I need to worry about modeling that.
<davexunit>may be best to let the programmer write what they need in that regard.
<shanecelis>davexunit: I see. Yeah, I think that's a good idea. Are you building up guile-2d in tandem while writing a game?
<davexunit>shanecelis: I have a game in mind, but right now I have just small examples.
<gzg`>shanecelis: Not my ideal system, but seems like a wok able enough of an approach -- seems like the practical solution, to my idealistic nature. To be "fully happy..." I'd want an opengl accelerated compositor for wayland (in guile) that could act as a toolkit, but blends very well with a completed guilemacs. :^P
<davexunit>I wrote a bit of a small shoot-em-up game to see where I felt the weak points were.
<shanecelis>davexunit: Cool. Yeah, it's tricky to write the library and app in tandem. It induces a lot of analysis paralysis for me. Which part goes where?
<davexunit>yeah I've felt that a lot.
<shanecelis>davexunit: Once I get guile-sdl working on my machine, I'm going to try guile-2d on a game jam. If it's not a total disaster (which it will be), maybe I can contribute it as an guile-2d example.
<davexunit>shanecelis: yay!
<davexunit>it will be *really* hard to get anyone else to play it though.
<davexunit>it's not exactly packaged or easy to install yet.
<shanecelis>davexunit: Yeah, I know, ain't packaging a bitch.
<shanecelis>It's funny how getting the thing written and working on your machine doesn't even feel like it's half-way working if you're trying to share it with anyone else.
<shanecelis>I think this is why everyone is writing in javascript these days. It's already on the client machine.
<davexunit>heh, yeah. it's certainly easy.
<davexunit>though with the proper packaging of guile libraries and stuff it wouldn't be bad.
<shanecelis>davexunit: very true.
<davexunit>it's easy to get python or ruby stuff running. pip install or gem install and off you go.
<shanecelis>all right, going AFK, see you guys later with head-scratching (to me) questions, no doubt.
<davexunit>see ya, shanecelis
<gzg`>shanecelis: o/
<amgarchIn9>is this even true, dje42? Not on the scheme side: (if '() 'a 'b).
<dje42>amgarchin9: Need More Data
<dje42>Ah, () vs #f.
<amgarchIn9>there is a nil-thing for elisp that is new: (if #nil 'a 'b) => 'b
<dje42>grep scm_is_false libguile/boolean.h
<amgarchIn9>hm, you are right.
<amgarchIn9>But Scheme '() is still true. So the wording is not quite correct.
<dje42>Thanks. I'll tweak it.
*civodul browses
<civodul>nice piece of work