[Tux] This is Rakudo version 2017.03-24-g43e09022b built on MoarVM version 2017.03-7-g029d1218 07:27
csv-ip5xs 3.071
test 12.554
test-t 4.964 - 5.001
csv-parser 12.910
Geth roast: 4b081040b1 | (Samantha McVey)++ | S19-command-line/repl.t
No functional change, but make REPL tests a bit easier to read
 08:21
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 >_<): gist.github.com/zoffixznet/17b8c6b...a766a3c738
timotimo i do believe you'd also have to forward the .phasers (or something) to the original block 09:01
lizmat I wonder if we could reliably add phasers at run time to the syntheutic 09:03
block
hmmm...
timotimo sounds very tricky
but i'm not well versed on the phasers 09:04
lizmat yeah, perhaps we need to revert github.com/rakudo/rakudo/commit/362f674 and support redo in that setup
.tell Zoffix looking at your approach, but perhaps reverting 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.
jnthn morning o/ 10:17
Originally, we implemented grep in terms of map, which meant we got all the phaser-y things for free :) 10:34
(And the slower performance such an approach offers, of course :))
m: gist.github.com/jnthn/b9d5f8dd975a...6588c2e7f0 11:12
camelia ok 1 - Simple EVAL in a loop does not crash
jnthn m: gist.github.com/jnthn/b9d5f8dd975a...6588c2e7f0
camelia ok 1 - Simple EVAL in a loop does not crash
jnthn Hmm
m: gist.github.com/jnthn/b9d5f8dd975a...6588c2e7f0 11:13
camelia ok 1 - Simple EVAL in a loop does not crash
jnthn m: gist.github.com/jnthn/b9d5f8dd975a...6588c2e7f0
camelia ok 1 - Simple EVAL in a loop does not crash
jnthn grr
masak how dare it not crash! 11:14
:P
jnthn m: gist.github.com/jnthn/b9d5f8dd975a...6588c2e7f0
camelia (signal SEGV)
jnthn :)
masak yaaay
jnthn Yeah, the RT'd example just sat in a loop
(Infinite one) 11:15
But we can't really do that in a test :)
masak m: gist.github.com/jnthn/b9d5f8dd975a...6588c2e7f0
camelia ok 1 - Simple EVAL in a loop does not crash
masak heh
seems a bit hit-and-miss
jnthn Yeah, such is life
But if it regresses it'll at least show ups as a flappy test and get investigated as such 11:16
*up
Which is better than no test at all
masak oh, agreed
I wish there was a solid way to turn flappies into failures :P
jnthn Just run them enough :P 11:17
jnthn wonders whether it's worth creating a new test file for EVAL being reentrant 11:18
I'm sure there's more to fix in that area
masak sounds worth it, then 11:19
masak .oO( You Arrrgh Gonna Need It )
samcv can somebody bump nqp and moarvm versions for rakudo to pull in this bug: github.com/MoarVM/MoarVM/commit/a0...b535d4d76d 11:21
i must sleep urgently
jnthn samcv: Yes, can do 11:22
samcv thx
Geth nqp: 0adbb98726 | (Moritz Lenz)++ | tools/build/MOAR_REVISION
Bump MoarVM revision

  ... for a fix for a line ending concatenation bug		 11:26
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...2-ga00278e
jnthn oh heh, I'd got it locally but was going to spectest first :) 11:27
(Need to spectest another local change too) 11:28
moritz jnthn: I'll let you do the rakudo bump then
jnthn moritz: It's fine, I didn't do that one yet :)
So feel free 11:29
Geth roast: a6949c4579 | (Jonathan Worthington)++ | integration/eval-and-threads.t
Add basic test for EVAL in multiple threads.
 11:30
rakudo/nom: 218f8c4600 | (Jonathan Worthington)++ | 3 files
Fix crash when doing EVAL from multiple threads.

The filename we give goes to make part of the unique Serialization Context ID. However, there was a race on producing the EVAL_<n> IDs that could lead to the same ID being used twice, thus meaning we did not get a unique serialization context and so illegally ended up sharing one of them between threads. This fixes the race, and thus fixes this source of troubles with concurrent EVAL.		 11:37
rakudo/nom: e8765d2bdb | (Jonathan Worthington)++ | t/spectest.data
Run integration/eval-and-threads.t
timotimo hah 11:38
that's really it? :D
that is just a tiny bit hilarious
jnthn There may be more, but it'll need a bigger EVAL to expose it, it seems :) 11:41
But yeah, the reported case now seems to run reliably
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 ;)
jnthn No
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
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 :)
but... who cares, really
`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 :)
Though perhaps we should make state vars keyed on thread 11:48
So that state is never shared amongst them
But that'd still not work to fix this case
Which makes me wonder what cases it *would* fix 11:49
(To be clear, the race is nothing to do with the state variable, so much as the ++ operation)
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.
masak pet peeve of mine when discussing operators: people who explain postfix:<++> as first returning the old value and *then* doing the increment... 11:50
jnthn hehe 11:51
I know what they mean but...yeah :P
masak aye
I think that peeve is part of the permanent damage I've inflicted on myself by implementing interpreters and expression parsers 11:52
jnthn Well, it kinda forces you to think more clearly about semantics :) 11:54
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:56
lizmat jnthn: would you mind if I changed github.com/rakudo/rakudo/commit/218f8c4600 a bit to be more in line with Rakudo::Internals other methods? 11:58
jnthn More in line with in what way? 11:59
lizmat well, normally Rakudo::Internals methods live in src/core/Rakudo/Internals.pm :-)
jnthn Oh man
lizmat I'll take that as a no then :-) 12:00
jnthn Yeah, that file is becoming a monster
I'm fine with stuff used in multiple places going there, of course.
But for things used in just one place, it's easier to keep them right next to the point of use, IMHO
lizmat Well, thinking about that, aren't there more places where we need an reliable monotonically increasing number ?
jnthn Easier to find them when changing them
Maybe, but.. :) 12:01
If you generalize it, it becomes a class you make instances of
But making instances of it means you need to make sure we only get one
Which we can do at INIT time I guess
lizmat well, I was more thinking about a hash :-)
jnthn A hash? 12:02
lizmat with the "key" being an string indicating for what you want the counter for
jnthn Then everything that wanted IDs would content on one thing *and* we'd pay the cost of hash lookups ;)
*contend
lizmat ok, fair enough
jnthn But yeah, we can generalize it if needed 12:03
And if it gets more than one use, move it
lizmat let's revisit this when we need an other case of an monotonically increasing number
jnthn Right :)
Premature abstraction is the root of all evil.
lizmat
.oO( Premature abstraction is the meta-root of all evil. )
 12:04
jnthn hah :)
masak .oO( Premature complexification is the root of -1 )
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 :)
Before it was more of a pain to find stuff 12:05
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
lizmat do you find my prototype at all useful ? 12:06
jnthn At the very least it's useful for the questions it asks :) 12:07
I hadn't through about `for` much before it
Also the LAST issue is...telling 12:08
lizmat one thought I had this morning:
jnthn And unique also
lizmat suppose we cehave a .hyper.map.grep.map sequen
suppose we have a .hyper.map.grep.map sequence
and the grep has a FIRST or LAST phaser in it
then the grep would need to be done serially (apart from the fact it doesn't atm, but am looking at that) 12:09
it would be nice if somehow that fact would not stop the next map to be concurrent again
jnthn I don't think it forces serialization of the whole thing 12:10
lizmat well, it does in my prototype, atm
jnthn But yes, we must make absolutely sure that the FIRST runs on the correct value
lizmat but the LAST can never be run 100% correctly 12:11
unless we support a "back-up one" option in iterators
or a "peek-one"
jnthn Yeah, this is one place race is easier than hyper :) 12:12
I think an approach based on "just delegate to the sequential version in batches" is probably not going to fly 12:13
Which implicates not only your prototype, but also the hyper map impl I already did in CORE.setting
What I do think we might be able to do is identify common patterns 12:14
In terms of the "nature" of the operation
lizmat yeah, I guess basically Any-iterable needs an Hyper-iterable counterpart 12:15
jnthn One pattern would be "use the sequential operation, but then allow us to proceed in parallel with further steps" 12:16
Which we can actually do for most things while we flesh the implementations out
Another would be a simple "do it on the batches", which covers simple cases of map/grep without any FIRST/LAST 12:17
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"
unique is like that
You can unique things in batches
But you then have to merge the seen hashes and re-unique them
lizmat yeah, and then further unique it down
jnthn And share out the updated merge for the next round
lizmat problem is that you might lose order then
jnthn squish is similar: you can do it in batches but need to also consider the join points
lizmat or maybe not 12:19
yeah, squish is clear
jnthn I *think* you could arrange it so that not
Things like sort are also interesting
In that if it's the transform kind, then you can do the mapping out in parallel
lizmat yeah, actually, unique would be first parallel, then take the result and serial that 12:20
could use the current impl of .unique for that
jnthn *nod*
Anyway, I think it's fairly we'll need the freedom to do things on a per-operation basis
lizmat actually, a simple implementation of .squish could do the same
but it wouldn't be optimal :-) 12:21
agree
repeated would take the same approach as .unique
categorize / classify are interesting cases :-) 12:22
jnthn Also though, looking at my sheet, hyper and race have significant differences
Those two actually aren't too bad at all
Interesting, but they parallelize pretty well :)
It's just that you have to merge hashes
And, with hyper, respect order
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
But we have cases like .reduce where the implementations will look entirely different.
.reduce in hyper ends up being "just inherit reduce" 12:25
.reduce in race can batch
Thus my feeling we want HyperSeq and RaceSeq so we can dispatch differently on these behaviors 12:26
I can't quite bring myself to call the role that shares stuff between them and Seq "Seqqy" :P
lizmat Concurrent ? 12:27
timotimo yeah, also don't call it seqsi
lizmat hmmm...
jnthn No, because it's for Seq as well :)
Which is not concurrent
lizmat perhaps Seq should change its name in the first place
jnthn Rat does the Rational role
lizmat because it is not a ... sequence
jnthn So we could go with Sequence
lizmat per se
jnthn It's a sequence of values 12:28
:)
Depends how you define sequence I guess :)
It's not the same meaning as "sequence operator" though
So yeah, Sequence is probably a bad name for it also :)
lizmat indeed, hence calling them both "sequence" proves to be confusing to teach
jnthn I'd probably just say "seq" :) 12:29
lizmat and cause problem on case insensitive file systems ?
jnthn No, I meant when teaching :)
lizmat ah
jnthn I'd call the Seq type exactly that
And be careful not to pluralize :P :P 12:30
Anyway, we can probably use Seqqy as a working name and TimToady++ can tell us what it should be called :-)
timotimo IteratorCombinators 12:31
lizmat fwiw, sometimes I wonder whether we shouldn't get rid of Seq altogether and make Iterator beefier
jnthn (For the shared role, I mean)
But a Seq is not an Iterator :)
And you never actually see the Iterator type
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
jnthn That's what we do with all Iterables :)
jnthn remembers ListIter, GatherIter, MapIter, RangeIter... :-)
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
lizmat that's true
so I wonder whether hyper / race processing should have to deal with Seq's at all 12:34
maybe it should all be iterators on the inside
only when we expose to the outside world again, does it become a Seq again
jnthn When you say .hyper or .race you get back *something*
That has to be some type
lizmat true, in my prototype a ConcurrentChain
jnthn And that type is how we know to chain 12:35
lizmat but is it a Seq ?
jnthn No 12:36
HyperSeq or RaceSeq or whatever we choose to call those types
I'm not attached to them having Seq in their name
lizmat HyperChain / RaceChain
jnthn That's an implementation detail rather than how you can consume it, though 12:37
lizmat SerialChain # for ==> processing
concurrent ==> processing
jnthn ==> we have more leeway on because it's syntax :)
A set of ==> joined things could evaluate to Nil, and we just thunk each step and pass it off to something
So I don't know we even need a type there :) 12:38
lizmat but each step could have its own worker thread, no ?
jnthn Yes, that's the idea
It's a way to write producer/consumer pipelines 12:39
Geth rakudo/nom: a123eb310e | (Moritz Lenz)++ | tools/build/NQP_REVISION
Bump NQP revision to get \r\n fix
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....2-g0adbb98
a01d6794d2 | (Zoffix Znet)++ | src/core/IO/Path.pm

Appears to be vestigial, functionality replaced by Proc. No tests. No docs. And has been broken since pre-Christmas.
jnthn Where you know that each step is only going to run on a single thread.
Unlike hyper/race where you map closure could run on a bunch of them 12:40
*your
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
jnthn Woodi: docs.google.com/spreadsheets/d/1kp...sp=sharing contains plenty of thinking on this :)
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...
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:43
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
jnthn Is that a bad thing? :P
geekosaur if you stare too long into the Seq...
lizmat ah well, it's just like 6 in German :-)
jnthn Woodi: The .cache method
Woodi: Which caches the result 12:45
So you can do stuff like .map(...)[1,5,3] or so
This is nothing new to hyper/race stuff; it's what Seq already does
So all it's really saying is "same as for the sequential case" :)
Ooops, forgot lunch :) 12:47
jnthn should go have that :)
bbi30
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].
Zoffix .tell [Coke] *and add tagging I meant... 13:13
yoleaux2 Zoffix: I'll pass your message to [Coke].
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:23
afk for some schlepping& 13:24
jnthn back
Still pondering that part :)
[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:13Z <Zoffix> [Coke]: *and add tagging I meant...
[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
I won't be able to put more time on it until April at this point.
Zoffix [Coke]: alright. So far, I don't think I have much interest in taking it over :) 13:36
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:37
[Coke] Zoffix: yah, i wasn't looking forward to that part. 13:41
It's still on my list, though; it's blocking about a dozen other things I want to do with the site.
jnthn Started a gist where I'm collecting together various hyper/race thoughts: gist.github.com/jnthn/6a80a9712fb3...0e46fca6d7
Woodi i wonder is hyper 14:10
grr... race very simple, just map done few times... 14:11
and is hyper subclass of hyper ? as a kind of behaviour not type
and do GPU integration need to be consideret atm ? 14:12
*subclass of race... 14:13
jnthn No, I don't think they want a subclass relationship 14:14
It's not clear to me which way around they'd go
lizmat jnthn: they share sink-all semantics :-) 15:02
[Coke] is so sad, he broke his recently-found-again Perl 6 pen. 15:03
jnthn lizmat: True-ish-maybe-kinda :)
[Coke] (snapped off the clip)
jnthn lizmat: I think I've got something of a step forward, trying to write it up coherently now :) 15:04
lizmat [Coke]: sorry to hear that, but we don't have any Perl 6 pens anymore ourselves :-( 15:05
[Coke] I'm happy to order a few dozen if you ever re-stock. :) 15:06
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
afkj again&
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.... 15:47
Zoffix emails requesting a quote for bus shelter ad 16:04
Dunno how much it'll be, but it'd be a fun way to spice up my commute :D
For a Perl 6 ad that is 16:05
Like this one: www.sambrookmedia.com/newsambrookim...ty_1_1.jpg
DrForr My last place ran one, I took a picture of one I found in Edinburgh. 16:06
Zoffix For Perl 6? :o 16:07
DrForr No, unfortunately. 16:08
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:10
Zoffix can think of better things to do with that money heh 16:11
geekosaur advertising a programming language on a bus shelter seems ... odd 16:14
(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...
Zoffix geekosaur: yeah, it was more for fun really, but I'm not spending half a grand for fun :) 16:16
This looks handy to use for our flappers: blogs.perl.org/users/ovid/2017/03/s...story.html 16:17
.oO( build something like that to TAP::Harness... )
 16:18
[Coke] Zoffix: yah, I could see throwing a few dozen bucks at that level of fun, but not much more. 16:24
DrForr Good way to induce Python graffiti and a new nasty meme. 16:28
Zoffix lol 16:29
I highly doubt it'd see Python graffiti :P
DrForr I would hope not either, but these things have a way of just happening. 16:30
jnthn lizmat: On gist.github.com/jnthn/6a80a9712fb3...0e46fca6d7 I've sketched out a design that might just work (probably will want some refinement as we implement) 16:32
lizmat: It retains the kind of ConcurrentActionator model where we give it the set of things to coordinate 16:34
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
And also will keep concurrency control largely in that coordinator. 16:35
jnthn should probably take a rest for a bit :) 16:43
[Coke] Sequencetial! (*cringe*) 16:59
Zoffix m: ".".IO.pipe 17:21
camelia No such method 'pipe' for invocant of type 'IO::Handle'
in block <unit> at <tmp> line 1
Zoffix Wonder what that's supposed to be. Delegates to IO::Handle.pipe, but it ain't got such a method... 17:22
Zoffix types "man pipe" into the terminal... I hope there are no pictures... 17:31
Added on Oct 30, 2014 as an intermediate step... And I don't see a Proc.pm file in that era. 17:34
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:35
geekosaur I think you want to look at IO::Pipe? 17:36
which indeed is supposed to be generated via Proc
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
the other possibility is that it's supposed to relate to POSIX fifos, but in that case perhaps it should be punted to ecosystem
Zoffix I'll just mark it for deletion. It hasn't worked for 3 years and no one noticed :) 17:38
Ah 17:39
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 »
Zoffix Indeed, Proc does this stuff now.
geekosaur maybe it's a convenience method wrapping Proc (likely if it's using IO::Pipe)
c: 2014.12 say "cal".IO.pipe.WHAT 17:41
committable6 geekosaur, ¦2014.12: «(IO::Handle)»
geekosaur hm, 2014 might predate IO::Pipe
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."
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 »
Zoffix c: 2014.12 say "cal | grep ar".IO.pipe.lines 17:43
committable6 Zoffix, ¦2014.12: « March 2017 »
Zoffix heh
.tell AlexDaniel the whateverables aren't that secure with RESTRICTED: c: 2014.12 say "cal | grep ar".IO.pipe.lines
yoleaux2 Zoffix: I'll pass your message to AlexDaniel.
geekosaur I think that's a known shortcoming and AlexDaniel has complained about it before 17:46
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:00
Zoffix RabidGravy: what do you mean an "unchanged test failure"? 19:39
A failure in a test I didn't change?
RabidGravy: there's a failure in t/090-ua-ssl.t 19:40
RabidGravy yes
Zoffix That my PR doesn't fix
RabidGravy right
I think the test is wrong, but nothing has changed
Zoffix Other than Rakudo version? 19:41
Or a change on httpbin.org 19:42
RabidGravy but I can't see how it ever threw the exception it is expecting
Zoffix Ah 19:43
Just tried it on 2017.01-144-gf2894d3 and it fails there too
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?
Zoffix & 19:47
RabidGravy I think that it's the SSL 19:49
lizmat was medium.com/rubyinside/the-new-abse....dapvisde1 already mentioned here ? 19:59
timotimo yup, an hour ago or so? 20:00
might have been longer
it was in my backlog in any case
15:30 my-local-time
which iirc is your-local-time 20:01
over in #perl6
BBIAB
lizmat is tired and gets an early night 20:23
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
AlexDaniel Zoffix: they have never been secure, I know 21:00
RESTRICTED setting doesn't prevent anything anyway
for the last week I've been trying to come up with a solution to this… but it's a bit complicated
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
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:02
so yeah, thanks for your report… but yeah :( 21:03
I'll get it done eventually
RabidGravy Zoffix, I merged that PR and todo'd the failing test temporarily
Zoffix RabidGravy++ 21:14
m: IO::Handle.^lookup("comb").file.say; IO::Handle.^lookup("split").file.say 21:32
camelia No such method 'file' for invocant of type 'Mu'
in block <unit> at <tmp> line 1
Zoffix huh
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»»
Zoffix zoffix@VirtualBox:~$ perl6 -e 'IO::Handle.^lookup("comb").file.say'
SETTING::src/core/IO/Handle.pm
zoffix@VirtualBox:~$ perl6 -v
This is Rakudo version 2017.03-17-g1132b1a built on MoarVM version 2017.03
dafuq?
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
m: IO::Handle.^lookup("split").file.say
camelia SETTING::src/core/Mu.pm
jnthn Is it a multi, with a proto in Mu?
Zoffix Ah, wait, the missing `comb` is the restricted bot... 21:35
hm 21:38
m: IO::Handle.^lookup("split").candidates».file.say
camelia ()
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 :)
dammit 21:40
And in the code for it, I use 1 `.file` for all the ».candidates >_< 21:41
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 21:49
AlexDaniel heh, full screen of bots rejoining… sorry for that :) 22:41
Zoffix AlexDaniel: what does bloatable do? 22:45
bloatable6: help
bloatable6 Zoffix, Like this: bloatable6: f583f22,HEAD # See wiki for more examples: github.com/perl6/whateverable/wiki/Bloatable
timotimo Zoffix: are you in #moarvm? AD posted a few examples there 22:46
Zoffix Ah. I see. 22:48
t/spec/S05-modifier/ignorecase.rakudo.moar (Wstat: 0 Tests: 36 Failed: 0) 23:56
TODO passed: 32, 36
Files=1230, Tests=132930, 527 wallclock secs (11.47 usr 5.54 sys + 1498.16 cusr 341.13 csys = 1856.30 CPU)
I notice the test uses `.pick($_)` I would suggest that it doesn't so it doesn't flops like that 23:57
Predictable data in tests rules
Sidenote: that stresstest PASS is after deleting 15 methods from IO::Handle :P 23:58
(not gonna commit, part of IO Plan; it was just easier to do it this way than figuring out if these have any tests) 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!