00:02:02  <creationix>woohoo, updated http benchmark to use new http decoder and I’m getting around 160,000 requests/second
00:02:30  <creationix>25% of all cores are uses in the bench client. I tried to do the test over ethernet, but it turns out usb to ethernet cables are a nice bottleneck
00:08:39  * kazuponjoined
00:10:48  * travis-cijoined
00:10:48  <travis-ci>luvit/luvit#1365 (http-decoder - ea5c7c0 : Tim Caswell): The build passed.
00:10:48  <travis-ci>Change view : https://github.com/luvit/luvit/compare/01282ce15dc3^...ea5c7c08b648
00:10:48  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/43539014
00:10:48  * travis-cipart
00:13:02  * kazuponquit (Ping timeout: 265 seconds)
00:16:54  * DarkGodquit (Ping timeout: 245 seconds)
00:36:46  * dan336joined
00:38:43  * dan336quit (Client Quit)
01:13:30  * kazuponjoined
01:24:08  * dan336joined
01:36:12  * kazuponquit (Remote host closed the connection)
01:39:52  * dan336quit (Read error: Connection reset by peer)
01:42:29  * kazuponjoined
03:02:55  <rphillips>creationix: memory usage?
03:03:16  <creationix>for the benchmark. I doubt it’s much, I can run again and see
03:05:50  * kazuponquit (Remote host closed the connection)
03:06:36  <creationix>rphillips: the 4 worker processes cap about 6mb
03:06:47  <creationix>master is 4mb
03:07:45  <creationix>If I use luvi-tiny to build luvit it’s just over 3mb each
03:07:53  <creationix>(this is linux x64)
03:12:01  * travis-cijoined
03:12:01  <travis-ci>luvit/luvit#1367 (luvi-up - 5bd2090 : Tim Caswell): The build passed.
03:12:01  <travis-ci>Change view : https://github.com/luvit/luvit/compare/8414cfb0b4cc...5bd2090cbc69
03:12:01  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/43552166
03:12:01  * travis-cipart
03:12:07  * kazuponjoined
03:26:55  <rphillips>nice
03:32:18  <rphillips>https://github.com/luvit/luvit/pull/564
03:32:44  <rphillips>emitting the exit after the uv.close seems to fix the lockup
03:33:29  * travis-cijoined
03:33:29  <travis-ci>luvit/luvit#1368 (fixes/emit_exit_on_nexttick - 003c7b4 : Ryan Phillips): The build passed.
03:33:29  <travis-ci>Change view : https://github.com/luvit/luvit/commit/003c7b4e7093
03:33:29  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/43553102
03:33:29  * travis-cipart
03:38:56  * kazuponquit (Remote host closed the connection)
03:47:25  * cledevquit (Quit: Leaving)
03:49:00  * cledevjoined
03:52:00  * travis-cijoined
03:52:00  <travis-ci>luvit/luvit#1370 (fixes/emit_exit_on_nexttick - 4f3ee94 : Ryan Phillips): The build passed.
03:52:00  <travis-ci>Change view : https://github.com/luvit/luvit/compare/003c7b4e7093...4f3ee941646a
03:52:00  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/43553961
03:52:00  * travis-cipart
03:59:06  <creationix>rphillips: why wait till close to delete handle? Wouldn’t it be safer to delete it right after close returns?
04:01:40  <rphillips>hmm yeah. ill patch that
04:02:48  <creationix>less race conditions help us sleep at night when this goes into production
04:18:25  * kazuponjoined
04:19:59  * cledevquit (Ping timeout: 260 seconds)
05:27:26  * cledevjoined
05:27:45  <rphillips>fixed
05:28:22  * travis-cijoined
05:28:22  <travis-ci>luvit/luvit#1372 (fixes/emit_exit_on_nexttick - e87abcc : Ryan Phillips): The build passed.
05:28:22  <travis-ci>Change view : https://github.com/luvit/luvit/compare/4f3ee941646a...e87abccc607c
05:28:22  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/43557854
05:28:22  * travis-cipart
05:46:11  * cledevquit (Ping timeout: 250 seconds)
05:50:36  * a_lequit (Ping timeout: 256 seconds)
05:51:51  * a_lejoined
06:16:34  * travis-cijoined
06:16:34  <travis-ci>luvit/luvi#220 (feat/add_win_svc - 4895657 : Rob Emanuele): The build passed.
06:16:34  <travis-ci>Change view : https://github.com/luvit/luvi/commit/48956574c004
06:16:34  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/43559804
06:16:34  * travis-cipart
09:30:37  * cledevjoined
09:39:01  * prontotestjoined
09:39:01  * prontotestpart
10:37:25  * kazuponquit (Remote host closed the connection)
13:03:28  * cledevquit (Ping timeout: 265 seconds)
14:06:39  * cledevjoined
14:57:39  <rphillips>child process stdin:write() has a bug on windows
14:58:53  <rphillips>the tls-server-verify should work on windows, but the stdin:write() never gets written back to the client connection in the subprocess
15:24:39  * KennethWilkejoined
15:39:01  * dan336joined
16:11:34  <KennethWilke>good morning
16:15:38  <rphillips>morning
16:20:54  <KennethWilke>i'm hitting something of a race condition today, from a script similar to: https://raw.githubusercontent.com/luvit/luvit/luvi-up/examples/tcp-uv-proxy.lua
16:22:44  <KennethWilke>when i use a uv_pipe_t socket for listening sometimes i get a SIGPIPE when the client disconnects and the upstream responds to the client around the same time
16:23:07  <rch>it sounds like the write is writing before the client disconnect is observed?
16:23:09  <KennethWilke>it's not always, and i think it's in the same epoll() call
16:23:15  <KennethWilke>yeah it does
16:23:21  <KennethWilke>with tcp sockets it doesn't seem to happen
16:23:35  <rch>SIGPIPE is only for pipes right
16:23:40  <KennethWilke>yeah
16:24:01  <KennethWilke>is there a way i could just capture that signal?
16:24:06  <KennethWilke>that'd suffice for my needs
16:24:20  <rch>probably the write call should have a check in it to see if the pipe is still valid
16:24:46  <rch>but maybe there's a cooler way to fix it
16:25:43  <rch>KennethWilke: not sure if this is exposed in luvit (yet) but imo if you really think you need to catch SIGPIPE you should set the handler to SIG_IGN
16:26:39  <rch>in master i see this: _luv_register_signal_handler(SIGPIPE, SIG_IGN);
16:26:50  <KennethWilke>i'm not familiar with that signal
16:26:50  <rch>in luvit_init.c
16:27:00  <rch>i wonder if that's not in the luvi-up branch
16:27:06  <KennethWilke>but that call would just like, use the SIG_IGN handler for SIGPIPE events?
16:27:13  <rch>it's not a signal it's an enum telling the kernel to ignore the signal (ign = ignore)
16:27:24  <KennethWilke>ahhh okay
16:27:31  <KennethWilke>yeah i'd prefer that over a handler
16:27:40  <rphillips>yeah, we need to ignore SIGPIPE
16:27:40  <KennethWilke>there's nothing i want to occur when that gets thrown
16:28:02  <rch>rphillips: shouldn't it be handled in the write call instead?
16:28:38  <rphillips>node ignores it globally
16:28:48  <rch>ok
16:28:59  <rch>so the luvi-up branch is missing the line i showed above which is in master
16:29:08  <rphillips>https://github.com/joyent/node/blob/master/src/node.cc#L3456
16:29:40  <rch>cool
16:29:47  <rch>any shortcut node takes must be fine for us
16:30:52  <rphillips>KennethWilke: you should be able to add it like this https://github.com/luvit/luv/blob/master/tests/test-signal.lua
16:36:36  <KennethWilke>awesome, ty, will give that a try
16:47:29  * endou_____quit (Ping timeout: 258 seconds)
16:50:21  * Michalikquit (Ping timeout: 260 seconds)
16:52:20  * KennethWilkequit (Quit: Leaving)
17:00:55  <creationix>mornin'
17:01:36  <rphillips>morning
17:01:45  * UniOnjoined
17:03:01  * KennethWilkejoined
17:05:11  * travis-cijoined
17:05:11  <travis-ci>luvit/luvit#1374 (luvi-up - 56b4f6b : Ryan Phillips): The build passed.
17:05:11  <travis-ci>Change view : https://github.com/luvit/luvit/compare/5bd2090cbc69...56b4f6b2385d
17:05:11  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/43619177
17:05:11  * travis-cipart
17:06:46  <KennethWilke>setting up that signal handler did the trick, now i can also handle sigint properly, woo!
17:11:42  <creationix>KennethWilke: nice
17:13:35  <KennethWilke>i was very surprised how efficient it is to concatenate buffers and make one write operation vs multiple writing calls
17:13:47  <creationix>yeah, syscalls are expensive
17:14:08  <creationix>now libuv does support sending an array of buffers, but I didn’t expose that to lua because it’s complicated
17:14:21  <creationix>it could be added if it ever made a real difference to an app
17:14:38  <KennethWilke>like i was getting 1.2k reqs per second doing multiple stream:write calls
17:14:47  <KennethWilke>and 20k when i concatenate first and make a single write call
17:14:58  <creationix>nice
17:15:16  <KennethWilke>i did try passing an array to write to see if it'd use that libuv feature
17:15:52  <KennethWilke>and it was like
17:15:55  * KennethWilkeflips table
17:15:56  <creationix>I should add that
17:15:57  <KennethWilke>this isnt a string!
17:16:00  <creationix>lol
17:16:14  <creationix>EFLIPSTABLE
17:16:23  <KennethWilke>lol
17:16:27  <KennethWilke>SIG_FLIP
17:17:03  <creationix>task noted https://github.com/luvit/luv/issues/100
17:17:08  <KennethWilke>woo!
17:17:23  <KennethWilke>i'd be curious to see if that'd be a lil faster than concatenating
17:17:53  <KennethWilke>my gut says it'd be slightly faster at least
17:18:00  <KennethWilke>but it's been wrong before
17:18:27  <KennethWilke>i also have no idea what lua is doing under the hood to concat things
17:19:23  <creationix>lua does mem copy
17:19:38  <creationix>which is “slow”, but fast and slow are relative
17:19:45  <creationix>system calls are one of the more expensive things you can do
17:20:01  <KennethWilke>yeah
17:20:04  <KennethWilke>dat context switching
17:20:13  <creationix>memcpy is much faster than system calls, especially for tiny strings
17:20:25  <KennethWilke>and this was with tiny requests
17:32:45  <KennethWilke>i was more wondering what kinda way it was organizing that stuff in heap
17:33:12  <KennethWilke>if the strings buffer was big enough already, or if it was realloc()ing or something
17:33:46  <creationix>not sure. I do know that pointers are stable in lua, the GC doesn’t move them around
17:33:56  <creationix>(which is probably why they don’t implement string chains)
17:34:42  <creationix>luajit is a hybrid of a hand-written interpreter in assembly and a JIT compiler
17:34:47  <creationix>so who knows what fancy tricks it does
17:35:48  <KennethWilke>lol i tried running it through ltrace
17:35:54  <KennethWilke>but ltrtace did some callstack too deep error
17:37:28  <rphillips>creationix: are exceptions being caught? when I write a test with a syntax error the process is hanging... not dumping the exception
17:37:39  <creationix>they should print
17:39:05  <rphillips>hmm. perhaps they are... there was a string concat with a nil
17:39:41  <rje>does libuv have any synchronization objects? (events, mutexes, i wouldn't mind an event)
17:40:17  <creationix>rphillips: I tihnk there could be a bug in the tap library
17:40:25  <creationix>it might be hanging on line 92
17:41:09  <creationix>I should probably call uv.stop() to cancel any pending handles in case of error
17:41:19  <rphillips>that might be it
17:41:35  <creationix>try putting a uv.stop() before the uv.run()
17:43:01  <creationix>also there is concern that throwing errors inside of uv.run() is dangerous
17:43:14  <creationix>I don’t pcall when calling callbacks. I let exceptions crash uv.run
17:43:24  <creationix>(it helps get meaningful stack traces)
17:45:12  <KennethWilke>rje, i think it has some sync primitives
17:45:35  <creationix>rje: yes, libuv has all sorts of stuff like that
17:45:37  <KennethWilke>i try to avoid using them though, because of the types of performance problems they can do
17:45:40  <creationix>I’m just not sure how to expose them to lua
17:45:50  <creationix>if you think of a good way to expose it, I’ll add it to luv
17:46:17  <creationix>http://docs.libuv.org/en/v1.x/threading.html
17:46:18  <KennethWilke>http://docs.libuv.org/en/v1.x/threading.html
17:46:23  <KennethWilke>hay! stop that
17:46:24  <KennethWilke>:p
17:46:39  <creationix>lol
17:46:41  <rje>k, thanks :) i'm not sure i'm going to need them yet. they're plan b.
17:47:15  <creationix>one idea I had was to revive dvv’s old experiment and create lua workers in threads
17:47:19  <KennethWilke>i hear you on that, i always like to handle my things like an assembly line
17:47:31  <creationix>they would have independent lua states and their own uv loop
17:47:37  <KennethWilke>that way no step in whatever process interacts with any others
17:48:21  <rje>i'm writing the windows service example right now and trying to make do without them
17:49:10  <KennethWilke>still handy that libuv provides cross platform sync primitives though
17:49:37  <creationix>yep, and the other section I didn’t bind was the dlopen stuff
17:49:50  <creationix>lua can’t handle C pointers and luajit ffi already does all that on it’s own
17:50:22  <KennethWilke>the ffi thing is still new to me
17:50:36  <KennethWilke>i really like the way the ctypes python lib handles interactions with shared objects
17:50:45  <KennethWilke>i dunno what it does, but it seems like magic
17:51:03  <creationix>yeah, luajit ffi has less sugar
17:51:09  * endou_____joined
17:51:14  <creationix>but it’s way faster than ffi in any other runtime. It’s embedded deep in the jit itself
17:52:00  <creationix>one of these days I plan on wrapping libuv to be poll based instead of callback based and interacting with it purely via ffi
17:52:16  <creationix>it should be crazy fast and require less C code
17:52:24  <creationix>(though a lot more lua code for the ffi bindings)
17:52:35  <KennethWilke>yeah and that ffi code looks less pretty
17:53:30  <creationix>you can ffi libuv today, but that requires passing c callbacks via the ffi which is very slow
17:56:00  <creationix>rphillips: did adding the uv.stop() help?
17:56:34  <rphillips>haven't tried it yet
17:57:37  <creationix>rphillips: ok, pushed the tweak to luvi-up
17:57:45  <creationix>it should be safer than before
17:57:50  <rphillips>cool. thanks
18:07:57  * travis-cijoined
18:07:57  <travis-ci>luvit/luvit#1375 (luvi-up - 55bb4a1 : Tim Caswell): The build passed.
18:07:57  <travis-ci>Change view : https://github.com/luvit/luvit/compare/56b4f6b2385d...55bb4a1ad4ea
18:07:57  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/43626490
18:07:57  * travis-cipart
18:10:06  * Michalikjoined
18:28:09  <creationix>rphillips: KennethWilke https://github.com/luvit/luv/pull/101
18:34:41  <creationix>hmm, gets ENOTSUP error on windows. Is the vector form of write not supported on windows?
18:38:16  * travis-cijoined
18:38:16  <travis-ci>luvit/luv#197 (vector-writes - b514920 : Tim Caswell): The build passed.
18:38:16  <travis-ci>Change view : https://github.com/luvit/luv/compare/a707d9c78332^...b514920d4649
18:38:16  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/43629309
18:38:16  * travis-cipart
18:41:28  <rphillips>https://github.com/luvit/luvit/pull/565
18:50:13  * travis-cijoined
18:50:13  <travis-ci>luvit/luvit#1376 (feat/null_cipher_test - 5510d51 : Ryan Phillips): The build has errored.
18:50:13  <travis-ci>Change view : https://github.com/luvit/luvit/commit/5510d512f502
18:50:13  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/43630690
18:50:13  * travis-cipart
18:52:30  * travis-cijoined
18:52:30  <travis-ci>luvit/luvit#1378 (feat/null_cipher_test - 7bb18ce : Ryan Phillips): The build failed.
18:52:30  <travis-ci>Change view : https://github.com/luvit/luvit/compare/5510d512f502...7bb18ce20236
18:52:30  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/43630844
18:52:30  * travis-cipart
18:57:50  * travis-cijoined
18:57:50  <travis-ci>luvit/luv#198 (vector-writes - 5e1b4d8 : Tim Caswell): The build passed.
18:57:50  <travis-ci>Change view : https://github.com/luvit/luv/compare/b514920d4649...5e1b4d817f88
18:57:50  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/43631280
18:57:50  * travis-cipart
19:04:21  <rch>KennethWilke: how did you get a reference to SIG_IGN?
19:05:10  <KennethWilke>oh i didn't do that, i just set an empty function as its handler
19:05:45  <KennethWilke>'uv.signal_start(sigpipe, "sigpipe", function() end)'
19:05:52  <rch>huh
19:06:01  <rch>i guess the difference is minimal
19:06:11  <rch>where is the constants module defined? can't find it
19:06:47  <KennethWilke>and the sigpipe first argument is my 'local sigpipe = uv.new_signal()'
19:07:09  <rch>right
19:11:49  <creationix>rch, this one? https://github.com/luvit/luv/blob/master/src/constants.c
19:12:38  <rch>aha! thanks
19:12:47  <rch>my submodule must not have been updated or something
19:13:22  * DarkGodjoined
19:14:06  <rch>so SIG_IGN is defined as an invalid function ptr
19:17:12  <rch>creationix: do you think the right way to make SIG_IGN available is to expose it in constants.c with lua_pushcfunction? even though it is defined as a funky macro: #define SIG_IGN ((__sighandler_t)1) /* ignore signal */
19:17:40  <creationix>where is that passed in to luv?
19:17:59  * travis-cijoined
19:17:59  <travis-ci>luvit/luvit#1380 (feat/null_cipher_test - 52eeab9 : Ryan Phillips): The build was fixed.
19:17:59  <travis-ci>Change view : https://github.com/luvit/luvit/compare/7bb18ce20236...52eeab913eb0
19:17:59  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/43633621
19:17:59  * travis-cipart
19:18:20  <creationix>and as long as __sighandler_t is an integer, it’s fine to expose it as an integer
19:18:50  <rch>oh I guess that would work fine, __sighandler_t is a function *
19:19:39  <creationix>hmm ,interesting
19:20:40  <rch>signal.h does it with different macro types but same result, 1
19:21:12  <rch>as long as equality operators work on the value maybe it doesn't matter between lua_pushcfunction and lua_pushinteger
19:21:39  <creationix>well, pushcfunction only takes a certain shape of C pointer
19:22:01  <creationix>int (*name)(lua_State *)
19:22:59  <rch>oh i thought that only mattered if you called the function.
19:23:15  * rchimagines calling void (*1)()
19:23:51  <creationix>so yeah, we can add SIG_IGN as 1, but where does lua pass that valie back to C?
19:24:06  <rch>great question, let me see
19:28:27  * travis-cijoined
19:28:27  <travis-ci>luvit/luv#200 (vector-writes - 8a7e905 : Tim Caswell): The build passed.
19:28:27  <travis-ci>Change view : https://github.com/luvit/luv/compare/5e1b4d817f88...8a7e905ccedf
19:28:27  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/43634482
19:28:27  * travis-cipart
19:29:39  <rch>creationix: yeah there's no way that can work. i think the best solution is to define SIG_IGN like KennethWilke did as `function() end`
19:29:58  <rch>Comparison will still work on it, and it will have the same effect as SIG_IGN intends.
19:30:32  <rch>since SIG_IGN isn't an enum, it's a special function ptr the kernel treats natively, i don't think there's any good way to represent it in lua space
19:31:35  <rch>comparisons on it will work work well
19:31:49  <rch>might be all that matters
19:45:10  <creationix>I could wrap the SIG_IGN in a lua C function that then calls it. Does it actually do anything?
19:45:43  <creationix>or allow the integer 1 in the signal API and special case it to pass SIG_IGN to libuv
19:46:40  * songgaoquit (Remote host closed the connection)
19:48:51  * larmejoined
19:51:27  <creationix>nah, libuv doesn’t accept SIG_IGN directly, it only accepts special libuv callbacks
19:52:29  <creationix>I could just make the callback optional in signal:start, then if you don’t pass one in, it just ignores the signal
19:57:35  <rphillips>rje: https://github.com/Squirrel/Squirrel.Mac
19:57:43  <rphillips>https://github.com/Squirrel/Squirrel.Windows
19:57:57  <rphillips>sorta interesting... it's the updater for atom
19:58:07  <creationix>rphillips: I was about to say, that’s the one used in atom
19:58:18  <rphillips>it doesn't seem to work with windows services
19:58:35  <rje>huh, neat.
20:07:51  <creationix>rch: KennethWilke: https://github.com/luvit/luv/pull/102
20:09:32  <KennethWilke>looks good to me
20:14:04  * travis-cijoined
20:14:04  <travis-ci>luvit/luvit#1382 (luvi-up - bf5c20b : Ryan Phillips): The build passed.
20:14:04  <travis-ci>Change view : https://github.com/luvit/luvit/compare/55bb4a1ad4ea...bf5c20b47a6a
20:14:04  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/43639181
20:14:04  * travis-cipart
20:15:33  * travis-cijoined
20:15:33  <travis-ci>luvit/luv#202 (improve-signal-start - 40a8799 : Tim Caswell): The build passed.
20:15:33  <travis-ci>Change view : https://github.com/luvit/luv/commit/40a8799539ab
20:15:33  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/43638968
20:15:33  * travis-cipart
20:28:27  <KennethWilke>hmm
20:29:12  <KennethWilke>this isn't really something i use often, but my interactive interpreter seems to have some sillyness
20:29:38  <KennethWilke>Welcome to the Luvit repl!
20:29:39  <KennethWilke>> local test="hello"
20:29:39  <KennethWilke>> print(test)
20:29:39  <KennethWilke>nil
20:29:54  <KennethWilke>looks like it garbage collects between lines
20:30:12  <KennethWilke>if i do 'local test="hello" print(test)' i get the expected output
20:30:39  <KennethWilke>and if i run a script through the interpreter it's fine as well, of course
20:38:09  <rphillips>creationix: is that how the signal handling works in libuv?
20:38:39  <creationix>KennethWilke: it’s not GC, it’s that each line in the repl runs in an independent local scope
20:38:42  <creationix>that’s the nature of eval
20:38:48  <creationix>just don’t use local in the repl
20:38:55  <KennethWilke>ahhh! okay
20:39:09  <KennethWilke>i just wanted to make sure that's expected behavior
20:39:48  <creationix>rphillips: I think that as long as you have a signal handler registered in libuv, it will ignore the signal
20:40:08  <creationix>it’s not ass effecient as `signal(SIGPIPE, SIG_IGN)`, but you can’t go that low in libuv
20:40:26  <creationix>the C callback will be called, but if you ommitted the lua callback, the C callback won’t do anything
20:40:41  <creationix>slightly faster than a noop lua callback
20:41:49  <rphillips>gotcha
21:08:10  <rch>huh interesting
21:17:20  * travis-cijoined
21:17:20  <travis-ci>luvit/luv#204 (master - 1757b39 : Tim Caswell): The build passed.
21:17:20  <travis-ci>Change view : https://github.com/luvit/luv/compare/2ae54a46f972...1757b39ef4fa
21:17:20  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/43645713
21:17:20  * travis-cipart
22:09:59  * UniOn_joined
22:11:02  * UniOnquit (Ping timeout: 258 seconds)
22:29:48  <rphillips>https://www.hakkalabs.co/articles/optimizing-go-3k-requestssec-480k-requestssec
22:29:56  <rphillips>haven't went through this yet, but looked interesting
22:30:34  <KennethWilke>ooo
22:32:18  <rje>rphillips, creationix: this is what the service api use is going toward in lua, opinions? https://github.com/rjemanuele/lua_winsvc/blob/master/examples/complete.lua
22:32:48  <rch>neat
22:34:01  <rje>rch, i had to scrap the port of luaservice to luvi as it wasn't working well. this is working out better as more of a windows service api wrapper
22:34:13  <creationix>wow, never realized services could be so complicated
22:34:22  <creationix>but I like the idea of mapping closely to the windows APIs
22:35:01  <rje>its pretty close, i needed a few other windows functions that i'm putting in that aux module.
22:35:39  <rje>its nice of msvc to use whatever for whitespace :/
22:36:07  <rje>creationix, i wonder about calls like this https://github.com/rjemanuele/lua_winsvc/blob/master/examples/complete.lua#L154
22:36:17  <rje>would it be better to wrap them in a pcall?
22:36:18  <rphillips>slick
22:36:36  <rje>that way the error could be caught qucik
22:38:43  <KennethWilke>rphillips: where's the silver bullet in that video?! :p
22:38:56  <creationix>if the user wants to ignore the error sometimes, I like to return assert friendly style
22:39:04  <rphillips>KennethWilke: haven't watched it yet
22:39:05  <creationix>so they can wrap it in assert when they want to catch the error
22:39:18  <creationix>success/value, err
22:39:19  <rje>creationix, so like it is now
22:39:37  <creationix>well, except in case of error, you should return the error string as the second return value
22:39:52  <rje>got it
22:39:53  <creationix>so the user doesn’t have to look it up themself with winsvcaux.GetLastErrorString())
22:40:42  <rje>yeah that made me itch
22:41:16  <creationix>but if the user rarely wants to ignore the error, go ahead and error() inside instead of returning
22:41:22  <creationix>then they can’t foget to check for error
22:41:25  <creationix>*forget
22:41:56  <creationix>generally I do assert style for low-level stuff and throw in high-level stuff
22:43:03  <rje>hrm. i hate fuzzy. hate to pick where to draw that line
22:43:29  <creationix>since this is for luvi, use assert style then
22:44:30  <rje>kk
22:45:17  <rje>fyi http://roy-t.nl/index.php/2013/09/04/lua-syntax-highlighting-in-visual-studio-2012-and-visual-studio-2013-preview/
22:47:04  <KennethWilke>rphillips: there's not a lot of juicy data in that video :\
22:47:06  <KennethWilke>it teases!
22:47:16  <rphillips>bummer
22:48:04  <KennethWilke>though in that realm of things, i recommend this long video: https://www.youtube.com/watch?v=73XNtI0w7jA
22:48:33  <KennethWilke>a common thread is making lock free structures, minimizing memory copying and context switching
22:50:36  <KennethWilke>the 480k reqs in go video says to use pointers instead of copying buffers, the c10m video gets into pedantic territory recommending using flatter C structures to avoid cache misses and all sorts of crap
22:51:44  * cledevquit (Ping timeout: 256 seconds)
22:52:59  <KennethWilke>also i think the 'processing' 480k reqs per second benchmark is considering all that data is already loaded in application memory, i was thinking he was talking about handling requests but he's talking about analyizing logs
22:59:08  <creationix>Almost done with a pure lua readline module for luvit
22:59:16  <KennethWilke>ooo nice
22:59:16  <creationix>I just can’t repl without it, I’m spoiled
22:59:23  <KennethWilke>i hear you
22:59:34  <creationix>the last part is Control Left Arrow to jump left one word
22:59:37  <KennethWilke>i got like ^[[C^[[D all ove rit
22:59:46  <creationix>turns out nagtive pattern matches are tricky in lua
22:59:54  <KennethWilke>there's always perl!
23:00:05  <KennethWilke>lol
23:13:37  <creationix>got it https://github.com/luvit/luvit/blob/0b8802e9d1a61de706c84adac46e6933675ac0a1/app/modules/readline.lua#L194-L208
23:13:54  <creationix>KennethWilke: if you want to play around, just run that file in luvit. It has a test at the bottom
23:14:06  <creationix>the history management isn’t quite right, but it seems to work great otherwise
23:16:18  <KennethWilke>yeah looks pretty good
23:16:24  <KennethWilke>i have a request!
23:16:29  <KennethWilke>ctrl+w support :D
23:16:34  * travis-cijoined
23:16:34  <travis-ci>luvit/luvit#1383 (readline - 0b8802e : Tim Caswell): The build passed.
23:16:34  <travis-ci>Change view : https://github.com/luvit/luvit/commit/0b8802e9d1a6
23:16:34  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/43658225
23:16:34  * travis-cipart
23:18:45  <KennethWilke>i think ctrl+w just removes from current cursor position until it hits whitespace
23:19:22  <KennethWilke>and if it's mid whitespace, it'll remove whitespace, then text until it hits whitespace
23:23:14  <KennethWilke>i'm gonna head outa here, y'all have a good'n!
23:24:00  * KennethWilkequit (Quit: Leaving)
23:26:13  <dan336>KennethWilke: are using luvi for a load balancer right?
23:26:35  <dan336>dan missed him.
23:27:53  * cledevjoined
23:57:08  * dan336quit (Quit: Leaving.)