IRC channel logs

2022-01-31.log

back to list of logs

<spk121>morning guilers
<spk121>I sometimes see people use $ as a prefix to a variable name. Is there a common meaning for $
***dongcarl1 is now known as dongcarl
<wingo>o/
***roptat is now known as Guest1387
***distopico_ is now known as distopico
<wingo>civodul: i think i have an idea for fully reproducible guile compiles, even with parallel compiles -- related to fix for inlining. basically it's compile everything twice. then when compiling file F, the only symbols that psyntax will expand are F.scm and any included file -- but all modules will already have been compiled. so we remove that "is module A used by module B already expanded and compiled or do i have to expand it myself" variation
<wingo>dunno how much symbols from first compile will propagate to second, though.
<civodul>hi!
<civodul>"compile everything twice" is what you suggested in the blog post about cross-module inlining, right?
<wingo>pretty much but in this case i would do the first compilation without cross-module inlining and the second with cross-module inlining
<wingo>making it so that the second compilation only includes the first in its run path
<wingo>anyway i mention this to you just in the context of guile 3.0.7 already being not reproducible when built in parallel
<civodul>right, ok
<civodul>so in this case it would remain reproducible as long as built with -j1, right?
<tohoyn>daviid: GVariant support would be good with GSimpleActions (in order to create stateful actions)
<sneek>tohoyn, you have 1 message!
<sneek>tohoyn, daviid says: I don't want todo that, for various reasons, but of course feel free to do it in theme-d[-golf] if that suites your needs 'better'
***Guest1387 is now known as roptat
<lampilelo>spk121: i think sometimes people use prefixes like $ or % for the top-level definitions of a module that aren't meant to be exported, maybe people use them some other way too, idk, although i think it's pretty common (i do it at least), for example, to create a record with a constructor prepended by % when you want to export a real constructor that does some more computation before creating an object
<wingo>civodul: i think with the compile-two-times policy we would get reproducibility with -jn
<wingo>provided that syntactic gensyms from stage1 don't end up in stage2's .go files. might not be the case but who knows
<civodul>wingo: we'll see :-) we already had a strategy that we thought would work but didn't quite suffice
<wingo>:)
<civodul>wingo: BTW, i have been profiling the compiler
<wingo>which one? :)
<civodul>in the scheme->tree-il phase, we spend 15% of the time in set-source-properties!
<civodul>turns out that psyntax uses set-source-properties! internally on lists of syntax objects
<civodul>i'm wondering if all of these are needed, esp. since syntax objects already carry location info
<wingo>i think maybe? the annotations on lists denote the positions of the parens
<civodul>right
<wingo>i.e. in (foo bar) the open-paren is the location for the application
<civodul>yes, so it's not quite the same piece of info
<civodul>so i wonder if there are situations where we could avoid that
<civodul>or store source location info differently or something
<wingo>yeah not sure
<civodul>(set! supports-source-properties? (const #f)) makes a big difference in CPU time + memory usage
<civodul>one thing we could do also is optimize the representation of location in srcprops.c
<civodul>we could probably make it a single integer containing line + col + file name index
<wingo>what if in rebuild-macro-output we just decorated the first pair in a list?
<wingo>given that the reader can now annotate any datum, surely it's no longer needed to annotate every pair in a list
<civodul>the recursive rebuild-macro-output means we potentially set source properties on every pair of the list, is that right?
<civodul>*recursive call
<wingo>yes
<attila_lendvai>anyone around who understands first class environments in guile? this is what i'm struggling with: https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00425.html
<attila_lendvai>and a guile specific question is this: when set-current-module is used, then how does that influence the module-local global variable bindings? especially when escaping closures are involved.
<attila_lendvai>IOW, should the value of (current-module) influence which bindings closures can see?
<tohoyn>attila_lendvai: but aren't the bindings in closures lexically bound in Scheme?
<attila_lendvai>tohoyn, that's what i would expect, yet the example in my mail only works when the escaping lambda is explicitly eval'd in the throwaway module.
<attila_lendvai>hrm, maybe i should put together a standalone guile-only example
*attila_lendvai is failing to reproduce in a simpler environment
<wingo>attila_lendvai: the environment for a lambda is the one that was current when the outermost lambda was created
<wingo>i.e. the module used to resolve top-level bindings
<wingo>this is a form of lexical scoping. however primitive-load doesn't propagate this lexical scope
<attila_lendvai>hrm... not saying i understand this in depth. but is this a user error? and if so, any hints on how to do it differently?
<wingo>i am not sure what your exact question is
<wingo>can you ask it here with code that is not doing what you expect?
<attila_lendvai>wingo, let me try to come up with a reproducer, and i'll ping you. this is in a complex setup with guix and shepherd involved.
*attila_lendvai is still failing to come up with a reproducer, and runs out of frustration tolerance
<attila_lendvai>i'll get back to this when i have more. i want to see results now.
<m455>hello guilers! i am new to guile and coming from racket/chicken scheme/chibi scheme. very excited to try the ecosystem out :D
<wingo>have fun, m455 :)
<m455>wingo: thanks! :D i think i might make a little fun hobby shellscript project to take all includes in a main.scm or something and compile all of the .scm files into one .scm file to package things up :D
<m455>though i'm not the most technical person so we'll see how this goes hahah
<wingo>sounds like fun :)
<m455>yeah :D how are you doing today wingo ?
<wingo>fine tx, a bit busy as always..
<m455>nice haha same here
<m455>especially with a 5 month-old baby lol
<dsmith-work>{appropriate time} Greetings, Guilers
<stis>Hey guilers!
<gnousrick>hi ! I'm trying to do a simple gemini server with guile, I use sockets for that. but when I do a (recv!) in a bytevector, I don't see the CRLF. I emulate a client with openbsd-netcat (nc -C). If I don't use -C option in nc, I see the newline char in the buffer. any idea about that issue ? maybe I miss something with nc ?
<gnousrick>ok, I just try a echo -e "\r\n" | nc and it's work.
<gnousrick>even without \r\n, I think it's just nc which does something but idk what
<gnousrick>or I'm just lucky :/ sometimes, it's detect nothing.. maybe I miss a flag in recv but idk which one
<lampilelo>echo puts \n at the end if you don't use -n option
<gnousrick>even whith that, nc must put \r\n at the end of the line
<dsmith-work>gnousrick: Are you seeing everything *but* the \r\n ? Is your buffer large enough?
<dsmith-work>Something else to consider is nagle algorithm.
<gnousrick>dsmith-work: yeah, my buffer's size is 1024 and I send only a little string (like "hep"). I see h e p in buffer and only 0 after.
<gnousrick>and I don't know about nagle algorithm, maybe I must check it
<dsmith-work>Remember TCP is just a byte stream. The sends and receives might not match in length. (not packet boundaries)
<gnousrick>:c
<dsmith-work>Nagle (on by default) tries to group small writes into larger packets, for less header to payload overhead.
<dsmith-work>But that's not good for interactive things, like an ssh session.