IRC channel logs

2020-07-01.log

back to list of logs

***jonsger1 is now known as jonsger
<dsmith>sneek: later tell R1ck77 The channel is often slow. Just wait a day or two...
<sneek>Okay.
***jonsger1 is now known as jonsger
<dsmith>sneek: later tell R1ck77 https://www.gnu.org/software/guile/manual/html_node/Conversion-to_002ffrom-C.html
<sneek>Got it.
<dsmith>sneek: later tell R1ck77 Use free()
<sneek>Okay.
<RhodiumToad>wklew: it's easy to show that the reset is evaluated before any shift.
<RhodiumToad>my first guess is that the storing of the first forced result of the evaluation of the stream is itself part of the continuation at this point.
<RhodiumToad>similar thing happens with delay/force from srfi-45 (can't do it with builtin delay/force because force isn't rewindable)
<wklew>RhodiumToad: ahh that complicates things
<wklew>I think storing thunks in the stream will be the cleanest solution
<wklew>otherwise I'd have to rewrite all the streaming functions to reset each element anyway
<wklew>thanks for the help!
<RhodiumToad>shift/reset can be a bit brain-bending
<wklew>for sure! been spending a lot of time with oleg's papers and such
<wklew>I'm trying to translate his ocaml library for probabilistic programming to guile
<wklew>oleg kiselyov that is
<RhodiumToad>I know which oleg you meant :-)
*RhodiumToad also read their stuff on shift/reset when learning about it
<RhodiumToad>not to mention the whole business of finding a ~20-year-old bug in their code
***sputny1 is now known as sputny
<rlb>Is this expected to work? https://paste.debian.net/hidden/871c70cc/ It hangs here if I uncomment the (touch err). But it's fine if I just use open-output-file to create err. i.e. it doesn't seem to like a (pipe).
<RhodiumToad>a system-call trace will probably make it pretty obvious what the problem is.
<rlb>RhodiumToad: heh, not (yet) obvious to me, but thanks for the suggestion.
***catonano_ is now known as catonano
<wklew>RhodiumToad: now I'm curious what/where the bug was
<RhodiumToad>rlb's bug? I don't know, I haven't see the trace :-)
<wklew>no sorry, we were speaking of oleg's code
<RhodiumToad>oh
<RhodiumToad>ssax parser screws up on CDATA
<RhodiumToad>a misreading of the spec which results in corrupted data
<wklew>oh
<wklew>good catch :)
<RhodiumToad>and I don't think the xml people anticipated that anyone could misread it in that specific wrong way, so there is no test for it in the xml validation suite
***sneek_ is now known as sneek
<dsmith>sneek: botsnack
<sneek>:)
***apteryx is now known as Guest83291
***apteryx_ is now known as apteryx
***bjoli is now known as manumanumanu
<manumanumanu>Hi folks
<sneek>Welcome back manumanumanu, you have 1 message!
<sneek>manumanumanu, wklew says: cool, that's interesting too!
<manumanumanu>:D
<manumanumanu>So, does anyone know of any newer research into optimizing pattern matchers than Balland 2006? I am finally writing an optimizing extensible pattern matcher, and I think i have most of it nailed down.
<manumanumanu>(Balland et al. of course)
<manumanumanu>I believe I can leave out a lot of the work their pattern matching optimizer does, since guile already does constant propagation, inlining and let fusion... I suspect it will be a _lot_ more simple to do in guile than in SML
<manumanumanu>hmmm. the problem when writing a pattern matcher is that you want a pattern matcher
<leoprikler>Instant pattern matcher, just call another pattern matcher ;)
<leoprikler>Balland et al. refers to "Optimizing pattern matching compilation by program transformation", right?
<mwette>I'm adding an option to Guile's configure.ac, how do I get an associated variable defined in config.h.in?
<leoprikler>mwette: AC_DEFINE?
<mwette>leoprikler: Thanks. Found it I think.
<mwette>Yes, it's working now. Thanks.
<manumanumanu>leoprikler: yes! I am not in academia or anything, but to me it seems like the latest and greatest in pattern matching compilation.
<leoprikler>Well, to be fair, it's not cited by a great number of other papers, so there have probably been little improvements since.
<manumanumanu>I actually found that the common lisp pattern matcher trivia uses it, and that produces excellent output. I haven't been able to make it produce worse-than-hand-tuned for most of my cases. For simple cases like ((a b 2 d e) ...) (a b 3 d e) ...) the code is a lot better than what (ice-9 match) produces. With all the work the guile optimizer does, I doubt we can actually do much better than the suggested
<manumanumanu>Balland, since we can just leave all the really hard parts to guile
<manumanumanu>On a similar note, does anyone know of any predicate-based generic method library that plays well with modules? (i.e: a method defined in module a should not be visible in module b unless it is explicitly imported)
<manumanumanu>It removes the possibility to specialize types, but I suspect it could be a lot simpler (and faster?) than, say, goops if all you want is simple generics that play well with regular records
<justin_smith>manumanumanu: I briefly played with the idea of using a lambda closing over a hash table, accepting "message" based dispatch, eg. a message #:extend to add a dispatch target, a message #:invoke to send a dispatchable value to a target, etc.
<justin_smith>I should take another go at that
<justin_smith>also explicitly lacking the ability to magically wrap any external or built in function or do meta level mainpulations
<justin_smith>that plus afew macros should go pretty far
<justin_smith>but I doubt it's a unique idea and hope somebody else made it and I can just use their lib
<manumanumanu>justin_smith: well, did that work well with the module system? Otherwise, I would probably just use chibi's implementation. That is elegant enough.
<justin_smith>manumanumanu: I only played with it briefly and don't have a version I'm happy with yet - I'll look at chibi's version
<justin_smith>manumanumanu: the difference between my approach and chibi's is that chibi does linear lookup which allows "next method" / arbitrary predicates, and mine was a single dispatch function with a hash - speed vs. inheritance
<justin_smith>mine would respect modules, as it generates a function belonging to a single module, just because you extend it doesn't mean it belongs to you
<manumanumanu>But if you have a method named banana in module a, extend it in module b, then import module a in module c, which banana is visible in module a?
<justin_smith>the method is a lambda belonging to the module that defines it, you can make a special call to add a dispatch key and function for that key, but that doesn't affect its visibility or ownership
<justin_smith>the reason it isn't done is not being satisfied with the conventions for calling it, which I want to have first before writing code that relies on it
<justin_smith>but I expect the final code to be smaller than the amount I've written about it in this channel so far, I am aiming quite low
<manumanumanu>I don't understand, but please ping me if you ever finish it :D
<justin_smith>manumanumanu: sure thing!