"Tuesday at 20:30 UTC"
Set by moderator on 8 July 2010.
00:18 dduncan joined 02:35 eternaleye joined 05:44 mikehh joined 07:50 rv2733 joined 12:56 particle joined 14:08 whiteknight joined 14:21 tcurtis joined 15:30 whiteknight joined 15:38 NotFound joined 16:13 eternaleye joined 16:15 whiteknight joined 18:39 mikehh joined
Coke Did: mostly hacked on partcl-nqp, slowly getting things back to even. 19:06
Did not: send out those emails about the experimental items. Prepare to discuss at #ps today. 19:07
EOR
mikehh What I did since my last report: 19:12
* building and testing parrot on amd64/i386, with gcc/g++
* various fixes
* branch testing and some fixes
* testing rakudo, partcl-nqp, partcl, pir/PIRATE, winxed and some plumage
What I intend to do in the next week:
* testing and fixing
* make sure I understand all the requirements for release manager for 2.7.0
.eor
19:46 chromatic joined
tcurtis Did: 19:54
* Implemented traversal of all PAST::Node attributes that I am aware of that can hold another PAST in PAST::Walker.
* Implemented traversal of PAST::Var attributes that can hold another PAST in PAST::Transformer.
* Switched PAST::Pattern to use PAST::Pattern::Transformer instead of Tree::Pattern::Transformer.
* Moved my GSoC project to a github repository
- github.com/ekiru/tree-optimization
- It's now available via plumage as "tree-optimization"
* Implemented a working tail-call elimination optimization for NQP-rx
- Caveat: only works for explicit returns.
- github.com/ekiru/nqp-rx/blob/optimi...zer.pm#L23
* Blog post 19:55
- parrot.org/content/tail-call-elimin...ing-github
* Discovered a segfault that might be GC related. Will create a TT later tonight if I can't find any that seem to be the same thing.
* Submitted a first draft of my GSoC midterm evaluation.
- May revise before Friday.
* Started rewriting the Squaak tutorial for modern NQP-rx.
- partially updated version is currently at github.com/ekiru/squaak-tutorial
Will do:
* Research the possibility of converting PAST or POST into some sort of SSA or CPS form to simplify optimization.
* Research LLVM's FunctionPass, LoopPass, and such, to see how best to adapt such things to PAST.
* Work on more optimizations for NQP-rx and PIRATE.
* Add new functionality and improve existing functionality of Tree/PAST/etc.::Walker/Transformer/Pattern
* Finish updating Squaak tutorial
EOR
q1q
chromatic I moved my office. I'll have more time in the coming week. 19:56
19:59 cotto_work joined 20:08 Chandon joined 20:09 khairul joined
khairul Did: 20:11
-blog post @ parrot.mangkok.com/?p=129
-mostly refactoring
Will Do:
-Complete GSoC midterm evaluation
-Catch up on last week's goals.
EOR
20:12 bacek joined
Chandon Done: 20:13
* GSOC Mid-term evaluation
* Basic Green Threads functionality
Will do:
* Blog post
bacek Little bit of pirate hacking. Nothing particular. Heavily affected by #rl... 20:14
cotto_work #did: met with khairul, reviewed code, finished gsoc midterm eval 20:15
#will do: not sure (tuits in short supply this week) 20:16
#eor
NotFound What I did: 20:21
-parrot
* Miscellaneous testing, nothing worth mentioning.
-winxed
* Several minor fixes and refactors
* More predef runtime evaluation
* Added a better example of opengl usage
* Added a minimal support for float in stage 0, allowing its usage in
places of stage 1 compiler where will be conditionally ignored,
allowing const float expression optimizations in stage 2
* More const expression optimizations in stages 1 and 2
What I will do:
No plan
EOR
Util # Done: 20:28
* Improved Perl6book build
* Worked on Win32 Rakudo coretest problem
# Plan to do:
* Perl6book examples
* Finish Win32 Rakudo coretest problem
# Blockers:
* $WORK
.end
20:30 moritz joined
chromatic Hello. 20:31
cotto_work hi
mikehh hi there
tcurtis Hello.
Util Hello 20:32
bacek aloha
NotFound hola
chromatic Let's review the past week. Looked slow to me; what's notable?
Coke release in one week. Nobody broke anything. 20:33
chromatic Is a code slush keeping people out of corer? 20:34
*core
cotto_work either that or a coincidental lack of tuits
Coke might be. haven't seen any branches other than gsoc.
20:34 eternaleye joined
bacek I think both. 20:34
20:34 wendar joined
Coke 'sfine. haven't heard any complaints from rakudo, either. 20:34
chromatic Any bugs anyone particularly wants fixed for next week? 20:35
Coke I'd like 'make html' to be finished by then. hope to have some tuits this week. (my parrot time this week was spent hacking on partcl-nqp)
chromatic Are you leading the charge on that?
Coke Any segfaults that are still open would be nice to have a whack at. 20:36
cotto_work There are a few small things (minor bugfix and some PARROT_EXPORT annotations) from khairul's branch.
Coke chromatic: yah.
chromatic Are there bite-sized tasks you can delegate on that one, Coke?
Coke we need to decide this week if any of the stuff marked experimental is mature enough to get unmarked.
chromatic: Yes, been doing that with mikehh who spoke up last week when this conversation happened. 20:37
if more people are interested, come see me.
chromatic Any other volunteers to fix make-html?
mikehh waiting on Coke, but working on it 20:38
Coke right. if so, ping me on irc or email.
ah, mikehh, if you want more tasks, I'll break a few off. =-)
chromatic We also need experimental review. Is there a canonical list?
Coke DEPRECATED.pod 20:39
chromatic Any other suggestions for focus?
Coke improve documentation.
especially for users.
chromatic Any particular part? The book? Something else?
Coke tcurtis++ for working on updating the squawk tutorial. 20:40
chromatic: I think the tutorial is the most commonly mentioned bit of broken docs.
chromatic Squaak?
Coke likely. =-)
chromatic That needs NQP knowledge and review. Is tcurtis in charge there? 20:41
Coke he stepped up, so sure. =-)
chromatic Okay, same goal then. 20:42
Anything else we should review for the release?
Coke platforms, TODO those failures on the smolder server... 20:44
particle make sure any web pages related to downloading parrot and asking for help are up to date
Coke (since the smoke obscures real failures)
chromatic Do we have a volunteer to review the download pages?
Sounds like a "Not yet" 20:47
Util Will review DL pages
chromatic Thank you. 20:48
Coke here: trac.parrot.org/parrot/wiki/ResolveExperimentals
chromatic allison, should we discuss the 2.3 - 2.6 series now or next week?
Coke I'll send a message out to list, we can use that to track/vote on anything that we think needs to be supported. 20:49
allison chromatic: some discussion is worthwhile in case of deprecations 20:50
chromatic As in "What did we discover we needed to deprecate?"
allison aye
but we can hold off on the overall planning until next week 20:51
bacek "everything" looks like a good answer :)
chromatic The big shocker for me was how pervasive TT #389 (don't store methods in namespaces) was.
moritz that's because we've been building too long on top of the wrong behaviour 20:52
chromatic Yeah, Class and Object and NameSpace are too intertwined. 20:53
Coke chromatic: note that there are still outstanding bugs related to that fix.
allison bacek: that's for 3.0 :)
bacek allison, ok :)
Coke chromatic: did you mean 2.7-3.0 ? 20:54
bacek I want to deprecated current :main sub selection.
Coke since we're about to release 2.6
bacek: and replace it with what?
bacek E.g. have only explicit :main sub.
chromatic I meant "Should we review how well our process worked for the past three months."
bacek Not "maybe first sub in PIR file if there is no :main"
Coke and what do you run if you have no explicit main?
bacek Coke, exception. 20:55
Coke do you throw an error? do nothign?
what problem is this solving?
bacek Coke, trac.parrot.org/parrot/ticket/1033#comment:7 20:56
Coke, we can't check 0-args subs. Because it can be :main. And :main has some kind of magical invocation with :slurpy args. 20:58
Coke bacek: EWRONGCOMMENT?
bacek Instead, I would like to have explicit :main sub with explicit .param pmc slurpy
allison it seems like fixing it so we check 0-arg subs would be a better solution 20:59
chromatic Removing magic always seems good to me.
bacek Coke, yeah. Read all of them :)
allison, it still deprecation. 21:00
particle chromatic: that's why you love C so much.
cotto_work now's the time to add it
bacek currently ":main" sub can be declared without params.
It works because we don't check 0-arity subs.
So, deprecation should be like ":main Sub must be declared with .param pmc args :slurpy" 21:01
chromatic and no magical "You didn't declare a :main, so we'll pick one"? 21:02
bacek it would be nice too.
Coke whatever we do, we need to make sure both ways are supported in a single release. (probably with a new :tag)
cotto_work Should multiple :main subs be explicitly disallowed too?
allison as long as it's always the first one, there's no real need to require :main
bacek cotto_work, no.
allison these are really two separate issues 21:03
bacek allison, yes.
chromatic Yes, let's keep them as separate issues.
allison if a sub is being used a the main, it has certain arguements and the sub needs to handle them
Coke I would not mind a :run that was like main except required a single of .param pmc foo slur:slurpy.
allison the arguments are orthogonal 21:04
(to whether it's being used as :main)
the second problem seems to be that people are getting confused by an implicit :main sub 21:05
chromatic Issue 1: disallow implicit :main
Issue 2: enable arity checking on 0-ary subs
allison thumbs up
bacek +100500 :) 21:06
chromatic +1 to both for me too
any other comments?
bacek I'll put it into DEPRECATED.pod and on wiki (later today) 21:07
tcurtis On that? Or on deprecations in general?
Coke I think we can get away with adding a warning in this release regarding the deprecated :main tag. (enabled only with -w), and not it the pod. then we can remove it post release.
mikehh how many instances of the inplicit :main / o-ary subs are there?
Coke chromatic: should 2 be "that aren't :main" ?
bacek Coke, no-no-no. :mail should have :slurpy args. 21:08
params
:main 21:09
bacek need coffee...
chromatic We don't do arity-checking on 0-ary subs to enable :main's magical behavior, as I understand it.
allison bacek: it doesn't matter if :main has :slurpy args
bacek: people can choose
bacek allison, :main _should_ have :slurpy. As chromatic said 21:10
particle chromatic: correct, that's my understanding too
allison backe: :main should handle some args, but it doesn't have to handle them as slurpy
chromatic We don't have to enforce :main with :slurpy.
21:10 whiteknight joined
bacek allison, ah, yes. 21:10
chromatic If a programmer chooses to handle arguments explicitly, the program can fail with an arity check and that could be intended behavior. 21:11
particle especially with :main :multi
bacek We just need note in docs.
chromatic Shall we move on to questions? 21:12
21:12 NotFound left
tcurtis I think pmichaud and jnthn want a notice that NQP's object model(and possibly P6object?)'s implementation and maybe API might change in as-yet-unknown ways before 2.9 related to the new implementation thereof jnthn's planning. Not absolutely certain it's a deprecation notice in Parrot or what that they want, though. 21:12
21:12 NotFound joined
chromatic Good point. Can you or someone check on any deprecations there? 21:13
allison P6Object should probably move out of Parrot and into NQP 21:14
chromatic That's probably a deprecation too.
tcurtis I don't think they wanted to deprecate anything specific, iiuc; just a warning that there might be some changes, so that if any changes need to be made to the API, they can still switch NQP over to jnthn's new implementation.
particle then only nqp-based languages can use it
allison it's pretty much only useful to nqp-based languages anyway 21:15
tcurtis allison: PCT uses it. 21:16
particle as do some non-nqp languages iirc
allison then make it part of PCT (and change the name) 21:17
not urgent or anything, just sensible cleanup 21:18
Coke the right way to say "something is going to change and we don't know what" is to make it experimental.
bacek We still need some foundation of objects system in parrot. Otherwise HLL interoperability will be much more painful.
chromatic +1 for experimental
allison it sounds like these are additions, rather than removals
so, the additions can be experimental
and we won't remove the existing features until after 2.9 21:19
bacek: uh, there is an object system
chromatic Do we have good documentation of what "experimental" means?
allison bacek: P6object certainly isn't it 21:20
bacek ok. 21:21
whiteknight chromatic: if we do, it's in the support policy
Coke or in Deprecated.pod 21:22
chromatic I'll check.
Coke but basically, it means "deprecation doesn't apply, sorry, not baked yet.
chromatic Any other questions? tcurtis had one.
tcurtis allison: jnthn is going to be re-implementing P6object with new features(e.g., index attribute lookup, custom dispatchers, faster type-checking, natively typed attributes(though I'm not certain what this means))They don't yet know what changes to the API might be necessary. None might; or some might.
chromatic: mine was about the Squaak tutorial. No need to ask it anymore since Coke brought it up. 21:23
chromatic Other questions?
cotto_work one 21:24
particle chromatic: docs/project/stability.pod iirc
allison tcurtis: right, but if they miss the deprecation notice in 2.6, that just means we leave the existing P6object in place, and they develop the new one with a different name
tcurtis: (which is a good idea anyway, since the old name is confusing) 21:25
tcurtis allison: but would they be able to swap it out in NQP-rx before 2.9?
Coke NQP-rx is an external app.
we bundle it, but I'm not sure it's covered under our policy. 21:26
(we should probably be explicit about stuff in ext/ in that regard.)
allison tcurtis: they can certainly change it in NQP-rx externally, and then we'll have to make the call on whether to update the Parrot bundled copy
tcurtis: but, again, if they change the name of the module, there's no problem 21:27
tcurtis: NQP-rx can use the new PCT::Object (or whatever), and leave the old P6object in Parrot unchanged
Coke gotta run. #offline 21:28
chromatic cotto_work, question?
cotto_work wrt Lorito design, it seems like the discussion would be better-formed if we made an attempt to nail down the design aspects in the approximate order they're listed on LoritoRoadmap. 21:29
Deciding on a set of ops is important, but other issues like register size, types and ffi are already being raised. I'd like to see us address those issues in turn (as much as possible) and deliberately rather than discussing them ad hoc.
Hmm. I guess that wasn't really a question.
call it a suggestion, then 21:30
chromatic In my discussion with allison, she suggested that some sort of spike solution on which we could iterate would help answer these questions.
allison +1
yes, there's a risk on both sides of spending too much time designing in a theoretical context, and of "just throwing something in to work now" and not thinking the issues through 21:32
I would like to see a working minimal set of opcodes quickly
tcurtis atrodo++ seems to have been working on some sort of prototype vm for the opcode set you mentioned in your mail to parrot-dev, allison 21:33
github.com/atrodo/lorito
allison and if we can pair it so we have the advanced discussion on each subsystem as we write them, we'll be doing well
tcurtis: I saw that, looked like a good start
cotto_work I see the value in that 21:34
chromatic Any other questions?
mikehh I also thought the whiteknight++ blog post important 21:35
cotto_work allison, would you say that the next step would be to get something that can run the P&W object model and see which design issues need to be solved to get that code usable? 21:36
s/run/implement/
allison I'm not sure I'm entirely sold on the P&W object model, but is has some good features 21:37
cotto_work Call it a first approximation. If we can implement that, we'll be closer to implementing whatever we end up wanting to use.
allison how about "we'll talk through the object model when we get to that part of the interpreter"? 21:38
we have a whole pile of problems in the existing implementation that we want to solve
the current object model is definitely one of them 21:39
cotto_work I'm thinking "What's the first thing we want our spike solution to be able to do?".
allison and its interaction with namespaces, etc
chromatic I have some thoughts on that.
allison we want a tiny interpreter capable of hosting a full parrot solution
i.e. our first set of opcodes needs to be enough to a) define the other opcodes we want and b) define our PMCs 21:40
bacek cotto_work, "20 dynops + implementation of RPA in it" as prototype
allison bacek: basically, yeah
cotto_work wfm. Hash might be more interesting, but anything like that would be fine. 21:41
allison say, Integer, Number, String, and Array
Hash next
(Hash is a good stress test)
cotto_work ok. So our current goal is a Lorito that can implement something like our current RPA. 21:42
+1
chromatic Anything else? 21:44
bacek nope
chromatic Let's wrap it up.
tcurtis One thing?
I asked jnthn what he thought about the suggestion to rename his new P6object re-implementation and do it separately. Here's his response: 21:45
"The issue would more be that PCT currently uses P6object to provide its underlying object model, and would switch to using The New Thing."
"I will do what is reasonable to make that painless. At present, I expect the impact to be relatively low to most users, especially since most people write stuff in nqp-rx."
"It'll mostly hit people who use p6object explicitly in conjunction with their use of PCT."
"So the deprecatin notice I was thinking of was more along those lines - that PCT could be sat atop a new meta-model implementation with a slightly different API (but not entirely different)."
"I'll do my best to judge the balance between progress and not causing pain, anyways. :-)"
allison so, it's a deprecation cycle on the interface of PCT, that's important here 21:47
it needs a deprecation notice
or, we may not be able to launch some change until after 2.9
21:48 jnthn joined
allison (which is only 3 months away, after all) 21:48
hi jnthn
jnthn hi! 21:49
I hope not to actually affect the interface of PCT
cotto_work quick question: Is it certain that we'll fold strings and PMCs into the same type in Lorito?
chromatic No.
cotto_work ok
jnthn There shouldn't be a need to.
allison cotto: no, just an idea
cotto_work eoq
sorear Is it certain that we'll fold PMCs and Objects into the same type?
allison sorear: yes 21:50
jnthn It's more that it'd have something other than p6object as its underlying meta-model implementation.
allison jnthn: it's perfectly possible to write a deprecation notice around that
jnthn So anyone who relies on peculiarities of P6object WRT to PCT objects would probably get hit.
allison: Yes, I think so.
allison can you describe the parts of PCT where the old interface peeked through? 21:51
e.g. "If you were calling this set of methods on X object..."
chromatic That might be better back in #parrot
jnthn allison: Generally, "if I do .HOW on an object that's part of the PCT eco-system, the object I get back from that might have a different interface" 21:52
allison: That is, it's only if going digging into the meta level.
allison: For the typical person writing grammars and actions in NQP and building PAST nodes, I'd expect close to zero impact.
allison jnthn: yeah, that's not a big deal, and easy to define in a deprecation notice
whiteknight if we fold PMCs and Objects together, will we still have a pluggable object model? 21:53
jnthn allison: I'll try and write on that gives specifics, but also gives enough wiggle room.
*one
chromatic whiteknight, with a good metaobject protocol we can.
allison whiteknight: yes, it means PMC get promoted to pluggable, rather than Objects being demoted to cement
cotto_work whiteknight, that's part of what p&w allows
whiteknight okay, just making sure we don't burn any bridges
allison the "PMC" is just one very primitive object model 21:54
jnthn General notice: while what I'm going to design wil obviously have various p6-isms, in a sense if I don't churn out a meta-model design that's pluggable enough for other languages to do their stuff, I'll probably have failed.
allison jnthn: sure, but not all languages will use it. Python won't, for example 21:55
jnthn allison: :-)
allison: The thing is, at some level we'll need some fundemtnals. 21:56
allison: That is, some small amount of protocol between which all of these different language implementations can talk. 21:57
Just something to keep in mind. 21:58
(And something I'll have in mind as I work on this.)
allison jnthn: agreed 21:59
jnthn: it should be a pretty simple level though
chromatic Can I help somehow?
allison jnthn: as in, we shouldn't require every language to implement the complexity of P6 objects, but p6 objects should be able to talk to the simpler object models 22:00
jnthn allison: Oh, completely.
allison: That kind of thing immediately faces me - for example, the meta-class NQP classes use doesn't want to have all the stuff in it to support full blown Perl 6 either. 22:01
allison: But I suspect there may be an even simpler pre-NQP layer too.
allison jnthn: makes sense 22:02
jnthn I'd like to try and not to go off and design something in complete isolation from what Parrot is doing though. I know there's interest in similar things on the Parrot side. 22:04
(e.g. meta-model improvements)
chromatic That's why I ask. 22:05
allison jnthn: the basic interface is likely to stay the same (i.e. you can call 'add_method' to add a method), though the internals are likely to change substantially in the near future
jnthn chromatic: I'm sure you can help. :-) The point I'm at now is more looking at what I need for Perl 6 and NQP, and what the smallest sane protocol I can build that on is. 22:07
chromatic: I kinda need a bit more time/space on that side of things at the moment, tbh.
chromatic I have a sketch that defines role, class, and object and models behavior based on that.
It doesn't bootstrap though. 22:08
jnthn chromatic: I plan to write up quite a lot of stuff that I'm thinking about.
chromatic: Maybe at that point we (and others who are interested) can compare notes.
(e.g. when I've got something more concrete to offer than "I'd like to do this awesome stuff")
chromatic I'll write some notes too.
jnthn chromatic: I'd be interested to see your sketches too.
OK, great.
There's a lot of things to weigh up on the Perl 6 side. One of my biggest realisations so far has been that Perl 6 really needs a meta-model designed for a gradually typed language, not a dynamically typed one. 22:10
We'd need to work out if, for example, Parrot would also want its its protocol to handle that or just stick with the dynamic parts. 22:11
chromatic Or at least how Parrot can make that possible. 22:12
jnthn (Other fun includes dealing with representations and natively typed attributes into the design...)
chromatic: *nod*
Anyway, I'll get some deprecation note - hopefully a sane one - in. 22:13
Squawk if it's not sane enough. :-)
And I'll blog some meta-model-y bits as I get things together. 22:14
23:07 Chandon left 23:24 cotto_work joined 23:26 jnthn 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!