Re: Funky «vector» operator
On Mar 22, 2004, at 10:36 PM, David Wheeler wrote: I'll wait and see what I hear back from the Emacs developers. In the meantime, there's TextEdit. I've heard back that it may be that Unicode support simply isn't included in the Carbonized version of Mac OS X. They plan to look into it. Regards, David
Re: GCC for PARROT (GCC Compiling itself to PARROT, then compilin g all supported languages to PARROT from PARROT)?!?!
Matt Fowles <[EMAIL PROTECTED]> writes: | All~ | | If I recall correctly, GCC supports Haskell, which is an ideal | language for Parrot. That might probably be the case, but we don't have it in the FSF release and I don't recall we have any mention of Haskell in the section of various front-ends for GCC we know about. I do know, however, that we have some support for Mercury (that is not directly contained in FSF GCC but, occasionally we have patches that arranges things for it). http://www.cs.mu.oz.au/research/mercury/download/gcc-backend.html -- Gaby
[PATCH] single item stack chunks
I've stripped down the whole stack code to use one item per chunk. It
passes all tests (3 disabled that push infintely and check for
CHECK_LIMIT and t/pmc/eval_6 which is borken).
This slows down register saving (and other stack operations)
considerably whithout any additional measures[1]:
$ perl tools/dev/parrotbench.pl -c=parrotbench.conf -b='^oof' -t
Numbers are cpu times in seconds. (lower is better)
p-j-Oc parr-j parr-C perl-th perlpython ruby
oofib 4.150s 11.530s 12.450s 4.100s 3.540s 2.140s 2.170s
p-j-Oc = parrot -j -Oc where savetop is optimized to pushtopp
parr-j = parrot -j, all 4 registers are saved (both unoptimized build)
[1] The old stack code used a next pointer to prevent stack thrashing.
This is of not much use for single items (and probably doesn't work with
Continuations), so I'm thinking of dedicated free_lists (again!) that
hold popped of stack items of one buffer size kind. They'll be kept
alive by marking them during DOD. If we cannot do this, I see not much
chance to gain old subroutine call performance.
Here is the diffstat of the patch:
classes/closure.pmc |3
classes/coroutine.pmc |2
imcc/pcc.c |8 +-
include/parrot/stacks.h | 13 ---
src/debug.c | 16 +---
src/register.c | 46 +---
src/stack_common.c | 142 --
src/stacks.c| 57 ++-
src/sub.c | 18 +---
t/op/stacks.t |4 -
t/pmc/eval.t|4 +
11 files changed, 86 insertions(+), 227 deletions(-)
TODOS: cleanup, POD, debug.c stack commands.
leo
--- parrot/classes/closure.pmc Sun Feb 22 19:54:30 2004
+++ parrot-leo/classes/closure.pmc Tue Mar 23 10:21:04 2004
@@ -89,8 +89,7 @@
struct Parrot_Sub * sub;
PMC* ret = SUPER();
sub = PMC_sub(ret);
-sub->ctx.pad_stack = stack_copy(interpreter,
-PMC_sub(SELF)->ctx.pad_stack);
+sub->ctx.pad_stack = PMC_sub(SELF)->ctx.pad_stack;
return ret;
}
--- parrot/classes/coroutine.pmcSun Feb 22 19:54:30 2004
+++ parrot-leo/classes/coroutine.pmcTue Mar 23 12:08:35 2004
@@ -73,7 +73,7 @@
void mark () {
struct Parrot_Coroutine *c = (struct Parrot_Coroutine *)PMC_sub(SELF);
mark_stack(INTERP, c->co_control_stack);
-mark_stack(INTERP, c->co_pad_stack);
+/* mark_stack(INTERP, c->co_pad_stack); */
SUPER();/* mark rest */
}
}
--- parrot/imcc/pcc.c Mon Mar 22 17:43:49 2004
+++ parrot-leo/imcc/pcc.c Tue Mar 23 12:01:06 2004
@@ -935,16 +935,16 @@
ins = set_I_const(interp, unit, ins, 4, 0);
#endif
/*
+ * emit a savetop for now
+ */
+ins = insINS(interp, unit, ins, "savetop", regs, 0);
+/*
* if we reuse the continuation, update it
*/
if (!sub->pcc_sub->nci)
if (!need_cc)
ins = insINS(interp, unit, ins, "updatecc", regs, 0);
-/*
- * emit a savetop for now
- */
/* restore self */
-ins = insINS(interp, unit, ins, "savetop", regs, 0);
if (meth_call) {
regs[0] = s0;
n = 0;
--- parrot/include/parrot/stacks.h Sat Feb 21 19:10:24 2004
+++ parrot-leo/include/parrot/stacks.h Tue Mar 23 10:22:28 2004
@@ -15,8 +15,7 @@
#include "parrot/parrot.h"
-#define STACK_CHUNK_DEPTH 256
-#define STACK_CHUNK_LIMIT 1000
+#define STACK_CHUNK_LIMIT 10
typedef struct Stack_Entry {
UnionVal entry;
@@ -26,13 +25,7 @@
typedef struct Stack_Chunk {
pobj_t obj;
-size_t used;
-int n_chunks;
-int chunk_limit;
-size_t item_size;
-size_t items_per_chunk;
const char * name;
-struct Stack_Chunk *next;
struct Stack_Chunk *prev;
} Stack_Chunk_t;
@@ -47,9 +40,7 @@
/*
* stack_common functions
*/
-Stack_Chunk_t * cst_new_stack(Parrot_Interp, const char *name, size_t, size_t);
-Stack_Chunk_t * stack_copy(Parrot_Interp, Stack_Chunk_t *stack);
-void stack_unmake_COW(Parrot_Interp, Stack_Chunk_t *stack);
+Stack_Chunk_t * cst_new_stack(Parrot_Interp, const char *name, size_t);
void* stack_prepare_push(Parrot_Interp, Stack_Chunk_t **stack_p);
void* stack_prepare_pop(Parrot_Interp, Stack_Chunk_t **stack_p);
--- parrot/src/debug.c Sat Mar 13 09:44:44 2004
+++ parrot-leo/src/debug.c Tue Mar 23 10:12:40 2004
@@ -2147,9 +2147,7 @@
unsigned long depth = 0, i = 0;
Stack_Chunk_t *chunk = interpreter->ctx.int_reg_stack;
-valid_chunk(chunk, command, depth,
-FRAMES_PER_INT_REG_CHUNK, i);
-
+internal_exception(1, "TODO");
if (!chunk) {
i = depth / FRAMES_PER_INT_REG_CHUNK;
PIO_eprintf(interpreter, "There are only %li frames\n",i);
@@ -2182,9 +2180,7 @@
unsigned long depth = 0, i = 0;
Stack_Chunk_t *chunk = interpreter->ctx.num_reg_stack;
-valid_chunk(chunk, command, depth,
-FRAMES_PER_NUM_REG_CHUNK, i);
-
+internal_exception(1, "TODO
RE: Safe execution core and ops classification
> - do we expect to have more then 32 different classes? > i see 13 operator classes currently > A perl script that scans ops-files for opcode classes and spits out: > > a) a pod with opcode classes headings and the list of opcodes that > belong to that class (at best created from a template, which has some > more explanation to that stuff) > the attached tarfile contains a script (tools/docs/opslist.pl) should generate a file, docs/ops/opslist.pod, with the above information > b) a C include file that defines bitmask enums for the > classes plus some > common shortcuts comming from a config file. These enums > should then be > scanned during Configure and provide a user visible PASM in > runtime/parrot/include. > If we have more then 32 classes, we'll use a ParrotSet PMC > (which will > be handy anyway) > i'm not sure where to get the info i need to do this. hope the attached script helps. > leo > --jerry ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. The file opslist.tar was removed from this message.
[PATCH] RE: Safe execution core and ops classification
> - do we expect to have more then 32 different classes? > i see 13 operator classes currently, though my tree may be out of date > A perl script that scans ops-files for opcode classes and spits out: > > a) a pod with opcode classes headings and the list of opcodes that > belong to that class (at best created from a template, which has some > more explanation to that stuff) > the attached tarfile contains a script (tools/docs/opslist.pl) should generate a file, docs/ops/opslist.pod, with the above information > b) a C include file that defines bitmask enums for the > classes plus some > common shortcuts comming from a config file. These enums > should then be > scanned during Configure and provide a user visible PASM in > runtime/parrot/include. > If we have more then 32 classes, we'll use a ParrotSet PMC > (which will > be handy anyway) > i'm not sure where to get the info i need to do this. hope the attached script helps. > leo > --jerry ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. opsfile.tgz Description: Binary data
Re: opsfile.tgz
Hi, On Tuesday 23 March 2004 14:49, Gay, Jerry wrote: > > - do we expect to have more then 32 different classes? > > i see 13 operator classes currently, though my tree may be out of date I think we should limit the number of unique IDs available at runtime to 32. We can assign the same number to several symbolic names (maybe even on demand, at runtime). This way, one can at least query if a specific feature is enabled. We then have "meta groups", for example a single "math" group instead of base_math and advanced_math; I think it is harmless if enabling one feature does also enable another (related) feature. A fine graded OP classification can be a win, but it is not necessary to be able to play around with 10 different hints _at runtime_. If hints can be freely grouped (at compiletime), everyone should be able to get a parrot that fulfils even very specific needs. Hints should IMO only be used to control parrot's core OPs. Extensions (i.e. special RE ops) can be controlled by restrictions at loadtime. > > A perl script that scans ops-files for opcode classes and spits out: > > > > a) a pod with opcode classes headings and the list of opcodes that > > belong to that class (at best created from a template, which has some > > more explanation to that stuff) > > the attached tarfile contains a script (tools/docs/opslist.pl) should > generate a file, docs/ops/opslist.pod, with the above information I belive Leo meant the hint classes, base_core and base_network for example. > > b) a C include file that defines bitmask enums for the > > classes plus some > > common shortcuts comming from a config file. These enums > > should then be > > scanned during Configure and provide a user visible PASM in > > runtime/parrot/include. > > If we have more then 32 classes, we'll use a ParrotSet PMC > > (which will > > be handy anyway) > > i'm not sure where to get the info i need to do this. lib/Parrot/OpLib/core.pm > hope the attached script helps. The list looks okay, maybe it can be kept as an additional section. Another section should show all hint groups and the OPs that belong to this list. A simple list is included in my previous mail from yesterday. > > leo > > --jerry jens
Re: Classes and metaclasses
At 6:17 PM -0800 3/22/04, chromatic wrote:
On Tue, 2004-03-16 at 11:57, Dan Sugalski wrote:
(I forgot to reply to this last week)
At 11:51 AM -0800 3/16/04, chromatic wrote:
>Just to be sure, if Class Y inherits from Class X, is X on Y's does
>list?
If class X does X, then yes. (I *really* should've picked better
names) Classes don't by default do themselves, so if you had a
top-level class Foo that didn't mark itself as doing anything, an
object of class Foo would return true for an isa('Foo') check but
false for a does('Foo') check.
Classes and roles don't automatically share the same namespace.
This means that the Perl 6 compiler will have to set does() on all
classes or class-manipulations. As you suggest, we're not mixing up
implementation (how does he do it?) with promise (he says he'll do it)
-- signature type checking has to respect roles, not inheritance.
This is... odd. And it'll cause interesting problems with
inter-language inheritance, since the perl 6 compiler will be the
only thing doing this, and I think generally all the other languages
(including perl 5) will be doing type checking based on the
inheritance hierarchy rather than the interfaces, but...
(Followups on why this must be -> p6l.)
Don't care, really. :)
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Continuations, stacks, and whatnots
At 8:46 AM +0100 3/23/04, Leopold Toetsch wrote: Piers Cawley <[EMAIL PROTECTED]> wrote: Dan Sugalski <[EMAIL PROTECTED]> writes: And what control stack? The continuation chain is the control stack, surely? Nope. There's the exception handlers, at the very least. Just add a field to the continuation structure "NextExceptionHandler" which points to the continuation of the next exception handler in the chain. What about C code that either installs exception handlers or throws exceptions? Or multiple nested exception handlers, or serial exception handlers in a block... And then there's the fun with exception handlers and coroutines. It's a stack, like it or not. >> Possibly some lexical pad stuff. (Though of that I'm less sure) I've always wondered why lexical pads have their own stack. I'd hang it off the Sub object and, when the sub's invoked, shove the current pad into a control register, which then gets closed over by any continuations that get made. Invoking a continuation restores the pad register and away you go. Interesting idea. Well, the control register is a pointer in the context structure. We should be careful not to use up too many PMC registers. But the current lexical pad structures are suboptimal (searching is O(n)). OTOH we need some kind of linked lists of pads, which matches the single item stacks approach. Just because the current version's implementation is broken doesn't make the concept wrong. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] single item stack chunks
At 12:34 PM +0100 3/23/04, Leopold Toetsch wrote:
I've stripped down the whole stack code to use one item per chunk.
It passes all tests (3 disabled that push infintely and check for
CHECK_LIMIT and t/pmc/eval_6 which is borken).
From reading this patch, either something's horribly wrong here or
the stack code's mutated beyond all recognition since the last time I
looked. For this to be reasonable we need:
1) A stack chunk freelist, akin to the PMC and buffer freelists
2) The stack entry has to look something like:
struct {
struct IntStackFrame *prev;
INTVAL Registers[REGSPERFRAME];
} IntStackFrame;
It could be a union of INTVAL, NUMVAL, STRING *, and PMC * if we
don't want to maintain several free lists. Throwing a flag word in
there's probably not out of order either.
The indirection through the Buffer stuff has to go (the two
indirections are a waste, and we certainly don't need this stuff
shifted around by the GC) and skipping the allocation of the memory
for the frame is needed. (Parrot_allocate really ought not ever be
called for these fixed-sized structures, it's a huge waste)
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: opsfile.tgz
At 3:43 PM +0100 3/23/04, Jens Rieks wrote: On Tuesday 23 March 2004 14:49, Gay, Jerry wrote: > - do we expect to have more then 32 different classes? i see 13 operator classes currently, though my tree may be out of date I think we should limit the number of unique IDs available at runtime to 32. We ought to limit it to 0, actually. :) These classifications are all compile-time things as they affect the code the preprocessor emits. I don't think there's much use for the meta-information to be there at runtime and I certainly don't think it should be *used* at runtime... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] single item stack chunks
Dan Sugalski wrote:
looked. For this to be reasonable we need:
1) A stack chunk freelist, akin to the PMC and buffer freelists
Well, that did I write in my message. Please read it (again). And please
one thing and then the next.
2) The stack entry has to look something like:
struct {
struct IntStackFrame *prev;
INTVAL Registers[REGSPERFRAME];
} IntStackFrame;
It could be a union of INTVAL, NUMVAL, STRING *, and PMC * if we don't
want to maintain several free lists. Throwing a flag word in there's
probably not out of order either.
This fixed size item doesn't really work IMHO. NUMVAL frames are of
different size, as are user-stack entries.
The indirection through the Buffer stuff has to go
Well in your last mail WRT that stuff you had PMCs there :) The Buffer
stuff doesn't really hurt, when the chunks are coming directly from the
free lists.
.. (Parrot_allocate really ought not ever be called for these
fixed-sized structures, it's a huge waste)
They aren't fixed size--or only per stack kind, but with have more then one.
leo
Re: [PATCH] single item stack chunks
At 5:38 PM +0100 3/23/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
looked. For this to be reasonable we need:
1) A stack chunk freelist, akin to the PMC and buffer freelists
Well, that did I write in my message. Please read it (again).
I did. The need for a freelist, however, has been there since the
beginning. This isn't a new need--it was in my mail about this that
started this round.
A freelist is a given here.
2) The stack entry has to look something like:
struct {
struct IntStackFrame *prev;
INTVAL Registers[REGSPERFRAME];
} IntStackFrame;
It could be a union of INTVAL, NUMVAL, STRING *, and PMC * if we
don't want to maintain several free lists. Throwing a flag word in
there's probably not out of order either.
This fixed size item doesn't really work IMHO. NUMVAL frames are of
different size, as are user-stack entries.
User stack entries are different from backing stack frames. They need
to be treated differently, and as such aren't under consideration
here. I see that someone unified this all ages back--that was a
mistake.
The indirection through the Buffer stuff has to go
Well in your last mail WRT that stuff you had PMCs there :)
Yeah, with no indirection. To be clear, I was proposing:
struct IntFramePMC {
pobj_t obj;
VTABLE *vtable;
struct PMC_EXT *pmc_ext;
DPOINTER *data;
PMC *_metadata;
struct _Sync *_synchronize;
PMC *_next_for_GC;
INTVAL Registers[REGISTERS_PER_FRAME];
};
for an integer register frame, with pmc_ext set to &data, and data
set to &Registers[0], and all the internal code skipping all the damn
indirection and going directly to the register store frm the pointer
to the frame.
For those folks following along that aren't familiar with what's
here, this is equivalent to:
struct IntFramePMC {
struct PMC;
struct PMC_EXT;
INTVAL Registers[REGISTERS_PER_FRAME];
}
which would be an OK way of doing it as well.
The Buffer stuff doesn't really hurt, when the chunks are coming
directly from the free lists.
Yeah, it does. Besides the extra indirection, memory allocated with
Parrot_allocate's movable by the GC. For fixed sized structures this
is a waste, since there's no real reason to bother with compacting
fixed-sized structures. Arenas with freelists work better there.
.. (Parrot_allocate really ought not ever be called for these
fixed-sized structures, it's a huge waste)
They aren't fixed size--or only per stack kind, but with have more then one.
They're of fixed size. That there are multiple types doesn't change
that. Every integer register frame will be the exact same size as
every other one--they don't vary.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: opsfile.tgz
On Tuesday 23 March 2004 17:11, Dan Sugalski wrote: > At 3:43 PM +0100 3/23/04, Jens Rieks wrote: > >On Tuesday 23 March 2004 14:49, Gay, Jerry wrote: > >> > - do we expect to have more then 32 different classes? > >> > >> i see 13 operator classes currently, though my tree may be out of date > > > >I think we should limit the number of unique IDs available at runtime to > > 32. > > We ought to limit it to 0, actually. :) These classifications are all > compile-time things as they affect the code the preprocessor emits. I > don't think there's much use for the meta-information to be there at > runtime and I certainly don't think it should be *used* at runtime... After thinking a bit more about it, it seems undesireable to do hint group modifications at runtime. They should be declared at compiletime, and I think they can be very useful to maintain system security when running untrusted code. It can be implemented as per-interpreter (or eventually runloop?) hints, to be able to disallow things like creating new/altering existing classes, loading of bytecode, disabling IO OPs and such things. A "query_hint" OP can be used to check at runtime if file access or network usage is permitted, for example. For security reasons, it should only be possible to test whether a feature is available, and to disable features. Either completely (until the interpreter exists) or for the current scope (handled like warnings?). It can be implemented as an (32bit) integer in the interpreter structure. Only a bit test against a predefined mask is needed to check if an instruction is allowed in a given context. "if( interpreter->hints & Parrot_hint_base_io )" The code for it can be spread out automatically for OPs belonging to a specific hints group. It is not necessary for base_core OPs, since it makes no sense to disable them. Other OPs (i.e. open) are doing rather complex things, a single bit test is not going to slow them down very much. Maybe its even enough to implement it for the slow/secure core. I belive that this will help to maintain the system's security when running untrusted code. jens
Re: opsfile.tgz
Dan Sugalski <[EMAIL PROTECTED]> wrote: >>I think we should limit the number of unique IDs available at runtime to 32. > We ought to limit it to 0, actually. :) These classifications are all > compile-time things as they affect the code the preprocessor emits. And how do you handle PBCs then? leo
Re: [PATCH] single item stack chunks
Dan Sugalski <[EMAIL PROTECTED]> wrote: > User stack entries are different from backing stack frames. They need > to be treated differently, and as such aren't under consideration > here. They are in the continuation context too. While the user stack may be freshly allocated in a sub the control stack can't. It's one stack. As COW is abandoned now, how different are stacks handled in stacks.c (User, Control, and Pad). Just saying "that's wrong" isn't really helpful. And finally WRT variable sized frames: It was discussed to save only used registers. When only P16..P19 registers are to be preserved we could just move these 4 pointers into a chunk. When this is happening a lot, we are wasting much memory with fixed sized frames. Investigating that isn't a bad idea - it might not work though. Changing the internals to use malloced memory is simple. It's all in one subroutine. I see the point with GC, but please lets do one step and then the next. leo
Re: opsfile.tgz
At 6:35 PM +0100 3/23/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: I think we should limit the number of unique IDs available at runtime to 32. We ought to limit it to 0, actually. :) These classifications are all compile-time things as they affect the code the preprocessor emits. And how do you handle PBCs then? No differently. I've half a reply to all this--I'll fire it off shortly. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Why use PARROT as the basis for Open Source Platforms (GNOME etc) ?
I've created the following WIKI (http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/WhyUseParrot) in response to Havoc Pennington's recent Opinion Article on Footnotes which advocates JAVA/JVM as the future of the Open Source Desktop. Please, feel free to check this out and respond as appropriate. Thanks, Gerry Butler The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
Re: Why use PARROT as the basis for Open Source Platforms (GNOME etc) ?
At 12:59 PM -0500 3/23/04, Butler, Gerald wrote: I've created the following WIKI (http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/WhyUseParrot) in response to Havoc Pennington's recent Opinion Article on Footnotes which advocates JAVA/JVM as the future of the Open Source Desktop. Please, feel free to check this out and respond as appropriate. Two important things: 1) Parrot's not hit 1.0 yet. Much as I like it (It is, after all, my fault) there are large portions not yet done. It works fine with what is finished, and I'm using it in a production project at work, but its not in a state that I'd recommend general usage. 2) Parrot isn't an acronym, and as such should be capitalized Parrot. (Unless you're on a teletype or using RAD-50) If you want to use PARROT the proper usage is: PARROT* * which stands for nothing 3) I can't count 4) While I know folks do love getting worked up and frothing over Their Favorite Software (which is, of course, The Absolute Right Thing for every possible use) I think nearly everyone involved would prefer the advocacy and "Your code/model/scheme/idea sucks!" messages to get routed elsewhere, rather than on any of these lists. I suggest /dev/null, but local conditions may vary. NL: and NLA0: are both nice places to save those message drafts, and remember that the advocacy versions of all these lists are hosted @127.0.0.1. (Which is much better suited to handle this sort of traffic... :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Oops, here's the full parrotunit
Piers Cawley <[EMAIL PROTECTED]> writes: > This time fer sure Since you're using a version of Gnus that supports it, you will want this in your .gnus: (setq mml-insert-mime-headers-always t) Gnus and ezmlm-idx don't play nice together without it (it's all ezmlm-idx's fault though, but good luck figuring out how and why). -- Lars Balker Rasmussen http://consult-perl.dk Consult::Perl
Safety and security
Okay, we'll try this again... (darned cranky mail clients) We've two big issues to deal with here--safety and security. While related they aren't the same and there are different things that need doing. As far as I can see it, we need four things: 1) An oploop that checks branch destinations for validity 2) Opcodes that check their parameters for basic sanity--valid register numbers (0-31) and basically correct (ie non-NULL) register contents 3) An oploop that checks basic quotas, mainly run time 4) Opcodes that check to see if you can actually do the thing you've requested #s 1&2 are safety issues. #2, specifically, can be dealt with by the opcode preprocessor, generating op bodies that do validity checking. #1 needs a bounds-checking runloop, which we mostly have already. I'm comfortable getting this done now, and this is what the framework that's going in should be able to handle OK. #s 3&4 deal with security. This... this is a dodgier issue. Security's easy to get wrong and hard to get right. (Though quotas are straightforward enough. Mostly) And once the framework's in place, there's the issue of performance--how do we get good performance in the common (insecure) case without sacrificing security in the secure case? At any rate, perl 5's Safe module is a good example of the Wrong Way to do security, and as such we're going to take it as a cautionary tale rather than a template. For security I want to go with an explicit privilege model with privilege checking in parrot's internals, rather than counting on op functions to Do The Right Thing. That means that IO restrictions are imposed by the IO code, not the IO ops, and suchlike stuff. Generally speaking, we're going to emulate the VMS quota and privilege system, as it's reasonably good as these things go. If we're going to tackle this, though, we need to pull in some folks who're actually competent at it before we do more than handwave about the design. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Safety and security
> > At any rate, perl 5's Safe module is a good example of the Wrong Way > to do security, and as such we're going to take it as a cautionary > tale rather than a template. For security I want to go with an > explicit privilege model with privilege checking in parrot's > internals, rather than counting on op functions to Do The Right > Thing. That means that IO restrictions are imposed by the IO code, > not the IO ops, and suchlike stuff. Generally speaking, we're going > to emulate the VMS quota and privilege system, as it's reasonably > good as these things go. For people who are wondering what has Dan got in his pipe today: http://www.sans.org/rr/papers/22/604.pdf And here a bit about quotas: http://h71000.www7.hp.com/DOC/72final/5841/5841pro_028.html#58_quotasprivilegesandprotecti (I swear I didn't make up the URL, HP did) > If we're going to tackle this, though, we need to pull in some folks > who're actually competent at it before we do more than handwave about > the design.
Dereferencing Syntax (Was: Outer product considered useful)
Luke Palmer writes:
> for @(@ranges[1]) -> $i {
Oooh, where did that dereferencing syntax come from, using parens rather
than braces?
Smylers
Re: Dereferencing Syntax (Was: Outer product considered useful)
Smylers wrote:
Luke Palmer writes:
for @(@ranges[1]) -> $i {
Oooh, where did that dereferencing syntax come from, using parens rather
than braces?
It isn't a dereferencing syntax--it's a context-forcing syntax (one I'm
intimately familiar with), which forces @ranges[1] into list context.
Which shouldn't affect anything. So I think it's probably a mistake.
--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: Dereferencing Syntax (Was: Outer product considered useful)
--- Smylers <[EMAIL PROTECTED]> wrote:
> Luke Palmer writes:
>
> > for @(@ranges[1]) -> $i {
>
> Oooh, where did that dereferencing syntax come from, using parens rather
> than braces?
@(...) is the "list context" operator in S3. I hope array references won't
explode in list context, that would be very annoying when making
multi-dimentional arrays:
@foo = ([1, 2], [3, 4]) # oops, would be (1, 2, 3, 4)
@foo = ($([1, 2]), $([3, 4])) # ugh :(
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
Unicode support in Emacs
Larry Wall wrote: > Well, it's too bad the emacs developers are lagging behind the vim > developers in this area, but it might (or might not) have something to > do with the fact that certain obnoxious people like me were bugging > the vim folks incessantly to get their Unicode story straight for a > couple of years before they actually did it. :-) About 10 years ago I wrote an email to Richard Stallman, who was at that time the maintainer for Emacs. And I asked him about Unicode. But at that time he had already thought of his own thing, slightly different than unicode, maybe slightly smarter... And he wrote me that this would be the way to go. :-( I get the impression that Unicode-support has kind of gone on top of this stuff and I must admit that the way I am currently using Unicode is to edit the stuff with \ucafe\ubabe-kind of replacements and run perlscripts to convert for example my private html-format into WWW-html. No, we should remind the Emacs-developers that the Unicode-support is at least pretty hard to handle for slightly below average users like me... > I would in particular like to thank Bram Moolenaar for not writing us > out of the book of life for all our whining. The Unicode support in > vim has been rock solid, and we are grateful. Maybe I'll start using that one day. ;-) Sorry for the off-topic, but I think that it has some importance for Perl in the sense that it is good to go the right way and not to wait until Emacs supports it out of the box without 1435 lines of lisp. Best regards, Karl P.S. Don't get me wrong: RMS is a good guy and he has done a lot of useful and good stuff, part of which many of us are using all the time. P.P.S. I don't think that RMS is the current maintainer of Emacs.
Re: CPAN Upload: A/AB/ABERGMAN/ponie-2.tar.gz - Ponie Development Release 2
On Mon, Mar 22, 2004 at 05:52:56PM +0100, Leopold Toetsch wrote: > Steve Hay <[EMAIL PROTECTED]> wrote: > > but linking parrot.exe fell over with three unresolved externals: > > asctime_r, gmtime_r and localtime_r. These are not present in the VC++ > > header files. > > These are fixed in Parrot CVS. Though I don't know, if ponie uses it > unaltered. Yes, the parrot subdirectory of ponie is direct from cvs.perl.org It's the perl subdirectory that is an import from a little while back (of 5.9.0) I assume that the ponie snapshot was made soon after a cvs up on the parrot directory, but this may not be. Nicholas Clark
UNO (Universal Network Objects) interface for Parrot?
Has anyone looked at what's needed to plug Parrot into UNO? --- snip --- http://udk.openoffice.org/ UNO (Universal Network Objects) is the interface-based component model of OpenOffice.org. UNO offers interoperability between different programming languages, different object models, different machine architectures and different processes; either in a local network or even via the internet. UNO components can be implemented in and accessed from any programming language for which a UNO language binding exists. Currently there are complete UNO language bindings for: - C - C++ (compiler dependent, please see http://porting.openoffice.org for a list of supported platforms) - Java - Python Additionally, there are bindings that allow to access UNO components, but do not support the development of new UNO components: - OpenOffice.org Basic - Object Linking and Embedding (OLE) Automation - Common Language Infrastructure (CLI). Note: The Microsoft .NET framework is an implementation of this standard. The language binding does NOT have the status "final" yet. Therefore do NOT use it (and programs based on it) in a production environment. --- snip --- Just a thought. Tim.
Re: Safety and security
On 24/03/2004, at 6:38 AM, Dan Sugalski wrote: At any rate, perl 5's Safe module is a good example of the Wrong Way to do security, and as such we're going to take it as a cautionary tale rather than a template. For security I want to go with an explicit privilege model with privilege checking in parrot's internals, rather than counting on op functions to Do The Right Thing. That means that IO restrictions are imposed by the IO code, not the IO ops, and suchlike stuff. Generally speaking, we're going to emulate the VMS quota and privilege system, as it's reasonably good as these things go. If we're going to tackle this, though, we need to pull in some folks who're actually competent at it before we do more than handwave about the design. This is a question without a simple answer, but does Parrot provide an infrastructure so that it would be possible to have proof-carrying[1] Parrot bytecode? I'm of course not advocating that we should look into proof-carrying code immediately, but I think it's important to realise that PCC exists, and that Parrot should be forward-compatible with it, if people want to put PCC concepts into Parrot at a later stage. 1. http://www.cs.princeton.edu/sip/projects/pcc/ -- Google around for plenty of other links! -- % Andre Pang : trust.in.love.to.save
Exceptions...
I'm trying to add exception handling support back in to tcl so I can trap references to non-existant variables. This is using a recent, but not just-now, cvs checkout. I am currently getting a segfault if I enable the exception handler. Running the code through -t, I see this near the end: 3844 set_eh P16 - P16=Exception_Handler=PMC(0x9e0518) 3846 find_lex P16, -1, S18- P16=Exception_Handler=PMC(0x9e0518), , S18="a" 4094 print "excepted\n" excepted 4096 set P2, P5["_invoke_cc"] - P2=NULL, P5=Exception=PMC(0x9e0500), 4100 invoke P2- P2=RetContinuation=PMC(0x9e04e8) 3850 clear_eh 3851 print "HERE?\n" HERE? 3853 typeof S17, P16 - S17="Sub", P16=NULL 4094 is the exception handler code - so that's getting called. It's a do nothing handler, so it just invokes back to where it was going, which it does. I don't have a short example on this one - I can try to cook one up, if you like, but it may take a while. The PIR associated with that is: set_eh ignore find_lex lexical, -1, arg0 clear_eh print "HERE?\n" typeof type, lexical if type == "PerlUndef" goto no_such_variable Here's the crash log (OS X) Date/Time: 2004-03-23 21:07:13 -0500 OS Version: 10.2.8 (Build 6R73) Host: oolong.local. Command:parrot PID:1404 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0010 Thread 0 Crashed: #0 0x0005c5f0 in Parrot_typeof_s_p (core_ops.c:106) #1 0x0010cf3c in runops_slow_core (runops_cores.c:146) #2 0xb12c in runops_int (interpreter.c:838) #3 0xb1f4 in runops_ex (interpreter.c:865) #4 0xb420 in runops (interpreter.c:941) #5 0xf134 in Parrot_runcode (embed.c:693) #6 0x3e9c in main (main.c:559) #7 0x2470 in _start (crt.c:267) #8 0x22f0 in start Thread 1: #0 0x9003e9a8 in semaphore_wait_signal_trap #1 0x9003e7c4 in _pthread_cond_wait #2 0x00199004 in queue_wait (tsq.c:319) #3 0x00107340 in event_thread (events.c:890) #4 0x90020c28 in _pthread_body Thread 2: #0 0x9002568c in select #1 0x00106ce8 in io_thread (events.c:640) #2 0x90020c28 in _pthread_body PPC Thread State: srr0: 0x0005c5f0 srr1: 0xf030vrsave: 0x xer: 0x lr: 0x0010cf3c ctr: 0x0005c598 mq: 0x r0: 0x0040 r1: 0xb870 r2: 0x1000 r3: 0x00a0bd04 r4: 0x0097e400 r5: 0x0098fea0 r6: 0x00bb5a38 r7: 0x0098fea0 r8: 0x0098fea0 r9: 0x r10: 0x0001e73b r11: 0x0097e400 r12: 0x0005c598 r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x r23: 0x r24: 0x r25: 0x r26: 0xbc84 r27: 0x0014 r28: 0x0004 r29: 0x0097e5c4 r30: 0xb870 r31: 0x0010ce64 -- Will "Coke" Coledawill at coleda dot com
Re: Continuations, stacks, and whatnots
All~ This got warnocked when last I sent it, so I will try again as I think it is a reasonable idea. I am not sure that I understand why we deal with exception handlers in the current manner. Why not just make exception handlers a second continuation passed to all functions. Then you call continuation 1 for successful returns and continuation 2 for exceptions. This will not introduce overhead to the common case, as common case is not installing exception handlers so you can just pass along the one you were handed, while it will simplify the code by removing the need for the control stack and special exceptions pmcs. Matt Dan Sugalski wrote: At 12:59 AM + 3/23/04, Piers Cawley wrote: Leopold Toetsch <[EMAIL PROTECTED]> writes: Dan Sugalski <[EMAIL PROTECTED]> wrote: ... If we go with a one frame stack chunk then we don't have to bother with COW-ing *anything* with the stack. BTW: which stacks: Register frames of course. What about Pad, User, and Control? I hope he means "All of 'em". And what control stack? The continuation chain is the control stack, surely? Nope. There's the exception handlers, at the very least. Possibly some lexical pad stuff. (Though of that I'm less sure)
Re: Continuations, stacks, and whatnots
Matt Fowles <[EMAIL PROTECTED]> wrote: > All~ > This got warnocked Only indirectly ... > ... Why not just make exception handlers a second > continuation passed to all functions. ... because it is answered in a f'up to a similar proposal by our summarizer: ,--[ leo ]--- | What about C code that either installs exception handlers or throws | exceptions? ` ,--[ dan ] | Or multiple nested exception handlers, or serial exception handlers in a | block... And then there's the fun with exception handlers and | coroutines. `- leo
Re: Exceptions...
Will Coleda <[EMAIL PROTECTED]> wrote: > I'm trying to add exception handling support back in to tcl so I can > trap references to non-existant variables. This is using a recent, but > not just-now, cvs checkout. > I am currently getting a segfault if I enable the exception handler. > Running the code through -t, I see this near the end: >3844 set_eh P16 - P16=Exception_Handler=PMC(0x9e0518) >3846 find_lex P16, -1, S18- P16=Exception_Handler=PMC(0x9e0518), > , S18="a" >4094 print "excepted\n" > excepted >4096 set P2, P5["_invoke_cc"] - P2=NULL, > P5=Exception=PMC(0x9e0500), >4100 invoke P2- P2=RetContinuation=PMC(0x9e04e8) >3850 clear_eh >3851 print "HERE?\n" > HERE? >3853 typeof S17, P16 - S17="Sub", P16=NULL Null PMC access in name() The problem is: you are clearing the exception handler in 3850 and then in 3853 you access the non-existent lexical. find_lex lexical, -1, "xx" isnull lexical, no_such_variable clear_eh I don't get the segfault here. This may be related to some fixes that the stack changes include. leo
B::Concise tests -> Grand Plan
Folks,
I hope this is an appropriate forum, I want to get the topic off of p5p,
and return there later with a more polished solution...
Rafael Garcia-Suarez wrote:
jim cromie wrote:
I picked this back up recently, I think it now incorporates all comments
from this thread started 1/6/04, plus a few off-list suggestions.
Thanks, I applied the Concise.pm part of your patch as change #22539.
I didn't apply the test patch, because :
1. you probably missed the fact that Concise returns different output
with threaded and unthreaded perls
2. you gave me an idea for a Grand Plan.
The other day I added an optimisation that basically transforms
my $x = undef;
into
my $x;
but I didn't add a test for it, because I didn't knew how to do it.
Thus, if we then modify the optree building in a way that breaks this
optimisation, this will go unnoticed, and this is not a good thing.
But your patch to B::Concise gives a tool to test such things.
So what I'd like is a new test file, let's say ext/B/t/optrees.t, that
lists code snippets and expected optrees in a way perhaps inspired by
the things under t/lib/warnings/*, in a way that it's easy to add new
stuff ; that takes into account perl configuration differences
(useithreads for example) ; and in which in the future we would add
regression tests for optree optimisations. (@x = sort @x in place comes
to mind as well.) What do you think about this ?
Lots to think about. But rather than start a design by committee thing,
heres a strawman to start with. It falls short on the 'framework'
question, but tests are still easy to add.
Attached patch pbc2.4 reworks the tests:
ext/B/t/concise.t tests B::Concise API
ext/B/t/optree.t
defines test function & helper
calls to test-func use heredocs to give args
tests are in 3 grps;
selftests - harness works as intended.
canonical example - from B::Concise docs
may add more B::Concise tests for Outside O Framework
optimizations
my $a = undef;
@a = sort @a;
BIGGEST ISSUE:
B::Concise gives different format for threaded vs non-threaded builds.
Note that the gvsv op is the only one different - in this sample.
with '[]' replaced by '()'
and leading <#> replaced by <$>
[EMAIL PROTECTED] bc3]$ ./perl -Ilib -MO=Concise -e '$a++'
5 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e:1) v ->3
4 <1> preinc[t2] vK/1 ->5
-<1> ex-rv2sv sKRM/1 ->4
3 <#> gvsv[*a] s ->4
-e syntax OK
[EMAIL PROTECTED] bleadnothread]$ ./perl -Ilib -MO=Concise -e '$a++'
5 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e:1) v ->3
4 <1> preinc[t1] vK/1 ->5
-<1> ex-rv2sv sKRM/1 ->4
3 <$> gvsv(*a) s ->4
-e syntax OK
The tests now pass for both threaded and non-threaded,
via a non-thread fixup stage, but is is done opcode by opcode,
and WILL NEED enhancement as new opcodes are added into tests.
are threaded/non-threaded differences considered to be a feature ?
is eliminating the diff a wrong-headed fix ?
diff -ru bleadperl/MANIFEST bc3/MANIFEST
--- bleadperl/MANIFEST Fri Mar 19 05:19:30 2004
+++ bc3/MANIFESTTue Mar 23 12:15:49 2004
@@ -118,6 +118,7 @@
ext/B/t/lint.t See if B::Lint works
ext/B/Todo Compiler backend Todo list
ext/B/t/o.tSee if O works
+ext/B/t/optree.t See if optimization works
ext/B/t/showlex.t See if B::ShowLex works
ext/B/t/stash.tSee if B::Stash works
ext/B/t/terse.tSee if B::Terse works
Only in bc3: MANIFEST~
diff -ru bleadperl/ext/B/t/concise.t bc3/ext/B/t/concise.t
--- bleadperl/ext/B/t/concise.t Tue Feb 4 14:17:24 2003
+++ bc3/ext/B/t/concise.t Tue Mar 23 01:23:03 2004
@@ -6,7 +6,7 @@
require './test.pl';
}
-plan tests => 5;
+plan tests => 38;
require_ok("B::Concise");
@@ -34,4 +34,134 @@
stderr => 1,
);
-like($out, qr/print/, "-exec option with //=");
+like($out, qr/print/, "'-exec' option output has print opcode");
+
+ API tests v.60
+
+use Config;# used for perlio check
+B::Concise->import(qw(set_style set_style_standard add_callback
+ add_style walk_output));
+
+## walk_output argument checking
+
+# test that walk_output accepts a HANDLE arg
+foreach my $foo (\*STDOUT, \*STDERR) {
+eval { walk_output($foo) };
+is ($@, '', "walk_output() accepts STD* " . ref $foo);
+}
+
+# test that walk_output rejects non-HANDLE args
+foreach my $foo (undef, 0, "string",[], {}) {
+eval { walk_output($foo) };
+isnt ($@, '', "walk_output() rejects arg '$foo'");
+[EMAIL PROTECTED]''; # clear the fail for next test
+}
+
+{ # any object that can print should be ok for walk_output
+package Hugo;
+sub new { my $foo = bless {} };
+sub print { CORE::print @_ }
+}
+my $foo = new Hugo;# suggested this API fix
+eval { walk_output($foo) };
+is ($@, '', "walk_output() accepts obj that can print");
+
+# now test a ref
Re: [perl #24728] Problem on SuSE (8.1 I think)
On Sun, Dec 21, 2003 at 11:44:44PM +, Frederick Alexander Thomssen wrote: > # New Ticket Created by Frederick Alexander Thomssen > # Please include the string: [perl #24728] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=24728 > > > > hi, > > I ran into troubles when installing perl 5.8.1/5.8.2/5.9.0 on a SuSE machine I > think it is a SuSE 8.1): > ./Configure aborted with the error message > "Configure: line 8199: set: -s: invalid option" after "Figuring out host > name...". > > The problem is in the file hints/linux.sh in lines 217-229. There runs a check > that uses csh/tcsh. This SuSE-tcsh seems to have a problem with hostname - > when you run hostname it returns "-s" - even after returning to bash (which > is my standard shell). > > So somewhere hostname will still return "-s" and brings me this error message. > I now commented these lines from hints/linux.sh out and it works... I suggest > to check if hostname still runs properly after these lines or using the > variable $HOSTNAME... Please accept my apologies that no-one here has responded in the past 3 months - it seems to be the way that open source mailing lists work. You've actually mailed the wrong bug reporting address (you mailed the perl6/parrot bug reporting address, not the perl5 address), so your bug has been sent to the parrot list, where no-one has answered (because it's "off topic"). This isn't great, considering that you made a genuine mistake. Although it has been spotted by a bug admin and your ticket now put in the correct bug queue (ie it's now perl5), this doesn't cause your message to be resent to the correct mailing list, so no-one there is aware of your bug report. I've Cc'd this message to the perl5 list, and tried to set followups to be there only. I'm not sure of the best way to avoid the problems you've had with being inadvertently ignored, but it is something we (the perl comminity) aren't getting right yet, and it is something we should fix. As to the original bug you report - I no longer have access to any SuSE machines, but I did build perl from source on a SuSE 8.1 box within the past 3 months and didn't encounter the problems you encountered. Strange. Hopefully someone else has access to SuSE and can replicate your problems Nicholas Clark
