|
00:10
nwc10 joined
01:00
lizmat joined
01:22
bloatable6 joined
02:01
lizmat joined
02:57
ilbot3 joined
03:03
lizmat joined
04:06
lizmat joined
04:34
lizmat joined
06:26
lizmat joined
06:44
zakharyas joined
07:41
lizmat joined
07:45
zakharyas joined
08:18
lizmat joined
08:38
domidumont joined
08:43
domidumont joined
09:33
zakharyas joined
09:45
lizmat joined
09:50
nativecallable6 joined
10:46
geospeck joined
11:13
robertle joined
12:32
brrt joined
13:21
domidumont joined
14:02
brrt joined
14:20
markmont joined,
lizmat joined
14:41
leedo joined,
lizmat joined
14:49
markmont joined
14:57
brrt joined
14:59
geospeck joined
15:04
brrt1 joined
15:12
dogbert17 joined
15:44
lizmat joined
16:13
domidumont joined
16:20
krunen joined
16:22
yoleaux joined,
tangible6 joined
|
|||
| Geth | MoarVM: e87a74130b | (Stefan Seifert)++ | src/core/nativecall.c Remove some duplicated code This is already done in lines 461 and 463 (before processing argument processing nodes). |
16:42 | |
|
16:50
releasable6 joined,
unicodable6 joined,
statisfiable6 joined
|
|||
| dogbert17 | nine: are you a nativecall expert? | 17:11 | |
| japhb | dogbert17: He constantly claims that he is not, yet he's responsible for both Inline::Perl5 and Inline::Python. :-) | 17:38 | |
| Plus of course nativecall JIT optimizations | 17:39 | ||
| dogbert17 | japhb: I'm wondering about this line, github.com/MoarVM/MoarVM/blob/mast...call.c#L19 | 17:41 | |
| it must be incorrect as a check for 'stdcall' is made on line 13 | |||
| or, it's correct and line 13 is fishy | 17:43 | ||
| japhb | Yep, one of those is wrong, I agree. | 18:02 | |
| "vectorcall" for the x64 one, maybe? (Not a windows programmer, just noticed it in the wikipedia article for stdcall) | 18:04 | ||
| nine | dogbert17: well that's certainly unreachable code | 18:40 | |
|
18:42
markmont joined
|
|||
| nine | Wikipedia tells me that on x86-64 there's only one calling convention in Windows (and UEFI) and one for everything else | 18:55 | |
| dogbert17 | nine: do you think the test, on line 19, should be removed? | 18:56 | |
| timotimo | what happened to all the other calling conventions windows has? | 19:04 | |
| nine | Looks to me like this should be more correct: gist.github.com/niner/9cf08c0f83a0...13ab383ef0 | 19:07 | |
| Except for the missing #endif of course | 19:08 | ||
| I do have the suspicion however that dyncall ignores the dcMode on x86_64 anyway. It's documentation already says that it will ignore invalid platform/mode combinations. | |||
| Also #ifdef __x86_64__ is probably not the proper cross-platform way to check for that architecture | 19:10 | ||
| dogbert17 | is there a proper cross-palform way? | 19:22 | |
| *platform | |||
| nine | Updated the gist with a probably more correct version | 19:25 | |
| Compiles and runs just fine on x86_64 Linux. | |||
| But then, so did the previous code :) | |||
| dogbert17 | sounds promising :) | 19:26 | |
| nine | dogbert17: do you actually see a problem with this code or did you just come across it and noticed the oddity? | 19:27 | |
|
20:33
lizmat joined
|
|||
| samcv | i think i may attempt to add proper integer property values to ucd2c.pl because right now it doesn't store it as an enum it just stores it using the full number of bits | 21:02 | |
|
21:32
harrow joined
21:38
harrow joined
21:57
AlexDaniel joined
|
|||
| dogbert17 | nine: sorry for the late reply, was out eating. I saw no problem but cppcheck did :) On the other hand, there might possibly be a problem but obviously not on Linux, which is what I have. | 22:08 | |
|
22:50
Ven joined
|
|||