Perl 6 - the future is here, just unevenly distributed

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

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

All times shown according to UTC.

Time Nick Message
02:32 b2gills joined #perl6-dev
03:58 Zoffix joined #perl6-dev
04:27 astj joined #perl6-dev
04:43 astj joined #perl6-dev
06:08 literal_ joined #perl6-dev
06:51 RabidGravy joined #perl6-dev
07:04 mst joined #perl6-dev
07:27 [Tux] This is Rakudo version 2017.03-24-g43e09022b built on MoarVM version 2017.03-7-g029d1218
07:27 [Tux] csv-ip5xs        3.071
07:27 [Tux] test            12.554
07:27 [Tux] test-t           4.964 - 5.001
07:27 [Tux] csv-parser      12.910
08:21 Geth ¦ roast: 4b081040b1 | (Samantha McVey)++ | S19-command-line/repl.t
08:21 Geth ¦ roast: No functional change, but make REPL tests a bit easier to read
08:21 Geth ¦ roast: review: https://github.com/perl6/roast/commit/4b081040b1
08:26 brrt joined #perl6-dev
08:50 lizmat Files=1180, Tests=55954, 192 wallclock secs (11.65 usr  4.55 sys + 1151.96 cusr 103.22 csys = 1271.38 CPU)
08:50 yoleaux2 22 Mar 2017 23:45Z <Zoffix> lizmat: here's my naive attempt at fixing the phasers in grep(Callable), but I don't know how phasers are handled and so it didn't work (now that I look at it; I don't know why expected it to work in the first place >_<):  https://gist.github.com/zoffixznet/17b8c6ba35ba145c59ae71a766a3c738
08:53 brrt left #perl6-dev
09:01 timotimo i do believe you'd also have to forward the .phasers (or something) to the original block
09:03 lizmat I wonder if we could reliably add phasers at run time to the syntheutic
09:03 lizmat block
09:03 lizmat hmmm...
09:03 timotimo sounds very tricky
09:04 timotimo but i'm not well versed on the phasers
09:04 lizmat yeah, perhaps we need to revert https://github.com/rakudo/rakudo/commit/362f674 and support redo in that setup
09:06 lizmat .tell Zoffix looking at your approach, but perhaps reverting https://github.com/rakudo/rakudo/commit/362f674 and adding redo support there would be a better (and ultimately faster) approach
09:06 yoleaux2 lizmat: I'll pass your message to Zoffix.
10:17 jnthn morning o/
10:34 jnthn Originally, we implemented grep in terms of map, which meant we got all the phaser-y things for free :)
10:34 jnthn (And the slower performance such an approach offers, of course :))
10:45 ZofBot joined #perl6-dev
11:12 jnthn m: https://gist.github.com/jnthn/b9d5f8dd975a1587a9be7c6588c2e7f0
11:12 camelia rakudo-moar 43e090: OUTPUT: «ok 1 - Simple EVAL in a loop does not crash␤»
11:12 jnthn m: https://gist.github.com/jnthn/b9d5f8dd975a1587a9be7c6588c2e7f0
11:12 camelia rakudo-moar 43e090: OUTPUT: «ok 1 - Simple EVAL in a loop does not crash␤»
11:12 jnthn Hmm
11:13 jnthn m: https://gist.github.com/jnthn/b9d5f8dd975a1587a9be7c6588c2e7f0
11:13 camelia rakudo-moar 43e090: OUTPUT: «ok 1 - Simple EVAL in a loop does not crash␤»
11:13 jnthn m: https://gist.github.com/jnthn/b9d5f8dd975a1587a9be7c6588c2e7f0
11:13 camelia rakudo-moar 43e090: OUTPUT: «ok 1 - Simple EVAL in a loop does not crash␤»
11:13 jnthn grr
11:14 masak how dare it not crash!
11:14 masak :P
11:14 jnthn m: https://gist.github.com/jnthn/b9d5f8dd975a1587a9be7c6588c2e7f0
11:14 camelia rakudo-moar 43e090: OUTPUT: «(signal SEGV)»
11:14 jnthn :)
11:14 masak yaaay
11:14 jnthn Yeah, the RT'd example just sat in a loop
11:15 jnthn (Infinite one)
11:15 jnthn But we can't really do that in a test :)
11:15 masak m: https://gist.github.com/jnthn/b9d5f8dd975a1587a9be7c6588c2e7f0
11:15 camelia rakudo-moar 43e090: OUTPUT: «ok 1 - Simple EVAL in a loop does not crash␤»
11:15 masak heh
11:15 masak seems a bit hit-and-miss
11:15 jnthn Yeah, such is life
11:16 jnthn But if it regresses it'll at least show ups as a flappy test and get investigated as such
11:16 jnthn *up
11:16 jnthn Which is better than no test at all
11:16 masak oh, agreed
11:16 masak I wish there was a solid way to turn flappies into failures :P
11:17 jnthn Just run them enough :P
11:18 * jnthn wonders whether it's worth creating a new test file for EVAL being reentrant
11:18 jnthn I'm sure there's more to fix in that area
11:19 masak sounds worth it, then
11:19 * masak .oO( You Arrrgh Gonna Need It )
11:21 samcv can somebody bump nqp and moarvm versions for rakudo to pull in this bug: https://github.com/MoarVM/MoarVM/commit/a00278e611a65292bad2da9f21b3d0b535d4d76d
11:21 samcv i must sleep urgently
11:22 jnthn samcv: Yes, can do
11:22 samcv thx
11:26 Geth ¦ nqp: 0adbb98726 | (Moritz Lenz)++ | tools/build/MOAR_REVISION
11:26 Geth ¦ nqp: Bump MoarVM revision
11:26 Geth ¦ nqp:
11:26 Geth ¦ nqp: ... for a fix for a line ending concatenation bug
11:26 Geth ¦ nqp: review: https://github.com/perl6/nqp/commit/0adbb98726
11:26 Geth ¦ nqp: version bump brought these changes: https://github.com/MoarVM/MoarVM/compare/2017.03-7-g029d1218...2017.03-22-ga00278e
11:27 jnthn oh heh, I'd got it locally but was going to spectest first :)
11:28 jnthn (Need to spectest another local change too)
11:28 moritz jnthn: I'll let you do the rakudo bump then
11:28 jnthn moritz: It's fine, I didn't do that one yet :)
11:29 jnthn So feel free
11:30 Geth ¦ roast: a6949c4579 | (Jonathan Worthington)++ | integration/eval-and-threads.t
11:30 Geth ¦ roast: Add basic test for EVAL in multiple threads.
11:30 Geth ¦ roast: review: https://github.com/perl6/roast/commit/a6949c4579
11:37 Geth ¦ rakudo/nom: 218f8c4600 | (Jonathan Worthington)++ | 3 files
11:37 Geth ¦ rakudo/nom: Fix crash when doing EVAL from multiple threads.
11:37 Geth ¦ rakudo/nom:
11:37 Geth ¦ rakudo/nom: The filename we give goes to make part of the unique Serialization
11:37 Geth ¦ rakudo/nom: Context ID. However, there was a race on producing the EVAL_<n> IDs
11:37 Geth ¦ rakudo/nom: that could lead to the same ID being used twice, thus meaning we did
11:37 Geth ¦ rakudo/nom: not get a unique serialization context and so illegally ended up
11:37 Geth ¦ rakudo/nom: sharing one of them between threads. This fixes the race, and thus
11:37 Geth ¦ rakudo/nom: fixes this source of troubles with concurrent EVAL.
11:37 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/218f8c4600
11:37 Geth ¦ rakudo/nom: e8765d2bdb | (Jonathan Worthington)++ | t/spectest.data
11:37 Geth ¦ rakudo/nom: Run integration/eval-and-threads.t
11:37 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e8765d2bdb
11:38 timotimo hah
11:38 timotimo that's really it? :D
11:38 timotimo that is just a tiny bit hilarious
11:41 jnthn There may be more, but it'll need a bigger EVAL to expose it, it seems :)
11:41 jnthn But yeah, the reported case now seems to run reliably
11:45 lizmat jnthn: wouldn't it be better to make state threadsafe ?
11:45 masak jnthn: huh. surprised at the class-my-method pattern to hide private state ;)
11:45 jnthn No
11:45 robertle joined #perl6-dev
11:45 masak jnthn: (not that it's wrong or anything. it's just I didn't expect to see you create a class with just a static method) :P
11:46 jnthn masak: I coulda made it a module with a sub, I guess :)
11:46 masak in the sense that you're not going near the MOP machinery, yes :)
11:46 masak but... who cares, really
11:47 masak `class` is a shorter keyword than `module` :P
11:47 jnthn lizmat: I did consider that we should clone blocks to things like map/grep in hyper/race so that each thread gets its own "instance" of them, though :)
11:48 jnthn Though perhaps we should make state vars keyed on thread
11:48 jnthn So that state is never shared amongst them
11:48 jnthn But that'd still not work to fix this case
11:49 jnthn Which makes me wonder what cases it *would* fix
11:49 jnthn (To be clear, the race is nothing to do with the state variable, so much as the ++ operation)
11:49 jnthn This goes back to that post I did a while back explaining that the real problem is that you can't magically figure out the transaction scope the programmer might (or might not ;)) have had in mind.
11:50 masak pet peeve of mine when discussing operators: people who explain postfix:<++> as first returning the old value and *then* doing the increment...
11:51 jnthn hehe
11:51 jnthn I know what they mean but...yeah :P
11:51 masak aye
11:52 masak I think that peeve is part of the permanent damage I've inflicted on myself by implementing interpreters and expression parsers
11:54 jnthn Well, it kinda forces you to think more clearly about semantics :)
11:56 masak I believe Algol 68 has a metaoperator that carries out some operator but then returns the old value. that's kind of a generalization of postfix:<++> and postfix:<-->
11:58 lizmat jnthn: would you mind if I changed https://github.com/rakudo/rakudo/commit/218f8c4600 a bit to be more in line with Rakudo::Internals other methods?
11:59 jnthn More in line with in what way?
11:59 lizmat well, normally Rakudo::Internals methods live in src/core/Rakudo/Internals.pm  :-)
11:59 jnthn Oh man
12:00 lizmat I'll take that as a no then  :-)
12:00 jnthn Yeah, that file is becoming a monster
12:00 jnthn I'm fine with stuff used in multiple places going there, of course.
12:00 jnthn But for things used in just one place, it's easier to keep them right next to the point of use, IMHO
12:00 lizmat Well, thinking about that, aren't there more places where we need an reliable monotonically increasing number ?
12:00 jnthn Easier to find them when changing them
12:01 jnthn Maybe, but.. :)
12:01 jnthn If you generalize it, it becomes a class you make instances of
12:01 jnthn But making instances of it means you need to make sure we only get one
12:01 jnthn Which we can do at INIT time I guess
12:01 lizmat well, I was more thinking about a hash :-)
12:02 jnthn A hash?
12:02 lizmat with the "key" being an string indicating for what you want the counter for
12:02 jnthn Then everything that wanted IDs would content on one thing *and* we'd pay the cost of hash lookups ;)
12:02 jnthn *contend
12:02 lizmat ok, fair enough
12:03 jnthn But yeah, we can generalize it if needed
12:03 jnthn And if it gets more than one use, move it
12:03 lizmat let's revisit this when we need an other case of an monotonically increasing number
12:03 jnthn Right :)
12:03 jnthn Premature abstraction is the root of all evil.
12:04 lizmat .oO( Premature abstraction is the meta-root of all evil. )
12:04 jnthn hah :)
12:04 * masak .oO( Premature complexification is the root of -1 )
12:04 jnthn Oh, other reason I worry less about sticking it in Rakudo/Internals.pm is that we actually ahve proper file/line numbers for CORE.setting things :)
12:05 jnthn Before it was more of a pain to find stuff
12:05 jnthn I think I'm gradually settling on us having HyperSeq, RaceSeq, and some role done by all of Seq, HyperSeq, and RaceSeq that factors out their commonalities
12:06 lizmat do you find my prototype at all useful ?
12:07 jnthn At the very least it's useful for the questions it asks :)
12:07 jnthn I hadn't through about `for` much before it
12:08 jnthn Also the LAST issue is...telling
12:08 lizmat one thought I had this morning:
12:08 jnthn And unique also
12:08 lizmat suppose we cehave a .hyper.map.grep.map sequen
12:08 lizmat suppose we have a .hyper.map.grep.map sequence
12:08 lizmat and the grep has a FIRST or LAST phaser in it
12:09 lizmat then the grep would need to be done serially (apart from the fact it doesn't atm, but am looking at that)
12:09 lizmat it would be nice if somehow that fact would not stop the next map to be concurrent again
12:10 jnthn I don't think it forces serialization of the whole thing
12:10 lizmat well, it does in my prototype, atm
12:10 jnthn But yes, we must make absolutely sure that the FIRST runs on the correct value
12:11 lizmat but the LAST can never be run 100% correctly
12:11 lizmat unless we support a "back-up one" option in iterators
12:11 lizmat or a "peek-one"
12:12 jnthn Yeah, this is one place race is easier than hyper :)
12:13 jnthn I think an approach based on "just delegate to the sequential version in batches" is probably not going to fly
12:13 jnthn Which implicates not only your prototype, but also the hyper map impl I already did in CORE.setting
12:14 jnthn What I do think we might be able to do is identify common patterns
12:14 jnthn In terms of the "nature" of the operation
12:15 lizmat yeah, I guess basically Any-iterable needs an Hyper-iterable counterpart
12:16 jnthn One pattern would be "use the sequential operation, but then allow us to proceed in parallel with further steps"
12:16 jnthn Which we can actually do for most things while we flesh the implementations out
12:17 jnthn Another would be a simple "do it on the batches", which covers simple cases of map/grep without any FIRST/LAST
12:18 lizmat yeah, that part is covered :-)
12:18 jnthn Yet another would be "do some work on the batches, but then do a follow-up shared step"
12:18 jnthn unique is like that
12:18 jnthn You can unique things in batches
12:18 jnthn But you then have to merge the seen hashes and re-unique them
12:18 lizmat yeah, and then further unique it down
12:18 jnthn And share out the updated merge for the next round
12:18 lizmat problem is that you might lose order then
12:18 jnthn squish is similar: you can do it in batches but need to also consider the join points
12:19 lizmat or maybe not
12:19 lizmat yeah, squish is clear
12:19 jnthn I *think* you could arrange it so that not
12:19 jnthn Things like sort are also interesting
12:19 jnthn In that if it's the transform kind, then you can do the mapping out in parallel
12:20 lizmat yeah, actually, unique would be first parallel, then take the result and serial that
12:20 lizmat could use the current impl of .unique for that
12:20 jnthn *nod*
12:20 jnthn Anyway, I think it's fairly we'll need the freedom to do things on a per-operation basis
12:20 lizmat actually, a simple implementation of .squish could do the same
12:21 lizmat but it wouldn't be optimal  :-)
12:21 lizmat agree
12:21 lizmat repeated would take the same approach as .unique
12:22 lizmat categorize / classify are interesting cases  :-)
12:22 jnthn Also though, looking at my sheet, hyper and race have significant differences
12:22 jnthn Those two actually aren't too bad at all
12:22 jnthn Interesting, but they parallelize pretty well :)
12:22 jnthn It's just that you have to merge hashes
12:22 jnthn And, with hyper, respect order
12:24 jnthn That's one of the cases where, like map/grep, hyper and race mostly differ only in respecting original order when assembling stuff
12:24 jnthn But we have cases like .reduce where the implementations will look entirely different.
12:25 jnthn .reduce in hyper ends up being "just inherit reduce"
12:25 jnthn .reduce in race can batch
12:26 jnthn Thus my feeling we want HyperSeq and RaceSeq so we can dispatch differently on these behaviors
12:26 jnthn I can't quite bring myself to call the role that shares stuff between them and Seq "Seqqy" :P
12:27 lizmat Concurrent ?
12:27 timotimo yeah, also don't call it seqsi
12:27 lizmat hmmm...
12:27 jnthn No, because it's for Seq as well :)
12:27 jnthn Which is not concurrent
12:27 lizmat perhaps Seq should change its name in the first place
12:27 jnthn Rat does the Rational role
12:27 lizmat because it is not a ... sequence
12:27 jnthn So we could go with Sequence
12:27 lizmat per se
12:28 jnthn It's a sequence of values
12:28 jnthn :)
12:28 jnthn Depends how you define sequence I guess :)
12:28 jnthn It's not the same meaning as "sequence operator" though
12:28 jnthn So yeah, Sequence is probably a bad name for it also :)
12:28 lizmat indeed, hence calling them both "sequence" proves to be confusing to teach
12:29 jnthn I'd probably just say "seq" :)
12:29 lizmat and cause problem on case insensitive file systems ?
12:29 jnthn No, I meant when teaching :)
12:29 lizmat ah
12:29 jnthn I'd call the Seq type exactly that
12:30 jnthn And be careful not to pluralize :P :P
12:30 jnthn Anyway, we can probably use Seqqy as a working name and TimToady++ can tell us what it should be called :-)
12:31 timotimo IteratorCombinators
12:31 lizmat fwiw, sometimes I wonder whether we shouldn't get rid of Seq altogether and make Iterator beefier
12:31 jnthn (For the shared role, I mean)
12:31 jnthn But a Seq is not an Iterator :)
12:31 jnthn And you never actually see the Iterator type
12:32 jnthn Part of the reason we wrap things up in Seq is so that we don't end up with a huge proliferation of user-facing type names.
12:32 lizmat I know that, but in many cases I've found myself asking a Seq for its iterator and then work with that down the chain
12:32 jnthn That's what we do with all Iterables :)
12:32 * jnthn remembers ListIter, GatherIter, MapIter, RangeIter... :-)
12:33 lizmat we have 165 Seq.new's in core
12:33 jnthn And the moment we leak those out, is the moment we can't refactor them internally, as we have to great benefit
12:33 lizmat that's true
12:34 lizmat so I wonder whether hyper / race processing should have to deal with Seq's at all
12:34 lizmat maybe it should all be iterators on the inside
12:34 lizmat only when we expose to the outside world again, does it become a Seq again
12:34 jnthn When you say .hyper or .race you get back *something*
12:34 jnthn That has to be some type
12:34 lizmat true, in my prototype a ConcurrentChain
12:35 jnthn And that type is how we know to chain
12:35 lizmat but is it a Seq ?
12:36 jnthn No
12:36 jnthn HyperSeq or RaceSeq or whatever we choose to call those types
12:36 jnthn I'm not attached to them having Seq in their name
12:36 lizmat HyperChain / RaceChain
12:37 jnthn That's an implementation detail rather than how you can consume it, though
12:37 lizmat SerialChain   # for ==> processing
12:37 lizmat concurrent ==> processing
12:37 jnthn ==> we have more leeway on because it's syntax :)
12:37 jnthn A set of ==> joined things could evaluate to Nil, and we just thunk each step and pass it off to something
12:38 jnthn So I don't know we even need a type there :)
12:38 lizmat but each step could have its own worker thread, no ?
12:38 jnthn Yes, that's the idea
12:39 jnthn It's a way to write producer/consumer pipelines
12:39 Geth ¦ rakudo/nom: a123eb310e | (Moritz Lenz)++ | tools/build/NQP_REVISION
12:39 Geth ¦ rakudo/nom: Bump NQP revision to get \r\n fix
12:39 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a123eb310e
12:39 Geth ¦ rakudo/nom: version bump brought these changes: https://github.com/perl6/nqp/compare/2017.03-10-g17212d21...2017.03-12-g0adbb98
12:39 jnthn Where you know that each step is only going to run on a single thread.
12:40 jnthn Unlike hyper/race where you map closure could run on a bunch of them
12:40 jnthn *your
12:41 lizmat foo ==> hyper.bar ==> @a
12:41 Woodi .uniq is funny :)  with .grep you split seqs into parallel things, grep them and work on the rest and join. with .uniq reducing in separate strims is not enough - it is needed to add another .uniq after .join... if there is more ops like .uniq we would better check if they obey ops algebra, is it legal to swap ops order
12:41 jnthn Woodi: https://docs.google.com/spreadsheets/d/1kpSb8LoskHSbM1FQvWdQ269rlRkU8vh5A_ElpN3Qay4/edit?usp=sharing contains plenty of thinking on this :)
12:42 jnthn I guess I kinda like Seq in the name of the hyper/race "monad" types in that once people know what a Seq is (a thing you can put in a one-shot pipeline) it sets up a decent expectation for that HyperSeq and RaceSeq are
12:42 Woodi but some work after .uniq and before .join is wasted on not globally unique elements...
12:43 jnthn Especially given that while they may work in parallel and work ahead to get you answers faster, it's still the final sinking or iteration at the end of the chain that actually makes any work happen.
12:44 Woodi jnthn: saw that. and I not get what "delegate to cache" means...
12:44 lizmat The only danger of Seq is that if you work too much with them, you start dreaming about Seqs
12:44 jnthn Is that a bad thing? :P
12:44 geekosaur if you stare too long into the Seq...
12:44 lizmat ah well, it's just like 6 in German  :-)
12:44 jnthn Woodi: The .cache method
12:45 jnthn Woodi: Which caches the result
12:45 jnthn So you can do stuff like .map(...)[1,5,3] or so
12:45 jnthn This is nothing new to hyper/race stuff; it's what Seq already does
12:45 jnthn So all it's really saying is "same as for the sequential case" :)
12:47 jnthn Ooops, forgot lunch :)
12:47 * jnthn should go have that :)
12:47 jnthn bbi30
13:01 awwaiid joined #perl6-dev
13:12 Zoffix .ask [Coke] how is your bootstrapification of docs.perl6.org coming along? I'm reviewing some of the IO grant changes that will be done and feels like some of the documentation that will be written would benefit from `"6.d language"` tag in docs. If the site is bootstrapified, I could give a stab and initial language tagging mechanism for the docs...
13:12 yoleaux2 Zoffix: I'll pass your message to [Coke].
13:13 Zoffix .tell [Coke] *and add tagging I meant...
13:13 yoleaux2 Zoffix: I'll pass your message to [Coke].
13:22 skids joined #perl6-dev
13:23 lizmat jnthn: any thoughts about the use of ConcBlockingQueue in my prototype?  the mechanism that you know how many IterationEnd's you're going to receive to determine whether to nqp::shift() on the queue or not?
13:24 lizmat afk for some schlepping&
13:24 * jnthn back
13:24 jnthn Still pondering that part :)
13:33 [Coke] .
13:33 yoleaux2 13:12Z <Zoffix> [Coke]: how is your bootstrapification of docs.perl6.org coming along? I'm reviewing some of the IO grant changes that will be done and feels like some of the documentation that will be written would benefit from `"6.d language"` tag in docs. If the site is bootstrapified, I could give a stab and initial language tagging mechanism for the docs...
13:33 yoleaux2 13:13Z <Zoffix> [Coke]: *and add tagging I meant...
13:35 [Coke] Zoffix: it's stalled at the moment. Because we have Pod::To::HTML in the mix, it's not a simple "change the template" drop in. and I kept getting distracted by other shiny stuff. I'm happy to share my branch in progress, but will not be offended if you take it over or do something else.
13:35 [Coke] I won't be able to put more time on it until April at this point.
13:36 Zoffix [Coke]: alright. So far, I don't think I have much interest in taking it over :)
13:37 Zoffix I don't think I could survive the bikeshedding and public opinion of the work when it gets merged. The bootstrappification of perl6.org was enough for me :P
13:41 [Coke] Zoffix: yah, i wasn't looking forward to that part.
13:41 [Coke] It's still on my list, though; it's blocking about a dozen other things I want to do with the site.
13:41 jnthn Started a gist where I'm collecting together various hyper/race thoughts: https://gist.github.com/jnthn/6a80a9712fb38b32537f9f0e46fca6d7
14:10 Woodi i wonder is hyper
14:11 Woodi grr... race very simple, just map done few times...
14:11 Woodi and is hyper subclass of hyper ? as a kind of behaviour not type
14:12 Woodi and do GPU integration need to be consideret atm ?
14:13 Woodi *subclass of race...
14:14 jnthn No, I don't think they want a subclass relationship
14:14 jnthn It's not clear to me which way around they'd go
15:02 lizmat jnthn: they share sink-all semantics  :-)
15:03 * [Coke] is so sad, he broke his recently-found-again Perl 6 pen.
15:03 jnthn lizmat: True-ish-maybe-kinda :)
15:03 [Coke] (snapped off the clip)
15:04 jnthn lizmat: I think I've got something of a step forward, trying to write it up coherently now :)
15:05 lizmat [Coke]: sorry to hear that, but we don't have any Perl 6 pens anymore ourselves  :-(
15:06 [Coke] I'm happy to order a few dozen if you ever re-stock. :)
15:07 [Coke] btw, please tell wendy I have her marketing sheet printed out on my office door. :)
15:07 lizmat [Coke]: will keep that in mind  :-)
15:08 lizmat 👍
15:08 lizmat afkj again&
15:47 Zoffix lizmat: speaking of which... if there are any more Perl 6 marketing brochures/flyers that need to be made, I have all the resources to do that....
16:04 * Zoffix emails requesting a quote for bus shelter ad
16:04 Zoffix Dunno how much it'll be, but it'd be a fun way to spice up my commute :D
16:05 Zoffix For a Perl 6 ad that is
16:05 Zoffix Like this one: http://www.sambrookmedia.com/newsambrookimages/Brampton-Self-Promo-TSA-Trinity_1_1.jpg
16:06 DrForr My last place ran one, I took a picture of one I found in Edinburgh.
16:07 Zoffix For Perl 6? :o
16:08 DrForr No, unfortunately.
16:10 Zoffix Hm, found some site with pricing for an adjacent city... Cheapest option is $625 canukistan dollars for 1 panel for 1 month :o
16:11 * Zoffix can think of better things to do with that money heh
16:14 geekosaur advertising a programming language on a bus shelter seems ... odd
16:15 geekosaur (barring fully commercial ones maybe, e.g. matlab --- but even then I'd expect them to aim higher)
16:15 DrForr Now on the Tube...
16:16 Zoffix geekosaur: yeah, it was more for fun really, but I'm not spending half a grand for fun :)
16:17 Zoffix This looks handy to use for our flappers: http://blogs.perl.org/users/ovid/2017/03/saving-your-test-suite-history.html
16:18 Zoffix .oO( build something like that to TAP::Harness... )
16:24 [Coke] Zoffix: yah, I could see throwing a few dozen bucks at that level of fun, but not much more.
16:28 DrForr Good way to induce Python graffiti and a new nasty meme.
16:29 Zoffix lol
16:29 Zoffix I highly doubt it'd see Python graffiti :P
16:30 DrForr I would hope not either, but these things have a way of just happening.
16:32 jnthn lizmat: On https://gist.github.com/jnthn/6a80a9712fb38b32537f9f0e46fca6d7 I've sketched out a design that might just work (probably will want some refinement as we implement)
16:34 jnthn lizmat: It retains the kind of ConcurrentActionator model where we give it the set of things to coordinate
16:34 jnthn lizmat: But generalizes it to a fork/join model which I believe will be sufficiently flexible to compose the various operations we need out of
16:35 jnthn And also will keep concurrency control largely in that coordinator.
16:43 * jnthn should probably take a rest for a bit :)
16:59 [Coke] Sequencetial! (*cringe*)
17:21 Zoffix m: ".".IO.pipe
17:21 camelia rakudo-moar a123eb: OUTPUT: «No such method 'pipe' for invocant of type 'IO::Handle'␤  in block <unit> at <tmp> line 1␤␤»
17:22 Zoffix Wonder what that's supposed to be. Delegates to IO::Handle.pipe, but it ain't got such a method...
17:31 * Zoffix types "man pipe" into the terminal... I hope there are no pictures...
17:34 Zoffix Added on Oct 30, 2014 as an intermediate step... And I don't see a Proc.pm file in that era.
17:35 * Zoffix assumes .pipe was meant to do the piping behaviour of Perl 5's open, but that stuff has been subsumed by Proc now
17:36 geekosaur I think you want to look at IO::Pipe?
17:36 geekosaur which indeed is supposed to be generated via Proc
17:37 geekosaur but I don't see this pipe method in docs for either IO::Handle or IO::Path, so no idea what it's supposed to be
17:37 geekosaur the other possibility is that it's supposed to relate to POSIX fifos, but in that case perhaps it should be punted to ecosystem
17:38 Zoffix I'll just mark it for deletion. It hasn't worked for 3 years and no one noticed :)
17:39 Zoffix Ah
17:40 Zoffix c: 2014.12 say "cal".IO.pipe.lines
17:40 committable6 Zoffix, ¦2014.12: «     March 2017        Su Mo Tu We Th Fr Sa             1  2  3  4    5  6  7  8  9 10 11   12 13 14 15 16 17 18   19 20 21 22 _␈2_␈3 24 25   26 27 28 29 30 31                             »
17:40 Zoffix Indeed, Proc does this stuff now.
17:40 geekosaur maybe it's a convenience method wrapping Proc (likely if it's using IO::Pipe)
17:41 geekosaur c: 2014.12 say "cal".IO.pipe.WHAT
17:41 committable6 geekosaur, ¦2014.12: «(IO::Handle)»
17:41 geekosaur hm, 2014 might predate IO::Pipe
17:41 Zoffix The commit for it reads "This basically exposes flaws in the current setup: an IO::Path is supposed to be a path on a file system."
17:42 geekosaur c: 2014.12 say "/usr/bin/cal".IO.pipe.lines #`{ look, a path :p }
17:42 committable6 geekosaur, ¦2014.12: «     March 2017        Su Mo Tu We Th Fr Sa             1  2  3  4    5  6  7  8  9 10 11   12 13 14 15 16 17 18   19 20 21 22 _␈2_␈3 24 25   26 27 28 29 30 31                             »
17:43 Zoffix c: 2014.12 say "cal | grep ar".IO.pipe.lines
17:43 committable6 Zoffix, ¦2014.12: «     March 2017        »
17:43 Zoffix heh
17:43 Zoffix .tell AlexDaniel the whateverables aren't that secure with RESTRICTED:   c: 2014.12 say "cal | grep ar".IO.pipe.lines
17:43 yoleaux2 Zoffix: I'll pass your message to AlexDaniel.
17:46 geekosaur I think that's a known shortcoming and AlexDaniel has complained about it before
18:00 Zoffix ZOFVM: Files=1230, Tests=132930, 125 wallclock secs (22.15 usr  3.43 sys + 2398.72 cusr 271.95 csys = 2696.25 CPU)
18:02 Geth ¦ rakudo/nom: a01d6794d2 | (Zoffix Znet)++ | src/core/IO/Path.pm
18:02 Geth ¦ rakudo/nom: [io grant] Remove IO::Path.pipe
18:02 Geth ¦ rakudo/nom:
18:02 Geth ¦ rakudo/nom: Appears to be vestigial, functionality replaced by Proc.
18:02 Geth ¦ rakudo/nom: No tests. No docs. And has been broken since pre-Christmas.
18:02 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a01d6794d2
18:24 AlexDaniel joined #perl6-dev
19:08 FROGGS joined #perl6-dev
19:39 Zoffix RabidGravy: what do you mean an "unchanged test failure"?
19:39 Zoffix A failure in a test I didn't change?
19:40 Zoffix RabidGravy: there's a failure in t/090-ua-ssl.t
19:40 RabidGravy yes
19:40 Zoffix That my PR doesn't fix
19:40 RabidGravy right
19:40 RabidGravy I think the test is wrong, but nothing has changed
19:41 Zoffix Other than Rakudo version?
19:42 Zoffix Or a change on httpbin.org
19:42 RabidGravy but I can't see how it ever threw the exception it is expecting
19:43 Zoffix Ah
19:43 Zoffix Just tried it on 2017.01-144-gf2894d3 and it fails there too
19:44 RabidGravy Hmm it must be be the response then
19:44 Zoffix But maybe it didn't throw it in the past and the test was just always skipped due to ::SSL not installed?
19:47 * Zoffix &
19:49 RabidGravy I think that it's the SSL
19:59 lizmat was https://medium.com/rubyinside/the-new-absent-operator-in-ruby-s-regular-expressions-7c3ef6cd0b99#.dapvisde1 already mentioned here ?
20:00 timotimo yup, an hour ago or so?
20:00 timotimo might have been longer
20:00 timotimo it was in my backlog in any case
20:00 timotimo 15:30 my-local-time
20:01 timotimo which iirc is your-local-time
20:01 timotimo over in #perl6
20:01 timotimo BBIAB
20:23 * lizmat is tired and gets an early night
20:50 AlexDaniel joined #perl6-dev
20:59 AlexDaniel .
20:59 yoleaux2 17:43Z <Zoffix> AlexDaniel: the whateverables aren't that secure with RESTRICTED:   c: 2014.12 say "cal | grep ar".IO.pipe.lines
21:00 AlexDaniel Zoffix: they have never been secure, I know
21:00 AlexDaniel RESTRICTED setting doesn't prevent anything anyway
21:00 AlexDaniel for the last week I've been trying to come up with a solution to this… but it's a bit complicated
21:01 timotimo froggs once put a security thingie into moar
21:01 AlexDaniel it should be executed with seccomp filters for sure, but there are other things that have to be done on top of that
21:02 AlexDaniel firejail seemed like a very easy way to accomplish this, but it seems to be a bit limited and not built for this purpose
21:03 AlexDaniel so yeah, thanks for your report… but yeah :(
21:03 AlexDaniel I'll get it done eventually
21:03 RabidGravy Zoffix, I merged that PR and todo'd the failing test temporarily
21:14 Zoffix RabidGravy++
21:32 Zoffix m: IO::Handle.^lookup("comb").file.say; IO::Handle.^lookup("split").file.say
21:32 camelia rakudo-moar a01d67: OUTPUT: «No such method 'file' for invocant of type 'Mu'␤  in block <unit> at <tmp> line 1␤␤»
21:32 Zoffix huh
21:33 Zoffix c: 1132b1a IO::Handle.^lookup("comb").file.say
21:33 committable6 Zoffix, ¦1132b1a: «No such method 'file' for invocant of type 'Mu'␤  in block <unit> at /tmp/ZixFE3aBGD line 1␤ «exit code = 1»»
21:33 Zoffix zoffix@VirtualBox:~$ perl6 -e 'IO::Handle.^lookup("comb").file.say'
21:33 Zoffix SETTING::src/core/IO/Handle.pm
21:33 Zoffix zoffix@VirtualBox:~$ perl6 -v
21:33 Zoffix This is Rakudo version 2017.03-17-g1132b1a built on MoarVM version 2017.03
21:33 Zoffix dafuq?
21:34 Zoffix What I was originally wanting to point out is that IO::Handle.^lookup("split").file.say points to Mu.pm, even though the method is in IO/Handle.pm, but now the .comb is messed too somehow
21:34 Zoffix m: IO::Handle.^lookup("split").file.say
21:34 camelia rakudo-moar a01d67: OUTPUT: «SETTING::src/core/Mu.pm␤»
21:34 jnthn Is it a multi, with a proto in Mu?
21:35 Zoffix Ah, wait, the missing `comb` is the restricted bot...
21:38 Zoffix hm
21:38 Zoffix m: IO::Handle.^lookup("split").candidates».file.say
21:38 camelia rakudo-moar a01d67: OUTPUT: «()␤»
21:39 AlexDaniel samcv: if I'm getting “should eventually be unreachable” thingy in my code, what does it mean?
21:39 Zoffix jnthn: hm, looks like indeed it's due to the proto. Looks like I need to make a big update to map.perl6.party :)
21:40 Zoffix dammit
21:41 Zoffix And in the code for it, I use 1 `.file` for all the ».candidates >_<
21:49 Zoffix oh, actually not that major a change; I'll still have the same number of routines, it's just the filenames for some of them will change
22:32 benchable6 joined #perl6-dev
22:32 committable6 joined #perl6-dev
22:32 evalable6 joined #perl6-dev
22:32 bisectable6 joined #perl6-dev
22:32 unicodable6 joined #perl6-dev
22:32 statisfiable6 joined #perl6-dev
22:36 committable6 joined #perl6-dev
22:36 bisectable6 joined #perl6-dev
22:36 benchable6 joined #perl6-dev
22:36 unicodable6 joined #perl6-dev
22:36 evalable6 joined #perl6-dev
22:36 statisfiable6 joined #perl6-dev
22:37 bloatable6 joined #perl6-dev
22:41 AlexDaniel heh, full screen of bots rejoining… sorry for that :)
22:45 Zoffix AlexDaniel: what does bloatable do?
22:45 Zoffix bloatable6: help
22:45 bloatable6 Zoffix, Like this: bloatable6: f583f22,HEAD # See wiki for more examples: https://github.com/perl6/whateverable/wiki/Bloatable
22:46 timotimo Zoffix: are you in #moarvm? AD posted a few examples there
22:48 Zoffix Ah. I see.
23:14 skids joined #perl6-dev
23:24 llfourn joined #perl6-dev
23:56 Zoffix t/spec/S05-modifier/ignorecase.rakudo.moar                      (Wstat: 0 Tests: 36 Failed: 0)
23:56 Zoffix TODO passed:   32, 36
23:56 Zoffix Files=1230, Tests=132930, 527 wallclock secs (11.47 usr  5.54 sys + 1498.16 cusr 341.13 csys = 1856.30 CPU)
23:57 Zoffix I notice the test uses `.pick($_)` I would suggest that it doesn't so it doesn't flops like that
23:57 Zoffix Predictable data in tests rules
23:58 Zoffix Sidenote: that stresstest PASS is after deleting 15 methods from IO::Handle :P
23:59 Zoffix (not gonna commit, part of IO Plan; it was just easier to do it this way than figuring out if these have any tests)

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