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 regular and
optimized builds with and without JIT fr
On Nov 2, 2004, at 10:46 AM, Dan Sugalski wrote:
At 1:42 PM -0500 11/2/04, Sam Ruby wrote:
I don't care if Parrot uses ICU on any platform.
I do care that Parrot supports utf-8 on every platform.
Ah, OK. Yes, we will support all the unicode encodings, as well as the
unicode character set, on all p
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 from June 1st through October.
With some help from
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.
Difference between lock() and err() is this.
$ perl5.6.1 -wle 'sub lock { "foo" } print l
Thank you for your reply.
Ive thought about it and it is really perfectly fine
with me if large parts (or all) of the old perl
interpreter where bundled with Parrot in order to
provide Perl5 compatability on Parrot. If using
existing Perl5 interpretor code saves effort and works
well, but still al
On Fri, Oct 22, 2004 at 01:59:13AM -0700, Yitzchak Scott-Thoennes wrote:
> On Mon, Oct 18, 2004 at 01:05:06PM -0400, Michael G Schwern <[EMAIL PROTECTED]>
> wrote:
> > On Mon, Oct 18, 2004 at 04:43:12PM +0200, H.Merijn Brand wrote:
> > > > Please consider 0.50 very soon, in which you fix 'err' cal
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 2:30 PM -0500 11/2/04, Matt Fowles wrote:
>>All~
>>
>>I don't like the idea of having to dig down through the entire return
>>chain promoting these guys. Is there a reason not to use DOD/GC to
>>recycle continuations?
>
> Yes. Speed.
>
> While you can
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Will Coleda <[EMAIL PROTECTED]> wrote:
>
> > I think we should be building dynclasses by default.
>
> Before applying it, some response from various platforms might be
> helpful. Please folks either apply that patch, or run the make
> command manually:
At 2:30 PM -0500 11/2/04, Matt Fowles wrote:
All~
I don't like the idea of having to dig down through the entire return
chain promoting these guys. Is there a reason not to use DOD/GC to
recycle continuations?
Yes. Speed.
While you can skip some of the digging (since you can stop at the
first pro
All~
I don't like the idea of having to dig down through the entire return
chain promoting these guys. Is there a reason not to use DOD/GC to
recycle continuations?
Matt
On Tue, 2 Nov 2004 14:10:09 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:51 PM +0100 11/2/04, Leopold Toetsch wrote
At 6:51 PM +0100 11/2/04, Leopold Toetsch wrote:
* The stack frame caching is back, hopefully now implemented correctly:
1) when a return continuation is invoked the stack frame is recycled
2) when a continuation is created, all the return continuations up the
call chain are converted to re
Quoth [EMAIL PROTECTED] (Dan Sugalski):
> Okay, here's a question for everyone to hash out.
>
> Assuming I have a parrot string which is explicitly marked as a
> binary string...
>
> What should happen when it's told to upcase/downcase/titlecase
> itself? (You may assume that we have strings w
At 1:42 PM -0500 11/2/04, Sam Ruby wrote:
Dan Sugalski wrote:
At 1:16 PM -0500 11/2/04, Sam Ruby wrote:
Dan Sugalski wrote:
At 5:43 PM + 11/2/04, Nicholas Clark wrote:
On Tue, Nov 02, 2004 at 12:35:26PM -0500, Sam Ruby wrote:
However, str has an upper() method defined on it. The way it operat
Dan Sugalski wrote:
At 1:16 PM -0500 11/2/04, Sam Ruby wrote:
Dan Sugalski wrote:
At 5:43 PM + 11/2/04, Nicholas Clark wrote:
On Tue, Nov 02, 2004 at 12:35:26PM -0500, Sam Ruby wrote:
However, str has an upper() method defined on it. The way it
operates
is to take the range of bytes that co
At 6:32 PM + 11/2/04, 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 some major disruptions.
At 1:16 PM -0500 11/2/04, Sam Ruby wrote:
Dan Sugalski wrote:
At 5:43 PM + 11/2/04, Nicholas Clark wrote:
On Tue, Nov 02, 2004 at 12:35:26PM -0500, Sam Ruby wrote:
However, str has an upper() method defined on it. The way it operates
is to take the range of bytes that correspond to us-ascii
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 some major disruptions.
>
> Please tag cvs before checking t
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 counter intuitive, at least to me:
.sub ma
At 6:16 PM +0100 11/2/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Okay, here's a question for everyone to hash out.
Assuming I have a parrot string which is explicitly marked as a
binary string...
What should happen when it's told to upcase/downcase/titlecase
itself?
I
Dan Sugalski wrote:
At 5:43 PM + 11/2/04, Nicholas Clark wrote:
On Tue, Nov 02, 2004 at 12:35:26PM -0500, Sam Ruby wrote:
However, str has an upper() method defined on it. The way it operates
is to take the range of bytes that correspond to us-ascii and perform a
us-ascii uppercase on them.
* The stack frame caching is back, hopefully now implemented correctly:
1) when a return continuation is invoked the stack frame is recycled
2) when a continuation is created, all the return continuations up the
call chain are converted to real continuations by changing the
vtable. This
Mark Stosberg wrote:
On Mon, 2004-11-01 at 07:45, Mark Stosberg wrote:
So, what resources are recommended to consult to make great estimates?
What habits to develop?
Thanks to everyone for all the responses. There is one theme I haven't
heard anyone mention:
The purely scientific approach that I a
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, here's a question for everyone to hash out.
> Assuming I have a parrot string which is explicitly marked as a
> binary string...
> What should happen when it's told to upcase/downcase/titlecase
> itself?
If it's pure binary pitch a fit.
If it has a
At 5:43 PM + 11/2/04, Nicholas Clark wrote:
On Tue, Nov 02, 2004 at 12:35:26PM -0500, Sam Ruby wrote:
However, str has an upper() method defined on it. The way it operates
is to take the range of bytes that correspond to us-ascii and perform a
us-ascii uppercase on them. The remaining byte
On Tue, Nov 02, 2004 at 12:35:26PM -0500, Sam Ruby wrote:
> However, str has an upper() method defined on it. The way it operates
> is to take the range of bytes that correspond to us-ascii and perform a
> us-ascii uppercase on them. The remaining bytes are left alone.
I'd prefer parrot not t
Dan Sugalski wrote:
Okay, here's a question for everyone to hash out.
Assuming I have a parrot string which is explicitly marked as a binary
string...
What should happen when it's told to upcase/downcase/titlecase itself?
(You may assume that we have strings which are explicitly marked at
least
Dan Sugalski wrote:
Okay, here's a question for everyone to hash out.
Assuming I have a parrot string which is explicitly marked as a binary
string...
What should happen when it's told to upcase/downcase/titlecase itself?
(You may assume that we have strings which are explicitly marked at
least
At 12:11 PM -0500 11/2/04, Matt Fowles wrote:
Dan~
I vote for doing nothing in the up/down case options as those are
frequently just used to get a cannonical form for comparison.
Although I could understand an argument for throwing an exception...
People better not be using binary data as a canonic
On Tue, 2 Nov 2004 09:51:39 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> You got an old forth.pbc, probably. Fingerprinting is disabled for the
> release, so it might be, that you can run forth.pbc with the released
> Parrot but not with a current one.
Odd, because it was newly made bytecod
Dan~
I vote for doing nothing in the up/down case options as those are
frequently just used to get a cannonical form for comparison.
Although I could understand an argument for throwing an exception...
Matt
On Tue, 2 Nov 2004 11:53:08 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, here
On Tue, Nov 02, 2004 at 11:53:08AM -0500, Dan Sugalski wrote:
> Okay, here's a question for everyone to hash out.
>
> Assuming I have a parrot string which is explicitly marked as a
> binary string...
>
> What should happen when it's told to upcase/downcase/titlecase
> itself? (You may assume t
Okay, here's a question for everyone to hash out.
Assuming I have a parrot string which is explicitly marked as a
binary string...
What should happen when it's told to upcase/downcase/titlecase
itself? (You may assume that we have strings which are explicitly
marked at least Unicode, so there i
On Nov 2, 2004, at 12:41 AM, Leopold Toetsch wrote:
When we have objects with finalizers, we have to run the finalizers in
order from most derived down the parent chain.
Maybe, but not necessarily. The case of loops means that we cannot
always do this cleanly (no "top" of the chain), and the fact
At 11:16 AM +0100 11/2/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 11:45 AM +0200 10/29/04, Leopold Toetsch wrote:
Should the traceback object be avaiable as a PMC?
Nah, I don't think so. There's nothing in the traceback that wouldn't
be in the current continuation, s
Mark,
There is one theme I haven't heard anyone mention:
The purely scientific approach that I assume involves collecting a lot
o
data and using complex formulas.
I think that may be because project estimation is more akin to alchemy
and witchcraft than it is "hard science".
:)
Steve
Mark,
I think Jared and Andy both have made excellent suggestions, especially
Andy's comment about breaking it down into manageable chunks.
So, what resources are recommended to consult to make great estimates?
What habits to develop?
When I first started estimating projects I very often would ma
On 2004-11-01, chromatic <[EMAIL PROTECTED]> wrote:
> On Mon, 2004-11-01 at 07:45, Mark Stosberg wrote:
>
>> So, what resources are recommended to consult to make great estimates?
>> What habits to develop?
>
> I have two primary rules:
>
> 1) Don't make an estimate for something I haven't done bef
At 11:41 AM +0100 11/2/04, Leopold Toetsch wrote:
James deBoer <[EMAIL PROTECTED]> wrote:
Some systems, notable Debian, ship perldoc and perl as seperate
packages. The presence of Perl does not imply the presence of perldoc.
This patch will test to see if perldoc actually works, aborting the
c
On Mon, 1 Nov 2004, James deBoer wrote:
> Some systems, notable Debian, ship perldoc and perl as seperate
> packages. The presence of Perl does not imply the presence of perldoc.
>
> This patch will test to see if perldoc actually works, aborting the
> configuration if it does not.
I don't feel s
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> Basically we want to be able to walk a continuation chain and get
>> access to everything.
> I think having methods is ok for that. It's in no way time critical to
> warrant opcodes.
I've now created two meth
Leopold Toetsch wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
I think we should be building dynclasses by default.
Before applying it, some response from various platforms might be
helpful. Please folks either apply that patch, or run the make
command manually:
+ cd dynclasses && $(MAKE)
Work
I have this error when installing under Solaris 9 :
/bin/sh ../mkinstalldirs /export/profs/aperghis/parrot/blib/lib
.././install-sh -c -m 644 libicudata.a
/export/profs/aperghis/parrot/blib/lib/li
bicudata.a
make[1]: Leaving directory
`/export/profs/aperghis/parrot/icu/source/stubdata'
perl -e 'c
James deBoer <[EMAIL PROTECTED]> wrote:
> Some systems, notable Debian, ship perldoc and perl as seperate
> packages. The presence of Perl does not imply the presence of perldoc.
> This patch will test to see if perldoc actually works, aborting the
> configuration if it does not.
> I was conside
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:45 AM +0200 10/29/04, Leopold Toetsch wrote:
>>Should the traceback object be avaiable as a PMC?
> Nah, I don't think so. There's nothing in the traceback that wouldn't
> be in the current continuation, so I don't think it's worth
> bothering.
Ok.
# New Ticket Created by James deBoer
# Please include the string: [perl #32280]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32280 >
Some systems, notable Debian, ship perldoc and perl as seperate
packages. The presenc
On Mon, Nov 01, 2004 at 01:53:59PM -0800, Jared Rhine wrote:
> [Mark == [EMAIL PROTECTED] on Mon, 1 Nov 2004 15:45:34 + (UTC)]
>
> Mark> So, what resources are recommended to consult to make great
> Mark> estimates? What habits to develop?
>
> Estimate only what you know...
Thank you Ja
Bernhard Schmalhofer (via RT) wrote:
this is an update of Parrot m4.
Thanks, applied.
leo
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Perl 6 Summary for 2004-10-23 through 2004-11-01
>newsub opcodes
> Leo wanted to add some newsub opcodes to save allocations. Dan countered
> that it would be a better thing to get constant pmcs working properly.
Not quite. The C opcodes were a
Matt Diephouse <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED]:~/parrot$ ./disassemble forth/forth.pbc
> PackFile_unpack: Bytecode not valid for this interpreter: fingerprint mismatch
You got an old forth.pbc, probably. Fingerprinting is disabled for the
release, so it might be, that you can run f
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:03 PM +0100 11/1/04, Leopold Toetsch wrote:
>>We need more vtables.
>>
>>* INTVAL hash()
>>
>>To properly support Python, we need:
>>- a hash PMC that isn't restricted to STRING* keys
> Works for me. We probably need to make sure that everything's in
50 matches
Mail list logo
