🦋 Welcome to Raku! raku.org/ | evalbot usage: 'p6: say 3;' or /msg camelia p6: ... | irclog: colabti.org/irclogger/irclogger_log/raku Set by ChanServ on 14 October 2019. |
|||
00:02
Altai-man_ joined
00:03
markoong left
00:05
sena_kun left
00:32
oddp left
00:54
hungryd11 joined
00:56
hungrydonkey left
01:05
epony left
01:19
molaf left
|
|||
Xliff | I want to build a regex from a string, is an EVAL the only way to go? | 01:28 | |
I guess a better way to describe what I want to do is replace 'from a string' with 'programatically' | 01:29 | ||
01:31
molaf joined
|
|||
guifa2 | Xliff: right now yes | 01:39 | |
But jnthn's Raku AST will have nodes for Regex | 01:40 | ||
Xliff | Oh, will it? Huzzah! \o/ | 01:41 | |
guifa2 | There may be some other ways to do it based on what you're exactly trying to piece together (see my Intl::Token::Number for instance) | 01:42 | |
Xliff | guifa: What branch is that on? Have you been playing with it? | ||
guifa2 | Xliff: I've not played with it yet, but looking forward to it eagerly because it will *greatly* simplify a lot of the stuff I'm doing | 01:43 | |
Xliff | Actually, been wanting to talk to you. | ||
Were you the one who was trying to work internationalization by mixing strings and Associative? | |||
Lookit.... repl.it/@Xliff/PointlessSecretHexagon#main.raku | |||
guifa2: Same. Here. | 01:44 | ||
Must. Find. Branch. | |||
guifa2 | Xliff: github.com/alabamenhu/Fluent/blob/...lasses.pm6 :-) | ||
see lines 5-13 ;-) | |||
01:45
epony joined
|
|||
Xliff | Huh. I've not seen that version of but() before... | 01:47 | |
Oh, that's VERY nice. Accomplishes the same thing? | |||
guifa2 | Yeah | ||
Method access is MUCH faster | |||
Xliff | Huh! | 01:48 | |
Thanks! :) | |||
guifa2 | (and always will be, because of how hashes work) | ||
But CLDR might add new stuff that I haven't handled yet, so the method access can't handle everything. So each object has a fallback hash | 01:49 | ||
If you call an attribute/method that doesn't exist, it gets passed to FALLBACK, which checks if it's in the hash | |||
If you use hash access, it checks if the method exists, else checks in the hash | |||
guifa2 is afk& (back in ~2 hrs) (there's actually a better way to do the StringyHash using parameterization that I want to show you now that I think about and I'll probably use) | 01:51 | ||
Xliff | Cool! | ||
I'll more than likely be around. Take care!~ | |||
02:03
sena_kun joined
02:05
Altai-man_ left
|
|||
[Coke] | star module list is here: github.com/rakudo/star/blob/master...odules.txt | 02:33 | |
looks like it doesn't have tags for 2020.05 release. | |||
02:40
dataangel joined
02:44
RaycatWhoDat joined
|
|||
RaycatWhoDat | Hi. Does anyone use D here? I know it's a bit weird to walk into the Raku channel for that question but I'm seeing some interesting parallels between two languages and was wondering if someone who had used both ssaw the same thing. | 02:45 | |
Pardon the typos and run-on sentence. | |||
rypervenche | RaycatWhoDat: You might need to wait a bit for that answer. A lot of the people who could answer that are likely asleep right now. | 02:51 | |
RaycatWhoDat | Thanks! No worries, I can come back. | 02:55 | |
02:56
OpenZen left
03:09
Xliff left
03:52
rindolf joined
03:54
HarmtH joined
03:57
rindolf left
03:58
rindolf joined
04:01
xinming left
04:02
xinming joined
04:03
Altai-man_ joined
04:05
sena_kun left
04:07
hungrydonkey joined,
hungryd11 left
|
|||
guifa2 | .tell Xliff how does this look for clean and simple? tio.run/##K0gtyjH7/78oPydVwSOxOKMy...psEu3@/wcA | 04:17 | |
tellable6 | guifa2, I'll pass your message to Xliff | ||
04:48
dolmen joined
05:15
xinming left,
xinming joined
05:17
aluaces joined,
bocaneri joined
05:32
xinming left
05:34
xinming joined
05:43
leah2 left
05:59
leah2 joined
06:01
reach_satori_ joined
06:02
satori__ left
06:04
aborazmeh joined,
aborazmeh left,
aborazmeh joined,
sena_kun joined,
root joined,
root is now known as Guest57659
06:05
Altai-man_ left,
poga left
06:07
Benett left,
mrsolo left
06:08
Benett joined,
mrsolo joined
06:11
discoD left
06:29
guifa2 left
06:36
mniip joined
06:38
wamba joined
06:45
aborazmeh left
06:52
hungrydonkey left,
hungrydonkey joined
|
|||
Geth | ecosystem: a75cbe7fb1 | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | META.list Bump up Grammar::Common and move it to ecosystem |
07:12 | |
07:21
dolmen_ joined
07:23
dolmen left
07:53
cognominal joined
07:54
wamba left
07:55
cognominal left
07:56
hungryd58 joined,
hungrydonkey left
08:02
Altai-man_ joined
|
|||
Kaiepi | m: for ^1024 { Nil for (1...100).map({ $_, $_ * 2 }).flat }; say now - $*INIT-INSTANT | 08:04 | |
camelia | 3.2652317 | ||
Kaiepi | m: for ^1024 { Nil for (1...100).map({ slip $_, $_ * 2 }) }; say now - $*INIT-INSTANT | ||
camelia | 4.29667762 | ||
08:05
sena_kun left
|
|||
Kaiepi | i never realized .flat is well optimized, i've been doing the latter | 08:06 | |
08:35
patrickb joined
|
|||
cpan-raku | New module released to CPAN! Game::Covid19 (0.0.4) by 03ELIZABETH | 08:44 | |
08:45
patrickb left
08:47
pecastro joined
08:49
jakar joined
|
|||
jakar | The version of the rakudo star distribution on site (rakudo.org/star) is stuck to the previous one (2020.01 instead of 2020.05) | 08:52 | |
08:52
rbt left,
rbt joined
08:53
jakar left
09:02
abraxxa joined
09:04
Sgeo left
09:07
abraxxa left
09:08
abraxxa joined
|
|||
lizmat | weekly: andrewshitov.com/2020/07/11/larry-...at-fosdem/ | 09:12 | |
notable6 | lizmat, Noted! (weekly) | ||
09:29
leont_ joined
09:37
ensamvarg left
09:38
ensamvarg joined
09:49
oddp joined
10:03
sena_kun joined
10:05
xinming left,
xinming joined
10:06
Altai-man_ left
10:12
dolmen_ left
10:14
aborazmeh joined,
aborazmeh left,
aborazmeh joined
10:22
dakkar joined
10:28
xinming left,
xinming joined
10:33
hungryd58 left
10:38
Tirifto joined
10:39
hungrydonkey joined
10:58
Black_Ribbon left
11:00
aborazmeh left
11:01
dolmen joined
11:02
markoong joined
11:12
raydiak joined
11:17
raydiak left,
Ekho left
11:32
raydiak joined
11:37
Ekho joined
11:55
aborazmeh joined,
aborazmeh left,
aborazmeh joined
12:00
vrurg left,
vrurg joined
12:03
Altai-man_ joined
12:05
sena_kun left,
vrurg left
12:16
holyghost joined
|
|||
holyghost | .tell Xliff, thanks for the quick response, there's more developer kits on the server now | 12:27 | |
tellable6 | holyghost, I'll pass your message to Xliff | ||
12:33
softmoth joined
12:34
vrurg joined
12:35
vrurg left
12:36
vrurg joined
|
|||
cpan-raku | New module released to CPAN! Text::ShellWords (0.1.0) by 03SOFTMOTH | 12:40 | |
softmoth | lizmat, I just added Text::ShellWords to CPAN; it's inspired by Perl's Text::ParseWords, but doesn't have redundant cruft (like old_shellwords() and line_parse()), so I don't know if it should have a CPAN5 tag or some other niceties. github.com/softmoth/raku-Text-ShellWords | ||
12:55
rbt left
12:56
rbt joined
13:15
lucasb joined
13:19
softmoth left
13:23
aborazmeh left
13:28
RaycatWhoDat left
13:33
holyghost left
13:56
xinming left
14:01
xinming joined
14:03
sena_kun joined
14:05
Altai-man_ left,
kensanata joined
14:36
dataangel left,
dataange` joined
14:40
kensanata left,
dolmen left,
felipe1 joined
|
|||
felipe1 | Hi guys | 14:40 | |
I'm having issues using DBIIsh | |||
does anybody else have experience with these issues? | 14:41 | ||
14:42
markong joined,
markoong left
14:44
dogbert17 left
14:50
felipe1 left
14:57
kensanata joined
14:58
OpenZen joined
|
|||
lizmat | .tell softmoth if it doesn't have the same name and an incomplete API, it probably should not have the CPAN5 tag | 15:03 | |
tellable6 | lizmat, I'll pass your message to softmoth | ||
15:12
dolmen joined
|
|||
rbt | @felipe1 If you made issue #195 I responded there. Otherwise, if you describe hte issue here I'm happy to help. | 15:30 | |
15:47
dakkar left
15:56
vike left
16:02
Altai-man_ joined
16:05
sena_kun left
16:15
dataange` is now known as dataangel
16:17
vike joined
16:23
guifa2 joined
16:31
dataangel left,
guifa2 left,
dataangel joined
16:37
guifa2 joined,
guifa2 left,
dolmen left,
guifa2 joined
16:45
RaycatWhoDat joined
|
|||
RaycatWhoDat | In any case, hello again. I asked a question yesterday and I think I caught the server during off-hours. I was wondering if anyone here used D and if so, have you seen any interesting parallels between the two languages? I asked the same question on the D forums but they seem to be in the "at least, I can read and understand D code" camp which is dismissive to say the least. | 16:48 | |
16:54
Sgeo joined
|
|||
cpan-raku | New module released to CPAN! Red (0.1.16) by 03FCO | 17:03 | |
ShimmerFairy | The closest I've come to D is obsessively keeping up with the newest additions to C++, so I don't have much to say unfortunately. | 17:05 | |
17:09
kensanata left
|
|||
oddp | RaycatWhoDat: do you have a specific use case in mind? What's your background? | 17:22 | |
I've been using dlang for quite a while now. | 17:23 | ||
17:35
cpan-raku left
|
|||
guifa2 | RaycatWhoDat: I don't use D, but looking over the dlang page, the one that jumps out at me the most is the integrated documentation language | 17:36 | |
17:36
cpan-raku joined,
cpan-raku left,
cpan-raku joined
|
|||
guifa2 | Their rationale is one, actually, I think we could probably bring up at some point with Raku: having a language-specified format means people are more likely to use it and use it in a more-standard way. | 17:37 | |
oddp | There are many similarities. Too many to list in here. That's why I'm asking about specific interests and use cases. | ||
But we could most certainly talk about some of the differences. | |||
ShimmerFairy | We do have an integrated documentation language, it's just been very neglected so far (I'm working on it right now actually.) | 17:43 | |
guifa2 | ShimmerFairy++ I've been working to add in a lot more integrated documentation in a few of my Intl::* modules. I figure having a few modules that fully use the format would be good for those who want to test other things with it. | 17:49 | |
ShimmerFairy | The worst part is that the people who originally worked out Pod never thought "hey, maybe we should spec how documentation turns into objects more than not at all". | 17:52 | |
guifa2 | ShimmerFairy: Exactly. My thinking on that was that with no spec now, a few people ought to try to start using it and say "the expectation is that this will be processed like X" to guide some of the development | 17:56 | |
Maybe I'm misguided on that, but it's what I'm doing now (seriously, happy to adjust if you think I should approach it differently to help out the core dev) | |||
ShimmerFairy | Yeah, at the moment I'm just writing up a "new" S26 that mainly works out how the Pod -> output format process works, but also throwing in a couple changes to Pod itself (no breaking changes too serious, and I don't get the final say anyway) | 17:58 | |
But I will say that making use of Pod is a good way to see where things are lacking, or to make other people see where things are lacking :) | 17:59 | ||
Grinnz | one thing that might be useful to keep in mind is that several usecases benefit from being able to render documentation without using the full interpreter which might run arbitrary code - documentation is data, and there was previously a problem where github cannot render raku pod because it needs to use the interpreter | ||
ShimmerFairy | Oh yeah, I really want to make sure that something like haskell's pandoc could implement as much Pod as it can. Some aspects inevitably require Raku or a suitable substitute mechanism for your specific program (custom blocks and formatting codes, for example), but still. | 18:00 | |
18:03
hungrydonkey left,
sena_kun joined
|
|||
ShimmerFairy | Like I'm really hoping people will agree with getting rid of cases of A<> that just run code (e.g. The A<FOOCLASS.name> class is perfect for your needs), as an example. | 18:03 | |
18:04
molaf left
|
|||
guifa2 | Wait, A<> is an option? Definitely not documented haha | 18:04 | |
18:05
Altai-man_ left
|
|||
ShimmerFairy | guifa2: Maybe not on docs.raku.org, but A<> (at least theoretically) lets you insert some text defined with an =alias directive. | 18:07 | |
guifa2 | I would honestly much rather an option to say "The O<Foo::Class> is perfect for …" and then in the formated documented, the O<Foo::Class> is made as a link/hover/whatevs to the documentation for that class | ||
(or whatever other code object it points to) | |||
ShimmerFairy | Usually =alias just has text assigned to a name, e.g. =alias FOO bar ... A<FOO> would insert "bar". There's supposed to be a version of =alias that can attach a declarator (like a class definition) to a name, and the you use method calls inside A<> on the alias name to insert text (yuck!) | 18:08 | |
guifa2 | All of my classes and attributes now are getting declarator pod, so that would make for a pretty sweet/tight integration | ||
ShimmerFairy | Well, O<> is definitely free for future standardization :) | ||
guifa2 looked up the formatting codes just to be sure before suggesting it ha | 18:09 | ||
ShimmerFairy | And of course the old S26 never bothered explaining how arbitrary the code executed in A<> can be, which makes it all a lot worse. | 18:10 | |
And btw I want to bring back Perl's F<> for marking off filenames, since I personally believe that's a useful bit of semantics not fully covered by the other formatting codes. | 18:11 | ||
guifa2 | Ooh, that would be nice for my documentation, actually | 18:14 | |
18:21
oneeggeach joined,
oneeggeach left
|
|||
ShimmerFairy | btw, O<> could somewhat easily be covered with L<>, perhaps with a separate scheme (e.g. L<obj:> could search for content exactly like L<doc:> but for code objects) | 18:25 | |
leont_ wanted a Pod::Usage, but back then it seemed I couldn't get to another package's pod variables | 18:32 | ||
(may have been mistaken, didn't dig very deep) | |||
ShimmerFairy | I'd like it if you could at least do P<doc:Other::Module#reference> to insert Pod blocks from other modules into your own document. | 18:34 | |
18:36
vike left
|
|||
guifa2 | ShimmerFairy: using L<obj:> wouldn't be bad either, but there it's forcing the Link, whereas O you could leave it to the render to show a link, use a different font, or maybe in an HTML rendering, provide a quick hover tip, etc. | 18:40 | |
ShimmerFairy | That's fair, I thought you wanted it to always jump you to the documentation (with hover text stuff being optional extra goodies a renderer could throw in if desired). | 18:41 | |
But whatever happens, it would be nice if declarator blocks were better integrated and we had some kind of Doxygen-esque API documentation, since right now they're just this weird dangly bit attached to the Pod standard. | 18:45 | ||
18:46
wamba joined
18:58
rindolf left
19:05
rindolf joined
19:07
__jrjsmrtn__ left
|
|||
codesections | "they're just this weird dangly bit attached to the Pod standard." They're helpful for people who spend more time in the REPL, because they populate the `.WHY` method | 19:10 | |
19:10
__jrjsmrtn__ joined,
rbt left
19:11
rbt joined
|
|||
RaycatWhoDat | Sorry, just caught up. oddp: I was actually evaluating the two of them for system administration and data munging purposes. There was a set of text documents that I needed to build a CSV for and I instinctively reached for Raku. | 19:12 | |
When I rewrote the script in D, that's when I saw the similarities and got interested in the use cases. | 19:13 | ||
19:14
rypervenche left
|
|||
RaycatWhoDat | What do you use D for? And when do you reach for it over Raku and vice versa? | 19:15 | |
guifa2 | codesections: I think what ShimmerFairy means is that the declarator pod were traditionally just a string, nothing more. Whereas all other pod was an actual podblock that could be parsed | ||
So if you use I<foo>, that would show up literally in the string | 19:16 | ||
19:17
rypervenche joined
|
|||
ShimmerFairy | Yeah, it's a very useful thing, but why it (in its current form at least) is considered a part of Pod is a complete mystery. | 19:17 | |
19:17
softmoth joined
|
|||
guifa2 | codesections: here's an example of what I mean: tio.run/##K0gtyjH7/9@2ID9FITg/N1XB...TYmqv2/38A | 19:17 | |
I think it was tbrowder that did some improvements in handling of multiline declarator pod, with the goal of eventually supporting full pod syntax | 19:21 | ||
softmoth | ShimmerFairy++ thanks for your continuing focus on it | 19:22 | |
tellable6 | 2020-07-11T15:03:40Z #raku <lizmat> softmoth if it doesn't have the same name and an incomplete API, it probably should not have the CPAN5 tag | ||
19:22
vike joined
|
|||
oddp | RaycatWhoDat: okay, nothing where there startup time, higher mem usage and significantly lower performance really matters. So stick with raku then, not much to gain from dlang in that regard. Although, there are some nice goodies in dlang for file processing. slurp, for example, works nicely with uniform text files: dlang.org/phobos/std_file.html#slurp | 19:28 | |
Dlang is one of my main general purpose languages; raku is something I picked up for the perl weekly challenges and advent of code to compare it against both d and ruby. I have no experience building anything major with raku. | |||
But I've asked the same another dlang user that was in here not so long ago: | |||
<c*>I’d probably prefer D over Raku for larger systems both because of static typing and performance. | 19:30 | ||
<c*>Raku is nicer for text processing because of its regexes. | |||
<c*>[...] | |||
<c*>Both D and Raku have excellent metaprogramming capabilities. | |||
<c*>I often refer to D as “the Perl of systems programming languages” because of this. | |||
RaycatWhoDat | Ooh, that's very interesting. | ||
oddp | There are lot of similarities: | 19:31 | |
ranges vs iterators; different names, lot of overlap otheriwse | |||
.parallel vs .hyper/race | |||
thread-local storage + message passing + sync + signals and slots vs supplies, channels, react | |||
dub vs zef | |||
auto + generics vs duck typing | |||
inline unittesting vs test module | 19:32 | ||
autodecoding vs unicode handling | |||
spawnShell vs shell | |||
contracts vs where signatures | |||
range.recurrence/sequence vs sequence operator | |||
getopt vs main signatures | |||
scope {failure,exit,success} and CTFE vs phasers | |||
codesections | :RaycatWhoDat I haven't used D, but I came (am coming?) to Raku from Rust and can relate to the idea of surprising similarities (including many that :oddp is listing right now!) | ||
oddp | c ffi is also similar, although dlang has experimental work going on for c and cpp header inclusion. | 19:33 | |
Now on to the differences: | |||
ShimmerFairy | For me, if it's not Raku then it's C++ (I'm kinda in love with how big and perplexing C++ is, so I'm unlikely to ever give it up). | ||
oddp | dlang has ... function annotations that are enforced by the compiler like nothrow, nogc and pure | 19:34 | |
true immutability all the way down | |||
solid gc story where you can restrict allocations | |||
fewer suprising features; a single mismatch doesn't result in some strange runtime difference | 19:35 | ||
perf is 10x to 1000x faster atm; and that includes compilation | |||
ranges (dlang's iterators) are often times overhead-free; similar perf as handwritten c++ code | 19:36 | ||
compile-time function evaluation, that can be enforced with enum/const; allowing computation at compile-time that is then backed into the binary. | 19:37 | ||
UFCS instead of methods and functions. | |||
meta programming instead of runtime dispatching: traits/introspection, static if/foreach | 19:38 | ||
mixins, but no ast macros | |||
sena_kun | " compile-time function evaluation, that can be enforced with enum/const; allowing computation at compile-time that is then backed into the binary." <- is it what allowed in Raku or? Because it is. | ||
oddp | spec isn't fully tested as in raku, sucks. | ||
dlang doesn't have these goodies here: | |||
no string interpolation | |||
no custom term expressions | 19:39 | ||
no meta operators | |||
no language dialects that allow compatibility breaking changes. | |||
no prefix and suffix expressions/statements: if, unless, gather, once, ... | |||
no ada-like subtyping; only contract invariants | 19:40 | ||
no exact math | |||
no implicit conversion between strings/ints | |||
no autovivification | |||
no ruby-like smart matching | |||
nothing like MOP, no callsame, nextsame, etc. | |||
NO GRAMMARS. :( | 19:41 | ||
RaycatWhoDat | Mm. Yeah, that's a big hit. | ||
codesections | :oddp You said "nothing where [Raku's slower] startup time … really matters". Do you think that slower startup time is a characteristic of the language (e.g, because of how much the VM is doing)? Or just a "for now" thing because it hasn't been optimized yet? | 19:42 | |
oddp | Peeps in here are working hard on perf. I ran my advent of code stuff, some of which are bruteforce solutions, against different versions; each and every release brought ton of improvements. | 19:43 | |
codesections | Raku is *so* nice for writing simple CLIs. But the current startup time is really painful for apps that are intended to be used frequently & interactively | ||
oddp | But most stuff is still slower than jitted ruby. D is miles of at this point. But I guess it will get better over time. | ||
ShimmerFairy | Nobody should learn Raku because you'll never want to parse text in any other language ever again. | 19:44 | |
codesections | Yeah, I know that perf in general has gotten a lot better, and I have some sense of how much headroom for improvement there is (or isn't). But I'm less sure about startup time in particular | ||
19:46
patrickb joined
|
|||
RaycatWhoDat | That's kinda where my head's at. The day the performance increase hits for Raku, I'll be dancing in the streets. | 19:47 | |
re: parsing text: There's another Lisp-Perl-esque combo called TXR. Anyone heard of it? | 19:48 | ||
codesections | :ShimmerFairy That's not a bad slogan for the language! »ö« | ||
19:50
kensanata joined
|
|||
RaycatWhoDat | Also, thank you, oddp, for the comprehensive answer. Does this server have logs so I can capture all of that? | 19:50 | |
wait | |||
I'm dumb | |||
I'm in Emacs, lol | |||
19:52
RaycatWhoDat left,
RaycatWhoDat joined
|
|||
RaycatWhoDat | TIL M-x write-file is not the best way to save an IRC log since it changes the buffer modes and detachs you from ERC. | 19:53 | |
codesections | ha. How do you like ERC, by the way? I spend most of my time in Emacs but, for whatever reason, still use WeeChat for IRC | 19:54 | |
RaycatWhoDat | I'm still a baby when it comes to all things IRC, so I couldn't give you specifics. But, for connecting to a server, joining a channel, and chatting over longer periods of time, it works very well. | 19:55 | |
Just remember that closing a channel buffer will /leave you | |||
codesections | Good to know. I should probably try it out next time I feel like futzing with my setup | 19:57 | |
moritz | re logs, check the /topic | 19:58 | |
oddp | RaycatWhoDat: regarding startup time in d: #!/usr/bin/env rdmd is pretty nice. Compiles the file whenever it deteced file changes, otherwise uses the cached binary. | 19:59 | |
Also, take the above with a grain of salt. As said, I'm a raku noob myself, some of the stuff listed might not be true. | |||
RaycatWhoDat | Gotcha. Would you be opposed to me posting the conversation on the D forums to get people talking? | 20:02 | |
oddp | Furthermore, that's by no means an exhaustive listing, just stuff I could think of off the top of my head. | ||
RaycatWhoDat | I have a thread in there that has 0 replies about this because people are weird, I suppose. | ||
20:03
Altai-man_ joined
|
|||
oddp | It's the same whenever I bring up nim. Even more similar to dlang since it matches it performance-wise. | 20:04 | |
20:05
sena_kun left
|
|||
guifa2 | codesections: startup can be a bit slow particularly compared to perl or python2 (but about the same as perl+OO package like moose), but it's in the same realm nowadays as Ruby or Python 3 (Python 2 : Python 3 startup times are actually fairly similar to Perl : Raku times). Java and Scala are the worst offenders | 20:08 | |
RaycatWhoDat | That's cool, oddp. I was looking at that language as well | 20:12 | |
oddp | guifa2: not quite: | 20:15 | |
~$ timev raku -e '' | |||
0.11 s, 77892 kb | |||
~$ timev perl -e '' | |||
0.00 s, 5248 kb | |||
~$ timev ruby -e '' | |||
0.06 s, 21944 kb | |||
~$ timev python -c '' | |||
0.01 s, 7248 kb | |||
That's python 3.8 | |||
20:16
patrickb left
|
|||
guifa2 | oddp: hrm, interesting. I was going by stats I found online where someone compared a bunch of languages, and another where someone compared Raku and Ruby (Raku was between 1-2x of Ruby in those tests) | 20:17 | |
codesections | I recently did some profiling on my PC, and my findings were more in line with what :oddp found than what :guifa2 had read. | 20:27 | |
I got 120 ms for Raku 2020.06, 31 ms for Ruby 2.7.0, and 5.86 ms for Python 3.8.2 | 20:28 | ||
(I also measured startup time for a dozen compiled languages and ~30 interpreted ones; I'm happy to share what I got for others if anyone's curious) | 20:30 | ||
20:30
rindolf left
|
|||
oddp | Is janet still fast? :) | 20:31 | |
codesections | You know, I didn't test it — but I really should have. I forgot about Janet. I'll run that test now :) | 20:33 | |
ShimmerFairy | py2: 0.17 (w/o first: 0.06) ruby2.7: 0.338 (w/o first: 0.345) py3: 0.138 (w/o first: 0.115) rakudo-m: 1.028 (w/o first: 0.68) | 20:34 | |
5 trials each, "w/o first" ignores the first time in case it's longer because of extra loading. | 20:35 | ||
guifa2 | I wonder if something happened between P 3.7 and P 3.8? A lot of the startup time complaints I'm reading now ~2018 talk about how slow 3.7 is much slower than 2, with lots of ideas on how to speed it up. | 20:36 | |
I don't use python though so don't follow it much | |||
ShimmerFairy | My python version is specifically 3.7, should've been more precise (also I'm busy system updating, which on an old computer running gentoo will eat into resources) | 20:37 | |
20:44
patrickb joined
21:02
abraxxa left
21:04
abraxxa joined
21:05
aborazmeh joined,
aborazmeh left,
aborazmeh joined
21:07
Benett left,
Benett joined
|
|||
codesections | :oddp Yep, Janet is still fast: 0.96 ms (about the same speed as D or TCL; slower than Dash/Lua/Perl; much faster than Python/Ruby/JS) | 21:10 | |
21:11
dolmen joined
|
|||
codesections | (And, really, I probably shouldn't have put Python (~6ms) in the same grouping and JavaScript (~26ms) and Ruby (~31ms) | 21:11 | |
) | |||
oddp | Sweet, thanks for that! | 21:20 | |
21:32
hungrydonkey joined
21:40
wamba left
22:00
mmm joined
22:02
mmm left
22:04
sena_kun joined,
kensanata left
22:05
Altai-man_ left
|
|||
tbrowder | guifa2: i'm glad ShimmerFairy is back in action, esp. for pod improvements. i'm nearly finished (fingers crossed) with a pr for choosing a rakudo option to maintain author formatting in decl blocks. i got delayed due to life and the us fed tax system, but i hope i can start work again soon. because of problems i was having with trailing decls, it may be just for leading decls only. | 22:39 | |
22:47
patrickb left
|
|||
guifa2 | tbrowder: are you just maintaining things as a string but with newlines, or will the declarators actually become Pod objects? | 22:48 | |
22:52
dolmen left
|
|||
tbrowder | no, they'll just be strings. and that was Damian's intent in S26 as you can see in the doc added to the rakudo repo in the docs subdir. | 22:56 | |
of course that string could be in pod format if the author wants to. | 22:57 | ||
22:58
aborazmeh left
|
|||
ShimmerFairy | My updates to S26 would either A) change that so they become real Pod blocks, or B) stop acting like they count as Pod since they're very very much divorced from the anything Pod-like. | 23:04 | |
tbrowder: thanks for pointing out the S26 notes btw, the config option stuff reflects what I was thinking (though I've so far been leaning towards a more coercive handling than a strict one) | 23:08 | ||
23:10
hvxgr joined
|
|||
tbrowder | yr welcome, glad you're back! | 23:10 | |
23:14
aborazmeh joined,
aborazmeh left,
aborazmeh joined,
pecastro left
23:18
reach_satori_ left,
reach_satori_ joined
|
|||
ShimmerFairy | tbrowder: also, Damian didn't actually say declarator blocks aren't parsed as Pod in that email, nor is that implied in the example script. I double-checked because I just spotted an example in S26 of a declarator block with a Z<> in it. | 23:20 | |
tbrowder | hm, ok, but it sure seen | 23:22 | |
seems to be implied. and the inclusion of the Z<> doesn't conflict with that. | 23:23 | ||
i'll have to check with my lawyer son ;-) | |||
ShimmerFairy | I think it's reasonable to say that .WHY gives you the literal source text (e.g. showing you the Z<>), but the theoretical rendering of declarator blocks by a Pod renderer would treat it as Pod text. | 23:26 | |
tbrowder | no disagreement there. but the author is not constrained to that by spec | 23:29 | |
lizmat was willing to agree that spec was wrong on decls, but i'm not sure she would support saying it should be pod. | 23:31 | ||
ShimmerFairy | Considering it was made part of S26, I think making declarator blocks contain Pod is not a controversial conclusion :) | 23:32 | |
(it woulda been chucked in S02 if it was really meant to be plaintext, methinks) | |||
jnthn | Personally, I'd quite like to be able to use formatting codes in declarator blocks and have them rendered, though I didn't think through any consequences/details of that. :) | 23:34 | |
ShimmerFairy | fwiw I've been running on the assumption that declarators hold Pod that some part of rakudo (theoretically) parses for years. | 23:36 | |
23:46
oddp left
23:52
dogbert17 joined
|