Re: across language question

[Leopold Toetsch]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> if compile test_pbc.php to test_pbc.pbc then how use this pbc for perl.

Not yet, sorry.

leo

Re: cvs commit: parrot/t/dynclass foo.t

[Leopold Toetsch]

Will Coleda <[EMAIL PROTECTED]> wrote:

>   +SKIP: { skip("No BigInt Lib configured", 1) if !$PConfig{gmp};

Good. Still better - as we eventually have more then one bigint lib
configurable - we should define a general 'HAS_BIGINT' for any of these
possible libs and test that symbol.

leo

Re: Kwalitee and has_test_*

[Tony Bowden]

On Thu, Apr 07, 2005 at 02:34:21PM -0400, David Golden wrote:
> * Shipping tests is a hint that a developer at least thought about 
> testing.  Counter: It's no guarantee of the quality of testing and can 
> be easily spoofed to raise quality.

This is certainly not why I ship tests, and I've never heard anyone
claim that it's a sensible reason for shipping tests, outside of this
thread.

> * Tests evaluate the success of the distribution against its design 
> goals given a user's unique system and Perl configuration.  Counter: 
> developers should take responsibility for ensuring portability instead 
> of hoping it works unti some user breaks it.

This is exactly why I believe shipping tests with code is a good thing.
I cannot possibly test every perl configuration on every OS. Even if the
team of Benedictine Monks that I employ to do this for could somehow
manage this, unfortunately they are not yet capable of testing it
against /future/ configurations.

Shipping tests with my code protects users from incompatability by
warning them /before/ they install the module, rather than when a user
finally triggers the problem in real code.

The more exhaustive my test suite is, the better this is.

This also makes my life as a developer much better. I don't have to field
lots of bug reports that say nothing more than "I can't get Foo::Bar
version 2.09 to work on Windows". Instead they can tell me "t/wibble.t
fails test 13 on windows saying: 'no such file or directory'". Then,
even without access to that platform, I can probably track down what
the problem is.

Shipping tests is a good thing. The better they are, the better a thing
it is.

Shipping tests that don't actually exercise any functionality of the
code, OTOH, does not share in this mojo. If I have POD for method
frobnitz(), then the POD is there for everyone to enjoy. Shipping a test
that confirms that tells no-one anything, and achieves no purpose, other
than, currently to raise my Kwalitee. Rather, it wastes time for the
poeple installing it, especially as it will recommend that they install
another non-core module (with several other non-core dependencies in
turn).

Kwalitee is only useful if it measures useful things. The presence of a
test file that somewhere mentions the words "Pod::Coverage" is not a
useful thing.

Tony

RE: How to force tests to issue "NA" reports?

[Barbie]

On 07 April 2005 23:02 Ken Williams wrote:

> On Apr 6, 2005, at 7:13 AM, Robert Rothenberg wrote:
> 
>> Is there a way tests to determine that a module cannot be installed
>> on a platform so that CPANPLUS or CPAN::YACSmoke can issue an "NA"
>> (Not Applicable) report? 
>> 
>> CPANPLUS relies on module names (e.g. "Solaris::" or "Win32::") but
>> that is not always appropriate in cases where a module runs on many
>> platforms  except some that do not have the capability.
> 
> In those cases, who's to say that that platform won't get such
> capabilities in the future?  If the module author has to list the
> platforms on which their module won't run, it'll get out of date, and
> the list will likely be incomplete to start out with.

This is something that Robert and I have discussed. It is rather difficult to
decide how to approach this. 

However, thinking about what *might* happen in the future for a future platform,
is not relavent to what we were thinking. There real problems now, such as
alarm(), symlinks and fork() on Win32, that create problems when distributions
use them. There are some distributions that only require them for testing, which
to my mind currently means bogus FAIL reports are generated. If the distribution
author is able to indicate which platforms they are willing to support, then it
could mean a NA report is generated, until such a time as the author is willing
to support that platform.

The reasoning behind all this, is that several authors have raised the subject
of getting FAIL reports for platforms they are not willing or unable to support.
We were trying to think of an adequate way of avoiding sending them reports
which they are not interested in currently. I know it could easily be a matter
of pressing the delete key, but seeing as it has been a wishlist item that keeps
getting mentioned, Robert and I figured it might be something we can address.

>> There's also a separate issue of whether "NA" reports should be
>> issued if a library is missing.  (Usually these come out as
>> failures.) 
> 
> People looking at failure reports should be able to tell whether the
> failure occurred because of a missing prerequisite (of which libraries
> are one variety) or because of runtime building/testing
> problems.  The
> correct way to solve this would be to have a mechanism for declaring
> system library dependencies, then check before smoke-testing whether
> those dependencies are satisfied.

This is also something I've been thinking about for about a year. My only
conclusion is that an addition test grade be created, which implies that the
distribution could not be completed, due to dependancies outside the realm of
the distribution or the install mechanism. My patch to CPANPLUS was to not
produce a report, but I do think it could be something users may wish to know 
about.

> Unfortunately that's a large problem space, and it has eluded attempts
> at cross-platform solutions so far.  It would be really nice
> if it were
> solved, though.

You're right it is a large problem space. There have been a few attempts to
figure it out, but as different platforms have different methods of recording
library information, it isn't going to be a quick fix.


On 07 April 2005 23:12 Michael G Schwern wrote:

> On Thu, Apr 07, 2005 at 05:01:34PM -0500, Ken Williams wrote:
>>> Is there a way tests to determine that a module cannot be installed
>>> on a platform so that CPANPLUS or CPAN::YACSmoke can issue an "NA"
>>> (Not Applicable) report?
> 
> AFAIK NA reports are issued when a Makefile.PL dies due to a "require
> 5.00X" failing.  That's the only way I've seen anyway.

Not true. The current CPANPLUS now will produce a NA report if the perl version
is lower than that specified by the distribution/module. This is checked for as
part of the prepare, build and test stages, not just the prepare stage.

Previously, the only time a NA report was produced was when one of the 3 stages
failed, and the top level namespace matched a platform name that wasn't the
current platform. This was why a while ago there were some NA reports for
distributions in the 'MAC::' namespace. There was a case insensitive test that
thought it was in the 'Mac::' namespace.

Hope that clarifies a few points.

Cheers,
Barbie.

-- 
Barbie (@missbarbell.co.uk) | Birmingham Perl Mongers user group |
http://birmingham.pm.org/

---
This mail sent through http://www.easynetdial.co.uk

[Pugs] Simple list of lists: Pugs confounded me

[Andrew Savige]

I'd like to convert the following p5 code to p6:

my @z = (
[ 'a1', 'a2' ],
[ 'b1', 'b2', 'b3' ]
);
for my $r (@z) { print "@$r\n" }

I thought this might do the trick [1]:

my @z = (
[ 'a1', 'a2' ],
[ 'b1', 'b2', 'b3' ]
);
for @z -> $r { say $r }

However, the p5 version prints:

a1 a2
b1 b2 b3

while the pugs p6 version prints:

a1
a2
b1
b2
b3

Is this a Pugs bug? If not, can anyone suggest a legitimate p6 version?

/-\

[1] Suggested by stvn at http://www.perlmonks.org/?node_id=445339


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

[CVS ci] MMD 21 - bigger restructuring

[Leopold Toetsch]

* the separate native type MMD enums are gone:
MMD_ADD_INT => MMD_ADD
* the native types INTVAL..PMC occupy types 0..3
* this almost halfs the MMD_table size
* enum_type_PMC serves as Any
* the special PMCs delegate, Ref and alike don't register
  MMD functions any more
* get_mmd_dispatch_type (the core of MMD opcode dispatch) is using
  the static MMD_table now as an (inefficiently big) cache
* if no entry is found, a dynamic lookup is done
* the native type MMD fallback functions are gone
* other fallback functions are unused:
  I don't think that we need these fallbacks anyway
* if no matching MMD is found, an exception is thrown
* the mmdvtregister opcode isn't needed any more:
* just define an appropriate @MULTI sub instead
* dynclasses/py*.pmc messed around with MMD NCI functions:
  it replaced the vtable, now Parrot infix multis are kept
leo

RE: Kwalitee and has_test_*

[Barbie]

On 07 April 2005 19:34 David Golden wrote:

> Let's step back a moment.
> 
> Does anyone object that CPANTS Kwalitee looks for tests?  

I think you're missing the point of Tony's argument. I don't think anyone would
dispute that shipping tests with a distribution is a Good Thing (tm). What is at
issue are tests that have no real benefit from testing on the authors or users
platform, apart from a feel good factor. If Test::Pod and Test::Pod::Coverage
don't produced errors on the authors platform, it is extremely doubtful they'll
produce errors on the users platform. I've been putting these tests into my
distributions for sometime, but others haven't, and some, like Tony, prefer to
keep those tests as part of their local test suite.

I do think that some kwalitee mark for them is worthwhile, but not at the
expense of checking a specific filename (as it was in the original check) or
whether the author includes a test using those modules. I believe Test::Pod
could be run without executing the modules, but Pod::Coverage requires the
module to at least load to see all the symbol table information, as some
functions/methods maybe created dynamically.

> * Shipping tests is a hint that a developer at least thought about
> testing.  Counter: It's no guarantee of the quality of
> testing and can
> be easily spoofed to raise quality.

This is not in question.

> * Tests evaluate the success of the distribution against its design
> goals given a user's unique system and Perl configuration.  Counter:
> developers should take responsibility for ensuring
> portability instead
> of hoping it works unti some user breaks it.

Again, not in question.

> The first point extends very nicely to both has_test_* and coverage
> testing.

Daffodils are flowers, therefore all flowers are daffodils!

Including pod/coverage tests shows the author felt comfortable releasing those
tests. Not including them tells you nothing about the authors thought process or
test suite. Please don't second guess them.

> The presence of a
> test is just a sign -- and one that doesn't require code to be run to
> determine Kwalitee.  

Test::Pod maybe, not true of Test::Pod::Coverage.

> The flip side, of course, is that by including test
> that are necessary for CPANTS, a developer inflicts them on
> everyone who uses the code.  That isn't so terrible for pod
> and pod coverage testing, but it's a much bigger hit for 
> Devel::Cover.

Devel::Cover test coverage can be a misleading. In one of my modules there are
set of debug statements, that if the value is undef, to avoid warnings it prints
the string 'undef'. Devel::Cover notes that I don't test for that, and as such I
don't have 100% test coverage in my module. I'm happy with that, and it doesn't
effect the working of the module. Would I be marked down on kwalitee for not
having 100% test coverage? There are plenty of other modules that are in a
similar situation. In another module, should I check that my module can handle a
broken DBI connection in the middle of a fetch?

> Why not find a way to include them in the META.yml file and have the
> build tools keep track of whether pod/pod-coverage/code-coverage was
> run?  Self reported statistics are easy to fake, but so are the
> has_test_* Kwalitee checks as many people have pointed out.

Not quite sure whether you're arguing for or against here. 

> Anyone who is obsessed about Kwality scores is going to fake other 
> checks, too.

Daffodils are flowers, therefore all flowers are daffodils!

You're second guessing again here. Someone who is obsessed with their kwalitee
scores, may actually be quite passionate about having the best quality packaged
distribution they possibly can. Many authors do actually take great pride in the
work they produce, so why would they want to release it in a packaged
distribution with a low quality rating?

> As to the benefits of having Devel::Cover run on many
> environments and recording the output

While this may be of interest to some authors, not all users would be that
interested. May be they should be, but that's another discussion entirely.
Devel::Cover reports, as I've mentioned above, could end up being very
misleading. How many modules actually have 100% test coverage? For those that
don't attain 100%, does that mean they are bad modules? Kwalitee is currently
measure 0 and 1, there is no decimal point.

> Ironically, for all the skeptical comments about "why a
> scoreboard" --
> the fact that many people care about the Kwalitee metric
> suggests that
> it does serve some inspirational purpose.

That's all it's there for. There is no prize, other than self satisfaction that
you've packaged your distributions as reliably as you possibly can.

Personally, I'm not fussed whether the pod testing is a kwalitee item, as I was
including those tests in my distributions before it was introduced. I look to
kwalitee items, simply as a checklist of things I may have missed from my
distributions. It does not represent g

Re: Dynamic Perl, Part 1 [IMCC]

[Tim Bunce]

On Thu, Apr 07, 2005 at 11:35:46PM -0400, William Coleda wrote:
> There are two open tickets about removing the core's dependance on Perl* 
> PMCs, and instead, making them dynamically loadable and using the language 
> agnostic PMCs for internal use.
> 
> Talking about this with Leo on IRC, he expressed an interest in getting 
> these changes in chunks to make them a little more digestable.
> 
> Attached, find the first trivial chunk, which removes as much Perl* from 
> IMCC internals and tests as possible without writing actually writing any 
> new PMC code. 
> PerlArray is going to be the hardest to pull out, as there is no other 
> Array-style pmc that does everything it does. (or, at least, I can't find 
> one. =-)

Does the core need "everything it does"?

If there was another "Array-style pmc that does everything it does"
then could PerlArray be an 'empty subclass' of it?

If the answer the first question is yes, then couldn't you just
rename PerlArray to something without "Perl" in it?

Is the taxonomy of PMCs and what functionality they have, written out
somewhere? If not then that seems like the best place to start.

Tim.

p.s. Forgive me if these are dumb questions - I'm still only a distant
observer.

Re: [Pugs] Simple list of lists: Pugs confounded me

[Stevan Little]

Andrew,
Multi-dimensional structures are currently not supported in Pugs. But 
never fear, Autrijus is working on them right now actually. He is in 
the process of refactoring some of the Array and Hash types (in 
Haskell) to support this.

What you are seeing in this example:
my @z = (
[ 'a1', 'a2' ],
[ 'b1', 'b2', 'b3' ]
);
for @z -> $r { say $r }
However, the p5 version prints:
a1 a2
b1 b2 b3
while the pugs p6 version prints:
a1
a2
b1
b2
b3
Is the current Pugs behavior of auto-dereferencing and flattening the 
inner lists (much like perl5 would do if they were @arrays not 
$array_refs). I would expect that in the next day or two the above code 
should work as you expect it to (I think Autrijus is trying to finish 
before Sunday/Monday's release).

- Stevan

Re: TestSimple/More/Builder in JavaScript

[Ovid]

--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> This  
> > is because there is no END block to grab on to in JavaScript.  
> 
> Could object destruction be used somehow?

It's my understanding that the Ecmascript standard leaves garbage
collection up to the implementation.  I suspect this means we can't be
sure exactly when an object is destroyed, though whether or not this
has any bearing on David's problem is not clear to me.

Cheers,
Ovid

-- 
If this message is a response to a question on a mailing list, please send
follow up questions to the list.

Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Re: array of arrays, hash of hashes, elems, last

[Nathan Gray]

On Wed, Apr 06, 2005 at 09:52:40PM -0400, Lev Selector wrote:
> But I can't make Arrays of Arrays or Hash of Hashes work.
> @ar.elems & @ar.last don't work either.

Autrijus' journal entry (http://use.perl.org/~autrijus/journal/) from
Wednesday states one of the goals for this week is:

  * Implement multidimensional data structure.

> Unless I am doing something wrong - then may be somebody
> can show an example of usage?

  pugs> my @ar = ; say @ar.elems;

I'm not sure where you found @ar.last.

-kolibrie

Re: How to force tests to issue "NA" reports?

[Chris Dolan]

On Apr 6, 2005, at 7:13 AM, Robert Rothenberg wrote:
Is there a way tests to determine that a module cannot be installed on 
a platform so that CPANPLUS or CPAN::YACSmoke can issue an "NA" (Not 
Applicable) report?

CPANPLUS relies on module names (e.g. "Solaris::" or "Win32::") but 
that is not always appropriate in cases where a module runs on many 
platforms  except some that do not have the capability.

There's also a separate issue of whether "NA" reports should be issued 
if a library is missing.  (Usually these come out as failures.)

Regards,
Rob
(Co-author of CPAN::YACSmoke)
It won't help you *today* but there is a proposed META.yml field called 
"excludes_os" which fits your request perfectly.
  http://module-build.sourceforge.net/META-spec-new.html#excludes_os

See also "optional_features.foo.excludes_os"
  http://module-build.sourceforge.net/META-spec-new.html#recommends
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software 
(http://www.media-landscape.com/) and partners in the revolutionary 
Croquet project (http://www.opencroquet.org/)


PGP.sig
Description: This is a digitally signed message part

[perl #34704] [PATCH] get SDL running on win32

[via RT]

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


the attached patch gets the SDL library and examples running on win32. 
please test on existing platforms by applying and running
 .\parrot examples\sdl\blue_rect.imc
 additionally, you may test against the minesweeper and tetris examples. 
these examples start on win32, but are buggy.
 ~jerry

Blocks, continuations and eval()

[wolverian]

Hi,

(I'm sorry if this topic has already been discussed.)

one day a friend asked if Perl 5 had a REPL facility.
(Read-Eval-Print-Loop). I told him it has perl -de0, which is different
in that it does not preserve the lexical scope across evaluated lines.
This is because eval STRING creates its own scope, in which the string
is then evaluated.

You can hack around this with a recursive eval(), which will eventually
blow the stack. I wrote a short module to do this, but never released
it. Have others done this? :)

To get to the real topic:

In Perl 6, the generic solution to fix this (if one wants to fix it)
seems, to me, to be to add a .eval method to objects that represent
scopes. I'm not sure if scopes are first class values in Perl 6. Are
they? How do you get the current scope as an object? Are scopes just
Code objects?

On #perl6, theorbtwo wasn't sure if .eval should be a method on coderefs
or blocks. Is there a difference between the two? I always hated this
about Ruby; there seems to be no practical value to the separation.

Also, are blocks/coderefs/scopes continuations? Should .eval be a method
in Continuation?

Thanks,

-- 
wolverian


signature.asc
Description: Digital signature

Re: [PATCH] apo/A05.pod: spelling error

[Patrick R. Michaud]

On Thu, Apr 07, 2005 at 11:13:42PM +0200, Steven Schubiger wrote:
> Attached is a patch that fixes a minor spelling error
> in apocalypse 5.

Applied, thanks!

Pm

Re: How to force tests to issue "NA" reports?

[David Cantrell]

Chris Dolan wrote:
On Apr 6, 2005, at 7:13 AM, Robert Rothenberg wrote:
Is there a way tests to determine that a module cannot be installed on 
a platform so that CPANPLUS or CPAN::YACSmoke can issue an "NA" (Not 
Applicable) report?
CPANPLUS relies on module names (e.g. "Solaris::" or "Win32::") but 
that is not always appropriate in cases where a module runs on many 
platforms  except some that do not have the capability.
It won't help you *today* but there is a proposed META.yml field called 
"excludes_os" which fits your request perfectly.
  http://module-build.sourceforge.net/META-spec-new.html#excludes_os
Let's take my module File::Find::Rule::Permissions as an example.  I 
know it doesn't work on Windows, but not having access to a Windows 
machine, I have *no idea* what $^O should be on that platform, 
especially for any odd Windows environments like Cygwin or WinCE.  I 
also know it doesn't work on VMS.

That restriction, along with the reason why, is documented.
However, I have no idea whether it works on a platform like MiNT or ODT, 
whatever those might be.  At best, any list here will be incomplete.

Better, I think, to have some way of specifying which features of the 
underlying system are required.  In this case, I require a Unix-ish 
permissions system, with rwxrwxrwx bits, users, and groups.

Presumably my need for a filesystem (not all platforms have one!) would 
be inherited both from File::Find::Rule and from my requiring the 
Unix-ish perms system, and so I wouldn't need to specify it myself.

Let's ignore the fact that FFRP has no useful tests anyway :-)
Oh, and to the list of fields at 
http://module-build.sourceforge.net/META-spec-new.html how about adding 
'requires_application'.  Mac::iTunes::Applescript has an obvious 
prerequisite.  The module Net::P0fq that I am slowly working on requires 
a running copy of p0f.

--
David Cantrell

[PATCH] apo/A05.pod: spelling error

[Steven Schubiger]

Attached is a patch that fixes a minor spelling error
in apocalypse 5.

Steven

--- A05.pod.origThu Apr  7 22:59:16 2005
+++ A05.pod Thu Apr  7 22:59:56 2005
@@ -2179,7 +2179,7 @@
 tree of objects.
 
 Matching against such boundaries or metadata would not be possible
-unless ether the regex engine is aware that it is matching against an
+unless either the regex engine is aware that it is matching against an
 array, or the string emulation provides visibility through the abstract
 string into the underlying array. The latter may be preferable, since
 (by the rules of the C<=~> matrix discussed in Apocalypse 4) C<@array

Re: TestSimple/More/Builder in JavaScript

[Adrian Howard]

On 7 Apr 2005, at 19:23, David Wheeler wrote:
Greetings fellow Perlers,
I'm pleased to announce the first alpha release of my port of 
TestSimple/More/Builder to JavaScript. You can download it from:

  http://www.justatheory.com/downloads/TestBuilder-0.01.tar.gz
[snip]
You rock! Excellent stuff. Off to play.
Adrian

Re: TestSimple/More/Builder in JavaScript

[Adrian Howard]

On 7 Apr 2005, at 20:27, David Wheeler wrote:
[snip]
Besides, I'm sure that Adrian will soon take my code to port 
Test::Class to JavaScript, and then we can have both approaches! ;-)
I did once hack JSUnit to output TAP - so you never know :-)
Adrian

Re: Blocks, continuations and eval()

[David Storrs]

On Fri, Apr 08, 2005 at 05:03:11PM +0300, wolverian wrote:

Hi wolverian,

> one day a friend asked if Perl 5 had a REPL facility.
> (Read-Eval-Print-Loop). I told him it has perl -de0, which is different
> [...]
> In Perl 6, the generic solution to fix this (if one wants to fix it)
> seems, to me, to be to add a .eval method to objects that represent
> scopes. I'm not sure if scopes are first class values in Perl 6. Are
> they? How do you get the current scope as an object? Are scopes just
> Code objects?

I'm unclear on what you're looking for.  Are you trying to get a way
to do interactive coding in P6?  Or the ability to "freeze" a scope
and execute it later?  Or something else?

--Dks


-- 
[EMAIL PROTECTED]

Re: Dynamic Perl, Part 1 [IMCC]

[Leopold Toetsch]

William Coleda <[EMAIL PROTECTED]> wrote:

> PerlArray is going to be the hardest to pull out, as there is no other
> Array-style pmc that does everything it does. (or, at least, I can't
> find one. =-)

The replacement ought to be ResizablePMCArray. Missing methods like
C need implementators.
The PMCArray is doomed and deprecated, it's a wrapper around PerlArray
anyway.

I'll have a closer look at the patch later, probably after SVN switch.

leo

Re: Blocks, continuations and eval()

[MrJoltCola]

At 10:03 AM 4/8/2005, wolverian wrote:
To get to the real topic:
In Perl 6, the generic solution to fix this (if one wants to fix it)
seems, to me, to be to add a .eval method to objects that represent
scopes. I'm not sure if scopes are first class values in Perl 6. Are
they? How do you get the current scope as an object? Are scopes just
Code objects?
On #perl6, theorbtwo wasn't sure if .eval should be a method on coderefs
or blocks. Is there a difference between the two? I always hated this
about Ruby; there seems to be no practical value to the separation.
Also, are blocks/coderefs/scopes continuations? Should .eval be a method
in Continuation?
I'm having a bit of trouble following you, but I can tell you that the VM 
portion
treats continuations as well as lexical scopes or pads as first class Parrot
objects (or PMCs).

I cannot say how much Perl6 will expose to the high level language.
Can you tell me what your idea of a "scope" is? I'm thinking a
continuation, and if that is what you are thinking, I'm thinking the
answer to your question is yes.
-Melvin

Re: TestSimple/More/Builder in JavaScript

[Geoffrey Young]

David Wheeler wrote:
> On Apr 7, 2005, at 5:55 PM, Michael G Schwern wrote:
> 
>> If you have isDeeply() there's little point to the eq* salad.
> 
> 
> Hrm, fair enough. I'll comment them out, then...

well, a few thoughts here...

as someone familiar with T::M and not javascript, were I to try to use this
it's an additional barrier to call it "Test::More in JavaScript" but not
provide _the exact same functions_ as Test::More.  now before everyone
starts slamming this let me explain...

as we shaped the php T::M port we started hitting a few things that were
perlish but not phpish.  isa_ok() is a good example - isa() is a perl method
but php calls it something else.  so, what we plan on doing (or did,
depending on the function) is implementing isa_ok() for the perl folks and
aliasing it to foo_ok() (I forget what) for the php folks.  I think we
carried over use_ok() even though php doesn't distinguish between use and
require in the perl sense, for example.

I guess what I'm trying to say is that, really, the target audience for
these ports is primarily people who are already Test::More savvy.  so,
taking away eq_array() or calling something isDeeply() just makes my life as
a perl-first developer more difficult.  ok, marginally so, but still...

the secondary audience are folks who are not Test::More savvy but who
program in $language.  for them, providing functions with names like
isDeeply() is more idiomatic, so it's a good idea to offer them too - we
should make them as comfortable as possible so they adopt our awesome tools.

anwyay, just a few random thoughts.  I don't ever plan on using javascript
so it really doesn't apply to me anyway :)

oh, and david... you really are crazy ;)

--Geoff

Re: How to force tests to issue "NA" reports?

[Sébastien Aperghis-Tramoni]

David Cantrell wrote:

> Let's take my module File::Find::Rule::Permissions as an example.  I
> know it doesn't work on Windows, but not having access to a Windows
> machine, I have *no idea* what $^O should be on that platform,
> especially for any odd Windows environments like Cygwin or WinCE.  I
> also know it doesn't work on VMS.

perlport to the rescue:
  http://search.cpan.org/dist/perl/pod/perlport.pod#PLATFORMS

> Oh, and to the list of fields at
> http://module-build.sourceforge.net/META-spec-new.html how about adding
> 'requires_application'.  Mac::iTunes::Applescript has an obvious
> prerequisite.  The module Net::P0fq that I am slowly working on requires
> a running copy of p0f.

  http://search.cpan.org/dist/Net-P0f/

Maybe we should join our forces here :)

On a side note, the tests would just check for the availability of p0f.
If it's not present, just skip the tests that require it.

--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.

Re: TestSimple/More/Builder in JavaScript

[David Wheeler]

On Apr 7, 2005, at 2:41 PM, Ovid wrote:
It's my understanding that the Ecmascript standard leaves garbage
collection up to the implementation.  I suspect this means we can't be
sure exactly when an object is destroyed, though whether or not this
has any bearing on David's problem is not clear to me.
According to the Rhino book, most implementations use mark and sweep. 
So you really can't rely on timely destruction, even if you *could* 
hook into it.

Cheers,
David

Re: TestSimple/More/Builder in JavaScript

[David Wheeler]

On Apr 8, 2005, at 8:23 AM, Adrian Howard wrote:
I did once hack JSUnit to output TAP - so you never know :-)
You are a very sick man. :-)
D

Re: TestSimple/More/Builder in JavaScript

[David Wheeler]

On Apr 8, 2005, at 9:36 AM, Geoffrey Young wrote:
as someone familiar with T::M and not javascript, were I to try to use 
this
it's an additional barrier to call it "Test::More in JavaScript" but 
not
provide _the exact same functions_ as Test::More.  now before everyone
starts slamming this let me explain...
Is this about the studlyCaps function names? :-)
as we shaped the php T::M port we started hitting a few things that 
were
perlish but not phpish.  isa_ok() is a good example - isa() is a perl 
method
but php calls it something else.  so, what we plan on doing (or did,
depending on the function) is implementing isa_ok() for the perl folks 
and
aliasing it to foo_ok() (I forget what) for the php folks.  I think we
carried over use_ok() even though php doesn't distinguish between use 
and
require in the perl sense, for example.
Yes, this is why I wrote eqAssoc() and then added an alias named 
eqHash(). Although the next release won't have these functions, on 
Schwern's advice. As for isaOk(), JavaScript has no equivalent--the 
implementation is a big hack. So I think "isa" works as well as 
anything else.

I guess what I'm trying to say is that, really, the target audience for
these ports is primarily people who are already Test::More savvy.  so,
taking away eq_array() or calling something isDeeply() just makes my 
life as
a perl-first developer more difficult.  ok, marginally so, but still...
I think that isDeeply() works across both disciplines. The studly caps 
are there to make the JS folks comfortable. People already familiar 
with T::M will adapt fairly easily. After all, if you're serious about 
writing JavaScript, it's a benefit to you to start thinking in 
JavaScript.

the secondary audience are folks who are not Test::More savvy but who
program in $language.  for them, providing functions with names like
isDeeply() is more idiomatic, so it's a good idea to offer them too - 
we
should make them as comfortable as possible so they adopt our awesome 
tools.

anwyay, just a few random thoughts.  I don't ever plan on using 
javascript
so it really doesn't apply to me anyway :)
I guess I missed the point, then. :-)
oh, and david... you really are crazy ;)
Yeah, yeah, whatever!
Cheers,
David

Re: Kwalitee and has_test_*

[Michael Graham]

Another good reason to ship all of your development tests with code is
that it makes it easer for users to submit patches with tests.  Or to
fork your code and retain all your development tools and methods.

Since most Perl modules go up on CPAN and nowhere else, I think that the
CPAN distribution should contain as much of the useful development
environment as possible.  That includes POD tests, coverage tests,
benchmark tests, developer documentation, nonsense poetry, scraps of
paper, bits of string.

However, personally I think all POD tests and coverage tests should be
skipped at install time unless the user specifically asks for those
tests to be run.

For one thing, they slow down the install and rarely provide useful
information to the user.

For another, they may generate errors that prevent install, even though
the module works correctly.

For instance, if my POD extraction tools are slightly different than the
developer's POD extraction tools, and this causes a POD coverage test to
fail, then the module will fail to install even though it would have
worked correctly.

Maybe I get all my documentation from search.cpan.org and I don't care
whether the module's docs are considered 'kwalitudinous' on my system.
Maybe I don't know enough about testing and module development to know
that the module still works fine in spite of the failed POD test.


Michael




---
Michael Graham <[EMAIL PROTECTED]>

YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - [EMAIL PROTECTED]
---

Re: TestSimple/More/Builder in JavaScript

[Michael G Schwern]

On Fri, Apr 08, 2005 at 12:36:16PM -0400, Geoffrey Young wrote:
> as someone familiar with T::M and not javascript, were I to try to use this
> it's an additional barrier to call it "Test::More in JavaScript" but not
> provide _the exact same functions_ as Test::More.  now before everyone
> starts slamming this let me explain...

Nahh, I'll start slamming now. :)  The eq_* salad was a mistake and I've 
been planning on deprecating them for a while now.  No sense in parroting 
mistakes forward.

In fact, I should probably get around to doing that before more 
implementations spring up.


> as we shaped the php T::M port we started hitting a few things that were
> perlish but not phpish.  isa_ok() is a good example - isa() is a perl method
> but php calls it something else.  so, what we plan on doing (or did,
> depending on the function) is implementing isa_ok() for the perl folks and
> aliasing it to foo_ok() (I forget what) for the php folks.  I think we
> carried over use_ok() even though php doesn't distinguish between use and
> require in the perl sense, for example.
> 
> I guess what I'm trying to say is that, really, the target audience for
> these ports is primarily people who are already Test::More savvy.  so,
> taking away eq_array() or calling something isDeeply() just makes my life as
> a perl-first developer more difficult.  ok, marginally so, but still...

This is sort of true and sort of not.  The original authors of the tests
might be those which are Test::More savvy but the users of the code, and
thus contributors, are likely not.  The short-term idea is to make Perl
programmers more comfortable testing in other languages.  

The long-term idea is to propogate a testing system into another community.
Both the TAP protocol for test interoperability and the Test::More test
writing style so there's something out there which is not XUnit.  This means 
it should make sense to non-Perl programmers, and that its more important 
in the long run that it does.  

So the nativized aliases are a good idea.  In fact, I'd go so far as to
discourage the use of the Perlish idioms.  Just mention in the docs
"wibble_ok() is like isa_ok()..."  If you know PHP (or whatever) and 
understand how inheritence works in PHP it should not confuse you to find
isa_ok() is called wibble_ok() (umm... assuming PHPers refer to inheritence
as "wibble").

In the same way that David translated from whatever_this_style_is_called() 
to studlyCaps() because the latter is (I'm assuming) considered good 
Javascript style.  Javascript programmers will be comfortable with it and
any native Perl programmer looking at it would know enough Javascript to 
expect it.

Re: How to force tests to issue "NA" reports?

[Michael G Schwern]

On Thu, Apr 07, 2005 at 07:49:40AM -0500, Chris Dolan wrote:
> >Is there a way tests to determine that a module cannot be installed on 
> >a platform so that CPANPLUS or CPAN::YACSmoke can issue an "NA" (Not 
> >Applicable) report?

The only way I know of to do this currently is for Makefile.PL to die
as a result of a failed "require 5.00X" line.  ie. Your Perl is not of a
high enough version.

Perhaps, as a stop-gap, this model could be expanded a little bit to allow
the Makefile.PL to die with a general NA report.

die "Stopped: $reason";

or

die "NA: $reason";

Since, at the moment, we're having trouble putting together a system to
cover the possible reasons for an NA report let the module author figure it
out.  Its simple and minimal.

Re: Blocks, continuations and eval()

[wolverian]

On Fri, Apr 08, 2005 at 08:35:30AM -0700, David Storrs wrote:
> I'm unclear on what you're looking for.  Are you trying to get a way
> to do interactive coding in P6?  Or the ability to "freeze" a scope
> and execute it later?  Or something else?

Neither in itself. I'm looking for a way to refer to scopes
programmatically. I'm also asking if they are continuations, or blocks,
or coderefs, or are those all the same?

The two things you mention are effects of being able to refer to scopes
in such a fashion. I do want both, but the real question isn't if they
are possible, but about what blocks, coderefs and scopes are.

I'm sorry if I was unclear. I probably should have spent more time
writing the post. :)

> --Dks

--
wolverian


signature.asc
Description: Digital signature

Re: Blocks, continuations and eval()

[wolverian]

On Fri, Apr 08, 2005 at 12:18:45PM -0400, MrJoltCola wrote:
> I cannot say how much Perl6 will expose to the high level language.

That is what I'm wondering about. I'm sorry I was so unclear.

> Can you tell me what your idea of a "scope" is? I'm thinking a
> continuation, and if that is what you are thinking, I'm thinking the
> answer to your question is yes.

Yes. I want to know how Perl 6 exposes continuations, and how to get one
for, say, the current lexical scope, and if it has a method on it that
lets me evaluate code in that context (or some other way to do that).

> -Melvin

-- 
wolverian


signature.asc
Description: Digital signature

Some ideas (was Re: How to force tests to issue "NA" reports?)

[Robert Rothenberg]

I'm all for something like this, though I prefer "requires_libraries" 
instead. (Listing libraries distinct from applications is a grey area, 
so best to put them under one term.)

Come to think of it, why not "recommends_libraries" too?
What is needed is some standard set of library and application names.
Implementing platform-independent logic to find these libraries is 
another matter.

Here's an idea. A module namespace called Config::Libraries, such as
  Config::Libraries->info('libgd')
which returns a hash of relevant information about the library. Some of 
the hash keys would be standardized, such as one to return a path to 
where the library or application is installed, another to return the 
version.  (It would return undef if the library was not installed.)

This information would be read from an adequate text configuration file 
format (YAML or IniFile).

There should be another interface to update the config file easily, 
along with a command-line script to do this.

Library installation utilities can use this script, or users can use it 
to manually update the config as needed.

The module would have some messy installation procedure that sets up an 
initial script. Ideally it should have Platform-specific parts inside 
generic wrapper methods.  There might be a separate installation file 
for each application that uses these methods to configure itself: this 
way adding a new library to the utility is a matter of adding script.

Pseudo-library names could be given to special capabilities that some 
systems do not have.

The downside is controlling the library namespace. Whoever controls the 
Config::Libraries module would have the de facto control, which is 
probably good enough for the time being.

That said, who has time to work on such a project? I've got my hands 
full already.

Regards,
Rob
On 08/04/2005 15:52 David Cantrell wrote:
Oh, and to the list of fields at 
http://module-build.sourceforge.net/META-spec-new.html how about adding 
'requires_application'.  Mac::iTunes::Applescript has an obvious 
prerequisite.  The module Net::P0fq that I am slowly working on requires 
a running copy of p0f.

Re: TestSimple/More/Builder in JavaScript

[David Wheeler]

On Apr 8, 2005, at 10:28 AM, Michael G Schwern wrote:
Nahh, I'll start slamming now. :)  The eq_* salad was a mistake and 
I've
been planning on deprecating them for a while now.  No sense in 
parroting
mistakes forward.
By the way, I've just removed those from my svn repository, and changed 
eqSet() to isSet(), which seems like a nice way to turn a useful 
comparison function not supported by isDeeply() into a test function.

In the same way that David translated from 
whatever_this_style_is_called()
to studlyCaps() because the latter is (I'm assuming) considered good
Javascript style.  Javascript programmers will be comfortable with it 
and
any native Perl programmer looking at it would know enough Javascript 
to
expect it.
Precisely.
Thanks!
David

[perl #34891] [PATCH] remove 'unreferenced local variable' warnings from src/*.c files

[via RT]

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


This transaction appears to have no contenti'm in the process of removing warnings from parrot, and i thought i'd split 
the patches up into manageable chunks. this patch removes 'unreferenced 
local variable' warnings from all src/*.c files.
 only known test failures (dynclasses, spawnw) on win32 with this patch 
applied.
 ~jerry


src.patch
Description: Binary data

Re: [perl #34704] [PATCH] get SDL running on win32

[chromatic]

On Thu, 2005-04-07 at 11:06 -0700, jerry gay wrote:

> the attached patch gets the SDL library and examples running on win32. 
> please test on existing platforms by applying and running
>  .\parrot examples\sdl\blue_rect.imc

I don't see a patch in this mail or in RT.  Can you re-send?

-- c

Re: [perl #34704] [PATCH] get SDL running on win32

[jerry gay]

urk. attached.
On 8 Apr 2005 18:41:42 -, chromatic via RT <[EMAIL PROTECTED]> wrote:
On Thu, 2005-04-07 at 11:06 -0700, jerry gay wrote:> the attached patch gets the SDL library and examples running on win32.> please test on existing platforms by applying and running>  .\parrot examples\sdl\blue_rect.imcI don't see a patch in this mail or in RT.  Can you re-send?-- c

SDL.patch
Description: Binary data

Re: How to force tests to issue "NA" reports?

[Ken Williams]

On Apr 8, 2005, at 12:32 PM, Michael G Schwern wrote:
die "NA: $reason";
Since, at the moment, we're having trouble putting together a system to
cover the possible reasons for an NA report let the module author 
figure it
out.  Its simple and minimal.

I like it.
 -Ken

[perl #34893] [PATCH] remove warnings from dynclasses/tcl*.pmc

[Will Coleda via RT]

This patch looks fine, if someone wants to apply it before the SVN 
migration.

Re: [Pugs] Simple list of lists: Pugs confounded me

[Autrijus Tang]

On Fri, Apr 08, 2005 at 09:22:27AM -0400, Stevan Little wrote:
> Multi-dimensional structures are currently not supported in Pugs. But
> never fear, Autrijus is working on them right now actually. He is in
> the process of refactoring some of the Array and Hash types (in
> Haskell) to support this.

Indeed.  Thanks to Stevan's massive test-driven efforts, I've managed
to make this work, as of r1651:

my @z = (
[ 'a1', 'a2' ],
[ 'b1', 'b2', 'b3' ]
);
for @z -> $r { say $r }

There's more IType related works tomorrow -- I'll post them on my
journal as usual.

Thanks,
/Autrijus/


pgpoBw6ANYRR4.pgp
Description: PGP signature

Probing requirements (was: Re: Some ideas)

[Randy W. Sims]

Robert Rothenberg wrote:
I'm all for something like this, though I prefer "requires_libraries" 
instead. (Listing libraries distinct from applications is a grey area, 
so best to put them under one term.)

Come to think of it, why not "recommends_libraries" too?
What is needed is some standard set of library and application names.
Implementing platform-independent logic to find these libraries is 
another matter.

Here's an idea. A module namespace called Config::Libraries, such as
  Config::Libraries->info('libgd')
which returns a hash of relevant information about the library. Some of 
the hash keys would be standardized, such as one to return a path to 
where the library or application is installed, another to return the 
version.  (It would return undef if the library was not installed.)

This information would be read from an adequate text configuration file 
format (YAML or IniFile).

There should be another interface to update the config file easily, 
along with a command-line script to do this.

Library installation utilities can use this script, or users can use it 
to manually update the config as needed.

The module would have some messy installation procedure that sets up an 
initial script. Ideally it should have Platform-specific parts inside 
generic wrapper methods.  There might be a separate installation file 
for each application that uses these methods to configure itself: this 
way adding a new library to the utility is a matter of adding script.

Pseudo-library names could be given to special capabilities that some 
systems do not have.

The downside is controlling the library namespace. Whoever controls the 
Config::Libraries module would have the de facto control, which is 
probably good enough for the time being.

That said, who has time to work on such a project? I've got my hands 
full already.
Eventually there will likely be a series of modules in Probe::* to deal 
with this sort of stuff. If no one else is interested I guess I'll 
eventually get around to it. The functionality is needed for 
Module::Build, specifically for either the proposed fields to the META 
spec or dEx[1] which is intended as an alternative solution to many of 
the proposed fields in the META spec.

There will be things like:
Probe::OS - Gather info on the operating system
Probe::Libs
Probe::Progs
Probe::FileSys - maybe incorporate ideas Schwern posted on p5p recently, 
detecting sensitivity, preservability of case, etc
Probe::Locations - where to install parts of apps, config files, data files
Probe::Apache
etc.

(IIUC, this namespace was once proposed for this use, but noone has 
developed it.)

At least this is what I'm thinking at the moment. It's subject to 
change. And this is a long way into the future. Lots of stuff to be done 
first.

1. 

[perl #34894] [PATCH] remove warnings from classes/*.pmc

[via RT]

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


This transaction appears to have no contentthis patch removes uninitialized variable warnings from the following:
 ast/node.c
charset/ascii.c
classes/complex.pmc
classes/fixedbooleanarray.pmc
classes/fixedpmcarray.pmc
classes/hash.pmc
classes/integer.pmc
classes/parrotclass.pmc
classes/parrotthread.pmc
classes/resizeablebooleanarray.pmc
classes/scratchpad.pmc
classes/tqueue.pmc
classes/unmanagedstruct.pmc
ops/io.ops
ops/string.ops
 all tests pass on win32--vc-7.1
 ...and now it's time for the weekend to begin.
~jerry


classes.patch
Description: Binary data

[perl #34893] [PATCH] remove warnings from dynclasses/tcl*.pmc

[via RT]

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


This transaction appears to have no contentthis patch removes warnings of unreferenced labels and local variables from 
dynclasses/tcl*.pmc
 ~jerry


dynclasses-tcl.patch
Description: Binary data

Re: How to force tests to issue "NA" reports?

[Robert Rothenberg]

Same here.
On 08/04/2005 20:02 Ken Williams wrote:
On Apr 8, 2005, at 12:32 PM, Michael G Schwern wrote:
die "NA: $reason";
Since, at the moment, we're having trouble putting together a system to
cover the possible reasons for an NA report let the module author 
figure it
out.  Its simple and minimal.

I like it.

Re: Probing requirements

[Randy W. Sims]

_brian_d_foy wrote:
In article <[EMAIL PROTECTED]>, Randy W. Sims
<[EMAIL PROTECTED]> wrote:


Probe::OS - Gather info on the operating system
Probe::Libs
Probe::Progs
Probe::FileSys - maybe incorporate ideas Schwern posted on p5p recently, 

Perhaps we can put this under a namespace like Config:: ?
I have no strong feelings about the namespace. The idea of Probe:: came 
from a document that used to be at:


It vaguely described something along the lines of what we're discussing. 
But that page disappeared a good while back and nothing has shown up in 
that namespace. So...

I didn't like the Probe name too much at first, but it's kinda grown on 
me; seems very perlish. I've come to think of Config::* as a place for 
static configuration information such as the compiler used to compiler 
perl, $Config{cc}. Probe would deal with more dynamic configuration 
gathering type stuff. For example, Probe::Compiler might determine what 
compiler(s) are installed, launch the compiler or compile a snippet to 
determine the version of the compiler and the version of the C lib, 
default include paths, and various other characteristics.

But, as I said, I'm not strongly attached to any particular namespace. 
And it will probably be a while before I get to it.

Randy.