[CVS ci] Parrot_reallocate_string

[Leopold Toetsch]

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 N0
lp:
concat S0, "1234567890"
dec I0
if I0, lp
time N1
sub N1, N0
print "Len "
length I1, S0
print I1
print " time "
print N1
print "\n"
end

Re: [perl #29034] [PATCH] miscellaneous cleanup and PDD07-conformance

[Leopold Toetsch]

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

Re: [perl #29034] [PATCH] miscellaneous cleanup and PDD07-conformance

[Leopold Toetsch via RT]

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

Re: Constant strings - again

[Jeff Clites]

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--you'd build a normalized 
compare on top of this.
I think this got caught on the list queue for a bit, and it's already 
been addressed, but just to be clear, Parrot's keeping decomposable 
characters decomposed, and generally normalizing, or at least 
pretending it's normalizing if it doesn't actually do so, when working 
with strings.
Yes, in order to define notions of normalized equivalence, you need a 
notion of strict equality on which to base them. string_equal() is the 
latter; the former are yet-to-be-coded.

JEff

Re: IMCC temp optimizations...

[Leopold Toetsch]

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

Re: Constant strings - again

[kj]

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 Kogai, if I can get in 
touch. I *really* wish I had someone who did mainly Korean text 
processing handy...) and we'll see where we go from there. I have no 
doubt it'll be... fun. Yeah, that's the word, fun!
  I asked a friend of mine about lending a hand with Korean, but he 
will be too busy for the next little while.  He did say that he will 
pass on the info to another person who might be able to lend a hand, 
though.  Hopefully you'll have your wish soon, Dan.

Cheers,

  ~kj

Re: Constant strings - again

[kj]

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 the answer's going to be a 
lot of work you can skip it, that's OK.
  The answer is fairly straight-forward, fortunately.

  Talking to Burnhard and perky on HanIRC, I was able to get the 
following information:

- 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)

- that being said, the consensus was that internal storage as Unicode 
is a good idea for modern programming languages and APIs.

- Tcl/Tk's method of per-FH filters for EUC, johab, etc. seems to be 
useful and well-received.

  So in essence, what I got from the conversation was that internal 
storage as Unicode is a good thing (and indeed, expected), so long as a 
method for conversion on input/output is provided.

  Sorry if that doesn't answer all the nuances of the question, but 
that's the best I can do for now.

Cheers,

  ~kj

Korean character set info

[kj]

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 superset UHC
- ISO-2022 comes in both -JP and -KR versions.
- johab is a legacy 16-bit encoding, leading bit = 1 + 3 * 5 bits for 
leading consonant, vowel, optional consonant(s) at the end
http://trade.chonbuk.ac.kr/~leesl/code/johap.gif

  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.  :)

  Do we have any local experts on Japanese charsets?  If not, I can do 
a little bit of research there, too.

Cheers,

  ~kj

Re: IMCC temp optimizations...

[Dan Sugalski]

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 symbols are in the biggest compilation unit (parrot -v 
"registers in .imc")?
Dunno what parrot thinks--it's not done yet. grep says 569 .locals 
and 473 temp PMC registers. ($Px) I think that can reasonably be 
considered A Lot. I'm rejigging the compiler to cut down on the 
number of .local declarations, but that'll increase the temp pmc 
usage, at least with the relatively simple temp system I've got now. 
(I can throw dummy labels in to create fake basic blocks if that'll 
help the register coloring code)
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: IMCC temp optimizations...

[Dan Sugalski]

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
 compile sessions--it's a tad tedious :)
Are you still sticking everything in one big _main?
Except for the library code, yup. No way around that.
--
Dan
--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: IMCC temp optimizations...

[Leopold Toetsch]

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

Re: IMCC temp optimizations...

[Leopold Toetsch]

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. If the code from a compiler looks like the output
from the program below, this works fine.

> ... I'm rejigging the compiler to cut down on the
> number of .local declarations, but that'll increase the temp pmc
> usage, at least with the relatively simple temp system I've got now.

Temps are fine. ".local"s ranging from top of the program (not counting
the declaration) down do hurt. Many small short ranged temps are much
better then long ranged vars because they have more interferences on
each other.

> (I can throw dummy labels in to create fake basic blocks if that'll
> help the register coloring code)

That makes it worse. More blocks, more life ranges to compare.

If you can emit code similar to "gen.pl" it could take advantage of my
last change.

leo

$ cat gen.pl
#!/usr/bin/perl
use strict;

#  a = 1 + 1 + 1 ... + 1

my ($i, $t, $N);
$N = $ARGV[0] || 299;
print ".sub _main [EMAIL PROTECTED]";
$t++;
print "\t\$P$t = new PerlInt\n";
print "\t\$P$t = 1\n";
for $i (0..$N) {
$t++;
print "\t\$P$t = new PerlInt\n";
print "\t\$P$t = 1\n";
$t++;
print "\t\$P$t = new PerlInt\n";
print "\t\$P$t = [EMAIL PROTECTED] + [EMAIL PROTECTED]";
}
print "\tprint \$P$t\n";
print "\tprint \"\\n\"\n";
print ".end\n";

Re: hyper op - proof of concept

[Aaron Sherman]

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 file:

Ok, the combination of Dan's (perhaps overzealous) emphasis on the
dynamic nature of Parrot's client languages and my assumption that we
had learned all there was to learn about the storage of aggregates
mislead me here.

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") and
what happens when I:

my int @foo = 1..3;
$foo[0] = URI::AutoFetch.new("http://numberoftheweek.math.gov/";);

If that's polymorphic, we're hosed. If it's an auto-conversion, then
we're good. I like the polymorphic version for a lot of reasons, but
I'll understand if we can't get that.

Thanks all!

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

Re: A12: Strings

[Aaron Sherman]

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 necessarily process it as bytes.

But, what happens if I:

{
use bytes;
my string $line = $filehandlelikething.getline;
}

Does my saying "string" enforce anything, or do I have to:

{
use bytes;
my string $line is bytes = $filehandlelikething.getline;
}

?

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

Re: IMCC temp optimizations...

[Angel Faus]

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 for very large subs with 
many virtual registers. 

That makes compilation much faster, and the execution penalty doesn't 
hurt too much.

Actually, it's (for me) an open question whether the "good" register 
allocation should be the default one. Perl (and python and..) users 
expect blazing compilation times, so maybe we should reserve it for 
higher -O levels.

But then, we won't know how bad are our compilation times until there 
are "real" programs written in perl6/parrot.

-angel


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 that the usage range is
> limited to 10 lines. If the code from a compiler looks like the
> output from the program below, this works fine.

A12: The dynamic nature of a class

[Aaron Sherman]

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 thing is.

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 then continue parsing, needing access to the values
that were just created in order to further parse the declaration of $j

There are several ways this can be accomplished:

 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 of which option is chosen, but may not be ideal.
 2. Have a pseudo Perl 6 interpreter in the compiler which can
execute a limited subset of Perl 6 that is allowed inside of
class and module definitions (Larry implied that they were not
limited in this way, but if they were, compilation could be
optimized a bit).
 3. Attempt to build a one-shot, bytecode stream that outputs a
bytecode stream that represents the program. This would be the
fastest in the general case, and would make pre-bytecoded
libraries much easier to implement. However, it would also mean
that class and module definitions could not affect the grammar
of the language, and Larry has said that won't be the case :-(

To me, #2 looks most attractive, but requires some duplication of
effort.

How easy would it be to interact with Parrot in the way that #1
proposes?

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

Re: IMCC temp optimizations...

[Dan Sugalski]

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 that the usage range is
limited to 10 lines. If the code from a compiler looks like the output
from the program below, this works fine.
This sped it up a lot. The output is:

Starting parse...
sub _MAIN:
registers in .imc:   I34, N0, S7, P1014
0 labels, 0 lines deleted, 0 if_branch, 0 branch_branch
0 used once deleted
0 invariants_moved
registers needed:I43, N0, S12, P3327
registers in .pasm:  I25, N0, S20, P32 - 464 spilled
2007 basic_blocks, 2079 edges
13691 lines compiled.
Writing sample.pbc
packed code 348208 bytes
sample.pbc written.
Which actually came out in reasonable time, rather than me giving up 
after 45 minutes. :) Still takes ages, so I've a lot of work to do 
here.

 > ... I'm rejigging the compiler to cut down on the
 number of .local declarations, but that'll increase the temp pmc
 usage, at least with the relatively simple temp system I've got now.
Temps are fine. ".local"s ranging from top of the program (not counting
the declaration) down do hurt. Many small short ranged temps are much
better then long ranged vars because they have more interferences on
each other.
Hrm. Does the code currently consider something like:

  $P0 = foo

to start a new lifetime for $P0?

--
Dan
--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: A12: The dynamic nature of a class

[Dan Sugalski]

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 require knowing what the result
of the previous thing is.
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 then continue parsing, needing access to the values
that were just created in order to further parse the declaration of $j
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 reason to and unless someone really 
messes up we're not going to. Just no need.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Korean character set info

[Dan Sugalski]

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, renamed to KS X 1001) or Microsoft's superset UHC
- ISO-2022 comes in both -JP and -KR versions.
- johab is a legacy 16-bit encoding, leading bit = 1 + 3 * 5 bits 
for leading consonant, vowel, optional consonant(s) at the end
http://trade.chonbuk.ac.kr/~leesl/code/johap.gif
Ah, cool. Looks like that stuff's in the O'reilly CJKV book (which I 
desperately want a second edition of) but that book's a bit slanted 
towards Chinese and Japanese.

  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 legacy too. Besides, as long as RAD-50 
lives, nobody's got much standing to call a character set "Legacy" :)

  Do we have any local experts on Japanese charsets?  If not, I can 
do a little bit of research there, too.
There, at least, I can get access to folks who've done work, and I 
can get by enough myself that I'm not too worried.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Constant strings - again

[Jeff Clites]

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 superseded by the UTF-* encodings. (UTF-16 can 
be thought of as UCS-2 plus surrogate pairs.)

It's my understanding that all of the characters HKSCS-2001 are 
available in Unicode 4.0 (with 35 rarely-used character being mapped 
into the private use area).

Necessarily, Unicode lags behind revisions to national standards--it 
takes time to incorporate the changes--but, so does everything else 
(inclusion of new characters into fonts, etc.).

JEff

embed.h doesn't work in C++

[Nicholas Clark]

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 `typedef struct Parrot_Interp*Parrot_Interp'


Pain being due to these two:

struct Parrot_Interp;

typedef struct Parrot_Interp *Parrot_Interp;


This doesn't seem right.

Nicholas Clark

Re: Korean character set info

[Jeff Clites]

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 legacy too. Besides, as long as RAD-50 
lives, nobody's got much standing to call a character set "Legacy" :)
Unicode is an actively evolving standard. It's far from legacy.

JEff

Re: embed.h doesn't work in C++

[Brent 'Dax' Royal-Gordon]

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.  I've tried to implement it once or twice, but 
my most recent attempt cause mysterious compile errors.

You're welcome to try it again, though...while you're at it, you might 
as well make all internal Parrot functions take an Interp * instead of a 
struct Parrot_Interp *.  That ought to save us a couple kilobytes.

--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.

Re: Korean character set info

[Dan Sugalski]

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 legacy, too.  :)
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" 
:)
Unicode is an actively evolving standard. It's far from legacy.
That evolution is what does it--every deployed version of Unicode is 
legacy, as there's always something to supplant it. Which arguably 
makes things worse in some cases--I'm waiting for us to run into 
problems when we start handing Unicode 4.0-compatible text off to 
system services expecting 3.x or 2.x code. Made worse in some ways 
because almost nobody'll notice, since most everyone we have doing 
stuff can get by with what the 2.0 standard provides.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: IMCC temp optimizations...

[Leopold Toetsch]

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 wrong with your code - wrong in the sense of: it
doesn't play with, what imcc expects ;)

You must have too much pseudo-globals in that unit, spanning a huge
range and interfering with one another. Do you use lexical vars or
Parrot globals?

> Hrm. Does the code currently consider something like:

>$P0 = foo

> to start a new lifetime for $P0?

If you don't use $P0 beyond that point yes. Do you name all
temps $P0 or some such? Or are you giving them unique names. You should
do the latter.

leo

Re: A12: The dynamic nature of a class

[Randal L. Schwartz]

> "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 then continue parsing, needing access to the values
>> that were just created in order to further parse the declaration of $j

Dan> Erm... no. Not even close, really. There's really nothing at all
Dan> special about this--it's a very standard user-defined type issue,
Dan> dead-common compiler stuff. You could, if you wanted, really
Dan> complicate it, but there's no reason to and unless someone really
Dan> messes up we're not going to. Just no need.

Yes, there's no need to visit the construction jobsite to figure out
the length of a 2x4 crossbeam if you already have the blueprints in
front of you.

Unless you like to waste gas. :-)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: A12: The dynamic nature of a class

[Larry Wall]

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 of which option is chosen, but may not be ideal.

#1 is a requirement for the general case.  Of course to the extent
that people stick with standard constructs they can be optimized.
But Perl 5's BEGIN blocks are just a start.  In Perl 6 people can add
arbitrary productions into the grammar that execute arbitrary code.
They can define their own metaclasses.  Traits are applied at compile
time by arbitrary bits of code.  Macros are applied by executing bits
of code you just compiled.  And so on.

Larry

Re: Korean character set info

[Jarkko Hietaniemi]

> 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.

Re: IMCC temp optimizations...

[Dan Sugalski]

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 during spilling.
Something is definetely wrong with your code - wrong in the sense of: it
doesn't play with, what imcc expects ;)
Yep, the 45 minute compile times were the hint that maybe imcc and I 
were fighting a bit. :)

You must have too much pseudo-globals in that unit, spanning a huge
range and interfering with one another. Do you use lexical vars or
Parrot globals?
I was using .locals for the actual variables in the source program, 
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 them, and it looks like that's the way to go. (This'd be easier 
if this language had, y'know, actual subroutines and stuff...)

 > Hrm. Does the code currently consider something like:

$P0 = foo

 to start a new lifetime for $P0?
If you don't use $P0 beyond that point yes. Do you name all
temps $P0 or some such? Or are you giving them unique names. You should
do the latter.
I've a lot of 'constant' temps named $P0. I'll go fix that and see where we go.
--
Dan
--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Korean character set info

[Jeff Clites]

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 how much it is 
still used.  Technically, ASCII is legacy, too.  :)
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" 
:)
Unicode is an actively evolving standard. It's far from legacy.
That evolution is what does it--every deployed version of Unicode is 
legacy, as there's always something to supplant it. Which arguably 
makes things worse in some cases--I'm waiting for us to run into 
problems when we start handing Unicode 4.0-compatible text off to 
system services expecting 3.x or 2.x code. Made worse in some ways 
because almost nobody'll notice, since most everyone we have doing 
stuff can get by with what the 2.0 standard provides.
Take a look at the following two pages for information on how the 
Unicode standard deals with change. It's exceedingly conservative, and 
designed specifically so that the sorts of problems you seem to be 
worrying about, in fact do not exist. The point of revisions is mainly 
to add new characters, and of course a system based on an older 
revision of the standard will not know about these characters, but 
since day 1 systems have needed to deal gracefully with unassigned code 
points. It's a non-problem.

http://www.unicode.org/faq/cope_change.html
http://www.unicode.org/standard/stability_policy.html
Unicode has been carefully designed with this sort of stability to 
change (or, backwards-compatibility, if you will) in mind.

JEff

Re: A12: The dynamic nature of a class

[Larry Wall]

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 reason to and unless someone really 
: messes up we're not going to. Just no need.

Okay, how do you run a BEGIN block?

Larry

Re: hyper op - proof of concept

[Larry Wall]

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 really there already, and how to build the rest of the
array on demand.

: and what happens when I:
: 
:   my int @foo = 1..3;
:   $foo[0] = URI::AutoFetch.new("http://numberoftheweek.math.gov/";);
: 
: If that's polymorphic, we're hosed. If it's an auto-conversion, then
: we're good. I like the polymorphic version for a lot of reasons, but
: I'll understand if we can't get that.

It's auto-conversion.  An "int" declaration is a strong guarantee that
the thing is never going to be required to store a random scalar.  On
the other hand, and "Int" declaration merely requires that the scalar
stored "does" Int.

Larry

Re: A12: The dynamic nature of a class

[Dan Sugalski]

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, really
: complicate it, but there's no reason to and unless someone really
: messes up we're not going to. Just no need.
Okay, how do you run a BEGIN block?
You call the anonymous sub that's been created for it. How *else* 
would you run a BEGIN block?

But that's completely irrelevant to the original question, about 
lexical variable classes. I presume you've got a point you're making?
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: A12: The dynamic nature of a class

[Larry Wall]

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

Re: A12: The dynamic nature of a class

[Aaron Sherman]

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 into the new Class
> >object named Joe and then continue parsing, needing access to the values
> >that were just created in order to further parse the declaration of $j
> 
> 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 reason to and unless someone really 
> messes up we're not going to. Just no need.

That's not at all what A12 said. And, I quote:

One of the big advances in Perl 5 was that a program could be in
charge of its own compilation via use statements and BEGIN
blocks. A Perl program isn't a passive thing that a compiler has
its way with, willy-nilly. It's an active thing that negotiates
with the compiler for a set of semantics. In Perl 6 we're not
shying away from that, but taking it further, and at the same
time hiding it in a more declarative style. So you need to be
aware that, although many of the things we'll be talking about
here look like declarations, they trigger Perl code that runs
during compilation.

This is in direct contradiction to what I'm hearing from you, Dan.
What's the scoop?

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

Re: Korean character set info

[chromatic]

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

Re: IMCC temp optimizations...

[Leopold Toetsch]

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 them, and it looks like that's the way to go.

If you use a hash anyway, just use globals - this seems to match the
target language's POV:

  $Px = global "foo"  # fetch
  global "foo" = $Py  # store

If spilling is still needed, the spill code can be improved, if the
variable already has a store (like a lexical or a global). Needs only
cutting down the life range, and a refetch in the other locations of
usage. This saves the store and simplifies spilling.

But if you treat all your variables like that, there will be no spilling
at all.

> ... (This'd be easier
> if this language had, y'know, actual subroutines and stuff...)

Yep.

leo

Re: A12: The dynamic nature of a class

[Dan Sugalski]

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/closure in class MetaClass, assign the result into the new Class
 >object named Joe and then continue parsing, needing access to the values
 >that were just created in order to further parse the declaration of $j
 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 reason to and unless someone really
 messes up we're not going to. Just no need.
That's not at all what A12 said. And, I quote:

One of the big advances in Perl 5 was that a program could be in
charge of its own compilation via use statements and BEGIN
blocks. A Perl program isn't a passive thing that a compiler has
its way with, willy-nilly. It's an active thing that negotiates
with the compiler for a set of semantics. In Perl 6 we're not
shying away from that, but taking it further, and at the same
time hiding it in a more declarative style. So you need to be
aware that, although many of the things we'll be talking about
here look like declarations, they trigger Perl code that runs
during compilation.
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 whatever Joe's 
in scope, instantiates a new object of that class, and sticks it into 
the $foo lexical slot that's in scope at runtime. It's possible you 
could redefine the grammar to have it do something different, in 
which case I suppose the answer's "whatever you've convinced the 
compiler to do" but in that case the question's essentially 
meaningless, since you could, if you wanted, define it such that 
invoking the perl 6 grammar reformatted your hard drives or something.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Korean character set info

[George R]

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):

- EUC-KR (KSC 5601, renamed to KS X 1001) or Microsoft's superset UHC
- ISO-2022 comes in both -JP and -KR versions.
- johab is a legacy 16-bit encoding, leading bit = 1 + 3 * 5 bits for 
leading consonant, vowel, optional consonant(s) at the end
http://trade.chonbuk.ac.kr/~leesl/code/johap.gif


Ah, cool. Looks like that stuff's in the O'reilly CJKV book (which I 
desperately want a second edition of) but that book's a bit slanted 
towards Chinese and Japanese.

  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 legacy too. Besides, as long as RAD-50 
lives, nobody's got much standing to call a character set "Legacy" :)

  Do we have any local experts on Japanese charsets?  If not, I can 
do a little bit of research there, too.


There, at least, I can get access to folks who've done work, and I can 
get by enough myself that I'm not too worried.
I don't agree with the Unicode legacy comment... :-(

But if you want to see another source of mapping tables, you can try 
this one: http://oss.software.ibm.com/icu/charset/index.html

I'm sure Dan and others are aware of ICU's charset repository. It 
contains mapping tables that I have been able collect from various 
platforms.  Others may find it useful too.

Unicode can also represent the hangul and hanja characters.

George

Re: A12: The dynamic nature of a class

[Aaron Sherman]

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 whatever Joe's 
> in scope, instantiates a new object of that class, and sticks it into 
> the $foo lexical slot that's in scope at runtime.

Right, ok, good. I gotcha.

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 class MetaClass and stores the
result into a new object (named "Joe") of class Class.

Perl 6's compiler does not (by default, at least) know how to run code.
It just knows how to translate that text into bytecode (or IMCC or
something). So it will need SOMETHING to execute, possibly multiple
times with parsing going on before, after or during some of those
executions.

During is the hard one. That means you have to actually call back from
Parrot into the Perl 6 compiler. But, even the simple:

eval "eval 'eval 1' "

causes that problem. How does Ponie deal with that? Does it simply act
as an interpreter for the first pass and then do code-gen ala -MO ? If
so, that's a nice dodge, but putting a full Perl 6 interpreter into Perl
6's compiler seems to me to be a tad heavy-weight.

Thoughts? Am I missing a simple way to get around this?

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

Re: Constant strings - again

[Jeff Clites]

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 comparison. 
It's only in the case where the hash values are inequal (and neither is 
zero) that it can know the strings are inequal, and stop without doing 
the full comparison.

(string_equal returns 1 to indicate !=, which matches string_compare 
but is the opposite of what you'd expect.)

JEff

Re: Constant strings - again

[Dan Sugalski]

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?
Nope, this is a literal "equal" comparison--you'd build a 
normalized compare on top of this.
I think this got caught on the list queue for a bit, and it's 
already been addressed, but just to be clear, Parrot's keeping 
decomposable characters decomposed, and generally normalizing, or 
at least pretending it's normalizing if it doesn't actually do so, 
when working with strings.
Yes, in order to define notions of normalized equivalence, you need 
a notion of strict equality on which to base them. string_equal() is 
the latter; the former are yet-to-be-coded.
I think, honestly, that for strings in a character set with multiple 
variants that are declared equal, I want them strict equality to be 
based on the canonical form of the strings rather than the binary 
form. For Unicode the standard defines them as identical, and if we 
have a mix of "really identical" and "logically identical" tests 
we're going to get a lot of subtle and damned annoying bugs seeping 
in.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: A12: The dynamic nature of a class

[Luke Palmer]

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 class MetaClass and stores the
> result into a new object (named "Joe") of class Class.
> 
> Perl 6's compiler does not (by default, at least) know how to run code.

There's where you're wrong.  In the static languages world, they like to
make the target architicture independent of the compiler's architecture.
C++ does this (and runs into rather a problem doing so, because of the
treatment of templates).

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, and obviously the Perl 6 compiler can
call out to parrot.

So:

  eval "eval 'eval 1'";
#(a(b(c )) )

Goes through this process:

Perl 6 compiles (a)
Perl 6 tells Parrot to run (a)
Parrot calls out to Perl 6 to compile (b)
Perl 6 tells Parrot to run (b)
Parrot call out to Perl 6 to compile (c)
Perl 6 tells Parrot to run (c)
The result is 1
The result is 1
The result is 1
...

Luke

Re: hyper op - proof of concept

[Aaron Sherman]

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 till it sinks in.
> The math folks are completely, totally, blazingly untrustworthy on
> this subject. [...] They can't have my »« without a fight.

Ah... now you see the true face of the age-old Linguistics-Mathematics
wars! ;-)

But seriously, to summarize what I've learned from this thread:

  * "my int @foo" will compile down into an efficient representation
  * PDL (and its like) will be able to use this to efficiently
perform high-level operations on arrays, but only built-in
operations
  * If someone (e.g. PDL) wants to implement other operations and
their hyper-equivalent, they can do it in a high level language
like P6 or as run-time loadable parrot opcodes (which PDL will
certainly have to do, since most of their ops are in an ancient
and gigantic Fortran lib).

Sounding like problem solved to me! Thanks Larry.

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

Re: A12: The dynamic nature of a class

[Aaron Sherman]

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, and obviously the Perl 6 compiler can
> call out to parrot.

Clearly my question was garbled the first time, as this answer is
exactly what I was looking for. Thanks!

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

Re: hyper op - proof of concept

[Dan Sugalski]

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 this before, and I'll keep repeating it till it sinks in.
 The math folks are completely, totally, blazingly untrustworthy on
 this subject. [...] They can't have my »« without a fight.
Ah... now you see the true face of the age-old Linguistics-Mathematics
wars! ;-)
Just to be clear here, for the archive:

Perl 6's hyper operators *will* use hyper vtable 
slots in the PMCs, and will use the hyper 
versions of the opcodes. Leo and I are going to 
fight out the "Do we have lots of ops or do we 
use a shift opcode" implementation details. 
Whether or not Larry allows overriding the hyper 
vtable slots in the base grammar is up to him. So:

$a = $b + $c # VTABLE_add($b, $c, $a)
$a = $b[1] + $c  # VTABLE_add_keyed($b, key(1), $c, key(), $a, key())
$a = $b >>+<< $c # VTABLE_add_hyper($b, $c, $a)
The default hyper functions will do whatever 
piecewise activity is defined, though I expect 
that'll be overridden in a few unusual cases.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Korean character set info

[Jarkko Hietaniemi]

>>>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 the variable
variables.

Re: embed.h doesn't work in C++

[Brent 'Dax' Royal-Gordon]

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 it.
make realclean && perl ./Configure.pl && make && make fulltest
passed without errors or additional warnings. (i686; SuSE Linux 9.0)
Wow.  Excellent.

You're welcome to try it again, though...while you're at it, you might
as well make all internal Parrot functions take an Interp * instead of a
struct Parrot_Interp *.  That ought to save us a couple kilobytes.
What files are "internal"? I can change this, too.
I believe that any function that takes 'struct Parrot_Interp *' 
currently should really be taking 'Interp *'.  Any function that takes 
the 'Parrot_Interp' typedef should be left alone.

--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.

A question about binary does

[Abhijit A. Mahabal]

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 my question is vague.

--Abhijit

role Set{
  method add ($elt) { $self.{$elt} = 1  }
  method remove ($elt) {...}
  method intersection($other where Set) {
# can I write that as: method intersection (Set $other) ?
return $self.keys.grep { exists $other{$^a}  }
  }
}

class Set_class does Set {}

class Collector{
  has %.coins does Set;# brand new singleton class
  has Set_class %.stamps;  # use existing class
}

my Collector $collector .= new;
$collector.coins.add(new Coin());   #okay
$collector.stamps.add(new Stamp()); #okay

# much later during compilation

role Set is extended{ # is this: die if any collision in any class
  method difference ($other where Set) {...}
}

$collector.stamps.difference(...); # okay
$collector.coins.difference(...);  # Is that legal?

# In other words, is the singleton class like a closure or like a
first-class class?

Abhijit A. Mahabal  http://www.cs.indiana.edu/~amahabal/

Re: Apo 12

[Aaron Sherman]

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 that the prototyping behavior they're looking for is actually
> supplied by wildcard delegation in Perl 6...

Well, I think to be fair, it's going to take a long while for most of
the world to digest A12 and figure out how it does or does not deliver
their pet features / paradigms.

Prototyping in P6 would seem to me to be easy, but not quite the
default. You'd want an intermediary that did the MetaClass negotiation
as you "derived" from an existing object. Or will that be in the core?
Can you say:

my Object $obj1;
MyClassExtenderClass.add_a_print_method($obj1.metaclass);
my ::{$obj1.class} $obj2;

?

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

Re: A12: Required Named Parameters Strike Back!

[Aaron Sherman]

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 foo(+$a is required, +$b is required) { ... }

Your example is a non-multi sub, which AFAIK means that you can do this
at compile time. But for multis and methods, I think Larry and Dan's
comments still hold.

The likelyhood that P6.0.0 will make this distinction is another thing.
I'd rather have a language that works than one that is complete. Plenty
of time to complete it later, but those who are thinking of taking on
large-scale development with it (e.g. converting over large CPAN modules
or implementing new Perl6ish libraries) just want something that runs :)

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

Re: A12: Required Named Parameters Strike Back!

[John Siracusa]

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 the way I described earlier:
>> 
>> sub foo(+$a is required, +$b is required) { ... }
> 
> Your example is a non-multi sub, which AFAIK means that you can do this
> at compile time. But for multis and methods, I think Larry and Dan's
> comments still hold.
> 
> The likelyhood that P6.0.0 will make this distinction is another thing.
> I'd rather have a language that works than one that is complete. Plenty
> of time to complete it later, but those who are thinking of taking on
> large-scale development with it (e.g. converting over large CPAN modules
> or implementing new Perl6ish libraries) just want something that runs :)

Yes, it appears that runtime checks for the existence of required params
will continue to be a necessary part of Perl programming.  I suppose a
saving grace is that Perl 6 will support "real" assertions that disappear
entirely from the program flow when a switch is flipped.

-John

Re: A12: Required Named Parameters Strike Back!

[John Siracusa]

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 himself

* runtime checks that the compiler generates automatically
  (presumably using a trait like "is required")

I'm sure someone will write the latter if it's not part of the core
language...hint hint :)

-John

Re: ICU Win32 Issues

[Jeff Clites]

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 tried native Win32, where I got another ICU issue (do we  
*really* need
unicode? :-). It seems as if ICU needs not only a (n)make and a  
compiler, but
depends on msdev.exe, which seems to be the executable for the M$ Devel
Studio which can also be used on the command line. It alway complains  
about
the missing file, and as I didn't have an MS Dev studio, I stopped for  
today.

So, after a hard days work, no real success :-(
Two thinks to look at, if you are still in the mood to experiment. :)

1) Take a look at:

	

and see if you can get ICU building by itself--that is, outside of its  
integration into parrot's Makefile (but from the source which comes  
with parrot). (That URL goes to the readme for the newest version of  
ICU, but I'm not sure if it's changed since the version we have.)

2) All of the setup for parrot is controlled by config/gen/icu.pl, so  
if you can build it "alone", then this file is what needs to be  
modified to set things up properly. I think that so far it is just  
handling one Windows build scenario (but I'm not sure which one)--but  
it is working for some setups, at least.

JEff