> "NS" == Nigel Sandever <[EMAIL PROTECTED]> writes:
NS> ATOMICITY AND CRITICAL SECTIONS
UG> that is what i mentioned above, disabling time slicing/ preemption when
UG> desired. it is not just a win32 concept. hell, turning off interrupts
UG> during interrupt handlers goes way back! r
On Thu, 01 Jan 2004 21:32:22 -0500, [EMAIL PROTECTED] (Uri Guttman) wrote:
UG> Uri Guttman
NS> Nigel Sandever. (Mostly not reproduced here!)
NS> REENTRANCY
UG> this is true for c level threads but not necessarily true for VM level
UG> threads. f the VM is atomic at its operation level and c
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Does IMCC have any good debugging hooks inside it? I'm running into a
> problem where one of my subs is thinking it's an old-style (params on
> stack) sub
That's very probably coming from comments before/inmidst .param
directives. The parser currently does
At 11:52 AM + 1/2/04, Harry Jackson wrote:
Dan Sugalski wrote:
[EMAIL PROTECTED] pbin]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-108.1)
Yeah, that was the one, unfortunately. Try disabling the JIT during
configu
As I studiously ignore all the thread threads (Ah, deadlines--gotta
love 'em) I'm bumping into a number of things in the system as it
currently stands that could use fixing/enhancement/rethinking. At the
moment, the thing is the debugger, trace mode, and/or the compiler.
First off, trace mode i
Does IMCC have any good debugging hooks inside it? I'm running into a
problem where one of my subs is thinking it's an old-style (params on
stack) sub rather than a PDD03 compliant sub. Doesn't seem to matter
where this thing appears (I've tried moving it) so there's something
weird going on, b
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Add in support for the T and L NCI types. (char pointer array and
> long array)
These should IMHO be no separate signatures, but be expressed in terms
of the 'p' signature and use an appropriate {Un,}ManagedStruct PMC[1]. If
we start passing all these
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> 3) a separate array for the JITed method stubs, which are per interpeter
>and only if the platform can generate such stubs on the fly.
Done now. JITted NCI methods are now enabled again but only i386 has the
necessary interface code in jit/*.
leo
Luke Palmer <[EMAIL PROTECTED]> wrote:
> I notice that ParrotObject only has [get|set]_integer_keyed. I assume
> we intend to make those for the rest of the data types.
Yep. Albeit before continuing here filling the blanks, I'd really like
to have attribute naming/mangling clarified. The pmc doe
Dan Sugalski wrote:
[EMAIL PROTECTED] pbin]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-108.1)
Yeah, that was the one, unfortunately. Try disabling the JIT during
configuration and seeing if that takes care of the pro
> I didn't realize there was moderation. (How was spam getting through?)
Spam was getting through because when I upgraded RT, I didn't
re-insert some of my envelope massaging magic, which meant that spam
was looking as if it was coming from a "valid" address, when it really
wasn't.
Once I re-inse
On Jan 1, 2004, at 11:31 PM, Robert Spier wrote:
I submitted a patch yesterday to [EMAIL PROTECTED],
and received the automated response (the ID is [perl #24789]), but it
doesn't seem to have been forwarded to the mailing list. Is something
up with the tracking system?
Nothing is up. It's in the
> I submitted a patch yesterday to [EMAIL PROTECTED],
> and received the automated response (the ID is [perl #24789]), but it
> doesn't seem to have been forwarded to the mailing list. Is something
> up with the tracking system?
Nothing is up. It's in the moderation queue. The list moderator
13 matches
Mail list logo
