🦋 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.
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
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 ;-)
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!~
[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.
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
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
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
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
Kaiepi i never realized .flat is well optimized, i've been doing the latter 08:06
cpan-raku New module released to CPAN! Game::Covid19 (0.0.4) by 03ELIZABETH 08:44
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
lizmat weekly: andrewshitov.com/2020/07/11/larry-...at-fosdem/ 09:12
notable6 lizmat, Noted! (weekly)
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
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
felipe1 Hi guys 14:40
I'm having issues using DBIIsh
does anybody else have experience with these issues? 14:41
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
rbt @felipe1 If you made issue #195 I responded there. Otherwise, if you describe hte issue here I'm happy to help. 15:30
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
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
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
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
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
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
guifa2 Wait, A<> is an option? Definitely not documented haha 18:04
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
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
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
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
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
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
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
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
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
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! »ö«
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
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.
oddp It's the same whenever I bring up nim. Even more similar to dlang since it matches it performance-wise. 20:04
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
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
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
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
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
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
guifa2 tbrowder: are you just maintaining things as a string but with newlines, or will the declarators actually become Pod objects? 22:48
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
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
tbrowder yr welcome, glad you're back! 23:10
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!