🦋 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: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:02 reportable6 left 00:04 reportable6 joined
ugexe why pull the functionality out of zef instead of just using the zef modules? 00:11
zef is not going to use external modules, so you would just end up with with multiple versions anyway 00:12
and putting it in rakudos lib/ isnt really an answer either since ideally zef will work with other raku compilers 00:13
pretty much has to go into the core if it goes anywhere else 00:14
well i guess maybe it could go in lib/ but i wouldnt be thrilled 00:21
META functionality is already tested in roast... it might not test functionality rakudo doesnt use but it does install modules to test CURI 00:22
also one might argue that every package manager shouldnt have to implement their own IO abstraction for fetching and there should be a core HTTP client 00:39
id love a lighter zef core, ive just seen how this sausage is made and it makes me nervous to think some of that stuff will cement certain things for better or worse 00:44
fwiw the reason we have e.g. cpan.json and cpan1.json is because the former has its meta6 stripped down to a variant older versions of zef understand (strips the conditional dependency logic) so already installed versions kept working and newer versions of zef started using the later variant with the new format 00:47
japhb ugexe: It sounds like there's some argument to be made for not just defining the point-in-time standard, but also explictly in what ways it's allowed to be extended in the future, and perhaps (like e.g. PNG) defining what extension paths *must* be understood to safely process the META6 data, and which ones older tools can safely assume doesn't apply to them. 01:02
01:03 jgaz joined 01:11 jgaz left 01:47 frost joined
japhb Gah, the keyword cloud on modules.raku.org (which I assume is taken from the META6 files) is a complete mess. Keywords that are probably synonymous, keywords that look similar but probably aren't, keywords only attached to some matching modules but not others, keywords using obscure abbreviations or terms, ... 02:12
raydiak the bulk of maintenance PRs I got on my modules while I was gone for over half a decade were META changes. do we *want* a fragile ecosystem, or if you make something that just works, should it continue to just work? this lack of "cement", META6.json being a poorly-defined moving target, is exactly one of the things we should be fixing. imo it's time for this corner of raku to grow up and make some 02:29
responsible commitments, even if it's scary. japhb++ I strongly agree, not just versioning but also extensibility of the meta format is likely a good idea
and I'm not saying the functionality should be rakudo-specific. I'm saying it should be in the compiler and covered by roast, which means all spec-compliant compilers would expose the same functionality 02:30
expecting everyone who wants to use this functionality to use it out of zef's modules implies that zef should forever be entrenched as the one and only authority on these things, which is exactly the kind of thing I see problems with 02:36
and please understand ugexe, I'm not implying anything negative about the quality of your work or your trustworthiness, or anything like that. I have the utmost respect for you. I'm reasoning only from a detached standpoint of logic as I see it 02:42
02:47 linkable6 left, evalable6 left 02:49 linkable6 joined 02:50 evalable6 joined
japhb Is github.com/finanalyst/ModuleCitation still the canonical module for tracking the ecosystem dependency graph? It looks like it hasn't been updated in 2+ years (and in particular, doesn't know about the zef ecosystem), and the only visible fork is older than that one, but it could have been replaced with a new thing. 03:23
03:51 Xliff joined
Xliff .tell ToddAndMargo class AA { has Str @.I is rw; submethod BUILD (:$data) { @!I[.key] = .value for $data.pairs }; method new(*%data) { self.bless( :data => %data ); }; }; AA.new(66 => 23, 10 => 1, 100 => 'a').gist.say; 03:53
tellable6 Xliff, I'll pass your message to ToddAndMargo
Xliff m: class AA { has Str @.I is rw; submethod BUILD (:$data) { @!I[.key] = .value for $data.pairs }; method new(*%data) { self.bless( :data => %data ); }; }; AA.new(66 => 23, 10 => 1, 100 => 'a').gist.say;
camelia Too many positionals passed; expected 1 argument but got 4
in method new at <tmp> line 1
in block <unit> at <tmp> line 1
Xliff m: class AA { has Str @.I is rw; submethod BUILD (:$data) { @!I[.key] = .value for $data }; method new(*@data) { self.bless( :data => @data ); }; }; AA.new(66 => 23, 10 => 1, 100 => 'a').gist.say; 03:54
camelia Too many positionals passed; expected 1 argument but got 2
in method new at <tmp> line 1
in block <unit> at <tmp> line 1
Xliff m: class AA { has Str @.I is rw; submethod BUILD (:$data) { @!I[.key] = .value for $data }; method new(*@data) { self.bless( :data => @data ); }; }; AA.new('66' => 23, '10' => 1, '100' => 'a').gist.say; 03:55
camelia Too many positionals passed; expected 1 argument but got 2
in method new at <tmp> line 1
in block <unit> at <tmp> line 1
raydiak japhb: I haven't tried it and have no idea what the state of it is, but there's also github.com/JJ/raku-river 03:58
Xliff .tell ToddAndMargo Actually, this one works... class AA { has @.I; submethod BUILD (:$data) { @!I[.key] = .value for $data[] }; method new (*@data) { self.bless( data => @data ) }; }; AA.new(2 => 'b', 4 => 66, 9 => 'apples').gist.say; 04:04
tellable6 Xliff, I'll pass your message to ToddAndMargo
japhb Thanks raydiak 04:05
raydiak yw 04:08
Xliff Wow.... 04:23
10,000 lines of Raku in less than a day.
github.com/Xliff/p6-X11 04:24
04:51 evalable6 left, linkable6 left 04:52 linkable6 joined 04:54 evalable6 joined 06:02 reportable6 left 06:04 reportable6 joined 07:02 patrickb joined 08:09 linkable6 left, evalable6 left 08:10 evalable6 joined 08:11 linkable6 joined 09:52 [TuxCM] left 09:59 [Tux] joined 10:01 [Tux] left 10:02 [Tux] joined
Geth rakudo/windowed-rakuw: 57885f6650 | (Patrick Böker)++ (committed using GitHub Web editor) | tools/templates/moar/Makefile.in
Fix `rakuw.exe` to be a non-console app

The *w.exe binaries are the "windowed" variants that don't open a console window.
  `rakuw.exe` was missing in the respective build system check.		 10:05
rakudo: patrickbkr++ created pull request #4451:
Fix `rakuw.exe` to be a non-console app
lizmat Xliff: cool! but it would help if that repo had a repo or a description :-) 10:21
*README
Geth rakudo: 4c417f318b | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Make for / map with 2+ args up to 2x as fast

By adding a IterateMoreWithoutPhasers iterator that has optimized push-all and sink-all methods, and use that when appropriate. Example:
   for ^50000 { for ^12 -> \a, \b, \c { Nil } }
Note that this is of course for the overhead of running such a loop of map: whatever is inside the block being called can drown out any performance gains here.		 10:57
10:58 sena_kun joined
Xliff lizmat: Speaking of p6-X11? 10:59
It's a day old...give it time to grow! :) 11:00
lizmat Xliff : yes :-)
sure... but people clicking on the link wind up in something without any info now...
which would be counterproductive for support in the long run?
Xliff lizmat: That should read - "It's not even a day old, give me time to write one!" 11:01
Geth nqp/new-disp: 0f486ef26d | (Jonathan Worthington)++ | src/HLL/sprintf.nqp
Avoid an implicit array stringification in NQP

It's not entirely clear why this didn't blow up under smart_strify; it certainly will under the dispatcher approach.
nqp/new-disp: 86d9dfc069 | (Jonathan Worthington)++ | 2 files
Migrate away from smrt_strify to a dispatcher

Bootstrapping bites and forces it to go into ModuleLoader, rather than living in the NQP setting with the others. More careful typing or use of explicit unboxing ops in ModuleLoader could be an alternative.
rakudo/new-disp: 531c228e8d | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Handle ForeignCode unwrapping in raku-invoke
 11:19
11:34 patrickb left 11:35 patrickb joined 11:36 patrickb left 11:37 patrickb joined
sena_kun releasable6, status 11:41
releasable6 sena_kun, Next release in ≈10 days and ≈7 hours. 1 blocker. Changelog for this release was not started yet
sena_kun, Details: gist.github.com/a526fe34143cd071bf...38094db53a
11:43 patrickb left 11:44 patrickb joined, squashable6 left 11:45 squashable6 joined 11:47 patrickb left 11:48 patrickb joined 11:49 patrickb left 11:50 patrickb joined 11:51 patrickb left 11:52 patrickb joined 11:53 patrickb left 11:54 patrickb joined, patrickb left 12:02 reportable6 left 12:05 reportable6 joined 12:28 smarton left, smarton joined 12:33 MasterDuke joined
ugexe raydiak: im all for detached logic, many of my rakudo prs were for offloading code from zef. but i had a mental model of how that stuff could fit into raku in a clean, backwards compatible, and (arguably) minimalistic way. when i try to imagine a meta6 model it is none of those things, so understand im reluctant would appreciate being proven wrong 12:58
13:00 sena_kun left 13:30 sena_kun joined 13:31 patrickb joined 13:33 MasterDuke left 13:40 timo left, MasterDuke joined, timo joined 14:16 patrickb left, patrickb joined 14:18 patrickb left, patrickb joined 14:20 patrickb left, patrickb joined 14:22 patrickb left, patrickb joined 14:26 patrickb left, patrickb joined 14:28 dogbert17 left, dogbert17 joined 14:30 patrickb left 14:31 patrickb joined 14:32 patrickb left 14:33 patrickb joined 14:34 patrickb left 14:35 patrickb joined, patrickb left
Geth rakudo/new-disp: dcde306f8c | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Add missing guard in proxy removal resume
 14:56
roast: fe65760bfc | Altai-man++ | S32-list/create.t
Add test for #2060
 15:07
roast: 033290f9fd | (Vadim Belman)++ (committed using GitHub Web editor) | S32-list/create.t
Merge pull request #748 from Raku/add-test-for-2060

Add test for #2060
15:26 Kaiepi left 15:28 Kaiepi joined 15:30 Kaiepi left 15:34 Kaiepi joined 15:36 Kaiepi left 15:40 Kaiepi joined 15:49 Xliff left
Geth rakudo/new-disp: 0b32c91b35 | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Typed error report of ambiguous multi dispatch
 16:08
16:22 patrickb joined 16:47 MasterDuke left
Geth rakudo/new-disp: ad064fdf41 | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Reinstate `is default` and exact arity tie-breaks
 16:54
17:01 sena_kun left
patrickb ugexe: It seems `prove.bat` on windows fails to reliably deal with executables with a space in their path. This in turn trips up Zef. (I checked. The arg arrives correctly in the prove.bat script on the perl side.) 17:41
ugexe: The `Zef::Service::Shell::Test` implementation works fine in that case. Any reason we don't make that implementation the default? 17:42
Hm. Could also just make `probe` return False on Windows. 17:44
17:52 MasterDuke joined
patrickb ugexe: Created github.com/ugexe/zef/pull/405 17:54
Geth rakudo/new-disp: cb64be2426 | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Update error handling
rakudo/new-disp: f728baba2d | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Handle end of dispatch list in non-trivial cases
raydiak ugexe: as I picture it, all we're talking about is something which takes a meta file or its contents as IO, Str, or Associative (either as separate routines or as a multi, maybe multi method new()), validates it, and returns either Failure(s), or an object which represents that meta information in a consistent way regardless of which optional data was or wasn't specified, which form of depends was used, 17:57
whether deps were specified with just a name or also :ver<> style specifications, etc.
having done a good job of writing a well-structured package manager yourself, I'd be more likely to defer to you for the exact details of the API and implementation, but I hope that illustrates the concept at least. from there it can be covered by roast and used by CompUnit stuff, zef, fez, and anything else that wants to. as far as I can see, there is nothing unclean, incompatible, or bloated about
something of that nature
I can see arguments for and against various details here, e.g. only the form which passes a path could actually verify that provides and resources are where they should be, maybe it should throw catchable exceptions instead of returning failures, stuff like that, but I think the basic concept is sound
as for how we provide for versioning and/or extensibility of the meta spec, that's an interesting idea that japhb brought up. I hadn't thought very deeply into that part yet. the obvious way to version it is just a "meta" or "meta-version" key. though off the top of my head, I rather like the idea of tying it to language version instead. a module written for e.g. 6.c shouldn't have the meta spec changing 18:02
under it. this makes it more fully a part of the spec, which is what I think we should be aiming for
18:03 reportable6 left 18:05 reportable6 joined
tonyo the more i think about that problem, the more i dislike putting it in core for anything that core doesn't explicitly need. when you `use XYZ` raku doesn't go to the meta, load the depends, load all of those modules, etc. the only thing that needs that info is the package manager, which is the case with a lot of meta data 18:16
raydiak raku uses it for the provides section at the least, possibly other things 18:18
*rakudo
github.com/rakudo/rakudo/search?q=META6.json 18:19
tonyo moving the implementation to core wouldn't have caught the bad depends key in the META unless rakudo tries to assert control over things that it doesn't use or need 18:21
raydiak so we want a partial implementation in rakudo which is separate from the full implementation? that sounds like the road right back to where we are now, where it isn't properly specified at all and just settles on whatever the prevailing implementation of the time is (currently zef but that wasn't and probably won't always be the case). and making it an external module means anything that wants to be capable 18:24
of installing that module can't use it.
tonyo if the only thing that needs to consume keys in the META, moving the tools to core won't solve the problem of OK meta vs BAD meta. eg zef needs to know the deps, fez doesn't care because it's not going to validate them
raydiak I won't be around much today to elucidate the idea. I just hope we think really carefully about what we're doing. we can't keep just changing our minds about this and submitting PRs to the whole ecosystem, that is not a forward-looking scalable approach 18:26
centralizing the idea in roast is what solves those problems
tonyo i'm saying you can't put that verification into core because what's relevant to rakudo is different from the tools consuming them. eg, another package manager may not even use the depends key in META but just analyze the AST - now you're saying rakudo _won't_ allow it because the depends key is missing even though it may work fine with that package manager 18:27
policing the ecosystem seems like a bad way to use core resources 18:28
the ecosystem is what it is, using things like p6c would be a big step forward and having tools that can test modules against rakudo versions, etc would be lower hanging fruit and a bigger win 18:29
deprecating things like p6c*
moving away from cpan would also move that needle forward 18:32
raydiak I don't find the fact that rakudo only uses some of META6 entirely persuasive, but I really have to move on with other things today, unfortunately. I seem to be rolling a boulder uphill anyway, maybe I'm just totally off base. hopefully someone takes this line of thought and does something with it, in whatever form 18:38
tonyo if your familiarity with how the meta is used is doing a github search for META6 then i'd recommend reading core about how it's actually used and then looking in zef or fez to see how they use it. zef and fez use it in similar ways to core but also use other information from the meta that core really _doesn't care about_ 18:40
if you remove the flexibility of external tools in figuring out if it can do what i mean by putting that strictness in core, then you're removing a lot of cool possibilities 18:41
maybe zef can determine depends by parsing the AST tree and it doesn't need that in the meta but now it can't install modules for rakudo because rakudo thinks the META is invalid because there's no depends key ... 18:42
ugexe well i presume rakudo would not be enforcing validation (i hope_ 18:45
instead it would provide some utility methods (similar to Test's 'ok')
so that others can do validation 18:46
the more i think about it the more i think a good first (big) step would be to write the current spec in OpenAPI so it is more easily language agnostic 18:47
which again a naive version can be seen here github.com/ugexe/Perl6-App--OpenAP...6Validator
tonyo right but rakudo can't tell you the META has invalid tags, it's overreaching 18:48
ugexe yeah... i dont remember where but something said something along the lines of parsers of meta6 data need to be aware it can be arbitrarily extended with new fields 18:49
the other way is having some field specifically to contain extension stuff, but thats not much better really
it could tell you that you don't have a 'name' field I suppose 18:50
that cant be inferred from code even theoretically
tonyo same with depends, though - rakudo doesn't do anything with it
ugexe right. ive mentioned before if we could find something for rakudo to do with it then it would help
tonyo right, i agree. my point is that rakudo can only say OK on a subset and that core shouldn't refuse anything being installed to a CUR based on anything it doesn't use like the `depends` key 18:51
ugexe only thing i can come up with is cleaning up orphaned stuff
tonyo name, ver, api, auth - all fine 18:52
there's another one i'm failing to remember atm
ugexe if rakudo used the depends key to find orphaned modules then it could be correct in rejecting an in valid depends 18:53
not sure i'd do that though... that should happen before it reaches rakudo 18:54
tonyo agreed, but until it does, it shouldn't reject anything with a weird looking or null depends 18:56
ugexe patrickb: the reason for preferring prove is the e.g. test summary 19:07
probably not a huge deal to just remove prove from zef, but something to consider
Geth rakudo: patrickbkr++ created pull request #4452:
Fix CURI probing on Windows		 19:16
ugexe if IO::Path.w doesn't work on windows then there are probably way bigger problems than this 19:26
s/doesnt work/isnt reliable/ 19:27
lizmat well, checking for .w is a race condition on any system, really
as you won't know you can actually write until you actually write, as another thread could have revoked the .w ? 19:28
19:30 AlexDaniel left
patrickb ugexe: Re broken .w - We have to start somewhere... 19:34
Also the breakage is in libuv and well known. So node currently lives with the same limitations.
ugexe in what way is it unreliable? 19:38
i havent had time to grok that much 19:39
patrickb Doesn't check the windows permissions at all (the ACLs). Only looks at that read only flag, that one can set to prevent oneself from deleting files. 19:42
Unreliable might be the wrong word. Mostly unimplemented fits better.
Geth rakudo: 4f5fb9e67c | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Reimagine IterateTwoWithoutPhasers

This affects for loops / maps that take 2 parameters. With regards to performance, there's very little difference with the push-all and sink-all state, although they have fewer allocations now, so that may affect things in a real life situation.
... (6 more lines)		 19:43
ugexe how can i reproduce the issue with a one liner on windows? 19:46
my naive attempts show it does what i want
or rather it does what is consistent (i.e. i cant mkdir inside of C:\Program Files so it doesnt surprise me if $*CWD.w is false) 19:48
patrickb ugexe: can you try `raku -e "say 'C:\Windows'.IO.w; 'C:\Windows\Non-existing.txt'.IO.spurt('foo')"` 19:49
ugexe do you know if its broke for when .w returns false too? 19:50
patrickb not sure.
ugexe i dunno if that actually matters... 19:51
at a minimum i think you'll want to put a `try` on it 19:52
you only care if you can open the file and should disregard any exceptions from opening closing or unlinking it 19:54
patrickb looks up try semantics 19:55
ugexe for exampe two instances of rakudo might be running and then one of the unlinks might fail (but who cares) 19:56
patrickb Pushed an update. 19:59
ugexe did you happen to find actual instances in nodejs of them doing this? because i dont doubt it now and am interested
patrickb Didn't look. 20:00
20:01 MasterDuke left
ugexe i cant help but think github.com/rakudo/rakudo/blob/cdad...n.pm6#L176 could be used to do this 20:06
it would however theoretically lock the repository when checking if it was writeable 20:07
no thats probably not a great idea 20:11
20:13 melezhik joined
melezhik . 20:13
patrickb ugexe: I actually used that line as reference for the file creation logic. But trying to meddle the writabilily check into the lock check is probably causing more pain than good. 20:15
ugexe yeah. i think i'll need a day to come to terms with this lol 20:17
patrickb Take your time. I'm grateful for thoughtful feedback. ;-) 20:19
20:19 patrickb left 20:20 patrickb joined
patrickb ugexe: re github.com/ugexe/zef/pull/405 Do you think it's possible for the error "'C:\Program' is not recognized as an internal or external command" to not originate from prove, but rakudo itself? 20:21
ugexe that was kind of my thought since its passing prove relative paths which themselves probably have no spaces 20:22
i guess theoretically they could ala `t/my tests/test.rakutest` 20:23
patrickb In my concrete case they aren't.
Rakudo is in C:\Program Files, but zef is in C:\data\repos\zef 20:24
ugexe actually it can never have spaces... it will always be t/
patrickb prove is passed t/. But prove will pass all those test file names to rakudo. 20:25
ugexe i dont see how that would be a problem. my expectation is that `prove -e 'perl' "C:\Program Files\foo.t"` works and thus `prove -e 'raku' "C:\Program Files\foo.t"` works as well 20:29
patrickb True. Do you know whether perl works without problems in a path with spaces on windows? Strawberry Perl installs to C:\Strawberry by default. 20:31
20:52 AlexDaniel joined
patrickb ugexe: OK. I'm now certain that the behavior is caused by prove. Analysis is in the PR. 21:22
Geth rakudo/new-disp: c4861450f1 | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Produce proxy readers beyond the initial set
 21:23
rakudo: bee5c7afd6 | (Ben Davies)++ | src/core.c/IO/Socket/INET.pm6
Clean up sockets created by IO::Socket::INET.new on error

Related to #4370.		 21:25
rakudo: 271f17b04d | (Ben Davies)++ | src/core.c/IO/Socket/INET.pm6
Fix nqp::socket passivity parameter values post-refactor

10 denotes a passive socket, not an active one. This isn't relevant to MoarVM, but is to the JVM.
rakudo: 68b08a3523 | (Vadim Belman)++ (committed using GitHub Web editor) | src/core.c/IO/Socket/INET.pm6
Merge pull request #4391 from Kaiepi/socket-cleanup

Clean up sockets created by IO::Socket::INET.new on error
21:26 linkable6 left 21:27 linkable6 joined
Geth rakudo/new-disp: 5b5fbad9b5 | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Fix dispatch of method calls on $scalar.VAR
 21:33
patrickb I'm off to bed. 'night everyone! 21:38
21:39 patrickb left
tonyo lizmat: for raku con, i'm going to end up having to upload a video. are there details somewhere on to whom and what format i need to do this? 21:43
jdv will you be in a remote location without internets? 21:52
tonyo yes 21:56
i can be online for a q&a possibly, depends on what time/when, just need to know. i'll be driving across the US so i need to be able to plan 21:57
Geth rakudo/new-disp: a03bc12c6a | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
a03bc12c6a | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
 22:03
rakudo/new-disp: ba8c5adc83 | (Jonathan Worthington)++ | src/vm/moar/dispatchers.nqp
Update some error throwing

These track changes in `master` since the dispatchers were implemented based upon the code that used be in spesh plugins.
lizmat tonyo: I don't have such details, you probably should check with ash 22:29
23:43 MasterDuke 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!