IRC channel logs


back to list of logs

<stis>the drawback is that the code need to change when guile changes the bit layout. but it is a superfast type dispatch
<daviid>ArneBab: my point is everything you describe, and somuch more, is handled by guile-dsv
<ArneBab>daviid: doesn’t guile-dsv do a lot more?
<daviid>that's what i just said? :) 'and so much more ...', just grab and use it ...
<nckx>dsmith-work: Is sneek amenable to join other channels, or does this make their overworked owner groan?
<nckx>Those are the only choices.
<nckx>sneek: botsnack
***dostoevsky0 is now known as dostoevsky
***dostoevsky6 is now known as dostoevsky
***dostoevsky9 is now known as dostoevsky
***dostoevsky3 is now known as dostoevsky
***dostoevsky0 is now known as dostoevsky
***dostoevsky6 is now known as dostoevsky
<xiews>Is there anything else to replace list-set! ?
***dostoevsky1 is now known as dostoevsky
<lilyp>xiews: in which sence?
<xiews>lilyp: to avoid this mutable pair error
<xiews> like setf
<lilyp>setf does the same as list-set
<lilyp>ahem, list-set! in Scheme
<lilyp>in other words it's destructive
<xiews>But I got wrong type Argument error.
<lilyp>full context please
<lilyp>use if you need to share code
<xiews>(list-set! '((1 2)) 0 '(2 3))
<lilyp>yeah that won't work
<lilyp>'((1 2)) is a compile-time constant
<xiews>So I cannot change it?
<chrislck>xiew: '((1 2)) and (list (list 1 2)) are the same except the first is immutable
<ArneBab>daviid: I think we’re talking past each other because I never said *why* I looked for that. In the Advent of Code i found that getting data input in Guile felt kind of cumbersome, so I’m looking for the smallest change that makes a serious impact.
<ArneBab>daviid: this here is a powerhorse but I would like to find 5-10 lines of Scheme could already improve many common cases.
<xiews>chrislck: lilyp is the following OK?
<xiews>(let ((a (list-ref b 1)))
<xiews>(list-set! a 0 (list 1 2)))
<stis>(define-syntax-rule (f x ..) #u8(x ...))
<stis>does not work
<stis>I've speed up write 2X using the scheme printer
<ajarara_>Howdy! I used to be able to load (gnu) in the guix source set, but now I get a boehm GC error (Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS). Anyone ran into this? Posted here instead of #guix because it feels like the solution is to recompile guile.
<unmatched-paren>ajarara_: looks like an OOM?
<unmatched-paren>or at least too much memory for libgc to handle
<unmatched-paren>i think that happens when variables have circular dependency
<ajarara_>Hmm.. alright. I'll try another base.
***ajarara_ is now known as ajarara
<daviid>ArneBab: but 'out of' this advent of code, that is in real life :), you would not rewrite 10 lines of code when you have such a well written and maintained tiny lib, no dependencies, that compiles and instaall in seconds, and does exactly what you need, and much more ...
<daviid>like (map your-proc (dsv->scm (open-input-file your-file))) [it will even guess the delimiter if you don't pss it] - what you say doesn't make much sense to me, it is as if you say 'i am going to rewrite (ice-9 match), because i only need 'a few simple patterns' ...
<daviid>anywy, no problem, do as you wish, i just disagree with this approach 'i am gona a rewrite a mini dsv lib ...', the one we have is too powerfull ...
<ArneBab>daviid: it doesn’t do exactly what I needed, that’s the point. It is much better if the goal really are delimiter-separated files. But the goal was — over and over again — some style of line-based format. One was „split a line into numbers“, the next was "split a line first by |, then by space", then one “parse parentheses per line”, then “just get each line”, and then one “split by -”. Half of these would have been
<ArneBab>perfect matches for dsv->scm, the other half not.
<ArneBab>The common thing was that they operated on lines, not that they split the lines by something.
<ArneBab>And yes, the code of guile-dsv is beautiful.
<ArneBab>But the one thing that was missing to make parsing not-painful was a plain map-over-lines.
<daviid>ArneBab: hum, maybe there is waay to pass a 'special char', so dsv would not split the lines, don't know
<daviid>i think guile-dsv should make it to guile core or guile-lib if not in guile-core
<ArneBab>The point is that “operate on this file line-by-line” is a primitive missing in Scheme.
<ArneBab>And I also think guile-dsv should be in guile
<ArneBab>(ice-9 dsv) would be a good module location, I think
<ArneBab>daviid: 6 out of 12 examples were a good fit for map-over-lines. 4 could have been solved nicely with guile-dsv, too (one of them not a good fit for map-over-lines, because it used just one single line of input).
<daviid>ArneBab: it does, try (dsv->scm (open-input-file "/etc/passwd") #\null)
<daviid>*it does permit a 'no split'...
<ArneBab>Does it also have "split line into chars", "turn line into vector of numbers", "tokenize by non-equal number of words", "count the words", and "get letters as numbers"?
<ArneBab>Those are the non-obviously-dsv operations I needed on the lines.
<daviid>those are your proc
<ArneBab>yes, the proc I passed into map-over-lines
<daviid>just feed map, using dsv, my point is i disagree with a scheme op called map-over-line, i am off this conversation now, need to hack :)
<ArneBab>(add one "split by -" which obviously would be better fit with guile-dsv and "just get the lines" for which map-over-lines is oddly ill-suited)
<ArneBab>ok — have fun! (that’s definitely more productive than arguing here; I should do the same. Thank you for stopping before this went even more out of hand!)