00:23 vrurg_ joined, vrurg left 01:09 MasterDuke joined
timo m: my @*ARGS = ":"; sub MAIN(*@, *%) { }; 02:41
camelia MVMArray: Can't shift from an empty array
in block <unit> at <tmp> line 1
timo my $split := nqp::split("=",$optstring); 02:42
$optstring = nqp::shift($split);
explodes here
m: my @*ARGS = "-"; sub MAIN(*@, *%) { }; 02:43
camelia ( no output )
timo m: my @*ARGS = "/"; sub MAIN(*@, *%) { };
camelia ( no output ) 02:44
timo ah, right. neither of these hit that code path, because just - is explicitly filtered out, and the / has to go after a - or :, not in the same position 02:48
m: use nqp; say nqp::split("=", "")
camelia ()
timo m: use nqp; say nqp::split("=", "a") 02:49
camelia (a)
timo m: use nqp; dd nqp::split("=", "a"); dd nqp::split("=", "")
camelia ("a",)
()
timo literally an empty array that we're trying to shift from
m: say "".split("=").raku; say "a".split("=").raku 02:50
camelia ("",).Seq
("a",).Seq
timo different behaviour in the raku split from the nqp split
03:54 MasterDuke left
bartolin because we spoke about null checks yesterday. It looks like MoarVM has its own problems in that area. The first evaluation I ran this morning resulted in a segmentation fault. 'use nqp; say nqp::atkey({}, "foo")' 06:46
I'm sceptical that it is a good approach to try to make the JVM backend behave the same regarding to null handling. It feels cleaner to check before and just not doing the action on null objects. 06:52
one example that's still fresh in my mind would be github.com/rakudo/rakudo/pull/5379...2493004275 06:53
luckily there is no segmentation fault, but it's still nqp::atkey on a null object. (Unless I miss something.)
sorry for the rambling. maybe I should open an issue in the problem solving repo? 07:00
btw, my example with the segmentation fault wasn't a good one. 'use nqp; nqp::existskey({}, "foo")' also results in a segfault on MoarVM. And it gives a NullPointerException on the JVMbackend. 07:05
I've created github.com/rakudo/rakudo/issues/5697 for the problem with nqp::existskey. 07:44
09:32 sena_kun joined 10:13 sena_kun left
timo ok, that comes from the object at the associative delegation slot being null 13:06
how should we behave here, i wonder. maybe get_object_at_offset that pulls stuff out of a P6opaque's body should give VMNull instead of real null when there's a null at that offset 13:08
nine Wouldn't the correct thing be to auto-vivify if absent? 13:50
lizmat m: use nqp; say nqp::existskey(%(), "foo") 13:53
camelia 0
lizmat looks like Hash.new is taken a shortcut
multi method new(Map: --> Map:D) { 13:55
nqp::create(self)
}
yup
timo do we use getattr + atkey/bindkey/existskey everywhere we have a Map? 14:00
or do we directly point the atkey/bindkey/existskey at the Map object?
lizmat the former afaik
Geth rakudo/main: ba3b24cff2 | (Elizabeth Mattijsen)++ | src/core.c/Map.rakumod
Make sure Map.new has an NQP hash always

Fixes #5697		 14:05
timo that doesn't feel like the right fix
lizmat why? how many times do you call Hash.new without arguments? 14:07
without making further changes to that hash later on ?
afk for a few hours&
timo i imagine there's a few situations where you have a datastructure where "named" stuff is optional, but it has a Hash in it anyway because of a "has %.foo"? or does that also delay initialisation with autoviv? 14:15
if there's no way to get rakudo to try to atkey/bindkey/existskey on the hash object directly, then trying to make nqp::blahkey work correctly is not crucial, because if you "use nqp", you get what you get (but not segfaults. ideally, never segfaults) 14:16
nine Because the underlying bug is still not fixed: 14:30
m: use nqp; my \A := Metamodel::ClassHOW.new_type(:name<A>); A.^add_attribute(Attribute.new(:name<$!a>, :type(Mu), :package(A), :auto_viv_primitive(nqp::hash), :associative_delegate)); A.^compose; nqp::existskey(A.new, "a")'
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> ; A.^compose; nqp::existskey(A.new, "a")<HERE>'
expecting any of:
infix
infix stopper
statement end
statement modifier…
nine m: use nqp; my \A := Metamodel::ClassHOW.new_type(:name<A>); A.^add_attribute(Attribute.new(:name<$!a>, :type(Mu), :package(A), :auto_viv_primitive(nqp::hash), :associative_delegate)); A.^compose; nqp::existskey(A.new, "a")
camelia (signal SEGV)
timo m: use nqp; my \A := Metamodel::ClassHOW.new_type(:name<A>); A.^add_attribute(Attribute.new(:name<$!a>, :type(Mu), :package(A), :associative_delegate)); A.^compose; nqp::existskey(A.new, "a") 14:55
camelia (signal SEGV)
timo ^- unless we also error during composition when there's no auto viv on the associative delegate slot, just doing autoviv when accessing things through the associative delegate won't help unless we also grab VMNull instead of real-null with get_obj_at_offset 14:56
same kind of error presumably happens for pos delegate and atpos/existspos/bindpos 15:11
does existspos exist?
ugexe I use Hash.new without arguments and without potentially changing the hash later on 15:13
since {} is often ambiguous
that being said i'm not sure i use it anywhere that i need it to be highly optimized 15:17
timo i would suggest counting the number of objects created during a spec test run with some tracing tool and comparing a run or three with and without that change 15:41
nine I think that's missing the point. MoarVM must not segfault because of simply running some HLL code. We put much effort into preventing segfaults even when users do really wrong things like sharing totally unprotected hashes between threads. This case here is way more straight forward than that. 16:11
16:55 donaldh_ is now known as donaldh 18:36 sena_kun joined
[Coke] jdv: let's plan something mid December to go through a fake release so I'm up to speed? 18:46
(and have all the privs I might need, etc.)
19:02 sena_kun left
ab5tract #TeamNoSegfault 21:06
[Coke] (I can go through the motions on the release myself and just yell if I get stuck on something) 21:09
patrickb I currently try to get the long paths PR working on Windows. Looking good so far. Unrelated to those changes, I did notice though that the nativecall tests randomly fail when run with via the rest harness. It' always entire files that fail. About a third of t/04-nativecall fails, different files every time. 21:34
I can't get it to fail when I run a file manually.
Did anyone observe the same effect in the past? Is this a known issue?
ugexe from what i can recall the issue was with masterdukes complimenting PR that uses libuv for some other file operations. specifically something with mkdir was off i think 21:37
[Coke] patrickb: that sounds right on nativecall.
thought I hd a ticket on that but cannot find it. 21:40
patrickb ugexe: So it might actually be related to the path changes! 21:45
patrickb tries with a vanilla rakudo 21:46
ugexe gist.github.com/ugexe/0b48f8ebd7d0...03729071ab 22:23
that generates a raku program with 10k deep for loops
it seems to never finish running
(the generated program) 22:24
with 1000 instead of 10,000 the generated program finished almost instantly
patrickb Nope, it's unrelated to the long path PR. 22:28
It sucks that the problem only surfaces when running through TAP::Harness... 22:29
ugexe is it running tests in parallel? 22:30
patrickb I don't think so.
ow, actually it does 22:31
succeeds with --jobs=1 22:32
Found and fixed. Only happens when having compiled moar with debugging enabled. 23:08
ugexe: Do you remember which test was failing? I can't repro right away locally. 23:15
ugexe no, and it might have only been for mingw 23:16
patrickb Ok. I'll skim through the issues again. 23:17
ISTR MinGW was a build error, and the test failure was some mkdir test issue. 23:18
[Coke] patrickb++ 23:44

Powered by Cro and the Raku® Programming Language.

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

Thank you!