On Tue, 30 Oct 2001, Dan Sugalski wrote:
> Okay, so I put together the code to handle checking the type of a stack
> entry. (entrytype Ix, iy) Seems to work OK, and I'm about to commit the
> thing. The single thing that's missing are some tests, so I take a look at
> t/op/stacks.t, and... Eeek
John Siracusa:
# Okay, so we've got these guys auto-created if we want:
#
# method foo is lvalue { return $.foo }
#
# (plus or minus the syntax) which lets us do:
#
# $obj.foo = 5;
# print $obj.foo;
#
# So, what about simple array accessors?
Please note that these are my best guesses;
On 10/30/01 12:13 PM, Brent Dax wrote:
> John Siracusa:
> Please note that these are my best guesses; I'm not a Damian ;^).
>
> # $obj.colors('red', 'green', 'blue');
> #
> # $obj.colors = ('red', 'green', 'blue');
> #
> # $obj.colors = ['red', 'green', 'blue' ];
>
> $obj.colors=('r
On Tue, Oct 30, 2001 at 04:29:15PM +1100, Damian Conway wrote:
>
>> > I'd do that like so (using Larry's preferred syntax):
>> [...]
>> > method INIT ($idval) { $.id := $idval }
>>
>> Hm... that looks to me like a regular ":="; is it?
>
> Yep.
>
>
>> If so, what
On Tue, Oct 30, 2001 at 03:59:30PM +1100, Damian Conway wrote:
> (Though I *do* harbour a secret desire to resurrect -> as a type specifier:
>
> sub foo (@args) -> rettype
Hmm... I would have expected "is" to come in here:
sub foo (@args) is IO::Handle
> my $bar -> int;
H
On Mon, Oct 29, 2001 at 04:16:24PM -0800, Larry Wall wrote:
> [EMAIL PROTECTED] writes:
> : 3. If you declare a method *without* any parameter list:
> :
> : method foo {...}
> :
> :then the method call arguments (including the invocant?)
> :are bound to @_.
> :
>
Okay, so we've got these guys auto-created if we want:
method foo is lvalue { return $.foo }
(plus or minus the syntax) which lets us do:
$obj.foo = 5;
print $obj.foo;
So, what about simple array accessors?
$obj.colors('red', 'green', 'blue');
$obj.colors = ('red', 'green
John asked:
> So, what about simple array accessors?
Writing:
class Demo;
my @.colors is public;
gives you:
> $obj.colors('red', 'green', 'blue');
No. $obj.colors() takes no arguments.
> $obj.colors = ('red', 'green', 'blue');
Yes.
> $obj.color
John icked:
> > # # Change apple color, but leave the blue berry
> > # $obj.fruit(apple => 'green');
> > #
> > # print $obj.fruit('apple'); # green
> >
> > $obj.fruit{apple}
>
> Icky, looks "unencapsulated" to me :)
[For the benefit of those playing alon
> > method foo ( $me, $again : $big, $boy ) {...}
> >
> > should be able to be called via either of:
> >
> > foo $obj1, $obj2 : @args;
> > or:
> > ($obj1, $obj2).foo(@args);
>
>
> This stuff brings to mind all sorts of questions:
>
Damian Conway:
# BTW, colon isn't an operator (it's a separator), so it can't be hyped.
What do you mean? We can hype the colon all we want! :^)
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
When I take action, Im not going to fire a $2 million missile at a $10
empty tent and h
On 10/30/01 5:12 PM, Damian Conway wrote:
>> # Change apple color, but leave the blue berry
>> $obj.fruit(apple => 'green');
>
> No. You want:
>
> $obj.fruit{apple} = 'green';
Hm, I think I'll be writing arg-type versions of that one because I'm not
too comfortable with exposing the fac
On Tue, Oct 30, 2001 at 12:27:32PM +1100, Damian Conway wrote:
>
>> >($obj1, $obj2)->foo(@args);
>>
>> Is that merely sugar for:
>>
>> # errr, $_.foo(@args) ?
>> $_->foo(@args) foreach($obj1, $obj2);
>
> No. What you showed would be achieved with either
Aaron wrote:
> > C means: "Once declared cannot be *assigned* to".
> >
> > But that doesn't mean one can't *bind* a new value to the
> > variable (which would retain its C-induced unassignability
> > after the binding).
>
> I understand that. I guess what I'm saying is, f
Aaron wrote:
> > sub foo (@args) -> rettype
>
> Hmm... I would have expected "is" to come in here:
>
>sub foo (@args) is IO::Handle
It would have to be:
sub foo (@args) is type(IO::Handle)
or something, I think. Unless Larry decides that every class/module
name i
On Wed, 31 Oct 2001, Damian Conway wrote:
> To me C means: "the *value* stored in the memory
> implementing this variable cannot be changed". Which doesn't preclude
> rebinding the variable to some *other* memory.
>
> But others have a different (and equally reasonable) interpretation of
> C: "th
> I have an Athlon 700 too. With these compiler flags:
>
> PERL-CFLAGS = -O3 -fomit-frame-pointer -pipe -s -march=pentium -ffast-math \
> -fexpensive-optimizations -fno-strict-aliasing \
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>
> I'm seeing 24 mops which puts Parrot even cl
On Oct 30, Dan Sugalski <[EMAIL PROTECTED]> took up a keyboard and banged out
> At 10:19 AM 10/30/2001 -0500, Michael Fischer wrote:
> >On Oct 29, Dan Sugalski <[EMAIL PROTECTED]> took up a keyboard and banged out
> > > At 03:33 PM 10/29/2001 -0500, Ken Fox wrote:
> > > >Anybody do a gcc-specific
Implements the following instructions:
1) open(i|ic,i|ic,s|sc) - Filehandle in $1, r/w mode in $2 (permissions
644), filename in $3
2) read(s,i|ic,i|ic) - String register in $1, filehandle in $2, number
of chars in $3
3) write(i,s) - Filehandle in $1, string register in $2
4) close(i) - Filehandl
- Original Message -
From: "Ken Fox" <[EMAIL PROTECTED]>
To: "Uri Guttman" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, October 30, 2001 7:05 AM
Subject: Re: Improved storage-to-storage architecture performance
> Uri Guttman wrote:
> > so my point is t
At 07:16 PM 10/29/2001 -0500, James Mastros wrote:
>Yeah. But that's a convention thing, I think. I also think that most
>people won't go to the bother of writing conversion functions that they
>don't have to. What we need to worry about is both, say, big5 and shiftjis
>writing both of the conv
On Oct 29, Dan Sugalski <[EMAIL PROTECTED]> took up a keyboard and banged out
> At 03:33 PM 10/29/2001 -0500, Ken Fox wrote:
> >Anybody do a gcc-specific "goto *pc" dispatcher
> >for Parrot yet? On some architectures it really
> >cooks.
>
> That's a good question. There was talk and benchmark num
At 01:05 AM 10/30/2001 -0500, Ken Fox wrote:
>The other thing to consider is that Perl is still a compile-on-the-fly
>system. I hope Perl 6 keeps this aspect of Perl instead of moving to a
>more Javaesque development environment.
Absolutely. Compile-and-go is an absolute must, and one that'll end
At 12:42 PM 10/30/2001 -0500, Michael L Maraist wrote:
> > Absolutely. Compile-and-go is an absolute must, and one that'll end up
> > disabling most of the potential optimizations for sheer startup time
> > reasons. Which is a pity, but we can always let people enable them if they
> > want from
On Tuesday 30 October 2001 01:47 am, Ken Fox wrote:
> Uri Guttman wrote:
> > that is good. i wasn't disagreeing with your alternative architecture.
> > i was just making sure that the priority was execution over compilation
> > speed.
>
> I use a snazzy quintuple-pass object-oriented assembler wri
At 05:27 PM 10/29/2001 +, David Trusty wrote:
>I would like to request a new feature for perl: The ability to
>attach a perl debugger to a running process.
This is a not inconsiderable task, and one with some potential security
issues if perl wasn't fired up with remote debugging enabled al
Okay, so I put together the code to handle checking the type of a stack
entry. (entrytype Ix, iy) Seems to work OK, and I'm about to commit the
thing. The single thing that's missing are some tests, so I take a look at
t/op/stacks.t, and... Eeek!
I fully admit I have no idea what's going on in
Dan Sugalski wrote:
> Hmmm. I'd like to see the two run with the same style dispatcher to get a
> closer comparison of run speeds. When you say threaded, you're doing more
> or less what the switch/computed-goto dispatcher does, right?
If you take a look at the op_add code I posted, you'll see
On Tue, Oct 30, 2001 at 10:19:10AM -0500, Michael Fischer wrote:
> Also, my understanding was that the goto *pc _was_ indeed very
> gcc specific, and therefore a no-no for parrot. Thoughts?
If we have switchable runops cores, I'm cool with having
compiler-specific stuff. But wouldn't it be cool
Michael L Maraist wrote:
> The only "memory" storage for scalars that I currently am conceiving of is
> in name-space stashes (globals). Thus our most likely implementation of S2S
> would be to have 'add "g_x", "g_y", "g_z"' which performs two stash
> lookups, an add, then one stash write.
Kakap
At 04:24 PM 10/30/2001 +, Simon Cozens wrote:
>On Tue, Oct 30, 2001 at 10:19:10AM -0500, Michael Fischer wrote:
> > Also, my understanding was that the goto *pc _was_ indeed very
> > gcc specific, and therefore a no-no for parrot. Thoughts?
>
>If we have switchable runops cores, I'm cool with
At 10:19 AM 10/30/2001 -0500, Michael Fischer wrote:
>On Oct 29, Dan Sugalski <[EMAIL PROTECTED]> took up a keyboard and banged out
> > At 03:33 PM 10/29/2001 -0500, Ken Fox wrote:
> > >Anybody do a gcc-specific "goto *pc" dispatcher
> > >for Parrot yet? On some architectures it really
> > >cooks.
> Absolutely. Compile-and-go is an absolute must, and one that'll end up
> disabling most of the potential optimizations for sheer startup time
> reasons. Which is a pity, but we can always let people enable them if they
> want from the command line.
Or via "use flags", since mod_perl and the l
Kevin Huber wrote:
> This is a comparison of mops running on Parrot (-O6 on an Athlon 700)
> versus Java JDK 1.4.0 beta 2 jitted and interpreted. You can see that
> Parrot performance is very comparable to Java in interpreted mode.
I have an Athlon 700 too. With these compiler flags:
PERL-CFLAG
At 11:21 PM 10/29/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > What sort of dispatch was your version using, and what sort was
> > parrot using in your test?
>
>Parrot used the standard function call dispatcher without bounds
>checking.
>
>Kakapo used a threaded dispatcher. There's a pre-pr
At 09:46 AM 10/30/2001 -0500, Ken Fox wrote:
>Kevin Huber wrote:
> > This is a comparison of mops running on Parrot (-O6 on an Athlon 700)
> > versus Java JDK 1.4.0 beta 2 jitted and interpreted. You can see that
> > Parrot performance is very comparable to Java in interpreted mode.
>
>I have an
Ah, one other spot where SS is a real problem.
Threads.
If we have fixed addresses to data stored in the executable code, it means
that every time we spawn off a thread we need to clone and fix up all the
code it has access to, otherwise Bad Things Will Happen. :(
In message <[EMAIL PROTECTED]>
James Mastros <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 29, 2001 at 11:20:47PM +, Tom Hughes wrote:
>
> > I suspect that the encode and decode methods in the encoding vtable
> > are enough for doing chr/ord aren't they?
>
> Hmm... come to think of it, ye
Automated smoke report for patch Oct 29 20:00:02 2001 UTC
v0.02 on hpux using cc version B.11.11.02
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during: - = unknown
c = Configure, m = make, t =
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> I think this is why storage-to-storage architectures have lost
KF> favor -- today's compilers are just too smart. Possibly with a
KF> software VM the memory pressure argument favoring registers isn't
KF> strong enough to offset the di
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> Uri Guttman wrote:
>> and please don't bring in hardware comparisons again. a VM design
>> cannot be compared in any way to a hardware design.
KF> I didn't say a single thing about hardware. My entire post was
KF> simply about an al
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> Uri Guttman wrote:
>> so my point is the the speed of the VM is a separate issue from the ease
>> of code generation. an S2S VM would be easier to code generate for but
>> may be slower to run. the speed difference is still an open poi
This is a comparison of mops running on Parrot (-O6 on an Athlon 700)
versus Java JDK 1.4.0 beta 2 jitted and interpreted. You can see that
Parrot performance is very comparable to Java in interpreted mode.
I've attached mops.class and mops.ksm, some disassembly output from
Kopi. mops.class was
Kevin Huber sent the following bits through the ether:
> Parrot2Java which I will make available once I fix a few more bugs
> :-).
Oh, cute! I've been frustrating myself by trying to do it the other
way around (it'll happen eventually...). Optimising the stack
loads/saves will be the fun part
44 matches
Mail list logo
