% particle has joined #parrotsketch % cognominal has left cognominal!~stef@cac94-1-82-67-232-89.fbx.proxad.net % cognominal has joined #parrotsketch % mdiep has joined #parrotsketch % Coke has joined #parrotsketch % allison has joined #parrotsketch Hey guys howdy! hi hello saw coke in person today. he was jet-lagged but cheerful as always s/today/yesterday/ hi all hi leo hi dude % chromatic has joined #parrotsketch chromatic is our designated whip-wielder today, right? Yes he is. Allison, talk to us! c! I'm about to head out the door to drive north Okay. Blocking on anything? I worked on the I/O pdd and on punie conditionals this week lots of good comments on the pdd leo, I'd like to postpone the functions/methods conversation until we get into your interfaces proposal, as I think it makes more sense there yep, exactly % pmichaud has joined #parrotsketch not blocking on anything Having fun? yes!!! Excellent. EOR Chip, you have the same first name as the Parrot lead designer. That means you get to report next. What a stunning coincidence (later all!) % allison has left allison!~allison@ppp-71-139-18-230.dsl.snfc21.pacbell.net I had a lot of fun responding to the namespace questions, and I'm getting a good vibe on finishing the project, which is to say, the vibe that it will be finished. Parrot -will- be finished. (no, not Howard. anyway) I'm enjoying having Allison as a second mind to field architecture issues, it's neat I am having fun, and I'm only blocking on real life ... which is off topic for this list, but does include some travel this week I do have a design question to bounce around a little (dup'd from recent mail), but I think I'll save that for #parrot after the meeting, for those who want to head over there for a beer #endif // Chip Thanks, Chip. Will? Hio. haven't touchec tcl in a while. Think I'm going to hold off doing anything until a few more subsystems ar ein place. However, I think I'm going to work on a new language for a while and exercise the PGE/TGE framework. coke: yay! The new language is APL. And Patrick takes it all back... * pmichaud wonders if he should retract his "yay" which should help break lots more stuff. =) actually, anything that can use PGE is a plus for me (* EOL *) Having fun? now that I have something shiny again, yes. =) Excellent. Leo? last week was GPW + travelling met a lot of interesting folks now it's namespace time - started hacking it in today after some brainwork on weekend EOR * chip saves his APL joke Having fun, Leo? yep, always Excellent. Matt ? I've been blocking on Real Life (school + work) for the past couple months, but it looks like that should free up some in the next couple of weeks. I'm looking forward to hacking [namespace] support for Tcl. Wonderful. Having fun? After that, I've been thinking about trying to find a way to be directly involved in the Perl6 effort. Whether by hacking on PGE or trying to get a handle of how Pugs uses Parrot. (Suggestions welcome for how to help given my skills) I will be when I'm not blocking so much. :-) I think Patrick will unblock a lot of people on your second point soon. that is the plan :-) Anything else, Matt? nope - that's it Thank you. Jerry? lately, i've only had enough bandwidth to hang out on #parrot and answer questions i've been considering changes, like improving test coverage of ops & pmc's, but haven't had the chunk of time i need to implement them That's important. Having fun? i'll be having more fun after my kitchen has been rebuilt, sometime mid-april ZZ Thanks! Patrick? this past week I committed a rules compiler it's in compilers/pge/rulec.pir; essentially it takes an input file that looks like a Perl 6 grammar, and outputs the pir code for the corresponding rules (creating Grammar classes as needed) yow so, we can work on maintaining the perl 6 grammar as a simple .g file, at least down to the expression level I'm brainstorming ideas about a good representation for operators; at the moment the only way to get things into the operator precedence parser is to write pir code to register them one-at-a-time it would be nice to have a specification file format of some sort for this... but I'm kicking that one to the design team to work on for me as soon as I finish my notes on that topic Allison had a similar question with regard to Punie. (punie is already using this, as will APL) I'm also following along with the perl 6 grammar/rules stuff that is being developed in pugs for building under p6 er, p5 Larry has mentioned that it would be better to not come up with wildly different grammars. :-0 er, :-) (fingers are typoed today :-( ) I'm about to finish a very preliminary perl 6 parser for simple statements, I'd like to have that by tomorrow evening but it may be thursday (simple statements including if and blocks, hopefully, but not yet subs) I look forward to that. Having fun? once I have simple statements in place I'll be doing the rest of the development on p6c so, hopefully we'll have lots of people submitting grammar patches at that point :-) I'm also putting together a list of "things others could be working on" I'm having lots and lots of fun, and only restricted by time (not many restrictions this week, kids are away on vacation :-) I do have a question for the group when we get to question time end-of-stuff Noted. Chip, you have the first question. pmichaud: Do you think Parrot needs to take any notice of the difference between a grammar class and a non-grammar class? And a side point, will Perl 6 make such a distinction on its own, so that a class Foo and a grammar Foo can both exist w/o conflict? chip: discussions that we've had on this point so far have indicated that there's not a distinction between a grammar class and a non-grammar class at the moment, a grammar class is any class that is a subclass of class Rule (it may become any class that does Rule, but I haven't thought that far ahead yet) glad to hear that. parsimonious. the big thing that grammars give us is inheritance of rules OK so, one could conceivably create a rule that is completely outside the class Rule space, but inherited rules might be difficult but completely named rules wouldn't be a problem it is pretty much as A05 and S05 have said.... a rule is just a sub, and a grammar is a collection of subs that provides inheritance do builtin rules exist in the Rule namespace? particle: yes all of the builtins are really Rule::alpha, Rule::digit, Rule::ws, etc. well, yeah, but a format was just a sub too, but it had its own namespace and invocation technique thus the question. but I think you've answered it, except why is Rule a role/class when Grammar exists? (or does it?) at the moment there's not a Grammar class defined as such there can be, but it'll just be a subclass of Rule well, let me register a complaint about 'rule foo' defining a sub rather than a Rule. that's pretty silly sub foo makes a Subroutine. rule foo should make a Rule. what does method foo create? touche In many sense I agree with you that "rule foo" seems like it ought to create a Rule. But I'm just going by what A05/S05 said in their stuff; it's a bit challengine -- I'll have to find the p6l thread from last summer where this was discussed however, the generalized container for methods is not called Method, while the container for rules is named Rule? That's pretty evil this was also a fairly detailed discussion last summer in Toronto at the hackathon that's a bad sign. Anything that takes that long to seem like a good idea... :-) but if it's been rehashed, let's not rerehash it any more. chromatic: consider me answered Okay. Patrick has the next question. I think the short summary is that it's tough to have both lexically scoped named rules and grammar-inherited rules and get everything to work out right * chip is happy to allow that X is hard where X is any part of good language design :-) we have to fudge something somewhere. But I don't think I'd have too much issue with renaming the Rule class to be Grammar or something like that (last comment) however, this particular point is bound to cause confusion for people in the future, so I should probably write up a short document about "why things ended up this way", which will either justify it or convince us we need to change it :-) my question for today: is there a "standard" location where we would put parrot executables, such as the rules compiler? in the build tree or 'make install'? i.e., as we start building tools in parrot, it seems like there ought to be a standard location for holding all of them in the build tree (and eventually in 'make install') Given my druthers, I wouldn't like to have a standard location so much as a standard access method my take - these are not substantially different than things which already exist in tools. MANIFEST.generated i.e. in punie/**/Makefile, a rule should be able to say "${PGE_BIN}pge" has entries like [main]bin installable_pdb [main]bin well, let me give the exact use cases I'm thinking of; if punie and the perl 6 parser want to make use of the rules compiler as part of their bootstrap, do they call it directly in compilers/pge or is there a standard place for it? s/bootstrap/build process/ that will be installed to e.g. /usr/local/parrot/bin I'd say, that such tools should be in parrot root or in a (TODO) bin pmichaud: I'd like a middle ground, as implied by my example: They will call it directly in compilers/pge, but the string "compilers/pge" should not appear in the punie Makefile or perl6 Makefile; rather, the build process should either arrange for that macro to be defined or for @PGE_BIN@ to be expanded in Makefile.in that way we can avoid copying binaries to another location in the build tree, which invites mistakes caused by the difference between 'I build it' and 'I built it and copied it to the bulid bin' oh, I see, I missed the "PGE" in "PGE_BIN" I was thinking "PARROT_BIN". "PGE_BIN" works for me I'd leave the full pathname in except for pathname portability issues, really okay, that answers my question well enough for now, thanks * chip wonders why a woman can't be more like a man^W^W^W^W^W^WWindows can't be more like Unix Are there any other questions? Did I miss anyone? coke: apl should excersize the unicode implementation, i expect. do you have a fancy keyboard for coding? I got some Q for chip, but that's more appropriate on #parrot i have a q particle - OS X gives a nice character palette. and I just found out how to get vi to handle utf8 files on osx, so I'm happy. in talking to jesse, i mentioned i'd like to take on the PIR PDD, time permitting. is that welcome? btw time isn't permitting, atm coke: good. and good luck! particle: bring it up to date, you mean? Seems like first-come, first-served is reasonable. You're qualified. particle: that'd be great, factual additions corrections are always welcome, esp. in crowds chip: yes. steal parts from existing docs, and consolidate into PDD form it's currently empty great. i'll make an effort when i'm able oh, yeah. I knew that Anything else? If not, I'll mention that it would be worthwhile for someone to contact Coverity to have them run the renamed Stanford Checker over Parrot. I don't know if they require people to sign an NDA to look over the results though. yowie, that would produce a treasure trove of stuff to fix Yay? Nay? "Ow, stop that hurts!"? http://scan.coverity.com/ <- mentions Perl having 91 bug reports I'd love to see them add Parrot to that (long) list Okay. I'll contact them and see what it requires from us. Thanks Anything else? But come to think of it, I would like them not to make it quite so public We are very pre-1.0 and it could be taken out of context. Just a mild request, if they require publicity to help, that's OK thanks again Fair enough. See you all next week. Will do, and boy I like Tuesday a lot better, cya % chromatic has left chromatic!~chromatic@63.105.17.30 % pmichaud has left #parrotsketch see you all next week % mdiep has left mdiep!~mdiep@c-24-11-80-190.hsd1.mi.comcast.net % particle has left #parrotsketch