🦋 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:01 reportable6 joined
japhb Yup, -116- starts at full speed. 00:08
-117- consists of an NQP bump that itself consists of a MoarVM bump, which upgrades to libuv 1.45. 00:09
libuv 1.45 introduces io_uring support for Linux, while 1.46 fixes an io_uring bug by turning off support for kernels older than 5.15.90. 00:10
And guess what? My kernel is 5.15.0-78-generic
MoarVM HEAD is "Update libuv to version 1.46 (#1761)" 00:13
NQP HEAD is "Bump MoarVM for libuv update" and refers to the MoarVM HEAD commit 00:16
ugexe Nice 00:17
japhb Rakudo has "Bump NQP to get libuv update" referring to the NQP HEAD 00:18
So ... now I'm confused again; I thought I'd found it. 00:19
Well, certainly 2023.04-116 to 2023.04-117 is the performance cliff, and it is for the libuv 1.45 bump, but the later libuv 1.46 bump doesn't seem to fix it for me, even though it sure smells like it ought to. 00:20
AH! libuv 1.46 doesn't disable io_uring support *entirely*, but only for the function uv__iou_fs_close 00:21
So ... probably my kernel has some other problem with io_uring. 00:22
japhb glares at libuv -- "You DEFINE a uv__use_io_uring function, but you don't CALL it, and that's really the point, isn't it?" 00:40
How do I force an *exact* version match for `zef install`? I'm getting this: 01:29
zef install 'Term::termios:ver<0.2>'
===> Searching for: Term::termios:ver<0.2>
===> Building: Term::termios:ver<0.2.3>:auth<zef:krunen>
But I specifically want what I asked for, and NOT 0.2.3. 01:30
ugexe for me it gets 0.2 02:25
i would wonder if you are on a recent version of zef 02:27
MasterDuke ugexe: have you looked at my new pair of stat/syscall PRs? 02:33
japhb ugexe: What version of zef should I expect? `zef --version` gives me 0.18.3 04:10
04:16 evalable6 left, linkable6 left 04:19 evalable6 joined 04:20 linkable6 joined 06:00 reportable6 left 06:01 reportable6 joined
lizmat japhb: that is I think the most recent 07:27
07:47 linkable6 left, evalable6 left 07:48 evalable6 joined 07:50 linkable6 joined
Geth rakudo/main: d9085270a8 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: give ⇒ its own token

It was done for all other unicode/ascii aliases as well		 07:57
08:32 sena_kun joined 08:58 hythm joined
nemokosch termios 0.2 is on REA, if at all 09:08
Geth rakudo/main: 37aa0544b8 | (Elizabeth Mattijsen)++ | src/Raku/ast/operator-properties.rakumod
RakuAST: Streamline OperatorProperties a bit

But mostly add many more comments as to the reason why it exists, and why it exists that way.		 09:55
hythm m: say v0.2.3 ~~ v0.2 ## v0.2 specification matches higher versions as well (as per rakudo), so candidates like `v0.2.1`, `v0.2.2`, `v0.2.3` etc... will match `v0.2` specification, since v0.2.3 is the latest version, it will be chosen ( not saying this should be the correct behavior, but this might be what is happening for Term::termios) 10:00
camelia True
hythm This would not happen if Term::termios uses fixed version scheme eg. (0.1, 0.2 ...) or (0.0.1, 0.0.2 ...) 10:02
nemokosch it might make sense for smartmatching to accept v0.2.3 for v0.2 - but then version resolution shouldn't use smartmatching 10:27
10:31 linkable6 left, evalable6 left 10:32 evalable6 joined, linkable6 joined 11:33 hythm left 12:00 reportable6 left, reportable6 joined 12:02 hythm joined
hythm m: say v0.2.3 ~~ Version.new( '0.2+' ) 12:03
camelia True
hythm m: say v0.2.3 ~~ Version.new( '0.2-' )
camelia True
hythm m: say Version.new( '0.2-' ).minus 12:04
camelia True
12:10 sena_kun left 12:19 ab5tract joined
ab5tract lizmat: can you kindly add a RAKUDO_RAKUAST=1 label to this issue I just filed? github.com/rakudo/rakudo/issues/5353 12:22
lizmat done
ab5tract thanks! 12:23
now, how to go about fixing it... :) 12:24
I guess this was probably a known issue?
lizmat not to me 12:25
and re fixing: nine might have some ideas and/or vrurg
jdv vrurg: yes - github.com/rakudo/rakudo/blob/main...de.pod#L21 12:38
ab5tract weird, I can't seem to compile rakudo from a realclean state. I get linker issues with libuv ("multiple definition of ...") 12:59
using `make realclean; find . -name .precomp -print0 | xargs -0 -r rm -rf; perl ./Configure.pl --gen-moar --backends=moar; make`
removing 3rdparty doesn't fix it 13:01
13:12 linkable6 left 13:14 linkable6 joined
Geth rakudo/main: 187865144b | (Elizabeth Mattijsen)++ | 8 files
Make &infix:<⇒> a first class citizen
 13:19
ugexe hmm, 2.0 compared to 2.0.3 should turn 2.0 into 2.0.0 13:42
m: say (v2.0).ACCEPTS(v2.0.3)
camelia True
ugexe m: say (v2.0.0).ACCEPTS(v2.0.3)
camelia False
ugexe something like v2.0 should never act as a range, and should only match against versions that are considered identical to 2.0 13:45
m: say v2.0 cmp v2.0.0'
camelia ===SORRY!=== Error while compiling <tmp>
Malformed postfix call
at <tmp>:1
------> say v2.0 cmp v2.0.⏏50'
ugexe m: say v2.0 cmp v2.0.0
camelia Same
ugexe if those are identical, then how could it match 2.0.3? (rhetorical question... but it shouldnt) 13:46
the only reason for that behavior to exist really is so `use v6` can match v6.c, v6.d, etc 13:47
but then just use v6.8
v6.* 13:48
i feel like that Version should be updated to act such that v2.0 doesn't match against v2.0.3, but then `use v6;` is gonna need some sort of special casing in code to turn it into v6.* (and should probably send the user a deprecation message to `use v6.*` instead of `use v6`) 13:50
lizmat: vrurg any idea how i'd go about attempting that? i dunno where all the v6 handling logic is 13:53
even still, it will be less than perfect, since all versions for non-core rakudo will turn v6 into v6.0, whereas rakudo will turn `use v6` into `use v6.*` (* instead of 0) 13:54
is there even any reason to do *anything* with `use v6;` even? 13:56
like does anything relevant happen when `use v6;`?
originally i thought it was aimed to tell the difference between perl and raku code source
lizmat yes, that was the original intent 13:57
and recently I have been removing it from all of roast and t, unless a specific version of Raku was required 13:58
still there's plenty of it in the ecosystem
ugexe yeah, there are a lot of modules and their tests that use it so im wondering how to get around blowing those up if i were to change it
lizmat I know where it lives in RakuAST
but I think we should think about fixing Version more generally 13:59
ugexe well that would be the intention, but fixing Version is going to break/change what `use v6;` does
vrurg As far as I remember, plan v6 loads the current default version, it's not v6.*.
lizmat indeed 14:00
ugexe what does v6.* load? .PREVIEW?
ab5tract wait, what does v6.* do if not load the latest released version?
ugexe v6.* for a module would load the latest released version for instance
lizmat m: use v6.*; say $*RAKU
camelia Raku (6.e)
ab5tract intriguing
ugexe yeah thats fine
lizmat m: say Q|use v6.*; $*RAKU|.AST.EVAL 14:01
camelia Raku (6.e.PREVIEW)
ugexe .PREVIEW is sorted lower than .0, so makes sense
vrurg ugexe: I mean you shouldn't worry about 'use v6' behavior.
ugexe oh, that would be a change in behavior as well
lizmat I'm not sure whether that difference is important
ugexe vrurg: ah ok, so `use v6;` could be a no-op?
vrurg It is a no-op.
ugexe lizmat: it is for modules
lizmat yes, it's a no-op in Raku
ugexe that way someone can release a .PREVIEW version of a module, and the final version without .PREVIEW would be sorted newer 14:02
not that anyone does that, so we don't have to really protect that behavior. but it does have a useful aspect
lizmat so, maybe Version.ACCEPTS needs more scrutiny 14:03
vrurg I use v6.e.PREVIEW in newer modules. :)
lizmat any missing part is considered to be a *
ugexe vrurg: yeah, I mean for modules (not loading raku version though)
lizmat m: say v2.0 ~~ v2.0.3
camelia False
ugexe use Foo:ver<2.0.PREVIEW>
lizmat m: say v2.0.3 ~~ v2.0
camelia True
lizmat m: say v2.0.3 ~~ v2.0.*
camelia True
lizmat they're the same
ugexe say (v2.0).ACCEPTS(v2.0.3); # this should be false 14:04
evalable6 True
vrurg ugexe: Ah, use... Anybody's using that in module versions?? Never seen it in the wild.
ugexe vrurg: i dont think so, although the idea was brought up before briefly in some issue long ago 14:05
vrurg Looking at the discussion, it smells more and more like a problem-solving to me. 14:06
ugexe m: say v2.0 cmp v2.0.3
camelia Less
ugexe m: say v2.0 cmp v2.0.0
camelia Same
ugexe it just doesn't make sense that 2.0 and 2.0.0 are the same, yet 2.0 matches 2.0.3
vrurg It's 2.0.3 matches 2.0, not vice versa. We can't use cmp because 2.0.3 > 1.0 but 2.0.3 !~~ 1.0 14:08
ugexe we can use cmp to show that 2.0 and 2.0.0 are the same 14:09
vrurg But it looks totally correct to me that 2.0.3 ~~ 2.0 but it is 2.0.3 != 2.0
ugexe but yes, generally one would use ~~ to figure out if one version is accept by a version/version-range
nemokosch smartmatch is not an equivalence check (it's not anything really)
vrurg Perhaps zef should use strict check unless there is '*'/'+' in the version string. We currently don't have an indication in Version that '*' was explicitly used though. 14:12
ugexe that isn't sufficient - leont's code would still have loaded the wrong version if they did `use Foo:ver<2.0>` 14:13
they (and myself) seem to believe that v2.0 is a concrete version and not a version range 14:14
14:14 codesections left
vrurg Agree. It'd be better to change 'use' behavior too then. 14:14
But not Version's. Not _that_ radical. 14:15
ugexe changing Version seems like the logical choice to me. Version itself needs an easy way for users to make this same comparison, and i'd bet that everything using Version ~~ Version right now expects it to act the way `use Foo:ver<...>` would (and thus how e.g. `zef install Foo:<ver...>` would) 14:16
vrurg BTW, looks a bit crazy, but ∈ looks like the appropriate op for the task. I.e. `v2.0.3 ∉ v2.0` but `v2.0.3 ∈ v2.0.*`. 14:18
ugexe m: say v2.0 ∉ v3.0 14:19
camelia True
ugexe i would say ~~ is indeed the correct thing to use here
vrurg And, still, why `v2.0.3 ~~ v2.0` seems logical to me is because `~~` generally answers `is left is right?` and 2.0.3 is 2.0 in general. 14:20
ugexe and everywhere it is used currently is trying to say ($does-this-version-or-version-range).ACCEPT($this-version)
vrurg m: say v2.0.3 ∈ v2.0.* 14:21
camelia False
vrurg I'm afraid, the problem is about the context we put ~~ into. For Version it's more so than for many other things. 14:22
Besides, I'm afraid there are modules relying on v2.0.3 ~~ v2.0 and changing this would cause them troubles. 14:23
ugexe yeah, but i'd argue that everywhere it is used (except for potentially anything testing `use v6` behavior explicitly) expects the behavior i describe
lizmat fwiw, I tried to switch the left/right behaviour for missing parts, but it causes quite some failing tests :-( 14:24
nemokosch does the version retrieval even be about "what operator to use"? v2.0 and v2.0+ simply seem two different concepts, why not use two different strategies? 14:25
vrurg OK, I have work to do. Specifically woke up earlier as for a typical weekend for that. And have done nothing yet... ;) So, if we can get a problem solving and set 2-week limit for it for ourselves then I'd prefer that way. 14:26
vrurg is afk unless there are emergencies 14:27
ugexe github.com/rakudo/rakudo/pull/1118 14:30
i can't tell if i implemented the behavior i'm arguing against now (lol) but larry did comment in there^
but apparently i knew a lot more about Versions in the past than i do now :P 14:32
Geth rakudo/main: dc078bfd73 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add default-xxxfix-operator methods

To allow custom xxxfix operators to have at least some operator properties, similar to what they have in the legacy grammar
ugexe wait no
i think i proposed padding with .0 14:33
and thats probably what i implemented
Geth rakudo/main: b1f54e17e0 | (Elizabeth Mattijsen)++ | src/Raku/ast/expressions.rakumod
RakuAST: allow ::Infix to handle unknown infixes

By giving them the default OperatorProperties, instead of erroring out.		 14:34
nemokosch > However use searches for modules matching a version prefix, so the subversions are wildcarded, and in this context :ver<1.2> really means :ver<1.2.*> 14:37
this is the problem
this declaration doesn't seem to match what people think or want
lizmat changing that to mean :ver<1.2.0> breaks tests so it may require a language version bump 14:38
which would be ironic :)
nemokosch I wonder what the idea was. Having versions like 1.2, 1.2.1, 1.2.2, etc. might be DIHWIDT-ish but definitely something that can happen without bad intentions. Does that declaration even provide an opt-out to access the 1.2 version? Would 1.2.0 magically work for it? 14:43
ugexe lizmat: which tests though? Are they the ones testing for use v6 or use Perl:ver<6....> or some such? 14:44
lizmat I didn't look further
lizmat scrolls back
t/spec/6.d/S02-literals/version.t test 20
t/spec/S11-modules/import-multi.rakudo.moar test 6 throws
t/02-rakudo/03-corekeys.t fails all 3 tests 14:45
that's it 14:46
14:53 Xliff joined
Xliff Raku-GLib suite timing statistics for Raku 2023.06.254.g.32.e.078.ca.75 14:53
Using the following processor: AMD Ryzen 9 5950X 16-Core Processor
Total number of projects: 34 (506509 loc)
Total non-parallel compile times: 10871.830 (319.760 avg)
Total parallel compile times: 2132.659 (62.725 avg) 5.098x speedup
[Tux] Rakudo v2023.06-257-g187865144 (v6.d) on MoarVM 2023.06-4-g75fe055c2
csv-ip5xs0.862 - 1.145
csv-ip5xs-205.918 - 6.266
csv-parser3.947 - 4.251
csv-test-xs-200.402 - 0.413
test6.537 - 7.800
test-t1.417 - 1.853
test-t --race0.855 - 1.006
test-t-2021.647 - 22.209
test-t-20 --race6.558 - 6.639
 14:54
hythm v0.2.3 ~~ v0.2 was confusing for me at the beginning, but now it makes sense, since (as other mentioned) v0.2.3 is considered a 0.2 version, so this behavior looks correct to me. when a user wants to use v0.2 rakudo should load v0.2. same for tools, if the user wants to install v0.2, the tools should resolve that to v0.2 (regardless of the operator 14:58
used `~~`,`cmp` or any)
nemokosch Agreed completely 14:59
ugexe well, in the PR I posted larry commented that he agreed there should be an easy way for module developers to make this comparison. and i believe he was implying that ~~ was that "way" 15:28
well maybe not 15:29
I'm confused because in the PR I proposed "Pad LHS with .0, such that it is always treated as a concrete version.", but then also said that PR aligns with "However use searches for modules matching a version prefix, so the subversions are wildcarded," 15:30
i wonder if i didnt read that whole sentence and meant just the first part "1.2 is equivalent to 1.2.0, 1.2.0.0" 15:31
hythm relevant discussion in this issue starts from this comment github.com/ugexe/zef/issues/379#is...-753240494 15:34
ugexe i wonder what would break if we just switched Version to semver(ish) 15:41
vrurg An unrelated thought I'm muling about for quite a while. There are typical patterns like `{ my $v = something; do things with $v; $v }`. What about something like `{ returns $v = something; do something with $v }` instead? Or, even, `{ returns something { do something with $_ } }`. 15:42
Xliff vrurg: I like the last one. 16:22
Would that return even if the block throws an exception?
For that to work, if the interior block throws, then the return stull occurs if there is a handled CATCH. Otherwise it's fatal. 16:25
Geth rakudo/main: 5fb6d83612 | (Elizabeth Mattijsen)++ | src/core.c/traits.pm6
Use OperatorProperties.new-compat to set %prec

It contains the same logic, but centralized in a single place		 16:37
lizmat m: dd &infix:<+>.op_prop 16:46
camelia No such method 'op_prop' for invocant of type 'Sub+{is-pure}'
in block <unit> at <tmp> line 1
lizmat m: dd &infix:<+>.op_props
camelia OperatorProperties.new(precedence => "t=",associative => "left")
lizmat m: Q|dd &infix:<+>.op_props|.AST.EVA
camelia No such method 'EVA' for invocant of type 'RakuAST::StatementList'.
Did you mean 'EVAL'?
in block <unit> at <tmp> line 1
lizmat m: Q|dd &infix:<+>.op_props|.AST.EVAL
camelia OperatorProperties.new(precedence => "t=",associative => "left")
lizmat so, when parsing code with the RakuAST grammar from the legacy grammar, the operator properties are visible 16:47
nvm brain twist 16:48
17:02 sena_kun joined
gfldex While fooling aroung with Rakudo, I get "Stage mast : Object does not exist in serialization context". Is there any way to get hold of the offending object? 17:04
lizmat in my experience when it happens at that stage, is to revert your code step by step until it doesn't happen anymore 17:07
also: there's probably an .ensure-sc missing somewhere 17:08
so: you created an object that is about to be serialized, but you didn't mark it as serializable (which is what .ensure-sc does) 17:09
hope this helps :-)
gfldex I changes almost nothing, so reverting wont help. I'm trying to follow up on my last blogpost and add referenced of child classes to ClassHOW. 17:10
.ensure-sc yields „Segmentation fault“. I may be able to get away with not to need „Stage mast“. 17:14
lizmat can you post a gist ? 17:16
maybe that will ring a bell with me or vrurg 17:17
gfldex gist.github.com/gfldex/3478a475b75...72555872c9 17:18
Changes are marked with
#MARK 17:19
Without line 12-14 the Segfault goes away.
lizmat ok, I thought you were doing stuff at the QAST level 17:23
lines 12-14 can go
I wonder whether @!children needs to be marked in some bootstrap somwhow 17:27
ok, jetzt bin ich überfragt :-) 17:29
17:59 ab5tract left 18:00 reportable6 left 18:03 reportable6 joined
Xliff How can I type the key of the hash as a type object? 18:35
Especially if I want to type a $ sigiled hash value...
This should probably go to #raku. Moving... 18:36
lizmat m:mL: my %h{Str:U} = ::("Str") => 42; dd %h 18:38
evalable6 Hash[Any,Str:U %h = (my Any %{Str:U} = (Str) => 42)
lizmat Xliff ^^
MasterDuke lizmat: suggestion for rak, a flag to include the first line of any searched file in the output (either always, or only if that file had a match to the pattern) 18:39
lizmat MasterDuke: please make an issue for it, otherwise it will fall through the cracks
MasterDuke done github.com/lizmat/App-Rak/issues/45 18:43
lizmat thanks! 18:45
vrurg m: my %h{Mu}; %h{(Int)} = 42; dd %h; 19:05
camelia Hash[Any,Mu] %h = (my Any %{Mu} = (Int) => 42)
vrurg Xliff: ^ here is a little bit simple approach. 19:06
*simpler
Xliff vrurg: Does not account for $-sigiled variables, which is a requirement. Thanks, though. 19:07
vrurg Xliff: what do you mean? 19:08
Xliff %h{Mu} is not $h
m: my $h{Mu};
camelia ===SORRY!=== Error while compiling <tmp>
The {} shape syntax with the $ sigil is reserved
at <tmp>:1
------> my $h{Mu⏏};
expecting any of:
statement end
statement modifier
statement modifier loo…
vrurg m: my $h = my %{Mu}; dd $h 19:09
camelia Hash[Any,Mu] $h = $(my Any %{Mu})
Xliff Ah! There is another option. TYVM!
vrurg m: my $h = my %{Mu}; $h{(Int)} = 42; dd $h;
camelia Hash[Any,Mu] $h = $(my Any %{Mu} = (Int) => 42)
vrurg An special case of anonymous declaration.
m: my $h = Hash[Any, Mu].new; say $h{(Int)} = 42; dd $h; 19:10
camelia 42
Hash[Any,Mu] $h = $(my Any %{Mu} = (Int) => 42)
vrurg This is what it actually does, eventually.
nemokosch does the anonymous variable not come with the usual thread safety concerns, though?
vrurg nemokosch: have you noticed it's a `my`? 19:11
m: sub foo { my %{Mu} }; say foo.WHICH; say foo.WHICH;
camelia Hash[Any,Mu]|2817476225328
Hash[Any,Mu]|2817476226768
vrurg is away for a while. 19:12
19:36 linkable6 left, evalable6 left 19:39 evalable6 joined, linkable6 joined
Geth rakudo/main: 2dbcdafdf3 | (Elizabeth Mattijsen)++ | src/Raku/ast/code.rakumod
RakuAST: make sure custom ops get correct default OperatorProperties
 19:51
lizmat 938 (+1)
vrurg gfldex: It's a familiar situation to me. In a couple of modules I rely on compiler internals to install INIT phaser where the registration is done. 20:15
ugexe japhb: what version of rakudo were you running with `zef install "Term::termios:ver<0.2>"`? For me that is installing 0.2 20:45
gist.github.com/ugexe/8253190d17dd...23e560ca2f 20:47
lizmat I wonder whether japhb changed the default config for searchable repos 20:52
ugexe that could result in confusing results, but i'm not sure that could result in this specific scenario 20:57
fez doesnt have 2.0, so if it didn't search REA it would have failed. REA has 0.2 and 0.2.3 so if it didn't have fez it should have still matched the 0.2 from REA 20:58
the fact they have zef v0.18.3 also makes me think their rakudo can't be *that* old
lizmat hmmm does the 2.0 have the same auth as 2.0 3?
ugexe no, but that doesn't matter as it wasn't specified 20:59
lizmat ack
ugexe japhb: a `zef list --installed` might be useful to see as well, just to see if there is some old zef code that maybe is getting loaded (despite the fact --verison is reporting 0.18.3) 21:01
cause the version is determined in the mainline, but the other `use Zef::Foo` could load code from older versions based on where it is in the repository chain 21:02
[Coke] japhb: termios releases borked on mac, so lineeditor borked as well. (can work around by instaling an older version of the dep. 21:03
21:20 linkable6 left, evalable6 left 21:21 evalable6 joined 21:23 linkable6 joined 21:30 Xliff left
japhb BAK, sorry I missed these earlier. 21:32
[Coke]: Yeah, essentially that's what I'm trying to do with (borked termios having a huge cascade through the things I work on). 21:33
ugexe: I was building lots of different Rakudo's, but all from 2023. The one I'm *currently* using is v2023.04-116-g01e822248, because that's the last commit before libuv 1.45, which is killing my startup time measurements. 21:34
ugexe: gist.github.com/japhb/c1a48e8e5839...ec75b3575d 21:37
That was for `zef list --installed`. Did I miss any other questions?
ugexe hmm, well you have Zef::Configuration installed so maybe lizmat was right
japhb ugexe: That was to get REA, IIRC. 21:38
ugexe could you run `zef install "Term::termios:ver<0.2>" --debug` as well? that'd give me a bit more insight
japhb Sure
Should I uninstall first?
ugexe ah, yeah
japhb OK will do
ugexe one last thing would be to get the contents of the zef config. run `zef --help` and then it'll show the configuration file path somewhere towards the bottom 21:39
REA is included in more recent versions of zef by default, so custom configuration files wouldnt be needed anymore
japhb Updated with --debug output 21:40
ugexe ah got it, i see what it is 21:42
that is getting it from p6c
that is probably still enabled because of the aforementioned custom config
japhb Config file added
ugexe what is the configs path
japhb /home/geoff/.config/zef/config.json
ugexe ah ok. just delete that :P
japhb Done. So I take it this can go away from my build script as well? 21:44
zef install Zef::Configuration
zef-configure enable rea
ugexe yep, no need to do that anymore
lizmat: you were right afterall
japhb (Feel free to now dance to your success like an 80's video) 21:45
ugexe what was happening though is it was fetching it from p6c (not being updated), which points to master branch on github, which doesn't have the version pointed at by the old p6c 21:46
(p6c and cpan are disabled in modern versions of zef)
japhb Weird. Victim of my own history, I guess. 21:47
Gist updated with latest output of --debug install
Looks now like it should to you?
ugexe yep that looks like what i expect 21:48
japhb Excellent! Thanks for all your help!
(And lizmat) 21:49
And it even works with my latest dev code! YAY! 21:50
OK, looks like I'll have to make Terminal::Print and Terminal::LineEditor use that specific version of Term::termios (before 0.2, it didn't actually *have* version numbers, so I couldn't specify such previously) 21:54
ugexe for brevity the original issue can be reproduced using a non-custom config zef via `zef install "Term::termios:ver<2.0>" --p6c --/fez --/rea --dry`
japhb gotcha 21:55
OK, pushed dependency changes, waiting for CI 22:04
New versions of Terminal::Print and Terminal::LineEditor released; [Coke], you might want to try again installing the latest. 22:12
japhb tries to remember what he was working on *before* all of this 22:13
22:38 sena_kun left
nemokosch m: say (0...5,3...7) 23:59
Raku eval (0 1 2 3 4 7)

Powered by Cro and the Raku® Programming Language.

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

Thank you!