IRC channel logs

<dodoyada>I'm new to guile, most of my experience is in jvm languages. I find every now and then that go to definition in geiser can't find an implementation so I assume it's implemented in c somewhere and may as well be magic. Is this a sustainable view or do I need to set up c sources? In clojure I would definitely expect to be able to go to java implementations

<sneek>Welcome back dodoyada, you have 1 message!

<sneek>dodoyada, nckx says: You'd check with 'lsmod | grep librem'. Also, define 'installing', since I can think of at least two ways, of which I'd expect only one to have any effect (kernel-loadable-modules).

<dodoyada>nckx: thanks! It isn't under lsmod, I just added librem-ec-acpi-linux-module to operating-system -> packages

<dodoyada>sneek is awesome

<dodoyada>trying (operating-system ... (kernel-loadable-modules (list

<dodoyada> librem-ec-acpi-linux-module)) ...)

<dsmith>good bot, sneek

<sneek>ACTION wags

<dsmith>sneek, botsnack

<sneek>:)

<rlb>dodoyada: is the specific concern wanting to be able to jump to the source of "everything", or a more general concern about ending up in C sometimes when you do, or maybe something else?

<dodoyada>rlb: I would like to be able to jump to the source of anything that would help with understanding/debugging, even if that's C, but if it's normal to consider C a cutoff that I shouldn't need to see I just want to know that I went as far as a typical guile developer would

<rlb>Ahh, ok, well don't know of any "jump to C" support, myself -- though if you don't mind a bit more work, and maybe what you were hinting at, checking out the source and git grepping will get you to the right spot most of the time fairly quickly (or of course via I think other, fancier ways).

<rlb>The info pages are varied, but quite informative in many places too wrt how things work on the C side, etc.

<rlb>(oh, and cf. scm.h and other bits in the source)

<rlb>Out of curiosity - coming more from java specifially, or clojure, or...?

<dodoyada>clojure, most recently but before that was (a bunch of jvm languages and then) clojure

<dodoyada>err I mean before that was java

<rlb>Ahh, OK.

<dodoyada>I'm trying this fibers server example https://notabug.org/ZelphirKaltstahl/guile-examples/src/master/web-development/example-01-using-fibers-webserver/main.scm#L65 except that I create the server in a new thread. I thought that if I change the debug handler and reevaluate it I should be able to refresh the browser and see the update but I don't. My first thought was maybe I need to eval routes-config because it wasn't keeping a r

<dodoyada>to debug-handler, but that doesn't work either. Any idea why it isn't changing the handler?

<dodoyada>ehh this probably addresses it https://elmord.org/blog/?entry=20180219-parenthetical-blognir

<dodoyada>so yeah, just inlining the impl of make-routes-dispatcher as a lambda handler to run-server allows updates to handlers. I don't 100% see the difference but I've seen similar things before and get the idea

<old>dthompson: nice blog post

<old>however I wonder if it is possible to remove the predicate in the procedure

<old>like really tell the compiler: Assume strongly that this is a float and I know what I'm doing

<dthompson>old: not in scheme, no

<old>that would get the last bit of performance out of it

<old>but I guess this kind of assumption is already made, but I'm not sure

<old>for example the following procedure

<dthompson>at the function call boundary you do not know what you are receiving, you have to check at runtime

<old>dthompson: I'm more concerned about multiple predicate in the same function, like in a loop

<old> https://paste.sr.ht/~old/cc31a070035467141aa83dce79bd666896b9890f

<dthompson>inside a function, with optimized code, a lot of type checking can be elided

<old>will there be multiple predicate in the above case? Or a single one (for the bytvector) is enough?

<dthompson>not sure I understand the question

<dthompson>check the disassembly. my guess is that the floating point arithmetic will all be unboxed.

<dthompson>if that's what you're wondering

<old>got fixnum? predicate in the disassembled loop

<old>and untag-fixnum

<old>that's kind of funny. If I set (sum 0) I got huge amount of allocation

<old>but (sum 0.0) reduce the amount of allocation by orders of magnitude

<dthompson>because 0 isn't a float

<dthompson>it's a fixnum

<dthompson>initializing sum to a constant float allows the addition to be unboxed

<old>at okay it's fixnum vs flonum

<dthompson>that fixnum? you mentioned earlier is probably for the index math, not the sum stuff

<old>ahhh

<old>hmm I'm kind of confused tho

<old>I've manage to make a variant with 0 allocation, by provinding the input and output bytevector in imperative style

<old>which is great

<old>however, this only work if I do the sum with the `+' operator. When I use `fl+' I get some allocation

<dthompson>probably fl+ is not recognized as a primitive that gets optimized the same way

<dthompson>fwiw I just use the regular arithmetic operators

<dthompson>I don't see any need to use fl+, etc. in practice

<old>okay

<old>hm C is still 50x faster. I wonder if the JIT would be of any help here

<dthompson>well of course C is going to be a lot faster :)

<dthompson>JIT will close the gap some

<old>right. Just wish we could have both

<old>C perf and Scheme beauty

<dthompson>there's a non-zero price for memory safety

<dthompson>see also things like prescheme, a statically typed scheme for low-level programming

<dthompson>guile has a compiler tower with multi-language support. there's lots of possibilities here.

<old>yes ofc. But I think the ideal is simply offload the work to C or some other runtime whenever performance are not met in Scheme

<dthompson>I don't consider offloading to C ideal at all

<old>just like numpy works

<old>meh I think that's fine

<dthompson>but of course that approach is easy to do right now with guile

<dthompson>so what's the isue?

<dthompson>C extensions were guile's bread and butter for decades

<old>would like to stay in Scheme as far as I can that's all :-)

<dthompson>guile is still leaving lots of potential performance gains on the table

<dthompson>we don't have whole program compilation. we don't have native compilation.

<old>right that would be great in the future

<old>and the new GC

<dthompson>for me, guile's bytecode compiler + JIT has been enough for me to do realtime graphics reliably

<old>ought to help a little I guess

<dthompson>whippet will also help

<old>talking about realtime graphics, I just received this book: https://www.amazon.com/Real-Time-Collision-Detection-Interactive-Technology/dp/1558607323

<old>will try to implement stuff in Guile, will certainly look at how chickadee does also

<old>well that's not graphics, but related to ^^

<dthompson>heard of that book, haven't read it

<old>so far it's okay. I'm just at chapter 3 out of 12

<old>little linear algebra primer

IRC channel logs

2024-02-27.log