IRC channel logs

<daviid>old: having the CL declare spec implemented in guile, at lesst the most important subset of the spec, so that the dreclaration are being 'taken care of' by our guile compiler ofc, is somehting I have been dreaming about for more then 20y - there is just no better way/spec, for users to (optionally) declare 'things' to a compiler - if you can work on this, really not a peice of cake, you'll be my hero :-)

<old>daviid: I will try do add in a first step something along: (declare (no-inline foo))

<old>I'm not very familiar with declare of CL so I don't what to which degree it's possible to declare thing to the compiler

<old>But for example, it would be nice to declare a type to the compiler. A "trust me bro, this is a string type" kind of declaration

<old>ofc if you don't get a string, that would be a violation and could result in undefined behavior, but you would elide a type check if done correctly

<old>Idk off hand which other declaration would be nice

<daviid>I recommand you read the spec, but apart from acheiving unboxing of int, float ... an avoid runtime checks for any scheme type, you also have options such like speed, optimization, debug ... properly used, I could get lisp code run faster then C (long time ago, code ostly manipuating floats ...)

<old>That would be very nice

<old>I think that selecting the proper optimization pass is doable also

<old>could be we can tag function in tree-il with some metadata that can be pass along the compiler tower

<old>so you can explicitly turn-off certain optimization on a function even if globally you are at O2

<old>that could be very nice say you have a bug in the compiler that segfault this one function of your

<old>which is not so rare in my experience

<old>ArneBab_: fixed your issue

<old>I haven't reproduce your issue with my patch

<old>Will format this later this evening or on monday

<old>and sent it to you for review.

<old>You prefer a PR ?

<ArneBab_>old: I’ll gladly review it in any format you choose!

<ArneBab_>old: where did you patch it? In my code, in fibers, or in guile? If it’s in guile, a PR would be better, because I can merge that after reviewing.

<ArneBab_>old: and thank you for taking the dive to fix this!

<probie>This is probably another silly question. When I open a repl in guile there are nearly 2000 variables/procedures/macros in scope. Is there a way to "hide" most of them?

<ArneBab_>probie: you can create your own module and then enter it via ,m the-module-name -- there you can constrain them to some degree. The sandbox may be an option (reduce available procedures), but I never tried that yet, so I don’t know whether it can be made to work at the REPL: https://doc.guix.gnu.org/guile/latest/en/html_node/Sandboxed-Evaluation.html

<old>ArneBab_: Guile in C

<graywolf>apteryx: Hi! Regarding https://codeberg.org/guile/guile/issues/199 , what happens when you press Cancel? Do you not get the error page?

<graywolf>I thought I had a clever hack against AI scrapers, so I am sad it also turns away real people :/

<graywolf>It is annoying browsers no longer display the realm

<ArneBab_>old: then a PR (and a link to it here) would be best. I can review and merge it then.

<probie>graywolf: I don't think most people will click cancel, they'll just close the tab

<probie>Continuing my trend of asking questions; I have what are conceptually 128-bit "bitvectors", and need to efficiently support bit-wise and/or as well as shifting. What data type should I use in guile?

<rlb> https://doc.guix.gnu.org/guile/latest/en/html_node/Bit-Vectors.html ?

<probie>That represents the data, but doesn't really provide the operations I need. I mean, they can be implemented, but it won't be "fast"

<rlb>Well, if you need more arithmetic operations, perhaps just integers?

<rlb>Depends on what you need.

<rlb>With integers you also have the bitwise operations, srfi-60, etc. https://doc.guix.gnu.org/guile/latest/en/html_node/Bitwise-Operations.html

<probie>"just integers" probably works (they're bit boards for a chess-like game). I guess I was just surprised that bit vectors didn't support and/or

<rlb>yeah, I hadn't noticed that yet --- I'd guess integers will be fairly efficient, though perhaps not as efficient for some of the things bitvectors do support.

<rlb>If you have the time, of course, could always do some testing of your performance-critical operations.

<rlb>might be interesting

<JohnCowan>probie: rlb: srfi 178 supports boolean operations on bitvectors, but I don't know if Guile has it yet

<rlb>JohnCowan: oh, thanks, I bet I'd seen that before, which would explain why I kept poking at our docs trying to figure out if we had operations like that. I don't think we do atm.

<rlb>Do you happen to know if guile's existing bitvectors are compatible with that srfi?

<rlb>i.e. could we just "extend" eventually?

<JohnCowan>you'd need to rejmplement it or get the implementation elsewhere, because the representation uses 1 bit per byte for simplicity and correctness.

<rlb>Oh, sure, I meant "functionally", i.e. do ours do anything "incompatible" somehow.

<rlb>if not, then might be interesting to poke at later.

<rlb>And only wondered if you already knew.

IRC channel logs

2026-06-13.log