***dje__ is now known as xdje
<[df]_>I saw, and was thoroughly entertained by your fosdem talk, paroneayea ***logicmoo is now known as dmiles
<daviid>ot: I generally copy the INSTALL file from guile for my projects, add specific instructions at the top and, at the end of the file, I add a title '* the GNU standard INSTALL file content' (org title) and paste the 'usual' INSTALL content, as the one from guile ... but then the savannah hacker looking at guile-cv tells me the copyright notice is incorrect... I've tried to duckduckgo to see if I could find the latest version, if it <daviid>extists?, just asked the same quizz in the #gnu channel, but noone answered. is there such a thing as latest version of INSTALL? <daviid>the copyright notice of the version (presumably not the latest then) guile and I have is: Copyright (C) 1994-1996, 1999-2002, 2004-2013 Free Software Foundation, Inc. <amz3>I do my own INSTALL files, but I don't use autoconf so <daviid>amz3: i need an answer for my question :) <daviid>actually it seems that in guile INSTALL is not even in the tree, so it is generated, would that be AC_PROG_INSTALL? <paroneayea>wingo: guile-fibers is failing to build on hydra <paroneayea>no, the tests don't seem to be taking up that much memory <eiro>it there a plan for a wasm version of guile ? <paroneayea>eiro: it was discussed pretty recently; there aren't specific plans, but there's interest... count me among the interested :) <paroneayea>eiro: main challenges are a) well, doing the work b) where the garbage collector comes from (since wasm doesn't have one... could use emscripten to port the C one guile uses) and b) wasm isn't set up for tail call optimizations at the moment, so it looks like we'd need to use a trampoline, which would add a bit of a performance hit to each procedure call (but, not a blocker) <paroneayea>eiro: maybe it's something you'd like to explore? :) <paroneayea>eiro: there was a scheme->js GSoC a couple years ago that made it partway, but note it wrote out actual javascript, not wasm, so not as performant as wasm would be <wingo>paroneayea: on hydra it oculd be a timeout <paroneayea>wingo: maybe some of these tests should be moved to benchmarks rather than unit tests though <wingo>dunno, for me it is important to run them. problem is they are not being compiled. <paroneayea>wingo: so, I'm trying to conceptualize how to write the actor model on top of fibers, but I'm getting stuck conceptually <paroneayea>wingo: main problem is the whole rondevouz thing <paroneayea>wingo: with the actor model, you drop off a message, and that actor gets to it when they can get to it <eiro>paroneayea, i have to explore guile programming itself. i saw the guix talk at fosdem last year (from ludovic) and was really impressed <wingo>paroneayea: does message sending exhibit any backpressure? <wingo>or can you always send a message <eiro>but i have no time to play with it and what i need right now is lean a langage for web stuff <paroneayea>wingo: you can always send a message, at least in my implementation <paroneayea>wingo: maybe backpressure is done in other actor models... <wingo>paroneayea: ok. obvious problem of course regarding unbounded queues, but ok :) <eiro>i saw elm but i was wondering if there is a scheme->js someone uses <wingo>so i would spawn a separate fiber to handle the inbox <paroneayea>sending the message over to the actor, then checking what messages it's gotten? <wingo>for how to implement a buffered channel in cml <wingo>which is what an inbox is, afaiu <wingo>so from the actor's perspective it just loops doing (receive-from-inbox) -> handle message -> send whatever messages -> start over again <wingo>the inbox itself handles the buffering <wingo>i hope you have performance benchmarks, i want to see how they change in your actors+fibers prototype compared to the original code :) <paroneayea>wingo: I have a hacky performance metrics file I haven't committed yet :) <wingo>for a lisp the thing that's most common is clojurescript of course <paroneayea>Karl Fogel told me a couple of days ago that "All I want for Christmas is Guile -> WebAssembly support" <wingo>eiro: i would recommend trying that fwiw. then if you still want to scheme, then you'd know a bit more about lisp and js and transpiling and all those things, dunno <wingo>paroneayea: i think it's possible fwiw :) you would have to come up with a tail call solution and you would have to <wingo>anyway i don't see an easy way to have resumable continuations and of course you have to have a gc <wingo>whenever it is that wasm gets to take advantage of host GC, that's when it gets interesting to me. MHO. <random-nick>the wasm team is planning GC support for working with JS objects <wingo>i am aware of that. we'll see where it ends up in their priority queue tho! <wingo>has to be implemented four times in practice, so it can take a while. <eiro>ohhh and what about rust bindings for guile ? any advice there ? <wingo>good question! i think it would have to be rust using guile from the libguile c interface -- so it would proceed like any rust binding of a c library <wingo>accessing facilities implemented in rust from guile is possible if the rust library exports a standard C-like ABI <wingo>so basically C is the common denominator there <wingo>but to make access nice from rust, you would want a nice binding written in rust i would think. <eiro>rust bindings for guile still exists <eiro>but i don't know if one is prefered or officially supported by the community <eiro>yep: i just googled and found at least 2 <wingo>i am ignorant tho and can't offer specific advice :) <eiro>i think i need to remove all my old beloved dev stack ***dsmith- is now known as dsmith
<amz3>I took me 1 day to write an algorithm that took me 2 month ten year ago <amz3>it's the earley algorithm, it can parse context free grammar in n^3 <amz3>I still need to write compute the parse tree tho <amz3>ACTION goes back to hack <amz3>is there a cartesian production procedure in guile? <amz3>is there a cartesian product procedure in guile? <stis>with projections car and cdr <void_pointer>Been thinking about the very long bootstrap time of Guile 2.1.x/2.2.x series. Wondering something on it. Did anyone at any point in the last 6 years fiddle with the order that the bootstrap go files are built in after eval.go is built (basically, the ones build using the interpreter writtin in scheme as opposed to the interpreter built by the minimal C based interpeter) <void_pointer>Since after eval.go is built, the order of the rest of the bootstrap go files can be arbitrarily changed in any way one pleases. Some orders would take longer than others, though. <void_pointer>The respective Makefile.am says "A subset of sources that are used by the compiler. We can compile these in any order; the order below is designed to hopefully result in the lowest total compile time." <void_pointer>Which makes it sounds like some thought was put into it but it wasn't necessarily derived or empirically checked, though perhaps it was <ArneBab>void_pointer: yes, people worked on that (I also tried, but my tests only made it slower), but the testing is pretty expensive (given the long time till you see whether it worked). If you have a good parallelizing setup, you could try all the different permutations. I do not, though. <void_pointer>ArneBab: I was just thinking of compiling them all but without using the resulting go files to speed things up while the profiler is on and then using all the compiled go files compile them all again with the profiler on. Profiler catches how much time is consumed in each file depending on its compilations state. Then, just rank them in descending order of difference. <void_pointer>Doing a full simulated-annealing/monte-carlo on the whole build order would take a long time, though it would be effective <void_pointer>But if people have already fiddled with it quite a bit, then it may be more trouble than the potential gain (which could be quite tiny) <ArneBab>void_pointer: you’d have no know how the compilation state of the other files affects each of the files to get an effective ordering. I do not think anyone ever took a truly complete analysis of this. But then, this analysis might only be valid for the exact version analyzed. <void_pointer>Yes, it would be quite complicated. Though, perhaps a simple analysis could give a decent ordering and then monte-carlo it to something better. <ArneBab>I think you can assume that the current ordering is the result of a simple analysis