<janneke>ah, somehow the arglist keywords get gc'd...hmm how can that be? ***turbofai` is now known as turbofail
<janneke>hmm? (delq '(3) '((1) (2) (3))) => '((1) (2)) <civodul>janneke: in compiled Guile code there's only one '(3) literal, i think, so (eq? '(3) '(3)) => #t <civodul>it's not true if you do ",o interp #t" <ArneBab>did something change with readline in 2.1.4? I can (import (ice-9 readline)) but (activate-readline) throws an unbound variable error. <davexunit>civodul: this was in response to our conversation about unattended upgrades in #guix, when I said that I'd want an automated test to determine if the new system is OK or not. <janneke>Nyacc's calc demo now runs (slowwww) in Mes! <janneke>Although i have a [very incomplete] C lalr parser that does not need syntax-case, joining forces with Nyacc would be so much nicer :-) <paroneayea>janneke: also glad you found the prescheme link useful <paroneayea>I wondered whether it had overlap with what you're doing <janneke>i'm also still wondering about the overlap, but it is inspiring! <linas>what's the right place to rport a bug? savannah? <paroneayea>civodul: I expect 0.4 to come around the corner quickly, and finally with real docs. the api should also slow down in its changes around then, as I think I have a good idea of what the right interfaces are now. <janneke>ACTION really wants to get some feel for 8sync; using nodejs at work for websockets+async <paroneayea>and, I will make sure 0.4 is in packaged in guix proper :) ***holomorph is now known as Guest44220
***holomorp1 is now known as holomorph
<paroneayea>8sync has been "the right interface through successive approximation" classic lisp design ;) <paroneayea>but eventually, it will need to stop changing so much... for my needs, not to mention any other possible users ;) <davexunit>paroneayea: how do you do live coding in your concurrent world? it's something I'm struggling with right now. <davexunit>if I have a bunch of concurrent fibers in a game, for example, I'd like to be able to re-evaluate one somehow. <paroneayea>1) I have (wrap) and (wrap-apply) macros which make re-evaluating htings a bit easier (really just wrapping in a thunk that references some other procedure at the top level) <paroneayea>2) for the record-y bits, using GOOPS with the actor model helps <paroneayea>3) since it's message passing, referencing which action of the actor is handled at message handler evaluation time <davexunit>I think #1 might be similar to something I'm trying but haven't really put through its paces yet. <davexunit>I have a 'define-coroutine' macro so that you can define coroutine objects at the top level <davexunit>if the coroutine is already running it will cancel it and start the new one. <paroneayea>but, I think that is one thing that's nice about 8sync right now <paroneayea>when I'm hacking on the MUD I'm changing how everything works as I walk around the world <paroneayea>I'd like to add some repl commands similar to what fibers has <paroneayea>and watching what messages are passing along the wire <paroneayea>currently I just dump pk statements straight into actors.scm when I need to spy <paroneayea>but obviously that's not a good long term strategy :) <paroneayea>one thing that will be coming by 0.5 probably is "remote actors" <paroneayea>erlang-like ability to talk to actors on another process or machine <paroneayea>I probably spend most time debugging in there, which probably is to the detriment of making demos that would become tests otherwise <davexunit>I think I need to adopt fibers notion of schedulers <davexunit>and give each game entity its own, or something. <davexunit>or maybe what I have now works just fine, dunno! <paroneayea>I spent some time talking with my brother about a decent RPG battle system <davexunit>right now I maintain a process tree. every new thread spawned registers itself as a child of its parent <paroneayea>so I'm kind of resisting the temptation to implement right now <paroneayea>but might be good to play with in the next lisp game jam :) <paroneayea>I've been spending so much time retooling 8sync I haven't quite gotten to the things I want to use it for yet, but my hope is that in a couple of weeks it'll be stable enough for me to port pubstrate's web application to it <paroneayea>as well as the activitypub test suite that *in theory* I'm supposed to be working on ;) <paroneayea>davexunit: I really want to get your websocket stuff ported to 8sync too. Hopefully soon! <davexunit>we can make a mean websocket server with that <davexunit>with suspendable ports, we still have to manage the scheduling right? <davexunit>I'm in one of those moods where I have tons of ideas buzzing around in my head, but I know I won't be able to accomplish any of them. <paroneayea>davexunit: suspendable ports basically jump out to a point so that your scheduler *can* handle them on its own <paroneayea>I think I maganaged to rewrite 8sync to use suspendable ports in one evening. <davexunit>I'm hoping that I will be able to write some basic code for game networking using udp with this stuff <davexunit>ACTION draws up a TODO list of features for a new, less opinionated game toolkit <paroneayea>davexunit: hm, so you have sdl / opengl experience, and I have this async library :) <civodul>davexunit: but Sly is pretty cool, isn't it? <paroneayea>I wonder if we can combine forces to test out an 8sync demo <davexunit>civodul: this will essentially be sly reimagined a bit. <davexunit>I'm dropping the FRP thing and aiming for getting the lower level building blocks right <davexunit>paroneayea: maybe a graphical frontend for mudsync? <paroneayea>davexunit: could be cool, though maybe if going that route, might be more fun to design something more specifically to be graphical <davexunit>civodul: so I already have a lot of code to re-use. <paroneayea>davexunit: re: the MUD and graphicalness, I might eventually have a web interface <davexunit>but I'm paying more attention to performance this time around. guile 2.2 has really changed my expectations. <paroneayea>since I think that might make a MUD more accessible to the modern world <davexunit>paroneayea: well, what's a networked game that we could in 2D? <paroneayea>davexunit: well, my long-running vision is still to have a top-down Zelda-like MMORPG using LPC assets <paroneayea>davexunit: or maybe just MRPG, doesnpt need MM :) <davexunit>paroneayea: to keep it reasonable to do, I would like to go the phantasy star online route: everyone joins a communual "lobby", but then goes into their own game with a strict player cap of 4 or something. <davexunit>paroneayea: top-down zelda-like sounds good to me <paroneayea>davexunit: aeva has also pointed out to me that cheating protection is hard, and the most fun game might be one played between close friends <paroneayea>davexunit: as in, either everyone agrees not to cheat or to have fun cheating :) <paroneayea>davexunit: I also still wonder about server vs client side scripting <paroneayea>davexunit: I wonder how fast server-only scripting could go. <paroneayea>syntensity did some neat things about running server and client code off the same code, but they had JS sandboxing <davexunit>paroneayea: I don't think it's a concern for this game. <davexunit>I mean, it *could* be, but we could just go the simple route of letting the admin install any extensions <davexunit>or grant special players access to do the same <davexunit>basically punt on the entire problem. it's a group of close friends, after all! <davexunit>paroneayea: so what do you say? should we go for it? if we really restrict our initial featureset I think we can do it. <paroneayea>davexunit: yes, let's go for it! But let me get out 8sync 0.4 first :) <paroneayea>davexunit: and hopefully you can try the tutorial, so you can know what (at least the backend) would work like <davexunit>but I can also just make a guix.scm file that grabs 8sync from whichever git commit you want. <paroneayea>davexunit: oh, I mean, let's wait for 0.4 because I'll have documentation then :) <davexunit>paroneayea: one important question: can 8sync be integrated into a game loop? <davexunit>I need an entry point to "tick" 8sync's scheduler along <paroneayea>a) either the actor model is refactored to allow it to sit on top of arbitrary event loops <paroneayea>b) and/or the game engine can be layered on top of it <paroneayea>eg it would be possible to set up an actor that runs the main "game engine" type things, like blitting to an sdl canvas <paroneayea>and have it sleep as long as necessary for each tick <davexunit>I think it's important for the game loop to be the very core <paroneayea>davexunit: alternately, the backend and frontends can be two different codebases, as long as they speak the same protocol <davexunit>in sly all I would do is update the global agenda <paroneayea>I don't know what you mean by "update the global agenda" <davexunit>you basically need to expose a procedure for doing what would be one iteration of your event loop <paroneayea>ah right, yeah there's something stubbed for something like that in 8sync's core <paroneayea>davexunit: whether or noth this is possible I think will be determined by trying it :) <davexunit>in sly's case, there was a global scheduler, (current-agenda), that needed to be pushed forward <paroneayea>davexunit: right, that happens in 8sync as well. <davexunit>does it have a notion of time-based scheduling? <paroneayea>davexunit: let's keep talking about this evil plan :) <davexunit>and can you increment by arbitrary amounts of time, rather than using system time? <davexunit>we need to step the game simulation by a fixed time step <paroneayea>davexunit: let's both iterate a bit more on our respective projects and keep talking about this :) <paroneayea>sounds like we're both mid-iterating on things that will make this more possible <davexunit>while LPC art assets aren't my personal aesthetic, I think using them will be a nice showcase of free art assets :) <davexunit>LPC art has a very... "western" style, I would say. I like the japanese style. <paroneayea>davexunit: one of the LPC assets came with much more "anime" characters <paroneayea>but, I think the LPC base character design is modular, which is nice <davexunit>compare final fantasy 6 graphics to LPC, that is a good example of the difference. <paroneayea>davexunit: right, though it would be hard to do FF6 style graphics in as much of a "lego" fashion as LPC <paroneayea>I think you'd need a good art director in charge to keep things consistent <davexunit>maybe it's partly that LPC is very high resolution, and I lean towards more pixely. :) <paroneayea>but, that decision was made in talking with the artist team <davexunit>I think LPC was very well designed for what its goals were <paroneayea>again, an artist team decision... "it's 201X, not 199X... why be constrained by colors" <davexunit>I'm curious how it would have worked out with a fixed pallete. <paroneayea>I've really wanted to make a game with the dawnbringer roguelike tileset <paroneayea>there's no reason someone couldn't do another LPC though <davexunit>I have an opengameart collection of db32 stuff <paroneayea>someone tried to organize it it, but I don't think they realized just how much work it was to coordinate/run <paroneayea>that's the one I really wanted to make a game with, but never got around to <davexunit>depends on what you're vision is, I suppose. <davexunit>I need to learn more about what you have in mind :) <davexunit>I'll read the backlog if you have more to say <davexunit>might be back on on my phone on the commute home <paroneayea>davexunit: I gave it some more thought, and I remembered why I don't think 8sync's actor model can really work with the Sly way of "run everything in one tick, and the tick is time" necessarily <paroneayea>a tick based method of time needs to reach a fixed point <paroneayea>one tick operation, everything needs to complete that happens that tick <paroneayea>that's not guaranteed to be true if actors are sending messages back and forth at their own leisure <davexunit>paroneayea: they just need to be cooperative. do your work and suspend. <paroneayea>davexunit: right, but the actor model I have, I'm not sure whether an actor might do "enough work" for just one tick <paroneayea>you might be able to take that approach with the same system though <davexunit>I think it would be fine. I'd need to see some code to make sure, though. <paroneayea>it might suspend when it wants to send a message to another actor and wait for its reply <paroneayea>eg, maybe "heroine" sends "be-attacked" message to the "bug" actor, and waits for the reply to find out how much damage she got on the bug, if any <davexunit>an AI needs to make room the player to work by waiting after taking actions <paroneayea>davexunit: I'm not positive this is a problem, it's something I've worried about before <paroneayea>davexunit: unrelated, I remember you were thinking about getting into chiptunes composition <paroneayea>just as an aside, since quasi-related to above convo :) <davexunit>oh awesome. I'll check that out. milkytracker is intimidating when you first try it. <paroneayea>davexunit: yeah this tutorial series definitely breaks it down really well. <paroneayea>davexunit: the one caveat I'd make is, in my case, he suggests switching to the Fasttracker II keyboard bindings <paroneayea>I found that for some reason a lot of the bindings he actually said played in the milkytracker one and not the reverse? <paroneayea>so I left it at milkytracker bindings and just kept the manual nearby for the rest <paroneayea>lots of fun though. let me know if you make something cool :) <paroneayea>davexunit: one thing he emphasizes in the videos is that you don't need to know music theory, but it helps :) <janneke>okay, cond => must never re-evaluate its clause <janneke>now my fluids seem to be overly simplistic...