🦋 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, reportable6 joined 00:05 eroux left 00:07 eroux joined 00:12 eroux left 00:22 eroux joined 00:43 jpn left 00:46 jpn joined 00:51 jpn left 01:04 eroux left 01:11 rf joined 01:13 razetime joined 01:31 eroux joined 02:19 jpn joined 02:24 jpn left 02:26 rf left
antononcube @Coke Did you present at the The Perl and Raku conference two weeks ago? 02:41
[Coke] Nope, I didn't attend 02:42
antononcube Ah, for some reason I though you were going to... 02:43
02:51 Xliff left 02:58 andydude joined 03:58 unicodable6 left, nativecallable6 left, bisectable6 left, quotable6 left, reportable6 left, greppable6 left, statisfiable6 left, releasable6 left, sourceable6 left, notable6 left, shareable6 left, squashable6 left, tellable6 left, benchable6 left, evalable6 left, bloatable6 left, coverable6 left, linkable6 left, committable6 left, benchable6 joined, quotable6 joined, linkable6 joined, evalable6 joined 03:59 bisectable6 joined, bloatable6 joined, releasable6 joined, nativecallable6 joined, squashable6 joined, sourceable6 joined, tellable6 joined 04:00 statisfiable6 joined, notable6 joined, shareable6 joined, coverable6 joined, reportable6 joined 04:01 unicodable6 joined, committable6 joined, greppable6 joined 04:07 jpn joined 04:12 jpn left 04:16 razetime left
guifa__ m: subset X of Str() where *.so; class A { method a (X $x) { $x.say }; }; my A $a .= new; (1..10).hyper(:batch(1), :degree(2)).map({ $a.a($_); }); 04:18
camelia 1
2
3
4
5
6
7
8
9
10
guifa__ xinming: you can also make it a coercing type, to handle the conversion from int to string automatically if it´s not a string 04:19
04:41 teatwo joined
[Coke] ended up going to CT and getting covid instead, not an upgrade 04:42
04:42 teatwo left 04:43 teatwo joined 04:44 teatime left 04:56 razetime joined 05:02 jpn joined 05:06 jpn left 05:27 jpn joined 06:00 reportable6 left 06:02 reportable6 joined
xinming guifa__: So there is diff between subset X of Str and subset X of Str() 06:22
What are the subtle diff between them?
This worked, But It's quite confusing then, Why will `subset X of Str where ..` worked without hyper 06:23
m: my %m = ("a" => 1, "b" => 2, "c" => 3); subset X of Str() where * (elem) %m.keys.Set; sub a (X $x) { $x.say }; ("a" .. "c").hyper(:batch(1), :degree(2)).map({ a($_); }); 06:26
camelia A worker in a parallel iteration (hyper or race) initiated here:
in block <unit> at <tmp> line 1

Died at:
Type check failed in binding to parameter '$x'; expected X but got Str ("a")
in sub a at <tmp> line 1
in block at…
xinming guifa__: with coercing type, it still fails.
I believe this is a bug
07:03 linkable6_ joined, evalable6_ joined 07:11 jpn left, andydude left, eroux left, Sgeo left, tejr left, m_athias left, nine_ left, reportable6 left, committable6 left, unicodable6 left, coverable6 left, shareable6 left, notable6 left, tellable6 left, squashable6 left, nativecallable6 left, releasable6 left, bisectable6 left, evalable6 left, linkable6 left, benchable6 left, PipStuart left, andinus left, kjp left, ProperN[out] left, daxim left, summerisle left, perlmaros left, guifa__ left, mjgardner left, SmokeMachine left, gabiruh left, samcv left, jetchisel left, tobs left, patrickb left, atweedie left, corwin left, ugexe left, zostay left, slu left, hexology left, Ekho left, hellwolf left, discord-raku-bot left, Util left, greppable6 left, statisfiable6 left, sourceable6 left, bloatable6 left, quotable6 left, Scotteh_ left, human-blip left, RonaldR34g4m left, samebchase left, jast left, ilogger2 left, polettix left, uzl[m] left, tbrowder_ left, xkr47 left, tailgate left, rypervenche left, justache left, mark22k left, Sevalecan left, amenonsen left, DarthGandalf left, oodani left, perryprog left, mtj left, PotatoGim left, askmeaboutloom left, cm left, GreaseMonkey left, Altreus left, clarkema left, xinming left, kst left, jgaz left, jrjsmrtn left, gfldex left, elcaro left, Voldenet left, dg left, Aedil left, simcop2387 left, avuserow left, tinita left, timo left, charsbar left, dutchie left, donpdonp|z_ left, nicole left, vrurg left, tonyo left, zups left, silug left, thowe left, esh left, kawaii left, Matthew|m left, MitarashiDango[m left, Orbstheorem left, moritz left 07:12 jpn left, Vyrus joined, clarkema joined, atweedie joined, patrickb joined 07:17 tobs joined, jetchisel joined, samcv joined, gabiruh joined, SmokeMachine joined, mjgardner joined, samebchase joined, human-blip joined, Scotteh_ joined, quotable6 joined, bloatable6 joined, sourceable6 joined, statisfiable6 joined, greppable6 joined, rypervenche joined, tailgate joined, xkr47 joined, tbrowder_ joined, nicole joined, donpdonp|z_ joined, dutchie joined, charsbar joined, timo joined, tinita joined, avuserow joined, simcop2387 joined, Aedil joined, dg joined, Voldenet joined, elcaro joined, gfldex joined, jrjsmrtn joined, jgaz joined, kst joined, xinming joined, moritz joined, Util joined, discord-raku-bot joined, hellwolf joined, kawaii joined, esh joined, thowe joined, silug joined, zups joined, tonyo joined, vrurg joined, nine_ joined, m_athias joined, tejr joined, Sgeo joined, andydude joined, jpn joined, corwin joined, ugexe joined, zostay joined, slu joined, hexology joined 07:18 reportable6 joined, committable6 joined, unicodable6 joined, coverable6 joined, shareable6 joined, notable6 joined, tellable6 joined, squashable6 joined, nativecallable6 joined, releasable6 joined, bisectable6 joined, benchable6 joined, PipStuart joined, andinus joined, kjp joined, ProperN[out] joined, daxim joined, summerisle joined, perlmaros joined, guifa__ joined 07:19 tib is now known as 020AAC0DL, guifa__ joined, perlmaros joined, summerisle joined, daxim joined, ProperN[out] joined, kjp joined, andinus joined, PipStuart joined, benchable6 joined, bisectable6 joined, releasable6 joined, nativecallable6 joined, squashable6 joined, tellable6 joined, notable6 joined, shareable6 joined, coverable6 joined, unicodable6 joined, committable6 joined, reportable6 joined, hexology joined, slu joined, zostay joined, ugexe joined, corwin joined, polettix joined, ilogger2 joined, jast joined, tobs joined, jetchisel joined, samcv joined, gabiruh joined, SmokeMachine joined, mjgardner joined, samebchase joined, human-blip joined, Scotteh_ joined, quotable6 joined, bloatable6 joined, sourceable6 joined, statisfiable6 joined, greppable6 joined, rypervenche joined, tailgate joined, xkr47 joined, tbrowder_ joined, nicole joined, donpdonp|z_ joined, dutchie joined, charsbar joined, timo joined, tinita joined, avuserow joined, simcop2387 joined, Aedil joined, dg joined, Voldenet joined, elcaro joined, gfldex joined, jrjsmrtn joined, jgaz joined, kst joined, xinming joined, moritz joined, Util joined, discord-raku-bot joined, hellwolf joined, kawaii joined, esh joined, thowe joined, silug joined, zups joined, tonyo joined, vrurg joined, nine_ joined, m_athias joined, tejr joined, Sgeo joined, andydude joined, jpn joined, dustinm` left, jmcgnh left
xinming my %m = ("a" => 1, "b" => 2, "c" => 3); subset X of Str() where * (elem) %m; sub a (X $x) { $x.say }; ("a" .. "c").hyper(:batch(1), :degree(2)).map({ a($_); }); 07:20
m: my %m = ("a" => 1, "b" => 2, "c" => 3); subset X of Str() where * (elem) %m; sub a (X $x) { $x.say }; ("a" .. "c").hyper(:batch(1), :degree(2)).map({ a($_); });
camelia A worker in a parallel iteration (hyper or race) initiated here:
in block <unit> at <tmp> line 1

Died at:
Type check failed in binding to parameter '$x'; expected X but got Str ("a")
in sub a at <tmp> line 1
in block at…
07:20 dustinm` joined 07:21 Altreus joined, GreaseMonkey joined, cm joined, mtj joined, PotatoGim joined, perryprog joined, askmeaboutloom joined, oodani joined, DarthGandalf joined, amenonsen joined, Sevalecan joined, mark22k joined, justache joined 07:24 sivoais left, Orbstheorem joined 07:25 sivoais joined 07:27 eroux joined 07:31 jpn left, jmcgnh joined 07:34 squashable6 left 07:35 Ekho joined 07:37 squashable6 joined 08:09 dakkar joined 08:10 sena_kun joined, andydude left
xinming I think I found where the bug is 08:14
08:14 Matthew|m joined
xinming m: my %m = ("a" => 1, "b" => 2, "c" => 3); subset X of Str() where { $_ (elem) %m }; sub a (X $x) { $x.say }; ("a" .. "c").hyper(:batch(1), :degree(2)).map({ a($_); }); 08:14
camelia a
b
c
08:15 MitarashiDango[m joined
xinming m: my %m = ("a" => 1, "b" => 2, "c" => 3); subset X of Str() where * (elem) %m; sub a (X $x) { $x.say }; ("a" .. "c").hyper(:batch(1), :degree(2)).map({ a($_); }); 08:15
camelia A worker in a parallel iteration (hyper or race) initiated here:
in block <unit> at <tmp> line 1

Died at:
Type check failed in binding to parameter '$x'; expected X but got Str ("a")
in sub a at <tmp> line 1
in block at…
08:15 uzl[m] joined
xinming `where * (elem) %m` will raise error, But `where { $_ (elem) %m }` will work 08:15
So anyone here could explaiin this please? :-) 08:16
I feel this bug is greater than I thought, on my program, It still raises error with `where { $_ (elem) %m }` version, But the test oneliner works 08:22
08:22 razetime left 08:25 Sgeo left 09:07 razetime joined 09:14 razetime left 09:26 jpn joined 09:31 jpn left, jpn joined
SmokeMachine m: my %m = ("a" => 1, "b" => 2, "c" => 3); subset X of Str() where * (elem) %m; sub a (X $x) { $x.say }; ("a" .. "c").map({ a($_); }); 09:47
camelia a
b
c
SmokeMachine m: my %m = ("a" => 1, "b" => 2, "c" => 3); subset X of Str() where * (elem) %m; sub a (X $x) { $x.say }; for "a" .. "c" { start say a($_) } 09:49
camelia ( no output )
SmokeMachine m: my %m = ("a" => 1, "b" => 2, "c" => 3); subset X of Str() where * (elem) %m; sub a (X $x) { $x.say }; await do for "a" .. "c" { start say a($_) } 09:50
camelia An operation first awaited:
in block <unit> at <tmp> line 1

Died with the exception:
Type check failed in binding to parameter '$x'; expected X but got Str ("a")
in sub a at <tmp> line 1
in code at <tmp> line 1
09:50 razetime joined
SmokeMachine m: my %m = ("a" => 1, "b" => 2, "c" => 3); subset X of Str() where { $_ (elem) %m }; sub a (X $x) { $x.say }; await do for "a" .. "c" { start say a($_) } 09:50
camelia a
True
b
True
c
True
SmokeMachine m: my %m = ("a" => 1, "b" => 2, "c" => 3); subset X of Str() where * (elem) %m; sub a (X $x) { $x.say }; await (start({ a(“a”) }), start { a “b” }) 09:52
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared routine:
start used at line 1. Did you mean 'spurt', 'sqrt', 'sort'?
SmokeMachine 10:52 <SmokeMachine> m: my %m = ("a" => 1, "b" => 2, "c" => 3); subset X of Str() where * (elem) %m; sub a (X $x) { $x.say }; await (start { a(“a”) }, start { a “b” }) 09:53
m: my %m = ("a" => 1, "b" => 2, "c" => 3); subset X of Str() where * (elem) %m; sub a (X $x) { $x.say }; await (start { a(“a”) }, start { a “b” })
camelia An operation first awaited:
in block <unit> at <tmp> line 1

Died with the exception:
Type check failed in binding to parameter '$x'; expected X but got Str ("a")
in sub a at <tmp> line 1
in block at <tmp> line 1
SmokeMachine xinming: I agree… that looks like a bug… 09:54
09:57 guifa__ left 09:58 guifa joined
SmokeMachine m: my %m = ("a" => 1, "b" => 2, "c" => 3); subset X of Str() where { $_ (elem) %m }; sub a (X $x) { $x.say }; await (start { a(“a”) }, start { a “b” }) 10:02
camelia a
b
xinming there is a small diff between `where { $_ (elem) %m }` and `where * (elem) %m` 10:26
without .hyper it works fine, with hyper, we can see the differences. 10:27
nemokosch not even surprised 10:35
not gonna lie, I have high hopes for RakuAST to eliminate WhateverCode weirdnesses 10:42
10:44 NemokoschKiwi joined
xinming nemokosch, When will RakuAst merged then? 10:49
lizmat xinming: there's two things here: 10:50
the RakuAST classes for building ASTs: these are available now when doing either "use experimental :rakuast" or "use v6.e.PREVIEW"
the new Raku grammar that uses RakuAST classes to build AST from code: this can be activated with RAKUDO_RAKUAST=1 10:51
nemokosch I'm thinking of the RakuAST based grammar, for that matter 10:52
lizmat this will be ready when it can a: pass all spectests, and b: can build the setting 10:54
that's when we can start thinking about releasing a 6.e language level
xinming lizmat: just tried with `use experimental :rakuast`, that bug is gone.
lizmat: when is it possible to happen according to your guess? 10:55
lizmat *that* shouldn't have made any difference with that bug
10:55 jpn_ joined
nemokosch yeah sounds weird 10:56
also, I noticed that the RakuAST representation is not what I assumed it to become
I checked on that pick xx 5 situation 10:57
and the AST representation downright contained a thunk wrapper on the left handside
xinming lizmat: Yea, My mistake, I tested on the wrong example.
lizmat nemokosch some bugs may have been ported :-)
10:58 jpn left
nemokosch hm, I'm not sure 10:58
my point is that apparently the parsing process examined the operator semantically
and I would have assumed that was not the task of it, quite the contrary
11:00 jpn joined 11:01 jpn_ left
I'd have expected (^10).pick + 5 and (^10).pick xx 5 to look the same, except for the one node of the operator on top 11:01
lizmat if the left side there wouldn't get thunked, you would get 5x the same random value 11:02
so xx does need special grammar handling]
nemokosch I'm not sure if it needs special grammar handling with RakuAST - and more importantly, thunking doesn't affect the syntax so it would be weird to call something an AST that already investigates the behavior of certain operators 11:04
anyway, when you evaluate the node of operator xx, you still have access to the expressions constructed as its operands, so why couldn't thunking only happen then? 11:05
xinming lizmat: BTW, is the bug `where * (elem) ..` vs `where { $_ (elem) .. }` easy to fix? 11:06
lizmat so I guess you'd be ok with needing to specify
{ (^10).pick } xx 5
then?
xinming: I have *no* idea
I would have to dive into that part of the grammar, and that is currently not on my shortlist of things to do 11:07
I suggest you make an issue for it so that it doesn't fall through the cracks
nemokosch I think that shouldn't be needed with proper RakuAST evalling at all, quite the opposite
I think by now it should be possible to let users define thunkiness for operators, instead of compiler hacking
if a RakuAST expression is evaluated starting from the root node, there seems to be no problem to decide if a subtree needs to be thunked or not 11:09
lizmat I think by now more people should be involved in making RakuAST work
so: well volunteered :-)
xinming lizmat: Ok, Will fire a bug so this can be fixed. 11:10
lizmat xinming: thanks, and please a nice, short golf :-)
nemokosch I think it's hard to expect people to work on something that is nowhere explained or written down 11:11
11:11 jpn left
lizmat nemokosch that goes for all involved 11:11
nemokosch and frankly, Jonathan Worthington has responsibility
lizmat well, technically, the RSC has responsibility nowadays 11:12
nemokosch that's why it was so weird when he summarized it as "oh it's so nice that people found my work worthy of continuing"
duh, like that was meant to be "the big thing"
lizmat that goes for all open source projects 11:13
nemokosch I don't think it goes for all open source projects that somebody initiates a monstrous task that is meant to be "the next big thing"
completes it to 20% and then leaves it behind with little to no resource about it 11:14
it's not just whether you are personally okay with it; it's just this mindset is overwhelmingly prone to failure
and of course if the one who invented the whole thing won't leave anything technical behind, how could one expect the poor others who just try to figure something out on their own and make it happen "whatever it takes" 11:15
this goes for basically all of Rakudo - you need have enough fanatism to compensate for your lack of knowledge, and the less you know, the more fanatism you need 11:17
lizmat github.com/rakudo/rakudo/blob/main.../README.md 11:18
nemokosch Yes, I said it aware of this file 11:24
take one example: what about the gazillion of FULL-UPPERCASE-MAGIC-METHODS? 11:25
the architecture is strongly based on this assumption that you are going to inherit/mix in stuff that provides a service, and some services inherit even from each other 11:27
jast I don't see how this could be done better in the early phases of something highly speculative 11:28
nemokosch outlining the speculations would also help
jast you can't start making something without assumptions and you usually for some time won't know which assumptions are the right ones
nemokosch anyway, if you are a design architect, this is not the kind of documentations you should provide for the people who will do the work 11:29
if you only compare it to vrurg's presentations on Rakudo, you can already see the layers of difference
jast I mean... you don't really know ahead of time how a project like this will develop, right?
I mean... you don't really know ahead of time how a project like this will develop, right? 11:30
nemokosch by the way, it's really said there was no continuation of that
jast I'm not saying that this was done optimally, but I understand how it came to be this way
nemokosch I do think it's a problem that we have a bunch of friends, or comrades at least, who will just stand for each other, whether some serious mistake has been made objectively, or not 11:31
nobody dares to say that the way RakuAST was left behind for the rest was unmanageable
and therefore there is no urge to improve on the situation, the mistakes are simply denied 11:32
jast I don't know jnthn at all
nemokosch if you are not fanatic enough, you are out, basically
or you are useless at least
jast well I think we exchanged about two lines in IRC once 11:33
mainly I just don't see how blaming someone will change anything 11:34
nemokosch It's rather the other way around imo
if you can't even agree that some action, or lack of action, is harmful for the project, how can you be dedicated to do it right? 11:35
jast "harmful" is a big word
nemokosch not too big in this case, I don't thinkso
and here in this situation, the problem is pretty much that nobody is willing to claim to know RakuAST enough to teach others
teach as in, post some documents about the architecture or make a couple of hours presentation 11:36
jast clearly this project didn't turn out so well if it's been in "early design phase" for over a year 11:38
but the time we're spending in this discussion you could have spent digging into it instead if it matters this much to you :)
nemokosch Yeah this is a common one 11:39
jast well, you seem to be saying jnthn has an obligation to put in his spare time... and you don't
nemokosch the sad truth is, I still have higher hopes that one day the project gets better managed, than that I will single-handedly solve the RakuAST issue
well, if a so called "language in production" depended on solely my judgement, I would probably be more careful 11:40
especially if this situation emerged mostly my lack of knowledge-sharing
because of*
jast well, nobody is perfect 11:41
nemokosch and really, I'm not saying that jnthn should keep doing XYZ stuff 11:42
I'm saying that if you leave a project for a larger amount of time that depends so much on your knowledge, at least do take the effort to share it so someone else can pick up
that's a one-time effort
and this is something people would expect from you, and you would expect from others, for any non-toy project 11:43
jast I don't really know his circumstances, but it's quite possible that things simply happened in such a way that that didn't work out so well
lizmat feels like this discussion has been had many times already and will now recuse herself 11:44
jast but we could turn this around just as well: nobody else stepped up to get involved just as deeply
nemokosch also, I don't know how it is for you but now that we are at it, I did bother to fix a couple of Rakudo bugs, to trace others' problems back in the core, to explain how things work, I did watch the Rakudo-related presentations in the last couple of years, and so on 11:46
jast I'd like to think I could do a great job of documenting things if I had been in a similar position, but I can't be certain really
nemokosch so fair enough, I'm not up there with lizmat and the likes but I do think I did more than an average potential contributor would 11:47
jast which is great but entirely irrelevant to this topic
nemokosch not if you are framing it as "duh you are just lazy to do it yourself" 11:48
jast that's not what I'm saying
nemokosch then I really see no point in beating the dead horse with this "if this matters so much for you..." sentiment
and this seems to be the big difference between what I think would be healthy and what the very few knowledgeable and influential people are doing in this community 11:50
jast I'm saying that well, jnthn didn't do everything, and nobody else filled the gap (to your satisfaction). you seem to be putting the responsibility entirely on him. I see it as the collective responsibility of everyone who cares about the project. if nobody cares "enough", that still doesn't make it their fault... it just means the project has an issue that is not exclusively one person, but the sum of what ever 11:51
yone is doing
(or not doing)
I'm not blaming you, either. I'm blaming no single person.
nor a specific group of people
nemokosch they seem to think that it all boils down to fanatism. If you have enough fanatism, you can lift mountains. But what if you can't have enough fanatism to start working without a direction, without any knowledge or substantial help? 11:52
well, then you will stay an outsider, and the few fanatics will always just say "cheer up and get to work" 11:53
11:54 jpn joined
jast so, the community is lacking someone who can do extensive mentoring. which is a shame, but whose fault is that? no one's if you ask me 11:55
nemokosch I do think that in the particular situation with RakuAST (and probably the lack of contributors to MoarVM for example), predominantly Jonathan Worthington is at fault (which is a big taboo in itself) - however, that is not the "systemic" problem 11:57
the real problem is this need to always put the blame on the people for not contributing enough, and never thinking about providing better circumstances for the contributors 11:58
jast creating those circumstances is a lot of work 11:59
12:00 reportable6 left
jast nobody is putting in the work to dive in by themselves, understandable 12:00
well, "nobody" is a bit strong a word maybe, simply used for illustration purposes
nemokosch then it is just as understandable for people to not rush to work on an underdocumented, obscure system
jast OTOH nobody is putting in the work to make it substantially easier to become a strong contributor 12:01
both are understandable IMO
which is also why I'm not blaming *anyone*
12:01 reportable6 joined, jpn left
jast it's possible that some existing contributors feel like the barrier to entry is much smaller than it is. I wouldn't know, I haven't been very involved in this topic (or anything really) 12:02
if that's the case and you're criticizing that, fine by me. I just wouldn't go as far as blaming people for not putting the type of effort that you wanted them to put in, if that makes sense 12:04
nemokosch For what it's worth, I think the entry point for the core library is not particularly high, and that's why I start to show CoreHackers::Sourcery around, or the usefulness ot the --target flag. I don't know how much it helps in and of itself 12:05
Anyway, I don't think I will ever empathize with this... well, downplaying that you also seem to present here. Like no, if you have a sufficiently large and important project, it's common sense to leave it in a state that willing others can continue. It's not something "I want XY to put in" 12:07
jast well, I have no idea why jnthn stopped being so active. maybe other things got in the way unexpectedly. 12:11
nemokosch And I have this bitter feeling that if one drew a metaphor or just hid the name, suddenly everybody would agree that it's common sense... 12:12
jast I can empathize
12:12 jpn joined
nemokosch and like this is the thing. In an ideal world, a lot of situations would never arise. However, when they do arise in reality, there needs to be some sort of relation or response to it. The "blaming" is not the important part - and frankly, it wouldn't be necessary in the first place if somebody just acknowledged the mistake or provided an explanation, instead of this weird "oh I'm so happy they picked up on my 12:19
little nuance I made in my freetime" lol
The important part would be to simply conclude that "if we don't provide some introduction or assistance to potential contributors, they will never be of help"
and this is an actionable thought 12:20
lizmat nemokosch how about this for an actionable thought: 12:25
RAKUDO_RAKUAST=1 raku t/spec/S02-names/is_default.rakudo.moar
has 1 failing test.
How about you try to figure out why that is failing, and I'll be around to answer any questions you might have 12:26
nemokosch as you wish 12:30
12:30 NemokoschKiwi left
xinming m: (1..3).map({ last if $_ > 2; .raku.say; }) 12:36
camelia 1
2
xinming I'm a bit confused, is that internally, .map is treated as a for loop internally? 12:37
lizmat xinming: no, it's actually the other way around.
a for is internally a .map that does a .sink-all on the iterator 12:38
xinming when I try to convert for into .hyper.map, I forgot to comment the last statement, and suprisingly, It works.
lizmat: thanks, got it.
lizmat now, the semantics "next" and "last" and "redo" within a hyper are really undefined at the moment 12:39
*of
xinming I think we need to implement "leave" statement.
jast what would that do? 12:40
lizmat it's like return for blocks
thought has gone into that
but the workaround atm is so simple that it was deemed not necessary to implement "leave"
nemokosch what is the workaround? 12:41
lizmat instead of a block, use a nameless sub
xinming nameless sub will add another indention to the code.
lizmat so "sub { }" instead of { }
xinming lizmat: Is there performance difference between block and sub? 12:42
lizmat xinming: that's only if you have an IDE maybe, that's not a parser requirement ?
nemokosch so I guess make spectest will create the spec folder 12:43
lizmat nemokosch indeed
m: my $a = sub { Nil }; $a() for ^1000000; say now - INIT now 12:44
camelia 0.01582713
lizmat m: my $a = { Nil }; $a() for ^1000000; say now - INIT now
camelia 0.015122427
lizmat I'd say: marginally so
xinming ^^
not something I think you'd need to worry about
xinming: also, part of the overhead is setting up a return point for the "return" statement 12:45
xinming lizmat: Yea, That's why I think why do we have block then. :-)
lizmat if we would implement "leave", this would need to be done for each block
xinming So, probably in the future, leave statement will be removed I guess 12:46
lizmat well, the design documents are frozen, so "leave" will continue to be mentioned in there
nemokosch okay, perhaps I don't want to wait for all tests to complete :DD 12:47
lizmat but at some point I guess we will remove the TODOd tests from roast
nemokosch anyway, it claims that there was 1 failing test but even without counting subtests I see like 5 12:49
lizmat maybe some of them are TODOd ? 12:50
nemokosch true but why do comments matter for this?
lizmat ? 12:52
in any case: in that test, the failing subtests all have the same error: lang-call cannot invoke object of type 'VMNull' belonging to no language 12:53
which points to something being Mu when it shouldn't
12:53 eroux left 13:10 eroux joined
nemokosch is there anything wrt variable declarations with the of trait that works? 13:14
lizmat I'm not sure, you'd have to try 13:20
you know of the .AST method on strings, right?
nemokosch not really but I know --target=ast 13:24
however, for something as mundane as my $foo of Int, even --target=parse explodes (which is weird, like why would parse care about the underlying semantic problem)
lizmat m: say Q|my $foo of Int|.AST 13:25
camelia ===SORRY!===
lang-call cannot invoke object of type 'VMNull' belonging to no language
lizmat ok, so it goes wrong there already
m: say Q|my Int $foo|.AST
camelia RakuAST::StatementList.new(
RakuAST::Statement::Expression.new(
expression => RakuAST::VarDeclaration::Simple.new(
type => RakuAST::Type::Simple.new(
RakuAST::Name.from-identifier("Int")
),
sigil …
lizmat so, the other syntax already appears to work 13:26
m: say Q|my Int $foo; $foo = "bar"|.AST.EVAL
camelia Type check failed in assignment to $foo; expected Int but got Str ("bar")
in block <unit> at <tmp> line 1
lizmat so you'd need to find the "of" handling of variable definition in the grammar, and hook that up correctly 13:27
in the associated action
nemokosch the thing is, variable-declarator describes a declaration like that, and that already accounts for traits, and of already has the same rule as in the old grammar 13:29
github.com/rakudo/rakudo/blob/52f4....nqp#L1860 then there is this part but I have no clue what $decl actually contains 13:30
well, probably the type attribute is not set on the trait, that's what the error message implies 13:34
13:41 xinming left
lizmat he... it looks like some debugging code is causing the error 13:42
nqp::gethllsym('nqp', 'note')($_.type.dump);
13:43 xinming joined
lizmat and the test in question now passes! 13:43
nemokosch okkay but... 13:44
how was the debugging code wrong? xD
lizmat I'd say that the nqp::gethllsym('nqp', 'note') yielded VMNull 13:45
nemokosch oof 13:46
anyway, why wasn't it just nqp::note?
lizmat yeah, no idea why that was written that way 13:48
anyways, +3 spectest files, so I'd call that a win :-)
nemokosch so I'd run the spectest again, and select a file that has only 1 or just a few failing tests 13:50
and look at that then
nemokosch I know that but truth be told, I also have preferences, it's much more interesting to fix something that is an improvement over the current grammar than to just catch up to it. This is why I wanted to fix the &-sigil declaration 13:52
Now I see that it works the same way as the old grammar but I have no idea what the modification was
and the way it works in the old grammar is still kind of wrong, it doesn't account for typing with the default value 13:53
so my Int &foo will have the value (Callable), even though it could (and should) be (Callable[Int])
lizmat well... the legacy grammar is a source of inspiration in almost all cases 13:54
so some bugs *will* have been ported that way as well 13:55
now, if you can fix the Int &foo case in RakuAST, that would be a good thing
so if you feel you'd want to sink your teeth in that, by all means!
13:56 razetime left
nemokosch oh, my mistake, & declarations still don't work well 13:56
well, then I guess I can't ask how you nailed the resolution of Callable 13:57
or this other thing. I know it's not measurable progress but I think it's a pretty essential question whether RakuAST incorporates semantic elements or not, back to thunkiness 13:59
thunkiness is not visible syntax and it would be good to make it transparent so that users can define things like that on their own; after all, that's almost literally a kind of macro 14:00
lizmat well, e.g. "a","b" is handled as a an infix in the grammar
well, thinking on that, the problem is that we don't have syntax for indicating that an argument should be evaluated *before* other arguments 14:02
that's why we don't have an "infix:<||>" or "infix:<??>" with the correct short-cicuiting syntax
I wonder if we could introduce a trait "is shortcut" 14:03
nemokosch yes, that's true. But then it could be that I don't know what RakuAST is meant to serve as. I thought it was meant to be an AST, both in the sense that it's only based on parsing syntax, and in the sense that it will be used for generating the actual bytecode
given such an AST, I would think that the nodes are traversed (at least hit) from root to leaves and when you visit a root node, you could investigate how the subtrees need to be handled 14:04
and therefore it wouldn't be late to thunkify one subtree
lizmat sub infix:<&&>($a is shortcut({ return False unless $a }), $b) { $b } 14:05
sub infix:<&&>($a is shortcut({ return $a unless $a }), $b) { $b } 14:06
*shortcircuit
nemokosch this is also a part of the complexity. There are several compiler phases that do several steps, it's not the kind of topic you just read a couple of pages about - and there is quite little substance on it anyway 14:07
lizmat well, in a lot of ways we're bleeding edge in compiler development, using a grammar to create a compiler to run the grammar to compile code 14:09
nemokosch or another thing with a high-level AST. Once you have such a thing and start to investigate the semantics of the nodes, you can do immense amounts of optimization, relatively easily. A lot of dead-code removal possibilities there. However, if you always do that at runtime, it will hit back heavily, so it would be good to move more towards the compiled nature, and have some more stable ABI for precompiled stuff 14:10
lizmat "the semantics of the nodes, you can do immense amounts of optimization, relatively easily" that was one of the reasons for RakuAST in the first place
it's the intent that static optimization will happen at CHECK time, or in a dedicated phaser 14:11
constant folding should be done with the .literalize method 14:12
*could
nemokosch I imagine it as something similar to the gcc -O flag. Some optimizations might take some time to catch, like you need to traverse the tree deep, multiple times. If the only/predominant use-case is that "CHECK time" happens "when I want to run the program", that may not be worth it. However, if you can do it once and then run the optimized program as many times as you wish, that's a much better investment 14:16
lizmat that's why we haz precompilation :-) 14:17
nemokosch well, better than nothing at all but a lot of things need to click for it to work as things stand. It's not really persistent or portable, doesn't work for standalone scripts, doesn't work with use lib ... 14:19
it's not really what I would think of when I hear about this option, and maybe I'm not alone with that... 14:20
the common theme is that these ambitious and motivating goals require a lot of planning and collaboration is inevitable because it won't just affect a couple of people 14:22
anyways, let's be less vague; I'm going to look up this operator thunkiness situation 14:24
lizmat please :-)
nemokosch so that I can at least ask a technical question about it :DD
lizmat :-) 14:29
14:39 jpn left 14:47 jpn joined 14:54 razetime joined 15:26 Sgeo joined
nemokosch damn, there are just so many IMPL-THIS-AND-THAT methods... 15:37
anyway, the infix does something similar to what I'm thinking of, except not with the output bytecode but with the RakuAST structure... 15:38
by the way, what's the apparent infix with and without operator? 15:40
cue github.com/rakudo/rakudo/blob/66d5...kumod#L202
lizmat feels more like condition-modifier handling ? 15:47
nemokosch can be but what is it doing among infix operators? 15:48
lizmat I haz no idea
nemokosch nine did this bit 15:51
lizmat that doesn't necessarily mean much if the legacy grammar / actions did the same
nemokosch "with and without will probably need special handling, along with metaoperators"
what does PERFORM-BEGIN produce? 15:52
lizmat an object that does the RakuAST::BeginTime role needs to supply a PERFORM-BEGIN method 16:00
16:00 jpn left
nemokosch well, this is an example for what I miss... For the RakuAST grammar, PERFORM-BEGIN seems to be a very important method. I must assume it still produces some RakuAST structure but it would really make a difference to have some documentation that you can at least grep 16:00
lizmat it doesn't produce anything
it needs to do whatever is necessary for that object at BEGIN time 16:01
basically, if a class does RakuAST::BeginTime
it means that it needs to do something at BEGIN time
all of the PERFORM-xxx methods are basically callbacks being called at some point during compilation 16:02
e.g. PERFORM-CHECK methods are being called during the CHECK phaser phase
*at CHECK time
nemokosch well, then this thunking of expressions within an infix operator happens at BEGIN time, in such a callback 16:09
that's quite a heavyweight unstructured intervention
lizmat anything that needs special grammar handling, is probably pretty unstructured 16:11
and ad-hoc
because there is currently no way to indicate thunkiness in args
nemokosch what is the phase when the RakuAST structure is ready and QAST emission may start?
lizmat after the CHECK phase 16:12
when method RakuAST::CompUnit.IMPL-TO-QAST-COMP-UNIT is called 16:14
I think :-)
nemokosch so yeah... if it was up to me, I would rather push that whole IMPL-THUNK-XXX macroverse into the corresponding IMPL-QAST-XXX method 16:16
lizmat nine 16:17
sadly nine is on holiday atm... he'd probably lecture us about the timing of actions :-) 16:18
nemokosch there is also IMPL-CHECK
PERFORM-BEGIN on one node can fire off IMPL-CHECK on another
I mean, apparently
lizmat I think the IMPL-CHECK method is the actual CHECK phaser handling ? 16:20
that's the whole thing about phasers:
m: INIT { say "running"; CHECK { BEGIN say "compiling"; say "checking" } 16:21
camelia compiling
===SORRY!=== Error while compiling <tmp>
Missing block
at <tmp>:1
------> BEGIN say "compiling"; say "checking" }⏏<EOL>
expecting any of:
postfix
statement end
lizmat m: INIT { say "running"; CHECK { BEGIN say "compiling"; say "checking" } }
camelia compiling
checking
running
lizmat m: INIT { say "running"; CHECK { BEGIN { say "compiling"; END say "the end" } say "checking" } } 16:22
camelia compiling
===SORRY!=== Error while compiling <tmp>
Strange text after block (missing semicolon or comma?)
at <tmp>:1
------> N { say "compiling"; END say "the end" }⏏ say "checking" } }
expecting any of:
infix
…
lizmat m: INIT { say "running"; CHECK { BEGIN { say "compiling"; END say "the end" }; say "checking" } }
camelia compiling
checking
running
the end
lizmat note the END phaser inside the BEGIN phaser ?
anyways, it feels this is getting rather too technical for #raku, maybe move this to #raku-dev ? 16:23
nemokosch sure 16:24
[Coke] can someone construct a bisectable to get github.com/jonathanstowe/META6/issues/30 ? 16:33
lizmat I thought we already had a bisect on that 16:34
?
[Coke] wasnt that the unmarshal bug?
there was no ticket on META6 repo until I just opened one yesterday, failure I got after the unmarshal fix was merged.
lizmat vrurg ? 16:35
[Coke] (I'm trying to stay on bleed, building with rakudobrew, this was the latest failure when trying to install my repo's deps)
m: my $v = Version.new("6.*"); say Version.new($v.parts.join(".")).Str 16:36
camelia 6.e.PREVIEW
[Coke] Apparently that used to return just 6.*
lizmat he,,, well, that would have been incorrect 16:37
[Coke] m: my $v = Version.new("6.c"); say Version.new($v.parts.join(".")).Str
camelia 6.c
lizmat confirmed it isn't installable
[Coke] so if that's a bug in META6, need a new release on that before the next rakudo release, at least (sooner the better) 16:38
lizmat my understanding was that some module would need an update,
not sure which one, only that Jonathan Stowe would do it ?
16:41 tea3po joined
[Coke] Again, I thought that was relating to the previous bug, and he seemed surprised by this report. 16:42
16:45 teatwo left
lizmat it wasn't 73d07b4b58c804d1bbd161b 16:48
hmmm... maybe 4f07e0e1a9280595c9a7 16:49
16:50 linkable6_ left 16:53 linkable6 joined
lizmat [Coke]: testing a fix now 16:53
[Coke]: github.com/rakudo/rakudo/commit/8e394fad08 17:01
dinner&
17:03 dakkar left 17:08 rf joined, razetime left 17:15 eroux left
[Coke] lizmat: that did it, thanks! 17:21
unfortunately, I now have github.com/jonathanstowe/Test-META/issues/43 17:25
17:26 jpn joined 17:31 hellwolf left 17:36 jpn left 17:37 jpn joined 17:43 jpn left 17:45 elcaro left, elcaro joined
lizmat meh, the name of the failing test does not spell well 17:53
17:59 dutchie_ joined, dutchie left 18:00 reportable6 left 18:01 bigdata joined 18:02 reportable6 joined 18:20 dutchie_ is now known as dutchie 18:27 rf left
SmokeMachine Having a way to implemente alternatives to && and || would be great!!! :) 18:43
18:49 jpn joined 18:54 jpn left
antononcube @SmokeMachine Do you have any alternatives (I assume tokens) in mind? 20:03
20:27 jpn joined, jjido joined 21:02 rf joined 21:24 bigdata left 21:26 sena_kun left 21:52 swaggboi left 21:53 jpn left 22:18 jjido left 22:34 jjido joined 23:08 jjido left 23:36 swaggboi 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!