00:02 dogbert11 joined 00:06 dogbert17 left 01:24 kvw_5 joined 01:27 kvw_5_ left 01:39 Kaiepi left, Kaiepi joined 01:52 leont left 01:56 leont joined 02:38 Kaiepi left 02:39 Kaiepi joined 03:51 evalable6 left, unicodable6 left, bloatable6 left, shareable6 left, tellable6 left, linkable6 left, squashable6 left, committable6 left, releasable6 left, statisfiable6 left, notable6 left, sourceable6 left, nativecallable6 left, benchable6 left, quotable6 left, coverable6 left, bisectable6 left, greppable6 left, bisectable6 joined, releasable6 joined, greppable6 joined 03:52 tellable6 joined, committable6 joined, unicodable6 joined, bloatable6 joined, sourceable6 joined, statisfiable6 joined 03:53 linkable6 joined, coverable6 joined 03:54 notable6 joined, nativecallable6 joined, squashable6 joined, evalable6 joined, benchable6 joined, quotable6 joined, shareable6 joined 04:27 CodeCanna joined 04:39 tonyo joined 04:46 CodeCanna left 07:31 japhb left
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 ?
07:53 japhb joined 08:12 linkable6 left 08:14 linkable6 joined
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
08:57 linkable6 left 09:00 linkable6 joined
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
09:56 Kaiepi left, Kaiepi joined
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
10:14 linkable6 left 10:17 linkable6 joined 10:35 linkable6 left, linkable6 joined
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
11:38 linkable6 left, evalable6 left 11:39 evalable6 joined 11:40 linkable6 joined
lizmat notable6: weekly 11:46
notable6 lizmat, No notes for “weekly”
lizmat well, that's easy then
11:49 frost-lab joined
[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
12:01 linkable6 left 12:04 linkable6 joined 12:06 linkable6 left 12:08 linkable6 joined 12:10 linkable6 left 12:13 linkable6 joined 12:16 linkable6 left, linkable6 joined
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
12:35 linkable6 left 12:36 linkable6 joined 12:40 domidumont joined
nine cool :) 12:43
13:02 softmoth left 13:05 frost-lab left 13:42 b2gills left 14:06 b2gills joined
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
16:00 Kaiepi left 17:20 domidumont left 17:51 Xliff joined 17:56 djinni` left 18:09 Kaiepi joined 18:12 djinni` joined 18:21 Xliff left 19:18 linkable6 left 19:19 linkable6 joined 19:21 linkable6 left 19:22 linkable6 joined 19:24 linkable6 left 19:25 linkable6 joined 19:26 linkable6 left 19:27 linkable6 joined 19:28 linkable6 left 19:31 linkable6 joined 19:32 linkable6 left 19:35 linkable6 joined 19:49 linkable6 left, linkable6 joined 19:51 linkable6 left 19:52 linkable6 joined 19:55 linkable6 left 19:57 linkable6 joined 20:09 linkable6 left 20:10 linkable6 joined 20:11 linkable6 left 20:12 linkable6 joined 20:13 linkable6 left 20:14 linkable6 joined 20:22 linkable6 left 20:25 linkable6 joined 20:36 linkable6 left 20:38 linkable6 joined
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
20:47 linkable6 left 20:50 linkable6 joined 20:58 linkable6 left 21:00 linkable6 joined
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
21:03 linkable6 left
Geth roast: vrurg++ created pull request #728:
Add a test for possible overriding of delegated methods		 21:03
21:05 linkable6 joined
japhb lizmat: >.< Yep, that's pretty LTA indeed, sheesh. 21:15
21:16 linkable6 left 21:17 linkable6 joined
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!
22:02 dogbert17 joined 22:05 dogbert11 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!