> Leave parsing and formatting entirely to libraries. Absolutely no need
> for that in the instruction set.
well, I have a bit of a problem with that... As it was pointed out
before, people have gone hogwild with the parsing and formatting
routines, and its a bloodbath of modules on CPAN with diff
(
ps - on a side note, is the news gateway through google working in posting
to the list? I tried posting via google, and although it shows up on
google, it didn't show up in the archives...
)
On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote:
> Edward S. Peschko wrote:
>
> > Gordon Henriksen wrote:
> >
> > > Leave parsing and formatting entirely to libraries.
> > > Absolutely no need for that in the instruction set.
> >
>
> I don't think optimising for "X" is the reason. Parrot should have
> concise, necessary, complete opcode primitives upon which anything
> else can be built.
how about opcode formatting primitives? That is what I would argue
strftime and relatives are... generic low-level ways of turning strings
On Tue, Mar 09, 2004 at 09:53:47PM -0500, Gordon Henriksen wrote:
> Edward,
>
> Want to call strptime? Use NCI. No need for anything new in the core.
> That's WHY it's the CORE.
I think there is a misunderstanding here. I don't think that strftime by itself
in the core - which probably has sys
> On a platform with a halfway decent JIT, a pure-PASM implementation
> could be as fast as an op-based one, given liberal use of the non-PMC
> registers. Maybe faster--no need to transcode to ASCII, extract a C
> string, or hack around platform X's quirks. And I'd imagine that the
> Parrot s
> Sometimes, if the customer wants to do an audit, we have to process
> over a month's worth, so we are bound by the actual execution
> time of the Perl script and the access time of a Sleepycat (Berkeley DB)
> database. The Perl programs must be able to scale
> with call/message volume, and right
