On 2009-Aug-17, at 12:27 pm, Moritz Lenz wrote:
However it seems we have to pay a price: each act of rendering a Pod
file actually means executing the program that's being documented (at
least the BEGIN blocks and other stuff that happens at compile time),
with all the security risks implied. So
On Tue, Aug 11, 2009 at 12:42 PM, Jon Lang wrote:
> jerry gay wrote:
>> for the latest spec changes regarding this item, see
>> http://perlcabal.org/svn/pugs/revision/?rev=27959.
>>
>> is everyone equally miserable now? ;)
>
> Already seen it. My latest points still stand, though: #`(...) is
> sti
On Mon, 17 Aug 2009, Jon Lang wrote:
Well, I definitely think there needs to be a class that combines the
inside and the outside, or the data and the metadata. Certainly the
separate parts will exist separately for purposes of implementation, but
there needs to be a user-friendlier view wrapped
Could we also get "=numbered" and "=term" directives that are
equivalent to "=item :numbered" and "=item :term", respectively, for
use with abbreviated blocks? E.g.:
=numbered First Item
=numbered Second Item
=numbered Third Item
=term First Name
Definition
=term Second Na
On Sun, Aug 16, 2009 at 1:26 PM, Damian Conway wrote:
> * This means Pod can be indented; the = is no longer tied to the
> first column. The indentation preceding the opening = (using the
> ($?TABSTOP // 8) rule, as for heredocs) now specifies the zeroth
> column of the Pod block.
Wi
Troels Liebe Bentsen wrote:
> Hey,
>
> Just joined the list, and I too have been thinking about a good path literal
> for Perl 6. Nice to see so many other people are thinking the same :).
Welcome to the list!
> Not knowing where to start in this long thread, I will instead try to show how
> I wo
Hey,
Just joined the list, and I too have been thinking about a good path literal
for Perl 6. Nice to see so many other people are thinking the same :).
Not knowing where to start in this long thread, I will instead try to show how
I would like a path literal to work. For me a path literal is a w
raiph mellor wrote:
>> However it seems we have to pay a price: each act of rendering a Pod
>> file actually means executing the program that's being documented (at
>> least the BEGIN blocks and other stuff that happens at compile time),
>> with all the security risks implied. So we'll need a *very
> Nonetheless, DOC INIT { system "rm -rf ." } (or etc.) would be unfortunate.
Gotcha. Perhaps something like perl6 -DOC is needed to execute DOC
blocks in the file passed on the command line and files it use's,
whereas perl6 -doc only processes DOC blocks in the Setting or its
use'd files, and mer
On Aug 17, 2009, at 14:34 , raiph mellor wrote:
However it seems we have to pay a price: each act of rendering a Pod
file actually means executing the program that's being documented (at
least the BEGIN blocks and other stuff that happens at compile time),
with all the security risks implied. So
On Aug 17, 2009, at 14:27 , Moritz Lenz wrote:
ll 99:
followed by a valid identifierN<
A valid identifier is a sequence of alphanumerics and/or
underscores, beginning with an alphabetic or underscore
Is there a good reason to deviate from Perl 6's definition of an
identifier?
> However it seems we have to pay a price: each act of rendering a Pod
> file actually means executing the program that's being documented (at
> least the BEGIN blocks and other stuff that happens at compile time),
> with all the security risks implied. So we'll need a *very* good
> sandbox. Is tha
On Sun, Aug 16, 2009 at 3:26 PM, Damian Conway wrote:
> It's Sunday evening and, as promised, here's the new draft of S26.
Thanks!
After an initial read thru the summary and spec my overall reaction to
the new pod is "whirled peas!". :)
> * Hence it must always parsed using full Perl 6 grammar:
Damian Conway wrote:
> It's not yet committed, as there will (no doubt) be much discussion
> first. I apologize in advance: I am still travelling on my annual world
> tour, so my ability to participate in this discussion will be limited
> and erratic.
In the spirit of "ask for forgiveness rather t
Timothy S. Nelson wrote:
> David Green wrote:
>> Jon Lang wrote:
>>> If so, could you give some examples of how such a distinction could be
>>> beneficial, or of how the lack of such a distinction is problematic?
>
> Well, my main thought in this context is that the stuff that can be
> done
On Sun, Aug 16, 2009 at 3:26 PM, Damian Conway wrote:
> * The DOC statement prefix constrains any block to which it is applied
> (including BEGIN, CHECK, INIT and similar) to run only if -doc is
> specified on the commandline
>
> * You can tell if you're running under -doc by checking $
16 matches
Mail list logo
