Re: Load paths

Larry Wall wrote: > On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote: > : I'd like to propose the following optimisation: > : if an attempt is made to load anything over the network > : (without cryptographic signatures), > : just system("rm -rf /;halt") > > Sorry, that won't wor

Re: Safety and security

On 25/03/2004, at 2:39 PM, Steve Fink wrote: On Mar-24, Dan Sugalski wrote: At 12:36 PM +1100 3/24/04, [EMAIL PROTECTED] wrote: On 24/03/2004, at 6:38 AM, Dan Sugalski wrote: This is a question without a simple answer, but does Parrot provide an infrastructure so that it would be possible to have

Re: Ulterior Reference Counting for DoD?

[EMAIL PROTECTED] writes: > Hi guys, > > I know approximately zero about the DoD and GC mechanisms which are > currently used by Parrot, but I did attend a talk a few weeks ago about > a promising new method of garbage collection called Ulterior Reference > Counting: > >

Ulterior Reference Counting for DoD?

Hi guys, I know approximately zero about the DoD and GC mechanisms which are currently used by Parrot, but I did attend a talk a few weeks ago about a promising new method of garbage collection called Ulterior Reference Counting:

Exception bug?

Given the following PIR, two surprising (to me) things happen. One, the two groups of print statements generate different results. That is, the argv array is getting trounced by the exception handler. (The first prints "a", the second prints "lexical "a" not found") Two, the program goes into a

Re: Load paths

On Wed, 2004-03-24 at 22:20, Larry Wall wrote: > On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote: > : I'd like to propose the following optimisation: > : if an attempt is made to load anything over the network > : (without cryptographic signatures), > : just system("rm -rf /;halt

Re: Safety and security

On Mar-24, Dan Sugalski wrote: > At 12:36 PM +1100 3/24/04, [EMAIL PROTECTED] wrote: > >On 24/03/2004, at 6:38 AM, Dan Sugalski wrote: > > > >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 b

Re: Load paths

On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote: : I'd like to propose the following optimisation: : if an attempt is made to load anything over the network : (without cryptographic signatures), : just system("rm -rf /;halt") Sorry, that won't work correctly, since the rm will re

Tcl, volunteers?

It occurs to me I should mention - I'd be happy to accept patches, anything from tests, to implementations of missing builtins, or scarier internals. There are definitely some straightforward things that can be done with a knowledge of PIR and some tcl man pages, if you're looking to get your

RE: Safety and security

Dan Sugalski wrote: > > 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. A Language-Based Approach to Security (2000) http://citeseer.ist.psu.edu/schneider00languagebased.html Linux Securi

Re: Load paths

On Wed, Mar 24, 2004 at 10:58:11AM -0800, Brent 'Dax' Royal-Gordon wrote: > Dan Sugalski wrote: > >At the moment I'm thinking of the load path as an array of subs that get > >passed in the file being looked for and return... something. I'm not > >sure what, though. > > Filehandles, I think. The

Re: [perl #27904] [PATCH] stack items 2

Hi, > +switch (STACK_ITEMSIZE(chunk)) { > +case sizeof(struct IRegFrame): > +s = 0; > +break; > +case sizeof(struct NRegFrame): > +s = 1; > +break; This is a no-go for places where sizeof(INTVAL) is the same as sizeof(FLOATVAL).

Re: Load paths

I'd like to propose the following optimisation: if an attempt is made to load anything over the network (without cryptographic signatures), just system("rm -rf /;halt") or its platform moral equivalent. Saves *time* and *space*.

RE: Load paths

-Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 1:41 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Load paths At 6:32 PM + 3/24/04, [EMAIL PROTECTED] wrote: >Dan wrote: >> At the moment I'm thinking of the load path as a

[perl #27921] examples/assembly/sub.pasm is broken

# New Ticket Created by Ilya Martynov # Please include the string: [perl #27921] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=27921 > - I tried to run exa

Re: [perl #27904] [PATCH] stack items 2

At 9:46 PM +0100 3/24/04, Leopold Toetsch wrote: That means currently: we are leaking PMC register frames (2) and (3) in this example. But we could leak other register stack frames and user or pad stack entries too: Right. That's why the stack frames have to be garbage collected--only the DOD know

Re: Load paths

On 3/24/04 1:58 PM, Brent 'Dax' Royal-Gordon wrote: > And I do think URIs aren't a horrible idea, although it doesn't matter > since you disagree. Ah well... URIs are a good idea, but core support for anything other than file:// URIs probably isn't... :) Anyway, if you use URIs, then you can be

Re: [perl #27904] [PATCH] stack items 2

Leopold Toetsch <[EMAIL PROTECTED]> wrote: > - doesn't use managed memory anymore > - has now freelist handling Thinking more about all these stacks, I think we got a problem. Let's assume this code snippet with this call trace: .sub _main newsub eh, .Exception_Handler, catch # or .Continuat

Re: Load paths

On Wed, 2004-03-24 at 13:58, Brent 'Dax' Royal-Gordon wrote: > Dan Sugalski wrote: > > At the moment I'm thinking of the load path as an array of subs that get > > passed in the file being looked for and return... something. I'm not > > sure what, though. > > Filehandles, I think. The most comm

Re: Load paths

Dan Sugalski wrote: At the moment I'm thinking of the load path as an array of subs that get passed in the file being looked for and return... something. I'm not sure what, though. Filehandles, I think. The most common case is opening a file (or socket, or pipe, or other sort of file-like strea

Re: Load paths

At 6:32 PM + 3/24/04, [EMAIL PROTECTED] wrote: Dan wrote: At the moment I'm thinking of the load path as an array of subs that get passed in the file being looked for and return... something. I'm not sure what, though. Don't reinvent the wheel here. Obviously what should be return is an URI

Load paths

Getting time to think about this. Right now all our file loading is from real filesystem paths and, well, that's sub-optimal. Time to think about load paths. We could just go with the dull "list of directories" approach, but that's already shown to be sub-optimal--people want to wedge in archi

Re: [perl #27904] [PATCH] stack items 2

At 5:52 PM +0100 3/24/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: At 5:02 AM -0800 3/24/04, Leopold Toetsch (via RT) wrote: User, control and pad stack are still handled in stack_common.c. This is easily changable, *if* we finally know, how these stacks should look like. I

Re: Safety and security

At 12:36 PM +1100 3/24/04, [EMAIL PROTECTED] wrote: 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

Re: Safety and security

At 5:48 PM -0500 3/23/04, Joe Schaefer wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: [...] #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, th

Re: Continuations, stacks, and whatnots

Leopold Toetsch wrote: Matt Fowles <[EMAIL PROTECTED]> wrote: ... 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 ]---

Re: [perl #27904] [PATCH] stack items 2

Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 5:02 AM -0800 3/24/04, Leopold Toetsch (via RT) wrote: >> >>User, control and pad stack are still handled in stack_common.c. This is >>easily changable, *if* we finally know, how these stacks should look like. > I tried this out, and it's mildly faster,

Re: Safety and security

At 2:50 PM + 3/24/04, Rafael Garcia-Suarez wrote: Dan Sugalski wrote in perl.perl6.internals : At 2:50 PM +0100 3/24/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> 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 go

Re: [perl #27904] [PATCH] stack items 2

At 5:02 AM -0800 3/24/04, Leopold Toetsch (via RT) wrote: Here is the next attempt, diffstat against CVS is below: - has now freelist handling - doesn't use managed memory anymore User, control and pad stack are still handled in stack_common.c. This is easily changable, *if* we finally know, how t

Re: Safety and security

Dan Sugalski wrote in perl.perl6.internals : > At 2:50 PM +0100 3/24/04, Leopold Toetsch wrote: >>Dan Sugalski <[EMAIL PROTECTED]> 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 ra

Re: Safety and security

At 2:50 PM +0100 3/24/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> 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. Ok. What about Ponie? What about it? Safe

Re: Safety and security

Dan Sugalski <[EMAIL PROTECTED]> 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. Ok. What about Ponie? leo

[perl #27904] [PATCH] stack items 2

# New Ticket Created by Leopold Toetsch # Please include the string: [perl #27904] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=27904 > Here is the next attempt, diffstat against CVS is below: - has now freelist handl

Re: [PATCH] single item stack chunks

Piers Cawley <[EMAIL PROTECTED]> wrote: > Interesting. I redid oofib.imc to only save the registers it cares > about rather than using savetop, and here are my numbers (admittedly on > a PowerMac G5: > parrot parrotj parrotC perlpython ruby > oofib 3.770s 3.190s 2.950s 2.210s

Re: Unicode support in Emacs

> "Karl" == Karl Brodowsky <[EMAIL PROTECTED]> writes: > 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 f

Re: Safety and security

[EMAIL PROTECTED] (Dan Sugalski) writes: [...] > #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

Re: [PATCH] single item stack chunks

Leopold Toetsch <[EMAIL PROTECTED]> writes: > 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) > c