On Mon, 2 Oct 2000, Jarkko Hietaniemi wrote:
> > Assuming that the perl parser generated IV SVs rather than NVs for
> > the 2 constants 2,3, then my scheme would handle this fine; the IV
>
> It currently does so.
>
> > version of add() would be called, and an IV SB would result.
>
> "The IV ve
On 2 Oct 2000, at 21:04, Adam Turoff wrote:
> If you want to use XML, Latex, Texinfo or raw *roff for your docs,
> then by all means do so. Understand that Perl can't be made to
> magically ignore embedded Texinfo, and Perl contributors realistically
> can't be made to understand/patch/correct m
On 2 Oct 2000, at 10:35, Garrett Goebel wrote:
> From: John Porter [mailto:[EMAIL PROTECTED]]
> >
> > It would be very detrimental to perl's performance to have to do an
> > XML parse of every input source file.
>
> if the parser can skip between:
>
> =pod
>
> =cut
>
> it can certainly be m
> Retracting would have been easier, but could very well be seen as giving up
> on pointing out PODs deficiencies.
Pointing POD deficiencies is fine. But the fundamental thrust of the RFC
is still "replace POD with XML". That's why I even noted the alternative
names and corresponding emphasis in
On Sun, 1 Oct 2000, Adam Turoff wrote:
> POD has three mighty significant advantages over XML:
> - it is easy to learn
> - it is to write
> - it is easy to ignore, if you're spelunking for Perl code
> Try and do that, when interferes with syntactically.
[snip]
> Moving towards a sys
At 08:36 04/10/2000 -0700, Nathan Wiger wrote:
>This RFC should either be retracted, or revised into:
>
> POD to XML translation should be easier
On this subject, I have notes about a Pod::SAX module that would make
pod2xml much easier. If I have time to implement it I'll do it, but I can't
tel
> >The knowledge gathered from writing the modules Storable,
> >Freeze::Thaw, and Data::Dumper, should be studied very carefully.
Those are my lifeblood, that's why I proposed having them in the core as being key to
persistance and communication. I store in binary and
communicate with Data::D
> One C++ problem I just found out is memory management. It seems
> that it's impossible to 'new' an object from an specified memory block.
> So it's impossible to put free'd objects in memory pool and re-allocate
> them next time.
It can't be done by the default new operator, but you can do it
On Wednesday, October 04, 2000 4:15 AM, Tom Christiansen
[SMTP:[EMAIL PROTECTED]] wrote:
> >POD, presumably. Or maybe son-of-POD; it would be nice to have better
> >support for tables and lists.
>
> We did this for the camel. Which, I remind the world, was
> written in pod.
>
> ''tom
Uh...
w
On Wednesday, October 04, 2000 1:21 AM, Perl6 RFC Librarian
[SMTP:[EMAIL PROTECTED]] wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Exception objects and classes for builtins
>
> =head1 VERSION
>
> Maintainer: Peter Scott <[EMAIL PROTE
Garrett Goebel wrote:
> From: Peter Scott [mailto:[EMAIL PROTECTED]]
> >
> > As I said earlier, why don't we just define a syntax for
> > *anything* to be used as an extension language, and let
> > the, er, market decide?
>
> Peaceful coexistance... what a concept.
Sounds to me like the real i
On Wed, 04 Oct 2000 03:15:22 -0600, Tom Christiansen wrote:
>We did this for the camel. Which, I remind the world, was
>written in pod.
You, masochist.
(duck, and run)
--
Bart.
Dan Sugalski wrote:
> At 03:23 PM 9/29/00 -0400, ye, wei wrote:
> >Dan Sugalski wrote:
> >
> > > At 02:29 PM 9/29/00 +0100, David Mitchell wrote:
> > > >Regarding the tentative list of vtable functions:
> > > >I'm rather worried about binary operators, eg 'is_equal', 'add' etc.
> > > >The danger
>POD, presumably. Or maybe son-of-POD; it would be nice to have better
>support for tables and lists.
We did this for the camel. Which, I remind the world, was
written in pod.
''tom
14 matches
Mail list logo
