IRC channel logs


back to list of logs

<amz3``>mwette: are you here?
<amz3``>mwette: ping
<amz3``>paroneayea: sorry to disturb, what is the name of the framework Sussman is working on, I don't recall the name
<amz3``>bsima: the paper is the art of the propagator
<amz3``>tx paroneayea
<bsima>cool thanks! amz3``
<mwette>I am here
<mwette>but cutting out any minute
<amz3``>ok mail is preferable then
<paroneayea>amz3``: yep that was it :)
<paroneayea>propagator model, pretty cool stuff
<amz3``>my understanding is that it could be used to compute materialized view or keep cache in sync
<paroneayea>well my code works but... I think I found a bug in fibers' channels
<paroneayea>ACTION tries to re-check
<paroneayea>it's conditions!
<paroneayea>wingo: I'm listening on a condition so the loop can tell when the actor should stop listening
<paroneayea>however, after some time, the condition somehow grows *huge*
<paroneayea>the waiters seem to keep growing
<paroneayea>you can see at that it starts out smaller
<paroneayea>I'm not sure why it would grow this way; it seems like somehow the waiters aren't dropping off
<paroneayea>wingo: maybe you didn't intend for conditions to be so "long lived"?
<paroneayea>in my system, the actor's loop keeps spinning around looking for new messages, but also seeing if it's flagged as dead
<paroneayea>I guess that's probably the problem... I'm guessing conditions weren't built to keep being checked
<paroneayea>the waiters just grows forever, is never reduced, so looping and checking it is probably causing problems
<paroneayea>on the upside!
<paroneayea>I got 8sync totally working with fibers otherwise :)
<paroneayea>or so it seems :)
<paroneayea>it's even much cleaner than it was before
<paroneayea>I guess I need to find a new good way to signal that something should halt
<paroneayea>okay yeah I comment out the conditions and everything's fast! ;)
***random-nickname is now known as random-nick
***shinra-chiron_ is now known as webshinra
<paroneayea> microblag update on 8sync & fibers
<paroneayea>huh interesting, an x11 toolkit built on top of concurrentml
<paroneayea>absolutely no screenshots :)
<ArneBab>paroneayea: awesome!
<ArneBab>paroneayea: did you see that I can get 50% of the request rate of a fileserver with fibers as with lighttpd?
<ArneBab>with a *trivial* implementation!
<paroneayea>ArneBab: awesome! I did not see that
<ArneBab>paroneayea: let me put it somewhere…
<paroneayea>ArneBab: nice work :)
<ArneBab>paroneayea: thanks :) — it’s actually thanks to wingos work :)
<ArneBab>paroneayea: if you want to test it, you MUST use wrk: httperf doesn’t manage to saturate fibers
<ArneBab>typical test: wrk -c 1000 -t 1 -d 30s --timeout 5m
<ArneBab>typical test: wrk -c 1000 -t 1 -d 30s --timeout 5m
<paroneayea>I really need a way to implement this stop thing
<ArneBab>paroneayea: if you want to see what a simple homeserver can do: wrk -c 100 -t 3 -d 10s --timeout 5m
<ArneBab>this is the server serving itself
<ArneBab>(sometimes it breaks with fport-write: broken pipe
<ArneBab>that server has two cores, clocked down to 800MHz, and is typically completely overloaded with 3-4 freenet-instances (only the one with WoT actually overloads it …)
<paroneayea>ArneBab: what's wrk?
<ArneBab>a server performance tester written in lua :)
<ArneBab>I had to switch to that because fibers outperform httperf by quite margin :)
<ArneBab>paroneayea: note the coincidence of wrk using lua — which wingo uses with snabb to build high performance network switches
<paroneayea>ArneBab: yeah, snabb uses luajit right? does wrk use vanilla lua or luajit?
<ArneBab>I think luajit
<ArneBab>paroneayea: do you have an easy way of getting wrk? If yes: Here’s guile base64 server vs. varnish/lighttpd "it works"
<ArneBab>varnish: wrk -c 100 -t 3 -d 30s --timeout 5m
<ArneBab>guile fibers: wrk -c 100 -t 3 -d 30s --timeout 5m
<ArneBab>result: varnish 85 requests / second, guile fibers 130 requests / second
<ArneBab>though to be fair, guile also creates 3 times as much load on the server as varnish (in this workload)
<ArneBab>(18% vs. 6%)
<ArneBab>(I assume that varnish does more than fibers here: the simple fibers server just calculates the base64 decode of the path)
<ArneBab>third comparison: this serves the lighttpd reply over varnish and re-routes to SSL via nginx: wrk -c 100 -t 3 -d 30s --timeout 5m
<ArneBab>56 requests / second
<ArneBab>(just as a reminder: this is an overloaded homeserver behind a cheap off-the-shelf fritz-box which was already outdated when we got it around 4 years ago)
<ArneBab>(with 500 concurrent connections Guile fibers serves 50% more requests per second, the latency using Guile is around two times the latency of varnish)w
<ArneBab>I just sent a message with these results to guile-user. Would anyone do a test from overseas before I shut down the Guile fibers testserver?
<ArneBab>paroneayea: ^
<recordguy>Hi, anyone have any idea why the following gives me syntax error? (copied from my REPL): "(use-modules (srfi srfi-9)) (define-record-type point (fields x y))"
<recordguy>gives me "source expression failed to match any pattern in form (define-record-type point (fields x y))"
<rain1>(define-record-type point (make-point x y) point? (x x) (y y))
<rain1>you had invalid syntax, you can do it like this instead
<recordguy>@rain1 oh so constructor and predicate are not optional?
<rain1>thats right
<rain1>under Specification there is a BNF
<rain1>and theres some examples later
<rain1>the record definition syntax is a bit more complex than id like
<recordguy>@rain1 thanks
<rain1> guile has its own version which is a bit different
<rain1>but it recommends srfi-9
<recordguy>yeah i was using "The Scheme Programming Language" book as reference, and the records syntax is different there... the book is R6RS -- looks like R6RS record syntax is different lol
<rain1>I wonder what R6RS was thinking, making records different to srfi-9
<rain1>i think guile implemnts r6rs records
<recordguy>yeah it has r6rs compatibility -- ill use to guile + srfis