On Wed, Mar 27, 2002 at 02:46:21PM -0500, Michel J Lambert wrote: > My methodology in creating this patch was to first apply Daniel's patch, > and then get it working. His patch had significant changes to an older > version of pbc2c.pl, which I tried to apply to the newest version. I then > proceeded to try and integrate them back into the current version of the > code. I guess it simplified enough that the new file was completely > identical to the original, sans whitespace. So I don't believe anything > has changed.
Quick check: use 'diff -b' to compare while ignoring whitespace. > Per the previous paragraph, I believe it should still work fine. I'm not > familiar with the existing bytecode to C compiler, and didn't know it used > CGoto.pm. I don't see *why* it does, since C.pm, CPrederef.pm, and > CGoto.pm seem to me like they should be used for the various cores. I'm > not sure how I use this compiler, but I think I've made a decent amount of > changes to CGoto.pm such that it either won't work, or will suddenly have > all it's problems fixed. Can anyone tell me how I'm supposed to use > pbc2c.pl? Read docs/running.pod. Last time I left it, pbc2c.pl worked. (I think I only touched CGoto.pm to fix it last time, though.) pbc2c requires similar enough functionality to the ops cores that I think it should remain an OpTrans/ modules. But I'd vote that your computed goto core should get the CGoto.pm name, and the existing one for pbc2c.pl should be renamed to something else. PlainC? Native? Decompile? >From a cursory look at your patch, I doubt many of your changes will really make sense for pbc2c. Though there might be enough in common for one to subclass the other (or pull out a common superclass); I don't know. > Problems with my patch: > + includes a commenting-out of the keyed function. That probably should > not be in this computed-goto patch. I just submitted a patch that may conflict with this, that makes the keyed stuff work when used internally. I don't know if it'll get committed, though. Hm, on a second look, I think they may not conflict after all. I don't think I ended up touching set_keyed. Your patch had Windows droppings all over it -- there's a carriage return at the end of every line. Is there some way you can suppress those?
