IRC channel logs

2021-02-09.log

back to list of logs

<rekado>it works with primitive-fork and execlp
<rekado>this works: guile -c '(for-each (lambda (n) (if (zero? (primitive-fork)) (begin (display n) (execlp "sleep" "sleep" "3")) (begin (waitpid WAIT_ANY)))) (list 1 2 3 4))'
***leoprikler_ is now known as leoprikler
<civodul>rekado: waitpid(2) in the parent gets automatically resumed
<civodul>not sure why
<civodul>perhaps a genuine bug
*civodul -> zZz
<civodul>ttyl!
***leoprikler_ is now known as leoprikler
<rlb>ruffni: that may be a known issue... https://salsa.debian.org/rlb/deb-guile/-/blob/deb/guile-3.0/d/sid/master/debian/patches/0005-Mark-test-out-of-memory-as-an-expected-failure-for-n.patch
<ruffni>yeah, i found a couple of older mentions of this test failing. some a couple of years old. i wasn't sure if it might be a new bug failing the old test or the same issue as mentioned here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29884
<chrislck> maybe guile needs a ReadLikeGuile2.2 option
***daviid is now known as Guest47549
***Guest47549 is now known as daviid
<wingo>i suppose if scheme read is the "real" reader, we can remove support for all reader options in read.c
<civodul>probably
<civodul>will scm_read call the Scheme read?
<wingo>civodul: yeah i think so
<wingo>i guess the bootstrap reader used by C would call an internal function or so
<civodul>ok
*wingo constructs bespoke hydroponic bug farm
<civodul>:-)
*spk121 started a build script that is nearly
*spk121 a full 'make' at this point
<civodul>spk121: i checked out the mini-gmp branch but i keep being interrupted since then :-)
<civodul>i'll report back soonish!
<spk121>civodul: no worries
<spk121>plus, you had a pretty busy weekend!
<mwette>glib stretches the C PP to the limit. How is this C?: GLIB_DEPRECATED_FOR('G_TYPE_VARIANT')
<mwette>
<rlb>mwette: https://github.com/Hirrolot/datatype99 which appears to depend on https://github.com/Hirrolot/metalang99 -- have not delved :)
<rlb>"Metalang99 is a functional language aimed at full-blown C99 preprocessor metaprogramming.~...
<mwette>rlb: thanks. The C99 parser in my ffi-helper can't parse that because it thinks it's a broken character literal. For now I just have to stop using glib as a test case for the ffi-helper.
<RhodiumToad>ah, I see that macro is just stringifying its arg, that's why it works
<mwette>What's the type of the argument literal?
<RhodiumToad>type?
<RhodiumToad>at least in the file I'm looking at, there are two versions of the macro; one ignores the arg entirely (for old compilers),
<RhodiumToad>the other is:
<RhodiumToad>#define G_GNUC_DEPRECATED_FOR(f) __attribute__((deprecated("Use " #f " instead")))
<mwette>Scheme <-> C: "foo" <-> "foo" ; #\c <-> 'c'
<RhodiumToad>so in this case the "f" argument is never actually interpreted as any kind of C code
<RhodiumToad>it's just converted to a string literal and then spliced into a compile-time attribute
<mwette>Right. I see now.
<mwette>Thanks.
<RhodiumToad>macros that use stringification or token pasting aren't really possible to interpret without expanding them
<mwette>Exactly. In a standalone case my parser works on that. I need to dig further into why updated glib is not getting parsed.
<RhodiumToad>er, that was the wrong #define I pasted above, but the right one is actually identical to it barring the name
<mwette>Confirmed it's choking on the attribute version expansion shown above.
<manumanumanu>wingo: btw, weinholt has a scheme reader that is r6rs conformant I believe. It is called "laesare" which means "reader". I think it is hosted on github, and unless I'm mistaken it is permissively licensed.
<manumanumanu>oh yes: https://github.com/weinholt/laesare
<mwette>RhodiumToad: when I try to isolate a simple case, it works: https://paste.debian.net/1184741/
<RhodiumToad>mwette: what if you do char *s = bar('abc'); ?
<mwette>same result
<RhodiumToad>hmm
<RhodiumToad>or if bar(X) is defined as "blah " #X " blah" ?
<mwette>char *s = "blah " "'abc'" "blah ";
<mwette> b
<RhodiumToad>well that's correct
<manumanumanu>karlosz: are you the guy who committed the riscV port of SBCL?
<karlosz>yes
<manumanumanu>nice job!
<manumanumanu>I'm still waiting for my sifive board, but sbcl is one of the things I expect to try on it
<karlosz>ah, i just used a vm
<mwette>RhodiumToad: I found the bug. When macro reference is "dead code" I was just letting it pass through. I needs to read the arguments first.
<manumanumanu>so, does anyone have any idea of how far the optimizer goes? I have a case where ,opt does _not_ do dead code elimination. I end up with (if #t do-this (failure)) in the output.
<manumanumanu>pretty deep in a deeply nested loop, though.
<mwette>module/language/cps/dce.scm
<manumanumanu>thanks
<spk121>wingo: with you talking about bootstrapping the reader... One evil idea would be to port the Guile compiler to janekke's mes, compile the reader and the rest of BOOTSTRAP with mes. And just use the .go file from that. <evil laugh>
<eduardore>Hello? My first connection to #guile, can anyone read me? :)
<RhodiumToad>we see you
<eduardore>ah! great thanks for answering
<mwette>manumanumanu: which sifive board? HiFive Unmatched?
<dsmith-work>{appropriate time} Greetings, Guilers
<dsmith-work>sneek: botsnack
<sneek>:)
<dsmith-work>goodbot
<joshuaBPMan>I think it took me about three months on hanging out on irc before I realized that sneek was a bot...
<civodul>spk121: just built --enable-mini-gmp and it went all fine
<civodul>so i guess i'm all for it!
<civodul>perhaps one thing we could do is automatically enable mini-GMP support when GMP is not found
<dsmith-work>civodul: Ah, cool.
<dsmith-work>civodul: So mini-gmp is only a subset of gmp, right? Does Guile not use the "extra" stuff in (maxi-)gmp?
<civodul>dsmith-work: it's a subset and simplified (pure C) implementation, AIUI
<civodul>Guile doesn't need more than that feature-wise
<dsmith-work>Ok, very cool.
<chrislck>would guile(mini-gmp) pass same benchmarks as guile(gmp) but only slower?
<spk121>civodul: I did already put in the logic to enable minigmp if gmp not found, I think. But I didn't test it
<spk121>chrislck: it should be identical but slower, as I understand it
<spk121>dsmith-work: I did have to re-implement one function having to do with double to integer conversion, but that was it
<civodul>spk121: ah ok, i didn't look at the diff in detail, but that logic didn't work for me
<civodul>anyway, we'll see what wingo thinks but it could be a 3.0.6 thing IMO
<chrislck>\o/ some more benchmarks would be very welcome.