On Wed, 2004-11-03 at 20:08, Milscvaer wrote:
> First, Perl ought to allow bytecode, already compiled,
> to be loaded via a bytecode equivelant to eval(), if
> this cannot be done already.
Please read through the design documents:
http://dev.perl.org/perl6/
Many of these ideas have come
Attached patch makes building in the dynclass ghetto a bit less
inhospitable...
- Sam Ruby
? pyint.imc
? test.imc
? config/gen/makefiles/.dynclasses_pl.in.swp
? dynclasses/pyboolean.pmc
? dynclasses/pydict.pmc
? dynclasses/pyfloat.pmc
? dynclasses/pyfunc.pmc
? dynclasses/pyint.pmc
? dynclasses/py
First, Perl ought to allow bytecode, already compiled,
to be loaded via a bytecode equivelant to eval(), if
this cannot be done already. This would work the same
way as executing Perl code via eval(). For instance,
perhaps through a new bceval function:
bceval($bytecode);.
In addition, Perl shoul
On Wed, 3 Nov 2004 12:52:26 -0800 (PST), Joshua Gatcomb
<[EMAIL PROTECTED]> wrote:
[snip]
> What we would like to do is determine if what we have
> done so far is sufficient or, if not, what specifically
> people would like to see. Some of our unimplemented
> ideas so far are:
> 1. Include the co
Klaas-Jan Stol wrote:
Hello,
I've been playing with closures and subs but I have a little bit of
trouble with those.
I'm a bit confused by all different flavours of syntax, I've been trying
to read and understand all documents concerning this subject, the most
useful was reading the test scripts
Hello,
I've been playing with closures and subs but I have a little bit of
trouble with those.
I'm a bit confused by all different flavours of syntax, I've been trying
to read and understand all documents concerning this subject, the most
useful was reading the test scripts. However, that is PAS
At 5:25 PM -0500 11/3/04, Matt Diephouse wrote:
On Wed, 3 Nov 2004 16:04:38 -0500, Matt Fowles <[EMAIL PROTECTED]> wrote:
I think it would be really cool if commits that had a significant
increase or descrease in speed would be flagged. Possibly just a
section of the page could be a table with
On Wed, 3 Nov 2004 16:04:38 -0500, Matt Fowles <[EMAIL PROTECTED]> wrote:
> I think it would be really cool if commits that had a significant
> increase or descrease in speed would be flagged. Possibly just a
> section of the page could be a table with commit dates and the percent
> effect they ha
All~
I think it would be really cool if commits that had a significant
increase or descrease in speed would be flagged. Possibly just a
section of the page could be a table with commit dates and the percent
effect they had. This table would not contain all commits dates, but
only the most recent
All:
Matt Diephouse and I spent the majority of our time
coming up with a flexible design and gathering
historical statistics. We didn't spend a lot of time
in how to present the data since everybody has their
own opinion (including us).
What we would like to do is determine if what we have
done
On Wed, 3 Nov 2004 18:30:58 +0100, Jerome Quelin <[EMAIL PROTECTED]> wrote:
> What about comparing against perl*, python and ruby?
What about it? Many of the benchmarks are parrot only: the gc tests,
for example. The others should remain mostly static, unless we do
daily checkouts, which is a lot
Abigail <[EMAIL PROTECTED]> writes:
>
>No new keywords in perl-5.001
>New in perl-5.002: tied __DATA__ sysopen prototype
>No new keywords in perl-5.003
>New in perl-5.004: __PACKAGE__ sysseek
>New in perl-5.005: qr lock INIT
>New in perl-5.6.0: CHECK our
>No new keywords
Jerome~
On Wed, 3 Nov 2004 18:33:28 +0100, Jerome Quelin <[EMAIL PROTECTED]> wrote:
> Damn, is it a new rule that perl 6 summarizer should be a maths teacher? :-)
Actually, as an American I would be a lowly math teacher... ;-)
Matt
--
"Computer Science is merely the post-Turing Decline of Form
I've just released mod_parrot 0.1. As I noted in my previous post a few
weeks ago, it now supports authentication handlers. Other major changes
include a testing framework (using Apache::Test), access to Apache
constants, and POD documentation.
You can download it here: http://www.smashing.org/m
On 04/11/03 11:19 -0500, Matt Fowles wrote:
> What gets more fun is raising something (usually e) to a matrix power.
> Then you have to do things with the Jordan Connical form and
> decompose your matrix into eigenvalues and stuff. On the plus side,
> this also allows you to define the sin and co
On 04/11/02 22:10 -0500, Matt Diephouse wrote:
> We have collected benchmark data for regular and
> optimized builds with and without JIT from June 1st through October.
What about comparing against perl*, python and ruby?
Nice work,
Jerome
--
[EMAIL PROTECTED]
Dan Sugalski wrote:
At 11:04 AM -0500 11/3/04, Sam Ruby wrote:
This omission seems odd. Was this intentional?
Nope.
A single pow_p_p_p op backed by a (non-MMD) vtable entry would make it
easier to support code like the following:
def f(x): return x**3
print f(3), f(2.5)
Yeah, it would. I kno
Dan~
On Wed, 3 Nov 2004 11:09:49 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Yeah, it would. I know I'm going to regret asking, but... any reason
> *not* to make it MMD? (Though I have no idea what happens if you
> square a matrix)
Squaring a matrix is easy (so long as it is square).
A^2 ==
At 11:04 AM -0500 11/3/04, Sam Ruby wrote:
This omission seems odd. Was this intentional?
Nope.
A single pow_p_p_p op backed by a (non-MMD) vtable entry would make
it easier to support code like the following:
def f(x): return x**3
print f(3), f(2.5)
Yeah, it would. I know I'm going to regre
This omission seems odd. Was this intentional?
A single pow_p_p_p op backed by a (non-MMD) vtable entry would make it
easier to support code like the following:
def f(x): return x**3
print f(3), f(2.5)
- Sam Ruby
> At 11:08 PM -0800 11/2/04, Jeff Clites wrote:
> >On Nov 2, 2004, at 7:10 PM, Matt Diephouse wrote:
> >
> >>Joshua Gatcomb and I have been working a little
> under a week to set up
> >>an automated build system for parrot that tracks
> performance (with
> >>help from Dan's box). We have collected
Garrett Goebel <[EMAIL PROTECTED]> wrote:
> Dan Sugalski wrote:
>>Piers Cawley wrote:
>>>
>>>Release candidate?
>>
>>What, think this warrants a 0.1.2 release? I'm not so sure about that.
>>It's not that big a deal...
> Weren't you the one calling them big changes?
Tagging CVS can be helpful bef
At 11:57 AM +0100 11/3/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Throwing the trace switch on makes parrot leak. A *lot*. Processes
that top out at 100M VSIZE hit 1G or more, which, well... it ain't
good. Tracing's slow enough as it is without the added hit of
swapping
At 11:08 PM -0800 11/2/04, Jeff Clites wrote:
On Nov 2, 2004, at 7:10 PM, Matt Diephouse wrote:
Joshua Gatcomb and I have been working a little under a week to set up
an automated build system for parrot that tracks performance (with
help from Dan's box). We have collected benchmark data for regula
On 2004-11-03, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 03, 2004 at 12:19:08AM +0100, Abigail wrote:
>> While I won't deny 'err' may be used in many existing programs, I doubt
>> it's used more than 'lock' was before 'lock' was introduced as a keyword.
I wouldn't be so sure. I im
Dan Sugalski wrote:
>Piers Cawley wrote:
>>Jeff Clites <[EMAIL PROTECTED]> writes:
>>
>>> On Nov 1, 2004, at 6:14 AM, Dan Sugalski wrote:
>>>
Because I need to get strings working right, so I'm going to be
implementing the encoding/charset library stuff, which is going to
cause
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:16 AM +0100 11/2/04, Leopold Toetsch wrote:
> I was thinking something a bit more primitive. Since we can treat the
> call chain as an array, we could do:
> $S0 = insert_opname_here [0; 'subname'] # Get the current sub name
> $S1 = insert_op
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Throwing the trace switch on makes parrot leak. A *lot*. Processes
> that top out at 100M VSIZE hit 1G or more, which, well... it ain't
> good. Tracing's slow enough as it is without the added hit of
> swapping and ever-increasing memory usage.
Yep. Traci
Matt Diephouse <[EMAIL PROTECTED]> wrote:
> Joshua Gatcomb and I have been working a little under a week to set up
> an automated build system for parrot that tracks performance (with
> help from Dan's box). We have collected benchmark data for regular and
> optimized builds with and without JIT fr
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>$P1 = interpinfo .INTERPINFO_CURRENT_CONT
>>$P1 = clone $P1
>>
>>I'm still inclined to make this sequence an opcode, though. The
>>cloning is still necessary, as the return continuation is returned.
> Hrm. I think the returned continuation should b
Piers Cawley <[EMAIL PROTECTED]> wrote:
> And, dammit, making a full continuation isn't something a programmer
> should do lightly.
BTW I had to change your example code (you remember it for sure, it's in
t/op/gc_13 inv CVS)
(define (choose . all-choices)
(let ((old-fail fail))
(call
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Python has two data types: str and unicode.
Python's unicode "features" are probably not really good examples
generally. Ongoing discussion in Python lists seem to indicate that
there a rather rough edges still.
> - Sam Ruby
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:16 PM +0100 11/2/04, Leopold Toetsch wrote:
>>
>>If it's pure binary pitch a fit.
>>If it has an encoding attached, continue,
> Yeah, that's the plan.
> I'd like to add another entry to the internal API:
>OPTIONAL_INTERNAL_EXCEPTION
> which wor
Sam Ruby <[EMAIL PROTECTED]> wrote:
> I just spent some time debugging a problem which turned out to be due to
> the "set" operator not doing what I expected (i.e., calling pmc_set).
> In retrospect, what set id doing is perfectly defensible, but "setref",
> as implemented by PerlScalar, remains co
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I expect I'll put together a Unicode charset that uses ICU to do its
> thing, and go from there. We certainly need Unicode support, so it's
> not like we can't do it. (And we still don't have a better option,
> unfortunately)
ICU 3.0 should be out AFAIK.
On Tue, 2 Nov 2004 13:33:47 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:16 PM -0500 11/2/04, Sam Ruby wrote:
>
> Making ICU optional, at least. It's too problematic on too many
> platforms, and just turns into a big headache. It seemed like a good
> idea at the time, and while it's still
36 matches
Mail list logo
