Brent Dax wrote:
> Unfortunately, I only got two replies to my earlier message asking for
> guinea pigs (thanks to those who did reply), so there are probably
> cross-platform bugs still lurking in the depths of the new system.
Following problem on Win32 with MSVC++ 6:
perl Configure.pl
I've committed Configure.pl 2.0 (as anyone who's subscribed to
cvs-parrot can see--it generated no fewer than 35 commit messages).
It's now fully automated--it asks no questions. If you like the old
behavior, pass in the --ask switch at the command line.
Unfortunately, I only got two replies to
I hate to solicit, but I have a "favor" to ask someone who is willing. I
would very much enjoy attending the O'reilly Open Source convention,
particularly the Perl conference; however, I am less that wealthy (seeing
as how I'm only 17). Would someone extremely generous be willing to donate
an
> >The rest of this message assumes that the answer to A is "run time error".
>
> I'm not sure that's correct. Might just be a runtime warning,
I would assume not. How can we optimize if we just make it a warning?
At 8:11 PM -0400 5/23/02, Miko O'Sullivan wrote:
>From: "Chris Angell" <[EMAIL PROTECTED]>
>> I have an idea for the int() function. I think it would be cool if it
>> returned false/undefined when the argument passed to it is a
>> whole number.
>
>This is related to something I've been ponderi
From: "Chris Angell" <[EMAIL PROTECTED]>
> I have an idea for the int() function. I think it would be cool if it
> returned false/undefined when the argument passed to it is a
> whole number.
This is related to something I've been pondering about variables and typing.
Question A: In Perl6, how
On Fri, 24 May 2002, Peter Gibbs wrote:
> My current work is based on counting the size of freed buffers - yes,
> this adds some overhead in free_unused_buffers, but it seems like it
> may be worth it - and only doing compaction runs when a predefined
> fraction of the pool size is available for f
Steve Fink wrote:
Reading this made me wonder if we should consider cached string
transcodings,
if we don't end up storing strings in a single form internally. The worst
case is
probably string constants, which could be transcoded over and over again
into
the same alternate encoding. As an exten
# New Ticket Created by Tony Payne
# Please include the string: [netlabs #617]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=617 >
Fixed some minor bugs w/ the Optimizer, having to do mainly with
handling of labels.
Sean O'Rourke wrote:
> >I took a look at what was going on, and found that the GC probably needs
a
> >good tuning. For the 20K file, parrot is doing 217 collections of the
> >string pool, the last 102 of which reclaim less than 10% of the pool.
> >Changing compact_string_pool() to increase the po
The hashtable currently has correctness and efficiency problems
resulting from string encodings (and their interaction with garbage
collection).
Correctness example:
Currently, string hash values are computed by going straight to the
actual data and running a fairly typical hashing algorithm. Th
At 7:01 PM -0700 5/22/02, Sean O'Rourke wrote:
>I took a look at what was going on, and found that the GC probably needs a
>good tuning. For the 20K file, parrot is doing 217 collections of the
>string pool, the last 102 of which reclaim less than 10% of the pool.
>Changing compact_string_pool()
At 1:23 PM +0100 5/23/02, Peter Haworth wrote:
>On Tue, 21 May 2002 12:18:50 -0400, Dan Sugalski wrote:
>> At 8:44 AM -0500 5/20/02, brian wheeler wrote:
>> >I've been trying to catch up with parrot again (darn it, babies take more
>> >time than I thought :) and I've come up with a question...
At 8:55 PM +0200 5/23/02, Jens Rieks wrote:
> > Theoretically this shouldn't be done,
>In practice you can't assume something like that (at least when using
>callee-save calling convention), or do I miss the point?
Nope, you didn't miss the point. The GC assumes that the register
frames might b
> Theoretically this shouldn't be done,
In practice you can't assume something like that (at least when using
callee-save calling convention), or do I miss the point?
> but I put in a patch to the GC to double check, just in case.
Fine, tanks :)
cya,
Jens Rieks
I prefer it to work like this:
set S0,""
set IO,42
pack S0, 4, I0 ,0
length I1, S0 # is 4
pack S0, 4, I0
length I1, S0 # is 8
pack S0, 4, I0, 1 # no segv :)
length I1, S0 # is 10004
Patch is already applied.
Daniel Grunblatt.
On Thu, 23 May 2002, Sean O'Rourke wrot
I've added a file RESPONSIBLE_PARTIES to the repository listing the
folks who I remembered as having both CVS commit access and
responsibility for a particular piece of Parrot. (If you've just got
plain commit access you're not on there, which is arguably a Good
Thing--all the power with none
At 8:00 PM +0200 5/23/02, Jens Rieks wrote:
>I've attached a small pasm file that crashes Parrot. Seems to be a GC issue,
>it workes fine if "sweepoff" is added.
The GC assumes that the stack entries are always valid, and you
pushed invalid strings onto the stack. (The string register was NULL
Hi Folks!
I've attached a small pasm file that crashes Parrot. Seems to be a GC issue,
it workes fine if "sweepoff" is added.
Might be useful for debugging?
cya,
Jens Rieks
#
# small example that crashes parrot
#
set I1, 1
main: bsr print
inc I1
le I1, 100, main
At 9:39 AM -0400 5/23/02, Clinton A. Pierce wrote:
>[re-cc'd p6i due to mailer failure on my part]
>>At 10:17 PM 5/22/2002 +, via RT wrote:
>>Clinton A. Pierce wrote:
>>
>>> * sync up, and get the latest Parrot BASIC. It's fully hash-enabled and
>>> quite speedy now.
>>>
>>> * Run "basic.p
Let's try "patch that compiles"...
/s
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.143
diff -u -p -r1.143 core.ops
--- core.ops20 May 2002 17:52:28 - 1.143
+++ core.ops23 May 2002 15:03:31 -
@@ -1957,11 +1957,17 @@ inline op pack(inout STR, in INT, in
Aldo Calpini writes:
>
>hi there,
>the Examples page on www.parrotcode.org states this about subroutines:
>
>The first five registers (I0-I4, S0-S4, P0-P4, N0-N4) are scratch
>and do not have to be preserved by the callee.
>
>this seems to be false for *recursive* subroutines. this is my
On Thu, 23 May 2002, Daniel Grunblatt wrote:
>
> On Wed, 22 May 2002, Sean O'Rourke wrote:
>
> > that pack() can't handle null bytes makes it a bit more complicated (and
> Exactly how do you want it to handle null bytes?
Nevermind -- sorry 'bout that. There's a little wierdness in there, but
it
On Thu, 23 May 2002, Aldo Calpini wrote:
> hello people,
>
> I've implemented some print opcodes in JIT (for i386), but I would
> like to know your opinion about these before submitting a patch.
>
> in reality, there isn't a big performance boost, because I'm just
> calling printf as the C opcod
[re-cc'd p6i due to mailer failure on my part]
>At 10:17 PM 5/22/2002 +, via RT wrote:
>Clinton A. Pierce wrote:
>
>> * sync up, and get the latest Parrot BASIC. It's fully hash-enabled and
>> quite speedy now.
>>
>> * Run "basic.pl" to assemble the interpreter, and get it started
>>
On Wed, 22 May 2002, Sean O'Rourke wrote:
> This is an implementation of LZW compression in Parrot assembly. The fact
> that pack() can't handle null bytes makes it a bit more complicated (and
> limited) than it has to be, but for just text files, it seems to work just
> fine. It's probably a
On Tue, 21 May 2002 12:18:50 -0400, Dan Sugalski wrote:
> At 8:44 AM -0500 5/20/02, brian wheeler wrote:
> >I've been trying to catch up with parrot again (darn it, babies take more
> >time than I thought :) and I've come up with a question... how do you do
> >"other" things to PMCs that aren't no
hello people,
I've implemented some print opcodes in JIT (for i386), but I would
like to know your opinion about these before submitting a patch.
in reality, there isn't a big performance boost, because I'm just
calling printf as the C opcode does. it just saves some
push/pop/call/ret instruct
28 matches
Mail list logo
