IRC channel logs


back to list of logs

<nalaginrut>oh, 2.2 is coming finally
<nalaginrut>lloda: just finished compilation of guile-tjit with gcc-6.3 successfully, now it seems not GCC's problem
<nalaginrut>ACTION rebased the latest master, smoothly
<lloda>nalaginrut: yeah, I didn't think that was it :-/
<lloda>I tried to get my system to write a core but I haven't managed it yet. It seems in modern Linux there are ten systems in place to avoid writing cores :-/
<wingo>fwiw i am still behind on guile-devel
<wingo>other than that and the blocker bugs i mentioned on status, the only big bug i am aware of is incompatibility with page size > 4096
<wingo>i would like to fix it but it's gnarly
<wingo>probably a small amount of code but lots of things to page in
<civodul>(rnrs io ports) exports bytevector->string in 2.2, but that's not an R6 procedure, is it?
<wingo>is it not? if not we can remove it from that export
<wingo>civodul: i think it is an r6rs procedure
<wingo>it's a port procedure because it takes a transcoder argument
<civodul>oh you're right
<hiphish>Hello. Is there a way to customise what messages Guile displays when it is invoked? After the fiftyth time I think I get that Guile comes with no warranty. I would also like to turn off the notification when a file has to be compiled, I only care if it failed to compile.
***hiphish is now known as HiPhish
<lloda>HiPhish: put this in your .guile (total hack): (module-set! (resolve-module '(system repl common)) 'repl-welcome (lambda (repl) #f))
<HiPhish>lloda: Thank you, that's exactly what I wanted. Is this documented somewhere? I couldn't find anything like that.
<lloda>It's not documented. From (system repl common) only repl-default-option-set! is. But I was already using that, so completion showed repl-welcome.
<civodul>wingo: BTW, looks like custom binary output ports are now buffered by default
<civodul>the mode bits lacks SCM_BUF0 it seems
<civodul>was it intentional?
<wingo>could be; i don't know. probably i have a bias towards buffering and i may have changed that without thinking
<wingo>is it a bad thing?
<civodul>i noticed it because tests/hash.scm fails in guix
<civodul>dunno if it's good or bad, i need to think about it
<civodul>buffering on custom output ports is ok; it was already there apparently, just slightly different, and thus 2.2 exposed issues in a couple of tests
<civodul>good :-)
<civodul>i see GDB uses the old port API, it'll need love
<wingo>ah indeed.
<avoine1>I saw that too, if we add the dwarf debugging information in our compile files would that make the GDB plugin obsolete?
<wingo>humm, this 64k page size thing, humm
<paroneayea>wingo: just gave an attempt at the doing the cleanup in run-server*... it doesn't seem like the thread is unwound unfortunately, so it never get cleaned up
<paroneayea>I'll post the patch to the bug tho
<lloda>bytevector->string benchmark :-(
<wingo>lloda: try latin-1 instead of ascii
<lloda>;; 11.772692s real time, 13.005757s run time. 2.802609s spent in GC.
<lloda>better, but still...
<wingo>lloda: and "utf-8" ?
<lloda>;; 1.344795s real time, 1.858142s run time. 1.776758s spent in GC.
<lloda>ok, I didn't expect that.
<wingo>probably (ice-9 iconv) should change to use get-string-all from (ice-9 textual-ports) instead of read-string from (ice-9 rdelim)
<wingo>heh i guess they are the same actually
<wingo>i guess it's read-string that's slow
<wingo>perhaps there could be some more fast paths there, oh well
<wingo>(the utf-8 case ends up going through a loop in C)
<wingo>actually now given that there are reasonable string-set! fast paths, perhaps we can add a string-set! vm opcode and that would largely fix the issue
<lloda>get-string-all was really slow, that's why I tried get-bytevector-all + conv
<lloda>;; 49.310074s real time, 88.766189s run time. 78.015907s spent in GC.
<lloda>^ with get-string-all
<wingo>optimizations are possible :)
<lloda>yeah ;)
<stis>hello guilers!
<paroneayea>happy International Womens' Day
<amz3>I know someone that will be happy to read that post :)
<civodul>paroneayea: interesting!
<wingo>civodul: wdyt about asking david kastrup to not post to guile-user? i do not want guile users getting the idea that he is a good model of behavior
<civodul>oh he wrote again?
<civodul>ACTION looks
<civodul>lemme reply :-)
<wingo>tx :)
<wingo>also! i like what you did in guix with the code of conduct
<wingo>does a nice job of setting tone
<wingo>we should make a code of conduct a 2.2 feature!
<wingo>specifically it looks like the one that guix uses is fine
<civodul>yes i thought about it, that'd be nice
<civodul>Guix was younger and smaller at the time, which simplified things
<wingo>it is more complicated with an older project
<wingo>though still the right thing of course ;)
<wingo>fwiw i am not interested in supporting the mark-function use case in the foreign object api as-is; happy to leave those users with smobs for the moment.
<civodul>wingo: you mean those who need mark functions would use SMOBs, right?
<civodul>that sounds reasonable to me
<wingo>civodul: yeah
<wingo>basically the deprecation/migration signal is pretty weak right now until we would have some kind of replacement for that use case i think
<wingo>part of why smobs aren't formally deprecated, just that the manual recommends other things
<wingo>first paragraph of mentions another use case (applicable smobs)
<wingo>anyway, it's a process :)
<spk121>wingo: fwiw, another SMOB-only feature is being able to create a custom printer in C
<wingo>spk121: good point
<wingo>with foreign objects you can make a printer in scheme but not c
<wingo>so that's a thing
<civodul>oh right
<civodul>hello spk121 :-)
<spk121>civodul: hi!
<wingo>i think i have a fix for the page size thing, so yay, another blocker down...
<civodul>wingo: woohoo!
<civodul>wingo: re stringbufs, (ice-9 rdelim) uses 'string-set!' a lot and thus it seems to be much slower now
<civodul>i guess we should rewrite it to avoid 'string-set!'
<wingo>civodul: slower than what? :)
<wingo>is it slower than 2.0?
<civodul>yes i think so
<civodul>well i'm investigating
<wingo>we can add a string-set! fast path to the compiler and vm
<wingo>i didn't do it before but i probably should have
<wingo>or optimize that code if that's the right thing
<civodul>i think it's reasonable to assume that string-set! is unusual
<civodul>and then make sure it really is ;-)
<wingo>yeah but with these buffery kinds of operations you might want it
<civodul>dunno, you could also use lists of bytevectors in some cases
<wingo>mmm, maybe, but then you enter into port territory
<wingo>but there is (ice-9 ports internal) now so scheme does have access to the port buffer
<wingo>for utf-8 ports at least we could probably do smarter things
<wingo>i see similar times for 2.0 and 2.2 for read-string on a 1MB file
<wingo>is it only with bigger files?
<spk121>string-set! has a lot of overhead because of typechecking, mutability checking, copy-on-write.
<wingo>spk121: string-ref has type-checking, and the mutability checking is now combined with copy-on-write fwiw
<wingo>i think there can be a nicer fast path; dunno
<wingo>did you see d0934df1f2f0e5d3fa9a1a1f15e6f2dec1d15698 ?
<wingo>no global stringbuf mutex any more, yay
<civodul>wingo: 80M on an input pipe
<wingo>is the pipe buffered?
<civodul>i don't have clear figures yet so take it with a grain of salt
<wingo>yeah could be with big files it doesn't work so well, i was just trying it now and indeed it looks bad
<wingo>;; 72.910672s real time, 83.762197s run time. 74.720088s spent in GC.
<wingo>on master for an 80 MB file
<spk121>wingo: rly? So not using the code in strings.c anymore? Because, scm_string_set_x still does all those things....
<wingo>spk121: yeah you're right. still if the string is shared or has an immutable stringbuf you can immediately dispatch to the runtime
<wingo>the common case can stay in the vm
<wingo>but do take a look at that commit!
<wingo>civodul: on 2.0 with a 80MB file:
<wingo>;; 12.801762s real time, 14.148364s run time. 3.787095s spent in GC.
<wingo>the strategy of read-string as consing up a list works fine for small strings but not big ones :)
<wingo>lol i was blaming string-set but there's no string-set in read-string
<wingo>anyway, zzzz
<wingo>night folks!