Actually, the version of the patch in my branch doesn't remove parsing logic from IMCC, it only removes the PASM compreg and the is_pasm option from most interface options. If we want to put in the effort we probably can remove all PASM-specific logic from IMCC completely, which would probably lead to some significant cleanups and some small performance improvements. I haven't done that yet but it's probably worthwhile to pursue.
I'll take a look at that packfileconstanttable.t test in the branch. I suspect the test is relying on some PASM-specific behavior and can probably be removed since the exact ordering of PMCs in the constant table from compiled PIR is not and never has been guaranteed. --Andrew Whitworth On Sun, May 6, 2012 at 6:14 PM, Will Coleda <[email protected]> wrote: > On Sat, May 5, 2012 at 7:53 AM, Will Coleda <[email protected]> wrote: >> We've been saying for years now that users shouldn't use PASM, but PIR >> (and lately, a push to NQP or winxed instead of PIR). Are any of our >> users currently using PASM? >> >> Moritz, JimmyZ, Whiteknight, and I are investigating what a parrot >> without PASM looks like in the coke/rm_pasm branch. >> >> So far for this branch: >> >> * parrot will no longer try to parse foo.pasm as a PASM file. >> * t/ tests that happen to use PASM are being rewritten in PIR >> * t/ tests that test PASM itself are being dropped >> * generated constant files are now PIR instead of PASM - drop in >> replacement except for s/.pasm/.pir/ >> * some doc updates >> >> Still to come: >> * more work to be done updating t/ >> * more doc updates >> * convert/drop any remaining .pasm files >> * remove PASM compiler from IMCC >> >> >> -- >> Will "Coke" Coleda > > All test files but one now pass in the branch - much thanks to JimmyZ > and moritz and whiteknight for their tuits. > > t/pmc/packfileconstanttable.t > not ok 16 - First entry in constant table is a sub > # Have: FixedIntegerArray > # Want: Sub > > Any eyes on that would be helpful. I'm not sure if the test itself > makes sense in a non-PASM world. > > IMCC internals still know how to parse PASM - we need to remove that - > whiteknight has a version of this in his branch, but it broke parrot's > bundled nqp, so we might need something a little less aggressive > there. I'm going to start on this next. > > Any feedback? Is something we can merge? > > -- > Will "Coke" Coleda > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
