Re: Inconsistent Parrot / IMCC behavior

2004-02-29 Thread Leopold Toetsch
Melvin Smith [EMAIL PROTECTED] wrote:
 At 08:01 PM 2/28/2004 -0800, Gregor N. Purdy wrote:
I made the change, and now I get consistent results. I'll check that in.

I am still not clear, though, on why we wouldn't have the same failure
in all cases. I'd think these should be equivalent:

   * Running parrot on 'foo.imc'
   * Running parrot on 'foo.pasm' generated from 'foo.imc'
   * Running parrot on 'foo.pbc' generated from 'foo.pasm'

 You would think it would be straightforward. Its not, due to the
 way we (Leo and I) mixed up IMCC and how it handles things,
 especially the lexer. The problem is definitely a bug, and I think
 we've made an error in trying to mix too many features and
 lexing/parsing modes into the same compiler.

Well, sometimes ago compiling PIR to PASM didn't even produce valid
source code, mainly due to internal label naming. Anyway compiling to
PASM isn't really ment to be equivalent to running code direclty (or
producing a PBC). It's mainly for debugging purposes only.

These steps are fine:
- foo.imc - run
- foo.imc - foo.pbc - run
- foo.pasm - run
- foo.pasm - foo.pbc - run

But not (in all cases):
- foo.imc - foo.pasm - anything

You can call this a bug of course, but it was never[1] intended to work
that way in all cases. There is really *no need* to compile to PASM and
run that code. This is an outdated POV from times where assenble.pl was
the one and only assembler.

 ... Its become too
 aggravating to maintain, at least for me. Leo is welcome to
 maintain v1 all he wants ;)

Me thinks that we should rework the whole structure of Parrot WRT
compilers. Something like this:
- a compiler/assembler is a loadable lib, which during load registers
  the filetype it can compile
- a macro preprocessor is a loadable IO filter layer

Now:
- Parrot starts in src/parrot.c (finally :)
- It does commandline handling and remembers all options
- Parrot now loads default compilers which register their file type(s)
- Parrot handles source file and commandline arguments over to a
  matching compiler

 The rewrite of IMCC and will handle _one single flavor_ of language.

Yep. I'm all for separating PASM and PIR lexing and parsing.

The underlaying code generation could be based on an AST node scheme,
similar to that used in YAL - Melvin, if you didn't look at YAL, please
do).

 -Melvin

leo

[1] except in the very beginning of course, when we had
PIR-PASM-assemble.pl.


Please no checkins

2004-02-29 Thread Leopold Toetsch
I'm currently preparing 0.1.0, so please no changes to CVS until further 
ntice.

Thanks,
leo


Re: www.parrotcode.org

2004-02-29 Thread Michael Scott
On 29 Feb 2004, at 03:07, Robert Spier wrote:

[...]

Someone else can take care of this for him.  (And I know he'd love it
if someone stepped forward to become official web content maintainer.)
We'll provide that person with resources and support, and it'll be
quite fun and easy for everyone.
Well, I'd like to be able to integrate the autogenerated html docs that 
I've been working on with the website content, so it makes sense for me 
to volunteer. What next?

Mike



i386 JIT problem with set_i_n

2004-02-29 Thread Jens Rieks
Hi,

the following test gives wrong results on i386/JIT.
It looks like the set_i_n JIT op rounds the number, whereas
the non JIT OP does not round the number.

jens

output_is('CODE', 'OUT', set_i_n testing);
##PIR##
.sub _main
.local num n
.local int i

n = 1.4
i = n
print i

n = 2.5
i = n
print i

n = 3.6
i = n
print i

print \n
end
.end
CODE
123
OUT



Re: Please no checkins

2004-02-29 Thread Jens Rieks
Hi leo,

Am Sonntag, 29. Februar 2004 11:47 schrieb Leopold Toetsch:
 I'm currently preparing 0.1.0, so please no changes to CVS until further
 ntice.
Here is the tetris example, include it if you want...

 Thanks,
 leo
jens



Re: Please no checkins

2004-02-29 Thread Jens Rieks



tetris.tgz
Description: application/tgz


Re: Please no checkins

2004-02-29 Thread Leopold Toetsch
Jens Rieks [EMAIL PROTECTED] wrote:
 Hi leo,

 Am Sonntag, 29. Februar 2004 11:47 schrieb Leopold Toetsch:
 I'm currently preparing 0.1.0, so please no changes to CVS until further
 ntice.
 Here is the tetris example, include it if you want...

Sorry, too late. Next time.

 jens

leo


Release done

2004-02-29 Thread Leopold Toetsch
Currently working on 10a of RELEASE_INSTRUCTIONS everything should be 
done, so let the checkins begin.

Have fun,
leo


Re: Release done

2004-02-29 Thread Nicholas Clark
On Sun, Feb 29, 2004 at 05:36:22PM +0100, Leopold Toetsch wrote:
 Currently working on 10a of RELEASE_INSTRUCTIONS everything should be 
 done, so let the checkins begin.

Woohoo!

Well done.
I see it's all over use.perl now too.

Nicholas Clark


Removing a lexical

2004-02-29 Thread Will Coleda
Is there a way to unstore a lexical in a scope?

--
Will Coke Coledawill at coleda 
dot com



Re: PLATFORM

2004-02-29 Thread Kenneth A Graves
On Sat, 2004-02-28 at 06:43, Leopold Toetsch wrote:
 Kenneth A Graves [EMAIL PROTECTED] wrote:
  On Fri, 2004-02-27 at 16:08, Kenneth A Graves wrote:
 
  How do I verify which runloops/features are working?
 
 CGoto core: make testg testC

Both give:
All tests successful, 1 test and 61 subtests skipped.

 JIT:make testj

Not so good.  I get:
Failed TestStat Wstat Total Fail  Failed  List of Failed
---
t/op/trans.t  2   512182  11.11%  11 18
t/pmc/perlstring.t1   256291   3.45%  3
t/pmc/pmc.t   1   256921   1.09%  23
1 test and 61 subtests skipped.

I'll investigate further to see if I can track these down.

  I added  or $^O eq 'freebsd' to t/pmc/{threads,timer}.t and those
  tests run successfully.  The same trick doesn't work for signal.t.
 
  So I think that gives:
 
  freebsd5.2-i386  YYY Y   -  Y   Y
 
 Thanks updated.
 
  --kag
 
 leo




Re: PLATFORM

2004-02-29 Thread chromatic
On Sat, 2004-02-28 at 03:43, Leopold Toetsch wrote:

 CGoto core: make testg testC

Both of these worked on Linux PPC with gcc-3.2.3

I did see an intermittent hang, this time on the second test of
t/src/intlist.t.  killall -HUP intlist_2 made the test continue, though
it failed.


 JIT:make testj

imcc/t/reg/spill.t1   256 31  33.33%  2
imcc/t/syn/pcc.t  1   256311   3.23%  17
t/op/integer.t2   512392   5.13%  1 33
t/op/stacks.t 5  1280565   8.93%  1-5

I'm attaching the output.

-- c


# Failed test (t/op/integer.t at line 21)
#  got: ''
# expected: '0
# 1
# 2
# 3
# 4
# 5
# 6
# 7
# 8
# 9
# 10
# 11
# 12
# 13
# 14
# 15
# 16
# 17
# 18
# 19
# 20
# 21
# 22
# 23
# 24
# 25
# 26
# 27
# 28
# 29
# 30
# 31
# '
# Failed test (t/op/integer.t at line 1040)
#  got: ''
# expected: '
# '
# Looks like you failed 2 tests of 39.
# Failed test (t/op/stacks.t at line 79)
#  got: ''
# expected: '0-1-2-3-4
# -5-6-7-8-9
# -10-11-12-13-14
# -15-16-17-18-19
# -20-21-22-23-24
# -25-26-27-28-29
# -30-31
# 01234
# 56789
# 1011121314
# 1516171819
# 2021222324
# 2526272829
# 3031
# '
# Failed test (t/op/stacks.t at line 104)
#  got: ''
# expected: '0-1-2-3-4
# -5-6-7-8-9
# -10-11-12-13-14
# -1516171819
# 2021222324
# 2526272829
# 3031
# '
# Failed test (t/op/stacks.t at line 121)
#  got: ''
# expected: '01234
# 56789
# 1011121314
# 15-16-17-18-19
# -20-21-22-23-24
# -25-26-27-28-29
# -30-31
# '
# Failed test (t/op/stacks.t at line 138)
#  got: ''
# expected: '0-1-2-3-4
# -5-6-7-8-9
# -10-11-12-13-14
# -1516171819
# 2021222324
# 2526272829
# 3031
# 
# 01234
# 56789
# 1011121314
# 1516171819
# 2021222324
# 2526272829
# 3031
# 
# 1617181920
# 2122232425
# 2627282930
# 31-16-17-18-19
# -20-21-22-23-24
# -25-26-27-28-29
# -30-31
# 
# 1617181920
# 2122232425
# 2627282930
# 310123
# 45678
# 910111213
# 1415
# '
# Failed test (t/op/stacks.t at line 194)
#  got: ''
# expected: '0
# 0
# 0
# 0
# 0
# 0
# 00
# 
# 1617181920
# 2122232425
# 2627282930
# 310-1-2-3
# -4-5-6-7-8
# -9-10-11-12-13
# -14-15
# 
# 0
# 0
# 0
# 0
# 0
# 0
# 00
# 
# 01234
# 56789
# 1011121314
# 15-16-17-18-19
# -20-21-22-23-24
# -25-26-27-28-29
# -30-31
# '
# Looks like you failed 5 tests of 56.
ppc JIT CPU
.so SO extension
# Failed test (imcc/t/reg/spill.t at line 80)
#  got: ''
# expected: '0123456789
# 10111213141516171819
# 20212223242526272829
# 30313233343536373839
# 1591317
# 2125293337
# 4145495357
# 6165697377
# '
# Looks like you failed 1 tests of 3.
# Failed test (imcc/t/syn/pcc.t at line 762)
#  got: ''
# expected: 'all params ok
# '
# Looks like you failed 1 tests of 31.
Failed 4/86 test scripts, 95.35% okay. 9/1324 subtests failed, 99.32% okay.
make: *** [testj] Error 255


Re: [PATCH] Configure test for inet_aton

2004-02-29 Thread Gordon Henriksen
On Friday, February 27, 2004, at 12:26 , Andrew Dougherty wrote:

On Fri, 27 Feb 2004, Gordon Henriksen wrote:

inet_pton is preferrable, as it supports IPv6.

That is, inet_pton should trump inet_aton if both are available.
Probably, but that would require testing to see if inet_pton is 
available. That information is not available from perl5's Configure, 
and there currently is no infrastructure in parrot for making such a 
test. Obviously that needs to change eventually.

On Mac OS X, the preferred technique would be to weak link with 
inet_pton and test for its availability at run-time. (inet_pton is not 
available on 10.1, but is available on 10.3.) This would be another 
case entirely.
Yes, indeed, that's the sort of thing that makes testing for function 
availability so much fun :-).
FWIW, this can't work across the 10.1/10.2 schizm.

	http://developer.apple.com/technotes/tn2002/tn2064.html

So parrot would need to:

  - either use a separate 10.1 binary (yuck),
  - or forgo use of inet_pton and IPv6 on Mac OS X 10.2 even though it 
is available (yuck),
  - or link in at runtime a different driver DLL for 10.1 vs. 10.2 
(yuck).

Roll-your-own doesn't really sound so bad. But until the implementation 
is not hardcoded to IPv6, preferring inet_aton (as present) gets the 
right behavior. But IPv6 can't be ignored forever.

Whatevsies.



Gordon Henriksen
[EMAIL PROTECTED]


Re: Current PLATFORMS

2004-02-29 Thread Paul Cochrane
* Leopold Toetsch ([EMAIL PROTECTED]) [040228 23:59]:
 Paul Cochrane [EMAIL PROTECTED] wrote:
  Hi,
 
  I got parrot to build on Alpha OSF1, but I can't get make test to go.  Here's
  what I see:
 
  rolf:[524]/var/tmp/parrot/usr/bin/make test
  perl t/harness --gc-debug --running-make-test  -b t/op/*.t t/pmc/*.t
  t/native_pbc/*.t imcc/t/*/*.t t/src/*.t
  t/op/00ff-dos...15944:./parrot: /sbin/loader: Error: Unresolved symbol in
  ./parrot: inet_pton
 
 Can you please cvs update and run:
 
 $ perl Configure.pl --define=inet_aton
 $ make  make test


Done, and it works ok.  Sorry this is late, I didn't check my mail over the
weekend.

I haven't been around parrot for long, so as far as I can tell from the output 
it looks jittable, but not able to be executed, and it's not using native 
signals.

I really hope this helps.

Here's the myconfig:

Summary of my parrot 0.0.13 configuration:
  configdate='Mon Mar  1 12:58:24 2004'
  Platform:
osname=dec_osf, archname=alpha-dec_osf
jitcapable=1, jitarchname=alpha-dec_osf,
jitosname=DEC_OSF, jitcpuarch=alpha
execcapable=0
perl=perl
  Compiler:
cc='cc', ccflags='-std -fprm d -ieee -D_INTRINSICS -I/usr/local/include
-DLANGUAGE_C -pthread',
  Linker and Libraries:
ld='ld', ldflags='-s -L/usr/local/lib',
cc_ldflags='',
libs='-lm -lpthread'
  Dynamic Linking:
so='.so', ld_shared='-shared -expect_unresolved * -O4 -msym -s
-L/usr/local/lib',
ld_shared_flags=''
  Types:
iv=long, intvalsize=8, intsize=4, opcode_t=long, opcode_t_size=8,
ptrsize=8, ptr_alignment=4 byteorder=12345678, 
nv=double, numvalsize=8, doublesize=8


And the output from make test:

perl t/harness --gc-debug --running-make-test  -b t/op/*.t t/pmc/*.t
t/native_pbc/*.t imcc/t/*/*.t t/src/*.t
t/op/00ff-dos...ok
t/op/00ff-unix..ok
t/op/arithmeticsok
t/op/basic..ok
t/op/bitwiseok
t/op/callingok
t/op/comp...ok
t/op/conv...ok
t/op/debuginfo..ok, 3/3 subtests skipped
t/op/gc.ok
t/op/globalsok
t/op/hacks..ok, 2/2 subtests skipped
t/op/ifunless...ok
t/op/info...ok
t/op/integerok
t/op/interp.ok
t/op/jitok
t/op/jitn...ok
t/op/lexicals...ok
t/op/macro..ok, 1/16 subtest skipped
t/op/number.ok
t/op/rx.ok, 1/23 subtest skipped
t/op/stacks.ok
t/op/string.ok
t/op/time...ok
t/op/trans..ok
t/op/types..ok
t/pmc/array.ok
t/pmc/boolean...ok
t/pmc/coroutine.ok
t/pmc/delegate..ok
t/pmc/dumperok
t/pmc/env...ok
t/pmc/eval..ok
t/pmc/exception.ok
t/pmc/float.ok
t/pmc/freezeok
t/pmc/intlist...ok
t/pmc/iook, 1/21 subtest skipped
t/pmc/iter..ok, 1/9 subtest skipped
t/pmc/key...ok
t/pmc/managedstruct.ok, 1/5 subtest skipped
t/pmc/mmd...ok
t/pmc/multiarrayok
t/pmc/nci...ok, 29/29 subtests skipped
t/pmc/object-meths..ok
t/pmc/objects...ok
t/pmc/orderedhash...ok
t/pmc/perlarray.ok
t/pmc/perlhash..ok
t/pmc/perlint...ok
t/pmc/perlnum...ok
t/pmc/perlstringok
t/pmc/pmc...ok
t/pmc/prop..ok
t/pmc/ref...ok
t/pmc/sarrayok
t/pmc/scratchpadok
t/pmc/signalskipping test on this platform
t/pmc/sort..ok
t/pmc/sub...ok
t/pmc/threads...ok, 2/11 subtests skipped
t/pmc/timer.ok
t/pmc/tqueueok
t/native_pbc/integer.ok
t/native_pbc/number.ok
imcc/t/imcpasm/cfg..ok
imcc/t/imcpasm/opt0.ok
imcc/t/imcpasm/opt1.ok, 1/49 subtest skipped
imcc/t/imcpasm/opt2.ok, 5/5 subtests skipped
imcc/t/imcpasm/optc.ok, 6/6 subtests skipped
imcc/t/imcpasm/pcc..ok, 10/10 subtests skipped
imcc/t/imcpasm/sub..ok
imcc/t/reg/spillok
imcc/t/syn/bsr..ok
imcc/t/syn/clashok
imcc/t/syn/constok
imcc/t/syn/eval.ok
imcc/t/syn/file.ok, 1/12 subtest skipped
imcc/t/syn/keyedok
imcc/t/syn/labels...ok
imcc/t/syn/macrook
imcc/t/syn/namespace.ok
imcc/t/syn/pcc..ok, 2/31 subtests skipped
imcc/t/syn/pod..ok
imcc/t/syn/scopeok
t/src/basic.ok
t/src/exit..ok
t/src/extendok
t/src/hash..ok
t/src/intlist...ok
t/src/iook, 1/20 subtest skipped
t/src/list..ok
t/src/manifest..ok
t/src/sprintf...ok
All tests successful, 1 test skipped, plus 67 subtests skipped.
Files=95,  Tests=1380, 111 wallclock secs (52.80 cusr + 28.33 csys = 81.13
CPU)


When building, the compiler still spits out this warning:
cc: Info: ../include/parrot/config.h, line 62: In this declaration, type long
double has the same representation as type double on this platform.
(longdoublenyi)
typedef long double HUGEFLOATVAL;
^

But I gather you may have guessed that.

 Thanks,
No worries!  :-)

Later

Paul


[perl #27243] [PATCH] Corrects (?) misleading POD usage re: -C option.

2004-02-29 Thread via RT
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #27243]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27243 


Changes 2 lines (marked ** below) in t\harness to correct errors in the POD and 
usage messages.


T:\tperldoc -t ./harness
NAME
t/harness - Parrot Test Harness

SYNOPSIS
% perl t/harness [options] [testfiles]

DESCRIPTION
Command-line options are:

-w
Turn warnings on.

-g
Run the CGoto core.

-j
Run with JIT enabled.

-P
Run the Prederef core.

**-P (sic)
Run the CGP core.

-S
Run Switched.

-b
Run bounds checking enabled.

-d
Run with debugging enabled.

-r
assemble to Parrot bytecode and then run the bytecode.

-O[012]
Run optimized to the specified level.

HISTORY
Mike Lambert stole t/harness for languages/perl6/t/harness.

Leo Toetsch stole languages/perl6/t/harness for imcc/t/harness.

Bernhard Schmalhofer merged imcc/t/harness back into t/harness.


T:\tperl harness -?
perl t/harness [options] [testfiles]
-w ... warnings on
-g ... run CGoto
-j ... run JIT
-P ... run Prederef
**-P ... run CGP
-S ... run Switched
-b ... run bounds checked
-v ... run verbose
-d ... run debug
-r ... assemble to PBC run PBC
-O[012] optimize



bin0.bin
Description: Binary data


[perl #27246] [PATCH] Correct ommision in config/gen/makefiles/befunge.in

2004-02-29 Thread via RT
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #27246]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27246 


There was no 
PERL = ${perl}
definition in this file (which does exist in jako.in and others), hence when the 
clean target was called, the RM_F expansion omitted the perl resulting in 

nmake befunge clean

and all the dependancies 

nmake languages-clean
nmake clean
nmake realclean

failing with invalid command or filename.

Lokking around, I think that BF.in is similarly wrong, but I am not currently 
building that, and could be mistaken .




bin0.bin
Description: Binary data


Parrot 0.1.0 Released

2004-02-29 Thread Leopold Toetsch
Parrot 0.1.0 Leaping Kakapo Released!

The Parrot team proudly presents the Parrot 0.1.0 leap release. It
provides some milestones like objects and multi-threading1[1] and
supports many more platforms.
After some pause you can grab it from
http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.1.0.tar.gz or
just get the latest and best from CVS by following the directions at
http://dev.perl.org/cvs/.
Turn your web browser towards http://www.parrotcode.org/ for more
information about Parrot, get involved, and:
Have fun!
leo
[1] The list of changes includes:

 - Ladies and gentlemen, I give you... objects!
 - Huge documentation overhaul
 - More supported platforms, s. PLATFORMS
 - Basic thread support for pthread based architectures
 - Basic event handling for timers and signals including:
 - PASM callbacks for NCI (native C) functions.
 - Improved platform configuration
 - COW stacks now working, stacks code redone
 - Structure handling vastly improved
 - Random PMC and rand primitives
 - Better subroutine call syntax in PIR
 - Make PIR subroutines compliant with pdd03
 - Improved profiling (DOD, GC timings)
 - Hash code improvements, incl. random key order support
 - Experimental freeze/thaw code for some PMC types
 - IO improvements for buffered layer and Win32
 - String iterators
 - String bitwise vtables
 - Many new opcodes
 - Suppport for JIT, where malloced memory isn't executable
 - Priority DOD scheme for objects that need timely destruction
 - Improved byte code loading (e.g. onLoad functions)
 - Language updates: forth, Perl6/P6C, m4
 - Libraries: Getopt_Long, SDL, Dumper, Sort
 - new JAPH examples
 - Unified imcc and parrot test handling
 - Many new tests (make test reports 1386 tests)
 - Numerous bug fixes