[Tux] t/p5_to_p6.t .................. ok 07:52
# Failed test 'at least one destructor ran'
Inline::Perl5 failed
This is Rakudo version 2016.10-40-g4fc17df built on MoarVM version 2016.10-15-g715e39a 07:55
csv-ip5xs 3.312
test 15.290
test-t 7.098
csv-parser 17.608
lizmat drops a pin 09:56
yoleaux2 09:04Z <jnthn> lizmat: I suspect that shouldn't fail at all, but just end the iteration
DrForr yo.
lizmat odd... I don't see jnthn's .tell in irclog.perlgeek.de/perl6-dev/2016-10-24 09:57
moritz: ^^^
moritz lizmat: me meinther 10:42
*neither
jnthn Oh
'cus I .tell'd it in #moarvm :)
Which is where the bot relayed it to me :) 10:43
lizmat ah, that's the reason, *phew* :-)
jnthn: was that about the :ov case ?
not sure what it referred to specifically
jnthn The thing I replied to was about :nth :) 10:45
lizmat ok, so :nth(Mu) is acceptable as a way to say :nth(Any) ? 11:08
brrt cross-talking bots :-o 11:09
dalek p: 0244a14 | (Pawel Murias)++ | t/serialization/02-types.t:
Test serializing an object which has native attributes with default values.
nqp: 88df898 | (Pawel Murias)++ | src/vm/js/ (7 files):
nqp: [js] Use a special value for nqp::null_s() instead of using the native javascript null.
jnthn m: say 'omg'.match(/./, :nth(1|2)) 11:10
camelia rakudo-moar 4fc17d: OUTPUTĀ«any(ļ½¢oļ½£, ļ½¢mļ½£)ā¤Ā»
jnthn I'd assume it's accpeting Any
And that lets us auto-thread things like the above
lizmat m: say 'omg'.match(/./, :nth(Mu)) 11:11
camelia rakudo-moar 4fc17d: OUTPUTĀ«ļ½¢oļ½£ā¤Ā»
jnthn o.O
lizmat this used to fail
jnthn That's fine by me
lizmat not failing now
jnthn Most things die if you give them a Mu
When they'd want an Any
Any is, after all, the default parameter type
Precisely so things auto-thread 11:12
lunch; bbiab
lizmat m: multi a(:$nth!) { dd $nth }; multi a(*%_) { dd "fallback" }; a(:nth(Mu)) # jnthn: do you consider this behaviour correct or is it a bug ? 12:25
camelia rakudo-moar 4fc17d: OUTPUTĀ«"fallback"ā¤Ā»
jnthn Looks correct to me 12:28
lizmat but the :nth has an !
yet that candidate is not selected
jnthn It doesn't type-match 12:29
m: multi a(Mu :$nth!) { dd $nth }; multi a(*%_) { dd "fallback" }; a(:nth(Mu))
camelia rakudo-moar 4fc17d: OUTPUTĀ«Mu $nth = Muā¤Ā»
lizmat ah, ok
jnthn The default parameter type is Any
lizmat gotcha 12:30
jnthn (This is what lets junction auto-threading work out)
lizmat yeah... but it was a bit of a WAT that it didn't select the candidate I thought it would
m: multi a(Mu :$nth!) { dd $nth }; multi a(*%_) { dd "fallback" }; a(:nth(1|2)) 12:31
camelia rakudo-moar 4fc17d: OUTPUTĀ«Junction $nth = any(1, 2)ā¤Ā»
lizmat apparently the Mu doesn't stop it from being selected ?
ah, no
duh
m: multi a(:$nth!) { dd $nth }; multi a(*%_) { dd "fallback" }; a(:nth(1|2)) 12:32
camelia rakudo-moar 4fc17d: OUTPUTĀ«Int $nth = 1ā¤Int $nth = 2ā¤Ā»
lizmat hmmm... how can I quickly determine if a value is Mu ?
jnthn Exactly Mu?
lizmat yup 12:33
jnthn ===
Or nqp::eqaddr if you need really fast
Since type objects don't exist in duplicate
ilmari m: Mu === Mu 12:34
camelia rakudo-moar 4fc17d: OUTPUTĀ«WARNINGS for <tmp>:ā¤Useless use of "===" in expression "Mu === Mu" in sink context (line 1)ā¤Cannot resolve caller infix:<===>(Mu, Mu); none of these signatures match:ā¤ ($?)ā¤ (\a, \b)ā¤ (Int:D \a, Int:D \b)ā¤ (int $a, int $b)ā¤ (Nuā€¦Ā»
lizmat m: use nqp; sub a(Mu \a) { say nqp::eqaddr(\a,Mu) }; a Mu
camelia rakudo-moar 4fc17d: OUTPUTĀ«0ā¤Ā»
lizmat argh
m: use nqp; sub a(Mu \a) { say nqp::eqaddr(a,Mu) }; a Mu
camelia rakudo-moar 4fc17d: OUTPUTĀ«1ā¤Ā»
lizmat ok
jnthn Ah, right, === wants to auto-thread :) 12:35
m: say Mu =:= Mu
camelia rakudo-moar 4fc17d: OUTPUTĀ«Trueā¤Ā»
jnthn That does it though
m: say Mu =:= Any
camelia rakudo-moar 4fc17d: OUTPUTĀ«Falseā¤Ā»
dalek kudo/nom: 46abb3b | lizmat++ | src/core/Cursor.pm:
Streamline Cursor a bit + new features

  - streamline Bool using nqp only
  - move bulk of MATCH into !MATCH so that if the Cursor already has
   a Match object, it can return quickly and be inlined
  - create STR method: return Str for cursor without need of Match object
  - create FROMLEN method: return Pair with from position and length
   without the need of a Match object
lizmat jnthn: ok, so let me recap the situation: 12:37
in a bit :-) 12:38
jnthn hehe ;)
jnthn tries to use that bit to get $dayjob task done
lizmat - Str.match(/./, :nth() ) correctly autothreads 12:39
- Str.match( /./, :nth(Mu) ) doesn't die, but ignores the parameter as if it is an :U 12:40
the latter behaviour is tested against and the only error in roast atm 12:41
to be able to fix this, I would have to add quite a few nqp::eqaddr(,Mu) checks
which wouldn't be in hot code paths, but since we call Str.match so many times, would probably be noticeable anyway 12:42
so my feeling is to not fix this case
if the check is to see if it autothreads, it should check that, no?
jnthn We actaully test that you can pass :nth(Mu)? 12:43
lizmat dies-ok { "a" ~~ m:nth(Mu)/a/ }, ':nth does not accept Mu param'; 12:44
in t/spec/S05-modifier/counted-match.t
we test that you can't pass Mu :-) 12:45
at the moment you can
jnthn Oh 12:46
But that's fine, no?
I don't really understand what's wrong with leaving :$nth taking Any
uh, having Any as its type
And letting junction auto-threading fall out of the dispatch, as usual 12:47
I'm guessing the code is detecting Junction as a special case today?
lizmat no: it falls out of not selecting that candidate and then being caught by another candidate
and then being ignored because of using nqp::defined() 12:48
so, when you specify a junction on nth, it uses that candidate, and all is hunky dory
if you specify Mu, it falls to another candidate in *%_ 12:49
and I'm using low level nqp on %_ for performance reasons
but that then gets ignored because type objects are ignored in the code, and Mu is a type object (aka nqp::defined check) 12:51
so the only thing wrong is that a hard :nth(Mu) doesn't die
dalek kudo/nom: 1b95636 | lizmat++ | src/core/Str.pm:
Implement Str.match( :return(:r) )

Not sure this should be documented as a public adverb, but it will be used internally for .comb and .subst so that we don't need to do a
  .map on the result of a Str.match.
Possible values are:
  - :r(Match) # default, return Match object(s)
  - :r(Str) # return Str object(s)
  - :r(Pair) # return Pair objects, where the key is the position
   # in the string, and the value is the number of chars
f09b8b7 | lizmat++ | src/core/Str.pm: Decommission Str.simplematch
Because the equivalent Str.match is 10% faster.		 12:55
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Streamline Cursor a bit + new features 13:19
travis-ci.org/rakudo/rakudo/builds/170115815 github.com/rakudo/rakudo/compare/4...abb3b79ebf
dalek ast: 46147a0 | lizmat++ | S32-str/comb.t:
Fix faulty Str.comb(Regex,$limit) tests
 13:27
ast/6.c-errata: ea55ffe | lizmat++ | S32-str/comb.t:
Fix faulty Str.comb(Regex,$limit) tests
 13:29
kudo/nom: 1794328 | lizmat++ | src/core/Str.pm:
Make Str.comb(Regex) about 7x faster

Because we don't need to do an additional mapping from Match objects to Str anymore.		 13:30
kudo/nom: 1c67e3b | lizmat++ | src/core/Str.pm:
Merge :global and :g in Str.subst

Not sure why they were separated, but they needn't be now		 13:52
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Implement Str.match( :return(:r) ) 13:55
travis-ci.org/rakudo/rakudo/builds/170120977 github.com/rakudo/rakudo/compare/4...956369ab70 13:56
dalek kudo/nom: c9a24d9 | lizmat++ | src/core/Str.pm:
Replace :return(:$r) with :object(:$ob)

To prevent confusion with the :ratchet(:$r) parameter		 14:09
lizmat jnthn TimToady: thoughts about adding the :object(:ob) to the list of allowable adverbs in m// ? 14:25
jnthn What does it do?
lizmat it determines the type of object returned 14:26
:object(Str) will give you strings
:object(Match) will give you Match objects (default)
:object(Pair) will give you Pairs with from/length info
:object(Str) is now internally used for .comb(Regex) 14:27
jnthn Was gonna say, isn't that form just called .comb... :) 14:28
lizmat not needing to do a .map *.Str made things quite a lot faster
github.com/rakudo/rakudo/commit/1794328cfb 14:29
jnthn I'm fairly sure TimToady won't be OK with the name :object... :)
lizmat well, initially I had :return(:$r), but that conflicts with :ratchet(:$r)
jnthn Yeah 14:30
lizmat alternately :return(:$re) could be misconstrued as well
perlpilot_ lizmat: Maybe :type(:$t) ?
cygx if nothing else, it would come in handy when moving from p5 to p6 14:31
cf gist.github.com/cygx/9c94eefdf6300...nch-pl-L25 vs gist.github.com/cygx/9c94eefdf6300...nch-p6-L21
lizmat yep 14:32
:type(:$t) could work for me
doesn't seem to have any clashes
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Decommission Str.simplematch
travis-ci.org/rakudo/rakudo/builds/170121601 github.com/rakudo/rakudo/compare/1...9b8b7b8a04
buggable [travis build above] āœ“ All failures are due to timeout (1), missing build log (0), or GitHub connectivity (0). All failures are on JVM only.
lizmat jnthn: do you think TimToady would be more inclined towards :type(:$t) ? 14:33
jnthn Well, it's less bad at least. :)
What's the use-case for the Pair? 14:34
lizmat some cases of subst
the cases that use $m.from and $m.pos 14:35
jnthn Are the pairs really much cheaper to construct that a Match? 14:36
I can believe strings are...
dalek kudo/nom: e472420 | lizmat++ | src/core/Str.pm:
Make my @a = Str.match(...) about 5% faster

By supplying custom push-all methods in the iterators		 14:37
jnthn (Asking 'cus otherwise it becomes an adverb tht's just about "give me strings")
lizmat well, that I don't know 14:38
there's code in Cursor.MATCH to create a Match object if there isn't one in the Cursor yet
I'm not sure when that code fires 14:39
but it is expensive
in simple cases, the Cursor appears to have a Match object already, so then it doesn't matter much
jnthn Ah, I guess it creates all the recursive matching structure 14:40
lizmat github.com/rakudo/rakudo/blob/nom/...sor.pm#L50
jnthn Is this used in cases with a literal replacement?
lizmat jnthn: I didn't really get to the subst part yet
I've only done .match so far 14:41
cygx :as might work as another colour for this bikeshed: m:g:as(Str)/.../ 14:42
could return a Range as well...
lizmat cygx: thing is you can't plug that right into a nqp::substr 14:43
you can into a substr() but... hmmmm
maybe Range should be another option then :-) 14:44
would only be minor additional overhead
cygx: fwiw, I'm warming up to :as 15:03
cygx glad to be of service 15:16
jnthn likes it more than type also, fwiw
perlpilot fwiw, I like :as too :) 15:18
timotimo .o( and its long form, :ass ) 15:28
lizmat jnthn: adding it as a adverb in m:as(Str)// would probably have to wait until 6.d , no? 15:43
perlpilot timotimo: :assign(:ass(:$as)) # that works ;-) 15:44
timotimo :) 15:46
dalek kudo/nom: aaec517 | lizmat++ | src/core/ (2 files):
Bikeshed :ob to :as

As discussed at irclog.perlgeek.de/perl6-dev/2016-...i_13456755 Also add support for :as(Range)		 15:49
cygx it's abviously short for :assemble
nope, I did not just google a list of words starting in ass*, looing for one that might fit ;)
*looking 15:50
perlpilot cygx: then clearly, :avg :ass is "avengers assemble" and not any of the other myriad possibilities :) 15:57
timotimo autobots assemble! 15:58
jdv79_ are there decepticons involved? 16:02
lizmat wouldn't know how they look :-) 16:03
dalek ast: 7dcf397 | lizmat++ | S05-modifier/counted-match.t:
Modify implicit check for support of junctions
 16:08
ast/6.c-errata: 711ff7e | lizmat++ | S05-modifier/counted-match.t:
Modify implicit check for support of junctions
 16:10
lizmat spectest should be error free again
afk& 16:33
lizmat back again 16:41
gfldex lizmat: does Str.subst use the new .match code already?
lizmat gfldex: yes, it does, but no further optimizations yet 16:42
gfldex stays tuned
lizmat gfldex: did you find a bug? or is it a lot faster already? :-)
gfldex the needle didn't move at all 16:43
lizmat :-(
but not surprising, looking at the overhead
cygx: how would you feel about some code changes in the Perl 6 version of the benchmark? 16:50
cygx lizmat: it would depend on the changes in question 16:56
the p5 and p6 versions are supposed to stay close to each other
lizmat ok, if that's the idea 16:57
it's just that the "split on string" feels very p5ish 16:58
cygx if you have a version that is more idiomatic p6/performs significantly better, there's nothing stopping us from adding another variant
lizmat I probably would have written that as %words = $input.split("\t") or so
I probably would have written that as %words = $input.split(("\t","\n")) or so 17:00
gfldex m: 'a;b,c'.split("\t"|"\n").say 17:01
camelia rakudo-moar aaec51: OUTPUTĀ«any((a;b,c), (a;b,c))ā¤Ā»
lizmat no, not | but (,)
you can specify a list of Str needles 17:02
gfldex i would have guessed that to work. But then I don't understand Junction.
lizmat looks good to me
neither the \t or the \n matched, so it returned the whole string in either case of the junction
cygx X::Hash::Store::OddNumber ;) 17:03
gfldex m: 'a;b,c'.split(";"|",").say
camelia rakudo-moar aaec51: OUTPUTĀ«any((a b,c), (a;b c))ā¤Ā»
lizmat m: say "a:b,c".split(":"|",")
camelia rakudo-moar aaec51: OUTPUTĀ«any((a b,c), (a:b c))ā¤Ā»
lizmat m: dd "a:b,c".split(":"|",")
camelia rakudo-moar aaec51: OUTPUTĀ«any(("a", "b,c"), ("a:b", "c"))ā¤Ā»
gfldex i somehow feel that .split should collaps the Junction and DWIM. 17:05
lizmat m: my %h = "a:b,c:d".split(<: ,>); dd %h
camelia rakudo-moar aaec51: OUTPUTĀ«Hash %h = {:a("b"), :c("d")}ā¤Ā»
cygx lizmat: .split(("\t", "\n", :skip-empty) takes 6,25s on my machine
*6.25s
lizmat as opposed to 7.56 before? 17:07
gfldex I expect somewhere in .split to be some operator that returns Bool to decide if a codepoint is a separator or not and thus swollows that Junction, resulting in DWIMiness. 17:08
cygx yes, 7.56s is the current value for the line-by-line addition to the hash using split 17:09
lizmat dinner& 17:10
gfldex Thinking about it a little longer the current behaviour makes sense too. "Either split by ',' or split by ';' and return the superposition.", would reflect the quantum-magic that is Junction. 17:11
I would like to query opinions tho, before I doc that. 17:12
lizmat if you do .split( a|b ), then you will get a junction of the result of .split(a) and .split(b) 17:13
if you do a .split(<a b>), you get the equivalent of .split( /a|b/ ), but faster
gfldex That leave the question what I can do with that Junction. Be design I wont get the two components out of it. 17:14
lizmat eating&
cygx m: say "abcd".match(/(.)(.)/, :g, :as(Str)).perl 17:18
camelia rakudo-moar aaec51: OUTPUTĀ«("ab", "cd")ā¤Ā»
gfldex m: dd ('a;b,c'.split(";"|",") (>=) ('a', 'b,c'))
camelia rakudo-moar aaec51: OUTPUTĀ«any(Bool::True, Bool::False)ā¤Ā»
gfldex m: dd so ('a;b,c'.split(";"|",") (>=) ('a', 'b,c'))
camelia rakudo-moar aaec51: OUTPUTĀ«Bool::Trueā¤Ā»
cygx is there (or should there be) a way to get something like (("a", "b"), ("c", "d")) out of it?
ie just the captures instead of the string corresponding to the whole match 17:19
gfldex m: dd ('a;b,c'.split(";"|",") eqv ('a', 'b,c')) 17:20
camelia rakudo-moar aaec51: OUTPUTĀ«any(Bool::True, Bool::False)ā¤Ā»
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Make my @a = Str.match(...) about 5% faster 17:54
travis-ci.org/rakudo/rakudo/builds/170147598 github.com/rakudo/rakudo/compare/c...7242070252
FROGGS o/ 18:31
lizmat FROGGS \o 18:32
and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2016/10/24/...ning-star/ 19:04
fwiw, I didn't mention the :as functionality yet 19:06
m: say "1234567890".subst(/(.).(.)/, "xxx") # captures are useless in this case, perhaps we should warn or throw for that ? 19:14
camelia rakudo-moar aaec51: OUTPUTĀ«xxx4567890ā¤Ā»
perlpilot Maybe someone wants to set $0 and $1 en passant of subst 19:16
AlexDaniel looks at the graph. One axis is marked ā€œsecondsā€, another is ā€œmonthsā€. Hmmmmā€¦ 19:17
But yeah, it is pretty cool. cygx++
lizmat perlpilot: yeah, good point :-) 19:18
but that implies that .Match objects will always have to be made for .subst :-( 19:19
m: say "1234567890".subst(/(.).(.)/, "xxx"); dd $0, $1 19:20
camelia rakudo-moar aaec51: OUTPUTĀ«xxx4567890ā¤Match.new(ast => Any, list => (), hash => Map.new(()), orig => "1234567890", to => 1, from => 0)ā¤Match.new(ast => Any, list => (), hash => Map.new(()), orig => "1234567890", to => 3, from => 2)ā¤Ā»
lizmat m: say "1234567890".subst(/(.).(.)/, "xxx"); say $0, $1
camelia rakudo-moar aaec51: OUTPUTĀ«xxx4567890ā¤ļ½¢1ļ½£ļ½¢3ļ½£ā¤Ā»
cygx AlexDaniel: fixed 19:28
AlexDaniel cygx: oh, wow! Did not expect that 19:30
thanks
nine Lexical module loading does have its tricky corner cases. Like class Foo { use Foo::Bar; ... } Where the lexically imported package stub "Foo" shadows the class we're currently declaring. 19:32
Which means that merging the loaded module's globals is no longer a merge of one hash into another but has to take all the nested scopes into account when looking for existing symbols. 19:33
It also means that we are gonna leak: class Foo { { use Foo::Bar; } { #`( Foo::Bar will still be available here, as it's added to the same Foo we can still see) } } 19:35
A rather unfortunate consequence of nested names meaning real nested packages.
AlexDaniel cygx: perhaps I am hypersensitive to that kind of stuff. Just a few minutes ago stumbled upon this: www.incose.org/images/default-sourc...e-1991.jpg 19:36
nine AlexDaniel: that is one strange (and presumably broken) graph 19:37
AlexDaniel nine: too bad the number of member is not around 2000 19:38
s* 19:39
lizmat goes to check out the lions in Amsterdam # www.imdb.com/title/tt4291700/
[Coke] assumes the bottom is supposed to be the year, up by-one, except they showed the y value instead of the x? (I'll let them slide on the weird choice of y values to call out on the axis) 19:40
nine AlexDaniel: ok, it's not broken :) Nevertheless strange
[Coke]: I think it's days
AlexDaniel days? What? 19:41
surprisingly, the number of days since 1991 is pretty close to the number of members :D 19:43
nine But it's a bit too many to fit between 1991 and 2015-12 19:44
[Coke] nine: the numbers aren't monotonically increasing. 19:47
also, the last number is the highlighted # of members.
cygx
.oO( there's an xkcd for that: xkcd.com/833/ )
 19:49
FROGGS AlexDaniel: the x axis is labeled with the number of members, and each column is one year 19:51
so the labeling is just weird
(it is 25 items on the x axis)
AlexDaniel it has been 15 minutes since I posted that link, why are we still discussing it? :D 19:52
FROGGS sorry, dunno :o)
cygx slow news day?
nine Beats trying to fix merge_globals_lexically ;)
FROGGS I'm compiling moar on qemu/mips... so I've got a loooooooooot of time right now 19:53
AlexDaniel it's also interesting that there is some room for negative numbersā€¦ 19:55
hm, or maybe not. I'm not sure where is the bottom on that graph
0, 400, 1400, ā€¦, 9400, 10000. Interesting. 19:57
[Coke] yah, that is a super weird choice, but doesn't misrepresent anything. 20:00
nine ==> Successfully installed panda 20:34
On lexical_module_loading :)
dalek kudo/lexical_module_load: 9ee5a77 | niner++ | src/Perl6/World.nqp:
Fix: use Foo::Bar; class Foo { my Foo::Bar $bar; } not finding Foo::Bar

A lexically imported package stub was replaced instead of upgraded when a class of the same name was declared.
kudo/lexical_module_load: 78621ec | niner++ | src/Perl6/ModuleLoader.nqp:
Fix: class Foo { use Foo::Bar; my Foo $foo; } not finding Foo

The lexically imported "Foo" package stub containing "Bar" shadowed the
  "Foo" class we're currently declaring. Fix by considering all scopes
when looking for existing symbols, not just the one we're importing into.		 20:36
cygx has it happened to anyone else that an object doesn't smatmatch against a role it does? 20:43
nqp::eqaddr(nqp::decont($m.^roles[1]), Algebraic) is 1, but $m ~~ Algebraic is False 20:44
there isn't really anything fancy going on, except that role and class are defined in different modules 20:46
RT #129957 21:12
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129957
AlexDaniel cygx: just want to note that it has always been like this, it's not a regression 21:19
(committable output: gist.github.com/Whateverable/c5570...87525d5cb9 ) 21:20
FROGGS m: say Str ~~ Stringy
camelia rakudo-moar aaec51: OUTPUTĀ«Trueā¤Ā»
FROGGS m: say Int ~~ Stringy
camelia rakudo-moar aaec51: OUTPUTĀ«Falseā¤Ā»
FROGGS m: say "foo" ~~ Stringy 21:21
camelia rakudo-moar aaec51: OUTPUTĀ«Trueā¤Ā»
FROGGS strange
AlexDaniel FROGGS: why?
FROGGS that it does not work with use'd roles... 21:22
AlexDaniel but Int is not Stringy, isn't it?
FROGGS that's correct 21:24
I was saying that rakudo thinks that '$m ~~ Algebraic' isnt true is weird 21:25
cygx the failure is present when using nqp::istype, which maps to MVM_6model_istype 21:30
that's above my paygrade
timotimo hm, i think there's a type check cache somewhere. but why would that be faulty? 21:31
cygx just speculating, but if I read it correctly, the cache gets filled during deserialization 21:39
then, simple pointer equality is used to lok for the type object
can something go wrong there (ie the cache containing a stale pointer or something)
timotimo the cache should have all its pointers kept up to date through a gc_mark function 21:44
cygx o/ 22:24
dalek ast: dfb9e21 | (Tom Browder)++ | README.md:
correct typo
 23:07
timotimo tbrowder: did you see my stuff to make "write big file.p6" or what it's called a whole bunch faster? 23:11
tbrowder timotimo: no, on the repo? i'll go check... 23:12
timotimo no, it was here on irc and i think i tried to .tell you? maybe i didn't, maybe i just highlighted you 23:14
tbrowder timotimo: where are yr comments?
timotimo give me a moment
can't find it in the irclog :o 23:15
tbrowder i have planned to try nativecall readline but haven't gotten there yet 23:16
timotimo there we have it. i'll grab a link now
tbrowder ok!
timotimo irclog.perlgeek.de/perl6/2016-10-22#i_13448046 - this line and like 20 lines later 23:17
why didn't this line show up when i searched for "nick: timotimo, text: tbrowder" >:(
tbrowder timotimo: i'll have to digest those comments, but my main concern had been the slow read times. to me, those are the real show stoppers, although i need to show the create times, too. 23:22
timotimo right
tbrowder btw, any ideas on direction for efforts on the iperl6 project? 23:24
timotimo "please oh god someone please just do something"? :)
tbrowder seems to me a good start would be to just translate the iperl5 efforts, except i haven't found the zero* api yet. 23:26
i just think, since you started the project, putting public your thoughts on a plan would be good for us PR people to follow instead of blasting off into unknown territory. 23:29
timotimo oof 23:31
i really should write something out, shouldn't i ... 23:32
for now i'm really tired, let's hope tomorrow brings tuits 23:33
tbrowder i have some round ones to spare... 23:54

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!