Re: specifying the key Type for a Hash

[Nigel Sandever]

On Sat, 04 Dec 2004 08:01:46 -0700, [EMAIL PROTECTED] (David Green) wrote:
> In article <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED] (Larry Wall) wrote:
> >S9 talk about it.  We current have things like:
> >my Cat %pet is shape(Str);
> >and parameters to types are in square brackets, so it's more like:
> >my %pet is Hash[:shape(Str) :returns(Cat)];
> 
> I still prefer "shaped", for pronounceability.  Although "shape" is a 
> bit of a stretch for something that's really more like "size", and even 
> stretchier for describing hash keys.  I'm not sure what better word we 
> could use, though.
> 
>  is built   # a constructive choice
>  is determined  # good for typing practice  =P
>  is bound   # what if you're bound AND determined?
>  is disposed# sounds like a destructor
>  is composed# I kinda like this one
>  is arrayed # oh, "array" in that other sense
>  is reckoned# bet no other language has that as a keyword
>  is cinched # it sounds so easy
>  is confined# to quarters
>  is walled  # now we're just being silly (no offense to Larry)
>  is earmarked   # some people wouldn't hear of it
>  is indexed # a bit better than "is keyed" (especially if it's your car)
>  is sized   # I think this was already rejected
>  is like# works really well if your type happens to be 'Totally'
>  is thus# very vague, but short
> 
> Hm.  
> 
> On the other hand, imagining Type-shaped holes into which your hash 
> keys fit *does* have a rather picturesque appeal...
> 
> 
>-David "the thesaurus is your friend (sometimes)" Green

I probably missed teh comprehensive dismissal thread, but why not 'type'?

my %pet is Hash[:type(Str) :returns(Cat)];

njs

Re: [perl #27304] [PATCH] move libnci.def out of root directory

[Bernhard Schmalhofer]

Will Coleda via RT wrote:
Can we get a ruling on this? I tend to agree with the statement "Random build files do not 
belong in the root directory".

The patch has been un-ACK'd for nine months at the moment.
While we are at it, shouldn't we rename 'libnci.so' and 'libnci.def' to 
'libnci_test.so' and 'libnci_test.def'. The library isn't used for NCI 
support, but for testing NCI support.

CU, Bernhard
Steps:
 (1) move ./libnci.def to ./src/libnci.def
 (2) apply patch
Patch updates ./config/gen/makefiles/root.in and ./MANIFEST with the
new location.
Why?  Random build files do not belong in the root directory.

--
**
Dipl.-Physiker Bernhard Schmalhofer
Senior Developer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel: +49 89 895574-839
Fax: +49 89 895574-825
eMail: [EMAIL PROTECTED]
Website: www.biomax.com
**

C implementation of Test::Harness' TAP protocol

[Clayton, Nik]

Having done the initial work to get most of FreeBSD's regression testing
infrastructure producing Test::Harness TAP compatible output, I've started
putting together a C library that makes it easier to write tests in C.

This is a few hours work at the moment, but it's functional, and I'd
appreciate comments.  The code's at:

http://jc.ngo.org.uk/trac-bin/trac.cgi/browser/nik/libtap/trunk/src/

I realise that's not the easiest way to download it, I'll make a tarball
available soon.  On the plus side, it's only a handful of files...

There are still a few things to do before it's a 1.0 candidate, listed at

http://jc.ngo.org.uk/trac-bin/trac.cgi/report/9

Here's the README:

Usage:

#include "tap.h", and link against libtap.so

Start by calling one of the plan_* functions:

plan_no_plan()   /* you have no test plan, or */
plan_skip_all("Because...")  /* all tests will be skipped, or */
plan_tests(42);  /* you will run 42 tests */

Then you have one of ok() or ok2() at your disposal.  ok()'s first parameter
is the code to test.  The second parameter is the test name.  This is a 
printf()like format string, and the third and subsequent parameters should
fill out any values in the string.

ok(a_func() == 0, "test name");
ok(some_func(i), "some_func(%d)", i);

ok2() is for situations where the code to test is sufficiently 
self-documenting that you don't need to provide a test name.

ok2(code to test); /* test name is automatically the same as the code */

E.g.,

ok(1 == 1, "1 equals one"); /* PRINT: ok 1 - 1 equals 1 */
ok2(1 == 2);/* PRINT: not ok 2 - 1 == 2 */

Sets of tests can be skipped.  Ordinarily you would do this because
the test can't be run in this particular testing environment.

For example, suppose some tests should be run as root.  If the test is
not being run as root then the tests should be skipped.  In this 
implementation, skipped tests are flagged as being ok, with a special
message indicating that they were skipped.

skip(n, msg, ...);

will produce output for 'n' lines of skipped tests.  The output message
is 'msg', and is printf()like.  It is your responsibility to ensure that
'n' is correct for the number of tests to skip.

This is normally implemented with a "do { ... } while(0);" loop, with a 
"continue;" immediately after the skip() call.  This ensures that there
are no additional side effects from the skipped tests.

do {
if(getuid() != 0) {
skip(1, "Test only makes sense as root");
continue;
}

ok(do_something_as_root() == 0, "do_something_as_root() worked");
} while(0);

Two macros, SKIP_START and SKIP_END can handle some of this for you.  The
above example could be re-written:

SKIP_START(getuid() != 0, 1, "Test only makes sense as root");

ok(do_something_as_root() == 0, "do_something_as_root() worked");

SKIP_END;

You also have diag(), which takes a printf() style format string and related
arguments, and sends the output to stderr as a test comment.  diag() adds
the necessary trailing "\n" for you.

diag("Expected return code 0, got return code %d", rcode);

Finally, there's exit_status(), which returns an int suitable for use
when return'ing from main(), or calling exit().  You should always do one
of:

return exit_status();
exit(exit_status());

As appropriate.
-- 
11 2 3 4 5 6 77
 0 0 0 0 0 0 05
-- The 75 column-ometer
Not speaking on behalf of my employer.  

Re: specifying the key Type for a Hash

[David Green]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Larry Wall) wrote:
>Maybe type parameters are just subscripts?  [...]
>my Fight %fight does key{Dog;Cat};

I like that.

>But if English-like is the criterion that'd still read better as
>my Fight %fight has key{Dog;Cat};

I like that even better.

>Maybe "has" and "does" are just synonyms, and you can use
>whatever makes more grammatical sense.  But pretty much every time
>I've introduced synonyms into Perl I've come to regret it.  But hey,
>if I introduce *different* synonyms this time, does that count as
>making a new mistake?

=)  Isn't "synonym" just Greek for TMTOWTDI?

To me, role-"has" seems different enough from attribute-"has" that 
the context would make it pretty clear which was meant.  (But maybe 
I'm just missing something subtle.  Or else something blatant.)

>The problem with a thesaurus is that it only gives you synonyms, not the
>word you really want.  :-)

Heh.  Sometimes I know the word I want, I just don't know I know it 
until the thesaurus reminds me.  And the rest of the time I just like 
looking through all the words.  As often as not, something on the 
opposite page catches my eye and I end up forgetting what I was 
looking for in the first place.

>Well, there's always "domain" and "range", if we want to be mathematical.

I'm happy with those too (perhaps because I do want to be a bit 
mathematical).

>Or we we wanted to be NASAesque, they'd be FATs, for Formal Argument Types.

"is FAT"?  Yeah, that works for me too.  =)

>Well, I just put "is shape" because that's what the PDLers settled on,
>but as far as I'm concerned linguistically, it could just be "is dim".
>That would settle the "make-it-like-English" question by making it
>not at all like English.
>On the aesthetic hand, "shape" is a much prettier word than "dim".

I would take that as an abbreviation and read it as "is dimensioned", 
which is English-like enough for me.  It's also short.  And I don't 
mind calling it dim, because if it were so smart, I wouldn't have to 
tell it what to do in the first place.  But "shape" *is* prettier.


  -David "pondering the shape of things to come" Green

Re: Premature pessimization

[Leopold Toetsch]

Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
>> This term came up in a recent discussion[1]. But I'd like to give this
>> term a second meaning.

> Except what you're talking about here is premature *optimzation*.

No. I don't think so.

>> During design considerations we (including me of course too) tend to
>> discard or pessimize ideas early, because they look inefficient

And I've summarized a bunch of examples. Maybe it wasn't too clear, but
the conclusion is of course: spilling, lexical refetching, using
method calls, ... (expensive looking operations) should not be discarded
early. They can be optimized *later*.

> ...  Inline caching is
> just another optimization.  We need to be feature complete.

That's exactly what I've written. I've described this idea as a
possible later optimization.

> And if you really feel like you need to optimize something, look into
> the lexicals-as-registers idea you had to fix continuation semantics.
> Then you can work under the guise of fixing something broken.

Yeah. Have a look at chromatic's 4 c-words:

  compiles -> correct -> complete -> competitive

"compiles" isn't really given, when there are compilers that either
can't compile an -O3 build of the switched core or take ages to
complete (if memory usage even permits that) choking the CG* cores.

"correct". I've discovered and analysed the problem with continuations.
I've made a proposal to fix that. No one has said that it's technically
wrong or couldn't work. It seems you are liking the idea, but Dan
doesn't. Now what?

"complete" - read e.g. my recent postings WRT MMD (and perl.cvs.parrot:)

"competitive" well, I like a speedy Parrot, that's obvious. It's a nice
to have. But not only. Folks on conferences get interested in Parrot
because it can proof that programs will run faster.

> Luke

leo

Re: continuation enhanced arcs

[Leopold Toetsch]

Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:

>> Matt Fowles <[EMAIL PROTECTED]> wrote:
>>
>>> Thanks for the clear explanation.  I did not realize that S registers
>>> could switch pointers, that does make things a little harder.  I have
>>> a recommendation for a possible hybrid solution.  Incur the cost of
>>> spilling I,S,N registers heavily.  Restore the state of P register.
>>
>> My conclusion was that with the copying approach I,S,N registers are
>> unusable.

> But you only need to copy when the frame you're restoring is a full
> continuation

Yes. With the effect that semantics of I,S,N (i.e. value registers)
suddenly changes.

> I'd submit that, in the vast majority of cases you're not going to be
> dealing with full continuations, and on the occasions when you are the
> programmer using them will be aware of the cost and will be willing to
> pay it.

*If* the programmer is aware of the fact that a subroutine can return
multiple times, he can annotate the source so that a correct CFG is
created that prevents register reusing alltogether. The problem is
gone in the first place.

*If* that's not true, you'd get the effect that suddenly I,S,N registers
restore to some older values which makes this registers de facto unusable.

leo

Re: iteration (was Re: Angle quotes and pointy brackets)

[David Green]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Matt Diephouse) wrote:
>On Sat, 04 Dec 2004 08:59:24 -0700, David Green <[EMAIL PROTECTED]> wrote:

>C signifies a role named "Iterate". Roles are sort of a
>mix of interfaces and mixins (as I understand it -- I'm still waiting
>for E12). So saying a class fulfills a role just means that it
>provides certain methods. In this case, I was saying class with the
>Iterate role would provide a C<.next> method.

I thought of that at first, but I don't want to have to call my 
iterating method "next" any more than I want to *have* to call my 
constructor "new".  But there is a difference in that "new" is called 
by some user who is supposed to have read the documentation, whereas 
"next" needs to get implicitly called by "for".  

So maybe it really should be a Role.  (One can always provide methods 
with better names that simply call the "real" .next, .prev, .final, 
etc. for increased user-friendliness.)

&eof := &final;# is that how to create an alias for a sub/method?

> >We've got "while" for looping, ".next" for iterating,
> > and "for" for doing both in one convenient little shortcut.
>
>But for needs to know if it has an iterator or a list. You don't want
>it iterating over things you didn't want it iterating. In this case, I
>was suggesting making an, though I suppose something like
>C<$sth.execute> could just return one.

Well, I was looking at lists as being kinds of iterators. If you want 
to "for" over an iterator without actually iterating it, I guess 
you'd have to make a reference to it or put it inside a list (so the 
list would be iterated instead).


  - David "iterate: to go around and around, like my head" Green

Re: specifying the key Type for a Hash

[David Green]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Smylers) wrote:

>No!  Avoid synonyms.  They're initially tempting, because then everybody
>gets to pick the one he/she wants to use, but then it turns out you need
>to learn all of them so as to read other people's code, and that's worse
>than not having them at all.

In one way I agree, but I think there's a better (right!) way to use 
synonyms.  In natural language, you don't use a synonym to avoid 
learning some other word; you learn both and choose whichever one has 
the more appropriate connotations, the more suitable flavour under 
the given circumstances.  (Computers care only about denotations, so 
typical computer languages don't bother with synonyms, but that's one 
of the reasons why Perl has a better flavour than your typical 
language.)

Perl already has lots of synonyms, really: "zip" and "¥", "or" and "||", 
"unless" and "if not". Nobody learns <= *instead* of > -- you expect 
everyone to be familiar with both, and use whichever one reads better 
in its particular context.  So some synonyms (perhaps like "has" for 
"is") I'm all for: people would use both on a regular basis and I don't 
see any problem with that.

On the other hand, I do think your point applies to things like, say, 
suggesting "put" as a synonym for "unshift".  The only reason to do 
that is not to have to use "unshift" at all, but you have to know it 
anyway because if it's available, you're going to run into it sooner 
or later.



  - David "a rose by any other name would parse as sweet" Green

Re: [perl #27304] [PATCH] move libnci.def out of root directory

[Leopold Toetsch]

Will Coleda via RT <[EMAIL PROTECTED]> wrote:

> Can we get a ruling on this? I tend to agree with the statement
> "Random build files do not belong in the root directory".

There's a stricter rule too (IIRC proposed by Nick or Jarkko). No build
files in the Parrot tree, because this prevents a shared (possibly r/o)
source tree.

  Configure.pl --build-dir=xxx

with a reasonable default inside the tree would be better.

leo

Re: pull & put (Was: Angle quotes and pointy brackets)

[David Green]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Luke Palmer) wrote:

>But what we'd really like to do is: given the user knows what push/pop 
>do, what would they *guess* to mean shift (I tend to think that this 
>is a very good technique for naming).
>And, well, I'm thinking pull.  So it's a toss-up between shift/unshift
>and put/pull.

I think "push" and "pull" fairly naturally could be taken to refer to the 
front of an array; you might even argue that the natural direction for 
something to "pop" is away from you (i.e. off the back)

The problem I have with push/pull referring to opposite ends is that the 
same person is doing the pushing and the pulling, so both words ought to 
apply to the same end of the array (the front end), which violates the 
comp-sci-y expectations.  (And although normally I'm happy to chuck CS 
jargon out the window, because so much of it is really bad, the push/pop 
thing goes pretty deep.)  Not to mention everyone coming from Perl <6.  
Though if we had "push" without "pop", that wouldn't be as bad.

I guess we could always use prepend/append, pull/pop.  You might not guess 
what they meant, but once you know, I think the meanings are reasonably 
"obvious".  (Dislike typing though I may, I'm hesitant to suggest "prep" 
and "app".) 

Hm, actually counting letters,  "prepend" is no longer than "unshift" (and 
if not a real word, is at least used as one more often than "unshift" is).  
In fact, prepend/append/pull/pop altogether are only one letter more than 
push/pop/shift/unshift.  So those are now officially my preferred 
replacements.


But if we want something that makes it immediately obvious what end of the 
array we're messing with.. something visually obvious... ooh, this sounds 
like a job for Unicode!!  (Just kidding.  Sort of.)  We've already got 
those lovely pipe operators to build on, and they can already do 
assignment; if you can go from = to +=, why not from <== to +<==?

 @a <== $foo, $bar;   # @a=($foo, $bar)
 $foo, $bar ==> @a;   # ditto
 
 @a +<== $foo, $bar;  # push @a, $foo, $bar
 $foo, $bar ==>+ @a;  # unshift @a, $foo, $bar
 
 @a -==> $foo, $bar;  # ($bar, $foo) = (pop @a, pop @a)
 $foo, $bar <==- @a;  # ($foo, $bar) = (shift @a, shift @a)

The + or - tells you whether you're adding on or taking away, and the 
arrow points to (or from) the end of the array you're doing it to.  (I 
know some people will hate four symbols in a row.  That's why we have 
seven-letter alternatives like "prepend".)

I was going to say an advantage over old-fashioned pop/shift is that you 
could remove more than one element at a time, but there isn't any reason 
for their P6 versions not to return as many items as are want()ed, is 
there?

The bad news (assuming anyone actually thinks there's anything good in the 
above suggestion) is that since +<== and friends are assignment operators, 
you can't just do foobar( @a-==>, $x, $y).  Um, unless -==> could be made 
to work as a unary operator.  Which even I don't think I like.  =)  So we 
should keep the wordy versions too.



-David "pull goes the weasel" Green

Re: specifying the key Type for a Hash

[Luke Palmer]

David Green writes:
> In article <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED] (Larry Wall) wrote:
> >Maybe type parameters are just subscripts?  [...]
> >my Fight %fight does key{Dog;Cat};
> 
> I like that.

Yeah, me too.  Except I'm having trouble seeing how key is a role.  It's
not adding anything into a hash; it's changing it.  Maybe I just don't
quite grok roles yet.

> 
> >But if English-like is the criterion that'd still read better as
> >my Fight %fight has key{Dog;Cat};
> 
> I like that even better.
> 
> >Maybe "has" and "does" are just synonyms, and you can use
> >whatever makes more grammatical sense.  But pretty much every time
> >I've introduced synonyms into Perl I've come to regret it.  But hey,
> >if I introduce *different* synonyms this time, does that count as
> >making a new mistake?

Yeah, that's true.  But, on the other hand, "has" seems to have quite a
lot to do with roles:

class Foo {
has $.bar;   # compose in a .bar() method
}

Then you can think of a class as an elementary decomposition of roles.
That's algebralicious.  (And its one of those things I can imagine not
seeing the potential in until someone does something Profound with it).

> >Well, there's always "domain" and "range", if we want to be
> >mathematical.
> 
> I'm happy with those too (perhaps because I do want to be a bit 
> mathematical).

Remember what happened last time you gave something a mathematical name
that was wrong?  Yeah, vector ops.  And then everyone (read: me) carped
about them not being vector anything.

What you want here is "domain" and "codomain".  Which leads me to
believe that you don't want either.

Luke

Re: pull & put (Was: Angle quotes and pointy brackets)

[Smylers]

David Green writes:

> I guess we could always use prepend/append, pull/pop.

No!  C and C are a well-defined pair, not just in Perl, for
dealing with stacks; we should keep those as they are.  (And no
synonyms, before somebody suggests any!)

Smylers

Re: Premature pessimization

[Sam Ruby]

Leopold Toetsch wrote:
"correct". I've discovered and analysed the problem with continuations.
I've made a proposal to fix that. No one has said that it's technically
wrong or couldn't work. It seems you are liking the idea, but Dan
doesn't. Now what?
I would suggest focusing on one issue at a time and starting with 
writing a test case.

But, overall, it is clear that you are frustrated.  It show when you 
give responses like "Doesn't really matter" when people like me ask 
questions about your proposals.  That, in turn, makes people like me 
frustrated.

Re: classoffset... I don't currently use this opcode, nor do I plan to. 
 This opcode has a builtin assumption that attributes are stored as 
attributes.  They may in fact be methods or properties in the Parrot 
sense, or Property's in the Python sense.

Re: VTABLES... I disagree with you on this one.  Prematurely mapping an 
operation to a string is a premature pessimization.  Add to that the 
fact that such names can conflict with usages by languages of this 
runtime.  Overall, the design of the opcodes and PMC layout should focus 
on trying to retain as much information as possible.

Re: continuations... frankly, I'm hoping that a solution emerges that 
doesn't involve significant reduction in functionallity.  I might be 
misunderstanding you, but it sounds to me like you are proposing 
ditching lexical pads.

- Sam Ruby

Re: Premature pessimization

[Leopold Toetsch]

Ashley Winters wrote:
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote:
Leopold Toetsch writes:
This term came up in a recent discussion[1]. But I'd like to give this
term a second meaning.
Except what you're talking about here is premature *optimzation*.
You're expecting certain forms of the opcodes to be slow (that's the
pessimization part), but then you're acutally using opcodes that you
think can be made faster.  This is a classic Knuth example.

So the sequence of using classoffset/getattribute is a _feature_
necessary for completeness, rather than a "pessimization" to
compensate for the belief that not explicitly caching would be
hopelessly slow? Ahh. I'm learning much. :)

On a semi-related note, can I get a classoffset without doing a hash
lookup?  That is, can I store the class number I get assigned somewhere
for quick fetching?
*SCNR* - leo

Re: [perl #27304] [PATCH] move libnci.def out of root directory

[Leopold Toetsch]

Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> Will Coleda via RT wrote:
>> Can we get a ruling on this? I tend to agree with the statement "Random 
>> build files do not
>> belong in the root directory".
>>
>> The patch has been un-ACK'd for nine months at the moment.

> While we are at it, shouldn't we rename 'libnci.so' and 'libnci.def' to
> 'libnci_test.so' and 'libnci_test.def'. The library isn't used for NCI
> support, but for testing NCI support.

Yep.

> CU, Bernhard

leo

Re: Premature pessimization

[Leopold Toetsch]

Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>>
>> "correct". I've discovered and analysed the problem with continuations.
>> I've made a proposal to fix that. No one has said that it's technically
>> wrong or couldn't work. It seems you are liking the idea, but Dan
>> doesn't. Now what?

> I would suggest focusing on one issue at a time and starting with
> writing a test case.

> But, overall, it is clear that you are frustrated.

... a bit by the lack of progress that can be achieved to e.g. fix
broken continuation behavior. But not much ;)

> ... It show when you
> give responses like "Doesn't really matter" when people like me ask
> questions about your proposals.  That, in turn, makes people like me
> frustrated.

Well, you worried about different classes having identical method names,
but the methods do different things. I asked why this is a problem. I
gave an example. Here is one more:

  obj."__set_integer_native"(10)

does 2 totally different things for arrays (set array size) or for
scalars (assign value 10).

> Re: VTABLES... I disagree with you on this one.  Prematurely mapping an
> operation to a string is a premature pessimization.

Except that we are doing that already. Please read through
classes/delegate.c. The problem is that this scheme doesn't work for
MMD of real objects.

> ... Add to that the
> fact that such names can conflict with usages by languages of this
> runtime.

Parrots method names (two leading underscores + vtable name) are
reserved. And again, when two distinct clases use the same method name
this is no conflict at all. Issues with classes in an inheritance chain
are easily avoided by following that convention.

> ... Overall, the design of the opcodes and PMC layout should focus
> on trying to retain as much information as possible.

Nothing get lost. Visible opcodes don't change. An example

 .sub m
  $P0 = newclass "Foo"
  $I0 = find_type "Foo"
  .local pmc obj
  obj = new $I0
  obj = 5
 .end

running that snippet gives:

Can't find method '__set_integer_native' for object 'Foo'.

The vtable method set_integer_native clearly maps to a real method that
can be either inherited or be provided by the user. This doesn't work
for MMD functions.

> Re: continuations... frankly, I'm hoping that a solution emerges that
> doesn't involve significant reduction in functionallity.  I might be
> misunderstanding you, but it sounds to me like you are proposing
> ditching lexical pads.

No. I'm not ditching lexical pads at all. They are of course needed. The
top pad is in the registers. Outer pads are looked up as usual.

> - Sam Ruby

leo

Re: Arglist I/O [Was: Angle quotes and pointy brackets]

[Austin Hastings]

Larry Wall wrote:
But here's the kicker.  The null filename can again represent the
standard filter input, so we end up with Perl 5's
   while (<>) {...}
turning into
   for =<> {...}
 

Two more issues: idiom, and topification
= Topification:
There are cases in P5 when I *don't* want
 while (<>) {...}
but prefer
 while ($input = <>) {...}
so that I can have something else be the topic. Every example to date 
has used C:

 for .lines {...}
but that sets the topic. I'm a little fuzzy on this, but doesn't C 
play topic games even in this?

 for .lines -> $input { ... $input ... }
That is, even though "$_" remains unaffected, doesn't this affect 
smartmatch etc.?

= Idiom:
The other concern is idiom. Using C suggests "start at the 
beginning, continue to the end". OTOH, using C is a little 
"weaker" -- "keep doing this until it's time to stop". Obviously they'll 
usually be used in the same way:

for =<> {...}   vs. while (<>) {...}
This seems a subtle concern, and maybe it's just my latent fear of 
change making me uncomfortable, but I actually *think* in english -- not 
that it does much good -- and this isn't how I think.

Can we ditch C in the examples in favor of C, for a while? :)
=Austin

Re: pull & put (Was: Angle quotes and pointy brackets)

[Austin Hastings]

Smylers wrote:
Larry Wall writes:
 

But then are we willing to rename shift/unshift to pull/put?
   

Yes.  C is a terrible name; when teaching Perl I feel
embarrassed on introducing it.
 

No!
But I'd be willing to rename them to get/put.
'Pull' is the opposite of 'push', but 'pop' already works.
Given the nature of many of the other changes in Perl 6, completely
changing regexps for example, renaming a couple of functions seems
minor.
 

Agreed.
Smylers
 

=Austin

Re: Premature pessimization

[Sam Ruby]

Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
"correct". I've discovered and analysed the problem with continuations.
I've made a proposal to fix that. No one has said that it's technically
wrong or couldn't work. It seems you are liking the idea, but Dan
doesn't. Now what?

I would suggest focusing on one issue at a time and starting with
writing a test case.

But, overall, it is clear that you are frustrated.
... a bit by the lack of progress that can be achieved to e.g. fix
broken continuation behavior. But not much ;)
My philosophy is simple: things without test cases tend not not get 
fixed, and when fixed, tend not to stay fixed.

... It show when you
give responses like "Doesn't really matter" when people like me ask
questions about your proposals.  That, in turn, makes people like me
frustrated.
Well, you worried about different classes having identical method names,
but the methods do different things. I asked why this is a problem. I
gave an example. Here is one more:
  obj."__set_integer_native"(10)
does 2 totally different things for arrays (set array size) or for
scalars (assign value 10).
I am worried about Parrot trying to establish common public names for 
common functions.  Many of the examples you gave did not include the 
prerequisite double underscores.  For example: "sub", "imag", "eof". 
These names are not likely to have a commmon behavior across all languages.

Re: VTABLES... I disagree with you on this one.  Prematurely mapping an
operation to a string is a premature pessimization.
Except that we are doing that already. Please read through
classes/delegate.c. The problem is that this scheme doesn't work for
MMD of real objects.
I don't know enough to have an informed opinion yet on MMD.  But 
__set_integer_native is not a MMD operation.  It already is efficiently 
dispatched to the correct method.  What do we benefit from the premature 
pessimisation of mapping this to a string?

... Add to that the
fact that such names can conflict with usages by languages of this
runtime.
Parrots method names (two leading underscores + vtable name) are
reserved. And again, when two distinct clases use the same method name
this is no conflict at all. Issues with classes in an inheritance chain
are easily avoided by following that convention.
Again, my point is that the examples need to follow that convention. 
Without exception.

... Overall, the design of the opcodes and PMC layout should focus
on trying to retain as much information as possible.
Nothing get lost. Visible opcodes don't change. An example
 .sub m
  $P0 = newclass "Foo"
  $I0 = find_type "Foo"
  .local pmc obj
  obj = new $I0
  obj = 5
 .end
running that snippet gives:
Can't find method '__set_integer_native' for object 'Foo'.
The vtable method set_integer_native clearly maps to a real method that
can be either inherited or be provided by the user. This doesn't work
for MMD functions.
Again, set_integer_native is not an MMD function?
Re: continuations... frankly, I'm hoping that a solution emerges that
doesn't involve significant reduction in functionallity.  I might be
misunderstanding you, but it sounds to me like you are proposing
ditching lexical pads.
No. I'm not ditching lexical pads at all. They are of course needed. The
top pad is in the registers. Outer pads are looked up as usual.
I guess I don't understand.  I guess it is time for a test case.  ;-)
How would the following work if the top pad is in registers?
  var = 1
  def g():
global var
var = 2
  print "before", var
  g()
  print "after", var
Such behavior is the default for perl5:
  my $var = 1;
  sub g {
$var = 2;
  }
  print "before $var\n";
  g();
  print "after $var\n";
- Sam Ruby

Re: Arglist I/O [Was: Angle quotes and pointy brackets]

[David Wheeler]

On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote:
   for =<> {...}
I dub the...the fish operator!
:-)
David

Re: specifying the key Type for a Hash

[Larry Wall]

On Mon, Dec 06, 2004 at 05:43:16AM +, Nigel Sandever wrote:
: I probably missed teh comprehensive dismissal thread, but why not 'type'?
: 
:   my %pet is Hash[:type(Str) :returns(Cat)];

Well, "type" is just a little off in a couple of ways.  On the one hand,
it's not specific enough, insofar as there are several different
types involved.  On the other hand, it's too specific, insofar as what
you're specifying there is not a type, but something more like a signature,
albeit one without parameters.  It's more like the attachment on a
multi to pick one of a set: &abs.

That says to me that what we're really looking at is

my Cat %pet is sig(Str);
my @matrix is sig(int where 0..3, int where 0..3);

where those might be abbreviated as:

my Cat %pet (Str);
my %matrix (3,3);

or

my Cat %pet .{Str};
my %matrix .[3;3];

or maybe even

my Cat %pet{Str};
my %matrix[3;3];

Which says that

my sub foo ($a) {...}

is maybe short for

my sub foo .($a) {...}

Hmm.  Also says maybe you could attach a block to a hash or array to
define what subscripting does.  Hmm.

Larry

Re: Arglist I/O [Was: Angle quotes and pointy brackets]

[Larry Wall]

On Mon, Dec 06, 2004 at 09:06:22AM -0800, David Wheeler wrote:
: On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote:
: 
: >>   for =<> {...}
: 
: I dub the...the fish operator!
: 
: :-)

Mmm.  Next thing you'll know, people will name their files oddly just so
they can write things like:

for = {...}

for =<|||'> {...}

for =<###*> {...}

for =<]]]°> {...}

for =<)))º> {...}

Larry

Re: [perl #32877] parrot build broken in Tru64, cc/ld confusion

[Andrew Dougherty]

On Sun, 5 Dec 2004, Jarkko Hietaniemi wrote:

> I am pretty certain that parrot was building fine in Tru64 back in
> 2004/11/07 15:12:42 when I submitted a patch (directly to CVS)
> for jit/alpha/jit_emit.h to get alpha JITing to compile at all.
>
> Since then something has broken building parrot in Tru64.  What happens
> is that dynclasses/build.pl attempts something called a "partial
> link" for the various Python-related objects, and the attempt fails
> because it tries to invoke "ld" with parameters meant exclusively for
> the native "cc" (or the C++ compiler "cxx"):
>
> ld -std -D_INTRINSICS -fprm d -ieee -I/p/include -DLANGUAGE_C -pthread
> -g   -DHAS_JIT -DALPHA-L/p/lib -shared -expect_unresolved "*" -O4
> -msym -std -s -L/p/lib ../src/extend.o -o python_group.so
> lib-python_group.o pybuiltin.o pyobject.o pyboolean.o pyclass.o
> pycomplex.o pydict.o pyfloat.o pyfunc.o pygen.o pyint.o pylist.o
> pylong.o pymodule.o pynone.o pytype.o pystring.o pytuple.o
> ld: Badly formed hex number: -fprm
> ld: Usage: ld [options] file [...]
> partial link python_group.so failed (256)
>
> If "ld" in the above is replaced with "cc", things work fine.

The offending line in config/gen/makefiles/dynclasses_pl.in
is probably this one:

$LD $CFLAGS $LDFLAGS $LD_LOAD_FLAGS $LIBPARROT

That CFLAGS doesn't belong there.  CFLAGS are intended to be sent to $CC,
not to $LD. The command being called here is $LD, which is defined in
config/init/data.pl as the "Tool used to build shared libraries and
dynamically loadable modules."

I no longer remember why LD is set to 'ld' on Tru64 -- is it just Ultrix
heritage combined with lots of inertia or is it really a sensible setting?

In any case, dynclasses_pl.in is wrong.  There should be no CFLAGS there.

-- 
Andy Dougherty  [EMAIL PROTECTED]

Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

[Larry Wall]

On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: Two more issues: idiom, and topification
: 
: = Topification:
: 
: There are cases in P5 when I *don't* want
: 
:  while (<>) {...}
: 
: but prefer
: 
:  while ($input = <>) {...}
: 
: so that I can have something else be the topic. Every example to date 
: has used C:
: 
:  for .lines {...}
: 
: but that sets the topic. I'm a little fuzzy on this, but doesn't C 
: play topic games even in this?
: 
:  for .lines -> $input { ... $input ... }
: 
: That is, even though "$_" remains unaffected, doesn't this affect 
: smartmatch etc.?

Currently it does.  There have been some rumblings in the design team
that maybe it shouldn't.  But it occurs to me that this might be another
spot to have our cake and eat it to.  We could say that

for @foo -> $input { ... $input ... }

doesn't set the topic in the block by default.  However, methods do set
the topic (though there have been rumblings about that too).  So we could
simply say that pointy subs can also be pointy methods if you specify
an invocant:

for @foo -> $input: { ... $input and $_ ... }

I think I like that, but it needs to be thunk about some more.  The downside
is that it's rather subtle.  The upside is that it falls out of existing
rules, and lets -> map more naturally in the way people expect.  I don't
think people will naturally expect -> to clobber $_.

Larry

while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

[Larry Wall]

On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: = Idiom:
: 
: The other concern is idiom. Using C suggests "start at the 
: beginning, continue to the end". OTOH, using C is a little 
: "weaker" -- "keep doing this until it's time to stop". Obviously they'll 
: usually be used in the same way:
: 
: for =<> {...}   vs. while (<>) {...}
: 
: This seems a subtle concern, and maybe it's just my latent fear of 
: change making me uncomfortable, but I actually *think* in english -- not 
: that it does much good -- and this isn't how I think.
: 
: Can we ditch C in the examples in favor of C, for a while? :)

Okay.  Have an example:

while =$IN -> $line {...}

I think that works.  I'm back to thinking unary = in scalar context iterates
like p5's <>, and you should use extraordinary means to get extraordinary
results:

while file $IN -> $blob {...}
while slurp $IN -> $bigblob {...}

Larry

Re: Arglist I/O [Was: Angle quotes and pointy brackets]

[Larry Wall]

Or even the dead fish operator:

while =<###x> -> $net {...}

And here's a flounder:

while =<:>

Larry

Re: pull & put (Was: Angle quotes and pointy brackets)

[Larry Wall]

On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote:
: But I'd be willing to rename them to get/put.

If I went with "get", the opposite would be "unget" for both historical
and huffmaniacal reasons.

Larry

Re: [perl #32877] parrot build broken in Tru64, cc/ld confusion

[Sam Ruby]

Andrew Dougherty wrote:
The offending line in config/gen/makefiles/dynclasses_pl.in
is probably this one:
$LD $CFLAGS $LDFLAGS $LD_LOAD_FLAGS $LIBPARROT
That CFLAGS doesn't belong there.  CFLAGS are intended to be sent to $CC,
not to $LD. The command being called here is $LD, which is defined in
config/init/data.pl as the "Tool used to build shared libraries and
dynamically loadable modules."
I can't find anything that fails if this is removed, so I committed the 
change.

- Sam Ruby

Re: Arglist I/O [Was: Angle quotes and pointy brackets]

[Austin Hastings]

David Wheeler wrote:
On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote:
   for =<> {...}

I dub the...the fish operator!
:-)
Back before there was a WWW, I used an editor called "tgif". It was 
written in france, and part of the idiom was to have two GUI buttons 
showing respectively the head ("  <* ") and tail (" >( ") parts of a 
fish. This were graphical images, please forgive my poor ascii drawing.

It took me a while to figure it out, but it was a cute bit of 
bilingualism. (Or perhaps it was a bit of bilingual cute-ism...)

=Austin

Re: while Idiom (Was: Arglist I/O)

[Smylers]

Austin Hastings writes:

> The other concern is idiom. Using C suggests "start at the 
> beginning, continue to the end". OTOH, using C is a little 
> "weaker" -- "keep doing this until it's time to stop". Obviously they'll 
> usually be used in the same way:
> 
> for =<> {...}   vs. while (<>) {...}
> 
> This seems a subtle concern, and maybe it's just my latent fear of 
> change making me uncomfortable, but I actually *think* in english -- not 
> that it does much good -- and this isn't how I think.

I think that C reads much better than C for English-ness.
Having taught Perl 5 beginners that C can be used to iterated
over each item in a list, many of them then instinctively try to use the
same keyword for iterating over each line in a file.  (Which of course
works -- albeit inefficiently and umidiomatically -- so they don't
bother looking any further.)

To me C makes sense when you've got a pile of stuff you're
intending to process (such as array items or lines in a file), and
C makes sense when you're waiting for a condition (such as the
user correctly entering her/his password) and you couldn't possibly know
in advance how many times you'll be looping.

Smylers

Re: specifying the key Type for a Hash

[Abhijit Mahabal]

On Mon, 6 Dec 2004, Larry Wall wrote:
Hmm.  Also says maybe you could attach a block to a hash or array to
define what subscripting does.  Hmm.
That's tantalizing. Did you have something like this in mind:
# Count number of accesses to each key
our %counter_hash;
my %hash is subscripted
   -> $subscript { %counter_hash{$subscript}++; %hash{$subscript} };
Or even:
# Provide a "view" of the hash
my %hash is subscripted
   -> $address { %hash{address_to_zipcode($address)}};
so that users can think that they are accessing %hash{"Bloomington, IN"} 
when they are really accessing %hash{47401}.

Or scarier, using MMD-like stuff (I am not even thinking about syntax) we 
get different things based on the signature of the key, giving us the 
ability to differentiate between %hash{$Dog} or %hash{$Vet}.

And pretty soon somebody will define an accessor for the signature 
(SQL_Query $s).

It seems to me that this idea is not very far away from P5 "tying", but I 
may be wrong. If it is not very far away, maybe we can even have:

my %hash is subscripted -> $s{
FETCH {...}
STORE {...}
}
Crazy stuff. I don't know if it is doable or even desirable, but it sure 
is cool!


Larry
--abhijit
Abhijit Mahabal  http://www.cs.indiana.edu/~amahabal/

Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

[Luke Palmer]

Larry Wall writes:
> Currently it does.  There have been some rumblings in the design team
> that maybe it shouldn't.  But it occurs to me that this might be another
> spot to have our cake and eat it to.  We could say that
> 
> for @foo -> $input { ... $input ... }
> 
> doesn't set the topic in the block by default.  However, methods do set
> the topic (though there have been rumblings about that too).  So we could
> simply say that pointy subs can also be pointy methods if you specify
> an invocant:
> 
> for @foo -> $input: { ... $input and $_ ... }
> 
> I think I like that, but it needs to be thunk about some more.  The downside
> is that it's rather subtle.  The upside is that it falls out of existing
> rules, and lets -> map more naturally in the way people expect.  I don't
> think people will naturally expect -> to clobber $_.

Considering that I was the rumbler, I'll try to stay concise.  Don't
think that this is anything more than a stormy brain, though.

I really like the fact that for always topicalizes. I like it because
it forces refactors where they ought to be happening.  I always get
confused when I see:

for (@array) {
for my $row (@{$data->[$_]}) {
for my $element (@$row) {
foobar($_) if $element;
}
}
}

It works that way in natural languages too.  If you try to use "it" too
remotely, you just confuse everybody.  In particular:

For each element in @array, look up the corresponding $row in $data,
and for each $element in the $row, call foobar on it if $element is
true.

Call foobar on what?

The remaining problem is what to do about unary dot.  Repeated here for
the, er, benefit? of p6l:

class Duple {
has $.left;
has $.right;

method perform (&oper) {
&oper($.left);
&oper($.right);
}
}

Let's change that into a Tuple class:

class Tuple {
has @.elems;

method perform (&oper) {
for @.elems {
.perform($_);
}
}
}

Can you find the mistake?

Luke

Re: while Idiom (Was: Arglist I/O)

[Luke Palmer]

Smylers writes:
> To me C makes sense when you've got a pile of stuff you're
> intending to process (such as array items or lines in a file), and
> C makes sense when you're waiting for a condition (such as the
> user correctly entering her/his password) and you couldn't possibly know
> in advance how many times you'll be looping.

And iterating over lines in a file is kind of between the two.  Since
both while and for work just as efficiently, and they're both just as
clear (we see that Austin thinks while is clearer than for, and I think
the opposite), I think it's great that you can use both.

Luke

Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

[Jonathan Scott Duff]

On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote:
> On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
> : Can we ditch C in the examples in favor of C, for a while? :)
> 
> Okay.  Have an example:
> 
> while =$IN -> $line {...}
> 
> I think that works.  I'm back to thinking unary = in scalar context iterates
> like p5's <>

What would these do?

while =$IN -> $l1,$l2 {...}
while =$IN -> @x {...}

That first one seems particularly useful.  I'm not exactly sure what
the second one should do, but it seems like it should be similar to
{ my @x = $IN.slurp; ... }

Can it be that unary = in n-ary context iterates like p5's <> except
when n == Inf or n == 0 (which are list and void context I guess) ?

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: pull & put (Was: Angle quotes and pointy brackets)

[Dan Brian]

If I went with "get", the opposite would be "unget" for both historical
and huffmaniacal reasons.
But "get" has too strong a class accessor connotation in most OO.
"unpull?" ;-)

Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

[Larry Wall]

On Mon, Dec 06, 2004 at 12:45:18PM -0600, Jonathan Scott Duff wrote:
: On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote:
: > On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: > : Can we ditch C in the examples in favor of C, for a while? :)
: > 
: > Okay.  Have an example:
: > 
: > while =$IN -> $line {...}
: > 
: > I think that works.  I'm back to thinking unary = in scalar context iterates
: > like p5's <>
: 
: What would these do?
: 
:   while =$IN -> $l1,$l2 {...}
:   while =$IN -> @x {...}
: 
: That first one seems particularly useful.  I'm not exactly sure what
: the second one should do, but it seems like it should be similar to
: { my @x = $IN.slurp; ... }

The C statement is not an arbiter of lists.  It want a scalar
value that can play the bool role.  Assuming that $IN is really $*IN,
they would both fail because you're trying to bind a scalar string
to a signature that doesn't accept a single scalar string.  It would
be exactly like

sub foo($I1, $I2) {...}
foo("#!/usr/bin/perl\n");   # missing $I2

sub bar(@x) {...}
bar("#!/usr/bin/perl\n");   # Trying to bind non-string to @x

That being said, if =$iterator returns a list of array references, the
second one would work.  I don't see any way to make the first one work.

: Can it be that unary = in n-ary context iterates like p5's <> except
: when n == Inf or n == 0 (which are list and void context I guess) ?

You mean slurps all the values and then throws away all but n of them?
That's how p5's <> currently behaves.  Or did you mean scalar <>?

In any event, I don't think C is ever going to provide an n-ary
context to whatever it wants a boolean value from.  That's what C
is for.

Larry

Re: while Idiom (Was: Arglist I/O)

[Elyse M. Grasso]

On Monday 06 December 2004 01:26 pm, Smylers wrote:

> I think that C reads much better than C for English-ness.
> Having taught Perl 5 beginners that C can be used to iterated
> over each item in a list, many of them then instinctively try to use the
> same keyword for iterating over each line in a file.  (Which of course
> works -- albeit inefficiently and umidiomatically -- so they don't
> bother looking any further.)
> 
> To me C makes sense when you've got a pile of stuff you're
> intending to process (such as array items or lines in a file), and
> C makes sense when you're waiting for a condition (such as the
> user correctly entering her/his password) and you couldn't possibly know
> in advance how many times you'll be looping.
> 
> Smylers
> 
> 
But you need to process the file while you haven't reached the end yet, or 
until you reach the end. And I can't think of an occasion where I knew going 
in what the length of the file I was processing was going to be. I suppose 
foreach might make sense if you sucked in the whole file at once and then 
processed the individual lines, but I've seldom been in situations where I 
could assume it was safe to do that. (Data expands to fill the space 
available, plus 10 %... and the production data file is always bigger than 
they told you it would be.)

The same goes for database queries: you loop while the query is returning data 
or until it stops returning data.

Foreach implies to me that you want to do the same thing, or something very 
similar, to each of the things you are processing. But in handling the lines 
of a file or the records returned by a query you may in fact want to throw 
many of them away, or handle various subgroups of data in different ways.

-- 
Elyse Grasso

http://www.data-raptors.comComputers and Technology
http://www.astraltrading.com   Divination and Science Fiction

Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

[Jonathan Scott Duff]

On Mon, Dec 06, 2004 at 10:59:18AM -0800, Larry Wall wrote:
> On Mon, Dec 06, 2004 at 12:45:18PM -0600, Jonathan Scott Duff wrote:
> : On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote:
> : > On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
> : > : Can we ditch C in the examples in favor of C, for a while? 
> :)
> : > 
> : > Okay.  Have an example:
> : > 
> : > while =$IN -> $line {...}
> : > 
> : > I think that works.  I'm back to thinking unary = in scalar context 
> iterates
> : > like p5's <>
> : 
> : What would these do?
> : 
> : while =$IN -> $l1,$l2 {...}
> : while =$IN -> @x {...}
> : 
> : That first one seems particularly useful.  I'm not exactly sure what
> : the second one should do, but it seems like it should be similar to
> : { my @x = $IN.slurp; ... }
> 
> The C statement is not an arbiter of lists.  

Okie.

> In any event, I don't think C is ever going to provide an n-ary
> context to whatever it wants a boolean value from.  That's what C
> is for.

Somehow I knew you were going to say that.  I'm just being reluctant
to use C for something I've been using C for all this time.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Premature pessimization

[Leopold Toetsch]

Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:

> My philosophy is simple: things without test cases tend not not get
> fixed, and when fixed, tend not to stay fixed.

There is of course a test case. I have mentioned it at least 20 times ;)
t/op/gc_13.imc - currently using lexicals.

> I am worried about Parrot trying to establish common public names for
> common functions.  Many of the examples you gave did not include the
> prerequisite double underscores.  For example: "sub", "imag", "eof".

Ah ok. Sorry. "__subtract". OTOH some might be that common and the usage
is the same in all languages that we might use that common name. But
that's probably not worth the effort. So yes, we should establish the
notion that all methods follow that convention.

>>>Re: VTABLES... I disagree with you on this one.  Prematurely mapping an
>>>operation to a string is a premature pessimization.
>>
>> Except that we are doing that already. Please read through
>> classes/delegate.c. The problem is that this scheme doesn't work for
>> MMD of real objects.

> I don't know enough to have an informed opinion yet on MMD.  But
> __set_integer_native is not a MMD operation.  It already is efficiently
> dispatched to the correct method.

For PMCs yes. For objects not efficiently and only with a separate
delegate meta-class.

> ... What do we benefit from the premature
> pessimisation of mapping this to a string?

Well, method names happen to be strings ;)

Anyway, I'll try to summarize our current method dispatch scheme:

   vtableMMD  NCI method
 -
 opcodeset P0, 4 add P0, P1, P2   io."__eof"()
 -
 PMC   pmc->vtable->..   mmd_dispatch_*   callmethod
 objectdelegate.c  1) callmethod
 object(PMC)   deleg_pmc.c 1) callmethod

NCI methods are working, the method lookup is dynamic, inheritance
works.

MMD inheritance is totally static (set up during PMC compilation).
PMCs dispatch with the mmd_dispatch_* functions in ops/*.ops.
1) overloading a MMD infix operation needs the mmdvtregister opcode, but
this does not effect any class inheritance and it's just for the given
two types.
Multi-dimensional MD is not implemented.

For vtables objects and objects derived from PMCs use two helper classes
that bridge the dynamic inheritance of objects to the static inheritance
in PMCs. This doesn't support runtime overloading of methods that
defaulted to the PMC method.

Looking at 5 different schemes that work for ~50% of the cases can -
well - make one pessimistic ;)

I'm proposing that *internally* (implementation detail ...) one scheme
should be enough. Again: the opcodes don't change.

>> The vtable method set_integer_native clearly maps to a real method that
   
>> can be either inherited or be provided by the user. This doesn't work
>> for MMD functions.

> Again, set_integer_native is not an MMD function?

__set_integer_native is a vtable method.

>> No. I'm not ditching lexical pads at all. They are of course needed. The
>> top pad is in the registers. Outer pads are looked up as usual.

> I guess I don't understand.  I guess it is time for a test case.  ;-)
> How would the following work if the top pad is in registers?

The top pad is always the currently executing one.

>var = 1
>def g():
>  global var
>  var = 2

>print "before", var
>g()
>print "after", var

It's obviously up to the "global" to do the right thing. My impression
(I don't have more Python knowledge ;) is, that "global" refers to the
outermost lexical pad in the main module.

> Such behavior is the default for perl5:

>my $var = 1;
>sub g {
>  $var = 2;
>}

As there is no "my $var" in the inner pad, that's just a C
opcode. It follows the C pointer to the outer pad and finds in the
lexical hash the "$var" which maps to a position in the register store
of the outer pad.

"my ($a, $b)" in the innermost pad (in sub g) would map directly to
registers as "my $var" maps to a register in "main" (in the outer pad).

It's the same as currently, except that we have now a separate array
that holds the lexicals. I was just mapping that array into the
preserved area of registers, which would make this area of course
variable-sized with the nice benefit that "my int $i" also works (we
don't have natural int lexicals currently).

> - Sam Ruby

leo

Re: pull & put (Was: Angle quotes and pointy brackets)

[Rod Adams]

Dan Brian wrote:
If I went with "get", the opposite would be "unget" for both historical
and huffmaniacal reasons.

But "get" has too strong a class accessor connotation in most OO.
"unpull?" ;-)

pushf/popf.  f is for "front".
But I still don't see anything wrong with shift/unshift.
I'd prefer to avoid having a group of words that all mean about the same 
thing, but keeping them straight requires some memory trick. I program 
in too many languages to keep my mnemonics straight. There's going to be 
enough fun with is/has/does/but. For reference, I always have to do a 
'perldoc perlvar' when I need a P5 $.

-- Rod Adams

slight discrepancy between S2 and S7

[Stéphane Payrard]

S2:

my $foo = 42;
say %MY::<$foo>;# prints "42"

S6:

 Perl5ish subroutine declarations
 ...
 sub say { print qq{"@_"\n}; }   # args appear in @_


Because C has no final newline, I would expect C will have
one.  Final newline or not. What is your say?


--
 stef

Re: pull & put (Was: Angle quotes and pointy brackets)

[Jonathan Scott Duff]

On Mon, Dec 06, 2004 at 01:25:29PM -0600, Rod Adams wrote:
> Dan Brian wrote:
> 
> >>If I went with "get", the opposite would be "unget" for both historical
> >>and huffmaniacal reasons.
> >
> >
> >But "get" has too strong a class accessor connotation in most OO.
> >
> >"unpull?" ;-)
> >
> >
> pushf/popf.  f is for "front".

Ew!  I'd prefer :head/:tail modifiers to push/pop over that. But ...

> But I still don't see anything wrong with shift/unshift.

Neither do I.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: pull & put (Was: Angle quotes and pointy brackets)

[Larry Wall]

On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote:
: >If I went with "get", the opposite would be "unget" for both historical
: >and huffmaniacal reasons.
: 
: But "get" has too strong a class accessor connotation in most OO.
: 
: "unpull?" ;-)

Given the existence of a unary = for abbreviated use, I'd probably
stick with shift/unshift.  (Presumably changing the semantics of
shift from p5 to be list/scalar/n-ary context sensitive, so you'd
have to write "scalar shift" to get Perl 5's shift semantics
in list context.)

Though it's awfully tempting to fill in the holes in the periodic table:

($a, $b, $c) = @foo *<< 3;

And then just say all the corresponding unaries default to 1 (or the arity
of the left):

$bit = +<< $number; # $number +<< 1
$graph = ~<< $string;   # chip()/chimp()
$whether = ?<< $boolean;# presumably clears $boolean
$elem = *<< $iterator;  # shift $iterator

That would mean that we couldn't use those unaries in front of <<...>> though.

I suppose unary *>> would mean pop.  Blurch.  Let's stick with the binaries,
if we add 'em at all.  I do think

foo( @bar *<< 3 )
foo( @bar *>> 3 )

might actually be clearer than

foo( splice(@bar,0,3) )
foo( splice(@bar,-3,3) )

Also, note that neither of the latter examples means the same as

foo( pop(@bar,3) )

since pop would presumably pop them in reverse order from splice.

We also get all the rotates if we allow *<<< and *>>>.

On the other hand, if anyone suggests a list xor:

@foo *^ @bar

I'll ask whether they mean

@foo »+^« @bar
@foo »~^« @bar
@foo »?^« @bar
@foo »*^« @bar

Larry

Re: specifying the key Type for a Hash

[Larry Wall]

On Mon, Dec 06, 2004 at 03:11:15AM -0700, David Green wrote:
[snip]
: I like that.
[snip]
: I like that even better.
[snip]
: I'm happy with those too (perhaps because I do want to be a bit 
: mathematical).
[snip]
: "is FAT"?  Yeah, that works for me too.  =)
[snip]
: I would take that as an abbreviation and read it as "is dimensioned", 
: which is English-like enough for me.
[snip]
: But "shape" *is* prettier.

Um.  You're so very...easy to please...  I guess I'm okay with that...

Larry

Re: iterators and functions (and lists)

[Larry Wall]

On Sun, Dec 05, 2004 at 12:05:46AM +, Matthew Walton wrote:
: I'm sorry, but from a C++ background, overriding postcircumfix:<( )> 
: feels far more natural to me than setting 'is default' on some method. 

That only works for disambiguation if you know which .() to call in
the first place.  It seems likely that that .() maps straight to MMD
and doesn't look for a singly dispatched .() at all.  But maybe I'm
just not understanding this.

: What if you do 'is default' on two methods? Compile-time error?

Syntactically legal, and semantically legal if they have different MMD
signatures.  Otherwise a compile time error if the compiler can catch
it then, but I wouldn't require a compiler to do so if it's onerous.
Seems like it ought to be pretty easy though, if one has a way of
doing a "test" dispatch without really dispatching, and we need something
like that to resolve a reference like &abs.

: What if 
: you're opening up someone else's class and want to override the existing 
: default (okay, so you shouldn't be doing that in an OOP world, but what 
: if you are? What if you're like me and like Perl's delightful mishmash 
: of paradigms while simultaneously liking other languages for their 
: purity? What if I actually talk about something relevant?)

I suppose you could always wrap it instead.  What you're talking about
already sounds suspiciously like Aspect Oriented Programming.

: >: # other thingies:
: >: 
: >:  sub foo { ... };
: >:  @array = @&foo # all the results of foo, lazily.
: >
: >Don't see the need for that when
: >
: >@array := foo()
: >
: >does laziness implicitly already.  Maybe even
: >
: >@array = foo()
: >
: >maintains laziness if it sees an infinite iterator in the return
: >value of foo().  Or maybe it blows up and tells you to use ":="
: >to avoid trying to make a copy.  That's probably cleaner.
: 
: This is going to take me a while to get my head round... Does this 
: particular foo() return an iterator? Or is it something which is 
: iterated? Have I missed a bit of a synopsis or apocalypse which would 
: make all this clear to me or are we still in handwaving mode?

Any foo() can return a list.  That list can be a Lazy list.  So the
ordinary return can say:

return 0...;

to return an infinite list, or even

return 0..., 0...;

to return a surreal list.  Either of those may be bound to an array
as its "generator of missing values".  Assignment sort of implies
copying, but I'm just saying that the copier could also be smart
at least about infinities or indefinities (ohh, a cool new word),
even if it flattens everything else.

: >Exceptions should not be used for
: >something so mundane as running out fo values.
: 
: Amen to that! One reason I ran screaming from Java was having to catch 
: ArrayOutOfBoundsException all the time. And all those exceptions which 
: the compiler forces you to catch. They're handy, but there is a limit. I 
: prefer return values which can indicate if they're valid or not. undef 
: is excellent for that :-)
: 
: A string pretending to be undef can be even better. Can we still do 
: that? I seem to recall it being in something at some point along the way.

An object can play the Undef role.  Or maybe undef can play Ref role.
In any event, since a string is an object, the answer is "Yes, but
an unthrown Exception object that can stringify would be better..."

: >If that's necessary to keep the Lazy from blocking when it runs out
: >of values.  Just like an ordinary array, a Lazy has to be aware of
: >when it is out of values, and when it should call into some meta-Lazy
: >for more iterator values.  And I suppose that meta-Lazy could in
: >turn have a meta-meta-Lazy, which could have a meta-meta-meta-Lazy,
: >and now my brane hurts.
: 
: And soon your entire program consists of code which may or may not ever 
: be evaluated. Welcome to Haskell :-)

Next thing you'll be telling me is that all this partially evaluated
code shouldn't have any side effects.  :-)

Larry

Re: C implementation of Test::Harness' TAP protocol

[Michael G Schwern]

Keeping in mind I'm not a C programmer so my user expectations may be
all wrong.


On Mon, Dec 06, 2004 at 10:00:32AM -, Clayton, Nik wrote:
> Then you have one of ok() or ok2() at your disposal.  ok()'s first parameter
> is the code to test.  The second parameter is the test name.  This is a 
> printf()like format string, and the third and subsequent parameters should
> fill out any values in the string.
> 
> ok(a_func() == 0, "test name");
> ok(some_func(i), "some_func(%d)", i);

Why add that extra auto-sprintf complexity?  Can't the user do the exact
same thing with:

ok(some_func(i), sprintf("some_func(%d)", i));

Making the test name a sprintf string can complicate things if they want
to do formatting themselves, they have the extra problem of escaping their
result for sprintf.

Also, folks putting in bare strings might be surprised.

ok( tax(.05), "taxing at 5%" );


> ok2() is for situations where the code to test is sufficiently 
> self-documenting that you don't need to provide a test name.
> 
> ok2(code to test); /* test name is automatically the same as the code */
> 
> E.g.,
> 
> ok(1 == 1, "1 equals one"); /* PRINT: ok 1 - 1 equals 1 */
> ok2(1 == 2);/* PRINT: not ok 2 - 1 == 2 */

Why the split?  You can do variable length argument lists in C.


> This is normally implemented with a "do { ... } while(0);" loop, with a 
> "continue;" immediately after the skip() call.  This ensures that there
> are no additional side effects from the skipped tests.
> 
> do {
> if(getuid() != 0) {
> skip(1, "Test only makes sense as root");
> continue;
> }
> 
> ok(do_something_as_root() == 0, "do_something_as_root() worked");
> } while(0);

It might make more sense to do this.

if( getuid() != 0 ) {
skip(1, "Test only makes sense as root");
}
else {
ok(do_something_as_root() == 0, "do_something_as_root() worked");
}

I'm becoming less and less happy with the way skip is implemented in 
Test::More.


> Two macros, SKIP_START and SKIP_END can handle some of this for you.  The
> above example could be re-written:
> 
> SKIP_START(getuid() != 0, 1, "Test only makes sense as root");
> 
> ok(do_something_as_root() == 0, "do_something_as_root() worked");
> 
> SKIP_END;

That's pretty cool.  Does it work with loops?  What if in that SKIP section
somebody calls a routine which then calls ok()?


> You also have diag(), which takes a printf() style format string and related
> arguments, and sends the output to stderr as a test comment.  diag() adds
> the necessary trailing "\n" for you.
> 
> diag("Expected return code 0, got return code %d", rcode);

Don't forget about adding the # comment on the front of each line.


> Finally, there's exit_status(), which returns an int suitable for use
> when return'ing from main(), or calling exit().  You should always do one
> of:
> 
> return exit_status();
> exit(exit_status());

What is this for?  <--- possible C ignorance

I hope you're not emulating Test::More's exit code == # of tests failed
"feature" that I'm planning on getting rid of.


-- 
Michael G Schwern[EMAIL PROTECTED]  http://www.pobox.com/~schwern/
michael schwern is

Re: slight discrepancy between S2 and S7

[Larry Wall]

On Mon, Dec 06, 2004 at 08:26:48PM +0100, Stéphane Payrard wrote:
: S2:
: 
: my $foo = 42;
: say %MY::<$foo>;# prints "42"
: 
: S6:
: 
:  Perl5ish subroutine declarations
:  ...
:  sub say { print qq{"@_"\n}; }   # args appear in @_
: 
: 
: Because C has no final newline, I would expect C will have
: one.  Final newline or not. What is your say?

Yes, the built-in C certainly adds a newline.  That's the only thing
that distinguishes it from C.  The comment in S2 is misleading,
but you shouldn't ever believe the comments anyway.  :-)

Or the Subject line.  Yours seems to have suffered a bitflip somewhere...

Larry

Re: Container method calls

[Larry Wall]

On Sat, Dec 04, 2004 at 03:28:12PM -0800, Ashley Winters wrote:
: On Sat, 4 Dec 2004 11:15:14 -0800, Larry Wall <[EMAIL PROTECTED]> wrote:
: > On Sat, Dec 04, 2004 at 10:25:49AM -0700, Luke Palmer wrote:
: > : But this convention provides much more accuracy than memorizing a list
: > : of methods that don't automatically thread, or memorizing a list of
: > : iterator methods that act on the iterator and not its current value.
: > 
: > Except that you don't actually have to memorize a list.  Methods thread
: > on their invocant only if their invocant isn't a Junction.  Its
: > mnemonic value is no better or worse than any other MMD distinction.
: 
: Is this behavior exclusive to methods? Or does something like this:
: 
: 3.14159 + "1"|2;
: 
: try to MMD-dispatch to:
: 
: multi sub *infix:<+> (Num $foo, Str|Int $bar)
: 
: instead of (or before) threading?

That would be an "instead of", I suspect.

Larry

Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

[Matthew Walton]

Luke Palmer wrote:
The remaining problem is what to do about unary dot.  Repeated here for
the, er, benefit? of p6l:
class Duple {
has $.left;
has $.right;
method perform (&oper) {
&oper($.left);
&oper($.right);
}
}
Let's change that into a Tuple class:
class Tuple {
has @.elems;
method perform (&oper) {
for @.elems {
.perform($_);
}
}
}
Can you find the mistake?
Well it's not using &oper on the elems anymore.
method perform (&oper) {
  for @.elems {
&oper($_);
  }
}
But I don't think that was the mistake you were talking about. And I 
don't see what it has to do with unary dot either, because you don't 
need to use unary dot to implement that method. Unless each member of 
@.elems is a Duple, in which case the class isn't one I'd call Tuple.

Sorry, nitpicking level seems to be set to 9 at the moment. What did you 
mean?

Re: while Idiom (Was: Arglist I/O)

[Matthew Walton]

Elyse M. Grasso wrote:
But you need to process the file while you haven't reached the end yet, or 
until you reach the end. And I can't think of an occasion where I knew going 
in what the length of the file I was processing was going to be. I suppose 
foreach might make sense if you sucked in the whole file at once and then 
processed the individual lines, but I've seldom been in situations where I 
could assume it was safe to do that. (Data expands to fill the space 
available, plus 10 %... and the production data file is always bigger than 
they told you it would be.)

The same goes for database queries: you loop while the query is returning data 
or until it stops returning data.

Foreach implies to me that you want to do the same thing, or something very 
similar, to each of the things you are processing. But in handling the lines 
of a file or the records returned by a query you may in fact want to throw 
many of them away, or handle various subgroups of data in different ways.
That doesn't make any difference as far as I'm concerned. foreach (or 
for in Perl 6) implies to me that you have a list of things and you're 
going to look at each of them in turn. Whether you do the same thing to 
them or not is to my mind irrelevant, you're stepping over a list item 
by item. for is, to me, ideally suited for anything where you're looking 
at a sequence of things one at a time - reading lines from a file fits 
that perfectly.

Perhaps the reason the indeterminate length of a file doesn't bother me 
is because I'm a Haskell programmer, where everything is lazy and 
recursing over lists is about the only way to get any kind of looping at 
all. Iterating over something of indeterminate length really doesn't 
bother me :-)

Something like the C++y
while(!in.eof()) {
...
}
Is attractive in its way, but I'd rather have something more convenient, 
and I think doing a for over a conceptual list (as in it's not really a 
list, but it's behaving kind of like one in this context) of lines in 
the file is infinitely better.

One can also view the results of a database query as a list of rows 
returned which you then look at one at a time. In fact, I find that far 
more natural than fetching until there are none left.

Of course, you're still really doing that behind the scenes.

Re: Premature pessimization

[Sam Ruby]

Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:

My philosophy is simple: things without test cases tend not not get
fixed, and when fixed, tend not to stay fixed.
There is of course a test case. I have mentioned it at least 20 times ;)
t/op/gc_13.imc - currently using lexicals.
$ parrot t/op/gc_13.imc
3 * 5 == 15!
What's broken?
I am worried about Parrot trying to establish common public names for
common functions.  Many of the examples you gave did not include the
prerequisite double underscores.  For example: "sub", "imag", "eof".
Ah ok. Sorry. "__subtract". OTOH some might be that common and the usage
is the same in all languages that we might use that common name. But
that's probably not worth the effort. So yes, we should establish the
notion that all methods follow that convention.
Cool.
Re: VTABLES... I disagree with you on this one.  Prematurely mapping an
operation to a string is a premature pessimization.
Except that we are doing that already. Please read through
classes/delegate.c. The problem is that this scheme doesn't work for
MMD of real objects.

I don't know enough to have an informed opinion yet on MMD.  But
__set_integer_native is not a MMD operation.  It already is efficiently
dispatched to the correct method.
For PMCs yes. For objects not efficiently and only with a separate
delegate meta-class.
The current delegation internals are not likely a good match for 
languages like Python or Ruby.  I see such languages as implementing 
their own semantics for classes, and Parrot limiting its knowledge to 
methods like findmeth and invoke.

... What do we benefit from the premature
pessimisation of mapping this to a string?
Well, method names happen to be strings ;)
Using the table below, at the moment, there are exactly zero strings 
materialized and/or compared against during the execution of vtable/PMC 
methods.  To the extent that these are represent common operations, this 
can be significant from a performance perspective.

Anyway, I'll try to summarize our current method dispatch scheme:
   vtableMMD  NCI method
 -
 opcodeset P0, 4 add P0, P1, P2   io."__eof"()
 -
 PMC   pmc->vtable->..   mmd_dispatch_*   callmethod
 objectdelegate.c  1) callmethod
 object(PMC)   deleg_pmc.c 1) callmethod
NCI methods are working, the method lookup is dynamic, inheritance
works.
MMD inheritance is totally static (set up during PMC compilation).
PMCs dispatch with the mmd_dispatch_* functions in ops/*.ops.
1) overloading a MMD infix operation needs the mmdvtregister opcode, but
this does not effect any class inheritance and it's just for the given
two types.
Multi-dimensional MD is not implemented.
For vtables objects and objects derived from PMCs use two helper classes
that bridge the dynamic inheritance of objects to the static inheritance
in PMCs. This doesn't support runtime overloading of methods that
defaulted to the PMC method.
Looking at 5 different schemes that work for ~50% of the cases can -
well - make one pessimistic ;)
I'm proposing that *internally* (implementation detail ...) one scheme
should be enough. Again: the opcodes don't change.
I don't think that there can be a single dynamic mechanism that works 
for all languages, let alone one that works for Parrot internals too.

For starters, "findmeth" is a method.  One that merits its own VTABLE 
entry (otherwise, how would you find it?).  Others that map cleanly onto 
existing language syntax also can benefit from such optimizations.

MMD might help out with mutiple language interop, but Python as 
currently designed doesn't need any such facility.

The vtable method set_integer_native clearly maps to a real method that
   
can be either inherited or be provided by the user. This doesn't work
for MMD functions.

Again, set_integer_native is not an MMD function?
__set_integer_native is a vtable method.
Cool.
No. I'm not ditching lexical pads at all. They are of course needed. The
top pad is in the registers. Outer pads are looked up as usual.

I guess I don't understand.  I guess it is time for a test case.  ;-)
How would the following work if the top pad is in registers?
The top pad is always the currently executing one.
  var = 1
  def g():
global var
var = 2

  print "before", var
  g()
  print "after", var
It's obviously up to the "global" to do the right thing. My impression
(I don't have more Python knowledge ;) is, that "global" refers to the
outermost lexical pad in the main module.
Such behavior is the default for perl5:

  my $var = 1;
  sub g {
$var = 2;
  }
As there is no "my $var" in the inner pad, that's just a C
opcode. It follows the C pointer to the outer pad and finds in the
lexical hash the "$var" which maps to a pos

Re: pull & put (Was: Angle quotes and pointy brackets)

[Austin Hastings]

Larry Wall wrote:
On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote:
: >If I went with "get", the opposite would be "unget" for both historical
: >and huffmaniacal reasons.
 

Why? (I get the huffman, not the history.) Is it just a nod to unshift?
Given the existence of a unary = for abbreviated use, I'd probably
stick with shift/unshift.  (Presumably changing the semantics of
shift from p5 to be list/scalar/n-ary context sensitive, so you'd
have to write "scalar shift" to get Perl 5's shift semantics
in list context.)
 

What about add/remove?
sub unshift(@a, [EMAIL PROTECTED])
{
 @a.add(@items);
}
We could add :head and :tail, with :head the default, and let push|pop 
be equivalent to (add|remove).assuming(tail => 1)

As a side note, other than historical consistency, is there a good 
reason for push/pop to use the end of the array? I'd argue that for a 
stack, you only want to "know" one address: @stack[0] -- the 'top' of 
the stack -- and if you ever iterate a stack you're inclined to see the 
items in "distance-from-top" order, making 0..Inf the right array 
sequence. If we're going to reorg the function space, let's huffmanize 
the stack stuff (push/pop/0) and let the other stuff go hang.

=Austin

Re: pull & put (Was: Angle quotes and pointy brackets)

[Larry Wall]

On Mon, Dec 06, 2004 at 03:50:42PM -0500, Austin Hastings wrote:
: Larry Wall wrote:
: 
: >On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote:
: >: >If I went with "get", the opposite would be "unget" for both historical
: >: >and huffmaniacal reasons.
: > 
: >
: Why? (I get the huffman, not the history.) Is it just a nod to unshift?

Try "man ungetc".

: >Given the existence of a unary = for abbreviated use, I'd probably
: >stick with shift/unshift.  (Presumably changing the semantics of
: >shift from p5 to be list/scalar/n-ary context sensitive, so you'd
: >have to write "scalar shift" to get Perl 5's shift semantics
: >in list context.)
: > 
: >
: What about add/remove?

Backwards Huffman, considering removal happens more often.

: sub unshift(@a, [EMAIL PROTECTED])
: {
:  @a.add(@items);
: }
: 
: We could add :head and :tail, with :head the default, and let push|pop 
: be equivalent to (add|remove).assuming(tail => 1)

"remove" is a transitive verb.  I think people would take "remove"
to be "remove any occurrences of", and in the absence of any obvious
direct object, "remove this array", or "remove the list of files in
this array".

: As a side note, other than historical consistency, is there a good 
: reason for push/pop to use the end of the array? I'd argue that for a 
: stack, you only want to "know" one address: @stack[0] -- the 'top' of 
: the stack -- and if you ever iterate a stack you're inclined to see the 
: items in "distance-from-top" order, making 0..Inf the right array 
: sequence. If we're going to reorg the function space, let's huffmanize 
: the stack stuff (push/pop/0) and let the other stuff go hang.

For indexable arrays, the front is what you want to nail down, but
that means it's difficult to make unshift efficient.  Swapping push/pop
for shift/unshift would make push/pop rather inefficient.  And the top
of your stack can just as easily be @stack[-1] as it is now.

I don't see much reason to change what we have currently unless we
decided "shift" was too long, and it isn't if we have unary = for
interators, and real function args to take away most of "my $arg = shift;".

Appearances to the contrary notwithstanding, I'm not trying to break
Perl 5 constructs just for the heck of it.

Larry

Re: C implementation of Test::Harness' TAP protocol

[Andrew Savige]

--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Why add that extra auto-sprintf complexity?  Can't the user do the exact
> same thing with:
> 
>   ok(some_func(i), sprintf("some_func(%d)", i));

No. sprintf in C needs a buffer and you don't know how big to make it.

> > ok2() is for situations where the code to test is sufficiently 
> > self-documenting that you don't need to provide a test name.
> > 
> > ok2(code to test); /* test name is automatically the same as the code
> */
> > 
> > E.g.,
> > 
> > ok(1 == 1, "1 equals one"); /* PRINT: ok 1 - 1 equals 1 */
> > ok2(1 == 2);/* PRINT: not ok 2 - 1 == 2 */
> 
> Why the split?  You can do variable length argument lists in C.

Not with the pre-processor. And you need the pre-processor for
__LINE__ and __FILE__.

An alternative is to drop the ugly ok2() and force the test writer
to use:

  ok(1 == 2, "");

I prefer that since I want to make it hard for people to avoid giving
a test a name, er, comment.

> > Finally, there's exit_status(), which returns an int suitable for use
> > when return'ing from main(), or calling exit().  You should always do one
> > of:
> > 
> > return exit_status();
> > exit(exit_status());
> 
> What is this for?  <--- possible C ignorance
> 
> I hope you're not emulating Test::More's exit code == # of tests failed
> "feature" that I'm planning on getting rid of.

I tried returning the number of failed tests in the exit status in
a C++ regression test suite a while back and dropped it because:
i) you are limited to 0-255 for this exit status;
ii) you can always tell the number of failed tests by parsing stdout;
iii) it's nice to cleanly detect a program crash; if it don't
return zero, it crashed.

/-\


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: C implementation of Test::Harness' TAP protocol

[Michael G Schwern]

On Mon, Dec 06, 2004 at 02:25:42PM -0800, Andrew Savige wrote:
> --- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > Why add that extra auto-sprintf complexity?  Can't the user do the exact
> > same thing with:
> > 
> > ok(some_func(i), sprintf("some_func(%d)", i));
> 
> No. sprintf in C needs a buffer and you don't know how big to make it.

If the user doesn't know how will ok() know how big to make it?


> > > ok(1 == 1, "1 equals one"); /* PRINT: ok 1 - 1 equals 1 */
> > > ok2(1 == 2);/* PRINT: not ok 2 - 1 == 2 */
> > 
> > Why the split?  You can do variable length argument lists in C.
> 
> Not with the pre-processor. And you need the pre-processor for
> __LINE__ and __FILE__.
> 
> An alternative is to drop the ugly ok2() and force the test writer
> to use:
> 
>   ok(1 == 2, "");
> 
> I prefer that since I want to make it hard for people to avoid giving
> a test a name, er, comment.

At the very least some better name than ok2().


> > > Finally, there's exit_status(), which returns an int suitable for use
> > > when return'ing from main(), or calling exit().  You should always do one
> > > of:
> > > 
> > > return exit_status();
> > > exit(exit_status());
> > 
> > What is this for?  <--- possible C ignorance
> > 
> > I hope you're not emulating Test::More's exit code == # of tests failed
> > "feature" that I'm planning on getting rid of.
> 
> I tried returning the number of failed tests in the exit status in
> a C++ regression test suite a while back and dropped it because:
> i) you are limited to 0-255 for this exit status;

For informational purposes...

TM gets around this by just declaring 254 to mean "254 failures or more".
If you have more than 254 failures something tells me the exact number isn't
all that important. :)


> ii) you can always tell the number of failed tests by parsing stdout;

Assuming you have a parser that's quiet.  This is less than simple with 
Test::Harness at the moment.


> iii) it's nice to cleanly detect a program crash; if it don't
> return zero, it crashed.

Yeah, I agree with that.


-- 
Michael G Schwern[EMAIL PROTECTED]  http://www.pobox.com/~schwern/
Quit looking, kids!  It'll EAT YOUR MIND!!
-- http://www.angryflower.com/fuck.gif

Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

[Luke Palmer]

Matthew Walton writes:
> Luke Palmer wrote:
> 
> >The remaining problem is what to do about unary dot.  Repeated here for
> >the, er, benefit? of p6l:
> >
> >class Duple {
> >has $.left;
> >has $.right;
> >
> >method perform (&oper) {
> >&oper($.left);
> >&oper($.right);
> >}
> >}
> >
> >Let's change that into a Tuple class:
> >
> >class Tuple {
> >has @.elems;
> >
> >method perform (&oper) {
> >for @.elems {
> >.perform($_);
> >}
> >}
> >}
> >
> >Can you find the mistake?
> 
> Well it's not using &oper on the elems anymore.

That's mostly because I really screwed up the example.  Mind, it was
very, very early in the morning when I wrote this.  Let's try again.
(This is a pretty trivial example, but the problem only gets worse as we
approach real life).

class MyStream {
has $.stream;

method :send_one ($item) {
$.stream.send($item);
}

method send ([EMAIL PROTECTED]) {
.:send_one("BEGIN");
for @data {
.:send_one($_);
}
.:send_one("END");
}
}

Luke

Re: iterators and functions (and lists)

[Luke Palmer]

Larry Wall writes:
> Any foo() can return a list.  That list can be a Lazy list.  So the
> ordinary return can say:
> 
> return 0...;
> 
> to return an infinite list, or even
> 
> return 0..., 0...;

Is it just me, or did you just return Ï*2?  
http://en.wikipedia.org/wiki/Ordinal#Arithmetic_of_ordinals

That would be totally cool.  But um, how do we get at the structure of
that list from within Perl?  It looks like no matter what you do it
would be impossible to see the second 0.

Luke

Re: iterators and functions (and lists)

[Austin Hastings]

Luke Palmer wrote:
Larry Wall writes:
 

Any foo() can return a list.  That list can be a Lazy list.  So the
ordinary return can say:
   return 0...;
to return an infinite list, or even
   return 0..., 0...;
   

Is it just me, or did you just return Ï*2?  
http://en.wikipedia.org/wiki/Ordinal#Arithmetic_of_ordinals

That would be totally cool.  But um, how do we get at the structure of
that list from within Perl?  It looks like no matter what you do it
would be impossible to see the second 0.
Luke
 

my ($foo1, $foo2) = foo();
?
=Austin

Re: iterators and functions (and lists)

[Larry Wall]

On Mon, Dec 06, 2004 at 06:14:56PM -0500, Austin Hastings wrote:
(B: Luke Palmer wrote:
(B: 
(B: >Larry Wall writes:
(B: > 
(B: >
(B: >>Any foo() can return a list.  That list can be a Lazy list.  So the
(B: >>ordinary return can say:
(B: >>
(B: >>   return 0...;
(B: >>
(B: >>to return an infinite list, or even
(B: >>
(B: >>   return 0..., 0...;
(B: >>   
(B: >>
(B: >
(B: >Is it just me, or did you just return $B&X(B*2?  
(B: >http://en.wikipedia.org/wiki/Ordinal#Arithmetic_of_ordinals
(B: >
(B: >That would be totally cool.  But um, how do we get at the structure of
(B: >that list from within Perl?  It looks like no matter what you do it
(B: >would be impossible to see the second 0.
(B: >
(B: >Luke
(B: >
(B: > 
(B: >
(B: my ($foo1, $foo2) = foo();
(B: 
(B: ?
(B
(BNo, that'd put 0 and 1 into those variables.
(B
(BYou'd have to bind the return value to @foo and then ask @foo for its
(Bhidden specs that generates its values.  That has two elements, one for
(Beach infinite iterator.  Here's the quote from A6:
(B
(BThe List type in particular is an internal type for the temporary
(Blists that are passed around in Perl. Preflattened lists are Eager,
(Bwhile those lists that are not preflattened are Lazy. When you call
(B@array.specs, for instance, you actually get back an object of type
(BLazy. Lists (Lazy or otherwise) are internal generator objects,
(Band in general you shouldn't be doing operations on them, but on
(Bthe arrays to which they are bound. The bound array manages its
(Bhidden generators on your behalf to "harden" the abstract list
(Binto concrete array values on demand.
(B
(BAs far as I can recall we haven't renamed C<.specs> to anything else yet.
(B
(BLarry

Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

[Austin Hastings]

Luke Palmer wrote:
   class MyStream {
   has $.stream;
   method :send_one ($item) {
   $.stream.send($item);
   }
   method send ([EMAIL PROTECTED]) {
   .:send_one("BEGIN");
   for @data {
   .:send_one($_);
   }
   .:send_one("END");
   }
   }
 

I'll guess that you're pointing at
 .:send_one($_);
Which supposedly uses "topic" to resolve .:send_one into $this.send_one. 
If that works, then I'm happy -- I like being able to control topic and 
$_ differently. But if C changes topic, then what?

OUTER::.:send_one($_);
Yuck.
=Austin

Re: pull & put (Was: Angle quotes and pointy brackets)

[mark . a . biggar]

stuff & grab :-)

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

-- Original message -- 

> On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote: 
> : But I'd be willing to rename them to get/put. 
> 
> If I went with "get", the opposite would be "unget" for both historical 
> and huffmaniacal reasons. 
> 
> Larry 

Re: continuation enhanced arcs

[Piers Cawley]

Leopold Toetsch <[EMAIL PROTECTED]> writes:

> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
>>> Matt Fowles <[EMAIL PROTECTED]> wrote:
>>>
 Thanks for the clear explanation.  I did not realize that S registers
 could switch pointers, that does make things a little harder.  I have
 a recommendation for a possible hybrid solution.  Incur the cost of
 spilling I,S,N registers heavily.  Restore the state of P register.
>>>
>>> My conclusion was that with the copying approach I,S,N registers are
>>> unusable.
>
>> But you only need to copy when the frame you're restoring is a full
>> continuation
>
> Yes. With the effect that semantics of I,S,N (i.e. value registers)
> suddenly changes.
>
>> I'd submit that, in the vast majority of cases you're not going to be
>> dealing with full continuations, and on the occasions when you are the
>> programmer using them will be aware of the cost and will be willing to
>> pay it.
>
> *If* the programmer is aware of the fact that a subroutine can return
> multiple times, he can annotate the source so that a correct CFG is
> created that prevents register reusing alltogether. The problem is
> gone in the first place.
>
> *If* that's not true, you'd get the effect that suddenly I,S,N registers
> restore to some older values which makes this registers de facto unusable.

But they're bloody value registers. They're *supposed* to restore to the
state they were in when the function was originally called. Which is
what copying semantics does.

Re: continuation enhanced arcs

[Piers Cawley]

Leopold Toetsch <[EMAIL PROTECTED]> writes:

> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
>>> Matt Fowles <[EMAIL PROTECTED]> wrote:
>>>
 Thanks for the clear explanation.  I did not realize that S registers
 could switch pointers, that does make things a little harder.  I have
 a recommendation for a possible hybrid solution.  Incur the cost of
 spilling I,S,N registers heavily.  Restore the state of P register.
>>>
>>> My conclusion was that with the copying approach I,S,N registers are
>>> unusable.
>
>> But you only need to copy when the frame you're restoring is a full
>> continuation
>
> Yes. With the effect that semantics of I,S,N (i.e. value registers)
> suddenly changes.
>
>> I'd submit that, in the vast majority of cases you're not going to be
>> dealing with full continuations, and on the occasions when you are the
>> programmer using them will be aware of the cost and will be willing to
>> pay it.
>
> *If* the programmer is aware of the fact that a subroutine can return
> multiple times, he can annotate the source so that a correct CFG is
> created that prevents register reusing alltogether. The problem is
> gone in the first place.
>
> *If* that's not true, you'd get the effect that suddenly I,S,N registers
> restore to some older values which makes this registers de facto
> unusable.

Further to my last response. If you have things set up so that you can
return multiple times from the same function invocation then the return
continuation should have been replaced with a full continuation before
the first return, so even the first return will use copying semantics,
and the registers will always be restored to the state they were in when
the function was first called, which is absolutely the right thing to
do.

Re: Premature pessimization

[Luke Palmer]

Leopold Toetsch writes:
> 
> On a semi-related note, can I get a classoffset without doing a hash
> lookup?  That is, can I store the class number I get assigned somewhere
> for quick fetching?

Hey now, you're citing the Luke Palmer that writes code.  Don't confuse
him with the Luke Palmer who does software design.  They really don't
get along so well...

Luke

[perl #32906] Can't make TCL

[via RT]

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


---
osname= linux
osvers= 2.4.21-4.elsmp
arch=   i386-linux-thread-multi
cc= gcc 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
---
Flags:
 category=core
 severity=high
 ack=no
---

I can't get TCL to `make', on the most recent CVS checkout:

[EMAIL PROTECTED] ~/personal/devel/parrot $ cd languages/tcl
[EMAIL PROTECTED] ~/personal/devel/parrot/languages/tcl $ make
make: *** No rule to make target `lib/commands/join.imc', needed by 
`lib/tcllib.imc'.  Stop.

---
Summary of my parrot 0.1.1 configuration:
   configdate='Mon Dec  6 12:02:34 2004'
   Platform:
 osname=linux, archname=i386-linux-thread-multi
 jitcapable=1, jitarchname=i386-linux,
 jitosname=LINUX, jitcpuarch=i386
 execcapable=1
 perl=/usr/bin/perl
   Compiler:
 cc='gcc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS 
-DDEBUGGING  -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
   Linker and Libraries:
 ld='gcc', ldflags=' -L/usr/local/lib',
 cc_ldflags='',
 libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp -lpthread 
-lm -L/usr/lib  -licuuc -licudata -lpthread -lm'
   Dynamic Linking:
 share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC',
 load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC'
   Types:
 iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
 ptrsize=4, ptr_alignment=1 byteorder=1234,
 nv=double, numvalsize=8, doublesize=8

---
Environment:
 HOMELANGLANGUAGELD_LIBRARY_PATHLOGDIRPATH 
PERL5LIBSHELL
-- 
   Matt

   Matthew Zimmerman
   Interdisciplinary Biophysics, University of Virginia
   http://www.people.virginia.edu/~mdz4c/

Re: C implementation of Test::Harness' TAP protocol

[Andrew Savige]

--- Michael G Schwern <[EMAIL PROTECTED]> wrote: 
> On Mon, Dec 06, 2004 at 02:25:42PM -0800, Andrew Savige wrote:
> > --- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > > Why add that extra auto-sprintf complexity?  Can't the user do the exact
> > > same thing with:
> > > 
> > >   ok(some_func(i), sprintf("some_func(%d)", i));
> > 
> > No. sprintf in C needs a buffer and you don't know how big to make it.
> 
> If the user doesn't know how will ok() know how big to make it?

By the magic of the ANSI C macros: va_start(), va_arg(), va_end().
These macros are provided by the C runtime library and typically require
some assembler to implement. In Nik's _gen_result() function (tap.c) he
employs these macros in harness with vprintf(): in this way, he does not
need to allocate a buffer at all, nor does he need worry about possible
buffer overruns. FWIW, I agree with this implemenatation decision, and
feel it will be well received by C programmers ... unless anyone can
suggest a better alternative, of course.

/-\


Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com

Re: pull & put (Was: Angle quotes and pointy brackets)

[Ashley Winters]

On Mon, 6 Dec 2004 11:34:24 -0800, Larry Wall <[EMAIL PROTECTED]> wrote:
> Though it's awfully tempting to fill in the holes in the periodic table:
> 
> ($a, $b, $c) = @foo *<< 3;
> 
> And then just say all the corresponding unaries default to 1 (or the arity
> of the left):
> 
> $bit = +<< $number; # $number +<< 1
> $graph = ~<< $string;   # chip()/chimp()
> $whether = ?<< $boolean;# presumably clears $boolean
> $elem = *<< $iterator;  # shift $iterator

Well, that's interesting.

> I suppose unary *>> would mean pop.  Blurch.  Let's stick with the binaries,
> if we add 'em at all.  I do think
> 
> foo( @bar *<< 3 )
> foo( @bar *>> 3 )

Hrm... if you're thinking of going that way, I'd rather have a
lazy-assignment/destructive-pipe operator of some sort:

($a,$b) <== [EMAIL PROTECTED];   # splice(@bar, 0, 2)

($a, $b) ==> [EMAIL PROTECTED]  # splice(@bar, 0, 0, $a, $b)
[EMAIL PROTECTED] ==> ($a, $b);   # splice(@bar, -2)
[EMAIL PROTECTED] <== ($a, $b);   # splice(@bar, @bar, 0, $a, $b);

Of course, with something indicating the desire to modify the array. I
don't know that [EMAIL PROTECTED] would be right for that, but I dunno. Just an
idea.

I'd want some way of telling the array to lazily add/remove elements
as part of the pipe operator, which would make:

foo <== [EMAIL PROTECTED];   # REMOVE however many elements from the front of 
@bar
as foo() wants

However, this would lead to me thinking about this sequence:

[EMAIL PROTECTED] ==> map ==> grep ==> @whatever;

as:

while pop @this { ... unshift @that, $_ }

Which would be interesting (bad) for performance

Ashley

Re: C implementation of Test::Harness' TAP protocol

[Andrew Savige]

--- "Clayton, Nik" <[EMAIL PROTECTED]> wrote: 
> Having done the initial work to get most of FreeBSD's regression testing
> infrastructure producing Test::Harness TAP compatible output, I've started
> putting together a C library that makes it easier to write tests in C.

Great!
This is something I'm interested in and wish I had more spare time
to pursue. Here are a few random ideas.

1) You might be able to steal some implementation ideas from:

http://cutest.sourceforge.net/

This is a very simple C Unit Testing framework.
In particular, it keeps state in a CuTest struct which is passed
around as the first (mostly hidden) parameter to most functions.

2) A uniform mechanism for test programs to handle command line
arguments would be nice. For example:

int main(int argc, char* argv[])
{
tap_init(argc, argv);  /* mythical new tap function */
// ...
}

Some possible command line arguments are:
  -v verbose
  -d debug
  -t give timing information (via ANSI C clock() function, say)

3) Implementing cmp_ok() in C is a challenge. ;-)

xUnit/cutest have things like:

AssertStrEquals
AssertIntEquals
...

The trouble with plain old ok() is that investigating test failures
is a pest. I suppose you could support equals for the basic C types.
For example:

cmp_ok_int_equals
cmp_ok_double_equals
cmp_ok_cstr_equals
cmp_ok_mem_equals
...

and so on. In the cstr/mem case, you can have the function check
for NULL pointers and give a nice diagnostic rather than crashing.

4) Is thread-safety a requirement of your library?

If so, you better think about it now because it's very hard to
retrofit.

HTH,
/-\


Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com

Perl 6 Summary for 2004-11-29 through 2004-12-06

[Matt Fowles]

Perl 6 Summary for 2004-11-29 through 2004-12-06
All~

Last week I asked for help identifying the source of a quotation. One
friendly soul suggested Alan J. Perlis, but could not find an actual
attribution. It did lead me to find a very applicable (and in my mind
funny) quote from Perlis, which I will now inflict upon you all, before
your regularly scheduled summary:

When someone says "I want a programming language in which I need only
say what I wish done," give him a lollipop. -Alan J. Perlis

  Perl 6 Language
   qq:i
Jim Cromie wondered if there could be a qq:i which sometimes
interpolates and sometimes doesn't depending on whether the variable had
been previously defined. There was some discussion which led to the
conclusion that this was just asking for strange bugs.



   getters and setters
John Siracusa wanted to know if Perl 6 would allow one to expose a
member variable to the outside world, but then later intercept
assignments to it without actually having to switch to using getters and
setters in all of the code that uses the variable. The answer: yes, yes
you can.



   « foo >>
Richard Proctor asked if he could do 

   flipflop operator
Juerd wondered about the fate of the flipflop. Larry explained that
while it had lost the election it was still going to work hard for you
in the Senate. Err, that's not quite right, he said that "It's leaving
syntactically but not semantically.", but the new syntax has not been
specified...



   temp $var
Alexey Trofimenko wanted to know whether " temp " would preserve or
destroy its old value. Larry is leaning towards the Perl 5 semantics of
destroying, I think.



   state vs my
Alexey Trofimenko wondered how much advice about optimizing Ruby also
applied to perl. Unfortunately, he also misunderstood the " state "
specifier. The topic then quickly veered into what exactly " state "
does.



   specifying a hash's key type
Abhijit Mahabal wanted to know if he could specify a hash's key type.
The answer is yes, but the exact syntax seems to be worth a discussion.
Luke Palmer, in his Mathematician's rage, attempted to shoot down any
usage of Domain and Range, as they really should be Domain and Codomain.



 -- wikipedia:
range Range (mathematics) - Wikipedia, the free encyclopedia

   container methods
Ashley Winters wants to have syntax for calling a method on the
container object rather than the containee. Luke Palmer agreed that this
was problematic. Larry appears to be in no hurry to add more operators
for this one, yet.



   slight discrepancy between synopses
Stéphane Payrard pointed out a small issue in some synopses. Larry
replied oops.



   arrays, lists, iterators, functions, coroutines, syntax
Many people suggested many things about the best thing to replace the
now missing " <" > op. I think Larry is leaning towards adding a undare
" = " op, which would do cool things. I don't thing anything is final
yet.

 -- iterators as functions

 -- unary " = " talk

   Push/Pop/Pull/Monkey
Many folk voiced their dislike of shift and unshift. I must agree with
them, but they also suggested a great many alternatives, including
pull/put, get/unget, and even getting rid of Push/Pop. I must say that I
really dislike that last idea, fortunately I am no alone. Currently we
are waiting for inspiration to strike.



   Topicalization
It was noticed that " for " might override one's topic at undesired
times. Larry rumminated about ways to solve this.



   Required Whitespace
Rod Adams does not like inconsistent whitespace rules. Larry explained
why the existing rules really were consistent.



  Perl 6 Compilers
The lack of traffic on p6c has given me another space to abuse. You
should listen to "Soul Coughing". If you would like to join in the fun
of abusing p6c, you should submit tests. Nothing is more abusive then
stress testing ;-)

  Parrot
   Tuning and Monitoring
Matt S asked how much support for tuning and monitoring. This week I
exercise the awesome powers of the summarizer and invoke the mighty
Warnock's Dilemnia.



   imcc.globals--
Leo removed some imcc globals. Nice work.



   ensure directories exist first
Andy Dougherty fixed a problem with writing a file in a non-existant
directory. Leo applied the patch.



   Namespace-sub invocation
L

Re: C implementation of Test::Harness' TAP protocol

[Michael G Schwern]

On Tue, Dec 07, 2004 at 12:55:01PM +1100, Andrew Savige wrote:
> 3) Implementing cmp_ok() in C is a challenge. ;-)
> 
> xUnit/cutest have things like:
> 
> AssertStrEquals
> AssertIntEquals
> ...
> 
> The trouble with plain old ok() is that investigating test failures
> is a pest. I suppose you could support equals for the basic C types.
> For example:
> 
> cmp_ok_int_equals
> cmp_ok_double_equals
> cmp_ok_cstr_equals
> cmp_ok_mem_equals
> ...
> 
> and so on. In the cstr/mem case, you can have the function check
> for NULL pointers and give a nice diagnostic rather than crashing.

Yucko.

Test::More implements cmp_ok() using an eval.  Could a macro prove useful
here to do something similar?

cmp_ok(foo, 'int', '==', bar);


-- 
Michael G Schwern[EMAIL PROTECTED]  http://www.pobox.com/~schwern/
I am the soul of honor, kindness, mercy, and goodness. Trust me in all things.
-- Corwin, "Guns of Avalon"

Re: Perl 6 Summary for 2004-11-29 through 2004-12-06

[Sam Ruby]

Matt Fowles wrote:
   keyword arguments
Sam Ruby wondered how he out to handle keyword arguments to functions.
Dan admitted that this is complex and outlined the cheat he has been
contemplating. No one has either commented on or implemented it yet.

Oh, yes, I did.  ;-)
Here's a test case that now passes:
http://pirate.versionhost.com/viewcvs.cgi/pirate/test/python/varargs.py?rev=HEAD&content-type=text/vnd.viewcvs-markup
At the moment, there is no Parrot conventions for such things, so this 
can't be expected to iteroperate across languages; but if such 
conventions ever do materialize, I'll adjust.

- Sam Ruby

Re: [perl #32906] Can't make TCL

[William Coleda]

You mean, someone actually tried to use Tcl? *Rub eyes*
Whoops. File got added to the tcl makefile based on a local copy of the command.
Committed update to MANIFEST and the join file (which isn't complete or tested, 
btw.)
Try again?
Matthew Zimmerman (via RT) wrote:
# New Ticket Created by  Matthew Zimmerman 
# Please include the string:  [perl #32906]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32906 >

---
osname= linux
osvers= 2.4.21-4.elsmp
arch=   i386-linux-thread-multi
cc= gcc 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
---
Flags:
 category=core
 severity=high
 ack=no
---
I can't get TCL to `make', on the most recent CVS checkout:
[EMAIL PROTECTED] ~/personal/devel/parrot $ cd languages/tcl
[EMAIL PROTECTED] ~/personal/devel/parrot/languages/tcl $ make
make: *** No rule to make target `lib/commands/join.imc', needed by 
`lib/tcllib.imc'.  Stop.

---
Summary of my parrot 0.1.1 configuration:
   configdate='Mon Dec  6 12:02:34 2004'
   Platform:
 osname=linux, archname=i386-linux-thread-multi
 jitcapable=1, jitarchname=i386-linux,
 jitosname=LINUX, jitcpuarch=i386
 execcapable=1
 perl=/usr/bin/perl
   Compiler:
 cc='gcc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS 
-DDEBUGGING  -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
   Linker and Libraries:
 ld='gcc', ldflags=' -L/usr/local/lib',
 cc_ldflags='',
 libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp -lpthread 
-lm -L/usr/lib  -licuuc -licudata -lpthread -lm'
   Dynamic Linking:
 share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC',
 load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC'
   Types:
 iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
 ptrsize=4, ptr_alignment=1 byteorder=1234,
 nv=double, numvalsize=8, doublesize=8

---
Environment:
 HOMELANGLANGUAGELD_LIBRARY_PATHLOGDIRPATH 
PERL5LIBSHELL

Re: C implementation of Test::Harness' TAP protocol

[Andrew Savige]

--- Michael G Schwern <[EMAIL PROTECTED]> wrote: 
> Yucko.
> 
> Test::More implements cmp_ok() using an eval.  Could a macro prove useful
> here to do something similar?
> 
> cmp_ok(foo, 'int', '==', bar);

Good idea Schwern.
These test suites inevitably degenerate into macro crack-pipe
smoking sessions. Lacking 'eval', it is always going to be very
hard work to even get close to Perl's Test::More functionality
and ease-of-use in C.

I don't have a filthy enough mind to make your:
  cmp_ok(foo, 'int', '==', bar);
macro work (mainly because '==' is not a valid C identifier).
But I can make this one work:
  cmp_ok(foo, int, eq, bar);
pretty easily:

#include 
void cmp_ok_inteq(int s, int t) {
printf("in cmp_ok_inteq: %d %d\n", s, t);
}
void cmp_ok_streq(const char* s, const char* t) {
printf("in cmp_ok_streq: '%s' '%s'\n", s, t);
}
#define cmp_ok(s, y, o, t)  cmp_ok_##y##o(s, t)
int main() {
int ifoo = 42;
int ibar = 43;
static const char* sfoo = "foo";
static const char* sbar = "bar";
cmp_ok(ifoo, int, eq, ibar);
cmp_ok(sfoo, str, eq, sbar);
return 0;
}

/-\



Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com

Test labels

[Andy Lester]

I think even better than 

  ok( $expr, "name" );

or

  ok( $expr, "comment" );

is

  ok( $expr, "label" );

RJBS points out that "comment" implies "not really worth doing", and I
still don't like "name" because it implies (to me) a unique identifier.
We also talked about "description", but "description" is just s
overloaded.

Thoughts?

xoxo,
Andy

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

Re: [perl #32877] parrot build broken in Tru64, cc/ld confusion

[Jarkko Hietaniemi]

> 
> The offending line in config/gen/makefiles/dynclasses_pl.in
> is probably this one:
> 
> $LD $CFLAGS $LDFLAGS $LD_LOAD_FLAGS $LIBPARROT
> 
> That CFLAGS doesn't belong there.  CFLAGS are intended to be sent to $CC,
> not to $LD. The command being called here is $LD, which is defined in
> config/init/data.pl as the "Tool used to build shared libraries and
> dynamically loadable modules."
> 
> I no longer remember why LD is set to 'ld' on Tru64 -- is it just Ultrix
> heritage combined with lots of inertia or is it really a sensible setting?

Could well be Ultrix heritage, but in any case the parameter syntaxes of
Tru64 cc and ld are rather different and non-intersecting, and the cc
doesn't automatically pass through unknown parameters to ld (one needs
to use the -W for explicit passing.)

The cc and ld manpages for example here (blame HP for the awful URLs):
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/MAN/MAN1/0607.HTM
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/MAN/MAN1/0668.HTM

> In any case, dynclasses_pl.in is wrong.  There should be no CFLAGS there.


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

Re: [perl #32877] parrot build broken in Tru64, cc/ld confusion

[Jarkko Hietaniemi]

Sam Ruby via RT wrote:
> Andrew Dougherty wrote:
> 
>>The offending line in config/gen/makefiles/dynclasses_pl.in
>>is probably this one:
>>
>>$LD $CFLAGS $LDFLAGS $LD_LOAD_FLAGS $LIBPARROT
>>
>>That CFLAGS doesn't belong there.  CFLAGS are intended to be sent to $CC,
>>not to $LD. The command being called here is $LD, which is defined in
>>config/init/data.pl as the "Tool used to build shared libraries and
>>dynamically loadable modules."
> 
> 
> I can't find anything that fails if this is removed, so I committed the 
> change.

Thanks, that helped!

> - Sam Ruby
> 
> 


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

Re: C implementation of Test::Harness' TAP protocol

[Michael G Schwern]

On Tue, Dec 07, 2004 at 03:18:17PM +1100, Andrew Savige wrote:
> Good idea Schwern.
> These test suites inevitably degenerate into macro crack-pipe
> smoking sessions. Lacking 'eval', it is always going to be very
> hard work to even get close to Perl's Test::More functionality
> and ease-of-use in C.
> 
> I don't have a filthy enough mind to make your:
>   cmp_ok(foo, 'int', '==', bar);
> macro work (mainly because '==' is not a valid C identifier).
> But I can make this one work:
>   cmp_ok(foo, int, eq, bar);
> pretty easily:

Whoa.


> #include 
> void cmp_ok_inteq(int s, int t) {
> printf("in cmp_ok_inteq: %d %d\n", s, t);
> }
> void cmp_ok_streq(const char* s, const char* t) {
> printf("in cmp_ok_streq: '%s' '%s'\n", s, t);
> }
> #define cmp_ok(s, y, o, t)  cmp_ok_##y##o(s, t)
> int main() {
> int ifoo = 42;
> int ibar = 43;
> static const char* sfoo = "foo";
> static const char* sbar = "bar";
> cmp_ok(ifoo, int, eq, ibar);
> cmp_ok(sfoo, str, eq, sbar);
> return 0;
> }


-- 
Michael G Schwern[EMAIL PROTECTED]  http://www.pobox.com/~schwern/
Kids - don't try this at--oh, hell, go ahead, give it a whirl...

Re: iterators and functions (and lists)

[Smylers]

Larry Wall writes:

> As far as I can recall we haven't renamed C<.specs> to anything else yet.

That sounds like a challenge ...

Smylers