On Tue, Nov 12, 2002 at 07:15:23PM -0700, Sean M. Burke wrote:
wrote on Mon, 11 Nov 2002 15:50:34 -0800:
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,
On Tue, Nov 12, 2002 at 07:15:23PM -0700, Sean M. Burke wrote:
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 ^.
I'd like to see an
On Tue, Nov 12, 2002 at 06:49:57PM -0700, Sean M. Burke wrote:
: 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 Cuse, is
At 09:43 2002-11-13 -0800, Larry Wall wrote:
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
[examples of how to create the glossary links snipped]
Assuming that we do go with the maintain a unique list of keys in %glossary, then do
an s/// approach, I'd be willing to maintain the list of terms.
--Dks
On Tue, Nov 12, 2002 at 12:06:13PM -0600, Garrett Goebel wrote:
I wonder if it'd be feasible to do lists something like:
[...]
=* level1
= level2
=+ level3
=* level4
= level3
= level1
I personally like the idea of keeping the '=' required, to be
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
What
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
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
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. Cprint may be a built-in right now;
but it should probably
Joseph F. Ryan wrote:
Dave Whipp wrote:
The fact that we don't need Cprint 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
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.
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
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.
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 Cint context:
my int $i = $obj;
blah blah blah...
=seealso Context
=seealso Numeric
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
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
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
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
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
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
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
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
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
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
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
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
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
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
I very much dislike XML for writing. It'd be nice to use some kind
of extended POD or something. Something that's mostly content,
little structure. Formats with a lot of structure tend to be
unproductive, and although the structure is useful, much of it is
redundant and can be bypassed by
Joseph F. Ryan wrote:
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
On Monday, November 11, 2002, at 05:08 AM, Angel Faus wrote:
I very much dislike XML for writing. It'd be nice to use some kind
I agree with you. XML is very unpleasant to write.
I certainly agree with that, but I was thinking of something very basic
-- just enough to get it into a
On Sunday, November 10, 2002, at 06:00 PM, Allison Randal wrote:
Revision on reading Mike's message: If the constant stream of revisions
happens on cognitivity, how about submitting approved docs to the
perl6 repository?
I would tend to agree, using the CVS repository to do nickle-and-dime
From: Angel Faus [mailto:afaus;corp.vlex.com]
I very much dislike XML for writing. It'd be nice to use some kind
of extended POD or something. Something that's mostly content,
little structure. Formats with a lot of structure tend to be
unproductive, and although the structure is
On Sunday, November 10, 2002, at 07:36 PM, Joseph F. Ryan wrote:
# 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
On Mon, Nov 11, 2002 at 01:40:59PM -0600, Garrett Goebel wrote:
The general Pro's and Con's of POD seem to be:
PRO
===
simple, concise, limited, extensible, forgiving
easy to convert to XXX, easy to write, easy to read, easy to ignore
separates block/inline markup, no special editor
On Mon, Nov 11, 2002 at 10:34:00AM -0800, Michael Lazzaro wrote:
... I was thinking of something very basic -- just enough to get
it into a database, for example. You'd just copy a standard
template and fill in the fields. Like perhaps:
section
id 1.1.2.1 /id
title Numeric Context /title
On Monday, November 11, 2002, at 11:58 AM, Adam Turoff wrote:
Two arguments that I don't see listed (and may not have been raised in
the most recent perl6-language version of the debate) are:
So long as someone can come up with a formal POD template that
represents all the fields we need,
From: David Wheeler [mailto:david;wheeler.net]
On Sunday, November 10, 2002, at 07:36 PM, Joseph F. Ryan wrote:
# 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
Garrett Goebel wrote:
Can anyone write up a detailed document describing how one would go about
writing Perl6 test cases and submitting them to Parrot? The parrot
documentation on testing, is understandably focused on testing parrot...
not the languages running on parrot.
I can't find any
Monday 11 November 2002 20:40, Garrett Goebel wrote:
The only consist support for something different than POD... was
for something that is in fact very similar to, and in fact based
upon POD: SDF.
http://www.ifi.uio.no/in228/scripting/doc/sdf/index.html
And the major arguments for
In order for TODO tests to work Test::Harness must be upgraded (only 5.8.0
ships with a T::H able to parse TODO tests). An upgraded version of
Test::Harness can simply be distributed with Parrot the same way Test::More
is.
On Mon, Nov 11, 2002 at 02:31:50PM -0600, Garrett Goebel wrote:
I can't
On Monday, November 11, 2002, at 03:33 PM, Michael G Schwern wrote:
Otherwise, they're just normal tests and are handled by things like
Test::Tutorial, Test::More and Test.pm. Details on the test output
protocol
can be found in Test::Harness.
I think it'd be useful for folks to get a pointer
On Mon, Nov 11, 2002 at 11:47:01PM +0100, Angel Faus wrote:
Does anyone have any experience with SDF?
I played with it for some in-house documentation a couple years ago.
I'm afraid I wasn't very impressed with it; I found it very difficult
to customize the output to what I wanted, and the
On Mon, 11 Nov 2002, David Wheeler wrote:
I think it'd be useful for folks to get a pointer to some existing Perl
6 tests that they can model off of. Do any exist yet?
languages/perl6/t/*/*.t is what we've got, though they're intended to
exercise the prototype compiler, not the real language
On Mon, Nov 11, 2002 at 03:50:34PM -0800, Damien Neil wrote:
POD parsers also go to a fair amount of trouble to infer syntax. For
example, a function name like this() will be rendered differently by
many POD processors. This is a good thing, in that you don't have to
litter your
Sean O'Rourke [EMAIL PROTECTED] wrote languages/perl6/t/*/*.t is
what we've got, though they're intended to
exercise the prototype compiler, not the real language (which looks like
it's changing quite a bit from what's implemented).
OK, lets take a specific test. builtins/array.t contains a
On Mon, 11 Nov 2002, Dave Whipp wrote:
This is fine as a test, but not as documentation. Furthermore, it is
depending on the print statement for its comparison (not necessarily bad;
but I find that golden-output style tests tend to become difficult to
maintain -- specific assertions tend to
Michael Lazzaro:
# OK, let's start on the first section (calling them
# Sections, not Chapters). As our first experiment, we
# will assume a treelike style (section 1 -- 1.1, 1.2, 1.2.1,
# etc.); look at http://www.mysql.com/documentation/ for an
# example of a good, detailed documentation
Hm. I'm not sure how well it goes with the Perl philosophy (the perl
language is what the perl interpreter accepts), but we could embed the
_real_ test cases in whatever formal spec happens. This would be the
excruciatingly boring document only read by people trying to implement
perl6. I
Sean O'Rourke wrote:
documentation, not code. An obvious question is how to extend it to be a
more thorough test, whilst not spoiling the documentation. We'd want to
intersperse text with the test-code; and probably mark a few bits as
hidden, from a normal documentation view (levels of hiding
Dave Whipp wrote:
Sean O'Rourke [EMAIL PROTECTED] wrote in message One thing the
golden-output has going for it is that it gets into and
out of perl6 as quickly as possible. In other words, it relies on
perl6/parrot to do just about the minimum required of it, then passes
verification off
On Mon, Nov 11, 2002 at 05:43:01PM -0800, Dave Whipp wrote:
Sean O'Rourke [EMAIL PROTECTED] wrote in message
One thing the golden-output has going for it is that it gets into
and out of perl6 as quickly as possible. In other words, it relies on
perl6/parrot to do just about the minimum
Joseph F. Ryan [EMAIL PROTECTED] wrote in message
news:3DD0674C.1080708;osu.edu...
A module? For something as basic as print?
I hope not, that would certainly be a pain.
My understanding is that Cprint will be a method on CIO::stream (or
whatever), which has a default invocant of $stdout. This
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
Dave Whipp wrote:
Andrew Wilson [EMAIL PROTECTED] wrote
The fact that we don't need Cprint 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
Luke Palmer wrote:
I very much dislike XML for writing. It'd be nice to use some kind of
extended POD or something. Something that's mostly content, little
structure. Formats with a lot of structure tend to be unproductive,
and although the structure is useful, much of it is redundant and can
Michael Lazzaro:
# On Monday, November 11, 2002, at 05:08 AM, Angel Faus wrote:
# I very much dislike XML for writing. It'd be nice to use some kind
# I agree with you. XML is very unpleasant to write.
#
# I certainly agree with that, but I was thinking of something
# very basic
# -- just
OK, let's start on the first section (calling them Sections, not
Chapters). As our first experiment, we will assume a treelike style
(section 1 -- 1.1, 1.2, 1.2.1, etc.); look at
http://www.mysql.com/documentation/ for an example of a good, detailed
documentation tree.
So let's go depth-first
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.
A quicky (hopefully without starting a war), can
TASK 1c:
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
Michael Lazzaro wrote:
OK, let's start on the first section (calling them Sections, not
Chapters). As our first experiment, we will assume a treelike style
(section 1 -- 1.1, 1.2, 1.2.1, etc.); look at
http://www.mysql.com/documentation/ for an example of a good, detailed
documentation tree.
Joseph F. Ryan wrote:
I really like the current perldoc.com appearance.
Couldn't we just use that? (for now, at least)
Sure, but it's possible we want the data sliced several different
ways... so we have to figure out what those ways might be. For example,
if we want a treelike structure with
Michael Lazzaro wrote:
Joseph F. Ryan wrote:
snip
n another note, is there place (CVS) that can be set up
that this stuff can uploaded this stuff to? :)
Not yet. We'll almost certainly just tack our stuff onto the current
Parrot/Perl6 CVS tree, since that's the obvious place for it.
Joseph F. Ryan wrote:
On another note, is there place (CVS) that can be set up that this stuff can
uploaded this stuff to? :)
The perl6 repository on cvs.perl.org already has a doc directory, I
expect you'll just want to use that. The design subdir is reserved for
Apocalypses, Exegeses and
Allison Randal wrote:
Joseph F. Ryan wrote:
On another note, is there place (CVS) that can be set up that this stuff can
uploaded this stuff to? :)
The perl6 repository on cvs.perl.org already has a doc directory, I
expect you'll just want to use that. The design subdir is reserved for
I wrote:
The perl6 repository on cvs.perl.org already has a doc directory, I
expect you'll just want to use that.
Revision on reading Mike's message: If the constant stream of revisions
happens on cognitivity, how about submitting approved docs to the
perl6 repository?
Allison
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
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
69 matches
Mail list logo
