IRC channel logs

2022-10-07.log

back to list of logs

<old>dthompson: How do I run the example in Starling? I get problem with generic or PNG palette
<dthompson>old: ahhhh starling is... not ready for public use. I might be able to help, though.
<dthompson>I'm actually getting a new version of it ready for (hopefully) a real public release
<old>Nice
<dthompson>the name is changing. starling is already the name of a game engine.
<dthompson>I just named it starling after one of my cats, since chickadee is named after another one of my cats.
<old>Well then I will wait patiently for the public release :-)
<old>What is the difference with Chickadee?
<dthompson>it's built on top
<old>I mean the engines not the cats
<dthompson>lol
<dthompson>it's kind of a fuzzy thing, but chickadee is a game library, starling (which will be named catbird going forward) is an engine.
<old>top as in GOOPS <top>?
<old>oh nvm
<dthompson>top as in it's a layer on top of chickadee
<old>on top of chickadee
<old>gotcha
<dthompson>yeah
<dthompson>I started chickadee because it's a lot easier to create a library of general purpose game related things than to make an engine
<old>true
<dthompson>engine's really need to have some strong opinions about architecture and stuff
<dthompson>engines*
<dthompson>so starling is the unreleased library I've been building as I've been doing lisp game jams
<dthompson>just trying to figure out what a hobbyist level engine for schemers might be like
<old>And what type of engine will it be? I see that it use a lot of the GOOPS infrastructure
<old>Right. I've been working in my lost time on a game engine in Scheme/C for a data oriented approach
<old>Defining pure systems that are connected together and mutate datum of entities.
<old>I have this crazy idea that one could write a system in Scheme, it would then be transpiled into C and OpenGL. The engine would then dispatch to either the Scheme, C or OpenGL variant depending on how much data there's to process for that system in a frame
<dthompson>what seems to be working for me is a combination of ideas from Emacs with Godot-like node trees
<dthompson>and heavily using OOP for maximum flexibility
<dthompson>I was able to incrementally build my last jam game with very few restarts of the program.
<dthompson>I highly encourage seeing how far you can get writing in Scheme and letting guile (or another scheme) do its compiler thing
<old>I see. You program new thing that are simple evaluated and add to your engine without restarting. A king of reload loop
<dthompson>GOOPS allows methods and classes to be modified live, and that goes a long way.
<old>I think it's good to start yes. But for a heavy video game, one has to offload thing to C or to the GPU. Scheme would simply not be fast enough
<old>Yes that's true. It's a dream for game dev
<dthompson>well all graphics rendering should be done with the gpu
<dthompson>chickadee does that
<old>of course. But collision is also a hard problem and require intense computation.
<dthompson>with guile's jit the performance is suprisingly good, honestly
<dthompson>and it's always possible to use the FFI as an escape hatch if you really need to.
<old>And even for simplest thing like movement with velocity and acceleration, when you want to apply that to 1 million object, C would be order of magnitude faster
<dthompson>that's true, so it depends on what you *need* to do
<old>Yes. I agree that though that for quick dev and none heavy game, pure scheme is 100% possible
<dthompson>I can render many thousands of moving sprites at 60fps with chickadee
<old>I did saw that with the Bee game. Quite impressive.
<old>I though that the sprites movement were maybe offload to the GPU since there's so many of them
<dthompson>total sprite numbers are overall quite low in that game. I have a stress test that does a lot more.
<dthompson>the sprite movement itself is computed on the cpu
<old>I mean it's enough for a human :p
<dthompson>and the vertex data that is sent to the gpu is recomputed every frame
<dthompson>so only the rendering is happening on the gpu, no compute shaders or anything.
<old>Okay
<dthompson>guile used to not be sufficient for this type of stuff, when I first started. guile 2.2's new AOT compiler and 3.0's JIT were game changers.
<old>Offloading would only be worth it if you have million of things to compute. Otherwise the I/O overhead is greater than the gain of computation
<dthompson>and soon enough (I hope) GC overhead is going to go way down
<dthompson>right
<old>It's true performance are quite good for Guile
<old>I had issue with the GC though in one of my main loop
<dthompson>reducing garbage creation is definitely a challenge
<old>In fact it was my own error. I was disabling the GC at the begining and renabling it after with a manual call to `(gc)`. I did not want the GC to trigger in the hot path
<dthompson>you gotta profile and look at disassembled procedures to identify sources of allocation
<old>But calling the GC at every frame is terrible
<dthompson>I don't do any gc tricks. I just avoid allocation as much as possible in the hot code.
<old>Yes but it's king of difficult to determine what's doing allocation
<dthompson>and I can keep the GC runs quite infrequent as a result
<dthompson>yeah, it can be.
<old>At least for me coming from a C background
<dthompson>guile could really improve there
<old>A cool feature that D has is the `@nogc` attribute to function
<old>Ensuring at compile time that the GC will never trigger in the call chain at that point
<old>I don't think it could easily be apply to Guile or any Lisp for that matter, but I think it's a cool feature
<dthompson>hmm, interesting
<old>By the way, do you vector for computing the sprites for example?
<dthompson>I heavily use bytevectors for all sorts of things
<old>Okay that's what I though
<old>List are terrible for heavy processing and vector are fixed in size ..
<dthompson>guile can optimize lots of those operations and use unboxed floating point arithmetic among other things
<old>Right
<old>get me thinking about this Lisp assembly game engine on PS2
<old>They could achieve native performance with Lisp
<dthompson>GOAL by naughty dog? yeah they compiled a special lisp language to native code
<old>Yes exactly
<old>I wish they could open that code
<dthompson>I don't know if they ever had cool live development stuff in their dev tools
<dthompson>yeah it would be cool
<old>I don't see why they could not. How would they debug?
<dthompson>it would be cool to hear more about what it was like to develop with it
<dthompson>there's some information out there but not a ton
<old>right. From the wiki page it seems that it was a social problem rather than a technical one
<old>that they abandoned it
<old>I'm not supprised. Anything with parethenses seems to turn-off the majority
<dthompson>probably didn't help that artists and non-programmers needed to use it as well
<dthompson>at least on ps3 era naughty dog games
<old>right that's another aspect, tooling around the video game industry
<old>Nothing prevent however to build this high levle tools with a GUI with scheme
<dthompson>this is why it's important to never succeed that much
<dthompson>stay in obscurity and you can do whatever you want :)
<old>right. Poor naughty dogs
<civodul>jpoiret: i see your copyright assignment is now on file, thanks!
<ArneBab>sneek: later tell dthompson: did I already tell you that my daughter and me started to build a small platformer on top of chickadee?
<sneek>Okay.
<ArneBab>sneek: later tell dthompson: the experience has been pretty good so far, despite me having little time.
<sneek>Okay.
<ArneBab>old: you can use wisp to write chickadee-code with far fewer parens :-)
<ArneBab>old: here’s a fragment from the game that shows how Chickadee looks in wisp: https://paste.debian.net/1256274/
***maximed is now known as antipode
***maximed is now known as antipode
<rekado_>ArneBab: can you recommend a mental tool to derive when to use “:” without knowing that this corresponds to parentheses in Scheme?
<ArneBab>rekado_: I use two: : calls a function, and : adds an indentation level.
<ArneBab>rekado_: : starts an inline line.
<ArneBab>That gives the beautiful symmetry of
<ArneBab>define : fun arg ;; fun arg is the inline line
<ArneBab> ...
<ArneBab>fun arg ;; call on a line
<ArneBab>define val : fun arg ;; call with an inline line
<ArneBab>rekado_: I think the easiest way to get there is starting from the empty line with only the : — that’s an empty indentation level. The inline line is just the optimization which pulls the next line into the previous one:
<ArneBab>let
<ArneBab> : ;; empty indentation level
<ArneBab> foo 'bar
<ArneBab>
<ArneBab>let
<ArneBab> : foo 'bar ;; next line contracted into the empty indentation
<ArneBab>
<ArneBab>let : : foo 'bar ;; use : to add another indentation level following the same principle
<jpoiret>civodul: great! I've not been available these past days since I was moving to Belgium for an internship. I've just arrived and I'll try to have a look at my mails this week-end
<civodul>yay!
<civodul>comrades, the GnuTLS bindings will start a new life: https://lists.gnupg.org/pipermail/gnutls-help/2022-October/004772.html
<civodul>grownups, those bindings
<wingo>hehe
<civodul>it started 15y ago! https://lists.gnupg.org/pipermail/gnutls-devel/2007-May/001495.html
<old>ArneBab: Oh I like the parentheses! I don't even see them anymore! I was just quoting the false argument that everyone seem to be throwing at me when I talk about any Lisp
<old>at least that is how it is my entourage
<old>The wisp code looks clean for scripting wow! I've used it for my workflow with GWL, but it seems that it also applies well to game scripting
<ArneBab>old: thank you :-)
<ArneBab>I’m glad to hear that it also looks clean to you — it should make it easier to sidestep the parentheses argument, because structurally wisp is just Scheme.
<old>I would still prefer to use good old regular s-exp, but I think it's a good idea to incorportate user scripting with wisp in a game engine
<old>It almost looks like some Python but declarative
<dsmith-work>Happy Friday, Guilers!!
<ArneBab>old: /me is happy :-)
<ArneBab>old: keep in mind that this is really just Scheme — you can always embed arbitrary scheme in wisp, and on module level they are fully interoperable (you can import wisp modules in regular sexp scheme).
<ArneBab>And if people decide that they actually prefer Scheme, they can just process their wisp through wisp2lisp to get regular scheme.
<old>Is there a lisp2wisp?
<old>I sometime have difficulty with the syntax that and the wisp-mode in Emacs itself. It would be nice to write in Lisp and convert to Wisp so other can more easily read it
<old>That's my main usage btw with GWL. I want other scientifics to be able to read the workflow without knowing Lisp
<old>I did not know that you could insert s-exp in Wisp? Sounds nice
<ArneBab>old: there’s no lisp2wisp because that’s a somewhat harder optimization problem than just adding parentheses for indentation (and I did not get to write that). But sweeten from project readable should already get you 90% of the way for small scripts. https://sourceforge.net/p/readable/code/ci/develop/tree/src/sweeten.sscm — I’d love to have something like that for wisp, — if you’d find a way to port it I’d be more than happy
<ArneBab>to merge it!
<Not_Leader>does .net have a build system?
<Not_Leader>wait sorry wrong channel
<chris>get the rope!
<ArneBab>When I open a port in a let, does it get closed on leaving let?
<ArneBab>(let ((port (open-input-file "foo"))) (read port)) ;; is port closed now?
<jpoiret>ports should get closed on gc
<lampilelo>ArneBab: waiting for the gc to do it could potentially make you run out of file descriptors
<ArneBab>yes …
<ArneBab>thank you!
<edoput>hi all. I'm trying to make some ffi bindings using make-foreign-object-type and I am not sure what I'm doing wrong. I'm getting back a pointer to a struct for which I don't know the layout so I though "I'll just shove it as a pointer value in a foreign class slot but make is not happy about it. I have an example of what I am trying to do here https://pastebin.com/V36FHikn if anybody can take a look
<ArneBab>I guess we cannot be more clever here, because what leaves the scope could be a continuation with which we could re-enter it.
<edoput>make reports "Invalid initargs: (#<pointer 0x....>)" but nothing further
<edoput>I would also appreciate an alternative approach if it requires little to no C. My main pain point is that I'm holding on to <pointer>s everywhere but I can't really tell them apart if they refer to different structs in the C library
<ArneBab>edoput: I can’t help with that right now, but once people return you should get an answer (if not, please ask again!)
<rekado_>edoput: the nyacc package contains an ffi helper, which is pretty convenient
<rekado_>see https://www.nongnu.org/nyacc/ffi-help.html
<ArneBab>Do you know what is missing so we can do (define foo (define bar 'bar) bar) ? Can that be made possible at all?
<ArneBab>It would feel good to have that equivalent to (define foo (let ((bar 'bar)) bar))
<lampilelo>edoput: i don't really know what's up with make-foreign-object-type, but you could use wrapped pointers instead (i.e. define-wrapped-pointer-type)
<lampilelo>edoput: also you have to use a keyword to specify the slot when you're making a goops object: (make <c> #:context (lib-make-context))
<dthompson>edoput: I agree with lampilelo that wrapping pointers in distinct types (whether via define-wrapped-pointer-type or otherwise) is generally the way to go.
<sneek>Welcome back dthompson, you have 2 messages!
<sneek>dthompson, ArneBab says: did I already tell you that my daughter and me started to build a small platformer on top of chickadee?
<sneek>dthompson, ArneBab says: the experience has been pretty good so far, despite me having little time.
<dthompson>ArneBab: oh cool! news to me! let me know how it goes. so few people use chickadee that I get little feedback as to what the biggest blockers are for people that aren't me.
<old>edoput: What about just using plain srfi-9 record to wrap your pointer?
<dthompson>define-wrapped-pointer-type is great if your needs are simple.
<dthompson>sometimes I make a custom srfi-9 record type if I need to attach additional information to the pointer.
<edoput>ok everybody. thanks a lot for all the input. I'll take a look at the wrapped pointer type :) it looks like the right way to do this. I'll also take a look at the nyacc ffi but I really need just two functions now so seems an overkill
<dthompson>I agree re: nyacc being overkill
<old>dthompson: Yes that's the gist, just put it in a record that you will be able to augment in the future
<old>I also have custom guardian for every record that has a foreign pointer
<edoput>old: that's good thinking. I can definitely do something with records instead of foreign structs
<edoput>another question that came up is the difference between set! and set!/unboxed for foreign structs. using set! with a <pointer> value would not work and set!/unboxed would
<old>It's very flexible. For example I have a `<texture>` record. The texture has two members, `name` and `ptr`. When I first create the texture, I set the pointer to `%null-pointer` and I defer the loading of the texture to a I/O thread
<old>this thread will then call `struct-set!` on the record to change the null pointer to the foreign pointer
<old>I also register the record to a guardian that free the texture if it is not null
<old>I think that set/unboxed deference the pointer?
<old>I'm not sure
<ArneBab>dthompson: the biggest blocker was finding out how to get the interactive shell working (is there a way to get one with readline and all the bells and whistles?), understanding that I cannot redefine the functions refernced in run-game, and that I have to mark the module as not declarative.
<ArneBab>dthompson: the game has 331 lines now and it already features a dragon jumping up on two platforms and reaching a chest :-)
<ArneBab>dthompson: currently I connect with telnet to the coop-repl-server
<ArneBab>and the experience has been pretty good so far.
<ArneBab>It did take me a while to actually understand how to work with sprite, atlas and batch.
<ArneBab>Currently it’s all custom low-level logic — down to giving sprite-offsets in the atlas as numbers.
<edoput>it works! thanks everybody :)
<ArneBab>\o/
<dthompson>ArneBab: thanks for the notes. guessing you don't use emacs?
<ArneBab>I do use Emacs, but Geiser wants parentheses and I use wisp :-)
<dthompson>ah right
<dthompson>I don't use non-declarative modules, but that is an easy way to get redefinable functions. nothing chickadee can do about that. it's a guile thing.
<dthompson>I could put a note in the manual about it to try to address the situation, though
<ArneBab>You can look at my example — this just needs one line in the module definition.
<ArneBab>dthompson: https://paste.debian.net/1256274/
<dthompson>yeah I think that's the simplest way to go
<ArneBab>what I also needed to find out: use ,m module definition
<ArneBab>(to enter the right module)
<ArneBab>and "if the game pauses because of an error, you’re in the debugger. Run (exit) to get it running again"
<ArneBab>"REPL is active. Connect with telnet localhost 37146
<ArneBab>then enter the drachi module with ,m drachi drachi"
<ArneBab>It would be great to have that in Emacs — I think cwebber wrote tooling for that.
<edoput>there is no way that foreign-library-function then takes a wrapped pointer predicate right?
<dthompson>ArneBab: error handling is slightly tricky since there's a REPL server and an event loop that need to coordinate. run-game has an #:error argument that can run whatever you want when an error happens.
<dthompson>by default the game will crash if an exception is raised outside of the repl
<old>edoput: Foreign function are simply pointer with types information. Guile convert all scheme value into C value then passe it to the real function
<old>This is all done by libffi I think
<dthompson>ArneBab: if you pass an error handler, you could instead set a flag, poll the repl server in a loop until the flag is unset, at which point the game will resume.
<old>It's possible to pass Scheme procedure such as predicate with `procedure->pointer`. However, I'm not sure what you're trying to accomplish here
<cwebber>hi
<old>edoput: The important is to respect the API of the library and its ABI
<dthompson>hi cwebber
<cwebber>oh yeah I wrote some hacky hack-on-wisp code
<cwebber>it's not very good, but it does work!
<edoput>old: just wondering if instead of using * in the #:arg-types of foreign-library-function now I can use an identifier declared by define-wrapped-pointer-type
<old>edoput: I don't think so
<dthompson>ArneBab: here's a somewhat advanced error handler that captures the stack so you can open a debugger for it within the repl server. https://git.dthompson.us/starling.git/tree/starling/repl-server.scm#n45
<old>'* really just mean a void pointer
<edoput>sad edoput
<old>edoput: You need to unwrap the wrapped pointer
<old>Wrapped pointer are sugar syntax around srfi-9 record
<old>So you can simply do: `(unwrap my-pointer)`
<edoput>yeah that works but I was thinking to have some checks for when I will do some stupid work
<old>`(define-wrapped-pointer-type <my-pointer> my-pointer? wrap-my-pointer unwrap-my-pointer print-my-pointer`
<old>How about not calling the foreign function directy but a wrapper of it?
<old>There you can do any check in scheme then you call the foreign function with the correct arguments
<edoput>I'm currently doing that where I unwrap things. I guess I'm just a macro aways from what I want
<edoput>anyway thanks for the support and good ideas
<ArneBab>dthompson: I didn’t know about the error-handler — thank you!
<ArneBab>I think a section "practical chickadee usage" would be pretty useful
<dthompson>ArneBab: yeah I agree. I'd like to expand the live coding section to include a pattern for handling errors that happen outside the repl.
<ArneBab>also notes how to integrate "I change my code" and "I apply that to the running program" would be great
<dthompson>chickadee still uses guile's clunky old exception system and I need to switch it to the new one. I'll feel better documenting it then.
<dthompson>yeah, I might give a shout out to GOOPS for making a lot of that type of stuff "just work"
<dthompson>but also mention non-declarative modules
<dthompson>I'm finally trying to learn guile's new exception system and having some difficulties porting code over to it.
***maximed is now known as antipode
<dthompson>if I'm reading the docs correctly, it's not really possible to have the equivalent of a pre-unwind handler when using with-exception-handler
<dthompson>I don't have control over whether an exception is continuable or not, which means that I cannot capture a stack object to use for debugging purposes if the raised exception is non-continuable
<ArneBab>dthompson: I don’t know that system well enough to really help there … but your plans sounds good!
<dthompson>:)
<ArneBab>One thing I’ll have to get solved is how to ship a chickadee game — I might have to learn how to create full-featured tarballs from guix and then just ship these.
<dthompson>ArneBab: it's an ongoing challenge, but chickadee provides the start of something in the latest version.
<dthompson>I have not found a satisfying way to use guix to produce something I'm happy to ship
<ArneBab>And it would be cool to have a way to deploy to Android (because my kids are asking for that :-) ), but that might be really hard to solve with GUile
<dthompson>hmm I don't anything about android
<dthompson>don't know*
<dthompson>has anyone even built guile on it?
<ArneBab>I’ve nowadays seen* quite a few games that look like a tarball from Guix with a binary to execute *: seen = actually bought
<ArneBab>I don’t know — that’s the next frontier
<ArneBab>First step: Get the game playable on any Linux distro so that 80% of my colleagues at work can play it on their work machines ;-)
<dthompson>sdl2 works on android so if guile runs chickadee should be able to work
<ArneBab>nice!
<old>I've seen some github repo with Guile for Android IIRC
<dthompson>a binary bundle with guix would be too large
<old>I'm also looking for that. I want to write connectivity scenario for Jami on Android
<ArneBab>there is Lilypond on Android: https://findlab.github.io/2020/10/23/lilypond-android/
<dthompson>ArneBab: here's the docs on 'chickadee bundle' https://dthompson.us/manuals/chickadee/Invoking-chickadee-bundle.html#Invoking-chickadee-bundle
<dthompson>it's definitely not "turn key" but it produced the bundler for my last game jam entry
<dthompson>it's not pleasant but building the game bundle in an ubuntu 16.04 VM is what produced the best result for me. nearly everyone that that tried it was able to run it.
<ArneBab>The lilypond people keep spearheading the hard work that Guile really needs to get widespread adoption. We "just" need to find ways to get these easy to use for ever Guile user.
<dthompson>did lilypond ever make it to modern guile? haven't paid attention to that story in years
<old>I think there's still on 2.2
<dthompson>well that's way better than being stuck of 1.8
<dthompson>stuck on*
<old>s|there's|they are|
<old>Way better than being stuck on Python2.7
<dthompson>oops, I said I used ubuntu 16.04 earlier, I meant 18.04.
<dthompson>basically I use the oldest LTS ubuntu that is still being supported. it has a libc old enough that the binaries that get shipped in the bundler are very likely to work anywhere
<ArneBab>old: they are still stuck on 2.2, because there are some patches that didn’t get merged yet. I’ll try to change that on the Guile side over the next few months.
<dthompson>I wish we could get guile working natively on windows. without cygwin or mingw.
<ArneBab>dthompson: I don’t really worry about the size right now. As long as it’s not Gigabytes in size my webserver can handle the load and people just won’t notice :-)
<ArneBab>yes, it would be nice to be able to create tools that my non-linux-using friends can use
<dthompson>ArneBab: I couldn't get a bundle that wasn't hundreds of megabytes.
<old>Have you tried with `guix pack`?
<dthompson>yes
<old>too huge?
<dthompson>it essentially contains an entire OS sans kernel
<dthompson>the full dependency tree.
<dthompson>very reliable. very huge.
<old>indeed
<old>Maybe it would be an idea to add an option for prunning uncessary thing
<dthompson>my previous game's bundled release was only 16 megabytes
<lampilelo>fun fact: arch linux recently removed python2 from its repositories
<old>dthompson: How much of that is noise? Like license file and documentation translated into 60 languages?
<old>Compared against your data asset e.g.
<drakonis>lampilelo: python 2 has been been declared eol for 2 years now
<dthompson>a lot of the guix pack would be noise
<dthompson>but it's very general purpose
<dthompson>that's the tradeoff
<ArneBab>Guix pack sounds like flatpak?
<dthompson>not exactly but kinda
<dthompson>I wrote something specifically for my niche and it does neat things to reduce the bundle size like removing all guile modules that are not used at runtime.
<ArneBab>that sounds cool
<dthompson>guile comes with a bunch of stuff and I was able to save lots of disk space by deleting everything that was unused.
<old>Nice
<drakonis>ArneBab: i think i'd describe flatpak as more of a distribution model and isolation
<dthompson>the bundle ends up being pretty minimal: guile executable + shared libs (libguile, sdl2, etc.) + guile modules + game data files
<drakonis>distribution and isolation model that is
<old>ArneBab: guix pack can generate .tar.gz, docker image, squashfs and .deb
<drakonis>its not exactly meant for relocating binaries
<ArneBab>old: do you know whether I can guix pack from a guix.scm file that describes the package?
<drakonis>ArneBab: i'd be surprised if you couldnt
<lampilelo>drakonis: another fun fact: arch linux is still stuck on guile 2.2.7
<drakonis>yes i've heard that one
<old>Guix pack will package everything that's in a profile
<drakonis>but that's because make has a dependency on it
<dthompson>one day, hopefully, this tree shaking approach will be obsolete because guile will compile directly to native code and I won't have to ship modules at all.
<old>I've used to to bundle students assignment and run it on a HPC computer
<drakonis>and anyone who'd bother fixing that is probably using guix now
<drakonis>ah, guile with compiling...
<drakonis>that'd be nice.
<old>ArneBab: You have a nice interface in `(guix scripts pack)` I think for that
<dthompson>then it will just be the executable + shared libs used via ffi + game data
<ArneBab>drakonis: I just searched, but there is no --load option for guix pack.
<dthompson>I got reeeaaaally close to using guix to produce these bundles once.
<drakonis>its not something you can do on the cli though
<dthompson>didn't quite work out. ran into some tricky gcc stuff I couldn't figure out.
<dthompson>but it's theoretically possible to use guix as a way to build relocatable binaries.
<drakonis>ArneBab: use a manifest
<old>dthompson: What do you mean? Guix pack can already relocate all binaries?
<ArneBab>I need something I can put in the README …
<old>It even do so for scripts
<ArneBab>(otherwise I forget how to do it)
<drakonis>alternatively use -e
<drakonis>for --expression
<drakonis>you can also use -f
<drakonis> https://guix.gnu.org/en/manual/devel/en/guix.html#Additional-Build-Options
<drakonis>wrong one
<drakonis>oops.
<old>`guix pack --load-path`
<ArneBab>let’s get away from the theory: I have this file https://paste.debian.net/1256329/ (guix.scm) and I want to get this packaged
<dthompson>old: it can't really. it has to use tricks to do it.
<old>dthompson: Yes namespace or other ad-hoc stuff
<dthompson>what I mean is I could get guix to produce binaries that did not contain references to /gnu/store'
<dthompson>I made special packages that used a special gcc toolchain to do it.
<old>Ideally, it would be nice to be able to statically link everything in a bundle
<ArneBab>when I say guix shell -f guix.scm I get: guix shell: Error: regular file expected
<old>ahh okay
<drakonis>ArneBab: use -m
<ArneBab>what do I pass the -m?
<old>A file that has a manifest
<ArneBab>can I specify the local sourcetree with that?
<drakonis>i'm having a brain fart right now
<old>`-f FILE` is for taking the last expression evaluated in FILE
<dthompson>I wonder if a future guile that did native compilation could statically link in C libraries that are used via the ffi? I have no idea what the reality of that situation looks like
<ArneBab>(sorry for sounding so dumb, I just don’t see where it fails and I thought it shoud …)
<drakonis>-f in guix pack is for format
<ArneBab>dthompson: in theory Guix should be able to provide these and then adjust the paths in the pack to just work
<old>ArneBab: Your paste sounds good. You should be able to do `guix shell -f draki.scm`
<old>Are we talking pack or shell ?
<ArneBab>My goal is to create a pack, I’m searching for the steps to take to get there
<old>dthompson: I'm not sure, but sound like what Gambit does
<drakonis>ArneBab: create a manifest and bring your package into scope
<dthompson>gambit seems to be the go-to for people that make games with scheme (the few that do)
<old>`guix pack -L . draki`
<drakonis>although i think that might not actually work like that
<old>dthompson: Yes. It run on NintendoDS!
<dthompson>ArneBab: it would be very difficult for guix to do that. so much goes into hardcording /gnu/store paths.
<old>s/draki/drachi
<drakonis>i'll step out of this conversation
<dthompson>ArneBab: it's a lot easier to build a separate tree of packages of the libraries/programs you need to be redistributable.
<ArneBab>can I get better error output?
<old>ArneBab: If you use `-L .` it will put the current directory in the load path of Guix. Your file however has to be a module.
<old>So really you want something like:
<ArneBab>dthompson: Guix creates a tree from /gnu and then changes all path and library entries to point there.
<old>(define-modules (drachi) ...) (define-public drachi (package ...))
<old>that in `drachi.scm`. The you can do `guix pack -L . drachi`
<dthompson>ArneBab: yes, very painstakingly. there's no easy way to take what it produces and then make something that will work anywhere.
<ArneBab>it should make it work everywhere because it ships all
<old>If you use the `-RR` switch
<old>yes
<dthompson>the trouble is that it either has to be extracted to /gnu/store *or* you have to use tricks like namespaces
<dthompson>it works for some use-cases. it doesn't work well for games.
<dthompson>there's also the massive bundle problem
<ArneBab>did you see this? https://guix.gnu.org/blog/2018/tarballs-the-ultimate-container-image-format/
<dthompson>yes
<ArneBab>it’s huge, but it would be an option.
<ArneBab>if it works
<old>I mean it's huge, but everyone in the world can run your software
<ArneBab>The bigger the game, the lower the pain :-)
<old>How many tools can be proud of that? None
<dthompson>there could still be issues
<old>Docker, snapack are no better
<dthompson>for example I've had guix built software fail because the version of mesa it was linked against naturally only works for gpus with free drivers but the target system required proprietary ones.
<old>Ah yes that's is true
<old>I have the same problem. Mesa was too old on Guix for my HPC node
<old>Had to fallback to rocm
<old>But that you can't know at compile time
<dthompson>by producing a more minimal bundle that assumes the target system has mesa on it (which any system with a desktop does) you actually get better compatibility
<dthompson>again it's a very specialized use-case. guix pack is a great general-purpose tool, I've just weighed the pros and cons and decided it's not a good fit.
<old>Okay so you want to be able to have a bundle that will use libray from the system
<dthompson>among other things
<ArneBab>for serious bundling of games you have to get this working out of the box — any game that doesn’t run right away is a disgruntled player.
<ArneBab>dthompson: I should really try your bundling
<old>Ofc, but dthompson has a point. Drivers for GPU for example are not compatible from version to version
<old>I guess that's one advantage to do thing on Windows
<old>You don't care about that kind of stuff
<old>There's an alternative though. You can select the implementation at runtime. If mesa does not work, fallback to something else.
<old>I do that in my game engine. Graphical procedures are mutated to an implementation selected by the user while launching the program
<old>Same for Audio. If you don't have pulse audio but you have alsa you do `./game -snd alsa`
<dthompson>bundling is a terrible practice and not one I'd recommend for anything serious. but for something as disposable as a game where you'll be lucky if someone spends even 5 minutes playing *if* it runs on the first try? eh it's fine
<dthompson>here's my special-purpose bundler: https://git.dthompson.us/chickadee.git/tree/chickadee/cli/bundle.scm
<dthompson>it's not a ton of code
<ArneBab>dthompson: well, almost every game you get is bundled.
<ArneBab>and chickadee games can be installed once distros want to ship them, so I don’t see a big issue.
<dthompson>right
<ArneBab>dthompson: and once more I want to say: you are doing awesome work! Thank you for enabling me to create this game with Guile!
<dthompson>yw I hope you have fun and don't run into too many bugs ;)
<ArneBab>If need be I can fix some bugs myself :-) — but I have not yet hit any showstopper.
<dthompson>ArneBab: I should mention that maybe the 'chickadee play' command is something you should try using. it's for quick prototyping and it provides repl server integration https://dthompson.us/manuals/chickadee/Invoking-chickadee-play.html#Invoking-chickadee-play
<ArneBab>Does it support games written in wisp? (switching the language and the extensions to search for?)
<antipode>guile,guix: I've sent a patch that adds support for SRFI-64 test suites to guile-build-system: https://issues.guix.gnu.org/58337
<dthompson>ArneBab: maybe you could help me make that work :)
<dthompson>because that would be cool
<ArneBab>what’s the best way to hack on chickadee itself?
<ArneBab>(I write the game with wisp and launch it directly via run-game)
<dthompson>that's a good way to do it. a lot of stuff in chickadee is not very easy to live hack because it needs to get inlined and optimized to hell so it performs well.
<dthompson>if the thing I'm working on doesn't involve graphics or input, I develop it at the REPL like usual. then I write something interactive as an integration test.
<ArneBab>can we start a bit earlier? Which repo do I get and how do I install it in Guix? :-)
<dthompson>ArneBab: git clone https://git.dthompson.us/chickadee.git
<dthompson>run 'guix shell' to get your dev environment.
<dthompson>then ./bootstrap, ./configure, make
<dthompson>to test that it works, run: ./run-example sprite
<dthompson>if a window pops up with a pixel art bird sprite, it works.
<ArneBab>cloning in progress :-)
<ArneBab>an dI see a bird on a blue background!
<dthompson>ArneBab: yay!
<dthompson>there's other fun examples you can try, too
<ArneBab>particles fails with chickadee/image/png.scm:354:31: ERROR:
<ArneBab> 1. &message: "PNG images using color palettes are not supported"
<dthompson>yeah I need to fix that
<dthompson>regression due to switching image loading libraries
<dthompson>tile-map is a good one
<dthompson>or sprite-batch
<ArneBab>60FPS at 5000 sprites with sprite-batch
<ArneBab>tile map scrolls! nice!
<dthompson>'model' renders a simple 3d model. you can move with arrow keys but no mouse look control yet.
<ArneBab>do you wan ta wisp example?
<dthompson>I guess I could include a version of the sprite example expressed in wisp?
<ArneBab>working :-)
<ArneBab>and while I’m at it … let’s try ecmascript
<dthompson>whaaaat will that even work?
<ArneBab>it just might, let’s try :-
<ArneBab>:-)
<singpolyma>What are we doing with ecmascript?
<ArneBab>evil evil funny things :-)
<ArneBab>ok, it does have a problem: I cannot have - in function names in js
<singpolyma>You can
<singpolyma>There is a trick
<singpolyma>this["some-function"](args)
<ArneBab>that’s evil, evil, evil — I like it ;-)
<singpolyma>If you need more I probably have them for ecmascript :)
<singpolyma>I have a helper to call guix record macros for example
<ArneBab>how can I import (chickadee math vector)? require("chickadee/math/vector") does not work
<singpolyma>var vector = require ("chickadee.math.vector")
<singpolyma>IIRC
<singpolyma>Then vector["r-thing"]
<ArneBab>does it support keyword arguments?
<ArneBab>chickadee["run-game"](load=theLoad, draw=theDraw);
<singpolyma>Oh, you may need a scheme shim for that I'd have to look at my hacks
<dthompson>haha this is madness
<dthompson>i love it
<singpolyma>I do want to make the interop story on guile better and not just a bunch of secret knowledge, but it's promising enough that I think it's doable