<rlb>So if all read options are completely global, how do you get the current value of a read option for use in a dynamic-wind to restore the original value? <rlb>(I mean, ignoring the newer port-specific options.) <rlb>...and to answer my earlier question about the reader -- looks like you might use dynamic-wind along with (read-options) to save the current settings, and (read-options previous-result) to restore them. <rlb>Unless I missed it, the docs don't say anything on the topic, i.e. I found it in options.c (had forgotten about that). If I get time, I may see about a doc patch, at least for the reader, if not for the broader subsystem described in options.c. ***Server sets mode: +nt
<wingo>rlb: hey good catch and fix! <wingo>please feel free to push, the patch looks great <lloda>"ice-9/boot-9.scm":1656:16: In procedure raise-exception: <lloda>I mean, every time there's an error somewhere, the source line is that one in boot-9 <lloda>you need to ,bt to have a clue where the error was at all <lloda>I don't remember that happening before <lloda>it's not a big deal or anything <wingo>the answer of course is that yes we can fix this :) <lloda>/home/danielo/sys/obj/guile3/x.scm:1:0: ? <lloda>while on 2.9 you'd get the raise-exception line from boot-9 instead <lloda>I mean x.scm is just one stack frame up, so it's there <lloda>but it's worse than before I think <civodul>looks like something broken in the test infrastructure, but i can't see what <artyom-poptsov>I saw that with the latest Guile versions some test fail due to strange (mis)behaviour in tests when two references to one procedure are compared and they're looking different to Guile although should be the same (as it was in older Guile versions.) <civodul>like (eq? (lambda (x) x) (lambda (x) x)) might be true, or it might be false <civodul>anyway, there's something else going on here :-) <civodul>so no hints in the test-suite.log i pasted above? <artyom-poptsov>Maybe I'll try to run tests again this evening and see what will happen. Should I consider 2.2.6, or other Guile version? <artyom-poptsov>Okay. This means I have to re-write some tests. What is the right way to compare procedures then? <wingo>it's really quite unspecified :/ <wingo>like (eqv? x x) may be #f, if x is a procedure, afaiu <wingo>but if you are asking for a workaround, you can change to have the logging handler be defined not at the top-level but rather lexically (within a `let') <civodul>wingo: i think these tests are fine though: they amount to (set! x proc) (eq? x proc) <wingo>in practice i think what is happening is that the references to the declarative binding `proc' are getting eta-expanded <wingo>to (lambda (...) (proc ...)) <wingo>allows proc itself to be contified within the compilation unit <civodul>but anyway, that's with 2.2 and i think it's evaluated, not compiled <wingo>which is precisely why procedure equality is unspecified in scheme <wingo>civodul: i think artyom-poptsov mentioned "latest guile versions" so i assumed 2.9.x <nerdypepper>seems to occur only when i pass 'and' as the argument to the 'accumulate' function <nerdypepper>i ran the program with `guile -l sets.scm`, if that matters <wingo>nerdypepper: it's a not-great error but the issue is that and is a macro, not a function <wingo>i.e. (and #t (error "what")) never evaluates the error ***wxie1 is now known as wxie
<nerdypepper>is there anything i can do to pass 'and' as a function? <wingo>nerdypepper: (lambda (x y) (and x y)) *janneke is fighting with `make TESTS=tests/peg.test' SCM_TESTS=... etc <janneke>there must be a way to run a single test <janneke>hmm, guile-test is executed from libguile, not inside test-suite <lloda>is that ./meta/build-env test-suite/standalone/test-etc janneke ? <janneke>lloda: thanks, no not standalone; test-suite/tests/peg.test, e.g <janneke>runnig `guile-test' apparently, looking to see if that is parameterized <janneke>../build/meta/guile -L ../module -C ../build/module -C . -L . -e main guile-test <rlb>wingo: ok, thanks -- now we'll see if I really still can. What's the convention, should I just push that to master? (Looks like there are merge-ups, but not recently?) <janneke>ha, this works: cd test-suite; ../build/meta/guile -C . -L . -e main guile-test tests/peg.test <rlb>Also, I wasn't sure if my commit message was OK, i.e. I didn't include ChangeLog style entries, but I can try to add those if that's preferred. <wingo>rlb: yes please rebase and push on master <wingo>i mean rebase the patch on top of master obvs <janneke>trying to upstream some peg enhancements...no promises yet <rlb>wingo: ok, and cherry-pick it to stable-2.2 too, or just leave it out there? <jcowan>In R5RS and R7RS, procedures have location tags that are set (behind the scenes) when a closure is created; they might be the address of the closure object in memory. R5RS requires both eq? and eqv? to return #t if its arguments have the same location tag; R6RS has no notion of location tags; R7RS compromises and requires eqv? to return #t but leaves the behavior of eq? open. <jcowan>This was done in R6RS to allow compilers to transform references to a procedure in object position to lambdas, but it interferes with things like a procedure which takes an argument that is either +, -, *, or / (say) and dispatching on it. <wingo>rlb: i would think it's fine to cherry-pick, as long as you are sure the bug is present there