Re: [perl #23172] [PATCH] Some more Configure --miniparrot tweaks
JüRgen BöMmels [EMAIL PROTECTED] wrote: move the standard-file-handles in io_stdio.c also to PMCs and add the Applied ... new 'P'-prototype to build_native_call.pl ... except that one, which was alredy there ;-) Thanks, leo
Q: pdd03 calling conventions
While trying to implement pdd03 inside the PIR assembler I'm not too sure if I get everything right from pdd03. Currently I have this: - a subroutine call can be prototyped or non_prototyped - a subroutine definition can be both and un_prototyped. In the latter case it checks CI0 and takes parameters either way. - return values are prototyped only currently Q: Should there be code to check the amount and types of function parameters? Always, or on demand (e.g. with a check_params in the sub def)? Now to return conventions: Q: Is the prototype specifier for return values independent or is it the same as that in the subroutine definition. Or has that to be checked at runtime (I3 has some info about expected return values, but not really, where to place return value(s)) Q: And finally, how does the caller get the return value(s), again a runtime check of which prototype specifier is having that info? The same WRT checking applies here. I think, parrot/imcc and any HL calling some (external) subroutines need header files, which have the information about function signatures and return values. Q: Which format (C-like .h files?), in runtime/parrot/include? Thanks, leo
Re: [RFC] Dynamic PMC Classes
Thanks for the clarification. Does that mean that a mechanism for dynamic PMCs would automatically allow them to be written in Parrot also (and not only load binary libs)? -- [EMAIL PROTECTED] - http://www.web42.com/crenz/ - http://www.web42.com/
Re: [RFC] Dynamic PMC Classes
Dan Sugalski [EMAIL PROTECTED] wrote: At 12:43 +0200 7/30/03, Leopold Toetsch wrote: I have started looking at dynamic classes. I have currently - new subdirectory /dynclasses - small hack for classes/pmc2c.pl to consider this directory too - dynclasses/foo.pmc, dynclasses/Makefile (unportable, but short ;-) Here's what I was thinking instead. We build classes as shared libraries, unless otherwise noted. PMC libraries get loaded up with an op--load_pmc or something of the sort. It takes a PMC name and tacks on the library prefix and suffix as need be. So we first need some more Configure support: - runtime directory - path separator - $(SO) extension (The dynclasses subdir is ment for building these libs, not for loading them from there [1]) ... We load in the PMC library, call its setup routine, call its initialization routine, and let it do its thing. The split into Csetup and class_init is necessary for our static PMCs too. Mainly ParrotIO is using the current class_init hook to work around initialization order and to setup its method table. [2] ... The setup routine, when called, will at the least register the PMC's class in the class name hash. There should be some code in the system to manage this, though it needs mutex protection. IMHO: The class_setup loads the class into the global Parrot_base_vtables. The class_init registers the class in a per interpreter class name hash. Different threads might have different classes loaded, but the class_enums have to be uniq. *) Determine the init and setup routine names - Parrot_classname_class_setup - Parrot_classname_class_init The class_setup also sets the class_enum i.e vtable-base_type. *) Make some standard for library paths and names - runtime/parrot/pmc *) Figure out how we want to handle versioning brrr, I need a Ponie ;-) [1] If there are no objections I'll check that part in. It shouldn't be too hard, to finally have a perl script, that generates a platform independend Makefile out from %PConfig. [2] Somehow related: There was some discussion about PMC methods. What about a standard way to allow methods for (almost) all PMCs: - have a vtable slot for the method hash - move find_method into default.pmc - PMCs used in that process mainly PerlHash should better not have methods ;-) leo
Re: [perl #23039] [PATCH] event handling-2
Leopold Toetsch [EMAIL PROTECTED] wrote: [ event checking without runloop penalty ] 3) So when the next instruction (normal, CG core) or the branch instruction (prederefed cores) gets executed, first the op_func_table or the patched instructions are restored and then the event handler can be called. Should I rediff that stuff and submit again / put it in? leo
make distclean
Is it the intended behaviour of make distclean to delete all files under the CVS/ directories, thus rendering succeeding cvs upd calls impossible? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
Test::More isa Catholic?
From Test::More docs:
# XXX BAD! $pope-isa('Catholic') eq 1
is( $pope-isa('Catholic'), 1,'Is the Pope Catholic?' );
This does not check if $pope-isa('Catholic') is
true, it checks if it returns 1. Very different.
Similar caveats exist for false and 0. In these
cases, use ok().
ok( $pope-isa('Catholic') ), 'Is the Pope Catholic?' );
This was presumably a better example before the isa_ok function was added ...
Perhaps this should be changed to something similar that couldn't use that?
(And if not, the and should presumably be changed round in the
This does not check ... line ...)
Tony
Devel::Cover and Module::Build
Has anyone added a ./Build cover target for Module::Build yet? I'm trying to move some of my stuff from MakeMaker to Build, and can't really work out how to pull my make cover equivalent across... Thanks, Tony
Re: Devel::Cover and Module::Build
On Thu, Jul 31, 2003 at 11:47:41AM +0100, Richard Clamp wrote:
trying to move some of my stuff from MakeMaker to Build, and can't
really work out how to pull my make cover equivalent across...
From Siesta::Build, Siesta's Module::Build subclass:
sub ACTION_cover {
my $self = shift;
$self-depends_on('build');
system qw( rm -rf cover_db );
# sometimes we get failing tests, which makes Test::Harness
# die. catch that
eval {
local $ENV{PERL5OPT} = -MDevel::Cover=-summary,0;
$self-ACTION_test(@_);
};
system qw( cover -report html );
}
Excellent, thanks.
Tony
subroutines and python status
Hey all, I'm trying to get functions working in python, and I'm not sure the best way to do this. What seems natural to me is to define subroutines in the middle of the code as I walk the parse tree: .sub __main__ goto endsub .sub _f print :(\n ret .end endsub: $I0 = addr _f end .end But of course, this prints a sad face. :/ I've read imcc/docs/parsing.pod, so I know why it does this... But what's the alternative? I can store all my subroutine definitions in a list or something and then dump them out after the __main__ routine. Is that the right approach? It seems strange to me, but I'm new at this. --- Incidentally, I spent all day working on pirate, and it now generates (and runs!) code for a bunch of python structures: - lists, strings, ints - assignment and multi-assignment ( x,y=1,2 ) - while, for, if/elif/else, break, continue - math operations (+, -, *, /, %) - boolean logic (and, or, not) - comparison operators It now runs amk's euclid.py perfectly now. Do we have a way to compare the speed vs python? :) Also, I wrote a pretty-printer for the lists in parrot, and you can call it (and presumably other parrot subs) directly from python code: if 1 2: _pyprint(one is greater than two...) print neat,huh? If I could get this subroutine stuff figured out, you could call functions written in python, too. :) http://sixthdev.versionhost.com/viewcvs.cgi/pirate/ Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Search for win32 developer
Index: io/io_win32.c
===
RCS file: /cvs/public/parrot/io/io_win32.c,v
retrieving revision 1.24
diff -u -r1.24 io_win32.c
--- io/io_win32.c 21 Jul 2003 18:00:45 - 1.24
+++ io/io_win32.c 31 Jul 2003 11:06:04 -
@@ -97,23 +97,23 @@
{
HANDLE h;
if ((h = GetStdHandle(STD_INPUT_HANDLE)) != INVALID_HANDLE_VALUE) {
-PIO_STDIN(interpreter) =
-PIO_win32_fdopen(interpreter, layer, h, PIO_F_READ);
+PIO_STDIN(interpreter) = new_io_pmc(interpreter,
+PIO_win32_fdopen(interpreter, layer, h, PIO_F_READ));
}
else {
return -1;
}
if ((h = GetStdHandle(STD_OUTPUT_HANDLE))
!= INVALID_HANDLE_VALUE) {
-PIO_STDOUT(interpreter) =
-PIO_win32_fdopen(interpreter, layer, h, PIO_F_WRITE);
+PIO_STDOUT(interpreter) = new_io_pmc(interpreter,
+PIO_win32_fdopen(interpreter, layer, h, PIO_F_WRITE));
}
else {
return -2;
}
if ((h = GetStdHandle(STD_ERROR_HANDLE)) != INVALID_HANDLE_VALUE) {
-PIO_STDERR(interpreter) =
-PIO_win32_fdopen(interpreter, layer, h, PIO_F_WRITE);
+PIO_STDERR(interpreter) = new_io_pmc(interpreter,
+PIO_win32_fdopen(interpreter, layer, h, PIO_F_WRITE));
}
else {
return -3;
Re: subroutines and python status
Michal Wallace: I can store all my subroutine definitions in a list or something and then dump them out after the __main__ routine. Is that the right approach? It seems strange to me, but I'm new at this. That seems to be the way to do it, speaking as someone who's working on a Perl 5-to-PIL converter (using the B optree-introspection modules). The problem here is that .sub has meanings beyond just here's a subroutine. .sub is actually a compilation unit, which complicates things terribly. You *could* just use branches and labels to create a new sub without actually making a new compilation unit: .sub main ... branch mysub_after mysub: ... ret mysub_after: ... .end But that makes imcc run slower, so I don't recommend it. --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker
Re: subroutines and python status
Michal Wallace wrote: Hey all, What seems natural to me is to define subroutines in the middle of the code as I walk the parse tree: You can do that: .sub __main__ bsr _main end .end .sub _main .sub _f print :)\n ret .end .sub _g print ;-)\n ret .end bsr _f bsr _g ret .end So you have just to emit code, to call your real main at the beginning. You could also have a look at docs/calling_conventions.pod, which currently is being implemented. But if you have your code generation for subs/params/return values in one place, its for sure not complicated to switch calling conventions later. Incidentally, I spent all day working on pirate, and it now generates (and runs!) code for a bunch of python structures: Wow. Sincerely, Michal J Wallace leo
Re: [RFC] Dynamic PMC Classes
At 11:10 +0200 7/31/03, Leopold Toetsch wrote: *) Determine the init and setup routine names - Parrot_classname_class_setup - Parrot_classname_class_init The class_setup also sets the class_enum i.e vtable-base_type. Well... there are versioning issues there. We ought to be able to have multiple versions of a class loaded, in which case this may not work. I'm pretty sure that there are some platforms that require unique names in libraries across the entire process. [1] If there are no objections I'll check that part in. It shouldn't be too hard, to finally have a perl script, that generates a platform independend Makefile out from %PConfig. Nope, go for it. [2] Somehow related: There was some discussion about PMC methods. What about a standard way to allow methods for (almost) all PMCs: - have a vtable slot for the method hash - move find_method into default.pmc - PMCs used in that process mainly PerlHash should better not have methods ;-) Yeah, that sounds familiar. I'll have to get back to you on this when I've got more tha 5 minutes for email. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Question about interpreter == NULL
Hello, Some Parrot functions allow a NULL interpreter and some don't. Parrot_warn for example fails badly if called with a NULL-interpreter, but in config/gen/platform/ansi.c in Parrot_floatval_time it is exactly called in this way. So what functions should allow for a NULL interpreter, which should assert (interpreter != NULL) and which should just asume a non-NULL interpreter? Parrot_sprintf? PIO_eprintf? Parrot_warn? bye boe -- 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
Re: Devel::Cover and Module::Build
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Thursday 31 July 2003 12:47, Richard Clamp wrote:
On Thu, Jul 31, 2003 at 11:39:48AM +0100, Tony Bowden wrote:
Has anyone added a ./Build cover target for Module::Build yet? I'm
trying to move some of my stuff from MakeMaker to Build, and can't
really work out how to pull my make cover equivalent across...
From Siesta::Build, Siesta's Module::Build subclass:
sub ACTION_cover {
my $self = shift;
$self-depends_on('build');
system qw( rm -rf cover_db );
Not very portable :)
Hm, would it make sense to build this support into Module::Build as a default?
Anyway, thanx, I will using that or something similair.
Best wishes,
Tels
- --
Signed on Thu Jul 31 17:31:07 2003 with key 0x93B84C15.
PGP key on http://bloodgate.com/tels.asc or per email.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBPyk2fHcLPEOTuEwVAQGf7Qf+OlMXMREAGwjqE7/5ZfsEd6BavsKW+p1+
ARSolFpW53Mpe+UJXTDUg3DW0u+eTfKsEFKPI2EPI78dBowGQSTplMkYS5WFIgyQ
pE0ZIQ83pOardp3QrkKaa1B79DBjFLzTpAxirlWtSpjLn95ZyQ8nhHL3MMH00Ly8
3LOGLYKhspft8e0xBY26eHHI4oV7KBMkcLUt6qIFygHKsE+ZYy9ALzvu46xVU1z0
qWEzIzZh/+NLs33mDVgzs4QlphXHRt6EBjyv6bWkx8C4BW5UX0GY0ryRoE8MpSk4
+EQXKEQiUamaxl6JglsexZMCdpab89qRfbjEWHSz455TUnWOnJqS5w==
=+VWw
-END PGP SIGNATURE-
Perl 6's for() signature
From an old summary: http://www.perl.com/pub/a/2003/04/p6pdigest/20030427.html?page=2 Paul Hodges took a crack at implementing for as a subroutine and came up with something that didn't look too insane. Luke Palmer added a refinement allowing for n at a time looping. However, for reasons that I can't quite put my finger on, I'm not quite sure that either method has got the sub signature quite right, and I'm not entirely sure how you would express for's signature as a Perl 6 signature anyway. Answers on a mailing list please. Did this ever get resolved to anyone's satisfaction? While reading EX6, I found myself wonder exactly what for() would look like in Perl 6 code... -John
Re: Perl 6's for() signature
At 10:05 AM 7/31/2003 -0600, Luke Palmer wrote:
Well, I don't think it's possible, actually. There's a flattening
list context at the beginning (implying a sugary drink from 7 eleven),
followed by a code block. But, as we know, slurpy arrays can only
come at the end of positional parameters.
Anyone but me feel the need for non-greedy slurpy arrays? similar to
non-greedy RE matches?
Then we could do:
sub for ([EMAIL PROTECTED], block) {...}
Proposed behavior of *?@ : All Arguement to Parameter mapping left of it
are processed Left to Right. Once seen, the mapping starts over right to
left. Everything remaining is slurpable.
Yes, it's more expensive to use, just like the RE version, but shouldn't
impact performance _too_ bad when it's not, since the behavior will be
detectable at compile time.
Thoughts?
Doing something like that was what came to my mind right away when I read
what Luke put too... It feels right to me, though I don't know that
counts for much. :-)
Jonathan
RE: Perl 6's for() signature
At 01:29 PM 7/31/2003 -0400, Hanson, Rob wrote:
Anyone but me feel the need for non-greedy
slurpy arrays? similar to non-greedy RE matches?
I definately like the idea of having something like that. It probably
wouldn't be used much, but it is nice to have the option.
One thing though, can't you accomplish the same thing by slurping
everything, then poping the block off of the array?
One could do most of the stuff in P6 parameters with P5's @_. But as Damian
showed at the end of E6, it can quickly grow to a nightmare, and making it
nicer is what P6 is all about.
-- Rod
Rob
-Original Message-
From: Rod Adams [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 31, 2003 12:56 PM
To: Perl 6 Language
Subject: Re: Perl 6's for() signature
At 10:05 AM 7/31/2003 -0600, Luke Palmer wrote:
Well, I don't think it's possible, actually. There's a flattening
list context at the beginning (implying a sugary drink from 7 eleven),
followed by a code block. But, as we know, slurpy arrays can only
come at the end of positional parameters.
Anyone but me feel the need for non-greedy slurpy arrays? similar to
non-greedy RE matches?
Then we could do:
sub for ([EMAIL PROTECTED], block) {...}
Proposed behavior of *?@ : All Arguement to Parameter mapping left of it
are processed Left to Right. Once seen, the mapping starts over right to
left. Everything remaining is slurpable.
Yes, it's more expensive to use, just like the RE version, but shouldn't
impact performance _too_ bad when it's not, since the behavior will be
detectable at compile time.
Thoughts?
RE: Perl 6's for() signature
Anyone but me feel the need for non-greedy
slurpy arrays? similar to non-greedy RE matches?
I definately like the idea of having something like that. It probably
wouldn't be used much, but it is nice to have the option.
One thing though, can't you accomplish the same thing by slurping
everything, then poping the block off of the array?
Rob
-Original Message-
From: Rod Adams [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 31, 2003 12:56 PM
To: Perl 6 Language
Subject: Re: Perl 6's for() signature
At 10:05 AM 7/31/2003 -0600, Luke Palmer wrote:
Well, I don't think it's possible, actually. There's a flattening
list context at the beginning (implying a sugary drink from 7 eleven),
followed by a code block. But, as we know, slurpy arrays can only
come at the end of positional parameters.
Anyone but me feel the need for non-greedy slurpy arrays? similar to
non-greedy RE matches?
Then we could do:
sub for ([EMAIL PROTECTED], block) {...}
Proposed behavior of *?@ : All Arguement to Parameter mapping left of it
are processed Left to Right. Once seen, the mapping starts over right to
left. Everything remaining is slurpable.
Yes, it's more expensive to use, just like the RE version, but shouldn't
impact performance _too_ bad when it's not, since the behavior will be
detectable at compile time.
Thoughts?
[perl #23186] [PATCH] adding yield semantics to IMCC
# New Ticket Created by Kenneth A Graves
# Please include the string: [perl #23186]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23186
The .pcc_* directives are working for me in terms of implementing
function calls. I want to do something similar for iterator calls.
I've decided to implement iterators using coroutines.
The initial call to the iterator (sending in the parameters) is
identical to a function call, except P0 is a Coroutine PMC instead of a
Sub, and there is an implicit Continuation argument to mark where the
caller wants control to go after the iterator is complete.
Subsequent calls to the iterator are just savetop, invoke, loop around
to the return_from_subroutine label.
Inside the iterator, there are three differences compared to a function:
1) Every register in use needs to be saved to the user stack. (Anyone
have a clean way to do this?)
2) Returning control to the caller is via invoke, not invoke P1.
3) When finished, invoke the implicit Continuation mentioned above.
To get this to work with IMCC, the only change I need is to get (2) to
happen. So I added .pcc_begin_yield and .pcc_end_yield, which do
the exact same thing as .pcc_begin_return and .pcc_end_return,
except leaving off the P1. (For now. Moving the save/restore of (1)
sub into the yield would be nice if I can figure out a way to do it.)
Example code and patch (relative to languages/imcc) attached. If I'm
off in left field compared to how coroutines/iterators were planned to
be supported, someone please say so.
--kag
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/62028/45719/dee7e8/pcc_yield.patch
-- attachment 2 --
url: http://rt.perl.org/rt2/attach/62028/45720/422adf/foo.pir
--- imcc.l.~1.40.~ 2003-07-30 11:00:29.0 -0400
+++ imcc.l 2003-07-31 12:38:42.0 -0400
@@ -153,6 +153,8 @@
.pcc_sub return(PCC_SUB);
.pcc_begin_returnreturn(PCC_BEGIN_RETURN);
.pcc_end_return return(PCC_END_RETURN);
+.pcc_begin_yieldreturn(PCC_BEGIN_YIELD);
+.pcc_end_yield return(PCC_END_YIELD);
prototypedreturn PROTOTYPED;
non_prototypedreturn NON_PROTOTYPED;
--- imcc.y.~1.71.~ 2003-07-30 19:00:18.0 -0400
+++ imcc.y 2003-07-31 13:01:50.0 -0400
@@ -409,13 +409,14 @@
%token t GLOBAL ADDR CLONE RESULT RETURN POW SHIFT_RIGHT_U LOG_AND LOG_OR
%token t COMMA ESUB
%token t PCC_BEGIN PCC_END PCC_CALL PCC_SUB PCC_BEGIN_RETURN PCC_END_RETURN
+%token t PCC_BEGIN_YIELD PCC_END_YIELD
%token t PROTOTYPED NON_PROTOTYPED
%token s LABEL
%token t EMIT EOM
%token s IREG NREG SREG PREG IDENTIFIER STRINGC INTC FLOATC REG MACRO ENDM
%token s PARROT_OP
%type t type
-%type i program sub sub_start emit nsub pcc_sub sub_body pcc_ret
+%type i program sub sub_start emit nsub pcc_sub sub_body pcc_ret pcc_yield
%type s classname relop
%type i labels _labels label statements statement
%type i pcc_sub_call
@@ -582,6 +583,22 @@
PCC_END_RETURN '\n' { $$ = 0; }
;
+pcc_yield: PCC_BEGIN_YIELD '\n' {
+Instruction *i, *ins = instructions;
+char name[128];
+if (!ins || !ins-r[1] || ins-r[1]-type != VT_PCC_SUB)
+fataly(EX_SOFTWARE, pcc_yield, line,
+pcc_yield not inside pcc subroutine\n);
+$sr$ = ins-r[1];
+sprintf(name, #pcc_sub_yield_%d:, line - 1);
+i = _mk_instruction(, name, NULL, 0);
+i = emitb(i);
+i-type = ITPCCSUB | ITLABEL | ITPCCYIELD;
+}
+pcc_returns
+PCC_END_YIELD '\n' { $$ = 0; }
+;
+
pcc_returns: /* empty */{ $$ = 0; }
| pcc_returns '\n'{ if($1) add_pcc_return($sr0, $1); }
| pcc_returns pcc_return '\n' { if($2) add_pcc_return($sr0, $2); }
@@ -599,6 +616,7 @@
| MACRO '\n' { $$ = 0; }
| pcc_sub_call{ $$ = 0; }
| pcc_ret
+| pcc_yield
;
labels:/* none */ { $$ = NULL; }
--- instructions.h.~1.24.~ 2003-07-29 11:00:15.0 -0400
+++ instructions.h 2003-07-31 12:53:29.0 -0400
@@ -11,7 +11,8 @@
ITSPILL = 0x40, /* set P31,x ; set x, p31 spilling */
ITEXT = 0x80, /* instruction is extcall in JIT */
ITSAVES = 0x100, /* saveall/restoreall in a bsr */
-ITPCCSUB = 0x200 /* PCC sub call */
+ITPCCSUB = 0x200, /* PCC sub call */
+ITPCCYIELD = 0x400 /* yield from PCC call instead of return */
};
--- pcc.c.~1.1.~2003-07-30 09:42:48.0 -0400
+++ pcc.c 2003-07-31 13:22:15.0 -0400
@@ -48,9 +48,10 @@
expand_pcc_sub_ret(Parrot_Interp interpreter, Instruction *ins)
{
SymReg *arg, *sub,
Re: subroutines and python status
Michal Wallace [EMAIL PROTECTED] wrote: .sub __start__ call __main__ .end .sub __main__ .sub _f print :) ret .end $I0 = addr _f print $I0 end .end That prints :), followed by the address, No, can't imagine that: $ parrot -o- pirate.imc __start__: bsr __main__ _f: print :) ret __main__: set_addr I16, _f print I16 end leo
Re: Can't build current CVS on Win32
Vladimir Lipskiy wrote: Run the Configure script with --jitcapable=0 --execcapable=0 That helped, but shouldn't this be recognized by Configure.pl? It's a short term workaround.
Re: subroutines and python status
Hey all, I'm trying to get functions working in python, and I'm not sure the best way to do this. What seems natural to me is to define subroutines in the middle of the code as I walk the parse tree: .sub __main__ goto endsub .sub _f print :(\n ret .end endsub: $I0 = addr _f end .end But of course, this prints a sad face. :/ I've read imcc/docs/parsing.pod, so I know why it does this... But what's the alternative? I can store all my subroutine definitions in a list or something and then dump them out after the __main__ routine. Is that the right approach? It seems strange to me, but I'm new at this. I think your approach may be fine. You can store them in a list and dump them at the cost of a little extra memory (not a concern at this point), but you can also put them inline, so long as you have something like this at the beginning of the file: .sub __START__ call __main__ .end So it emits that code right away, because it's the first compilation unit imcc sees. --- Incidentally, I spent all day working on pirate, and it now generates (and runs!) code for a bunch of python structures: - lists, strings, ints - assignment and multi-assignment ( x,y=1,2 ) - while, for, if/elif/else, break, continue - math operations (+, -, *, /, %) - boolean logic (and, or, not) - comparison operators Very Cool. It now runs amk's euclid.py perfectly now. Do we have a way to compare the speed vs python? :) We just modify it to repeat 100,000 times or so, and compare that way. Which I did. Parrot comes in about 3x slower than python on euclid. From looking at the imcc code, though, I think it could be much much better. One of my questions is, why do you make so many PerlNums when there isn't a trace of a floating point number to be found...? In any case, great work! Luke Also, I wrote a pretty-printer for the lists in parrot, and you can call it (and presumably other parrot subs) directly from python code: if 1 2: _pyprint(one is greater than two...) print neat,huh? If I could get this subroutine stuff figured out, you could call functions written in python, too. :) http://sixthdev.versionhost.com/viewcvs.cgi/pirate/ Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: Q: pdd03 calling conventions
While trying to implement pdd03 inside the PIR assembler I'm not too sure if I get everything right from pdd03. Currently I have this: - a subroutine call can be prototyped or non_prototyped - a subroutine definition can be both and un_prototyped. In the latter case it checks CI0 and takes parameters either way. - return values are prototyped only currently Q: Should there be code to check the amount and types of function parameters? Always, or on demand (e.g. with a check_params in the sub def)? Larry spoke of a double entry point to every Perl function, at least. The first is the untrusted entry point, which would do checking and all of that. The second is the trusted entry point, which the compiler can call if it knows for sure everything is right, so time isn't wasted checking. I don't know how much you want this to affect the imcc level. It would be nice to have everything prototyped, actually. Every sub would also have an unprototyped entry point by a different name, which would convert things to the way the prototyped sub wanted them. In fact, it's probably a mistake to think that the sub itself knows whether it's prototyped or not. It's really the caller who should be saying that (consider a perl sub defined in the middle of a file, unprototyped above, prototyped below). Luke Now to return conventions: Q: Is the prototype specifier for return values independent or is it the same as that in the subroutine definition. Or has that to be checked at runtime (I3 has some info about expected return values, but not really, where to place return value(s)) Q: And finally, how does the caller get the return value(s), again a runtime check of which prototype specifier is having that info? The same WRT checking applies here. I think, parrot/imcc and any HL calling some (external) subroutines need header files, which have the information about function signatures and return values. Q: Which format (C-like .h files?), in runtime/parrot/include? Thanks, leo
Re: make distclean
On Thu, 31 Jul 2003, Sebastian Bergmann wrote: Is it the intended behaviour of make distclean to delete all files under the CVS/ directories, thus rendering succeeding cvs upd calls impossible? As I understand it, make distclean is what you would do before packaging up Parrot for a public release, so, yes, it should nuke the CVS and .cvsignore files. If this isn't what you intend, you should probably be using make cvsclean instead, which specifically doesn't delete the CVS files. Simon
Re: make distclean
Simon Glover wrote: As I understand it, make distclean is what you would do before packaging up Parrot for a public release, so, yes, it should nuke the CVS and .cvsignore files. Okay, thanks for the info. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
Can't build current CVS on Win32
LIB: fatal error LNK1181: Input file jit_cpu.obj can not be opened NMAKE: fatal error U1077: 'lib' : Return-Code '0x49d' Stop. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
Re: Can't build current CVS on Win32
Run the Configure script with --jitcapable=0 --execcapable=0
or find the line
if (-e jit/$cpuarch/core.jit) {
in config/auto/jit.pl and replace it with this
if (-e jit/$cpuarch/core.jit and $osname ne 'MSWin32') {
LIB: fatal error LNK1181: Input file jit_cpu.obj can not be opened
NMAKE: fatal error U1077: 'lib' : Return-Code '0x49d'
Stop.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
Re: Search for win32 developer
Thanks, applied. Simon
Re: Can't build current CVS on Win32
Vladimir Lipskiy wrote: Run the Configure script with --jitcapable=0 --execcapable=0 That helped, but shouldn't this be recognized by Configure.pl? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
Re: subroutines and python status
On Thu, 31 Jul 2003, Leopold Toetsch wrote: You can do that: .sub __main__ bsr _main end .end .sub _main ... So you have just to emit code, to call your real main at the beginning. Well that worked, and even let me get rid of the endsub label: .sub __start__ call __main__ .end .sub __main__ .sub _f print :) ret .end $I0 = addr _f print $I0 end .end That prints :), followed by the address, which is what I wnat. I can't seem to duplicate the problem I was having now, but somehow last night, if I commented out the addr line, the _f sub wouldn't run. In other words, it was like the addr call was actually invoking the routine. Maybe I was just tired. :) You could also have a look at docs/calling_conventions.pod, which currently is being implemented. Thanks. I hadn't seen the pdd version. I was going off the other version in imcc/docs [ in pirate, not in this example :) ] Incidentally, I spent all day working on pirate, and it now generates (and runs!) code for a bunch of python structures: Wow. Actually, between imcc and the python compiler module, it's not nearly as hard as I thought it would be. So far, I think the parrot version is actually a lot simpler than the python compiler, just because imcc is doing so much of the work. Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: subroutines and python status
On Thu, 31 Jul 2003, Brent Royal-Gordon wrote: Michal Wallace: I can store all my subroutine definitions in a list or something and then dump them out after the __main__ routine. That seems to be the way to do it, speaking as someone who's working on a Perl 5-to-PIL converter (using the B optree-introspection modules). I think I'm going to go ahead and take this approach. Thanks! :) Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: Question about interpreter == NULL
Juergen Boemmels [EMAIL PROTECTED] wrote: Hello, Some Parrot functions allow a NULL interpreter and some don't. Parrot_warn for example fails badly if called with a NULL-interpreter, but in config/gen/platform/ansi.c in Parrot_floatval_time it is exactly called in this way. So what functions should allow for a NULL interpreter, which should assert (interpreter != NULL) and which should just asume a non-NULL interpreter? Parrot_sprintf? PIO_eprintf? Parrot_warn? IMHO we just need 2 functions that check for a valid interpreter: PIO_eprintf PIO_printf for printing to stderr/stdout during 1st interpreter construction destruction if something goes wrong. In all other cases we have an valid interpreter (or an parent interpreter if any). bye boe leo
Re: [RFC] Dynamic PMC Classes
Dan Sugalski [EMAIL PROTECTED] wrote: At 11:10 +0200 7/31/03, Leopold Toetsch wrote: *) Determine the init and setup routine names - Parrot_classname_class_setup - Parrot_classname_class_init The class_setup also sets the class_enum i.e vtable-base_type. Well... there are versioning issues there. We ought to be able to have multiple versions of a class loaded, in which case this may not work. I'm pretty sure that there are some platforms that require unique names in libraries across the entire process. I think we can postpone that for later. Perl5 module versioning + addons that handle this, have very sophisticated schemes. Though I can just imagine to find/load a specific version of a pmc class, but not to have different versions of one module loaded, both providing the class Foo. [1] If there are no objections I'll check that part in. It shouldn't be too hard, to finally have a perl script, that generates a platform independend Makefile out from %PConfig. Nope, go for it. Ok. Have checked in that a minute ago. leo
Re: subroutines and python status
On 31 Jul 2003, Luke Palmer wrote: It now runs amk's euclid.py perfectly now. Do we have a way to compare the speed vs python? :) We just modify it to repeat 100,000 times or so, and compare that way. Oh, duh. :) Which I did. Parrot comes in about 3x slower than python on euclid. From looking at the imcc code, though, I think it could be much much better. No doubt. One of my questions is, why do you make so many PerlNums when there isn't a trace of a floating point number to be found...? Because I didn't read the docs that said PerlNum means float. :) I'll switch it to PerlInt (or maybe int?) later... It's also using far more temporary variables than it needs. Right now I'm thinking that no matter how complicated the expression, it really only needs two extra registers: the result and a temporary variable, because all the operators are either unary or binary... I might try that after I get functions and classes working. In any case, great work! :) thanks! Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: Question about interpreter == NULL
Leopold Toetsch [EMAIL PROTECTED] writes:
[...]
PIO_eprintf
PIO_printf
for printing to stderr/stdout during 1st interpreter construction
destruction if something goes wrong. In all other cases we have an
valid interpreter (or an parent interpreter if any).
This means all the Parrot_warn(NULL,...) in config/gen/platform/ansi.c
are invalid. Ok remove them
Index: config/gen/platform/ansi.c
===
RCS file: /cvs/public/parrot/config/gen/platform/ansi.c,v
retrieving revision 1.7
diff -u -r1.7 ansi.c
--- config/gen/platform/ansi.c 14 Jul 2003 07:58:20 - 1.7
+++ config/gen/platform/ansi.c 31 Jul 2003 19:22:42 -
@@ -27,7 +27,6 @@
{
/* unable to provide this level of precision under ANSI-C, so just fall
back to intval time for this. */
-Parrot_warn(NULL, PARROT_WARNINGS_PLATFORM_FLAG, Parrot_floatval_time not
accurate);
return (FLOATVAL)Parrot_intval_time();
}
@@ -39,7 +38,6 @@
void
Parrot_sleep(unsigned int seconds)
{
-Parrot_warn(NULL, PARROT_WARNINGS_PLATFORM_FLAG, Parrot_sleep not implemented);
return;
}
@@ -92,7 +90,6 @@
void *
Parrot_dlopen(const char *filename)
{
-Parrot_warn(NULL, PARROT_WARNINGS_PLATFORM_FLAG, Parrot_dlopen not implemented);
return NULL;
}
@@ -115,7 +112,6 @@
void *
Parrot_dlsym(void *handle, const char *symbol)
{
-Parrot_warn(NULL, PARROT_WARNINGS_PLATFORM_FLAG, Parrot_dlsym not implemented);
return NULL;
}
@@ -127,7 +123,6 @@
int
Parrot_dlclose(void *handle)
{
-Parrot_warn(NULL, PARROT_WARNINGS_PLATFORM_FLAG, Parrot_dlclose not
implemented);
return 0;
}
Re: subroutines and python status
One of my questions is, why do you make so many PerlNums when there isn't a trace of a floating point number to be found...? Because I didn't read the docs that said PerlNum means float. :) I'll switch it to PerlInt (or maybe int?) later... Yeah, all your auxillary data; i.e. the flags you check for control flow, c. should be int registers. Python ints should still probably be pmcs. It's also using far more temporary variables than it needs. Right now I'm thinking that no matter how complicated the expression, it really only needs two extra registers: the result and a temporary variable, because all the operators are either unary or binary... I might try that after I get functions and classes working. Indeed. Functionality is the most important thing at the moment; we can worry about speed later. You mind submitting a patch to put this in the languages/pirate directory of the parrot distro? I'd like to stay up to date, and probably do some work (as, I imagine, would others). Luke In any case, great work! :) thanks! Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
[imcc] objects speed, .include and file-scoped vars, and various stuff
Hi there, Since objects are closing in, I begin to work on the new version of Befunge, that will be written in imcc. Anyway, whatever the reason, I'm playing with imcc and have some questions about it: - will objects introduce a speed overhead? I'm asking this question because the Lahey space can be modelized by an object, with attributes (min and max x, min and max y, content) and methods (set_max, set_min, get_value_at, etc.). But since there will be only one Lahey space, an object may be overkill (especially if there are speed issues), and I'd better create a regular module with file-scoped vars and global subroutines. - if I implement the Lahey space module as a regular module, how can I declare file-scoped vars that will be accessible by the subroutines of the file and only them? Since imcc parses compilation units first, I don't see how to do this... Maybe with the .namespace keyword? - if I can't use file-scoped lexical vars, maybe the solution is to declare some global var with the global keyword (in some sort of init_module function). The question is once again if this comes with a speed overhead? And if yes, which will be faster: a Lahey space full-blown object or a regular module with globals (that one need to retrieve)? - can you think of another solution that will be imcc-friendly? On a side note: - the global does not seem to be available: $ cat foo.imc sub _main .local int width width = 0 global lhs_width = width end .end $ imcc foo.imc error:imcc:iANY file foo.imc line 5: op not found 'store_global_sc_i' (store_global2) $ Will the feature be implemented soon? - when using the global keyword, can the string where one stores the value be anything? For example, can I use foo::bar as a global name? - when including a file with .include, the line numbering continues to increase without being zeroed, and it's quite difficult to track errors because of this behavior - when including a file, if it isn't properly newline terminated, you get an error even if the line is a comment... $ imcc main.imc (error) line 26: parse error, unexpected $undefined, expecting '\n' Didn't create output asm. Thanx for your answers, Jerome -- [EMAIL PROTECTED]
Re: Question about interpreter == NULL
Juergen Boemmels wrote: Leopold Toetsch [EMAIL PROTECTED] writes: [...] PIO_eprintf PIO_printf for printing to stderr/stdout during 1st interpreter construction destruction if something goes wrong. In all other cases we have an valid interpreter (or an parent interpreter if any). This means all the Parrot_warn(NULL,...) in config/gen/platform/ansi.c are invalid. Ok remove them Not exactly :-) platform/ansi and probably miniparrot using such function should IMHO and probably just PANIC() or throw an exception, which might then do panic. Its very likely a sever error, when unsupported platform functions are called during parrot bootstrap, which is that what I presume miniparrot/ansi.c will finally be doing. leo
Re: [perl #23186] [PATCH] adding yield semantics to IMCC
Kenneth A Graves (via RT) wrote: The .pcc_* directives are working for me in terms of implementing function calls. I want to do something similar for iterator calls. I've decided to implement iterators using coroutines. Seems very well done and clean to me. Albeit further comments of lanugage gurus WRT coroutines iterators might be helpful/welcome. If tha patch gets warnocked, I'll commit. Additionally some tests would be fine: a source code thingy like t/imcpasm/pcc.t[1] (or a separate file) and some running examples with output to be compared. [1] I know that these are a PITA to maintain. A simple change in e.g. the register allocator changes allocated Parrot register numbers and breaks mostly all tests. OTOH its IMHO unavoidable to consolidate a desired output, what code actually is spit out. - At least for now, until all the specs are carved in granite and a functional test giving just a test result will suffice. leo
Re: subroutines and python status
Luke Palmer [EMAIL PROTECTED] wrote: You mind submitting a patch to put this in the languages/pirate I'd appreciate that very much. Pie-thon, here we come ... Luke leo
Re: Q: pdd03 calling conventions
At 10:24 +0200 7/31/03, Leopold Toetsch wrote: While trying to implement pdd03 inside the PIR assembler I'm not too sure if I get everything right from pdd03. Currently I have this: - a subroutine call can be prototyped or non_prototyped - a subroutine definition can be both and un_prototyped. In the latter case it checks CI0 and takes parameters either way. - return values are prototyped only currently Q: Should there be code to check the amount and types of function parameters? Always, or on demand (e.g. with a check_params in the sub def)? Always. It's perfectly legal for a sub that gets arguments it doesn't expect, for example if it gets params in I registers and it takes only PMCs, to throw an exception. Now to return conventions: Q: Is the prototype specifier for return values independent or is it the same as that in the subroutine definition. Or has that to be checked at runtime (I3 has some info about expected return values, but not really, where to place return value(s)) The return prototype is independent of the paramter prototypes. I think this needs a little fleshing out as well, since the subs need to know what the caller is expecting back, which needs passing in. I'd rather not have to have some sort of hacked up inspection scheme to get the various perl want* parameters. Q: And finally, how does the caller get the return value(s), again a runtime check of which prototype specifier is having that info? The same WRT checking applies here. Caller inspects the registers to see what it was handed back. I think, parrot/imcc and any HL calling some (external) subroutines need header files, which have the information about function signatures and return values. Q: Which format (C-like .h files?), in runtime/parrot/include? I think C-like includes are fine. IMCC can emit typechecking code for PMCs if you want, or we can put that off for later. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: subroutines and python status
At 02:54 PM 7/31/2003 -0400, Michal Wallace wrote: Actually, between imcc and the python compiler module, it's not nearly as hard as I thought it would be. So far, I think the parrot version is actually a lot simpler than the python compiler, just because imcc is doing so much of the work. Leo and I (and the rest of us) like to hear comments like this that actually validate the work put into the tools. Although they have a long way to go, its a heck of a lot nicer than this time a year ago. Thanks again, -Melvin
Re: subroutines and python status
At 01:51 PM 7/31/2003 -0600, Luke Palmer wrote: You mind submitting a patch to put this in the languages/pirate directory of the parrot distro? I'd like to stay up to date, and probably do some work (as, I imagine, would others). I'd like to officially complain that pirate is a cooler name than my own cola and I haven't figured out what to do about it yet. :) -Melvin
Re: [imcc] objects speed, .include and file-scoped vars, and various stuff
At 11:02 PM 7/31/2003 +0200, Jerome Quelin wrote: Anyway, whatever the reason, I'm playing with imcc and have some questions about it: I think its officially time to put together a nice set of documentation for IMCC (like web based). I'll try to start, right after I catch up with the year of progress Leo has made since I last touched it. Leo, Dan, prepare for a barrage of offline email. :) -Melvin
Re: [CVS ci] don't trace system areas in sweep opcode
Leopold Toetsch: To clean up on scope exit (and after a Perl Cundef ins), the HL emits a Csweep 0 opcode. This doesn't do Ctrace_system_areas anymore, because there is nothing unanchored and alive beyond the runloop's stack. Have I mentioned lately that you guys are geniuses? --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker
Re: cvs commit: parrot embed.c
Daniel Grunblatt: +PIO_eprintf(interpreter, Parrot VM: Platform JIT_ARCHNAME + is not EXEC-capable.\n); An unprefixed constant like JIT_ARCHNAME should not be available to embedders. If it is, something's wrong. I don't have a copy of the source with me, and I'm writing this offline, so I can't tell you what the correct constant is. --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker
Re: [perl #23135] Build fails under Win32
Vladimir Lipskiy: Is there anybody who could drop a couple of lines on account of this question while Brent is unget-at-able? Not quite un-get-at-able--just unable-to-hack-able. :^) Hey, I use win32 (mingw) and the JIT has always worked fine for me. If this is an issue with MSVC, it should be specific about that To learn from Brent Dax, it's a os specific problem. The JIT may be an MSVC-only thing, but to my knowledge it has *never* worked on Windows/MSVC. However, I can't imagine that exec works on Windows under any platform, because I don't think the .exe format is supported. It may be more appropriate to just disable exec on Win32, and let JIT be decided according to the normal logic. I necer tested Configure with just --execenabled=0. --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker
Re: cvs commit: parrot embed.c
On Thursday 31 July 2003 14:31, Brent Dax wrote: Daniel Grunblatt: +PIO_eprintf(interpreter, Parrot VM: Platform JIT_ARCHNAME + is not EXEC-capable.\n); An unprefixed constant like JIT_ARCHNAME should not be available to embedders. If it is, something's wrong. I don't have a copy of the source with me, and I'm writing this offline, so I can't tell you what the correct constant is. Fixed, thanks. --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker Daniel.
Re: Perl 6's for() signature
Anyone but me feel the need for non-greedy slurpy arrays? similar to
non-greedy RE matches?
Then we could do:
sub for ([EMAIL PROTECTED], block) {...}
Proposed behavior of *?@ : All Arguement to Parameter mapping left of it
are processed Left to Right. Once seen, the mapping starts over right to
left. Everything remaining is slurpable.
With obvious restrictions on no other slurpy/semi-slurpy arrays in the
param list, b/c that would make things go insane, IMHO. Although, I guess
with typing, you could do splits on the typed params between, and assuming
there was no ambiguity ...
Ow, my head hurts now :o
--attriel
Re: Perl 6's for() signature
- Original Message - From: Hanson, Rob [EMAIL PROTECTED] To: 'Rod Adams' [EMAIL PROTECTED]; Perl 6 Language [EMAIL PROTECTED] Sent: Thursday, July 31, 2003 1:29 PM Subject: RE: Perl 6's for() signature Anyone but me feel the need for non-greedy slurpy arrays? similar to non-greedy RE matches? I definately like the idea of having something like that. It probably wouldn't be used much, but it is nice to have the option. One thing though, can't you accomplish the same thing by slurping everything, then poping the block off of the array? Rob Yes, but you lose compile-time type checking on the last parameter. I would prefer to have for 1,2,3; fail at compile-time, not run time;
