IRC channel logs
2026-06-26.log
back to list of logs
<mwette>I like starting line and column at 1: makes more sense. <ekaitz>old: you are looking at the unmatched paren issue, right? <old>ekaitz: that and more. the reader erro reporting is not great and I want to improve it <ekaitz>old: i took a look into it when I found the issue and talked with arun. It is designed in a way the error reporting is not really taken into account <old>it was ported from C to match exactly I think <old>but we can do better now <ekaitz>it was trickier than I thought it was going to be <old>for example I merge today c19c452f8d5f02b7ff60dfd19055d3c27e0bc398 <old>hmm for the unbalance parenthesis, I did it locally <old>it's kind of trivial if you keep parameterize context <old>> c19c452f8d5f02b7ff60dfd19055d3c27e0bc398 <old>#( 1 . 2) => foo.scm:2:3: bad literal vector `#(1 . 2)'. Did you mean `#(1 2)'? <old>Instead of the old backtrace in the reader <old>oh I made a mistake. The reader annotate the syntaxes with -1 on column aready okay <old>so it's already a 0 index base for column cool <euouae>How are things? I have been designing a game in Godot 4 and it's a lot of fun. I think Godot recently got a nice boost in dev due to nonsense with unity. Anyway, how is Hoot doing? <euouae>I see there's been a new release, 0.9.0 <old>so says we change error location of the reader <old>to be the begining of the expression instead of the end <old>would that be considered a breaking change hm ? <old>yet this only change the reported message in error <old>location of syntax objects and source properties are unchanged <old>so I guess if someone grep their read-error that could be breaking hm <old>if that's even a thing <ekaitz>oh, in that case maybe it isn't? <rlb>I don't think we've generally included the format of our error messages in our "api", and I suspect we generally don't want to. <old>the error location itself is not expose to the exception <old>i.e., you can't have the error location as numbers. You need to parse the message to extract them <old>which I would like to chnage in the future. For good error reporting, origin tracking is critical <rlb>Yeah, I could easily imagine, all else equal, you might want both the start and the end as attributes/components/whatever of an exception like that. <dsmith>Hmm. Could Geiser (or other?) be aware of error reporting? <rlb>How can we tell the scm_t_hash size from scheme? Or alternately, do we have easy access to sizeof(uintptr_t) in scheme? <rlb>ahh, at least (sizeof uintptr_t) works for (system foreign) <mwette>(use-modules (system foreign) (sizeof uintptr_t)