01:20 Altai-man_ joined 01:22 sena_kun left 01:26 TreyHarris left 01:39 TreyHarris joined 01:56 kalkin-- joined 01:59 kalkin- left 02:26 leont left 03:21 sena_kun joined 03:23 Altai-man_ left 04:23 bloatable6 left, bisectable6 left, sourceable6 left, greppable6 left, committable6 left, coverable6 left, shareable6 left, releasable6 left, reportable6 left, nativecallable6 left, squashable6 left, quotable6 left, unicodable6 left, notable6 left, statisfiable6 left, benchable6 left 04:24 shareable6 joined, nativecallable6 joined, squashable6 joined, committable6 joined 04:25 releasable6 joined, reportable6 joined, coverable6 joined, unicodable6 joined, notable6 joined 04:26 statisfiable6 joined, bloatable6 joined, sourceable6 joined, benchable6 joined, bisectable6 joined, quotable6 joined, greppable6 joined 05:20 Altai-man_ joined 05:23 sena_kun left 07:21 sena_kun joined 07:23 Altai-man_ left
|Tux| Rakudo version 2019.11-291-g9a571b685 - MoarVM version 2019.11-97-geb13ccad1
csv-ip5xs0.721 - 0.727
csv-ip5xs-206.446 - 6.796
csv-parser22.944 - 23.070
csv-test-xs-200.429 - 0.434
test6.987 - 7.232
test-t1.684 - 1.767
test-t --race0.797 - 0.814
test-t-2029.985 - 29.989
test-t-20 --race9.067 - 9.248
 08:26
lizmat Files=1294, Tests=109647, 209 wallclock secs (28.23 usr 8.27 sys + 2939.15 cusr 268.01 csys = 3243.66 CPU) 08:41
Xliff lizmat: What tests are these and how can I run them? 09:10
lizmat make spectest
Xliff Jeebus! 209 wallclock? What is that being run on? 09:13
lizmat my monster MBP :-)
Xliff Are there any specs on that?
.oO( And I thought mine was a monster! )
lizmat 2.4GHz Intel Core i9
32 GB 2400 Mhz DDR4 09:14
1TB SSD
with TEST_JOBS=16
Xliff Aha!
Hmmm... my make spectest fails to find Inline::Perl5, which is installed. 09:16
I'm running 0e2485a83f337099a58005d86b696dccd397f6a8
09:20 Altai-man_ joined
Xliff Files=1294, Tests=109655, 163 wallclock secs (26.10 usr 3.85 sys + 2959.43 cusr 160.03 csys = 3149.41 CPU) 09:21
TEST_JOBS=20
nine Xliff: did you follow the instructions printed by make spectest?
Xliff nine: Yesss...
Actually, I just did that on the posted run. That did NOT affect the results.
lizmat Xliff: looks like you have a bigger monster :-)
Xliff Currently spectest FAILS 09:22
lizmat nine: those instructions don't work for me
Xliff Those aren't outright failures, BTW. All are marked Dubious
t/spec/S12-construction/destruction.t
t/spec/S12-construction/roles-6e.t 09:23
t/spec/S14-roles/submethods-6e.t
09:23 sena_kun left
nine Sounds like vrurg++'s recent work? 09:25
lizmat hmmm... don't fail for me... 09:28
Xliff Recompiled to latest on git. 09:32
Now only one failure:
t/spec/S16-io/watch.t -- test 1 failed
Files=1294, Tests=109659, 171 wallclock secs (25.82 usr 3.61 sys + 3043.49 cusr 165.04 csys = 3237.96 CPU)
Again... same "failure" : Dubious, test returned 1 (wstat 256, 0x100) 09:33
kalkin-- Can some one have a look at my Rakudo PRs? 09:39
Feedback is welcome
github.com/rakudo/rakudo/pulls?q=i...r%3Akalkin ā† the top three ones 09:40
Xliff m: my $a = 2; $a.perl.say 09:46
camelia 2
Xliff m: my $a = 2/21; $a.perl.say
camelia <2/21>
Xliff m: my $a = 2/21; say "$a.perl"
camelia 0.095238.perl
Xliff kalkin--: Are you sure you don't want braces around $_.perl() here -> "enum $_.perl() { signature2text $_.enums.pairs } \n" 09:48
github.com/rakudo/rakudo/pull/3360...e08e2caa7e
kalkin-- Xliff: it looks to me you are right, but I wonder why it worked for me? Maybe i copy pasted something wrong. I have an own internal Pod::To::Text2 PM file, may be i copy/pasted old version? 10:05
Will fix that
Xliff: Just tested it. It works o_O 10:19
p6: enum Foo <Bar Buz Boom>; my $f = Buz; say "==> $f.perl()"; say "$f" 10:20
camelia ==> Foo::Buz
Buz
kalkin-- looks to me that this is completely fine :)
10:30 Xliff left, Xliff_ joined 11:21 sena_kun joined 11:23 Altai-man_ left
AlexDaniel sena_kun: forget about ZefFailures, look at AlwaysFails 11:25
sena_kun AlexDaniel, but I spotted a regression looking at ZefFailures... 11:26
AlexDaniel sena_kun: OK then don't listen to me!
:)
I mean, it never hurts to look, yes
sena_kun AlexDaniel, well, my guess is "Just check each module which fails", and there are around 300 of them anyway, so 30 more or less... 11:27
AlexDaniel to clarify, AlwaysFail means that it was tested on --new (usually master HEAD) and tests failed, then it tested on --old (usually previous release) and it also failed
normally that means that the module is just broken and it should be ignored 11:28
or that you don't have some dependencies installed so it can't be tested
sena_kun AlexDaniel, what's the motivation behind suggesting me to look at AlwaysFails then, if they are supposedly broken anyway?
AlexDaniel but because we're at ā‰ˆ100 more AlwaysFail modules, it means that there's something wrong somewhere
sena_kun: cuz these 100 modules were testable just fine during the previous release 11:29
sena_kun AlexDaniel, ah. well, but they can be broken and we don't know about that. anyway, I'm going to report that zef search timeout, if it is not reported already, because that's annoying 11:30
AlexDaniel so something is wrong somewhere, it could be a zef regression, or an incomplete setup with dependencies not installed, or somethingā€¦
sena_kun: as for that zef search timeout, I think the output is buffered and we're not getting the rest of it
sena_kun: so it's simply a timeout, the module failed to install in 10 minutes
or whatever the limit is 11:31
sena_kun AlexDaniel, possibly...
anyway, less talking and more checking. ;)
AlexDaniel pretty sure this thing is a clear indication that something changed in zef: github.com/rakudo/rakudo/pull/3373...-568438862
and even if the change is good, it should probably be reverted if it causes issues in tens of modulesā€¦ 11:32
just tried it locally and I can reproduce
sena_kun latest commits to zef were at Nov 3, and we had a release with that, apparently
no?
I mean, "latest commits that are not for appveynor" 11:33
AlexDaniel not sure
to be fair I just have this file hereā€¦ which is X months old
maybe it's from the releas before the last one 11:34
release*
sena_kun AlexDaniel, then we need to check 'em all the more
AlexDaniel hmmmmmmmm 11:35
just tried that module with the right PERL6LIB and it failed some testsā€¦ 11:36
Cannot look up attributes in a WorkdayCalendar type object
probably a regression 11:37
or something
it's weird
sena_kun: I did this: github.com/ugexe/zef/issues/330 11:47
sena_kun AlexDaniel, thanks!
AlexDaniel, I am continuing to go over failures... 11:48
AlexDaniel, you probably should get some rest. ;)
AlexDaniel maybe? 11:49
I didn't sleep today, didn't feel like sleepingā€¦
12:09 leont joined
lizmat sena_kun AlexDaniel: I can push to master without interfering with the release, right ? 12:12
sena_kun lizmat, yeah 12:13
lizmat oki
sena_kun lizmat, we have regressions anyway, so 1)need to check every failing module; 2)prepare info about broken ones and report, wait for fixes; 3)another round
lizmat, while you are here, Method::Also is broken on master
lizmat is hoping to get the re-imagined val() handling into master today
sena_kun: looking at it now 12:14
sena_kun reliably so, and it wasn't before, so a regression...
lizmat Cannot resolve caller bar_ber(Bar:U, Str:D); Routine does not have any candidates. Is only the proto defined? 12:15
looks like something vrurg did :-)
sena_kun lizmat, I am seeing Too many positionals passed; expected 4 arguments but got 5 at /home/koto/.zef/store/Method-Also-0.0.4.tar.gz/Method-Also-0.0.4/t/01-basic.t:32 12:16
lizmat as it is related to roles
sena_kun don't tell me I am doing it wrong just running `zef install Foo` with the correct rakudo checkout
lizmat sena_kun: I assume that is on the release branch ?
sena_kun lizmat, 2019.11-291-g9a571b685 built on MoarVM version 2019.11-93-g7a93b2897 12:17
not release branch, but what Blin tested yesterday
lizmat that's what I'm testing with
I'm just running raku t/01-basic.t in the repo 12:18
sena_kun lizmat, can you try `zef install .`?
lizmat ok, then I get that error 12:19
sena_kun lizmat, well, either way it is broken and I reported that. :S 12:20
should likely create a ticket 12:21
lizmat the line in question is "class Bar does Ber {" so I think the error is actually somewhere in the RoleHOW
is there an invocation for zef to have it run with --ll-exception ? 12:22
sena_kun (no idea) 12:23
lizmat gist.github.com/lizmat/72970bb417e...7590d35940
sena_kun lizmat, I'm creating a ticket then... 12:24
github.com/rakudo/rakudo/issues/3378 12:26
lizmat well, that gist is pretty useless: 12:27
hmm... what is a BOOTContext ? 12:30
apparently the "specialize with" method gets one 12:31
hmmm... looks like Xliff_'s changes to Method::Also are interfering with vrurg's work 12:33
sena_kun: at least temporary fix on its way to CPAN. Removed the blocker label 12:55
sena_kun lizmat, thanks, noted
I am running Blin again, with increased timeout... after that will look at results 13:06
Geth_ roast: 5b06aeeaf6 | (Elizabeth Mattijsen)++ | S03-operators/arith.t
Make sure undefine keeps working in test

As it will be removed in v6.e		 13:10
sena_kun a stupid question, but how do I know which rakudo revision is used in Blin?
AlexDaniel sena_kun: should be in the output, no? 13:12
good question :D
sena_kun I guess latest HEAD 13:17
"Will compare between 2019.11 and HEAD"
13:20 Altai-man_ joined
Altai-man_ ok, now $dayjob 13:21
13:23 sena_kun left
kalkin-- Another Bug or Feature Question: =defn is parsed as Pod::Defn, but =para is parsed as Pod::Block::Named with name set to para. IMHO it's inconsistent, but may be it should be like this? 13:36
13:36 kalkin-- is now known as kalkin-
tbrowder =defn is a special pod name and it gets special handling and has additional attributes 14:12
14:15 lucasb joined
tbrowder note that pod class naming isnā€™t real consistent due in part to the number of pod objects not implemented when the Christmas release was presented to the public 14:16
^^^ thatā€™s my opinion 14:25
Geth_ roast: e012309c70 | (Elizabeth Mattijsen)++ | 4 files
Some more 'undefine' fixes

Either add a local "undefine" sub, or change it to = Nil, or remove a test completely if it was just testing for the existence of "undefine".		 14:33
kalkin- tbrowder: There is a lot of stuff broken/wrong in Pod6 parsing. I dunno what i should do. Should I open for everything a GitHub issue, or should i write everything down + my own ideas about how some specific parts should work as one big GitHub issue? 14:39
lizmat kalkin-: having a master issue is a good start, then maybe add sub issues later 14:40
kalkin- lizmat: k, will do 14:41
lizmat m: 10 ** 100000000; say "compiled" # wonder what is going wrong here? perhaps we shouldn't do this as Ints? 14:53
camelia (timeout)
lizmat m: use nqp; dd nqp::tonum_I(10) ** 100000000
camelia Inf
15:21 sena_kun joined 15:23 Altai-man_ left
tbrowder kalkin: PRs would be wonderful! 15:59
16:25 toddr left 17:21 Altai-man_ joined 17:23 sena_kun left
jnthn lizmat: Just constant folding, no? 17:30
kalkin- tbrowder: I would love to do PRs, but the stuff is very complicated. IMHO Pod parsing should be an own grammar which is used each time a pod block is encountered, instead the parsing is all over the place, but may be it's a naĆÆve approach 17:40
It's very hard to tell what is used for what. 17:41
My current approach is add nqp::say("DRIN") and see if i get it triggered
tbrowder i agree, but thatā€™s the rub: no one has documented how to do that that i know of, and the experts are too busy with other higher-priority projects. 17:44
17:46 unclechu left, Demos[m] left, AlexDaniel` left, rba[m] left 18:02 Demos[m] joined
lizmat jnthn: yeah, just constant folding, but also with runtime 18:27
m: my $a = 10; say "started"; dd $a ** 100000000
hmmm... 18:28
camelia (timeout)started
lizmat ah, ok
18:29 unclechu joined, AlexDaniel` joined, rba[m] joined 18:35 lucasb left
lizmat so, use nqp; dd nqp::pow_I(10,100000,Num,Int) takes about 4 seconds to run on my MBP 19:06
the infix:<**>(Int,Int) candidate has a comment: # when a**b is too big nqp::pow_I returns Inf 19:07
this appears to be untrue
nine You know you have an algorithmic problem, when you can get the result faster doing it by hand...
lizmat github.com/perl6/nqp/blob/master/d...rkdown#pow specifically states that it will always return an Int
m: dd 10e100000 19:08
camelia Inf
lizmat yet this returns Inf without any complaints
this feels inconsistent :-) 19:09
19:21 sena_kun joined 19:23 Altai-man_ left 19:45 Xliff_ left
lizmat bisectable6: dd "1.".succ 20:09
bisectable6 lizmat, On both starting points (old=2015.12 new=9a571b6) the exit code is 0 and the output is identical as well
lizmat, Output on both points: Ā«"2."ā¤Ā»
lizmat m: dd "Ā¹".succ 20:11
camelia "Ā¹"
20:17 AlexDani` joined
lizmat whee! my val() re-imagining passes all spectests! 20:17
moritz that can just mean one thing: too few tests :D 20:18
congrats lizmat
20:18 AlexDaniel left
lizmat moritz: meh :-) 20:19
that's the next thing :-)
it's between 1.6x and 2.1x faster 20:20
so far :-)
with about 20% of allocations 20:23
I guess I'll first write some more tests before merging 20:25
and I definitely don't want this in the 2019.12 release
raku -e 'say val(q/:16{ aa bb cc dd }/)' 20:45
Blob:0x<AA BB CC DD>
^^ new feature, soon in a release near you
sena_kun thinks about the release 20:56
20:59 pmurias joined
pmurias lizmat: re pow_I, Inf is returned for exponents that don't fint into a bigint digit 21:04
tellable6 2019-12-17T20:46:18Z #raku-dev <MasterDuke> pmurias: think it would make sense to try and have rakudo listed here? github.com/neomatrix369/awesome-graal
lizmat pmurias: and how big is that? and how long does it take it to find out ? 21:05
pmurias lizmat: it's cheaply compared 21:11
pmurias is figuring the exact size
lizmat m: dd 10e100000 21:12
camelia Inf
lizmat m: dd 10 ** 100000
pmurias on the js backend Inf is returned for exponents bigger than 4294967296
camelia 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ā€¦
lizmat m: dd 10 ** 1000000
pmurias m: say 10e1.^name
camelia (timeout)
Num
lizmat so why does 10 ** 1000000 timeout then ? 21:13
pmurias lizmat: because the exponent is not big enough? 21:16
m: dd 10 ** 1000000000000
camelia Failure.new(exception => X::Numeric::Overflow.new, backtrace => Backtrace.new)
pmurias lizmat: the exponent is too big enough to calculate and not big enought to trigger the too big check 21:19
lizmat well, technically I guess it's correct that it doesn't trigger 21:20
but realistically, I've had "10 ** 1000000" run for 15 minutes without result
so it may well be that it will just take too long, at least until our computers are 1000x faster 21:21
so effectively a program would hang
21:21 Altai-man_ joined
lizmat so maybe we need a $*MAX-EXPONENT 21:21
21:23 sena_kun left
lizmat $*MAX-POWER 21:23
pmurias do people use super big bigints that take hundreds of mb of memory? 21:25
pmurias is not sure what the sane value for throwing the exceptions is and just allowing tweaking it without a good answer to that won't help much 21:27
lizmat I ran into this while trying to re-implement nqp::numify in Raku 21:31
nqp::numify handles 10e100000 without any issue 21:32
m: dd 10e100000
camelia Inf
lizmat yet 10 ** 100000 "hangs"
jnthn 10e100000 isn't calculating anything, though; it's just a Num literal 21:37
And it doesn't have all the precision of the Int, so it's kind of apples and oranges 21:38
lizmat but that Num literal needs to be calculated
m: <10*10**100000>
camelia WARNINGS for <tmp>:
Useless use of constant integer 10*10**100000 in sink context (line 1)		 21:39
jnthn A floating point number is actually represented in memory as a significant and an exponent
*significand
lizmat m: <10*10**10000000>
camelia WARNINGS for <tmp>:
Useless use of constant integer 10*10**10000000 in sink context (line 1)
lizmat m: dd <10*10**10000000>
jnthn Whereas a big integer ain't; it's represented using as much memory is needed for the digits.
*as is needed 21:40
camelia (timeout)
jnthn I'm not surprised such a calculation on a bigint takes so long, though 15 minutes is quite a while... I don't think putting arbitrary limits in place helps anyone who is actually wanting to do such math.
japhb Still, integer exponentiation should be relatively "fast" in that you need O(log(exponent)) multiplications of O(log(exponent)) digit numbers, yes? 21:58
kalkin- Pod docs on roles are missing the role in WHEREFORE *sigh* 22:09
japhb * O(log(exponent)) multiplications of O(exponent) digit numbers
multiplication of very large numbers is O(n log n) for n=exponent, and for midsize numbers more in the range of O(n ** 1.46), so it's somewhere around n**1.5 in practice I suppose. So for 10 ** 1_000_000, I guess around 1_000_000_000 ops. 22:20
(back of the envelope thinking obviously) 22:21
22:52 dogbert11 joined 22:54 dogbert17 left 23:01 Kaiepi left 23:02 Kaiepi joined 23:10 dogbert17 joined 23:12 dogbert11 left 23:21 sena_kun joined 23:23 Altai-man_ left

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!