IRC channel logs


back to list of logs

<daviid>str1ngs: I think I fixed the bug you reported, could you pull and try? please note that you _must_ get the iter after you modified the buffer content, otherwise it will also segfault, here is an example which works now -
<daviid>str1ngs: here is example that fals, unfortunately with a segfault, when the iter is invalid -
<daviid>it segfault, but it clearly explains why ...
<str1ngs>daviid: it's working now. will test more in the morning
<daviid>ok, good
<str1ngs>thanks, I'm getting close to removing most of my SCM_DEFINE's :)
<str1ngs>daviid: I noticed some critical console error message like. CRITICAL **: 00:02:21.365: g_object_info_get_n_properties: assertion 'GI_IS_OBJECT_INFO (info)' failed which are recent. I don't think they are related to the iter issues
<daviid>good to hear, but let's not 'rush', there are still corner cases ... and missing bits ... but hopefully g-golf will get 'there' ... tx for your help and patience ...
<str1ngs>I'll look more into what code is cause the critical errors make sure it's not an issue on my end.
<str1ngs>daviid: not a problem. this helps me out just as much
<daviid>hum, these msgs should only occur at 'gi-import' time, no?
<daviid>what is the namepace that trigger those?
<str1ngs>possibly , but it's kinda late for me to look into it. I'll check first thing in the morning
<str1ngs>I'll check this first thing and report back. thanks for the iter fix
<str1ngs>on a pure scheme note, I've been playing around with macro's and trying to reason out writing a DSL. do you know if its possible to expand a atom or symbol using a macro. or would that require a reader?
<daviid>str1ngs: I am not a syntax (very) knowledgeable person, Ill let others answer those quiz ...
<str1ngs>understandable maybe I should ask in #scheme. your tail recursive loops in g-golf have been educational. the pattern is a nice way to avoid using set! within lets
***paroneayea is now known as dustyweb
<dsmith-work>Morning Greetings, Guilers
<lloda>hi dsmith-work
<Tirifto>Hello all! Anyone got insight into the working of menus in guile-ncurses?
<spk121>Tirifto: I know a bit about it
<spk121>what's up?
<Tirifto>spk121: Ah! Do you know if a menu is supposed to have its associated menu set to #f by default, and if the rest of ncurses assumes ‘stdscr’ upon encountering #f in that context?
<spk121>Tirifto: I don't think that is how it is intended to work. The underlying ncurses menu functions encourage you make a window and subwindow for your menu that are appropriately sized. But if you just call post-menu w/o setting up those windows it will draw to stdscr.
<Tirifto>spk121: I see. When I create a menu and don't assign a window to it, (menu-win the-menu-in-question) just returns #f.
<spk121>Yeah. #f meaning the C function returned NULL. NULL meaning that no window was assigned to the menu. So #f doesn't mean stdscr, it means "i don't know"
<spk121>which is, in effect, stdscr
<Tirifto>Ah, so ncurses say ‘let's go with stdscr then’ upon funding #f, meaning ‘I don't know’, where a window is expected?
<spk121>I believe so.
<Tirifto>Okay, that makes sense. Thanks!
<Tirifto>If my Guile Scheme program has functions with only constants as inputs in it (or other functions as input, which in turn only have constants as input), which may get called multiple times, are they going to be reevaluated on every call, or will that be optimised out? (Just wondering if I should worry about this much in the program design.)
<ArneBab>manumanumanu: arg, yes, you’re right. I did not see that either, so nothing to be embarassed about!
<ArneBab>manumanumanu: dsv sounds interesting — parsing csv files is famous for being hard to do exactly right, and having something which just works would be great
<ArneBab>Tirifto: they will be re-evaluated, but you can easily wrap them to add a cache (so you can retrofit that if you find that you need it).
<chrislck>Tirifto: look up memoization
<Tirifto>ArneBab, chrislck: Thank you!
<janneke>chrislck: what's the reason for not using ice-9 poe?
<chrislck>janneke: umm because I've never encountered ice-9 poe before, and it looks horribly complex... anything wrong with mine?
<chrislck>guile modules are not always named very well
*civodul didn't even know (ice-9 poe) was about memoization
<civodul>i've definitely seen it before, but it's one of these modules that came from another era
<civodul>with a not-so-descriptive name :-)
<chrislck>yeah could have been power-over-ethernet in guile
<janneke>chrislck: nothing wrong, just seems similar :)
<janneke>iwbn if it had a nicer name (ice-9 memoization) or so and included some lambda memoization goodies from guix
<janneke>and was documented in the manual ;)
<civodul>heh :-)
<civodul>any idea why it's called "poe"?
<civodul>i must be missing a reference
<janneke>no idea, let me know when someone finds out :)
<dsmith-work>Pretty sure the #\p is is for "pure".
<civodul>it was apparently written in 1996 or before, first commit in the repo:
<civodul>it's like visiting the attic
<dsmith-work>There were tarball releases before then. guile-i guile-ii guile-iii (iirc)
<janneke>dsmith-work: yeah, that's what i for the o and e :)
<dsmith-work>Tom Lord eh?
<spk121>looks like Mikael Djurfeldt was the last one to make a functionality patch to poe.scm in 1996
<civodul>if Mikael is around next FOSDEM, we should discuss it :-)
<jcowan>fwiw there is a Perl hacker named Chris Poe who's been involved in memoization
<manumanumanu>ArneBab: oh, yes, but I am just now writing some tests, and managed to crash the csv parser instantly :D
<spk121>so (ice-9 poe) was not in guile-ii from 1995, but, was last functionally patched in 1996. I couldn't find the old RCS files, so that's as far as I can go, I guess
<enderby>what does ice stand for btw?
<Tirifto>Modules from the water-9 group after a feature freeze?
<spk121>enderby: well, if I recall correctly, the ice-9 from Kurt Vonnegut's fiction was supposedly so cold that froze anything it touched, so kind of always expanding. And the original intention of ice-9 was that is where it would absorb all the new libraries, like the ice-9 of fiction.
<spk121>So it is just a dumb joke from the 1990s
<enderby>icic, thanks!
<jcowan>not to be confused with actual ice IX, which was discovered later
<manumanumanu>Hmmm. why is it implemented like that? Guile can hash lists, so you can just use a hash table with the args as the key...
<manumanumanu>i have a define/hash which is just a 6 line macro.
<jcowan>The cost is a lot higher, and since multiple values are second-class, they make things even harder
<manumanumanu>define/memoized i mean
<jcowan>with an equal? hashtable?
<jcowan>imo it is worthwhile having fast paths for 1-arg 1-value and many-args 1-value
<jcowan>and leave the many-value case to those who really need it
<enderby>is it not possible to load r7rs in guile yet?
<amz3>enderby: no with master, but maybe with r7rs-wip branch it works?
<ArneBab>sp1ff0: I don’t think that the joke is bad :-)
<ArneBab>enderby: the argument is that ice-9 crystallizes everything, so it’s a perfect seed for Guile.
<manumanumanu>soon, everything will be guile
<ArneBab>But it’s been discussed (and not objected to) to alias it as guile or so.
<ArneBab>(that’s my last information at least)
<ArneBab>enderby: here’s some additional stuff which might help you get started:
<enderby>ArneBab: ty
<dsmith-work>Aren't there some incompatibilites between r6rs and r7rs? Like argument order on some functions?
<dsmith-work>Such that you can't be both r6 AND r7 ?
<manumanumanu>a lot of r7rs can be implemented portably in r6rs, but there are some reader incompatibilities iirc.
<jcowan>Only one function (bytevector-copy!) has significant arg-order issues. R6RS/R7RS systems have to give them different names if both libraries are loaded.
<jcowan> <-- Will Clinger's paper on adding R7RS to Larceny, which is non-strict R6RS.
<jcowan>It goes into plenty of detail.
<str1ngs>sneek: later tell daviid. the critical console log error I mentioned last night. Was an issue with nomad selectively importing a non existing info object. So nothing to worry about in terms of g-golf.
<sneek>Got it.
<manumanumanu>Anyone knows why set! is slow in guile? In chez, any set! value is boxed, which adds overhead. Does guile do something similar?
<dsmith-work>manumanumanu: set! mutates. It's slow by design so you avoid it!
<dsmith-work>manumanumanu: Actually, my understanding is it really adds some constraints to the optimizer.
<manumanumanu>But why is it slow by design? I understand that it can make it a lot harder for the compiler to reason about what the code does. Why is mutation slower in guile than in a notoriously mutating language like python?
<dsmith-work>Oh, I was just being silly about "by design".
<ArneBab>manumanumanu: is it slower than in Python or only slower than other parts of Guile?
<dsmith-work>manumanumanu: Back in the "old days" of guile, like 1.4, 1.6. I was able to make some code *faster* by mutating.
<manumanumanu>ArneBab: adding mutation to avoid about 100000x (make-string 20) actually made my code slower
<dsmith-work>Because it was gc-ing a whole lot less.
<dsmith-work>Before the compiler.
<manumanumanu>having _one_ buffer instead of creating a new one for each row (in guile-dsv) actually made my code slower.
<manumanumanu>Not by much
<manumanumanu>but still.
<manumanumanu>Whatever happened ate the performance benefits of not allociting a new string for each row
<ArneBab>manumanumanu: allocating can be really cheap if you have enough memory
<ArneBab>manumanumanu: and here is why: (define foo (map (λ(x) (make-string 20)) (iota 100000))) → adds just 22MiB of memory
<ArneBab>(from 18 MiB to 40 MiB)
<ArneBab>and from 130 VIRT to 219 VIRT
<dsmith-work>("just" 22M of memory!)
<ArneBab>we’re talking about speed here, right? :-)
<ArneBab>100k strings, each 20 characters
<ArneBab>if each character required only one byte, this would still consume 2 MiB.
<ArneBab>to test easily: run guile in one terminal, then open another terminal with `top -p $(pgrep guile) | grep guile` and
<ArneBab>now you can experiment with how much memory this takes
<ArneBab>a single string with 2 million chars takes 11 MiB
<ArneBab>(define foo (make-string (* 20 100000)))
<ArneBab>so the overhead of string delimiting and the cons cels of the list increases the memory by roughly factor 2
<ArneBab>manumanumanu: so you likely only threw 11 MiB into the garbage collector
<ArneBab>which it likely happily ignored
<ArneBab>because you had enough left over
<ArneBab>(we’re far from the low level optimizations here for which L2 cache-hits actually matter)
<manumanumanu>That I understand. But why was it slower having _one_ string that I grow using set!?
<ArneBab>how did you grow it?
<manumanumanu>I do the same thing now if one field is too large: make a new string that is twice as long and copy the contents.
<manumanumanu>the difference was that I either had the string in the closure that encapsulates the reading procedure, or that I sent a new string along for each line.
<ArneBab>I don’t know enough about the string representation in Guile to say it with certainty
<ArneBab>^ that’s what’s left over after I deleted everything I wasn’t sure about :-)
<manumanumanu>I don't think it has anything to do with that. I think set! is the criminal, but why?
<ArneBab>dsmith-work: is it possible with Guile to actually see the difference of hitting L2 caches? I did that with Fortran once ( ) and I’d like to know whether we can get that 3-5x speedup in Guile, too.
<manumanumanu>I have a decent idea of what is fast and why. But this I don't understand
<ArneBab>maybe you can see it with (define foo)
<dsmith-work>ArneBab: wingo would know.
<ArneBab>,disassemble (λ() (set! foo 5))
<ArneBab>,disassemble (λ() (make-string 20))
<ArneBab>the main difference is box-set! vs. box-ref
<jcowan>Ah, another Fortran fan!
<jcowan>Fortran was the first computer language I learned and wrote programs in, though not the first in which my programs actually executed.
<ArneBab>jcowan: I’ve been the opposite, but roughly 3 years into my PhD I realized how wrong I was. It’s still outdated, but I now consider it the most unfaily underappreciated language.
<jcowan>Maybe Lisp (in all its forms) too.
<ArneBab>though Lisp has this air of superiority around it (and people consider it as too crazy), while Fortran has a bad reputation as this language everyone hates
<ArneBab>until a Pythonista (me) realizes that numerical code in Fortran actually looks more Pythonesque than Python-code with numpy.
*jcowan chuckles
<wingo>manumanumanu: guile does the same thing as chez for assigned variables (boxing)
<wingo>the name of the pass is "assignment conversion" fwiw
<wingo>it's done as part of tree-il->cps compilation
<manumanumanu>I had just disassembled it and had started getting familiar with the instruction set :D
<wingo>optimizations are possible (for non-escaping vars we could do a kind of ssa transformation) but not implemented as most guile programs aren't set!-heavy
<manumanumanu>I just thought: I am mutating the string. It is already thread-unsafe. It was a clear optimization
<manumanumanu>at least until I benchmarked :D
<manumanumanu>Good to know!
<manumanumanu>guile-dsv is now half as fast as python's csv parser, which is about 1200 lines of C :D
<jcowan>What are guile-dsv's options?
<wingo>weinholt: just landed a patch to bind else, =>, etc
<wingo>in master anyway
<manumanumanu>jcowan: separator, newline, escape char and trim?
<manumanumanu>or at least, soon it has trim? again.
<jcowan>Is newline respected on output only? I hope so (i.e. on input any newline will work)
<weinholt>wingo, cool; i'll need to start trying it out
<jcowan>Does trim? ignore escape-space sequences?
<manumanumanu>jcowan: it has #:newline 'lax :D
<manumanumanu>which supports CR, LF, CRLF and CR<EOF>
<jcowan>In today's world I can't imagine using anything else
<manumanumanu>escape-space sequences?
<jcowan>i.e if you have "foo\ , bar" with trim on, does that reduce to "foo " and "bar"?
<manumanumanu>It does not support escape characters outside double quoted strings
<manumanumanu>that will be a row like #("foo\\" "bar")
<jcowan>Oh, double quotes!
<jcowan>my current design (not yet filled out, never mind implemented) distinguishes between csv-per-the-RFC and dsv (one line each, single-char escape)
<manumanumanu>It supports that spec I believe.
<manumanumanu>but no headers yet!
<manumanumanu>I had forgotten about that.
<manumanumanu>So, I will have a #:skip-header? keyword argument as well.
<manumanumanu>at least until I support headers and dsv->hash-table :D
<manumanumanu>oh my, it has gotten late again.
<manumanumanu>Now I need some sleep.
<weinholt>that's just a myth
<weinholt>you need more coding
<manumanumanu>I am a grass widower until sunday. My life has fallen apart around me. I spent two nights coding and can't take it tonight :D
<dsmith-work>What is a "grass widower" ?
<weinholt>gräsänkling, swedish expression i guess, basically means your spouse is on a trip
<manumanumanu>weinholt: strohwitwe in german, grass widower in english
<manumanumanu>but probably not a common english expression.
<manumanumanu>In german it is pretty well known.
<manumanumanu>as in swedish. In english I suspect it is quite old fashioned.
<manumanumanu>jcowan: if you want to check guile-dsv out, you can find it here Apart from the keyword stuff, and that I am using substring/copy it should be easily portable.
<jcowan>manumanumanu: Nice. I'll look at it in more detail later.
<jcowan>I would change reader to generator
<jcowan>also, is there any chance of having a more liberal license? The license of SRFIs is basically BSD.