00:19:57  * happy-dudequit (Quit: Connection closed for inactivity)
00:25:30  * rcyrjoined
00:30:44  * dap_quit (Quit: Leaving.)
00:50:57  * rcyrchanged nick to systemfault
01:16:30  * Ruyijoined
01:24:48  <hij1nx_>txdv: ping
01:42:41  * Fishrock123quit (Remote host closed the connection)
01:57:57  * Perilous_quit (Ping timeout: 250 seconds)
02:07:18  * PerilousApricotjoined
02:10:15  * happy-dudejoined
02:11:14  * Fishrock123joined
02:28:05  * brsonquit (Quit: leaving)
02:57:12  * tunniclm_quit (Ping timeout: 276 seconds)
03:11:50  * Fishrock123quit (Remote host closed the connection)
03:34:09  * PerilousApricotquit (Remote host closed the connection)
03:34:54  * PerilousApricotjoined
03:39:37  * frandagostinoquit (Ping timeout: 252 seconds)
03:43:00  * Fishrock123joined
04:09:27  * Fishrock123quit (Quit: Leaving...)
04:38:24  * frandagostinojoined
04:41:33  <txdv>hij1nx_: pong?
05:18:54  * frandagostinoquit (Ping timeout: 276 seconds)
05:43:53  * seishunjoined
05:59:23  * PerilousApricotquit (Remote host closed the connection)
06:54:41  * rmgquit (Remote host closed the connection)
06:55:17  * rmgjoined
06:57:14  * Dirksonjoined
06:59:48  <Dirkson>Hey all. I'm having some horrible issues with uv_async_send. Since it coalesces calls, I can't actually use the uv_async_t data type to send data - If I send an int, it's likely to be dropped on the floor. If I send a pointer, it's likely to drop the *pointer* on the floor, ensuring a data leak. Am I actually intended to send data via uv_async_Send? If so, how? If not, why does it have uv_async_t->data?
06:59:49  * rmgquit (Ping timeout: 252 seconds)
07:03:25  <txdv>use a queue
07:03:55  <Dirkson>txdv: Oh, is that provided?
07:04:09  <txdv>lock the queue, add the your item to the queue, unlock it, send a notification with uv_send, on receiving lock the queue, dequeue all elements, unlock the queue, enjoy the use of all your elements
07:04:21  <txdv>Dirkson: i dont think so
07:04:30  <Dirkson>I feel like this has bitten me before. Maybe I should be scrawling "uv_asynt_send does not send, and does not have data, despite having a data member" across the top of my uv files.
07:05:19  <txdv>if you do 2 uv_async_sends and the other event loop doesn't manage to handle the first 'send' then it will coalese them together, you are right
07:05:39  <Dirkson>Which drops either data or pointers on the floor.
07:06:00  <txdv>i dont understand what you want to say with 'drops data or pointers on the floor'
07:07:14  <Dirkson>txdv: If it coalesces calls, then I lose whatever data was in uv_async_t->data. If that's a pointer, I now have a memory leak. Therefore, I really can't imagine a scenario where passing data into uv_async_t's data member works.
07:07:29  <txdv>yes that is true
07:07:55  <txdv>as i said, i would just use a queue and use uv_send like a notification system that there is some data in the queue
07:08:12  <txdv>the queue will take care of 'decoalescing' or whatever you want to call it
07:08:52  <Dirkson>txdv: Yeah, I think this is probably a good way to move forward. I'm just frustrated this bit me again. I'm really displeased with a function called 'send' that LOOKS like it can send data being completely unable to send data
07:09:29  <txdv>I remember raising some concern about this
07:09:40  <txdv>but the janitors said it is supposed to be like that
07:09:50  <txdv>'there are no guarantees that for each send there will be a callback'
07:09:57  <txdv>it might get coalesed, as you said
07:10:14  <txdv>https://github.com/txdv/LibuvSharp/blob/master/LibuvSharp/AsyncWatcher.cs
07:10:17  <txdv>this is how i deal with it
07:10:33  <Dirkson>Removing its data member would help. And removing the really REALLY broken example using its data member in the documentation would help more.
07:10:54  <txdv>can you give me a link to that exmaple?
07:11:09  <Dirkson>txdv: Ah, this is a bit greek to me. More a C guy than a C++ one.
07:11:13  * seishunquit (Ping timeout: 244 seconds)
07:11:13  <Dirkson>txdv: Yeah, hold on a tick.
07:11:38  <txdv>Dirkson: the code is very minimal
07:13:29  <txdv>it does exactly what I said, create a queue with every uv_async_t and then on the queue, enques, deques, dispatches
07:14:33  <txdv>but yeah, maybe i will try to push it as a change
07:14:40  <txdv>Dirkson: is it coalescing on windows or linux?
07:16:04  <Dirkson>txdv: https://nikhilm.github.io/uvbook/threads.html - Most of the way down the page, the first example in the "Inter-thread communication" section. The example ONLY works when the pointer is global to all libuv functions using it, and is never freed. I've never really seen anyone use a pointer like that. Most real world implementations are going to want to break one of those two things... and fall afoul of the
07:16:06  <Dirkson>warning below the example. Like... It's technically correct, especially with the warning right there, but ooooh-so-misleading.
07:16:23  <Dirkson>txdv: I'm on linux. I haven't tested the windows build behavior.
07:17:02  <txdv>i remember that it coalesces on one but not on the other
07:17:12  <txdv>so i guess it does it on linux
07:17:21  <Dirkson>Interesting!
07:19:32  <txdv>it has bitten many asses in this channel
07:19:51  <txdv>and i am for implementing a variant where it does not coalesce the calls
07:20:40  <Dirkson>Makes sense. For the time being, I'm just going to do your queue idea. That's a solid one : )
07:21:49  <txdv>Dirkson: libuv may also combine multiple calls to uv_async_send and invoke your callback only once
07:21:53  <txdv>in the warning tooltip
07:21:55  <txdv>in that documentation
07:22:01  <txdv>second sentence
07:23:18  <Dirkson>txdv: Yup. It's there, and I'm sure I've read it before, but that data member keeps leading me down the wrong path. Most other data members in libuv *can* be trusted for this sort of thing.
07:23:30  <Dirkson>... I think. Now I'm less certain of myself.
07:24:23  <txdv>the others have a uv_req where the data member lives
07:24:50  <txdv>this one doesnt
07:24:50  <Dirkson>That sounds familiar
07:25:35  <txdv>the data member of this one is associated only with the handle itself
07:27:07  <txdv>you are using async_t data member therefore obviously if you use it twice in different places you are going to overwrite it
07:27:23  <txdv>if i were you i would store the queue pointer in there
07:28:12  <Dirkson>Ugh. Yeah, you're right.
07:44:51  <Dirkson>txdv: Thanks for the help and for letting me sound my frustrations : )
07:51:42  <txdv>you are welcome
07:51:53  <txdv>what are you coding with libuv?
07:52:01  * rendarjoined
07:53:05  <Dirkson>txdv: https://scrumbleship.com/ - Spacegame! More current video: https://www.youtube.com/watch?v=yi71aoDFZ2E
07:55:39  <txdv>looks like minecraft
07:55:43  <txdv>did you write it with C?
07:56:11  <Dirkson>I get that a lot. It's a bit different, although there's a solid Minecraft influence. Yup, plain C all the way through.
07:56:33  <txdv>looks like it has already a lot of people playing it
07:56:48  <Dirkson>There's a bit of a community. Still small.
07:57:47  <txdv>are you the only developer?
07:58:33  <Dirkson>Yup. Although we occasionally have community members contributing resources or patches.
07:59:47  <Ralith>Dirkson: uv_async_send is purely for notification, it is not a message passing mechanism in and of itself
07:59:57  <Ralith>the data member functions exactly the same way the data member of every other uv struct does
07:59:57  * happy-dudequit (Quit: Connection closed for inactivity)
08:00:12  <Ralith>i.e. it is not special in any way
08:01:02  <Ralith>the "documentation" that you linked is both unofficial and very old
08:01:23  <Ralith>strongly recommend referring to the up-to-date official documentation and/or the source code
08:01:39  <Dirkson>Ralith: The name and data member make it solidly misleading, at least for me. I'm at least partially frustrated at myself, because I'm pretty sure it's bitten me before.
08:02:17  <Ralith>the data member is identical in every way to the data member of every other libuv struct; changing it would be a poor design decision
08:02:25  <Dirkson>Ralith: docs.libuv.org is the official documentation?
08:02:34  <Ralith>indeed
08:03:28  <Dirkson>Ralith: From a user perspective - I can use every other data member I'm aware of to send data from one portion of libuv to another. But this one I cannot. I realize this probably makes internal sense, but it's pretty darn confusing once you get to the bits of libuv exposed to me.
08:04:34  <Ralith>the intended use of the data members is to associate user data with a specific handle so that it can be recovered in that handle's callbacks
08:04:54  <Ralith>this is true uniformly of every handle type
08:05:01  <Ralith>I'm not sure why you expect async to work differently
08:06:36  <Ralith>the 'data' field is in fact defined as part of the handle type and merely inherited by async, as it is by every other handle type
08:07:12  <txdv>also in other place you use uv_req to store the data and not the handle itself
08:07:53  <txdv>but still, people get confused, he is not the first one
08:08:06  <Ralith>leaving that aside, it's prudent to make a point of very carefully studying the documentation of any parallelism-related operations you're using
08:08:10  <Ralith>assumptions there will almost always cause bugs
08:09:21  <txdv>http://docs.libuv.org/en/v1.x/async.html <- there is a big red box!
08:09:35  * systemfaultquit (Quit: Bye!)
08:09:39  <Ralith>the docs are really pretty clear on all matters here
08:09:58  <Ralith>see also http://docs.libuv.org/en/v1.x/handle.html#c.uv_handle_t.data
08:10:22  <Ralith>as cited from http://docs.libuv.org/en/v1.x/async.html#public-members
08:10:54  <Ralith>there is only so much an API can do to save you from yourself if you're going to do parallelism without reading the docs :P
08:11:34  <Ralith>(though it wouldn't hurt to have named the method 'notify' instead of 'send' I suppose)
08:12:14  <Dirkson>Other libuv types that I currently access the data member of allow me to send pointers without dropping data. From my perspective, uv_async_t *is* special. I gather from your conversation that this is because it's a 'handle' type, but this differentiation isn't obvious when using libuv. I'm *not* saying you're wrong about the internal structure of libuv, just explaining why I personally find this part of it
08:12:16  <Dirkson>very confusing.
08:12:58  <Ralith>you are very confused, and it seems I'm not doing as good a job of addressing that as I hoped
08:13:08  <Ralith>everything that has a 'data' member is a handle type
08:13:27  <Ralith>per the documentation linked above, libuv never touches that member, ever
08:13:31  <Ralith>it is purely for your own use
08:13:55  <Ralith>thus, if you are accessing it from multiple threads, standard shared memory rules apply
08:14:29  <Ralith>if you're not familiar with standard shared memory rules, they can be pretty well summed up as "don't do that"
08:15:10  <Ralith>none of this has the slightest bit to do with libuv's internals, as can be seen by the fact that it's all laid out explicitly in the documentation of the public API
08:15:51  <txdv>jeez, dont kill that dude with your official talk
08:16:31  <Ralith>disclaimer: do not take me too seriously because it is 1AM
08:16:54  <Ralith>but still, really, libuv has great docs and you would do yourself a great service by reading them :P
08:17:06  <txdv>you sound like you are trying to prove a point with your over officialy style
08:17:27  <Ralith>well, I am trying to prove a point.
08:17:39  <txdv>and i agree that the data member on the handle should already warn the dev
08:17:41  <Dirkson>With uv_udp_send_t, I can deal with the "data" member directly in callbacks, without appearing to leak memory. But I cannot do the same thing with uv_async_t. *Think* You're probably right that the major differentiation is the multithreaded nature of what uv_async is dealing with... But that still makes uv_async special : ) And anyway, you're still kinda going on the offensive, trying to dispell my confusion
08:17:43  <Dirkson>- It's not really needed. txdv set me on the path of setting up a queue around uv_async, so I'm working on getting that set up. I'm just trying to communicate to you what I found confusing, because knowing what users find confusing about your design can be handy.
08:18:37  <txdv>yeah, but uv_udp_send_t saves the data in the request, uv_async_send doesnt
08:18:56  <txdv>its still confusing, im just telling you were the data is saved
08:19:30  <Dirkson>And I definitely admit that some part of my confusion *this* time was my own damn falt. I'm pretty sure I ran into this problem before, and didn't leave myself good enough notes to avoid it. I've done that now... hopefully :D
08:19:48  <txdv>ok, we are all sorry, the documentation is great, lets move on
08:20:10  <Ralith>>_>
08:20:58  <Ralith>txdv: I'm not sure what you mean by "saves the data in the request"; the 'data' field of any handle is explicitly never read or written by libuv.
08:21:46  <Ralith>it would rather defeat the point of being a user data pointer otherwise
08:22:07  <Ralith>Dirkson: sorry to go off on a bit of a rant on you there
08:22:32  <Dirkson>Ralith: Oh, don't worry about it. It's 1am, like you mentioned ^.^ My own bedtime was 5 hours ago...
08:22:56  <txdv>udp_send, tcp_send has a request field, you have to create a request, the data field of it is never touched, yes
08:23:14  <txdv>but the result is that every callback of send has a unique request associated with it
08:25:00  <Ralith>speaking for myself, I frequently reuse requests :P
08:25:28  <txdv>well, yes, but you do it only after you get the callback of it
08:25:40  <txdv>which is issued by libuv to inform you that this request is ready to be used by someone else
08:25:57  <txdv>now he probably just looked for the same data member, found it in the handle itself and then was confused why its not working
08:26:36  <txdv>w/whois Ralith
08:26:39  <txdv>damn it
08:26:40  <txdv>:D
08:26:44  <Ralith>rude
08:26:45  <Dirkson>Ralith: I actually worked out I could reuse a request the other day! I'm not sure it really saves much time in my situation, but it was kinda pleasant to avoid an unneccesary free/malloc
08:26:48  <Ralith>(not actually)
08:27:47  <txdv>yeah, that is probably the main reason for reusing them
08:27:53  <txdv>so you dont have free/malloc ALL the time
08:28:21  <Ralith>Dirkson: for my purposes it's mostly about reducing bookkeeping effort rather than improving performance
08:28:38  <Dirkson>Fair.
08:29:19  <txdv>2 requests 1 buffer
08:29:34  <Ralith>permature optimization is etc
08:30:32  <Dirkson>You know, I'm tired enough that I keep finding myself wanting to chat at you guys rather than figure out how this queue should work. I think I'll head to bed. Thanks for the help : )
08:31:07  <Ralith>\o
08:31:10  <Ralith>beware shared memory
08:32:07  <txdv>he is so tired that he can't code and is forced to socialize
08:32:10  <txdv>poor soul
08:32:17  <txdv>must be exhausted
08:33:41  <Ralith>haha
09:56:34  * rmgjoined
10:01:27  * rmgquit (Ping timeout: 260 seconds)
11:23:00  * Ruyiquit (Read error: Connection reset by peer)
11:47:02  <bawNg>txdv: I'm going to be really busy over the next few days, so I'll have minimal time to work on this, but I just grabbed the 3.5 branch and tested connecting a client from a 3.5 VS project, which worked fine
11:47:19  <bawNg>I had to add a Tuple to build the 3.5 solution: https://gist.github.com/bawNg/849af37c95e1a6527901c88f8b6b2bc6
11:48:21  <txdv>-,-
11:48:25  <txdv>I forgot to add the tuple
11:48:59  <txdv>ill sit down thsi evening and merge the .net35 into master
11:49:23  <bawNg>Keep in mind since the examples use tasks, they can't work for 3.5
11:49:23  <txdv>i just did not commit the Tuple.cs but yeah
11:49:37  <txdv>what examples?
11:50:05  <bawNg>The ones in the examples directory
11:50:23  <txdv>all of them are suffixed with Async
11:50:38  <txdv>but yeah, I see I lack an example without async for tcp
11:50:46  <bawNg>No worries
11:51:12  <txdv>I think i rewrote it to async and then threw it out
11:51:23  <txdv>I don't remember, but ill probably just write some this evening
11:51:25  <txdv>its not hard
11:52:02  <bawNg>Yeah, not a priority either
11:52:12  <bawNg>I'm sure not many people will be using it with 3.5
11:52:48  <txdv>nobody is using it
11:52:49  <txdv>;D
12:03:40  <bawNg>I just took a look through a little of the API, and I'll need a lot of changes to optimize things, I'll have to go through more later when I can find time
12:06:29  <txdv>bawNg: where do you see the performance issues?
12:06:43  <txdv>or what things you do you want to optimize?
12:06:47  <bawNg>Some initial concerns I came across are: Events are used heavily, they have an crazy amount of overhead under all .Net runtimes, that would need to either be reworked or replaced with a light weight event system (I prototyped one recently which will replace events in Oxide)
12:07:05  <bawNg>Read returns a string instead of taking a array buffer to write to (needed for binary protocol and to avoid creating garbage)
12:09:20  <txdv>the read you are seeing is an overload
12:09:46  <txdv>the events ...
12:09:51  <txdv>What particular event? read event?
12:10:11  <bawNg>It's the only Read method which seems to be exposed by the Tcp client instance
12:10:18  <bawNg>I haven't looked at the source yet
12:10:34  <txdv>I have a branch where I requestify that thing, as in, you call Read(bytearra, callback)
12:10:47  <txdv>and you get your callback called when the read is done
12:11:03  <bawNg>That sounds a lot better, doesn't seem to be exposed or on this branch currently
12:11:30  <bawNg>The read method uses stream.Data += to register a callback
12:11:50  <bawNg>Registering the callback is slow, as is calling it and removing the registration
12:13:17  <bawNg>I recently benchmarked event performance under both .Net and Unity Mono runtimes after noticing the insane amount of overhead with adding and removing Oxide timers, it's best to avoid events for anything which happens often
12:13:35  <txdv>here is the current interface: https://github.com/txdv/LibuvSharp/blob/master/LibuvSharp/IUVStream.cs#L12-L16
12:13:39  <txdv>it is modelled after node.js
12:13:52  <txdv>and this is the other one: https://github.com/txdv/LibuvSharp/blob/newapi/LibuvSharp/IUVStream.cs#L11-L12
12:14:47  <txdv>Yeah, you are generally right, but this has been already taken into consideration, not from the perspective of it being slow
12:14:48  <bawNg>This is .Net event overhead compared to the prototype I wrote: https://gist.github.com/bawNg/9360b46d5f9f5ad9a12e61d66708fc1f
12:16:51  <txdv>like libuvsharp vs your thing>?
12:17:29  <txdv>i dont understand how you add callbacks
12:17:40  <bawNg>The amount of API which requires delegates is also concerning, since every time a delegate is created, that is a heap allocation which needs to be GC'd later
12:18:05  <bawNg>So some of the API may need to be reworked with an alternative which does not require frequent delegate registration
12:18:39  <bawNg>txdv: The "callbacks" in that benchmark comparison is the light weight event system I prototyped
12:19:55  <txdv>Can you show me?
12:23:49  <bawNg>Sure, I haven't pushed it out to the official Oxide repo yet since I have to merge and clean up a whole bunch of other stuff first, https://gist.github.com/bawNg/e5bc4f52b872365ad186cdf5caac1567
12:37:26  <txdv>but you are just saving the callback delegate in the class Callback in the field Invoke
12:38:45  <txdv>i dont understand what this tries to achieve
12:39:04  <txdv>but I dont think it is that hard to rewrite libuvsharp with this class
12:39:28  <txdv>i mean you just change at the appropriate places stuff from Action to Event.Callback
12:39:31  <txdv>And so on
12:39:54  <bawNg>Look at the benchmark comparison, .Net events are a crazy amount slower than that simple prototype
12:40:57  <bawNg>Implementation using that event system is a bit more verbose, but it's worth it to reduce overhead
12:41:58  <bawNg>Those times are in seconds by the way, not milliseconds
12:45:10  <txdv>O, well, against events I get it
12:45:24  <txdv>but it is not more lightweight than a simple callback, right?
12:46:04  <bawNg>Right, if you only ever need to register a single callbacks, that would be way simpler and faster
12:46:20  <bawNg>*single callback
12:57:36  * happy-dudejoined
13:26:45  * PerilousApricotjoined
13:30:38  * kaushik_joined
13:31:49  <kaushik_>Hi. Can I ask questions here directly ?
13:37:07  * frandagostinojoined
13:37:57  * kaushik_part
13:41:28  * fdagostinojoined
13:41:50  * frandagostinoquit (Ping timeout: 248 seconds)
13:47:10  * fdagostinoquit (Ping timeout: 248 seconds)
13:58:14  * rmgjoined
14:02:57  * rmgquit (Ping timeout: 260 seconds)
14:05:59  * alexforsterjoined
14:10:29  * alexforsterquit (Ping timeout: 268 seconds)
14:14:55  * Fishrock123joined
14:34:35  <txdv>YES YOU CAN
14:34:37  <txdv>MY GOD
15:06:50  * Fishrock123quit (Quit: Leaving...)
15:38:57  * seishunjoined
15:59:39  * rmgjoined
16:22:09  * brsonjoined
16:26:17  * dap_joined
16:29:45  * brsonquit (Ping timeout: 244 seconds)
16:30:31  * brsonjoined
16:35:55  * brsonquit (Ping timeout: 244 seconds)
16:36:45  * brsonjoined
16:59:24  * brsonquit (Quit: leaving)
17:17:56  * Fishrock123joined
17:30:50  * brsonjoined
18:02:25  * rcyrjoined
18:14:12  <creationix>anyone know what could cause libuv to never call a callback to simple functions like uv_fs_open?
18:14:27  <creationix>I see this problem from time to time and someone is hitting is consistently on an embedded platform
18:18:19  * rcyrchanged nick to systemfault
18:21:25  * systemfaultpart ("Bye!")
18:23:31  <Dirkson>txdv: Hey, can I ask you if I can ask a question about whether or not I can ask a question?
19:44:27  * saheljoined
19:48:12  * frandagostinojoined
19:54:47  * rendarquit (Ping timeout: 250 seconds)
19:59:46  * bawNgquit (Ping timeout: 250 seconds)
20:00:56  * rendarjoined
20:04:34  * Perilous_joined
20:08:13  * PerilousApricotquit (Ping timeout: 250 seconds)
20:18:53  <frandagostino>Hi there, I m having an issue with fs_open in MIPSEL, does anyone can help me with some libuv source code doubts?
21:23:38  * PerilousApricotjoined
21:26:13  * Perilous_quit (Ping timeout: 250 seconds)
21:42:58  * Guest53161joined
21:43:17  * PerilousApricotquit (Remote host closed the connection)
21:44:50  * PerilousApricotjoined
21:57:18  * seishunquit (Ping timeout: 268 seconds)
22:12:27  * flying6joined
22:19:22  * tunniclm_joined
22:27:39  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
22:36:44  * dap_quit (Quit: Leaving.)
23:02:29  * frandagostinoquit (Quit: Leaving)
23:17:23  * sahelquit (Ping timeout: 244 seconds)
23:51:26  * qardjoined
23:51:42  * tunniclm_quit (Ping timeout: 276 seconds)
23:54:12  * flying6quit (Ping timeout: 250 seconds)