🦋 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:05 reportable6 joined 02:18 moon-child left 02:23 moon-child joined 03:22 AlexDaniel left 03:43 squashable6 left, squashable6 joined, squashable6 left 03:45 squashable6 joined 05:12 linkable6 left, evalable6 left, tellable6 left, evalable6 joined 05:13 linkable6 joined, tellable6 joined 06:02 reportable6 left 06:03 reportable6 joined 07:09 patrickb joined 07:24 AlexDaniel joined
raydiak anyone have thoughts about the best way to regain the functionality lost in github.com/rakudo/rakudo/commit/be...292bfd9f6b ? the lack thereof is causing logs.liz.nl/raku/2021-06-11.html#01:38 09:19
lizmat wow, a commit > 7 years old 09:32
I have no thoughts about that 09:33
well, on second thought: what happens if we revert that commit ? 09:34
raydiak right, who knows if it's even still a problem, could have been choking on an issue fixed long ago 09:35
lizmat have you tried reverting it ? 09:38
raydiak not yet, just recently got done chasing it down. don't even have java installed yet on this machine
lizmat fwiw, I'm more interested in reverting it would fix the issue on the MoarVM backend, then on breaking the JVM backend in this day and age 09:39
sorry usev6 :-) 09:40
raydiak heh good point. I'll find out... 09:42
moon-child or even disable it just for jvm 09:43
lizmat moon-child: good point, conditional compilation wasn't available then for the nqp files, if I recall correctly 09:44
bartolin lizmat: :) I'm on your side, there. I could take a look if it's still a problem -- but probably only this evening or over the weekend. 10:07
raydiak yes, reverting fixes it 10:09
lizmat raydiak: ok, then please make a PR for it :-) 10:10
raydiak sure thing. should I add the if jvm stuff, or don't worry about it because it might actually work on modern jvm? 10:13
lizmat make the PR, maybe bartolin can then have a look at it over the weekend 10:14
it's not like it's super urgent if it has been broken for 7+ years :-)
raydiak heh, true. PR will be up in a few 10:16
Geth rakudo: raydiak++ created pull request #4397:
Restore Pod6 E<> html entity support		 10:26
raydiak guess I'm a contributor again :) 10:27
lizmat raydiak++ 10:28
and ++raydiak # for future endeavours
raydiak aw, thanks. I switched to bottled water a couple days ago, seems to be helping a lot with my brain fog. we have really terribly hard water in this house, no idea how old the plumbing is. so hopefully more to come 10:31
lizmat well, lead in the drinking water is supposed to have contributed to the downfall of the Roman Empire :-) 10:38
raydiak really?? wow 10:39
lizmat although that appears to have been debunked :-)
penelope.uchicago.edu/~grout/encyc...oning.html
raydiak I'll have to see about getting a test kit or something, who knows what's in here. I think they said something about lead paint and maybe radon when we moved in, too 10:44
lizmat proper ventilation is important, even more so in the covid era 10:45
radon is usually only an issue in poorly ventilated basements 10:46
raydiak there is a storage/laundry room downstairs. no windows
lizmat as there's more of the source exposed (soil, building materials)
but yeah, if you have doubts, test! 10:47
raydiak really we're just aiming to move when our lease is up later this year. the lease doesn't allow my dog here either so she's staying with my mother, but I miss her very much. moving here was more of a stop-gap measure to get out of slummy apartments 10:50
lizmat hopes you'll be able to find a better place to live 10:51
raydiak thanks! we should, it'll just take some hunting. the market here is going insane, seems like rent has just about doubled in the past 5 years or so 10:53
11:00 frost joined
raydiak way past my intended bed time. thanks for the direction, chatting, and encouragement! o/ 11:13
Geth rakudo: cognominal++ created pull request #4398:
[doc in script] fix an url and make it a link		 11:19
rakudo: 5885e2cc54 | (Stéphane Payrard)++ | lib/Test.rakumod
[doc in script] fix an url and make it a link
 11:27
rakudo: 16eaa06936 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | lib/Test.rakumod
Merge pull request #4398 from cognominal/fix-url-and-make-it-link

  [doc in script] fix an url and make it a link
11:35 sena_kun joined 11:44 b2gills left 12:02 reportable6 left
sena_kun releasable6, status 12:04
releasable6 sena_kun, Next release in ≈8 days and ≈6 hours. 1 blocker. 0 out of 14 commits logged
sena_kun, Details: gist.github.com/f1a422c8831560fa71...aacd2cddc2
12:04 reportable6 joined 12:56 Kaipi joined 12:58 Kaiepi left 12:59 frost left 13:12 b2gills joined 14:28 vrurg left
MasterDuke34 i just watched the recording of paul evans' talk about adding keywords to perl. skipping over the cool technical stuff, i was struck by his description of how some keyword modules have made the jump from cpan to core perl 14:31
and that's been the common refrain for proposed additions to raku/rakudo that aren't met with near-univeral approval, "implement it in module, and if it's popular enough we'll then consider for addition to core" 14:33
but i'm wondering, do we have any examples of that *actually* happening? 14:34
and i'm also wondering if there are some factors that might make it harder for us (at least right now): 14:36
the smaller userbase in general so maybe less positive noise about a popular module
number of people who perhaps use rakudo star which already comes with some modules so don't go out of their way to install more 14:37
lizmat NativeCall comes to mind :-) 14:38
MasterDuke34 and that in turn led me to thinking about rakudo's lib directory. aiui, raku doesn't make any guarantees about its contents (though maybe rakudo does) 14:39
(good point re NativeCall, i think that migration happened before my time)
should we offer rakudo's lib directory as a middle ground between inclusion in core and "exclusion" to the ecosystem? 14:40
ugexe dual life problem 14:41
MasterDuke34 you still wouldn't want to add just anything and everything, but maybe relaxed criteria could be established?
?
ugexe and a problem with depending on rakudo/lib modules in general
no real versioning
MasterDuke34 but theoretically these aren't things that would have multiple versions. if they're nearly core-level features, i wouldn't expect someone to want to increase the module version all that frequently 14:43
ugexe practically they very much do though
MasterDuke34 e.g., how many times has Test increased its version?
and we release a new rakudo (nearly) every month 14:44
ugexe how many times has NativeCall or new modules been added to that single distribution?
MasterDuke34 SIL, SL, snapper, and Telemetry in the past couple years 14:45
but i'm not sure if you're getting at something with that question or just looking for stats
ugexe my point is every time the sha1 of a distribution is changed it really needs to be a different version 14:46
lizmat MasterDuke34: I know of several modules that were added because inclusion in the core was considered not ok 14:47
eigenstates being one of them
afk for a few hours, possibly rest of the day&
MasterDuke34 eigenstates is in lib? 14:48
ugexe ive had changes to NativeCall break zef before, and made changes that required NativeCall changes before for instance
MasterDuke34 or you mean it was initially rejected from core, released to the ecosystem, then eventually made it into core? 14:49
tonyo no
lizmat MasterDuke34: raku.land/cpan:ELIZABETH/eigenstates :-) 14:50
really afk&
MasterDuke34 ugexe: so you're saying we should be more strict about versioning what's in lib?
or that it can't be versioned and that's a problem? 14:51
ugexe it can indeed be versioned and should be. the issue is it also needs to be split up into distributions which would mean `-Ilib` for pre-install rakudo would need to be `-Ilib/NativeCall -Ilib/Test`. Other than that it would just need some tooling to automatically bump versions in some META6.json whenever changes are made 14:52
14:54 lizmat_ joined
MasterDuke34 fwiw, i'm not intending this as a proposal for a massive policy shift. i just realized i'd never thought of suggesting lib as a third option besides core and ecosystem 14:54
and i guess i'm not sure what are the criteria for core vs lib vs ecosystem
ugexe stackoverflow.com/questions/600947...ife-module 14:57
fwiw if you arent familiar with that^
14:57 lizmat left
MasterDuke34 ah, only somewhat 14:59
ugexe github.com/ugexe/Perl6-CompUnit--R...itory--Lib it was my intention to one day get this into core but the motivation never took me that way
MasterDuke34 but that wouldn't *have* to be a problem 15:01
something could start in lib and then move to core - not a problem
ugexe not really
MasterDuke34 or could start in lib and then move to ecosystem - not a problem 15:02
ugexe lets take Test for instance
you then add Test to your dependencies
but now there isnt a Test module for zef to find in rakudo
so it looks to the ecosystem and may or may not find it or the right version
MasterDuke34 why isnt there a Test module for zef to find in rakudo? 15:04
ugexe if it was moved to core `use Test` is no longer going to try and load a Test module 15:05
or rather its not going to load the Test code that was moved to core 15:06
MasterDuke34 ah
would it have to though? core doesn't really have any modules now, but could it? 15:10
there are two `my module <name> {...}` used in core code. is it possible to stick a `module <name> {...}` at the end of the core setting? 15:13
ugexe what would be the point? sure `use Test` would work but the reason you would want that to work is so you can grab whatever needs to be used. if its core there is no real reason to need to `use` it, and since its in the core there is no need for `use Test` to tell us if its installed since simply checking if raku version is e.g. 6.f would be sufficient
15:15 vrurg joined
ugexe with all that said i could make the argument that NativeCall belongs in core, and *maybe* Test. CompUnit::Repository::Staging absolutely does but cant be for some reason 15:18
MasterDuke34 so it sounds like there are technical, and not just policy, reasons to not suggest lib as a middle ground for stuff that's rejected from core
ugexe yeah. imo lib/ should be constrainted to things that would be useful on other raku implementations 15:19
even if they aren't in the ecosystem those modules can be distributed to install targets (like a self contained lib) 15:20
15:38 Kaipi left
Geth rakudo/rakuast: 67e0d0cf50 | (Jonathan Worthington)++ | 12 files
Prepare for expression thunking

Various contexts imply a thunk on an expression. Functionality that needs this includes:
  * Attribute default values
  * The LHS of `xx` (and other such thunky operators)
... (11 more lines)		 15:42
18:02 reportable6 left 18:04 reportable6 joined 18:50 Kaiepi joined 19:58 Kaiepi left 19:59 Kaiepi joined 20:04 Kaiepi left 20:12 Kaiepi joined 20:27 Xliff joined
bartolin raydiak: I hope my comment at github.com/rakudo/rakudo/pull/4397 makes sense. Maybe it makes sense to do the special case for the JVM backend in your branch, so that the CI is happy? 21:19
I don't see a (realistic) way of making the code in src/core/Pod.nqp work on the JVM backend. 21:20
raydiak sure, I can do that. totally makes sense. I considered doing that right off the bat, but I wanted to make sure it's still broken for JVM since it had been so long. at least now we understand what it's smacking into 21:21
bartolin raydiak++ ;) 21:22
raydiak the only part I don't get is why can't it be loaded from a file? or, how do things like uniprop work? there has to be some giant hash that handles that somewhere...
bartolin++ thanks for the investigation :)
21:44 lizmat_ is now known as lizmat
moon-child I'm surprised that limit is there; 64k seems kinda small. And I can't imagine the gains from using a 16-bit index would be that significant 21:49
lizmat raydiak: uniprop doesn't work on JVM I don't think? 21:50
raydiak ah 21:53
lizmat so, let me get this straight: is the size of the hash the problem on the JVM backend? Or is it the initialization code? 21:55
raydiak from what I read, it's the code. you can have larger java arrays, but you load it from an external file (or construct it procedurally). is that right bartolin? 21:59
22:05 patrickb left
raydiak theoretically we could even just break it up into multiple hashes and then merge them unless I'm mistaken 22:20
22:23 sena_kun left 22:58 japhb joined
raydiak I added the old implementation back in for JVM to github.com/rakudo/rakudo/pull/4397 and now CI is happy 23:04
I do suspect there should be a sane way to support this in JVM, but at least for now it won't be broken 23:06
ugexe ive been looking at some old experimental code, and ran into this `Distribution` that allows you to store all files for a distribution inside the META6.json itself and will install when passed to CURI.install 23:24
example meta6: github.com/ugexe/zef2/blob/5a9c581...#L111-L130
simple implementation: github.com/ugexe/zef2/blob/5a9c581...6#L58-L107
taking it a step further you could have a CUR that loads those distributions, and this you have a kind of fat-pack solution 23:25
23:26 Xliff left
moon-child it should be possible at least if it's a constant? World.nqp has a 10-year-old todo reading 'XXX Want constant syntax in NQP really' 23:48

Powered by Cro and the Raku® Programming Language.

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

Thank you!