github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:57 lucasb left 00:58 ZzZombo_ joined 01:01 ZzZombo left, ZzZombo_ is now known as ZzZombo 01:59 ZzZombo_ joined 02:01 ZzZombo left, ZzZombo_ is now known as ZzZombo 05:48 harrow` joined 05:50 avarab joined, avarab left, avarab joined 05:54 camelia left, harrow left, avar left 05:56 camelia joined 06:11 harrow` left 06:14 harrow joined
Geth_ MoarVM: Kaiepi++ created pull request #1192:
[IP6NS Grant] Prepare for upcoming sync UDP/UNIX/raw socket support		 06:44
06:46 ZzZombo_ joined 06:49 ZzZombo left, ZzZombo__ joined, 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, ZzZombo_ is now known as ZzZombo 07:53 zakharyas joined 08:21 brrt joined 08:34 ZzZombo_ joined 08:36 ZzZombo left, ZzZombo_ is now known as ZzZombo 08:46 ZzZombo_ joined 08:50 ZzZombo left, ZzZombo_ is now known as ZzZombo 08:53 brrt left 09:17 eaterof left 09:19 eater joined 09:28 chansen_ left, chansen_ joined 09:31 samcv joined 10:41 brrt joined
brrt \o 10:41
nwc10 o/ 10:42
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, domidumont joined 14:07 brrt` left 14:36 ZzZombo left 14:38 ZzZombo joined 14:55 zakharyas left
japhb \o/ 15:22
15:24 patrickb joined
timotimo o 15:58
patrickb Can someone have a look at github.com/MoarVM/MoarVM/pull/1182 ? Or just merge the PR? It passes all tests... 16:10
16:12 domidumont left 16:24 MasterDuke joined
nine 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:24
patrickb nine: Do you know which ones are missing the feature? VC 2019 is ok with this code... 16:25
nine no, I don't 16:27
16:36 domidumont joined
dogbert17 nine: the method !setup() is called twice in your example 16:36
i.e. github.com/rakudo/rakudo/blob/mast...l.pm6#L271 16:37
japhb patrickb: Browsing around a bit, it looks like support might have started in VC 2013 (see devblogs.microsoft.com/cppblog/c11...n-vs-2013/ where it mentions "C99 variable declarations" would be "implemented in 2013 RTM")
But since that's a forward looking comment, I can't be sure.
Wikipedia (in en.wikipedia.org/wiki/C99) says "Visual C++ 2013 implements a limited subset of C99 required to compile popular open-source projects." 16:38
patrickb japhb: Thanks for the research! I guess I'll rewrite the code to comply for now. 16:40
16:48 domidumont left 16:49 domidumont joined
nine Ok, I think now I understand. 17:34
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
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:40
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
timotimo it could also have a boolification spec :P
nine Yeah, but that sounds more complicated :D 17:46
japhb repr functions are (relatively) cheap, aren't they? +1 pointer per repr, and there aren't a lot of those?
Which is to say, why overload an existing one, when you can just add something new that makes that communication easier? 17:47
timotimo they are. also, the jit can specialize that if we really want
nah, don't add more repr functions just for fun
nine It doesn't sound like fun anyway ;)
japhb I didn't say "just for fun", I meant "add an interface to allow passing that *kind* of info to higher levels"
timotimo you'll have to add a NULL entry to all reprs for that repr op :) 17:48
japhb 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
I think the overload is a code smell, but I'm not the one having to write it, so fair enough. :-) 17:49
nine I'm not gonna make the same change to 46 files
japhb Picky, picky. ;-)
timotimo it's an implementation detail :) :) 17:50
18:03 brrt` joined 18:20 brrt` left
lizmat nine: re "I'm not gonna make the same change to 46 files", what is the change, and what are the files? 18:28
18:38 zakharyas joined
MasterDuke 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? 18:43
19:02 zakharyas left
timotimo 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:03
lizmat 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
timotimo i don't consider it a useful addition
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
nine 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
timotimo pointers are unsigned after all!
nine 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
timotimo :D
i want a machine that has floating point pointers
replace NullPointerException with NaNPointerException 19:08
did you see that machine that uses floating point math for its native bits?
nine That sounds....unhealthy 19:13
timotimo why are things like this so hard to search for 19:16
aha 19:17
tom7.org/nand/ 19:19
nine Now I see....it's actually lovely! 19:27
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:32
19:40 Kaiepi left
patrickb nine: I think I made the PR C89 compatible. Ready to merge? 19:42
19:42 Kaiepi joined
nine 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:51
patrickb "int a = foo(); int b;" is not ok? 19:52
nine it is!
patrickb how does that make sense!?!
timotimo reasons
patrickb :-P 19:53
nine 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
patrickb learned something today
nine I'm quite sure it made some sense in the 70s!
timotimo "i'll take useless knowledge for 300 please"
patrickb Then I can actually put the consts back in again!
nine jnthn++ isn't around is he? Because... 19:55
nine whispers "I like const!"
lizmat having all declarations in place before actually parsing code, makes sense for a compiler with very little memory available 19:56
nwc10 lizmat: aha, that's the thing that I missed 19:57
we are all spoiled these days
lizmat indeed
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
nwc10 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)
lizmat until I realized that the stack had run into the program
nine lizmat: ah, the times :) 19:59
patrickb nine: IIUC the code was conforming to the declaration first rule originally.
nine: Do I miss something here? 20:00
Uhm, given that the rule is "declaration at the beginning of the *block*" (and not function)
Which google tells me is the case.
nine 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
patrickb nine: I restored the previous version (+ minor reformatting). Looks good to me. 20:06
MasterDuke timotimo: would something like github.com/iovisor/bcc/tree/master...cpp/pyperf be possible/useful for moarvm? 20:08
timotimo ooh 20:10
probably not terribly easy for jitted frames? maybe?
MasterDuke fwiw, i found that via news.ycombinator.com/item?id=21218707. lots of stuff going on with bpf nowadays 20:12
timotimo bpf was a very light inspiration for confprog
nine patrickb: oooh...now I see. Previously I was only looking at the first commit: github.com/MoarVM/MoarVM/pull/1182...b5aecbR128 20:13
patrickb Ah well. That dance made me learn something about C. :-D 20:14
MasterDuke 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
Geth_ MoarVM/master: 6 commits pushed by (Patrick Böker)++, niner++
timotimo of course
20:17 Kaiepi left
patrickb 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:17
nine Hope it's worth it :) 20:18
timotimo 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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!