On Tue, 9 Sep 2003, Gordon Henriksen wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 9 Sep 2003, Gordon Henriksen wrote:
> >
> > > Random thought
> > >
> > > There's some discussion on perl-qa right now about how Test::More
> > > should implement "is_deeply", which executes a
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Tue, 9 Sep 2003, Gordon Henriksen wrote:
>
> > Random thought
> >
> > There's some discussion on perl-qa right now about how Test::More
> > should implement "is_deeply", which executes a code block and tests
> > that the return value is equivalent
Garrett Goebel wrote:
> Nicholas Clark wrote:
> > Garrett Goebel wrote:
> > > Leopold Toetsch wrote:
> > > > Garrett Goebel <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > As I was googling to see how other people have approached
> > > > > these problems I ran across:
> > > >
> > > > > http://blogs
Nicholas Clark wrote:
> Garrett Goebel wrote:
> > Leopold Toetsch wrote:
> > > Garrett Goebel <[EMAIL PROTECTED]> wrote:
> > >
> > > > As I was googling to see how other people have approached
> > > > these problems I ran across:
> > >
> > > > http://blogs.gotdotnet.com/cbrumme/CategoryView.aspx
On Tue, 9 Sep 2003, Gordon Henriksen wrote:
> Random thought
>
> There's some discussion on perl-qa right now about how Test::More should
> implement "is_deeply", which executes a code block and tests that the
> return value is equivalent to a particular nested data structure. (The
> question
Random thought
There's some discussion on perl-qa right now about how Test::More should
implement "is_deeply", which executes a code block and tests that the
return value is equivalent to a particular nested data structure. (The
question posed on that list is with regard to how to handle tie()
On Monday, September 8, 2003, at 03:34 , Steve Fink wrote:
On Sep-08, Leopold Toetsch wrote:
I don't know why Storable.xs is using a general HV for mapping an
address to an integer (more isn't needed to serialize all IMHO - Dan's
next_for_GC approach doesn't provide more info). Perl5 does conve
Steve Fink <[EMAIL PROTECTED]> wrote:
> On Sep-08, Leopold Toetsch wrote:
>> Parrot has some DOD counters for possibly active PMCs. A simple and
>> probably fix-sized[1] hash based on such a count with just a mapping of
>> {&pmc => id} takes 12 bytes per entry on 32-bit architecures and its
>> rea
On Sunday, September 7, 2003, at 01:41 , Dan Sugalski wrote:
At 8:56 PM -0600 9/4/03, Luke Palmer wrote:
Gordon Henriksen writes:
What you're suggesting also has significant side-effects: It halts
hypothetical multithreaded programs, suspends DoD, prevents the
traversal mechanism from callin
On Sunday, September 7, 2003, at 06:21 , Nicholas Clark wrote:
On Fri, Sep 05, 2003 at 09:34:04AM -0400, Dan Sugalski wrote:
On Fri, 5 Sep 2003, Peter Haworth wrote:
With the seen hash approach, I wouldn't expect the hash itself to
take nearly as much space as the frozen structure;
My experienc
On Sep-08, Leopold Toetsch wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > On Fri, Sep 05, 2003 at 09:34:04AM -0400, Dan Sugalski wrote:
> >> On Fri, 5 Sep 2003, Peter Haworth wrote:
>
> >> > With the seen hash approach, I wouldn't expect the hash itself to take
> >> > nearly as much space
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 05, 2003 at 09:34:04AM -0400, Dan Sugalski wrote:
>> On Fri, 5 Sep 2003, Peter Haworth wrote:
>> > With the seen hash approach, I wouldn't expect the hash itself to take
>> > nearly as much space as the frozen structure;
>>
>> My experience t
On Fri, Sep 05, 2003 at 09:34:04AM -0400, Dan Sugalski wrote:
> On Fri, 5 Sep 2003, Peter Haworth wrote:
> > With the seen hash approach, I wouldn't expect the hash itself to take
> > nearly as much space as the frozen structure;
>
> My experience tracing variable graphs in Perl 5 indicates othe
At 8:56 PM -0600 9/4/03, Luke Palmer wrote:
Gordon Henriksen writes:
What you're suggesting also has significant side-effects: It halts
hypothetical multithreaded programs, suspends DoD, prevents the
traversal mechanism from calling back into parrot code, requires
fine-grained locks which are e
On Thu, Sep 04, 2003 at 08:43:50AM -0500, Garrett Goebel wrote:
> Leopold Toetsch wrote:
> > Garrett Goebel <[EMAIL PROTECTED]> wrote:
> >
> > > As I was googling to see how other people have approached
> > > these problems I ran across:
> >
> > > http://blogs.gotdotnet.com/cbrumme/CategoryView.
On Fri, 5 Sep 2003, Peter Haworth wrote:
> On Thu, 4 Sep 2003 09:02:18 -0400 (EDT), Dan Sugalski wrote:
> > On Wed, 3 Sep 2003, Gordon Henriksen wrote:
> > > A seen hash is also threadsafe, can be interrupted by DoD, and is safe
> > > for recursion. (By "threadsafe," I mean that unchanged data str
On Thu, 4 Sep 2003 09:02:18 -0400 (EDT), Dan Sugalski wrote:
> On Wed, 3 Sep 2003, Gordon Henriksen wrote:
> > A seen hash is also threadsafe, can be interrupted by DoD, and is safe
> > for recursion. (By "threadsafe," I mean that unchanged data structures
> > can be safely serialized from multiple
On Thursday, September 4, 2003, at 10:56 , Luke Palmer wrote:
Is there a problem with providing a mechanism which would suspend all
threads except for the "current" one, as to ensure that the serialize
operates, er, serially. Could it be implemented with a top-priority
event post that acquires
Luke Palmer:
# Is there a problem with providing a mechanism which would suspend all
# threads except for the "current" one, as to ensure that the serialize
# operates, er, serially. Could it be implemented with a top-priority
# event post that acquires a global lock?
What about the thread that d
Gordon Henriksen writes:
(B> What you're suggesting also has significant side-effects: It halts
(B> hypothetical multithreaded programs, suspends DoD, prevents the
(B> traversal mechanism from calling back into parrot code, requires
(B> fine-grained locks which are extremely expensive and have
Dan Sugalski wrote:
> Note that a seen hash isn't particularly threadsafe here, at least not
> in any useful way, since we have to make sure the structure we're
> traversing doesn't change during traversal or any threadsafety we put
> in is useless since we're potentially dumping corrupt data.
So
Leopold Toetsch wrote:
> Garrett Goebel <[EMAIL PROTECTED]> wrote:
>
> > As I was googling to see how other people have approached
> > these problems I ran across:
>
> > http://blogs.gotdotnet.com/cbrumme/CategoryView.aspx/CLR
>
> What did you find there, besides a description that a certain
>
On Wed, 3 Sep 2003, Gordon Henriksen wrote:
> What's a dump stream actually going to look like? E.g.,
> Fine and good. But dump must handle object graphs, which can be
> recursive or self-referential or whatnot:
>
> $a = { b => undef };
> $b = { a => $a};
> $a->{b} = $b;
> pr
Garrett Goebel <[EMAIL PROTECTED]> wrote:
> As I was googling to see how other people have approached these problems I
> ran across:
> http://blogs.gotdotnet.com/cbrumme/CategoryView.aspx/CLR
What did you find there, besides a description that a certain company
is producing b0rken software ;-)
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> Panic! Dump needs to refer to line 4 again, or else recurse! How?
Don't Panic! Here is the point, where either next_for_GC is used or the
seen hash. The former is/was used to mark (visit) PMCs. If they have
been visited, they have that pointer set els
Ok, this thread has now +45 entries, I'll try to summarize the
proposed PMC traversal schemes.
0) As the subject still applies ;-) we want to be able to dump() or
pretty_print() a PMC (and possibly aggregate members of that). This
turns out to be a special case of a deep traversal over nested PMCs
What's a dump stream actually going to look like? E.g.,
$a = [1, 2, 3];
print dump($a);
1: PMC PerlArray
2: 3 # element count
3: PMC PerlInt# [0]
4: 1 # value
5: PMC PerlInt# [1]
6: 2 # value
7: PMC PerlInt# [2]
8: 3 #
Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Wed, 3 Sep 2003, Leopold Toetsch wrote:
>
> >> Then we might get deadlocks.
>
> > This is always a possibility, and there isn't anything we
> > can do about it at the interpreter level. Deadlocks are
> > an unfortunate fact
On Wed, 3 Sep 2003, Brent Dax wrote:
> Dan Sugalski:
> # It's impossible to have clone in a threaded environment guarantee that
> it
> # won't deadlock.
>
> If I recall correctly, all shared variables are owned by a single shared
> interpreter.
Nope. Shared variables are owned by their creating
Dan Sugalski:
# It's impossible to have clone in a threaded environment guarantee that
it
# won't deadlock.
If I recall correctly, all shared variables are owned by a single shared
interpreter. What if, the first time the traversal encounters a shared
PMC, it gets a lock on the shared interpreter
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Wed, 3 Sep 2003, Leopold Toetsch wrote:
>
> >> Then we might get deadlocks.
>
> > This is always a possibility, and there isn't anything we can do about it
> > at the interpreter level. Deadlocks are an u
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Wed, 3 Sep 2003, Leopold Toetsch wrote:
>> Then we might get deadlocks.
> This is always a possibility, and there isn't anything we can do about it
> at the interpreter level. Deadlocks are an unfortunate fact of life in a
> threaded environment.
clon
On Wed, Sep 03, 2003 at 02:07:10PM -0400, Dan Sugalski wrote:
> On Wed, 3 Sep 2003, Leopold Toetsch wrote:
>
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > On Wed, 3 Sep 2003, Leopold Toetsch wrote:
> >
> > >> But if one thread sets pmc->next_for_GC the next thread might encounter
> > >> this
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Wed, 3 Sep 2003, Leopold Toetsch wrote:
>
> >> But if one thread sets pmc->next_for_GC the next thread might encounter
> >> this PMC later (albeit for this thread at the first time) and think, I've
> >> vi
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Wed, 3 Sep 2003, Leopold Toetsch wrote:
>> But if one thread sets pmc->next_for_GC the next thread might encounter
>> this PMC later (albeit for this thread at the first time) and think, I've
>> visited this PMC already and just flush out the object ID
On Wed, 3 Sep 2003, Leopold Toetsch wrote:
> K Stol <[EMAIL PROTECTED]> wrote:
>
> > just a thought: aren't shared objects/data/whatever protected by a
> > mutex? To me, that's the obvious solution for accessing shared data.
> > As I said, just a thought.
>
> They will be protected by a mutex ye
K Stol <[EMAIL PROTECTED]> wrote:
> just a thought: aren't shared objects/data/whatever protected by a
> mutex? To me, that's the obvious solution for accessing shared data.
> As I said, just a thought.
They will be protected by a mutex yes. That helps against two threads
updating the same PMC at
- Original Message -
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
To: "Peter Haworth" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, September 03, 2003 4:38 PM
Subject: Re: [RfC] vtable->dump
> Peter Haworth <[EMAIL PROTECTED
Peter Haworth <[EMAIL PROTECTED]> wrote:
> On Wed, 3 Sep 2003 09:24:22 +0200, Leopold Toetsch wrote:
>> One general traverse() vtable is just the simpler interface IMHO.
>>
>> Running through each aggregate just once plus updating a seen_hash seems
>> simpler and faster to me and doesn't have any n
On Wed, 3 Sep 2003 09:24:22 +0200, Leopold Toetsch wrote:
> One general traverse() vtable is just the simpler interface IMHO.
>
> Running through each aggregate just once plus updating a seen_hash seems
> simpler and faster to me and doesn't have any negative impact on PMC size
> and DOD speed.
An
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
[ optimize DOD before thaw/clone ]
> Even with a depth restriction, a recursive estimate can produce
> misleading results due to circular references. Only actually walking
> the structure can get the number right. However, wa
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:38 PM +0200 9/2/03, Leopold Toetsch wrote:
[ next_for_GC ]
> That's easy, then, as it is. :) Besides, from looking at pobj.h, it's
> already there, so I'm not sure what we'd need to do. Perhaps I need
> to resync.
The PMC_EXT structure is only alloca
At 8:38 PM +0200 9/2/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Every PMC should have a next_for_GC pointer. You moved it to the ext
structure, ...
I moved it there for a good reason: speed. The smaller a PMC the faster
is the interpreter.
Right, and this part is only nee
Leopold Toetsch wrote:
[snip]
> [1] when we want to thaw/clone big structures, we should have some means
> to estimate the amount of needed headers. If we will not have enough, we
> do a DOD run before clone/thaw and then turn DOD off - it will not yield
> any more free headers anyway. This can avo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Every PMC should have a next_for_GC pointer. You moved it to the ext
> structure, ...
I moved it there for a good reason: speed. The smaller a PMC the faster
is the interpreter.
> ... but it's there, and they all ought to have one. Any PMC that
> gets fr
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > Doing the walk is *also* easy. You clear the next PMC pointer, just as
> > with a normal DOD run setup. call the DOD mark on the inital PMC
>
> there is no mark() for a plain PMC scalar (and no next pointe
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Doing the walk is *also* easy. You clear the next PMC pointer, just as
> with a normal DOD run setup. call the DOD mark on the inital PMC
there is no mark() for a plain PMC scalar (and no next pointer inside
the PMC). If the PMC has a mark routine this ca
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Tue, 2 Sep 2003, Leopold Toetsch wrote:
>
> >> So if it was mark()ed already we return. That's not possible for freeze,
> >> thaw, dump, clone whatever. These must keep track of already visited
> >> object
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Tue, 2 Sep 2003, Leopold Toetsch wrote:
>> So if it was mark()ed already we return. That's not possible for freeze,
>> thaw, dump, clone whatever. These must keep track of already visited
>> objects via an hash for freeze, dump, clone, and via an ID arr
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Tue, 2 Sep 2003, Leopold Toetsch wrote:
>
> >> and no, not that one inside DOD, that one doesn't handle duplicates.
>
> > Yes, yes it *does* handle duplicates. Otherwise it'd get caught in
> > infinite lo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Tue, 2 Sep 2003, Leopold Toetsch wrote:
>> and no, not that one inside DOD, that one doesn't handle duplicates.
> Yes, yes it *does* handle duplicates. Otherwise it'd get caught in
> infinite loops every time it came across a circular data structure. T
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
> and no, not that one inside DOD, that one doesn't handle duplicates.
Yes, yes it *does* handle duplicates. Otherwise it'd get caught in
infinite loops every time it came across a circular data structure. That's
what the next pointer in the PObj heade
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Further: having clone implemented in terms of freeze + thaw needs
>> additional memory for the intermediate frozen image. Isn't that
>> suboptimal?
> Only slightly -- It's just *one single* PMC's data that's stored in that
>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:37 PM +0200 8/29/03, Leopold Toetsch wrote:
>>Aren't you saying the opposite of above here? I want to be able to
>>traverse from a given start point (being it the own interpreter or some
>>PMC) as deeply down as there is something. You did say, that w
At 6:37 PM +0200 8/29/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
On Fri, 29 Aug 2003, Leopold Toetsch wrote:
I think, we need a general solution for freeze, dump and clone. As shown
the latter is broken. That would be IMHO an iterator interface with a
callback function
At 12:03 PM +0200 8/31/03, Leopold Toetsch wrote:
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
class freezer {
class thawer {
class cloner {
[ big snip ]
Do you expect that these are overridden by some languages using parrot?
I.e. that ponie tries to implement a freezer that writes out
Leopold Toetsch wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> >class freezer {
> >class thawer {
> >class cloner {
>
> [ big snip ]
>
> Do you expect that these are overridden by some languages using parrot?
> I.e. that ponie tries to implement a freezer that writes outpu
Nicholas Clark wrote:
>
> On Sat, Aug 30, 2003 at 10:13:02PM -0400, Benjamin Goldberg wrote:
> > Nicholas Clark wrote:
>
> > > The attacker can craft a bogus CGITempFile object that refers to any
> > > file on the system, and when this object is destroyed it will attempt to
> > > delete that fi
On Sat, Aug 30, 2003 at 10:13:02PM -0400, Benjamin Goldberg wrote:
> Nicholas Clark wrote:
> > The attacker can craft a bogus CGITempFile object that refers to any
> > file on the system, and when this object is destroyed it will attempt to
> > delete that file at whatever privilege level the CGI
On Sun, Aug 31, 2003 at 12:03:48PM +0200, Leopold Toetsch wrote:
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> >class freezer {
> >class thawer {
> >class cloner {
>
> [ big snip ]
>
> Do you expect that these are overridden by some languages using parrot?
> I.e. that ponie tries t
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>class freezer {
>class thawer {
>class cloner {
[ big snip ]
Do you expect that these are overridden by some languages using parrot?
I.e. that ponie tries to implement a freezer that writes output for
Storable?
Further: having clone imple
Nicholas Clark wrote:
>
> On Fri, Aug 29, 2003 at 05:30:37PM +0200, Leopold Toetsch wrote:
>> I think, we need a general solution for freeze, dump and clone. As
>> shown
>
> I don't know if this is relevant here, but I'll mention it in case.
> For perl5 there isn't a single good generic clone sys
Leopold Toetsch wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > Actually, I think the following interface would be better:
>
> >void freeze(PMC *freezer);
> >void thaw (PMC *thawer);
>
> I'm thinking of (in horrible pseudo code ;-):
[snip]
> Above functionality does IMHO mat
On Saturday, August 30, 2003, at 07:59 , Nicholas Clark wrote:
You can't trust you data deserialiser. It can do evil on you before it
returns.
It's not the deserializer that you can't trust—it's the data. Of course
it's a security nightmare to deserialize data from an untrusted source.
That doe
On Fri, Aug 29, 2003 at 05:30:37PM +0200, Leopold Toetsch wrote:
> I think, we need a general solution for freeze, dump and clone. As shown
I don't know if this is relevant here, but I'll mention it in case.
For perl5 there isn't a single good generic clone system. Probably the
best (in terms of q
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Actually, I think the following interface would be better:
>void freeze(PMC *freezer);
>void thaw (PMC *thawer);
I'm thinking of (in horrible pseudo code ;-):
typedef struct {
size_t action_func_nr; // clone, freeze, thaw, dump
Dan Sugalski wrote:
>
> On Fri, 29 Aug 2003, Leopold Toetsch wrote:
>
>> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>> I think we'd be better served getting the freeze/thaw stuff in and
>>
>> We were just discussing this in the f'up.
>
> I read those, but I wanted to make sure the discussion went
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Fri, 29 Aug 2003, Leopold Toetsch wrote:
>> I think, we need a general solution for freeze, dump and clone. As shown
>> the latter is broken. That would be IMHO an iterator interface with a
>> callback function taking and returning a void*.
> Right, wh
On Fri, 29 Aug 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Fri, 29 Aug 2003, Leopold Toetsch wrote:
> >> Pluggable implies a dump() vtable method, doesn't it?
>
> > Nope. Pluggable implies freezethaw.c provides all the functionality to
> > freeze or thaw a PMC, w
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I think we'd be better served getting the freeze/thaw stuff in and
We were just discussing this in the f'up.
> teaching the debugger how to dump a frozen PMC. This'll get us two
> benefits:
> 1) We'll have a single way to dump a PMC rather than two
> 2)
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Fri, 29 Aug 2003, Leopold Toetsch wrote:
>> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>
>> We were just discussing this in the f'up.
> I read those, but I wanted to make sure the discussion went this way. :)
Fine :-)
>> Pluggable implies a dump() vtab
On Fri, 29 Aug 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > I think we'd be better served getting the freeze/thaw stuff in and
>
> We were just discussing this in the f'up.
I read those, but I wanted to make sure the discussion went this way. :)
> > If we make the
On Fri, 29 Aug 2003, Leopold Toetsch wrote:
> Tracing through Parrot programs shows the type and value of variables.
> This doesn't work very well for PMCs, trace_pmc_dump() tries to extract
> some info from the PMC, but much better would it be, if the PMC itself
> can return a string represent
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> > Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
> >> STRING* dump(INTERP, SELF, STRING *, INTVAL flags);
>
> > what is the STRING * parameter good for. I assume lineheaders.
>
> The place, where to appen
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> STRING* dump(INTERP, SELF, STRING *, INTVAL flags);
> what is the STRING * parameter good for. I assume lineheaders.
The place, where to append SELF.dump. Appending doesn't consume a new
header for each
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Tracing through Parrot programs shows the type and value of
> variables. This doesn't work very well for PMCs, trace_pmc_dump()
> tries to extract some info from the PMC, but much better would it be,
> if the PMC itself can return a string representati
Tracing through Parrot programs shows the type and value of variables.
This doesn't work very well for PMCs, trace_pmc_dump() tries to extract
some info from the PMC, but much better would it be, if the PMC itself
can return a string representation of itself.
STRING* dump(INTERP, SELF, STRING *
77 matches
Mail list logo
