|
ActionsInPharoOneDotThree
The list of changes performed in 1.3
Pharo 1.3 saw a lot of changes to improve important part of the systems. We are really happy and convinced that these changes will give large benefits in the future. We thanks you all that helped us so much. Without you pharo would change slower and would be less fun. Over 700 items in the issue tracker have been solved in 1.3. A complete list can be found on the Issue Tracker The Build Server always has the latest release, so please give it a test run! Build Server. Currently known bugs:
Cleaning architectural dependenciesWe clean a lot of unwanted dependencies between several packages. We applied Moose tools and we will continue to improve the architecture of the system. In particular we will identify better layers in the system. This is important to be able to change large components and to be agile and make certain hypotheses exposed. Applying code critics to the complete systemWe started to run code critics on the complete system and fix them. We will continue on this path and we will add automated code critics in the hudson build scripts. In particular we removed more than you can expect duplicated code between classes and subclasses. We plan to add Pharo specific Lint Rules and also bring rule checking for all the hosted applications on our hudson server. Support for server and headless imagesBeing able to run Pharo on headless servers is important for web development as well as for building scripts. We introduced a better way of handling non interactive mode. We want to make sure that Pharo can run without UI. Ideally we would like to be able to plug a UI layer on the fly to get a real headless mode but this is clearly future. But at least you know our vision. We improved the way the command line works. A new implementation is now available and it can support multiple extensions without conflicts. Pharo has now a support for stdin, stdout and stderr. More robust and better startup/shutdownAt startup and shutdown the image executes the methods startUp: and shutdown: of registered classes (registered using addToStartUpList:, addToShutDownList:, ... methods and friends). Now we improved the robstuness of actions performed at startup by introducing a two stages process. During the first stage of start up the UI manager, the default uimanager is switched to a specific non interactive ui manager (StartupUIManager). Note that this specific non interactive UIManager kills the system on any attempt to open windows and interaction. So be warned, don't use interaction in the first phase. Then all registered classes execute their start up procedures (which should not imply interactive behavior). After startup list is finished, any deferred startup actions are executed, which you can add using the method addDeferredStartupAction: method. This change is important since it structures the startup and make sure that certain actions only occurs when they can run. Better look and feelWe copied the work done for Moose and reorganize a bit the themes. We deprecated some old ones. We will continue to improve this aspect. Better widgetsIn general we believe that the core widgets should be more powerful. We did a lot of progress there and we will continue our effort.
Now we introduced a NullStyler to be able to have a more modular system.
We deprecated ParagraphEditor and use the new text editor. We got a better TextMorph, with a better find/replace behavior. There is now a really powerful text selection that can show automatically all the occurrences of a selection in the complete text. This makes code changes really fast. The visual impact is excellent.
PluggableList Morph was improved in multiple fashions. Multiple selection is now supported. List items can be searched then the focus on a new item can be driven using keyboard. PluggableListMorph can now behaves like a multiple selection list. This behavior can be switched on the fly. (MultipleListOfMany, PluggableIconListMorphOfMany are now deprecated since PluggableListMorph can do the same). Benjamin van Ryseghem did an excellent job there.
We continued to integrate deeper Polymorph into the system and revisit also some polymorph choices.
Better toolsOur goal is to be able to get models for all the tools and to rewrite all the basic tools so that we can deprecate the old hierarchy around StringHolder. We made good progress there. Benjamin van Ryseghem really helped a lot for this task.
Smalltalk resetTools. Note, that with tools registry, you are no longer need to keep (and implement) a singleton pattern per each tool class, which requires it , i.e.SomeTool default doSomething. instead, with using registry, you can register a sole tool instance (or class) to registry , and then just write Smalltalk tools someTool doSomething.
New libraries or Enhancement
A new method on:fork: is introduced, on error it will manipulate the stack and fork a process with the part containing the error. This lets in particular the execution of non broken behavior continue to run. This changes will bring a lot of stability and robustness in the system in key core places. The logic of the UI thread will be rewritten to take advantage of it.
Announcements are important and we improved the first naive implementation. Support for weak announcements was first added. Then announcement took advantage of the on:fork: introduction. It makes sure now that all system announcement will be delivered.
Often when you build proxy, you cannot control all the messages sent to the proxy because the proxy implementation relies on DNU and ProtoObject. We designed a new version which does not suffer such limit based on an not so well known VM hook. Ghost a proxy library is also available.
We removed the old undo framework and introduced a brand new one working really well. Thanks Alain Plantec
Thanks to the wonderful idea of Laurent Laffont we started to systematically comment, uncommented classes! Old CompilerWhile we continued to work on OPAL and in particular its decompiler and various point between layers, we continued to integrate improvements to the old compiler.
Network
Varia
CleanupsThe system continues to contain a lot of dead code. In the 1.3 release cycle we continued cleaning unused code. We use a combination of two strategies. For one, deprecating code (moving classes and methods to the Deprecated13 package). This allows clients to continue to use this code and slowly migrate. The second strategy is hard and radical deletion.
The removal of MVC allowed to do start a major cleanup related to the text model. Paragraph has been replaced by MultiNewParagraph everywhere, lots of unused code was removed from text and canvas classes.
Security
|