Leopold Toetsch wrote:
Nicholas Clark wrote:
It's not likely to be a portability problem,
To NULL or not to NULL, this is the question.
I introduced a macro, depending on a symbol HAS_NON_ZERO_NULL, which
should be set for these architecures.
Currently interpreter.c only, other files
On Sun, Nov 10, 2002 at 12:15:06PM +0100, Leopold Toetsch wrote:
> Leopold Toetsch wrote:
>
> >Nicholas Clark wrote:
>
>
> >>It's not likely to be a portability problem,
>
>
> >To NULL or not to NULL, this is the question.
>
> I introduced a macro, depending on a symbol HAS_NON_ZERO_NULL, wh
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-fir
Larry Wall <> writes:
> But at the moment I'm thinking there's something wrong about any
> approach that requires a special character on the signature side.
> I'm starting to think that all the convolving should be specified
> on the left. So in this:
>
> for parallel(@x, @y, @z) -> $x
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 anyon
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
On Fri, Nov 08, 2002 at 07:07:47PM +, Richard Nuttall wrote:
> One further comment on the differences. Bother MYSQL and PHP are much
> more simple languages, and the bulk of their references are functional,
> breaking down into a neat hierarchy. Perl6 needs documentation that
> slices a numb
[EMAIL PROTECTED] (Michael Lazzaro) wrote in news:CB2CAEFE-F33C-
[EMAIL PROTECTED]:
>
> This message is to open the perl6-documentation list. First things
> first, can we get a quick roll call of who is interested in this
> effort, at least in abstract principle? No point in having discussion
--
On Sat, 9 Nov 2002 23:22:45
Brent Dax wrote:
>Michael Lazzaro:
># Brent Dax wrote:
># >
># > I was writing up some docs (in a perldoc-like style--we can always
># > change the form later, but the content is important), and started
># > working on documenting references. I ended up wit
On Thu, Nov 07, 2002 at 04:16:50PM -0500, Dan Sugalski wrote:
> Basically anything you can potentially find in a symbol table or
> lexical scratchpad will potentially be able to have a property
> attached to it. The only way that we'll be able to reasonably
> restrict (and optimize) the use of
"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 wi
Grabbing the last few snapshots from dev.perl.org, I can't find one that'll
build under Win32. During Configure.PL I get these errors:
Determining stack growth direction...'.\test.exe' is not recognized as an
internal or extern
al command, operable program or batch file.
Odd number of elements
Michael Lazzaro wrote:
"Joseph F. Ryan" wrote:
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, Exegese
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
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
compiler/parser
Okay, I survived this year's Lightweight Languages workshop, and as
part of the aftermath I have a roadmap. These are the things going
in, and in the order they're going in:
*) Exceptions. (Adding the cope and hcf instructions for them)
*) A better C function call interface. (And an incredibly h
20 matches
Mail list logo
