|
01:33
_________ left
01:35
_________ joined
01:46
hulk joined
01:47
kylese left
02:15
hulk left,
kylese joined
03:53
atcroft joined
05:39
Sgeo left
06:06
belluzj joined
07:21
belluzj left
07:47
acidsys left
08:07
acidsys joined
08:14
abraxxa joined
08:51
dustinm` left
09:10
dustinm` joined
|
|||
| Voldenet | it might not be intended, but since it's a regular sub, there's no reason why it shouldn't work | 10:44 | |
| m: sub prefix:<§>($a, $b) { say $a, $b }; 5 ==> prefix:<§>(2) # it's as good as this | |||
| camelia | 25 | ||
| Voldenet | I can kinda imagine it not working in rakuast, like it doesn't work in rakupp for instance | 11:00 | |
| lizmat | m: Q|sub prefix:<§>($a, $b) { say $a, $b }; 5 ==> prefix:<§>(2)|.AST.EVAL | ||
| camelia | 25 | ||
| lizmat | not sure why that wouldn't work in RakuAST ? | 11:01 | |
| does rakupp allow creation of custom prefixes? | 11:02 | ||
|
11:08
belluzj joined
11:26
abraxxa left
11:32
belluzj left
12:16
MasterDuke joined
12:23
MasterDuke left
14:17
belluzj joined
|
|||
| Voldenet | yes it does, but it's not supported everywhere | 14:41 | |
| rakupp is cutting many corners in order to be fast itseems | |||
|
14:44
belluzj left
|
|||
| disbot | <antononcube> I don't think Rakupp is cutting corners intentionally, it is more of "side effect" or "byproduct" of its development process. | 14:46 | |
| Voldenet | also true, doubt introducing this syntax would make it significantly slower anyway | 14:48 | |
| disbot | <antononcube> For example, I submitted issues for certain missing functionalities and they appeared after a week or so. | ||
| <antononcube> Rakupp is still slower on algorithms / packages I am mostly interested in. | 14:49 | ||
| Voldenet | Well, for a lot of my use cases runtime actually is slower most often | 14:54 | |
| but for a lot of scripts that are short anyway, it's just quicker to complete | 14:55 | ||
| because of 150ms startup time… | |||
| disbot | <antononcube> This is one of the reasons I used Python in certain "production level" recommender systems few years ago. Python the did not have the fastest sparse matrix algebra (still, very fast, though) but since it can start and re-hydrate objects so quickly (say, 70 times faster that Wolfram Language and 20 times faster than R) it was simply a superior solution. | 14:59 | |
| <antononcube> Here is a screenshot of a Rakudo-vs-Rakupp comparison "presentation slide" from the Raku study group meeting last week: | 15:03 | ||
| <antononcube> cdn.discordapp.com/attachments/633...98aa6& | |||
|
15:16
belluzj joined,
belluzj left
15:40
human-blip left
15:42
human-blip joined
|
|||
| Voldenet | because of that tradeoff people don't like rust so much | 16:40 | |
| compilation times can be severe | |||
|
20:48
Sgeo joined
22:48
Pixi` joined
22:51
Pixi left
22:53
Pixi` left
23:05
Pixi joined
23:12
DemandDystopia joined
23:14
DemandDystopia9 joined
23:15
DemandDystopia9 left,
DemandDystopia left,
DemandDystopia joined
|
|||
| DemandDystopia | Hm, I checked some more feedop stuff and it predictably works for type and position (incl terms). It working for infixes would probably be interesting if there wasn't list associativity to do the same thing but more flexible | 23:38 | |
| m: sub infix:<§> { "⟦$^a $^b $^c⟧"}; say (1 § 2 <== 3 § 4 <== 5); | |||
| camelia | ⟦1 2 ⟦3 4 5⟧⟧ | ||
| DemandDystopia | though for postcircumfix it seems like it takes raku quite a lot longer than the other things? At least for the online compilers like glot & stuff even a normal one seems slower & this like it makes it worse, is that a known thing? | 23:39 | |
| m: sub postcircumfix:<⟪ ⟫> {"⟪$^a $^b⟫"}; say (6⟪7⟫) | |||
| camelia | ⟪6 7⟫ | ||
| DemandDystopia | oh, wrong paste | 23:40 | |
| m: sub postcircumfix:<⟪ ⟫> {"⟪$^a $^b $^c⟫"}; say (6⟪7⟫ <== 8) | |||
| camelia | ⟪6 7 8⟫ | ||
|
23:42
DemandDystopia left
|
|||
