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.
[EMAIL PROTECTED] (Brent Dax) writes:
> +(@c{qw(ivsize opsize nvsize)})=split('/', `test$c{exe}`);
I changed this so it works without having "." in $PATH.
- ask
--
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
[EMAIL PROTECTED] (Mattia Barbon) writes:
> Automated smoke report for patch Sep 20 00:00:02 2001
I've changed the .timestamp file to be UTC and include that
information.
--
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
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. F
[EMAIL PROTECTED] (Andy Dougherty) writes:
> > > 2) The use of `!' to pack() in the assembler.
> >
> > Oops. My fault. I forgot that was a new addition.
>
> Here's the fix for that.
I applied it. Stuff works again on 5.005_03.
- ask
--
ask bjoern hansen, http://ask.netcetera.dk/ !try;
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 app
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
On Thu, Sep 20, 2001 at 09:06:12AM -0500, Gibbs Tanton - tgibbs wrote:
> Failed 1/5 test scripts, 80.00% okay. 7/74 subtests failed, 90.54% okay.
> make: *** [test] Error 2
>
> Damien, is there any way we could get a similar fix for number.t? That
> would make us at 100% on Tru64.
I'm currently
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.
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.11
diff -u -r1.11 Configure.pl
--- Configure.pl2001/09/20 13:35:26 1.11
+++ Configure.pl2001/09/20 19:49:03
@@ -105,7 +105
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Might sound that way, but it isn't. What I'm talking about is
DS> something like:
DS> READ S3, P1, I0
DS> X: SLEEP 3
DS> EQ I0, 0, X
DS> PRINT S3
DS> Where we issue the read on the filehandle in P1, telling it
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> There probably won't be any. The current thinking is that since
DS> the ops themselves will be a lot smaller, we'll have an explicit
DS> event checking op that the compiler will liberally scatter through
DS> the generated code. L
Hi,
Parrot::Smoke 0.01 has just been released.
It works on Win2k and Linux, but it should work
in most Unices.
Comments and suggestions are welcome.
Regards
Mattia
--- Forwarded message follows ---
Date sent: Fri, 21 Sep 2001 02:41:42 +0200
Send reply to: [EMAIL PR
On Thu, 20 Sep 2001, Dan Sugalski wrote:
> FWIW, my 600MHz Alpha clocks in at around 23M ops/sec. Nyah! ;-P
My PIII 700Mhz gets 23M. Well, ok, to get above 21M I had to make a
slight alteration (below). Damn Alphas and their "superior technology".
-sam
RCS file: /home/perlcvs/parrot/interpre
Hoi,
This doesn't take into account locale.
line 211:
mkdir("Parrot", 0777) or ( $! =~ /File exists/i or die "Can't make directory ./Parrot:
$!");
On Sunday 16 September 2001 21:43, Buggs wrote:
> Hoi,
>
> probably obsolete soon, but still.
>
> Buggs
>
> Index: Configure.pl
>
On Thu, Sep 20, 2001 at 11:52:50PM +0100, Tom Hughes wrote:
> I have test.pasm reporting 7.14M ops/sec on a 200MHz K6 running
> linux with the interpreter compiled -O3. That's about twice the
> speed that I get without any optimisation.
Oh, right. Optimization.
I'm getting 2.67 MIPS with -O3.
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> That's actually what test.pasm tests. :) I just checked in a new version
> that prints labels.
>
> FWIW, my 600MHz Alpha clocks in at around 23M ops/sec. Nyah! ;-P
I have test.pasm reporting 7.14M ops/sec on a 200
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> So, if you're running on one of the core platforms, please check out a
> *clean* CVS copy, try and build and post the output of make test.
Tests cleanly on linux/x86:
perl t/harness
t/op/basic..ok, 1/2 skippe
On Thu, Sep 20, 2001 at 04:54:21PM -0500, Brian Wheeler wrote:
> Since all benchmarks are crap anyway, I've written a test which tells
> the average number of instructions per second. On my athlon 700 I get
> 3966053 instructions per second and on my PIII 866 I get 5081485
> instructions per seco
[I'm behind on my mail :-)]
On Wed, 12 Sep 2001 13:19:40 -0400, Dan Sugalski wrote:
>We're trying to align to a power-of-two boundary, and mask is set to
>chop off the low bits, not the high ones. It should be something like:
>
>
>
>The calc:
>
> mem & mask + (~mask + 1)
>
On Thu, 2001-09-20 at 16:46, Dan Sugalski wrote:
> At 04:54 PM 9/20/2001 -0500, Brian Wheeler wrote:
> >Since all benchmarks are crap anyway, I've written a test which tells
> >the average number of instructions per second. On my athlon 700 I get
> >3966053 instructions per second and on my PIII
At 04:54 PM 9/20/2001 -0500, Brian Wheeler wrote:
>Since all benchmarks are crap anyway, I've written a test which tells
>the average number of instructions per second. On my athlon 700 I get
>3966053 instructions per second and on my PIII 866 I get 5081485
>instructions per second. Do those sou
Since all benchmarks are crap anyway, I've written a test which tells
the average number of instructions per second. On my athlon 700 I get
3966053 instructions per second and on my PIII 866 I get 5081485
instructions per second. Do those sound like reasonable numbers? Of
course, since time_i i
> + cd t; make realclean
( from MM_Unix, sub clean
if ($Is_Win32 && Win32::IsWin95()) {
push @m, <{MAKEFILE}
\$(MAKE) clean
cd ..
EOT
}
else {
push @m, <{MAKEFILE} && \$(MAKE) clean
EOT
}
If you could change it to
cd t
At 02:17 PM 9/20/2001 -0700, Damien Neil wrote:
>On Thu, Sep 20, 2001 at 05:09:52PM -0400, Dan Sugalski wrote:
> > Just a reminder--function names shouldn't exceed 31 characters. The C
> > standard doesn't guarantee anything past that...
>
>You think that's bad? You aren't guaranteed more than si
> you can't do non-blocking i/o on files without aio_read type calls. but
> what dan is saying is that the api the interpreter uses internally will
> be an async one. it will either use native/POSIX aio calls or simulate
> that with sync calls and callbacks or possibly with threads.
>
That sound
At 02:04 PM 9/20/2001 -0700, Damien Neil wrote:
>On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote:
> > >For clarification: do you mean async I/O, or non-blocking I/O?
> >
> > Async. When the interpreter issues a read, for example, it won't assume
> the
> > read completes immediately.
At 05:23 PM 9/20/2001 -0400, Michael L Maraist wrote:
>There wasn't any code for CHECK_EVENTS w/in Parrot when I first read the
>source-code. I merely assumed that it's role was not-yet determined, but
>considered the possible uses. CHECK_EVENTS seems to be gone at the
>moment, so it's a moot
Arthur Bergman wrote:
> > Arthur Bergman wrote:
> >
> > > In an effort to rest my braine from a coredumping perl5 I started to think a bit
>on threading under parrot?
> > >
> > > While it has been decided that perl should be using ithread like threading, I
>guess that is irelevant at the parrot
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 _.
- Damien
Index: test_main.c
===
RCS file: /home/perlcv
On Thu, Sep 20, 2001 at 05:09:52PM -0400, Dan Sugalski wrote:
> Just a reminder--function names shouldn't exceed 31 characters. The C
> standard doesn't guarantee anything past that...
You think that's bad? You aren't guaranteed more than six characters,
case-insensitive for external identifier
> "DN" == Damien Neil <[EMAIL PROTECTED]> writes:
DN> On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote:
>> >For clarification: do you mean async I/O, or non-blocking I/O?
>>
>> Async. When the interpreter issues a read, for example, it won't assume the
>> read complete
Just a reminder--function names shouldn't exceed 31 characters. The C
standard doesn't guarantee anything past that...
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL
On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote:
> >For clarification: do you mean async I/O, or non-blocking I/O?
>
> Async. When the interpreter issues a read, for example, it won't assume the
> read completes immediately.
That sounds like what I would call non-blocking I/O. Asy
> Nope. Internal I/O, at least as the interpreter will see it is async. You
> can build sync from async, it's a big pain to build async from sync.
> Doesn't mean we actually get asynchrony, just that we can.
>
It is trivial to build async from sync, just using thread. Most Unix async
are built
At 01:53 PM 9/20/2001 -0700, Damien Neil wrote:
>On Thu, Sep 20, 2001 at 04:38:57PM -0400, Dan Sugalski wrote:
> > Nope. Internal I/O, at least as the interpreter will see it is async. You
> > can build sync from async, it's a big pain to build async from sync.
> > Doesn't mean we actually get asy
On Thu, Sep 20, 2001 at 04:38:57PM -0400, Dan Sugalski wrote:
> Nope. Internal I/O, at least as the interpreter will see it is async. You
> can build sync from async, it's a big pain to build async from sync.
> Doesn't mean we actually get asynchrony, just that we can.
For clarification: do you
On Thu, Sep 20, 2001 at 04:24:19PM -0400, Dan Sugalski wrote:
> At 01:08 PM 9/20/2001 -0700, Damien Neil wrote:
> >Another approach would be to include a means of defining information
> >that must be included by the file implementing the ops. For example:
>
> I like that approach. I'd say go for
At 04:36 PM 9/20/2001 -0400, Rocco Caputo wrote:
>On Thu, Sep 20, 2001 at 04:13:48PM -0400, Michael L Maraist wrote:
> > >
> > > What we're going to do is fire up a new interpreter for each thread. (We
> > > may have a pool of prebuilt interpreters hanging around for this
> > > eventuality) Thread
At 12:33 PM 9/20/2001 -0700, Hong Zhang wrote:
> > DS> I'm also seriously considering throwing *all* PerlIO code into
> > separate
> > DS> threads (one per file) as an aid to asynchrony.
> >
> > but that will be hard to support on systems without threads. i still
> > have that internals async
On Thu, Sep 20, 2001 at 04:13:48PM -0400, Michael L Maraist wrote:
> >
> > What we're going to do is fire up a new interpreter for each thread. (We
> > may have a pool of prebuilt interpreters hanging around for this
> > eventuality) Threading *is* essential at the parrot level, and there are
> >
Quoting Dan Sugalski <[EMAIL PROTECTED]>:
> > Could you explain again why you don't want char* anywhere, and
> prefer
> > void*?
>
> Because for character data we're not sure char * is right. (Might be
> wchar_t, __int16, __int32, or something else) It's also to shake off the
>
> "Oh, it's
On Thu, Sep 20, 2001 at 04:25:45PM -0400, Dan Sugalski wrote:
> At 01:06 PM 9/20/2001 -0700, Robert Spier wrote:
> > Could you explain again why you don't want char* anywhere, and prefer
> > void*?
>
> Because for character data we're not sure char * is right. (Might be
> wchar_t, __int16, __
At 01:08 PM 9/20/2001 -0700, Damien Neil wrote:
>Another approach would be to include a means of defining information
>that must be included by the file implementing the ops. For example:
>
> HEADER {
> #include
> }
>
>This would then be placed into interp_guts.h. (Possibly surrounded
>by
At 01:06 PM 9/20/2001 -0700, Robert Spier wrote:
>Dan,
>
> Could you explain again why you don't want char* anywhere, and prefer
> void*?
Because for character data we're not sure char * is right. (Might be
wchar_t, __int16, __int32, or something else) It's also to shake off the
"Oh, it's c
At 02:21 PM 9/20/2001 -0400, Andy Dougherty wrote:
>On Thu, 20 Sep 2001, Dan Sugalski wrote:
>
> > At 04:38 PM 9/20/2001 +0100, Simon Cozens wrote:
> > >On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote:
> > > > I don't want to do int->pointer casts anywhere in the source if we can
> >
>
>
> What we're going to do is fire up a new interpreter for each thread. (We
> may have a pool of prebuilt interpreters hanging around for this
> eventuality) Threading *is* essential at the parrot level, and there are
> even a few (as yet undocumented) opcodes to deal with them, and some stuff
On Thu, Sep 20, 2001 at 11:11:42AM -0400, Dan Sugalski wrote:
> Actually the ops=>C conversion was conceived to do exactly what's being
> done now--to abstract out the body of the opcodes so that they could be
> turned into a switch, or turned into generated machine code, or TIL'd. If
> you're
On Thu, Sep 20, 2001 at 09:06:12AM -0500, Gibbs Tanton - tgibbs wrote:
> Damien, is there any way we could get a similar fix for number.t? That
> would make us at 100% on Tru64.
(Apologies if this shows up twice; something appears to be screwy with
my mail system.)
I'm currently getting segfaul
Dan,
Could you explain again why you don't want char* anywhere, and prefer void*?
You answered this on language-dev, but went off on what seemed to be a tangent
about encodings.
Some ramblings of my own that may be confusing me, are:
char* doesn't necessarily mean "a string".
would t
> Arthur Bergman wrote:
>
> > In an effort to rest my braine from a coredumping perl5 I started to think a bit
>on threading under parrot?
> >
> > While it has been decided that perl should be using ithread like threading, I
>guess that is irelevant at the parrot level. Are you
> > going to h
Arthur Bergman wrote:
> In an effort to rest my braine from a coredumping perl5 I started to think a bit on
>threading under parrot?
>
> While it has been decided that perl should be using ithread like threading, I guess
>that is irelevant at the parrot level. Are you
> going to have one "virtu
On Thu, Sep 20, 2001 at 12:33:54PM -0700, Hong Zhang wrote:
>
> > DS> I'm also seriously considering throwing *all* PerlIO code into
> > separate
> > DS> threads (one per file) as an aid to asynchrony.
> >
> > but that will be hard to support on systems without threads. i still
> > have tha
> DS> I'm also seriously considering throwing *all* PerlIO code into
> separate
> DS> threads (one per file) as an aid to asynchrony.
>
> but that will be hard to support on systems without threads. i still
> have that internals async i/o idea floating in my numb skull. it is an
> api that
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
Automated smoke report for patch Sep 20 00:00:02 2001
v0.01 on MSWin32 using cl version
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-
Below is a patch doing five things:
1) rename $nvivsiz to $sizeof_float
which should be easier to understand
2) rename the inner $count to $num_params
which should avoid some confusion
3) change $num_i and $num_n to $num_ints and $num_floats respectively
which should help c
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I'm also seriously considering throwing *all* PerlIO code into separate
DS> threads (one per file) as an aid to asynchrony.
but that will be hard to support on systems without threads. i still
have that internals async i/o idea floa
On Thu, 20 Sep 2001, Dan Sugalski wrote:
> At 04:38 PM 9/20/2001 +0100, Simon Cozens wrote:
> >On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote:
> > > I don't want to do int->pointer casts anywhere in the source if we can
> > > possibly avoid it. Yech.
> >
> >In which case, do we *nee
> "AB" == Arthur Bergman <[EMAIL PROTECTED]> writes:
AB> In an effort to rest my braine from a coredumping perl5 I started
AB> to think a bit on threading under parrot? While it has been
AB> decided that perl should be using ithread like threading, I guess
AB> that is irelevant at th
On Thu, 20 Sep 2001, Brent Dax wrote:
> 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 specia
On Thu 20 Sep 2001 15:49, Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 20, 2001 at 09:00:20AM +0100, Simon Cozens wrote:
> > So, if you're running on one of the core platforms, please check out a *clean*
> > CVS copy, try and build and post the output of make test.
>
> FWIW, here's the c
This patch adds some more tidying-up to Makefile.in and t/Makefile.
The split between clean and realclean is absolutely arbitrary; season to
taste.
diff -r -u parrot/Makefile.in parrot-andy/Makefile.in
--- parrot/Makefile.in Wed Sep 19 12:48:28 2001
+++ parrot-andy/Makefile.in Thu Sep 20 12:
I will be on vacation in Disney World from now until Sunday night.
Therefore, if you need me I won't be here :)
Tanton
At 04:38 PM 9/20/2001 +0100, Simon Cozens wrote:
>On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote:
> > I don't want to do int->pointer casts anywhere in the source if we can
> > possibly avoid it. Yech.
>
>In which case, do we *need* a type that can hold both.
I can't think of a reas
On Thu 20 Sep 2001 16:55, Andy Dougherty <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Sep 2001, Philip Kendall wrote:
>
> > What version of Perl are we requiring to bootstrap Parrot? At the
> > moment, things fail with 5.005 because:
> >
> > 2) The use of `!' to pack() in the assembler.
>
> Oops. M
On Thu, Sep 20, 2001 at 09:00:20AM +0100, Simon Cozens wrote:
> So, if you're running on one of the core platforms, please check out a *clean*
> CVS copy, try and build and post the output of make test.
FWIW, here's the current state of Linux/Sparc (ivsize=8, nvsize=8,
ptrsize=4)
Failed 4/5 test
On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote:
> I don't want to do int->pointer casts anywhere in the source if we can
> possibly avoid it. Yech.
In which case, do we *need* a type that can hold both.
--
"Darkly hinting of head hitting desk"
-- Megahal (trained on asr)
At 04:16 PM 9/20/2001 +0100, Dave Mitchell wrote:
>Also, I think that IV needs splitting into two or more different
>types.
>
>There is the type that specifically fits in the Parrot integer registers
>and is recognised by parrot ops;
>
>Then there are all the other places within perl and parrot wh
On Thu, 20 Sep 2001, Andy Dougherty wrote:
> On Thu, 20 Sep 2001, Philip Kendall wrote:
>
> > What version of Perl are we requiring to bootstrap Parrot? At the
> > moment, things fail with 5.005 because:
> >
> > 2) The use of `!' to pack() in the assembler.
>
> Oops. My fault. I forgot that
Simon Cozens <[EMAIL PROTECTED]> wrote:
> I'm seriously investigating the possibility of changing IV and NV to something
> more readable.
>
> (But for those of you who are following language-dev, don't tell 'em because
> then they'll think they've won. ;)
Some time ago I sugested that NV was a
At 10:22 PM 9/19/2001 -0700, Dave Storrs wrote:
>I'm working on documenting the opcodes, and I want to make sure that I
>understand the 'RETURN' code properly. I've poked around a little bit to
>see if I coudl figure it out, but I don't want to divert too much. Would
>someone please explain to m
At 12:07 AM 9/20/2001 -0700, Damien Neil wrote:
>I'm not at all certain what to do with things outside the opcodes
>themselves. The .ops => .c conversion was clearly originally
>concieved as translating one file into another. In order to dispatch
>ops via a switch, you need to pull out only the
At 03:59 PM 9/20/2001 +0200, Arthur Bergman wrote:
>While it has been decided that perl should be using ithread like
>threading, I guess that is irelevant at the parrot level. Are you
>going to have one "virtual cpu" per thread with it's own set of registers
>or are you going to context switch t
At 03:34 PM 9/20/2001 +0100, Simon Cozens wrote:
>(But for those of you who are following language-dev, don't tell 'em because
>then they'll think they've won. ;)
Ah, go ahead and tell them. I don't much care about who wins or loses if
the code's easier to maintain and runs fast. (Neither do I m
So, while we're having a little freeze, some
thoughts/proposals:
We've seen at least 2 implementations of the
build_interp_starter/process_opfunc stuff.
Lets consider how we can structure this code
with the Parrot/*.pm stuff to be as generic
and flexible as we can ( for a very targetted
purpose,
On Thu, 20 Sep 2001, Philip Kendall wrote:
> What version of Perl are we requiring to bootstrap Parrot? At the
> moment, things fail with 5.005 because:
>
> 2) The use of `!' to pack() in the assembler.
Oops. My fault. I forgot that was a new addition.
It's not really a big problem. You can
I'm seriously investigating the possibility of changing IV and NV to something
more readable.
(But for those of you who are following language-dev, don't tell 'em because
then they'll think they've won. ;)
--
I don't understand how people can think SCSI is anything more quirky
than a genius wi
On Thu, Sep 20, 2001 at 02:49:01PM +0100, Simon Cozens wrote:
> It's applied; just resync.
Same make warnings as before. But the tests are now all:
$ perl5.6.1 -Ilib t/op/basic.t
1..2
Invalid type in pack: 'q' at assemble.pl line 77.
not ok 1 - branch_ic
# Failed test (Parrot/Test.pm at li
What version of Perl are we requiring to bootstrap Parrot? At the
moment, things fail with 5.005 because:
1) The `use warnings;' in Config_pm.in.
2) The use of `!' to pack() in the assembler.
I guess we can just remove the use warnings, but the `!' is more of a
problem?
Phil
--
Philip Kenda
On Thu, Sep 20, 2001 at 10:38:10AM -0400, Andy Dougherty wrote:
> This patch does two only somewhat related things.
>
> Parrot/Opcode.pm: Change the hard-wired assumption that sizeof(nv) =
> 2*sizeof(iv) to a PConfig-type computed value.
>
> Parrot/Test.pm: Change it to run with the perl that
This patch does two only somewhat related things.
Parrot/Opcode.pm: Change the hard-wired assumption that sizeof(nv) =
2*sizeof(iv) to a PConfig-type computed value.
Parrot/Test.pm: Change it to run with the perl that was used to generate
this version of Parrot. This is useful if, for example
[EMAIL PROTECTED] (Andy Dougherty) writes:
[...]
> That's because assemble.pl hasn't been patched yet to use the right
> pack_type. You can either apply my patch from yesterday [...]
If you sign up for an account at http://dev.perl.org/auth/account I am
sure that Dan and Simon will let me flip
[EMAIL PROTECTED] (Simon Cozens) writes:
[...]
> So, if you're running on one of the core platforms, please check out a *clean*
> CVS copy, try and build and post the output of make test.
On FreeBSD 4.x all passes (or skips) except the first t/op/integer
test. (as other people have mentioned).
On Thu, 20 Sep 2001, Simon Cozens wrote:
> On Wed, Sep 19, 2001 at 02:51:19PM -0400, Andy Dougherty wrote:
> > This might help a bit.
>
> It does; Parrot is now working to at least some degree on Tru64.
Your job has just begun :-).
Seriously, some serious thought is needed about integral and
Ok, I applied Damien's integer.t fix and we now get:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/op/number.t7 1792237 30.43% 1 7 9 11 13 15 17
4 subtests skipped.
Failed 1/5 test scri
After one more change to process_opfunc.pl we get the following:
Failed TestStat Wstat Total Fail Failed List of Failed
---
t/op/integer.t4 1024264 15.38% 1 3 21 23
t/op/number.t 7 179223
On Thu, Sep 20, 2001 at 09:00:20AM +0100, Simon Cozens wrote:
> So, if you're running on one of the core platforms, please check out a *clean*
> CVS copy, try and build and post the output of make test.
FWIW, here's the current state of Tru64:
Failed TestStat Wstat Total Fail Failed List o
On Thu, Sep 20, 2001 at 09:22:50AM -0400, Michael G Schwern wrote:
> > That's because assemble.pl hasn't been patched yet to use the right
> > pack_type. You can either apply my patch from yesterday or you can
> > hand-patch the pack_type for 'i' to be 'q'.
>
> This one?
> http:[EMAIL PROTECTED]
In an effort to rest my braine from a coredumping perl5 I started to think a bit on
threading under parrot?
While it has been decided that perl should be using ithread like threading, I guess
that is irelevant at the parrot level. Are you
going to have one "virtual cpu" per thread with it's own
[EMAIL PROTECTED] (Nicholas Clark) writes:
> 2: I've not tried compiling parrot apart from the 0.01 snapshot (yet)
>[and as I've not real all the threads offhand I don't know where the
> CVS is]
http://cvs.perl.org/ :-)
--
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
These are the minimal fixes for smoking to take effect.
After these are in, I'll release Parrot::Smoke
* Makefile.in
* it is $(INC)/config.h, not config.h
* .o => $(O)
* test_main.c
* _read was ok when it was inside
ifdef WIN32
now it must be read ( or it fails in
no
On Tue, 18 Sep 2001, H.Merijn Brand wrote:
[...]
> > it's only updated every 6th hour. Maybe I'll get time to get it to
> > update more often (but not create a snapshot) tonight.
>
> From all my machines I get
>
> i2:/l1/pro/3gl/CPAN/parrot 104 > rsync -avz rsync://cvs.perl.org::parrot-HEAD/ .
On Wed, Sep 19, 2001 at 02:51:19PM -0400, Andy Dougherty wrote:
> This might help a bit.
It does; Parrot is now working to at least some degree on Tru64.
Andy, I love you and I want to have your children.
--
void russian_roulette(void) { char *target; strcpy(target, "bullet"); }
Don't forget that this patch requires the configure patch by Brent that was
just a couple of messages back.
-Original Message-
From: Michael G Schwern
To: Andy Dougherty
Cc: [EMAIL PROTECTED]
Sent: 9/20/2001 8:22 AM
Subject: Re: Complete failure on Linux/PowerPC with 64bit ints.
On Thu,
On Thu, Sep 20, 2001 at 09:03:45AM -0400, Andy Dougherty wrote:
> On Thu, 20 Sep 2001, Michael G Schwern wrote:
> > But if we run Configure.pl with bleadperl that *does* use 64bit ints
> > and has debugging flags on, there's trouble.
>
> > And all of the tests fail with "This isn't Parrot bytecod
On Thu, 2001-09-20 at 00:38, Simon Cozens wrote:
> On Wed, Sep 19, 2001 at 11:29:08PM -0500, Brian Wheeler wrote:
> > The only incompatibility I've introduced is now assemble.pl won't read
> > from stdin...you have to give it a filename. Patches welcome!
>
> And, of course, these beautiful new f
Michael --
Thanks. Applied.
On Thu, 2001-09-20 at 04:00, Michael L Maraist wrote:
> Guess you're the man to see about a zebra... Well, an equal sign if you don't
> squint really hard.
>
> Version 1.6 line 613
> You have
> $string =~ s/([^\\])\$((([A-Za-z][A-Za-z0-9_]*)\b)|({[A-Za-z][A-Za-z0=9_]
On Thu, 20 Sep 2001, Michael G Schwern wrote:
> But if we run Configure.pl with bleadperl that *does* use 64bit ints
> and has debugging flags on, there's trouble.
> And all of the tests fail with "This isn't Parrot bytecode!"
That's because assemble.pl hasn't been patched yet to use the right
Simon --
> But this still sucks:
>
> while (code >= code_start && code < (code_start + code_size) && code->i) {
> DO_OP(code, temp, func, interpreter);
> }
>
> Three tests and an addition each op. At the *very least*, we should store
> code_end = code_start + code_size. And at b
1 - 100 of 120 matches
Mail list logo
