|
š¦ 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:50 | |
|
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. |
12:36 | |
| 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. |
12:52 | ||
|
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. |
18:59 | |
| 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. |
21:56 | |
| problem-solving: codesections++ created pull request #289: Clarify Problem Solving process description in README |
21:57 | ||
| 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 | ||
| afaik | |||
| 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 | |