🦋 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.
AlexDaniel jmerelo: if I keep noticing that I'm still browsing docs.PERL6.org and there's no redirect or even indication that I'm on the wrong domain I'm gonna start a riot. 01:10
tellable6 AlexDaniel, I'll pass your message to jmerelo 01:11
AlexDaniel rba: by any chance can we start redirecting? Can you remind me why didn't we start doing it right away? 01:11
Kaiepi releasable6, status 02:42
releasable6 Kaiepi, Next release will happen when it's ready. 5 blockers. 166 out of 336 commits logged (⚠ 3 warnings)
Kaiepi, Details: gist.github.com/7956ece1e254fbdd11...8ebc38b59b
Geth whateverable: b7e2a61920 | (Aleks-Daniel Jakimenko-Aleksejev)++ | META6.json
Bump version
03:34
moritz Good morning everybody 06:32
if you want news.perlfoundation.org/post/gp_rakuast to get approved, a supportive comment on that blog post might help convince the grant committee 06:33
and conversely, if you think it's a bad idea, also let us know in the comments!
El_Che hi, almost-neutral-moritz 08:12
moritz hi El_Che :D 09:26
I'm biased, and I admit it
El_Che pretty much everyone here is a jnthn fanboi, including me :) 09:27
I'm finish watching the talk before commenting (having kids at home that need school guidance is a lot of work, who would have thoough ;). 09:29
so far, the talk was very interesting
altough on a layer well below where I work :) 09:30
it's interesting to know how it all works
El_Che for whoever add the combinations array method: thanks! It save me a lot of loops with questionable logic. It's really great. 10:02
El_Che In case someone tested my SuperMain module: I just fixed those pesky boolean named parameters :) 10:58
lizmat drops a pin 13:02
raschip jnthn: I have a question about your RakuAST work. Would it be correct to say it's not really an **abstract** syntax tree if this work goes forward? It would be a concrete syntax tree, wouldn't it? Since I think to be useful it would have to reflect the actual program... 13:06
moritz to me, it sounds like an abstract syntax tree 13:11
a concrete syntax tree is more like the match object at the end of the parsing stage
jnthn raschip: A concrete syntax tree would always model stuff like whitespace, comments, etc. as well as other details that don't really matter (for example, 100_000 and 100000 would have the same representation in RakuAST). 13:12
moritz at least, going by the answers in stackoverflow.com/questions/188885...syntax-tre
jnthn I think there should be a way to retain the other stuff too (although the default will be to discard it) 13:13
Maybe it'll just be realized by exposing the match tree, and RakuAST is attached via. .ast :) 13:14
otoh, that *also* discards whitespce and comments by default. 13:15
raschip Right, it would be a not-so-abstract tree. Although Raku already attaches comments to the tree, since it's possible to retrieve them, the part about not representing actual precedence parsing still applies. Thanks jnthn and moritz. 13:18
Would it be correct to say that the CST is what's produced by Perl6::Parser, then? 13:21
jnthn It attaches doc comments, but not the rest. 13:22
Yes, I'd say the Match tree counts as a CST
AlexDaniel [Coke]: ummm I'm unable to leave a comment on the RakuAST proposal 14:41
[Coke]: now it requires me to login, so I'm trying to make an account and I can't 14:42
it says that the *name* is already in use, so I can't create a new account
but I don't think I ever had one
also, isn't it weird that it considers names to be unique? 14:43
[Coke] If you'd like, you can PM me the comment and I'll add it, attributing to you, while we try to get your account set.
raschip Yes, that is weird.
[Coke] Yup, sounds weird.
[Coke] AlexDaniel: github.com/RapidApp/tpf-blog-live/issues - please open a ticket here about issues with the site. 14:45
(issues that are not content related, like this one.)
Please feel free to tag me in the ticket (@coke) 14:46
ryn1x Since a Channel acts like a queue and is non blocking on to write, this implies some sort of buffered channel implementation... does the underlying data structure have a capacity or buffer size? Or can it grow dynamically and indefinitely? I am wondering if a thread on the receiving end crashed what will happen in the worst case, given another 14:48
thread keeps putting messages onto the channel that never get read.
moritz I'm pretty sure it can grow dynamically, and gobble up all your RAM 14:50
raschip They work like an Array, which doesn't have a limited size by default in Raku.
AlexDaniel [Coke]: github.com/RapidApp/tpf-blog-live/issues/14 14:56
ryn1x: re Channel: great questions, can you file a ticket somewhere? Raku/doc maybe? 14:58
tellable6 AlexDaniel, I'll pass your message to ryn1x
ryn1x ok thanks 14:58
tellable6 2020-04-20T14:58:10Z #raku <AlexDaniel> ryn1x: re Channel: great questions, can you file a ticket somewhere? Raku/doc maybe?
[Coke] AlexDaniel: Thanks. Probably an issue with the rollover from the previous software. 15:02
[Coke] I had an issue where I had no name set, I think, and things got confused. 15:02
AlexDaniel [Coke]: tbh I don't know if I have an account or not… I don't think I do 15:03
[Coke] Sure, could be anything. Again, happy to post a comment for you in the meantime.
AlexDaniel [Coke]: gist.github.com/AlexDaniel/70d7b3e...44b1d40d3c 15:53
El_Che The I'm feely lucky button on modules.raku.org is broken and points to this: modules.raku.org/dist/. I don't know who maintains it. 16:08
[Coke] AlexDaniel`: added 16:10
AlexDaniel` [Coke]: thanks! 16:12
[Coke] thank you for the feedback. Always good to hear from the community when processing grants. 16:13
chloekek 17° and windy outside with the window open is so cozy. 17:32
tellable6 2020-04-18T19:08:28Z #raku <guifa2> chloekek: I just saw your issues re printf. See my comments there, not sure if you'd want to collab on a projec there, but I'd be happy to help work on it.
2020-04-20T14:06:11Z #raku-dev <lizmat> chloekek crai.foldr.nl doesn't show Camelia anymore, but still references it in the footer :-)
chloekek lizmat: Camelia is still on the cardboard box. I plan to put it larger on the home page though. 17:33
lizmat :-)
lizmat so, I'm completely without inspiration for a presentation on the Conference in the Cloud: perlconference.us/tpc-2020-cloud/ 17:43
maybe it would be an idea to set up a repo with presentation suggestions ?
cpan-raku New module released to CPAN! Test::Async (0.0.2) by 03VRURG 17:51
vrurg lizmat: can't we use an existing one? Like marketing, for example. 17:51
lizmat vrurg o/ 17:52
yeah, sure...
vrurg o/ :)
I wonder if the first round of submissions has been considered already. I've got no reply to mine. 17:53
lizmat did you submit for the in-person, or the cloud one, or both ?
chloekek lizmat: I was also thinking maybe we could keep a list of presentation recordings on raku.org/resources/ 17:54
lizmat chloekek: feels like a good idea
vrurg lizmat: both. 17:55
lizmat hmmmm 17:56
vrurg The in-person has been accepted.
guifa2 vrurg: I haven't had my cloud talk accepted yet either 18:05
vrurg guifa2: thanks! Then it most definitely means they're very busy what could be well-explained with totally new format they try to handle. 18:06
guifa2 vrurg: indeed. but I would imagine anyone whose talk was already accepted for in person will get accepted for the cloud version 18:11
lizmat guifa2 vrurg I'm told you should be receiving confirmation either today or tomorrow 18:29
so keep your fingers crossed! :-) 18:30
guifa2 lizmat: not fair cheating with inside info haha 18:40
lizmat doesn't always work :-) 18:41
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/04/20/2020-...-progress/ 18:53
vrurg lizmat: I have a correction: there is a new module, Test::Async. Another matter, I forgot to change 'production' status to true while publishing. 19:05
lizmat if it's not on CPAN, I don't see any updates 19:06
vrurg Ok, will go in for this week then. :) Anyway, I messed up with META... 19:07
cpan-raku New module released to CPAN! Test::Async (0.0.3) by 03VRURG
lizmat yup, next week! 19:08
chloekek lizmat: I think parsing COBOL is straightforward. The trickiest bits are in fixed form directives, line continuations etc. Expressions and statements are simple rules for which compiler vendors provide EBNF for all the dialects they support (as well as the standard, but it doesn’t specify dialects that are widely used). 19:32
chloekek The biggest problem with implementing COBOL would be that 1) it has very many constructs, 2) the way it operates on data is with very specific rules that are unusual in today’s languages, such as decimal wraparound, and 3) performance is a concern for most deployed programs. 19:33
lizmat I understand that a lot of COBOL programs nowadays run on simulated hardware 19:37
so running something closer to the metal, may work, or not?
chloekek The simulation is probably more so in terms of I/O devices. 19:38
chloekek I only have surface-level knowledge of mainframes. They have a different architecture from personal computers and rack servers, with different I/O- and computation trade-offs. Running your optimized transaction processor on MoarVM on an IBM Z will not do you any good in terms of performance, unless MoarVM learns how to generate code for mainframe architectures. 19:46
But if you have a COBOL app that you run on a JVM (e.g. with Micro Focus) and want to attract Perl or Raku programmers, sure. :) 19:47
lizmat I think the whole point of a COBOL exercise on Raku, would be the capability of running COBOL programs outside of mainframes ? 19:48
chloekek That’s already possible with GnuCOBOL and various commercial compilers. 19:49
lizmat ah, ok, that just goes to show how much I know of that area :-)
chloekek In fact, I added GnuCOBOL to glot.io a while back :) glot.io/new/cobol
It would sure be fun though. I once attempted to implement COBOL and got some very basic programs working. It compiled to JS, because that’s what you do. 19:50
glot.io/snippets/fmov67aipd 19:52
lizmat cool 19:53
chloekek COBOL data types are like Cool. :) 19:54
Having a Raku slang for just COBOL picture clauses would be neat. 19:55
PIC X(20) #`[ 20-character string. ]; PIC 99V99 #`[ 4-digit unsigned number. decimal point in the middle, except when doing unformatted I/O ] 19:56
chloekek Also kudos for sending Raku weekly in an email that can also be viewed without HTML support. :) 20:16
lizmat chloekek: you need to thank Wordpress for that
chloekek WordPress++ 20:17
jjatria Are there any examples out there of how to make a Grammar give useful error messages when something does not match? 20:38
I found `FAILGOAL`, but haven't figured out how to properly use it
[Coke] Grammar::Debug ? 20:39
jjatria Hm, I'm thinking more from the user's perspective
[Coke] or, not for you, for the user?
jjatria So not debugging the Grammar, but the input, if that makes sense
[Coke] ah
;)
yup. In general, the examples I've seen mean you have to add alternatives everywhere which die with the helpful error. 20:40
but I'd wait for someone else to answer. :)
jjatria :D
I guess the Raku grammar might be a good place to look, but I was hoping for something less daunting 20:41
guifa2 jjatria: The technique described by [Coke] is what's done generally 20:45
So if you expect a letter or a number, and anything else would be an error:
[Coke] \o/
guifa2 token foo {  <letter> || <number> || { die "You have a problem here" } } 20:46
A common way of disallowing a character / token is to use [ <bad> {die} ]? 20:47
If <bad> doesn't match, no harm done because it never gets to die because the group is optional. 20:48
jjatria Ah, cool, that's useful
That's the kind of thing I was looking for, examples of how these things look when implemented. Thanks! 20:49
guifa2 jjatria: take a look at this definition for some stuff: 20:52
gist.github.com/alabamenhu/7e30eec...24518e378d
jjatria Thanks! 20:53
guifa2 That's one I just did for the binary grammar's grammar. It expects things in the format b0000_0000 or o00_00 or x00 (if 8 bit), but also unlimited underscores inside the token (so x_________f___8 is valid, but x56_ is not). 20:57
Right shifting with X is only allowed terminally, so that might help understand what's going there 20:58
jdv79 "The iterator of this Seq is already in use/consumed by another Seq" is one of the more annoying errors 22:09
lizmat jdv79: if you have a golf, we can either say what's wrong with your code, or that it is a bug :) 22:15
sleep&
jdv79 it just pops ups from time to time and i know mostly why it happens but its awfully unintuitive for newbies 22:16
i can't golf it atm, sorry
is some ways the diff tween array and scalar assignment are whack 22:18
AlexDaniel jdv79: yeah, getting Seqs is pretty much always unexpected, it's just that most of the time it's a pleasant surprise 22:19
jdv79 i realize its got cleverness and utility but does it strike a good balance overall - maybe
kind of similar in my mind to Scalar. most of the time you can ignore it and its all nice but sometimes the abstraction bites and seemingly out of nowhere if you're pleasantly otherwise oblivious to what's under teh covers 22:21
AlexDaniel sometimes I'd have a bunch of code that does all kinds of processing, and then I'd be like “oh, it'd be nice if this was lazy so that it doesn't process a bunch of stuff needlessly”
and then I look and it turns out that it's Seqs all the way through and I don't need to change anything
jdv79 yeah, i know there's goodness. i'm just remarking on the rough edges that poke out here and there 22:22
i'm trying to think how i could introduce raku at $work and its stuff like that where i'd have trouble justifying or even just explaining it to my colleagues. 22:24
SmokeMachine Hi guys! is that a bug? 22:35
m: sub a([$a]) { dd $a }; a [1]; a [1 => 2]
camelia 1
Too few positionals passed to 'a'; expected 1 argument but got 0 in sub-signature
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
SmokeMachine m: sub a([|$a]) { dd $a }; a [1]; a [1 => 2] 22:36
camelia 5===SORRY!5=== Error while compiling <tmp>
Obsolete use of | or \ with sigil on param $a
at <tmp>:1
------> 3sub a([|$a7⏏5]) { dd $a }; a [1]; a [1 => 2]
expecting any of:
shape declaration
SmokeMachine sub signature... 22:39
jnthn SmokeMachine: I think it's spec'd semantics of List.Capture 23:31
Though I ain't sure I like them :)
The pair promotion to named arguments seems to be a trap more often than it's useful
I'm not sure what *else* relies on this behavior, however. 23:32
SmokeMachine jnthn: and that, even doing “1” => 2 or (1 => 2) will not fix the problem as when you are trying to receive a Pair... 23:33
SmokeMachine m: sub foo(Pair $p) { dd $p }; foo (1 => 2) 23:33
camelia 1 => 2
SmokeMachine m: sub foo(Pair $p) { dd $p }; foo 1 => 2
camelia 1 => 2
SmokeMachine m: sub foo(Pair $p) { dd $p }; foo bla => 2 23:34
camelia Too few positionals passed; expected 1 argument but got 0
in sub foo at <tmp> line 1
in block <unit> at <tmp> line 1
SmokeMachine m: sub foo(Pair $p) { dd $p }; foo “bla" => 2
camelia 5===SORRY!5=== Error while compiling <tmp>
Unable to parse expression in curly double quotes; couldn't find final '”' (corresponding starter was at line 1)
at <tmp>:1
------> 3b foo(Pair $p) { dd $p }; foo “bla" => 27⏏5<EOL>
SmokeMachine m: sub foo(Pair $p) { dd $p }; foo (“bla" => 2)
camelia 5===SORRY!5=== Error while compiling <tmp>
Unable to parse expression in curly double quotes; couldn't find final '”' (corresponding starter was at line 1)
at <tmp>:1
------> 3foo(Pair $p) { dd $p }; foo (“bla" => 2)7⏏5<EOL>
jnthn Well, yes, by the time it's in a List then the syntactic distinction is long gone.
SmokeMachine m: sub foo(Pair $p) { dd $p }; foo ("bla" => 2)
camelia :bla(2)
SmokeMachine m: sub foo(Pair $p) { dd $p }; foo (bla => 2)
camelia :bla(2)
SmokeMachine m: sub foo(Pair $p) { dd $p }; foo "bla" => 2
camelia :bla(2)
SmokeMachine m: sub foo([Pair $p]) { dd $p }; foo ["bla" => 2] 23:35
camelia Too few positionals passed to 'foo'; expected 1 argument but got 0 in sub-signature
in sub foo at <tmp> line 1
in block <unit> at <tmp> line 1
SmokeMachine jnthn: are you thinking of maybe changing it?
jnthn I mean, you can have the other thing, so long as you accept that if you do `foo [bla => 2]` then you're going to get a positional, not a named.
m: sub foo([:$bla]) { dd $p }; foo [bla => 2] 23:36
SmokeMachine jnthn: I don’t know if that would be the intent most of the time… but that was my intent this time...
camelia 5===SORRY!5=== Error while compiling <tmp>
Variable '$p' is not declared
at <tmp>:1
------> 3sub foo([:$bla]) { dd 7⏏5$p }; foo [bla => 2]
jnthn m: sub foo([:$bla]) { dd $bla }; foo [bla => 2]
camelia 2
jnthn So you'd break that.
I suspect, in hindsight, the behavior we ended up with creates too much of a discontinuity 23:37
SmokeMachine m: sub foo([*%a]) { dd %a }; foo [bla => 2]
camelia Hash element = {:bla(2)}
jnthn Yup, that one'd break too
Otoh, Capture promotion would be much cheaper if we didn't scan for Pair 23:38
In fact, you might even be able to elide the coercion completely in some cases, which'd be better for performance too.
So it's at least worth thinking about changing it 23:39
SmokeMachine on my case, I was wanting to receive something like: 1 => [2 => [4, 5], 3 => [6, 7]], my signature was: (Pair (Int :$key, :value([$left, $right?])))
changing it, that would work, right? 23:40
jnthn Yes 23:41
SmokeMachine and would that make sense to not search Pairs on sub signature but continue doing that on signature? 23:42
Oh! you was saing onli inside List!
s/onli/only/
jnthn Nothing specific to signatures would actually change
It's the behavior of List.Capture that we're considering
SmokeMachine List.Capture, right?
yes 23:43
jnthn Any type can implement method Capture to choose how it is going to destructure in a Signature.
SmokeMachine I think, on this case, that would make completely sense...
that’s a interesting information.. I’ve never thought about implementing a Captue method… that could be useful... 23:44
jnthn: would you mind if I change the subject for a second?
jnthn If you've a moment to make a problem solving ticket on List.Capture, please do 23:45
What else? :)
SmokeMachine I was thinking… on your macro proposal, would it be able to do something like method macro?
I mean, would that be possible do on Red, a ResultSeq.map be a macro? or could it have access to the RakuAST somehow? 23:46
I’m going to create the ticket
jnthn Well, the trouble there is that nethod dispatch is late-bound, whereas macros happen at compile time, so the direct answer is "no"... :) 23:48
jnthn However, there's probably - with a bit more work - a way to make this happen. 23:49
Well, to make you able to get the AST
SmokeMachine I would really like to have a `method map(&block)` and get the RakuAST of that &block... 23:50
jnthn I can see two ways to do it
SmokeMachine Hum...?
jnthn 1) I speculated in my recent talk that we'll be able to have custom compiler passes, which will be fed the entire AST of the compilation unit to process. If you can do enough type-tracking to always know when you're doing something against a Red collection, then you could arrange for the AST to be preserved anyway. Heck, you could even walk it at compile-time and make sure it's something you know how to turn into SQL, and do some of the translation 23:52
2) Or the bigger hammer is to have a way to force AST preservation on all method calls of a certian name, using the same technique, and then some way to make it "contaigious" on all using modules. 23:53
Or the less likely option 3) is that we decide that the AST is always preserved for all compiled code, but that's a lot of memory/disk overhead... 23:54
jnthn Option 1 is neat in that you can actually tell people at compile time when they do something with no SQL mapping, not at runtime. Which would fix the LINQ problem where one didn't know until runtime. 23:55
(I assume it's still that way, I didn't do .Net for years...)
SmokeMachine transforming that into a custom code that would know how to do the SQL at compie time would be great… but the custom compiler passes is not planned to the 1st step, right? 23:56
jnthn Not really, but it's probably the easiest of all the things I'd proposed to defer 23:57
I suspect it's easy to implement, and the work is in the API design. I'd be happy to look at proposals. 23:58
SmokeMachine so I could hope to something make it first step?
Hum… proposals… that would be interesting… is there any file you would suggest me to start looking at? 23:59
jnthn Not really; the things you'd be best looking at don't exist yet :)