Re: require < 6.x
NeonEdge wrote on 2/21/01 4.07: ... >sense: could p6 allow (for the >first few versions anyway) a >"require <6;" directive? My ... This sounds to me like a good idea, especially if we implement some of the other radical changes, such as implicit 'use strict' or major changes to builtins. Personally I'd have it be 'use perl5' (it's the difference between making a new pragma and defining a third meaning for require [or redefining its current meaning]) but that's a minor detail. Unfortunately, it may be too late. Oh well... --Brent Dax Excuse typos, it's hahd to write on a Palm...
Re: Perl_foo() vs foo() etc
Dan Sugalski wrote on 4/11/01 13.38: >At 03:09 PM 4/11/2001 >-0400, John Siracusa wrote: >>On 4/11/01 10:55 AM, Dan >Sugalski wrote: >> > It does fix the link issues, >though. perl6.so won't ever >have an >> > unqualified function in >it--they'll all have either a >Perl_ or _Perl_ >> > prefix on them, and all >global data will have a PL_ >prefix on it. >> >>Remind me again why it's >PL_ and not PERL_? > >Well, Perl_ and PERL_ won't >work, since that's relying on >case-sensitivity in the >various linkers, which is a Bad >Thing. Why don't we just say, "Variables and functions will NOT have the same post-prefix name"? Having Perl_foo and PL_foo is a bit confusing anyway. I like Perl_foo and PERL_foo--it makes it very clear what things are while making sure we keep our own little 'namespace'. --Brent Dax Excuse typos, it's hahd to write on a Palm...
RE: Something to hash out
# -Original Message- # From: Simon Cozens [mailto:[EMAIL PROTECTED]] # Sent: Saturday, August 25, 2001 10:59 AM # To: Dan Sugalski # Cc: [EMAIL PROTECTED] # Subject: Re: Something to hash out # # # On Sat, Aug 25, 2001 at 10:37:35AM -0400, Dan Sugalski wrote: # > I'm currently thinking of using .pasm as the extension for # parrot assembly # > code, and .pbc for precompiled bytecode. (Yes, the # interpreter loads and # > runs compiled bytecode from disk. Wheee!) Can anyone think # of anything # > better? They seem rather lame. (Bonus points for clever # acronyms gotten # > without strain, or puns in any human language) # # I was using .pas and .pac. Gotta think about 8.3ness, unfortunately. If you're worried about Win32, even Microsoft is breaking 8.3 in Visual Studio.NET. (The extension for VB project files is .vbproj, and VC++ is .vcproj. I'm trying to shuck Win32, but haven't been too successful so far--apparently Tux didn't like my old box.) Besides, both of those can be truncated without any problems. # On an unrelated note, and seeing Dan Bryan's experiments with # different # kinds of switch/dispatch, I think it makes sense to separate out ops # which correspond to PMC vtable functions (add, subtract, # etc.) and those # which don't. Those which do can be done with a switch to save # a function # call, and those which don't can use function pointers. This achieves # the same objective as auto-generating op wrappers around # vtable functions, # (saving one level of indirection) while leveraging the gain # from a split-level # op despatch loop. Not a bad idea. Allowing for optimizations later so they aren't premature is usually a good idea. :^) --Brent Dax [EMAIL PROTECTED]
RE: Deoptimizations
# -Original Message-
# From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
# Sent: Saturday, September 01, 2001 12:29 PM
# To: [EMAIL PROTECTED]
# Subject: Deoptimizations
#
#
# Random musings from a discussion I had yesterday. (And check
# me on my
# assumptions, please.)
#
# One of the more common lamentations is that a dynamic
# language (like Perl)
# doesn't mix well with optimizations, because the majority of
# optimizations
# are done at compile time, and the state at compile time isn't
# always the
# state at runtime. A common declaration is, "We'd like to
# optimize that, but
# we can't, because foo may change at runtime."
#
# Perl 5 optimizations replace (or, more accurately, null out)
# a more complex
# opcode stream [1] with a simpler one. Constant folding is
# one such example.
#
# 5 -> add -> 10 -> add -> 15 -> store
#
# becomes
#
# 30 -> store
#
# plus a bunch of null ops. (The null ops are faster than
# attempting to
# splice the new opcode stream [1] in place of the old one, but
# I don't know
# by how much.)
#
# Consider the following:
#
# Create an optimization op, which is more a less a very fancy
# branch operator.
# Whenever you elect to do an aggressive optimization, place
# the opt op as a
# branch between the newly created... [1] and the old, full one.
#
# The op could decide ( From a switch or variable - turn on and off
# optimizations while running. Or from state introspection,
# perhaps, since you
# probably have a good idea of what changes would invalidate
# it. ) whether to
# exercise the optimized code, or revert to the original,
# unoptimized version.
# I supposed, if you were to implement an advanced JIT, you
# could replace an
# invalidated optimization with its newly optimized variant.
#
# That would also work with a couple of tie-ins with the
# language. First,
# of course, the ubiquitous pragma, which could affect which
# optimizations
# (assuming we categorized them) we should run, and which we
# shouldn't, based
# on the suggestions from the programmer. And perhaps some
# hook into the
# internals for the same reason.
#
# sub foo {
# no optimizations;
# ...
# }
#
# or
# {
# local $opt = (ref $obj eq "SomeNewObject");
# # If the $obj has changed, don't run any optimizations
# }
#
# Is this possible? Feasible? Way out there?
I think it's a good idea! ++[bwarnock]!
Of course, the hard part is detecting when the optimization is invalid.
While there are simple situations:
sub FOO {"foo"}
print FOO;
evaluating to:
/-no--"foo"-\
opt: FOO redefined? -< >---print
\-yes-call FOO--/
there could also be some more complicated situations, in which the
situations where the optimizations are invalid are harder to define.
I'd also suggest a different pragma:
use less 'optimization';
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
RE: Deoptimizations
# -Original Message-
# From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
# Sent: Saturday, September 01, 2001 3:01 PM
# To: Brent Dax; [EMAIL PROTECTED]
# Subject: Re: Deoptimizations
#
#
# On Saturday 01 September 2001 05:07 pm, Brent Dax wrote:
# > Of course, the hard part is detecting when the optimization
# is invalid.
# > While there are simple situations:
# >
# > sub FOO {"foo"}
# >
# > print FOO;
# >
# > evaluating to:
# >
# > /-no--"foo"-\
# > opt: FOO redefined? -< >---print
# > \-yes-call FOO--/
# >
# > there could also be some more complicated situations, in which the
# > situations where the optimizations are invalid are harder to define.
#
# Granted, code can always be written more complexly than our
# ability to
# understand it, in which case we very well may throw out the
# warnings that
# Thou Shall Not (if thou wants consistant, accurate results).
#
# But for many optimizations, although perhaps more with peephole
# optimizations than with full code analysis type of
# optimizations, simply
# identifying a possible optimization usually identifies its
# potential undoing
# as well.
#
# After all, optimizations don't just happen. They are, more
# or less, a set
# of known patterns that you look for. For a dynamic language,
# part of the
# original identification of those patterns may very well be
# the additional
# identification of what pieces are critical to the optimization.
#
# Of course, with as *highly* a dynamic language as Perl, there
# may be several
# hundred things that could invalidate a given optimization -
# it would be less
# optimal to detect all those things that to simply run the
# unoptimized code!
#
# But in many cases, it may only be one or two.
You'd be surprised how quickly the possibilities pile up:
sub FOO {"FOO"}
sub BAR {"BAR"}
sub BAZ {"BAZ"}
sub QUUX ("QUUX")
print FOO.BAR.BAZ.QUUX;
When you try to do inlining and constant folding, you end up with
something like this:
OPT:
Redefined FOO or BAR or BAZ or QUUX?
/ \
no yes
/ \
/ \
/ \
/ \
"FOOBARBAZQUUX" OPT:
| Redefined FOO?
| /\
|yesno
|/\
|call FOO"FOO"
|\/
| \ /
| \/
| \ /
|\/
| OPT:
| Redefined BAR?
| /\
|yesno
|/\
|call BAR "BAR"
|\/
| \ /
| \/
| \ /
|\/
| Concatenate
|||
| OPT:
| Redefined BAZ?
| /\
|yesno
|/\
|call BAZ "BAZ"
|\/
| \ /
| \/
| \ /
|\/
| Concatenate
|||
| OPT:
| Redefined QUUX?
| /\
|yesno
|/\
| call QUUX"QUUX"
|\/
| \ /
| \/
| \ /
|\/
| Concatenate
\ /
\ /
\ /
\ /
\ /
Should MY:: be a real symbol table?
Currently, in Perl 5, my() variables are stored in a totally separate way from normal our()/local() variables, in an array-of-arrays structure. This means that my() variables are second-class citizens. The opcodes to look up a my() variable are separate from the opcodes for an our()/local() variable. >From my point of view, this seems dumb. Is there any real reason my() variables are stored in a pad instead of a symbol table? It seems more natural that they would be stored in a symbol table, since symbol tables are designed to hold variables. It also seems like it would allow us to implement 'my sub'. Of course, this has long been in Perl 5; I don't think it could be changed at this point. However, we're now doing the same thing with Perl 6. As if it didn't seem stupid enough as is, we're supposed to simulate at least some of the functionality of a symbol table through the MY:: pseudo-package. Once again, why isn't MY:: stored in some sort of anonymous symbol table? This would allow us to do all the things we can normally do with a global, without the hassles of writing a magical pseudo-package. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Should MY:: be a real symbol table?
# -Original Message- # From: Simon Cozens [mailto:[EMAIL PROTECTED]] # Sent: Sunday, September 02, 2001 4:34 AM # To: Brent Dax # Cc: [EMAIL PROTECTED] # Subject: Re: Should MY:: be a real symbol table? # # # On Sun, Sep 02, 2001 at 03:13:09AM -0700, Brent Dax wrote: # > Is there any real reason my() variables are stored in a pad # instead of a # > symbol table? # # Recursion. Perhaps I wasn't entirely clear. I'm suggesting array-of-symbol-tables instead of array-of-arrays. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Should MY:: be a real symbol table?
# -Original Message-
# From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
# Of Ken Fox
# Sent: Sunday, September 02, 2001 8:49 AM
# To: Brent Dax
# Cc: [EMAIL PROTECTED]
# Subject: Re: Should MY:: be a real symbol table?
#
# Brent Dax wrote:
# > Is there any real reason my() variables are stored in a pad instead
# > of a symbol table?
#
# Simon already told you why a pad is used.
#
# But I think you misunderstand what a symbol table is. Variables
# aren't *stored* in the symbol table. Only the definitions and storage
# locations of variables are stored there. During execution of a program
# symbol tables usually aren't needed -- the generated code embeds the
# necessary information from the symbol table. For example, if you have
#
# void f() { int x; x = 1; ... }
#
# then "x" in the symbol table may be defined as "4 byte
# integer at stack
# pointer - 4". The code for getting/setting "x" doesn't use the symbol
# table because it has instructions like "mov sp[-4], 1" or something.
That's certainly true for C. Actually, I'm not sure the symbol tables
still exist when you execute the program.
Perl, however, is such a dynamic language you can't do a lot of that
resolution at compile-time. What happens when I say:
C:\Documents and Settings\Administrator\Desktop>perl
$x="foo";
$::{"x"}=\"bar";
print $x;
^Z
bar
? If that had been resolved at compile-time, it would have printed
"foo"--but I replaced the SV with "foo" in it. (FWIW, though, I think
it resolves it down to the typeglob.)
However, there are other cases, such as stash manipulations and symbolic
references.
# > Once again, why isn't MY:: stored in some sort of anonymous symbol
# > table? This would allow us to do all the things we can normally do
# > with a global, without the hassles of writing a magical
# > pseudo-package.
#
# You can't store lexical variable definitions in a global symbol
# table. What happens when you try to access a local variable that
# doesn't exist because it isn't in scope? Also, many of the scopes
# that contain variables aren't named. How would you differentiate
# between the following two "$x" variables?
#
# sub f() { if (...) { my $x; ... } else { my $x; ... } }
That's not terribly hard--the two ${x}es are in unrelated scopes. The
more difficult case is:
sub f() { my($x); if(...) {my($x); ...} }
but in that case the inner my($x) could be translated to
temp($MY::x)--the behavior is basically the same. (Actually, if pads
are replaced with stashes, is there any situation where my($x) can't be
translated to temp($MY::x)? Hmmm...)
# If you want to grab a lexical, you *must* be in scope. If you're
# already in scope there's no reason for "MY::" -- just use the
# variable's real name.
But we've promised to support %MY::. I think we could avoid coding a
special case by using an array of symbol tables instead of an array of
arrays. Besides, who's to say we don't want 'use dominatrix;' to
require my() variables to be fully qualified? :^)
# It sounds like you just want a simple way of getting the variables
# in scope -- are you writing a debugger? I agree with you that it would
# be very nice to have a low-level debugging API that doesn't treat
# lexicals differently than globals.
No, but I'm planning to help write Perl 6, and I want to make things at
least a bit easier. :^)
Plus, it would help remove many inconsistencies in certain operations,
such as symbolic references:
C:\Documents and Settings\Administrator\Desktop>perl
our($x)="global";
{
my($x)="local";
print join ' ', $x, ${"x"};
}
^Z
local global
(I also seem to remember some weirdness similar to this with eval, but
couldn't reproduce it.)
While this is the documented behavior of Perl 5.6.1, I don't think it's
the right behavior--do you?
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
RE: Should MY:: be a real symbol table?
# -Original Message- # From: Sam Tregar [mailto:[EMAIL PROTECTED]] # Sent: Sunday, September 02, 2001 1:23 PM # To: Brent Dax # Cc: [EMAIL PROTECTED] # Subject: RE: Should MY:: be a real symbol table? # # On Sun, 2 Sep 2001, Brent Dax wrote: # # > but in that case the inner my($x) could be translated to # > temp($MY::x)--the behavior is basically the same. # (Actually, if pads # > are replaced with stashes, is there any situation where # my($x) can't be # > translated to temp($MY::x)? Hmmm...) # # Closures, for one. File-scoped lexicals for another. # Lexical variables # are very different beasts from package variables. They are # not compatible # in some significant ways. Okay, I forgot to account for the fact that we'd have to increment the refcount for every inner scope a my() variable is referred to in. That's not terribly hard, is it? File-scoped lexicals are basically the same thing--increment the refcount for every inner scope they're referred to in (unless they have some other special behavior I'm not aware of). # Now, that said, we'll need to do something better than pads to support # %MY. If that means full-blown symbol tables for every scope... Well, # I'd be surprised. There's a reason lexical variables are faster than # package variables and I imagine we'd like to keep it that way. I imagine they'd *still* be faster than package variables, if only because it would check for a my() variable by that name first. Since we don't have to deal with autovivifying my() variables, we can probably resolve many lookups at compile time at least to the correct stash entry, which will make tighter loops than a full lookup each time. (In other words, if we know all the my() variables available, we can do the lookup at compile time to get the address of an RV to the actual SV.) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Should MY:: be a real symbol table?
# -Original Message-
# From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
# Sent: Sunday, September 02, 2001 1:37 PM
# To: Brent Dax
# Cc: Simon Cozens; [EMAIL PROTECTED]
# Subject: RE: Should MY:: be a real symbol table?
#
#
# On Sun, 2 Sep 2001, Brent Dax wrote:
# >
# > Perhaps I wasn't entirely clear. I'm suggesting
# array-of-symbol-tables
# > instead of array-of-arrays.
#
# It is right now in perl 5, and that isn't changing. How do you think
# string eval finds lexicals in scope by name now? :)
"As mentioned briefly above, the xcv_padlist element holds a
pointer to an AV. This array, the padlist, contains the
names and values of lexicals in the current code
block...The first element of the padlist - called the
'padname' - is an array containing the names of the
variables, and the other elements are lists of the current
values of those variables. Why do we have several lists of
current values? Because a CV may be entered several
times - for instance, when a subroutine recurses."
--from Simon Cozens's tutorial on Perl 5 internals.
What I'm suggesting is that, instead of the padlist's AV containing
arrays, it should contain stashes, otherwise indistinguishable from the
ones used for global variables. This way we don't have to recode the
lookup or do incredibly fancy stuff to support %MY::. It may even speed
up eval STRING or other situations in which lookup is at runtime. And
we should be able to resolve at least to the HE level at compile-time,
if you're worried about it slowing down runtime.
However, we might even be able to do this without a padlist! How? By
using temp() on the MY:: stash. Observe:
sub factorial {
my($x)=@_;
if($x==1) {return 1}
else {return $x*factorial($x-1)}
}
This could be translated by the parser to something like this:
sub factorial {
temp($MY::x)=@_;
if($MY::x==1) {return 1}
else {return $MY::x*factorial($MY::x-1)}
}
Assuming that each subroutine is given one MY:: stash, what
functionality has been lost? $x gets a new SV for each call into
factorial() (via the call to temp()), and since each subroutine has its
own MY:: stash, any routines that might be called by factorial() won't
be able to see factorial()'s MY::. Finally, this opens up the
possibility of easily-implemented static my() variables--just eliminate
the call to temp().
The basic principle behind this is to ask one simple question: "how are
temp() variables different from my() variables?" Ignoring closures and
implementation details (like that my() variables are stored in a pad),
the only difference is that temp() variables stay visible outside the
subroutine they were temp()orized in, while my() variables don't. The
simple way to emulate this is to make sure that no subroutine can see
another's MY:: stash. Since any subroutine can have my() variables, we
simply have to make sure each sub's MY:: stash blocks out each other
sub's.
There is a possible caveat with inner blocks--how does an outer block
get, er, blocked from accessing an inner block's my() variables?
However, I think this isn't really that big a problem, and can easily be
solved with properties:
sub foo {
# $x not declared yet, so it's out of scope
if(@_) {
my($x);
# now $x is in scope
# when we re-enter foo(), $x is not in
# scope in there.
foo();
# but by the time we get back, $x is back
# in scope again.
}
# $x is out of scope again
}
becomes
sub foo {
temp($MY::x);
$MY::x is out_of_scope();
#since $MY::x is marked as out of scope,
#attempts to access it in this block are
#unsuccessful...
if(@_) {
temp($MY::x);
# but in here, it's temp()ed again
# and the out_of_scope property is
# not in effect.
# when we re-enter foo, $x will be
# temp()ed again and the new $x
# will be marked as out of scope...
foo();
# but by the time we get back, we've
# got our $x back and we can access
# it.
}
# the inner temp is out of effect, so once
# again $x is marked as out of scope.
}
I don't think the argument that my() variables should be
RE: Should MY:: be a real symbol table?
Note: some parts of this may seem a bit like a flame. This is unintentional. Ken Fox: # Brent Dax wrote: # > What I'm suggesting is that, instead of the padlist's AV containing # > arrays, it should contain stashes, otherwise indistinguishable from # > the ones used for global variables. # # Lexicals are fundamentally different from Perl's package (dynamically # scoped) variables. Even if you could somehow hack package variables # to implement lexicals, it would waste space duplicating a symbol table # for each instance of a lexical scope. *How* are they "fundamentally different"? You keep saying this, but I don't see it. In *functionality* what is the "fundamental difference" between package and lexical variables? # > The simple way to emulate this is to make sure that no subroutine # > can see another's MY:: stash. # # Right. Sounds a lot like a pad to me -- each instance of a scope (sub) # gets its' own copy of the variables. (By instance I mean activation # record, not the symbol table definition.) But in this case the pad is actually a full symbol table. The concept is the same, the data structure is different. # > There is a possible caveat with inner blocks--how does an # outer block # > get, er, blocked from accessing an inner block's my() variables? # > However, I think this isn't really that big a problem, and # can easily be # > solved with properties: # # You don't understand lexically scoped variables. There isn't # any run-time name lookup on a variable -- the compiler resolves all # access to a specific memory location (or offset). All your fancy # symbol table flag twiddling is slow, unreliable and unnecessary. There *is* run-time lookup in some contexts, such as a string eval. (Currently symbolic references are not another case--symrefs only work with globals--but I think they should work with lexicals too.) In the end, all I'm doing is suggesting an alternate implementation which should reduce our workload and make many concepts which currently don't work with lexicals work correctly. If there are big, huge problems with the alternate implementation I'm proposing, please explain them to me. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: An overview of the Parrot interpreter
Note: this is my understanding of the situation; I could be wrong.
Sam Tregar:
# On Sun, 2 Sep 2001, Simon Cozens wrote:
#
# > For instance, the Parrot VM will have a register
# architecture, rather
# > than a stack architecture.
#
# s/rather than/as well as/; # we've got a stack of register
# frames, right?
IIRC, that's mostly for when we run out of registers or we're changing
scopes or whatever. For the most part, it's a register architecture.
# > There will be global and private opcode tables; that is to
# say, an area
# > of the bytecode can define a set of custom operations that
# it will use.
# > These areas will roughly map to compilation units of the original
# > source; each precompiled module will have its own opcode table.
#
# Side note: this isn't making sense to me. I'm looking
# forward to further
# explanation!
In other words, when you have sub foo {} in your code, it will be
assigned an opcode number in the 'private' section. The global section
is for things that are built-in to Parrot, while the private section is
for stuff you write. (Right?)
# > If our PMC is a string and has a vtable which implements Perl-like
# > string operations, this will return the length of the
# string. If, on the
# > other hand, the PMC is an array, we might get back the number of
# > elements in the array. (If that's what we want it to do.)
#
# Ok, so one example of a PMC is a Perl string...
>From what I've seen, PMCs will represent SVs, AVs, and HVs at the opcode
level. (When you get down to C, it's really SVs and AVs and HVs, but in
bytecode it's all PMCs.)
# > Parrot provides a programmer-friendly view of strings. The
# Parrot string
# > handling subsection handles all the work of memory allocation,
# > expansion, and so on behind the scenes. It also deals with
# some of the
# > encoding headaches that can plague Unicode-aware languages.
#
# Or not! Are Perl strings PMCs or not? Why does Parrot want to handle
# Unicode? Shouldn't that go in a specific language's string
# PMC vtables?
Perl *scalars* are PMCs. Those PMCs may hold strings within them.
However, string manipulation is done in special string registers, which
are *not* PMCs.
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
RE: Should MY:: be a real symbol table?
# -Original Message-
# From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
# Sent: Monday, September 03, 2001 4:31 PM
# To: Ken Fox; Brent Dax
# Cc: Simon Cozens; [EMAIL PROTECTED]
# Subject: Re: Should MY:: be a real symbol table?
#
# >Lexicals are fundamentally different from Perl's package
...
# No, actually, they're not.
#
# The big difference between lexical variables and package
# variables is that
# lexicals are looked up by stash offset and package variables
# are looked up
# by name. (Okay, there are a few minor details beyond that, but that's
# really the big one) There really isn't anything special about
# a stash. All
# it is is a hash perl thinks contains variable names. (And it has GVs
# instead of [SHA]Vs, but once again a trivial difference, and
# one going away
# for perl 6)
#
# The real question, as I see it, is "Should we look lexicals
# up by name?"
# And the answer is Yes. Larry's decreed it, and it makes sense. (I'm
# half-tempted to hack up something to let it be done in perl
# 5--wouldn't
# take much work)
#
# The less real question, "Should pads be hashes or arrays",
# can be answered
# by "whichever is ultimately cheaper". My bet is we'll
# probably keep the
# array structure with embedded names, and do a linear search
# for those rare
# times you're actually looking by name.
Yay, someone understood what I was saying! :^)
As far as expensiveness, I think this can be just as fast as our current
offset-into-the-pad method.
If we allocate the stash at compile time (so the HEs don't change), we
can resolve lexicals down to the HE. In essence, the HE would be
serving the job a GV does in Perl 5 for globals, or an offset does for
lexicals on array-of-array pads--indirection. (Obviously this would be
in the fixup section in pre-compiled code.)
For those who don't understand my ravings:
sub foo { my($bar, @baz); ... }
becomes:
CV {
refcount --> 1
opcodes ---> ...
padstash --+
...|
} |
|
STASH { <+
HE (Hash Entry) { (0x1)
key -> '$bar'
value ---> SV *
...
}
HE { (0x2)
key > '@baz'
value --> SV *
...
}
...
}
At compile-time, we can allocate and fill the stash. Then, _still in
compile time_, we determine which HE will contain the value. For
example, we know that the value slot of the hash entry at 0x1 will
contain the SV currently representing $bar.
Now, we can change the actual SV containing the current value of $bar at
will. As long as the HE doesn't change, we're safe.
Since we're now looking up our variable names in a hash instead of an
array (remember, Perl hashes are only about 15% slower than arrays),
when we do have to look up a lexical at runtime we avoid an expensive
linear search. (I don't know how the offsets are determined at
compile-time in Perl 5, but if they're also determined by a linear
search, we'll make compilation more efficient too.)
Obviously, the current array-of-array pads are more compact than a
stash; however, I doubt that will be a serious issue.
~~
As far as the temp() thing I mentioned earlier, compare these two pieces
of code:
sub factorial {
my($x)=shift;
return 1 if($x==1);
return $x * factorial($x-1);
}
sub factorial {
temp($x)=shift;
return 1 if($x==1);
return $x * factorial($x-1);
}
These subroutines recurse. However, neither sub gets confused and tries
to modify another stack frame's $x. In the second sub, *temp() is just
a mechanism to get a new $x*. That's what I was talking about--I was
trying to draw an analogy between existing functionality and my
proposal.
If this point is still confusing, contact me privately and I can explain
it in more detail; if I get a bunch of requests I'll post it to the
group.
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
RE: Should MY:: be a real symbol table?
# -Original Message- # From: Dan Sugalski [mailto:[EMAIL PROTECTED]] # Sent: Monday, September 03, 2001 5:50 PM # To: Brent Dax; Ken Fox # Cc: Simon Cozens; [EMAIL PROTECTED] # Subject: RE: Should MY:: be a real symbol table? # # # At 05:30 PM 9/3/2001 -0700, Brent Dax wrote: # >As far as expensiveness, I think this can be just as fast as # our current # >offset-into-the-pad method. # # I was speaking in both speed and memory use when I was talking about # expense. We'd need to maintain a hash structure for each pad, # plus we'd # need to either design the hash structure such that it didn't # need absolute # addresses (so we could build it at compile time, which could # be a long time # before runtime with a disk freeze or two and an FTP in the # interim), or # we'd need to patch the addresses up at runtime when we # allocated a new pad. I assume we're willing to have more fixup time for runtime performance, correct? Then consider this: array-of-array pad: curpad => a pointer to the current pad; same as in Perl 5 offs => an offset into the current pad, representing a variable Accessing the address of the variable: curpad[offs] stash pad: hvaddr => the address of an HE, representing a variable Accessing the address of the variable: hvaddr->value Is either of these likely to be faster than the other? (Although I'm not an assembler hacker, I can't see the first being faster than the second.) If so, does the possible speed benefit outweigh any increased startup overhead? # I'm not convinced the memory usage, and corresponding time to # clone and/or # set up the hash-based pad, is worth the relatively infrequent by-name # access to variables in the pad. I could be wrong, though. # We'll have to try # it and see. (Shouldn't affect the bytecode, however, so we can try # different methods and benchmark them as need be) By using something similar to temp() (where the SV* is temporarily replaced), cloning should only be necessary for situations in which two threads are running the same function at the same time. Similarly, setting up the hash shouldn't take any more abstract operations than setting up padlist[0]; the actual hash internals may take more time to do their job, however. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Should MY:: be a real symbol table?
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
# -Original Message-
# From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
# Sent: Monday, September 03, 2001 7:25 PM
# To: Brent Dax; Ken Fox
# Cc: Simon Cozens; [EMAIL PROTECTED]
# Subject: RE: Should MY:: be a real symbol table?
#
#
# At 07:05 PM 9/3/2001 -0700, Brent Dax wrote:
# ># From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
# ># At 05:30 PM 9/3/2001 -0700, Brent Dax wrote:
# ># >As far as expensiveness, I think this can be just as fast as
# ># our current
# ># >offset-into-the-pad method.
# >#
# ># I was speaking in both speed and memory use when I was
# talking about
# ># expense. We'd need to maintain a hash structure for each pad,
# ># plus we'd
# ># need to either design the hash structure such that it didn't
# ># need absolute
# ># addresses (so we could build it at compile time, which could
# ># be a long time
# ># before runtime with a disk freeze or two and an FTP in the
# ># interim), or
# ># we'd need to patch the addresses up at runtime when we
# ># allocated a new pad.
# >
# >I assume we're willing to have more fixup time for runtime
# performance,
# >correct?
#
# Yes. But fixup is a runtime cost, so we need to weigh what
# the fixup costs
# versus the return we get from it.
But it's a one-time runtime cost, unlike, say, a string eval in a loop.
(sub-entry overhead complaints cut--they'll be addressed at the end of
the e-mail.)
# ># I'm not convinced the memory usage, and corresponding time to
# ># clone and/or
# ># set up the hash-based pad, is worth the relatively
# infrequent by-name
# ># access to variables in the pad. I could be wrong, though.
# ># We'll have to try
# ># it and see. (Shouldn't affect the bytecode, however, so we can try
# ># different methods and benchmark them as need be)
# >
# >By using something similar to temp() (where the SV* is temporarily
# >replaced), cloning should only be necessary for situations
# in which two
# >threads are running the same function at the same time.
#
# Nope, I'm talking about recursion. When you do:
#
#sub foo {
# foo();
#}
#
# we need to clone foo's pad from the template, because we need
# a new one.
# Otherwise that whole lexical variable/recursion thing doesn't
# work, which
# is A Bad Thing. :)
Now is where the temp() stuff I was talking about earlier comes in.
sub foo {
my($bar);
foo();
}
is basically equivalent to
sub foo {
temp($MY::bar);
foo();
}
(I mentioned to Ken Fox in private that this isn't too different than
temp()ing globals when each sub is in its own package.)
If we did this, I don't think the cost would be greater to recurse than
it would be for array-of-arrays. (Especially since we'd make sure to
optimize the hell out of temp.) This would also lead to less code to
write and a smaller binary. Plus a simple way to do static: don't
temp()orize the variable on entry.
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
RE: An overview of the Parrot interpreter
Simon Cozens:
# On Mon, Sep 03, 2001 at 04:05:26PM -0700, Brent Dax wrote:
# > In other words, when you have sub foo {} in your code, it will be
# > assigned an opcode number in the 'private' section. The
# global section
# > is for things that are built-in to Parrot, while the
# private section is
# > for stuff you write. (Right?)
#
# That's a better explanation than I managed, thanks.
#
# > Perl *scalars* are PMCs. Those PMCs may hold strings within them.
# > However, string manipulation is done in special string
# registers, which
# > are *not* PMCs.
#
# That's also a better explanation than I managed, thanks.
Hey, I'm a trained professional in Cozens-to-English, what do you
expect? :^)
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
RE: pads and lexicals
Dave Mitchell: # Simon Cozens <[EMAIL PROTECTED]> wrote: # > On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote: # > > So I guess I'm asking whether we're abandoning the Perl 5 concept # > > of a pad full of tmp targets, each hardcoded as the # target for individual # > > ops to store their tmp results in. # > # > Not entirely; the last thing we want to be doing is creating PMCs at # > runtime. # # Sorry, I thought you were suggesting that at compile time a # fixed number of # tmp PMCs would be created, and slots 1-N of the PMC registers # would be set # permanently to point to them. Which is why I was concerned about the # possibility of N+1 tmps being needed. # # > > If a certain number of PMC regs are 'hardcoded' with pointers to # > > PMC tmps, then we need to address register overflow, eg # an expression like # > > # > > foo($x+1, $x+2, , $x+65); # > # > That's slightly different, though, because that'll all be # passed in as # > a list. # # So how does that all work then? What does the parrot assembler for # # foo($x+1, $x+2, , $x+65) # # look like roughly - and where do the 65 tmp PMCs come from? # In Perl 5 they're # the 65 pad tmps associated with the add ops. If foo is an unprototyped function (and thus takes a list in P0) we can immediately push the values of those calculations on to the list, something like (in a lame pseudo-assembler that doesn't use the right names for instructions): load $x, I1 load 1, I2 add I1, I2, I3 push P0, I3 load 2, I2 add I1, I2, I3 push P0, I3 (lather, rinse, repeat) In the more general case, however (say, $x*1+$x*2+...$x*65) that's an interesting question. Could we just do some fun stuff with lists? What do real CPUs do? --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: pads and lexicals
Dan Sugalski: ... # new P0, list# New list in P0 # get_lex P1, $x # Find $x # get_type I0, P1 # Get $x's type # set_i I1, 1 # Set our loop var # $10: new P2, I0 # Get a temp of the same type as $x # add P2, P1, I1 # Add counter to $x, store # result in P2 # push P0, P2 # Push it into the list # eq I1, 65, $20, $10 # If loop counter's 65 goto # $20, else $10 # $20 call foo# Call the sub ... Are you expecting the optimizer to be *that* powerful? If so, I think I'll stay with the execution engine... :^) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: pads and lexicals
Dan Sugalski: # At 12:04 PM 9/6/2001 -0700, Brent Dax wrote: # >If foo is an unprototyped function (and thus takes a list in # P0) we can # >immediately push the values of those calculations on to the list, # >something like (in a lame pseudo-assembler that doesn't use the right # >names for instructions): # # FWIW, it's: # # op, dest, source, source, source Yeah, I was just being too lazy to go open the assembler PDD and look for the right instructions, so I missed the format too. :^) # >In the more general case, however (say, $x*1+$x*2+...$x*65) that's an # >interesting question. Could we just do some fun stuff with # lists? What # >do real CPUs do? # # Real CPUs don't do lists. It's just one big addressable byte array... Those were two separate questions. :^) First, I thought that we could generalize the P0 case to all similar cases. Then, I thought "Hey, this has to happen on real CPUs all the time. How do they handle it?" See? Two separate ideas. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
Defeating variable-width encodings
A thought I had: if variable-width encodings are so difficult because it's hard to index into them by character, why don't we break them up ourselves? +PV---+ +strchunk-+-+ +strchunk-+-+ |string |-->|the quick brown fox jumped ov|>+-->|er the lazy dog |/| |... | +-+-+ +-+-+ Now, if we want to substr($str, 40, 1), we can skip the first chunk. (32 was a number I picked out of the air; other numbers may be better.) This avoids the possible huge overheads of other linked-list approaches while also avoiding some of the linear scanning that would otherwise be required to index into the string. As far as things with lvalue substr()...we could fudge that number a bit and allow strchunks to be a little more or less than 32, as long as they know their size. Then, whey you scan, you just add up the number of characters in each chunk until you overshoot. That makes scanning a bit slower, but not much. (We'd probably also want the string to rebalance itself periodically, but that's a different story.) An alternate approach would be to remember how far into the string you have to index to get to certain points in the string. (For the purpose of this part of the document, a 'byte' is a codepoint and a 'character' is an abstract character.) For example: +PV---+ |string |-->"the quick brown fox jumped over the lazy dog" |length 44| |bytes 44| |half 22| |quar 11| |threeq 33| |... | Although in this example the string is normal ASCII, consider what we would have if we replaced the 'o' in 'brown' and the 'a' in 'lazy' with two-byte characters (represented by a doubled letter): +PV---+ |string |-->"the quick broown fox jumped over the laazy dog" |length 44| |bytes 46| |half 23| |quar 11| |threeq 34| |... | Now, on a call like substr($str, 36, 1) we can skip all the way to byte 34--which we know represents character number 33--and count from there. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Math functions? (Particularly transcendental ones)
Jeremy Howard: # Uri Guttman wrote: # > >>>>> "BS" == Benjamin Stuhl <[EMAIL PROTECTED]> writes: # > # > >> Can anyone think of things I've forgotten? It's been a # while since # > >> I've done numeric work. # > # > BS> ln, asinh, acosh, atanh2? # > # > dan mentioned log (base anything) but i don't recall ln. # and definitely # > the arc hyberbolics are in after i pointed them out. dunno # about atanh2. # > # We only really need ln(). Then [log(y) base x] is simply # [ln(y)/ln(x)]. # There's no need to have separate functions for different bases. "OISC: You've heard of RISC, Reduced Instruction Set Computers? Well, here is the concept taken to its logical extreme -- an emulator for a computer with just one (1) instruction (Subtract and Branch if Negative)! Sample programs in the OISC machine language are included. We now have available have a revised and expanded version of oisc called OIC. In the future, this may replace OISC." from http://www.tuxedo.org/~esr/retro/ :^) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Math functions? (Particularly transcendental ones)
Dan Sugalski: # At 10:08 AM 9/10/2001 -0700, Wizard wrote: # >Uri Guttman wrote: ... # Okay, I see what you're aiming at. I don't think we will, # mainly because # it's not going to do us a whole lot of good. Parrot's got # more registers # than any system on the planet that I know of, so the bit that handles # converting to native machine code will need to do some analysis and # register renaming anyway. It can handle putting things in the # right places. I seem to remember reading in an article somewhere that Itanium has 128 registers. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Speaking of namespaces...
Damien Neil: # On Mon, Sep 10, 2001 at 06:58:23PM -0400, Dan Sugalski wrote: # > At 03:52 PM 9/10/2001 -0700, Damien Neil wrote: # > >Parrot fails to work in very obscure ways on FreeBSD. After some # > >poking around, I tracked the problem to the "end" op--this appears # > >to conflict with something inside libc. Renaming the op fixes the # > >problem. # > # > Ah, that's what was killing the build on Nat's machine. # Patch, by chance? # # The following quick-and-dirty patch appears to work. This prefixes # all opcode functions with "Parrot_op_". I'd have made the prefix # configurable, but the opcode generation is spread across three # different files. # # (Aside: What's the best way to generate a useful patch with cvs? # The following comes from "cvs -q diff -u".) This patch seems to work on the FreeBSD box I have access to. Now to figure out what's causing all those 'use of uninitialized value at assembler.pl line 81' messages... --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Speaking of namespaces...
Damien Neil: # On Mon, Sep 10, 2001 at 04:04:20PM -0700, Damien Neil wrote: # > The following quick-and-dirty patch appears to work. This prefixes # > all opcode functions with "Parrot_op_". I'd have made the prefix # > configurable, but the opcode generation is spread across three # > different files. # # Oops--that breaks the assembler. This patch fixes the assembler to # work with the prior patch. That explains it! :^) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Parrot 0.0.1 is released.
# -Original Message- # From: Jeffrey Coleman Carlyle [mailto:[EMAIL PROTECTED]] # Sent: Monday, September 10, 2001 5:04 PM # To: 'Simon Cozens' # Cc: [EMAIL PROTECTED] # Subject: RE: Parrot 0.0.1 is released. # # # Am I missing something (well, clearly I am), but are test.pasm and # test2.pasm missing from the CVS repository? Check the t/ directory. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Patch to assembler/disassembler + parrot asm
Dan Sugalski: ... # The jump ops will be easy to figure--either they'll take a # register, a # constant number, or a label. We don't allow labels that could # be confused # with registers. (No I0: anywhere...) Noo! How will I write really confusing JAPHs now? :^) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Configure system
Simon Cozens:
# One of the items on the Parrot TODO is to build a Configure
# system. I don't want to spark up the old metaconfig-versus-autoconf
# debate again, so I'll clarify what I mean.
...
# You'll notice that the Parrot build process currently depends on the
# existence of Perl 5 to build certain header files and preprocess the
# opcode table. So if we know we've got Perl 5 hanging around, we know
# we've already got a config file which tells us things like how big IVs
# are, what header files we have around, and so on. Furthermore, we
# can write a Perl program which uses Config.pm to give us this
# information in a hash, and hence we can use that to produce a
# config.h
# specific to a given machine.
#
# So I'd like to see a patch which consists of a program to
# automatically generate Parrot's config.h from Perl's Config.pm. You
# could be really clever, and also have it conditionally include some
# of the header files mentioned in parrot.h depending on whether the
# i_... values in Config.pm say we have them. (You may need to move the
# "#include"s of the system header files from parrot.h to config.h)
# No prizes will be awarded for using Perl's config.h, or C preprocessor
# abuse. :)
I'm starting to do some hacking on this. (Hey, I can't sleep... :^) )
Since Perl 5 already has this stuff, it seems like it should be pretty
easy. (Famous last words?) The $64,000 question is, what do I have to
copy over? A simple "autogenerate what's already in Parrot's config.h"
is easy--I've already written a prototype (pasted after my sig)--but
seems like it's too easy considering what you're talking about. What
else does it need to do?
The prototype below properly defines IV and NV (most of the time) based
on Perl 5's IV and NV. It also sets up HAS_HEADER_FOO for each of the
i_ symbols in Config.pm. Let me know if I should change the symbol I
define. (If the comment line with my name in it seems improper, feel
free to remove it.)
I'm on Win32, so I don't have the tools to make a diff (I'm trying to
get PPT working) so you'll have to turn it into a patch yourself.
Sorry.
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
~~~
#!/usr/bin/perl -w
#we want -w on
#Configure.pl, written by Brent Dax
use strict;
use Config;
print <<"END";
Parrot Configure
Copyright (C) 2001 Yet Another Society
Since you're running this script, you obviously have
Perl 5--I'll be pulling some defaults from its configuration.
Rules are the same as Perl 5's Configure--defaults are in
square brackets, and you can hit enter to accept them.
END
#Some versions don't seem to have ivtype or nvtype--provide
#defaults for them.
#XXX Figure out better defaults
my($iv, $nv)=(($Config{ivtype}||'long'), ($Config{nvtype}||'long
double'));
my $input;
print "How big would you like integers to be? [$iv] ";
chomp($input=);
$iv=$input||$iv;
print "How about your floats? [$nv] ";
chomp($input=);
$nv=$input||$nv;
my($config_h)=<<"END_OF_CONFIG_H";
/* config.h
*
* Platform-specific config file
*
* DO NOT EDIT THIS FILE!
* This file was autogenerated by Configure.pl--please
* rerun that! Changes to this file may be lost!
*
*/
#if !defined(PARROT_CONFIG_H_GUARD)
#define PARROT_CONFIG_H_GUARD
typedef $iv IV
typedef $nv NV;
typedef struct _vtable VTABLE;
typedef void DPOINTER;
typedef void SYNC;
//typedef IV *(*opcode_funcs)(void *, void *) OPFUNC;
#define FRAMES_PER_CHUNK 16
#define FRAMES_PER_PMC_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_NUM_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_INT_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_STR_REG_CHUNK FRAMES_PER_CHUNK
#define MASK_CHUNK_LOW_BITS 0xf000
END_OF_CONFIG_H
print <<"END";
Okay. Now I'm gonna probe Perl 5's configuration to see
what headers you have around. This could take a bit on slow
machines...
END
#set up HAS_HEADER_
foreach(grep {/^i_/} keys %Config) {
$config_h.=defineifdef((/^i_(.*)$/));
}
$config_h.="\n#endif";
open(CONFIG_H, ">config.h");
print CONFIG_H $config_h;
print <<"END";
Okay, we're done!
You can now use `make test_prog' (or your platform's equivalent to
`make')
to build your Parrot. Happy Hacking,
The Parrot Team
END
sub defineifdef {
my $thing=shift;
if($Config{"i_$thing"}) {
return "#define HAS_HEADER_\U$thing\E\n";
}
else {
return "#undef HAS_HEADER_\U$thing\E\n"; #XXX do we want this?
}
}
RE: Configure system
Simon Cozens: # On Tue, Sep 11, 2001 at 02:22:13AM -0700, Brent Dax wrote: # > A simple "autogenerate what's already in Parrot's config.h" is easy # # This is a good start. # # > --I've already written a prototype (pasted after my sig)--but # > seems like it's too easy considering what you're talking # about. What # > else does it need to do? # # I'd rather it took a config.h.in or similar and slapped the IV/NV/etc. # typedefs in the middle. This means we can hack the template each time # we need it to change, instead of hacking the Perl script that # generates # config.h. Good idea. Why didn't I think of it? :^) # Thanks for working on this. No problem--I'm just helping the best way I can at this point. Attached are new Configure.pl and config.ht files. Feel free to rename config.ht if you want. (They may have Windows newlines, unless e-mail clients do some translating of those behind the scenes that I don't know about.) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet." Configure.pl config.ht
RE: Things we need to do.
Simon Cozens: # If you're looking for something to do, we *always* have good # little jobs for people. :) # # 1) See if there's a neat way of making the assembler #grok shortened forms of ops: # #add I1, I2, I3 => add_i I1, I2, I3 #print S1 => print_s S1 # # 2) Extend the Configure.pl system to autogenerate the #Makefile as well. Use Makefile.in as a template, and #fill in things like LIBS. I'll take care of Configure.pl. This will also give me a chance to let you select a different C compiler, which may help on Windows. (My system has a copy of gcc with DJGPP, but it's broken somehow--keeps complaining about compiling header files.) Does Perl 5's Configure know when to do the -lm stuff? Do I detect that by checking the compiler flags thing in %Config for /\b-lm\b/? # 3) Move all the header files to "include/" and have the #C source #include "parrot/include/" # # 4) Send me and Ben a patch to munge all the function names #to meet the coding standards. You could even send a Perl #script to do it! # # 5) Implement some more string encodings. docs/strings.pod #tells you what you need to do. # # 6) A test suite! My kingdom for a test suite! --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: Things we need to do.
Brent Dax:
# Sent: Thursday, September 13, 2001 14:17
# To: Simon Cozens; [EMAIL PROTECTED]
# Subject: RE: Things we need to do.
#
#
# Simon Cozens:
# # 2) Extend the Configure.pl system to autogenerate the
# #Makefile as well. Use Makefile.in as a template, and
# #fill in things like LIBS.
#
# I'll take care of Configure.pl. This will also give me a chance to let
# you select a different C compiler, which may help on Windows. (My
# system has a copy of gcc with DJGPP, but it's broken somehow--keeps
# complaining about compiling header files.)
It didn't take very long. Patch for Configure.pl below my sig (yes, I
finally did get PPT to work); delete Makefile and add the attached
Makefile.in.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
--- Configure.pl.oldThu Sep 13 15:34:06 2001
+++ Configure.plThu Sep 13 15:31:34 2001
@@ -1,7 +1,7 @@
#!/usr/bin/perl -w
#so we get -w
-#Configre.pl, written by Brent Dax
+#Configure.pl, written by Brent Dax
use strict;
use Config;
@@ -22,11 +22,18 @@
#defaults for them.
#XXX Figure out better defaults
my(%c)=(
- iv => ($Config{ivtype}||'long'),
- nv => ($Config{nvtype}||'long double')
+ iv => ($Config{ivtype}||'long'),
+ nv => ($Config{nvtype}||'long double'),
+ cc => $Config{cc},
+ ccflags => '-Wall -o $@',
+ libs => $Config{libs}
);
#inquire about numeric sizes
+
+prompt("What C compiler do you want to use?", 'cc');
+prompt("What flags would you like passed to your C compiler?",
'ccflags');
+prompt("Which libraries would you like your C compiler to include?" ,
'libs');
prompt("How big would you like integers to be?", 'iv');
prompt("How about your floats?", 'nv');
@@ -43,22 +50,16 @@
$c{headers}.=defineifdef((/^i_(.*)$/));
}
-#now let's assemble the config.h file
-my $config_h;
-{
- local $/;
- open(CONFIG_HT, ";
- close CONFIG_HT;
-}
+print <<"END";
-# ${field} is replaced with $c{field}
-$config_h =~ s/\$\{(\w+)\}/$c{$1}/g;
+Okay, that's finished. I'm now going to write your very
+own Makefile and config.h to disk.
+END
-#write out the config.h file
-open(CONFIG_H, ">config.h");
-print CONFIG_H $config_h;
-close CONFIG_H;
+#now let's assemble the config.h file
+buildfile("config.h");
+#and the makefile
+buildfile("Makefile");
print <<"END";
@@ -91,3 +92,17 @@
$c{$field}=$input||$c{$field};
}
+sub buildfile {
+ my($filename)=shift;
+
+ local $/;
+ open(IN, "<$filename.in");
+ my $text=;
+ close(IN);
+
+ $text =~ s/\$\{(\w+)\}/$c{$1}/g;
+
+ open(OUT, ">$filename");
+ print OUT $text;
+ close(OUT);
+}
Makefile.in
RE: Things we need to do.
Brad Hughes:
# Brent Dax wrote:
# [...]
# >
# > +sub buildfile {
# > + my($filename)=shift;
# > +
# > + local $/;
# > + open(IN, "<$filename.in");
#
# According to the coding guidelines PDD (which still doesn't seem
# to have been assigned a PDD number), filenames shouldn't have more
# than one '.' in them. I know this is a common Unixy Configure idiom,
# but it's nonportable, and portability is a goal of the Perl6 configure
# process[1]. May I suggest that after the first '.',
# subsequent '.'s be
# changed to '-'s:
Ask Simon, he's the one who came up with 'config.h.in' in the first
place. BTW, your example isn't portable to DOS--you can't have four
characters in the extension.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: Things we need to do.
I should have that ready in a bit. ITMT, don't apply my other patches--the next one will cover all of this. --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done. # -Original Message- # From: Simon Cozens [mailto:[EMAIL PROTECTED]] # Sent: Friday, September 14, 2001 01:41 # To: [EMAIL PROTECTED] # Subject: Re: Things we need to do. # # # On Thu, Sep 13, 2001 at 09:48:27PM -0400, Dan Sugalski wrote: # > Ah, I'm sure it was a slip 'o the keyboard. :) config.h_in # (or config_h.in) # > are both OK, and unique enough on 8.3 systems. # # Yeah, that was it! Brent, do you want to take care of that. # (config_h.in would be better, since it gets mindshare from the # current Perl 5 build process.) # # Simon
RE: Things we need to do.
Simon Cozens:
# Yeah, that was it! Brent, do you want to take care of that.
# (config_h.in would be better, since it gets mindshare from the
# current Perl 5 build process.)
Didn't take long--patch below sig. You'll also have to rename
config.h.in to config_h.in yourself.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
--- c:\old_parrot\Configure.pl Tue Sep 11 02:44:00 2001
+++ Configure.plFri Sep 14 02:02:10 2001
@@ -1,11 +1,18 @@
#!/usr/bin/perl -w
#so we get -w
-#Configre.pl, written by Brent Dax
+#Configure.pl, written by Brent Dax
use strict;
use Config;
+my($DDOK)=undef;
+eval {
+ require Data::Dumper;
+ Data::Dumper->import();
+ $DDOK=1;
+};
+
#print the header
print <<"END";
Parrot Configure
@@ -22,11 +29,17 @@
#defaults for them.
#XXX Figure out better defaults
my(%c)=(
- iv => ($Config{ivtype}||'long'),
- nv => ($Config{nvtype}||'long double')
+ iv => ($Config{ivtype}||'long'),
+ nv => ($Config{nvtype}||'long double'),
+ cc => $Config{cc},
+ ccflags => '-Wall -o $@',
+ libs => $Config{libs}
);
-#inquire about numeric sizes
+#ask questions
+prompt("What C compiler do you want to use?", 'cc');
+prompt("What flags would you like passed to your C compiler?",
'ccflags');
+prompt("Which libraries would you like your C compiler to include?" ,
'libs');
prompt("How big would you like integers to be?", 'iv');
prompt("How about your floats?", 'nv');
@@ -40,25 +53,22 @@
#set up HAS_HEADER_
foreach(grep {/^i_/} keys %Config) {
+ $c{$_}=$Config{$_};
$c{headers}.=defineifdef((/^i_(.*)$/));
}
-#now let's assemble the config.h file
-my $config_h;
-{
- local $/;
- open(CONFIG_HT, ";
- close CONFIG_HT;
-}
+print <<"END";
-# ${field} is replaced with $c{field}
-$config_h =~ s/\$\{(\w+)\}/$c{$1}/g;
+Okay, that's finished. I'm now going to write your very
+own Makefile, config.h, and Parrot::Config to disk.
+END
-#write out the config.h file
-open(CONFIG_H, ">config.h");
-print CONFIG_H $config_h;
-close CONFIG_H;
+#now let's assemble the config.h file
+buildfile("config_h");
+#and the makefile
+buildfile("Makefile");
+#and Parrot::Config
+buildconfigpm();
print <<"END";
@@ -91,3 +101,48 @@
$c{$field}=$input||$c{$field};
}
+sub buildfile {
+ my($filename)=shift;
+
+ local $/;
+ open(IN, "<$filename.in") or die "Can't open $filename.in: $!";
+ my $text=;
+ close(IN) or die "Can't close $filename.in: $!";
+
+ $text =~ s/\$\{(\w+)\}/$c{$1}/g;
+ $filename =~ s/_/./;#config_h => config.h
+
+ open(OUT, ">$filename") or die "Can't open $filename: $!";
+ print OUT $text;
+ close(OUT) or die "Can't close $filename: $!";
+}
+
+sub buildconfigpm {
+ unless($DDOK) {
+ print <<"END";
+
+Your system doesn't have Data::Dumper installed, so I couldn't
+build Parrot::Config. If you want Parrot::Config installed,
+use CPAN.pm to install Data::Dumper and run this script again.
+END
+
+ return;
+ }
+
+ my %C=%c;
+ delete $C{headers};
+ my $dd=new Data::Dumper([\%C]);
+ $dd->Names(['*PConfig']);
+
+ local $/;
+ open(IN, ";
+ close(IN) or die "Can't close Config.pm_in: $!";
+
+ $text =~ s/#DUMPER OUTPUT HERE/$dd->Dump()/eg;
+
+ mkdir("Parrot") or ( $! =~ /File exists/i or die "Can't make directory
./Parrot: $!");
+ open(OUT, ">Parrot/Config.pm") or die "Can't open file
Parrot/Config.pm: $!";
+ print OUT $text;
+ close(OUT) or die "Can't close file Parrot/Config.pm: $!";
+}
--- /dev/null Wed Dec 31 16:00:00 1969
+++ Config_pm.inThu Sep 13 23:40:00 2001
@@ -0,0 +1,14 @@
+package Parrot::Config;
+
+use strict;
+use warnings;
+use Exporter;
+
+use vars qw(@ISA @EXPORT %PConfig);
+@ISA=qw(Exporter);
+
+@EXPORT=qw(%PConfig);
+
+#DUMPER OUTPUT HERE
+
+1;
RE: parrot/config.h patch and others
Gibbs Tanton - tgibbs:
# Here is the parrot/config.h patch
#
# It fixes Makefile.in, but not in the correct way. Brent, if
# you could look
# at this and fix it the right way I would really appreciate it
# (note that I
# have no clue what the right way is :)
It's understandable that you couldn't find the right way--it was in
Configure.pl, not Makefile.in. In fact, that seems to be the only
change necessary--so I now present to you the full, complete, unabridged
patch for this feature:
--- c:\old_parrot\Configure.pl Fri Sep 14 08:06:22 2001
+++ Configure.plFri Sep 14 08:15:56 2001
@@ -28,11 +28,16 @@
#Some versions don't seem to have ivtype or nvtype--provide
#defaults for them.
#XXX Figure out better defaults
+#NOTE: This is the correct place to set defaults, not Makefile.in
+#or config_h.in.
my(%c)=(
iv => ($Config{ivtype}||'long'),
nv => ($Config{nvtype}||'long double'),
cc => $Config{cc},
- ccflags => $Config{ccflags},
+ #XXX This may not be correct, since we'll capture options like
+ #-DDEBUGGING too; however, this is what the version in CVS was
+ #like.
+ ccflags => $Config{ccflags}." -I..",
libs => $Config{libs}
);
:^)
As you can see, I also put in a note in the future for others who can't
find the right place to set defaults, as well as an XXX involving
whether we should 'inherit' ccflags at all.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
[patch README] Update README to reflect new Configure script
--- c:\old_parrot\READMEFri Sep 14 12:13:42 2001 +++ README Mon Sep 10 09:56:28 2001 @@ -34,11 +34,6 @@ For now, unpack your Parrot tarball, (if you're reading this, you've probably already done that) type + perl Configure.pl + +to run the Configure script. This will generate a config.h header, a +Parrot::Config module, and a Makefile. Next type + make test_prog and the test interpreter should build. --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: Half-completed parrot/parrot.h conversion?
Gibbs Tanton - tgibbs: # 1.) create an include/parrot directory under the main source directory # 2.) move all .h files into include/parrot # 3.) add -I./include to Configure.pl I'll take care of the Configure munging--I have an idea for how to work this. --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: Half-completed parrot/parrot.h conversion?
Gibbs Tanton - tgibbs:
# 1.) create an include/parrot directory under the main source directory
# 2.) move all .h files into include/parrot
# 3.) add -I./include to Configure.pl
The patch below my sig will handle the Configure side of things.
Include it in your own set of patches. Do not apply this until
everything else is ready for the switchover. Do not pass Go. Do not
collect $200. :^)
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
--- c:\old_parrot\Configure.pl Fri Sep 14 08:06:22 2001
+++ Configure.plFri Sep 14 12:35:56 2001
@@ -30,9 +30,10 @@
#XXX Figure out better defaults
my(%c)=(
iv => ($Config{ivtype}||'long'),
- nv => ($Config{nvtype}||'long double'),
+ nv => ($Config{nvtype}||'double'),
cc => $Config{cc},
- ccflags => $Config{ccflags},
+ #XXX Do we want to get flags like -DDEBUGGING from Perl 5?
+ ccflags => $Config{ccflags}."-I./include",
libs => $Config{libs}
);
@@ -64,12 +65,29 @@
END
#now let's assemble the config.h file
-buildfile("config_h");
+buildfile("config_h", "include/parrot");
#and the makefile
buildfile("Makefile");
#and Parrot::Config
-buildconfigpm();
+{
+ unless($DDOK) {
+ print <<"END";
+Your system doesn't have Data::Dumper installed, so I couldn't
+build Parrot::Config. If you want Parrot::Config installed,
+use CPAN.pm to install Data::Dumper and run this script again.
+END
+
+ last;
+ }
+
+ my $dd=new Data::Dumper([\%c]);
+ $dd->Names(['*PConfig']);
+ $c{dumped}=$dd->Dump;
+
+ buildfile("Config_pm", "Parrot");
+}
+
print <<"END";
Okay, we're done!
@@ -102,7 +120,7 @@
}
sub buildfile {
- my($filename)=shift;
+ my($filename, $path)=(@_); $path||='.';
local $/;
open(IN, "<$filename.in") or die "Can't open $filename.in: $!";
@@ -112,37 +130,8 @@
$text =~ s/\$\{(\w+)\}/$c{$1}/g;
$filename =~ s/_/./;#config_h => config.h
- open(OUT, ">$filename") or die "Can't open $filename: $!";
+ mkdir("$path", 0777) or ( $! =~ /File exists/i or die "Can't make
directory $path: $!");
+ open(OUT, ">$path/$filename") or die "Can't open $path/$filename: $!";
print OUT $text;
close(OUT) or die "Can't close $filename: $!";
}
-
-sub buildconfigpm {
- unless($DDOK) {
- print <<"END";
-
-Your system doesn't have Data::Dumper installed, so I couldn't
-build Parrot::Config. If you want Parrot::Config installed,
-use CPAN.pm to install Data::Dumper and run this script again.
-END
-
- return;
- }
-
- my %C=%c;
- delete $C{headers};
- my $dd=new Data::Dumper([\%C]);
- $dd->Names(['*PConfig']);
-
- local $/;
- open(IN, ";
- close(IN) or die "Can't close Config.pm_in: $!";
-
- $text =~ s/#DUMPER OUTPUT HERE/$dd->Dump()/eg;
-
- mkdir("Parrot", 0777) or ( $! =~ /File exists/i or die "Can't make
directory ./Parrot: $!");
- open(OUT, ">Parrot/Config.pm") or die "Can't open file
Parrot/Config.pm: $!";
- print OUT $text;
- close(OUT) or die "Can't close file Parrot/Config.pm: $!";
-}
--- c:\old_parrot\Config_pm.in Fri Sep 14 02:57:00 2001
+++ Config_pm.inFri Sep 14 12:26:20 2001
@@ -9,6 +9,6 @@
@EXPORT=qw(%PConfig);
-#DUMPER OUTPUT HERE
+${dumped}
1;
RE: [PATCH] testsuite and Win32 compilation
Mattia Barbon:
# > PLEASE can someone rewrite the tests to actually *test* things
# > and print "ok 1\n" and so on?
# Here it is ( for the second time )
#
# > Quick, or I'll call Schwern in.
# Ah, I thought you missed my patches, then I was correct
# both attached
...
(in things.diff)
# -C_FLAGS = ${ccflags} -I..
# +C_FLAGS = ${ccflags} -I.. ${cc_debug}
How did those -I..'s survive? Since we added include/parrot they're no
longer necessary; I suggest they be removed.
# +#if defined(WIN32)
# +program_code = malloc( file_stat.st_size );
# +#else
Should we be using malloc, or are we supposed to use our own allocator?
(I haven't been munging in the C, so I don't really know--it just looks
a little suspicious.)
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: RFC: Bytecode file format
Benjamin Stuhl: # --- Brian Wheeler <[EMAIL PROTECTED]> wrote: # > I've been thinking alot about the bytecode file format # > lately. Its # > going to get really gross really fast when we start # > adding other # > (optional) sections to the code. # > # > So, with that in mind, here's what I propose: # > # > * All data sizes are in longwords (4 bytes) because # > that's just the way # > things are :) # # We can't do that. There are platforms on both ends that # have _no_ native 32-bit data formats (Crays, some 16-bit # CPUs?). They still need to be able to load and generate # bytecode without ridiculuous CPU penalties (your Palm III # is not running on a 700MHz Pentium III, after all!) Er, Palm OS 3.5 has an Int32 data type. (Earlier Palms had that too, but it was named something else. Since most 32-bit processors have 64-bit integer types available, it makes sense that 16-bit processors would have 32-bit integers.) And I somewhat doubt that Crays will have problems with startup time. :^) --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: .pl extension
Paul Johnson: # Call me an old fuddy duddy if you will, or Unix-centric if # you must, but # the .pl extension historically refers to Perl Libraries, and even now # that is my first thought when I see it. # # Now I realise that many people working on this project have rarely, if # ever, used Perl 4 or earlier versions, and I also realise that many # people now use the .pl extension to refer to executable Perl scripts, # but I still wonder whether we shouldn't change the .pl extension. # # If an extension is required, the recommended extension is .plx, but I # question whether an extension is necessary at all. # # I don't really want to start a discussion about file associations, or # the adequacy or otherwise of any operating system, I am merely # suggesting that the .pl extension be removed or replaced. # # A counter argument might be that Perl 6 is seven or more years # subsequent to Perl 4 and it's about time we reused that extension. # Maybe that's one for the language bods. # # Other random points: # # - the .pl files are Perl 5 # - but some time they could be Perl 6 # - the .plx extension isn't prominent in the Perl 5 documentation # - a patch is probably not useful ;-) # # Anyway, just a suggestion before we get too many .pl files. The .pl extensions are meant to indicate that these are Perl scripts, not shell scripts (or C programs). Considering that Configure in Perl 5 is a shell script, it would make sense for people to assume Configure without an extension in Parrot is one too. The .pl makes people realize it's a Perl script; if we used .plx, some people might not understand what that was. (I can't really speak for the other scripts; Configure is my specialty.) Besides, ActivePerl on Win32 sets up file associations on .pl, not .plx. :^) --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: [proposed] Moving *.h to include/parrot/ right away
Gregor N. Purdy:
# With the appropriate modification to Makefile.in as well (diff
# attached)? I don't remember seeing anyone particularly upset by it.
# [[ UPDATE: REALLY ATTACHED THIS TIME ]]
The correct modification isn't in Makefile.in, it's in Configure.pl.
You'll want to change
ccflags => $Config{ccflags}
to
#ADD NEW C COMPILER FLAGS HERE
#Just add any additional flags into the quote marks.
#Leave any flags currently there as-is unless you're
#replacing them with something better.
ccflags => $Config{ccflags}." -I./include"
. (I'm not giving a diff here because it seems that things have gotten
really out of whack with Configure and associated files--everyone seems
to have their own versions floating around.) I also suggest we change
the line in Makefile.in that looks something like:
C_FLAGS = ${ccflags}
to exactly
#DO NOT ADD FLAGS HERE
#Add them in Configure.pl--search for the comment "ADD NEW C COMPILER
FLAGS HERE"
C_FLAGS = ${ccflags}
so people don't keep making the same mistakes.
# If not, I'd be happy to do it. It'll take just a few minutes...
I suggest you create the new directory structure in a tarball first, and
send it to myself and anyone else who's interested in this so we can
check it before you commit. This is a large change in the layout; there
are a thousand subtle ways to mess up without noticing it immediately.
Many eyes make bugs shallow, right? :^)
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: Difficulties
Will Coleda: # The README doesn't mention Configure.pl (minor doc patch follows), and # Parrot::Opcode is requiring perl5.6, which makes my 5.5.3 # quite unhappy. I think I sent in a patch to README to mention Configure.pl yesterday. Let's see if I can find it... # From: Brent Dax [mailto:[EMAIL PROTECTED]] # Sent: Friday, September 14, 2001 12:17 # To: [EMAIL PROTECTED] # Subject: [patch README] Update README to reflect new Configure script # # # --- c:\old_parrot\READMEFri Sep 14 12:13:42 2001 # +++ README Mon Sep 10 09:56:28 2001 # @@ -34,11 +34,6 @@ # For now, unpack your Parrot tarball, (if you're reading this, you've # probably already done that) type # # + perl Configure.pl # + # +to run the Configure script. This will generate a config.h header, a # +Parrot::Config module, and a Makefile. Next type # + # make test_prog # # and the test interpreter should build. Did nobody notice this? If so, why not? As for the 5.6 thing...I think we're supposed to support 5.005 and above. Can you tell what Parrot::Opcode needs it for? (And if it's for 'our', I'm going to punch someone... :^) ) --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
HOLD IT!
We're getting lost in a maze of twisty little Configure versions, all different. Can we get a freeze on changes to Configure and associated files until we can get this sorted out? --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: [PATCH] testsuite and Win32 compilation
Gibbs Tanton - tgibbs: # ## +#if defined(WIN32) # ## +program_code = malloc( file_stat.st_size ); # ## +#else # # Also, since more than win32 is not going to have mmap, # perhaps you could add # a Configure #define for HAS_MMAP or something like that. # Then you could # test the cc compiler to check for mmap availability. Configure sets up a bunch of HAS_HEADER_FOO macros in parrot/config.h, including HAS_HEADER_MEMORY (undef on my Win32 system). Would this be the correct file? --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: Difficulties
Damien Neil:
# On Sat, Sep 15, 2001 at 01:15:57AM -0700, Brent Dax wrote:
# > As for the 5.6 thing...I think we're supposed to support 5.005 and
# > above. Can you tell what Parrot::Opcode needs it for?
# (And if it's for
# > 'our', I'm going to punch someone... :^) )
#
# Er...I think it IS for our, actually. :> I'm so used to using it, I
# didn't realize I was introducing a 5.6ism. The silly thing is, I
# deliberately avoided using "open(my $fh, $file)" to keep from
# requiring
# 5.6...
*THWAP*
# I notice that someone did add a "use 5.6.0" to Parrot::Opcode--here's
# a patch which removes it, and the offending ours.
#
# Index: Parrot/Opcode.pm
# ===
# RCS file: /home/perlcvs/parrot/Parrot/Opcode.pm,v
# retrieving revision 1.3
# diff -u -r1.3 Opcode.pm
# --- Parrot/Opcode.pm 2001/09/15 00:57:42 1.3
# +++ Parrot/Opcode.pm 2001/09/15 08:33:48
# @@ -1,12 +1,11 @@
# package Parrot::Opcode;
#
# -use 5.6.0;
# use strict;
# use Symbol;
# use Digest::MD5 qw(&md5_hex);
use vars qw(%opcode $fingerprint); #or strict will throw a tantrum
#
# -our %opcode;
# -our $fingerprint;
# +my %opcode;
# +my $fingerprint;
#
# sub _load {
# my $file = @_ ? shift : "opcode_table";
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: Difficulties
Damien Neil: # On Sat, Sep 15, 2001 at 01:52:26AM -0700, Brent Dax wrote: # > use vars qw(%opcode $fingerprint); #or strict will throw a tantrum # # Not necessary--the patch changes those variables to lexicals. # There wasn't any strong reason for them to be package vars. Oh, duh... *smacks his forehead* --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: [PATCH] testsuite and Win32 compilation
Mattia Barbon:
# > ## +#if defined(WIN32)
# > ## +program_code = malloc( file_stat.st_size );
# > ## +#else
# >
# > #Should we be using malloc, or are we supposed to use our
# own allocator?
# > #(I haven't been munging in the C, so I don't really
# know--it just looks
# > #a little suspicious.)
# >
# > In memory.{h,c} there is a mem_sys_allocate(IV) that I
# would suggest.
# Of course you're right.
# New patch Attached
#
# The attached patch replaces things.diff ( testsuite.diff should be
# OK )
I've made some small changes, including some comments so people don't
keep putting new C compiler flags in the wrong place. Most of the other
changes were things like formatting. Patch attached. I'll commit this
myself if nobody has any objections. (Once this is committed, I'll work
on the parrot/config.h stuff, and merge that in to this patch.)
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: [PATCH] testsuite and Win32 compilation
Brent Dax:
# Mattia Barbon:
# # > ## +#if defined(WIN32)
# # > ## +program_code = malloc( file_stat.st_size );
# # > ## +#else
# # >
# # > #Should we be using malloc, or are we supposed to use our
# # own allocator?
# # > #(I haven't been munging in the C, so I don't really
# # know--it just looks
# # > #a little suspicious.)
# # >
# # > In memory.{h,c} there is a mem_sys_allocate(IV) that I
# # would suggest.
# # Of course you're right.
# # New patch Attached
# #
# # The attached patch replaces things.diff ( testsuite.diff should be
# # OK )
#
# I've made some small changes, including some comments so people don't
# keep putting new C compiler flags in the wrong place. Most
# of the other
# changes were things like formatting. Patch attached. I'll
# commit this
# myself if nobody has any objections. (Once this is
# committed, I'll work
# on the parrot/config.h stuff, and merge that in to this patch.)
Ack, forgot to actually *attach* the file...
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
--- parrot-cvs\parrot\Configure.pl Fri Sep 14 17:57:42 2001
+++ parrot\parrot\Configure.pl Sat Sep 15 16:01:18 2001
@@ -5,7 +5,36 @@
use strict;
use Config;
+use Getopt::Long;
+my( $opt_debugging, $opt_defaults, $opt_version, $opt_help ) =
+ ( 0, 0, 0, 0 );
+my( %opt_defines );
+my $result = GetOptions( 'debugging!' => \$opt_debugging,
+'defaults!' => \$opt_defaults,
+'version'=> \$opt_version,
+'help' => \$opt_help,
+'define=s' => \%opt_defines,
+ );
+
+if( $opt_version ) {
+ print '$Id:$' . "\n";
+ exit;
+}
+
+if( $opt_help ) {
+ print <<"EOT";
+$0 - Parrot Configure
+Options:
+ --debugging Enable debugging
+ --defaults Accept all default values
+ --define name=value Defines value name as value
+ --help This text
+ --versionShow assembler version
+EOT
+ exit;
+}
+
my($DDOK)=undef;
eval {
require Data::Dumper;
@@ -29,21 +58,48 @@
#defaults for them.
#XXX Figure out better defaults
my(%c)=(
- iv => ($Config{ivtype}||'long'),
- nv => ($Config{nvtype}||'long double'),
- cc => $Config{cc},
- ccflags => $Config{ccflags},
- libs => $Config{libs},
- perl => $^X,
+ iv => ($Config{ivtype}||'long'),
+ nv => ($Config{nvtype}||'double'),
+ cc => $Config{cc},
+ #ADD C COMPILER FLAGS HERE
+ ccflags => $Config{ccflags}." -I./include",
+ libs => $Config{libs},
+ perl => $^X,
+ cc_debug => '-g',
+ o =>'.o', # object files extension
+ exe => $Config{_exe},
+ ld => $Config{ld},
+ ld_out => '-o ', # ld output file
+ ld_debug => '', # include debug info in executable
+ debugging =>$opt_debugging,
);
+foreach my $i ( keys %opt_defines ) {
+ $c{$i} = $opt_defines{$i};
+}
+
+# set up default values
+my $hints = "hints/" . lc( $^O ) . ".pl";
+if( -f $hints ) {
+ local($/);
+ open HINT, "< $hints" or die "Unable to open hints file '$hints'";
+ my $hint = ;
+ close HINT;
+ eval $hint or die "Error in hints file $hints: '$@/$!'";
+}
+
#ask questions
prompt("What C compiler do you want to use?", 'cc');
+prompt("How about your linker?", 'ld');
prompt("What flags would you like passed to your C compiler?", 'ccflags');
prompt("Which libraries would you like your C compiler to include?", 'libs');
prompt("How big would you like integers to be?", 'iv');
-prompt("How about your floats?", 'nv');
+prompt("And your floats?", 'nv');
+unless( $c{debugging} ) {
+ $c{ld_debug} = ' ';
+ $c{cc_denug} = ' ';
+}
print <<"END";
@@ -95,6 +151,8 @@
#prompt for something from the user
sub prompt {
+ return if $opt_defaults;
+
my($message, $field)=(@_);
my($input);
print "$message [$c{$field}] ";
--- parrot-cvs\parrot\Makefile.in Fri Sep 14 17:57:42 2001
+++ parrot\parrot\Makefile.in Sat Sep 15 16:01:24 2001
@@ -1,21 +1,27 @@
-O =
RE: [PATCH] Win32 (resubmit)
# -Original Message-
# From: Mattia Barbon [mailto:[EMAIL PROTECTED]]
# Sent: Sunday, September 16, 2001 14:30
# To: [EMAIL PROTECTED]
# Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
# Subject: [PATCH] Win32 (resubmit)
#
#
# This patch adds:
# * Win32 compilation ( of course! )
# * Configure.pl
#--debugging Enable debugging
#--defaults Accept all default values
#--define name=value Defines value name as value
#--help This text
#--versionShow assembler version
#
# Support for hints files ( named hints/lc($^O).pl ).
# Support for debugging on *NIX/GCC, Win32/MSVC
#
# * Makes Opcodes.pm 5.005-happy
I'm applying this at least in spirit. The actual diff (not a context
diff, unfortunately) is after my sig. I'm also making Configure.pl
check the MANIFEST.
# P.S.: don't forget to cvs-add hints/mswin32.pl
I won't forget, even if it doesn't appear in the diff.
By the way, I got this to work as a project under Visual Studio 7 (with
a ton of fiddling and adding custom build steps). If anyone is as crazy
as me, feel free to ask for the project files.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
cvs server: Diffing .
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.5
diff -r1.5 Configure.pl
7a8,36
> use Getopt::Long;
>
> my( $opt_debugging, $opt_defaults, $opt_version, $opt_help ) = ( 0, 0,
0, 0 );
> my( %opt_defines );
> my $result = GetOptions(
> 'debugging!' => \$opt_debugging,
> 'defaults!' => \$opt_defaults,
> 'version'=> \$opt_version,
> 'help' => \$opt_help,
> 'define=s' => \%opt_defines,
> );
>
> if( $opt_version ) {
> print '$Id:$' . "\n";
> exit;
> }
>
> if( $opt_help ) {
> print <<"EOT";
> $0 - Parrot Configure
> Options:
>--debugging Enable debugging
>--defaults Accept all default values
>--define name=value Defines value name as value
>--help This text
>--versionShow assembler version
> EOT
> exit;
> }
24,25c53,54
< Rules are the same as Perl 5's Configure--defaults are in
< square brackets, and you can hit enter to accept them.
---
> First, I'm gonna check the manifest, to make sure you got a
> complete Parrot kit.
27a57,58
> check_manifest();
>
32,37c63,76
< iv => ($Config{ivtype}||'long'),
< nv => ($Config{nvtype}||'long double'),
< cc => $Config{cc},
< ccflags => $Config{ccflags},
< libs => $Config{libs},
< perl => $^X,
---
> iv => ($Config{ivtype}||'long'),
> nv => ($Config{nvtype}||'double'),
> cc => $Config{cc},
> #ADD C COMPILER FLAGS HERE
> ccflags => $Config{ccflags}." -I.. -I./include",
> libs => $Config{libs},
> perl => $^X,
> cc_debug => '-g',
> o =>'.o', # object files extension
> exe => $Config{_exe},
> ld => $Config{ld},
> ld_out => '-o ', # ld output file
> ld_debug => '', # include debug info in executable
> debugging =>$opt_debugging,
39a79,92
> foreach my $i ( keys %opt_defines ) {
> $c{$i} = $opt_defines{$i};
> }
>
> # set up default values
> my $hints = "hints/" . lc( $^O ) . ".pl";
> if( -f $hints ) {
> local($/);
> open HINT, "< $hints" or die "Unable to open hints file '$hints'";
> my $hint = ;
> close HINT;
> eval $hint or die "Error in hints file $hints: '$@/$!'";
> }
>
41a95
> prompt("How about your linker?", 'ld');
45c99
< prompt("How about your floats?", 'nv');
---
> prompt("And your floats?", 'nv');
46a101,104
> unless( $c{debugging} ) {
> $c{ld_debug} = ' ';
> $c{cc_denug} = ' ';
> }
97a156,157
> return if $opt_defaults;
>
149a210,242
>
> sub check_manifest {
> my $not_ok;
> open(MANIFEST, "MANIFEST");
>
> while() {
> chomp;
> unless(-e
RE: [PATCH]Makefile.in
Robert Spier: # Gibbs Tanton - tgibbs writes: # >Ok, here is the rule based makefile... # # Thanks # # Looks good (and works for me.) # # I suggest the following patch on top of Gibbs' patch, to seperate form # and function of CC and CFLAGS. (Also, the "standard" (fwiw) is # CFLAGS, not C_FLAGS) Thanks, both applied. (It's so cool to say that! :^) ) --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: parrot-nightly
I applied this fairly recently; it may be helpful for a parrot-nightly. C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot>perl Configure.pl --help Configure.pl - Parrot Configure Options: --debugging Enable debugging --defaults Accept all default values --define name=value Defines value name as value --help This text --versionShow assembler version C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot>perl Configure.pl --defaults Parrot Configure Copyright (C) 2001 Yet Another Society Since you're running this script, you obviously have Perl 5--I'll be pulling some defaults from its configuration. First, I'm gonna check the manifest, to make sure you got a complete Parrot kit. Okay, we found everything. Next you'll need to answer a few questions about your system. Rules are the same as Perl 5's Configure--defaults are in square brackets, and you can hit enter to accept them. Okay. Now I'm gonna probe Perl 5's configuration to see what headers you have around. This could take a bit on slow machines... Okay, that's finished. I'm now going to write your very own Makefile, config.h, and Parrot::Config to disk. Okay, we're done! You can now use `make test_prog' (or your platform's equivalent to `make') to build your Parrot. Happy Hacking, The Parrot Team --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done. H.Merijn Brand: # I've waited till either Configure or make would do something # sensible, and I'm # also aware that parrot-nightly isn't stable. Does # perl6-internals value input # like this (on a regular basis) or not. # # Either way, is there a point in time that parrot is released # as pseodo-stable # snapshots like Jarkko does with perl5? # # l1:/pro/3gl/CPAN/parrot-nightly 106 > make # perl Configure.pl # Parrot Configure # Copyright (C) 2001 Yet Another Society # # Since you're running this script, you obviously have # Perl 5--I'll be pulling some defaults from its configuration. # # First, I'm gonna check the manifest, to make sure you got a # complete Parrot kit. # # Okay, we found everything. Next you'll need to answer # a few questions about your system. Rules are the same # as Perl 5's Configure--defaults are in square brackets, # and you can hit enter to accept them. # # What C compiler do you want to use? [cc] # How about your linker? [ld] # What flags would you like passed to your C compiler? [ # -DDEBUGGING -Ae -D_HPUX_S # OURCE -I/pro/local/include -D_LARGEFILE_SOURCE # -D_FILE_OFFSET_BITS=64 -I.. -I./ # include] # Which libraries would you like your C compiler to include? # [-lnsl -lnm -lndbm -l # gdbm -ldb -ldld -lm -lc -lndir -lcrypt -lsec] # How big would you like integers to be? [long] # And your floats? [double] # # Okay. Now I'm gonna probe Perl 5's configuration to see # what headers you have around. This could take a bit on slow # machines... # # Okay, that's finished. I'm now going to write your very # own Makefile, config.h, and Parrot::Config to disk. # # Okay, we're done! # You can now use `make test_prog' (or your platform's # equivalent to `make') # to build your Parrot. # # Happy Hacking, # The Parrot Team # perl make_op_header.pl opcode_table > op.h # Can't locate Parrot/Opcode.pm in @INC (@INC contains: # /pro/lib/perl5/5.6.1/PA-RI # SC2.0 /pro/lib/perl5/5.6.1 # /pro/lib/perl5/site_perl/5.6.1/PA-RISC2.0 /pro/lib/pe # rl5/site_perl/5.6.1 /pro/lib/perl5/site_perl .) at # make_op_header.pl line 6. # BEGIN failed--compilation aborted at make_op_header.pl line 6. # make: *** [op.h] Error 2 # l1:/pro/3gl/CPAN/parrot-nightly 107 > # # -- # H.Merijn BrandAmsterdam Perl Mongers # (http://www.amsterdam.pm.org/) # using perl-5.6.1, 5.7.1 & 629 on HP-UX 10.20 & 11.00, AIX # 4.2, AIX 4.3, # WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: # [EMAIL PROTECTED] # http:[EMAIL PROTECTED]/ # [EMAIL PROTECTED] # send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
[PATCH Makefile.in] RE: [doughera@lafayette.edu: Re: bytecode and sizeof(IV)]
Easy Makefile.in patch. I was worried that Win32 might need the linker
(the change to $(LD) was submitted as part of a Win32 compatibility
patch) but that doesn't seem to be the case. I don't have a MinGW
toolkit installed, however--can someone check that it works there? It
also works on a BSD box, so I'm applying.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
--- ..\..\parrot-cvs\parrot\Makefile.in Tue Sep 18 10:54:52 2001
+++ Makefile.in Tue Sep 18 10:53:54 2001
@@ -28,7 +28,7 @@
$(CC) -shared $(C_LIBS) -o $@ $(O_FILES)
$(TEST_PROG): test_main$(O) $(O_FILES)
- $(LD) $(C_LIBS) ${ld_debug} ${ld_out}$(TEST_PROG) $(O_FILES)
test_main$(O)
+ $(CC) $(C_LIBS) $(CFLAGS) -o $(TEST_PROG) $(O_FILES)
test_main$(O)
test_main$(O): $(H_FILES)
RE: [PATCH] Tiny Configure patch
Andy Dougherty: # Now that the *.h files are in their correct home, we don't need # the -I.. flag. It could even pick up *wrong* versions of the # header files # in a neighboring directory. Thanks, applied. --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: [PATCH] Win32/perl 5.004/other
Mattia Barbon:
# This patch contains different things.
# If you prefer three smaller patches,
# just speak, I'll resend.
#
# * Configure.pl
# * 5.004_04 does not have $Config{_o}, $Config{_exe},
# use obj_ext, and exe_ext
# * Use ExtUtils::Manifest for manifest parsing
# ( now you can put blank lines/comments/
# file descriptions in MANIFEST )
# * add rm_f configuration variable
# ( WIndows, as usual, is different )
# * MANIFEST, MANIFEST.SKIP
# * updates, skip CVS-related files
# in fullcheck
# * Makefile.in
# * some cleanup
# * new targets:
# distclean, to remove configure-generated files
# fullcheck, to do a ExtUtils::Manifest::fullcheck
# * hints/mswin32.pl
# * added rm_f
# * test_main.c
# * renamed _read to read
I can't speak for the C bits, but the Configure and Friends changes look
okay. Someone else should check the C stuff (and maybe double-check the
MANIFEST and MANIFEST.SKIP changes) before it's applied.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: A task for the interested
Dan Sugalski:
# One of the things that the configure script needs to do is
# generate the
# opcode dispatch macro to either be a giant switch statement (with a
# fallthrough default to handle cases we don't know about) or
# the function
# table dispatch we have now.
If somebody codes up the alternate dispatch, I can easily modify
Configure.pl, config_h.in and the hints files to handle it. Something
like this, perhaps:
#define USE_${dispatch}_DISPATCH
#ifdef USE_switch_DISPATCH
#define DISPATCHER
#else
#define DISPATCHER
#endif
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: A task for the interested
Simon Cozens:
# On Tue, Sep 18, 2001 at 02:32:32PM -0700, Brent Dax wrote:
# > If somebody codes up the alternate dispatch, I can easily modify
# > Configure.pl, config_h.in and the hints files to handle it.
# Something
# > like this, perhaps:
#
# Something like that, but the Right Way would be to rewrite DO_OP in
# interp_guts.h
So, something more like this?
~~
--- ..\..\parrot-cvs\parrot\config_h.in Fri Sep 14 09:40:36 2001
+++ config_h.in Tue Sep 18 14:44:48 2001
@@ -24,7 +24,14 @@
#define MASK_CHUNK_LOW_BITS 0xf000
+#define USE_DISPATCH_${dispatch}
+#ifdef USE_DISPATCH_SWITCH
+# undef DO_OP
+# define DO_OP
+#endif
+
+
${headers}
--- ..\..\parrot-cvs\parrot\build_interp_starter.pl Tue Sep 18
10:54:52 2001
+++ build_interp_starter.pl Tue Sep 18 14:48:26 2001
@@ -59,12 +59,13 @@
#
print INTERP <opcode_funcs; \\
-(void *)y = x[*w]; \\
-w = (y)(w,z); \\
- } while (0);
+#ifndef DO_OP
+# define DO_OP(w,x,y,z) do { \\
+ x = (void *)z->opcode_funcs; \\
+ (void *)y = x[*w]; \\
+ w = (y)(w,z); \\
+} while (0);
+#endif
EOI
# Spit out the OPCODE_FINGERPRINT macro
~~~
(With, of course, the correct code put in config_h.in, and various
changes and additions to the hints/ folder to automagically suggest the
right dispatch to use.)
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: A task for the interested
Simon Cozens:
# On Tue, Sep 18, 2001 at 02:51:35PM -0700, Brent Dax wrote:
# > So, something more like this?
#
# Urh, how can I put this? No.
#
# I *really* want to avoid macro hackery - undef'ing this and
# then testing if it's defined and then redefining it, and
# urgh, urgh, urgh. No.
#
# I was thinking more like:
#
# > +++ build_interp_starter.pl Tue Sep 18 14:48:26 2001
# > @@ -59,12 +59,13 @@
# > #
# >
# if ($Config{dispatch} eq "fpointer") {
# > print INTERP < -#define DO_OP(w,x,y,z) do { \\
# > -x = (void *)z->opcode_funcs; \\
# > -(void *)y = x[*w]; \\
# > -w = (y)(w,z); \\
# > - } while (0);
# > EOI
# } elsif ($config{dispatch} eq "switch") {
#print INTERP <
RE: bytecode and sizeof(IV)
Russ Allbery: # Simon Cozens <[EMAIL PROTECTED]> writes: # # > Yep, and the latest "pedantic" patch doesn't help. Also, I'm seeing # > this, which is weird: # # > ld -ldbm -ldb -lm -liconv -o test_prog global_setup.o # interpreter.o parrot.o register.o basic_opcodes.o memory.o # bytecode.o string.o strnative.o test_main.o # # Definitely bugs in Configure there; cc has to be used as the # linker or -lc # isn't added (and possibly some of the other crt.o files too), and # libraries have to be after all the object files. I've already patched Makefile.in to fix this. --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
autotest
Okay, here's the results of my lame imitation of smoke testing--a script (highly customized for my machine) called autotest. Summary- --- VC7 Normal: BROKEN VC7 Debugging: BROKEN Details- --- Configuration VC7 Normal is BROKEN. Step: make test STDOUT output: C:\Perl\bin\perl.exe t/harness t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerdubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 1, 26 Failed 2/26 tests, 92.31% okay t/op/number.dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/23 tests, 95.65% okay (-2 skipped tests: 20 okay, 86.96%) t/op/string.ok, 1/5 skipped: I'm unable to write it! t/op/trans..ok Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/integer.t2 512262 7.69% 1 26 t/op/number.t 1 256231 4.35% 1 4 subtests skipped. STDERR output: # Failed test (Parrot/Test.pm at line 73) # got: '' # expected: '305419896 -1698898191 2147483647 -2147483648 -1 ' # Failed test (Parrot/Test.pm at line 73) # got: '' # expected: ' ' # Looks like you failed 2 tests of 26. # Failed test (Parrot/Test.pm at line 73) # got: '' # expected: '1.00 4.00 16.00 64.00 256.00 1024.00 4096.00 16384.00 65536.00 262144.00 1048576.00 4194304.00 16777216.00 67108864.00 268435456.00 1073741824.00 4294967296.00 17179869184.00 68719476736.00 274877906944.00 1099511627776.00 4398046511104.00 17592186044416.00 70368744177664.00 281474976710656.00 1125899906842620.00 4503599627370500.00 18014398509482000.00 72057594037927904.00 288230376151712000.00 1152921504606850048.00 4611686018427389952.00 ' # Looks like you failed 1 tests of 23. Failed 2/5 test scripts, 60.00% okay. 3/74 subtests failed, 95.95% okay. NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0xff' Stop. Configuration VC7 Debugging is BROKEN. Step: make test STDOUT output: C:\Perl\bin\perl.exe t/harness t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerdubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 1, 26 Failed 2/26 tests, 92.31% okay t/op/number.dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/23 tests, 95.65% okay (-2 skipped tests: 20 okay, 86.96%) t/op/string.ok, 1/5 skipped: I'm unable to write it! t/op/trans..ok Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/integer.t2 512262 7.69% 1 26 t/op/number.t 1 256231 4.35% 1 4 subtests skipped. STDERR output: # Failed test (Parrot/Test.pm at line 73) # got: '' # expected: '305419896 -1698898191 2147483647 -2147483648 -1 ' # Failed test (Parrot/Test.pm at line 73) # got: '' # expected: ' ' # Looks like you failed 2 tests of 26. # Failed test (Parrot/Test.pm at line 73) # got: '' # expected: '1.00 4.00 16.00 64.00 256.00 1024.00 4096.00 16384.00 65536.00 262144.00 1048576.00 4194304.00 16777216.00 67108864.00 268435456.00 1073741824.00 4294967296.00 17179869184.00 68719476736.00 274877906944.00 1099511627776.00 4398046511104.00 17592186044416.00 70368744177664.00 281474976710656.00 1125899906842620.00 4503599627370500.00 18014398509482000.00 72057594037927904.00 288230376151712000.00 1152921504606850048.00 4611686018427389952.00 ' # Looks like you failed 1 tests of 23. Failed 2/5 test scripts, 60.00% okay. 3/74 subtests failed, 95.95% okay. NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0xff' Stop. --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: autotest
Brent Dax: # Okay, here's the results of my lame imitation of smoke # testing--a script # (highly customized for my machine) called autotest. Here's the results of a run on FreeBSD. It looks like something is broken in the integer test. (It's not my script--I get the same errors when I run `make test' manually.) --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done. autotest started at Wed Sep 19 00:00:36 2001. Starting CVS update...done. Summary- --- GCC/FreeBSD Normal: BROKEN GCC/FreeBSD Debugging: BROKEN Details- --- Configuration GCC/FreeBSD Normal is BROKEN. Step: make test STDOUT output: perl t/harness t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/26 tests, 96.15% okay t/op/number.ok, 2/23 skipped: various reasons t/op/string.ok, 1/5 skipped: I'm unable to write it! t/op/trans..ok Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/integer.t1 256261 3.85% 1 4 subtests skipped. *** Error code 2 Stop in /usr/home/brentdax/parrot. STDERR output: # Failed test (Parrot/Test.pm at line 73) # got: '305419896 -1698898191 2147483647 -2147483648 2147483647 ' # expected: '305419896 -1698898191 2147483647 -2147483648 -1 ' # Looks like you failed 1 tests of 26. Failed 1/5 test scripts, 80.00% okay. 1/74 subtests failed, 98.65% okay. Configuration GCC/FreeBSD Debugging is BROKEN. Step: make test STDOUT output: perl t/harness t/op/basic..ok, 1/2 skipped: label constants unimplemented in assembler t/op/integerdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/26 tests, 96.15% okay t/op/number.ok, 2/23 skipped: various reasons t/op/string.ok, 1/5 skipped: I'm unable to write it! t/op/trans..ok Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/integer.t1 256261 3.85% 1 4 subtests skipped. *** Error code 2 Stop in /usr/home/brentdax/parrot. STDERR output: # Failed test (Parrot/Test.pm at line 73) # got: '305419896 -1698898191 2147483647 -2147483648 2147483647 ' # expected: '305419896 -1698898191 2147483647 -2147483648 -1 ' # Looks like you failed 1 tests of 26. Failed 1/5 test scripts, 80.00% okay. 1/74 subtests failed, 98.65% okay.
RE: [PATCH] changing IV to opcode_t!!
Andy Dougherty:
# On Wed, 19 Sep 2001, Brent Dax wrote:
#
# > Andy Dougherty:
# > ...
# > # +prompt("And what is sizeof(iv)?", 'ivsize');
# > # prompt("And your floats?", 'nv');
# > # +prompt("And what is sizeof(nv)?", 'nvsize');
# > ...
# >
# > Somehow, this seems like something we ought to be able to do
# > programmatically. Can't we just compile a quick little C
# program with
# > something like:
# >
# > printf("%d/%d", sizeof(${iv}), sizeof(${nv}));
# >
# > in it, and then parse the output? I don't like asking
# users stuff like
# > their int sizes--too prone to confusion and mistyping.
#
# Oh, sure, though I wouldn't worry too much about current
# Parrot "users"
# being unable to handle such things -- for the most part it'll
Hey, even the best programmer can accidentally hit 7 instead of 4 (see
your numeric pad). We should ask as little as possible (without losing
flexibility), and infer everything else.
# pick them up
# correctly from the Configure defaults from the perl5 being
# used to build
# Parrot. (If run as part of an automated smoke test, for
# example, we'll
# possibly pick up all sorts of 32/64 permutations.)
#
# However, you're right. The Configure mechanism ought to be able to
# compile and run a small program. The interface for doing
# that ought to be
# set up before too much effort is made splicing it in ad-hoc. Having
# someone else do that hard work has been one of my main goals :-).
I'll work on it later today.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: [PATCH] changing IV to opcode_t!!
Andy Dougherty:
...
# +prompt("And what is sizeof(iv)?", 'ivsize');
# prompt("And your floats?", 'nv');
# +prompt("And what is sizeof(nv)?", 'nvsize');
...
Somehow, this seems like something we ought to be able to do
programmatically. Can't we just compile a quick little C program with
something like:
printf("%d/%d", sizeof(${iv}), sizeof(${nv}));
in it, and then parse the output? I don't like asking users stuff like
their int sizes--too prone to confusion and mistyping.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: [PATCH] changing IV to opcode_t!!
Brent Dax:
# I'll work on it later today.
Patch below sig. I don't know if (or even really think that) this will
apply cleanly--I haven't updated my CVS in a while--but I don't expect
this to go in until after 0.02. This is basically just to show you what
I'm thinking. Let me know if my thought process is flawed.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
--- ..\..\parrot-cvs\parrot\Configure.plTue Sep 18 11:32:06 2001
+++ Configure.plThu Sep 20 01:48:06 2001
@@ -62,6 +62,8 @@
my(%c)=(
iv => ($Config{ivtype}||'long'),
nv => ($Config{nvtype}||'double'),
+ ivsize => undef, #filled in later in
program
+ nvsize => undef, #ditto
cc => $Config{cc},
#ADD C COMPILER FLAGS HERE
ccflags => $Config{ccflags}." -I./include",
@@ -118,6 +120,17 @@
print <<"END";
+Alright, I'm now gonna compile and run a little C program
+to figure some stuff out.
+END
+
+buildfile("test_c");
+system("$c{cc} test.c $c{ccflags} -o test$c{exe}") and die "Compilation
of test.c unsuccessful";
+@c{qw(ivsize nvsize)}=(`test$c{exe}` =~ m{(\d+)/(\d+)});
+unlink('test$c{exe}', 'test.c');
+
+print <<"END";
+
Okay, that's finished. I'm now going to write your very
own Makefile, config.h, and Parrot::Config to disk.
END
--- ..\..\parrot-cvs\parrot\config_h.in Fri Sep 14 09:40:36 2001
+++ config_h.in Thu Sep 20 01:44:36 2001
@@ -6,8 +6,12 @@
#if !defined(PARROT_CONFIG_H_GUARD)
#define PARROT_CONFIG_H_GUARD
+
typedef ${iv} IV;
+#define ivsize ${ivsize}
+
typedef ${nv} NV;
+#define nvsize ${nvsize}
typedef struct _vtable VTABLE;
typedef void DPOINTER;
@@ -24,7 +28,6 @@
#define MASK_CHUNK_LOW_BITS 0xf000
-
${headers}
--- /dev/null Wed Dec 31 16:00:00 1969
+++ test_c.in Thu Sep 20 01:31:36 2001
@@ -0,0 +1,6 @@
+#include
+
+int main(int argc, char **argv) {
+ printf("%d/%d", sizeof(${iv}), sizeof(${nv}));
+ return 0;
+}
RE: [PATCH] changing IV to opcode_t!!
Simon Cozens:
# On Thu, Sep 20, 2001 at 01:50:04AM -0700, Brent Dax wrote:
# > +int main(int argc, char **argv) {
# > + printf("%d/%d", sizeof(${iv}), sizeof(${nv}));
# > + return 0;
# > +}
#
# $Config{ivsize} not good enough for ya, then? :)
No, because the user may have chosen a different value for IV. For
example, I may have chosen 'long long' in Perl 5 but 'long' in Parrot to
be safe (IIRC, we're still having 64-bit issues). Thus, we can't depend
on $Config{ivsize}. Thus, a little bit of C is necessary to check for
us. Thus, I am very tired, since I'm talking like this. I should go to
sleep. Goodnight.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: question about branching/returning
Damien Neil: # "RETURN(0);" (written exactly like that, no variation permitted) # is a special case, and terminates the runops loop. The only op # which uses this is "end", and it doesn't actually ever execute. # Personally, I feel that this special case should be removed. We should probably just check if the thing returned 0 and exit runops if that's the case. This will also protect us against utter stupidity like: FOO:jump FOO which wouldn't be a bad thing to protect against. --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
Backslashes in $PConfig{perl}
Configuration VC7 Normal is BROKEN. Step: make test STDOUT output: C:\Perl\bin\perl.exe t/harness t/op/basic..dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/2 tests, 50.00% okay (-1 skipped test: 0 okay, 0.00%) t/op/integerdubious Test returned status 26 (wstat 6656, 0x1a00) DIED. FAILED tests 1-26 Failed 26/26 tests, 0.00% okay t/op/number.dubious Test returned status 21 (wstat 5376, 0x1500) DIED. FAILED tests 1-19, 21, 23 Failed 21/23 tests, 8.70% okay (-2 skipped tests: 0 okay, 0.00%) t/op/string.dubious Test returned status 4 (wstat 1024, 0x400) DIED. FAILED tests 1-3, 5 Failed 4/5 tests, 20.00% okay (-1 skipped test: 0 okay, 0.00%) t/op/trans..dubious Test returned status 18 (wstat 4608, 0x1200) DIED. FAILED tests 1-18 Failed 18/18 tests, 0.00% okay Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/basic.t 1 256 21 50.00% 1 t/op/integer.t 26 665626 26 100.00% 1-26 t/op/number.t21 537623 21 91.30% 1-19 21 23 t/op/string.t 4 1024 54 80.00% 1-3 5 t/op/trans.t 18 460818 18 100.00% 1-18 4 subtests skipped. STDERR output: 'C:Perlinperl.exe' is not recognized as an internal or external command, operable program or batch file. # Failed test (Parrot/Test.pm at line 74) # got: 'can't stat t/op/basic1.pbc, code 2 ' # expected: '42' # Looks like you failed 1 tests of 2. ... It looks like the backslashes in the path are being interpreted incorrectly. I don't think the problem is in Configure; can somebody look at it? --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: [PATCH] Fixed typo in Configure.pl
Stefan Dragnev:
# - $c{cc_denug} = ' ';
# + $c{cc_debug} = ' ';
So *that*'s why -g kept appearing...thanks, applied.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
[PATCH] Fix ivsize and nvsize issues
Okay, this fixes the issues with changing your IV or NV size. It also
provides an early warning if your C compiler settings aren't okay. I've
also made the style of the code a little more consistent. I'm applying
this, but I figure people might as well check it over anyway.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
--- ..\..\parrot-cvs\parrot\Configure.plThu Sep 20 21:14:30 2001
+++ Configure.plThu Sep 20 21:24:56 2001
@@ -6,9 +6,10 @@
use strict;
use Config;
use Getopt::Long;
+use ExtUtils::Manifest qw(manicheck);
-my( $opt_debugging, $opt_defaults, $opt_version, $opt_help ) = ( 0, 0,
0, 0 );
-my( %opt_defines );
+my($opt_debugging, $opt_defaults, $opt_version, $opt_help) = (0, 0, 0,
0);
+my(%opt_defines);
my $result = GetOptions(
'debugging!' => \$opt_debugging,
'defaults!' => \$opt_defaults,
@@ -17,12 +18,12 @@
'define=s' => \%opt_defines,
);
-if( $opt_version ) {
+if($opt_version) {
print '$Id: Configure.pl,v 1.12 2001/09/21 01:43:50 brentdax Exp
$' . "\n";
exit;
}
-if( $opt_help ) {
+if($opt_help) {
print <<"EOT";
$0 - Parrot Configure
Options:
@@ -54,39 +55,43 @@
complete Parrot kit.
END
-#check_manifest();
+check_manifest();
#Some versions don't seem to have ivtype or nvtype--provide
#defaults for them.
#XXX Figure out better defaults
my(%c)=(
iv => ($Config{ivtype} ||'long'),
-ivsize => ($Config{ivsize} || 4 ),
-longsize => ($Config{longsize} || 4 ),
+ ivsize => undef,
+
nv => ($Config{nvtype} ||'double'),
-nvsize => ($Config{nvsize} || 8 ),
-opcode_t => ($Config{ivtype} ||'long'),
+ nvsize => undef,
+
+ opcode_t => ($Config{ivtype} ||'long'),
+ longsize => undef,
+
cc => $Config{cc},
#ADD C COMPILER FLAGS HERE
ccflags => $Config{ccflags}." -I./include",
libs => $Config{libs},
- perl => $^X,
cc_debug => '-g',
o =>'.o', # object files extension
exe => $Config{_exe},
+
ld => $Config{ld},
ld_out => '-o ', # ld output file
ld_debug => '', # include debug info in
executab
le
+
+ perl => $^X,
debugging =>$opt_debugging,
);
-foreach my $i ( keys %opt_defines ) {
- $c{$i} = $opt_defines{$i};
-}
+#copy the things from --define foo=bar
+@c{keys %opt_defines}=@opt_defines{keys %opt_defines};
# set up default values
-my $hints = "hints/" . lc( $^O ) . ".pl";
-if( -f $hints ) {
+my $hints = "hints/" . lc($^O) . ".pl";
+if(-f $hints) {
local($/);
open HINT, "< $hints" or die "Unable to open hints file
'$hints'";
my $hint = ;
@@ -123,6 +128,17 @@
print <<"END";
+Alright, now I'm gonna check some stuff by compiling and running
+a small C program. This could take a bit...
+END
+
+buildfile("test_c");
+system("$c{cc} $c{ccflags} -o test$c{exe} test.c") and die "C compiler
died!";
+(@c{qw(ivsize opsize nvsize)})=split('/', `test$c{exe}`);
+unlink('test.c', "test$c{exe}");
+
+print <<"END";
+
Okay, that's finished. I'm now going to write your very
own Makefile, config.h, and Parrot::Config to disk.
END
@@ -208,36 +224,29 @@
$text =~ s/#DUMPER OUTPUT HERE/$dd->Dump()/eg;
- mkdir("Parrot", 0777) or ( $! =~ /File exists/i or die "Can't
make direc
tory ./Parrot: $!");
open(OUT, ">Parrot/Config.pm") or die "Can't open file
Parrot/Config.pm:
$!";
print OUT $text;
close(OUT) or die "Can't close file Parrot/Config.pm: $!";
}
sub check_manifest {
- my $not_ok;
- open(MANIFEST, "MANIFEST");
+ print "\n";
- while() {
- chomp;
- unless(-e $_) {
- print "File $_ is missing!\n";
- $not_ok=1;
- }
- }
+ my(@missing)=manicheck();
- if($not_ok) {
+ if(@missing) {
print <<"END";
Ack, some files were missing! I can't continue running
without everything here. Please try to find the above
files and then try runni
RE: _read => read
Damien Neil: # test_main.c still seems to contain a call to _read(), rather than # read(). This breaks compilation under Tru64 for me; the attached # patch removes the _. Since this (I think) has been submitted multiple times and never applied (and no reason was given for not applying), I've applied it myself. Thanks, Damien. --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: Parrot Smoke Sep 20 00:00:02 2001 MSWin32 4.0
Mattia Barbon:
# Automated smoke report for patch Sep 20 00:00:02 2001
# v0.01 on MSWin32 using cl version
...
# MSWin32 --defaults --define iv=int --define nv=float
# MSWin32 --debugging --defaults --define iv=int --define nv=float
# t/op/integerdubious DIED. FAILED test 25
# t/op/number.dubious DIED. FAILED tests 1-5, 9-18, 23
# t/op/trans..dubious DIED. FAILED tests 1-18
...
Can you manually run ${your_make_here} test and try to figure out what's
going on? Specifically, does it give you anything like:
'C:Perinperl.exe' is not recognized as an internal or external command,
operable program or batch file.
like it does on my system? (Explanation: what does 'print
"C:\Perl\bin\perl.exe"' give you? (Although that's only half the story,
and I can't figure out where the other half of the story lies...))
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: [PATCH] Fix ivsize and nvsize issues
On Behalf Of Ask Bjoern Hansen:
# [EMAIL PROTECTED] (Brent Dax) writes:
#
# > +(@c{qw(ivsize opsize nvsize)})=split('/', `test$c{exe}`);
#
# I changed this so it works without having "." in $PATH.
I noticed. Thank you.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: [PATCH] Fix ivsize and nvsize issues
Simon Cozens:
# On Thu, Sep 20, 2001 at 09:44:41PM -0700, Brent Dax wrote:
# > Okay, this fixes the issues with changing your IV or NV
# size. It also
# > provides an early warning if your C compiler settings
# aren't okay. I've
# > also made the style of the code a little more consistent.
# I'm applying
# > this, but I figure people might as well check it over anyway.
#
# Excellent, thanks; sorry I was so quick to apply Andy's patch
# while you
# were working on this.
S'ok. I was gonna wait until after 0.02 was released, but then the
smokers started having problems.
# > sub check_manifest {
#
# ExtUtils::Manifest?
check_manifest is a wrapper around ExtUtils::Manifest::manicheck() that
prints out a different message depending on whether it found everything
or not.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: $PConfig{longsize}
Simon Cozens:
# This is never set, although it is (indirectly) tested for. Here's
# a patch.
#
# (@c{qw(ivsize opsize nvsize)})=split('/', `./test$c{exe}`);
# +$c{longsize} = $c{opsize};
Actually, that middle one *should* be longsize, not opsize. That was
from before I realized what longsize was used for. I'll commit a
trivial fix in a bit.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: [PATCH] Fixed typo in Configure.pl
Dan Sugalski:
# At 06:43 PM 9/20/2001 -0700, Brent Dax wrote:
# >Stefan Dragnev:
# ># - $c{cc_denug} = ' ';
# ># + $c{cc_debug} = ' ';
# >
# >So *that*'s why -g kept appearing...thanks, applied.
#
# Don't forget that debugging isn't always -g. (It's /DEBUG for
# me on VMS)
That sort of thing appears in a hints file for the OS. What is $^O on
VMS? I'll set it up.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: [PATCH] Fixed typo in Configure.pl
Brad Hughes:
# Brent Dax wrote:
# >
# > Dan Sugalski:
# > # At 06:43 PM 9/20/2001 -0700, Brent Dax wrote:
# > # >Stefan Dragnev:
# > # ># - $c{cc_denug} = ' ';
# > # ># + $c{cc_debug} = ' ';
# > # >
# > # >So *that*'s why -g kept appearing...thanks, applied.
# > #
# > # Don't forget that debugging isn't always -g. (It's /DEBUG for
# > # me on VMS)
# >
# > That sort of thing appears in a hints file for the OS.
# What is $^O on
# > VMS? I'll set it up.
# >
#
# I've got some patches and a VMS hints file for you. I'll email
# them off later today. Should they just go to the perl6-build list?
Sure, -build should be fine.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: [COMMIT] disassemble.pl
Simon Cozens:
# +if (($] >= 5.006) && ($PConfig{ivsize} == $PConfig{longsize}) ) {
The version check is no longer necessary, since Configure.pl now detects
longsize itself.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: Parrot Smoke Sep 20 00:00:02 2001 MSWin32 4.0
Mattia Barbon:
# > 'C:Perinperl.exe' is not recognized as an internal or
# external command,
# > operable program or batch file.
# Apply this for the C:Perinperl.exe problem
#
# - system "$^X -e \"$redir_string;system qq{$command};\"";
# + system "$^X -e \"$redir_string;system q{$command};\"";
Thanks, applied.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: A task independent of the freeze
Gregor N. Purdy:
# Dan --
#
# > Here's something for someone looking to do something
# interesting while the
# > code freeze is on.
# >
# > Write yourself a program that takes a .pasm file and,
# rather than spitting
# > out bytecode, spits out the bodies of the opcode functions with the
# > appropriate replacements done on the parameters. The output
# should be
# > suitable for stuffing into the guts of test_main.c in the
# place of the call
# > to the runops loop.
#
# My first cut is pretty sloppy, but it does generate this C file, which
# compiles, but I don't have the time to figure out how to get
# it all the
# stuff it needs to link to. If someones gets it running, I'd
Parrot::Config may come in handy, especially @PConfig{qw(cc ccflags
libs)}.
# like to see
# how many Mops they get vs. regular.
#
# This is generated from t/test.pbc (not t/test.pasm).
#
# The code is a total hack job, but you are welcome to look at it
# (compile.pl and Parrot/OpFunc.pm).
I modified my Makefile:
--- ..\..\parrot-cvs\parrot\MakefileFri Sep 21 16:41:52 2001
+++ MakefileFri Sep 21 16:39:18 2001
@@ -15,7 +15,7 @@
CC = cl
LD = link
PERL = C:\Perl\bin\perl.exe
-TEST_PROG = test_prog.exe
+TEST_PROG = test.exe
PDUMP = pdump.exe
.c.o:
@@ -29,12 +29,12 @@
$(CC) -shared $(C_LIBS) -o $@ $(O_FILES)
$(TEST_PROG): test_main$(O) $(O_FILES)
- $(CC) $(CFLAGS) -o $(TEST_PROG) $(O_FILES) test_main$(O)
$(C_LIBS)
+ $(CC) $(CFLAGS) -o $(TEST_PROG) $(O_FILES) test$(O) $(C_LIBS)
$(PDUMP): pdump$(O) $(O_FILES)
$(CC) $(CFLAGS) -o $(PDUMP) $(O_FILES) pdump$(O) $(C_LIBS)
-test_main$(O): $(H_FILES)
+test$(O): $(H_FILES) test.c
global_setup$(O): $(H_FILES)
and it built, but gave me a GPF (from trying to read memory at 0x4) when
I ran the resulting program. Make sure that you delete test$(O) before
trying this--it's a remnant from the Configure process I never thought
of. I'll patch Configure to delete it soon.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
More Configure.pl Modifications
Okay, this makes Configure generate a Parrot::Config module in the
current directory. This is analogous to Config.pm, except this exports
a %PConfig hash (to avoid collisions). I'm using Data::Dumper to create
the hash, so it'll make sure you have it and just not generate the file
(and tell the user) if Data::Dumper isn't available. Patches after my
sig. Someone suggested that we use .whatever_in instead of .whatever.in
for portability reasons; this does so on the new file but leaves the old
files as they are. It also adds "or die ..." to all openings and
closings of files.
Note that this patch *replaces* my last patch, sent earlier today. Do
*not* apply my last patch--apply this one instead.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
--- c:\old_parrot\Configure.pl Tue Sep 11 02:44:00 2001
+++ Configure.plThu Sep 13 23:32:26 2001
@@ -1,11 +1,18 @@
#!/usr/bin/perl -w
#so we get -w
-#Configre.pl, written by Brent Dax
+#Configure.pl, written by Brent Dax
use strict;
use Config;
+my($DDOK)=undef;
+eval {
+ require Data::Dumper;
+ Data::Dumper->import();
+ $DDOK=1;
+};
+
#print the header
print <<"END";
Parrot Configure
@@ -22,11 +29,17 @@
#defaults for them.
#XXX Figure out better defaults
my(%c)=(
- iv => ($Config{ivtype}||'long'),
- nv => ($Config{nvtype}||'long double')
+ iv => ($Config{ivtype}||'long'),
+ nv => ($Config{nvtype}||'long double'),
+ cc => $Config{cc},
+ ccflags => '-Wall -o $@',
+ libs => $Config{libs}
);
-#inquire about numeric sizes
+#ask questions
+prompt("What C compiler do you want to use?", 'cc');
+prompt("What flags would you like passed to your C compiler?",
'ccflags');
+prompt("Which libraries would you like your C compiler to include?" ,
'libs');
prompt("How big would you like integers to be?", 'iv');
prompt("How about your floats?", 'nv');
@@ -40,25 +53,22 @@
#set up HAS_HEADER_
foreach(grep {/^i_/} keys %Config) {
+ $c{$_}=$Config{$_};
$c{headers}.=defineifdef((/^i_(.*)$/));
}
-#now let's assemble the config.h file
-my $config_h;
-{
- local $/;
- open(CONFIG_HT, ";
- close CONFIG_HT;
-}
+print <<"END";
-# ${field} is replaced with $c{field}
-$config_h =~ s/\$\{(\w+)\}/$c{$1}/g;
+Okay, that's finished. I'm now going to write your very
+own Makefile, config.h, and Parrot::Config to disk.
+END
-#write out the config.h file
-open(CONFIG_H, ">config.h");
-print CONFIG_H $config_h;
-close CONFIG_H;
+#now let's assemble the config.h file
+buildfile("config.h");
+#and the makefile
+buildfile("Makefile");
+#and Parrot::Config
+buildconfigpm();
print <<"END";
@@ -91,3 +101,47 @@
$c{$field}=$input||$c{$field};
}
+sub buildfile {
+ my($filename)=shift;
+
+ local $/;
+ open(IN, "<$filename.in") or die "Can't open $filename.in: $!";
+ my $text=;
+ close(IN) or die "Can't close $filename.in: $!";
+
+ $text =~ s/\$\{(\w+)\}/$c{$1}/g;
+
+ open(OUT, ">$filename") or die "Can't open $filename: $!";
+ print OUT $text;
+ close(OUT) or die "Can't close $filename: $!";
+}
+
+sub buildconfigpm {
+ unless($DDOK) {
+ print <<"END";
+
+Your system doesn't have Data::Dumper installed, so I couldn't
+build Parrot::Config. If you want Parrot::Config installed,
+use CPAN.pm to install Data::Dumper and run this script again.
+END
+
+ return;
+ }
+
+ my %C=%c;
+ delete $C{headers};
+ my $dd=new Data::Dumper([\%C]);
+ $dd->Names(['*PConfig']);
+
+ local $/;
+ open(IN, ";
+ close(IN) or die "Can't close Config.pm_in: $!";
+
+ $text =~ s/#DUMPER OUTPUT HERE/$dd->Dump()/eg;
+
+ mkdir("Parrot") or ( $! =~ /File exists/i or die "Can't make
directory ./Parrot: $!");
+ open(OUT, ">Parrot/Config.pm") or die "Can't open file
Parrot/Config.pm: $!";
+ print OUT $text;
+ close(OUT) or die "Can't close file Parrot/Config.pm: $!";
+}
--- /dev/null Wed Dec 31 16:00:00 1969
+++ Config.pm_inThu Sep 13 23:40:00 2001
@@ -0,0 +1,14 @@
+package Parrot::Config;
+
+use strict;
+use warnings;
+use Exporter;
+
+use vars qw(@ISA @EXPORT %PConfig);
+@ISA=qw(Exporter);
+
+@EXPORT=qw(%PConfig);
+
+#DUMPER OUTPUT HERE
+
+1;
RE: Platforms Status
Buggs: # Collect all the P(ok)emons on the Core Platforms # and try to find the secret ways to the None Core Platforms. # Then proceed to level 0.0.2. # # -- # CORE PLATFORMS # -- # === # Linux (x86): # make ok / test ok # === # CygWin # Configure.pl fails # === # Win32 make ok / test ok (with caveats: nmake doesn't do 'test' correctly, and 'clean' doesn't work because of the 'rm' command) # === # Tru64 # make ok / test fails # === # OpenVMS (Alpha) # ?? # === # Solaris (Sparc) # ?? # === # FreeBSD (x86) # make ok / test ok # === # # - # NONE CORE PLATFORMS # - # # === # FreeBSD (Alpha) # make ok / test fails # === # Linux (Alpha) # make ok / test stacks fails # === # IRIX # make ok / test fails # === # Linux (Sparc) # make ok / test fails # === # iPaq (arm) # make ok / test fails (float errs) # === Linux (Itanium) make ok / test fails (badly--see smoke report below my sig) As you can see from the smoke report below, I've gotten remote smoke tests from Test-Drive machines (more or less) working. (I'll share how I did that in a later message.) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done. Automated smoke report for patch Sep 24 19:00:02 2001 UTC v0.01 on Linux using cc version 2.96-ia64-000717 snap 001117 O = OK F = Failure's), extended report at the bottom ? = still running or test results not (yet) available Build failures during: - = unknown c = Configure, m = make, t = make test-prep Configuration --- --- - F F --defaults F F --defaults --define nv=float F F --defaults --define nv=double F F --defaults --define nv=\"long double\" F F --defaults --define iv=int F F --defaults --define iv=int --define nv=float F F --defaults --define iv=int --define nv=double F F --defaults --define iv=int --define nv=\"long double\" F F --defaults --define iv=long F F --defaults --define iv=long --define nv=float F F --defaults --define iv=long --define nv=double F F --defaults --define iv=long --define nv=\"long double\" F F --defaults --define iv=\"long long\" F F --defaults --define iv=\"long long\" --define nv=float F F --defaults --define iv=\"long long\" --define nv=double F F --defaults --define iv=\"long long\" --define nv=\"long double\" | | | +- --debugging +--- normal Failures: linux--defaults linux--debugging --defaults t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define nv=float linux--debugging --defaults --define nv=float t/op/integerdubious DIED. FAILED test 25 linux--defaults --define nv=double linux--debugging --defaults --define nv=double t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define nv=\"long double\" linux--debugging --defaults --define nv=\"long double\" t/op/integerdubious DIED. FAILED test 25 linux--defaults --define iv=int linux--debugging --defaults --define iv=int linux--defaults --define iv=int --define nv=float linux--debugging --defaults --define iv=int --define nv=float linux--defaults --define iv=int --define nv=double linux--debugging --defaults --define iv=int --define nv=double linux--defaults --define iv=int --define nv=\"long double\" linux--debugging --defaults --define iv=int --define nv=\"long double\" t/op/basic..dubious DIED. FAILED test 1 linux--defaults --define iv=long linux--debugging --defaults --define iv=long t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define iv=long --define nv=float linux--debugging --defaults --define iv=long --define nv=float t/op/integerdubious DIED. FAILED test 25 linux--defaults --define iv=long --define nv=double linux--debugging --defaults --define iv=long --define nv=double t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define iv=long --define nv=\"long double\" linux--debugging --defaults --define iv=long --define nv=\"long double\" t/op/integerdubious DIED. FAILED test 25 linux--defaults --define iv=\"long long\" linux--debugging --defaults --define iv=\"long long\"
RE: build fails (Was: RE: Updated Platforms Status)
Henrik Tougaard:
# > --
# > CORE PLATFORMS
# > --
# > OpenVMS (Alpha)
# > ??
#
# Fails during configure.pl:
...
# What flags would you like passed to your C compiler?
# [/Include=[]/Standard=Relax
# ed_ANSI/Prefix=All/Obj=.obj/NoList -I./include]
...
# Alright, now I'm gonna check some stuff by compiling and running
# a small C program. This could take a bit...
# Use of uninitialized value at configure.pl line 136.
# %DCL-W-VALREQ, missing qualifier or keyword value - supply
# all required
# values
# \INCLUDE\
# C compiler died! at configure.pl line 136.
# %RMS-E-FNF, file not found
#
# $ perl -v
#
# This is perl, version 5.005_02 built for VMS_AXP
#
# ---
# I have looked at it a bit, and the cause is in the command
# line, that is
# built:
#
# CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList
# -I./include -o test_siz test.c
#
# The -I./include is *WRONG* om VMS.
#
# This comes from line 74 in configure.pl:
# cc => $Config{cc},
# #ADD C COMPILER FLAGS HERE
# ccflags => $Config{ccflags}." -I./include",
# libs => $Config{libs},
#
# the " -I./include" is *WRONG* - I don't know what to put in instead.
As a stopgap measure,
($^O eq 'VMS' ? " /Include=[.include]" : " -I./include")
ought to work (or something like it--I'm not a VMS guy). Of course, the
same problem probably occurs on Mac OS (and would occur on Win32 if it
wasn't clever enough to take / instead of \). The real way to do this
is probably with File::Spec or some similar tomfoolery--can someone
familiar with this module give me some guidance? (Note, however, that
someone who has been informed of this problem can manually fix it, by
putting the corrected command line in when the prompt comes up instead
of blindly hitting ENTER.)
You may not be aware, but on [EMAIL PROTECTED] they're discussing this
sort of thing--apparently mm[ks]'s (the make equivalents) Makefile
syntax is sufficiently different that it has to be done differently.
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
RE: Tru64 core dumps
Simon Cozens: # On Wed, Sep 26, 2001 at 09:47:08AM -0500, Gibbs Tanton - tgibbs wrote: # > Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS # is designed for a # > 32 bit system. It needs to be changed in the Configure.pl # script to be # > 0xf000 for 64 bit systems. With that changed # it works fine. # # Oooh. Sounds like a job for Configure Man! :) Configure Man To The Rescue! (Trumpets sound, then stop abruptly.) Now, how do I figure out if we're on a 64-bit system? :^) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
RE: Configure.pl *badly* wrong
Andy Dougherty: # On Wed, 26 Sep 2001, Andy Dougherty wrote: # # > I posted a patch last week to change the 'l' to a 'q', but # more generally, # > the assumption that sizeof(opcode_t) == sizeof(IV) should # probably be # > removed and each should be computed independently. Perhaps # late today I'll # > have a chance to do that if nobody beats me to it. # # Nobody beat me to it :-). Looks good to me. Can someone else apply this? I have to run--I don't have the time. --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
BabyPerl 0.01
I mentioned this idea before, and I've managed to implement a bit of it.
This is a compiler implementing a (very small) subset of Perl 6; it puts
the assembler code on STDOUT. Control flow and loops aren't implemented
yet. It uses Parse::RecDescent for parsing, and has a lot of 5.6-isms
in it. Here's a sample of input and output:
INPUT:
our string($hello);
our string($hi);
our string($hola);
our string($shalom);
$hello="H"~"ello, ";
$hi="Hi, ";
$hola="Hola, ";
$shalom="Shalom, ";
print($hello);
print($hi);
print($hola);
print("and ");
print($shalom);
print("world!");
our int($one);
$one=1;
our int($two);
$two=2;
our int($three);
$three=$one+$two;
print($three);
our int($six);
$six=$one+$two+$three;
print($six);
OUTPUT:
#File: test.bpl
#Variables:
# $hello(S) => S5
# $hi(S) => S6
# $hola(S) => S7
# $shalom(S) => S8
# $one(I) => I5
# $two(I) => I6
# $three(I) => I7
# $six(I) => I8
concat S0, "H", "ello, "
set S5, S0
set S6, "Hi, "
set S7, "Hola, "
set S8, "Shalom, "
print S5
print S6
print S7
print "and "
print S8
print "world!"
set I5, 1
set I6, 2
add I0, I5, I6
set I7, I0
print I7
add I0, I6, I7
add I0, I5, I0
set I8, I0
print I8
end
That isn't quite valid Parrot bytecode, because of the concat. Concat
is currently documented to take only two arguments. This will make the
compiler's life more difficult, as it requires another special case. I
recommend that we add a three-argument form of concat for consistency
with ops like add. babyperl.pl is attached; this is _really_ messy
code, and will probably be mostly rewritten before being added to the
little_languages directory of the Parrot distribution. Note that the
following things are still missing:
-Comments
-Interpolation
-Operator precedence
-Comparison operators
-And and Or
-Anything not already implemented in Parrot
print() currently only takes one parameter, but you can use ~ to
concatenate things together. It spits out a crapload of debugging
information--symbol table dumps and stack dumps--but it's all on STDERR
so you can redirect that to your null device to get rid of it.
Share and enjoy!
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
babyperl.pl
RE: [PATCH] rm -f in Win32
Mattia Barbon: # Makes Win32 use ExtUtils::Command::rm_f as a rm -f replacemnt. Thanks, applied. This one's been hovering near the top of my stack for a while, but I kept pushing new things on above it till now. --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
RE: Configure.pl *badly* wrong
Andy Dougherty: # On Wed, 26 Sep 2001, Andy Dougherty wrote: # # > > I posted a patch last week to change the 'l' to a 'q', # but more generally, # > > the assumption that sizeof(opcode_t) == sizeof(IV) should # probably be # > > removed and each should be computed independently. # Perhaps late today I'll # > > have a chance to do that if nobody beats me to it. # > # > Nobody beat me to it :-). # # The patch below (or something) is still needed. Otherwise, # even a simple # # perl5.7.2 Configure.pl --defaults # # fails miserably for me on both Intel and Sparc. (My 5.7.2 is # compiled with # ivsize=8, which means Configure.pl picks 'long long' for both IV and # opcode_t). Thanks, (finally) applied. I must have missed this patch in the shuffle or forgotten about it--I'll have to remember to flag all Configure patches in the future so they appear at the top of my e-mail. --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
RE: Manifest constants?
Wizard: # This was discussed to some extent on this list before (see RFC # http://dev.perl.org/rfc/263.pod). If parrot is expected to be # a JVM for # countless other languages, then it MUST (IMHO) understand the # concept of # NULL. Either that, or it must make allowances for the dynamic # inclusion of a # definition of NULL (whatever that might mean). What's the semantic difference between NULL and undef? --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
RE: Manifest constants?
Dan Sugalski: # (I'll start # stuffing 0xDEADBEEF in there if I have to... :) Actually, I think 0xDECAF would bug late-night coders even more! :^) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
Platform readiness reports
FreeBSD/x86 OK/OK Win32/x86 OK/NOK (report after my sig) Linux/IA64 OK/NOK (smoke report after my sig) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done. Win32/x86: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/stacks.t1 256 91 11.11% 5 t/op/time.t 1 256 21 50.00% 2 5 subtests skipped. Failed 2/8 test scripts, 75.00% okay. 2/99 subtests failed, 97.98% okay. Linux/IA64: Automated smoke report for patch Sep 24 19:00:02 2001 UTC v0.01 on linux using cc version 2.96-ia64-000717 snap 001117 O = OK F = Failure(s), extended report at the bottom ? = still running or test results not (yet) available Build failures during: - = unknown c = Configure, m = make, t = make test-prep Configuration --- --- - F F --defaults F F --defaults --define nv=double F F --defaults --define nv=\"long double\" F F --defaults --define iv=long F F --defaults --define iv=long --define nv=double F F --defaults --define iv=long --define nv=\"long double\" F F --defaults --define iv=\"long long\" F F --defaults --define iv=\"long long\" --define nv=double F F --defaults --define iv=\"long long\" --define nv=\"long double\" | | | +- --debugging +--- normal Failures: linux--defaults linux--debugging --defaults linux--defaults --define nv=double linux--debugging --defaults --define nv=double t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define nv=\"long double\" linux--debugging --defaults --define nv=\"long double\" t/op/integerdubious DIED. FAILED test 25 linux--defaults --define iv=long linux--debugging --defaults --define iv=long linux--defaults --define iv=long --define nv=double linux--debugging --defaults --define iv=long --define nv=double t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define iv=long --define nv=\"long double\" linux--debugging --defaults --define iv=long --define nv=\"long double\" t/op/integerdubious DIED. FAILED test 25 linux--defaults --define iv=\"long long\" linux--debugging --defaults --define iv=\"long long\" linux--defaults --define iv=\"long long\" --define nv=double linux--debugging --defaults --define iv=\"long long\" --define nv=double t/op/stacks.dubious DIED. FAILED tests 1, 3, 5, 7-9 linux--defaults --define iv=\"long long\" --define nv=\"long double\" linux--debugging --defaults --define iv=\"long long\" --define nv=\"long double\" t/op/integerdubious DIED. FAILED test 25
CVS
Automated snapshots and e-mail notifications of CVS commits have both stopped. What's going on? --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
RE: CVS
Ask Bjoern Hansen: # [EMAIL PROTECTED] (Brent Dax) writes: # # > Automated snapshots and e-mail notifications of CVS commits have # > both stopped. What's going on? # # snapshots looks okay, but there's something #$@# with the mails. I'll # have a look. :-) Yeah, it turns out the snapshot thing was a bug in my remote-smoke-test program. It was unpacking to ~/parrot/parrot instead of ~/parrot, making it appear as if parrot-latest hadn't been updated since 9-24, the last time I manually unpacked it. Ouch. *looks at his feet sheepishly* --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
RE: Platform readiness reports
Brent Dax: # Linux/IA64 # OK/NOK (smoke report after my sig) Actually it's not as bad as I thought--it works fine on non-64-bit types, and even then only one test dies. Automated smoke report for patch Oct 2 07:00:01 2001 UTC v0.01 on linux using cc version 2.96-ia64-000717 snap 001117 O = OK F = Failure(s), extended report at the bottom ? = still running or test results not (yet) available Build failures during: - = unknown c = Configure, m = make, t = make test-prep Configuration --- --- - O O --defaults O O --defaults --define nv=double F F --defaults --define nv=\"long double\" O O --defaults --define iv=long O O --defaults --define iv=long --define nv=double F F --defaults --define iv=long --define nv=\"long double\" F F --defaults --define iv=\"long long\" F F --defaults --define iv=\"long long\" --define nv=double F F --defaults --define iv=\"long long\" --define nv=\"long double\" | | | +- --debugging +--- normal Failures: linux--defaults --define nv=\"long double\" linux--debugging --defaults --define nv=\"long double\" linux--defaults --define iv=long --define nv=\"long double\" linux--debugging --defaults --define iv=long --define nv=\"long double\" linux--defaults --define iv=\"long long\" linux--debugging --defaults --define iv=\"long long\" linux--defaults --define iv=\"long long\" --define nv=double linux--debugging --defaults --define iv=\"long long\" --define nv=double linux--defaults --define iv=\"long long\" --define nv=\"long double\" linux--debugging --defaults --define iv=\"long long\" --define nv=\"long double\" t/op/integerdubious DIED. FAILED test 25 --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
RE: Parrot 0.0.2
Simon Cozens: # Any objections to a release today? How's Cygwin and Win32 looking? Win2K non-Cygwin is looking a little sick to its stomach: Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot>pmake test Reading C:/Perl/site/lib/Make.pm Reading C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot\makefile C:\Perl\bin\perl.exe t/harness t/op/basic..ok, 1/5 skipped: label constants unimplemented in assembler t/op/bitwiseok t/op/integerok t/op/number.ok t/op/stacks.NOK 5# Failed test (Parrot/Test.pm at line 74) # got: 'Seem to have negative Nx not ok ' # expected: 'Seem to have negative Nx Seem to have positive Nx after pop ' t/op/stacks.ok 9/9# Looks like you failed 1 tests of 9. t/op/stacks.dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 5 Failed 1/9 tests, 88.89% okay (-3 skipped tests: 5 okay, 55.56%) t/op/string.NOK 4# Failed test (Parrot/Test.pm at line 74) # got: 'Error: Control left bounds of byte-code block (now at location 31)! ng ** ' # expected: 'A string of length 21 A string of lengt A string of lengt ** nothing ** ' t/op/string.ok 11/11# Looks like you failed 1 tests of 11. t/op/string.dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 4 Failed 1/11 tests, 90.91% okay (-1 skipped test: 9 okay, 81.82%) t/op/time...NOK 2# Failed test (Parrot/Test.pm at line 74) # got: 'failure ' # expected: 'ok, (!= 1970) Grateful Dead not ok, (now>before) timelords need not apply ' # Looks like you failed 1 tests of 2. t/op/time...dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 2 Failed 1/2 tests, 50.00% okay t/op/trans..ok Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/stacks.t1 256 91 11.11% 5 t/op/string.t1 256111 9.09% 4 t/op/time.t 1 256 21 50.00% 2 5 subtests skipped. Failed 3/8 test scripts, 62.50% okay. 3/100 subtests failed, 97.00% okay. --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
RE: Parrot 0.0.2
Simon Cozens: # On Wed, Oct 03, 2001 at 09:39:32AM -0700, Brent Dax wrote: # > Win2K non-Cygwin is looking a little sick to its stomach: # # Dammit. There had to be a show-stopper, didn't there? And of course it had to be Microsoft. :^) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
RE: Parrot 0.0.2
Simon Cozens: # On Wed, Oct 03, 2001 at 05:51:14PM +0100, Simon Cozens wrote: # > > # got: 'Seem to have negative Nx # > > not ok # > > # expected: 'Seem to have negative Nx # > > Seem to have positive Nx after pop # # So pop_n is broken on Win32. Did you see any compiler warnings # in the stacks code? Nope. No warnings at all (which is better than I can say for bleadperl :^) ). --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
RE: Parrot 0.0.2
--Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done. # -Original Message- # From: Simon Cozens [mailto:[EMAIL PROTECTED]] # Sent: Wednesday, October 03, 2001 09:51 # To: Brent Dax # Cc: [EMAIL PROTECTED] # Subject: Re: Parrot 0.0.2 # # # OK, let's try and clear this up. # # On Wed, Oct 03, 2001 at 09:39:32AM -0700, Brent Dax wrote: # > # got: 'Seem to have negative Nx # > not ok # > ' # > # expected: 'Seem to have negative Nx # > Seem to have positive Nx after pop # > ' # # Don't know what's going on here. # # > t/op/string.NOK 4# Failed test (Parrot/Test.pm at line 74) # > # got: 'Error: Control left bounds of byte-code # block (now at # > location # > 31)! # # There isn't an "end" on that test. Fixed. # # > # got: 'failure # > ' # # Since there was no other output, this failed: # timeI0 # ge I0, 0, OK1 # # Now that's anyone's guess. # # I've added some debugging prints, can you try a resync? I tried it and ended up with something weird: C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot>pmake test Reading C:/Perl/site/lib/Make.pm Reading C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot\makefile C:\Perl\bin\perl.exe t/harness t/op/basic..ok t/op/bitwiseok t/op/integerok t/op/number.ok t/op/stacks.NOK 5# Failed test (Parrot/Test.pm at line 74) # got: 'Seem to have negative Nx not ok ' (etc, as before) Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/stacks.t1 256 91 11.11% 5 t/op/time.t 1 256 21 50.00% 2 4 subtests skipped. Failed 2/8 test scripts, 75.00% okay. 2/100 subtests failed, 98.00% okay. Code 65280 from C:\Perl\bin\perl.exe t/harness at C:/Perl/site/lib/Make.pm line 265. C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot>perl t/harness t/op/basic..ok t/op/bitwiseok t/op/integerok t/op/number.ok t/op/stacks.ok, 3/9 skipped: various reasons t/op/string.ok, 1/11 skipped: TODO: printing empty string reg segfaults t/op/time...ok t/op/trans..ok All tests successful, 4 subtests skipped. Files=8, Tests=100, 32 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) Weird, huh? If I use nmake /a (forces it to do test, even though it thinks test is up to date) instead of pmake, I get the same output as pmake. This is pretty spooky...
RE: SV: OpenVMS
Michael G Schwern:
# On Wed, Oct 03, 2001 at 07:09:06PM +0100, Simon Cozens wrote:
# > On Wed, Oct 03, 2001 at 01:55:39PM -0400, Dan Sugalski wrote:
# > > If you want to wait, that's fine. I don't think I'm going
# to get untangled
# > > for another day or three, though.
# >
# > Waiting might also help to shake out whatever's wrong with
# Win2K. Maybe
# > it's just Brent's system being funny. (And I'd try playing
# with Compaq
# > Test Drive's OpenVMS system, but I can't find gzip, vmstar
# or, unfortunately,
# > perl. And damn, it's been a long time since I used DCL.)
#
# Unpleasent things happen with 5.005_03
...
# Okay. Now I'm gonna probe Perl 5's configuration to see
# what headers you have around. This could take a bit on slow
# machines...
# Out of memory!
# Out of memory!
# %SYSTEM-F-ABORT, abort
Oof. It probably doesn't like the 'grep {/pattern/} keys %Config' very
much. Replace:
foreach(grep {/pattern/} keys %Config) {
blah blah blah
with:
while($_=each %Config) {
next unless /pattern/;
blah blah blah
(untested) and it ought to work okay. (Fill in the correct /pattern/,
of course.)
# bleadperl 12109 is slightly less unpleasent.
#
# Okay. Now I'm gonna probe Perl 5's configuration to see
# what headers you have around. This could take a bit on slow
# machines...
#
# Alright, now I'm gonna check some stuff by compiling and running
# a small C program. This could take a bit...
# Use of uninitialized value in concatenation (.) or string at
# configure.pl line 137.
# %DCL-W-VALREQ, missing qualifier or keyword value - supply
# all required values \INCLUDE\
# C compiler died! at configure.pl line 137.
# %RMS-E-FNF, file not found
Yeah, that whole test.c thing is highly Unix-centric. I'll probably
wrap it up in a function so hints files can override its behavior. If
you can't figure out how to adapt what's there for VMS, you can always
replace the split() with the actual values of the things. (Yucky, I
know, but it would at least work.)
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
RE: SV: OpenVMS
Dan Sugalski: # At 02:56 PM 10/4/2001 +0100, Simon Cozens wrote: # >Can't we just use a hints file? :( # # Give me a day or so and I'll get it fixed properly. I'm used # to that by If you're hacking in that area, can you package the test.c stuff in a subroutine for ease of hints overloading? # now... :) (There's a reason we just chucked it all and do our # own thing to # configure stuff in perl 5 on VMS) I thought that was funny shell syntax and other such things. With Perl 5's portability stuff (think File::Spec, etc.) we should be able to have One True Configure, at least while it's still implemented in Perl. Right? --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
Itanium much happier
Looks like long long is no longer a problem, but long double still is. That's okay--Itanium is bouncing up and down in glee compared to yesterday. Automated smoke report for patch Oct 4 07:00:01 2001 UTC v0.01 on linux using cc version 2.96-ia64-000717 snap 001117 O = OK F = Failure(s), extended report at the bottom ? = still running or test results not (yet) available Build failures during: - = unknown c = Configure, m = make, t = make test-prep Configuration --- --- - O O --defaults O O --defaults --define nv=double F F --defaults --define nv=\"long double\" O O --defaults --define iv=long O O --defaults --define iv=long --define nv=double F F --defaults --define iv=long --define nv=\"long double\" O O --defaults --define iv=\"long long\" O O --defaults --define iv=\"long long\" --define nv=double F F --defaults --define iv=\"long long\" --define nv=\"long double\" | | | +- --debugging +--- normal Failures: linux--defaults --define nv=\"long double\" linux--debugging --defaults --define nv=\"long double\" linux--defaults --define iv=long --define nv=\"long double\" linux--debugging --defaults --define iv=long --define nv=\"long double\" linux--defaults --define iv=\"long long\" --define nv=\"long double\" linux--debugging --defaults --define iv=\"long long\" --define nv=\"long double\" t/op/integerdubious DIED. FAILED test 25 --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
RE: Itanium much happier
Andy Dougherty:
# In perl.perl6.internals, you wrote:
# >Looks like long long is no longer a problem, but long double
# still is.
# >That's okay--Itanium is bouncing up and down in glee compared to
# >yesterday.
#
# Can you check if sizeof(long double) is 12 or 16? I think there are
# still places that assume sizeof(numval)/sizeof(intval) is an integer.
spe166> cat > size.c
#include
int main(void) {
printf("%d\n", sizeof(long double));
return 0;
}
spe166> gcc -o size size.c
spe166> ./size
16
spe166>
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
