msg dukeleto I am working on TT#1217 & TT#1218. Summary: When testing DynPMCs via `loadlib`, each test must run as a separate instance of Parrot. The first patch, while otherwise perfect, causes false negatives; every test after the first successful test will pass, even if the PMC cannot be loaded, because it was *already* loaded by the prior test. Details->tickets when I return in 12 hours; going offline.

somebody said hachi was extremely slow at it or http://kuiki.net/ or http://kuiki.net/hachi or dateless or duct-taped to the channel or (see kyuu) or the sound you make when you sneeze or not really named Sharls Davis Kendy or a geeky fanboy, people should keep a tazer nearby to fend me off or okra or not okra or Japanese for 8 or full or (920) 420-0656 or dreamy or works for LiveJournal (http://news.livejournal.com/92408.html)

I would personally prefer a setup.nqp instead of setup.pir, but looking at the setup.pir he sent me for Plumage, most of the code is setting up multi-level configuration hashes, and then calling into his framework. Unfortunately right now NQP doesn't do very well at declaring hash structures, so it's not a huge win to convert at the moment.

Come to think of it, you don't even have to build up the list at run time and then convert it; you can loop at AST time building a bunch of $P0[$P1] = $P2 nodes, and just iterate over the AST children setting $P1 and $P2 (or $S0 and $P1 if the keys are forced to be strings)

NotFound, also, Plumage currently is using the JSON parser to initialize some big hashes, but I end up having to do a second pass over the data to programmatically fix up JSON's lack of data types. Sucky.

pmichaud, ISTR that I need both positional flattening and named flattening, but positional is definitely by far the more immediate issue. I've got PIR code that exists for no reason but to manually flatten arg arrays in certain ways. Ew.

We have a policy about that. I don't like it a whole lot. I mean, if it makes parrot better, *please* break my code, all over, twice a day. But that isn't what the policy says about changing the tool's behabiour.

It'd be kinda nice if we could break everything all the time like ninjas, but having a deprecation policy makes life better for people who we expect will eventually want to use Parrot, even if only by getting us in the mindset of not deprecating stuff at random.

NotFound: as in "Only passes parse if the makefile uses only the intersection of supported features from all makes" or as in "Only passes parse if no make will actively error or do the wrong thing given this makefile"?

minor question about the nqp-rx merge : shouldn't it be named parrot_nqp (instead of parrot-nqp) to match parrot_config and parrot_debugger. Also `make realclean` doesn't remove parrot-nqp* properly (I have a patch for this).