Re: Anonymous Named params (Was Revision of A12's lookahead notions)

[Larry Wall]

On Sat, Aug 14, 2004 at 12:32:30AM -0400, Joe Gottman wrote:
:Doesn't the concept of an anonymous named param (in the fourth and fifth
: examples above) seem like an oxymoron?  If it's anonymous it can't have a
: name (or at least we can't know its name).

It's anonymous only in the sense that the caller doesn't know that
callee's declared name for the slurpy function, just as when you say

push @foo <== 1,2,3

the caller doesn't know what push calls its slurpy list.

: More importantly, what is an anonymous named param used for?  

It's for passing a closure argument without having to put parens
around it.  I think that's about all it's good for.  Though arguably
it'd be nice to allow a slurpy scalar that lets the PDL folks
write something like

[1..10:(3)]

to mean

[1..10:by(3)]

Except then they'll want to write

[1..10:3]

and then they'll get completely confused when

[1..10:int($y)]

doesn't work.  So maybe we force them to say "by".

:Also, suppose I have a hash 
:   %foo = {'by' => 1, 'from' => 2}; 
: Would 
:   splurt :%foo;
: have the same result as
:   splurt :by(1) :from(2); 
: 
: or would I need the braces in this case?

Hmm, I don't know where to begin.  First, the braces are really
only intended for anonymous closures, not anonymous hashes.  (Though
an argument could be made to allow that usage, which presumably
would map all the internal hash keys to parameter values.)

Next, colon is not a prefix operator, so you can't just put it
in front of %foo like that.  Even if you allow for a "null" name,
we don't have adverbs that look like :abc%foo, so :%foo doesn't make
any sense.  Plus you're passing it where a term is expected, so it's
not an adverb in any case unless you said

splurt() :%foo

or some such.  But if you're gonna pass it where a term is expected,
it's just a list of pairs, and you could say

splurt %foo.pairs

or maybe even just

splurt %foo

presuming the signature of splurt won't confuse that for a scalar
argument.  You can do tricks like that because normal argument
processing is pretty sophisticated.  Adverbs, on the other hand,
are intended only for introducing single pairs, and extending the
syntax for them indefinitely would be a mistake of the same sort as
allowing people to nest statement modifiers.  If you want to get
fancy with named parameters, put 'em in the argument list where
they belong.

That being said, I still wonder whether there ought to be a way
of pattern matching single hash arguments like we do single array
arguments.  That is, we already have things like:

sub headtail ([$head, [EMAIL PROTECTED], $num) {...}

which will pattern match a call like

headtail(@array, 1)

so maybe there's some call for

sub headstails ({+$heads, +$tails, *%edges}, $num) {...}

that will pattern match a call like

headstails(%hash, 1);

On the other hand, we don't have a way to name such a parameter
in either the [] or {} case yet, so it's hard enough to relate
it to named parameters, let alone anonymous named parameters...

Larry

Anonymous Named params (Was Revision of A12's lookahead notions)

[Joe Gottman]

> -Original Message-
>   1d) Additional arguments may occur as adverbs *only* if there
>   are explicit parens.  (Or in the absence of parens they may
>   parse as arguments when a term is expected--but then they're
>   not adverbs, just named arguments...)
> 
>   splurt():by{ +$_ }  # okay
>   splurt 1,2,3 :by{ +$_ } # ILLEGAL (comma rejects the adverb)
>   splurt 1,2,3 :{ +$_ }   # ILLEGAL (comma rejects the adverb)
>   splurt 1,2,3,:{ +$_ }   # likely okay (as anonymous named
> param)
>   splurt :{ +$_ } # likely okay (as anonymous named
> param)
>   splurt { +$_ }  # okay (positional param)
>   splurt 1,2,3, { +$_ }   # okay (positional param)
> 


   Doesn't the concept of an anonymous named param (in the fourth and fifth
examples above) seem like an oxymoron?  If it's anonymous it can't have a
name (or at least we can't know its name).  More importantly, what is an
anonymous named param used for?  

   Also, suppose I have a hash 
%foo = {'by' => 1, 'from' => 2}; 
Would 
splurt :%foo;
have the same result as
splurt :by(1) :from(2); 

or would I need the braces in this case?


Joe Gottman

Questions about Exceptions & Re: What Unicode means to us

[Michael Stone]

Larry Wall wrote:
On Wed, Aug 11, 2004 at 04:16:48PM -0400, Dan Sugalski wrote:
: If it's that handy then someone can write a library routine. This 
: feels very much to be in the same category as running a 
: speech-to-text algorithm if you send WAV data to a text filehandle.

Well, you can write a library routine, but if you have to invoke it
in a separate pass it's not as efficient.
: Not going to happen. Charset conversion mismatches either throw an 
: exception or falls back to a default bogus character.

Seems to me that a reasonable compromise is merely to provide a way
to hook in a user-defined callback and leave it at that.  Then the
user can have whatever policy they like, and Dan doesn't have to
implement it.
Larry
From - Fri
 

It strikes me that many of the same issues that I just raised (or tried 
to raise, anyway) to try to clarify what I was saying to Brent apply 
equally well here, to the suggestion of user-defined callbacks.  
Specifically, what happens if you want to have more than one of them?  I 
suspect I'm missing something fundamental, because I'm very new to all 
of this, so if you can point it out, I'd be much obliged.  Specifically, 
I can easily understand how to solve this kind of problem if we were 
working at the level where the MMD infrastructure was available, but 
since Dan tells me that that is above all of this... well, basically, 
how does it work?  Is the situation where you have two vendors who both 
want to install call-backs for the same thing simply a "I'm sorry, but 
we don't support that" situation?

However, before referencing that post, I have to ask a few questions to 
try to deal with the current inadequacy of my understanding of Parrot 
exception handling:

I have a basic idea of how exceptions work at the level of 
continuations, inside of the Parrot machine, but can someone please 
explain how they work (or tell me where to read) at the level of the 
Parrot C runtime? 

Furthermore, how are we addressing (if at all) Aaron's point about 
languages which don't have the most impressive exception handling in the 
world?

Finally, (and I'm just thinking about charset stuff here), exceptions 
frequently involve a bit of string processing.  So if the 
charset/encoding code starts throwing exceptions, how do we write the 
string processing that those exceptions do so that further exceptions 
aren't thrown?  Is Parrot like C++ where if an exception handler 
generates a second exception, the runtime immediately calls abort()?  If 
not, how do we handle this situation, or another one like it?

Does this relate at all to the 
continuations-don't-cross-the-C/Parrot-interface rule?

Thanks for any help or pointers that you can give on this topic,
Michael

Re: Functions for embedders to override

[Michael Stone]

On Tue, Aug 10, 2004 at 10:45:43AM -0700, Brent 'Dax' Royal-Gordon wrote:
: I would assume (hope) that these tables would not be allowed to change
: once Parrot started using them.  It seems like an extremely dangerous
: thing to have two calls to read() be performed by different functions,
: after all.
 

Why is it any more dangerous than allowing a function like read() to 
read from sockets, strings, memory, file handles, special devices, or 
anything else the user can dream up than can support the read() interface?

Furthermore, look at the benefits in terms of the ease with which it 
becomes possible to transparently install debugging hooks and logging 
and security handlers (among many other types) in legacy code that is 
retargeted to the Parrot VM.
The way that I got involved in this thread was actually because of some 
language in Dan's 8/4/2004-11:23 AM email "Re: Unicode Support - ICU 
Optional" in which the statement "3) We make Parrot's string system use 
the loadable encoding and charset system " got me thinking about the 
loadability-of-low-level-functions issue. 

As a question for my own understanding, how low-level is the encoding 
API supposed to be?  Is it at the same level as read(), malloc(), and 
friends?  In one of Dan's more recent emails, he hit the nail on the 
head when he said: "The issue here is whether we let the interpreter 
swap out what's the equivalent of functions in the C runtime."  Are the 
charset and encoding APIs at the level of the C runtime?  I was under 
the impression that they were, since the C runtime spends a lot of time 
dealing with strings and with string encoding.

If that's so, and if as, according to the first quote, the encoding and 
charset system needs to be loadable, I merely asked if we were planning 
on making a general framework (i.e. macros, or pre-processor magic) to 
support this kind of ability to store multiple versions of low-level 
implemented-in-C functions. 

There were two motivations for this question.  One issue was "how are we 
actually going to do the loading and the function resolution" which, I 
feel, still needs to be addressed.  (If I just missed the explanation, 
since I joined the list relatively recently, could someone send me a link?)

The second was if we've got a table with one function pointer in it, why 
not make it easy to chain functions together so that we can get the 
benefits of AOP-like functionality not only for operations done at C 
compile-time but for operations at any time. 

Here's what I was thinking: given that we're using a table of function 
pointers, its easy enough when compiling Parrot to substitute a 
chain-of-functions for any of the low-level calls in the table.  
However, since this is done at compile time, it's very difficult to add 
and remove options, or, if you're in a multi-vendor environment, it 
might be very, very hard to make code (that you don't have the source 
for) behave properly with this kind of solution.  (You run into a 
similar kind of problem in C++ with multiple inheritance that policy 
classes and template metaprogramming give you a nice way to solve.  But 
anyway:)

So it's easy, under ideal circumstances, to make special parrot builds 
that do what I'm talking about, if we're using these tables of function 
pointers for low-level things, as is implied by the demand to have 
loadable charset/encoding abilities, even if we don't do it with 
explicit chains of functions, but just by writing our own chain in a 
single function, compiling it, and stuffing its address in the table slot. 

However, Parrot is about being able to do lots of cool stuff at runtime 
without sacrificing speed, right?  Furthermore, it wants to do this in a 
really portable way.  It seemed to me that there might well be lots of 
situations where it would be great to have this ability to chain 
handlers for these functions but where recompiling parrot to support it 
was probably not possible, or as I point out with the situation where 
multiple vendors want to install hooks, where things get downright nasty 
at compile-time but are fine at runtime. 

So the second issue that I'm asking is "if we're going to have function 
tables for all of this low-level stuff, can we at least chain things at 
runtime AS WELL as at compile time, since compile time is obviously made 
possible simply by the fact that we're using function tables but runtime 
would (it seems to me) solve a number of other 
things-that-people-will-surely-want-to-do."  This question is orthogonal 
from an implementation perspective to the question of which parts of the 
"C runtime", whatever that includes, will be accessed through function 
tables.  My point was that if we're going to use function tables for 
anything this low-level, let's build it the right way and get this 
really cool feature out of it.

Also, to reiterate a point, while I'm afraid that I'm not terribly 
familiar with Perl's .wrap/.unwrap functions, as Dan suggests, the real 
is

Re: [perl #31026] Fix generation of src/nci.c to be more efficient

[chromatic]

Oh yeah, the goal of this exercise was to cache the hash, not build it
every time.  Here's a version which does that and passes the tests with
GC_DEBUG.  It still complains about passing constant C-strings to
hash_put(), but that's a different story.

-- c


Index: include/parrot/interpreter.h
===
RCS file: /cvs/public/parrot/include/parrot/interpreter.h,v
retrieving revision 1.149
diff -u -u -r1.149 interpreter.h
--- include/parrot/interpreter.h	26 Jul 2004 07:34:33 -	1.149
+++ include/parrot/interpreter.h	13 Aug 2004 22:13:36 -
@@ -267,6 +267,7 @@
 IGLOBALS_INTERPRETER,
 IGLOBALS_DYN_LIBS,
 IGLOBALS_RUNTIME_LIBRARY,
+IGLOBALS_NCI_FUNCS,
 
 IGLOBALS_SIZE
 } iglobals_enum;
Index: build_tools/build_nativecall.pl
===
RCS file: /cvs/public/parrot/build_tools/build_nativecall.pl,v
retrieving revision 1.49
diff -u -u -r1.49 build_nativecall.pl
--- build_tools/build_nativecall.pl	9 Aug 2004 21:20:12 -	1.49
+++ build_tools/build_nativecall.pl	14 Aug 2004 01:59:44 -
@@ -175,6 +175,7 @@
  *  References:
  */
 #include "parrot/parrot.h"
+#include "parrot/hash.h"
 
 /*
  * if the architecture can build some or all of these signatures
@@ -245,10 +246,15 @@
 build_call_func(Interp *interpreter, PMC *pmc_nci,
 STRING *signature)
 {
-STRING *ns;
-STRING *message;
-char   *c;
-void   *result = NULL;
+char   *c;
+STRING *ns, *message;
+HashBucket *b;
+PMC*iglobals;
+
+void   *result= NULL;
+Hash   *known_frames  = NULL;
+PMC*HashPointer   = NULL;
+
 #if defined(CAN_BUILD_CALL_FRAMES)
 
 /* Try if JIT code can build that signature,
@@ -260,12 +266,41 @@
 #endif
 if (result)
 return result;
+
 /* And in here is the platform-independent way. Which is to say
"here there be hacks" */
 UNUSED(pmc_nci);
 if (0 == string_length(interpreter, signature)) return F2DPTR(pcf_v_v);
-$icky_global_bit
 
+iglobals = interpreter->iglobals;
+
+if (iglobals)
+HashPointer = VTABLE_get_pmc_keyed_int(interpreter, iglobals,
+IGLOBALS_NCI_FUNCS);
+
+if (HashPointer)
+known_frames = PMC_struct_val(HashPointer);
+
+if (known_frames == NULL)
+{
+new_cstring_hash( interpreter, &known_frames );
+
+$icky_global_bit
+
+if (iglobals)
+{
+HashPointer = pmc_new(interpreter, enum_class_Pointer);
+VTABLE_set_pmc_keyed_int(interpreter, iglobals, IGLOBALS_NCI_FUNCS,
+HashPointer);
+PMC_struct_val(HashPointer) = known_frames;
+}
+}
+
+b = hash_get_bucket(interpreter, known_frames,
+string_to_cstring(interpreter, signature));
+
+if (b)
+return F2DPTR( b->value );
 
 /*
   These three lines have been added to aid debugging. I want to be able to
@@ -437,21 +472,12 @@
 HEADER
   }
 
-  if (defined $params) {
-  push @icky_global_variable, <

Re: What Unicode means to us

[Michael Stone]

Aaron,
  I happen to agree with Dan about the unwieldiness of replacing 
characters with their full names during character translation, but your 
idea of using Unicode equivalents seems more palatable.  I'm going to 
ignore the issue of how this method of handling errors fits into the 
scheme of possible error-handling methods, for the moment, because I 
want to talk about that in a separate email.  Having said that, I have a 
few specific questions about some of your design choices.  It's late and 
I'm tired, so I'm probably a bit incoherent.  If you have trouble 
understanding me, let me know and I'll try to clarify.  So, first:

How are you going to choose between different canonical compositions and 
compatability compositions when such a choice has to be made?  For 
example, when encoding combining characters, vertically oriented text, 
or Korean jamo vs. syllables, how will you pick between the four 
different normalization forms?

If a transparent conversion is required to get a string into Unicode 
before transforming out of it, do we print the source character or its 
Unicode equivalent if an error occurs?

Michael

Re: Revision of A12's lookahead notions

[Larry Wall]

On Fri, Aug 13, 2004 at 09:19:29PM -0400, Uri Guttman wrote:
: i have no issue with splurt() being needed to disambiguate. i just
: wanted to see your take (this week :) on it as i felt the table was
: ambiguous so far. as far as making it a warning, wouldn't that make the
: warning space sensitive? :-/

There are some of those in Perl 5 already.

Larry

Re: Handling block parameters in Ruby

[Larry Wall]

On Fri, Aug 13, 2004 at 08:41:35PM -0400, Matt Diephouse wrote:
: > You know, at some point you just break down and write them positionally:
: > 
: > @array.each( { $^odd.bar() }, { $^even.baz() });
: 
: Speaking of which, let's talk a little bit about how I'd write these
: methods. After looking at Apocalypse, Exegesis, and Synopsis 6 again,
: I have a few more questions. There are two different ways used to
: declare a subroutine or method:
: 
:  sub foo (&block) {
:  &block('foo');
:  }

The second & is unnecessary there.  If you declare a &foo, you get foo() for free.

:  sub foo (Code $block) {
:  $block('foo');
:  }
: 
: Which is right? both? The second seems more extensible.

Either should work.  Scalars are always more general, since they can
hold anything.  But sometimes the point is to be less general...

: And that leads
: me to another question: can a slurpy array pick up a block?
: 
:  sub foo ([EMAIL PROTECTED]) {
:  say ref @args[0]; # @args[0].type?
:  }

Probably "typeof", actually, since "ref" is unclear, and "type" is
a keyword that prevents an indirect object syntax.  Though arguably
"type" should be "subtype" or "constrain" or some such, which would
free up "type" for a unary.

:  foo { $^a =~ /bar/ }; # does this print "Block\n"?

Maybe something more like "Code". Haven't revisited the
Code hierarchy in a while though.  But the signature type
is in angles (this week), since parens are taken for actual
arguments.

: It'd be nice to be able to declare my each method like so:
: 
: class Array {
: method each($self: [EMAIL PROTECTED]) {

Could go as far as to say Code [EMAIL PROTECTED], I expect.  And you can
probably get away with @self too.  (I also wouldn't call it "each",
since there's likely to be a built-in of that name, but I understand
you're just playing here...)

method roundrobin(@self: Code [EMAIL PROTECTED]) {

: my $i = 0;
: my @results;
: for @$self -> $elem {
: my $block = @blocks[ $i++ % [EMAIL PROTECTED] ];

The + is redundant there, though okay as documentation, which
I suppose is why you put it.

: @results.push( $block($elem) );

You can also write those two lines as:

my &block = @blocks[ $i++ % [EMAIL PROTECTED] ];
@results.push( block($elem) );

or as

@results.push( @blocks[ $i++ % [EMAIL PROTECTED] ]($elem) );

: }
: return @results;
: }
: }
: 
: But that still doesn't let me call that like I'd want;
: 
: my @r = @array.each :{ $^first * 2 }
: :{ $^second * 9 }
: :{ $^third * 42 };

Which would take some special dispensation like "Multiple anonymous
closures are pushed onto the slurp array if there's no slurp closure."

On the other hand, we've not really specified very well what happens
if you pass two named parameters of the same name, other than saying
the first one binds to the named parameter (if any) and the second
one ends up in the slurpy hash.  But what happens to the third one?
An argument could be made for creating a subarray in the hash when
there are multiples, in which case your multiple blocks would
come through as %hash{""}[].  But I hate it that you'd have to
treat a single argument differently.

Maybe there's some way to extend signature syntax similarly to what
we did for [$head, [EMAIL PROTECTED] arguments.  There seems to be some kind
of generic problem here with assuming named array arguments are always
passed as a reference to a single array rather than a list of arguments
with the same name.  I'd much prefer a general solution than a bandaid
just for blocks.

: The other thing I'm wondering is how to apply adverbs to the results
: of a function, if that's even possible. I believe this is valid:

Adverbs by definition modify verbs, not nouns.

:  my $odd = 1... :by(2) # an infinite list of odd numbers 

I suppose an adverb can apply itself directly to a postfix operator
like that, given that it still sets up the expectation for an
operator rather than a term.

: But this?
: 
:  sub odd_numbers([EMAIL PROTECTED] of Pair) {
:  return 1...;
:  }
:  my $odd = odd_numbers :by(2);
: 
: Does that pass C 2> as a Pair to the function?

Yes.  A term is expected, :by(2) is just a pair.

: Or does it apply the adverb to the result? Maybe I need to do this?
: 
:  my $odd = (odd_numbers) :by(2);
: 
: My head is swimming at this point, so I'd better give it a rest.

That would apply the adverb to the =, which would make anyone's
head swim, especially anyone trying to figure out how to implement
assignment "by 2".

Larry

Re: Revision of A12's lookahead notions

[Uri Guttman]

> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:

  LW> On Fri, Aug 13, 2004 at 07:05:28PM -0400, Uri Guttman wrote:
  LW> :   LW> : splurt + 1  # same??
  LW> :   LW> : splurt +1   # work on +1??
  LW> : 
  LW> : so how do the 2 above get parsed? the space between + and 1 looks alike
  LW> : a 0-ary splurt but the +1 could be 0-ary added to 1 or unary with +1 as
  LW> : its arg. this could mean a form of white space sensitivity.

  LW> That's the sort of whitespace dependency we're trying to avoid now.
  LW> So those both mean splurt(+1).  I suppose the first form could be
  LW> made to spit a warning since it's probably a mistake.  But it's no
  LW> worse than the situation in Perl 5 in that regard where you have to
  LW> write splurt() + 1 if that's what you mean.

i have no issue with splurt() being needed to disambiguate. i just
wanted to see your take (this week :) on it as i felt the table was
ambiguous so far. as far as making it a warning, wouldn't that make the
warning space sensitive? :-/

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

Re: Handling block parameters in Ruby

[Matt Diephouse]

On Fri, 13 Aug 2004 11:36:05 -0700, Larry Wall <[EMAIL PROTECTED]> wrote:
> Yes, that's precisely why I'm trying to generalize Ruby's single
> "magic" block into one or more ordinary parameters.

Excellent. :)

> Two anonymous adverbs?  Hmm.  While I can think of ways to force it to
> work, I'm inclined to disallow it simply because it'd make another
> arbitrary rule we'd have to explain.

And there's quite a bit to explain already.

> You know, at some point you just break down and write them positionally:
> 
> @array.each( { $^odd.bar() }, { $^even.baz() });

Speaking of which, let's talk a little bit about how I'd write these
methods. After looking at Apocalypse, Exegesis, and Synopsis 6 again,
I have a few more questions. There are two different ways used to
declare a subroutine or method:

 sub foo (&block) {
 &block('foo');
 }

and

 sub foo (Code $block) {
 $block('foo');
 }

Which is right? both? The second seems more extensible. And that leads
me to another question: can a slurpy array pick up a block?

 sub foo ([EMAIL PROTECTED]) {
 say ref @args[0]; # @args[0].type?
 }
 
 foo { $^a =~ /bar/ }; # does this print "Block\n"?

It'd be nice to be able to declare my each method like so:

class Array {
method each($self: [EMAIL PROTECTED]) {
my $i = 0;
my @results;
for @$self -> $elem {
my $block = @blocks[ $i++ % [EMAIL PROTECTED] ];
@results.push( $block($elem) );
}
return @results;
}
}

But that still doesn't let me call that like I'd want;

my @r = @array.each :{ $^first * 2 }
:{ $^second * 9 }
:{ $^third * 42 };

The other thing I'm wondering is how to apply adverbs to the results
of a function, if that's even possible. I believe this is valid:

 my $odd = 1... :by(2) # an infinite list of odd numbers 

But this?

 sub odd_numbers([EMAIL PROTECTED] of Pair) {
 return 1...;
 }
 my $odd = odd_numbers :by(2);

Does that pass C 2> as a Pair to the function? Or does it apply
the adverb to the result? Maybe I need to do this?

 my $odd = (odd_numbers) :by(2);

My head is swimming at this point, so I'd better give it a rest.

matt

> On the other hand, the parser will have to deal with multi-block
> structures all the time, so perhaps something could be modelled on
> how we eventually handle if/elsif/else, presuming we actually
> declare those as macros, and not strictly as grammar rules.
> 
> Larry

Re: Revision of A12's lookahead notions

[Larry Wall]

On Fri, Aug 13, 2004 at 07:05:28PM -0400, Uri Guttman wrote:
:   LW> :   splurt + 1  # same??
:   LW> :   splurt +1   # work on +1??
: 
: so how do the 2 above get parsed? the space between + and 1 looks alike
: a 0-ary splurt but the +1 could be 0-ary added to 1 or unary with +1 as
: its arg. this could mean a form of white space sensitivity.

That's the sort of whitespace dependency we're trying to avoid now.
So those both mean splurt(+1).  I suppose the first form could be
made to spit a warning since it's probably a mistake.  But it's no
worse than the situation in Perl 5 in that regard where you have to
write splurt() + 1 if that's what you mean.

Larry

Re: Revision of A12's lookahead notions

[Uri Guttman]

> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:

  LW> On Tue, Aug 10, 2004 at 06:10:17PM -0400, Uri Guttman wrote:
  LW> : can you have a 0- or 1-ary function? meaning like the many funcs that
  LW> : work on $_ with no args or the single arg you pass in. how do you
  LW> : declare it so it parses correctly?
  LW> : 
  LW> : splurt  # should work on $_
  LW> : splurt()# should work on $_
  LW> : splurt + 1  # same??
  LW> : splurt +1   # work on +1??

so how do the 2 above get parsed? the space between + and 1 looks alike
a 0-ary splurt but the +1 could be 0-ary added to 1 or unary with +1 as
its arg. this could mean a form of white space sensitivity.

  LW> : splurt( +1 )# definitely work on +1

  LW> And functions declared 0-ary explicitly parse as terms, while all 2-ary
  LW> and higher functions parse as list operators unless you use parens.
  LW> (All functions are considered to be list ops before declaration,
  LW> and if the declaration subsequently changes that fact, it's an error.
  LW> So 0-ary and 1-ary functions have to be predeclared if you want them
  LW> to parse as unaries.)

that all makes sense as all is fair if you predeclare and the default
parsing is well documented and understood.

  LW> I think this is all consistent and useful, but of course I could simply
  LW> be wrong, or more likely, wrongish.

depends on how you parse wrong! :)

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

Re: [perl #31026] Fix generation of src/nci.c to be more efficient

[chromatic]

On Fri, 2004-08-13 at 11:58, Leopold Toetsch wrote:

> When that's fixed (or hash's memory is malloced) then the keys have to 
> be declared with CONST_STRING() or - as these are C strings in the first 
> place, you create a custom hash with C-string keys. See the API in 
> hash.c:new_hash_x() or just new_cstring_hash()

I suspect CONST_STRING() would work better, but a C-string hash makes
for cleaner generated code.

*where to store the hash of functions*

> interpreter->iglobals e.g. where BTW the entry #3 "Env" is history and 
> unused ;)

Yeah, that was a tricky bit.  I kept seeing segfaults and uninitialized
interpreter->iglobals during the first call to build_call_func() until I
looked in init_world().  A couple of PMCs actually build NCI funcs
during initialize_core_pmcs().  There's an order of operations thing
here that someone besides me may want to sort out.

The resulting patch isn't yet perfect, but it's a fair stab closer and
works with GC_DEBUG enabled on my box.

It also throws a lot of "discards qualifiers from pointer type" warnings
due to hash_put() taking a void pointer and me passing in a constant
string, but that's beyond my ken to fix this afternoon.

-- c


Index: build_tools/build_nativecall.pl
===
RCS file: /cvs/public/parrot/build_tools/build_nativecall.pl,v
retrieving revision 1.49
diff -u -u -r1.49 build_nativecall.pl
--- build_tools/build_nativecall.pl	9 Aug 2004 21:20:12 -	1.49
+++ build_tools/build_nativecall.pl	13 Aug 2004 22:13:36 -
@@ -175,6 +175,7 @@
  *  References:
  */
 #include "parrot/parrot.h"
+#include "parrot/hash.h"
 
 /*
  * if the architecture can build some or all of these signatures
@@ -245,10 +246,14 @@
 build_call_func(Interp *interpreter, PMC *pmc_nci,
 STRING *signature)
 {
-STRING *ns;
-STRING *message;
-char   *c;
-void   *result = NULL;
+char   *c;
+STRING *ns, *message;
+void   *result = NULL;
+Hash   *known_frames;
+HashBucket *b;
+PMC*iglobals;
+PMC*HashPointer   = NULL;
+
 #if defined(CAN_BUILD_CALL_FRAMES)
 
 /* Try if JIT code can build that signature,
@@ -264,8 +269,29 @@
"here there be hacks" */
 UNUSED(pmc_nci);
 if (0 == string_length(interpreter, signature)) return F2DPTR(pcf_v_v);
-$icky_global_bit
 
+iglobals = interpreter->iglobals;
+
+if (iglobals)
+HashPointer = VTABLE_get_pmc_keyed_int(interpreter, iglobals,
+IGLOBALS_NCI_FUNCS);
+
+if (!HashPointer)
+{
+new_cstring_hash( interpreter, &known_frames );
+
+$icky_global_bit
+}
+else
+{
+known_frames = PMC_data( HashPointer );
+}
+
+b = hash_get_bucket(interpreter, known_frames,
+string_to_cstring(interpreter, signature));
+
+if (b)
+return F2DPTR( b->value );
 
 /*
   These three lines have been added to aid debugging. I want to be able to
@@ -437,21 +463,12 @@
 HEADER
   }
 
-  if (defined $params) {
-  push @icky_global_variable, <

Re: Handling block parameters in Ruby

[Brent 'Dax' Royal-Gordon]

On Fri, 13 Aug 2004 11:44:28 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Still, I think it might be worth dedicating a slot to it. It's a
> handy feature, and if we open it up to perl & python I'd bet we'd see
> them using it.

This makes we wonder if we shouldn't generalize the concept of these
slots somehow.

-- 
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker

There is no cabal.

Re: Something broke for me

[Michel Pelletier]

On Fri, 13 Aug 2004 16:40:12 -0400
Dan Sugalski <[EMAIL PROTECTED]> wrote:

> At 11:24 AM -0700 8/13/04, Michel Pelletier wrote:
> >I've been developing Parakeet on a month old Parrot build, so today I
> >decided to update to a recent checkout, and Parakeet broke two ways.
> >
> >The first is multi-inheritance stopped working, but that's not as big
> >a deal as the new problem.
> 
> Gack -- it's a very big deal, and the test suite should've picked 
> that up. D'you have a code snippet that demonstrates it, so we can 
> fix the problem and get a test to help keep it happening in the 
> future?

I should have been more clear, *Parakeet* multi-inheritance breaks, I
have no proof that Parrot's is broke, or it just changed out from under
me the way I'm using it.  I'll try to come up with a simple test case
tonight.  Here's where it breaks in Parakeet:

  class C 
extends A
meth testMethod 2 end
  end

  C new var c
  c -> testMethod println  # prints 2

  # another for multi-inheritance

  class X 
meth xciting "exciting!" end
  end

  # multi-inheritance

  class D
extends C 
extends X
  end

  D new var d
  d -> testMethod println
  d -> xciting println  # seg-faults here after printing "exciting!"

I ran into a seg-fault in the same place a couple weeks ago on my old
build, but fixed it because each of my compiled functions and methods
included my "macros.imc" file, which I didn't realize was totally
redundant (I figured every use of the compile opcode started with a
fresh compiler state, but I guess that's not the case, thank God).

So speaking of pathalogical test cases, un-comment the last two lines of
the following example to seg-fault (note that my macros.imc file, which
I attached, is, weird).

.sub _main @MAIN
  .local pmc pir
  .local pmc mysub
  compreg pir, "PIR"
  newclass $P0, "one"
  compile mysub, pir, ".include \"cruft/macros.imc\"\n.namespace[\"one\"]\n"
  newclass $P1, "two"
  compile mysub, pir, ".include \"cruft/macros.imc\"\n.namespace[\"two\"]\n"
  newclass $P2, "three"
  compile mysub, pir, ".include \"cruft/macros.imc\"\n.namespace[\"three\"]\n"
  newclass $P3, "four"
  compile mysub, pir, ".include \"cruft/macros.imc\"\n.namespace[\"four\"]\n"
  newclass $P4, "five"
  compile mysub, pir, ".include \"cruft/macros.imc\"\n.namespace[\"five\"]\n"
  newclass $P5, "six"
  compile mysub, pir, ".include \"cruft/macros.imc\"\n.namespace[\"six\"]\n"

# uncomment to seg-fault

#  newclass $P6, "seven"
#  compile mysub, pir, ".include \"cruft/macros.imc\"\n.namespace[\"seven\"]\n"
.end

Include my macros.imc file more than seven times and boom.
 
> >Print a prompt, read a line, print the line, print the prompt, a
> >simplification of Parakeet's interpreter loop.  it works on a month
> >old parrot checkout just fine, but on a checkout done this afternoon
> >it prints the prompt *after* it reads the line.
> 
> This one looks like an autoflush problem.

That was my first guess too.

> I don't think we've ever 
> formally defined what happens when you don't set the autoflush 
> properties of filehandles,and I think some of Leo's IO optimizations 
> for the piethon are causing a problem here. Doesn't look like we've 
> defined how to set autoflushing for filehandles, so we'd best go do 
> that.

Hmm, I'm suprised this didn't break a lot more stuff since it's just a
simple input to output loop one would find about anywhere.  Well, I'll
wait for the configurable autoflush features and step back to the old
build for now.

-Michel


macros.imc
Description: Binary data

Re: Something broke for me

[Dan Sugalski]

At 11:24 AM -0700 8/13/04, Michel Pelletier wrote:
I've been developing Parakeet on a month old Parrot build, so today I
decided to update to a recent checkout, and Parakeet broke two ways.
The first is multi-inheritance stopped working, but that's not as big a
deal as the new problem.
Gack -- it's a very big deal, and the test suite should've picked 
that up. D'you have a code snippet that demonstrates it, so we can 
fix the problem and get a test to help keep it happening in the 
future?

Print a prompt, read a line, print the line, print the prompt, a
simplification of Parakeet's interpreter loop.  it works on a month old
parrot checkout just fine, but on a checkout done this afternoon it
prints the prompt *after* it reads the line.
This one looks like an autoflush problem. I don't think we've ever 
formally defined what happens when you don't set the autoflush 
properties of filehandles,and I think some of Leo's IO optimizations 
for the piethon are causing a problem here. Doesn't look like we've 
defined how to set autoflushing for filehandles, so we'd best go do 
that.

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

Something broke for me

[Michel Pelletier]

I've been developing Parakeet on a month old Parrot build, so today I
decided to update to a recent checkout, and Parakeet broke two ways.

The first is multi-inheritance stopped working, but that's not as big a
deal as the new problem.  Consider:

.sub _main @MAIN

  BeginInteraction:
getstdin $P0
print ">>>"
readline $S0, $P0
print $S0
goto BeginInteraction

.end

Print a prompt, read a line, print the line, print the prompt, a
simplification of Parakeet's interpreter loop.  it works on a month old
parrot checkout just fine, but on a checkout done this afternoon it
prints the prompt *after* it reads the line.

[EMAIL PROTECTED]:~/dev/parrot$ ./parrot languages/test/test.imc
one two
>>>one two

Did I miss something that changed, or should I file a bug report?

-Michel

Re: PMC semantics - integer

[Dan Sugalski]

At 1:43 PM +0200 8/10/04, Leopold Toetsch wrote:
We currently have two integer PMCs, we need another one for Python. 
But before just copy&paste another file, I'd really have done that 
right.
I think what we need's a policy here. Larry's weighed in on what 
Perl's going to want, which is cool. (In part because I'd lost track 
of this message :)

So, for us:
1) The base types don't change. Ints stay Ints, Strings stay Strings, 
and so on.

2) All language-specific PMC classes get names prefixed with their 
language. (So PerlInt, PerlString, and so on) If the version number 
gets wedged in there that's fine--language designer/porter/whoever's 
call. We'll also recommend a leading double-underscore, but it's not 
our problem if someone doesn't and there's a collision.

3) The base name for all our PMC classes has a double-underscore 
prepended. That means __Undef, __SArray, and so on. No, we don't have 
to prepend Parrot. We're special that way.

4) We should set a rule *now* that says that all parrot base types 
can be referenced by constant number. This should save us a lot of 
hassle later--if code wants a base Undef it can use the Undef number 
and not have to worry about whether a language has an Undef base 
class, or doesn't follow the naming scheme, or something.

5) We need to set up an alias and namespace system so languages can 
generally ignore this. Perl's going to want its base int class named 
"int" or "Int", and so is Python, and we should make at least a 
minimal attempt to set things up so that code that looks up PMC 
classes by name actually behaves right.

If someone wants to take on ownership of the existing PDD on our base 
types that's fine with me.
--
Dan

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

Re: PMC semantics - integer

[Larry Wall]

On Tue, Aug 10, 2004 at 01:43:37PM +0200, Leopold Toetsch wrote:
: We need offical PDDs about the behavior of our PMCs. I hope that Perl6 
: types will be the same as Perl5 types.

Well, assuming that Perl 6 is like Perl 5 is often a good first
approximation, but in this case we're thinking that Ints (but not
ints) promote to arbitrary size.  We don't think of it as promoting to
BigInt, but rather simply that the Int type doesn't have an arbitrary
size limitation.  In essence, we think of it the other way around:
Int *is* BigInt, but optimized to use a fast representation for
small integers.  You'd use "int" if you want fast integers limited
to the natural integer size of the current machine, and then the
P6 compiler is free to use integer registers rather than PMCs.
Untyped variables are assumed to store an Int PMC rather than an int,
though the optimizer might be able to demote some Ints to int, of course,
given sufficiently aggressive optimization flags.

Anyway, that's the current p6think.  It's not so far off of the Python
model here, I suspect, at least on the Int level.

Larry

Re: [perl #31026] Fix generation of src/nci.c to be more efficient

[Leopold Toetsch]

chromatic wrote:
On Fri, 2004-08-13 at 09:23, Dan Sugalski wrote:

This hash should either be allocated from constant PMCs that don't 
get GC'd, or put in the root set, then.

Just to be specific then, the steps would be:
	- allocate a new PMC
	- mark it as constant (PMC_constant_FLAG) 
That would be too late. Constant PMCs are living in the 
constant_pmc_pool. *But* constant PerlHashes have non-constant 
buffer-like headers and are unusable as constants currently.

See e.g. constant_pmc_new_nonit() in src/pmc.c
When that's fixed (or hash's memory is malloced) then the keys have to 
be declared with CONST_STRING() or - as these are C strings in the first 
place, you create a custom hash with C-string keys. See the API in 
hash.c:new_hash_x() or just new_cstring_hash()

... or call the register op on
the PMC (though does this have interpreter-specific meaning?)
dod_register_pmc() would work but is a bit inefficient. The long term 
solution is for sure to keep such Parrot internal structures that live 
forever out of the root set and make these really constant. For now 
that's a simple and working solution.

- store it somewhere that other interpreters and other trips through
the function can access it (don't know how to do this)
interpreter->iglobals e.g. where BTW the entry #3 "Env" is history and 
unused ;)

leo

Re: [perl #31046] IRIX64 perlnum_36 float output expectation

[Andy Dougherty]

On Tue, 10 Aug 2004, Jarkko Hietaniemi wrote:

> $ perl -Ilib t/pmc/perlnum.t
> ...
> not ok 36 - +- zero
> # Failed test (t/pmc/perlnum.t at line 690)
> #  got: '0
> # 0
> # '
> # expected: '0
> # -0.00
> # '

> I don't think there is any guarantee how fp -0.0 should be printed
> by printf() (I could be wrong on this, as usual). Even if there is,
> unless Parrot does something about it (to fudge the result), I do not
> think a platform behaving slightly differently (like printing the
> negative zero as zero) is not a failure.

At present, I think parrot *does* try and "do something about it", but it
does so in a rather non-portable way.  What I think it ought to do is use
signbit(), if available.

The hack used now depends on BIG_ENDIAN or LITTLE_ENDIAN (I think -- I
don't have sources available right now so I can't check) and probably
assumes something about sizeof(int) relative to sizeof(double).  I'd
expect that the "algorithm" used there is simply wrong for IRIX64.

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: What Unicode means to us

[Larry Wall]

On Wed, Aug 11, 2004 at 04:16:48PM -0400, Dan Sugalski wrote:
: If it's that handy then someone can write a library routine. This 
: feels very much to be in the same category as running a 
: speech-to-text algorithm if you send WAV data to a text filehandle.

Well, you can write a library routine, but if you have to invoke it
in a separate pass it's not as efficient.

: Not going to happen. Charset conversion mismatches either throw an 
: exception or falls back to a default bogus character.

Seems to me that a reasonable compromise is merely to provide a way
to hook in a user-defined callback and leave it at that.  Then the
user can have whatever policy they like, and Dan doesn't have to
implement it.

Larry

Re: Functions for embedders to override

[Dan Sugalski]

At 11:04 AM -0700 8/13/04, Larry Wall wrote:
On Tue, Aug 10, 2004 at 10:45:43AM -0700, Brent 'Dax' Royal-Gordon wrote:
: I would assume (hope) that these tables would not be allowed to change
: once Parrot started using them.  It seems like an extremely dangerous
: thing to have two calls to read() be performed by different functions,
: after all.
Just as a datapoint, Perl 6's .wrap/.unwrap will have to work at run
time, because one person's compile time is another person's run time.
We deliberately fuzz them in Perl, because most compilation policy
is actually set by running bits of Perl code.
These are playing at a different level, and different rules apply. 
Interpreter-level subs'll be overridable. That's not a problem. The 
issue here is whether we let the interpreter swap out what's the 
equivalent of functions in the C runtime. *That*, I think, we're not 
going to allow. Later, maybe, but not now.
--
Dan

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

Re: Handling block parameters in Ruby

[Larry Wall]

On Fri, Aug 13, 2004 at 02:21:30PM -0400, Matt Diephouse wrote:
: All this talk of blocks and Ruby (and A12 Lookahead Notions) brings up
: an important question in my mind: how will Perl 6 handle multiple
: blocks? When using Ruby, I found blocks both easy and pretty. But I
: found writing a method with multiple blocks to be both less easy and
: less pretty.

Yes, that's precisely why I'm trying to generalize Ruby's single
"magic" block into one or more ordinary parameters.

: >From what I understand, something like this will be possible (but will
: it need parens?):
: 
:  @array.each :odd{ $^odd.bar() } :even{ $^even.baz() };

No parens necessary there.  But parens are necessary if you want to
pass any non-adverbial arguments to a method.  On the other hand, since
adverbs are just named parameters you can also write that:

@array.each( :odd{ $^odd.bar() } :even{ $^even.baz() } );

or equivalently

@array.each( 'odd' => { $^odd.bar() }, 'even' => { $^even.baz() } );

: But what about this?
: 
:  @array.each:{$^odd.bar() }:{ $^even.baz() };
:
: Admittedly it's a much smaller case, but it should be useful, even if
: I can't think of a non trivial case offhand.

Two anonymous adverbs?  Hmm.  While I can think of ways to force it to
work, I'm inclined to disallow it simply because it'd make another
arbitrary rule we'd have to explain.

You know, at some point you just break down and write them positionally:

@array.each( { $^odd.bar() }, { $^even.baz() });

On the other hand, the parser will have to deal with multi-block
structures all the time, so perhaps something could be modelled on
how we eventually handle if/elsif/else, presuming we actually
declare those as macros, and not strictly as grammar rules.

Larry

Re: [perl #31064] [PATCH] nail the last IRIX64 nci.t failure (due to unaligned access)

[chromatic]

On Wed, 2004-08-11 at 09:21, Jarkko Hietaniemi wrote:

--- t/pmc/nci.t 2004-08-11 19:11:06.0 +0300
+++ t/pmc/nci.t.dist2004-08-11 19:14:15.0 +0300
@@ -566,7 +566,7 @@
   push P2, 0
   push P2, 0
   push P2, .DATATYPE_STRUCT_PTR
-  # attach the unmanaged struct as property
+  # attach the unmanged struct as property
   set P1, P2[-1]
   setprop P1, "_struct", P4
   push P2, 0

That's either an awfully subtle comment on the test, or a reversed
patch.

-- c

Re: Handling block parameters in Ruby

[Matt Diephouse]

On Fri, 13 Aug 2004 10:46:45 -0700, Larry Wall <[EMAIL PROTECTED]> wrote:
> This maps pretty well onto Ruby's magic blocks
> (and admittedly was inspired by it), though Perl will have different
> syntactic rules about how to pass one, of course, because we're
> generalizing the concept somewhat.  In particuler, one way to pass
> a magic block is as an anonymous adverb: C<< :{...} >>.  I suspect
> it can also be passed as the final element on the slurpy list,
> from which it could be removed at either compile time or call time.
> Or it could be passed as an explicitly named parameter.  That's
> what I mean by generalizing Ruby's concept--there's no "magic" syntax
> for blocks--it's just another named parameter, where the name can
> sometimes be omitted on the call.  It's always declared with a name
> on the receiving end, and there's no magic "yield" on an implicit
> closure.  Just call the named closure.

All this talk of blocks and Ruby (and A12 Lookahead Notions) brings up
an important question in my mind: how will Perl 6 handle multiple
blocks? When using Ruby, I found blocks both easy and pretty. But I
found writing a method with multiple blocks to be both less easy and
less pretty.

>From what I understand, something like this will be possible (but will
it need parens?):

 @array.each :odd{ $^odd.bar() } :even{ $^even.baz() };

But what about this?

 @array.each:{$^odd.bar() }:{ $^even.baz() };

Admittedly it's a much smaller case, but it should be useful, even if
I can't think of a non trivial case offhand.

-- 
matt diephouse
--
http://matt.diephouse.com

> 
> Larry
>

Re: Functions for embedders to override

[Larry Wall]

On Tue, Aug 10, 2004 at 10:45:43AM -0700, Brent 'Dax' Royal-Gordon wrote:
: I would assume (hope) that these tables would not be allowed to change
: once Parrot started using them.  It seems like an extremely dangerous
: thing to have two calls to read() be performed by different functions,
: after all.

Just as a datapoint, Perl 6's .wrap/.unwrap will have to work at run
time, because one person's compile time is another person's run time.
We deliberately fuzz them in Perl, because most compilation policy
is actually set by running bits of Perl code.

Don't know to what extent you can generalize that to embedding
interfaces though.  Just that you already have to provide for the fact
that the person who called the unwrapped function needs to return
from the unwrapped function eventually even if the function got
wrapped in the meantime.  Unwrapping a function is perhaps dicier,
but no dicier than deleting a subroutine, which we already allow in
Perl 5.  Smells like a GC problem on the return continuation, mostly.
(Of course, as soon as you mention continuations in the same breath
as embedding, you've got issues... :-)

Larry

Re: Handling block parameters in Ruby

[Larry Wall]

On Fri, Aug 13, 2004 at 02:12:06PM +0100, mark sparshatt wrote:
: My main worry with this approach is how it would interact with slurpy 
: args. I mean if method is defined as
: 
: def method(*args)
: ...
: end
: 
: how do I make sure that $clos doesn't become part of args?

In Perl 6 circles we've been considering that a signature declaration
could have a "slurpy function" as well as slurpy arrays and hashes.
The magic block would actually be processed as a named argument with
an implicit name, so there's no problem with where to pass it in the
positional arguments.  This maps pretty well onto Ruby's magic blocks
(and admittedly was inspired by it), though Perl will have different
syntactic rules about how to pass one, of course, because we're
generalizing the concept somewhat.  In particuler, one way to pass
a magic block is as an anonymous adverb: C<< :{...} >>.  I suspect
it can also be passed as the final element on the slurpy list,
from which it could be removed at either compile time or call time.
Or it could be passed as an explicitly named parameter.  That's
what I mean by generalizing Ruby's concept--there's no "magic" syntax
for blocks--it's just another named parameter, where the name can
sometimes be omitted on the call.  It's always declared with a name
on the receiving end, and there's no magic "yield" on an implicit
closure.  Just call the named closure.

[I've cc'd p6l, so please send replies to the appropriate list.]

Larry

Re: [perl #31026] Fix generation of src/nci.c to be more efficient

[chromatic]

On Fri, 2004-08-13 at 09:23, Dan Sugalski wrote:

> This hash should either be allocated from constant PMCs that don't 
> get GC'd, or put in the root set, then.

Just to be specific then, the steps would be:

- allocate a new PMC
- mark it as constant (PMC_constant_FLAG) or call the register op on
the PMC (though does this have interpreter-specific meaning?)
- store it somewhere that other interpreters and other trips through
the function can access it (don't know how to do this)
- stuff the Hash into the data pointer of the constant PMC, when
initializing the table
- retrieve the PMC and its hash all other times

If that's reasonable, I'll hack on it a bit today.  If there's a simpler
way, please point me at code to inspire me and I'll hack on that
instead.

-- c

Re: Revision of A12's lookahead notions

[Larry Wall]

On Tue, Aug 10, 2004 at 06:10:17PM -0400, Uri Guttman wrote:
: can you have a 0- or 1-ary function? meaning like the many funcs that
: work on $_ with no args or the single arg you pass in. how do you
: declare it so it parses correctly?
: 
:   splurt  # should work on $_
:   splurt()# should work on $_
:   splurt + 1  # same??
:   splurt +1   # work on +1??
:   splurt( +1 )# definitely work on +1

Yes, functions declared with a single optional argument end up parsed
as named unaries, as in Perl 5 (though Perl 5 merely assumed that
a single argument was optional).  The "greedy function" rule still
applies in that it will try to look for an argument, and only default
to being 0-ary if it can't find an argument.

And functions declared 0-ary explicitly parse as terms, while all 2-ary
and higher functions parse as list operators unless you use parens.
(All functions are considered to be list ops before declaration,
and if the declaration subsequently changes that fact, it's an error.
So 0-ary and 1-ary functions have to be predeclared if you want them
to parse as unaries.)

I think this is all consistent and useful, but of course I could simply
be wrong, or more likely, wrongish.

Larry

Re: [perl #31026] Fix generation of src/nci.c to be more efficient

[Dan Sugalski]

At 5:16 PM +0100 8/10/04, Nicholas Clark wrote:
On Mon, Aug 09, 2004 at 03:11:53PM -0400, Dan Sugalski wrote:
 At 11:57 AM -0700 8/9/04, chromatic wrote:

 >Is there a particular hash lookup style you have in mind?  If there's
 >something similar in the code already, I can copy, paste, and modify the
 >generator trivially.
 You could look at what we do for class registration -- that code
 might be similar. I don't think we've got too much at the C level
 that messes around with parrot hashes yet, though.
Does the structure change at runtime? (ie can one register new dynamically
loaded NCI helper code?)
If not, a generated switch statement would work as well as a data structure,
surely?
The hash is constant (as are the current signature things), so we 
should be fine with a compile-time construct like a big switch 
statement. Either way, as long as the garbage collector doesn't eat 
it. :)

Speed isn't that big an issue here, since this is all initialization 
code anyway--you call it once per function when the function's 
registered with parrot. While we certainly don't want it slow, which 
the current system is very likely to be with more function 
signatures, there's a limit to how much worrying's worth it. I'd 
expect our built-in hash to be more than faast enough for the purpose.
--
Dan

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

Re: [perl #31026] Fix generation of src/nci.c to be more efficient

[Dan Sugalski]

At 1:11 PM +0200 8/13/04, Leopold Toetsch wrote:
chromatic wrote:
No, not a lot of examples.  Here's a patch that's somewhat naive but
passes all tests on my machine (Linux PPC).
I'm a bit concerned about the initialization code, especially the static
hash, but it's more important to have code available for review than
improvement than to wait until it's perfect to release it.
Your concerns are valid. The hash gets happily collected by the 
garbage collector. All nci tests fail here with --gc-debug.
This hash should either be allocated from constant PMCs that don't 
get GC'd, or put in the root set, then.
--
Dan

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

Re: Functions for embedders to override

[Dan Sugalski]

At 11:07 AM +0200 8/13/04, Hans Ginzel wrote:
On Mon, Aug 09, 2004 at 12:04:31PM -0400, Dan Sugalski wrote:
 When Parrot's being embedded I can see the following functions
 needing overriding by the embedder:
 *) Memory: malloc, realloc, calloc, free
 *) Signals: handler register, Handler un-register, signal raise, alarm set
 *) Files: Open, close, seek, tell, read, write. (Possibly asynchronously)
lock(), flock(),
   The original functions should stay accesible to write wrappers.
Can't do that, unfortunately. The only thing available is what's in 
the table. The overrides may be done for security or integrity 
reasons (which'd be quite common in an embedding situation) which 
means that using the original versions would be a security risk. We 
shouldn't do that.
--
Dan

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

Re: Handling block parameters in Ruby

[Dan Sugalski]

At 1:00 PM +0200 8/13/04, Leopold Toetsch wrote:
mark sparshatt wrote:
I'd like advice on how to handle method invocations that include 
special block parameters such as

method() {do something}
The idea is to turn the block into a closure pmc. The problem is 
how to pass this to the method, so that it knows that it's a 
special block parameter. Particularly in a way so that a language 
which doesn't know about blocks can still call Ruby code.
Can't you just compile the code like this:
  new_pad 0
  newsub $clos, .Closure, _do_something
  method($clos)
  ...
.sub _do_something
  new_pad -1
 ...
and pass the closure as additional argument to the method?
This runs into issues of argument placement. The closure argument's 
not a real parameter any more than the object is a real parameter for 
a method call. It arguably ought to be separated out. The original 
design of the calling conventions had it as a separate parameter, but 
Larry convinced me to take it out. I'm thinking that, in retrospect, 
that was a sub-optimal decision.

On the other hand, I'm not sure an extra block slot's the right 
answer either, though it's more right than not. It'd have to go into 
the interpreter structure with the return continuation, calling 
object and method object, so that's another pointer that'd need to be 
copied, cleared, or set as appropriate. (though that's only a 1 cycle 
cost most places)

Still, I think it might be worth dedicating a slot to it. It's a 
handy feature, and if we open it up to perl & python I'd bet we'd see 
them using it.
--
Dan

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

Re: register allocation

[Dan Sugalski]

At 12:24 AM -0600 8/13/04, Thomas Fjellstrom wrote:
On August 9, 2004 02:34 pm, Dan Sugalski wrote:
 At 4:12 PM -0400 8/9/04, Melvin Smith wrote:
 >At 11:22 AM 8/9/2004 -0400, Dan Sugalski wrote:
 >>At 1:13 PM +0200 8/8/04, Leopold Toetsch wrote:
 >>>Leopold Toetsch <[EMAIL PROTECTED]> wrote:
   You can verify this step by running -v:
 >>>
 >>>$ parrot -v inv_mod.imc 2>&1 | grep symb
 >>>build_reglist: 5783 symbols
 >>>allocate_non_interfering, now: 2205 symbols
 >>>
 >>>It really should help.
 >>
 >>It did. I'm not sure how long the build ran (the last time I
 >>checked it'd racked up over 150 minutes of CPU time on a 2GHz
 >>dual-processor system, and may have run up to about 180 CPU
 >>minutes) but it finished.
 >>
 >>Now we need to cut down the runtimes just a touch. :)
 >
 >DSWEPIC
 >
 >Dan Stop Writing Evil Pathological Intermediate Code.
 Hah! I wish I was writing this. Instead, I'm writing a compiler for
 an Evil Pathological Language. :(
Perl? >:)
You kidding? Perl's got nothing on this... thing. More than all the 
annoyance, with none of the redeeming features, though it does work. 
(On the other hand, I'm quite looking forward to being able to let it 
die in obscurity where it belongs :)
--
Dan

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

Re: Test for functions with operator names

[Andy Lester]

On Fri, Aug 13, 2004 at 02:29:40PM +0200, Rafael Garcia-Suarez ([EMAIL PROTECTED]) 
wrote:
> Andy Lester wrote:
> > #./perl -T
>   ^^
> the lack of "!" here gave me a small headache during the integration.

Sorry about that.  Here's one teeny more patch to add, to minimize the
amount of silencing we do.

xoxo,
Andy


--- t/comp/opsubs.t.orig2004-08-13 09:40:54.0 -0500
+++ t/comp/opsubs.t 2004-08-13 09:45:00.0 -0500
@@ -26,8 +26,8 @@
 
 # m operator
 can_ok( 'main', "m" );
-SILENCE_WARNING: { # Complains because $_ is undef
-no warnings;
+SILENCE_WARNING: {
+no warnings 'uninitialized'; # m// complains because $_ is uninitialized
 isnt( m('unqualified'), "m-unqualified", "m('unqualified') is oper" );
 }
 is( main::m('main'), "m-main", "main::m() is func" );

-- 
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: What Unicode means to us

[Dan Sugalski]

At 7:37 PM +1000 8/10/04, Adam Richardson wrote:
I'm not sure how you plan to integrate the database level (or whether it
affects what you are doing at all), but presumably you know all about the
new encoding and collation sets in mySQL 4.1. Things have changed quite a
bit there from 4.0, and I've seen a few issues with various middleware
handling those changes.
I can't remember if I replied to this, or what happened to it, what 
with the perl.org list machine dying a horrible death and all. So, 
risking redundancy...

The plan for database level integration is to make the C-level API 
sufficiently rich as to allow extensions to specify the 
encoding/charsets of the strings they create, as well as to transform 
strings into encodings/charsets they like better.

Which does remind me that we ought to make the NCI interface a bit 
richer so we can specify this in the signatures as well. That'd be 
useful.
--
Dan

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

Re: parrot cvs mirrored with svk

[Dan Sugalski]

At 6:34 AM +0800 8/10/04, Chia-liang Kao wrote:
While this is not the best list discussing which version control system
is better, I must say that I didn't mean svn is better though I setup the
mirror. And my purpose was actually to make it possible for svk to mirror
more efficiently.
Don't worry about it -- Subversion's long-standing occasionally sore 
topic, and I'm afraid you've inadvertently caught some history.  :)

Having a working subversion mirror's a cool thing, and at some point 
I think we will move the main repository over to subversion from CVS, 
if for no other reason than to allow us to delete directories and 
rename files without hassle. As Andy's timing shows, though, we've 
still got some issues to deal with before we can reasonably do this.

On Mon, Aug 09, 2004 at 03:56:46PM -0400, Andy Dougherty wrote:
 > 41 minutes? Subversion checkout takes 2m14s for me, as compared to CVS 1m.
 Yes, 41 minutes, compared to 8 minutes for cvs.

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

Re: Handling block parameters in Ruby

[mark sparshatt]

Leopold Toetsch wrote:
mark sparshatt wrote:
I'd like advice on how to handle method invocations that include 
special block parameters such as

method() {do something}
The idea is to turn the block into a closure pmc. The problem is how 
to pass this to the method, so that it knows that it's a special 
block parameter. Particularly in a way so that a language which 
doesn't know about blocks can still call Ruby code.

Can't you just compile the code like this:
  new_pad 0
  newsub $clos, .Closure, _do_something
  method($clos)
  ...
.sub _do_something
  new_pad -1
 ...
and pass the closure as additional argument to the method?
My main worry with this approach is how it would interact with slurpy 
args. I mean if method is defined as

def method(*args)
...
end
how do I make sure that $clos doesn't become part of args?
--
Mark Sparshatt

Re: Test for functions with operator names

[Rafael Garcia-Suarez]

Andy Lester wrote:
> Here's a test file that makes sure that even with sub q{}, that q() is
> an operator, but &q() and main::q() are function calls.  I suggest that
> it be called t/comp/operator-subs.t.

Thanks, applied as #23215.

> #./perl -T
  ^^
the lack of "!" here gave me a small headache during the integration.

Re: [perl #31063] [PATCH] Mention new languages in LANGUAGES.STATUS

[Leopold Toetsch]

Bernhard Schmalhofer (via RT) wrote:
the two new languages 'Span' and 'Parakeet' should be mentioned in
LANGUAGES.STATUS.
Thanks, applied.
leo

Re: Handling block parameters in Ruby

[Leopold Toetsch]

mark sparshatt wrote:
I'd like advice on how to handle method invocations that include special 
block parameters such as

method() {do something}
The idea is to turn the block into a closure pmc. The problem is how to 
pass this to the method, so that it knows that it's a special block 
parameter. Particularly in a way so that a language which doesn't know 
about blocks can still call Ruby code.
Can't you just compile the code like this:
  new_pad 0
  newsub $clos, .Closure, _do_something
  method($clos)
  ...
.sub _do_something
  new_pad -1
 ...
and pass the closure as additional argument to the method?
leo

Re: [perl #31026] Fix generation of src/nci.c to be more efficient

[Leopold Toetsch]

chromatic wrote:
No, not a lot of examples.  Here's a patch that's somewhat naive but
passes all tests on my machine (Linux PPC).
I'm a bit concerned about the initialization code, especially the static
hash, but it's more important to have code available for review than
improvement than to wait until it's perfect to release it.
Your concerns are valid. The hash gets happily collected by the garbage 
collector. All nci tests fail here with --gc-debug.

leo

Re: [perl #31050] [PATCH] Exception handling bugfix on failed delegation

[Leopold Toetsch]

Felix Gallo (via RT) wrote:
Synopsis: in CVS as of Tue Aug 10 17:30:52 EDT 2004, the
examples/japh/japh[4,5,6,9].pasm examples all crash with
segmentation fault on my highly hacked up linux box.
Ah, yep thanks.
They arguably should be working fine. 
IO changes WRT output line-buffering made thread-related fail. The japhs 
using delegate were failing mainly during missing prototypes for return 
values. But I've changed these to use objects now.

The patch is attached.  
Thanks, applied
leo

Re: Revision of A12's lookahead notions

[Uri Guttman]

> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:

  LW>   1c) Explicit parentheses may delimit the actual arguments,
  LW>   in which case the function is parsed as a function rather
  LW>   than a list operator.  Adverbs may follow the parens:

  LW>   splurt(1,2,3):by{ +$_ } # okay
  LW>   splurt(1,2,3):{ +$_ }   # okay (implicit binding to *& param)
  LW>   splurt 1,2,3# okay (assumed to be list operator)
  LW>   splurt; # okay, 0-arg list
  LW>   splurt() + 1# okay, explicit 0 arg list
  LW>   splurt + 1  # wrong unless predeclared 0-ary

can you have a 0- or 1-ary function? meaning like the many funcs that
work on $_ with no args or the single arg you pass in. how do you
declare it so it parses correctly?

splurt  # should work on $_
splurt()# should work on $_
splurt + 1  # same??
splurt +1   # work on +1??
splurt( +1 )# definitely work on +1

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

Re: Functions for embedders to override

[Uri Guttman]

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:

  DS> At 6:32 PM +0100 8/10/04, Arthur Bergman wrote:

  >> Modern operating systems all have a way to get around the suckiness
  >> of poll/select when you have large number of fds
  >> (epoll/aio/kqueue/whatever), there should be away to override those
  >> interfaces as well :-) (maniac laugh)

  DS> Gah. I want one semi-generic way. And a lollypop, too, so at least I'm
  DS> pretty sure to get one of two.

  DS> Overriding poll/select is more because I'm assuming that any system
  DS> which overrides the file functions may well override the monitoring
  DS> functions for filehandles.

take a look at libevent which wraps most/all of the select flavors and
provides a single api. it's a c lib with some flavor of open source
license. i would love to see it wrapped in perl5 xs/swig/inline
and put on cpan (hint! :) .

supporting all those event loop flavors directly in parrot seems like
too much work.

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

PATCH for parrotcode.org

[William Coleda]

Attached find a patch to http://www.parrotcode.org/examples/index.html that:
(0) depends on a patch I sent to the webmaster folks earlier adding back in the docs/* 
hierarchy (a small shim of .html files that just points to everything that ends up in 
parrot's docs directory after a build. - goes against cvs-latest)
(1) removes all references to assemble.pl (sorry, Simon!)
(2) updates all examples so that they work. (some used opcode variants that were 
removed)
(3) hyperlinks to the aforementioned soon-to-be added things in the docs/ directory.
(4) Adds blocks clearly indicating the output of the examples. (as a side effect, 
reworked some of the outputs to prefer spaces over newlines. Hopefully no one's 
sensibilities will be affected)
(5) cleaned up some minor HTML nits. (and, sadly, probably added more back in.)
(6) removed some of the "parrot used to" language and some of the "we're missing 
stuff" language.
Future patches should probably:
(a) split up the examples into multiple pages.
(b) move the actual examples into parrot and include them on the fly with Roberts very cool server side include magic. 
(c) Include some PIR examples.
(d) switch the pretty boxes to CSS classes, presuming the webmasters don't object.
(e) add examples for new features that didn't exist at the time of the last overhaul, like Objects (jryan on #parrot promises an example for objects soon.)

Regards.
Index: examples/index.html
===
--- examples/index.html (revision 427)
+++ examples/index.html (working copy)
@@ -5,7 +5,7 @@
 
 
 Eventually this section of the site will become a full introduction to
-Parrot assembly code. Please be patient while it is built.
+Parrot assembly code and PIR. Please be patient while it is built.
 
 
 Introduction
@@ -37,36 +37,25 @@
 
 
 
-Download and install the latest version of Parrot if you have not already done so. 
+Download the latest version of Parrot if you have not already done so. 
 
 
-Recent changes
-
-
-The calling conventions have been completely changed from callee-save
-to caller-save. The examples have been updated and are now much more
-comprehensive.
-
-
-
-Updated the examples to work with the new assembler.
-
-
 Parrot assembler
 
 
-Parrot assembler is a low-level language which compiles directly into
+Parrot assembler (PASM) is a low-level language which compiles directly into
 the Parrot virtual machine. Unlike most other virtual machines (but
 like most real computers), Parrot is register-based. It has 32
 registers of four different types: integers, numbers, strings, and
-PMCs. These are named I0...I31, N0...N31, S0...S31, P0...P31. Most
+PMCs. These are named I0...I31, N0...N31, S0...S31,
+ and P0...P31. Most
 Parrot operators have the same format: the name of the operator, the
 destination register, and the operands.
 
 
 
-The Parrot assembly language documentation (PDD6)
-(docs/parrot_assembly.pod in the source distribution) is the
+The 
+Parrot assembly language documentation (PDD6) is the
 main source of information about the assembly language, so you should
 read that for full information about the language.
 
@@ -74,10 +63,11 @@
 Hello world!
 
 
-The first example clearly has to be an example that prints out "Hello
-world!". What could be simpler than the following code:
+The first example clearly has to be an example that prints out "Hello
+world!". What could be simpler than the following code:
 
 
+
 
 
 
+
+If you save this small file as "hello.pasm", you can assemble and execute
+it in one pass with ./parrot hello.pasm
+
 
 
-If you save this small file as "hello.pasm", you can assemble the code
-to bytecode with ./assemble.pl hello.pasm -o hello.pbc and
-actually run the code with ./parrot hello.pbc which will
-indeed print out "Hello world!".
+If you would rather assemble separately, you can first generate a bytecode
+file with ./parrot -o hello.pbc hello.pasm. Then, you can run the
+pre-assembled bytecode with: ./parrot hello.pbc. Either way, you'll
+get:
 
 
+
+Hello world!
+
+
+
 
 Note that the first line in the file is a comment, which starts with a
 '#' character - everything until the end of the line is counted as a
 comment. Note the last line contains the operator end which
-stops execution of the program.
+stops execution of the program. This is required.
 
 
 Assignment
@@ -108,10 +109,9 @@
 Assignment between registers is done with the set
 operator. The following code sets the first integer register to 1, the
 first number register to 4.2 and the first string register to
-"Resting". It will then print them all out, resulting in "1, 4.20, Resting":
+"Resting"
 
 
-
 
@@ -127,12 +127,20 @@
 end
 
 
+Prints:
 
+
+1, 4.20, Resting
+
+
+
 
 Note how it seems that the print operator is polymorphic - it can
 print integers, numbers, strings, and string constants. Actually,
 these are all separate operators (for details look in
-core.ops in the source distribution) - th

Re: Why do users need FileHandles?

[Nicholas Clark]

On Wed, Aug 11, 2004 at 03:25:20PM -0700, David Storrs wrote:
> On Sat, Aug 07, 2004 at 03:55:21PM +0100, Nicholas Clark wrote:

> > However, Acme::Intraweb hasn't been updated for a while, whereas CPANPLUS
> > has, so I'm not sure if it still works. Both are by Jos Boumans.
> 
> Urrmmm...ok, I'm sure I'm just being dense here, but I do not see your
> point.  Can you unpack it for me?

IIRC you said "it would be good if perl6 could do this"

My point was that Jos wrote a module for perl5 that could do this last year.
However, I suspect if you attempt to install it from CPAN today it will
break, because it's not been updated to cope with changes to CPANPLUS,
upon which it depends.

Nicholas Clark

Re: register allocation

[Thomas Fjellstrom]

On August 9, 2004 02:34 pm, Dan Sugalski wrote:
> At 4:12 PM -0400 8/9/04, Melvin Smith wrote:
> >At 11:22 AM 8/9/2004 -0400, Dan Sugalski wrote:
> >>At 1:13 PM +0200 8/8/04, Leopold Toetsch wrote:
> >>>Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>   You can verify this step by running -v:
> >>>
> >>>$ parrot -v inv_mod.imc 2>&1 | grep symb
> >>>build_reglist: 5783 symbols
> >>>allocate_non_interfering, now: 2205 symbols
> >>>
> >>>It really should help.
> >>
> >>It did. I'm not sure how long the build ran (the last time I
> >>checked it'd racked up over 150 minutes of CPU time on a 2GHz
> >>dual-processor system, and may have run up to about 180 CPU
> >>minutes) but it finished.
> >>
> >>Now we need to cut down the runtimes just a touch. :)
> >
> >DSWEPIC
> >
> >Dan Stop Writing Evil Pathological Intermediate Code.
>
> Hah! I wish I was writing this. Instead, I'm writing a compiler for
> an Evil Pathological Language. :(

Perl? >:)

-- 
Thomas Fjellstrom
[EMAIL PROTECTED]
http://strangesoft.net

Re: Why do users need FileHandles?

[David Storrs]

On Sat, Aug 07, 2004 at 03:55:21PM +0100, Nicholas Clark wrote:
> On Sat, Jul 24, 2004 at 02:50:18PM -0700, David Storrs wrote:

> > #!/usr/bin/perl6
> 
>   #!/usr/bin/perl

I stated perl6 explicitly to be, well, explicit.


> > #use warnings;  # Note that I am NOT explicitly using these
> > #use strict;
> > 
> > {   no 'warnings'; no 'strict';   # These must be explicitly turned off...
> > no installation_security; # or this would throw warning & error
> 
>   use Acme::Intraweb;
> 
> > use SomeModule; #
> > use OtherModule;# 
> > use Foo;# If these are not installed,
> > use Bar;# they will be auto-installed.
> > use Baz;#
> > use Jaz;#
> > }
> 
> 
> However, Acme::Intraweb hasn't been updated for a while, whereas CPANPLUS
> has, so I'm not sure if it still works. Both are by Jos Boumans.

Urrmmm...ok, I'm sure I'm just being dense here, but I do not see your
point.  Can you unpack it for me?

--Dks

Handling block parameters in Ruby

[mark sparshatt]

I'd like advice on how to handle method invocations that include special 
block parameters such as

method() {do something}
The idea is to turn the block into a closure pmc. The problem is how to 
pass this to the method, so that it knows that it's a special block 
parameter. Particularly in a way so that a language which doesn't know 
about blocks can still call Ruby code.

On the Cardinal mailing list Dan Sugalski mentioned the possibility of 
having a special block parameter. For Ruby use this would be perfect.

The downside is that AFAICT it'd only be used by Ruby code. I'm not sure 
it's a good idea to modify the calling conventions for the benefit of 
just one user language.

--
Mark Sparshatt

[perl #31061] [PATCH] parrot_coverage.pl

[via RT]

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



Hi,

I found tools/dev/parrot_coverage.pl in freshly updated cvs tree to be
completely broken at least on my workstation:

> cat /etc/redhat-release 
Red Hat Linux release 9 (Shrike)

> gcov -v
gcov (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
Copyright (C) 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

After applying the attached patch I got all worked. Additionally this
patch eliminates all warnings that appeared with the old version.

Vadim.
Index: tools/dev/parrot_coverage.pl

===

RCS file: /cvs/public/parrot/tools/dev/parrot_coverage.pl,v

retrieving revision 1.3

diff -u -r1.3 parrot_coverage.pl

--- tools/dev/parrot_coverage.pl9 Aug 2004 15:09:36 -   1.3

+++ tools/dev/parrot_coverage.pl11 Aug 2004 12:22:44 -

@@ -34,7 +34,7 @@

 my $HTMLDIR = "parrot_coverage";

 my $DEBUG   = 1;

 

-if ($ARGV[0] =~ /recompile/) {

+if ($ARGV[0] && $ARGV[0] =~ /recompile/) {

 

  clean up remnants of prior biulds

 File::Find::find({wanted => sub {

@@ -43,7 +43,7 @@

 }}, $SRCDIR);

 

  build parrot with coverage support

-system("perl Configure.pl --cc=\"gcc -fprofile-arcs -ftest-coverage\"");

+system("perl Configure.pl --ccflags=\"-fprofile-arcs -ftest-coverage\"");

 system("make");

 

  Now run the tests

@@ -71,8 +71,8 @@

 foreach my $da_file (@dafiles) {

 my $dirname   = dirname($da_file) || ".";

 my $filename  = basename($da_file);

-my $objectfilename = $da_file;

-$objectfilename =~ s/\.da$//g;

+my $srcfilename = $da_file;

+$srcfilename =~ s/\.da$/.c/;

 

 #gcov must be run from the directory that the compiler was invoked from.

 #Currently, this is the parrot root directory.

@@ -81,7 +81,7 @@

 #Hence, as soon as we know the true name of the object file being profiled, 

 #we rename the gcov log file.

 #The -o flag is necessary to help gcov locate it's basic block (.bb) files.

-my $cmd = "gcov -f -b -o $da_file $objectfilename";

+my $cmd = "gcov -f -b -o $dirname $srcfilename";

 print "Running $cmd..\n" if $DEBUG;

 open (GCOVSUMMARY, "$cmd|") || die "Error invoking '$cmd': $!";

 my $tmp;

@@ -122,13 +122,13 @@

 next;

 }

 

-my ($percent, $total_lines, $function) = /\s*([^%]+)% of (\d+)(?: 
source)? lines executed in function (.*)/;

+($percent, $total_lines, my $function) = /\s*([^%]+)% of (\d+)(?: 
source)? lines executed in function (.*)/;

 if ($total_lines) {

 $function_line_coverage{$source_file}{$function} = $percent;

 next;

 }

 

-my ($percent, $total_branches) = /\s*([^%]+)% of (\d+) branches taken at 
least once in file/;

+($percent, my $total_branches) = /\s*([^%]+)% of (\d+) branches taken at 
least once in file/;

 if ($total_branches) {

 my $covered_branches = int(($percent/100) * $total_branches);

 $totals{branches} += $total_branches;

@@ -137,19 +137,19 @@

 next;

 }

 

-my ($percent, $total_branches, $function) = /\s*([^%]+)% of (\d+) 
branches taken at least once in function (.*)/;

+($percent, $total_branches, $function) = /\s*([^%]+)% of (\d+) branches 
taken at least once in function (.*)/;

 if ($total_branches) {

 $function_branch_coverage{$source_file}{$function} = $percent;

 next;

 }

 

-my ($percent, $total_calls, $function) = /\s*([^%]+)% of (\d+) calls 
executed in function (.*)/;

+($percent, my $total_calls, $function) = /\s*([^%]+)% of (\d+) calls 
executed in function (.*)/;

 if ($total_calls) {

 $function_call_coverage{$source_file}{$function} = $percent;

 next;

 }

 

-my ($percent, $total_calls) = /\s*([^%]+)% of (\d+) calls executed in 
file/;

+($percent, $total_calls) = /\s*([^%]+)% of (\d+) calls executed in file/;

 if ($total_calls) {

 my $covered_calls = int(($percent/100) * $total_calls);

 $totals{calls} += $total_calls;

@@ -330,7 +330,7 @@

 close(IN);

 

 

-my $outfile = "$outfile_base.branches.html";

+$outfile = "$outfile_base.branches.html";

 print "Writing $outfile..\n" if $DEBUG;

 open (IN, "<$infile") || die "Can't read $infile: $!\n";

 open (OUT, ">$outfile") || die "Can't write $outfil

Re: Functions for embedders to override

[Hans Ginzel]

On Mon, Aug 09, 2004 at 12:04:31PM -0400, Dan Sugalski wrote:
> When Parrot's being embedded I can see the following functions
> needing overriding by the embedder:
>
> *) Memory: malloc, realloc, calloc, free
> *) Signals: handler register, Handler un-register, signal raise, alarm set
> *) Files: Open, close, seek, tell, read, write. (Possibly asynchronously)

lock(), flock(),

   The original functions should stay accesible to write wrappers.


Hans

[perl #31050] [PATCH] Exception handling bugfix on failed delegation

[via RT]

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


Synopsis: in CVS as of Tue Aug 10 17:30:52 EDT 2004, the
examples/japh/japh[4,5,6,9].pasm examples all crash with
segmentation fault on my highly hacked up linux box.

They arguably should be working fine.  But that's neither
here nor there.  The problem this patch addresses is that
find_or_die attempts to get a class from a PMC which is
not necessarily an object, doesn't do error checking on 
that attempt, and then attempts to print the class's
object attributes.

The patch is attached.  

Tickling the bug (note that 10 and 13 are also broken):

$ for i in examples/japh/*.pasm  
> do
> echo $i
> ./parrot $i
> done
examples/japh/japh1.pasm
Just another Parrot Hacker
examples/japh/japh10.pasm
Js nte artHce
examples/japh/japh11.pasm
examples/japh/japh12.pasm
Just another Parrot Hacker
examples/japh/japh13.pasm
Js nte artHce
examples/japh/japh14.pasm
Just another Parrot Hacker
examples/japh/japh15.pasm
Just another Parrot Hacker
examples/japh/japh16.pasm
Just another Parrot Hacker
examples/japh/japh17.pasm
Just another Parrot Hacker
examples/japh/japh2.pasm
Just another Parrot Hacker
examples/japh/japh3.pasm
Just another Parrot Hacker
examples/japh/japh4.pasm
Segmentation fault
examples/japh/japh5.pasm
Segmentation fault
examples/japh/japh6.pasm
Segmentation fault
examples/japh/japh7.pasm
Just another Parrot Hacker
examples/japh/japh8.pasm
Just another Parrot Hacker
examples/japh/japh9.pasm
Segmentation fault
$

Felix
--- delegate.pmc2004-08-10 23:29:33.0 +0200
+++ .#delegate.pmc.1.27 2004-08-10 22:59:34.0 +0200
@@ -85,14 +85,19 @@
 PMC *class = pmc;
 if (PObj_is_object_TEST(pmc)) {
 class = GET_CLASS((Buffer *)PMC_data(pmc), pmc);
-}
-internal_exception(METH_NOT_FOUND,
-"Can't find method '%s' for object '%s'",
+internal_exception(METH_NOT_FOUND,
+"Can't find method '%s' for object '%s'\n",
 string_to_cstring(interpreter, meth),
 string_to_cstring(interpreter, PMC_str_val(
 get_attrib_num((SLOTTYPE *)PMC_data(class),
 PCD_CLASS_NAME)))
 );
+} else {
+internal_exception(METH_NOT_FOUND,
+"Can't find method '%s' - erroneous PMC\n",
+string_to_cstring(interpreter, meth)
+);
+   }
 }
 return returnPMC;
 }

Questions on NCI for nasty library

[Hildo . Biersma]

> "Hildo" == Hildo Biersma <[EMAIL PROTECTED]> writes:

Hildo> I'm looking at writing Parrot support for a vendor library: IBM MQ
Hildo> (Message Queueing, aka "MQSeries", aka "WebSphere MQ").  The current
Hildo> perl module (which I maintain) uses XS code and Parrot's NCI should
Hildo> simplify this a lot.

Hildo> I have two questions though:

This thread got side-track with perl5 issues, so let me ask again:

- Are there any examples of creating a PMC class that maps to a C
  structure, with the PMC class (in C) setting defaults and adding
  accessor methods?

- How do I define a class with constant values that are accessible to
  other classes?  E.g. I want to be able to use constants like this
  pseudo-code:

OpenOptions.Flags = WMQ.MQC.MQOO_READ_ONLY

  where MQOO_READ_ONLY is a typed constant that lives in the WMQ.MQC
  class.

Hildo> - MQ has some data structures that are a tad too complex to use
Hildo>   Parrot's UnManagedStruct and ManagedStruct.  In addition, the C
Hildo>   structures need to be initialized with a non-zero default from an
Hildo>   IBM header file, so there needs to be C code.

Hildo> Does anyone have code examples of how to create a PMC class that
Hildo> maps to external C structure definitions and how to use such a PMC
Hildo> class with NCI code?

Hildo> - MQ has constants.  Thousands of them.  In the perl module, these get
Hildo> mapped to perl XS subroutines (which bloats the symbol table no
Hildo> end).  For parrot, I'd prefer to use two big hash tables of the type

Hildo> name  => PMC with (value, kind, description)
Hildo> value => name (for reason codes only)

Hildo> What's the best way to create a big hash table in parrot?  I have
Hildo> an existing perl script to parse the IBM MQ header files and generate
Hildo> perl source code, so generating parrot code is not the issue -
Hildo> really, it's what the best structure in parrot is.

Hildo> I'd prefer to optimize for smallest data structure size, and am
Hildo> willing to take a minor hit at lookup time; looking up constants is
Hildo> not performance-critical.

Re: The encoding API

[Gopal V]

Hi Dan & Michael,

As a guy who speaks a strange language (multi byte chars, multi glyph
chars,  caseless
text and half vowels) , I think you have made it too complicated than
it should be .

> charset end of things, offsets will be in graphemes (or Freds. I
> don't remember what we finally decided to name the things))

Writing a unicode composition and rendering is VERY VERY HARD ...
Find a way to leech that ... (I've tried a pango module for malayalam and
it's really really hard to do).

> When dealing with variable-length encodings, removal of codepoints in
> the middle may make the string shrink, and adding them may make it
> grow. The encoding layer is responsible for managing the underlying
> byte buffer to maintain consistency.

It was soo easy with immutable strings ... I think that is why Java could
implement unicode properly :)

> >>  void to_encoding(STRING *);
> >>
> >>Make the string the new encoding, in place

A String should always be Unicode IMHO , they should be converted to
byte buffers
by encoding and back from byte buffers while decoding.

> >>  UINTVAL get_codepoint(STRING *, offset);
> >>  void set_codepoint(STRING, offset, UINTVAL codepoint);

*if* , String always contains (length, UINTVAL[])  always , doesn't it
make life easier  ?


> >>  UINTVAL get_byte(STRING *, offset)
...
> Byte offset. Needs more clarity.
...
> >>   void set_byte(STRING *, offset, UINTVAL byte);
...

My advice would be to never let the layer above the encoding know that
we're storing
it in bytes :)

> >>   STRING *get_codepoints(STRING, offset, count);

Immutability of returned string (and original) would save memory ..
especially the UINTVAL
array was GC allocated :) .. of course what you have here is the
substring operation in
a new and obfuscated name :)

// some psuedo code as I see it.
substring(string, offset, count)
{
// validate params or catch fire and exit
   string2=gc_alloc(string_header);
   string2->length =  count;
   string2->data = &(string->data[offset]); // hopefully data is also gc_alloc'd
   return string2;
}

I'm afraid your design is waaay too complicated, at least for an
average guy like me .
I'd like to suggest that all STRING be  unicode and convert to byte
buffers and back for all
other purposes. But that's just a suggestion :)

Gopal

How to misuse code coverage

[Andy Lester]

A link from Ask Bjoern Hansen's blog: http://www.askbjoernhansen.com/

"How To Misuse Code Coverage"
http://testing.com/writings/coverage.pdf

xoa

-- 
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Async I/O (was Re: Functions for embedders to override)

[Scott Bronson]

On Tue, 2004-08-10 at 22:42, Dan Sugalski wrote:
> Part of me's tempted to just define our own set of functions, but the 
> problem there is that we then put the onus on the embedding app to 
> conform to us, which I'm not sure is the right way to go about things.

When the standard APIs are all so completely different (kqueue, epoll,
aio, /dev/poll) and seriously broken (select, poll), I think you pretty
much HAVE to define your own API!  If you standardize on kqueue,
implementing epoll becomes incredibly difficult, and vice versa.  The
only solution that I am aware of is to introduce a sane API that works
with all possible underlying implementations.


I had a similar need for another project about a year ago.  I wanted my
my application to have a single I/O API, no matter which underlying
implementation was being used.  I looked at a few libraries at the time
that claimed to do exactly this, but they were all very heavyweight and
intrusive.  So, I rolled my own.  Here's a quick description...


The API:

Each file is represented by a filedescriptor and a callback routine. 
These are grouped into an io_atom structure.  io_atoms are intended to
be embedded into other data structures, so all io_atom
allocation/deallocation is handled by the caller.

typedef struct io_atom {
io_proc proc;
int fd;
} io_atom;

To use it:

typedef {
io_atom io;
int parse_state;
... etc.
} struct my_connection;


io_add starts monitoring an atom. Specify the events that you are
interested in in flags (IO_EXCEPT appears to be very platform
dependent...  IO_READ is also used to get incoming connections from a
listening socket).

int io_add(io_atom *atom, int flags);

Change the events an atom is monitoring using io_set.
Stop monitoring an atom with io_del.

int io_set(io_atom *atom, int flags);
int io_del(io_atom *atom);


Whenever an event occurs on a filehandle, the atom's io_proc
notification is called.  The flags tell what happened.

#define IO_READ 0x01
#define IO_WRITE 0x02
#define IO_EXCEPT 0x04

   typedef void (*io_proc)(struct io_atom *atom, int flags);



Your application waits for events and dispatches them using io_wait.  A
timeout of 0 means return immediately after dispatching all pending
events, a timeout of MAXINT means no timeout -- never return.  Timeout
is in milliseconds.

int io_wait(int timeout);


Finally, because some of these implementations require dynamic memory
(kqueue), we need:

void io_init(); // inits internal data structures
void io_exit(); // releases all dynamic memory used

If you call io_exit without calling io_del on all the added FDs first,
the files are are not closed.  They are simply not monitored anymore.


TODO:

Some more work needs to be put into standardizing what error messages
can be returned by what calls and exactly what they mean.  Extensive
documentation.  Generalization.

Write a clearer demo!  :)


Perhaps TODO:

In my application, the io_atom appears first in every struct, so it's
real easy and memory-efficient to convert the atom into its containing
structure:

typedef struct connection {
io_atom io; ///< I/O information (set by rot_connect)
struct in_addr remote_addr;
int remote_port;
...

void callback(struct io_atom *io, int flags)
{
connection *conn = (connection*)io;
do_stuff(conn, flags);
}

This might not be true in the general case...  Maybe the io_atom should
include a void* client-specified refcon?


In summary...

I'm quite happy with this design, but the code is marginal right now. 
Nevertheless, I've banged together a mediocre networking demo.  Baware
the boogs!!  I figure I should have some time in a few weeks to solidify
this and get it into Parrot if nobody solves the IO issue before then. 
My girlfriend is moving to Boston, so that should help a lot.  :)

- Scott


P.S. This is all licensed under the same terms as Parrot: GPL or
Artistic 2.0, your choice.


// io.h
// Scott Bronson
// 2 Oct 2003

// This is the generic Async I/O API.  It can be implemented using
// select, poll, epoll, kqueue, aio, and /dev/poll (hopefully).
//
// This code is licensed under the same terms as Parrot itself.

#define IO_READ 0x01
#define IO_WRITE 0x02
#define IO_EXCEPT 0x04


// Tells how many incoming connections we can handle at once
// (the backlog parameter to listen)
#define STD_LISTEN_SIZE 128

struct io_atom;

/**
 * This routine is called whenever there is action on an atom.
 *
 * @param atom The atom that the proc is being called on.
 * @param flags What sort of action is happening.
 */
typedef void (*io_proc)(struct io_atom *atom, int flags);

typedef struct io_atom {
	io_proc proc;
	int fd;
} io_atom;


void io_init();
void io_exit();

int io_add(io_atom *atom, int flags);
int io_set(io_atom *atom, int flags);
int io_del(io_atom *atom);
/// Waits for an event, then handles it.  Stops waiting if

Charset API, part 2

[Dan Sugalski]

This is part two of the charset API. Part 1 dealt with access and 
transformation of strings, part two here deals with glyph and 
codepoint classification.

I'm not sure if these belong in the charset vtable or should be 
separate. Probably putting them in the vtable's the right (or at 
least least-wrong) thing to do.

It's probably pretty clear, but there's no language or locale stuff 
in here. There ought to be, but I'm not sure where to put it, so 
there isn't. This *does* affect the classification of characters, 
depending on how you look at it, so there's a possibility we will 
abstract this out somewhat. We likely need to do that for the regex 
engine(s) anyway, so that can wait for later.

In the following,  is one of: wordchar, whitespace, digit, 
punctuation, and newline.

  INTVAL is_(STRING, glyph_offset)
Return 1 if the glyph at the offset is in the specified class
  INTVAL find_(STRING, glyph_offset)
Return the offset of the first glyph in the string at or after the
offset which is in the class. -1 means there isn't one.
  INTVAL find_not_(STRING, glyph_offset)
Return the offset of the first character at or after the offset which
is *not* in the specified class
  INTVAL find_word_boundary(STRING, glyph_offset)
Return the offset of the first character which is after a word
boundary.
Yes, I can see having particular classes of characters, and classes 
which are explicitly specified, but I'm not sure those are truly and 
properly generic, so they're not here. I can certainly see adding in 
support for that if we think it's appropriate.
--
Dan

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

Test for functions with operator names

[Andy Lester]

Here's a test file that makes sure that even with sub q{}, that q() is
an operator, but &q() and main::q() are function calls.  I suggest that
it be called t/comp/operator-subs.t.

A transcription of the IRC conversation that started this discussion is
at the bottom of this file.  So often we have these discussions where a
topic is discussed and decided, it would be nice if they turned into
tests that define the behavior.  I've spent only about 90 mins working
on this test file, so it's not like writing these tests is a big time
suck.  Next time we get into behavior discussions, let's get a
deliverable of a .t file out of them.

Thanks,
xoxo,
Andy


#./perl -T

use warnings;
use strict;
$|++;

=pod

Even if you have a C, calling C will be parsed as the
C operator.  Calling C<&q()> or C gets you the function.
This test verifies this behavior for nine different operators.

=cut

use Test::More tests => 36;

sub m  { return "m-".shift }
sub q  { return "q-".shift }
sub qq { return "qq-".shift }
sub qr { return "qr-".shift }
sub qw { return "qw-".shift }
sub qx { return "qx-".shift }
sub s  { return "s-".shift }
sub tr { return "tr-".shift }
sub y  { return "y-".shift }

# m operator
can_ok( 'main', "m" );
SILENCE_WARNING: { # Complains because $_ is undef
no warnings;
isnt( m('unqualified'), "m-unqualified", "m('unqualified') is oper" );
}
is( main::m('main'), "m-main", "main::m() is func" );
is( &m('amper'), "m-amper", "&m() is func" );

# q operator
can_ok( 'main', "q" );
isnt( q('unqualified'), "q-unqualified", "q('unqualified') is oper" );
is( main::q('main'), "q-main", "main::q() is func" );
is( &q('amper'), "q-amper", "&q() is func" );

# qq operator
can_ok( 'main', "qq" );
isnt( qq('unqualified'), "qq-unqualified", "qq('unqualified') is oper" );
is( main::qq('main'), "qq-main", "main::qq() is func" );
is( &qq('amper'), "qq-amper", "&qq() is func" );

# qr operator
can_ok( 'main', "qr" );
isnt( qr('unqualified'), "qr-unqualified", "qr('unqualified') is oper" );
is( main::qr('main'), "qr-main", "main::qr() is func" );
is( &qr('amper'), "qr-amper", "&qr() is func" );

# qw operator
can_ok( 'main', "qw" );
isnt( qw('unqualified'), "qw-unqualified", "qw('unqualified') is oper" );
is( main::qw('main'), "qw-main", "main::qw() is func" );
is( &qw('amper'), "qw-amper", "&qw() is func" );

# qx operator
can_ok( 'main', "qx" );
eval "qx('unqualified')";
like( $@, qr/^Insecure/, "qx('unqualified') doesn't work" );
is( main::qx('main'), "qx-main", "main::qx() is func" );
is( &qx('amper'), "qx-amper", "&qx() is func" );

# s operator
can_ok( 'main', "s" );
eval "s('unqualified')";
like( $@, qr/^Substitution replacement not terminated/, "s('unqualified') doesn't 
work" );
is( main::s('main'), "s-main", "main::s() is func" );
is( &s('amper'), "s-amper", "&s() is func" );

# tr operator
can_ok( 'main', "tr" );
eval "tr('unqualified')";
like( $@, qr/^Transliteration replacement not terminated/, "tr('unqualified') doesn't 
work" );
is( main::tr('main'), "tr-main", "main::tr() is func" );
is( &tr('amper'), "tr-amper", "&tr() is func" );

# y operator
can_ok( 'main', "y" );
eval "y('unqualified')";
like( $@, qr/^Transliteration replacement not terminated/, "y('unqualified') doesn't 
work" );
is( main::y('main'), "y-main", "main::y() is func" );
is( &y('amper'), "y-amper", "&y() is func" );

=pod

from irc://irc.perl.org/p5p 8/12/2004

kane-xs bug or feature?
purlYou decide
kane-xs [EMAIL PROTECTED] ~]$ perlc -le'sub y{1};y(1)'
kane-xs Transliteration replacement not terminated at -e line 1.
Nicholasbug I think
kane-xs i'll perlbug
rgs feature
kane-xs smiles at rgs
kane-xs done
rgs will be closed at not a bug,
rgs like the previous reports of this one
Nicholasfeature being first class and second class keywords?
rgs you have similar ones with q, qq, qr, qx, tr, s and m
rgs one could say 1st class keywords, yes
rgs and I forgot qw
kane-xs hmm silly...
Nicholasit's acutally operators, isn't it?
Nicholasas in you can't call a subroutine with the same name as an
operator unless you have the & ?
kane-xs or fqpn (fully qualified package name)
kane-xs main::y() works just fine
kane-xs as does &y; but not y()
AndyIf that's a feature, then let's write a test that it continues
to work like that.

=cut


-- 
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: What Unicode means to us

[Dan Sugalski]

At 10:48 AM -0400 8/11/04, Aaron Sherman wrote:
I don't want to argue per-se (that doesn't do anyone any good), so if
your mind is made up, that's cool... still, I think there's some value
in exploring the options, so read on if you're so inclined.
On Wed, 2004-08-11 at 04:40, Dan Sugalski wrote:
 > Converting Unicode to non-Unicode character sets will be
 > lossless where possible, and will attempt to encode the name of
 > the character in ASCII characters into the target character set.
 Gack. No, I think this'd be a bad idea as the default behavior.
Well ok, why not make an exception the default behavior then? Just
reverse what I suggested from the default to the option. It's still
mighty handy for a language (any Parrot-based language) to be able to
render a meaningful string in any ASCII-capable encoding from any
Unicode subset.
If it's that handy then someone can write a library routine. This 
feels very much to be in the same category as running a 
speech-to-text algorithm if you send WAV data to a text filehandle.

Not going to happen. Charset conversion mismatches either throw an 
exception or falls back to a default bogus character.
--
Dan

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

[perl #31065] [PATCH src/*.c] Clean Up POD in C Files

[via RT]

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


Here's a patch that cleans up some POD errors and warnings in C files.

-- c


Index: src/inter_run.c
===
RCS file: /cvs/public/parrot/src/inter_run.c,v
retrieving revision 1.6
diff -u -u -r1.6 inter_run.c
--- src/inter_run.c	23 Jul 2004 13:26:32 -	1.6
+++ src/inter_run.c	11 Aug 2004 23:27:01 -
@@ -306,7 +306,7 @@
 /*
 
 =item C
 
 Mark saved register aread live during DOD
 
@@ -351,10 +351,11 @@
 
 =item C
-=cut
 
 Run a method sub from C.
 
+=cut
+
 */
 
 void
Index: src/lexical.c
===
RCS file: /cvs/public/parrot/src/lexical.c,v
retrieving revision 1.2
diff -u -u -r1.2 lexical.c
--- src/lexical.c	20 Jun 2004 10:31:38 -	1.2
+++ src/lexical.c	11 Aug 2004 23:27:02 -
@@ -17,6 +17,8 @@
 
 =over 4
 
+=cut
+
 */
 
 #include "parrot/parrot.h"
Index: src/pmc.c
===
RCS file: /cvs/public/parrot/src/pmc.c,v
retrieving revision 1.86
diff -u -u -r1.86 pmc.c
--- src/pmc.c	10 Jul 2004 15:30:56 -	1.86
+++ src/pmc.c	11 Aug 2004 23:27:03 -
@@ -51,7 +51,7 @@
 
 =item C
 
 Reuse an existing PMC, turning it into an empty PMC of the new
 type. Any required internal structure will be put in place (such as
@@ -611,7 +611,7 @@
 
 F.
 
-<[EMAIL PROTECTED]>
+C<[EMAIL PROTECTED]>
 (http://www.nntp.perl.org/group/perl.perl6.internals/5516).
 
 =head1 HISTORY
Index: src/resources.c
===
RCS file: /cvs/public/parrot/src/resources.c,v
retrieving revision 1.126
diff -u -u -r1.126 resources.c
--- src/resources.c	9 Aug 2004 14:51:13 -	1.126
+++ src/resources.c	11 Aug 2004 23:27:03 -
@@ -92,15 +92,12 @@
 
 Allocates memory for headers.
 
-Alignment problems:  C sets the size, but not the alignment of
-the memory block we are about to allocate.  The alignment of I
-block is currently determined by the C sent in by the
-I allocation. See
-L for details. Currently, we work around it by forcing all the
-C<*ALIGNMENT> C<#define>s in F<.h>> to be the
-same.
-
+Alignment problems:  C sets the size, but not the alignment of the
+memory block we are about to allocate.  The alignment of I block is
+currently determined by the C sent in by the I allocation.
+See L
+for details. Currently, we work around it by forcing all the C<*ALIGNMENT>
+C<#define>s in Finclude/parrot/I.hE> to be the same.
 
 =cut
 
Index: src/stack_common.c
===
RCS file: /cvs/public/parrot/src/stack_common.c,v
retrieving revision 1.18
diff -u -u -r1.18 stack_common.c
--- src/stack_common.c	7 Jul 2004 11:02:29 -	1.18
+++ src/stack_common.c	11 Aug 2004 23:27:03 -
@@ -24,18 +24,6 @@
 #include "parrot/parrot.h"
 #include 
 
-
-/*
-
-=item C
-
-Called from C to initialize the interpreter's
-register stacks.
-
-=cut
-
-*/
-
 typedef struct {
 size_t size;
 Stack_Chunk_t *free_list;
@@ -51,7 +39,8 @@
 
 =item C
 
-Initialize the stack subsystem
+Called from C to initialize the interpreter's
+register stacks.
 
 =cut
 
Index: src/string.c
===
RCS file: /cvs/public/parrot/src/string.c,v
retrieving revision 1.214
diff -u -u -r1.214 string.c
--- src/string.c	10 Aug 2004 11:05:11 -	1.214
+++ src/string.c	11 Aug 2004 23:27:04 -
@@ -16,10 +16,6 @@
 two data members, beside setting C/C for external
 strings.
 
-=head2 Functions
-
-=over 4
-
 =cut
 
 */
@@ -51,8 +47,6 @@
 
 /*
 
-=back
-
 =head2 String COW support
 
 =over 4
Index: src/warnings.c
===
RCS file: /cvs/public/parrot/src/warnings.c,v
retrieving revision 1.23
diff -u -u -r1.23 warnings.c
--- src/warnings.c	23 Apr 2004 09:21:13 -	1.23
+++ src/warnings.c	11 Aug 2004 23:27:04 -
@@ -10,7 +10,7 @@
 
 Parrot C and C string versions of a function to print warning/error
 messages.
- 
+
 =cut
 
 */

Re: The encoding API

[Michael Stone]

After my discussion, I've included an annotated copy of the functions, 
where I've added my comments after each function.

So, assuming (hah!) that I correctly understood everything in the draft, 
It seems that I have several general concerns:
1.  Why are lists of bits or bytes that are being interpreted as 
"unencoded", which seem to fit your definition of "string" in the WTHI: 
A String (http://www.sidhe.org/~dan/blog/archives/000255.html), written 
as being of the same type as lists of codepoints that have a definite 
encoding attached?  They may be similar, but would some confusion be 
avoided (or worth avoiding) by recognizing what seems to be to be a 
fundamental difference in the way that the two are interpreted?

2.  Do "offset" parameters measure the offset in codepoints or in bytes, 
or does it vary by function?  If it varies by function, I think we need 
a better notation for that.  However, if it's in bytes, who has to deal 
with the problems posed by variable-length encodings?  However, if 
"strings" represent text as an array (or list of bytes), then it makes 
some sense for the offset to be in bytes and not codepoints.

3.  Are we storing Unicode code-points in 32-bit wide fields, and if so, 
is UINTVAL guaranteed to be 32-bits wide on all supported platforms?
Incidentally, as I understand the standard, Unicode was designed not to 
care about signed/unsigned semantics.  That's why U+ is always an 
illegal value.

4.  When we're replacing codepoints in a STRING, which I understand to 
be a collection of bytes, what happens when the codepoint that we're 
replacing is shorter than the code-point that is being put in its place 
(in a variable length encoding)?  Are there any other issues with 
inserting code-points that we need to be aware of, like issuing warnings 
when illegal codepoints are inserted, or problems with neighboring 
codepoints that need to be checked (I'm thinking of Hangul here)?

5.  Do we need to have any hooks for transport-layer encodings like 
compression algorithms?

6.  Can the meanings of the functions be more clearly conveyed, 
particularly with respect to the length functions, or are these already 
standardized names for this functionality?

7.  What, if any responsibilities do these functions have for insuring 
that the input that they're dealing with and the output that they 
produce are valid?

8.  How will errors be handled?  By exception?  If so, what exceptions?  
What atomicity guarantees can we give?  I.e., If we're transforming a 
string "in-place" and an exception is thrown, what happens to the string?

Hope this gives you some ideas.  All in all, I think it will be quite 
workable.
Michael 
("Ashsong" on irc)

The annotated functions:
 void to_encoding(STRING *);
   Make the string the new encoding, in place
If this fails, it dies by throwing an exception?  If so, what exception?
Is this an atomic function?
 STRING *copy_to_encoding(STRING *);
   Make a copy of the string, in the new encoding.
Likewise.  Also, what semantics does the return value have if this fails?
 UINTVAL get_codepoint(STRING *, offset);
   Return the codepoint at offset.
Is "offset" the number of codepoints to skip or the number of bytes to 
skip?
(Since strings are thought of as being the bits that represent text, yet 
implementations (I think) shouldn't be responsible for dealing with 
variable-length encodings).

Also, what are the failure semantics?
 void set_codepoint(STRING, offset, UINTVAL codepoint);
   Set the codepoint at offset to codepoint
Since strings are lists of bits representing text, if you insert a 
codepoint in a UTF-8 encoded string (or anything else that's a 
variable-length encoding) and the codepoint that you insert is longer 
than the one that's there, what happens?

Also, is UINTVAL guaranteed to be 32-bits wide? (Since that's what 
Unicode code-points are supposed to be stored in, as I understand it.)

 UINTVAL get_byte(STRING *, offset)
   Get the byte at offset
Same concerns about the meaning of "offset".
  void set_byte(STRING *, offset, UINTVAL byte);
   Set the byte at offset to byte
Same concerns about "offset". 

Why is the type of parameter "byte" a UINTVAL?
  STRING *get_codepoints(STRING, offset, count);
Get count codepoints starting at offset, returned as a STRING of no
charset. (If called through the charset code the returned string 
may be
put into a charset if that's a valid thing) 
Same concerns about "offset".
  STRING *get_bytes(STRING, offset, count)
 Get count bytes starting at offset, returned as a binary STRING.
What is the design rationale for naming a set of bytes from which 
encoding (if I understand correctly) is deliberately being stripped as 
being of the same type as the encoded string?

Say I take a string in a foreign encoding and immediately call get_bytes 
on it.  Should I, as a programmer, be allowed to (implicitly) convert 
the resulting chunk of bytesback into a string in the current encoding 
by calling o

Re: Mailing list archives

[Matthew Walton]

Joe Gottman wrote:
   There's something wrong with the mailing list archives at
http://dev.perl.org/perl6/lists/.  I can get to this page OK, but when I
click on a link to the perl6-internals or perl6-language archives, I get a
"This page cannot be displayed" error.
The perl.org list server's been having some fairly serious trouble, 
according to what I read on Planet Perl. That would probably also 
explain why the list has been so quiet lately.

Re: The new Perl 6 compiler pumpking

[Steve Fink]

Sorry if this is a repeat, but I didn't get my own mail back, so I
think I may have had sending problems.

On Aug-09, Patrick R. Michaud wrote:
>
> Luke Palmer and I started work on the grammar engine this past week.
> It's a wee bit too early in the process for us to be making any
> promises about when people might be seeing releases and the like.
> But I think he and I are in agreement that we'd like to have a grammar
> engine substantially completed (at least to the level of being able
> to "bootstrap" a Perl 6 compiler) within the next 3-4 months.

I have one of those too, in languages/regex. The parser is crap, and
the implementation of the translation has probably seen a few too many
rounds of evolution, but I believe the output is the Right Way To Do
It and is relatively easy to extend to support the rest of the Perl6
features. Okay, maybe it's only One Of The Right Ways To Do It. I'd be
interested in knowing what your output looks like, and encourage you
-- if it's close enough -- to steal my rewrite rules wholesale.
(Actually, the parser used in the languages/perl6 directory is pretty
nice; the one in languages/regex that I use for testing is crap.)

See languages/regex/docs/regex.pod for an introductory document on
this style of rule implementation. I wrote it a while back, and have
added at least one more fundamental concept to what I laid out there,
but it should be more or less valid nonetheless.

I left off working on it long ago to concentrate on beefing up the
Perl6 compiler enough to make it an interesting host language, but
recently I've (locally) added match objects and a parse tree. I have
rules, but I was holding off grammars until someone else braver and
smarter than I beat on Parrot's object support a bit more. The various
cuts are straightforward additions that I've already sketched out, and
everything else is gravy. Heh.

And I'm really wishing I had picked Jako or one of the other
languages/* as a sample host language...

Mailing list archives

[Joe Gottman]

   There's something wrong with the mailing list archives at
http://dev.perl.org/perl6/lists/.  I can get to this page OK, but when I
click on a link to the perl6-internals or perl6-language archives, I get a
"This page cannot be displayed" error.

 

Joe Gottman

Re: What Unicode means to us

[Aaron Sherman]

I don't want to argue per-se (that doesn't do anyone any good), so if
your mind is made up, that's cool... still, I think there's some value
in exploring the options, so read on if you're so inclined.

On Wed, 2004-08-11 at 04:40, Dan Sugalski wrote:

> > Converting Unicode to non-Unicode character sets will be
> > lossless where possible, and will attempt to encode the name of
> > the character in ASCII characters into the target character set.
> 
> Gack. No, I think this'd be a bad idea as the default behavior. 

Well ok, why not make an exception the default behavior then? Just
reverse what I suggested from the default to the option. It's still
mighty handy for a language (any Parrot-based language) to be able to
render a meaningful string in any ASCII-capable encoding from any
Unicode subset.

I think the only problem would be in the realm of directionality of
script, but I assume that all non L-R scripts have some convention for
injecting snippits of L-R, just as en-US injects R-L, easy as "Ù Ù Ù".

> What's right is up in the air -- I'm figuring we'll either throw an 
> exception or substitute in a default character, but the full 
> expansion's definitely way too much.

That's too bad, as:

"This was converted from ïnicode"

becoming

"This was converted from {FULLWIDTH LATIN CAPITAL LETTER U}nicode"

seems much more reasonable than choosing some poor ASCII character to
act as the fallback.

If someone does something stupid like converting a 5MB document in UTF-8
encoded Cyrillic into ASCII, then they're going to get a huge result,
but that's no less useful than 3MB of text that looks like " ** 
***-**. ***'* *", I would think, and perhaps more useful for certain
purposes (e.g. it could still be deciphered and/or re-assembled).

The other way to go would be some sort of standardized low-level
notation to represent encoding and codepoint such as:

"This was converted from {U+FF35}nicode"

That's less readable, but arguably more reversible and/or precise.
Certainly more easily automatically detected. For example, the following
Perl 5 code could reverse such transformation:

s{\{(.)\+([a-f\d]+)\}}{
character(target_encoding  => $target_encoding,
  source_encoding  => abbrv_to_encoding($1),
  source_codepoint => hex("0x".$2))
}eg;

assuming, of course, a function "character" and a function
"abbrv_to_encoding" which attempt generate a character in a target
encoding based on a character in a source encoding and return an
encoding ID/name/object/whatever based on a one-character abbreviation
respectively.

It would be ideal if other tactics could be used like the GB 2312
encoding in ASCII described in RFC 1842. Of course, the above could be
permuted that way:

"This was converted from {G+~{<:Ky2;S{#,NpJ)l6HK!#~}}"

But that starts to get deeper into character set and encoding
transformation than my head is capable of coping with at this stage (I'm
really just learning about these topics). I fear I'm walking down a road
that ends in my suggesting that every non-Unicode string has a MIME
header, but rest assured that that's not my goal. I just wanted to
suggest a useful alternative to throwing an exception on incompatible
type conversion, especially for those client languages (e.g. m4) in
which an exception will either have to be ignored or treated as fatal.

-- 
â 781-324-3772
â [EMAIL PROTECTED]
â http://www.ajs.com/~ajs

Re: What Unicode means to us

[Aaron Sherman]

On Mon, 2004-08-09 at 14:14, Dan Sugalski wrote:

> Additionally if we have source text which is 
> Latin-n, EBCDIC, ASCII, or whatever we must be 
> able to convert it with no loss to Unicode. 
> (Which I believe is now doable with Unicode 4.0) 
> Losslessly converting Unicode to 
> ASCII/EBCDIC/whatever is *not* required, which is 
> fine as it's theoretically (and often 
> practically) impossible.

Can I suggest instead:

If we have source text which is comprised of a non-Unicode
character-set we must be able to convert it with minimal loss to
Unicode (minimal being defined as zero for all Unicode-subset
character sets).

Converting Unicode to non-Unicode character sets will be
lossless where possible, and will attempt to encode the name of
the character in ASCII characters into the target character set.
An example would be the conversion of the UTF-8 string (in Perl
5 notation):

"foo \x{263a} bar"

to the ASCII representation:

"foo {SMILING FACE, WHITE} bar"

There are 4 possible failure modes, each resulting in a
conversion exception: 1) the ASCII name is not available 2) the
ASCII name cannot be converted into the target character set
(recursive name-lookups are not allowed, nor would they be very
useful) 3) a VM parameter requesting exceptions on failed
character-set conversions has been set to a true value 4) the
source is a PMC and that PMC has a property indicating that
exceptions should be generated on failed conversions.

This just seems a bit more useful in the general case to me, while
allowing the language implementation the option of requesting an
exception either globally or per-PMC.

Thoughts?

-- 
â 781-324-3772
â [EMAIL PROTECTED]
â http://www.ajs.com/~ajs

[perl #31060] [PATCH] config.h.in tweaks

[via RT]

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


The PARROT_BYTEORDER (which is, oddly, unused) probably makes more sense
as a hex constant, and adding PARROT_LITTLEENDIAN as a logical inverse.

-- 
Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'.  It is 'dead'." -- Jack Cohen

--- config/gen/config_h/config_h.in.dist2004-08-11 14:28:52.0 +0300
+++ config/gen/config_h/config_h.in 2004-08-11 14:29:25.0 +0300
@@ -49,10 +49,12 @@
 
 #define PARROT_CPU_ARCH"${jitcpuarch}"
 #define PARROT_OS_NAME "${jitosname}"
-#define PARROT_BYTEORDER${byteorder}
+#define PARROT_BYTEORDER0x${byteorder}
 #define PARROT_BIGENDIAN${bigendian}
 #define PARROT_PTR_ALIGNMENT${ptr_alignment}
 
+#define PARROT_LITTLEENDIAN!(PARROT_BIGENDIAN)
+
 typedef Parrot_Int INTVAL;
 typedef Parrot_UInt UINTVAL;
 typedef Parrot_Float FLOATVAL;

Re: What Unicode means to us

[Dan Sugalski]

At 4:15 PM -0400 8/10/04, Aaron Sherman wrote:
On Mon, 2004-08-09 at 14:14, Dan Sugalski wrote:
 Additionally if we have source text which is
 Latin-n, EBCDIC, ASCII, or whatever we must be
 able to convert it with no loss to Unicode.
 (Which I believe is now doable with Unicode 4.0)
 Losslessly converting Unicode to
 ASCII/EBCDIC/whatever is *not* required, which is
 fine as it's theoretically (and often
 practically) impossible.
Can I suggest instead:
If we have source text which is comprised of a non-Unicode
character-set we must be able to convert it with minimal loss to
Unicode (minimal being defined as zero for all Unicode-subset
character sets).
   
Converting Unicode to non-Unicode character sets will be
lossless where possible, and will attempt to encode the name of
the character in ASCII characters into the target character set.
Gack. No, I think this'd be a bad idea as the default behavior. 
What's right is up in the air -- I'm figuring we'll either throw an 
exception or substitute in a default character, but the full 
expansion's definitely way too much.
--
Dan

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

[perl #31063] [PATCH] Mention new languages in LANGUAGES.STATUS

[via RT]

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


Hi,

the two new languages 'Span' and 'Parakeet' should be mentioned in
LANGUAGES.STATUS.

I see that LANGUAGES.STATUS is in a funny text format. Would it be useful to
transform it into something like YAML?

CU, Bernhard

-- 
/* [EMAIL PROTECTED] */

NEU: WLAN-Router fïr 0,- EUR* - auch fïr DSL-Wechsler!
GMX DSL = supergïnstig & kabellos http://www.gmx.net/de/go/dsl

languages_status_20040811.patch
Description: Binary data

Fw: Re: [perl #31031] Need a way to access the namespace of a class object

[Michel Pelletier]

I sent this on Tue, but it never came back to me from the list, so here
it is again.  Sorry if anyone gets a repeat.

Begin forwarded message:

Date: Tue, 10 Aug 2004 13:58:47 -0700
From: Michel Pelletier <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [perl #31031] Need a way to access the namespace of a class object


> From: Dan Sugalski (via RT) <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Reply-To: [EMAIL PROTECTED]
> Subject: [perl #31031] Need a way to access the namespace of a class object 
> Date: Mon, 09 Aug 2004 14:09:04 -0700
> 
> # New Ticket Created by  Dan Sugalski 
> # Please include the string:  [perl #31031]
> # in the subject line of all future correspondence about this issue. 
> # http://rt.perl.org:80/rt3/Ticket/Display.html?id=31031 >
> 
> 
> We need a way to get a handle on a class object's namespace or, 
> alternately, a scheme to allow adding a method by name to a class 
> object.

Can't the second thing be done now?  Maybe I don't understand or I'm
doing it wrong in Parakeet, but I create classes initially and later on
add methods to them by compiling PIR:

(in Parakeet)

0> class foo meth bar "hi!" println end end
0> see foo
.namespace["foo"]
.sub _bar method
inc .LEVEL
new_pad .LEVEL
.TOS = new .PerlString
.TOS = "hi!"
.PUSH
.POP
print .TOS
print "\n"
pop_pad
.pcc_begin_return
.pcc_end_return
.end
0> 

The class object is created by the word 'class'.  'meth' starts a new
method body which PIR gets emitted to during compilation, and then 'end'
(the first end that ends the meth definition) compiles it with the
"compile" opcode.  Notice that the PIR doesn't contain the class
definition, only the methods.  The class already exists when this code
is compiled.

It works for me, I can add any number of methods to a class by name.

-Michel

[perl #31059] [PATCH] pointer alignment

[via RT]

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


I don't think it's fair or correct to claim pointer alignment is
four on every platform just because 32-bit HP-UX hangs in the test.

-- 
Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'.  It is 'dead'." -- Jack Cohen
Index: parrot/config/auto/alignptrs.pl
===
RCS file: /cvs/public/parrot/config/auto/alignptrs.pl,v
retrieving revision 1.11
diff -u -r1.11 alignptrs.pl
--- parrot/config/auto/alignptrs.pl 8 Mar 2004 08:49:05 -   1.11
+++ parrot/config/auto/alignptrs.pl 11 Aug 2004 11:20:25 -
@@ -16,6 +16,7 @@
 use strict;
 use vars qw($description @args);
 use Parrot::Configure::Step ':auto';
+use Config;
 
 $description="Determining your minimum pointer alignment...";
 
@@ -26,11 +27,10 @@
 
   return if $miniparrot;
   # HP-UX 10.20/32 hangs in this test.
-  # We currently don't need this configure setting,
-  # so we just do not test and set some value here
-  print(" not tested (4) ") if $_[1];
-  Configure::Data->set(ptr_alignment => 4);
-  return;
+  if ($^O eq 'hpux' && $Config{ccflags} !~ /DD64/) {
+  Configure::Data->set(ptr_alignment => 4);
+  return;
+  }
 
   return if (defined(Configure::Data->get('ptr_alignment')));
   cc_gen('config/auto/alignptrs/test_c.in');

Re: [perl #31031] Need a way to access the namespace of a class object

[Michel Pelletier]

> From: Dan Sugalski (via RT) <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Reply-To: [EMAIL PROTECTED]
> Subject: [perl #31031] Need a way to access the namespace of a class object 
> Date: Mon, 09 Aug 2004 14:09:04 -0700
> 
> # New Ticket Created by  Dan Sugalski 
> # Please include the string:  [perl #31031]
> # in the subject line of all future correspondence about this issue. 
> # http://rt.perl.org:80/rt3/Ticket/Display.html?id=31031 >
> 
> 
> We need a way to get a handle on a class object's namespace or, 
> alternately, a scheme to allow adding a method by name to a class 
> object.

Can't the second thing be done now?  Maybe I don't understand or I'm
doing it wrong in Parakeet, but I create classes initially and later on
add methods to them by compiling PIR:

(in Parakeet)

0> class foo meth bar "hi!" println end end
0> see foo
.namespace["foo"]
.sub _bar method
inc .LEVEL
new_pad .LEVEL
.TOS = new .PerlString
.TOS = "hi!"
.PUSH
.POP
print .TOS
print "\n"
pop_pad
.pcc_begin_return
.pcc_end_return
.end
0> 

The class object is created by the word 'class'.  'meth' starts a new
method body which PIR gets emitted to during compilation, and then 'end'
(the first end that ends the meth definition) compiles it with the
"compile" opcode.  Notice that the PIR doesn't contain the class
definition, only the methods.  The class already exists when this code
is compiled.

It works for me, I can add any number of methods to a class at runtime.

-Michel

[perl #31064] [PATCH] nail the last IRIX64 nci.t failure (due to unaligned access)

[via RT]

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


Because this is a family channel I won't publicly comment on the
classes/unmanagedstruct.pmc change at line 527.

-- 
Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'.  It is 'dead'." -- Jack Cohen

--- classes/unmanagedstruct.pmc.dist2004-08-11 19:07:06.0 +0300
+++ classes/unmanagedstruct.pmc 2004-08-11 19:08:09.0 +0300
@@ -169,6 +169,7 @@
  */
 if (*type == enum_type_struct_ptr) {
 /* that is either a pointer */
+assert((PTR2INTVAL(p) & (PARROT_PTR_ALIGNMENT - 1)) == 0);
 PMC_data(init) = *(void**)p;
 }
 else {
@@ -182,8 +183,8 @@
  * p is the location of the struct pointer in the
  * outer struct, the inner is at PMC_data(init)
  */
+assert((PTR2INTVAL(p) & (PARROT_PTR_ALIGNMENT - 1)) == 0);
 *(void**)p = PMC_data(init);
-
 }
 return char_offset_key(interpreter, init, next, type);
 }
@@ -527,8 +528,6 @@
 
 if (align && offs % align) {
 int diff;
-if (align > 4 && !strcmp(PARROT_CPU_ARCH, "i386"))
-align = 4;
 diff = align - (offs % align);
 offs += diff;
 }
--- t/pmc/nci.t 2004-08-11 19:11:06.0 +0300
+++ t/pmc/nci.t.dist2004-08-11 19:14:15.0 +0300
@@ -544,7 +544,7 @@
 output_is(<<'CODE', <<'OUTPUT', "nci_p_i - nested struct *");
   loadlib P1, "libnci"
   dlfunc P0, P1, "nci_pi", "pi"
-  # this test function returns a struct { char; {int, int, double} }
+  # this test function returns a struct { char; x->{int, double} }
   set I5, 4
   invoke
 .include "datatypes.pasm"
@@ -566,7 +566,7 @@
   push P2, 0
   push P2, 0
   push P2, .DATATYPE_STRUCT_PTR
-  # attach the unmanaged struct as property
+  # attach the unmanged struct as property
   set P1, P2[-1]
   setprop P1, "_struct", P4
   push P2, 0