On Mon, Nov 15, 2021 at 12:43 JJ Merelo wrote:
> Done also for the official site, https://docs.raku.org
> Check it out.
>
Thank you, JJ--it looks great!
-Tom
Done also for the official site, https://docs.raku.org
Check it out.
El lun, 15 nov 2021 a las 19:17, JJ Merelo () escribió:
> Testing the newly deployed docs here https://rakudocs.github.io/
>
> I'll try and do a couple of updates and checks and if everything is OK,
> will deploy to the officia
Testing the newly deployed docs here https://rakudocs.github.io/
I'll try and do a couple of updates and checks and if everything is OK,
will deploy to the official site.
El dom, 14 nov 2021 a las 19:54, Tom Browder ()
escribió:
> Doc site i see is several weeks old and missing my last merged c
On Nov 26, 7:42 am, [EMAIL PROTECTED] (Will Coleda)
wrote:
> # New Ticket Created by Will Coleda
> # Please include the string: [perl #47826]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=47826>
>
> The NCI information in
On Feb 22, 2006, at 9:38 AM, Will Coleda wrote:
On Feb 22, 2006, at 6:03 AM, Karl Forner wrote:
Hello,
I've played a little with 'make html', and the docs produced seem
to me much
more useful than the docs available on the parrotcode.org website.
What I particularly appreciate is the hyp
On Feb 22, 2006, at 6:03 AM, Karl Forner wrote:
Hello,
I've played a little with 'make html', and the docs produced seem
to me much
more useful than the docs available on the parrotcode.org website.
What I particularly appreciate is the hyperlinks to other pod
documents and
the ability to
"Autrijus Tang" <[EMAIL PROTECTED]> wrote:
On Mon, Aug 08, 2005 at 12:03:25AM +0100, Jonathan Worthington wrote:
> So, I re-wrote it. It now talks about PIR, and has examples in PIR. It
> mentions how PIR differs from PASM. Subroutines now get a look in to
> the
> introduction, and it mention
On Mon, Aug 08, 2005 at 12:03:25AM +0100, Jonathan Worthington wrote:
> So, I re-wrote it. It now talks about PIR, and has examples in PIR. It
> mentions how PIR differs from PASM. Subroutines now get a look in to the
> introduction, and it mentions in passing that Parrot is capable of doing O
[EMAIL PROTECTED] (Dan Sugalski) writes:
[...]
> It's an ongoing fight between the "go get the libs and install them"
> folks and the "self-contained distribution" folks. I'm in the latter
> category. :)
As Larry said, "self-contained" is good for users. For developers
(and CVS) "go get the libs
At 11:49 AM -0800 3/4/04, Robert Spier wrote:
> >I'd like to remove non-modified, non-parrot Perl modules from lib
>and install them via CPAN.pm.
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any more than it's going to run apt-get on
systems tha
At 4:45 PM +0100 3/4/04, Michael Scott wrote:
On 4 Mar 2004, at 15:51, Dan Sugalski wrote:
[...]
I'd like to remove non-modified, non-parrot Perl modules from lib
and install them via CPAN.pm.
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any more
On 6 Mar 2004, at 05:31, Robert Spier wrote:
[...]
The problem isn't today. It's the "trend" and next month, when
someone decides they need to add some other module, and has a
precedent to follow. Then, suddenly we end up with 30 different
modules included in our distribution, each one changed
> >
> > "within reason". Thats where we're way off right now.
>
> Let's keep a bit of perspective here. The non-Parrot:: contents of lib
> accounts for only 4.6% of the non-ICU content (and only 1.5% if you
> count ICU in the total size). It's difficult to see that as
> unreasonable, or as "bl
On Mar 4, 2004, at 7:50 PM, Robert Spier wrote:
IMHO, the releases better include everything necessary to build the
application, within reason. Consistency and simplicity counts for a
lot.
Why create headaches we don't need?
"within reason". Thats where we're way off right now.
Let's keep a bit
> But once we start expecting people in the real world to compile this thing
> on their boxes in order to install perl, it would be extremely foolish to
> make them manually download and install perl6 + parrot + icu + perl5 +
> cpan modules 1 through 10, all from different sources.
Try building
At this point in the development cycle you can certainly make such
arguments (although I would tend to fall on the side of consistency
myself, at least for things that really Don't Matter in the grand scheme
of things, such as POD modules).
But once we start expecting people in the real world
> The determinism seems perhaps worth the bloat. It's quite localize
> bloat after all.
I disagree.
We _want_ a heterogeneous environment -- a homogeneous environment
doesn't exist in the real world -- most of your concerns were with
tracking down the issues. Since we have parrotbug now (or rea
There's no reason to include large, independently maintained modules
like Pod::Simple in the parrot CVS tree and tarball. It just turns
into a maintenance nightmare, should we ever start modifying these
things.
[...]
I don't understand why you are insisting on including these thin
> > No. Sorry, definitely not. Parrot's config isn't going to install
> > perl modules off the 'net any more than it's going to run apt-get on
> > systems that support it. We either provide it or do without.
>
> What about ICU. There is already a new version pending (again).
Since we haven't act
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> No. Sorry, definitely not. Parrot's config isn't going to install
> perl modules off the 'net any more than it's going to run apt-get on
> systems that support it. We either provide it or do without.
What about ICU. There is already a new version pending
On Thu, Mar 04, 2004 at 03:40:27PM +0100, Michael Scott wrote:
: I'd like to remove non-modified, non-parrot Perl modules from lib and
: install them via CPAN.pm. I have a version here which works, but I
: remember from experience it can be tricky to set up CPAN.pm to work
: behind firewalls, so
> >I'd like to remove non-modified, non-parrot Perl modules from lib
> >and install them via CPAN.pm.
>
> No. Sorry, definitely not. Parrot's config isn't going to install
> perl modules off the 'net any more than it's going to run apt-get on
> systems that support it. We either provide it or
On Mar 4, 2004, at 7:45 AM, Michael Scott wrote:
On 4 Mar 2004, at 15:51, Dan Sugalski wrote:
[...]
I'd like to remove non-modified, non-parrot Perl modules from lib and
install them via CPAN.pm.
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any m
On 4 Mar 2004, at 15:51, Dan Sugalski wrote:
[...]
I'd like to remove non-modified, non-parrot Perl modules from lib and
install them via CPAN.pm.
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any more than it's going to run apt-get on
systems tha
At 3:40 PM +0100 3/4/04, Michael Scott wrote:
On 7 Feb 2004, at 00:53, Michael Scott wrote:
On 6 Feb 2004, at 22:32, Leopold Toetsch wrote:
- icu
- lib/Test/*
- lib/Pod/*
are all "standard" thingys. I'm not thinking that we are gonna
reinventing wheels nor that we are gonna copying existing wheel
On 7 Feb 2004, at 00:53, Michael Scott wrote:
On 6 Feb 2004, at 22:32, Leopold Toetsch wrote:
- icu
- lib/Test/*
- lib/Pod/*
are all "standard" thingys. I'm not thinking that we are gonna
reinventing wheels nor that we are gonna copying existing wheels, so
I'd
vote for just removing all that fro
On 6 Feb 2004, at 22:32, Leopold Toetsch wrote:
- icu
- lib/Test/*
- lib/Pod/*
are all "standard" thingys. I'm not thinking that we are gonna
reinventing wheels nor that we are gonna copying existing wheels, so
I'd
vote for just removing all that from CVS.
yep
All non-trivial packages have some
Robert Spier <[EMAIL PROTECTED]> wrote:
> Pod::Simple is relatively easy to subclass. And Sean is pretty
> receptive to changes.
[ more referenced source inside ]
- icu
- lib/Test/*
- lib/Pod/*
are all "standard" thingys. I'm not thinking that we are gonna
reinventing wheels nor that we are go
> Suppose I could make a few changes to Pod-Simple, then our problem
> would be solved.
Pod::Simple is relatively easy to subclass. And Sean is pretty
receptive to changes.
> never have occurred to me to shove all of that in CVS. It always
> surprised me a that ICU was there, rather than just
Suppose I could make a few changes to Pod-Simple, then our problem
would be solved.
But, being serious, say I'd decided to use Template-Toolkit, it would
never have occurred to me to shove all of that in CVS. It always
surprised me a that ICU was there, rather than just what was needed to
get
> I can possibly help it, so it's ok by me to delete lib/Pod, if that's
> the consensus.
I'm not sure what the consensus is. But we should probably come to one.
-R
Ah, ok, my bad then. I'd just assumed that, apart from any need for
modification, the other things were there simply to save having to tell
everyone to go off and get them. I don't intend to change Pod-Simple if
I can possibly help it, so it's ok by me to delete lib/Pod, if that's
the consensus
> I've added the Perl modules for the docs tools to lib/Parrot/IO and
> lib/Parrot/Docs. I've also added Pod-Simple (2.05) and Pod-Escapes
> (1.03) which they use.
I probably blinked.. but why are we including CPAN modules that we are
not likely to change into the parrot repository?
-R
On Tue, Feb 03, 2004 at 09:23:58AM +0100, Leopold Toetsch wrote:
> Tim Bunce <[EMAIL PROTECTED]> wrote:
> >> Yeah, I think getting the docs better will be an aggressive goal for
> >> the next release.
>
> > How's this all looking now we're in Feb?
>
> There is still a lot of outdated (or unimplem
Tim Bunce <[EMAIL PROTECTED]> wrote:
>> Yeah, I think getting the docs better will be an aggressive goal for
>> the next release.
> How's this all looking now we're in Feb?
There is still a lot of outdated (or unimplemented?) stuff in assembly
related docs.
WRT release :)
,--[ p6i ]
On Mon, Jan 12, 2004 at 09:33:57AM -0500, Dan Sugalski wrote:
> At 11:52 AM + 1/12/04, Tim Bunce wrote:
> >Has a date been set for the next release?
>
> Nope. I suppose we could shoot for another holiday release, if
> someone's got a good february one.
>
> >Are the docs (especially the PDDs)
Great, thanks.
Tim.
On Sat, Jan 31, 2004 at 01:05:02AM +0100, Michael Scott wrote:
> I haven't ruled out something like that in the long term, but what I'm
> trying achieve at the moment is just to see some pod everywhere. This
> has the merit that I visit every file and ensure that some basic
I haven't ruled out something like that in the long term, but what I'm
trying achieve at the moment is just to see some pod everywhere. This
has the merit that I visit every file and ensure that some basic
information gets provided for the newbies - my target audience.
In a sense I'm following
Would doxygen be of use here? http://www.doxygen.org/
Here's an example use http://www.speex.org/API/refman/speex__bits_8h.html#a2
Follow the links, including to the annotated source file.
Tim.
On Thu, Jan 29, 2004 at 07:20:50PM +0100, Michael Scott wrote:
> I've add inline docs to everything i
On Thursday 29 January 2004 18:20, Michael Scott wrote:
> For those who want to browse:
>
> http://homepage.mac.com/michael_scott/Parrot/docs/html/
>
> Mike
Thanks
you defn. rock...
--
Vishal Vatsa
Dept. of Computer Sc.
NUI Maynooth
Matt Fowles <[EMAIL PROTECTED]> wrote:
[ another TOFU [1] ]
AOL
leo
> Mike~
> You rock. That is really nice.
> Matt
> Michael Scott wrote:
>> I've add inline docs to everything in src (except for malloc.c and
>> malloc-trace.c).
>>
>> At times I wondered whether this was the right thing to
Mike~
You rock. That is really nice.
Matt
Michael Scott wrote:
I've add inline docs to everything in src (except for malloc.c and
malloc-trace.c).
At times I wondered whether this was the right thing to do. For example,
in mmd.c, where Dan had already created a mmd.pod, I ended up
duplicati
Dan Sugalski wrote:
Michael Scott wrote:
Perhaps the most controversial feature of all this is that I'm using
rows of 80 '#'s as visual delimiters to distinguish documentation
sections from code.
Please don't. If you really, really must, chop it down to 60 or so
characters. 80 may wrap in some
Duh. Rereading that I can see I got my numbers in a twist. I've been
adding them where missing.
On 22 Jan 2004, at 19:39, Dan Sugalski wrote:
At 2:06 PM +0100 1/19/04, Michael Scott wrote:
Some files have CVS version $Id strings, some don't.
While tidying up the documentation I'm visiting every
Yep. I bounced Sam's comment around in my head for a while until I saw
that I was only putting them in for my own current convenience - makes
it easier to see what I'm doing as I'm doing it - so they won't be
there. Minimal is best. And anyway who wants to be "SO 20th century".
Mike
On 22 Jan
At 2:06 PM +0100 1/19/04, Michael Scott wrote:
Some files have CVS version $Id strings, some don't.
While tidying up the documentation I'm visiting every file. I can either:
1) add them when missing
2) remove them when present
3) do nothing
I was inclined to (1) until I reflected that it did pres
At 10:42 AM +0100 1/21/04, Michael Scott wrote:
Perhaps the most controversial feature of all this is that I'm using
rows of 80 '#'s as visual delimiters to distinguish documentation
sections from code.
Please don't. If you really, really must, chop it down to 60 or so
characters. 80 may wrap in
My vote goes for the simplest that will still parse;
/*
=head1 foo
*/
After all, arent't we all using editors that can highlight the
scructure of our code to our satisfaction ? Surely even VIM et al can
stick in dividers or something to make them stand out if the coder
desires? I've already go
Thank you! You make some of my cheesy code a bit more respectable :)
--Josh
At 23:35 on 01/20/2004 +0100, Michael Scott <[EMAIL PROTECTED]> wrote:
> I've committed updates to the documentation in the Perl scripts in
> build_tools, classes and tools/dev.
>
> http://homepage.mac.com/mich
Mike~
I just recently added a file src/generic_register.c. I think that I
simply copied the CVS $Id from the file register.c which I used as a
template.
Matt
Michael Scott wrote:
I've committed updates to the documentation in the Perl scripts in
build_tools, classes and tools/dev.
http:
* Andrew Dougherty ([EMAIL PROTECTED]) [040120 02:19]:
>
> Wordsize errors are one common type of error that show up on PPC
> (and SPARC) more readily than on x86, due to byte-order issues.
>
> When reporting problems, it's often a good idea to include the ./myconfig
> file in the parrot build di
* Harry ([EMAIL PROTECTED]) [040118 05:06]:
>
> --- Paul Cochrane <[EMAIL PROTECTED]> wrote:
> > Yeah, I don't think you're going crazy. The funny thing is that
> > about a three
> > weeks ago my cvs checkout worked fine. I did a cvs update, and then
> > Configure.pl didn't work[1], so I re-chec
On Tue, 13 Jan 2004, Paul Cochrane wrote:
> This also gives me an opportunity to mention to anyone with more time (and
> possibly ability) than me, that parrot is having problems on LinuxPPC. The
> specifics are:
> - parrot hangs on t/op/arithmetics when doing make test
> - make gives an
They're already commited.
On 16 Jan 2004, at 00:21, chromatic wrote:
On Thu, 2004-01-15 at 15:02, Michael Scott wrote:
So, after migrating from Pod::Checker to Pod-Simple, I've cleared up
all the pod errors and done a rudimentary html tree.
Do you have patches to fix the errors in CVS or are the
On Thu, 2004-01-15 at 15:02, Michael Scott wrote:
> So, after migrating from Pod::Checker to Pod-Simple, I've cleared up
> all the pod errors and done a rudimentary html tree.
Do you have patches to fix the errors in CVS or are they even necessary?
-- c
So, after migrating from Pod::Checker to Pod-Simple, I've cleared up
all the pod errors and done a rudimentary html tree. The state of
parrot pod can be seen here
http://homepage.mac.com/michael_scott/Parrot/docs/html/. That's every
file that has pod in it. Obviously there are a few files such
On Mon, Jan 12, 2004 at 05:01:41PM +, Harry Jackson wrote:
>
> If there are any shy lurkers out there please speak now or forever hold
> your peace.
>
Well, here i speak ;-)
I have some (minor) skills in C, Perl, Networking, compiling, and other
stuff. I also downloaded Parrot some months a
Harry Jackson wrote:
Harry Jackson
If there are any shy lurkers out there please speak now or forever hold
your peace.
Alright, that's me too. I've been lurking for a couple years, actually,
and have only made one post on perl6-language, I think. I just
downloaded parrot again last week after
Well, there is always up-to-date documentation, your debugger output ...
0x4C56
Who says that the copy-paste antipattern is bad?
Mark Solinski wrote:
I'm also a shy lurker but would love to help in any way I can. I have twenty+ years experience in C/C++/OOP. Is there a reasonable place to start?
Bloody hell man, what took you so long ;-). With that amount of
experience, take your pick.
http://www.parrotcode.org/todo
Har
I'm also a shy lurker but would love to help in any way I can. I have twenty+ years
experience in C/C++/OOP. Is there a reasonable place to start?
Mark Solinski
[EMAIL PROTECTED]
[EMAIL PROTECTED]
On Monday 12 January 2004 17:58, Harry Jackson wrote:
> Robert Eaglestone wrote:
> > Yes, I'm a shy lurker.
>
> Are there any more, don't be shy, there might be a lot of barking but no
> one bites at least I have not had anyone bite me _yet_.
>
> Is there anyone on the list who wants to help but do
Ooh, ooh, a chance to leave shy lurker status behind and work on one of
the coolest software projects out there, count me in.
I have some rudimentary C skills and I'm sure there's some elbow grease
around here somewhere...
Jeff
On Mon, Jan 12, 2004 at 05:58:18PM +, Harry Jackson wrote:
> Rob
Paul Cochrane wrote:
If there are any shy lurkers out there please speak now or forever hold
your peace.
I'll admit to being a shy lurker... (and have rudimentary C knowledge, but a
bit low on the elbow grease atm :-/)
Another one, we are getting more and more of them pop up from all over
the
> If there are any shy lurkers out there please speak now or forever hold
> your peace.
I'll admit to being a shy lurker... (and have rudimentary C knowledge, but a
bit low on the elbow grease atm :-/)
This also gives me an opportunity to mention to anyone with more time (and
possibly ability)
Ping. One quiet lurker here. I'd like to help out, but not really sure
where to start. Given Dan's suggestion, I think I might start looking at
some more abusive-type tests. Destruction and dissection can be fun. I'd
be happy to help out in other newbie-type ways, too.
--Kevin
Harry Jackson wr
Harry~
You have outlined my situation exactly. I completely agree.
Matt
Harry Jackson wrote:
Tim Bunce wrote:
The developers _of_ parrot need to keep in mind the needs of those
poised on the edge of developing _in_ parrot.
I think that there are a lot of people who would help but the learni
Dan Sugalski wrote:
At 5:01 PM + 1/12/04, Harry Jackson wrote:
Tim Bunce wrote:
and am always worried about making an ass of myself when posting.
Dammit, and here I was trying to lead by example. It's OK! :)
Smoothing the path for newcommers, of both types, is very important.
I spent
Harry Jackson wrote:
If there are any shy lurkers out there please speak now or forever hold
your peace.
Poit. That's me.
At 1:26 PM -0500 1/12/04, Simon Glover wrote:
Well, one thing that people can contribute that doesn't require much
(if any) knowledge of the internals is tests (whether in PASM, PIR,
or one of the other languages that run on top of Parrot). Tests that
uncover bugs are particularly helpful!
Abso
Well, one thing that people can contribute that doesn't require much
(if any) knowledge of the internals is tests (whether in PASM, PIR,
or one of the other languages that run on top of Parrot). Tests that
uncover bugs are particularly helpful!
Simon
I'm currently building some docs related modules which will allow us to
create an html tree from the pod, inline stuff included.
I cleaned up all the pod errors last week and was going to report on
that but got sidetracked when I realised that POD::Checker diverged
somewhat from Perl's own pod
At 5:01 PM + 1/12/04, Harry Jackson wrote:
Tim Bunce wrote:
and am always worried about making an ass of myself when posting.
Dammit, and here I was trying to lead by example. It's OK! :)
Smoothing the path for newcommers, of both types, is very important.
I spent quite a bit of time fishin
Robert Eaglestone wrote:
Yes, I'm a shy lurker.
Are there any more, don't be shy, there might be a lot of barking but no
one bites at least I have not had anyone bite me _yet_.
Is there anyone on the list who wants to help but does not know where to
start. If you are really that shy email me off
Harry Jackson wrote:
>
> I think that there are a lot of people who would help but the learning
> curve seems too high. I for one am finding it a pretty steep curve at the
> moment and am always worried about making an ass of myself when posting.
> I decided to hell with it, if you're ain't in y
Tim Bunce wrote:
The developers _of_ parrot need to keep in mind the needs of those
poised on the edge of developing _in_ parrot.
I think that there are a lot of people who would help but the learning
curve seems to high. I for one am finding it a pretty steep curve at the
moment and am always wo
At 4:47 PM + 1/12/04, Tim Bunce wrote:
On Mon, Jan 12, 2004 at 09:33:57AM -0500, Dan Sugalski wrote:
At 11:52 AM + 1/12/04, Tim Bunce wrote:
>Has a date been set for the next release?
Nope. I suppose we could shoot for another holiday release, if
someone's got a good february one.
Valen
On Mon, Jan 12, 2004 at 09:33:57AM -0500, Dan Sugalski wrote:
> At 11:52 AM + 1/12/04, Tim Bunce wrote:
> >Has a date been set for the next release?
>
> Nope. I suppose we could shoot for another holiday release, if
> someone's got a good february one.
Valentines day? :-)
[ On a whim I thou
At 11:52 AM + 1/12/04, Tim Bunce wrote:
Has a date been set for the next release?
Nope. I suppose we could shoot for another holiday release, if
someone's got a good february one.
Are the docs (especially the PDDs) upto date on best practices?
Alas not, no.
If not, will that be a goal for th
Tim Bunce <[EMAIL PROTECTED]> wrote:
> Has a date been set for the next release?
No, not yet. But I can imagine to have a release in February. It of
course depends on progress WRT objects and threads.
> Are the docs (especially the PDDs) upto date on best practices?
No. Not much better then as o
> > I have noticed that docs\parrot_assembly.pod is old version of
> > \docs\pdds\pdd06_pasm.pod file.
> > Will these files be distinguished in the future?
>
> And they're both wrong, unfortunately. :( pdd06 is supposed to be
> canonical, so parrot_assembly.pod will be going away at some point. A
Simon Glover <[EMAIL PROTECTED]> writes:
> On Mon, 3 Nov 2003, Dan Sugalski wrote:
>
> > On Mon, 3 Nov 2003, Nick Kostirya wrote:
> >
> > > Catalog docs\ops is empty in 0.0.13 version.
> > > Is it bug?
> >
> > I think that's leftover cruft.
>
> Well, we used to generate a .pod file for each .
On Mon, 3 Nov 2003, Dan Sugalski wrote:
> On Mon, 3 Nov 2003, Nick Kostirya wrote:
>
> > Catalog docs\ops is empty in 0.0.13 version.
> > Is it bug?
>
> I think that's leftover cruft.
Well, we used to generate a .pod file for each .ops file, at build time,
which lived in here. However, we do
On Mon, 3 Nov 2003, Nick Kostirya wrote:
> Hello.
> I have several questions about parrot dosc.
>
> I have noticed that docs\parrot_assembly.pod is old version of
> \docs\pdds\pdd06_pasm.pod file.
> Will these files be distinguished in the future?
And they're both wrong, unfortunately. :( pdd06
Dave Whipp <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>
>> I'm not arguing that the unit tests themselves shouldn't carry
>> documentation, but that documentation (if there is any) should be
>> aimed at the perl6 developer.
>
> Depends what you mean by "perl6 developer": is that the interna
Piers Cawley wrote:
I'm not arguing that the unit tests themselves shouldn't carry
documentation, but that documentation (if there is any) should be
aimed at the perl6 developer.
Depends what you mean by "perl6 developer": is that the internals
people, or the lucky user?
Unit tests should be
"Dave Whipp" <[EMAIL PROTECTED]> writes:
> "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 d
[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: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 w
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]>
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 exa
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, lo
"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 te
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
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
# produci
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
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 wan
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
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
# iss
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 num
100 matches
Mail list logo
