IRC channel logs
2025-10-10.log
back to list of logs
<rlb>ACTION owes dsmith a beverage -- that spurious inter-protocol attack test failure that's plagued him should soon be fixed. <euouae>Does gdb have a libguile module for pretty printing SCM values? <euouae>I'm messing around to get a feel for gdb with libguile <rlb>euouae: perhaps try meta/gdb-uninstalled-guile, etc. <rlb>i.e. running that puts you in gdb for the locally built guile. <euouae>e.g. I have an (SCM) 0x404. Printed in bits, 10000000100. scm.h tells me 100 is "non-integer immediate". SCM_IFLAGNUM(key) gives 4; iflagnames array in print.c says #t. <rlb>and yes, there are helpers <euouae>I'm already in the locally built guile with LD_PRELOAD_PATH <euouae>the system libguile on debian is not compiled with symbols <rlb>At the point you've reached, I'd recommend just bootstrapping your own build and working from there. <rlb>Then you can even easily put fprintfs, etc. in the C code if you need to. <rlb>meta/uninstalled-env also lets you run things against the built guile <euouae>okay, it really is #t, I tried `pp` from gdbinit <rlb>and meta/guile runs the built guile, etc. <euouae>yeah its my own guile, I haven't modified it though <rlb>It's much easier to just "make -j5 && meta/guile" :) <euouae>yeah in fact with CFLAGS='-ggdb -g3 -O0' <euouae>thanks! it's a bit of a headache to figure all this out <rlb>Could probably do with better dev docs... <euouae>That's a good point. I'll keep it in the back of my head because my "entry" to this is a good time to keep notes of what I needed <euouae>I just came up with another idea to debug this problem <euouae>I can write it in C. Hopefully it manifests there too. <euouae>but maybe that's a bad idea. sigh <euouae>I guess I really need to understand the VM stuff <dsmith>(Of course I prob forgot something..) <rlb>dsmith: thanks -- I'll plan to look tomorrow, but if you don't hear from me "soon", just badger me. <wehlutyk>has anybody tried using chickadee and guile-fibers together? <wehlutyk>I know this was mentioned as tricky if not impossible by dthompson <wehlutyk>but even the most basic combination fails: <wehlutyk>would it still not be possible to run chickadee inside a single fiber/thread? <apteryx>is there something in guile we can do to guard an execution block from having any background thread (spawned by libguile or libgc)? <euouae>you can't prevent threads from context switching in the kernel normally <euouae>if you have control of the RTS then you can do it <euouae>I'd assume with fibers you can do it by putting the critical section in a sync block <wehlutyk>dthompson: I'm finally giving up about chickadee+fibers (so jumping into goblins instead), but would you have a hint about why? <dthompson>wehlutyk: graphics must be done from the main thread <dthompson>but your fiber can run in any thread by default <euouae>might be worth noting that in the manual <euouae>i.e. specifically the fibers thing <dthompson>I don't recommend using fibers with chickadee currently <euouae>For normal game dev you don't need fibers, you can use regular threads <dthompson>fibers would be nice but we need a way to integrate better with the game loop <euouae>Wouldn't you normally need an input thread, a network thread, and the game loop? <dthompson>at a certain scale, yes, but for most people? no <dthompson>networking implies multiplayer which is far more complicated than what most people want to do <dthompson>maybe? depends on what you're doing. if you don't have a lot of experience making games I would highly recommend sticking to single player. <dthompson>multiplayer gets very complicated very quickly <euouae>Or make the game really simple and explore the other features: Try to make a multiplayer tic-tac-toe, make it graphic with a server. <euouae>By simplifying some aspects you can delve on the other aspects <wehlutyk>I'm (very slowly) attempting a guile version of DynamicLand / Folk.Computer <dthompson>but if you've never made a single player game before I wouldn't even recommend that. you need to get the hang of event loops, managing game state, basic graphics techniques, etc. <dthompson>because someone has been working on dynamicland with hoot <euouae>dthompson: looks like 2025 game jam is soon! I'll sign up for it <euouae>This time I'll actually use Guile instead <euouae>oh man I already have a stupid idea <euouae>it's going to involve wind mechanics <old>I am loading a user configuration file with `load-in-vicinity'. I have a custom reader for that for better error reporting <old>but it seems that my reader is not used by sub-modules of the user configuration with auto-compilation <old>any idea how can this be fixed? <old>I guess what is happening is that with auto-compilation, the module is compiled in the default environment of the language <old>hmm I guess %auto-compilation-options <old>eh I guess, auto-compilation is done in load-primitive-path, which is called from `try-module-autoload' in a fresh user environment where the reader is not set <old>and unfortunatelly, %load-hook is called after auto-compilation and not before .. <old>I have to make a big hack around `make-fresh-user-module` to install my custom reader for auto-compiled modules <apteryx>euouae: my question about restricting execution to a single thread was in the context of trying to use 'unshare' (the Linux system call) safely from Guile. We're having a non-deterministic crash in Guix because of likely some unexpected threads causing unshare to return EINVAL. Lots of tracing and extra context at https://codeberg.org/guix/guix/issues/1169. <apteryx>It'd be nice to have a Guile internal expert take a look to interpret what we see in the backtraces and what the likely source of the running threads. <old>well auto-compilation is simply broken IMO <euouae>old: in what context are you using it? <euouae>old: I don't think it should be a thing I'll be honest. IMHO the default should be to have it turned off <euouae>I don't know the situation in which one benefits from autocompilation <rlb>dsmith: hah, yeah, I thought I'd poked at it, but likely only briefly -- that was probably when I was randomly scanning bugs, which I've done occasionally "recently". <dsmith>rlb, Looks like you had it. Interesting that my initial debugging probe was almost exactly the same as yours.. <rlb>Sure, but you bothered to figure out more or less *why* :) <rlb>Still owe you a beverage. <old>euouae: I am loading a configuration file that can be modularized by the user <old>euouae: There's a big different between evaluation and compiling these file for startup time <old>like a scale factor of 3 <euouae>old: the configuration file should be installed prior to the user loading it <old>that's not the workflow I want for that <old>do you install a makefile before using it? <old>my configuration file is a "blueprint", which is like a makefile, part of a source-tree of projects <euouae>presumbly the work it does is longer? or is it not a makefile? <old>if an IDE just want to laod the blueprint to expose some functionnality <old>or bash autocompletion <euouae>are these examples or what actually happens with your file <old>but yes if it's just for buulding thing, than loading time is armotized I agree <old>euouae: actually happened <old>We have bash autocompletion and emacs IDE integration for these blueprints and the startup time for just loading it is 50 ms <old>almost percitble by humans <rlb>old: I don't recall the details, but I hit some issues with the reader that sound familiar when I was working on lokke -- one issue I do remember is that I'd assumed/hoped that changes like prefix-keywords would be restored at the end of a module. <rlb>I'm wondering if the reader itself was also in that category... <old>euouae: but there are other way to circumvent loading time .. making a daemon for example that auto-reload it on changes is one <old>and IDE can communicate with the daemon to get the necessary informations <old>rlb: right it seems that auto-compilation was kind of made in the optic of getting good performance in most base cases <old>but whenever you enter custom readers land, you'r on your own <rlb>It's been a good while, but I think I was wondering if we might want a way to tie more "things" to extensions, i.e. if the file extension is .clj, then "use this reader", etc. But haven't thought about it enough to know if that really makes sense. <rlb>(also don't recall exactly what we have right now, offhand) <dsmith>Sounds like emacs auto-mode-alist <euouae>is it about writing your own DSL? <rlb>euouae: it's what turns the text representation of a language into the internal datastructure, i.e. for scheme reading "(1 2 3)" returns a list (cons chain) containing the three integers. <rlb>But you could also have a reader that did the same thing for "[1, 2, 3]", which would be reading a different language. <rlb>Also the "R" in REPL. <dsmith>Somewhat related is read-hash-extend, which allows you to add custom #thing readers <rlb>I forget whether that's "global" too atm. <old>rlb: my main problem is around reader limitation right now <old>The reader is just making syntax object with source annocation which is great <old>but when you have a syntax error, psyntax somehow does not provide you with that information <old>for example, a bad lambda form: `lambda' just raise an exception with no meaningful error location <old>So I made a "context" reader, that wrapp the current language reader and remember the last syntax that was read <old>that way I can print a meaningful backtrace <old>and it works very well .. until I started mixing with Wisp. Apparently the wisp language specification does not check the `current-reader' fluid like the scheme language do <old>but hey, if psyntax could just forward the proper syntax violation location I would be more than happy <old>how many time users had: unknown file:1:0: _: bad use of '_' syntactic keyword in subform _ of _ <old>because they forgot to import (ice-9 match), yet they can't know that because the error location is not shown! <dsmith>Yeah, Guile's error reporting a somewhat less than awesome. <dsmith>Especially and dealing with Rust. Error reporting there is so good it almost makes you want to create an error just to experience it. <characteristic>Rust's error reporting definitely does not make you want to try to return a Result from a function that returns an Option using the ‹?› operator… i wonder if they improved that error since the last time i used Rust <euouae>but static type checking is largely why and less macro usage <mra>ocaml has pretty good errors, but iirc hindley-milner type inference somewhat limits the quality of error messages that you can output? <mra>i seem to recall reading somewhere that even if you can completely infer types hindly-milner style, a bidirectional typechecker still gives better errors <euouae>It's one of those things where the more familiar a programmer is with the tpe system the better they can figure out the error <mra>ah, on the "bidirectional typeing is better than hindley-milner even when hindley-milner is possible" thing, i was thinking of a comment in some source code that i saw once <mra>maybe not the most reliable source <sneek>Welcome back mwette, you have 1 message! <sneek>mwette, daviid says: I chaned the definotion to add #:inc-filter (lambda (file path) (string-contains path "fluidsynth/" 0)), which i sort of blindingly takefrom the dbus.h example, and that seems to generate the complete low level api, tx <mwette>daviid`: Good to hear it worked: there has to be a way to indicate which declarations should be processed. #:inc-filter is pretty simple to use <mwette>The comments mention #lang, but the patch also supports file extension IIRC