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