Re: More speed trials

2001-10-06 Thread Buggs

On Sunday 07 October 2001 01:16, Bryan C. Warnock wrote:
[...]
 One of the more interesting discoveries?  Adding a 'default:' case to the
 switch slowed down the Linux runs by several percent.

In that, umh, case: do you have an explanation
or could you provide the code?


Buggs



Re: Solaris problems with trans.t

2001-09-29 Thread Buggs

On Saturday 29 September 2001 16:23, Gibbs Tanton - tgibbs wrote:
 Ok, I've added (NV) to all of the integer trans ops arguments.  See if that
 helps.

It gives some warnings

basic_opcodes.c, line 226: warning: statement not reached
basic_opcodes.c, line 234: warning: statement not reached
basic_opcodes.c, line 270: warning: statement not reached

but make test is ok.

Leaves OpenVMS.


Buggs



Re: Cygwin Problems (was: [PATCH assemble.pl] Fix binary values i n bytecode)

2001-09-28 Thread Buggs

On Friday 28 September 2001 19:55, Gibbs Tanton - tgibbs wrote:
 Ooohh, that's bad.  Cygwin works fine for me.  What test is it failing on?
 What version of perl?

I reinstalled Cygwin with Default Text File Type set to Unix
instead of DOS and the tests went ok.
Don't know if that's good or bad.

Buggs



Solaris problems with trans.t

2001-09-28 Thread Buggs

Hoi,

the solaris math functions(sin() ...)
do not return the same value as perl when
called with an integer.
This causes the trans.t to fail.
On solaris sin(1) != sin(1.0).

Buggs



Re: Solaris problems with trans.t

2001-09-28 Thread Buggs

On Saturday 29 September 2001 04:45, Gibbs Tanton - tgibbs wrote:
 In perl sin(1) != sin(1.0) or in C or in both?

 Also, what version of the OS is this, SunOS 5.8 works fine.

Perl equal and C not equal, that is.

bash-2.03$ perl -le 'if(sin(1) == sin(1.0)){print equal}else{print not equal}'
equal
bash-2.03$ ./sin
not equal
bash-2.03$ cat sin.c
# include math.h
int
main()
{
if(sin(1) == sin(1.0))
{
printf(equal\n);
}
else
{
printf(not equal\n);
}
return(1);
}
bash-2.03$ uname -a
SunOS usf-cf-sparc-solaris-2 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-60
bash-2.03$ perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
osname=solaris, osvers=2.8, archname=sun4-solaris
uname='sunos localhost 5.8 sun4u sparc sunw,ultra-1 '
hint=previous, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
cc='cc', optimize='-xO3 -xdepend', gccversion=
cppflags=''
ccflags =''
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
alignbytes=8, usemymalloc=n, prototype=define
  Linker and Libraries:
ld='cc', ldflags =''
libpth=/lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -ldl -lm -lc -lcrypt
libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-R 
/usr/perl5/5.00503/sun4-solaris/CORE'
cccdlflags='-KPIC', lddlflags='-G'
 
 
Characteristics of this binary (from libperl):
  Built under solaris
  Compiled at Dec 22 1999 00:00:57
  @INC:
/usr/perl5/5.00503/sun4-solaris
/usr/perl5/5.00503
/usr/perl5/site_perl/5.005/sun4-solaris
/usr/perl5/site_perl/5.005
.
 




Re: [COMMIT] Preparation for putting NVs in const_table.

2001-09-26 Thread Buggs

On Wednesday 26 September 2001 23:09, Simon Cozens wrote:
 On Wed, Sep 26, 2001 at 02:18:11PM -0400, Gregor N. Purdy wrote:
  I've just committed the changes I posted a few days back that prepare
  for putting NVs in the const_table. Stay tuned for more, but here's
  the bullets for this commit:

 These are pretty huge changes. Can I get some status reports from
 people before we go much further?

bitwise.t fails now on freebsd (intel) perl 5.005_03.

Buggs



Re: [COMMIT] Preparation for putting NVs in const_table.

2001-09-26 Thread Buggs

On Thursday 27 September 2001 01:27, Gregor N. Purdy wrote:
 On Wed, 26 Sep 2001, Andreas Buggs Hauser wrote:
  On Wednesday 26 September 2001 23:09, Simon Cozens wrote:
   On Wed, Sep 26, 2001 at 02:18:11PM -0400, Gregor N. Purdy wrote:
I've just committed the changes I posted a few days back that prepare
for putting NVs in the const_table. Stay tuned for more, but here's
the bullets for this commit:
  
   These are pretty huge changes. Can I get some status reports from
   people before we go much further?
 
  bitwise.t fails now on freebsd (intel) perl 5.005_03.

 Make sure you've got the latest bitwise.t, which has 'end' in a
 few key places...

Pretty sure because I removed the 'end' 's and tested again.
After that I did a 

cvs checkout -D 2001-09-25

and it worked again.

Sorry :(

Buggs



Re: Wow.

2001-09-24 Thread Buggs

On Monday 24 September 2001 03:27, Dan Sugalski wrote:
 At 01:47 AM 9/24/2001 +0100, Simon Cozens wrote:
 http://astray.com/mandlebrot.pasm
 
 Leon, you're a sick, sick man.

 Okay, I think that means we need to weld in bitmap handling opcodes into
 the interpreter. :)

 Also looks like there are some bugs in the num register handling that need
 fixing. :(


Just forgotten or is there more to it?

Buggs


Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.22
diff -u -3 -p -r1.22 basic_opcodes.ops
--- basic_opcodes.ops   2001/09/21 09:25:39 1.22
+++ basic_opcodes.ops   2001/09/24 10:22:56
@@ -693,3 +693,7 @@ AUTO_OP shr_i_ic {
 AUTO_OP xor_i {
   INT_REG(P1) = INT_REG(P2) ^ INT_REG(P3);
 }
+/* SET Nx, Nx */
+AUTO_OP set_n {
+  NUM_REG(P1) = NUM_REG(P2);
+}
Index: opcode_table
===
RCS file: /home/perlcvs/parrot/opcode_table,v
retrieving revision 1.21
diff -u -3 -p -r1.21 opcode_table
--- opcode_table2001/09/19 22:57:15 1.21
+++ opcode_table2001/09/24 10:22:56
@@ -44,6 +44,7 @@ dec_i_ic  2   I i
 # NUM ops

 set_n_nc   2   N n
+set_n  2   N N
 add_n  3   N N N
 sub_n  3   N N N
 mul_n  3   N N N



Platforms Status

2001-09-24 Thread 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
??
===
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)
===



Buggs



Re: Platforms Status

2001-09-24 Thread Buggs

On Monday 24 September 2001 22:48, Simon Cozens wrote:
 On Mon, Sep 24, 2001 at 10:44:33PM +0200, Buggs wrote:
  Tru64
  make ok / test fails

 Can I have some more data on this? Works perfectly here.

The machine from Compaq Testdrive.

Compaq Tru64 Unix 5.1(JAVA)   ES40 4@667MHz (ev6)   telnet to 
192.233.54.230


Could also be the Perl, which is 5.005_03.
Same problems as on FreeBSD (Alpha).

A lot of these

# Failed test (Parrot/Test.pm at line 74)
#  got: ''
# expected: 'ok 1
ok 2

Buggs



Re: Quick Test hack for someone

2001-09-24 Thread Buggs

On Tuesday 25 September 2001 00:00, Simon Cozens wrote:
 When tests fail for Really Bad reasons, they tend to do something like
 this:

 Got: '
 '
 Expected: '
 ok 1
 ...
 '

 It'd be really nice if we could intercept that and give more detail on why
 the test failed. Did the assembler compile to a PBC ok? Did the interpreter
 segfault? (This is what usually happens.) Or did something else happen?

 Would make debugging a lot quicker.


The hack is to upgrade Test::Harness :)
Looks much less wiered.

BTW after updating cygwin(1.3.2 - 1.3.3) it compiles.


Buggs



Re: Platforms Status

2001-09-24 Thread Buggs

On Monday 24 September 2001 22:59, Buggs wrote:
 On Monday 24 September 2001 22:48, Simon Cozens wrote:
  On Mon, Sep 24, 2001 at 10:44:33PM +0200, Buggs wrote:
   Tru64
   make ok / test fails
 
  Can I have some more data on this? Works perfectly here.

 The machine from Compaq Testdrive.

 Compaq Tru64 Unix 5.1(JAVA)   ES40 4@667MHz (ev6)   telnet to
 192.233.54.230

Actually that one sucks.


But this one:
Compaq Tru64 Unix 5.1a(JAVA)  DS10-L 1@466MHz (ev6) telnet to 
192.233.54.152

with perl5.6 does a lot nicer.
stacks.t produces nice core dumps so.


Buggs



Re: [patch] A few fixes to the Jako compiler

2001-09-15 Thread Buggs

Hoi,

Just not to lie.

Buggs

Index: little_languages/jakoc
===
RCS file: /home/perlcvs/parrot/little_languages/jakoc,v
retrieving revision 1.1
diff -u -3 -p -r1.1 jakoc
--- little_languages/jakoc  2001/09/15 20:58:05 1.1
+++ little_languages/jakoc  2001/09/16 00:55:32
@@ -271,7 +271,7 @@ sub begin_if_block
 printf %-12s %-8s %s\n, ${prefix}_NEXT:, gt, $args[0], $args[1], 
${prefix}_REDO, ${prefix}_LAST;
 printf %s_REDO:\n, $prefix;
   } else {
-printf(STDERR jako: Syntax error. Unrecognized condition in while on line 
%d.\n, $line);
+printf(STDERR jako: Syntax error. Unrecognized condition in if on line %d.\n, 
+$line);
   }
 }



Re: PDD 6 (parrot assembly) now in CVS

2001-09-14 Thread Buggs

On Thursday 13 September 2001 18:26, Dan Sugalski wrote:
 At 10:21 AM 9/13/2001 -0600, Nathan Torkington wrote:
 Dan Sugalski writes:
   Lines 249 to 261 seem to duplicate 204 to 216.
  
   D'oh! Thanks, fixed.
 
 Oh man, good luck building a unit testing system for the docs :-)

 That's actually an interesting thing to consider. We could check for
 duplicate headers (=item, =head1, =head2, =head3), run MD5 checksums on
 paragraphs, and other mildly interesting things.

Will do that next if still considered to be a good thing :-)
What else to check?

 Anyone care to take a shot at it? I hear there's a good text-processing
 language on the net somewhere we could grab and use... ;-)

This should spit out the longest duplicate string in a file
and give its byte positions in that file.


Buggs


 longdup.pl


Re: PDD 6 (parrot assembly) now in CVS

2001-09-13 Thread Buggs

On Wednesday 12 September 2001 17:45, Dan Sugalski wrote:
 I just checked PDD 6 into CVS. (parrot/docs/parrot_assembly.pod) Some
 changes since last time, so check it out to see what's up.

   Dan

Lines 249 to 261 seem to duplicate 204 to 216.

Buggs

===
RCS file: /home/perlcvs/parrot/docs/parrot_assembly.pod,v
retrieving revision 1.1
diff -u -3 -p -r1.1 parrot_assembly.pod
--- docs/parrot_assembly.pod2001/09/12 15:44:40 1.1
+++ docs/parrot_assembly.pod2001/09/13 16:06:44
@@ -246,20 +246,6 @@ omitted, increment is 1.
 Decrement register x by nn. nn is an integer constant. If nn is
 omitted, decrement by 1.
 
-=item iton Nx, Iy
-
-Copy the integer value from register y to the numeric register x.
-
-=item ntoi Ix, Ny
-
-Copy the number from register y to register x. Copy is truncated, and
-may be capped if it is too large or small for an integer.
-
-=item tostring Sx, ty, Iz
-
-Take the value in register y and convert it to a string of type z,
-storing the result in string register x.
-
 =back
 
 =head2 Transcendental operations




Re: PDD 6 (parrot assembly) now in CVS

2001-09-13 Thread Buggs

On Thursday 13 September 2001 18:26, Dan Sugalski wrote:
 At 10:21 AM 9/13/2001 -0600, Nathan Torkington wrote:
 Dan Sugalski writes:
   Lines 249 to 261 seem to duplicate 204 to 216.
  
   D'oh! Thanks, fixed.
 
 Oh man, good luck building a unit testing system for the docs :-)

 That's actually an interesting thing to consider. We could check for
 duplicate headers (=item, =head1, =head2, =head3), run MD5 checksums on
 paragraphs, and other mildly interesting things.

 Anyone care to take a shot at it? I hear there's a good text-processing
 language on the net somewhere we could grab and use... ;-)

Yeah, someone really should implement such a language.

Interesting in the context of testing dox could be,
Dr. Dobb's, #323 April 2001, p. 145, Suffix Arrays by Jon Bentley.

Listing One is stated to have found the longest repeated string
in the 4,460,056 character's of the King James Bible in about 36 seconds
on a 600-MHz Celeron processor.

Have fun,
Buggs