Re: "Functional" Perl6 compiler doesn't seem to be functioning
Chris Dutton wrote:
> Maybe I'm just doing something wrong...
> Then when I try to run perl6, via "perl perl6" to avoid @INC issues, I get:
>
> "Code must live with a function"
>
> Trying to compile hw.p6.
What does hw.p6 look like? Anyways:
sub main() {
# your code goes here
my $a = 1;
print $a _ "\n";
}
You might have a look at t/compiler
leo
Re: [perl #15907] [PATCH] Make warnings configurable
Just replying to [EMAIL PROTECTED] does not seem to
forward to the list. Ok, here once again to perl6-internals
Mike Lambert (via RT) <[EMAIL PROTECTED]> writes:
> Looking at the patch, it seems rather GCC-specific. The checking for
> "no-X" versus "X" in the warnings flags seems to be rather non-portable to
> compilers like MSVC.
Yes its gcc-specific. Thats why the -WX vs -Wno-X part is in gcc.pl
The general part in progs.pl of this patch just sets the element
cc_warn in Config::Data, which is used in the Makefile just behind
${ccflags}. An other way to do it is not to introduce a command-line
option, and use ccflags for this, but then you need even more the
gcc-specific part to switch of the automatic warnings, because the
later warning option takes precedence over the former one.
But the cc_warn mechanism was already there, I just made it accessible
through Configure.pl. If this option is called --ccwarn or --cc_warn I
have no strong preference, and I've chosen --ccwarn similar to
--ccflags.
> Unfortunately, I don't believe this is easily fixable.
I think its easy. We need a file for MSVC too, and there we can do all
the special cases for MSVC. Unfortunatly the only Visual compiler I've
access too is a russian version, so i can't submit any patches on
this.
> Mike Lambert
bye
jürgen
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Ok, Pike is... (was: Perl 6 Summary for week ending 2002-08-18)
Explained far more throughly at http://pike.ida.liu.se/ than I can in an e-mail. It really looks like an intriguing language, with a (supposedly) very fast runtime, (again, supposedly) beating Perl, Python, Tcl, and Java in execution times. Unfortunately I've been unable to get it to compile anything successfully after building the compiler, due to an error regarding a file (master.pike) that doesn't appear to even be in the source distribution.
[perl #16670] [PATCH] find_bucket in hash.c not GC safe
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #16670]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16670 >
find_bucket as writen is GC-unsafe. This patch corrects this, by not reusing
old values of bucket pointers across calls to string_compare, which can invoke
compaction, causing the bucket to move.
I have code to fix the same problem in hash_delete, but hash_delete does not
appear to be used, so I can't test it.
--
Jason
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/34819/28529/9eadc8/hash.diff
Index: hash.c
===
RCS file: /cvs/public/parrot/hash.c,v
retrieving revision 1.24
diff -u -r1.24 hash.c
--- hash.c 19 Aug 2002 23:14:48 - 1.24
+++ hash.c 20 Aug 2002 15:02:57 -
@@ -275,15 +275,19 @@
static HASHBUCKET *
find_bucket(Interp *interpreter, HASH* hash, BucketIndex head, STRING *key)
{
+BucketIndex next;
if (head == NULLBucketIndex) return NULL;
if (key != NULL) {
HASHBUCKET* bucket = getBucket(hash, head);
while (bucket != NULL) {
+next = bucket->next;
+
if (string_compare(interpreter, key, bucket->key) == 0) {
-return bucket;
+return getBucket(hash, head);
}
-bucket = getBucket(hash, bucket->next);
+head = next;
+bucket = getBucket(hash, next);
}
}
else {
Re: [perl #16298] [PATCH] pbc2c.pl startup
Leopold Toetsch (via RT) wrote: > attached patch uses now a similar startup code for native compiled > programs like test_main.c. Rediffed and additional patch to compile natively .pasm containing keyed access (pack_key was not export in lib/Parrot/Types.pm). please apply, leo --- Types.pmTue Aug 20 07:06:11 2002 +++ /home/lt/src/parrot-007/lib/Parrot/Types.pm Tue Aug 20 15:59:34 2002 @@ -19,6 +19,7 @@ &pack_sv &pack_op &pack_arg +&pack_key &unpack_byte &unpack_intval --- pbc2c.plTue Aug 20 07:06:07 2002 +++ /home/lt/src/parrot-007/pbc2c.plTue Aug 20 20:54:30 2002 @@ -21,6 +21,7 @@ use Parrot::OpTrans::Compiled; use Parrot::OpLib::core; use Parrot::Config; +use Parrot::Key; my $trans = Parrot::OpTrans::Compiled->new; @@ -196,6 +197,8 @@ print<
testing native compiled parrot
Hi,
Attached shell script (for systems with a shell) runs all parrot tests
natively compiled either static or shared.
It uses the perl6 driver for this, which has (since I ran out of disc
space first ;-) an explicit option to delete the ~2MB static executables
after successful tests.
(perl6 is able to run .p6 .imc .pasm and .pbc files - patches for non
*nix OSs welcome)
A lot of errors are due to these warnings:
-
decimal constant is so large that it is unsigned
-
comparison between signed and unsigned
one error is:
-
`REL_PC' undeclared (first use in this function)
Test result after applying [perl #16298]:
../testnative
[ ... ]
Failed Test Status Wstat Total Fail Failed List of failed
---
t/op/hacks.t 11 100,00% 1
t/op/ifunless.t 62 33,33% 1, 4
t/op/integer.t 399 23,08% 16-23, 34
t/op/interp.t 11 100,00% 1
t/op/rx.t276 22,22% 6, 8, 10, 12, 14, 17
t/op/stacks.t353 8,57% 4, 7, 34
t/op/string.t874 4,60% 81-82, 84-85
t/pmc/perlhash. 151 6,67% 9
t/pmc/sub.t 32 66,67% 2-3
5 subtests skipped.
Failed 9/26 test scripts, 65.38% okay. 29/432 subtests failed, 93.29% okay.
BTW stacks_33 takes quite a long time to finish ... and succeeds finally.
../testnative --shared
[ same result ]
(All tests on i386-linux, perl 5.005_03)
leo
#!/bin/sh
#
# run parrot tests in native C mode
#
cleanup() {
if [ "$S" = "--shared" ] ; then
rm parrot parrot.orig
make
else
mv parrot.orig parrot
fi
exit
}
trap cleanup 1 2 3
mv parrot parrot.orig
if [ "$1" = "--shared" ] ; then
rm parrot
make shared
export LD_LIBRARY_PATH=blib/lib
S=--shared
fi
echo 'cd languages/perl6; perl6 -C $S --ignore-exitcode --rm-exe ../../$1' > parrot
# use -kC to keep all intermediate files
# on error, files are kept
# if you don't --rm-exe, you'll need plenty of disk space
chmod 755 parrot
make test
cleanup
Re: [perl #16670] [PATCH] find_bucket in hash.c not GC safe
Jason Gloudon (via RT) wrote: > > find_bucket as writen is GC-unsafe. This patch corrects this, by not reusing > old values of bucket pointers across calls to string_compare, which can invoke > compaction, causing the bucket to move. Dunno, how expensive getBucket is, but wouldn't it be faster, to check, if a GC run was actually done, and only then recalculate the pointers? This would apply too similar operations (clone ...) too. leo
GC generation?
Would it make people's lives easier and potentially faster if we added a GC_GENERATION field to the interpreter, one we increment every time we do a GC or DOD run? I expect a UINTVAL should be sufficient to hold the counter. This way things that might have to do pointer recalcs or whatever can have a better idea of whether they should or not. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #16670] [PATCH] find_bucket in hash.c not GC safe
On Tue, Aug 20, 2002 at 07:39:28PM +0200, Leopold Toetsch wrote: > > Dunno, how expensive getBucket is, but wouldn't it be faster, to check, > if a GC run was actually done, and only then recalculate the pointers? > This would apply too similar operations (clone ...) too. Probably not worth it. getBucket() is cheap. Assuming it gets inlined, it's just (i == -1) ? NULL : &(struct->field->array)[i] Something like a test, branch, and two dereferences? Otherwise, it's temp = interpreter->collect_count; OPERATION if (interpreter->collect_count > temp) getBucket() which is a test, branch, and one dereference (the second will probably be cached.) Not much difference, and if no GC happened then getBucket() will probably benefit from the cache too.
Re: [perl #16298] [PATCH] pbc2c.pl startup
On Tue, Aug 20, 2002 at 09:12:36PM +0200, Leopold Toetsch wrote: > Leopold Toetsch (via RT) wrote: > > >attached patch uses now a similar startup code for native compiled > >programs like test_main.c. > > Rediffed and additional patch to compile natively .pasm containing keyed > access (pack_key was not export in lib/Parrot/Types.pm). Applied.
Re: GC generation?
Dan Sugalski wrote: > I expect a UINTVAL should be sufficient to hold the counter. Why? Because you don't expect a perl process to run longer than a couple hours? Or because rollover won't matter? -- John Douglas Porter
Re: GC generation?
At 6:16 PM -0400 8/20/02, John Porter wrote: >Dan Sugalski wrote: >> I expect a UINTVAL should be sufficient to hold the counter. > >Why? Because you don't expect a perl process to run longer >than a couple hours? Or because rollover won't matter? Rollover won't really matter much, if we're careful with how we document things. Still, a UINTVAL should be at least 2^32--do you really think we'll have that many GC generations in a few hours? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: [DRAFT PPD] External Data Interfaces
On Sun, 2002-08-18 at 18:53, Brent Dax wrote: > # And do we need a RFC like definition of should/may/must/mustn't? > > If so, I'd suggest the definition be patched into PDD0, so it's shared > by all PDDs instead of repeating the definitions everywhere. Noted. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
[COMMIT] Basic BNF and Parse::RecDescent grammar for Perl6 rx//operator
The subject pretty much says it all. The format pretty much corresponds to the upcoming Exegesis. Major changes were to the modifiers, and a few syntax changes in the depths. Sean, feel free to take what you can use (if anything) from this and delete the rest. -- Jeff <[EMAIL PROTECTED]>
regexen? rules? patterns?
I just put a rough cut at them in CVS. To actually use them, you'll need to apply a rather brutal patch/hack to IMCC, which I'll post to the list shortly. This does not use Jeff's grammar -- I wanted to get what I had into CVS before taking a look at that. Enjoy, /s
imcc hack for perl6 regexes
This is what you'll need. It uses dlopen(), and is likely Bad in a number
of other ways, but if you're on a fairly normal UNIX, it should allow imcc
to grok what P6C produces for regexes.
/s
? languages/imcc/a.out
? languages/imcc/anyop.c
? languages/imcc/anyop.h
? languages/imcc/a.pasm
? languages/imcc/a.pbc
? languages/imcc/foo.imc
? languages/imcc/mine
? languages/imcc/imc.patch
? languages/imcc/imc-hack.tgz
Index: languages/imcc/Makefile
===
RCS file: /cvs/public/parrot/languages/imcc/Makefile,v
retrieving revision 1.3
diff -p -u -w -r1.3 Makefile
--- languages/imcc/Makefile 5 Aug 2002 21:56:30 - 1.3
+++ languages/imcc/Makefile 20 Aug 2002 07:34:58 -
@@ -5,17 +5,20 @@
DEBUG = -g
# GCC
#CC = gcc -efence -Wall -pedantic
-CC = gcc -Wall -pedantic
+CC = gcc -Wall -pedantic -I../../include
YACC = bison -v -y
LEX = flex
-LIBS =
+LIBS = -lm -ldl
#LIBS = -lefence
#LIBS = -ll -ly
-HEADERS = imc.h imcparser.h stacks.h cfg.h instructions.h cfg.h debug.h sets.h
+HEADERS = imc.h imcparser.h stacks.h cfg.h instructions.h cfg.h debug.h \
+ sets.h anyop.h
default :
$(MAKE) imcc
+ cd ../..; $(MAKE) shared
+ cd ../..; $(MAKE) rx_ops.c
clean :
rm -f core
@@ -70,6 +73,11 @@ sets.o: sets.c $(HEADERS)
debug.o: debug.c $(HEADERS)
$(CC) $(DEBUG) -c debug.c
-imcc : imcparser.o imclexer.o imc.o stacks.o symreg.o instructions.o cfg.o sets.o
debug.o
- $(CC) $(DEBUG) -o imcc imc.o imcparser.o imclexer.o stacks.o symreg.o
instructions.o cfg.o sets.o debug.o $(LIBS)
+anyop.o: anyop.c $(HEADERS)
+ $(CC) $(DEBUG) -c anyop.c
+
+imcc : imcparser.o imclexer.o imc.o stacks.o symreg.o instructions.o cfg.o \
+ sets.o debug.o anyop.o
+ $(CC) $(DEBUG) -o imcc imc.o imcparser.o imclexer.o stacks.o symreg.o \
+ instructions.o cfg.o sets.o debug.o anyop.o $(LIBS)
Index: languages/imcc/imc.c
===
RCS file: /cvs/public/parrot/languages/imcc/imc.c,v
retrieving revision 1.17
diff -p -u -w -r1.17 imc.c
--- languages/imcc/imc.c7 Aug 2002 03:23:42 - 1.17
+++ languages/imcc/imc.c20 Aug 2002 07:34:58 -
@@ -18,7 +18,7 @@
/* Globals: */
-IntStack nodeStack;
+IMCStack nodeStack;
int n_spilled;
int lastbranch;
@@ -30,7 +30,7 @@ int lastbranch;
void allocate() {
int to_spill;
-nodeStack = intstack_new();
+nodeStack = imcstack_new();
n_spilled = 0;
while (1) {
@@ -238,7 +238,7 @@ int simplify (){
if (IMCC_DEBUG)
fprintf(stderr, "#simplifying [%s]\n", g[x]->name);
- intstack_push(nodeStack, x);
+ imcstack_push(nodeStack, x);
g[x]->simplified = 1;
changes = 1;
@@ -292,7 +292,7 @@ void order_spilling () {
if (min_node == -1) return; /* We are finished */
- intstack_push(nodeStack, min_node);
+ imcstack_push(nodeStack, min_node);
interference_graph[min_node]->simplified = 1;
}
}
@@ -326,8 +326,8 @@ int try_allocate() {
char buf[256];
SymReg ** graph = interference_graph;
-while ((intstack_depth(nodeStack) > 0) ) {
- x=intstack_pop(nodeStack);
+while ((imcstack_depth(nodeStack) > 0) ) {
+ x=imcstack_pop(nodeStack);
memset(colors, 0, sizeof(colors));
free_colors = map_colors(x, graph, colors);
Index: languages/imcc/imcc.l
===
RCS file: /cvs/public/parrot/languages/imcc/imcc.l,v
retrieving revision 1.6
diff -p -u -w -r1.6 imcc.l
--- languages/imcc/imcc.l 9 Aug 2002 20:11:18 - 1.6
+++ languages/imcc/imcc.l 20 Aug 2002 07:34:58 -
@@ -80,7 +80,7 @@ RANKSPEC\[[,]*\]
"addr" return(ADDR);
"global"return(GLOBAL);
"clone" return(CLONE);
-"string"return(STRING);
+"string"return(STRINGV);
"call" return(CALL);
"print" return(PRINT);
"push" return(PUSH);
@@ -98,6 +98,7 @@ RANKSPEC\[[,]*\]
"=="return(RELOP_EQ);
"!="return(RELOP_NE);
"**"return(POW);
+"," return(COMMA);
{LETTER}{LETTERDIGIT}*":" {
yytext[yyleng-1] = 0; /* trim last ':' */
Index: languages/imcc/imcc.y
===
RCS file: /cvs/public/parrot/languages/imcc/imcc.y,v
retrieving revision 1.13
diff -p -u -w -r1.13 imcc.y
--- languages/imcc/imcc.y 9 Aug 2002 20:11:18 - 1.13
+++ languages/imcc/imcc.y 20 Aug 2002 07:34:58 -
@@ -13,11 +13,12 @@
#include
#include
#include
+#include
#include "imc.h"
+#include "anyop.h"
#define
Re: [perl #16308] [PATCH] logical right shift
> This adds logical shift right opcodes. They are essential for bit shifting > negative values without sign extension getting in the way. Applied, thanks. Mike Lambert
Re: [perl #16274] [PATCH] Keyed access
> I have a clean version that's up to date, and as everybody seems to > be happy with it I'm going to go ahead and commit it now. Ah-ha! I found a showstopper! Oh, it's a little late for that, isn't it? :) Anyways, cd to languages/BASIC, run basic.pl, type "LOAD wumpus", and watch it die on "Not a string!". It could be that basic is using keys in weird ways, or it could be that the key patch is borked...I haven't looked into it enough to determine the true cause here. Thanks, Mike Lambert
Re: GC generation?
> At 6:16 PM -0400 8/20/02, John Porter wrote: > >Dan Sugalski wrote: > >> I expect a UINTVAL should be sufficient to hold the counter. > > > >Why? Because you don't expect a perl process to run longer > >than a couple hours? Or because rollover won't matter? > > Rollover won't really matter much, if we're careful with how we > document things. Still, a UINTVAL should be at least 2^32--do you > really think we'll have that many GC generations in a few hours? Currently, 5000 iterations of life execute in 6 seconds, with 42K DOD runs. At that rate, we have a rollover every week. Not really a problem, but if we have code which doesn't allow for rollover, it is a problem. I can see using the generations value to handle code that is dependant upon things "changing". However, as Steve mentioned, it's probably easiest and fastest to just always re-dereference the bufstart. It might be useful to specify the generation within a pool, with the assumption that the GC would track it and promote it to a different generational pool before an overflow occurs. But it'd make more sense to use a byte/short for this, and reset it to 0 with each promotion. (Or in the case of the final generation, ignore rollover.) A dod generation count doesn't buy us much. Because we don't track inter-pool pointers, we need to do a full dod every time we need to determine the root set. However, copy collection can be localized to a given pool, and as long as we copy every header into that pool, we can avoid copying a lot of data. If we have more DOD's than collections, it would make sense to just iterate over the header list with each collection to search for pool pointers, and hope the generational overhead is outweighed by the ability to avoid re-copying stuff. This will probably be more apparent with real-world programs than test programs that can keep every bit of memory in the cache. If collections are more frequent than DODs, we might be able to set up lists of pointers on a DOD run, organized into generational pool, and just use those during collection. That's effectively one additional pointer per header, however. And there are better uses for such space. Finally, it's possibly to do whole-scale generational promotion of an entire pool, and avoid a generations count altogether. I forget the details exactly, but it involves seperating each generation into two pools, and storing the generation count in the pool itself. It introduces some error into the promotion rates (some stuff is promoted too early, some too late), but it avoids the extra generational count. So in conclusion, generational systems can be done using at most a byte or a short, and it's even possible to do them with nothing at all. So until the need arises, I don't think the generations count would be worth it. Especially since I plan to try and prove the need for a header pool pointer at some point. :) Mike Lambert
