that's why i suggested, that parrot and the languages should somehow bring the base dir into the environment, which can be somehow picked up by all parrot tools, e.g. check envvar PARROT_HOME, if not exist, try find parrot in PATH, if exist, set PARROT_HOME internally to one dir up, if not in path, use argv[0], maybe there is a whole path...

All kidding aside, I'd really like to see all other installation methods for Parrot projects go away, and Plumage be considered canonical. Only then can we get people eating dog food enough to really work out all the problems.

I've designed (but been too sick to implement yet -- soon though) the ability to say 'plumage upgrade all' and have it pull down the projects, find the minimal parrot version that works, rebuild and reinstall parrot, and then reinstall all projects on top of it.

pmichaud, I've been thinking about that, actually. I want people to be able to (in fact, I think according to the design of Perl 6, we *have to*) be able to install multiple versions of any Parrot project. And I'm running up against the problem that parrot's library handling structure really doesn't like to do that, especially for HLLs.

On a separate note ... according to the P6protoobject docs, it's possible to override the proto object's .new() by just declaring a method new in the class itself. But what do I need to put in that method to instantiate the object?

pmichaud, I'd be willing to make the first half of my new method be inline PIR at this point. I just don't know what PIR to use ... because the only example I have is the proto object new method, and that's written from the perspective of a completely different point in the meta space.

pmichaud: Going slightly off topic (back to your comment about 2 PMCs per object), would there be any way to default to not having them, and then 'promote' (similar to autoboxing) when a request that requires them is made?

I could really use even some example inline PIR of how to create an object from within an NQP class's new() method. I want my new() to be able to take an argument, and I can't do that with the default protoobject new

I don't know if we must fix this by storing the values in a FLOATVAL variable before comparing, or fix the test because is wrong to compare for exact equality two floating values calculated in different ways.

parrot: Merge convert_OSNAME into trunk. In config steps after auto::arch, we know 'osname', so use '->data->get('osname')' instead of '->data->get_p5('OSNAME')'. Cf.: https://trac.parrot.org/parrot/ticket/1194.