🦋 Welcome to the main IRC channel of the Raku Programming Language (raku.org). This channel is logged for the purpose of keeping a history about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs can be inspected at colabti.org/irclogger/irclogger_log/raku
Set by lizmat on 21 April 2021.
raydiak japhb: I don't see anything in the docs to explain it, would take some deeper digging. --target=parse shows some possibly relevant things, but I don't know enough about internals to tell you the difference between an xblock and a pblock and a blockoid, or even if that's relevant 00:04
japhb Fair enough. :-) 00:09
raydiak looks like maybe something to do with spesh, possibly a bug. it blows up with --optimize=0
it probably optimizes the when block away somehow, turns it into something faster and simpler than a block 00:10
japhb Interesting. 00:22
I was wondering if it was intentional in order to make succeed and proceed magically work or something
raydiak seems not, --optimize=0 gives "Too many positionals passed; expected 0 arguments but got 1" 00:24
(after "Odd", of course)
japhb Interesting! 00:49
kawaii I made a little slot machine script thingy, maybe someone has some optimizations or improvements but it's cute. :) www.irccloud.com/pastebin/BFWwVwP0/slots.raku 01:35
I feel like the multipliers hash and wheel array can be merged somehow, maybe a hash of pairs? 01:36
raydiak heh, cool 01:53
raydiak kawaii: here are some simplifications: gist.github.com/raydiak/59350a9171...4a76d6667b 02:25
updated it, arguably a bit easier to read this way 02:32
Xliff jj? 08:18
demostanis[m] Does Raku have a quoting constructs for junctions? Something like `qj[a b]` that would make a Junction. 10:44
lizmat any(<a b>) 10:46
demostanis[m] Thanks 10:47
Xliff What is the .Int operator in Raku? Like + is for .Num 10:48
lizmat note that this is just a combination of existing expressiveness -)
Xliff: there is none, .Int it is
Xliff I prever <a b>.any, myself
Aww... why didn't .Int get any love, lizmat? 10:49
( Prolly run out of symbols? ;-> )
lizmat lack of suitable characters to use as prefix?
yup
Xliff Should find one in Unicode.
I have .XCompose and WinCompose. I yam not afraid!
𝕚, maybe? 10:51
method prefix:<𝕚> (\v) { v.Int } 10:52
m: multi sub prefix:<𝕚> (\v) { v.Int }; say 𝕚3.14169
camelia 5===SORRY!5=== Error while compiling <tmp>
Malformed postfix call
at <tmp>:1
------> 3i sub prefix:<𝕚> (\v) { v.Int }; say 𝕚3.7⏏0514169
Xliff m: multi sub prefix:<𝕚> (\v) { v.Int }; say 𝕚(3.14169)
camelia 5===SORRY!5=== Error while compiling <tmp>
Undeclared routine:
𝕚 used at line 1
Xliff Huh. Thought that would work. 10:53
m: multi sub prefix:<𝕚> (\v) is equiv(&prefix:<+>) { v.Int }; say 𝕚(3.14169) 10:55
camelia 5===SORRY!5=== Error while compiling <tmp>
Undeclared routine:
𝕚 used at line 1
Xliff raku say 𝕚
m: raku say 𝕚
camelia 5===SORRY!5=== Error while compiling <tmp>
Undeclared routines:
raku used at line 1
𝕚 used at line 1
Xliff Huh! The one symbol I pick and it's usable as an op! 10:56
Ah, well. To bed I am. Good night, #raku. 10:57
lizmat Xliff: nighty night! 11:01
kawaii raydiak: sorry for late reply, just woke up, but I agree! thank you! 11:16
Xliff Lizmat: are there any documentation pages for attribute traits? 11:36
I know you introduced some new ones a while back that I haven't had a chance to familiarize myself with.
lizmat docs.raku.org/type/Attribute ? 11:37
Xliff Ah! Thanks!
lizmat: Is there any way to have rakudo generate positional new from traits? 11:38
I was thinking "is built".
lizmat is built indicates that it will be accepted as a *named* param with .new 11:39
Xliff Right.
lizmat so you'd want something like "is built(Positional)" ? 11:40
Xliff Was hoping to save keystrokes.
lizmat well, that would be a major overhaul of default handling of classes / objects
Xliff m: class A { has $!b; has $!c; submethod BUILD (:$!b, :$!c) { }; method new ($b, $c) { self.bless( :$b, :$c ) }; };
camelia ( no output )
lizmat but it *is* an interesting idea
why the BULD in that case ? 11:41
Xliff Would LOVE to drop the BUILD and new with a trait.
Can BUILD be dropped?
m: class A { has $!b; has $!c; method new ($b, $c) { self.bless( :$b, :$c ) }; }; A.new(1, 2); 11:42
camelia ( no output )
lizmat m: class A { has $!b is built; has $!c is built; method new ($b, $c) { self.bless( :$b, :$c ) }; };
camelia ( no output )
lizmat that should work ?
Xliff m: class A { has $!b; has $!c; submethod BUILD (:$!b, :$!c) { }; method new ($b, $c) { self.bless( :$b, :$c ) }; method Str { $!b ~ '/' ~ $!c }; }; ~A.new(1, 2_ 11:43
camelia 5===SORRY!5=== Error while compiling <tmp>
Unable to parse expression in argument list; couldn't find final ')' (corresponding starter was at line 1)
at <tmp>:1
------> 3Str { $!b ~ '/' ~ $!c }; }; ~A.new(1, 27⏏5_
expecting any …
Xliff m: class A { has $!b; has $!c; submethod BUILD (:$!b, :$!c) { }; method new ($b, $c) { self.bless( :$b, :$c ) }; method Str { $!b ~ '/' ~ $!c }; }; ~A.new(1, 2)
camelia WARNINGS for <tmp>:
Useless use of "~" in expression "~A.new(1, 2)" in sink context (line 1)
Xliff m: class A { has $!b; has $!c; submethod BUILD (:$!b, :$!c) { }; method new ($b, $c) { self.bless( :$b, :$c ) }; method Str { $!b ~ '/' ~ $!c }; }; say ~A.new(1, 2)
camelia 1/2
Xliff m: class A { has $!b; has $!c; method new ($b, $c) { self.bless( :$b, :$c ) }; method Str { $!b ~ '/' ~ $!c }; }; say ~A.new(1, 2)
camelia Use of uninitialized value element of type Any in string context.
Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.
/
in method Str at <tmp> line 1
Use of uninitialized value element of type Any in st…
Xliff m: class A { has $!b is built; has $!c is built; method new ($b, $c) { self.bless( :$b, :$c ) }; method Str { $!b ~ '/' ~ $!c }; }; say ~A.new(1, 2) 11:44
camelia 1/2
Xliff \o/
Now just have to get rid of new!
lizmat PRs will be considered :-)
Xliff RakuAST would make short work of it.
lizmat not so sure: this would affect all of the BUILDPLAN logix 11:45
*logic
and that's carefully optimized for fun and profit
Xliff Would have to override CLASSHOW.^compose so that I could .^add_method at the last minute.
lizmat and nudging that runs the risk of slowdowns across the board 11:46
ok, if you're thinking like that... hmmm
that would leave the BUILDPLAN logic untouched
Xliff No, I would be punning all attributes with a Role. new() would be created from .^attribute order with all attributes having that trait.
And yes, that would be the hope.
lizmat still wonder if that would be a net performance gain 11:47
but then you're interested in fewer keystrokes, right ?
Xliff Was more concerned with O(fun) than gain.
I have strange ideas of Fun, these days.
lizmat yeah, sure... :-) 11:48
could be done in a module then :-)
Xliff github.com/Xliff/p6-EDS
lizmat: True. Could be done in a module.
Above link is the start of bindings for EvolutionDataServer
lizmat Xliff: perhaps rename the repo?
:-)
looks cool! 11:49
Xliff developer.gnome.org/eds/stable/
lizmat: Hrm. Maybe. I think EvolutionDataServer is too long, though.
You think that's bad?
lizmat I was more thinking "raku-EDS" :-)
instead of "p6-EDS" :-) 11:50
Xliff github.com/Xliff/p6-GOA (GNOME Online Accounts)
lizmat: Yes. Prior to release there will be a prefix change.
lizmat ++Xliff :-)
Xliff BTW - 530,000 lines and climbing.
lizmat wow 11:52
Xliff Huh! Constants can support dashes, but enums can't? 11:54
lizmat example? 11:55
Xliff One second. Trying to get a clean parse before commit.
Oh... and this isn't valid, either! 11:56
m: sub test-vcard-qp-2-1-parsing { }
camelia 5===SORRY!5=== Error while compiling <tmp>
Missing block
at <tmp>:1
------> 3sub test-vcard-qp7⏏5-2-1-parsing { }
expecting any of:
new name to be defined
Xliff m: our enum VCardVersion is export ('ver2-1', 'ver2_1' => 0, 'ver3', 'ver4'); ver2-1.say 11:57
camelia 5===SORRY!5=== Error while compiling <tmp>
Undeclared routine:
ver2 used at line 1
Xliff Numerics-following-dashes gets interpreted as subtraction
lizmat ah, yes
Xliff Grr...
lizmat kebabcase needs an alpha *after* the dash 11:58
that's been documented that way
because of ambiguity otherwise
Xliff Ohh! Significant improvement of compile times! 12:00
All p6-Projects compile in 93% of the time it took last-week
20201-4-11 was slower. 12:01
Total time single-instance was 13658 for this week. Last week it was 14579, the weeb before 12760
Oddly enough... parallel times increased from 3640s to 3725s 12:03
lizmat well, some race condition was fixed in the scheduler, that may have affected taht 12:04
Xliff Oh. Good. 12:06
raydiak m: sub term:<a-1> { constant $ = sub ($a=1) { say $a } }; a-1("this works in a small number of very specific cases, but please don't do it. like ever.") 12:22
camelia this works in a small number of very specific cases, but please don't do it. like ever.
raydiak is a bad example
and on that note...g'night all \o
lizmat gnight raydiak
El_Che so far 2021.04 is building fine 12:27
lizmat looks forward to be doing "apt-get upgrade" on her Debian box 12:28
El_Che fedora 32 is the only one still running
lizmat the fastest / easiest way to run Raku in production so fae
*far
El_Che then tag and release
lizmat at least for me :-)
El_Che I always do a round of check before releasing it 12:29
I don't expect fedora to fail, so the package soon be up in around 20 minutes or so 12:30
(the upload is also automated when tagged)
tonyo those changes in master? maybe time i should rebuild 12:33
El_Che lizmat: packages now being build github.com/nxadm/rakudo-pkg/runs/2431595098 12:44
lizmat El_Che++ 12:45
ctilmes rakudo 2021.04 is ready on alpine edge 12:56
mscha I've just (finally) installed the latest Rakudo Star, and doing some benchmarking... 13:08
my @primes = (^∞).grep(&is-prime); say “@primes[1_000_000] ({ (now - INIT now).fmt(‘%.2f’) }s)” 13:09
raku-2020.10: 15485867 (6.55s)
raku-2021.02.1: 15485867 (9.56s) 13:10
Significantly slower??
(Still quite a bit faster than raku-2020.05, which took about 38 minutes.:-)  ) 13:11
m: my @primes = (^∞).grep(&is-prime); say “@primes[1_000_000] ({ (now - INIT now).fmt(‘%.2f’) }s)” 13:12
camelia 15485867 (8.39s)
lizmat m: say (^∞).grep(&is-prime).skip(1_000_000).head; say "({(now - INIT now.fmt(‘%.2f’)}s)” 13:15
camelia 5===SORRY!5=== Error while compiling <tmp>
Unable to parse expression in parenthesized expression; couldn't find final ')' (corresponding starter was at line 1)
at <tmp>:1
------> 3head; say "({(now - INIT now.fmt(‘%.2f’)7⏏5}s)”…
lizmat m: say (^∞).grep(&is-prime).skip(1_000_000).head; say "({(now - INIT now).fmt(‘%.2f’)}s)”
camelia 5===SORRY!5=== Error while compiling <tmp>
Unable to parse expression in double quotes; couldn't find final '"' (corresponding starter was at line 1)
at <tmp>:1
------> 3 say "({(now - INIT now).fmt(‘%.2f’)}s)”7⏏5<EOL>
expe…
lizmat m: say (^∞).grep(&is-prime).skip(1_000_000).head; say "({(now - INIT now).fmt(‘%.2f’)}s)" 13:16
camelia 15485867
(7.28s)
lizmat mscha: it pays not to have to cache 13:17
mscha lizmat: still a lot faster on 2020.10 (5.43s) than on 2021.02.01 (8.19s) 13:21
lizmat mscha: can't disagree with that
oddly enough the is-prime handling was supposed to have been made faster in the past 6 months 13:22
or was that before 2020.10? hmmm... can't remember for sure
mscha It's certainly many magnitudes faster than in 2020.05 (38 minutes).
lizmat mscha: would appreciate if you could find out what made this change 13:23
mscha lizmat: I don't think I'm able to do that.  I just install Rakudo Star once in a while and don't really follow the development provess. 13:25
process
lizmat mscha: no worries :-)
El_Che github action is action up, launched a new tagged build :/ 13:42
(nothing to do with the rakudo release or rakudo-pkg, just github)
demostanis[m] github.com/demostanis/rakudostarplus 13:49
lizmat afk for a few hours&
El_Che demostanis[m]: you should add a plus 13:55
MasterDuke the recent slow down in mscha's example is the new coercion protocol merge (and then some optimizations after the initial merge, but it's still slower than before). i don't think it's related to is-prime 14:01
El_Che weekly: rakudo-pkg for rakudo 2021.01 released, added packaged for newly released *buntu 21.04 14:03
lizmat: ==^
demostanis[m] <El_Che "demostanis: you should add a plu"> What do you mean? 14:18
El_Che github.com/demostanis/rakudostarplusplus would be a cooler name 14:20
demostanis[m] Rakudo Star+ isn't that bad, and ++ sounds like it's written in C++ 14:24
Also why isn't rakudo.org written in Raku?
El_Che the ++ is a reference to augementing a variable in many languages 14:29
$var++
masak "incrementing"
El_Che better
damn thesaurus
:)
masak language is, what's the word, hard 14:30
El_Che yet, not rigid
masak probably something to be thankful for, though 14:31
demostanis[m] "Rakudo Star, INCREMENTED"
masak if we could only speak in formally correct utterances, then not much would get said
El_Che "correct" is a very normaive stance on language 14:55
lizmat El_Che: $ raku -v 15:57
Welcome to Rakudo(tm) v2021.04.
:-)
El_Che :) 16:13
Marcool Hi all, is there a hard limit on the length that a constant list can be? 16:45
I'm hitting a compile time error trying to gobble a large wordlist into a constant (to save time on runtime)
Bytecode validation error at offset 4741598, instruction 388958: argument index 63404 not in range 0..63403 16:46
the code is something like:
lizmat interesting! nine ^^
Marcool unit module Dict; constant @dict is export = (loooooong list of words);
and in the executable: 16:47
use Dist; say @dict[25000] #for example; exit;
use Dict* of course
lizmat do you actually have to do the @dict[25000] to get the error, or is "use Dict" enough ? 16:48
Marcool lizmat: I'll give it a try 16:49
Marcool it takes a while, it obviously gets quite far in the precomp, and fails, clearly, on attempting to insert item number 63404 into (something?) (native struct of some kind?) 16:50
lizmat 63404 is a bit of an odd number
close to 64K but not quite 16:51
Marcool yeah I was trying to see if there was a power of 2 anywhere there but there isn't that I can see
that's right, 64K is the closest, but not exactly off by one or anything
nope, same error without the say @dict[whatever] 16:54
just use Dict; is enough 16:55
wc -l Dict.rakumod -> 325552
one array entry per line 16:56
incidentally parsing that in a text file a _runtime_ works fine, like a classic my @lines="dict.txt".IO.lines;
lizmat interesting 17:04
I think this is worth making an issue about 17:05
Marcool thanks for the interest :) 17:06
do you want me to do so or would you rather do it?
lizmat Marcool: if you could do it, please !
Marcool I have also run it with --ll-exception and have a trace if that's helpful
sure no problem 17:07
lizmat yes, that would be helpful, thank you!
Marcool github.com/rakudo/rakudo/issues
?
or moarvm ?
lizmat feels like a Rakudo issue atm to me
Marcool ok thanks, I'll do that right away
lizmat ++Marcool
Marcool done 17:26
github.com/rakudo/rakudo/issues/4344
let me know if there's anything else I can do to help
[Coke] the only place 63403 or 63404 appear in the source is in nqp/MoarVM/src/strings/gb2312_codeindex.h, in an unlikely location. 17:41
gfldex m: class NotNil is Nil {}; class C { method NotNil() { NotNil.new } }; sub s(NotNil()) {}; s(NotNil.new); 20:36
camelia Impossible coercion from 'Nil' into 'NotNil': method NotNil returned a type object Nil
in sub s at <tmp> line 1
in block <unit> at <tmp> line 1
gfldex I'm almost certain that NotNil is not Nil. 20:37
gfldex m: class NotNil is Nil {}; class C { method NotNil() { NotNil.new } }; sub s(NotNil()) {}; s(C.new); 20:45
camelia Impossible coercion from 'C' into 'NotNil': method NotNil returned a type object Nil
in sub s at <tmp> line 1
in block <unit> at <tmp> line 1
gfldex And I'm sure NotNil did not return Nil.
C.NotNil that is
moon-child m: class NotNil is Nil {}; say NotNil; say NotNil.new 20:48
camelia Nil
Nil
gfldex m: class NotNil is Nil {}; dd NotNil; dd NotNil.new 20:49
camelia Nil
Nil
gfldex o.0
gfldex m: class NotNil is Nil {}; my \nocontainer = NotNil.new; dd nocontainer; 20:50
camelia Nil
lizmat m: m: class NotNil is Nil {}; my \nocontainer = NotNil.new; dd nocontainer =:= Nil 20:56
camelia Bool::True
lizmat interesting
you need to provide your own .new for the NotNil class, as Nil.new =:= Nil
m: dd Nil.new =:= Nil
camelia Bool::True
gfldex m: class NotNil is Nil {}; my \nocontainer = NotNil.new; dd nocontainer.WHAT; 20:58
camelia Nil
gfldex m: class NotNil is Nil {}; my \nocontainer = NotNil.new; dd NotNil.WHAT;
camelia Nil
gfldex m: say Failure.new.WHAT;
camelia (Failure)
gfldex m: class NotNil is Nil { method new { use nqp; nqp::create(self)} }; class C { method NotNil() { NotNil.new } }; sub s(NotNil()) {}; s(C.new); 21:03
camelia ( no output )
gfldex m: class NotNil is Nil { method new { self.CREATE }; class C { method NotNil() { NotNil.new } }; sub s(NotNil()) {}; s(C.new); 21:04
camelia 5===SORRY!5=== Error while compiling <tmp>
Missing block
at <tmp>:1
------> 3l.new } }; sub s(NotNil()) {}; s(C.new);7⏏5<EOL>
gfldex m: class NotNil is Nil { method new { self.CREATE } }; class C { method NotNil() { NotNil.new } }; sub s(NotNil()) {}; s(C.new); 21:05
camelia ( no output )
gfldex We may want to write that down somewhere …
neshpion what does Str.fc do? docs say it's for doing caseless comparisons but `$thing.fc.contains("SeArCh")` keeps returning false for me 21:39
neshpion m: my $thing = "my STRING!"; say "string? ", $thing.fc.contains("string"); 21:40
camelia string? True
neshpion o.o
neshpion actually i'm trying it on a heredoc not a regular string 21:41
neshpion m: my $thing = "YEET"; say $thing.fc.contains("yeet"); 21:42
camelia True
neshpion m: my $thing = "yeet"; say $thing.fc.contains("YEET"); 21:43
camelia False
neshpion that's what my problem is, i'm checking using upper case
lizmat m: say "YEET".fc eq "yEeT".fc
camelia True
lizmat you need to use the .fc on both sides of the eq
.fc is not guaranteed to give you anything you can do a reliable .contains on 21:44
neshpion m: say "yeet".fc.contains("YEET".fc) 21:45
camelia True
neshpion ok
lizmat well, even that could cause false positives 21:46

Powered by Cro and the Raku® Programming Language.

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

Thank you!