Desk check this code please

[John M. Dlugosz]

Is this code syntactically and conceptually correct?

 method postfix:<++> (-->::?CLASS)
 is export
  {
  my ::?CLASS $temp = self;
  self =. successor;
  return $temp;
  }
 
 method prefix:<++> (-->::?CLASS)
 is export
 is rw
  {
  self =.successor;
  return self;
  }

In particular, are pre/postfix functions defined as methods inside a class (or 
role, as the case may be)?  I'm guessing that 

 ++$x

will first see that prefix:<++> is a member of that class, and do method 
dispatch on it.

So, does making it "export" mean anything?

Operator or not, if methods are "export", do they need to be multi, or are they 
not multi if dispatched via method but become multi if dispatched as a sub?

--John

Generic Parameter Proposal

[John M. Dlugosz]

First, consider the stated examples for Generic type parameters, from the 
passage which defines the terminology in S02:

sub max (Num ::X @array) {
push @array, X.new();
}

sub compare (Any ::T $x, T $y) {
return $x eqv $y;
}

There are only two paragraphs and these two examples, so many questions are 
"begged".  I propose to answer many of these with this treatment, and hold it 
up for peer review and acceptance.  I also want to propose a new feature change.

Question 1 - can the Any be left off?  That is, ::X as an undeclared type name 
used as the only type, syntactically correct?

Question 2 - is $x constrained to ::T or does that just note what it was 
originally? (in cases where $x is not read only.  In this example that is moot.)

The syntax to define the value type for variables provides for multiple types 
simply listed one after the other, which are taken to mean "and".

Dog Fish $x;

This means that $x must have both Dog and Fish interfaces.  A better example 
might be

Document Storable Positional $doc;

where the code makes use of several different fairly abstract interfaces and 
doesn't care what kind of concrete class it gets.

So, we might want to capture that concrete type to, and write

Document Storable Positional ::DocType $doc;

Now the fact that this is a generic type notwithstanding, it is just another 
type in the list.  It just happens to be the same type that is the actual type 
$doc was initialized with.  But, it implies that yes, $doc is constrained to 
that type from then on.  The generic type just customizes the list at run-time, 
but it is still a list of juxaposed types, so they are ANDed together.

Mammel Elephant $dumbo;

might be redundant if Elephant .does Mammel.  But that's beside the point.  
Likewise that DocType (after binding) subsumes all the others in the list.

Now we have a list of juxaposed type names, that are ANDed together.  The 
generic type is the one that wasn't defined (as a type) before.  It needs the 
:: so it doesn't flag as an undefined symbol, but the others could have the 
sigil if you wanted to be explicit:

::Document ::Storable ::Positional ::DocType $doc;

Whether or not the sigil was present is lost on the semantic meaning, once it 
gets past the parser.  The only reason we had it on ::DocType or ::T was 
because it was not defined.

The only real difference between the generic type and the others is that one 
was not previously known.  Really, it is just a list of type names.

So,

::T $x;

Should be just fine.  The parser is not depending on another type already seen 
before that.  It is a list of one type, and after it figures that out, it later 
notices that it is not defined yet.

That answers the two questions, based only on other things in the Synopses.

Now for a proposal, and the observation of an issue.

The only thing that makes a generic type parameter generic is that it was 
previous undefined as a type.  So, what if you have code that's working just 
fine, and then some other change puts a symbol T into the lexical scope, 
perhaps as a global import?  Boom!  The code changes meaning drastically.

Contrast that to the normal meaning of declaring a variable, in which case it 
hides anything with the same name in the outer scopes.  Introducing a global 
one does not change the code that uses lexical variables.  Except for generics. 
 That is inconsistant and wrong for the same reason that it would be wrong for 
all other kinds of symbols.

To address this, I propose using a positive way to declare generic parameters 
rather than having them implicit based on not previously existing.  I propose 
the triple colon, :::, for this purpose:

:::T $x;

I beleive this does not conflict with anything, and it is in the same spirit as 
@@ and ;;.

--John

Re: Chained Comparisons ?

[John M. Dlugosz]

Larry Wall larry-at-wall.org |Perl 6| wrote:

Well, that's more or less how Icon does it, but we're not going to expose
anything like that to the user.  If we assume that comparisons take two
immutable objects, we can leave it to the compiler to compute the actual
value once, and then feed it to both sides of the implicit AND.  The
user just writes an ordinary binary comparison that returns a boolean.

For several years now I've been treating any use of "but" as a code
smell, and changing the design so it isn't necessary.  It's been a
rather useful construct that way, like "eval" and "BEGIN". :)

  

Thanks for the clarification, Larry.
 * hidden from the user (no funny return values, no funny way to write 
the function)

 * argument only evaluated once
Any strong feeling about order-of-evaluation issues?

I assume this extends to any user-written infix:{'<'} since we're not 
supposed to reuse existing operators for different purposes, but only to 
extend the domain of the same meaning.


So how about making a new operator or set of operators that will have 
the same behavior?  I don't like compiler magic that is not available 
for reuse .


Is "chained" associativity specific to this (functions return Bool and 
are ANDed pairwise), or can it be used for other things like ganging 
$a+$b+$c+$d to a single +(*$L,*$R,Vector [EMAIL PROTECTED]) function that doesn't 
keep re-allocating and copying memory but does it all in one shot?


--John

Re: Chained Comparisons ?

[Bob Rogers]

   From: "Brandon S. Allbery KF8NH" <[EMAIL PROTECTED]>
   Date: Wed, 16 Apr 2008 09:39:52 -0400

   . . .

   Yes, they use multiple-typed values such that (3 < 5) returns (5 but  
   True), which used in a numeric context is a 5 that can be chained  
   with further infix:{'<'}s but in a boolean context is True.

Pardon a lurker, but I'm not sure I understand the point of this.  In:

if $x < $y < $z { ... }

I would expect a sensible compiler short-circuit the "$x < $y" part, and
indeed the "Chained comparisons" section of S03 (version 135) says

A chain of comparisons short-circuits if the first comparison
fails . . .

But the definition of chaining associativity under "Operator precedence"
says this is equivalent to:

if ($x < $y) and ($y < $z) { ... }

(modulo multiple evaluation), but IIUC "and" is not short-circuiting.
Which is intended?  I am hoping the "Operator precedence" definition
should be "andthen"; I would find non-short-circuiting behavior rather
surprising.

   Assuming that the intent is for short-circuiting, the compiler
*can't* in general produce code that invokes subsequent chained ops, as
that would require evaluating subsequent arguments.  So when would these
"Num but True" values ever be needed?
   
   And wouldn't it also be helpful to implement chaining in such a way
that a specialized chained op implementation couldn't mess it up by
returning plain True?

   My apologies if this is spelled out somewhere; I couldn't find
anything about this application of multiple-typing in S03.

-- Bob Rogers
   http://rgrjr.dyndns.org/

Re: Chained Comparisons ?

[Joe Gottman]

Brandon S. Allbery KF8NH wrote:


On Apr 16, 2008, at 3:49 , John M. Dlugosz wrote:
Or, are the operators written in a tricky way, to return an object 
that encapsulates the original right argument and the proper boolean 
result, and has forms to take this object as well?  IOW, no built-in 
support.


Yes, they use multiple-typed values such that (3 < 5) returns (5 but 
True), which used in a numeric context is a 5 that can be chained with 
further infix:{'<'}s but in a boolean context is True.



So does (5 < 3) return (3 but False)  or just False ?

Joe Gottman

Re: Chained Comparisons ?

[Larry Wall]

On Wed, Apr 16, 2008 at 09:39:52AM -0400, Brandon S. Allbery KF8NH wrote:
>
> On Apr 16, 2008, at 3:49 , John M. Dlugosz wrote:
>> Or, are the operators written in a tricky way, to return an object that 
>> encapsulates the original right argument and the proper boolean result, 
>> and has forms to take this object as well?  IOW, no built-in support.
>
> Yes, they use multiple-typed values such that (3 < 5) returns (5 but True), 
> which used in a numeric context is a 5 that can be chained with further 
> infix:{'<'}s but in a boolean context is True.

Well, that's more or less how Icon does it, but we're not going to expose
anything like that to the user.  If we assume that comparisons take two
immutable objects, we can leave it to the compiler to compute the actual
value once, and then feed it to both sides of the implicit AND.  The
user just writes an ordinary binary comparison that returns a boolean.

For several years now I've been treating any use of "but" as a code
smell, and changing the design so it isn't necessary.  It's been a
rather useful construct that way, like "eval" and "BEGIN". :)

Larry

Re: Chained Comparisons ?

[John M. Dlugosz]

Patrick R. Michaud pmichaud-at-pobox.com |Perl 6| wrote:

It applies to any operator that has 'chain' associativity --
see S06, "Subroutine traits".

  
If I want to make my own chained operator, perhaps the 
curvy ≼, ≽, etc. or make my operator ≧ 
a synonym for >=, how would I tell the compiler that they 
belong to the same set of chained operators?



sub infix:«≽» ($a, $b) is equiv(&infix:«>=») { ... }

Or, if you want to create your own chained precedence level
separate from the existing relational ops, 


sub infix:«≽» ($a, $b) is assoc is looser(...)  { ... }

Pm

  


Your answer is the opposite of Brandon's. 

Re: Returning Arrays?

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

HaloO,

John M. Dlugosz wrote:

I seem to recall seeing sigils in a signature without names,
but now I can't remember where.


E.g. in S06 und section "The want function".

Regards, TSa.
Somewhere else, I think it discussed unnamed parameters to functions, 
not just signature matching.

Re: Returning Arrays?

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

HaloO,

John M. Dlugosz wrote:

How do you declare a function that returns an array?  Something like

   sub foo (blah) is Array of X { ... }



I meant "of", not "is".



In general the of keyword instanciates parametric types just like
the direct indexing of typenames with []. The only unspecced thing
is the variance of ::Foo[::Bar] with respect to ::Bar.


Variance?





So that brings me to the second problem.  For parameters, it's no 
problem because people just use the @ sigil and don't think about 
containers.  So how do I do that with the return value?  I don't name 
the return value, so there is no place to put the sigil.


  sub foo (blah) is X @*


Should be 'sub foo( --> X *@)' or 'our X *@ sub foo()'. In case that
this doesn't parse 'our :(X *@) sub foo()' should.


No, *@ is the slurpy array parameter.  I was thinking of

  (*,*,$x) = @array;  # skips first two elements

to suppose that @* might mean "no name" if the syntax would not allow 
for bare @ there without an identifier.

[perl #49712] [CAGE] t/pmc/nci.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

[perl #49710] [CAGE] t/pmc/objects.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

[perl #49708] [CAGE] t/pmc/namespace.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

[perl #49706] [CAGE] t/pmc/mmd.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

[perl #49702] [CAGE] t/pmc/float.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

[perl #49700] [CAGE] t/pmc/object-meths.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

[perl #49698] [CAGE] t/pmc/string.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

[perl #49696] [CAGE] t/pmc/resizablepmcarray.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

[perl #49690] [CAGE] t/pmc/threads.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

[perl #49688] [CAGE] t/pmc/sub.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

[perl #49680] [CAGE] t/pmc/bigint.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

[perl #49678] [CAGE] t/pmc/complex.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

[perl #49676] [CAGE] t/pmc/hash.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

[perl #49674] [CAGE] t/pmc/iterator.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

[perl #49672] [CAGE] t/pmc/resizablestringarray.t: Determine whether test can be divided into smaller files

[James Keenan via RT]

Examination of this file suggests that its length is simply a function
of the fact that PIR and PASM are mostly written with very short lines.
  There is no compelling reason to try to subdivide the file.  Closing
ticket.

Re: The Big Three Rakudo (and Parrot OO) Bottlenecks

[chromatic]

On Wednesday 16 April 2008 15:39:41 Jonathan Worthington wrote:

> chromatic wrote:

> > It helps the PIR Ackerman benchmark by 4.67%.  parrot_pass_args gets more
> > expensive, but next_arg_sig and everything else except for
> > Parrot_init_arg_indexes_and_sig_pmc gets called much, much less.  I
> > played with the patch a little bit, but didn't get it much faster.

> So is the optimization worth applying, do you think? Seems like a
> relatively small gain once we take it away from a benchmark that we'd
> expect it to directly help...

> > It may be possible to avoid the Parrot_init_arg_indexes_and_sig_pmc
> > calls, but I couldn't immediately see how.
> I pondered this too, but didn't really look into it properly.

If we can do this, the optimization might be worth it.

-- c

Re: The Big Three Rakudo (and Parrot OO) Bottlenecks

[Jonathan Worthington]

chromatic wrote:
It helps the PIR Ackerman benchmark by 4.67%.  parrot_pass_args gets more 
expensive, but next_arg_sig and everything else except for 
Parrot_init_arg_indexes_and_sig_pmc gets called much, much less.  I played 
with the patch a little bit, but didn't get it much faster.
  
So is the optimization worth applying, do you think? Seems like a 
relatively small gain once we take it away from a benchmark that we'd 
expect it to directly help...



It may be possible to avoid the Parrot_init_arg_indexes_and_sig_pmc calls, but 
I couldn't immediately see how.
  

I pondered this too, but didn't really look into it properly.

Jonathan

Re: [svn:parrot] r26828 - in trunk/languages/perl6/src: builtins parser

[Jonathan Worthington]

Patrick R. Michaud wrote:

There's currently a problem in that

class Foo { }

doesn't create 'Foo' as a subclass of Object.
  

Hmmmthat's odd, since I can do:

class Foo { }
if Foo ~~ Object { say "yes" }
yes
if Foo.new() ~~ Object { say "yes" }
yes

I know that it doesn't explicitly do that in the class declaration 
method, but in make_proto it will:


   $P0 = get_class 'Perl6Object'
   class.'add_parent'($P0)

If it doesn't have that as a parent already. So from what I can see, it 
is Foo will end up inheriting from Object. What have you found that 
doesn't work as it should?



Also, something that might help with the discussion of multimethod
dispatch in rock-paper-scissors is to note that the mmd types do
not have to be directly related in the type hierarchy.  In other
words, we _should_ be able to do the example without needing the
base Thing class.  (Whether this currently works or not in Parrot 
is perhaps another issue. :-)
  

Appears to work.

class Foo { }; class Bar { }
multi sub test(Foo $x) { say "foo" }
multi sub test(Bar $x) { say "bar" }
test(Foo.new())
foo
test(Bar.new())
bar

So yes, you could re-write it and just write "Object", or "Any" or 
probably just no type at all (which should default to Any).


Jonathan

Re: [perl #41095] [BUG] Segfault in test.exe during Configuration

[Nikolay Ananiev]

Confirmed. This bug is still there as of r27009

"Nikolay Ananiev" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> I'll be able to test Parrot in the next 48 hours
> on my pentium mmx and tell you what the result is.
>
> - Original Message - 
> From: "James Keenan via RT" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, April 14, 2008 5:36 AM
> Subject: [perl #41095] [BUG] Segfault in test.exe during Configuration
>
> Jonathan:  Do you know if we've overcome this problem?
>
> Thank you very much.
>
> kid51
> 

Re: [perl #52976] [BUG] perl6 stand-alone binary broken

[chromatic]

On Wednesday 16 April 2008 10:49:15 Christoph Otto (Volt) wrote:

> The perl6 stand-alone binary chokes on chromatic's mmd example
> (http://www.oreillynet.com/onlamp/blog/2008/04/multiple_dispatch_now_please
>.html) under linux/x86.  The bug was exposed in r26173, but the root cause
> is probably deeper.  It looks easy to reproduce, but I can certainly
> provide more information if as needed.

The root cause is a double-free on something in a context somewhere.  If you 
keep the patch in r26173 around and bisect the thousand or so commits before 
there, you (or I) can probably find it.

-- c

[perl #52976] [BUG] perl6 stand-alone binary broken

[Christoph Otto (Volt)]

# New Ticket Created by  "Christoph Otto (Volt)" 
# Please include the string:  [perl #52976]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=52976 >


The perl6 stand-alone binary chokes on chromatic's mmd example 
(http://www.oreillynet.com/onlamp/blog/2008/04/multiple_dispatch_now_please.html)
 under linux/x86.  The bug was exposed in r26173, but the root cause is 
probably deeper.  It looks easy to reproduce, but I can certainly provide more 
information if as needed.

Christoph


[EMAIL PROTECTED]:/usr/src/parrot/parrot-svn-cotto 1 $ ./perl6 
languages/perl6/mmd.p6
1
0
*** glibc detected *** ./perl6: double free or corruption (!prev): 0x081c8568 
***
=== Backtrace: =
/lib/i686/cmov/libc.so.6[0xb78308f5]
/lib/i686/cmov/libc.so.6(cfree+0x90)[0xb7834360]
/usr/src/parrot/parrot-svn-cotto/blib/lib/libparrot.so.0.6.1(mem_sys_free+0x23)[0xb7cc1393]
/usr/src/parrot/parrot-svn-cotto/blib/lib/libparrot.so.0.6.1[0xb7cc14bf]
/usr/src/parrot/parrot-svn-cotto/blib/lib/libparrot.so.0.6.1[0xb7ccb45c]
/usr/src/parrot/parrot-svn-cotto/blib/lib/libparrot.so.0.6.1(Parrot_exit+0x70)[0xb7cba070]
./perl6[0x8048a56]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb77db450]
./perl6[0x8048891]
=== Memory map: 
08048000-0817e000 r-xp  08:0a 938951 
/usr/src/parrot/parrot-svn-cotto/perl6
0817e000-0817f000 rw-p 00135000 08:0a 938951 
/usr/src/parrot/parrot-svn-cotto/perl6
0817f000-08637000 rw-p 0817f000 00:00 0  [heap]
b632e000-b632f000 r--s  08:0a 1102853
/usr/src/parrot/parrot-svn-cotto/runtime/parrot/library/Parrot/Exception.pbc
b632f000-b6335000 r--s  08:0a 1102883
/usr/src/parrot/parrot-svn-cotto/runtime/parrot/library/PCT/HLLCompiler.pbc
b6335000-b6337000 r--s  08:0a 1102854
/usr/src/parrot/parrot-svn-cotto/runtime/parrot/library/Parrot/Capture_PIR.pbc
b63b5000-b63cc000 r--s  08:0a 1102881
/usr/src/parrot/parrot-svn-cotto/runtime/parrot/library/PCT/PAST.pbc
b63cc000-b63ce000 r--s  08:0a 1494400
/usr/src/parrot/parrot-svn-cotto/runtime/parrot/library/PGE/Util.pbc
b640-b6401000 r--s  08:0a 1102856
/usr/src/parrot/parrot-svn-cotto/runtime/parrot/library/Protoobject.pbc
b64c-b64ea000 r--s  08:0a 1102899
/usr/src/parrot/parrot-svn-cotto/runtime/parrot/library/PGE.pbc
b64ea000-b64ec000 r--s  08:0a 1102882
/usr/src/parrot/parrot-svn-cotto/runtime/parrot/library/PCT/Grammar.pbc
b64ec000-b64ed000 r--s  08:0a 1102880
/usr/src/parrot/parrot-svn-cotto/runtime/parrot/library/PCT.pbc
b690-b6921000 rw-p b690 00:00 0
b6921000-b6a0 ---p b6921000 00:00 0
b6a8a000-b6a8c000 rw-p b6a8a000 00:00 0
b6a8c000-b6a98000 r-xp  08:01 44187  /lib/libgcc_s.so.1
b6a98000-b6a99000 rw-p b000 08:01 44187  /lib/libgcc_s.so.1
b6a99000-b6b7b000 r-xp  08:0a 9158712/usr/lib/libstdc++.so.6.0.10
b6b7b000-b6b7e000 r--p 000e2000 08:0a 9158712/usr/lib/libstdc++.so.6.0.10
b6b7e000-b6b8 rw-p 000e5000 08:0a 9158712/usr/lib/libstdc++.so.6.0.10
b6b8-b6b86000 rw-p b6b8 00:00 0
b6b86000-b6b9a000 r-xp  08:0a 9158706/usr/lib/libz.so.1.2.3.3
b6b9a000-b6b9b000 rw-p 00013000 08:0a 9158706/usr/lib/libz.so.1.2.3.3
b6b9b000-b6b9c000 rw-p b6b9b000 00:00 0
b6b9c000-b6bca000 r-xp  08:01 44249  /lib/libncurses.so.5.6
b6bca000-b6bcd000 rw-p 0002d000 08:01 44249  /lib/libncurses.so.5.6
b6bcd000-b76a3000 r--p  08:0a 9160630/usr/lib/libicudata.so.38.1
b76a3000-b76a4000 rw-p 00ad5000 08:0a 9160630/usr/lib/libicudata.so.38.1
b76a4000-b77ba000 r-xp  08:0a 9160642/usr/lib/libicuuc.so.38.1
b77ba000-b77c4000 rw-p 00115000 08:0a 9160642/usr/lib/libicuuc.so.38.1
b77c4000-b77c5000 rw-p b77c4000 00:00 0
b77c5000-b790d000 r-xp  08:01 60447  /lib/i686/cmov/libc-2.7.so
b790d000-b790e000 r--p 00148000 08:01 60447  /lib/i686/cmov/libc-2.7.so
b790e000-b791 rw-p 00149000 08:01 60447  /lib/i686/cmov/libc-2.7.so
b791-b7913000 rw-p b791 00:00 0
b7913000-b7a44000 r-xp  08:0a 9191478
/usr/lib/i686/cmov/libcrypto.so.0.9.8
b7a44000-b7a5a000 rw-p 00131000 08:0a 9191478
/usr/lib/i686/cmov/libcrypto.so.0.9.8
b7a5a000-b7a5e000 rw-p b7a5a000 00:00 0
b7a5e000-b7a8a000 r-xp  08:01 44262  /lib/libreadline.so.5.2
b7a8a000-b7a8e000 rw-p 0002c000 08:01 44262  /lib/libreadline.so.5.2
b7a8e000-b7a8f000 rw-p b7a8e000 00:00 0
b7a8f000-b7ad1000 r-xp  08:0a 9159686/usr/lib/libgmp.so.3.4.2
b7ad1000-b7ad2000 rw-p 00042000 08:0a 9159686/usr/lib/libgmp.so.3.4.2
b7ad2000-b7ad9000 r-xp  08:01 60463  /lib/i686/cmov/librt-2.7.so
b7ad9000-b7adb000 rw-p 6000 08:01 60463  /lib/i686/cmov/librt-2.7.so
b7adb000-b7ae4000 r-xp  08:01 60449  /lib/i686/cmov/libcrypt-2.7.so
b7ae4000-b7ae6000 rw-p 8000 08:01 60449  /lib/i686/cmov/libcrypt-2.7.so
b7ae6000-b7b0d000 rw-p b7ae60

Re: working out kinks in the parrot release process

[jerry gay]

On Wed, Apr 16, 2008 at 1:49 PM, Mark Glines <[EMAIL PROTECTED]> wrote:
> On Wed, 16 Apr 2008 13:45:22 -0700
>  "jerry gay" <[EMAIL PROTECTED]> wrote:
>
>  > also, i'd like to automate more of the release process. currently, we
>  > have a period of time where the link on the website for the most
>  > recent parrot will point to the previous release of parrot, until the
>  > new distro propagates to the cpan mirrors. in order to overcome this
>  > problem, and to automate one more release step, i propose the
>  > following:
>  >
>  > write a piece of code that watches http://svn.perl.org/parrot/tags/
>  > for a new tag that matches /RELEASE_.*/, and when that occurs, run
>  > 'make release VERSION=`cat version`', and updates a link on the
>  > website to point to that tarball. we can then use that tarball to do a
>  > final test, and upload it to cpan.
>  >
>  > comments welcome.
>
>  Does this mean dalek needs a CPAN account now?
>
no, no. the cpan upload would still be manual, but we'd use the url
from parrotcode.org for the tarball, rather than uploading from our
local machine.
~jerry

Re: [svn:parrot] r26828 - in trunk/languages/perl6/src: builtins parser

[Bob Rogers]

   From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
   Date: Wed, 16 Apr 2008 14:47:13 -0500

   Also, something that might help with the discussion of multimethod
   dispatch in rock-paper-scissors is to note that the mmd types do
   not have to be directly related in the type hierarchy.  In other
   words, we _should_ be able to do the example without needing the
   base Thing class.  (Whether this currently works or not in Parrot 
   is perhaps another issue. :-)

   Pm

It works; Kea-CL uses this.

-- Bob

Re: working out kinks in the parrot release process

[Mark Glines]

On Wed, 16 Apr 2008 13:45:22 -0700
"jerry gay" <[EMAIL PROTECTED]> wrote:

> also, i'd like to automate more of the release process. currently, we
> have a period of time where the link on the website for the most
> recent parrot will point to the previous release of parrot, until the
> new distro propagates to the cpan mirrors. in order to overcome this
> problem, and to automate one more release step, i propose the
> following:
> 
> write a piece of code that watches http://svn.perl.org/parrot/tags/
> for a new tag that matches /RELEASE_.*/, and when that occurs, run
> 'make release VERSION=`cat version`', and updates a link on the
> website to point to that tarball. we can then use that tarball to do a
> final test, and upload it to cpan.
> 
> comments welcome.

Does this mean dalek needs a CPAN account now?

Mark

working out kinks in the parrot release process

[jerry gay]

one consistent trouble spot in the parrot release process is the CPAN
upload process. often times, we have trouble with perl modules that
have been added, deleted, or renamed causing the release to be marked
as 'unauthorized'. dealing with unauthorized releases involves
intervention from a pause admin.

the reason we run into trouble at all is because we're indexing
modules in the parrot repo. with the exception of a few (Parrot::Embed
comes to mind), i don't see a need to index any of the modules.
they're all parrot-specific, and we don't use CPAN's bug tracker or
rating systems to maintain those modules. therefore, i'd like to make
parrot 0.6.1 the last release that's ever listed as unauthorized due
to module ownership problems.

let's update the metadata to refrain from indexing modules under the
Parrot:: namespace, except where it makes sense.


also, i'd like to automate more of the release process. currently, we
have a period of time where the link on the website for the most
recent parrot will point to the previous release of parrot, until the
new distro propagates to the cpan mirrors. in order to overcome this
problem, and to automate one more release step, i propose the
following:

write a piece of code that watches http://svn.perl.org/parrot/tags/
for a new tag that matches /RELEASE_.*/, and when that occurs, run
'make release VERSION=`cat version`', and updates a link on the
website to point to that tarball. we can then use that tarball to do a
final test, and upload it to cpan.

comments welcome.
~jerry

Re: [svn:parrot] r26828 - in trunk/languages/perl6/src: builtins parser

[Patrick R. Michaud]

On Wed, Apr 16, 2008 at 09:38:41PM +0200, Jonathan Worthington wrote:
> chromatic wrote:
> >You're right.  I started from the wrong point in my bisect.
> >  
> No worries.
> 
> >I can't reproduce the problem with any revision before or after the 0.6.1 
> >release.
> >  
> But the 0.6.1 release had a problem? If I'm understanding correctly, the 
> current revision doesn't show the problem?

There's currently a problem in that

class Foo { }

doesn't create 'Foo' as a subclass of Object.

Also, something that might help with the discussion of multimethod
dispatch in rock-paper-scissors is to note that the mmd types do
not have to be directly related in the type hierarchy.  In other
words, we _should_ be able to do the example without needing the
base Thing class.  (Whether this currently works or not in Parrot 
is perhaps another issue. :-)

Pm

Re: [svn:parrot] r26828 - in trunk/languages/perl6/src: builtins parser

[Jonathan Worthington]

chromatic wrote:

You're right.  I started from the wrong point in my bisect.
  

No worries.

I can't reproduce the problem with any revision before or after the 0.6.1 
release.
  
But the 0.6.1 release had a problem? If I'm understanding correctly, the 
current revision doesn't show the problem?


Thanks,

Jonathan

Re: [svn:parrot] r26828 - in trunk/languages/perl6/src: builtins parser

[chromatic]

On Wednesday 16 April 2008 11:22:08 Jonathan Worthington wrote:

> > This is the commit which broke the Rock, Paper, Scissors MMD example.

> *confused look* But I didn't implement the stuff needed to run the rock,
> paper scissors MMD example until 4 days after the commit you mention?
> http://parrotvm.org/svn/parrot/revision/?rev=26885

You're right.  I started from the wrong point in my bisect.

I can't reproduce the problem with any revision before or after the 0.6.1 
release.

-- c

Re: Parrot 0.6.1 "Bird of Paradise" Released

[François Perrad]

2008/4/15 jerry gay <[EMAIL PROTECTED]>:

> Aloha!
>
> On behalf of the Parrot team, I'm proud to announce Parrot 0.6.1
> "Bird of Paradise." Parrot (http://parrotcode.org/) is a virtual machine
> aimed
> at running all dynamic languages.
>

The Windows setup is available on http://parrotwin32.sourceforge.net/

François.


>
> Parrot 0.6.1 can be obtained via CPAN (soon), or follow the
> download instructions at http://parrotcode.org/source.html.
> For those who would like to develop on Parrot, or help develop
> Parrot itself, we recommend using Subversion or SVK on the
> source code repository to get the latest and best Parrot code.
>
> Parrot 0.6.1 News:
> - Specification
>  + drafted pdd29_compiler_tools.pod
>  + updated pdd28_character_sets.pod draft
>  + updated pdd19_pir.pod draft
> - Languages
>  + c99: added independent C pre-processor
>  + HQ9+: reimplemented with PCT
>  + Lua:
>. reimplementation with PCT, using PAST and POST
>. behavior aligned wih 5.1.3
>  + Rakudo:
>. implemented basic I/O, including '$*IN', '$*OUT', '$*ERR', 'prefix:='
>. implemented simple typing and runtime type checking
>. added basic multi-method dispatch
>. expanded named argument handling, including Pair and colonpairs
>. added 'Whatever' and 'Capture' classes
>. implemented 'handles' trait verb
>. added 'loop' statement
>. implemented 'given', 'when', 'for', 'while', 'until' statement
> modifiers
>. implemented Hash methods '.keys' and '.values'
>. fixed bug to get '.WHAT' working correctly
>. initial implementation of 'eval'
> - Compilers
>  + NQP:
>. created a bootstrapped build, see 'make boot'
>. added 'infix:<', 'infix:<=', 'infix:>', 'infix:>=' relational
> operators
>. added 'postfix:++', 'postfix:--' operators
>  + PCT:
>. added methods specifying default behaviors in PAST, reducing repeated
> code
>. improved symbol table lookup
>  + PGE:
>. removed deprecated code including: P6Regex, P6Grammar, PAST-pm
> - Miscellaneous
>  + notable speedups during compilation and execution of parrot and HLLs
>  + pdb (the parrot debugger) can now catch parrot exceptions
>  + better detection of glibc and gettext during configuration
>  + various bugfixes, code cleanups, deprecations, and coding standard
> fixes
>
>
> Mahalo to all our contributors for making this possible, and our
> sponsors for supporting this project.
>
> Enjoy!
> ~jerry
>
>

Re: [svn:parrot] r26828 - in trunk/languages/perl6/src: builtins parser

[Jonathan Worthington]

chromatic wrote:

On Sunday 06 April 2008 16:05:45 [EMAIL PROTECTED] wrote:

  

Modified:
   trunk/languages/perl6/src/builtins/guts.pir
   trunk/languages/perl6/src/parser/actions.pm
   trunk/languages/perl6/src/parser/grammar.pg

Log:
[rakudo] Add type-checking of parameters to subroutines and methods.



This is the commit which broke the Rock, Paper, Scissors MMD example.
  
*confused look* But I didn't implement the stuff needed to run the rock, 
paper scissors MMD example until 4 days after the commit you mention?

http://parrotvm.org/svn/parrot/revision/?rev=26885

Jonathan

Re: [svn:parrot] r26828 - in trunk/languages/perl6/src: builtins parser

[chromatic]

On Sunday 06 April 2008 16:05:45 [EMAIL PROTECTED] wrote:

> Modified:
>trunk/languages/perl6/src/builtins/guts.pir
>trunk/languages/perl6/src/parser/actions.pm
>trunk/languages/perl6/src/parser/grammar.pg
>
> Log:
> [rakudo] Add type-checking of parameters to subroutines and methods.

This is the commit which broke the Rock, Paper, Scissors MMD example.

-- c

Re: static types, checking, conversions

[Larry Wall]

On Wed, Apr 16, 2008 at 04:29:23PM +, [EMAIL PROTECTED] wrote:
: You should look at Common Lisp.  it's definition of "optional typing" is that 
if you take a correct program and remove all the type declarations, then it 
still works correctly, although it may be significantly less efficient.  Larry 
and i have discussed this and that was his goai in Perl.  Now Perl doesn't 
quite meet that because of inferred method dispatch on .new().  you need to 
change
: 
: my Dog $spot = .new();
: 
: to
: 
: my $Spot = Dog.new();
: 
: when you remove the declaration.

You'd also break multiple dispatch rather badly...

Larry

Re: static types, checking, conversions

[mark . a . biggar]

You should look at Common Lisp.  it's definition of "optional typing" is that 
if you take a correct program and remove all the type declarations, then it 
still works correctly, although it may be significantly less efficient.  Larry 
and i have discussed this and that was his goai in Perl.  Now Perl doesn't 
quite meet that because of inferred method dispatch on .new().  you need to 
change

my Dog $spot = .new();

to

my $Spot = Dog.new();

when you remove the declaration.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: TSa <[EMAIL PROTECTED]>
> HaloO,
> 
> Mark J. Reed wrote:
> > It would behoove @Larry to examine the optional type constraints
> > system proposed for Javascript:TNG (see link from firefox.com
> > developers page).  I therefore assume that they have done so, but
> > others would benefit by doing likewise. :)
> 
> Do I get that right: you imply that I didn't do my homework?
> Note that I don't feel offended by that.
> 
> I found two dissertations and a couple of papers about typing
> JavaScript. The quintessential is that optional typing is
> defined as having *no* impact on the dynamic behavior of the
> program. In that respect type annotations are like comments.
> I doubt that this is the case with Perl 6, or is it?
> 
> 
> Regards, TSa.
> -- 
> 
> The Angel of Geometry and the Devil of Algebra fight for the soul
> of any mathematical being.   -- Attributed to Hermann Weyl

Re: cross operator and empty list

[TSa]

HaloO,

Larry Wall wrote:

Then [X]() also is ()? How about (0,1) X ([]) === (0,1)?


No, that's (0,[]), (1,[1]).  [] *doesn't* flatten in list context.


I guess you meant (0,[]), (1,[]). And you didn't answer what
[X]() returns. Following your arguments this would be undef.



I am genuinely curious as to why anyone who is not a mathematician
would want this?


Well, as an alternate default list. Especially if you are unsure
if a list will be subject to X. This would also be true and still
neutral for concatenation. So we would end up with two identity
elements unless they are equal as far as listhood is concerned.
Hmm, I agree that's all a bit constructed.


Rather than bend the current practical meanings of ()
and [], we possibly have the symbolic concept expressible as none(*).

> We don't define junctions as special in lists, which means it would
> be up to the implementation of infix: to do something with it.

Would '() but .elems(1)' do the trick, too? With overloading X in
mind any type distinct from List would do. E.g. a UnitList singleton
type. But I don't get how none(*) expresses the unit list concept.
Why is none(*).elems == 1 and why (1,2,none(*)) === (1,2)? Would
other junctions behave the same?



But let me reiterate that lists are just lists, not sets.  In fact,
they're closer to bags than sets.  But lists are as much about
ordering as they are about membership.  Please don't take the use
of mathematical language to metaphorically describe the behavior of
infix: as an attempt to confuse you.  :)


I just wondered what mathematical structure (List,infix:) has.
Without an identity element it's just a semigroup. Whereas (List,
infix:<,>) is a monoid with () as identity element. So e.g. I wonder
if there's an isomorphism between that and (Str,infix<~>). But I
agree that I shouldn't bother the list with such things unless I
hope it could be useful for Perl 6 which I hoped for the identity
of X. But seemingly that was a false hope.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"
  -- C.A.R. Hoare

Re: parrot benchmarking

[Geoffrey Broadwell]

On Wed, 2008-04-16 at 09:47 +0100, Tim Bunce wrote:
> I agree with Geoffrey that optimized builds should be the default.

Thank you!

> Developers working on parrot (wanting unoptimized/debug quick builds)
> would just need to set an env var in their .profile, for example, and
> carry on as now.  No changes in their procedures, and no changes in the
> docs (other than to mention the env var).

The only issue here is that in the past the optimizers have had a
number of bugs (presumably because the optimized builds were getting
used so rarely).  If the developers never use optimized builds, but we
ship them to end users, then A) each monthly release will be buggier for
end users than the developers think it is, and B) we'll get confusion
when attempting to recreate reported bugs.

That's part of why I recommended the more complex arrangement, in which
the two parrot variants are both built and self-documenting, rather than
only one being built which is magically different for developers and end
users.

I understand Tim's concern that this is a complex arrangement, so here's
a compromise: can we at least agree that the pre-release testing should
include running the full test suite against both the debug and optimized
builds, and that there should be some easy way for a developer to choose
to run the test suite using either or both builds at will?


-'f

Re: static types, checking, conversions

[Mark J. Reed]

Type checking in both js2/ecma4 and p6 is not merely documentation.
It is enforced, but only if present.  This is a tricky thing to
achieve, which is why I suggested reading the js stuff to see how they
went about it.



On 4/16/08, Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> wrote:
>
> On Apr 16, 2008, at 3:44 , TSa wrote:
> > I found two dissertations and a couple of papers about typing
> > JavaScript. The quintessential is that optional typing is
> > defined as having *no* impact on the dynamic behavior of the
> > program. In that respect type annotations are like comments.
> > I doubt that this is the case with Perl 6, or is it?
>
> My understanding is that Perl6 uses static typing as such (i.e. not
> merely comments) when it is provided.
>
> --
> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
> system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
> electrical and computer engineering, carnegie mellon universityKF8NH
>
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

Mark J. Reed <[EMAIL PROTECTED]>

[perl #52956] [BUG] --parrot_is_shared=0 IS shared?

[via RT]

# New Ticket Created by  Will Coleda 
# Please include the string:  [perl #52956]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=52956 >


While trying to put the macport for 0.6.1 together, I noticed that the
install failed.

Tracked it down to the fact that --parrot_is_shared=0 seems to be
generating a parrot that relies on a shared lib.

This is happening for me on osx/86 (but the build works because it's
finding the blib/lib version: once you install it, this fails because
then it can't find the lib.), and on linux/x86 on feather (the build
fails because miniparrot requires the shared library and can't find
it, stopping the build immediately).

This worked as recently as 0.5.2 (the last macport)

-- 
Will "Coke" Coleda

Re: Returning Arrays?

[TSa]

HaloO,

John M. Dlugosz wrote:

I seem to recall seeing sigils in a signature without names,
but now I can't remember where.


E.g. in S06 und section "The want function".

Regards, TSa.
--

"The unavoidable price of reliability is simplicity"
  -- C.A.R. Hoare

Re: static types, checking, conversions

[Brandon S. Allbery KF8NH]

On Apr 16, 2008, at 3:44 , TSa wrote:

I found two dissertations and a couple of papers about typing
JavaScript. The quintessential is that optional typing is
defined as having *no* impact on the dynamic behavior of the
program. In that respect type annotations are like comments.
I doubt that this is the case with Perl 6, or is it?


My understanding is that Perl6 uses static typing as such (i.e. not  
merely comments) when it is provided.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH

Re: Chained Comparisons ?

[Patrick R. Michaud]

On Wed, Apr 16, 2008 at 07:49:48AM -, John M. Dlugosz wrote:
> I know how comparisons are chained in Perl 6.  There is a very 
> short section on it in S03.
> 
> So, are the operators infix:{'<'} etc. written in the normal 
> way to take two arguments?  Then the language transforms 
> A op B op C into A op B AND B op C on an innate level.  Does 
> that apply to any user-defined operator with those names?  

It applies to any operator that has 'chain' associativity --
see S06, "Subroutine traits".

> If I want to make my own chained operator, perhaps the 
> curvy ≼, ≽, etc. or make my operator ≧ 
> a synonym for >=, how would I tell the compiler that they 
> belong to the same set of chained operators?

sub infix:«≽» ($a, $b) is equiv(&infix:«>=») { ... }

Or, if you want to create your own chained precedence level
separate from the existing relational ops, 

sub infix:«≽» ($a, $b) is assoc is looser(...)  { ... }

Pm

Re: Chained Comparisons ?

[Brandon S. Allbery KF8NH]

On Apr 16, 2008, at 3:49 , John M. Dlugosz wrote:
Or, are the operators written in a tricky way, to return an object  
that encapsulates the original right argument and the proper  
boolean result, and has forms to take this object as well?  IOW, no  
built-in support.


Yes, they use multiple-typed values such that (3 < 5) returns (5 but  
True), which used in a numeric context is a 5 that can be chained  
with further infix:{'<'}s but in a boolean context is True.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH

Re: Returning Arrays?

[TSa]

HaloO,

John M. Dlugosz wrote:

How do you declare a function that returns an array?  Something like

   sub foo (blah) is Array of X { ... }


The 'is' there is your invention, isn't it? The synopsis
require 'of' or 'returns' depending if you want to specify
the outer and/or inner type. The 'is' keyword would be used as

  sub foo () is Code of Array of X {...}
  sub foo () is Code[Array[X]] {...}  # same thing

In general the of keyword instanciates parametric types just like
the direct indexing of typenames with []. The only unspecced thing
is the variance of ::Foo[::Bar] with respect to ::Bar.


seems right, but it has two problems.  First is a real problem, and is a 
mistake seen a lot in C# and the .NET framework.  A concrete type is 
used when it should be an interface.  What if the function wants to use 
a List or Seq or some bizzare tied thing of its own?  Defining it as



   sub foo (blah) is Positional of X { ... }


What's so bad about 'sub foo ( --> Positional of X) {...}'?


is not as snappy, and I don't think it will catch on.  (I'm still 
wondering whether Lists and Seq's are Positional anyway, merely lazy 
about it)


I would thing that Seq does Positional in an immutable way.
That is in &postcircumfix:<[ ]>:(Positional $seq: Int *@@slice --> ::T)
::T is always an rvalue.


So that brings me to the second problem.  For parameters, it's no 
problem because people just use the @ sigil and don't think about 
containers.  So how do I do that with the return value?  I don't name 
the return value, so there is no place to put the sigil.


  sub foo (blah) is X @*


Should be 'sub foo( --> X *@)' or 'our X *@ sub foo()'. In case that
this doesn't parse 'our :(X *@) sub foo()' should.


perhaps?   I seem to recall seeing sigils in a signature without names, 
but now I can't remember where.


Same here. Should be in the synopsis somewhere.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"
  -- C.A.R. Hoare

Re: parrot benchmarking

[James E Keenan]

Tim Bunce wrote:


I'd suggest a simpler approach than Geoffrey's: The default 'make'
target could default to a reasonably safe portable optimized target, but
be overridable by an env var.

[snip]

Developers working on parrot (wanting unoptimized/debug quick builds)
would just need to set an env var in their .profile, for example, and
carry on as now.  No changes in their procedures, and no changes in the
docs (other than to mention the env var).



If I understand the configuration system correctly, we currently handle 
this via flags to Configure.pl:


   --optimize   Optimized compile
   --optimize=flags Add given optimizer flags

(I'm attaching config/init/optimize.pm for reference.)

Would there be something gained by using env vars rather than (or in 
addition to) the configuration options?


kid51


# Copyright (C) 2001-2005, The Perl Foundation.
# $Id: optimize.pm 24769 2008-01-12 01:22:59Z jkeenan $

=head1 NAME

config/init/optimize.pm - Optimization

=head1 DESCRIPTION

Enables optimization by adding the appropriate flags for the local platform to
the C. Should this be part of config/inter/progs.pm ? XXX

=cut

package init::optimize;

use strict;
use warnings;

use base qw(Parrot::Configure::Step);

sub _init {
my $self = shift;
my %data;
$data{description} = q{Enabling optimization};
$data{result}  = q{};
return \%data;
}

our $verbose;

sub runstep {
my ( $self, $conf ) = @_;

$verbose = $conf->options->get( 'verbose' );
print "\n" if $verbose;

print "(optimization options: init::optimize)\n"
if $verbose;

# A plain --optimize means use perl5's $Config{optimize}.  If an argument
# is given, however, use that instead.
my $optimize = $conf->options->get('optimize');
if ( defined $optimize ) {
$self->set_result('yes');

# disable debug flags
$conf->data->set( cc_debug => '' );
$conf->data->add( ' ', ccflags => "-DDISABLE_GC_DEBUG=1 -DNDEBUG" );
if ( $optimize eq "1" ) {

# use perl5's value
# gcc 4.1 doesn't like -mcpu=xx, i.e. it's deprecated
my $opts = $conf->data->get_p5('optimize');
my $gccversion = $conf->data->get( 'gccversion' );
my $arch_opt = 'cpu';
if ( defined $gccversion and $gccversion > 3.3 ) {
$arch_opt = 'arch';
}
$opts =~ s/-mcpu=/-m$arch_opt=/;
$conf->data->add( ' ', ccflags => $opts );
print "opts: ", $opts, "\n" if $verbose;

# record what optimization was enabled
$conf->data->set( optimize => $opts );
}
else {

# use what was passed to --optimize on the CLI
$conf->data->add( ' ', ccflags => $optimize );

# record what optimization was enabled
$conf->data->set( optimize => $optimize );
}
}
else {
$self->set_result('no');
print "(none requested) " if $conf->options->get('verbose');
}

return 1;
}

1;

# Local Variables:
#   mode: cperl
#   cperl-indent-level: 4
#   fill-column: 100
# End:
# vim: expandtab shiftwidth=4:

Re: static types, checking, conversions

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:



I found two dissertations and a couple of papers about typing
JavaScript. The quintessential is that optional typing is
defined as having *no* impact on the dynamic behavior of the
program. In that respect type annotations are like comments.
I doubt that this is the case with Perl 6, or is it?


Regards, TSa.



In Perl 6, I'm trying to identify where type annotations affect behavior 
and when they don't.  I think that's important since it separates the 
must-do analysis from optional optimization, and conversely describes 
what the optimizer can't do even if it thinks it could.


As a degenerate case, not being allowed to assign or bind something is 
certainly an impact on behavior.


If MMD is based on actual dynamic types, then static types don't affect 
the result, other than to prevent the program from loading the wrong 
thing into a variable that then gets used as a parameter. 


Also, look at:
 
  my Dog $spot .= new("Fido");


the static type Dog does affect the subsequent use of .new.  Even if you 
explain that in terms of the protoobject, the point is that saying Dog 
=does= something, it's not just a comment like a (current) Javascript 
naming convention.


--John

Re: Help with the "What can I do with Perl 6 today" wiki page

[Aaron Trevena]

On 16/04/2008, Aaron Trevena <[EMAIL PROTECTED]> wrote:
>  I started the "What can I do with Perl 6 today" wiki page at the start
>  of the year...

That would be at
http://www.perlfoundation.org/perl6/index.cgi?what_can_i_do_with_perl_6_today

A.


-- 
http://www.aarontrevena.co.uk
LAMP System Integration, Development and Hosting

Help with the "What can I do with Perl 6 today" wiki page

[Aaron Trevena]

Hi All,

I started the "What can I do with Perl 6 today" wiki page at the start
of the year, but have been too busy with $paid_work to put much time
into it since.

I was hoping anybody who's written perl 6 code and run it with Rakudo
or pugs could help fill in the gaps - there are a list of common/usual
programming problems (please add more, for example from the P99 list),
each requires a solution in perl 6 and a status message of whether it
runs, errors or is blindingly fast (or make a cup of tea and watch
some TV slow).

Any contribution would be helpful - you don't have to benchmark, or
use the latest version, or you could just add benchmarks to others
with newer or older versions.

Cheers,

A.

-- 
http://www.aarontrevena.co.uk
LAMP System Integration, Development and Hosting

Re: parrot benchmarking

[Tim Bunce]

On Wed, Apr 16, 2008 at 12:10:54AM +0200, Leopold Toetsch wrote:
> Am Freitag, 11. April 2008 21:02 schrieb Nuno 'smash' Carvalho:
> > Greetings all,
> >
> >  I just posted a little Parrot benchmark in my use.perl's journal
> 
> Just a reminder:
> 
> Please don't use unoptimzed builds for benchmarking.

I agree with Geoffrey that optimized builds should be the default.

For example, chromatic posted a blog recently that said:
(http://www.oreillynet.com/onlamp/blog/2008/04/multiple_dispatch_now_please.html)

 Download the new Parrot release next Tuesday, 15 April 2008, then type:
 $ perl Configure.pl
 $ make
 $ make perl6
 ... and you too can play with this in your own code.

Anyone doing that is likely to get a poor impression of performance.

I'd suggest a simpler approach than Geoffrey's: The default 'make'
target could default to a reasonably safe portable optimized target, but
be overridable by an env var.

That way curious end-users and benchmarkers get good performance by
default. Possibly not the ultimate, but far better than now.

Developers working on parrot (wanting unoptimized/debug quick builds)
would just need to set an env var in their .profile, for example, and
carry on as now.  No changes in their procedures, and no changes in the
docs (other than to mention the env var).

Then chromatic's recipie works well for all.

Tim.

Returning Arrays?

[John M. Dlugosz]

How do you declare a function that returns an array?  Something like

   sub foo (blah) is Array of X { ... }

seems right, but it has two problems.  First is a real problem, and is a 
mistake seen a lot in C# and the .NET framework.  A concrete type is 
used when it should be an interface.  What if the function wants to use 
a List or Seq or some bizzare tied thing of its own?  Defining it as



   sub foo (blah) is Positional of X { ... }

is not as snappy, and I don't think it will catch on.  (I'm still 
wondering whether Lists and Seq's are Positional anyway, merely lazy 
about it)


So that brings me to the second problem.  For parameters, it's no 
problem because people just use the @ sigil and don't think about 
containers.  So how do I do that with the return value?  I don't name 
the return value, so there is no place to put the sigil.


  sub foo (blah) is X @*

perhaps?   I seem to recall seeing sigils in a signature without names, 
but now I can't remember where.


--John

Re: static types, checking, conversions

[John M. Dlugosz]

Thom Boyer thom-at-boyers.org |Perl 6| wrote:

Mark J. Reed wrote:

It would behoove @Larry to examine the optional type constraints
system proposed for Javascript:TNG (see link from firefox.com
developers page).  I therefore assume that they have done so, but
others would benefit by doing likewise. :)
  
Could you be a little more specific on where to find information on 
JavaScript's proposed system of type constraints?


The firefox.com developers page 
(http://developer.mozilla.org/en/docs/Main_Page) has several links on 
JavaScript topics. The most promising one leads to 
http://developer.mozilla.org/en/docs/JavaScript, and, while that page 
has info on quite a few different versions of JavaScript, version 2 is 
not one of them. Of course, I'm only guessing that JavaScript 2 is 
what you might have meant by Javascript:TNG. (I can't find any mention 
of TNG or "Next Generation" on either of those pages, either.)

=thom

The links under ECMAscript 4, like "Read the tutorial on evolutionary 
programming in ES4 
"
In http://www.ecmascript.org/.  This paper shows how to add types to an 
untyped program as it grows.


--John

Chained Comparisons ?

[John M. Dlugosz]

I know how comparisons are chained in Perl 6.  There is a very short section on 
it in S03.

So, are the operators infix:{'<'} etc. written in the normal way to take two 
arguments?  Then the language transforms A op B op C into A op B AND B op C on 
an innate level.  Does that apply to any user-defined operator with those 
names?  If I want to make my own chained operator, perhaps the curvy ≼, 
≽, etc. or make my operator ≧ a synonym for >=, how would I tell 
the compiler that they belong to the same set of chained operators?

Or, are the operators written in a tricky way, to return an object that 
encapsulates the original right argument and the proper boolean result, and has 
forms to take this object as well?  IOW, no built-in support.

--John

Re: static types, checking, conversions

[TSa]

HaloO,

Mark J. Reed wrote:

It would behoove @Larry to examine the optional type constraints
system proposed for Javascript:TNG (see link from firefox.com
developers page).  I therefore assume that they have done so, but
others would benefit by doing likewise. :)


Do I get that right: you imply that I didn't do my homework?
Note that I don't feel offended by that.

I found two dissertations and a couple of papers about typing
JavaScript. The quintessential is that optional typing is
defined as having *no* impact on the dynamic behavior of the
program. In that respect type annotations are like comments.
I doubt that this is the case with Perl 6, or is it?


Regards, TSa.
--

The Angel of Geometry and the Devil of Algebra fight for the soul
of any mathematical being.   -- Attributed to Hermann Weyl