Am 21.07.2013 um 10:32 schrieb Marcus Denker <[email protected]>:

> 
> On Jul 21, 2013, at 10:20 AM, Norbert Hartl <[email protected]> wrote:
> 
>> 
>> 
>> Am 21.07.2013 um 10:16 schrieb Marcus Denker <[email protected]>:
>> 
>>> 
>>> On Jul 21, 2013, at 10:05 AM, Damien Cassou <[email protected]> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code
>>>> that looks like this:
>>>> 
>>>> [...]
>>>> changes isReadOnly
>>>>             ifTrue: [ self inform: 'Pharo cannot write to the
>>>> changes file ...' ].
>>>> [...]
>>>> 
>>>> This code raises a warning if the changes file can't be written to. In
>>>> the PharoLauncher case, the image and changes file won't be writable
>>>> and it is ok (they will be in a place like /usr/lib). I certainly
>>>> don't want my users to see this warning.
>>>> 
>>>> What can I do please?
>>>> 
>>> 
>>> We need to get rid of .changes and .sources… it will solve all kinds of 
>>> problems.
>>> 
>> What will be the replacement?
>> 
> 
> -> 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?

> -> 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?

> -> 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.

> 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)

Norbert

Reply via email to