AlexDaniel .seen azawawi 01:35
yoleaux I saw azawawi 27 May 2017 12:50Z in #perl6: <azawawi> jnthn: in Graphics::PLplot im aiming on providing Raw (native) and cooked with sugar API :)
AlexDaniel test fails under prove but not when you run the file by itself
my best guess is that it is a buffering issue also, but I have troubles making sense out of it 01:36
Geth roast: skids++ created pull request #314:
adjust tests for closure of RT#131187		 01:40
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131187
Geth roast: 563f957d06 | skids++ | S02-names/is_default.t
unskip prexisting test that covers RT#131387

Fix the obvious error in the test, so maybe do 6.c.errata, too		 01:41
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131387
Geth roast: ce1a5a2e6b | skids++ | S02-names/is_default.t
Thoroughly test attributes now that they work
roast: 6271d239cd | skids++ (committed using GitHub Web editor) | S02-names/is_default.t
Merge pull request #314 from skids/rt131387

Sorry, that's RT#131387
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131387
AlexDaniel .seen pierre_ 02:40
yoleaux I saw pierre_ 7 Jul 2017 14:38Z in #perl6: <pierre_> which one should i use? (knowing that i can't install HTTP::UserAgent with zef, some tests are failing
AlexDaniel .seen pierre
yoleaux I haven't seen pierre around.
AlexDaniel three modules to go 02:49
Geth roast: skids++ created pull request #315:
Add tests for RT#131962		 03:12
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131962
Geth roast: 38faa6da57 | skids++ | S32-hash/keys_values.t
Add tests for RT#131962
roast: 8fdce37baa | skids++ (committed using GitHub Web editor) | S32-hash/keys_values.t
Merge pull request #315 from skids/rt131962

Add tests for RT#131962
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131962
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131962
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Make BUILDALLPLAN and BUILD_LEAST_DERIVED use same internal logic 04:34
travis-ci.org/rakudo/rakudo/builds/275184428 github.com/rakudo/rakudo/compare/5...06b843121b
samcv good * 05:28
AlexDaniel o/ 05:41
Skarsnik Hello 05:51
AlexDaniel \o 06:03
Skarsnik_ AlexDaniel, did you manage to read the toast data? ^^ 06:04
AlexDaniel Skarsnik_: sure. There are now three tickets like this: github.com/azawawi/perl6-ncurses/issues/16 06:07
Skarsnik_: and RT #132085 which is now closed and RT #132083
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132085
Link: rt.perl.org/rt3/Public/Bug/Display...?id=132083
AlexDaniel and that's it. 06:08
Skarsnik_ good ^^
AlexDaniel Skarsnik: thanks :) 06:09
Skarsnik 3 modules is not that much in the end ^^ 06:10
AlexDaniel the picture is much better than it was last month :) 06:12
but we had less changes this time also 06:13
Skarsnik: RT #132083 is quite interesting actually
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132083
AlexDaniel but I have to get some sleep :) 06:14
Skarsnik I have to go x)
good nigh then x)
[Tux] This is Rakudo version 2017.08-123-gc4043b068 built on MoarVM version 2017.08.1-156-g49b90b99 06:22
csv-ip5xs 1.348 - 1.391
test 9.915 - 10.123
test-t 3.542 - 3.669
csv-parser 11.447 - 11.494
lizmat Files=1223, Tests=67782, 289 wallclock secs (11.02 usr 4.75 sys + 1950.09 cusr 205.81 csys = 2171.67 CPU) 07:45
m: dd (1,2,3).Set.any # one could argue that should be (1,2,3).any 08:11
camelia any(1 => Bool::True, 3 => Bool::True, 2 => Bool::True)
lizmat opinions? if so, what about Bag.any and Mix.any ?
nine I've never really liked that our sets are really just hashes and that we make that so obvious. 08:28
jnthn I think .any working by consistently .list-ifying the thing is probably right 09:08
Geth rakudo/better-sched: 340d8ed3bb | (Jonathan Worthington)++ | src/core/ThreadPoolScheduler.pm
Respect max_threads

To a degree, anyway. We will always start one timer, general, and affinity thread if they're needed even if it takes us over the maximum number of threads.		 09:52
rakudo/better-sched: c50d35a90e | (Jonathan Worthington)++ | src/core/ThreadPoolScheduler.pm
Add extra timer workers as needed
jnthn Now my benchmark doesn't start 250 threads and uses 2.3 GB of RAM :P 09:58
*and use
Now it hits the default limit of 64
Benchmark is await start { (eager (^10000).grep(*.is-prime)).elems } xx 500; 09:59
Essentially, CPU-bound work
Where we don't really benefit from more threads than CPU cores
So next is to try and look at rusage and be smarter on that
What's interesting, though, is that the time difference between the two is only 2s (2:17 vs 2:19) 10:00
That is, these days it seems MoarVM copes pretty well with juggling a lot more threads than should sensibly be started, if it's gotta 10:01
Probably thanks for my re-write of GC orchestration over the summer
*thanks to
Geth nqp: a3b1e9cfb9 | (Jonathan Worthington)++ | tools/build/MOAR_REVISION
Bump for new MoarVM getrusage op
 10:48
nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...9b90b99... No newline at end of file
2d9ec57ab7 | (Jonathan Worthington)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Ā¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...9b90b99... No newline at end of file
jnthn Well, there's getrusage, for whatever purposes people wish to put it to :) 10:49
lunch & 11:17
stmuk I'm seeing t/spec/S03-operators/buf.t fail on Rakudo version 2017.08-123-gc4043b0 built on MoarVM version 2017.08.1-158-g3c3a52f on linux 12:04
MasterDuke consistently? even when run by itself? it's fine for me at same rakudo and nearly the same moar 12:09
stmuk no and I'm running on its own in a loop and it seems ok :/ 12:13
jnthn back 12:14
MasterDuke jnthn: did you happen to see gist.github.com/MasterDuke17/7926d...0621e59b03 ? top 30 by exclusive_time for a profile-compile of --target=parse at 2017-2-3 and 2017-9-10 12:17
very different results, but roughly the same total time to compile
all the profiles i did up to and including 2017-2-3 had pretty similar results, then i didn't do any for a while, and now it's quite different 12:21
maybe i should go back and do one at each release inbetween
stmuk hmm I only saw the buf.t failure once 12:23
with TEST_JOBS=6
MasterDuke there are a couple that flop during a full spectest, but never fail when run by themselves 12:25
lizmat m: class A { has $.a is required = 42 }; dd A.new # wonder this should be a compile-time error 12:34
camelia The attribute '$!a' is required, but you did not provide a value for it.
in block <unit> at <tmp> line 1
lizmat m: class A { has $!a is required }; dd A.new # how can we ever set the private attribute during object creation? 12:35
camelia The attribute '$!a' is required, but you did not provide a value for it.
in block <unit> at <tmp> line 1
jnthn m: class A { has $!a is required; submethod BUILD() { $!a = 42 } }; dd A.new 12:37
camelia A.new
lizmat aaahhh :-)
jnthn I can imagine having some less trivial BUILD logic that conditionally sets stuff and finding `is required` a useful sanity check
(Like, something should be set on all paths, then we make a thinko) 12:38
lizmat and the "class A { has $.a is required = 42 }" case ?
jnthn That's a useless use of is required, I think :) 12:39
lizmat should it be a compile time error ?
at BUILDPLAN creation time ?
or a warning: "useless use of "is required" when a default is provided" ? 12:40
jnthn More like at attribute composition time.
It could feasibly be
Error feels a tad harsh
lizmat ah, yes, add a worry at that time?
jnthn Not worth breaking existing code that does this over
Yeah, something like that
[SCHEDULER] Per-core utilization: 148.333333 12:41
wat :)
stmuk hmm the sha1 hashes in the perl6 -v are longer in newer versions of git 12:44
perlpilot stmuk: maybe they adopted a different algorithm by default than SHA1 12:46
samcv stmuk, does `git describe` work? in nqp or rakudo repo 12:48
what about `git describe --tags` though they probably give the same 12:49
i have 2.14.1 what version do you have stmuk 12:50
also i'm going to bed, will read backlog in the morning
stmuk I'm using git version 2.7.4 which reports 2017.08-123-gc4043b0 and git version 2.13.2 which reports 2017.08-123-gc4043b068 12:52
perlpilot According to the docs, "core.abbrev - Set the length object names are abbreviated to. If unspecified or set to "auto", an appropriate value is computed based on the approximate number of packed objects in your repository" So, perhaps they changed the algorithm to figure out the minimum number of characters 12:56
(assuming you haven't actually set core.abbrev anywhere or didn't specify ala `git rev-parse --short=9 ...` 12:57
)
stmuk github.com/git/git/commit/e6c587c7...b08bc86892 13:04
jnthn Cool, got it starting up to the number of CPU cores we have threads for that benchmark I posted earlier 13:24
Which again greatly reduces memory use
Results in a time reduction too thanks to not over-subscribing the CPU.
Drops from 3.28 system to 0.36 system 13:25
Probably from not having the overheads of dealing with too many threads
Geth rakudo/better-sched: 683037be69 | (Jonathan Worthington)++ | src/core/ThreadPoolScheduler.pm
Start factoring CPU cores and usage into scheduler

So that it can pick a better number of threads for the workoad. Now it only boosts threads beyond the number of CPU cores if detects very low resource usage in combination with a queue of work, which is suggestive of a deadlock that may be resolved by an extra thread.		 13:29
rakudo/better-sched: 89b9ac7830 | (Jonathan Worthington)++ | src/core/ThreadPoolScheduler.pm
Correct typos; MasterDuke17++
 13:31
lizmat jnthn: with my BUILDPLAN work I'm now getting: Serialization Error: missing static code ref for closure '' (gen/moar/Metamodel.nqp:1455) 13:50
this seems to be related to me just wanting to put a block into the buildplan 13:51
@plan[@plan - 1][4] := -> $obj, $attr { ... }
jnthn Yeah, you can't do that
lizmat that's a "can't",. period ? :-(
or is there a way around that ?
jnthn I think that sub ($obj, $attr) { ... } may work out 13:52
lizmat tries
jnthn point blocks in NQP aren't really code objects
One of the many places it cheats :)
lizmat hehe... ok 13:53
jnthn Hurrah for trying real-world things against the scheduler
(found 2 bugs so far that stresstest didn't tickle) 13:57
lizmat that also happened with the old scheduler? or brand new bugs ? 13:59
jnthn New bugs in the new scheduler
lizmat squash them hard! :-)
jnthn Yeah, that's the aim :) 14:00
lizmat Cannot find method 'throw' on object of type NQPMu 14:13
sigh :-(
Geth rakudo/better-sched: 7c18112c59 | (Jonathan Worthington)++ | src/core/ThreadPoolScheduler.pm
Never hand back queue in Scalar
 14:16
rakudo/better-sched: c285b489c6 | (Jonathan Worthington)++ | src/core/ThreadPoolScheduler.pm
Consistently use binding on $!affinity-workers
rakudo/better-sched: 7fcab1067d | (Jonathan Worthington)++ | src/core/ThreadPoolScheduler.pm
More typo fixes; MasterDuke17++
jnthn Hm, getting a few uninit warnings now when I stress Cro (which is how I found the above issues) 14:17
Wonder if they're from the new scheduler too 14:18
Yes. 14:22
lizmat jnthn: my idea is to replace the "is required" handling by making it a default value that throws 14:23
jnthn hm, interesting :)
lizmat basically: has $.a = X::Attribute::Required.new(...).throw
jnthn Can't think of an obvious downside ot that
lizmat well, the downside is that I can't get it to work 14:24
:-(
jnthn ;)
diff?
lizmat well, the complete diff is rather large 14:25
this is the bit where I try to set the block:
@plan[@plan - 1][4] := sub ($obj, $attr) {
X::Attribute::Required.new(
name => $attr.name,
why => $attr.required
).throw
};
as the default value block is called as a method on the object, with the Attribute object as the parameter 14:26
Geth rakudo/better-sched: b5605c2dd6 | (Jonathan Worthington)++ | src/core/ThreadPoolScheduler.pm
Fix affinity worker threshold logic

Gets rid of a warning it very rightly produced, which showed up the problem		 14:27
jnthn Isn't that NQP code?
lizmat yes
jnthn X::Attribute::Required doesn't exist yet
The build plan is put together in the MOP 14:28
The MOP is built before CORE.setting
That and the namespces of the two langs don't overlap, doubly so given Perl 6 resolves things lexically too
lizmat ok, I just had a bit of a epiphany
jnthn Did you take a look at whether you can do it in Attribute.compose?
lizmat you mean, the warning for has $.a is required = 42? 14:29
jnthn No, adding the default that throws
Though I guess that makes introspection of defaults show it up, which is arguably naughty
lizmat yeah... :-(
but, i could call it something else :-) 14:30
ok, that's a thought :)
jnthn m: class A { has $.x is required; has $.y = 42; submethod TWEAK() { say $!y } }
camelia ( no output )
jnthn m: class A { has $.x is required; has $.y = 42; submethod TWEAK() { say $!y } }; A.new
camelia The attribute '$!x' is required, but you did not provide a value for it.
in block <unit> at <tmp> line 1
jnthn m: class A { has $.x is required; has $.y = 42; submethod TWEAK() { $!x = 100; say $!y } }; A.new
camelia The attribute '$!x' is required, but you did not provide a value for it.
in block <unit> at <tmp> line 1
lizmat would you consider that a bug?
jnthn (Just checking TWEAK is too late)
lizmat that last one ?
jnthn Well, your optimization idea is predicated on it not being :-) 14:31
I'd never really considered it, tbh
Cool, now a Cro service that gets just one request at a time starts just a couple of pool threads, and one hammered with 100 concurrent requests maxes out at 7 threads on my 12-core box, presumably 'cus it feels adding more won't help much (will do some tuning though to see if it's really chosing well) 14:42
*choosing
Bad news is I seem to have got a new SEGV 14:43
Hm, which seems to be nothing to do with my changes, looking at the stack trace 14:45
And may also be the async socket server crash that gfldex reported
d'oh 14:47
MoarVM HEAD sorts it out 14:51
gfldex: ^^
Geth rakudo/better-sched: de311f46a9 | (Jonathan Worthington)++ | src/core/ThreadPoolScheduler.pm
Add RAKUDO_SCHEDULER_DEBUG_STATUS env var

Which turns on output of regular status info, at the moment just the calculated per-core utilization. This makes RAKUDO_SCHEDULER_DEBUG just contain information about what kinds of new threads have been created, which got hard to find among all the regular output made with each supervision.		 14:57
Skarsnik . 15:04
Geth rakudo/better-sched: 3b98fb9e39 | (Jonathan Worthington)++ | src/core/ThreadPoolScheduler.pm
Supervising 100 times a second is likely enough
 15:06
jnthn Alright, I think that gets the scheduler into better shape :) 15:12
Of course one can measure and tweak these things almost endlessly
But it seems to result in a lot less threads (and thus memory) for things that just do the odd light bit of async (like run does behind the scenes, or a web app barely under load), converges on the number of available cores for CPU bound things, and can add up to 64 threads by default now (though will be reluctant to go far beyond the CPU core count unless it looks like there's a deadlock due to insufficient threads) 15:16
nine Sounds like a huge improvement :) 15:17
jnthn Nicer for those of you with AMD 32-core chips too ;) 15:18
Skarsnik ^^
nine \o/ 15:19
Skarsnik The news Ryzen 7 cpu are tempting x)
not sure they do 32 cores yet for regular people x)
nine Well 16 cores and 32 threads: www.amd.com/en/products/cpu/amd-ry...pper-1950x 15:20
Skarsnik Only 1200ā‚¬ 15:21
cheap
jnthn Yeah, when I said core I meant "virtual cores", or what your OS things it has to scheduler threads on :) 15:22
*thinks
Anyways, will merge this after the weekend release; it's just too close now for such a key component to be replaced
Oh, also I need to probably make it work on JVM too :S
And knowing JVM, there won't be a getrusage :P 15:23
Skarsnik the jvm has nothing for this kind of work? 15:24
jnthn I'd assume it does
Though I don't know what
And my initial search for getrusage equivalent in java doesn't show much up 15:25
Skarsnik I mean to schedule thread so you don't have write a thread scheduler for it?
jnthn Except that somebody called it through nja
*jna
Yeah, but the scheduler is a Perl 6 level thing
ilmari docs.oracle.com/javase/8/docs/jre/...sCpuTime-- ? 15:28
jnthn Think that's what stackoverflow.com/questions/366474...pplication is talking about also 15:29
Yeah, that'd be good enough I think
Thanks
[Coke] jnthn++! 15:51
Geth nqp: 38aa9ce23f | (Jonathan Worthington)++ | 2 files
A very cheating getrusage for JVM

In that it only fills out UTIME_SEC and UTIME_MSEC, which mercifully
  are both one of the few things that seems easy to emulate on the JVM
and also the only ones we really need for Rakudo.		 15:56
ugexe is there a better way to hide output from a Proc::Async than .stdout.tap: {} ? 16:05
jnthn No 16:06
Well, actually yes
.stdout(:bin).tap: {} will save decoding data only to throw it away 16:07
ugexe ah right
jnthn But in terms of shorter, no
ugexe yeah didnt mean shorter... just avoiding overhead
jnthn Ah, then yeah, that'll save a good amount of it
May also be possible, though not so portable, to .bind-stdout(INIT open("/dev/null", :w)) 16:08
Which I suspect would be cheapest 16:09
[Coke] wonder if we'd like a .stdout(:null)
jnthn An .ignore-stdout would be more consistent with the current API 16:10
ugexe i was ideally trying to open less file handles, since there is still an issue with exhausting file handles with something like `while 1 { with Proc::Async.new(:w, ...) { .tap.stdout: {}; .kill } }` 16:11
ilmari $*SPEC.devnull is the portable spelling of "/dev/null" 16:12
Geth rakudo/better-sched: 596611c8fd | (Jonathan Worthington)++ | src/core/ThreadPoolScheduler.pm
Fix non-MoarVM build with new scheduler

Dropping the atomics gives slightly less accurate data, but should not cause any bad behaviors.		 16:14
ugexe my @procs; my @promises; for ^1000 { .say; if @procs { @procs[*-1].kill; }; my $proc = Proc::Async.new("sleep", "20"); $proc.stdout.tap(-> $ {}); @promises.push: $proc.start; @procs.push: $proc; }; await @promises; # the code example from rt that exhaust descriptors
jnthn Hm, doesn't @procs keeps all of the procs, so GC can never collect them? 16:17
ilmari
.oO( java.util.concurrent.atomic.AtomicInteger? )
jnthn ilmari: The problem isn't that we can't do them on JVM, just that I don't have time for that yak shave right now :)
ilmari jnthn: fair enough 16:18
Geth nqp: 43a18f5aa6 | (Jonathan Worthington)++ | src/vm/jvm/runtime/org/perl6/nqp/sixmodel/reprs/ConcBlockingQueueInstance.java
Support elems on ConcBlockingQueue

Which is needed by the new Rakudo scheduler		 16:21
jnthn Alright, that gets the JVM happier with my better-sched branch 16:22
ugexe jnthn: a similar issue (also by hoelzro) shows a different example, titled "Garbage collected running Proc::Async objects dont seem to clean up their handles" 16:23
if @procs.pop -> $p { $p.kill } didn't change anything for me though
jnthn Hm, then looks like there perhaps is a leak somewher 16:24
*somewhere
ugexe i was hunting for it yesterday. no luck yet though
jnthn wonders where
The handle is closed here: github.com/MoarVM/MoarVM/blob/mast...ops.c#L589 16:26
I'm curious if the stdout supply gets the done signal
ugexe i know it get the quit signal
jnthn Oh, on kill? 16:27
Or on running out of handles?
github.com/MoarVM/MoarVM/blob/mast...ops.c#L607 shows a close on the quit path too
I'd maybe throw printf or so in around those if you want to debug, to check if either of those closes are reached 16:28
ugexe if i do quit => -> $ { } it will run through all 1000 iterations and then give the message for running out of handles
jnthn Ah, ok
I don't knowt hat'd be on the path we're looking at
I'd see if done gets send though
ugexe it fired ~22 times out of the 130 (where it gives the handle exhaustion error) 16:29
done fired^
this is with a ulimit of 150 as in the RT btw 16:31
jnthn huh, that's stranger still 16:33
Why would be only sometimes get the EOF...
ugexe i thought it just started queuing more processes up towards the end before they were getting started 16:34
jnthn Oh 16:35
That's possible
In that case, there's not a lot we can do
That'd imply we're not leaking handles, just having enough processes active at once that we really do run out
ugexe so its a race against nqp::procasynckill (or whatever its called)? 16:37
jnthn I guess it's also possible there's an isuse there 16:38
Can we ever fail to kill because the process wasn't started yet, etc.
ugexe i was just wondering how i didn't get an exception for that
jnthn It happens async and it seems there's no way to block on knowing the signal was sent: github.com/MoarVM/MoarVM/blob/mast...ops.c#L882 16:39
Just checked that there's no way to race between kill and the setting of ->handle on startup 16:41
(There isn't)
So we always have a process handle at that point
Time to head home; bbl 16:42
Zoffix m: role Foo { multi method x { "role" } }; class :: does Foo { multi method x { "class" } }.new.x.say 17:50
camelia class
Zoffix m: role Foo { multi method x(:$x) { "role" } }; class :: does Foo { multi method x { "class" } }.new.x.say
camelia role
Zoffix Kinda thought the result would be the same for both, due to implicit *%_
timo might be caused by the tighter invocant constraint? 17:56
role Foo { multi method x(:$x) { "role" } }; class :: does Foo { multi method x { "class" } }.new.^find_method('x')[0].candidates.perl.say 17:57
m: role Foo { multi method x(:$x) { "role" } }; class :: does Foo { multi method x { "class" } }.new.^find_method('x')[0].candidates.perl.say
camelia (method x (<anon|80616960> $: *%_) { #`(Method|81835040) ... }, method x (<anon|80616960> $: :$x, *%_) { #`(Method|81839448) ... })
timo oh, hm.
sorry, i missed the signature in the role
but named args only contribute to multi candidate finding as last-resolt tiebreakers? 17:58
Zoffix Yeah 18:00
Also found this glitch; dunno if it's in any way related
m: role Foo { multi method x(:$x) { "role" } }; class :: does Foo { multi method x(:$) { "class" } }.new.x.say
camelia 5===SORRY!5=== Error while compiling <tmp>
Found named parameter '(unnamed)' twice in signature :(<anon|71941360> $: $, *%_): *%_ vs $
at <tmp>:1
Zoffix Pretty much any other combination of args (or not mixing a role) avoids that error
Filed it as rt.perl.org/Ticket/Display.html?id=132089 18:02
Oh 18:03
s/Ok//;
.ask jnthn Is this is a bug? I expected it to say "class" because methods have implicit *%_ and also named args are used only for tie breaking and there's no tie here as far as I undertstand: m: role Foo { multi method x(:$x) { "role" } }; class :: does Foo { multi method x { "class" } }.new.x.say 18:05
yoleaux Zoffix: I'll pass your message to jnthn.
Skarsnik m: say num.^nativesize 18:06
camelia No such method 'gist' for invocant of type 'NQPMu'. Did you mean 'isa'?
in block <unit> at <tmp> line 1
Skarsnik Should MQPMu never be returned to the user?
lizmat Skarsnik: no, that's internals leaking out 18:10
Skarsnik rakudobugable, I am lazy repport this bug xD 18:13
buggable,
buggable, mail 18:14
geekosaur huggable, rakudobug 18:23
huggable geekosaur, Report bugs by emailing to [email@hidden.address] See also: github.com/rakudo/rakudo/wiki/rt-introduction
gfldex jnthn: did the moar changed hit Rakudo HEAD yet?
Geth rakudo/nom: b7ab48ee15 | (Elizabeth Mattijsen)++ | src/core/Attribute.pm
Attribute.required can be anything, not just int
 18:25
rakudo/nom: edac1d6870 | (Cuong Manh Le)++ | src/core/Exception.pm
Supress line number if throw X::Package::Stubbed
 18:39
rakudo/nom: 29691b2f83 | (Cuong Manh Le)++ | 2 files
Merge branch 'nom' of github.com/rakudo/rakudo into nom
rakudo/nom: fe719405b1 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Exception.pm
Merge pull request #1154 from Gnouc/nom

Supress line number if throw X::Package::Stubbed
rakudo/nom: dea0a08545 | (Elizabeth Mattijsen)++ | 2 files
Streamline BUILDPLAN a little more

  - settable attributes with default are now handled in a single task
   - this saves one list with 3 entries per attribute
   - also has a small runtime benefit (in the order 2%)
   - also handles the task *without* default
  - is required check task now emitted after each settable task without default
... (6 more lines)		 18:42
gfldex jnthn: my stresstest doesnt work at all anymore. Did buffering in Async::Proc change? 18:45
ugexe i think so 18:46
at least the amount it reads at a time was optimized (in addition to the regular stdout buffering stuff from a week+(?) ago) 18:47
Geth nqp/profiler_extra_options: c6188dc862 | (Timo Paulssen)++ | src/vm/moar/HLL/Backend.nqp
allow passing options to profiler

like --profile=heap:filter=majoronly
nqp/profiler_extra_options: 57516cc76c | (Timo Paulssen)++ | src/vm/moar/HLL/Backend.nqp
allow passing options to profiler

like --profile=heap:filter=majoronly		 18:48
timo (rebased it on top of latest master) 18:49
gfldex writing very short string via Async.put seam to block now 18:52
lizmat that feels like a release blocker to me
Geth rakudo/nom: 7ba9b7cd6f | (Zoffix Znet)++ | src/core/Exception.pm
Shorten signature of a method

The actual params aren't used and aren't needed, but we still need a bit of params to make the method more specific than the one from the role.
  See also:
  github.com/rakudo/rakudo/pull/1154
  irclog.perlgeek.de/perl6-dev/2017-...i_15164490		 18:54
Zoffix does bumps
gfldex bidirectional Async::Proc seams to be broken (still golfing) 18:55
unidirectional is a lot faster now and there seams to be a new memory leak 18:58
timo did you already see how using Proc::Async causes the ThreadPoolScheduler to fill up its maximum threads rather quickly? 19:00
i think i was discussing this with Skarsnik but i'm not sure if you saw 19:01
Zoffix hm 19:02
lizmat: does this pass for you? t/fudgeandrun t/spec/S02-types/int-uint.t
timo hmm, stage parse 120s, what did i break to cause this ...
Zoffix Fails for me and I wonder if it's the nqp/MoarVM bump or the couple of commits I pulled before doing the bumping 19:03
lizmat Zoffix: yes
Zoffix OK. Tis the bump then
nine timo: debug build?
Zoffix ZOFFLOP: t/spec/S11-modules/nested.t
ZOFFLOP: t/spec/S17-supply/interval.t
timo i do have -O3 in my moarvm
in the makefile
Zoffix ZOFVM: Files=1273, Tests=144748, 138 wallclock secs (15.55 usr 2.49 sys + 2799.30 cusr 215.27 csys = 3032.61 CPU) 19:04
timo haha
i changed the nursery size to be a lot smaller
Zoffix Output of failures in t/spec/S02-types/int-uint.t gist.github.com/zoffixznet/22f483f...834772fc0d
That's on master MoarVM and master nqp 19:05
Geth nqp/profiler_extra_options: 84e2f1caf8 | (Timo Paulssen)++ | src/vm/moar/HLL/Backend.nqp
remove debug output
Zoffix And well, the commits from them. 'cause I just ran stresstest before pushing dea0a08545 and it was green
m: use Test; class Overlap is repr("CUnion") { has uint32 $.u32; has uint16 $.u16; has uint8 $.u8; }; my $overlap = Overlap.new(u32 => 1234567); is $overlap.u32, 1234567, "uint32 in union is unsigned"; 19:07
camelia not ok 1 - uint32 in union is unsigned
# Failed test 'uint32 in union is unsigned'
# at <tmp> line 1
# expected: '1234567'
# got: '1179648'
Zoffix c: 2017.08 use Test; class Overlap is repr("CUnion") { has uint32 $.u32; has uint16 $.u16; has uint8 $.u8; }; my $overlap = Overlap.new(u32 => 1234567); is $overlap.u32, 1234567, "uint32 in union is unsigned"; 19:08
committable6 Zoffix, Ā¦2017.08: Ā«ok 1 - uint32 in union is unsignedĀ»
Zoffix bisect: use Test; class Overlap is repr("CUnion") { has uint32 $.u32; has uint16 $.u16; has uint8 $.u8; }; my $overlap = Overlap.new(u32 => 1234567); is $overlap.u32, 1234567, "uint32 in union is unsigned";
bisectable6 Zoffix, Bisecting by exit code (old=2015.12 new=7ba9b7c). Old exit code: 0
Zoffix, bisect log: gist.github.com/5592b70c7afa73e0f1...3f88889139
Zoffix, (2017-09-14) github.com/rakudo/rakudo/commit/de...9734798a35
Zoffix complicated stuff :)
Well, I guess it's not from the bump, so I'll push it 19:09
Geth nqp: 9a2ba37548 | (Zoffix Znet)++ | tools/build/MOAR_REVISION
Bump MoarVM
Ā¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...2-g4a7248e
rakudo/nom: 06e20f80c9 | (Zoffix Znet)++ | tools/build/NQP_REVISION
Bump NQP
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....5cdbdd3... No newline at end of file
a8e0352b03 | (Elizabeth Mattijsen)++ | src/core/Mu.pm

  - move the check out of the parameter to bindattr_x
   - this causes one Scalar allocation less for each initialization
Zoffix m: use Test; class O is repr("CUnion") { has uint32 $.u32; has uint16 $.u16; }; my $o = O.new: u32 => 1234567; is $o.u32, 1234567; 19:12
camelia not ok 1 -
# Failed test at <tmp> line 1
# expected: '1234567'
# got: '1179648'
Zoffix Slightly golfed. 19:13
gfldex jnthn: run-this.sh shows the blocking Proc::Async, run-unidirectional.sh shows the memory leak github.com/gfldex/perl6-stress-moar
Zoffix Oh, lizmat++ already mentioned this failing test in the commit message 19:14
lizmat: ^ does my last eval fail for you? Seems to fail on Linux
lizmat ok 1 - 19:15
AlexDaniel by the way 19:16
RT #132083 may be related
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132083
lizmat AlexDaniel: the fails started to appear after *my* last BUILDPLAN related commit 19:17
AlexDaniel ah, right, that's another one I guess
Zoffix FWIW the other two tests for that test that test $.u16 and $.u8 are fudged. It's possible the passing test was passing by accident
Zoffix & 19:18
timo neat. 19:27
lizmat nine: is Inline::Perl5 still using the BUILDALL(@a,%h) interface ? 20:01
jnthn gfldex: Looks like the bump was done since you asked, so yeah, the socket fix should be in 20:04
yoleaux 18:05Z <Zoffix> jnthn: Is this is a bug? I expected it to say "class" because methods have implicit *%_ and also named args are used only for tie breaking and there's no tie here as far as I undertstand: m: role Foo { multi method x(:$x) { "role" } }; class :: does Foo { multi method x { "class" } }.new.x.say
jnthn Nothing has changed with regard to Proc::Async and buffering
What changed is buffering of $*OUT and $*ERR when they're attached to a non-TTY. Proc::Async attaches pipes, and thus the buffering is enabled. 20:06
This only brings Perl 6 in line with other languages. 20:08
For example, try perl6 -e 'react { my $p = Proc::Async.new("perl", "-E", q/while (1) { say "x" x 1000; sleep 1; }/); whenever $p.stdout { .perl.say }; $p.start }' 20:09
lizmat m: class A { has $! = 42 }; use nqp; dd nqp::getattr(A.new,A,q/$!/) # this should probably be a compile time error 20:32
camelia P6opaque: no such attribute '$!' in type A when trying to get a value
in block <unit> at <tmp> line 1
lizmat m: class A { has $! = 42 }; use nqp; dd nqp::getattr(A.new,A,q/$!!/) 20:33
camelia Int $!! = 42
lizmat whee!
jnthn lol!
That's beautiful
lizmat well, I think it needs to die :-) 20:34
jnthn m: class A { has $/ = 42 }; use nqp; dd nqp::getattr(A.new,A,q|$!/|)
camelia Int $!/ = 42
jnthn hahahaha
lizmat cause it interferes with some more nefarious opts I'm planning
jnthn For anyone wondering: $/ and $! are allowed variable names. has $foo is an allowed attribute name, the compiler names the attribute $!foo and installs a lexical alias 20:35
lizmat m: class A { has $. = 42 } # planning on this type of error
camelia 5===SORRY!5=== Error while compiling <tmp>
Unsupported use of $. variable; in Perl 6 please use the .kv method on e.g. .lines
at <tmp>:1
------> 3class A { has $.7ā5 = 42 } # planning on this type of erro
jnthn has $! doesn't parse as a twigil 'cus that has to have a name after it 20:36
It just parses as $! like in my $!
The compiler faithfully installs the attribute as $!! and a lexical alias from $! to it
Which of course is shadowed in all the methods by the real $! :)
Declared per method 20:37
jnthn wrote most of the code that does all of this, and totally didn't see this interaction coming
I'm kinda proud it's robust enough that it all just works out, but kinda horrified it is allowed too ;) 20:38
lizmat m: sub a(:$) { dd MY::.keys }; a |("" => 42) # another weirdo 21:08
camelia ("\$_", "\$/", "\$*DISPATCHER", "\$!", "\$Ā¢").Seq
jnthn That one's even covered by tests, I think :P 21:11
The has $! and has $/ sure ain't though, and those truely do seem about useless 21:12
lizmat but what is the use? You can pass a values as a non-named parameter, but you can't really do anything with it inside the sub ? 21:15
jnthn True, but if you slurp... :) 21:20
jnthn bbl 21:26
lizmat is too tired and goes to bed 21:31
Zoffix \o
[Coke] lizmat: when I wrote is required, it was just a bitflag; what else can it be? 21:35
(I think that was me)
[Coke] waves good night. 21:38
Geth rakudo: book++ created pull request #1156:
Implement pred() and succ() for the Enumeration role		 22:53
roast: skids++ created pull request #316:
Add tests for RT#126426 and RT#129856		 22:56
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=126426
Link: rt.perl.org/rt3/Public/Bug/Display...?id=129856
Geth roast: 69a5e0db0f | skids++ | 2 files
Add tests for RT#126426 and RT#129856
 22:57
roast: 6e5180e96c | skids++ (committed using GitHub Web editor) | 2 files
Merge pull request #316 from skids/rt126426

Add tests for RT#126426 and RT#129856
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=126426
Link: rt.perl.org/rt3/Public/Bug/Display...?id=129856
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=126426
Link: rt.perl.org/rt3/Public/Bug/Display...?id=129856
Zoffix comment on the earlier uint failure: "That test doesn't make sense to me. 1234567 is much less than 2**31 so how would it be testing for unsigned? And yet it gets the wrong answer, so what's the real bug?" 23:16
So it's more evidence that it was passing accidentally
and should be just fudged
"more" <-- because the other piece of evidence is that u16 and u8 in that test currently don't work and are already fudged 23:18
Geth rakudo/nom: 2645a1e97c | (Philippe Bruhat (BooK))++ | src/core/Enumeration.pm
Implement pred() and succ() for the Enumeration role

These method will walk the enumeration in the declaration order.
Using Order as an example:
  - Order::Same.succ is Order::More,
  - Order::Same.pred is Order::Less.
Calling pred or succ on the boundaries will fail with X::OutOfBound. Using the same example, Order::Less.pred fails with this X::OutOfRange:
  "Decrement out of range. Is: Less, should be in Order::Less^..Order::More".		 23:41
rakudo/nom: 8df53f34dd | (Philippe Bruhat (BooK))++ | src/core/Enumeration.pm
Remove Failure from Enumeration's pred and succ

Following this comment from Zoffix on #perl6:
   If we make .pred go to previous element (and just return the first
   element if it's already at the first element) and .succ go to next
   element (and just return the first element if it's already at the
... (5 more lines)
rakudo/nom: 627de78337 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Enumeration.pm
Merge pull request #1156 from book/book/enum-pred-succ

Implement pred() and succ() for the Enumeration role
BenGoldberg So I've got an idea for how to speed up perl6 startup, but I want to first make certain I fully understand how it works at present... 23:57
If I understand correctly, during compilation, we generate the setting programmatically, compile the setting, load the compiled setting, and finally serialize the loaded setting. 23:58

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!