<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. *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>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>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>I'm leaning towards writing macros that will always make a trampoline from the callback <wingo>38 failures, 6 errors, and one upass <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 <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. git@github.com:dje42/gdb.git 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.] <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 git@github.com:dje42/gdb.git , 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 <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>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 guile-user@gnu.org about it <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! <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>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>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. <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>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" <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". <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>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>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>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? *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. <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. <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? <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? <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>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>though with the proper packaging of guile libraries and stuff it wouldn't be bad. <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. <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>But Scheme '() is still true. So the wording is not quite correct.