[perl #41908] merging extension guessing feature for library.c
Mike Mattie
now that 0.4.10 has released I would like to merge rt# 41908 which introduces extension guessing.
The current implementation does not affect the behavior of existing code. No new test-suite
regressions are introduced.
the .load_byte_code op will now accept "foo" trying ".pbc",".pasm",".pir" in order. compatibility
with existing code is preserved by trying "foo" as-is first so "foo.pir" will still be preferred
over a compiled version in the search paths.
I have considered that this functionality may need to be presented in a perl5'ish way. If it
is possible for the argument to .load_bytecode to be unquoted then
.load_bytecode "foo.pir" # provide the current behavior.
.load_bytecode foo # provide the extension guessing similar to perl5 use.
As mentioned in the proposals in the RT ticket, PARROT_LOAD_PREFER=compile|source could
be used to control whether source or compiled objects are preferred in loading. This
allows the development cycle to retain it's scripting interactivity with a single
environment variable set, and efficient default (installed) behavior of preferring a
compiled object. Note that the latter is how perl5 currently behaves.
Future:
It may make since for byte-code and shared object loading to be unified in a new
interface. An opcode such as .load_module could intelligently load
shared objects, byte-code, and source. This could be the path to implementing the
API cleanup proposed at the end of rt #41908 , where locating the file, and
detecting the type of file is cleanly separated; getting dynext.c out of library.c's
internals.
This does not necessarily have to replace the existing functions.
Cheers,
Mike Mattie (coder...@gmail.com)
Paul Cochrane via RT
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...)
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
>
Mike Mattie
"Paul Cochrane via RT" <parrotbug...@parrotcode.org> 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.
Mike Mattie
"Paul Cochrane via RT" <parrotbug...@parrotcode.org> 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 noticed that the patch was generated before I had turned off the
tabs in my editor. I have rebased the patch against 18443 and
double checked it for any tab issues. passed full test harness
on i686-pc-gnu-linux.
Paul Cochrane
> I noticed that the patch was generated before I had turned off the
> tabs in my editor. I have rebased the patch against 18443 and
> double checked it for any tab issues. passed full test harness
> on i686-pc-gnu-linux.
Many thanks for rebasing the patch! I've applied it as r18446, thanks :-)
I've tested the patch on linux x86, could others please confirm that
it works as expected on their platforms?
Paul
Paul Cochrane
> 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.
Please accept my apologies, you're correct it didn't break anything,
just wasn't appropriate so close to a release.
Paul
Mike Mattie
"Matt Diephouse via RT" <parrotbug...@parrotcode.org> wrote:
> On Wed Mar 21 03:44:10 2007, codermattie wrote:
> > Hello,
> >
[snip]
> 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.
I wanted to do things incrementally. With RT #42898 the patch sequence
dealing with extension guessing is code complete. With the full interface
cut in code I will do up the tests and docs as #429898 gets kicked around.
The relationship between #41908 and the patch may not be entirely clear
because I wanted to get feedback on my plan before I finished all the changes.
That is why there is so much speculation in #41908.
I also took care to make sure the existing tree was not disrupted,
and that the new behavior could be adopted incrementally.
The latter in particular was why what could have been one patch was split
into #41908, and #42898. I wanted the preservation of existing behavior tested
by other people before I took the next step.
I will keep your comments in mind with my future submissions to RT. Your reply
indicates that at the very least I could improve my clarity when communicating
with the project.
With these comments in mind if you have a better approach I for the future
please let me know about it.
Cheers,
Mike Mattie - coder...@gmail.com
> Thanks.
>
> --
> Matt Diephouse
>
Cheers,
Mike Mattie - coder...@gmail.com
Paul Cochrane via RT
> On Wed Mar 21 03:44:10 2007, codermattie wrote:
> 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.
The discussion of the solution to the install target problem has been
split out into a separate ticket: RT#42901
Closing the current ticket.