rating 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]
/-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
# -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 detect
ity 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]
# -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 r
# -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
# -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) co
# -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
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 f
o 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."
# -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
# -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
--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]]
# Se
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 th
do-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) tha
izer 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."
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 righ
|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."
rograms 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."
t 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 PRO
k 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."
n 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 program
nd
# 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."
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
o 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 Ja
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&
dings. 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.
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
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 P
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 1
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
he 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 sh
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.
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]
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 +
ould 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.
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.
gure
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
associati
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 witho
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 D
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.
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.
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 someon
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...
ome 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 merg
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
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 *w
FLAGS, 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.
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
s 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
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.
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.
#else
#define DISPATCHER
#endif
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
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
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, ur
ic_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
12000.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.
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 er
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)?", 'nvsiz
ically. 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.
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 thi
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
oved.
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.
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
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.
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.
--B
27;ve applied it myself.
Thanks, Damien.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
xe' 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 ha
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.
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 lit
d 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.
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 a
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 w
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.
;$^X -e \"$redir_string;system q{$command};\"";
Thanks, applied.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
t 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.
ings 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
===
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 PR
27;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.
ms. 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
ndently. 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.
-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 ta
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* pa
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.
# 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.
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.
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 F
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.
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 o
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-0
1% 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.
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 pump
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.
--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
piler 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 t
ue 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.
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 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 PROTECT
. IV and opcode_t are both long. It happens under both
make test and perl t/harness. It doesn't happen when NV is just double.
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
--
---
t/op/stacks.t1 256 91 11.11% 5
4 subtests skipped.
Failed 1/8 test scripts, 87.50% okay. 1/100 subtests failed, 99.00%
okay.
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
1 - 100 of 621 matches
Mail list logo
