RE: [netlabs #801] [PATCH] PerlArray in scalar context
Sean O'Rourke:
# > # 4 - the other arrays boosted to the highest dimension
# > It's already been defined to be #4.
#
# Argh. Then I need to whinge a bit -- what if it's a ragged
# array? What if different elements have different dimensions
# themselves, e.g. "[1,[2,3]]"? I think there's serious
# can-of-worms potential here, and by making hyping more
# "intelligent", we'll actually make it useful in fewer cases.
I don't see any cases where it becomes *less* useful by making it more
intelligent. Can you give an example?
As for the ragged array argument, I would argue for the following
statement in the documentation:
The behavior of hyperoperators with ragged and recursive
data structures is undefined (and likely to be downright
weird).
# > My point was that we can't just render it into bytecode
# that directly,
# > unless all the arrays are typed (in which case we know the
# > dimensionality).
#
# I've been mostly thinking of the static parts of Perl 6, so
# add that to the grain of salt you apply to my posts. Along
# similar lines, I didn't intend that to be a "this is exactly
# how hyper-operators are implemented" post, but just a "this
# is one reason why we don't want a `hype' opcode" one. If we
# have to play dynamic shenanigans with hyperoperators, we can
# still figure out the appropriate dimensions in bytecode, then
# do the appropriate looping recursively on each dimension.
# But for the simple, static case, we should use the simple version.
Absolutely. If we know the dimensions at compile-time, we should use
that information. But I have a sneaking suspicion that that won't be
the general case.
# > I'd imagine that we'll have to have an opcode like:
# >
# > hyper P0, P1, P2, LABEL
#
# I'm not seeing why this should be an opcode. The point of my
# innocent example was that hyping isn't an ordinary 3-operand
# kind of thing. Hyperoperators can change the way an entire
# expression is compiled (for the C++ buffs out there, check
# out POOMA and/or the matrix template library). The code
# below will give the correct result, but we can do better by
# avoiding the temporaries when dimensions are known at compile
# time (or maybe even at run-time, though I haven't thought it through).
I think that when dimensions aren't known until runtime, we'll need a
'hyper' opcode. Keep in mind how much it could inflate the bytecode if
we render a ton of generic, N-dimensional hyper-operator logic into
bytecode.
I suspect that rendering this into C will:
a) keep the general logic in one reusable place
b) shrink the bytecode size
c) possibly speed up execution (optimizer good...)
# > (though a real compiler would fold those into one.)
#
# That would be pretty hard (I think), since it involves
# coalescing two subs into one, then cleaning out a bunch of
# temporaries.
Perhaps. Looking for identical subs seems like an obvious size
optimization to me, but I'm not really a compiler guy. :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"In other words, it's the 'Blow up this Entire Planet and Possibly One
or Two Others We Noticed on our Way Out Here' operator."
--Damian Conway
[perl #17025] [PATCH] again #16895 ops2c.pl
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17025]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17025 >
If this one is already in queue, bare with me.
find_op does either die or return false positives for non existing ops.
Please[1] apply,
leo
[1] I'd really like to get rid of my ever increasing imcc changes (~100K
+100K generated parser/lexer), but I can't, because of core damage.
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/36594/29537/873f17/ops2c.pl.diff
--- ops2c.plWed May 15 08:23:22 2002
+++ /home/lt/src/parrot-007/ops2c.plSat Aug 31 19:57:13 2002
@@ -401,8 +401,7 @@
int op;
int i = 2;
if((op = op_hash_jump[bucket]) == 0) {
- printf("Invalid bucket for %s\\n", name);
- exit(0);
+ return -1;
}
for(;;) {
if(name[i] != op_hash[op].name[i]) {
@@ -411,8 +410,12 @@
return -1;
continue;
}
- if(name[i] == 0)
- return op_hash[op].opcode;
+ if(name[i] == 0) {
+ int n = op_hash[op].opcode;
+ if (strcmp(op_info_table[n].full_name, name))
+ return -1;
+ return n;
+ }
i++;
}
}
[perl #17026] [PATCH] core.ops including #16838
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17026]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17026 >
core.ops has currently:
- obvious errors e.g.
-inline op mul (out PMC, out PMC, out PMC) {
- wrong docu and minor typos e.g.
-=item B(in PMC, in STR)
- and finally (as discussed in perl6-internals, "core ops ARGDIR"),
wrong ARGDIRs for PMCs:
This patch changes almost all PMCs to inout, actually these, where a
vtable is called, because the underlying PMC has to exist at this moment.
This patch is crucial[1] for the waiting big imcc update.
[1] imcc does now a full life analysis of all symbols. The register
allocator depends on this life info for register reusing, so getting
this right is *really* important.
This patch is tested with imcc/perl6 from CVS as well as with my imcc
version, and has currently no impacts on other parts of parrot, though
the JIT people might have a closer look at it.
$ perl6 --test -Rj # run all perl6 tests jitted
brings the same result as w/o the patch (i386-linux) (i.e. 2 additional
failures, which might hide somewhere in JIT code).
Please apply,
leo
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/36596/29540/29af40/core.ops.diff
--- core.opsThu Sep 5 06:43:27 2002
+++ /home/lt/src/parrot-leo/core.opsThu Sep 5 09:26:20 2002
@@ -485,13 +485,13 @@
=item B(out NUM, in STR)
-=item B(out PMC, in INT)
+=item B(inout PMC, in INT)
-=item B(out PMC, in NUM)
+=item B(inout PMC, in NUM)
=item B(out PMC, in PMC)
-=item B(out PMC, in STR)
+=item B(inout PMC, in STR)
=item B(out STR, in INT)
@@ -570,17 +570,17 @@
goto NEXT();
}
-inline op set(out PMC, in INT) {
+inline op set(inout PMC, in INT) {
$1->vtable->set_integer_native(interpreter, $1, $2);
goto NEXT();
}
-inline op set(out PMC, in NUM) {
+inline op set(inout PMC, in NUM) {
$1->vtable->set_number_native(interpreter, $1, $2);
goto NEXT();
}
-inline op set(out PMC, in STR) {
+inline op set(inout PMC, in STR) {
$1->vtable->set_string_native(interpreter, $1, $2);
goto NEXT();
}
@@ -594,32 +594,32 @@
=head2 PMC assignment operations: Px = x
-=item B(out PMC, in INT)
+=item B(inout PMC, in INT)
-=item B(out PMC, in NUM)
+=item B(inout PMC, in NUM)
-=item B(out PMC, in PMC)
+=item B(inout PMC, in PMC)
-=item B(out PMC, in STR)
+=item B(inout PMC, in STR)
=cut
-inline op assign(out PMC, in PMC) {
+inline op assign(inout PMC, in PMC) {
$1->vtable->set_pmc(interpreter, $1, $2);
goto NEXT();
}
-inline op assign(out PMC, in INT) {
+inline op assign(inout PMC, in INT) {
$1->vtable->set_integer_native(interpreter, $1, $2);
goto NEXT();
}
-inline op assign(out PMC, in NUM) {
+inline op assign(inout PMC, in NUM) {
$1->vtable->set_number_native(interpreter, $1, $2);
goto NEXT();
}
-inline op assign(out PMC, in STR) {
+inline op assign(inout PMC, in STR) {
$1->vtable->set_string_native(interpreter, $1, $2);
goto NEXT();
}
@@ -628,41 +628,41 @@
=head2 Keyed set operations: Px[ INTKEY ] = Bx
-=item B(out PMC, in INTKEY, in INT)
+=item B(inout PMC, in INTKEY, in INT)
-=item B(out PMC, in INTKEY, in NUM)
+=item B(inout PMC, in INTKEY, in NUM)
-=item B(out PMC, in INTKEY, in STR)
+=item B(inout PMC, in INTKEY, in STR)
-=item B(out PMC, in INTKEY, in PMC)
+=item B(inout PMC, in INTKEY, in PMC)
=cut
-inline op set (out PMC, in INTKEY, in INT) {
+inline op set (inout PMC, in INTKEY, in INT) {
INTVAL key = $2;
$1->vtable->set_integer_keyed_int(interpreter, $1, &key, $3);
goto NEXT();
}
-inline op set (out PMC, in INTKEY, in NUM) {
+inline op set (inout PMC, in INTKEY, in NUM) {
INTVAL key = $2;
$1->vtable->set_number_keyed_int(interpreter, $1, &key, $3);
goto NEXT();
}
-inline op set (out PMC, in INTKEY, in STR) {
+inline op set (inout PMC, in INTKEY, in STR) {
INTVAL key = $2;
$1->vtable->set_string_keyed_int(interpreter, $1, &key, $3);
goto NEXT();
}
-inline op set (out PMC, in INTKEY, in PMC) {
+inline op set (inout PMC, in INTKEY, in PMC) {
INTVAL key = $2;
$1->vtable->set_pmc_keyed_int(interpreter, $1, &key, $3, NULL);
goto NEXT();
}
-=head2 Keyed set operations: Ax = Px[ INTKEY ]
+=head2 Keyed get operations: Ax = Px[ INTKEY ]
=cut
@@ -672,7 +672,7 @@
=item B(out STR, in PMC, in INTKEY)
-=item B(out PMC, in PMC, in INTKEY)
+=item B(inout PMC, in PMC, in INTKEY)
=cut
@@ -694,7 +694,7 @@
goto NEXT();
}
-inline op set (out PMC, in PMC, in INTKEY) {
+inline op set (inout PMC, in PMC, in INTKEY) {
INTVAL key = $3;
$1 = $2->vtable->get_pmc_keyed_int(interpreter, $2, &key);
goto NEXT();
@@ -703,37 +703,37 @@
=head2 Keyed set operations: Px[ KEY ] = Bx
-=item B(out PMC, in KEY, in INT)
+=item B(inout PMC, in KEY, in INT)
Re: [perl #17026] [PATCH] core.ops including #16838
At 8:04 AM + 9/5/02, Leopold Toetsch (via RT) wrote:
>core.ops has currently:
>
>- obvious errors e.g.
> -inline op mul (out PMC, out PMC, out PMC) {
>
>- wrong docu and minor typos e.g.
> -=item B(in PMC, in STR)
>
>- and finally (as discussed in perl6-internals, "core ops ARGDIR"),
>wrong ARGDIRs for PMCs:
We need to nail down what the directions mean. The IMCC and JIT folks
are the ones that care here. I've been working on the assumption that
an out means that the register in question may change value, so it's
not appropriate on, say, add P1, P2, P3, since the destination
*register* doesn't change, just the value of the PMC in the register.
This is different than, say, add I1, I2, I3 where the value in the
destination register does change.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Parrot long-term goals/prospects
I really hadn't planned on going into this now, but the issue's been raised enough that it can't be left to later. Here's the current set of long-term goals for Parrot: 1) We *will* run Perl 6, Perl 5, Ruby, Python, JVM bytecode, and .NET bytecode. Not necessarily in that order 2) [EMAIL PROTECTED] list at some point transitions to being for perl 6 development 3) Parrot development moves to [EMAIL PROTECTED] 4) The *only* tools you will need to build parrot are a C compiler environment and either a make tool or a shell 5) Build environment bits may be in any language that the current maintainer is comfortable with as long as the language they're written in is available at the point in the build they are needed 6) Perl 6 is hosted on Parrot, and Larry gets no more special treatment than any other language designer of a language hosted on parrot does. 7) POD will remain our documentation format, unless/until someone comes up with something equally easy to read and write without any tools. We can mutate it to our needs, and if so we'll give it a new name. 8) Forth and Scheme may well be maintained specifically for whiny language bigots 9) The perl-specific bits of Parrot will get isolated into a perl directory and treated as add-ons What does this mean? Well, here are the footnotes. #1: means that we're looking to be multi-language. Really. #2 & #3 will make things tricky for google, history, and whatnot. We can deal. #4: The current reliance on Perl will remain until parrot's sufficiently self-hosted that we don't need an external perl environment. We will *not* add any other add-ons, though we may be forced by ICU to add C++ to the list. #5: It's perfectly acceptable to ship bytecode-compiled programs the build uses that are generated from languages that aren't yet built. (So part of the build could be done with bytecode programs generated from, say, Ruby or Python, that Parrot executes even if Ruby or Python hasn't been built yet. Or at all, if it's a minimal Parrot build) #6: This doesn't mean Larry's privs are restricted. Far from it. It means that other people can ask for the same sort of stuff, assuming Parrot is well and truly a primary target. This includes Guido, Matz, or anyone with their own custom language. (We reserve the right to tell everyone "no" on core engine changes however) #7: There's nothing fundamentally wrong with POD. It's simple and easy and, while limited, requires little effort to write. (The first person #8: No, not for whiny Forth and Scheme bigots. For whiny language bigots of other languages. Start spouting off about how X is clearly the superior language and we'll only accept patches from you in Forth. Unless X is Forth for you, in which case we'll only take Scheme patches. #9: It's likely that miniperl will be a required build component for quite a while, though I'd prefer to not have it so. The core parrot engine will *not* require perl being built, though some of the default behaviour may be perlish for quite a while. No other language is required to accept the core behavior, though. The time to implement these, however, is *NOT* *NOW*. The benefit for tossing over perl for something else (or nothing else, and maintain some sort of aloof independence) is non-existant. When the engine is fully specified and built then things may (almost undoubtedly will) change. Talk of, or actions towards, independence when we don't even have objects spec'd out is pretty stupid, though. So, there you have it. The plans for World Domination. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot long-term goals/prospects
On Thu, Sep 05, 2002 at 07:03:00AM -0400, Dan Sugalski wrote: > 4) The *only* tools you will need to build parrot are a C compiler > environment and either a make tool or a shell I believe we may be able to get away without a make tool or a shell. It won't be pretty, but I see no reason why we can't automatically generate the default order of building things from source code scratch into a C program, which manually ask the user 1: build this C program from this single self contained C source file 2: run it, with the current directory being the parrot source directory and it bootstraps the rest. No use to anyone developing the parrot source code and wanting dependency checking, but that's not the intent of this. It's to get a parrot bytecode interpreter up to the point that it can run a make-like system supplied as parrot bytecode. Doesn't matter if it then needs to rebuild most things. (Everything else in Dan's message, which I read quickly, I agree with, at least in overview) Nicholas Clark
Re: [netlabs #801] [PATCH] PerlArray in scalar context
Brent Dax wrote: > Keep in mind how much it could inflate the bytecode if > we render a ton of generic, N-dimensional hyper-operator logic into > bytecode. The main problem I see is that you could spend minutes executing inside that hyper op. Doesn't that screw with the plan for putting the event handler in the dispatch loop? It's not very friendly for debugging either -- how can the user set a breakpoint on one of the hyped calls? The bytecode generated for hyper can't be any larger than the equivalent loops in Perl 5. If there isn't any problem with byte code size now, why would there be a problem in Perl 6? - Ken
Re: [perl #17026] [PATCH] core.ops including #16838
On Thu, Sep 05, 2002 at 04:38:37AM -0400, Dan Sugalski wrote:
> At 8:04 AM + 9/5/02, Leopold Toetsch (via RT) wrote:
> >core.ops has currently:
> >
> >- obvious errors e.g.
> > -inline op mul (out PMC, out PMC, out PMC) {
> >
> >- wrong docu and minor typos e.g.
> > -=item B(in PMC, in STR)
> >
> >- and finally (as discussed in perl6-internals, "core ops ARGDIR"),
> >wrong ARGDIRs for PMCs:
>
> We need to nail down what the directions mean. The IMCC and JIT folks
> are the ones that care here. I've been working on the assumption that
> an out means that the register in question may change value, so it's
> not appropriate on, say, add P1, P2, P3, since the destination
> *register* doesn't change, just the value of the PMC in the register.
> This is different than, say, add I1, I2, I3 where the value in the
> destination register does change.
That makes it sound like we have (at least) 2 directions of out. We seem
to have
in the register is read,
(and the value pointed to by the register is read)
out1the register is written to
out2the value pointed to by the register is written to, but the register
itself is unchanged
and both are useful, but for different parts of optimisation. I suspect
(but I don't know about imcc, and I've not thought about it) that out2 is
useful for optimising how many PMCs you actually need to use as temporaries
in the first place, and out1 is useful for optimising how you map
temporaries to real parrot registers. But I'm guessing, and for JIT
purposes I think only need to know about out1.
Nicholas Clark
Re: Parrot long-term goals/prospects
On Thu, Sep 05, 2002 at 12:12:52PM +0100, Nicholas Clark wrote: > On Thu, Sep 05, 2002 at 07:03:00AM -0400, Dan Sugalski wrote: > > 4) The *only* tools you will need to build parrot are a C compiler > > environment and either a make tool or a shell > > I believe we may be able to get away without a make tool or a shell. > > It won't be pretty, but I see no reason why we can't automatically > generate the default order of building things from source code scratch into > a C program, which manually ask the user > > 1: build this C program from this single self contained C source file > 2: run it, with the current directory being the parrot source directory The way I'd do it is to have a make-like utility (possibly written in Perl), that has two modes of action. First it can act as a traditional make, and would be used by developers during the frequent compilation cycles. Second, it has the ability to produce an output script based on the dependency tree, in one of several formats, eg UNIX shell, whatever VMS uses, DOS batch (?!?) etc. This script would be a simple unconditional build everything script, just listing all the comands that the make would have executed anyway. So for example in the UNIX setup it might output a shell script looking like #!/bin/sh . config.sh . policy.sh $CC -$CCFLAGS -o foo.o foo.c $CC -$CCFLAGS -o bar.o bar.c Then the output scripts can be bundled with with the src code, so the initial build can be done without having Perl (or whatever) around. This may also be useful for initial porting to new machines. But I haven't thought this through much, and its probably Not Nearly As Simple As I Think. No doubt Andy or Brent will put me right :-) Dave. -- "But Sidley Park is already a picture, and a most amiable picture too. The slopes are green and gentle. The trees are companionably grouped at intervals that show them to advantage. The rill is a serpentine ribbon unwound from the lake peaceably contained by meadows on which the right amount of sheep are tastefully arranged." Lady Croom - Arcadia
Re: [perl #17026] [PATCH] core.ops including #16838
Dan Sugalski (via RT) wrote: > We need to nail down what the directions mean. This is, what I'm trying to do since quite a time. > ... The IMCC and JIT folks > are the ones that care here. Here is the IMCC folks speaking ;-) >... I've been working on the assumption that > an out means that the register in question may change value, so it's > not appropriate on, say, add P1, P2, P3, since the destination > *register* doesn't change, just the value of the PMC in the register. This is what I did say in my first attempt to clarify this, my proposal then was, to make them all »in«. Then Angel Faus answered, that »inout« would be more appropriate, because something in this PMC is modified. This is ok for me, because »inout« is for the life cycle of a register the same as »in«, so I treat »inout« as »in«. With my patch we would have in ... I,S,N,P unchanged inout..I,S,N new value, P unchanged, but some change inside out... I,S,N,P new value ... which is ok, as long as we don't have an op like: make_me_an_arr(inout PerlHash) which would make a different PMC out of it's argument (I mean not by changing the vtable, but return a new PMC) Actually a »in« argument is always ok, because it means for IMCC, this register is alive. A »out« means, for the register allocator, we have a new value, so don't care about the old value, this can be assigned the same "physical" parrot register. So too much »in« ARGDIRS just provoke a worse register allocation and maybe spilling. leo
Re: [perl #17026] [PATCH] core.ops including #16838
At 1:28 PM +0200 9/5/02, Leopold Toetsch wrote: >Dan Sugalski (via RT) wrote: > >We need to nail down what the directions mean. > > >This is, what I'm trying to do since quite a time. > >... The IMCC and JIT folks are the ones that care here. > >Here is the IMCC folks speaking ;-) Sorry. I've been pathetically behind in my p6i mail lately. If in means no change, inout means register is the same but the string/pmc may have mutated itself, and out means the register is changed, then I'm cool with it. Go ahead and commit the patch. Do be aware that *reading* from a PMC can potentially alter it, so: add inout P1, in P2, in P3 isn't necessarily a safe thing to assume. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #17026] [PATCH] core.ops including #16838
On Thu, Sep 05, 2002 at 08:15:28AM -0400, Dan Sugalski wrote: > At 1:28 PM +0200 9/5/02, Leopold Toetsch wrote: > >Dan Sugalski (via RT) wrote: > > > >We need to nail down what the directions mean. > > > > > >This is, what I'm trying to do since quite a time. > > > >... The IMCC and JIT folks are the ones that care here. > > > >Here is the IMCC folks speaking ;-) > > Sorry. I've been pathetically behind in my p6i mail lately. > > If in means no change, inout means register is the same but the > string/pmc may have mutated itself, and out means the register is > changed, then I'm cool with it. Go ahead and commit the patch. I believe applying the patch is the right thing, because it's progress on where we are, but I think (not fully formed yet) that we would benefit from finer granularity on what can get modified > Do be aware that *reading* from a PMC can potentially alter it, so: > >add inout P1, in P2, in P3 > > isn't necessarily a safe thing to assume. This is the "does a 'const' method mean that the memory representation of an object does not change, or only that the publicly accessible representation is unchanged" question, isn't it? [IIRC the question at one time was whether a const method in C++ could change the underlying object, providing the values returned by all public methods would not change as a result] The upshot of my thoughts is that I believe that the ops would benefit from having out (if not in as well) being broken down into (at least) 1: the value in the register did/didn't change 2: the value of the thing referenced by the register did/didn't change (possibly 2a and 2b being that the internals of the object didn't/might've changed) So then JITs, imcc and other things would know the difference between what these two do add inout_val P1, in P2, in P3 set out_reg P1, in P2 Nicholas Clark
Re: Parrot: maximizing the audience
On Wed, Sep 04, 2002 at 10:27:42PM -0400, Melvin Smith wrote: >This is no surprise. Parrot documentation will be lacking until >things settle down. Actually it's not so much the documentation. I didn't complain about 0.0.7 and 0.0.8 requiring changes to parrot-gen.py, because that's simply to be expected at this point. More documentation would be nice, of course, but it's not the major stumbling block. >Faster execution times would be on the top of my list. >I'm speaking for Perl, not Python, but last time I checked, neither >language was spectacular in this category. I can't remember the last time I found a Python program too slow for my purposes; Moore's Law is doing a fine job there. Better performance is not that exciting to me. >Eek, Scheme would do little for Parrot's acceptance in the >commercial world, and we all know its the commercial world >that provides most of the fuel to the fire. Seeing a "real" Perl, Python, >Java or C# running on Parrot would be my preference. Getting something -- anything -- running is what I'm suggesting; commercial acceptance is irrelevant for that purpose. I suggested Scheme because the syntax is easy to parse, the language is already specified in detail, and getting continuations working would exercise a complex part of Parrot's design. Perl6 can be ruled out because its design isn't finished yet; I assume Perl5 is difficult, and it will require extra work in implementing regexes, which aren't needed for most other languages. Like Perl5, implementing Ruby would also entail implementing regexes. Python might not be too difficult if imcc is used and the necessary PMCs get written, but I'm not moving very quickly on that. I hadn't thought of C#/Java, but they're not really Parrot's target languages, being static as opposed to dynamic. With one full language implementation, you can take real programs off the net and benchmark them, or take real libraries (a rule engine in Scheme, say) and try calling them from proto-Perl code to see how well cross-language works in practice. It provides an actual target to poke at. --amk (www.amk.ca) Destiny? Isn't that just a fancy name for blind chance? -- Peri, in "Mindwarp"
RE: [netlabs #801] [PATCH] PerlArray in scalar context
On Wed, 4 Sep 2002 22:51:53 -0700 (PDT), Sean O'Rourke wrote: > On Wed, 4 Sep 2002, Brent Dax wrote: > > Sean O'Rourke: > > # On Wed, 4 Sep 2002, Brent Dax wrote: > > # > What if (say) @b is a two-dimensional array? > > # > > # Then you get "interesting values of undef" :). Seriously, I > > # suspect one of the following: > > # > > # 1 - runtime error > > # 2 - each row (or column) of @b numified to its length > > # 3 - the first element of each row/col of @b > > # 4 - the other arrays boosted to the highest dimension > > # > > # I like #2, because it is easy and keeps hyper-operation > > # simple. If those aren't just numeric operators, but some > > > > It's already been defined to be #4. Where? I just re-skimmed A3 and E3, but didn't find that. All A3 says is that scalars get promoted to arrays, which makes sense. Going any further doesn't necessarily DWIM. > Argh. Then I need to whinge a bit -- what if it's a ragged array? What > if different elements have different dimensions themselves, e.g. > "[1,[2,3]]"? I think there's serious can-of-worms potential here, and by > making hyping more "intelligent", we'll actually make it useful in fewer > cases. I defintely agree. Wouldn't it be simpler to just ignore the extra-dimensionality? Especially when it's a user defined operator; it could actually want one scalar and one array operand. Maybe we should have multiple carets to denote hyper-hyper-operators if that's what the user wants: @a = @b ^^* @c; If hyperoperators get transformed into loops behind the scenes, this shouldn't be too hard to implement. -- Peter Haworth [EMAIL PROTECTED] Override self destruct? (y/n@^%i@&$# NO CARRIER
Re: [perl #17026] [PATCH] core.ops including #16838
In message <[EMAIL PROTECTED]> Nicholas Clark <[EMAIL PROTECTED]> wrote: > [IIRC the question at one time was whether a const method in C++ could > change the underlying object, providing the values returned by all public > methods would not change as a result] The answer to which is of course that a const method can change any mutable members of the object ;-) Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu
Re: [perl #17026] [PATCH] core.ops including #16838
At 1:40 PM +0100 9/5/02, Nicholas Clark wrote: >I believe applying the patch is the right thing, because it's progress >on where we are, but I think (not fully formed yet) that we would benefit >from finer granularity on what can get modified Point. OK, put 'em in. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #17030] [PATCH] Implementation of Lists for languages/scheme
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #17030]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17030 >
Hello,
The recent discussion of languages independence rememberd me of an
very old patch of mine which implements scheme pairs. (January 2002).
The languages/scheme directory did not change very much since then,
but the key system totally changed since then.
But neverless, I got it running. The dedicate SchemePair PMC is not
necessary any more, I just used an Array of size 2.
scheme now can create pairs with (cons) and lists with (list), print
them using (write) and access its elements using
(car), (cdr), (set-car!) and (set-cdr!). See lists.t for examples.
BTW: The MANIFEST-patch contains some auxillary files also missing,
which I delibrately haven't edited out. HINT: [perl #16839]
bye
juergen
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/36614/29555/b23eff/scheme.diff
Index: MANIFEST
===
RCS file: /cvs/public/parrot/MANIFEST,v
retrieving revision 1.207
diff -u -r1.207 MANIFEST
--- MANIFEST 4 Sep 2002 03:48:26 - 1.207
+++ MANIFEST 4 Sep 2002 23:53:27 -
@@ -58,6 +58,8 @@
config/gen/config_h/config_h.in
config/gen/config_pm.pl
config/gen/config_pm/Config_pm.in
+config/gen/libparrot_def.pl
+config/gen/libparrot_def/libparrot_def.in
config/gen/makefiles.pl
config/gen/makefiles/classes.in
config/gen/makefiles/docs.in
@@ -67,6 +69,7 @@
config/gen/makefiles/perl6.in
config/gen/makefiles/root.in
config/gen/makefiles/scheme.in
+config/gen/makefiles/imcc.in
config/gen/myconfig.pl
config/gen/myconfig/myconfig.in
config/gen/platform.pl
@@ -378,6 +381,7 @@
languages/perl6/examples/mandel.p6
languages/perl6/examples/qsort.p6
languages/perl6/mkdistro.sh
+languages/perl6/overview.pod
languages/perl6/pconfig.pl
languages/perl6/perl6
languages/perl6/perl6re/Perl6RE.bnf
@@ -434,6 +438,7 @@
languages/perl6/t/parser/speed_3.exp
languages/perl6/t/parser/speed_3.pl
languages/perl6/t/rx/basic.t
+languages/perl6/t/rx/call.t
languages/perl6/t/rx/special.t
languages/python/python.bnf
languages/python/python.prd
@@ -487,6 +492,7 @@
languages/ruby/t/01_terminal.t
languages/ruby/t/02_expression.t
languages/scheme/Scheme.pm
+languages/scheme/Scheme/Builtins.pm
languages/scheme/Scheme/Generator.pm
languages/scheme/Scheme/Parser.pm
languages/scheme/Scheme/Test.pm
@@ -498,6 +504,7 @@
languages/scheme/t/harness
languages/scheme/t/io/basic.t
languages/scheme/t/logic/basic.t
+languages/scheme/t/logic/lists.t
lib/Class/Struct.pm
lib/Make.pm
lib/Parrot/BuildUtil.pm
Index: languages/scheme/Scheme/Builtins.pm
===
RCS file: languages/scheme/Scheme/Builtins.pm
diff -N languages/scheme/Scheme/Builtins.pm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ languages/scheme/Scheme/Builtins.pm 4 Sep 2002 23:53:28 -
@@ -0,0 +1,50 @@
+package Scheme::Builtins;
+
+use strict;
+
+my %built_ins =
+(
+ write =>
+ [['# Write function', ''],
+ ['write_ENTRY', 'save', 'I0'],
+ ['', 'typeof', 'I0', 'P5'],
+ ['', 'ne', 'I0', '.PerlUndef', 'write_N_UNDEF'],
+ ['', 'print', '"()"'],
+ ['', 'branch', 'write_RET0'],
+ ['write_N_UNDEF','eq', 'I0', '.Array', 'write_ARRAY'],
+ ['', 'print', 'P5'],
+ ['', 'branch', 'write_RET0'],
+ ['write_ARRAY', 'save', 'P5'],
+ ['', 'save', 'P6'],
+ ['', 'print', '"("'],
+ ['write_NEXT', 'set', 'P6', 'P5'],
+ ['', 'set', 'P5', 'P6[0]'],
+ ['', 'bsr', 'write_ENTRY'],
+ ['', 'set', 'P5', 'P6[1]'],
+ ['', 'typeof', 'I0', 'P5'],
+ ['', 'eq', 'I0', '.PerlUndef', 'write_KET'],
+ ['', 'ne', 'I0', '.Array', 'write_DOT'],
+ ['', 'print', '" "'],
+ ['', 'branch', 'write_NEXT'],
+ ['write_DOT','print', '" . "'],
+ ['', 'bsr', 'write_ENTRY'],
+ ['write_KET','print', '")"'],
+ ['', 'restore', 'P6'],
+ ['', 'restore', 'P5'],
+ ['write_RET0', 'restore', 'I0'],
+ ['', 'ret'],
+ ]
+);
+
+sub generate {
+ my ($self, $name) = @_;
+
+ die "$name: Unknown buildin\n" unless exists $built_ins{$name};
+
+ for (@{$built_ins{$name}}) {
+my ($label, $op, @args) = @$_;
+$self->_add_inst ($label, $op, [ @args ]);
+ }
+}
+
+1;
Index: languages/scheme/Scheme/Generator.pm
===
RCS file: /cvs/public/parrot/languages/scheme/Scheme/Generator.pm,v
retrieving revision 1.2
diff -u -r1.2 Generator.pm
--- languages/scheme/Scheme/Generator.pm 24 Mar 2002 23:42:38 - 1.2
+++ languages/scheme/Scheme/Generator.pm 4 Sep 2002 23:53:29 -
@@ -2,6 +2,7 @@
use strict;
use Dat
Re: [perl #17026] [PATCH] core.ops including #16838
Nicholas Clark (via RT) wrote: > On Thu, Sep 05, 2002 at 04:38:37AM -0400, Dan Sugalski wrote: [ inout ] > That makes it sound like we have (at least) 2 directions of out. We seem > to have > > in the register is read, > (and the value pointed to by the register is read) > out1 the register is written to > out2the value pointed to by the register is written to, but the register > itself is unchanged > and both are useful, but for different parts of optimisation. I suspect > (but I don't know about imcc, and I've not thought about it) that out2 is > useful for optimising how many PMCs you actually need to use as temporaries > in the first place, and out1 is useful for optimising how you map > temporaries to real parrot registers. But I'm guessing, and for JIT > purposes I think only need to know about out1. out2 is currently of no deeper meaning. P6C takes just the next virtual register, which is fine, it's makes code more readable. out2 might be useful for future optimizers, e.g. can I drop this instruction because it has no effect - no -, but I can drop "out1" _if_ it's the last instruction in a life cylce of a register. out1 is exactly what matters, and yes, this is for register allocation. > Nicholas Clark
Re: [perl #17030] [PATCH] Implementation of Lists forlanguages/scheme
At 1:58 PM + 9/5/02, "Jürgen" "Bömmels" (via RT) wrote: >The recent discussion of languages independence rememberd me of an >very old patch of mine which implements scheme pairs. (January 2002). >The languages/scheme directory did not change very much since then, >but the key system totally changed since then. > >But neverless, I got it running. The dedicate SchemePair PMC is not >necessary any more, I just used an Array of size 2. > >scheme now can create pairs with (cons) and lists with (list), print >them using (write) and access its elements using >(car), (cdr), (set-car!) and (set-cdr!). See lists.t for examples. Cool, applied. How far from "real" scheme are we? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: [netlabs #801] [PATCH] PerlArray in scalar context
On Thu, 5 Sep 2002, Brent Dax wrote: > Sean O'Rourke: > # > # 4 - the other arrays boosted to the highest dimension > # > It's already been defined to be #4. > # > # Argh. Then I need to whinge a bit -- what if it's a ragged > # array? What if different elements have different dimensions > # themselves, e.g. "[1,[2,3]]"? I think there's serious > # can-of-worms potential here, and by making hyping more > # "intelligent", we'll actually make it useful in fewer cases. > > I don't see any cases where it becomes *less* useful by making it more > intelligent. Can you give an example? I was thinking of something like this: my (@xs, @ys) = two_arrays_of_arrays; my @zs = @as ^dot_product @bs; > As for the ragged array argument, I would argue for the following > statement in the documentation: > > The behavior of hyperoperators with ragged and recursive > data structures is undefined (and likely to be downright > weird). But we can do better than this if we (a) say that hyping only goes down one level by default; and (b) reduce hyping (without complaint) to a scalar operation when both operands are scalars. > Absolutely. If we know the dimensions at compile-time, we should use > that information. But I have a sneaking suspicion that that won't be > the general case. D'oh. I meant 'number of dimensions' rather than dimensions. Your statement above seems right if and only if hyping applies to all dimensions by default. > c) possibly speed up execution (optimizer good...) We already get some benefit here. For more, you're likely to implement a bona fide matrix or vector PMC, for which the normal operators will do "hyper" things. > # That would be pretty hard (I think), since it involves > # coalescing two subs into one, then cleaning out a bunch of > # temporaries. > > Perhaps. Looking for identical subs seems like an obvious size > optimization to me, but I'm not really a compiler guy. :^) You could be, any day you chose ;). At least as much as yours truly, /s
[perl #17032] [BUG] shared libs on solaris 6 without GNU
# New Ticket Created by "Sean O'Rourke" # Please include the string: [perl #17032] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=17032 > >From busunsl on perlmonks (http://perlmonks.org/index.pl?node_id=195334): The problem is: This is on Solaris 6, without GNU. The error is: ld: fatal: option -h and building a dynamic executable are incompatible ld: fatal: Flags processing errors make[2]: *** [blib/lib/libparrot.so] Error 1 make[2]: Leaving directory `/home/sybase/src/parrot-0.0.8' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/sybase/src/parrot-0.0.8/languages/imcc' make: *** [imcc] Error 2 The solution is (http://perlmonks.org/index.pl?node_id=195362) Changed the main Makefile from LD_SHARED= -shared to LD_SHARED= -G /s
Re: [perl #17026] [PATCH] core.ops including #16838
Applied (see also mailing list discussion). /s
Re: [perl #17032] [BUG] shared libs on solaris 6 without GNU
On Thu, 5 Sep 2002, Sean O'Rourke wrote: > Changed the main Makefile from > > LD_SHARED= -shared > to > > LD_SHARED= -G Mostly correct. config/init/data.pl is where the bad data is coming from. My patch to fix it is already entered into the database as perl #16937. (I also submitted the same patch previously; I think the id was 16818.) I'm simply waiting to see if my patch causes anyone problems. If not, I'll go ahead and commit it. -- Andy Dougherty [EMAIL PROTECTED]
[perl #17034] [PATCH] More MANIFEST and build clean-up
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #17034]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17034 >
Here are today's patches I needed to get parrot building. Again, I had to
guess about some of the MANIFEST changes. Those of you with commit
priveleges, *please* try to keep MANIFEST in sync.
The multiarray.pmc patch is, I hope, self-explanatory (use /**/ for
comments instead of //).
diff -r -u parrot-cvs/MANIFEST parrot-andy/MANIFEST
--- parrot-cvs/MANIFEST Thu Sep 5 09:32:55 2002
+++ parrot-andy/MANIFESTThu Sep 5 09:51:54 2002
@@ -58,11 +58,13 @@
config/gen/config_h/config_h.in
config/gen/config_pm.pl
config/gen/config_pm/Config_pm.in
+config/gen/libparrot_def.pl
+config/gen/libparrot_def/libparrot_def.in
config/gen/makefiles.pl
config/gen/makefiles/classes.in
config/gen/makefiles/docs.in
-config/gen/makefiles/jako.in
config/gen/makefiles/imcc.in
+config/gen/makefiles/jako.in
config/gen/makefiles/languages.in
config/gen/makefiles/miniperl.in
config/gen/makefiles/perl6.in
@@ -379,11 +381,14 @@
languages/perl6/examples/mandel.p6
languages/perl6/examples/qsort.p6
languages/perl6/mkdistro.sh
+languages/perl6/overview.pod
languages/perl6/pconfig.pl
languages/perl6/perl6
languages/perl6/perl6re/Perl6RE.bnf
languages/perl6/perl6re/Perl6RE.pm
languages/perl6/prd-perl6.pl
+languages/perl6/t/builtins/array.t
+languages/perl6/t/builtins/string.t
languages/perl6/t/compiler/1.t
languages/perl6/t/compiler/2.t
languages/perl6/t/compiler/3.t
@@ -394,7 +399,6 @@
languages/perl6/t/compiler/8.t
languages/perl6/t/compiler/9.t
languages/perl6/t/compiler/a.t
-#languages/perl6/t/compiler/builtins.t
languages/perl6/t/compiler/qsort.t
languages/perl6/t/harness
languages/perl6/t/parser/Makefile
@@ -435,6 +439,7 @@
languages/perl6/t/parser/speed_3.exp
languages/perl6/t/parser/speed_3.pl
languages/perl6/t/rx/basic.t
+languages/perl6/t/rx/call.t
languages/perl6/t/rx/special.t
languages/python/python.bnf
languages/python/python.prd
diff -r -u parrot-cvs/classes/multiarray.pmc parrot-andy/classes/multiarray.pmc
--- parrot-cvs/classes/multiarray.pmc Wed Sep 4 21:02:57 2002
+++ parrot-andy/classes/multiarray.pmc Thu Sep 5 10:17:54 2002
@@ -269,7 +269,7 @@
* it should work anyway. TODO: verify its validity
*/
- dead_val = buffer_ptr->virtual_addr; // save our begin value
+ dead_val = buffer_ptr->virtual_addr; /*save our begin value*/
while(buffer_ptr->virtual_addr != offs && (buffer_ptr != NULL)) {
/* my_val = (offs - (buffer_ptr->sparse_offset)); */
@@ -354,7 +354,7 @@
*/
} else {
- init_marray(INTERP, SELF, NULL); //no size
+ init_marray(INTERP, SELF, NULL); /*no size*/
}
}
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
[perl #17035] [PATCH] chr support
# New Ticket Created by Leon Brocard
# Please include the string: [perl #17035]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17035 >
I realise that proper Unicode support is coming, but it may be a while
to get here. We currently have ord() and it makes sense to have a
chr() as well, so that's what my patch provides. Please apply, thanks ;-)
Leon
--
Leon Brocard.http://www.astray.com/
scribot.http://www.scribot.com/
... I'm sure it's in the manual somewhere...
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/36636/29568/60614d/chr.patch
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.204
diff -u -r1.204 core.ops
--- core.ops5 Sep 2002 03:46:44 - 1.204
+++ core.ops5 Sep 2002 14:32:53 -
@@ -201,6 +201,22 @@
goto NEXT();
}
+=item B(out STR, in INT)
+
+Returns the character represented by the $2 number in the ASCII
+character set.
+
+=cut
+
+inline op chr (out STR, in INT) {
+ STRING *s;
+ s = string_make(interpreter, &$1, (UINTVAL)1, NULL, 0, NULL);
+ *(char *)s->bufstart = $2;
+ s->strlen = 1;
+ $1 = s;
+ goto NEXT();
+}
+
Index: t/op/string.t
===
RCS file: /cvs/public/parrot/t/op/string.t,v
retrieving revision 1.31
diff -u -r1.31 string.t
--- t/op/string.t 4 Sep 2002 13:49:55 - 1.31
+++ t/op/string.t 5 Sep 2002 14:32:53 -
@@ -1,6 +1,6 @@
#! perl -w
-use Parrot::Test tests => 91;
+use Parrot::Test tests => 94;
use Test::More;
output_is( <<'CODE', <
Re: [perl #17035] [PATCH] chr support
At 3:04 PM + 9/5/02, Leon Brocard (via RT) wrote: >I realise that proper Unicode support is coming, but it may be a while >to get here. We currently have ord() and it makes sense to have a >chr() as well, so that's what my patch provides. Please apply, thanks ;-) Done. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #17030] [PATCH] Implementation of Lists for languages/scheme
Dan Sugalski <[EMAIL PROTECTED]> writes: > At 1:58 PM + 9/5/02, "Jürgen" "Bömmels" (via RT) wrote: > >The recent discussion of languages independence rememberd me of an > >very old patch of mine which implements scheme pairs. (January 2002). > >The languages/scheme directory did not change very much since then, > >but the key system totally changed since then. > > > >But neverless, I got it running. The dedicate SchemePair PMC is not > >necessary any more, I just used an Array of size 2. > > > >scheme now can create pairs with (cons) and lists with (list), print > >them using (write) and access its elements using > >(car), (cdr), (set-car!) and (set-cdr!). See lists.t for examples. > > Cool, applied. How far from "real" scheme are we? I think its quite far. The first thing is symbols and strings. But how do I represent them at parrot-level. PerlString maybe, but then how will they be distinct from each other. Or just leave out strings for a while. Lexicals are also missing. I haven't looked closely to that. Without variables a language is not very useful. lambda-expression: this may compile just down to a sub.pmc Functions like map, apply, list?, etc. have to be implemented. Macros, tail-recursion, eval, and call/cc are also needed to call it "real". I hope the next patch will not need another half a year. juergen -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
interpolated strings
Thanks to Joseph Ryan, P6C does interploated strings now, meaning less underscore, which we can all agree is a Good Thing ;). /s
Re: [perl #17026] [PATCH] core.ops including #16838
Nicholas Clark wrote: > 1: the value in the register did/didn't change > 2: the value of the thing referenced by the register did/didn't change > > (possibly 2a and 2b being that the internals of the object didn't/might've > changed) Actually, thinking now of an optimizer, we should know these things. given the instruction: set P0, P1[1000] and this is the last instruction in the life cycle of P0, this instruction could be deleted. But when reading the array had the side effect of extending this array, it gives different results when you get the array size, depending on -Ox. > So then JITs, imcc and other things would know the difference between what > these two do > > add inout_val P1, in P2, in P3 > > set out_reg P1, in P2 Above are no problem, but here is another one, "out_reg" is not enough: set out_alias P1, in P2 new out_reg P1, inconst I0 The former is currently handled by propagate_alias() in imcc. The latter is a typical instruction, which ends the life cycle of an old P1 and starts a new one, so that the register allocator could and does reuse this very parrot register. > Nicholas Clark leo
Re: Parrot: maximizing the audience
On Wed, Sep 04, 2002 at 11:11:45PM -0400, John Porter wrote: > Thanks, Steve. I agree 100% with everything you said! > > Except: > > > ... the best way to that > > goal is to use Perl6 as the driver, at least until something else > > shows up, because that's the only way to derive realistic requirements > > for what needs to be accomplished. > > The incorrectness of that is directly proportional to the immaturity > of the language specification. And it goes without saying (heh) that > there are plenty of languages with more solid specs than Perl6. That's the "showing up" part. We've got smart people right now who care about getting Perl6 up and running on Parrot. Or at least, a person who's straining to become plural. :-) We have a handful of other languages that are more proof-of-concept or for other reasons are happy to just do as much as possible with the amount of Parrot that exists already. These are undeniably great things, but won't drive development. More languages would be better (perhaps Scheme will push on the Sub PMC and its three-headed relatives?), but at this very moment we only have one. Speaking of Sub/Coroutine/Continuation, right now we *really* need someone who pretends to understand this stuff to take a look at Jonathan Sillito's patches and do something with them. Or give him commit privs, or something.
Re: [perl #17008] [PATCH] automatic PMC integration
On Wed, Sep 04, 2002 at 08:48:29PM -0700, Sean O'Rourke wrote: > On Wed, 4 Sep 2002, Steve Fink wrote: > > I tend to create new PMC classes frequently, and they're a pain to > > maintain without committing, because you have to touch lots of files > > to add a PMC, and in ways that are sure to cause conflicts. > > Is one of these an intstack PMC, perchance? Nope. It used to be. Now it's an integer dequeue, only I'm afraid that if I called it that nobody would use it. :-) It will be going in Real Soon Now. (It's been finished and heavily tested for quite some time, but I've had to sneak in a bunch of precursor patches to prepare things for it.)
Re: [perl #17008] [PATCH] automatic PMC integration
Is there a reason you went for a deque instead of a stack? I can definitely see the need for a _PMC_ deque (unshift on the current PerlArray implementation blows), and for an integer _stack_ (regexes), but not for an int-only deque. I'm assuming you have a reason for this, which I have not yet discovered, and I'm curious what it is. /s On Thu, 5 Sep 2002, Steve Fink wrote: > On Wed, Sep 04, 2002 at 08:48:29PM -0700, Sean O'Rourke wrote: > > On Wed, 4 Sep 2002, Steve Fink wrote: > > > I tend to create new PMC classes frequently, and they're a pain to > > > maintain without committing, because you have to touch lots of files > > > to add a PMC, and in ways that are sure to cause conflicts. > > > > Is one of these an intstack PMC, perchance? > > Nope. It used to be. Now it's an integer dequeue, only I'm afraid that > if I called it that nobody would use it. :-) > > It will be going in Real Soon Now. (It's been finished and heavily > tested for quite some time, but I've had to sneak in a bunch of > precursor patches to prepare things for it.) >
Re: [Info] African Grey update
Steve Fink wrote: > Twice as fast seems like a good thing. Is this with the stackwalk > disabled? What prevents this from being applied to Parrot now? Yes, stackwalk is disabled, as it still isn't required yet. Enabling stackwalk takes 112 seconds, so the other differences in grey seem to have very little impact on performance. I believe the main reasons for non-applicability (per Dan) are: 1) Stackwalk is mandated. I am still waiting for code that requires stackwalk so I can test some ideas on this. 2) Buffer headers (and to a lesser extent PMCs) are larger. It would be interesting to include headers in the reported memory usage for parrot, as is now done in grey, so the impact of this can be seen. > Is there an easy way to see how many of those collection runs were > complete, or the total number of pages collected and the total number > that could have been collected, or some sort of statistic that > indicates how often the paged collections kick in? I'll take a look at this tomorrow. Thanks for your interest -- Peter Gibbs EmKel Systems
Re: [Info] African Grey update
BTW, I'm glad to see you still working on/maintaining the African Grey variation. I think it is important to maintain alternatives. Who knows, at some point in the future, it may be determined that this is the right way to go. If memory for embedded systems is the only issue, then I could definately see the sources merged and a configure option available to choose the right one. As for the stackwalk, well...you never know. Anyway, keep up the good work. Tanton - Original Message - From: "Peter Gibbs" <[EMAIL PROTECTED]> To: "Steve Fink" <[EMAIL PROTECTED]> Cc: "perl6-internals" <[EMAIL PROTECTED]> Sent: Thursday, September 05, 2002 1:57 PM Subject: Re: [Info] African Grey update > Steve Fink wrote: > > > Twice as fast seems like a good thing. Is this with the stackwalk > > disabled? What prevents this from being applied to Parrot now? > > Yes, stackwalk is disabled, as it still isn't required yet. Enabling > stackwalk takes 112 seconds, so the other differences in grey > seem to have very little impact on performance. > > I believe the main reasons for non-applicability (per Dan) are: > 1) Stackwalk is mandated. >I am still waiting for code that requires stackwalk so I can test >some ideas on this. > 2) Buffer headers (and to a lesser extent PMCs) are larger. >It would be interesting to include headers in the reported >memory usage for parrot, as is now done in grey, so the >impact of this can be seen. > > > Is there an easy way to see how many of those collection runs were > > complete, or the total number of pages collected and the total number > > that could have been collected, or some sort of statistic that > > indicates how often the paged collections kick in? > > I'll take a look at this tomorrow. > > Thanks for your interest > -- > Peter Gibbs > EmKel Systems > > > >
Missing Files
I just did a cvs update and tried to configure, but it said I was missing the following files: languages/scheme/Scheme/Builtins.pm languages/scheme/t/logic/lists.t Does anyone else have this problem? Tanton
RE: Parrot long-term goals/prospects
Nicholas Clark:
# On Thu, Sep 05, 2002 at 07:03:00AM -0400, Dan Sugalski wrote:
# > 4) The *only* tools you will need to build parrot are a C compiler
# > environment and either a make tool or a shell
#
# I believe we may be able to get away without a make tool or a shell.
The final build system has been speced out for a while. It involves
three components:
a) a bunch of platform-specific shell scripts (or whatever)
b) a miniparrot that can run with *very* minimal config info
c) a bunch of byte-compiled programs
Basically, you run your platform's shell script. I use the term "shell
script" loosely--on Win32 it'll be a batch file, and on VMS it'll be in
DCL. You get the idea.
Your platform's shell script drives the C compiler (which it may ask you
for path information on) to build miniparrot. Miniparrot can run more
or less with ANSI C only--no platform specific bits. The bytecode
swapper will have to do its tests at runtime.
Miniparrot's job is to ask the configuration questions or probe the
environment for them, generate any files that need to be generated
(config.h, has_header.h...), and drive the C compiler to build the final
Parrot. (I also have a neat idea that we probe for Perl 5 and copy
stuff from Config.pm if it's there (or any other language with a similar
repository of build information)).
So, building Parrot ought to look something like this (for a Windows
user):
c:\parrot> cd build
c:\parrot\build> win32
Are you using MS VC++? [yn] y
Miniparrot build complete.
Enter 'miniparrot build.pbc' to continue.
c:\parrot\build> miniparrot build.pbc
Parrot version 1.0 Build 1.0
Copyright (C) 2002 Yet Another Society
Hello, I'm Build. My job is to poke and prod your system to
figure out
how to build Parrot, then build it for you. The process is
mostly
automated--after the first couple questions, I can finish on my
own--unless you've passed the '--ask' command-line flag, in
which case
I'll ask you about pretty much everything.
Preparing my internal data structures...done.
Figuring out what kind of system I'm on...
Win32? This could be a bit tricky.
done.
Probing for C toolkit...
I've found VC++ and GCC.
Which of these toolkits should I use? [VC++]
OK, I'll use the Microsoft tools. Blech.
done.
Probing for languages with configuration info...
You have Perl 5! Sweet!
Should I take configuration info from it? [y]
OK, I'll use some info from Perl 5.
You have Python! Sweet!
Should I take configuration info from it? [y]
OK, I'll use some info from Python.
done.
Probing for data type sizes...done.
Okay, I've finished the configuration stuff. I will now start
building
Parrot for you.
Okay, Parrot is built. To test Parrot, type 'miniparrot
build.pbc test'
at a command prompt; to install it, type 'miniparrot build.pbc
install'.
c:\parrot\build>
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"In other words, it's the 'Blow up this Entire Planet and Possibly One
or Two Others We Noticed on our Way Out Here' operator."
--Damian Conway
Re: [perl #17008] [PATCH] automatic PMC integration
On Thu, Sep 05, 2002 at 10:33:50AM -0700, Sean O'Rourke wrote:
> Is there a reason you went for a deque instead of a stack? I can
> definitely see the need for a _PMC_ deque (unshift on the current
> PerlArray implementation blows), and for an integer _stack_ (regexes), but
> not for an int-only deque. I'm assuming you have a reason for this, which
> I have not yet discovered, and I'm curious what it is.
I refuse to discuss this until we can come to an agreement on the
number of u's and e's in deque/dequeue.
Actually, I have developed this clever regex algorithm where I use a
dequeue as if it were two stacks placed back-to-back that handles
dynamic rule replacement really well... just kidding. No, for regexes,
I just use the dequeue as a stack. The reason why I made it into a
dequeue was just to make it more palatable, because now it can be used
as a typed array ("my int @array" or whatever.) I like to avoid adding
anything that is completely regex-specific when possible, and adding
the shift/unshift functionality didn't slow down push/pop at all.
Re: Parrot: maximizing the audience
On Thu, 5 Sep 2002 10:27:05 -0700 Steve Fink <[EMAIL PROTECTED]> wrote: >Speaking of Sub/Coroutine/Continuation, right now we *really* need >someone who pretends to understand this stuff to take a look at >Jonathan Sillito's patches and do something with them. Or give him >commit privs, or something. Hey those are my three headed babies you are talking about! :) Sorry, I've been preoccupied and I must have missed Jonathan's patch. I will have a look. -Melvin
Re: Missing Files
On Thu, 5 Sep 2002, Tanton Gibbs wrote: > I just did a cvs update and tried to configure, but it said I was missing > the following files: > > languages/scheme/Scheme/Builtins.pm > languages/scheme/t/logic/lists.t > > Does anyone else have this problem? Yes. Aargh. And I had *just* fixed the MANIFEST file --again-- a few hours ago. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #17030] [PATCH] Implementation of Lists forlanguages/scheme
Juergen Boemmels <[EMAIL PROTECTED]> writes:
f> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>> At 1:58 PM + 9/5/02, "Jürgen" "Bömmels" (via RT) wrote:
>> >The recent discussion of languages independence rememberd me of an
>> >very old patch of mine which implements scheme pairs. (January 2002).
>> >The languages/scheme directory did not change very much since then,
>> >but the key system totally changed since then.
>> >
>> >But neverless, I got it running. The dedicate SchemePair PMC is not
>> >necessary any more, I just used an Array of size 2.
>> >
>> >scheme now can create pairs with (cons) and lists with (list), print
>> >them using (write) and access its elements using
>> >(car), (cdr), (set-car!) and (set-cdr!). See lists.t for examples.
>>
>> Cool, applied. How far from "real" scheme are we?
>
> I think its quite far.
> The first thing is symbols and strings. But how do I represent them at
> parrot-level. PerlString maybe, but then how will they be distinct
> from each other. Or just leave out strings for a while.
Symbol: [ '*symbol*', "symname" ]
Held in a Hash (hashed on the string name).
String: [ '*string*', "a string" ]
Which means Pairs become: [ '*pair*', , ]
(Or, more likely)
{ type => '*symbol*', value => 'symbol', (vtable => ...)? }
{ type => '*string*', value => 'a string' }
{ type => '*pair*', value => [ , ] }
{ type => '*int*', value => 1 }
{ type => '*rational*', value => 1/2 }
> Lexicals are also missing. I haven't looked closely to that. Without
> variables a language is not very useful.
{ type => '*environment*' value => {scratchpad => aScratchPadPMC}
> lambda-expression: this may compile just down to a sub.pmc
> Functions like map, apply, list?, etc. have to be implemented.
{ type => '*function*', value => {env => anEnvironment,
arglist => aListOfSymbols,
sequence => aListOfForms} }
{ type => '*compiled-function*', value => aSubPMC }
All these types should possibly also carry a pointer to either a jump
table or a hash of type methods so, for instance the default car
becomes (in perlish pseudocode)
sub car ($thing) { $thing.{vtable}{car}.($thing) }
For bonus points things should be arranged so that 'vtable{car}' can
be any of a scheme function, a sub.pmc or a custom op. For tail call
bonus points it should be possible to alter the current continuation
before calling (or just to make a tail call to it as appropriate...)
> Macros, tail-recursion, eval, and call/cc are also needed to call it
> "real".
Oh yes: continuation: { type => '*continuation*',
value => aContinuation.pmc }
The empty list: { type => '*the-empty-list*',
value => '*the-empty-list*' }
etc...
Implementation is a simple matter of coding. I've been reasonably
convinced since PerlHashes became ready for primetime that one could
implement a full blown, if not necessarily very *fast* version of
scheme whilst maintaining one's own environments, continuations and
all the other good stuff, but lack of tuits has tended to get in the
way of implementing it.
Things would almost certainly be easier with full blown PMCs handling
dispatch for the 'thing' that a '*function*' points at, but not
entirely necessary. Another option is to make first class PMCs of all
the various types, but I'm not sure how one would go about
implementing 'mixed' vtables, where some things are implemented in C,
others PBC and still others in one interpreted language or
another. One option for that would be to have a single 'SchemeObject',
which as well as having a vtable implemented in C would first do
dispatch through its 'scheme_vtable' hash. Continuations, Integers,
Rationals, and other things which map directly onto existing PMC types
(and which don't need extra methods) could then just use their normal
PMC.
Thoughts?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
[perl #17039] [PATCH] intarray aka integer dequeue PMC
# New Ticket Created by Steve Fink
# Please include the string: [perl #17039]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17039 >
Here is the new PMC I keep babbling about. Before I commit it, any
comments? Like, does anybody think this should be named differently?
It's really a dequeue (double-ended queue), meaning that push, pop,
shift, and unshift are all constant-time operations, but arbitrary
indexed lookup is theoretically linear-time. (It's linear in the
number of 256-element chunks, so in practice it's usually fast.)
It is implemented as a modification of rxstack.c. It is still a
circular, doubly-linked list of chunks containing a fairly large array
of integers, only now the first chunk can be partial as well as the
last, in order to efficiently support shift/unshift. The length is
cached in the first node. Also, these chunks are now Buffer
subclasses, so they are completely managed by GC (rxstack uses
mem_sys_allocate).
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/36692/29583/f4c51f/intarray.patch
Index: MANIFEST
===
RCS file: /cvs/public/parrot/MANIFEST,v
retrieving revision 1.212
diff -p -u -a -r1.212 MANIFEST
--- MANIFEST5 Sep 2002 17:56:58 - 1.212
+++ MANIFEST5 Sep 2002 19:17:21 -
@@ -23,6 +23,7 @@ classes/coroutine.pmc
classes/csub.pmc
classes/default.pmc
classes/genclass.pl
+classes/intarray.pmc
classes/intqueue.pmc
classes/key.pmc
classes/multiarray.pmc
@@ -206,6 +207,7 @@ include/parrot/exceptions.h
include/parrot/global_setup.h
include/parrot/hash.h
include/parrot/headers.h
+include/parrot/intarray.h
include/parrot/interp_guts.h
include/parrot/interpreter.h
include/parrot/io.h
@@ -235,6 +237,7 @@ include/parrot/sub.h
include/parrot/trace.h
include/parrot/unicode.h
include/parrot/warnings.h
+intarray.c
interpreter.c
io.ops
io/TODO
@@ -590,12 +593,14 @@ t/op/time.t
t/op/trans.t
t/pmc/array.t
t/pmc/boolean.t
+t/pmc/intarray.t
t/pmc/perlarray.t
t/pmc/perlhash.t
t/pmc/perlstring.t
t/pmc/pmc.t
t/pmc/sub.t
t/src/basic.t
+t/src/intarray.t
test_main.c
tools/dev/check_source_standards.pl
tools/dev/genrpt.pl
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.206
diff -p -u -a -r1.206 core.ops
--- core.ops5 Sep 2002 15:03:23 - 1.206
+++ core.ops5 Sep 2002 19:17:29 -
@@ -3428,6 +3428,146 @@ inline op restoreall() {
###
+=head2 Fast access ops
+
+The fast access ops are shortcuts to common operations implemented in PMCs.
+
+=over 4
+
+=cut
+
+
+
+=item B(in PMC, in INT)
+
+=item B(in PMC, in NUM)
+
+=item B(in PMC, in STR)
+
+=item B(in PMC, in PMC)
+
+Push $2 onto the end of the aggregate PMC $1, if that operation is defined.
+
+=cut
+
+inline op push (in PMC, in INT) {
+$1->vtable->push_integer(interpreter, $1, $2);
+goto NEXT();
+}
+
+inline op push (in PMC, in NUM) {
+$1->vtable->push_float(interpreter, $1, $2);
+goto NEXT();
+}
+
+inline op push (in PMC, in STR) {
+$1->vtable->push_string(interpreter, $1, $2);
+goto NEXT();
+}
+
+inline op push (in PMC, in PMC) {
+$1->vtable->push_pmc(interpreter, $1, $2);
+goto NEXT();
+}
+
+=item B(out INT, in PMC)
+
+=item B(out NUM, in PMC)
+
+=item B(out STR, in PMC)
+
+=item B(out PMC, in PMC)
+
+Pop off last entry in the aggregate $2, placing the result in $1.
+
+=cut
+
+inline op pop (out INT, in PMC) {
+$1 = $2->vtable->pop_integer(interpreter, $2);
+goto NEXT();
+}
+
+inline op pop (out NUM, in PMC) {
+$1 = $2->vtable->pop_float(interpreter, $2);
+goto NEXT();
+}
+
+inline op pop (out STR, in PMC) {
+$1 = $2->vtable->pop_string(interpreter, $2);
+goto NEXT();
+}
+
+inline op pop (out PMC, in PMC) {
+$1 = $2->vtable->pop_pmc(interpreter, $2);
+goto NEXT();
+}
+
+=item B(in PMC, in INT)
+
+=item B(in PMC, in NUM)
+
+=item B(in PMC, in STR)
+
+=item B(in PMC, in PMC)
+
+Unshift $2 onto the end of the aggregate PMC $1, if that operation is defined.
+
+=cut
+
+inline op unshift (in PMC, in INT) {
+$1->vtable->unshift_integer(interpreter, $1, $2);
+goto NEXT();
+}
+
+inline op unshift (in PMC, in NUM) {
+$1->vtable->unshift_float(interpreter, $1, $2);
+goto NEXT();
+}
+
+inline op unshift (in PMC, in STR) {
+$1->vtable->unshift_string(interpreter, $1, $2);
+goto NEXT();
+}
+
+inline op unshift (in PMC, in PMC) {
+$1->vtable->unshift_pmc(interpreter, $1, $2);
+goto NEXT();
+}
+
+=item B(out INT, in PMC)
+
+=item B(out NUM, in PMC)
+
+=item B(out STR, in PMC)
+
+=item B(out PMC, in PMC)
+
+Shift off last entry in the aggregate $2, placing the result in $1.
+
+=cut
+
+inline o
Re: Missing Files
At 3:28 PM -0400 9/5/02, Andy Dougherty wrote: >On Thu, 5 Sep 2002, Tanton Gibbs wrote: > >> I just did a cvs update and tried to configure, but it said I was missing >> the following files: >> >> languages/scheme/Scheme/Builtins.pm >> languages/scheme/t/logic/lists.t >> >> Does anyone else have this problem? > >Yes. Aargh. And I had *just* fixed the MANIFEST file --again-- a few >hours ago. My fault--I missed that they were added by the Scheme patch I put in. Fixed. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Teasing notes
Since I'm about to go heads-down, as a deadline jumped a week closer (to yesterday) *) I think we may have to have separate vtable operations for hyperoperators *) Calling conventions are changing *again*. Adding the type of the return value, and the calling frame *) We're switching from a tree-like stack to full activation frames. Since we're almost there as it is, this shouldn't be a big deal. And it'll make "chop to three entries" stack ops actually correct, as they'll be frame ops *) We'll be returning frames from subs too, potentially, which is a good solution to the problem of coroutines returning overflow on the stack, which they currently can't do right. *) I think I've finally given in, and vtables will be hierarchical for some of the less-used operations. Like the transcendental math ops, which I think we're going to need to have overloadable Sorry 'bout the brevity. I'll be back next week some time, depending on the perl 6 conference thingie. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #17026] [PATCH] core.ops including #16838
At 6:24 PM +0200 9/5/02, Leopold Toetsch wrote: >Nicholas Clark wrote: > >>1: the value in the register did/didn't change >>2: the value of the thing referenced by the register did/didn't change >> >>(possibly 2a and 2b being that the internals of the object didn't/might've >>changed) > > >Actually, thinking now of an optimizer, we should know these things. >given the instruction: > >set P0, P1[1000] > >and this is the last instruction in the life cycle of P0, this >instruction could be deleted. But when reading the array had the >side effect of extending this array, it gives different results when >you get the array size, depending on -Ox. The optimizer needs to be *really* careful with this sort of thing. Optimizing away reads and writes isn't safe in the general case, because code may be depending on the side effects. That's why hints in the AST/PIL are so important. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #17030] [PATCH] Implementation of Lists for languages/scheme
Piers Cawley wrote:
> Juergen Boemmels <[EMAIL PROTECTED]> writes:
> > But how do I represent them at parrot-level.
>
> { type => '*environment*' value => {scratchpad => aScratchPadPMC}
Etc.
The point being, we're building these things into parrot so that
HLLs can use them natively, rather than have to invent each their
own particular flavor of wheel.
--
John Douglas Porter
Re: [perl #17039] [PATCH] intarray aka integer dequeue PMC
Steve Fink wrote: > Here is the new PMC I keep babbling about. Before I commit it, any > comments? Like, does anybody think this should be named differently? > It's really a dequeue (double-ended queue), ... I for one think it ought to be called what it is - a dequeue. -- John Douglas Porter
Tinderbox turning green !
Ok, with the alignment hack now in (see resources.c) and lots of various and sundry portability fixes, it looks like we're on our way to turning the tinderbox a lovely shade of green. (The solaris failures are timeouts unrelated to parrot, and the other failures are due to MANIFEST hiccoughs and should be fixed next time the tinderboxes run.) Let's try to keep it this way! -- Andy Dougherty [EMAIL PROTECTED]
Re: Tinderbox turning green !
On Thu, 5 Sep 2002, Andy Dougherty wrote: > Ok, with the alignment hack now in (see resources.c) and lots of various > and sundry portability fixes, it looks like we're on our way to turning > the tinderbox a lovely shade of green. (The solaris failures are timeouts > unrelated to parrot, and the other failures are due to MANIFEST hiccoughs > and should be fixed next time the tinderboxes run.) Must be time for me to get exceptions added in... :) Dan
RE: Parrot long-term goals/prospects
On Fri, 2002-09-06 at 02:45, Brent Dax wrote: > So, building Parrot ought to look something like this (for a Windows > user): > > c:\parrot> cd build > c:\parrot\build> win32 > Are you using MS VC++? [yn] y > > Miniparrot build complete. > Enter 'miniparrot build.pbc' to continue Is there any reasons *not* to continue here? If someone only wants miniparrot, they should say 'win32 /miniparrot' or whatever. > c:\parrot\build> miniparrot build.pbc > > Parrot version 1.0 Build 1.0 > Copyright (C) 2002 Yet Another Society Ooh, optimism. > > Hello, I'm Build. My job is to poke and prod your system to > figure out > how to build Parrot, then build it for you. The process is > mostly > automated--after the first couple questions, I can finish on my > own--unless you've passed the '--ask' command-line flag, in > which case > I'll ask you about pretty much everything. > > Preparing my internal data structures...done. > Figuring out what kind of system I'm on... > Win32? This could be a bit tricky. > done. > Probing for C toolkit... > I've found VC++ and GCC. > Which of these toolkits should I use? [VC++] > OK, I'll use the Microsoft tools. Blech. > done. > Probing for languages with configuration info... > You have Perl 5! Sweet! > Should I take configuration info from it? [y] > OK, I'll use some info from Perl 5. > You have Python! Sweet! > Should I take configuration info from it? [y] > OK, I'll use some info from Python. > done. > Probing for data type sizes...done. > > Okay, I've finished the configuration stuff. I will now start > building > Parrot for you. > > Okay, Parrot is built. To test Parrot, type 'miniparrot > build.pbc test' Ohhh. and you were doing so well! :-) "You want I should test it out? [y]" > at a command prompt; to install it, type 'miniparrot build.pbc > install'. "Are you satisfied enough for me to install it now? Please? Pretty please? [y]" (Or, in the instance of [n]s, "Okay, you can always (test|install) it later by running $command.") Beyond that, I like this glimpse of the future. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Teasing notes
On Thu, 2002-09-05 at 16:20, Dan Sugalski wrote: > > *) I think we may have to have separate vtable operations for hyperoperators > *) I think I've finally given in, and vtables will be hierarchical Being vtable-ignorant in general: 1) How big is *too* big (for the regular vtable) 2) How big is *too* big (for the heirarchical vtable) 3) Ops that can't/won't fit are done as a sub call, right? -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Teasing notes
At 8:53 PM -0400 9/5/02, Bryan C. Warnock wrote: >On Thu, 2002-09-05 at 16:20, Dan Sugalski wrote: >> >> *) I think we may have to have separate vtable operations for hyperoperators > >> *) I think I've finally given in, and vtables will be hierarchical > >Being vtable-ignorant in general: > >1) How big is *too* big (for the regular vtable) Well, we're at 252 entries now. That's almost 1K per vtable. >2) How big is *too* big (for the heirarchical vtable) I'm not sure. I'm OK putting everything that's reasonably overloadable into the vtable, but I'm not sure how much, past potentially the math operators and hyperoperators, we have to add. >3) Ops that can't/won't fit are done as a sub call, right? Yep. Or at least the core has code to do the function--we may not actually call a method/sub/whatever at the parrot level. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[COMMIT] A couple of patches from last night...
And some more marked as committed that got missed... Most of the time I'm looking at http://www.parrotcode.org/openpatches/ in order to find out what needs to be committed. I'm so far just marking patches as 'Applied', not closing out the RT report. (NOte: I'm not claiming that I committed all of these... Most of them were simply committed but not marked in RT as applied... Patch #17007 - This needs to be tested on HP/UX, and unfortunately caused a temporary but caught problem on Cygwin. Patch #16992 - Committed. Patch #17035 - Committed but not marked as such. Patch #17034 - Committed but not marked as such. Patch #17030 - Committed but not marked as such. Patch #17025 - Committed. Patch #17009 - Committed. Patch #17002 - Committed but not marked as such. Patch #17000 - Committed. -- Jeff <[EMAIL PROTECTED]>
Re: [COMMIT] A couple of patches from last night...
And a couple others: #16962 -- (docs) applied #16938 -- (imcc) applied /s On Thu, 5 Sep 2002, Jeff wrote: > And some more marked as committed that got missed... > > Most of the time I'm looking at http://www.parrotcode.org/openpatches/ > in order to find out what needs to be committed. I'm so far just marking > patches as 'Applied', not closing out the RT report. > > (NOte: I'm not claiming that I committed all of these... Most of them > were simply committed but not marked in RT as applied... > > Patch #17007 - This needs to be tested on HP/UX, and unfortunately > caused a temporary but caught problem on Cygwin. > Patch #16992 - Committed. > Patch #17035 - Committed but not marked as such. > Patch #17034 - Committed but not marked as such. > Patch #17030 - Committed but not marked as such. > Patch #17025 - Committed. > Patch #17009 - Committed. > Patch #17002 - Committed but not marked as such. > Patch #17000 - Committed. > -- > Jeff <[EMAIL PROTECTED]> >
Re: [COMMIT] A couple of patches from last night...
I have applied at least one other not on your list (#17008). Should I be marking things as applied? I didn't think I had the permissions to do that, so I've just been trying to make sure I post a "Thanks, applied" so it gets into RT's reply set. Can I do more than that?
Re: [COMMIT] A couple of patches from last night...
Steve Fink wrote: > > I have applied at least one other not on your list (#17008). Should I > be marking things as applied? I didn't think I had the permissions to > do that, so I've just been trying to make sure I post a "Thanks, > applied" so it gets into RT's reply set. Can I do more than that? The list will keep growing as I clean the rest of this backlog out, and I've been pretty much going through these in a linear fashion. I'm trying to establish and keep up a practice of committing at least one patch per night, so things keep more up-to-date. And getting rid of the Warnock phenomenon. Basically trying to make sure I stay on track and keep getting my job done... -- Jeff <[EMAIL PROTECTED]>
Re: [COMMIT] A couple of patches from last night...
Jeff wrote: > > And some more marked as committed that got missed... > Patch #17000 - Ewps. It was recently pointed out to me that I accidentally reversed #17000. The problem has been fixed, I believe. Sorry, Andy. -- Jeff <[EMAIL PROTECTED]>
[PATCH] a couple fixes for mingw32
The first enclosed patch quashes "invalid pragma" warnings in platform.h, the second one makes another exception to imcc requiring (maybe imcc should come with a sysexits.h instead?) __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com --- config/gen/platform/win32.h.origTue Jul 23 00:25:36 2002 +++ config/gen/platform/win32.h Thu Sep 5 18:35:46 2002 @@ -14,6 +14,7 @@ #endif /* These disable certain Level 4 Warnings */ +#ifdef _MSC_VER #pragma warning( disable: 4100 ) /* disables 'unreferenced formal parameter' * warnings */ #pragma warning( disable: 4115 ) /* disables 'named type definition in @@ -21,6 +22,7 @@ * include files */ #pragma warning( disable: 4505 ) /* disables 'unreferenced local function has * been removed' warnings in header files */ +#endif /* ** Miscellaneous: */ --- languages/imcc/imc.h.orig Mon Aug 26 23:48:44 2002 +++ languages/imcc/imc.hThu Sep 5 18:57:56 2002 @@ -3,14 +3,14 @@ #include #include -#ifndef _MSC_VER -# include -#else +#if defined(_MSC_VER) || defined(__MINGW32__) # define EX_DATAERR 1 # define EX_SOFTWARE 1 # define EX_NOINPUT 1 # define EX_IOERR 1 # define EX_UNAVAILABLE 1 +#else +# include #endif #include "symreg.h"
Re: [perl #17039] [PATCH] intarray aka integer dequeue PMC
Steve Fink (via RT) wrote: > # New Ticket Created by Steve Fink > # Please include the string: [perl #17039] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=17039 > Why intarrary.pmc: > +=item B(in PMC, in PMC) ... > +=item B(in PMC, in INT) There are already very useful arrary operations, which are currently used in e.g. embed.c namely "push_string" and these don't have an opcode. perl6/P6C array flattening code would be cut down by ~2/3, when this opcode is implemented (push ..) I see a forthcoming pollution of core.ops namespace. And I can't imagine (now at 0.40pm ;), we need a third array class - but I didn't read the patch. One array base class doing it, ought to be enough. So why doesn't this fit in array.pmc, which PerlArray does reuse? Minor note: todays in/inout conclusion is currently :-) "inout". my 2 ¢ leo
Re: [perl #17039] [PATCH] intarray aka integer dequeue PMC
On Fri, Sep 06, 2002 at 12:47:11AM +0200, Leopold Toetsch wrote: > Steve Fink (via RT) wrote: > > ># New Ticket Created by Steve Fink > ># Please include the string: [perl #17039] > ># in the subject line of all future correspondence about this issue. > ># http://rt.perl.org/rt2/Ticket/Display.html?id=17039 > > > > Why intarrary.pmc: > > >+=item B(in PMC, in PMC) > > ... > > > >+=item B(in PMC, in INT) > > > There are already very useful arrary operations, which are currently > used in e.g. embed.c namely "push_string" and these don't have an opcode. Now they do. push(in PMC, in STR) calls exactly that vtable entry. > perl6/P6C array flattening code would be cut down by ~2/3, when this > opcode is implemented (push ..) And this patch implements them. Unless I'm misunderstanding what you're saying. > I see a forthcoming pollution of core.ops namespace. I think it is reasonable for all of the vtable entries to have their own opcodes. I think you may be misunderstanding something here -- those new push/pop/shift/unshift instructions in core.ops are in no way specific to the IntArray PMC. They work equally well for the current Array and PerlArray PMCs. push(PMC, STR) just calls $1->vtable->push_string(...). > And I can't imagine (now at 0.40pm ;), we need a third array class - but > I didn't read the patch. Speed and space. This is intended to replace the special-purpose intstack currently in the Interp struct. They both provide a fast, integer-only stack. intarray.c is just a modified version of rxstacks.c, but I don't think rxstacks.c does anything that intarray.c cannot do. But that's the underlying data structure. Your question was why we need another array class (PMC). Two reasons: 1. My regex implementation doesn't use anything specific to regexes in Parrot (i.e., no rx_* ops, no special-purpose data structure embedded in the interpreter struct, and no intstack_* instructions.). So to get a fast integer stack that I could have more than instance of per interpreter, I needed to make it a PMC. 2. Part of the Perl6 design was to allow space-efficient versions of some data structures. For example, you can declare an integer-only array. This is the PMC that would hold it. (Maybe. It's really a dequeue, so indexed lookup requires linear rather than constant time. But I bet it would be easier to modify intarray to support arbitrary sized chunks of arrays than it would to write a new integer-only linear array that supported fast shift/unshift.) > One array base class doing it, ought to be enough. So why doesn't this > fit in array.pmc, which PerlArray does reuse? It could extend array.pmc, except that at least right now there is nothing in array.pmc that it could usefully inherit. It has the same *interface* as array.pmc -- but the only programmatic interface that we've defined is the vtable, and that's the same for all PMCs. Or, in other words, the implementation of intarray.pmc is so different from the implementation of array.pmc that no useful _implementation_ inheritance exists. I guess I really ought to rename it IntDequeue, since it really is a different data structure than Array and PerlArray. It's just that "dequeue" is impossible to type. And I suspect Array/PerlArray will change to look more like intarray, when we realize we need to support fast shift/unshift. (As opposed to right now, when we don't support them at all!) How about IntList? Anyone have a problem with that name? > Minor note: todays in/inout conclusion is currently :-) "inout". So should it be push(inout PMC, in INT)? And pop(out INT, inout PMC)? Thanks for the comments.
Current Perl6 on MS Win32 status
Perl6 on Win32 MS VC++ gives: Failed TestStatus Wstat Total Fail Failed List of Failed -- t/compiler/8.t 1 256 61 16.67% 6 t/compiler/a.t 1 256 31 33.33% 2 t/rx/call.t1 256 21 50.00% 1 t/compiler/8NOK 6# got: 'Wrong type on top of stack! # ed 1 # 1 # 2 # a.1: 3 # b.1 # foo # ' # expected: '1 # 2 # a.1: 3 # b # 4 # 5 # Survived 1 # 1 # 2 # a.1: 3 # b.1 # foo # ' # Looks like you failed 1 tests of 6. This one is known, and is waiting on a BUFFER_external patch. Now that parrot works on win32 again, I'll try to clear out my patch queue. t/compiler/aok 1/3Couldn't find global label '__setup' at line 1. Couldn't find global label '_main' at line 3. Couldn't find operator 'bsr' on line 1. Couldn't find operator 'bsr' on line 3. # Failed test (t/compiler/a.t at line 51) t/compiler/aNOK 2# got: '' # expected: '1 # 1.1 # 2 # -- # 1.1 # 2.1 # -- # 1 # 1.1 # 2 # 2.1 # 3.1 # 4 # 4.1 # 5.1 # 6.1 # -- # 1 # 1.1 # 2.1 # 3.1 # 4 # 4.1 # 5.1 # ' This error was in imc->pasm, specifically: last token = [] (error) line 63: parse error Didn't create output asm. t/rx/call...NOK 1# got: 'ok 1 # ok 2 # ok 3 # ok 4 # ok 5 # ok 6 # ok 7 # ok 8 # ok 9 # ' # expected: 'ok 1 # ok 2 # ok 3 # ok 4 # ok 5 # ok 6 # ok 7 # ok 8 # ok 9 # ok 10 # ' No idea on where the missing "ok 10" went. If people would like the p6/imcc/pasm/pbc files, I can provide them. Just let me know. Mike Lambert
Re: [perl #16852] [PATCH] Eliminate empty extension
> > This patch trims off the period at the end of executable filenames for > > C-based tests on unix. (It compiled "t/src/basic_1.c" -> > > "t/src/basic_1."; this patch makes that "t/src/basic_1") > > This patch should also update languages/perl6/P6C/TestCompiler.pm, since > it hijacks lib/Parrot/Test.pm to get its functionality. I'll probably > apply this after the code opens up again, but if someone beats me to it, > please be sure to update the affected file above. Applied, thanks, Mike Lambert
