IRC channel logs
2024-11-12.log
back to list of logs
<makx>has guile not gotten a base64 encoding function beyond getting the wrapped one from gcrypt? <ekaitz>makx: dthompson did one the other day and shared in social media, but no, guile doesn't have one in the standard library <lechner->Hi, I would like to handle utmp from Guile but the related C library routines are not yet accessible from Guile. What is the right strategy, please? Should I bring the C library call to Guile or implement everything in a guile-utmp? <makx>re base64, this is a bit silly. i found some discussions on the mailing list off and on, but no resolution. wonder what the reason is. <lloda>the reason is always the same, someone needs to send a patch, someone needs to review it, someone needs to commit it <lloda>if it's something that belongs in Guile <dthompson>my microbenchmark says the encoder is ~11x faster than the modified industria base64 used in guix/gcrypt. the decoder is ~2x *slower* due to use of string ports, but this was done to avoid string-ref which is O(n) on hoot. <morenonatural>as a spanish speaker, I have to point out that non-ascii characters are not supported. and they should be supported <dthompson>they're not supported in an *alphabet*, but the 2 alphabets that are in the spec are in the ascii range <makx>dthompson: i guess this comes about often? <makx>so, first for context, i was trying to convert some racket code to guile (as you do if you want hoot n goblins n such), which needs http basic auth <makx>the base64 encode question <makx>it looks like a prime bikeshed to me. <makx>in any case i was just wondering why i couldn't just find an implementation around in a library <dthompson>the answer is that not many projects need such a thing and the ones that do use the implementation from the industria library which is r6rs <makx>can you clarify whay the industria library is and what 'is r6rs' means in this context? <dthompson>I take it you are new to scheme, then? r6rs is the 6th version of the scheme standard. industria is a scheme library written using that standard. <makx>(I am sure I am being clumsy at trying to discover things, but essentially none of the finding engines on the internet are very helpful any more) <makx>I am very much not new to scheme <makx>maybe i lived a lot inside the racket sphere of scheme <dthompson>they kind of have their own entire universe over there <makx>so I found things quite hard to discover <makx>but in any case, thanks for the pointers, I'll have a look tonight <dthompson>like industria was made by someone that doesn't use guile. it happens to work on guile, but scheme is a loosely knit ecosystem <dthompson>there's no one central place to look up all the libraries that exist. it's good and bad. <makx>wouldn't mind that so much if search engines were still of any use :/ <dthompson>fwiw I think guile should probably just have base16/32/64 modules built-in... if someone wants to take on such a project. <ArneBab>(my plan is to convert all the code to regular Scheme once I’m done to create a second version of that article with more parentheses) <ArneBab>dthompson: IIRC base32 can be quite daunting, because it requires bit-level shifting. <ArneBab>one letter of base32 only has 5 bit of information, so while you can represent 5 byte as 8 base32-letters, any byte count that’s not a multiple of 5 runs into padding hell (worse than with base64 where you at least always shift by two bit). <makx>before *I* look at anything vaguely daunting, i will try converting my little private project to guile and see how far i get <ArneBab>Do ask in the mailing list — especially if something feels wrong (it can usually be optimized) — and use full text in the Guile Reference info manual to find stuff ☺ <ArneBab>As search engines got worse, this local documentation became much more valuable … <makx>actually, a point of praise, I like the guile manual <makx>(searching for base64 doesn't help in there though. also i think it could use more examples in places.) <makx>probably the first-best thing to do for me is propose such examples after i figured out how to do it <ekaitz>dthompson: are you trying to add the base64 to guile's stdlib? i think we should have it <ekaitz>we have many things for web and base64 is very useful in that context <civodul>dthompson: was it for licensing reasons that you came up with a different implementation? <civodul>good to see the Goblins grow anyhow :-) <dthompson>wanted a more efficient encoder and something that didn't use string-ref as its O(n) on hoot <ekaitz>dthompson: why is it O(n) on hoot? is it a temporary thing? <dthompson>ekaitz: wingo is of the opinion that it is unreasonable to expect constant time access to characters in a string <ekaitz>yeah so it requires processing of the whole thing <dthompson>without a lot of extra work, the only way to get to char n is to start at char 0 and iterate to find it. <dthompson>hoot strings are built on the wasm stringref proposal which *does not* provide constant time access to chars <dthompson>wingo's recommendation is to use string ports for iterating, so that's what I did for my base64 implementation. it is less efficient than a string-ref loop on guile-vm though <dsmith>makx, ^^ The above has links to libs and applications in Guile <ArneBab>dthompson: makes me wonder how much there is in goblins that would be worth upstreaming into Guile. <dthompson>there's not too much else that's general-purpose like that <ArneBab>I have a few things in my wisp examples that I want to upstream … (most importantly the doctests) <ArneBab>but those hang in discussion (waiting for a reply on guile-devel) <rlb>...if we end up adopting the utf8 changes I proposed, string-ref will definitely no longer be "direct" with non-ascii strings for guile itself either -- i.e. no longer the small 1 for O(1), it'll be a notably larger "1" :) <rlb>*exactly* - though it *is* compile-time tunable atm :P <rlb>...reminds me -- I need to try rebasing/testing against current main (been a bit), and then I need to get back to fixing 32-bit. <k4r4b3y>that issue was quite a headscratcher for me <wingo>would take a little while to page that back in <ekaitz>and that's why the rest of the code after where it points to is not correctly disassembled by gdb <ekaitz>mwette: i spent literally like 30 hours with this <ekaitz>(and i wrote that riscv backend, like 3 years ago) <ekaitz>i'm not sure that's the source of my problem though <ekaitz>the vcode instruction that segfaults is `call` <ekaitz>let me share a larger paste with the line with the problem <ekaitz>i marked the RISV machine instructions with the vcode they came from <ekaitz>wingo: is there any easy way to prevent `call` from being JIT-ed and continue to JIT everything else? <wingo>ekaitz: remind me. what is the instruction width of risc-v (32 bits always?) <wingo>and is there a stack alignment constraint in the ABI ? <wingo>ekaitz: unfortunately jit in guile is an all or none thing <wingo>is there an alignment constraint for jump targets? <ekaitz>but maybe i'm just hallucinating at this point <ekaitz>ACTION runs for dinner but will come back soon <wingo>ekaitz: link to the code you are working on? <wingo>ekaitz: you could try the approach that armv7 takes, to just write zeroes for the jump and then in patch_jmp_without_veneer you just overwrite the bytes instead of patching <wingo>dunno, might be clearer; though i know aarch64 does it a slightly different way <wingo>actually. does the aarch64 code work at all? <wingo>ah, i see, there is some macrology <wingo>ekaitz: if all insts are 32 bits why do we encode bit 1 of offsets? <wingo>i guess there is a thumb-like instruction set? <ekaitz>the jump instructions don't encode the bit 1, in order to have a larger range <wingo>i know they don't encode bit 0 <wingo>but they do encode bit 1, which would let you jump to unaligned addrs <ekaitz>i'm going to leave that for the moment and focus on the segfault (this is another problem i found when disassembling) <ekaitz>the call v-instruction segfaults, and i'd like to find the reason <ekaitz>if i had a way not to jit it, i would be able to be more precise that that's the problem <ekaitz>i don't understand what it does there with s3 <ekaitz>if i could disable the call vinstr i could test if the rest of the thing works <ekaitz>wingo: is there any way i can play around with instrument-call for that? <wingo>not sure i understand the question <ekaitz>I want to make the JIT not to compile `call` and i'm thinking on making `instrument-call` not to count when it is called or something <ekaitz>hmm but it compiles the whole function or nothing, so there's no way to do that <ekaitz>because the call is just a vinst <wingo>well, i suggest fixing the veneer bug then :) <wingo>it is small and perhaps the fix could make you think of other things <ekaitz>yeah... but this is failing earlier than that veneer bug <ekaitz>so maybe the veneer thing just looks like a bug, but it isn't really <wingo>if the disassembly is bogus that would indicate an encoding error which may be shared by e.g. calli <ekaitz>i tried to align a little bit aggressively adding some bytes after the veneer until it was aligned to 32 bits <ekaitz>and that didn't really change anything <wingo>incidentally i am not sure that it is valid c to do "inst i; i.w = x; i.J.whatever = y" <wingo>i.e. you write the whole object as the "w" element then write parts of bitfields using a different union element <wingo>but, we do -fno-strict-aliasing, perhaps in that context it is ok <ekaitz>i think i copied that from gnu-lightning <wingo>better to do i.w = Jtype(...) <ekaitz>i think part of the problem with the alignment might be mine <mwette>Yes. RISC-V needs to have things aligned on natural boundaries. If MES and tcc don't do that you will be hurting, I think. <ekaitz>but maybe it's more lax than i thought <ekaitz>in any case, that happens after the problem i have right now and i don't think they are related <ekaitz>so i'm not sure where should I focus right now <mwette>you are on a VF2? It may have registers to log errors and capture statistics. Not sure if that is useful or not. <mwette>I saw yesterday that guix.gnu.org has a VF2 guix system distribution. I'm wondering what "raw" means. <ekaitz>mwette: i just have guix as a package manager in the vf2