[perl #53430] [PATCH] Concat call_list.txt from fragments in config step

[via RT]

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


Currently, src/call_list.txt is a static file; any time new NCI
signatures are needed, it is edited manually.  For very large APIs with
many unique signatures that may vary from platform to platform (OpenGL),
this is suboptimal.  There are (at least) two problems with this:

1. Even if a large API is disabled (because it wasn't detected, or
because Configure.pl was called with a --without-foo option), the unused
NCI signatures are still compiled and included in the parrot library --
potentially several hundred K completely wasted.

2. When generating signatures from system headers, call_list.txt will
need to be modified at Configure time anyway, so pretending it is static
makes no sense.

For this reason, I believe we should add a config step that concatenates
src/call_list.txt from a directory of fragments.  The attached patch
makes just that change, splitting the existing call_list.txt into
several smaller pieces in the process.  I have checked that running
Configure with the patch will produce a call_list.txt that contains the
same signatures, though in a different order.

Once this basic concept is accepted, then OpenGL (and potentially other
libraries) can start generating the call_list fragment from system
headers, and in particular not generating a fragment at all if OpenGL is
disabled.  This will come in a separate patch.  (Currently the OpenGL
fragment contains only a handful of signatures, just enough to get the
triangle to spin.  The generated version of opengl.in will contain
200-250 signatures.)


-'f

=== MANIFEST
==
--- MANIFEST	(revision 4951)
+++ MANIFEST	(local)
@@ -291,6 +291,16 @@
 config/auto/va_ptr/test_c.in[]
 config/auto/warnings.pm []
 config/auto/warnings/test_c.in  []
+config/gen/call_list.pm []
+config/gen/call_list/00_header.in   []
+config/gen/call_list/core.in[]
+config/gen/call_list/misc.in[]
+config/gen/call_list/mysql.in   []
+config/gen/call_list/opengl.in  []
+config/gen/call_list/pcre.in[]
+config/gen/call_list/postgresql.in  []
+config/gen/call_list/sdl.in []
+config/gen/call_list/tests.in   []
 config/gen/config_h.pm  []
 config/gen/config_h/config_h.in []
 config/gen/config_h/feature_h.in[]
@@ -2688,7 +2698,6 @@
 src/bignum.h[]
 src/builtin.c   []
 src/byteorder.c []
-src/call_list.txt   [devel]doc
 src/charset.c   []
 src/charset/ascii.c []
 src/charset/ascii.h []
@@ -3521,6 +3530,7 @@
 t/steps/auto_warnings-06.t  []
 t/steps/auto_warnings-07.t  []
 t/steps/auto_warnings-08.t  []
+t/steps/gen_call_list-01.t  []
 t/steps/gen_config_h-01.t   []
 t/steps/gen_config_pm-01.t  []
 t/steps/gen_core_pmcs-01.t  []
=== MANIFEST.generated
==
--- MANIFEST.generated	(revision 4951)
+++ MANIFEST.generated	(local)
@@ -285,6 +285,7 @@
 languages/squaak/squaak.pbc   [main]
 languages/tcl/tcl.pbc [main]
 languages/tcl/runtime/tcllib.pbc  [main]
+src/call_list.txt [devel]doc
 src/glut_callbacks.c  [main]
 src/jit_emit.h[main]include
 src/nci.c [main]
=== config/gen/call_list	(new directory)
==
=== config/gen/call_list/00_header.in
==
--- config/gen/call_list/00_header.in	(revision 4951)
+++ config/gen/call_list/00_header.in	(local)
@@ -0,0 +1,54 @@
+# Copyright (C) 2002-2008, The Perl Foundation.
+
+# DO NOT EDIT THIS FILE.
+#
+# Any changes made here will be lost.
+#
+# This file is generated automatically by config/gen/call_list.pm
+#

rand in Rakudo

[Илья]

Hi!
This is (attached) small game Paper-Rock-Scissors based on the
chromatic`s journal post.
I have question about rand in Rakudo. Look like it`s do not work properly:

...
s
Your Scissors
My Scissors
Draw.
s
Your Scissors
My Scissors
Draw.
s
Your Scissors
My Scissors
Draw.
s
Your Scissors
My Rock
You LOOSE!
s
Your Scissors
My Rock
You LOOSE!
s
Your Scissors
My Rock
You LOOSE!
s
Your Scissors
My Rock
You LOOSE!
s
Your Scissors
My Paper
You WIN!
s
Your Scissors
My Paper
You WIN!
s
Your Scissors
My Paper
You WIN!
s
Your Scissors
My Paper
You WIN!
s
Your Scissors
My Paper
You WIN!
s
Your Scissors
My Paper
You WIN!
s
Your Scissors
My Scissors
Draw.
s
Your Scissors
My Scissors
Draw.
s
Your Scissors
My Scissors
Draw.
...

And other example:

say rand(100) for 1..100;

Rakudo say equal number all time (


Thanks!
P.S. Excuse, my bad English.

Ilya Belikin
Vladivostok.pm


RPS.pl
Description: Perl program

Re: [perl #53430] [PATCH] Concat call_list.txt from fragments in config step

[chromatic]

On Sunday 27 April 2008 17:04:10 Geoffrey Broadwell wrote:

> Currently, src/call_list.txt is a static file; any time new NCI
> signatures are needed, it is edited manually.  For very large APIs with
> many unique signatures that may vary from platform to platform (OpenGL),
> this is suboptimal.  There are (at least) two problems with this:
>
> 1. Even if a large API is disabled (because it wasn't detected, or
> because Configure.pl was called with a --without-foo option), the unused
> NCI signatures are still compiled and included in the parrot library --
> potentially several hundred K completely wasted.
>
> 2. When generating signatures from system headers, call_list.txt will
> need to be modified at Configure time anyway, so pretending it is static
> makes no sense.
>
> For this reason, I believe we should add a config step that concatenates
> src/call_list.txt from a directory of fragments.  The attached patch
> makes just that change, splitting the existing call_list.txt into
> several smaller pieces in the process.  I have checked that running
> Configure with the patch will produce a call_list.txt that contains the
> same signatures, though in a different order.
>
> Once this basic concept is accepted, then OpenGL (and potentially other
> libraries) can start generating the call_list fragment from system
> headers, and in particular not generating a fragment at all if OpenGL is
> disabled.  This will come in a separate patch.  (Currently the OpenGL
> fragment contains only a handful of signatures, just enough to get the
> triangle to spin.  The generated version of opengl.in will contain
> 200-250 signatures.)

I'm somewhat unconvinced, in general.  For the OpenGL bindings, where the 
build process has to build specific C code which links against specific 
libraries, I can mostly see the point.  For other bindings where it's 
possible to build Parrot without even having the libraries installed, install 
them later, and still use them (everything but the test libraries and 
OpenGL), there's little benefit.  This just multiplies files based on which 
library needed a specific signature first.  I'm not sure that will help us 
maintain them.

As you say, the real problem is that we have a static list of NCI thunks known 
only at compile time.  If it's easier to work on the OpenGL bindings in tree 
with a change like this, I can live with having a separate library of 
signatures merged in somehow, but I'm not sure that benefit outweighs the 
pain of splitting up everything else, especially given all of the hope that 
Kevin succeeds in his GSoC project.

-- c

Re: First look: Advanced Polymorphism whitepaper

[Ovid]

--- "John M. Dlugosz" <[EMAIL PROTECTED]> wrote:

> Here is a first look at the ideas I've worked up concerning the Perl
> 6 type system.  It's an overview of the issues and usage of
> higher-order types in comparison with traditional subtyping
subclasses.
> 
> http://www.dlugosz.com/Perl6/

Nice paper.  ++

This might not be too big a deal, but the formatting of the code is a
bit odd.  It's not monospaced and the indentation and brace placement
seem very arbitrary.  Since these items are always "code smells" to me
of a bad programmer[1], seeing it in an otherwise good paper is very
jarring.  Could this merely be a strange rendering artifact?

Cheers,
Ovid

[1]  Well, the monospaced bit isn't since I'm not used to programmers
programming in word processors instead of text editors.  Perhaps I'm
spoiled :)

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Perl and CGI  - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/

Re: First look: Advanced Polymorphism whitepaper

[John M. Dlugosz]

Ovid publiustemp-perl6language2-at-yahoo.com |Perl 6| wrote:

This might not be too big a deal, but the formatting of the code is a
bit odd.  It's not monospaced and the indentation and brace placement
seem very arbitrary.  Since these items are always "code smells" to me
of a bad programmer[1], seeing it in an otherwise good paper is very
jarring.  Could this merely be a strange rendering artifact?

Cheers,
Ovid

[1]  Well, the monospaced bit isn't since I'm not used to programmers
programming in word processors instead of text editors.  Perhaps I'm
spoiled :)
  


The code is not monospaced, since this isn't the 1980's.  I've been 
writing code using an editor that uses proportional fonts for years.  I 
find it more readable, and helps fit things on a line without scrolling too.


Source Insight even changes font size and color for highlighting.  
Function names are big and blue, for example.


If the braces and positioning is funny, I wonder if it's a rendering 
thing.  I'm using Windows and have the fonts.  Could you post a screen 
shot and point out what's inconsistent?



   sub foo ()
{   # one char indent for body
...
}


class {
   has $.x;# blocks indented 3 spaces
   }

Closing brace is always aligned with the content it is closing.  Opening 
may be same, or on previous line.


--John

Re: First look: Advanced Polymorphism whitepaper

[Ovid]

--- "John M. Dlugosz" <[EMAIL PROTECTED]> wrote:

> If the braces and positioning is funny, I wonder if it's a rendering 
> thing.  I'm using Windows and have the fonts.  Could you post a
> screen shot and point out what's inconsistent?

I see that a large part of this is that we have significantly different
brace styles, so I can see your point.  With the proportional font,
it's still a bit difficult to see, but if you're happy with it, that's
OK.

I'm also on Windows, though not sure about the fonts.

http://tinyurl.com/4mvnxw
http://i82.photobucket.com/albums/j275/publius_ovidius/Random/polymorphism.png

Glad to see the nice work, though.

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Perl and CGI  - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/

Re: Concurrency implementation tasks

[Allison Randal]

Bob Rogers wrote:

   From: "Klaas-Jan Stol" <[EMAIL PROTECTED]>

   about the removal of internal_exception: the specified ticket (in the
   list on the wiki) does not have a conclusion: no final decision seems
   to be have made on that issue.  What's more, a quick check on a few
   calls to internal_exception revealed that there's no interpreter
   argument available . . .

Yes; that's what the ticket is really about, whether it's worth
modifying callers in the few cases where it's needed, so the ticket is
really misnamed.  internal_exception itself is still needed for sanity
checking in cases where exceptions cannot work.

   A good example of this is for instance in tsq.c::queue_destroy. (line
   381) This exception indicates something's wrong with the thread-safe
   queue, which I assume is really really fatal, and should result in
   parrot exiting?

   kjs

Yes.  These cases should be few (stack corruption, severe GC problems),
but they cannot be reduced to zero without removing useful sanity
checks.  In some cases, it may be a choice between an internal_exception
and a (possibly exploitable) jump into random memory.

   In any case, convertible calls to internal_exception should already
have been handled in RT#40392 (though it is possible that other
inappropriate internal_exception calls may have crept in since then).


There's certainly a need for a way to die cleanly and print out an error 
message and possibly a backtrace under extreme circumstances. But that's 
not what internal_exception does (even though we're using it that way 
now). internal_exception is an early and very poor attempt at an 
implementation of exceptions, and carries a load of baggage of nasty code.


I'll put in a new task:

- Provide a simple function for completely fatal errors where throwing 
an exception isn't possible, and replace last dregs of 
'internal_exception' with it.


Allison

Re: Concurrency implementation tasks

[Klaas-Jan Stol]

On Mon, Apr 28, 2008 at 1:53 PM, Allison Randal <[EMAIL PROTECTED]> wrote:
> Bob Rogers wrote:
>
> >
> >   From: "Klaas-Jan Stol" <[EMAIL PROTECTED]>
> >
> >
> >   about the removal of internal_exception: the specified ticket (in the
> >   list on the wiki) does not have a conclusion: no final decision seems
> >   to be have made on that issue.  What's more, a quick check on a few
> >   calls to internal_exception revealed that there's no interpreter
> >   argument available . . .
> >
> > Yes; that's what the ticket is really about, whether it's worth
> > modifying callers in the few cases where it's needed, so the ticket is
> > really misnamed.  internal_exception itself is still needed for sanity
> > checking in cases where exceptions cannot work.
> >
> >   A good example of this is for instance in tsq.c::queue_destroy. (line
> >   381) This exception indicates something's wrong with the thread-safe
> >   queue, which I assume is really really fatal, and should result in
> >   parrot exiting?
> >
> >   kjs
> >
> > Yes.  These cases should be few (stack corruption, severe GC problems),
> > but they cannot be reduced to zero without removing useful sanity
> > checks.  In some cases, it may be a choice between an internal_exception
> > and a (possibly exploitable) jump into random memory.
> >
> >   In any case, convertible calls to internal_exception should already
> > have been handled in RT#40392 (though it is possible that other
> > inappropriate internal_exception calls may have crept in since then).
> >
>
>  There's certainly a need for a way to die cleanly and print out an error
> message and possibly a backtrace under extreme circumstances. But that's not
> what internal_exception does (even though we're using it that way now).
> internal_exception is an early and very poor attempt at an implementation of
> exceptions, and carries a load of baggage of nasty code.
>
>  I'll put in a new task:
>
>  - Provide a simple function for completely fatal errors where throwing an
> exception isn't possible, and replace last dregs of 'internal_exception'
> with it.
>
>  Allison
>

so this function should exit then? Maybe it should be called
'exit_fatal', or something at least that marks that parrot will bail
out.

kjs

YAPC::NA 2008 Hackathon

[Will Coleda]

If you're attending the YAPC::NA 2008 conference, please consider
attending the pre-con parrot hackathon.

Let's keep this on the yapc wiki, since we're targeting attendees as
well as existing hackers.

http://conferences.mongueurs.net/yn2008/wiki?node=ParrotHackathon

I threw on one or two things I know we'll be working on then.

Please note that the release is supposed to be occurring on the
Tuesday of the conference, 2 days after the hackathon.

See you there!
-- 
Will "Coke" Coleda

Re: First look: Advanced Polymorphism whitepaper

[Jon Lang]

John M. Dlugosz wrote:
> Here is a first look at the ideas I've worked up concerning the Perl 6 type
> system.  It's an overview of the issues and usage of higher-order types in
> comparison with traditional subtyping subclasses.
>
>  http://www.dlugosz.com/Perl6/

Very interesting, if puzzling, read.

I'm having some difficulty understanding the business with £.  I
_think_ that you're saying that £ sort of acts as a prefix operator
that changes the meaning of the type with which it is associated; and
the only time that a change in meaning occurs is if the type in
question makes use of ::?CLASS or a generic parameter.

You say that in Perl 6, a role normally treats ::?CLASS as referring
to the role.  Perhaps things have changed while I wasn't looking; but
I was under the impression that Perl 6 roles try to be as transparent
as possible when it comes to the class hierarchy.  As such, I'd expect
::?CLASS to refer to whatever class the role is being composed into,
rather than the role that's being composed.  If you have need to
reference the role itself, I'd expect something like ::?ROLE to be
used instead.  Of course, without something like your '£', the only
way to decide whether you actually want the class type or the role
type would be within the definition of the role itself; and without a
sort of "reverse '£'", there would be no way to take a role that
refers to ::?ROLE and make it refer to ::?CLASS instead.  That said,
I'm not convinced that this is a problem.

As for classes and roles that have generic parameters: here, you've
completely lost me.  How does your proposed '£' affect such classes
and roles?

-- 
Jonathan "Dataweaver" Lang

Re: YAPC::NA 2008 Hackathon

[Will Coleda]

On Mon, Apr 28, 2008 at 10:09 AM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 28, 2008 at 09:54:17AM -0400, Will Coleda wrote:
>  >
>  > Please note that the release is supposed to be occurring on the
>  > Tuesday of the conference, 2 days after the hackathon.
>
>  Should we perhaps change the release date?  It seems like we might
>  want to add a bunch of things during the hackathon that wouldn't
>  necessarily be ready for release by Tuesday.
>
>  Pm
>
>

I agree that we don't want to impact the release date, but branches
are cheap: we can do a temporary hackathon branch (or seven) and fold
them back in post-release if there are concerns about being ready by
Tuesday.


-- 
Will "Coke" Coleda

Re: YAPC::NA 2008 Hackathon

[Patrick R. Michaud]

On Mon, Apr 28, 2008 at 09:54:17AM -0400, Will Coleda wrote:
> 
> Please note that the release is supposed to be occurring on the
> Tuesday of the conference, 2 days after the hackathon.

Should we perhaps change the release date?  It seems like we might
want to add a bunch of things during the hackathon that wouldn't
necessarily be ready for release by Tuesday.

Pm

Re: Decrement of Numbers in Strings (Was: [svn:perl6-synopsis] r14460 - doc/trunk/design/syn)

[TSa]

HaloO,

John M. Dlugosz wrote:

Huh?

if you call
 $q = "aaa";
 incr($q);

then the value passed in is a Str.  The static type is Any, the dynamic 
type is Str.


Sorry, I got that messed up. The ::Type captures the dynamic type
of the value, of course. But I want to get at the constraint of
the caller's container. The purpose is to read out the intents of
the caller which are manifested in the container constraint. BTW,
you call the container constraint the static type of the variable.


$x.VAR.WHAT will be the prototype object for Scalar, which has nothing 
to do with the value inside it.


I doubt that. I believe that Scalar is the HOW of VAR $x. That is their
syntactic slots are:

   my $x is HOW of WHAT;

The actual value brings in another pair of HOW and WHAT. This WHAT
has to be compatible with the WHAT of $x. As far as type checking
is concerned the HOW is of secondary interest.




>>   ::T $x = $ret if T ~~ Type; # don't violate caller's constraint
>>
>>   return $ret;
>>   }
>>
> T is undefined.

My idea was to capture it from $ret which is a compile time
activity as far is the origin of ::T is concerned. Then I
collapsed

   my ::T $temp = $ret;
   if T ~~ Type { $x = $temp; }

into a single line.


>>   say incr(5); # print 6, no error
> Compile-time error; can't bind 5 to an rw.

But I wanted a decent rw parameter that particularly does not
show this unforgiving behavior. The error should be signaled
when the rw is actually used as an lvalue. That is $x := 5
is ok, but a subsequent $x = 6 is an error.


Why not just let MMD do it?  Switching on the type is bad smell.  
Polymorphism should do that.


The whole point of my ranting was to behave differently for

  my Str $x = "-100"; # $x.WHAT === $x.VAR.WHAT === Str

and

  my $y = "-100"; # $y.WHAT === Str but $y.VAR.WHAT === Any

MMD only sees the Str of "-100" *not* the Str of $x!


   multi sub incr (Str $x is rw --> Str) { ... }# do the string 
version.

   multi sub incr (Numeric ::T $x is rw --> T)
{
$x += 1;


This is a potential error. Because here is where the caller's
container's constraint needs to be checked against the value
you try to write into it. Numeric is *not* the store constraint
of the caller.



However I've no clever idea how to denote a contra-variant constraint
on the caller's container's constraint in an rw sub. Perhaps

   sub foo (FooOut <-- FooIn $x is rw) {...}

The arrow is of course optional. Its absence means that the caller has
to provide an unconstraint container to be type save. The visual problem
with this arrow is that is cousin --> is not per parameter but for the
whole sub. Alternatively it could be a signature on the trait.


I think I see what you're getting at.  But I don't see what it has to do 
with the container.  The value bound to $x needs to be at least as 
general as FooIn.


You mean FooIn is a contra-variant constraint of the value? I figured
that binding is about containers. Binding to a value implies a read-only
binding. Now how would that be expressed in terms of constraints? Easy,
the constraint of the virtual container is unconditionally false.

   my where {False} $x = 17; # same as: constant $x = 17;

Here the = 17 is pseudo-assignment and doesn't check the constraint.
Otherwise you can't get in a value at all. We could also extent that
to single assignment semantics and allow exactly one assignment to $x
including the one at initialization time.

The problem with rw parameters is that the current spec doesn't have
enough syntactic slots to put the cross checking of values' types for
in- and output. In sub foo (A $a) the A is a constraint for a value that
$a could be bound to at call time. But changing that to sub foo (A $a
is rw) still means A being a constraint on the values you bind to $a
at call time. But where is the syntactic slot of the constraint for
assignment to $a in the body of foo? In this slot foo announces the
type of things it is going to put into $a.


 Hmm, or are you thinking of subset constrained 
containers trying to bind to $x?  Currently, there is no mechanism to 
propagate the constraint in.


But the outer constraint has to be checked whenever a new value is
stored in the caller's variable. So it *must* go in somehow.


 If the binding chooses to work by 
"copy/return" mechanism, then it will be checked when the value is 
copied back to the original container, using that container's SET, 
assuming copy/return is designed and intended to reference the original 
container not just the differently-typed value.  I can see the need for 
that, such as with tied variables in general.  Or maybe the container 
for $x aliases the original container -- that might be what "is ref" is 
supposed to mean.


Apart from the fact that I really have difficulties to see a difference
between 'is rw' and 'is ref' I nonetheless try to define binding in a
type sound fashion. A signature with a rw parameter is exactly the same
as binding two containers together.

Re: [perl #53430] [PATCH] Concat call_list.txt from fragments in config step

[Geoffrey Broadwell]

On Mon, 2008-04-28 at 00:30 -0700, chromatic wrote:
> I'm somewhat unconvinced, in general.  For the OpenGL bindings, where the 
> build process has to build specific C code which links against specific 
> libraries, I can mostly see the point.  For other bindings where it's 
> possible to build Parrot without even having the libraries installed, install 
> them later, and still use them (everything but the test libraries and 
> OpenGL), there's little benefit.

Here you seem to be assuming that we will already have all of the NCI
signatures we will need for any new library we come across.  My
experience (and my reading of comments in call_list.txt) is that that is
very rarely true.  At any given time, NCI seems be missing a handful of
odd signatures needed by any new library we come across, which means
that call_list.txt has to be updated and Parrot rebuilt anyway.

nci.o is already needlessly large for users that don't need to load a
pile of libraries; trying to include all "common" signatures will just
make that worse.

> This just multiplies files based on which 
> library needed a specific signature first.  I'm not sure that will help us 
> maintain them.

I'm not wedded to splitting them up as much as I did.  In fact, I'd be
fine with core.in, opengl.in, and misc.in.  Better for you?

> As you say, the real problem is that we have a static list of NCI thunks 
> known 
> only at compile time.  If it's easier to work on the OpenGL bindings in tree 
> with a change like this,

It is.

> I can live with having a separate library of 
> signatures merged in somehow, but I'm not sure that benefit outweighs the 
> pain of splitting up everything else, especially given all of the hope that 
> Kevin succeeds in his GSoC project.

I'm trying to take advantage of the time I have now to get this OpenGL
binding working well.  As many of you can attest, my personal project
time is very bursty -- I can't wait until the end of the summer,
especially since there's no guarantee of success (though definitely my
best wishes for success).

I'm not trying to make the best choice for Parrot 1.0.  I'm trying to
make the best choice for Parrot 0.6.x.


-'f

Parrot Bug Summary

[Parrot Bug Summary]

Parrot Bug Summary

http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Apr 28 16:11:11 2008 GMT
---

  * Numbers
  * New Issues
  * Overview of Open Issues
  * Ticket Status By Version
  * Requestors with most open tickets

---

Numbers

Ticket Counts: 63 new + 724 open = 787
Created this week: 23
Closed this week: 15

---

New Issues

New issues that have not been responded to yet

1 - 2 weeks old
53140 PDD13PBC work: Implement write support for creating new .pbc files
53138 PDD13PBC work: test the hell out of PMC-based .pbc file write support
53136 PDD13PBC work: Convert PMC-based access code to use new on-disk format
53134 PDD13PBC work: Move everything in parrot over to the new PMC-based API
53132 PDD13PBC work: test the hell out of PMC-based readonly .pbc file access
53130 PDD13PBC work: implement readonly .pbc file access through PMC API
53120 Re: [TODO] config/auto/perldoc.pm: Recent change needs discussion
53104 dyld: lazy symbol binding failed: Symbol not found: _parrot_i386_cmpxchg 
  (icu?)
53100 The ** operator like in  ** ',' is missing from PGE. would be a
  nice feature for writing parsers and minimizing rules
52956 [BUG] --parrot_is_shared=0 IS shared?
2 - 3 weeks old
52886 [BUG] including gmp.h causes build break in C++ build
52876 Re: [bug] Build failure with G++
52870 [PATCH] README_cygwin.pod update
3 - 4 weeks old
52396 [BUG] Test 1 of t/pmc/io.t sigbus on ppc
4 - 5 weeks old
52204 [BUG]: Parrot build failure on parisc64 GNU/Linux
5 - 6 weeks old
6 - 7 weeks old
51634 [BUG] docs/parrotbyte.pod && docs/pdds/pdd13_bytecode.pod are either
  incorrect/unclear
7 - 8 weeks old
8 - 9 weeks old
51350 [PATCH] correction and extension of the pair implementation
51330 [TODO] dynext - dll versioning
51206 [BUG] Tail call into PIR compiler broken?
9 - 10 weeks old
10 - 11 weeks old
50894 [BUG] parrot -O Fails Tests
11 - 12 weeks old
50642 [CAGE] refactor init_class_from_hash & parrot_class_register
12 - 13 weeks old
50500 [PROPOSAL][PAST] add PAST::Var :scope('attribute')
50448 [Memory Leak] IMCC Can Leak Lexer Data on Exception
50360 [RFE] Redesign Parrot NCI callback functionality
13 - 14 weeks old
50090 [TODO] pge - throw useful exception on non-quoted non-word characters
14 - 15 weeks old
49970 [BUG] -O1 and -O2 don't turn on -Ot as per docs
49968 [BUG] 'parrot -O2 oofib.pir' errors out, when -O1 succeeds
49966 [BUG] parrot -v -O2 segfaults, when -v and -O2 separately both work
15 - 16 weeks old
16 - 17 weeks old
49258 [BUG] Parrot::Test with --run-exec assumes "." is in $PATH
17 - 18 weeks old
49177 [TODO] pct - PAST::Val node should throw exception if :value attribute
  not set
18 - 19 weeks old
49001 [PROPOSAL][DOCS] Change word "compilation_unit" into something else (like
  "sub")
48877 [TODO] Don't generate .constant declarations for vtable method names.
19 - 20 weeks old
48749 [BUG] t/examples/tutorial.t if_unless failure (Win32)
48645 [CAGE] Make PMCs depend on Parrot::Pmc2c::* Modules
48507 [BUG] oo - n_add, n_sub, etc. don't work with objects
48467 [BUG] assignment of objects creates Ref instead of copy
20 - 21 weeks old
48367 [BUG] intlist_get could be dereferencing NULL
48150 [DOCS] pdd23 doesn't document obtaining thrown exception object
---

Overview of Open Issues

PlatformSeverity  Tag  Lang
aix0abandoned 0   5005threads   0  Amber0
All1fatal 2   bounce0  BASIC0
bsdos  0High  0   Bug  87  bc   0
cygwin 2low   1   compiler  0  befunge  0
cygwin_nt  0medium0   configure 3  bf   0
darwin10none  1   core  2  cola 0
dec_osf0Normal2   dailybuild0  forth0
dgux   0unknown   0   docs  3  jako 0
dos0Wishlist  3   duplicate 0  Lisp 0
dynixptx   0 install   2  lolcode  0
freebsd8  library   0  m4   0
generic0  notabug   0  ook  0
gnu0  notok 0  perl61
HPUX   2  ok0  plot 0
irix   0  Patch32  punie0
irix64 0  regex 2  pynie0
Linux  3  sendToCPAN0  python   0
lynxos 0  Todo437  ruby 0
mac0 

Re: First look: Advanced Polymorphism whitepaper

[TSa]

HaloO,

Jon Lang wrote:

I'm having some difficulty understanding the business with £.  I
_think_ that you're saying that £ sort of acts as a prefix operator
that changes the meaning of the type with which it is associated; and
the only time that a change in meaning occurs is if the type in
question makes use of ::?CLASS or a generic parameter.


The difference seems to be the two definitions of bendit

  sub bendit (IBend ::T $p -->T)
  {
 IBend $q = get_something;
 my T $result= $p.merge($q);
 return $result;
  }

  sub bendit (£ IBend ::T $p -->T)
  {
 T $q = get_something;
 my T $result= $p.merge($q);
 return $result;
  }

The interesting thing that is actually left out is the return type
of get_something. I think in both cases it does the IBend role but
in the second definition it is checked against the actual type T
which is Thingie if called with a Thingie for $p. So the advantage
of this code is that the compiler can statically complain about the
return type of get_something. But I fail to see why we need £ in
the signature to get that.

The use of £ in

  sub foo (£ pointlike ::PointType $p1, PointType $p2 --> PointType)

is that of *structural* subtyping. Here FoxPoint is found to be
pointlike. In that I would propose again to take the 'like' operator
from JavaScript 2. Doing that the role should be better named Point
and foo reads:

  sub foo (like Point ::PointType $p1, PointType $p2 --> PointType)

This is very useful to interface between typed and untyped code.
With rthe 'like' the role Point has to be *nominally* available
in the argument. There's no problem with 'like'-types beeing more
expensive than a nominal check.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity"  -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: First look: Advanced Polymorphism whitepaper

[Jon Lang]

TSa wrote:
>  The use of £ in
>
>   sub foo (£ pointlike ::PointType $p1, PointType $p2 --> PointType)
>
>  is that of *structural* subtyping. Here FoxPoint is found to be
>  pointlike. In that I would propose again to take the 'like' operator
>  from JavaScript 2. Doing that the role should be better named Point
>  and foo reads:
>
>   sub foo (like Point ::PointType $p1, PointType $p2 --> PointType)
>
>  This is very useful to interface between typed and untyped code.
>  With the 'like' the role Point has to be *nominally* available
>  in the argument. There's no problem with 'like'-types being more
>  expensive than a nominal check.

Ah; that clears things up considerably.  If I understand you
correctly, John is using '£' to mean "use Duck Typing here".  _That_,
I can definitely see uses for.  As well, spelling it as 'like' instead
of '£' is _much_ more readable.  With this in mind, the above
signature reads as "$p1 must be like a Point, but it needn't actually
be a Point.  Both $p2 and the return value must be the same type of
thing that $p1 is."

What, if anything, is the significance of the fact that pointlike (in
John's example; 'Point' in TSa's counterexample) is generic?

-- 
Jonathan "Dataweaver" Lang

Re: [PATCH] Rearrange PObj Struct Members

[Andy Dougherty]

On Sun, 27 Apr 2008, chromatic wrote:

> Here's another proposed patch for testing on various platforms.  I'm trying 
> to 
> get rid of some dodgy casts (which likely don't help C++ and processors with 
> stricter alignment than 32-bit x86).  I'd also like to remove unnecessary 
> members from a few structs.  This is the next step.
> 
> Are there any weird errors or unexpected crashes on anything more exotic than 
> 32-bit x86 GNU/Linux?

>  /* Parrot Object - base class for all others */
>  typedef struct pobj_t {
> +Parrot_UInt flags;
>  UnionVal u;
> -Parrot_UInt flags;
>  } pobj_t;

On 32-bit SPARC, at least, that's going to introduce a wasted 4 bytes of
padding.  (UnionVal will be aligned on an 8-byte boundary, but
Parrot_Uint is only 4 bytes long.)  This is, of course, not an error in
and of itself, but if any of those "dodgy" casts assume no padding, then
there will be an error.

I'll try building, but since there are 4 permutations to try (cc and gcc,
and with and without this patch) and since each build takes 1 to 2 hours
if everything goes well, it won't be until tomorrow at the earliest that
I can report anything back.  (Longer, if manual intervention is required
to fix unrelated errors.)

-- 
Andy Dougherty  [EMAIL PROTECTED]

[perl #53458] mingw32 does not sleep!

[via RT]

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


When you run the following pir script:

.sub main
sleep 1
print "ok\n"
.end

Running this on linux waits for a second, and then prints ok (as
expected).

Running this on mingw32 prints ok and returns immediately.  This is
with mingw-gcc 3.4.5 as packaged with Strawberry Perl 5.10.0.

Mark

Re: [PATCH] Rearrange PObj Struct Members

[chromatic]

On Monday 28 April 2008 10:24:37 Andy Dougherty wrote:

> On Sun, 27 Apr 2008, chromatic wrote:

> >  /* Parrot Object - base class for all others */
> >  typedef struct pobj_t {
> > +Parrot_UInt flags;
> >  UnionVal u;
> > -Parrot_UInt flags;
> >  } pobj_t;

> On 32-bit SPARC, at least, that's going to introduce a wasted 4 bytes of
> padding.  (UnionVal will be aligned on an 8-byte boundary, but
> Parrot_Uint is only 4 bytes long.)  This is, of course, not an error in
> and of itself, but if any of those "dodgy" casts assume no padding, then
> there will be an error.

I don't believe they rely on padding, but that's why I ask.

Does 32-bit SPARC align all pointers on 8-byte boundaries?

My ultimate goal is to get pobj_t down to:

typedef struct pobj_t {
Parrot_UInt flags;
void *GC_next;
} pobj_t;

... where GC_next is a pointer to the next pobj_t in a linked list.  This'll 
let us get rid of all of the dodgy casts required to maintain arena free 
lists as well as to remove the UnionVal member from GCable structures that 
don't need it, saving two pointers from every Stack_Chunk_t, for example.

> I'll try building, but since there are 4 permutations to try (cc and gcc,
> and with and without this patch) and since each build takes 1 to 2 hours
> if everything goes well, it won't be until tomorrow at the earliest that
> I can report anything back.  (Longer, if manual intervention is required
> to fix unrelated errors.)

Much appreciated.

-- c

Re: First look: Advanced Polymorphism whitepaper

[chromatic]

On Monday 28 April 2008 10:15:25 Jon Lang wrote:

> Ah; that clears things up considerably.  If I understand you
> correctly, John is using '£' to mean "use Duck Typing here".  _That_,
> I can definitely see uses for.  As well, spelling it as 'like' instead
> of '£' is _much_ more readable.  With this in mind, the above
> signature reads as "$p1 must be like a Point, but it needn't actually
> be a Point.  Both $p2 and the return value must be the same type of
> thing that $p1 is."

That was always my goal for roles in the first place.  I'll be a little sad if 
Perl 6 requires an explicit notation to behave correctly here -- that is, if 
the default check is for subtyping, not polymorphic equivalence.

-- c

Re: [PATCH] Rearrange PObj Struct Members

[Mark Glines]

On Mon, 28 Apr 2008 10:41:27 -0700
Mark Glines <[EMAIL PROTECTED]> wrote:

> On Sun, 27 Apr 2008 17:24:53 -0700
> chromatic <[EMAIL PROTECTED]> wrote:
> 
> > Here's another proposed patch for testing on various platforms.  I'm
> > trying to get rid of some dodgy casts (which likely don't help C++
> > and processors with stricter alignment than 32-bit x86).  I'd also
> > like to remove unnecessary members from a few structs.  This is the
> > next step.
> > 
> > Are there any weird errors or unexpected crashes on anything more
> > exotic than 32-bit x86 GNU/Linux?
> 
> This seems to cause memory corruption on linux/amd64.  Only two tests
> fail, the rest pass, but those are failing pretty gloriously.  See
> attached log.

gdb's backtrace is a bit easier to read.

(gdb) bt
#0  0x2b16911a2185 in raise () from /lib/libc.so.6
#1  0x2b16911a3630 in abort () from /lib/libc.so.6
#2  0x2b16911db96b in __libc_message () from /lib/libc.so.6
#3  0x2b16911e0b9d in malloc_printerr () from /lib/libc.so.6
#4  0x2b16911e2575 in _int_free () from /lib/libc.so.6
#5  0x2b16911e28a6 in free () from /lib/libc.so.6
#6  0x2b168ddebf6c in mem_sys_free (from=0x95d960) at src/gc/memory.c:251
#7  0x2b168ddef475 in parrot_hash_destroy (interp_unused=0x60a080, 
hash=0x95d960) at src/hash.c:778
#8  0x2b168df2a441 in Parrot_Hash_destroy (interp=0x60a080, pmc=0x981238) 
at ./src/pmc/hash.pmc:121
#9  0x2b168ddea44d in Parrot_dod_free_pmc (interp=0x60a080, 
pool_unused=0x60b750, p=0x981238) at src/gc/dod.c:674
#10 0x2b168ddea36b in Parrot_dod_sweep (interp=0x60a080, pool=0x60b750) at 
src/gc/dod.c:640
#11 0x2b168ddead53 in Parrot_dod_ms_run (interp=0x60a080, flags=4) at 
src/gc/dod.c:1103
#12 0x2b168ddeaec8 in Parrot_do_dod_run (interp=0x60a080, flags=4) at 
src/gc/dod.c:1169
#13 0x2b168ddf6cd2 in Parrot_really_destroy (interp=0x60a080, 
exit_code_unused=0, arg_unused=0x0) at src/inter_create.c:346
#14 0x2b168dde31e1 in Parrot_exit (interp=0x60a080, status=0) at 
src/exit.c:89
#15 0x00400c3e in main (argc=1, argv=0x7fff1d0d70c0) at src/main.c:66

Mark

Re: [perl #53356] Misc. build warnings

[chromatic]

On Monday 28 April 2008 10:40:02 [EMAIL PROTECTED] wrote:

> Just a query, wouldn't:
> Index: src/key.c
> ===
> --- src/key.c   (revision 27216)
> +++ src/key.c   (working copy)
> @@ -329,12 +329,14 @@
>  }
>  case KEY_start_slice_FLAG:
>  case KEY_inf_slice_FLAG:
> +{
> +return VTABLE_get_integer(interp, key);
> +}
>  default:
> -break;
> +return VTABLE_get_integer(interp, key);
>  }
>  }
>
> -return VTABLE_get_integer(interp, key);
>  }
>
>
> be a little better?

What if the PMC passed in isn't a Key PMC, but has an integer value?

-- c

Re: [PATCH] Rearrange PObj Struct Members

[chromatic]

On Monday 28 April 2008 10:41:27 Mark Glines wrote:

> On Sun, 27 Apr 2008 17:24:53 -0700
>
> chromatic <[EMAIL PROTECTED]> wrote:
> > Here's another proposed patch for testing on various platforms.  I'm
> > trying to get rid of some dodgy casts (which likely don't help C++
> > and processors with stricter alignment than 32-bit x86).  I'd also
> > like to remove unnecessary members from a few structs.  This is the
> > next step.
> >
> > Are there any weird errors or unexpected crashes on anything more
> > exotic than 32-bit x86 GNU/Linux?
>
> This seems to cause memory corruption on linux/amd64.  Only two tests
> fail, the rest pass, but those are failing pretty gloriously.  See
> attached log.

I had a similar problem on my 32-bit Linux system, until I added this part of 
the patch:

=== src/gc/smallobject.c
==
--- src/gc/smallobject.c.   (revision 27223)
+++ src/gc/smallobject.c.   (local)
@@ -523,9 +517,9 @@
 free_list_end  = &dest->free_list;
-
 while (*free_list_end)
-free_list_end = (void **)*free_list_end;
+free_list_end = &PMC_struct_val((PObj *)free_list_end);
-
-*free_list_end = source->free_list;
+PMC_struct_val((PObj *)free_list_end) = source->free_list;
-
 /* now append source arenas */
 cur_arena = source->last_Arena;

My backtrace was different, though.  I was getting segfaults trying to walk 
the free list when the next pointer was flag values, not a pointer.

If there's an error on 64-bit systems, I still suspect it's in there.

-- c

Re: First look: Advanced Polymorphism whitepaper

[John M. Dlugosz]

Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:

I'm having some difficulty understanding the business with £.  I
_think_ that you're saying that £ sort of acts as a prefix operator
that changes the meaning of the type with which it is associated; and
the only time that a change in meaning occurs is if the type in
question makes use of ::?CLASS or a generic parameter.

  
Not only generic parameters, but overridden virtual type names too.  In 
general, type names can be changed by derived classes just like methods.





You say that in Perl 6, a role normally treats ::?CLASS as referring
to the role.  
No, ::?CLASS refers to the actual class.  Maybe you're confused because 
a footnote said to pretend it stood for the role when using the role 
itself as a type, because it does not exist at all.





As for classes and roles that have generic parameters: here, you've
completely lost me.  How does your proposed '£' affect such classes
and roles?

  


The pointlike[::T] role has a generic parameter.
The concrete class Point3D[Rat] matches "pointlike", and it figures out 
that to make the match work that T has to be Rat.

It figures out that FoxPoint is pointlike, if it uses Num for T.

Re: First look: Advanced Polymorphism whitepaper

[Jon Lang]

chromatic wrote:
> Jon Lang wrote:
>  > Ah; that clears things up considerably.  If I understand you
>  > correctly, John is using '£' to mean "use Duck Typing here".  _That_,
>  > I can definitely see uses for.  As well, spelling it as 'like' instead
>  > of '£' is _much_ more readable.  With this in mind, the above
>  > signature reads as "$p1 must be like a Point, but it needn't actually
>  > be a Point.  Both $p2 and the return value must be the same type of
>  > thing that $p1 is."
>
>  That was always my goal for roles in the first place.  I'll be a little sad 
> if
>  Perl 6 requires an explicit notation to behave correctly here -- that is, if
>  the default check is for subtyping, not polymorphic equivalence.

By my reading, the default behavior is currently nominal typing, not
duck-typing.  That said, my concern isn't so much about which one is
the default as it is about ensuring that the programmer isn't stuck
with the default.  Once it's decided that Perl 6 should support both
duck-typing and nominal typing, _then_ we can argue over which
approach should be the default, and how to represent the other
approach.

-- 
Jonathan "Dataweaver" Lang

[perl #53352] [PATCH] Build warnings in STRUCT_COPY

[NotFound]

On Sat, Apr 26, 2008 at 8:16 PM, chromatic <[EMAIL PROTECTED]> wrote:

>  > A possible solution is to add another macro taking as second argument
>  > the struct instead of a pointer.
>  That seems cleaner to me; want to try that patch?

The attached patch adds the macro STRUCT_COPY_ST, and uses it in the
src/charset charset init functions.

All test pass with 27216 in my system (Ubuntu 8.04)

-- 
Salu2
Index: src/charset/iso-8859-1.c
===
--- src/charset/iso-8859-1.c	(revisión: 27216)
+++ src/charset/iso-8859-1.c	(copia de trabajo)
@@ -628,7 +628,7 @@
 NULL
 };
 
-STRUCT_COPY(return_set, &base_set);
+STRUCT_COPY_ST(return_set, base_set);
 return_set->preferred_encoding = Parrot_fixed_8_encoding_ptr;
 Parrot_register_charset(interp, "iso-8859-1", return_set);
 return return_set;
Index: src/charset/binary.c
===
--- src/charset/binary.c	(revisión: 27216)
+++ src/charset/binary.c	(copia de trabajo)
@@ -467,7 +467,7 @@
 NULL
 };
 
-STRUCT_COPY(return_set, &base_set);
+STRUCT_COPY_ST(return_set, base_set);
 return_set->preferred_encoding = Parrot_fixed_8_encoding_ptr;
 Parrot_register_charset(interp, "binary", return_set);
 return return_set;
Index: src/charset/unicode.c
===
--- src/charset/unicode.c	(revisión: 27216)
+++ src/charset/unicode.c	(copia de trabajo)
@@ -925,7 +925,7 @@
 NULL
 };
 
-STRUCT_COPY(return_set, &base_set);
+STRUCT_COPY_ST(return_set, base_set);
 /*
  * for now use utf8
  * TODO replace it with a fixed uint_16 or uint_32 encoding
Index: src/charset/ascii.c
===
--- src/charset/ascii.c	(revisión: 27216)
+++ src/charset/ascii.c	(copia de trabajo)
@@ -789,7 +789,7 @@
 NULL
 };
 
-STRUCT_COPY(return_set, &base_set);
+STRUCT_COPY_ST(return_set, base_set);
 return_set->preferred_encoding = Parrot_fixed_8_encoding_ptr;
 Parrot_register_charset(interp, "ascii", return_set);
 return return_set;
Index: include/parrot/parrot.h
===
--- include/parrot/parrot.h	(revisión: 27216)
+++ include/parrot/parrot.h	(copia de trabajo)
@@ -241,10 +241,12 @@
 #endif /* O_BINARY */
 
 /* Hide our struct copying behind macros */
+/* Copying to struct pointer from struct pointer */
 #define STRUCT_COPY(d, s)(PARROT_ASSERT(d), PARROT_ASSERT(s), *(d)=*(s))
 #define STRUCT_COPY_N(d, s, n) (PARROT_ASSERT(d), PARROT_ASSERT(s), PARROT_ASSERT(sizeof (*(d))==sizeof (*(s))), memcpy((d), (s), sizeof (*(d))*(n)))
+/* Copying to struct pointer from struct */
+#define STRUCT_COPY_ST(d, s)(PARROT_ASSERT(d), *(d)=(s))
 
-
 /* internationalization settings */
 #ifdefPARROT_HAS_GETTEXT
 #  include 

Re: [perl #53352] [PATCH] Build warnings in STRUCT_COPY

[NotFound]

On Mon, Apr 28, 2008 at 8:15 PM, NotFound <[EMAIL PROTECTED]> wrote:

>  All test pass with 27216 in my system (Ubuntu 8.04)

Sorry, I mean 27219, 27216 was from the modified files.

-- 
Salu2

Re: [PATCH] Rearrange PObj Struct Members

[Mark Glines]

On Mon, 28 Apr 2008 11:05:45 -0700
chromatic <[EMAIL PROTECTED]> wrote:

> I had a similar problem on my 32-bit Linux system, until I added this
> part of the patch:
> 
> === src/gc/smallobject.c
> ==
> --- src/gc/smallobject.c.   (revision 27223)
> +++ src/gc/smallobject.c.   (local)
> @@ -523,9 +517,9 @@
>  free_list_end  = &dest->free_list;
> -
>  while (*free_list_end)
> -free_list_end = (void **)*free_list_end;
> +free_list_end = &PMC_struct_val((PObj *)free_list_end);
> -
> -*free_list_end = source->free_list;
> +PMC_struct_val((PObj *)free_list_end) = source->free_list;
> -
>  /* now append source arenas */
>  cur_arena = source->last_Arena;

So far as I can tell, your previously posted patch contains the above
code changes, the only difference I can see is that this one also
removes a few blank lines.  So I guess the error is still in there on
amd64...

Mark

Re: First look: Advanced Polymorphism whitepaper

[John M. Dlugosz]

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

HaloO,

Jon Lang wrote:

I'm having some difficulty understanding the business with £.  I
_think_ that you're saying that £ sort of acts as a prefix operator
that changes the meaning of the type with which it is associated; and
the only time that a change in meaning occurs is if the type in
question makes use of ::?CLASS or a generic parameter.


The difference seems to be the two definitions of bendit

  sub bendit (IBend ::T $p -->T)
  {
 IBend $q = get_something;
 my T $result= $p.merge($q);
 return $result;
  }

  sub bendit (£ IBend ::T $p -->T)
  {
 T $q = get_something;
 my T $result= $p.merge($q);
 return $result;
  }

The interesting thing that is actually left out is the return type
of get_something. I think in both cases it does the IBend role but
in the second definition it is checked against the actual type T
which is Thingie if called with a Thingie for $p. So the advantage
of this code is that the compiler can statically complain about the
return type of get_something. But I fail to see why we need £ in
the signature to get that.
In the top example, merge has to be declared with invariant parameter 
types, so the actual type passed "isa" IBend.  That means merge's 
parameter is IBend.  If get_something returned the proper type, it would 
be lost.


In the lower example, the merge parameter is allowed to be covariant.  
The actual type is not a subtype of IBend.  The parameter to merge is 
checked to make sure it is also T.  The £ means "use the higher-order 
£ike-this" rather than "isa" substitutability.


The issue is how to give covariant parameter types =and= minimal type 
bounds for T at the same time.





The use of £ in

  sub foo (£ pointlike ::PointType $p1, PointType $p2 --> PointType)

is that of *structural* subtyping. Here FoxPoint is found to be
pointlike. In that I would propose again to take the 'like' operator
from JavaScript 2. Doing that the role should be better named Point
and foo reads:

  sub foo (like Point ::PointType $p1, PointType $p2 --> PointType)

This is very useful to interface between typed and untyped code.
With rthe 'like' the role Point has to be *nominally* available
in the argument. There's no problem with 'like'-types beeing more
expensive than a nominal check.


Yes, with Point would work for matching as well as pointlike.  When the 
covariant parameter type destroys the "isa" relationship between Point 
and Point3D, "£ Point" will still indicate conformance to the "like" rules.


I like "like" as the ASCII synonym to £, but didn't want to get into 
that in the whitepaper.  I wanted to concentrate on the need for a 
higher-order type check, not worry about how to modify the grammar.


--John

Re: [PATCH] Rearrange PObj Struct Members

[chromatic]

On Monday 28 April 2008 11:19:08 Mark Glines wrote:

> chromatic <[EMAIL PROTECTED]> wrote:
> > I had a similar problem on my 32-bit Linux system, until I added this
> > part of the patch:
> >
> > === src/gc/smallobject.c
> > ==
> > --- src/gc/smallobject.c.   (revision 27223)
> > +++ src/gc/smallobject.c.   (local)
> > @@ -523,9 +517,9 @@
> >  free_list_end  = &dest->free_list;
> > -
> >  while (*free_list_end)
> > -free_list_end = (void **)*free_list_end;
> > +free_list_end = &PMC_struct_val((PObj *)free_list_end);
> > -
> > -*free_list_end = source->free_list;
> > +PMC_struct_val((PObj *)free_list_end) = source->free_list;
> > -
> >  /* now append source arenas */
> >  cur_arena = source->last_Arena;
>
> So far as I can tell, your previously posted patch contains the above
> code changes, the only difference I can see is that this one also
> removes a few blank lines.  So I guess the error is still in there on
> amd64...

Right.  I meant that this part of my previously posted patch fixed similar 
thread and STM errors for me, so it likely needs a further tweak on your 
system to run correctly.

-- c

Re: First look: Advanced Polymorphism whitepaper

[Jon Lang]

John M. Dlugosz wrote:
> TSa wrote:
> > Jon Lang wrote:
> > > I'm having some difficulty understanding the business with £.  I
> > > _think_ that you're saying that £ sort of acts as a prefix operator
> > > that changes the meaning of the type with which it is associated; and
> > > the only time that a change in meaning occurs is if the type in
> > > question makes use of ::?CLASS or a generic parameter.
> >
> > The difference seems to be the two definitions of bendit
> >
> >  sub bendit (IBend ::T $p -->T)
> >  {
> > IBend $q = get_something;
> > my T $result= $p.merge($q);
> > return $result;
> >  }
> >
> >  sub bendit (£ IBend ::T $p -->T)
> >  {
> > T $q = get_something;
> > my T $result= $p.merge($q);
> > return $result;
> >  }
> >
> > The interesting thing that is actually left out is the return type
> > of get_something. I think in both cases it does the IBend role but
> > in the second definition it is checked against the actual type T
> > which is Thingie if called with a Thingie for $p. So the advantage
> > of this code is that the compiler can statically complain about the
> > return type of get_something. But I fail to see why we need £ in
> > the signature to get that.
>
>  In the top example, merge has to be declared with invariant parameter
> types, so the actual type passed "isa" IBend.  That means merge's parameter
> is IBend.  If get_something returned the proper type, it would be lost.
>
>  In the lower example, the merge parameter is allowed to be covariant.  The
> actual type is not a subtype of IBend.  The parameter to merge is checked to
> make sure it is also T.  The £ means "use the higher-order £ike-this" rather
> than "isa" substitutability.
>
>  The issue is how to give covariant parameter types =and= minimal type
> bounds for T at the same time.

Perhaps it would be clearer if you could illustrate the difference between

   sub bendit (£ IBend ::T $p -->T)
   {
  T $q = get_something;
  my T $result= $p.merge($q);
  return $result;
   }

and

   sub bendit (IBend ::T $p -->T)
   {
  T $q = get_something;
  my T $result= $p.merge($q);
  return $result;
   }

Or perhaps it would be clearer if I actually understood what
"covariant" means.

> > The use of £ in
> >
> >  sub foo (£ pointlike ::PointType $p1, PointType $p2 --> PointType)
> >
> > is that of *structural* subtyping. Here FoxPoint is found to be
> > pointlike. In that I would propose again to take the 'like' operator
> > from JavaScript 2. Doing that the role should be better named Point
> > and foo reads:
> >
> >  sub foo (like Point ::PointType $p1, PointType $p2 --> PointType)
> >
> > This is very useful to interface between typed and untyped code.
> > With rthe 'like' the role Point has to be *nominally* available
> > in the argument. There's no problem with 'like'-types beeing more
> > expensive than a nominal check.
>
>  Yes, with Point would work for matching as well as pointlike.  When the
> covariant parameter type destroys the "isa" relationship between Point and
> Point3D, "£ Point" will still indicate conformance to the "like" rules.
>
>  I like "like" as the ASCII synonym to £, but didn't want to get into that
> in the whitepaper.  I wanted to concentrate on the need for a higher-order
> type check, not worry about how to modify the grammar.

OK; how does "higher-order type checks" vs. "isa relationships" differ
from "duck typing" vs. "nominal typing"?

-- 
Jonathan "Dataweaver" Lang

[perl #53120] Re: [TODO] config/auto/perldoc.pm: Recent change needs discussion

[James Keenan via RT]

Since the problematic commit was reverted, we can resolve this ticket.

[perl #53462] [TODO] pct - report smarter error message for non-PAST nodes

[via RT]

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


Whenever a non-PAST node appears in a PAST tree, PCT should
provide a far more useful error message than it does now.

Pm

[perl #53464] [TODO] pge - trim whitespace around #= keys

[via RT]

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


Modify PGE to trim extra whitespace around #= keys
(which really shouldn't be there, but we should be nice 
about it when there is).

Or, if not actually trimming the whitespace, then at least
issue a warning about it.

Pm

Re: First look: Advanced Polymorphism whitepaper

[John M. Dlugosz]

Andy_Bach-at-wiwb.uscourts.gov |Perl 6| wrote:

Just an even simpler question:
  sub bendit (£ IBend ::T $p -->T)
   {
  T $q = get_something;

Does the "T ..." usage then scope the var so no 'my/our' is needed?

a
---
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
Voice: (608) 261-5738 Fax: 264-5932

"When angry, count to four; when very angry, swear."
Mark Twain


  

Yes.  ::T declares T, as a parameter, just like $p.


--John

Re: First look: Advanced Polymorphism whitepaper

[John M. Dlugosz]

Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:

Ah; that clears things up considerably.  If I understand you
correctly, John is using '£' to mean "use Duck Typing here".  _That_,
I can definitely see uses for.  As well, spelling it as 'like' instead
of '£' is _much_ more readable.  With this in mind, the above
signature reads as "$p1 must be like a Point, but it needn't actually
be a Point.  Both $p2 and the return value must be the same type of
thing that $p1 is."

What, if anything, is the significance of the fact that pointlike (in
John's example; 'Point' in TSa's counterexample) is generic?

  


It is designed for coping with generics and virtual types that have been 
redefined by the base class.  It works for structural "duck" typing too, 
using the same algorithm.


The example shows that it needs to figure out what T must be, and help 
show how generic classes don't have the proper "isa" because the types 
change in each specialization.

Re: First look: Advanced Polymorphism whitepaper

[John M. Dlugosz]

chromatic chromatic-at-wgz.org |Perl 6| wrote:
That was always my goal for roles in the first place.  I'll be a little sad if 
Perl 6 requires an explicit notation to behave correctly here -- that is, if 
the default check is for subtyping, not polymorphic equivalence.


-- c

  


Perhaps the default can be "like", not "isa", for cases where the actual 
type is being captured in a generic argument too.


F-bounds type propagation only works if the actual assigned type is 
tracked and further propagated through use of that symbol.  Making it a 
one-time assignment (actual type noticed when binding, and then type 
noted as a generic) allows the full higher-order polymorphism to work 
without needing to radically change the way typing works in the first 
place--it's the same as declaring it of that type, which the type system 
can handle already.


That make more sense if you just read the higher order parts (pun 
intended; parts 18-20 or so) of "The Theory of Classification" 
(http://www.dcs.shef.ac.uk/~ajhs/classify/index.html)


I will meditate on the idea of what happens if higher-order polymorphism 
is the default for matching.


--John

Re: First look: Advanced Polymorphism whitepaper

[John M. Dlugosz]

Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:

Perhaps it would be clearer if you could illustrate the difference between

   sub bendit (£ IBend ::T $p -->T)
   {
  T $q = get_something;
  my T $result= $p.merge($q);
  return $result;
   }

and

   sub bendit (IBend ::T $p -->T)
   {
  T $q = get_something;
  my T $result= $p.merge($q);
  return $result;
   }

Or perhaps it would be clearer if I actually understood what
"covariant" means.

  

The use of £ in

 sub foo (£ pointlike ::PointType $p1, PointType $p2 --> PointType)

is that of *structural* subtyping. Here FoxPoint is found to be
pointlike. In that I would propose again to take the 'like' operator
from JavaScript 2. Doing that the role should be better named Point
and foo reads:

 sub foo (like Point ::PointType $p1, PointType $p2 --> PointType)

This is very useful to interface between typed and untyped code.
With rthe 'like' the role Point has to be *nominally* available
in the argument. There's no problem with 'like'-types beeing more
expensive than a nominal check.
  

 Yes, with Point would work for matching as well as pointlike.  When the
covariant parameter type destroys the "isa" relationship between Point and
Point3D, "£ Point" will still indicate conformance to the "like" rules.

 I like "like" as the ASCII synonym to £, but didn't want to get into that
in the whitepaper.  I wanted to concentrate on the need for a higher-order
type check, not worry about how to modify the grammar.



OK; how does "higher-order type checks" vs. "isa relationships" differ
from "duck typing" vs. "nominal typing"?

  




I think I see another whitepaper in my immediate future.

And to think I was asking the same question ("what is covariant") on 
this mailing list less than a month ago!  See 
http://www.nntp.perl.org/group/perl.perl6.language/2008/04/msg28845.html 
and the reply.


--John

Re: [PATCH] Rearrange PObj Struct Members

[Andy Dougherty]

On Mon, 28 Apr 2008, chromatic wrote:

> On Monday 28 April 2008 10:24:37 Andy Dougherty wrote:
> 
> > On Sun, 27 Apr 2008, chromatic wrote:
> 
> > >  /* Parrot Object - base class for all others */
> > >  typedef struct pobj_t {
> > > +Parrot_UInt flags;
> > >  UnionVal u;
> > > -Parrot_UInt flags;
> > >  } pobj_t;
> 
> > On 32-bit SPARC, at least, that's going to introduce a wasted 4 bytes of
> > padding.  (UnionVal will be aligned on an 8-byte boundary, but
> > Parrot_Uint is only 4 bytes long.)  This is, of course, not an error in
> > and of itself, but if any of those "dodgy" casts assume no padding, then
> > there will be an error.
> 
> I don't believe they rely on padding, but that's why I ask.

And wisely so!  I sometimes (ok, often) find it a bit hard to tell what 
the underlying assumptions are.

> Does 32-bit SPARC align all pointers on 8-byte boundaries?

No.  It's the double inside the UnionVal cache that forces the 8-byte 
alignment.

> 
> My ultimate goal is to get pobj_t down to:
> 
>   typedef struct pobj_t {
>   Parrot_UInt flags;
>   void *GC_next;
>   } pobj_t;

That should not require any padding.  So my objection about wasting space 
can be ignored, since it would only be a temporary issue that would 
ultimately go away.

> ... where GC_next is a pointer to the next pobj_t in a linked list.  This'll 
> let us get rid of all of the dodgy casts required to maintain arena free 
> lists as well as to remove the UnionVal member from GCable structures that 
> don't need it, saving two pointers from every Stack_Chunk_t, for example.

Sounds like a worthy goal.  A cache is a nice-sounding idea, but perhaps 
not quite at this lowest level.

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: [perl #53352] [PATCH] Build warnings in STRUCT_COPY

[chromatic]

On Monday 28 April 2008 11:15:56 NotFound wrote:

> The attached patch adds the macro STRUCT_COPY_ST, and uses it in the
> src/charset charset init functions.
>
> All test pass with 27216 in my system (Ubuntu 8.04)

I renamed it to STRUCT_COPY_FROM_STRUCT (but that's only a little better than 
your version) and applied it as r27222.

Thanks!

-- c

[perl #45015] [TODO] Create a 'Rational' PMC for rational numbers

[Markus Mayr via RT]

I am making good progress on this item. The PMC should be function
complete. I am going to check it against coding guidelines, write some
more tests and comment the code, during the next few days. After that it
should be commit-worthy.

Btw, IMHO this should not reference #36330. Rationals are exact. If
accuracy is not sufficient, it is increased. BigNums are as good and
accurate as you want them to be. Nevertheless they work at a fixed level
of precision (being much faster therefore). So these two PMCs have two
different purposes and implementation is not related to each other.


rational.pmc
Description: Binary data

[perl #53450] [PATCH] for file "parrot.spec"

[via RT]

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


Hello,

the command "rpmbuild -ba parrot.spec" did only work after I changed the
file "parrot.spec" to hold a new line.

The attached file "parrot.spec.patch" holds the output from the command:
> diff -u parrot.spec parrot.spec.new > parrot.spec.patch

After that change I produced rpms (make rpms) for the parrot version
0.6.1 under the operating-systems:
Fedora 7, Fedora 8 and Fedora 9-Beta 

The rpms "libicu-devel" and "perl-SVK" are not needed to build parrot.
So the following two lines should be removed or commented out:
BuildRequires:  libicu-devel
BuildRequires:  perl-SVK


Gerd Pokorra

--- parrot.spec	2008-04-25 14:43:07.0 +0200
+++ parrot.spec.new	2008-04-28 13:03:43.0 +0200
@@ -81,7 +81,8 @@
 rm -rf $RPM_BUILD_ROOT%{_usr}/compilers \
 $RPM_BUILD_ROOT%{_usr}/config \
 $RPM_BUILD_ROOT%{_includedir}/src \
-$RPM_BUILD_ROOT%{_usr}/src
+$RPM_BUILD_ROOT%{_usr}/src \
+$RPM_BUILD_ROOT%{_usr}/tools
 
 %check
 export LD_LIBRARY_PATH=$( pwd )/blib/lib

Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)

[Daniel Ruoso]

Seg, 2008-04-28 às 10:15 -0700, Jon Lang escreveu:
> Ah; that clears things up considerably.  If I understand you
> correctly, John is using '£' to mean "use Duck Typing here".  _That_,
> I can definitely see uses for.

hrmm... I might just be overlooking something... but...

sub foo (Point $p) {...}

means...

$signature ~~ $capture

means...

Point $p := $capture[0]

means...

$capture[0] ~~ Point

means...

$capture[0].^does(Point)

which is implementation specific, but as for what it's worth, might be
abasolutely anything that says true to that call, even if it's just a
reference to a pointer in a low-level binding of some library...

The point I'm trying to make is that Perl 6 already accepts anything
that "does" Point, even if it "isn't" a Point, that happens basically
because Perl 6 have polymorphic representation.

That actually means that you *never* can count on knowing how the
object is implemented (except for native types, of course). So there's
actually no need for the "like" idiom, because there's no "true isa" in
Perl 6.

In Perl 6 one object "isa" something as long as it says true to "isa"
something. The only exceptions are the native types, see
http://www.perlfoundation.org/perl6/index.cgi?smop_native_types for a
little longer reasoning on that.

daniel

Re: [perl #53210] [TODO] change new_from_string to init_str

[chromatic]

On Tuesday 22 April 2008 10:05:57 Allison Randal wrote:

> We've been kicking around the idea of removing new_from_string for a
> while, but the pushback is always that it's useful to be able to create
> a new PMC with some initialization data, without first creating a PMC
> initializer that has to be garbage collected. So, instead of removing it
> entirely, make it a standard initialization option, passing a string
> argument instead of a PMC argument.

A C string or a STRING string?

(The latter are STRING initializers which have to be garbage collected.)

> Note, this will require changes to the "new" opcode, and to the
> low-level initialization functions ("pmc_new", etc). But, at least it'll
> be consistent, instead of a lone crack-headed different way of
> instantiating PMCs.

Crack removal ++;

Is one of the changes to the new opcode adding a _s variant?  Is one of the 
changes to pmc_new adding an optional parameter, or a new pmc_new_some_suffix 
version?

-- c

Re: [perl #53356] Misc. build warnings

[Andy_Bach]

On 26 April 2008 chromatic wrote:
> src/key.c:306: warning: switch missing default case

Fixed in 27195.


Just a query, wouldn't:
Index: src/key.c
===
--- src/key.c   (revision 27216)
+++ src/key.c   (working copy)
@@ -329,12 +329,14 @@
 }
 case KEY_start_slice_FLAG:
 case KEY_inf_slice_FLAG:
+{
+return VTABLE_get_integer(interp, key);
+}
 default:
-break;
+return VTABLE_get_integer(interp, key);
 }
 }

-return VTABLE_get_integer(interp, key);
 }


be a little better?  When I was trying to figure this out before (perl 
#52710 - which can be closed now), I was hung up on why there were KEY_* 
values being passed in that didn't have KEY_flags values. I was trying to 
match the usage of default in:
key_number(PARROT_INTERP, ARGIN(PMC *key))
{
switch (PObj_get_FLAGS(key) & KEY_type_FLAGS) {

   default:
real_exception(interp, NULL, INVALID_OPERATION, "Key not a 
number!\n");
}


At least by leaving it a separate section, not combined w/ 
start_slice|inf_slice, if it turns out that there's a 'missing' flag or 
something. It'll be more obvious??? In any case, the final
  return VTABLE_get_integer(interp, key);

shouldn't be needed, right?

a
---
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
Voice: (608) 261-5738 Fax: 264-5932

"When angry, count to four; when very angry, swear."
Mark Twain

Re: [perl #53352] [PATCH] Build warnings in STRUCT_COPY

[NotFound]

On Mon, Apr 28, 2008 at 10:05 PM, chromatic <[EMAIL PROTECTED]> wrote:

>  I renamed it to STRUCT_COPY_FROM_STRUCT (but that's only a little better than
>  your version) and applied it as r27222.

Thanks, but in 27222 looks like only include/parrot/parrot.h reflects
the changes, not the files in src/encodings. There is some problem
with that part?

-- 
Salu2

Re: [perl #53352] [PATCH] Build warnings in STRUCT_COPY

[NotFound]

The attached patch redoes the changes in these files with the new name.

-- 
Salu2
Index: src/encodings/utf16.c
===
--- src/encodings/utf16.c	(revisión: 27222)
+++ src/encodings/utf16.c	(copia de trabajo)
@@ -708,7 +708,7 @@
 bytes,
 iter_init
 };
-STRUCT_COPY(return_encoding, &base_encoding);
+STRUCT_COPY_FROM_STRUCT(return_encoding, base_encoding);
 Parrot_register_encoding(interp, "utf16", return_encoding);
 return return_encoding;
 }
Index: src/encodings/fixed_8.c
===
--- src/encodings/fixed_8.c	(revisión: 27222)
+++ src/encodings/fixed_8.c	(copia de trabajo)
@@ -555,7 +555,7 @@
 iter_init
 
 };
-STRUCT_COPY(return_encoding, &base_encoding);
+STRUCT_COPY_FROM_STRUCT(return_encoding, base_encoding);
 Parrot_register_encoding(interp, "fixed_8", return_encoding);
 return return_encoding;
 }
Index: src/encodings/utf8.c
===
--- src/encodings/utf8.c	(revisión: 27222)
+++ src/encodings/utf8.c	(copia de trabajo)
@@ -895,7 +895,7 @@
 bytes,
 iter_init
 };
-STRUCT_COPY(return_encoding, &base_encoding);
+STRUCT_COPY_FROM_STRUCT(return_encoding, base_encoding);
 Parrot_register_encoding(interp, "utf8", return_encoding);
 return return_encoding;
 }
Index: src/encodings/ucs2.c
===
--- src/encodings/ucs2.c	(revisión: 27222)
+++ src/encodings/ucs2.c	(copia de trabajo)
@@ -575,7 +575,7 @@
 bytes,
 iter_init
 };
-STRUCT_COPY(return_encoding, &base_encoding);
+STRUCT_COPY_FROM_STRUCT(return_encoding, base_encoding);
 Parrot_register_encoding(interp, "ucs2", return_encoding);
 return return_encoding;
 }

Re: First look: Advanced Polymorphism whitepaper

[John M. Dlugosz]

Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:

John M. Dlugosz wrote:
  

 I think I see another whitepaper in my immediate future.



I look forward to it.

  
I'll put a link to it on , perhaps even 
before I'm finished with it.


--John

Re: [perl #53422] [BUG] pdump crash on intel macosx

[Laimonas Vėbra]

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


This is #53422:
http://rt.perl.org/rt3/Ticket/Display.html?id=51262

[perl #53452] [BUG] ar can't read libparrot.a on Mac OS 10.5.2

[via RT]

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


I've just upgraded my laptop to Mac OS 10.5.2 (from 10.4). I'm using 
Apple's build of gcc, 4.0.1.

Since the upgrade, when I change a core PMC (even just adding a comment) 
and then try to run 'make' or 'perl Configure.pl && make' on a checkout 
that's been built before, I get an error when I hit this stage of the 
compile:
---
perl -MExtUtils::Command -e mkpath blib/lib
ar cr blib/lib/libparrot.a  src/string.o src/ops/core_ops.o [...]
---

The error is:
---
ar: blib/lib/libparrot.a is a fat file (use libtool(1) or lipo(1) and 
ar(1) on it)
ar: blib/lib/libparrot.a: Inappropriate file type or format
make: *** [blib/lib/libparrot.a] Error 1
---

If I run 'make realclean' then libparrot.a and several other related 
files are deleted, and I can build again.

Also relevant, when I run a fresh 'make' after 'realclean', ranlib warns:
---
ranlib: archive library: blib/lib/libparrot.a will be fat and ar(1) will 
not be able to operate on it
---

That part of the Makefile is generated from the following two lines in 
config/gen/makefiles/root.in:

Part of "BUILD TOOLS CONFIGURATIONS":
---
AR_CR= @ar@ @ar_flags@
---

And part of the "$(LIBPARROT_STATIC)" target:
---
   $(AR_CR) @[EMAIL PROTECTED]@ @ar_extra@ $(O_FILES)
---

Partial solution -- based on the documentation in 'man libtool':
---
Libtool with -static is intended to replace ar(5) and ranlib.
---

I modified config/gen/makefiles/root.in, changing:
---
$(LIBPARROT_STATIC) : $(O_FILES)
 $(MKPATH) @blib_dir@
 $(AR_CR) @[EMAIL PROTECTED]@ @ar_extra@ $(O_FILES)
 $(RANLIB) $@
---

to:
---
$(LIBPARROT_STATIC) : $(O_FILES)
 $(MKPATH) @blib_dir@
 libtool -static -o @[EMAIL PROTECTED]@ @ar_extra@ $(O_FILES)
---

And it compiles fine, passes 'make test', and recompiles fine after 
modifying a core PMC. But, I suspect this is a modification local to 
Apple's GCC, so what works here won't work anywhere else. I need a way 
to alter the "LIBPARROT_STATIC" target from config/init/hints/darwin.pm 
so it uses 'libtool -static' instead of 'ar' and 'ranlib'.

That's as far as I had time to work on it today, so I'll raise the 
question to the group (especially to those who have been working on the 
configure and build systems): What's the best way to allow these more 
extensive modifications to the build instructions for particular 
platforms/compilers?

Allison

Re: [perl #53422] [BUG] pdump crash on intel macosx

[Mark Glines]

On Mon, 28 Apr 2008 21:35:03 +0300
Laimonas Vėbra <[EMAIL PROTECTED]> wrote:

> Stephane Payrard wrote:
> > # New Ticket Created by  Stephane Payrard 
> > # Please include the string:  [perl #53422]
> > # in the subject line of all future correspondence about this
> > issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=53422 >
> 
> This is #53422:
> http://rt.perl.org/rt3/Ticket/Display.html?id=51262

You're right.  Tickets merged, thanks.

Mark

Re: [perl #53356] Misc. build warnings

[Andy_Bach]

chromatic wrote
> What if the PMC passed in isn't a Key PMC, but has an integer value?

Ah (sound of scales falling from my eyes) - the reason for the 
test/switch:
  if (VTABLE_isa(interp, key, CONST_STRING(interp, "Key"))) {
switch (PObj_get_FLAGS(key) & KEY_type_FLAGS) {
...

is to handle cases where the "key" needs special handling. But 
non-KEY_flag values (non-KEY pmcs?) passed to key_integer are *not* a 
problem.

"never mind"

a
---
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
Voice: (608) 261-5738 Fax: 264-5932

"When angry, count to four; when very angry, swear."
Mark Twain

Re: [perl #53352] [PATCH] Build warnings in STRUCT_COPY

[chromatic]

On Monday 28 April 2008 14:00:28 NotFound wrote:

> The attached patch redoes the changes in these files with the new name.

Thanks!  Applied in r27223.

-- c

Re: [perl #53450] [PATCH] for file "parrot.spec"

[chromatic]

On Monday 28 April 2008 09:06:15 [EMAIL PROTECTED] wrote:

> the command "rpmbuild -ba parrot.spec" did only work after I changed the
> file "parrot.spec" to hold a new line.
>
> The attached file "parrot.spec.patch" holds the output from the command:
> > diff -u parrot.spec parrot.spec.new > parrot.spec.patch
>
> After that change I produced rpms (make rpms) for the parrot version
> 0.6.1 under the operating-systems:
> Fedora 7, Fedora 8 and Fedora 9-Beta
>
> The rpms "libicu-devel" and "perl-SVK" are not needed to build parrot.
> So the following two lines should be removed or commented out:
> BuildRequires:  libicu-devel
> BuildRequires:  perl-SVK

I want to keep the ICU, because we're likely going to need it, but SVK isn't 
necessary.

Thanks, applied as r27224.

-- c

[perl #53452] [BUG] ar can't read libparrot.a on Mac OS 10.5.2

[James Keenan via RT]

On Mon Apr 28 09:07:06 2008, [EMAIL PROTECTED] wrote:
> I've just upgraded my laptop to Mac OS 10.5.2 (from 10.4). I'm using 
> Apple's build of gcc, 4.0.1.
> 
> Since the upgrade, when I change a core PMC (even just adding a comment) 
> and then try to run 'make' or 'perl Configure.pl && make' on a checkout 
> that's been built before, I get an error when I hit this stage of the 
> compile:
> ---
> perl -MExtUtils::Command -e mkpath blib/lib
> ar cr blib/lib/libparrot.a  src/string.o src/ops/core_ops.o [...]
> ---
> 
> The error is:
> ---
> ar: blib/lib/libparrot.a is a fat file (use libtool(1) or lipo(1) and 
> ar(1) on it)
> ar: blib/lib/libparrot.a: Inappropriate file type or format
> make: *** [blib/lib/libparrot.a] Error 1
> ---
> 

Whenever I hear of Mac OS X upgrades and that 'lipo' term, I think of
the issues Seneca Cunningham has raised here:

http://rt.perl.org/rt3/Ticket/Display.html?id=52214

Could there be a connection?

kid51

[perl #52904] [TODO]: Mac OS X 10.5: Resolve compilation and build issues

[James Keenan via RT]

Adding one more ticket to the list:

http://rt.perl.org/rt3/Ticket/Display.html?id=53452

Concurrency Branch Exception PMC

[chromatic]

I'm working on the concurrency branch, and specifically the Exception PMC.  
Here's a patch that does what I think it needs I'll run more tests and 
see if Parrot still works.

-- c

Index: src/pmc/exception.pmc
===
--- src/pmc/exception.pmc	(revision 27224)
+++ src/pmc/exception.pmc	(working copy)
@@ -10,32 +10,23 @@
 
 This is the exception base class.
 
-For now, this class is based on C. This will change when the
-full PMC PDD is implemented.
-
 An exception object has these attributes:
 
 =over 4
 
-=item 0 C<_message>
+=item C
 
 Textual representation of the exception.
 
-=item 1 C<_type>
+=item C
 
-The exception type, (see F, F).
-
-=item 2 C<_severity>
-
-The severity of the exception, (see F,
+The severity of the exception, (see F,
 F).
 
-=item 3 C
+=item C
 
 Additional data for the exception.
 
-=item 4 C
-
 =back
 
 Optional:
@@ -64,9 +55,6 @@
 underscore (that is reserved for Parrot's internal usage. These are
 stored as properties.
 
-Note: currently, HLL information must be indexed by number. Slots 9 and 10
-are available for the HLL - This is subject to change.
-
 =back
 
 When an exception handler is called, the exception object is passed as
@@ -79,26 +67,6 @@
 
 #include "parrot/parrot.h"
 
-/* This finds the index of an attribute in an object's attribute store and
- * returns it. Returns -1 if the attribute does not exist. */
-static INTVAL
-get_attrib_index(PARROT_INTERP, PMC *self, STRING *name)
-{
-if (!string_compare(interp, name, CONST_STRING(interp, "message")))
-return 0;
-
-if (!string_compare(interp, name, CONST_STRING(interp, "type")))
-return 1;
-
-if (!string_compare(interp, name, CONST_STRING(interp, "severity")))
-return 2;
-
-if (!string_compare(interp, name, CONST_STRING(interp, "payload")))
-return 3;
-
-return -1;
-}
-
 /*
 
 =head2 Methods
@@ -110,6 +78,9 @@
 */
 
 pmclass Exception extends ResizablePMCArray need_ext {
+ATTR STRING *message;
+ATTR PMC*payload;
+ATTR INTVAL  severity;
 
 /*
 
@@ -122,13 +93,39 @@
 */
 
 VTABLE void init() {
-SUPER();
-/* pre-fill 11 slots with PMCNULL */
-SELF.set_integer_native(11);
+Parrot_Exception * const exception =
+mem_allocate_zeroed_typed(Parrot_Exception);
+
+PObj_custom_mark_SET(SELF);
+PObj_active_destroy_SET(SELF);
+
+PMC_data(SELF)  = exception;
+exception->message  = CONST_STRING(interp, "");
+exception->severity = 0;
+exception->payload  = PMCNULL;
 }
 
 /*
 
+=item C
+
+Mark any active exception data as live.
+
+=cut
+
+*/
+
+VTABLE void mark() {
+Parrot_Exception * const exception = PARROT_EXCEPTION(SELF);
+
+if (exception->message)
+pobject_lives(interp, (PObj *)exception->message);
+if (exception->payload)
+pobject_lives(interp, (PObj *)exception->payload);
+}
+
+/*
+
 =item C
 
 Returns the Parrot string value for C<*key>. The only current recognized
@@ -145,14 +142,17 @@
 VTABLE STRING *get_string_keyed(PMC *key) {
 STRING *s = key_string(INTERP, key);
 
-if (!string_compare(INTERP, s, CONST_STRING(INTERP, "_message")))
-return SELF.get_string_keyed_int(0);
+if (!string_compare(INTERP, s, CONST_STRING(INTERP, "_message"))) {
+Parrot_Exception * const exception = PARROT_EXCEPTION(SELF);
+return exception->message;
+}
 
-return 0;
+return CONST_STRING(interp, "");
 }
 
 VTABLE STRING *get_string() {
-return SELF.get_string_keyed_int(0);
+Parrot_Exception * const exception = PARROT_EXCEPTION(SELF);
+return exception->message;
 }
 
 /*
@@ -168,12 +168,11 @@
 VTABLE INTVAL get_integer_keyed(PMC *key) {
 STRING *s = key_string(INTERP, key);
 
-if (!string_compare(INTERP, s, CONST_STRING(INTERP, "_type")))
-return SELF.get_integer_keyed_int(1);
+if (!string_compare(INTERP, s, CONST_STRING(INTERP, "_severity"))) {
+Parrot_Exception * const exception = PARROT_EXCEPTION(SELF);
+return exception->severity;
+}
 
-if (!string_compare(INTERP, s, CONST_STRING(INTERP, "_severity")))
-return SELF.get_integer_keyed_int(2);
-
 return 0;
 }
 
@@ -194,24 +193,6 @@
 
 /*
 
-=item C
-
-Returns the PMC value of the element at index C, but ignores too
-big negative keys.
-
-=cut
-
-*/
-
-VTABLE PMC *get_pmc_keyed_int(INTVAL key) {
-if (key <= -PMC_int_val(SELF))
-return PMCNULL;
-
-return SUPER(key);
-}
-
-/*
-
 =item C
 
 Sets the Parrot string value for C<*key>.
@@ -223,8 +204,10 @@
 VTABLE void set_string_keyed(PMC *key, STRING *value) {
 STRING *s = key_string(INTERP, key);
 
-if (!string_compare(INTERP, s, CONST_STRING(INTE

[perl #53270] [TODO] Rename/refactor _handle_mswin32()

[James Keenan via RT]

Having heard no objections, I've applied the patch, incorporating
suggestions from Geoffrey Broadwell, in r27226.

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

[via RT]

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


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