>>
>> -> transaction log attached to he end of the running image file
>>
> Ok, sounds reasonable on the one hand (getting rid of an additional file) and
> dangerous on the other hand (on image write the transaction log needs to be
> read/written/moved making it possible to loose image and transaction log.
> Think about a "disk full" scenario). How is this covered?
>
For the change log: it will stop recording (like now when there is no space
for .changes appending)
Image save: right now you override the existing file, this means that if you
don't have enough space for you (likely) larger image, it will fail and
override the old image.
New: it will fail, but while writing the *new* file. So you at least keep your
old. In both cases you can't write a new image file, but right now you loose
your old one, too.
So it's better.
>> -> accepted methods kept in image history until next commit to the source
>> repo
>>
> Great. Everyone can have a ImmediateCommitStrategy so no reason to complain,
> right?
>
Yes, it is the same as now: you loose the "method save" commits as only what is
in Monticello is saved for real.
>> -> sources in image. First compresses text with a shared compression
>> dictionary,
>> later a high-level representation of code that superseded the AST, text
>> and bytecode.
>>
> That is really cool. There is no reason to have sources separate until you
> treat it like text you basicall don't care about. I'm curious with what
> you'll come up with regarding the thing that supersedes ast, text and
> bytecode. And especially if the visual syntax can still be the same as it is
> now. As you know I would be a fan of something that would keep the smalltalk
> syntax (meaning visual characters) the same but adds visual things (colors,
> icons, type setting) to indicate the presence of meta data. Underneath there
> be something that can transport the code with an extended source format to
> another image. Cool times are these.
The idea would be to keep it at the beginning just the same: instead of a
stream of characters, the data structure would be different, but would be just
s string form what it shows.
(this means no changes to MC, Git, or even file out). Purely internal.
>
>> Yes, and I know that everyone things that this is wrong. And I don't care :-)
>>
> Come on. Things aren't that bad.
:-)
> Just imagine that all of the people that aren't complaining do agree or don't
> care about. And that's a way bigger number. I personally like those steps
> even if it means we are loosing a lot of tools and frameworks out there (And
> there aren't that many)
I think nothing works directly on the .source and .changes right now… so one
would loose nothing. (Of course after there are other things thinkable… but
that is for after).
Marcus
