weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today
Set by moderator on 20 September 2010.
04:45 ash_ left 17:11 ash_ joined 17:59 ash_ left
moritz_ prepasting report, because I can: 18:13
* worked a lot on the book; would like to encourage others to contribute too
* worked on the backtrace printer, simplified it in one case, made it smarter about warnings
* cut the compiler release 18:14
* implemented a basic version of require
* a few doc improvements
.EOR
18:39 masak joined 18:46 masak left 18:47 masak joined, masak left 18:57 masak joined, masak left 18:58 masak joined
Util Pre-pasting report, because #parrotsketch has the right idea. 18:59
* Posted 2 more Perl 6 solutions to RosettaCode tasks: Topological_sort and Equilibrium_index = also translated Ruby solution of Sudoku task into Perl 6, but am not happy with it yet.
* Gave a Perl 6 talk at Atlanta.pm = Rationals = .perl & :pairs vs p5's Data::Dumper = meta-operators ( X Z Xop Zop, [op] ). 19:00
.end
(trying again)
Pre-pasting report, because #parrotsketch has the right idea.
* Posted 2 more Perl 6 solutions to RosettaCode tasks: Topological_sort and Equilibrium_index
= also translated Ruby solution of Sudoku task into Perl 6, but am not happy with it yet.
* Gave a Perl 6 talk at Atlanta.pm
= Rationals
= .perl&:pairs vs p5's Data::Dumper
= meta-operators ( X Z Xop Zop, [op] ).
.end
moritz_ Util++
pmichaud My report, and then I have to (alas) depart on some errands: 19:01
* Some minor bugfixes and code explorations
* I'm still working on getting feedback on cpan6 design details -- will report next week.
19:01 ash_ joined
pmichaud * Will cut the next R* release later today 19:01
EOR
afk for about 30 mins 19:02
moritz_ and now it's #phasers time! 19:03
masak seems the meeting has begun now.
moritz_ jnthn? masak? sorear? any reports?
sorear Hello moritz_
19:03 diakopter joined
moritz_ (non-rakudo reports are also welcome) 19:03
masak not much here. I've been present, but haven't done anything of note. 19:04
jnthn writing my report, ready in a moment :-)
sorear niecza/mm is right about ready to merge
jnthn someone else can go while I finish typing :-)
sorear niecza is now generating meta-objects at compile time, mostly, instead of generating a giant BEGIN/PRE-INIT sub 19:05
19:05 colomon joined
sorear (ok we still make a giant sub to thaw the objects :/) 19:05
moritz_ \\o colomon 19:08
colomon o/
guess I can report quickly while we wait on jnthn. 19:09
moritz_ +1
colomon basically vacationed and got a cold. 19:10
I've been working on getting the ABC module to actually do something useful.
sorear just broke the $*FOO test, so the merge isn't likely to happen *right now*
colomon adding actions to the parser, etc.
sorear What is ABC supposed to do?
colomon generated some blog posts on it, will generate some more as soon as I have the tuits, I'm very eager to accomplish something here.
sorear: ABC is a simple music notation. 19:11
I'm working on getting the grammar to translate from ABC notation to Lilypond's music handling. 19:12
s/handling/notation/
so in terms of perl 6, it's just something interesting to me implemented in perl 6 19:13
sorear I see.
colomon learning my way around writing actions for a grammar, getting practical experience writing roles, etc.
jnthn ready, btw
colomon .eor
jnthn colomon: Get well soon! 19:14
moritz_ jnthn: go ahead then
jnthn Last week
* Gave 6model on .Net support for attribute storage (get and bind)
* Finished porting all the representations I'll need for now to Parrot's 6model implementation
* Filled out the KnowHOW much more in the Parrot implementation
* Ported many of the JnthnNQP changes into nqp-rx
* knowhow Foo { ... } stuff now works
* Got attributes working on 6model on Parrot impl too.
* Was quite nice to run the same code snippet on Parrot and .Net, both compiled (well, one cross-compiled) through NQP and using two implementations of the same meta-model design. :-)
* Started to stub in ClassHOW
* Got some thinking time on how natively typed attributes and stuff could look, dynamic method caching techniques, etc.
This week
* Focus on getting to a basically functional ClassHOW on nqp-rx
* Try switching NQP's class keyword to use it, and start dealing with the fallout
* Try and get multi-dispatch stuff prototyped in the .Net implementation
Blockers
* Broken body clock due to doing lots of on-site work at the moment. "Patches welcome." ;-)
* Brain cycles - the coding is pretty easy, most of the time...
END
moritz_ colomon.health++ 19:15
colomon++
jnthn++ 19:16
sorear++
moritz_ has one thing to discuss
currently it feels rather lonely to hack on the book
colomon let's not forget moritz_++, as he seems to be the main rakudo commiter at the moment. :)
moritz_ sometimes people read through it, and complain that things aren't explained well 19:17
which is great
but it seems that often I'm the only one working on actually fixing it
so, what can we do about it?
sorear * niecza/mm is now merged.
Util I can tackle more of the "things that aren't explained well" 19:18
moritz_ ++Util
colomon moritz_: do we have some sort of list of what needs to be done on the book?
sorear pmichaud: Did anything become of your plot to contact obra, scwern, Alias?
masak moritz_: I have a fair number of things to contribute, but somehow I've never gotten around to starting.
moritz_: there was a point at which I couldn't build the book any more, and my contributions dropped off after that. 19:19
moritz_ colomon: there's a bug tracker on github, and some TODOs in the code
Util colomon: github.com/perl6/book/issues
masak I guess I should start by trying to make the book build locally again...
apologies for the lags at my end.
moritz_ mostly considers the .pod files onlz 19:20
jnthn moritz_: I paid attention to the subs-n-sigs chapter tickets, but didn't get to fix them yet. Mostly it's trying to fit it in amongst everything else. I'll try and at least commit *something* this week.
moritz_ *only
masak moritz_: that works fine for some of the changes I have in mind.
moritz_: as the book nears 100% ready, though, the rendered aspects of it become increasingly important.
moritz_ masak: I consider rendering aspects mostly the job of our publisher 19:21
at least the finer points
masak be that as it may -- I looked over the book last weekend and found I had tens of minor things I could improve about the book pdf. 19:22
it's mostly a matter of finding the time to do it.
colomon Util: those seem to be mostly "bugs" -- I was thinking more of sections that still need to be written... 19:23
moritz_ anyway, it's good to get some positive feedback
colomon: we need a section on statements
colomon moritz_: for what it's worth, I've been using the book while working on the ABC project. :) 19:24
masak for what it's worth, I still consider the book at most half-way done, in terms of work.
colomon it's been helpful.
19:25 ash_ left
colomon hmmm.... should we set some sort of goal for the next Rakudo release? I mean, more than "fix whatever random bits we can"? 19:25
moritz_ masak: I agree :(
colomon: you mean book goals for the rakudo release?
colomon I meant rakudo goals -- wanted to get the thought in before my cold-adled brain wandered off -- but book goals would be good too, I guess. 19:26
masak moritz_: from the bright side, I see a lot of good work being done on it that I didn't expect. 19:27
moritz_: I am impressed by what you've contributed so far, and I'll try my best to make your efforts less lonely :)
moritz_ :-)
colomon: I'm currently in a phase of increasing meatspace stress, so any goals we set would be highly speculative from my side - I don't know if there's a benefit in definining them 19:28
masak I do think there's a benefit in setting goals, even if we don't meet all of them. 19:29
colomon moritz_: it just feels a bit to me like we were much more focused when we were working for the first R* release. Understandable to rest a bit after that, but it feels to me like we need something to carry forward.
jnthn From my side, I think that the sooner the new meta-model stuff lands, the better. 19:30
colomon moritz_: of course, you're doing pretty well moving forward yourself. it's the rest of us (especially me) I'm worried about. :)
moritz_ colomon: I've pretty much always worked on random stuff just within my reach
jnthn Thus, I'm focusing the Perl 6 part of my attention span pretty much fully on that.
moritz_ colomon: but if you want some goals, we should find some 19:31
jnthn That *is* going to mean I'm less visibly active in the stuff that lives in the Rakudo repo.
For now, anyway. :-)
sorear Unexpectedly, niecza/mm seems to be much faster
colomon jnthn: sure, you and sorear are both being amazingly productive elsewhere. :)
masak hm. thinking out loud: it'd be nice to have a file somewhere marking for each chapter the perceived "done-ness" of that chapter: how well it covers its topic, how well-reviewed it is, how well-polished it is.
then we'd have a central place to go to for the "status" of the book.
sorear STD.pm6 is back to being 90+% of runtime
19:32 ash_ joined
jnthn colomon: Aye, but the aim is that this all joins up with Rakudo in the not too distant future. :-) 19:32
Well, the bits I'm doing, anyways. :-)
masak also, it'd have the psychological benefit of putting a concrete number on something quite nebulous.
colomon masak: +1
jnthn sorear: Faster is good. \\o/
moritz_ masak: +2
jnthn masak: +1 19:33
masak optionally, people can sign up for specific tasks of making the book better in small ways.
sorear niecza/mm is now merged and passing all 520 remaining tests
masak think Advent Calendar success.
ok, I volunteer to commit a skeleton for such a file. 19:34
ash_ btw, the framework for try.rakudo.org tutorials is setup and i am sorta hacking on it when i have time, but anyone that wants to help is welcome to
masak ash_++
ash_: try.rakudo.org is very long-term important. you're a hero. 19:35
ash_ i'll work on them some when i have time, but currently school has me swamped, and i need to get my GSoC parrot NCI changes merged into trunk eventually (i just need to write tests for my code)
Util ash_: I mentioned try.rakudo.org in my talk. Monger: "that only works for one-liners, right?" Util types multi-statement example into actual website; "Nope!". Crowd: Ooos and Ahhs. ash_++ 19:38
ash_ lol, not all of those are guaranteed to work, since it is the real repl 19:39
masak that implication arrow did not make sense to me. 19:41
but nevermind.
Util moritz_: .pdf snapshot to be updated on github.../downloads soon?
moritz_ Util: I can do that tonight, if there's demand 19:42
Util Just noticed that it is >1 month old.
moritz_ will do 19:51
anything else we need to discuss?
jnthn doesn't have anything
pmichaud back again 19:52
masak the enums patch went in, but in a significantly less effective form than I originally wrote it. 19:53
maybe #perl6 is a better forum for that, though.
I recently figured out why I felt the need to instantiate the anon class in my original patch. removing that made fewer things work in the current one.
jnthn o/ pmichaud 20:00
pmichaud yes, 2h00 20:06
er, 20h00
jnthn It's about that. 20:07
Is today still good?
pmichaud I either need new keyboards or new fingers or both :-(
diakopter new sprixel -3.0 gained ("gained" over perlesque, at least) nested evaluation environments, which paves the way for nested compilation units, BEGIN, use, etc.
pmichaud sure, today still works out well
we can discuss here, or in #phasers, or wherever you wish :)
oh, we're in #phasers
maybe today isn't so good :-P 20:08
sorear pmichaud: How did your chat with obra, Alias, etc go?
pmichaud sorear: I mentioned earlier that I'm still working on that.
sorear ah
pmichaud I'll report again next week.
jnthn pmichaud: #phasers probably avoids too much noise in #perl6
pmichaud: And means it's logged for the curious. :-) 20:09
pmichaud (I got seriously sidetracked on non-perl6 tasks this last week. On the plus side, I now have some steady income again :)
#phasers is my preference also
jnthn OK, great.
sorear things I'd generally like to persue in niecza in the coming weeks:
colomon steady income++
jnthn pmichaud: That's good to have taken care of. :-) 20:10
sorear * detangle CgOp from the CLR and try to sane-ify the back back end
* gradual typing stuff (vtables etc)
* roles
* multi methods
* bootstrapping
jnthn pmichaud: heh, sorear is kinda listing my roadmap... :-)
<grin>
pmichaud: Maybe best is if I give a quick status update on where I've got so far? 20:11
Then there's some context for what needs to come along next.
pmichaud jnthn: sounds like a good starting point
jnthn OK 20:12
I started out by prototyping a bunch of meta-model stuff in .Net, and wrote enough runtime support around it to actually be able to run some simple NQP programs.
It's turing complete, at least. ;-)
Did a bunch of profiling, re-working (not just performance, but design issues), etc.
A couple of weeks ago I dug into the Parrot port. 20:13
It really has been a fairly direct port in that you can look at the two side by side and see they're just about the same thing, aside from what they build on top of and C vs C#.
In terms of the meta-model primitives, I have the two just about neck and neck now. 20:14
In the model there's essentially three things.
1) Representations. These all implement an API. They're responsible for how we store an object in memory. They'll also play an important part in packed arrays, compact structs, etc. 20:15
The API in the Parrot implementation is mostly the same as in the .Net one apart from the Parrot one has to co-operate with the GC whereas the C# one just gets it thanks to there being no unmanaged parts (yet). 20:16
2) Meta-objects that implement the HOW API (or some subset of it). This has the declarative and introspective bits.
There is one meta-object that is implemented at "low level", which is KnowHOW (HOW being a convention postfix for things you'd get back from a .HOW). 20:17
It just provides a pure prototype-ish thingy. That is, no inheritance - it's completely flat. You could almost see it as a concrete role too I guess. The main thing is that it's easy to implement.
And to bootstrap.
3) Shared Tables. Every object starts with an STable pointer. The rest of the object is under the control of the REPR. We have on STable per (HOW, REPR) pair. 20:18
The STable is also where the v-table will be kept cached to do gradually typed dispatches. 20:19
That's pretty much *it*. Everything else - classes, roles, meta-attributes, etc - can be built on top of this.
I'm pretty much at the "build that stuff" stage now.
sorear Of importance is to note that HOWs are just Perl 6 objects. 20:20
pmichaud this all sounds like exactly where we wanted to be at this stage
jnthn sorear: Correct
sorear In particular, every method call involves a call to .^find-method
jnthn The only thing in this whole design that are not first-class objects are the STable and the representation implementations. 20:21
Everything else is just an object.
diakopter listens keenly
jnthn sorear: Apart from where we cheat thanks to gradual typing optimizations, but yes.
sorear I'm taking niecza in a slight different direction; instantiatable classes are represented using a special type which extends into the C# domain and is about as primitive as Sub
ClassHOW will probably subclass this thing; RoleHOW will be entirely based on normal Perl6 primitives 20:22
jnthn sorear: Does that allow for repr polymorphism, or is that something you're putting aside for the time being?
Oh, I think I mis-understood.
(What you just said about ClassHOW made me understand a bit more what you were thinking.) 20:23
pmichaud: That's pretty much the current state. Any questions before I give you the things I want input on? 20:24
sorear jnthn: I think I'm allowing for repr polymorphism, but I won't really know for sure until #perl6 understands repr polymorphism better
I am thinking that as your work progresses we'll have a better understanding of what features "REPR polymorphism" requires
in particular, once the apps hacking starts
jnthn sorear: fwiw, REPRs aren't really something I expect hardly anyone to write, unlike custom HOWs and stuff which I bet a lot of folks will write. 20:25
pmichaud jnthn: no questions so far
jnthn oh gah, double negatives!
s/aren't/are/ 20:26
pmichaud: OK.
pmichaud: So one of my next steps is going to be to get an implementation of classes written.
e.g. ClassHOW
sorear jnthn: I'd like to see how many people are writing fully custom HOWs
jnthn I'd then switch nqp-rx to compile its class keyword stuff in terms of making calls to this. I currently have both old-model and new-model stuff in the actions.pm, and it chooses by the package declarator (so I didn't break classes when adding knowhow - it seemed a bit more gentle that way :-)). 20:27
sorear I expect most people will be writing roles here and composing them into anonymous ClassHOW subclasses
jnthn sorear: Yes, that'll be the common case, I think. I guess until we give people an implementation where they can write fully custom HOWs, we won't really know. 20:28
sorear (Moose requires all meta objects to be subclasses of Class::MOP::Class and I don't see anyone complaining)
jnthn pmichaud: At that point, I'll hit a migration issue. 20:29
pmichaud: That is, there'll be some things that are inherited from that use P6object. But as you pointed out yesterday, there may be less of those than I first feared (e.g. hardly any).
Should the general approach to be to migrate such things into the nqp-rx repo? 20:30
pmichaud p6object was merely intended to provide a perl6-compatible mop api
afaik, nothing in nqp-rx relies on the inner workings of p6object
if it does, we should replace/fix it
jnthn Well, it's more reliance on Parrot's object model too.
nqp-rx today (not in my nom branch) doesn't ever make an add_method call. 20:31
pmichaud oh, right.
jnthn It relies on Parrot's Class PMC magically slurping things up marked :method.
pmichaud I'm totally fine with switching nqp-rx to work in terms of add_method
instead of relying on the :method compile-time flag.
jnthn OK, phew. :-) 20:32
I'm not quite so sure about the stuff we have that's written in PIR, mind.
I mean, what gets more interesting is when I want to get the grammar package declarator switched over.
Does that have inheritance dependencies outside of the nqp-rx repo?
pmichaud yes, that makes things temporarily slower, by converting what was compile-time to loadinit-time. But I'm expecting to make that up with serialization later anyway.
jnthn Same. 20:33
pmichaud 'grammar' simply means that we inherit from Regex::Cursor, iirc.
jnthn Which is in nqp-rx repo?
pmichaud yes.
src/Regex/Cursor.pir
jnthn And in PIR?
Right.
pmichaud I'm okay with switching those to be written in nqp also.
jnthn How would a first pass involving wrapping Q:PIR inside NQP method declarations sit with you? 20:34
Then the NQP re-write can take place a bit at a time.
Rather than the whole file in one go.
pmichaud I don't have a problem with that.
jnthn OK.
I'm tempted to do that and have a compiler write the boilerplate for me. ;-) 20:35
(rather than write all the add_method calls out in a PIR loadinit...)
pmichaud I'm thinking of something slightly different, though
(still forming in my head -- give me a couple of minutes to chase it down) 20:36
jnthn OK :-)
pmichaud actually, I need a 5-min break to take care of house-things... bbi5
then I have a counter-suggestion or two
jnthn I'll be right here. :-) 20:37
sorear jnthn: How will non-instantiable types work?
jnthn: after role Foo { }, what is Foo? is it defined? does it have a distinct WHAT and HOW?
jnthn sorear: To make sure we're talking about the same thing, what's your definition of "non-instantiable"?
Oh, roles...
Foo is undefined, since it's a type object. 20:38
I think the trick with roles is that whenever you call a method on one, the method dispatcher puns a class and calls it on the pun.
(And caches the pun)
sorear There will never be a defined object whose .WHAT is a role
or a subtype
jnthn Heh...yes. :-) 20:39
sorear that's what I mean by non-instantiatable
jnthn Anyway, for roles the non-instantiability will drop out of the fact that any call to .new (or any other method which may make an instance) will end up re-dispatched to a punned class.
pmichaud back again 20:40
jnthn So RoleName.new never actually tries to end up instantiating the role, but instead is more like (class :: does RoleName { }).new
sorear Do you have any plans for PackageHOW or ModuleHOW?
pmichaud okay, what strikes me about this is how very similar it feels to the nqp-rx rewrite and migration I did last year
jnthn But that anonymous class gets cached in the role meta-object.
pmichaud my guess is that we're going to come up with a completely new nqp-rx that is (mostly) syntactically identical to the one we have now, but has completely reworked internals 20:41
jnthn sorear: I'm still working through exactly what those would look like. My first thought is "yes, but they don't have a great deal of methods", e.g. there's probably a .ver and a .auth... I'd be curious to know what you think on that. 20:42
pmichaud: Yes, that's my feeling too.
pmichaud: Especially so if we're going to also end up with Perl 6 multi-dispatch in it.
pmichaud: And I think we can't *not* have the multi-method dispatch otherwise NQP won't even be able to properly stringify type objects... :/ 20:43
sorear jnthn: S10 thinks that .ver and .auth are methods on the .WHO, not the .HOW
jnthn (e.g. we need multi-dispatch that can distinguish on the :D/:U stuff)
sorear: Hm
sorear which are essentially distinct objects in Niecza, not sure about rakudo
pmichaud oh, we can certainly have the stringify method do its own internal "multi dispatch".
jnthn pmichaud: True.
pmichaud I mean, I do that already for handling autoviv in Rakudo. 20:44
jnthn pmichaud: And ACCEPTS
Yeah
pmichaud So, that's not an absolutely necessity.
jnthn It's a hack though.
pmichaud *absolute
20:44 ash_ left
pmichaud you're correct that it's not as elegant 20:44
jnthn Yeah...I guess if I'm struggling on the multi-dispatch and want to push forwards I can take that route.
sorear pmichaud: Why did adding rx to nqp require a complete rework?
pmichaud sorear: there were a large number of reasons 20:45
sorear: some technical, some other
jnthn pmichaud: Thanks, that's actually a simple but very helpful point. "Why didn't I think of that?" :-)
pmichaud we could even get p6object to do the same hack (and remove the subclassing role) if we felt it was important. 20:46
p6object doesn't absolutely require that its protoobjects be subclassed -- that was just the initial guess at how it would work.
jnthn *nod*
Yeah, but that approach is also what gives the undefinedness. 20:47
pmichaud sorear: the main reason for rewriting nqp-rx from scratch was because pge needed protoregexes, and it was far easier to rewrite that from scratch than to try to fix the existing pge (more)
also I wanted to rewrite pge to make use of PAST
instead of generating code directly 20:48
moritz_ (but don't forge that nqp-rx still misses some PGE features)
pmichaud moritz_: I haven't forgotten that -- but for the most part those features haven't bubbled up to critical need. <Otherclass::regex> is an important exception, I grant. I did figure out a way to resolve that, I think. 20:49
jnthn pmichaud: Given that I basically agree that we're getting - in a less radical way than nqp-rx - a new nqp, what's the practical upshot? 20:50
moritz_ pmichaud: not critical, but partially very annoying for users
pmichaud jnthn: I'm thinking I need to brainstorm a few hours about the larger implications of that.
in the same way I had to brainstorm to come up with the original nqp-rx plan 20:51
jnthn pmichaud: OK. Can I push a coulple more things onto your brainstorming stack? :-)
pmichaud yes please
jnthn One thing that needs to be figured into this is that nqp-nom now has dynops/dynpmcs.
Just needs a little thought on how they are pushed over to the Parrot world.
A bigger thing though...is the serialization. 20:52
As I wrote in my blog post, I can go two quite distinct ways on that.
pmichaud I'm actually happy that we have dynops/dynpmcs. I'm thinking I can make the regex stuff much faster if I can have some custom dynops.
jnthn Here's one really big worry that I've had since I wrote that post. 20:53
pmichaud I re-read the serialization stuff earlier
jnthn Today our bootstrap for nqp works like this.
pmichaud waits for the worry
jnthn We make PIR files.
And we then start bootstrapping by compiling those. 20:54
*If* I build the serialization stuff on top of Parrot's existing freeze/thaw, that means we end up freezing the stuff in the constants table.
That means that we're kinda forced to go all the way to PBC, not PIR.
Which means we have a big problem, because as soon as the Parrot folks break bytecoe compat (like, regularly) then the bootstrap is hosed. 20:55
*bytecode
pmichaud agreed, that's guaranteed breakage
jnthn IIUC, every new Parrot release is a new bytecode version today.
With the PIR, at the *very* worst we stand a chance of hand-patching it if something gets really, really messed up (but that's hard to imagine needing to do). 20:56
With a PBC, that's impossible.
(...says the guy who tried to binary patch PBCs to bet relocatable Windows installs...)
*get
sorear jnthn: include a copy of the correct version of Parrot in the bootstrap? ;)
jnthn ;-) 20:57
sorear: That actually still doesn't help. (more)
The old Parrot would write old-version bytecode files.
sorear yeah, because Parrot doesn't support cross-PBC-compiling
jnthn Right.
pmichaud my guess is that .pbc as a serialization format is a non-starter for us for quite a while.
sorear is happy that CLR bytecode files are a lot more stable 20:58
jnthn s/bytecode files are/is/ ;)
pmichaud unless you want to clean up Parrot's bytecode handling.
(and I'm guessing "not really")
jnthn I think I'd stand a decent chance of integrating bounded serialization stuff. 20:59
But having to implement bytecode version compatibility...well...ouch.
Not to mention that I probably have to get consensus rather than just commit. :-)
pmichaud for the time being, I'm guessing that PIR remains our serialization format, unless/until NQP creates its own.
jnthn And not break the deprecation policy.
What does PIR as a serialization format look like? 21:00
(more)
sorear Bytecode is not covered under deprecation.
pmichaud PIR as a serialization format looks like it does now :)
jnthn One option is to just emit PIR that builds up the data structures.
pmichaud i.e., instead of generating bytecode/constants, we generate PIR that creates the constants.
"emit PIR that builds up the data structures" === PIR as a serialization format :)
jnthn That's...exactly what I was hoping to not have to do. :| 21:01
pmichaud I agree
sorear jnthn: You'd prefer to create a custom, second language just for the purpose of constructing objects?
jnthn How would some kinda "blob" stored in the PIR that gets shuffled off to a decoder work out?
pmichaud which means the choices are to figure out how to work within parrot's existing .pbc (and figure out how to stabilize that), or come up with a different serialization format.
jnthn sorear: Yes.
sorear: "langauge" :-) 21:02
sorear We have a perfectly good decoder. It's called runops.
jnthn More like binary format.
pmichaud "blob stored in the PIR and shuffled off to a decoder" is still PIR as a serialization format. :)
it doesn't have to be PIR instructions that build the data structures 21:03
jnthn Oh, OK
I was reading "PIR as a serialization format" as just that.
(e.g. PIR instructions that build 'em.)
pmichaud that's one way
my point is more that I don't think we can rely on .pbc as a bootstrapping mechanism, as you pointed out
jnthn OK
pmichaud so we have to go to something that is guaranteed to be compatible across parrot versions 21:04
21:04 ash_ joined
jnthn Which almost certainly precludes extending Parrot's freeze/thaw. 21:04
pmichaud and the only choices there are going to be PIR, or some other serialization structure that we borrow (json?) or define ourselves.
jnthn OK 21:05
pmichaud since we're creating dynops, we can certainly come up with our own thaw/freeze opcode equivalents (more)
jnthn I do wonder if I can come up with a common one.
pmichaud since we have our own REPR, we can certainly build an internal method that does thaw/freeze the way we need
jnthn Oh, yes, I was expecting this would fit in very closely with the REPR API bits.
pmichaud I'd even be okay if we compiled the resulting constants down to C code that gets compiled, similar to the way pbc_to_exe works now. 21:06
sorear maybe something link BSON or ASN.1 BER
like
jnthn Er, by common one I mean, something that looks kinda the same - or even identical - accross our multiple backends...
pmichaud yes, sure
jnthn sorear: Will look those up, thanks.
pmichaud I'd _really_ like that.
sorear has dabbled with a proper compact JSON at several points 21:07
jnthn pmichaud: "that"?
pmichaud "something that looks kinda the same..."
jnthn OK :-)
Me too ;-)
pmichaud in some sense I'm not a fan of creating yet another serialization format
jnthn Not least because it means I don't have to prototype it in C first... :-)
pmichaud but at the same time, I'd like us to not be trapped here forever 21:08
jnthn True, but in a sense it's hardly one that we're going to advocate for use outside of Rakudo implementation.
pmichaud jnthn: I'm not sure about that last part, though.
if other people start targeting nqp as a platform for building dynamic languages....
jnthn Well, OK, maybe I'm being a bit too narrow.
Right.
Let me try and say it better.
It's not something we'd seek to design so we could advocate it as a general purpose serialization format. :-) 21:09
pmichaud but yes, this gets directly at the strategic sorts of questions I need to brainstorm about nqp-rx itself (more)
jnthn Yes, I'm well aware that there's a larger context to all of this.
pmichaud until now, nqp has defined itself as a syntactic front end for creating parrot code
the changes we're looking at tend to make nqp into its own virtual machine platform 21:10
jnthn Yes, that seems to be the way things are heading.
pmichaud I'm not at all opposed to that -- indeed, it's something I explicitly expected could happen when I started thinking about nqp-rx last year -- but I want to think about some of the larger implications now that we're getting to that point.
to bring this back down to more immediate terms (more) 21:11
jnthn I think the fact that porting Rakudo implies porting the compiler toolchain = an interesting opportunity. :-)
pmichaud I'm thinking we're on the same page that we're working towards a new self-hosting nqp that uses the new object model instead of p6object as a base 21:12
and that we're also on the same page as far as porting more of the Parrot Compiler Toolkit into nqp
jnthn *nod*
pmichaud afaict, I don't have any "sacred cows" as far as trying to keep things tied to the existing p6object or past implementations 21:13
i.e., I fully expect we completely replace p6object with the new stuff
I also am not terribly worried about trying to retain compatibility with parrot's existing object implementation
so, if we can no longer use the :method flags (or any other PIR flag, for that matter), I'm not going to lose any sleep over it. 21:14
jnthn Me either, but I've been keeping reasonably quiet about that for now.
pmichaud same goes for Parrot namespaces, btw
in fact, one of the first objects we really need to have available is a better namespace mechanism (you may have this already :-)
jnthn I've not really done anything here yet.
I would say this
It's easier to prototype in 6model 21:15
:-)
pmichaud I have no doubt about that
jnthn In 6model I just didn't do namespaces anyway.
There's lexicals and that's it.
pmichaud it wouldn't suprirse me much if the new nqp implementation that we don't use parrot namespaces at all.
jnthn There's no global root namespace.
Hmm
I hadn't been bargining on that, but I'm willing to go with that if you're happy to help out on that part. 21:16
sorear pmichaud: I just got done writing a new namespace implementation for niecza
jnthn (e.g. I hadn't foreseen it as part of this set of changes, but rather a later thing)
pmichaud well, where does Perl 6 need something like Parrot namespaces?
(I don't think it does.)
jnthn I agree, I just have a tendancy to think in small, achievable leaps. :-) 21:17
pmichaud Parrot namespaces are one of those technical debts that we'll have to address at some point... this might be the point.
jnthn If we want to choose this "next nqp" as the time we move away from Parrot namespaces, though, then I'm fine with that.
pmichaud I'm also wondering if I should look at also getting a Hague grant to do some work assisting with the migration.
jnthn +1
Mention the namespace stuff in it. 21:18
pmichaud (not as much as yours... but enough to help out with the rx and pct bits)
we might need to switch the grant manager to someone else (for both grants)
but I suspect that's doable.
jnthn Hmm. :-)
pmichaud okay -- to me it seems like we're both thinking of a common goal with few discrepancies.... do you agree? 21:19
jnthn Yes, I think we're very much on the same page, and I think this conversation has decided a few things already. 21:20
I agree that it all raises some much wider questions that need more thought too.
For now, I've got plenty to do while you work out the bigger picture. :-) 21:21
pmichaud are there any questions that you perceive as possible blockers for you?
in general my answer seems to be "do what you think is best" :-) 21:22
jnthn Let me check...
The migrating stuff into nqp-rx repo is sorted out. We've muchly narrowed down how the serialization stuff should look.
pmichaud I'm wondering if this deserves a new repo, or a forked repo. 21:23
I'm fine with keeping it as a branch... but in some ways it feels very much like a new product.
jnthn I don't have any immediate strong feelings either way on that.
I'm happy to go with whatever you feel is best.
I can easily buy the "new product" argument.
pmichaud that'll be part of my thinking over the next day or so
so, to summarize: 21:24
* I think the paths your currently headed on are fine and compatible with my expectations
* I'm going to look at a larger strategic direction w.r.t. nqp itself
* sometime over the next week I'll publish a nqp roadmap that outlines where I think things should go overall
* I'll see about applying for a Hague grant so that I can easily assist with some of the migration effort -- especially on the PCT and regex parts 21:25
sound good? 21:26
jnthn Yes, this sounds like a good direction. 21:27
And I'm unblocked in terms of having plenty of things to work on from here on in.
We can take repo moves and other bits once we've got the roadmap. 21:28
(And I *really* like the idea of having said roadmap too.)
pmichaud ooc, what difficulties do you envision with making nqp target both parrot and .Net ? Or, perhaps better -- what level of difficulty do you see there?
yes, I think nqp needs a roadmap now.
jnthn There's some significant design work on some aspects of the runtime. For example, there's *no* exception model in any of the stuff I did so far. 21:30
(for .Net, that is)
pmichaud yes, exceptions will be large in both cases.
jnthn Well, yeah, it's not like we have what we really need on Parrot either, I guess. 21:31
pmichaud correct :)
for the parts that we do have -- do you see having dual (or multiple) backends as being very hard to manage long-term or something we'll be able to handle?
especially the object-model stuff 21:32
jnthn The current situation of the object model is a double edged sword.
The implementation looks very alike on Parrot and on .Net, and will look very similar on mberends++ JVM port too.
pmichaud that's what I wanted to hear. :) 21:33
jnthn The *cost* is that I've basically created an object meta-model that plugs into Parrot around the edges but largely denies its existence.
Or at least
That could cost us.
pmichaud denies Parrot's existence?
or denies the existence of Parrot's object model? 21:34
or ...?
jnthn The latter.
:-)
pmichaud perfect.
jnthn It is
pmichaud that's also what I hope/expect.
this is exciting. jnthn++
jnthn Aye, but I worry if the mis-match will cost us on performance at some point.
pmichaud my expectation continues to be that Parrot will evolve towards the new model rather than try to preserve the old. 21:35
jnthn For example
masak jnthn++
jnthn We have a PMC (RakudoObject - we can rename it NQPObject or whatever later...) that is just a "wrapper" for all objects.
er, all Perl 6 objects 21:36
Basically we take the PMC_data pointer and hang whatever off it.
pmichaud I mean, we _know_ that Parrot needs some substantial improvements to its object handling -- it'll be nice if we offer them a working alternative.
jnthn The first pointer in whatever that is will be the s-table pointer, through which we find the REPR
But since the REPR is what knows about object layout, it's for the REPR to do gc marking.
Basically the PMCs end up as a level of indirection. 21:37
pmichaud I'd prefer NQPObject over RakudoObject.... but I'd prefer P6Object over that. Or maybe something even more generic than the "P6".
jnthn I really didn't want to call it P6object. (more)
It creates naming confusion with the current one, though I know that's less of an issue over time.
pmichaud well, there's currently not a P6Object class :) 21:38
jnthn But secondly the P6foo style names have so far tended to be associated with representations.
(e.g. P6opaque)
pmichaud but yes, I understand the P6 objection.
jnthn It's kind of a prefix convention, like HOW is a postfix one. :-)
pmichaud what P6 things do we have besides P6opaque, ooc?
jnthn :-) 21:39
So basically I'm trying (we'll see if I manage) to tie up reprs and native type handling.
So we have P6int and P6num
Which in their boxed form aren't capable of having attributes but just storing a native integer or native floating point value. 21:40
pmichaud feels like thought maybe shouldn't be P6 prefixed.
*those
i.e., maybe there's a better/different prefix for that
jnthn But a chunk of the repr API I didn't define yet (this is hand-wavey envisiony stuff) would let a REPR say "oh, if you're in a context where you can just inline this bit of storage, do so"
pmichaud anyway, I'd strongly prefer NQPObject over RakudoObject 21:41
jnthn Thus how we get natively typed attributes, compact structs and (with another repr) compact arrays.
OK, I can do that.
pmichaud if we can come up with something slightly more generic than that, I'd likely go with it.
jnthn Also +1 on a better prefix/postfix for reprs 21:42
pmichaud But I do tend to think of NQP as much more than just Rakudo
jnthn OpaqueREPR works for me.
Yes, RakudoObject was not a great name.
It was also copied right from the .Net prototype. :-)
pmichaud OpaqueREPR would be okay also.
jnthn I mean for the REPR, not for the container PMC.
pmichaud NQPMC :-P
jnthn ;-) 21:43
pmichaud okay, I'm going to take a break for a while
jnthn OK. I think it's time for me to grab a beer too. :-)
pmichaud I'm really happy to see the way things are headed
jnthn Thanks for this, it's been a *very* helpful meeting. :-)
pmichaud sure thing
same here
afk for a while 21:44
jnthn goes to say hi to his chladnicka
diakopter hopefully it's running 21:58
sorear afk(8h) 22:00
jnthn I wish it'd stop running, it knackers me out chasing after it to get a beer out... 22:01
masak was about to Google Translate 'chladnicka', when he realized what it was, and the pun, at the same time 22:25
d'oh
jnthn "cold thingummy" 22:27
masak aye.
холод 22:28
jnthn
.oO( oh heh, I wonder if лед comes from the same root... )
 22:30
masak not entirely inconceivable. 22:31
холод and 'cold' sound kinda related, too. 22:32
anyway, this is too off-topic. would work on #perl6, though :P
jnthn All channels go through off-topic phases...
masak :) 22:34
unless they're about everything.
23:24 ash_ left 23:33 masak left

Powered by Cro and the Raku® Programming Language.

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

Thank you!