<lilyp>trevdev: try peeking into the load-paths, I'm pretty sure they're different for systemd-activated services <lilyp>you can set the environment variables via systemd or try using a wrapper script in the style guix typically has <trevdev>The only reason this script could work in my shell and not in the d is likely because of something like that lilyp: I will keep trying to sort it out until I lose my patience for it. I currently have an EnvironmentFile setting that is setting my XDG path because that was the first broken thing I could actually read in plain language ***Lemniscate is now known as Sauvin
<vldn>i saw that msys2 has guile3.0.8 in it's repos <sneek>Welcome back vldn, you have 2 messages! <sneek>vldn, mwette says: start with (mdoule-uses (resolve-module <sneek>vldn, mwette says: maybe start with (module-uses (resolve-module '(your module path))) <vldn>is it possible to crosscompile an opengl app from linux to (native) windows? <vldn>sorry to clarify i meant a guile app with opengl bindings <antipode>-- here are some cross-compilable bindings in Guile (e.g. guile-fibers-1.1 has a binding to epoll) <vldn>i never crosscompiled to windows before, can the crosscompiled app use the gpu and all drivers correctly within the msys2 environment? i think there could be some posix problems with crosscompiling guile <antipode>Why would POSIX be a problem? IIUC, you are binding to Windows' GL libraries, not Linux', presumably Windows's GL libraries don't use POSIX stuff. <vldn>because guile uses posix stuff? <vldn>and guile needs to run on windows for the app <vldn>without some emulation layer like wsl <antipode>vldn: I thought the question was can the opengl-related stuff be cross-compiled, not can Guile itself be cross-compiled. <antipode>So I'm assuming you can already cross-compile Guile. <antipode>vldn: Given that link, I think you answered your own question. <antipode>(I assume msys2 doesn't include completely broken stuff) <dthompson>ArneBab: about the png color palette thing: I use libpng and it will take some extra work to process files that use color palettes that I haven't done yet. I put that error message in to let people know of the missing feature. <old>dthompson: Why not use stb_image instead? <dthompson>and also have maximum control of how the data is manipulated <old>True you would have to compile a C lib since it's an header file thing <old>I get it. Just wondering cuz I'm using it and it works like a charm :) <dthompson>it also allows for replacing C libraries with scheme later. <dthompson>for example, I'm using libjpeg to load jpegs. but there is a guile jpeg loader out there. *dthompson is writing his own dang REPL implementation <ArneBab>dthompson: it works in the older version, so does that mean that the colors aren’t correct in the old version or that the new version isn’t able to work with it yet? <dthompson>ArneBab: older versions used SDL2_image to load images. <dthompson>I have abandoned that approach in favor of using libpng, libjpeg, etc. directly. <dthompson>it's a move in a positive direction (more scheme, less C) but there are short term disadvantages. <dthompson>I'll raise the priority of loading palleted pngs on my todo list :) <dthompson>the workaround for now is to use GIMP or something to re-export them in full color <old>dthompson: A guile jpeg loader? I get that is nice that to have things in pure Scheme, but why use that if there's on in C that is faster and binding for guile <dthompson>old: C libraries are clunky and prone to vulnerabilities. the FFI is great to have for interoperability, but as a long term strategy I believe strongly in moving away from C. <old>I don't C still has its role here. I don't think everything should be in Scheme all the time like the Rust people think that rewriting everything in Rust is a good thing <old>There's very low level stuff that can't be done in Scheme unfortunatelly <dthompson>a common approach is to treat scheme as glue around a bunch of C libraries. I want to expand the possibilities of what can be done in Scheme. <dthompson>that's true, but more and more things are possible. <old>Well ofc if Guile allows more low level stuff than I would tend to align on your view <dthompson>over the last few years many things that were once not feasible become possible. <old>I've only started using Guile as my main language along with C for about a year so I could not say <old>But looking at guile 2.2, looks like giant steps have been made since <dthompson>most people in the lisp games community rely on C libraries as much as they can. it's practical, but it doesn't expand what their favorite lisp implementation can actually do. <old>To me the first thing would be have memory allocation on desired alignment <old>Like, I would like a bytevector aligned on a cache boundary or page boundary <dthompson>if you're only interested in making a game as fast as possible that's as performant as possible, that's fine. I have different goals. <old>I don't think it's possible now. And this can be crucial for performance processing <ArneBab>old: Guile 3.0 is much faster now, and with the new garbage collector (whippet — search the logs) even more should be possible. wingo is really pushing the boundaries of what Guile can be used for. <old>Okay so for performance you agree to use C. At least for now <dthompson>I use C where I cannot feasibly use Scheme, whether for performance or because the complexity of writing a new implementation is too much to take on. <ArneBab>The advantage of having stuff in Scheme is that I can more easily hack it — adapt it to what my game needs — without requiring more infrastructure (compiler, additional compile step, …). <dthompson>and I keep those C library dependencies scoped down to more fundamental things: libpng, freetype, etc. <old>I tend to agree with that. Scheme is my favorite language even though I'm an old school C wizard :-p <dthompson>okay, back to my repl implementation. (yet another new one) <old>ArneBab: I have come across it there and there yes <dthompson>I should write a blog post demystifying repls in guile because the repl code in guile is... old and crufty and confusing. <old>dthompson: To be honest, I've never get a good workflow with the REPL. I'm using geiser and everything .. <dthompson>with suspendable ports and 'read' in scheme the cooperative repl that mark and I (mostly mark) wrote almost 10 years ago is obsolete. <old>Something is missing I don't know <old>ArneBab: Is c-indent just a proof of concept? <dthompson>I think people here could definitely help sort out any workflow issues you are having, if you ever feel like taking another pass on it. <old>Well I think I've got used to the gist. Go to the buffer, evaluate it and switch back to geiser to do stuff <ArneBab>old: I’m not really sure — it’s not from me. It’s a fun way to show that the fully consistent structures you can get in Scheme are pretty close to C. The productive tool is sc that uses parentheses: https://github.com/sph-mn/sph-sc <old>The biggest problem IMO is that it only evaluate one buffer. So if a macro is changed, I have to evaluate every buffer that use that macro! <dthompson>old: that's because there's nothing in the system that is doing dependency tracking like that. I don't know of any lisp that would do that. <old>The second problem is debugging .. I use `(pk ...)` to see stuff, but for someone who is used to single step in the terminal with GDB, I sometime feel like debugging an embedded system through a serial line lo <ArneBab>old: did you already try ,help debug? <old>ArneBab: Yes. Maybe I should really give it a try. <dthompson>I'll admit that I do not using all of guile's debugging facilities to their fullest ;) <old>In my best dream, I would debug from GDB both Scheme code and any C foreign code in the same interface <ArneBab>(disclosure: I didn’t use the debugger much, yet — ,break <proc> sounds like it would be really useful) <old>Steping through a FFI function would automagically get me into the C function <ArneBab>maybe you could call out to gdb and set a breakpoint when you step to an FFI call? <old>Yes that is what I do actually <antipode>dthompson: I have written some Scheme code I could consider 'clunky' and in some aspects buggy (though no security bugs AFAIK) <old>I have two terminals, one with GDB attached to the process, and my REPL for debugging scheme <old>But the unification of both would be awesome. <antipode>I like using bindings when they are straightforward (e.g. guile-gcrypt), but if it starts doing things with callbacks, loops and complicated destruction of objects it easily becomes difficult (e.g. original bindings to GNUnet) <antipode>(The GTK bindings handle it reasonably well IME) <old>antipode: Well sometime it's the design of the library that is complicated more than the binding <old>Have you tried the bindings for Jami? Full of callbacks :-) <antipode>old: The design wasn't too complicated, but it really doesn't fit with exceptions and fibers-style concurrency. <dthompson>yeah anything capturing a C stack frame is bad news for that stuff <old>antipode: What library you're refering to? <old>Ahhh, I've never used it <old>But I've heard of. I might think it does a little more impure stuff than Gcrypt <old>Maybe that's why thing are a little more messy <antipode>I ended up porting (not binding) the (non-service) parts from C to (Guile) Scheme <civodul>has anyone considered writing write(2) bindings for Guile? <civodul>i would use it for networking code, typically <dthompson>I'm not familiar with it but the ask makes more sense now <antipode>civodul: Not quite what you were looking for, but maybe useful: gnunet-scheme _almost_ has bindings for 'sendmsg' <antipode>It has code for making and decoding ancillary messages, the only thing missing is the actual 'sendmsg' binding IIRC <antipode>(useful for SCM_RIGHTS or things tlike IP_RECVERR) <civodul>antipode: ooh, that can be useful, too! <antipode>When doing IPv4 / IPv6 networking with 'read' and 'write', the networking error messages often seem rather generic to me, so (when writing those bindings) the idea was to ask the kernel for the precise error (with IP_RECVERR) and raise appropriate exceptions in Guile <antipode>Later it turned out I was only doing AF_UNIX things :p <antipode>(Still, SCM_RIGHTS and the credentials thing could turn out to be useful ...) <old>Not sure if that's what you wanted. But it's trivial and it works <civodul>old: ah yes, it looks like it should do the job, thanks! <civodul>what i was getting at is that we should consider adding something like that to libguile <old>mmap(2) would also be useful <old>And seccomp(2) and bpf(2)! <antipode>If there is interest in having sendmsg in Guile, I can relicense it. <pkill9>what could be causing 'Unbound variable: match:prefix' even though match:prefix is part of guile? <pkill9>I must have messed something up somewhere <pkill9>maybe causing it to overwrite it idk <antipode>(There is some weirdness with some regexp stuff being in (guile) while the rest is in (ice-9 regex)) <Zelphir>I've run into a problem with srfi-64 unit testing. I am trying to use (test-error ...) to test, whether some code of mine raises a specific exception. However, I seem to be able to change the error-type argument to whatever I want, and the test still passes, even though the code actually raises another exception type. I made a subtype of `&programming-error` and for testing the testing purposes, I "expected" an `&external-error` instead. Still test <Zelphir>is passing. Is this a known issue? I seem to remember vaguely, that there was something up with the testing in Guile, but I think that was about testing when something is supposed to return false. Not sure. <antipode>Zelphir: IIRC, there was some report on Guile using the old reference implementation of SRFI-64, which was buggy. <antipode>I don't remember if someone started fixing things, though. <Zelphir>OK I will search around a bit. Otherwise I have to check the log file everytime, whether the exception is really what I expected. <old>Zelphir: There's a bug yes <old>I have this in libpatch: <old> 20 (define-syntax-rule (test-patch-error label exp exp* ...) 21 (test-assert label 22 (guard (exn ((patch-exception? <antipode>I sometimes use 'guard' inside test-assert things as well <antipode>To work-around the Guile bug, but also to verify its components were set correctly (when it has components) <old>So you could juste run your own `test-error*` meanwhile it get fixes mainstream <antipode>E.g. a hypothetical 'patch-exception-location'. <antipode>old: Yes, but Guile isn't very actively developed, you might need to contribute a fix yourself if someone hasn't done already. <antipode>(to get things fixed in a timely fashion) <old>antipode: I would like so. Tbh I'm happy about the recent chance of licensing restriction. This was really a pain to just contribute trivial stuff <old>But I think thing could get further. Contributing to Guix for example is a breeze. Guile could be something like that perhaps? <antipode>I suppose, though Guile would need more maintainers and committers for that. <antipode>There was some thread on Guile maintenance a while back ... <old>Yes I've replied in those. Maybe it's time to take that step and change the contributions/issues processes. Allowing more contributions from the community and more releases <old>I sometime feel that Guile is stagnating, but that's my 2cent <old>I know that a lots is happening that we don't see yet <Zelphir>Ah right, I could catch exceptions myself inside the test. I might do that as a workaround. Also thanks for the code link.