🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:02 reportable6 left 00:03 reportable6 joined 01:03 evalable6 left, linkable6 left 01:05 evalable6 joined 01:06 linkable6 joined 03:08 melezhik left 05:11 quotable6 left, benchable6 left, linkable6 left, releasable6 left, reportable6 left, bisectable6 left, coverable6 left, evalable6 left, statisfiable6 left, greppable6 left, sourceable6 left, committable6 left, bloatable6 left, shareable6 left, tellable6 left, nativecallable6 left, squashable6 left, unicodable6 left, notable6 left, shareable6 joined, sourceable6 joined, tellable6 joined 05:12 notable6 joined, squashable6 joined, statisfiable6 joined, reportable6 joined, coverable6 joined, benchable6 joined, greppable6 joined, bloatable6 joined, evalable6 joined 05:13 nativecallable6 joined, releasable6 joined, linkable6 joined 05:14 committable6 joined, bisectable6 joined, quotable6 joined, unicodable6 joined 06:02 reportable6 left 06:03 reportable6 joined 07:03 evalable6 left, linkable6 left 07:04 linkable6 joined, evalable6 joined 07:10 patrickb joined 08:06 Kaiepi left 08:11 Kaiepi joined 08:51 patrickb left 09:51 evalable6 left, linkable6 left 09:52 evalable6 joined 09:54 linkable6 joined
Geth rakudo: bfa6b295c4 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Various for / map iterator cleanups

  - lose one allocation per call in pull-one
  - fix issue with 'redo' in last iteration of 1 arg in 2 arg block
  - reduce bytecode size by abstracting control exception handling
11:02 linkable6 left, evalable6 left 11:05 linkable6 joined, evalable6 joined 11:23 MasterDuke left
Geth rakudo: 9c69b7d5f6 | (Elizabeth Mattijsen)++ | 2 files
Add SlippyIterator.(push-)control-payload methods

These were first "local" support methods, but it turns out these are more generally applicable. This reduces the bytecode size of the iterator methods, which allows for earlier / easier inlining when the fast path (without 'next' or 'last' statements inside the block being executed) is being repeatedly run..
raydiak been afk all day. a few meandering thoughts about the meta discussion: (1) yes actually I am fairly familiar with how meta is used in rakudo, the logic rakudo follows to locate and load modules, and also how meta is used in module managers both past and present. I did not link that search because it represents the entirety of my awareness. I will attempt to communicate my intentions more clearly in the 11:42
(2) my first thought about the "depends" issue is that the thing I'm proposing should complain about weird-looking contents of anything it is aware of which includes depends and the rest of the currently documented spec, however see further thoughts under #7. it should ensure that the content is valid, and catch things like missing the "requires" level of the hash-of-hash-of-arrays form of depends, as one
example. it should not complain if depends is missing, as it is optional
(3) zef doing magical dependency sniffing is a perfect example, as it would lead to people writing meta files which only work with a single tool which implements unspecced behavior, which is precisely the kind of fragmentation we don't want. if we want to allow for that type of behavior, it should either become part of the next version of the spec, or there should be an extension system to declare that
nonstandard behavior so that at least other tools which don't recognize that extension can say "I don't support this meta file" instead of happily installing modules in a silently broken way without their dependencies. or reporting them incorrectly in a dependency graph or web page, or whatever the particular tool does
(4) as for removing cool possibilities, I again defer to versioning and extensions. any spec, by definition, removes possibilities. that doesn't mean that formalizing things is bad, particularly where interoperability and long-term stability is concerned. I would think something like a "meta-ext" key with an array of extensions e.g. "autodeps" (referring to #3) would provide for the possibilities, and
extentions which become popular may even become part of the next version of the spec, or perhaps part of a set of "standardized extensions" (think "-zef-autodeps" becoming just "autodeps" or so). in this way we could also allow for advanced functionality which is specced, but may not be practical or easy for all tools to implement. it would make the meta files themselves somewhat "modular"
(5) ignoring unknown keys with extra ancillary data I don't see a problem with, as long as they can be safely ignored and the module can still be properly installed/introspected/whatever. an example would be a field for an image and/or icon, or something like that. something which is required functionality for handling the module should be declared as an extension
(6) if doing it in core is really so abhorrent, I still disagree (we build in the whole unicode database, html entities, pod to text, unit testing...but we draw the line at meta files? sounds wrong to me)...but fine, if that's the case, then we need something like roast for meta files. a central implementation-agnostic standard, controlled by the raku community, which all implementations of meta producers
and consumers should aim to comply with, regardless of extra keys or extensions
(7) I can see the argument for not outright failing if parts that a particular implementation doesn't use aren't valid. I can also see the argument that anything which is a standard key should always have valid contents, regardless of whether that key is specifically used. what about suppressable and non-fatal warnings when loading a meta with invalid parts, which only become fatal if you attempt to access
those particular keys through the standard API? if we don't attempt to validate nonstandard keys, and have an extension system, and versioning of the meta spec, and allow the warnings to be suppressed, I think that allows for plenty of growth while still having a formal spec
(8) unfortunately I will continue to be pressed for time until at least the day after tomorrow. even right after I send these messages, I need to get one more thing done before I go to bed and wake up for an appointment tomorrow, and it's already after 4 AM here. but I will continue to backlog and respond when I'm able if we want to continue to consider this 11:43
Geth rakudo: 941349d08e | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Make some more use of the new SlippyIterator methods
12:03 reportable6 left 12:04 reportable6 joined
Geth rakudo/new-disp: 7c3be10e0d | (Jonathan Worthington)++ | 2 files
Filter out multis not accepting a passed named

Since the bind check now works by really invoking the multi candidate and seeing it it ends up failing a type or constraint check, we should pre-filter those that do not accept one of the passed nameds at all. This is an efficiency and memory improvement too, since it means we will not end up with entries for such unviable candidates being put into the candidates list built at a callsite in a non-trivial dispatch.
12:34 MasterDuke joined
nine raydiak: I wonder what META related tests could even look like in roast? We don't have any Rakudo code to test after all 13:33
14:02 frost left 14:45 Altai-man joined 15:45 linkable6 left, evalable6 left 15:47 linkable6 joined 15:48 evalable6 joined
Geth nqp/new-disp: 14a68e9127 | (Jonathan Worthington)++ | src/vm/moar/QAST/QASTRegexCompilerMAST.nqp
Switch the regex compiler to emit dispatch ops
tonyo counter point for #3 - low level magic i agree with, if zef can do it then other tools can do it and dictating how module authors write modules makes for a bad experience in writing modules. rakudo, again, doesn't do anything with depends and shouldn't enforce anything. #4, no one said formalizing is bad - removing flexibility from tools is bad, changing the argument and then defending against that point 16:00
doesn't make the original point invalid. #6 this already exists in fez, if it's on fez then zef can install it. #7 this is my entire point but we don't need an extension system, if rakudo doesn't use it then it shouldn't arbitrarily attempt to validate it (like "depends") because it isn't the authority on whether that information is what the consumer needs. (also, this point is the scope of my
argument). #8 nbd, i'm fine with this mode of communication 16:01
also, for #6 this is the biggest win imo, p6c and cpan both have no validation or guarantees
fez can likely install it* 16:03
argh, zef can likely install it*
jdv it sounds like you are advocating for a single solution, i'm not a fan. 16:35
but i'm just a casual observer
Geth rakudo/new-disp: 76d05b1358 | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Correct multiple dispatch on natives
tonyo jdv: what do you mean by single solution? 16:38
jdv i like the fact that p6c and cpan "ecosystems" exist for the same reason i like that jvm and js raku impls exist - more than one impl/option tends to help lift quality and rout out "badness"
tonyo ah, i'm not advocating for single solution, i'm advocating for tighter controls on the ecosystem side. less about having one and more about having tools built for the job. p6c and cpan both allow you to upload something with bad METAs 16:39
jdv sounds like a feature of a loosely coupled distributed system to me:) 16:40
tonyo i'm advocating fez because it doesn't allow you to upload a "version":"*" to the ecosystem and will make some guarantee that if you download "auth:tony-o" you're getting one of my modules. i can upload to cpan under my pause but in my meta put "auth":"cpan:jdv" and your name is on there
if that's a feature then rakudo shouldn't be validating anything and it should be up the loosely coupled distribution system to figure out how to make it available to rakudo 16:41
my point isn't single server, it's that rakudo shouldn't validate what it doesn't absolutely need. as far as cleaning up the quality of the ecosystem there's more value in building tools designed for the job and not serving distributions that require further processing to even be searched for 16:44
jdv i thought that type of decision making was more for the "recommendation manager" and not the storage backend 16:45
tonyo p6c and cpan both don't index raku dists, zef has to run a cron to re-index them in a way that makes sense to be installed
jdv if you take your way to its conclusion you rule out the possibility of using backends like github/gitlab/a local "registry" like minicpan... 16:46
i'm not arguing specifically for p6c or cpan - just against zef because its single instance only afaik
tonyo you can use those as a backend but you need some guarantees
jdv s/zef/fez/
can i setup a fez on my laptop? 16:47
tonyo pure git anything makes no guarantee that i don't upload some hate speech named modules with your auth name on them
jdv: for sure
jdv so? 16:49
tonyo that degrades the quality of the ecosystem. 16:51
jdv who said the ecosystem has to have the smarts? 16:52
tonyo the goal is improve the quality of the ecosystem.
one avenue is to make rakudo validate the meta
another avenue is to make the ecosystem itself make some guarantee of quality 16:53
uploading modules that get indexed under another user's name is a degradation of quality
uploading modules that supercede all other versions with that name is another degredation of that quality 16:54
jdv i just don't think ruling out certain types of backends is a maximally valuable way to go
tonyo i don't disagree with you..if you reread what i wrote then you'll see i'm not saying that. the quality in those ecosystems could be vastly improved
git is perfectly fine but it needs a better way to be indexed. running crons and making no guarantees of auth to the actual user, that version isn't set in a way that it gets picked by the recommendation manager every time, etc make for poor quality. 16:56
cpan has the same troubles 16:57
jdv are there docs on how to setup a "local fez"?
sorry to start something and run but i have to run:( i think we're not on such a different page as i thought. 17:01
tonyo there arent, you can install fez with zef if that's easier for you. i can also add some docs on how to run it for development purposes
jdv: i think we're of similar thinking - i don't like corners. i just also think that p6c and cpan could be greatly improved for use with rakudo if quality is the goal 17:02
Geth rakudo/new-disp: fa6e94f2b2 | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Implement CALL-ME support

Thanks to new-disp, this can be done by resolving the CALL-ME method at callsite setup time and delegating to the resolved method dispatcher. This means that an invocation of a CALL-ME will be far more efficient, since the original implementation had to resolve the method every time
  (and since it all went through one location that was polymorphic), as
well as do a costly args slurping/flattening dance.
17:19 evalable6 left, linkable6 left 17:20 linkable6 joined 17:21 evalable6 joined 17:33 [Coke] left 17:39 [Coke] joined 18:02 reportable6 left, Kaiepi left 18:03 Kaiepi joined 18:05 reportable6 joined
Geth rakudo: eae82f09fa | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Re-imagine IterateOneWithoutPhaser.pull-one

Makes that method about 10% faster. But in most cases it won't get called, as these simple types of for loops / maps are codegenned as calls to the p6forstmt op. But it's good to see the fallback being a little faster.
In any case, the code is smaller and simpler.
18:06 Kaiepi left, Kaiepi joined
Geth rakudo: d8281722db | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Rework IterateOneWithoutPhaser.push-all a bit

No measurable improvement, but a smaller bytecode footprint
  (576 -> 540)
japhb I get the feeling after new-disp lands that a significant performance boost will come from retuning inline balance, especially with all the work lizmat++ has been doing to shrink iterator footprints 19:19
19:28 melezhik joined
[Tux] Rakudo v2021.06-69-geae82f09f (v6.d) on MoarVM 2021.06-17-g736154d29
csv-ip5xs0.859 - 0.904
csv-ip5xs-208.307 - 10.104
csv-parser27.630 - 27.837
csv-test-xs-200.371 - 0.377
test7.475 - 8.585
test-t1.983 - 2.106
test-t --race0.981 - 0.996
test-t-2033.639 - 34.934
test-t-20 --race9.897 - 10.601
20:07 dogbert17 left 20:19 Kaiepi left, Kaiepi joined 21:40 melezhik left 22:47 Xliff joined
Geth rakudo/new-disp: c8d3e1be60 | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
SomeType($value) style coercions a la new-disp

Compared to the current implementation, we can lift out anything from some to a lot of the work and cache + guard it. The best case is when we have only a single argument to coerce and it is either a bare value or in a Scalar container, in which case we can also guard on the target type, pre-calculate the coercion type, and rewrite the call directly to ... (5 more lines)
23:47 linkable6 left, evalable6 left, linkable6 joined 23:50 evalable6 joined