🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). This channel is logged for the purpose of keeping a history about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Log inspection is getting closer to beta. If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 25 August 2021.
Xliff How are constants handled in Parameter? 05:35
Xliff Rather, if the Parameter is a constant value, how can I retrieve it from the Parameter object? 05:35
Xliff Arg! Constant values are constraints! LOL. 06:03
I have to dig 'em out with nqp.
nqp:hllize( nqp::getattr( nqp::decont($parameter), Parameter, '@!post_constraints').head 06:04
Od1n1 hello rakoons. 08:54
lizmat Od1n1 o/ 10:01
Xliff \o lizmat 10:21
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/01/31/2022-05-foo-is-42/ 13:06
guifa o/ 14:31
[Coke] heh. was just about to describe a delay I was seeing in zef, and as I finished typing the send here, it moved t the next step. :) 14:32
ychaouche hi all 14:33
[Coke] hi 14:35
gfldex I still don't understand how Tomasz managed to put "Raku" and "Speedrun" into the same heading. He must have a special tool for that. 14:53
guifa me when I woke up: I dunno if I'm going to have time to finish my basic BASIC slang proof-of-concept in time for the weekly 14:55
me when I had my coffee: oh, lizmat++ already published the weekly. I get another week now :-)
lizmat hehe... there's always a pro for every con :-) 14:56
gfldex: the SpeedRun describes how much time Tomasz spends on it
?
gfldex Maybe I'm just slow. :) 14:57
guifa I just have to finish up the signature processing (yeah, I'm going custom signatures even!) and finish writing the VM-within-a-VM code in RakuAST
lizmat guifa++ 15:00
guifa I'm going alzy though. A hash and an array, hash is lineNumber => codeIndex, and the array is just each line of code haha. But proof of concepts don't have to be efficient I figure 15:12
lizmat nope :-) 15:25
MasterDuke m: sub a("b") {}; say &a.signature.params[0].constraint_list[0]  # Xliff 15:30
camelia b
cetjs2 lizmat, in gsoc 2022 raku will participaTE? 15:44
lizmat I guess an application will be made, just like last year 15:45
only last year it wasn't accepted :-(
cetjs2 lizmat, ага. I understood 15:46
guifa lizmat actually just now reading up on it. apparently some of them were CRAZY inefficient (or I guess, did the best they could at the time) and would scan forward/backward character by character for new lines. ouch 15:51
lizmat ah, yes, BASIC :-) 15:52
if you only have a few K of memory :-)
Xliff MasterDuke: Huh. Missed that. Thanks! 15:53
clarkema Is there a clean way of checking whether a resource exists before trying to use it? At the moment I've got `if %?RESOURCES<header.ttl>.IO ~~ Slip {`, which does work but seems less than ideal 16:31
CIAvash `IO.e`? 16:36
clarkema You'd think so, but it returns a Slip from the .IO call and then can't call .e on that 16:38
guifa ah yes
I had the %?RESOURCES issue back a while ago
lemme remember exactly how I solved it
clarkema would be nice to be able to call .e on the resource directly 16:39
guifa Agreed, but I think there was some work being done in that area, but not sure what the status is 16:40
I guess I actually used something more complicated than checking for a Slip 16:41
github.com/alabamenhu/Intl-CLDR/bl...guages.pm6
clarkema I assume it has something to do with library resources 16:42
thanks guifa, I'll take a look
guifa Yeah. When installing a module, the resources aren't stored with the same names/structure that you see. I'd love for us to get to a point that resources are fully introspectable (e.g. list all the files in a directory) but I don't think that's been a priority since, presumably, module authors should know exactly what resources they have 16:44
clarkema Yeah, I know I control the resources directory and could just add the file and charge ahead, but the error message when it's missing is very non-obvious and I prefer not leaving landmines lying around for my future-self's foot 16:46
guifa instead of `if %?RESOURCES<foo>.IO ~~ Slip { … }`, perhaps you could consider a define `sub resource (Str $file) { given %?RESOURCES{$file} { when Slip { die "File $file not located in resources. Maybe you should add it?" }; default { .return } } }` 16:51
obviously, modifying the result of a non-existent file based on your needs 16:52
clarkema Looks like that's going to be the best approach, thanks :) 16:57
ugexe in what case would a file listed in %?RESOURCES not exist? 17:52
lizmat when it got deleted at some point after installation ? 17:53
clarkema or a typo during development
ugexe it makes me sad we continue to treat %?RESOURCES as a file when it could be any type of io source 17:54
clarkema such as? 17:56
ugexe a socket
clarkema what would be the benefit vs the socket API? 17:58
ugexe well, uh, you could use a socket 17:59
ugexe CompUnit::Repository::[Tar|Github] dont load code off the filesystem (well ::Tar does, but it streams the bytes out of the file, they don't go to an actual file somewhere first) 18:02
when you hard couple %?RESOURCES to being a file path your code can't work with those things 18:03
clarkema sure, but then there should be some equally generic way of signalling 'there are no bytes at this named place' 18:04
ugexe same with a theoretical CompUnit::Repository::FatPack::PureRaku
clarkema Especially if you're not using; if you're streaming resources from the network then then chances of failure are way higher than loading a file that 'should' be known good in the resources directory
s/not using/& files/ 18:05
ugexe I'd probably check $?DISTRIBUTION.content('resources/name-of-file').slurp
maybe %?RESOURCES<whatever>.slurp will work without the .IO 18:06
in which case that is equally ok
$?DISTRIBUTION.content('resources/name-of-file').open.slurp rather
ugexe raku -e 'my $dist = CompUnit::Repository::FileSystem.new(prefix => $*CWD).distribution; for $dist.meta<resources>.flat -> $r { say "Missing $r" unless try $dist.content("resources/$r").open.slurp }' 18:10
ugexe that will also work for the auto platform naming of stuff placed in resources/libraries/ 18:13
[Coke] --version output on git bash on windows is fine as is, in the VS command prompt, needs chcp 65001, which is expected. Looks much better now without the bold text. 21:07
(this is probably old news) 21:08
Xliff m: sub a () { 42; }; &a.WHERE # <- Can that change? 21:20
camelia ( no output )
Xliff m: sub a () { 42; }; &a.WHERE.say # <- Can that change? 21:20
camelia 2852129596152
MasterDuke i think .WHERE is generally allowed to change, but in practice maybe it won't for compile time things like subs. you'd need to ask someone like nine or timo to be sure 21:37
m: sub a() { say "hi" }; say &a.WHERE; for ^1_000_000 { my @b = .comb; }; say &a.WHERE 21:39
camelia 2741538338400
2741534130296
moon-child I see no reason why you would want to disallow .WHERE changing for compile-time things. I think mvm is not currently globally compacting, but that might change in the future 21:44
SmokeMachine Sorry for not golfing it, but does anyone have any idea of why would this be happening when the code is inside a whenever and a start only on the 2 first iterations? github.com/FCO/Red/issues/537#issu...1026262630 22:13
timo yeah, where will change, usually only up to once, though? there's a mechanism to get an id that's stable for the program's runtime for one object, which is called "objectid" 22:18
MasterDuke moon-child: not really disallow, just some stuff is created right away in gen2 or because we know it'll stick around and i don't know if .WHERE will *actually* change for them, even though you shouldn't rely on that 22:21
Xliff m: class A { }; A.new.objectid.say 22:42
camelia No such method 'objectid' for invocant of type 'A'
in block <unit> at <tmp> line 1
Xliff ^^ timo
ugexe m: use nqp; say nqp::objectid($*CWD) 22:43
camelia 4369382167664
timo yeah it's not a method 22:52
it's internal
i believe WHICH on some things uses it? 22:53

Powered by Cro and the Raku® Programming Language.

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

Thank you!