🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
00:00 reportable6 left 00:02 reportable6 joined, sena_kun left 00:13 deoac joined, jgaz left 00:18 jpn left 00:41 freeside joined 00:44 deoac left 00:45 freeside left
rf Is raiph around? 00:51
01:12 frost joined
guifa_ tonyo: looks like I might have an issue again with uploading Intl::CLDR again but I'll be danged if I can remember what was causing the issue the last time 01:23
01:25 Manifest0 left 01:26 frost left, a1 joined, frost joined 01:27 freeside joined 01:28 a1 left 01:31 freeside left 01:32 pingu left 01:40 saint- joined 01:49 freeside joined 01:55 freeside left 01:58 freeside joined 02:03 freeside left 02:08 derpydoo joined
MasterDuke anybody here use rakudo on a windows 2022 machine? 02:25
02:25 frost left, cfa joined
cfa [Coke]: App::Uni is very neat. one suggestion: perhaps use $*PROGRAM-NAME.IO.basename rather than $*PROGRAM-NAME for the usage printout -- at least on this machine, the path to uni is very long 02:26
02:38 drakonis left 02:39 cfa left 02:44 jpn joined 02:47 razetime joined 02:49 jpn left 02:52 frost joined
tonyo guifa_: i'm about to go to sleep but is it possible you link me to the repo? 03:32
i can take a look at it in the morning 03:33
03:49 rf left 04:12 razetime left 04:53 freeside joined 05:02 [Coke]_ joined 05:04 [Coke] left 05:07 [Coke] joined, [Coke]_ left 05:28 razetime joined 06:00 reportable6 left, reportable6 joined 06:51 Sgeo left 07:19 jpn joined 07:24 jpn left 07:49 frost left 07:54 kaskal left 07:57 pingu joined
pingu got it working for those interested: m.youtube.com/watch?v=Cokf_UZGCeY&...e=youtu.be 07:58
07:59 kaskal joined 08:01 razetime left 08:23 razetime joined 08:27 jpn joined 08:33 jpn left 08:39 ispyhumanfly left 08:52 nort left 08:54 ispyhumanfly joined 08:58 Manifest0 joined 08:59 ispyhumanfly left 09:03 nort joined
leont Instead of $*PROGRAM-NAME.IO, one can just use $*PROGRAM 09:06
09:09 dakkar joined 09:11 ispyhumanfly joined 09:24 jpn joined 09:29 ispyhumanfly left, jpn left 09:49 dakkar left 09:53 jpn joined 09:56 ispyhumanfly joined 10:03 ispyhumanfly left
Geth raku.org: ash++ created pull request #178:
TRC 2023		 10:06
10:31 sena_kun joined 10:32 ispyhumanfly joined 10:46 freeside left 10:49 razetime left 10:53 ispyhumanfly left 11:02 pingu left 11:04 [Coke] left 11:07 [Coke] joined 11:12 frost joined 11:16 jpn left 11:19 kjp left
Geth raku.org: 219ac503d7 | (Andrew Shitov)++ (committed using GitHub Web editor) | source/index.html
TRC 2023 (#178)
 11:19
11:19 freeside joined
Geth raku.org: ash++ created pull request #179:
Oops, the title was not updated		 11:23
raku.org: 127266e35a | (Andrew Shitov)++ (committed using GitHub Web editor) | source/index.html
Oops, the title was not updated (#179)
 11:25
11:32 ispyhumanfly joined, jpn joined, kjp joined 11:51 tonyo left, tonyo joined 12:00 reportable6 left, freeside left, freeside joined 12:01 reportable6 joined 12:07 ab5tract left 12:19 ispyhumanfly left 12:20 ispyhumanfly joined 12:28 ispyhumanfly left 12:33 ispyhumanfly joined 12:38 ispyhumanfly left, ispyhumanfly joined 12:41 saint- left 12:51 ispyhumanfly left 12:53 jpn left 13:00 ispyhumanfly joined 13:04 freeside left 13:22 jpn joined 13:25 freeside joined 13:30 freeside left 13:38 jpn left 13:42 jpn joined 13:51 rf joined 13:55 thundergnat joined
thundergnat m: my @S = (1,), { (0, |@^l) »+« (|(@^last »*« @^l.keys), 0) } … *; my @b = @S.map: *.sum; .say for @b.head(15), @b[50 - 1]; 13:55
camelia Too few positionals passed; expected 2 arguments but got 1
in block <unit> at <tmp> line 1
thundergnat m: my @S = (1,), { (0, |$^l) »+« (|($^l »*« @^l.keys), 0) } … *; my @b = @S.map: *.sum; .say for @b.head(15), @b[50 - 1]; 13:56
camelia Too few positionals passed; expected 2 arguments but got 1
in block <unit> at <tmp> line 1
thundergnat m: my @S = (1,), { (0, |$^l) »+« (|($^l »*« $^l.keys), 0) } … *;  .say for @S.head(15); 13:57
camelia (1)
(0 1)
(0 1 1)
(0 1 3 1)
(0 1 7 6 1)
(0 1 15 25 10 1)
(0 1 31 90 65 15 1)
(0 1 63 301 350 140 21 1)
(0 1 127 966 1701 1050 266 28 1)
(0 1 255 3025 7770 6951 2646 462 36 1)
(0 1 511 9330 34105 42525 22827 5880 750 45 1)
(0 1 10…
thundergnat m: my @S = (1,), { (0, |$^l) »+« (|($^l »*« $^l.keys), 0) } … *; my @b = @S.map: *.sum; .say for @b.head(15); 13:58
camelia 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
thundergnat m: my @S = (1,), { (0, |@^l) »+« (|(@^l »*« @^l.keys), 0) } … *; my @b = @S.map: *.sum; .say for @b.head(15); 13:59
camelia 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
thundergnat m: my @S = (1,), { (0, |@^l) »+« (|(@^l »*« @^l.keys), 0) } … *; my @b = @S.map: {.sum}; .say for @b.head(15); 14:01
camelia 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
thundergnat m: my @S = (1,), { (0, |@^l) »+« (|(@^l »*« @^l.keys), 0) } … *; my @b = @S.map: {.sum}; .say for @S.head(15);
camelia (1)
(0 1)
(0 1 1)
(0 1 3 1)
(0 1 7 6 1)
(0 1 15 25 10 1)
(0 1 31 90 65 15 1)
(0 1 63 301 350 140 21 1)
(0 1 127 966 1701 1050 266 28 1)
(0 1 255 3025 7770 6951 2646 462 36 1)
(0 1 511 9330 34105 42525 22827 5880 750 45 1)
(0 1 10…		 14:02
thundergnat Hmm. Why isn't it summing the lists?
m: my @l = 0, {(^++$)} ... *; say @l.map(*.sum)[^10]; 14:05
camelia (0 0 1 3 6 10 15 21 28 36)
thundergnat that works. 14:06
14:08 freeside joined
thundergnat m: my @S = (1,), { (0, |@^l) »+« (|(@^l »*« @^l.keys), 0) } … *;  say @S.head(10); say @S.head(10).map: *.sum; 14:09
camelia ((1) (0 1) (0 1 1) (0 1 3 1) (0 1 7 6 1) (0 1 15 25 10 1) (0 1 31 90 65 15 1) (0 1 63 301 350 140 21 1) (0 1 127 966 1701 1050 266 28 1) (0 1 255 3025 7770 6951 2646 462 36 1))
(1 2 3 4 5 6 7 8 9 10)
thundergnat m: my @S = (1,), { (0, |@^l) »+« (|(@^l »*« @^l.keys), 0) } … *;  say @S.head(10); say @S.head(10).map: {sum |$_}; 14:10
camelia ((1) (0 1) (0 1 1) (0 1 3 1) (0 1 7 6 1) (0 1 15 25 10 1) (0 1 31 90 65 15 1) (0 1 63 301 350 140 21 1) (0 1 127 966 1701 1050 266 28 1) (0 1 255 3025 7770 6951 2646 462 36 1))
(1 1 2 5 15 52 203 877 4140 21147)
thundergnat m: my @S = (1,), { (0, |@^l) »+« (|(@^l »*« @^l.keys), 0) } … *;  say @S.head(10); say @S.head(10).map: {sum $_};
camelia ((1) (0 1) (0 1 1) (0 1 3 1) (0 1 7 6 1) (0 1 15 25 10 1) (0 1 31 90 65 15 1) (0 1 63 301 350 140 21 1) (0 1 127 966 1701 1050 266 28 1) (0 1 255 3025 7770 6951 2646 462 36 1))
(1 2 3 4 5 6 7 8 9 10)
thundergnat bisectable: my @S = (1,), { (0, |@^l) »+« (|(@^l »*« @^l.keys), 0) } … *;  say @S.head(10); say @S.head(10).map: *.sum; 14:11
bisectable6 thundergnat, Will bisect the whole range automagically because no endpoints were provided, hang tight
thundergnat, Output on all releases: gist.github.com/d3eeaeb5dc70fe75bf...34f7867888
thundergnat, Bisecting by output (old=2022.12 new=7ad82e9) because on both starting points the exit code is 0
thundergnat, bisect log: gist.github.com/1245502310c2d38f19...e5c5121d4d 14:12
thundergnat, (2023-02-13) github.com/rakudo/rakudo/commit/5c...9fcee57ad4
thundergnat, Output on all releases and bisected commits: gist.github.com/38249f59ad5f61de0f...a12207058e
14:12 freeside left
thundergnat Huh. That commit has broken code in the field. 14:13
lizmat meh 14:15
14:15 freeside joined
lizmat I guess we then need to ditch the [+] -> &sum optimization :-( 14:15
thundergnat: could you please make an issue, or reopen github.com/rakudo/rakudo/issues/5205 ? 14:17
thundergnat Sure. Preference? 14:18
lizmat new issue
thundergnat 👍
14:20 freeside left
Nemokosch is there some policy on freezing the main branch before releases, by the way? 14:26
thundergnat Issue submitted: github.com/rakudo/rakudo/issues/5209 14:37
14:40 razetime joined 14:44 vrurg_ is now known as vrurg 14:53 freeside joined 14:58 freeside left 15:00 freeside joined, cfa joined 15:04 thundergnat left 15:05 freeside left
cfa o/ 15:06
15:10 Sgeo joined 15:14 hythm joined
hythm I have a regex question that I created a test file for here: gist.github.com/hythm7/fa2d0cdbe85...5ab47d1202 the question is how can I fix the failing test (last one) without breaking other tests. 15:15
What I'm trying to do is I want to have support for an option that can be boolean or have value, for example if passed `test` this means `test => True`, but if I passed `test runtime` this should be `test => runtime` and the values like `runtime` are not specific words, should be able to pass anything. 15:26
lizmat isn't this really a question about MAIN dispatch ? 15:33
hythm Sure, but I want to parse @*ARGS with grammar, I dont want to use MAIN dispatch for this scenario 15:35
lizmat so, if I understand correctly, you want to run that grammar on @*ARGS,join(' ') ? 15:37
hythm yes, basically I run it like this `Grammar.parse( @*ARGS, :$actions ) 15:39
Its more of a regex probelm, the main issue I'm having is I cant figure out how to tell grammar to correctly parse the test case in this line gist.github.com/hythm7/fa2d0cdbe85...kutest-L64 15:43
15:50 freeside joined
tonyo hythm: raku.land/github:jnthn/Grammar::Debugger 15:51
^ helps immensely when debugging grammars 15:52
15:56 freeside left
rf Is there a nice way to restrict a IO::Path object to only find children 15:56
For example I don't want it to be possible to do $path.add('..');
hythm tonyo: Thanks, I do know why the grammar fails for the last test, I just dont know how to fix it 16:00
Nemokosch can you say why it fails, then? 😄 16:01
rf: so do you want to modify the behavior of IO::Path basically? 16:02
hythm because the token in this line gist.github.com/hythm7/fa2d0cdbe85...kutest-L23 , as I noted in the gist it can match the last test if I reversed the order
rf Nemokosch: If I have to I will 16:03
tellable6 rf, I'll pass your message to Nemokosch
tonyo m: say (".".IO.add("..").resolve.absolute.index(".".IO.absolute)//-1) == 0; say (".".IO.add("rf").resolve.absolute.index(".".IO.absolute)//-1) == 0 16:04
camelia False
True
tonyo likely a better way but quick and dirty
and i think there's an edge case for it if the path doesn't exist and resolve leaves in the `..` 16:05
m: say ("/hello-world".IO.add("..").resolve.absolute.index("/hello-world".IO.absolute)//-1) == 0
camelia True
tonyo m: say ("/hello-world".IO.add("..").resolve.absolute.index("/hello-world".IO.absolute)//-1) == 0 && "/hello-world".IO.add("..").resolve.e
camelia False
Nemokosch probably a mixin like that would help 16:08
hythm the issue is really due to token ''option-b' which can match 'b' only, or. can match 'b' and a value (after b). when pass 'b a' , should it parse it as two boolean options, option  'a' and option 'b', or should it parse it as option 'b' with value 'a' ## hope this makes sense :D 16:09
16:09 codesections joined 16:12 jgaz joined
Nemokosch my brain melts every time I see "rule" and "token" used mixed 16:12
by the way 16:14
don't you think the problem would rather be that 'val' is being evaluated as another option? 16:15
hythm yes thats a problem, it can be fixed by changing the definition order of `option-b` token, but again that will break some tests 16:18
Nemokosch frankly speaking, I don't know what these proto's are for, how they work. What you say implies that they have || semantics rather than | semantics 16:19
so my quick but sane advice would be to just ditch the proto's and list the choices in a | separated token 16:20
16:20 [Coke]_ joined
hythm ok trying that 16:21
16:23 [Coke] left
[Coke]_ cfa: done locally, will be in next release (but probably won't release with just this.) 16:26
16:27 [Coke]_ is now known as [Coke]
rf tonyo: thanks 16:32
16:34 freeside joined
hythm tried combinations of | and ||, but no luck still, created another gist here gist.github.com/hythm7/128bc02c190...f9b827f892 16:34
16:38 freeside left
hythm anyway I feel I'm trying to do something in regex that can not or should not be done, but I'll ask one more time in a few days later, in case someone more experienced in regex more than me like moritz can see the question and may be comment on it 16:41
Nemokosch I'm pretty sure this should be doable at least... 16:42
what is this .space actually? 16:44
hythm i'm sure it's doable if <val> token is a set of known words, the grammar will try to match <val> against these words. but when <val> can be anything really, then it can wrongly match another option 16:45
<.space> just \s and the dot means I'm not interesting of getting the matched value of it 16:46
interested in*
Nemokosch I only replaced <.space> to \s everywhere and the output got better immediately lol 16:47
the grammar is not specified enough, though, that's for sure 16:49
what tells you how "b a" would be interpreted?
it really could be either 16:50
hythm may be soemthing like when see <val> check if it matches another option (in this case 'a') if so fail and try to match as a new option 16:52
[Coke] in that case <val> can also be "not an existing option" 16:53
16:56 jpn left
hythm if that is the case and <val> is "not an existing option" then we now sure that <val> is just <val>, it's the ending part of <option-b> token, and should be parsed as such 16:57
17:00 freeside joined 17:05 freeside left
Nemokosch good idea 17:06
17:21 razetime left 17:23 freeside joined
how can one say "fail the match if it matches token X"? 17:27
cfa [Coke]: neat (did you see leont's message about using $*PROGRAM?) 17:28
Nemokosch all that I miss is proper access to token X inside <?{}>
17:28 freeside left
why are the tokens of the grammar in question not exposed, or if they are, how? 17:28
hythm not sure I understand the question, you can access the tokens with the $<token-name>? 17:32
[Coke] cfa; no, I just saw what I thought was your message? 17:34
cfa: ok, see it 17:35
Nemokosch those are the captures, no? 17:36
I meant the actual pattern
the "method"
[Coke] but it seems wrong.
ah, got it, var name also changed.
cfa++ leont++ 17:37
tonyo m: grammar XXX { rule TOP { ^ <-x>+ $ }; token x { "a" }; }; say XXX.parse("abcdef"); say XXX.parse("fff"); # nemokosch 17:40
camelia Nil
｢fff｣
Nemokosch so <- just works with a token? :jawdrop: 17:44
hm, wait. 17:45
how does this apply when token x is not this banal? 17:46
17:48 Guest8418 joined
gist.github.com/2colours/f2148c631...023d12c587 17:49
fails 3 tests
all tests with "b", except "b a command" 17:50
17:52 Guest8418 left
tonyo m: grammar XXX { rule TOP { ^ <-x>+ $ }; token x { "a" | "e" }; }; say XXX.parse("abcdef"); say XXX.parse("efff"); # nemokosch 17:53
camelia Nil
Nil
tonyo ... it just works, i'm not sure what you mean by not this banal
Nemokosch "b val command" really could have worked at least
"not this banal" - something that can't be immediately modeled with a character group, for starters 17:54
17:55 freeside joined
tbh it even makes sense that what I did doesn't work 17:55
it has no "length" 17:56
[Coke] lizmat: your list.sum fix fixes my one off script that was failing. 17:57
(worked in 2022.07, was failing inuntil just now0
17:59 freeside left 18:00 reportable6 left
tonyo doesn't all of regex boil down to matching character groups 18:00
what is an example of "not this banal" token set you want to negate? 18:01
Nemokosch check the gist out 18:02
lizmat [Coke]: well, I borked it in the first place, a few days ago :-)
18:03 reportable6 joined
Nemokosch the thing is, option a and option b could arguably be "alpha" and "bravo" or anything 18:06
and val also wouldn't be one character for sure
tonyo i'm not going to grok a 50+ line file for the sake of clarifying negating a token when the example works OK 18:11
Nemokosch well, that's exactly I did when hythm sent the original gist and spent an hour figuring how the grammar could be fixed 18:17
but have it your way
lizmat Nemokosch please stop being so confrontational 18:18
the fact that tonyo doesn't feel like spending time on something, should not be a reason for you to react this way
consider this a warning: a yellow card if you will 18:19
since you are on Discord, there will be no other option but to kick the Discord bot from the #raku channel
and that will also hinder people on both sides
so please: be more friendly and less confrontational 18:20
and don't reply by saying that "they" started it
18:21 ChanServ sets mode: +o lizmat
Nemokosch I just don't see your problem in the first place. It wasn't any less "confrontational" to basically drop the topic out loud, it wasn't even all that factual 18:25
"I don't feel like it" or "I don't have time for this" would just do, no? 18:26
18:27 discord-raku-bot was kicked by lizmat (Your behavior is not conducive to the desired environment.)), discord-raku-bot joined
It's really demoralizing that I put an hour into a topic someone else brought up and then the biggest problem still is that I mention it 18:28
18:28 discord-raku-bot was kicked by lizmat (Your behavior is not conducive to the desired environment.)), discord-raku-bot joined 18:30 Guest8418 joined 18:39 hythm left, ChanServ sets mode: -o lizmat 18:41 hythm joined
Zephyr hello, mod from the Discord side here, may I have some context? 19:31
if it's still relevant
lizmat Zephyr what can I say, Nemokosch keeps getting immediately confrontational and people started to complain about it to me in privmsgs 19:34
I already looked less at the #raku channel than before, because of these polemics 19:35
they bothered me, but that's ok: I have a thick skin, most of the time
problem is, I have no way of kicking Nemokosch other than by kicking the bot 19:36
and people cannot /ignore Nemokosch on this side, without /ignore ing the bot
Zephyr well, that's a bit concerning to say the least. I remember back in around November they were temporarily given the IRC-Readonly role which made them unable to talk in bridged channels for a while. in today's scenario though, may I have a specific example of where they were confrontational in that way? 19:38
lizmat thing is: if Nemokosch would be less about themselves and more about the project, they would be a true treasure for the project
discussion about the way Raku installs modules starts at irclogs.raku.org/raku/2023-02-15.h...20:00-0002 19:41
19:41 linkable6 left
lizmat then it starts getting off the rails at irclogs.raku.org/raku/2023-02-15.html#21:20 19:42
19:43 linkable6 joined
lizmat another example irclogs.raku.org/raku/2023-02-13.html#23:22 19:46
sadly the combination of the bot and the search engine makes it hard to look for exchanges with Nemokosch on the discord bot
Zephyr I guess moderating the bridge is quite a problem... I'm not sure what would be the reasonable course of action here. however, if kicking the bot becomes needed I think it'd be more reasonable to handle it on the Discord side through the IRC-Readonly or another restricted role which I can apply upon request 19:49
in which case though, I'm not sure about the expected duration 19:50
lizmat another example: irclogs.raku.org/raku/2023-02-07.html#12:47
Nemokosch no, that's not an "example"
lizmat well, I'd say I can only hope that Nemokosch will think about what just happened and .... 19:51
I was just writing that an Nemokosch decided that it was not an example
Nemokosch that's an example of something that bothers me a lot, if anything
and I have talked about it with you personally 19:52
lizmat Zephyr I suggest not seeing any of Nemokosch's messages on the #raku channel for 24 hours would be a good start
Zephyr alright, let me implement that right away
I apologize @Nemokosch, I'm not taking sides but in this case complying seems to be my job 19:53
lizmat Nemokosch: 20:38:40] <lizmat>thing is: if Nemokosch would be less about themselves and more about the project, they would be a true treasure for the project
tellable6 lizmat, I'll pass your message to Nemokosch
lizmat think about that
19:55 discord-raku-bot left, discord-raku-bot joined
Zephyr alright, I manually excluded their id from the bridge for now 19:55
lizmat Zephyr thanks!
19:58 Guest8418 left 20:00 NemokoschKiwi joined 20:01 NemokoschKiwi left 20:08 freeside joined
ugexe til windows 10 and 11 come with a curl.exe 20:10
20:12 freeside left
hythm FWIW, I did not think Nemokosch was confrontational in the conversation that resulted in kicking them from the channel, may be a little emotional but not confrontational. But English is not my first language, so I could have missed something. Anyway I just said what I thought. 20:14
lizmat hythm: if it had been the first time... 20:19
but it's not, and once "normal users" start saying that they are evading the #raku channel because the conversations are not fun anymore 20:20
and I will repeat again: [20:38:40] <lizmat> thing is: if Nemokosch would be less about themselves and more about the project, they would be a true treasure for the project 20:21
20:22 Xliff joined
hythm so we can do something about that and make #raku fun for everyone including Nemokosch, may be with being more understanding when conversations gets heated and only resort to kick from channel when all else fail 20:25
lizmat I'd be all for that! 20:26
to give a recent example: " It's really demoralizing that I put an hour into a topic someone else brought up and then the biggest problem still is that I mention it"
my point would be: if you spent an hour on that and you didn't learn anything from that, that would be a pity 20:27
but the fact that they put an hour in it, shouldn't even be mentioned: it's not a contest who gets to spend more time on Raku 20:28
we all spend the amount of time on Raku that we feel comfortable with
I just happen to have more time available than most, on account that I don't *have* to work for a living anymore 20:29
but as a relatively newcomer to Raku to claim in various instances that the way Raku does things, is just bad, and easily fixable 20:30
that shows: a. most likely a less than complete understanding of the problem space
b. a lack of life experience that would by which one knows that all of the best ideas fall apart when getting in contact with reality 20:31
a recent case in point: difference in behaviour between [+] and [*]
that behaviour existed that way for at least 5 years already 20:32
I tried to fix it, and other things broke
so it was needed to fix it in another way
was the first fix wrong? No, I don't think so 20:33
20:33 lucs joined
lizmat but there's code out there that depends on the old behaviour, and the new behaviour broke it 20:33
that's when a great fix hits reality 20:34
lizmat stops rambling
20:36 cfa left
hythm understands lizmat's points as well 20:38
21:03 derpydoo left 21:09 ab5tract joined 21:15 codesections left 21:19 Guest8418 joined
jdv whise ivan_linux in here? 21:20
*who is 21:21
.seen rf 21:26
tellable6 jdv, I saw rf 2023-02-16T16:32:24Z in #raku: <rf> tonyo: thanks
jdv .tell rf are you aware of github.com/CurtTilmes/raku-jsonsimd?
tellable6 jdv, I'll pass your message to rf
21:34 hythm left
rf jdv: Yeah I've seen it. 21:37
tellable6 2023-02-16T21:26:46Z #raku <jdv> rf are you aware of github.com/CurtTilmes/raku-jsonsimd?
21:48 ispyhumanfly left 21:50 frost left, codesections joined
rf That module makes it way more complicated than it needs to be imo, plus its deprecated. 21:51
21:51 jpn joined 21:53 ab5tract left
jdv does yours have advantages in general use? 22:06
rf Its not deprecated, but its not **that** fast yet. I wouldn't use it in prod until I figure out how to make it faster. RIght now its only slightly faster than JSON:Fast 22:07
That package is slower than JSON::Fast as well, so if you need speed my implementation is the best i've seen (mileage may vary)
jdv im confused. are you talking about ctilmes or yours? 22:08
iirc i used ctilmes in prod in the past
rf ctilmes is deprecated, I wouldn't use mine in prod sorry 22:09
jdv just curious overall. iirc the perf issue is crossing the lang barrier which isnt easily fixable so far
where do you see it being deprecated? news to me:) 22:10
rf Sub from-json (from GLOBAL) seen at:
-e, line 1
Please use JSON::Fast, JSON::Tiny or JSON::Pretty from modules.raku.org/ instead.
jdv huh, i dint see that but im on my "phone"... 22:14
22:14 pingu joined
rf Yeah, I think the only reason to use mine is you want the FASTEST (once again mileage may vary) solution 22:14
But the only feature I have right now is parsing, not really concerned with going the other way right now 22:15
22:15 ispyhumanfly joined
jdv ok 22:15
rf This weekend i'm gonna try to go even faster, I think I have an idea :) 22:16
jdv cool. i think you mean rakudo is spitting that warning out. that doesnt say anuthing about ctilmes. 22:17
ugexe m: from-json(q|{}|) 22:18
camelia ( no output )
ugexe that deprecation message is from rakudos internal form-json 22:19
22:19 ispyhumanfly left
rf Huh, I don't see that when I run json fast or json tiny 22:20
ugexe because they are exporting their own from-json
if you see that deprecation message its because you are using the internal rakudo from-json
so i suspect your benchmarks are incorrect 22:21
22:22 tg57 joined
jdv id be interested if and how yours and ctilmes differ wrt perf 22:22
rf That's weird because ctilmes says it exports from-json
jdv since based on skimming your reddit post yours is probably not a derivative work 22:23
ugexe are you using "use JSON::simd :subs;"?
rf Yeah
ugexe not "use JSON::simd;"
rf Gonna try it in REPL
jdv fun stuff! 22:24
rf Yeah its about 1% slower than JSON::Fast on my machine 22:27
ugexe but its outputting a deprecation message?
rf No, I was a goof
I wasn't importing it properly for the benchmark
jdv progress. woohoo. 22:28
ugexe so one thing is calling from-json with JSON::simd creates a new object each time
JSON::simd.new.parse($str)
22:28 sena_kun left
rf They're all within like ~1% of each other give or take, JSON-Simd, JSON::FAST and JSON::simd 22:28
I'll try that with the new 22:29
ugexe if you are doing a loop for parsing it you'd want to do the .new outside of the loop
jdv except the parse of simd is blazin. thats not the issue.
ugexe if you aren't using a loop it wont matter
22:29 Xliff left
ugexe raku -e 'use JSON::Fast; for 1..100000 { from-json(q|{ "foo" : 42 }|) }' 0.41s user 0.03s system 118% cpu 0.377 total 22:31
raku -e 'use JSON::simd :subs; for 1..100000 { from-json(q|{ "foo" : 42 }|) } 2.57s user 0.27s system 105% cpu 2.696 total
that seems... strange 22:32
rf nqp is REALLY fast 22:33
simd can depend on your machine as well 22:34
What is your chip?
ugexe m2
rf I think it's a little weird on ARM
22:34 jpn left
rf ugexe: lemire.me/blog/2020/12/13/arm-macb...benchmark/ 22:35
Parsing is a good bit faster on x86_64
around an extra gb a second
pastebin.com/BR0c6maV 22:38
Also, I think JSON::Fast does some sort of caching 22:41
Going to run the big benchmarks against all 3, report back in an hour or so. 22:42
23:01 ispyhumanfly joined 23:05 Geth left, RakuIRCLogger left 23:06 ispyhumanfly left, codesections left 23:17 codesections joined 23:20 freeside joined 23:24 freeside left 23:30 tg57 left 23:31 Guest8418 left 23:49 xinming left 23:51 xinming joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!