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

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

by pharo＠googlecode.com

Status: Accepted Owner: nicolas....(a)gmail.com Labels: Type-Squeak Milestone-1.3 New issue 3928 by nicolas....(a)gmail.com: Add reciprocalModulo: support in Kernel http://code.google.com/p/pharo/issues/detail?id=3928 This is an enhancement I made for Squeak. This method is much faster than that provided in Cryptography and I believe it belongs to Kernel. Integrating it in Pharo would enable cross dialect upgrade of this external package.

March 31, 2011

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

by Nicolas Cellier

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] [update 1.3] #13119

by Nicolas Cellier

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] [COTDC] 39 - EditableDropListMorph

by laurent laffont

On Wed, Mar 30, 2011 at 9:23 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: EditableDropListMorph > I'm a DropListMorph which content can be modified. Try: (EditableDropListMorph on: [#(one two three)] list: #value selected: nil changeSelected: nil) openInWindow extent: 400@20. Laurent > > > 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

Re: [Pharo-project] Regarding SimpleMorphic

by csrabak＠bol.com.br

Em 31/03/2011 13:31, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: [snipped] > Let us kill this StringHolder crap and be in 2010. 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 (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? Perhaps understanding the "crucial incident" could lead us to better roadmap. . . -- Cesar Rabak

March 31, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by Tudor Girba

+1 Doru On 31 Mar 2011, at 18:31, StÃ©phane Ducasse wrote: > > On Mar 31, 2011, at 2:14 PM, Fernando Olivero wrote: > >> Model >> TextModel >> Workspace >> PluggableTextModel >> TextProvider >> CodeProvider >> Browser >> HierarchyBrowser >> Debugger >> Inspector > > > Why this hierarchy is wrong? > > Wheel > Car > > We do not like that Car inherits from Wheel? > We prefer to say > > Car > has Weels > > > So > BrowserModel inherits from Model but not from TextModel > BrowserModel > has a textModel et other stuff > > > A BrowserModel should not inherit from CodeProvider > it has a code provider. > > Let us kill this StringHolder crap and be in 2010. > > Stef > -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

March 31, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by csrabak＠bol.com.br

Benjamin, Testing the understanding of the diagram of yours: Model, Pluggable TextMorph, Pluggable CodeMorph, Browser, Browser Model, Debugger and Debugger Model all inherit from Object? the representation of "based on" means that it changes states in the model counterpart, and "use" means that has some similarity but not enough to inherit from the other classes? Could you elaborate this with a more complete UML diagram? Thanks for giving thoughts on this subject. Regards, -- Cesar Rabak Em 31/03/2011 10:29, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com > escreveu: On Mar 31, 2011, at 2:14 PM, Fernando Olivero wrote: > In CUIS the intent is to provide specialization on the model, And then > each model holds the responsibility of creating the appropriate view > (SystemWindow), by creating a composition of widgets. This is a subset > of the model hierarchy, > > 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. So why it inherits from Model ? The same for Browser, HierarchyBrowser, Debugger, Inspector and so on... Maybe it's better to have something like

March 31, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by Fernando Olivero

Correct, but this is not enough to advocate for the removal of the Browser as a "model" for the view. I believe you are both talking about the same thing, neither of you want to no have a "browser" model . The diff would be regarding the current implementation in Pharo. The model shouldn't know about the view, as in my previous mail, i was arguing that maybe the drawback of this approach is to have the model assemble the view. Thanks Benajamin for pdf detailing the idea, and Stef for the clarification. Current Browser class (model) would be the BrowserModel of your desing. But the VIEW responsibility would be in the BrowserMorph( VIEW). I imagine the same with the remaining tools? 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." 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 2) View on specialized views, moving the current functionality from the model to the view, that dont have model logic. 3) I suggest keeping the curent names, for instance, Browser is the model, BrowserMorph is the view ( in Morphic) 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

[Pharo-project] Issue 3927 in pharo: UIManager/Broswer

by pharo＠googlecode.com

Status: Accepted Owner: Benjamin...(a)gmail.com New issue 3927 by Benjamin...(a)gmail.com: UIManager/Broswer http://code.google.com/p/pharo/issues/detail?id=3927 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 Should be redefined properly (see what SMx did)

March 31, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by Benjamin

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