travis-ci Rakudo build errored. Zoffix Znet 'Add S24-testing/8-die_on_fail.t to list of tests to run' 00:52
travis-ci.org/rakudo/rakudo/builds/153129466 github.com/rakudo/rakudo/compare/1...7fb7d90549
buggable ✓ [travis build above] One job failed due to the timeout. No other failures.
MasterDuke is anyone else seeing *really* long precomp times with a rakudo built today? compared to a rakudo built yesterday for example 01:02
Zoffix t/04-nativecall/06-struct.t started failing for me, but only when run with `make test` :/ 01:42
gist.github.com/zoffixznet/9fa7ea1...bc7b76cda2 01:46
And these spectest fail (I believe this was already identified above; the modules stuff gist.github.com/zoffixznet/4cc3e21...b04ec681a0 )
And yet all pass if run by themselves (╯°□°）╯︵ ┻━┻ gist.github.com/zoffixznet/278dc7e...2e573fa4ec 01:48
REPL breakage is by github.com/rakudo/rakudo/commit/be...0c8b42eec0 01:57
Trying to figure out the fix.
Well, I think I have a fix but I've no idea why it worked before :/ 02:28
The fix being removing this reset: github.com/rakudo/rakudo/commit/be...de1a04R390
Actually the fix won't fix anthing, 'cause it just evals the code from the start. It's something to do with context and I've no idea what they are 03:02
.tell lizmat be7ce041a8 breaks variables in REPL (RT#128973). I tried to fix it and it looks like it has something to do with context and they appear to behave different when in different thread? I've don't know what contexts are yet, so I failed at fixing this. Perhaps you would know how to fix it? 03:16
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128973
yoleaux2 Zoffix: I'll pass your message to lizmat.
Zoffix yoleaux2, botsnack 03:17
synopsebot6 om nom nom
Zoffix Hey! That's just rude, synopsebot6!
Zoffix hibernates
dalek ast: da7a590 | (Zoffix Znet)++ | S19-command-line/repl.t:
Re-fudge tests for RT#127933

The unfudging happened due to passing TODOs, however, that pass happened due to RT#128973, which merely shadowed this bug.		 03:25
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127933
Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128973
nine lizmat: now that I've run the 5th spectest I can finally reproduce the issue here 07:28
yoleaux2 17 Aug 2016 22:15Z <lizmat> nine: with 848add944fe6de9090f0 and 7d804663db8fdd331 reverted, all works fine for me :-(
nine I have a theory: S10-packages/precompilation.t actually writes files into t/spec/packages. When this happens between nested.t precompiling A.pm and B.pm file#t/spec/packages' id changes. This id is included in the precomp ids. Therefor when compiling B.pm, we calculate a different precomp id for Grammar.pm 07:42
So there's two different precomp files for Grammar.pm which then collide. 07:43
I think the solution will be to change CompUnit::Repository::FileSystem::!comp-unit-id to just nqp::sha1($name); instead of nqp::sha1($name ~ self.id); 07:47
But it's hard to know the implications :/ And harder to test as the error is so much depending on timing. 07:52
[Tux] test FAIL again. will have a look later 07:55
nine And I still get a flapping S11-modules/require.rakudo.moar :/ 08:11
lizmat . 08:19
yoleaux2 03:17Z <Zoffix> lizmat: be7ce041a8 breaks variables in REPL (RT#128973). I tried to fix it and it looks like it has something to do with context and they appear to behave different when in different thread? I've don't know what contexts are yet, so I failed at fixing this. Perhaps you would know how to fix it?
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128973
dalek kudo/nom: 643c0f9 | lizmat++ | src/core/REPL.pm:
Revert "Make the REPL catch CONTROL-c when executing"

This reverts commit be7ce041a800a9b3f4b532b84583ce0c8b42eec0.
No time to fix regression of losing defined variables now. Will have to wait until after the release.		 08:20
nine Ok, nested.t failed again. So my "fix" didn't actually work :/ 08:25
But it also doesn't seem to be the same issue. The test runs just find when run individually 08:26
lizmat nine: am about to start commuting to Cluj 08:32
it's gonna take a few days where I'll be mostly offline
won't be able to test anything until much later today (if at all) 08:33
DrForr lizmat: Good luck! See ya here in a few days! HEAL, DAMNIT!
lizmat DrForr: working on it :-)
nine lizmat: ok. Have fun! See you in Cluj :)
lizmat commuting&
nine Both require.t and nested.t now fail before even outputting a test plan. So I guess they die trying to calculate the sha1s of the files in the FileSystem repo. Could really be some weird issue reading the files. 08:55
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Revert "Make the REPL catch CONTROL-c when executing" 09:15
travis-ci.org/rakudo/rakudo/builds/153202296 github.com/rakudo/rakudo/compare/e...3c0f902598
|Tux| one out of every 3 test runs FAIL's, so it is very very hard to pinpoint what is failing 09:55
timotimo oh crap 09:59
ItayAlmog Should the compiler give error about accessing class attribute (has) at runtime or compilation? 10:00
jnthn Can catch those at compile time 10:01
Though not until class composition time (on the closing curly)
Due to roles
timotimo GTK::Simple is now incredibly slow to start up and to compile and install
ItayAlmog Yeah, But how can I know if you are calling a defined type at compile time ? 10:03
jnthn "calling a defined type"? 10:09
nine Looks like we'll have to revert 848add944fe6de9090f0 and 7d804663db8fdd331 for now :/ 10:10
jnthn We can't type check assignments to attributes at compile time in general, but we can check they exist at least, which is what I thought you meant. 10:11
ItayAlmog like, saying you have a class which has an attribute x and method getX, than it means you need to initialize the class first with the new method.
So for right now It will do the check at compile time :\ 10:12
at runtime* 10:13
jnthn Can you give an example?
m: class C { has $!x; method getX() { $!xx } }
camelia rakudo-moar 643c0f: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Attribute $!xx not declared in class C␤at <tmp>:1␤------> ss C { has $!x; method getX() { $!xx } }⏏<EOL>␤»
jnthn Do you meant that kind of error (which is compile time)?
ItayAlmog no, one sec
|Tux| This is Rakudo version 2016.07.1-214-g643c0f9 built on MoarVM version 2016.07-18-g2f269d8 10:14
ItayAlmog m: class T { has $x; method setX() { $x++ }; } T.setX()
|Tux| csv-ip5xs 9.905
test 15.093
test-t 7.249
csv-parser 16.534
camelia rakudo-moar 643c0f: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Strange text after block (missing semicolon or comma?)␤at <tmp>:1␤------> ss T { has $x; method setX() { $x++ }; }⏏ T.setX()␤ expecting any of:␤ infix␤ infix stopper␤ …»
ItayAlmog m: class T { has $x; method setX() { $x++ }; }; T.setX()
camelia rakudo-moar 643c0f: OUTPUT«Cannot look up attributes in a type object␤ in method setX at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
jnthn Oh, *that* one is runtime
ItayAlmog ok :
jnthn Though theoretically possible at compile time in simple cases like that one. 10:15
ItayAlmog sorry I didn't explained the problem well :)
Yeah, in theory it can make these simple tests to help the user yeah, So runtime it is :) 10:16
Zoffix I'm thinking we move the REPL start {} block to be around the REPL loop and attach a SIGINT handler that will throw. We then await and check for that specific throw and restart that Promise if it was an attempt to abort a running code, and will probably fix the variable issue too. 10:31
Zoffix will test sometime today
timotimo, MasterDuke also was reporting slowness in modules last night 10:32
How do you trigger the partial line mode in REPL, where it waits for you to enter the rest of the line even if you press ENTER? I saw that codepath last night, but couldn't enter it. It just kept giving me errors on partial lines 10:39
DrForr Well, Perl6::Tidy finally catches all the whitespace in and after 'sub foo( Str $a where 'foo' ) { }', which is more formidable of a challenge than it should be :)
nine timotimo: Does reverting 848add944fe6de9090f0 and 7d804663db8fdd331 help with your performance issue?
masak ItayAlmog: suggestion: to always put in the twigils for clarity, like `has $!x;` or `has $.x;` 11:17
ItayAlmog ok :) 11:29
m: class P { has $.x = 5; }; class T is P {}; T.x 11:32
camelia rakudo-moar 643c0f: OUTPUT«Cannot look up attributes in a type object␤ in block <unit> at <tmp> line 1␤␤»
ItayAlmog m: class P { has $.x = 5; }; class T is P {}; T.new.x
camelia ( no output )
ItayAlmog m: class P { has $.x = 5; }; class T is P {}; say T.new.x 11:33
camelia rakudo-moar 643c0f: OUTPUT«5␤»
unmatched} *sigh* trying to use Atom over sshfs over slow network is rather painful. 12:21
I wish I liked vim... or any other terminal-based editor :/ 12:22
DrForr One of the benefits of vim is it's pretty much anywhere you are :)
unmatched} Maybe I can force myself to like it somehow 12:23
DrForr For me it's more muscle memory than anything. Plus it gives you a chance to wear out different keys on the keyboard. 12:25
unmatched} The whole edit mode/insert mode or whatever is is annoying as well. I have CTRL+S in muscle memory that I probably press it after every few words 12:26
dalek ast: 2d3fa13 | (Zoffix Znet)++ | S19-command-line/repl.t:
Declared variables must persist across multiple lines of input

RT#128973		 12:27
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128973
ShimmerFairy unmatched} for the record, I use vim when I need to make quick edits in-terminal, it's not too bad in that respect. But emacs is superior for any real editing :P 12:41
lucs unmatched}: I've got my "save" mapped to "::" in vim -- I think I reflexively press it every time I stop typing (so, very, very often). 12:51
What I like about Vim is that I can very easily set up my config on just about any machine from my git repo. 12:52
unmatched} yeah, but I don't want to read thousand pages of information just to learn how to configure my editor :) 12:53
Same thing with Atom. It may be a "hackable editor" but just try making it auto-close parentheses without auto-closing quotes too :) 12:54
lucs Turns out I probably read those thousand pages, but I did it over a period of many years :p
ShimmerFairy lucs: that's what gets me in trouble with vim, since trying C-x C-s to save gets you a suspended console :P
lucs :)
arnsholt ShimmerFairy: stty stop undef # =) 12:55
ShimmerFairy heh, I learned about ^Q soon enough, and I'm used to using vim for quick edits now, so that doesn't happen anymore :) 12:56
ItayAlmog when you call `Type.new`, What is it doing in the background?
mst ShimmerFairy: ZZ
arnsholt I do that anyways, because it's super confusing when it happens
And I hit it every so often, when I want to do something like ^A 12:57
ShimmerFairy arnsholt: Konsole nowadays pops up a little warning across the top telling you what you screwed up (think Firefox's "we blocked a popup" type messages)
arnsholt I actually have my vim configured to handle ^A and ^E, since they're so ingrained from bash
ShimmerFairy mst: ZZ?
unmatched} ItayAlmog: it calls that method on Type, or Mu.new if Type doesn't implement it. And there's nothing special about that method. It just calls self.bless 12:58
lucs You type that when you go to sleep...
unmatched} s: Mu, "new", \()
SourceBaby unmatched}, Something's wrong: ␤ERR: Cannot resolve caller sourcery(Mu, Str, Capture); none of these signatures match:␤ ($thing, Str:D $method, Capture $c)␤ ($thing, Str:D $method)␤ (&code)␤ (&code, Capture $c)␤ in block <unit> at -e line 6␤␤
unmatched} ugh, of course
s: Any, "new", \()
SourceBaby unmatched}, Sauce is at github.com/rakudo/rakudo/blob/643c.../Mu.pm#L81
mst ShimmerFairy: in vi/vim, in command mode, ZZ is save+exit
unmatched} ItayAlmog: ^^ that should be the sauce for it 12:59
mst shorter than :wq<enter>
ShimmerFairy mst: oh? My "workflow" has always been i [typing stuff] ESC :wq ENTER
mst ShimmerFairy: ESC ZZ
is equivalent 13:00
nine mst: that.....will require lots of training to adopt
nine must have typed :wq<CR> a million times
ItayAlmog I am right now working on way to instantiate a class (for right now everything is on the heap to make is easier for me)
ShimmerFairy mst: I'll try to keep that in mind, if I ever get bothered by typing two extra chars to save and quit out of an editor I don't use much :P
mst ShimmerFairy: I've had people who aren't already vi addicts moan about it at length before, so I mention it to be helpful 13:01
ShimmerFairy fair enough, I could see the shifting required being an issue especially 13:02
mst I also use Ctrl-[ instead of the Esc key
less finger travel makes it a lot more comfortable
lucs mst: same here
(and ctrl-h for backspace) 13:03
ShimmerFairy ItayAlmog: if your class has public attributes, then the quickest way to do it would be with named parameters. As a tiny example: class Foo { my $.bar }; Foo.new(:bar(42))
dalek ast: 38f9743 | (Zoffix Znet)++ | packages/Test/Util.pm:
Teach is_run_repl to take a Callable to test output streams

A Regex can take you far enough, but it's cleaner to use a callable than a bunch of lookarounds when trying to test precise output without relying on user messages REPL displays on start up.
ShimmerFairy mst: I dunno, reaching for 'Esc' reminds me that I'm finally escaping vim, and that it forgot what the primary "mode" of a text editor should be :P
lucs (oops, not ctrl-h for backspace in Vim, but everywhere else)
ItayAlmog Well, For right now my compiler will not do it >:P 13:04
mst ShimmerFairy: add 'start' to the bottom of your .vimrc then
ShimmerFairy mst: hmm... is this a secret plot to make me defect from the hallowed halls of emacs? :) More seriously, I think I'm comfortable enough with the sequence I go through by now. If only I got this advice sooner... 13:06
dalek ast: a69943d | (Zoffix Znet)++ | S19-command-line/repl.t:
REPL must not re-execute previously entered code

A potential fix for RT#128973 would've led to all of previously entered code to be stored in a variable and executed over and over, for each new line of input. This test can now catch such regressions.
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128973
DrForr Or repurpose your capslock. Much shorter.
mst ShimmerFairy: not really, since tbh it's realising that starting in command mode is more powerful that's the point at which you start to properly grok vi to my mind :P 13:07
bear in mind I use ex-vi.sf.net/ out of choice
it annoys me less than anything else, and because it was designed for 1200 baud, it's the only editor I've found that still works fine over conference wireless 13:08
ShimmerFairy DrForr: yeah, I've started having occasional pain in my left pinky (which is when I'm careful and have my ring finger take over). I wish Space Cadet keyboards were still around. They looked cool and sanely designed.
mst: so command mode is a poor man's modifier keys? :P 13:09
mst or vice versa, once you're spending enough time in command mode :) 13:11
mst keeps playing with spacemacs 13:15
I really like the amount of power emacs' command system has
but modifier keys are just enraging after a while, I much prefer modal
dalek ast: 5bf61e3 | (Zoffix Znet)++ | S19-command-line/repl.t:
Update factual information in the comment
 13:16
mst (also, I want an option for a scriptable editor, and oh gods vimscript no)
ShimmerFairy there's a reason why I wish the Space Cadet keyboard was still around, emacs was built for it. In particular, Ctrl by the spacebar so the thumb uses it.
mst: elisp is probably better, but I do wish it would modernize and go with common lisp. Or Perl 6, that works too :P 13:17
ilmari mst: evil-mode? 13:27
ilmari uses emacs and always switches capslock to be an extra control 13:28
mst ilmari: spacemacs has one of the vi binding sets built in
ilmari ah
mst that's why I'm playing from there
ilmari ShimmerFairy: I think was working on porting emacs to guile, which has both elisp and scheme frontends 13:29
s/was/someone $&/
ah: www.emacswiki.org/emacs/GuileEmacs 13:30
ooh, it also has ECMAScript and WIP support for Lua
dunno about common lisp, though 13:31
ShimmerFairy ilmari: yeah, I came across that before. I hope it comes through, since then I could code in common lisp if I wish :) . (At least, IIRC)
ilmari github.com/NalaGinrut/guile-lua-rebirth # seems to be the lua frontend, and has seen recent development 13:35
ShimmerFairy
.oO(Maybe also NQPmacs, for similar multiple-language support!)
 13:36
ItayAlmog It is working! I can create a new Mu object and call the define method, which (for right now) will return 1 (defined) and you can call Mu.defined which will return 0 (undefined) :D 13:57
* It is not parsing code! I create the AST manually :\
unmatched} Nice 13:58
"> Tried to read() on a socket from outside its originating thread" 14:37
And so ends my "fix" for REPL :P
Which was this: gist.github.com/zoffixznet/2d23b81...4078f22e5a 14:48
And the message is basically from: await start get
No idea how to proceed next or how such proceedal will interact with Readline/Linenoise 14:49
( full src/core/REPL.pm with my changes, since it's easier to see than diff gist.github.com/zoffixznet/872a809...f1ba2d3adf ) 14:50
I guess this is the perfect excuse to learn about contexts and try to fix lizmat's original fix. 14:58
To the learning machine!
nine unmatched}: might be fixing the context thingy will be a lot easier 15:00
unmatched} Though that fix is kinda iffy in that we don't kill the running code, but basically put it into background. so "foo".say for ^Inf will still keep running after ^C 15:01
and spamming the screen
hoelzro unmatched}: is your REPL work in a branch? 15:31
hoelzro needs to catch up on the recent happenings in REPL-land 15:32
unmatched} unmatched}: there's no real "work" to be honest. I was just trying to do #128900 and the first attempt wasn't perfect and there was some breakage, so it was revereted: github.com/rakudo/rakudo/commit/be...0c8b42eec0 15:35
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128900
unmatched} (the diff above is all I got for my attempt) 15:36
I mean hoelzro
Dunno why I decided to talk to myself :P
jdv79 jnthn, unmatched}: thanks for the bug work 15:40
hoelzro unmatched}: ok, thanks for looking at that! 15:44
unmatched}: I saw a lot of chatter about the REPL last night/this morning (I have irssi e-mail me whenever someone mentions "REPL"); were there other issues? I thought I saw something about a release blocker? or was this it? 15:45
I would like to help more with the REPL work, but I had a side contract in July and I'm moving into a house next week, so this has been a really awful summer for Perl 6 work for me =( 15:46
unmatched} hoelzro: yeah, the revert fixed the blocker. 15:47
hoelzro ok, thank you for dealing with all that!
unmatched} It was lizmat who took care of it :)
hoelzro lizmat++
and unmatched}++ for getting involved =)
unmatched}++ a lot for lots of work and blog posts lately, for that matter
unmatched}
.oO( how crazy is it to use Proc::Async with $*EXECUTABLE to work around no-thread-killing limitation.... )
 17:35
nine Oooh...this is it! The failing S11 tests do use lib "." while other tests create short lived files like getout-13575-776701.in. Those files disappear between the .dir that lists them and the .open leading to: "Failed to open file /home/nine/rakudo/getout-13575-776701.in: no such file or directory" 17:42
ugexe nine: github.com/rakudo/rakudo/pull/837 related to your $!id PRs 17:45
nine ugexe: just saw it. Looks cool :) Have you by any chance benchmarked it? 17:48
ugexe nine: no, i'll try it tonight though. i figured nqp::sha1 would be the bottleneck no matter what, and it still gets called the same number of times 17:52
nine I have no intuition about Perl 6 performance at all. But then I wonder if anyone really has. 17:53
dalek kudo/nom: c405ccd | ugexe++ | src/core/ (3 files):
Implement Rakudo::Internals.DIR-RECURSE

Directory recursion is used in at least 2 internal locations, and this aims to consolidate that behavior		 17:55
kudo/nom: 92d5e76 | niner++ | src/core/ (3 files):
Merge pull request #837 from ugexe/internals-recursive-dir

Implement Rakudo::Internals.DIR-RECURSE
unmatched} Well. My crazy REPL method failed. 18:06
Time to dial up the insanity
unmatched} tries to make a Proc::Async-based proof of concept
Could end up being a good Perl 6 async article if I manage to succeed 18:07
nine Kinda sucks that slurp unconditionally throws exceptions on failure to open :/ 18:13
well, there's still slurp-rest 18:15
ugexe: I dislike a bit that DIR-RECURSE returns strings instead of IO::Paths. I have to .IO them again. Seems wasteful. 18:17
ugexe nine: yeah. i did strings because the other path related methods in Rakudo::Internals return strings 18:22
no other reason
unmatched} shelves the idea 18:24
nine ugexe: oh, and there's now: Too few positionals passed; expected 2 arguments but got 0 18:25
on the reduce in case we don't find any files
unmatched} Gonna put it on a very far back burner, so if anyone wants to give rt.perl.org/Ticket/Display.html?id=128900 a go, you're welcome to :)
ugexe nine: ah crap. i even remember thinking of the cleanest way to implement that check first 18:28
dalek kudo/nom: 9aef5c3 | (Zoffix Znet)++ | docs/ChangeLog:
Remove REPL ^C from Changelog

The original fix for RT#128900 ( be7ce041a80 ) was reverted ( 643c0f9 ), so the feature won't be present in this release.		 18:29
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128900
nine ugexe: I replaced the reduce by nqp::sha1([~] grep ...)
unmatched} And this is the contents of my second failed REPL attempt. This one can read across the threads, but can't start a new loop on ^C, because signal tap is in another thread, so I can't throw from it to kill the REPL thread: gist.github.com/zoffixznet/3012637...d94348dfd7 18:30
brrt hmm, oh you can 18:31
you need a bit of difficulty though
unmatched} brrt: how? 18:32
brrt okay, the second thread is waiting on the Proc::Async right?
kill the Proc::Async
unmatched} brrt: no, there's no Proc::Async involved. That was my third idea, but I kinda ran out of steam :)
brrt hmmm
okay, still kill the child process
unmatched} How? 18:33
ugexe nine: ah yeah thats probably it. a shame though, always nice to use a grep/map/reduce combo transform
unmatched} Basically, it's essentially this: start { signal(SIGINT).tap: { ... }; loop {} }
What do I put inside the signal tap to make that start {} block end; considering I can't put anything inside that loop {}
brrt you need two things 18:34
a): to communicate with loop and tell it that it should stop
or in other words, a shared (and locked) $is_running 18:35
or something like that
nine Failed to stat file: no such file or directory
This is becoming harder and harder :/
brrt a select on a 'pleaseCloseMe' and whatever else channel is equivalent
nine misses working with databases and transactions
unmatched} brrt: Yeah, I can't. That loop is representative of code entered into REPL by the user. If the user enters loop {}; that's all there is so it blocks, and I wants the signal to end that loop.
brrt b): a way to unbreak the waiting inside the loop
well, alright, what are you waiting for in the loop? 18:36
oh, right, i get it
i'm thinking of a forking shell
hmmm
well, the low level api to that, in posix, is pthread_signal or something like that 18:37
don't we expose that, i wonder
there are a bunch of things we can set to stop a thread for GC, although, you don't really want that mechanism 18:39
and, i think pthread_signal() is not the right thing (It's only for condition variables anyway) 18:40
dalek kudo/nom: e039eb9 | niner++ | src/core/CompUnit/Repository/FileSystem.pm:
Fix spectest failures caused by changing the repo during compilation

S10-packages/precompilation.t actually writes files into t/spec/packages. When this happens between nested.t precompiling A.pm and B.pm the t/spec/packages FileSystem repository's id changes. This id is included in the precomp ids. Therefor when compiling B.pm, we calculate a different precomp id for Grammar.pm leading to collision on load.
This just takes commit 22e46b56a2451bb5836ec0100244b59360f59c0c further by completely removing an obsolete mechanism.		 18:42
kudo/nom: bc0293e | niner++ | src/core/CompUnit/Repository/FileSystem.pm:
Fix spurious spectest failures caused by ephemeral files

Fix spurious "Failed to stat file" errors in massively parallel spectests
If between the call to dir() and the stat the file vanishes, we died with an
  "Failed to stat file: no such file or directory" error. Make that non-fatal
as we use the stat result for filtering anyway and files that don't exist anymore should definitely be filtered out.
nine Finally a chance to use the word ephemeral ;) 18:43
ugexe: the "Failed to stat file" error is in this line: @paths.append( dir($path, :$test) ) if Rakudo::Internals.FILETEST-D($path); 18:53
ugexe seems it might be related to the ephemeral files you mention. I guess it has to check FILETEST-E($path) && FILETEST-D($path) 18:55
nine It's tricky. The file may as well disappear between the FILETEST-E and FILETEST-D 18:56
ugexe ugh 18:57
unmatched} Doesn't -D imply -E?
Oh.. that's what you were talking about.. never mind :P 18:58
nine I wonder if I should just leave it as is. I can only reproduce those failures by runningthose S11 tests in loops while running a TEST_JOBS=12 spectest. It's hardly a real world use case.
unmatched} I get a whole bunch of failures in spectest, just running my first TEST_JOBS=30 run from HEAD 18:59
ugexe wouldnt this theoretically affect regular calls to dir() in certain situations as well then? 19:00
nine of course
unmatched} Here are the failures: gist.github.com/zoffixznet/13fbf2c...bd43e5f872
All of them are "Parse errors: No plan found in TAP output"
That's a TEST_JOBS=30 make stresstest 19:01
nine unmatched}: with bc0293ec87e13d48f0d6df9ae8461b801a2ae8b3 applied?
unmatched} Yeah 19:03
lemme nuke it and fetch it and build from scratch
nine unmatched}: TEST_JOBS=30 make stresstest completed successfully here. Running again with TEST_JOBS=100 19:07
unmatched} (FWIW, I'm doing it on a 24-core box) 19:08
nine I'd love to have that as development machine :) But with AMD's Zen approaching, I'm at least gonna upgrade to an 8 core next year. 19:09
unmatched} nine: still failures, though if I `make` files individually they seem to pass: gist.github.com/zoffixznet/2b862a3...2fbe44e36e 19:13
nine: here's the full build/test log: gist.github.com/zoffixznet/2fe90d3...1cfabbb1e3 19:14
nine unmatched}: can you please try running a "while RAKUDO_MODULE_DEBUG=1 perl6 -Ilib --ll-exception t/spec/S11-modules/require.rakudo.moar ; do true ; done" while running the spectest? 19:15
That should give us some error message to work with.
Doing the same for the other failed tests will increase chances of catching something. 19:16
unmatched} nine: "failed to stat file" (at the end of the output) gist.github.com/zoffixznet/3685af2...d8140e9232 19:19
nine: here's for t/spec/S10-packages/use-with-class.t gist.github.com/zoffixznet/0b0a758...6035eed52f 19:22
nine Ok, so it is the same issue after all 19:24
unmatched} here's t/spec/S11-modules/importing.t gist.github.com/zoffixznet/5406ce9...ad98408338
unmatched} stops; let me know if you need it for the rest of the files :)
nine Maybe like this? @paths.append( dir($path, :$test) ) if try Rakudo::Internals.FILETEST-D($path); 19:26
unmatched}: thanks! Took me a while to respond as I had to finish mopping the floor 19:27
nine With this ^^^ I cannot reproduce any failures at all anymore. 19:56
unmatched}: can you re-test please?
unmatched} Yeah, in about an hour (communiting atm) 20:02
nine ok 20:03
Btw jnthn++ # having stable spectests is just fantastic when debugging new flappers! 20:04
Though I did just get a failure in t/spec/S17-supply/wait.t
ok $waiting + 2 < now failed. However I think, that my $waiting = now; should simply be moved to before the isa-ok start { line. Otherwise the started thread may be sleeping for a while before we start counting. 20:05
Yes, reproducible. 20:09
dalek ast: 3615150 | niner++ | S17-supply/wait.t:
Fix race in S17-supply/wait.t

The started thread may have been sleeping for quite a while before we started counting the time. Could have led to occasional failures of "did we wait long enough?"		 20:12
Zoffix nine++ did stresstest with TEST_JOBS=30, 50, 100 All PASS on all runs. 21:02
Did , TEST_JOBS=1000 too and got these failures but I'm 99% certain those are timing based tests and they just failed 'cause it took forever to get through the tests with some many running at the same time: gist.github.com/zoffixznet/aa0748f...beb41fce01
s/some/so/; 21:03
Zoffix does TEST_JOBS=10000 make stresstest just for fun :P 21:08
Same failures as with 1000 jobs. Timing based tests: gist.github.com/zoffixznet/b6b556e...cbe65fef66 21:15
nine Cool! Thanks for testing ;) 21:29
lizmat . 22:33
.tell nine spectest clear! :-)
yoleaux2 lizmat: I'll pass your message to nine.
timotimo great! 22:35
dalek kudo/nom: 1b898c8 | lizmat++ | src/core/Mu.pm:
Another fix for RT #128931

Basically, make it impossible for an Int:D to mimic an Int:U.WHICH		 22:46
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128931
lizmat this was something I still hadn't committed before commuting 22:48
now, it's time for some sleep
so good night, #perl6-dev!
Zoffix night 23:29

Powered by Cro and the Raku® Programming Language.

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

Thank you!