[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 [03:43] *** squashable6 joined [03:43] *** squashable6 left [03:45] *** squashable6 joined [05:12] *** linkable6 left [05:12] *** evalable6 left [05:12] *** tellable6 left [05:12] *** evalable6 joined [05:13] *** linkable6 joined [05:13] *** tellable6 joined [06:02] *** reportable6 left [06:03] *** reportable6 joined [07:09] *** patrickb joined [07:24] *** AlexDaniel joined [09:19] anyone have thoughts about the best way to regain the functionality lost in https://github.com/rakudo/rakudo/commit/beeafc12fe4fc16bb780fc675b0a55292bfd9f6b ? the lack thereof is causing https://logs.liz.nl/raku/2021-06-11.html#01:38 [09:32] wow, a commit > 7 years old [09:33] I have no thoughts about that [09:34] well, on second thought: what happens if we revert that commit ? [09:35] right, who knows if it's even still a problem, could have been choking on an issue fixed long ago [09:38] have you tried reverting it ? [09:38] not yet, just recently got done chasing it down. don't even have java installed yet on this machine [09:39] 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:40] sorry usev6 :-) [09:42] heh good point. I'll find out... [09:43] or even disable it just for jvm [09:44] moon-child: good point, conditional compilation wasn't available then for the nqp files, if I recall correctly [10:07] 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:09] yes, reverting fixes it [10:10] raydiak: ok, then please make a PR for it :-) [10:13] sure thing. should I add the if jvm stuff, or don't worry about it because it might actually work on modern jvm? [10:14] 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 :-) [10:16] heh, true. PR will be up in a few [10:26] ¦ rakudo: raydiak++ created pull request #4397: Restore Pod6 E<> html entity support [10:26] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/4397 [10:27] guess I'm a contributor again :) [10:28] raydiak++ [10:28] and ++raydiak # for future endeavours [10:31] 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:38] well, lead in the drinking water is supposed to have contributed to the downfall of the Roman Empire :-) [10:39] really?? wow [10:39] although that appears to have been debunked :-) [10:39] https://penelope.uchicago.edu/~grout/encyclopaedia_romana/wine/leadpoisoning.html [10:44] 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:45] proper ventilation is important, even more so in the covid era [10:46] radon is usually only an issue in poorly ventilated basements [10:46] there is a storage/laundry room downstairs. no windows [10:46] as there's more of the source exposed (soil, building materials) [10:47] but yeah, if you have doubts, test! [10:50] 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:51] * lizmat hopes you'll be able to find a better place to live [10:53] 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 [11:00] *** frost joined [11:13] way past my intended bed time. thanks for the direction, chatting, and encouragement! o/ [11:19] ¦ rakudo: cognominal++ created pull request #4398: [doc in script] fix an url and make it a link [11:19] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/4398 [11:27] ¦ rakudo: 5885e2cc54 | (Stéphane Payrard)++ | lib/Test.rakumod [11:27] ¦ rakudo: [doc in script] fix an url and make it a link [11:27] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/5885e2cc54 [11:27] ¦ rakudo: 16eaa06936 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | lib/Test.rakumod [11:27] ¦ rakudo: Merge pull request #4398 from cognominal/fix-url-and-make-it-link [11:27] ¦ rakudo: [11:27] ¦ rakudo: [doc in script] fix an url and make it a link [11:27] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/16eaa06936 [11:35] *** sena_kun joined [11:44] *** b2gills left [12:02] *** reportable6 left [12:04] releasable6, status [12:04] sena_kun, Next release in ≈8 days and ≈6 hours. 1 blocker. 0 out of 14 commits logged [12:04] sena_kun, Details: https://gist.github.com/f1a422c8831560fa71b36caacd2cddc2 [12:04] *** reportable6 joined [12:56] *** Kaipi joined [12:58] *** Kaiepi left [12:59] *** frost left [13:12] *** b2gills joined [14:28] *** vrurg left [14:31] 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:33] 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:34] but i'm wondering, do we have any examples of that *actually* happening? [14:36] 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 [14:37] 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:38] NativeCall comes to mind :-) [14:39] 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) [14:40] should we offer rakudo's lib directory as a middle ground between inclusion in core and "exclusion" to the ecosystem? [14:41] dual life problem [14:41] you still wouldn't want to add just anything and everything, but maybe relaxed criteria could be established? [14:41] ? [14:41] and a problem with depending on rakudo/lib modules in general [14:41] no real versioning [14:43] 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] practically they very much do though [14:43] e.g., how many times has Test increased its version? [14:44] and we release a new rakudo (nearly) every month [14:44] how many times has NativeCall or new modules been added to that single distribution? [14:45] 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 [14:46] my point is every time the sha1 of a distribution is changed it really needs to be a different version [14:47] 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 [14:47] afk for a few hours, possibly rest of the day& [14:48] eigenstates is in lib? [14:48] ive had changes to NativeCall break zef before, and made changes that required NativeCall changes before for instance [14:49] or you mean it was initially rejected from core, released to the ecosystem, then eventually made it into core? [14:49] no [14:50] MasterDuke34: https://raku.land/cpan:ELIZABETH/eigenstates :-) [14:50] really afk& [14:50] ugexe: so you're saying we should be more strict about versioning what's in lib? [14:51] or that it can't be versioned and that's a problem? [14:52] 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:54] *** lizmat_ joined [14:54] 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 [14:57] https://stackoverflow.com/questions/6009476/what-is-a-dual-life-module [14:57] fwiw if you arent familiar with that^ [14:57] *** lizmat left [14:59] ah, only somewhat [14:59] https://github.com/ugexe/Perl6-CompUnit--Repository--Lib it was my intention to one day get this into core but the motivation never took me that way [15:01] but that wouldn't *have* to be a problem [15:01] something could start in lib and then move to core - not a problem [15:01] not really [15:02] or could start in lib and then move to ecosystem - not a problem [15:02] lets take Test for instance [15:02] you then add Test to your dependencies [15:02] but now there isnt a Test module for zef to find in rakudo [15:02] so it looks to the ecosystem and may or may not find it or the right version [15:04] why isnt there a Test module for zef to find in rakudo? [15:05] if it was moved to core `use Test` is no longer going to try and load a Test module [15:06] or rather its not going to load the Test code that was moved to core [15:06] ah [15:10] would it have to though? core doesn't really have any modules now, but could it? [15:13] there are two `my module {...}` used in core code. is it possible to stick a `module {...}` at the end of the core setting? [15:13] 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 [15:18] 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] 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 [15:19] yeah. imo lib/ should be constrainted to things that would be useful on other raku implementations [15:20] even if they aren't in the ecosystem those modules can be distributed to install targets (like a self contained lib) [15:38] *** Kaipi left [15:42] ¦ rakudo/rakuast: 67e0d0cf50 | (Jonathan Worthington)++ | 12 files [15:42] ¦ rakudo/rakuast: Prepare for expression thunking [15:42] ¦ rakudo/rakuast: [15:42] ¦ rakudo/rakuast: Various contexts imply a thunk on an expression. Functionality that [15:42] ¦ rakudo/rakuast: needs this includes: [15:42] ¦ rakudo/rakuast: [15:42] ¦ rakudo/rakuast: * Attribute default values [15:42] ¦ rakudo/rakuast: * The LHS of `xx` (and other such thunky operators) [15:42] ¦ rakudo/rakuast: <…commit message has 11 more lines…> [15:42] ¦ rakudo/rakuast: review: https://github.com/rakudo/rakudo/commit/67e0d0cf50 [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 [21:19] raydiak: I hope my comment at https://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:20] I don't see a (realistic) way of making the code in src/core/Pod.nqp work on the JVM backend. [21:21] 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:22] raydiak++ ;) [21:22] 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... [21:22] bartolin++ thanks for the investigation :) [21:44] *** lizmat_ is now known as lizmat [21:49] 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:50] raydiak: uniprop doesn't work on JVM I don't think? [21:53] ah [21:55] 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:59] 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? [22:05] *** patrickb left [22:20] theoretically we could even just break it up into multiple hashes and then merge them unless I'm mistaken [22:23] *** sena_kun left [22:58] *** japhb joined [23:04] I added the old implementation back in for JVM to https://github.com/rakudo/rakudo/pull/4397 and now CI is happy [23:06] 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:24] 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: https://github.com/ugexe/zef2/blob/5a9c581648cd3b28975f0b98e31d9a2e395c28f2/t/distribution.t#L111-L130 [23:24] simple implementation: https://github.com/ugexe/zef2/blob/5a9c581648cd3b28975f0b98e31d9a2e395c28f2/lib/Zef/Distribution.pm6#L58-L107 [23:25] 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:26] *** Xliff left [23:48] 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'