Jonathan Sillito <[EMAIL PROTECTED]> wrote:
> this is just the "current continuation". In pasm this could be:
> new P1, .Continuation
> set_addr I3, returnhere
> set P1, I3
> invoke # or invoke_method
> returnhere:
> # etc ...
> With a 'cc' variant the common case is simp
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> There's no reason why the other scheme (whatever it is) can't be either
> frequent DoD runs or my hybrid refcounting/dod scheme.
Frequent DOD runs are not a problem for an average program (for some
definition of average). But when we come to ~1 milli
Randal L. Schwartz wrote:
> All I'm asking for in my quest is to keep the "install health check"
> tests down to a minute or two. Remember that CPAN.pm insists that
> "make test" works before I can install.
I agree. Modules should commonly have long-running exhaustive tests
and/or stress tests. T
> "Adrian" == Adrian Howard <[EMAIL PROTECTED]> writes:
Adrian> I don't see it as a real problem. If I've written a test I want it
Adrian> run. Otherwise I wouldn't have written it. Not running tests is pretty
Adrian> much the ultimate sin as far as I am concerned - but I'm odd that way
Adrian
This message was cancelled from within Mozilla.
Jonathan Sillito wrote:
[snip]
> -inline op invoke(in PMC) {
+inline op call(in PMC) {
>opcode_t *dest;
> - PMC * p = $1;
> -
> - dest = (opcode_t *)p->vtable->invoke(interpreter, p, expr NEXT());
> -
> + PMC * sub = $1;
> + dest = (opcode_t *)p->vtable->invoke(interpreter, sub, expr NEXT()
Jonathan Sillito wrote:
[snip]
> -inline op invoke(in PMC) {
+inline op call(in PMC) {
>opcode_t *dest;
> - PMC * p = $1;
> -
> - dest = (opcode_t *)p->vtable->invoke(interpreter, p, expr NEXT());
> -
> + PMC * sub = $1;
> + dest = (opcode_t *)p->vtable->invoke(interpreter, sub, expr NEXT()
Matt Fowles wrote:
>
> Benjamin Goldberg wrote:
> >>For more complex cases timely destruction will not be assured.
> >
> > Which is not-so-good. We'd like timely destruction *always*
> >
> > However, given that your suggestion can be implemented purely
> > through compile time behaviors, there'
Hey, thanks for the comments.
So you suggest leaving as the op as invoke? I don't mind, I just think we
should be consistent in our naming; what about having the following four
ops:
- invoke
- invokecc
- invoke_method
- invokecc_method
You also wondered about the need for the 'cc' varian
At 10:01 AM -0500 6/4/03, Garrett Goebel wrote:
From: Graham Barr [mailto:[EMAIL PROTECTED]
I may be missing something here. But within the resources of
an object may be other PMCs. As those PMCs will not be referenced
from anywhere else what is to stop the DoD run from freeing those
before it
At 9:56 AM -0500 6/4/03, Garrett Goebel wrote:
Dan Sugalski wrote:
We aren't doing refcounting. We are continuing with the current
scheme as implemented. We're not looking to do anything to change
that scheme except perhaps implementing a generational or continuous
garbage collection system.
La
From: Graham Barr [mailto:[EMAIL PROTECTED]
>
> I may be missing something here. But within the resources of
> an object may be other PMCs. As those PMCs will not be referenced
> from anywhere else what is to stop the DoD run from freeing those
> before it freed the object ?
Putting my head out o
Dan Sugalski wrote:
>
> We aren't doing refcounting. We are continuing with the current
> scheme as implemented. We're not looking to do anything to change
> that scheme except perhaps implementing a generational or continuous
> garbage collection system.
Last I checked Python used refcounting
13 matches
Mail list logo
