IRC channel logs
2025-09-11.log
back to list of logs
<old>rlb: re: If/when I merge it, would you mind if I condense the comments a bit? <old>Yes sure. I was more verbose than necessary only on purpose <old>dsmith: you have something in mind? <dsmith>old, Nothing specifically. Just a "hmm, that might cause a hard to find bug" feeling. <dsmith>old, Like maybe some file or socket fails from lack of available file descriptors. <old>one bug that was very painful for me with child process was SIGINT set to SIG_IGN when using system* <old>but you did not have that bug with system, only system* <old>and so, I was unable to cancel a build-process in Guile by pressing C-c because of that <old>I was very surprise when I decided to check the children signal mask <tianshu>When using foreign library, if I have a struct { char x[64], char y[64] }, how to represent it in foreign-library-function call? Can I represent it with something without define a struct on scheme side? <rlb>old: appreciated, it was very easy to follow. <rlb>Still pending for 3.0.11 if anyone has the time/context: https://codeberg.org/guile/guile/pulls/10 Otherwise I'll try to catch civodul again there. Then I'll probably start looking at what's left wrt release.org that I think I can help with -- never been closer... <rlb>Anyone know of any easy way to export/import codeberg/forgejo issues/prs? (I still want to convert my repo, which predates the guile/guile migration, to be a fork, but I had a little history I might like to keep.) <rlb>I already asked them about some built-in option to convert to a fork, but that's not yet a thing. <dsmith>rlb, You already know pr 10 looks good to me. Would be nice if wingo gives his ok <rlb>Yeah, in some sense, that was just a "final" call -- I'm likely to merge it if it still looks good when I get back to it :) And thanks. <rlb>Credit in part due to whichever other test I started with for that :) <rlb>Today I mostly messed with srfi-207, trying to decide if I should merge it, and got side tracked by some relatively (and hopefully) optimizations I noticed --- guessing that people might actually use base64 "in anger" at some point. <rlb>"relatively easy (and hopefully)" <rlb>One of the release.org steps is (maybe) "Update Gnulib" -- perhaps we'll skip it unless there's something notable we need. <rlb>We should also describe the process there. <euouae>now that I've finally resolved the issue with autotools I'm moving on to writing a simple text editor in Guile using guile-ncurses <dsmith>This friday is an important date. All bot output will be piped though a filter. Just for fun. <dsmith>(I wired this up last year but I'm not sure of anyone noticed) <old>sneek: what is guile <sneek>Its been said that Guile is fantastic, sneek <old>dsmith: what filter? <old>sneek: sneek who is dsmith <old>sneek: who is dsmith <old>sneek: who is civodul <old>seems like sneek need a little help <sneek>civodul?, pretty sure was seen in #guix 4 hours and 44 minutes ago, saying: Hello Guix!. <sneek>sshine was in #spritely 23 days ago, saying: also, I want to point out that the conversation was 2.6% chinese :Þ. <sneek>old?, pretty sure was seen in #guile 1 second ago, saying: sneek: seen old. <dsmith>Ah, that "mataphone" matching kicking in <identity>sneek can not see sneek for sneek is a sneeky sneek <old>sneek: later tell sneek hello <old>is that protection from recursion <old>sneek: later ask sneek hello <old>sneek: later tell sneek: later tell sneek <old>I'm trying to read from a pipe with O_NONBLOCK and setvbuf 'none <old>I know that pipe can be empty and would like to have EAGAIN from Guile instead of blocking .. <old>anyway other than using FFI? <civodul>old: you should be getting EGAIN, is that not the case? <old>with strace(1), I can see the EAGAIN followed by a poll(2) <old>(I have not installed suspendable ports here) <old>btw, does anybody know if it's possible to wait on two conditions in fibers <old>I have a little problem here. I have a task scheduler single threaded in fibers. I need to reserve slot for jobs using the POSIX jobserver, thus reading a token from a FIFO. But I also have an explicit jobslot from the process itself as a flag variable <old>So I want to be able to wake a fibers either from reading a token from the named FIFO, or by releasing that internal flag <old>hmf I guess I would like to combine a readable operation with a wait-condition <old>that would be the choice-operation I guess? <dthompson>wrap-operation is also useful if you need to massage the result of one or more operations in the choice <old>dthompson: thanks that work really nicely <old>such power within fibers I like it <dsmith>Is there plans to include fibers into Guile? <dsmith>s/Is there plans/Is there a plan/ <dsmith>s/Is there plans/Are there plans/ <dthompson>I think there's rough consensus that it should be included, yeah <dsmith>ISTR something about lack of non-Linux support holding it back? (Windows?) <dthompson>not having windows support has never stopped anything in guile before ;) <old>hmm but I still need to have a try-fn for reading <old>I can't find a way to "try to read a byte or goe to sleep until readable" <dsmith>dpk over in #scheme is showing pics of the codeberg servers <dpk>we’re finished and i’m on the way home again now :D <ieure>dsmith, Are they on fire or... <dsmith>Nah. Since Guile is now hosted there I thought there might be some interest. <dpk>ieure: we were installing new hard drives with more terabytes for Codeberg users :-) <resica>dthompson, hi, I know you maintain the chickadee project. Are there any plans to move up to SDL3? <dthompson>I just have very little time to spend on non-work projects these days so progress is quite slow <resica>I don't think SDL2 will be purged from fedora or arch anytime soon. <dthompson>the upgrade path for chickadee is a little tricky. it will need to support both sdl2 and sdl3 for awhile <dthompson>I've started some work on an abstraction layer but it's not done <dthompson>but the basic plan is to get things working with either sdl2 or sdl3 with opengl rendering as a first step. then break the graphics api completely and provide something that is compatible with sdl3 gpu. <resica>In theory, how much faster would guile be compared to say python? Even if they're using the same library. <dthompson>I don't know how to say without completely making up numbers <resica>To put forward a logical extreme, I wouldn't be making call of duty black ops for example. <rlb>My vague impression is that guile faster in general, but cpython can be quite fast *if* you hit the right C bits, e.g. I think some dict operations are fairly fast. <dthompson>python is slow* but the asterisk is that lots of performance sensitive stuff is shunted to C extensions and then there's probably JIT stuff to consider <dthompson>I feel comfortable saying that scheme is more amenable to performant compilation, generally speaking <dthompson>but guile is a little project and python is an industry giant <rlb>Fairly sure about that too. <resica>Not to mention, I've heard that the guile/scheme REPL is wonderful for on the fly development. <dthompson>whatever game you have in mind will probably be fine on guile. probably would be fine on python, too. <rlb>And python has some serious issues in places. For example, until recently, and may still be the case, you can get a big performance boost in tight loops by just assigning globals (vars, functions, etc.) to temporary locals and using them there. <rlb>Because global lookups are slow, and I think maybe can't be optimized because of the promised semantics. <dthompson>repl driven development is very good, but when you introduce an event loop (i.e. a game) it gets a little more complicated. <resica>I guess it really boils down to if I like python's syntax or scheme better. <dthompson>yeah, or if you want to go all-in on python's style of OOP because that's really all you get with python <rlb>it's a *little* more flexible now with dataclasses, but yeah... <dthompson>python being one of the most popular languages around has clear advantages in terms of available tools and libraries. <resica>Since the GNU site is a bit slow on my end, what is the environmental variable for search paths for guile libs? <dthompson>GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH <dthompson>the former is for source files, the latter for bytecode <dsmith>And then there is the GIL to consider. While Guile as posix threads and optionally fibers <identity>resica: you should be able to get at the manual with (info "(guile) Top") from Emacs and “info "(guile) Top"” from the terminal, if it is installed <rlb>You may know, but you may also have the info pages handy, i.e. "info guile" (or M-x info in emacs), and then C-s to recursively incrementally search, etc. <resica>Oh yeah, I forgot for a second there was an info page. I almost never use that, should remember it more. <rlb>Oh, I just meant as an alternative to trying to find it on the web. <rlb>It's (of course) the exact same pages as you get via gnu.org, so handy atm. <rlb>Merged the concurrent init fix, old's tmpfile fix, and srfi 207 support (bytestrings, enc/dec base64, read/write u8\"\\xe2;\\x88;\\x9e; Improbability\", etc.). <resica>dthompson, when using chickadee with the REPL, do I need to run "scheme > run inferior scheme" or use the shell script launcher under the bin directory? <rlb>(Used a merge commit for srfi 207 so it'll be easier to back out if "something goes wrong".) <rlb>For anyone interested, might be a reasonable time to test again for 3.0.11 (i.e. might be mostly there). I'll probably test s390x again (for big endian) and a 32-bit arch soonish. <rlb>Well, hold that thought -- apparently I broke bootstrapping with 207 (didn't think to check that). <rlb>Not sure what needs doing yet -- I think it's probably the reader-changes wrt stage0. <rlb>Current main is fine on 64-bit LE (amd64) and 32-bit LE (i386), but not fine on 64-bit BE (s390x). On the latter it fails on "fluids.test: fluids are GC'ed". Ring any bells? <rlb>(Also, this is in a current Debian unstable envt, so notably, GCC 15.) <rlb>Putting a (sleep 1) before the gc "fixes" it? <rlb>I assume that probably means the test just isn't quite right, but I'd love a second opinion. <rlb>I'm not yet sure exactly what it was trying to test, i.e. was it more than just that the fluid eventually ends up in the guardian? <rlb>If so, then was the loop making fluids just a hope that it'd put enough pressure or the gc or something? <rlb>I'll have to look more closely, but of course, if anyone else is more familiar there... <rlb>(Oh, looks like civodul is a likely candidate to badger.) <dsmith>rlb, I was building from scratch on fbsd but was in a $DAYJOB meeting. Yeah, getting a syntax error. in srfi-207 <rlb>Should be fixed now. <rlb>I just forgot to remove a vestigial include-from-path, and I still had the file here... <rlb>Locally (amd64, trixie), fluids.test passes fine even if I remove that loop entirely. <rlb>Perhaps the compiler and/or arch affects the gc's eagerness somehow? <rlb>ACTION reads up on guardians <rlb>Even increasing the loop iterations by two orders of magnitude and adding a (make-string 4096) doesn't help, but the sleep does, even a (sleep 0) with no loop at all works. <rlb>That makes me wonder about scheduling. <rlb>Though it's nominally a two core host (vm?), so the increase loop load should have "worked"? <rlb>sneek: later tell civodul the "fluids are GC'ed" test is failing on s390x (64-bit, BE, gcc15), and it succeeds if I add a (sleep 1) just before the (gc), with or without the loop. Any idea why? <dsmith>So. Latest git passes for me on fbsd with a magic configure option and some skips in some tests. <dsmith>Without the ac_cv_func_posix_spawn_file_actions_addclosefrom_np instructions to ./configure, one of the standalone tests segfaults <rlb>I'd be in favor of eventually getting some version of all that (whatever we need) into main, i.e. freebsd ought to work. <dsmith>I think it's one of those cases where yeah, the function is there, but it does something different than Linux <rlb>right -- I might know someone(s) we could badger later if anyone wants to pursue it. <rlb>in terms of a potential broader fix <dsmith>Two of the skips are for seeking in a hole. That might be filesystem dependant on fbsd. <dsmith>I'm on ufs. zfs might be different (and work as advertised) <dsmith>One of the tests looks at /proc/self/fd/0 But I don't have /proc mounted. Might pass if it was.