- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-users] Last pending things for Pharo 1.2
by Marcus Denker March 13, 2011

March 13, 2011

On Mar 13, 2011, at 4:35 PM, Guillermo Polito wrote: > F***, MethodWrappers.Tests.ObjectAsOneTimeMethodWrapperTest.testInstallOnClassCategory is broken again... Is it failing randomly? If so, can we remove that test? :( > It is failing randomly, yes. I thought I noted that in the original bug report? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] the glamorous toolkit project
by Tudor Girba March 13, 2011

March 13, 2011

Hi, I would like to promote the idea of projects in Pharo. The concept is simple: we should build new infrastructures that go beyond small fixes and that require the concerted work of multiple people over a longer period of time. A project has a clear goal, and is led by someone. That someone is not necessarily the one that writes all the code (like we might tend to do it), but simply one that ensures that the project advances, that the different contributions are integrated, and that things are not left at 90%. I would like to announce the Glamorous Tool project. The goal of this project is to provide a new set of tools for developing with Pharo. It is to be developed on top of Glamour, and it should address at least the followings: - Coder (ex-System Browser) - Debugger - Inspector - Playground (ex-Workspace - it's not called Workspace anymore because I would like to encourage people not to "work" there) - Chaser (senders, implementors and references) The project spans several topics. For example: - Glamour support - Morphic enhancements: --- Proper TextMorph with keybindings and context sensitiveness --- Collapsable Panes --- Scalable tabs --- Parallel rendering - Suitable models --- RPackage --- Code introspection --- Debugger model - Testing --- Because these tools are so critical, they should be robust --- OB is a good example for the testing part - Usability --- Principle: Spawning a window might be easy, but it is not effective --- Principle: Uniformity --- Principle: Less concepts are better than many - Graphic design of skins and icons - Weak announcements - Performance I will lead it, and you are welcome to participate. The today sprint is a good occasion to take a look. The current code can be found at: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. Cheers, Doru -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

4 7

[Pharo-project] Short summary of new announcement capabilities
by Henrik Sperre Johansen March 13, 2011

March 13, 2011

Barring a few update problems, they changes Igor and I made today should be ready for general review/inclusion shortly. Here's a few points about the most important differences to the current implementation: 1. Now supports action blocs with 0, 1 or 2 arguments (announcement and receiver). This should allows us to: 1.1 Write blocks with strict guarantees for expiry and removal without keeping strong references to announcers in subscriber, by using the announcer arg to unsubscribe if action is invalid. (Not very nice resulting code, but necessary if altering outside-accessible state) 1.2 use suspendWhile: equivalent from blocks where announcer is not kept in context when such protocol is added. 1.3 Not use :ann argument for action blocks in which you don't really care. 1.4 Provide an upgrade path from events by replacing them with 0-arg MessageSend announcements under the hood if we want. (Would requires some nasty bits with objects as announcers though). 2. Support weak subscriptions for message send type of announcement. Block action requires ephemeron support in VM to correctly unsubscribe automatically, and trying to create them currently raises an error. 3. Reify Subscriptions (which are returned by #when:do: and friends), which can be made weak with #makeWeak. However, for thread-safety reasons this is done using #becomeForward:. If weakness can be determined at subscription time, the recommended way would be to use: announcer weak when:send:to: The weak send creates a wrapper which will instantiate the subscription as weak from the get-go. 4. The SubscriptionRegistry is thread-safe, in the sense that add: remove: and deliver: are protected by a Monitor. (so you can remove: in action block without a deadlock, see 1.1). Rather than block for the entire deliver: process, we chose to only protect the copy of subscriptions. This implies that the following may happen: Thread 1 starts delivery of announcement. Thread 2 interrupts after copy is created, then removes a subscription and carries on doing its stuff Thread 1 resumes, and delivers announcement to remaining subscriptions, potentially including that removed by Thread2. Don't think this is likely to be a common scenario where protecting the entire delivery would have made a difference. If you think otherwise, and can provide a good use case, please speak up and we may change it. if you want to browse the changes, they are available for perusal in the changesets attached to: http://code.google.com/p/pharo/issues/detail?id=3814 (Split in two to take care of migrating existing subscriptions) Don't try to load them though, as they depend on changes in other issues, and the comment changes cause errors. Feedback would be appreciated. Cheers, Henry PS. We forgot to include #on:do:for: & friends, which allow you to specify another subscriber than the object block belongs to. This is an oversight and will be corrected before inclusion. Just in case you were following Tudor's tweets and were wondering where they had gone.

3 2

[Pharo-project] [update 1.3] #13086 new version
by StÃ©phane Ducasse March 13, 2011

March 13, 2011

13086 ----- - Added test packages - Removed PharoCorePackageDependencyTests

1 0

[Pharo-project] Actions done in Pharo 1.2
by Mariano Martinez Peck March 13, 2011

March 13, 2011

Please, we need help to write down / summarize all the actions done in Pharo 1.2. Include them here: http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotTwo cheers Mariano

3 5

[Pharo-project] [update 1.3] #13085 new version
by StÃ©phane Ducasse March 13, 2011

March 13, 2011

13085 ----- - Remove Object>>undo. - Issue 3312: [Kernel Dependencies] BlockClosure >> #decompile. - Issue 3313: [Kernel Dependencies] UndefinedObject / Compiler. Stef

1 0

[Pharo-project] [update 1.3] #13084 new version!
by StÃ©phane Ducasse March 13, 2011

March 13, 2011

13084 ----- - Issue 3311: [Kernel Dependencies] Object / Compiler. - Issue 3283: Symbol dependent on Scanner. Part 5, 6 and 7. - FinderUI fixes. Sorry for the corruption. Stef

1 0

[Pharo-project] Update process broken by 13084
by Henrik Sperre Johansen March 13, 2011

March 13, 2011

See title. Probably caused by saving from multiple open copies of the same image so the .changes file source was exported from was corrupted :) Cheers, Henry

4 11

[Pharo-project] About Pharo sprint
by Igor Stasenko March 13, 2011

March 13, 2011

It is easy to tell, when it happens.. because my inbox is flooded with tons of messages :) And that's great :) -- Best regards, Igor Stasenko AKA sig.

2 3

[Pharo-project] [ANN] pharo focused sprint - bern, feb 26
by Tudor Girba March 13, 2011

March 13, 2011

Hi, We would like to organize a Pharo Sprint on Saturday, February 26 at SCG, University of Berne, Switzerland (room 107): http://scg.unibe.ch/contact/maps Unlike other sprints, this would not be about fixing things from the tracker, but about building something new and reviewing the situation around one central topic. For this one, the main topic will be Morphic and the IDE. Why? Because it is time to rethink our day-to-day tools and bring them closer to this century (ok, maybe decade :)). It is Ok if you are not a specialist. It is more important to want to participate and learn. The rest will come in time. ***** Please let us know by mail if you plan to attend and what you would wish to work on (see below). Proposed tasks (other tasks are possible in the same area): - Enhancements of Morphic widgets: --- TabGroupMorph with lazy pages, closable tabs, overflow handling and toolbars (a start exists in Glamour) --- High level support for collapsable panes (based on the input of Gary) --- SearchMorph with multiple groups of items (like in Spotlight) --- MorphTreeMorph integrated with GeneralScrollPane to allow for space filling --- BreadcrumbMorph --- Hyperlinks in TextMorphs - Test and enhance the current IDE - Evaluate TextMorphs: NewTextMorph, PluggableTextMorph, SMxPluggableTextMorph etc - Prototype a new ToolSet solution - Enhancements of Glamour and of the Glamorous Toolkit --- Debugger --- Coder --- Multipage Workspace --- CodeBubbles - Develop WeakAnnouncement (start from the implementation of Lukas) - Evaluate the various keybinding implementations - Evaluate ToolBuilder - Evaluate the path to adopt SimpleMorphic A second working topic is getting Monticello faster, but this will only be tackled if there are enough people for the first one. Cheers, Adrian and Doru -- www.tudorgirba.com "Be rather willing to give than demanding to get."

14 29