IRC channel logs

<wingo>paroneayea: i was thinking, i can probablymake fibers a bit more lightweight

<wingo>i was at first trying to make them have identity -- like you could ask what fibers are running etc. but now i think that's a layer that's best added above

<wingo>i.e. you can build fibers-with-identity on top of "raw" fibers

<wingo>or actors-with-identity, etc

<sjoerd`>has there been activity on making a JIT already? It would seem libgccjit might be a proper backend for bytecode

<ArneBab_>sjoerd`: there are people who experimented with compiling with GNU lightning: https://www.gnu.org/software/lightning/manual/lightning.html

<ArneBab_>"One thing I have found incredibly pleasant with Guile is the manual. Good manuals explain how to use the software. Great manuals encourage you to understand the software and the implementation details." → http://decafbad.net/2017/07/26/day-56100-leap-years-in-scheme-guile-code-and-the-guile-manual/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+CraigMaloney+%28Craig+Maloney%29

<ArneBab_>(sorry for the PR dirt in the link, I didn’t realize it was in there when copying)

<ArneBab_>sjoerd`: were there news around gccjit?

<ArneBab_>sjoerd`: here’s the link to the compiler experiment: https://github.com/8c6794b6/guile-tjit

<sjoerd`>ArneBab_: it is right here, https://gcc.gnu.org/wiki/JIT

<sjoerd`>Would it also make sense to have GNU R compiling to Tree-IL?

<civodul>would be interesting :-)

<civodul>re guile-tjit, there's a paper from the 2016 Scheme Workshop

<mbuf>Are there any examples on integrating JavaScript with Artanis?

<ArneBab_>sjoerd`: I think it would be interesting to have R on Guile

<ArneBab_>but likely lots of work

<ArneBab_>sjoerd`: the larger plan for Guile is however to add a specialized compilation step. For a proof-of-concept see http://wingolog.org/archives/2014/02/18/compost-a-leaf-function-compiler-for-guile

<sjoerd`>Am reading

<dsmith-work>Morning Greetings, Guilers

<civodul>ACTION struggles with bytestructures

<paroneayea>wingo: hm interesting... I think it wouldn't interfere at all with the stuff I'm doing to make that change

<jlicht>Does guile have something akin to a reader macro? I found the documentation for `read-hash-extend', which might already do what I want

<paroneayea>wingo: are you thinking it would be better for conceptual simplicity or speed?

<wingo>paroneayea: both

<paroneayea>wingo: gotcha

<paroneayea>right now 8sync on fibers is "half the speed" on a single core than it was before but

<paroneayea>now we can take advantage of multiple cores

<paroneayea>you get it back if you add two cores ;)

<paroneayea>and that's just for message passing, which I think won't be the bulk of cost of most programs (most of it should happen in the handlers themselves)

<paroneayea>so I think it's mostly ok

<paroneayea>being able to take advantage of multiple cores and preemption is a big win, so

<civodul>jlicht: read-hash-extend is the thing (or Guile-Reader); but think twice before you start relying on a reader extension :-)

<wingo>paroneayea: one thing, did you try re-using the operation for every turn of the actor's loop?

<wingo>like the operation that you make to send or receive or be signalled -- that data structure is stateless, you can re-use it

<jlicht>civodul: I am player around with Semantic Versions, and it quickly became a hassle to run (clean <..>) on all my input while doing some REPL driven development ;-)

<paroneayea>wingo: yup I'm reusing it

<jlicht>civodul: So I will only be using it as a convenience when coding, not in the actual code itself

<paroneayea>wingo: also, adding actors overhead runs at half the speed of a basic ping-pong test in fibers also

<wingo>paroneayea: cool

<ijp>if it's only for the repl, then a repl command is probably more appropriate than a reader extension

<paroneayea>and of course

<paroneayea>we do have double the message passing

<paroneayea>because we have the intermediary delivery fiber

<paroneayea>for the buffered queue

<civodul>jlicht: i agree with ijp ↑

<jlicht>ijp: That is probably more appropriate then. How can one 'extend' the repl in this way? The manual mostly talks about the existing commands

<ijp>Check out the module (system repl command) and in particular define-meta-command

<ArneBab_>hello ijp — nice to catch you online!

<jlicht>cool. Thanks civodul, ijp :-)

<paroneayea>I'm still a bit jealous of Akka which apparently can get to 1M messages per second per core, but maybe we'll get a nudge closer to that when we hit native code generation :)

<ArneBab_>ijp: do you have an update on your guile-js work?

<ijp>ArneBab_: If you don't mind waiting, I'll message the list at some point in the week

<ArneBab_>sure :)

<ArneBab_>ijp: one problem which came up here which I couldn’t answer was "is the code somewhere"

<ArneBab_>ijp: do you have your code online somewhere?

<ijp>there is some on gitlab, but I haven't pushed recently

<ArneBab_>will you do that for the message to the list?

<ijp>yes

<ArneBab_>ah, gitlab as keyword found your gitlab repo in my history: https://gitlab.com/ijp/guile/tree/compile-to-js-2017/

<manumanumanu>So, I have added #:final-keywords to my for loops, which are not quite syntactically the same as rackets ones (no body-or-break-clause, but nobody uses those any way), but they are on par feature wise. However, ArneBab_ asked me about the macro expansion time, which is somewhere close to 0.02s for a non-trivial for loop. That is not good enough. What are the tricks to keep macro expansion down?

<manumanumanu>macro-expansion time*

<manumanumanu>I moved away from generating and outputting lots of syntax in favour of a more procedural style, which made it slightly faster

<manumanumanu>the code can be found here: https://bitbucket.org/bjoli/guile-for-loops/ (explanation/docs in for-loops-impl.scm)

<ArneBab_>manumanumanu: you can call into helper functions as much as possible. That keeps the code size down (be minimizing duplicated intermediate code)

<manumanumanu>yeah, that's what I have been doing. My first attempt was more or less a syntax-rules-only approach, but now, instead of generating and outputting code for the next macro, I am passing syntax objects to helper functions around

<manumanumanu>before i started doing that, I had 3 steps that generated the code for the next macro, now I only have 1 intermediate step before emitting the code.

<manumanumanu>I still need to use syntax-case to destructure the syntax passed around, so I don't know how much is gained by the procedural style anyway

<solene>hello, how can I parse a html answer to extract some tags ? I can't find any library doing this

<bavier`>solene: you might be able to use the sxml module

<dsmith-work>Ancient, but might be able to be resurrected: https://lists.gnu.org/archive/html/guile-devel/2013-07/msg00029.html

<dsmith-work>I guess htmlprag is part of guile-lib

<daviid>solene: htmlprag is in guile-lib, here is the doc link: http://www.nongnu.org/guile-lib/doc/ref/htmlprag/

<solene>bavier`: I tried the sxml module but it seems that my html isn't a perfect xml so it throws an error while converting it

<dsmith-work>solene: Which is the exact problem htmlprag attempts to address

<dsmith-work>A "pragmatic" parser for html

<solene>yes, htmlprag seems to do exactly what I need ! :)

<ijp>Someone(tm) should go over the html5 parsing algorithm with a fine toothed comb, and make htmlprag do the same

<paroneayea>or just rewrite it following https://www.w3.org/TR/2011/WD-html5-20110113/parsing.html

<paroneayea>or even the current editor's draft

<paroneayea>current ED looks more complicated tho ;P

<paroneayea>might be easier to start with the 2011 document

<paroneayea>ah no

<paroneayea>nm me

<paroneayea>it looks just as complex

<paroneayea>I didn't see that https://www.w3.org/TR/2011/WD-html5-20110113/tokenization.html was on its own page, heh

<paroneayea>I think auditing the algorithm against that incredibly complex document would be so much work that it would maybe even be less work to just type in the algorithm from that page by hand

<paroneayea>esp since the w3c document isn't a specification of behavior as much as a step by step algorithm

IRC channel logs

2017-07-31.log