On Fri, 18 Aug 2000, Graham Barr wrote:
> > No. The documentation states that the compilation is done only when the
> > source file is out of date with the companion object file. As I
> > understand it, Inline has some kind of limited automatic make ability.
>
> So it is a security issue then a
Jarkko Hietaniemi wrote:
> De ja vu. Are you familiar with Cons?
>
> http://search.cpan.org/doc/KNIGHT/cons-2.1.1/README
>
Interesting. I was not familiar with this package. I just needed a good
way to know whether a snippet of source code had been changed. Since the
snippet is probably just
On Fri, 18 Aug 2000, Simon Cozens <[EMAIL PROTECTED]> wrote:
> RFC 131
{snipped}
Having pondered this (unsuccesfully) for a couple weeks, I will
certainly concede that this is the simplest way of handling this
problem.
A couple counter-points.
1. I believe your extrapolation from 'one strin
I don't think you should even attempt to version/transaction protect
a tied variable. Anything that leaves the memory or could leave the
memory (e.g. socket write) should probably not be versioned.
Unless the tied variable somehow is able to tie itself into the
transaction manager. It is up for
Perl6 RFC Librarian writes:
> There has been a proposed new core function C. this seems
> to be generally regarded as a good thing. Fine. If it is implemented
> we should use it. Offending functions (See RFC 37) should use
> C internally to determine what to return i.e; a list or a hash.
This imp
Simon Cozens writes:
: On Fri, Aug 18, 2000 at 09:57:59AM -0700, Larry Wall wrote:
: > Because we don't lose much efficiency to polymorphism, since we need it
: > anyway to support generic scalars, and we gain some efficiency whenever
: > we procrastinate conversions out of existence.
:
: Surely
On Fri, Aug 18, 2000 at 09:57:59AM -0700, Larry Wall wrote:
> Because we don't lose much efficiency to polymorphism, since we need it
> anyway to support generic scalars, and we gain some efficiency whenever
> we procrastinate conversions out of existence.
Surely we do, because we have to add in
Oops,
In my haste to upload version 0.23 (which supports MSWin32) I introduced
a bug which will cause "make test" to fail *only* if the user is
installing Inline.pm for the first time. Of course, everyone (except me)
caught this right away.
So I hastlily uploaded v0.24 :-) Please use that one i
[EMAIL PROTECTED] writes:
: A single internal encoding which is opaque to the programmer Would Be Nice.
We seem to be asking for contradictory things here. If it's truly
opaque, the programmer shouldn't care whether it's polymorphic or
monomorphic. I'm inclined to think the polymorphic solution
On Fri, Aug 18, 2000 at 10:22:13AM -0500, Jarkko Hietaniemi wrote:
> Danger! Only the implementer(s) of this pluggable data storage and
> its interface should care about details like "an array of wchars".
> All other people, even other core people, should use just the
> interface, not do things l
> That's the thing. It doesn't matter. It B matter. Keep it
> pluggable; you could have everything in Latin1, in UTF8, in UTF16, or
> who knows what, but the core developer shouldn't have to care. One good
> way to achieve this is to have the string presented in the variable as
> an array of wchar
> Internal String Storage to be Opaque
> Number: 131
> =item Why a single internal encoding?
FWIW, I would like to throw my support behind this proposal.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Internal String Storage to be Opaque
=head1 VERSION
Maintainer: Simon Cozens <[EMAIL PROTECTED]>
Date: Aug 18 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Numb
On Thu, Aug 17, 2000 at 07:01:59PM -0700, Brian Ingerson wrote:
> Hi all,
>
> This is Brian Ingerson (the Inline.pm author). My coworker, Colin Meyer,
> tipped me off to this thread. I thought I'd throw in a few tidbits to
> make sure everyone's on track. But first of all, make sure to RTFM.
> (B
Hi all,
This is Brian Ingerson (the Inline.pm author). My coworker, Colin Meyer,
tipped me off to this thread. I thought I'd throw in a few tidbits to
make sure everyone's on track. But first of all, make sure to RTFM.
(Because I put a lot of effort in explaining it there) The latest copy
is:
ht
/--- On Thu, Aug 17, 2000 at 06:17:51PM -0400, Chaim Frenkel wrote:
| Though this is a tough problem especially in the face of threads.
| Though versioned variables may be able to remove most of the
| locking
| issues and move it down into the commit phase.
Yes, but you can give strange
On Fri, Aug 18, 2000 at 09:02:21AM +0100, Hildo Biersma wrote:
> > sv->vtable->svpvx;
> >
> > Isn't this going to really, really hurt?
>
> Doing three C pointer lookups is going to be less expensive than
> invoking a subroutine
But you're doing that as well. vtables store function pointers.
Simon Cozens wrote:
>
> I'm obviously missing something about vtables. It'll be obvious when someone
> corrects me, but...
>
> Currently, SvPVX(foo) requires one lookup; with a vtable, it would necessitate
> two, (One to find the functino in "foo", and then the functino must find the
> data in "
No, because each table lookup takes less time than comparing one
letter of a text string.
> sv->vtable->svpvx;
>
> Isn't this going to really, really hurt?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Does despair.com sell a discordia
19 matches
Mail list logo
