🦋 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
ugexe it seems like that error means something is calling .indent($some-value-getting-BOOTInt), but I'm not seeing anything that jumps out at me 00:08
Geth rakudo/main: aca81e9225 | (Nick Logan)++ | 2 files
Remove unused transcode compiler option

This appears to have only been used by Parrot. Every other backend has their apply_transcodings function in nqp return the original input without any modifications. This change stops passing the transcoding option.
rakudo/main: 7e552d4797 | (Nick Logan)++ (committed using GitHub Web editor) | 2 files
Merge pull request #5308 from rakudo/ugexe/remove-unused-transcode-option

Remove unused transcode compiler option
nqp/main: 379bc81aa9 | (Nick Logan)++ | 4 files
Remove unused apply_transcoding compiler function

This appears to have only been used by Parrot. Every other backend has their apply_transcodings function in nqp return the original input without any modifications. This change removes the apply transcodings function, and the code that called it.
nqp/main: 1a48ed20b9 | (Nick Logan)++ | 5 files
Remove unused transcode compiler option

This appears to have only been used by Parrot. This change stops passing the transcoding option.
nqp/main: 40f9ee383c | (Nick Logan)++ (committed using GitHub Web editor) | 9 files
Merge pull request #804 from Raku/ugexe/remove-unused-transcode-option

Remove unused apply_transcoding compiler function
01:45 evalable6 left, linkable6 left 01:46 linkable6 joined 01:47 evalable6 joined
MasterDuke hm. should IO::Path (and maybe any other that make sense, like IO::Handle, et al.) get a `has Stat $.stat` attribute that's lazily constructed any time a method is called that currently uses nqp::stat. then any subsequent methods could just use that attribute 01:56
or should everything always make a new nqp::stat call, since the attribute may have gone stale? there are always race conditions, but maybe they'd be worse if we always cached the result of the first stat 01:58
should stat caching default to opt-in or opt-out? 02:01
ugexe i think you'd only want to cache it in the sense of one "action". like if i call .open and it ends up doing 17 stats they should just reuse the one. if i make another request to .open i'd expect it to redo the stat though 02:02
MasterDuke for open i definitely can see the argument to not cache. but for things like .(group|inode|dev|modified|e|<...>) it seems like caching would be fine (or at least, not unexpected) 02:08
ugexe caching e wouldnt work 02:09
MasterDuke you mean because of the way it's currently implemented? or for some other reason? 02:10
ugexe rakudo used to cache .e .f and some others, and it was really broken for doing thing 02:12
like checking if a file exists before creating it is common, and now .e would be cached as false even though its created 02:13
MasterDuke hm. i don't really remember that. any idea more precisely when?
well, the creation could re-do the stat and overwrite the cache
ugexe it could be created by a different call to "whatever/path".IO.open(...) 02:14
like you had to be super aware of the difference between different IO::Path objects even if they pointed to the same thing 02:15
i believe lizmat removed the cache in IO::Path sometime before 6.c
MasterDuke btw, why isn't IO::Path a value type? 02:16
it sounds like you're suggesting not even adding an attribute to IO:* and just doing any caching "manually" where appropriate (i.e., in individual methods which right now make multiple nqp::stat calls)? 02:18
ugexe github.com/rakudo/rakudo/commit/0c...45487a2183 here is the commit where it was added initially i think 02:19
MasterDuke i wonder if i should still make a new Stat (name could be bikeshed) class that users could have access to. i.e., something like `my Stat $s = "foo".IO.stat`, which just has accessors for the different fields 02:20
ugexe github.com/rakudo/rakudo/commit/8d...018a71fc45 -- a commit i made updating the aforementioned cache 02:22
having a .IO.stat seems like a decent idea to me 02:23
or an IO::Path.stat rather
MasterDuke 76f71878da61731f33b457e84c7b0e801c64af66 is where $!e was removed, by zoffix in 2017 02:26
76f71878da61731f33b457e84c7b0e801c64af66 is where $!e was removed, by zoffix in 2017 02:27
02:27 linkable6 left
ugexe ah yep 02:28
japhb The "explicit caching" variant we ended up with was methods like .rwx, so people could at least check multiple mode bits at once. Still not the same as the _ pseudo-file in Perl that literally meant "use the last cached value".
Not entirely clear on why we can't just say if you want to use a cached stat structure, you have to be explicit. 02:29
02:30 linkable6 joined
MasterDuke except those don't actually check multiple bits "at once", they still perform multiple stat calls 02:30
japhb Lots of stuff with filesystem atomicity tricks will only work if there are no implicit caching.
I meant the API
As in, we designed a partial, limited API that *could* do a single stat call, but there are lots of ways you'd want to look at a single stat structure that those don't cover. 02:31
*a single stat call for very particular combinations
MasterDuke sure, but i'm not entirely happy about offering the api when we don't actually do what we say/imply we're doing
japhb Oh totally agreed with that.
MasterDuke huh. i've done a bunch of Perl, but didn't know about _ 02:32
japhb Probably not exactly easy to search for .... 02:33
MasterDuke we could say you have to be explicit about caching. but if 99.9% of the users/use-cases would want it...maybe it should be the default? (of course, maybe it's closer to 60%, which isn't so compelling) 02:34
japhb Whatever we do, it should be as easy as we can manage to reason about it, because screwing up handling of file permissions and operations seems to be an evergreen class of security bugs. 02:42
MasterDuke afk, but thanks all for the discussion (and others can feel free to chime in). still haven't really made any changes to rakudo yet, but getting a clearer picture of what i think i want to do 03:03
03:30 linkable6 left, evalable6 left 03:31 linkable6 joined 03:33 evalable6 joined 04:33 bloatable6 left, statisfiable6 left, greppable6 left, evalable6 left, linkable6 left, committable6 left, reportable6 left, bisectable6 left, sourceable6 left, coverable6 left, quotable6 left, squashable6 left, releasable6 left, tellable6 left, notable6 left, nativecallable6 left, unicodable6 left, benchable6 left, shareable6 left, shareable6 joined, linkable6 joined, benchable6 joined, bloatable6 joined 04:34 sourceable6 joined, releasable6 joined, reportable6 joined, coverable6 joined, unicodable6 joined, quotable6 joined, committable6 joined, tellable6 joined, bisectable6 joined, greppable6 joined 04:35 squashable6 joined, statisfiable6 joined, nativecallable6 joined 04:36 evalable6 joined, notable6 joined 05:02 squashable6 left 05:04 squashable6 joined 06:00 reportable6 left 06:03 reportable6 joined 08:45 sena_kun joined
Geth rakudo/main: d520abb7f5 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: handle C<> / V<> / <> better

  - fix C<> / V<> handling if they were *not* the outer markup code
  - flatten letterless markup (aka any balanced <foo> inside a < >)
   at parse time, making it no longer visible to renderers (as it
   probably should have been from the start).
roast: be855d47a6 | (Elizabeth Mattijsen)++ | S26-documentation/08-formattingcodes.t
Fix faulty C<> rendering test

C<> means verbatim semantics, so leading spaces *should* be in there. This is fixed with RakuAST
10:49 evalable6 left, linkable6 left, evalable6 joined, linkable6 joined
Geth rakudo/main: f0be6ea866 | (Elizabeth Mattijsen)++ | src/core.c/Version.pm6
Small shortcut for uninterpretable versions

As Version.new is the same as $v
rakudo/main: 1b764648e8 | (Elizabeth Mattijsen)++ | src/core.c/Version.pm6
Dehug closing parentheses

No changes, but hopefully a better readable diff with future changes to the Version logic
rakudo/main: 4f07e0e1a9 | (Elizabeth Mattijsen)++ | 2 files
Remove Version $!whatever attribute

  - not documented
  - not tested
  - not used
ugexe i think thats breaking the api 11:39
lizmat ah> 11:40
ugexe there used to be a Version.new candidate with 4 positional arguments. now there is not
i'd be surprised if anyone was using that candidate, but we shouldn't assume it isn't used just because it isn't used in the core 11:41
lizmat oddly, no tests were hurt in that commit
but I will add it back as a non-functional
ugexe did it not function before?
lizmat it was stored in the object, but the attribute wasn't used anywhere 11:42
at least not in the core
and was not documented
neither was the 4 positional .new
ugexe if it wasn't working then it is a little more reasonable to break the api 11:44
lizmat I'll add it back in just in case 11:45
ugexe++ for the spot
ugexe it looks like Version used to have a method whatever() { nqp::hllbool($!whatever) } 11:47
oh right, that was removed in that commit as well 11:48
lizmat I guess I need to add that back again as well then
ugexe removing the whatever method is probably more likely to break things
m: say (v1.0).whatever; say (v1.0).plus; say (v1.0.*).whatever; # someone might use something like this to detect if a version if a range or not 11:50
camelia False
lizmat yeah...
12:00 reportable6 left 12:03 reportable6 joined
Geth rakudo/main: ea4912ec79 | (Elizabeth Mattijsen)++ | src/core.c/Version.pm6
Restore Version.whatever

  - add the optional positional arg back in, without any function
  - add method whatever back in, but make it lazy by letting it look
   at the parts and return True if any of the parts is Whatever
rakudo/main: 1045f1b292 | (Elizabeth Mattijsen)++ | src/core.c/Version.pm6
Don't store a Whatever instance, but a type object

  * is a Whatever.new. By storing a Whatever type object, we can
simplify the test in .whatever to a =:= comparison
rakudo/main: 69bb5ea327 | (Elizabeth Mattijsen)++ | src/core.c/Version.pm6
Make Version.ACCEPTS a bit faster

By using =:= comparisons for Whatever
13:13 jgaz left 13:20 jgaz joined 14:54 squashable6 left 14:57 squashable6 joined 16:08 linkable6 left, evalable6 left 16:09 evalable6 joined 16:10 linkable6 joined
Geth rakudo/main: 6f8bb0a346 | (Elizabeth Mattijsen)++ | src/core.c/Version.pm6
NQPify Version.ACCEPTS

For speed because it is used a lot, and will get to do a bit more soon.
timo i asked nine recently how there can be a race condition in the exprjit and now i rememeber what he meant, this is about not being able to write access to something in a way that is compatible with some kind of atomic operation we need 17:11
so it's not that the exprjit compiler has a race condition in it, it's that it generates code for a specific situation that is racy
17:32 linkable6 left, evalable6 left 17:34 evalable6 joined 17:35 linkable6 joined 18:00 reportable6 left 18:02 reportable6 joined
Geth rakudo/main: 73d07b4b58 | (Elizabeth Mattijsen)++ | src/core.c/Version.pm6
Add support for Version.new("1,2,3-")

This adds support for Version objects that will accept any Version equal or **before** a given Version object.
   say Version.new("1.2.3") ~~ Version.new("1.2.4-"); # True
   say Version.new("1.2.4") ~~ Version.new("1.2.4-"); # True
... (19 more lines)
nine timo: right 18:38
Geth rakudo/main: d37e6e8315 | (Elizabeth Mattijsen)++ | src/core.c/Version.pm6
Make v1.2 eqv v1. True

As originally envisioned and TODO tested for
roast: e7385eac9b | (Elizabeth Mattijsen)++ | S02-literals/version.t
Untodo v1.2 eqv v. tests
rakudo/main: a04661369b | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: add support for v1.2-
roast/master: 5 commits pushed by (Elizabeth Mattijsen)++ 19:05
roast: 5f971928b5 | (Elizabeth Mattijsen)++ | S02-literals/version.t
RakuAST: add tests for v1.2-
20:15 Voldenet_ joined 20:16 Voldenet left, Voldenet_ is now known as Voldenet 21:17 Voldenet_ joined, Voldenet left, Voldenet_ is now known as Voldenet 21:21 sena_kun left 23:35 Util joined