Re: [CVS ci] packfile #2

2003-01-28 Thread Leopold Toetsch
Garrett Goebel wrote: Leopold Toetsch wrote: > > - 8/12 byte float issues are still the same - are these >formats really portable, or should we try to store >ASCII equivalents? No? ? Because my knowledge here approaches zero, so I'm just aping information back at you from google se

Re: This week's Perl 6 Summary

2003-01-28 Thread banjo
On Tue, 2003-01-28 at 06:34, Piers Cawley wrote: > Compiling to Parrot > K Stol is looking for a final project for his Bachelor's degree and > would like to implement some language targeting Parrot and asked for > suggestions. Simon Wistow suggested PHP or Lua, Leon Brocard suggested

[perl #20592] [PATCH] save and restore more of a coroutine's context (and more)

2003-01-28 Thread via RT
# New Ticket Created by Jonathan Sillito # Please include the string: [perl #20592] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=20592 > A description of each attachment: 1) coroutine.t (which should be put in t/pmc/) ex

Re: Securing Parrot ASM

2003-01-28 Thread Matthew Byng-Maddick
On Tue, Jan 28, 2003 at 02:26:14PM -0500, Dan Sugalski wrote: > *) There'll be a set of 'privileges' of some sort (call 'em > capabilities or whatever) and to do various tasks will require that > you have an appropriate privilege Please don't use "capabilities" for this. The term "capability" is

Re: [perl #20584] [PATCH] packfile #5

2003-01-28 Thread blair christensen
On Tue, Jan 28, 2003 at 01:33:53PM +, Leopold Toetsch wrote: > # New Ticket Created by Leopold Toetsch > # Please include the string: [perl #20584] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=20584 > > > > This i

Parrot developer world map

2003-01-28 Thread Leon Brocard
Last week I collected your data. This week I bring you pretty pictures: http://www.astray.com/parrot/worldmap/ So London would seem a good place for a Parrot developer day, as would California. I guess most people will be meeting up at Perl conferences anyway. What do people have in mind for s

RE: [CVS ci] packfile #2

2003-01-28 Thread Garrett Goebel
Leopold Toetsch wrote: > > - 8/12 byte float issues are still the same - are these >formats really portable, or should we try to store >ASCII equivalents? No? ? Because my knowledge here approaches zero, so I'm just aping information back at you from google searches and scanning documen

PyCon

2003-01-28 Thread Christopher Armstrong
Hey, any Parrot hackers going to the Python convention at the end of March? http://python.org/pycon/. Price will be $150-$200. I'm very interested in meeting and discussing there :-) -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted P

Re: Securing Parrot ASM

2003-01-28 Thread Dan Sugalski
At 11:41 AM + 1/28/03, Thomas Whateley wrote: Hi, I've been thinking about how to run un-trusted code, without having to audit every line, or use some sort of sandbox, and was wondering if Parrot could provide a Mandator Access Control mechanism (ala SE Linux/Flask). Ah, I've been hoping to

Re: Securing Parrot ASM

2003-01-28 Thread Allen Short
> "Brent" == Brent Dax <[EMAIL PROTECTED]> writes: > I don't see why Parrot couldn't do much of this. It can > certainly audit allocations made through its own > memory-allocation system, and with only a little help from the > system it should be able to audit its processor u

Re: Securing Parrot ASM

2003-01-28 Thread Allen Short
> "Matthew" == Matthew Byng-Maddick <[EMAIL PROTECTED]> writes: >> I guess what I'm saying is, sure, you can't stop a native >> function (which was called from parrot code) from doing >> whatever it wants, but you can still prevent the parrot code >> from using that function in

Re: Securing Parrot ASM

2003-01-28 Thread Fred K Ollinger
> On Tue, Jan 28, 2003 at 10:39:33AM -0600, Joseph Guhlin wrote: > > Pardon my ignorance on the whole issue but I'm just a lurker trying to > > understand enough to help out. =) > > I know security on parrot like this would be difficult, and this thread > > is specifically about securing PASM, but

Re: Securing Parrot ASM

2003-01-28 Thread Christopher Armstrong
On Tue, Jan 28, 2003 at 04:15:41PM +, Matthew Byng-Maddick wrote: > On Tue, Jan 28, 2003 at 11:04:43AM -0500, Christopher Armstrong wrote: > > Hrm, maybe I just don't know what's going on, but I'm not sure why > > this is a problem. Couldn't "call out to native functions" or perhaps > > "call o

Re: [Introspector-developers] Re: Bytecode metadata

2003-01-28 Thread Gopal V
If memory serves me right, James Michael DuPont wrote: > > > Bah. That's "parrot -o foo.o foo.pmc" isn't it? > > > > And if we make C a parrot supported language we can even build parrot > > with parrot? Hmmm... bootstrapping > 1. The gcc : I have %99 of the information about the function b

Re: Securing Parrot ASM

2003-01-28 Thread Christopher Armstrong
On Tue, Jan 28, 2003 at 09:24:20AM -0800, Brent Dax wrote: > Christopher Armstrong: > # One other thing to think about is resource limits. It'd be nice to not > # require `ulimit' or whatever system-specific resource limitation > # mechanism, but rather rely on the parrot interpreter to > # baby-si

RE: Securing Parrot ASM

2003-01-28 Thread Brent Dax
Matthew Byng-Maddick: # It seems to me that the linking with native code is going to # end up being one that most people switch on, because it will # be necessary and/or useful in getting anything done. Then make sure that "link in native code" isn't a permission--"link in native code library X"

RE: Securing Parrot ASM

2003-01-28 Thread Brent Dax
Christopher Armstrong: # One other thing to think about is resource limits. It'd be nice to not # require `ulimit' or whatever system-specific resource limitation # mechanism, but rather rely on the parrot interpreter to # baby-sit. Also, it'd make catching these resource-limit violations # much mo

Re: Securing Parrot ASM

2003-01-28 Thread Matthew Byng-Maddick
On Tue, Jan 28, 2003 at 10:39:33AM -0600, Joseph Guhlin wrote: > Pardon my ignorance on the whole issue but I'm just a lurker trying to > understand enough to help out. =) > I know security on parrot like this would be difficult, and this thread > is specifically about securing PASM, but what abo

Re: Securing Parrot ASM

2003-01-28 Thread Joseph Guhlin
Pardon my ignorance on the whole issue but I'm just a lurker trying to understand enough to help out. =) I know security on parrot like this would be difficult, and this thread is specifically about securing PASM, but what about something like FreeBSD's 'jail' command built in? That way, even un

Re: Securing Parrot ASM

2003-01-28 Thread Fred K Ollinger
> I've been thinking about how to run un-trusted code, > without having to audit every line, or use some sort of sandbox, > and was wondering if Parrot could provide a Mandator Access > Control mechanism (ala SE Linux/Flask). I think that this is a great idea. > When assembling Parrot, the assemb

Re: Securing Parrot ASM

2003-01-28 Thread Matthew Byng-Maddick
On Tue, Jan 28, 2003 at 11:04:43AM -0500, Christopher Armstrong wrote: > On Tue, Jan 28, 2003 at 02:11:39PM +, Matthew Byng-Maddick wrote: > > What happens when you link in some module that's written natively? > > Basically, my conclusion was that this was, unfortunately, still > Hrm, maybe I j

Re: Securing Parrot ASM

2003-01-28 Thread Christopher Armstrong
On Tue, Jan 28, 2003 at 02:11:39PM +, Matthew Byng-Maddick wrote: > On Tue, Jan 28, 2003 at 11:41:14AM +, Thomas Whateley wrote: > > I've been thinking about how to run un-trusted code, > > without having to audit every line, or use some sort of sandbox, > [snip] > > block to audit and be c

Re: Securing Parrot ASM

2003-01-28 Thread Matthew Byng-Maddick
On Tue, Jan 28, 2003 at 11:41:14AM +, Thomas Whateley wrote: > I've been thinking about how to run un-trusted code, > without having to audit every line, or use some sort of sandbox, [snip] > block to audit and be certain of what a module/program could > do to my system. As author of http://de

[perl #20584] [PATCH] packfile #5

2003-01-28 Thread via RT
# New Ticket Created by Leopold Toetsch # Please include the string: [perl #20584] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=20584 > This is a first try to solve the packfile wordsize issues. Could people with 64 bit m

Re: Securing Parrot ASM

2003-01-28 Thread Christopher Armstrong
On Tue, Jan 28, 2003 at 11:41:14AM +, Thomas Whateley wrote: > Hi, > > I've been thinking about how to run un-trusted code, > without having to audit every line, or use some sort of sandbox, > and was wondering if Parrot could provide a Mandator Access > Control mechanism (ala SE Linux/Flask)

Securing Parrot ASM

2003-01-28 Thread Thomas Whateley
Hi, I've been thinking about how to run un-trusted code, without having to audit every line, or use some sort of sandbox, and was wondering if Parrot could provide a Mandator Access Control mechanism (ala SE Linux/Flask). When assembling Parrot, the assembler could either look in a file or a pe

Re: Bytecode metadata

2003-01-28 Thread martin
On Sun, 26 Jan 2003, James Mastros wrote: > just define a new packfile section, SIGNATURE, that is defined to be a > cryptographic signature of all sections previous to it in the file. I'm battling with this in another file format at the moment; if possible can we please *not* have it sensitive to

Re: Compiling to Parrot

2003-01-28 Thread K Stol
Hi there, didn't have time to reply earlier, had to do some research on Lua and had to get approval for the project, so couldn't let you know earlier. sorry about that. But now, I have it (the approval, that is) so I'll be implementing a compiler for Lua->parrot (most probably IMCC in between). t

Re: occasioanl CVS hickups?

2003-01-28 Thread Leopold Toetsch
Robert Spier wrote: Odd. There's not enough information in the logs to figure out what's going on. (And the code shouldn't have this kind of failure mode.) If it keeps happening, please keep me in the loop. Did it again. This time w/o error message - it looked totally sane. From yesterday

[CVS ci] packfile #3 - double/long double PBC support

2003-01-28 Thread Leopold Toetsch
This patch enables reading 12 byte long doubles on parrot with 8 byte doubles and vv. Writing long doubles via imcc/packout works too. The questions still remains: how portable are these formats? Still borken: assemble.pl leo