Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2017-02-02

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:15 pyrimidine joined #perl6-dev
01:13 pyrimidine joined #perl6-dev
01:46 geekosaur joined #perl6-dev
02:21 Geth ¦ rakudo/nom: ab3162c127 | (Zoffix Znet)++ | src/core/Numeric.pm
02:21 Geth ¦ rakudo/nom: Fix infix:<before>/infix:<after> for Complex
02:21 Geth ¦ rakudo/nom:
02:21 Geth ¦ rakudo/nom: Currently before/after uses `cmp` that's pretty liberal with allowed types,
02:21 Geth ¦ rakudo/nom: which makes comparisons like `i after 42` "work". Per TimToady++[^1], these
02:21 Geth ¦ rakudo/nom: should use infix:«<=>», which this patch makes it do.
02:21 Geth ¦ rakudo/nom:
02:21 Geth ¦ rakudo/nom: However, one side effect of this is that <42+42i> after <41+42i> used to work,
02:21 Geth ¦ rakudo/nom: <…commit message has 5 more lines…>
02:21 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ab3162c127
02:22 Geth ¦ roast: af93bfd4c0 | (Zoffix Znet)++ | S03-operators/relational.t
02:22 Geth ¦ roast: Test `before`/`after` with Real/Complex
02:22 Geth ¦ roast:
02:22 Geth ¦ roast: Accompanies commit https://github.com/rakudo/rakudo/commit/ab3162c127
02:22 Geth ¦ roast: review: https://github.com/perl6/roast/commit/af93bfd4c0
02:36 Geth ¦ rakudo/nom: 6c92994729 | (Zoffix Znet)++ | src/core/Numeric.pm
02:36 Geth ¦ rakudo/nom: Revert "Fix infix:<before>/infix:<after> for Complex"
02:36 Geth ¦ rakudo/nom:
02:36 Geth ¦ rakudo/nom: This reverts commit ab3162c1275f2519a2b349ac9c3528697e6c730f.
02:36 Geth ¦ rakudo/nom:
02:36 Geth ¦ rakudo/nom: I misunderstood.
02:36 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/6c92994729
02:37 Geth ¦ roast: bd0e07bac7 | (Zoffix Znet)++ | S03-operators/relational.t
02:37 Geth ¦ roast: Revert "Test `before`/`after` with Real/Complex"
02:37 Geth ¦ roast:
02:37 Geth ¦ roast: This reverts commit af93bfd4c0ccd497451fe8c3b5e4a7c928bd1eec.
02:37 Geth ¦ roast:
02:37 Geth ¦ roast: I misunderstood.
02:37 Geth ¦ roast: review: https://github.com/perl6/roast/commit/bd0e07bac7
02:39 pyrimidine joined #perl6-dev
02:49 ilbot3 joined #perl6-dev
02:49 Topic for #perl6-dev is now Perl 6 language and compiler development 2.0 | Logs at http://irclog.perlgeek.de/perl6-dev/today
03:56 pyrimidine joined #perl6-dev
04:51 geekosaur joined #perl6-dev
06:09 cog_ joined #perl6-dev
06:12 stmuk_ joined #perl6-dev
06:14 japhb joined #perl6-dev
06:15 sivoais joined #perl6-dev
06:51 RabidGravy joined #perl6-dev
07:27 [Tux] This is Rakudo version 2017.01-138-g6c9299472 built on MoarVM version 2017.01-25-g70d4bd53
07:27 [Tux] csv-ip5xs        2.847
07:27 [Tux] test            12.180
07:27 [Tux] test-t           4.889 - 2nd 5.039
07:27 [Tux] csv-parser      13.258
07:44 lizmat Files=1175, Tests=55869, 187 wallclock secs (11.25 usr  4.68 sys + 1102.90 cusr 114.08 csys = 1232.91 CPU)
09:39 pyrimidi_ joined #perl6-dev
10:11 Geth ¦ rakudo/nom: f2b97b0ec3 | (Elizabeth Mattijsen)++ | src/core/Rakudo/Iterator.pm
10:11 Geth ¦ rakudo/nom: Add R:It.ReifiedList.skip-at-least
10:11 Geth ¦ rakudo/nom:
10:11 Geth ¦ rakudo/nom: For faster skipping along a reified list.
10:11 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/f2b97b0ec3
10:11 Geth ¦ rakudo/nom: 18e6f0d6d5 | (Elizabeth Mattijsen)++ | src/core/Rakudo/Iterator.pm
10:11 Geth ¦ rakudo/nom: Add R:It.Empty.skip-one/skip-at-least
10:11 Geth ¦ rakudo/nom:
10:11 Geth ¦ rakudo/nom: For even faster skipping along the empty iterator
10:11 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/18e6f0d6d5
10:16 lizmat afk&
10:36 AlexDaniel joined #perl6-dev
10:41 |Tux| joined #perl6-dev
11:00 AlexDaniel joined #perl6-dev
11:17 |Tux| joined #perl6-dev
12:51 Geth ¦ rakudo/nom: 87f61d9694 | (Elizabeth Mattijsen)++ | src/core/Rakudo/Iterator.pm
12:51 Geth ¦ rakudo/nom: Introducing R:It.ReifiedArray
12:51 Geth ¦ rakudo/nom:
12:51 Geth ¦ rakudo/nom: Basically a streamlined version of the Array.iterator for the fully
12:51 Geth ¦ rakudo/nom: reified case.  Added specific support for skip-one and friends, like
12:51 Geth ¦ rakudo/nom: we have in R:It.ReifiedList
12:51 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/87f61d9694
12:51 Geth ¦ rakudo/nom: c069f4598b | (Elizabeth Mattijsen)++ | src/core/Array.pm
12:51 Geth ¦ rakudo/nom: Use R:It.ReifiedArray in Array.iterator
12:51 Geth ¦ rakudo/nom:
12:51 Geth ¦ rakudo/nom: This could have some beneficial effects, specifically in the
12:51 Geth ¦ rakudo/nom: if @a { }  and +@a cases.
12:51 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c069f4598b
13:10 lizmat_ joined #perl6-dev
13:11 brokenchicken What's the price paid for additional multi candidates?
13:12 brokenchicken Like if I choose to add another multi instead of adding a conditional in a existing multi, what negative effect is there?
13:14 lizmat_ if it allows compile-time candidate selection, there's almost always a plus
13:14 lizmat or faster run-time selection
13:14 lizmat or caching
13:14 brokenchicken But does it end up using more RAM or anything like that?
13:15 lizmat well, it would be another entry in the dispatch table  :-)
13:15 lizmat so yes, more ram
13:15 lizmat does it offset the ram used for the condition?  no idea
13:16 brokenchicken Also, I often notice code that avoids using a semicolon at the end of a statement. Is that on purpose because there's some benefit or it is simply because in those cases the semicolon is not required?
13:17 lizmat to me it indicates that it's a return value
13:17 lizmat but that's just me
13:17 lizmat there is no functional difference
13:17 brokenchicken OK. Thanks.
13:34 ggoebel joined #perl6-dev
13:35 jnthn I tend to use omit the ; on the last line of a block/routine when it's a return value
13:35 jnthn Purely as a matter of convention
13:37 Geth ¦ rakudo/nom: 833fe43da6 | (Elizabeth Mattijsen)++ | 2 files
13:37 Geth ¦ rakudo/nom: Give List/Array their own dedicated .tail
13:37 Geth ¦ rakudo/nom:
13:37 Geth ¦ rakudo/nom: I looked at it after seeing it being recommended on StackOverflow.
13:37 Geth ¦ rakudo/nom: Turned out the generic Iterable.tail based solution had disadvantages
13:37 Geth ¦ rakudo/nom: for reified Lists/Arrays.  This is now no longer the case.
13:37 Geth ¦ rakudo/nom:
13:37 Geth ¦ rakudo/nom: For reified List/Arrays, .tail is about 8x as fast as [*-1], and
13:37 Geth ¦ rakudo/nom: .tail(N) is about 16x as fast as [*-N .. *-1] (on a 10 element list).
13:37 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/833fe43da6
13:44 [Coke] jnthn: I mean, it's gotta be slightly faster to compile, no? :)
13:46 jnthn Well, it's one less char to parse, so technically yes :P
13:55 [Coke] WOOHOO
13:56 ggoebel joined #perl6-dev
13:57 * masak .oO( purely a matter of convection )
13:58 [Coke] ... so we have a few degrees of freedom there? (</stretch>)
13:58 masak :P
14:05 brokenchicken cpan@perlbuild2~/CPANPRC/rakudo (nom)$ ./perl6 -e 'say i ~~ (-500000000000000000..2000000000000000)'
14:05 brokenchicken False
14:05 brokenchicken cpan@perlbuild2~/CPANPRC/rakudo (nom)$ ./perl6 -e 'say i ~~ (-500000000000000000..200000000000000000000)'
14:05 brokenchicken True
14:05 brokenchicken Does this look weird to anyone?
14:06 masak ...a little?
14:06 brokenchicken heh
14:06 brokenchicken masak: so you'd expect it to give False in both cases?
14:07 masak aye
14:07 brokenchicken OK
14:07 masak I'd expect that
14:09 jnthn wtf :)
14:09 brokenchicken jnthn: consequence of <=> scaling tolerance for ignoring imaginary part based on both args
14:10 arnsholt Well, that falls out from the "imaginary parts negligeable" part of Complex compare brokenchicken highlighted earlier today, no?
14:10 arnsholt Yeah, that
14:10 brokenchicken m: say i <=> 2000000000000000
14:10 camelia rakudo-moar 833fe4: OUTPUT«Can not convert Complex to Real: Complex is not numerically orderable␤  in block <unit> at <tmp> line 1␤␤Actually thrown at:␤  in block <unit> at <tmp> line 1␤␤»
14:10 brokenchicken m: say i <=> 200000000000000000000
14:10 camelia rakudo-moar 833fe4: OUTPUT«Less␤»
14:11 arnsholt That's super-weird, IMO
14:11 brokenchicken yeah
14:11 arnsholt It should just throw in all cases, I think
14:11 masak <=> yes; ~~ no
14:12 arnsholt I guess ~~ is different, yeah
14:12 brokenchicken Complex.Real and by extension >/</<=/>= do the same type of thing, but use the default $*TOLERANCE
14:12 arnsholt But if Range ~~ uses <=> internally, it'll throw =)
14:13 arnsholt Or perhaps not, given that it doesn't explode in the example above
14:13 brokenchicken It's a failure. And I took care of it in my example :)
14:13 arnsholt Heh
14:24 AlexDaniel joined #perl6-dev
14:45 brokenchicken cpan@perlbuild2~/CPANPRC/rakudo (nom)$ ./perl6 -e 'for ([<0+0i>, -1..10],) { dd "{.[0].perl} ~~ {.[1].perl}"; "{.[0].perl} ~~ {.[1].perl}".EVAL.say; say .[0] ~~ .[1] }'
14:45 brokenchicken "<0+0i> ~~ -1..10"
14:45 brokenchicken True
14:45 brokenchicken False
14:45 brokenchicken wtf?
14:46 jdv79 timotimo: any luck on grinding that conc related bug
14:46 jdv79 ?
14:46 brokenchicken something doesn't decontainerise...
14:47 DrForr My suspicion would be that 0+0i is two values, 0 and 0i.
14:48 brokenchicken DrForr: no, it's a complex literal. But it gives different result depending on whether I feed it as is or via an array
14:48 brokenchicken m: dd <0+0i>
14:48 camelia rakudo-moar 833fe4: OUTPUT«<0+0i>␤»
14:48 brokenchicken m: dd WHAT <0+0i>
14:48 camelia rakudo-moar 833fe4: OUTPUT«Complex␤»
14:49 DrForr Okay, I thought I'd seen instances where it was a number created from Re and Im parts, but I may havae spent too much time in the grammar.
14:49 brokenchicken hm, sticking deconts as nqp::decont(.[0]) ~~ nqp::decont(.[1]) doesn't fix it :S
14:50 brokenchicken Ah
14:51 brokenchicken It's aliasing stuff. The .[1] ain't what I meant it to be
15:09 brokenchicken ZOFVM: Files=1224, Tests=132845, 178 wallclock secs (22.34 usr  3.16 sys + 3453.93 cusr 258.35 csys = 3737.78 CPU)
15:25 Woodi [6~[5~
15:34 Geth ¦ rakudo/nom: f2894d311c | (Zoffix Znet)++ | src/core/Range.pm
15:34 Geth ¦ rakudo/nom: Fix smartmatch of Complex against Ranges
15:34 Geth ¦ rakudo/nom:
15:34 Geth ¦ rakudo/nom: For non-Int Ranges, ACCEPTS uses `before`/`after` that utilizes `cmp`
15:34 Geth ¦ rakudo/nom: semantics and so we end up with weirdness such as i ~~ 0..1 giving True.
15:34 Geth ¦ rakudo/nom:
15:34 Geth ¦ rakudo/nom: TimToady++ suggested[^1] to use `<=>` instead, however, its scaling
15:34 Geth ¦ rakudo/nom: tolerance for ignoring imaginary part feels a bit too weird in Ranges[^2],
15:34 Geth ¦ rakudo/nom: <…commit message has 6 more lines…>
15:34 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/f2894d311c
15:41 Geth ¦ roast: 490dbe4634 | (Zoffix Znet)++ | S02-types/range.t
15:41 Geth ¦ roast: Test Complex smartmatch against Range
15:41 Geth ¦ roast:
15:41 Geth ¦ roast: Rakudo fix: https://github.com/rakudo/rakudo/commit/f2894d311c
15:41 Geth ¦ roast: review: https://github.com/perl6/roast/commit/490dbe4634
15:51 [Coke] our pod to html might be borked. Seeing lots of constructs uselessly wrapped in <p> tags.
15:51 [Coke] https://validator.w3.org/nu/?doc=https%3A%2F%2Fdocs.perl6.org%2F
15:52 [Coke] ... moving to #perl6, whoops
16:10 pyrimidine joined #perl6-dev
16:21 timotimo jdv79: sorry, no luck so far :(
16:58 pyrimidine joined #perl6-dev
17:04 timotimo jdv79: though could you see if turning off spesh will make your ungolfed code work or crash?
17:13 FROGGS joined #perl6-dev
17:13 jdv79 MVM_SPESH_DISABLE?
17:14 timotimo yup
17:14 timotimo if that helps, we can try the spesh bisect tool to figure out what exact thing b0rks it
17:59 jdv79 first try seems to validate your view
18:00 jdv79 but im busy atm to try again
18:00 jdv79 *too
18:09 TimToady here's the current statistics on dynvar overhead: https://gist.github.com/anonymous/495fa6ad87c38f2df671066e5ed53a1e
18:09 timotimo thanks jdv79
18:09 timotimo my internet connection is currently ... the absolute crap
18:09 TimToady tl;dr is that we're a bit under 4% overhead, but the current cache mechanism is obviously overstressed still, with an average of 13 frames to find a cached copy of $*W, for instance
18:10 timotimo oof.
18:10 timotimo $*W is pretty expensive, then
18:10 timotimo that's Quite Bad, then
18:11 timotimo since it's needed all the time
18:11 TimToady and every time we look up @*comp_line_directives, it's not there, and we average 155 frames to figure that out
18:11 timotimo i don't even know what comp_line_directives is
18:11 timotimo is that #?line blah 0?
18:11 TimToady beats me, it's only in nqp
18:11 timotimo could very well be it
18:11 timotimo not quite sure why it'd be dynamic in scope, if it is what i think it is
18:12 TimToady dynvars have definitely been a bit of an attractive nuisance over the years
18:13 timotimo is 55787 the number of lookups in total?
18:14 timotimo and all of them hit N, i.e. "not there"?
18:15 brokenchicken $*HAS_YOU_ARE_HERE hah
18:15 TimToady F = found in frame, C = found in cache (earlier frame), N = not found, I = found in an inlined block
18:16 timotimo i might look into getting rid of the comp line directives dynvar
18:16 TimToady well, this really tells us two different things
18:16 TimToady first, we overuse dynvars
18:16 TimToady but second, the general dynvar overhead is too much
18:16 timotimo it's surprisingly high up in the list, and i'm pretty sure it's only used in the core setting
18:16 timotimo what were you running to get these stats?
18:17 TimToady MVM_DYNVAR_LOG=/tmp/dlog on the parser step
18:17 timotimo well, the parser step of what? :)
18:17 TimToady (which does little IO, or $*STDOUT would be way up there)
18:18 TimToady the setting
18:18 timotimo oh, huh?
18:18 timotimo but the core setting uses line directives!
18:18 TimToady and then I have a program that analyzes the log
18:18 timotimo what the ...
18:19 timotimo okay now i use mosh to connect to my irc client
18:19 timotimo that should make things more bearable
18:20 brokenchicken So that 4% only affects setting compilation and nothing in user code?
18:21 brokenchicken m: say 72*.04
18:21 camelia rakudo-moar f2894d: OUTPUT«2.88␤»
18:22 brokenchicken Oh wait no, it affects user code too, duh :P
18:22 timotimo all user code that uses dynamic variables too much would suffer worse performance until the dynvar caching stuff is bettered
18:23 TimToady I should maybe try this on something that is heavy in $*STDOUT or $*STDERR
18:23 timotimo .o( rc-forest-fire )
18:23 TimToady hah
18:24 TimToady well, if a program is only using one dynvar, the cache will work pretty okay, I expect
18:24 timotimo ought to, yeah
18:32 jnthn TimToady: fwiw, I think $*W could also go on the cursor
18:35 timotimo i wonder how hard it'd be to run the same measurements but pretend that one given dynvar wasn't a dynvar
18:35 timotimo perhaps an env var could be introduced that prevents a single name for a dynvar to reach the cache at all?
18:35 timotimo then we could compare how other dynvars would move around in that case
18:36 timotimo without taking the necessary steps to install it in a proper place
18:36 timotimo and so we could automatically do it for every dynvar that exists and pick out the one that's worth the most
18:37 timotimo just a random thought
18:37 TimToady jnthn: yes, I'm gonna put a lot of those into a Braid object that floats along where we currently just have $!actions
18:38 TimToady in fact, actions can go in that object too
18:38 TimToady then there's no more overhead to copying the braid pointer than we have currently copying the actions pointer
18:38 TimToady and things like pragmas and other stuff can go in there too
18:39 timotimo and "are we in a core setting?"
18:39 TimToady that too
18:40 TimToady btw, on 1000 generations of forest fire, $*OUT never caches, but is N with 20 frames per lookup average, so we can do better there
18:40 timotimo never caches o_O
18:40 timotimo maybe it tends to cache in frames that are going to be thrown out immediately anyway? or "never gets installed at all"?
18:40 jnthn It doesn't cache because it's not on the call stack, but in PROCESS::<$OUT>
18:41 timotimo oh, huh
18:41 TimToady well, it's looking 20 frames to figure that out every time
18:41 timotimo that information doesn't land in the cache, so that'd be a good step forward perhaps?
18:41 jnthn Well, unless the cache has a way of saying "we don't have it on the stack"
18:41 TimToady and that's a pretty shallow program
18:41 jnthn Which would be reasonable.
18:42 TimToady yes, we need to cache negatives too
18:42 TimToady whatever the scheme
18:42 jnthn Trouble with caching results from PROCESS is that it might be rebound
18:42 TimToady not supposed to be
18:43 jnthn Well, if we're willing to forbid that... :)
18:43 TimToady well, a good cache would just have a link straight to PROCESS::<$OUT>
18:43 jnthn How general is it, though? In Test::Scheduler I relied on being able to rebind PROCESS::<$SCHEDULER> for example
18:45 TimToady m: PROCESS::<$OUT> = $*ERR
18:45 camelia rakudo-moar f2894d: ( no output )
18:45 TimToady we could maybe restrict to assignment, so we always have the same container
18:45 jnthn That could work
18:45 TimToady then the cache can point to the container
18:45 jnthn *nod*
18:45 jnthn Yeah
18:47 TimToady in general it would be good to have a better idea of which dynvars are readonly though
18:49 TimToady what do you think of the idea of adding dynvar cache entries to a (supposedly immutable) lexpad on the fly
18:50 TimToady that is, instead of having a dedicated hash in a caching frame, just use the lexpad
18:51 TimToady we'd still presumably have a pointer in the current frame to the nearest caching frame, since we don't want to cache everything in every frame
18:51 brokenchicken nqp: say(nqp::div_i(10000000000000000, 4))
18:51 camelia nqp-moarvm: OUTPUT«468729856␤»
18:51 TimToady where a caching frame is the nearest frame tht is associated with a 'my $*foo' of some sort
18:51 TimToady (ignoring $/, $_, and $! for the moment)
18:52 timotimo yeah, $/, $_, and $! would probably trash that
18:52 TimToady which we probably exempt from the dynvar cache
18:53 TimToady and just scan frames for them, as currently
18:53 brokenchicken m: use nqp; say(nqp::isbig_I(10000000000000000))
18:53 camelia rakudo-moar f2894d: OUTPUT«1␤»
18:53 brokenchicken hm
18:53 brokenchicken m: say int.Range
18:53 camelia rakudo-moar f2894d: OUTPUT«-9223372036854775808..9223372036854775807␤»
18:54 brokenchicken So that range is bogus? Our int can have max around 20 bits?
18:54 brokenchicken s: int, 'Range', \()
18:54 SourceBaby brokenchicken, Sauce is at https://github.com/rakudo/rakudo/blob/f2894d3/src/core/Int.pm#L157
18:54 TimToady maybe isbig is about whether we steal half the pointer or not
18:55 brokenchicken m: say log 9223372036854775807 / log 2
18:55 camelia rakudo-moar f2894d: OUTPUT«44.0347852958582␤»
18:55 timotimo yup
18:55 timotimo there's an XXX in there
18:56 timotimo "someone please check that on a 32bit platform"
18:56 brokenchicken m: say log(9223372036854775807) / log 2
18:56 camelia rakudo-moar f2894d: OUTPUT«63␤»
18:56 timotimo oh
18:56 timotimo it's actually about fitting into an INTVAL
18:56 timotimo so i expect it to be about 64bit
18:56 brokenchicken m: say log(10000000000000000) / log 2
18:56 camelia rakudo-moar f2894d: OUTPUT«53.1508495181978␤»
19:03 jnthn TimToady: The set of lexicals we have is fixed by compile time
19:03 TimToady yes, but do we rely on that in a way that would prevent using the data structure as the cache?
19:03 jnthn TimToady: The lexpad is actually an array of fixed size, with a hash held statically mapping names to indexes if we need to do late-bound lookups
19:04 jnthn MoarVM doesn't have a concept of a not-fixed-at-compile-time lexical.
19:04 jnthn So yeah, that goes quite deep
19:05 jnthn But if the ideas is to hang the cache off of a frame that has dynamic lexicals, we would still hang it off the frame, I guess?
19:05 TimToady so, in theory, we could add to the hash, and extend all the arrays (lazily perhaps) with the same offsets for any given dynvar
19:06 TimToady I'm just trying to save a pointer in the frame
19:06 jnthn I think an awful lot of assumptions hang off that array's size being fixed.
19:07 jnthn It's even allocated with the fixed size allocator
19:07 TimToady if we didn't steal the lexpad, my scheme has a pointer to the current cache frame, and a hash pointer in cache frames
19:07 jnthn I think I'd prefer the extra pointer in MVMFrame
19:07 jnthn I mean, this scheme actually *elimiantes* two pointers
19:07 TimToady and in a cache frame, the cache pointer points to the next cache frame up the stack
19:07 jnthn Oh, there is one other worry however. :S
19:08 jnthn m: sub foo() { my $*a; await bar(); say $*a }; sub bar() { start { $*a = 42 } }; foo()
19:08 camelia rakudo-moar f2894d: OUTPUT«42␤»
19:09 jnthn In the case we await this isn't so troublesome, but dynamic lookups can come from another thread
19:09 jnthn Unless we say that those cannot use the cache
19:10 jnthn But if we have a hash and we're fiddling with it on one thread and reading it on another...SEGV coming.
19:10 pyrimidine joined #perl6-dev
19:10 TimToady is this a GC thing the we can't point to another thread's frame?
19:10 TimToady *that
19:11 jnthn No, in fact we hold references to frames from other threads all the time
19:11 jnthn It's not that you can't hold a reference. It's that you *can* hold a reference.
19:11 jnthn And that means you can't assume something you hang off of MVMFrame is only going to be touched by a single thread.
19:12 jnthn The ->outer of any start block, and most supply blocks, points to an MVMFrame that started life on another thread.
19:12 TimToady well, an update is gonna be pretty quick and simple, from a locking point of view
19:13 TimToady or we go with some lock-free scheme
19:13 TimToady there's nothing says the cache has to be standard hash
19:13 jnthn Well, the typical one in this kind of situation is to go immutable
19:14 TimToady especially if we're gonna intern the dynvar names
19:14 jnthn So we never actually mutate the hash, we just make a new one and it's the installation of that which is atomic
19:14 jnthn So something is only ever reading a particular version
19:14 TimToady since there will typically not be so many unique dynvar names
19:14 nine Read Copy Update
19:15 jnthn Provided the GC is managing the hash then it'll take care of there being no dangling references.
19:15 jnthn How many things do we suspect we'll have in the hash, though?
19:15 jnthn (I'm wondering if there's enough to make a hash worth it.)
19:16 TimToady if we have integers representing names, scanning a short array for a given integer is gonna be pretty cache friendly
19:16 jnthn (Since, especially if you intern, you can linear-scan a small number of entries pretty fast.)
19:16 jnthn Yeah
19:16 jnthn Of course, the moment we start to intern is the moment we get a new memory leak. :-)
19:17 jnthn (Though not likely to be an issue in this case.)
19:17 TimToady in the olden days, you'd make a linked list and link the new one in at the front for sharing between the immutable tails
19:17 TimToady but not so cache friendly
19:18 jnthn Aye.
19:19 TimToady I suppose with some history one might just create a frame with the cache entries we think we'll need, but populate the entries lazily
19:19 TimToady so we don't build up from an empty array of integers each time
19:21 TimToady that is, manage the "namespace" of the integer list much like we do with the names of a lexpad, so all similar frames share the same structure
19:21 jnthn Could do
19:21 jnthn There's also a bunch of spare static frame flags, fwiw
19:22 jnthn If we need to convey which frames should have a cache down to the VM
19:24 TimToady well, I'm mostly just trying to preload the branes of whoever are going to do this eventually, which I suspect is not me, given how much I have yet to do on the compiler end of things :)
19:25 TimToady and GC vs frames is still a half a paygrade up from me :)
19:25 TimToady but it's nice to know there's an "easy" 3% improvement sitting there, anyway
19:26 TimToady well, I suppose if I do the braid thing right, it could drop below 3% overhead for the parser
19:26 TimToady but still
19:27 timotimo maybe the fact that it'll fill up cpu caches less will also make things in the periphery a tiny bit faster …
19:27 timotimo one can dream, right?
19:30 TimToady Sure, anything you don't do has the benefit of not adding entropy to the universe.  :)
19:30 TimToady (except maybe for the deciding not to do it part...)
19:36 TimToady my general plan of attack on the language braid issue is much the same as I did with $*ACTIONS, which is to use the current dynvars as the scaffolding to double-check that the new mechanism points to the same values at critical spots, then eventually remove the scaffolding
19:36 timotimo %)
19:37 TimToady in the case of %*LANG, we'll have to decide whether to support people who are currently relying on the %*LANG interface
19:37 TimToady it's not tested in roast, so not officially a part of the language, but at the same time, people have written documents referencing it, if not modules
19:40 timotimo yeah, modules exist that use it
19:41 TimToady can maybe do some shallow emulation there in the short term for 6.c
19:41 TimToady had some shallow emulation of $*ACTIONS in there for a while till I decided to just rip out that scaffolding
19:41 TimToady haven't heard much carpage about that...
19:42 TimToady but in the case of actions, we already had a documented :actions() interface to .parse
19:42 timotimo aye
19:43 TimToady what's the name of "all the modules" again?
19:43 timotimo perl6-all-modules
19:43 timotimo potentially under moritz/
19:43 TimToady thanks
19:50 TimToady I see that I've bitrotted v5 by removing $*ACTIONS, but maybe it was already bitrat
19:51 brokenchicken it was already
19:52 brokenchicken rat is an acceptable past tense of rot?
19:53 TimToady rit, rat, had rot
19:53 moritz for experimental linguists at least :-)
19:56 TimToady yeah, there's 10 or so modules out there that refer to %*LANG, besides v5
19:57 moritz probably Slang:: modules?
19:57 buggable joined #perl6-dev
19:57 moritz oh, seems some others too
19:58 moritz CompUnit::Util
19:58 moritz BioInf # that one surprised me
19:58 moritz Control::Bail
20:00 TimToady fortunately, none of them other than v5 do 'my %*LANG'
20:01 TimToady so I should be able to setup up %*LANG such that it can just poke things into the new braid thingie
20:02 TimToady just need a temporary $*BRAID thing to point %*LANG at the current cursor's braid object
20:05 TimToady but that has to be 'my $*BRAID' at the same spots we currently do 'my %*LANG'...hmm...
20:06 TimToady or maybe just keep it in %*LANG<braid>, and then it automatically scopes the same...
20:06 TimToady and automatically goes away when %*LANG goes away
20:06 moritz so, what's a braid?
20:07 TimToady all the languages associated with the current actual language we're parsing, so MAIN, Regex, Quote, etc
20:08 TimToady I suppose we could call it tag-team languages :)
20:08 TimToady but I like "braided languages"
20:10 TimToady in a larger sense, the braid is all those things that define the current language at the current spot in the lexical scope, so includes things like, pragams, current package name, anything that influences the meaning of anything we haven't parsed yet
20:12 TimToady so the cursor itself represents the current language in the narrow sense of grammar methods, while the braid (which will hang off the cursor as a kind of shared delegate (but that changes more frequently than $!shared does)) represents the current language in the wider sense
20:13 * TimToady wonders what a pragam is...
20:13 moritz ok, thanks for the explanation
20:14 TimToady so basically the cursor's $!shared delegate is everything shared by a given parse, while $!braid will be everything shared by a lexical scope (or the rest of the lexical scope, when we change it halfway through)
20:16 TimToady we could perhaps combine those, since the whole parse is a kind of lexical scope, but then we'd be copying the same values around everywhere when we know they're never gonna change in an inner scope
20:17 TimToady whether the occasional copy is more expensive than the extra pointer, who can say?
20:17 * jnthn figures %*HOW or whatever it's called will end up in the braid too
20:18 TimToady lotsa things going in there, if lexically scoped
20:18 TimToady as you said, maybe the whole world goes along with it
20:20 TimToady but maybe the world can just be in $!shared
20:22 TimToady unless we want to start dealing with hypothetical worlds or some such, in which case we might carry it along for the ride
20:22 TimToady as I say, the division between $!shared and $!braid is really only pragmatic for how much copying we want to do at language boundaries
20:24 TimToady interestingly, with the braid delegate, we can tweak the current braid using mixins without recalculating the NFAs based on the cursor type
20:25 TimToady so we could get rid of the hash and just use mixins for the equivalent of %*LANG<Regex> and such
20:27 TimToady and then the braided languages would be encoded in the braid type, without any attribute, just a method to return the sublang
20:28 TimToady dunno how much that buys us, though, given how seldom we would actually copy one braid object to anther
20:29 TimToady and since a braid object is shared over many cursors, probably don't really need to worry much about attribute storage
20:59 lizmat m: sub a(--> 42) { { return } }; dd a   # expected 42
20:59 camelia rakudo-moar f2894d: OUTPUT«Nil␤»
20:59 lizmat am
20:59 lizmat jnthn: am I wrong in expecting that?  ^^^
21:12 jnthn What were you expecting?
21:12 jnthn Looks right to me.
21:13 jnthn m: sub a(--> 42) { return }; dd a
21:13 camelia rakudo-moar f2894d: OUTPUT«42␤»
21:13 jnthn Um
21:13 jnthn How does that one work?
21:13 pyrimidine joined #perl6-dev
21:13 jnthn I thought the --> was just for the fall-off-the-end though...
21:14 ugjka joined #perl6-dev
21:15 lizmat jnthn: apparently not ?
21:16 lizmat m: sub a(--> 42) { return 666 }
21:16 camelia rakudo-moar f2894d: OUTPUT«5===SORRY!5=== Error while compiling <tmp>␤No return arguments allowed when return value 42 is already specified in the signature␤at <tmp>:1␤------> 3sub a(--> 42) { return 666 7⏏5}␤»
21:16 lizmat jnthn: so I guess a bare return is sorta expected in this casse
21:16 lizmat *case
21:27 jnthn m: sub a(--> 42) { if 1 { return 666 } }
21:27 camelia rakudo-moar f2894d: ( no output )
21:27 jnthn Fail
21:27 jnthn m: sub a(--> 42) { if 1 { return } }; say a
21:27 camelia rakudo-moar f2894d: OUTPUT«Nil␤»
21:27 jnthn That's a pretty bad discrepancy
21:28 jnthn m: sub a(--> 42) { return }
21:28 camelia rakudo-moar f2894d: ( no output )
21:28 jnthn m: sub a(--> 42) { return }; say a
21:28 camelia rakudo-moar f2894d: OUTPUT«42␤»
21:28 * jnthn wonders how that works :)
21:30 lizmat rakudobug material ?
21:32 jnthn Surely
21:32 jnthn I didn't even know we had that feature :P
21:45 lizmat RT #130706
21:45 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=130706
21:48 perlpilot that's interesting.
21:48 perlpilot m: sub a(--> 42) { sub { return } }; dd a  # weird
21:48 camelia rakudo-moar f2894d: OUTPUT«42␤»
21:49 lizmat no, to be expected
21:49 lizmat you return out of the inner sub, and fall off the outer one, and that returns 42
21:50 perlpilot oh, because the inner sub is basically ignored
21:50 lizmat ah, and that  :-)
21:51 lizmat m: sub a(--> 42) { return sub { return } }
21:51 camelia rakudo-moar f2894d: OUTPUT«5===SORRY!5=== Error while compiling <tmp>␤No return arguments allowed when return value 42 is already specified in the signature␤at <tmp>:1␤------> 3sub a(--> 42) { return sub { return } 7⏏5}␤»
21:52 perlpilot sweet.
21:52 perlpilot m: sub a(--> 42) { if 1 { return 5 } }; dd a
21:53 camelia rakudo-moar f2894d: OUTPUT«5␤»
21:53 lizmat m: sub { }  # perhaps a nameless sub in sink context should warn ?
21:53 camelia rakudo-moar f2894d: ( no output )
21:53 perlpilot so, that one should have complained in the same way
21:58 TimToady yes, shoulda
22:02 geekosaur joined #perl6-dev
22:14 MasterDuke joined #perl6-dev
22:14 Geth ¦ Pod-To-HTML/coke/html-test: 0b44eb2aa4 | (Will "Coke" Coleda)++ | t/09-Html.t
22:14 Geth ¦ Pod-To-HTML/coke/html-test: Add a test for =pod Html
22:14 Geth ¦ Pod-To-HTML/coke/html-test:
22:14 Geth ¦ Pod-To-HTML/coke/html-test: Issue #23
22:14 Geth ¦ Pod-To-HTML/coke/html-test: review: https://github.com/perl6/Pod-To-HTML/commit/0b44eb2aa4
22:14 [Coke] ... wrong window.
22:21 pyrimidine joined #perl6-dev
22:49 pyrimidine joined #perl6-dev
23:21 pyrimidine joined #perl6-dev
23:27 MasterDuke can NQP's src/HLL/Compiler.nqp not use $*W?
23:45 Geth ¦ star: wchristian++ created pull request #85: note in the readme that platform-issues may exist
23:45 Geth ¦ star: review: https://github.com/rakudo/star/pull/85
23:51 travis-ci joined #perl6-dev
23:51 travis-ci Rakudo build passed. Zoffix Znet 'Merge pull request #1010 from ronaldxs/new-fancier-fudgeandrun
23:51 travis-ci https://travis-ci.org/rakudo/rakudo/builds/197412611 https://github.com/rakudo/rakudo/compare/97359ae42e2a...bc53f6770f58
23:51 travis-ci left #perl6-dev
23:55 Geth ¦ star: 5388a95f66 | (Steve Mynott)++ | tools/star/release-guide.pod
23:55 Geth ¦ star: I did 2017.01
23:55 Geth ¦ star: review: https://github.com/rakudo/star/commit/5388a95f66
23:55 Geth ¦ star: 494842a834 | (Christian Walde (Mithaldu))++ | README
23:55 Geth ¦ star: note in the readme that platform-issues may exist
23:55 Geth ¦ star:
23:55 Geth ¦ star: Currently the readme does not mention that there may be issues with the build process, which are documented outside of the tarball. This added sentence mentions that.
23:55 Geth ¦ star: review: https://github.com/rakudo/star/commit/494842a834
23:55 Geth ¦ star: e0a5125286 | (Steve Mynott)++ | README
23:55 Geth ¦ star: Merge pull request #85 from wchristian/patch-1
23:55 Geth ¦ star:
23:55 Geth ¦ star: note in the readme that platform-issues may exist
23:55 Geth ¦ star: review: https://github.com/rakudo/star/commit/e0a5125286

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary