B-JVM-Jasmin

 view release on metacpan or  search on metacpan

ChangeLog  view on Meta::CPAN

	* Java/org/perl/internals/Scalar.java: added seq and sne functions

	* Jasmin.pm (B::LOGOP::JVMJasminPre): got cond_expr working
	(B::BINOP::JVMJasminPost): fixed seq and sne work

1999-12-04  Bradley M. Kuhn  <bkuhn@ebb.org>

	* lib/B/JVM/Jasmin/Emit.pm (nop): added method

	* Jasmin.pm (B::BINOP::JVMJasminPre): had to change things so that
	the "concat" pre-processing did argument IN order.  It looks like
	the "trick" of processing things in reverse order may be
	problematic.  In this case, it occurred because if there are
	cascaded BINOPs of "concat" type, and some of them are actually
	".=" operations, we can get the wrong r-values in cases like:
	$x = $y . ($y .= "f");

	* lib/B/JVM/Jasmin/Emit.pm (dup): spruced up the POD and error
	messages for this function
	(swap): added function

Jasmin.pm  view on Meta::CPAN

  } elsif ($name eq "print") {

=item print

For a "print" LISTOP, we need to process the kids in reverse order, save
pushing the C<LIST_MARK>, which must happen first (the "print"
post-processing depends on the mark being there).  As in many instances,
Perl appears to its own stack like a queue at times, and this causes
problems, since we are using the JVM operand stack.  In other words, for a
"print" LISTOP, the Perl stack looks like this (left is top):

LIST_MARK, "1", "2\n"

However, this would print the string "12\n", not "2\n1".  It's as if Perl
first finds the mark, and then processes from the mark to the end of the
stack as a queue!  (This behavior is probably documented somewhere else, but
I just discovered it serendipitously (perhaps I should read documentation
more :)).  So, to process a "print" statement, we grab the "pushmark" OP
first, process that, and then call C<WalkOPTree> recursively in I<reverse>
for the rest of the sub-OPs.

lib/B/JVM/Utils.pm  view on Meta::CPAN

=cut

#-----------------------------------------------------------------------------

=item B::JVM::ExtractMethodData

usage: B::JVM::ExtractMethodData(METHOD_STRING)

Takes a string that is believed to a valid method string for a JVM method, and
if it is a valid method string, returns a hash reference that looks like:
  { methodName => NAME_OF_THE_METHOD,
    returnType => TYPE_ID_OF_RETURN_TYPE,
    argumentTypes => [ ARGUMENT_1_RETURN_TYPE_ID,
                       ARGUMENT_1_RETURN_TYPE_ID,
                       ... ] }
An undefined value is returned if the method string is not valid.

=cut

sub ExtractMethodData {

perljvm.PL  view on Meta::CPAN

#
# You may distribute under the terms of either the GNU General Public License
# or the Artistic License, as specified in the LICENSE file that was shipped
# with this distribution.

use Config;
use File::Basename qw(&basename &dirname);
use Cwd;

# List explicitly here the variables you want Configure to
# generate.  Metaconfig only looks for shell variables, so you
# have to mention them as if they were shell variables, not
# %Config entries.  Thus you write
#  $startperl
# to ensure Configure will look for $Config{startperl}.

# This forces PL files to create target in same directory as PL file.
# This is so that make depend always knows where to find PL derivatives.

$origdir = cwd;
chdir dirname($0);