Re: Revamping the build system

Brent Dax <[EMAIL PROTECTED]> writes: > What about little inline things? > AUTO_OP sleep(i|ic) { > #ifdef WIN32 > Sleep($1*1000); > #else > sleep($1); > #endif > } This reminds me. gcc is slowly switching over to writing code like that as: if

RE: Revamping the build system

Espen Harlinn: # Here is just a proposal: # # 1. Place os neutral code in one directory # 2. place os dependant code in platform specific directories What about little inline things? AUTO_OP sleep(i|ic) { #ifdef WIN32 Sleep($1*1000); #else sleep($1

Re: Are threads what we really want ???

On Wednesday 24 October 2001 08:28 pm, you wrote: > I’ve just spent some time looking through the various RFC’s for Perl 6. > > IMHO: The various proposals dealing with multi threading, synchronization > and RPC can be solved in a different way. > > Instead of thinking about multiple threads, one

RE: Revamping the build system

Here is just a proposal: 1. Place os neutral code in one directory 2. place os dependant code in platform specific directories 3. create an initial SIMPLE makefile and a config.h for each supported platform/compiler combination I know this isn't hightech, but it works like a charm. 4. write all

Are threads what we really want ???

I’ve just spent some time looking through the various RFC’s for Perl 6. IMHO: The various proposals dealing with multi threading, synchronization and RPC can be solved in a different way. Instead of thinking about multiple threads, one could think about multiple execution contexts. Each instance

RE: Windows compile problems

Dan Sugalski: # At 10:20 PM 10/24/2001 +0100, Simon Cozens wrote: # >On Wed, Oct 24, 2001 at 01:56:01PM -0700, Brent Dax wrote: # > > core_ops.obj : error LNK2019: unresolved external # symbol _sleep # > > referenced in function _Parrot_sleep_i # > > test_prog.exe : fatal error LNK1120

Re: Windows compile problems

On Wed, 24 Oct 2001, Simon Cozens wrote: > On Wed, Oct 24, 2001 at 01:56:01PM -0700, Brent Dax wrote: > > After thinking about this for a couple minutes, I came up with a > > solution involving a macro (I can hear the groans from here): > > #define VTABLE_CALL(vfunc, type) > > ((op_func_t)((INTVA

RE: Windows compile problems

Andy Dougherty: # In perl.perl6.internals, you wrote: # # >+#else # >+ # >+ /* Win32 doesn't have gettimeofday or , so just use # >normal time w/o microseconds # >+ XXX Is there a Win32 equivalent to gettimeofday? */ # # Yes. See ext/Time/HiRes/HiRes.xs in perl-current. Whoa. That is just

Re: Windows compile problems

At 10:20 PM 10/24/2001 +0100, Simon Cozens wrote: >On Wed, Oct 24, 2001 at 01:56:01PM -0700, Brent Dax wrote: > > core_ops.obj : error LNK2019: unresolved external symbol _sleep > > referenced in function _Parrot_sleep_i > > test_prog.exe : fatal error LNK1120: 1 unresolved externals >

Re: Windows compile problems

On Wed, Oct 24, 2001 at 01:56:01PM -0700, Brent Dax wrote: > After thinking about this for a couple minutes, I came up with a > solution involving a macro (I can hear the groans from here): > #define VTABLE_CALL(vfunc, type) > ((op_func_t)((INTVAL)vfunc+(INTVAL)type)) This is entirely my fault; I

Re: Revamping the build system

On 24 Oct 2001, Russ Allbery wrote: > Dan Sugalski <[EMAIL PROTECTED]> writes: > > > Making the build system (past the initial bootstrap of microparrot) all > > perl would make building modules on systems without a build system of > > their own (like, say, the Mac, as I found trying to install C

Re: Windows compile problems

In perl.perl6.internals, you wrote: >+#else >+ >+ /* Win32 doesn't have gettimeofday or , so just use >normal time w/o microseconds >+ XXX Is there a Win32 equivalent to gettimeofday? */ Yes. See ext/Time/HiRes/HiRes.xs in perl-current. -- Andy Dougherty [EMAIL PROTECTED

RE: Windows compile problems

Bent Dax: # vtable_ops.c(37) : error C2296: '+' : illegal, left operand has type # 'add_method_t' ... # AUTO_OP add (p, p, p) { # ((op_func_t)((INTVAL)$2->vtable->add_1 + # (INTVAL)$3->vtable->num_type))($2,$3,$1); # } Okay, this is going to be a blow-by-blow of my littl

Re: Revamping the build system

Dan Sugalski <[EMAIL PROTECTED]> writes: > Making the build system (past the initial bootstrap of microparrot) all > perl would make building modules on systems without a build system of > their own (like, say, the Mac, as I found trying to install Coy and > Quantum::Superposition on the 5.6.1 al

RE: Windows compile problems

Dan Sugalski: # At 09:37 AM 10/24/2001 -0700, Brent Dax wrote: # >It's probably a problem. Configure.pl creates a macro # >HAS_HEADER_SYSTIME in config.h--why isn't Parrot respecting it? # # Parrot bug. I'll go fix unless someone beats me to it. Patch below my sig fixes this; however, after this

RE: Revamping the build system

From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > At 11:33 PM 10/23/2001 -0700, Russ Allbery wrote: > >Configure doesn't really deal with portability to non-Unix > >systems either, being a shell script itself. Perl seemed > >to just bypass it in favor of pre-generated results. > > Configure still

RE: Windows compile problems

At 09:37 AM 10/24/2001 -0700, Brent Dax wrote: >It's probably a problem. Configure.pl creates a macro >HAS_HEADER_SYSTIME in config.h--why isn't Parrot respecting it? Parrot bug. I'll go fix unless someone beats me to it. Dan

RE: Revamping the build system

At 01:46 PM 10/24/2001 -0500, Garrett Goebel wrote: >From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > > At 11:33 PM 10/23/2001 -0700, Russ Allbery wrote: > > >Configure doesn't really deal with portability to non-Unix > > >systems either, being a shell script itself. Per

Re: Memory bug: new_string_header() and free_string()

At 11:10 AM 10/24/2001 -0700, R. O'Neil wrote: >I noticed recently that calling pdump on a >pbc file, in this case mops.pbc, causes a >segfault. I traced this down to calling >free_string() in resources.c. It just so >happens that calling mem_allocate_aligned() >in new_string_header() makes the

Memory bug: new_string_header() and free_string()

I noticed recently that calling pdump on a pbc file, in this case mops.pbc, causes a segfault. I traced this down to calling free_string() in resources.c. It just so happens that calling mem_allocate_aligned() in new_string_header() makes the STRING pointer unacceptable for free(). This ca

Re: Revamping the build system

At 11:33 PM 10/23/2001 -0700, Russ Allbery wrote: > >> I've looked inside a lot, and I definitely do not agree. But maybe you've > >> not seen autoconf 2.50 and later? > > > Russ- Could you expand on this? 2.50 seems to be at least 80% the same > > as the previous versions, with very similar m4

RE: Windows compile problems

Jaen Saul: # I can't compile on a Win XP 26.00 machine with Microsoft # Visual Studio 6.0 # (no service packs), but I could compile it a while ago. Nmake says: # # cl -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT # -DHAVE_DES_FCRYPT # -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS # -DPER

Re: Silly little demo

Dan -- > I just checked in examples/assembly/life.pasm. Inspired by Damian's truly > evil SelfGOL, and the need to have a working demo for last night's > Boston.PM meeting (which I didn't manage--there was a dopey logic problem I > missed until just *after* the meeting, of course) I cobbled up

Re: Windows compile problems

In perl.perl6.internals, you wrote: >At 06:14 PM 10/23/2001 +0200, Jaen Saul wrote: >>I checked, there is NO sys/time.h header in the CRT include directories... >>Is this just me or is this really a problem? > >It's really a problem. :( Yes. Parrot should probably be respecting Perl5's Configure

Re: Windows compile problems

At 06:14 PM 10/23/2001 +0200, Jaen Saul wrote: >I checked, there is NO sys/time.h header in the CRT include directories... >Is this just me or is this really a problem? It's really a problem. :( >BTW. I'm making a little Object Oriented Basic compiler in Python for >Parrot. Y'know, there's just

Silly little demo

I just checked in examples/assembly/life.pasm. Inspired by Damian's truly evil SelfGOL, and the need to have a working demo for last night's Boston.PM meeting (which I didn't manage--there was a dopey logic problem I missed until just *after* the meeting, of course) I cobbled up a program to p

Re: [PATCHES] make problems

Please ignore this, I sent these out early yesterday in two different mails. They never ended up being posted so I assumed the problem was on my end. Apparently there was just intense lag. Sorry for the multiple posts... -Ryan __ Do You Yahoo!?

Re: PackFile_unpack in pdump.c is missing the first arg

Ryan -- Thanks. Applied. -- Gregor On Tue, 2001-10-23 at 11:51, [EMAIL PROTECTED] wrote: > I fixed this with the patches below, so everything at least will make. However >calling pdump on a pbc file will segfault at the end. > > Index: pdump.c > ==

Windows compile problems

Hi, I can't compile on a Win XP 26.00 machine with Microsoft Visual Studio 6.0 (no service packs), but I could compile it a while ago. Nmake says: cl -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX -I./

Re: [PATCH] pbc2c.pl causing make problems with mops.pbc

Oops, attached the wrong file. Here is the diff. --- "R. O'Neil" <[EMAIL PROTECTED]> wrote: > Here is a fix for that. The interpreter was not > getting passed in as it should. > > -Ryan __ Do You Yahoo!? Make a great connection at Yahoo! Per

[PATCH] pbc2c.pl causing make problems with mops.pbc

Here is a fix for that. The interpreter was not getting passed in as it should. -Ryan __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com pbc2c.pl

Re: PackFile_unpack in pdump.c is missing the first arg

I fixed this with the patches below, so everything at least will make. However calling pdump on a pbc file will segfault at the end. Index: pdump.c === RCS file: /home/perlcvs/parrot/pdump.c,v retrieving revision 1.3 diff -r1.3 pdu

[PATCH] Bugfix for pbc2c.pl

pbc2c.pl is generating some problems when deconstructing mops.pbc. The patch is simple: Index: pbc2c.pl === RCS file: /home/perlcvs/parrot/pbc2c.pl,v retrieving revision 1.2 diff -r1.2 pbc2c.pl 124c124 < c = PackFile_Constant_

Re: Revamping the build system

Russ Allbery <[EMAIL PROTECTED]> writes: > I'm not sure what there is to expand on. I've looked at 2.50, and it > definitely doesn't look like an unmitigated evil hack to me. It looks > like a collection of tests for various standard things that packages need > to know to compile, put together