<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 <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`>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 <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 ***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>well, seems like it's already compiled, but $ guile --version <amz3>guile (GNU Guile) 2.1.5.21-35a90 <amz3>I forgot to add the correct prefix <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>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 <amz3>ACTION look at fluids documentation <wingo>of course you can make a wrapper around spawn-fiber or whatever <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 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>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 <paroneayea>wingo: ooh, I see you submitted a fibers patch to guix, will review :) <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>the manual has example invocations fwiw <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 <wingo>amz3 that just means you ran the client while the server wasn't running <wingo>or you have a firewall or something <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 <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>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 <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 <janneke>amz3: well, as mes is a scheme interpreter and a C compiler in scheme... <janneke>so if any duplication can be removed, somehow, why not? <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 <amz3>janneke: and the binaries produced by your C compiler are reproducible? <wingo>does it hang or does it crash or something? <wingo>paroneayea: you build guile-next from git? <wingo>i updated the guile-next package earlier today, no idea if hydra built it already <amz3>janneke: what about the 17kb binaries, can mes produce that binary? or mes is the binary? <paroneayea>wingo: I forgot to rebase guix before I applied the patch :D <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>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? <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>it's seems to me those are different goals but I might be mistaken <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>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>it compiles hot-spots to 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 <amz3>I see the puzzle makes sens now <janneke>in theory, combining those efforts could lead somewhere..dunno <janneke>but for starters, I'm just looking at reducing the bootstrap binaries and writing a C compiler in Guile <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 ;-) <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