AlexDaniel feels like reverting is a better option 02:01
lizmat Files=1232, Tests=74493, 327 wallclock secs (14.77 usr 5.23 sys + 2263.10 cusr 230.39 csys = 2513.49 CPU) 08:15
m: class A { method a(:U:) {} } # would this make sense as a short way to say "method a(::?CLASS:U:) { }" ? 08:49
camelia 5===SORRY!5=== Error while compiling <tmp>
Missing block
at <tmp>:1
------> 3class A { method a(:7⏏5U:) {} } # would this make sense as a s
lizmat afk& 08:50
psch some more poking makes it look like the problem with the EvalServer is the supervisor 10:18
as in, it just doesn't stop looping in !maybe-start-supervisor
and well, with each evalclient.pl execution we start a new GC, with its own TC and then its own supervisor, presumably 10:19
each time we run evalclient.pl we get a GeneralWorker and an AffinityWorker waiting on their respective queues, one thread stuck during throwing an UnwindException (??) and a TimerThread 10:27
the last is probably something internal-ish to jvm..?
+the
hm, or the sleep calls from the supervisor
Geth star: 35945de1d9 | (Steve Mynott)++ | 3 files
change 2017 to 2018
 11:11
Zoffix lizmat: feels a bit ambiguous to me. Would it still be ::?CLASS in role methods? Also, anywhere else you can leave off an explicit type name, the default is a Mu or an Any. Plus, one slip of a finger and you got a bug in your code (:U is ::?CLASS:U, but ::U is a type capture) 11:15
jnthn I thought that method foo:D() { } and method foo:U() { } had been propposed long ago for that
Zoffix lizmat: basically, if type can be left off on invocant, why can't it be left off elsewhere and elsewhere ::?CLASS isn't that good as default 11:19
And if you default to Any/Mu you run into potential bugs like this: 11:32
m: class Foo { multi method foo (::?CLASS:D:) { say "parent" } }; class Bar is Foo { multi method foo (Any:D:) { say "kid" } }; Bar.new.foo
camelia parent
Zoffix Also, would the ::?CLASS meaning exist for all parameters in method foo(:D, :D, &(:D:, :D)) {} 11:33
Regardless of what the haters on reddit say, IMO ::?CLASS:D is perfectly cromulent. 11:34
Zoffix &
Geth star: f1ad1d68e5 | (Steve Mynott)++ | tools/build/panda-state.p6
we don't use panda now
 11:36
AlexDaniel releasable6: next 11:45
releasable6 AlexDaniel, Next release in 1 day and ≈7 hours. Blockers: github.com/rakudo/rakudo/issues?q=...%9A%A0%22. Unknown changelog format
Geth star: eb4eefbdc4 | (Steve Mynott)++ | docs/perl6intro.pdf
new perl6intro.pdf
 11:50
stmuk odd "make bigpage" fails in the doc repo ... sure it worked last time I tried it 11:53
AlexDaniel what's the error? 11:56
stmuk gist.github.com/stmuk/c32241924e97...6313df950a 11:57
I thought those tracebacks were supposed to display the original file name as well 11:58
ah it seems to be a dependency between rakudo version and doc version ... latest does work with latest 12:18
|Tux| NICE! tux.nl/Talks/CSV6/images/test-t-d30.png 12:39
Rakudo version 2017.12-270-g90246e652 - MoarVM version 2017.12.1-36-g20a4a7976
csv-ip5xs1.088 - 1.095
csv-ip5xs-2012.280 - 12.814
csv-parser11.912 - 12.447
csv-test-xs-200.460 - 0.515
test11.125 - 11.145
test-t2.683 - 2.691
test-t --race1.129 - 1.140
test-t-2048.031 - 48.434
test-t-20 --race17.088 - 17.591
I'll do another twee when we go under 2.56, which means 100x as fast as when I started timing 12:41
tweet
timotimo i wonder what caused this performance improvement 13:20
the only change was "make range consistently a string"? 13:21
AlexDaniel that's what I always wonder as well 13:28
|Tux| it might be form earlier. yesterday I mentioned that my system was relatively busy 13:30
dogbert2 the next target has to be < 2.5
perhaps timotimo or lizmat hav some cool opts up their sleeve 13:31
AlexDaniel: btw did you se my libuv-response yesterday?
timotimo nine has been pushing some optimizations past the finish line in the last few days that will be rather good
dogbert2 yeah, they might do the trick 13:32
AlexDaniel dogbert2: yes, but? 13:33
dogbert2: you pointed to the revert that was done because the issue is not fixed in libuv
the regression rather
iirc
so we're still stuck with the old version, or am I missing something?
dogbert2 I got the opposite impression :-) could be wrong though 13:34
AlexDaniel the revert downgraded libuv
dogbert2 where's ugexe, he could clear this up 13:35
nine Those optimizations are not yet merged into master. I wait till after the imminent release.
dogbert2 .seen ugexe 13:36
yoleaux I saw ugexe 23 Nov 2017 15:02Z in #perl6: <ugexe> I’m getting tired of it
AlexDaniel dogbert2: well, it's quite easy actulaly. There's this issue github.com/libuv/libuv/issues/1625 13:37
dogbert2: and this pull request: github.com/libuv/libuv/pull/1659
last comment 9 days ago, so there's hope
dogbert2 I guess that we could wait and hope for the best 13:38
Zoffix New blog post: "Long Live Perl 5!": rakudo.party/post/Long-Live-Perl-5 14:30
masak Zoffix++ 14:35
[Coke] lizmat++ zoffix++ 14:58
tbrowder ditto! 15:03
AlexDaniel: looking at SUPERNOVA some more, two things look particularly interesting but i would need some help creating the structure it would require, and certainly approval of the direction: (1) a separate language and (2) a separate grammar (probably required by the separate language). my naive view sees the p6 scanner shifting over to the pod lingo at the start of every pod object, and the pod scanner 15:12
shifting back to the p6 scanner at the end of that pod object. the “somehow” being part of the great unknown to me.
AlexDaniel isn't it what we already do when switching between main, regex and quote slangs? 15:15
I was thinking that the whole idea is to have POD added to that
tbrowder the shifting might even be a good parallelization optimization.
AlexDaniel well, not really, but it's already there 15:16
the switching I mean
tbrowder i don’t know about the switching. do you mean like when the actions call the pod class? 15:18
AlexDaniel github.com/rakudo/rakudo/blob/mast...rammar.nqp 15:19
search for slang_grammar maybe
tbrowder whoa, the light is less dim! i see the place the slangs are defined...may be a start...should i press on in that direction? imho, ShimmerFairy’s work is a lot of progress toward what i think your goal is. 15:37
stmuk RT#132741
synopsebot RT#132741 [new]: rt.perl.org/Ticket/Display.html?id=132741 [BUILD] Broken on FreeBSD and OpenBSD
stmuk RT#132742 15:38
synopsebot RT#132742 [new]: rt.perl.org/Ticket/Display.html?id=132742 [BUILD] FreeBSD and OpenBSD Builds now dependent on gmake
Geth star: 801acfac3a | (Steve Mynott)++ | docs/CREDITS
CREDITS where its due
 16:48
jnthn stmuk: You've got me twice in there, fwiw :)
Geth star: ffad40efd9 | (Steve Mynott)++ | docs/CREDITS
dedup
 16:49
stmuk jnthn: yeah I noticed secs after pushing :)
you probably deserve two listings anyway :) 16:50
tbrowder jnthn: could ascii reading be faster if one used nqp ops inside p6? 17:39
jnthn tbrowder: Perhaps so, though having already worked some on optimizing that code path's code-gen, there's probably only so much to win that way 17:56
All: here's a short note I intend to send to TPF for inclusion with my grant extension application: gist.github.com/jnthn/812c0f4319f2...5d926d785d Feedback welcome (I've gotta go afk now, but will read backlog later). 17:57
psch humm, what's a *Worker supposed to do when the queue is empty..? 18:04
timotimo psch: you mean the workers in the ThreadPoolScheduler?
psch i mean, i'd assume a scheduler/supervisor knows to tell the workers to relax when their queues are empty?
(where "relax" probably means "quit pulling from an empty queue") 18:05
timotimo: yes, those
timotimo well, pulling from an empty queue will just let the thread wait until something comes up
psch specifically GeneralWorker and AffinityWorker, that's the two that stick around after an evalclient.pl finishes
timotimo the OS takes care to let the threads sleep
oh, right, that's interesting
psch timotimo: ah, so we should agressively kill threads in the jvm EvalServer?
timotimo because right now we just rely on the program quitting to shut those down 18:06
maybe the underlying implementation on the jvm has something cool we could use here 18:07
psch i've never really thoroughly loked at jvm (or other) thread impls 18:09
but that's the most right-ish idea i guess. reusing the GC is probably bad, and i don't have any other ideas vOv 18:10
hrm, although i did get debugging-specific weirds just now as well 18:11
but then bartolin++ confirmed it's extra threads hanging around, and suspending after running evalclient.pl also puts them in the nqp::shift($queue) call... 18:12
heh, how 'bout "append 'exit()' to incoming code for the EvalServer,' that seems like a clean and reliable solution ;p 18:14
timotimo in theory we can put a flag into the ThreadPoolScheduler a la "shutting down" and queue a special message on the queue for every thread that's still remaining so that it'll exit its loop
psch timotimo: i'm not sure this should be solved outside of the EvalServer, actually
as perl6-{m,j} just don't have the problem normally
timotimo hm, that's true 18:15
psch okay here's a radical idea: actually call gc.exit(0) on the GC that we run the eval code in... 18:20
the only problem is that i *think* Ops.invokeMain doesn't block..? 18:21
timotimo that gc doesn't mean garbage collector, does it? 18:23
psch no, it's GlobalContext
i'm not sure anymore how that translates to moar 18:24
timotimo it could correspond to MVMInstance perhaps 18:25
psch well it has things like the KnowHOW and all the BOOT* types
plus the hll config
and yeah, a lot of other things
timotimo that sounds a lot like MVMInstance 18:30
psch hehe 18:43
so, calling gc.exit doesn't mess everything up at least
and it actually exits too, apparently
but only the executing thread itself, the worker threads stick around and keep waiting on the queue
timotimo surely java has some way of throwing an exception onto another thread? 18:44
psch i don't have the threads easily available on the java side 18:45
i mean, beyond "dig through the GC to find all threads associated with it"
i still feel like i'm missing something though 18:50
i mean, i'm exiting from the GC, which is where the threads that stick around should come from right?
i.e. the two Workers that stick around should have been started by the code that i start in the GlobalContext..?
timotimo i imagine so 18:51
psch i guess this gets complicated by the whole "we start a java program that owns *all* threads" bit the EvalServer lets us do
but then those two workers should be in the same GlobalContext, which is what i'm calling exit() on anyway 18:52
timotimo i wouldn't expect a thread dieing to cause threads it itself spawned to die as well; unlike processes where a parent dieing will also tear down the child processes
tbrowder AlexDaniel: i assume preprocessing elminates pod from the code, yes?
timotimo if the globalcontext's exit function doesn't go through the other threads and stops them one-by-one i don't think it'll do terribly much 18:53
bbl
psch well it reduces the mem footprint increase per evalclient.pl call to ~80mb instead of uh 200?
which might be enough for spectesting 18:54
or it might not heh
well, not intercepting exits and calling gc.exit exits the EvalServer 19:17
this is kinda good to know because it means that the exit call on the GC was actually missing and makes sense
because otherwise why would we want to intercept an exit?
the issue of the Workers getting stuck on polling their queue might make sense to solve differently though 19:18
as in, have the GC that spawned those threads kill them even if it gets its exit intercepted
hmm, mem foot print at ~2.2g after ~40 calls of 'run "echo", 42' 20:50
plus the threads do get reaped apparently
still, something is still leaking mem, although i'm pretty sure it's better than without my current WIP 20:51
.tell bartolin i got a patch that .interrupts all threads belonging to each of the eval'd GCs, which seems to help with but not solve the mem leak 20:52
yoleaux psch: I'll pass your message to bartolin.
bartolin psch: oh, so it's not only threads. i didn't looked further since the leakage of threads seemed quite severe. however, very nice to see you working on this (and to have you around again) 21:32
yoleaux 20:52Z <psch> bartolin: i got a patch that .interrupts all threads belonging to each of the eval'd GCs, which seems to help with but not solve the mem leak
psch bartolin: i'm running spectest, although TEST_JOBS=1 seems necessary
bartolin: some ~20 files in by now with one failure in S17-supply/throttle.t
bartolin psch: cool. I changed to running spectest file by file (without evalserver) -- it takes about 5 hours on my (not too beefy) vm 21:36
psch oh, yeah, maybe timing this would've been nice... :) 21:37
bartolin psch: and yes, there are some failing test (files), which were hard to fudge. +/- a fwe flappers, my list looks like this: gist.github.com/usev6/605eaccde110...77459fab0a
*few 21:38
also, I've fudged quite some tests for the JVM that die with "UnwindException in thread ..." 21:40
psch yeah, there's definitely some other leakage, i'm at ~2.8g resident for the eval server after around 60 files now
UnwindException leaks are scary and confusing >_>
kinda like EXPR except vm specific :) 21:41
bartolin: do you have a rough number of mem increase per eval-client.pl call? 21:42
bartolin: because while i'm fairly sure my patch does reduce the memleak i'd like to have an estimate how much per
AlexDaniel tbrowder: “should i press on in that direction?” IMO yes
tbrowder: what preprocessing? I'm not sure 21:43
bartolin psch: sorry, not easily available. (and since I'm in the process of moving house, I don't have much time to look at it atm) 21:44
psch bartolin: ah, okay, no worries then :)
hmm, ~62 min TIME+ and ~4gb RES according to top 22:13
tbrowder hm, i meant precompilation... 23:11
Geth rakudo: W4anD0eR96++ created pull request #1423:
Fix duplicated parsing for ∞		 23:38
tbrowder Zoffix: ref yr sieve* p6 vs p5 comments (great demo!): nqp question: it looks like one or more var decls are inside parens but they are used later in what looks like a different scope! please enlighten me. 23:41
i thought “my ($var)” was not the same as “(my $var)”... 23:43
in the same arena, where does the “:my $var” come from or mean in rakudo nqp land? 23:52
Geth rakudo: 626991e0ff | (Alex Chen)++ | 2 files
Fix duplicated parse ∞
 23:53
rakudo: bfb5279aa5 | (Zoffix Znet)++ (committed using GitHub Web editor) | 2 files
Merge pull request #1423 from W4anD0eR96/patch-1

Fix duplicated parsing for ∞
jnthn tbrowder: It's just a way of declaring a variable inside of a regex/rule/token
I don't exactly know why : was picked 23:54
But since a plain "my" would be interpreted as literal chars to match, something is needed
geekosaur because : can already embed code iirc 23:55
tbrowder jnthn: thanks!
geekosaur but it has to be fairly simple code. so :my is just a special case
(in that it knows the next 'token' is part of it, which I think is not true of normal : unless you parenthesize/bracket the whole thing iirc?) 23:56
jnthn It's does call back into the MAIN language to do the parse, but it constrains it to :my, :our, :state, etc. 23:57
I don't think there's any other : code embedding in regexes
geekosaur hm, ok. actually I think I gleaned that from the speculations, so the reality is likely simpler
jnthn And things like :s parse as mods
(to turn on sigspace, in that case) 23:58
geekosaur unfortunately there's afair amount of regex that is still only well described in S05
jnthn I guess the :scope_decl syntax is ambiguous with the internal mod syntax, but since there's a small set of both we get away with it :) 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!