[PATCH] Make obscure.ops work
I realize that obscure.ops isn't a big deal, but why not make
it work? Thus this patch. This patch eliminates the versions
of the ops that accept integers, under the assumption that trig
on integers is extraordinarily silly.
Index: obscure.ops
===
RCS file: /home/perlcvs/parrot/obscure.ops,v
retrieving revision 1.6
diff -u -2 -p -r1.6 obscure.ops
--- obscure.ops 3 Jan 2002 19:41:46 - 1.6
+++ obscure.ops 21 Apr 2002 02:49:21 -
@@ -37,6 +37,4 @@ Reference:
-=item B(n, i)
-
=item B(n, n)
@@ -45,6 +43,6 @@ Set $1 to the coversine (in radians) of
=cut
-inline op covers(n, i|n) {
- $1 = 1.0 - sin((FLOATVAL)$2);
+inline op covers(out NUM, in NUM) {
+ $1 = 1.0 - sin($2);
goto NEXT();
}
@@ -53,6 +51,4 @@ inline op covers(n, i|n) {
-=item B(n, i)
-
=item B(n, n)
@@ -62,6 +58,6 @@ Set $1 to the exsecant of $2 (given in r
-inline op exsec(n, i|n) {
- $1 = (((FLOATVAL)1.0) / cos((FLOATVAL)$2)) - (FLOATVAL)1.0;
+inline op exsec(out NUM, in NUM) {
+ $1 = (1.0 / cos($2)) - 1.0;
goto NEXT();
}
@@ -70,6 +66,4 @@ inline op exsec(n, i|n) {
-=item B(n, i)
-
=item B(n, n)
@@ -78,6 +72,6 @@ Set $1 to the haversine (in radians) of
=cut
-inline op hav(n, i|n) {
- $1 = 0.5 * (1.0 - cos((FLOATVAL)$2));
+inline op hav(out NUM, in NUM) {
+ $1 = 0.5 * (1.0 - cos($2));
goto NEXT();
}
@@ -86,6 +80,4 @@ inline op hav(n, i|n) {
-=item B(n, i)
-
=item B(n, n)
@@ -94,6 +86,6 @@ Set $1 to the versine (in radians) of $2
=cut
-inline op vers(n, i|n) {
- $1 = 1.0 - cos((FLOATVAL)$2);
+inline op vers(out NUM, in NUM) {
+ $1 = 1.0 - cos($2);
goto NEXT();
}
--
Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]>
"It furthers one to have somewhere to go."
Style in *.pmc?
While editing *.pmc, I'm inclined to make various style details consistent. But I don't know whose style rules rule in *.pmc. If necessary, I'll be glad to create a pmc style guide. -- Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]> "It furthers one to have somewhere to go."
RE: Style in *.pmc?
Chip Salzenberg:
# While editing *.pmc, I'm inclined to make various style
# details consistent. But I don't know whose style rules rule
# in *.pmc. If necessary, I'll be glad to create a pmc style guide.
I'm not sure what the correct style is, but the coding style PDD should
be a good starting point. ( know that the indents are wrong, for
example.)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
[netlabs #529] New Jit
# New Ticket Created by Daniel Grunblatt # Please include the string: [netlabs #529] # in the subject line of all future correspondence about this issue. # http://bugs6.perl.org/rt2/Ticket/Display.html?id=529 > I'm currently working on the new jit from Jason Gloudon. Trying to make it work in ALPHA and may be some other architecture too.
Re: [PATCH] Arg direction information
G'day all. On Sun, Apr 21, 2002 at 08:24:36PM -0300, Daniel Grunblatt wrote: > Can you store this info in the 'op_info_table' too? Yes. CVSmeisters: Please ignore this patch. A replacement one will be available once "make test" is finished. Cheers, Andrew Bromage
[PATCH] Arg direction info, version 2
G'day all.
Adds argument direction information into Parrot::Op and the
op_info_table.
Cheers,
Andrew Bromage
Index: ops2c.pl
===
RCS file: /cvs/public/parrot/ops2c.pl,v
retrieving revision 1.22
diff -u -r1.22 ops2c.pl
--- ops2c.pl19 Mar 2002 23:28:50 - 1.22
+++ ops2c.pl22 Apr 2002 00:44:15 -
@@ -12,6 +12,13 @@
use lib 'lib';
use Parrot::OpsFile;
+my %arg_dir_mapping = (
+ '' => 'PARROT_ARGDIR_IGNORED',
+ 'i' => 'PARROT_ARGDIR_IN',
+ 'o' => 'PARROT_ARGDIR_OUT',
+ 'io' => 'PARROT_ARGDIR_INOUT'
+);
+
sub Usage {
print STDERR <<_EOF_;
usage: $0 trans input.ops [input2.ops ...]
@@ -232,6 +239,7 @@
my $body = $op->body;
my $arg_count = $op->size;
my $arg_types = "{ " . join(", ", map { sprintf("PARROT_ARG_%s", uc $_) }
$op->arg_types) . " }";
+my $arg_dirs = "{ " . join(", ", map { $arg_dir_mapping{$_} } $op->arg_dirs) .
+" }";
print SOURCE < $code,
TYPE => $type,
NAME => $name,
- ARGS => [ @args ],
+ ARGS => [ @$args ],
+ ARGDIRS => [ @$argdirs ],
BODY => '',
MAY_JUMP => 0,
};
@@ -115,6 +116,27 @@
{
my $self = shift;
return $self->{ARGS}[shift];
+}
+
+#
+# arg_dirs()
+#
+
+sub arg_dirs
+{
+ my $self = shift;
+ return @{$self->{ARGDIRS}};
+}
+
+
+#
+# arg_dir()
+#
+
+sub arg_dir
+{
+ my $self = shift;
+ return $self->{ARGDIRS}[shift];
}
Index: lib/Parrot/OpsFile.pm
===
RCS file: /cvs/public/parrot/lib/Parrot/OpsFile.pm,v
retrieving revision 1.18
diff -u -r1.18 OpsFile.pm
--- lib/Parrot/OpsFile.pm 19 Apr 2002 01:32:43 - 1.18
+++ lib/Parrot/OpsFile.pm 22 Apr 2002 00:44:17 -
@@ -93,6 +93,7 @@
my $short_name;
my $args;
my @args;
+ my @argdirs;
my $seen_pod;
my $seen_op;
my $line;
@@ -164,6 +165,7 @@
$short_name = lc $2;
$args = trim(lc $3);
@args = split(/\s*,\s*/, $args);
+ @argdirs= ();
$body = '';
$seen_op= 1;
$line = $.+1;
@@ -179,17 +181,21 @@
if ($use eq 'in') {
push @temp, ($type eq 'p') ? 'p' : "$type|${type}c";
+ push @argdirs, 'i';
}
elsif ($use eq 'inconst') {
die "Parrot::OpsFile: Arg format 'inconst PMC' is not allowed!"
if $type eq 'p';
push @temp, "${type}c";
+ push @argdirs, 'i';
}
elsif ($use eq 'inout') {
push @temp, $type;
+ push @argdirs, 'io';
}
else {
push @temp, $type;
+ push @argdirs, 'o';
}
}
@@ -207,7 +213,8 @@
#
if (/^}\s*$/) {
- $count += $self->make_op($count, $type, $short_name, $body, \@args, $line,
$orig);
+ $count += $self->make_op($count, $type, $short_name, $body, \@args,
+ \@argdirs, $line, $orig);
$seen_op = 0;
@@ -241,13 +248,15 @@
sub make_op
{
- my ($self, $code, $type, $short_name, $body, $args, $line, $file) = @_;
+ my ($self, $code, $type, $short_name, $body, $args, $argdirs,
+ $line, $file) = @_;
my $counter = 0;
my $jumps = 0;
foreach my $variant (expand_args(@$args)) {
my(@fixedargs)=split(/,/,$variant);
- my $op = Parrot::Op->new($code++, $type, $short_name, 'op', @fixedargs);
+ my $op = Parrot::Op->new($code++, $type, $short_name,
+ [ 'op', @fixedargs ], [ '', @$argdirs ]);
my $op_size = $op->size;
#
Re: [PATCH] Arg direction info, version 2
On Mon, 22 Apr 2002, Andrew J Bromage wrote: > Adds argument direction information into Parrot::Op and the > op_info_table. Applied, thanks. I also committed a patch that adds branch information too, I believe it will be usefull for you too. Daniel Grunblatt.
[PATCH] Re: parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
I think that I have perhaps discovered the solution to my inability to
compile parrot after 0.0.4.
It turns out that many (all?) things were compiling. I got a parrot.o,
for example. So none of the suspected problems with long long or cgoto
are now suspect. I was, for some reason, failing to link at the end,
but for some reason cc didn't return an error, so make didn't return an
error.
It turns out that the flags beign passed to my linker were
"-flat_namespace -L/usr/local/lib -L/sw/lib -flat_namespace" [sic]
Removing the second "-flat_namespace" worked.
The two questions:
1. Why don't other people run into this? Does this not show up if
you've built a perl later than 5.6.1 (which, IIRC, don't require
the explicit argument of -Dldflags=-flat_namespace upon Configure)?
2. Why didn't this cause a problem in parrot-0.0.4, where the option
was also duplicated (as I have later checked)?
Anyway, with the following patch I can just acccept all the defaults in
Configure.pl, then make; make test with no problems.
Index: hints/darwin.pl
===
RCS file: /home/perlcvs/parrot/hints/darwin.pl,v
retrieving revision 1.4
diff -u -r1.4 darwin.pl
--- hints/darwin.pl 8 Feb 2002 06:25:38 - 1.4
+++ hints/darwin.pl 22 Apr 2002 03:45:49 -
@@ -1,5 +1,6 @@
$c{ccflags} .= " -I/sw/include";
$c{ccflags} =~ s/-flat_namespace\s*//;
+$c{ldflags} =~ s/-flat_namespace\s*//;
$c{ldflags} .= " -L/sw/lib -flat_namespace ";
$c{libs} .= " -ldl";
$c{cc_warn} = "-Wno-shadow"
--
David "Cogent" Hand
Re: Style in *.pmc?
On Sun, Apr 21, 2002 at 02:15:42AM -0700, Brent Dax wrote: > Chip Salzenberg: > # While editing *.pmc, I'm inclined to make various style > # details consistent. But I don't know whose style rules rule > # in *.pmc. If necessary, I'll be glad to create a pmc style guide. > > I'm not sure what the correct style is, but the coding style PDD should > be a good starting point. ( know that the indents are wrong, for > example.) The PMCs were all written at different times, and advances have passed them by at different points in their history (eg, inheritance). They could probably use a brutal rewrite by a consistent hand. Certainly nobody's going to complain. (And welcome back! Where ya been all this time? Slumming over on the linux kernel or somewhere?)
Re: [PATCH] Re: parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
On Mon, Apr 22, 2002 at 12:00:31AM -0400, David Hand wrote:
>
> Index: hints/darwin.pl
> ===
> RCS file: /home/perlcvs/parrot/hints/darwin.pl,v
> retrieving revision 1.4
> diff -u -r1.4 darwin.pl
> --- hints/darwin.pl 8 Feb 2002 06:25:38 - 1.4
> +++ hints/darwin.pl 22 Apr 2002 03:45:49 -
> @@ -1,5 +1,6 @@
> $c{ccflags} .= " -I/sw/include";
> $c{ccflags} =~ s/-flat_namespace\s*//;
> +$c{ldflags} =~ s/-flat_namespace\s*//;
> $c{ldflags} .= " -L/sw/lib -flat_namespace ";
> $c{libs} .= " -ldl";
> $c{cc_warn} = "-Wno-shadow"
You sure about that patch? Looks like you're removing it and adding it
the next line.
Re: Style in *.pmc?
On Sun, 21 Apr 2002, Steve Fink wrote:
> On Sun, Apr 21, 2002 at 02:15:42AM -0700, Brent Dax wrote:
> > Chip Salzenberg:
> > # While editing *.pmc, I'm inclined to make various style
> > # details consistent. But I don't know whose style rules rule
> > # in *.pmc. If necessary, I'll be glad to create a pmc style guide.
> >
> > I'm not sure what the correct style is, but the coding style PDD should
> > be a good starting point. ( know that the indents are wrong, for
> > example.)
>
> The PMCs were all written at different times, and advances have passed
> them by at different points in their history (eg, inheritance). They
> could probably use a brutal rewrite by a consistent hand. Certainly
> nobody's going to complain.
s/could probably use/need/; as they stand, the PMCs fiddle about with
each others internals in ways that are simply wrong. For instance,
consider this code from perlint.pmc:
void concatenate (PMC * value, PMC* dest) {
STRING* s;
s = string_concat(INTERP,
SELF->vtable->get_string(INTERP, SELF),
value->vtable->get_string(INTERP, value),
0
);
dest->vtable = &Parrot_base_vtables[enum_class_PerlString];
dest->vtable->set_string_native(INTERP,dest,s);
}
By stomping on the destination PMC's vtable before assigning the string,
we're throwing away all knowledge of its contents, and thus won't be
able to do the right thing in cases when that PMC represents a tied
variable, for instance.
I've made a start on fixing this, and other breaches of encapsulation,
with my recent patch to perlstring.pmc, but I've been loathe to go
any further until I get some feedback from Dan and/or Jeff about
whether I'm fixing it right. If somebody else wants to take over this
I'd only be too happy -- I can go back to beefing up the test suite
(which is pretty sparse at the moment as far as the PMCs are concerned).
Simon
Re: [PATCH] Re: parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
On Sun, Apr 21, 2002 at 09:24:26PM -0700, Steve Fink wrote:
> On Mon, Apr 22, 2002 at 12:00:31AM -0400, David Hand wrote:
> >
> > Index: hints/darwin.pl
> > ===
> > RCS file: /home/perlcvs/parrot/hints/darwin.pl,v
> > retrieving revision 1.4
> > diff -u -r1.4 darwin.pl
> > --- hints/darwin.pl 8 Feb 2002 06:25:38 - 1.4
> > +++ hints/darwin.pl 22 Apr 2002 03:45:49 -
> > @@ -1,5 +1,6 @@
> > $c{ccflags} .= " -I/sw/include";
> > $c{ccflags} =~ s/-flat_namespace\s*//;
> > +$c{ldflags} =~ s/-flat_namespace\s*//;
> > $c{ldflags} .= " -L/sw/lib -flat_namespace ";
> > $c{libs} .= " -ldl";
> > $c{cc_warn} = "-Wno-shadow"
>
> You sure about that patch? Looks like you're removing it and adding it
> the next line.
Well, "-flat_namespace" needs to be there that once, but only once.
What was happening to me was that it was being added even though it was
there. It seems rather easier to remove it if it exists and then
unconditionally add it, rather than looking for it and adding it if it's
not there.
Either way, though, really. Perhaps this instead?
Index: hints/darwin.pl
===
RCS file: /home/perlcvs/parrot/hints/darwin.pl,v
retrieving revision 1.4
diff -u -r1.4 darwin.pl
--- hints/darwin.pl 8 Feb 2002 06:25:38 - 1.4
+++ hints/darwin.pl 22 Apr 2002 04:32:28 -
@@ -1,5 +1,6 @@
$c{ccflags} .= " -I/sw/include";
$c{ccflags} =~ s/-flat_namespace\s*//;
-$c{ldflags} .= " -L/sw/lib -flat_namespace ";
+$c{ldflags} .= " -L/sw/lib ";
+$c{ldflags} .= " -flat_namespace " unless $c{ldflags} =~ /-flat_namespace\s*/;
$c{libs} .= " -ldl";
$c{cc_warn} = "-Wno-shadow"
--
David "Cogent" Hand
PMCs on parade
According to Simon Glover: > I've made a start on fixing this, and other breaches of encapsulation, > with my recent patch to perlstring.pmc, but I've been loathe to go > any further until I get some feedback from Dan and/or Jeff about > whether I'm fixing it right. If somebody else wants to take over this > I'd only be too happy [...] I'll be glad to. Lots of the PMC subsystems looks Topaz-like to me. That's almost certainly a case of convergent evolution rather than derivation, but in any case, the PMCs look really interesting to me. -- Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]> "It furthers one to have somewhere to go."
Back from Neptune
According to Steve Fink: > And welcome back! Where ya been all this time? Slumming over on the > linux kernel or somewhere? Thanks. I've been making Real Life changes: I quit my day job and I'm going to college for the first time in my life at age 38; so I need to find consulting work that I can do over the net in between classes (hint, hint :-)). -- Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]> "It furthers one to have somewhere to go."
