Re: String API

(As previously remarked, I'm trying to catch up from a few days offline, so excuse me if this is OOD.) On Tue, 11 Sep 2001, Ken Fox wrote: > The interpreter knows the internals of the stack structure and is > responsible for managing it. To change the stack implementation, we'll > have to caref

string vtable editing script

I've been offline for a few days and haven't caught up on email yet (nor, most likely, will I ever), so I hope no one else has already done this, but Attached is a file, msv.tar.gz which contains a simple script and .pm file (*) for editing the string vtable. It asks you for a bunch of typed

RE: Constant comparisons

On Sat, 15 Sep 2001, Nathan Torkington wrote: > Gibbs Tanton - tgibbs writes: > > It seems to me that this might eventually get out of hand...could there > > possibly be some way to automate the generation of a family of opcodes? For > > example: > > Hear hear, the same thing occurred to me. T

Re: [patch] New comparison ops + better op inference

On 15 Sep 2001, Gregor N. Purdy wrote: > All -- > > In working to make Jako be able to handle while (i < 0) as well as > while (i < n), I added a bunch of integer and numerical comparison > ops. I also tinkered with the assembler's op inferencing to get it > to pick the ops I intended. Please b

RE: Constant comparisons

Gibbs Tanton - tgibbs writes: > It seems to me that this might eventually get out of hand...could there > possibly be some way to automate the generation of a family of opcodes? For > example: Hear hear, the same thing occurred to me. The way that there are separate functions for each argument

Re: coding standards

Gibbs Tanton - tgibbs writes: > I will try to watch things as they go in and make coding standard > changes immediately from now on so we don't have such a massive > change. Alternatively, pumpkings could refuse to apply patches that don't conform. One or two goes around and people will learn to

mod_parrot

Robert Spier and I just had some fun. Parrot for Apache. :-) http://cvs.perl.org/cvsweb/mod_parrot/ It's really simplistic and doesn't actually work. As Robert just told me, it'll be really ugly to get to actually send stuff back to the browser until Parrot has some kind of real IO subsystem.

RE: Constant comparisons

It seems to me that this might eventually get out of hand...could there possibly be some way to automate the generation of a family of opcodes? For example: MANUAL_OP_FAMILY eq_T1_T2 { if( T1 == T2 ) { RETURN(P3); } else { RETURN(P4); } } OVER(i, ic, n, nc) Note that I'm not pro

coding standards

Ok, I just updated every .c and .h file to include the new coding standard. I also updated most of the .pl files to use Parrot_Interp instead of Perl_Interp. Please refresh your copy of the files. I will try to watch things as they go in and make coding standard changes immediately from now on s

[PATCH] Duplicate in Parrot/Opcode.pm

Hoi, Is this a pattern? Buggs Index: Parrot/Opcode.pm === RCS file: /home/perlcvs/parrot/Parrot/Opcode.pm,v retrieving revision 1.3 diff -u -3 -p -r1.3 Opcode.pm --- Parrot/Opcode.pm 2001/09/15 00:57:42 1.3 +++ Parrot/Opcode.pm 20

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

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 +++

Re: Minor "cleanup" patch to interpreter.*

On Sat, 15 Sep 2001, Michael Fischer wrote: > This set of patches just eliminates some casts, and some > "foo" in favor of (IMHO) clearer variable names. > > I also removed the DO_OP macro as it seems unnecessary > for the current case, but perhaps I undervalue it? Yup. The point of that macro

Minor "cleanup" patch to interpreter.*

This set of patches just eliminates some casts, and some "foo" in favor of (IMHO) clearer variable names. I also removed the DO_OP macro as it seems unnecessary for the current case, but perhaps I undervalue it? == --- build_interp_starte

RE: [PATCH] testsuite and Win32 compilation

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't really # # know--it just l

RE: [PATCH] testsuite and Win32 compilation

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't really # know--it just looks # > #a little suspicious

How to get Digest::MD5

Since build_interp_starter.pl and assemble.pl need Digest::MD5, I tried to get it via CPAN, but it requires a compilation, which requires perl.h. I'd think that there must be somewhere I can get the MD5 binary, since the MD5 module would be of use to others besides perl developers. My Perl is

"Automated" Purify Run

This time i've filtered out all the memory leak related data so all that shows up are legitimate errors. (hopefully) I have set up a cheesy script to update the following URL with the current output of purify on the current CVS test_prog (test,test2,test3,euclid) every hour. http://www.hitchh

Constant comparisons

I wanted to be able to say eq I1, 15, label1, label2 That is, to compare against a constant. I've implemented versions of the comparison opcodes that let you compare against constants. This is my first patch to Parrot. Be merciful :-) Nat (also working on test system ... stay tuned) In

[commit] Renamed jako_compiler.pl to jakoc

All -- I have renamed the Jako compiler from jako_compiler.pl to jakoc. Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECT

Re: parrot compilation failure in Tru64

On Sat, Sep 15, 2001 at 08:16:36PM +0100, Simon Cozens wrote: > On Sat, Sep 15, 2001 at 08:43:19PM +0300, Jarkko Hietaniemi wrote: > > Never mind 'portable' for now, currently it's not even *working* on > > 64-bit platforms > > That as may be, I'd like to make sure we start fixing it in the >

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

All -- > If the assembler patch I submitted a little while ago goes in, I'll > commit these changes to the Jako compiler. They fix a bug in assignment > handling and add some more conditionals to while and if. Also it goes > back to using implicit opcodes in a few cases that were broken before >

Re: [patch] New comparison ops + better op inference

All -- > In working to make Jako be able to handle while (i < 0) as well as > while (i < n), I added a bunch of integer and numerical comparison > ops. I also tinkered with the assembler's op inferencing to get it > to pick the ops I intended. > > The attached patch also contains my label parsin

Re: Parrot's mascot

Rocco -- > > > I'd like to suggest that the Parrot image we've seen associated with > > > Perl6 be > > > > this: http://pettalk.zapp.com.au/images/Africangrey.jpg > > I can't seem to find a picture of a Norwegian Blue anywhere. Maybe that's because its an EX-parrot! http://www.intriguing.co

Re: Parrot's mascot

Simon -- > > I'd like to suggest that the Parrot image we've seen associated with > > Perl6 be > > this: http://pettalk.zapp.com.au/images/Africangrey.jpg I also found this site: http://www.resonans.net/jako/ Regards, -- Gregor __

Re: parrot compilation failure in Tru64

On Sat, Sep 15, 2001 at 02:28:25PM -0500, Gibbs Tanton - tgibbs wrote: > > Never mind 'portable' for now, currently it's not even *working* on > > 64-bit platforms > > You might try putting an ! after the l in the assembler pack type and see if > that fixes things. 'q' did the trick a few ve

[patch] New comparison ops + better op inference

All -- In working to make Jako be able to handle while (i < 0) as well as while (i < n), I added a bunch of integer and numerical comparison ops. I also tinkered with the assembler's op inferencing to get it to pick the ops I intended. The attached patch also contains my label parsing fix to the

Re: coding standard

On Sat, Sep 15, 2001 at 03:11:33PM -0500, Gibbs Tanton - tgibbs wrote: > Ok everyone, I have changed all of the .c and .h files to match the coding > standard. I also changed all instances of Perl_Interp to Parrot_Interp. I > want to give everyone a chance to yell NOOO > before I com

Re: Minor "cleanup" patch to interpreter.*

On Sat, Sep 15, 2001 at 03:56:55PM -0400, Michael Fischer wrote: > I also removed the DO_OP macro as it seems unnecessary > for the current case, but perhaps I undervalue it? You do. I'm suspecting that this will eventually be used to construct machine-specific op dispatchers to help us optimize

[PATCH] testsuite

> I have a question on your test suite. > Would backticks not be more portable then trying to figure out how to > redirect STDOUT on each OS? To me, it would just be simpler to use the No, I don't need to "figure out", I just execute a perl -e ".redirections...;system '$command'"; where re

RE: parrot compilation failure in Tru64

> Never mind 'portable' for now, currently it's not even *working* on > 64-bit platforms You might try putting an ! after the l in the assembler pack type and see if that fixes things. Right now, it is going to be putting opcodes out in 32 bits. Since Tru64 is 64 bits, a long is going to be

Re: parrot compilation failure in Tru64

On Sat, Sep 15, 2001 at 08:43:19PM +0300, Jarkko Hietaniemi wrote: > Never mind 'portable' for now, currently it's not even *working* on > 64-bit platforms That as may be, I'd like to make sure we start fixing it in the right direction rather than the wrong one. :) Simon

RE: coding standards

I don't know, I always liked seeing them separate. I'll change it to $Id:$ to take up less space. -Original Message- From: Russ Allbery To: [EMAIL PROTECTED] Sent: 9/15/2001 2:08 PM Subject: Re: coding standards Gibbs Tanton <- tgibbs <[EMAIL PROTECTED]>> writes: > * CVS Info > *

Re: parrot compilation failure in Tru64

On Sat, 15 Sep 2001, Philip Kendall wrote: > My personal view would be that the gains due to portable bytecode would > be outweighed by the amount of cruft we'd have to put into the > interpreter to get them. As Nicholas Clark and someone else who's name > I've forgotten[1] mentioned, there are p

[patch] A few fixes to the Jako compiler

All -- If the assembler patch I submitted a little while ago goes in, I'll commit these changes to the Jako compiler. They fix a bug in assignment handling and add some more conditionals to while and if. Also it goes back to using implicit opcodes in a few cases that were broken before the assemb

Re: coding standards

Gibbs Tanton <- tgibbs <[EMAIL PROTECTED]>> writes: > * CVS Info > * $RCSfile: $ > * $Revision: $ > * $Date: $ If you're going to include all that, why not just use $Id$, which contains all of that information? -- Russ Allbery ([EMAIL PROTECTED])

Re: Microbenchmark JVM<->PVM

Leon -- > Sky asked me if anyone had done any simple benchmarks comparing JVM > and PVM at this point. Now, I know we're still at an early stage and > haven't really looked at speed, but a trivial counting and simple > arithmetic benchmark: Here's an implementation of the code in Jako. I haven't

[patch] Small mod to assemble.pl to allow uppercase and underscoresin labels

All -- The labels autogenerated by the Jako compiler use uppercase characters and underscores. This patch makes the opcode inference logic in the assembler happy with that situation. It also prints out the qualified opcode it inferred when it fails to find a matching opcode. Regards, -- Gregor

Re: parrot compilation failure in Tru64

On Sat, Sep 15, 2001 at 06:33:18PM +0100, Simon Cozens wrote: > > We also need to think about endianness. Urgh. > > This is something I ought to seek consensus on. (And possibly a ruling from > Dan.) > > Do we *expect* Parrot bytecode to be portable? My gut reaction would be to > say no, but I

RE: Difficulties

Oh yeah...good point...:) This patch has been applied. Thanks! -Original Message- From: Will Coleda To: Gibbs Tanton - tgibbs Cc: '[EMAIL PROTECTED] ' Sent: 9/15/2001 12:33 PM Subject: Re: Difficulties Um... with the current setup, there IS no Makefile until you run Configure.pl, so I

Re: parrot compilation failure in Tru64

On Sat, Sep 15, 2001 at 06:33:18PM +0100, Simon Cozens wrote: > On Sat, Sep 15, 2001 at 06:32:57PM +0100, Philip Kendall wrote: > > I posted a couple of bodge fixes from this, but I haven't done much in > > the past couple of days... do we want to use a 32 bit type for reading > > in bytecode or c

Re: parrot compilation failure in Tru64

On Sat, Sep 15, 2001 at 06:32:57PM +0100, Philip Kendall wrote: > I posted a couple of bodge fixes from this, but I haven't done much in > the past couple of days... do we want to use a 32 bit type for reading > in bytecode or convert the 32 bit on-disc format into a 64 bit format in > memory befo

Re: Difficulties

Um... with the current setup, there IS no Makefile until you run Configure.pl, so I really don't see how that's possible. =-) Gibbs Tanton - tgibbs wrote: > > The README really doesn't have to mention Configure.pl because when you do > make test_prog it will run Configure.pl for you (at least it

Re: parrot compilation failure in Tru64

On Sat, Sep 15, 2001 at 04:44:47PM +0100, Simon Cozens wrote: > > And segfaults here: > > (gdb) run test.pbc > Starting program: /var/tmp/parrot/test_prog test.pbc > > Program received signal SIGSEGV, Segmentation fault. > 0x120007388 in read_constants_table (program_code=0x11b48) at byteco

Re: Parrot's mascot

On Sat, Sep 15, 2001 at 02:27:22PM +0100, Simon Cozens wrote: > On Fri, Sep 14, 2001 at 07:49:50PM -0400, Gregor N. Purdy wrote: > > I'd like to suggest that the Parrot image we've seen associated with > > Perl6 be > > this: http://pettalk.zapp.com.au/images/Africangrey.jpg I can't seem to find

Re: Microbenchmark JVM<->PVM

Don't have Blackdown installed but here are some timing and profiling results (linux/x86, compiled with -pg, 'gprof test_prog' output, remembering the caveat of profiling always skewing the measurements): ugli:/tmp/jhi/parrot ; time ./test_prog j.pbc r 119,14s u 119,14s s 0,00s 100% "./test_prog

Re: parrot compilation failure in Tru64

On Sat, Sep 15, 2001 at 04:44:47PM +0100, Simon Cozens wrote: > On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote: > > The question is why was it wrong after a fresh checkout? (also in Linux) > > No idea. Is make_op_header.pl run? Does op.h contain the #define's? > > > Another ob

Re: parrot compilation failure in Tru64

On Sat, Sep 15, 2001 at 04:44:47PM +0100, Simon Cozens wrote: > On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote: > > The question is why was it wrong after a fresh checkout? (also in Linux) > > No idea. Is make_op_header.pl run? Does op.h contain the #define's? This is eerie--

Re: parrot compilation failure in Tru64

On Sat, Sep 15, 2001 at 04:44:47PM +0100, Simon Cozens wrote: > On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote: > > The question is why was it wrong after a fresh checkout? (also in Linux) > > No idea. Is make_op_header.pl run? Does op.h contain the #define's? I'll try a new c

Re: parrot compilation failure in Tru64

On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote: > The question is why was it wrong after a fresh checkout? (also in Linux) No idea. Is make_op_header.pl run? Does op.h contain the #define's? > Another observation is that after 'rm op.h; make op.h' the thing > builds but with s

Re: parrot compilation failure in Tru64

On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote: > On Sat, Sep 15, 2001 at 04:35:49PM +0100, Simon Cozens wrote: > > On Sat, Sep 15, 2001 at 06:18:38PM +0300, Jarkko Hietaniemi wrote: > > > do { foo [ 0 ] = end ; foo [ 1 ] = set_i_ic ; foo [ 2 ] = set_i ; foo [ 3 ] >= add_i

RE: Difficulties

I haven't had any problem with my instead of use vars...can you send me the test program that blows up? -Original Message- From: Uri Guttman To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: 9/15/2001 8:57 AM Subject: Re: Difficulties > "BD" == Brent Dax <[EMAIL P

Re: parrot compilation failure in Tru64

On Sat, Sep 15, 2001 at 04:35:49PM +0100, Simon Cozens wrote: > On Sat, Sep 15, 2001 at 06:18:38PM +0300, Jarkko Hietaniemi wrote: > > do { foo [ 0 ] = end ; foo [ 1 ] = set_i_ic ; foo [ 2 ] = set_i ; foo [ 3 ] = >add_i ; foo [ 4 ] = sub_i ; foo [ 5 ] = mul_i ; foo [ 6 ] = div_i ; foo [ 7 ]

Re: parrot compilation failure in Tru64

Well, I must have checked out at a bad moment since Linux+gcc 2.95.2 is not faring much better: make test_prog|&head cc -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I..-c -o interpreter.o interpreter.c interpreter.c: In function `make_interpreter': in

Re: parrot compilation failure in Tru64

On Sat, Sep 15, 2001 at 06:18:38PM +0300, Jarkko Hietaniemi wrote: > do { foo [ 0 ] = end ; foo [ 1 ] = set_i_ic ; foo [ 2 ] = set_i ; foo [ 3 ] = >add_i ; foo [ 4 ] = sub_i ; foo [ 5 ] = mul_i ; foo [ 6 ] = div_i ; foo [ 7 ] = ... Your op.h needs rebuilding. It builds fine on Tru64 here.

Re: RFC: Bytecode file format

On Sat, Sep 15, 2001 at 04:17:34PM +0100, Nicholas Clark wrote: > On Fri, Sep 14, 2001 at 06:11:35PM -0400, Dan Sugalski wrote: > > What we're doing is making sure the common case, the bytecode on disk being > > used by the platform that owns the drive, is as fast as possible. We're > > also mak

parrot compilation failure in Tru64

[just (Sat 11:15 EET) checked-out copy] (After running Configure.pl) make test_prog halts at: cc -std -fprm d -ieee -D_INTRINSICS -DLANGUAGE_C -I..-c -o interpreter.o interpreter.c cc: Error: interpreter.c, line 97: In this statement, "end" is not declared. (undeclared) BUILD_TABLE(foo

Re: Microbenchmark JVM<->PVM

At 09:23 PM 9/15/2001 +0900, Masatake E. Hori wrote: > > piglet$ time java Bench > > 1.470u 0.080s 0:01.59 97.4% 0+0k 0+0io 5784pf+0w > > piglet$ time ./test_prog run.pbc > > 40.080u 0.030s 0:42.07 95.3% 0+0k 0+0io 137pf+0w > >Maybe you got a Just-In-Time compiler? >I turned mine off and I got,

Re: Difficulties

> "BD" == Brent Dax <[EMAIL PROTECTED]> writes: BD> use vars qw(%opcode $fingerprint);#or strict will throw a tantrum so why didn't 'my' work. those are file globals from what i can tell. my causes interpreter.c to blow up. use vars fixes it. uri -- Uri Guttman - [EMA

Re: Difficulties

> "WC" == Will Coleda <[EMAIL PROTECTED]> writes: WC> The README doesn't mention Configure.pl (minor doc patch follows), and WC> Parrot::Opcode is requiring perl5.6, which makes my 5.5.3 quite unhappy. i noticed both of those problems. i found Opcode.pm has a use 5.6.0 and it uses our.

Re: Parrot's mascot

On Fri, Sep 14, 2001 at 07:49:50PM -0400, Gregor N. Purdy wrote: > I'd like to suggest that the Parrot image we've seen associated with > Perl6 be this: http://pettalk.zapp.com.au/images/Africangrey.jpg Simon

Re: Internet Virtual Machine?

On Sat, Sep 15, 2001 at 04:14:16PM +0300, Jarkko Hietaniemi wrote: > On Sat, Sep 15, 2001 at 01:34:06AM -0700, Randal L. Schwartz wrote: > > So is there anything we can leverage from > > http://ivm.sourceforge.net/ > > They use the word 'empower'. I think they lost the credibility game

Re: RFC: Bytecode file format

On Fri, Sep 14, 2001 at 04:42:21PM -0400, Dan Sugalski wrote: > At 03:10 PM 9/14/2001 -0500, Brian Wheeler wrote: > >I've been thinking alot about the bytecode file format lately. Its > >going to get really gross really fast when we start adding other > >(optional) sections to the code. > > > >So

RE: [PATCH] testsuite and Win32 compilation

--- Brent Dax <[EMAIL PROTECTED]> wrote: > Gibbs Tanton - tgibbs: > # ## +#if defined(WIN32) > # ## +program_code = malloc( file_stat.st_size ); > # ## +#else > # > # Also, since more than win32 is not going to have mmap, > # perhaps you could add > # a Configure #define for HAS_MMAP or someth

Re: Microbenchmark JVM<->PVM

> piglet$ time java Bench > 1.470u 0.080s 0:01.59 97.4% 0+0k 0+0io 5784pf+0w > piglet$ time ./test_prog run.pbc > 40.080u 0.030s 0:42.07 95.3% 0+0k 0+0io 137pf+0w Maybe you got a Just-In-Time compiler? I turned mine off and I got, hamlet{193}: time java Bench 16.442u 0.093s 0:22.88 72.2%1

Re: Microbenchmark JVM<->PVM

Masatake E. Hori sent the following bits through the ether: > > piglet$ time java Bench > > 1.470u 0.080s 0:01.59 97.4% 0+0k 0+0io 5784pf+0w > > piglet$ time ./test_prog run.pbc > > 40.080u 0.030s 0:42.07 95.3%0+0k 0+0io 137pf+0w > > Maybe you got a Just-In-Time compiler? Oh, I hadn't r

Re: Microbenchmark JVM<->PVM

On Sat, Sep 15, 2001 at 12:16:55PM +0100, Leon Brocard wrote: > piglet$ time java Bench > 1.470u 0.080s 0:01.59 97.4% 0+0k 0+0io 5784pf+0w > piglet$ time ./test_prog run.pbc > 40.080u 0.030s 0:42.07 95.3% 0+0k 0+0io 137pf+0w We're really 40 times slower than Blackdown? Shite. What're we doing

Re: coding standards

On Fri, Sep 14, 2001 at 11:45:36PM -0500, Gibbs Tanton - tgibbs wrote: > Sorry...forgot the tabs...this one should be right. Thanks, applied.

Re: HOLD IT!

On Sat, Sep 15, 2001 at 01:44:25AM -0700, Brent Dax wrote: > 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? You're the Configure pumpking. I'll only take chang

Microbenchmark JVM<->PVM

Sky asked me if anyone had done any simple benchmarks comparing JVM and PVM at this point. Now, I know we're still at an early stage and haven't really looked at speed, but a trivial counting and simple arithmetic benchmark: piglet$ time java Bench 1.470u 0.080s 0:01.59 97.4% 0+0k 0+0io 5784p

RE: [PATCH] testsuite and Win32 compilation

> ## +#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't really know--it just looks > #a little suspicious.) > > In memory.{h,c} there is

Re: RFC: Bytecode file format

Simon Cozens sent the following bits through the ether: > If you don't know what Python's CodeObjects look like, I suggest > you go see it now. I've been spendind a lot of time recently looking at the Java classfile specification. Yes, they were trying to optimise for space, but there are some i

RE: Difficulties

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... *smacks his

Re: Difficulties

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. - Damien

RE: Difficulties

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 someone... :^) ) # # Er...I think it IS fo

Re: Difficulties

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 someone... :^) ) Er...I think it IS for our, actually. :> I'm so

Internet Virtual Machine?

So is there anything we can leverage from http://ivm.sourceforge.net/ -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraini

RE: [PATCH] testsuite and Win32 compilation

Gibbs Tanton - tgibbs: # ## +#if defined(WIN32) # ## +program_code = malloc( file_stat.st_size ); # ## +#else # # Also, since more than win32 is not going to have mmap, # perhaps you could add # a Configure #define for HAS_MMAP or something like that. # Then you could # test the cc compiler to

HOLD IT!

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.

RE: Difficulties

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 Dax [mailto:[EMAIL

RE: [proposed] Moving *.h to include/parrot/ right away

Gregor N. Purdy: # With the appropriate modification to Makefile.in as well (diff # attached)? I don't remember seeing anyone particularly upset by it. # [[ UPDATE: REALLY ATTACHED THIS TIME ]] The correct modification isn't in Makefile.in, it's in Configure.pl. You'll want to change ccf