🦋 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 demostanis[m]: I know it's several hours after the fact, but maybe you'll see this in the scrollback. 12m34s on a ryzen 5 2500u laptop (4 smt2 cores @ 2ghz/3.6ghz turbo) running manjaro...but I forgot to pass -j so that's single-threaded :P 02:27
actually I don't know how to parallel build rstar where you don't call make yourself, -j is a make thing. summerisle got any tips? 02:38
moon-child I don't think it's possible. I usually build the components individually myself 02:45
(though nqp and rakudo builds don't seem to be particularly parallel. Mvm is) 02:46
(well, nqp and rakudo probably _could_ be built in parallel, but the makefile isn't set up in such a way that make knows how to do that)
raydiak just came across this, gonna try export MAKEFLAGS="-j<whatever number>" 02:49
sounds reasonable that the makefile would have to take special care for it to even work in parallel, but idk what summerisle must have meant by "56 threads" if it's not possible 02:50
raydiak looks like it will run that way for moar, but the bulk of everything else just runs in serial anyway. guess that explains why my 2019 low-mid-range laptop only took 6x as long as some 64-core monster... 02:55
and yes I agree, I don't use rstar myself. the question just made me curious. I use rakubrew, unless I'm trying to hack on rakudo (which never happened much and hasn't happened at all in a very long time) 03:02
-j8 only dropped me to 10m55s, so around a 10-15% time savings 03:04
hard to say anything specific with a laptop anyway, the room is cooling off now that the sun is down, some parts could have still been a bit heat-soaked from the run before it, yada yada 03:06
demostanis[m] <summerisle "demostanis: if it's any help (it"> That's so fast... 08:40
Well I made a small Perl script which can do pretty much like Rakudo Star but with support for GPG verification, fetching through git, and parallel installation for modules 08:41
I'm sure it's faster than R* 08:42
El_Che if you want fast, use a pkg :) 08:44
demostanis[m] Rakudo Star isn't much packaged... it's not even in Arch repos, and in AUR it's a very very very outdated version 08:45
El_Che If you're compiling stuff I completely miss the use case of star 08:46
as you can build modules yourself
demostanis[m] The goal is to then package this new version 08:47
El_Che package rakudo and zef
modules are of of date the day you package them
demostanis[m] But my script also installs some modules 08:48
El_Che so like dist do, I would package modules separately
demostanis[m] "of of date"?
El_Che yes, r is not release often and modules have new versions in the meanwhile
modules have a different release cycle (whenever they want to release a bug release or feature) than rakudo (monthly) or star (varies, last time I checked yearly) 08:49
demostanis[m] My script isn't only for speed
El_Che go ahead with the script, no problems about it 08:50
just saying that assuming the 3 release cycles are related is a common error
demostanis[m] But yeah, probably one should package Raku modules for distros
El_Che for me at this stage of the ecosystem is a packaged raku + zef the way to go 08:51
once it's more mature distros version will be good enough
demostanis[m] And R* will become useless? 08:52
El_Che no, there is a use case for many people I think eg windows 08:53
there isn't any use case for my usecase
(I use Linux and containers)
I understand "with batteries" as a great stdlib of a language and raku delivers on that 08:56
demostanis[m] You mean that packaging additional modules like R* does might be useless for most users as Raku already has "batteries included"? 08:59
packaging in the default install* 09:00
El_Che no, I mean distribution of the compile with a list of modules
I think the best scenario is like how all languages are packages
a package for the compiler/runtime and separate packages for modules that are updates on their own schedule 09:01
that's what most dist already do for raku 09:02
however, for my own use case I prefer packaged rakudo + zef and I'll retrieve my own modules. In the future I would love to see these modules in directory of my project, e.g. vendored 09:03
(afk) 09:06
moritz an approach similar to python's virtualenv would be nice, yes 11:45
masak lizmat: on second thought, I think it might very well work if you just say "savoring a nice Chateau 4573562 right now" 11:52
lizmat that would be *very* futuristic 11:53
masak yes, but when has that ever stopped us
lizmat but yeah, give or take a few miliion years from now
true
masak .oO( the future is already digitized, we just got to wines much sooner than we expected ) 11:54
lizmat Raku, the programming language for the aeons
masak ok, so what I'm hearing is: ditch hierarchical CPAN-style module names, and rename all modules according to the naming scheme "Chateau 4573562" 11:55
I hope I got that right; it's being turned into law as we speak
lizmat
.oO( good thing we tend to be law breakers )
11:56
El_Che masakm, lizmat: soundtrack for your discussion www.youtube.com/watch?v=L397TWLwrUU 13:09
Geth doc: a26ad28489 | (Stoned Elipot)++ | doc/Type/Range.pod6
Correct wording
16:43
doc: 0c478083eb | (Stoned Elipot)++ | doc/Type/Range.pod6
Refer to List.fmt for Range.fmt
linkable6 Link: docs.raku.org/type/Range
Geth doc/range-cmp: c02da92dc7 | (Stoned Elipot)++ | doc/Type/Range.pod6
Rewording and completion for Range infix:<cmp>
16:45
doc: stoned++ created pull request #3873:
Rewording and completion for Range infix:<cmp>
raydiak m: use MONKEY-SEE-NO-EVAL; my @a; @a[1] = 1; say @a.raku; say @a[0]:exists; my @b := EVAL @a.raku; say @b.raku; say @b[0]:exists; 16:46
camelia [Any, 1]
False
[Any, 1]
True
raydiak not only does .raku throw away sparse array information, I don't think we even have a syntax which could properly represent it as an expression without a do block. list assignment to a slice could work to construct it, but as an expression it would return the list of values on the right of the assignment instead of the sparse array, so you'd still have to wrap it in a do block so you can name the array and 16:54
return it without exposing the temporary name to the surrounding context
xinming releasable6: status 18:10
releasable6 xinming, Next release will happen when it's ready. 2 blockers. 191 out of 191 commits logged
xinming, Details: gist.github.com/bc1759028b69acb492...a92e0fbb06
lizmat raydiak: [,1] *could* be such a thing I guess 18:40
m: dd "use nqp; [nqp::null,44]".EVAL.raku # alas, not the same 18:41
camelia "[Mu, 44]"
lizmat raydiak: care to create a problem-solving issue for that ? 18:48
raydiak lizmat: sure thing 18:55
lizmat I guess we need some special value of Mu to indicate a hole 18:56
similar to IterationEnd
Tirifto[m] Hello! If I have a mutable object I’d like to make immutable while the program runs, should I just coerce it to a similar immutable type (e.g. Array → List), or is there a nicer mechanism to arrive at something similar? 18:57
lizmat Array.List *won't* make the entries immutable 19:05
raydiak lizmat: that was the first thing I thought, but now I'm not sure an actual value is necessary. we already have :exists for logical tests, and your ",1" proposal gives us a syntax to indicate where something shouldn't :exist
lizmat Tirifto[m] but why do you want to do that? To make it a value type ? 19:06
raydiak: I'm pretty sure there have been huge discussions about ,, in lists
and I think the consensus was that they *should* be a syntax error
as there is ambiguity 19:07
raydiak do you recall what sort of ambiguity?
lizmat and lack of clarity, e.g. when the first comma is on the end of a line, and the next line starts with whitespace and a comma
that's an easy mistake to make 19:08
raydiak I suppose I could see that, fair enough. I still like ,, more than another value/type/thing, but I'm certainly no language designer 19:10
lizmat it's one of the lessons learned from Perl, like not wanting sigil variance 19:12
in Perl ,, is just the same as , if I recall correctly
otoh, the result of such a discussion could be that existedness of an Array element is just not roundtrippable 19:14
as supporting a special value would definitely affect parsing performance 19:15
afk for half an hour or so
raydiak I definitely agree that ,, shouldn't just collapse to , 19:17
but I wonder if sparse arrays were considered in the previous discussions. I think using ,, to skip an element is totally reasonable (and probably does exactly that in some other languages, though I can't cite them off the top of my head) 19:19
as far as just saying "sparse arrays can't round-trip"...I don't like that at all. afaik, .raku is definitely intended to be an EVALable thing to produce an identical data structure, and existence is definitely part of the data structure. otherwise we're basically conceding "Raku doesn't support sparse arrays. Use a hash instead." 19:23
Tirifto[m] lizmat: If ‘value type’ means what I think it does, then probably. I just thought that immutability might make the intention behind the code clearer and improve performance, although I don’t really know if the latter’s true. :P 19:30
raydiak lizmat: github.com/Raku/problem-solving/issues/279 19:39
raydiak Tirifto[m]: I just tested, and it appears that coercing an Array to a List actually does make the entries immutable (at some point in the past, that wasn't the case) 19:51
though I'm uncertain of the performance impact, and personally I doubt that sprinkling coercions around in your code will actually make it clearer from a readability standpoint, though I do understand what you're saying about conveying the semantic intention 19:52
Tirifto[m] raydiak: Thanks for testing! It might very well be the case that it won’t be much help. I also didn’t think about it too deeply, but I might give it a try and see how it goes. :-) 20:13
lizmat raydiak: interesting... but it doesn't make the List a ValueType :-( 20:29
raydiak Tirifto[m]: happy to help! TIMTOWTDI, definitely. if you like it and it does what you want, go for it. the only other thought I have is premature optimization. if this isn't in a hot path, the argument could be made that your time and the verbosity of the code would be better allocated elsewhere. and if it is in a hot path, also keep in mind that the coercion itself probably has some runtime cost
lizmat: are Lists usually value types? I never really thought about trying to compare lists by identity... 20:31
lizmat no, because Lists *can* contain mutable elements
m: my $a = 42; my $b = 666; ($a,$b) = ($b,$a); dd $a, $b 20:32
camelia Int $a = 666
Int $b = 42
lizmat ^^ examples of lists with mutable elements
raydiak huh 20:34
m: my ($a, $b, $c) = ^3; my @a = $a, $b, $c; @a := @a.List; say @a; @a[0] = 1;
camelia (0 1 2)
Cannot modify an immutable List ((0 1 2))
in block <unit> at <tmp> line 1
raydiak coercion from an Array to a List seems to be special-cased to unbox all the elements. if there's no intermediate array, it's mutable: 20:37
m: my ($a, $b, $c) = ^3; my @a := ($a, $b, $c); say @a; @a[0] = 1; say @a;
camelia (0 1 2)
(1 1 2)
lizmat well, as you said, coercing an array to a List apparently deconts
sena_kun .weekly twitter.com/koto_san_kana/status/1...1617976324 20:41
.note twitter.com/koto_san_kana/status/1...1617976324
weekly twitter.com/koto_san_kana/status/1...1617976324
haha, pathetic 20:42
sena_kun off
raydiak sena_kun++ thank you! 20:45
lizmat sena_kun++ # retwat
lizmat notable6: weekly twitter.com/koto_san_kana/status/1...1617976324 20:47
notable6 lizmat, Noted! (weekly)
lizmat ^^ sena_kun
raydiak lizmat: do we have a deeply immutable compound/"listy" value type? 20:48
lizmat not in core
modules.raku.org/dist/Tuple:cpan:ELIZABETH 20:49
raydiak ah...how many datatype modules do you have? that's the third of yours I've encountered today :) 20:50
lizmat Let's just say I'm more a backend than a frontend person :-)
raydiak that sounds dirty... 20:51
lizmat meh 20:51
I guess a dirty mind is a joy forever :-)
raydiak haha good point 20:52
could Tuple implement type constraints or is default()? or would that mess up its usability/performance for core purposes? 20:57
I'm not even sure if those are things implemented by the class itself, or if that happens elsewhere. maybe it just works as is? 21:00
lizmat interesting idea... hmmm 21:02
it was developed to be as fast as possible given the situation... hence it is directly using VMArrays under the hood 21:03
and those don't know about types 21:04
raydiak: please create an issue for that... to prevent this notion from falling through the cracks 21:06
in the Tuple repo please :-)
raydiak okay :)
done 21:09
lizmat thanks! 21:10
raydiak of course, happy to help 21:11
basically makes it a Blob for higher level non-native value types 21:12
lizmat Hmm... maybe it should therefore be incorporate this into the Blob role 21:15
m: Blob[Any] = "foo", 21
camelia Could not instantiate role 'Blob':
Can only parameterize with native int types, not 'Any'.
in any protect at gen/moar/stage2/NQPCORE.setting line 1216
in block <unit> at <tmp> line 1
lizmat m: my Blob[Any] $foo = "foo", 21 21:16
raydiak that was a pretty big split 21:22
lizmat yeah... :-) 21:26
raydiak not sure about making it a Blob formally. Blob is pretty binary-focused. it has methods like .bytes, .decode, .unpack, all that stuff
lizmat true... but it *is* immutable, contrary to Buf 21:27
lizmat but yeah... maybe not 21:27
raydiak my vote would be Tuple does Positional, and is more of a sibling of Blob 21:29
lizmat well, Tuple does already do Positional :-) 21:29
raydiak heh I assumed. I was just looking at the type graph for Blob and thinking in those terms 21:31
japhb FWIW, CBOR::Simple will treat basic Positional as generic "holds anything, every item may be different". Blob is already special cased (making it quite fast indeed), as will the other native typed arrays once I implement the appropriate extension that allows avoiding endian swaps. 21:33
raydiak oh japhb, I was meaning to ask...can you add your benchmark script to the CBOR::Simple repo? like in a tools subdir or something? 21:36
raydiak I had some thoughts about performance improvements, and even if nothing I try ends up working out it'd be an interesting/educational real-life test case anyway 21:38
MasterDuke japhb: wouldn't it make sense to handle Iterable same as Positional? 21:45
raydiak I have a couple questions about the current state of META files. The first is version. I've seen different places say version is optional, it's required but '*' is okay, or it's required and must be an actual version number. which is correct? where do I find authoratative information on this (couldn't find it in roast the last time I tried)? What do I do if a module is in a nascent state and incrementing a 22:14
version number for every breaking change is a burden? if an actual number is required, can I just leave it at e.g. "0" or "0.0.1" and keep making changes or will that cause something to misbehave in some external tool or ecosystem or package manager or whatever? kinda wonder if I shouldn't just somehow use the git commit hash, or "major.minor." prepended to an incrementing number for every commit like an index
into the commit history since the last major/minor tag or along those lines...
or are we just really trying hard to strong-arm people into doing versioning correctly even at the earliest alpha stages of development? 22:15
also, what if people explicitly ask for an older version from their use statement? it can be available in the git repo and tagged and everything, but the META only declares the latest version 22:18
raydiak my other question atm is about "auth". is github: or zef: or cpan: or whatever really necessary? does it get functionally used for anything? what if I migrate from one to another, won't that break people's existing use statements if they're explicit about auth? or have a same-named account on multiple and don't personally consider any particular one "more authoratative"? wouldn't it just be better to use my 22:27
handle without tying it to one specific service, which seems like a potential failure point out of my own control? also what if I want the authority to be something tied to my own domain/server? just write whatever I want in there? then what's the point of the service: prefix at all?
japhb raydiak: In reverse order, the ones that I can answer: 22:30
lizmat is glad that japhb is around to answer questions while she hits the sack 22:31
japhb The name needs to be unique within some naming authority, and that naming authority has to be the one that controls access to that data store. We just have some recognized naming authorities already, but there's no reason you couldn't define/enforce some other one.
Have a good night, lizmat! :-) 22:32
raydiak g'night lizmat! it was nice chatting with you 22:32
japhb raydiak: When you upload packages to zef or cpan, you are uploading a snapshot tarball of a particular version. So they can keep all the versions they want.
japhb :api<0> is explicitly saying "I've thought about it, and I can tell you right now the API is still liquid." 22:33
Version '*' turns out to be a problem; its interpretation causes issues, so don't use it. fez won't even let you. 22:34
Yeah, I can add the benchmark script; I was planning to at some point, but kept forgetting. :-)
japhb MasterDuke: Iterable also includes Associative and Seq, and those both need some care to get right. Associative is already handled, Seq I'm not sure if I'll .cache in order to enforce writing only definite lists, or if I'll consider that a clue that the user wants indefinite-length array output. 22:36
Did I miss anything? 22:37
MasterDuke i suspected something like that, makes sense
raydiak afaik, Iterable means you can loop over it. e.g. Associative (actually, Map) does Iterable. doesn't mean all Iterables have to implement Map. e.g. Lists are also Iterable 22:41
japhb Hmmm, should the benchmark script go in tools/ or examples/? 22:42
raydiak: Yes, I know, I meant that Associative has to be handled separately in CBOR than other types of Iterables, since it has a special encoding and special rules about key order and such. 22:43
japhb Which is to say an Associative and an Iterable containing Pairs is NOT the same in CBOR. 22:44
I guess benchmarking is more of a tool thing than an example ...
raydiak hmmm...I could see a good justification for either. if it has facilities for repetition and timing and outputting that kind of data, put that part in a script in tools, and the actual data and usage in examples? 22:45
I could also see an argument for refactoring the part I suggested go in examples into tests in t, and have the benchmark tool run certain specific test files in loops with timing 22:47
japhb raydiak: Interesting idea. I don't think I'd want t/ scripts to be slow enough to actually give good performance measurements (though that might be useful for xt/), because it would slow down the edit/run/debug loop 22:50
Anyway, I just pushed it.
As the comment at the top says, you'll need a medium-large JSON file to test with (to compare against JSON::Fast on its "home turf"), and I just used the zef ecosystem data for that. 22:51
raydiak good point
thanks!
raydiak wonder if there'd be much difference using a different dataset, especially one more deeply nested, or more numbers instead of strings, etc. if you were wanting to use this for MUGS, I'd expect many games to use a lot more numbers 22:56
raydiak japhb: also, I was just curious for my own education, what factors made you choose CBOR over e.g. BSON or UBJSON or whatever else (whether JSON-inspired/related or not)? 23:05
japhb raydiak: The fact that it was self-describing and self clocking, the number of IETF specs that refer to it, the fact that it was explicitly designed to have a relatively simple codec in most languages, the (actively used) extensibility, the richer data model, the fact that it didn't require extra encoding for utf8 or blob (both just slot right in with a leading bytecount), ... 23:10
raydiak: I'm still working on filling out more different scenarios in the perf-test, especially once I start doing packed structures more complex than 8-bit uints. But I spent yesterday more working on the unnecessarily slow bits that I'd already found. :-) 23:11
I've got an idea for a restructuring of the decoder that I *think* will be an across-the-board improvement (faster for decoding any non-trivial structure), but I have no idea whether it will be a few % or a speed doubling. 23:13
We shall see. :-)
raydiak sounds like it's off to a great start! have you tried it under the moar profiler yet? 23:14
japhb Nope, haven't done that yet. I wish we had a good per-line profiler, like NYTProf is for perl5, because the routines here are HUGE with big branching structures, so per-call statistics are too rough. :-/ 23:16
OTOH, the Moar profiler does per-block, doesn't it? That might work out.
raydiak I don't recall, haven't tried it in many years, I mostly just remember that it exists 23:17
japhb nodnod
raydiak that was one of my optimization thoughts: I was under the impression that these days, multis are often faster than long sets of conditionals 23:18
kawaii which operator would I use to do three-way string comparison of three different variables? 23:21
raydiak leg for strings specifically 23:23
kawaii oh I didn't know about leg! 23:24
lemme try!
raydiak or coll/unicmp may be more correct depending on your intention. and sort/collate may be easier and/or faster if you're sorting a list of strings 23:29
I don't actually know much about these things, just look at docs.raku.org/language/operators and search the page for "three-way" 23:31
so in retrospect, it would have been more accurate to say for strings specifically: leg by codepoint, unicmp by default lexographic order, or coll by lexographic order customizable via $*COLLATION 23:41
japhb m: given 5 { when * % 2 { say "Odd"; &?BLOCK(6) }; when * %% 2 { say "Even" }} 23:44
camelia Odd
Even
japhb ^^ Why does that even work? Why does &?BLOCK go to the given and not to the when?
raydiak heh, even that isn't right. leg is also lexographic; cmp (not string-specific) is by codepoint, and coll is something I don't fully understand yet