04:13 bartolin left 04:24 bartolin joined
ab5tract Sure, but that’s more options not less., and there is no way to output a file name that doesn’t conform to that 06:24
Or isn’t affected by that, rather 06:26
Geth rakudo: usev6++ created pull request #5714:
[JVM] Reduce backend-specific code in find_best_dispatchee		 07:40
nqp/main: 5b86eef601 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get MasterDuke++ fast path comparison fix
 09:19
09:19 japhb left 09:26 japhb joined
Geth rakudo/main: 936c356935 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get MasterDuke++ fast path comparison fix
 09:31
09:37 sena_kun joined 10:07 sena_kun left
lizmat hmmm I just noticed there are quite a few tags in the ecosystem that consist of multple words 11:52
shouldn't a tag be a single word ? 11:53
(without any spaces?)
ab5tract Is there a canonical source for these tags or can devs add them Freeform? 14:00
lizmat freeform, in the META6.json
14:20 vrurg joined
ugexe I’m not sure I follow. You asked how someone might find themselves using a command that wouldn’t work anymore if we normalized named. The scenario I described is just that: if the names were normalized and they were using e.g. Zef instead of zef then it would no longer work 14:35
At least I think that’s what you asked 14:43
patrickb I think I don't understand. As long as we stay on a case insensitive FS, all variants of "zEf" should continue to work, irrespective of how we choose to name the script file (as long as the letters making up the word stay zZeEfF), right? 15:30
timo is it really freeform if we limit them to strings, and not arrays, objects, floats, ints, booleans, or null? :P 15:31
patrickb Just to be sure I don't miss a point here: There is nothing we can do about FSes limiting how scripts could be named, apart from maybe converting unsupported chars to some fallback. Right? 15:32
lizmat ah, ok, well, strings and arrays of strings are allowed afaik
patrickb wonders whether the lack of comments on ps#455 is a good or a bad sign. 15:35
linkable6 PS#455 [open]: github.com/Raku/problem-solving/issues/455 [rakudo] Revamping wrapper scripts in CURI
patrickb Wow. It understood that ps referred to problem-solving?!? 15:36
timo we do have a little map of prefixes for issue numbers in there, yeah
i think
linkable6: source
linkable6 timo, github.com/Raku/whateverable
timo github.com/Raku/whateverable/blob/...ble.p6#L30 15:37
ugexe patrickb: the problem is zef, Zef, zEF, etc would all shadow the same name on some systems and not others. that is not the case for installed modules because we sha1 them 16:17
timo if not everything that generates sha1s from names uses NFG (or equivalent), we might also get differences there when there's unicode normalization differences 16:19
just a random thought 16:20
ugexe we could punyencode to handle unicode stuff but case-sensitivity is a problem because both upper and lowercase letters are very common in names which means all names would need some normalization marker in their name
yeah i think we explicitly use latin-1 for sha1ing source but we don't do anything like that for names 16:21
patrickb ugexe: I think I understand now. You are describing a case where a user would be used to typing in "Zef" and then won't be able to do so anymore when they moved to a case-sensitive FS. 16:22
But this has nothing to do with a name normalization we might (not) perform, correct?
ugexe yeah, or they might tell people to use "Zef" and those people listening may be on a case sensitive file system
it sort of does: if we normalized names then "Zef" shouldnt work anymore 16:23
lizmat if someone moved from a case-insensitive to a case-sensitive FS, raku would only be one of the muscle memory errors
patrickb ugexe: Can you elaborate how normalizing names would make a difference? Maybe an example of name before and after normalization would help me understand. 16:24
Geth rakudo/main: 5ff3eafef4 | (Elizabeth Mattijsen)++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
Restore error message on Junction sub-sig binding error
 17:02
rakudo/main: 8765d61725 | (Timo Paulssen)++ | lib/NativeCall/Types.rakumod
Have to make sure scalars don't make it into nativecallcast.

Fixes #5682		 17:18
rakudo/main: 10397f1613 | (Patrick Böker)++ (committed using GitHub Web editor) | lib/NativeCall/Types.rakumod
Merge pull request #5684 from rakudo/missing_decont_in_typedpointer_at-pos

Have to make sure scalars don't make it into nativecallcast
18:53 sena_kun joined
ugexe i'm not sure it matters in the context of raku I guess. `curl` works the same as `CuRl` on macos 18:54
lizmat m: my %h; %h<a> = %h; put %h # heh, .Str needs the same protection that .gist / .raku have 19:01
timo oh no :)
camelia (timeout)
lizmat m: my %h; %h<a> = %h; say %h 19:02
camelia (\Hash_5074152274656 = {a => Hash_5074152274656})
timo m: my %h{Any}; %h{%h} = 5; say %h.raku
camelia (my Any %{Any})
timo m: my %h{Any}; %h<a> = 99; %h{%h} = 5; say %h.raku
camelia (my Any %{Any} = :a(99), (:a(99)) => 5)
timo m: my %h{Any}; %h<a> = 99; %h{%h} = 5; say %h.raku; %h<b> = 100; say %h.raku
camelia (my Any %{Any} = :a(99), (:a(99)) => 5)
(my Any %{Any} = :a(99), (:a(99)) => 5, :b(100))
timo oh? 19:03
i guess that's what i get for using postcircumfix:<{ }> with an Associative?
m: my %h{Any}; %h<a> = 99; %h{$%h} = 5; say %h.raku; %h<b> = 100; say %h.raku
camelia (timeout)
timo ^- nobody expected recursion inside the hash keys huh? :) :) :)
that doesn't go through .Str, right? 19:04
m: my %h{Any}; %h<a> = 99; %h{$%h} = 5; say %h.gist;
lizmat object hashes uses the .WHICH as keys under the hood
camelia (timeout) 19:05
timo yeah, and the output has to get the object back for display
19:14 librasteve_ joined
patrickb ugexe: Sticking to the curl example. The current executable name is "curl". How would a normalized version that prevents other capitalizations from working look? 19:20
(I think there is some misunderstanding here. The above question seems to be rhetoric (or I really miss some really obvious point). I do hope that this question reveals where the misunderstanding lies.) 19:27
Geth rakudo/no_rebless_in_every_statement: a2aa5a712d | (Timo Paulssen)++ | src/Perl6/Grammar.nqp
don't call nqp::rebless on every statement

it causes a full deoptimization up the entire stack, even when it has no effect otherwise.		 19:29
rakudo: timo++ created pull request #5716:
don't call nqp::rebless on every statement		 19:30
rakudo/main: 38e655f470 | timo++ (committed using GitHub Web editor) | src/Perl6/Grammar.nqp
don't call nqp::rebless on every statement

it causes a full deoptimization up the entire stack, even when it has no effect otherwise.		 19:46
ugexe i can't give an example for curl. for raku it theoretically can be done via something like BEGIN { my $basename = 'foo'; die unless $*PROGRAM.basename eq $basename } in the wrapper 19:55
but since non-raku scripts don't do that i don't think we should either
i'm actually surprised that zEf works on macos. I thought github.com/rakudo/rakudo/blob/38e6...kumod#L311 would do a case sensitive match 19:56
Geth rakudo/main: 1340c2b08e | (Elizabeth Mattijsen)++ | 8 files
Fix .Str / .gist / .raku on self-referencing QuantHashes

The mutable versions could become self-referential with a simple
   my %s is SetHash; %s ,= 1;
and then infiniloop if .Str / .gist / .raku was called on them ... (5 more lines)		 19:57
ugexe ah nevermind $script will always be whatever was in the meta.json, i.e. what it was seen as on the file system since it is templated into the wrapper script
timo so i've looked at R#5715 and a quick "perf record" with a jit perf map shows nfa's optimizer taking a very high spot 20:25
linkable6 R#5715 [open]: github.com/rakudo/rakudo/issues/5715 [performance][grammar and actions][operators][Will be addressed in RakuAST] Defining a custom postcircumfix operator cases multisecond hang
timo the call path towards the optimizer being invoked goes through NQPClassHOW's caches, which are flushed when a mixin is generated, which we do so that old NFAs don't stick around and make our parses be incorrect 20:27
that means after we create a new variant of Perl6::Grammar, every time we hit an NFA "for the first time" it has to be re-generated, which includes a pass through the optimizer 20:28
an alternative could be to do smarter tracking of what goes into an NFA at creation time, to see which entries in the cache have to be invalidated when a new regex is added to a grammar, or an existing one is overwritten 20:30
that is potentially difficult to get right, famously cache invalidation is one of the tricky problems in compsci
another alternative could be to see if what we generate before creating the NFA matches what we generated in our parent class, and if it's the same, we could re-use the optimized result from the parent 20:31
then the difficulty could be how to actually compare a newly generated NFA to whatever we used to have before we ran the optimizer on another NFA. maybe hashing is correct here 20:32
another way forward could be to put some effort into optimizing the optimizer for faster run time? 20:33
ab5tract regarding my question about normalization, it's been mostly elaborated on by patrickb earlier. I'll only add that I didn't realize that the discussion involved producing wrapper scripts, though that is pretty obvious in retrospect. The macOS example seemed very confusing though as it related to the idea of users losing muscle memory related to previously working invocations 21:13
Losing that muscle memory when switching platforms makes sense, but in terms of the user experience before and after normalization-to-inscrutable-shas+wrapper-scripts, I don't see how there can reasonably be any UX delta whatsoever, as our naming capabilities on any given platform will remain exactly the same 21:15
I'll also add one overlapping anecdote, which is that I just about threw this macbook out of a window in Iceland in the rain after discovering that its 2024 and I was computing on a half-year old laptop of considerable expense... 21:18
... that is completely incapable of differentiating files by case
It honestly did not occur to me on any level to expect that or factor that in as a consideration when buying into the macos ecosystem
I guess it's a bit of a testament to some latent reality that case insensitivty is kind of cool but a bit of a YAGNI in practice that I've never encountered an issue with it outside of specifically investigating Raku issue reports related to it 21:19
ugexe you can make macos case sensitive, it just isnt by default 21:29
[Coke] I have a case sensitive drive on my intel mac so I can more easily do some stuff. I have a few git repos checked out there 21:32
Was very easy to setup and carve out space from the main drive.
ab5tract I'm aware that it's an option. I was just remarking on both the shocking nature of the revelation of case-insensitivity in 2023 (which is when this occurred) as well as the fact that literally nothing in terms of personal computing since then has given my reason to bother with enabling case sensitivity 21:37
ugexe it does seem bizarre in that it would seem like it would be more difficult to implement / maintain a case insensitive file system than a case sensitive one. windows is the same. 21:41
i personally don't set my file systems as case sensitive on windows or macos because it breaks Steam. On worktop where I don't have Steam it is mandated I use the default file system 21:42
ab5tract indeed! That's basically what I decided after looking into it. I figured I would take a few deep breaths.. "you didn't notice this until you looked into a Rakudo ticket specifically related to this.. why not just let it sit for a bit and see if it every actually gets in your way?" 21:49
there's a bizarre, unexpected ninth-degree irony that converting my laptop's drive to case-sensitive would result in **more** inconsistency and usability issues than not doing so 21:50
Geth rakudo/main: aa385bb948 | (Justin DeVuyst)++ | 2 files
Update release guide and Akefile to align with current practice.
 22:21
jdv [Coke]: there you go ^ 22:22
[Coke] Thanks, will give those a shot.
22:23 librasteve_ left
ab5tract jdv++ 22:40
patrickb Where in a rakudo installation would I place data files? (The template data used to generate the runner programs on Windows) share/perl6/lib/resources/win-runner.exetmpl? 22:59
23:02 sena_kun left
Geth roast: 1b14e5eb27 | (Elizabeth Mattijsen)++ | 3 files
Add tests for #4678
 23:25
ugexe patrickb: will your plan work with a rakudo that is upgraded while continuing to work with installed scripts? or would we need to add more upgrade-repository logic (github.com/rakudo/rakudo/blob/aa38...umod#L183) 23:34

Powered by Cro and the Raku® Programming Language.

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

Thank you!