00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:05:39  * rendarquit (Quit: Leaving)
00:11:59  * seishunquit (Ping timeout: 264 seconds)
00:12:28  * c4milo_joined
00:12:44  * c4miloquit (Ping timeout: 245 seconds)
00:22:44  * chris_99quit (Quit: Ex-Chat)
00:29:34  * quijotejoined
00:31:02  * c4milo_quit (Remote host closed the connection)
00:34:31  * quijotequit (Ping timeout: 272 seconds)
00:37:48  * dsantiagoquit (Read error: Connection reset by peer)
00:39:15  * dsantiagojoined
00:47:49  * toothrotquit (Ping timeout: 272 seconds)
00:52:00  * wolfeidaujoined
00:57:29  * andrehjrjoined
01:05:43  * stagasquit (Ping timeout: 256 seconds)
01:16:00  * toothrotjoined
01:30:19  * quijotejoined
01:34:37  * quijotequit (Ping timeout: 240 seconds)
02:03:34  * tjkrusinskijoined
02:19:54  * c4milojoined
02:24:34  * c4miloquit (Ping timeout: 255 seconds)
02:31:01  * quijotejoined
02:35:49  * quijotequit (Ping timeout: 256 seconds)
03:31:57  * quijotejoined
03:36:22  * quijotequit (Ping timeout: 240 seconds)
03:46:17  * tjkrusinskiquit (Ping timeout: 240 seconds)
03:55:07  * warehouse13quit (Quit: Leaving)
03:55:28  * tjkrusinskijoined
04:08:52  * c4milojoined
04:14:17  * c4miloquit (Ping timeout: 272 seconds)
04:22:33  * andrehjrquit (Quit: Computer has gone to sleep.)
04:32:33  * quijotejoined
04:37:19  * quijotequit (Ping timeout: 255 seconds)
05:00:00  * tjkrusinskiquit (Ping timeout: 264 seconds)
05:21:26  * andrehjrjoined
05:28:45  * AlsoDirksonchanged nick to dirkson
05:29:51  * andrehjrquit (Quit: Computer has gone to sleep.)
05:33:19  * quijotejoined
05:38:02  * quijotequit (Ping timeout: 265 seconds)
05:57:44  * c4milojoined
06:02:19  * c4miloquit (Ping timeout: 245 seconds)
06:14:46  * petka_quit (Quit: Connection closed for inactivity)
06:34:03  * quijotejoined
06:38:34  * quijotequit (Ping timeout: 245 seconds)
07:29:26  * cb0joined
07:34:52  * quijotejoined
07:39:17  * quijotequit (Ping timeout: 240 seconds)
07:46:38  * c4milojoined
07:51:04  * c4miloquit (Ping timeout: 245 seconds)
08:05:15  * rmgjoined
08:09:49  * rmgquit (Ping timeout: 245 seconds)
08:10:51  * dsantiagoquit (Quit: Computer has gone to sleep.)
08:14:24  * cb0quit (Remote host closed the connection)
08:35:37  * quijotejoined
08:40:15  * quijotequit (Ping timeout: 265 seconds)
08:51:02  * stagasjoined
09:19:37  * quijotejoined
09:22:20  * rendarjoined
09:35:34  * c4milojoined
09:39:33  * hij1nxjoined
09:39:57  * c4miloquit (Ping timeout: 240 seconds)
09:41:34  <hij1nx>uv_fs_read, when it doesn't get a callback, should return the number of bytes read into the buffer?
09:43:19  <hij1nx>yep
09:43:26  <hij1nx>figured it out :)
09:44:03  <hij1nx>my goodness i love libuv, i sit down to write code with it and it just works. <3
10:04:44  <txdv>how
10:04:51  <txdv>a lot of people complain but you dont
10:06:07  <txdv>hij1nx: what do you think is so good about libuv\?
10:06:14  <txdv>are you using C or C++?
10:20:43  <hij1nx>txdv: im just tinkering -- https://github.com/hij1nx/nodeuv-fs
10:21:33  <txdv>callback hell in c++
10:21:34  <txdv>why not
10:22:49  <txdv>https://github.com/libuv/libuv/wiki/Projects-that-use-libuv
10:22:54  <txdv>you might want to check this
10:22:59  <txdv>there are already a bunch of c++ bindings
10:23:06  <txdv>which have been abandoned
10:23:10  * Left_Turnjoined
10:23:20  <txdv>i love it how the open source community usually has the attention span and interest rate of a cat
10:24:23  * quijotequit (Ping timeout: 240 seconds)
10:25:28  <hij1nx>txdv: im not writing bindings
10:25:34  <hij1nx>txdv: that's already been done
10:25:54  <txdv>A friendly c++1y wrapper for libuv's filesystem operations
10:26:00  <txdv>it literally says in the readme that you are doing that
10:26:03  <hij1nx>txdv: im just writing some small libs that bring the node user experience to c++
10:26:25  <txdv>this is what bindings in other language are all about
10:26:54  <hij1nx>"a wrapper" isn't exactly "c++ bindings"
10:27:08  <hij1nx>c++ bindings, i would expect to be a directl 1:1 mapping
10:27:51  <txdv>no
10:27:52  <txdv>stop
10:28:29  <txdv>i dont need to fight with anyone over the difference of c++ wrapper and binding on the internet
10:28:51  <hij1nx>who's fighting?
10:29:01  <hij1nx>that's not what this room is about.
10:29:11  <hij1nx>we are here because we enjoy using libuv.
10:29:30  <txdv>why are you writing a wrapper if you enjoy using libuv?
10:30:19  <hij1nx>txdv: oh snap, you are right... hmm... not sure what i was thinking ;)
10:30:56  <txdv>im just kidding
10:32:52  * tkelmanjoined
10:33:22  <txdv>hij1nx: i think node.native wraps it already in c++11
10:33:44  <txdv>hij1nx: whta is c++1y supposed to mean?
10:34:00  <rendar>txdv, its the new standard of c++
10:34:00  <txdv>are you waiting for 2016 to release a wrapper with specific c++16 features?
10:34:58  <txdv>i mean c++14
10:35:06  <txdv>still in draft
10:42:28  * tarrudajoined
10:52:57  * SergeiRNDjoined
10:54:19  * SergeiRNDquit (Client Quit)
11:01:08  * quijotejoined
11:03:29  * quijotequit (Read error: Connection reset by peer)
11:03:42  * quijotejoined
11:11:03  * quijote_joined
11:11:04  * quijotequit (Read error: Connection reset by peer)
11:24:30  * c4milojoined
11:27:19  * Left_Turnquit (Ping timeout: 245 seconds)
11:29:10  * c4miloquit (Ping timeout: 258 seconds)
11:38:21  * Left_Turnjoined
11:54:37  * quijote_quit (Ping timeout: 264 seconds)
11:57:30  * am11joined
12:11:35  * quijotejoined
12:16:05  * quijotequit (Ping timeout: 256 seconds)
12:16:09  * quijote_joined
12:16:16  * quijote_quit (Remote host closed the connection)
12:17:21  * chris_99joined
12:36:36  * jan____joined
12:37:46  * jan____quit (Changing host)
12:37:46  * jan____joined
12:48:24  * petka_joined
12:59:37  * [spoiler]joined
13:03:32  <am11>hello, since libuv is single threaded, what is the purpose of uv_loop_new ? Can we instantiate a new loop and uv_run / uv_stop it, while the uv_default_loop is awaiting return somewhere else?
13:05:54  * tjkrusinskijoined
13:13:16  * c4milojoined
13:14:35  * AvianFlujoined
13:18:17  * c4miloquit (Ping timeout: 252 seconds)
13:21:52  <txdv>am11 every thread can have its own loop
13:21:59  <txdv>nodejs has only one loop
13:24:25  <am11>txdv: is it ok to uv_run and then uv_stop the default_loop, while it is already blocked (waiting for return)?
13:24:39  <txdv>no
13:24:56  <txdv>i don't know why you are using uv_run in your binding
13:25:01  <txdv>you really shouldn't
13:27:04  <txdv>if you run compile_it or whatever that sass function is
13:27:19  <txdv>it is blocking for the hole duration until it returns
13:27:45  <txdv>that is the idea of a Sync function
13:28:06  <txdv>if you have Sync function, make the importer return synchronously as well
13:28:17  <txdv>if you have an async function, make the importer take a callback
13:29:39  <txdv>then you will have no need for for running the loop yourself
13:29:47  <txdv>and you have a consitent and clear api
13:30:58  <am11>for the renderSync, the default loop is blocked. so uv_async_send is not going anywhere. in render (async), we call compile_it on uv_queue_work, so uv_async_send runs as soon uv_cond_wait is called.
13:32:06  <txdv>you don't need uv_async_send for renderSync
13:32:31  <txdv>there is literally no need to run anything anywhere but in the main loop
13:34:37  * tjkrusinskiquit (Ping timeout: 255 seconds)
13:37:16  <am11>if i move uv_async_send inside the condition (before uv_cond_wait), the renderSync calls freeze. From the the pure C++ funciton (sass_importer() in our case), how else we can pass the call to libuv?
13:38:42  <txdv>you run compile_it synchronously
13:38:52  <txdv>it calls the function importer synchronously
13:39:18  <txdv>and uses the return value immediately, instead of passing an argument that you have to call back
13:39:25  <txdv>you don't need to pass anything to it
13:39:35  * tjkrusinskijoined
13:43:52  <am11>ok then I will add a sync version of dispatched_async_uv_callback(), which just takes ctx_w and retun immediately? Then perhaps NanScope would not be avaiable in it..
13:46:04  * chris_99quit (Quit: Ex-Chat)
13:46:15  <txdv>I don't really think that you understood what i want
13:46:21  <txdv>maybe i should just code it for you
13:48:12  <am11>:)
13:48:20  <am11>do you mean we should call the async version the same way (synchronously from sass_importer)?
13:50:15  <txdv>describe to me how you are calling the sync version currently
13:50:21  <txdv>and what signature the importer function in the js world has
13:53:07  <txdv>everyone is afk
13:53:12  <txdv>where is saghuuuuuuuuuuuuul
13:54:35  <am11>First, in the NANMETHOD(RenderSync) or NANMETHOD(RenderFileSync), we create a sass_context and sass_wrappper_context (same as their async variants). then we fill the options and call compile_data (or compile_file in RenderFileSync). While in async variants we call compile_it via uv_queue_work, which selects either compile_file or compile_data (based on the context).
13:55:47  <am11>when libsass calls sass_importer, we check if the call was async, use uv_run approach on the default loop (which is already blocked, waiting for response)
13:56:43  <am11>js has this signature: function(url,previous,done) { /*done is optional, you can just return synchronously like this*/ return {file: url};}
13:56:51  <am11>this is the user side..
13:57:16  <txdv>why ar eyou calling uv_run on the default loop?
13:57:39  <am11>we catch the return and call the binding.ImportedCallback(result_from_user)
13:58:25  <am11>because if the uv_run is not used, it doesn't call the dispatcher method (uv_async_send)
13:59:09  <am11>in case of async, sine the uv_queue_work has freed the default loop, uv_async_send works there
13:59:46  <am11>(but uv_run deosn't work with async, i don't know why..)
14:00:00  <am11>so that's why we have two approaches
14:12:48  <txdv>why do you need to uv_async_send when you are doing a synchronous operation?
14:13:52  <txdv>the only reason why you are doing uv_async_send in the first place is because if you are doing an ASYNC request you are in a different thread
14:13:58  <txdv>now you are in the same one
14:17:49  <am11>oh that's right. then I will just refactor the code to make render*Sync only accept sync imports.
14:17:58  <am11>(and keep the async as is)
14:18:58  <txdv>praise the lord
14:19:24  <txdv>the importer function of the async passes a done callback which has to be called
14:19:37  <txdv>the importer function of the sync variant has to return it immediately
14:20:31  * tjkrusinskiquit (Ping timeout: 258 seconds)
14:20:32  <am11>yes this is exactly how it will be :)
14:21:06  <am11>renderSync({importer: function(url, prev){return {file:blah}}})
14:21:21  <am11>render({importer: function(url, prev, done){done({file:blah})}})
14:24:17  <txdv>so you do understand now that there is no need for calling uv_run
14:26:13  <am11>yes. in sync case, i will just call a function which will simply call js and return value immediately.
14:36:44  * tjkrusinskijoined
14:48:34  * andrehjrjoined
14:52:23  * tjkrusinskiquit (Ping timeout: 244 seconds)
15:00:08  * andrehjrquit (Quit: Computer has gone to sleep.)
15:21:09  * seishunjoined
15:55:19  <am11>txdv: tada! https://github.com/am11/node-sass/commit/018094257cc29e28ff2d58cc564299b52dec7da8 8-)
15:55:31  <am11>its fixed! :D
15:56:12  <am11>but (yet again).. another segmentation fault when running the tests. this time in "stats"
15:57:22  * tkelmanquit (Ping timeout: 246 seconds)
16:00:27  * tarrudaquit (Ping timeout: 272 seconds)
16:15:14  * bradleymeckjoined
16:17:43  * wolfeidauquit (Remote host closed the connection)
16:18:13  * wolfeidaujoined
16:18:25  * SergeiRNDjoined
16:21:31  * rmgjoined
16:26:11  * rmgquit (Ping timeout: 265 seconds)
16:44:02  * tjkrusinskijoined
16:57:22  * [spoiler]quit (Quit: Leaving)
17:03:06  * c4milojoined
17:07:46  * bradleymeckquit (Quit: bradleymeck)
17:07:57  * c4miloquit (Ping timeout: 244 seconds)
17:10:56  * andrehjrjoined
17:14:36  * SergeiRNDquit (Quit: Leaving.)
17:21:36  * dsantiagojoined
17:23:47  * dsantiagoquit (Max SendQ exceeded)
17:24:35  * dsantiagojoined
17:43:25  * c4milojoined
17:44:06  * SergeiRNDjoined
17:48:48  * wolfeidauquit (Remote host closed the connection)
17:49:17  * wolfeidaujoined
17:53:11  * rvaggquit (Ping timeout: 272 seconds)
17:55:09  * rvaggjoined
18:35:27  * wolfeidauquit (Remote host closed the connection)
18:35:55  * wolfeidaujoined
18:44:04  * andrehjrquit (Quit: Computer has gone to sleep.)
18:56:55  * tarrudajoined
19:13:30  * tarrudaquit (Ping timeout: 244 seconds)
19:36:02  * bradleymeckjoined
19:36:20  * andrehjrjoined
19:46:18  * andrehjrquit (Quit: Computer has gone to sleep.)
20:00:49  * c4miloquit
20:19:47  * SergeiRNDquit (Quit: Leaving.)
20:22:08  * dsantiagoquit (Quit: Computer has gone to sleep.)
20:33:18  * brsonjoined
20:35:06  <txdv>am11: what stats?
20:37:49  * SergeiRNDjoined
20:39:51  * bradleymeckquit (Quit: bradleymeck)
20:57:12  * bradleymeckjoined
21:05:22  * chris_99joined
21:09:07  * andrehjrjoined
21:13:34  * SergeiRNDquit (Quit: Leaving.)
21:15:13  * LOUDBOT_quit (Remote host closed the connection)
21:15:19  * LOUDBOTjoined
21:17:32  * chris_99quit (Quit: Ex-Chat)
21:17:55  * bradleymeckquit (Quit: bradleymeck)
21:27:55  * bradleymeckjoined
21:32:29  * bradleymeckquit (Client Quit)
21:37:35  * tarrudajoined
21:44:25  * chris_99joined
21:44:28  * chris_99quit (Changing host)
21:44:28  * chris_99joined
21:52:32  * andrehjrquit (Quit: Computer has gone to sleep.)
21:53:30  * andrehjrjoined
22:04:45  * chris_99quit (Quit: Ex-Chat)
22:05:19  * chris_99joined
22:19:29  <am11>txdv: its a object which initially JS creates and adds startTime to it, then pass it to C++, which fills includedFiles: all the imported files which libsass encountered during the compilation, libsass returns us an array and we fill stats in GetStats() method.. which i think should be renamed to get_stats :)
22:21:42  <txdv>you cant modify v8 objects in a different thread
22:22:32  <txdv>i dont know if you are doing that, but that comes to my mind
22:24:47  <am11>actually we are marking it Persistent using NanAssignPersistent https://github.com/sass/node-sass/blob/8075bd62b1a58ccd7f2ec0a41d6225df30412e30/src/binding.cpp#L69
22:26:23  <am11>which should persist the state of the object (as the name suggest). before it used to store only stats with source-map, i changed it to store the whole result with map, stat and generated css. (this way map don't get in output twice)
22:41:28  * OrangeDuckjoined
22:42:11  <OrangeDuck>Does libuv have a source distribution I can just compile with "configure & make & make install" or do I need to use autotools?
22:45:15  <txdv>you can compile with gyp
22:45:50  <txdv>otherwise you will need gyp
22:46:37  <OrangeDuck>thanks
22:48:40  <txdv>i mean otherwise you will need autotools
22:53:21  <OrangeDuck>man
22:53:26  <OrangeDuck>no gyp for python 3
22:54:02  <am11>2.7 works fine
22:54:26  <am11>just mock it :)
22:58:18  <OrangeDuck>okay :)
23:25:07  * seishunquit (Ping timeout: 252 seconds)
23:39:25  * Ralithquit (Ping timeout: 252 seconds)
23:41:08  * Ralithjoined
23:46:52  * Ralithquit (Ping timeout: 240 seconds)
23:48:48  * Ralithjoined
23:50:48  <am11>txdv: if i do stress testing (by pasting a same piece of code multiple times in a file and then copy paste in njs at once), after running few chunks it throws: node: ../deps/uv/src/unix/core.c:199: uv__finish_close: Assertion `0' failed.\nAborted
23:50:53  <am11>on Ubuntu 12