🦋 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: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
00:00 reportable6 left 00:03 reportable6 joined 03:56 linkable6 left, evalable6 left 03:58 linkable6 joined, evalable6 joined 06:00 reportable6 left 06:02 reportable6 joined 06:12 kurahaupo left
nine Or just have the build system take care of it by adding the appropriate version requirements to the test files. We have been through this before. This is something that's only needed for roast. The solution should be in roast as long as it's somehow possible, which it is. 07:09
07:47 kurahaupo joined
lizmat gfldex: the use of an environment variable was discussed at the RCS, and voted against by jnthn 08:27
nine: disagree that it's just something for roast: I would like to run my modules tests with the most recent version of Raku as well 08:28
and not have to do any fudging of the test files
nine But why? 08:46
lizmat But why what? 08:47
gfldex: also, I would generally only be interested in a "raku-latest" 08:52
09:04 kurahaupo left 09:11 kurahaupo joined
nine Why would you want to (regularly) test your module with a different compiler version than it was written for? It will not be run with a different version. 10:04
m: my constant nope = CORE::<&not>; 10:06
camelia ( no output )
nine This ^^^ currently doesn't find the &not function with the RakuAST frontend. The reason is that the initializer is run at BEGIN time, so it doesn't actually have the setting as an outer lexical context, so PseudoStash doesn't find it. 10:07
The same is true for the old frontend. However, that creates that jumbo frame containing all visible lexical symbols. This includes CORE-SETTING-REV which we mark those setting frames with. Incidentally the same frame contains &not, so it works out in the end. But it's all fake. 10:08
m: use v6.e.PREVIEW; dd CORE::OUTER::OUTER::OUTER::OUTER::<&not> 10:10
camelia Sub not = proto sub not (Mu $, *%) {*}
nine m: use v6.e.PREVIEW; dd BEGIN CORE::OUTER::OUTER::OUTER::OUTER::<&not>
camelia Any element{'&not'} = Any
nine As evidenced by this ^^^ discrepancy
We can't just add forceouterctx the setting as an intermediary (unfinished) scope may shadow setting symbols. 10:13
I guess I could change codegen of CORE:: from PsuedoStash.new<CORE>.who to a WVal containing a suitably prepared PseudoStash 10:19
lizmat nine: this would only apply to modules that do *not* have a language version pinned 10:35
I try not to pin language versions in modules: but I would like to know whether they run in the current dev language version 10:36
1. to find out regressions that roast didn't catch
nine Why would you ever want to not pin the language version in a module?
lizmat 2. to pin the module to a language version if it *is* new syntax / semantics that are breaking it
because of maintenance: a module that will work in all language versions is less maintenance than a module that is pinned to a language version that may not be supported in the future 10:37
nine That is really like russian roulette. I don't know why we would want to support that :)
lizmat why is that Russian roulette > 10:38
?
that's why we have tests, no?
nine Because the module can break any time we do a backwards incompatible change in a new language version. Which is the whole point of versioning the language in the first place
lizmat also note: I have currently 194 modules in the ecosystem
most of them I cannot foresee ever not working in a future language version 10:39
and that's why I want to know before the dev language version becomes default
when a backwards incompatible change affects a module of mine 10:40
(or any other unpinned module in the ecosystem, for that matter)
nine Just pin the language version and you don't have to worry about that any more. No need for environment variables or anything. 10:41
What you are asking for is adding a new mechanism so you can do tedious work because you just don't use the mechanism that's already there, that's super easy and that's meant precicely so you wouldn't have to worry about that at all. 10:44
lizmat ok, so I pin all of my modules to 6.c
nine If that's the version they are written for, then yes. 10:45
lizmat then years from now, 6.c will no longer be supported, and all of my modules stop working without reason
nine Which is precicely why we won't suddenly stop supporting 6.c.
That's the social contract.
lizmat that's beside the poin
t
if Raku is to be a 100year language, 6.c *will* become unsupported at some point 10:46
nine No. That is not how it is intended. 10:48
lizmat ah?
nine Also we simply don't have a reason to stop supporting any older version. That's why we wanted to have everything as lexically as possible, so we can do breaking changes in new versions without touching the old one. 10:52
lizmat I think there's a solid reason for wanting to stop support of 6.c, namely the await behaviour 10:53
also: we could stop supporting 6.d to be able to drop NQP's broken sprintf support 10:56
.oO( "who ever needs more than 640K" )
 10:57
nine await behaviour? 11:04
NQP has never been coverend by any guarantees. We're basically free to remove whatever we want. 11:06
lizmat the fact that a thread relinquishes itself to the pool when it's awaiting something, that's 6.d is it not? 11:07
this is not about NQP
nine I remember that 6.d fixed some behaviour related to await. So everything's fine, isn't it? New code can have better behaviour and old code that's presumably written with the old behaviour in mind can continue undisturbed. 11:09
lizmat indeed... but the old behaviour is *bad* in multi-threaded environments 11:10
and in many cases, modules pinned to 6.c would work better in 6.d
maybe all cases 11:11
nine So authors should port them and we should encourage them to do so. Just removing support for 6.c is the most unfriendly way to do that. Especially since it's just about "would be nice because it works better", not something critical that's blocking anything. 11:13
11:37 evalable6 left, linkable6 left 11:38 linkable6 joined 11:39 evalable6 joined 12:00 reportable6 left 12:02 reportable6 joined
jdv m: $*RAKU.compiler.version 12:51
camelia ( no output )
jdv m: $*RAKU.compiler.version.say
camelia v2023.05.130.gc.452.fdbf.0
12:56 kawaii left 12:57 kawaii joined
Geth rakudo/main: e10e3aa0ce | (Elizabeth Mattijsen)++ | 5 files
RakuAST: more work on declarator doc

  - include trailing newline in declarator doc, just as doc block paras
  - adjust tests and deparsing accordingly
  - allow trailing declarator docs on consecutive lines after declarand		 13:26
lizmat I guess that brings us on 891 ?
meh, 881 ? 13:32
Geth roast: 60e6fd81de | (Elizabeth Mattijsen)++ | S26-documentation/wacky.t
Cleanup wacky trailing declarator doc tests

As discussed at the RSC, the semantics for trailing declarator docs are now:
  - if multiple declarators are on the same line, bind to the last one
  - must start on the same or next line of declarator
  - can be continued on consecutive lines		 13:53
lizmat 882
13:57 linkable6 left 13:58 linkable6 joined 14:35 japhb left, japhb joined 16:34 linkable6 left, evalable6 left 16:36 evalable6 joined 16:37 linkable6 joined 17:04 jdv left, jdv joined
Geth rakudo/main: 77aa79cecd | (Nick Logan)++ | src/core.c/CompUnit/Repository/FileSystem.pm6
Avoid using junctions

Junctions are slow, so we should avoid using them in code that may get run on many items.		 17:48
rakudo/main: d30ac3e48c | (Nick Logan)++ | src/core.c/CompUnit/Repository/FileSystem.pm6
Reduce number of calls to abs2rel

Preciously we always called `.IO.relative` (abs2rel) on every path of the CURFS prefix. This changes that behavior to only do this conversion after we've filtered down to the paths we are interested in.
rakudo/main: 9a5fe3d6e8 | (Nick Logan)++ (committed using GitHub Web editor) | src/core.c/CompUnit/Repository/FileSystem.pm6
Merge pull request #5284 from rakudo/ugexe/curfs-optimizations

Optimize CURFS startup time
17:54 kurahaupo left 18:00 reportable6 left 18:01 reportable6 joined
ugexe I wonder if we could make DIR-RECURSE faster by spawning multiple threads 18:02
lizmat ugexe: I think I tried that, but the overhead of starting threads was not worth it, at least in my tests 18:03
also: recursive (sym)links make that hard, if doubles are handled in different threads 18:04
ugexe i wonder if its still mostly an i/o bound problem anyway 18:07
lizmat pretty sure it is, although maybe less prominent on SSD drives 18:08
MasterDuke how easy would it be to spawn a small number of threads? i.e., not one for every call, but batched
jdv isnt that just m:n like hyper and friends? 18:36
18:48 squashable6 left 18:49 squashable6 joined
Geth roast: d72d32f428 | (Elizabeth Mattijsen)++ | S26-documentation/wacky.t
Todo tests that need RakuAST
 18:57
19:07 jgaz left 20:13 squashable6 left 20:15 squashable6 joined
Geth rakudo/ugexe/dont-squat-common-arg-names-redux: 73888f45ad | (Nick Logan)++ | src/core.c/CompUnit/RepositoryRegistry.pm6
Remove largely unknown flags from installed raku script shims

A mostly unknown feature of the bin script shims CURI installs is that it allows choosing the distribution to load the script from, which allows loading an e.g. older version of some script. However to do so required using the :$name :$auth :$ver :$api arguments which prevents any installed raku bin script from taking any arguments of those names; the shim scripts breaks things such as providing a bin/foo --ver that outputs version information. This change removes those arguments until a better solution can be implemented.		 21:04
rakudo: ugexe++ created pull request #5286:
Remove largely unknown flags from installed raku script shims
ugexe getting a list of all files in my home directory recursively takes about the same time using DIR-RECURSE(...) and File::Find from perl 21:15
I wonder if cutting the number of stat calls in half would even make a difference 21:16
One way of cutting down the stat calls might be to skip the existence check in pull-one() (i.e. only check existence on the path the user supplied to DIR-RECURSE) and just CATCH + ignore file doesn't exist 21:19
since if the paths returned by dir() exist 99% of the time then it might be wasteful to stat everything dir returns 21:20
MasterDuke jdv: yeah, but since it's a recursive function, it would be a little trickier to not spawn a new thread for each call 21:33
ugexe: hm...that could be a good idea
ugexe: `time find . | wc -l` reports 113028 files and takes 0.13s. `raku -e '.say for Rakudo::Internals.DIR-RECURSE("."); note now - INIT now' | wc -l` reports 93867 files and takes 0.93s 21:37
find is going to be pretty heavily optimized, but maybe we can get some closer
ugexe DIR-RECURSE will skip things that starts with . i believe 21:40
"However find has an optimization: it knows how many subdirectories a directory has from its link count, and it stops calling lstat once it knows that it's traversed all the subdirectories." 21:45
22:07 linkable6 left, evalable6 left 22:10 evalable6 joined, linkable6 joined
Geth rakudo/rakuast-phase-cleanup: 12 commits pushed by (Jonathan Worthington)++
review: github.com/rakudo/rakudo/compare/c...0307f7a002		 22:16
ugexe deleting the stat -- github.com/rakudo/rakudo/blob/9a5f...1387-L1389 -- and adding a try block around the other two stat calls (that check if its a file or dir) isn't any faster 23:24
i guess it'd still be nice to do one stat call to contain the information that those two stat calls return
23:52 squashable6 left 23:54 squashable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!