what if
> my Dog &hot () is rw { my Dog $anonymous }
goes dollarless as
my Dog sub hot () is rw { my Dog scalar anonymous }
--
David Nicol 816.235.1187
silly ears http://www.bobdylan.com/songs/gates.html
Quite right, Ken. The new patch hopefully takes care of that issue, and
fixes an additional bug in the concat operator.
Ken Fox wrote:
> Jeff wrote:
> > diff -ru parrot/core.ops parrot_orig/core.ops
> > --- parrot/core.ops Tue Nov 6 11:14:25 2001
> > +++ parrot_orig/core.opsWed Nov
read(s,i|ic,i|ic) was setting the length of the string to the selected
length no matter what.
--
--Jeff
<[EMAIL PROTECTED]>
diff -ru parrot/core.ops parrot_orig/core.ops
--- parrot/core.ops Tue Nov 6 11:14:25 2001
+++ parrot_orig/core.opsWed Nov 7 20:53:05 2001
@@ -199,7 +199,7 @
Ken Fox writes:
: Garrett Goebel wrote:
: > Just does compile-time typing for $foo? Not inlining the constant?
:
: You can't assume that the value associated with the symbol is
: the same each time through the code, so how can it be inlined?
:
: > I was thinking lowercase typed variables couldn'
Brent Dax writes:
: Larry Wall:
: # Note that the "sub" is standing in for &, so it'd have to be
: #
: # my Dog sub hot {...}
: #
: # or
: #
: # my Dog &hot {...}
:
: What about package subs?
:
: our Dog sub hot {...}
:
: seems just a bit verbose...
Seems to me that discouraging
Larry Wall:
# Note that the "sub" is standing in for &, so it'd have to be
#
# my Dog sub hot {...}
#
# or
#
# my Dog &hot {...}
What about package subs?
our Dog sub hot {...}
seems just a bit verbose...
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
When I take a
: Personally I suspect he may prefer to stick with "type-before-name":
:
: my Dog $spot;
:
: sub Dog hot {...}
Note that the "sub" is standing in for &, so it'd have to be
my Dog sub hot {...}
or
my Dog &hot {...}
To get a dollarless variant of Perl it may suffice to
Dan Sugalski wrote:
> No it isn't. It can get the integer length of the array and stuff it in a
> register at the beginning of the loop, or do an integer compare when it
> needs to, depending on the semantics of the loop.
Wow. Did you just come up with a place in Perl where static
behavior is gua
Sam Vilain writes:
: On Wed, 7 Nov 2001 12:26:31 +
: Sam Vilain <[EMAIL PROTECTED]> wrote:
:
: > Why limit Perl to OO and procedural programming at its core?
:
: I just realised my mistake after looking at the hyperoperator discussion:
: Hyperoperators bring functional programming to Perl, w
Dan Sugalski wrote:
> I doubt there'll be GC pluggbility. (Unless you consider "Ripping out the
> guts of resources.c and gc.c and replacing them" pluggability... :) If it
> works out that way, great, but I don't know that it's really something I'm
> shooting for.
That problem doesn't bother me t
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> JITs help when the VM is focused on lots of small instructions
KF> with well-known, static semantics. Perl's use of Parrot is going
KF> to be focused almost completely on PMC vtable ops. A JIT has
KF> no advantage over a threaded inter
Simon Cozens wrote:
> ... Mono's work on JIT compilation ... they've got some pretty
> interesting x86 code generation stuff going on.
Mono is doing some very cool stuff, but it's kind of hard
to understand at this time. The x86 code generation macros are
easy to use, but the instruction selectio
At 06:06 PM 11/7/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 04:29 PM 11/7/2001 -0500, James Mastros wrote:
> > > On Wed, Nov 07, 2001 at 10:15:07AM -0500, Ken Fox wrote:
> > > > If Perl can keep the loop index in an integer register, then Parrot
> > > > could use fast loop ops. IMHO th
Dan Sugalski wrote:
> At 04:29 PM 11/7/2001 -0500, James Mastros wrote:
> > On Wed, Nov 07, 2001 at 10:15:07AM -0500, Ken Fox wrote:
> > > If Perl can keep the loop index in an integer register, then Parrot
> > > could use fast loop ops. IMHO there's no point in using fast loop ops
> > > if taking
At 10:38 PM 11/7/2001 +, Alex Gough wrote:
>[0] Someone mentioned something about this confusing the line endings
> in win32, which will cause erroneous test failures, I might look at this
> as well.
*Please* do--it seems to confuse the test harness to no end on CygWin.
At 08:44 PM 11/7/2001 +0100, Bart Schuller wrote:
>On Wed, Nov 07, 2001 at 07:12:40AM -0600, Dave Goehrig wrote:
> > I brought up the whole low level integer rewrite stuff above, because
> > look at it again. That is eactly what we are meant to do when we know
> > it is safe to optimize a variabl
On Wed, 7 Nov 2001, Nathan Torkington wrote:
> I want to see a document that says how Parrot implementers should
> write tests for the features they implement. Does *anyone* understand
> how to do this? If so, could you please step forward and write such a
> document and become a hero.
I thoug
On Wed, Nov 07, 2001 at 07:12:40AM -0600, Dave Goehrig wrote:
> I brought up the whole low level integer rewrite stuff above, because
> look at it again. That is eactly what we are meant to do when we know
> it is safe to optimize a variable to a more limited domain than say
> 'scalar'. We don't
At 04:29 PM 11/7/2001 -0500, James Mastros wrote:
>On Wed, Nov 07, 2001 at 10:15:07AM -0500, Ken Fox wrote:
> > I've been thinking of ways to speed up stuff like:
> > foreach my $x (@vector) {
> > $x *= $scale
> > }
> >
> > If Perl can keep the loop index in an integer register, then Parro
At 12:55 PM 11/7/2001 -0800, Brent Dax wrote:
>Is there a reason we have the current two-pointer stack setup, instead
>of a struct stack or something to abstract the pointers away?
No real reason. Seemed to make sense at the time. The base pointer points
at the chunk at the start of each stack,
I want to see a document that says how Parrot implementers should
write tests for the features they implement. Does *anyone* understand
how to do this? If so, could you please step forward and write such a
document and become a hero.
I imagine a test writing HOW-TO would cover:
* structure of
At 10:04 AM 11/7/2001 -0600, Dave Goehrig wrote:
>On Wed, Nov 07, 2001 at 03:41:54PM -0500, Ken Fox wrote:
> > Dan Sugalski wrote:
> > > my $foo;
> > > $foo = 12;
> > > print $foo;
> > > $foo /= 24;
> > > print $foo;
> >
> > Well, there's only two assignments there,
>
>It isn't
At 03:41 PM 11/7/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > my $foo;
> > $foo = 12;
> > print $foo;
> > $foo /= 24;
> > print $foo;
> >
> > may well have the vtable pointer attached to the PMC for $foo change with
> > every line of code. Probably will, honestly.
>
>Wel
At 09:47 AM 11/7/2001 -0600, Dave Goehrig wrote:
> > The problem with inlining methods from PMC vtables is it assumes those
> > vtable methods are constant. They're not.
>
>They're not constant universally, but the are constant locally.
No, they aren't. A vtable method can completely swap out a v
On Wed, Nov 07, 2001 at 10:15:07AM -0500, Ken Fox wrote:
> I've been thinking of ways to speed up stuff like:
> foreach my $x (@vector) {
> $x *= $scale
> }
>
> If Perl can keep the loop index in an integer register, then Parrot
> could use fast loop ops. IMHO there's no point in using fa
On Wed, Nov 07, 2001 at 03:41:54PM -0500, Ken Fox wrote:
> Dan Sugalski wrote:
> > my $foo;
> > $foo = 12;
> > print $foo;
> > $foo /= 24;
> > print $foo;
>
> Well, there's only two assignments there,
It isn't even two assignment, hell, it reduces to: 120.5
literally, if you
Is there a reason we have the current two-pointer stack setup, instead
of a struct stack or something to abstract the pointers away? The
current setup is hard to use and easy to confuse. (I know I confused
myself with the stacks in the regexp code... :^) )
typedef struct _stack {
struct
> The problem with inlining methods from PMC vtables is it assumes those
> vtable methods are constant. They're not.
They're not constant universally, but the are constant locally. In
those locales that inlining is worth the cost we can do it. And
as long as we are willing to take the hit in o
Dan Sugalski wrote:
> my $foo;
> $foo = 12;
> print $foo;
> $foo /= 24;
> print $foo;
>
> may well have the vtable pointer attached to the PMC for $foo change with
> every line of code. Probably will, honestly.
Well, there's only two assignments there, so I assume that print
Dan Sugalski:
# >Is anybody working on the Perl code generator yet? I think
# >the code generator might influence op implementation.
Chicken and egg. We can't really generate code until the ops are ready,
but we would like the code generator to be around so we can make
intelligent decisions abou
On Wed, Nov 07, 2001 at 11:50:00AM -0500, Dan Sugalski wrote:
> I mean "Change which table of functions is in effect for a
> variable at this point in time".
I honestly, still don't think that makes a lick of difference,
though I admit I may be introducing an "out of context problem".
> my
At 05:35 AM 11/7/2001 -0600, Dave Goehrig wrote:
>[snip inlining PMC vtable]
>
>On Wed, Nov 07, 2001 at 09:49:04AM -0500, Dan Sugalski wrote:
> > We can't do that. PMCs, even statically typed ones, can change their
> > vtables as they see fit.
>
>That is true, but it does not negate the option of
At 10:15 AM 11/7/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 07:47 PM 11/6/2001 -0500, Ken Fox wrote:
> > >If the guts of a vtable implementation are ripped out and given an
> > >op, isn't that inlining a PMC method? There doesn't seem much point
> > >in replacing a dynamic vtable offse
[snip inlining PMC vtable]
On Wed, Nov 07, 2001 at 09:49:04AM -0500, Dan Sugalski wrote:
> We can't do that. PMCs, even statically typed ones, can change their
> vtables as they see fit.
That is true, but it does not negate the option of inlining, it simply
increases the overhead required for
Dan Sugalski wrote:
> At 07:47 PM 11/6/2001 -0500, Ken Fox wrote:
> >If the guts of a vtable implementation are ripped out and given an
> >op, isn't that inlining a PMC method? There doesn't seem much point
> >in replacing a dynamic vtable offset with a constant vtable offset.
> >The method really
On Tue, Nov 06, 2001 at 05:22:27PM -0500, Dan Sugalski wrote:
> A variable with a numeric value can be taken in one of three ways:
>
> *) As an integer. Which means either platform-native or bigint
> *) As a float. Which means either platform-native or bigfloat
> *) As a generic number. Which me
--- Benoit Cerrina <[EMAIL PROTECTED]> wrote:
> I guess the actual page of interest is:
> http://www.cs.utexas.edu/users/oops/papers.html
> please correct me if wrong
You are correct -- that looks like a better source. The main
paper I was thinking of was:
Paul R. Wilson, Mark S. Johnstone, Mic
At 09:13 AM 11/7/2001 +0100, Benoit Cerrina wrote:
>From: "Dan Sugalski" <[EMAIL PROTECTED]>
>
> > 'Kay, here's a quick overview of how memory, garbage collection, and dead
> > object detection are going to work in Parrot. (And I appreciate this
> > getting raised now, BTW--both because it's about
At 09:32 AM 11/7/2001 -0500, Andy Dougherty wrote:
>I think a generic platform.c with a few sprinkled #ifdef's is more
>appropriate. That's what the patch below does.
Applied. Thanks.
Dan
--"it's like this"
At 07:47 PM 11/6/2001 -0500, Ken Fox wrote:
>Simon Cozens wrote:
> > > some static typing ability, so it should be able
> > > to emit bytecode that doesn't go through the PMC vtable.
> >
> > Yes, but that's fundamentally different from inlining vtable methods
> > in the runops loop, which is what
From: Garrett Goebel [mailto:[EMAIL PROTECTED]]
> From: Sam Vilain [mailto:[EMAIL PROTECTED]]
>
> > So if functional programming can be in Perl 6, why not rules based
> > programming?
>
> Is Parse::RecDescent insufficient for your needs?
Sorry, that was before my morning pot of espresso. I jus
From: Sam Vilain [mailto:[EMAIL PROTECTED]]
> So if functional programming can be in Perl 6, why not rules based
> programming?
Is Parse::RecDescent insufficient for your needs?
I think the current platform/linux.[ch] files do more harm than good. They
may eventually be necessary, but nearly everything that's currently in
linux.[ch] also would belong in a hypothetical freebsd.[ch], openbsd.[ch],
netbsd.[ch], solaris.[ch], ncr.[ch], unixware.[ch], smes.[ch],
unisys.[ch], d
On Wed, 7 Nov 2001 12:26:31 +
Sam Vilain <[EMAIL PROTECTED]> wrote:
> Why limit Perl to OO and procedural programming at its core?
I just realised my mistake after looking at the hyperoperator discussion:
Hyperoperators bring functional programming to Perl, with all of the mad
but inspired p
On Wed, 24 Oct 2001 14:20:58 +0100
Graham Barr <[EMAIL PROTECTED]> wrote:
> I have always found that the perl output from byacc (with a few tweaks)
> generates a sufficient parser. The addition of a switch statement
> will hopefully make it more efficient.
What you are saying is you are using ya
I've just been having a look at Mono's work on JIT compilation,
and it looks like they've got some pretty interesting x86 code
generation stuff going on. Anyone want to have a look at that
and report back on its potential for Parrot?
--
And it should be the law: If you use the word `paradigm' wi
Automated smoke report for patch Nov 6 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 =
- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 06, 2001 11:55 PM
Subject: Parrot memory/GC/DOD primer
> 'Kay, here's a quick overview of how memory, garbage collection, and dead
> object detection are going to work in Parrot
48 matches
Mail list logo
