Tweety: hi % obra has joined #parrotsketch % pmichaud has joined #parrotsketch % chromatic has joined #parrotsketch Hi! hi I know we have no leo this week % allison has joined #parrotsketch Darn, I had a Leo question. And no mdiep until august His job prevents him from IRCing at work Leo's report: Hi Jesse, I'll be in Delft (.nl) next Tue and dunno yet, if I'll have internet access there at meeting time. Just in case, here's the report: - various accumulated bug fixes - implemented: isa I0, P0, ["Foo"; "Bar"] syntax - released 0.4.4 "Feather" leo pmichaud: you're up next. How's stuff? oh had to take care of a runaway sprinkler system ah, lesseee this week I mostly worked on subroutines and related things made more updates to PGE, added some initial subroutine parsing rules to the grammar did a refactor of the perl6 grammar so that postcircumfix and circumfix operators are handled top-down, as Larry has been suggesting for some time as of this morning I have parameterless subs working, I'm doing parameters now we have the beginnings of infix:<~~> (smart match), which is able to do matches against regexes beyond that, I can't remember what else I did blocking on anything besides grammar? not blocking on anything at the moment not even blocking on the grammar :-) Very cool heh allison: you're up. (oh, I still owe a scheduling message re: YAPC, will compose + send now) I was laptopless for much of last week Oddly, it was actually a positive impact on productivity I spent a good bit of time reading up on XPath and XSLT their syntax is terrible, but the behavior is much what TGE wants so I have a swath of notes on the TGE refactor now I think that's probably my next priority cool Punie is less important now that there are several other languages using TGE EOR *nod* Anything blocking? Laptop happy again? my slightly older laptop is working okay the laptop that died is still questionable (one of those "not quite resolution"s) blocking on time still, so I'm ditching a few more non-parrot things % chip2 has joined #parrotsketch {ENOFEATHER} Ooh. that suggests I should pick on chip next. anything else before I turn to him? And if not... Chip! How's it hanging? pmichaud and audrey both reported an inability to implement "is rw" I translated pmichaud's example into PIR and realized his issue, sorta kinada Then I realized I didn't understand his example really, because it's in Perl 6, and ever since Larry decided that scalars are two PMCs each (container and value) I don't know what semantics to expect for the code he wrote. So that issue is waiting for clarification. (me has answer) (looking fwd) % spinclad has joined #parrotsketch % Coke has joined #parrotsketch I've proposed a unification of classes and namespaces, and there are two ways to go. One way pollutes just slightly the user-visible namespace, but we're doing that anyway with __init, etc., so it's not a big deal IMO The other way makes the class's method namespace notionally an attribute of the class rather than an object with independent life. I look fwd to replies on p6i or comments here if you've read that. I'm going to document [consistently] that init_pmc's parameter is arbitrarily interpreted, and that init_pmc_props is guilty of being very very silly and should be removed. Also that using set_pointer() as a cheat to avoid init_pmc() is naughty. On the agenda: Replying to more such queries and hacking up PDDs into something I like. Also, I'm coming around to an idea that Parrot 2.0 will be our Perl 6, only without the five-years-of-wrangling part. ^D coke: what's p? p? (I have q for chip at question time) (actually, I'll ask via email, nm) up :) APL is coming along since last we spoke. many more operands implemented. Swapped in a stub PMC which will hopefully evolve into an N-dimensional array from the 1d version it is now. (once I learn more about PMCs than I want to, as I want to do something slightly tricky) and I'm just staring at chip's email, trying to figure out what it means for tcl, but hopefully mdiep will take the ball on that one so I don't have to. fin. chromatic: how's things? (What will our Chip 2.0 be?) I added is_deeply to PIR's Test::More. I hate PIR; thus it is now a real language. I would love to see some documentation on how multidispatch works, as it's confusing and not what I expect. I also started porting Pheme to use a real Cons object instead of built-in PMC arrays. Then I ran into more trouble with multi-dispatch. My patch to Pheme is at http://wgz.org/chromatic/tmp/add_cons.patch I don't know if it's my mistake or Parrot's, but it'll block me from any more progress for a bit. That's it. Ok. Question time? pmichaud: question: go for it obra: I already asked in /msg -- will summarize in my email response to chip (on p6i) ok who else? What's Parrot 2.0, chip? Parrot 2.0 [sorry for delay] That's a design reboot, without changing scope. (That's the "not like Perl 6.0" part.) Current or planned? For example, vtables are not what they should be, given MMD. Also, properties are needlessly baroque, if not simply Wrong. This is entirely notional. It's a mental drawer in which to place all the ideas that take the form "X is much better than what we have, and we should really have done that from the beginning, but we _can_ carry on without fixing it" But if we don't eventually actually do it, I shall simply die (or the project-involvement equivalent) of frustration. Could the contents of that drawer move into something more public somehow? Interestin idea! doc/reboot perhaps. doc/2.0/design_notes ? Sort of the Jarkko/Nicholas/Andy bait file. there's a docs/dev already Yes, I shall do so. (I'm trying to make it explicit that it's not for now) Thanks for the suggestion. obra: did you mean design_notes as a subdir, btw? I know this is all arbitrary for tech, but the self-documentation of a file/dir is worth some thought I don't know if I did I'd start as a file svn lets you make it a directory later ;) quite I agree too but having one big file of rambling to start with might invite more participation % chip2 has left chip2!~chip@nat.cloudmark.com and ease of search-and-replace :-) :) what's next? I'll write it up in email, but here's a quick proposal for yapc scheduling chip 8:30-9:10, particle (jerry) 9:10-9:50, me 9:50-10:10 and 10:20-10:40 (split), coke 10:40-11:20, allison 11:20-noon my talk can split into two 20 minute talks no problem, so we still get the break that's "coke and me", isn't it? =-) yes, "coke and me", but you're the distinguishing variable :-) I'm just covering my behind. (must commit skeleton of presentation) pmichaud: marvy thanks don't worry, it's no problem for me to make my talk longer... :-) (that was for coke) btw, I'd like to clarify that 2.0 is only a drawer for ideas at this time. (in case that wasn't already clear) pmichaud: schedule looks good I'm not going to tell anyone how to spend their time, of course, but I don't want to cannibalize 1.0 chip: I think 2.0 is a good idea. We'll especially have things we want to "re-do" in parrot once we have a working perl6. We can eliminate the workarounds and kludgy korners If there are bits of the 2.0 design that remove significant pain from 1.0, it might be worth thinking about scope and cost. How does threading work in 2.0? correctly STM is a good plan, IMO, but I have no immediate idea what demands it will place on the design at the low levels (software transactional memory) ok. anything else? oh, I have a question go for it mainly for chromatic, coke, and patrick % chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net Working on TGE refactors I'm assuming it's better to work in a branch? so it doesn't interfere with your work immediately? I can break it down into pretty small chunks if svn-head always works, I don't care. (I can ask chromatic separately) the big thing is the syntax changes how easy is compat glue for the old syntax? (on phone just a sec) this is going to be a total breakage of old syntax no compatibility layer allison: branch is probably better branch, please, unless it's easy to transition it'll be easy to transition, but it's a little bit of manual edits i.e. I don't really want to update everyone's tree grammars, so better to put it in a branch and move it back into the mainline after everyone has updated in the branch I have a suggestion, just a sec k (And after patrick, that's it for this week. see you real soon) can you start a new directory, tge2? I.e., keep it in trunk thanks, jesse! np what's the implication for later integration? it's a bit of a pain to move things between branch and trunk do people have to change to "TGE2" for now and then later change back to TGE? so yes, as we convert over, we switch to TGE 2 and then later back to TGE (when TGE is fully deprecated) that works I just prefer to stay in trunk. Others might disagree chip? that's fine with me, but it'll probably require test/makefile/etc rejiggering is apparently gone I don't mind the rejiggering back which could be messy, and messy to clean up later for the most part, the user-facing changes should be limited to one major breakage of the syntax otherwise, it's internal cleanups, and adding new options when I did the PGE update a couple of weeks ago, it was a bit of a marathon to get all of the languages up-to-date on it allison: ? allison, if you can coordinate a time for the breakage^Wrefactor, i can help migrate the language code yes, if we have a timeframe for it, it could be done pretty quickly chip: branch or new dir (eg TGE2) for tge refactor? chip: that was a "as architect, do you have any opinions on whether we duplicate directories or branch" but, I think we're settling on neither branching or duplicating If we have to do one, I'd vote for a duplication, to avoid divergence from the HEAD work But it's only a vote patrick, particle: I can plan a day for the shift kewl Is there an "svn ln"? we can organize a day late this week or early next week that works for you all no links. and just make a quick shift (bummer) but branching is easy. since it's COW anyway, i'm off to #parrot if you need me I'll talk to robert (the advantage of a branch, is that everyone can test their languages, and then we can integrate them wholesale) (if the branch is temporally short - e.g. 1 week or so - that should minimize the problems I imagined) an alternate approach -- rename the existing tge to tge2, and build the new one as tge :-) also possible that way we could all update languages now to tge2, and the migrate over as tge becomes ready I don't know the extent of changes you're looking at; if they're really fairly minor, it's not an issue at all though, if everyone switches over to the new one in the branch I'm writing an email now you'll still be able to do everything you can do now including using PIR as the core body of the rule other features I'll add on later but the only thing that will break backwards compatibility is the syntax update anyway, I'll work with whatever comes out whenever it's ready :-) you're so easygoing :) easygoing is least stressful for me very true anybody here ever use the PMC properties? yup in TGE I'm working on the init init_pmc init_pmc_props troika The docs for init_pmc are busted and I'm fixing them, but some of the busted docs refer to a baroque altenration of integral and string keys for the same property is this a feature you're using for properties, or was it supposed to be an initialization-specific hack? (the mixture of ints and strings for prop keys) I think it was actually a weird hangover from an earlier state of Perl 6 design all I use is named access OK um, what about $P0 = getinterp / $P1 = $P0['lexpad';1] is that a complete question? sorry I don't understand i'm not sure if that has to do with the integral / string keys thing, guess not. oh, no, not at all k % allison has left allison!~chatzilla@sub17-30.member.dsl-only.net % Coke has left #parrotsketch % pmichaud has left #parrotsketch % obra has left obra!~jesse@diesel.bestpractical.com % spinclad has left #parrotsketch % sabre has joined #parrotsketch % chip has left chip!chip@feather.perl6.nl % chip has joined #parrotsketch % sabre has left sabre!~sabre@c-67-180-120-5.hsd1.ca.comcast.net % sabre has joined #parrotsketch