#raku-dev on 14 July 2021 - Raku Programming Language Log

🦋 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

10:36

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..

11:34

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

future

(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