Re: imcc concat and method syntax
Melvin Smith [EMAIL PROTECTED] wrote: foo.baz is a method or member access foo . baz is concatenation So it is now. CONCAT requires whitespace on either side. -Melvin leo
[CVS ci] more PIR syntax improvements
PIR did parse since quite a time instructions like: $I0 = defined $P0[0] $P1 = clone $P2 but these were handled with explicite rules. And I found me often writing: len = length $S0 which wasn't a valid syntax. I've now tossed the special handling of defined and clone. Instead PIR allows now generally to write lhs = PARROT_OP args so these instructions: $I0 = defined a $I0 = defined a[0] b = clone a $I0 = length s $N0 = sin 0 $I0 = can $P0, puts $I0 = isa $P0, scalar are now (amongst many more) valid PIR syntax. There are currently no checks, if this instructions is something meaningfull too. It's just converted to PARROT_OP lhs[, args] So you can write: $I0 = add 10, 20 or even: .sub _main $P0 = find_global _s $P0 = invokecc $S0 = done\n $S0 = print end .end .sub _s print in sub\n P1 = invoke .end where it really gets ugly. We could of course limit this syntax to more useful constructs. leo
Re: [BUG] can not use op names as sub/method name
Jens Rieks [EMAIL PROTECTED] wrote: Hi, On Saturday 13 March 2004 07:28, Leopold Toetsch wrote: Jens Rieks [EMAIL PROTECTED] wrote: .sub open method Or, maybe .sub foo method as an alternative syntax? This would allow other characters than now in sub names, too. I've now allowed PARROT_OPs after a .sub, so .sub open method or such is valid. I don't know, if we need a string there too as alternative syntax. jens leo
Re: More object stuff
Dan Sugalski [EMAIL PROTECTED] wrote: ... --should we have the base object system participate in multimethod dispatch? That is, if someone does an: add P1, P2, P3 and P2 is a parrot object, should that add vtable method automatically redispatch to MMD if the vtable method can't be found in P2's class hierarchy? Could be useful, sometimes. But why would one write a mathematical class that then uses default addtion? Adding two Dogs isn't too meaniningful either and it gives normally 10 more or so. What about: newclass P10, Dog mmd_dispatch P10, __add which then points the vtable slot of CDog::add to MMD. leo
Re: Classes and metaclasses
On 03/13/04 Mark Sparshatt wrote:
One difficulty is when calling class methods some languages require that
you provide the class object as the receiver (Ruby and c# do this) while
some languages let you use an instance of the class as the receiver
(Java does this)
I think you're confusing what it looks like and what it does.
When designing a VM such as parrot it's very important to keep the two
things separate.
What it looks like is the realm of the compiler. The compiler maps
from the language syntax to the execution capabilities provided by the
virtual machine and runtime. Even if from the syntax point of view
it looks like static methods in C# require the class name to invoke
them, this doesn't mean a 'class object' is involved at all. Same with
java: if it's allowed to call a static method with the syntax:
instance_of_class.static_method_of_class ();
it doesn't mean instance_of_class is involved in the call: it isn't.
The compiler will find static_method_of_class and emit a direct call to it,
possibly discarding instance_of_class completely (unless it's an
expression with possible side effects, but in any case, the instance
object is not involved in the call).
What it does is the realm of the virtual machine or runtime.
The virtual machine needs to provide enough power for the compiler
to be able to implement its specific languuage semantics (either
directly or through helper methods/libraries). Of course, if the VM
provides more than one way to do it, the compiler should try to use the
more efficient one. For example, on the CLR you can call a static method
in at least three ways:
* directly from IL code (same overhead as a direct C function call)
* using reflection (provides lots of flexibility, since it can
be done at runtime, arguments are converted to the correct
types if needed etc. Of course the price to pay is slowness...)
* delegate invocation: some of the benefits of a reflection call
with an overhead just slightly bigger than a direct call
I think parrot should provide two mechanisms: a fast one for languages
that can take advantage of it and a more dynamic one for use by the
other implementations. Of course the main issue becomes: what happens
when two different langauges with different semantics need to call each
others's methods? This is the main issue that parrot faces if it is to
become a real VM for dynamic languages, but sadly this problem space has
not been addressed yet, mostly because of the lack of real langauge
implementations (but the pie contest is rapidly approaching and it's
likely to be a big driving force:-) The PHP compiler is also progressing
nicely from what I hear, so it's likely that by summer some people
will have to actually deal with inter-languages calls).
Some of the call issues are present already: I don't remember if it has
been addressed somewhere already, but how does parrot deal with
perl (arguments passed in the @_ array) with the parrot call convention
that passes some args in registers and some not?
For example, consider:
sub my_func {
my ($arg1) = shift;
do_something (@_);
}
When it is called with:
my_func (1);
my_func (1, 2, 3, 4, ..., 11, 12, 13);
my_func (@an_array);
Since the call has no prototype some args go in registers and some in
the overflow array. In the first case my_func will need to build the @_
array from the first PMC arg register. In the second case the compiler
needs to create a temporary array and put some args in registers and
some in the overflow temp array. When called, my_func needs to gather
all the args and put them in the @_ array.
In the third case the compiler needs to discard the passed array, put
some of the elements in registers and some in a newly created temp array
(the overflow array) unless it can play tricks by modifying @an_array
(but this is only safe when @an_array is a temporary list, such as one
returned from sort etc.). Again, at the method prolog, my_func needs to
reconstruct the argument array @_ from args in registers and in the
overflow array. Some of the shuffling could be avoided if @_ becomes
a magic array which keeps some data in registers and some in the
overflow array, but this has many issues itself, since the first
arguments are in registers which could be overwritten at the first call.
So it looks like there is already a lot of complexity and memory
shuffling: has anyone generated the code (maybe by hand) to implement in
parrot something like the above scenario and measured the speed
characteristics vs the equivalent perl5/python code (I don't know,
though, if in python the call semantics are similar to the perl5 ones...)?
Thanks.
lupus
--
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
Re: Classes and metaclasses
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: The one question I have is whether we need to have a call class method operation that, when you invoke it, looks up the class of the object and redispatches to it, or whether class methods are just methods called on class objects. The terms are misleading a bit here. - a ParrotClass isa delegate PMC - a ParrotObject isa ParrotClass ^^ That definitely seems to be the wrong way 'round. - a HLL class isa Parrotclass and a low-level PMC object - a HLL object isa all of above
[perl #27609] [PATCH] Fix illegal CFLAGS
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #27609]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27609
While checking out ponie-2, I got stuck building parrot. The
following patch papers over the problem, but I wonder why
makefiles.pl is altering CFLAGS. Shouldn't that information
logically be in CFLAGS.in?
diff -r -u parrot/config/gen/makefiles.pl parrot-andy/config/gen/makefiles.pl
--- parrot/config/gen/makefiles.pl Mon Mar 8 19:00:04 2004
+++ parrot-andy/config/gen/makefiles.pl Fri Mar 12 16:43:12 2004
@@ -35,10 +35,13 @@
open(CFLAGS, CFLAGS) or die open CFLAGS: $!;
+ # Why is this here? I'd think this information belongs
+ # in the CFLAGS.in file. -- A.D. March 12, 2004
if (Configure::Data-get('cpuarch') =~ /sun4|sparc64/) {
+ # CFLAGS entries must be left-aligned.
print CFLAGS EOF;
- jit_cpu.c -{-Wcast-align}# lots of noise!
- nci.c -{-Wstrict-prototypes} # lots of noise!
+jit_cpu.c -{-Wcast-align}# lots of noise!
+nci.c -{-Wstrict-prototypes} # lots of noise!
EOF
}
--
Andy Dougherty [EMAIL PROTECTED]
Re: PDD15: per-class attribute offsets
Dan Sugalski wrote: As well as involving much finding of instances, and moving of their attribute values, this isn't thread safe (please excuse my lack of PASM syntax knowledge): Yeah, adding an attribute requires a stop-the-world action, as every object that has the modified class needs to be modified. That's a non-trivial activity. But, even if we stop everything until all objects got their attribute list updated, any offsets previously obtained via Cclassoffset may still be bogus afterwards. And there is no way for the code that holds the offset to know that either. Maybe we should provide a version of Cgetattribute that takes relative offset and the class name/PMC and then make that operation atomic?
[perl #27624] [PATCH] make output from classes/make neat
# New Ticket Created by Matt Fowles
# Please include the string: [perl #27624]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27624
All~
This patch makes the output from classes/make a little neater...
Matt
Index: config/gen/makefiles/classes.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/classes.in,v
retrieving revision 1.15
diff -u -r1.15 classes.in
--- config/gen/makefiles/classes.in 7 Mar 2004 05:45:14 - 1.15
+++ config/gen/makefiles/classes.in 14 Mar 2004 02:45:31 -
@@ -29,7 +29,8 @@
.SUFFIXES: .c .h .pmc .dump $(O)
.c$(O):
- $(CC) $(CFLAGS) ${cc_o_out}$@ -c $
+ @echo 'classes/$'
+ @$(CC) $(CFLAGS) ${cc_o_out}$@ -c $
.pmc.dump:
$(PMC2CD) *.pmc
Re: parrot no longer compiles on win32
Goplat [EMAIL PROTECTED] wrote: ops/sys.ops:169: warning: implicit declaration of function `gmtime_r' ops/sys.ops:170: warning: implicit declaration of function `asctime_r' ops/sys.ops:178: warning: implicit declaration of function `localtime_r' msvcrt doesn't have these functions (it uses thread-local storage to make the traditional functions thread safe) I've moved these functions now all to platform/generic/time.c with a CParrot_ prefix, so that people can implement proper wrappers around in their relevant platform subdir. leo
Re: CPAN Upload: A/AB/ABERGMAN/ponie-2.tar.gz - Ponie Development Release 2
Marcus Holland-Moritz [EMAIL PROTECTED] wrote: One of my modules embeds the ucpp preprocessor, which has a function init_tables(). The same function exists in parrot. Renamed. thanks for testing, leo
Re: [perl #27609] [PATCH] Fix illegal CFLAGS
Andy Dougherty [EMAIL PROTECTED] wrote: While checking out ponie-2, I got stuck building parrot. The following patch papers over the problem, but I wonder why makefiles.pl is altering CFLAGS. Shouldn't that information logically be in CFLAGS.in? Maybe processing that doesn't provide the needed flexibility. I don't know. Thanks, applied. leo
Re: Classes and metaclasses
Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: The one question I have is whether we need to have a call class method operation that, when you invoke it, looks up the class of the object and redispatches to it, or whether class methods are just methods called on class objects. The terms are misleading a bit here. - a ParrotClass isa delegate PMC - a ParrotObject isa ParrotClass ^^ That definitely seems to be the wrong way 'round. Why? A ParrotClass is responsible for the method dispatch. The ParrotObject inherits that behavior. leo
Re: PDD15: per-class attribute offsets
Oli [EMAIL PROTECTED] wrote: But, even if we stop everything until all objects got their attribute list updated, any offsets previously obtained via Cclassoffset may still be bogus afterwards. And there is no way for the code that holds the offset to know that either. Good point. It seems that after adding attributes to classes with instantiated objects, attribute access can only be done by attribute names with the current scheme. So if a class isn't marked final, attribute access is named only. Maybe we should provide a version of Cgetattribute that takes relative offset and the class name/PMC and then make that operation atomic? When the classoffset is relative the lookup is as expensive as with attribute names (I estimate - the cost of a hash lookup), that's the price of it. leo
Re: Mutating methods
Date: Fri, 12 Mar 2004 12:01:10 -0800 Larry Wall wrote:
It's really a pity that question mark is already so overloaded with
boolean connotations, because
$dog? .bark
would really be the best postfix operator in ASCII for this.
People would probably end up writing
my Dog $spot ?= .new;
as an idiom. And
@array?[.min .. .max]
would be the way to get a topicalized subscript.
some time in the past there was a talk about ... ?? ... :: ... operator being
a combination of two binary : ?? and :: . But I dont know the ruling.
If one factorize trinary ??:: to two binary operators,
?? could act a postfix topicalazer while :: becomes binary
operator :
$a :: $b evaluates to left or right argument according to true/false property of the
_current topic_
something like infix:::($a,$b){ given CALLER::_ { when .true return $a ; return $b }
but it evaluate $b only
if necessary.
Arcadi
Operators that keep going and going...
No, this isn't a complaint about the number of operators in Perl6. ;-) Rather I'd just like to throw out an idea (or two) that occurred to me today somewhere between consciousness and the lack thereof while riding the Skytrain. Obviously the Perl6 community has accepted that it's possible to have variants on operators for things like vectorization. I'm wondering if there would be any desire, need or room for what I have so far thought of as persistent (or Energizer Bunny) operators. The closest analogy I can think of is a spreadsheet formula, where when one cell is altered, any calculations dependent on the data in that cell are recalculated. The other thought that grew from these random neurons firing was whether or not it would be possible to have operators that don't actually do anything until the data they're dependent upon changes. my $a = 0; my $b = 9; $a later= $b; print $a $b\n # 0 9 $b = 10; print $a $b\n # 10 10 Not sure if any of this would be even remotely useful, but this seems to be as good a place as any to discuss wacky ideas that are of dubious value. :-) --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.593 / Virus Database: 376 - Release Date: 20/02/2004
Re: Operators that keep going and going...
[EMAIL PROTECTED] (Carissa) writes: Obviously the Perl6 community has accepted that it's possible to have variants on operators for things like vectorization. I'm wondering if there would be any desire, need or room for what I have so far thought of as persistent (or Energizer Bunny) operators. Given that this is possible in Perl 5 (see Mark-Jason Dominus' forthcoming book) I don't doubt it'll be easy to implement as a Perl 6 module with user-defined operators. -- Facts do not cease to exist because they are ignored. -- Aldous Huxley
Re: [perl #27624] [PATCH] make output from classes/make neat
Matt Fowles [EMAIL PROTECTED] wrote: This patch makes the output from classes/make a little neater... Thanks, applied. leo
[FYI] mainframe inside the notebook
The German computer mag iX 4/2004 (p98 ff) has an article about the hercules[1] emulator. You can run e.g. Linux S/390, Z/OS, OS/390, and such on a x86 box. [1] www.conmicro.cx/Hercules/ leo
Re: [perl #27637] [PATCH] Fix failing Tcl language tests
Bernhard Schmalhofer [EMAIL PROTECTED] wrote: this patch let's the Tcl test suite complete again. There are no new features and the test suite han't been touched. The major change is, that subs are now called like: word_length = __match_close( start_word, buffer ) Thanks, applied. leo
OO version of Data::Dumper, library/onload.imc, library/objects.imc
Hi all, here is ready-for-commit version of Data::Dumper. Not everything is documented yet, but the original interface is still functional. Most of the code is now loaded with load_bytecode, which reduces memory usage if several loaded modules are using the dumper. New/modified things: - the code is loaded with load_bytecode - parrot's new method calling syntax is used - initial support for different output styles Data::Dumper now depends on library/onload.imc and library/objects.imc, both are included in the attached file. onload.imc is a small helper file that calls __onload when it is included, and prints an error message if the including file is directly executed with parrot. objects.imc is a cleaned version of objecthacks.imc... jens dumper.tgz Description: application/tgz
Re: parrot no longer compiles on win32
--- Leopold Toetsch [EMAIL PROTECTED] wrote:
Goplat [EMAIL PROTECTED] wrote:
ops/sys.ops:169: warning: implicit declaration of function `gmtime_r'
ops/sys.ops:170: warning: implicit declaration of function `asctime_r'
ops/sys.ops:178: warning: implicit declaration of function `localtime_r'
msvcrt doesn't have these functions (it uses thread-local storage to make
the traditional functions thread safe)
I've moved these functions now all to platform/generic/time.c with a
CParrot_ prefix, so that people can implement proper wrappers around
in their relevant platform subdir.
leo
Thanks, with that and the attached patch to add said wrappers (and include
time.h) parrot compiles once again.
__
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com--- config/gen/platform/win32/time.c~ Thu Feb 19 09:06:20 2004
+++ config/gen/platform/win32/time.cSun Mar 14 09:03:18 2004
@@ -39,3 +39,35 @@
{
Sleep(seconds * 1000);
}
+
+/*
+ * Parrot_gmtime_r()
+ */
+
+struct tm *
+Parrot_gmtime_r(const time_t *t, struct tm *tm)
+{
+*tm = *gmtime(t);
+return tm;
+}
+
+/*
+ * Parrot_localtime_r()
+ */
+
+struct tm *
+Parrot_localtime_r(const time_t *t, struct tm *tm)
+{
+*tm = *localtime(t);
+return tm;
+}
+
+/*
+ * Parrot_asctime_r()
+ */
+
+char*
+Parrot_asctime_r(const struct tm *tm, char *buffer)
+{
+return strcpy(buffer, asctime(tm));
+}
--- include/parrot/parrot.h~Sat Feb 21 10:09:38 2004
+++ include/parrot/parrot.h Sun Mar 14 08:49:40 2004
@@ -75,6 +75,10 @@
# include sys/time.h
#endif
+#ifdef PARROT_HAS_HEADER_TIME
+# include time.h
+#endif
+
#ifdef PARROT_HAS_HEADER_MATH
# include math.h
#endif
Re: OO version of Data::Dumper, library/onload.imc, library/objects.imc
Jens Rieks [EMAIL PROTECTED] wrote: here is ready-for-commit version of Data::Dumper. Committed (forgot description and credits - sorry). Two tests are failing here t/pmc/dumper.t2 512122 16.67% 8 12 Could be whitespace problem. Thanks for the first OO app, leo
unprefixed global symbols
Leopold Toetsch [EMAIL PROTECTED] wrote: Marcus Holland-Moritz [EMAIL PROTECTED] wrote: One of my modules embeds the ucpp preprocessor, which has a function init_tables(). The same function exists in parrot. Renamed. Another item for the embedding/extending todo list: namespace hygiene. Some thought perhaps needs to go into creating a family of prefixes, and documenting their roles. Mitchell (nipped by mark_hash last week) $ nm ./blib/lib/libparrot.a |egrep ' [TDRC] |\.o:'|grep -v Parrot_ exceptions.o: 0920 T do_exception 0034 T do_panic 086c T handle_exception T internal_exception 0498 T new_c_exception_handler 089c T new_internal_exception 0448 T pop_exception 0220 T push_exception 04d4 T push_new_c_exception_handler 0974 T real_exception 064c T rethrow_c_exception 05d8 T rethrow_exception 04fc T throw_exception global_setup.o: 0018 C class_count_mutex 0004 C class_table_size R data_types 0004 C enum_class_max T init_world 0004 C interpreter_array 0018 C interpreter_array_mutex 0004 C n_interpreters 0004 C run_native interpreter.o: 2c4c T disable_event_checking 0330 T do_prederef 256c T dynop_register 2c70 T enable_event_checking 2c94 T enter_nci_method 0898 T exec_init_prederef 0910 T init_jit 21f0 T interpinfo 0388 C interpre 1ae4 T make_interpreter 09bc T prepare_for_run 1008 T runops 0c64 T runops_int 24cc T sysinfo_i 2514 T sysinfo_s register.o: 00cc T mark_pmc_register_stack 007c T mark_register_stack 0194 T mark_string_register_stack T setup_register_stacks memory.o: 00dc T mem_setup_allocator T mem_sys_allocate 0040 T mem_sys_allocate_zeroed 00c4 T mem_sys_free 0080 T mem_sys_realloc objects.o: packfile.o: 2d28 T PackFile_ConstTable_clear 2dac T PackFile_ConstTable_unpack 2f58 T PackFile_Constant_destroy 2f30 T PackFile_Constant_new 2f70 T PackFile_Constant_pack_size 30a0 T PackFile_Constant_unpack 3584 T PackFile_Constant_unpack_key 33c8 T PackFile_Constant_unpack_pmc 25c4 T PackFile_FixupTable_clear 2a2c T PackFile_FixupTable_new_entry 127c T PackFile_Segment_destroy 1514 T PackFile_Segment_dump 1f44 T PackFile_Segment_new 11fc T PackFile_Segment_new_seg 136c T PackFile_Segment_pack 12c8 T PackFile_Segment_packed_size 144c T PackFile_Segment_unpack 09c4 T PackFile_add_segment T PackFile_destroy 2ca4 T PackFile_find_fixup_entry 0a20 T PackFile_find_segment 394c T PackFile_fixup_subs 0d40 T PackFile_funcs_register 0964 T PackFile_map_segments 0bfc T PackFile_new 0ac8 T PackFile_remove_segment_by_name 06a8 T PackFile_unpack 0f50 T default_dump_header 0004 C exec_const_table 03f4 T mark_const_subs stacks.o: 06bc T get_entry_type 003c T mark_stack 0018 T new_stack 062c T pop_dest 028c T rotate_entries 0144 T stack_destroy 01c8 T stack_entry 014c T stack_height 0654 T stack_peek 0540 T stack_pop 04a0 T stack_push T stack_system_init stack_common.o: T cst_new_stack 0088 T stack_copy 0288 T stack_prepare_pop 0130 T stack_prepare_push 00cc T stack_unmake_COW string.o: 0444 T const_string 16bc T hash_string_equal 028c T string_append 1918 T string_bitwise_and 1ae8 T string_bitwise_or 1d94 T string_bitwise_xor 2040 T string_bool 13cc T string_chopn 145c T string_compare 0c7c T string_compute_strlen 0cc8 T string_concat 0a68 T string_copy 2520 T string_cstring_free 26d4 T string_downcase 26f4 T string_downcase_inplace 179c T string_equal 03ec T string_from_cstring 246c T string_from_int 2498 T string_from_num 05a0 T string_grow 0610 T string_index 024c T string_init 2658 T string_iterator_init 05ec T string_length 0480 T string_make 0cb4 T string_max_bytes 20ec T string_nprintf 09b0 T string_ord 2538 T string_pin 0e6c T string_repeat 10e8 T string_replace 01f4 T string_set 08dc T string_str_index 0f2c T string_substr 2710 T string_titlecase 2730 T string_titlecase_inplace 24c8 T string_to_cstring 21ac T string_to_int 21dc T string_to_num 0a88 T string_transcode 25b0 T string_unpin 2698 T string_upcase 26b8 T string_upcase_inplace sub.o: 0024 T cow_copy_context 0ea0 T lexicals_mark 0168 T mark_context 071c T new_closure 0790 T new_continuation 07f8 T new_coroutine 07c4 T new_ret_continuation 08d4 T new_ret_continuation_pmc 06a0 T new_sub 0144 T restore_context T save_context 0ee0 T scratchpad_delete 0d78 T scratchpad_get 0968 T scratchpad_get_current 0e00 T scratchpad_get_index 0aa0 T scratchpad_new 0c20 T scratchpad_store 0cc0 T
Re: Operators that keep going and going...
Carissa writes: The other thought that grew from these random neurons firing was whether or not it would be possible to have operators that don't actually do anything until the data they're dependent upon changes. I should hope that would be possible, since it's possible in Perl 5! See perldoc overload, in the section Really symbolic calculator (near the end). Luke
RE: Operators that keep going and going...
It just goes to show.. the perl community has already thought of everything.. -Original Message- From: Luke Palmer [mailto:[EMAIL PROTECTED] Sent: Sunday, March 14, 2004 12:41 PM To: Carissa Cc: Perl Language Subject: Re: Operators that keep going and going... Carissa writes: The other thought that grew from these random neurons firing was whether or not it would be possible to have operators that don't actually do anything until the data they're dependent upon changes. I should hope that would be possible, since it's possible in Perl 5! See perldoc overload, in the section Really symbolic calculator (near the end). Luke
Re: Classes and metaclasses
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: The one question I have is whether we need to have a call class method operation that, when you invoke it, looks up the class of the object and redispatches to it, or whether class methods are just methods called on class objects. The terms are misleading a bit here. - a ParrotClass isa delegate PMC - a ParrotObject isa ParrotClass ^^ That definitely seems to be the wrong way 'round. Why? A ParrotClass is responsible for the method dispatch. The ParrotObject inherits that behavior. But logically, a Class is an Object, and an object is an *instance* of a class. Surely a class should be responsible for storing and finding method, but some other thing, call it a Dispatcher object (in Smalltalk it's the Interpreter, but we've got one of those already), is responsible for the actual dispatch. By making the dispatcher drive the dispatch sequence you can do nice things like decoupling the method cache from the class itself, just have the dispatcher maintain its own cache. Then when something changes that might invalidate the cache you just tell the dispatcher to flush its cache and carry on; no need to go finding every affected class and having them flush their caches. Having a dispatcher object helps with multimethod dispatch too of course (and where are you going to stick your multimethod lookup cache if you *don't* have a dispatcher object). Of course, if you have OO languages that have weird dispatch rules, you might need to have multiple dispatchers hanging around but (I'd argue) you're still better attaching them to classes using composition rather than inheritance.
Re: OO version of Data::Dumper, library/onload.imc, library/objects.imc
Hi,
On Sunday 14 March 2004 18:55, Leopold Toetsch wrote:
Jens Rieks [EMAIL PROTECTED] wrote:
here is ready-for-commit version of Data::Dumper.
Committed (forgot description and credits - sorry).
Two tests are failing here
t/pmc/dumper.t2 512122 16.67% 8 12
Could be whitespace problem.
Hmm... no idea what went wrong. I've attached the whole file...
Thanks for the first OO app,
leo
jens
#! perl -w
# Copyright: 2001-2003 The Perl Foundation. All Rights Reserved.
# $Id: dumper.t,v 1.7 2004/03/14 17:52:38 leo Exp $
=head1 NAME
t/pmc/dumper.t - Data Dumping
=head1 SYNOPSIS
% perl t/pmc/dumper.t
=head1 DESCRIPTION
Tests data dumping.
=cut
use strict;
use Parrot::Test tests = 12;
# no. 1
output_is('CODE', 'OUT', dumping array of sorted numbers);
##PIR##
.sub _main
.local pmc array
new array, .PerlArray
push array, 0
push array, 1
push array, 2
push array, 3
push array, 4
push array, 5
push array, 6
push array, 7
push array, 8
push array, 9
_dumper( array, array )
end
.end
.include library/dumper.imc
CODE
array = PerlArray (size:10) [
0,
1,
2,
3,
4,
5,
6,
7,
8,
9
]
OUT
# no. 2
output_is('CODE', 'OUT', dumping unsorted numbers);
##PIR##
.sub _main
.local pmc array
new array, .PerlArray
push array, 6
push array, 1
push array, 8
push array, 3
push array, 2
push array, 9
push array, 7
push array, 4
push array, 0
push array, 5
_dumper( array, array )
end
.end
.include library/dumper.imc
CODE
array = PerlArray (size:10) [
6,
1,
8,
3,
2,
9,
7,
4,
0,
5
]
OUT
# no. 3
output_is('CODE', 'OUT', dumping sorted strings);
##PIR##
.sub _main
.local pmc array
new array, .PerlArray
push array, alpha
push array, bravo
push array, charlie
push array, delta
push array, echo
push array, foxtrot
push array, golf
push array, hotel
_dumper( strings, array )
end
.end
.include library/dumper.imc
CODE
strings = PerlArray (size:8) [
alpha,
bravo,
charlie,
delta,
echo,
foxtrot,
golf,
hotel
]
OUT
# no. 4
output_is('CODE', 'OUT', sorting unsorted strings);
##PIR##
.sub _main
.local pmc array
new array, .PerlArray
push array, charlie
push array, hotel
push array, alpha
push array, delta
push array, foxtrot
push array, golf
push array, bravo
push array, echo
_dumper( strings, array )
end
.end
.include library/dumper.imc
CODE
strings = PerlArray (size:8) [
charlie,
hotel,
alpha,
delta,
foxtrot,
golf,
bravo,
echo
]
OUT
# no. 5
output_is('CODE', 'OUT', dumping different types);
##PIR##
.sub _main
.local pmc array
new array, .PerlArray
push array, 0.1
push array, charlie
push array, 2
push array, hotel
push array, 5
push array, alpha
push array, 0.2
push array, delta
push array, 4
push array, foxtrot
push array, 0.5
push array, 0.4
push array, 1
push array, golf
push array, 0.3
push array, 3
push array, bravo
push array, 0.0
push array, 0
push array, echo
_dumper( array, array )
end
.end
.include library/dumper.imc
CODE
array = PerlArray (size:20) [
0.10,
charlie,
2,
hotel,
5,
alpha,
0.20,
delta,
4,
foxtrot,
0.50,
0.40,
1,
golf,
0.30,
3,
bravo,
0,
0,
echo
]
OUT
# no. 6
output_is('CODE', 'OUT', dumping complex data);
##PIR##
.sub _main
.local pmc hash1
.local pmc hash2
.local pmc hash3
.local pmc array1
.local pmc array2
new hash1, .PerlHash
new hash2, .PerlHash
new hash3, .PerlHash
new array1, .PerlArray
new array2, .PerlArray
_dumper( hash1, hash1 )
S0 = hello
S1 = world
set hash1[S0], S1
_dumper( hash1, hash1 )
S0 = hello2
S1 = world2
set hash1[S0], S1
_dumper( hash1, hash1 )
S0 = hash2
set hash1[S0], hash2
_dumper( hash1, hash1 )
S0 = hello3
S1 = world3
set hash2[S0], S1
_dumper( hash1, hash1 )
S0 = name
S1 = parrot
set hash3[S0], S1
S0 = is
S1 = cool
set hash3[S0], S1
push array1, this
push array1, is
push array1, a
push array1, test
push array1, hash3
S0 = array1
set hash2[S0], array1
_dumper( hash1, hash1 )
end
.end
.include library/dumper.imc
CODE
hash1 = PerlHash {
}
hash1 = PerlHash {
hello = world
}
hash1 = PerlHash {
hello = world,
hello2 = world2
}
hash1 = PerlHash {
hash2 = PerlHash {
},
hello = world,
hello2 = world2
}
hash1 = PerlHash {
hash2 = PerlHash {
hello3 = world3
},
hello = world,
hello2 = world2
}
hash1 = PerlHash {
hash2 = PerlHash {
array1 =
Re: Distributed testing idea
Just for the record, I've abandoned the HTTP::Daemon changes that supported using two unidirectional pipes. Given what I've learned, I believe the HTTP protocol precludes that mode. The problem is reading some types of response messages. When using sockets, the server closes the socket after a sending a response without a Content-Length field. The resulting EOF allows the client to detect that the message is complete. With persistent, unidirectional pipes an EOF is not an option. Now it might be possible to rely on a blank line to indicate the header is complete. However, I see no way to enforce that so I am not going to try. Scott P.S. Btw, I've switched to Net::Jabber for this IPC problem. Thanks to whoever mentioned it, it rocks! On Sun, 22 Feb 2004 19:05:02 -0600, Scott Bolte wrote: On Sun, 22 Feb 2004 16:13:01 +, Tim Bunce wrote: Now I do agree the HTTP protocol is worth using for managing the flow of data. I run HTTP over ssh myself. (I modified HTTP::Daemon to use two unidirectional pipes instead of a single, bidirectional socket.) Has (will) that be included in future releases? Yes. I plan on submitting the changes back after the bits have a chance to dry. I want to advance my current project to the point where I can stress-test the HTTP::Daemon and UserAgent modifications before I submit the changes. I'll subscribe to the libwww mailing list since that seems to be the right forum for posting the changes. If you want a copy of the HTTP code as-is just drop me a line. Scott
[PROPOSED PATH] Clean Up Compiler Warnings (Linux PPC)
Hi there, The attached patch (mostly for discussion, not applying) cleans up three compiler warnings on Linux PPC. These are all related to implicitly declared functions. My solution may not be the best approach, but it works for me. In particular, the posix_memalign() manpage states: Everybody agrees that posix_memalign() is declared in stdlib.h. In order to declare it, glibc needs _GNU_SOURCE defined, or _XOPEN_SOURCE defined to a value not less than 600. I'm also seeing some large integer truncation errors, but they're beyond my ability today. Warnings file attached. -- c Index: include/parrot/parrot.h === RCS file: /cvs/public/parrot/include/parrot/parrot.h,v retrieving revision 1.86 diff -u -u -r1.86 parrot.h --- include/parrot/parrot.h 14 Mar 2004 18:11:20 - 1.86 +++ include/parrot/parrot.h 15 Mar 2004 02:51:12 - @@ -29,6 +29,7 @@ #include parrot/config.h /* ANSI C89 headers */ +#define _XOPEN_SOURCE 600 #include stdlib.h #include stdio.h #include errno.h Index: jit/ppc/jit_emit.h === RCS file: /cvs/public/parrot/jit/ppc/jit_emit.h,v retrieving revision 1.35 diff -u -u -r1.35 jit_emit.h --- jit/ppc/jit_emit.h 21 Feb 2004 10:58:58 - 1.35 +++ jit/ppc/jit_emit.h 15 Mar 2004 02:51:12 - @@ -833,12 +833,10 @@ r22, r23, r24, r25, r26, r27, r28, r29, r30, r31, r1, r2, r3, r4, r5, r6, r7, r8, r9, r10 }; -#ifdef __IBMC__ - void ppc_flush_line(char *_sync); void ppc_sync(void); -#else +#ifndef __IBMC__ void ppc_flush_line(char *_sync) In file included from src/jit_cpu.c:46: include/parrot/jit_emit.h: In function `Parrot_jit_begin': include/parrot/jit_emit.h:639: warning: large integer implicitly truncated to unsigned type include/parrot/jit_emit.h: In function `Parrot_jit_normal_op': include/parrot/jit_emit.h:668: warning: large integer implicitly truncated to unsigned type include/parrot/jit_emit.h: In function `Parrot_jit_cpcf_op': include/parrot/jit_emit.h:683: warning: large integer implicitly truncated to unsigned type include/parrot/jit_emit.h: In function `Parrot_jit_restart_op': include/parrot/jit_emit.h:716: warning: large integer implicitly truncated to unsigned type src/jit_cpu.c: In function `Parrot_end_jit': src/jit_cpu.c:63: warning: large integer implicitly truncated to unsigned type src/jit_cpu.c: In function `Parrot_branch_i_jit': src/jit_cpu.c:78: warning: large integer implicitly truncated to unsigned type In file included from src/exec.c:27: include/parrot/exec_dep.h: In function `Parrot_exec_cpcf_op': include/parrot/exec_dep.h:51: warning: large integer implicitly truncated to unsigned type src/exec_cpu.c: In function `Parrot_end_exec': src/exec_cpu.c:64: warning: large integer implicitly truncated to unsigned type src/exec_cpu.c: In function `Parrot_branch_i_exec': src/exec_cpu.c:79: warning: large integer implicitly truncated to unsigned type
Re: parrot no longer compiles on win32
Goplat [EMAIL PROTECTED] wrote: --- Leopold Toetsch [EMAIL PROTECTED] wrote: Goplat [EMAIL PROTECTED] wrote: ops/sys.ops:169: warning: implicit declaration of function `gmtime_r' ops/sys.ops:170: warning: implicit declaration of function `asctime_r' ops/sys.ops:178: warning: implicit declaration of function `localtime_r' msvcrt doesn't have these functions (it uses thread-local storage to make the traditional functions thread safe) I've moved these functions now all to platform/generic/time.c with a CParrot_ prefix, so that people can implement proper wrappers around in their relevant platform subdir. Thanks, with that and the attached patch to add said wrappers (and include time.h) parrot compiles once again. Thanks, applied. leo
