<stis>Hmm, I can read in 20M doubles in a bytevector if we use binary represenrtation like a hex #xf.ff, and it is (trivially) precise. <stis>reading in decimal version land you in 3M doubles / s. Guiles' reader takes 1M doubles / s <stis>Actially the reader is very inneficient, we are talking about 0.4M doubles / s <stis>so the best case is an improvement of 2.5*20 = 50X <stis>you can set a flag in the writer and all real bytevectors and real numbers will be produced in hex representation <stis>we are talking about 150MB/s typically you increase the throughput by 10X if you use a direct binary representation <stis>Next step will be a fast string reader <stis>Hmm perhaps I should make a C library so that other project could benefit <stis>the standard C library prints 0.7M doubles / s and reads and similary it reads 0.7M floats / s <mwette>lechner: try (current-warning-port (%make-void-port "w")) <wklew>is there a reason the -L switch to guile does nothing when executing a script? <wklew>is only seems to have an effect when using the REPL ***karlosz_ is now known as karlosz
***karlosz_ is now known as karlosz
***karlosz_ is now known as karlosz
<sneek>Welcome back tohoyn, you have 1 message! <sneek>tohoyn, daviid says: i still have some house keeping, cleaning work, then i'll push those changes related to calback support in g-golf, hopefully tonight, maybe later, but will let you know <tohoyn>daviid: as regards your message to lechner 2022-06-03 is it ok to change the internals of G-Golf? <tohoyn>daviid: I mean creating an own version of G-Golf. ***karlosz_ is now known as karlosz
***w1gz_ is now known as w1gz
***rgherdt_ is now known as rgherdt
<lampilelo_>wklew_lurk: it may possibly be a bug, i don't see a reason why a script should ignore -L, but it definitely does, guile stops parsing arguments after encountering -s, the code for it is has been basically the same for 11 years now, although it seems like the behavior was different before that <lampilelo_>wklew_lurk: you can definitely report it as a bug ***lampilelo_ is now known as lampilelo
<undltd>what would be a distribution-agnostic way for a guile program to reference certain data file shipping in package? something normally stored in somewhere under `/usr/share/...` on traditional Linux distributions? <mwette>When you use `#!/path/to/shell -a -b -c' only the first argument is passed to shell. <mwette>^e.g., "man bash" and search for "#!" <mwette>I usually write scripts as #!/bin/bash .... exec guile $0 -L !# ..." ***karlosz_ is now known as karlosz
<drakonis>embedding CL in other languages without needing design compromises like designing everything in C <stis>powl is really expensive, I use a lookup table in stead and performance is way way better I can now read 20M doubles/s <stis>I have now a reader for long doubles <lilyp>next up are long long doubles? <lilyp>come to think of it, C would be much more fun if it had a "very" keyword <lilyp>very long int, very short int, etc :) <lilyp>gnu humor has long long unsigned contract; <lilyp>we don't have parameterized types in C sadly :( *unmatched-paren writes a C2x proposal, "`very', `somewhat', and `kinda': Improved Qualifiers for Integer Types2 <nckx>s/very restrict/much restrict/ <lilyp>oh come on, it could be worse <lilyp>if everything else fails, we can still default to objective c <nckx>There could be an ‘enough’ keyword. <nckx>long enough buffer → checkmate hackers. <nckx>Just bump it every 18 months. <lilyp>would enough be an auto-malloc pointer? <lilyp>unmatched-paren: that's a segfault <lilyp>trust me, I did operating systems <nckx>unmatched-paren: so *that's* why modern browsers are secure! <nckx>You can't overflow if you're out of memory. <unmatched-paren>lilyp: all you need to do is `for (void *p = (void *)1; p < get_amount_of_ram_in_system(); p++) { free(p); }` though <nckx>So what I actually came to ask (sorry): is there any Guile binding whatsoever for POSIX capabilities? (libcap, libcap-ng, …) <lilyp>if the call to free(p) even goes through, you'll get a page fault <lilyp>nckx if it's not in guix, it doesn't exist :) <lilyp>it doesn't even work on embedded systems with direct memory access; though there you don't have the problem that you can't get memory <lilyp>but back to other systems, you do forget about swap as well, so... <unmatched-paren>(is this possible? or will it just keep going because /dev/zero is basically infinitely large? would i need to use dd instead if i was this insane?) <nckx>It won't. You'll hit the end of sda0. <unmatched-paren>nckx: right, i wondered whether cat might just try to read the whole thing before writing, but in retrospect that's a ridiculous idea <nckx>cat /dev/zero > /dev/null uses 100% CPU. That could be optimised, cat. <nckx>100% activity? Have you ever seen a cat? <nckx>Anyway: wait, you have an sda0? <nckx>I've never seen an NVME. My impression is that they're always called nvme0c5x12p1pbis445b81225room12 or something bizarre. <nckx>Or they seem to in bug reports. <nckx>And they obnoxiously demand ‘support’ in everything, which makes me wonder: why can't they just be a block device? <nckx>Yeah, we needed more SAN concepts under our laptop keyboards, that was missing. *nckx checks /topic — nah looks about right. <nckx>(I still have an on-topic question pending if anyone wants to make a point out of answering it :) ***lilyp_ is now known as lilyp
*unmatched-paren shuts up <lilyp>joke's on me, I tried compiling guix in /tmp and it didn't work <nckx>unmatched-paren: That was aimed at me, not you! <nckx>Your answers were perfectly relevant responses to my unhinged rant. <lilyp>regarding guile-libcap, I do think that guix would be the first user/"provider" of that package <nckx>lilyp: That's what I feared. I don't want to write bindings, which is why I've never written bindings, which is why I don't want to write any. <stis>So the new reader for guile I am working on now groks 20M doubles if read into a bytevector. Nice! that's 40-50X guiles current reader <stis>yeah the types in C and C++ are insane, flot32 float64 and float128 would be better as I normally try to use uint64_t etc as well