00:06 lichtkind left 00:33 leont left 04:22 leont joined 06:03 leont left 07:10 JJMerelo joined 07:46 JJMerelo left 07:57 patrickb joined
patrickb ping rba 08:27
tellable6 2020-06-04T08:00:39Z #raku-dev <JJMerelo> patrickb what's with these pipeline errors? dev.azure.com/Rakudo/rakudo/_build...02&l=9
hey patrickb, you have a message: gist.github.com/4ce7bdbd860ccd5eb0...ead9e89ef4
hey patrickb, you have a message: gist.github.com/d777c37435c55702ba...9ef831467e
08:56 sena_kun joined
patrickb o/ 09:14
So I have this set of PRs (MoarVM, NQP, rakudo, doc and roast) that depend on each other. Especially rakudo and MoarVM will each break without their counterpart. Is there anything to look out for when merging except for also bumping the rev files? 09:16
lizmat nope, doing them in order is important :-) 09:22
AlexDaniel sena_kun: just move November here: github.com/Raku/Blin/blob/7d81839a...lin.p6#L45 09:23
sena_kun AlexDaniel, that's another option, but I don't mean seeing it once in a while because it indicates we still have a bug somewhere... Somewhere. 09:25
MasterDuke patrickb: i like to do moarvm, then add a commit to the nqp pr with a bump, and `git rebase -i` to move it first, and then rinse and repeat for the rakudo pr
sena_kun oops, s/mean/mind/
patrickb MasterDuke: That's what I'm doing right now. Except for the reordering, as I have a bidirectional dependency so the order is irrelevant wrt not breaking. 09:27
MasterDuke cool. and yeah, my method is not a requirement, just my usual workflow 09:28
patrickb MasterDuke: It's been my workflow for quite some time as well. :-)
Geth_ nqp: be561a1576 | (Patrick Böker)++ | src/vm/js/nqp-runtime/io.js
Always handle proc exec arguments verbatim on JS

Together with a change in rakudo this fixes Raku/problem-solving#20.		 09:29
nqp: 0604ccb4f3 | (Patrick Böker)++ | tools/templates/MOAR_REVISION
Bump MoarMV for the Windows argument quoting change

This is a prerequisite for a related upcoming Rakudo change.
nqp: db4395b5b0 | (Patrick Böker)++ (committed using GitHub Web editor) | 2 files
Merge pull request #610 from patrickbkr/problem-solving20

Always handle proc exec arguments verbatim on JS
rakudo: 709941c6b7 | (Patrick Böker)++ | 2 files
Implement verbatim arg handling in Proc

This solves Raku/problem-solving#20.		 09:31
rakudo: 61a39f356b | (Patrick Böker)++ | tools/templates/NQP_REVISION
Bump NQP for Windows argument quoting changes

These are a requirement for the respective changes in rakudo to work.
rakudo: fc9df315a2 | (Patrick Böker)++ (committed using GitHub Web editor) | 3 files
Merge pull request #3576 from patrickbkr/problem-solving20

Implement verbatim arg handling in Proc
roast: 09550709bb | (Patrick Böker)++ | 2 files
Add tests for Windows specific Proc argument quoting
 09:32
roast: ce28dec228 | (Patrick Böker)++ (committed using GitHub Web editor) | 2 files
Merge pull request #636 from patrickbkr/problem-solving20

Add tests for Windows specific Proc argument quoting. The respective implementation is merged already.
patrickb Shall I also merge the matching `doc` changes even though these didn't make it into a release yet? 09:33
sena_kun patrickb, why so? 09:34
Or, hmm.
I can argue it either way, but it's better to wait, IMO.
patrickb People might read docs.raku.org and stuff will not work. On the other hand it feels good to merge the whole bunch at once. As you said, can argue either way. 09:35
lizmat docs would need to mention "from a release" anyway, so if your doc update does that, then there is no problem merging it now 09:36
Files=1306, Tests=111378, 214 wallclock secs (29.15 usr 7.74 sys + 3016.21 cusr 261.55 csys = 3314.65 CPU) 09:39
before patrickb++ merge ^^ 09:40
09:41 leont joined 10:10 Altai-man_ joined
jnthn nine: So I decided earlier this week that I'd try and get a RakuAST-using compiler up and running before doing a load more nodes, in that it'd be kind of fun to do it by working my way through sanity tests etc. And of course am now realizing that this means thinking through some of the bits you're looking at. 10:10
(There's also the innevitable bit of CDD in here: would be nice to have something to show off in my CiC talk... :)) 10:12
10:12 sena_kun left
jnthn One of the nice things about the serialization context is that it's got a lifetime that transcends an individual batch of bytecode we send off to MoarVM; I'm wondering what the code/lexical scopes view of that looks like. 10:15
nine I've been thinking a bit more about the All The Things block as well. Seems to me like all that's needed is for the compiler to include the outer compiler's lexpad as well when looking for lexicals. Maybe if one is found, we still need to put it into the wrapper frame, so the value is available when running the code. But that's on-demand rather than up-front. 10:26
s/lexpad/lexpads/
jnthn nine: I was kinda thinking about something where we have have "unfinished" frames registered with the VM, and lexical lookups that cross the boundary into one of those would potentially trigger a code callback 10:28
(such late-bound lookups would be compiled into a different op) 10:29
10:30 JJMerelo joined
jnthn (it's lexical, so we know what is what...) 10:30
JJMerelo Can someone who is owner of raku-community-modules give acces to travis-ci.com? 10:31
nine That would of course make sense. I just wonder if the complexity is necessary. I don't think the wrapper frame is bad in itself, it's just the up front filling with all known lexicals that is. So, are there cases where the wrapper frame cannot work? Closures maybe? Where we really need the runtime to understand this? 10:32
JJMerelo ... or give enough access so that I can do it
jnthn nine: Also that we have some model of a lexical scope that isn't an MVMFrame, but more late-bound, but come the point we actually finish the compilation and produce bytecode, they all have to be resolved into something that serializes like the outer context could
nine: If the BEGIN does an EVAL, I think all bets are off... 10:33
I think the wrapper frame actually *is* bad, because we're effecitvely telling lies about our outer chain 10:34
And they keep catching up with us
JJMerelo ... meanwhile I'll keep using travis-ci.org, for which apparently I have permission.
jnthn JJMerelo: Hopefully done 10:35
JJMerelo jnthn thanks!
nine Ok, then there's no sense in thinking about solutions involving that wrapper frame.
jnthn And I fear with what I want to do, the lies are turning into whoppers... :) 10:36
For example, I'd like to try and interpret role bodies in the common case
So in that case a scope comes to be for something we never created bytecode for 10:37
As well as closure clones of all the methods, which we'd also not have compiled the bytecode for yet
nine Looks to me like we have a compiler with some bolted on ability to finish compiling parts of the code early and running them. Works for limited cases but will run into issues quickly. Maybe we need a bit of a shift in mindset.
Instead of BEGIN stuff and EVAL being those nasty special things, we should consider the situation normal, that at any point we have multiple nested compilations going on with outer stuff still in limbo and judge any solution against this picutre. 10:38
jnthn Exactly. 10:39
nine Because....having a role body do a BEGIN EVAL which creates a sub that has a trait is actually not that contrived an example 10:40
jnthn I mean, we have a quite traditional compilation model at the moment in terms of the compiler/VM relationship, and then we try and do all of this tradition-busting stuff atop of it. We've done pretty well given that, but...it feels like we're having to fight it. 10:42
nine So it's normal that a lexical lookup can end up in a frame that's not compiled yet. A frame that on the runtime's side e.g. is just a stub?
jnthn Yes, I think the runtime needs to have some awareness of WIP static frames and WIP frames. 10:43
nine I've fought it for weeks and weeks now :) I would much prefer to cooperate
jnthn Yes, your suffering was informative... :)
nine So we need to tell the runtime that these frames will exist. This kinda ties into something I've also thought: the linear separation of stages might be a bit of an oversimplification. 10:44
jnthn Yup. This also ties into my "MoarVM should focus more on interpreter cooperation" quip. 10:45
nine Currently I have a start stage in the MoarVM backend that initializes some stuff, but that's not a proper solution as compilation may start with a later stage (in case we already have a QAST).
Feels like front- and backend should cooperate some more with both getting initialized early
In which case we could create MAST::Frames at the same time we create the QAST::Block (or whatever it will be in the future) 10:46
jnthn Yes, much like we have an SC that we add to over time, I think we need a similar thing for a compilation unit.
nine Which gets the information one step closer to the runtime already
More concurrency of these stages and closer ties between compiler and runtime also fit nicely with the re-imagining of spesh 10:47
jnthn Not quite sure on the MAST::Frame front, but there needs to be *something* that exists ("frame handle"?) that, at the point we do decide to produce bytecode, is involved with it. 10:48
nine Yeah, whatever it's going to be. I'd just start with an almost empty MAST::Frame that gets filled with values over time. Maybe it works out, maybe we need something different 10:49
And keeping with the new mindset: no code is safe from getting run at BEGIN time. After all BEGIN time code may call any sub or method. So allocating frame handles for all blocks by default makes sense. 10:51
jnthn I think in some cases there might not be a MAST::Frame at all. I mean, if you write a BEGIN block or an EVAL that is super simple (e.g. a BEGIN that just does a mixin or some other MOP call), we might not ever bother producing bytecode. 10:53
nine A possible generalization here is: since we'll have stubs for lexicals with callbacks for getting values, the same mechanism could be used for code objects. No need to treat them specially.
jnthn I guess new-disp is about saying "well, actually, let's just keep dispatch knowledge out of the VM but expose to the VM the things it needs to know to go fast", and I wonder if we need such a revolution for frames/scopes too. 10:55
nine Can we actually get away with that? Maybe not so much in precompilation mode
jnthn I guess there's 3 concepts we want to expand the lifetime/workflow of; to use the MoarVM terms for them: compilation units, static frames, and frames 10:59
Keeping the last two apart is almost certainly really important 11:01
It's the class/object style distinction
nine Yep, it's e.g. for locals one where you have the information on which slots are there and the other which has the values for them 11:04
Do we have any information on nested compilation units now that you mention them? 11:05
I think they are only really linked at the frame level 11:06
jnthn Those aren't modeled at the VM level at all
That's part of the problem really
We don't actually want to have them
nine we don't? 11:07
jnthn A BEGIN doing an EVAL doing a BEGIN doing an EVAL all really are part of the same (Raku level) compilation unit, which we expect to produce one bytecode file from
nine True. What I've really been doing the hard way is finding out which things really belong to the outer most compilation unit and which parts we need to keep locally. 11:08
Or as I discovered again yesterday: which parts need to be kept locally but added to the outer compilation unit later on 11:09
The result being that almost everything will land in the outer most comp unit 11:17
rba patrickb: pong 11:46
12:10 sena_kun joined 12:12 Altai-man_ left
Geth_ rakudo: e1cefecc92 | (Elizabeth Mattijsen)++ | 331 files
Unify all # vim lines

to '# vim: expandtab sw=4', aka lose the reference to perl6. Let people configure their own syntax highlighter for their situation. But indicate we want expanded tabs with 4 spaces.		 12:17
12:25 AlexDaniel left
patrickb rba: I'll have lunch now, back in an hour. Do you have a little time later today? I'd like to do something about the SSL rakubrew.org issue... 12:31
Geth_ rakudo/rakuast: 2bca5d113e | (Jonathan Worthington)++ | 5 files
Reorganize AST EVAL workflow

In support of having a RakuAST-based compiler as well as AST EVAL.
  * We now always wrap the AST node into a compilation unit, making sure
   that it's something that makes sense as a top-level thing to evaluate
   (following the general principle of using the type system to model
... (5 more lines)
rba patrickb: Sure. All fine. Everything is going on at the same time ;-)
12:32 Kaeipi left 12:34 Kaiepi joined 12:59 JJMerelo left 13:04 AlexDaniel joined, AlexDaniel left, AlexDaniel joined
nine So...I now know that I have to start compilation with an empty @!load_dependency_tasks and add those to the outer compiler's list at the end. This sounds like the most trivial things to do. But for 20 minutes I'm now sitting here without a good idea where exactly to put this. 13:42
It's like the World object has access to those tasks but doesn't know when compilation ends. And the compiler's driving loop doesn't actually have access to the World object as that gets created by a grammar 13:43
Geth_ rakudo/rakuast: db5f10e270 | (Jonathan Worthington)++ | 5 files
Piece together enough to compile an empty file

That is, `RAKUDO_RAKUAST=1 ./rakudo-m -e ''` now completes without error.		 13:55
nine Holy crap! It finally makes it through rakudo installation and passes Inline::Perl5's precompiled raku block tests :) 14:07
jnthn Wow!
nine++
14:10 Altai-man_ joined 14:12 leont left, sena_kun left 14:17 leont joined
patrickb rba: I'm available now. 14:27
timotimo cool 14:46
15:13 JJMerelo joined 15:35 Altai-man_ left 15:36 sena_kun joined
Geth_ rakudo/rakuast: ca57776839 | (Jonathan Worthington)++ | 5 files
Get basic setting loading in place
 15:48
rakudo/rakuast: c727635378 | (Jonathan Worthington)++ | 3 files
Move RakuAST::CompUnit to its own file
16:00 JJMerelo left 16:10 Altai-man_ joined 16:12 sena_kun left
Geth_ rakudo/rakuast: 7f2d604a63 | (Jonathan Worthington)++ | 3 files
Wire up enough to be able to compile `say(42)`

Using existing RakuAST nodes, plus a stubbed in literals table class. We cheat heavily on many of the grammar rules for the moment.		 16:15
jnthn This is curious. `time ./rakudo-m -e 'say(42)'` comes out at 0.105s. `time RAKUDO_RAKUAST=1 ./rakudo-m -e 'say(42)'` comes out at 0.067s. 16:16
What I don't know is how much of that comes from my grammar being way simpler for now (this won't stay the case) and how much is 'cus we don't iterate and make stub QAST nodes for every top-level CORE.setting symbol (this will stay the case). 16:17
So don't get too excited yet. 16:18
[Coke] still, good to start there and not twice as slow. :) 16:22
Geth_ rakudo/rakuast: bcc7041e47 | (Jonathan Worthington)++ | tools/templates/Makefile-backend-common.in
Make sure we invoke NQP properly in the build
 16:31
rakudo/rakuast: 1b2121e133 | (Jonathan Worthington)++ | src/Raku/ast/resolver.rakumod
Fix a comment; MasterDuke++
 16:35
rakudo/rakuast: 181ec2df88 | (Jonathan Worthington)++ | 2 files
Add precedence table and a bunch of infixes
 17:00
jnthn oh dammit, the moment I think "time to go home" I hear it start hammering it down outside... 17:02
timotimo whoops 17:06
jnthn Though it seems to have already stopped...
At least I have a vaguely waterproof jacket with me
home & o/ 17:11
Altai-man_ o/ 17:12
Kaiepi bastille% raku -e 'use v6.e.PREVIEW; say await $*RESOLVER.query: "www.google.com", T_A, C_IN' 17:16
(142.250.64.100)
got async dns queries working
patrickb rba: ping
rba patrickb: yes sir 17:19
patrickb Hey! :-)
rba I can fix the ssl cert. Yet I have to think more how to avoid it 3 months... 17:21
patrickb What can we do to fix rakbrew.org?
The difficulty is that it's separate servers, right?
Boiling down to the "How do we sync the servers?" problem we brainstormed about a while ago? 17:22
rba patrickb: Yes, I guess so. 17:24
Give me another hour. Will copy the working cert later today... 17:25
patrickb rba: That was the brainstorming discussion: colabti.org/irclogger/irclogger_lo...02-14#l169 17:38
The essence of that discussion was: If and only if the simple solution doesn't suffice, go for the complex solution. So just use rsync. 17:42
For the static files.
18:07 lichtkind joined 18:11 sena_kun joined 18:13 Altai-man_ left
rba patrickb: certificates are in sync now. fixing it longterm is done another time. 18:51
patrickb rba: Nice! Ping me if you need help with the long term solution.
rba patrickb: will do :-) 18:52
nine Kaiepi: cool! 19:08
19:24 MasterDuke left 20:10 Altai-man_ joined 20:12 sena_kun left 20:29 Kaiepi left 21:05 patrickb left
Geth_ rakudo: d984e7c24d | (Elizabeth Mattijsen)++ | 3 files
Consistify Rakudo::Iterator.Pairs

No functional change		 21:16
22:11 sena_kun joined 22:12 Altai-man_ left 22:26 leont left 22:57 MasterDuke joined 22:59 lichtkind left
Geth_ rakudo: bf01f84545 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Introduce Rakudo::Iterator.Truthy

Not used yet, but will be used for .split(:skip-empty) functionality and possibly other situations		 23:14
rakudo: da9943a417 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Introduce Rakudo::Iterator.MatchCursor

Given a regex, a string and a way of moving the cursor (:g, :ov, :ex) create an iterator producing the cursors. Future workhorse of all iterators that are based on regular expressions, such as .split and .comb.
Not used yet.
rakudo: 150af9a2d3 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Introduce Rakudo::Iterator.MatchCursorLimit

Given a regex, a string, a integer limit and a way of moving the cursor
  (:g, :ov, :ex) create an iterator producing the cursors. Future workhorse
of all iterators that are based on regular expressions with a limit, such as .split and .comb.
Not used yet.
Also removed the specific push-all for MatchCursor, it will not be needed.
lizmat sleep& 23:22
Geth_ rakudo/rakuast: e3eb15a56c | (Jonathan Worthington)++ | 2 files
Compile some basic prefix/postfix ops to RakuAST

Also preparing the way for all the meta-op stuff, although those aren't yet part of the RakuAST model.		 23:39

Powered by Cro and the Raku® Programming Language.

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

Thank you!