On Sun, 06 May 2007 07:52:04 -0700 "Paul Cochrane via RT" <[EMAIL PROTECTED]> wrote:
> Matt, > > This patch actually broke stuff and was reverted shortly before > Parrot 0.4.10. It needs to be reapplied, and then checked that it > doesn't break anything (IIRC there were problems on Win32), hence why > the ticket is still open. I've only just returned from 3 weeks > overseas and haven't had time over the past couple of months to > attack the ticket. If you have the tuits, go for it! other than > that, I'll have a go at it hopefully sometime soon (famous last > words...) I don't remember it breaking win32. As I remember it, it was committed the day before 0.4.10 , which wasn't appropriate for a patch like this. If there are win32 issues I would really like to know about them so I can resolve them. This patch should not change existing behavior at all. It adds a bit of infrastructure so that more flexible behavior can be easily built on top of it later. It is a "new feature" , but from my point of view it is a incremental towards a bug fix. What sort of format/extension a parrot file will have is entirely random; this includes critical pieces such as the runtime library, making use of basic facilities difficult. I want to break the hardwiring of the format (.pir|.pbc) when a module is loaded. Once the loader figures out the format loaded instead of hard-coding it all over the parrot tree, then something can be done about normalizing the standard library. ".load_bytecode" would also be more like perl "use" instead of perl "do" . With patch 5 #41908 the extension is still hardcoded, just inside parrot instead of all throughout the parrot source tree. Currently the first open attempted is with the name as-given , so it implements past/current parrot behavior. Sane behavior for selecting the right format when there are multiple formats for the same source was proposed as PARROT_LOAD_PREFER. I have authored a couple of lengthy messages hashing out these issues. I was stalled due to time for a few weeks , but I have dropped enough items off my open-source TODO to take a crack at this again. > Paul > > > I'd like to get this ticket (#41908) resolved. The patch was > > applied, so everything is good > > there, but your reply here has left me wondering. If there is more > > to be done, could you open > > another ticket? > > > > It's better to split off new requests/bugs into new tickets rather > > than keep them in the patch > > ticket because it cuts down the amount of reading that needs to be > > done when sorting > > through tickets. The patch itself doesn't seem that relevant that it > > couldn't be a separate > > ticket. > > > Thanks. > > > > -- > > Matt Diephouse > > > > >
signature.asc
Description: PGP signature
