IRC channel logs
2026-05-02.log
back to list of logs
<JohnCowan>rlb: I was once on a WG (not IETF) with someone from $MONOPOLY who said, "If there aren't at least ten million documents that have [this feature], WE DO NOT CARE." <rlb>Hmm, was this wrt the json discussion y'all were having? <JohnCowan>no, it qaa about xml namespace names that were in the form if relative uflx <rlb>oh, not sure I was following that discussion. <rlb>old: I almost certainly should have left it alone for now, but I may have gotten inline "basis strings" working (what, for now, I'm calling that promotion of stringbufs to a string subtype) --- after only moderate quantities of colorful language. We'll see, only finally got past eval, have to see how the tests fare if it gets that far. <rlb>nope, compile-cps isn't having it. <rlb>OK, so check-guile really doesn't compile the tests before running them. I just ended up with different results because of that (because (I'm assuming) of differences in eval/compile). Wonder if that's the right default. <rlb>(if compiled code (auto or otherwise) is what's more often run in the wild) <probie>Is there a reasonable parser combinator library for Guile (like Angstrom for OCaml or Parsec for Haskell)? <regtur>probie: I am not familiar with Angstrom or Parsec, but you may want to look into Guile PEG <janneke>(eg, if anything is out of order, you'll just get => #f without getting any more information whatsoever) <mwette>janneke: thanks -- I've looked into it several times in the past but never went far. Maybe I'll get back to it after the merge. <janneke>mwette: fwiw, i've heard of an effort to separate gcc's frontend and backend, and connect them with s-exps <janneke>it's something to do with gnu cobol support <janneke>i've got not much more information whatsoever, but wouldnt it be cool if gcc's frontend's s-exps were compatible with nyacc's? <janneke>possibly regtur has more (contact?) information on this if you're interested <regtur>James Lowden (one of the authors of the gcc cobol front end) is seriously experimenting on this <mwette>Hmm. The (original, at least) gcc had a lisp-like form for RTL. So I wonder what that is about. Try 'gcc -c --dump-rtl-expand foo.c' for simple foo.c <janneke>mwette: interesting, i've got no idea; regtur? <mwette>nyacc's convention of sxml for intermediate language may not be the most efficient, but it is fairly easy to work with, IMO. <mwette>I've been working on a matlab to pick-your-language translator, with analysis for extracting type information. <janneke>mwette: certainly! writing mescc, nyacc's s-exps were never any problem or consideration <janneke>otoh, mescc is also pretty tightly bound to nyacc's s-exps <regtur>mawette: rtl seems to be at the assembly level, I believe James is aiming at a higher abstraction between the front end and the back end <mwette>web search says as of May 2026 gcc has cobol front end called gcobol <mwette>that makes sense. Also, I thought gimple sort-of replaced the original rtl. <regtur>If I am not mistaken, James is trying to document gimple using sexps <ekaitz>both gimple and rtl exist, don't they? <ekaitz>they are two places where optimization happens <ekaitz>i remember a little about the machine descriptor files and all that <ekaitz>what a crazy codebase that gcc is... my lord <regtur>'gcc -c -fdump-tree-gimple foo.c' shows that gimple is not sexps <mwette>I used to build gcc cross compilers before the days of configure (e.g., 1.42 sticks in my head) ; it came with a long README file. <mwette>For my translation project I convert sxml to 'vxml' a vectorized tree, where every node turns into an index in the vector. Then when I want to track some property (e.g., type) I add a vector for that property. A bit fortranish, but it works. <ekaitz>i always forget, how could i globally set the line width of the stack trace in guile? <ekaitz>my strings continue have "..." and I do actually want to see the end <rlb>(include it with the utf8 work) <rlb>(By "symbols", I mean the string that symbols refer to.) <JohnCowan>rlb: I was reading your README, and spotted "wise" for "wide". <rlb>execinfo.h and the info libc sample print_trace was handy (to just write a conditional stack dump in the code --- imagine I could do something similar with gdb, but that was easier at the time) <Riviera>ArneBab_: “This page contains the following errors:error on line 158 at column 10: Opening and ending tag mismatch: img line 156 and figure <sneek>Riviera, you have 1 message! <sneek>Riviera, ulfvonbelow says: if you look at ~/.guix-profile/etc/profile, you'll see that $GUIX_PROFILE is treated specially if set. This is why the manual and hints always specify to first set GUIX_PROFILE, then source $GUIX_PROFILE/etc/profile <Riviera>ArneBab_: Below is a rendering of the page up to the first error.” <Riviera>ArneBab_: Not an e-reader, but the Books app on macOS. <Riviera>ArneBab_: Also is there some sort of link list: "Wissen Software Politik Anderes Kreatives Rollenspiel" that does not appear to belong there. <ArneBab_>Riviera: thank you for testing! I’ll try to find how I can get rid of these. <ArneBab_>Riviera: already found the first issue: doctype must be set to xhtml5, not html5. <ieure>Does Guile have anything like Clojure's group-by? <rlb>Though you might want to check upstream for any changes (I haven't in a good while). <rlb>Maybe fairly straightforward if alists or specific hash-tables are ok. <ieure>rlb, Clojure implementation heavily relies on its hash-map implementation, hash-maps in other Lisps are much more fiddly to use. I can write an alist version, was just hoping there was one already. <rlb>sure --- presumably you'd convert it to much more limited semantics for whatever your use is. "general purpose" would be something else entirely. <ieure>Yeah, it's fairly easy to hack up, just had to find some of the alist procedures. <Riviera>ArneBab_: Those errors are gone, yes, but it's a rather strange document. Reflow does not appear to work after the table of contents. Did you "hard-render" it somehow? <Riviera>ArneBab_: (In other words: After the table of contents the lines do not wrap except for apparently pre-set positions. Also in normal text, not just in the code blocks.)