Zoffix :S "Unhandled exception: Missing or wrong version of dependency 'gen/moar/stage2/QRegex.nqp' (from 'src/Perl6/Pod.nqp')" 00:06
gist.github.com/zoffixznet/d17c923...bf48222ad8
Oh. I see why. Ran it with `perl6` but it runs `./perl6-m` somewhere inside 00:07
FWIW, I'm preparing release in this fork and will create a PR for merging on 18th: github.com/zoffixznet/rakudo/tree/...se-2016-06 01:46
And will use same branch name for nqp fork. It doesn't look like I need to "prepare" it in advance though :)
Fixed. Thanks. 01:49
MasterDuke does anybody else see pretty regular "*** Error in `/home/dan/Source/perl6/install/bin/moar': double free or corruption (!prev): 0x00007f6b14fe4710 ***" when using Promise.allof? 02:24
timotimo are you using a library or something that isn't threadsafe? 02:25
MasterDuke i'm trying to make perl6/doc/htmlify.p6 faster 02:26
so some of the slow bits i turned into starts + await(Promise.allof(@starts)) 02:28
timotimo mhm
MasterDuke this one is new "Internal error: zeroed target thread ID in work pass" 02:29
timotimo ah, yeah, multithreaded breakage
what exact version are you on right now? 02:30
MasterDuke This is Rakudo version 2016.05-150-gc7cd003 built on MoarVM version 2016.05-34-gfbe9e24
i really want to use the concurrency stuff, but keep running into seg faults, weird errors, etc. 02:32
timotimo hmm, ok
MasterDuke a little offputting
timotimo well, you can try valgrinding it :\
i'm not sure what parts you are encountering that aren't threadsafe
MasterDuke git diff output, gist.github.com/MasterDuke17/d06f0...426ef33d52 02:33
timotimo how would oyu feel about actually valgrinding it? 02:37
MasterDuke i just started it with perl6-valgrind-m
timotimo how long does it usually run before it crashes?
MasterDuke it's always been in one of the "Processing <type> Pod files ...' steps 02:39
a couple 'Syscall param write(buf) points to uninitialised byte(s)' so far 02:40
timotimo i'm not actually sure what the extract-pod and process-pod-source subs do
MasterDuke those valgrind messages appeared to happen between 'Initializing ...' and 'Creating html/ subdirectories' 02:41
timotimo oh, that's interesting 02:42
do you get stack traces with those? like, with actual line numbers?
MasterDuke first bunch of output from valgrind, gist.github.com/MasterDuke17/4167f...d5dc657803 02:43
timotimo it was spawning multiple processes 02:44
MasterDuke seems so, also, that was before any of my changes 02:45
oh damn, that was/is my system perl6 (2016.05 built on MoarVM version 2016.05), not the compiled-from-head i usually use for testing 02:49
timotimo i'm not sure if there were many multithreading improvements recently 02:52
before 2016.05, though, yeah. but i'm not sure when exactly
MasterDuke i guess i'll let this one keep going and then run again with a more recent perl6 02:54
timotimo OK
MasterDuke couple more of those errors, gist.github.com/MasterDuke17/8561e...52c20b589f 02:55
timotimo strange.
MasterDuke hmm. now "killed" 02:56
timotimo out of memory, probably 02:59
MasterDuke gotten to 'Writing specialized visualizations to html/images/ ...' with no messages from valgrind so far when using the up-to-date perl 6, but has been sitting there for a while 03:30
b2gills MasterDuke: You should realize that ļ½¢await(Promise.allof(@starts)); my @returned = @startsĀ».resultļ½£ can be simplified to just ļ½¢my @returned = await(@starts)ļ½£ 03:41
ugexe github.com/rakudo/rakudo/commit/66...2c22774388 is giving me 'Outdated precompiled' errors 04:09
and if its run with RAKUDO_MODULE_DEBUG=1 it gives Failed to find 'sources/9FA0AC28824EE9E5A9C0F99951CA870148AE378E' while trying to do '.modified' 04:12
zef actually has tests for these types of things in xt/install.t 04:20
nine ugexe: how can this commit give you errors when the agument hasn't been used by any caller?! 05:34
psch hrm 06:44
so, yeah, i do get a Hash in QAST::Compiler 06:45
but i can't reach the perl6 hll to get the type to reach its $!storage
oh duh 06:50
i can just de-hllize in src/control.pm >_>
[Tux] This is Rakudo version 2016.05-150-gc7cd003 built on MoarVM version 2016.05-18-g1339332 07:25
test 17.363
test-t 9.752
csv-parser 21.586
psch gist.github.com/peschwa/a48ca71403...79d18766c7 07:50
i think i should be able to work with that \o/
although i'm a bit befuddled that the second EVAL has the missing qbid
and the fact that it's compiling both evals twice (and NC::Types actually like 8 times..?) also hints at some holes in my understanding 07:51
nine psch: but it's progres nevertheless :) 08:16
psch nine: FSVO, probably... :) 08:25
i'm mostly confused with trying to pull apart what RAKUDO_MODULE_DEBUG adds to that
i've updated the gist, fwiw 08:28
like, i'm having trouble mapping the EVAL_* "files" to stages during precomp
and well, with the missing qbid happening in the second EVAL, it kinda feels like it's not really a missing nested CU, but just something else gone wrong, although i don't really know how i would verify that 08:29
the off-by-one-ish error with cuid_to_qbid seems suspect, but... 08:30
MasterDuke timotimo: ran overnight, but never finished with the up-to-date rakudo, here's the output after i killed it, gist.github.com/MasterDuke17/0669d...2578872e87 11:32
b2gills: thanks, that's simpler
ugexex nine: i should have been more clear: i mean thats the latest commit i was using. it could be anything within the last week or so 14:18
note that zef still works fine for the general use case, just that test fails. so i suspect it has to do with installing to inst#/custom/dir. I'm not able to dig deeper for a week or so or i'd have tracked it down myself 14:27
BrokenRobot bisect: 2 āˆˆ <2> or die 14:51
bisectable BrokenRobot: on both starting points the exit code is 1 and the output is identical as well
BrokenRobot m: 2 āˆˆ <2>
camelia rakudo-moar c7cd00: OUTPUTĀ«WARNINGS for <tmp>:ā¤Useless use of "āˆˆ" in expression "2 āˆˆ <2>" in sink context (line 1)ā¤Ā»
BrokenRobot m: say so 2 āˆˆ <2>
camelia rakudo-moar c7cd00: OUTPUTĀ«Falseā¤Ā»
BrokenRobot Should that be a True?
geekosaur notes that the former is an Int and the latter an IntStr 14:53
timotimo oh damn 14:55
BrokenRobot Yeah, but IntStr is really more of a convenience IMO
timotimo inconvenience, you mean :)
BrokenRobot heh 14:56
It uses .WHICH to check for existence. 15:00
m: class Foo {}; my $a = Foo.new; my $b = Foo.new; .WHICH.say for 2, <2>, $a, $b 15:01
camelia rakudo-moar c7cd00: OUTPUTĀ«Int|2ā¤IntStr|2ā¤Foo|83205328ā¤Foo|83205360ā¤Ā»
BrokenRobot Not a bug, I guess, but it makes my awesome method to check thing's existence in array less awesome 15:05
m: my @a = <a b c 2>; say 2 āˆˆ @a
camelia rakudo-moar c7cd00: OUTPUTĀ«Falseā¤Ā»
BrokenRobot m: my @a = <2>; my @b = 2; say @a eqv @b; 15:13
camelia rakudo-moar c7cd00: OUTPUTĀ«Falseā¤Ā»
BrokenRobot Inconvencience indeed.
lizmat waves from Orlando 15:20
jdv79 is it hot out? 15:21
nine lizmat: o/ 15:23
dalek ast: a7ed445 | (Daniel Green)++ | S02-literals/adverbs.t:
Add test for RT #128306
 15:30
ast: 1ab6884 | lizmat++ | S02-literals/adverbs.t:
Merge pull request #126 from MasterDuke17/RT128306

Add test for RT #128306
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128306
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128306
BrokenRobot m: $_ = "foo"; .say if ~~Str 15:58
camelia rakudo-moar c7cd00: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Expected a term, but found either infix ~~ or redundant prefix ~ā¤ (to suppress this message, please use a space like ~ ~)ā¤at <tmp>:1ā¤------> $_ = "foo"; .say if ~~āStrā¤Ā»
BrokenRobot prefix:<~~> could function as infix:<~~> against $_ on LHS 15:59
[Coke] m: say ~~3;
camelia rakudo-moar c7cd00: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Expected a term, but found either infix ~~ or redundant prefix ~ā¤ (to suppress this message, please use a space like ~ ~)ā¤at <tmp>:1ā¤------> say ~~ā3;ā¤Ā»
[Coke] m: say ~ ~3; 16:00
camelia rakudo-moar c7cd00: OUTPUTĀ«3ā¤Ā»
[Coke] guess there's no confusion with ~ ~
sortiz
.oO( 'if ~~' can be spelled when )
 16:03
BrokenRobot But only in statement modifier form 16:06
m: for <a b c> { if $_ ~~ "a" { .say }; say "meow" } 16:07
camelia rakudo-moar c7cd00: OUTPUTĀ«aā¤meowā¤meowā¤meowā¤Ā»
lizmat "feels like 36 outside"
BrokenRobot m: for <a b c> { when "a" { .say }; say "meow" }
camelia rakudo-moar c7cd00: OUTPUTĀ«aā¤meowā¤meowā¤Ā»
lizmat jdv79: when it is "only" 32
BrokenRobot m: .WHAT.say for 1+i, <1+i>, <1+1i> 16:19
camelia rakudo-moar c7cd00: OUTPUTĀ«(Complex)ā¤(Str)ā¤(Complex)ā¤Ā»
lizmat Seems to be something in the parser: 16:20
m: sub prefix:<~~> { dd CALLER::<$_>, $^a; CALLER::<$_> ~~ $^a }; $_ = "foo"; .say if ~~ Str
camelia rakudo-moar c7cd00: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Expected a term, but found either infix ~~ or redundant prefix ~ā¤ (to suppress this message, please use a space like ~ ~)ā¤at <tmp>:1ā¤------> R::<$_> ~~ $^a }; $_ = "foo"; .say if ~~ā Strā¤Ā»
lizmat m: sub prefix:<abc> { CALLER::<$_> ~~ $^a }; $_ = "foo"; .say if abc Str
camelia rakudo-moar c7cd00: OUTPUTĀ«fooā¤Ā»
BrokenRobot It's the same for other stuff that warns: 16:24
m: sub infix:<?> {}; sub infix:<:> {}; say 2 ? : 2 16:25
camelia rakudo-moar c7cd00: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Unsupported use of ? and : for the ternary conditional operator; in Perl 6 please use ?? and !!ā¤at <tmp>:1ā¤------> infix:<?> {}; sub infix:<:> {}; say 2 ?ā : 2ā¤Ā»
BrokenRobot s/warns/errors out/;
[Coke] m: say ComplexStr.WHAT 16:37
camelia rakudo-moar c7cd00: OUTPUTĀ«(ComplexStr)ā¤Ā»
BrokenRobot m: use Test; sub blarg {$^a}; say blarg 42; eval-dies-ok "blarg 42" 16:56
camelia rakudo-moar c7cd00: OUTPUTĀ«42ā¤ok 1 - ā¤Ā»
BrokenRobot isn't sure why there is an eval-dies-ok in the first place.
[Coke] to simplify testing for something that is supposed to die? 17:01
BrokenRobot [Coke]: there's dies-ok 17:02
[Coke] m: use Test: eval-dies-ok "3"; #doesn't die, so test fails. not sure why your blarg example dies (and therefore passes) 17:03
camelia rakudo-moar c7cd00: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Confusedā¤at <tmp>:1ā¤------> use Testā: eval-dies-ok "3"; #doesn't die, so tesā¤Ā»
BrokenRobot Make it take Str/Callable just like throws-like
BrokenRobot is filing a Bug and an RFC ATM
[Coke] dies-ok takes code, eval-dies-ok takes a string.
so with eval-dies-ok, the code doesn't have to compile, even. 17:04
with dies-ok, it has to compile and then die
BrokenRobot No it doesn't 17:05
dies-ok can take Str
s/can/should/
[Coke] Calling dies-ok(Str) will never work with any of these multi signatures:
BrokenRobot I think we're talking past each other here.. 17:06
[Coke] I'm telling you how it is, you're asking for it to change.
I think that's where we are.
no?
geekosaur wasn't there a specific push to avoid using EVAL when it's not needed? 17:08
BrokenRobot [Coke]: more proposing than asking. I know how it is and I think it's hairy and is inconsistent with other subs in the module. 17:11
RFC: rt.perl.org/Ticket/Display.html?id=128418 17:12
Bug: rt.perl.org/Ticket/Display.html?id=128417
dalek ast: d4dd53b | niner++ | / (3 files):
Tests for RT #126878
 17:17
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126878
jnthn If you want it to evaluate in the current context, then it must be done via a closure that uses EVAL 17:20
dies-ok { EVAL '...' } 17:21
Or throws-ok { EVAL '...' }
BrokenRobot jnthn: but throws-ok already evals in proper context, why not make dies-ok do the same? 17:22
jnthn How does it do it?
BrokenRobot :context( CALLER:: ....
jnthn dammit
BrokenRobot lol
jnthn That *will* break.
Soon.
As soon as the optimizer gets better. 17:23
So we should address that soon.
BrokenRobot k, I'll close dies-ok bug and open one for throws-like
jnthn That context named arg should also go away, it's too open to abuse.
In so far as, it's really tempting to think it's going to reliably work out 17:24
But the design docs are clear that the only variables you can rely on being visible through CALLER:: are those marked "is dynamic" (or declared $*foo)
Anyways, thank for noticing the inconsistency. 17:25
lizmat jnthn: so lemme get this straight: throws-like accepting a Str is wrong, but otherwise you're fine with throws-like ? 17:26
jnthn Just saw your message in RT... :) 17:27
lizmat :-)
jnthn The things that I eliminated were cases of throws-like ..., X::AdHoc
The reason being that X::AdHoc mostly means "we didn't yet get to putting in a properly typed exception" 17:28
You *could* write those cases as throws-like ..., Exception;
Which is just a long way to spell dies-ok ...
Thus why I can imagine me switching some throws-like to dies-ok
lizmat well, but you lost information there :-( 17:29
jnthn How so?
I mean, the spectests should not be asserting we throw X::AdHoc
lizmat when I was going through roast last year, I found quite a few cases were dies-ok tests were succeeding for the wrong reason 17:30
jnthn Otherwise it's just a pain when we *do* put in a proper exception, 'cus it's cause errata
[Coke] lizmat: yes, but x::adhoc is not information worth saving
jnthn Sure, but the way we should be addressing that is by adding more typed exceptions.
lizmat it at least meant I had a look at it :-(
[Coke] we need to finish going through all the exceptions and if we're going to type them, type them.
lizmat now that info is all gone :-(
jnthn It's a git repo, how is anything lost?
lizmat if the commit cannot be reapplied, it is effectively lost 17:31
[Coke] but it shouldn't be reapplied.
we should not be tsting specifically that we are throwing the Adhoc exception.
lizmat well, to me they were canaries 17:32
whenever we would put in a typed exception were there wasn't one before
it would fail
[Coke] (because then it's stuck in (e.g.) 6.c release and the thought was we couldn't change it without a spec change)
lizmat so we could fix it
dalek ast: 0d22c77 | niner++ | / (5 files):
Tests for RT #117117
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=117117
lizmat now, whenever we put in a new typed exception, the dies-ok still fails
but we cannot be sure it failed for the right reasone :-(
[Coke] we just ran out of time before christmas to do it the right way, or to flush out issues.
lizmat well, I would have gladly fixed the errata with a dies-ok, if the Ad-Hoc started failing 17:33
anyways, water under the bridge
[Coke] Yup, we still have to fix that. let's try to make sure we have a good answer in place for 6.d
jnthn Note that you could quite easily run a tweaked Test.pm that reports under-specific exception types :) 17:34
[Coke] lizmat: I think the thought was at the time was that that would constitute an incompatible chagne.
I think we could probably document our way out of that bag now, but let's make that part of the plan for 6.d
gah, gotta run. laters.
jnthn dinner, but I can write up said Test.pm tweak later if it's not clear :) 17:35
&
nine procrastination++ # so far I've found and fixed the real reason behind RT #128156, started a good refactor branch for after the release and got us rid of 4 RT tickets 17:59
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128156
nine What I actually wanted to do was add a dependency loop detection for RT #128285 but I have a hard time deciding where exactly 18:01
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128285
nine Well at least I just now found that it's actually a duplicate of RT #126688 18:03
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126688
lizmat nine++ 18:06
afk&
sortiz nine, btw, I use RMD a lot and found confusing the reverse order of its output, moreover without a time stamp.
nine sortiz: yes, same here. I'm no fan of capturing STDERR during precompilation but it really seems necessary. 18:07
sortiz nine, can you elaborate a little? 18:09
(about the necessity) 18:10
nine sortiz: rt.perl.org/Ticket/Display.html?id=127176 18:11
sortiz nine, I understand, Tnks. 18:16
dalek kudo/nom: 07c8267 | niner++ | src/core/CompUnit/ (2 files):
Remove .rev-deps cache

  .rev-deps files were a good idea at the time for tracking which reverse-
dependencies we have to recompile after updating a module. But that was when we only ever used a single precomp store at a time, so everything of interest would be found in the same store.
Now a reverse dependency may be in a store further up the chain and .rev-deps files are possibly incomplete. They are also a problem for packaging modules as they are changed on installation of other modules. Removing them also clears the way for fixing the PrecompilationStore abstraction.		 18:52
rakudo/nom: 2126eda | niner++ | src/core/CompUnit/PrecompilationRepository.pm:
nine Zoffix: there's one of your release blockers ^^^
BrokenRobot nine: do you mean that's a new one or something that was fixed? 18:54
I didn't have that on release blocking list 18:55
Ohh
BrokenRobot retracts the Ohh 18:56
nine ?
Ooops! 18:57
Damn...I had that commit on nom, too instead of only the branch
BrokenRobot: I meant github.com/rakudo/rakudo/commit/21...5e26c88bc6 fixing rt.perl.org//Public/Bug/Display.html?id=126688 18:58
Add protection against circular dependencies in precompilation 18:59
Die with a hint about what's wrong instead of spawning more and more processes. Fixes all cases reported in RT #126688 Note that we can still loop endlessly when loading modules from source.
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126688
BrokenRobot Ah :) nine++
nine .rev-deps[1~The [4~ commit was meant for after the release

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!