IRC channel logs
2025-09-04.log
back to list of logs
<dsmith>That segfault in test-system-cmds goes away if I undef HAVE_POSIX_SPAWN_FILE_ACTIONS_ADDCLOSEFROM_NP <rlb>I must be missing something -- in array-map.c we call scm_ramapc(rafill, fill, ...) but in ramapc, it looks like if the second argument isn't SCM_UNBNDP(), then it calls the first argument (rafill) with three arguments, but rafill only takes two. <rlb>Or are we just getting "lucky"? <rlb>that looks like a bug... <dsmith>Hmm. `echo Hell World | wc -w` is " 2\n" on fbsd <rlb>yes, on (free)bsd you have to omit the "" in say test expected = $(... | wc -l). <rlb>i.e. not "$(... | wc -l)" <rlb>ACTION keeps forgetting that in the bup tests... <rlb>dsmith: if you hit any other surprises, shout, I might have something handy. <dsmith>Now all tests pass except for the 6 skips I added <rlb>(though of course that's not fbsd) <dsmith>the wc thing is posix.test: "wc with stdin and stdout redirects" <dsmith>rlb, test-concurrent-init passes on fbsd <kkremitzki>Just a thought, but I have had some sporadic issues accessing gnu.org/s/guile presumably due to server overload, could it make sense to have a separate guile.gnu.org ? <dsmith>My auto*-fu is weak. Is there a way in ./configure to not check for posix_spawn_file_actions_addclosefrom_np ? <dsmith>Ah. This seems to do it: ac_cv_func_posix_spawn_file_actions_addclosefrom_np=no ./configure <dsmith>rlb, RE wc on *bsd. Just pass the output through string-trim ? Or instead skip the test? <rlb>sure, if easy enough, stripping whitespace seems right <rlb>I think that's probably fine "everywhere". <dsmith>rlb, Also, the (*)() -> void* patch seems to be fine on freebsd <euouae>Been having some good fun doing advent of code challenges <euouae>I've discovered transducers and streams today <euouae>I can put it up if you'd like to see it <ArneBab>I’m still continuing on the 2021 problems now and then. <euouae>I'm doing 2024 but Ive never done an AoC fully <ArneBab>for the code you like, I’d like to see that. AoC is a great way to learn new approaches. <euouae>I did day 2 with transducers. I use list-transduce but I should probably move to port-transduce (i.e. transduce with reads over the port/file instead of reading the entire file in memory) <euouae>Actually I implemented both days naively at first; the naive recursive solution is "optimized Scheme" actually and is faster than using streams. <euouae>But streams make the code much better to look at, and for any real work the speed gain is negligible <euouae>ArneBab: as you can tell I did not use autotools -- it's still a TODO of mine to fix autotools support for Guile. <euouae>The thing that's broken is `make distcheck` I believe <ArneBab>but once you get that running, you have a simple local check to ensure that all should work in deployment. <euouae>ArneBab: thanks I will take a look <euouae>ArneBab: I'm not yet at the point where I want to look into this issue and fix it yet so this will have to wait a bit <euouae>but I want to ask you -- if you have a solution, why not contribute the m4 macros to guile? It currently ships with a broken distcheck <euouae>That solution you have from guile-devel is broken too, I am not sure why it works for you <euouae>Hm -- although your solution is different to mine in some parts. I wonder if that's the magic trick... I'll have to study it eventually and figure it out. <ArneBab>euoae: my solution works for wisp, so it needs some different suffixes. That’s why I didn’t add it to guile. <ArneBab>⇒ has quite a bit more complexity than a pure scheme one needs. <rlb>dsmith: great - thanks for testing; I also raised a trivial pr to fix the incorrect rafill invocation -- though clearly it hasn't mattered. <euouae>had some fun with `make-string' and `substring/shared' yesterday. It's funny that I was trying to get a "single buffer" optimization but by (initially) using `substring' I ended up cloning the buffer per-line anyway <euouae>I think I finally see the light with regards to Guile's autotools situation <euouae>I don't think Guile object files are meant to be compiled in one machine and installed in another (unlike ELF files) <euouae>Therefore the entire process of writing .scm.go: rules and installing the resulting .go files together with the .scm files is broken /because it was never meant to be that way/. I am not 100% sure on this of course. <euouae>Does anyone know if Guile object files are meant to be shared between computers? <ieure>euouae, Not sure about "meant to be," but they *are* on Guix. Any Guile packages get AOT compiled and the .go files shipped in a ccache directory. <rlb>In debian, we don't, but it was my impression that it was supposed to be possible -- iirc there are 4 "flavors" wrt endianness and word size. <dthompson>object files are meant to be distributed yeah <rlb>sorry, we do, but per arch. <rlb>i.e. we don't take advantage of the fact that you *could* share them (cwould be nice wrt the slower host build times, in theory). <dthompson>they're not universally distributable. they are built for a particular architecture and require a guile vm that supports the bytecode version <rlb>dthompson: do we have any promises there? I'd vaguely thought we might, but now that I think harder about it, in addition to word size and endianness, it'd probably also be at least "soname" too, e.g. not promised across major versions, etc. <rlb>I suppose it's part of the ABI. <dsmith>Yes, there are 4 flavors, but there is also a version number. Sometimes new opcodes are added. <dsmith>But if the wordsize+endian+version match, then it should be portable between arches. "should" <rlb>ahh, right, I'd forgotten about the version (wonder if I need to (likely I'd guess), and/or did change that in the utf-8 series). <dsmith>Or maybe I'm thinking about the dirname they are in? <dsmith>I have 3.0-LE-8-4.6 and 3.0-LE-8-4.7 <rlb>I'll plan to double-check things later... <euouae>I know they're not universlaly distributable -- neither are ELF files like I said <euouae>I'm just trying to figure out the autotools process with Guile <euouae>it's either broken or not explained, either way... for now I'm just trying to install the scheme files without compiling them <dsmith>The source tarball comes with pre-compiled .go files. They *are* ELF files. But that's just a file format. They do not contained machine code. <euouae>Okay I dind't know go files are ELF files, but you don't have to tell me that ELF is a file format <euouae>That they're ELF files in itself does not guarantee that they are meant to be distributed across different systems (same arch) but if you say so -- then fine. I really need to go down this stupid rabbit hole and figure out exactly how to ship them. The Guile manual is severely lacking in this regard <ieure>Do the .go files have bytecode? <euouae>ieure: AFAIK it's just an intermediate representation of scheme code <rlb>it's code for guile's "vm" <dsmith>Yes, they have bytecode. And diagnostic info. And read-only sections. So not everything is loaded at once, only as needed. <rlb>euouae: what's the original problem you're having, again? <euouae>It probably contains a mash of random snippets from online -- no real thought into it. I plan to look at it with fresh eyes (& more M4 knowledge) again these coming days <rlb>hmm, not sure I ever run distcheck for the debs at least... <rlb>i.e. there we just "make install" and then package those files... <euouae>distcheck is supposed to show you that you package the right files, that the tests run, etc <rlb>(make install to a local prefix) <euouae>These are serious issues that newcomers encounter that prevent them from getting into guile <rlb>Oh, sure -- if it's broken and you want to help fix it, great. Just didn't know if it was critical to whatever you were originally trying to do. <euouae>I want to possibly fix the m4 code, I want to fix the guile manual on autotools <euouae>It's not critical but I'm trying to write an emacs clone in Guile and I'm flustered by the build system <euouae>I even wrote an m4 clone in Python to understand m4 better to fix all that's broken with Guile and autotools <rlb>I also saw saw one bug filed along those lines wrt maybe not working right if the source was read-only. <ArneBab>sneek: later tell euouae: the .go files are distributed, because that avoids long startup times on first run after update. With long, I mean minutes for a somewhat large program. After that, if you don’t have precompiled *.go files, guile will auto-compile them. <rlb>Perhaps also distributed because bootstrapping on slower architectures can take actual days :) <ArneBab>sneek: later tell euouae: another reason is that *.go files are language-independent. Whether you wrote your logic in elisp, in ecmascript, in wisp, in brainfuck, or in pure scheme: once it’s compiled to *.go files, you can use it from any other language. <ieure>ArneBab, How can that be true if Guile's .go files contain bytecode and not machine code (as dsmith said eariler)? <ieure>Are you talking about cases where the "other language" embeds Guile? <ArneBab>ieure: I talk about the case where the other language is one of the languages supported by Guile <ArneBab>(not *any* language, but Guile-language) <ArneBab>The examples I gave are all languages supported in Guile. <ieure>I see. I didn't realize Guile had JS and Brainfuck support. <ArneBab>AFAIK it even has xcb-xml-source support to efficiently create xcb bindings :-) <ieure>Interesting, I knew Racket had frontends for different languages, but didn't realize Guile did. <ArneBab>the JS support is stricter than browsers <ieure>imma write some Guix packages in brainfuck <ArneBab>Guile is less flexible than Racket: the languages are per file, and when you import a file with a different language without pre-compiling, the auto-compilation throws errors. <ArneBab>That said: this means that Guile is more about embedded domain specific languages that can use all capabilities of the host language than about building tiny languages that solve one problem but have to be learned from scratch when you want to hack the code. <ArneBab>⇒ I’m not sure what would be the best way forward. <ArneBab>But I like the current state: lots of flexibility but little added complexity for the simple case (which is: all is Scheme). <jklowden>Hello! gnu.lists.org seems to be unresponsive at present. Is it just me, or is something going on?