IRC channel logs


back to list of logs

***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>a bit irritating
<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>lookig for the fix
<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
<civodul>yeah, dunno
<civodul>lighting 1.x was exactly that
*wingo nod
<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
<civodul>that sounds quite bad :-)
<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
<amz3>hello #guile
<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
<sneek>Got it.
<wingo>sneek: later tell lloda similarly if array-sum is not compiled and array-ref and array-length are compiled, same thing, no speedup
<sneek>Got it.
<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>sneek: botsnack
<amz3>I hope more guile / scheme hackers join the guile room
<rain1>what guile room?
<jcowan>the one we are in, presumably
<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>the port is closed?
<manumanumanu>Hey ho
<manumanumanu>What are y'all up to?
<stis>python sockret standard lib
<stis>er socket
<manumanumanu>sockret. Nice name for a socket lib
<janneke>64bit port of mescc
*wingo poking jit.c
<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
<manumanumanu>Even or odd?
<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.
<rekado>don’t know.
<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…?
<civodul>like a bad content-type header?
<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>“eq” is (string-index x #\=)
<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>it looks like a parsing bug, though
<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?
<civodul>i guess i'm missing something
*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>that response is some XML.
<rekado>and I guess it should not try to parse the payload as HTTP
<civodul>the email is within that XML?
<rekado>I’ll investigate tomorrow.
<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>could be
<civodul>well well, no
<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.
<rekado>thanks for listening!
<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>ArneBab: I mean CSRF
<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