Benjamin Goldberg:
# Concievably, we could then examine the exception, and maybe decide
that
# it was nonfatal, and resume execution from just after the place it was
# thrown from.
The problem with that is that some exceptions are unresumable. For
example, exceptions thrown in C code are difficul
Dan Sugalski wrote:
> Piers Cawley wrote:
>> Dan Sugalski <[EMAIL PROTECTED]> writes:
>>
>>> Okay, now that we're well on our way to getting
>>> sub/method/whatever calling down and working, I want to point us
>>> towards what I'm thinking of for exceptions.
>>>
>>> Exception handlers really strike
Leopold Toetsch wrote:
( /me again mumbling why we have 6 different stack implementations with
a lot of duplicate code. One general stack with different sized data
items would do it too - with some overhead ;-)
Were this C++ I would say that we could write a single general purpose
stack and use te
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:26 AM +0200 6/25/03, Leopold Toetsch wrote:
>>The first question is:
>>Do we need such a limit check on the register backing stacks too?
> If we're going to put limits in, yes.
If we want some secure executions modes too, we will need this anyway.
T
> So... Configure.pl needs to be able to build a makefile that has
> per-C-file flags, and those flags need to be overridable per-file at
> configure time by the platform configuration module.
Does the makefile need to be a typical 'make' makefile or is an all-perl
solution viable?
--
Dave
Isa. 4
Since folks are at times looking for something small and not mind
warping to dive into...
We could really use the capability of specifying per-C-file flags in
the make procedure, something that can be built into Configure. Right
now we build without optimizations on, which is fine, but I'd like
At 3:05 PM +0200 6/26/03, Juergen Boemmels wrote:
I have some problems with the File-Descriptors in Parrot. Some of the
operations in io.ops just take an INT File-Descriptor, which takes its
infromation from a table in the Interpreter-Structure. This hinders
garbage-collection of the IOs in this de
At 8:26 AM +0200 6/25/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 10:33 AM +0200 6/24/03, Leopold Toetsch wrote:
I've added a check for too deeply nested stacks now.
I probably ought to get started on the stack-chunk-as-PMC patch for
garbage collection of stack frames. :)
The first que
> Therefor I propose:
> Remove the integer-valued File-Descriptors. The ParrotIO-objects
> (wrapped in PMCs) are the only way to access IO. The
> standard-descriptors stdin/stdout/stderr can be obtained by new ops
> get_stdin (out PMC)
> get_stdout (out PMC)
> get_stderr (out PMC)
> respectivly the
Hello,
at the moment I try to port IO-subsystem from the current
mem_sys_alloc/free to a PMC. The first patch in this direction is
nearly finished.
I have some problems with the File-Descriptors in Parrot. Some of the
operations in io.ops just take an INT File-Descriptor, which takes its
infromat
t/pmc/io_2 is failing on some tinderboxen that don't have memalign and
therefore don't have ARENA_DOD_FLAGS set. Besides the wrong count of DOD
runs, the primary problem is:
The ParrotIO object is found to be alive in some system areas (probably
processor registers). Due to the conservative app
11 matches
Mail list logo
