01:47 ilbot3 joined 01:51 geekosaur joined 03:43 geekosaur joined
dalek ast: 478881d | usev6++ | S06-advanced/wrap.t:
Unfudge passing test for rakudo-j
 05:45
06:27 astj joined 06:29 [TuxCM] joined 06:37 RabidGravy joined
[TuxCM] This is Rakudo version 2016.04-15-gb3d8169 built on MoarVM version 2016.04 08:18
test 21.991
test-t 12.387
csv-parser 23.721
08:39 lizmat joined
dalek ast: 4b44fe5 | usev6++ | S06-advanced/wrap.t:
Add ticket number for skipped test (JVM)
 08:53
lizmat jnthn: agree github.com/rakudo/rakudo/pull/754 should be closed and RT'd ? 09:03
rt.perl.org/Ticket/Display.html?id=127968 # problem in sleepsort marcusramberg found yesterday 09:15
09:23 vendethiel joined
timotimo another thing to think about is that with ropes we can in theory handle strings that big; adding individual parts together wouldn't result in the whole thing being allocated; just a little record of what got concatenated 09:23
however, if you've added two strings that add up to 2**32, you've got to have two 2**31 big strings :) 09:24
and we do force ropes to become one flattened string when we regex-match against them
09:40 lizmat joined
lizmat timotimo: wouldn't that by itself cause a slowdown in the use of regexes? 09:42
other question: while looking at RT #127968 09:43
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127968
lizmat is there a reason why Channel.list is not implemented as an Iterator ???
jnthn: ^^^
timotimo i'm not sure what you mean by that?
"that by itself"? 09:44
lizmat well, Channel.list would return a Seq with an Iterator class in which the pull-one would do an nqp::poll ?
rather than first creating a Supply and then taking a list off of that ?
timotimo sorry, i was refering to the previous topic still 09:45
lizmat timotimo: ah, I meant, creating the concatenated string might be already quite expensive
timotimo oh 09:46
well, at 2**32 characters, yeah
you'll be memcpying 2**32 * 4 bytes together
lizmat if it consisted of many ropes
timotimo that can't be fast :)
lizmat I assume nqp::readallfh already creates a single roped string, right ? 09:47
timotimo it should, yeah 09:48
lizmat ?>/|";.,/[plkm,./ 09:51
(that was some chai tea on my keyboard) 09:52
timotimo uh oh! 09:54
lizmat yeah, probably ok 09:55
if I go up in a puff of smoke, you know what happened :-)
timotimo probably makes the keys a bit sticky :| 09:57
lizmat it was sugarless chai (sweetener only), so not too sticky 10:05
and it was only the lower right corner of my keyboard that got hit
timotimo phew 10:26
dalek kudo/nom: 48cc6b5 | lizmat++ | src/core/Channel.pm:
Preliminary fix for RT #127968

I'm not sure why a Channel would need to create a Supply first to be able to create a .list. So I re-imagined Channel.list to be a Seq with a simple Iterator that is polling the Channel. This causes one Channel spectest to fail, but I feel the test is wrong as it apparently assumes there is a Supply underlying Channel.list. Comments / Patches welcome!		 10:36
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127968
bartolin lizmat: RT #127968 was already reported as RT #127960 (which has a backtrace but no details otherwise). I could merge both tickets (and keep your subject) or I could reject the earlier report as a dup. do you have a preference?
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127968
Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127960
timotimo have you looked closely at what the Supply method on Channel does, exactly?
lizmat timotimo: yes, and it is useful in and of itself 10:38
but I'm not sure we need it to create a .list
so you could argue I implemented a work-around yes :-)
bartolin: argh, why didn't I see that in my mail ? 10:39
please merge the two tickets: the stack trace may be useful for someone like jnthn 10:40
bartolin will do
lizmat bartolin++ 10:41
jnthn lizmat: Agree github.com/rakudo/rakudo/pull/754 is the wrong fix, yeah. 11:11
lizmat PR closed 11:12
timotimo there is no such PR as a bad PR :)
clearly, the user must have accidentally run into this problem? 11:13
jnthn yeah
Maybe we should just make our string length 64-bit :P
"Overflow *that*!"
tadzik . o O ( I had trouble reproducing this, my SSD was not big enough to put swap there, but... ) 11:29
lizmat I'm confused now: shouldn't .list not return something listy and isn't a Seq a listy thing ? 11:36
jnthn Seq isn't really list-y enough 11:38
Doesn't bind to @ for one. 11:39
ooh, lunch time :) bbl 11:40
11:45 lizmat joined, astj joined
dalek rakudo/nom: 5a14162 | lizmat++ | src/core/Channel.pm: 11:55
rakudo/nom: Fix test breakage caused by 48cc6b5f469e915333
rakudo/nom:
rakudo/nom: Implements:
rakudo/nom: - Channel.receive-nil-on-close
rakudo/nom: - Channel.iterator
rakudo/nom: - Channel.Seq
rakudo/nom: Re-Implements:
rakudo/nom: - Channel.list
rakudo/nom:
rakudo/nom: Also: RT #127968 was a dup of RT #127960
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127968
lizmat I'm not sure whether receive-nil-on-close shouldn't actually be the default behaviour of Channel.receive
[TuxCM] This is Rakudo version 2016.04-17-g5a14162 built on MoarVM version 2016.04 12:08
test 21.864
test-t 12.765
csv-parser 23.775
12:10 lizmat_ joined
nine_ MadcapJake: subcommands are something that can and should be explored in module space before support is added to core 12:38
MadcapJake nine_: that's true, I make take a stab at my proposed interface above. 13:24
s/make/might/
14:01 hankache joined
lizmat m: class A { multi method a() {}; multi method a(42) {} }; say A.^find_method("a").package # feels like a bug to me 15:04
camelia rakudo-moar 5a1416: OUTPUTĀ«(Dummy)ā¤Ā»
lizmat jnthn: ^^^ expected to see (A) here, really
m: class A { method a() {} }; say A.^find_method("a").package # works 15:05
camelia rakudo-moar 5a1416: OUTPUTĀ«(A)ā¤Ā»
jnthn m: class A { multi method a() {}; multi method a(42) {} }; say A.^lookup('a').candidates[0]>>.package 15:06
camelia rakudo-moar 5a1416: OUTPUTĀ«((A))ā¤Ā»
jnthn m: class A { multi method a() {}; multi method a(42) {} }; say A.^lookup('a').candidates>>.package
camelia rakudo-moar 5a1416: OUTPUTĀ«((A) (A))ā¤Ā»
jnthn The cands themselves are fine
Oh...
It's just the default proto is just cloned from a dummy one
We should tweak its package after cloning it. Probably a 1-line fix. :) 15:07
m: class A { proto method a(|) { * } multi method a() {}; multi method a(42) {} }; say A.^lookup('a').package
camelia rakudo-moar 5a1416: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/CwIQQ9RCxLā¤Strange text after block (missing semicolon or comma?)ā¤at /tmp/CwIQQ9RCxL:1ā¤------> class A { proto method a(|) { * }ā multi method a() {}; multi method a(42)ā¤ expecting any of:ā€¦Ā»
jnthn m: class A { proto method a(|) { * }; multi method a() {}; multi method a(42) {} }; say A.^lookup('a').package
camelia rakudo-moar 5a1416: OUTPUTĀ«(A)ā¤Ā»
jnthn Yeah, fine on an explicit proto too
Just the generated one 15:08
tadzik gist.github.com/tadzik/f2634cfac10...f376499e3c rakudobug? 15:20
I'd expect to get USAGE in both cases
masak tadzik: me too, I think 15:43
tadzik argh, that exception is X::AdHoc :| 15:44
gist.github.com/tadzik/3e32043c3c2...b57c642ac1 15:45
prolly since it's from the binder 15:46
proposed patch: gist.github.com/tadzik/2001b1f3ec4...3655b58ab2 16:03
it can theoretically trigger from user error, is someone literally does "die 'Constraint type bla bla'" from their MAIN, but I'd argue that it does more good than harm
spectests pass, so I'm tempted to go ahead with it and ask for forgviness/mercy later 16:19
nine_ Could the .backtrace[0].subname fail somehow? 16:21
tadzik you mean: yield a false positive?
nine_ More like do we always have a backtrace and does the first element always have a .subname?
tadzik ah 16:22
Backtrace::Frame always has a .subname
and I don't think we can have a backtrace with 0 frames in any case 16:23
moritz? 16:26
moritz uhm 16:28
there are filtered views on backtraces
they can certainly be empty
if you look at all the magic in AT-POS, it is certainly possible for it to not find anything 16:29
tadzik indeed 16:31
dalek rakudo/nom: adb2c8f | niner++ | src/ (4 files): 16:33
rakudo/nom: Fix EVAL during precompilation
rakudo/nom:
rakudo/nom: EVALed code is considered an independent compilation unit that gets compiled
rakudo/nom: using a new World which contains an independent serialization context. It also
rakudo/nom: gets its own QAST compiler.
rakudo/nom:
rakudo/nom: When a BEGIN time EVAL is run during precompilation of a module, the
rakudo/nom: independent SC would not be written into any file but would still be referenced
rakudo/nom: from the outer compilation unit. We therefor use the outer world's
rakudo/nom: CompilationContext which contains the SC. We also need to share a couple of
rakudo/nom: other attributes that keep track of the compilation's state.
moritz nine_++ # months of work cummulating into a single commit 16:34
oh, two commits actually; dalek swallowed one
nine_ Well the second one was a quite quick refactor, not even comparable to the work that went into the first :) 16:36
And it may well be that I have to re-visit this topic again as it's only an 80 % fix. It's enough to unblock the repository work though.
16:43 hankache joined
lizmat nine++ 16:43
timotimo that's the magical commit! \o/ 16:49
vendethiel nine_: looks amazing :D 17:24
masak nine++! 17:28
does this mean something for slangs and/or other languages? 17:29
jnthn nine_++ # persistence 17:35
timotimo persistence is something i'm sorely lacking :S 17:36
17:50 lizmat joined
vendethiel timotimo: yeah, hard stuff 17:51
17:51 lizmat joined
nine_ masak: sorry, I've got much too little experience with slangs to answer that. 18:07
masak dang :) 18:10
so do I!
dalek ast: e732b37 | lizmat++ | integration/precompiled.t:
RT #124324 is fixed, nine++
 18:35
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=124324
lizmat PSA: re github.com/rakudo/rakudo/pull/578 18:41
I've asked leont to adapt the PR in such a way that we can do a make spectest using prove6 by setting an environment variable
thus allowing easy switching between "production" spectesting, and "dogfood testing" spectesting 18:42
jnthn +1
lizmat as soon as that is the case, I plan to merge that PR
so that we can have more eyes on it more easily
jnthn *nod*
jnthn wonders if working thorugh the treasure trove that is gist.github.com/jnthn/2996cce212da...60e71fe5a5 next week might help with some of what it runs in to... 18:44
lizmat oooh shiny!
jnthn It takes about 16 hours to do such a spectest run :) 18:45
lizmat fwiw, I recognize a lot of those test files as flappers 18:50
jnthn Yes, me too ;) 18:51
lizmat food! drink! girls! 18:54
.oO( Father Jack is everywhere )
&
jnthn enjoy :) 18:57
walk & 18:58
19:02 hankache joined
dalek rakudo/relocateable-precomp: 899befd | niner++ | src/core/CompUnit/Repository/Installation.pm: 21:53
rakudo/relocateable-precomp: Turn short-name lookup files into directories
rakudo/relocateable-precomp:
rakudo/relocateable-precomp: This may become part of CompUnit::Repository::Installation format v1.
rakudo/relocateable-precomp: Having to change any already existing files on installation of a module makes
21:54 dalek joined 21:56 cognominal joined
tadzik oh yiss 21:57
22:46 lizmat joined 22:55 astj joined
lizmat so, is there a reason why we only have Version:D cmp Version:D, and not Version:D gt Version:D and friends? (ge eq ne lt le) ? 23:11
dalek kudo/nom: 688ddee | lizmat++ | src/core/Version.pm:
Add Version lt|le|eq|ne|ge|gt Version

It would seem we need a richer set of operators for Version comparisons. This causes some (un-spectested) changes:
   say v2.8 eq v2.8.0; # False before, now True
   say v2.8 eqv v2.8.0; # False before, still False		 23:30
23:57 tomboy64 joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!