Re: the getting started guide
On Wed, Oct 09, 2002 at 07:17:01PM -0400, Dan Sugalski said: > I'll see about getting some of the internal structures diagrammed > better, which is the only place things are a little dodgy, but that's > otherwise fine. [accidentally sent to Robert Spier ony earlier] Autodia (http://www.droogs.org/autodia/) can automatically create Dia documents - I could hack together some filters to grok Parrot / Perl6 / IMCC / whatever if yer interested. Dependant on spare tuits of course :)
Re: Fw: perl6 operator precedence table
Larry Wall wrote: [...] > Maybe we should ... to mean "and so on forever": > > @a[0...; 0...:10; 0...:100] > > Except then we couldn't use it to mean what Ruby means by it, which > might be handier in real life. No more yada-yada-yada? Brad
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
One first thing I notice while I'm supposed to be doing homework. :-) Wasn't "class MyClass;" supposed to work along the line of Perl5's "package MyClass;" and make everything following that statement the definition of MyClass?
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
Hi,
Many thanks Michael, this is very useful, really. I had lost all the
OO discussion and this document is very helpful.
I really like the part of context transformations, I hope something
like this gets in.
Just a silly note:
> Recipe 1.9: Using Subroutines as Objects
>
> Problem:
> You want to use a subroutine as if it were an object.
>
> Solution:
> Just do it:
> sub mysub { ... };
> my $var = mysub.foo;
>
I think it was said that the way to avoid the ambiguity here is to add
& to sub name.
For example:
my $var = &msyub.foo; # call foo method on &mysub object
my $var2 = mysub.foo; # equivalent to mysub().foo()
Best,
-angel
Delegation syntax
Problem:
You want to use delegation (rather than inheritance)
to add some capabilities of one class or object to
another class or object.
Solution:
Use a PROXY block:
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel;
when 'steer' { $left_front_wheel, $right_front_wheel }
}
...
}
Discussion:
The PROXY block behaves as if the following were
true. The block has a topic. The topic is an object
that represents a method call. This object stringifies
to the name of the method called. The block is called
each time a method call is invoked on the enclosing
class, or an instance of the class. The whens' blocks
are a list of things that are proxies for (ie delegatees
of) the matched call.
Roughly speaking, my idea is to do Damian's Delegation
class dressed using new clothes that look like ones from
the Apos that have come out since he wrote the module
at http://tinyurl.com/1qsk. A longer example follows.
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel;
attr $left_rear_wheel is Wheel;
attr $right_rear_wheel is Wheel;
attr FlyWheel $flywheel .= new;
attr MP3::Player $mp3 .= new;
when 'steer'{ $left_front_wheel, $right_front_wheel }
when 'drive'{ 'rotate_clockwise' => $left_rear_wheel,
'rotate_anticlockwise' => $right_rear_wheel }
when 'power'{ 'brake' => $flywheel }
when 'brake'{ / .*_wheel / }
when 'halt' { 'brake' => SELF }
when /^MP_(.+)/ { sub { $1 } => $mp3 }
when 'debug'{ 'dump' => ATTRS }
}
...
}
or something like this.
--
ralph
Delegation syntax
Problem:
You want to use delegation rather than inheritance to
add some capabilities of one class or object to
another class or object.
Solution:
Use a PROXY block:
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel;
when 'steer'{ $left_front_wheel, $right_front_wheel }
}
...
}
Discussion:
A PROXY block is somewhat analogous to the PRE
block of a sub or method. A PROXY block has, or at
least appears to have, an object that represents the
method call as its topic. The object stringifies to the
name of the method. The whens' blocks are a list of
objects that are to receive the message instead of
the object represented by the enclosing class. (That
part could be done other ways; I had to pick a way,
and did so fairly arbitrarily.)
Generalizing, I can imagine a number of dispatch,
marshalling, etc. related blocks at the class definition
level.
Roughly speaking, my idea is to do Damian's Delegation
class dressed using new clothes that look like ones from
the Apos that have come out since he wrote the module
at http://tinyurl.com/1qsk. A longer example follows. (I've
futzed a few things where I didn't understand Damian's
code or I'm not sure of a perl 6 thing.):
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel;
attr $left_rear_wheel is Wheel;
attr $right_rear_wheel is Wheel;
attr FlyWheel $flywheel .= new;
attr MP3::Player $mp3 .= new;
when 'steer'{ $left_front_wheel, $right_front_wheel }
when 'drive'{ 'rotate_clockwise' => $left_rear_wheel,
'rotate_anticlockwise' => $right_rear_wheel }
when 'power'{ 'brake' => $flywheel }
when 'brake'{ / .*_wheel / }
when 'halt' { 'brake' => SELF }
when /^MP_(.+)/ { sub { $1 } => $mp3 }
when 'debug'{ 'dump' => ATTRS }
}
...
}
--
ralph
Re: Warnings on VC++
Brent Dax wrote: > core_ops.c(19) : warning C4005: 'CONST' : macro redefinition Thanks, for reporting, (hopefully) fix checked in. leo
RE: [perl #17817] [PATCH] Parrot_sprintf-related stuff, part 2
On Wed, 9 Oct 2002, Brent Dax wrote: > Can you try this? > > (at the top of the function...) > va_list *arg = (va_list *) & (obj->data); > (vararg accesses should look like...) > va_arg(*arg, ...); > (no end-of-function assignment should be necessary) > > If that works for you, I'll commit a version that uses it. That works for me, as does the simpler implicit cast va_arg(obj->data, ...); Alas I fear neither one's going to work on PPC systems. As Nicholas Clark pointed out, va_list may be an opaque type, so that even innocent stuff like misc.c's obj.data = args won't necessarily do what we want. (I've redirected this back to p6i in case a PPC user is willing to chip in and help out.) Here's a relevant excerpt from my glibc stdarg() manpage: va_copy An obvious implementation would have a va_list a pointer to the stack frame of the variadic function. In such a setup (by far the most common) there seems nothing against an assignment va_list aq = ap; Unfortunately, there are also systems that make it an array of pointers (of length 1), and there one needs va_list aq; *aq = *ap; Finally, on systems where parameters are passed in regis ters, it may be necessary for va_start to allocate memory, store the parameters there, and also an indication of which parameter is next, so that va_arg can step through the list. Now va_end can free the allocated memory again. To accommodate this situation, C99 adds a macro va_copy, so that the above assignment can be replaced by va_list aq; va_copy(aq, ap); ... va_end(aq); As I read the threads starting around http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-11/msg00803.html (you have to follow both forward and backwards references to get the whole story) the "array of pointers" approach is used on the PPC architecture, so Parrot is definitely going to have to worry about running into this. In light of this, I'm unsure how well your idea of a polymorphic obj->data type is going to work out, though I realize that's a major feature of this implementation. But Sun's compiler's inability to handle the (va_list) cast may well be the least of your worries :-). -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #17817] [PATCH] Parrot_sprintf-related stuff, part 2
On Wed, 9 Oct 2002, Nicholas Clark wrote: > Which reminds me, not sure if this is relevant yet, but there's some or other > platform that p5p encountered that can't simply copy whatever it is the opaque > type va_list expands to there. > > There's a perl5 Configure symbol need_va_copy which indicates whether a > special macro needs to be used. Thanks for the pointer. Now why didn't I think to look there? -- Andy Dougherty [EMAIL PROTECTED]
Re: [INFO] New array base: list.c
Follow up to my announce + some additional notes. list.c checked in + intlist fix + 3 more tests. Leopold Toetsch wrote: > The current implementation of array.pmc is rather inefficient and > limited - and really slow. > > So I rewrote the base routines almost from scratch and have currently a > file named list.c, which I will commit (yep cvs ci, thanks to Dan, Steve > and others, who made this possible) in the next future - if people agree. > > Some features: > > - list.c is based roughly on principles of intlist.c > (chunk based, fast index set/get, push/pop/shift/unshift) > - can handle arrays, no chunk allocation first > - can store packed char, short, int, num, PMC* (void*), ... > - different growing policies: > - growing (min alloc 4 items/chunk -> max 1024 items/chunk > (both are defines but above are good limits in tests) > - or fixed 1024 items/chunk for arrays first accessed > like "set P0[500], I0" > - same speed as intlist, ~double speed for big # (10^6) items > - can handle sparse arrays, saving many MBs for very sparse arrays - list_delete(..., idx, n_items) - list_insert(..., idx, n_items) ... make room for n_items at idx These should it make fairly simple to implement splice(). As mentioned in the file, list.c can emulate intlist.c, so intlist.c users - please - give it a try: just compile/link list instead of intlist. Status: - Runs all intlist tests - insert/delete is only barely tested, this needs definitely more, especially combined and mixed with other operations. If people agree, we could start to base other array classes on list.c, though I'd rather do classes cleanup and keyed access first. Comments welcome, leo
Warnings on Solaris 8, 64-bit ints
Here's my current batch of warnings from a fresh check-out. I haven't checked them out. However, if the casts between pointers and integers are correct and won't overflow, then judicious use of the INTVAL2PTR and PTR2INTVAL macros from parrot.h should silence them. The printf format warnings probably aren't worth worrying about just yet, since Brent is working on redoing that whole system. Summary of my parrot 0.0.8 configuration: configdate='Thu Oct 10 10:16:11 2002' Platform: osname=solaris, archname=sun4-solaris-64int jitcapable=1, jitarchname=sun4-solaris, jitosname=solaris, jitcpuarch=sun4 perl=perl64 Compiler: cc='gcc', ccflags='-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib ', cc_ldflags='', libs='-lsocket -lnsl -ldl -lm' Dynamic Linking: so='.so', ld_shared='-G -L/usr/local/lib', ld_shared_flags='' Types: iv=long long, intvalsize=8, intsize=4, opcode_t=long long, opcode_t_size=8, ptrsize=4, ptr_alignment=4 byteorder=87654321, nv=double, numvalsize=8, doublesize=8 continuation.pmc: In function `Parrot_Continuation_set_integer_native': continuation.pmc:32: warning: cast to pointer from integer of different size coroutine.pmc: In function `Parrot_Coroutine_init': coroutine.pmc:31: warning: cast to pointer from integer of different size coroutine.pmc: In function `Parrot_Coroutine_set_integer': coroutine.pmc:49: warning: cast to pointer from integer of different size coroutine.pmc: In function `Parrot_Coroutine_set_integer_native': coroutine.pmc:53: warning: cast to pointer from integer of different size intqueue.pmc: In function `Parrot_IntQueue_init': intqueue.pmc:92: warning: cast increases required alignment of target type perlhash.pmc: In function `Parrot_PerlHash_get_pmc_keyed': perlhash.pmc:192: warning: passing arg 2 from incompatible pointer type pointer.pmc: In function `Parrot_Pointer_get_integer': pointer.pmc:53: warning: cast from pointer to integer of different size pointer.pmc: In function `Parrot_Pointer_get_number': pointer.pmc:57: warning: cast from pointer to integer of different size sub.pmc: In function `Parrot_Sub_init': sub.pmc:31: warning: cast to pointer from integer of different size sub.pmc: In function `Parrot_Sub_set_integer': sub.pmc:40: warning: cast to pointer from integer of different size sub.pmc: In function `Parrot_Sub_set_integer_native': sub.pmc:44: warning: cast to pointer from integer of different size debug.ops: In function `Parrot_debug_break': debug.ops:96: warning: cast increases required alignment of target type debug.ops:106: warning: cast increases required alignment of target type packfile.c: In function `PackFile_check_segment_size': packfile.c:245: warning: long int format, different type arg (arg 4) packfile.c: In function `PackFile_Constant_destroy': packfile.c:673: warning: long int format, different type arg (arg 4) string.c: In function `string_append': string.c:131: warning: cast to pointer from integer of different size string.c: In function `string_make': string.c:185: warning: assignment discards `const' from pointer target type string.c: In function `string_concat': string.c:425: warning: cast to pointer from integer of different size string.c: In function `string_repeat': string.c:470: warning: cast to pointer from integer of different size trace.c: In function `trace_op_dump': trace.c:84: warning: long int format, different type arg (arg 4) jit.c: In function `build_asm': jit.c:570: warning: cast increases required alignment of target type include/parrot/jit_emit.h: In function `Parrot_jit_bicc': In file included from jit_cpu.c:14: include/parrot/jit_emit.h:319: warning: cast increases required alignment of target type include/parrot/jit_emit.h:326: warning: cast increases required alignment of target type include/parrot/jit_emit.h: In function `Parrot_jit_int_load': include/parrot/jit_emit.h:344: warning: cast increases required alignment of target type include/parrot/jit_emit.h:345: warning: cast increases required alignment of target type include/parrot/jit_emit.h:349: warning: cast increases required alignment of target type include/parrot/jit_emit.h:358: warning: cast increases required alignment of target type include/parrot/jit_emit.h:359: warning: cast increases required alignment of target type include/parrot/jit_emit.h:365: warning: cast increases required alignment of target type include/parrot/jit_emit.h:371: warning: cast increases required alignment of target type include/parrot/jit_emit.h: In function `Parrot_jit_int_store': include/parrot/jit_emit.h:396: warning: cast increases required alignment of target type include/parrot/jit_emit.h:402: warning: cast increases required alignment of target type include/parrot/jit_emit.h: In function `Parrot_jit_float_load': include/parrot/jit_emit.h:426: warning: cast increases required alignment of target type include/parrot/j
Re: [perl #17524] [PATCH] use key functions in packfile
Leopold Toetsch (via RT) wrote: > # New Ticket Created by Leopold Toetsch > # Please include the string: [perl #17524] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=17524 > > > > This patch hides some internals of keys by using the appropriate key > functions in packfile.c. Packfile shouldn't know keys internals. Applied, leo
[CVS ci] perl6 --output
One more from the section missed + left overs: This patch make "perl6 --output file" work as described in perl6 --help. $ time perl6 -o- mops.p6 | ../imcc/imcc -r -- - But above pipe is as fast^Wslow as going via .imc: $ time perl6 -r mops.p6 leo
[PATCH] Perlhash fix & test (was Re: Eliminate padding warnings)
On Wed, 9 Oct 2002, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Simon Glover <[EMAIL PROTECTED]> wrote:
>
> > I've just had a quick look at hash.h (which I should have done in the
> > first place) and you're quite right. Second attempt at a correct patch
> > below.
> >
> > All tests still pass, but this isn't much comfort, as the fact that the
> > preceding patch 'worked' suggests that nothing's actually testing this
> > line of code. I'll see if I can do something to remedy this tomorrow,
> > unless somebody beats me to it.
>
> That looks better, although you can actually get rid of the cast
> once you do that as pmc_val has the right type.
>
OK, third time lucky... the patch below removes the cast as Tom suggests,
and also adds a test case to perlhash.t that exercises the code.
Simon
--- classes/perlhash.pmc.oldWed Oct 9 15:59:29 2002
+++ classes/perlhash.pmcThu Oct 10 11:42:26 2002
@@ -189,7 +189,7 @@ pmclass PerlHash {
if (!nextkey)
return entry->val.pmc_val;
return entry->val.pmc_val->vtable->get_pmc_keyed(INTERP,
- entry, nextkey);
+ entry->val.pmc_val, nextkey);
}
internal_exception(OUT_OF_BOUNDS,
--- t/pmc/perlhash.t.oldThu Oct 10 11:43:29 2002
+++ t/pmc/perlhash.tThu Oct 10 11:46:14 2002
@@ -1,6 +1,6 @@
#! perl
-use Parrot::Test tests => 16;
+use Parrot::Test tests => 17;
use Test::More;
output_is(<<'CODE', <
[PATCH] Removing two-arg ne
On Wed, 9 Oct 2002, Dan Sugalski wrote:
> At 7:42 PM -0700 10/8/02, Steve Fink wrote:
> >Thanks, applied.
> >
> >Who came up with the idea of two-argument ne, anyway? That's kind of
> >bizarre.
>
>
> Definitely bizarre. I think I'd rather not have it, it doesn't make much sense.
Easily done. Patch below removes the ops, plus the relevent tests from
integer.t and number.t
Simon
--- core.ops.oldThu Oct 10 11:57:08 2002
+++ core.opsThu Oct 10 11:57:29 2002
@@ -902,14 +902,6 @@ op eq (in PMC, in PMC, inconst INT) {
-=item B(in INT, in INT)
-
-=item B(in NUM, in NUM)
-
-=item B(in STR, in STR)
-
-=item B(in PMC, in PMC)
-
=item B(in INT, in INT, inconst INT)
=item B(in NUM, in NUM, inconst INT)
@@ -920,38 +912,8 @@ op eq (in PMC, in PMC, inconst INT) {
Branch if $1 is not equal to $2.
-Return address is popped off the call stack if no address is supplied.
-
=cut
-inline op ne (in INT, in INT) {
- if ($1 != $2) {
-goto POP();
- }
- goto NEXT();
-}
-
-inline op ne (in NUM, in NUM) {
- if ($1 != $2) {
-goto POP();
- }
- goto NEXT();
-}
-
-op ne (in STR, in STR) {
- if (string_compare (interpreter, $1, $2) != 0) {
-goto POP();
- }
- goto NEXT();
-}
-
-op ne (in PMC, in PMC) {
- if (! $1->vtable->is_equal(interpreter, $1, $2)) {
-goto POP();
- }
- goto NEXT();
-}
-
inline op ne(in INT, in INT, inconst INT) {
if ($1 != $2) {
goto OFFSET($3);
--- t/op/integer.t.old Thu Oct 10 11:58:24 2002
+++ t/op/integer.t Thu Oct 10 12:00:56 2002
@@ -1,6 +1,6 @@
#! perl -w
-use Parrot::Test tests => 39;
+use Parrot::Test tests => 38;
output_is(< 34;
+use Parrot::Test tests => 33;
use Test::More;
output_is(<
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
On Wednesday, October 9, 2002, at 07:54 PM, Chris Dutton wrote:
> One first thing I notice while I'm supposed to be doing homework. :-)
>
> Wasn't "class MyClass;" supposed to work along the line of Perl5's
> "package MyClass;" and make everything following that statement the
> definition of MyClass?
Yeah, I think so too, but don't know for sure. The "class MyClass"
would mirror "sub" declarations, allowing you to make anonymous
classes, assign properties to classes, etc. The package-style "class
MyClass;" would work, um, just like packages.
One reason I can think of to choose the first instead of the second
would be if you wanted properties (or parent classes!) to be able to
alter the grammar of an individual class, which would be a neat way to
tack different OO zealotry onto a class without enforcing it on others:
class MyClass is wackyGrammar {
...
}
vs.
{
class MyClass;
...
use wackyGrammar;
}
there would be a minor problem because you've already entered the
"grammar" of a class by the time you get to the 'use' . (A hybrid
approach, a packagelike "class MyClass is wackyGrammar;" would also
work, tho.)
In theory, *both* could be made to work with little effort. I think it
depends on how much we want to treat classes like packages, vs. classes
like objects. I arbitrarily chose to put the non-package example in
because it was more likely to provoke counterexamples. ;-)
MikeL
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
On Thursday, October 10, 2002, at 02:33 AM, Angel Faus wrote: > Just a silly note: >> Recipe 1.9: Using Subroutines as Objects > I think it was said that the way to avoid the ambiguity here is to add > & to sub name. Thanks, applied. MikeL
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
On Wed, 9 Oct 2002, Michael Lazzaro wrote: > PLEASE contribute to this document! Email me with suggestions, "yes" > or "no" votes on recipe approaches, info on philosophies or best-guess > syntax, etc., or discuss them here on perl6-language. Very nice. I hope this evolves into a useful perl6 reference. Here are some comments on section 1. Recipe 1.6 my $obj = MyClass.new(...); # synonymous, if ... is empty Yes. my $obj = MyClass(...); This seems to assume that objects have a default method if you treat them like a subroutine. Kinda tcl-ish, but I don't recall anything like this in the apocalypes. my $obj = MyClass; I think $obj would contain a reference to MyClass, not an instance of MyClass. my $obj is MyClass; # similar to above, but autovivifying? This declares $obj as a MyClass, but does not instantiate it. If I recall the discussion on this subject, the preferred syntax was my $obj is Myclass .= new(...); Notice that you still have to explicitly invoke the new method. The "is MyClass" merely prevents you from assigning a non-MyClass value to $obj. The difference between "my $i is int = 3" and "my $obj is MyClass = MyClass.new" is that "3" is already an instance of int. MyClass does not have a textual representation which the compiler will recognize unless you perform some source filtering/lexical rules tricks. The theory about being "autovivified according to the default constructor" is nice, but I think it is not true. If you do not explicitly assign a value to a variable (number, string, or object), it gets a value of undef. Autovivification refers to the automatic creation of the *variable*, not the value. If you use a variable before declaring it, the variable is created with a value of undef. Similarly, if you use a hash or array item which does not exist, it is autovivified with a value of undef. Recipe 1.10 & 1.11 Issue: Or can you? In perl5, class methods are the same as instance methods. The difference is that they receive a class reference as $self instead of an object instance. (perl5 class references happen to be strings, but we won't hold perl6 to that.) So it is not yet known whether class methods in perl6 will have any greater distinction from instance methods than that. Recipe 1.15 I think the thought here was to use the binding operator. my ClassAlias := MyClass; ~ John Williams
Re: Interface lists (was Re: Interfaces)
On Mon, 30 Sep 2002, Michael G Schwern wrote:
: On Tue, Oct 01, 2002 at 01:36:19AM +0100, Simon Cozens wrote:
: > [EMAIL PROTECTED] (Michael G Schwern) writes:
: > > method _do_internal_init ($num) is private {
: >
: > Just thinking aloud, would
: > sub foo is method is private is integer is fungible {
: >
: > be better written as
: > sub foo is fungible private integer method {
: >
: > or not?
It's potentially ambiguous. Here's a bad example, but there are probably
better ones:
my $foo is rw cmp "";
Plus we have to worry about arguments to properties, if we allow
anything other than (). I'd personally like to see some properties
that can take a closure as their argument, but the parser would have
to know that in advance or the "method" property above would slurp
up the subroutine block by accident. Or the sub block itself needs
a keyword.
: How about seperated by commas, like any other list?
:
: method foo is fungible, private, integer {
Is ambiguous:
my ($foo is foo, bar, $bar is baz) = (1,2);
Also, precedence of comma with respect to assignment causes problems.
We may be able to relax this later somehow, but for now we're saying
that "is...is...is..." isn't all that onerous.
To which the only correct reply is, "but...but...but..." :-)
Larry
[parrot] Bindings for other toolkits
Hi, Most systems, have a variety of scripting languages to do stuff in. And almost all the time to make it work with another library you have to specifically port the other library to a specific interpreter. Which means you have separate binding for each language. gtk has separate bindings for perl, python and ruby. Is it possible to avoid this with parrot? Can we make it so that if we port gtk to parrot, any other language can pick it up and use it? You know single binding for gtk, qt, gnome, kde. used by all languages. Is it possible? If so is it a desirable feature? Which brings me to another er... ramble. The documents there are about Parrot aren't very easy for novices. Novice that I am I'd be willing to write a few "really from the ground up how to do stuff" sort of introductory guide to extending languages to Parrot or extending toolkits to it. Er.. anybody else intrested? Can get me going... cheers, Ramesh __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com
Re: the getting started guide
Robert Spier wrote: >>>So the html is canonical and you're converting it to pod? I'm >>>confused. >>> >>> >>I am writing it in my own format. It lets me take notes, write todo >>lists, autogenerate the table of contents and glossary. Then I run it >>through some perl that currently spits out html and almost make pod. >> >> > >Whatever floats your boat. > > My boats a floatin > > >>I found another problem, I just downloaded the newest version of >>WinCVS and it tells me that this port does not support pserver: >>cvs [update aborted]: the :pserver: access method is not supported by >>this port of CVS >>Where can I get a reliable port of cvs for Windows? My old executable >>(v1.11)works fine. >> >> > >This doesn't make any sense. They can't abandon pserver. > >Try going back to the stable 1.2 version of WinCVS. > > I tried 1.3.8.1 Beta8, I will try v1.2. >Are you sure that's the right error message? In the latest 1.3.6 >beta, there is no such error message, but there is this one: > > Yep I cut and pasted it right from my console. I'll download the newest realease and try it again and try v1.2. If someone could tell me where to get cvs for windows without all the GUI that would be great. This is the version info from the one that gave me the error: Concurrent Versions System (CVSNT) 1.11.1.3 (Build 57a) (client/server) Copyright (c) 1989-2001 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVSNT version (Mar 13 2002) Copyright (c) 1999-2001 Tony Hoyle and others see http://www.cvsnt.org CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. Specify the --help option for further information about CVS This is the version info from the one that works: Concurrent Versions System (CVS) 1.11 (client) Copyright (c) 1989-2000 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. Specify the --help option for further information about CVS Thanks, Erik
[perl #17844] [PATCH] Avoid JIT on Sparc with 64-bit INTVAL and 32-bit pointers
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #17844]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17844 >
The combination of 64-bit INTVAL and 32-bit pointers doesn't work with the
Sparc jit.
diff -r -u parrot-orig/config/auto/jit.pl parrot-andy/config/auto/jit.pl
--- parrot-orig/config/auto/jit.pl Thu Aug 8 23:18:04 2002
+++ parrot-andy/config/auto/jit.pl Thu Oct 10 14:02:14 2002
@@ -62,6 +62,10 @@
if (-e "jit/$cpuarch/core.jit") {
$jitcapable = 1;
+if ($cpuarch =~ /sun4|sparc64/ &&
+ Configure::Data->get('intvalsize') > Configure::Data->get('ptrsize')) {
+ $jitcapable = 0;
+ }
}
$jitcapable = $_[0] if defined $_[0];
--
Andy Dougherty [EMAIL PROTECTED]
Re: Interfaces
On Mon, 7 Oct 2002, chromatic wrote: : On Wed, 02 Oct 2002 04:12:44 -0700, Michael G Schwern wrote: : : > I like the "class Vehicle is interface" as a shorthand for declaring every : > method of a class to be an interface. : : Perhaps associating a property with a class can be shorthand for associating : that property with every method of the class? Not in general, since the class needs to be able to have properties apart from from its methods, such as its parent classes. But a particular property such as "interface" could certainly be set up to be distributive over the methods or attributes. Larry
Re: remote generators and a macro language proposal
According to Luke Palmer:
> for ( grep { $_{smoker} and $_{age} > 18 } @Subscribers ) {
> .send($Cigarette_Advertisement)
> }
Hm, would this work too:
for ( grep { .{smoker} and .{age} > 18 } @Subscribers )
{ .send($ciggie_ad) }
? I think .{x} reads better than $_{x} , esp. in parallel with the
method call in the same loop.
--
Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]>
"It furthers one to have somewhere to go."
Re: Interfaces
On Mon, 7 Oct 2002, Andy Wardley wrote: : Nicholas Clark wrote: : > I think that the first syntax : > : > class Car::Q is Car renames(eject => ejector_seat) : > is CD_Player renames(drive => cd_drive); : > : > makes it more clear that I'd like to pick and choose which methods : > the composite object gets from which parent. : : But now you've turned composition back into inheritance, and I think it's : important to be able to distinguish between the two. : : The car is definately not a CD player, it just has one. : : I think we need a more flexible syntax for specifying how interfaces : should be constructed in the case of composed objects, rather than : turning composition into inheritance to avoid the problem. Yes, that's important. If you've got a CD_Player *object*, it doesn't do anyone any good to pretend it's a car *object*. We too often lose sight of the fact that objects should behave like objects. That's what OO really means, after all. OO isn't about inheritance Anyway, I don't see offhand why composition can't simply be done with attributes as it is in C++, especially since attributes manifest as methods outside the class. I don't think $car.cd.eject() is all that horrible to contemplate. Larry
Object Instantiation (Was: Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1)
On Thursday, October 10, 2002, at 11:23 AM, John Williams wrote: > my $obj = MyClass(...); > > This seems to assume that objects have a default method if you treat > them > like a subroutine. Kinda tcl-ish, but I don't recall anything like > this > in the apocalypes. > > my $obj = MyClass; > > I think $obj would contain a reference to MyClass, not an instance > of MyClass. This is an area that's been bothering me for a while now (the Apoc's so far don't directly address it, AFAIK.) Here's why: Instantiating new objects is *darn* frequent in OO programming. And of those objects, a sizable number -- possibly even a majority -- have constructors with no required arguments, e.g. "default constructors". And pretty much every one of those constructors is going to be named ".new". Therefore, since creating an object using a default constructor is really common, it should be drop-dead simple. I think there's utility in trying to accommodate: $obj = MyClass.new(...);# normal case $obj = MyClass.new; # if the constructor takes no args $obj = MyClass(...) # implied "new" w/ args $obj = MyClass; # implied "new", no args Since instantiating a class is MUCH more common than is passing classes themselves around, the latter case could be "expanded" instead: $obj = MyClass; # instantiate it, using the default constructor $obj = MyClass.TYPE;# assign a reference to MyClass $obj = 'MyClass'; # ... or just treat it as a string? trading less code in the very common case for more code in the not-as-common case. (It would make other things simpler, too, e.g. transformations.) So tho I have no say in the decision, I'm REALLY hoping that we can leave out the new(). (The idea of being able to drop the new() was stolen from languages in which the name of the constructor is the same as the name of the class, there is no new() at all.) As far as the syntax for type declarations: I have less bees about this one. Clearly, my $obj is MyClass; should declare a variable of type MyClass. (You're right, it shouldn't autoviv.) So what's the simplest syntax for typing + instantiation, together? Dunno, maybe my $obj is MyClass .= new; is it, but still I'm hoping for an alternative that is easier to explain to people when I'm training them. Hmm, think, think... MikeL
Re: Eliminate padding warnings
> on ARM, lots of these two: > > In file included from ../include/parrot/register.h:16, > from ../include/parrot/interpreter.h:42, > from ../include/parrot/parrot.h:160, > from array.c:27: > .../include/parrot/string.h:59: warning: padding struct size to alignment boundary > Yep, it doesn't fix any of these...Just those for individual structure members being padded.
Re: [perl #17803] [PATCH] Various tests
At 07:42 PM 10/8/2002 -0700, Steve Fink wrote: >Thanks, applied. > >Who came up with the idea of two-argument ne, anyway? That's kind of >bizarre. I'd much rather have it tested if it exists at all, but it >seems pretty obscure. It's not completely without precedent, on the Z-80: RET CC Return from sub if CC is true But reversing the sense of the test makes it doubly weird. :)
Re: Object Instantiation (Was: Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1)
On Thu, 10 Oct 2002, Michael Lazzaro wrote:
: On Thursday, October 10, 2002, at 11:23 AM, John Williams wrote:
: > my $obj = MyClass(...);
: >
: > This seems to assume that objects have a default method if you treat
: > them
: > like a subroutine. Kinda tcl-ish, but I don't recall anything like
: > this
: > in the apocalypes.
: >
: > my $obj = MyClass;
: >
: > I think $obj would contain a reference to MyClass, not an instance
: > of MyClass.
:
: This is an area that's been bothering me for a while now (the Apoc's so
: far don't directly address it, AFAIK.) Here's why:
:
: Instantiating new objects is *darn* frequent in OO programming. And of
: those objects, a sizable number -- possibly even a majority -- have
: constructors with no required arguments, e.g. "default constructors".
: And pretty much every one of those constructors is going to be named
: ".new".
That's why it's short. :-)
: Therefore, since creating an object using a default constructor is
: really common, it should be drop-dead simple. I think there's utility
: in trying to accommodate:
:
: $obj = MyClass.new(...);# normal case
: $obj = MyClass.new; # if the constructor takes no args
: $obj = MyClass(...) # implied "new" w/ args
: $obj = MyClass; # implied "new", no args
:
: Since instantiating a class is MUCH more common than is passing classes
: themselves around, the latter case could be "expanded" instead:
:
: $obj = MyClass; # instantiate it, using the default constructor
: $obj = MyClass.TYPE;# assign a reference to MyClass
: $obj = 'MyClass'; # ... or just treat it as a string?
:
: trading less code in the very common case for more code in the
: not-as-common case. (It would make other things simpler, too, e.g.
: transformations.) So tho I have no say in the decision, I'm REALLY
: hoping that we can leave out the new().
Sorry, no. The bare class name will refer to the class itself in such
constructs as
when Dog { bark() }
when Cat { meow() }
if $! =~ IntegerOverflow {...}
&squeek := Mouse sub ($x) { return mickey($x) }
: (The idea of being able to drop the new() was stolen from languages in
: which the name of the constructor is the same as the name of the class,
: there is no new() at all.)
Yep, I know about those. Can't say I wasn't tempted. But the simpler
concept should generally have the simpler usage, I think, all other things
being equal. If you're going to do something verbish with a noun, there
ought to be a verb.
That being said, () is a verb of sorts, so we could allow a constructor
syntax in which a class functions as a subroutine reference. But that'd
probably be a shorthand for .new(), or whatever the conversion method is
called, where conversion from undef is equivalent to an argumentless .new().
: As far as the syntax for type declarations: I have less bees about
: this one. Clearly,
:
: my $obj is MyClass;
:
: should declare a variable of type MyClass. (You're right, it shouldn't
: autoviv.) So what's the simplest syntax for typing + instantiation,
: together? Dunno, maybe
:
: my $obj is MyClass .= new;
:
: is it, but still I'm hoping for an alternative that is easier to
: explain to people when I'm training them. Hmm, think, think...
Note that according to the current design team notions your syntax there
is declaring the type of the variable (like a tie), not the type of
the value. You want either
my MyClass $obj;
or
my $obj returns MyClass;
for that. (The first is just synactic sugar for the second.) Things get
more complicated for arrays and hashes. The following are equivalent:
my MyClass @array;
my @array returns MyClass;
my @array is Array of MyClass;
Or something like that.
How the constructor syntax will fit in with that is still up in
the air. I'm rather partial to tacking a closure on the end like
sub syntax, only the closure executes immediately at elaboration
time with the topic being the current object. But that may be the
general syntax rather than the usual syntax. Possibly a declaration
can serve as a topicalizer for any assignment or binding to itself,
so maybe you could say
my MyClass $obj = .new;
to mean the same as
my MyClass $obj { .new }
or maybe
my MyClass $obj { .init }
Or maybe we can have something weird like
my MyClass.new $obj;
That would assume that the object you're creating functions as its
own class. Except you don't actually have the object at compile time...
Perhaps one of
my new MyClass $obj;
new my MyClass $obj;
new MyClass my $obj;
my MyClass $obj is init;
my MyClass $obj.init;
could also be allowed for an argumentless form, though. But this is
all wild speculation at this point.
Larry
Re: remote generators and a macro language proposal
On Thu, 10 Oct 2002, Chip Salzenberg wrote:
: According to Luke Palmer:
: > for ( grep { $_{smoker} and $_{age} > 18 } @Subscribers ) {
: > .send($Cigarette_Advertisement)
: > }
:
: Hm, would this work too:
:
: for ( grep { .{smoker} and .{age} > 18 } @Subscribers )
: { .send($ciggie_ad) }
:
: ? I think .{x} reads better than $_{x} , esp. in parallel with the
: method call in the same loop.
Didn't see the original, but if those are attributes, why wouldn't
it just be:
for grep { .smoker and .age > 18 } @Subscribers {
.send($ciggie_ad)
}
'Course, this might be more readable:
for @Subscribers {
.send($ciggie_ad) if .smoker and .age > 18;
}
Most smokers don't know what "grep" means, after all...
Larry
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
On Wed, 9 Oct 2002, Chris Dutton wrote:
: Wasn't "class MyClass;" supposed to work along the line of Perl5's
: "package MyClass;" and make everything following that statement the
: definition of MyClass?
Yes, though we're thinking of limiting that construct to the front
of a file, along with "module MyModule;". That is, we discourage
people from writing
{
class MyClass;
...
}
when they mean
class MyClass {
...
}
Larry
Re: Delegation syntax
: Problem:
:
: You want to use delegation rather than inheritance to
: add some capabilities of one class or object to
: another class or object.
:
: Solution:
:
: Use a PROXY block:
:
: class MyClass {
:
: PROXY {
: attr $left_front_wheel is Wheel;
: attr $right_front_wheel is Wheel;
:
: when 'steer'{ $left_front_wheel, $right_front_wheel }
: }
: ...
: }
I think this is falling into the "use overload " trap.
If something is part of the method interface, it ought to be declared
as a method. It's the *implementation* syntax that should be screwed
around with to do delegation. Something like:
method steer is really(Wheel) is also(???) { .profit!!! }
I guess now we need C and C tokens now to go with C<...>.
:::---)))
Larry
Re: [parrot] Bindings for other toolkits
At 10:01 AM -0700 10/10/02, Ramesh Ananthakrishnan wrote: >Hi, > Most systems, have a variety of scripting languages >to do stuff in. And almost all the time to make it >work with another library you have to specifically >port the other library to a specific interpreter. >Which means you have separate binding for each >language. gtk has separate bindings for perl, python >and ruby. > Is it possible to avoid this with parrot? That's one of the main points, yep. You write one library, it works with all Parrot-hosted libraries. > Which brings me to another er... ramble. The >documents there are about Parrot aren't very easy for >novices. Currently they're not meant to be--they're internals documentation geared at the folks writing the interpreter, but we do need to get less technical documentation, and some's being worked on. More, of course, is always welcome. :) > Novice that I am I'd be willing to write a >few "really from the ground up how to do stuff" sort >of introductory guide to extending languages to Parrot >or extending toolkits to it. Er.. anybody else >intrested? Can get me going... Absolutely. We've not got the extension mechanism spec'd out quite fully enough, I think, though Brent's done some prelim work on it. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] Removing two-arg ne
Simon Glover wrote: > On Wed, 9 Oct 2002, Dan Sugalski wrote: > > >>At 7:42 PM -0700 10/8/02, Steve Fink wrote: >> >>>Thanks, applied. >>> >>>Who came up with the idea of two-argument ne, anyway? That's kind of >>>bizarre. >>> >> >>Definitely bizarre. I think I'd rather not have it, it doesn't make much sense. >> > > Easily done. Patch below removes the ops, plus the relevent tests from > integer.t and number.t There are also 2 operand =item B(in INT, in INT) equivalents - toss them, my 2 ยข There are also 2 operand math operations of dubious achievement: 5 add 2 sub 4 mul 1 div 2 mod Each of them will be doubled for each RHS INT argument giving ~25 opcodes. I would kill these too. IMHO a smaller core will perform better, then the above saving of 1 operand in the byte code can achieve. leo
Failed src tests on Win32
D:\Perl\bin\perl.exe t/harness t/src/basic.# No tests run! t/src/basic.dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 1-2 Failed 2/2 tests, 0.00% okay t/src/intlist...# No tests run! t/src/intlist...dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 1-4 Failed 4/4 tests, 0.00% okay t/src/sprintf...# No tests run! t/src/sprintf...dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED test 1 Failed 1/1 tests, 0.00% okay t/op/basic..ok t/op/bitwiseok t/op/debuginfo..ok t/op/gc.ok t/op/globalsok t/op/hacks..ok t/op/ifunless...ok (WinNT with 6sp and VC++ 6.0 with 5sp and processor pack) Nick.
Re: [perl #17817] [PATCH] Parrot_sprintf-related stuff, part 2
On Wed, Oct 09, 2002 at 11:28:32PM -0700, Brent Dax wrote:
> Once I clear up the issue with the Sun compiler, I'll be committing
> this. Well, a slightly modified version. Relax, it's nothing
> drastic--I just ran it through check_source_standards.pl and
> run_indent.pl.
That checkin broke the build on my machine. It said:
spf_vtable.c: In function `getchr_va':
spf_vtable.c:41: `char' is promoted to `int' when passed through `...'
spf_vtable.c:41: (so you should pass `int' not `char' to `va_arg')
spf_vtable.c: In function `getfloat_va':
spf_vtable.c:117: `float' is promoted to `double' when passed through `...'
I am on a rather vanilla x86 linux with gcc 2.96, so I decided it
would be better to fix this and potentially break other platforms
(though hopefully they'll be ok with this change too.) So I committed
this:
Index: spf_vtable.c
===
RCS file: /cvs/public/parrot/spf_vtable.c,v
retrieving revision 1.1
diff -p -u -r1.1 spf_vtable.c
--- spf_vtable.c11 Oct 2002 01:46:31 - 1.1
+++ spf_vtable.c11 Oct 2002 06:42:04 -
@@ -38,7 +38,7 @@ getchr_va(struct Parrot_Interp *interpre
{
va_list *arg = (va_list *) (obj->data);
-char ch = va_arg(*arg, char);
+char ch = (char) (int) va_arg(*arg, int);
return string_make(interpreter, &ch, 1, NULL, 0, NULL);
}
@@ -114,7 +114,7 @@ getfloat_va(struct Parrot_Interp *interp
switch (size) {
case SIZE_SHORT:
-return (HUGEFLOATVAL) (float)va_arg(*arg, float);
+return (HUGEFLOATVAL) (double)va_arg(*arg, double);
case SIZE_REG:
return (HUGEFLOATVAL) (double)va_arg(*arg, double);
case SIZE_HUGE:
Re: [PATCH] Perlhash fix & test (was Re: Eliminate padding warnings)
Thanks, applied.
RE: Failed src tests on Win32
Nick Kostirya:
# D:\Perl\bin\perl.exe t/harness
# t/src/basic.# No tests run!
# t/src/basic.dubious
# Test returned status 255 (wstat 65280, 0xff00)
# DIED. FAILED tests 1-2
# Failed 2/2 tests, 0.00% okay
# t/src/intlist...# No tests run!
# t/src/intlist...dubious
# Test returned status 255 (wstat 65280, 0xff00)
# DIED. FAILED tests 1-4
# Failed 4/4 tests, 0.00% okay
# t/src/sprintf...# No tests run!
# t/src/sprintf...dubious
# Test returned status 255 (wstat 65280, 0xff00)
# DIED. FAILED test 1
# Failed 1/1 tests, 0.00% okay
Known issue. Right now, the code behind Parrot::Test::c_output_is
doesn't work on Windows. But thanks for reporting this--had we not
known about it already, it probably would have thrown us into a blind
panic. :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: [perl #17844] [PATCH] Avoid JIT on Sparc with 64-bit INTVAL and 32-bit pointers
On Thu, Oct 10, 2002 at 06:52:25PM +, Andy Dougherty wrote: > > The combination of 64-bit INTVAL and 32-bit pointers doesn't work with the > Sparc jit. Seems fair to me. Thanks, applied.
