Re: Parrot Shootout

[Joshua Isom]

I just wrote up the binarytrees test in pir, based on the c version. 
Although I haven't waited more than twenty minutes yet, I can't get it 
working with the argument being 16(what they test with) beyond printing 
the first line.  The results I'm getting, it's slow, and I don't have 
enough ram.  Right now, on FreeBSD, it's taking up over 280 megs of 
memory, varying between 50 and 80 megs resident.  And apparently 
something in the jit core with FreeBSD 5.4 is broken...  Something with 
the integers...


Anyway, I've attached the file in case anyone else has better luck.  
I'm using parrot r10431 at the moment on OS X, and 0.3.1 on FreeBSD.  
For smaller numbers, it's usable.  With twelve, I get around 30 seconds 
to a minute for both versions/archs.  From my rough numbers of it, it 
should only take about about 15 minutes, but the memory constraint 
slows it down for me.


I notice that a lot of the code pertains to lines 42-47, creating an 
array and storing values in it.  But by far, the biggest part of the 
execution is tied in calling subroutines and returning.  With an 
argument of 8, invokecc(and it's ilk) are called 100701 times.  Either 
there's a problem with the code that I'm not aware of, or you have a 
great new test for debugging the gc...




binarytrees.pir
Description: Binary data

Re: Bug or feature? Probably bug with macros

[Leopold Toetsch]

On Dec 11, 2005, at 0:53, Joshua Isom wrote:

Since it's not documented at all that I've seen, either for or 
against, I'm wondering what's the arguments to macros are supposed to 
be.  Consider this code.



.sub main :main
.IfElse(TRUE,
print "True\n"
,
print "False\n"
)


This is at least astonishing. The argument lexer obiously just scans 
for the next comma.



--
This will print True, then False, then False.  Comma's aren't allowed 
for any of the statements(and they can be multilined), even commented 
out ones(which if this "feature" isn't a bug, that part is).  By using 
pir's syntax, a lot of commas are eliminated, so it's at least 
somewhat of a practical thing.  But since I doubt this is at all 
intended, is it a bug?


Or an undocumented feature. And untested. Dunno if we should keept it.


Joshua


leo

Re: [perl #37788] [TODO] dir reorg: move imcc/docs/ to docs/imcc/

[Leopold Toetsch]

On Dec 11, 2005, at 0:49, Joshua Isom wrote:

The documentation thing I've noticed too.  A big reason I use perl is 
there's a lot of documentation and I was able to teach myself.  That's 
not very easy with a lot of other languages.  I don't deal at all with 
PAST because the best reference documentation would be 
examples/past/hello.past and it's not helpful.


PAST isn't much more than 'hello.past'. When you search the p6i 
archives you'll find some messages about PAST and that it's up to HLL 
authors to specify the nodes and what not.


I think it'd help to have a wiki available for learning each of pasm, 
pir, and past.


I'd appreciate to have the docs inside parrot, but any effort tp 
improve docs is of course welcome.



Joshua


leo

Re: Parrot Shootout

[Leopold Toetsch]

Joshua Isom wrote:
I just wrote up the binarytrees test in pir, based on the c version. 
Although I haven't waited more than twenty minutes yet, I can't get it 
working with the argument being 16(what they test with) beyond printing 
the first line.  The results I'm getting, it's slow, and I don't have 
enough ram.  Right now, on FreeBSD, it's taking up over 280 megs of 
memory, varying between 50 and 80 megs resident.  And apparently 
something in the jit core with FreeBSD 5.4 is broken...  Something with 
the integers...


Actually it took 1.3 GB of RAM to finish. Woot. And Chip is to blame 
this time not me :)


  PMC_cont_ASSIGN(SELF, new_foo(something));

did evaluate the new_foo twice i.e. each return continuation helper 
struct was allocate twice (and freed once).


Now it finishes in 2m44 [1] taking 53 M RAM for N=16. Still too slow 
with too much memory used.


I've delete the whole del_tree stuff too, it might just slows things down.

I notice that a lot of the code pertains to lines 42-47, creating an 
array and storing values in it.  But by far, the biggest part of the 
execution is tied in calling subroutines and returning.  


Yep. 3 tips:
  a) use Parrot -C
  b) use {Fixed,Resizable}PMCArray instead of Array
  c) always use the same call/return signature
  e.g. don't mix ack(x,y) and ack(x, 1)
  that is get rid of the constant by using a temp $I1 = 1 for the 
2nd case


[1] It takes now 2m11 with c) done too

Attached is my version of biarytree.pir.

leo

.sub itemcheck
.param pmc node
$I0 = exists node[0]
unless $I0 goto final
.local pmc tmp
tmp = node[0]
unless_null tmp, else
$I0 = node[2]
.return($I0)
else:
# tmp = node[0]
$I0 = itemcheck(tmp)
tmp = node[1]
$I1 = itemcheck(tmp)
$I0 -= $I1
$I1 = node[2]
$I0 += $I1
final:
.return($I0)
.end

.sub bottomuptree
.param int item
.param int dep
.local pmc left, right, tree
.local int item2
unless dep > 0 goto else
item2 = item * 2
$I0 = item2 - 1
dec dep
left = bottomuptree($I0, dep)
right = bottomuptree(item2, dep)
goto endif
else:
null left
null right
endif:
tree = new .FixedPMCArray
tree = 3
tree[0] = left
tree[1] = right
tree[2] = item
.return(tree)
.end

.sub main :main
.param pmc argv
.local int N, dep, mindepth, maxdepth, stretchdepth
.local pmc stretchtree, longlivedtree, tmptree
$S0 = argv[1]
N = $S0
mindepth = 4
unless N < 6 goto else
maxdepth = mindepth + 2
goto endif
else:
maxdepth = N
endif:
stretchdepth = maxdepth + 1
$I0 = 0
stretchtree = bottomuptree($I0, stretchdepth)
$I0 = itemcheck(stretchtree)

print "stretch tree of depth "
print stretchdepth
print "\t check: "
print $I0 
print "\n"

null stretchtree
$I0 = 0
longlivedtree = bottomuptree($I0, maxdepth)

dep = mindepth
beginfor_1:

.local int i, iterations, check

$N0 = maxdepth - dep
$N0 += mindepth
$N1 = 2
$N2 = pow $N1, $N0
iterations = $N2

check = 0

i = 1
beginfor_2:
   noop

tmptree = bottomuptree(i, dep)
$I0 = itemcheck(tmptree)
check += $I0
$I0 = 0 - i
tmptree = bottomuptree($I0, dep)
$I0 = itemcheck(tmptree)
check += $I0

inc i
if i <= iterations goto beginfor_2
$I0 = iterations * 2
print $I0 
print "\t trees of depth "
print dep
print "\t check: " 
print check
print "\n"


dep += 2
if dep <= maxdepth goto beginfor_1

$I0 = itemcheck(longlivedtree)
print "long lived tree of depth "
print maxdepth
print "\t check: "
print $I0 
print "\n"

.end

Re: [perl #37865] [RESOLVED] [PATCH t/perl/Parrot_IO.t] Fix Failing Test #23

[Alberto Simões]

Just to change CREDITS, please.

Joshua Hoblitt via RT wrote:
According to our records, your request regarding 
  "[PATCH t/perl/Parrot_IO.t] Fix Failing Test #23" 
has been resolved. 


If you have any further questions or concerns, please respond to this message.

For other topics, please create a new ticket.

Please don't feel obligated to say "Thanks" or "Kudos" or "I owe you a beer" -- 
if you respond to this message it will reopen the ticket. If you must, please send email directly to the 
person who handled your ticket, and not to the tracking system.

https://rt.perl.org/rt3/Ticket/Display.html?id=37865 >


--
Alberto Simões - Departamento de Informática - Universidade do Minho
 Campus de Gualtar - 4710-057 Braga - Portugal
Index: CREDITS
===
--- CREDITS (revision 10442)
+++ CREDITS (working copy)
@@ -25,7 +25,7 @@
 D: Building on various platforms.
 
 N: Alberto Manuel Brandao Simoes
-E: [EMAIL PROTECTED]
+E: [EMAIL PROTECTED]
 D: reported a problem with File::Spec in Parrot::IO::Directory and provided a
 partial patch to fix it.
 

Re: b0rken www docs

[Will Coleda]

Thanks, applied with modifications. Also removed pointer to old rx ops.

On Dec 10, 2005, at 8:11 PM, Joshua Hoblitt wrote:


Someone on #parrot just pointed out that the docs at
http://www.parrotcode.org/docs/ops/ have been b0rken by the recent  
tree

reorganization(s).  I've already submitted a patch that fixes this to
Will.

Cheers,

-J

--

Re: Parrot Shootout

[Leopold Toetsch]

Leopold Toetsch wrote:


I've timed Ack(3, 9) with an optimized Parrot build:

Python  13.7
Parrot -j   15.3
Parrot -C   13.8


Down now (r10445) at:

  parrot -C ack.pir 5.7s
  parrot -C binarytrees 16 1m14s

That is a little code cleanup was good for 100% speedup ;-)

This is a AMD X2 3800+ running at 2000 Mhz. It's BTW not easy to run 
benchmarks on that machine, the first few timings where 23-26 secs, 
obviously PowerNow had reduced cpu freq to ~50%.


Well powersave -f helps a lot,

leo

Secure execution of Remote Code

[Bryan Burgers]

I was wondering... Are there plans to have parrot securely execute
remote code, similar to JVM, so a person can have a parrot plug-in in
their browser (for example), and run parrot 'applets' with the
confidence that they are safe?
Or is this not really part of the plan?
If there's information about this already, you can just point me to
it, but I couldn't find any.  Thanks for the help,
Bryan Burgers

Re: Secure execution of Remote Code

[Luke Palmer]

On 12/11/05, Bryan Burgers <[EMAIL PROTECTED]> wrote:
> I was wondering... Are there plans to have parrot securely execute
> remote code, similar to JVM, so a person can have a parrot plug-in in
> their browser (for example), and run parrot 'applets' with the
> confidence that they are safe?
> Or is this not really part of the plan?
> If there's information about this already, you can just point me to
> it, but I couldn't find any.  Thanks for the help,

Well, the best place to ask this would actually be on
[EMAIL PROTECTED]  This list is not really concerned with
parrot, at least at the moment (but that looks like it will change
pretty soon).

And, I don't know much about it, but I do believe that this is part of
the plan.  When Dan Sugalski was our grand architect, he mentioned it
a fair amount.  I think that we use a different runcore for code that
needs to be safe; i.e. no JIT allowed.

Luke

Re: Parrot Shootout

[Leopold Toetsch]

On Dec 11, 2005, at 17:01, Leopold Toetsch wrote:


Leopold Toetsch wrote:


I've timed Ack(3, 9) with an optimized Parrot build:
Python  13.7
Parrot -j   15.3
Parrot -C   13.8


Down now (r10445) at:

  parrot -C ack.pir 5.7s
  parrot -C binarytrees 16 1m14s


./parrot -C ack.pir4.9s
./parrot -C binarytrees.pir 1659.1s

I'm stopping the optimization game now, before we are at incredible 
speed and/because the low hanging fruit is already consumed.


All tests with Configure.pl --optimize (it doesn't make sense to run 
comparable bechmarks w/o -Ox) on linux/x86 with a 2 GHz athlon w 512K 
cache.


leo

Re: Parrot Shootout

[Leopold Toetsch]

On Dec 11, 2005, at 22:25, Leopold Toetsch wrote:


./parrot -C ack.pir4.9s
./parrot -C binarytrees.pir 1659.1s


And another f'up me: should we collect these shootout benchmarks in a 
separate directory, with tests attached (with reduced N aka reduced 
runtime)?


Are there plans to submit these tests?

leo

Re: Parrot Shootout

[Joshua Hoblitt]

On Sun, Dec 11, 2005 at 11:07:32PM +0100, Leopold Toetsch wrote:
> 
> On Dec 11, 2005, at 22:25, Leopold Toetsch wrote:
> 
> >./parrot -C ack.pir4.9s
> >./parrot -C binarytrees.pir 1659.1s
> 
> And another f'up me: should we collect these shootout benchmarks in a 
> separate directory, with tests attached (with reduced N aka reduced 
> runtime)?
> 
> Are there plans to submit these tests?

It might be interesting to have a few small benchmarks as part of a
smoke submission...

-J

--


pgpqrgaNIRylS.pgp
Description: PGP signature

Re: Bug or feature? Probably bug with macros

[Joshua Isom]

It could be very beneficial for debugging.  My debugger tends to be a 
lot of print statements, so something like


.globalconst int DEBUG = 1
.macro IfDebug(level, code)
unless .level >= DEBUG goto .$endif
.code
.local $endif:
.endm

.IfDebug(1,
print "var = "
print var
)

would be useful, but nevertheless, pir statements that span multiple 
lines is just weird to me.  I think I'm most surprised about that.  Is 
it odd that I find the fact that it allows multiple lines more 
surprising than allowing code?


On Dec 11, 2005, at 4:14 AM, Leopold Toetsch wrote:



On Dec 11, 2005, at 0:53, Joshua Isom wrote:

Since it's not documented at all that I've seen, either for or 
against, I'm wondering what's the arguments to macros are supposed to 
be.  Consider this code.



.sub main :main
.IfElse(TRUE,
print "True\n"
,
print "False\n"
)


This is at least astonishing. The argument lexer obiously just scans 
for the next comma.



--
This will print True, then False, then False.  Comma's aren't allowed 
for any of the statements(and they can be multilined), even commented 
out ones(which if this "feature" isn't a bug, that part is).  By 
using pir's syntax, a lot of commas are eliminated, so it's at least 
somewhat of a practical thing.  But since I doubt this is at all 
intended, is it a bug?


Or an undocumented feature. And untested. Dunno if we should keept it.


Joshua


leo

Re: Parrot Shootout

[Dr.Ruud]

Roger Browne:

> Unfortunately I could only get to Ack(3, 6) before parrot aborted with
> "maximum recursion depth exceeded", at recursion depth 1000.


Alternative:

#!/usr/bin/perl

use strict;
use warnings;

use Memoize;

{ local ($,, $\) = ("\t", "\n");

  sub ack {
return $_[1] +1 if 0 == $_[0];

return ack($_[0] -1, 1) if 0 == $_[1];

return ack($_[0] -1, ack($_[0], $_[1] -1));
  }

  memoize('ack');

  my $base = 3;
  print "Ack($base, $_): ", ack($base, $_) for (0..13);
}

-- 
Affijn, Ruud

"Gewoon is een tijger."

Re: Some thoughts on threading

[Sam Vilain]

On Thu, 2005-12-08 at 17:16 +0100, Ron Blaschke wrote:
> The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software."
> [1] He starts with "The biggest sea change in software development since
> the OO revolution is knocking at the door, and its name is Concurrency."

Perhaps have a read of:

http://svn.openfoundry.org/pugs/docs/AES/S17draft.pod

Two non-traditional methods of concurrency are discussed;

  * atomic blocks - an atomic { } guard around a block that, assuming
the block performs no I/O, will guarantee atomic
success or failure of the block.

  * co-routines - essentially co-operative multitasking between
  'blocking' threads that actually switch tasks when
  they block (or yield).

There is also some stuff there on other types of timesharing and
multiprocessing - Threads, Processes and Multiplexing (like Ruby).

Sam.

Re: Bug or feature? Probably bug with macros

[Leopold Toetsch]

On Dec 11, 2005, at 23:45, Joshua Isom wrote:

It could be very beneficial for debugging.  My debugger tends to be a 
lot of print statements, so something like


.globalconst int DEBUG = 1
.macro IfDebug(level, code)
unless .level >= DEBUG goto .$endif
.code
.local $endif:
.endm

.IfDebug(1,
print "var = "
print var
)

would be useful, but nevertheless, pir statements that span multiple 
lines is just weird to me.  I think I'm most surprised about that.  Is 
it odd that I find the fact that it allows multiple lines more 
surprising than allowing code?


As said, it was surprising me too. Anyway, I think typical use cases 
are debugging and I prefer a solution that boils down to no code at all 
for the non-debug case, like C's assert with -DNDEBUG.


With a bit of generalization we could have some -Ddefine [1] stuff that 
{en,dis}ables lexing of lines within the scope of that define.


[1] -D\d+ is used for debugging, -D[a-zA-Z\w*] is still avaiable for 
define (or we change current -D)


leo

Re: Parrot Shootout

[Leopold Toetsch]

On Dec 10, 2005, at 19:18, Dr.Ruud wrote:


Roger Browne:


Unfortunately I could only get to Ack(3, 6) before parrot aborted with
"maximum recursion depth exceeded", at recursion depth 1000.



Alternative:



use Memoize;


Sure. And there is a (inline) memoized perl Ack already, which is one 
of the fastest of all tests submitted.


The goal of these benchmarks is to run 'as is' with the same algorithm.

leo

Re: Parrot Shootout

[Joshua Isom]

Are there plans to submit these tests?

leo


From the faq...

Please will you include my favourite language?
Maybe we will when you write 15 of the benchmark programs in your 
favourite language, and contribute them to "The Computer Language 
Shootout" :-)


From the all benchmarks page...

And remember, languages that implement more benchmarks will move to the 
top of the list, and those with many missing benchmarks (No Program, 
Error, Timeout) will stay at the bottom!


So why submit until there's a reasonable collection?  Oh, attached is 
fannkuch, works fairly well.  Only about four seconds for me, three 
with an optimized build.  And given that their machine's faster(and x86 
linux as opposed to my ppc OSX), I think it's reasonable to say that 
parrot beats smalltalk gst.


I'll probably write more, it's somewhat random which order I go in...  
A startup program's easy to do...  Case sensitive, etc...


.sub main :main
print "hello world\n"
.end




fannkuch.pir
Description: Binary data

[perl #37887] Patch for tests.pod talking about testing parrot

[via RT]

# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #37887]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=37887 >


---
osname= linux
osvers= 2.4.26
arch=   i486-linux
cc= cc 
---
Flags:
category=docs
severity=none
ack=no
---

Index: docs/tests.pod
===
--- docs/tests.pod  (revision 10449)
+++ docs/tests.pod  (working copy)
@@ -5,12 +5,34 @@
 
 docs/tests.pod - Testing Parrot
 
-=head1 A basic guide to writing tests for Parrot
+=head1 A basic guide to writing and running tests for Parrot
 
 This is quick and dirty pointer to how tests for Parrot should be written.  The
 testing system is liable to change in the future, but tests written following
 the guidelines below should be easy to port into a new test suite.
 
+=head1 How to test parrot
+
+The easy way to test parrot is running C. If you have
+updated your code recently and tests began failing, go for a C and recompile parrot before complaining.
+
+If you architecture suport JIT, you can test parrot JIT engine using
+C. It works just like C, but uses the JIT
+engine when possible.
+
+=head2 Submitting smoke test results
+
+Parrot has a status page with smoke test results
+L. You can supply new tests
+results just running C. It will run the same tests as
+C would, but creating a HTML table with the test
+results. At the end, it will try to upload the test results to the
+smoke server.
+
+It is also possible to run a smoke test on JIT. For that, try running
+C.
+
 =head1 How to write a test
 
 New tests should be added to F<*.t> files. These test files can be found in the

---
Summary of my parrot 0.4.0 (r10446) configuration:
  configdate='Sun Dec 11 17:43:04 2005'
  Platform:
osname=linux, archname=i486-linux
jitcapable=1, jitarchname=i386-linux,
jitosname=LINUX, jitcpuarch=i386
execcapable=1
perl=/usr/bin/perl5.8.5
  Compiler:
cc='cc', ccflags=' -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE',
  Linker and Libraries:
ld='cc', ldflags=' -L/usr/local/lib',
cc_ldflags='',
libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp'
  Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC',
load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC'
  Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234, 
nv=double, numvalsize=8, doublesize=8

---
Environment:
HOMELANGLANGUAGELC_ALLLC_COLLATELD_LIBRARY_PATH
LOGDIRPATHPERL5_CPANPLUS_CONFIGSHELL

[perl #37888] Latest changes break JIT on FreeBSD and OS X

[via RT]

# New Ticket Created by  Joshua Isom 
# Please include the string:  [perl #37888]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=37888 >


With the binarytrees test(Leo's modifications), using -j causes a seg 
fault on FreeBSD 5.4, and "invoke() not implemented in class 'SArray' 
current instr.: 'main' pc 135 (binarytrees.leo.pir:45)" on OS X.  I'm 
using r10448 for both.

Re: [perl #37887] AutoReply: Patch for tests.pod talking about testing parrot

[Alberto Simoes]

As it is not easy to get the diff from this email, here it goes really 
in attach.


I know the text is not the best, but it is something to start with.

Parrot Assembler via RT wrote:

Greetings,

This message has been automatically generated in response to the
creation of a parrotbug regarding:
"Patch for tests.pod talking about testing parrot"

There is no need to reply to this message right now.  Your ticket has been
assigned an ID of [perl #37887].

Please include the string:
 [perl #37887]
In the subject line of all future correspondence about this issue. To do so, 
you may reply to this message.


Thank you,
  parrotbug

https://rt.perl.org/rt3/Ticket/Display.html?id=37887 
-

Received: (qmail 20403 invoked by alias); 11 Dec 2005 19:24:20 -
Received: (qmail 20399 invoked from network); 11 Dec 2005 19:24:19 -
Received: from localhost (HELO la.mx.develooper.com) (127.0.0.1) by localhost 
with SMTP; 11 Dec 2005 19:24:19 -
Received: (qmail 20396 invoked by alias); 11 Dec 2005 19:24:19 -
Received: from la.mx.develooper.com (HELO x1.develooper.com) (63.251.223.176) 
by la.mx.develooper.com (qpsmtpd/0.28) with SMTP; Sun, 11 Dec 2005 11:24:12 
-0800
Received: (qmail 20336 invoked by uid 225); 11 Dec 2005 19:24:09 -
Received: (qmail 20331 invoked by alias); 11 Dec 2005 19:24:08 -
Received: from eremita.di.uminho.pt (HELO eremita.di.uminho.pt) 
(193.136.19.131) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Sun, 11 Dec 
2005 11:24:00 -0800
Received: by eremita.di.uminho.pt (Postfix, from userid 1000) id 6748A157054; 
Sun, 11 Dec 2005 19:25:19 + (WET)
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Subject: Patch for tests.pod talking about testing parrot
X-Spam-Status: No, hits=-2.6 required=8.0 tests=BAYES_00
Return-Path: <[EMAIL PROTECTED]>
X-Spam-Check-BY: la.mx.develooper.com
X-Old-Spam-Status: No, hits=-2.6 required=8.0 tests=BAYES_00
Date: Sun, 11 Dec 2005 19:25:19 + (WET)
Received-SPF: neutral (x1.develooper.com: local policy)
Received-SPF: pass (x1.develooper.com: local policy)
X-Old-Spam-Check-BY: la.mx.develooper.com
Message-ID: <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Alberto Manuel Brandao Simoes)
X-RT-Original-Encoding: ascii
content-type: text/plain; charset="utf-8"


---
osname= linux
osvers= 2.4.26
arch=   i486-linux
cc= cc 
---

Flags:
category=docs
severity=none
ack=no
---

Index: docs/tests.pod
===
--- docs/tests.pod  (revision 10449)
+++ docs/tests.pod  (working copy)
@@ -5,12 +5,34 @@
 
 docs/tests.pod - Testing Parrot
 
-=head1 A basic guide to writing tests for Parrot

+=head1 A basic guide to writing and running tests for Parrot
 
 This is quick and dirty pointer to how tests for Parrot should be written.  The

 testing system is liable to change in the future, but tests written following
 the guidelines below should be easy to port into a new test suite.
 
+=head1 How to test parrot

+
+The easy way to test parrot is running C. If you have
+updated your code recently and tests began failing, go for a C and recompile parrot before complaining.
+
+If you architecture suport JIT, you can test parrot JIT engine using
+C. It works just like C, but uses the JIT
+engine when possible.
+
+=head2 Submitting smoke test results
+
+Parrot has a status page with smoke test results
+L. You can supply new tests
+results just running C. It will run the same tests as
+C would, but creating a HTML table with the test
+results. At the end, it will try to upload the test results to the
+smoke server.
+
+It is also possible to run a smoke test on JIT. For that, try running
+C.
+
 =head1 How to write a test
 
 New tests should be added to F<*.t> files. These test files can be found in the


---
Summary of my parrot 0.4.0 (r10446) configuration:
  configdate='Sun Dec 11 17:43:04 2005'
  Platform:
osname=linux, archname=i486-linux
jitcapable=1, jitarchname=i386-linux,
jitosname=LINUX, jitcpuarch=i386
execcapable=1
perl=/usr/bin/perl5.8.5
  Compiler:
cc='cc', ccflags=' -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE',
  Linker and Libraries:
ld='cc', ldflags=' -L/usr/local/lib',
cc_ldflags='',
libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp'
  Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC',
load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC'
  Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234, 
nv=double, numvalsize=8, doublesize=8


---
Environment:
HOMELANGLANGUAGELC_ALLLC_COLLATE

Re: [perl #37887] Patch for tests.pod talking about testing parrot

[chromatic]

On Sun, 2005-12-11 at 11:24 -0800, via RT wrote:

> Index: docs/tests.pod

Thanks, applied as 10451, along with some other spelling corrections.

-- c

Re: [perl #37891] Make smoke tests give progress indication

[Alberto Simoes]

Attached patch.

Parrot Assembler via RT wrote:

Greetings,

This message has been automatically generated in response to the
creation of a parrotbug regarding:
"Make smoke tests give progress indication"

There is no need to reply to this message right now.  Your ticket has been
assigned an ID of [perl #37891].

Please include the string:
 [perl #37891]
In the subject line of all future correspondence about this issue. To do so, 
you may reply to this message.


Thank you,
  parrotbug

https://rt.perl.org/rt3/Ticket/Display.html?id=37891 
-

Received: (qmail 2946 invoked by alias); 11 Dec 2005 21:46:40 -
Received: (qmail 2939 invoked from network); 11 Dec 2005 21:46:40 -
Received: from localhost (HELO la.mx.develooper.com) (127.0.0.1) by localhost 
with SMTP; 11 Dec 2005 21:46:40 -
Received: (qmail 2936 invoked by alias); 11 Dec 2005 21:46:40 -
Received: from la.mx.develooper.com (HELO x1.develooper.com) (63.251.223.176) 
by la.mx.develooper.com (qpsmtpd/0.28) with SMTP; Sun, 11 Dec 2005 13:46:33 
-0800
Received: (qmail 2850 invoked by uid 225); 11 Dec 2005 21:46:28 -
Received: (qmail 2845 invoked by alias); 11 Dec 2005 21:46:28 -
Received: from eremita.di.uminho.pt (HELO eremita.di.uminho.pt) 
(193.136.19.131) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Sun, 11 Dec 
2005 13:46:20 -0800
Received: by eremita.di.uminho.pt (Postfix, from userid 1000) id BE805157050; 
Sun, 11 Dec 2005 21:47:40 + (WET)
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Subject: Make smoke tests give progress indication
X-Spam-Status: No, hits=-2.6 required=8.0 tests=BAYES_00
Return-Path: <[EMAIL PROTECTED]>
X-Spam-Check-BY: la.mx.develooper.com
X-Old-Spam-Status: No, hits=-2.6 required=8.0 tests=BAYES_00
Date: Sun, 11 Dec 2005 21:47:40 + (WET)
Received-SPF: neutral (x1.develooper.com: local policy)
Received-SPF: pass (x1.develooper.com: local policy)
X-Old-Spam-Check-BY: la.mx.develooper.com
Message-ID: <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Alberto Manuel Brandao Simoes)
X-RT-Original-Encoding: ascii
content-type: text/plain; charset="utf-8"


---
osname= linux
osvers= 2.4.26
arch=   i486-linux
cc= cc 
---

Flags:
category=core
severity=none
ack=no
---

Running make smoke as it is at the moment is too much boring as we don't have 
any progress indication at all.

We requested Test::TAP::HTMLMatrix authors help (gaal and nothingmuch) and they 
promise us a new release of Test::TAP::Model real-soon-now (I wonder how much 
time this is).

At the moment, just changed added "evil" code. It should be changed as soon as 
the new release (Test::TAP::Model 0.05) is out.

I'll attach the diff in the RT mail.

Cheers
Alberto

---
Summary of my parrot 0.4.0 (r10446) configuration:
  configdate='Sun Dec 11 17:43:04 2005'
  Platform:
osname=linux, archname=i486-linux
jitcapable=1, jitarchname=i386-linux,
jitosname=LINUX, jitcpuarch=i386
execcapable=1
perl=/usr/bin/perl5.8.5
  Compiler:
cc='cc', ccflags=' -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE',
  Linker and Libraries:
ld='cc', ldflags=' -L/usr/local/lib',
cc_ldflags='',
libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp'
  Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC',
load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC'
  Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234, 
nv=double, numvalsize=8, doublesize=8


---
Environment:
HOMELANGLANGUAGELC_ALLLC_COLLATELD_LIBRARY_PATH
LOGDIRPATHPERL5_CPANPLUS_CONFIGSHELL



--
Alberto Simões - Departamento de Informática - Universidade do Minho
 Campus de Gualtar - 4710-057 Braga - Portugal
Index: t/harness
===
--- t/harness   (revision 10449)
+++ t/harness   (working copy)
@@ -158,28 +158,52 @@
 };
 die "You must have Test::TAP::HTMLMatrix installed.\n\n$@" if $@;
 
-my $start = time();
-my $model = Test::TAP::Model::Visual->new_with_tests(@tests);
-my $end = time();
+## FIXME: ###
+# This is a temporary solution until Test::TAP::Model version
+# 0.05.  At that point, this function should be removed, and the
+# verbose line below should be uncommented.
+{
+  no warnings qw/redefine once/;
+  *Test::TAP::Model::run_tests = sub {
+my $self = shift;
 
-my $duration = $end - $start;
+$self->_init;
+$self->{meat}{start_time} = time;
 
-my $v = Test::TAP::HTMLMatrix->new(
+foreach my $file (@_) {
+ print STDERR "- $file\n";
+ $sel

[perl #37891] Make smoke tests give progress indication

[via RT]

# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #37891]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=37891 >


---
osname= linux
osvers= 2.4.26
arch=   i486-linux
cc= cc 
---
Flags:
category=core
severity=none
ack=no
---

Running make smoke as it is at the moment is too much boring as we don't have 
any progress indication at all.

We requested Test::TAP::HTMLMatrix authors help (gaal and nothingmuch) and they 
promise us a new release of Test::TAP::Model real-soon-now (I wonder how much 
time this is).

At the moment, just changed added "evil" code. It should be changed as soon as 
the new release (Test::TAP::Model 0.05) is out.

I'll attach the diff in the RT mail.

Cheers
Alberto

---
Summary of my parrot 0.4.0 (r10446) configuration:
  configdate='Sun Dec 11 17:43:04 2005'
  Platform:
osname=linux, archname=i486-linux
jitcapable=1, jitarchname=i386-linux,
jitosname=LINUX, jitcpuarch=i386
execcapable=1
perl=/usr/bin/perl5.8.5
  Compiler:
cc='cc', ccflags=' -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE',
  Linker and Libraries:
ld='cc', ldflags=' -L/usr/local/lib',
cc_ldflags='',
libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp'
  Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC',
load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC'
  Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234, 
nv=double, numvalsize=8, doublesize=8

---
Environment:
HOMELANGLANGUAGELC_ALLLC_COLLATELD_LIBRARY_PATH
LOGDIRPATHPERL5_CPANPLUS_CONFIGSHELL

Re: [perl #37891] Make smoke tests give progress indication

[Will Coleda]

Applied as r10455.

On Dec 11, 2005, at 4:46 PM, [EMAIL PROTECTED] (via RT) wrote:

Running make smoke as it is at the moment is too much boring as we  
don't have any progress indication at all.


We requested Test::TAP::HTMLMatrix authors help (gaal and  
nothingmuch) and they promise us a new release of Test::TAP::Model  
real-soon-now (I wonder how much time this is).


At the moment, just changed added "evil" code. It should be changed  
as soon as the new release (Test::TAP::Model 0.05) is out.


I'll attach the diff in the RT mail.

Cheers
Alberto

Re: Parrot Shootout

[Dr.Ruud]

Leopold Toetsch:
> Dr.Ruud:
>> Roger Browne:

>>> Unfortunately I could only get to Ack(3, 6) before parrot aborted
>>> with "maximum recursion depth exceeded", at recursion depth 1000.
>>
>> Alternative: use Memoize;
>
> Sure. And there is a (inline) memoized perl Ack already, which is one
> of the fastest of all tests submitted.
>
> The goal of these benchmarks is to run 'as is' with the same
> algorithm.

Define "the same algorithm".
(Some language could memoize when it is not explicitly told so.)

If there would be a "volatile" attribute for sub, to define that the sub
is non-memoizable (or that its runs are not cacheable), than the
'algorithm' would not need the "use Memoize" and "memoize('ack')" lines.

-- 
Affijn, Ruud

"Gewoon is een tijger."