On Fri, 24 Oct 2003 17:33:17 +0100, Peter Haworth wrote:
> [stuff he didn't mean to send]
Sorry. Looks like I hit Send instead of Cancel.
--
Peter Haworth [EMAIL PROTECTED]
"this system is slightly less secure than putting your IP address and
root password in big letters in a 30-seco
On Fri, 24 Oct 2003, Peter Haworth wrote:
> On Tue, 21 Oct 2003 11:39:38 -0400 (EDT), Dan Sugalski wrote:
> > On Tue, 21 Oct 2003, Juergen Boemmels wrote:
> > > This is a question of what is allowed at destruction time. You don't
> > > want to allow memory allocation, but allow freezing. That gets
On Tue, 21 Oct 2003 11:39:38 -0400 (EDT), Dan Sugalski wrote:
> On Tue, 21 Oct 2003, Juergen Boemmels wrote:
> > This is a question of what is allowed at destruction time. You don't
> > want to allow memory allocation, but allow freezing. That gets hard,
> > because you need at least allocate the S
On Tue, 21 Oct 2003 13:20:34 -0400 (EDT), Dan Sugalski wrote:
> On Tue, 21 Oct 2003, Jeff Clites wrote:
> > 2) I don't see it as a huge problem that serialization code could end
> > up creating additional objects if called from a destroy() method.
>
> User code may, parrot may not. The reasons are
On Oct 21, 2003, at 8:11 AM, Juergen Boemmels wrote:
If you think about it: The call to the destructors is done after
free_unused_pobjects completed. The memory of the objects without
destructors is already freed. If you are still in an out of memory
situation when the destructors are run, then it
At 12:56 -0700 10/21/03, Clark C. Evans wrote:
On Tue, Oct 21, 2003 at 09:25:48PM +0200, Elizabeth Mattijsen wrote:
| At 15:18 -0400 10/21/03, Dan Sugalski wrote:
| >On Tue, 21 Oct 2003, Clark C. Evans wrote:
| > > If you are going to go this far (including content-length) may I
| > > just suggest
Dan/Elizabeth,
Thank you for considering my response, let me rephrase and then
I'll go back to my own list (*grins*).
On Tue, Oct 21, 2003 at 09:25:48PM +0200, Elizabeth Mattijsen wrote:
| At 15:18 -0400 10/21/03, Dan Sugalski wrote:
| >On Tue, 21 Oct 2003, Clark C. Evans wrote:
| > > If you are
On Tue, 21 Oct 2003, Clark C. Evans wrote:
> Back to the YAML list... sorry for interloping!
Ah, you weren't interloping--it is a good idea. You just managed to come
in on the other side of Good Enough today. :)
Dan
On Tue, Oct 21, 2003 at 07:41:08PM +0200, Elizabeth Mattijsen wrote:
| If you ask me, you could do easy with a simple header line like:
|
| parrot xml 1.0
| \0
|
| basically magic word ('parrot')
| followed by a space
| followed by the type
| followed by a space
| followed by version
| f
At 15:18 -0400 10/21/03, Dan Sugalski wrote:
On Tue, 21 Oct 2003, Clark C. Evans wrote:
> If you are going to go this far (including content-length) may I
> just suggest using a MIME envelope? This has several advantages:
This is a very good idea, but not this time, as it's too easy to get stuck
On Tue, 21 Oct 2003, Clark C. Evans wrote:
> If you are going to go this far (including content-length) may I
> just suggest using a MIME envelope? This has several advantages:
This is a very good idea, but not this time, as it's too easy to get stuck
in the endless churn of very good ideas and
On Tue, 21 Oct 2003, Clark C. Evans wrote:
> On Tue, Oct 21, 2003 at 09:12:27AM -0400, Dan Sugalski wrote:
> | We're talking about the first thing in a file (or stream, or whatever). I
> | was under the impression that XML files should be entirely composed of
> | valid XML, hence the need for the
On Tue, Oct 21, 2003 at 09:12:27AM -0400, Dan Sugalski wrote:
| We're talking about the first thing in a file (or stream, or whatever). I
| was under the impression that XML files should be entirely composed of
| valid XML, hence the need for the stream type marker being valid XML. YAML
| doesn't c
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Tue, 21 Oct 2003, Jeff Clites wrote:
>> 1) Serialization traversals need to "take note" of logical int and
>> float slots
> That's not an issue for us. A PMC is responsible for serializing itself,
> so if its got a string, float, or int component then
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> So, in a nutshell, throwing an XML format type tag at the beginning buys
> us nothing regardless of whether it's an XML stream or not?
Yes. That's what people say :)
What about a well known format called PBC. (Parrot bortable^Wbyte code :)
It knows about
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Tue, 21 Oct 2003, Juergen Boemmels wrote:
>> You know we already have two versions of pobject_lives lying around.
> Then we need to fix that, too.
One is with ARENA_DOD_FLAGS one w/o. If you are trying to implement your
universal mark() for everything
At 13:49 -0400 10/21/03, Dan Sugalski wrote:
On Tue, 21 Oct 2003, Elizabeth Mattijsen wrote:
> Yep. But mainly I think because you'll need to encode binary data to
> make it valid XML. That's on overhead you don't to suffer for those
> serialization that don't need it.
I had it in mind that th
At 12:53 -0400 10/21/03, Dan Sugalski wrote:
> Yeah, if you're just needing to tag the stream with a label to indicate
the type plus a version number, then xml's on the one hand overkill and
> on the other hand not necessarily a big help to xml proponents.
So, in a nutshell, throwing an XML form
At 08:21 -0400 10/21/03, Dan Sugalski wrote:
> I find the notion of an "XML header" a bit confusing, given Dan's
statement to the effect that it was a throw to XML folks.
I think anything "XML folks" will be interested in will entail
*wrapping* stuff, not *prefixing* it.
Nah, I expect what the
On Tue, 21 Oct 2003, Elizabeth Mattijsen wrote:
> At 13:49 -0400 10/21/03, Dan Sugalski wrote:
> >On Tue, 21 Oct 2003, Elizabeth Mattijsen wrote:
> Hmmm... maybe as an optimilization, something that would fit in 4 or
> 8 bytes would be better for the magic string (so a single or double
> integer c
On Oct 21, 2003, at 10:49 AM, Dan Sugalski wrote:
On Tue, 21 Oct 2003, Elizabeth Mattijsen wrote:
At 12:53 -0400 10/21/03, Dan Sugalski wrote:
Yeah, if you're just needing to tag the stream with a label to
indicate
the type plus a version number, then xml's on the one hand
overkill and
on the
On Oct 21, 2003, at 10:41 AM, Elizabeth Mattijsen wrote:
At 12:53 -0400 10/21/03, Dan Sugalski wrote:
> Yeah, if you're just needing to tag the stream with a label to
indicate
the type plus a version number, then xml's on the one hand overkill
and
> on the other hand not necessarily a big hel
On Tue, 21 Oct 2003, Elizabeth Mattijsen wrote:
> At 12:53 -0400 10/21/03, Dan Sugalski wrote:
> > > Yeah, if you're just needing to tag the stream with a label to indicate
> >> the type plus a version number, then xml's on the one hand overkill and
> > > on the other hand not necessarily a big
On Tue, 21 Oct 2003, Jeff Clites wrote:
> I don't believe that is quite true. There are a couple of important
> differences between traversal-for-GC and traversal-for-serialization,
> which will be a challenge to reconcile in the one-true-traversal:
>
> 1) Serialization traversals need to "take no
> Yeah, if you're just needing to tag the stream with a label to indicate
> the type plus a version number, then xml's on the one hand overkill and
> on the other hand not necessarily a big help to xml proponents.
So, in a nutshell, throwing an XML format type tag at the beginning buys
us nothing
On Oct 21, 2003, at 6:12 AM, Dan Sugalski wrote:
On Tue, 21 Oct 2003, Elizabeth Mattijsen wrote:
At 08:21 -0400 10/21/03, Dan Sugalski wrote:
I find the notion of an "XML header" a bit confusing, given Dan's
statement to the effect that it was a throw to XML folks.
I think anything "XML folks"
Melvin Smith <[EMAIL PROTECTED]> wrote:
>> Albeit I'm not convinced, that we can't have a seen hash.
> A seen hash most likely would:
> 1) Kill GC performance especially in pathological cases. The GC
>should be quiet and invisible.
> 2) Cause memory usage to double upon a mark run.
GC isn't
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Tue, 21 Oct 2003, Leopold Toetsch wrote:
>> You can append items to the constant table. You can't declare existing
>> items as constant, because you can't change the underlying object pool,
>> where the object was allocated. This would change the object
On Oct 21, 2003, at 5:53 AM, Dan Sugalski wrote:
Note that I do *not* want to have multiple object traversal systems
in
parrot! We have one for DOD, and proposals have ranged upwards from
there.
No. That is *not* happening--the chance for error is significant, the
side-effects of the error annoy
On Tue, 21 Oct 2003, Juergen Boemmels wrote:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > > > The chill and warm runtime methods take a PMC or a frozen representation
> > > > of a PMC (respectively) and provide a human readable version of that PMC.
> > >
> > > I dunno, why chill() is
Dan Sugalski <[EMAIL PROTECTED]> writes:
[...]
> > > The chill and warm runtime methods take a PMC or a frozen representation
> > > of a PMC (respectively) and provide a human readable version of that PMC.
> >
> > I dunno, why chill() is superior to dump() or pretty_print(), but the
> > name does
On Tue, 21 Oct 2003, Leopold Toetsch wrote:
> Albeit I'm not convinced, that we can't have a seen hash.
A seen hash most likely would:
1) Kill GC performance especially in pathological cases. The GC
should be quiet and invisible.
2) Cause memory usage to double upon a mark run.
-Melvin
On Tue, 21 Oct 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Tue, 21 Oct 2003, Leopold Toetsch wrote:
>
> [ thaw ]
>
> >> This should IMHO be able to create constant PMCs out of metadata, e.g.
> >> for subroutine objects. So there should be some means to tell thaw()
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Tue, 21 Oct 2003, Leopold Toetsch wrote:
[ thaw ]
>> This should IMHO be able to create constant PMCs out of metadata, e.g.
>> for subroutine objects. So there should be some means to tell thaw() to
>> create PMC(s) in the constant_pmc_pool.
> There s
On Tue, 21 Oct 2003, Elizabeth Mattijsen wrote:
> At 08:21 -0400 10/21/03, Dan Sugalski wrote:
> > > I find the notion of an "XML header" a bit confusing, given Dan's
> >> statement to the effect that it was a throw to XML folks.
> >>
> >> I think anything "XML folks" will be interested in will
On Tue, 21 Oct 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > Since this has come up again, ...
>
> [ FYI: I was starting implementing this, based on a general traverse
>vtable with callback functions. Two patches got backed out by
>Dan after some discus
On Mon, 20 Oct 2003, Gregor N. Purdy wrote:
>
> > the xml header is only for the top level thing in the serialized
> > tree. if it is nonstandard you have to mark the serialized string so you
> > can call the matching thaw methods. each object in the serialized tree
> > will have to support that m
On Mon, 20 Oct 2003, Melvin Smith wrote:
> At 04:38 PM 10/20/2003 -0400, Dan Sugalski wrote:
> >The encoding methods for freezing (and corresponding decoding methods for
> >thawing) may be overridden to provide an alternate serialization format.
> >The only requirement of the serialziation format
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> > 1) Freezing at the destruction level may *not* use any additional memory
> > for object traversal
This is a really hard problem. In some early experiments with
destruction ordering (one of the problems wich need iteration) I
didn't get around
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Since this has come up again, ...
[ FYI: I was starting implementing this, based on a general traverse
vtable with callback functions. Two patches got backed out by
Dan after some discussion in PM ]
> ... and it's apparent that the last time
On Oct 20, 2003, at 10:09 PM, Gregor N. Purdy wrote:
Here's an example of a wrapper:
That's a bit better, although bear in mind that if the intent is that
you could throw the entire chunk at an XML parser and have it not
complain, you are going to have to take some care in generating t
> the xml header is only for the top level thing in the serialized
> tree. if it is nonstandard you have to mark the serialized string so you
> can call the matching thaw methods. each object in the serialized tree
> will have to support that method or some code has to be supplied to
> handle all
At 09:56 PM 10/20/2003 -0400, Uri Guttman wrote:
> "MS" == Melvin Smith <[EMAIL PROTECTED]> writes:
MS> That answers my question of overhead with regards to XML headers.
MS> If there is a single header for defining the type of "stream" then the
MS> actual serialization can be dense enoug
> "MS" == Melvin Smith <[EMAIL PROTECTED]> writes:
MS> That answers my question of overhead with regards to XML headers.
MS> If there is a single header for defining the type of "stream" then the
MS> actual serialization can be dense enough.
MS> I just needed clarification. :)
well,
At 08:41 PM 10/20/2003 -0400, Uri Guttman wrote:
> "MS" == Melvin Smith <[EMAIL PROTECTED]> writes:
MS> At 04:38 PM 10/20/2003 -0400, Dan Sugalski wrote:
>> The encoding methods for freezing (and corresponding decoding
methods for
>> thawing) may be overridden to provide an alternate se
> "MS" == Melvin Smith <[EMAIL PROTECTED]> writes:
MS> At 04:38 PM 10/20/2003 -0400, Dan Sugalski wrote:
>> The encoding methods for freezing (and corresponding decoding methods for
>> thawing) may be overridden to provide an alternate serialization format.
>> The only requirement of t
At 04:38 PM 10/20/2003 -0400, Dan Sugalski wrote:
The encoding methods for freezing (and corresponding decoding methods for
thawing) may be overridden to provide an alternate serialization format.
The only requirement of the serialziation format is that it starts with a
minimally valid piece of XML
ollow and critique. :)
-Melvin
Dan Sugalski <[EMAIL PROTECTED]>
10/20/2003 04:46 PM
To: [EMAIL PROTECTED]
cc:
Subject: Re: Object freezing
Note that I forgot to account for the possibility of freezing code and
environment. As such, the free
Note that I forgot to account for the possibility of freezing code and
environment. As such, the freeze and thaw opcodes have the following
variant:
freeze Sx, Py, Iz
thaw Py, Sx, Iz
where Z is the freeze/thaw level. O (the default) is the PMC only, 1
includes the global/class data for the
Since this has come up again, and it's apparent that the last time around
I wasn't sufficiently clear, it's time to go through this again, and for
the final time. (I will beat this thing into the ground by the time we're
done)
The way object serialization will be handled from the bytecode level i
50 matches
Mail list logo
