Parrot_reallocate_string was missing one important feature - it did
never reallocate the string. It always allocated a new string and copied
data.
Execution of the test program below goes from 14s to 0.09 s (unoptimized
build, Athlon 800).
leo
_main:
set S0, ""
set I0, 10
time
WOOLLEY kj (via RT) wrote:
Just a simple set of code cleanups, and moving (mostly headers) to
PDD07 conformance (mostly guard statements).
Thanks, applied.
leo
WOOLLEY kj (via RT) wrote:
>
> Just a simple set of code cleanups, and moving (mostly headers) to
> PDD07 conformance (mostly guard statements).
Thanks, applied.
leo
On Apr 21, 2004, at 7:33 PM, Dan Sugalski wrote:
At 11:17 AM -0700 4/21/04, Jeff Clites wrote:
On Apr 21, 2004, at 10:20 AM, Dan Sugalski wrote:
Just to make sure... we're making sure the strings are always
properly decomposed before comparing, right?
Nope, this is a literal "equal" comparison--
Dan Sugalski wrote:
... (I'd like to avoid 30 minute compile
sessions--it's a tad tedious :)
Should be faster now by some factor.
How many symbols are in the biggest compilation unit (parrot -v
"registers in .imc")?
leo
On 21 Apr 2004, at 15:14, Dan Sugalski wrote:
I've got a Cunning Plan, oddly enough, though the margins of this
e-mail are too small to contain it. As soon as I get it finished I'm
going to pass it onto the list and to a few non-list folks who I know
are deep into this stuff (Autrijus and Dan K
On 21 Apr 2004, at 16:54, Dan Sugalski wrote:
Woohoo! Cool, and thanks very much.
No problem. I can't find someone to come on-board yet, but I did get
an answer to your question.
If he's up for it, could you ask him a question? Namely "Treating all
text as Unicode--good idea or bad idea?" If
Hello folks,
This will be of interest to only a few people, but it will be good to
have it in the archives for when we need it.
Here is a list of Korean character sets that represent hangul (Korean
symbols) and hanja (Sino-Korean):
- EUC-KR (KSC 5601, renamed to KS X 1001) or Microsoft's s
At 1:22 PM +0200 4/22/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
... (I'd like to avoid 30 minute compile sessions--it's a tad tedious :)
Should be faster now by some factor.
Cool, thanks. I've an optimized build of parrot going now, and I'll
see what things look like when it's dine.
How many
At 7:55 AM +0200 4/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
I think it may be a handy thing if someone'd go through and draw up a
set of rules for the use of temps, and things that'll cause the
register coloring algorithm to go mad. (I'd like to avoid 30 minute
com
Dan Sugalski wrote:
As I sit here and wait for parrot to churn on the output from compiling
a relatively small program
I've put in another factor ~2.5 change for a unit with 2000 temps.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Dunno what parrot thinks--it's not done yet. grep says 569 .locals
> and 473 temp PMC registers.
I've now enabled some more code that speeds up temp allocation more
(~2.5 for 2000 temps in a unit). This needs that the usage range is
limited to 10 lines. I
On Wed, 2004-04-21 at 13:51, Larry Wall wrote:
> In any event, it is absolutely my intent that the builtin array
> types of Perl 6 support PDL directly, both in terms of efficiency
> and flexibility. You ain't seen Apocalypse 9 yet, but that's what
> it's all about. Straight from my rfc list fil
On Wed, 2004-04-21 at 01:51, Larry Wall wrote:
> Note these just warp the defaults. Underneath is still a strongly
> typed string system. So you can say "use bytes" and know that the
> strings that *you* create are byte strings. However, if you get in a
> string from another module, you can't n
A good register allocation algorithm will always have problems with
big subs, there is nothing that we can do about it.
I think that what "real compilers" do to solve this problem is
implement two different algorithms: one for normal subs which tries
to generate optimal code, and a naive one f
Ok, so I got to thinking about Parrot and compilation last night. Then
something occurred to me, and I'm not sure how it works.
When Perl sees:
class Joe { my $.a; method b {...} }
my Joe $j;
Many things happen and some of them will require knowing what the result
of the previous
At 4:03 PM +0200 4/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Dunno what parrot thinks--it's not done yet. grep says 569 .locals
and 473 temp PMC registers.
I've now enabled some more code that speeds up temp allocation more
(~2.5 for 2000 temps in a unit). This needs
At 10:48 AM -0400 4/22/04, Aaron Sherman wrote:
Ok, so I got to thinking about Parrot and compilation last night. Then
something occurred to me, and I'm not sure how it works.
When Perl sees:
class Joe { my $.a; method b {...} }
my Joe $j;
Many things happen and some of them will r
At 6:03 PM -0600 4/21/04, kj wrote:
Hello folks,
This will be of interest to only a few people, but it will be good
to have it in the archives for when we need it.
Here is a list of Korean character sets that represent hangul
(Korean symbols) and hanja (Sino-Korean):
- EUC-KR (KSC 5601, re
On Apr 21, 2004, at 4:52 PM, kj wrote:
- there are (of course) some character sets that don't work well with
Unicode -- for example, Big5HKSCS doesn't encode in UCS2 (though I
didn't find out why)
UCS-2 is limited--it can only address the BMP (that is, only 2^16
characters). It has been superse
If I use a C++ compiler to include embed.h:
In file included from /Users/nick/Ponie/ponie06/parrot/include/parrot/embed.h:19,
from perl.h:31,
from miniperlmain.c:27:
/Users/nick/Ponie/ponie06/parrot/include/parrot/interpreter.h:59: error: conflicting
types for
On Apr 22, 2004, at 8:31 AM, Dan Sugalski wrote:
At 6:03 PM -0600 4/21/04, kj wrote:
The URL above goes to a useful table for working with johab. I do
know it is a legacy charset, but I don't know how much it is still
used. Technically, ASCII is legacy, too. :)
Ah, at this point Unicode's
Nicholas Clark wrote:
Pain being due to these two:
struct Parrot_Interp;
typedef struct Parrot_Interp *Parrot_Interp;
This doesn't seem right.
It is and it isn't. The naming conventions say that struct
Parrot_Interp should really be struct parrot_interp_t, but that's a
ginormous global change
At 8:51 AM -0700 4/22/04, Jeff Clites wrote:
On Apr 22, 2004, at 8:31 AM, Dan Sugalski wrote:
At 6:03 PM -0600 4/21/04, kj wrote:
The URL above goes to a useful table for working with johab. I
do know it is a legacy charset, but I don't know how much it is
still used. Technically, ASCII is
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> registers needed:I43, N0, S12, P3327
> registers in .pasm: I25, N0, S20, P32 - 464 spilled
> 2007 basic_blocks, 2079 edges
Ouch. Register allocation is spending huge times during spilling.
Something is definetely wro
> "Dan" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> More to the point, Perl 6's compiler will have to parse "class Joe",
>> create a new object of type Class, parse and execute the following
>> block/closure in class MetaClass, assign the result into the new Class
>> object named Joe and th
On Thu, Apr 22, 2004 at 10:48:51AM -0400, Aaron Sherman wrote:
: 1. Have a feedback loop between Parrot and Perl 6 that allows the
: compiler to execute a chunk of bytecode, get the result as a PMC
: and store it for future use. This will probably be needed
: regardless
> Ah, at this point Unicode's legacy too. Besides, as long as RAD-50
> lives, nobody's got much standing to call a character set "Legacy" :)
I suggest Parrot's native character set to be cuneiform.
At 6:04 PM +0200 4/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
registers needed:I43, N0, S12, P3327
registers in .pasm: I25, N0, S20, P32 - 464 spilled
2007 basic_blocks, 2079 edges
Ouch. Register allocation is spending huge times
On Apr 22, 2004, at 9:01 AM, Dan Sugalski wrote:
At 8:51 AM -0700 4/22/04, Jeff Clites wrote:
On Apr 22, 2004, at 8:31 AM, Dan Sugalski wrote:
At 6:03 PM -0600 4/21/04, kj wrote:
The URL above goes to a useful table for working with johab. I
do know it is a legacy charset, but I don't know h
On Thu, Apr 22, 2004 at 11:22:32AM -0400, Dan Sugalski wrote:
: Erm... no. Not even close, really. There's really nothing at all
: special about this--it's a very standard user-defined type issue,
: dead-common compiler stuff. You could, if you wanted, really
: complicate it, but there's no reas
On Thu, Apr 22, 2004 at 10:29:39AM -0400, Aaron Sherman wrote:
: That said, I now see why hyper goes in Parrot... maybe. It depends on
: how dynamic Perl is about lazy arrays (e.g. "my int @foo = 1..Inf")
As dynamic as it needs to be. The built-in array type has to know how
much of the array is r
At 9:20 AM -0700 4/22/04, Larry Wall wrote:
On Thu, Apr 22, 2004 at 11:22:32AM -0400, Dan Sugalski wrote:
: Erm... no. Not even close, really. There's really nothing at all
: special about this--it's a very standard user-defined type issue,
: dead-common compiler stuff. You could, if you wanted, re
On Thu, Apr 22, 2004 at 12:42:49PM -0400, Dan Sugalski wrote:
: But that's completely irrelevant to the original question, about
: lexical variable classes. I presume you've got a point you're making?
Yes, my point is you didn't actually answer his question.
Larry
On Thu, 2004-04-22 at 11:22, Dan Sugalski wrote:
> At 10:48 AM -0400 4/22/04, Aaron Sherman wrote:
> >More to the point, Perl 6's compiler will have to parse "class Joe",
> >create a new object of type Class, parse and execute the following
> >block/closure in class MetaClass, assign the result in
On Thu, 2004-04-22 at 09:17, Jarkko Hietaniemi wrote:
> > Ah, at this point Unicode's legacy too. Besides, as long as RAD-50
> > lives, nobody's got much standing to call a character set "Legacy" :)
>
> I suggest Parrot's native character set to be cuneiform.
... but only for constants.
-- c
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I was using .locals for the actual variables in the source program,
Well, you know it: .locals aren't vars.
> and $Px for all the temps the compiler generated. I've been migrating
> a lot of the code to use a few .local-defined hashes and indexing
> into
At 1:05 PM -0400 4/22/04, Aaron Sherman wrote:
On Thu, 2004-04-22 at 11:22, Dan Sugalski wrote:
At 10:48 AM -0400 4/22/04, Aaron Sherman wrote:
>More to the point, Perl 6's compiler will have to parse "class Joe",
>create a new object of type Class, parse and execute the following
>block/closu
Dan Sugalski wrote:
At 6:03 PM -0600 4/21/04, kj wrote:
Hello folks,
This will be of interest to only a few people, but it will be good
to have it in the archives for when we need it.
Here is a list of Korean character sets that represent hangul
(Korean symbols) and hanja (Sino-Korean):
On Thu, 2004-04-22 at 14:44, Dan Sugalski wrote:
> At 1:05 PM -0400 4/22/04, Aaron Sherman wrote:
> >This is in direct contradiction to what I'm hearing from you, Dan.
> >What's the scoop?
>
> The scoop is that
>
> my Joe $foo;
>
> emits the code that, at runtime, finds the class ID of what
On Apr 20, 2004, at 11:22 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
Here's another tiny patch, to let us fast-fail string_equal if we have
cached hashval's which don't match.
What about a hash value collision?
If the hash values are equal, it proceeds on to do the full com
At 2:48 AM -0700 4/22/04, Jeff Clites wrote:
On Apr 21, 2004, at 7:33 PM, Dan Sugalski wrote:
At 11:17 AM -0700 4/21/04, Jeff Clites wrote:
On Apr 21, 2004, at 10:20 AM, Dan Sugalski wrote:
Just to make sure... we're making sure the strings are always
properly decomposed before comparing, right?
Aaron Sherman writes:
> But according to A12 as I understand it, the part BEFORE that, which
> looked innocently like a definition:
>
> class Joe { my $.a; method b {...} }
>
> would actually get turned into a BEGIN block that executes the body of
> the class definition as a closure in clas
On Wed, 2004-04-21 at 15:46, Larry Wall wrote:
> On Wed, Apr 21, 2004 at 03:15:37PM -0400, Dan Sugalski wrote:
> : The math folks tell me it makes sense. I can come up with a
> : half-dozen non-contrived examples, and will if I have to. :-P
>
> I've said this before, and I'll keep repeating it ti
On Thu, 2004-04-22 at 15:37, Luke Palmer wrote:
> But Perl 6 is tightly coupled with Parrot. Perl 6 will be a Parrot
> program (even if it calls out to C a lot), and can therefore use the
> compreg opcodes. That means that any code executing in Parrot can call
> back out to the Perl 6 compiler,
At 3:58 PM -0400 4/22/04, Aaron Sherman wrote:
On Wed, 2004-04-21 at 15:46, Larry Wall wrote:
On Wed, Apr 21, 2004 at 03:15:37PM -0400, Dan Sugalski wrote:
: The math folks tell me it makes sense. I can come up with a
: half-dozen non-contrived examples, and will if I have to. :-P
I've said thi
>>>Ah, at this point Unicode's legacy too. Besides, as long as RAD-50
>>>lives, nobody's got much standing to call a character set "Legacy" :)
>>
>>I suggest Parrot's native character set to be cuneiform.
>
>
> ... but only for constants.
Yeah, I was going to propose the Phaistos disc signs for
Jens Rieks wrote:
It is and it isn't. The naming conventions say that struct
Parrot_Interp should really be struct parrot_interp_t, but that's a
ginormous global change. I've tried to implement it once or twice, but
my most recent attempt cause mysterious compile errors.
I've prepared a patch for
This is actually a couple of questions:
1: can you extend roles by saying: role Set is extended {}
2: if yes, does this change variables for which you said $var does Set?
In other words, is the singleton class like a closure or a first-class
class?
What follows is just some example code in case
On Mon, 2004-04-19 at 12:18, Larry Wall wrote:
> On Mon, Apr 19, 2004 at 11:44:24AM -0400, Dan Sugalski wrote:
> : For that they leave it to lambda.weblogs.com to heap *educated* scorn
> : and derision on things. :)
>
> Hmm, well, in all their educatedness, they don't seem to have figured
> out t
On Tue, 2004-04-20 at 10:51, John Siracusa wrote:
> Hm, so how would the "is required" trait that Damian posted work? Would it
> simply be shorthand for a run-time check that I don't have to write myself?
> I was under the impression that it would work the way I described earlier:
>
> sub fo
On 4/22/04 5:33 PM, Aaron Sherman wrote:
> On Tue, 2004-04-20 at 10:51, John Siracusa wrote:
>> Hm, so how would the "is required" trait that Damian posted work? Would it
>> simply be shorthand for a run-time check that I don't have to write myself?
>> I was under the impression that it would work
On 4/22/04 6:52 PM, John Siracusa wrote:
> Yes, it appears that runtime checks for the existence of required params
> will continue to be a necessary part of Perl programming.
...of course, there are at least two ways to do "runtime checks":
* runtime checks that the programmer has to write h
On Apr 19, 2004, at 3:41 PM, Marcus Thiesen wrote:
As I'm currently at my fathers place I had the time and resources to
do some cygwin and native win32 testing.
Great!
I can't get it to work under Cygwin since the ICU changes because it
tries to
do some linking stuff that fails
...
Next I tri
54 matches
Mail list logo
