Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2017-03-19

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

All times shown according to UTC.

Time Nick Message
00:20 Ven joined #perl6-dev
01:34 MasterDukeMobile 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
07:31 Geth ¦ nqp: dffc2ddbde | (Samantha McVey)++ | tools/build/MOAR_REVISION
07:31 Geth ¦ nqp: Bump MoarVM to bring in fixes and tests passing again
07:31 Geth ¦ nqp:
07:31 Geth ¦ nqp: fe1dc84a Merge pull request #556 from MasterDuke17/special_case_crlf_in_MVM_nfg_is_concat_stable
07:31 Geth ¦ nqp: f2731339 Special case "\r\n" in MVM_nfg_is_concat_stable
07:31 Geth ¦ nqp: 7d7a6b18 Fix bug in indexic_s if expanding cp is the last cp
07:31 Geth ¦ nqp: c9b3a35a Add more details on speed improvement to changelog
07:31 Geth ¦ nqp: review: https://github.com/perl6/nqp/commit/dffc2ddbde
07:31 Geth ¦ nqp: version bump brought these changes: https://github.com/MoarVM/MoarVM/compare/2017.03...2017.03-4-gfe1dc84a
07:32 samcv ok cool. test should be fixed now
07:33 Geth ¦ nqp: 713526e023 | (Samantha McVey)++ | docs/ops.markdown
07:33 Geth ¦ nqp: Fix typo in `indexic` op in ops.markdown
07:33 Geth ¦ nqp: review: https://github.com/perl6/nqp/commit/713526e023
07:59 travis-ci joined #perl6-dev
07:59 travis-ci NQP build passed. Samantha McVey 'Bump MoarVM to bring in fixes and tests passing again
07:59 travis-ci https://travis-ci.org/perl6/nqp/builds/212630636 https://github.com/perl6/nqp/compare/a36cc5a9877c...dffc2ddbdebd
07:59 travis-ci left #perl6-dev
08:02 travis-ci joined #perl6-dev
08:02 travis-ci NQP build passed. Samantha McVey 'Fix typo in `indexic` op in ops.markdown'
08:02 travis-ci https://travis-ci.org/perl6/nqp/builds/212630868 https://github.com/perl6/nqp/compare/dffc2ddbdebd...713526e0239a
08:02 travis-ci left #perl6-dev
08:52 RabidGravy joined #perl6-dev
08:56 [Tux] This is Rakudo version 2017.03-8-gbfbe4298a built on MoarVM version 2017.03-4-gfe1dc84a
08:56 [Tux] csv-ip5xs        3.021
08:56 [Tux] test            12.463
08:56 [Tux] test-t           4.838 - 4.842
08:56 [Tux] csv-parser      13.094
09:35 agentzh joined #perl6-dev
10:50 lizmat Files=1179, Tests=55902, 193 wallclock secs (11.84 usr  4.68 sys + 1156.42 cusr 106.96 csys = 1279.90 CPU)
11:03 Ven joined #perl6-dev
11:13 Ven_ joined #perl6-dev
11:36 timotimo huggable: speed
11:36 huggable timotimo, http://tux.nl/Talks/CSV6/speed4.html
11:36 timotimo buggable: speed
11:36 buggable timotimo, ▂▁▁▁▁▁▂▁▂▁▁▂▂▁▂▁▁▁▁▂▂▂▂▂▂▂▂▂▂▂▂▂▁▃▃▂▂▂▂▁▂█▂▂▃▂▁▁▁▁ data for 2017-02-24–2017-03-19; range: 4.788s–7.664s
11:37 timotimo 2017-02-19 10:22:49 test-t 999.999
11:37 timotimo 2017-02-19 10:23:44 test-t 999.999
11:37 timotimo that certainly muddies up the graph
11:37 lizmat those two days, test-t didn't compile
11:38 lizmat *times
11:38 lizmat perhaps NaN would have been better  :-)
11:39 [Tux] :P
11:39 [Tux] and it was just one day. You lot acted promptly :)
11:41 timotimo buggable: source
11:41 buggable timotimo, See: https://github.com/zoffixznet/perl6-buggable
11:41 timotimo @recent .= grep: * ne '999.999'; # filter out bogus results
11:41 timotimo so that's not what that spice in there was
11:41 timotimo 2017-03-14 09:48:29 test-t 5.016
11:42 timotimo 2017-03-15 23:56:09 test-t 7.664
11:42 timotimo 2017-03-16 10:09:09 test-t 5.037
11:42 timotimo that's the spike
11:42 timotimo i wonder what happened there
11:44 lizmat I think that was samcv working on lc -> fc ?
11:44 timotimo oh, maybe
11:45 [Tux] and my system-upgrade had no measurable influence on timings </pheeuw>
12:52 Geth ¦ roast/recursive-dir: ddf9ae1c03 | (Wenzel P. P. Peppmeyer)++ | S32-io/dir.t
12:52 Geth ¦ roast/recursive-dir: add test for &dir(:recursive)
12:52 Geth ¦ roast/recursive-dir: review: https://github.com/perl6/roast/commit/ddf9ae1c03
12:54 Geth ¦ rakudo: gfldex++ created pull request #1045: teach &dir to be recursive
12:54 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/1045
12:55 gfldex who knew I had a commit bit to roast!
12:55 gfldex (that was planned to be a PR too)
13:37 agentzh joined #perl6-dev
14:50 moritz gfldex: you should have a commit bit to just about all repos in the perl6 github organization
14:58 IRCFrEAK joined #perl6-dev
14:59 AlexDaniel joined #perl6-dev
15:17 Geth ¦ rakudo/nom: fbe7ace6fc | (Zoffix Znet)++ | src/core/IO/Path.pm
15:17 Geth ¦ rakudo/nom: Make IO::Path.dir a multi
15:17 Geth ¦ rakudo/nom:
15:17 Geth ¦ rakudo/nom: So module-space can augment it with multies
15:17 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/fbe7ace6fc
15:21 IOninja ZOFVM: Files=1228, Tests=132877, 126 wallclock secs (21.25 usr  3.36 sys + 2413.49 cusr 283.17 csys = 2721.27 CPU)
15:44 ggoebel joined #perl6-dev
16:00 gfldex m: use MONKEY-TYPING; augment class IO::Path { multi method dir(:$recursive) { note 'oi‽' } }; dir(:recursive);
16:00 camelia rakudo-moar fbe7ac: ( no output )
16:00 gfldex m: use MONKEY-TYPING; augment class IO::Path { multi method dir(:$recursive) { note 'oi‽' } }; IO::Path.^compose; dir(:recursive);
16:00 camelia rakudo-moar fbe7ac: ( no output )
16:02 IOninja the other candidate wins, 'cause it's earlier in source
16:02 IOninja m: use MONKEY-TYPING; augment class IO::Path { subset Foo of IO::Path where True; multi method dir(Foo: :$recursive) { note 'oi‽' } }; dir(:recursive);
16:02 camelia rakudo-moar fbe7ac: OUTPUT: «Potential difficulties:␤    Smartmatch against True always matches; if you mean to test the topic for truthiness, use :so or *.so or ?* instead␤    at <tmp>:1␤    ------> 3IO::Path { subset Foo of IO::Path where 7⏏5True; multi method dir(Foo: …»
16:02 IOninja m: use MONKEY-TYPING; augment class IO::Path { subset Foo of IO::Path where {True}; multi method dir(Foo: :$recursive) { note 'oi‽' } }; dir(:recursive);
16:02 camelia rakudo-moar fbe7ac: ( no output )
16:02 IOninja m: use MONKEY-TYPING; augment class IO::Path { subset Foo of IO::Path:D where {True}; multi method dir(Foo: :$recursive) { note 'oi‽' } }; dir(:recursive);
16:02 camelia rakudo-moar fbe7ac: ( no output )
16:02 IOninja :/
16:03 IOninja m: use MONKEY-TYPING; augment class IO::Path { subset Foo of IO::Path:D where {True}; multi method dir(Foo: :$recursive!) { note 'oi‽' } }; dir(:recursive);
16:03 camelia rakudo-moar fbe7ac: ( no output )
16:03 gfldex m: use MONKEY-TYPING; IO::Path.^add_method('dir', my method (:$recursive) { note 'oi‽' }); IO::Path.^compose; dir(:recursive);
16:03 camelia rakudo-moar fbe7ac: ( no output )
16:03 IOninja m: use MONKEY-TYPING; augment class IO::Path { subset Foo of IO::Path:D where {True}; multi method dir(Foo: :$recursive!) { note 'oi‽' } }; ".".IO.dir(:recursive);
16:03 camelia rakudo-moar fbe7ac: ( no output )
16:03 IOninja weird
16:03 gfldex indeed
16:04 IOninja Ahhhhh
16:04 IOninja gfldex: the bot's restricted. It's not the real IO::Path class
16:04 gfldex it doesn't work on my host either
16:05 gfldex m: say dir;
16:05 camelia rakudo-moar fbe7ac: OUTPUT: «(".cpanm".IO ".local".IO ".npm".IO ".perl6".IO ".perlbrew".IO ".rcc".IO ".ssh".IO "Perlito".IO "evalbot".IO "log".IO "nqp-js".IO "p1".IO "p2".IO "perl5".IO "std".IO ".bash_history".IO ".bashrc".IO "mbox".IO ".lesshst".IO "evalbot.log".IO ".cpan".IO "dale…»
16:05 ugexe multi method dir(Foo: :$recursive! where *.so) { note 'oi‽' } }; # don't you mean to *.so the check on :recursive?
16:05 ugexe (not related to this problem obviously)
16:06 gfldex jnthn: we need a little dispatcher judgement here
16:07 IOninja gfldex: the first version? Those won't work 'cause the core candidate wins. Try the ones with the subset
16:07 IOninja That dispatcher thing was already judged.
16:07 IOninja It's not a bug.
16:07 gfldex so my candidate is just late in the list then?
16:07 IOninja mhm
16:07 IOninja And you can make it be considered first by making the invocant typecheck more specific
16:08 IOninja (or add positional args)
16:08 gfldex is it the implicit *%_ that is at play here?
16:09 IOninja I think it's that named args don't play a role in dispatch other than "have any" vs "none"
16:10 gfldex that makes overloading quite tricky
16:10 IOninja I don't think we want to encourange rampant `augment` use :)
16:10 gfldex well, overloading would introduce a new type object to match on
16:10 gfldex I can still .wrap
16:13 ugexe I wonder what the performance penalty is for augmenting something with heavy use like IO::Path
16:14 gfldex the dispatcher cache should take care of that
16:15 ugexe Ah, how does augmenting in general impact performance?
16:15 ugexe (not how as in how much, but as in what effects cause any slowdowns)
16:20 gfldex as I understand it it's just .add_method and .compose. Whereby the latter marks the dispatcher cache as dirty.
16:21 gfldex and since it happens at compile time, that should not matter much anyways
16:21 ugexe I wondered if precomp would get disabled or something like that
16:22 gfldex i can't see why it should. Method dispatch is compile time anyways.
16:22 gfldex you don't need MONKEY-* to use the MOP
16:25 ugexe At the very least wouldn't it need to re-precompile things? Like if Foo::Bar has `use XXX`, and later on in the dependency graph `XXX` is augmented
16:27 ugexe I guess if it only affects dispatching then no... but for some reason I thought it affected more than that
16:27 gfldex at least for now augment only allows to add methods
16:33 cognominal joined #perl6-dev
17:32 bartolin joined #perl6-dev
17:38 agentzh joined #perl6-dev
17:54 agentzh joined #perl6-dev
18:36 agentzh joined #perl6-dev
19:45 agentzh joined #perl6-dev
21:42 lizmat m: say Seq ~~ Positional   # shouldn't this be True ?
21:42 camelia rakudo-moar fbe7ac: OUTPUT: «False␤»
21:43 lizmat m: dd Seq.new(^10 .iterator)[5]
21:43 camelia rakudo-moar fbe7ac: OUTPUT: «5␤»
21:44 lizmat .tell jnthn Shouldn't PositionalBindFailover does Positional ?
21:44 yoleaux2 lizmat: I'll pass your message to jnthn.
21:47 IOninja No, because it doesn't support [] willy-nilly.
21:47 IOninja From spec: "The Iterable role implies the ability to support sequential access through iterators. There is also limited support for en-passant use of postcircumfix:<[ ]>, but since some Iterables may only be iterated once, not all Iterables are considered Positiona"
21:47 IOninja l
21:47 IOninja And IIRC PositionalBindFailover makes a List out of a Seq
21:48 IOninja m: sub (@foo) { say WHAT @foo }(1...*)
21:48 camelia rakudo-moar fbe7ac: OUTPUT: «(List)␤»
21:48 lizmat but only internally
21:49 lizmat m: my @a = ^10; say @a.rotate ~~ Positional   # should this be True ?
21:49 camelia rakudo-moar fbe7ac: OUTPUT: «True␤»
21:49 lizmat if @a.rotate returns a Seq, it becomes false
21:49 IOninja m: my $s = (1...*); say $s[0]; say $s[5]; say $s[2]; say $s[0]; say $s[5]; say $s[2];
21:49 camelia rakudo-moar fbe7ac: OUTPUT: «1␤6␤3␤1␤6␤3␤»
21:50 IOninja Oh, I guess it does support willy-nilliness....
21:50 lizmat yes, I think that was one of the outcomes of the GLR
21:50 lizmat that Seq wraps iterators and thus support positional will-nillyness
21:51 IOninja Ah
21:51 lizmat that's why Seq has its own AT-POS
21:51 IOninja s: (1...*), 'AT-POS', \(5)
21:51 SourceBaby IOninja, Sauce is at https://github.com/rakudo/rakudo/blob/fbe7ace/src/core/Seq.pm#L193
21:52 IOninja Ah. I see.
21:54 lizmat the reason I'm asking, is that having List.rotate return a Seq, gives some spectest fallout, one of them is caused by Seq not being Positional
21:58 MasterDuke left #perl6-dev
21:59 MasterDuke joined #perl6-dev
22:01 lizmat I was also thinking that Seq.rotate could work for rotation values >= 0
22:02 lizmat == 0 would just be self
22:02 lizmat >0 would basically a caching skip of N that would be "played" after the original iterator expires
22:02 lizmat rotation values <0 would still need to reify everything first
22:07 Geth ¦ roast: b68190d533 | usev6++ | S29-conversions/ord_and_chr.t
22:07 Geth ¦ roast: Use better ticket for fudge message
22:07 Geth ¦ roast: review: https://github.com/perl6/roast/commit/b68190d533
22:14 jnthn No, Seq should not do Positional
22:14 yoleaux2 21:44Z <lizmat> jnthn: Shouldn't PositionalBindFailover does Positional ?
22:14 jnthn The point of the PositionalBindFailover role is so when we fail to bind a Seq to an argument that wants a Positional, we can resolve it by grabbing the cached thing
22:14 lizmat jnthn: should @a.rotate ~~ Positional be True ?
22:15 jnthn Hm, I forget the return value of rotate, but it's in-place, ain't it?
22:15 lizmat rotate atm returns a List / Array
22:15 lizmat I was trying to make it return a Seq
22:15 jnthn Oh, no, it ain't
22:16 jnthn If it's going to return a Seq then it ain't going to be Positional
22:16 lizmat right, and a spectest then  fails
22:16 lizmat so is the test wrong ?
22:16 jnthn One that explicitly checks for that?
22:16 lizmat yup
22:16 jnthn Well, it depends if we think Seq is a better choice of return type
22:16 lizmat @a.rotate ~~ Positional
22:17 lizmat for rotate values < 0, it doesn't make sense as it needs to reifiy
22:17 jnthn It'd be a bit weird to have .reverse return a Seq and .rotate not, I guess
22:17 jnthn I'd thought .rotate was in-place until I just checked the docs now :)
22:17 lizmat but for rotate values > 0, that would basically be a caching .skip(N) and replay the cache at the end
22:18 jnthn *nod*
22:18 lizmat hence my attempt at making it a Seq
22:19 lizmat and getting that type of spectest fails  :-(
22:20 jnthn If that's the only spectest fail, and given rotate is probably little-used, we can likely get away with considering it errata
22:20 jnthn I don't really fancy having to explain why .reverse returns Seq and .rotate does not :)
22:20 jnthn Feels like the odd one out in that sense
22:21 lizmat well, until recently .reverse didn't return a Seq either  :-)
22:21 jnthn Aye
22:21 lizmat and thunk xx 42 is still problematic  :-(
22:21 jnthn xx should certainly be returning a Seq
22:22 IOninja What makes a Positional Positional? Seq supports .AT-KEY and stuff
22:22 jnthn I think I'd be fine with rotate returning Seq, given we now have reverse that way
22:22 Geth ¦ rakudo/nom: 6060bd38ce | (Elizabeth Mattijsen)++ | src/core/Any-iterable-methods.pm
22:22 Geth ¦ rakudo/nom: Streamline Any.unique
22:22 Geth ¦ rakudo/nom:
22:22 Geth ¦ rakudo/nom: - don't return when doing pull-one
22:22 Geth ¦ rakudo/nom: - don't create native str representation
22:22 Geth ¦ rakudo/nom: - add sink-all
22:22 Geth ¦ rakudo/nom: - makes it a few percent faster
22:22 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/6060bd38ce
22:22 jnthn IOninja: It's the role that goes with the @ sigil
22:22 MasterDuke fwiw, .rotate is used ~25 in the ecosystem
22:23 jnthn So, things that you can consider as array-ish
22:24 jnthn And so stateful
22:24 jnthn Seq is not like this, because it's one-shot
22:24 IOninja OK.
22:25 jnthn Introducing something that was a one-shot Iterable was at the heart of the GLR's eliminating lots of memory retention surprises
22:25 jnthn (Pre-GLR, I - and I suspect most others - found that a hard to reason about.)
22:25 lizmat jnthn: do you consider the PositionalBindFailover a temporary or a final solution ?
22:26 lizmat fwiw, it feels like a temporary solution to me
22:26 jnthn No
22:26 jnthn Heh
22:26 lizmat one that may have an infinite lifetime
22:26 lizmat but still  :-)
22:27 jnthn Well, the alternative was that we hard-coded a list of types into the binder :)
22:28 jnthn And when somebody came along and asked "how do I make a type that behaves like Seq when passed to an @foo" then answer would be "tough luck" :)
22:28 jnthn Sticking a role there means we can see "oh, you just..."
22:28 lizmat ok, I can see that
22:28 lizmat but should Seq be doing that role in the end ?
22:28 jnthn Sure
22:29 jnthn HyperSeq also does it, fwiw
22:30 jnthn Aside from it being open to other types joining the scheme, it's also a bit faster to check for that role than to check for Seq and HyperSeq
22:30 lizmat ack
22:31 jnthn The cases when you'd actually be doing somewhere where you need to implement the role are pretty few and far between :)
22:31 jnthn You'd pretty much have to be implementing your own list-processing paradigm or something
22:32 * jnthn is still pondering whether we'll want a RaceSeq to go with HyperSeq or whether that doesn't want to be type-encoded...
22:34 jnthn On the discussion about augment earlier - I suspect use of augment probably needs to imply "no precompilation"
22:34 lizmat jnthn: wouldn't a RaceIterator not be simply a protected pull-one ?
22:34 lizmat *consist of
22:34 jnthn No
22:35 jnthn Race is just a form of hyper that doens't care about order
22:35 jnthn But it still needs to be involved in the batching and, if we care for it to perform decently, pipelining stuff.
22:36 jnthn (That is, .race.grep(...).map(...) should batch things up and run the map/grep on those things together, not do a fork/join between every stage)
22:37 jnthn The start of a .race just pulls input values using the normal iterator API
22:37 lizmat jnthn: in the case of race, I was more thinking along a RaceIterator with a protected pull-one, being run from N threads at a time
22:38 lizmat with the result being put into a ConcQueue, and a resulting iterator eating off of that
22:38 lizmat wouldn't that allow for minimum overhead ?
22:39 lizmat or maybe this is an altogether different paradigm
22:39 jnthn Sounds perhaps different again
22:39 jnthn I'm not sure where the batching goes in that model
22:39 lizmat there would be no batching
22:40 jnthn I think the model you're suggesting is much more like what the ==> operator is meant to support
22:40 jnthn Where it sets up producer/consumer between the stages
22:41 jnthn And there it would make sense to stick concurrent queues between
22:41 jnthn That's an OK model when the operations are relatively costly
22:42 lizmat so a racy version of ==>  :-)
22:42 jnthn But in .grep(*.some-simple-property) then the cost of communication would dwarf the test
22:43 jnthn Thus the batching under the hyper/race paradigm
22:44 jnthn Hm, yeah, you're right that ==> does care about order
22:44 lizmat jnthn: can't put my finger on it, but it feels over-engineered and a bit klunky still :-)
22:44 jnthn What, the batching?
22:44 lizmat yeah
22:46 lizmat I mean, you're batching values so you can use the single-threaded version of a method on it, and then collect the result again, right ?
22:46 lizmat and you need to offset the batch size with the overhead of setting up / calling the single threaded version of the method
22:48 lizmat but you don't know the setup / calling overhead of every method
22:48 lizmat so your batching size optimum will heavily depend on what you will be doing
22:49 jnthn That's in no small part why we optionally allow the user to pick it, though with time we can do reasonable heuristics on it
22:49 jnthn Also even *then* there's no single right answer
22:49 jnthn Because it's a latency/throughput knob
22:49 lizmat indeed
22:49 lizmat and that's why I'm feeling uneasy with it
22:50 lizmat feels to me we're trying to row against the stream, rather than go with the flow
22:51 lizmat so I was thinking, maybe we need some HyperIterator role that would have a 'process-one' method
22:51 lizmat given a value to process, and return what it is supposed to
22:52 lizmat in the case of a failing grep, an empty slip
22:53 lizmat in the case of a map, some values, possibly a Slip
22:55 jnthn Guess I can only say in my expereince dealing with these things, being able to trade off latency and throughput was the difference between a decent user expereince an an uncceptable wait to first result (in the latency direction) or parallelism being able to win something over sequential for various cases (in the throughput direction)
22:55 jnthn If I'd not be able to pick my preference, I'd just not have been able to apply it in one use-case or the other
22:57 lizmat but isn't that about limiting the resource usage of a race/hyper more than anything else ?
22:57 lizmat and you picking latency / throughput just another way of limiting resource usage ?
22:57 lizmat aka, is that the right knob  :-)
22:58 lizmat wouldn't you need to be able to say: use 50% of CPU maximally, and only 10% of disk IO ?
22:58 lizmat or something like that ?
23:01 jnthn No, it wasn't really resource usage at all that was the issue. It was more that in one case, the computation was producing results that a user was waiting to see, and some data earlier mattered more than all data faster. In the other case the goal was just to chug through the operation ASAP.
23:02 jnthn The batching (also named splitting or partitioning elsewhere) thing is not something I've come up with, fwiw. It's also what things like PLINQ and Java 8 parallel streams, which are in the very same problem space, have to offer.
23:03 lizmat good to know1
23:03 lizmat !
23:03 lizmat grr...  I'm tired, so I probably should discussing parallel things  :-)
23:03 jnthn Prolly Clojure also, but been a good while since I looked at that :)
23:04 jnthn Though they seemed to have quite a nice story in this area also
23:04 jnthn Yeah, I've had a cold this weekend
23:04 jnthn Sore throat, sore ears, headache. Not much fun. :/
23:04 jnthn So should probably go rest that off too
23:04 jnthn Didn't notice it was already midnight...
23:06 lizmat yeah, time flies
23:07 jnthn Doubly so at a weekend, it seems...
23:08 jnthn Anyways, going for another go at sleeping off the coldy thingy. :)
23:08 jnthn 'night
23:10 lizmat nighty night!

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