IRC channel logs
2023-06-03.log
back to list of logs
<rlb>wingo, civodul: too big a change for now, but after getting back to the utf-8 work, I was vaguely wondering if it could be worth the complexity to lift the string character bytes in-line for common cases, i.e. immutable-ascii, immutable-utf8, and perhaps even mutable ascii, i.e. avoid always jumping through the stringbuf pointer, at least for "original" strings. But then we'd also need a "non-shared substring" flavor that could point <rlb>...value depends in part on how common non-substring strings are. <jpoiret>is there a way to expand code step by step? <jpoiret>i'm getting a syntax error because of some stray ellipses in a very complex macro-generating-macro, and just adding with-ellipses doesn't cut it, so I'd like to see where exactly it goes wrong <jpoiret>the roundabout method complains about the ellipsis for some reason, but the "one step expanded" version works properly <civodul>jpoiret: unfortunately no, there's no macro debugger in Guile <civodul>the example above might reveal a bug <civodul>i would expect ... not to be interpreted as an ellipsis, indeed <civodul>(with-ellipsis xyz (discard-with-extra-steps (oops ...))) works fine <civodul>(is "ellipsis" uncountable actually?) <jpoiret>so there's no way to change the fact that it's an ellipsis! maybe i can try to work around that then <civodul>do you have a reproducer for the networking.scm problem? <civodul>wingo: we're discussing hairy macrology :-) <wingo>civodul: i want to merge wip-soft-ports ! <wingo>lmk what you think. doesn't have to be tonight <civodul>i didn't know about its existence :-) <civodul>i can't look at it right now, though <wingo>well, yes -- but really it's a rework so that there is a scheme interface to the full port type functionality <wingo>and then a rebase of the existing soft ports and custom binary ports on top of that <wingo>and implementation of custom textual ports <wingo>and a new interface to soft ports <wingo>and finally some refactors to pretty-printing and truncated-printing to abort if too many chars are printed <wingo>less c, more scheme, is the thing :) <civodul>jpoiret: we introduce a syntax object that inherits the source location of the original form, that's it <civodul>wingo: so yeah, i won't take a look right now, but happy to do so in the coming days! <civodul>jpoiret: i'd avoid syntax-case for match-record altogether, it doesn't bring anything <civodul>also, the location of (match-record ...) is not the best one for that error message <civodul>maybe worth discussing one of these days if you have thoughts on how to improve the situation <mwette>jpoiret: I'm guessing you were not using with-ellipsis in the right context I added (lambda (t) (with-ellipsis t () (syntax-case ... and it worked. <mwette>oops (lambda (t) (with-ellipsis ::: (syntax-case t () ... <jpoiret>mwette: doesn't work for me, whether i put it around the syntax-case and the syntax-rules <jpoiret>but with civodul's explanation it actually seems reasonable that it doesn't work <wingo>civodul: for that bug, is it really 250 MB for 22k entries? that is 10 kb per vector, yes? <wingo>but yes happy to discuss etc :) <jpoiret>mwette: huh, i thought i had tried this as well, good to know <jpoiret>weird that this wouldn't work with syntax-rules <rlb>wingo, civodul: am I right to think that we can't change the layout of at least SCM_IMMUTABLE_STRINGs without an X release? i.e. whatever we do has to preserve that bit we've exposed? And are there other cases, i.e. does anything else store currrent-format strings in .go files, etc.? <jpoiret>mwette: right, but why would the position of the with-ellipsis here matter? it's changing the binding at the syntax level, so why would lambda guard it? <mwette>I think you'd have to look at what with-ellipsis is. it's putting a lambda where a syntax form is expected, I'm guessing. Not sure. <jpoiret>it's a builtin thing in (ice-9 psyntax), and I am not proficient enough in Guile internals to be able to read psyntax