Perl 6 - the future is here, just unevenly distributed

IRC log for #phasers, 2010-09-28

| Channels | #phasers index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
04:45 ash_ left #phasers
17:11 ash_ joined #phasers
17:59 ash_ left #phasers
18:13 moritz_ prepasting report, because I can:
18:13 moritz_ * worked a lot on the book; would like to encourage others to contribute too
18:13 moritz_ * worked on the backtrace printer, simplified it in one case, made it smarter about warnings
18:14 moritz_ * cut the compiler release
18:14 moritz_ * implemented a basic version of require
18:14 moritz_ * a few doc improvements
18:14 moritz_ .EOR
18:39 masak joined #phasers
18:46 masak left #phasers
18:47 masak joined #phasers
18:47 masak left #phasers
18:57 masak joined #phasers
18:57 masak left #phasers
18:58 masak joined #phasers
18:59 Util Pre-pasting report, because #parrotsketch has the right idea.
18:59 Util * 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.
19:00 Util * 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 Util .end
19:00 Util (trying again)
19:00 Util Pre-pasting report, because #parrotsketch has the right idea.
19:00 Util * Posted 2 more Perl 6 solutions to RosettaCode tasks: Topological_sort and Equilibrium_index
19:00 Util = also translated Ruby solution of Sudoku task into Perl 6, but am not happy with it yet.
19:00 Util * Gave a Perl 6 talk at Atlanta.pm
19:00 Util = Rationals
19:00 Util = .perl&:pairs vs p5's Data::Dumper
19:00 Util = meta-operators ( X Z Xop Zop, [op] ).
19:00 Util .end
19:00 moritz_ Util++
19:01 pmichaud My report, and then I have to (alas) depart on some errands:
19:01 pmichaud * Some minor bugfixes and code explorations
19:01 pmichaud * I'm still working on getting feedback on cpan6 design details -- will report next week.
19:01 ash_ joined #phasers
19:01 pmichaud * Will cut the next R* release later today
19:01 pmichaud EOR
19:02 pmichaud afk for about 30 mins
19:03 moritz_ and now it's #phasers time!
19:03 masak seems the meeting has begun now.
19:03 moritz_ jnthn? masak? sorear? any reports?
19:03 sorear Hello moritz_
19:03 diakopter joined #phasers
19:03 moritz_ (non-rakudo reports are also welcome)
19:04 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 :-)
19:04 sorear niecza/mm is right about ready to merge
19:04 jnthn someone else can go while I finish typing :-)
19:05 sorear niecza is now generating meta-objects at compile time, mostly, instead of generating a giant BEGIN/PRE-INIT sub
19:05 colomon joined #phasers
19:05 sorear (ok we still make a giant sub to thaw the objects :/)
19:08 moritz_ \o colomon
19:08 colomon o/
19:09 colomon guess I can report quickly while we wait on jnthn.
19:09 moritz_ +1
19:10 colomon basically vacationed and got a cold.
19:10 colomon I've been working on getting the ABC module to actually do something useful.
19:10 * sorear just broke the $*FOO test, so the merge isn't likely to happen *right now*
19:10 colomon adding actions to the parser, etc.
19:10 sorear What is ABC supposed to do?
19:10 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.
19:11 colomon sorear: ABC is a simple music notation.
19:12 colomon I'm working on getting the grammar to translate from ABC notation to Lilypond's music handling.
19:12 colomon s/handling/notation/
19:13 colomon so in terms of perl 6, it's just something interesting to me implemented in perl 6
19:13 sorear I see.
19:13 colomon learning my way around writing actions for a grammar, getting practical experience writing roles, etc.
19:13 * jnthn ready, btw
19:13 colomon .eor
19:14 jnthn colomon: Get well soon!
19:14 moritz_ jnthn: go ahead then
19:14 jnthn Last week
19:14 jnthn * Gave 6model on .Net support for attribute storage (get and bind)
19:14 jnthn * Finished porting all the representations I'll need for now to Parrot's 6model implementation
19:14 jnthn * Filled out the KnowHOW much more in the Parrot implementation
19:14 jnthn * Ported many of the JnthnNQP changes into nqp-rx
19:14 jnthn * knowhow Foo { ... } stuff now works
19:14 jnthn * Got attributes working on 6model on Parrot impl too.
19:14 jnthn * 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. :-)
19:14 jnthn * Started to stub in ClassHOW
19:14 jnthn * Got some thinking time on how natively typed attributes and stuff could look, dynamic method caching techniques, etc.
19:14 jnthn This week
19:14 jnthn * Focus on getting to a basically functional ClassHOW on nqp-rx
19:14 jnthn * Try switching NQP's class keyword to use it, and start dealing with the fallout
19:14 jnthn * Try and get multi-dispatch stuff prototyped in the .Net implementation
19:14 jnthn Blockers
19:14 jnthn * Broken body clock due to doing lots of on-site work at the moment. "Patches welcome." ;-)
19:14 jnthn * Brain cycles - the coding is pretty easy, most of the time...
19:14 jnthn END
19:15 moritz_ colomon.health++
19:15 moritz_ colomon++
19:16 moritz_ jnthn++
19:16 moritz_ sorear++
19:16 * moritz_ has one thing to discuss
19:16 moritz_ currently it feels rather lonely to hack on the book
19:16 colomon let's not forget moritz_++, as he seems to be the main rakudo commiter at the moment.  :)
19:17 moritz_ sometimes people read through it, and complain that things aren't explained well
19:17 moritz_ which is great
19:17 moritz_ but it seems that often I'm the only one working on actually fixing it
19:17 moritz_ so, what can we do about it?
19:17 sorear * niecza/mm is now merged.
19:18 Util I can tackle more of the "things that aren't explained well"
19:18 moritz_ ++Util
19:18 colomon moritz_: do we have some sort of list of what needs to be done on the book?
19:18 sorear pmichaud: Did anything become of your plot to contact obra, scwern, Alias?
19:18 masak moritz_: I have a fair number of things to contribute, but somehow I've never gotten around to starting.
19:19 masak 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
19:19 Util colomon: http://github.com/perl6/book/issues
19:19 masak I guess I should start by trying to make the book build locally again...
19:19 masak apologies for the lags at my end.
19:20 * 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.
19:20 moritz_ *only
19:20 masak moritz_: that works fine for some of the changes I have in mind.
19:20 masak moritz_: as the book nears 100% ready, though, the rendered aspects of it become increasingly important.
19:21 moritz_ masak: I consider rendering aspects mostly the job of our publisher
19:21 moritz_ at least the finer points
19:22 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 masak it's mostly a matter of finding the time to do it.
19:23 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
19:23 moritz_ colomon: we need a section on statements
19:24 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.
19:24 colomon it's been helpful.
19:25 ash_ left #phasers
19:25 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 :(
19:25 moritz_ colomon: you mean book goals for the rakudo release?
19:26 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:27 masak moritz_: from the bright side, I see a lot of good work being done on it that I didn't expect.
19:27 masak moritz_: I am impressed by what you've contributed so far, and I'll try my best to make your efforts less lonely :)
19:27 moritz_ :-)
19:28 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:29 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.
19:30 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.  :)
19:30 moritz_ colomon: I've pretty much always worked on random stuff just within my reach
19:30 jnthn Thus, I'm focusing the Perl 6 part of my attention span pretty much fully on that.
19:31 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.
19:31 jnthn For now, anyway. :-)
19:31 sorear Unexpectedly, niecza/mm seems to be much faster
19:31 colomon jnthn: sure, you and sorear are both being amazingly productive elsewhere.  :)
19:31 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.
19:31 masak then we'd have a central place to go to for the "status" of the book.
19:31 sorear STD.pm6 is back to being 90+% of runtime
19:32 ash_ joined #phasers
19:32 jnthn colomon: Aye, but the aim is that this all joins up with Rakudo in the not too distant future. :-)
19:32 jnthn Well, the bits I'm doing, anyways. :-)
19:32 masak also, it'd have the psychological benefit of putting a concrete number on something quite nebulous.
19:32 colomon masak: +1
19:32 jnthn sorear: Faster is good. \o/
19:32 moritz_ masak: +2
19:33 jnthn masak: +1
19:33 masak optionally, people can sign up for specific tasks of making the book better in small ways.
19:33 sorear niecza/mm is now merged and passing all 520 remaining tests
19:33 masak think Advent Calendar success.
19:34 masak 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
19:34 masak ash_++
19:35 masak 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)
19:38 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:39 ash_ lol, not all of those are guaranteed to work, since it is the real repl
19:41 masak that implication arrow did not make sense to me.
19:41 masak but nevermind.
19:41 Util moritz_: .pdf snapshot to be updated on github.../downloads soon?
19:42 moritz_ Util: I can do that tonight, if there's demand
19:42 Util Just noticed that it is >1 month old.
19:51 moritz_ will do
19:51 moritz_ anything else we need to discuss?
19:51 * jnthn doesn't have anything
19:52 pmichaud back again
19:53 masak the enums patch went in, but in a significantly less effective form than I originally wrote it.
19:53 masak maybe #perl6 is a better forum for that, though.
19:53 masak 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.
20:00 jnthn o/ pmichaud
20:06 pmichaud yes, 2h00
20:06 pmichaud er, 20h00
20:07 jnthn It's about that.
20:07 jnthn Is today still good?
20:07 pmichaud I either need  new keyboards or new fingers or both  :-(
20:07 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.
20:07 pmichaud sure, today still works out well
20:07 pmichaud we can discuss here, or in #phasers, or wherever you wish :)
20:07 pmichaud oh, we're in #phasers
20:08 pmichaud maybe today isn't so good :-P
20:08 sorear pmichaud: How did your chat with obra, Alias, etc go?
20:08 pmichaud sorear: I mentioned earlier that I'm still working on that.
20:08 sorear ah
20:08 pmichaud I'll report again next week.
20:08 jnthn pmichaud: #phasers probably avoids too much noise in #perl6
20:09 jnthn 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 :)
20:09 pmichaud #phasers is my preference also
20:09 jnthn OK, great.
20:09 sorear things I'd generally like to persue in niecza in the coming weeks:
20:09 colomon steady income++
20:10 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
20:10 sorear * gradual typing stuff (vtables etc)
20:10 sorear * roles
20:10 sorear * multi methods
20:10 sorear * bootstrapping
20:10 jnthn pmichaud: heh, sorear is kinda listing my roadmap... :-)
20:10 jnthn <grin>
20:11 jnthn pmichaud: Maybe best is if I give a quick status update on where I've got so far?
20:11 jnthn Then there's some context for what needs to come along next.
20:11 pmichaud jnthn: sounds like a good starting point
20:12 jnthn OK
20:12 jnthn 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.
20:12 jnthn It's turing complete, at least. ;-)
20:12 jnthn Did a bunch of profiling, re-working (not just performance, but design issues), etc.
20:13 jnthn A couple of weeks ago I dug into the Parrot port.
20:13 jnthn 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#.
20:14 jnthn In terms of the meta-model primitives, I have the two just about neck and neck now.
20:14 jnthn In the model there's essentially three things.
20:15 jnthn 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:16 jnthn 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 jnthn 2) Meta-objects that implement the HOW API (or some subset of it). This has the declarative and introspective bits.
20:17 jnthn 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 jnthn 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.
20:17 jnthn And to bootstrap.
20:18 jnthn 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:19 jnthn The STable is also where the v-table will be kept cached to do gradually typed dispatches.
20:19 jnthn That's pretty much *it*. Everything else - classes, roles, meta-attributes, etc - can be built on top of this.
20:19 jnthn I'm pretty much at the "build that stuff" stage now.
20:20 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
20:20 jnthn sorear: Correct
20:20 sorear In particular, every method call involves a call to .^find-method
20:21 jnthn The only thing in this whole design that are not first-class objects are the STable and the representation implementations.
20:21 jnthn Everything else is just an object.
20:21 * diakopter listens keenly
20:21 jnthn sorear: Apart from where we cheat thanks to gradual typing optimizations, but yes.
20:21 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
20:22 sorear 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?
20:22 jnthn Oh, I think I mis-understood.
20:23 jnthn (What you just said about ClassHOW made me understand a bit more what you were thinking.)
20:24 jnthn 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
20:24 sorear I am thinking that as your work progresses we'll have a better understanding of what features "REPR polymorphism" requires
20:24 sorear in particular, once the apps hacking starts
20:25 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
20:25 jnthn oh gah, double negatives!
20:26 jnthn s/aren't/are/
20:26 jnthn pmichaud: OK.
20:26 jnthn pmichaud: So one of my next steps is going to be to get an implementation of classes written.
20:26 jnthn e.g. ClassHOW
20:26 sorear jnthn: I'd like to see how many people are writing fully custom HOWs
20:27 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
20:28 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)
20:29 jnthn pmichaud: At that point, I'll hit a migration issue.
20:29 jnthn 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).
20:30 jnthn 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
20:30 pmichaud afaik, nothing in nqp-rx relies on the inner workings of p6object
20:30 pmichaud if it does, we should replace/fix it
20:30 jnthn Well, it's more reliance on Parrot's object model too.
20:31 jnthn nqp-rx today (not in my nom branch) doesn't ever make an add_method call.
20:31 pmichaud oh, right.
20:31 jnthn It relies on Parrot's Class PMC magically slurping things up marked :method.
20:31 pmichaud I'm totally fine with switching nqp-rx to work in terms of add_method
20:31 pmichaud instead of relying on the :method compile-time flag.
20:32 jnthn OK, phew. :-)
20:32 jnthn I'm not quite so sure about the stuff we have that's written in PIR, mind.
20:32 jnthn I mean, what gets more interesting is when I want to get the grammar package declarator switched over.
20:32 jnthn Does that have inheritance dependencies outside of the nqp-rx repo?
20:32 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.
20:33 jnthn Same.
20:33 pmichaud 'grammar' simply means that we inherit from Regex::Cursor, iirc.
20:33 jnthn Which is in nqp-rx repo?
20:33 pmichaud yes.
20:33 pmichaud src/Regex/Cursor.pir
20:33 jnthn And in PIR?
20:33 jnthn Right.
20:33 pmichaud I'm okay with switching those to be written in nqp also.
20:34 jnthn How would a first pass involving wrapping Q:PIR inside NQP method declarations sit with you?
20:34 jnthn Then the NQP re-write can take place a bit at a time.
20:34 jnthn Rather than the whole file in one go.
20:34 pmichaud I don't have a problem with that.
20:34 jnthn OK.
20:35 jnthn I'm tempted to do that and have a compiler write the boilerplate for me. ;-)
20:35 jnthn (rather than write all the add_method calls out in a PIR loadinit...)
20:35 pmichaud I'm thinking of something slightly different, though
20:36 pmichaud (still forming in my head -- give me a couple of minutes to chase it down)
20:36 jnthn OK :-)
20:36 pmichaud actually, I need a 5-min break to take care of house-things... bbi5
20:36 pmichaud then I have a counter-suggestion or two
20:37 jnthn I'll be right here. :-)
20:37 sorear jnthn: How will non-instantiable types work?
20:37 sorear jnthn: after role Foo { }, what is Foo?  is it defined?  does it have a distinct WHAT and HOW?
20:37 jnthn sorear: To make sure we're talking about the same thing, what's your definition of "non-instantiable"?
20:37 jnthn Oh, roles...
20:38 jnthn Foo is undefined, since it's a type object.
20:38 jnthn 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.
20:38 jnthn (And caches the pun)
20:38 sorear There will never be a defined object whose .WHAT is a role
20:38 sorear or a subtype
20:39 jnthn Heh...yes. :-)
20:39 sorear that's what I mean by non-instantiatable
20:39 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.
20:40 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
20:40 sorear Do you have any plans for PackageHOW or ModuleHOW?
20:40 pmichaud okay, what strikes me about this is how very similar it feels to the nqp-rx rewrite and migration I did last year
20:40 jnthn But that anonymous class gets cached in the role meta-object.
20:41 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:42 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 jnthn pmichaud: Yes, that's my feeling too.
20:42 jnthn pmichaud: Especially so if we're going to also end up with Perl 6 multi-dispatch in it.
20:43 jnthn 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
20:43 jnthn (e.g. we need multi-dispatch that can distinguish on the :D/:U stuff)
20:43 jnthn sorear: Hm
20:43 sorear which are essentially distinct objects in Niecza, not sure about rakudo
20:43 pmichaud oh, we can certainly have the stringify method do its own internal "multi dispatch".
20:43 jnthn pmichaud: True.
20:44 pmichaud I mean, I do that already for handling autoviv in Rakudo.
20:44 jnthn pmichaud: And ACCEPTS
20:44 jnthn Yeah
20:44 pmichaud So, that's not an absolutely necessity.
20:44 jnthn It's a hack though.
20:44 pmichaud *absolute
20:44 ash_ left #phasers
20:44 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.
20:44 sorear pmichaud: Why did adding rx to nqp require a complete rework?
20:45 pmichaud sorear: there were a large number of reasons
20:45 pmichaud sorear: some technical, some other
20:45 jnthn pmichaud: Thanks, that's actually a simple but very helpful point. "Why didn't I think of that?" :-)
20:46 pmichaud we could even get p6object to do the same hack (and remove the subclassing role) if we felt it was important.
20:46 pmichaud p6object doesn't absolutely require that its protoobjects be subclassed -- that was just the initial guess at how it would work.
20:46 jnthn *nod*
20:47 jnthn 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)
20:47 pmichaud also I wanted to rewrite pge to make use of PAST
20:48 pmichaud instead of generating code directly
20:48 moritz_ (but don't forge that nqp-rx still misses some PGE features)
20:49 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:50 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
20:50 pmichaud jnthn: I'm thinking I need to brainstorm a few hours about the larger implications of that.
20:51 pmichaud 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? :-)
20:51 pmichaud yes please
20:51 jnthn One thing that needs to be figured into this is that nqp-nom now has dynops/dynpmcs.
20:51 jnthn Just needs a little thought on how they are pushed over to the Parrot world.
20:52 jnthn A bigger thing though...is the serialization.
20:52 jnthn As I wrote in my blog post, I can go two quite distinct ways on that.
20:52 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.
20:53 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
20:53 jnthn Today our bootstrap for nqp works like this.
20:53 * pmichaud waits for the worry
20:53 jnthn We make PIR files.
20:54 jnthn And we then start bootstrapping by compiling those.
20:54 jnthn *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.
20:54 jnthn That means that we're kinda forced to go all the way to PBC, not PIR.
20:55 jnthn 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 jnthn *bytecode
20:55 pmichaud agreed, that's guaranteed breakage
20:55 jnthn IIUC, every new Parrot release is a new bytecode version today.
20:56 jnthn 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 jnthn With a PBC, that's impossible.
20:56 jnthn (...says the guy who tried to binary patch PBCs to bet relocatable Windows installs...)
20:56 jnthn *get
20:56 sorear jnthn: include a copy of the correct version of Parrot in the bootstrap? ;)
20:57 jnthn ;-)
20:57 jnthn sorear: That actually still doesn't help. (more)
20:57 jnthn The old Parrot would write old-version bytecode files.
20:57 sorear yeah, because Parrot doesn't support cross-PBC-compiling
20:57 jnthn Right.
20:57 pmichaud my guess is that .pbc as a serialization format is a non-starter for us for quite a while.
20:58 * sorear is happy that CLR bytecode files are a lot more stable
20:58 jnthn s/bytecode files are/is/ ;)
20:58 pmichaud unless you want to clean up Parrot's bytecode handling.
20:58 pmichaud (and I'm guessing "not really")
20:59 jnthn I think I'd stand a decent chance of integrating bounded serialization stuff.
20:59 jnthn But having to implement bytecode version compatibility...well...ouch.
20:59 jnthn Not to mention that I probably have to get consensus rather than just commit. :-)
20:59 pmichaud for the time being, I'm guessing that PIR remains our serialization format, unless/until NQP creates its own.
20:59 jnthn And not break the deprecation policy.
21:00 jnthn What does PIR as a serialization format look like?
21:00 jnthn (more)
21:00 sorear Bytecode is not covered under deprecation.
21:00 pmichaud PIR as a serialization format looks like it does now :)
21:00 jnthn One option is to just emit PIR that builds up the data structures.
21:00 pmichaud i.e., instead of generating bytecode/constants, we generate PIR that creates the constants.
21:00 pmichaud "emit PIR that builds up the data structures" === PIR as a serialization format :)
21:01 jnthn That's...exactly what I was hoping to not have to do. :|
21:01 pmichaud I agree
21:01 sorear jnthn: You'd prefer to create a custom, second language just for the purpose of constructing objects?
21:01 jnthn How would some kinda "blob" stored in the PIR that gets shuffled off to a decoder work out?
21:01 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.
21:01 jnthn sorear: Yes.
21:02 jnthn sorear: "langauge" :-)
21:02 sorear We have a perfectly good decoder.  It's called runops.
21:02 jnthn More like binary format.
21:02 pmichaud "blob stored in the PIR and shuffled off to a decoder"  is still PIR as a serialization format.  :)
21:03 pmichaud it doesn't have to be PIR instructions that build the data structures
21:03 jnthn Oh, OK
21:03 jnthn I was reading "PIR as a serialization format" as just that.
21:03 jnthn (e.g. PIR instructions that build 'em.)
21:03 pmichaud that's one way
21:03 pmichaud my point is more that I don't think we can rely on .pbc as a bootstrapping mechanism, as you pointed out
21:03 jnthn OK
21:04 pmichaud so we have to go to something that is guaranteed to be compatible across parrot versions
21:04 ash_ joined #phasers
21:04 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.
21:05 jnthn OK
21:05 pmichaud since we're creating dynops, we can certainly come up with our own thaw/freeze opcode equivalents (more)
21:05 jnthn I do wonder if I can come up with a common one.
21:05 pmichaud since we have our own REPR, we can certainly build an internal method that does thaw/freeze the way we need
21:05 jnthn Oh, yes, I was expecting this would fit in very closely with the REPR API bits.
21:06 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
21:06 sorear like
21:06 jnthn Er, by common one I mean, something that looks kinda the same - or even identical - accross our multiple backends...
21:06 pmichaud yes, sure
21:06 jnthn sorear: Will look those up, thanks.
21:06 pmichaud I'd _really_ like that.
21:07 * sorear has dabbled with a proper compact JSON at several points
21:07 jnthn pmichaud: "that"?
21:07 pmichaud "something that looks kinda the same..."
21:07 jnthn OK :-)
21:07 jnthn Me too ;-)
21:07 pmichaud in some sense I'm not a fan of creating yet another serialization format
21:07 jnthn Not least because it means I don't have to prototype it in C first... :-)
21:08 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.
21:08 pmichaud jnthn: I'm not sure about that last part, though.
21:08 pmichaud if other people start targeting nqp as a platform for building dynamic languages....
21:08 jnthn Well, OK, maybe I'm being a bit too narrow.
21:08 jnthn Right.
21:08 jnthn Let me try and say it better.
21:09 jnthn 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)
21:09 jnthn Yes, I'm well aware that there's a larger context to all of this.
21:09 pmichaud until now, nqp has defined itself as a syntactic front end for creating parrot code
21:10 pmichaud 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.
21:10 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.
21:11 pmichaud 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. :-)
21:12 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 pmichaud and that we're also on the same page as far as porting more of the Parrot Compiler Toolkit into nqp
21:12 jnthn *nod*
21:13 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 pmichaud i.e., I fully expect we completely replace p6object with the new stuff
21:13 pmichaud I also am not terribly worried about trying to retain compatibility with parrot's existing object implementation
21:14 pmichaud 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.
21:14 pmichaud same goes for Parrot namespaces, btw
21:14 pmichaud in fact, one of the first objects we really need to have available is a better namespace mechanism (you may have this already :-)
21:14 jnthn I've not really done anything here yet.
21:14 jnthn I would say this
21:15 jnthn It's easier to prototype in 6model
21:15 jnthn :-)
21:15 pmichaud I have no doubt about that
21:15 jnthn In 6model I just didn't do namespaces anyway.
21:15 jnthn There's lexicals and that's it.
21:15 pmichaud it wouldn't suprirse me much if the new nqp implementation that we don't use parrot namespaces at all.
21:15 jnthn There's no global root namespace.
21:15 jnthn Hmm
21:16 jnthn 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
21:16 jnthn (e.g. I hadn't foreseen it as part of this set of changes, but rather a later thing)
21:16 pmichaud well, where does Perl 6 need something like Parrot namespaces?
21:16 pmichaud (I don't think it does.)
21:17 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.
21:17 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.
21:17 pmichaud I'm also wondering if I should look at also getting a Hague grant to do some work assisting with the migration.
21:17 jnthn +1
21:18 jnthn 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)
21:18 pmichaud we might need to switch the grant manager to someone else (for both grants)
21:18 pmichaud but I suspect that's doable.
21:18 jnthn Hmm. :-)
21:19 pmichaud okay -- to me it seems like we're both thinking of a common goal with few discrepancies.... do you agree?
21:20 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 jnthn I agree that it all raises some much wider questions that need more thought too.
21:21 jnthn 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?
21:22 pmichaud in general my answer seems to be "do what you think is best"  :-)
21:22 jnthn Let me check...
21:22 jnthn The migrating stuff into nqp-rx repo is sorted out. We've muchly narrowed down how the serialization stuff should look.
21:23 pmichaud I'm wondering if this deserves a new repo, or a forked repo.
21:23 pmichaud I'm fine with keeping it as a branch... but in some ways it feels very much like a new product.
21:23 jnthn I don't have any immediate strong feelings either way on that.
21:23 jnthn I'm happy to go with whatever you feel is best.
21:23 jnthn I can easily buy the "new product" argument.
21:23 pmichaud that'll be part of my thinking over the next day or so
21:24 pmichaud so, to summarize:
21:24 pmichaud * I think the paths your currently headed on are fine and compatible with my expectations
21:24 pmichaud * I'm going to look at a larger strategic direction w.r.t. nqp itself
21:24 pmichaud * sometime over the next week I'll publish a nqp roadmap that outlines where I think things should go overall
21:25 pmichaud * 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:26 pmichaud sound good?
21:27 jnthn Yes, this sounds like a good direction.
21:27 jnthn And I'm unblocked in terms of having plenty of things to work on from here on in.
21:28 jnthn We can take repo moves and other bits once we've got the roadmap.
21:28 jnthn (And I *really* like the idea of having said roadmap too.)
21:28 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?
21:28 pmichaud yes, I think nqp needs a roadmap now.
21:30 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 jnthn (for .Net, that is)
21:30 pmichaud yes, exceptions will be large in both cases.
21:31 jnthn Well, yeah, it's not like we have what we really need on Parrot either, I guess.
21:31 pmichaud correct :)
21:31 pmichaud 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?
21:32 pmichaud especially the object-model stuff
21:32 jnthn The current situation of the object model is a double edged sword.
21:32 jnthn The implementation looks very alike on Parrot and on .Net, and will look very similar on mberends++ JVM port too.
21:33 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.
21:33 jnthn Or at least
21:33 jnthn That could cost us.
21:33 pmichaud denies Parrot's existence?
21:34 pmichaud or denies the existence of Parrot's object model?
21:34 pmichaud or ...?
21:34 jnthn The latter.
21:34 jnthn :-)
21:34 pmichaud perfect.
21:34 jnthn It is
21:34 pmichaud that's also what I hope/expect.
21:34 pmichaud this is exciting.  jnthn++
21:34 jnthn Aye, but I worry if the mis-match will cost us on performance at some point.
21:35 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
21:35 masak jnthn++
21:35 jnthn We have a PMC (RakudoObject - we can rename it NQPObject or whatever later...) that is just a "wrapper" for all objects.
21:36 jnthn er, all Perl 6 objects
21:36 jnthn Basically we take the PMC_data pointer and hang whatever off it.
21:36 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.
21:36 jnthn The first pointer in whatever that is will be the s-table pointer, through which we find the REPR
21:36 jnthn But since the REPR is what knows about object layout, it's for the REPR to do gc marking.
21:37 jnthn 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".
21:37 jnthn I really didn't want to call it P6object. (more)
21:37 jnthn It creates naming confusion with the current one, though I know that's less of an issue over time.
21:38 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.
21:38 jnthn (e.g. P6opaque)
21:38 pmichaud but yes, I understand the P6 objection.
21:38 jnthn It's kind of a prefix convention, like HOW is a postfix one. :-)
21:38 pmichaud what P6 things do we have besides P6opaque, ooc?
21:39 jnthn :-)
21:39 jnthn So basically I'm trying (we'll see if I manage) to tie up reprs and native type handling.
21:39 jnthn So we have P6int and P6num
21:40 jnthn 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.
21:40 pmichaud *those
21:40 pmichaud i.e., maybe there's a better/different prefix for that
21:40 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"
21:41 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.
21:41 jnthn OK, I can do that.
21:41 pmichaud if we can come up with something slightly more generic than that, I'd likely go with it.
21:42 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
21:42 jnthn OpaqueREPR works for me.
21:42 jnthn Yes, RakudoObject was not a great name.
21:42 jnthn It was also copied right from the .Net prototype. :-)
21:42 pmichaud OpaqueREPR would be okay also.
21:42 jnthn I mean for the REPR, not for the container PMC.
21:42 pmichaud NQPMC  :-P
21:43 jnthn ;-)
21:43 pmichaud okay, I'm going to take a break for a while
21:43 jnthn OK. I think it's time for me to grab a beer too. :-)
21:43 pmichaud I'm really happy to see the way things are headed
21:43 jnthn Thanks for this, it's been a *very* helpful meeting. :-)
21:43 pmichaud sure thing
21:43 pmichaud same here
21:44 pmichaud afk for a while
21:44 * jnthn goes to say hi to his chladnicka
21:58 diakopter hopefully it's running
22:00 * sorear afk(8h)
22:01 jnthn I wish it'd stop running, it knackers me out chasing after it to get a beer out...
22:25 * masak was about to Google Translate 'chladnicka', when he realized what it was, and the pun, at the same time
22:25 masak d'oh
22:27 jnthn "cold thingummy"
22:27 masak aye.
22:28 masak холод
22:30 jnthn .oO( oh heh, I wonder if лед comes from the same root... )
22:31 masak not entirely inconceivable.
22:32 masak холод and 'cold' sound kinda related, too.
22:32 masak anyway, this is too off-topic. would work on #perl6, though :P
22:32 jnthn All channels go through off-topic phases...
22:34 masak :)
22:34 masak unless they're about everything.
23:24 ash_ left #phasers
23:33 masak left #phasers

| Channels | #phasers index | Today | | Search | Google Search | Plain-Text | summary