Kv Org [mailto:[EMAIL PROTECTED]] wrote
> I believe Perl6 needs a facility to run
> "compartmented" code (object-oriented and
> module-loading) that is tagged as to its permissions
> and "owner" ID. The goal would be to let such code use
> harmful actions only by calling permitteed outside
> funct
> First and foremost, is there any compelling reason, to have totally
> different structures for PMCs and Buffers?
> - Both have a ->data aka ->bufstart
> - Both have ->flags, that have vastly the same meaning.
As jason said in another message, Dan has changed his mind from
yesteryear, and decide
Disclaimer: I am very out of touch with what's actually going on on
perl6-internals at the moment. (And even more out of touch with the source
code)
On Tue, Sep 24, 2002 at 04:56:25AM +, Leopold Toetsch wrote:
> +return list->chunk_list[idx / INTLIST_CHUNK_SIZE];
On Tue, Sep 24, 2002 at
I have always longed for a more flexible security
system that could limit what a part of code could do
in Perl.
In perl5 Safe.pm (and Safe::Hole) have serious
limitations and problems since it is difficult to have
the security-limited code (that executes in a safe
compartment) have use packages
Many of you know that we put together a pair of parrot t-shirts to
auction off at YAPC::EU as part of the auction fundraiser for YAPC
and YAS. (Proceeds of the auction went to cover some shortfalls in
the conference budget, with the extra going to YAS for future con
stuff and perl foundation g
On Fri, Sep 27, 2002 at 09:28:41AM +0200, Leopold Toetsch wrote:
> First and foremost, is there any compelling reason, to have totally
> different structures for PMCs and Buffers?
The reasons stopped being compelling about a month or two ago, when it was
decided to unify the two. No one has had
At 4:44 PM +0200 9/27/02, Leopold Toetsch wrote:
>Tom Hughes wrote:
>
>>In message <[EMAIL PROTECTED]>
>> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
>
>>I applied this to my checkout (with _intlist_new renamed to
>>allocate_chunk because names starting with _ are reserved).
>
>
>Ah, didn
At 12:40 PM -0700 9/26/02, Sean O'Rourke wrote:
>On Thu, 26 Sep 2002, Paul Johnson wrote:
>> Is that sufficiently vague?
>
>Not vague enough, because the current implementation manages to miss the
>broad side of that semantic barn...
The intention is to allow aggregates to have different default
--
On Thu, 26 Sep 2002 14:06:50
John Williams wrote:
>We should respect default values if arrays can declare them.
>
>Perhaps there will be a modifier for operator declarations to declare what
>the default behavior should be. Otherwise I don't know how different
>behaviors for different
On Thu, 26 Sep 2002, Luke Palmer wrote:
> Before people get I far on the regex engine, is there any plan to
> implement split buffers; i.e. storing one string in multiple places and
> tying them together? Has this already been done?
I don't understand how this would affect the regex engine -- w
In message [EMAIL PROTECTED]>
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Tom Hughes wrote:
>
> > Unfortunately it doesn't test clean afterwards:
> > dunsmere [~/src/parrot] % perl t/harness t/pmc/intlist.t
>
> > t/pmc/intlistNOK 3# Failed test (t/pmc/intlist.t at line 149) #
> > g
Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> I applied this to my checkout (with _intlist_new renamed to
> allocate_chunk because names starting with _ are reserved).
Ah, didn't know that - ok changed too.
> Unfortunately it doesn
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #17624]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17624 >
14! is actually 87178291200. The value used in the test assumes 32-bit
integer wrapa
In message <[EMAIL PROTECTED]>
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> This patch contains:
> - removal of the initial parameter from intlist_new - no need for it in
> the public interface (thanks Tom)
> - junk_list is now a Buffer, which gets collected
> - some macros to hide this
Before people get I far on the regex engine, is there any plan to
implement split buffers; i.e. storing one string in multiple places and
tying them together? Has this already been done?
I think it would be a good idea, as it would make many common operations
faster on large data sets. Say,
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17621]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17621 >
This patch contains:
- removal of the initial parameter from intlist_new - no need f
On Thu 26 Sep 2002 20:53, Andy Dougherty <[EMAIL PROTECTED]> wrote:
> On Thu, 26 Sep 2002, Dan Sugalski wrote:
>
> > At 5:05 PM +0200 9/26/02, H.Merijn Brand wrote:
> > >
> > >perl t/harness
> > >t/builtins/array.Can't bless non-reference value at
> > >../../assemble.pl line 163.
> >
> > Hr
Steve Fink wrote:
> To expand on that: the currently commented-out dependency on
> Configure.pl in the makefile is wrong. It says the $(STICKY_FILES)
> depend only on the Configure.pl script itself, which is woefully
> incomplete:
There are a lot more dependencies, that are uncovered:
classe
H.Merijn Brand (via RT) wrote:
>>Attached patch fixed the "make --test" problem, reported by Tanton et al.
> no dashes I may hope?
Argh, yes of course, lack of coffee early in the morning ...
> # make test
>
> should be the same as
>
> # perl6 --test
>
> If I followed the discussion corre
I have some questions and suggestions regarding PMCs, Buffers and memory
management/internal data structures.
First and foremost, is there any compelling reason, to have totally
different structures for PMCs and Buffers?
- Both have a ->data aka ->bufstart
- Both have ->flags, that have vastly th
In message <[EMAIL PROTECTED]>
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Attached patch fixed the "make --test" problem, reported by Tanton et al.
> Actually it was my fault, I forgot about the changed semantics of
> running imcc and the usage in TestCompiler.pm
Looks good to me, and
21 matches
Mail list logo
