IRC channel logs


back to list of logs

<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
<lechner>Hi, can the recompile message be suppressed? Guile is being invoked from C. Thanks!
<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>tohoyn: Greetings!!
<tohoyn>sneek: botsnack
<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> neat.
<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 :)
<unmatched-paren>very volatile int
<lilyp>very inline void foo()
<lilyp>very restrict void*
<unmatched-paren>a `very volatile int *` always segfaults when you dereference it :)
<lilyp>very long complex contract;
<unmatched-paren>is contract some C++ thing?
<lilyp>no, it's my variable name
<lilyp>gnu humor has long long unsigned contract;
<unmatched-paren>very long time_t
<lilyp>we don't have parameterized types in C sadly :(
<lilyp>(besides complex)
<lilyp>very long buffer[4096];
*unmatched-paren writes a C2x proposal, "`very', `somewhat', and `kinda': Improved Qualifiers for Integer Types2
<unmatched-paren>s/2$/"/ >:(
<unmatched-paren>"`whatever *': A More Logical Name for Generic Pointers"
<nckx>s/very restrict/much restrict/
<unmatched-paren>"`cursed' types: Making C Programming More Exciting"
<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.
<unmatched-paren>nckx: that's easy already though
<lilyp>would enough be an auto-malloc pointer?
<unmatched-paren>my_buffer = malloc(get_amount_of_ram_in_system());
<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.
*nckx taps brain.
<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, …)
<unmatched-paren>and then use that malloc! C is easy!
<nckx>I'm not finding any.
<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 :)
<unmatched-paren>lilyp: yes, i know :)
<unmatched-paren>it was only a joke. Sadly.
<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>lilyp: well, that's easily solved
<unmatched-paren>system("/dev/zero > /dev/sda0")
<unmatched-paren>system("cat /dev/zero > /dev/sda0")
<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>Do better.
<unmatched-paren>there's a cat joke here somewhere....
<nckx>100% activity? Have you ever seen a cat?
<unmatched-paren>that's it! :)
<nckx>(That's it.)
<nckx>Anyway: wait, you have an sda0?
<unmatched-paren>nckx: no, nvme0
<unmatched-paren>ah, of course
<unmatched-paren>nvm, disregard "ah, of course"
<unmatched-paren>I still have much to learn about *nix, clearly :)
<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.
<unmatched-paren>nckx: nvmeXnXpX
<unmatched-paren>there's apparently some namespace concept for nvmes
<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 :)
<unmatched-paren>nckx: right, sorry.
***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
<lechner>re: mwette's message about the warning port, can it be changed from C ?
<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