Re: Tentative [PATCH]: valclone
This is taken from this week's summary, but I thought this post would fit
best in this thread.
Tentative valclone patch
Luke Palmer has been thinking about value and reference objects. He
wondered if there was any value in a valclone operator alongside
set
and clone which would allow the target PMC to decide whether to use
set or clone semantics. He also offered a patch implementing the
operator if people thought it would be useful. Leo Tötsch wasn't sure
the new operator was necessary.
Klaas-jan Stol noted that he'd encountered problems with
reference/value
confusion when he'd been working on his Lua compiler, but he wondered
if
the problem couldn't be solved by having a general, language
independent
argument PMC class. (I'm not sure I understood what he meant by this
so I'm hoping for an explanation with code fragments).
--
Piers
Piers,
I heard your call :-) Here goes...
Maybe it isn't possible what I'd like, but here's what I was thinking of.
I don't know Perl that well, and to keep things readable for everybody,
let's suppose we have the following routine in some (non-existent) language:
subroutine foo(x, y)
{
// do stuff
}
.sub _foo
.param Argument x
.param Argument y
# do stuff
ret
.end
Now, when foo is called with arguments which are references to things
(objects), then only the reference must be copied into the argument
variables.
However, when the arguments are more 'basic' types like integers or
whatever, some languages may require that these are passed by value! When
these 'basic' types are implemented as PMCs (which is likely in dyn. typed
languages), then the PMC REFERENCE is copied, because that's the default for
PMCs.
to clearify:
P0 = new PerlInt
P1 = new PerlInt
P0 = 123
P1 = P0# now P1 is referencing the PerlInt in P0; changing the object
from P1 will affect the PMC referenced # by P0.
inc P1
print P0# will print 124 !
In Perl, this is the default behaviour (for what I understood): everything
is passed by reference. However there are languages (well, there MAY be) in
which the 'basic' types are passed by value.
In these cases, we'd need a _clone_ instruction. This would result in:
.sub _foo
.local PerlUndef x
.local PerlUndef y
# now using pseude code, for ease of reading:
#Parameter x:
if actual type of x is a 'basic' type, then
x = clone P5# P5 is first argument, see PDD for calling conv.
else
x = P5
#Parameter y:
if actual type of y is a 'basic' type, then
y = clone P6 # don't copy reference, but copy whole of object
else
y = P6# y will reference same object as P6
#do stuff
ret
.end
Obviously, this is not very clean, not to mention fast. So it would be nice
to stuff this run-time check into some PMC.
At this very moment I realize that it's not really a matter of some PMC type
for arguments, but that it's a matter of adding a operation for PMCs:
something like a pass_as_argument operation: the PMC knows what to do:
clone or copy. (now raises the question: is this worth it?)
I know Perl don't has this problem, but there may be languages that do have
this problem (and I can mention at least 1 :-). It would be kinda nice if
Parrot can easily handle this as well, but that's not up to me to decide of
course.
Klaas-Jan
Re: Tentative [PATCH]: valclone
This is taken from this week's summary, but I thought this post would fit
best in this thread.
Tentative valclone patch
Luke Palmer has been thinking about value and reference objects. He
wondered if there was any value in a valclone operator alongside
set
and clone which would allow the target PMC to decide whether to use
set or clone semantics. He also offered a patch implementing the
operator if people thought it would be useful. Leo Tötsch wasn't sure
the new operator was necessary.
Klaas-jan Stol noted that he'd encountered problems with
reference/value
confusion when he'd been working on his Lua compiler, but he wondered
if
the problem couldn't be solved by having a general, language
independent
argument PMC class. (I'm not sure I understood what he meant by this
so I'm hoping for an explanation with code fragments).
--
Piers
Piers,
I heard your call :-) Here goes...
Maybe it isn't possible what I'd like, but here's what I was thinking of.
I don't know Perl that well, and to keep things readable for everybody,
let's suppose we have the following routine in some (non-existent) language:
subroutine foo(x, y)
{
// do stuff
}
.sub _foo
.param Argument x
.param Argument y
# do stuff
ret
.end
Now, when foo is called with arguments which are references to things
(objects), then only the reference must be copied into the argument
variables.
However, when the arguments are more 'basic' types like integers or
whatever, some languages may require that these are passed by value! When
these 'basic' types are implemented as PMCs (which is likely in dyn. typed
languages), then the PMC REFERENCE is copied, because that's the default for
PMCs.
to clearify:
P0 = new PerlInt
P1 = new PerlInt
P0 = 123
P1 = P0# now P1 is referencing the PerlInt in P0; changing the object
from P1 will affect the PMC referenced # by P0.
inc P1
print P0# will print 124 !
In Perl, this is the default behaviour (for what I understood): everything
is passed by reference. However there are languages (well, there MAY be) in
which the 'basic' types are passed by value.
In these cases, we'd need a _clone_ instruction. This would result in:
.sub _foo
.local PerlUndef x
.local PerlUndef y
# now using pseude code, for ease of reading:
#Parameter x:
if actual type of x is a 'basic' type, then
x = clone P5# P5 is first argument, see PDD for calling conv.
else
x = P5
#Parameter y:
if actual type of y is a 'basic' type, then
y = clone P6 # don't copy reference, but copy whole of object
else
y = P6# y will reference same object as P6
#do stuff
ret
.end
Obviously, this is not very clean, not to mention fast. So it would be nice
to stuff this run-time check into some PMC.
At this very moment I realize that it's not really a matter of some PMC type
for arguments, but that it's a matter of adding a operation for PMCs:
something like a pass_as_argument operation: the PMC knows what to do:
clone or copy. (now raises the question: is this worth it?)
I know Perl don't has this problem, but there may be languages that do have
this problem (and I can mention at least 1 :-). It would be kinda nice if
Parrot can easily handle this as well, but that's not up to me to decide of
course.
Klaas-Jan
Re: Exceptions
Benjamin Goldberg [EMAIL PROTECTED] wrote: Should the raise opcode produce resumable exceptions? There is no problem with resuming after an opcode. E.g. when Craise is: invokecc Px # call exception handler and the handler returns by Cinvoke P1 i.e. via the return continuation, execution just resumes. But when an exception is thrown somewhere inside C code, I can't imagine to resume there. leo
Re: [perl #22857] Parrot IO test failures
Leopold Toetsch [EMAIL PROTECTED] writes: Simon Glover [EMAIL PROTECTED] wrote: I'm getting failures in tests 1 2 in t/pmc/io.t; however, both tests seem to run fine if I run them in the debugger. valgrind does indicate, that there are unitialized items in many parts of io_buf.c. Can you tell me more about this. I know some parts code, but I still did not manage to get valgrind running on my mashine. (I don't know, if these tests even should use the bufferd IO layer, but there is for sure something wrong there) At the moment the default is to use the buffered IO. The pushing and popping of IO-Layers did not already made it to io.ops. The arbitrary failures come from uninitialized memory. I try to look into this. 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
[perl #22864] [PATCH] Move ParrotIO to PMCs
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #22864]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22864
Hello,
this is the first step of the IO-system away from the mem_sys_alloc/free
memory-managment system to a full-fledged PMC-based system.
In this patch only the ParrotIO structures are transformed to a
PMC. This is simply done by wrapping the ParrotIO in a PMC_data. For
easier access of the layer-pointer (this is the first thing that is
actually needed if a function is called) is stored in the
cache.struct_val. The rest of the patch is mostly to an update of
parrot to the new prototypes.
The filedescriptor-ops are not deleted in this patch, but use
a hack to always create a new temporary PMC from the filedescriptor.
The standard filedescriptors stdin, stdout and stderr are protected
from closing by the PMC_destroy function by marking them as
PIO_F_SHARED. Don't know if this is a right solution.
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/60093/44531/17a4cc/io7.diff
Index: embed.c
===
RCS file: /cvs/public/parrot/embed.c,v
retrieving revision 1.68
diff -u -r1.68 embed.c
--- embed.c 14 Jun 2003 17:48:31 - 1.68
+++ embed.c 30 Jun 2003 21:42:46 -
@@ -71,7 +71,7 @@
off_t program_size, wanted;
char *program_code;
struct PackFile *pf;
-ParrotIO * io = NULL;
+PMC * io = NULL;
INTVAL is_mapped = 0;
#ifdef HAS_HEADER_SYSSTAT
@@ -84,7 +84,7 @@
if (filename == NULL || strcmp(filename, -) == 0) {
/* read from STDIN */
-io = PIO_STDIN(interpreter);
+io = new_io_pmc(interpreter, PIO_STDIN(interpreter));
/* read 1k at a time */
program_size = 0;
}
Index: io.ops
===
RCS file: /cvs/public/parrot/io.ops,v
retrieving revision 1.23
diff -u -r1.23 io.ops
--- io.ops 30 Jun 2003 07:47:32 - 1.23
+++ io.ops 30 Jun 2003 21:42:46 -
@@ -36,7 +36,7 @@
=cut
inline op close(in PMC) {
- PIO_close(interpreter, (ParrotIO*)(PMC_data($1)));
+ PIO_close(interpreter, $1);
goto NEXT();
}
@@ -58,20 +58,15 @@
ParrotIO *io;
mode = string_to_cstring(interpreter, $3);
- io = PIO_fdopen(interpreter, $2, mode);
+ $1 = PIO_fdopen(interpreter, $2, mode);
+ if (!$1) {
+$1 = pmc_new(interpreter, enum_class_PerlUndef);
+ }
/* string_cstring_free(mode); */
/* TODO all results from sring_to_cstring() need freeing
but this generates ugly warnings WRT discarding the const
qualifier -lt
*/
- if (io) {
-$1 = pmc_new_noinit(interpreter, enum_class_ParrotIO);
-VTABLE_init(interpreter, $1);
-PMC_data($1) = io;
- }
- else {
-$1 = pmc_new(interpreter, enum_class_PerlUndef);
- }
#else
$1 = pmc_new(interpreter, enum_class_PerlUndef);
#endif
@@ -88,22 +83,16 @@
=cut
inline op open(out PMC, in STR, in STR) {
- ParrotIO * io;
/* These char * need to go away soon */
const char * path, * mode;
path = string_to_cstring(interpreter, $2);
mode = string_to_cstring(interpreter, $3);
- io = PIO_open(interpreter, path, mode);
+ $1 = PIO_open(interpreter, path, mode);
/* string_cstring_free(mode); */
/* string_cstring_free(path); */
- if(io) {
-$1 = pmc_new_noinit(interpreter, enum_class_ParrotIO);
-VTABLE_init(interpreter, $1);
-PMC_data($1) = io;
- }
- else {
+ if(!$1) {
$1 = pmc_new(interpreter, enum_class_PerlUndef);
}
goto NEXT();
@@ -123,7 +112,7 @@
op open(out INT, in STR) {
char *path = string_to_cstring(interpreter, $2);
- ParrotIO *io = PIO_open(interpreter, path, +);
+ PMC *io = PIO_open(interpreter, path, +);
/* string_cstring_free(path); */
if (io) {
$1 = PIO_getfd(interpreter, io);
@@ -137,7 +126,7 @@
op open(out INT, in STR, in STR) {
char *path = string_to_cstring(interpreter, $2);
char *mode = string_to_cstring(interpreter, $3);
- ParrotIO *io = PIO_open(interpreter, path, mode);
+ PMC *io = PIO_open(interpreter, path, mode);
/* string_cstring_free(mode); */
/* string_cstring_free(path); */
if (io) {
@@ -151,7 +140,7 @@
-=item Bclose(out INT)
+=item Bclose(inout INT)
Close file opened on file descriptor $1.
@@ -165,7 +154,7 @@
table = ((ParrotIOData*)interpreter-piodata)-table;
io = table[$1];
table[$1] = NULL;
-PIO_close(interpreter, io);
+PIO_close(interpreter, new_io_pmc(interpreter, io));
}
goto NEXT();
}
@@ -208,16 +197,18 @@
op print(in STR) {
STRING *s = $1;
if (s string_length(s)) {
-PIO_putps(interpreter, PIO_STDOUT(interpreter), s);
+PIO_putps(interpreter, new_io_pmc(interpreter, PIO_STDOUT(interpreter)),
+ s);
}
goto NEXT();
}
op print(in PMC) {
PMC *p = $1;
-
Re: [perl #22855] [PATCH] build imcc as parrot
On Tue, 1 Jul 2003, Leopold Toetsch wrote: Andy Dougherty [EMAIL PROTECTED] wrote: On Mon, 30 Jun 2003, Leopold Toetsch wrote: Attached is a minimum patch to build imcc as the parrot executable languages/imcc/*.o languages/imcc/*.o doesn't match anything Brain dead make? No. Here's the same result with GNU make: gmake: *** No rule to make target `languages/imcc/*.o', needed by `languages/imcc/imcc'. Stop. The problem is that with a clean build tree, there are no *.o files down in languages/imcc/ at the point when that target is reached. Hence make doesn't have anything to expand *.o as, and quite reasonably complains. If, however, there is even a single .o file in that directory, then the wildcard is expanded as you'd expect and the make proceeds. Anyway, this line could for sure be deleted. That's probably sufficient for now. Alternatively, you could simply always force the descent into languages/imcc. I can imagine scenarios where the *.o files were updated but the *.c files weren't (e.g. re-compiling imcc/*.c with different options) and the root Makefile would miss that dependency, but such scenarios are certainly outside the normal run of things. Apart from that, it built fine and passed all tests with Sun's cc and perl5.00503 on Solaris 8. Fine. Thanks for your feedback. You're welcome. And thanks for moving us past the perl assembler! -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #22855] [PATCH] build imcc as parrot
On Tue, Jul 01, 2003 at 10:04:41AM -0400, Andy Dougherty wrote: The problem is that with a clean build tree, there are no *.o files down in languages/imcc/ at the point when that target is reached. Hence make doesn't have anything to expand *.o as, and quite reasonably complains. If, however, there is even a single .o file in that directory, then the wildcard is expanded as you'd expect and the make proceeds. Is it possible to get a Bourne shell (here invoked as subshell) to expand the wildcard to if nothing matches? If so, that would solve the problem, wouldn't it? Nicholas Clark
Re: This week's summary
At 1:18 AM +0100 7/1/03, Alan Burlison wrote: Rafael Garcia-Suarez wrote: Hmm, I'm only a lurker, but that looks *very* suspect to me. Some compilers may choose to reorder even without optimization turned on. I'd say that it is a bug in Parrot if it requires optimization to be off for this code - how many different compilers have you tried? That doesn't make this per-C-file-cc-option-tweaking necessarily unuseful. Perl 5 uses something similar, because the lexer is sometimes miscompiled when some compilers with a high optimization level. Example : see the hints files and lookup XXX_cflags or toke_cflags in hints/README.hints. I'm not saying it isn't useful - per compiler workarounds for brokenness is one thing, but the implication was that this tweakage was needed for *all* compilers for those particular files, which spells 'broken' in my book. If the code makes assumptions about execution order without using the necessary mutexes/cvs to enforce these assumptions, it is very unlikely to work on large SMP machines, for example. Unfortunately given what the code does we can't use mutexes, since they're not interrupt-safe, which I'm not particularly happy about. The queues in question are thread-specific, though, which takes some of the danger out of things. I fully expect to have to do more work than just disabling optimizations to disable reordering to make this function right everywhere. (I know, I know, platform-independent interrupt code is just not doable, but...) Personally, I'd much prefer to use platform-provided interrupt-safe queueing mechanisms, and we will in those places where it's available. I know it *is* available on VMS, and *isn't* available on OS X and Linux. I'm also very painfully aware of some of the issues that need to be dealt with for processors with internal read and write reordering, which isn't anywhere near fun to deal with. (Well, OK, it is, but I'm weird that way) What I'd really like is a nice, portable, insqti/remqhi implementation, but barring that (since I'm not going to get it) something as close as possible. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #22855] [PATCH] build imcc as parrot
Andy Dougherty [EMAIL PROTECTED] wrote: The problem is that with a clean build tree, there are no *.o files down in languages/imcc/ at the point when that target is reached. Hence make doesn't have anything to expand *.o as, and quite reasonably complains. If, however, there is even a single .o file in that directory, then the wildcard is expanded as you'd expect and the make proceeds. If you want a version of make where non-extisting files will still match the wildcards (because the wildard engine looks at Make's DAG), you might want to look at makepp (http://makepp.sourceforge.net). Its written in Perl, so should be portable to everywhere parrot needs to build. Its blurb makes it look pretty good, though I've not yet used it in a real project. Dave.
Re: [perl #22864] [PATCH] Move ParrotIO to PMCs
? include/parrot/platform_interface.h Index: embed.c === RCS file: /cvs/public/parrot/embed.c,v retrieving revision 1.69 diff -u -r1.69 embed.c --- embed.c 1 Jul 2003 15:41:00 - 1.69 +++ embed.c 1 Jul 2003 17:59:34 - @@ -220,9 +220,8 @@ #else /* HAS_HEADER_SYSMMAN */ -PIO_fprintf(interpreter, PIO_STDERR(interpreter), -Parrot VM: uncaught error occurred reading file -or mmap not available.\n); +PIO_eprintf(interpreter, Parrot VM: uncaught error occurred reading +file or mmap not available.\n); return NULL; #endif /* HAS_HEADER_SYSMMAN */ Index: trace.c === RCS file: /cvs/public/parrot/trace.c,v retrieving revision 1.34 diff -u -r1.34 trace.c --- trace.c 14 Jun 2003 17:48:31 - 1.34 +++ trace.c 1 Jul 2003 17:59:34 - @@ -246,7 +246,7 @@ } /* Flush *stderr* now that we've output the trace info */ -PIO_flush(interpreter, PIO_STDERR(interpreter)); +PIO_flush(interpreter, new_io_pmc(interpreter, PIO_STDERR(interpreter))); } -- 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: [perl #22864] [PATCH] Move ParrotIO to PMCs
At 8:06 PM +0200 7/1/03, Juergen Boemmels wrote: Dan Sugalski [EMAIL PROTECTED] writes: This dies on 9 tests on OS X, and I think from the complaints that valgrind will also be very unhappy, but I'm putting it in so it can be thumped by other folks as well as me. The tinderboxens are very unhappy right now. I missed two points in porting from ParrotIO * to PMC *, but this triggers only a warning in untested code, so I missed them. Attached patch should fix them. In, though the tests still bomb out for me. (Lots of freeing of un-malloc'd memory warnings) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl6 Daydreams (on topic but frivolous)
* Jonadab the Unsightly One ([EMAIL PROTECTED]) [01 Jul 2003 23:41]: Iain Truskett [EMAIL PROTECTED] writes: Not the only one. And with Parrot being able to execute Z-code, it might be sane to port Inform to Parrot! Did you mean port Inform to run on Parrot, or port Inform to compile to parrot? The former. I was thinking more of Parrot being a portable interactive fiction platform for reading and creating games. cheers, -- Iain.
Re: [ANNOUNCE] Test::Warn::None 0.02
On Monday, June 30, 2003, at 02:07 pm, Fergal Daly wrote: On Wednesday 25 June 2003 20:15, Adrian Howard wrote: Add an explicit test script finished footer? But how does the footer-adder know that the correct number of tests ran. You would need to declare a plan to run x additional extensions at which point you're doing sub-plans. The footer doesn't indicates that the correct number of tests ran (that's the plan's job), it just shows that a test script completed without error. So a noplan test might look like ok 1 ok 2 1..2 # fin a planned test with an extension might look like 1..2 ok 1 ok 2 3..3 ok 3 # fin and a test with a failed extension might look like 1..2 ok 1 ok 2 # some ghastly error that caused an early exit and no error code on exit and Test::Harness would pick up the lack of a # fin as indicating a premature exit. Most early exits would be caught via the bogus exit value anyway. Having an explicit script complete footer would only catch a few odd cases. Of course if we carry on much longer we're going to end up with T::H and T::B having to do nasty version checks to make sure they're talking the same protocol :-) I suppose I'm thinking of things from the I messed up my test script point of view rather than my test script died unexpectedly. Exit codes should catch the died unexpectedly stuff. A correct plan is good for catching the programmer errors but is a pain to maintain. To be honest, I'm not sure that having a global plan at the test script level gives you that much benefit. I like planned tests, but a manually maintained global plan is a maintainence nightmare if you have a large number of tests, or if the number of tests is runtime dependant. I've not noticed any problems now that I use Test::Class for most of my test code. I still plan the number of tests executed - I just do it at the method-level rather than the test-script level. That's why I liked the previous suggestions about being able to extend plans. It seemed a nice simple way to get the security of being able to have micro-plans without having to worry about the global plan count. (not that we couldn't do it your way too). I have some vague thoughts that there are some potentially cute things that you could do with extended plans that would be hard to do with sub-blocks/plans (e.g. any sort of test that cross-cuts several test scripts in an AOPish sort of way - checking that test data has returned to a state of grace for example). I guess that can be solved by controlling the timing of the output. I don't think there's a need for the results of test 1 to be printed before carrying out test 2, except maybe when the tests are being run by the developer. That would work, but you face the problem of having an evil internal-error causing your script to exit early without getting any output from earlier tests. You also lose user feedback for long test sequences (you only find out that test 2 failed after all 276000 test run). Being able to extend the plan seems a simpler solution to me. Adrian
Re: [perl #22864] [PATCH] Move ParrotIO to PMCs
On Tue, 1 Jul 2003, Dan Sugalski wrote: This dies on 9 tests on OS X, and I think from the complaints that valgrind will also be very unhappy, but I'm putting it in so it can be thumped by other folks as well as me. I think I might have figured out why valgrind's unhappy. We're currently marking the ParrotIO PMC as needing active destruction, so as to ensure that PIO_close gets called when the PMC gets garbage collected. However, as far as I can see there's nothing to stop this from happening even after we've called PIO_close explicitly ourselves, so we can end up trying to free the same io structure twice. Does this make sense? Simon
[perl #22867] Popbottom ops
# New Ticket Created by Simon Glover # Please include the string: [perl #22867] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22867 Based on the documentation in core.ops, I would expect this code: set S15, a\n set S16, b\n pushs set S15, c\n set S16, d\n popbottoms print S15 print S16 end to print: a d In fact, it prints: d Similarly, this code: set I15, 1 set I16, 2 pushi set I15, 3 set I16, 4 popbottomi print I15 print I16 end prints: 04 when I would have expected: 14 Simon
