Dan Sugalski wrote:
[sniping to reduce verbiage]
The issue is that the PMC's original vtable assumes (and should, IMHO
be _able_ to assume) that it has total control over the PMC's data,
Well... I think I'll disagree here. The *class* vtable can assume this.
However that doesn't mean that any r
On Fri, 23 Jan 2004 [EMAIL PROTECTED] wrote:
> The subject says it all.
>
> As parrot is designed to be targetted by many langauges,
> how will it handle 'eval' opcodes for those different languages?
>
> Shell out to a seperate process?
You could do that, or you can provide a C-based
compiler as
The subject says it all.
As parrot is designed to be targetted by many langauges,
how will it handle 'eval' opcodes for those different languages?
Shell out to a seperate process?
Nigel.
Robert~
You can close the following tickets
24848
24840
22281
21988
Matt
My most recent "get tcl working again" error was in fact, the result of
a bad jump, as Leo suggested. Of course, that jump was never made
before, and in trying to track down why I was hitting an error
condition I hadn't before, I realized that I had a few
non-calling-convention subs near where
I'm also concerned by those timings that leo posted.
0.0001 vs 0.0005 ms on a set- that magnitude of locking overhead
seems pretty crazy to me.
It seemed like a few people have said that the JVM style of locking
can reduce this, so it seems to me that it merits some serious
consideration, even
Dan Sugalski wrote:
Last chance to get in comments on the first half of the proposal. If
it looks adequate, I'll put together the technical details (functions,
protocols, structures, and whatnot) and send that off for
abuse^Wdiscussion. After that we'll finalize it, PDD the thing, and
get the
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:28 AM +0100 1/22/04, Leopold Toetsch wrote:
>>And mainly the return convention are still broken.
> I thought those were fixed.
Not yet.
> ... There's no difference between calling and
> return conventions
To be done.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I'm finding parrot's killing its memory pools somewhere and dying
> when it goes to compact memory during a GC sweep.
Yep. See also "Memory corruption" by Steve Fink and my f'ups.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The only tricky bit comes in with the examination of the root set of
> other threads--accessing the hardware register contents of another
> running thread may be... interesting. (Which, I suppose, argues for
> some sort of volatile marking of the temp vari
> Is there any way to get RT to close tickets (or change their status)
> entirely via e-mail? That'd make this a lot easier if we could throw
> a:
> RT-Status: Closed
> or something like it in the reply to a bug report that notes the bug
> has been fixed.
I could implement this, but there are a
On Thu, 2004-01-15 at 09:16, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > If that's living in an managedstruct, then accessing the struct
> > elements should be as simple as:
>
> > set I0, P20['bar']
> > set S1, P20['plugh']
> > set P20['baz'], 15
>
> That's
Duh. Rereading that I can see I got my numbers in a twist. I've been
adding them where missing.
On 22 Jan 2004, at 19:39, Dan Sugalski wrote:
At 2:06 PM +0100 1/19/04, Michael Scott wrote:
Some files have CVS version $Id strings, some don't.
While tidying up the documentation I'm visiting every
Yep. I bounced Sam's comment around in my head for a while until I saw
that I was only putting them in for my own current convenience - makes
it easier to see what I'm doing as I'm doing it - so they won't be
there. Minimal is best. And anyway who wants to be "SO 20th century".
Mike
On 22 Jan
Last chance to get in comments on the first half of the proposal. If
it looks adequate, I'll put together the technical details
(functions, protocols, structures, and whatnot) and send that off for
abuse^Wdiscussion. After that we'll finalize it, PDD the thing, and
get the implementation in and
At 8:37 AM -0500 1/19/04, Benjamin K. Stuhl wrote:
Luke Palmer wrote:
Benjamin K. Stuhl writes:
Other than the special case of :readonly, can you give me an example
of when you'd need to, rather than simply writing a PMC class that
inherits from some base? I'm having trouble thinking of an exampl
At 12:10 PM +0100 1/22/04, Leopold Toetsch wrote:
I have converted that one now into a static constant string, but
this isn't a solution.
We have discussed already a few times, what to do with such constant
strings, e.g. declare them static with some macro tricks or use a
string hash. We need a
At 3:25 PM -0800 1/20/04, Robert Spier wrote:
(FYI, for the future, I may not ack all the changes, although it
depends how many there are.)
Is there any way to get RT to close tickets (or change their status)
entirely via e-mail? That'd make this a lot easier if we could throw
a:
RT-Status: Clos
At 2:52 PM +0100 1/17/04, Elizabeth Mattijsen wrote:
Don't know why you thgink it would be fetched 3 times, but as using
tied variables in Perl 5, a fetch is done _everytime_ the value of
the tied variable is needed.
You misunderstand. I'm talking about fetching the PMC for the
variable *out of
At 2:06 PM +0100 1/19/04, Michael Scott wrote:
Some files have CVS version $Id strings, some don't.
While tidying up the documentation I'm visiting every file. I can either:
1) add them when missing
2) remove them when present
3) do nothing
I was inclined to (1) until I reflected that it did pres
At 4:59 PM -0800 1/19/04, Dave Whipp wrote:
"Dan Sugalski" <[EMAIL PROTECTED]> wrote:
=head2 Guarantees
Maybe this isn't strictly a threading thing, but are we going to make any
guarantees about event orderings? For example, will we guarantee that a
sequence of events send from one thread to anoth
At 10:42 AM +0100 1/21/04, Michael Scott wrote:
Perhaps the most controversial feature of all this is that I'm using
rows of 80 '#'s as visual delimiters to distinguish documentation
sections from code.
Please don't. If you really, really must, chop it down to 60 or so
characters. 80 may wrap in
At 10:28 AM +0100 1/22/04, Leopold Toetsch wrote:
Steve Fink <[EMAIL PROTECTED]> wrote:
I did a cvs update, and it looks like imcc doesn't properly return
integers anymore from nonprototyped routines.
I don't even know if this is allowed. But anyway, if the call is non
prototyped, native types s
At 2:15 PM -0500 1/21/04, Matt Fowles wrote:
All~
So, lets do the classes as:
*) Array - fixed-size, mixed-type array
*) vPArray - variable-sized PMC array
*) PArray - Fixed-size PMC array
*) vSArray - variable-sized string array
*) SArray - fixed-size string array
I suggest using "Array" to mean
[Note to everyone -- I'm digging through my mail so be prepared for a
potential set of responses to things that're already answered...]
At 6:37 PM -0500 1/19/04, Gordon Henriksen wrote:
Dan Sugalski wrote:
For a copying collector to work, all the mutators must be blocked,
and arguably all reade
At 12:15 AM +0100 1/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ No Guarantees WRT data access }
... seems to indicate that even whole ops like add P,P,P are atomic.
Yep. They have to be, because they need to guarantee the integrity of
the pmc structures and the data
>Even if that works, PASM tests shouldn't be in t/src but in t/pmc/io.t.
Sorry, I didn't know that.
The attached patch is for t/pmc/io.t
>leo
Thanks,
Arvindh
biotests2.patch
Description: biotests2.patch
This e-mail and any files transmitted with it are for the sole use of the intended
recipie
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #25233]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=25233 >
I'm finding parrot's killing its memory pools somewhere and dying
when it goes to compa
# New Ticket Created by "Tamilmani, Arvindh Rajesh (Cognizant)"
# Please include the string: [perl #25232]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=25232 >
The attached patch
a) fixes bugs in reading a larger chunk w
On Thu, Jan 22, 2004 at 07:56:51AM -0500, Michal Wallace wrote:
>
> > I did something like this:
> >
> > $ make -C dynclasses
> > $ cp dynclasses/pisequence.so blib/lib/libpisequence.so
>
> Aha! I was trying to figure out how to do -lpisequence.
> It didn't occur to me to just RENAME it. :)
Perh
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> *) Array - fixed-size, mixed-type array
> Personally I'd leave Array as it is, since it does one of the things
> that we need it to do.
Array isn't really mixed-typed. It has methods to store or retrieve
non-PMC types, but they are converted internally t
Arvindh Rajesh Tamilmani <[EMAIL PROTECTED]> wrote:
> name="biotests.patch"
Something is wrong with these tests: patching t/src/io.t and PASM code.
Even if that works, PASM tests shouldn't be in t/src but in t/pmc/io.t.
leo
On Thu, 22 Jan 2004, Leopold Toetsch wrote:
> Michal Wallace <[EMAIL PROTECTED]> wrote:
>
> > I'm trying to make a dynamically loaded PMC that
> > subclasses another dynamically loaded PMC.
>
> Its a linker problem, but not too simple. Your analysis is correct:
> pistring needs the symbol Parrot_P
Running parrot built with --gc=libc works fine, all tests pass *except*
t/pmc/pmc_62 when --gc-debug is set.
I could track this down until here:
classes/default.c:
static void
check_set_std_props(Parrot_Interp interp, PMC *pmc, STRING *key, PMC *value)
{
if (!string_compare(interp, key, str
Steve Fink <[EMAIL PROTECTED]> wrote:
> I did a cvs update, and it looks like imcc doesn't properly return
> integers anymore from nonprototyped routines.
I don't even know if this is allowed. But anyway, if the call is non
prototyped, native types should go into P3. So you have the overhead of
P
Michal Wallace <[EMAIL PROTECTED]> wrote:
> Hi all,
> I'm hoping this is just a simple linker option, but
> I've been reading "ld" manuals for the past few
> hours and I just don't get it. :)
> I'm trying to make a dynamically loaded PMC that
> subclasses another dynamically loaded PMC.
Its a l
36 matches
Mail list logo
