IRC channel logs


back to list of logs

<jmd>Is there a way to refer to characters with something a little more meaningful than, say, #\\stx ?
<wingo>you can use formal-name->char if that's what you would like
<wingo>otherwise not really :)
<lloda`>wingo: ok to push;a=shortlog;h=refs/heads/wip-exception-truncate to master? Except the last one
<lloda`>I sent a version of these to the list, I've cut them down a bit. I can resend to the list of you're going through that.
<wingo>would you mind resending? i will look at them directly
<lloda`>np, I resend
<lloda`>ah, I forgot to fix one of the commit messages. Anyway, sent.
<amz3`>wingo: regarding, fibers, is it ok to run CPU bound task in a fiber?
<amz3`>wingo: does write/read procedures work with suspendable ports?
<amz3`>ok my last question is answered in the manual
<amz3`>the answer is write and read will block (
<wingo>amz3`: cpu-bound is fine; if it is interruptable it will be preempted every so often to let other fibers run
<wingo>if not it will block other fibers from running in that same scheduler but depending on your use case that could be ok
<wingo>also by default run-fibers spawns a scheduler for each cpu available to it
<wingo>in the taskset / current-processor-count sense
<dsmith-work>Tuesday Greetings, Guilers
***micro_ is now known as micro`
<amz3`>wingo: that's the #:hz parameter in run-fibers procedure. In the 1.2 part, it's written
<amz3`>“If a fiber runs for too long (by default, 10 milliseconds), it will be preempted: interrupted and rescheduled for the next turn. The preemption frequency can be tuned by the user or turned off for a fully cooperative scheduling model.”
<wingo>#:hz 0 to turn off preemption
<amz3`>how is defined "interruptable"?
<wingo>see "Barriers" in the manual
<yrk>is guile cross-platform?
<lloda`>are the magic help comments 'Commentary:', 'Code:', etc. documented somewhere?
<lloda`>ah module/ice-9/documentation.scm
<wingo>yeah you can do (help (foo bar)) to get help on the (foo bar) module
<wingo>need to turn on the texinfo parsing tho
<wingo>to get the nicer documentation
<wingo>have you seen that, lloda` ?
<wingo>e.g. (use-modules (texinfo reflection)) then (help (statprof))
<lloda`>wingo: yes. I saw the nice output of help and wanted to do the same for my modules :)
<lloda`>but we need a pager, etc. to be on par with ipython and such
<amz3>let's compile 2.1.7
<amz3>well, seems like it's already compiled, but $ guile --version
<amz3>guile (GNU Guile)
<amz3>oops I made a mistake
<amz3>I forgot to add the correct prefix
<amz3>ok done
<wingo>good evening
<paroneayea>hi wingo !
<wingo>heya paroneayea :)
<amz3>wingo: tbh I am not sure I understood the barrier documentation. It seems to me the fibers scheduler can most of the time pause any fiber (except if you use some specific procedure listed in the doc)
<amz3>AFAIU one can use `with-continuation-barrier' to avoid being paused
<wingo>that's pretty much correct; the thing you have to watch out for are things like array-for-each or charset-fold etc that trampoline through c and back to scheme again
<wingo>with-continuation-barrier does indeed prevent you from being preempted
<wingo>though it also means that you can't use channels etc within that call
<amz3>ok tx
<amz3>In my program I need to prepare the threads being executed, is it possible with fibers to run some callback before the initial threads are created?
<amz3>in the dynamic context of the new thread
<wingo>what do you mean
<amz3>ACTION look at fluids documentation
<wingo>of course you can make a wrapper around spawn-fiber or whatever
<amz3>I need to init a fluid
<amz3>in the dynamic context of the new thread but it might be a fluid question
<amz3>I mean a kernel thread sorry
<amz3>I can probably not open as much database link as there fibers running in the webserver, I want to share among the fibers that run inside the same thread to share database session object
<amz3>I want to share among the fibers that run inside the same *kernel thread* a database session/link
<amz3>I was by the init-thunk argument of run-fibers
<amz3>I was looking* for the
<amz3>I am wondering why I was looking for that feature in fluids manual...
<wingo>amz3 if you want an association between a kernel thread and an object you need to use kernel threads specifically
<wingo>fibers may migrate between threads
<wingo>fibers doesn't have a threadpool facility yet but that would be the right solution
<wingo>i.e. (let ((reply-channel (make-channel))) (put-message threadpool-request-channel (cons message reply-channel)) (get-message reply-channel)
<wingo>then have a thread pool doing (match (get-channel threadpool-request-channel) ((message . reply-channel) (put-message reply-channel (do-the-thing message)))))
<amz3>it's possible to put-message another channel :)
<wingo>from a number of kernel threads
<wingo>yes :)
<wingo>and it's possible to put-message between a fiber and a kernel thread
<wingo>so, that's what i'd do i think
<wingo>there are other possibilities too of course
<wingo>in general cml and go literature is useful
<wingo>also core.async
<wingo>from clojure
<amz3>wingo: that's basically what I think I need:
<paroneayea>wingo: ooh, I see you submitted a fibers patch to guix, will review :)
<paroneayea>it's based on my earlier patch :)
<wingo>yep :)
<wingo>it's pretty much the same patch :)
<amz3>the ping-server.scm seems to work, but I can't debug ping-client.scm
<wingo>what do you mean debug?
<wingo>the manual has example invocations fwiw
<amz3>wingo: ^
<janneke>Mescc now from 81 skipped C-statements @FOSDEM down to 29
<amz3>janneke: what the name of your talk?
<janneke>amz3: mes, maxwell equations of software
<amz3>janneke: I don't find it at
<wingo>amz3 that just means you ran the client while the server wasn't running
<wingo>or you have a firewall or something
<janneke>amz3: ah, guixsdbootstrap :-)
<janneke>ACTION likes that name
<paroneayea>wingo: hm, did you try building the guix package?
<paroneayea>I'm hitting an error building it, which I think is the same error I had before
<amz3>janneke: it looks good :)
<janneke>amz3: i didn't dare to look yet, maybe i will
<janneke>amz3: i mean, thanks! :-)
<amz3>janneke: my answer to your question, is I don't know how it can be useful
<amz3>janneke: you want to be able to read the code of the bootstrap binaries with the compiler based on nyacc?
<wingo>paroneayea: yes
<wingo>only that the tests take forever for the reason i described on the list
<janneke>amz3: yes, the idea is to have 13kB of boostrap binaries, rather than 220MB
<amz3>janneke: hmm, 13kb of C code?
<amz3>janneke: oh sorry, I think I am not familiar enough with the bootstrap paradox
<janneke>the mes binary is currently 13kB
<janneke>np, thanks for looking!
<amz3>janneke: you also say it may go into guile in the talk? or it should help guix instead?
<janneke>and that's enough to can run a scheme program that is a C compiler
<paroneayea>wingo: weird
<janneke>amz3: well, as mes is a scheme interpreter and a C compiler in scheme...
<janneke>guile also executes scheme :-)
<janneke>so if any duplication can be removed, somehow, why not?
<paroneayea>wingo: weird, it's not working here
<janneke>the aim is mainly to help bootstrapping guix, but it could help bootstrapping any distro (don't tell them yet ;-)
<paroneayea>I wonder if there's actually a hardware-related thing going on since my laptop is so old
<paroneayea>that couldn't be it, could it?
<amz3>janneke: and the binaries produced by your C compiler are reproducible?
<wingo>prolly not
<wingo>what do you see?
<wingo>does it hang or does it crash or something?
<janneke>amz3: yes
<wingo>paroneayea: you build guile-next from git?
<wingo>i updated the guile-next package earlier today, no idea if hydra built it already
<wingo>it is needed for fibers
<amz3>janneke: what about the 17kb binaries, can mes produce that binary? or mes is the binary?
<paroneayea>wingo: oh right
<paroneayea>wingo: I forgot to rebase guix before I applied the patch :D
<paroneayea>doing so now.
<janneke>amz3: that's my main target at the moment, to make mescc produce this binary
<janneke>gcc can do it, but mescc needs to learn about 29 statements :-)
<amz3>janneke: what part of the differenter interpreter/compiler is mes? mes is written in a mix of scheme and C?
<janneke>currently, the scheme interpreter [mes] is written in C
<wingo>paroneayea: see you tomorrow then ;-)
<wingo>unless hydra is really fast of course!
<janneke>amz3: the C compiler [mescc] is written in scheme
<amz3>janneke: why does it use C?
<amz3>janneke: for compiling the boostrap binaries of guix, isn't it?
<amz3>because we can't replace all the code that use the gcc toolchain and stuff
<amz3>it's a path of transpency I think that's what you call it
<janneke>amz3: as civodul said: some apps in GuixSD are still not written in Guile :-)
<amz3>janneke: we need to cooperate ;-)
<janneke>currently, the GNU system is still pretty much based on C
<janneke>amz: sure, yay!
<janneke>we need a C compiler to produce a guile binary and to produce gcc etc.
<amz3>this is different from guile being self-hosted right?
<amz3>janneke: ^
<paroneayea>wingo: heh, yeah :)
<janneke>amz3: until/unless mes is merged with guile...yes
<janneke>that's also not a goal at all, only if it makes sense
<amz3>my understanding is that guile maintainers want to add a layer that will implement different backends for differents proc architectures, how does mes help?
<amz3>janneke: if it's boring I stop asking question
<amz3>janneke: tell me
<amz3>it's seems to me those are different goals but I might be mistaken
<janneke>amz3: thanks
<janneke>i'm enjoying it...i'm trying to fix some assembly that's broken
<janneke>amz3: apropos different architectures...mes only supports x86 at the moment
<amz3>janneke: you say in the talk that use guile? using guile modules? what does it mean in terms of code do you fork guile modules?
<janneke>amz3: in theory, mes could help to speed-up guile by compiling scheme to native code, but that's waaaaay in the future. using GNU lightning makes much more sense atm
<janneke>amz3: i am using Matt Wette's incredible C-parser, Nyacc
<janneke>that's written for Guile
<janneke>so, Mes needs to support some bits of Guile; optargs e.g.
<amz3>it's clear for me how mes is helping the bootstraping of guix and guile but I don't see where it helps to improve performance
<janneke>amz3: have you heard of nash?
<amz3>janneke: yep
<janneke>it compiles hot-spots to native code
<janneke>Mes also compiles to native code
<amz3>scheme -> native code?
<amz3>scheme -> C -> native code?
<janneke>no, currently not. Only C -> native code
<janneke>indeed, there are projects like ur-scheme and there is PreScheme
<janneke>those compile Scheme to C
<amz3>I see the puzzle makes sens now
<janneke>in theory, combining those efforts could lead somewhere..dunno
<amz3>idk too!
<janneke>but for starters, I'm just looking at reducing the bootstrap binaries and writing a C compiler in Guile
<wingo>like tcc or something
<janneke>yes, targeting subset of C for atm, but possibly tcc later
<wingo>you might be able to target a subset of c that tcc uses
<janneke>yes, i was hoping tcc would not use all of C...but after having a quick look at it i'm not so sure anymore ;-)
<wingo>ACTION zzzz
<janneke>anyway, Mes --the Scheme interpreter-- uses a real small subset, so for now I'm good :-)
<wyrdblurter>Having problems building Guile-SDL2 with Joystick code, any advice ?
<wyrdblurter>Specifically Symbol not found: SDL_JoystickCurrentPowerLevel