Re: Release doc tasks
* Michael Scott ([EMAIL PROTECTED]) [040220 10:35]: One thing that would help is if people ran perl tools/docs/write_docs.pl -d -s Runs fine on my box: interactionmac parrot $ uname -a Linux interactionmac.physics.uq.edu.au 2.4.19-r6 #7 Tue Apr 22 16:54:53 EST 2003 ppc 740/750 GNU/Linux interactionmac parrot $ perl -v This is perl, v5.8.0 built for powerpc-linux Copyright 1987-2002, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page. Later Paul -- [EMAIL PROTECTED] Department of Physics University of Queensland St Lucia Brisbane Queensland 4072 Australia Quantum Mechanics: the dreams stuff is made of.
[perl #27095] [PATCH] Corrections to memory handling for win32/exec.c
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #27095] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27095 The following corrects my poor memory handling pointed out by mrnobo1024 at news://nntp.perl.org/perl.perl6.internals/21454 exec.diff Description: Binary data
Feature freeze
You knew it already, but just to make sure ... - No new feature checkins - Object patches are fine - Tests, bug fixes, docu updates, and such are more then welcome Release date is still considered to be Feb, 29th. *If* objects need some more days to settle, release will be on Feb, 30th (that is the date, when objects are usable ;) WRT release name: Piers has proposed The Leaping Kakapo (whatever that is:) We could also name it The Leaping Aoudad. leo
Re: [perl #27057] Let OrderedHash store STRING and FLOATVAL
Bernhard Schmalhofer [EMAIL PROTECTED] wrote:
This patch adds the methods 'get_number_keyed', 'set_string_keyed' and
'set_number_keyed' to
the OrderedHash PMC.
Thanks, applied.
The method 'set_string_keyed_str' is also included, but I can't figure out
when it
will be called.
Its only usable internally. Opcodes use {g,s}et_string_keyed, which just
verify and extract a string from the contant key.
CU, Bernhard
leo
Re: [perl #27095] [PATCH] Corrections to memory handling for win32/exec.c
[EMAIL PROTECTED] (via RT) wrote: The following corrects my poor memory handling pointed out by mrnobo1024 at news://nntp.perl.org/perl.perl6.internals/21454 Thanks, applied, leo
native PBC issues
First of all its of course my fault. This whole stuff is vastly untested and it makes my brain hurt. I've cleaned up a bit and committed some changes, but this might still all be wrong. So to get that running, people please submit native_pbc test files from 64-bit machines and from big-endian architectures. Please follow the instructions in t/native_pbc/*.t and commit test files with -kb. Reading foreign PBC isn't number 1 priority yet, but it should work some time. Thanks, leo
Re: [CVS ci] PLATFORMS
At 8:02 PM -0800 2/24/04, Robert Spier wrote: After a bit of self-education on the CVS FAQ, I've come to the conclusion that renaming (delete/add) PLATFORMS to PLATFORMS.txt is the best way to solve this. Better it get fixed in CVS. There could be more errors of this kind. Confused. What would you like me to do? Can you delete the directory entirely from CVS? Also. cvs update -dP should work just fine for this. at least it does for me. Unless -P doesn't work properly on case-insensitive filesystems. It doesn't work properly for this in case-insensitive file systems. It tries doing directory things with platforms, which is at that point PLATFORMS, which isn't at all a directory, and CVS dies with a platforms not a directory error. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Feature freeze
Leopold Toetsch wrote: WRT release name: Piers has proposed The Leaping Kakapo (whatever that is:) We could also name it The Leaping Aoudad. A Kakapo is a flightless night parrot: http://www.kakapo.net/en/. So leaping Kakapo does make a kind of sense. kaka is the Maori word for parrot. Po must be Maori for night. The mountain kaka is carnivorous. It has been known to attack and kill lambs and pigs. Kakapo is also a combination of kaka and pooh. -Which are words loaded with other meanings... In American English (at least), kaka is childish slang for shit as is poo. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Need some help with object tests
If we're going to hit the February 30th release, I'm gonna need a little help. At the moment I'm most of the way through getting objects done. And, amazingly enough, there's stuff to do that I'm not bottlenecking on. Specifically the object tests. PDD 15, as it stands in the repository, documents the ops as they either do or will exist. I'm not going to change that, at least not now. Probably not ever, really. We have a reasonably extensive set of tests for objects, unfortunately I've massively broken them all with the changes to the intruction set. What I need is for someone (or someones) to go through and patch up the tests to use the new, Officially Blessed(tm) object ops. Some of the tests will fail right now, as (for example) attribute inheritance doesn't work and the op to actually get a class' attribute offset doesn't exist yet, but it will, so... This'd be a good time to dig into things. It's also probably the last chance for someone to try this and point out where things are horribly deficient. (Note that this isn't in reference to the deficiencies Mike Wallace is pointing out--that's separate, and something I've unfortunately put aside for the moment until this piece of functionality gets released. Sorry, Mike, but I've not forgotten!) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Feature freeze
Garrett Goebel [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: WRT release name: Piers has proposed The Leaping Kakapo (whatever that is:) We could also name it The Leaping Aoudad. A Kakapo is a flightless night parrot: http://www.kakapo.net/en/. So leaping Kakapo does make a kind of sense. Thanks for the explanation. So 0.1.0 got a name ... leo
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
Re: Need some help with object tests
At 11:59 AM -0500 2/25/04, Simon Glover wrote: 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? I hadn't planned on putting that in for this round. I've been working under the assumption that a class' code knows the details about its part of an object, and all the other parts belonging to other classes are hidden from view. Adding in some introspection capabilities wouldn't be a bad thing, certainly, though we'll need to figure out how to gateway to non-parrotclass-based objects at some point. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Need some help with object tests
On Wed, Feb 25, 2004 at 11:59:21AM -0500, Simon Glover wrote: : : 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? From the language point of view that would be a method call on the metaclass instance. Of course, maybe *that* method needs a special opcode to get at the real metaclass data... Larry
Re: addattribute bug
At 12:23 PM -0500 2/25/04, Simon Glover wrote: 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? Good question, though I'd lean towards a bug. I'm in the middle of some of the attribute stuff, so let me take a look at it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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...
At 1:51 PM -0500 2/25/04, Simon Glover wrote: 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. Relic. 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? Relic. 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? Relic. In all these cases the object will ultimately do a method lookup to see if it has a method in place to do the operation, so you can substitute an object for any other sort of PMC. Attribute access should be only through the attribute API. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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
Object benchmarks?
As I continue to inch ever-closer to things working (down to three failed tests) it'd be cool if we could have some benchmark programs to give things a shakeout to see how our performance looks. (Given that we have no method cache or anything I can see things being... suboptimal :) Anyway, bodging together some tests just of parrot's performance, as well as some comparisons to perl 5 (or ruby, or python... that'd be cool too!) would be a nice thing to see if we're on the right track here or not. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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
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) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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
Objects. Nearly there
We've only two failing tests. Object.t/21 is failing because the test is incorrect (the PMCs aren't copied into the attribute array, they're actually put in there so the same PMC is used over and over) and object.t/22 is, well, tripping a bug of some sort. Hopefully by the time you read this test 22 will be working right. If someone wants to take a shot at 21 in the interim that'd be, well, swell. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Another object bug
At 6:42 PM -0500 2/25/04, Simon Glover wrote: 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? Yes. At least... sorta kinda yes. Everything inside an object's attributes that's outside the range (class_offset .. class_offset+class_attrib_count] is supposed to not be touched. This all assumes that compilers will generate correct code, and at the moment there's no reason, other than for testing, to use absolute offsets--the ops to do it all relatively are there and work. We may hide or otherwise protect these slots in the future--right now I'm happy with it all working as long as you don't poke it too hard. (Many of the functions don't properly check for class or objectness, for example) 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? Yes. That example's wrong and I'll go fix it. 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. D'oh! I'll go fix. Though since classes are supposed to be objects you could argue that it's actually correct, other than the fact that it's wrong. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Ladies and gentlemen, I give you... objects!
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 heavily, I'd much appreciate it. Y'know, we may well make that Feb 30th date after all. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Ladies and gentlemen, I give you... objects!
On Wed, 2004-02-25 at 15:54, 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 heavily, I'd much appreciate it. I'll revise some of the SDL code to use objects instead of pseudo objects. While I'm at it, is there nice IMCC syntactic sugar for making method calls, or do I have to fill in the registers myself? It's quite nice to write: ($I2, $I3) = _some_function_call( $I0, $I1 ) It'd be a shame not to have something similar for methods -- c
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
[PATCH] win98 fixes for imcc/t/syn/file.t, classes/env.pmc, t/pmc/env.t
imcc/t/syn/file.t: has a qx() use 21, and later an (unnecessary) qx() using
single quotes, neither of which the windows 98 shell supports.
classes/env.pmc: used getenv() when it should use Parrot_getenv()
t/pmc/env.t: parrot can't change or delete the PARROT_TMP that this sets so
tests 3, 5, and 6 were failing - added a delete $ENV{PARROT_TMP} after test 2
__
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools--- imcc/t/syn/file.t~ Tue Feb 17 01:38:00 2004
+++ imcc/t/syn/file.t Wed Feb 25 17:54:08 2004
@@ -8,7 +8,7 @@
=head1 SYNOPSIS
-A test script which is suppossed to be called by Test::Harness.
+A test script which is supposed to be called by Test::Harness.
=cut
@@ -23,7 +23,7 @@
my $PERL5 = $PConfig{perl};
##
-open FOO, temp.pasm or die Cant write temp.pasm\n;
+open FOO, temp.pasm or die Can't write temp.pasm\n;
print FOO 'ENDF';
.constant BAR 42
ENDF
@@ -45,7 +45,7 @@
unlink temp.pasm;
##
-open FOO, temp.imc or die Cant write temp.imc\n;
+open FOO, temp.imc or die Can't write temp.imc\n;
print FOO 'ENDF';
.const int BAR = 42
ENDF
@@ -67,7 +67,7 @@
unlink temp.imc;
##
-open FOO, temp.inc or die Cant write temp.inc\n;
+open FOO, temp.inc or die Can't write temp.inc\n;
print FOO 'ENDF';
.const int BAR = 42
ENDF
@@ -148,7 +148,7 @@
# test load_bytecode branches and subs
# write sub2
-open FOO, temp.imc or die Cant write temp.imc\n;
+open FOO, temp.imc or die Can't write temp.imc\n;
print FOO 'ENDF';
.pcc_sub _sub2 prototyped
print sub2\n
@@ -179,7 +179,7 @@
OUT
# write sub2
-open FOO, temp.imc or die Cant write temp.imc\n;
+open FOO, temp.imc or die Can't write temp.imc\n;
print FOO 'ENDF';
.pcc_sub _sub2 prototyped
print sub2\n
@@ -214,7 +214,7 @@
OUT
# write sub2
-open FOO, temp.imc or die Cant write temp.imc\n;
+open FOO, temp.imc or die Can't write temp.imc\n;
print FOO 'ENDF';
.pcc_sub _not_sub2 prototyped
print not sub2\n
@@ -250,7 +250,7 @@
OUT
# write sub2
-open FOO, temp.imc or die Cant write temp.imc\n;
+open FOO, temp.imc or die Can't write temp.imc\n;
print FOO 'ENDF';
.pcc_sub _sub2 prototyped
print sub2\n
@@ -308,7 +308,7 @@
OUT
# write subs
-open FOO, temp.imc or die Cant write temp.imc\n;
+open FOO, temp.imc or die Can't write temp.imc\n;
print FOO 'ENDF';
.pcc_sub _sub1 prototyped
print sub1\n
@@ -344,7 +344,7 @@
# include a non-existent file and catch the error message
my $err_msg;
{
-open FOO, temp.imc or die Cant write temp.imc\n;
+open FOO, temp.imc or die Can't write temp.imc\n;
print FOO 'END_PIR';
# Including a non-existent file should produce an error
.include non_existent.imc
@@ -355,14 +355,22 @@
.end
END_PIR
close FOO;
-$err_msg = qx{$PARROT temp.imc 21}
+open OLDERR, STDERR or die Can't save STDERR\n;
+open STDERR, temp.out or die Can't write temp.out\n;
+system $PARROT temp.imc;
+open FOO, temp.out or die Can't read temp.out\n;
+{ local $/; $err_msg = FOO; }
+close FOO;
+open STDERR, OLDERR or die Can't restore STDERR\n;
+unlink temp.out;
}
# read a non-existent file and catch the error message
my $enoent_err_msg;
{
-my $ENOENT = qx{$PERL5 -e 'open FOO, non_existent.file; print( \$! + 0 )'};
-open FOO, temp.imc or die Cant write temp.imc\n;
+open FOO, non_existent.file;
+my $ENOENT = $! + 0;
+open FOO, temp.imc or die Can't write temp.imc\n;
print FOO END_PIR;
.sub _main
# run a OS command, and get the errmessge for the exit code
--- classes/env.pmc~Sun Feb 22 09:48:42 2004
+++ classes/env.pmc Wed Feb 25 18:12:16 2004
@@ -39,14 +39,14 @@
int free_it = 0;
STRING *retval;
char *val = NULL;
-
+
if (keyname) {
val = Parrot_getenv(keyname, free_it);
string_cstring_free(keyname);
if (val) {
-retval = string_from_cstring(interpreter, val, 0);
+retval = string_from_cstring(interpreter, val, 0);
} else {
-retval = string_from_cstring(interpreter, , 0);
+retval = string_from_cstring(interpreter, , 0);
}
} else {
retval = string_from_cstring(interpreter, , 0);
@@ -67,7 +67,7 @@
void set_string_keyed(PMC* key, STRING* value) {
char *keyname = string_to_cstring(interpreter,
-VTABLE_get_string(interpreter, key));
+VTABLE_get_string(interpreter, key));
char *env_val = string_to_cstring(interpreter, value);
if (keyname env_val) {
Parrot_setenv(keyname, env_val);
@@ -91,20 +91,20 @@
*/
INTVAL exists_keyed(PMC* key) {
- char *keyname = string_to_cstring(interpreter,
- VTABLE_get_string(interpreter, key));
- int free_it;
-
- if (keyname) {
-
UNIMPORTANT in the scheme of things.
On Wed, 25 Feb 2004 10:30:24 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote: [EMAIL PROTECTED] (via RT) wrote: The following corrects my poor memory handling pointed out by mrnobo1024 at news://nntp.perl.org/perl.perl6.internals/21454 Thanks, applied, leo Leo, Now that cvs will let me update my local copy from the server properly. Looking at the my local copy, it has been updated, but the complete source (not just the diffs) have been incorporated TWICE, one below the other. The second time double-spaced? I've check the server end via the web interface and that is fine, so the problem is purely local, but if anyone has encountered this and know how to prevent it, or even just has some suggestions as to what to try, I'm all ears. Sorry to bother you guys with such trivia. Nigel.
Re: [CVS ci] PLATFORMS
Better it get fixed in CVS. There could be more errors of this kind. Confused. What would you like me to do? Please purge the platforms directory on the server. It collides with the PLATFORMS file on these poor pseudo-OS, that have case-insensitive filenames. (There could also still be a directory called hints on the server, it did exist some time ago. If yes please rm it too) *POOF* -R
Re: Another object bug
Dan Sugalski [EMAIL PROTECTED] 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) *Please* don't. Cclassoffset (and attribute access) should by all means start with 0. - Let's hide the internals - If that offset is ever changed, existing code will break - Its ugly We can afford one more instruction ( offset += POD_FIRST_ATTRIB; ) that's just one CPU cycle. leo
Re: Ladies and gentlemen, I give you... objects!
Chromatic [EMAIL PROTECTED] wrote: While I'm at it, is there nice IMCC syntactic sugar for making method calls, or do I have to fill in the registers myself? It's quite nice to write: ($I2, $I3) = _some_function_call( $I0, $I1 ) Not yet. But you could try to prepend one instruction P2 = the_object It'd be a shame not to have something similar for methods Please read Melvins proposal. There will be of course support for it, but not just now. -- c leo
Re: native PBC issues
chromatic wrote: Hm, I'm still not sure where they should go, but here are the integer and number pbc and header files from Linux PPC. No problem, I've sorted these tests in. Thanks, leo
Re: Another object bug
Leopold Toetsch writes: Dan Sugalski [EMAIL PROTECTED] 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) *Please* don't. Cclassoffset (and attribute access) should by all means start with 0. - Let's hide the internals - If that offset is ever changed, existing code will break - Its ugly We can afford one more instruction ( offset += POD_FIRST_ATTRIB; ) that's just one CPU cycle. Agreed. Though I do like the ability to replace the class name PMC currently in slot 0. But then there are a lot of PMCs in a lot of places that I'd like to replace, and the eventual Parrot::B should do that for me. So I vote Yes on offset 0. Luke
