<rekado>I haven’t really investigated this much, but I’m having a problem with reported error locations when using load. <rekado>I’m loading a wisp file and any errors triggered by that file prints something like “ice-9/boot-9.scm:1669:16: In procedure raise-exception: …” instead of the location in that file. <rekado>it’s probably my fault, because I’m setting a prompt tag before using “load”, and I’m walking up the stack in the error handler. <mwette>rekado: I get that all the time, with Scheme code. <mwette>Sometimes works better if you compile relevant code w/ -O0. <rlb>...given the recent compiler changes, is say (memv x chars) likely to perform much differently from an equivalent case clause for say 10-20 characters? ***daviid is now known as Guest39344
***Guest39344 is now known as daviid
<apteryx>is there a way to have format ignore some characters (e.g. ascii color escape codes); I'd like padding to work as expected even when coloring output. <RhodiumToad>you want it to treat the string's length as something other than what it really is for padding purposes <apteryx>one of the components gets decorated by an ANSI escape code, which format rightly treats as characters. Since they're invisible though, that visually doesn't work well with the usual padding mechanism. <RhodiumToad>that suggests you need your own function to get the "display length" of a string, and compute the padding from that <RhodiumToad>which of course requires knowing what sequences are escapes <apteryx>another thing I was wondering about: is string-match really inefficient compared to regexp-exec? Wouldn't the byte compiler already be able to preprocess (e.g., compile) the regexp when it's static, else cache the result from a first compilation at run time? <apteryx>The doc suggests that no, but I'm curious whether there technical reasons for such limitation. <spk121>Over the years, I have written a few fairly elaborate parsers for escape codes (ECMA48 and other associated standards) but sadly I don't have one in Scheme to offer you <terpri>apteryx, dunno if it's "really inefficient" compared to regexp-exec, but typical uses of string-match don't compile static regexps during byte-compilation <terpri>e.g. compare ',x (lambda (x) (string-match "a*b" x))' and ',x (let ((a*b (make-regexp "a*b"))) (lambda (x) (regexp-exec a*b x)))' <terpri>(i'd guess it's because string-match or regexp-exec could be redefined by the user) ***daviid is now known as Guest7891
***Guest7891 is now known as daviid
***rekado_ is now known as rekado
<rekado>with srfi-64 can I use test-error and test-read-eval-string to not only detect that a syntax error is reported, but also match on the error message? <rekado>mwette: I was hoping to avoid compilation, because it’s an extra step, but I’ll give it a try in the pursuit of better error messages. ***nalkri is now known as Guest58182
<wingo>i should maintain it better :P i always have 2 or 3 WIP checkouts around for experiments in progress that i haven't gotten around to publishing <wingo>i have a moderate goal of not breaking back-compatibility, but if there are real improvements that can apply generally then i'm fine with breaking changes <wingo>generally speaking that means added functionality always ok, changed functionality possible but good to avoid <wingo>i keep meaning to take a few months and do a proper grammar-of-graphics thing :P <rlb>wingo: oh, and it's not at all urgent, I was just toying with a perf test against the C vecs. <rlb>(when the test suite hit that) <civodul>wingo: as you prefer, i'm happy with you pulling or with me pushing if you don't mind giving me access <civodul>and yes, these were just basic fixes <civodul>but actually, perhaps i forked off an older branch at wingolog.org? <civodul>re grammar of graphics, don't miss rekado's guile-picture-language :-) ***Guest58182 is now known as nalkri
***ChanServ sets mode: +o civodul
***civodul changes topic to 'Welcome to #guile. See https://gnu.org/s/guile for more information. Guile 3.0.5 is out! <https://www.gnu.org/software/guile/news/gnu-guile-305-released.html>. This channel is logged, see <http://logs.guix.gnu.org/guile/>. Bug database at <https://bugs.gnu.org/guile>.'