Hi pharoers
I think that doing is more difficult than evolving :)
So before this scenario happens, I want to have a new changes management system
that is orthogonal to the source management. Right now these two concepts are
mixed together.
Martin in the context of his PhD is working on a nice replacement to changeset
and
also he is building a nice representation of a change (in the spirit of
deltaStream)
with changes representation and not just method, class, package.
The project is called Epicea. We want to support for example:
- I perform a list of changes
- I tagged them with comments like refactored this method into
these two
- publish the code
- and Alain can review my code at the level of the semantic change by
looking and commenting on changes using the tags.
I hope to get a nice demo for ESUG :)
Stef
>>>>
>>>>> 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
