<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. ***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
<xiews>lilyp: to avoid this mutable pair error <lilyp>setf does the same as list-set <lilyp>in other words it's destructive <xiews>But I got wrong type Argument error. <xiews>(list-set! '((1 2)) 0 '(2 3)) <lilyp>'((1 2)) is a compile-time constant <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. <xiews>chrislck: lilyp is the following OK? <stis>(define-syntax-rule (f x ..) #u8(x ...)) <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. ***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) <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. <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!)