<paroneayea>the emacs-sly package also filed an issue referencing the guile list email. ***masoudd_ is now known as masoudd
***Kooda_ is now known as Kooda
<nalaginrut>well, for a very rough testing, 27% performance increased for massive co-routines spawn based on delimited-continuations <nalaginrut>civodul: did you see my rough test result for Nash ;-) <nalaginrut>oops, I've realized that I'm testing them between two different machines, maybe it's not fair <nalaginrut>the machine running Nash is new and strong one, although my laptop is strong too <civodul>because we don't know the length of the string being displayed <civodul>what matters most here is that a warning is displayed anyway ;-) <alezost>definitely :-) although I don't really understand why there are @@ on other lines but not on that one <alezost>oh, now I got it! there is "~S" there <wingo>tx for rolling the release :) <amz3>nalaginrut_: thx for working on Nash <wingo>ACTION just released fibers v0.3.0 too <wleslie>wingo: did you feel (when reading CSP) that making all synchronisation bi-directional makes the model less applicable to modern concurrent systems? <wleslie>as opposed to eg actors, where there's a happens-before (causality) <wingo>what do you mean actors has a happens-before <wleslie>a message is sent before it is recieved, so the synchronisation only goes in one direction <wleslie>in CSP, both programs would engage in the one instantaneous message-send event, or they would use a queue to decouple the send into distinct stages <wingo>i think unbuffered channels are more expressive. you get a more expressive "select" and every message has an owner <wingo>if you add a queue to a buffered channel, messages in the queue are owned by the buffer thread etc <wingo>i liked after reading "using csp" that i could prove things about concurrent systems if i want <wingo>but i don't know if there is a similarly useful theory for systems with unbounded buffers everywhere <wingo>and the lack of backpressure in erlang systems means you apparently often have to build that yourself <wingo>so some of the difference goes away <wleslie>hmm. when you say select is more expressive, do you mean matching on several messages at once or so? <wingo>i mean like select { send a on ch1; send b on ch2 } only one of those messages will actually be sent <wingo>pseudosyntax above of course <wingo>which is nice for like select { receive on ch1; timeout after 1s } you will never get the event in limbo if the timeout event is the one that synchronizes <wingo>i mean the message on ch1 in limbo <wingo>that's what i mean by ownership, you never have messages just sitting in queues somewhere, unless you add a queue <wingo>incidentally go's default is still unbuffered channels and someone complained after fibers v0.2.0 saying that because fibers channels were singly buffered, that you couldn't do certain go things nicely <wingo>which, i don't know if that's a big deal <wingo>but it was like spawn { send 1 on ch1; receive from ch1 } || spawn { receive x from ch1; send x*2 on ch1 } <wingo>in a system with unbuffered channels, that works <wingo>it's like call and response, procedure-call like <wingo>but with buffers, the "send 1 on ch1" probably doesn't block, then the "receive from ch1" just pops off that 1 that we just sent <wleslie>'are you talking to me? or shall I talk to you?' <davexunit>wingo: congrats on the release. the new docs are interesting. <davexunit>wingo: timers are interesting. how often is the predicate called that checks if the expiry time has passed? <wingo>timers register themselves with the scheduler <wingo>the need for the predicate is just to check whether the operation was already performed by some other operation <wingo>e.g. (choice-operation (timer-operation 1) (timer-operation 1)) <ArneBab>davexunit: you can write a get request anywhere with an iframe. <paroneayea>I should also announce the new fibers thing, that's fun <paroneayea>also, I'm trying to turn this into a lesson for other projects so <paroneayea>wingo: is there a release tarball of fibers somewhere? <paroneayea>I'll post about it on the guile microblog accounts <davexunit>wingo: ah, I see. thanks. I'll read the implementation for resume-on-timer <paroneayea>wingo: btw, I don't have experience with erlang, but I do with other actor model systems <paroneayea>and I think that "reading on your inbox will block with no messages" is kind of the wrong way to think about it, from the actor models I've worked with.... though I guess it's true <paroneayea>I think the right perspective is that an actor gets "woken up" when a message appears in its inbox for it to process it. <ArneBab>wingo: the fibers docs read well, though I’m not yet at a point where I can use them. <ArneBab>wingo: one think I’d wish to see in the Manual is a cool example <amz3>ArneBab: AFAIK they are example in the sources ***bnw is now known as Guest21958
<ArneBab>wingo: to update: one thing I wish to see in the manual is a really prominent reference to fibers/examples ☺ ***Guest21958 is now known as bnw
<void-pointer>There, done with the main part of the unit-testing framework. All that is left is to choose a license and write the external documentation. <paroneayea>void-pointer: are you integrating or writing a unit test system for guile? or is this something else? <void-pointer>It was a good adventure, that is for sure. A lot of macro work. <void-pointer>Right now, it has full functionality and I just finished the unit tests for it <paroneayea>but I heard guile-lib has some stuff that builds on it <paroneayea>void-pointer: cool, post it to guile-user when you have something to show! <void-pointer>Basically, I wanted a version of SRFI-64 that would write TAP output (unfortunately, that does mean some features of SRFI-64 cannot be implemented) <void-pointer>So, I got test-begin, test-end, test-assert, test-eq, test-eqv, test-equal, test-approximate, test-error, and test-group-with-cleanup all implemented <void-pointer>And instead of doing test-skip and test-expect-fail as procedures/macros, the same functionality is handled as keyword arguments to the test macros <paroneayea>void-pointer: so what's the motivation behind not using srfi-64? <void-pointer>Just, one sadly cannot just keep nesting test-suites and one should know how many tests will be done up front (well, one can run and count later and adjust) <void-pointer>TAP output is much easier to integrate into automake, for one <void-pointer>That, and wanting to implement skipping and expected failures as keyword arguments <void-pointer>paroneayea: So, basically, all of the reasons you mentioned <void-pointer>paroneayea: oh, didn't see your mention of guile-lib till just now <void-pointer>I thought about using that, but I still don't know what license I am going to use for my project yet and the unit-test module in guile-lib is GPLv3 <void-pointer>That would only force the unit tests themselves to be GPLv3, not the whole package <paroneayea>void-pointer: though, sounds like you were trying to become more familiar with scheme too <paroneayea>and it sounds like this has been a good exercise for you <paroneayea>so even if you go with guile-lib, it sounds like not time wasted. <void-pointer>Needed to work with deep nesting of macros to really get the hang of them. Also, all of this gave me a bit more familiarity with the different functions in the scheme environment and in the modules including guile extensions. <void-pointer>There, just tested it on guile 2.0. It works on both 2.0.11 and 2.1.4 <void-pointer>The tests are triply or quadruply nested macros. The custom unit-testing I did to test the unit testing module nested the two levels further <void-pointer>I'm just happy I managed to keep the whole thing under 500 lines (that includes the comments and white space). <void-pointer>Hmm, now, what license to choose for it. Choices I am considering are LGPLv2.1+ (most likely), GPLv2+ (least likely), or BSD/MIT <void-pointer>Decently restrictive but still compatible with GPL 2 and 3, and LGPL 2.1 and 3 <void-pointer>Now, got to write some documentation for it. Going to do it in info, which I am somewhat new to (I am, however, very used to TeX and LaTeX)