IRC channel logs

2016-12-20.log

back to list of logs

<janneke>ah, somehow the arglist keywords get gc'd...hmm how can that be?
<janneke>ACTION -> zZzzz
***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
<janneke>civodul: interesting
<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.
<lloda>which error? it works here
<janneke>ah! great
<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.
<civodul>davexunit: ah sure, i see
<janneke>Nyacc's calc demo now runs (slowwww) in Mes!
<civodul>janneke: awesome!
<janneke>Thanks!
<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>yay janneke
<paroneayea>janneke: also glad you found the prescheme link useful
<paroneayea>I wondered whether it had overlap with what you're doing
<janneke>paroneayea: yes, thanks a lot!
<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>linas: bug-guile @ gnu . org
<linas>ah OK, thanks
<civodul>paroneayea: congrats on 8sync 0.3!
<janneke>yes! congrats paroneayea
<paroneayea>civodul: thank you :)
<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 
<janneke>but it keeps changing so fast :-)
<paroneayea>and, I will make sure 0.4 is in packaged in guix proper :)
<paroneayea>janneke: yes, sorry
<janneke>paroneayea: np, i like that :-)
***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>repl driven development
<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>davexunit: a few things:
<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>live hacking is really easy
<paroneayea>when I'm hacking on the MUD I'm changing how everything works as I walk around the world
<davexunit>yeah that's awesome
<paroneayea>this needs a tweak, done
<davexunit>I'd like to see a demo of that in action :)
<paroneayea>I should do a screencast
<davexunit>that would be really great
<paroneayea>I plan to do a live demo at FOSDEM
<davexunit>ooh
<paroneayea>I'd like to add some repl commands similar to what fibers has
<paroneayea>but for listing actors
<paroneayea>and watching what messages are passing along the wire
<davexunit>ooh
<davexunit>I didn't know fibers had repl commands
<davexunit>that's something I'm sorely lacking.
<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>that should be a nice feature
<davexunit>cool :)
<paroneayea>mudsync is a nice testbed for 8sync
<paroneayea>maybe even too nice
<paroneayea>I probably spend most time debugging in there, which probably is to the detriment of making demos that would become tests otherwise
<paroneayea>but, at least it's fun
<davexunit>yeah that is very nice
<davexunit>I need something equivalent for myself
<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 :)
<davexunit>yes!
<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>but here I am yak shaving instead
<paroneayea>davexunit: I really want to get your websocket stuff ported to 8sync too. Hopefully soon!
<paroneayea>anyway, back to it
<davexunit>nonblocking IO will be *great* for that
<paroneayea>yeah
<davexunit>we can make a mean websocket server with that
<paroneayea>yeah :D
<davexunit>exciting
<davexunit>with suspendable ports, we still have to manage the scheduling right?
<paroneayea>davexunit: yes
<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
<davexunit>okay
<davexunit>makes sense
<paroneayea>I think I maganaged to rewrite 8sync to use suspendable ports in one evening.
<davexunit>so I still need a poll set
<paroneayea>yep
<davexunit>I have no code to deal with that currently
<paroneayea>8sync is still using select :(
<davexunit>but if I ever do networking I will need it
<paroneayea>eventually it won't though :)
<davexunit>I'm hoping that I will be able to write some basic code for game networking using udp with this stuff
<davexunit>without losing my mind
<paroneayea>yeah
<paroneayea>fun fun fun :)
<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
<paroneayea>using sdl
<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: that would be fun :)
<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: yeah, sounds good.
<davexunit>paroneayea: well, what's a networked game that we could in 2D?
<davexunit>could do*
<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 :)
<ft>Zelda ftw!
<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.
<paroneayea>davexunit: I'd be fine with that
<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
<davexunit>I agree with that assessment.
<paroneayea>davexunit: as in, either everyone agrees not to cheat or to have fun cheating :)
<davexunit>yeah
<paroneayea>davexunit: I also still wonder about server vs client side scripting
<paroneayea>davexunit: I wonder how fast server-only scripting could go.
<paroneayea>it would be easier to hack for sure
<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 :)
<davexunit>okay :)
<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>oh sure :)
<paroneayea>I plan on getting out 0.4 soon.
<paroneayea>fast release cycles these last few weeks :)
<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>davexunit: so I think either one of two things
<paroneayea>one or both of
<paroneayea>a) either the actor model is refactored to allow it to sit on top of arbitrary event loops
<paroneayea>(well, any that support suspendable ports)
<paroneayea>b) and/or the game engine can be layered on top of it
<paroneayea>in Sly's case, I guess we'd need a)
<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
<paroneayea>that eg is for b) :)
<paroneayea>a) I think is self descriptive enough
<davexunit>I think it's important for the game loop to be the very core
<davexunit>it's somewhat complicated and special.
<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
<davexunit>and that would do everything
<davexunit>is that possible with 8sync?
<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
<davexunit>and that would run all pending operations
<paroneayea>davexunit: right, that happens in 8sync as well.
<paroneayea>(agenda-run-once agenda)
<davexunit>perfect
<davexunit>does it have a notion of time-based scheduling?
<paroneayea>davexunit: let's keep talking about this evil plan :)
<paroneayea>davexunit: yes
<davexunit>and can you increment by arbitrary amounts of time, rather than using system time?
<paroneayea>davexunit: not currently :)
<davexunit>okay, we'll need that. :)
<davexunit>we need to step the game simulation by a fixed time step
<paroneayea>davexunit: it is probably possible
<paroneayea>davexunit: let's both iterate a bit more on our respective projects and keep talking about this :)
<davexunit>sure thing
<paroneayea>sounds like we're both mid-iterating on things that will make this more possible
<davexunit>hope the questions weren't overwhelming ;)
<paroneayea>but I like this as a project plan!
<davexunit>same
<paroneayea>:)
<davexunit>while LPC art assets aren't my personal aesthetic, I think using them will be a nice showcase of free art assets :)
<paroneayea>davexunit: what's your personal aesthetic? :)
<paroneayea>grungier? :)
<paroneayea>"not metal enough"
<paroneayea>;)
<davexunit>LPC art has a very... "western" style, I would say. I like the japanese style.
<paroneayea>aha
<paroneayea>davexunit: one of the LPC assets came with much more "anime" characters
<paroneayea>er, games
<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.
<davexunit>yeah, LPC is very nice in that regard.
<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>yes
<davexunit>agreed
<davexunit>maybe it's partly that LPC is very high resolution, and I lean towards more pixely. :)
<paroneayea>I think that might also be it
<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>it also has no restrictions on pallete
<davexunit>yeah
<paroneayea>again, an artist team decision... "it's 201X, not 199X... why be constrained by colors"
<paroneayea>and fair enough
<davexunit>I'm curious how it would have worked out with a fixed pallete.
<davexunit>I *really* like the dawnbringer 32 palette
<paroneayea>dawnbringer is great
<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
<paroneayea>it hasn't happened though
<davexunit>I have an opengameart collection of db32 stuff
<davexunit>or maybe it was db16...
<davexunit>there's a good amount of 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>and it kind of fizzled out
<davexunit>I can only imagine...
<davexunit>paroneayea: http://opengameart.org/content/dawnbringer-32-color-palette
<paroneayea>maybe LPC 2 will happen some day
<paroneayea>I won't run it though :)
<davexunit>paroneayea: also http://opengameart.org/content/dawnbringer-16-color-palette
<paroneayea>yeah really nice :)
<davexunit> http://opengameart.org/content/dawnlike-16x16-universal-rogue-like-tileset-v181
<paroneayea> http://opengameart.org/content/dawnlike-16x16-universal-rogue-like-tileset-v181
<paroneayea>that one
<paroneayea>haha
<paroneayea>yup
<davexunit>ha!
<davexunit>I'd love to use this :)
<paroneayea>that's the one I really wanted to make a game with, but never got around to
<davexunit>along with: http://opengameart.org/content/recolor-all-the-items
<davexunit>bam! rpg
<paroneayea>that would be a very different game though
<paroneayea>would be very tile based probably
<davexunit>depends on what you're vision is, I suppose.
<davexunit>I need to learn more about what you have in mind :)
<paroneayea>I guess they could move around freely
<davexunit>gotta go afk now
<paroneayea>I mean, different than a zeldalike :)
<paroneayea>yeah later davexunit
<davexunit>I'll read the backlog if you have more to say
<paroneayea>nah I should get more stuff done
<davexunit>might be back on on my phone on the commute home
<davexunit>k later!
<paroneayea>davexunit: let's check in soon though :)
<paroneayea>wow that recolor looks great
<paroneayea>nice job on the DCSS redo
<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
<paroneayea>I'm not sure
<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
<davexunit>room for the*
<paroneayea>davexunit: I'm not positive this is a problem, it's something I've worried about before
<paroneayea>you're right, we need code to show it.
<davexunit>yeah we'll see
<paroneayea>davexunit: unrelated, I remember you were thinking about getting into chiptunes composition
<paroneayea>davexunit: https://www.youtube.com/playlist?list=PLgQLAgklMBxEuPzQUNKc2xSJu5pXx7xVx great tutorials :)
<paroneayea>for milkytracker, which we have in guix
<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>I have no idea why
<paroneayea>so I left it at milkytracker bindings and just kept the manual nearby for the rest
<davexunit>ah okay. I'll look out for that.
<paroneayea>lots of fun though. let me know if you make something cool :)
<davexunit>will do. need to remember my music theory
<davexunit>I'm just a lowly drummer
<paroneayea>davexunit: one thing he emphasizes in the videos is that you don't need to know music theory, but it helps :)
<paroneayea>so plunge ahead!
<davexunit>:)
<janneke>okay, cond => must never re-evaluate its clause
<janneke>make sense when you see it
<janneke>now my fluids seem to be overly simplistic...