- 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 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

Re: [Pharo-project] Pharo a VMs

by Schwab,Wilhelm K

Is it fair to say "all _recent_ VMs?" A few months back, I had problems with older w32 vms at least. It was obvious: complete freeze of the GUI on startup. I switched to a VM I got from 3.10 with no problems, and then switched to Bryce's Exupery VMs (win and Linux) more recently. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexandre Bergel Sent: Saturday, March 21, 2009 3:46 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo a VMs All VM on which Squeak run may be safely used with Pharo. This may change in the future with the introduction of closures. Cheers, Alexandre On 20 Mar 2009, at 21:59, Mariano Martinez Peck wrote: > Hi men! > > I know very little about VMs but I have a very simple question, which > vms are 100% compatibles with Pharo ? > > I know standard vm, cog, exupery and hydra. > > And which of them that are compatible with pharo is the most > "performant" ? > > thanks, > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ 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] Mickael system submission Slice merging problem

by Michael Rueger

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

March 21, 2009

[Pharo-project] [ANN] 10257 System Package creation

by StÃ©phane Ducasse

with this version System have now packages So far I learned that merging is quite broken when only moving between packages both merge tools do not work and this is probably a MC problem Pavel I got a conflict wiht the more general beep. I reverted and hope this is ok. What is left to do Dealing with the Tests standalone packages and the three new packages containing 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 Now leaving, let me know if this is ok. What energy spent for just creating packages. Stef

March 21, 2009