00:04:13  * piscisaureus__joined
00:06:23  * piscisaureus_quit (Ping timeout: 245 seconds)
00:17:49  * piscisaureus__quit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:33:59  * tilgoviquit (Remote host closed the connection)
00:58:00  * alejandro[away]changed nick to alejandromg
02:19:01  * piscisaureus_joined
02:56:26  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
03:25:21  * bradleymeckjoined
03:32:43  * indutnyjoined
03:38:49  * bradleymeckquit (Quit: bradleymeck)
03:49:40  * alejandromgquit (Read error: Connection reset by peer)
03:54:13  * alejandromgjoined
05:52:22  * mmalecki[away]changed nick to mmalecki
06:32:10  * alejandromgquit (Quit: leaving)
07:16:57  * mmaleckichanged nick to mmalecki[away]
09:06:16  <indutny>creationix: https://github.com/indutny/candor/commit/3c73da62e2f476e498f7a47653fb80138ce99154
09:06:18  <indutny>cons strings implemented
09:06:31  <indutny>well, performance is not as fast as I would like it to be
09:06:40  <indutny>but at least much faster than regular concatenation
09:06:57  <indutny>it's 1.5x slower than in v8
09:07:00  <indutny>(approximately)
09:20:50  * Raynosjoined
12:05:25  * piscisaureus_joined
12:07:17  <indutny>piscisaureus_: hey man
12:07:50  <indutny>piscisaureus_: can you please take a look at this, once you'll have a free time: https://github.com/indutny/candor/commit/3c73da62e2f476e498f7a47653fb80138ce99154
12:08:00  <indutny>piscisaureus_: it's a cons string implementation for candor
12:08:18  <creationix>const strings wohoo!
12:08:21  <creationix>*cons
12:10:31  <creationix>did api.h not change?
12:11:03  <indutny>creationix: no
12:11:04  <indutny>:)
12:11:11  <indutny>creationix: morning
12:11:23  <indutny>creationix: creating can2c utlility for candor.io
12:11:36  <creationix>good idea
12:12:13  <creationix>what's the GC going to be in the C version
12:12:30  <indutny>GC?
12:12:32  <creationix>or is it just candor to candor API
12:12:42  <indutny>it's just for builtins
12:12:44  <indutny>:)
12:12:45  <indutny>lib/net.can
12:12:52  <indutny>js2c
12:12:57  <creationix>ahh, that kind of c
12:13:34  <creationix>but I was thinking, other than the GC, your compiler isn't that different from a static compiler right?
12:14:20  <piscisaureus_>indutny: I am not a gc expert. But I will look at the string functions.
12:14:23  <indutny>not really
12:14:30  <indutny>piscisaureus_: gc doesn't matter here
12:14:36  <indutny>piscisaureus_: but thanks :)
12:16:03  <piscisaureus_>indutny: how is queue implemented? as a linked list on the heap?
12:16:25  <indutny>piscisaureus_: in Flatten? as a stack in C++ heap memory
12:16:44  <indutny>but allocations are going inside zone, so it's quite fast
12:16:56  <indutny>"stack" as CS structure
12:20:04  <piscisaureus_>indutny: why do you create Cons-es with NULL on either side?
12:20:13  <indutny>piscisaureus_: on only one side actually
12:20:24  <piscisaureus_>indutny: it seems to me that that should be trivial to eliminate
12:20:26  <indutny>when cons string is flatten, right side is nulled and left will point to flattened string
12:20:33  <indutny>piscisaureus_: how's so?
12:20:51  <piscisaureus_>indutny: well what v8 does is it has an empty flat string object in the roots
12:21:06  <piscisaureus_>indutny: so if they flatten a string they make the rhs the empty string
12:21:13  <indutny>piscisaureus_: that's what I do
12:21:17  <indutny>except I use NULL
12:21:20  <piscisaureus_>indutny: so you can eliminate all the == NULL checks
12:21:25  <piscisaureus_>like, in push_grey etc
12:21:29  <indutny>aah
12:21:32  <indutny>I can put nil here
12:21:34  <indutny>good point
12:22:54  <indutny>piscisaureus_: fixed, thanks
12:27:25  <indutny>creationix: how are you doing that https://github.com/creationix/candor.io/blob/master/Makefile#L50
12:27:43  <indutny>If I'll put %.h here https://github.com/indutny/candor/blob/master/Makefile#L68
12:27:47  <indutny>everything will stop working
12:29:06  <creationix>hmm, that shouldn't work
12:29:10  <creationix>(mine)
12:29:22  <indutny>creationix: it starts running strange build commands for me
12:29:25  <creationix>oh nevermind
12:29:26  <indutny>with -Isrc/
12:29:43  <indutny>creationix: ?
12:30:26  <creationix>the only gotcha about make wildcards is the first dependencty needs to be the wildcard dependency
12:30:33  <creationix>I once put "build" first
12:30:38  <creationix>and very strange things happened
12:30:49  <indutny>hm...
12:31:28  <creationix>so make sure the %.h is after the %.cc
12:31:49  <creationix>$< is the first one
12:31:54  <indutny>well it is
12:32:00  <indutny>can you try adding this?
12:32:14  <creationix>ok
12:35:13  <creationix>indutny, seems to work, except not all your .cc files have .h files to go with them
12:35:56  <indutny>oh
12:36:01  <indutny>that may be the case!
12:36:21  <creationix>even empty files will help
12:36:30  <creationix>just something for make to check against
12:37:00  <creationix>`touch src/x64/fullgen-x64.h && touch src/x64/stubs-x64.h`
12:38:17  <indutny>hell yeah!
12:38:18  <indutny>:D
12:40:12  <indutny>creationix: thanks, https://github.com/indutny/candor/commit/895368106eb2f8f24e41bcc7e69c1120c322b159
12:40:41  <indutny>that means no more -B for candor.io and candor :)
12:40:42  <indutny>finally
12:41:36  <piscisaureus_>indutny: the cons string impl looks good to me
12:41:52  <indutny>piscisaureus_: cool, thanks for reviewing!
12:41:54  <piscisaureus_>indutny: I don't know whether your queue approach is faster than v8's recursive flattening
12:42:04  <indutny>piscisaureus_: wow
12:42:09  <indutny>piscisaureus_: how are they managing big depth?
12:42:27  <indutny>piscisaureus_: my recursive approach was segfaulting on cons with depth 200000
12:42:28  <piscisaureus_>indutny: they flatten out of order
12:42:48  <piscisaureus_>indutny: and they recurse on the short end and iterate on the long side
12:43:02  <indutny>piscisaureus_: hm... but both sides may be long
12:43:13  <indutny>cons + cons
12:43:13  <piscisaureus_>indutny: that means that you have to create a really big string to overflow the heap (so that the string wouldn't fit on the heap anyway)
12:43:34  <indutny>well, recursion is faster
12:43:35  <piscisaureus_>indutny: well you can only create such a situation by creating a tree shape
12:43:47  <indutny>piscisaureus_: that's it
12:44:02  <indutny>piscisaureus_: but also possible to do a = 'long-string' + a
12:44:11  <indutny>and tree will grow on right side
12:44:20  <piscisaureus_>indutny: yeah, so that triggers recursion once
12:44:40  <indutny>piscisaureus_: looks like I don't understand what kind of recursion you're talking about
12:44:45  <piscisaureus_>indutny: but then in the flatten function that is called recursively it will iterate over the long trail
12:44:56  <piscisaureus_>indutny: they make the recursion vs iteration decision every time
12:45:24  <piscisaureus_>indutny: btw - the v8 implementation of flattening to utf8 is really pathetic at the moment.
12:45:34  <piscisaureus_>because out of order flattening is not possible there
12:45:49  <creationix>piscisaureus_, you still working on string issues?
12:47:01  <piscisaureus_>creationix: unfortunately, yes
12:49:47  <piscisaureus_>creationix: so, do you have any comments on that?
12:51:02  <indutny>:)
12:51:14  <indutny>piscisaureus_: recursion thing looks very unstable to me
12:51:19  <indutny>but I may be wrong
12:52:19  <piscisaureus_>indutny: I don't think it is really unstable
12:52:57  <piscisaureus_>indutny: it is somewhat fragile because it relies on the fact that an allocation failure will happen before a flattening operation is started that might overflow the stack
12:53:09  <indutny>piscisaureus_: hehe
12:53:12  <indutny>piscisaureus_: yes, that's it
12:53:16  <indutny>piscisaureus_: but v8 has limited heap
12:53:23  <indutny>piscisaureus_: so they know it better
12:53:27  <indutny>piscisaureus_: candor's heap grow on-demand
12:54:03  <piscisaureus_>indutny: v8's heap can also grow on demand
12:54:19  <indutny>piscisaureus_: I thought it has an upper limit
12:54:31  <indutny>piscisaureus_: which should be specified before execution
12:54:49  <indutny>piscisaureus_: anyway, dunno how, but candor was segfaulting :D
12:54:54  <indutny>piscisaureus_: on stack overflow
12:55:19  <creationix>piscisaureus_, no, sorry, unicode is a mess
12:55:20  <piscisaureus_>indutny: yeah but on x64 you can now set the v8 heap limit to *crazy big*
12:55:27  <indutny>hehe
12:55:33  <indutny>piscisaureus_: what's the purpose of that limit, btw?
12:55:39  <creationix>I prefer languages where the string primitive is just binary data and then unicode is a library on top of that
12:55:45  <indutny>creationix: ++
12:55:46  <kohai>creationix has 6 cherry juices
12:55:47  <indutny>definitely
12:55:53  <indutny>two-byte string are awful
12:56:00  <indutny>piscisaureus_: isn't it? ;)
12:56:12  <indutny>s/string/strings
12:56:13  <creationix>well awful or not, it's javascript
12:56:15  <piscisaureus_>indutny: actually, I think that if you would make the v8 heap reallybig then you could trigger a stack overflow flattening. I don't think they considered the option
12:56:18  <creationix>the language isn't going away
12:56:31  <piscisaureus_>indutny: and segfaulting on stack overflow is expected
12:56:36  <indutny>piscisaureus_: yes
12:56:41  <piscisaureus_>indutny: because you will hit a guard page
12:56:48  <creationix>hmm new node vunlerability? ;)
12:56:52  <indutny>piscisaureus_: odd that it was happening on 200000 recursion iteration
12:56:58  <indutny>creationix: hahahaha
12:57:07  <piscisaureus_>creationix: well not one that will trigger in chrome
12:57:18  <indutny>creationix: and not on every node server
12:57:18  <piscisaureus_>creationix: or I would just have earned myself a new car :-p
12:57:25  <indutny>piscisaureus_: hey, that's my idea :)
12:58:36  <piscisaureus_>creationix: dunno if I agree with you on the binary strings thing
12:58:50  <piscisaureus_>creationix: but I do think that exposing the underlying representation makes sense
12:59:11  <piscisaureus_>or hmm
12:59:15  <piscisaureus_>maybe not
12:59:24  <piscisaureus_>indutny: https://github.com/v8/v8/blob/master/src/objects.cc#L6728-6778
13:00:37  <indutny>piscisaureus_: recursion
13:01:26  <creationix>piscisaureus_, I guess it depends on what the language is for. If you only deal with character strings, then why not treat the contents as characters. Unicode is good for that.
13:01:49  <indutny>piscisaureus_: well, the thing is that you need a 2^N -1 strings to get depth (N-1)
13:01:56  <creationix>piscisaureus_, but in networking, byte strings are pretty common
13:03:05  <creationix>that's a lot of strings
13:03:26  <indutny>yes
13:03:32  <creationix>1^(N-1) won't work becuse it iterates in single chains right?
13:03:51  <indutny>sorry?
13:04:17  <creationix>well, does the tree have to have two children at every node (be a full binary tree)
13:04:44  <piscisaureus_>creationix: yeah, that's why languages need a native buffer type, and an easy way to cast buffers to strings and vice versa (preferrably zero copy)
13:05:14  <indutny>piscisaureus_: just memcpy in candor :)
13:05:24  <creationix>piscisaureus_, then there is mutability of these buffers
13:05:49  <creationix>in most cases, you don't need mutable buffers, just a way to build up buffers
13:06:28  <piscisaureus_>indutny: yeah but given that the minimum cons length is 8 you also need to allocate (2^N-1)*8 bytes before you can flatten a string which requires depth N
13:06:28  <creationix>cons buffers where the nodes can be things like UInt32, Int8, char[17], etc
13:06:47  <indutny>piscisaureus_: 13
13:07:01  <indutny>piscisaureus_: at least in my trunk's clone
13:07:11  <piscisaureus_>indutny: I think in v8 it's 8 or so
13:07:23  <indutny>piscisaureus_: I seen const=13
13:07:37  <indutny>piscisaureus_: // minimum length for a cons string.
13:07:37  <indutny> static const int kminlength = 13;
13:07:48  <indutny>src/objects.h
13:08:11  <piscisaureus_>ah, right
13:08:38  <piscisaureus_>indutny: although this does not mean that a cons can never be shorter than 1
13:08:45  <indutny>piscisaureus_: of course
13:08:50  <indutny>piscisaureus_: it's just for runtime
13:09:03  <indutny>but concatenating "1" + "1" will end in normal string
13:09:11  <piscisaureus_>indutny: if you do "verylongstring + 'a'" then I think it will always make another cons
13:09:20  <indutny>that's too
13:09:52  <piscisaureus_>indutny: so if you do `for(;;) s += 'a';` then you will end up with conses of 1
13:10:13  <creationix>piscisaureus_, indutny, do either of you know if it would be faster to pass uv_write the flattened string or the invidual parts as a vector?
13:10:58  <piscisaureus_>creationix: umm. uv-win has no support for writev except for tcp atm :-(
13:11:24  <creationix>so then uv would have to flatten it or is it a ton of syscalls?
13:12:34  <piscisaureus_>creationix: well right now libuv just asserts if you use writev on a pipe or on a file
13:12:39  <piscisaureus_>creationix: not on unix of course
13:12:52  <creationix>ouch
13:13:02  <piscisaureus_>creationix: but on unix it should be faster with one caveat
13:13:20  <piscisaureus_>creationix: libuv will malloc memory to store the vectors if you do uv_write
13:13:49  <piscisaureus_>creationix: so if you send a lot of vectors that point to strings that are only a couple bytes in size the overhead of that is probably bigger than just flattening
13:14:01  <piscisaureus_>creationix: but if the strings are long then yes, writev is preferrable
13:14:13  <piscisaureus_>(just checked the situation with ben too)
13:14:18  <creationix>hmm
13:14:29  <creationix>so malloc does have memory overhead
13:14:33  <piscisaureus_>creationix: yes
13:14:37  <creationix>I was wondering how it knew how much to free
13:14:54  <piscisaureus_>creationix: but memory overhead is not so much of the issue - it's the time overhead :-)
13:15:04  <creationix>yeah, malloc is kinda slow
13:15:17  <creationix>I have noticed that
13:15:42  <piscisaureus_>creationix: btw - I take patches for writev support :-p
13:16:04  <piscisaureus_>creationix: although I am afraid your religion does not allow you to write patches for uv-win
13:16:09  <creationix>ok, so the case that I'm using candor cons strings to build large binary strings out of thousands of tiny (~4byte) chunks, it's better to flatten in candor
13:16:21  <piscisaureus_>creationix: yeah definitely
13:16:37  <creationix>piscisaureus_, hey, I have two windows machines on my desk
13:16:47  <creationix>(they just happen to both be booted into linux atm)
13:16:53  <piscisaureus_>creationix: you should consider that if the string is small than flattening requires you to copy 4 bytes
13:17:11  <piscisaureus_>creationix: creating a vector means setting a pointer and a length which is 16 bytes :-)
13:17:18  <piscisaureus_>creationix: kinda obvious innit ;-)
13:17:56  <creationix>I guess I can't reuse the candor pointers since it's a tree and writev needs a flat vector
13:18:44  <piscisaureus_>creationix: also, the sweet spot is probably with bigger strings, because of (a) the malloc overhead and (b) the overhead of the kernel accessing userspace pages.
13:19:11  <piscisaureus_>creationix: which requires validation of those pages etc. The more pages involved, the more pain we have to incur.
13:21:03  * bnoordhuisjoined
13:21:17  <bnoordhuis>creationix: speak to me
13:22:35  <indutny>oooh
13:22:39  <indutny>who's there :)
13:22:54  <indutny>btw, malloc is badly working when called from different threads
13:23:11  <bnoordhuis>depends on the malloc implementation
13:23:19  <bnoordhuis>glibc's is quite smart
13:23:40  <indutny>bnoordhuis: yes, various implementations suffers from different things :)
13:28:52  <creationix>bnoordhuis, hello
13:29:07  <indutny>piscisaureus_: https://github.com/indutny/candor/commit/aedc93fce7cf01ea736d45bfd81a1f925ea2a19b
13:29:21  <creationix>bnoordhuis, what about C++ new?
13:29:49  <indutny>creationix: the same hell
13:29:57  <indutny>AFAIK
13:30:11  <creationix>wow multithreading cross-platform sucks
13:30:17  <indutny>hahaha
13:30:23  <indutny>hell yes
13:30:42  <indutny>cross-platform *anything* sucks
13:31:05  <creationix>people are wanting me to add threading and writev support to luvit
13:31:12  <creationix>I see now that will make windows support even more painful
13:31:30  <creationix>actually, threading via uv_work_t should be safe right?
13:31:41  <creationix>(I would treat it like a webworker)
13:31:59  <creationix>or use candor Isolate in candor.io
13:32:10  <creationix>with uv_work_t
13:32:20  <indutny>err
13:32:24  <indutny>do not rely on that now :)
13:32:33  <indutny>Isolate is not really thread-safe now
13:32:39  <indutny>Isolate::GetCurrent() needs to be fixed
13:32:50  <indutny>and Zone should be relocated into isolate (which is simple)
13:34:04  <indutny>but yeah, Isolate is very cheap
13:34:15  <indutny>probably much chepear than in v8
13:34:26  <creationix>ok, so eventually, we can use Isolate for threading
13:34:31  <indutny>if you'll reduce initial heap size from 2mb to 200kb
13:34:41  <indutny>creationix: yes
13:34:45  <indutny>creationix: but data sharing is a problem
13:34:52  <creationix>for sure
13:34:56  <piscisaureus_>indutny: lgtm
13:34:56  <indutny>I do not want to implement parallel GC
13:34:59  <indutny>piscisaureus_: cool! :)
13:35:02  <indutny>piscisaureus_: it even works :D
13:35:18  <creationix>so each Isolate won't have it's own gc?
13:35:18  <indutny>piscisaureus_: thanks
13:35:19  <piscisaureus_>creationix: libuv has threading support
13:35:23  <indutny>creationix: it will
13:35:28  <piscisaureus_>creationix: uv_thread_create etc
13:35:34  <piscisaureus_>creationix: as well as locks
13:35:42  <piscisaureus_>even SRW locks
13:35:44  <indutny>creationix: in languages with natural thread support, Parallel GC is used
13:35:49  <creationix>piscisaureus_, is that new? I don't remember seeing that
13:35:58  <indutny>creationix: but in candor - Mark-Copying
13:36:17  <creationix>indutny, yeah, I'm fine with each isolate not sharing anything
13:36:26  <indutny>ok
13:36:36  <indutny>though, it's possible to move to shared data
13:36:44  <indutny>if we really will want that
13:36:59  <creationix>could you transfer a candor object between isolates
13:37:05  <indutny>creationix: by copying
13:37:10  <indutny>recursive copying
13:37:14  <creationix>so it's never shared, but doesn't require a copy or serialize/deserialize?
13:37:38  <creationix>I guess deep copy is easier
13:37:50  <indutny>it's essentially the same thing as serialize/deserialize
13:37:55  <creationix>the language doesn't have the concept of losing ownership of an object
13:37:57  <indutny>well, sort of
13:38:08  <indutny>creationix: it's just impossible in current heap implementation
13:38:20  <creationix>I don't need it any time soon
13:38:23  <indutny>creationix: heap is a continuous region of memory
13:38:38  <indutny>creationix: so separate heaps have separate chunks of memory
13:38:46  <creationix>I see
13:38:52  <creationix>so it has to copy at the moment
13:38:57  <bnoordhuis>creationix: sorry, back
13:39:08  <bnoordhuis>had to explain the basics to bert, you know how it is
13:39:09  <indutny>yes
13:39:10  <creationix>though, a recursive C++ copy is probably fast enough
13:39:27  <creationix>bnoordhuis, heh, try explaining C/C++ to me ;)
13:39:40  <bnoordhuis>creationix: new and new[] are backed by malloc on most if not all platforms
13:39:54  <creationix>bnoordhuis, ok then
13:40:18  <bnoordhuis>you can do pool-based allocation with placement new btw
13:40:31  <bnoordhuis>if you're afraid of the overhead of new / new[], that is
13:40:43  <indutny>creationix: aka Zone
13:40:54  <indutny>creationix: and freelist
13:41:16  <creationix>luvit does naive malloc all over the place and it's still twice as fast as node
13:41:16  <indutny>as I know malloc adds some tagging to bytes that it allocates
13:41:22  <indutny>to determine sizeof chunk
13:41:27  <creationix>the vm seems to make a larger difference
13:41:46  <creationix>indutny, that makes sense
13:47:48  * Raynosquit (Read error: Connection reset by peer)
13:47:53  * indutnyquit (Ping timeout: 246 seconds)
13:59:12  <piscisaureus_>creationix: https://github.com/joyent/libuv/blob/master/include/uv.h#L1410-1440
14:26:02  * indutnyjoined
14:26:27  <indutny>creationix: heya
14:26:37  <indutny>it works, thanks :)
14:31:43  <creationix>:)
14:37:00  <indutny>interesting
14:37:09  <indutny>I'm not operator of this channel
14:37:15  <indutny>are you?
14:40:37  * indutny_joined
14:49:18  * Raynosjoined
14:52:11  <creationix>indutny, you need to msg chanserv
14:52:17  <creationix>I assume you registered the channel
14:52:24  <indutny>yes
14:52:31  <indutny>I registered it
14:52:34  <indutny>but /op doesn't work
14:52:40  <indutny>should I message it about it?
14:52:47  <creationix>so I think it's /msg ChanServ op #luvit indutly
14:52:55  <creationix>(minus typos)
14:53:10  <indutny>hell yeah :)
14:53:12  <indutny>thanks once again
14:53:16  <creationix>I lost my op status a while back when my creationix.com server restarted
14:53:19  <creationix>you have to give it to me
14:53:21  <creationix>chanserv won't
14:53:27  <creationix>(if you want me to have it that is)
14:55:17  <creationix>indutny, I wonder if we should rename "new" to be "clone"
14:55:24  <creationix>"new" may confuse people
14:55:39  <indutny>that's what I thought too
14:55:46  <indutny>creationix: https://github.com/creationix/candor.io/pull/3
14:56:06  <indutny>creationix: can you put that on mailing list?
14:56:12  <indutny>creationix: trying to keep everyone notified
14:56:22  <indutny>(I mean new=>clone)
14:56:24  <creationix>sure
14:59:28  <indutny>cool
14:59:29  <indutny>thank you
15:01:58  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
15:06:04  * piscisaureus_joined
15:07:13  <indutny>ok, it builds on osx now :)
15:07:20  <indutny>now time to fix those stupid segfaults
15:08:17  <creationix>:)
15:10:19  <indutny>crap RuntimeLookupProperty assertion
15:21:12  * bradleymeckjoined
15:21:30  * bradleymeckquit (Client Quit)
15:27:57  <indutny>ok, fixed
15:34:27  * piscisaureus_quit (Ping timeout: 265 seconds)
15:34:30  <indutny>or not :(
15:35:43  <indutny>or yes :D
15:51:50  <indutny>creationix: basically, it fails now, because you're putting Handle<Object>* in req->data and then using it as Object*
16:07:18  * bradleymeckjoined
16:19:58  <creationix>indutny, where is that?
16:20:39  <creationix>UVData::VoidToObject ?
16:25:31  * piscisaureus_joined
16:38:23  <creationix>indutny, I thought I was storing UVData* instances in ->data
16:51:07  * piscisaureus__joined
16:51:45  * piscisaureus_quit (Read error: Connection reset by peer)
16:55:13  * bnoordhuisquit (Ping timeout: 264 seconds)
17:07:29  * hij1nxjoined
17:19:28  * alejandromgjoined
17:28:29  * tilgovijoined
17:37:58  <indutny_>sorry
17:38:03  <indutny_>missed your messages
17:38:11  <indutny_>creationix: ^
17:56:15  * piscisaureus__quit (Quit: ~ Trillian Astra - www.trillian.im ~)
17:58:09  * piscisaureus_joined
18:04:49  * hij1nxquit (Quit: hij1nx)
18:05:49  * indutnychanged nick to indutny_znc
18:05:49  * indutny_changed nick to indutny
18:15:31  * hij1nxjoined
19:23:03  * tilgoviquit (Ping timeout: 245 seconds)
19:31:04  <indutny>creationix: ping
19:31:27  <indutny>creationix: if you'll have a free minute, can you please ammend README.md in candor to include latest changes in syntax and API
19:31:58  <creationix>ok
19:32:01  <creationix>pretty busy day though
19:32:05  <indutny>creationix: thank you!
19:32:18  <indutny>creationix: that's not urgent, we all do our work first :)
19:51:59  * piscisaureus_quit (Ping timeout: 252 seconds)
19:52:35  * piscisaureus_joined
20:48:15  * bradleymeckquit (Quit: bradleymeck)
21:54:25  <piscisaureus_>creationix: I have some template trickery lying around that I wrote for you
21:54:31  <piscisaureus_>creationix: are you still interested in that?
21:54:40  <piscisaureus_>I think I did it 2 weeks ago or so
22:00:52  * tilgovijoined
22:05:30  <creationix>piscisaureus_, I could look at it to learn
22:05:35  <creationix>but I think I like what I have right now
22:07:42  <piscisaureus_>creationix: alright then
22:07:46  * tilgoviquit (Read error: Connection reset by peer)
22:07:49  <piscisaureus_>creationix: I will flush the code
23:09:31  * tilgovijoined
23:32:13  * tilgovi_joined
23:32:25  * tilgoviquit (Ping timeout: 264 seconds)