Re: Revamping the build system
Robert Spier [EMAIL PROTECTED] writes: On Tue, 2001-10-23 at 20:52, Russ Allbery wrote: Dan Sugalski [EMAIL PROTECTED] writes: Once we build miniparrot, then *everything* can be done in perl. Having hacked auto* stuff, I think that'd be a good thing. (autoconf and friends are unmitigated evil hacks--people just don't realize how nasty they are because they never need to look inside) 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 syntax, some new macros added, some old macros removed, some old bugs fixed, some new bugs added. 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 about as well as I can imagine doing that for the huge variety of tests one has to deal with. I haven't worked with metaconfig instead, but I have to say that I find it way easier to deal with autoconf than to deal with metaconfig. (I know this is heresy in the Perl community. *grin*) I've maintained the autoconf configuration for a reasonably large package (INN), but not one that requires portability to Windows -- at the same time, last time I checked, 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. But I could be behind on the state of the art. The shell script it generates is butt-ugly, but that's the price of insane portability. I'm not as fond of automake or libtool, but libtool at least lives up to what it says it does, and takes care of a bunch of portability issues that are rather obscure and difficult to deal with. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
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 about as well as I can imagine doing that for the huge variety of tests one has to deal with. I haven't worked with metaconfig instead, but I have to say that I find it way easier to deal with autoconf than to deal with metaconfig. That was horribly unclear. What I meant to say was that I find it way easier to deal with autoconf output than metaconfig output. (As part of my day job, I maintain a site-wide installation of hundreds of packages here at Stanford.) Perl at least does have a non-interactive way of running configure, making it about as good as an autoconf configure script. Other packages that use metaconfig, like elm and trn, are absolutely obnoxious to compile. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
[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_new_string(string_make($data, $size, $encoding, $flags, $type)); --- c = PackFile_Constant_new_string(interpreter, string_make(interpreter, $data, $size, $encoding, $flags, $type));
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 pdump.c 12a13,14 #include parrot/parrot.h #include parrot/interpreter.h 17,22c19,25 struct stat file_stat; int fd; char *packed; long packed_size; struct PackFile * pf; --- struct statfile_stat; intfd; char * packed; long packed_size; struct PackFile * pf; struct Parrot_Interp * interpreter; 60a64 interpreter = make_interpreter(); 63c67,69 PackFile_unpack(pf, packed, packed_size); --- interpreter-code = pf; PackFile_unpack(interpreter, pf, packed, packed_size); Index: Makefile.in === RCS file: /home/perlcvs/parrot/Makefile.in,v retrieving revision 1.38 diff -r1.38 Makefile.in 46,47c46,47 $(PDUMP): pdump$(O) packfile$(O) memory$(O) global_setup$(O) string$(O) strnative$(O) strutf8$(O) strutf16$(O) strutf32$(O) transcode$(O) $(CC) $(CFLAGS) -o $(PDUMP) pdump$(O) packfile$(O) memory$(O) global_setup$(O) string$(O) strnative$(O) strutf8$(O) strutf16$(O) strutf32$(O) transcode$(O) resources$(O) $(C_LIBS) --- $(PDUMP): pdump$(O) $(O_FILES) $(CC) $(CFLAGS) -o $(PDUMP) pdump$(O) $(O_FILES) $(C_LIBS) --- Thus spake [EMAIL PROTECTED] (Peter Cornelius): I get a the following error when I do a 'make' with a fresh checkout. pdump.c: In function `main': pdump.c:63: warning: passing arg 1 of `PackFile_unpack' from incompatible pointe r type pdump.c:63: warning: passing arg 2 of `PackFile_unpack' from incompatible pointe r type pdump.c:63: warning: passing arg 3 of `PackFile_unpack' makes pointer from integ er without a cast pdump.c:63: too few arguments to function `PackFile_unpack' make: *** [pdump.o] Error 1 Host info. [ /home/peterc/parrot/parrot]uname -a Linux goip 2.2.16 #1 Wed Aug 2 20:22:26 GMT 2000 i686 unknown [ /home/peterc/parrot/parrot]gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) It looks like PackFile_pack wants a 'struct Parrot_Interp *interpreter' that it's not getting from pdump.c Just tryin' to help, Peter C.
[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: [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! Personals. http://personals.yahoo.com pbc2c.diff
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./incl
ude -o core_ops.obj -c core_ops.c core_ops.c
core_ops.c(15) : fatal error C1083: Cannot open include file: 'sys/time.h':
No such file or directory
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.
I checked, there is NO sys/time.h header in the CRT include directories...
Is this just me or is this really a problem?
BTW. I'm making a little Object Oriented Basic compiler in Python for
Parrot. It's nice and clean and OO (rather uncommented, but I can fix that)
:) Maybe it will fit into the languages directory, or is it for Perl-only
compilers? I'll upload the code somewhere as soon as it can compile
something. Right now I have the lexer and scanner done, and some parts of
the parser, but it doesn't compile into Parrot code yet.
-Jaen Saul
Here's what's in time.h: (cut a little bit to save space)
typedef long time_t;
typedef long clock_t;
struct tm {
int tm_sec; /* seconds after the minute - [0,59] */
int tm_min; /* minutes after the hour - [0,59] */
int tm_hour;/* hours since midnight - [0,23] */
int tm_mday;/* day of the month - [1,31] */
int tm_mon; /* months since January - [0,11] */
int tm_year;/* years since 1900 */
int tm_wday;/* days since Sunday - [0,6] */
int tm_yday;/* days since January 1 - [0,365] */
int tm_isdst; /* daylight savings time flag */
};
_CRTIMP char * __cdecl asctime(const struct tm *);
_CRTIMP char * __cdecl ctime(const time_t *);
_CRTIMP clock_t __cdecl clock(void);
_CRTIMP double __cdecl difftime(time_t, time_t);
_CRTIMP struct tm * __cdecl gmtime(const time_t *);
_CRTIMP struct tm * __cdecl localtime(const time_t *);
_CRTIMP time_t __cdecl mktime(struct tm *);
_CRTIMP size_t __cdecl strftime(char *, size_t, const char *,
const struct tm *);
_CRTIMP char * __cdecl _strdate(char *);
_CRTIMP char * __cdecl _strtime(char *);
_CRTIMP time_t __cdecl time(time_t *);
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 === RCS file: /home/perlcvs/parrot/pdump.c,v retrieving revision 1.3 diff -r1.3 pdump.c 12a13,14 #include parrot/parrot.h #include parrot/interpreter.h 17,22c19,25 struct stat file_stat; int fd; char *packed; long packed_size; struct PackFile * pf; --- struct statfile_stat; intfd; char * packed; long packed_size; struct PackFile * pf; struct Parrot_Interp * interpreter; 60a64 interpreter = make_interpreter(); 63c67,69 PackFile_unpack(pf, packed, packed_size); --- interpreter-code = pf; PackFile_unpack(interpreter, pf, packed, packed_size); Index: Makefile.in === RCS file: /home/perlcvs/parrot/Makefile.in,v retrieving revision 1.38 diff -r1.38 Makefile.in 46,47c46,47 $(PDUMP): pdump$(O) packfile$(O) memory$(O) global_setup$(O) string$(O) strnative$(O) strutf8$(O) strutf16$(O) strutf32$(O) transcode$(O) $(CC) $(CFLAGS) -o $(PDUMP) pdump$(O) packfile$(O) memory$(O) global_setup$(O) string$(O) strnative$(O) strutf8$(O) strutf16$(O) strutf32$(O) transcode$(O) resources$(O) $(C_LIBS) --- $(PDUMP): pdump$(O) $(O_FILES) $(CC) $(CFLAGS) -o $(PDUMP) pdump$(O) $(O_FILES) $(C_LIBS) --- Thus spake [EMAIL PROTECTED] (Peter Cornelius): I get a the following error when I do a 'make' with a fresh checkout. pdump.c: In function `main': pdump.c:63: warning: passing arg 1 of `PackFile_unpack' from incompatible pointe r type pdump.c:63: warning: passing arg 2 of `PackFile_unpack' from incompatible pointe r type pdump.c:63: warning: passing arg 3 of `PackFile_unpack' makes pointer from integ er without a cast pdump.c:63: too few arguments to function `PackFile_unpack' make: *** [pdump.o] Error 1 Host info. [ /home/peterc/parrot/parrot]uname -a Linux goip 2.2.16 #1 Wed Aug 2 20:22:26 GMT 2000 i686 unknown [ /home/peterc/parrot/parrot]gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) It looks like PackFile_pack wants a 'struct Parrot_Interp *interpreter' that it's not getting from pdump.c Just tryin' to help, Peter C. -- _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/
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!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
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 play Conway's Life on a 15x15 board. Enjoy, and we now return you to your regularly scheduled Stuff. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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 something so... *wrong* about that. I love it. :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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 values
for $Config{i_time} and $Config{i_systime}.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
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 a program to play Conway's Life on a 15x15 board. Thats cool. Enjoy, and we now return you to your regularly scheduled Stuff. Before returning, I made it clear the screen on my terminal before each board print. Too bad a porable solution would be too much to take on... Patch attached (requires recent Parrot/Assembler.pm change to handle octal character escapes in strings). Ok. NOW, I can go back to my regularly scheduled Stuff... Regards, -- Gregor _ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/ Index: examples/assembly/life.pasm === RCS file: /home/perlcvs/parrot/examples/assembly/life.pasm,v retrieving revision 1.1 diff -a -u -r1.1 life.pasm --- examples/assembly/life.pasm 2001/10/24 14:56:48 1.1 +++ examples/assembly/life.pasm 2001/10/24 15:43:37 @@ -158,7 +158,8 @@ dump: save I0 save I1 - print \n\n\n\n\n\n\n\n\n\n\n +# print \n\n\n\n\n\n\n\n\n\n\n +print \033[H\033[2J\0 print --\n set I0, 0 set I1, 14 @@ -171,4 +172,4 @@ ge I1, 0 printloop restore I1 restore I0 - ret \ No newline at end of file + ret
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 # -DPERL_MSVCRT_READFIX -I./incl # ude -o core_ops.obj -c core_ops.c core_ops.c # core_ops.c(15) : fatal error C1083: Cannot open include file: # 'sys/time.h': # No such file or directory # NMAKE : fatal error U1077: 'cl' : return code '0x2' # Stop. # # 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 probably a problem. Configure.pl creates a macro HAS_HEADER_SYSTIME in config.h--why isn't Parrot respecting it? # BTW. I'm making a little Object Oriented Basic compiler in Python for # Parrot. It's nice and clean and OO (rather uncommented, but I # can fix that) # :) Maybe it will fit into the languages directory, or is it # for Perl-only # compilers? I'll upload the code somewhere as soon as it can compile # something. Right now I have the lexer and scanner done, and # some parts of # the parser, but it doesn't compile into Parrot code yet. *Holds his fingers up in a cross shape to ward off the Python devil* ;^) # Here's what's in time.h: (cut a little bit to save space) So you do have time.h? Now I'm confused... FWIW, I get the same thing on Win2000/VC++7: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9254 for 80x86 Copyright (C) Microsoft Corporation 1984-2001. All rights reserved. core_ops.c core_ops.c(15) : fatal error C1083: Cannot open include file: 'sys/time.h': No such file or directory --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 When I take action, Im not going to fire a $2 million missile at a $10 empty tent and hit a camel in the butt. --Dubya
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 syntax, some new macros added, some old macros removed, some old bugs fixed, some new bugs added. 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. My impressions of autoconf are based on my first experience, which dates back a number of years. (And the subsequent port of the thing to DCL for VMS) The thing was full of special cases and odd workarounds to run on any of a dozen different almost-but-not-quite-the-same implementations of the shell. More recent looks just brought back really bad memories. :) It's likely better now, as I don't think it could've gotten worse. 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. But I could be behind on the state of the art. Configure still doesn't, which is part of the problem. Some systems (notably VMS) have a home-grown configure checker which works out fine, but others, like Windows, don't and have to count on static configs. (Last time I looked there were several depending on your compiler, but that might've changed) I'd really like to reduce the amount of platform-specific stuff in the base build/configure of perl 6. Having already done a configure-ish thing for VMS, I think it won't be a huge problem, though rather tedious in spots. 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 alpha the other night... :) and it'll let us skip some of the more awkward bits of make. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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 can be temporarily fixed by the included patch, but there is certainly some deeper consideration in order. I imagine the same problem will pertain to PMCs since they are allocated and deallocated similarly. -Ryan Index: resources.c === RCS file: /home/perlcvs/parrot/resources.c,v retrieving revision 1.1 diff -r1.1 resources.c 26c26 return mem_allocate_aligned(sizeof(STRING)); --- return mem_sys_allocate(sizeof(STRING)); __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
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 STRING pointer unacceptable for free(). Ah, those. STRING and PMC headers will be coming out of an arena soon, so this won't be as much of an issue. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Revamping the build system
At 01:46 PM 10/24/2001 -0500, Garrett Goebel wrote: From: Dan Sugalski [mailto:[EMAIL PROTECTED]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 doesn't, which is part of the problem. Some systems (notably VMS) have a home-grown configure checker which works out fine, but others, like Windows, don't and have to count on static configs. (Last time I looked there were several depending on your compiler, but that might've changed) I'd really like to reduce the amount of platform-specific stuff in the base build/configure of perl 6. Having already done a configure-ish thing for VMS, I think it won't be a huge problem, though rather tedious in spots. Would CML2 contribute to or detract from the tedium? It'd certainly detract from the tedium, and that's always a good thing. :) Whether it'll be useful or not's a separate issue. CML2's more of a Here are your options, which do you want with dependencies, rather than a feature probe system. Anybody know where to get ahold of this ESR guy? He might have some useful ideas. I'll talk with him when I see him in November, if I don't get a chance earlier. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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 --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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 I get another, more
insidious set of errors:
cl -O1 -MD -Z7 -DDEBUGGING -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_IMPLIC
IT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX -I./include -o
vtable_ops.o
bj -c vtable_ops.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9254 for
80x86
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.
vtable_ops.c
vtable_ops.c(37) : error C2296: '+' : illegal, left operand has type
'add_method_t'
vtable_ops.c(43) : error C2296: '+' : illegal, left operand has type
'subtract_method_t'
vtable_ops.c(49) : error C2296: '+' : illegal, left operand has type
'multiply_method_t'
vtable_ops.c(55) : error C2296: '+' : illegal, left operand has type
'divide_method_t'
vtable_ops.c(61) : error C2296: '+' : illegal, left operand has type
'modulus_method_t'
vtable_ops.c(67) : error C2296: '+' : illegal, left operand has type
'concatenate_method_t'
NMAKE : fatal error U1077: 'cl' : return code '0x2'
I guess that's cl being picky about casts. Changing the definition for
add_p_p_p to:
AUTO_OP add (p, p, p) {
((op_func_t)((INTVAL)$2-vtable-add_1 +
(INTVAL)$3-vtable-num_type))($2,$3,$1);
}
gets rid of its error. I don't know how to automate that, though. I've
looked through ops2c.pl, Parrot::Op, and Parrot::OpsFile without any
luck.
Anyway, I think the patch below will work for the first problem. Apply
and enjoy.
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
When I take action, I'm not going to fire a $2 million missile at a $10
empty tent and hit a camel in the butt.
--Dubya
--- core.ops.orig Wed Oct 24 07:54:54 2001
+++ core.opsWed Oct 24 13:06:48 2001
@@ -3,8 +3,11 @@
*/
#include math.h
-#include sys/time.h
+#ifdef HAS_HEADER_SYSTIME
+ #include sys/time.h
+#endif
+
=head1 NAME
core.ops
@@ -95,9 +98,19 @@
=cut
AUTO_OP time(n) {
+#ifdef HAS_HEADER_SYSTIME
+
struct timeval t;
gettimeofday(t, NULL);
$1 = (FLOATVAL)t.tv_sec + ((FLOATVAL)t.tv_usec / 100.0);
+
+#else
+
+ /* Win32 doesn't have gettimeofday or sys/time.h, so just use
normal time w/o microseconds
+ XXX Is there a Win32 equivalent to gettimeofday? */
+ $1 = (FLOATVAL)time(NULL);
+
+#endif
}
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 alpha the other night... :) and it'll let us skip some of the more awkward bits of make. I can certainly see the features of that approach. It just seems like quite a lot of work. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
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 little quest.
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))
AUTO_OP add (p, p, p) {
VTABLE_CALL($2-vtable-add_1, $3-vtable-num_type)($2, $3, $1);
}
After adjusting all applicable ops in that file to use that macro, I got
an error on this line of intclass.c:
Parrot_base_vtables[enum_class_int] = (struct _vtable) {
Okay, can someone stop with the gcc-isms? Changing that to:
struct _vtable temp={
...
};
Parrot_base_vtables[enum_class_int] = temp;
fixed that, but then I got linker errors. Ugh.
LINK : fatal error LNK1104: cannot open file 'classes/intclass.obj'
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Turns out that for some mysterious reason intclass.obj was in . instead
of classes. So I edited the Makefile to reflect that, which got me
this:
core_ops.obj : error LNK2019: unresolved external symbol _sleep
referenced in function _Parrot_sleep_i
test_prog.exe : fatal error LNK1120: 1 unresolved externals
At this point I have to leave. I'll work on this more later.
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
When I take action, I'm not going to fire a $2 million missile at a $10
empty tent and hit a camel in the butt.
--Dubya
Re: Windows compile problems
In perl.perl6.internals, you wrote: +#else + + /* Win32 doesn't have gettimeofday or sys/time.h, 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] Dept. of Physics Lafayette College, Easton PA 18042
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 Coy and Quantum::Superposition on the 5.6.1 alpha the other night... :) and it'll let us skip some of the more awkward bits of make. I can certainly see the features of that approach. It just seems like quite a lot of work. As I've opined before, AD One other thing that nearly all such previous auto-configuration AD systems have in common is that nearly every developer of such a system AD vastly underestimated the scale and complexity of the task to be AD undertaken. Still, with autoconf or metaconfig, a different build system has to be maintained for everyone without /bin/sh. Maintaining duplicate systems is a lot of work too, though it might perhaps end up split up among more (or at least different) people. I honestly don't know what will be best for Perl6 in the long run. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
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 asked if this was sane C and it turned out not to be. I need to revamp the multimethod business to use arrays. Okay, can someone stop with the gcc-isms? Guilty again. But Alex Gough had a patch which fixed this, and I thought he committed it. core_ops.obj : error LNK2019: unresolved external symbol _sleep referenced in function _Parrot_sleep_i test_prog.exe : fatal error LNK1120: 1 unresolved externals Cool, this one wasn't my fault. -- Relf Test Passed.
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 Cool, this one wasn't my fault. That one's mine. I added a sleep opcode, but sleep's apparently less platform-neutral than I thought. :( Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Windows compile problems
Andy Dougherty: # In perl.perl6.internals, you wrote: # # +#else # + # + /* Win32 doesn't have gettimeofday or sys/time.h, 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 too scary. I am not touching that with a ten-foot pole. Sorry. --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 When I take action, Im not going to fire a $2 million missile at a $10 empty tent and hit a camel in the butt. --Dubya
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)((INTVAL)vfunc+(INTVAL)type)) This is entirely my fault; I asked if this was sane C and it turned out not to be. I need to revamp the multimethod business to use arrays. The MIPSPro is getting annoyed about this as well, I think (I didn't notice this before as a gcc compiled version of vtable_ops.o confused make): cc-3316 cc: ERROR File = vtable_ops.c, Line = 49 The expression must be a pointer to a complete object type. (interpreter-pmc_reg-registers[cur_opcode[2]]-vtable-multiply_1 + interpreter-pmc_reg-registers[cur_opcode[3]]-vtable-num_type)(interpreter-pmc_reg-registers[cur_opcode[2]],interpreter-pmc_reg-registers[cur_opcode[3]],interpreter-pmc_reg-registers[cur_opcode[1]]); ^ Okay, can someone stop with the gcc-isms? Guilty again. But Alex Gough had a patch which fixed this, and I thought he committed it. I didn't. I'm avoiding things not in t/, although I guess I could stop doing that. I'll continue not to commit the patch for now. Alex Gough -- He may look like an idiot, and talk like an idiot...but don't let that fool you. He really is an idiot.
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: 1 unresolved externals # # Cool, this one wasn't my fault. # # That one's mine. I added a sleep opcode, but sleep's apparently less # platform-neutral than I thought. :( From the MS documentation: Sleep The Sleep function suspends the execution of the current thread for the specified interval. To enter an alertable wait state, use the SleepEx function. VOID Sleep( DWORD dwMilliseconds // sleep time ); Parameters dwMilliseconds [in] Specifies the time, in milliseconds, for which to suspend execution. ... Header: Declared in Winbase.h; include Windows.h. Library: Use Kernel32.lib. Unfortunately, I can't figure out how to utilize it. Including windows.h causes a conflict with Parrot's definition of BOOL, including winbase.h gives me a ton of syntax errors, and putting the declaration inline just leaves me with 'unresolved symbol _Sleep'. Ugh. In my local copy, I've set up sleep to just have: fprintf(stderr, Sleep currently unimplemented for this platform); HALT; for Win32. This seems to work okay--all tests pass, oddly enough, although I won't be able to play Life. --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 When I take action, I'm not going to fire a $2 million missile at a $10 empty tent and hit a camel in the butt. --Dubya
Are threads what we really want ???
Ive just spent some time looking through the various RFCs 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 of an object must belong to one and only
one execution context. Each execution context has an attached security
context and a security manager.
When making a call from an object in one execution context to a method of an
object in another execution context the security context of the caller is
passed to the receiver an validated by its security manager before being
allowed to execute. Asynchronous execution could be implemented using
oneway functions and future variables and a combination of both.
future variables would allow for returning results from oneway
functions, and for turning synchronous functions into oneway functions.
deferred methods would also be very nice. A deferred method is something
that would be executed at some later time when the current execution context
is idle.
If the following keywords were added to Perl:
1. abandon
2. asynch[ronous]
3. at
4. cancel
5. deferred
6. future
7. oneway
We would be able to write code in the following manner:
oneway foo
{
return 1+1;
}
bar
{
return 2+2;
}
future $i = deffered foo();
execution should continue immediately without waiting for foo to execute.
When at a later time we would like to access $i foo would be forced to
execute. If we during further execution decides that we really doesnt need
the value $i abandon can be used to tell the runtime that we really doesnt
want the future $i.
if( something )
{
abandon $i; # abandon the future, foo will still be executed
}
else if(something else)
{
cancel foo; # remove foo from the deffered queue and abandon associated
futures
}
else
{
print($i); # by accessing the future $i foo will be forced to execute
and
# $i will be turned into a normal variable when the
result
# from foo is assigned to it.
}
The at keyword is for executing a method in another execution context
future $i = foo() at somehost.farfaraway.org;
and on the same host
future $i = foo() at ; either as a thread or as a separate process
depending on OS facilities
and for creation of objects in another execution context.
$i = new SomeClass at 'somehost.farfaraway.org' as 'loginid' identified by
'password';
$i-foo(); # since foo is a oneway the current context doesnt wait for foo
$i-bar(); # since bar is not a oneway the current context waits for bar to
complete its exeution
asynch $i-bar(); # explicitly tell the runtime to execute bar as a oneway
deffered $i-bar(); # put the execution of bar() on the deffered queue of
the remote execution context
deffered # anonymous deffered function/block
{
# something to do at a later time
}
asych at # anonymous asynch function/block executed in an dynamically
generated execution context
{
$i-bar(); # get the value of $i from the parent execution
context and
call
# bar at 'somehost.farfaraway.org'
}
try
{
future $i = deffered foo();
# before leaving the try block:
# all futures that has not been abandoned must be satisfied at this
point
# that is $i behaves just like another variable beyond this point
# and deffred functions must be forced to execute
}
catch ...
futures should also be allowed as parameters to functions, so that a future
reference variable could be passed to a function.
I'm well aware that most of this functionality can be achived by other
means - but I think a language and runtime level solution would be most
elegant and portable. My choice of syntax and keywords are for illustration
purposes only.
Best regards
Espen Harlinn
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 other build tools in Perl 5. use uuids to identify packages, not name, this way my MY::TextModule and your MY::TextModule can be identified as two different packages, OR require that I do something like harlinn::no::MY::TextModule when I name my packages/modules. 6. And please don't use fork at any time during the build process Ideally only the following tools should be needed during the initial build process: 1. The simplest version of make ever written 2. A modern C/C++ compiler 3. A linker To test for the presence of a particular library and associated include files maintain a list of filenames for each supported platform/compiler combination. Like: ACE: LIB=E:\src\Corba\ACE_wrappers\bin\ace.lib; INCLUDE=E:\src\Corba\ACE_wrappers;E:\src\Corba\ACE_wrappers\TAO TCL: LIB=C:\Tcl\lib\tcl83.lib INCLUDE=C:\Tcl\include DEFINES=WIN32;WINNT=1 // a comment DB2: LIB=C:\SQLLIB\lib\db2api.lib;C:\SQLLIB\lib\db2cli.lib INCLUDE=C:\SQLLIB\include and so on ... or in other words: platform independent package name: LIB=[optional fullpath to library[;optional fullpath to next library]] INCLUDE=[optional fullpath of directory[;optional fullpath to next directory]] DEFINES=NAME1=VALUE1;NAME2=VALUE2 // Comments My point is that the format of this file should be kept really simple and used during the next stage of the build process to generate the final build. If a package is missing from this file, then it's not included in the final build. Best regards Espen Harlinn
Re: Are threads what we really want ???
On Wednesday 24 October 2001 08:28 pm, you wrote: Ive just spent some time looking through the various RFCs 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 of an object must belong to one and only one execution context. Each execution context has an attached security context and a security manager. When making a call from an object in one execution context to a method of an object in another execution context the security context of the caller is passed to the receiver an validated by its security manager before being allowed to execute. Asynchronous execution could be implemented using oneway functions and future variables and a combination of both. future variables would allow for returning results from oneway functions, and for turning synchronous functions into oneway functions. deferred methods would also be very nice. A deferred method is something that would be executed at some later time when the current execution context is idle. If the following keywords were added to Perl: 1.abandon 2.asynch[ronous] 3.at 4.cancel 5.deferred 6.future 7.oneway [snip] I'm well aware that most of this functionality can be achived by other means - but I think a language and runtime level solution would be most elegant and portable. My choice of syntax and keywords are for illustration purposes only. Well, from the sideline, I have a couple of comments. First, parrot is supposed to be language agnostic, so such an implementation would go unused in python / perl5 lingo. Perhaps there could be support modules bolted on, who knows. However, this sort of RFC is probably a bit too late (ironically) to make any headway, given that we're in the post RFC stage. As for the technical feasibility. I'm not sure what direction you're trying to take. You speak as if this were an alternative to a threading model, but you don't talk about fake threading or even dispatch-driven code (which I'm sure is already ruled out in the interest of main-stream performance). Thus I'm not quite sure what your vision of the implementation is. The pseudo-perl code is really only syntactic sugar. Again, parrot doesn't care what perl6 does. Only what perl6 needs at a fundamental level. If you want to try again in terms of op-codes, then you might make some more head-way. In general, however, IPC is not an issue parrot is concerned with. As far as I understand, it won't even be part of the core, but instead live in dynamically loaded system modules. I believe the real push of threading is less involved with IPC (or ITC as the case may be) but to provide state-of-the-art programming capability in a reliable (and performance minded) manner. Apache 2.0 will be MT, and perl5 is not, thus there's going to be a rift if at least an MT mod_perl can't be relied apon. The MT has to co-exist with c-librarires (a la DBD drivers), and it seems will be very close to a posix varient (with locking on marginally shared structures). I think a litmus test is going to be MT DBD support. (Currently many CPAN modules refuse to compile alongside perl5.005 threads) None the less, separate execution contexts is exactly what seems to be going forward. Each thread will have (at least) one parrot interpreter datastructure. I'm assuming that this implies completely separate name-spaces. So long as there are well thought out interfaces between the threads, any such IPC that you refer to can be imlemented ontop. In fairness though, I've been partial to the QNX real-time-OS, which utilized at it's lowest level a message passing architecture (not too dissimilar in fundamental concept from what you're suggesting). The advantage was that these messages could be relayed/tunneled anywhere (including other processes or other networks networks). But the messages were hidden behind system calls (as with TCP/IP based messenges), so performance wasn't hindered too badly. That said, I'm not seeing an advantage that outweighs the specialization complexity in implementing what I do understand about your RFC. -Michael
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);
#endif
}
Would you demand that that be put in a separate file? (As a matter of
fact it can't be--ops2c.pl isn't equipped for that sort of thing.)
Where would you draw the line?
# 3. create an initial SIMPLE makefile and a config.h for each supported
# platform/compiler combination
Problem with that is, some platforms don't have make or have bad makes.
Neither nmake nor pmake works well enough on Win32 (and dmake uses a
different syntax). VMS almost always uses mms or mmk (and even if they
had a normal make, I dare you to write a Makefile that will run there
and on other platforms). Most Macs don't even have a command line or
compiler, let alone make. You won't find such things available on
handhelds either.
Personally, I think we should write a shell script (or equivalent) for
each platform that simply invokes the compiler to build miniperl, and we
can do whatever we need from there. A safe config.h could look like:
typedef long INTVAL;
typedef double FLOATVAL;
typedef long opcode_t;
#undef HAS_HEADER_*
etc. Something like that ought to work on any platform; if necessary we
can use #ifdefs with OS symbols (#ifdef WIN32, etc.) to figure it out.
All miniperl does is figure out whatever Configure figures out currently
and builds everything. (Also, we may want to write it so it looks for a
Perl 5 or Perl 6 that's already installed and hands things off to that
if possible.)
When you think about it, how much functionality do we need? Do we need
much of anything OS-dependent besides simple IO, -X operators and
system() to emulate make? Do we even need to be as smart as make? Is
there really a problem with stupidly rebuilding everything, even if it
isn't all necessary?
# I know this isn't hightech, but it works like a charm.
#
# 4. write all other build tools in Perl
Great. How are we going to do this? We can't depend on having a
working Perl around at the beginning of the build process.
# 5. use uuids to identify packages, not name, this way my
# MY::TextModule and
# your MY::TextModule can be identified as two different
# packages, OR require
# that I do something like harlinn::no::MY::TextModule when I name my
# packages/modules.
Huh? Oh, you're talking about namespace conflicts. I don't think
there's much we can do about that, except the official list on the CPAN
we already have.
# 6. And please don't use fork at any time during the build process
Good idea. It's not a good idea for miniperl to require working
ithreads on Win32.
# Ideally only the following tools should be needed during the
# initial build
# process:
# 1. The simplest version of make ever written
Once again, we can't depend on make. Some platforms just don't have it;
others use totally different syntax.
# 2. A modern C/C++ compiler
# 3. A linker
Yup. It's kinda hard to compile C without those. :^)
# To test for the presence of a particular library and
# associated include
# files maintain a list of filenames
# for each supported platform/compiler combination. Like:
#
# ACE: LIB=E:\src\Corba\ACE_wrappers\bin\ace.lib;
# INCLUDE=E:\src\Corba\ACE_wrappers;E:\src\Corba\ACE_wrappers\TAO
# TCL: LIB=C:\Tcl\lib\tcl83.lib INCLUDE=C:\Tcl\include
# DEFINES=WIN32;WINNT=1 // a comment
# DB2: LIB=C:\SQLLIB\lib\db2api.lib;C:\SQLLIB\lib\db2cli.lib
# INCLUDE=C:\SQLLIB\include
#
# and so on ...
#
# or in other words:
# platform independent package name: LIB=[optional fullpath to
# library[;optional fullpath to next library]]
# INCLUDE=[optional fullpath of directory[;optional
# fullpath to next
# directory]]
# DEFINES=NAME1=VALUE1;NAME2=VALUE2 // Comments
#
# My point is that the format of this file should be kept
# really simple and
# used during the next stage of the build process
# to generate the final build. If a package is missing from
# this file, then
# it's not included in the final build.
Huh? I don't get what this is even used for.
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
When I take action, I'm not going to fire a $2 million missile at a $10
empty tent and hit a camel in the butt.
--Dubya
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 (WIN32) {
Sleep($1*1000);
} else {
sleep($1);
}
or the equivalent thereof instead of using #ifdef. If you make sure that
the values are defined to be 0 or 1 rather than just defined or not
defined, it's possible to write code like that instead.
This has the significant advantage that the compiler will continue to
syntax-check the code that isn't active on the build platform, making it
much less likely that one will get syntax errors in the code not active on
the platform of the person doing the patching. The dead-code-elimination
optimization phase of any decent compiler should dump the dead paths
entirely.
It may not be possible to use this in cases where the not-taken branch may
refer to functions that won't be prototyped on all platforms, depending on
the compiler, but there are at least some places where this technique can
be used, and it's worth watching out for.
(In the case above, I'd probably instead define a sleep function on WIN32
that calls Sleep so that the platform differences are in a separate file,
but there are other examples of things like this that are better suited to
other techniques.)
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
