[squeak-dev] Deltastreams update
Göran Krampe
goran at krampe.se
Thu Mar 12 13:05:43 UTC 2009
Hi!
Ralph Johnson wrote:
> On Thu, Mar 12, 2009 at 5:28 AM, Göran Krampe <goran at krampe.se> wrote:
>> - Human readable, just like a cs. We just gzip them and make up some nice
>> extension like .dz or something. :)
>> - Editable in a text editor. This means it can not be too complex.
>> - Easy to extend. This means the base syntax should leave room for new
>> elements and "relaxed parsing" that can ignore unknown elements
>> - Very easy to parse. This means it needs to be simple, simple, simple. I
>> don't want to depend on YAXO or similarly large package for parsing.
>> - Not "compiler driven". I want the format to be safe and fast to load. This
>> means the regular Smalltalk Compiler is out of the picture.
>
> I don't understand the combination of "human readable" and "not
> compiler driven". Does this mean that you are going to include
> bytecodes as well as source code?
No. :)
> If the file is editable in a text
> editor, then it will be easy to make the bytecodes be incompatible
> with the source code.
No bytecodes, see below.
> Maybe your definition of "human readable" and "editable in a text
> editor" are different from mine. Perhaps you only intend human
> readability as a last resort, as a way of debugging the system, for
> example.
No, I would like them to be "fairly readable". And I do want them to be
quite easily "generated" and fiddled with (although I don't really
expect them to be generated or edited by many other tools than the DS
codebase itself).
I think your mentioning of bytecodes comes from a misconception - a
Delta carries source code, but it is *not* compiled when loaded into an
image. The compilation is done in the "next step" - when you "apply" the
Delta to the image (using SystemEditor to do it atomically).
So the file is actually "just a serialization of a DSDelta instance".
Since a DSDelta instance is basically a sequence of DSChange instances,
and the most common one is a DSMethodModifiedChange - it kinda will look
like a changeset, although much more "detailed" in nature.
But from a usage perspective we could even dump them using
SmartRefStream - since we first load them into the image - but I do
think a "real" format has its advantages.
Btw, what I meant with "Compiler driven" was how the chunk format works:
http://wiki.squeak.org/squeak/1105
...but I don't think I want an "executable" format like this.
> Netstrings aren't very editable, because you have to keep
> counting characters every time you change a line. But if editability
> is only for extreme emergencies, this is OK.
Good point, hadn't thought about that weakness of netstrings. Hmmmm.
Perhaps Yaml is worth looking at? Need to figure out its
advantages/disadvantages.
regards, Göran
More information about the Squeak-dev
mailing list
|