00:35 jnthn joined 02:22 DrForr joined 02:39 skids joined
bartolin morning, #p6dev 05:02
could someone bump the nqp version, so we get the shiny new loadbytecodebuffer op on JVM, too?
nine++ for the continued procomp work 05:03
*precomp even 05:05
05:19 TimToady joined 06:00 sno joined
dalek kudo/nom: a5540ee | niner++ | tools/build/NQP_REVISION:
Bump NQP revision for loadbytecodebuffer on JVM
 06:57
07:58 RabidGravy joined
dalek kudo/js: 130a92b | (Pawel Murias)++ | src/vm/js/ (3 files):
[js] Implement a bunch of p6* ops.
 08:00
08:07 travis-ci joined
travis-ci Rakudo build failed. Stefan Seifert 'Bump NQP revision for loadbytecodebuffer on JVM' 08:07
travis-ci.org/rakudo/rakudo/builds/129922374 github.com/rakudo/rakudo/compare/1...540ee5f08a
08:07 travis-ci left 08:35 pmurias joined
dalek p: a4d08e6 | (Pawel Murias)++ | src/vm/js/nqp-runtime/core.js:
[js] Cloning and a reprname for captures.
 08:35
p: 39989e9 | (Pawel Murias)++ | t/nqp/76-capture.t:
Test that captures can be cloned.
p: 4b6a274 | (Pawel Murias)++ | src/vm/js/nqp-runtime/runtime.js:
[js] Implement $context<$variable> := $value.
09:52 dalek joined
lizmat good *, #p6dev 09:57
after building and pulling, I ran my own CSV test again, and it went up from 1.5 to 2.1 seconds 09:58
I wonder what [Tux]'s benchmark will show
|Tux| builds ā€¦ 10:03
lizmat ok, this is weird: I ran the same test with --profile 10:04
the profile info states the program ran for 815ms
whereas the time output states it ran for 2700 msecs 10:06
|Tux| failed to load library 'dynext/libperl6_ops_moar.so' 10:07
at gen/moar/m-BOOTSTRAP.nqp:1066 (<ephemeral file>:)
I'll start from scratch
lizmat yeah, needs a configure 10:08
looking at the RAKUDO_MODULE_DEBUG output, that accounts for 698msec
of which 411 are for: 411 41027 RMD: dependency: 2D67050B4AAC60FFA064BA058F0D62CF8A36F158 site#sources/2D67050B4AAC60FFA064BA058F0D62CF8A36F158 Slang::Tuxic
and this appears to be repeatable 10:09
moritz
.oO( maybe rename it Slang::Toxic::ForPerformance? )
 10:11
|Tux| gist.github.com/Tux/c0430e073e4cf4...d647bcb77f :( 10:14
jnthn lizmat: That's pretty normal (--profile showing less) because it excludes compilation time and also the time to take the profile data and turn it into JSON and stick it into the HTML template. 10:15
lizmat jnthn: but a *normal* run (without profile) takes 2100 msecs 10:19
10:19 ZoffixWin left
lizmat jnthn: so there's 1300 msecs "missing" 10:19
jnthn: define MVM_NURSERY_SIZE 4194304 # is this the correct "production" nuresery size ? 10:21
jnthn m: say 4194304.base(16)
camelia rakudo-moar a5540e: OUTPUTĀ«400000ā¤Ā»
jnthn Yes
lizmat ok, just checking :-)
jnthn 4MB
On "missing": try --stagestats to see how long compilation takes 10:22
Note that module loading happens at compile time
lizmat Stage parse : 1.405
jnthn There's your missing time :)
lizmat yeah, but that's like it was in complete time before 10:23
jnthn --profile is only runtime of the program after its compiled
OK, so compilation got slower rather than runtime.
lizmat so something messed up parsing
|Tux| I cannot build, as my gist shows. is my local situation to blame?
jnthn Well, parse is really parsing + actions + world (including module loading) 10:24
lizmat [Tux] could be, I had no problem building, perhaps a side-effect of blead
dalek p: 7a7d0ab | jnthn++ | tools/build/MOAR_REVISION:
Bump MOAR_REVISION for callframe changes.
 10:25
jnthn [Tux]: Did you build MoarVM HEAD against Rakudo HEAD? :)
|Tux| yes
dalek kudo/nom: 8b6a4f1 | jnthn++ | src/vm/moar/ops/perl6_ops.c:
Sync with MoarVM API changes.
kudo/nom: 925336a | jnthn++ | src/vm/moar/ops/perl6_ops.c:
Add an MVMROOT on ctx, now frames are GCable.
kudo/nom: 743e7a3 | jnthn++ | src/vm/moar/ops/perl6_ops.c:
Chase MoarVM reframe branch changes.
kudo/nom: cebcdd5 | jnthn++ | src/vm/moar/ops/perl6_ops.c:
Ensure we don't read out-dated pointer.
kudo/nom: 260d5bd | jnthn++ | src/vm/moar/ops/perl6_ops.c:
Merge branch 'moar/reframe' into nom

Introduce .Map coercer
|Tux| rakudobrew build moar-blead
jnthn |Tux|: Yeah, that won't end well when I'm in the middle of merging in a batch of changes that need commits over 3 repos ;) 10:26
Try again now, the above push to the Rakudo repo was the final piece :)
Was just waiting for my spectest run to finish
|Tux| already building
|Tux| follows dalek
jnthn Also: the MoarVM change that just went in is a fairly notable internals refactor. It's been stress-tested to the point that I ended up shaking out and fixing bugs that were totally unrelated to the refactor along the way, so I'm hopeful there will be little fallout from this. 10:28
lizmat --output=gen/moar/stage1/nqpmo.moarvm gen/moar/stage1/nqpmo.nqp
make: *** [gen/moar/stage1/nqpmo.moarvm] Segmentation fault: 11
jnthn It's probably only an immediate performance win for compute-bound parallel programs and for giving lower GC times on programs that keep thousands and thousands of closures in memory 10:29
lizmat hmmm...
lizmat nukes install
jnthn: Moar doesn't build for me anymore :-( 10:30
jnthn ?
lizmat --output=gen/moar/stage1/nqpmo.moarvm gen/moar/stage1/nqpmo.nqp
make: *** [gen/moar/stage1/nqpmo.moarvm] Segmentation fault: 11
actually: 10:31
--output=gen/moar/stage1/nqpmo.moarvm gen/moar/stage1/nqpmo.nqp
make: *** [gen/moar/stage1/nqpmo.moarvm] Segmentation fault: 11
/Users/liz/Github/rakudo.moar/install/bin/moar --libpath=src/vm/moar/stage0 src/vm/moar/stage0/nqp.moarvm --bootstrap --setting=NULL --no-regex-lib --target=mbc \
jnthn How did you build? 10:32
'cus that's exactly the failure mode I got from a mis-merge earlier on
lizmat gist.github.com/lizmat/ad2ee697983...0ef2d1cf9f 10:33
perhaps I should nuke nqp as well ?
jnthn could try 10:34
799a0bda284c is indeed MoarVM HEAD
So that part looks right
/Users/liz/Github/rakudo.moar/install/bin/moar --version is worth a try just to be really sure 10:36
Failing that, try a build with MVM_JIT_DISABLE=1
lizmat same fail after nuking nqp dir 10:37
jnthn Darn OSX. :/ 10:38
jnthn just noticed that our Travis build for Moar only has Linux builds
lizmat builds ok with MVM_JIT_DISABLE=1
10:39 ZoffixWin joined
jnthn travis-ci.org/rakudo/rakudo/builds/129961395 has OSX though 10:40
But still running
lizmat jnthn: does building with MVM_JIT_DISABLE=1 mean there will be no jit at all ? 10:42
jnthn lizmat: Yes, though still the rest of spesh
lizmat ok
jnthn lizmat: Oh, it means it's only disabled provided that env var is set
|Tux| This is Rakudo version 2016.04-180-g1100877 built on MoarVM version 2016.04-124-g799a0bd
test 20.251
test-t 13.065
csv-parser 34.776
jnthn lizmat: It's Not Just You: travis-ci.org/rakudo/rakudo/jobs/129961401 10:43
It's seemingly the intersection of OSX and JIT changes.
lizmat yup, that's the one
perhaps some of the compilation warnings have a clue?
I mean, there seem to be more than before
jnthn None of them are near the JIT, alas. 10:44
There is one worth fixing, but if it were a problem we'd know about it in non-JIT builds too
Most of them are stylistic whining 10:45
lizmat src/profiler/heapsnapshot.c:681:25: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
seems at least indicating some real isse ? 10:46
jnthn Yeah
But can't be that
(Since that code only runs if you --profile=heap)
lizmat: Don't suppose you could cd into the nqp directory and run the failing command with gdb? 10:47
lizmat $ gdb
-bash: gdb: command not found
jnthn o.O
oh...clang 10:48
lldb? :)
lizmat trying 10:51
* thread #1: tid = 0x8f7e61, 0x000000010001b81d libmoar.dylib`MVM_interp_run + 67773, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7fff0000036b) 10:53
frame #0: 0x000000010001b81d libmoar.dylib`MVM_interp_run + 67773
libmoar.dylib`MVM_interp_run:
-> 0x10001b81d <+67773>: movq -0x48(%rbp), %rcx
0x10001b821 <+67777>: movzwl (%rcx), %eax
0x10001b824 <+67780>: addq $0x2, %rcx
0x10001b828 <+67784>: movq %rcx, -0x48(%rbp)
jnthn: does that help? 10:54
jnthn Also could you try at the prompt typing "bt" and pressing enter? 10:55
I *think* that works on lldb but I've not used it in ages
Though I can guess what the stack trace for there is anyway really
lizmat: And the build without JIT completed, yes? 10:58
lizmat yup 10:59
(lldb) bt 11:00
* thread #1: tid = 0x8f7e61, 0x000000010001b81d libmoar.dylib`MVM_interp_run + 67773, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7fff0000036b)
* frame #0: 0x000000010001b81d libmoar.dylib`MVM_interp_run + 67773
jnthn OK, thanks. 11:01
lizmat: I've disabled JIT at Configure time on OSX while we deal with this; if you could test for me building Moar HEAD and it's OK, then I'll bump NQP/MOAR revisions after lunch, so not to inconvenience anyone while we get it sorted out. :) 11:03
bbi20
11:18 travis-ci joined
travis-ci Rakudo build failed. jnthn 'Bump NQP_REVISION for latest MoarVM. 11:18
travis-ci.org/rakudo/rakudo/builds/129961395 github.com/rakudo/rakudo/compare/a...0087706494
11:18 travis-ci left 11:51 pmurias joined 12:22 Hotkeys joined 12:45 cognominal joined 12:50 tomboy65 joined
kudo/nom: d31495f | lizmat++ | src/core/Enumeration.pm:
Fix RT #128138

   $ 6 'enum Foo <a b>; dd Foo.enums'
   Map.new((:a(0),:b(1)))		 12:57
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128138
[Coke] I saw that os x was broken in backlog, but I thought a workaround had been put in. I just tried to build rakudo, it updated moar, I get a segfault. 12:59
lizmat if you use moar HEAD, it has JIT disabled and you should be able to build 13:00
[Coke] wipes install/ and tries again.
lizmat perhaps I should just bump NQP and Rakudo
[Coke] any reason why we can't bump NQP to use moar head then?
right.
lizmat yeah, I'll do it
[Coke] lizmat++
also, glad hoelzro is doing the release this month, then. :) 13:01
Is this a blocker for the May release?
I would lean towards yes.
dalek p: 6ef30d3 | lizmat++ | tools/build/MOAR_REVISION:
Bump Moar to get JIT disable on OS X
lizmat [Coke]: definitely a blocker :-) 13:02
[Coke] added an RT 13:04
dalek kudo/nom: 70e444a | lizmat++ | tools/build/NQP_REVISION:
Bump NQP to get JIT disable on OS X
jnthn Thanks for bumping; was tied up with a meeting :) 13:28
Now it's bumped, and if it's working, do we need an RT?
dalek p: 08e121c | (Pawel Murias)++ | src/vm/js/nqp-runtime/runtime.js:
[js] Better message for uncaught exceptions.
 13:32
p: f069115 | (Pawel Murias)++ | src/vm/js/nqp-runtime/s (2 files):
[js] Serialize modeFlags.
p: f968c27 | (Pawel Murias)++ | src/vm/js/nqp-runtime/serialization.js:
[js] Remove TODO that were done.
13:32 pmurias joined
p: 4ab2963 | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (4 files):
[js] Serialize and deserialize parameteric types.
lizmat jnthn: surely we want to fix the JIT on OS X ? 13:35
the RT is for that
jnthn lizmat: Hopefully we'll get it working again before the next MoarVM release, but I won't be backing out the frame refactors just for it. 13:36
lizmat well, that would just mean it's not a release blocker
DrForr lizmat: When are you getting in to Austin?
lizmat still something that would need to be fixed
jnthn Yes, completely agree it wants to be fixed. :)
And we've the better part of a week to do so. 13:37
lizmat DrForr: should be arriving in Houston around 1pm, expect to be in Austin around 6pm
jnthn Also, I'm fighting with Travis to try and get OSX builds in the MoarVM travis so we'd have spotted this sooner
lizmat DrForr: we'll be driving from Houston to Austin
DrForr Ah, you're just one flight behind me then, I get in at 2:30 local to Austin.
lizmat DrForr: no, not flying from Houston 13:38
DrForr yeah, just caught that. I think I get to Houston about an hour before that.
lizmat those small jumps are not worth the waiting, hassle of re-checking your luggage
and cost: usually renting a car is cheaper (especially if you intend to rent one anyway) 13:39
DrForr Yeah. 13:40
dalek ast/6.c-errata: e6cd197 | lizmat++ | S02-types/WHICH.t:
JSONPrettyActions should never been in here
 13:42
nine Aw packaging sucks 13:44
Somewhere between January and now precompilation of NativeCall broke because it can't load NQPHLL anymore but I'm quite certain that noone even got near nqp's module loading code. 13:45
13:46 cognominal joined
jnthn nine: When packaged, or just generally? 13:47
lizmat fwiw, RAKUDO_MODULE_DEBUG=1 6 'use NativeCall' seems to indicate it is loading precomp
nine jnthn: trying to update my openSUSE packages, i.e. MoarVM, nqp and rakudo packaged separately
and building as unpriviledged user into a separate BUILDROOT directory 13:48
13:50 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Introduce .Map coercer' 13:50
travis-ci.org/rakudo/rakudo/builds/129989717 github.com/rakudo/rakudo/compare/1...3b426e7f23
13:50 travis-ci left
dalek kudo/nom: ec1f7c1 | (Tom Browder)++ | src/Perl6/Compiler.nqp:
remove false statement until it is made true
 13:56
kudo/nom: a5389db | lizmat++ | src/Perl6/Compiler.nqp:
Merge pull request #766 from tbrowder/rakudo-man

remove false statement until it is made true
kudo/nom: 4b1acbb | lizmat++ | src/core/Process.pm:
Fix for RT #128099

Also for .Str and .Numeric		 14:09
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128099
14:10 brrt joined 14:28 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Fix RT #128138 14:28
travis-ci.org/rakudo/rakudo/builds/129989961 github.com/rakudo/rakudo/compare/0...1495ff87ef
14:28 travis-ci left
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128138 14:28
nine oooooooooooooh! tools/build/install-core-dist.pl is simply missing the NQP repo 14:45
How on earth can that ever work?!
timotimo :D :D 14:46
psch how would that go missing..? oO
oh
nevermind, i read an "in" there
nine The script completely replaces the repo-chain 14:47
Oh, it does so only if the DESTDIR directory passed as argument is not in the standard repo-chain. If it is, then we keep the rest of the chain intact as we just move the head.
[Coke] t/spec/S17-supply/syntax.t 14:48
er, seems to be flapping as normal here on os x.
lizmat [Coke]: yeah, flapping for me now as well again
jnthn [Coke]: Yeah, that's still on the "needs attention soon" list :) 14:49
[Coke] I'll remove the JIT as a blocker for the may release. :sadface: :)
jnthn Uh, *my* needs attentin soon list even :)
timotimo that sentence made zero sense until i saw the sentence it was meant to apply a correction to 14:50
lizmat [Coke]: fwiw, brrt is looking at it now on an OS X machine
jnthn heh, and I did a typo :)
nine YES YES YES!
lizmat afk for a few hours&
nine Loading precompiled /usr/share/perl6/precomp/469EC6236B55837D5F1435D042DB5322F043BD0B.1463150080.44484/C7/C712FE6969F786C9380D643DF17E85D06868219E
It loads the precomp file generated during packaging :) 14:51
timotimo urgh, those miles-long filenames :o
other than that: awesome! \o/
14:56 hankache joined
dalek kudo/nom: 3b39d0b | niner++ | tools/build/Makefile- (2 files):
Create precomp directories of standad repos during installation

Fixes unnecessary "Cannot create directory .../perl6/site/precomp" like errors when installing rakudo system wide.		 14:57
kudo/nom: 385f28b | niner++ | tools/build/install-core-dist.pl:
Fix "Could not find NQPHLL" when building with DESTDIR

When building with $DESTDIR the repository is not one of the standard repositories, so by replacing $*REPO with it, we also lose the rest of the repo chain and with it the NQP repository. Fix by always using the standard 'perl' repo's next-repo.		 15:09
jnthn nine++ 15:10
[Coke] does that resolve ShimmerFairy's recent ticket? 15:12
nine [Coke]: yes, I think we're finally through that now :)
Building a new set of rpms with these commits to confirm 15:13
15:13 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Bump NQP to get JIT disable on OS X' 15:13
travis-ci.org/rakudo/rakudo/builds/129991572 github.com/rakudo/rakudo/compare/d...e444a27d22
15:13 travis-ci left
psch github.com/rakudo/rakudo/blob/nom/....nqp#L8219 that's the bit i think is missing to bring that into the jvm slow path binder 15:15
i'm not quite sure how to replicate it...
nine And indeed the rpms work just fine :) 15:27
So, we should be good for building as unpriviledged user and installing system wide now. 15:28
[Coke] RT: 1291; CONC: 7; GLR: 6; JVM: 70; LHF: 2; LTA: 69; NYI: 27; OSX: 4; PERF: 15; POD: 3; PRECOMP: 3; RFC: 16; SEGV: 19; STAR: 1; TESTNEEDED: 25; TODO: 10; UNI: 5; WEIRD: 2 15:29
OSX: 7, after fixing the platform tracker to look at the real field, too. 15:32
15:56 travis-ci joined
travis-ci Rakudo build failed. lizmat 'Merge pull request #766 from tbrowder/rakudo-man 15:56
travis-ci.org/rakudo/rakudo/builds/130004538 github.com/rakudo/rakudo/compare/7...389db1b5a2
15:56 travis-ci left 16:06 skids joined
psch well, i did get Buf.push(Buf) working on r-j, but i get a parse failure in NativeCall::Compiler::GNU 16:09
because it doesn't recognize NativeCall::Types::void as a type
16:32 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Fix for RT #128099 16:32
travis-ci.org/rakudo/rakudo/builds/130007971 github.com/rakudo/rakudo/compare/a...1acbb21456
16:32 travis-ci left
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128099 16:32
17:14 travis-ci joined
travis-ci Rakudo build failed. Stefan Seifert 'Create precomp directories of standad repos during installation 17:14
travis-ci.org/rakudo/rakudo/builds/130020724 github.com/rakudo/rakudo/compare/4...39d0bbd36f
17:14 travis-ci left
timotimo well, "void" is a pointer, and java doesn't have pointers 17:33
17:37 brrt joined 17:42 ZoffixWin joined 17:55 sno joined 18:02 travis-ci joined
travis-ci Rakudo build failed. Stefan Seifert 'Fix "Could not find NQPHLL" when building with DESTDIR 18:02
travis-ci.org/rakudo/rakudo/builds/130024281 github.com/rakudo/rakudo/compare/3...5f28b78fa1
18:02 travis-ci left 18:11 TimToady joined
psch timotimo: i don't think that's the problem, considering NativeCall::Types::void maps to repr Uninstantiable 19:01
i mean, i recognize there's a bit of "haha only serious" in there, but it still seems to me that it's more likely that my changes just broke something else, instead of uncovering a fundamental incompatability between NC and the JVM... :) 19:02
nine psch: have you pushed your fix yet? 19:03
psch nine: the only fix i have that i haven't pushed is for getattr 19:04
nine: i don't have a fix for the broken install-core-dist.pl, i only have a patch that shifts the problem somewhere else
nine maybe there are actually two problems?
psch there's probably a few more than two problems somewhere inside nqp-j... :/ 19:09
anyway, the patch i do have doesn't solve #126493, so i'm thinking there's still something wrong there 19:10
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126493
psch gist.github.com/peschwa/e82fac05cb...6687a15aa1 is my attempt to replicate gist.github.com/peschwa/e82fac05cb...6687a15aa1 in the jvm Binder 19:12
err
github.com/rakudo/rakudo/blob/nom/....nqp#L8188 is the second link
not the gist... :)
because, afaiu, the slow path Binder on r-m doesn't really happen that often, which mean usually we run through Actions.nqp to do param binding 19:13
and r-j always uses its VM-level Binder
and, yeah, it solves Buf.push(Buf), which means it solves "this type does not support positional" or whatsit 19:14
but it still dies during install-core-dist.pl
with "Function 'NativeCall::Types::void' needs parens to avoid gobbling block (or perhaps it's a class that's not declared or available in this scope?)"
in NativeCall::Compiler::GNU:32 19:15
NC::T:void is scoped 'our' and is imported before, so i'd think it's something about topicalization in a given-block
but e.g. "given Int { when Int { say 'ok' } }" still works, so i'm out of ideas :)
...although that might change tomorrow or so vOv 19:16
in any case, i don't think pushing that half-fix is particularly useful. it doesn't feel atomic to me, more like sub-atomic, which is why i don't want to put it into a commit 19:17
nine Yep, time will probably help. Took me weeks to fully understand the BEGIN time EVAL thing and I was often at a point where I didn't have any idea anymore.
19:20 brrt joined
dalek p: 618c6be | lizmat++ | tools/build/MOAR_REVISION:
Bump Moar to get JIT fixes
 19:38
lizmat nine: gist.github.com/lizmat/2311c751663...99176d935f # Inline::Perl5 test/install failure 19:47
dalek kudo/nom: dcf6e44 | lizmat++ | tools/build/NQP_REVISION:
Bump NQP to get JIT back on OS X
 19:55
bartolin btw, the build was broken on FreeBSD, too (using clang). seems to work again with the latest fixes :-) 20:00
lizmat :-) 20:10
the build was broken everywhere, only the BSD's were anal enough to complain about it 20:11
20:22 sortiz joined
sortiz With latest: t/spec/S17-supply/syntax.t .................................... Failed 8/60 subtests # spectest still running... 20:25
20:25 ZoffixWin left
lizmat sortiz: known flapper 20:25
varies between builds as well :-(
sortiz Well, but today it fails consistently, after ok 52 with 'Aborted (core dumped)' 20:34
dalek kudo/nom: e39b21c | lizmat++ | src/core/Process.pm:
Simplify $*USER/$*GROUP initialization

The whole IdFetch class is no longer necessary with the new way of registering PROCESS:: dynamic variables. Also make creation of IdName objects faster with dedicated .new (although one could argue that for the two objects that will ever exist for this, this isn't needed).
Unless of course, we're going to make the IdName class public as a more generic "dualvar" class.		 20:35
sortiz On the bright side: t/spec/S32-num/power.rakudo.moar: TODO passed: 13-15, 68-70 20:36
lizmat sortiz: it only fails for me if PERL6LIB=lib is set
(which it is when run with make)
a bare perl6 t/spec/S17-supply/syntax.t doesn't fail for me 20:37
sortiz Yep, after a make install and running by hand, it succeed. 20:39
Will investigate...
lizmat sortiz: this problem may go away when all of jnthn's work in Moar lands 20:40
I wouldn't spend too much time on it now 20:41
but if you have in itch there, scratch it!
sortiz I have other itches. :-) 20:43
btw, thanks for the enums fix, indeed a Map coercer was needed. 20:45
lizmat yeah, that seemed as the most generic solution: might be needed in other places 20:47
20:52 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Bump NQP to get JIT back on OS X' 20:52
travis-ci.org/rakudo/rakudo/builds/130093728 github.com/rakudo/rakudo/compare/3...f6e446cb18
20:52 travis-ci left
lizmat m: class A is IntStr { method gist { "foo" } }; say A.new(42,"bar") # expected "foo" here 21:12
camelia rakudo-moar e39b21: OUTPUTĀ«barā¤Ā»
timotimo hm, un-subclassable problem? 21:13
lizmat the reason we don't see "foo" here, is that "say" has a candidate for Str:D which matches the IntStr:D
m: class A is IntStr { method gist { "foo" } }; say A.new(42,"bar").gist
camelia rakudo-moar e39b21: OUTPUTĀ«barā¤Ā»
lizmat huh?
psch m: class A is IntStr { method gist { "foo" } }; put A.new(42,"bar").gist
camelia rakudo-moar e39b21: OUTPUTĀ«barā¤Ā»
psch m: class A is IntStr { method gist { "foo" } }; print (A.new(42,"bar").gist) 21:14
camelia rakudo-moar e39b21: OUTPUTĀ«barĀ»
psch allomorphs are weird vOv
timotimo ah, hehe.
it makes sense to me that we'd directly print a Str-derived thing
lizmat m: say IntStr ~~ Str
camelia rakudo-moar e39b21: OUTPUTĀ«Trueā¤Ā»
lizmat m: sub a(Str:D $a) { dd $a }; a(IntStr.new(42,"foo")) 21:15
camelia rakudo-moar e39b21: OUTPUTĀ«IntStr.new(42, "foo")ā¤Ā»
psch m: class A is IntStr { method gist { "foo" } }; my $x = A.new(42,"bar").gist; say $x 21:16
camelia rakudo-moar e39b21: OUTPUTĀ«barā¤Ā»
psch how does that make sense..?
lizmat m: class A is IntStr { method gist { "foo" } }; my $x = A.new(42,"bar").gist; say $x.gist
camelia rakudo-moar e39b21: OUTPUTĀ«barā¤Ā»
psch m: class A is IntStr { method gist { "foo" } }; say A.new(42,"bar").gist eq 'foo' 21:17
camelia rakudo-moar e39b21: OUTPUTĀ«Falseā¤Ā»
psch m: class A is IntStr { method gist(A:D:) { "foo" } }; say A.new(42,"bar").gist eq 'foo'
camelia rakudo-moar e39b21: OUTPUTĀ«Falseā¤Ā»
psch m: class A is IntStr { method gist(A:U:) { "foo" } }; say A.gist eq 'foo'
camelia rakudo-moar e39b21: OUTPUTĀ«Trueā¤Ā»
lizmat m: class A is IntStr { multi method gist(A:D:) { "foo" } }; say A.new(42,"bar").gist 21:19
camelia rakudo-moar e39b21: OUTPUTĀ«barā¤Ā»
lizmat aaah....
dalek kudo/nom: b0254d5 | lizmat++ | src/core/allomorphs.pm:
Allow subclassing of IntStr
lizmat had already fixed this locally 21:20
ok, I guess we don't want to make the Str:D say candidate any more involved 21:21
dalek kudo/nom: 02e6b35 | (Salvador Ortiz)++ | lib/NativeCall.pm6:
NativeCall: Add ssize_t to $type_map

Needed to by usable as an argument		 21:26
kudo/nom: 91f31ac | lizmat++ | lib/NativeCall.pm6:
Merge pull request #767 from salortiz/patch-3

NativeCall: Add ssize_t to $type_map
nine lizmat: I though jnthn++'s fixes have landed already? 21:33
lizmat all of the reframe ones? 21:34
nine I think so
lizmat I only thought some fixes made it ?
nine Also I can reproduce those Inline::Perl5 failures. Will fix tomorrow
lizmat ++nine :-)
nine Well I don't really know any better than you
Oh, those failures are segfaults 21:35
Maybe they're actually reframe regressions.
segfaults in MVM_gc_root_temp_push_slow
jnthn: gist.github.com/niner/5397c59cbc44...7443142ef1 21:36
dalek kudo/nom: 3614487 | lizmat++ | src/core/Process.pm:
Get rid of internal IdName class altogether

Since we now have IntStr, we actually don't need it anymore.
Small incompatibility change: before, .gist would return
   "$!name ($!id)"
but since IntStr:D is a Str:D, it will use the Str.gist, which would just be the name. This does not cause any spectest breakage.		 21:37
nine Yep, all 3 test files segfault with the same backtrace
nine This ain't right: 21:38
(gdb) p tc->num_temproots
$2 = 4294967294
temproot count underflow I dare say :)
jnthn: ^^^
jnthn nine: Hm. In src/moar/roots.h, there's a MVM_TEMP_ROOT_DEBUG that can be set to 1 21:39
nine Happens with MVM_SPESH_DISABLE=1, too and is 100 % reproducable. This should actually be somewhat simple to figure out
jnthn Yeah, though sensitive to a few things, so try to leave everything unchanged except building a MoarVM that way 21:40
And then breakpoint in MVM_panic
nine Have to watch some Married with Children now though. So will work on this tomorrow :)
jnthn And we should easily find the guilty party
Though the backtrace is a good clue too
21:41 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Simplify $*USER/$*GROUP initialization 21:41
travis-ci.org/rakudo/rakudo/builds/130101842 github.com/rakudo/rakudo/compare/d...9b21c669b9
21:41 travis-ci left
jnthn Hm, really odd 21:42
The MVMROOT macro is used throughout the caller
nine Illegal attempt to pop empty temporary root stack 21:43
Is the only new output
jnthn Right, so it was indeed underflow
nine Ok, my girlfriend gently pushes me towards relaxation :) Good night! 21:44
jnthn nine: 'night...if I can't spot it myself, guess we continue debugging later :)
lizmat night nine! 21:45
jnthn Darn it, it really looks from the code that said problem should be "impossible"... 21:46
psch ah, one of those "this should never happen" that actually happens? :) 21:51
lizmat good night, #p6dev!
psch 'night lizmat, nine o/
jnthn 'night, lizmat
psch: Well, we have a macro MVMROOT(tc, object, {...}); that runs the block, rooting first and unrooting after it. 21:52
psch: You can in theory screw it up if you were to do, for example, flow control that takes you out of that, but that's result in leaving too much on the stack rather than too little...
psch jnthn: "rooting" means "mark as non-collectable" i assume? 21:54
dalek p: 3c4f0ff | peschwa++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java:
Make getattr mostly work like it does on moar.

Well, mostly, hopefully. There might be a case where we have multiple Fields that could take the attr we got, and we wrongly assign to the first we find.		 21:55
psch ...that was lying around for a bit, thought i might as well push it
jnthn psch: That together with "and update the pointer if the object moves" 22:01
psch: I wrote some explanation in 6guts.wordpress.com/2016/04/30/ref...d-torture/ if you're curious :) 22:03
psch yeah, i might have a look later 22:04
still, it's somewhat peripheral to what i'm usually working on... 22:05
jnthn Yes, unless you're interested in hacking on MoarVM you can easily not know about it :) 22:06
psch it's not that i'm not interested in hacking on MoarVM, it's just that's i'm more interested in keeping two backends working ;) 22:10
TimToady psch++ 22:11
jnthn psch: Yeah, this piece won't help you in that mission, so you can skip it :) 22:14
And psch++ indeed
psch oh, i don't doubt that it's still interesting and educational. it's just not immediately useful :) 22:17
jnthn aye :) 22:20
22:41 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Allow subclassing of IntStr' 22:41
travis-ci.org/rakudo/rakudo/builds/130110921 github.com/rakudo/rakudo/compare/e...254d521dd1
22:41 travis-ci left 23:59 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Get rid of internal IdName class altogether 23:59
travis-ci.org/rakudo/rakudo/builds/130114582 github.com/rakudo/rakudo/compare/9...14487bdab3
23:59 travis-ci 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!