|
Parrot 1.3.0 "Andean Swift" released | parrot.org Set by moderator on 23 June 2009. |
|||
|
00:00
patspam joined
00:35
Whiteknight joined
00:39
hercynium joined
|
|||
| dalek | ose: r48 | Austin++ | trunk/src/parser/actions.pm: Bugfix for :phylum() |
01:05 | |
| kid51 | Austin ping | 01:46 | |
| dalek | tracwiki: Austin_Hastings++ | smoking parrot.png attached to SmokingParrot | 01:51 | |
| tracwiki: Smoking (dead) parrot image | |||
| tracwiki: trac.parrot.org/parrot/attachment/...ction=diff | |||
| tracwiki: v5 | Austin_Hastings++ | SmokingParrot | 01:54 | ||
| tracwiki: trac.parrot.org/parrot/wiki/Smokin...ction=diff | |||
| tracwiki: Austin_Hastings++ | smoking parrot.png attached to SmokingParrot | |||
| tracwiki: trac.parrot.org/parrot/attachment/...ction=diff | |||
| kid51 | Oh, that's sick ;) | 01:56 | |
| Austin | Hi, kid | ||
| kid51 | Commented: code.google.com/p/close/wiki/CloseIntro | ||
| dalek | tracwiki: Austin_Hastings++ | smoking parrot.png attached to SmokingParrot | 01:57 | |
| tracwiki: trac.parrot.org/parrot/attachment/...ction=diff | |||
| Austin | Cool. Thanks. (Believe it or not, that's the "toned down" version.) | ||
| I'll have to tone it down some more. | |||
| You said something about TODO tests earlier. That's just "# TODO" after the not_ok, right? | 01:58 | ||
| (at EOL, I mean) | |||
| dalek | tracwiki: v80 | Austin_Hastings++ | WikiStart | 02:05 | |
| tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff | |||
| kid51 | I think I was referring to the general principle of TODO tests, not how they're specifically implemented in PIR (as opposed to in Perl 5). | 02:06 | |
| And I think pmichaud eventually made the same points. | |||
| Austin | Ah. I know they exist, but I don't know what the TAP for them is supposed to look like. I'll google it. | ||
| kid51 | TODO is for what we have yet to implement or for what we know is implemented but not working. | 02:07 | |
| Probably supposed to look like any TODO tests in our Smolder reports. | |||
| Austin | On another subject entirely, how about building a tree specification language? | 02:08 | |
| (in Perl5) | |||
| kid51 | Earlier today, I sent you prv msg saying send me email. | 02:10 | |
| I've no idea what a tree specification language is, so you'd have to spell it out more. | |||
| Austin | Yeah. You still want that? I'd like to just put in on Trac. | ||
| s/put in on/ put IT on/ | |||
| kid51 | Yes, putting it on Trac Wiki would be better. | ||
| Austin | 'kay | ||
| kid51 | Perhaps with a .png of a parrot climbing a tree. | 02:11 | |
| Austin | Hey, I had to google for quite a while to find an image suitable for mangling... | ||
| dalek | tracwiki: v81 | Austin_Hastings++ | WikiStart | ||
| tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff | |||
| Austin | Do you know anything about issue types in trac? | 02:14 | |
| kid51 | No | ||
| Austin | :( | ||
| kid51 | On which page might they be located? Or are an issue? | 02:15 | |
| Austin | I don't know either. We talked @yapc::parrot-bof about reinstating the textual "roadmap" for releases. | 02:17 | |
| Jerry Gay (particle) mentioned something about special issue types. | |||
| kid51 | All I can say is, if you go to the current roadmap, and then are able to resurrect the original version, you might get a clue. | 02:18 | |
| Austin | Laugh | ||
| I don't think you can get there from here. | |||
| kid51 | How about this? trac.parrot.org/parrot/wiki/TracReports | 02:20 | |
| Austin | Right. Cool. That's how it's being done now. | 02:22 | |
| I just want somebody to write some prose that explains the overall "aim" of the milestone releases. | |||
| Like "1.0 is intended to provide a platform for HLL developers" | 02:23 | ||
| or "1.5 is for unicode support" | |||
| whatever. | |||
| Commingling the prose with the task queries would rock. | 02:24 | ||
| kid51 | Post that on list, or pre-post it for #parrotsketch on Tuesday. | 02:27 | |
| kid51 must sleep | |||
| purl | $kid51->sleep(8 * 3600); | ||
| Austin | Ok. Good night. | ||
| Infinoid | We release once a month regardless of which features get in, so the roadmap items aren't really set in concrete | 02:28 | |
| dalek | tracwiki: v6 | Austin_Hastings++ | BigProjectIdeas | ||
| tracwiki: Added TreeUnit reference | |||
| tracwiki: trac.parrot.org/parrot/wiki/BigPro...ction=diff | |||
| tracwiki: v27 | jkeenan++ | ParrotQuotes | |||
| tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff | |||
| tracwiki: v3 | Austin_Hastings++ | SandBox | |||
| tracwiki: trac.parrot.org/parrot/wiki/SandBo...ction=diff | |||
| Austin | Yeah, but I think a little more clarity of vision would help keep us on track, and it might help lower the "on-ramp" for new people. | 02:29 | |
| Infinoid | Vision is great. But volunteer developer resources are very hard to predict | ||
| Austin | Yeah. | 02:30 | |
| I wonder why trac isn't honoring my WikiWords ? | |||
| Infinoid | We should have that turned off except for existing pages | ||
| excessive camelcasing causes strange results in the rss output (and irc logs) | 02:31 | ||
| Austin | I think you did. | ||
| Maybe that's why it's not working. | |||
| Infinoid | goodnight all | 02:32 | |
| dalek | tracwiki: v82 | Austin_Hastings++ | WikiStart | 02:35 | |
| tracwiki: No more wikiwords. Use explicit links instead. | |||
| tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff | |||
|
02:36
janus joined
02:51
zak_ joined
|
|||
| dalek | tracwiki: v1 | Austin_Hastings++ | Glossy-Brochure | 03:22 | |
| tracwiki: trac.parrot.org/parrot/wiki/Glossy...ction=diff | |||
| tracwiki: v7 | Austin_Hastings++ | BigProjectIdeas | 03:25 | ||
| tracwiki: No more wikiwords. Use explicit links instead. | |||
| tracwiki: trac.parrot.org/parrot/wiki/BigPro...ction=diff | |||
|
03:28
Themeruta joined
|
|||
| dalek | rrot: r39894 | pmichaud++ | trunk/compilers/pct/src/PAST/Node.pir: [pct]: Fix 'value' -> 'lvalue', from TT #810 (reported by Austin Hastings) |
03:33 | |
|
03:59
pjcj joined
|
|||
| dalek | TT #810 closed by pmichaud++: PCT - PAST::Val::lvalue() passes through to 'value' | 04:07 | |
| rrot: r39895 | pmichaud++ | trunk/compilers/pct/src/PAST/Compiler.pir: [pct]: Fix bug with 'attribute' scoped PAST::Var nodes (TT #803, report |
04:10 | ||
| rrot: r39896 | petdance++ | trunk (2 files): list_splice() does modify @value_list |
04:30 | ||
| tracwiki: v1 | Austin_Hastings++ | TreeUnit | 04:33 | ||
| tracwiki: trac.parrot.org/parrot/wiki/TreeUn...ction=diff | |||
| Austin | msg kid51 Typed up in stupefying detail at: trac.parrot.org/parrot/wiki/TreeUnit | ||
| purl | Message for kid51 stored. | ||
|
04:34
Zak joined
|
|||
| dalek | tracwiki: v2 | Austin_Hastings++ | TreeUnit | 04:36 | |
| tracwiki: trac.parrot.org/parrot/wiki/TreeUn...ction=diff | |||
| bacek_at_work | pmichaud: around? | 04:37 | |
| pmichaud | around. | 04:38 | |
| bacek_at_work | pmichaud: (new "Iterator") on keys_revamp branch "Iterator" is pure interface class. | ||
| so, there is no point to create it directly. | |||
| pmichaud | bacek_at_work: I don't disagree. | 04:39 | |
| bacek_at_work | pmichaud: ah, ok :) | ||
| pmichaud | I didn't say we should keep the "new Iterator" form -- I said I had no strong opinion about it. | ||
| (which I don't) | 04:40 | ||
| bacek_at_work | ok... | 04:41 | |
| bacek_at_work still having troubles with clear understanding of English... | |||
| pmichaud | no problem. | 04:42 | |
| If I was strongly in favor of getting rid of "new Iterator", I would've said +1 to it. | |||
| If I was strongly opposed, I would've said -1. | |||
| Since it doesn't matter much to me either way, I'm effectively saying "0". :-) | |||
| bacek_at_work | so, now we have only "+0.5" for removing "new Iterator"... | 04:43 | |
| pmichaud | well, you can count mine as a non-vote. | 04:44 | |
| either way, it's not purely a "add up the votes" democracy. :-) | |||
| some votes count more than others. :-) | |||
| bacek_at_work | erm... According to my calculation it's now reduced to "+0.05"... | 04:45 | |
| Austin | What's the trouble with "new Iterator" ? | ||
| pmichaud | anyway, I'm fine if we get rid of "new Iterator". But if someone decides we really need to keep it, then I'm fine with that too. | ||
| Austin: it's kind of a backwards way to get at an iterator. | |||
| in some senses it assumes that all iterators are the same | |||
| Austin | Isn't that the point? | 04:46 | |
| pmichaud | they should have the same API, yes. | ||
| Austin | That all Iterators *are* the same? | ||
| Okay. | |||
| pmichaud | but internally they may be quite different. | ||
| Austin | So the problem is inversion-of-control? | ||
| pmichaud | that's a good way of putting it | ||
| phrased another way -- even in Perl 6 we distinguish RangeIterator from other types of iterators | |||
| Austin | What does "new Iterator" do now? Does it just make an Iterator, or does it call my class and ask for one? | ||
| pmichaud | I think right now it tries to figure out what kind of aggregate you have and construct an appropriate iterator for that | 04:47 | |
| I don't think it asks the class for one. | |||
| Austin | Well, that has to stop. | ||
| pmichaud | But I haven't looked at it directly -- bacek++ would be able to say exactly what it does. | ||
| Austin | (And I was so proud when I got "i = new Iterator, foo" working in close. Sigh.) | ||
| pmichaud | At any rate, going through the vtable interface to obtain an iterator seems saner to me. | 04:48 | |
| bacek_at_work | Austin: check TT#811 | ||
| Austin | Why not go through the method interface? Any reason it has to be a vtable? | ||
| bacek_at_work | Austin: performance reason only. | ||
| pmichaud | cross-hll | 04:49 | |
| the method that language Foo uses for getting an iterator might not be the same method as language Bar | |||
| and we can't force them to be the same, except via the vtable interface | |||
| Austin | So how do I implement a tree iterator for my whatever-tree class? | ||
| .sub get_iter :vtable ? | 04:50 | ||
| pmichaud | right now, you just define the get_iter vtable method | ||
| Austin | I'm still a little leery of that, because of my knee-jerk "no more vtables" reaction. | 04:51 | |
| pmichaud | well, we're not adding a new vtable function in this case -- it already exists. | 04:52 | |
| Austin | But I can see it working. The HLL compiler just emits the vtable override sub, and then it's in PIR space again. | ||
| Okay. #811 +1 from me. | |||
| (For what that's worth.) | |||
| Good timing, Bacek. How many HLL's are going to be affected by this? | 04:53 | ||
| (Close is one.) | |||
| pmichaud | bacek_at_work: in TT#811, the code you give there explicitly checks for 'hash', 'array', or 'string'. Why? | 04:54 | |
| Austin | Pmichaud: We almost had this conversation at PVMW. Is there, or should there be, an analogue to the "Iterable" role in Java? Something that reports support for get_iter? | 04:57 | |
| (Because "type == array or type == string or type == hash" is kinda lame. | |||
| pmichaud | Austin: I think we should just ask the aggregate for an iterator and let *it* throw the exception if it can't do that. | 04:58 | |
| if we want to have a standardized role for "are you able to iterate" without actually creating an iterator -- well, I guess that makes sense too. | 04:59 | ||
| bacek_at_work | pmichaud: because some aggregate can try to create Iterator | ||
| pmichaud | but I'd rather have a stronger use case than this one. | ||
| (in general I'm a fan of not adding things until they're truly needed) | |||
| Austin | No, you're right. I was lost in a haze of possible iterator classes. But that's the implementor's problem. Either don't inherit this behavior, or catch the exception. | 05:00 | |
| bacek_at_work | pmichaud: VTABLE_get_iter will throw exception if it's not implemented. | 05:01 | |
| pmichaud | right. That's what should happen. | 05:02 | |
| That seems to me to be exactly what I'd want to happen. | |||
| bacek_at_work | (adding explicit check for type) If FooAggregate.get_iter will create Iteator" instead of specific FooIterator we'll have infinite recursion. | 05:04 | |
| pmichaud | oh, I see. | 05:05 | |
| although I have difficulty believing that any FooAggregate would turn around and try to create an Iterator on itself, knowing that it will fail. | |||
| Austin | I don't. | ||
| What? I have to deliver an Iterator? Isn't there a PMC for that? I'll just pass the request along. | 05:06 | ||
| pmichaud | sure, but if FooAggregate isn't a string, hash, or array, then "pass the request along" would fail anyway. | ||
| If it is one of those, then it'll still be the infinite loop. | |||
| Austin | Which wouldn't be a problem if they called iter() on the underlying representation, but they'll blow it and call it on themselves. | ||
| pmichaud | so saying that FooAggregate.get_iter might create Iterator is a red-herring sort of argument | 05:07 | |
| because it won't work even if the checks are there. | |||
| Austin | How so? | ||
| pmichaud | right now init_pmc in Iterator checks to see if the aggregate does hash, array, or string, yes? | 05:08 | |
| it also throws and exception if the aggregate is not one of those | |||
| *an exception | |||
| Austin | Right. | ||
| pmichaud | okay. So, let's suppose I'm writing FooAggregator | ||
| er, FooAggregate | |||
| and I get down to the get_iter vtable | |||
| Austin | But we're saying that init_pmc will just call pmc.iter(), right? | 05:09 | |
| pmichaud | it's doing that now (in bacek's version) | ||
| Austin | sorry, that "Iterator.init_pmc()" will just call pmc.iter() | ||
| Yep. | |||
| pmichaud | PMC *real_iter = VTABLE_get_iter(INTERP, aggregate); | ||
| I'm saying that having the check for string/hash/array doesn't provide any protection against the issue bacek identified | |||
| Austin | True. | 05:10 | |
| pmichaud | so, as I was saying... | ||
| we get down to FooAggregate.get_iter and say "oh, I'll just delegate that to the Iterator PMC" | |||
| Austin | But I think we were supposing that it would *always* pass along the call. | ||
| pmichaud | if I try delegating that to the Iterator PMC, bacek claims it'll be an infinite loop if we don't do the checks | ||
| Austin | Right. | 05:11 | |
| Because of the "always pass along" supposition. The code in Trac won't have that problem. | |||
| Bacek, you still here? | 05:12 | ||
| pmichaud | so, we're just helping the pmc author by throwing an exception instead of infinite looping. I can accept that. | ||
| basically, one can call Iterator.init_pmc only for aggregates that are already hash/array/string. | |||
| but of course, if the aggregate is already hash/array/string, then we end up with the same infinite loop. | 05:13 | ||
| and we don't protect against that. | |||
| Austin | I think it was the other way around. Bacek was trying to detect the loop because he wanted Iterator.init_pmc() to just return aggregate.get_iter() | ||
| pmichaud | I don't follow that. The code does aggregate.get_iter() only for string/hash/array | 05:14 | |
| Austin | (Speaking of which, is VTABLE_does the same as type ==, or is that a role? | ||
| pmichaud | vtable_does is more like a role. | ||
| Austin | So anybody who "does" hash gets called? That's even more bogus. | ||
| nopaste.com/p/a5o59fcLb | 05:15 | ||
| pmichaud | right. | 05:16 | |
| that's what my question was leading to. | |||
| Austin | And that's where the infinite loop comes from. | ||
| pmichaud | yes, I understand that. | ||
| Austin | But I like simple code. | 05:17 | |
| pmichaud | putting the checks in there helps a pmc writer when attempting to create a get_iter vtable | ||
| Austin | And that's simple. | ||
| pmichaud | but it does so at a runtime cost for hash/array/string | ||
| (the common cases) | |||
| and, it doesn't protect the pmc writer who is creating a get_iter vtable for an aggregate that does array/hash/string -- that case will still get the infinite loop | |||
| bacek_at_work | (sorry for delays... I'm @work) | 05:20 | |
| Austin kicks work. | |||
| bacek_at_work | Ok, proper check in Iterator.init should be real_iter =VTABLE_get_iter(aggregate); if (VTABLE_type(real_iter) == enum_class_Iterator) ex_throw("Bah! Don't be lazy"); | 05:21 | |
| pmichaud | oh, that would be nice. | 05:22 | |
| although it still infinite loops :-) | |||
| Austin | Yeah. | ||
| :-( | |||
| Maybe a static pointer to current object? | 05:23 | ||
| Are ops thread-atomic? | 05:24 | ||
| pmichaud | personally, I find it's generally difficult to always stop a programmer from infinite looping. | 05:28 | |
| chromatic | Infinoid, I think it's possible, but every time we change the layout of PObj, something goes weird. | 05:29 | |
| pmichaud | (gc bug hunters) -- is it helpful for me to continue reporting the places where Rakudo is failing against parrot trunk? Or should I not bother or wait until specifically asked? | 05:31 | |
| chromatic | It helps me to know if my run of t/spec/S12-methods/what.t, for example, is a failure you expect or if it's a likely GC problem. | 05:33 | |
| pmichaud | at present we don't expect any failures. | 05:34 | |
| some are creeping in from time to time (due to people changing the spectests on us), but I'm trying to fudge/fix those quickly. | 05:35 | ||
| chromatic | Good to know. | ||
| pmichaud | by far the majority of failures are -G related. | ||
| dalek | rrot: r39897 | petdance++ | trunk/src/list.c: the function add_chunk made more sense split into add_chunk_at_start and add_chunk_at_end. There were two branches within and most of each was different. Only two lines of code in common between the two new functions. |
05:50 | |
| pmichaud | sleep time here -- back tomorrow | 05:53 | |
|
05:59
eternaleye joined
06:09
eternaleye joined,
uniejo joined
06:27
buildbot joined
06:31
slavorg joined
|
|||
| Austin | Anybody know what a "KEY" is when declared as a parameter in a .ops file? | 06:46 | |
|
06:47
mikehh joined
|
|||
| chromatic | From the book: | 06:49 | |
| A key value. Something like C<[5 ; "Foo" ; 6 ; "Bar"]>. These are the same as indexes that we use in PMC aggregates. | |||
| Austin | Yipes. | 06:50 | |
|
06:50
iblechbot joined
|
|||
| Austin | I guess it makes sense, but can I convert a S register into a key? | 06:51 | |
| (I'm fighting with 'exists' right now.) | |||
| chromatic | You'd have to use a keyed_str variant vtable. | ||
| Austin | What does that mean? | 06:52 | |
| purl | You're a nut! You're crazy in the coconut! | ||
| Austin | Oh, boy. | ||
| So an INTKEY is presumably a [key] constrained to hold just integers? | 06:53 | ||
| chromatic | It's an INTVAL used for a keyed_int variant. | 06:54 | |
| get_pmc_keyed, get_pmc_keyed_int, get_pmc_keyed_str, etc | |||
| Austin | But I'm getting an error claiming that opcode "exists_i_p_ic" was not found. Since the result is boolean, and the subject is an array or hash type, I'm pretty confident that "exists_i_p" is correct. What should the third type be, if not an integer? | 06:57 | |
| An array of some sort? | |||
| chromatic | INTKEY, I believe. | 06:59 | |
| Austin | How do I construct an intkey? | 07:05 | |
| There's a Key pmc, but it doesn't look promising | |||
| chromatic | Use an integer register as a key; $P1 = $P0[$I0] | ||
| Austin | Sure. But then I can't do multi-dim keys, right? | ||
| It looks like Key is what I want. | |||
| Make a new Key, then push whatever horrible things on the end of it, then pass it right along. | |||
| chromatic | Right. | ||
| Austin | Guaranteed impossible to optimize. :( | ||
| chromatic | Welcome to Sucktown, population Keys. | 07:06 | |
| Austin | Yeah, the comments in the code were a little depressing. | ||
|
07:06
MoC joined
|
|||
| bacek_at_work | hey! I almost cleaned up Keys mess! | 07:14 | |
| Austin | @bacek: Which keys mess? | ||
| I thought you were iterating? | |||
| bacek_at_work | Yes. But Keys are used for Iterating (in trunk) | 07:16 | |
| Thats why they are so messy... | |||
| Austin | Ahh. Yes. | ||
| Should that be true? | 07:17 | ||
| mikehh | All tests PASS (pre/post config, smolder, fulltest) at r39897 - Ubuntu 9.04 amd64 | ||
| bacek_at_work | Austin: "Should that be true?" | 07:19 | |
| Austin | Should an iterator know about however-many levels of keys, or should it be a key containing however-many sub-iterators? | 07:20 | |
| bacek_at_work | no and no | 07:22 | |
| Austin | How should it work, then? | ||
| bacek_at_work | "Keys" are for nested lookups only | ||
| trac.parrot.org/parrot/ticket/761 | 07:23 | ||
| so, iterator should iterate "flat" aggregate. | 07:24 | ||
| Key is "path" in nested aggregates. | |||
| Austin | Okay. | 07:25 | |
| So how do you iterate ? | 07:26 | ||
|
07:26
Gerd joined
|
|||
| dalek | ose: r49 | Austin++ | trunk/ (4 files): Added builtin-exists (for 1-dim items) |
07:32 | |
|
07:37
eternaleye joined
|
|||
| bacek_at_work | Austin: using FooIterator. | 07:44 | |
| Austin | Bacek? | ||
| purl | Bacek is importing the last week's worth of patches from github.com/bacek/parrot/tree/packfile_revamp, I imagine | ||
| Austin | If you've got a multi-level hash/array thing, how are you going to iterate that? | 07:45 | |
|
07:48
eternaleye joined
|
|||
| mikehh | I am getting -> Method 'succ' not found for invocant of class 'Method' - in make spectest again | 07:49 | |
| Austin | mikehh: Sounds like a Rakudo thing, no? | 07:51 | |
| mikehh | I passed most tests yesterday at 13:18 BST and now at 08:52 BST a lot are failing again (latest rakudo on latest parrot) | 07:52 | |
| Austin | If only rakudo spectests didn't succ... | 07:53 | |
| heh heh heh | |||
| mikehh | :-} | ||
| moritz | Austin: no, it calls that method fairly randomly | ||
| bacek_at_work | mikehh: GC bug... | 07:54 | |
| Austin: recursively iterate over? | |||
| moritz | mikehh: could you try again with groups.google.com/group/parrot-dev/...tch?part=2 applied please? | 07:55 | |
| bacek_at_work | time to go home | 08:02 | |
| see you soon | 08:03 | ||
|
08:15
|MoC| joined
|
|||
| mikehh | moritz: I don't think it makes that much difference - slightly different results | 08:39 | |
| nopaste | "mikehh" at 90.209.206.211 pasted "rakudo test failures for moritz" (76 lines) at nopaste.snit.ch/17125 | 08:50 | |
| mikehh | I know this should be in #perl6 | ||
| moritz | no problem | 08:51 | |
| mikehh: thanks very much for trying it out | |||
| mikehh | moritz: I am going to try it again from scratch to see if there is any difference | 08:52 | |
|
08:52
bacek joined
|
|||
| bacek | hi again | 08:53 | |
| purl | oh, you're back! | ||
|
08:56
cotto joined
|
|||
| mikehh | bacek: hi | 08:57 | |
| purl | hello, mikehh. | ||
| bacek | hi mikehh | ||
| purl | hi mikehh is probably still getting some weird results on Kubuntu Intrepid Amd64 - TT#412 | 08:58 | |
| mikehh | bacek: I think that we are still getting GC bugs for rakudo | 09:00 | |
| bacek | I KNOW! :) | ||
| mikehh | I thought that they had cleared up, but it seems they are back | ||
| bacek | There is always another bug waiting... | ||
| mikehh | moritz: I rebuilt and got slightly different results more tests passed - different failures | 09:37 | |
| nopaste | "bacek" at 114.73.176.104 pasted "Bah... Two results of same test run..." (18 lines) at nopaste.snit.ch/17126 | 09:41 | |
| bacek | msg Whiteknight nopaste.snit.ch/17126 special for you... | 09:43 | |
| purl | Message for whiteknight stored. | ||
|
09:54
donaldh joined
|
|||
| jonathan | bacek: Do you have some stack randomization or heap allocation randomization stuff going on? | 09:57 | |
| bacek | jonathan: erm... No idea. Debian/Lenny x86. | 09:58 | |
| jonathan | bacek: Heh. I don't know anything about Linux. :-) | 10:00 | |
| bacek | jonathan: it... exists :) | 10:01 | |
| jonathan | ;-) | ||
| en.wikipedia.org/wiki/ASLR | 10:02 | ||
| That could be why you see indeterminite crashes, anyway. These bugs are very sensitive to memory layout... | |||
| bacek | In Linux, a weak form of ASLR has been enabled by default since kernel version 2.6.12 | 10:05 | |
| Aha! | |||
| jonathan++ | |||
| nopaste | "mikehh" at 90.209.206.211 pasted "differences in make spectest runs in rakudo for moritz" (86 lines) at nopaste.snit.ch/17127 | 10:10 | |
| moritz | mikehh: thanks for the analysis. I'm hilighting pmichaud since it will interest him, too | 11:00 | |
|
11:21
donaldh joined
11:43
bacek joined
11:52
TonyC joined
11:59
masak joined
12:00
Whiteknight joined
|
|||
| Whiteknight | good morning #parrot | 12:01 | |
| moritz | good localtime() | 12:02 | |
| Whiteknight | purl msg bacek that's quite the nopaste! That's the same exact test, passing once and failing again with no differences? Very interesting | 12:03 | |
| purl | Message for bacek stored. | ||
|
12:03
bacek joined
|
|||
| Whiteknight | good morning moritz. I take it slavorg is down? | 12:03 | |
| good morning bacek! | |||
| bacek | good mor^W | ||
| what? I almost gone to bed! | |||
| moritz | seems like | ||
| bacek | bacek@icering:~/src/rakudo.tt452$ ../parrot/parrot --gc-debug ./perl6.pbc t/00-parrot/02-op-math.t | 12:04 | |
| Method 'succ' not found for invocant of class 'Method' | |||
| moritz | ah, it had no op | ||
| thus couldn't hand out ops | |||
| bacek | bah! It's not GC bug. Ot --gc-debug can't catch it... | ||
| Whiteknight | that's good, right? GC bugs are the worst, so any other kind of bug must be better | 12:05 | |
| bacek | Whiteknight: no... I've lost someone to blame... | ||
| Whiteknight | HA! | ||
| that looks to me like it could be a hash corruption issue | 12:06 | ||
| if hashes are losing keys, and if method names are stored in keys... | |||
| bacek | indeed... But this is on my keys_revamp branch where I can reproduce this bug more easily. And I checked every single line in hashes for sanity. | 12:07 | |
| So... I can declare... | 12:08 | ||
| IT'S ALL BACEK'S FAULT! | |||
| moritz | YaY, we have somebody to blame! | ||
| Whiteknight | does that bug ever occur in trunk, or is it just the branch? | 12:09 | |
| bacek | Whiteknight: it is. | ||
| moritz | but we won't start throwing stones until he fixed it :-) | ||
| Whiteknight: trunk too | |||
| Whiteknight | great | 12:10 | |
| moritz | ! | 12:11 | |
| (as in "not") | |||
| Whiteknight | we really need a "sarcasm" operator | ||
| bacek | In Sovi^ Perl6 you can declare OWN operators! | 12:12 | |
| sjn | <sarcasm>you mean like this?</sarcasm> | ||
| Whiteknight | I suggest :P | ||
| bacek | rakudo: say "hi" | ||
| polyglotbot | OUTPUT[hiā¤] | ||
| moritz | rakudo: sub prefix:<sc:>($x) { "<sarcasm>$x</scarasm>" }; say sc:"great" | 12:13 | |
| polyglotbot | OUTPUT[<sarcasm>great</scarasm>ā¤] | ||
| bacek | rakudo: prefix:<:P>($s) { say "<sarcasm>" ~ $s ~ "</sarcasm>" }; :P "Bah!" | 12:14 | |
| polyglotbot | OUTPUT[Statement not terminated properly at line 1, near ":<:P>($s) "ā¤in Main (src/gen_setting.pm:3340)ā¤] | ||
| Whiteknight | rakudo: sub prefix:<:P>($x) {"<sarcasm>$x</sarcasm>"}; say :P" | ||
| polyglotbot | OUTPUT[say requires an argument at line 1, near " :P\\""ā¤in Main (src/gen_setting.pm:2444)ā¤] | ||
| Whiteknight | damnit | ||
| rakudo: sub prefix:<:P>($x) {"<sarcasm>$x</sarcasm>"}; say :P"awesome"; | |||
| polyglotbot | OUTPUT[<sarcasm>awesome</sarcasm>ā¤] | ||
| sjn | :) | ||
| bacek | Bah! :) | ||
| sjn | rakudo: :P | 12:15 | |
| polyglotbot | RESULT[{"P" => 1}] | ||
| sjn | :) | ||
| bacek | Wow. masa^W rakudo bug! | ||
| moritz | why? | 12:16 | |
| purl | Left field. | ||
| moritz | it seems perfectly fine to me | ||
| :P as a term is a pair | |||
| jonathan | Right. | ||
| bacek | is it defaulting to 1? | ||
| jonathan | Rakudo is right there I think. :-) | ||
| rakudo: say True | |||
| purl | true | ||
| polyglotbot | OUTPUT[1ā¤] | ||
| jonathan | rakudo: say Bool::True | ||
| polyglotbot | OUTPUT[1ā¤] | ||
| jonathan | purl! :-P | 12:17 | |
| sjn | rakudo: say "\\rakudo"; | ||
| polyglotbot | OUTPUT[Parrot VM: Can't stat languages/perl6/perl6.pbc, code 2.ā¤main: Packfile loading failedā¤] | ||
| jonathan | fail | ||
| Whiteknight | TEH FAILZ | ||
| sjn | rakudo: say "\\rwhere did the text go?"; | ||
| polyglotbot | OUTPUT[Parrot VM: Can't stat languages/perl6/perl6.pbc, code 2.ā¤main: Packfile loading failedā¤] | ||
| Whiteknight | rakudo: w00t | 12:18 | |
| polyglotbot | OUTPUT[Could not find non-existent sub w00tā¤] | ||
| Whiteknight | rakudo: say "w00t" | ||
| polyglotbot | OUTPUT[w00tā¤] | ||
| Whiteknight | rakudo: say "\\rw00t" | ||
| polyglotbot | OUTPUT[ | ||
| masak | o_O | 12:19 | |
| Whiteknight | that's the solution, you have to w00t it | ||
| raise rakudo's self esteem | |||
| jonathan | rakudo: say "I am The Awesome." | 12:20 | |
| polyglotbot | OUTPUT[I am The Awesome.ā¤] | ||
| bacek | rakudo: sub say($x where $x eq "w00t") { say "Bah!" }; say "great"; say "w00t" | 12:21 | |
| polyglotbot | OUTPUT[Unable to parse multisig; couldn't find final ')' at line 1, near "eq \\"w00t\\")"ā¤in Main (src/gen_setting.pm:3340)ā¤] | ||
| jonathan | block | ||
| bacek | rakudo: sub say($x where { $x eq "w00t" }) { say "Bah!" }; say "great"; say "w00t" | ||
| polyglotbot | OUTPUT[Parameter type check failed; expected Junction, but got Str for $x in call to sayā¤in sub say (/tmp/vqtO1O38Td:1)ā¤called from Main (/tmp/vqtO1O38Td:1)ā¤] | ||
| bacek | erm... | ||
| jonathan | Again, correct, though mis-leading error. | 12:22 | |
| (already we have a ticket for that) | |||
| bacek | ah. ok. | ||
| jonathan | (the Junction should be expanded) | ||
| bacek taking off masak's hat | |||
| jonathan | (internally if there are multiple type constraints they're held in an all junction) | 12:23 | |
| I did a refactor to get type check error handling in one place already. So it'll be easier to fix now. :-) | |||
|
12:24
skids joined
12:32
ruoso joined
|
|||
| dalek | TT #814 created by stifynsemons++: v39897 build failure on Mac OS 10.5.7 | 12:44 | |
| masak | so, I hear there are plans to make a profiling runcore. | 12:59 | |
| I just want to say that this piece of news excites me, and that if you need early beta testers for it, I'm available. | 13:00 | ||
|
13:02
Coke joined
13:07
buildbot joined
13:14
AndyA_ joined
|
|||
| Coke drinks a peach-flavored coffee. | 13:14 | ||
| davidfetter never considered peach as a coffee additive | 13:29 | ||
| how is it? | |||
| Coke | it tastes like a hot, squished, fuzzy peach. | 13:30 | |
| davidfetter | heh | ||
| Coke | bizarre. I'd drink it again. | ||
| davidfetter | :) | ||
| Coke | (which is good, as we have a case of the k-cups here at work.) | ||
| davidfetter | k-cups? | ||
| Coke | k-cups is www.keurig.com/ | 13:31 | |
| optimized for maximal packaging. :| | |||
| davidfetter | ugh | ||
| istm it shouldn't be impossible to make refillable cups | 13:32 | ||
| Coke | you'd think. | ||
| davidfetter | ask 'em :) | 13:33 | |
| www.keurig.com/help/faq.asp#coffeeTea3 | 13:35 | ||
| ugh | |||
| davidfetter ponders internalizing this cost | |||
|
13:36
Andy joined
|
|||
| NotFound | hi | 13:52 | |
| purl | niihau, NotFound. | ||
|
13:52
Gerd left
|
|||
| masak | oh my, a bot massacring Pinyin... | 14:12 | |
| davidfetter | i'm thinking that should be nin3hao3 anyhow | 14:15 | |
| masak | why? because they are not acquainted, or because purl is a bot? | 14:17 | |
|
14:18
soxet joined
|
|||
| davidfetter | the former | 14:18 | |
| masak | I haven't had the impression that natives would be offended if someone said 'ni2' instead of 'nin3' -- at least the difference is less important than, say, 'tu'/'nous' in France. | 14:20 | |
| er, 'vous'. | |||
| davidfetter checks with a "native" | 14:21 | ||
| masak | :) | ||
| jonathan | I found most natives were too busy being amazed that I could say "ni hao" to be offended. ;-) | ||
| masak | yes, that might be it, too. :) | ||
| but I think I've been greeted with 'ni hao' by someone's parents. | |||
| either they were going out of their way to be familiar, or it didn't matter that much to them. | 14:22 | ||
| davidfetter | it's how you greeted them, if i understand this right | ||
| and i'm guessing you get a lot of leeway as a ferriner | 14:23 | ||
| masak | I think they greeted me first, but ok. | ||
| Coke wonders if chinese have a concept similar to gaijan. | 14:30 | ||
| Coke needs more koohii. | |||
| masak | Coke: do you mean 'gaijin'? | 14:31 | |
| Coke | whoops. | ||
| I surely do. | |||
| what little japanese I had is nearly gone. =-) | |||
| masak | yes, the same word exists in Chinese. | 14:32 | |
| NotFound | I think that worrying about japanese traditions is like learning etiquette of Don Quijote's times before travelling to Spain X-) | ||
| masak | I should say 'Mandarin' there, actually. | ||
| it's wai4ren2 in Mandarin. | 14:33 | ||
| dalek | TT #815 created by fperrad++: Add a step for Configure | 14:36 | |
|
14:41
chromatic joined,
iblechbot joined
|
|||
| davidfetter | <-- mei3guo3ren2 | 14:42 | |
| (i think i got the tones right) | |||
|
14:49
Administrator joined
|
|||
| jimmy | Did anybody need help about chinese? | 14:49 | |
| coke? | 14:50 | ||
| purl | coke is probably Will Coleda <mailto:will@coleda.com> or perpetually annoyed. | ||
| davidfetter | jimmy, we were wondering under what circumstances "nin3 hao3" is more appropriate than "ni3 hao3" | 14:51 | |
| jimmy | Is that a joke? | ||
|
14:52
PacoLinux joined
|
|||
| jimmy | masak: good afternoon | 14:53 | |
| masak | jimmy: no hai! hao jiu bu jian le! | ||
| erm, s/no hai/ni hai/ | 14:54 | ||
| jonathan | .oO( is no hai Chinese for oh hai? ) |
||
| davidfetter | jimmy, nope | ||
| masak | my Lolcal is destroying my Mandarin. :/ | ||
| s/cal/cat/ | |||
| jonathan | lol! | ||
| davidfetter | heh | ||
| masak | also, just to practice: jimmy: ä½ å„½! å„½ä¹ äøč§äŗ! | 14:55 | |
| jimmy | masak: hello,no time no see. | 14:57 | |
| masak: long time no see. | |||
| purl | No...I've been watching you. That thing you do with the candle is most impressive. | ||
| masak | purl: you really need to be quiet more often. | 14:58 | |
| purl | masak: sorry... | ||
| masak | it's an interesting fact that 'long time no see' is one of the few borrowings from Chinese into English. that's why it looks ungrammatical in English. | 15:00 | |
| jimmy | davidfetter:I think that's a joke. | 15:04 | |
| masak: yeah | 15:05 | ||
| gaijin ļ¼ tigao? | 15:08 | ||
| tisheng | 15:09 | ||
| Coke | yah, I didn't mean a word that means foreigner, but if it had the same connotations. | ||
|
15:10
tokuhirom_ joined
|
|||
| jimmy | Please give me some english words and I'll list all words in chinese.. | 15:11 | |
| chromatic | pants | 15:12 | |
| killer robot | |||
| hovercraft | |||
| eels | |||
| masak | futon | ||
| chromatic | monkey butter | ||
| purl | monkey butter is probably www.jwz.org/gruntle/monkeybutter.html or www.jwz.org/gruntle/ or cookie.allrecipes.com/az/MnkyPBBars.asp | ||
| masak | Coke: there's a pseudo-prefix 'lao3' to words which denote scary things. for example 'lao3hu1', "tiger". it can also be applied to foreigners, 'lao3wai4', but the usage is controversial nowadays, I think. | 15:13 | |
| jimmy might be able to fill in the gaps in my knowledge here. | |||
| jimmy | chromatic: another joke ? | 15:14 | |
| masak | jimmy: yes. :) | 15:15 | |
| jimmy: but I would like to see translations of those words. | |||
| jimmy: for the hovercraft and the eels, see en.wikipedia.org/wiki/Dirty_Hungarian_Phrasebook | |||
| Hunger | :) | 15:16 | |
|
15:20
donaldh joined
|
|||
| Coke read's Ovid's post with some curiosity. | 15:31 | ||
| jonathan | "It wasn't me!" | 15:32 | |
| Coke hasn't been following p5p, so only sees the occasional blog post. | |||
| masak also | |||
| pmichaud | which post in particular, here? | 15:33 | |
| Coke | use.perl.org/~Ovid/journal/39237?from=rss | ||
| Coke finds www.nntp.perl.org/group/perl.perl5....48155.html also, which is related. | 15:37 | ||
| ah. apparently I am not as far behind on p5p news as I thought, as that is from last night. | 15:38 | ||
| sad. | |||
| moritz | also consttype.blogspot.com/2009/07/resigning.html | ||
| PerlJam | oh! I nominate chromatic ;> | 15:40 | |
| chromatic | No thanks; I have my doubts about the pumpking concept in general. | 15:41 | |
| Andy | Any volunteers to make Perlbuzz more professional? | 15:42 | |
| Because apparently that's what it's supposed to be. | |||
| Whatever "professional" is. | |||
| pmichaud | Andy: is this in response to a comment where someone said "it needs to be more professional"? | 15:43 | |
| Andy | consttype.blogspot.com/2009/07/perl...seful.html | ||
| moritz | someone is very disappointed | 15:44 | |
| pmichaud | fwiw, here's my take on the role of "pumpking". The pumpking's primary job, as I understand it, is to oversee the development process. But the primary metric by which a pumpking is to be evaluated has to be by the quality of whatever gets released. That means there have to be releases. | 15:47 | |
| jimmy | sorroy,I can't follow you, masak | ||
| pmichaud | If there are no releases, then as far as the larger community is concerned, there's no progress. This was one of the major problems that plagued Perl 6 development until recently -- no releases implies no progress, regardless of how much "work" has actually been done. | 15:48 | |
| masak | jimmy: about the hovercraft. then never mind. | ||
| moritz | pmichaud: I guess you know that the p5p pumpking has much more to do and say than that | 15:49 | |
| jimmy | davidfetter:mei3guo2ren2? | ||
| davidfetter | jimmy, yeah, as you can tell, my mandarin is pretty limited ;) | 15:50 | |
| jimmy | well, not all chinese know mandarin. | 15:51 | |
| good night, everybody. | |||
| chromatic | The pumpking job is difficult and thankless: www.modernperlbooks.com/mt/2009/06/...pking.html | ||
| PerlJam | Isn't that some of the evidence that perlbuzz is unprofessional? :) | 15:53 | |
| Andy | how so? | 15:54 | |
| chromatic | I believe that was sarcasm. | ||
| PerlJam | indeed. | ||
| chromatic: though I'm not sure whether to ++ or -- you for being the proverbial last-straw for Rafael. | 15:55 | ||
| pmichaud | moritz: I didn't say the only metric; I just said the primary one. If there's another metric that is more important, I'd like to hear it. | ||
| Andy | PerlJam: Screw you, it was Perlbuzz that was the last straw! | 15:56 | |
| It wasn't chromstic. | |||
| I want credit for it! | |||
| After all, "Someone is actively trying to damage the community image of P5P out there, and perlbuzz is helping him." | 15:57 | ||
| PerlJam | Andy: sorry, perlbuzz wasn't mentioned by name in the resignation letter. | ||
| Andy | Yeah, but we know better! | ||
| chromatic | How about +0? I've explained my goals from the start. | ||
| particle | stop looking backwards. it's time to start up the "perl is dead" threads again. | ||
| Coke | I would like to point out that this channel is logged and sarcasm is hard to read. | ||
| chromatic | Also sarcasm is rarely helpful online. | 15:58 | |
| Andy | s/ online// | ||
| moritz | pmichaud: I was not referring to the metrics, but to the role. In Perl 5 it's not only "overseeing", but also "applying patches", "releasing", "tracking bugs" etc. | ||
| pmichaud | moritz: sure... but all of those only matter if they lead to a release. | ||
| moritz | right. | 15:59 | |
| pmichaud | that was the point of my comment above. | ||
| the pumpking doesn't have to apply patches, he simply has to make sure that patches get applied. the pumpking doesn't have to track bugs, he simply has to make sure they are being tracked (and addressed). | 16:00 | ||
| Sometimes the pumpking actually *does* those tasks, yes. But delegation and distribution of tasks are what scale. | |||
| s/Sometimes/Often/ | 16:01 | ||
|
16:03
PacoLinux joined
|
|||
| pmichaud | jonathan: still here for lexicals discussion? | 16:03 | |
| jonathan | pmichaud: yes, sure | 16:04 | |
| pmichaud | okay. | ||
| so, right now a lexpad stores register numbers | |||
| Andy | I hope nobody minds my refactoring from last night. | 16:05 | |
| jonathan | Right. I'd rather not change that if we don't have to. | ||
| Andy | behaviors defined by a single boolean make me sad | ||
| even if that boolean is wrapped in an enum | |||
| pmichaud | essentially I think that we give every Sub a LexPad that isn't tied to a register frame | ||
| sorry, that's wrong. | |||
| rephrasing | |||
| every Sub gets a register frame for its LexPad | 16:06 | ||
| its static LexPad | |||
| this is, in fact, what essentially happens now when we end up autoclosing subs -- we create dummy register frames for the autoclosed portion | |||
| jonathan | OK. | 16:07 | |
| pmichaud | that static register frame is then what would hold the pre-initialized values | ||
| jonathan | OK. | ||
| pmichaud | I _think_ that's something of the way I had been thinking of things | ||
| jonathan | That sounds sensible to me so far. | 16:08 | |
| The next question is, how do we know when we're setting them into this context? | |||
| Do we know if just because we auto-closed? | |||
| So we hand over the original frame/create it, rather than cloning one? | |||
| pmichaud | no, not exactly. | ||
| pmichaud thinks a second. | 16:09 | ||
| oh, maybe we could prototype something in PIR | |||
| now that I'm thinking about it | |||
| let me check a couple of things | 16:10 | ||
| okay. | 16:12 | ||
| oh, one other item... checking | 16:13 | ||
| okay, how about this? | 16:14 | ||
|
16:14
Theory joined
|
|||
| pmichaud | right now, we have .loadinit code that attaches properties to Parrot Subs to make them into Rakudo subs | 16:14 | |
| as part of that .loadinit sequence, we | 16:15 | ||
| create a new LexPad | |||
| populate the LexPad with our pre-initialized variables (properties, values, whatever) | |||
| attach that LexPad to the sub | |||
| jonathan | Where "populate the lexpad" means? | 16:16 | |
| pmichaud | example: my Foo @array; | ||
| in the lexpad we would create a Perl6Array, attaching 'rw' property and the 'type' property to it | |||
| jonathan | nod | 16:17 | |
| OK, better question is: show me what that'd look like inside the loadinit | |||
| pmichaud | just a sec | ||
| jonathan | (esp the "create a new lexpad" step) | ||
| pmichaud | oh, that part is easy | ||
| lexpad = new 'LexPad', lexinfo | |||
| Theory | chromatic: I blame you. | 16:18 | |
| jonathan | lexpad['$foo'] = $P0 # where does it actually store this? | ||
| chromatic | For making lexpads easy, Theory? | 16:19 | |
| Theory | um | ||
| pmichaud | oh, lexpads aren't hashes | ||
| darn. | |||
| jonathan | Right. | ||
| pmichaud | okay, we create a hash then | ||
| jonathan | That's what makes this a tad tricky. | ||
| pmichaud | just create a plain hash, then | ||
| and we'll attach the hash | |||
| jonathan | At which point we get to, we make a hash containing the initial values and attach that, and then copy at the start of the sub. | 16:20 | |
| pmichaud | right. | ||
| "copy at the start of the sub" can be a dynop for now | |||
| or it can be a PIR sub | |||
| jonathan | Maybe employing a dynop to do that copy so we don't have to (a) call - slow or (b) emit a wobload of inline PIR into every sub. | ||
| Oh, there's always (c) a macro | 16:21 | ||
| pmichaud | well, I think the big win is that we're not constantly creating PMCs for type, rw, etc. | ||
| jonathan | But you don't like those. :-) | ||
| pmichaud | because those get shared. | ||
| jonathan | (And where to keep them is a pain too...) | ||
| I like the dynop approach. | |||
| pmichaud | I think I'd actually start with PIR | ||
| ultimately it should be a speed win | |||
| jonathan | What, call a PIR sub? | 16:22 | |
| pmichaud | yes. | ||
| jonathan | Yeah, can do that for a first cut. | ||
| But thing is | |||
| will $P0 = clone $P0 # where $P0 is a Perl6Array | |||
| Actually clone the metadata? | |||
| pmichaud | currently, no. | 16:23 | |
| but in reality, we don't want it to clone the metadata | |||
| we want to use setprophash | |||
| jonathan | No, that's why I was asking. | ||
| Did setprophash get implemented yet? | |||
| pmichaud | I think so. If it didn't, though, we can always iterate getprophash and bind individually. | ||
| davidfetter wonders what a phash is | |||
| jonathan | Or write setprophash dynop and propose it for moving into core. | ||
| pmichaud | it's also possible that we really don't want to do a clone | 16:24 | |
| although if we're expecting things to have initial values, then perhaps we should (more) | |||
| but we could have the "initial lexpad" simply keep track of the type of things to be created, rather than have an initial copy | 16:25 | ||
| jonathan | I suspect initial copy may be easier. | 16:26 | |
| pmichaud | I'm wondering if it does bad things on startup, though. | ||
| jonathan | Such as? | 16:27 | |
| pmichaud | a user-defined object might have side effects to creation | ||
| and creating one prematurely might cause problems | 16:28 | ||
| jonathan | ah, hmm | ||
| This gets kinda "fun" though. | |||
| Because e.g. traits are meant to be applied _once_. | |||
| Consdier | |||
| my Int @arr; | |||
| We're meant to call trait_mod:<of>(@arr, Int) once. | |||
| Ever. | 16:29 | ||
| But you do bring up an interesting problem. | |||
| pmichaud | I don't see the tricky part to that. | ||
| jonathan | Well it means that we need to create a Perl6Array and apply that trait to it. | ||
| And then "re-use" that already-set-up container. | 16:30 | ||
| pmichaud | we can't create something that says "become a Perl6Array upon register frame activation" and apply the traits to that? | ||
| jonathan | Like, on the first call? | ||
| pmichaud | I see your point, yes. | 16:31 | |
| jonathan | That'd mean the loadinit woulnd't be able to apply the triats, it'd just have to store a thunk that did. | ||
| pmichaud | well, it can put traits on the thunk | ||
| and the thunk keeps those traits when it's unthunked | 16:32 | ||
| jonathan | And then we call that thunk once. | ||
| pmichaud | we're already going to have to do setprophash anyway | ||
| jonathan | True. | ||
| Also | |||
| It means there's much less work that we have to do at startup | |||
| e.g. if a sub is never called, we don't spend time setting stuff up for it. | |||
| pmichaud | right, that's kinda what I was aiming at. | ||
|
16:32
Austin_zzz joined
|
|||
| pmichaud | we still have an issue, there, though -- and that's dealing with Parrot's autoclose | 16:33 | |
| PerlJam lauds chromatic to offset Theory's blame. | |||
| jonathan | Though it does mean for every block we'll have a loadinit *and* a setup thunk block. | ||
| Theory | heh | ||
| pmichaud | well, I wasn't necessarily thinking of the setup thunk as being a block. | 16:34 | |
| in the parrot sub sense | |||
| just enough information attached to the sub so that we can dtrt | |||
| jonathan | hmm | ||
| pmichaud | the same way that signatures aren't blocks, they're metadata that provides !SIGNATURE_BIND with enough detail to dtrt | ||
| heh | 16:35 | ||
| jonathan | Aye, I'm just worried we're going to get ourselves into a horrible tangle if we're not very careful. | ||
| pmichaud | actually, our initial lexpad is really just more signature data. | ||
| i.e., a block's lexinfo could be considered part of its signature. | |||
| jonathan | Because new traits are a language tweak really. | ||
| And we need to make sure we dispatch the trait application in the correct lexical scope and from within the correct namespace. | 16:36 | ||
| pmichaud | that argues against combining the .loadinits | ||
| (we had talked about combining .loadinits as a startup optimization -- this would seem to say we can't do that) | 16:37 | ||
| jonathan | Aye, for trait application this gets a bit more scary. | ||
| If we start doing stuff like that from the wrong lexical scope, and we miss out on lexical multi-variants, we're going to be in trouble. | 16:38 | ||
| pmichaud | okay. | ||
|
16:38
sekimura joined
|
|||
| pmichaud | can I ask for a day or two to let some of this percolate in my head a bit (more) | 16:38 | |
| I had only been thinking about things from a purely parrot perspective, without much thought to trying intermediate steps | |||
| jonathan | You can. I'm actually going to be offline again for end of this week and next week. | ||
| pmichaud | oh, that might work out really well then | 16:39 | |
| jonathan | (Seeing family etc) | ||
| I pondered taking a laptop with me, but where I'm going to be doesn't have so much connectivity options. | |||
| pmichaud | I think I can come up with some ideas about being able to do much of this in existing parrot, without introducing radical changes | ||
| jonathan | Plus I think what we're talking about is a bigger refactor than I can really pull off in the next day or two. | 16:40 | |
| pmichaud | either way, I think I'll have an idea of whether radical changes are needed so we can get them in the deprecation cycle before the 21st | ||
| I agree, it's pretty big. | |||
| but I like the idea of doing it in smaller steps | |||
| and we should get some performance wins along the way | |||
| (even in PIR) | |||
| jonathan | OK, that sounds good. | 16:41 | |
| pmichaud | shall we plan a bit of scheduling between now and yapc::eu ? | 16:42 | |
| you're offline from approx July 9 to July 17 ? | 16:43 | ||
| jonathan | The weekend after that too. | ||
| pmichaud | so, to about July 19 ? | 16:44 | |
| jonathan | (Heading back then) | ||
| Right. | |||
| pmichaud | July 19 I'm traveling to oscon, will be at oscon 20-24 | ||
| jonathan | OK. | ||
| pmichaud | returning home on 25 | ||
| I expect to be available while at oscon, of course | |||
| jonathan | Didn't you have some issues with the net connectivity there last year? | ||
| pmichaud | but it'll be somewhat like yapc, where I'm also doing other on-site things (like giving presentations) | ||
| yes, I did, but that was on my old laptop. | 16:45 | ||
| I have new laptop this year :-) | |||
| jonathan | :-) | ||
| pmichaud | also, last year was at the oregon convention center | ||
| although I guess it's o'reilly that handles the networking in any event | |||
| regardless, my new laptop seems to have a much more robust wifi card | |||
| jonathan | Ah, good. | 16:46 | |
| pmichaud | I've noticed much fewer connectivity issues with it wherever I go. | ||
| jonathan | Wow, I hadn't realized how soon YAPC:EU was... | ||
| pmichaud | so I don't expect wifi to be an issue | ||
| anyway, I'll be at oscon 20-24. Parrot release is 21. Rakudo release would be 23. | |||
| after that, we have one week before yapc::eu | 16:47 | ||
| jonathan | Aye. | ||
| pmichaud | anything big we want to have done going into yapc::eu ? | ||
| most of what I've been planning to focus on for yapc::eu hasn't been directly code related | 16:48 | ||
| here are (some of) my desired outcomes from yapc::eu | |||
| > 1. Detailed plans for Rakudo development over the next 6 months | 16:49 | ||
| > 2. Identification of specific features and timeline for a "Rakudo 1.0 release" | |||
| > 3. Clarification of Perl 6 specification issues that are blocking development | |||
| > 4. Publication of items 1-3 above | |||
| > 5. Presentation of "Hacking Rakudo Perl" at YAPC::EU | |||
| > 6. Recruitment of more developers and users to Perl 6 and Rakudo Perl | |||
| I'm thinking of adding | |||
| jonathan | I think at a code level there's not much I want to have pre-YAPC. | ||
| Other than making sure that all code in my yet-to-be-written talk works. ;-) | |||
| pmichaud | > 7. Detailed review of rakudo's implementation status at synopsis sub-section level | ||
| jonathan | That - 7 - would be very helpful in really gauging where we are at. | 16:50 | |
| pmichaud | That was obra's suggestion | ||
| jonathan | I expect doing it properly will take at least half a day. | ||
| pmichaud | I agree it would be hugely helpful. | ||
| well, I'm thinking I should have a draft of it pre-yapc::eu | |||
| jonathan | I'd already considered printing off S12 and S14 and going thorugh those highlighting what's done. | 16:51 | |
| And not done. | |||
| pmichaud | I was thinking of simply grabbing "=head\\d" and "=item" lines from the synopses, and marking those. | ||
| jonathan | That'd be OK too. | ||
| pmichaud | marks would be "done, mostly done, a little done, not at all" or something like that | 16:52 | |
| jonathan | Thing is though, in S12 I think we can count 1 heading that we don't have any coverage of yet. | ||
| So I'd really like to know what's left. | |||
| Same with S14. | |||
| pmichaud | right | ||
| anyway, maybe I can put together a structure for marking progress | 16:53 | ||
| jonathan | That would be good to have. | ||
| pmichaud | might even just end up being a (online) spreadsheet | ||
| jonathan | Then we can review it together at YAPC::EU | ||
| pmichaud | at least as a start, until we see what sorts of automated tools we might build for it | ||
| yes, and perhaps bring others in on the review | |||
| jonathan | That too. | ||
| pmichaud | presenting it might make a good lightning talk :-) | 16:54 | |
| jonathan | Yes! | ||
| Especially if we can make it look pretty ;-) | |||
| pmichaud | of course | ||
| I might even try to do a version as an oscon lightning talk, but the timing on that might be a bit tricky | |||
| maybe I'd just do a small subset, like S03-S05 | 16:55 | ||
| then we have the full thing for yapceu | |||
| jonathan | nod | ||
| pmichaud | okay, sounds reasonable | ||
| jonathan | The ones I'd be interested to go through are like S02/S03/S04/S06 | ||
| pmichaud | agreed | ||
| jonathan | As I've really not got a good feel for just how much of those we already cover. | ||
| pmichaud | we do pretty well on many things | 16:56 | |
| jonathan | S12 and S14 I've been working very actively on. | ||
| pmichaud | S06 is probably our weakest point from that set | ||
| jonathan | So I've got a good picture of where we're at. | ||
| Even looking through the headings in S06 though | 16:57 | ||
| The initial set we seem good on | |||
| Ah, but feeds and macros are big missing bits | 16:58 | ||
| Also some of the more complex sig stuff | |||
| pmichaud | right | 17:01 | |
| and we still don't handle named arguments correctly :-( :-( | |||
| I blame Parrot. | |||
| jonathan | Aye. | 17:02 | |
| :-( | |||
| dalek | rrot: r39898 | NotFound++ | trunk/src/io/unix.c: [cage] reverting change in r39869 that broke c++ build |
17:05 | |
|
17:17
jhorwitz joined
|
|||
| jdv79 | are traits working in rakudo? | 17:18 | |
| pmichaud | which traits? | ||
| jdv79 | The ones doc'd in S14 | 17:19 | |
| jonathan | Ah, writing your own custom traits? | ||
| jdv79 | i have a module i'd like to port from Moose and i think i need traits to do it | ||
| jonathan | They're working to some extent. I comitted the initial refactor to start getting them in place yesterday. | 17:20 | |
| So it's really bleeding edge at the moment. | |||
| jdv79 | oh. i'll take a quick gander then. thanks. | ||
| jonathan | gist.github.com/141544 # enough is done in Rakudo that things like this work, for exampl | 17:21 | |
| e | |||
| Traits on subs you're likely to have no problem with. | |||
| Or few. | |||
| Traits on variables, there be dragons at the moment. | |||
| I'm very interested in any issues taht you run into though, of course. | 17:22 | ||
| Tene | Wow, one-pint swallows. | 17:32 | |
| jonathan has impressive drinking skills. | |||
|
17:35
mberends joined
|
|||
| jonathan | ;-) | 17:35 | |
| davidfetter | mmm...drinks | 17:39 | |
| dalek | rrot: r39899 | fperrad++ | trunk (4 files): [config] refactor the generation of has_header.h with a template |
17:49 | |
| ose: r50 | Austin++ | trunk/ (3 files): Fixes issue #20. Added 'split' builtin, tests. |
17:53 | ||
|
17:53
ruoso joined
17:54
buildbot joined
17:55
zak_ joined
18:05
rdice joined
|
|||
| Coke reads code.google.com/p/close/wiki/CloseIntro and thinks (wait, what about NQP?) | 18:08 | ||
| or .hll_macros, for that point. | |||
| ... or jolt. | 18:09 | ||
| (cola? some beverage-based lang.) | |||
| not that those necessarily obviate close, but mentioning why they were insufficient or overkill or whatever would be helpful. | |||
| Austin | What's the NQP syntax for storing something in an integer register? | 18:11 | |
| jonathan is curious to look at how Austin++ got storage in int registers working | 18:12 | ||
| Austin isn't telling. | |||
| (Until 0.3) | |||
| jonathan | aww. :-( | ||
| Rakudo will need to do that for it's lowercase int tyep. | |||
| *type | |||
| Austin | Yeah. | ||
| "Close milestone 0.3" is actually a PCT rewrite. | 18:13 | ||
| Or should I say "feature fest"? | |||
| Tene | Austin: NQP syntax *will* be: my int $x; | ||
| pmichaud | I asked that question on the mailing list ("why is NQP insufficient?") too but saw now response | 18:15 | |
| s/now/no/ | |||
| but yes, the syntax for putting things in int registers is my int $x; | |||
| also my num $x; and my str $x; | 18:16 | ||
| dalek | rrot: r39900 | jonathan++ | trunk/runtime/parrot/library/P6object.pir: [p6object] Remove redundant line. |
18:17 | |
| Austin | I kind of figured that "NQP is insufficient" == "not(X is written in NQP)" for some set of x | ||
| pmichaud | I don't understand. | 18:18 | |
| that simply because we haven't written X in NQP yet, that means that NQP must be insufficient for writing X? | |||
| Tene | Yes, that's what he's saying. | 18:19 | |
| Austin | Pretty much. | ||
| pmichaud | hmmm. | ||
| Austin | Lots of files ending in .PIR, not so many in .NQP in the lib dirs | ||
| pmichaud | well, sure, most of those .pir came long before NQP | ||
| and nobody's had a strong reason or inkling to try rewriting them | |||
| ("if it ain't broke...") | 18:20 | ||
| jonathan | pmichaud: I don't know if you have noticed the following during the Parrot build: | ||
| ..\\..\\parrot.exe C:\\Consulting\\parrot\\trunk\\runtime\\parrot\\library\\PGE\\Perl6Grammar.pir --output=src\\Grammar_gen.pir src\\Grammar.pg | |||
| in file 'C:\\Consulting\\parrot\\trunk\\runtime\\parrot\\library\\PGE\\Perl6Grammar.pir' line 174 | |||
| Duplicated IDENTIFIER 'namespace' | |||
| pmichaud | jonathan: yes -- there's a patch for it. | ||
| I just haven't tested/applied it yet. | |||
| jonathan | OK. | ||
| it just whizzed by as I was building and I wondered if you'd spotted it too :-) | 18:21 | ||
| Austin | What's the return type of an unset attribute from PCT::Node? | ||
| pmichaud | Undef | ||
| Austin | Thanks. | 18:22 | |
| pmichaud | Austin: any chance you could rewrite the prose to not claim that NQP is insufficient...? ;-) | ||
| Austin | Sure. | ||
| pmichaud | it did seem like a very strong claim when I read it. | ||
| Austin | I've got a rewrite-request pending. Probably today. | ||
| pmichaud | okay, thanks. | 18:23 | |
| btw, I think TT #803 is fixed. I didn't close the ticket yet because I'm trying to figure out if/how I want to write a test for it. | |||
| Coke | assign it to moritz! =-) | 18:24 | |
| ... just use the NQP test? | |||
| add a new regression file in the nqp test suite, slap it in there. | 18:25 | ||
| pmichaud | sure, but it really ought to be a test for PCT, not for NQP. | ||
| Coke | it's a test for pct written in nqp. | 18:26 | |
| Austin | I've got a set of those in Close. | ||
| pmichaud | so I'd want to see it in t/compilers/pct, not compilers/nqp/t | ||
| also, checking output is a bit tricky. | |||
| since it doesn't produce something that is easily "ok 1" | 18:27 | ||
| Austin | Yeah. I added a "TreeUnit" page to talk about that. | ||
| HLL guys (like me!) are likely to appreciate some kind of tree-output-validator | 18:28 | ||
| pmichaud | Perl 6 has designs for one, although nobody's implemented it yet. | ||
| Coke | (tree output validator) - ... use TGE to generate some testable output. =-) | 18:29 | |
| Austin | Coke: How hard would it be to hook TGE up to NQP or Close code, instead of PIR? | ||
| pmichaud | See "Unpacking tree node parameters" in Synopsis 6 for Perl 6's ideas about tree management. | ||
| Austin | Okay, I found it. What's the context of this =head2? | 18:31 | |
| Coke | Austin: ISTR getting TGE to allow other languages in the blocks was on allison's todo list about 2-3 years ago. =-) | ||
| I don't think it ever landed. | |||
| I can probably dig up an RT for you. | |||
| pmichaud | It didn't. And I think we primarily blocked on having a good tree matching syntax. At least, that's where I blocked. | ||
| the mechanisms themselves were no problem, but having a clean syntax to specify the tree transformations was always an issue. | 18:32 | ||
| Coke | rt.perl.org/rt3/Ticket/Display.html?id=40002 | ||
| Austin | Jesus. I don't think I'll ever learn Perl6. | ||
| multi traverse ( NAry $top ( :kids [$eldest, *@siblings] ) ) { | 18:33 | ||
| NotFound | jonathan: there were trac tickets for all "Duplicated IDENTIFIER" warnings from the first day imcc was able to emit them. | ||
| Austin | The O'Reilly book is going to be behind the counter, under a wooden panel. "You must have an IQ at least 5 points higher than yours currently is to buy this book." | ||
| pmichaud | what frightens me a little is that I can read that Perl 6 line without any difficulty :-) | 18:34 | |
| even though I haven't really studied that syntax | |||
| NotFound | pmichaud: BTW, the warning is seen several times because the Makefile uses the .pir instead of the .pbc generated. This is intentional? | 18:36 | |
| pmichaud | yes | ||
| jonathan | pmichaud: You know you've been doing Perl 6 too long when... ;-) | ||
| pmichaud | jonathan: maybe I should resign today also. :-) | ||
| jonathan | noooooooooooo! | ||
| pmichaud | "I'm resigning because I saw the line of code 'multi traverse ( NAry $top ( :kids [$eldest, *@siblings] ) )' and it actually made sense to me." | 18:37 | |
| jonathan is a terrified by that thought | |||
| chromatic | What's not obvious about that line of code? | ||
| jonathan | I actually quite want to implement the stuff to make that line of code work. :-) | ||
| pmichaud | 15:58 <chromatic> Also sarcasm is rarely helpful online. | 18:38 | |
| Unless that wasn't sarcasm, in which case I might be even more frightened :-) | |||
| I do have to say, though, that I'm curious to see what we can do with tree matching when such things are available. | 18:39 | ||
| Tene | use xpath; | ||
| chromatic | To be fair, I've thought about tree matching for a while myself. | ||
| pmichaud | oh yes, I had forgotten that. Okay, I'm unfrightened. | ||
| jonathan | Getting us able to multi-dispatch based upon nested signature bindability won't be so bad. | 18:42 | |
| Doing it fast though is a whole different matter. :-) | 18:43 | ||
| pmichaud | right now I'm interested in "at all" :-) | 18:45 | |
|
18:46
ilia joined
|
|||
| jonathan | Well, I'm kinda waiting on seeing what the Parrot dispatch refactor brings. | 18:47 | |
| erm | |||
| calling conventions refactor | |||
|
18:48
rob joined
|
|||
| cotto wonders if that's ever going to land | 18:51 | ||
| jonathan | same | 18:52 | |
| I'd rather not having to work around PCC in Rakudo. | 18:53 | ||
|
18:55
darbelo joined
|
|||
| Austin | Well, that's nice. The Post Office thinks I've moved. :-| | 18:57 | |
| cotto | Maybe they're trying to tell you something. | 19:01 | |
| Austin | Yeah. They're trying to tell me I need to call my mother. Since she just called in a panic... | 19:02 | |
|
19:02
japhb joined
|
|||
| Austin | Should Undef have a definite logical value? | 19:02 | |
| pmichaud | false. | ||
| assuming you mean "boolean value" | |||
| undef evaluates to 0 as a number, "" as a string, and false as a boolean | |||
| Austin | Because class 'Undef' doesn't handle logical not. | ||
| pmichaud | ? | 19:03 | |
| Austin | logical_not() not implemented in class 'Undef' | ||
| pmichaud | oh | ||
| interesting. | |||
| what calls logical_not()? | |||
| Austin | Is that a vtable message? | ||
| pmichaud | I guess the "not" opcode? | ||
| Austin | Yep. | ||
| pmichaud | but undef does implement get_boolean, yes? | 19:04 | |
| Austin | ok(!(obj.flat()), "flat: New object is not flat"); | ||
| undef.pmc has get_bool return 0 | |||
| pmichaud | right | 19:05 | |
| anyway, interesting. | |||
| Austin | Apparently only scalar.pmc implements logical not. | ||
| pmichaud | correct -- I had never even heard of logical_not until now. :-) | ||
| Austin | Well, is this a bug? | 19:06 | |
| (I'm inclined to think it is...) | |||
| pmichaud | you'd have to ask the parrot designers/architects about that one :-) | ||
| Austin | Hmm. I'll just submit the bug, and they can resolve it. | 19:07 | |
| pmichaud | I'm a little surprised there's even a logical_not :-) | ||
| Austin | :) | ||
| One of those things that seemed like a good idea in 2001, I guess. | |||
| Kind of like flying cars. | |||
| And perfume.com | |||
| pmichaud | aha | 19:08 | |
| NQP uses the isfalse opcode | |||
| instead of 'not' | |||
| NotFound | At least he not started to kill people on that year. | ||
| Austin | NotFound: huh? | ||
| NotFound | 2001 | ||
| mikehh | looks like r39899 caused a failure in t/steps/gen_config_h-01.t | ||
| Austin | Allison commited a changeset 24650 to in support of pdd17pmc on 01/07/08 that vtable-ized the logical operations. | 19:10 | |
| pmichaud decides to switch hacking locations (to the back porch). He doesn't notify the Post Office. | |||
| weird, it's as recent as Jan 2008. | |||
| Austin | Just wait, Pmichaud, until your mom calls you in a panic, convinced that the "Return to Sender" she just got means you're dead or in the hospital. | 19:11 | |
| pmichaud | Since she keeps moving without notifying me, I hope otherwise. | 19:12 | |
| Austin | And "josh" committed cs#1844, implementing a patch from Sean O'Rourke that "fixed' logical_not in PerlInt. | ||
| pmichaud | I tried calling on Mother's Day and she had changed her phone number. | ||
| Coke | josh has been gone for some time. | ||
| Austin | Here's your sign. | ||
| Coke | so has PerlInt. | ||
| cs# ? | |||
| mikehh | pre-config/smolder FAIL with t/steps/gen_config_h-01.t exits after test 9 - fulltest PASS | ||
| Austin | cs# = changeset# | 19:13 | |
| Coke | ah. in svn we tend to use r. | ||
| so, r1844. | |||
| mikehh | at r39900 - Ubuntu 9.04 amd64 | ||
| Austin | This is from Trac. I sort of assume that Trac is tied up with SVN, though they keep claiming otherwise. | ||
| NotFound | mikehh: Debian amd64 here, and don't see that problem | 19:14 | |
| Coke | Austin: trac has-a-svn. | 19:15 | |
| mikehh: you might be better off opening tickets for these reports. | 19:16 | ||
| NotFound | Uh, no, It fails. | ||
| Coke | unless notfound happens to be here. =-) | ||
| NotFound | t/steps/gen_config_h-01.t .. 1/11 Undefined subroutine &gen::config_h::_handle_define_option called at t/steps/gen_config_h-01.t line 62. | ||
| pmichaud | Gee, there's a service for everything: www.renewbot.com/ | 19:18 | |
| dalek | kudo: 1340dd4 | jnthn++ | src/ (3 files): A few s/new/root_new/ for the (minor) win. |
19:19 | |
| kudo: ec0a594 | jnthn++ | src/parrot/P6role.pir: Oops, last patch had an issue. |
|||
| kudo: 68fd939 | jnthn++ | src/parrot/P6role.pir: Another new that should have been a root_new. |
|||
| kudo: c70c241 | jnthn++ | (2 files): Bump PARROT_REVISION, unfudge crony.t. |
|||
|
19:20
donaldh joined
|
|||
| Austin | Virtual theft? | 19:23 | |
| Keep renewing until the heat death of the universe... | |||
| pmichaud | our library limits to one renewal | 19:24 | |
| but, having paid around $80 so far in 2009 in overdue fines (that would've been avoided by this), it's a bargain | |||
| Austin | Laugh | 19:25 | |
| For $80, you could just sign up for Amazon Prime and get the free shipping. | 19:26 | ||
| Plus, you keep the books. | |||
| dalek | TT #816 created by Austin_Hastings++: PMC 'Undef' does not support logical_not | ||
| pmichaud | well, the bulk of that was from a very large number of childrens books that were checked out and we thought we had renewed but didn't | 19:27 | |
| Austin | The revenge of Dr. Seuss. | ||
| Pmichaud: What's a "handlers" ? | 19:32 | ||
| pmichaud | Austin: in PCT? | 19:33 | |
| Austin | Yeah. PAST::Node has a handlers method. | 19:34 | |
| It looks like it's supposed to be an array of PAST subtrees? | 19:35 | ||
| Coke | pmichaud: I'm going to update tcl to require a parrot revision (OR a release) during Configure.pl later this evening. Feel free to steal that code if it helps. | ||
| pmichaud | Coke: I already have that in Rakudo. | ||
| added it for #18 | |||
| Coke | ah, very good. | ||
| pmichaud | Austin: I think it's a way to put exception handlers around any PAST structure. Tene++ might remember in more detail, since he wrote it. | 19:36 | |
| Austin | Okay. Thanks. | ||
| mikehh | Coke: I try and see if we can get it sorted before opening a ticket ;-} | ||
| Tene | That's right. | ||
| Austin: it should accept a list of PAST::Control objects | |||
| pmichaud | Coke: I can find the patch diffs if you're interested | ||
| Tene | Austin: if you want more detail, please ask. | 19:37 | |
| also, feel free to contribute a doc patch. :) | |||
| Austin | Nope. Just trying to write a test case. But it doesn't seem very "list-y". Takes one value, returns one value. | 19:38 | |
| pmichaud | looks to me like it just accepts any single PAST::Control object | 19:40 | |
| Austin | ok 18 - handlers: Overwrite works. | 19:41 | |
| On that note, it's time for lunch. | |||
| Tene | perl6.past: { ...; CATCH { ... }; CATCH { ... } } | ||
| nopaste | "polyglotbot" at 193.200.132.146 pasted "perl6 past" (333 lines) at nopaste.snit.ch/17129 | ||
| Tene | What does that have? | ||
| <handlers> => ResizablePMCArray (size:2) [ | |||
| Austin_otl | An echelon of ellipses? | 19:42 | |
| Tene | Austin_otl: just wanted to generate a block with two handlers | ||
| it accepts one value. That value should be an array of handlers. | |||
| dalek | rtcl: r518 | coke++ | trunk/Configure.pl: make it easier to pull in more parrot config info |
19:46 | |
| pmichaud | okay, yes, array of handlers | 19:48 | |
|
19:50
avar joined
|
|||
| avar | Of possible parrot interest: techblog.wikimedia.org/2009/06/on-t...languages/ | 19:51 | |
|
20:01
jdv79 joined
|
|||
| Coke | pmichaud: how did you do the dotted revision comparison - roll your own? | 20:10 | |
|
20:10
Zak joined
|
|||
| pmichaud | Coke: yes | 20:11 | |
| simple function | |||
| sub version_int { sprintf('%d%03d%03d', split(/\\./, $_[0])) | |||
| } | |||
| converts 1.3.0 into 1003000 | 20:12 | ||
| Coke | probably the easiest way to cheat. danke. | ||
| dalek | TT #794 closed by NotFound++: split opcode should respect HLL mappings | 20:18 | |
| NotFound | t/steps/gen_config_h-01 fails also on i386 | ||
| dalek | kudo: cf851ca | pmichaud++ | t/spectest.data: Remove S03-operators/smartmatch.t from spectest.data -- it has several spec errors. |
20:23 | |
|
20:33
mikehh_ joined
20:41
bacek joined,
hercynium joined
20:43
mikehh_ joined
20:46
maettu joined
|
|||
| maettu | What I've been wondering about for the last week or so: Parrot is "quite" slow at the moment, in a case I studied even much slower than C. How come you are so confident that you will get a) parrot get out the door b) make it *fast*? | 20:53 | |
| Coke | maettu: That's an excellent question. | 20:54 | |
| chromatic | a) We release every month. We're pretty darn good at getting Parrot out the door. | ||
| b) We know what the bottlenecks are and we have a plan to address them. | |||
| mikehh | Notfound: the test looks for a sub that was removed in r39899 | 20:56 | |
| maettu | (I feel that this is very calming to me. Whenever I will fight some little problems on my little projects, I will think of you and your confidence.) | 20:57 | |
| chromatic | Confidence or bull-headed stubbornness, people have various opinions. | 20:58 | |
| mikehh | Notfound: check smolder - it fails on all architectures since #24564 | 20:59 | |
|
21:00
eternaleye joined
|
|||
| mikehh | Notfound: We need to modify the test I think | 21:01 | |
| maettu | chromatic: Whatever. I think there are plenty of worthwile ideas in parrot, so just keep going. (And it's pretty cool to do some parrot-pseudo-assembler with a garbage collector etc. at hand) | 21:02 | |
| Coke | is object's vtable name a safe way to say "I have no version of this vtable but if you want to override it you can? - if so, would adding some syntax to pmc2c so we can just say VTABLE name :overridable ? | ||
| chromatic | I don't understand the question, Coke. Can you not override name? | ||
| Coke | er, a safe /example/ - obviously we'd s/name/actual vtable name/ when generating the C. | ||
| chromatic: doesn't work for arbitrary dynpmcs that aren't objects. | 21:03 | ||
| or is the recommend way there to subclass your PMC and then override /that/ vtable? | |||
| chromatic | That surprises me. I expect that it should work. | ||
| Oh. | |||
| Right. | |||
| Because you have to check if it's overridden from PIR and then... blah. | |||
| Or do you mean C dynpmcs? | 21:04 | ||
| Coke | that's the only kind of dynpmc of which I am aware. | ||
| (anything written in PIR is a kind of object.) | |||
| where object isa PMC, but a PMC isn't necessarily an object. | |||
| NotFound | mikehh: For some value of "we"? ;) | 21:05 | |
| chromatic | I can't imagine why you can't override it. To my knowledge, there's nothing special there (unless the pmc2c generator forbids it). | ||
| Coke | I'm not trying to override name. | ||
| mikehh | NotFound: As in sombody need to approve it :-) | 21:06 | |
| Coke | I'm just pointing to that as an example of "is this how I can override a dynamic-c-pmc's vtable from PIR, and if so, can we make a shortcut so I don't have to cut and paste it.) | ||
| chromatic | Oh. You want to write a dynpmc which contains vtable entries you can override from PIR. | 21:07 | |
| Yeah, copy and paste is the current best way. | |||
| mikehh | NotFound: just trying to figure exactly what it was testing fort | ||
| chromatic | That argues for a function to keep all of that knowledge around instead. | 21:08 | |
| mikehh | s/fort/for/ | ||
| Coke | mikehh: in general the config/steps test test the current config implementation as written. | 21:09 | |
| which is to say, they're not necessarily testing the way things ought to work, just they way they worked when the tests were written. | 21:10 | ||
| which may or may not be relevant to the current failure. | |||
| bacek | good morning #parrot | 21:18 | |
| nopaste | "pmichaud" at 72.181.176.220 pasted "latest rakudo gc trials (x86 and x86_64, ubuntu)" (20 lines) at nopaste.snit.ch/17131 | 21:23 | |
| pmichaud | oddly, the long-standing S10-* test that was failing on exit is no longer doing so. | 21:24 | |
| chromatic | pmichaud, is that with the patch I posted a day or so ago? | 21:25 | |
| pmichaud | that's using exactly what's in the repos, no patches | ||
| I can try with the patch if you like. | |||
| nopaste | "chromatic" at 72.90.115.31 pasted "Add Metadata GC Flag (pmichaud)" (10 lines) at nopaste.snit.ch/17132 | 21:26 | |
| jonathan | chromatic: Heh, is that the flag not being set at the point we attach properties?! | 21:27 | |
| chromatic | It wasn't there, which seemed wrong. | ||
| jonathan | aye | 21:28 | |
| chromatic | There may be other spots which need similar flags. | 21:30 | |
|
21:34
maettu left
|
|||
| pmichaud | quick summary: the tests that failed in my nopaste 17131 above fail in the same way after the metadata gc flag patch. | 21:35 | |
| (I'm running a spectest to see if any other tests fail) | |||
| chromatic | Pity. | ||
| jonathan | That doesn't mean the patch is unrequired. | 21:37 | |
| Just not sufficient I guess. :-( | |||
|
21:53
Theory joined,
japhb joined
21:54
Austin_otl joined
21:55
dduncan joined,
dduncan left
|
|||
| bacek | chromatic: around? | 21:55 | |
| Austin sings "'round, 'round, get around; I get around..." | 21:56 | ||
| chromatic | Yes, what can I do for you? | 21:57 | |
| bacek | chromatic: remember our conversation about cstring hash? | 21:59 | |
| I claimed that it's not protected from dlclose. | |||
| (nopaste coming) | |||
| chromatic | Yes. | 22:00 | |
| nopaste | "bacek" at 114.73.131.80 pasted "cstring hash shenanigans." (23 lines) at nopaste.snit.ch/17133 | 22:01 | |
| bacek | is dlopen/dlclose can change memory layout? | ||
|
22:02
Theory joined
|
|||
| chromatic | I expect not. What are you seeing in this paste? | 22:02 | |
|
22:03
Limbic_Region joined
|
|||
| bacek | That pointer to "parrot" string treated as uninitialized by valgrind. | 22:03 | |
| chromatic | As far as Valgrind knows, our whole stack is uninitialized. | 22:04 | |
| bacek | ouch... | 22:05 | |
| chromatic | Valgrind doesn't know very much about stack scanning GC. There are some Valgrind headers and defines we could use to decorate such code; that might help get more useful results out of Valgrind here. | ||
| bacek | valgrind.org/docs/manual/mc-manual....l.mempools | 22:10 | |
| looks good starting point. | |||
|
22:11
zak_ joined
|
|||
| chromatic | I don't remember the exact headers. I ran into confusion trying to decide how to write a configure step for them. | 22:11 | |
| mikehh | seen kid51 | 22:13 | |
| purl | kid51 was last seen on #parrot 19 hours, 45 minutes and 31 seconds ago, saying: must sleep | ||
| bacek | chromatic: what main purpose of PObj_is_special_PMC? | 22:14 | |
| (rephrase) When this flag should be set? | |||
| Tene | *every* PMC should feel special! | 22:15 | |
| (sorry) | |||
| bacek | Tene: all PMC are special. But some of them more special :) | ||
|
22:15
Theory joined
|
|||
| mikehh | bacek: dat is de problem :-} | 22:16 | |
| chromatic | a PMC with metadata, a custom mark, or PMC data in an array (I don't care for the latter) | ||
| dalek | kudo: 99ad1eb | masak++ | src/ (4 files): added $format default to all .fmt variants |
||
| tracwiki: Austin_Hastings++ | new parrot.png attached to NewParrotDeveloperGuide | |||
| tracwiki: New parrot image | |||
| tracwiki: trac.parrot.org/parrot/attachment/...ction=diff | |||
| tracwiki: v17 | Austin_Hastings++ | NewParrotDeveloperGuide | |||
| tracwiki: trac.parrot.org/parrot/wiki/NewPar...ction=diff | |||
| bacek | chromatic: oookey. Should ParrotLibrary has this flag? It explicitly clone metadata in .clone, but doesn't set this flag in .init | 22:17 | |
| chromatic | Yes, probably. | 22:18 | |
| purl | Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look Because \\ an asshole. | ||
| cotto | forget probably | 22:24 | |
| purl | cotto: I forgot probably | ||
| cotto | probably | ||
| Austin | Yes, probably. | ||
| purl | Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look Because \\ an asshole. | ||
| Austin | purl: forget probably. | ||
| purl | Austin, I didn't have anything matching probably | ||
| Austin | forget Yes, probably. | ||
| purl | Austin, I didn't have anything matching yes, probably | ||
| Austin | yes, probably. | 22:25 | |
| purl | Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look Because \\ an asshole. | ||
| bacek | purl: no, probably is <reply> | ||
| purl | OK, bacek. | ||
| bacek | yes, probably. | ||
| purl | Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look Because \\ an asshole. | ||
| Austin | yes, probably. | ||
| purl | Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look Because \\ an asshole. | ||
| bacek | stupid girl... | ||
| purl: no, yes, probably. is <reply> | 22:26 | ||
| purl | OK, bacek. | ||
| bacek | yes, probably. | ||
| purl | Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look Because \\ an asshole. | ||
| bacek | bah! | ||
| Austin | I have a question: Is parrot going to support threading (of PIR threads), and if so, will it be one interp per thread, or one interp with several threads inside? | 22:29 | |
| dalek | ose: r51 | Austin++ | trunk/t/library/pct/PAST (4 files): Added tests for pct/PAST/Node.c= |
||
| bacek | Austin: interp per thread iiuc | ||
|
22:31
Theory_ joined
|
|||
| Austin | Yowza. What things are shared? | 22:32 | |
|
22:32
avar left
|
|||
| chromatic | By default, core data structures. | 22:32 | |
| No user data. | |||
| bacek | It's Internet era, dude. Everything is shared! | 22:33 | |
| :) | |||
| Austin | bacek: :-) | ||
| chromatic: Core data structures = filehandles and shmem segs and such? Loaded pbc? Or interp innards/gc/mem pools? | 22:34 | ||
| cotto | forget yes, probably. | ||
| purl | cotto, I didn't have anything matching yes, probably | ||
| cotto | forget (yes, probably.) | ||
| purl | cotto, I didn't have anything matching (yes, probably.) | ||
| cotto | literal yes, probably | 22:35 | |
| literal yes, probably. | |||
| purl | cotto: yes, probably. =is= <reply> | ||
|
22:35
Theory joined
|
|||
| Austin | Yes, probably. | 22:35 | |
| purl | Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look Because \\ an asshole. | ||
| cotto | literal Yes, probably. | ||
| purl | cotto: Yes, probably. =is= <reply> | ||
| Austin | Yes, probably. | ||
| purl | Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look Because \\ an asshole. | ||
| cotto | It must be a special case. | ||
| purl, owner? | |||
| purl | owner is, like, hachi, see also #purl | ||
|
22:36
rg joined
|
|||
| bacek | No one can outsmart stupid bot! :) | 22:36 | |
| Austin | purl is the first, tentative step in the evolution of homo superior virtualis. | ||
| cotto | I pinged hachi about it in #purl. | 22:42 | |
|
22:45
Theory_ joined
|
|||
| Austin | cotto++ | 22:45 | |
| Thanks. | |||
| It's irksome. | |||
| cotto | In the meantime, there's always < purl-- > | 22:46 | |
|
22:49
kid51 joined
|
|||
| mikehh | kid51: r39899 changed config/gen/config_h.pm which removed a sub used in t/steps/gen_config_h-01.t which now fails | 22:53 | |
| Coke returns to find an insane amount of bot-spam. | 22:54 | ||
| purl does respond in private, you know. | |||
| purl | Coke: huh? | ||
| mikehh | kid51: I am not sure exactlky what it was testing for - whether we need to modify the test or what? | 22:55 | |
| s/exactlky/exactly/ | |||
| dalek | rrot: r39901 | fperrad++ | trunk/t/steps/gen_config_h-01.t: [config] update tests after r39899 |
22:56 | |
| mikehh | ok that seems to sort that out :-} | ||
| kid51 | fperrad to the rescue | 22:57 | |
| He is very good about keeping the configuration steps in shape. I saw that he submitted a patch today for a new config step. | |||
| It was a very thorough patch. | 22:58 | ||
| I don't have an opinion yet as to whether it should be applied, but it was thorough. | |||
| mikehh | well the test now passes | 23:01 | |
| after r39901 | |||
| he doesn't seem to hang arouind here much | 23:03 | ||
| dalek | tracwiki: v83 | jkeenan++ | WikiStart | 23:04 | |
| tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff | |||
| tracwiki: v84 | jkeenan++ | WikiStart | |||
| tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff | |||
|
23:08
ruoso joined
23:20
donaldh joined
|
|||
| Coke | pmichaud++ for version_int, which I meant to include in the commit msg. | 23:20 | |
| dalek | rtcl: r519 | coke++ | trunk/ (2 files): Require a minimum parrot revision or release. |
23:21 | |
| mikehh | Ok now All tests PASS (pre/post config, smolder, fulltest) at r39901 - Ubuntu 9.04 amd64 | ||
| I want to set up a parrot etc testbed and want to run the various platforms from a base Ubuntu 9.04 amd64 VM | 23:46 | ||
| anybody got any experience running a VM on a desktop rather than a server | 23:47 | ||
| pmichaud | I do, but only with VMWare | 23:48 | |
| mikehh | I was thinking of using kvm but I don't really know enough about it | ||
| I was thinking of having Ubuntu i386 and Windows 7 as guests initially | 23:50 | ||
| and possibly adding maybe openbsd or something like that later | |||
| I have an AMD Phenom 940 quad core with 8GB and 2x1TB disk drives | 23:52 | ||
| I am open to suggestions | |||
| Austin | Mikehh: The only caveat I have about running vm's is the resources they consume -- they're doing a really GOOD job of emulating PCs, which means timers, etc. | 23:53 | |
| That said, I ran VMware and Vxbox with no problems from my Dell Latitude. You could probably just set up a cron job to do a "make smoke" every couple of hours, and if they missed one because the box was shut down, no harm done. | 23:54 | ||
| pmichaud | agreed -- I always managed to run VMware on my (now 5+ year old) Latitude with few problems | 23:55 | |
|
23:55
tetragon joined
|
|||
| mikehh | My old desktop system was a dual core Pentium D - 2GB without VM capabilities | 23:55 | |
| pmichaud | my current desktop system is a dual core Pentium D | 23:56 | |
| (2GB, in fact) | |||
| mikehh | I rebooted between i386 and amd64 Ubuntu - I want to avoid that | ||