[00:57] *** lucasb left [00:58] *** ZzZombo_ joined [01:01] *** ZzZombo left [01:01] *** ZzZombo_ is now known as ZzZombo [01:59] *** ZzZombo_ joined [02:01] *** ZzZombo left [02:01] *** ZzZombo_ is now known as ZzZombo [05:48] *** harrow` joined [05:50] *** avarab joined [05:50] *** avarab left [05:50] *** avarab joined [05:54] *** camelia left [05:54] *** harrow left [05:54] *** avar left [05:56] *** camelia joined [06:11] *** harrow` left [06:14] *** harrow joined [06:44] ¦ MoarVM: Kaiepi++ created pull request #1192: [IP6NS Grant] Prepare for upcoming sync UDP/UNIX/raw socket support [06:44] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1192 [06:46] *** ZzZombo_ joined [06:49] *** ZzZombo left [06:49] *** ZzZombo__ joined [06:49] *** ZzZombo__ is now known as ZzZombo [06:50] *** ZzZombo_ left [06:52] *** domidumont joined [07:18] *** ZzZombo_ joined [07:20] *** ZzZombo left [07:21] *** ZzZombo_ is now known as ZzZombo [07:37] *** sena_kun joined [07:50] *** ZzZombo_ joined [07:52] *** ZzZombo left [07:52] *** ZzZombo_ is now known as ZzZombo [07:53] *** zakharyas joined [08:21] *** brrt joined [08:34] *** ZzZombo_ joined [08:36] *** ZzZombo left [08:36] *** ZzZombo_ is now known as ZzZombo [08:46] *** ZzZombo_ joined [08:50] *** ZzZombo left [08:50] *** ZzZombo_ is now known as ZzZombo [08:53] *** brrt left [09:17] *** eaterof left [09:19] *** eater joined [09:28] *** chansen_ left [09:28] *** chansen_ joined [09:31] *** samcv joined [10:41] *** brrt joined [10:41] \o [10:42] o/ [10:50] *** patrickb joined [11:13] *** brrt` joined [11:14] *** brrt left [11:18] *** brrt` left [11:25] *** zakharyas left [12:46] *** lucasb joined [13:07] *** brrt` joined [13:20] *** patrickb left [13:24] *** zakharyas joined [13:34] *** domidumont left [13:34] *** domidumont joined [14:07] *** brrt` left [14:36] *** ZzZombo left [14:38] *** ZzZombo joined [14:55] *** zakharyas left [15:22] \o/ [15:24] *** patrickb joined [15:58] o [16:10] Can someone have a look at https://github.com/MoarVM/MoarVM/pull/1182 ? Or just merge the PR? It passes all tests... [16:12] *** domidumont left [16:24] *** MasterDuke joined [16:24] patrickb: the code in MVM_platform_open mixes statements and declarations. That's kinda ironic, since stupid Windows compilers is all that's keeping us from upgrading to C99 to get rid of that stupid restriction [16:25] nine: Do you know which ones are missing the feature? VC 2019 is ok with this code... [16:27] no, I don't [16:36] *** domidumont joined [16:36] nine: the method !setup() is called twice in your example [16:37] i.e. https://github.com/rakudo/rakudo/blob/master/lib/NativeCall.pm6#L271 [16:37] patrickb: Browsing around a bit, it looks like support might have started in VC 2013 (see https://devblogs.microsoft.com/cppblog/c1114-stl-features-fixes-and-breaking-changes-in-vs-2013/ where it mentions "C99 variable declarations" would be "implemented in 2013 RTM") [16:37] But since that's a forward looking comment, I can't be sure. [16:38] Wikipedia (in https://en.wikipedia.org/wiki/C99) says "Visual C++ 2013 implements a limited subset of C99 required to compile popular open-source projects." [16:40] japhb: Thanks for the research! I guess I'll rewrite the code to comply for now. [16:48] *** domidumont left [16:49] *** domidumont joined [17:34] Ok, I think now I understand. [17:36] Repossession calls gc_free on the NativeCallBody because: /* Clear it up, since we'll re-allocate all the bits inside it on deserialization. */ [17:36] This causes the discrepancy between the high level $!setup flag and the actual jitcode pointer in the NC body [17:40] Makes me wonder if we couldn't have MoarVM keep track of that state for us. All that's needed is some way to communicate it back up to Perl 6 code. [17:44] Since NativeCall is a repr, I could probably abuse a repr function like get_int for that. Getting an int from a NativeCall will give you it's initialization status. Makes sense, doesn't it? [17:44] it could also have a boolification spec :P [17:46] Yeah, but that sounds more complicated :D [17:46] repr functions are (relatively) cheap, aren't they? +1 pointer per repr, and there aren't a lot of those? [17:47] Which is to say, why overload an existing one, when you can just add something new that makes that communication easier? [17:47] they are. also, the jit can specialize that if we really want [17:47] nah, don't add more repr functions just for fun [17:47] It doesn't sound like fun anyway ;) [17:47] I didn't say "just for fun", I meant "add an interface to allow passing that *kind* of info to higher levels" [17:48] you'll have to add a NULL entry to all reprs for that repr op :) [17:48] Rather than "overload get_int to get this one function", add a function that can return a low-level detail given some enum to look up [17:49] I think the overload is a code smell, but I'm not the one having to write it, so fair enough. :-) [17:49] I'm not gonna make the same change to 46 files [17:49] Picky, picky. ;-) [17:50] it's an implementation detail :) :) [18:03] *** brrt` joined [18:20] *** brrt` left [18:28] nine: re "I'm not gonna make the same change to 46 files", what is the change, and what are the files? [18:38] *** zakharyas joined [18:43] is there a way to use a cast an `MVMGrapheme32 *` so i can use it in MVM_exception_throw_adhoc_free that won't annoy valgrind? [19:02] *** zakharyas left [19:03] lizmat: adding a new entry to one of the REPROps structs so that there's space for a "is this nativecall object initialized?" function [19:05] so this is really useful? And not being done because it is too much work? I'll do it, if you can explain to me what needs to be done [19:05] i don't consider it a useful addition [19:06] re-using get_int aka unbox_i for this purpose is totally fine, since you wouldn't have any other need to unbox a nativecall object to an int, unless you want to, like, get the address of the function or whatever [19:06] but for that you can use get_uint :P [19:06] lizmat: no, it's just not worth it. I'll just use get_int. Asking a NativeCall site for its integer value and getting the initialization status does make some sense [19:06] pointers are unsigned after all! [19:07] timotimo: so...in a sense, it's actually good to block get_int, lest someone misses its signedness when implementing the "get me the pointer" thing ;) [19:07] :D [19:07] i want a machine that has floating point pointers [19:08] replace NullPointerException with NaNPointerException [19:08] did you see that machine that uses floating point math for its native bits? [19:13] That sounds....unhealthy [19:16] why are things like this so hard to search for [19:17] aha [19:19] http://tom7.org/nand/ [19:27] Now I see....it's actually lovely! [19:32] Getting rid of $!setup is only half the deal as the function body will already be replaced with a version that doesn't even check that flag anymore [19:40] *** Kaiepi left [19:42] nine: I think I made the PR C89 compatible. Ready to merge? [19:42] *** Kaiepi joined [19:51] patrickb: that was....a bit farer than needed actually. "int a = 1; int b = 2;" is totally fine in C89. What's not is "int a = 1; foo(); int b;" [19:52] "int a = foo(); int b;" is not ok? [19:52] it is! [19:52] how does that make sense!?! [19:52] reasons [19:53] :-P [19:53] You can do anything as long as it's part of a declaration. But once you do the first non-declaration statement, no more declarations are allowed [19:53] * patrickb learned something today [19:53] I'm quite sure it made some sense in the 70s! [19:53] "i'll take useless knowledge for 300 please" [19:53] Then I can actually put the consts back in again! [19:55] jnthn++ isn't around is he? Because... [19:55] * nine whispers "I like const!" [19:56] having all declarations in place before actually parsing code, makes sense for a compiler with very little memory available [19:57] lizmat: aha, that's the thing that I missed [19:57] we are all spoiled these days [19:57] indeed [19:58] I once tried to augment a terminal program for which there was 1.5KB 8-bit memory available [19:58] and it would crash, and I couldn't understand why [19:58] I sadly forget the details, but I remember Leo talking about having to manage overlays manually, and how the compiler would literally wear out (because it was a paper tape, and you used the same tape for each run) [19:58] until I realized that the stack had run into the program [19:59] lizmat: ah, the times :) [19:59] nine: IIUC the code was conforming to the declaration first rule originally. [20:00] nine: Do I miss something here? [20:00] Uhm, given that the rule is "declaration at the beginning of the *block*" (and not function) [20:00] Which google tells me is the case. [20:01] The MultiByteToWideChar calls were in between declarations [20:01] MultiByteToWideChar(CP_UTF8, 0, path, -1, (LPWSTR)wpath, len); [20:04] *** domidumont left [20:05] *** domidumont joined [20:06] nine: I restored the previous version (+ minor reformatting). Looks good to me. [20:08] timotimo: would something like https://github.com/iovisor/bcc/tree/master/examples/cpp/pyperf be possible/useful for moarvm? [20:10] ooh [20:10] probably not terribly easy for jitted frames? maybe? [20:12] fwiw, i found that via https://news.ycombinator.com/item?id=21218707. lots of stuff going on with bpf nowadays [20:12] bpf was a very light inspiration for confprog [20:13] patrickb: oooh...now I see. Previously I was only looking at the first commit: https://github.com/MoarVM/MoarVM/pull/1182/commits/e127b849fd96a201b486736e5e852a7546816940#diff-8c981fc66de59933691e4a7a48b5aecbR128 [20:14] Ah well. That dance made me learn something about C. :-D [20:15] timotimo: interesting. i still think tcpdump and wireshark first when i hear bpf, still haven't quite wrapped my head around all that it does now [20:15] ¦ MoarVM/master: 6 commits pushed by (Patrick Böker)++, niner++ [20:15] ¦ MoarVM/master: e127b849fd | Improve Unicode handling with paths [20:15] ¦ MoarVM/master: efeec455e0 | Dynamic library loading works with unicody paths on Windows [20:15] ¦ MoarVM/master: 70bcaf90b6 | Make unicode path fixes compile on non-Windows [20:15] ¦ MoarVM/master: 87d7f58d40 | Deduplicate and shorten open and fopen wrappers [20:15] ¦ MoarVM/master: 1f8dbb5283 | Minor style cleanup [20:15] ¦ MoarVM/master: 7aabd24612 | Merge pull request #1182 from patzim/unicody-paths [20:15] of course [20:15] ¦ MoarVM/master: review: https://github.com/MoarVM/MoarVM/compare/39f5774386bb...7aabd24612e7 [20:17] *** Kaiepi left [20:17] With the above change I can now run perl6 located on the desktop of my Windows machine with me being named "Patrick Böker". :-D [20:18] Hope it's worth it :) [20:19] if yu want to live like that ... :P [20:19] (very good work) [20:20] *** domidumont left [20:37] *** Kaiepi joined [20:38] *** sena_kun left [22:43] *** patrickb left