niner / Inline-Perl5 Public

…tribute"

This reverts commit eaff08f due to segfaults
in complex (multi-threaded) applications with apprently broken my_perl pointers.

IterationBuffer is a thin wrapper around VM arrays and doesn't have the
containerization and error checking overhead of standard Array. Binding instead
of assigning can avoid having to create Scalar containers.

Explicit return is still slower than fall through

Since new-disp, multi dispatch on constants is as fast as multi dispatch on
types, so we can get rid of the P5Types workaround (regardless of how elegant
that was)

Implement MRO which doesn't depend on C3MRO internals

Provide own `mro` method which either depends on DFS or C3
linearization.

Fix an MRO-related exception

Perl6::Metamodel::C3MRO `%!mro` attribute got additional 'all_conc' key
under both top-level keys.

Fix access to $=finish via CALLER pseudo

Same fix as in a3e5f85. Just forgot that
there is a copy of the affected code and this copy needs fixing as well.

0 is a legal object keeper index. -1 is used as "no reference" sentinel.
This brings p5_free_wrapped_perl6_obj in line with other functions dealing
with p6mg->index.

While the ObjectKeeper is thread safe (by virtue of having one per Perl
interpreter) it is not actually reentrant. This matters when during a call
to ObjectKeeper.keep a garbage collection run takes place and this run causes
a Raku object to be freed that holds the last reference to a Perl object which
reference another Raku object. The latter would then be removed from the
ObjectKeeper. If this happens between reading $!last_free and updating
$!last_free with the next location read from the free-chain we end up writing
the object to keep into a position that has just become part of the free-chain.

Fix by making sure we only read $!last_free once, so we get a consistent
result. The downside of this simple fix is that instead of crashing we
actually lose a slot in the objects array. This slot is the one that would have
been pointed to by $!last_free, but is now missing from the free-chain.
However, since this is incredibly rare, it's not clear if a more comprehensive
solution is really necessary.

If a Perl object supports stringification, we can make use of it to gist to
something more interesting than just the class name.

I think these methods would still access the original Perl interpreter instead
of the current thread's.

When Raku calls into Perl which calls into Raku which finally calls into Perl
and the latter throws an exception object, along the way back to the outer
Raku code this object got turned into an empty string which was then no longer
recognized as an exception.
Wrap such objects in Inline::Perl5::Exception objects which are derived from
Exception and delegate stringification.

SPAGAIN must be called after the global Perl stack pointer may have changed and
PUTBACK must be called after the stack pointer was modified globally. It
follows that a PUTBACK directly after an SPAGAIN makes no sense. We just copied
the stack pointer in one direction. Copying back us useless busy work. Same is
true for the other direction. pop_return_values does a PUTBACK. This makes an
SPAGAIN afterwards superfluous.

It is possible that during the callback for removing an object from the object
keeper, we run a GC which in turn may cause some Perl object to be freed. Seems
prudent to refresh the stack pointer after this call.

`CALLER` is actually a dynamic chain only pseudo-package. The only reason
`CALLER::<$=finish>` worked previously is due to a bug in underlying
`PseudoStash`. Correct access must be done via `CALLER::MY::<$=finish>`.

It is also not necessary to workaround a bug in Rakudo by manually
instantiating a `PseudoStash` instance. The above used `CALLER::MY::`
syntax sugar works now.

The trick with 3 different modules implementing a find_best_dispatchee sub
worked during compilation of Inline::Perl5::ClassHOW. Unfortunately it doesn't
work when one tries to install the distribution, because there the error to
compile the Full version causes installation to abort.

Instead of using modules to contain any compilation errors, we now run a
separate compilation process manually and if that succeeds, EVAL the code in
place.

It would be more elegant to just catch any exceptions thrown by an EVAL, but
that leads to other errors as EVAL during BEGIN time will modify the state
of the outer compiler and the exception leave that state inconsistent.

So far we've relied on the method cache to make our custom DESTROY method
available. Since the method cache is on its way out, find_method needs to
step in. No idea why I excluded DESTROY from that in the first place.

Apparently when trying to get things to work I made find_method is raw at some
point and didn't check if that was actually necessary. Either that or at some
point it actually was necessary (for whatever reason). Anyway it's not needed
now and there's no good reason to return Scalar containers. Quite contrary,
that can only hurt if the caller doesn't decont.

With rakudo's new dispatch implementation find_best_dispatchee is no longer
used. This uncovered a copy&past bug that led to $many-args getting added
to the proto twice instead of $many-args and $scalar-many-args. Wasn't a
problem before, because the proto's candidate list hasn't been queried when
looking for a candidate. Instead the custom find_best_dispatchee
implementation picked the right one directly.

Fixes issue #164.

Add syntax highlighting tags to README.md

By tagging the code blocks with the correct languages both GitHub and Raku Land (https://raku.land/cpan:NINE/Inline::Perl5) will be able to syntax highlight them correctly.