Re: Project Start: Section 1
"Joseph F. Ryan" <[EMAIL PROTECTED]> writes: > Allison Randal wrote: > >>Joseph F. Ryan wrote: >> >>>Patch to where? p/l/perl6? I don't think they should go in its /t; >>>maybe a new directory, /fulltests? >>> >> >>We have standards for a reason. Stick with /t. >> >>Allison >> > Well, my point was that language tests will be different than the > compiler/parser tests for awhile. For instance, take a simple string > substitution test: > > # simple substitution > my $var = "perl5"; > $var =~ s/\d/6/; > > While this is completely valid perl6, and something that might want > to be included in the regex test suite, it won't pass neither the > P6C parser tests, nor the P6C compiler tests, nor the P6C regex > tests, because substitution isn't implemented yet. Therefore, I > don't think that it should be included in the P6C tests. So where > to put it? If it really needs to go in /parrot/languages/perl6/t, > perhaps tests like these could go in somewhere like > /parrot/languages/perl6/t/future ? Mike Schwern gave us TODO tests for a reason. Write the appropriate tests, mark them as TODO; they'll get run, but won't show up as failures in the testing report (unless they suddenly start passing, in which case they're no longer TODO). -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Project Start: Section 1
Luke Palmer <[EMAIL PROTECTED]> writes: >> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm >> Date: Sun, 10 Nov 2002 11:44:43 -0800 >> From: Michael Lazzaro <[EMAIL PROTECTED]> >> >> Determine a schema describing the fields/elements of the documentation, >> in order for the docs to be databased & later sliced in a variety of >> ways (beginner manual, advanced specs, test cases, etc.) Input and/or >> output requirements are, at minimum: >> >> -- as XML >> -- as HTML >> -- as manpage (*roff) >> -- as PDF >> -- as LaTex >> -- as POD >> -- as executable test cases >> >> Note that POD consists of formatting directives, not schema information, >> and so cannot represent the information in a form sufficient for full >> slicing. At this point it would therefore appear that XML is the most >> obvious authoring option. > > I very much dislike XML for writing. Agreed. > It'd be nice to use some kind of "extended POD" or something. > Something that's mostly content, little structure. =begin doc-schema ... =end doc-schema > Of course, a sensible XML format could still be useful. Very > sensible. Representing document metatdata in XML makes a good deal of sense; but with only a very small amount of thought that can be inlined in POD documentation. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Autovivification
On Sat, Nov 09, 2002 at 11:22:45PM -0800, Brent Dax wrote: : I think that, if Perl can determine the type with virtually no : ambiguity, it should autovivify. In this case, since we know they : wanted an array (they used the @ explicitly), we'll autovivify an array. : (I say "virtually no" because one could make the argument that you don't : know if we wanted a standard array or a typed one.) I would not tie autovivification to typing. Autovivification only makes sense when there's an existing value you need to construct a location for, so it really only makes sense in the lvalue of an assignment, (or a parameter that is rw because it's going to be assigned to.) Much of the utility of autovivification goes away if we require typing. And really, the autovivification bugs of Perl 5 have to do with not distinguishing referential context from lvalue context. (And with ops that aren't smart enough to turn an undef ref into an undef value in an *rvalue* context.) So I think Perl 6 should autovivify an untyped array if assigned to. I'm not terribly interested in turning Perl 6 into a language that only DWIMs if you type your variables. On the other side, one might argue that autovivification of untyped arrays could be disallowed under "use strict autoviv" or some such. At some point we'll need to determine how many settings there are on the stricture "knob" for Perl 6, and whether there's any good mechanism for adding new strictures without breaking old code. It seems a little stupid to have to specify which version of strict you're using... Larry
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
On Mon, 11 Nov 2002 17:43:01 +, Dave Whipp wrote: > I see where you are coming from ... but is the IO infrastructure really the > most primitive thing to rely on? It may be at the moment; but I expect > that it will become more complex. C may be a built-in right now; > but it should probably move to a module later. > If we can't rely on C to kill a test (and C; > then things are pretty badly broken (assuming that C exists). It's more than just C, though, because it includes function calls, argument passing, and boolean context. That's why we don't use Test.pm or Test::More for t/op/* in Perl 5. As far as possible, we test units in isolation. > If we are going to pick a very small subset on which almost all tests > will depend ... isn't it better to pick the test-infrastructure itself to be > that dependency; rather that some arbitrary module (like IO). Provided Parrot is tested appropriately, I think we can rely on that baseline. In other words, once Parrot is up and running, we can assume that it has passed all of its tests. Would you be more comfortable with a pure-Parrot test suite? I don't think we're at that point of bootstrapping yet, but it would be nice to test other Parrot-enabled languages. -- c
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
Joseph F. Ryan wrote:
Dave Whipp wrote:
The fact that we don't need C is not a good argument for
not using it. Perl tests should assume that Parrot works!
Right, so whats wrong with using one of parrot's most basic ops? Thats
all perl6 print
is; a small wrapper around a basic parrot feature.
The problem is not that you are (or aren't) using a primitive op. The
problem is that the testing methodology is based on an output-diff.
The most obvious drawback is that the use of a text-diff is that
it separates the "goodness" critera from the detection point.
Instead of saying "assert $a==5", you say
{
...
print $a, "\n";
...
}
CODE
...
5
...
OUT
If you a new to the test, there is a cognitive problem associating
the "5" with the $a. You could try using comments to match them:
{
...
print $a, ' # comparing value of $a', "\n"; # Expect 5
...
}
CODE
...
5 # comparing value of $a
...
OUT
but now you're adding extra fluff: if you change the test,
you've got more places to make mistakes. The alternative
"assert" localises the condition in both time and space.
C is also more scalable. If you are comparing 2 complex
structures (e.g. cyclic graphs), then you have to tediously
produce the golden output (you might choose to run the test,
and then cut-and-paste, but that violates the rule that you
should know the expected result before you run the test).
The alternative to the big output would be to internally check
various predicates on the data; an then print an OK/not-OK
message: but that's just an unencapsulated assert.
And talking of predicates: there are times when you want
to be fuzzy about the expected result: there may be some
freedom of implementation, where exact values are
unimportant, but some trend must be true. Consider:
$start_time = time;
$prev_time = $start_time;
for 1..10 {
sleep 1;
$new_time = time;
assert($new_time >= $prev_time);
$prev_time = $new_time;
}
assert ($new_time - $start_time <= 11);
Writing that as a golden-diff test is somewhat awkward.
There are occasionally reasons to use "print" style
testing; but it should be the exception, not the rule.
Dave.
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
Richard Nuttall wrote: I agree with that. take the example of reverse (array) in this thread. Really, the testing should have a number of other tests to be complete, including thorough testing of boundary conditions. e.g. - tests of reverse on 0. undef 1. Empty list 2. (0..Inf) - Error ? 3. Mixed data types 4. Complex data types 5. Big (long) lists 6. Big (individual items) lists 7. Array References 8. Things that should raise a compile-time error 9. Things that should raise a run-time error This gets pretty boring in main documentation. Writing a complete test suite really also needs reasonable knowledge of how the internals are written in order to understand the kinds of tests that are likely to provoke errors. (More thoughts on this if requested). This get back to defining the focus/level of the testing that we want to achieve. Some of these items may make sense for paranoid testing; but not as part of a comprehensive test suite. Consider item 0. Do we need to test C? The answer is probably "no": conversion of undef to an empty lsit is a property of the list context in the caller. We tested that as part of our compehensive set of arglist evaluations. The reverse function never sees the undef, so we don't need to test it. Item 1 may be worth testing; but then we see that what we realy have is a parameterised test: one control path with multiple datasets. One parametarised test would code most of the other items. The most interesting case is Item:2. This is a question that a user might want to ask. The question is a language-issue, not implementation. Derivative thoughts ask about lazy lists in general (is the reverse still lazy?); and hence onto tied lists. Perhaps there is an interface to list-like objects: perhaps we need to document/test that. In sammary: yes, lists of tests can get boring; and yes, we would want to construct documentation that hide most of the tedious details. I treat it as a challenge: to create a unified infrastructure for documentation and testing, which is neither too tedious for the user, nor too vague for the tester; but which has projections (viewpoints) that give the desired level of boredom. Perhaps its not possible, but we should at least try. Perhaps we can only go as far as creating executable examples as tests. But if we can get that far, then most of the infrastructure for a more detailed (boring) document will be in place. Dave.
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
Dave Whipp wrote: Richard Nuttall wrote: Writing a complete test suite really also needs reasonable knowledge of how the internals are written in order to understand the kinds of tests that are likely to provoke errors. (More thoughts on this if requested). [...] Consider item 0. Do we need to test C? The answer is probably "no": conversion of undef to an empty lsit is a property of the list context in the caller. We tested that as part of our compehensive set of arglist evaluations. The reverse function never sees the undef, so we don't need to test it. This is an example of an awareness of implementation leading to better knowledge about what areas are worth testing. In a previous life, I worked as part of a team (implementing Expert Systems in VAX Pascal actually), and we had one person whose sole aim in life was to design and build test cases. In many cases his complete lack of knowledge of implementation detail was good because he thought up all sorts of tests that were useful because he wasn't as close to the trees as we were, in other cases some of the tests didn't exercise any new functionality because in the itnernals, seemingly different cases were implmented using the same functionality. R.
[CVS ci] JIT t/op/interp_2 - i386
I did check in a fix (or part of it) for restarting JIT. - changed restartable OPs to have jump flag set - test PC (eax) if zero, stop JIT This makes all test succeed on i386/linux under JIT too. Other architectures could follow the scheme of the i386 code, which shouldn't be too hard. Currently they will probably segfault, as these OPs are now marked as doing jumps. For actually making JIT restartable at any PC, I have some ideas too: - after the initial code (Parrot_jit_begin) place a long jump, initially pointing to the first instruction - when PC != code_start, patch this jump to point to the actual location leo
Re: [perl #18336] [PATCH] Segfault in PIO_destroy
[EMAIL PROTECTED] (via RT) wrote: # New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #18336] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18336 > -newhandles = (ParrotIOTable)mem_sys_allocate(size); +newhandles = (ParrotIOTable)mem_sys_allocate_zeroed(size); return newhandles; Thanks, applied, leo
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
On Mon, Nov 11, 2002 at 07:56:32PM -0800, Dave Whipp wrote:
> "Andrew Wilson" <[EMAIL PROTECTED]> wrote
>> Perl's tests are built on Test::More, it uses ok() and is() not
>> assert(). If we're going to be doing test cases for perl 6 then we
>> should do them using perl's standard testing format (i.e. Test::More,
>> Test::Harness, etc.)
>
> I would argue that we should write our tests using perl6's standard
> format -- and we need to define that format. There may be a good
> argument for using the perl5 standards; but we should explore the
> alternatives. "assert" is a generally accepted term: I'm not sure
> why perl should be different.
You could argue that, but I would say that perl 6 already has someone
responsible for making sure it gets tested properly. As far as I know,
when Mike wrote Test::More and redesigned Test::Harness he had perl 6 in
mind.
There is already a list for people interested in testing perl6. perl-qa
is perl 6's testing list. Mike asked them not to put the 6 in the name
because he wanted to raise standards of testing in perl 5 and thought a
6 would put people off. If there is a case for replacing the testing
mechanism then you probably need to argue it on perl-qa.
>> If your program can't do basic I/O it's probably pretty broken. Even
>> if we we're to only rely on the test modules, they also need to be
>> able to communicate with the outside world.
>
> My day-job is ASIC verification: in a previous job I tested
> microprocessor cores. We generally found mechanisms to communicate
> pass/fail without requiring any IO capability. A common method is to
> use the programm counter -- if we execute the instruction at address
> 0x123456, then exit as a PASS; if we reach 0x654321, then fail. (we
> used the assembler to get the addresses of specific pass/fail labels).
Ok, I concede you don't need print to do this stuff. Standard perl
tests (perl 5 current practice) generally don't use print anyway, they
would do
use Test::More Tests => 1;
my $a = some_function('foo');
is($a, 5, "some_function frobnitzes foo correctly");
or:
use Test::More Tests => 1;
is(some_function('foo''), 5, "some_function frobnitzes foo correctly");
which may have been what you wanted to rename as assert.
> We don't need to go to these extremes for perl testing, because we
> have an exit(int) capability. exit(0) means pass: anything else
> (including timeout) is a fail.
>
> The fact that we don't need C is not a good argument for not
> using it. Perl tests should assume that Parrot works!
Was the test you quoted a parrot test? If it is it probably needs to be
lower level and can't use the full gamut of the Testing suite.
There's a case to be made for defining a documentation format that test
cases can be defined in and extracted from. I think though that we need
to be aware that work on perl 6 testing has already been done and make
sure the stuff we produce is useful. There's little point in producing
tests in the wrong format.
andrew
--
Libra: (Sept. 23 - Oct. 23)
You will have one of the worst days of your life next week. However,
since it's one of several thousand worst days of your life, it's not all
that significant.
msg23979/pgp0.pgp
Description: PGP signature
Re: Continuations
On Wed, 06 Nov 2002 10:38:45 +1100, Damian Conway wrote:
> Luke Palmer wrote:
> > I just need a little clarification about yield().
>
> C is exactly like a C, except that when you
> call the subroutine next time, it resumes from after the C.
>
> > how do you tell the difference between a
> > recursive call and fetching the next element? How would you maintain
> > two iterators into the same array?
>
> The re-entry point isn't stored in the subroutine itself. It's stored
> (indexed by optree node) in the current subroutine call frame. Which,
> of course, is preserved when recursive iterator invocations recursively
> yield.
So to get the same yield context, each call to the coroutine has to be from
the same calling frame. If you want to get several values from the same
coroutine, but from different calling contexts, can you avoid the need to
wrap it in a closure?
sub iterate(@foo){
yield $_ for @foo;
undef;
}
# There's probably some perl5/6 confusion here
sub consume(@bar){
my $next = sub{ iterate(@bar); };
while $_ = $next() {
do_stuff($_,$next);
}
}
sub do_stuff($val,$next){
...
if $val ~~ something_or_other() {
my $quux = $next();
...
}
}
--
Peter Haworth [EMAIL PROTECTED]
"...I find myself wondering if Larry Ellison and Tim Curry
were separated at birth...hmm..."
-- Tom Good
Re: [CVS ci] JIT t/op/interp_2 - i386
Leopold Toetsch wrote: > I did check in a fix (or part of it) for restarting JIT. Full restart for JIT/i386 is in CVS now. This implied some changes: - interpreter has now a jit_info * - build_asm had a jit_info on the stack, this is currently static, but will be allocated soon. - architectures have to implement Parrot_jit_restart (currently a dummy is provided, which will of course break t/op/interp_2 and emit warnings about missing return value) Some notes WRT implementation in i386: The first code in JIT is emitted by Parrot_jit_begin, the last 5 bytes of this code are 5 nop's now. When JIT is called again with a pc != code_start, i.e. for restart at pc, then a jump instruction to the native offset to this pc is patched into the JIT code. Other architectures could probably do something similar. The only tricky part is to calculate the jump offset, because offsets are already converted to absolute ptrs into the JIT code when restart is called. leo
Re: Some basic string tests.
On Monday, November 11, 2002, at 02:32 PM, Joseph F. Ryan wrote:
-Things that are currently unimplemented in P6C are in the TODO
folder, per
David Wheeler's suggestion.
That's not actually what I meant. You use TODO blocks in your test
scripts, like this:
TODO: {
local $TODO = "Not yet implemented";
ok( foo(), $test_name );
is( foo(42), 23, $test_name );
};
perldoc Test::More for more information.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Docs Data Format (was Re: Project Start: Section 1)
On Monday, November 11, 2002, at 11:22 PM, Brent Dax wrote: =section 1.1.2.1 Numeric Context Numeric Context is a context full of cheesy goodness. For example, the following code will put C<$obj> in C context: my int $i = $obj; blah blah blah... =seealso Context =seealso Numeric Values =tests Where %glossary_entries's values are a unique entry ID of some sort. And if that's not easy enough for you, you can always add a G construct, or even use L. That seems the best proposal so far. Any objections? Do we have anything to mitigate the list-construction issues yet, or is that part still problematic? MikeL
RE: Docs Data Format (was Re: Project Start: Section 1)
Michael Lazzaro:
# Do we have anything to mitigate the list-construction issues
# yet, or is
# that part still problematic?
Perhaps we can add an =bullet command that's the equivalent of:
=over 4
=item *
(one paragraph)
=back
Unless you're numbering or each bullet handles multiple paragraphs,
there's no reason you need to state the =over/=back explicitly, IMHO.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Docs Testing Format (was Re: HOWTO: Writing Perl6 Tests)
I've asked Allison to give us someone on p6i who can tell us exactly what tests are appropriate and how they should be coded, assuming she can get someone to agree to it. ;-) I expect that person should be able to tell us exactly (1) what sorts of tests they want, and (2) how we should build them, and we should Do What They Say. They've been asking for assistance in writing test cases, and we're a perfect group to help do that, since we're going to have to get into & discuss all the edge cases anyway. But I would imagine that in order to be helpful at all to p6i and QA, we need to make the tests paranoid, tedious, and as encompassing as possible. There may be implementation-specific tests (like memleaks, etc.) we can't help much with, but syntax and behavioral issues, we can. I think our largest goal should be to be able to organize the tests exactly as the documentation is organized. That doesn't mean anyone will ever see it, other than us and the testers, but if we can coordinate them as a unified effort we can (I hope) make life much easier for the poor souls who will have to track down and add future tests. So from our standpoint, I would propose we simply have fields in each sub*section like (?): =test_group general string behaviors =test conversion to boolean ... code ... =test conversion from boolean ... code ... That information can then be sliced out and displayed in whatever formats we need... for example, exported into /t files automatically. Comments? MikeL
Re: Project Start: Section 1
On Mon, Nov 11, 2002 at 10:34:00AM -0800, Michael Lazzaro wrote: : (I'm also hoping POD itself will change to be more descriptive, perhaps : partly based on what we learn here, but that'll be in the distant : future.) You are certainly authorized to experiment with POD variants in the near future. We've already said that POD will be changing, particularly in the semantics of =for/=end. Oh, and don't be fooled by C<>, B<>, and I<>. They're actually descriptive. They don't stand for courier, bold, and italic--they actually stand for "Code", "Brawny", and, er... "Imphasis". Yeah. Larry
RE: Docs Testing Format (was Re: HOWTO: Writing Perl6 Tests)
Michael Lazzaro:
# But I would imagine that in order to be helpful at all to p6i and QA,
# we need to make the tests paranoid, tedious, and as encompassing as
# possible. There may be implementation-specific tests (like memleaks,
# etc.) we can't help much with, but syntax and behavioral
# issues, we can.
#
# I think our largest goal should be to be able to organize the tests
# exactly as the documentation is organized. That doesn't mean anyone
# will ever see it, other than us and the testers, but if we can
# coordinate them as a unified effort we can (I hope) make life much
# easier for the poor souls who will have to track down and add future
# tests.
#
# So from our standpoint, I would propose we simply have fields in each
# sub*section like (?):
#
# =test_group general string behaviors
#
# =test conversion to boolean
# ... code ...
#
# =test conversion from boolean
# ... code ...
#
# That information can then be sliced out and displayed in whatever
# formats we need... for example, exported into /t files automatically.
#
# Comments?
Why use POD like this instead of a more atomic version of the standard
testing format used by Perl 5? We can use the directory structure to
organize things. Since most tests are not worthy of inclusion in the
docs (do you really want "$foo eq reverse scalar reverse $foo" in the
documentation for reverse()?) I don't see why we can't do this.
t/
var/
scalar/
string/
to_bool.t
from_bool.t
...
regress.t
num/
bool/
ref/
typed/
prop/
taint/
array/
normal/
sized/
typed/
hash/
normal/
restricted/
typed/
code/
normal/
proto/
vari/
curry/
anonymous/
placehold/
oper/
normal/
arithmetic.t
string.t
list.t
logic.t
junction.t
misc.t
vector/
arithmetic.t
string.t
list.t
junction.t
misc.t
regex/
alone/
grammar/
TestGrm/
module/
TestMod/
meta.t
export.t
globals.t
class/
TestCls/
...
t/string/to_bool.t:
use Test tests => 4;
$str="This string is true!";
ok(?$str, "True value is true");
$str="0truetruetruetruetrue";
ok(?$str, "String beginning with 0 is still true");
$str="0";
ok(?$str, "0 is false");
$str="";
ok(?$str, "Empty string is false");
This way, you can still echo the structure of the documentation, but the
tests don't clutter up the docs.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: Docs Testing Format (was Re: HOWTO: Writing Perl6 Tests)
On Tue, Nov 12, 2002 at 09:22:37AM -0800, Michael Lazzaro wrote: > But I would imagine that in order to be helpful at all to p6i and QA, > we need to make the tests paranoid, tedious, and as encompassing as > possible. There may be implementation-specific tests (like memleaks, > etc.) we can't help much with, but syntax and behavioral issues, we can. I think we'd be much better erring on the side of slightly too paranoid than not paranoid enough. > I think our largest goal should be to be able to organize the tests > exactly as the documentation is organized. That doesn't mean anyone > will ever see it, other than us and the testers, but if we can > coordinate them as a unified effort we can (I hope) make life much > easier for the poor souls who will have to track down and add future > tests. > > So from our standpoint, I would propose we simply have fields in each > sub*section like (?): > > =test_group general string behaviors > > =test conversion to boolean > ... code ... > > =test conversion from boolean > ... code ... > > That information can then be sliced out and displayed in whatever > formats we need... for example, exported into /t files automatically. > > Comments? Looks good to me. andrew -- Aquarius: (Jan. 20 - Feb. 18) It's not true that all the good band names are taken. But if believing that keeps you from starting a band, great. msg23988/pgp0.pgp Description: PGP signature
Re: Docs Testing Format (was Re: HOWTO: Writing Perl6 Tests)
On Tuesday, November 12, 2002, at 10:01 AM, Brent Dax wrote: Why use POD like this instead of a more atomic version of the standard testing format used by Perl 5? We can use the directory structure to organize things. Since most tests are not worthy of inclusion in the docs (do you really want "$foo eq reverse scalar reverse $foo" in the documentation for reverse()?) I don't see why we can't do this. Dunno, looking for a way where we can harness the authors for producing tests in the least-intimidating way. I'm not really thinking that the tests will be a useful, displayable part of the docs, but I figure the closer we can tie it into writing each docs section, the more likely we'll be to get contributors to actually think about it & do it. I could be wrong there, tho... MikeL
RE: Project Start: Section 1
Larry Wall wrote: > > On Mon, Nov 11, 2002 at 10:34:00AM -0800, Michael Lazzaro wrote: > : (I'm also hoping POD itself will change to be more > : descriptive, perhaps partly based on what we learn here, but > : that'll be in the distant future.) > > You are certainly authorized to experiment with POD variants in the > near future. We've already said that POD will be changing, > particularly in the semantics of =for/=end. Perhaps Sean O'Rouke (POD person and the Perl6 grammarian) or some other knowledgible individual can point us in the direction any particularly good documentation, articles, and/or code examples of how to mess around with extending POD and pod parsers. Brent Dax wrote: > > Perhaps we can add an =bullet command that's the equivalent of: > > =over 4 > > =item * > > (one paragraph) > > =back > > Unless you're numbering or each bullet handles multiple > paragraphs, there's no reason you need to state the =over/=back > explicitly, IMHO. I wonder if it'd be feasible to do lists something like: *> level1 >> level2 +>>> level3 * level4 >>> level3 <<< << > level1 < resulting in: * level1 - level2 1 level3 o level4 2 level3 * level1 Where the * signifies unordered, + ordered, > over, and < back? And if there really is no reason to explicitly require the =back, then it'd look even better: *> level1 >> level2 +>>> level3 * level4 >>> level3 > level1 Or if the leading = really must be required: =*> level1 =>> level2 =+>>> level3 =* level4 =>>> level3 => level1 -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
RE: Project Start: Section 1
Garrett Goebel:
# =*> level1
# =>> level2
# =+>>> level3
# =* level4
# =>>> level3
# => level1
Too much punctuation, IMHO. If it ever does become necessary to do
multi-level bulleting and stuff, we might as well make it explicit with
=over/=back.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
On Mon, Nov 11, 2002 at 09:49:35PM -0800, Dave Whipp wrote: : This get back to defining the focus/level of the testing that we want to : achieve. Some of these items may make sense for paranoid testing; but : not as part of a comprehensive test suite. Er, I thought it was paranoia that makes a test suite comprehensive... :-) : Consider item 0. Do we need to test C? The answer is : probably "no": conversion of undef to an empty lsit is a property of the : list context in the caller. We tested that as part of our compehensive : set of arglist evaluations. The reverse function never sees the undef, : so we don't need to test it. Just as a nitpick, reverse(undef) does not produce a null list. An undef in list context is still a scalar value. : Item 1 may be worth testing; but then we see that what we realy have is : a parameterised test: one control path with multiple datasets. One : parametarised test would code most of the other items. : : The most interesting case is Item:2. This is a question that a user : might want to ask. The question is a language-issue, not implementation. : Derivative thoughts ask about lazy lists in general (is the reverse : still lazy?); and hence onto tied lists. Perhaps there is an interface : to list-like objects: perhaps we need to document/test that. I think a major point that everyone's missing here is that there may well no longer be a single global &*reverse function anymore, or if there is, it'll defer the actual reversing of list elements to the list object in question, just as &*print defers to the object's stringification and/or print methods. So a reverse on a lazy list may or may not work, depending on whether the lazy list object knows how to reverse itself. So in reverse 1,2,3..Inf (3..Inf).reverse may choose to fail, or it may choose to return Inf,Inf,Inf,Inf,Inf... ad nauseum. It will be a pervasive problem to decide whether to organize these tests from the viewpoint of the underlying class or the overlying user view. My guess is we end up doing both, because both views need to work. Larry
Re: Project Start: Section 1
On Tue, Nov 12, 2002 at 12:06:13PM -0600, Garrett Goebel wrote: > Or if the leading = really must be required: > > =*> level1 > =>> level2 > =+>>> level3 > =* level4 > =>>> level3 > => level1 What about this for bulletted lists: =item * level1 =item ** level2 =item *** level3 =item level4 =item *** level3 =item * level1 and this for ordered lists: =item # level1 =item ## level2 =item ### level3 =item level4 =item ### level3 =item # level1 -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: Project Start: Section 1
Brent Dax wrote: > > Garrett Goebel: > # =*> level1 > # =>> level2 > # =+>>> level3 > # =* level4 > # =>>> level3 > # => level1 > > Too much punctuation, IMHO. If it ever does become necessary to do > multi-level bulleting and stuff, we might as well make it > explicit with =over/=back. Really? Which requires more typing => or =bullet? The think I don't like about =over/=back, is that each POD command has to be separated by a newline. So a significant portion of your visible screen becomes filled with pod commands instead of whatever you're trying to document. At least for me, the amount I can conceptualize is closely linked to the amount of information I can fit on my screen... I figured => would do the default of unordered unless the current list item type is modified. So for doing bullets, I'd imagine it'd look like: => item1 => item2 => item3 But I wanted to allow a syntax that would allow you the author to switch between unordered and ordered without having to retype the prefix for every item in the list. I.e., without worrying whether the current formatter will only look at the first =item to decide how to format the list... Though in the end, any changes to POD that reduce typing and conserve screen real-estate are fine by me ;) Garrett -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Project Start: Section 1
On Tue, Nov 12, 2002 at 12:16:53PM -0600, Jonathan Scott Duff wrote: > On Tue, Nov 12, 2002 at 12:06:13PM -0600, Garrett Goebel wrote: > > Or if the leading = really must be required: > > > > =*> level1 > > =>> level2 > > =+>>> level3 > > =* level4 > > =>>> level3 > > => level1 I don't like this much, I think it looks untidy. We're you planning to make the indentation mandatory? > What about this for bulletted lists: > > =item * level1 > =item ** level2 > =item *** level3 > =item level4 > =item *** level3 > =item * level1 > > and this for ordered lists: > > =item # level1 > =item ## level2 > =item ### level3 > =item level4 > =item ### level3 > =item # level1 This looks much nicer to me. andrew -- Aquarius: (Jan. 20 - Feb. 18) You won't be too worried about the buildup of trinitrotolulene in your system, until you figure out it's the scientific term for dynamite.
Re: Docs Testing Format (was Re: HOWTO: Writing Perl6 Tests)
On Tue, 12 Nov 2002 10:00:05 +, Michael Lazzaro wrote: > On Tuesday, November 12, 2002, at 10:01 AM, Brent Dax wrote: >> Why use POD like this instead of a more atomic version of the standard >> testing format used by Perl 5? We can use the directory structure to >> organize things. Since most tests are not worthy of inclusion in the >> docs (do you really want "$foo eq reverse scalar reverse $foo" in the >> documentation for reverse()?) I don't see why we can't do this. > Dunno, looking for a way where we can harness the authors for producing > tests in the least-intimidating way. I'm not really thinking that the > tests will be a useful, displayable part of the docs, but I figure the > closer we can tie it into writing each docs section, the more likely > we'll be to get contributors to actually think about it & do it. I > could be wrong there, tho... Advantages of inline tests: - close to the documentation - one place to update - harder for people to update docs without finding code Disadvantages: - doc tools must skip tests normally - pure-doc patches are harder - some tests (bugs, regressions) don't naturally fit in docs - makes docs much larger - adds an extra step to extract tests before running them - adds weight to installed documents (or they must be extracted) Advantages of external tests: - tests can be grouped by purpose/thing tested within tests - test files can be smaller - individual tests can be run during development - tests can be grouped by subsystem/purpose Disadvantages of external tests: - proper organization is important - multiplies files - doc patchers may find test to patch and vice versa On the whole, I prefer external tests. Brent's schema looks good. In Perl 5 land, the culture expects documentation and test patches with the addition of a new feature. I think we can cultivate that for Perl 6. As Brent also alluded, there will probably be standalone regression tests anyway. Most everything else is solvable by the right kinds of community pressure. "Don't know where to put your test? Look in t/scalar/DWIM/numify.t." -- c
RE: Project Start: Section 1
Garrett Goebel:
# Brent Dax wrote:
# >
# > Garrett Goebel:
# > # =*> level1
# > # =>> level2
# > # =+>>> level3
# > # =* level4
# > # =>>> level3
# > # => level1
# >
# > Too much punctuation, IMHO. If it ever does become necessary to do
# > multi-level bulleting and stuff, we might as well make it explicit
# > with =over/=back.
#
# Really? Which requires more typing => or =bullet?
Actually, I find short words easier to type than a single punctuation
character.
Which is easier to read and understand? Remember, the meaning of => in
Perl code is very, very different from a bullet. This isn't in Perl
code, but it's still psychologically weird to have it mean something so
different.
# The think I don't like about =over/=back, is that each POD
# command has to be separated by a newline. So a significant
# portion of your visible screen becomes filled with pod
# commands instead of whatever you're trying to document. At
# least for me, the amount I can conceptualize is closely
# linked to the amount of information I can fit on my screen...
OK, that's a legitimate gripe. It's also a separate one. Can we adjust
POD so that you don't need an extra newline between commands?
Personally, I don't see a problem with making all /^^=/ magical.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
RE: Docs Testing Format (was Re: HOWTO: Writing Perl6 Tests)
Michael Lazzaro:
# On Tuesday, November 12, 2002, at 10:01 AM, Brent Dax wrote:
# > Why use POD like this instead of a more atomic version of
# the standard
# > testing format used by Perl 5? We can use the directory
#
# Dunno, looking for a way where we can harness the authors for
# producing
# tests in the least-intimidating way. I'm not really thinking
I suspect that adding more work to the authors's job will just scare
away potential authors. "I'd love to write the docs for tainting! Wait
a minute, I have to write the tests, too? I don't have time for *that*
much work!"
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
RE: Project Start: Section 1
Andrew Wilson wrote: > > On Tue, Nov 12, 2002 at 12:16:53PM -0600, Jonathan Scott Duff wrote: > > On Tue, Nov 12, 2002 at 12:06:13PM -0600, Garrett Goebel wrote: > > > Or if the leading = really must be required: > > > > > > =*> level1 > > > =>> level2 > > > =+>>> level3 > > > =* level4 > > > =>>> level3 > > > => level1 > > I don't like this much, I think it looks untidy. We're you > planning to make the indentation mandatory? Nope not mandatory, just easier on the reader's eyes it the author choses to do so... I don't imagine most people would switch back and forth between unordered and ordered list. So an example similar to Scott's could be: =* => level1 =>> level2 =>>> level3 = level4 =>>> level3 =>> level2 => level1 and =+ => level1 =>> level2 =>>> level3 = level4 =>>> level3 =>> level2 => level1 Assuming =* and =+ toggle the list unordered/ordered default. The =*> syntax would assumably allow you to toggle the default for a specific level... I'd be glad to take this off-list for anyone who'd like to continue this thread... Garrett
Re: Docs Testing Format
On Tuesday, November 12, 2002, at 10:47 AM, chromatic wrote: On the whole, I prefer external tests. Brent's schema looks good. OK, good enough for me. Without objection, let's do it that way. MikeL
Re: The eternal "use XXX instead of POD" debate (was: Project Start: ?Section 1)
On Mon, Nov 11, 2002 at 03:50:34PM -0800, Damien Neil wrote: : I'd love to see a cleaner POD, with tables, better support for lists, : and the ability to turn syntax inferencing on a per-document basis. We used a preprocessor to put tables into the POD for the Camel. Lists don't seem to occur all that often in technical docs, so it doesn't seem to be all that big a problem in practice, though we could certainly talk about improvements. As for per-document policy, there should certainly be some kind of =use module directive that, like Perl's C, is something more than just an "include". Larry
Re: Docs Testing Format (was Re: HOWTO: Writing Perl6 Tests)
"Chromatic" <[EMAIL PROTECTED]> wrote: > Advantages of inline tests: > - close to the documentation > - one place to update > - harder for people to update docs without finding code Plus, it gives us a mechanism to validate example-code within documents > Disadvantages: > - doc tools must skip tests normally > - pure-doc patches are harder > - some tests (bugs, regressions) don't naturally fit in docs > - makes docs much larger > - adds an extra step to extract tests before running them > - adds weight to installed documents (or they must be extracted) These seem to be reasonable arguments: though issues of file-size and the need for extraction seem a bit weak. Oh, and bugs do belong in documents: "erata". The majority of tests do not belong in documents, for the simple reason that they are implementation-centric, not user-centric. But then, in perl, every file can contain POD, so even external-test files can be documents (documents that are not part ofthe perl6 documentation project). > Advantages of external tests: > - tests can be grouped by purpose/thing tested within tests > - test files can be smaller > - individual tests can be run during development > - tests can be grouped by subsystem/purpose All of these seem to be red-herrings: obviously the individual files are smaller if you split them: but the boiler plate probably makes the total size greater then for the integrated form. Similarly, arguments based on structure are probably neutral. All formats will have structure; and all will/should allow us to run individual tests. The important arguments should be based on human psychology: which is easier to comprehend and maintain? > Disadvantages of external tests: > - proper organization is important > - multiplies files > - doc patchers may find test to patch and vice versa These are red-herrings too. Proper organisation is always important; you'll always have multiple files (and if you include tests as part of the document files, you'll probably end up with more doc files). It may be true that doc patchers need to find corresponding tests ... but its quite easy to miss a test even if its in the same file. > On the whole, I prefer external tests. Brent's schema looks good. > > In Perl 5 land, the culture expects documentation and test patches with the > addition of a new feature. I think we can cultivate that for Perl 6. As > Brent also alluded, there will probably be standalone regression tests anyway. Maybe there's a terminology problem: but what is a regression test? In my world, we create a regression by running existing tests: we don't write a special test suite for the regression. There may be a small number of tests that we exclude from the regression, but then the special case is the non-regressed tests. I'm happy pick a format and run with it. When we've a few micro-sections done, then we can review. I see (in another post) that Mike has opted for external, "without objection". I'm abstaining. But I would like to see executable examples as part of the docs. Dave.
Literal Values
I've written a frist version of the "1.1 - Literal Values" subsection
(in Michael's schema).
It discusses the different ways of creating literal numbers and
strings in perl6.
There are no tests, and the format may be outdated. I will gladly
resubmit this in a more complete form.
I have directly stolen some paragraphs from perl5 documentation.
Special prize to the one who lists all the original sources!
This is just a tentative draft, so feel free to delete/add at your own
taste.
Does it look ok? Any comments? (including grammar errors, of course)
-angel
---
=subsection Literal Values
=head1 Literal numbers
=head2 Integers
Integers can be represented by its decimal representation,
such as:
my $x = 14; # stores the integer 14 in $x
You can also write the number in any other base, using the
C syntax.
For example:
my $x = 2:101110; #binary
my $x = 3:1210112; #tertiary
my $3 = 8:1270; #octal
my $x = 16:1E3A7; #hexadecimal
my $x = 256:255.255.255.0; #256-base
As you can see, when the base is greater than 10, there
is a need to represent digits that are greater than 9.
You can do this in two ways:
=over
=item *
Alphabetic characters: Following the standard
convention, perl will interpret the A letter as the digit 10,
the B letter as digit 11, and so on.
=item *
Separating by dots: You can also write each digit in
its decimal representation, and separate digits using the
C<.> character.
=back
For example, the integer 30 can be written in hexadecimal
base in two equivalent ways:
my $x = 16:1D
my $x = 16:1.14
This two representations are incompatible, so writing
something like C<16:D.13> will generate a compile-time error.
Finally, you can create negative integers prepending the
C<-> character.
For example:
my $x = 18;
my $x = -18;
=head2 Floating Point-Numbers
You can use the decimal representation of the number and
the standard exponental notation.
my $x = -2.542;
my $x = 7.823e12;
Perl lets you operate integer numbers with floating-point
numbers, so the following operation is correct:
print 3.5 + 2; # prints 5.5
=head1 Literal strings
Duble quotes or single quotes may be used around literal
strings:
print "Hello, world";
print 'Hello, world';
However, only double quotes "interpolate" variables and
special characters such as newlines ("\n"):
print "Hello, $name\n"; # works fine
print 'Hello, $name\n'; # prints $name\n literally
my $x = 'world';
print "Hello, $x";# Hello, world
You can type any character including newlines and tabs
in literal strings:
my $x = 'Look mum, I can type
newlines and tabs too!';
If you use a Unicode editor to edit your program,
Unicode characters may occur directly within the
literal strings.
Unicode characters can also be added to a doble-quoted
string using the C<\x{...}> notation. The Unicode code
for the desired character, in hexadecimal, should be
placed in the braces. For instance, a smiley face is
C<\x{263A}>.
Perl provides escapes for easily inserting characters
that have a codepoint below 256:
print "\xB" # Hexadecimal - character number 16:xA
print "\024" # Octal - character number 8:33
Aditionally, you can use the C<\N{...}> notation and
put the official Unicode character name within the
braces, such as C<\N{WHITE SMILING FACE}>.
See the L section for a full explanation
of the interpolation mechanism and a list of special
characters in doble-quoted strings.
=head2 String as vector of ordinals
Literals of the form C are parsed as a string
composed of characters with the specified ordinals. This
is an alternative, more readable way to construct
(possibly unicode) strings instead of interpolating
characters, as in C<\x{1}\x{2}\x{3}\x{4}>. The leading C
may be omitted if there are more than two ordinals, so
C<1.2.3> is parsed the same as C.
Re: Docs Testing Format (was Re: HOWTO: Writing Perl6 Tests)
On Tue, Nov 12, 2002 at 11:21:09AM -0800, Brent Dax wrote: > Michael Lazzaro: > # On Tuesday, November 12, 2002, at 10:01 AM, Brent Dax wrote: > # > Why use POD like this instead of a more atomic version of the > # > standard testing format used by Perl 5? We can use the directory > # > # Dunno, looking for a way where we can harness the authors for > # producing tests in the least-intimidating way. > > I suspect that adding more work to the authors's job will just scare > away potential authors. "I'd love to write the docs for tainting! Wait > a minute, I have to write the tests, too? I don't have time for *that* > much work!" I agree. We should be flexible. But it's really up to the pumpkin holder. I'd think that patches that come with both docs and tests get priority over those that don't have both, but they all have the potential to be applied. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Literal Values
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> From: Angel Faus <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Organization: vLex.com
> Date: Tue, 12 Nov 2002 21:03:30 +0100
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> I've written a frist version of the "1.1 - Literal Values" subsection
> (in Michael's schema).
>
> It discusses the different ways of creating literal numbers and
> strings in perl6.
>
> There are no tests, and the format may be outdated. I will gladly
> resubmit this in a more complete form.
>
> I have directly stolen some paragraphs from perl5 documentation.
> Special prize to the one who lists all the original sources!
>
> This is just a tentative draft, so feel free to delete/add at your own
> taste.
>
> Does it look ok? Any comments? (including grammar errors, of course)
>
> -angel
>
> ---
> =subsection Literal Values
>
> =head1 Literal numbers
>
> =head2 Integers
>
> Integers can be represented by its decimal representation,
> such as:
s/Integers/An integer/
> my $x = 14; # stores the integer 14 in $x
>
> See the L section for a full explanation
> of the interpolation mechanism and a list of special
> characters in doble-quoted strings.
s/doble/double/
> =head2 String as vector of ordinals
>
> Literals of the form C are parsed as a string
> composed of characters with the specified ordinals. This
> is an alternative, more readable way to construct
> (possibly unicode) strings instead of interpolating
> characters, as in C<\x{1}\x{2}\x{3}\x{4}>. The leading C
> may be omitted if there are more than two ordinals, so
> C<1.2.3> is parsed the same as C.
This is equivalent to 256:1.2.3.4
Looks good :)
Luke
Re: Docs Testing Format (was Re: HOWTO: Writing Perl6 Tests)
On Tuesday, November 12, 2002, at 12:03 PM, Dave Whipp wrote: I'm happy pick a format and run with it. When we've a few micro-sections done, then we can review. I see (in another post) that Mike has opted for external, "without objection". I'm abstaining. But I would like to see executable examples as part of the docs. Yeah, let's review after we get a few sections in and see if we want to change our minds. I generally like the idea, but if the people writing the tests now aren't keen on it, they should win. MikeL
Re: Literal Values
On Tue, Nov 12, 2002 at 09:03:30PM +0100, Angel Faus wrote: > This is just a tentative draft, so feel free to delete/add at your own > taste. > > Does it look ok? Any comments? (including grammar errors, of course) I've tweaked the first bit on literal integers a bit, see what you think. =subsection Literal Values =head1 Literal numbers =head2 Integers There are many ways to specify literal numeric values in perl, but they default to base 10 for input and output. Once the number has been read by perl it becomes just a magnitude. That is it loses all trace of the way it was originally represented and is just a number. This code for instance prints the literal value 14. my $x = 14; # stores the integer 14 in $x print $x; You can represent the literal value in any other base, using the C syntax. For example: my $i = 2:101110; # binary my $j = 3:1210112; # tertiary my $k = 8:1270; # octal Printing these would give 46, 1310, and 696 respectively. When the base is greater than 10, there is a need to represent digits that are greater than 9. You can do this in two ways: =over =item * Alphabetic characters: Following the standard convention, perl will interpret the A letter as the digit 10, the B letter as digit 11, and so on. my $l = 16:1E3A7; # hexadecimal =item * Separating by dots: You can also write each digit in its decimal representation, and separate digits using the C<.> character. my $m = 256:255.255.255.0; # 256-base =back For example, the integer 30 can be written in hexadecimal base in two equivalent ways: my $x = 16:1D my $x = 16:1.14 These two representations are incompatible, so writing something like C<16:D.13> will generate a compile-time error. Finally, you can create negative integers by prepending the C<-> character. For example: my $x = 18; my $y = -18; andrew -- Leo: (July 23 - Aug. 22) The only thing that keeps you from realizing your potential is the depressing awareness that it probably wouldn't take much time or effort. msg24007/pgp0.pgp Description: PGP signature
doubled messages??
Is anyone else getting all the traffic from this list twice? I don't get it from any of the other p6 lists, so I'm not quite sure what's up. --Dks
Re: [CVS ci] JIT t/op/interp_2 - i386
On Tue, Nov 12, 2002 at 04:03:35PM +0100, Leopold Toetsch wrote: > Some notes WRT implementation in i386: > The first code in JIT is emitted by Parrot_jit_begin, the last 5 bytes > of this code are 5 nop's now. > When JIT is called again with a pc != code_start, i.e. for restart at > pc, then a jump instruction to the native offset to this pc is patched > into the JIT code. Instead of patching the code, we can pass pc to the native code and have the preamble jump to the corresponding native code address. This avoids the need to flush the instruction cache since we don't modify any code that the CPU has already executed. This works for now, but the way I was going to fix this was to call longjmp (through a wrapper function) from the native code in order to exit the native code and get back to the runops loop. Once multiple bytecode segments become a reality, this will be necessary as the native code will need to transfer control to an interpreter loop in order to execute code that has not been compiled. -- Jason
Re: [CVS ci] JIT t/op/interp_2 - i386
Jason Gloudon wrote: On Tue, Nov 12, 2002 at 04:03:35PM +0100, Leopold Toetsch wrote: When JIT is called again with a pc != code_start, i.e. for restart at pc, then a jump instruction to the native offset to this pc is patched into the JIT code. Instead of patching the code, we can pass pc to the native code and have the preamble jump to the corresponding native code address. This avoids the need to flush the instruction cache since we don't modify any code that the CPU has already executed. Yes, this was my first intention, how to implement this beast. But I know very little aboit i386 asm, so I took the more simple approach. This works for now, but the way I was going to fix this was to call longjmp (through a wrapper function) from the native code in order to exit the native code and get back to the runops loop. Once multiple bytecode segments become a reality, this will be necessary as the native code will need to transfer control to an interpreter loop in order to execute code that has not been compiled. Sounds reasonable, though a restart op like trace_i does the same, get out of JIT and return to the runops loop. But anyway, jumping directly to the PC in Parrot_jit_begin is the way to go. leo
Re: branch dump
At 4:57 AM +0530 11/12/02, Gopal V wrote: If memory serves me right, Dan Sugalski wrote: > that case, why bother verifying? Hmm wouldn't the JIT benifit from a pre knowledge of basic blocks and types or some information ? ... (I seem to think so ...). Oh, sure. But whether the metadata is trustable is an interesting question, as is whether the JIT can generate code that's safe to execute from an unsafe base. It's distinctly possible that when running in safe mode you don't get the JIT. > at runtime anyway. With a full scan of the bytecode, of course, and > you'd need to figure where each and every instruction starts, which > can be costly. Can't that be added onto the JIT'ing process ? ... viz during conversion ,check for jump targets ?.. I still have this assumption that JITs need to maintain some sort of basic block identification for peephole optimisations ?.. Or is that totally irrelvant for register VMs ? ... (this is the first register VM I have encountered...) More like I'm not expecting to use the JIT for untrusted code. I'm not sure we'll be able to reasonably use the CG core, though I expect we probably will. The JIT can likely use basic block info in normal circumstances. I leave that up to the JIT folks--if there's useful metadata they can do things with, we can see about getting it into the bytecode. So, Parrot is more secure than perl is ? (that being your benchmark). Oh, absolutely not. Some benchmarks are too poor to consider. :) VMS is my benchmark system. I want the safe interpreters to be as safe as a locked down VMS system. Whether we get there or not's an open question, but it's where we're trying. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Superpositions and laziness
Damian Conway <[EMAIL PROTECTED]> writes:
> Luke Palmer wrote:
>
>
>> sub a_pure_func(Num $n) returns Num {
>> class is Num {
>> method FETCH { $n * $n } }.new }
>> Yes? No?
>
> Not quite.
>
>
> > sub a_pure_func(Num $n) returns Num {
> > class is Num {
> > has Num $cache;
> > method FETCH { $cache //= $n * $n } } }
>
>
> Still not quite.
>
> You don't want a C method (which won't be called unless the
> object somehow becomes the implementation of a tied variable).
>
> What you want are conversion-to-(num|str|bool) methods:
>
>sub a_pure_func(Num $n) returns Num {
>class is Num {
>has Num $cache;
>sub value { $n * $n }
>method operator:+ ($self:) { +($cache //= value ) }
>method operator:~ ($self:) { ~($cache //= value ) }
>method operator:? ($self:) { ?($cache //= value ) }
>}.new
>}
So, we'd have 'is lazy' do something like the following to the
declared sub?
sub make_lazy(&func) {
my $new_func = {
&func.returns.make_deferred_object( &func, *@_ }
};
$new_func.signature(&func.signature);
return $new_func;
}
And then, say:
class Object {
method make_deferred_object($class is Class : &func, *@args) {
class is $class {
has $class $cache;
sub value { &func(*@args) }
method operator:+ { +($cache //= value) }
method operator:~ { ~($cache //= value) }
method operator:? { ?($cache //= value) }
}.new
}
}
Which is somewhat dependent on being able to do C. If
that's not possible then I'd hope you could do something like:
given my $anon_class = Class.new {
my $cache;
.isa($class);
.add_sub'value' => { &func(*@args) }
.add_method 'operator:+' => {...}
.add_method 'operator:~' => {...}
.add_method 'operator:?' => {...}
return .new;
}
Hang on, couldn't you rewrite things to not use the cache?
class is $class {
sub value { &func(*@args) }
method operator:+ ($self is rw:) { +($self = value) }
method operator:~ ($self is rw:) { ~($self = value) }
method operator:? ($self is rw:) { ?($self = value) }
}.new
I don't know if I hope that works or hope it fails miserably.
Also note that, if you were feeling sufficiently lazy with numbers,
you could define the set of binary operators for your deferred
numbers:
method operator:+ ($self: Num $other) is lazy { +($self) + $other }
method operator:* ($self: Num $other) is lazy { +($self) * $other }
method operator:/ ($self: Num $other) is lazy { +($self) / $other }
method operator:- ($self: Num $other) is lazy { +($self) - $other }
Or would that just be evil, Bad And Wrong?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Superpositions and laziness
Michael Lazzaro <[EMAIL PROTECTED]> writes:
> On Friday, November 8, 2002, at 07:03 AM, Adam D. Lopresto wrote:
>> I still prefer "cached", which sounds less lingo-ish than "memoized"
>> but reads
>> better than "same" ("Same as what?").
>
> Insert obligatory reference to Eiffel here, which IIR uses the word
> "once":
>
> sub square ( Num $n ) is same { ... }
> sub square ( Num $n ) is pure { ... }
> sub square ( Num $n ) is once { ... }
> sub square ( Num $n ) is cached { ... }
> sub square ( Num $n ) is memoized { ... }
Having said I prefer 'pure', on further consideration I like cached,
but I think there's still a place for 'pure', but probably not as a
core property.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Superpositions and laziness
[ I've added some of Damian's text back into Michael's message to save replying to two separate messages. ] On Mon, Nov 11, 2002 at 09:44:37AM -0800, Michael Lazzaro wrote: > On Monday, November 11, 2002, at 02:19 AM, Damian Conway wrote: > > I can certainly see your point, but to me this is disquieteningly > > reminiscent of the horror that is C in C++ methods. Because, Yes, there are those overtones. You can never retrofit purity. > > if you're serious about C meaning "pure" in the mathematical > > sense, then C subs can't access globals or C, can't > > have C parameters, and call non-C subroutines. Yes, unless "pure" really means "pure enough". > > One of the reasons I like C is because it does specify > > exactly the way the subroutine is to behave (i.e. be called the > > first time, and not called every subsequent time the same arguments > > are supplied). So I can do nasty^H^H^H^H^Hhandy things like giving > > the sub side-effects, in the sure knowledge that they won't be > > invoked more than once. I think I agree that if you want to give perl a hint about how to optimise your program, and you want to specify that the results of calling a function should be cached, then "cached" seems the best way to do that. > > With C I can never be sure what optimizations the compiler is > > or isn't going to make, or even whether those optimzations will be > > the same from platform to platform [*]. So I can never be sure what > > the precise behaviour of my sub will be. :-( I would say that would be the whole point of "pure". If you declare a function to be "pure" (and you're telling the truth), then when and how often that function is called should have no bearing on the output of the program, except maybe for when it appears. The function could be cached, optimised away, farmed out to one of the 63 processors you're not using or be optimised in any number of helpful ways. Having said all that, I'm not overly wedded to the idea. It seems useful, but so does actually specifying "cached". I'm not convinced that either has to be a part of the core language to be useful. In fact, I only poked my head up because I knew the answer to Nick's question :-) > Amen. The more abstract or metaphorical the name, the more difficult > it is to be really sure of what it does. Of the choices, "cached" > seems by far the most self-explanatory. If we used "pure", we'd have > to teach people what "pure" means, which would be much harder than > teaching them what "cached" means. A "pure" function may be run zero, one or more times every time you call it. And every time you don't. ;-) [ I notice that Piers has just said about the same as me in one sentence. ] -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: The eternal "use XXX instead of POD" debate (was: Project Start: ?Section 1)
On Tue, Nov 12, 2002 at 11:40:05AM -0800, Larry Wall wrote: > On Mon, Nov 11, 2002 at 03:50:34PM -0800, Damien Neil wrote: > : I'd love to see a cleaner POD, with tables, better support for lists, > : and the ability to turn syntax inferencing on a per-document basis. > > We used a preprocessor to put tables into the POD for the Camel. > Lists don't seem to occur all that often in technical docs, so it > doesn't seem to be all that big a problem in practice, though we > could certainly talk about improvements. As for per-document policy, > there should certainly be some kind of > > =use module > > directive that, like Perl's C, is something more than just an > "include". And has the freedom to change the grammar for pod text? And beyond? Tim.
Re: Literal Values
On Tue, Nov 12, 2002 at 09:03:30PM +0100, Angel Faus wrote: > Does it look ok? Sure. > Any comments? (including grammar errors, of course) Here are mine. > --- > =subsection Literal Values > > =head1 Literal numbers > > =head2 Integers > > Integers can be represented by its decimal representation, > such as: Integers can be expressed by decimal notation, for instance: > > my $x = 14; # stores the integer 14 in $x > I don't know if it would help or hinder, but I think there should be a sentence like: Decimal notation is the same positional notation we all learned in grade school with the ones position at the far right, then immediately to the left of that is the tens position, then hundreds, and so forth > For example, the integer 30 can be written in hexadecimal > base in two equivalent ways: > > my $x = 16:1D > my $x = 16:1.14 > > This two representations are incompatible, so writing > something like C<16:D.13> will generate a compile-time error. Also note that a compile-time error will be generated if you specify a "digit" that is larger than your radix can support. For instance, my $x = 3:23; # error Is there some more generic term for number-in-some-arbitrary-radix? "Digit" always means base-10 numbers to me. (I'll coin "radit" if I have to ;-) What happens with this one: 256:255.255..0 # same as 256:255.255.0.0 ? # or error? > Finally, you can create negative integers prepending the > C<-> character. > > For example: > > my $x = 18; > my $x = -18; my $x = -256:245.234; my $x = -2:101001; I wonder if all of the "my $x =" parts should just be removed. The reader doesn't need to know about assignment, variables or scope declarators to learn about literals. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: Docs Testing Format (was Re: HOWTO: Writing Perl6 Tests)
Dave Whipp:
# Maybe there's a terminology problem: but what is a regression
# test? In my world, we create a regression by running existing
My understanding is that a "regression test" is basically a test to make
sure a bug doesn't come back once it's been fixed.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: Literal Values
On Tue, Nov 12, 2002 at 09:11:24PM +, Andrew Wilson wrote: > For example: > > my $i = 2:101110; # binary > my $j = 3:1210112; # tertiary > my $k = 8:1270; # octal > > Printing these would give 46, 1310, and 696 respectively. Hmm. As companion to specifying numeric literals in an arbitrary radix, I'm sure people will want to know how to output numerics in an arbitrary radix. If perl 6 will have such a facility, a reference to it should go here too. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Literal Values
On Tuesday, November 12, 2002, at 12:03 PM, Angel Faus wrote: =subsection Literal Values =head1 Literal numbers =head2 Integers Rather than using =head, each should be a subsection. What should be the syntax for closing a section? =section ... =end-section =section ... =section-end =section ... =/section =begin section ... =end section ? MikeL
Re: Literal Values
Angel Faus wrote: I've written a frist version of the "1.1 - Literal Values" subsection (in Michael's schema). Alright, I have the tests done to match this section of the documentation. Well, everything except 'bit', since the last time I checked (and this could be resolved by now), there was some debate over Boolean types, and I know bit was included in this argument. Also, I'm still not sure how hashes are supposed to interpolate within strings, and I'm also a bit unsure on how &() is supposed to work. On another note, I redid my string and interpolation tests to conform with the Test::More-ish style (including TODO-block tests) that P6C currently uses. Let me know if you like that better than what I did in that last message I sent. New tests are available at: http://jryan.perlmonk.org/images/literaltests.tar.gz
Re: doubled messages??
On Tue, Nov 12, 2002 at 01:13:37PM -0800, Dave Storrs wrote: > Is anyone else getting all the traffic from this list twice? I don't > get it from any of the other p6 lists, so I'm not quite sure what's > up. Presumably you are subscribed to both perl6-documentation and perl6-all, which is now relaying perl6-documentation, but wasn't at first. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Docs Testing Format (was Re: HOWTO: Writing Perl6 Tests)
On Tue, Nov 12, 2002 at 12:03:01PM -0800, Dave Whipp wrote: > Maybe there's a terminology problem: but what is a regression test? In my > world, we create a regression by running existing tests: we don't write a > special test suite for the regression. There may be a small number of tests > that we exclude from the regression, but then the special case is the > non-regressed tests. I have an ASIC testing background too, and Perl is not that different. In Perl, the same tests do for module testing, integration testing, system testing, regression testing and any other kind of testing you want to do. What you call them depends more on when you run them than what they do. In my experience, the same is true of most software. If you are lucky enough to have tests you might as well run them all as often as you can. This is normally feasible in software because the tests won't often take too long. Testing is generally more important in hardware (higher cost of failure) and the tests usually run for longer, but I think the same principles apply. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
RE: Literal Values
Michael Lazzaro:
# What should be the syntax for closing a section?
How about the empty string? Isn't the end of a section defined by EOF
or when the next section starts?
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: Literal Values
On Tuesday, November 12, 2002, at 04:08 PM, Brent Dax wrote: Michael Lazzaro: # What should be the syntax for closing a section? How about the empty string? Isn't the end of a section defined by EOF or when the next section starts? I mean if you can have sections inside sections, how do you tell the difference between a "child" =section and a "sibling" =section? =section blah =section subblah =section subsubblah =section subblah2 =section blah2 Or do you build the tree in "flattened" form, and rely on the author to get the numbering right? =section 1 blah =section 1.1 subblah =section 1.1.1 subsubblah =section 1.2 subblah2 =section 2 blah2 MikeL
Re: Literal Values
On Tue, 12 Nov 2002 17:56:28 +, Joseph F. Ryan wrote: > Alright, I have the tests done to match this section of the documentation. > Well, everything except 'bit', since the last time I checked (and this > could be resolved by now), there was some debate over Boolean types, and > I know bit was included in this argument. Also, I'm still not sure how > hashes are supposed to interpolate within strings, and I'm also a bit > unsure on how &() is supposed to work. > > On another note, I redid my string and interpolation tests to conform with > the Test::More-ish style (including TODO-block tests) that P6C currently > uses. Let me know if you like that better than what I did in that last > message I sent. For the most part, they look fine to me. I'm a little concerned about some of the numeric tests: output_is(<<'CODE', <<'OUT', "Simple Floats"); print 4.5; print 0.0; print 13.12343 CODE 4.50.013.12343 OUT I'd be more comfortable with a newline between the numbers, just in case. It's not an issue in the string tests. -- c
Re: Literal Values
chromatic wrote: On Tue, 12 Nov 2002 17:56:28 +, Joseph F. Ryan wrote: For the most part, they look fine to me. I'm a little concerned about some of the numeric tests: output_is(<<'CODE', <<'OUT', "Simple Floats"); print 4.5; print 0.0; print 13.12343 CODE 4.50.013.12343 OUT I'd be more comfortable with a newline between the numbers, just in case. It's not an issue in the string tests. -- c Alright, fine by me; I was wondering on that myself. Done & Updated.
RE: Literal Values
Michael Lazzaro:
# On Tuesday, November 12, 2002, at 04:08 PM, Brent Dax wrote:
# > Michael Lazzaro:
# > # What should be the syntax for closing a section?
# >
# > How about the empty string? Isn't the end of a section
# defined by EOF
# > or when the next section starts?
#
# I mean if you can have sections inside sections, how do you tell the
# difference between a "child" =section and a "sibling" =section?
#
# Or do you build the tree in "flattened" form, and rely on the
# author to
# get the numbering right?
Flattened, because it allows you to split the docs across multiple files
to keep them manageable. I'd like to be able to load the POD up onto my
Palm and edit it on the road, but Documents to Go slows down if the file
gets much over 20K.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: Literal Values
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Date: Tue, 12 Nov 2002 15:22:53 -0600 > From: Jonathan Scott Duff <[EMAIL PROTECTED]> > > What happens with this one: > > 256:255.255..0 # same as 256:255.255.0.0 ? > # or error? On the contrary, it's equivalent to 65535 .. 0, or the empty list. > -Scott > --
Underscore
I deleted the thread for that first doc, but it just occured to me that it didn't mention the 1_234_567 notation. Luke
Re: Literal Values
On Tue, Nov 12, 2002 at 05:38:00PM -0700, Luke Palmer wrote: > > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > > Date: Tue, 12 Nov 2002 15:22:53 -0600 > > From: Jonathan Scott Duff <[EMAIL PROTECTED]> > > > > What happens with this one: > > > > 256:255.255..0 # same as 256:255.255.0.0 ? > > # or error? > > On the contrary, it's equivalent to 65535 .. 0, or the empty list. Doh! I wasn't thinking about the range operators at all. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Literal Values
On Tue, Nov 12, 2002 at 03:58:37PM -0800, Michael Lazzaro wrote: > Or do you build the tree in "flattened" form, and rely on the author to > get the numbering right? > > =section 1 blah > =section 1.1 subblah > =section 1.1.1 subsubblah > =section 1.2 subblah2 > =section 2 blah2 Or number the sections like this: =section # blah =section ## subblah =section ### subsubblah =section ## subblah2 =section # blah2 And let the author only worry about "sectioning" and not about numbering at all. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Literal Values
> > output_is(<<'CODE', <<'OUT', "Simple Floats");
> > print 4.5;
> > print 0.0;
> > print 13.12343
> > CODE
> > 4.50.013.12343
> > OUT
> >
> >I'd be more comfortable with a newline between the numbers, just in case.
It's
> >not an issue in the string tests.
>
> Alright, fine by me; I was wondering on that myself. Done & Updated.
When I look at this, I find myself wanting to separate the control from the
data. Here's an alternative:
my @input = qw( 4.5 0.0 13.12343 );
my @output = qw( 4.5 0.0 13.12343 ); # can't assume that input==output
my $code = join(";", map {"print $_"} @input);
my $expect = join( "", @output);
output_is($code, $expect, "Simple Floats");
This is, perhaps, slightly harder to grok initially. But its easier to
extend the test data; and also to make control-path changes (such as added
the \n to the print statement). It might be better to use a hash for the
test data.
It is possible to make this type of test much easier to read. A mechanism I
have used in the past is to put the test data into a table (I used html).
Then, you have the test data and expected output as a nice table in a
document; and a simple piece of code to extract tests from it (assuming you
use a perl5 module to parse the table).
Dave.
Re: The eternal "use XXX instead of POD" debate (was: Project Start: ?Section 1)
Larry Wall wrote on Tue, 12 Nov 2002 11:40:05 -0800: could certainly talk about improvements. As for per-document policy, there should certainly be some kind of =use module directive that, like Perl's C, is something more than just an "include". I thought about putting something of the sort into perldpodspec and Pod::Simple, but didn't see a particularly clean way to have it so that 1) you wouldn't have to depend on a particular Pod-parsing module, and which 2) could work in cases where the Pod-parser and the formatter are sanely segregated. -- Sean M. Burkehttp://search.cpan.org/author/sburke/
Re: Literal Values
On Tue, Nov 12, 2002 at 01:20:04PM -0700, Luke Palmer wrote:
: > =head2 String as vector of ordinals
: >
: > Literals of the form C are parsed as a string
: > composed of characters with the specified ordinals. This
: > is an alternative, more readable way to construct
: > (possibly unicode) strings instead of interpolating
: > characters, as in C<\x{1}\x{2}\x{3}\x{4}>. The leading C
: > may be omitted if there are more than two ordinals, so
: > C<1.2.3> is parsed the same as C.
:
: This is equivalent to 256:1.2.3.4
Not quite. v1.2.3.4 is a string of four characters that only happens
to look like the internal representation of 256:1.2.3.4 on a 32-bit
big-endian machine. And it's perfectly possible to have v1234.4321,
which is a two character string, while 256:1234.4321 is an error.
Larry
Re: The eternal "use XXX instead of POD" debate (was: Project Start: ?Section 1)
wrote on Mon, 11 Nov 2002 15:50:34 -0800: I'd love to see a cleaner POD, Have you looked at perlpodspec, and had a look at the new Pod::Simple formatters? with tables, I like tables, but it is sheer agony to produce tables in many output formats. I'm starting to wonder whether some kind of verbatim block might be the answer, so that parsers that have said that they know about tables, will get tables; and otherwise they'll get the verbatim block. Something like: #:table-lines | | | inchestwips points centimeters 20 tw 1 pt 40 tw 2 pt ~57 tw.1cm 60 tw 3 pt 80 tw 4 pt 1/16" 90 tw 4.5 pts That assumes that each line is one row. Presumably a similar syntax could be adapted to cases where that's not the case. That's vaguely like the verbatim-formatted stuff that I've been experimenting with lately, where the second line here: flock COUNTER, LOCK_EX; #: ^^^ bolds the characters above the "^". better support for lists, In what sense? If you want something to happen in Pod, ask on the Pod-people list. and the ability to turn syntax inferencing on a per-document basis. On the Pod-people list, we have mostly decided that those inference rules are more trouble than they are worth, precisely because they are unpredictable, and typically there's no way to disable them. I am entirely happy with a future for Pod where no formatter (or, god help us, a parser) thinks it its duty to turn "an O(N) solution" into "an C solution". I distinctly sense that the discussion here is very much like previous grieve-and-growl sessions, where people too often say little more than "I don't like X about Pod" when they're not talking about Pod at all, but just some some appalling old version of Pod::Html or Pod::Man. It's like complaining that Perl doesn't have objects since you never know when you'll be using Perl 4. -- Sean M. Burkehttp://search.cpan.org/author/sburke/
faq
Hello, I have a question about the Parrot FAQ. I hope it's not too off-topic for this list. The FAQ mentions that "it would be nice to write the Perl to Bytecode compiler in Perl" and that there is no bootstrap problem. Does this mean that the perl6 compiler is written in perl5 and it will be rewritten in perl6 when a large enough subset of perl6 is implemented? I figure Perl5 will be obsolete at some point in the future... I noticed that the current incomplete perl6 implementation is written in perl5 using Parse::RecDescent, but I figured it's just a test implementation until the "real" compiler is written in C... Thanks marius
Re: Literal Values
On Tue, 12 Nov 2002, Michael Lazzaro wrote: > What should be the syntax for closing a section? I'm partial to the LaTeX approach, where you specify the level and the computer figures out the rest. It seems like either level or closing-tag is sufficient by itself. Levels put all the information in one place, and seem to take up less space (hence supporting the idea of pod as lightweight markup). /s
Re: Superpositions and laziness
Paul Johnson <[EMAIL PROTECTED]> writes: > [ I notice that Piers has just said about the same as me in one sentence. ] Ah, but I get lots of practice boiling stuff down when I'm writing the summaries. Though the current one is still giving me headaches -- I'm about halfway through perl6-language and I've not even started on perl6-documentation. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Literal Values
On Tue, 12 Nov 2002 17:00:17 +, Dave Whipp wrote:
(cross-posting to perl.qa for other perspectives)
> When I look at this, I find myself wanting to separate the control from the
> data. Here's an alternative:
>
> my @input = qw( 4.5 0.0 13.12343 );
> my @output = qw( 4.5 0.0 13.12343 ); # can't assume that input==output
>
> my $code = join(";", map {"print $_"} @input);
> my $expect = join( "", @output);
> output_is($code, $expect, "Simple Floats");
>
> This is, perhaps, slightly harder to grok initially. But its easier to
> extend the test data; and also to make control-path changes (such as added
> the \n to the print statement). It might be better to use a hash for the
> test data.
Yes, that is easier to extend. I'm not a big fan of mushing together several
different tests into one output_is() chunk, but that's because we don't have
anything of finer grain yet.
It'd be nice to write something like:
output_lines(< It is possible to make this type of test much easier to read. A mechanism I
> have used in the past is to put the test data into a table (I used html).
> Then, you have the test data and expected output as a nice table in a
> document; and a simple piece of code to extract tests from it (assuming you
> use a perl5 module to parse the table).
Being able to specify an output separator (assuming "\n" in its absence) may
alleviate this.
-- c
