***Server sets mode: +nt
***karahobny is now known as Guest40074
<wingo>lloda: figured out what was going wrong; lightning had a bug where it wasn't preserving the value of callee-save register r12 <wingo>still working on the fix tho <stis>good catch, a tough one! <wingo>lightning includes a little register allocator used when making calls, and it can use unexpected registers... registers even unexpected to itself <wingo>i would rather have a somewhat less generic library :) <stis>I guess this uglifies our codebase, are the lightening folks responsive for bug reports? <civodul>wingo: it used to have no register allocator, but then it was probably more burden on the user (i haven't tried the new one though) <wingo>stis: until now it has been manageable. i'm sure this is just a bug somehow <wingo>civodul: honestly i wouldn't mind being resposible for register allocation, dunno <wingo>i would prefer a simpler library without an optimization phase, without a graph of nodes, etc <wingo>just emitting assembly into a buffer <wingo>i think the problem here is just that for x86-64, r12 was missing the flag to indicate that it's actually callee-save <wingo>found some other weird bugs in lightning git, like the fact that the default allocator for code pages just doesn't work at all <wingo>well, maybe mmap used to return something that wasn't MAP_FAILED when asked to allocate 0-byte pages... <wingo>dunno, the stock allocator isn't very good (it puts every jit_emit() on its own page), i guess everyone uses their own allocator <wingo>we will need to do so i think <wingo>lloda: ok pushed a fix, your array-sum example works now <wingo>no speedup though as the bottleneck is in array-length/array-ref, and in making heap numbers <wingo>takes around 1.6s on my machine either way <wingo>whereas the original f32v-sum takes 180ms before jit compilation, and 50ms after <wingo>jit-compiling array-length works, jit-compiling array-ref doesn't yet <wingo>and jit->jit calls aren't working it seems :) need to fix <wingo>sneek: later tell lloda with current git i can jit-compile array-sum. as i said, no change. when running without hooks (as the jit does not currently emit hook calls) it's around 1.42s on this laptop regardless of whether array-sum is compiled or not <wingo>sneek: later tell lloda similarly if array-sum is not compiled and array-ref and array-length are compiled, same thing, no speedup <wingo>sneek: later tell lloda but if all three are compiled, elapsed time goes down to 1.2s. all the rest of the time is in gc <amz3>I hope more guile / scheme hackers join the guile room <rekado>I’m trying to use “mu-message-from-port” from the Guile bindings of the latest unreleased Mailutils. <rekado>It is supposed to read a mail from a port, but it looks like it does not take a regular Guile port as an argument. <rekado>It says “Wrong type (expecting exact integer): #<closed: file 1795690>” <rekado>does anyone happen to know why that is? <weinholt>rekado, the implementation asserts that the argument must be a port, maybe the error is from somewhere else? <stis>python sockret standard lib <manumanumanu>stis: hugo and I are going to have a scheme meet-up in Linköping some day. It is quite a long way from West Aros, but I don't know how you travel... <stis>I can take a day off and join, would be nice. PLease choose a week where I don't have the kids at home then <rekado>weinholt: turns out that it’s a problem *printing* the message object, not in parsing it. <rekado>I’ve sent a bug report to bug-mailutils. <stis>I can not v35 v37 v39 v40 v42 v44 v46 v48 <stis>for what I know, work travel comes also from time to time with short notice <manumanumanu>I don't know if there are any other schemers in Östergötland that might be interested, but if you know any please spread the word <stis>stockholm? mikael djurfeldt? <hugo>manumanumanu: Is West Aros Västerås? <rekado>amz3: is your Scheme day for FOSDEM separate from what we try to organize as a Guile + other {small languages,Scheme implementations} devroom? <stis>Yep aros is stream opening in a lake, East Aros is Uppsala and West Aros is Västarås <ArneBab>amz3: I am only somewhat familiar with cross-site-forgery prevention, but enough to know that it’s a mudhole with more traps than I can see. At the company we have a ~10 page summary of the essentials, but I’ll need to ask our dev lead whether I would be allowed to share that with you (as individual). <ArneBab>(I wish secure employment (sufficiently secure to get bank loans with good conditions) and working in the open with free software in a great team would already be easier. <ArneBab>rekado: sounds like guile is wrong, yes … as far as I read, it MUST split the bytes by the boundary, though the boundary =-=-= is awfully short. <rekado>I found this same boundary also in an email made with gnus. <ArneBab>that’s strange … what happens if the body includes that boundary? <rekado>I’d think that this would not be good. <rekado>but maybe gnus has some way of picking a different boundary then. <ArneBab>typically the boundary seems to be something like a UUID, much longer and very unlikely to be in the content, even for large files. <ArneBab>amz3: I’d like to be around for FOSDEM, but I don’t yet know whether I can be. It would be cool to share my experience with using wisp for various smaller projects. <weinholt>manumanumanu, anything happening around göteborg? <rekado>Can I monkey-patch the procedure that parses the Content-type header? <civodul>rekado: probably, but do you really need to do that? :-) <rekado>the current implementation in (web http) leads to an error when receiving messages from Debbugs, so I think I do…? <rekado>yes. The header value looks like this: multipart/related; type="text/xml"; start="<main_envelope>"; boundary="=-=-=" <rekado>the problem is with the boundary. <rekado>it contains equal signs, but (web http) aborts when the last “=” is not also the first “=”. <rekado>FWIW your message about the mailutils bug also contains this boundary <rekado>Content-Type: multipart/mixed; boundary="=-=-=" <rekado>I wonder if that’s a gnus thing. <civodul>"when the last = is not also the first ="? <civodul>re monkey patching, i think you could copy the (declare-header! ...) expression with your own code, and that'll override the content-type handler that (web http) provides <rekado>it does this: (unless (and eq (= eq (string-rindex x #\=))) (bad-header 'content-type str)) <rekado>that’s where it bails out because the right index of #\= is the last character of the boundary string, not the equal sign separating the “boundary” key from the value. <rekado>can I do this inside of (web http) so that I don’t have to replace all references to module-internal variables with (@@ (web http) the-thing)? <civodul>if you do this inside (web http), then it's "patching", not "monkey patching" :-) <civodul>the parser should ignore the quoted equal signs i guess <rekado>I don’t know if that assertion is relied upon later; haven’t looked more closely. <rekado>(e.g. in eating up tokens up to the equal sign, etc) <civodul>something i don't understand: the Content-Type example above is that of an email; it's not an HTTP header, right? <rekado>I’m talking to the Debbugs SOAP service. <civodul>right, but is it expected that this is getting parsed as HTTP? *rekado looks at the code <rekado>i’m sending a request to the SOAP service via http-post and expect to receive a response from it. <rekado>and I guess it should not try to parse the payload as HTTP <rekado>maybe I’m doing something silly. <civodul>it's also very possible that i don't get it, dunno <rekado>I’m using http-post with #:decode-body? #t to get a string instead of a bytevector as a response. <rekado>I wonder if that’s the cause of the problem. <civodul>though you should probably #:stream? #t and then read from the returned port <civodul>(normally #:decode-body? is just about decoding the body as a string in the right encoding, so it should be safe) <rekado>well, I need to try to reproduce this tomorrow with a clear head. <amz3>ArneBab: don't bother with trying to share with me the documents about CSF <amz3>rekado: I don't know if it's separate, I wish it's not. <amz3>rekado: AFA communication has gone so far, it's more like 'guix event' maybe 'guix+guile' maybe 'guix+guile+lua'. I never read anywhere that there was a plan for a 'scheme' or 'small language' devroom. nowhere in the mailling I read, it might be a mistake of my own <amz3>and as far as I am concerned, I don't think it wise to call it 'small language' devroom. <amz3>lua alone is not a small language