Re: [perl #22343] pdb + internal_exception = segfault
On Wed, 21 Sep 2005, Joshua Hoblitt via RT wrote: [EMAIL PROTECTED] - Tue May 27 19:30:39 2003]: Currently, if you're in the debugger, and do anything that causes an internal_exception call within the interpreter, you get a segfault. [Backtrace snipped] ...etc I think what's happening is that we're trying to destroy the interpreter that pdb itself is using, which will clearly cause bad things to happen. Does this bug still exist? I've just tried this out with the current snapshot, and you no longer get a segfault. However, I'd still argue that the interaction between pdb and Parrot's exception code remains buggy, as hitting an internal exception call kills not only the currently executing code but also kills the whole pdb session. It would be more useful if it just dropped you back to the main pdb prompt. Whether this is worth fixing depends on the perceived usefulness of pdb, and so isn't my call -- I certainly have no time to work on it for the forseeable future. Regards, Simon
Re: [perl #24381] Parrot doesn't build with PIO_OS_STDIO defined
On Wed, 21 Sep 2005, Joshua Hoblitt via RT wrote:
[EMAIL PROTECTED] - Fri Oct 31 12:58:45 2003]:
An attempt to build Parrot with PIO_OS_STDIO defined (as is the case
when you're trying to build miniparrot) dies in core_ops.c with the error
message:
ops/io.ops: In function `Parrot_sockaddr_s_i_s':
ops/io.ops:497: parse error before `;'
[etc...]
The reason is the interaction between the sockaddr op definition:
op sockaddr(out STR, in INT, in STR) {
$1 = PIO_sockaddr_in(interpreter, (unsigned short)$2, $3);
goto NEXT();
}
and this ifdef in io.h:
#ifdef PIO_OS_STDIO
extern INTVAL PIO_stdio_isatty(PIOHANDLE fd);
extern INTVAL PIO_stdio_getblksize(PIOHANDLE fd);
# define PIO_isatty(x) PIO_stdio_isatty(x)
# define PIO_sockaddr_in(i,p,a)
# define PIO_getblksize(x) PIO_stdio_getblksize(x)
#endif
The preprocessor turns the op definition into:
op sockaddr(out STR, in INT, in STR) {
$1 = ;
goto NEXT();
}
which is clearly a syntax error.
An easy fix is to wrap the offending line in #ifndef PIO_OS_STDIO ..
#endif, but there may be a better solution.
This bug still exists, in a slightly modified form. If PIO_OS_STDIO is
defined, then the build fails as described above. For PIO_OS_STDIO to
be defined, then either MINIPARROT must be defined, or
PARROT_HAS_HEADER_UNISTD must be undefined, since PIO_OS_STDIO is set by
the following bit of io.h:
#ifdef MINIPARROT
# define PIO_OS_STDIO
#else
# ifdef _WIN32
#define PIO_OS_WIN32
# else
#ifdef PARROT_HAS_HEADER_UNISTD
# define PIO_OS_UNIX
#else
# define PIO_OS_STDIO
#endif
# endif
#endif
However, it seems like MINIPARROT isn't actually #defined by anything any
longer; in particular, running Configure with the --miniparrot option no
longer adds -DMINIPARROT to the CFLAGS line. Therefore, it doesn't seem
possible to hit this problem unless we build on a system without
unistd.h, or unless we trigger it deliberately (as I did while checking
that the problem still existed).
Simon
Re: perlscalar morph code
On Tue, 12 Apr 2005, Nicholas Clark wrote: I think that there are 2 bugs here 1: Morphing from enum_class_PerlString to enum_class_BigInt or enum_class_Complex looks broken. The return in the second if clause will quit the function and the DYNSELF.init() will never get called. Can anyone easily write a regression test that demonstrates this This code: new P0, .PerlString new P1, .BigInt typeof I1, P1 morph P0, I1 set P0, 123 print P0 end segfaults for me with the latest snapshot of parrot, but prints '123' as expected if you remove the two lines mentioned below. The analogous test with Complex instead of BigInt appears to work regardless of whether the lines are present or not. I think that the cure is to remove SELF-vtable = Parrot_base_vtables[type]; return; I've also re-run the test suite with these lines removed, and all existing tests still pass. Hope this is useful, Simon
Re: Summary for the week ending 2005-04-12
On Tue, 12 Apr 2005, The Perl 6 Summarizer wrote: Dynamic Perl, Part 1 William Coleda announced that he was starting work on removing the core's dependence on Perl* PMCs in favour of using language agnostic PMCs internally and loading the Perl ones dynamically as required. Everything but PerlArray was dealt with quickly and names and ways forward with that tricky case were discussed. It looks like we're going to have a 'ResizablePMCArray' added to the core once people have the tuits. Minor correction: 'ResizablePMCArray' is already in the core, but some of the necessary vtable methods still need to be implemented (and tested!). Simon
Re: [perl #33747]
On Mon, 10 Jan 2005, Matt Diephouse wrote:
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #33747]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=33747
I'm not sure what this should print, but I'm pretty sure the right
answer isn't 8.
.sub main @MAIN
$S0 =
$S1 = substr $S0, -1, 1
print $S1
print \n
end
.end
If you s/-1, 1/-1/, it doesn't print the 8.
Well, you're trying to take a non-zero length substring from out of a
zero-length string, so I would contend that Parrot ought to throw an
exception. The reason that it doesn't is that this code in
string_substr() in string.c does not act as intended for a zero-length
string:
...
true_offset = (UINTVAL)offset;
/* Allow regexes to return $' easily for aaa =~ /aaa/ */
if (offset == (INTVAL)string_length(interpreter, src) || length 1) {
return string_make_empty(interpreter, enum_stringrep_one, 0);
}
if (offset 0) {
true_offset = (UINTVAL)(src-strlen + offset);
}
if (true_offset src-strlen - 1) {/* 0 based... */
internal_exception(SUBSTR_OUT_OF_STRING,
Cannot take substr outside string);
}
...
As best I can tell, the intent of the code is this:
1) If you ask for a substring (of arbitrary length) starting at one
character position past the end of the string, then return an
empty string.
2) If you ask for a zero-length substring, then return an empty string,
regardless of the supplied offset
3) If the supplied offset is before the start or after the end of the
string, then throw an exception.
4) Otherwise, continue.
The problem here is with step three, and in particular the comparison
between true_offset and src-strlen - 1. This does not work as intended
for a zero-length string, because src-strlen is an _unsigned_ int, and
so if src-strlen = 0, then src-strlen - 1 is very very large. The
patch below fixes this bug while otherwise keeping the behaviour the
same, but I'm posting it to the list rather than simply applying it
because it is not clear to me that the behaviour described above is
precisely what we want. Specifically, should this code:
set S0,
substr S2, S0, 0, 1
throw an exception or not? At the moment, it does not (even with my
patch), because the offset == the string length. On the other hand,
this code:
set S0,
substr S2, S0, -1, 1
will throw an exception. Is this behaviour correct?
Incidentally, the reason that:
set S0,
substr S2, S0, -1
works is that the code passes in the length of S0 as the length
parameter, and since this is zero, string_substr returns an empty
string, without any reference to the offset parameter.
Simon
PS I've also included a patch to t/op/string.t that adds tests which
feed zero length strings to the various forms of the substr op. The
tests assume that the behaviour described above is correct.
--
Index: src/string.c
===
RCS file: /cvs/public/parrot/src/string.c,v
retrieving revision 1.229
diff -u -r1.229 string.c
--- src/string.c3 Nov 2004 21:44:39 - 1.229
+++ src/string.c10 Jan 2005 19:05:09 -
@@ -1421,7 +1421,7 @@
true_offset = (UINTVAL)(src-strlen + offset);
}
-if (true_offset src-strlen - 1) {/* 0 based... */
+if (src-strlen == 0 || true_offset src-strlen - 1) { /* 0 based... */
internal_exception(SUBSTR_OUT_OF_STRING,
Cannot take substr outside string);
}
Index: t/op/string.t
===
RCS file: /cvs/public/parrot/t/op/string.t,v
retrieving revision 1.79
diff -u -r1.79 string.t
--- t/op/string.t 2 Jan 2005 11:34:55 - 1.79
+++ t/op/string.t 10 Jan 2005 19:06:18 -
@@ -16,7 +16,7 @@
=cut
-use Parrot::Test tests = 135;
+use Parrot::Test tests = 144;
use Test::More;
output_is( 'CODE', OUTPUT, set_s_s|sc );
@@ -512,6 +512,127 @@
end
CODE
+output_like( 'CODE', 'OUTPUT', substr, +ve offset, zero-length string );
+ set S0,
+ substr S1, S0, 10, 3
+ print S1
+ end
+CODE
+/Cannot take substr outside string/
+OUTPUT
+
+output_is( 'CODE', 'OUTPUT', substr, offset 0, zero-length string );
+ set S0,
+ substr S1, S0, 0, 1
+ print S1
+ print _\n
+ end
+CODE
+_
+OUTPUT
+
+output_like( 'CODE', 'OUTPUT', substr, offset -1, zero-length string );
+ set S0,
+ substr S1, S0, -1, 1
+ print S1
+ end
+CODE
+/Cannot take substr outside string/
+OUTPUT
+
+output_like( 'CODE', 'OUTPUT', substr, -ve offset, zero-length string );
+ set S0,
+ substr S1, S0, -10, 5
+ print S1
+ end
+CODE
+/Cannot take substr outside string/
+OUTPUT
+
+output_is( 'CODE', 'OUTPUT', zero-length substr,
Key question
Or rather, a question about keys: what should the following two code
snippets do?
1) new P0, .Key
set P0, 1
set N0, P0
print N0
end
2) new P0, .Key
set P0, 1
set I0, P0
print I0
end
At the moment, the first one throws an exception ('Key not a number!'),
while the second one goes into an infinite loop and eventually
segfaults. As I see it, there are three possibilities:
i) In both cases, we throw an exception.
ii) We try to convert the string to an float (or int) using
string_to_num (or string_to_int). [In which case, what
do we do if the string is something like asdf?]
iii) We declare that trying to get numeric information out of
non-numeric keys is undefined behaviour, and so Parrot may do
anything (including segfault).
Which of these should Parrot do?
Simon
Resizable array questions
1) When we resize a Resizable*Array (where * = Integer, Float or String) by calling set_integer_native, we also set the PMC's active_destroy flag. However, we don't do this when resizing a ResizablePMCArray (which also has a different memory allocation strategy). Is this because we don't strictly need to, or is this just an oversight? 2) Why does the ResizablePMCArray PMC use a different memory allocation strategy, i.e. what advantage does it have over the strategy used by the other Resizable arrays? Simon
Fetching uninitialzed values from arrays
Does Parrot make any guarantee about the value of an uninitialzed array element, or should I expect the value returned by: new P0, .FixedBooleanArray set P0, 1 set I0, P0[0] to be garbage? (Just to be clear - I think it's fine if it is garbage, but I couldn't find an explicit statement of policy in the docs). Simon
Re: [perl #33603] Undef != Undef
On Fri, 31 Dec 2004, Leopold Toetsch wrote:
Simon Glover [EMAIL PROTECTED] wrote:
new P0, .ResizablePMCArray
set P0, 1
clone P1, P0
eq P0, P1, L1
print not
L1: print ok
print \n
end
prints not ok.
This is a different issue. The ResizablePMCArray doesn't properly
inherit the is_equal multi method from FixedPMCArray and as far as I can
see, there is no Undef involved at all. Empty array slots are filled
with PMCNULL, which is a singleton. The example works for FixedPMCArray.
In the case of the ResizablePMCArray, the Undef comes into it because
of this loop in is_equal():
for (j = 0; j n; ++j) {
PMC *item1, *item2;
item1 = DYNSELF.get_pmc_keyed_int(j);
item2 = VTABLE_get_pmc_keyed_int(INTERP, value, j);
if (item1 == item2)
continue;
if (!mmd_dispatch_i_pp(INTERP, item1, item2, MMD_EQ))
return 0;
}
and this code in get_pmc_keyed_int:
data = PMC_data(SELF);
if (data[key] == PMCNULL)
data[key] = pmc_new(INTERP, enum_class_Undef);
return data[key];
When is_equal calls get_pmc_keyed_int to do the comparison, it creates
and returns an Undef PMC, rather than simply returing PMCNULL, and
since Undef != Undef, this ultimately causes the comparison to fail.
In the case of FixedPMCArray, the test passes because the
implementation of get_pmc_keyed_int doesn't have the test for PMCNULL
-- instead, it just does:
data = (PMC **)PMC_data(SELF);
return data[key];
Hence, if the entry is PMCNULL, the code actually returns PMCNULL,
and since PMCNULL == PMCNULL, the comparison succeeds and the test
passes.
I guess the real question is should we be creating that Undef PMC;
i.e. should fetching an undefined element return a fully-fledged
Undef value, or simply a PMCNULL, which may later be promoted to a
real Undef?
Simon
[PATCH] Stomp a warning in pybuiltin.pmc
The attached patch fixes this warning in pybuiltin.pmc:
pybuiltin.pmc: In function `make_type':
pybuiltin.pmc:76: warning: declaration of `nameprop' shadows previous local
Simon
--- dynclasses/pybuiltin.pmc.oldTue Dec 21 15:30:01 2004
+++ dynclasses/pybuiltin.pmcTue Dec 21 15:32:25 2004
@@ -73,7 +73,7 @@ static PMC* make_type(Interp* interprete
item = VTABLE_get_pmc_keyed_str(interpreter, stash, key);
if (item-vtable-base_type == enum_class_NCI) {
-PMC *nameprop = pmc_new(interpreter, dynclass_PyString);
+nameprop = pmc_new(interpreter, dynclass_PyString);
VTABLE_set_string_native(interpreter, nameprop, key);
VTABLE_setprop(interpreter, item, NAME, nameprop);
item-vtable = Parrot_base_vtables[dynclass_PyNCI];
Re: Numeric semantics for base pmcs
On Tue, 24 Aug 2004, Dan Sugalski wrote: 6) Division of two ints produces a bignum Surely it should only produce a bignum as a last resort. For instance, shouldn't: 4 / 3 produce a float? Also, what about a case like: 4 / 2 Does that produce an int, a float or a bignum? 9) Any operation with a bignum produces a bignum Should there be some way to test whether a bignum can be downgraded into a float? Simon
Re: (De-Lurk)
On Tue, 3 Aug 2004, Andrew Rodland wrote: On a related note, is there a tasks grab-bag list anywhere, some stuff that isn't core work, but It Would Be Nice If, and someone like me could give a shot? Well, there's the TODO list, although that's somewhat short on details. Another good way to learn more about the internals is writing tests -- if you're using gcc, then you can build a copy of parrot with -fprofile-arcs -ftest-coverage, run the test suite, and then use gcov to let you know which bits of the code aren't currently being tested. Then all you have to do is to figure out how to test those bits (which ranges from really easy to really hard, depening on the code in question). Simon
RE: This week's summary
On Thu, 29 Jul 2004, Butler, Gerald wrote: sarcasm Of course American and Right are synonymous! Just ask OUR WONDERFUL GOD (I mean President) GEORGE W. BUSH. He'll tell ya' /sarcasm OK, gentlemen, this is both way off topic and starting to head into flame war territory, so I suggest that we either quietly drop it, or move it elsewhere. Simon PS Gerald, this isn't aimed at you specifically -- yours just happens to be the most recent message in the thread.
Re: Event design sketch
One quick point: unless I'm misunderstanding something, there seems to be no easy way to wait on multiple events to complete if those events can occur in any order. For instance, suppose we have 5 events, P1 - P5 If we know that the events will occur in some specified order (say 1-2-3-4-5), then we can just loop over Cwait Px, specifying the apporpriate x for each iteration. However, if the events actually occur in the order 4-3-2-5-1, we'll drop events 2-5 while waiting for 1. Now, this is fine if 1 _must_ happen before 2 etc., but often this is more restrictive than we need to be, since all we really care about is ensuring that all 5 events are handled before we do anything else. Is there any easy and efficient way to do this with the current framework? Simon
Re: writing PMCs (documentation)
On Fri, 7 May 2004, Nicholas Clark wrote: I'm trying to find documentation on how to write PMCs. I can find lots of PMCs in the source tree, but I can't seem to find documentation on how to go about writing them, or what the various fields and flags do. For example, the string PMC_data occurs in many source files, but as far as I can tell nowhere in any documentation files, and there aren't many comments about it in include/parrot/pobj.h I don't find any documentation saying if you do this you'll need to do that in a destructor else you'll leak. Am I missing something obvious? No. The closest we have to something like this is probably the stuff written by Mike Scott for the Wiki: http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ParrotDiagramsPMC (Well, that plus the comments in pobj.h, which are somewhat opaque.) If no-one else volunteers, I'll try to put together something like this, as we do need it, but I'm unlikely to have sufficient tuits until the end of May :-( Simon
Re: writing PMCs (documentation)
On Fri, 7 May 2004, Simon Glover wrote: On Fri, 7 May 2004, Nicholas Clark wrote: I'm trying to find documentation on how to write PMCs. I can find lots of PMCs in the source tree, but I can't seem to find documentation on how to go about writing them, or what the various fields and flags do. For example, the string PMC_data occurs in many source files, but as far as I can tell nowhere in any documentation files, and there aren't many comments about it in include/parrot/pobj.h I don't find any documentation saying if you do this you'll need to do that in a destructor else you'll leak. Am I missing something obvious? No. The closest we have to something like this is probably the stuff written by Mike Scott for the Wiki: http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ParrotDiagramsPMC (Well, that plus the comments in pobj.h, which are somewhat opaque.) If no-one else volunteers, I'll try to put together something like this, as we do need it, but I'm unlikely to have sufficient tuits until the end of May :-( Sorry to follow-up to myself, but I've thought of a few other things that are probably worth loooking at. First, PDD04 (datatypes) has some info on PMC internals, although this is incomplete, and possibly out of date... Second, when you come to implement the various vtable methods, you should probably look at PDD02, which is the closest thing to a comprehensive overview that we have, although I don't think it includes anything about the recent MMD-related changes that Dan has announced. Simon
Re: hyper op - proof of concept
On Wed, 21 Apr 2004, Leopold Toetsch wrote: PMC-only means, that you'll always have to call e.g. get_integer on the PMC, because the PMC might be tied. This limitation isn't really good for performance reasons. People might use it most likely in combination with natural typed arrays. Absolutely -- I really, _really_ want to be able to use hyper ops with fixed size, floating point arrays, and to have that be as fast as possible, as that should make it possible to implement something like PDL in the core. Simon
Re: hyper op - proof of concept
On Wed, 21 Apr 2004, Aaron Sherman wrote:
On Wed, 2004-04-21 at 10:13, Simon Glover wrote:
Absolutely -- I really, _really_ want to be able to use hyper ops with
fixed size, floating point arrays, and to have that be as fast as
possible, as that should make it possible to implement something like
PDL in the core.
Mistake.
You don't want to have to convert to-and-from arrays of PMCs in order to
do those ops, and regardless of what kind of hyper-nifty-mumbo-jumbo you
put into Parrot, that's exactly what you're going to have to do.
Why? I was under the impression that in Perl 6 it was going to be
possible to declare arrays that only contain values of a particular
type -- I believe the syntax I saw was:
my @array is float;
although I've not been following p6l, so this may have changed somewhat.
Are you saying that despite that, those values still have to be PMCs?
If so, then you're quite right -- I would make no sense to convert them
to floats and then back again -- but this also means that core Perl 6
is not going to be nearly as useful to me as I had hoped.
In fact, Parrot Data Language (if there were such a thing) would likely
introduce its own runtime-loadable opcode set to operate on a new PMC
type called a piddle. Then, each client language could define (in a
module/library) its own means of interacting with a piddle. For example
in Perl, you might:
multi method new(Class $class, int @ary) {...}
multi method new(Class $class, float @ary) {...}
multi method new(Class $class, int $value) {...}
multi method new(Class $class, Octets $value: %*_) {...}
and then you would override BUILD in order to emit your special piddle
opcodes.
Then, in user-space:
my PDL::Piddle $foo = [1,2,3,4,5,6];
Does what you expect, and
$foo + $bar
is special.
This is all very well, but it places a much larger hurdle in the way of
someone wanting to use Perl 6 for these kinds of computationally
intensive array manipulations, particularly if our hypothetical Perl 6
version of PDL isn't a core module.
Simon
Re: [CVS ci] new FloatvalArray PMC type
On Wed, 21 Apr 2004, Leopold Toetsch wrote: The subject has it all. It's even tested a bit ;) Since we've already got PMCArray and StringArray, shouldn't we call this FloatArray rather than FloatvalArray? (Or alternatively, we could rename the first two to PMCvalArray StringvalArray). Simon
Stack opcode names
We currently have save and restore ops that work with the user stack, and saveall and restoreall that work with the register stacks, and which are equivalent to: pushi pushn pushs pushp and popi popn pops popp respectively. Wouldn't a better name for the latter be pushall and popall, to avoid any confusion with save and restore, or is this not worth bothering about? Simon
RE: GCC for PARROT (GCC Compiling itself to PARROT, then compilin g all supported languages to PARROT from PARROT)?!?!
On Mon, 22 Mar 2004, Butler, Gerald wrote: The important point is that the starting language must have semantics which treat variables, object, etc. as abstract entities to be manipulated not *memory locations* to be accessed arbitrarily. Then, the parse stage must spit This requirement probably means that Fortran is a non-starter, as a number of its features (equivalence, common blocks) do rely on a specific layout of variables in memory. Simon
Re: [perl #27690] Numeric comparison bug
On Wed, 17 Mar 2004, Leopold Toetsch wrote: Simon Glover [EMAIL PROTECTED] wrote: This code: new P0, .PerlNum set P0, -1.2 new P1, .PerlString set P1, -1.2 eq_num P0, P1, OK print not OK: print ok\n end [And yes, I'm well aware of the problems inherent in doing floating point comparisons. Breakpoint 1, Parrot_PerlNum_cmp_num (interpreter=0x82654f0, pmc=0x40305850, value=0x40305838) at perlnum.c:301 301 diff = PMC_num_val(pmc) - VTABLE_get_number(interpreter, value); (gdb) n 302 return diff 0 ? 1 : diff 0 ? -1 : 0; (gdb) p diff $1 = 2.2204460492503131e-16 (gdb) OK, that suggests that there's a bug somewhere in our string-number conversion. Either that, or we're going to have to live with the fact that 1.2 and '1.2' are not the same number (which would suck). Simon
Re: [BUG] src/hash.c:256: promote_hash_key: Assertion `key' failed.
On Thu, 11 Mar 2004, Jens Rieks wrote: $ tar xzf err2.tgz $ cd err2 $ ../parrot t/pmc/dumper_1.imc parrot: src/hash.c:256: promote_hash_key: Assertion `key' failed. aborted It is caused by 'callmethod dumper' (err2/library/dumper.imc:82) Ah, I stumbled over this yesterday. The problem is that the callmethod STRING op hasn't been implemented yet, as noted in PDD15 (but not, I now see, in the inline documentation). Quite why you get such an uninformative error message I'm not sure. NB. The same holds true for callmethodcc STRING and both forms of the tailcallmethod ops. Simon
Re: Alternate function calling scheme
On Tue, 9 Mar 2004, Leopold Toetsch wrote: Object instantiation is 40 % of the whole used time. Let's start to optimize object layout first. I think there's definitely the potential for a big speed-up there. For instance, simply replacing the Array that used to store the class, classname and attributes gives me a speed-up of about 15% on the object benchmarks; getting rid of the indirection entirely should be a much bigger win. Simon
Re: subclassing bug
On Thu, 4 Mar 2004, Dan Sugalski wrote: At 10:20 PM +0100 3/2/04, Jens Rieks wrote: The following code results in a clone() not implemented in class 'ParrotClass' error: .sub _main .local pmc a .local pmc b .local pmc c newclass a, A subclass b, a, B subclass c, b, C end .end Steve was right -- the clone I was using was getting in the way. (And flat-out busted, honestly) Only a shallow copy of the parent class' array is needed here, so I put in a bit of custom code rather than use the clone and it works properly now. Which leads me to ask a question that I've been pondering for a while -- do we actually need to use a fullblown Array PMC to hold the object meta-information and attributes? Couldn't we save a level of indirection (and one PMC header per object) by using a List structure directly? Simon
Re: Tetris example
On Tue, 2 Mar 2004, Jens Rieks wrote: from pdd 15: : instantiate Px, Py, Sz (Unimplemented) : Instantiate a brand new class, based on the metadata : in Py, named Sz. I think I have missread this last time. What it is op supposed to do? How can I create an object of class the Block? newclass P1, Block# Creates a Block class find_type I0, Block # Gets Parrot's internal index no. for the # Block class new P2, I0 # Creates an object in that class This really needs to be spelled out better in the PDD -- it is mentioned in an example, but I don't think it's covered in the discussion of object-related opcodes. NB. The code above just creates the object -- you still need to init. the data by hand. Simon
Re: subclassing bug
A PASM version of the test case is: newclass P16, A subclass P16, P16, B subclass P16, P16, C end I think I've figured out what's happening here. Stepping through the code with gdb shows that the first subclassing works fine, but the second blows up in Parrot_single_subclass at line 233: temp_pmc = VTABLE_clone(interpreter, VTABLE_get_pmc_keyed_int(interpreter, (PMC *)PMC_data(base_class), PCD_ALL_PARENTS)); This fetches the parent class's parent array, which is an Array PMC, and which at this point contains a single entry -- a ParrotClass PMC corresponding to class A. We then call the clone method of this array, in order to copy it to temp_pmc. This in turn calls list_clone in order to copy its data, and since our list is comprised of a single PMC, list_clone calls its clone vtable method. BUT: this PMC is a ParrotClass, and there isn't currently a clone method implemented for ParrotClass, so we fall back on the default option, which is to throw an exception and die. The only reason that this works the first time that we create a subclass is that at that point the parent's parent list is empty. An obvious fix for this would be to implement a clone method for ParrotClass, but I'm not sure if this really makes sense, as we could then potentially end up with multiple PMCs representing the same class. (Also, implies that objects in deeply nested classes would have a considerable memory overhead, since they'd each have to drag around PMCs for each of their parent classes). Simon
More closeable tickets in RT
20707 -- fixed (and also irrelevant now we no longer use assemble.pl) 21665 -- fixed 21759 -- patch accepted and applied 22321 -- patch accepted and applied 26898, 26904, 26927, 26939, 26941, 26945, 26953, 26956, 26964, 26976, 27097, 27098, 27143, 27150 -- spam Simon
Re: Another object bug
On Thu, 26 Feb 2004, Dan Sugalski wrote: At 2:38 PM +0100 2/26/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At 8:10 AM +0100 2/26/04, Leopold Toetsch wrote: *Please* don't. Cclassoffset (and attribute access) should by all means start with 0. Why? Simplifies compilers: newclass P1, Foo addattribute P1, i findclass I1, Foo new P2, I1 classoffset I2, P2 In static cases, where P2 is known to be a CFoo, attrib #0 (i) would be always 0. That is, the Cclassoffset opcode can be omitted in that case. That's a very rare case, honestly, and since arguably every object is a subclass of the base object class and people will end up sticking attributes and methods into the base object class it's going to happen anyway. I think I'd rather leave it as a non-zero, non-guaranteed base offset. No, it won't. No code should ever assume an absolute offset. That in itself's broken. like t/pmc/objects.t? I was waiting for you to pull that out. :) Yes, objects.t assumes some evil low-level knowledge of the internals. Well, in part that's because classoffset wasn't implemented when I started writing the tests, so I had to use absolete offsets. Do you want me to rework it to be less evil? Simon
Re: Another object bug
On Thu, 26 Feb 2004, Dan Sugalski wrote: At 10:03 AM -0500 2/26/04, Simon Glover wrote: On Thu, 26 Feb 2004, Dan Sugalski wrote: like t/pmc/objects.t? I was waiting for you to pull that out. :) Yes, objects.t assumes some evil low-level knowledge of the internals. Well, in part that's because classoffset wasn't implemented when I started writing the tests, so I had to use absolete offsets. Do you want me to rework it to be less evil? Yeah, I think that'd be a good idea. I've this nasty feeling that sometime between 0.1.0 and 0.1.2 someone's going to end up adding in more attributes at runtime to the base object class... OK, the object tests now use relative offsets throughout. Simon
Re: Need some help with object tests
One question: there doesn't appear to be any way to generate a list of the existing attributes of a class or even to determine how many attributes a particular class has. Should there be ops for one or both of these things? Simon
addattribute bug
This code: newclass P1, Foo subclass P2, P1, Bar addattribute P2, bar_i print ok 2\n end barfs with: SArray index out of bounds! Is this a bug or just something that hasn't been implemented yet? Simon
More object questions...
Currently, calling get_integer on a ParrotClass returns the attribute count, so you can do: newclass P1, Foo addattribute P1, foo_i addattribute P1, foo_j set I1, P1 print I1 and the code will print '2'. Will this be part of the new API, or is it simply a relic of the previous implementation. Similarly, calling get_integer_keyed_str with a fully-qualified attribute name returns the attribute offsets, meaning that this: newclass P1, Foo addattribute P1, foo_i addattribute P1, foo_j set I2, P1[Foo\x00foo_j] print I2 prints '1' -- is this part of the API or not? Finally, a number of the current tests seem to rely on being able to set and get attribute values with the syntax: set P2[Foo\x00i], 10 set P3[Foo\x00i], 20 set I2, P2[Foo\x00i] set I3, P3[Foo\x00i] (where P2, P3 are objects of class Foo, and Foo has an attribute i). Is this part of the API? Simon
Re: More object questions...
(You're probably getting sick of these by now...) Should asking for a non-existant attribute cause Parrot to throw an exception. Currently, it doesn't seem to be able to make up its mind -- this: newclass P1, Foo find_type I0, Foo new P2, I0 getattribute P3, P2, -2 getattribute P3, P2, -1 getattribute P3, P2, 0 getattribute P3, P2, 1 end completes silently, but if we ask for an attribute with an offset = 2 or = -3, we get an Array index out of bounds! exception. Which is the correct behaviour? (Incidentally, I get the same behaviour with setattribute). Simon
Re: Need some help with object tests
OK, I've dumped a few of the tests that were purely testing features of the old interface, and converted the rest to use the new object ops. Of the 21 tests that remain, nos. 14-15, 18-19 and 21 are still failing: 14, 15 and 21 due to the subclassing bug mentioned previously, 18, 19 because accessing a non-existant attribute at offset 0 currently doesn't throw an exception. Note that the test coverage of the object ops is far from complete, so there's still plenty of scope for people to write object tests if they want to help out. Simon
Re: Object benchmarks?
Here's something very simple I just hacked together to see how fast storing and retrieving attribute values is: set I1, 100 newclass P1, Foo addattribute P1, i find_type I0, Foo new P2, I0 new P3, .PerlInt set P3, 0 time N0 L1: setattribute P2, 0, P3 getattribute P4, P2, 0 inc P3 lt P3, I1, L1 time N1 sub N2, N1, N0 print N2 print \n end For 1 million iterations, I get: un-JITTED -- 0.42 sec JITTED-- 0.34 sec (Incidentally, if I comment out the setattribute and getattribute lines, then I get: un-JITTED -- 0.11 sec JITTED-- 0.05 sec which is the cost of the inc and comparison). Simon
Another object bug
If I'm understanding the docs correctly, this should print '0'. Instead, it prints 'Array index out of bounds!' newclass P1, Foo addattribute P1, i find_type I0, Foo new P2, I0 classoffset I1, P2, Foo print I1 print \n end Simon
Re: Another object bug
On Wed, 25 Feb 2004, Dan Sugalski wrote: At 4:54 PM -0500 2/25/04, Simon Glover wrote: If I'm understanding the docs correctly, this should print '0'. Instead, it prints 'Array index out of bounds!' Another bug, though the offset ought to be 2 right now. (Attributes 0 and 1 are taken by other things so they're valid) OK, I think I see what's going on now: attribute 0 is the class PMC, attribute 1 is the classname PMC, and then any other attributes go into slots 2+ However, there's currently nothing to stop you stomping on the PMCs in slots 0 and 1 by setting attributes with those offsets: in other words, doing: newclass P1, Foo addattribute P1, i find_type I0, Foo new P2, I0 new P3, .PerlInt set P3, 1024 setattribute P2, 1, P3 works, but changes the classname PMC to be a PerlInt with a value of 1024. Are we supposed to be able to do this? A second issue (and what confused me in the first place) is that in your attribute example in PDD 15 you have: Adding the attributes Ca and Cb to the new class CFoo: newclass $P0, Foo addattribute $P0, a, Foo::a # This is offset 0 addattribute $P0, b, Foo::b # This is offset 1 I assume that this should actually refer to offsets 2 and 3? Finally, in looking at the ops code, I noticed an unrelated bug: in the classname op, you do: classname_pmc = VTABLE_get_pmc_keyed_int(interpreter, (PMC *)PMC_data($2), POD_CLASS_NAME); To get the classname for the PMC. The problem is that the op is documented as working with a PMC respresenting a class, but you're using the symbolic constant from the object enum. This currently works, since the classname PMC is stored in slot 1 in both a ParrotObject and a ParrotClass PMC, but it still looks like a bug. Simon
Re: Ladies and gentlemen, I give you... objects!
On Wed, 25 Feb 2004, Dan Sugalski wrote: Yep, it looks like everything that should work now actually *does* work now, modulo a test that needs a thump. If folks would abuse this The test has now been thumped. All tests now pass here. Of course, that just means that it's time to write some more than don't... :-) Simon
Re: [perl #26911] Failing tests on Linux/x86
On Tue, 24 Feb 2004, Leopold Toetsch wrote: Simon Glover [EMAIL PROTECTED] wrote: I sent this a few days ago, but RT doesn't seem to have forwarded it to the list for some reason. Fixed. Confirmed. The only failures I'm now getting are some of the object tests (which Dan has just broken), and the first couple of signals tests (which I'm going to look into when I have time). Thanks, Simon
Re: Various newbie questions.
On Tue, 24 Feb 2004 [EMAIL PROTECTED] wrote: 2) I sent this question previously (22 Feb 2004 20:37 GMT) but it never made it onto the list. (I was unsubscribed!). If I make a change in win32.c, (now: config/gen/platform/win32/exec.c) what is the procedure (or where is this documented) to get platform.c re-generated and compiled into parrot.exe? The only mechanism I have found that does this is to nmake realclean configure.pl nmake which doesn't seem right somehow, but I think I've read every documentation file at least twice and nothing has leaped of the page as to the right way to do this. That seems right to me: platform.c is generated when configure runs, and so we don't want to delete it when we do a simple 'make clean', only when we do 'make realclean'. This is documented in the makefile itself, but I'm not sure if we document it elsewhere; if not, then we probably should. Incidentally, it's not only platform.c that behaves like this -- a number of other files have the same behaviour, either because they are platform dependent or because they depend on the particular configuration options chosen. The full list is in the Makefile -- see the section 'STICKY GENERATED FILES:'. Again, I'm not sure if these are documented anywhere else, but they should be. Simon
Re: cvs commit: parrot/src packfile.c
On Tue, 24 Feb 2004, Garrett Rooney wrote: The PARROT_BIGENDIAN case has a typo in pf_items.c, here's a patch to make it compile again. Thanks, applied. Simon
Re: Objects and time
On Mon, 23 Feb 2004, Melvin Smith wrote: At 05:09 PM 2/23/2004 +0100, Leopold Toetsch wrote: WRT feature freeze: I'd say: Starting from Tue, 24th 8.00 GMT no more feature patches *should* go in, *except* objects. Basically that means: everyone will get really quiet and we will all watch Dan. :) Alternatively: everybody will spend their time writing tests and documentation... (Well, OK, probably not, but I'm hopelessly optimistic). Simon
Re: PDD status
On Sat, 21 Feb 2004, Michael Scott wrote: All that metadata up front in the PDDs is a bit off-putting. I'm thinking of going through all of them and putting it at the end. Any objections? Well, I've just committed the version I posted pretty much as-is, but feel free to make any changes to the layout you think are appropriate. Simon PS Bryan: I've put my name on this as maintainer for now; I hope that's OK.
[perl #26911] Failing tests on Linux/x86
I sent this a few days ago, but RT doesn't seem to have forwarded it to the list for some reason. Simon -- Forwarded message -- Date: Thu, 19 Feb 2004 15:21:19 -0500 (EST) From: Simon Glover [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Failing tests on Linux/x86 I'm seeing a bunch of tests failing on my dual-processor x86; specifically, I get failures in: t/op/calling,1-2 t/op/lexicals, 3-6 t/op/stacks, 23, 51, 53 t/pmc/array, 6-11 t/pmc/coroutine, 2 t/pmc/dumper,1-5 and then it hangs indefinitely in test 6 in dumper.t The problem appears to be GC related; if I change the line: $args .= ' --gc-debug'if $gc_debug; in t/harness to: $args .= ' --gc-debug'unless $gc_debug; (i.e. I switch gc-debug off), then I only get two failures: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/pmc/timer.t1 256 71 14.29% 2 t/src/hash.t 1 256101 10.00% 6 Since we're not seeing any of these failures in the tinderbox machines, I suspect that the problem is something specific to my setup. I've attached my myconfig file below, as well as the output from perl -V I'm afraid that I don't have a clear idea of when things first started failing, since this is the first time that I've run the test suite for quite some time. Simon -- Summary of my parrot 0.0.13 configuration: configdate='Thu Feb 19 15:03:38 2004' Platform: osname=linux, archname=i686-linux-ld jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/home/scog/local/bin/perl Compiler: cc='gcc', ccflags=' -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread' Dynamic Linking: so='.so', ld_shared='-shared -L/usr/local/lib', ld_shared_flags='' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=4 byteorder=1234, nv=long double, numvalsize=12, doublesize=8 - Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.9-31smp, archname=i686-linux-ld uname='linux nevis 2.4.9-31smp #1 smp tue feb 26 06:55:00 est 2002 i686 unknown ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=define usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2', cppflags='-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.1 2.96-98)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='long double', nvsize=12, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.4.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.2.4' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LONG_DOUBLE USE_LARGE_FILES Built under linux Compiled at Aug 3 2002 16:34:41 %ENV: PERL5LIB=/home/scog/local/lib/site_perl/5.8.0 @INC: /home/scog/local/lib/site_perl/5.8.0 /home/scog/local/lib/perl5/5.8.0/i686-linux-ld /home/scog/local/lib/perl5/5.8.0 /home/scog/local/lib/perl5/site_perl/5.8.0/i686-linux-ld /home/scog/local/lib/perl5/site_perl/5.8.0 /home/scog/local/lib/perl5/site_perl .
Re: PDD 11 -- extensions
On Sat, 21 Feb 2004, Mattia Barbon wrote: Il Fri, 20 Feb 2004 16:12:40 -0500 (EST) Simon Glover [EMAIL PROTECTED] ha scritto: Here's a first draft of PDD 11. It's based on a combination of the existing extend.pod and the comments in extend.c, with additional text by yours truly. It should provide a minimal level of documentation for all of the functions currently implemented in extend.c, but it doesn't discuss future additions to the API (other than warning people that there will be some). it was agreed that extension API should use the same names as the rest of Parrot (i.e.: Parrot_String instead of Parrot_STRING, etc.). A patch was submitted but not applied. The rest looks OK. I found the patch (#24817), but it doesn't look like there was agreement on whether or not it should go in, so I'm going to stick with the old names for now. However, a definitive decision from Dan or Leo would be nice. Simon
Re: [perl #26911] Failing tests on Linux/x86
On Mon, 23 Feb 2004, Leopold Toetsch wrote: Simon Glover [EMAIL PROTECTED] wrote: I sent this a few days ago, but RT doesn't seem to have forwarded it to the list for some reason. Can you cvs update and try again please. GC related bugs should be fixed now. I'm still getting the same failures with a fresh checkout. Simon
Re: PDD status
On Fri, 20 Feb 2004, Tim Bunce wrote: Did you forget to add Volunteers wanted for each of these ? Well, I'm going to try to tackle some of it, but since I have minimal CFT at the moment, any volunteers would be very welcome. Simon
Extension API questions
I'm currently trying to put together a first draft of PDD 11 (extensions) based on extend.pod plus the comments in extend.c and I've got a few questions: [NB. I've dropped the Parrot_PMC prefixes below to save typing] i) We have _get_string, _get_pointer, _get_intval, _get_numval, _get_cstring and _get_cstringn. We also have intkey variants of all of these, _except_ for _get_string. Is this missing deliberately, or was this just an oversight? ii) The only way we have to access keyed aggregates is via intkeys. Shouldn't we also be able to access them using strings or PMCs as keys? [We do, after all, have the vtable functions to allow this] iii) At the moment, to create a new PMC, you need to know its internal identifier number. You can retrieve this using Parrot_PMC_typenum if you know the name of the PMC that you want to create, but what do you do if you're just handed a PMC and you want to say 'Create me a PMC of the same type as this one'? Simon
Re: Extension API questions
On Fri, 20 Feb 2004, Dan Sugalski wrote: At 2:37 PM -0500 2/20/04, Simon Glover wrote: I'm currently trying to put together a first draft of PDD 11 (extensions) based on extend.pod plus the comments in extend.c and I've got a few questions: [NB. I've dropped the Parrot_PMC prefixes below to save typing] i) We have _get_string, _get_pointer, _get_intval, _get_numval, _get_cstring and _get_cstringn. We also have intkey variants of all of these, _except_ for _get_string. Is this missing deliberately, or was this just an oversight? Oversight. OK, I've added one. We ought to put together a TODO list for the other bits and pieces soon. Simon
PDD 11 -- extensions
Here's a first draft of PDD 11. It's based on a combination of the existing extend.pod and the comments in extend.c, with additional text by yours truly. It should provide a minimal level of documentation for all of the functions currently implemented in extend.c, but it doesn't discuss future additions to the API (other than warning people that there will be some). If nobody complains, I'll go ahead and commit this soon. Simon -- =head1 TITLE The Parrot Extension System =head1 VERSION =head2 CURRENT Maintainer: Class: Internals PDD Number: 11 Version: 1.0 Status: Developing Last Modified: February 20, 2004 PDD Format: 1 Language: English =head2 HISTORY =over 4 =item version 1 None. First version =back =head1 CHANGES =over 4 =item Version 1.0 None. First version =back =head1 ABSTRACT The extension API for Parrot is a simple, somewhat abstract, interface to Parrot for code written in C or other compiled languages. It provides about the same level of access to Parrot that bytecode programs have. =head1 DESCRIPTION The API presents to C programs roughly the same interface presented to bytecode programs--that is, a C extension can see everything that a bytecode program can see, including Parrot's base architecture, registers, stacks, and whatnot. This view isn't required, however, and often extension code won't need or want to know what Parrot's internal structures look like. For this reason the functions in the extension API are divided into two broad groups, one that has no particular knowledge of the internals and one that does. The stability of the two API groups is guaranteed separately. Group 1, the internals unaware group, should be good basically forever. Group 2, the internals aware group, is only guaranteed for the lifetime of the current architecture. (It's likely that both groups will last equally long; however, the Group 1 interface could reasonably be emulated on a different engine, while the Group 2 interface is more closely tied to Parrot). BNote: The extension API has not yet been completely specified. New functions may be added, and those described below may change or be removed. You have been warned... =head1 API =head2 Group 1: Internals-unaware functions These functions are the ones that are largely unaware of the structure and architecture of Parrot. They deal mainly in data as abstract entities, and Parrot itself as a black box that, at best, can make subroutine or method calls. This is sufficient for many extensions which act as black box processing units and in turn treat Parrot itself as a black box. =head3 PMC access functions The following functions are for storing and retrieving data inside PMCs. Note that use of the _keyed functions with non-aggregate PMCs will generally just result in Parrot throwing an exception. =over 4 =item Parrot_PMC_get_string(interp, pmc) Returns a Parrot_STRING that represents the string value of the PMC. =item Parrot_PMC_get_string_intkey(interp, pmc, Parrot_Int key) Keyed version of CParrot_PMC_get_string. Returns a Parrot_STRING representing the string value of whatever is stored at the element of the PMC indexed by Ckey. =item Parrot_PMC_get_pointer(interp, pmc) Returns a pointer to some item of data. The details of what the pointer points to depend on the particular PMC. This function is useful for dealing with PMCs that hold pointers to arbitrary data. =item Parrot_PMC_get_pointer_intkey(interp, pmc, Parrot_Int key) A keyed version of CParrot_PMC_get_pointer. Returns the pointer value of whatever is stored at the element of the PMC indexed by Ckey. =item Parrot_PMC_get_intval(interp, pmc) Returns the integer value of the PMC. =item Parrot_PMC_get_intval_intkey(interp, pmc, Parrot_Int key) A keyed version of CParrot_PMC_get_intval. Returns the integer value of whatever is stored at the element of the PMC indexed by Ckey. =item Parrot_PMC_get_numval(interp, pmc) Returns the numeric value of the PMC. =item Parrot_PMC_get_numval_intkey(interp, pmc, Parrot_Int key) A keyed version of CParrot_PMC_get_numval. Returns the numeric value of whatever is stored at the element of the PMC indexed by Ckey. =item Parrot_PMC_get_cstring(interp, pmc) Returns a C-string (char *) that represents the string value of the PMC. The memory the char * points to is a copy of the original value, and changing it will not change the original in any way. This memory will Inot be reclaimed by garbage collection, nor may it be returned to the system with Cfree. It must be returned with CParrot_free_cstring. =item Parrot_PMC_get_cstring_intkey(interp, pmc, Parrot_Int key) A keyed version of CParrot_PMC_get_cstring. Returns a C-string representing the string value of whatever is stored at the element of the PMC indexed by Ckey. =item Parrot_PMC_get_cstringn(interp, pmc, len) Returns a C-string (char *) that represents the
Re: PDD status
OK, here's a rewritten version of PDD 0, which reflects my view of the role that the PDDs currently play in Parrot development. Comments welcome. Simon
Re: PDD status
On Sat, 21 Feb 2004, Simon Glover wrote: OK, here's a rewritten version of PDD 0, which reflects my view of the role that the PDDs currently play in Parrot development. Comments welcome. Let's try that again, with the the PDD actually attached this time... Simon - =head1 TITLE Parrot Design Documents =head1 VERSION =head2 CURRENT Maintainer: Class: Meta PDD Number: 0 Version: 2 Status: Developing Last Modified: 20 February 2004 PDD Format: 1 Language: English =head2 HISTORY v2 substantially rewritten on 20 Feb 2004 by Simon Glover v1 created on 7 Dec 2000 by BCWarnock [EMAIL PROTECTED] v1 promoted to Developing as PDD 0 on 20 February 2001 by Dan Sugalski. =head1 CHANGES Substantially rewritten to reflect what the PDDs actually are (rather than what we hoped they would be 3+ years ago). =head1 ABSTRACT This document defines the standard format for the Parrot Design Documents (PDDs) - the basic descriptions/plans for the design of Parrot. =head1 DESCRIPTION The original intent of the Parrot Design Documents (which themselves were initially Perl Design Documents) was threefold: =over 4 =item 1 To provide a clear indication of the direction of current development (essentially, a road map from an abstract idea to a concrete implementation). =item 2 To act as a historical record of the rationale behind the decision, in order to provide context to future developers, who may not have been familiar with the original discussion. =item 3 To provide a historical, technical and cultural perspective for future development work. Re-implementation or even tangential tasks need only address what has changed since the original PDD. =back Needless to say, things didn't work out this way. Some of the context discussed above is now documented in the F*.dev documents (see the F/docs/dev directory); much of it remains undocumented. The portions that have wound up being documented as PDDs are the basic design of the Parrot interpreter. In other words, the PDDs describe the Bfeatures that the interpreter should implement. They Bshould not discuss the details of the actual implementation (unless they absolutely have to) or the choices leading to that particular implementation; these are details that should go in the relevant F*.dev file. On the other hand, they Bshould detail the trade-offs made in the actual design. =head1 IMPLEMENTATION All newly created PDDs will adhere to the PDD standard current as of the time of proposal. An example of the currently accepted layout is given in Fdocs/pdds/pdd_template.pod, which should be used as a template for any future PDDs. =head2 FORMAT All PDDs will be written in POD parseable by the current stable release of Perl. Although XML is a viable solution and has its vocal supporters, and although Parrot is intended to be used by many groups outside of the Perl community, we have chosen POD for its simplicity and ease of reading in plaintext form. Conversion to other formats (e.g. HTML) is encouraged, but the POD version should remain the master copy. All PDDs will be written in English. British, American, or Other is the choice of the author. Translation to other languages, like all Perl documentation, is encouraged. (See SLPDD TRANSLATIONS.) All PDDs will contain the following information: =over 4 =item TITLE: A short, general description of a specific part of the Parrot design. This may be a particular subsystem (e.g. the garbage collector), or a more general topic (e.g. basic Parrot datatypes). =item VERSION: Contains current and selected historical metadata on the PDD itself. =item CURRENT: Contains the following information, current as of the date of submission. =over 4 =item Maintainer Required. The name and current email address for the point of contact for the PDD. This is the person to whom questions, comments, and patches should generally be addressed. This need not be the author of the document. (In practice, non-trivial changes to the PDDs should probably be discussed on the perl6-internals mailing list before they take place). =item Class Required. The area of Parrot the PDD covers. This allows related PDDs to be logically grouped. The current list of valid classes is: Internals - on the design of the Parrot interpreter Documentation - on Parrot documentation Meta - on the Parrot project as an entity Testing - on the testing of Parrot It is expected that most PDDs will fit into a single class, but in principle a may belong to more than one class. However, peripheral excursions into the scope of another class should not warrant an actual classification (i.e. you shouldn't classify something as CTesting simply because you happen to mention potential tests at one or two points in the text). =item PDD Number Required. No two PDDs should have the same number. PDD
Re: Release doc tasks
Re. obsolete docs: parrot_assembly.pod is a really old version of pdd06, and should probably just be dumped (the last patch to it was 16 months ago, the last non-trivial patch about 2 years ago) embed.pod should probably be reworked as a proper PDD (since pdd10_embedding.pod is empty right now) pdd12_assembly.pod -- what was the intent of this? (i.e. is there stuff that isn't covered in pdd06_pasm.pod that should go in here, or can we just dump this and recycle the number?) Simon
PDD status
PDD 0 (intro. to PDDs): Very, very out of date; I think it actually pre-dates Parrot PDD 1 (overview of Parrot): Not obviously out-of-date, but could use some text on IMCC and on the JIT PDD 2 (vtable functions): Needs documentation on freeze, thaw and share from somebody who actually understands what they do. We also need to figure out which of the functions described in it are simply waiting to be implemented and which are never going to be implemented PDD 4 (datatypes): The bigint/bignum stuff is completely out-of-date. We also need to figure out if there are any other internal datatypes that we should be documenting. PDD 5 (opfuncs): Very, very out-of-date. Needs a significant rewrite. PDD 6 (PASM): Missing a lot of ops. Also includes some ops that don't exist. (An easy task for the interested would be to put together a list of each). PDD 7 (coding standards): OK, as far as I know. PDD 8 (keys): This is quite old, so we need to check if it accurately describes the current system. PDD 9 (GC): Doesn't discuss any of the recent changes, such as the early DOD stuff PDD 10 (embedding): Empty. (Although we do have embed.pod) PDD 11 (extending): Empty. (But see extend.pod) PDD 12 (assembly): Empty and obsolete. PDD 13 (bytecode): Empty. (But see parrotbyte.pod) PDD 14 (bignums): Bignums are unimplemented, so all of this may change in the future. PDD 3 (calling conventions): PDD 15 (objects): Dan's handling these. PDD 16 (NCI): Needs looking over by somebody who understands the NCI system.
Re: Objects: Now or forever (well, for a while) hold your peace
One really pedantic comment: wouldn't it make sense to rename the fetchmethod op to fetchmeth, for consistency with callmeth, tailcallmeth etc? Simon
Re: Object spec
Here's a patch to fix various typos etc. that I noticed on going over the spec. Simon --- pdd15_objects.pod.old Fri Feb 13 17:06:46 2004 +++ pdd15_objects.pod Fri Feb 13 17:10:08 2004 @@ -174,7 +174,7 @@ =item * -remove interfaces +Remove interfaces =back @@ -209,13 +209,13 @@ hold all the per-object instance data. ParrotClass PMCs hold all the class-specific information. Instantiating a new OO class creates a new ParrotClass PMC, and enters the new OO class into Parrot's PMC class -table, at which point it is indistiguishable from any other PMC +table, at which point it is indistinguishable from any other PMC class. (This doesn't mean that non-ParrotClass things can be subclassed or treated as an OO class. Neither is that forbidden. Just unimplemented) It's important to note that Iall 'standard' classes are -ParrotClass PMC instancess, and Iall 'standard' objects are +ParrotClass PMC instances, and Iall 'standard' objects are ParrotObject PMCs. We do Inot create a brand new PMC class for each OO class, and they all share the ParrotClass or ParrotObject vtable, respectively. This distinction is mostly an artifact of the @@ -252,7 +252,7 @@ The class attribute name hash. Keys are the fully qualified attribute names (in whatever format the language governing the class wants) and -the values are the offset from the beginnign of the attribute array of +the values are the offset from the beginning of the attribute array of the particular attribute. =back @@ -265,7 +265,7 @@ ParrotClass PMCs also have the I am a class flag set on them. -The ParrotObject PMC is an array of metainformation and +The ParrotObject PMC is an array of meta-information and attributes. The elements of this array are: =over 4 @@ -317,7 +317,7 @@ =item setattr Px, Sy, Pz -Set the attribute of obbect Px with the fully qualified name Sy to Pz +Set the attribute of object Px with the fully qualified name Sy to Pz =item fetchmethod Px, Py, Sz
Re: Object spec
A few questions: 1) How is the search order for the parents of a particular class specified? In particular, is this determined at the Parrot level or at the language level? Can it change at runtime? 2) Re. the classoffset op: how does this work when multiple parent classes specify the same attribute? For instance, suppose 'foo' is the first attribute specified in classes 'Bar' and 'Baz', which are theselves unrelated (i.e. 'Bar' doesn't inherit from 'Baz', nor vice versa), but which are both parent classes of a third class 'Qux'. Now, if P0 holds an object of class 'Qux', does: classoffset I0, P0, 'Bar' return the same value as: classoffset I0, P0, 'Baz' or not? 3) If more than one parent class specifies a particular attribute, do all of these parents have to be removed before the attribute is removed? Regards, Simon
Re: open issue review (easy stuff)
Here are a few that can be closed; I'm sure this is far from a complete list. Simon 15357: Read write ops in core.ops are broken Close - the broken ops no longer exist. 16114: [PATCH] faster assembler Close - we don't use assemble.pl any more. 17974: make clean removes lib/Parrot/PMC.pm Close - the bug was fixed. 18637: PDD06: Incomplete sentence at end of section Close - fixed. 18892: Perl_Parse from JNI Native code crashing... Close (or redirect) - Perl 5.6.1 bug 19143: Another GC bug? Close - fixed. 21668: APL doesn't use sigils Close - not a bug 22316: [PATCH] Truncated entry in glossary.pod Close - fixed. 22856: IMCC fails to build Close - fixed. 22867: Popbottom ops Close - not a bug, just unclear documentation, which I fixed. 23767: parser_util.c doesn't compile Close - fixed. 24056: [PATCH] disassemble crashes Close - fixed. 24063: [PATCH] Add C test info to tests.pod Close - patch was applied. 24267: Inconsistent behaviour of logical or op Close - fixed.
Re: Docs and releases
Well, one thing that people can contribute that doesn't require much (if any) knowledge of the internals is tests (whether in PASM, PIR, or one of the other languages that run on top of Parrot). Tests that uncover bugs are particularly helpful! Simon
Re: When is enough too much?
On Tue, 23 Dec 2003, Dan Sugalski wrote: I'm pondering, once again, more things with the Postgres interface. In this case I need to pass in arrays of ints (and floats, I suppose) and arrays of char pointers. My first thought is to have a new type that converts an Array (or something like it) to a C array, either of ints or char pointers. That'd solve my problem quite nicely. But... that begs the question--is it going too far? Is this the sort of stuff that ought to have custom C interfaces for, rather than adding in Yet More Types to the NCI interface? Speaking personally, being able to automatically convert a Parrot array to an array of ints or floats would be very useful, but that's because I do fairly hard-core number crunching in my day job. What are the arguments againtst putting something like this in the NCI interface? Simon
Re: threads and shared interpreter data structures
On Tue, 23 Dec 2003, Uri Guttman wrote: RA == Rod Adams [EMAIL PROTECTED] writes: A major use of many languages these days is web services. In the parrot world, I see three possible ways for this to happen. - CGI/Exec. No problem to make parrot work, but the performance issues with this are well known. - mod_parrot. With Apache 2.0, this would need to be heavily threaded to match the Apache core. - A pure parrot web application server (PPWAS) that can compete directly against the EJB/.NET crowd. This would obviously need heavy threading with high performance. you missed at least two major designs a pure parrot event loop system. if it has true async file i/o (which dan has promised by using kernel threads but not parrot threads), you can do it all in one process and one thread and not have the sync/locking thread overhead or the process context switch overhead. use an apache front end to a backend design as with the above. then you get all the apache stuff you want and you get a fast backend with no mod_perl craziness, no parrot level thread issues, etc. the moral is, parrot threads are not the be-all/end-all solution. my favorite query about threads is how well do they scale beyond one box? (even dan can't fix that problem. :) Well, Dan's type 2 threads sound fairly like a message-passing system, in which case it would hopefully be possible to have them seamlessly interface with MPI or PVM; in which case, scaling beyond one box is no problem (well, at least until latency, bandwidth and/or Amdahl's law start to bite...) Simon
Re: Determining PMC memory addresses
On Fri, 28 Nov 2003, Cory Spencer wrote: On Fri, 28 Nov 2003, Leopold Toetsch wrote: Op vtable Meaning - is_same PMCs are ident - is_equal PMCs are equivalent, holding the same value Y cmp cmp PMCs - cmp_num cmp PMCs numerically - cmp_string cmp PMCs as strings Proposals for opcode names welcome. How does the current 'eq' opcode deal with comparissons of PMC/PMC values? 'eq' calls is_equal, so that should have a 'Y' in the table above. Simon
Re: Proposal: parrot-compilers list
On Tue, 18 Nov 2003, Jeff Clites wrote: On Nov 17, 2003, at 11:22 AM, Melvin Smith wrote: In the past couple of years we've seen several sub-projects pop-up and subsequently fizzle out (maybe due to Parrot slow progress or maybe due to lack of critical mass). I propose creating 'parrot-compilers' as a general purpose list for any and all language development ... So I'll be one of the few nay-sayers. I'm not definitely against it, but here are two counter-arguments: 2) Forking a list almost always leads to an increase of messages of the form you should be asking this on the other list..., and/or of cross-posting, neither of which is very interesting to deal with. I'm of the opinion that unless traffic is unmanageable, fewer lists is better. So I think a fair question to ask is: How many people currently subscribed to this list would not subscribe to both? For those who subscribe to both, splitting wouldn't be an improvement. Well, I'm currently subscribed to perl6-internals but probably would not subscribe to parrot-compilers (since I don't currently have time to learn enough to be able to usefully contribute). Simon
Re: docs
On Mon, 3 Nov 2003, Dan Sugalski wrote: On Mon, 3 Nov 2003, Nick Kostirya wrote: Catalog docs\ops is empty in 0.0.13 version. Is it bug? I think that's leftover cruft. Well, we used to generate a .pod file for each .ops file, at build time, which lived in here. However, we don't appear to be doing this anymore (although I'm not sure when this changed). Simon
Re: [PS] obsolete files
On Thu, 23 Oct 2003, Leopold Toetsch wrote: Here is a list of files that I consider to be unused: * ops2cgc.pl unused, functionality is in ops2c.pl * make.pl unused?, seems outdated * classes/csub.pmc AFAIK unused, we have NCI, method_util is outdated * classes/pointer.pmc used AFAIK only by rx.ops - should be a ManagedStruct If no one hollers, I'll remove these and change rx.ops to use a ManagedStruct PMC. Can I also suggest: optimizer.pl lib/Parrot/Optimizer.pm They haven't been touched for 20 months / 16 months respectively, I don't know of anybody using them, and I think that IMCC makes them obsolete. Simon
Re: More file moves
On Thu, 23 Oct 2003, Dan Sugalski wrote: *.ops and ops.num are in the ops directory, where all ops should go from now on. *.c is in the base directory Um, it actually appears to be in the src directory; the base directory is empty. Was this an intentional change of plan? Simon
Re: Almost, but not quite, there
On Thu, 23 Oct 2003, Dan Sugalski wrote:
At 4:43 PM -0400 10/23/03, Dan Sugalski wrote:
And I could certainly do with some help at this point.
Parrot is *almost* put back together. There's some weird linking problem
that's keeping parrot from working out as it should, and I've not been
able to track it down. If anyone feels like syncing up and giving it a
shot, I'd not mind it at all.
And now we're fine, and even test good with the JIT. Woohoo!
Time to thump it some and see what I missed.
Well, I've just stumbled across one problem: if you run Configure
with --ask, then it won't accept its own default list of ops files.
The problem is this bit of config/inter/ops.pl:
{
$ops=prompt('Which opcode files would you like?', $ops);
if($ops !~ m{^\s*core\.ops}) {
print core.ops must be the first selection.\n;
redo;
}
}
}
Configure lists ops/core.ops as the first in the list of default ops
files, but this doesn't match the regex. The patch below fixes this
on Unix, but probably isn't portable to Win32; I imagine there's a
better way to fix it.
Simon
Index: config/inter/ops.pl
===
RCS file: /cvs/public/parrot/config/inter/ops.pl,v
retrieving revision 1.2
diff -u -r1.2 ops.pl
--- config/inter/ops.pl 23 Oct 2003 19:21:30 - 1.2
+++ config/inter/ops.pl 23 Oct 2003 22:19:39 -
@@ -34,7 +34,7 @@
{
$ops=prompt('Which opcode files would you like?', $ops);
- if($ops !~ m{^\s*core\.ops}) {
+ if($ops !~ m{^ops/\s*core\.ops}) {
print core.ops must be the first selection.\n;
redo;
}
Re: [perl #24267] Inconsistent behaviour of logical or op
On Wed, 22 Oct 2003, Leopold Toetsch wrote:
Simon Glover [EMAIL PROTECTED] wrote:
Clearly there's a bug here, since the behaviour should be consistent;
I have changed the PerlInts to work like all others, thanks
I don't think your fix is correct, since:
new P0, .PerlNum
new P1, .PerlInt
new P2, .PerlNum
set P0, 10.5
set P1, 0
or P2, P1, P0
print P2
print \n
end
will now print 10, rather than 10.5 (which is better than the behaviour
before the fix, but which is still not right).
Having done some more nosing around, I see that PerlString doesn't
actually have its own implementation of logical_or; instead, it falls
back on the scalar.pmc version, which does:
void logical_or (PMC* value, PMC* dest) {
if (DYNSELF.get_bool()) {
VTABLE_set_pmc(INTERP, dest, SELF);
}
else {
VTABLE_set_pmc(INTERP, dest, value);
}
}
Is there a good reason why we're not doing the same thing for
PerlInt/Num/Undef?
Simon
Bounds checking in extension API
What, if any, validation of their input should the register access functions in the extension API do? Currently, they don't do any, which means that you can create a buffer overflow simply by using a register number 31 or 0; eg, Parrot_set_intreg(interpreter, 1, 100); reliably segfaults on my machine. Is it the responsibility of the extension writer to do this kind of bounds checking (in which case we need to make this extremely plain in the documentation), or should Parrot do this itself? Simon
Re: Bounds checking in extension API
On Fri, 17 Oct 2003, Dan Sugalski wrote: On Fri, 17 Oct 2003, Simon Glover wrote: What, if any, validation of their input should the register access functions in the extension API do? Currently, they don't do any, which means that you can create a buffer overflow simply by using a register number 31 or 0; eg, Parrot_set_intreg(interpreter, 1, 100); reliably segfaults on my machine. Is it the responsibility of the extension writer to do this kind of bounds checking (in which case we need to make this extremely plain in the documentation), or should Parrot do this itself? This ought to be done by the extension API, though it was something I skimped on when I was throwing it together. OK, so what do we do in response to an out-of-bounds access? Throw a Parrot exception? Or indicate an error in some other fashion? Simon
Another extension API question
How do we create a Parrot_STRING in an extension? Parrot_Ints and Parrot_Floats are easy, since they're just declarations, and for PMCs there's Parrot_PMC_new, but there doesn't appear to be an equivalent for strings. Simon
Re: The Pumpking is dead, long live the Pumpking!
On Fri, 17 Oct 2003, Jim Cromie wrote: Dan Sugalski wrote: Hey folks. It's that time of year again, when the patch pumpkin passes paws. Hands, rather. Steve Fink now joins the ranks of Parrot Pumpkings Emeritus, having shepherded a number of releases out the door. We wish him a happy retirement and hope the nervous twitches stop soon. Replacing him as the pumking is the inimitable Leo Toetsch, so do please extend your sympathy^Wcongratulations to the newest volunteer for the post. wow - 1st the PatchMonster, now the Pumpking. we watch in awe as the World Domination Plan unfolds. whats next, the WhiteHouse ? It would be a marked (tm) improvment.. Are you sure you want to set a precedent for having an Austrian in the Whitehouse? Simon PS Steve: thanks for all of your hard work Leo: good luck!
Re: [perl #24239] [PATCH] OpenBSD support
On Fri, 17 Oct 2003, Adam Thomason wrote: # New Ticket Created by Adam Thomason # Please include the string: [perl #24239] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24239 Two issues while building parrot on OpenBSD 3.3/i386: * arpa/inet.h doesn't include netinet/in.h (which defines struct in_addr) on its own. This sends up a wave a warnings about the incomplete type in function signatures. Moving the inclusion of netinet/in.h above arpa/inet.h in parrot.h fixes the problem for me, and doesn't seem to affect building on AIX or Gentoo. * pthread support requires both a ccflags option (-pthread) and a libs option (-lpthread). I've added config/init/hints/openbsd.pl to address this. Patch for both is attached. With it applied, the standard tests all pass and testj fails 5/924 subtests. I'll try to investigate the holdouts. Thanks, applied. Simon
isa query
What should this code print? newclass P1, Foo instantiate P2, P1 isa I0, P2, Foo print I0 print \n end How about this? newclass P1, Foo instantiate P2, P1 isa I0, P2, ParrotObject print I0 print \n end (NB Both will segfault without the fix I just checked in for parrotobject.pmc, as the PMC wasn't being initialized properly due to a typo). Simon
mmd_dispatch_numval
From mmd.pod: =item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num) Like Cmmd_dispatch_string, only it returns a FLOATVAL. Wouldn't it be more sensible to call the function mmd_dispatch_floatval ? Simon
Re: mmd_dispatch_numval
On Thu, 16 Oct 2003, Dan Sugalski wrote: On Thu, 16 Oct 2003, Simon Glover wrote: From mmd.pod: =item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num) Like Cmmd_dispatch_string, only it returns a FLOATVAL. Wouldn't it be more sensible to call the function mmd_dispatch_floatval ? Yep. The terminology's mixed in a number of places--we should probably go fix it everywhere and be done with it. (Unless I'm just behind the times and its already been done :) OK, I've changed it over to mmd_dispatch_floatval in mmd.c, mmd.h and mmd.pod; as far as I can tell, it's not yet being used anywhere else. Simon
Re: mmd_dispatch_numval
On Thu, 16 Oct 2003, Jeff Clites wrote: On Oct 16, 2003, at 2:40 PM, Simon Glover wrote: On Thu, 16 Oct 2003, Dan Sugalski wrote: On Thu, 16 Oct 2003, Simon Glover wrote: From mmd.pod: =item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num) Like Cmmd_dispatch_string, only it returns a FLOATVAL. Wouldn't it be more sensible to call the function mmd_dispatch_floatval ? Yep. The terminology's mixed in a number of places--we should probably go fix it everywhere and be done with it. (Unless I'm just behind the times and its already been done :) OK, I've changed it over to mmd_dispatch_floatval in mmd.c, mmd.h and mmd.pod; as far as I can tell, it's not yet being used anywhere else. Although I think float is clearer than number (in that it's clearly different than integer), it might be easier to go with number--since we have set_number vtable methods, and N registers rather than F registers Ah, but we currently use floatval and FLOATVAL in a lot more places than we do numval or NUMVAL (or number). Simon
Re: [perl #24096] Null Nx fails under JIT on x86
Summary of my parrot 0.0.11.2 configuration: configdate='Thu Oct 2 13:50:07 2003' Platform: osname=linux, archname=i686-linux-ld jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/home/scog/local/bin/perl Compiler: cc='gcc', ccflags=' -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lnsl -ldl -lm -lcrypt -lutil' Dynamic Linking: so='.so', ld_shared='-shared -L/usr/local/lib', ld_shared_flags='' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=4 byteorder=1234, nv=long double, numvalsize=12, doublesize=8
RE: This week's summary (off-list-to-protect the names of the young and old)
On Mon, 15 Sep 2003, Melvin Smith wrote: Dan spoke too soon, we have just confirmed that PIERS_C = 2.04739336492890995260663507109 * BRENT_D They both know their time of birth to the nearest nanosecond? Impressive. Simon
Re: lvalue cast warnings
On Fri, 29 Aug 2003, Andy Dougherty wrote: On a fresh checkout today, my Solaris C compiler issued the following warnings. If memory serves, there are other compilers that don't like lvalue casts as well. lcc tcc to name two; only with these, it's an error, not just a warning. Simon
Re: [perl #23284] [PATCH] Some updates to .cvsignore
On Mon, 11 Aug 2003, Jürgen Bömmels wrote: Hi, I did some experiments in the languages directory and now there are many files unknown to cvs. This patch fixes them. (This patch is created with cvsutils so you need to cvs add some of the files) Thanks, applied. Simon
Re: Packfile stuff
On 11 Aug 2003, Juergen Boemmels wrote: Dan Sugalski [EMAIL PROTECTED] writes: At 11:48 PM +0200 8/5/03, Leopold Toetsch wrote: Simon Glover wrote: parrot_compiler: No make test: make fails with missing 'open_i_s' (integer file descriptors are removed) This is a two-line fix; I've already commited it. (It still doesn't actually work, mind, as it makes Parrot segfault when I try to compile the sample PASM file, but I don't have time to investigate this at the moment). Simon
Re: perl - $(PERL) in makefiles/root.in
On Sun, 10 Aug 2003, Jim Cromie wrote: following corrects 1 remaining use of bare 'perl' to match all the other uses of $(PERL) Thanks, applied. Simon
Re: Packfile stuff
On Tue, 5 Aug 2003, Dan Sugalski wrote: At 12:18 PM +0200 8/5/03, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Here's some stuff we need to add to the packfile format and the sub header to get things ready for more language work. First: any changes here imply, that assemble.pl/disassemble.pl will seeze to work. So first step would be: grep the tree and remove all traces of these programs. I'm fine with assemble.pl in its current incarnation going away. I'd prefer to keep disassemble.pl, or at least *some* disassembler, around. I'm not sure if we want to build disassembly functionality into Parrot. (Mainly for size of executable issues--I'm fine with shipping a disassembler as part of the parrot kit, as well as having the disassembler as a loadable library) Well, there's disassemble.c, which pdb uses; does that do everything that you want? Simon
Perlarray internals
In the get_integer_keyed_int method in perlarray.pmc, we're cuurently
doing:
INTVAL get_integer_keyed_int (INTVAL key) {
if (key = DYNSELF.elements() || key -DYNSELF.elements()) {
PMC* temp = undef(INTERP);
return VTABLE_get_integer(INTERP, temp);
}
else
return SUPER(key);
}
(with similar code for get_number_keyed_int and get_string_keyed_int).
In other words, if we're referencing an element outside the current
array bounds, then we call undef(), which creates a new PerlUndef PMC,
and we then use this _solely_ to call get_integer on, despite the fact
that we _know_ that the result is going to be zero. This seems
remarkably inefficient. Is there any good reason not to simply rewrite
the above as:
INTVAL get_integer_keyed_int (INTVAL key) {
if (key = DYNSELF.elements() || key -DYNSELF.elements()) {
return 0;
}
else
return SUPER(key);
}
--
Simon
Re: [perl #23276] Prefixing #define names
On Mon, 11 Aug 2003, Vladimir Lipskiy wrote: OK. I'm starting out a prefixing story and here is CHAPTER I. The HAS_HEADER_ defines. Thanks, applied. Simon
Re: [perl #23252] [PATCH] IO seek/tell refactoring
Thanks, applied. Simon
Re: Packfile stuff
On Tue, 12 Aug 2003, Leopold Toetsch wrote: Juergen Boemmels [EMAIL PROTECTED] wrote: what still fails is pbc2c.pl (This needs Parrot::Packfile, which can only read format 0 (old assemble.pl) bytecodes). This is obsoleted by Daniel's exec patches. Don't we need to keep this for building native executables on platforms where the JIT/exec stuff doesn't work (eg. Win32)? Simon
Re: io_win32.c warnings
On Sun, 10 Aug 2003, Vladimir Lipskiy wrote: The attached patch removes these warnings: io/io_win32.c(312) : warning C4028: formal parameter 4 different from declaration io/io_win32.c(312) : warning C4029: declared formal parameter list different from definition io/io_win32.c(358) : warning C4113: 'long (__cdecl *)(struct Parrot_Interp *,struct _ParrotIOLayer *,struct _ParrotIO *,long ,long ,long )' differs in parameter lists from 'long (__cdecl *)(struct Parrot_Interp *,struct _ParrotIOLayer *,struct _ParrotIO *,__int64 ,long )' Thanks, applied. Simon
Re: perlnum.pmc
On Thu, 7 Aug 2003, Benjamin Goldberg wrote: Shouldn't the get_number() method use string_from_num, instead of calling sprintf/snprintf? I've just tried this, and a number of tests break. There seem to be two main reasons. Firstly, some tests were assuming that stringified PerlNums would always include six digits following the decimal point, including trailing zeros; in other words, 1.1 would be printed as 1.10 It seems unwise to rely on this being the case (particularly since the tests in question are generally of arithmetic ops, and not of the sprintf system), so I've tweaked the tests slightly to avoid this particular issue. The second problem is that string_to_num doesn't seem to create strings with sufficient precision in some cases. For instance: new P0, .PerlNum set P0, 1234.5678911 print P0 print \n end prints: 1234.57 while the corresponding version using FLOATs prints: 1234.567891 NB The problem does seem to arise at the stage where the string is created for printing, since: new P0, .PerlNum set P0, 1234.5678911 sub P0, 1234 print P0 print \n end prints: 0.567891 Anyway, the list of tests that fail is: Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/arithmetics.t2 512402 5.00% 25 29 t/pmc/perlstring.t1 256171 5.88% 1 t/pmc/pmc.t 7 1792897 7.87% 31-32 48-49 85-87 20 subtests skipped. Simon
Re: This Week's Summary
On Mon, 11 Aug 2003, Piers Cawley wrote: Matt Fowles [EMAIL PROTECTED] writes: Piers Cawley wrote: I want a Ponie! I promise that, as development of Ponie (the port of Perl 5 to Parrot) accelerates you'll see a summary of Ponie activity in this summary as well. However, almost all the traffic on the [EMAIL PROTECTED] mailing list has been about fighting Subversion. However, Arthur did post a mini status update at the end of July http://xrl.us/o2s -- Status report I am having trouble following this url. Is there another? Ah... bugger. I thought ponie-dev got gatewayed through to news and picked up by google in the same way as the perl6 lists. I'm not sure where the archive might be. There's one on the perl.org server: http://nntp.x.perl.org/group/perl.ponie.dev Simon
Re: [perl #23252] [PATCH] IO seek/tell refactoring
Thanks, applied. Simon
Re: We *need* this op! :-)
On Thu, 7 Aug 2003, Jos Visser wrote: Accompanying patch adds the fortytwo op to Parrot, so the following PASM becomes legal: fortytwo I0 print I0 print \n end Example: $ ../parrot test42.pasm 42 Why not just use a macro? # .macro fortytwo (A) #set .A, 42 # .endm # # .fortytwo(I0) # print I0 # print \n # end Simon
Re: [perl #23271] [PATCH] Configure on cygwin
On Sun, 10 Aug 2003, Lars Balker Rasmussen wrote: The problem with Configure on cygwin was fairly simple - cygwin's perl has been compiled with -lutil, which is not in the standard distribution. A simple fix to the hints file makes parrot compile on cygwin and mostly complete the test-suite. (5 tests failed, 10 subtests). Thanks, applied. Simon
Re: [perl #23218] [PATCH] Description of more variants in docs/dev/infant.dev
Thanks, applied (with a few typographical tweaks by me). Simon
Re: JIT bug with restoretop
On 3 Aug 2003, Luke Palmer wrote: This fix has worked fine with JIT until now, so I suspect the problem is elsewhere. Bug confirmed here (although I need a slightly longer string to trigger it). Here's a stacktrace: --- Program received signal SIGSEGV, Segmentation fault. 0x0809c215 in Parrot_exec_add_text_rellocation (obj=0x50, nptr=0x820c94c , type=2, symbol=0x815ab88 interpre, disp=-4) at exec.c:233 233 new_relloc = mem_sys_realloc(obj-text_rellocation_table, (gdb) bt #0 0x0809c215 in Parrot_exec_add_text_rellocation (obj=0x50, nptr=0x820c94c , type=2, symbol=0x815ab88 interpre, disp=-4) at exec.c:233 #1 0x080a9dbc in Parrot_jit_begin (jit_info=0x8209960, interpreter=0x819ed98) at include/parrot/jit_emit.h:2520 #2 0x080a6919 in build_asm (interpreter=0x819ed98, pc=0x82098e8, code_start=0x82098e8, code_end=0x8209920, objfile=0x0) at jit.c:1020 #3 0x0806169d in runops_jit (interpreter=0x819ed98, pc=0x82098e8) at interpreter.c:438 #4 0x080619b9 in runops_int (interpreter=0x819ed98, offset=0) at interpreter.c:591 #5 0x08061a1b in runops_ex (interpreter=0x819ed98, offset=0) at interpreter.c:607 #6 0x08061b1d in runops (interpreter=0x819ed98, offset=0) at interpreter.c:643 #7 0x080d5089 in Parrot_runcode (interpreter=0x819ed98, argc=1, argv=0xb39c) at embed.c:377 -- Simon
Re: JIT bug with restoretop
On Sun, 3 Aug 2003, Daniel Grunblatt wrote: On Sunday 03 August 2003 15:27, Simon Glover wrote: On 3 Aug 2003, Luke Palmer wrote: This fix has worked fine with JIT until now, so I suspect the problem is elsewhere. Bug confirmed here (although I need a slightly longer string to trigger it). Here's a stacktrace: I couldn't reproduce it here, but from your bt I supposed that jit_info-objfile was getting something (!= NULL) while running under jit, as it was not initialized correctly, so I fixed that. Could you confirm if the bug's still there? No, that seems to have fixed it. Simon
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: Search for win32 developer
Thanks, applied. Simon
