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
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 ]--
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 co
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:
3
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
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 f
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 ma
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
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
> > 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
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 fo
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
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.
Plea
--- 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 wo
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 respo
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
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.
Wh
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
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?
le
Luke Palmer writes:
> for @(@ranges[1]) -> $i {
Oooh, where did that dereferencing syntax come from, using parens rather
than braces?
Smylers
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
> >
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 sin
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 {
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 3
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.
Regard
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
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 conti
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* s
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
> - 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
> - 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, w
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]:
$ p
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-end
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
34 matches
Mail list logo
