- Pharo-dev - lists.pharo.org

Re: [Pharo-project] the glamorous toolkit project

by Tudor Girba

I think that this is a good idea. Having the Core tools better is definitely a good thing. Furthermore, the nice thing is that we can reuse the Morphic widgets in Glamour. Cheers, Doru On 13 Mar 2011, at 11:09, StÃ©phane Ducasse wrote: > > On Mar 13, 2011, at 11:01 AM, Mariano Martinez Peck wrote: > >> Tudor/Ben, did you think about "rewrting" the new UI tools like Recent Messages, Finder, etc...using Glamour ? > > > With Ben we are targeting removing StringHolder, so we will rewrite some tools (but not in Glamour) > to make sure that we can work without glamour and make sure that we can get rid of StringHolder and friends. > In parallel if people make Glamour working well and fully then at some point it could be the ide for Pharo > but we need some fallbacks and we will be working on that with Ben. > > Stef > > >> >> >> On Sun, Mar 13, 2011 at 1:24 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> +1000 Great initiative and most welcomed. >> And as you said, even if you don't do most, a planing, coordination >> and bugging people around helps as well :) >> >> On 12 March 2011 08:25, Tudor Girba <tudor.girba(a)gmail.com> wrote: >>> 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 >> >> you can make it bold (or what else you do to mark that it is done and >> ready to be integrated :) >> >>> - 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." >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > -- www.tudorgirba.com "Some battles are better lost than fought."

March 13, 2011

Re: [Pharo-project] Short summary of new announcement capabilities

by Tudor Girba

Great work! I am so looking forward to use this :). Please keep us posted when we can play with it and how to load it. Cheers, Doru On 13 Mar 2011, at 10:48, StÃ©phane Ducasse wrote: > Thanks a ***LOT*** > It is really important for pharo. > > Stef > > On Mar 13, 2011, at 2:08 AM, Henrik Sperre Johansen wrote: > >> 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. >> >> > > -- www.tudorgirba.com "One cannot do more than one can do."

March 13, 2011

Re: [Pharo-project] Issue 3806 in pharo: Duration>>hours is broken

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #9 on issue 3806 by stephane...(a)gmail.com: Duration>>hours is broken http://code.google.com/p/pharo/issues/detail?id=3806 (No comment was entered for this change.)

March 13, 2011

Re: [Pharo-project] Issue 3806 in pharo: Duration>>hours is broken

by pharo＠googlecode.com

Updates: Status: Accepted Comment #8 on issue 3806 by stephane...(a)gmail.com: Duration>>hours is broken http://code.google.com/p/pharo/issues/detail?id=3806 No really. What is the consensus?

March 13, 2011

Re: [Pharo-project] the glamorous toolkit project

by Tudor Girba

Hi Mariano, The idea is indeed to rewrite all the use cases solved by tools in Glamour at the end. However, this does not mean that we will redo those tools like they are now :). Cheers, Doru On 13 Mar 2011, at 11:01, Mariano Martinez Peck wrote: > Tudor/Ben, did you think about "rewrting" the new UI tools like Recent Messages, Finder, etc...using Glamour ? > > > On Sun, Mar 13, 2011 at 1:24 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > +1000 Great initiative and most welcomed. > And as you said, even if you don't do most, a planing, coordination > and bugging people around helps as well :) > > On 12 March 2011 08:25, Tudor Girba <tudor.girba(a)gmail.com> wrote: > > 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 > > you can make it bold (or what else you do to mark that it is done and > ready to be integrated :) > > > - 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." > > > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- www.tudorgirba.com "Being happy is a matter of choice."

March 13, 2011

Re: [Pharo-project] Issue 3706 in pharo: In OB: Text in comment pane of Browser uses syntax highlighting

by pharo＠googlecode.com

Comment #14 on issue 3706 by stephane...(a)gmail.com: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 I understand that you cannot maintain seaside pier magritte. Now do not wait that 1.2 is released to migrate to it else this is clearly a deadlock. So what is the conclusion? That we cannot have a system where we maintain all the tools in alpha. So people should not wait the release version to migrate but the beta phase. The beta phase is done for that: you can migrate the tools to get ready for the rc. And else we will not ship external tools because we do not know how they work. I do not know and do not have the time to understand and maintain OB. So either other people do it or it dies and I cannot do much about that. This is not because we will have it in the core that it will change this state of fact.

March 13, 2011

Re: [Pharo-project] Issue 3815 in pharo: Filing in Class comments raises an error

by pharo＠googlecode.com

Comment #7 on issue 3815 by stephane...(a)gmail.com: Filing in Class comments raises an error http://code.google.com/p/pharo/issues/detail?id=3815 No recent submission is working. Now we should fix all the metamodel underneath and this is not something that can easily be done. We are working on the ring metamodel to be able to do that in the future. So the UI was redbuilt by benjamin and the source ugly model should be incrementally migrated to use ring API and Ring objects.

March 13, 2011

Re: [Pharo-project] Issue 3706 in pharo: In OB: Text in comment pane of Browser uses syntax highlighting

by pharo＠googlecode.com

Comment #13 on issue 3706 by renggli: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 > Yes but if the maintainer of OB does not want to maintain the 1.2 branch > when we are doing 1.2 alpha then what do we do? ( I never understood your > position at this level). The thing is that I cannot (and I never could) maintain Seaside, Magritte, Pier, PetitParser and Helvetia on a (shaky) not yet released version of Pharo. > We cannot play the platform evolution (vs the core) if maintainers of the > packages do not play the game. With Seaside, Magritte and Pharo we do not want to play such games (to be able to deliver the best possible first experience). With OB and RB I don't have the time to maintain two versions (I thought that people jumped in here for Pharo 1.2, but frankly the existing code is very broken). > It works really well with Moose. I do not agree. From what I know, many Moose users stick with old versions of Moose (and Pharo), because the new versions do not work for them.

March 13, 2011

Re: [Pharo-project] Issue 3815 in pharo: Filing in Class comments raises an error

by pharo＠googlecode.com

Comment #6 on issue 3815 by stephane...(a)gmail.com: Filing in Class comments raises an error http://code.google.com/p/pharo/issues/detail?id=3815 A dirty solution is to remove the class comments change notification from the fileIn. fileIn "File the receiver in. If I represent a method or a class-comment, file the method in and make a note of it in the recent-submissions list; if I represent a do-it, then, well, do it." Cursor read showWhile: [ | methodClass aSelector s | (methodClass := self methodClass) notNil ifTrue: [ methodClass compile: self text classified: category withStamp: stamp notifying: nil. (aSelector := self methodSelector) ifNotNil: [ RecentMessageSet noteMethodSubmission: aSelector forClass: methodClass ] ]. type == #doIt ifTrue: [ ((s := self string) beginsWith: '----') ifFalse: [ Compiler evaluate: s ] ]. ]

March 13, 2011

[Pharo-project] [update 1.3] #13086 new version

by StÃ©phane Ducasse

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

March 13, 2011