Makefile and Win slash
Hello.
Рlease, when write makefile template draw attention to slash is "\" under
Win
For example, file config/gen/makefiles/root.in contain string
IMCC_DIR_SL = $(IMCC_DIR)${slash}
which converted to
IMCC_DIR_SL = $(IMCC_DIR)\
:-)
Maybe write so
IMCC_DIR_SL = $(IMCC_DIR)${slash} # space need for Win
?
Then build is successful.
Best.
[perl #24131] [PATCH] Almost all tests for languages/perl6 are failing
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #24131] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=24131 > Hi, I noticed that since couple of days the test for 'perl6' are failing. Sadly, I'm still somewhat confused about the connection between P6C::TestCompiler, Parrot::Test and Test::More. However I found out that P6C::TestCompiler passes only three arguments to Parrot::Test::generate_pbc_for(). The problem is that Parrot::Test::generate_pbc_for() expects four arguments. Adding the filename for the '.pbc' seemed to fix the problem. A patch is attached. My setup: Linux linux 2.4.20-4GB-athlon #1 Mon Mar 17 17:56:47 UTC 2003 i686 unknown unknown GNU/Linux This is perl, v5.8.0 built for i586-linux-thread-multi -- attachment 1 -- url: http://rt.perl.org/rt2/attach/65721/49046/57cbf1/perl6_tests.patch perl6_tests.patch Description: perl6_tests.patch
Re: IMCC - calling convention syntax
Will Coleda <[EMAIL PROTECTED]> wrote: > As I realize my example is incorrect. =-) > Is there any reason not to make the ".pcc_call _parse" work also, > rather than having to construct a .Sub? We probably could construct a Sub PMC under the hood. The reason for 2 stages is efficiency though: If you are generating and calling a Sub in a loop, there is unneeded overhead. So the rule is: Construct your Sub early. But there are of course examples, where there isn't any loop. leo
Binary MMD vtable fucntions are in
I figured out why my MMD code was failing (off by one errors. D'oh!) and fixed it, with the fixes checked in. Two-arg multimethod dispatch now works. (More bizarrely, it's actually *faster* to use Integer PMCs, which do MMD, than it is to use PerlInt PMCs, which don't do MMD. Go figure :) I'll see about getting some docs into the system so this stuff is actually usable. One thing that the current MMD system does *not* do is inherited methods. PerlInt isa perlscalar isa scalar, but adding a MMD method on a scalar doesn't do anything for PerlInts. That needs to be addressed. Dan
Re: IMCC - calling convention syntax
The optimizer could hoist the construct out of the loop... Assuming it can realize its possible to do that. Regards, -- Gregor On Tue, 2003-10-07 at 01:14, Leopold Toetsch wrote: > Will Coleda <[EMAIL PROTECTED]> wrote: > > As I realize my example is incorrect. =-) > > > Is there any reason not to make the ".pcc_call _parse" work also, > > rather than having to construct a .Sub? > > We probably could construct a Sub PMC under the hood. The reason for 2 > stages is efficiency though: If you are generating and calling a Sub in > a loop, there is unneeded overhead. > So the rule is: Construct your Sub early. But there are of course > examples, where there isn't any loop. > > leo -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: [perl #24131] [PATCH] Almost all tests for languages/perl6 are failing
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > Hi, > I noticed that since couple of days the test for 'perl6' are failing. Applied, thanks. leo
You too can direct the Attack of the Unicode Monster!
WHich ought ot be some sort of really bad '50s era black and white giant atomic monster movie. But anyway. ICU now configures and builds on at least some platforms. That means it's time to build an encoding and chartype library for it. This'd be a nice little project for someone looking to get their feet wet in the parrot source, so... Takers? Dan
Re: You too can direct the Attack of the Unicode Monster!
I've been poking at it a little bit--nothing finished yet, but I've been making some headway. JEff On Tuesday, October 7, 2003, at 08:51 AM, Dan Sugalski wrote: WHich ought ot be some sort of really bad '50s era black and white giant atomic monster movie. But anyway. ICU now configures and builds on at least some platforms. That means it's time to build an encoding and chartype library for it. This'd be a nice little project for someone looking to get their feet wet in the parrot source, so... Takers? Dan
[perl #24149] [PATCH] small Makefile patch (rm *.s in realclean instead of clean)
# New Ticket Created by "Aldo Calpini" # Please include the string: [perl #24149] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=24149 > make clean is currently doing an rm *.s, thus removing the asmfun.s which gets installed by Configure.pl. this means that, in order to build parrot after a make clean, you need to run Configure.pl again. this patch moves the rm *.s instruction to the (seemingly more appropriate) 'realclean' make target. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; -- attachment 1 -- url: http://rt.perl.org/rt2/attach/65774/49110/5adfe4/makefile.patch makefile.patch Description: makefile.patch
Re: You too can direct the Attack of the Unicode Monster!
On Tuesday, Oct 7, 2003, at 17:51 Europe/Berlin, Dan Sugalski wrote: WHich ought ot be some sort of really bad '50s era black and white giant atomic monster movie. But anyway. ICU now configures and builds on at least some platforms. That means it's time to build an encoding and chartype library for it. This'd be a nice little project for someone looking to get their feet wet in the parrot source, so... I have been looking at the string stuff and icu with this in mind. I would have mentioned it earlier, except that the closer I get to the monster the less equipped I seem. At the moment the only weapon I possess is time. Also, I'm working on OS X, so there is the library loading issue to be solved too. Mike Takers? Dan
Re: [RfC] new PMC compiler
Dan Sugalski <[EMAIL PROTECTED]> wrote: > If it's clearer to read than pmc2c.pl, sure, go for it. That code's been > stretched well beyond what it it it was originally intended to do and is > getting kind of crufty. Ok, checked in. Almost all of the exceptions to code generation are handled in separate (Pmc2c::)classes. It for sure needs some cleanup but should be much more maintanable then the old one. $ perl classes/pmc2c2.pl --vtable # => vtable.dump $ perl classes/pmc2c2.pl --dump classes/*.pmc # => *.dump $ perl classes/pmc2c2.pl --c classes/*.pmc # => *.c *.h Then the rules from classes/Makefile (*.o depend on generated *.h) interfer, so disabling PMC2C in the classes/Makefile helps for testing. > Dan leo
More interface files
While I'm having a heck of a time getting anything besides a connection to happen with it... I've checked in library/postgres.pasm. It's an interface to Posgres 7.3's libpq (the C interface to postgres) library. Have fun, folks. Dan
[perl #24155] [PATCH] pmc2c2 Makefile
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #24155]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24155 >
Attached is a patch for easier testing of the new pmc compiler.
It probably requires gnu make, because it currently uses
ifdef/else/endif to allow switching the old and new pmc compilers.
For now it should be rather simple to adjust these few lines. And
finally they can go away.
Further changes:
- see the comment in Makefile.in WRT the fin: target
- removed some dependencies on generated pmc_*.h files
Comments welcome
leo
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/65800/49132/410abe/pmc2c-make.patch
--- parrot/classes/pmc2c2.plTue Oct 7 17:40:32 2003
+++ parrot-leo/classes/pmc2c2.plTue Oct 7 18:04:33 2003
@@ -268,6 +268,7 @@
gen_super_meths($class, $vt);
my $Dumper = Data::Dumper->new([$class], [qw(class)]);
$Dumper->Indent(1);
+print "Writing $dump\n" if $opt{verbose};
open PMD, ">$dump" or die "Can't write '$dump";
print PMD $Dumper->Dump;
close PMD;
--- parrot/config/gen/makefiles/classes.in Sat Sep 13 13:40:18 2003
+++ parrot-leo/config/gen/makefiles/classes.in Tue Oct 7 21:48:36 2003
@@ -18,7 +18,46 @@
CC = ${cc}
PERL = ${perl}
MAKE_F=${make}
+
+NEW_PMC = 1
+
+all : $(O_FILES) fin
+
+# main depends on $(O_FILES)
+# when 1 is recompiled each other is out of data, but not
+# to the rules insided here, so we touch al O_FILES at the
+# end and avoid getting called ever and ever
+fin:
+ touch $(O_FILES)
+
+ifdef NEW_PMC
+
+PMC2CD=$(PERL) pmc2c2.pl --dump --verb
+PMC2CC=$(PERL) pmc2c2.pl --c --verb
+
+pmc_%.h %.c : %.dump
+ $(PMC2CC) $<
+
+../vtable.dump: ../vtable.tbl
+ cd .. ; perl classes/pmc2c2.pl --vt
+
+%.dump : %.pmc ../vtable.dump
+ $(PMC2CD) $<
+
+else
+
PMC2C=$(PERL) pmc2c.pl
+
+pmc_%.h %.c : %.pmc
+ $(PMC2C) $<
+
+endif
+
+.PRECIOUS: %.c %.dump
+
+
+%.o : %.c
+ $(CC) $(CFLAGS) -o $@ -c $<
.c$(O):
$(CC) $(CFLAGS) ${cc_o_out}$@ -c $<
--- parrot/config/inter/pmc.pl Thu Oct 2 14:06:03 2003
+++ parrot-leo/config/inter/pmc.pl Tue Oct 7 21:39:22 2003
@@ -83,10 +83,7 @@
my $parent_headers = '';
$parent_headers .= "pmc_$_.h " foreach (pmc_parents($pmc));
$pmc_build .= "$pmc.c pmc_$pmc.h: $parent $pmc.pmc\n";
- $pmc_build .= "\t\$(PMC2C) perlhash.pmc\n" if ($pmc eq 'orderedhash');
- $pmc_build .= "\t\$(PMC2C) $pmc.pmc\n";
$pmc_build .= "\n";
- $pmc_build .= "$pmc\$(O): \$(NONGEN_HEADERS) $parent_headers pmc_$pmc.h\n";
}
# build list of libraries for link line in Makefile
parrot stack and Z-machine
Still working on the prelude to the preface to the "Z-machine running natively on Parrot" project, namely translating Z-code into a Perl executable. (My brother, who's a CS professor so he should know, says I'm actually *compiling* it. Compiling bytecode to an interpreted language? Weird!) I'm making some progress, but now I have to deal with the harder opcodes I'd ignored, like I/O and save/restore. (Interesting to hear about Parrot curses, wrt Z-code I/O, btw.) I figured I could just use the Perl subroutine mechanism to emulate Z-machine calls. So I just translate Z-code's "call routine arg0 arg1..." to "&routine(arg0, arg1, ...)" and "ret value" becomes "return $value". I realized that I get in trouble when we get to the save/restore commands. Those are supposed to save and restore the call stack, which includes the subroutine addresses & all the local variables in the various routines. Am I right in thinking I don't actually have access to that in Perl? (That is, I can't change the call stack at runtime, such that when I "return" it'll return to a different subroutine than the one that actually called the current routine.) In Perl, I can fake it by making my entire program have no subroutines (yuck!) and using gotos and manually storing the call stack. Then I thought, "but what do I do about Parrot?", which is supposed to be the whole point of this project. Then I thought that maybe I *do* have access to Parrot's stack! So the question is, will I be able to write a Parrot opcode that resets the Parrot call stack? And I guess to reset the register stacks too? Otherwise, I won't be able to save/restore games. -Amir __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: parrot stack and Z-machine
Amir Karger writes: > Still working on the prelude to the preface to the "Z-machine running > natively on Parrot" project, namely translating Z-code into a Perl > executable. (My brother, who's a CS professor so he should know, says > I'm actually *compiling* it. Compiling bytecode to an interpreted > language? Weird!) Yeah. Actually, Perl 5 is even compiling itself, into bytecode, which is then interpreted. An example of a language that isn't compiled is, say, Bourne Shell, which is executed based on repeated text substitutions. > I'm making some progress, but now I have to deal with > the harder opcodes I'd ignored, like I/O and save/restore. (Interesting > to hear about Parrot curses, wrt Z-code I/O, btw.) > > I figured I could just use the Perl subroutine mechanism to emulate > Z-machine calls. So I just translate Z-code's "call routine arg0 > arg1..." to "&routine(arg0, arg1, ...)" and "ret value" becomes "return > $value". > > I realized that I get in trouble when we get to the save/restore > commands. Those are supposed to save and restore the call stack, which > includes the subroutine addresses & all the local variables in the > various routines. Am I right in thinking I don't actually have access > to that in Perl? (That is, I can't change the call stack at runtime, > such that when I "return" it'll return to a different subroutine than > the one that actually called the current routine.) You mean.. in Parrot? In Perl 5, using just the language, no you don't. In parrot, however, you do. There is actually no call stack; it's implicit in the cascade of P1 registers. That's why we call it the 'call chain'. > In Perl, I can fake it by making my entire program have no subroutines > (yuck!) and using gotos and manually storing the call stack. Then I > thought, "but what do I do about Parrot?", which is supposed to be the > whole point of this project. Then I thought that maybe I *do* have > access to Parrot's stack! > > So the question is, will I be able to write a Parrot opcode that resets > the Parrot call stack? And I guess to reset the register stacks too? > Otherwise, I won't be able to save/restore games. >From disk, right? No, I don't think that's possible using the basic Parrot mechanisms. That is, in general, a fairly hard thing to do (although, it might be done, considering how people have been talking about serialization recently. In any case, it's not available at the moment). So you could wait until it might be implemented. But I don't recommend that, because then you're counting on the timelyness of open source, which doesn't exist :-). Then let's think of some other solutions to the problem. This will be pretty abstract, mind you. My first thought is that you can create a "call frame" object. This object then holds a reference to the current lexical pad, the bytecode address, and a reference to the caller's call frame object. This object would be passed into new functions much in the manner of the return continuations we now pass. To save, you walk up these frames, serializing whatever is there (presuming you know the exact set of possible data types that might be in your lexical pads). Because of the explicitness of the bytecode format, it's possible to take this data and re-create the stack out-of-band, and then jump to the proper address. It'd be a lot of work, but possible nonetheless. There are problems with that, however. The biggest one is that it places a lot of restrictions on what kinds of data you're allowed to have in your program. I don't know Z-code well enough to say whether this will be too limiting. Maybe continuations aren't so hard to serialize after all (well, excluding things like open filehandles and such). What's the status on the serialization subsystem? Luke
Re: You too can direct the Attack of the Unicode Monster!
> Also, I'm working on OS X, so there is the library loading issue to be > solved too. 10.3 should make this easier, as it has dlopen emulation. (While not necessarily the perfect long-term solution, it at least lets you get things done.) -R
