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

Re: [Pharo-project] {Spam?} Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

by Keith Hodges

StÃ©phane Ducasse wrote: >>> over a period of years of maintenance and incremental development; >>> >> When I fully joined the squeak community, who was running the release >> team? Yes it was exactly the same guys as are the pharo team, namely >> Stef, and Marcus. >> > > booooohhhhh we are the "vilain"..... > > I didn't say that. I was apparently being told that I shouldn't criticise you because you are the "champions of the new way" and that the old squeak days were far worse. When in actual fact from my perspective the old old squeak days are irrelevant (I was using ST/X) and the recent-old squeak days were run by you, so you are not "champions of a new way" after all, you are champions of "your way", which is the same way that you did 3.9, but with less stake holders. I am not saying that "your way" is villainous. I am saying that it is a complete straw man to use the "old old ways" of the past to justify how wonderful "your way" is, when actually "your present way" is just the same, Keith

March 21, 2009

Re: [Pharo-project] Fwd: I have the following version of Seaside

by Damien Cassou

2009/3/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Where do I get the latest pharo, and how do I install it on my image? pharo-web already contains Seaside 2.8: http://code.google.com/p/pharo/wiki/Downloads?tm=2. This page also points to the latest downloadable Pharo version. Then, you can install Seaside: instClass := Smalltalk at: #Installer ifAbsent: [ScriptLoader new installingInstaller]. instClass ss project: 'KomHttpServer'; install: 'DynamicBindings'; install: 'KomServices'; install: 'KomHttpServer'. instClass ss project: 'Seaside'; answer: '.*username.*' with: 'admin'; answer: '.*password.*' with: 'seaside'; install: 'Seaside2.8a1'. -- Damien Cassou http://damiencassou.seasidehosting.st

March 21, 2009

Re: [Pharo-project] Fwd: [ANN] 10254

by StÃ©phane Ducasse

so henrik is is ok if I remove areasRemainingToFill: from BorderedMorph? Stef On Mar 19, 2009, at 1:46 PM, Henrik Johansen wrote: > I know, which is why I thought it was strange, the .cs contained: > !BorderedMorph removeSelector: #areasRemainingToFill:! > which when I file it in, results in no areasRemainingToFill: method > for > BorderedMorph in the image. > > I really have no idea how the update process makes it revert to an > older > version instead, nor how one would go about fixing it... :/ > > Cheers, > Henrik > > StÃ©phane Ducasse wrote: >> >> >> henrik I just integrated the file you gave me. >> If you have a new version that fixes the problem I will do a new >> version. >> >> Stef >> >> On Mar 19, 2009, at 12:20 PM, Henrik Johansen wrote: >> >>> It seems BorderedMorph's areasRemainingToFill: method got reverted >>> to >>> the version in use prior to the override by PolyMorph (which has now >>> been promoted to Morph), instead of removed completely. >>> (This is the state my image is in after updating a released 248, at >>> least) >>> >>> Cheers, >>> Henry >>> >>> StÃ©phane Ducasse wrote: >>>> Issue 655: Overlapping Graphics on World do not Properly Repaint >>>> Issue 658: Preferences resetHaloSpecifications >>>> Issue 664: unimplemented errorCantGoBack >>>> Closed 665 >>>> >>>> now we will focus on the closures. >>>> >>>> Stef >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 21, 2009

Re: [Pharo-project] {Spam?} Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

by StÃ©phane Ducasse

> >> over a period of years of maintenance and incremental development; > When I fully joined the squeak community, who was running the release > team? Yes it was exactly the same guys as are the pharo team, namely > Stef, and Marcus. booooohhhhh we are the "vilain"..... We were trying to break as much as possible and we did a robust release that integrated more than 625 bug fixes. So please respect that. And yes you are insulting us. Stef

March 21, 2009

Re: [Pharo-project] Mickael system submission Slice merging problem

by StÃ©phane Ducasse

Ok I will do that now. So we can clean the inbox. Stef On Mar 21, 2009, at 3:02 PM, Michael Rueger wrote: > StÃ©phane Ducasse wrote: > >> what will happen with Test (which contains already some tests....) >> >> SystemChangeNotification-Tests-sd.11.mcz >> Tests-sd.46.mcz >> Tests-System-Digital Signatures-sd.2.mcz >> Tests-System-Object Events-sd.2.mcz >> Tests-SystemChangeNotification-sd.2.mcz >> >> So I think that we should have the contents of Tests as packages and >> remove Tests as top package. >> I will do that in a second time. >> Is is ok for you? > > Sounds good to me :-) > > Thanks! > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 21, 2009

Re: [Pharo-project] [squeak-dev] Re: Rewriting an Input/EventSensor code

by Igor Stasenko

2009/3/21 Igor Stasenko <siguctua(a)gmail.com>: > 2009/3/21 John M McIntosh <johnmci(a)smalltalkconsulting.com>: >> >> On 21-Mar-09, at 3:09 AM, Igor Stasenko wrote: >> >>> Right, but here we're talking about doing such conversion much more >>> earlier (at event source object), >>> so then event sensor already deals with first class event objects. >>> I want to know, if such scheme (which i described in first post) is >>> plausible. >> >> For the iPhone VM I return a complex event type, which then points to >> Smalltalk objects which are the >> representation of the touch events. For location and acceleration data I >> return the actual objective-C objects. >> This data is then processed by EventSensor. >> >> If you choose to push the responsibility to the VM for creating event >> objects then you need to be cognizant >> of the fact that whatever is proposed has to change very little over time, >> otherwise you end up with the issue >> of image versus VM compatibility and the fact that VM version changes >> proceed at a slow rate. >> > Nope. I don't want VM to deal with real event objects. > VM will still use the old event buffers to deliver events to image. > But once image receiving it, it should convert it to an instance of > event as soon as source. > This is the role of EventSource class - represent VM as event source, > which producing an instances of KernelXXXEvent classes, and hiding the > details of converting raw event buffers from the eyes of higher > layers, which then going to handle the event (EventSensor/Morphic etc) > To give an example what i talking about, here the bits of prototype implementation: KernelEvent class>>initialize "Initialize the array of event types. Note, the order of array elements is important and should be same as event type returned by VM in event buffer" EventTypes := { KernelMouseEvent. KernelKeyboardEvent. KernelDragDropEvent. KernelMenuEvent. KernelWindowEvent. } ----- KernelEvent class>>fromBuffer: eventBuffer "Decode a raw VM event into an instance of KernelEvent subclass" | type | type := EventTypes at: (eventBuffer at: 1) ifAbsent: [ ^ KernelUnknownEvent from: eventBuffer ]. ^ type new from: eventBuffer ----- KernelEvent>>from: buffer "Initialize an event instance from raw event buffer. Note, all subclasses should call super to initialize fields correctly" eventType := buffer at: 1. timeStamp := buffer at: 2. timeStamp = 0 ifTrue: [timeStamp := Time millisecondClockValue]. windowIndex := buffer at: 8. ---- KernelMouseEvent>>from: buffer super from: buffer. position := Point x: (buffer at: 3) y: (buffer at: 4). buttons := buffer at: 5. modifiers := buffer at: 6. as you can see, there is nothing complicated. It simply frees underlaying event handling layers from deciphering event buffers by themselves, instead, they deal with first class even objects, with harmonized protocol. > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

March 21, 2009

Re: [Pharo-project] [squeak-dev] Re: Rewriting an Input/EventSensor code

by Igor Stasenko

2009/3/21 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > > On 21-Mar-09, at 3:09 AM, Igor Stasenko wrote: > >> Right, but here we're talking about doing such conversion much more >> earlier (at event source object), >> so then event sensor already deals with first class event objects. >> I want to know, if such scheme (which i described in first post) is >> plausible. > > For the iPhone VM I return a complex event type, which then points to > Smalltalk objects which are the > representation of the touch events. For location and acceleration data I > return the actual objective-C objects. > This data is then processed by EventSensor. > > If you choose to push the responsibility to the VM for creating event > objects then you need to be cognizant > of the fact that whatever is proposed has to change very little over time, > otherwise you end up with the issue > of image versus VM compatibility and the fact that VM version changes > proceed at a slow rate. > Nope. I don't want VM to deal with real event objects. VM will still use the old event buffers to deliver events to image. But once image receiving it, it should convert it to an instance of event as soon as source. This is the role of EventSource class - represent VM as event source, which producing an instances of KernelXXXEvent classes, and hiding the details of converting raw event buffers from the eyes of higher layers, which then going to handle the event (EventSensor/Morphic etc) > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com > =========================================================================== > > > > > -- Best regards, Igor Stasenko AKA sig.

March 21, 2009

Re: [Pharo-project] Problem with senders?

by David RÃ¶thlisberger

> I have a pharo0.1-10236dev09.02 but updated trougth: right button -> > system update -> to 10256. Nothing more installed. You should take a more recent pharo-dev or also update OB with 'ScriptLoader loadOB'. system update doesn't update OB. David > On Fri, Mar 20, 2009 at 8:07 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > > Sorry...It was totally my fault :( Sorry I nwas trying to run > Algernon, but it doesn't work :( > > I am algernon adict. > > I did this: > > Installer sm > update; > install: 'Algernon'. > Installer wiresong > project: 'ob'; > install: 'OB-Algernon'. > > > > > On Fri, Mar 20, 2009 at 7:48 AM, David RÃ¶thlisberger > <squeak(a)webcitas.ch> wrote: > > > > I am trying to see the senders of a message. I select > "startsWith:" in a > > workspace -> right button -> extended search -> senders of it > and I get > > a wallback. > > I cannot reproduce this. > What kind of image do you use? Looks like a pharo-dev; but which > version? > Did you update it manually to 10256? > #of:label: is defined for a long time in OBNavigate; which > version of OB have you loaded? > > David > > > MessageNotUnderstood: OBShowSenders class>>of:label: > > 20 March 2009 1:11:08 am > > > > VM: unix - a SmalltalkImage > > Image: Pharo0.1 [Latest update: #10256] > > > > SecurityManager state: > > Restricted: false > > FileAccess: true > > SocketAccess: true > > Working Dir /home/mariano/squeak/imagenes > > Trusted Dir /home/mariano/squeak/imagenes/secure > > Untrusted Dir /home/mariano/squeak/imagenes/My Squeak > > > > OBShowSenders class(Object)>>doesNotUnderstand: #of:label: > > Receiver: OBShowSenders > > Arguments and temporary variables: > > aMessage: of: an OBSelectorNode label: 'Senders of > > startsWith: [4]' > > exception: MessageNotUnderstood: OBShowSenders > class>>of:label: > > resumeValue: nil > > Receiver's instance variables: > > superclass: OBNavigate > > methodDict: a MethodDictionary(#browserClass->a > > CompiledMethod (3617) #noChildr...etc... > > format: 136 > > instanceVariables: nil > > organization: ('as yet unclassified' browserClass > > noChildrenMessage) > > > > subclasses: nil > > name: #OBShowSenders > > classPool: nil > > sharedPools: nil > > environment: Smalltalk > > category: #'OB-Standard-Announcements' > > traitComposition: nil > > localSelectors: nil > > > > DEVToolSet class>>browseSendersOf:name:autoSelect: > > Receiver: DEVToolSet > > Arguments and temporary variables: > > aSymbol: #startsWith: > > labelString: 'Senders of startsWith: [4]' > > autoSelectString: 'startsWith:' > > Receiver's instance variables: > > superclass: StandardToolSet > > methodDict: a MethodDictionary() > > format: 2 > > instanceVariables: nil > > organization: ('as yet unclassified') > > > > subclasses: nil > > name: #DEVToolSet > > classPool: nil > > sharedPools: nil > > environment: Smalltalk > > category: #ImageForDevelopers > > traitComposition: nil > > localSelectors: nil > > > > ToolSet class>>browseSendersOf:name:autoSelect: > > Receiver: ToolSet > > Arguments and temporary variables: > > aSymbol: #startsWith: > > titleString: 'Senders of startsWith: [4]' > > autoSelectString: 'startsWith:' > > Receiver's instance variables: > > superclass: AppRegistry > > methodDict: a MethodDictionary() > > format: 2 > > instanceVariables: nil > > organization: ('as yet unclassified') > > > > subclasses: nil > > name: #ToolSet > > classPool: nil > > sharedPools: nil > > environment: Smalltalk > > category: #'System-Applications' > > traitComposition: nil > > localSelectors: nil > > registeredClasses: an > OrderedCollection(StandardToolSet > > OTToolset DEVToolSet) > > default: DEVToolSet > > > > SystemNavigation>>browseSendersOf:name:autoSelect: > > Receiver: a SystemNavigation > > Arguments and temporary variables: > > aSelector: #startsWith: > > labelString: 'Senders of startsWith:' > > autoSelectString: 'startsWith:' > > title: 'Senders of startsWith: [4]' > > size: 4 > > senders: an OrderedCollection(a MethodReference > Algernon >> > > #isMatchingClass:gi...etc... > > Receiver's instance variables: > > browserClass: nil > > hierarchyBrowserClass: nil > > > > > > --- The full stack --- > > OBShowSenders class(Object)>>doesNotUnderstand: #of:label: > > DEVToolSet class>>browseSendersOf:name:autoSelect: > > ToolSet class>>browseSendersOf:name:autoSelect: > > SystemNavigation>>browseSendersOf:name:autoSelect: > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - > > SystemNavigation>>browseAllCallsOn: > > [] in TextMorphForShoutEditor(ParagraphEditor)>>sendersOfIt > {[self > > systemNavigation browseAllCallsOn: aSelector]} > > > TextMorphForShoutEditor(Controller)>>terminateAndInitializeAround: > > TextMorphForShoutEditor(ParagraphEditor)>>sendersOfIt > > [] in PluggableShoutMorph(PluggableTextMorph)>>sendersOfIt > {[textMorph > > editor sendersOfIt]} > > [] in PluggableShoutMorph(PluggableTextMorph)>>handleEdit: > {[result := > > editBlock value]} > > TextMorphForShout(TextMorph)>>handleEdit: > > PluggableShoutMorph(PluggableTextMorph)>>handleEdit: > > PluggableShoutMorph(PluggableTextMorph)>>sendersOfIt > > UndefinedObject(Object)>>perform:orSendTo: > > [] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > > {[(selArgCount := selector numArgs) = 0 ifTrue: [target > perform: > > selector] ...]} > > BlockContext>>ensure: > > CursorWithMask(Cursor)>>showWhile: > > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > > ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: > > ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: > > MouseButtonEvent>>sentTo: > > ToggleMenuItemMorph(Morph)>>handleEvent: > > MorphicEventDispatcher>>dispatchDefault:with: > > MorphicEventDispatcher>>dispatchEvent:with: > > ToggleMenuItemMorph(Morph)>>processEvent:using: > > MorphicEventDispatcher>>dispatchDefault:with: > > MorphicEventDispatcher>>dispatchEvent:with: > > ...etc... > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 21, 2009

Re: [Pharo-project] [squeak-dev] Re: Rewriting an Input/EventSensor code

by John M McIntosh

On 21-Mar-09, at 3:09 AM, Igor Stasenko wrote: > Right, but here we're talking about doing such conversion much more > earlier (at event source object), > so then event sensor already deals with first class event objects. > I want to know, if such scheme (which i described in first post) is > plausible. For the iPhone VM I return a complex event type, which then points to Smalltalk objects which are the representation of the touch events. For location and acceleration data I return the actual objective-C objects. This data is then processed by EventSensor. If you choose to push the responsibility to the VM for creating event objects then you need to be cognizant of the fact that whatever is proposed has to change very little over time, otherwise you end up with the issue of image versus VM compatibility and the fact that VM version changes proceed at a slow rate. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

March 21, 2009

Re: [Pharo-project] {Spam?} Re: I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

by Keith Hodges

Schwab,Wilhelm K wrote: > Keith, > > Interestingly, I could make only minor modifications, and write that same paragraph with Squeak as the stone wall. The Squeak community ignored many wonderful ideas Which is why we have finally got to a stage where the paradigm has shifted, even up to board level. We started with LevelPlayingField, and that enabled progress in spite of the release team. Since that took off, Squeak hasnt been standing still or closed to new ideas. Nor have those that needed fixes to the image been left stranded, with "Installer mantis". What we have lacked is a new release in image form. > over a period of years of maintenance and incremental development; When I fully joined the squeak community, who was running the release team? Yes it was exactly the same guys as are the pharo team, namely Stef, and Marcus. > IMHO, look there to explain the numerous forks. Pharo has a stated objective of breaking what needs to be broken to make progress, and it's not even at a first release yet. > And so has LevelPlayingField, it enables you to break what needs to be broken, because you can put the compatibility back into LevelPlayingField if you need to. > You seem to think that the world will be a great place if all the Squeak forks can share code. No, but I do think it will be a horrible place if we cant, and you have to think these things through and plan. "If you fail to plan, you plan to fail", I think it goes. For a start if projects like Pier and Seaside go Pharo only, then I am really up a creek. > What about VW, Dolphin, X, etc.? In the spirit of cooperation that you demand from the alpha versions of Pharo, Squeak could have, years ago, done something about its isolation of users of other dialects via its unique handling of underscores. > Agreed. Underscores has been first on my list (waiting for when I get time to hack the kernel) for three years. > The Pharo team is not being rude; they are focused on a huge task for the good of research, developers, users/customers, and Smalltalk. There is no animosity toward Squeak; there is determination to eliminate incompatibilities and cruft in general. > What is your definition of rude then? ( http://www.everything2.org/title/Americans%2520are%2520rude ) If I make a fix to a package that someone else is maintaining, I attempt to contact the maintainer and talk the change through with them. At the very least I attempt to check my fix into their repo so that they can benefit from it. Before making Sake/Packages, I discussed with the 3.10 release team, and the creator of Universes to see if we could adapt Universes to provide the needed functionality. Lex refused to relax the openness of universes or to compromise on the purely declarative approach, so Sake/Packages was born. Its called communication and recognising that some one else put their time and effort into solving the problem before on my behalf, and also the antithesis of "not invented here". Keith

March 21, 2009