[prev] [thread] [next] [lurker] [Date index for 2003/10/24]
Steve Purkis <spurkis@xxxxx.xxx> writes:
> On Wednesday, October 22, 2003, at 08:53 pm, Piers Cawley wrote:
>
>> Steve Purkis <spurkis@xxxxx.xxx> writes:
>>
>>> On Wednesday, October 22, 2003, at 04:04 pm, Mark Fowler wrote:
>>>
>>>> Okay, so the question is, where are we heading now?
>>>
>>> Good question. I did post a short-term plan last week which I'll get
>>> started on in my copious amounts of spare time, but AFAIK there are no
>>> plans further than that. Not for lack of ideas, mind you... I've
>>> submitted quite a few patches in the past, and I know Piers has a
>>> whole stack of them tucked away somewhere. But as far as I'm
>>> concerned Piers is still the lead developer on this project - I've got
>>> the go-ahead to do maintenance, but aside from that I think we need
>>> some feedback from Piers before we can decide which way to go.
>>
>> The current problem with Pixie, as I see it, is that the locking
>> stuff isn't working very well at all, and without locking Pixie is
>> very limited.
>
> Right, that's already #1 in the TODO list.
>
>
>> I can't remember if we've fixed the object graph stuff to use a
>> separate table yet (and if we haven't, we should do...).
>
> It doesn't look like it - I remember we had a good long talk about it
> though. I'll add it to the list.
>
>
>> Other plans include getting rid of a few more of the case statements
>> that work on the reftype of the object, and switch to using
>> polymorphic dispatch with Heritable::Types instead.
>
> Ok, but you'll have to point out which.
>
>
>> There's also a case to be made for unbundling Pixie::Info as it's a
>> handy tool for other things as well I think.
>
> I agree, though I think this is lower priority. I'm also worried
> about Pixie overwriting info another object has set... maybe if you
> could configure the magic number used?
Well, I did claim it on p5p, and it's way up in the 128-255
range... It's why I want it unbundled tbh. Brush it up slightly so
the info scalar is actually a hash of hashes keyed on 'using'
package. So Pixie would have
$thing --magic-pointer--> { Pixie }{oid}
and Foo would have
$thing --magic-pointer--> {Foo}{bar}
In fact, if memory serves, we already use this two level structure.
Once we get Scalar::Footnote (or whatever we call it) released, we're
far less likely to see people clashing with the magic number.
>>>> I can't really do much on Pixie development, it being a little over
>>>> my head atm, but what I'd really like to do is start adding
>>>> comments to the Pixie source code, and maybe working on the
>>>> documentation.
>>>>
>>>> Does this sound like a good idea? What's the best way for me to go
>>>> about this. Obviously, I'd really like someone to be checking my
>>>> working to make sure my comments aren't completely wrong.
>>>
>>> I think adding some Pod is a good idea,
>>
>> More Pod is always a good idea, documenting how to use the bloody
>> thing.
>
> I've got some kicking around somewhere that I'll put in.
>
>
>>> but I'd go easy on the comments - I know for a fact James prefers
>>> self-documenting code, and I assume Piers does too as his code is
>>> quite readable.
>>
>> Why thank you. Generally my gut feeling is that every time I think
>> "Maybe I should add a comment here?" I'd be better off working out
>> what it is about the code that is hard to understand and rewriting it
>> so it's clear.
>
> Yeah, I must admit I'm sold on the idea too. Only comments I tend to
> put in nowadays are TODO items that I can grep for when I'm feeling
> bored ;-).
>
>
>> Admittedly, there are a couple of places where Perl
>> makes that very hard to do (I'm thinking particularly of the code
>> that does the Data::Dumper -> exec tricks, which uses dynamic scoping
>> in slightly weird ways).
>>
>>> Maybe some design docs would be a better idea? I'm more than happy
>>> to go over things with you, time permitting. But bear in mind I'm
>>> still learning too.
>>
>> I've been meaning to write something along those lines as a
>> presentation at some point, but I've not done it yet. Tuit shortage
>> can be a terrible thing.
>
> Well, that's something that Mark and I can work on then. It will be
> handy for others looking under the hood.
>
> What do you think about the plan I posted the other day? Here it is
> again, slightly modified:
>
> 1. tag current release as 'dev-22-10-2003' [done]
> 2. commit sources of 2.06 as 2.08_01 and go from there. *
> 3. update the TODO list
> 4. apply http://staging.quiup.com/perl/Pixie-2.06-reconnect-bug.patch
> 5. add Mark's recursive structures TODO tests
> 6. update docs
Make sense.
> The only problem is (2) - I don't want to throw away any work you've
> done, but in order to keep developing on top of the current codebase I
> need to know how stable it is. It passes all but one (minor) test,
> but I've not yet had the chance to try it out in development. What do
> you think?
I want to throw out a most of the work I've done tbh. The release is
at least mostly working for a single process, which is useful as far
as it goes. Moving the object graph out to a separate table is
probably the first thing that should be done once we have a new
release. (I may have code that does that already btw. I need to get
something written for Neil Baumann first, and then I'll get onto it)
> PS: I have a lot of other ideas, but I'll keep them seperate for now.
Okay.
There's stuff above here
Generated at 13:56 on 01 Jul 2004 by mariachi 0.52