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 yacc
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
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?
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 just saw
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 fast
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
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.
Well, there's only
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 even two assignment,
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
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 Parrot
could
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 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,
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 thought
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 variable to a
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 is
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.
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 the length
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 there's no
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 selection
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 interpreter.
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 too
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
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 @@
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
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 {
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 optimized
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't
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
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,
: 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 make
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
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
- 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. (And
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
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 time and
--- 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, Michael
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 means
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 needs
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
[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
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 offset with a
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
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 about
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'
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],
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 you were
46 matches
Mail list logo
