<meo>how would I implement a DSL like (with-foo foo (bar-fn 1 2)) where foo is passed to exp implicitly and bar-fn is not a top-level definition? parameterize foo and use syntax rules for bar-fn? <meo>leoprikler: foo is an immutable srfi-9 record, it contains text terminal buffer, cursor position and similar settings, bar-fn are procedures that e.g. move cursor or apply changes to buffer <meo>so I would like to do something like (in-terminal term ((move 10 10) (fill-rect 5 5))) etc <leoprikler>i think you could implement the latter part inside a match(-lambda) <meo>oooh let me google it <leoprikler>e.g. (move x y) gets translated to (set-fields term ...) <leoprikler>meo: search for "ice-9 match" inside the documentation <meo>yes found it already, thanks <meo>how would I pass the context object to these methods? isn't using an implicit argument to a procedure a violation of functional purity? <meo>oh right pattern matching would be able to do that on syntactic level I guess <meo>well more homework to do, excellent <leoprikler>as for in-term, that would than be (call-with-term term (lambda (term) (for-each (match-lambda ...)))) <meo>oh yeah I saw that pattern <leoprikler>oh, but since you're using immutable records, you should (fold (match-lambda ...) term <quoted syntax>) <meo>then I can apply a top level syntax transformer to abstain from explicitly quoting the DSL calls <meo>I'm a bit too excited <leoprikler>actually... I think you can (fold (match-lambda ...) term quoted-syntax) directly <meo>I'm going to try it all out in the evening <meo>thanks tons for the advice <meo>any suggestions to using arrays inside an immutable structure? I basically spawn a new deep copy on every modification and it feels.. uncomfortable <leoprikler>if you can make do with lists, lists are typically wiser <leoprikler>otherwise I'd suggest using some functional data structures like fector <meo>list-ref isn't O(n) is it? <sneek>Welcome back wingo, you have 1 message! <meo>leoprikler: abstract character and attribute buffer <wingo>excellent debugging, civodul and flatwhatson :-) <wingo>so i guess we should release 3.0.7 today, wdyt civodul <meo>leoprikler: it's rank 2 <meo>I _suppose_ I could implement some data structure on top or just do something silly like a map hased by coordinates <tohoyn>wingo: what do you think about bug #45131? <meo>actually at this point I care more about correctness than performance <meo>the underlying structure is private and can be changed later <meo>maybe I should just implement it in C or something <civodul>i think we need to update NEWS for earlier fixes <meo>oh yeah speaking of which, one of the tests in guix causes guile to crash <meo>I need to isolate that... <leoprikler>since you need O(n) for copying, what exactly is the problem with using lists instead of vectors then? I assume the access, but if you're clever with your fold's you should have overall O(n) for your algorithms <wingo>tohoyn: sure can apply that one <tohoyn>wingo: could you inform me when it has been applied? <meo>leoprikler: im cheating by buffering the changes, anyway it's too early to consider this a problem <wingo>lloda: do you anticipate breaking chanes from the srfi-64 change? *wingo recalls quite a number of user problems from the last srfi-64 update ***ChanServ sets mode: +o wingo
***wingo changes topic to 'Welcome to #guile. See https://gnu.org/s/guile for more information. Guile 3.0.7 is out! <https://gnu.org/software/guile/news/gnu-guile-307-released.html>. This channel is logged, see <http://logs.guix.gnu.org/guile/>. Bug database at <https://bugs.gnu.org/guile>.'
***ChanServ sets mode: -o wingo
<wingo>release all done; the manual commit is taking time because fucking CVS <lampilelo>wingo: the change to srfi-64 fixes the bug introduced by the last one, if someone, in the meantime, wrote code that relies on that bug, it will break <wingo>omg what, are we going to have another round of people wondering why their srfi-64-based test suites fail??? <lampilelo>the problem with the last change was that the test runner was getting uninstalled every time the test group finished <lampilelo>this change makes it so the test runner is gettin uninstalled only if there was no test runner to begin with and the test group introduced a temporary one <lampilelo>it shouldn't have any side-effects other than fixing the bug, also i can take all the blame because it's my patch <lampilelo>i'm thinking about another fix to srfi-64 because there's a problem of test-group not working if you don't have a runner installed, i suspect people don't like srfi-64 for testing because of this kind of small bugs that prevent it from "just working" <wingo>compatible fixes that smooth user experience are golden <lampilelo>so you say there was a slew of people complaining but nobody made a patch! outrageous! ;) <lloda>i had to fix my own tests after the earlier srfi-64 patch, but i didn't have to do anything for the latest one fwiw ***rekado_ is now known as rekado
<mwette>meo: look at share/guile/3.0/module/language/cps/with-cps.scm <meo>thanks much appreciated <meo>I dont have the faintest idea how to test constructs like these <taylan>heya, is there an actual bug tracker for Guile? I was only able to find the mailing list archive, which can't give me a list of open reports if I'm not mistaken. <rekado>taylan: bug-guile@gnu.org is backed by debbugs <taylan>ah, thanks. for some reason Google was useless. ***sneek_ is now known as sneek
<taylan>does anyone happen to know where the module (system syntax internal) is defined? I can only find module/system/syntax.scm which uses it but doesn't define it. <taylan>ok, I found where the forms exported from the module are defined (in libguile/syntax.c), still curious how the module is defined though. <taylan>oh, doh, like 10 lines above where I looked :) <dsmith-work>Behold the mighty power of grep! (or ripgrep in this case) <sneek>Welcome back zimoun, you have 1 message! <sneek>zimoun, efraim says: changing the zstd test to use compression level 16 worked. I'll commit the change to core-updates. <zimoun>civodul: test-assert with with-exception-handler fails excepts if it is wrapped with call/cc. The exception is generated by raise-exception make-error. I guess, I miss something. Why does it work with call/cc and not without? <civodul>zimoun: do you have a specific example? <civodul>BTW, as a rule of thumb, never use call/cc except for SICP :-) <zimoun>a function that returns an exception (define-exception-type). This function is βnewβ gem->guix-package from Guix and we are trying to test β(gem->guix-package "do-not-exist")β <civodul>zimoun: so what about: (test-assert "xyz" 'exc (guard (c ((error? c) 'exc)) (gem->guix-package "does-not-exist"))) ? <civodul>there are quite a few tests like this <civodul>(note: Guix doesn't use the Guile 3 exception API yet) <zimoun>civodul: thanks. Is it a willing to not use Guile 3 exception API? Or can we add it for the new tests? <civodul>zimoun: for now we'll stick to srfi-34 or good'ol catch <civodul>(current Guix still builds with 2.2)