IRC channel logs

<jab>I wonder how hard it would be to wire up support for box2d in chickadee.

<JohnCowan>jab: this is "new crunch", which is only conceptually related to "old crunch"; it exploits the data inferencing of the Chicken 6 compiler

<jab>JohnCowan: have you messed with "new crunch" yet?

<av>hi is anyone knowledgeable on the guile's compiler tower?

<av>the docs are very hard to read

<ekaitz>av: what do you need to learn?

<av>I wanted to know, how syntax-transformers get applied correctly? At the moment, i get the error 'Wrong type to apply: #<syntax-transformer test-equal>'. Unless I use the fresh-user-environment module. Sorry if it's a bit brief

<av>ekaitz: .

<ekaitz>hm! i don't have a proper answer to that

<av>I understand that the language tries to use test-equal as if it was a normal procedure, even though it really should be expanded at compile time, but it doesn't! It thinks its a procedure

<av>Pulling my hair over this

<dthompson>the application of a syntax transformer error is almost always caused by using a macro before it is defined

<dthompson>because guile will treat that as a regular procedure call and not a macro expansion

<JohnCowan>jab: no, just read the more-magic post

<av>Hey dthompson: ! I once posted one of your blog post on hackernews and it got quite a bit of traction lol! Love your stuff

<av>anyway the thing is i'm not just doing normal guile stuff, I'm defining a language.

<av> https://git.sr.ht/~avv/gg/tree/0bb88471752b6eb568a226454b13615cf973f8d2/item/language/gg/spec.scm

<av>and therein lies the problem

<av>there seems to be no proper macro expanding, but I'll take your advice and see what I'm missing maybe

<dthompson>av: heh which one was it? also thanks

<av>the one about optimization

<dthompson>ah okay, yeah I remember that

<dthompson>thanks! :)

<av>np X)

<av>i just got guile to segfault

<av>great

<av>do syntax transformers and normal definitions live in the same public interface? It might be the problem

<av>I mean, it used to be that you need to #:export-syntax for syntax-transformers

<av>neverwind i don't think so

<av>*nervermind

<old>av: report your segfault: https://codeberg.org/guile/guile/issues

<old>Segfault are my #1 priority to fix

<old>export-syntax is deprecated. All bindings live in the same scope/namespace

<av>Ok I'll create an issue, and find something reproducable

<av>should i provide the core dump as well? or is it not necessary/not safe?

<av>old: .

<old>gdb bt if you can

<old>(gdb) thread apply all bt

<av>its a recursion issue so the backtrace is very, very large. I've put a tar in the issue for you to see it for yourself

<av>i didnt know it was a recursion issue at first, but this error seems pretty tame. seems like it should be simply a stack overflow

<old>ty

<av>np

<old>So I was thinking of making a release candidate of 3.0.12 in the next 3-4 months

<av>oh yeah? with what news?

<av>(call (@@ (language gg spec) test-begin) (const "hi"))

<av>(call (@@ (language gg spec) test-equal) (const #t) (const #t))

<av>(call (@@ (language gg spec) test-end) (const "end"))

<av>that confirms it

<av>it's calling test-equal as a procedure, although i made sure time and time again that its a syntax-transformer within the module

<av>wtf is going on in compile-tree-il

<av>wait no @@ (language gg spec) looks awfully suspicious

<av>i deffo need a break

<graywolf>Style question: With #:use-module, do you typically pick just the needed bindings with #:select, or simply bring in everything?

<graywolf>I am bit torn and cannot decide which way should I prefer as the default one.

<old>av: Lots of bug fixes and some features. See NEWS

<old>graywolf: I use #:use-module plain generaly. #:autoload when I don't want to pull the whole module tree

<old>other prefer to be explicit about all bindings

<rlb>graywolf: I now generally use #:select after experience with the clojure community where that's nearly always the norm. Makes it very easy to know where something came from, and insulates from future changes at of course a one time cost of some extra lines.

<ieure>rlb, I agree, wildcard imports are IMO a bad idea in any language. I will pretty much always #:select or #:prefix these days.

<rlb>(The clojure norm was actually originally :refer :all, but changed.)

<ieure>rlb, Yep, I remember that. I'm glad it changed.

<ieure>I was farting around with Clojure before the 1.0 release.

<old>finish a rabbit hole on the worker threads state machine

<old>that thing was broken

<old>at least since 3.0.10

<old>I think that just this fix alone is worth the 3.0.12 release. Basically, any primitive-fork can just deadlock or crash, depending on how unlucky you are

<old>will send it for review soon

<rlb>that's less than ideal :)

<graywolf>How can access the current exception in the repl? Like, if exception happend and now I have the [1] in the repl, how can access the exception that caused it?

<graywolf>There is ,error, but that just prints it.

<graywolf>ieure: rlb: It is bit annoying that you cannot always use #:select on the module that brings in a binding though. E.g., ((json) #:select (json-string->scm)) dies with error, despite the fact that ,use (json) bring the binding of that name in scope.

<graywolf>(json) is from guile-json-4 package in Guix

<rlb>As far as I know you should be able to select any binding that's exported.

<rlb>and those are the ones that should show up if you don't select.

<graywolf>Well it does not work in this case, probably due to the fact that (json) just re-exports from (json parser) and (json builder).

<graywolf>At least cannot think of any other reason

<rlb>I don't know that package, but offhand, I'd assume that means something's not quite right somewhere.

<rlb>(whether in the package, or in guile itself)

IRC channel logs

2026-09-02.log