<stis>\me is working on guile python again, trying to find bugs and follow spec as close as possible <stis>wondreing if I shall use type hints to improve speed as well <apteryx>seems to me like it should have been a let*-values or something <daviid>apteryx: the module uses srfi-71 ... <sneek>Welcome back manumanumanu, you have 1 message! <manumanumanu>apteryx: you should have a look at srfi-71. It is really neat. <janneke>spk121: ah good, this year's potluck is looking very nice *janneke is testing 2.2 compatibility... <janneke>hmm...no code for module (ice-9 copy-tree) <janneke>guess i'll have to patch it out for 2.2 <wingo>there is copy-tree in 2.2 in default env <janneke>yeah, upgrading to 3.0 gives a warning; so i blinly added a use-module <janneke>this 3.0 upgrade has been pretty smooth, considering how much has changed <janneke>and a factor 2 better performance for time-consuming scenarios, "for free", just terrific <spk121>wingo: did you check out janneke's mingw patch replacing all longs with scm_t_inum? should it be pushed? <apteryx>manumanumanu, civodul: I've now read srfi-71. It's great! Thanks for the pointers. <talin>hello. i am trying to figure out what are the main practical differences between guile and racket <talin>whether either of them have any particular limitations and such <davexunit>I'm not a racket user, but what I've observed is that racket has a bigger userbase, more libraries, and their own IDE. <davexunit>that said I still like Guile more, personally. <davexunit>it has more of a minimalist vibe and we have the Guix project which is amazing. <civodul>wingo: i've just pushed two minor improvements to (web client), taken from Guix <wingo>civodul: great. now do NEWS :) <wingo>no good deed goes unpunished, etc ;) <civodul>wingo: heh :-) it's not even NEWS-worthy though, it's not "user-visible" <davexunit>does anyone know how to reliably integrate srfi-64 tests with automake? I'm updating an old project written during the guile 2.0 days and what used to work no longer does. the tests themselves are fine, it's the exiting with a proper status code to tell automake if the tests passed/failed that is unreliable. <wingo>spk121: haven't looked at it yet, but i would like to :) <civodul>davexunit: you can take the "test driver" from build-aux/ in Guix <wingo>davexunit: did you see that somethign changed in 3.0.5 ? <civodul>apteryx tweaked it recently and it's become pretty flexible <davexunit>I can get 'make check' and 'make distcheck' to pass locally, but then I tried building in guix and 'make check' fails because of an exception that is unrelated to the tests themselves. like srfi-64 is behaving differently for some reason. <wingo>there was a fix to make the test runner comply with the spec which sadly broke lots of users <wingo>davexunit: do a git log and grep for srfi-64, you'll find it <davexunit>wingo: was it commit de5d1a7f99b8e952b115237ebc29633062f99bb9 <davexunit>"Fix bug #42713: srfi-64: Reset test-runner-current if done" <apteryx>daviid: congrats for the guile-lib release! <davexunit>I used to rely on calling (test-runner-current) after (test-end "foo") to get the results, but now that returns #f. then I discovered that test-end returns the test runner, so I wrote a test-end* that calls test-end and then exits with status code 0 if the tests passed. that works locally. <davexunit>but when guix runs make check, test-end returns unspecified and all the tests fail as a result. <davexunit>civodul: I looked at that test runner but it was quite complex <civodul>davexunit: true, but consider it a black box ;-) *civodul isn't used to giving that type of advice <davexunit>I didn't really understand everything it was doing so I didn't want to add more confusion on top of my existing confusion. <davexunit>I'm having trouble finding the right way to check test runner results once all tests have been completed. <davexunit>every way I try breaks in a different context for mysterious (to me) reasons <davexunit>here I was thinking I was making a quick update to an old project ;) <apteryx>davexunit: I've already swaped out lots of details, but if you need to inspect test results post test run, perhaps you could look into the .trs files? ***`micro_ is now known as Guest13676
<davexunit>apteryx: that seems like the wrong layer. I want to inspect the srfi-64 test runner within guile so I can return 0 upon success or 1 on failure. <apteryx>Then you have to do so before calling test-end, persist that value, and return it post test-end <apteryx>I had to do something like this for some guile library, I forgot which one, let me try to find it out <tohoyn>talin: IMHO GOOPS is better than Racket's object system <davexunit>apteryx: so that's what I thought I had to do, but it doesn't work in all contexts as far as I can tell <davexunit>but if it's working for guile-ssh then maybe something else is wrong <davexunit>apteryx: a-ha! I found the issue. thank you for showing me that this strategy works. <davexunit>it was an issue in something completely unrelated that wasn't obvious in the error messages I was seeing <davexunit>I forgot to include my test wrapper script in the release tarball -_- <apteryx>does wrapping a multi values returing procedure with lambda* transparently passes on these values? Seems not. <tohoyn>why is it so that a lambda in tree-il has to consist of lambda-case definitions? <davexunit>lambda* is for optional args and keyword args, it doesn't do anything special with multiple return values. call-with-values and let-values are your friends for this. <tohoyn>would it be more efficient if lambda consisted only of a single procedure body? <davexunit>apteryx: feel free to share example code and I can take a look if you're still stuck <wingo>tohoyn: in terms of compuied code? doesn't matter a whole lot with guile's current compilation strategy. a procedure needs to check its arg count, and if the count is unexpected, jumping to the next case is just as cheap as throwing an error <wingo>but it would be nice if we could skip arg count checks in many cases. unless a function is contified, we don't do that right now <tohoyn>wingo: yes, I meant the efficiency of compiled code <davexunit>let-values may read a bit nicer than receive <lloda>with srfi-71 it almost always reads cleaner than either let-values or receive <lloda>only with a rest arg (let (((values a . b) f) ...)) looks worse <lloda>also apologies for the srfi-64 breakage :-/ <lloda>what i do myself is (define error-count (test-runner-fail-count (test-runner-current))) <lloda>crude i suppose but it works <davexunit>srfi-64 to me feels like low-level infrastructure that needs a friendly wrapper <davexunit>I wish it was Schemier. like a set of combinators that can be composed to form a test suite that you then pass to a test runner. <apteryx>is there no non-capturing group support in libc (Guile)'s implementation of regexp? such as (?:something|something-else) <davexunit>rlb: that's essentially what I did. I've now seen at least 3 different versions of this same concept. :) <davexunit>as if I needed another project (can't even maintain the ones I already have properly), I want to make a testing library that is actually good. <jlicht>davexunit: you are an amazing maintainer! We just need there to be 6 of you :) <apteryx>dsmith-work: thanks about irregex, didn't know about it <davexunit>I've been pretty burnt out for the last couple of years ***Noisytoot is now known as NOISYTOOT
***NOISYTOOT is now known as VERYNOISYTOOT
***VERYNOISYTOOT is now known as Noisytoot
***sneek_ is now known as sneek