IRC channel logs

2020-05-11.log

back to list of logs

<malaclyps>arpunk, I ended up using the upstream version -- my "fix" is to submit patches to bring guix up to date
<arpunk>malaclyps: Thanks for the heads up
***catonano_ is now known as catonano
***jonsger1 is now known as jonsger
<bsima>is there an example somewhere of using guile for emacs scripting? I have some guile code I would like to call from emacs, but not sure how to go about it
<bsima>maybe I should just ask this on the mailing list. seems complicated
<dsmith-work>sneek: botsnack
<sneek>:)
<dsmith-work>sneek: seen unknown_lamer ?
<sneek>unknown_lamer was last seen in #guile 6 hours ago, saying: sneek: botsnack.
<dsmith-work>gootbot
<dsmith-work>version
<dsmith-work>sneek: version
<sneek>Sneeky bot running on Guile version 3.0.0 using bobot++ 2.3.0-darcs
<dsmith-work>sneek: version
<dsmith-work>sneek: version
<dsmith-work>sneek: version
<dsmith-work>sneek: botsnack
<sneek>:)
<dsmith-work>sneek: version
<dsmith-work>sneek: botsnack
<sneek>:)
<dsmith-work>sneek: version
<dsmith-work>sneek: botsnack
<sneek>:)
<dsmith-work>sneek: version
<sneek>Sneeky bot running on Guile version 3.0.0 using bobot++ (something from git)
<dsmith-work>unknown_lamer: Both bot:getversion and bot:getreleaserevision seem to be undefined for me.
<unknown_lamer> https://git.hcoop.net/clinton/bobotpp.git/commitdiff/17f13c7ac1b386279a5da43c0fef7c2dbc11ce8a should be defined as of this rev
<dsmith-work>release-2.3.1-4-g031d65a
<dsmith-work>Which is "Call configure from bootstrap"
<unknown_lamer>hrm
<unknown_lamer>they work in my test bot
<dsmith-work>Had some errors installing, maybe it's still old code I'm running.
<unknown_lamer><unknown_lamer> ]eval (bot:getreleaserevision)
<unknown_lamer><Bot> "2.3.1.4-031d"
<unknown_lamer>same revision (different build-aux/git-whatever probably due to me having newer gnulib)
<dsmith-work>The first install error is that "/bin/bash: /usr/local/share/info: Is a directory"
<dsmith-work>Which it is. THe guile info pages are instelled in there.
<dsmith-work>Then (after make -k install) /bin/bash: /usr/local/share/guile/site/3.0/bobotpp: Is a directory
<dsmith-work>Doens't seem right.
<dsmith-work>It's *supposed* to be a dir. RIght?
<unknown_lamer>yes
<unknown_lamer>dsmith-work: I moved some stuff to build-aux, might try from a fresh snapshot?
<unknown_lamer>I had to clear out a bunch of gunk by hand when rebuilding (just had to shuffle things around a bit to integrate the git revision parsing stuff)
<dsmith-work>Ya. Just did a git clean -dxf and starting over
<unknown_lamer>just pushed the paren fix
<dsmith-work>Thanks
<dsmith-work>Hmm. the bootstrap is failing.
<dsmith-work>unknown_lamer: See pm
<dsmith-work>sneek: botsnack
<sneek>:)
<dsmith-work>sneek: version
<sneek>Sneeky bot running on Guile version 3.0.0 using bobot++ (something from git)
<dsmith-work>sneek: version
<sneek>Sneeky bot running on Guile version 3.0.0 using bobot++ release.2.3.1-6-a463-dirty
<dsmith-work>Yey!
<dsmith-work>sneek: seen dsmith?
<sneek>dsmith was last seen in #guile one day ago, saying: $1 = #("foo bar" (0 . 7) (0 . 3) (4 . 7)).
<dsmith-work>sneek: botsnack
<sneek>:)
<wingo>moin
<sneek>wingo, you have 1 message!
<sneek>wingo, dsmith says: Your .dir-locals.el is unbalanced
<wingo>tx for not, i fixed it
<wingo>initial measurements, baseline compiler (-O0) goes between 5x and 15x as fast as -O1, depending on input
<wingo>still ironing out a couple bugs
<civodul>hi wingo
<civodul>nice
<civodul>haven't played with it yet :-/
<wingo>np, probably best that i catch these few bugs
<wingo>the real test will be if we can get bootstrap/ compiled with the baseline compiler tho; currently my test is just making c&e tests use -O0
*dsmith rubs hands in anticipation
<civodul>wingo: are you changing the c&e macro to test both compilers?
<wingo>civodul: yes
<wingo>i did that, i think
<nikita`>hm. https://gitlab.com/gnutls/gnutls/-/issues/996 this is the wrong bugtracker, right? I report this issue with one year delay or so.. system/base/target.scm is within guiles source, not gnutls?
<civodul>nikita`: i think you already reported a similar issue some time ago: "x86_64--netbsd" is not a valid triplet
<civodul>should be "x86_64-pc-netbsd" or similar
<nikita`>but it isn't
<civodul>a triplet with three elements :-)
<nikita`>i think we just had a chat, never a report. but we don't have tripplets in pkgsrc, what guile expects is a mistake for all systems targeted by pkgsrc
<civodul>i'll reply in the bug tracker
<nikita`>ok
<dsmith-work>Morning Greetings, Guilers
***drakonis1 is now known as drakonis
<wingo>neat, i can now compile module/ with the baseline compiler
<civodul>yay!
<wingo>neat, seems to be all in shape. will switch over bootstrap/ to use baseline
<civodul>that's a really nice side effect of this endeavor
<wingo>indeed
*wingo does first clean bootstrap...
<wingo>still takes around 3 minutes to compile eval tho
<wingo>maybe can be reduced by careful trimming of the module graph to avoid loading the cps compiler unless it's used
<wingo>pretty sure that overhead is mostly the expander
<wingo>but compiling psyntax only took 6 minutes or so after that
<chrislck>here's a surprising ice-9 match-lambda error condition:
<chrislck> http://paste.debian.net/1146155/
<heisenberg-25>Hi, is there a nonblocking implementation for `write` function to write scheme values to file?
<wingo>heisenberg-25: not in guile itself, dunno if someone has that as a module
<wingo>unless you object->string then put-string to a nonblocking port
<heisenberg-25>wingo: Ok. I am writing a lot of scheme objects at once so object->string may cause a memory explosion, right?
<wingo>could be, yeah. best to find some implementation of "write" in scheme somewhere and use that
<heisenberg-25>Btw I am asking this as I am using fibers and want to write messages in a channel to file :) . So far using write works for smaller size of objects
<tohoyn>daviid, str1ngs: should g-golf work with guile 3.0? for me it does not.
<wingo>civodul: ok i think it is ready to go for guix
<wingo>if you are able to try git guile for guix, then compile with #:optimization-level 0, or otherwise compile with #:opts '(#:cps? #f)
<wingo>should yield more straightforward debuginfo and a faster compile that takes less memory
<justin_smith>heisenberg-25: maybe I am missing something about fibers, but wouldn't blocking be the right behavior, as you don't want writes to one port to be able to overlap, and a non-blocking send of a message is all that's needed for the thread that requests the write
<justin_smith>that is to say, if I were doing this from scratch, I'd want a single blocking writer (in its own thread) to insure integrity of output data
<heisenberg-25>justin_smith: checkout this pitfall about blocking i/o in the fibers documentation https://github.com/wingo/fibers/wiki/Manual#31-blocking
<justin_smith>heisenberg-25: when I use clojure with core.async, I explicitly create a non-async thread that reads from a channel (in order to isolate my i/o from the async machinery) - it prevents multiple weird issues
<justin_smith>that said I don't know fibers yet (I've looked at them as an analog to core.async but not yet used them in anger) so I'm sure there's subtleties that don't translate
<justin_smith>but, if there's an analogous situation, it would be making a non-fiber thread that can read the kind of port fibers use
<justin_smith>s/port/message
<justin_smith>a brief browse finds that get-message on a channel is thread safe, not sure if it works outside fibers though
<heisenberg-25>justin_smith: It is basically to allow suspending/resuming of a fiber waiting on i/o. blocking i/o calls prevent this
<justin_smith>heisenberg-25: I understand that's what fibers are for, the problem is that you often have i/o or CPU intensive things at the edges that you don't want monopolizing fiber resources, so the pattern required in core.async is an adaptor to a blocking thread via channel - you want a blocking thread (for the i/o or CPU usage) that can commonicate with another non-blocking thread (for coordination / light weight
<justin_smith>cooperative multitasking)
<justin_smith>it could be that fibers don't really want / need this paradigm, if that's the case I apologize for the noise as what I'm saying isn't relevant here
<justin_smith>but my first instinct, having done a lot of async programming, is that having a syncronous process that owns an output destination and blocks, mixed with channel reads / writes to communicate with non-blocking code, is the ideal pattern
<justin_smith>(of course no other process should be sharing that thread that is blocking - the blocking is essentially letting your sync on system calls, and could in theory be replaced by interrupt / select based poll ops)
<civodul>wingo: yay, thanks!
<civodul>i'll report back
***amiloradovsky1 is now known as amiloradovsky
<justin_smith>OK, I'd been intending to read about fibers, and so far they look much nicer to use than core.async, and some things I've learned to do to get around core.async problems might be silly in fiber world :/
<justin_smith>I look forward to using them in anger and find out how they really compare
<justin_smith>hmm - the section of the manual on blocking (which heisenberg-25 first linked) describes the same problems (and same solution) with blockign file IO - indefinite wait time and using real threads as a middle layer
***jonsger1 is now known as jonsger
<str1ngs>sneek: later tell tohoyn. It does not work with guile 3.0 as far as I've tested.
<sneek>Got it.
***jao is now known as Guest32803