% chromatic has left #parrotsketch
% davidfetter has left #parrotsketch
<spinclad> [nick | busy]
% spinclad is now known as ||
<||> 14:30:41 < chromatic> Okay, who's here?
<||> 14:30:53 < davidfetter> me
<||> 14:31:16 < allison> me too
<||> 14:32:33 < chromatic> Okay, let's start with davidfetter then.
<||> 14:32:59 < davidfetter> there's a new packager for the RPMs
<||> 14:33:38 -!- PerlJam [duff@feather.perl6.nl] has joined #parrotsketch
<||> 14:33:38 -!- AndyAgain [~Andy@host3131.follett.com] has quit [Read error: Connection reset by peer]
<||> 14:33:48 < davidfetter> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246348
<||> 14:34:01 -!- AndyAgain [~Andy@host3131.follett.com] has joined #parrotsketch
<||> 14:34:07 -!- diakopter [~diakopter@host01a.appflux.net] has joined #parrotsketch
<||> 14:34:15 < davidfetter> that's it for me. oh, prato was great :)
<||> 14:34:33 < chromatic> Allison?
<||> 14:35:01 < allison> - I've been suffering from a lack of network access, but I'm about to check in my YAPC example code and the metamodel diagram (as soon as I stop typing this).
<||> 14:35:20 < allison> - My work this week has been on instantiating new metamodel objects within the standard system (through the 'new' opcode, etc). Finishing off work from the hackathon.
<||> 14:35:35 < allison> Should be ready to check that in today or tomorrow.
<||> 14:35:41 < allison> EOR
<||> 14:35:58 < chromatic> I spent the last week tracking down memory problems.  I think I found one, and I posted an ugly patch that could use testing.
<||> 14:36:04 < chromatic> It fixes one test for me, but not the shootout tests.
<||> 14:36:13 < chromatic> I suspect a problem with CGP and JIT for those, unfortunately.
<||> 14:36:38 < chromatic> I also heard that Bundle::Parrot fails to install from the CPAN, probably because the most-recently-indexed version is an unauthorized version.  We should fix that.
<||> 14:36:38 < chromatic> EOR
<||> 14:36:43 < chromatic> Who else is here with a report?
<||> 14:38:12 < chromatic> Okay.  Are there any questions?
<||> 14:38:44  * particle arrives, late
<||> 14:39:10 < chromatic> aha, you go
<||> 14:39:28 < particle> i've spent the last week or so debugging segfaults. after a lengthy search and debug, a segfault recently disappeared. i posted my investigation notes in a ticket.
<||> 14:40:01 < particle> i came out of it learning a lot, and have a few questions that could use answering.
<||> 14:40:28 < particle> otherwise, i've been trying to clean things up on win32x64.
<||> 14:40:48 < particle> the segfault in perl6 tests has now disappeared, so i can finally turn my attention elsewhere
<||> 14:42:03 < particle> .end
<||> 14:42:36 < chromatic> NOW, question time.
<||> 14:42:49 -!- pmichaud [pmichaud@feather.perl6.nl] has joined #parrotsketch
<||> 14:42:54 < pmichaud> ....HERE!  :-)
<||> 14:43:02 < chromatic> Okay, now pmichaud report time.
<||> 14:43:09 < pmichaud> I don't have a report prepared
<||> 14:43:20 < pmichaud> I have plenty to report on, but nothing prepared :-)
<||> 14:43:25 < chromatic> That's okay.
<||> 14:43:26 < pmichaud> so, bear with me a sec
<||> 14:43:51 < pmichaud> this past weekend I had to leave town for a family emergency -- things are fine there, but it did take me away from my other normal activities a bit
<||> 14:44:04 < pmichaud> last #parrotsketch I reported was pre-oscon, and a lot has happened since then
<||> 14:44:18 < pmichaud> we now have a compilers/pct/ directory, where the revised versions of the parrot compiler tools are going
<||> 14:44:32 < pmichaud> basically, this will combine PAST, POST, HLLCompiler, and other "compiler-related" items into a single library
<||> 14:45:00 < pmichaud> I'm also continuing to work on nqp ("Not Quite Perl"), which is starting to come together very nicely.  It greatly simplifies the task of building asts
<||> 14:45:15 < pmichaud> I hope to check in preliminary working versions of nqp tonight or tomorrow
<||> 14:45:26 < AndyAgain> I'm in a meeting right now and can't talk.  I'm just logging this in the background.
<||> 14:45:49 < allison> patrick: great!
<||> 14:45:51 < pmichaud> the hackathon at yapc was very successful, we managed to fix a number of issues in parrot and perl6, and chromatic++ was even able to convert pheme to use past-pm
<||> 14:46:13 < chromatic> Well, sort of...
<||> 14:46:20 < pmichaud> this included adding namespace capabilities into past-pm, which is another big bonus
<||> 14:46:48 < pmichaud> at the hackathon I worked a bit on converting the existing compiler tools to be more compatible with the pdd15 oo system, including removing instances of find_type and other items
<||> 14:47:02 < pmichaud> there are still some things that need to be migrated, but it shouldn't be difficult to do them as we get closer
<||> 14:47:25 < pmichaud> there are some capabilities that we're semi-blocking on with pdd15, and I wish I had a list ready for parrotsketch but will summarize to the mailing list later tonight
<||> 14:47:50 < pmichaud> actually, I think I'll just halt here and send a summary to #parrotsketch or the mailing list later tonight :-)
<||> 14:47:53 < pmichaud> so, end of report
<||> 14:48:36 < chromatic> Okay.  Now, either someone else will appear or we'll take questions.
<||> 14:49:52 < particle> coke asked a question earlier today: why does gc suck so much?
<||> 14:50:07 < chromatic> It tries to be really clever with PObj flags.
<||> 14:50:11 < pmichaud> I think it has to do with the fact that you're constantly dealing with 'g'  :-)
<||> 14:50:22 < particle> actually, it was "so, why does our GC suck?" # but you get the idea
<||> 14:50:35 < chromatic> There's one spot where it's easy to get bugs: where you don't explicitly mark everything you need to mark.
<||> 14:50:44 < chromatic> There's one spot where our underlying C structs have way too much magic.
<||> 14:50:48 < particle> yeah, that'll kill you
<||> 14:50:56 < chromatic> There's one spot where the "Let's put stuff on the free list!" is also way too much magic.
<||> 14:51:22 < chromatic> Other than that, it's pretty straightforward.
<||> 14:51:31 < chromatic> ... except for Copy on Write.
<||> 14:51:59 < particle> i find it's hard to debug because the effects tend to be noticed so far away from the cause.
<||> 14:52:09 < chromatic> particle, can you try the patch I posted late last night?
<||> 14:52:23 < allison> the GC PDD is coming up soon
<||> 14:52:29 < particle> sure, now that i have a working, segfault-free parrot, i'll try anything :)
<||> 14:52:39 < allison> c, can you drop those as notes in the GC PDD?
<||> 14:53:09 < chromatic> Under a new section entitled "Why This Doesn't Always Work"?
<||> 14:53:12 < allison> if we need to change internal architecture to make GC cleaner and more reliable, we will
<||> 14:53:14 < particle> coke seems to have an assert failure in tcl tests somewhere. i think he's enabled -G to get around it.
<||> 14:53:16 < chromatic> Variable sized PMCs will help.
<||> 14:53:32 < allison> chromatic: we've abandoned variable sized PMCs
<||> 14:53:42 < allison> though, was it really that they would help?
<||> 14:53:55 < allison> or just that they would uncover a pile of GC bugs?
<||> 14:54:22 < allison> chromatic: well, abandoned is a strong word
<||> 14:54:26 < chromatic> If we use variable-sized PMCs, we can get rid of a really ugly union in the PObj struct.
<||> 14:54:36 < chromatic> I cannot prove that this is a source of bugs, but I can prove that it is a source of evil.
<||> 14:54:53 < chromatic> By induction, I imply that evil is a source of bugs, mostly because cockroaches don't go to heaven.
<||> 14:55:01 < chromatic> They go to Houston.
<||> 14:55:04 < allison> chromatic: we can eliminate that without moving to variable sized PMCs
<||> 14:55:22 < allison> do we want to eliminate it entirely?
<||> 14:55:24 < chromatic> I don't mean variable sized headers.
<||> 14:55:50 < allison> okay, leo's variable sized PMCs is for a variable-sized header struct
<||> 14:56:11 < chromatic> I mean "The X PMC holds three pointers to various things, while the Y PMC holds no seven and everyone is happy."
<||> 14:56:11 < allison> for any other definition of "variable sized PMCs" we already have them
<||> 14:56:20 < allison> yup, we have that now
<||> 14:56:32 < chromatic> Well we're not using them.
<||> 14:56:40 < allison> we are in some cases, but not enough
<||> 14:56:59 < chromatic> Then I say, death to the union.
<||> 14:57:09 < allison> deprecating the union is a good way to start the process of converting everything away from the union
<||> 14:57:21 < allison> the union was originally only intended to be used as a cache
<||> 14:57:28 < allison> not as the core data of the PMC
<||> 14:57:51 < allison> I'll make a note in deprecated.pod
<||> 14:58:07 < chromatic> That might fix the Key and Iterator PMCs too.
<||> 14:58:12 < particle> this will involve a rewrite of many core pmcs.
<||> 14:58:46 < particle> class/object/role/exporter all use the new style (no union)
<||> 14:58:47 < allison> particle: yes, which is why I decided not to deprecate it immediately
<||> 14:58:50 < chromatic> Fortunately, I won't miss most of the code.
<||> 14:59:34 < particle> let's make it clear in the docs that the union is for cache
<||> 15:00:11 < particle> then we can pessimize the existing code and re-optimize it after it's well organized
<||> 15:00:17 < chromatic> Fixing PMC_data(), PMC_intval() etc will help.
<||> 15:00:39 < allison> chromatic: if the union val is deprecated, those are also removed
<||> 15:01:02 < particle> ready for another topic?
<||> 15:01:04 < allison> particle: the question is whether it's relegated to cache-only, or deprecated entirely
<||> 15:01:19 < allison> particle: yes, this is an ongoing discussion for PMC PDD
<||> 15:01:20 < chromatic> Plenty of places outside of src/pmc/*.pmc use PMC_data() etc.
<||> 15:01:30 < particle> allison, that's your call. for now, it's cache, as i understand.
<||> 15:01:36 < allison> chromatic: yes, but they shouldn't
<||> 15:01:51 < allison> it's a horrible breakage of encapsulation
<||> 15:02:00 < particle> too true!
<||> 15:02:01 < allison> they should be using vtable functions on the PMC
<||> 15:02:14 < particle> or methods.
<||> 15:02:18 < allison> yup
<||> 15:02:35 < chromatic> That's what I wanted to hear.
<||> 15:02:43 < allison> refactor away :)
<||> 15:02:45 < chromatic> There's my answer to why GC sucks.
<||> 15:03:17 < allison> far too much poking into the internals of PMCs rather than respecting the defined interfaces, yes
<||> 15:03:17 < particle> for the next release, i want to kill all the segfaults.
<||> 15:03:39 < pmichaud> (killing segfaults)++
<||> 15:03:43 < chromatic> Not sure I can guarantee that.
<||> 15:03:44 < particle> i know of one, reported by coke.
<||> 15:03:50 < particle> anybody know of others?
<||> 15:04:03 < particle> (or actively working on others?)
<||> 15:04:04 < chromatic> Plenty in t/examples/shootout.t
<||> 15:04:10 < allison> there are several buried in TODO and skip tests
<||> 15:04:14 < particle> ah, yes.
<||> 15:04:44 < allison> any we can kill are a definite plus
<||> 15:04:48 < particle> andy, ptc, and infinoid have recently made great strides in lint, splint, and coverity testing
<||> 15:05:04 < AndyAgain> infinoid++
<||> 15:05:09 < allison> excellent!
<||> 15:05:09 < chromatic> We have Coverity tests?
<||> 15:05:13 < particle> this, as well as andy's headerizer work, has already uncovered some bugs.
<||> 15:05:30 < particle> chromatic: yes, ptc set it up, and has requested a few more ids for access.
<||> 15:05:31 < AndyAgain> particle: Oh?  Do tell.
<||> 15:06:12 < particle> andy: you found&fixed a bug yesterday thanks to splint, no?
<||> 15:06:44 < particle> function visibility (static, PARROT_API, etc) has been cleaned up tremendously.
<||> 15:07:12 < particle> without specifically trying, many win32x64 segfaults have been cleared up in the past week
<||> 15:07:20 < AndyAgain> particle: No, just found.
<||> 15:08:28 < particle> okay, well, i'm glad to have so many eyes on our c code. i can't tell you the last time this happened.
<||> 15:09:00 < particle> i can tell you this work promises to make our code much more pleasurable to work with, and improve correctness.
<||> 15:09:54 < particle> coupled with kid51's increasing config/ test coverage, we're really increasing our confidence in our code. i'm Happy.
<||> 15:10:26  * allison happy too
<||> 15:10:36  * pmichaud happy
<||> 15:10:38 < AndyAgain> particle, allison: Thanks for saying.  That makes me happy to hear.
<||> 15:10:45 < AndyAgain> because I wanted to not be doin' this for nothing.
<||> 15:10:56 < AndyAgain> One thing is we're going to have a TON of decorators on ourfuncs.
<||> 15:11:25 < pmichaud> andy:  I also add my appreciation for your work.  I really am glad that we're getting this thorough review of the underlying code base
<||> 15:11:30 < AndyAgain> like this
<||> 15:11:31 < AndyAgain> PARROT_API
<||> 15:11:31 < particle> as long as there's a document explaining what they mean and how to code using them, it's an *excellent* code policy, andy.
<||> 15:11:31 < AndyAgain> PARROT_CANNOT_RETURN_NULL
<||> 15:11:31 < AndyAgain> PARROT_WARN_IF_UNUSED
<||> 15:11:32 < AndyAgain> STRING *
<||> 15:11:32 < AndyAgain> Parrot_make_COW_reference(PARROT_INTERP, NULLOK(STRING *s))
<||> 15:11:56 < AndyAgain> particle: Yeah, I'm adding new ones for the ones that splint can handle.
<||> 15:12:07 < AndyAgain> splint does tons of NULL tracking
<||> 15:12:34 < particle> these macros should eventually be added to pdd07, like PARROT_API is.
<||> 15:12:58 < particle> 's okay to keep them on a wiki or .pod until things settle down.
<||> 15:14:05 < particle> okay. in order for us to migrate to the new pdd15, we need to get away from type numbers.
<||> 15:14:13 < particle> some of you have already started doing this in code.
<||> 15:14:36 < particle> an important part of this is s/.Integer/'Integer'/g
<||> 15:14:54 < particle> that's *everywhere*. thousands of tests.
<||> 15:15:02 < particle> examples. libraries. etc.
<||> 15:15:24 < particle> is there *any* reason to wait on converting these?
<||> 15:16:06 < pmichaud> I've been converting them as I come across them
<||> 15:16:15 < pmichaud> there is a question about when 'Integer' is not really .Integer
<||> 15:16:38 < pmichaud> e.g., in a HLL, the meaning of 'Integer' can be different
<||> 15:17:09 < pmichaud> in these cases we may need to switch to something like  ['parrot';'Integer'], except I don't think that's workable either
<||> 15:18:14 < pmichaud> (because iirc, this isn't the pdd15 spec)
<||> 15:18:41 < allison> particle: for everything outside of the tests, there's no reason to wait
<||> 15:19:03 < allison> particle: for the tests themselves, I need to make sure I don't introduce regressions as I make my refactors
<||> 15:19:32 < particle> ok, great. i'll hold off on creating a cage ticket for test conversion, then.
<||> 15:20:31 < allison> pmichaud: that's true, though we've never been able to test for the exact type id either, because it changes everytime a new PMC is added to the core
<||> 15:20:55 < allison> the plan is to move to lookups in the namespace
<||> 15:21:01 < pmichaud> agreed for non-builtins
<||> 15:21:18 < allison> even for builtins (at least that's the current plan)
<||> 15:21:34 < pmichaud> I meant "agreed" to the previous statement, not the lookups (more)(
<||> 15:21:51 < allison> ah, right
<||> 15:21:54 < pmichaud> for the builtins like .Integer, it was a pretty safe bet you'd get the parrot Integer object
<||> 15:22:16 < pmichaud> in the current pdd15 spec we don't seem to have a way to guarantee that 
<||> 15:22:19 < allison> ah, yes, because the macros were updated when new PMCs were added
<||> 15:22:55 < pmichaud> and using new 'Integer' is safe only if in the root of the parrot HLL namespace
<||> 15:23:06 < allison> true, the only way to guarantee that you're getting a built-in PMC under the type id-less system is to look in the 'parrot' hll
<||> 15:23:21 < pmichaud> the closest we have at the moment is  $P0 = get_root_namespace ['parrot'; 'Integer']      \  $P1 = new $P0
<||> 15:23:33 < allison> and even that isn't a total guarantee, because it could have been replaced in the 'parrot' HLL
<||> 15:23:49 < pmichaud> but even this assumes that the 'Integer' namespace is tied to the Integer class, which also hasn't been specced
<||> 15:23:55 < allison> yep, that's as close as you can get
<||> 15:24:05 < allison> they will be tied
<||> 15:24:08 < pmichaud> jonathan and I remarked on this in a m/l thread at YAPC
<||> 15:24:16 < allison> if it isn't mentioned in the PMC PDD it will be
<||> 15:24:20 < pmichaud> okay
<||> 15:24:32 < pmichaud> if that doesn't get added in the next day or so I'll add a ticket or a patch
<||> 15:24:37 < particle> we can design a decoration for core pmcs with something that doesn't allow override in 'parrot' namespace, if it's wanted.
<||> 15:24:38 < allison> builtin PMCs will be tied to a corresponding spot in the 'parrot' HLL namespace
<||> 15:24:52 < pmichaud> thanks for the ruling
<||> 15:24:57 < pmichaud> that's helpful
<||> 15:25:14 < pmichaud> particle: I'm not sure it's entirely necessary to have the decoration
<||> 15:25:29 < pmichaud> i.e., I'd wait until we find we need it :-)
<||> 15:25:42 < particle> sure, it's mostly a change for pmc2c i suspect
<||> 15:26:03 < particle> pmclass Foo does bar extends baz is_core {
<||> 15:26:09 < particle> or whatever
<||> 15:27:43 < pmichaud> anyway, according to pdd15:   $P0 = new .Integer  can be replaced by $P0 = new 'Integer' only in the parrot root namespace
<||> 15:27:45 < allison> particle: makes sense. It may be a 2.0 feature
<||> 15:27:56 < pmichaud> in all other namespaces, one would need to get the namespace for the 'Integer' class and use that
<||> 15:28:19 < allison> pmichaud: yes
<||> 15:28:39 < allison> I don't remember how keyed access is currently working for 'new'
<||> 15:28:51 < pmichaud> oh, yes
<||> 15:28:52 < pmichaud> of course
<||> 15:28:57 < allison> it may also be possible to do new ['parrot';'Integer']
<||> 15:28:58 < pmichaud> $P0 = new [ 'Integer' ]
<||> 15:29:05 < pmichaud> works in the parrot HLL (in any namespace)
<||> 15:29:15 < pmichaud> pdd15: "A key looks for the class in the namespace identified
<||> 15:29:16 < pmichaud> by the multilevel key relative to the currently selected HLL."
<||> 15:29:34 < allison> ok, so new is using absolute namespaces?
<||> 15:29:46 < allison> the pdd says relative namespaces
<||> 15:29:52 < particle> hll relative
<||> 15:29:55 < pmichaud> A string looks for a class in the current namespace
% Coke has joined #parrotsketch
<||> 15:30:07 < allison> but if "$P0 = new [ 'Integer' ]" gets the parrot HLL in any namespace...
<||> 15:30:13 < pmichaud> no
<||> 15:30:21 < pmichaud> $P0 = new ['Integer'] works if the current sub is in the parrot HLL
<||> 15:30:23 < allison> oh, that was a hypothetical code example
<||> 15:30:40 < pmichaud> in another HLL, one would have to explicitly get Integer from the parrot namespace (using get_root_namespace or equivalent)
<||> 15:31:00 < pmichaud> $P0 = new 'Integer'    # works in parrot HLL, root namespace
<||> 15:31:02 < allison> yes
<||> 15:31:12 < pmichaud> $P0 = new ['Integer']    # works in parrot HLL, any namespace
<||> 15:31:14 < allison> if that is a major pain, we can work something out
<||> 15:31:30 < pmichaud> I think the fact that new ['Integer'] works in the parrot HLL will be good enough for me
<||> 15:31:31 < allison> but really, it may help clear up some of our namespace bugs
<||> 15:31:43 < pmichaud> (and things based on pct)
<||> 15:31:52 < particle> sounds good to me. it seems like hlls can cache that namespace if they feel they'll be doing the lookups often.
<||> 15:31:52 < pmichaud> I don't know how it might affect the other hll implementations, such as tcl
<||> 15:32:20 < pmichaud> even easier, HLLs can set their notion of 'Integer' to point to the parrot class :-)
<||> 15:32:26 < allison> pmichaud: ok, we'll wait to hear from other HLL implementors
<||> 15:32:51 < allison> yes, aliasing across namespaces is allowed
<||> 15:33:12 < particle> ah, aliasing. yay.
<||> 15:33:52 -!- chromatic_ [~chromatic@c-67-169-216-154.hsd1.or.comcast.net] has joined #parrotsketch
<||> 15:34:42 < allison> (though, not currently spec'd IIRC)
<||> 15:34:54 < allison> (so let me know how you end up using it)
<||> 15:35:35 < pmichaud> I have to depart now for other errands -- I'll be around on #parrot though
<||> 15:35:45 -!- chromatic [~chromatic@c-24-21-59-142.hsd1.or.comcast.net] has quit [Read error: Connection reset by peer]
<||> 15:36:37 < particle> okay, things have wound down enough. talk to you same time next week!
% || is now known as spinclad
<Coke> ... I'm just in time!
<Coke> See you all next week.
% Coke has left #parrotsketch
% tewk has joined #parrotsketch
<tewk> I've been keeping pmc2c up to date, haven't made any changes in weeks, I think it just needes some name (ie interface is resevered or something with MSVC) fixes to compile on windows.
<tewk> But I really need to just sit down and take the hour it would take to merge it.
% allison has left allison!~chatzilla@sub17-30.member.dsl-only.net
% particl1 has joined #parrotsketch
% particle has left particle!~particle@c-24-19-12-148.hsd1.mn.comcast.net
% allison has joined #parrotsketch
% particle has joined #parrotsketch
% particl1 has left particl1!~particle@c-24-19-12-148.hsd1.mn.comcast.net
% b2gills has joined #parrotsketch
% b2gills has left #parrotsketch
% AndyAgain has joined #parrotsketch
% AndyAgain is now known as Andy
% Andy has left Andy!~Andy@64.81.227.163