šŸ¦‹ 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:03 reportable6 left, reportable6 joined 00:11 frost joined 02:15 frost left 02:16 MasterDuke left 03:10 AlexDaniel left 03:12 AlexDaniel joined 03:35 AlexDaniel left 05:22 coverable6 left, greppable6 left, notable6 left, statisfiable6 left, benchable6 left, shareable6 left, bisectable6 left, unicodable6 left, quotable6 left, committable6 left, bloatable6 left, linkable6 left, releasable6 left, reportable6 left, evalable6 left, nativecallable6 left, sourceable6 left, tellable6 left, squashable6 left, sourceable6 joined, releasable6 joined, notable6 joined, benchable6 joined, quotable6 joined, squashable6 joined, linkable6 joined, committable6 joined 05:23 unicodable6 joined, reportable6 joined, coverable6 joined 05:24 tellable6 joined, statisfiable6 joined, bloatable6 joined, nativecallable6 joined 05:25 evalable6 joined, shareable6 joined, greppable6 joined, bisectable6 joined 05:26 squashable6 left 05:28 squashable6 joined 06:02 reportable6 left 06:03 reportable6 joined 06:18 notna joined 07:05 patrickb joined 07:25 AlexDaniel joined 07:49 AlexDaniel left 08:00 AlexDaniel joined 08:23 AlexDaniel left 08:33 AlexDaniel joined 08:40 AlexDaniel left 09:00 frost joined 09:06 AlexDaniel joined 10:09 linkable6 left, evalable6 left 10:11 evalable6 joined, linkable6 joined 10:22 Kaiepi left 10:23 Kaiepi joined 10:42 discord-raku-bot left
Geth rakudo: 917d674bc3 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
R:I:UnendingValue no longer a PredictiveIterator

Yes, the number of elements it will generate is known (Inf), but that is really a technicality and inhibiting making it harder to make PredictiveIterators more optimizable (if they cannot be lazy).
10:56 discord-raku-bot joined 12:02 reportable6 left 12:03 reportable6 joined
Geth rakudo: 03aef65c59 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Separate R:I:IntRange into two classes

One for the non-lazy case, and one for the lazy case with Inf as end-point. The lazy case is no longer a PredictiveIterator. This causes a minor performance improvement for both the 1..N as well as the 1..Inf case.
rakudo: 7cf3927d39 | (Elizabeth Mattijsen)++ | src/core.c/Iterator.pm6
PredictiveIterator provides own push-until-lazy

Since PredictiveIterators are no longer expected to be lazy, we can shortcut .push-until-lazy to call .push-all without laziness check.
This makes test-t about 1% faster.
13:03 linkable6 left, evalable6 left 13:06 linkable6 joined, evalable6 joined 13:19 frost left 14:24 melezhik joined
melezhik . 14:25
15:18 notna left 16:18 linkable6 left, evalable6 joined, evalable6 left 16:19 evalable6 joined, linkable6 joined 18:02 reportable6 left 18:04 melezhik left 18:05 reportable6 joined
Geth rakudo: 2542a0ac44 | (Elizabeth Mattijsen)++ | 3 files
Implement "next foo"

Allow a value to be specified with "next". In a .map like context, it specifies the value of the current iteration, while skipping the rest of the iteration (as you would expect "next" to do). In a .grep like context, the value specified is inspected on truthiness: when true, then the element will be included (while skipping the rest of the iteration). In any other case, the element will *not* be included.
lizmat figured nobody disliked "last foo", it would be ok to directly push to master 19:00
20:24 [Coke] left, [Coke] joined 21:39 patrickb left 21:41 zostay left 21:42 kawaii_ left 21:52 kawaii_ joined 21:53 zostay joined
Geth problem-solving/clarify-readme: e43a7a59a4 | (Daniel Sockwell)++ (committed using GitHub Web editor) | README.md
clarify PS process in README

This is an attempted solution to #272 as described in that issue. In particular, it is intended to clarify the existing process without adding any substantive changes.
problem-solving: codesections++ created pull request #289:
Clarify Problem Solving process description in README
tbrowder vrurg: got a sec to talk about modf? 22:17
vrurg tbrowder: Not much. 22:18
But let's try. :)
tbrowder what do you think about having modf be a method only like base? i think one advantage is it will make it easier to implement 22:19
and more robust, too 22:20
maybe more robust 22:22
i've been approaching from the routine side first, but as you've seen, getting mired down in the subtle differences of number attributes 22:25
just a thought... 22:26
vrurg Not sure. I don't think I'm the right person to ask. I'll try too look into the PR, maybe something would ignite the light within...
tbrowder i think it is probaly best to have both to match other languages as well as fit the raku numerical library model better 22:28
vrurg I'd rather be worried about the latter ā€“ the established model dictates the rules. 22:29
tbrowder yes, you're right, and your comments on the roast tests help working in that direction. 22:31
vrurg Aside of this, I an implementation for native num. It also pushes towards a standalone sub.
* I see an implementation
tbrowder don't waste any time on the modf PR for now. but i will keep pushing my changes and, if/when all looks satisfactory, i can redo a new and clean PR. 22:34
gfldex tbrowder: having it method-only means you don't have to stick it into v6.e. Or you have the method in v6.d and put the sub in v6.e.
vrurg gfldex: I think it will fit nicely into 6.c too. 22:36
tbrowder hm, i didn't think of that. my previous changes to core were in 6.c i believe evan after 6.d
yes, there should be no conflicts, nothing being used of new 6.d features akaik 22:37
gfldex ppl already use Rakudo in production. If you stick the sub into anything but 6.e, you might screw somebody. We have the language version to avoid conflicts with existing code. 22:38
tbrowder its a new feature and shouldn't conflict
that's what roast checks, too 22:40
gfldex If you can come up with a `sub modf` somebody else can too. If that is defined already in CORE the compiler will not run the script or compile the module.
vrurg gfldex: How can a new math sub break anything? If there is a custom one with the same it'd just override the core version.
A case possible that where it was breaking before the code would be passing without an error and this could pose some risk. 22:42
tbrowder it's not in CORE unless there's another rakudo ripoff around
gfldex If it is defined in the script, then yes. If it is imported from a customm module it wont load that module.
tbrowder hm, is that true? i hadn't considered that 22:43
even if the external module is called with an :auth adverb? 22:45
gfldex It wont import a symbol that is already imported from elsewhere. That includes CORE.
tbrowder so i've just been lucky we don't have many users, huh? 22:47
ok, so should new features only be in the next version?
vrurg gfldex: You're mistaken. Try 'unit module foo; sub log(Str:D $msg) is export { say $msg };`
gfldex gist.github.com/74601dd9b68a27dc27...767dc099a3 22:55
results in
Cannot import symbol '&ord' from 'TestModule', because it already
exists in this lexical scope.
at /home/dex/projects/raku/tmp/import-fail/test.raku:3
------> use TestModuleā;
tbrowder why would a user use the EXPORT which not needed? 22:56
*is not 22:57
gfldex That is a simple example, there can be good reason to use sub EXPORT. And even if this is considered a mistake, we still have to take our userbase into account when we add new subs into the global namespace. 22:58
tbrowder i disagree. raku can be abused just like nqp, and that is accepted to be on the user's own risk 23:00
*at 23:01
gfldex I disagree the even compare the use of nqp in Raku code to using plain Raku code on the side of the user. 23:02
tbrowder i've always thought using EXPORT in raku was a holdover from perl. raku makes it so much easier without it. 23:05
i'm talking about the user side. 23:06
gfldex In some cases it's the only way out. see: gfldex.wordpress.com/2020/10/26/pl...olescence/
vrurg gfldex: Dunno what happens in your test, but `sub EXPORT { Map.new: '&log' => &log } ` added to my test broke nothing. Same with 'ord' 23:14
gfldex did you put sub EXPORT into a separate file? 23:15
vrurg gfldex: sure. 23:31
BTW, use of a hash in EXPORT is incorrect. Because, as a matter of fact, you export a Scalar containing &ord, not the sub symbol itself. 23:35
it has to be sub EXPORT { Map.new: '&ord' => &ord }
gfldex docs.raku.org/language/modules#ind...sub_EXPORT
vrurg Documentation lags behind. Yes, for years it was a de-facto standard until I hit a serious bug related to this. 23:37
gfldex Changing it to Map.new does indeed fix it. However, my argument still stands because of "for years it was a de-facto standard". 23:39
When returning anything but a Map or Hash Rakudo does complain with '&EXPORT sub did not return a Map'. A deprication warning (or at least some warning) on Hash seams reasonable. 23:41
23:43 cognominal left
vrurg Actually, I tried that EXPORT with hash and it work for me too. Rakudo v2021.06-27-geab780f38. 23:44
With regard to the warning, there was a discussion about it. Don't remember why, but it was decided not to warn. 23:45
I have filed an issue for docs: github.com/Raku/doc/issues/3910 23:46
gfldex I'm on HEAD now to, still got the error on %(). But it's to late in the day to worry about it. 23:53