00:24 sena_kun left 00:34 leont left 00:47 leont joined 00:56 squashable6 left 00:57 squashable6 joined 02:59 leont left 04:56 hungrydonkey left 04:58 hungrydonkey joined 06:18 jmerelo joined
nine Xliff: actually I was wondering how an unmodified rakudo master does for you without any parallel compile. If you see any changes there 07:08
tellable6 nine, I'll pass your message to Xliff
nine NativeCall tests fail consistently: t/04-nativecall/00-misc.t ....................................... Dubious, test returned 1 (wstat 256, 0x100) 07:21
tellable6 2020-02-25T22:38:05Z #raku-dev <lizmat> nine github.com/rakudo/rakudo/blob/mast...e.pm6#L144 feels like the last .add is in the wrong set of params
2020-02-25T22:39:49Z #raku-dev <lizmat> nine nvm, figured it
nine got: "\x[1B]===\x[1B]SORRY!\x[1B]===\x[1B] Error while compiling -e\n\x[1B]===\x[1B]SORRY!\x[1B]===\x[1B] Error while compiling /tmp/perl6_roast_00_misc_t_line31_0_354507043518361151582701714/Foo.pm6 (Foo)\nCould not find NativeCall in:\n file#/tmp/perl6_roast_00_misc_t_line31_0_354507043518361151582701714\n inst#/home/nine/.raku\n 07:22
inst#/home/nine/rakudo/gen/build_rakudo_home/site\n inst#/home/nine/rakudo/gen/build_rakudo_home/vendor\n inst#/home/nine/rakudo/gen/build_rakudo_home/core\n ap#\n nqp#\n perl5#\nat /tmp/perl6_roast_00_misc_t_line31_0_354507043518361151582701714/Foo.pm6 (Foo):2\n\nat -e:1\n"
lizmat: 8ac2eecc239c1c9c7eba71becf68e8e7e4087cd4 is the first bad commit 07:35
lizmat: I'm pretty sure assigning Nil into a slot in an nqp::hash will not do what we want 07:37
Geth rakudo: atroxaper++ created pull request #3513:
Fix run() with :out(Handle:D) and :merge		 08:37
roast: atroxaper++ created pull request #622:
Add test for run with :out(Handle:D) and :merge		 08:38
rakudo: atroxaper++ created pull request #3514:
#1882 Fix run() with :out(Handle:D) and :merge		 08:47
linkable6 RAKUDO#1882 [open]: github.com/rakudo/rakudo/issues/1882 [Hacktoberfest][easy to resolve][good first issue] run(..., :$out, :merge) does not redirect stderr to the $out file handle
Geth roast: atroxaper++ created pull request #623:
Add test for run with :out(Handle:D) and :merge
lizmat Files=1303, Tests=111207, 211 wallclock secs (28.57 usr 8.29 sys + 2945.81 cusr 277.67 csys = 3260.34 CPU) 09:17
09:25 |Tux| joined
Geth rakudo: 6c7ffbdbbf | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationStore/File.pm6
Potentially fix problem

  nine++ reported that 8ac2eecc239c1c9c7eba71becf68e8e7e4087cd4 broke
t/04-nativecall/00-misc.t , which I cannot reproduce. However, that commit did change the semantics slightly: instead of an Any, a Nil would be returned for a non-existing path. But since the check used //= , any subsequent attemopt would run the same code ... (5 more lines)		 09:40
lizmat nine: I can not reproduce the error you've seen... 09:41
Geth rakudo: 1f838791e3 | (Mikhail Khorkov)++ | src/core.c/Proc.pm6
#1882 Fix run() with :out(Handle:D) and :merge

Previously, the run routine with :merge and :out(Handle:D) arguments did not write output to the :out argument. Now both stderr and stdout will be written to the :out argument in such case.		 09:42
rakudo: b6851c3e7e | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Proc.pm6
Merge pull request #3514 from atroxaper/mkhorkov-1882

  #1882 Fix run() with :out(Handle:D) and :merge
linkable6 RAKUDO#1882 [open]: github.com/rakudo/rakudo/issues/1882 [Hacktoberfest][easy to resolve][good first issue] run(..., :$out, :merge) does not redirect stderr to the $out file handle
roast: 1af0b27a22 | (Mikhail Khorkov)++ | S32-io/pipe.t
Add test for run with :out(Handle:D) and :merge
roast: e7a0707d27 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | S32-io/pipe.t
Merge pull request #623 from atroxaper/mkhorkov-1882

Add test for run with :out(Handle:D) and :merge
09:54 |Tux| left 09:56 hungryd37 joined, hungrydonkey left 09:57 |Tux| joined
lizmat afk for a few hours& 10:04
|Tux| Rakudo version 2020.02-51-gb6851c3e7 - MoarVM version 2020.02-4-gfee45b9b4
csv-ip5xs0.697 - 0.705
csv-ip5xs-205.716 - 5.773
csv-parser22.379 - 22.858
csv-test-xs-200.363 - 0.365
test7.281 - 7.328
test-t1.768 - 1.797
test-t --race0.776 - 0.803
test-t-2030.244 - 30.395
test-t-20 --race8.568 - 8.777
 10:21
10:27 sena_kun joined
sena_kun 10:27
10:49 Guest1277 joined 11:34 Altai-man_ joined 11:36 sena_kun left 11:45 leont joined 12:06 titsuki joined 12:21 hankache joined
hankache hello * 12:21
.seen rba 12:24
tellable6 hankache, I saw rba 2020-02-25T20:18:29Z in #raku-dev: <rba> I will ask around if someone of my organiser friends like to take the chance.
hankache .tell rba I have an MSI for Rakudo Star 2020.01. Unfortunately I lost access to scp files once the old infra died. Would you be able to grant me access again? Thanks 12:25
tellable6 hankache, I'll pass your message to rba
hankache Meanwhile the files can be found here for testing: hankache.com/files/ 12:31
rba hankache: give me a sec. I will let you know how to scp. 12:33
hankache thanks rba
12:36 jmerelo left
rba hankache: scp <file> rakudo.org@lavm-perl6infra-1.atiko...oads/star/ 12:39
hankache: let me know if it works. 12:41
hankache rba: connection refused 12:43
rba hankache: may you send me your ssh keys? pm or let should I take the one from github? 12:46
12:51 squashable6 left 12:52 squashable6 joined
hankache rba both the ones I use are on github 12:53
rba hankache: quickly afk for lunch. will do in 20 minutes. 12:54
hankache rba: take your time
rba: or if you prefer I can mail them to you
13:03 MasterDuke left 13:17 titsuki left
rba hankache: added both keys from github. May you try again? 13:22
hankache rba: still getting connection refused 13:23
rba hankache: Grr. Same error again. Use "scp -P 2222"
hankache rba: same error 13:24
ssh: connect to host lavm-perl6infra-1.atikon.io port 2222: Connection refused 13:25
rba hankache: scp -P 2222 LICENSE rakudo.org@lavm-perl6infra-1.atiko...oads/star/ 13:27
hankache: worked for me and your keys are there. 13:28
hankache rba let me check the other machine 13:30
rba hankache: If you like I grab the file from URL. 13:33
hankache: Feb 26 13:32:30 lavm-perl6infra-1 sshd[22579]: Connection closed by 46.101.89.150 port 33021 [preauth] 13:34
13:35 sena_kun joined
hankache rba same on the second machine 13:37
13:37 Altai-man_ left
hankache scp -P 2222 "rakudo-star-2020.01-x86_64 (JIT).msi" rakudo.org@lavm-perl6infra-1.atiko...oads/star/ 13:37
am I doing something wrong?
13:38 Xliff joined
rba hankache: no. Please send me your ssh public keys again. 13:38
13:39 hankache_ joined
hankache_ rba sorry my bad, it's working correctly. it seems the issue was the network. Bloody fortinet 13:40
rba++
13:43 hankache left
rba hankache_: Hmm. May you upload the three files again? I have to rename them to fit the new naming scheme. 13:43
hankache_ rba sure
Xliff nine: You were asking for compile times? Sorry for the delay: gist.github.com/Xliff/476f61268a45...37f8c1ef5e 13:44
tellable6 2020-02-26T07:08:41Z #raku-dev <nine> Xliff: actually I was wondering how an unmodified rakudo master does for you without any parallel compile. If you see any changes there
Xliff .tell nine Unmodified rakudo compile comparison for GLib --> gist.github.com/Xliff/476f61268a45...37f8c1ef5e 13:45
tellable6 Xliff, I'll pass your message to nine
hankache_ rba I'll rename and upload 13:47
13:47 Xliff left
rba hankache_: May you let me know how to build on windows? 13:55
hankache_ rba done. renamed and uploaded
rba hankache_++ 13:56
hankache_ rba sure. The old build process was failing on windows, I had to patch something really quick to make it work. I'll commit my changes to the Star repo 13:57
rba hankache_: sounds great!
hankache_ rba thanks for your help 13:58
rba hankache_: I'm curious if we would be able to automate this using Azure DevOps Piplines.
So, this means the Rakudo Star 2020.01 is complete. Source/MacOSX and Windows are available for download 13:59
hankache_ rba: I know nothing about Azure DevOps Pipelines, but I managed to write a quick and dirty cmd script to do the build. I don't see why it shouldn't be feasible 14:00
Yes they are finally available. It has been a while 14:02
14:06 hankache joined 14:09 hankache_ left
lizmat .ask Xliff could you also do a timing on the 2020.02 release ? 14:19
tellable6 lizmat, I'll pass your message to Xliff
14:26 hankache left
nine So it became slower?! 14:29
tellable6 2020-02-26T13:45:29Z #raku-dev <Xliff> nine Unmodified rakudo compile comparison for GLib --> gist.github.com/Xliff/476f61268a45...37f8c1ef5e
nine Xliff: that's from 0 to working. Are compile times after modifying some source file better now? 14:30
tellable6 nine, I'll pass your message to Xliff
lizmat nine: apparently from 2020.01 something to HEAD 14:31
that's why I would like to know timing for the 2020.02 release, because there I didn't touch any of the Repo stuff yet
nine: BTW, is the nativecall test still failing for you ?
nine lizmat: seems to be fixed now! lizmat++ 14:39
lizmat nine: I'm surprised that last patch made a difference 14:40
but glad that it solved it for you
nine: two questions: is there a reason not to make CompUnit::PrecompilationId a subclass of Str ? 14:45
nine lizmat: before that fix, we wrote Nil into $!loaded{$key} so the next nqp::ifnull(nqp::atkey($!loaded, $key)) would take the wrong turn, because a Nil object is not NULL 14:46
lizmat and secondly: a precomp ID is a 40digit hexadecimal number, no ?
nine: ah, right, still don't understand why that didn't show up in my tests
14:48 titsuki joined
nine Yes a precomp ID is actually a number, but we usually deal with it in a stringified form 14:48
lizmat so why is this check: 2 < $id.chars < 64 && $id ~~ /^<[A..Za..z0..9._-]>+$/ ? 14:52
specifically I find the ._- suspect ? 14:53
nine It's because....well...you know...I think... jnthn said so! github.com/rakudo/rakudo/blame/mas...nt.md#L331 14:54
Well the compiler's ID did include a build time stamp 14:55
lizmat ah, so the . and - are obsolete 14:56
nine I don't know if other users of the PrecompilationRepository use those 14:57
lizmat m: use nqp; class A is Str { method new(str $a) { nqp::p6bindattrinvres(nqp::create(self),Str,q/$!value/,$a) } }; dd A.new("foo") # why doesn't this work ? 15:08
evalable6 (exit code 1) P6opaque: representation mismatch when storing value (of type Str) to attribute (of type str)
in method new at /tmp/RkCmbCzYrF line 1
in block <unit> at /tmp/RkCmbCzYrF line 1
jnthn have to use bindattr_s 15:11
lizmat aaah... and we don't have a p6bindattrunvres_s
moritz nine: Hi. Do you have any Python 3 plans for Inline::Python? 15:12
github.com/niner/Inline-Python/issues/37 suggest dropping 2.7 compat and switching to Python 3 entirely 15:13
jnthn lizmat: no, though just write ; self :)
lizmat: It's not really a performance op, just a convenience one
moritz I'm asking because I'm revising the "Perl 6 Fundamentals" book (then "Raku Fundamentals"), and its chapter 12 relies heavily on Inline::Python 15:14
15:14 titsuki left
moritz and I don't think it's acceptable if I release a new revision of a book that relies on a deprecated language verison, even if it's the python language :-) 15:14
nine moritz: yeah, Inline::Python needs updating. I'd actually like to keep 2.7 compatibility but honestly, the chance of someone using Inline::Python to actually migrate a Python code base to Raku seems tiny 15:17
lizmat would be cool if you could have an Inline::Python 2 and an Inline::Python 3 15:19
so Python people could use Raku to access the best of both Python worlds :-)
nine That's impossible for the same reasons that it's impossible to use a Python 2 lib in a Python 3 program 15:20
Well it's impossible in the same process. It would always have been possible to use multiple processes
lizmat weird... I mean, you can use Inline::Perl5 and Inline::Python in the same process? 15:22
are Python 2 and Python 3 not different libraries ?
rba patrickb: Playing around with Azure DevOps Pipelines. May this be something we like to have a look together?
tellable6 rba, I'll pass your message to patrickb
nine Python 2 and 3 are too similar. You get conflicting symbols when you try to load both
The clean cut and fresh start with Perl 6 is what made Inline::Perl5 possible 15:23
Geth rakudo: 17c45d89d1 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationUnit.pm6
Make CompUnit::PrecompilationId a Str

  - simplifies treating it as a string, because now it is one
  - no need for extra Stringy methods, such as Str, substr
  - automatically makes it a value type
  - allows all occurrences of .Str on precompilation ID's to be removed		 15:28
lizmat nine: ah, I see....
15:34 Altai-man_ joined 15:36 sena_kun left
Geth rakudo: 895038096d | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationUnit.pm6
De-hllize CompUnit::PrecompilationId cache
 15:44
rakudo: 747a35ba0b | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationStore/File.pm6
Remove now superfluous .Str coercions
 15:55
16:42 leont left 16:43 rypervenche left 16:47 rypervenche joined 17:06 hankache joined 17:09 Guest1277 left
Geth star/master: 89 commits pushed by (Patrick Spek)++, tyil++, (Naoum Hankache)++
review: github.com/rakudo/star/compare/139...253c2b1095		 17:14
hankache Highly subjective question: What is the preferred way to run raku from the command line raku or rakudo ? 17:22
lizmat uses "raku", or a "r" alias for "raku -e" 17:23
Altai-man_ raku?
japhb I use raku 17:24
hankache We have a winner 17:25
Altai-man_ it actually depends on purpose, I think. if you just wanna generally execute a program written in raku, then raku. if you care about some specific implementation (imaging there are more options than just rakudo), in this specific case you call specific implementation you want.
hankache thanks
17:28 MasterDuke joined
Geth star: 65f8cd4611 | (Naoum Hankache)++ (committed using GitHub Web editor) | README.md
README update Windows link
 17:28
lizmat is there a specific reason why a nqp::atkey on a non-existing key on a BOOTContext throws, rather than return nqp::null ? 17:33
m: sub a() { use nqp; dd nqp::atkey(nqp::getattr(CALLER::LEXICAL::,Map,q/$!storage/),q/$a/) }; $! = 42; a 17:34
evalable6 (exit code 1) Lexical with name '$a' does not exist in this frame
in sub a at /tmp/3sz21aYPVG line 1
in block <unit> at /tmp/3sz21aYPVG line 1
jnthn m: dd CALLER::LEXICAL::<$a> 17:35
evalable6 Nil
17:35 sena_kun joined
jnthn Hm, it doesn't even seem to match the semantics we want for Raku, so I guess we end up having to handler wrap it? 17:35
lizmat yeah, I think the Stash.AT-KEY handles that
17:36 jmerelo joined
lizmat it first does an existskey 17:36
vrurg CALLER and LEXICAL are pseudos, so PseudoStash does it in AT-KEY
lizmat so we have 2 lookups
jmerelo I'm having lots of trouble with Documentable and the latest versions of Raku. Boils down to: it hangs when I try to a say $object. 17:37
17:37 Altai-man_ left
jnthn jmerelo: Released version or HEAD? 17:37
MasterDuke jnthn: github.com/rakudo/rakudo/commit/bd...3a1498351d works for all the things i've tried, but actually slows down the only-types case (since they're no longer a chain of nqp::istype, though i guess i could do nqp::istype in that case and .ACCEPTS otherwise) and is a very minimal speedup for a bunch of concretes
jmerelo jnthn: Released version. Again, I find it almost impossible to golf it. Here's the code github.com/Raku/Documentable/issues 17:38
Main issue now is this one github.com/Raku/Documentable/issues/84
In here: github.com/Raku/Documentable/blob/...m6#L31-L59 doing a say self hangs, simply stops. It does the last call of a self method... 17:40
... but after the object is built, any call to any method of the object hangs.
jnthn Hangs using CPU or not?
Growing memory use or not?
jmerelo jnthn: will check
MasterDuke something i noticed about junctions (not caused by my optimization work) is that they blow up profiles
m: sub a($a where 1|2|3|4|5|6|7|8|9|0|"abc") { $a }; my $b; my $c = "a" ~ "bc".comb[0] ~ "c"; my $s = now; $b = a($c) for ^5_000; say now - $s; say $b 17:41
evalable6 5.1551609
abc
jnthn If using CPU and growing memory, it can be an infinite recursion somewhere
jmerelo jnthn: yep, it's doing both.
100% CPU, growing memory little by little... 17:42
MasterDuke if you set that loop count to anything over ~150 the profiles start getting gigantic
jmerelo jnthn: the only funky thing we do is using precompilation, but that should not be a problem... I guess. I mean, it's a problem, but a different kind of problem (the one that got me here in the first place) 17:44
MasterDuke oh right, it's not junctions themselves, its .ACCEPTS 17:45
m: my $a; $a = 1.ACCEPTS("abc") for ^1_000; say $a
evalable6 False
MasterDuke that creates a 6mb profiles
vrurg jnthn: I requested for review on #3500, but basically the only reason for that if you happen to mind of implementing .wrap via changing $!do on Code.
jnthn vrurg: Hm, how were we doing it before? I forget exactly... 17:51
MasterDuke: wow, that sounds odd
vrurg jnthn: does Wrapper role with a CALL-ME handler. This was causing 'cannot invoke handler' error in some cases. 17:52
jnthn Well, that's more working around a VM limitation if anything... How does unwrapping work now? 17:53
vrurg jnthn: In general, it wrapping does it similar to multi, using a list of Code objects. The first one is a stub to initiate WrapDispatcher, the last one is the original routine. 17:54
Total unwrap results in restoring the original static code.
jnthn Original $!do? 17:55
vrurg So, the good about it: unwrap doesn't leave behind an altered sub object.
Yes, original $!do.
The last one is not totally the original, it's a clone. But it has the original $!do.
All spectests are passing. 17:56
jnthn It's probably OK
Hm, where does `unwrap` come from now? I think that was carried by the role now? 17:57
*before, i mean
Sorry, long tiring bug hunt today...
vrurg jnthn: I know how it is, it was same hunt for me yesterday. :) unwrap was always a method on Routine. Now it does all the work. 17:58
The handler .wrap returns has .restore but it eventually calls .unwrap and is there for spec compatibility only.
I also wonder if it makes sense to unwrap totally if used without a handle argument: &foo.unwrap(). A spec mention this behavior, but there no even todo for it. 18:00
jnthn I'm not sure how strict we were about unwrap ordering before now, and if that'll have changed?
Though arguably if you haven't broken spectest you've not changed anything that matters ;) 18:01
lizmat ,oO( and Blin ? )
I guess we should ask sena_kun for a Blin run after this gets merged ?
vrurg Nah. I thought that unwrapping in the middle should strip off all later applied wraps, but it doesn't and specs are specific about this.
jnthn Ah, OK, if there were spectests on this then fine. 18:02
It's been considered and handled.
vrurg lizmat: would be nice. But from a user perspective nothing should be changed.
sena_kun lizmat, my routine is usually running blin each weekend, so no problem
jnthn OK, I don't really have anything more to add
lizmat okidoki!
vrurg But I can't not to brag about it: with new dispatchers it is possible to wrap a candidate of a multi method with a multi sub. And it works.
jnthn Wow 18:03
Nice :)
sena_kun by the way, anyone wants to cherry-pick dyncall commits with musl fixes?
jnthn I saw your question about MoarVM dispatcher support stuff; will have to take a look, but...
18:03 hungryd37 left
jnthn ...currently callsame/nextsame etc. perform pretty awfully 18:03
Geth rakudo: 8b70bfb843 | (Elizabeth Mattijsen)++ | src/core.c/Any.pm6
Add support for BOOTContext to dd

It just makes life easier for some core devs :-)		 18:04
jnthn I suspect we need to think through the overall approach
vrurg jnthn: BTW, I left a feature request for moar. To have it work, I utilize a $*NEXT-DISPATCHER to report subsquent dispatchers where to pass control when they're exhausted. But that'd be better to have an op similar to setdispatcerfor
jnthn iirc there's also some slightly icky C code in the Rakudo-specific ops involving dispatchers too
Yes, that feature request is what I'm talking about :) 18:05
vrurg Unfortunately, I don't have time to get deeper into moar, so not much help there. Only used the code to understand the basics of how dispatcher is obtained. 18:06
jnthn If we need to revisit those ops, probably we want to think the whole thing through from a performance angle and provide something good for it, so you can use callsame/nextsame - at least in straightforward cases - without fearing the slowdown.
It's a slight pity that a self.Foo::Bar::baz is going to be way faster than a nextsame :) 18:07
(They used to both be bad, but the former was comparatively easy to tackle with a spesh plugin)
vrurg Besides, some expect nextsame to do tail optimization which it doesn't. But would be nice if it is. 18:08
18:08 MasterDuke left
vrurg is away to finish a spectest for the new functionality. 18:08
japhb jnthn: Yeah, the slowdowns for callwith etc. was quite noticeable in one of my apps, as was runtime multi-dispatch. It also made tracing through using the profiler UI really annoying, because of the extra normally-hidden layers of anonymous dispatch bits. I eventually just hardcoded fast paths for my most common cases, with all the (re-)dispatch magic stripped away, and performance was much improved. 18:22
Geth roast: vrurg++ created pull request #624:
Additional tests for dispatching		 18:27
jmerelo sena_kun: can you help here? github.com/perl6/Pod-To-Cached/issues/16 18:29
sena_kun: the problem seems to be here: github.com/perl6/Pod-To-Cached/blo...#L127-L130 That "compilation" does not seem to work until next instance of the program. So somehow the actual storing is in exit 18:30
18:30 MasterDuke joined
MasterDuke jnthn: sorry, the junction optimization not being so great, or .ACCEPTS creating large profiles? 18:31
tbrowder shouldn't the current env var RAKUDOLIB be changed to RAKULIB? (at least add RAKULIB to be equivalent to PERL6LIB) 18:32
jmerelo tbrowder: pprobably
jnthn MasterDuke: the profiles 18:33
tbrowder i'm reluctant to change PERL6LIB in the docs to RAKUDOLIB because it doesn't quite track (IMHO) with changing 'perl6' to 'raku' 18:34
vrurg tbrowder: RAKULIB is planned but not implemented yet. 18:35
tbrowder ok, thnx. 18:36
jmerelo: that's why i didn't make those changes
vrurg: do you know if anyone is working on the change? 18:37
vrurg tbrowder: No yet, afaik. patrickb is mostly the one fixing the env variables. But basically, it should be simple most of the time: just dup what is there for PERL6LIB. Then choose the one which is defined and has higher prio. 18:38
tbrowder roger 18:39
jmerelo tbrowder: OK. Anyway, it's a good amount of work you're doing, and I appreciate that. 18:40
tbrowder thnx, i was getting tired of doing one file at at time and tried to take a short cut i knew wasn't a good idea! 18:41
Geth rakudo/master: 4 commits pushed by (Vadim Belman)++ 18:43
roast: e6351921d0 | (Vadim Belman)++ | 2 files
Add tests for dispatcher interaction

Method, multi, and wrapper dispatchers must not break each other and return control to the previous dispatching when exhausted.
roast: 32581b3c4d | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files
Merge pull request #624 from vrurg/rakudo_3499

Additional tests for dispatching
tbrowder thanks for putting on the brakes! i also want to change file extensions '.p6' and 'pm6' to '.raku' and '.rakumod' if that is acceptable in the lastest raku (i have only tested .raku which hasn't caused any problems yet). 18:45
vrurg tbrowder: I only use .rakumod for new files. No problem. 18:49
.seen Kaiepi 18:50
tellable6 vrurg, I saw Kaiepi 2020-02-19T13:13:43Z in #raku-dev: <Kaiepi> can someone review github.com/rakudo/rakudo/pull/3491 ? i want to get it in before people start using unix socket support
sena_kun encourages reviewing of socket-related things
tbrowder ok, thnx, sounds like it's ok to change the docs. in docs changes so far, i've been eliminating things like ".perl is being deprecated. new code should use .raku" and just making it read ".raku"; otherwise, imho, we have an ongoing doc maintenance problem trying to fine tune them constantly during some long but indefinite time. what say you folks? 18:54
maybe ensure we keep things like those old names in the glossary for a very long time. 18:55
jmerelo tbrowder: glossary is OK 19:05
m: say 3.perl; say 3.raku
evalable6 3
3
jmerelo The thing is .perl still works. It's not deprecated. We should at least mention it. 19:06
tbrowder right, but i think only in the glossary. and maybe also in just ONE place in the docs--somewhere where the perl6 => raku name change is mentioned. 19:07
lizmat I would be in favour of mentioning .perl in a single place, as deprecated 19:13
19:34 Altai-man_ joined 19:37 sena_kun left
tbrowder how about a new para in "intro.pod6" where we can mention language deprecations and new terms related to the name change. make a table of them "Rake term <=> Perl 6 term" and a note that all Perl 6 terms are deprecated? 19:51
*Raku
MasterDuke it's the failure path that creates the giant profiles. `1.ACCEPTS("1")` creates tiny profiles, even for 1m iterations, but `1.ACCEPTS("abc")` creates giant ones around 1k iterations 19:54
jmerelo tbrowder: that would be OK, I think. 20:04
20:06 jmerelo left
tbrowder take a look at my doc pr #3252 for a start 20:07
rba tyil: Strange. Looks like in the tar archive each file is twice. check rakudo.org/dl/star/rakudo-star-2020.01.tar.gz 20:08
vrurg Altai-man_: do you plan to run blin any time soon? 20:14
jnthn vrurg: He mentioned earlier every weekend 20:15
Altai-man_ vrurg, my routine is weekends, but I don't mind doing it today
Geth rakudo: f2cc20c6ed | (Elizabeth Mattijsen)++ | 4 files
Some Perl 6 -> Raku changes in docs
vrurg Altai-man_: no rush. weekly is ok.
Thanks!
Altai-man_ as I have a server, it's very easy to run one each night, though I don't have enough time lately to do any automation... or really anything else...
vrurg would rather stick to his ignorance for a few days to shift focus to another task. :) 20:16
Otherwise I would have to work on fixes and I'd rather not for some time. 20:17
20:19 lucasb joined
japhb Given that jnthn++ merged the derived-specializations branch in MoarVM, maybe time for a bumping? 20:24
20:26 hankache left
tyil rba: that's... very odd 20:27
I'll need to check that out
tbrowder, jmerelo: I think it's good for the docs to present the raku options without too much baggage, users rarely if ever need to know it used to be .perl for instance 20:31
also, keeping many referals to Perl 6 everywhere just makes it harder to continue forward as Raku 20:32
tbrowder that's my opinion, too ;-)
tyil on FOSDEM, I saw the most interest when I just told people Raku is a programming language, instead of going out of my to include the history all the time about it being Perl 6 but then being renamed
it's Raku, that's what we should document it as, and how we should present it to the world 20:33
MasterDuke why does this !SET-SELF take arguments it does nothing with? github.com/rakudo/rakudo/blob/mast...ce.pm6#L12 20:34
tyil MasterDuke: I think those arguments are always passed 20:35
if you dont specify them being accepted, it will generate an error that there's no sub accepting the params given
also, it uses the code argument, no?
MasterDuke yeah, but this one doesn't github.com/rakudo/rakudo/blob/mast...ce.pm6#L89 20:36
is it just binding the given arguments to the private members? implicitly instead of explicitly 20:37
i.e., instead of taking `$bt, $bt-next` and doing `$!bt = $bg; $!bt-next = $bt-next` in the body? 20:38
21:09 squashable6 left
rba hankache: Still like to know what you fixed to build Rakudo Star on Windows. As I'm getting the same error. 21:10
tellable6 rba, I'll pass your message to hankache
21:11 squashable6 joined
lizmat japhb: did he ? 21:14
aaah... yes... will bump now! 21:15
Geth nqp: 1e88914d9a | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump NQP to get the new derived specialization improvements
 21:20
21:21 cognomin_ joined 21:25 cognominal left 21:35 sena_kun joined 21:36 Altai-man_ left
lizmat japhb: I'm seeing some issues so need additional time to see whether it is the MoarVM bump, or stuff that vrurg or I did today 21:50
or that it is something that has been borked a little longer 21:51
vrurg lizmat: I found a problem with nextcallee. Will take care of it a bit later.
though will be afk for a while. 21:52
lizmat could you verify that Text::CSV installs for you with zef ?
can anyone confirm that Text::CSV installs on HEAD ? 21:53
vrurg lizmat: installs for me. Considering that I didn't pull the bump yet, it's the likely cause. 21:54
Ok, afk. bbl
22:08 leont joined
Geth rakudo: 9e494c8379 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/Dispatchers.nqp
Revert "Inline a method"

This reverts commit 899929674f0350ae04d778633189caad0f043b9e.
This breaks installation of Text::CSV, and potentially (many) other modules. So revert for now.		 22:13
rakudo: a27005b374 | (Elizabeth Mattijsen)++ | 3 files
Revert "Big rewrite of dispatchers and wrapping"

This reverts commit 502fd7fd144277a37b71f0580ba19b561c172741.
lizmat .tell vrurg sorry, but the big rewrite broke Text::CSV, so I've reverted them :-( 22:14
tellable6 lizmat, I'll pass your message to vrurg
lizmat grrr... looks like this wasn't the reason after all... but unclear what the problem is 22:20
===SORRY!=== Error while compiling /Users/liz/Github/zef/bin/zef
===SORRY!=== Error while compiling /Users/liz/Github/zef/site#sources/092D7DA0185CE0F1584F42452CD1E526B4B9DE17 (Zef::CLI)
New type Perl6::Metamodel::ClassHOW for NQPRoutine is not a mixin type
afk for a bit& 22:23
22:26 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Some Perl 6 -> Raku changes in docs' 22:26
travis-ci.com/tbrowder/rakudo/builds/150733224 github.com/tbrowder/rakudo/compare...cc20c6ed34
22:26 travis-ci left
MasterDuke hm. if i have it create nqp::istype ops for type objects, but .ACCEPTS for concrete objects, it slows it way way down 22:36
m: sub a($a where Int|Hash|Array|Complex|Real|Numeric|IO|Rat|Str) { $a }; my $b; my $c = "a" ~ "bc".comb[0] ~ "c"; my $s = now; $b = a($c) for ^10_000; say now - $s; say $b
evalable6 0.035689
abc
MasterDuke if i add a 2 before the Str, it slows to .7 22:37
japhb MasterDuke: Why *before* the Str? A junction doesn't have an intrinsic order, so you ought to be able to put all the heavy checks last without loss of generality. 22:40
MasterDuke it doesn't have an order by spec, but it does by implementation
i'm not trying to find an ordering that makes that code run faster, but to optimize that heavy check to be less heavy. so it need it to be hit to test 22:42
japhb MasterDuke: I guess I mean that nothing in the spec stops you from collecting a list of fast checks and a separate list of slow checks in the optimizer, and then doing them in that order.
Ah, I see what you mean
MasterDuke but yeah, that could be another optimization 22:43
re-ordering the checks 22:44
Geth rakudo: tbrowder++ created pull request #3516:
Enable env var RAKULIB
japhb Especially since you can assume that any concrete type that is reached in that case is definitely *not* one of the types you already checked for, you can through out some impossible checks. And the remainder you can first check whether the argument type matches the concrete test type exactly (and if so emitting a faster custom check), before falling back to the slow .ACCEPTS 22:45
*throw out
*concrete test value's type
sheesh, can't type
So: `$a where "boo"|Str|Int` can emit just checks for Str|Int, because if it's not a Str, then it's not "boo" 22:47
And `$a where "bar"|"foo"` can check if $a istype Str, and if so just emit a pair of fast string equality check, rather than a pair of slow .ACCEPTS calls 22:49
MasterDuke: ^^
Or actually, sorry, it can do -- `if nqp::istype($a, Str) { <check string equality } else { <check ACCEPTS }` 22:50
MasterDuke japhb: not quite. i thought so too, but jnthn pointed out that `$a where 1|2` should accept "1"
ah, yes, that would probably be possible
vrurg lizmat: As I told you, Text::CSV did install for me and my local version is before the last NQP bump. 22:56
lizmat undoes the revert and builds again 22:57
vrurg Don't commit the undo, I'll get nextcallee fixed and open a new PR. 22:59
lizmat gist.github.com/lizmat/f79faa3a433...1a1dcea710 with the revert reverted 23:00
Geth roast/RAKULIB: 55651cd89e | (Tom Browder)++ | S11-modules/perl6lib.t
Test new env var RAKULIB
 23:05
vrurg lizmat: is it for Text::CSV?
lizmat I found that zef itself doesn't install with the problem, see gist 23:06
Geth roast: tbrowder++ created pull request #625:
Test new env var RAKULIB		 23:07
lizmat now, the odd thing is that if I bump NQP to get jnthn's latest fixes, it dies with the same error :-(
vrurg Then it's about the bump, I guess? Or do I miss something? 23:08
lizmat a bump, with your commits reverted, creates the same problem as not bumped but with your commits
at least for me :-(
I'm getting too tired now... need some sleep 23:09
will look again tomorrow, hoping someone will have fixed this
sleep&
vrurg Do full cleanup of the installation directory each time. Sounds as if moar or nqp are not updated at some steps.
lizmat: g'night!
MasterDuke japhb: jnthn did say he didn't want the generated code to get to big though...but maybe i'll give it a try and see what it looks like 23:29
23:34 Altai-man_ joined, hungrydonkey joined 23:36 sena_kun left
Geth ¦ problem-solving: ToddAndMargo assigned to jnthn Issue qqx not picking up quotes in Windows 7 github.com/Raku/problem-solving/issues/166 23:36
nqp: tinmarino++ created pull request #600:
More explicit error when more than one --target is provided		 23:43

Powered by Cro and the Raku® Programming Language.

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

Thank you!