<nalaginrut>lloda: just finished compilation of guile-tjit with gcc-6.3 successfully, now it seems not GCC's problem <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 <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 <wingo>could be; i don't know. probably i have a bias towards buffering and i may have changed that without thinking <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>i see GDB uses the old port API, it'll need love <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 <wingo>lloda: try latin-1 instead of ascii <lloda>;; 11.772692s real time, 13.005757s run time. 2.802609s spent in GC. <lloda>;; 1.344795s real time, 1.858142s run time. 1.776758s spent in GC. <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. <wingo>optimizations are possible :) <amz3>I know someone that will be happy to read that post :) <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 <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? <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 <spk121>wingo: fwiw, another SMOB-only feature is being able to create a custom printer in C <wingo>with foreign objects you can make a printer in scheme but not c <wingo>i think i have a fix for the page size thing, so yay, another blocker down... <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>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 <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>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. <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