nine bartolin_: oh, yes, right. 07:52
tellable6 2021-04-04T09:46:09Z #moarvm <dogbert17> nine do you happen to know which commit fixed github.com/MoarVM/MoarVM/issues/1029 ?
Geth nqp: 92d71ba8ca | (Christian Bartolomäus)++ | src/vm/jvm/runtime/org/raku/nqp/runtime/Ops.java
[JVM] Allow nqp::backtrace with nqp:null argument

This follows github.com/MoarVM/MoarVM/commit/3623701173 and should allow to unify the code for Backtrace.new between MoarVM and JVM backend.
08:44
Geth rakudo: usev6++ created pull request #4302:
Support backtrace creation from nqp::null on JVM
09:03
bartolin_ I'll wait for the spectest to finish before merging. 09:04
bbl &
nine In the meantime I'll find out the differences between nativecall, nativecallinvoke and nativeinvoke 09:05
bartolin_ oh, ++nine 09:26
nine: github.com/usev6/rakudo/commit/ad2...2d09bcd07a has the workarounds that I was mumbling about in github.com/rakudo/rakudo/pull/4277...-812060052 09:30
together with github.com/Raku/nqp/pull/708 this makes more than half of the test files from 04-nativecall pass. A lot of the remaining problems seem to be caused by the NullPointerException I mentioned -- which could very well be a totally different problem 09:32
nine Ah, yes. github.com/MoarVM/MoarVM/commit/1b...e8e155c080 would need porting to JVM. That's the unbox_i($!call). 09:35
Where does the NPE happen with the get_int implemented?
bartolin_ Unfortunately I wasn't able to find the exact place :( But I've stumbled upon this old issue that might be related: github.com/Raku/old-issue-tracker/issues/3713 09:37
.oO( 2015-06-30 -- time is flying by )
09:39
github.com/Raku/old-issue-tracker/...-570866667
nine I think the full implementation would be just: 09:40
@Override
public long get_int(ThreadContext tc) {
return body.entry_point == null ? 0 : 1;
}
Geth nqp: cb55e25345 | (Christian Bartolomäus)++ | src/vm/jvm/QAST/Compiler.nqp
[JVM] Add op 'nativecallinvoke'

For now, it's identical to 'nativecall'. The op was introduced for MoarVM with github.com/Raku/nqp/commit/28e0650f1c and it is used in Rakudo's lib/NativeCall.rakumod.
nine I guess there's no way to get a Java backtrace for those NPEs? 09:42
bartolin_ I didn't find it yet -- but probably that's because I'm not familiar with the available tools. I'll try to look into that. 09:45
But first I'll try to stick your suggestion for porting github.com/MoarVM/MoarVM/commit/1b...e8e155c080 into .../sixmodel/reprs/NativeCallInstance.java 09:46
Geth rakudo: 9c3f68b06a | (Christian Bartolomäus)++ | tools/templates/NQP_REVISION
Bump NQP for nqp::backtrace(nqp::null) on JVM
09:50
rakudo: 0b91b21afa | (Christian Bartolomäus)++ | 3 files
[JVM] Support backtrace creation from nqp::null

This makes the JVM backend behave like MoarVM when creating a new backtrace without an existing exception. For more details see
  github.com/rakudo/rakudo/commit/2e79780e4a.
Please note that the change for src/core.c/Deprecations.pm6 fixed an oversight in the above commit. (Now only relevant for the JS backend, but this lead to spectest failures in S02-types/isDEPRECATED.t on the JVM backend before.)
nine bartolin_: the irony about the whole backtrace affair is that the JVM has been right all along, yet the test has been fudged for the JVM and the MoarVM bug made into spec. 09:52
bartolin_ nine: yeah, I've read that (either in one of your commit messages or while backlogging IRC). I'm pretty sure that I've fudged the tests for the JVM once they started to fail :/ 09:55
bartolin_ it happens from time to time that tests start to fail on the JVM backend. Usually I try to find out what causes the breakage, but often I don't have enough time to investigate closely. In that cases I tend to fudge the tests, so that new spectest failures are easy to see -- and for "looking at the problem later". 10:01
Probably that is not good enough. Maybe I should try to take the time and create issues for such regressions on the JVM backend -- because regressions there could point to a bug that doesn't surface on MoarVM (or to backend-specific code). 10:11
Geth nqp: usev6++ created pull request #710:
[JVM] Make nqp::unbox_i on NativeCall object work
10:42
nine MasterDuke: did you re-compile rakudo after the MoarVM change? If not rakudo's compiled C code will still work with the old layout of MVMInstance. 10:58
MasterDuke: seems to work just fine after a full re-compile 11:00
MasterDuke nine: oh ha. didn't even think of that. was a little confused that such a simple changed died so explosively 11:12
nine It cought me a few times with changes to MVMThreadContext 11:15
lizmat notable6: weekly 11:46
notable6 lizmat, No notes for “weekly”
lizmat well, that's easy then
[Tux] Rakudo v2021.03-116-g0b91b21af (v6.d) on MoarVM 2021.03-27-g42959e464
csv-ip5xs0.804 - 0.812
csv-ip5xs-207.957 - 8.445
csv-parser25.986 - 26.901
csv-test-xs-200.378 - 0.383
test7.429 - 7.912
test-t1.895 - 1.944
test-t --race0.926 - 0.960
test-t-2030.041 - 31.363
test-t-20 --race9.708 - 9.717
11:49
bartolin_ nine: I made some progress with the NullPointerException. It seems to stem from github.com/Raku/nqp/blob/cb55e2534...java#L2636 because tc.native_j is null. Interestingly there is a check for this in the very simliar code at github.com/Raku/nqp/blob/cb55e2534...ava#L2575. That check was introduced with github.com/Raku/nqp/commit/720d05222b .. 12:18
nine bartolin_: don't we have a VMNull object on the JVM as well? 12:27
Oh, but tc.native_j is not a place for storing SixModelObjects but explicitly for any Java object. So maybe a null is indeed ok there 12:30
bartolin_ yeah, I think null seems to be okay there. (otherwise there would be a VMNull available). Anyway it feels like I make more progress 12:33
nine cool :) 12:43
lizmat And another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/04/05/2021-...ting-rats/ 14:43
vrurg lizmat++ these are alway great news! :) 14:59
Geth rakudo: c9aceda43d | (Elizabeth Mattijsen)++ | src/core.c/unicodey.pm6
Make .uniprop a proper multio method

  - make the sub version just pass on, like it should
  - make the .uniprop General_Category lookup a constant
  - move logic to Rakudo::Unicodey, only place for backend specific code
  - makes the sub version 25% slower (as it now passes on to the method)
  - makes the method version about 30x as fast
20:41
lizmat m: BEGIN my int $a = 4 # that seems, LTA ? 21:01
camelia 5===SORRY!5=== Error while compiling <tmp>
An exception occurred while evaluating a BEGIN
at <tmp>:1
Exception details:
5===SORRY!5=== Error while compiling
Lexical with name '$a' has wrong type. real type 8 wanted type -1
a…
Geth rakudo: vrurg++ created pull request #4303:
Don't add a delegated method if target already has it
Geth roast: vrurg++ created pull request #728:
Add a test for possible overriding of delegated methods
21:03
japhb lizmat: >.< Yep, that's pretty LTA indeed, sheesh. 21:15
vrurg lizmat: I hate that error, saw it too many times. But there was always something with higher priority to fix it. 21:37
lizmat is there an issue already ? 21:39
it's the first time (that I remember) that I run into this 21:40
m: my constant int $a = 42
camelia 5===SORRY!5=== Error while compiling <tmp>
Missing initializer on constant declaration
at <tmp>:1
------> 3my constant int7⏏5 $a = 42
lizmat mehg
Geth rakudo: vrurg++ created pull request #4304:
Make CLIENT:: work for code invoked from NQP world
21:42
vrurg lizmat: quick lookup into issues doesn't reveal any related ticket. 21:45
lizmat ok, too tired now to do anything anymore, so I'm going to be calling it a day 21:47
"a day"
&
vrurg lizmat: o/ g'night!