Re: HLL Debug Segments

[Leopold Toetsch]

On Nov 15, 2005, at 0:07, Jonathan Worthington wrote:


What's the fascination with overloading comment syntax?


Because a compiler can emit it right now w/o any change to Parrot.



Jonathan


leo

Re: PDD20: An idea: Call frames as PMCs

[Leopold Toetsch]

On Nov 15, 2005, at 4:28, Chip Salzenberg wrote:


On Sun, Nov 13, 2005 at 11:33:07AM +0100, Leopold Toetsch wrote:



OK, call frame as PMC looks like a non-starter.  Consider it rescinded.


Autrijus mentioned on #parrot that we'd need weak pointers at some 
time. Then we can reconsider callframe PMCs.



interp."get_caller"(n_levels)# interpreter method or
sub_class = getclass 'Sub'
sub_class."get_caller"(n_levels) # class method 0 = this sub, 1 = 
 caller, ...
a_sub."get_caller"(nlevels)  # obj method, if you already 
have a sub


Well, like I explained WRT lexicals, subroutines don't have callers
(nor do they have LexPads).  _Call_frames_ have callers (and LexPads).


Sure. The interpreter or the sub implement "get_caller" on behalf of 
the callframe.



Which leads to:

The current introspection model only walks back the current call chain.
That's good but not enough.  We also need to walk back any live call
chain, using any live continuation as a starting point.


Yup


How about if we implement get_caller() on Interpreter and Continuation,
rather than Interpreter and Sub?


... Interpreter and Sub and Continuation ;-) Dropping the interface 
from Sub would again need to expose the RetContinuation, which converts 
it (and all up the call chain) to real Continuations. If you already 
have a Continuation then that's fine.



  Alternatively, I guess we could make
get_caller() take two parameters: a Continuation as a starting point
(Null would mean "me"), and a number of levels up.


Hmm. That are 3 params in the method: object, start, level. I guess 
this needs first some thoughts, how we handle class methods, when 
invoked by an instance of the class.


leo

Re: HLL Debug Segments

[Brent 'Dax' Royal-Gordon]

Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> On Nov 15, 2005, at 0:07, Jonathan Worthington wrote:
> > What's the fascination with overloading comment syntax?
>
> Because a compiler can emit it right now w/o any change to Parrot.

That's an advantage for the week it takes to implement the feature. 
For the remaining age of the universe, however, it's a detriment,
because Parrot will silently ignore any syntax errors and programmers
will have to be careful to ensure their comments aren't "magic".

If it walks like a pragma and quacks like a pragma, it should have the
syntax of a pragma.  Use a leading dot; you'll thank yourself later.

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

Re: HLL Debug Segments

[Leopold Toetsch]

On Nov 15, 2005, at 10:04, Brent 'Dax' Royal-Gordon wrote:


Leopold Toetsch <[EMAIL PROTECTED]> wrote:



Because a compiler can emit it right now w/o any change to Parrot.


That's an advantage for the week it takes to implement the feature.
For the remaining age of the universe,


Err, I didn't say that this is the final syntax. I just want to have a 
syntax to start with right now. Changing it from a comment to a 
directive is easy, after parsing is implemented in Parrot.


leo

Re: context matters

[Patrick R. Michaud]

On Mon, Nov 14, 2005 at 06:59:51PM -0800, jerry gay wrote:
> while adding some shiny new pge tests for return context, i came
> across this PIRism:
> 
> ##...
>   rulesub = p6rule('$:=(.)')
>   match = rulesub('abc')
>   .local string res
>   res = match['A']
>   print res
> ## prints: a
> 
> using keyed string access to the match object
> ##...
>   rulesub = p6rule('$:=(.)')
>   match = rulesub('abc')
>   .local string res
>   res = match[0]
>   print res
> ## errors: Null PMC access in get_string()
> [...]
> it seems that in keyed string access to the match object, the result
> is returned directly as a string. in keyed integer access to the match
> object, an intermediate pmc must be used. although the workaround is
> simple, the lack of symmetry seems odd. is this due to PIR
> restrictions, or to PGE implementation?

Well, I suppose it can be argued either way.  First, note that
PGE::Match is a subclass of Hash, so one has available all of the
(non-integer) keyed methods by default.  The PGE::Match object
then overloads some (but currently not all) of the *_keyed_int
methods to be able to provide access to the array component of the
Match object.

Thus, while PGE::Match currently defines a C<__get_pmc_keyed_int>
method, it's doesn't yet define a C<__get_string_keyed_int> method.
So, a statement like

   .local string res
   .local pmc match
   res = match[0]

is defaulting to using the inherited op from the Hash class, and
since there's not an entry at the 0 key in the hash (as opposed to
the array) you get the null PMC.

I guess I should go ahead and provide methods in the match objects
for the other *_keyed_int operations, if only to avoid this sort of
confusion and the need to store things to an intermediate pmc.

Another possibility may be to simply use the hash for all captures,
including the "array" captures, thus removing the numbers from
being valid keys.  Something I read in S05 leads me to believe
that $/<1> and $/[1] are actually the same, in which case we might
not need the separate "array component" and *_keyed_int methods
for Match objects.

Pm

Re: RFC: Test::JSON

[Adam Kennedy]

Chromatic wrote:

On Mon, 2005-11-14 at 12:45 -0800, Ovid wrote:



Yes, I can see that.  I could actually have dropped Test::Differences
"eq_or_diff" and just used the "is_deeply" function from Test::More,
but when working with large data structures, there's just no comparison
between the two.  I suppose I could make Test::Differences optional and
fall back on is_deeply if they don't have T:D installed.



At some point, people install modules for the convenience of not writing
that code themselves.  I think they'll survive if you require modules
for the convenience of not having to write that code yourself, at least
if you don't go crazy with it.


The question is, what level of deps is "crazy" for something that they 
don't actually need on their computer permanently but only need for 2 
seconds to install something of yours.


Adam K

Re: CPANTS: released_while_burning_midnight_oil

[David Cantrell]

A. Pagaltzis wrote:

* Ian Langworth <[EMAIL PROTECTED]> [2005-11-14 18:15]:

PS. If you feel that sarcasm and satire are not best reflected
in email, I cordially suggest that you eat a helicopter.

What wine is more appropriate with helicopters, though, white or
red?


If they're UN Stormtrooper Black Helicopters, it has to be a Pinot Noir.

--
David Cantrell

Re: RFC: Test::JSON

[Tels]

-BEGIN PGP SIGNED MESSAGE-

Moin,

On Monday 14 November 2005 23:22, Adam Kennedy wrote:
> Chromatic wrote:
> > On Mon, 2005-11-14 at 12:45 -0800, Ovid wrote:
> >>Yes, I can see that.  I could actually have dropped Test::Differences
> >>"eq_or_diff" and just used the "is_deeply" function from Test::More,
> >>but when working with large data structures, there's just no
> >> comparison between the two.  I suppose I could make
> >> Test::Differences optional and fall back on is_deeply if they don't
> >> have T:D installed.
> >
> > At some point, people install modules for the convenience of not
> > writing that code themselves.  I think they'll survive if you require
> > modules for the convenience of not having to write that code
> > yourself, at least if you don't go crazy with it.
>
> The question is, what level of deps is "crazy" for something that they
> don't actually need on their computer permanently but only need for 2
> seconds to install something of yours.

This reminds me of my mini-rant about testing module dependencies. As I 
said, enjoy re-suing code, but sometimes less is more. Finding the middle 
ground is hard, but the extremes can be spotted easy. :)

Thats als why I find it really good that perl contains so many modules in 
a standard distribution, your users don't need to install tons of stuff 
just to use Foo::BAR.

Best wishes,

Tels

- -- 
 Signed on Tue Nov 15 11:13:46 2005 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Yeah, baby, yeah!"

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQ3m1PncLPEOTuEwVAQEPSAf+LZzx2MUmYC4+4ixX17oQkHRAQyZ/tiG6
XywrcLBJ/nuyxFc0f9sBfIJgiD/pLUadT4Ac20F69FM0I7uUkaTQOuhzqxOAOkVR
7P3EU3i3TjKbSwg35mqmXKvwF1WT3YBJB1YQ8hzUneDnu+O8fJrMnLq+24RRgely
MkgX7hpIGmLjfPD2uhpcINi28IvzA/zlPwqydx7WiJTPF5oIdZg2pn3JS5UGlYoG
qSgzW+ZeHeo3pLGMftC7pGrEBfJpGQ5sEo4GAAbMQx/sh1yGGoNXuOXAmNL4V/fH
Kp0gNYqVMnD93LFSIqjlrRlVopFrDGupjldFQKBBZQP6b0eoadSTVA==
=arzN
-END PGP SIGNATURE-

Re: [perl #37651] [PATCH] Add $LINK_DYNAMIC when linking pbc_merge

[Francois PERRAD]

At 08:08 10/11/2005 -0800, you wrote:

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


This patch is required for pbc_merge on some platforms (HP-UX is the
one that I see it on), particularly when creating tcllib.


Same problem on Win32, but this patch doesn't solve it with MinGW.

Now a stupid question, why pbc_merge is a big/fat executable and not a Perl 
script or better a PIR program ?


François Perrad.



pbc_merge calls dynamically loaded pmc code which needs access to
symbols in the executable, such as const_string.

Cheers,

Nick
Index: config/gen/makefiles/root.in
===
--- config/gen/makefiles/root.in(revision 9883)
+++ config/gen/makefiles/root.in(working copy)
@@ -817,7 +817,7 @@
$(LINK) ${ld_out}$(PBCMERGE) \
$(SRC_DIR)/pbc_merge$(O) \
$(SRC_DIR)/parrot_config$(O) \
-   $(LINKFLAGS) $(ALL_PARROT_LIBS)
+   $(LINKFLAGS) $(LINK_DYNAMIC) $(ALL_PARROT_LIBS)

Re: Private tests

[Tels]

-BEGIN PGP SIGNED MESSAGE-

Moin,

On Monday 14 November 2005 18:21, Chris Dolan wrote:
> Hello all,
>
> I've just published an article about public vs. private regression
> tests.  I've defined private tests as t/*.t files that are for the
> author only and don't go in MANIFEST.  Naturally, those don't get as
> much publicity as tests included in CPAN distributions.
>
> In the article I advocate that some tests should be private.  In
> particular,
>1) those that test non-critical aspects of a module (like
> documentation and coding style)
>2) those that are too expensive to run often
>3) those that require special software or customization
> In my conclusion I describe a possible system where authors publish
> the results of private tests with their distributions as a trust-
> based kwalitee system.  That is, authors assert kwalitee rather than
> be judged for it.
>
>http://www.chrisdolan.net/talk/index.php/2005/11/14/private-
> regression-tests/
>
> Both positive and negative feedback is very welcome!

Private tests will only be run by the author, meaning they will be only 
run on a very small subset of all systems the modules can be used on.

This limits their usefullness quite a bit.

Case ein point: I can test my modules on linux, 32 bit, unthreaded, under 
unicode, and under perl 5.8.x. Thats about it, everything else gets 
really really complicated for me to set up and maintain/test. 

So, no win32, no mac, now solaris, no irix, no perl 5.6.x, no 
iso-something, no EBDIC (or however it is spelled), no threading, no 64 
bit, no SMP system.

As for 1), these things should matter (the "broken window analogy") and 
you would be surprised to know how these tests can pass on your system, 
and still fail on other systesm (forget to include the .pod file in 
MANIFEST is the most obvious one).

As for 2), random testing should be employed (Math::BigInt does this, it 
runs 256 or so tests with random number patterns (and thus known results 
like "2 * A - A == A"). The tests are quite fast, but they cover only a 
small subset of potential values. However, since each system and user 
runs a new, different random set, you end up with a really huge testing 
number being run. (Yes, this has found some bugs)

And for 3), this might be the only point I can think that private tests 
are usefull (I have a private testset for Graph::Easy that I use from 
time to time, it is not public mainly because it fails/hangs/takes 
forever and is work-in-progress).

However, I have to actually read your article to find out what your 
proposal solves (compared to me just running thetest once in a while :)

Hope that was usefull :)

Best wishes,

Tels

- -- 
 Signed on Tue Nov 15 11:04:21 2005 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Now, _you_ behave!"

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQ3m0pHcLPEOTuEwVAQF6lQf8CtubDMQjLdCBcEGNczxZj2Y1kTVhOU7Z
bvweeJe4RWFfmd2JMw7dwiu3Sjb57hNlVkl4LwN+7vx3tm3DsnhRUoMHvkDtCddC
8bfxpLcOi8WMlySAud+unKnpZVwlwn2rZ/enu2Dd01QKOgOQkBr1HWTJUguPv4No
eWT3UiEZhV4hU764gtF7a8raHjbvxpTJcNk22KHnRmyTKX+SugCyI0qkmIQrFntl
cQWXyA9GV7V+5bK5/Sp2eWv2MXX3fhNDxtZywkmqun+6/YhPgSDJQp3FcKThZFYy
WxPXsrXVIXFJbbtkSs+PGe18VdXqEFCHOI29H1+9gyiC3FW3N6AARw==
=GA3y
-END PGP SIGNATURE-

Re: CPANTS: released_while_burning_midnight_oil

[David Landgren]

David Cantrell wrote:

A. Pagaltzis wrote:

* Ian Langworth <[EMAIL PROTECTED]> [2005-11-14 18:15]:

PS. If you feel that sarcasm and satire are not best reflected
in email, I cordially suggest that you eat a helicopter.

What wine is more appropriate with helicopters, though, white or
red?


If they're UN Stormtrooper Black Helicopters, it has to be a Pinot Noir.



Of course, if the module is under the Text:: hierarchy, then a glass of 
Chardonnay is recommended.


David
--
"It's overkill of course, but you can never have too much overkill."

Re: HLL Debug Segments

[Joshua Hoblitt]

On Tue, Nov 15, 2005 at 10:25:07AM +0100, Leopold Toetsch wrote:
> 
> On Nov 15, 2005, at 10:04, Brent 'Dax' Royal-Gordon wrote:
> 
> >Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> 
> >>Because a compiler can emit it right now w/o any change to Parrot.
> >
> >That's an advantage for the week it takes to implement the feature.
> >For the remaining age of the universe,
> 
> Err, I didn't say that this is the final syntax. I just want to have a 
> syntax to start with right now. Changing it from a comment to a 
> directive is easy, after parsing is implemented in Parrot.

Why do I get the feeling that Parrot is going to end up stuck supporting
a syntax where:

#line

and

# line  

mean two different things?  If the only good thing that can be said
about using '#' for debug info is that compilers can emit it right now,
supported or not, then it's worth noting that compilers can also emit
'#.debug_hll ...' right now and the '#' can simply be removed when
support for it is ready. 

Cheers,

-J

--


pgpRl94jtcHIp.pgp
Description: PGP signature

a note WRT PASM/PIR compiler end encodings

[Leopold Toetsch]

Tonight on #parrot:

03:15 <@mdiep> meaning that imcc doesn't know it's being feed utf8 
instead of ascii

03:16 <@Coke> mdiep: B***it. it knows the encoding of the string.

*) Parrot's compilers take plain old C-strings and don't know anything 
about the charset/encoding of the string - but read on


*) I'was thinking about changing the interface to pass in a STRING*
   and convert *somehow*.

But given this snippet:

.sub main :main
.local string code, code2
.local pmc compiler, prog
code = <<'EOC'
set S0, iso-8859-1:"Tötsch"
print S0
EOC
code2 = downcase unicode:"END\n"
code .= code2   # code is now utf16/ucs2
compiler = compreg "PASM"
$I0 = find_encoding "utf8"  ## case 1)
trans_encoding code, $I0
# $I0 = find_charset "ascii"## case 2)
# trans_charset code, $I0
prog = compiler(code)
prog()
.end

Case 1 (transcode utf16 to utf8) results in this program being compiled:

set S0, iso-8859-1:"Tötsch"
print S0
end

( ./parrot -D20 foo.pir; cat EVAL_1 )

This is plain wrong, because the string contains now an utf8 encoded 
sequence instead of the latin1 char. Sure the program even prints 
something, but the wrong thing.


Case 2 (convert to ascii) just fails, because the text isn't ascii

"can't convert unicode to ascii"

So now what should we do? I have expressed my opinion several times on 
IRC, with not much success so far: Parrot can't do nothing against this, 
because the code to compile is invalid or wrong or bogus.


It's up to the compiler writer, to produce valid code. Valid for 
PASM/PIR is currently just ascii.


Above program should start with:

code = <<'EOC'
set S0, iso-8859-1:"T\xf6tsch"

That is: everything non-ascii in the source code has to be escaped 
properly, *then* a conversion to ascii succeeds and everything is fine.


We can IMHO just discuss, if Parrot should transcode a program code to 
ascii, or if this is up to the compiler writer.


leo

Re: [perl #37651] [PATCH] Add $LINK_DYNAMIC when linking pbc_merge

[Jonathan Worthington]

"Francois PERRAD" <[EMAIL PROTECTED]> wrote:

>
>This patch is required for pbc_merge on some platforms (HP-UX is the
>one that I see it on), particularly when creating tcllib.

Same problem on Win32, but this patch doesn't solve it with MinGW.

Yup, I know about this problem.  We shouldn't be loading the dynamic 
libraries at all, which is the right fix.  I'll try and sort that out 
sometime soon.


Now a stupid question, why pbc_merge is a big/fat executable and not a 
Perl script or better a PIR program ?


Not really a stupid question.  Writing it in Perl would involve either 
writing packfile handling routines in Perl or using XS to call into Parrot 
packfile handling code, meaning a lot of work.  I'd like to have written it 
in PIR, but at the moment we just don't have facilities for working with 
packfiles or walking bytecode from PIR.  One day we will, then pbc_merge can 
be re-written in PIR.  Writing it in C was the easiest way to get a working 
pbc_merge until that time.


Jonathan 

Re: HLL Debug Segments

[Roger Browne]

Leopold Toetsch wrote:
> I'd much more prefer that a compiler (amber anyone ;) just emits PIR 
> with debug syntax so that folks get a feeling how it looks like...

OK, I've done this.

I have modified the Amber compiler to generate PIR code that contains
debug directives, so that we can discuss a real example.

You can access the generated PIR file from the link on this page:
http://xamber.org/temp/debug.html

There is also a link to the Amber source file from which the PIR is
generated (annotated with line numbers). This is for your interest only;
you don't need to look at it if you are only interested in the PIR debug
directives.

SYNTAX USED:

I have used a syntax that I found convenient to generate, but of course
I will change it to whatever the Parrot project wants to use. It's a
fairly minimal syntax for the most common cases, which are line numbers,
file numbers and column numbers.

I realise that starting these directives with a PIR comment character is
controversial, however in the short term this enables the PIR to remain
runnable, so I have made every directive start with "#.debug ".

If that is followed by a string, it represents the current filename,
e.g.:

   #.debug "foo.am"

An integer represents a line number:

   #.debug 27

A colon separates line numbers and column numbers:

   #.debug 27:9

Other kinds of data are represented by a key (an identifier) followed by
a value (a string or integer). There are two samples of this in the
current PIR file. The first is a zone, which has the value "assertion"
within code that evaluates assertions, and the value "" elsewhere. The
second is a class_number, which is a distinct positive integer for each
class, or 0 for unknown. For example:

   #.debug class_number 4
   #.debug zone "assertion"
   ...
   #.debug zone ""
   ...
   #.debug class_number 0

SOME ISSUES FOR DISCUSSION:

Amber uses natural numbers for counting, so the first column of the first
line is 1:1. A line number of column number of 0 represents 'unknown'. If
PIR uses a different convention, I will adjust the code generation to match.

Amber sometimes generates multiple directives without any intervening
PIR code. Some of these may be 0:0, for constructs where Amber isn't yet
tracking the line/column number, but imcc should accept this. For
example:

   #.debug 48:12
   #.debug 0:0
   #.debug 48:56

RUNNING THE PIR:

If you want to run this PIR, you will need revision 9911 or later of Parrot.
You have to first build the Amber PMCs:

   cd languages/amber ; make pmcs

Then you can run it like this:

   parrot life.pir

This runs a small text-mode display of Conway's game of life for 20
generations (takes only a few seconds). You can choose a different
number of generations by adding a command-line argument:

   parrot life.pir 35

ERROR REPORTING:

I have inserted a trap so that an exception is raised after generation
42 has been displayed. So, if you run the program like this...

   parrot life.pir 50

...then you will get the following message after generation 42:

   This is an Amber exception raised to test error reporting.
   current instr.: 'ANY :: raise' pc 208 (life.pir:81)
   called from Sub 'ROOT_CLASS :: life' pc 1699 (life.pir:656)
   called from Sub 'ROOT_CLASS :: make' pc 1235 (life.pir:495)
   called from Sub '_root' pc 71 (life.pir:39)

In the future, we should be able to report the HLL line numbers instead
of (or in addition to) the PC and PIR counters.

I hope this example is useful for the purposes of discussion, and maybe
also as sample input data for whoever implements this. I will keep the
example updated according to any design decisions that are made.

Regards,
Roger Browne

Re: Perl6 perlplexities

[Piers Cawley]

Rob Kinyon <[EMAIL PROTECTED]> writes:
> First-class blocks make continuations and coros almost neglible to
> implement from an API perspective. Almost makes me wonder how much
> trouble it would be to implement this in P5 ...

Um... tosh. Seriously. Full continuations need some fairly serious retooling of
the call stack if they are to work properly. And one shot continuations are the
next best thing to useless.

-- 
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/

[perl #37684] [RFE] Give parrot a -c-like option

[via RT]

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


It would be somewhat helpful if parrot supported an option like  
perl's -c that verified the code was compilable but did not execute it.

This may be the unix equivalent of:

parrot -o /dev/null foo.pir

But having a command line option would give us more portability.

Chained buts optimizations?

[Aaron Sherman]

This question came out of a joking comment on IRC, but it's a serious
concern. Can chained buts be optimized, or must the compiler strictly
create intermediate metaclasses, classes and objects in the following:

my $a = $b but C but D but E but F;

The difference is between:

my $tmprole = role {
is $b.meta.role;
does C;
does D;
does E;
does F;
};
my $a = $b but $tmprole;

and

my $tmpbc = $b but C;
my $tmpbcd = $tmpbc but D;
my $tmpbcde = $tmpbcd but E;
my $a = $tmpbcde but F;

In the second example, constructors are called 4 times, but in the first
case constructors are called only once sort of. Until you get to
taking about constructors on the metaclasses, but metaclass constructors
still make my head hurt.

The same goes for destructors, but I don't think those get to get called
until everything goes away (since there's a reference chain between
them).

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

Re: Chained buts optimizations?

[Luke Palmer]

On 11/15/05, Aaron Sherman <[EMAIL PROTECTED]> wrote:
> This question came out of a joking comment on IRC, but it's a serious
> concern. Can chained buts be optimized, or must the compiler strictly
> create intermediate metaclasses, classes and objects in the following:
>
> my $a = $b but C but D but E but F;

Certainly.  The semantics should precisely equivalent either way
(constructors don't get called during a rebless, I think).

Luke

Re: Making parrot portable

[Chip Salzenberg]

On Mon, Nov 14, 2005 at 05:19:49PM +0100, Florian Ragwitz wrote:
> After I've collected enough informations I'll start implementing the
> necessary changes. I hope it'll be done by the end of this week. I'm not
> sure how I should handle that though. I guess it might break parrot
> building for a while. So shall I do it in trunk, do a local svk branch
> and provide snapshots or bloat the repository some more and create a new
> svn branch?

If you're doing all your own development and testing, I'd suggest a
local svk branch.  Providing snapshots is welcome but not mandatory.
Once you've experimented enough to know for sure that your changes are
an overall improvement (and specifically that they don't break the
architectures that work now), you could commit your work to the trunk.

Thanks muchly for asking...
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

This week's summary

[The Perl 6 Summarizer]

The Perl 6 Summary for the fortnight ending 2005-11-13
Welcome to another fortnight's worth of summary. We'll get back to a
weekly schedule one of these fine days, you see if we don't.

This fortnight in perl6-compiler
There was a surprisingly large amount of activity on the list, but
again, the place to look for perl6 compiler news is the Planet Perl Six
aggregator.



  PGE improvements and changes
Patrick announced that he'd checked in some major changes to the PGE
internals. The changes include a shiny new shift-reduce operator
precedence parser which is used to parse the rules themselves. PGE
finally has a "" parsing rule which can be used to parse a valid
Perl 6 rule. There are other changes, but those two are the headlines.
Patrick asked for the usual questions, comments, patches and tests.

A couple of days later, he posted a more comprehensive overview of the
new and shiny bits in PGE.





  PGE problem with non-greedy quantifiers
Allison fell foul of some changes in the new PGE. This turned out to be
a bug in PGE, so Patrick fixed it.



  The meaning of \n and \N
Noting that Synopsis 5 says that '"\n" now matches a logical (platform
independent) newline, not just "\012"', Patrick asked the list for more
details about what that should mean so he could get on and implement it
in PGE. He offered up a suggested matching rule. Larry thought that the
suggested rule was close enough for jazz.



  "[]" and "()" on rule modifiers
Patrick continues to work on the PGE. This time he asked about the
behaviour of rule modifiers, with particular reference to the ":w"
modifier. Larry had answers.



  Parrot 0.3.1 "Wart" released
Leo announced the release of Parrot 0.3.1 "Wart", complete with shiny
new features like variable sized register frames and no more spilling, a
much better PGE (see above) and other goodies. The latest release has
more than 3000 tests, and that's probably still not enough.



  Octal in p6rules (and strings)
Patrick Continued his voyage of stringy discovery, this time asking
about the black art of specifying glyphs/bytes/whatever using octal
notation. He wondered about his assumption that the correct way to do it
is with "\o123" by analogy with using "0o123" to specify a number in
octal. He also wanted confirmation that the "\nnn" notation had been
dropped. A surprisingly long discussion ensued as Larry did a good deal
of thinking aloud and Patrick got on with implementing the nailed down
bits.



Meanwhile, in perl6-internals
  SWIGging Parrot
John Lenz is one of the developers a SWIG, which started off as the
Python equivalent to Perl's XS. He had some questions about writing a
SWIG module for parrot and asked if there would be interest in having
SWIG be one of the 'official' ways of doing native calls from Parrot.
Leo thought not, pointing out that Parrot's NCI is fully dynamic and
groovy.



  NCI using ffcall library
Garrett Goebel joined in the ongoing discussion of using ffcall to
implement the Parrot NCI (Native Call Interface) by pointing back to an
earlier discussion of using libffi to implement the Parrot NCI. Last
time round, Dan had pointed out that, because libffi is an external
library, there still needs to be a supported (if possibly hackish) way
of doing NCI that comes with Parrot, but that configure could probe for
external libraries to use where they are available.



  Heredocs in function calls
Patrick wondered if there might be a convenient way to support heredoc
parameters in PIR function calls. Nicholas Clark wondered why one would
bother since most PIR code should be generated code.

Later on, Leo implemented them. About the only place they don't work now
is in macro arguments.





  Simple register allocation
Summarizing a discussion on IRC, Patrick noted that it would be nice if
the PIR compiler had a way to use a very basic register allocation for
.subs that only use a small number of registers. After all, there's
little point in doing a complex analysis of control flow if a sub uses
(say) 5 registers at most. The problem is that this analysis gets harder
as the subs get longer (O(n) on the length of the sub). In the case of
PGE (for instance), the subs can get very long, with lots of control
flow statements, but use a maximum of 10 PMC, 9 int and 4 string
registers for the whole thing.

Warnock applies.



  Careful with that "bsr" Eugene
Leo noted that, with the introduction of variable si

Re: This week's summary

[Roger Browne]

On Tue, 2005-11-15 at 16:24 +, The Perl 6 Summarizer wrote:

>  ...Roger Browne (whose name I keep wanting to use as a Clerihew)...

Thanks for the summaries, Piers! Here's a Clerihew for you:

   Roger Browne
   took his Parrot to town
   Wearing an upside-down
   Amber crown  >:)

   How to write a Clerihew:
   http://www.gigglepoetry.com/poetryclass/clerihew.htm

Regards,
Roger

Re: HLL Debug Segments

[Dave Whipp]

Will Coleda wrote:

Right, the hard bit here was that I needed to specify something other  
than "file". Just agreeing that we need something other than just  
"file/line".


I'd have thought the onus is the other way: justify the use of 
"file/line" as the primitive concept.


We're going to have aset of "parrot compiler tools", which represent 
high level language and subsequent transformations as trees. If these 
trees are available, then all that is needed for debug traceability is a 
pointer/reference to nodes in the tree. If the node has a "get 
file/line" method, then the node (attribute grammar?) can be responsible 
for chaining the information back to the source code, even when things 
like common-subexpression optimizations have been done (the method can 
query the callstack, etc., to resolve this).

Re: RFC: Test::JSON

[chromatic]

On Tue, 2005-11-15 at 09:22 +1100, Adam Kennedy wrote:

> The question is, what level of deps is "crazy" for something that they 
> don't actually need on their computer permanently but only need for 2 
> seconds to install something of yours.

I sleep pretty well at night refusing to support people who don't run
the tests that ship with my modules.  There's my crazy.  If you're (not
you Adam, but the generic you) not willing to give up maybe a couple of
megabytes of disk space for all of the testing modules on the CPAN
altogether, I feel little obligation to spend my free time to help you
debug a problem the hard way.

-- c

Re: context matters

[jerry gay]

On 11/14/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 14, 2005 at 06:59:51PM -0800, jerry gay wrote:
> > it seems that in keyed string access to the match object, the result
> > is returned directly as a string. in keyed integer access to the match
> > object, an intermediate pmc must be used. although the workaround is
> > simple, the lack of symmetry seems odd. is this due to PIR
> > restrictions, or to PGE implementation?
>
> Well, I suppose it can be argued either way.  First, note that
> PGE::Match is a subclass of Hash, so one has available all of the
> (non-integer) keyed methods by default.  The PGE::Match object
> then overloads some (but currently not all) of the *_keyed_int
> methods to be able to provide access to the array component of the
> Match object.
>
> Thus, while PGE::Match currently defines a C<__get_pmc_keyed_int>
> method, it's doesn't yet define a C<__get_string_keyed_int> method.
> So, a statement like
>
>.local string res
>.local pmc match
>res = match[0]
>
> is defaulting to using the inherited op from the Hash class, and
> since there's not an entry at the 0 key in the hash (as opposed to
> the array) you get the null PMC.
>
it seems to me it could inherit from Array as well, but it may not be
a precise fit.

> I guess I should go ahead and provide methods in the match objects
> for the other *_keyed_int operations, if only to avoid this sort of
> confusion and the need to store things to an intermediate pmc.
>
this is probably the better way to go, and seems easy enough to
implement (and test.) :)
i'll take a stab at it, if you don't mind.

> Another possibility may be to simply use the hash for all captures,
> including the "array" captures, thus removing the numbers from
> being valid keys.  Something I read in S05 leads me to believe
> that $/<1> and $/[1] are actually the same, in which case we might
> not need the separate "array component" and *_keyed_int methods
> for Match objects.
>
if my read of S05 is correct, i believe $<1> (and $1) equates to
$/[0]. of course, you may have a newer copy than i do. ;)

i still have some tests to write for match return values, i'll try to
get some tests in for the above based on a close reading of S05.

~jerry

Re: context matters

[Patrick R. Michaud]

On Tue, Nov 15, 2005 at 10:26:05AM -0800, jerry gay wrote:
> > Thus, while PGE::Match currently defines a C<__get_pmc_keyed_int>
> > method, it's doesn't yet define a C<__get_string_keyed_int> method.
> > So, a statement like
> >
> >.local string res
> >.local pmc match
> >res = match[0]
> >
> > is defaulting to using the inherited op from the Hash class, and
> > since there's not an entry at the 0 key in the hash (as opposed to
> > the array) you get the null PMC.
> >
> it seems to me it could inherit from Array as well, but it may not be
> a precise fit.

Worse, I think the two might interact in strange and undesirous
ways.  

> > I guess I should go ahead and provide methods in the match objects
> > for the other *_keyed_int operations, if only to avoid this sort of
> > confusion and the need to store things to an intermediate pmc.
> >
> this is probably the better way to go, and seems easy enough to
> implement (and test.) :)
> i'll take a stab at it, if you don't mind.

Sure, that'd be great!

> if my read of S05 is correct, i believe $<1> (and $1) equates to
> $/[0]. of course, you may have a newer copy than i do. ;)

I have a newer copy.  $<0>, $0, and $/[0] are now all the same.

Pm

Call frame introspection (was Re: PDD20 - Call frames as PMCs)

[Chip Salzenberg]

On Tue, Nov 15, 2005 at 10:17:30AM +0100, Leopold Toetsch wrote:
> Autrijus mentioned on #parrot that we'd need weak pointers at some 
> time. Then we can reconsider callframe PMCs.

Ah, weak pointers.  I remember a time without weak pointers.  It was a
happy time.  Birds chirped in the trees

> >How about if we implement get_caller() on Interpreter and Continuation,
> >rather than Interpreter and Sub?
> 
> ... Interpreter and Sub and Continuation ;-) Dropping the interface 
> from Sub would again need to expose the RetContinuation [...]

I certainly agree that exposing the RetContinuation, which
automatically promotes it and its whole call chain to a full
Continuation, is not something to do routinely.

However, it's a Bad Thing to put get_caller() or any other such call
frame introspection query into the Sub interface.  You might as well
put a filename() query on a Unix inode.[*]  That's gotta go, and it's
gotta not come back.

If caller introspection is common enough that invoking a method on
Interpreter is too slow or inconvenient -- and since we can't use
Continuations as the primary interface for caller queries -- I guess
the next step of optimization would be specialized opcodes for call
frame introspection.  I hope we don't have to go there, and we can
stick with the Interpreter interface for common usage.

> >  Alternatively, I guess we could make
> >get_caller() take two parameters: a Continuation as a starting point
> >(Null would mean "me"), and a number of levels up.
> 
> Hmm. That are 3 params in the method: object, start, level. I guess 
> this needs first some thoughts, how we handle class methods, when 
> invoked by an instance of the class.

What's bad about how it works now?  <- not a rhetorical question

[*] an inode may have as few as zero or as many as USHORT_MAX[**] names,
and finding them all requires scanning a disks's entire directory tree

[**] your mileage may vary
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: This week's summary => Perl 6 perlplexities

[Michele Dondi]

On Tue, 15 Nov 2005, The Perl 6 Summarizer wrote:


 Perl 6 perlplexities
   Michele Dondi worries that the increase in complexity of some aspects of
   Perl 6 is much bigger than the increase in functionality that the
   complexity buys us. In particular Michele is concerned that the Perl 6
   parameter passing and signature stuff is going to be a big loss. People
   mostly disagreed with him. Rob Kinyon made a remark that chimed strongly


To be sure, I never intended to claim that "signature stuff is going to be 
a big loss", and I hope that I didn't. First of all I chose it solely as 
an example. Then the sense that I was trying to convey is that 90% of what 
has already been stuffed in it will already be "the best thing since 
sliced bread", and that trying to fit the remaining 10% of all fancy types 
of parameter passing may not really make it better hence resulting in a 
_possible_ loss.



Michele
--
   "premature optimization is the root of all evil"
- Tad McClellan in clpmisc, "Re: Whats the variable holding the dir seperator?"

Re: Chained buts optimizations?

[Aaron Sherman]

On Tue, 2005-11-15 at 12:30, Luke Palmer wrote:
> On 11/15/05, Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > This question came out of a joking comment on IRC, but it's a serious
> > concern. Can chained buts be optimized, or must the compiler strictly
> > create intermediate metaclasses, classes and objects in the following:
> >
> > my $a = $b but C but D but E but F;
> 
> Certainly.  The semantics should precisely equivalent either way
> (constructors don't get called during a rebless, I think).

So, are you saying that:

$a = $b but C;

is:

$a = $b.clone.rebless(class {is $b.meta.class; does C;});

? Or are you refering to does instead of but (which creates a new
object)? If you are saying the former, then would:

$a = $b but C but D;

be:

$a = $b.clone.rebless(class {is $b.meta.class; does C; does D});

or:

{
my $_tmp = $b.clone.rebless(class {is $b.meta.class; does C;});
$a = $_tmp.clone.rebless(class {is $_tmp.meta.class; does D;});
}

?

This is where the semantic difference arises, since the constructor
and/or destructor for $b.meta.class might well be something that I
expected to be called multiple times, and won't see.

All of that is fine, as far as I'm concerned, as long as we give the
user the proviso that chained buts might be optimized down into a single
cloning operation or not at the compiler's whim, but it could be a nasty
shock if it's not documented, and it's a rather ugly amount of overhead
if we don't allow for the optimization.

-- 
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

Re: Chained buts optimizations?

[Larry Wall]

On Tue, Nov 15, 2005 at 02:11:03PM -0500, Aaron Sherman wrote:
: All of that is fine, as far as I'm concerned, as long as we give the
: user the proviso that chained buts might be optimized down into a single
: cloning operation or not at the compiler's whim, but it could be a nasty
: shock if it's not documented, and it's a rather ugly amount of overhead
: if we don't allow for the optimization.

The situation will probably not arise frequently if we just give people
the opportunity to write

my $a = $b but C | D | E | F;

instead, or whatever our type set notation turns out to be.

Larry

Re: Chained buts optimizations?

[John Macdonald]

On Tue, Nov 15, 2005 at 11:23:49AM -0800, Larry Wall wrote:
> On Tue, Nov 15, 2005 at 02:11:03PM -0500, Aaron Sherman wrote:
> : All of that is fine, as far as I'm concerned, as long as we give the
> : user the proviso that chained buts might be optimized down into a single
> : cloning operation or not at the compiler's whim, but it could be a nasty
> : shock if it's not documented, and it's a rather ugly amount of overhead
> : if we don't allow for the optimization.
> 
> The situation will probably not arise frequently if we just give people
> the opportunity to write
> 
> my $a = $b but C | D | E | F;
> 
> instead, or whatever our type set notation turns out to be.

If adding a but involves calling some code to initialize the
but-iness (I don't know if it does myself), that code might
inspect or operate on the item that is being modified in a way
that would be changed if a previous but had not yet been fully
initialized.  So, the initialization code for each of the buts
(if any) should be called in order.  Reblessing for each one
would only matter if the subsequent but code used introspection
and varied its actions depending on the blessed state.

The choice between:

my $a = $b but C | D | E | F;

and:

my $a = $b but C but D but E but F;

might be used to control the short-cut initialization (which,
would have to be an explicit definition rather than an
optimization since it could have different meaning).

-- 

Re: context matters

[Larry Wall]

On Tue, Nov 15, 2005 at 12:32:38PM -0600, Patrick R. Michaud wrote:
: On Tue, Nov 15, 2005 at 10:26:05AM -0800, jerry gay wrote:
: > > Thus, while PGE::Match currently defines a C<__get_pmc_keyed_int>
: > > method, it's doesn't yet define a C<__get_string_keyed_int> method.
: > > So, a statement like
: > >
: > >.local string res
: > >.local pmc match
: > >res = match[0]
: > >
: > > is defaulting to using the inherited op from the Hash class, and
: > > since there's not an entry at the 0 key in the hash (as opposed to
: > > the array) you get the null PMC.
: > >
: > it seems to me it could inherit from Array as well, but it may not be
: > a precise fit.
: 
: Worse, I think the two might interact in strange and undesirous
: ways.  

Inheritance is wrong here anyway.  We need some kind of basic Tree node
object that *does* Hash, Array, and Item, but isn't any of them.

Think about how you'd want to represent XML, for instance:

~$obj   name of tag, probably
+$obj   number of elements?
+$obj[] number of elements?
+$obj{} number of attributes?
$obj[]  ordered child elements
$obj{}  unordered attributes

But the scalar values don't match up with how Match objects work, so it
would likely have to be:

~$obj   representation of entire 
+$obj   +~$obj (0 with warning?)

Another approach would be to say that we make Hash smart enough to
behave like an array or a scalar in context, and then we write

~%obj   name of tag, probably
+%obj   number of attributes?
+%obj[] number of elements?
%obj[]  elements
%obj{}  attributes

But then hashes should have to store scalars and arrays as "hidden"
keys, and we still have an inconsistent scalar interface.  Plus it
smacks of pseudo-hashery.

Yet another approach is to reinvent typeglobish objects (but without
confusing them with symbol table entries.)  But we've stolen the *
sigil since then.  And it might be more readable to simply be able
to declare highlanderish variables such that

my Node $obj;
my @obj ::= $obj[];
my %obj ::= $obj{};

And otherwise we just stick with $ sigil and semantics.  Basically,
match objects are ordinary objects that merely *contain* other types,
while providing Str, Int, Num, Array and Hash roles.

Of course, we could give syntactic relief in just the declaration
on the order of

my ?obj;# the '?' is negotiable, of course

that implies the creation of a highlander variable.  Outside the
declaration you'd only be able to use one of the real sigils.
Interestingly, though, that kind of implies that ^obj as an rvalue
would give the type of $obj in that scope.

One interesting question is, if you said

my ?obj := %random_hash;

whether it would try to emulate the $ and @ views or merely fail, or
something in between, like returning null lists and undefined values.
Presumably &obj would likely fail unless ?obj contained a code object
of some sort.  It would make sense to allow tests for "exists &obj"
and such.

And then maybe we'd be talking about the ?/ variable rather than the
$/ variable.  And we'd get @/ and %/, FWIW.  Of course, none of this
highlander stuff buys you anything as soon as you go down a level in
the tree (unless you realias the child nodes).  To my mind the main
benefit of declaring something like ?obj rather than $obj is that
you are documenting the expected polymorphism, and only secondarily
that you're claiming all the local "obj" namespaces.

[Followups to p6l.]

Larry

Re: Chained buts optimizations?

[Larry Wall]

On Tue, Nov 15, 2005 at 03:43:59PM -0500, John Macdonald wrote:
: On Tue, Nov 15, 2005 at 11:23:49AM -0800, Larry Wall wrote:
: > On Tue, Nov 15, 2005 at 02:11:03PM -0500, Aaron Sherman wrote:
: > : All of that is fine, as far as I'm concerned, as long as we give the
: > : user the proviso that chained buts might be optimized down into a single
: > : cloning operation or not at the compiler's whim, but it could be a nasty
: > : shock if it's not documented, and it's a rather ugly amount of overhead
: > : if we don't allow for the optimization.
: > 
: > The situation will probably not arise frequently if we just give people
: > the opportunity to write
: > 
: > my $a = $b but C | D | E | F;
: > 
: > instead, or whatever our type set notation turns out to be.
: 
: If adding a but involves calling some code to initialize the
: but-iness (I don't know if it does myself), that code might
: inspect or operate on the item that is being modified in a way
: that would be changed if a previous but had not yet been fully
: initialized.  So, the initialization code for each of the buts
: (if any) should be called in order.  Reblessing for each one
: would only matter if the subsequent but code used introspection
: and varied its actions depending on the blessed state.
: 
: The choice between:
: 
: my $a = $b but C | D | E | F;
: 
: and:
: 
: my $a = $b but C but D but E but F;
: 
: might be used to control the short-cut initialization (which,
: would have to be an explicit definition rather than an
: optimization since it could have different meaning).

Roles are *supposed* to be well behaved.  If there's a difference
between those two notations, it would be that I'd expect the first to
do the normal compile-time collision checking for all the new roles
at once, while the nested form should do run-time mixins at each
step that potentially hide any previous methods of the same name.
You could have intermediate forms like:

my $a = $b but C | D but E | F;

where any E or F methods hide any C or D methods, but it detects collisions
between E and F or between C and D.

Larry

Re: context matters

[Patrick R. Michaud]

On Tue, Nov 15, 2005 at 12:28:30PM -0800, Larry Wall wrote:
> On Tue, Nov 15, 2005 at 12:32:38PM -0600, Patrick R. Michaud wrote:
> : On Tue, Nov 15, 2005 at 10:26:05AM -0800, jerry gay wrote:
> : > > Thus, while PGE::Match currently defines a C<__get_pmc_keyed_int>
> : > > method, it's doesn't yet define a C<__get_string_keyed_int> method.
> [...]
> Inheritance is wrong here anyway.  We need some kind of basic Tree node
> object that *does* Hash, Array, and Item, but isn't any of them.

Agreed; I just went with Hash for the time being as a cheap 
implementation approach for now, and provide interfaces that 
allow Match objects to act in the various roles we have defined
thus far.  I fully suspect the actual type and implementation of 
Match will change as we define and understand the problem space 
a bit better.

The rest of the items in Larry's message I leave for p6l.  :-)

Pm

Re: Private tests

[Chris Dolan]

Tels,

I believe you have misunderstood my intentions.  I was not advocating  
that any algorithmic tests be non-public.  The only tests that should  
be private are ones that satisfy one or more of the following  
restrictions:


   1. require special additional software that’s difficult or  
expensive to acquire,

   2. require special configuration to run properly,
   3. don’t affect the quality of the final software, or
   4. take too long to run.

That is, tests like spell-checking, pod-checking, Perl::Critic and  
ones that take tens of minutes to run.  Naturally, any test whose  
results may vary from machine to machine should be public wherever  
feasible.


After reading some of the insightful comments posted on my blog, I've  
been convinced that the private tests should be included in the CPAN  
distribution, but disabled in some way (perhaps via a file extension  
other than .t?).  That way, resourceful or interested users can run  
the tests but average users don't need to.


The example I included at the end of the article stating a failed  
test under Windows was only tangentially related and perhaps was a  
distraction.  I was saying that perhaps it would be useful if authors  
could assert things about their personal testing experience that  
would be machine readable and useful to others.  In that example I  
was suggesting that the author could announce that the hypothetical  
module was known to fail under Windows and, as a TODO test, was an  
implicit request for help from other developers.


Chris

On Nov 15, 2005, at 4:12 AM, Tels wrote:


-BEGIN PGP SIGNED MESSAGE-

Moin,

On Monday 14 November 2005 18:21, Chris Dolan wrote:


Hello all,

I've just published an article about public vs. private regression
tests.  I've defined private tests as t/*.t files that are for the
author only and don't go in MANIFEST.  Naturally, those don't get as
much publicity as tests included in CPAN distributions.

In the article I advocate that some tests should be private.  In
particular,
   1) those that test non-critical aspects of a module (like
documentation and coding style)
   2) those that are too expensive to run often
   3) those that require special software or customization
In my conclusion I describe a possible system where authors publish
the results of private tests with their distributions as a trust-
based kwalitee system.  That is, authors assert kwalitee rather than
be judged for it.

   http://www.chrisdolan.net/talk/index.php/2005/11/14/private-
regression-tests/

Both positive and negative feedback is very welcome!



Private tests will only be run by the author, meaning they will be  
only

run on a very small subset of all systems the modules can be used on.

This limits their usefullness quite a bit.

Case ein point: I can test my modules on linux, 32 bit, unthreaded,  
under

unicode, and under perl 5.8.x. Thats about it, everything else gets
really really complicated for me to set up and maintain/test.

So, no win32, no mac, now solaris, no irix, no perl 5.6.x, no
iso-something, no EBDIC (or however it is spelled), no threading,  
no 64

bit, no SMP system.

As for 1), these things should matter (the "broken window analogy")  
and
you would be surprised to know how these tests can pass on your  
system,

and still fail on other systesm (forget to include the .pod file in
MANIFEST is the most obvious one).

As for 2), random testing should be employed (Math::BigInt does  
this, it
runs 256 or so tests with random number patterns (and thus known  
results
like "2 * A - A == A"). The tests are quite fast, but they cover  
only a

small subset of potential values. However, since each system and user
runs a new, different random set, you end up with a really huge  
testing

number being run. (Yes, this has found some bugs)

And for 3), this might be the only point I can think that private  
tests

are usefull (I have a private testset for Graph::Easy that I use from
time to time, it is not public mainly because it fails/hangs/takes
forever and is work-in-progress).

However, I have to actually read your article to find out what your
proposal solves (compared to me just running thetest once in a  
while :)


Hope that was usefull :)

Best wishes,

Tels

- --
 Signed on Tue Nov 15 11:04:21 2005 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Now, _you_ behave!"

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQ3m0pHcLPEOTuEwVAQF6lQf8CtubDMQjLdCBcEGNczxZj2Y1kTVhOU7Z
bvweeJe4RWFfmd2JMw7dwiu3Sjb57hNlVkl4LwN+7vx3tm3DsnhRUoMHvkDtCddC
8bfxpLcOi8WMlySAud+unKnpZVwlwn2rZ/enu2Dd01QKOgOQkBr1HWTJUguPv4No
eWT3UiEZhV4hU764gtF7a8raHjbvxpTJcNk22KHnRmyTKX+SugCyI0qkmIQrFntl
cQWXyA9GV7V+5bK5/Sp2eWv2MXX3fhNDxtZywkmqun+6/YhPgSDJQp3FcKThZFYy
WxPXsrXVIXFJbbtkSs+PGe18VdXqEFCHOI29H1+9gyiC3FW3N6AARw==
=GA3y
-END PGP SIGNATURE-



--
Chris Dolan, Software Developer, Clotho Advanced 

Re: Private tests

[chromatic]

On Tue, 2005-11-15 at 15:23 -0600, Chris Dolan wrote:

> After reading some of the insightful comments posted on my blog, I've  
> been convinced that the private tests should be included in the CPAN  
> distribution, but disabled in some way (perhaps via a file extension  
> other than .t?).  That way, resourceful or interested users can run  
> the tests but average users don't need to.

I posted a small Module::Build subclass that shows one way to do this to
Perl Monks:

http://perlmonks.org/?node_id=508160

Perhaps a better approach is to store these tests in a subdirectory of
t/.

-- c

Re: This week's summary

[Leopold Toetsch]

On Nov 15, 2005, at 17:24, The Perl 6 Summarizer wrote:


The Perl 6 Summary for the fortnight ending 2005-11-13



  "string_bitwise_*"


Leo, it seems to boil down to a choice between throwing an 
exception or
simply mashing everything together and marking the 'resulting bit 
mess'

as binary. Warnock applies.


I've today cleaned up the string_bitwise code a bit. These rules apply 
now:


- usage of non-fixed_8 encoded strings in binary string ops throws an 
exception

- else the result string has charset binary, fixed_8 encoded.

Thanks again for your concise summaries,
leo

Announcing "Amber for Parrot 0.3.1 (Magic cookies)"

[Roger Browne]

I have released "Amber for Parrot" version 0.3.1 (Magic cookies):

Downloads: http://xamber.org/download.html
Release history: http://xamber.org/history.html
Project home page: http://xamber.org/index.html

"Amber for Parrot" is an Eiffel-like scripting language for the Parrot
Virtual Machine.

Changes since version 0.3.0:

  - Parrot PMCs are now used to implement classes ARRAY, BOOLEAN,
CHARACTER, INTEGER, STRING and TABLE. This improves
interoperability and performance

  - A new PMC kernel class PATHNAME implements some manipulations
on directory/file pathnames

  - Class JSON performs simple serialization

  - Replaced the test harness with a more useful, more flexible
and easier-to-use November 2005 model

  - Added about 40 new tests

  - A new kernel class INTERNAL can be used for (limited)
introspection

  - Preconditions are no longer checked by default; specify
"--check" to enable runtime checking of all assertions

  - The AMBER_OPTIONS environment variable can be used to set
some command-line options

  - Directives, prefixed with a hash, may be included at the top
of a script and will override the command-line options

  - Implemented a simplified initial version of the 'inspect'
instruction (a kind of case statement)

  - A new option "--debug-info" emits file/line/column/other
info into the generated .pir file

  - Various bug fixes

  - Estimated progress towards release 1.0: language constructs
43%, libraries 6%, documentation 4%, robustness 4%

Roger Browne

Re: Private tests

[Philippe 'BooK' Bruhat]

Le mardi 15 novembre 2005 à 15:23, Chris Dolan écrivait:
> 
> After reading some of the insightful comments posted on my blog, I've  
> been convinced that the private tests should be included in the CPAN  
> distribution, but disabled in some way (perhaps via a file extension  
> other than .t?).  That way, resourceful or interested users can run  
> the tests but average users don't need to.

What about a special environment variable, like RUN_PRIVATE_TESTS?

-- 
 Philippe "BooK" Bruhat

 When you do not think for yourself, no one thinks for you...
(Moral from Groo The Wanderer #61 (Epic))

Re: Private tests

[Adam Kennedy]

Philippe 'BooK' Bruhat wrote:

Le mardi 15 novembre 2005 à 15:23, Chris Dolan écrivait:

After reading some of the insightful comments posted on my blog, I've  
been convinced that the private tests should be included in the CPAN  
distribution, but disabled in some way (perhaps via a file extension  
other than .t?).  That way, resourceful or interested users can run  
the tests but average users don't need to.



What about a special environment variable, like RUN_PRIVATE_TESTS?



I've been working on a concept of taggable tests on some of my larger 
commercial stuff, integrating with the Test::More skip() function, and 
some form of environment variables does indeed seem the best way to do 
such a thing.


For example, with applications that talk to the database, a lot of the 
time I want to be able to just test all the code that doesn't need a 
live production database, or need a database with the production schema, 
or need a schema that it is allowed to modify, and so on and so forth.


So I have a bunch of environment variables like TEST_TAG_DB_RO 
TEST_TAG_DB_RW, TEST_TAG_DB_SCHEMA and so on and so forth.


It seems to be working OK, I'm sure there's be a Test::Tags module in a 
year or something.


Adam K

Re: Private tests

[Chris Dolan]

On Nov 15, 2005, at 3:38 PM, chromatic wrote:

I posted a small Module::Build subclass that shows one way to do  
this to

Perl Monks:

http://perlmonks.org/?node_id=508160


Yeah, I saw that one.


Perhaps a better approach is to store these tests in a subdirectory of
t/.


Beware that M::B has a recursive mode for finding tests.  It's set by  
the author, so you should be safe in this case, but it's a point  
worth remembering.


*light bulb* And in fact, that could be the run-time trigger.  Hmmm

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/)

Re: Private tests

[David Golden]

Adam Kennedy wrote:

What about a special environment variable, like RUN_PRIVATE_TESTS?



I've been working on a concept of taggable tests on some of my larger 
commercial stuff, integrating with the Test::More skip() function, and 
some form of environment variables does indeed seem the best way to do 
such a thing.


Isn't Test::Manifest sort of geared to do this kind of thing?  (Or could be 
extended to do so?)

Re: Private tests

[Adam Kennedy]

David Golden wrote:

Adam Kennedy wrote:


What about a special environment variable, like RUN_PRIVATE_TESTS?



I've been working on a concept of taggable tests on some of my larger 
commercial stuff, integrating with the Test::More skip() function, and 
some form of environment variables does indeed seem the best way to do 
such a thing.



Isn't Test::Manifest sort of geared to do this kind of thing?  (Or could 
be extended to do so?)


No. The manifest solution seems to work very well for specifying order, 
but I wouldn't want to use it for finding testing subsets.


For starters, the tags need to be orthogonal. So if I use the tags 
NEEDS_DNS and NEEDS_DATABASE and NEEDS_APACHE then you need to be able 
to enable or disable the tags/flags individually.


Also, doing it at the manifest level means you can only deal with things 
at a per-file level, which what is much more useful is to do it at a 
sub-test level.


If you are testing something, you can have both it's normal tests and 
just wrap the tests that need the database or DNS or whatever in a skip.


Here's an example of how the output ends up. Excuse the failures, I'm 
working on something :)


[EMAIL PROTECTED]:~/GeoSol/trunk/cgi-bin/test$ wprove -rl
Password:
00_legacy/20050200...ok
00_legacy/20050300...ok
00_legacy/20050900...ok
./01_compile.ok
./02_integrity...ok
./03_database_integrity..ok
456/689 skipped: Skipping: TEST_TAG_DB_RO is disabled
./04_library_apisok
./06_code_symbolsNOK 421
#   Failed test 'GeoSol::Interface::Role::File->can('DataToView')'
#   in ./06_code_symbols.t at line 176.
# GeoSol::Interface::Role::File->can('DataToView') failed
# Looks like you failed 1 test of 798.
./06_code_symbolsdubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 421
Failed 1/798 tests, 99.87% okay
./07_templates...ok
./08_images..ok
auto/geosol__entity..ok
auto/geosol__viewok
auto/geosol_base.ok
auto/geosol_cachemanager.ok
auto/geosol_config...ok
auto/geosol_data__simple.ok
12/14 skipped: Skipping: TEST_TAG_DB_RO is disabled
auto/geosol_data__string.ok
22/25 skipped: Skipping: TEST_TAG_DB_RO is disabled
auto/geosol_data_boolean.ok
auto/geosol_data_datetimeok
auto/geosol_data_integer.ok
auto/geosol_data_listok
auto/geosol_data_longstring..ok
auto/geosol_data_shortstring.ok
auto/geosol_db...ok
13/16 skipped: Skipping: TEST_TAG_DB_RO is disabled
auto/geosol_db_configok
auto/geosol_db_schemaok
9/12 skipped: Skipping: TEST_TAG_DB_RO is disabled
auto/geosol_emailok
auto/geosol_entity_application...ok
auto/geosol_entity_message...ok
auto/geosol_entity_reportok
auto/geosol_entity_resumeok
auto/geosol_entity_session...ok
auto/geosol_entity_user..ok
auto/geosol_fieldok
auto/geosol_html.ok
etc etc...

Adam K

Re: Private tests

[chromatic]

On Tue, 2005-11-15 at 22:33 -0600, Chris Dolan wrote:

> Beware that M::B has a recursive mode for finding tests.  It's set by  
> the author, so you should be safe in this case, but it's a point  
> worth remembering.

I haven't looked at the code again just now, but wouldn't overriding
find_test_files() and filtering out specific subdirectories based on
active environment variables do the trick?

-- c

Error Laziness?

[Luke Palmer]

Here is some perplexing behavior:

say "Foo";
hello there;

sub hello () {
say "Bar";
}

sub there () {
say "Baz";
}

This prints:

Foo
*** No compatible subroutine found: "&hello"
at lazy.p6 line 2, column 1-12

I would expect it to print:

Foo
Baz
*** No compatible subroutine found: "&hello"
at lazy.p6 line 2, column 1-12

(If it didn't die at compile time, which would also be acceptable behavior)

What's up with that?

Re: Error Laziness?

[Luke Palmer]

On 11/16/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Here is some perplexing behavior:
>
> say "Foo";
> hello there;
>
> sub hello () {
> say "Bar";
> }
>
> sub there () {
> say "Baz";
> }
>
> This prints:
>
> Foo
> *** No compatible subroutine found: "&hello"
> at lazy.p6 line 2, column 1-12
>
> I would expect it to print:
>
> Foo
> Baz
> *** No compatible subroutine found: "&hello"
> at lazy.p6 line 2, column 1-12

Okay, this makes sense.  Apparently Pugs supports "is lazy" (cool!). 
So you don't know when to evaluate your arguments until after you've
selected the call.

There are two reasons I've posted to perl6-language this time.  First
of all, is this acceptable behavior?  Is it okay to die before the
arguments to an undefined sub are evaluated?

Second, consider this "is lazy" code:

sub foo ($bar is lazy) {
my $bref = \$bar;
do_something($bref);
}
foo(42);

This will evaluate $bar, even if it is not used in do_something.  In
fact, this will evaluate $bar even if the do_something call is omitted
altogether.  This doesn't give you much control over the time of
evaluation, and presumably if you're saying "is lazy", control is
precisely what you want.

I think we need more control.  I think "is lazy" parameters should
pass a thunk that needs to be call()ed:

sub foo ($bar is lazy) {
say $bar; # says something like Thunk(...)
say $bar();  # evaluates parameter and prints it
say $bar; # still says something like Thunk(...)
say $bar();  # doesn't evaluate again, just fetches
}

Whaddaya think?

Luke