[perl6/specs] c2d66a: Try to fix pod

2017-07-10 Thread GitHub
un, 09 Jul 2017) Changed paths: M v6d.pod Log Message: --- Try to fix pod

[perl6/specs] 030df4: Fix POD error

2017-07-05 Thread GitHub
ed, 05 Jul 2017) Changed paths: M v6d.pod Log Message: --- Fix POD error

[perl6/specs] 845eb7: Typos and POD fixes in S02

2014-11-03 Thread GitHub
) Changed paths: M S02-bits.pod Log Message: --- Typos and POD fixes in S02

[perl6/specs] d8869f: Pod would be an IO::Handle, not an IO::Path

2014-10-05 Thread GitHub
) Changed paths: M S02-bits.pod Log Message: --- Pod would be an IO::Handle, not an IO::Path Commit: a5df488e95515f034982d7a5d844a0c322c5afa2 https://github.com/perl6/specs/commit/a5df488e95515f034982d7a5d844a0c322c5afa2 Author: Elizabeth Mattijsen l...@dijkmat.nl Date

[perl6/specs] 5aed9c: Fix some minor POD errors

2014-08-06 Thread GitHub
) Changed paths: M S17-concurrency.pod M S28-special-names.pod M S32-setting-library/IO.pod M S99-glossary.pod Log Message: --- Fix some minor POD errors Stops perldoc complaining about missing encodings and parser confusion. Commit

[perl6/specs] ceebcf: Add splat; Fix some POD errors and long lines.

2014-08-06 Thread GitHub
paths: M S99-glossary.pod Log Message: --- Add splat; Fix some POD errors and long lines.

[perl6/specs] 8c901d: Refer to .content method for Pod blocks rather tha...

2014-07-16 Thread GitHub
: M S26-documentation.pod Log Message: --- Refer to .content method for Pod blocks rather than .contents

[perl6/specs] 64799d: Fixing pod errors in S05

2014-05-14 Thread GitHub
paths: M S05-regex.pod Log Message: --- Fixing pod errors in S05 nested lists were messed up around line 2270

[perl6/specs] 800d9f: Remove pod tags as a source of meta-information

2014-03-13 Thread GitHub
) Changed paths: M S19-commandline.pod Log Message: --- Remove pod tags as a source of meta-information Meta-information of a compilation unit will need to be specified in the (currently being specced) META.info file of a distribution.

[perl6/specs] 1446a9: Remove some more pod-based authoritative info

2014-03-13 Thread GitHub
) Changed paths: M S11-modules.pod Log Message: --- Remove some more pod-based authoritative info

[perl6/specs] 3e8a4d: Use pod compunit credentials as defaults only

2013-12-05 Thread GitHub
) Changed paths: M S11-modules.pod Log Message: --- Use pod compunit credentials as defaults only Leave all the nitty gritty to the actual implementation on the install interface.

[perl6/specs] 6af26e: s/Pod6::/Pod::/g to match Rakudo and Niecza

2013-08-29 Thread GitHub
) Changed paths: M S26-documentation.pod Log Message: --- s/Pod6::/Pod::/g to match Rakudo and Niecza

[perl6/specs] f6636e: [S21] Fixed some POD formatting errors.

2012-11-23 Thread GitHub
: M S21-calling-foreign-code.pod Log Message: --- [S21] Fixed some POD formatting errors. The errors were mainly problems with item lists and missing whitespace around directives.

[perl6/specs] a95049: [S02] fix POD error

2012-04-09 Thread GitHub
paths: M S02-bits.pod Log Message: --- [S02] fix POD error

Re: [perl6/specs] 6ef69b: pod vars are now lowercase as seen in 3e1a9a5a576b...

2012-04-05 Thread Damian Conway
-case, but aren't) and the semantics of upper-case (should be semantic blocks, but aren't). So we changed them to what the syntax and semantics were telling us they should be: lower-case. But this change broke the one-to-one mapping between Pod sections and Pod-access variables. Previously

Re: [perl6/specs] 6ef69b: pod vars are now lowercase as seen in 3e1a9a5a576b...

2012-04-05 Thread herbert breunung
mapping between Pod sections and Pod-access variables. Previously it was: =pod- $=pod =UserDef- $=UserDef =SYNOPSIS - $=SYNOPSIS =DATA - $=DATA But, after the Riga discussions it became: =pod- $=pod =UserDef

[perl6/specs] 46a599: removing antiquities regarding Pod, applying pat...

2012-04-05 Thread GitHub
) Changed paths: M S02-bits.pod Log Message: --- removing antiquities regarding Pod, applying patch by damian Commit: a65c854a075054fedb5524b8897d11ecd0936333 https://github.com/perl6/specs/commit/a65c854a075054fedb5524b8897d11ecd0936333 Author: Herbert Breunung lichtk

Re: [perl6/specs] 6ef69b: pod vars are now lowercase as seen in 3e1a9a5a576b...

2012-04-05 Thread Damian Conway
Thank you damian, i will apply that patch, Much appreciated, Herbert! Damian

Re: [perl6/specs] 6ef69b: pod vars are now lowercase as seen in 3e1a9a5a576b...

2012-04-04 Thread herbert breunung
Message: --- pod vars are now lowercase as seen in 3e1a9a5a576b90e9eeabdb7083d16431513513f2

[perl6/specs] 6ef69b: pod vars are now lowercase as seen in 3e1a9a5a576b...

2012-04-03 Thread GitHub
) Changed paths: M S28-special-names.pod Log Message: --- pod vars are now lowercase as seen in 3e1a9a5a576b90e9eeabdb7083d16431513513f2

[perl6/specs] 3ac109: Disallow Pod blocks inside of Formatting Codes.

2011-08-21 Thread noreply
) Changed paths: M S26-documentation.pod Log Message: --- Disallow Pod blocks inside of Formatting Codes. Commit: bf64672f51ab45faa3059eb428532551bcb4ea74 https://github.com/perl6/specs/commit/bf64672f51ab45faa3059eb428532551bcb4ea74 Author: Tadeusz Sośnierz tadzi

[perl6/specs] a68bbb: [S19] break up unintentional pod formatting code

2011-01-30 Thread noreply
: M S19-commandline.pod Log Message: --- [S19] break up unintentional pod formatting code Commit: e144eacb2967f40a782e439d527a65cc0a577f8e https://github.com/perl6/specs/commit/e144eacb2967f40a782e439d527a65cc0a577f8e Author: Fitz Elliott felli...@virginia.edu Date: 2011-01-29 (Sat

Re: How are unrecognized options to built-in pod block types treated?

2010-08-05 Thread Aaron Sherman
namespace system, however. Using it would seem wise. Explicit versioning is your friend. Can I get some support for this? Not from me. ;-) I think it's a dreadful prospect to allow people to write documentation that they will have to rewrite when the Pod spec gets updated. I would

Re: How are unrecognized options to built-in pod block types treated?

2010-08-05 Thread Carl Mäsak
Darren (): Read what I said again.  I was proposing that the namespace comprised of names matching a pattern like this:  /^ [A..Z]+ | [a..z]+ $/ /^ [[A..Z]+ | [a..z]+] $/ // Carl

How are unrecognized options to built-in pod block types treated?

2010-08-04 Thread Carl Mäsak
Straight to an example: =for head1 :imageulteriorepicure-328651980.jpg Steaming hot Cfor loops As far as parsing goes, that's valid Perl 6 Pod. You're perhaps more used to seeing it as '=head1', but S26 asserts the equivalence of these two forms. The reason I'm using the paragraph

Re: How are unrecognized options to built-in pod block types treated?

2010-08-04 Thread Damian Conway
and the parser should simply accept them without complaint and include them in the internal data structure it builds, whereupon they will be available to user-defined Pod extensions. Damian

Re: How are unrecognized options to built-in pod block types treated?

2010-08-04 Thread jerry gay
they are parsed. Mixed-case config options should be freely available to users and the parser should simply accept them without complaint and include them in the internal data structure it builds, whereupon they will be available to user-defined Pod extensions. Damian are there codepoints in unicode

Re: How are unrecognized options to built-in pod block types treated?

2010-08-04 Thread Aaron Sherman
or not. Is this allowed? S26 only tells me this about config options: Pod predefines a small number of standard configuration options that can be applied uniformly to any built-in block type. To me, predefines could mean either we made these for you; use only those or we made these for you

Re: How are unrecognized options to built-in pod block types treated?

2010-08-04 Thread Darren Duncan
at least a warning when they are parsed. Mixed-case config options should be freely available to users and the parser should simply accept them without complaint and include them in the internal data structure it builds, whereupon they will be available to user-defined Pod extensions

Re: How are unrecognized options to built-in pod block types treated?

2010-08-04 Thread Damian Conway
Aaron wrote: I dislike reserved in this context, but understand why the namespace has to be shared. For config options, I'd say anything should go, but people inventing their own config options should be aware that across N release cycles, new options may be introduced. ...which means that

Re: How are unrecognized options to built-in pod block types treated?

2010-08-04 Thread Darren Duncan
to be there by default. This is somewhat analogous to the main:: namespace for Perl code. A parallel solution would be that POD can declare a version, similarly to how Perl code can declare a Perl version, whose spec it is expected to be interpreted according to. If POD declares

Re: How are unrecognized options to built-in pod block types treated?

2010-08-04 Thread Brandon S Allbery KF8NH
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/4/10 21:26 , Darren Duncan wrote: jerry gay wrote: are there codepoints in unicode that may be either upper-case or lower-case, depending on the charset? if so, then there's ambiguity here, depending on the user's locale. i suspect not, but

Re: How are unrecognized options to built-in pod block types treated?

2010-08-04 Thread Darren Duncan
Brandon S Allbery KF8NH wrote: On 8/4/10 21:26 , Darren Duncan wrote: jerry gay wrote: are there codepoints in unicode that may be either upper-case or lower-case, depending on the charset? if so, then there's ambiguity here, depending on the user's locale. i suspect not, but languages are

Re: How are unrecognized options to built-in pod block types treated?

2010-08-04 Thread David Green
On 2010-08-04, at 7:43 pm, Darren Duncan wrote: A parallel solution would be that POD can declare a version, similarly to how Perl code can declare a Perl version, whose spec it is expected to be interpreted according to. I thought that was more or less how it worked anyway. You can make

POD classes -- a suggestion

2009-09-16 Thread Aaron Sherman
I'd really like to be able to assign a class to POD documentation. Here's an example of why: class Widget is Bauble #= A widget is a kind of bauble that can do stuff { has $.things; #= a collection of other stuff #==XXX{ This variable needs to be replaced for political reasons

Fwd: More flexible POD

2009-08-11 Thread Matthew Walton
POD To: Jon Lang datawea...@gmail.com I'm not sure what it should be, but I do believe that there should be a solution which allows elegant mixing of code and Pod. I want to document my APIs by attaching the documentation to the methods in question, otherwise the documentation won't get updated when

Re: More flexible POD

2009-08-11 Thread Mark Overmeer
Being on holidays, it is not easy to follow threads closely, so if I repeat things other people have said already, I apologize beforehand. My responses may b late as well. Two years ago, I discussed various options, which compared POD to features in to other languages and suggested various

Re: pod variables?

2009-03-01 Thread Timothy S. Nelson
On Fri, 27 Feb 2009, Darren Duncan wrote: Jon Lang wrote: Under the section about twigils in S02, $=var is described as a pod variable. I'm not finding any other references to pod variables; what are tey, and how are they used? (In particular, I'm wondering if they're a fossil

pod variables?

2009-02-27 Thread Jon Lang
Under the section about twigils in S02, $=var is described as a pod variable. I'm not finding any other references to pod variables; what are tey, and how are they used? (In particular, I'm wondering if they're a fossil; if they aren't, I'd expect further information about them to be in S26

Re: pod variables?

2009-02-27 Thread Darren Duncan
Jon Lang wrote: Under the section about twigils in S02, $=var is described as a pod variable. I'm not finding any other references to pod variables; what are tey, and how are they used? (In particular, I'm wondering if they're a fossil; if they aren't, I'd expect further information about them

Perl 6 pod processor in Perl 5

2009-02-11 Thread Gabor Szabo
://kobesearch.cpan.org/dist/Perl6-Conf Not surprisingly neither of them can handle the perl pod. I contacted both maintainers asking to look into it suggesting to use Perl6::Perldoc of Damian but it is quite old. Is there any other module written in Perl 5 that could parse a perl 6 file, recognize

Re: Perl 6 pod processor in Perl 5

2009-02-11 Thread Mark Overmeer
* Gabor Szabo (szab...@gmail.com) [090212 06:44]: As an experiment to check how we could reuse CPAN to distribute Perl 6 packages. Not surprisingly neither of them can handle the perl pod. I contacted both maintainers asking to look into it suggesting to use Perl6::Perldoc of Damian

S*.pod edits submissions

2008-08-31 Thread John M. Dlugosz
I have changed files at http://www.dlugosz.com/Perl6/offerings/ waiting for someone in authority to merge.

POD in the test suite

2008-01-18 Thread Moritz Lenz
I noticed that many test files contain old POD like this: =pod some description here =cut Should that all be replaced by the new POD? =begin description text here =end description -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ signature.asc Description: OpenPGP

Re: POD in the test suite

2008-01-18 Thread Larry Wall
On Fri, Jan 18, 2008 at 10:54:11AM +0100, Moritz Lenz wrote: : I noticed that many test files contain old POD like this: : : =pod : : some description here : : =cut : : : Should that all be replaced by the new POD? : : =begin description : : text here : : =end description Jah, so glaube

Re: Some Things I'd Like To Do With Pod

2007-06-24 Thread Piers Cawley
On 22/06/07, brian d foy [EMAIL PROTECTED] wrote: ===Per class documentation, not per file documentation Related to the one above, I'd like to have NAME, SYNOPSIS, etc. for each class, not just per file. Well, what I really want is the Smalltalk class and method browsers, but I know I'm not

Re: Pod 6: ease of implementation vs easy of use

2007-06-17 Thread Mark Overmeer
* Damian Conway ([EMAIL PROTECTED]) [070616 23:21]: I will, however, take a moment to answer the accusation that I appear to have redesigned Pod the way I did in order to make implementation easier... The opposit: your work is known to seek the corners of the language which hurt most. So

Re: POD - Code entanglement

2007-06-16 Thread John Beppu
is close to how OODoc is extending POD for Perl5. IMO We can (should) do better for Perl6. -- MarkOv Mark Overmeer MScMARKOV Solutions [EMAIL PROTECTED

Pod 6: ease of implementation vs easy of use

2007-06-16 Thread Damian Conway
I'm not going to argue about the design of Pod 6 any more. As both Mark and brian have pointed out, this really comes down to philosophical differences that no amount of discussion is going to resolve. In any case, I'm sure that Larry now has plenty of grist from which to mill a final

POD - Code entanglement (was: Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn)

2007-06-14 Thread Moritz Lenz
to the pod: =begin pod =head3 Cmethod from_string(Str $s); initialize the Sudoku from a string C$s, with a 0 denoting an empty cell and a number between 1 and 9 a clue. Note that there is currently no way to use this function for sizes bigger than 9x9 overall length. =end pod method from_string

Re: POD - Code entanglement

2007-06-14 Thread Thomas Wittek
Moritz Lenz: =begin pod =head3 Cmethod from_string(Str $s); [..] =end pod method from_string(Str $s){ # implementation of that method here } Since method signatures are very expressive in Perl 6, there should be a way of accessing them in the POD without copy paste. As I

Re: POD - Code entanglement

2007-06-14 Thread Mark Overmeer
love the power of CSS. I could imagine a semantic documentation in Perl6, that could be translated to XML/HTML+CSS or to POD(6) for formatting it. The nicest thing would be that the semantic docs become part of the parse tree, which then (using standard introspection) can be used to generate

Re: POD - Code entanglement

2007-06-14 Thread Juerd Waalboer
as *external* documentation. That's nice. Semantics are very useful in documentation, why throw them away? Why not have both? With normal POD as suggested by Damian, you could still generate it from something else. A few macros could help ignore the inline documentation. -- korajn salutojn, juerd

Re: POD - Code entanglement

2007-06-14 Thread Aankhen
On 6/14/07, Thomas Wittek [EMAIL PROTECTED] wrote: It's a bit like HTML-XML, where the former lacks most of the semantics and makes the information processing - not to speak about a consistent look over several documents - a lot harder. Actually, that's incorrect. HTML is a markup language

Re: POD - Code entanglement

2007-06-14 Thread Ruud H.G. van Tol
Mark Overmeer schreef: The nicest thing would be that the semantic docs become part of the parse tree, which then (using standard introspection) can be used to generate manual pages, natively into POD, roff, HTML, whatever. I like to call them: lexical comments. -- Groet, Ruud

Re: POD - Code entanglement

2007-06-14 Thread Thom Boyer
Thomas Wittek wrote: I mean POD uses constructs like headlines, lists, blocks, italic etc. which all describe _how it looks like_ and not _what it is_. I think Damian would take exception to that statement. He worked quite hard to make sure that POD describes _meaning_ rather than

Re: POD - Code entanglement

2007-06-14 Thread Moritz Lenz
Thomas Wittek wrote: Moritz Lenz: =begin pod =head3 Cmethod from_string(Str $s); [..] =end pod method from_string(Str $s){ # implementation of that method here } Since method signatures are very expressive in Perl 6, there should be a way of accessing them in the POD without

Re: POD - Code entanglement

2007-06-14 Thread Mark Overmeer
above syntax, why not define =method the method synopsis goes here =option foo is the fooiest parameter =default foo 10 =requires bar is the barstest parameter Which is close to how OODoc is extending POD for Perl5. IMO We can (should) do better for Perl6

Re: multi-line comments, C macros, Pod abuse

2006-08-21 Thread Joshua Hoblitt
On Mon, Aug 21, 2006 at 12:06:36AM +0100, Andrew Suffield wrote: On Sun, Aug 20, 2006 at 03:55:56PM -0600, Luke Palmer wrote: Why would you care about introducing a new lexical scope? You would care about that if you used a variable you declared in the commented code in the code below

Re: multi-line comments, C macros, Pod abuse

2006-08-21 Thread markjreed
I think this is not even a metaprogramming issue so much as a programming environment one. I mean, if your editor doesn't make it easy to stick a # at the beginning of a bunch of lines with one action, and likewise remove them later, you need to get a new editor. :) On 8/21/06, Joshua Hoblitt

Re: multi-line comments, C macros, Pod abuse

2006-08-20 Thread Joshua Hoblitt
On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote: On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote: You don't actually need a macro in that case: if 0 { q ... } Which, of course, eliminates the original desire to have a code-commenting construct where you just

Re: multi-line comments, C macros, Pod abuse

2006-08-20 Thread Mark J. Reed
On 8/20/06, Joshua Hoblitt [EMAIL PROTECTED] wrote: This is exactly the type of construct that I had in mind. A couple of questions. Is code inside of a #{}: - parsed and required to be syntacticly correct? No. It's a comment. # followed by one or more open bracket characters creates a

Re: multi-line comments, C macros, Pod abuse

2006-08-20 Thread Andrew Suffield
', is it a no-op? Which isn't true for #{}/{}, because {} introduces new lexical scope. It's still a pretty good idea, but it's not as good as the C preprocessor. if (0) has the same problem. Pod doesn't. Anybody able to think up a non-pod construct that doesn't affect the code it wraps? (Solutions which

Re: multi-line comments, C macros, Pod abuse

2006-08-20 Thread Larry Wall
On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote: : On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote: : On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote: : You don't actually need a macro in that case: : : if 0 { q : ... : } : : Which, of course,

Re: multi-line comments, C macros, Pod abuse

2006-08-20 Thread Luke Palmer
here is this one: - when 'uncommented', is it a no-op? Which isn't true for #{}/{}, because {} introduces new lexical scope. It's still a pretty good idea, but it's not as good as the C preprocessor. if (0) has the same problem. Pod doesn't. Anybody able to think up a non-pod construct

Re: multi-line comments, C macros, Pod abuse

2006-08-20 Thread Luke Palmer
On 8/20/06, Luke Palmer [EMAIL PROTECTED] wrote: Well, I think you are being too picky. [snip snarky sarcastic rant] Hmm, perhaps I'm feeling edgy. Or maybe some of the comments reminded me of those rediculously long, whiny threads. Anyway, that was un-called-for. Luke

Re: multi-line comments, C macros, Pod abuse

2006-08-20 Thread Andrew Suffield
On Sun, Aug 20, 2006 at 03:55:56PM -0600, Luke Palmer wrote: The important question here is this one: - when 'uncommented', is it a no-op? Which isn't true for #{}/{}, because {} introduces new lexical scope. Why would you care about introducing a new lexical scope? You would care

Re: multi-line comments, C macros, Pod abuse

2006-08-19 Thread Nicholas Clark
On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote: On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote: You don't actually need a macro in that case: if 0 { q ... } Which, of course, eliminates the original desire to have a code-commenting construct where you just

Re: multi-line comments, C macros, Pod abuse

2006-08-19 Thread Dr.Ruud
Stuart Cook schreef: Larry Wall: if 0 { ... } The one disadvantage of that approach is that it will break if the commented-out code temporarily fails to compile. How frequent does that happen? And in that case s/if 0/\#/, as Luke mentioned. And if the compile failure has to

Re: multi-line comments, C macros, Pod abuse

2006-08-19 Thread Daniel Hulme
Stuart Cook schreef: Larry Wall: if 0 { ... } The one disadvantage of that approach is that it will break if the commented-out code temporarily fails to compile. How frequent does that happen? All the time. I often comment out bits of code while I'm refactoring or

multi-line comments, C macros, Pod abuse

2006-08-18 Thread Joshua Hoblitt
. E.g. #if 1 (magic now happens)... #endif The best equivalent I've been able to come up with in Perl 5 is: =for off ... =cut #=for off (magic now happens)... =cut Except that now this requires all sorts of weird voodoo to keep the Pod formatting from

Re: multi-line comments, C macros, Pod abuse

2006-08-18 Thread Larry Wall
On Fri, Aug 18, 2006 at 11:58:20AM -1000, Joshua Hoblitt wrote: : It occurred to me that other day that in our in house C code we : somewhat frequently use an idiom that's not easily translated into Perl : 5. Our rule is that if your commenting out more then 1 or 2 lines of : code that you wrap

Re: multi-line comments, C macros, Pod abuse

2006-08-18 Thread Stuart Cook
On 8/19/06, Larry Wall [EMAIL PROTECTED] wrote: if 0 { ... } The one disadvantage of that approach is that it will break if the commented-out code temporarily fails to compile. If that's a problem, though, you could always write your own macro. Stuart Cook

Re: multi-line comments, C macros, Pod abuse

2006-08-18 Thread Aaron Crane
Stuart Cook writes: On 8/19/06, Larry Wall [EMAIL PROTECTED] wrote: if 0 { ... } The one disadvantage of that approach is that it will break if the commented-out code temporarily fails to compile. If that's a problem, though, you could always write your own macro. You don't

Re: multi-line comments, C macros, Pod abuse

2006-08-18 Thread Luke Palmer
On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote: You don't actually need a macro in that case: if 0 { q ... } Which, of course, eliminates the original desire to have a code-commenting construct where you just change the 0 to a 1. After all, we already have #{}.

Linking Synopses to corresponding pod-files?

2006-05-04 Thread Markus Laire
When reading Synopses, I sometimes notice some mistakes or typos, which I'd like to submit a patch for, but it's not easy to do so as I don't know where to get the source. Could each Synopsis include a link to the corresponding .pod (if it's available in Internet, that is), so that submitting

Re: Linking Synopses to corresponding pod-files?

2006-05-04 Thread Juerd
Markus Laire skribis 2006-05-04 14:55 (+0300): When reading Synopses, I sometimes notice some mistakes or typos, which I'd like to submit a patch for, but it's not easy to do so as I don't know where to get the source. Have you tried s/html/pod/? :) Juerd -- http://convolution.nl

Re: Linking Synopses to corresponding pod-files?

2006-05-04 Thread Markus Laire
On 5/4/06, Juerd [EMAIL PROTECTED] wrote: Markus Laire skribis 2006-05-04 14:55 (+0300): When reading Synopses, I sometimes notice some mistakes or typos, which I'd like to submit a patch for, but it's not easy to do so as I don't know where to get the source. Have you tried s/html/pod

S05.pod

2006-04-17 Thread Sean Sieger
from There are no C/s or C/m modifiers (changes to the meta-characters replace them - see below). to There are no C/s or C/m modifiers (change to the meta-characters that replace them - see below).

Re: S05.pod

2006-04-17 Thread Trey Harris
In a message dated Mon, 17 Apr 2006, Sean Sieger writes: from There are no C/s or C/m modifiers (changes to the meta-characters replace them - see below). to There are no C/s or C/m modifiers (change to the meta-characters that replace them - see below). I don't think so There are no

apo/A06.pod: spelling error(s)?

2005-04-20 Thread Steven Philip Schubiger
In macro circumfix:(*...*) () is parsed(/.*?/ { } is the second enclosing part of the parsed parentheses omitted by intention? If not, I'd volunteer to provide a patch. Steven

Re: apo/A06.pod: spelling error(s)?

2005-04-20 Thread Luke Palmer
Steven Philip Schubiger writes: In macro circumfix:(*...*) () is parsed(/.*?/ { } is the second enclosing part of the parsed parentheses omitted by intention? If not, I'd volunteer to provide a patch. Fixed. Thanks. Luke

[PATCH] Re: apo/A06.pod: spelling error(s)?

2005-04-20 Thread Steven Philip Schubiger
. Steven --- perl6/doc/trunk/design/apo/A06.pod Wed Apr 20 20:03:19 2005 +++ perl6/doc/trunk/design/apo/A06.pod Wed Apr 20 20:05:32 2005 @@ -3004,12 +3004,12 @@ interpolated with a special C ... marker, which is considered part of the name: -macro circumfix:(*...*) () is parsed

Re: [PATCH] Re: apo/A06.pod: spelling error(s)?

2005-04-20 Thread Patrick R. Michaud
On Wed, Apr 20, 2005 at 08:13:20PM +0200, Steven Philip Schubiger wrote: On 20 Apr, Luke Palmer wrote: : Steven Philip Schubiger writes: : In : macro circumfix:(*...*) () is parsed(/.*?/ { } : : is the second enclosing part of the parsed parentheses omitted : by intention? If not, I'd

[PATCH] apo/A06.pod: spelling error(s)

2005-04-17 Thread Steven Philip Schubiger
A spelling mistake and a word, that supposedly has been forgotten. Steven --- apo/A06.pod Sun Apr 17 14:34:16 2005 +++ apo/A06.pod Sun Apr 17 14:42:37 2005 @@ -2021,7 +2021,7 @@ All blocks are considered closures in Perl 6, even the blocks that declare modules or classes

Re: [PATCH] apo/A06.pod: spelling error(s)

2005-04-17 Thread Patrick R. Michaud
On Sun, Apr 17, 2005 at 02:52:27PM +0200, Steven Philip Schubiger wrote: A spelling mistake and a word, that supposedly has been forgotten. Steven Applied, thanks! Pm --- apo/A06.pod Sun Apr 17 14:34:16 2005 +++ apo/A06.pod Sun Apr 17 14:42:37 2005

[PATCH] apo/A05.pod: spelling error

2005-04-08 Thread Steven Schubiger
Attached is a patch that fixes a minor spelling error in apocalypse 5. Steven --- A05.pod.origThu Apr 7 22:59:16 2005 +++ A05.pod Thu Apr 7 22:59:56 2005 @@ -2179,7 +2179,7 @@ tree of objects. Matching against such boundaries or metadata would not be possible -unless

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

2005-03-17 Thread Brent 'Dax' Royal-Gordon
David Storrs [EMAIL PROTECTED] wrote: Aside from links, that's pretty much the entire perlpodtut boiled down into 7 bullets; a little experimentation to get the hang of it and it all holds together nicely, easy to remember. Yes, yes, yes. Pod is one of the things Perl 5 did almost exactly

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

2005-03-17 Thread Aaron Sherman
. Yes, yes, yes. Pod is one of the things Perl 5 did almost exactly right. Absolutely, and that's why I'd like to see more POD details preserved. It's simple, intuitive, and stays out of your way. It gives you most of the formatting primitives you actually *need*, and nicely balances the need

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

2005-03-17 Thread Aaron Sherman
, and given how hard it is for PERL to do the right thing, there, I think it's fair to fall back on only perl can parse perl, and just do what the eye suggests is correct. Remember that POD (and thus Kwid) are not intended to be Perl-specific, just Perl-friendly. You can always: C{$x[0

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

2005-03-17 Thread Juerd
this fact at our peril, and the hacks in pod syntax (e.g. C ) to get around this are glaring anti- huffmanisms. Other than awareness, this really doesn't have a point to it. In ASCII, ' was meant as an apostrophe, but we use it as a quote. Yen was never meant to have anything to do with zipping

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

2005-03-17 Thread Brian Ingerson
just a matter of: do you make it Wikiish or PODish? Aaron, I think AJS Kwid is fine if it fits your brain. It doesn't fit mine in much the same way that Kwid doesn't fit yours, in much the same way that Pod doesn't quite fit either of ours. The interesting thing to me is that all 3 syntaxes map

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

2005-03-17 Thread Aaron Sherman
On Thu, 2005-03-17 at 09:54, Juerd wrote: Pod needs incremental improvements--tables Oops, forgot that one. I'll add it tonight, when I get home from work. See PodTables in the Pugs wiki. Or see the archive of this list, where we hammered it out previously. YMMV. I'll have the second

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

2005-03-17 Thread Juerd
Aaron Sherman skribis 2005-03-17 16:30 (-0500): See PodTables in the Pugs wiki. Or see the archive of this list, where we hammered it out previously. Since when is anything in Perl 6, except its name, set in stone? PodTables is a more detailed and more consistent approach to a suggestion I

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

2005-03-17 Thread Aaron Sherman
On Thu, 2005-03-17 at 16:39, Juerd wrote: Aaron Sherman skribis 2005-03-17 16:30 (-0500): See PodTables in the Pugs wiki. Or see the archive of this list, where we hammered it out previously. Since when is anything in Perl 6, except its name, set in stone? PodTables is a more detailed

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

2005-03-17 Thread Aaron Sherman
of the above was news to you, then I suggest you take another look at why POD (and more generally, any abstract markup language) exists. If any of the above were NOT true, it would be contrary to the entire point of an abstract, layout-neutral markup language. It is, however, contrary to the spirit

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

2005-03-17 Thread Brent 'Dax' Royal-Gordon
Aaron Sherman [EMAIL PROTECTED] wrote: Specifically, I like the use of angle brackets in Pod. Angle brackets are simple, distinctive shapes; they remain wide in variable-width This is aesthetic preference. I could cite the reasons that I have an aesthetic preference for the other syntax

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

2005-03-17 Thread Aaron Sherman
On Thu, 2005-03-17 at 17:07, Brent 'Dax' Royal-Gordon wrote: Aaron Sherman [EMAIL PROTECTED] wrote: and the hacks in pod syntax (e.g. C ) to get around this are glaring anti- huffmanisms. Whatever bracketing character we decide to use, there will always be occasions where we need

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

2005-03-17 Thread Sam Vilain
Aaron Sherman wrote: Sam mugwump Vilain refers to each of these syntaxes as /Pod dialects/. He is working on more formally defining the common model or AST that these dialects map to. Why? Seriously, why on earth do you want to encourage the proliferation of variant markup languages?! There aren't

Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]

2005-03-17 Thread gcomnz
On Thu, 17 Mar 2005 16:16:00 -0700, gcomnz [EMAIL PROTECTED] wrote: Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote: By the way, I think I've seen a few people suggest some sort of syntax-switching mechanism for Pod6. The day people have to think about what dialect of Pod they're using

  1   2   3   >