March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3928 in pharo: Add reciprocalModulo: support in Kernel

by pharo＠googlecode.com

Comment #2 on issue 3928 by stephane...(a)gmail.com: Add reciprocalModulo: support in Kernel http://code.google.com/p/pharo/issues/detail?id=3928 tx we will integrate that. This is always important to improve the kernel classes.

March 31, 2011

Re: [Pharo-project] [update 1.3] #13123

by StÃ©phane Ducasse

On Mar 31, 2011, at 9:33 PM, Mariano Martinez Peck wrote: > Thanks Laurent. All this is really important. I guess you are learning a lot :) we all are learning and thinking that we are all concerned when **we** write our classes without comments. > > On Thu, Mar 31, 2011 at 9:20 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > 13123 > ----- > > COTDC integration > - 32 - MCScanner - L.Renggli, L.Laffont > - 33 - StrikeFontSet - HwaJong Oh, L.Laffont > - 34 - MCStWriter, MCStReader - L.Laffont > - 35 - MCPackageCache - S.Ducasse > - 36 - MCDefinitionIndex - S.Ducasse > - 37 - MCPatcher - HJ.Oh > - 38 - PathShape, Polygon - G.Chambers, L.Laffont > - 39 - EditableDropListMorph - L.Laffont > > Laurent >

March 31, 2011

Re: [Pharo-project] [update 1.3] #13119

by StÃ©phane Ducasse

Yes I got a strange message too. but marcus never got it and hudson neither. So I gave up and took the hudosn image. Stef > Very strange, I saved the image, closed the image, restarted and it > now behaves differently asking me to proceed to overwrite > Transcript... > I can then update normally... > > Nicolas > > 2011/3/31 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> I have update 13119 failing on this MCMethodDefinition: >> >> classIsMeta: true >> source: 'addEntry: aString >> "Add a new entrie to the entries circular list. If full, a new entry >> will replace the oldest one." >> | msg now | >> logToFile ifTrue: [ >> now := DateAndTime now. >> msg := String streamContents: [ :strm | >> now printWithMsOn: strm. >> strm >> nextPutAll: '' process:''; >> nextPutAll: Processor activeProcess priority printString; >> nextPut: $ ; >> nextPutAll: Processor activeProcess hash printString; >> nextPut: $ ; >> nextPutAll: aString; >> lf ]]. >> >> self addEntry: aString logToFile: msg' >> category: #private >> selector: #addEntry: >> className: #Transcript >> timeStamp: 'jmv 2/18/2011 12:59' >> >> Since Transcript is not a class (it is an instance of ThreadSafeTranscript). >> It cannot understand classSide then DNU... >> >> What's up >> >> Nicolas >> >> 2011/3/31 Marcus Denker <marcus.denker(a)inria.fr>: >>> 13119 >>> ----- >>> >>> Issue 3913: Fix in PluggableListMorph hierarchy >>> Issue 3736: new Transcript from CUIS >>> >>> >>> -- >>> Marcus Denker -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >>> >> >

March 31, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by StÃ©phane Ducasse

>> > > Stef, > > I'm sure you really miss last year, but we're entering the second quarter of 2011 ;-) > > []s > > Getting back to the technical part of your post, I also always tried to understand why in some cases we end up with this strange hierarchy people long time ago thought that inheritance = reuse. > (which you mock saying Car inherits from Wheel), specially if we take in account Smalltalk is a single inheritance language, so you have only a shot to specialize a given class. > > Maybe the folks that did it in the past were less used to composing than inheriting and the second way saves writing some new methods to avoid breaking the Demeter principle? I'm quite sure that LOD was not their concern. > > Perhaps understanding the "crucial incident" could lead us to better roadmap. . . No. We know design. We should just implement it. Stef

March 31, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by StÃ©phane Ducasse

> > > I agree with it and would like to help with the Nautilus model, and > the corresponding view for SimpleMorphic. > > I belive we should look at CUIS TexProvider hierarchy, since he > already cleanup this classes, and the intent is similar to the yours. > As he told in en email: "To clean the hierarchy is ok, but we should > be very careful to no put MODEL LOGIC in the VIEW. In CUIS the idea is > to deal with PluggableTextModel that gets plugged a TextProvider or > CodeProvider." I do not see why we need that at all. For the moment let us finish Nautilus and remove most of the StringHolder subclasses then after porting that to SimpleMorphic will just be switching to the correct treeMorph because the model will be the same in Morphic and in SM > Somehow similar to what you propose in the pdf, and what stef is > talking about. Composition instead of inheritance. > > So to summarize: > > 1) Model logic in specialized code providers Not only: a browser model should know not only about code but about the current state of the tools: which view (packages,.... buttons is selected). > 2) View on specialized views, moving the current functionality from > the model to the view, that dont have model logic. Not really so far we use a good tree and this is enough > 3) I suggest keeping the curent names, for instance, Browser is the > model, BrowserMorph is the view ( in Morphic) We will see. For the moment this is not important. We should get SM cleaned and port Polymorph on top of it and clean the main widgets. > > > Fernando > pd: I will sync with Juan on this effort, so we can all work together > on the next Morphic. > > > > > On Thu, Mar 31, 2011 at 5:46 PM, Benjamin > <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >> On Mar 31, 2011, at 5:51 PM, Torsten Bergmann wrote: >> >>>>> Model >>>>> TextModel >>>>> Workspace >>>>> PluggableTextModel >>>>> TextProvider >>>>> CodeProvider >>>>> Browser >>>>> HierarchyBrowser >>>>> Debugger >>>>> Inspector >>>> >>>> For me, this hierarchy is bad. >>>> Workspace is not a model, it's a view basically. >>> >>> Take care not to confuse things here. If you think as "Workspace" >>> as the window that is popping up when you open a workspace >>> then you are on the wrong track. >>> What you see is just one (morphic) view on a model/workspace instance. >>> >>> >>> Workspace, Inspector, Browser - all these ARE models and >>> you can have different looking views on it or open one or more views >>> on the same model. >>> >>> Try >>> >>> |browserModel | >>> browserModel := Browser new. >>> Browser >>> openBrowserView: (browserModel openEditString: nil) >>> label: 'View 1'. >>> Browser >>> openBrowserView: (browserModel openEditString: nil) >>> label: 'View 2'. >> >> >> >> Browser class>>#newOnClass: aClass label: aLabel >> "Open a new class browser on this class." >> | newBrowser | >> >> newBrowser := self new. >> newBrowser setClass: aClass selector: nil. >> ^ self >> openBrowserView: (newBrowser openOnClassWithEditString: nil) >> label: aLabel >> >> >> openOnClassWithEditString: aString >> "Create a pluggable version of all the views for a Browser, including views and controllers." >> ^ self openAsMorphClassEditing: aString. >> >> >> openAsMorphClassEditing: editString >> "Create a pluggable version a Browser on just a single class." >> ^UIManager default openBrowser: self asMorphClassEditing: editString >> >> >> >> >> >> So here, a Browser instance send openBrowser: asMorphClassEditing: with self as parameter: >> >> openBrowser: aBrowser asMorphClassEditing: editString >> "Create a pluggable version a Browser on just a single class." >> | window dragNDropFlag hSepFrac switchHeight mySingletonClassList | >> >> window := (SystemWindow labelled: 'later') model: aBrowser. >> dragNDropFlag := true. >> hSepFrac := 0.3. >> switchHeight := 25. >> mySingletonClassList := PluggableListMorph on: aBrowser list: #classListSingleton >> selected: #indexIsOne changeSelected: #indexIsOne: >> menu: #classListMenu:shifted: keystroke: #classListKey:from:. >> mySingletonClassList enableDragNDrop: dragNDropFlag. >> >> aBrowser >> addLowerPanesTo: window >> at: (0@hSepFrac corner: 1@1) >> with: editString. >> window >> addMorph: mySingletonClassList >> fullFrame: ( >> LayoutFrame >> fractions: (0@0 corner: 0.5@0) >> offsets: (0@0 corner: 0@switchHeight) >> ). >> >> aBrowser >> addMorphicSwitchesTo: window >> at: ( >> LayoutFrame >> fractions: (0.5@0 corner: 1.0@0) >> offsets: (0@0 corner: 0@switchHeight) >> ). >> >> window >> addMorph: aBrowser buildMorphicMessageCatList >> fullFrame: ( >> LayoutFrame >> fractions: (0@0 corner: 0.5@hSepFrac) >> offsets: (0@switchHeight corner: 0@0) >> ). >> >> window >> addMorph: aBrowser buildMorphicMessageList >> fullFrame: ( >> LayoutFrame >> fractions: (0.5@0 corner: 1.0@hSepFrac) >> offsets: (0@switchHeight corner: 0@0) >> ). >> >> window setUpdatablePanesFrom: #(messageCategoryList messageList). >> ^ window >> >> For me, it's not a Model behavior to add panes ... >> >> >> Ben >> >> >> >>> >>> Evaluate it, show the windows side by side and then click >>> in one: two views on the same model and the changes are >>> propagated to all dependent views. >>> >>> So they ARE MODELS: >>> Take a browser for example. It should know about which class >>> is selected, which methods to display, ... it's a code holder >>> and manager thing. Nothing more ... it doesnt even need a UI. >>> >>> But it's "view parts" could be (one or more) real windows >>> layouted in either morphic or a view in Squeaks old MVC or >>> browser on a Seaside webpage (actually Seaside really has an HTML >>> based browser). >>> >>> The browser model does for instance care if you are working >>> on the instance or class side (see #metaClassIndicated >>> and senders) - but it doesnt care if you switch either using >>> buttons or radio buttons or whatever ... thats up to the view/presentation >>> layer. >>> >>> In general you should be able to also drive this model >>> without ever really having to open a view ... >>> >>> So that even the tools are models (although most people think of them >>> as windows) is a major difference in Smalltalk's UI design compared to >>> most UI frameworks in other languages. >>> >>> VisualWorks uses a special class ApplicationModel to subclass >>> for tools and application windows to make this more clear. >>> >>> Java's Swing (written by people who designed VisualWorks UI first) has a >>> similar but more excessive model design JButton -> ButtonModel, ... >>> The other extreme is VB6/Delphi where you dont have a model at all >>> and have to write an own if you want separation ;) >>> >>> Nothing said about the code quality of the current implementation >>> in Pharo... >>> >>> Bye >>> T. >>> -- >>> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >>> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >>> >> >> >> >

March 31, 2011

Re: [Pharo-project] Progress bar design pattern

by Martin Dias

Hi! On Wed, Mar 30, 2011 at 2:13 AM, Daniel Lyons <fusion(a)storytotell.org>wrote: > > On Mar 29, 2011, at 6:17 PM, Martin Dias wrote: > > I have a couple of algorithms and I want to show the progress while they > run. I played with the progress bar and it's okay for my needs. > > The progress bar should be pluggable and decoupled of the algorithms. > > I am writing to you to ask about good designs for my problem. I hope I > haven't expressed the problem in a too abstract way. > > The design I have in mind is a kind of observer pattern: the serialization > algorithm publishes information about the run; a specific listener > implements the progress bar for that serialization algorithm, interpreting > the information published. > > > I'm a newcomer here, so I'm sharing my experience with non-Smalltalk > systems and my best guess what would constitute good designs. I hope other > real Smalltalkers will poke some holes in this and point out the right way > to do things! ;) > > The simplest design, IMO, would be this API: > > MyProgressBar>>percentComplete: aNumber > MyProgressBar>>beIndeterminant > MyProgressBar>>beDeterminant > Sorry, what is an indeterminant progress bar? > > You would manually invoke percentComplete: with a new percent complete each > time you want to advance the progress bar. I've seen this kind of thing in > practice somewhere. Maybe it was Cocoa? > > The next level of abstraction would be to go a bit more jQuery UI and > remove percentComplete: and use this instead: > > MyProgressBar>>maximum: anInteger > MyProgressBar>>current: anInteger > > Now you'll calculate the progress bar based on some quantity of "tasks" you > want to do. You could even go further and just have: > > MyProgressBar>>incrementProgress > > instead of letting your clients tell you which one they're on. That would > prevent progress bar relapse. Either of these would be easy to implement on > top of the above API using percent. > > The simplest observer-type pattern would be to rely on the built-in > observer/event system and use the stuff from Object's updating protocol or > events-registering or events-triggering. I don't know which one of these is > modern or preferred. Anybody? :) At any rate, they make it possible to > expose a simple object/message protocol as in Polymorph, where your progress > bar widget would be listening for change notifications from your domain > object. Then you can ask the same questions about your model as above, in > terms of whether you want to work in terms of simply percent complete or N/M > or what. > > I was looking to use String>>displayProgressAt:from:to:during:. The example shown on its comment is: 'Now here''s some Real Progress' displayProgressAt: Sensor cursorPoint from: 0 to: 10 during: [:bar | 1 to: 10 do: [:x | bar value: x. (Delay forMilliseconds: 500) wait]]. But my doubt was how to connect the algorithm progress with that "bar value: x". I would like to avoid that the model (my serialization algorithm) explicitly speak of percentages, I prefer the calculus of the percentage to be done in another place, some observer that interprets the progress and then updates the bar. I will try to follow the idea I understood of your last paragraph: I will have the algorithm run reified in a class, let say MyAlgorithmRun, which sends itself #changed each time it has progressed, and a dependent, let say an instance of MyAlgorithmRunProgressObserver, receives an #update:. Then the observer interprets the current state of the run, and sends #value: to the UI progress bar. Is it okay? > Another question is whether or not you want to provide a string message > status to go under the progress bar. > > Does this help at all, or did I miss the point? > > Yes! for me it's very useful to think, thanks! > â > Daniel Lyons > >

March 31, 2011

Re: [Pharo-project] [update 1.3] #13123

by Mariano Martinez Peck

Thanks Laurent. All this is really important. I guess you are learning a lot :) On Thu, Mar 31, 2011 at 9:20 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > 13123 > ----- > > COTDC integration > - 32 - MCScanner - L.Renggli, L.Laffont > - 33 - StrikeFontSet - HwaJong Oh, L.Laffont > - 34 - MCStWriter, MCStReader - L.Laffont > - 35 - MCPackageCache - S.Ducasse > - 36 - MCDefinitionIndex - S.Ducasse > - 37 - MCPatcher - HJ.Oh > - 38 - PathShape, Polygon - G.Chambers, L.Laffont > - 39 - EditableDropListMorph - L.Laffont > > Laurent >

March 31, 2011

Re: [Pharo-project] Issue 3928 in pharo: Add reciprocalModulo: support in Kernel

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #1 on issue 3928 by nicolas....(a)gmail.com: Add reciprocalModulo: support in Kernel http://code.google.com/p/pharo/issues/detail?id=3928 Name: SLICE-Issue-3928-support-reciprocalModulo-nice.1 Dependencies: Kernel-nice.856, KernelTests-nice.317 Add #reciprocalModulo: support and test

March 31, 2011

[Pharo-project] [COTDC] 40 - PasswordDialogWindow

by laurent laffont

Today: PasswordDialogWindow Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

March 31, 2011

[Pharo-project] [update 1.3] #13123

by laurent laffont

13123 ----- COTDC integration - 32 - MCScanner - L.Renggli, L.Laffont - 33 - StrikeFontSet - HwaJong Oh, L.Laffont - 34 - MCStWriter, MCStReader - L.Laffont - 35 - MCPackageCache - S.Ducasse - 36 - MCDefinitionIndex - S.Ducasse - 37 - MCPatcher - HJ.Oh - 38 - PathShape, Polygon - G.Chambers, L.Laffont - 39 - EditableDropListMorph - L.Laffont Laurent

March 31, 2011