On Fri, Aug 18, 2000 at 07:20:28AM +0100, Graham Barr wrote:
> So it is a security issue then as it needs somewhere to cache these
> object files, and anyone must be able to do it.
No more insecure than having your own LIB directory, although the prospect of
every user having their own copy of ev
On Thu, Aug 17, 2000 at 05:26:18PM -0400, Sam Tregar wrote:
> On Thu, 17 Aug 2000, Nick Ing-Simmons wrote:
> > Simon Cozens <[EMAIL PROTECTED]> writes:
> > >Wow. I'm sold. Can this be how we should be doing XS in Perl 6?
> > So we now run equivalent of xsubpp and cc every time script is run?
>
>
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 "foo") given that C, beastly as it i
We mostly can. This is really an echo of the "read-only, not constant"
idea from a while back. This way you can take references to them, for
instance. The compiler doesn't know where they will go.
Overloading the assign-to-me operator is faster than having a flag, you
never have to check it.
Think about deadlock, extra overhead, and time taken to take the lock.
If a set of variables should be locked as a unit only one mutex should
be assigned.
What to do about overlapping members
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> I wrote a transaction-enabled data
512 byte pages, stored on a permanent device and paged
in as required, for everything
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Does despair.com sell a discordian calendar?
I wrote a transaction-enabled database in perl 5, using fork()
for my multithreading and flock() for my mutexes. It continues
to work just fine.
Threading gives us mutexes. Are you just saying that
every variable should have its own mutex, and perl's = assignment
operator should implicitly se
On Thu, Aug 17, 2000 at 08:20:35PM +, Nick Ing-Simmons wrote:
> Simon Cozens <[EMAIL PROTECTED]> writes:
> >>BEGIN {$c_code = &c_code_generator()}
> >>use Inline C => $c_code; # will die if code doesn't compile
> >>myfunc1();
> >>
> >>greet('Ingy');
> >>
> internally, how to do it:
>
> ASSIGNMENT, as in, Change-my-values-w/o-changing-my-type,
> is in the vtable for the object.
>
> When an object becomes constant, its ASSIGNMENT function gets
> replaced with
>
> $heres_what_it_gets_replaced_with=sub{
> throw "ERROR-ASSIGNMENT-TO-CONSTANT"
> };
>
>
internally, how to do it:
ASSIGNMENT, as in, Change-my-values-w/o-changing-my-type,
is in the vtable for the object.
When an object becomes constant, its ASSIGNMENT function gets
replaced with
$heres_what_it_gets_replaced_with=sub{
throw "ERROR-ASSIGNMENT-TO-CONSTANT
Nice thought.
Actually, this or something like this might be helpful in maintainting
invariants in the face of exceptions.
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 commi
> We need to get a new keyword for defining such a variable, I think
> "transaction" is too long, we could use "safe" for this reason.
The proposal looks good. But isn't this more a language issue at this
point? Seems like we'll have to figure out the behavior we want first.
Also, "safe" i
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Transaction-enabled variables for Perl6
=head1 VERSION
Maintainer: Szabó, Balázs <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 130
=head1 ABSTRACT
Tran
Simon Cozens wrote:
> I'm trying to find out some useful information on the Microsoft .NET
> Implementation Language, since everyone's raving about it and all I've
> seen is vapourware, glowing press releases and not a drop of code, and
> I'd rather see something a little more technical if it's wh
> As for single datum access, I C[index]> or
> C{key}> should be considered. This however, is not the
> core of this proposal. Merely a possibility. Just as extending the
> inelegant metaphor above to C<{function()}->{key}> would become a
> possibility.
Personally, I think lists should always sta
On Thu, 17 Aug 2000, Nick Ing-Simmons wrote:
> Simon Cozens <[EMAIL PROTECTED]> writes:
> >Wow. I'm sold. Can this be how we should be doing XS in Perl 6?
> So we now run equivalent of xsubpp and cc every time script is run?
No. The documentation states that the compilation is done only when the
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Sane resolution to large function returns
=head1 VERSION
Maintainer: Jerrad Pierce <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 127
=head1 ABSTRACT
Pe
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Components in the Perl Core Should Have Well-Defined APIs and Behavior
=head1 VERSION
Maintainer: Bradley M. Kuhn <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
linkable output mode
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 121
=head1 ABSTRACT
Perl5 offers a clunky in
Michael G Schwern <[EMAIL PROTECTED]> writes:
>
>I wouldn't mind an optional OO contract system in the core of Perl,
>but this may be a case of "why do it in core when a module will work?"
I _think_ the proposal was to have design-by-contract in the perl core
in the sense that contract is checked
On Thu, Aug 17, 2000 at 08:20:35PM +, Nick Ing-Simmons wrote:
> Simon Cozens <[EMAIL PROTECTED]> writes:
> >>BEGIN {$c_code = &c_code_generator()}
> >>use Inline C => $c_code; # will die if code doesn't compile
> >>myfunc1();
> >>
> >>greet('Ingy');
> >>
Simon Cozens <[EMAIL PROTECTED]> writes:
>>BEGIN {$c_code = &c_code_generator()}
>>use Inline C => $c_code; # will die if code doesn't compile
>>myfunc1();
>>
>>greet('Ingy');
>>greet(42);
>>
>>use Inline C => <<'END_OF_C_CODE';
>>
>>void gr
Michael wrote:
> I wouldn't mind an optional OO contract system in the core of Perl,
> but this may be a case of "why do it in core when a module will work?"
> Since OO contracts are typically turned off in production code any
> performance gains from adding it to the core wouldn't ma
On Thu, Aug 17, 2000 at 01:28:29PM -0400, Chaim Frenkel wrote:
> I posted this to -qa and -internal, since I was suggesting this
> for the internal development of perl. Not for the user visible
> pieces.
My mistake. For the internals, sounds like it couldn't hurt. Though
I have no idea how put
I posted this to -qa and -internal, since I was suggesting this
for the internal development of perl. Not for the user visible
pieces.
If we will be going through an intermediate language, then that
language should/could/will/might support such specifications.
Then under appropriate prodding will
At 01:10 PM 8/17/00 +, Simon Cozens wrote:
>In comp.lang.perl.announce, Brian Ingerson wrote:
> >Inline.pm allows a programmer to write C code directly inside a Perl
> >script and just run it. No XS, no SWIG, no make. Using Inline to write
> >extension modules for the CPAN is fully supported a
In comp.lang.perl.announce, Brian Ingerson wrote:
>Inline.pm allows a programmer to write C code directly inside a Perl
>script and just run it. No XS, no SWIG, no make. Using Inline to write
>extension modules for the CPAN is fully supported and just as easy. C++,
>Fortran, Pascal, and Python are
On Thu, Aug 17, 2000 at 07:03:13AM -0400, Michael G Schwern wrote:
> I wouldn't mind an optional OO contract system in the core of Perl,
> but this may be a case of "why do it in core when a module will work?"
Isn't this rather a language issue?
> Since OO contracts are typically turned off in
On Sun, Aug 13, 2000 at 07:16:41PM -0400, Chaim Frenkel wrote:
> What do you think of creating a mechanism for attaching pre-, post-,
> invariant conditions to the internals?
I'd like to point out that two modules already do this.
Class::Contract which was just unleashed by Damian Conway, and
inv
Simon Cozens wrote:
> I'm trying to find out some useful information on the Microsoft .NET
> Implementation Language, since everyone's raving about it and all I've
> seen is vapourware, glowing press releases and not a drop of code, and
> I'd rather see something a little more technical if it's wh
Ariel Scolnicov wrote:
> Nathan Torkington <[EMAIL PROTECTED]> writes:
> > $a and $b were done for speed: quicker to set up those global
> > variables than to pass values through the stack. The documentation
> > for perl5's sort function says that passing as arguments is
> > considerably slower
I'm trying to find out some useful information on the Microsoft .NET
Implementation Language, since everyone's raving about it and all I've
seen is vapourware, glowing press releases and not a drop of code, and
I'd rather see something a little more technical if it's what we're
going to be targett
32 matches
Mail list logo
