<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 - http://paste.debian.net/1100208/ <daviid>it segfault, but it clearly explains why ... <str1ngs>daviid: it's working now. will test more in the morning <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
<Tirifto>Hello all! Anyone got insight into the working of menus in guile-ncurses? <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" <Tirifto>Ah, so ncurses say ‘let's go with stdscr then’ upon funding #f, meaning ‘I don't know’, where a window is expected? <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). <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 <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>no idea, let me know when someone finds out :) <dsmith-work>There were tarball releases before then. guile-i guile-ii guile-iii (iirc) <janneke>dsmith-work: yeah, that's what i figured..now for the o and e :) <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 <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 <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... <jcowan>The cost is a lot higher, and since multiple values are second-class, they make things even harder <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. <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) <dsmith-work>Aren't there some incompatibilites between r6rs and r7rs? Like argument order on some functions? <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. <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. <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? <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 <manumanumanu>having _one_ buffer instead of creating a new one for each row (in guile-dsv) actually made my code slower. <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>we’re talking about speed here, right? :-) <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>(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!? <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? <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) <ArneBab>the main difference is box-set! vs. box-ref <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. <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>guile-dsv is now half as fast as python's csv parser, which is about 1200 lines of C :D <wingo>weinholt: just landed a patch to bind else, =>, etc <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? <jcowan>In today's world I can't imagine using anything else <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 <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>So, I will have a #:skip-header? keyword argument as well. <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 <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>as in swedish. In english I suspect it is quite old fashioned. <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.