"David L. Nicol" <[EMAIL PROTECTED]> writes:
> Marc Lehmann wrote:
> >
> > On Sat, Dec 30, 2000 at 05:31:29AM +, "David L. Nicol" <[EMAIL PROTECTED]>
>wrote:
> > > I do not know exactly what the perl5 default sort heuristic is,
> > > aside that it tries to DWIM both numeric and string data.
I´ve upgraded from Linux Red Hat 6.2 to Linux Red Hat 7, and also upgraded from perl
5.00503 to perl 5.6.0. and now my perlcc doesn´t work anymore. It says it can´t find
the "boot_Dynaloader" and the "xs_init". Does anyone have a solution?
Thanks,
Chris Bernauer
Here's PDD #1, the first of the internals perl documents. (Bcc'd to the
RFC librarian, so he doesn't get a zillion replies)
Cut here
=head1 TITLE
A high-level overview of the perl system
=head1 VERSION
=head2 CURRENT
Maintainer: Dan Sugalski
Class: Meta
PDD Number: 1
V
On Tue, 2 Jan 2001, Jeff Okamoto wrote:
> I know this isn't necessarily a topic for -internals, but if someone
> could direct me to the right ML to think about how to make Perl easier
> to cross-compile, I'll take the discussion there.
[EMAIL PROTECTED] would be the right list, but Jarkko and I
On Tue, Jan 02, 2001 at 06:22:31PM -0800, Steve Fink wrote:
> Just in looking at your example, it seems like some complex replacements
> would be a bit of a pain to generate. It would be nice to have a
> specification for those opcode replacements. Like, say, perl code. How
> hard would it be to d
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 11:03 PM 1/3/01 +, Nick Ing-Simmons wrote:
>> Dan Sugalski <[EMAIL PROTECTED]> writes:
>> >Would someone like to take a crack at a PDD for the PerlIO system? It
>> >doesn't need to be particularly fancy (nor complete) to st
Would someone like to take a crack at a PDD for the PerlIO system? It
doesn't need to be particularly fancy (nor complete) to start with, but
having one will give us a place to work from. (Waiting for me to spec it
out may take a while...)
Dan
-
Dan Sugalski <[EMAIL PROTECTED]> writes:
>Would someone like to take a crack at a PDD for the PerlIO system? It
>doesn't need to be particularly fancy (nor complete) to start with, but
>having one will give us a place to work from. (Waiting for me to spec it
>out may take a while...)
I am will
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Would someone like to take a crack at a PDD for the PerlIO system?
DS> It doesn't need to be particularly fancy (nor complete) to start
DS> with, but having one will give us a place to work from. (Waiting
DS> for me to spec it out
At 11:03 PM 1/3/01 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >Would someone like to take a crack at a PDD for the PerlIO system? It
> >doesn't need to be particularly fancy (nor complete) to start with, but
> >having one will give us a place to work from. (Waiting
First off, this looks really cool to me, nice job. The only thing I'm a
little surprised by is this:
> =head2 Independent subsystems
>
> Perl also has a number of subsystems that are independent of any
> single module.
>
> =item PerlIO subsystem
>
> =item Regex engine
I would have actually ex
At 04:13 PM 1/3/01 -0800, Nathan Wiger wrote:
>First off, this looks really cool to me, nice job. The only thing I'm a
>little surprised by is this:
>
> > =head2 Independent subsystems
> >
> > Perl also has a number of subsystems that are independent of any
> > single module.
> >
> > =item PerlIO
I think one of the things we might want to do is figure out what people use
signals for and see if we can abstract out some of that functionality
without actually exposing signals. (From an internals standpoint, at least)
The big one I can think of is interrupting timers. Right now people use
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> A subsystem is, in this instance at least, a piece of perl that
DS> can more or less stand alone, but cross modules. The regex engine,
DS> for example, is pretty much a black box--hings go in and come out,
DS> an Magic Happens ins
2001-01-03-21:43:39 Dan Sugalski:
> I think one of the things we might want to do is figure out what people use
> signals for [...] The big one I can think of is interrupting
> timers. [...] (Excepting I/O signalish things, which will get
> handled elsewhere)
How about, goosing long-lived daemon
> "BT" == Bennett Todd <[EMAIL PROTECTED]> writes:
BT> How about, goosing long-lived daemons to ask 'em to re-read their
BT> config files? The only signal code I ever wrote for perl was for
BT> that --- and never did manage to work my way around to testing the
BT> resulting code enoug
16 matches
Mail list logo
