- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by StÃ©phane Ducasse

> Thats why I implemented a Configuration Browser which > is accessible from world menu "Tools" -> "ConfigurationBrowser". Yes I know and I want it back :) > > It is a simple tool that should easy loading without all > these Gofer and install scripts. > > Its a simple tool - depending on Pharo version XX it points to > http://www.squeaksource.com/MetaRepoForPharoXX > and displays all ConfigurationOfXYZ within that repo. > > This worked in Pharo 1.2 and works in Pharo 1.3 also. > > By default in Pharo 1.3 it opens on http://www.squeaksource.com/MetaRepoForPharo13 > - since this is empty and not filled by the community the browser > is unfortunately empty too. Yes for me this is the way to go!!! Because then we can have jenkins engine to build and validate the software for us. > > In Pharo 1.2 it showed some contents since I filled > http://www.squeaksource.com/MetaRepoForPharo12 > with copies of configs that are know to work with Pharo 1.2. > > > If you like you can (programmatically) open it on any > repository with configs you like: > > (MetacelloConfigurationBrowser new) > repository: 'http://www.squeaksource.com/MetacelloRepository'; > open > > So the idea is simple: if you have a ConfigurationOfSOMEPACKAGE > that is know to work in Pharo 1.3 then use the copy button of > Monticello browser to copy it to http://www.squeaksource.com/MetaRepoForPharo13 > > So it is a simplified SqueakMap for Monticello configs. > > If you know Seaside is working than copy the mcz's of it's > config to > http://www.squeaksource.com/MetaRepoForPharo13 > and others can easily load it without evaluating scripts > in workspaces or search in repos. > > Unfortunately nobody cared to copy the configs. > Anything that has to happen is that the community copies > the config that are tested and that are known to work. > > My fault is that it looks like I missed to answer some > questions on [1] and [2] or to make it more clear what the > tool is all about. > > This simple tool will not solve the problem of porting packages > but may raise the visibility of packages that are known to > work in a Pharo version! Nothing more. But this is an important tool for me. Now we can just fill the repository with the right configurations and this should really support the idea of a real distribution. > Bye > T. > > [1] http://forum.world.st/Configuration-Browser-is-a-mastery-td3706003.html > [2] http://stackoverflow.com/questions/6880596/how-to-browse-metacello-reposito…

Dec. 29, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by StÃ©phane Ducasse

On Dec 29, 2011, at 7:52 PM, Benoit St-Jean wrote: > 1) readily available, no ? Again what is the list of package not loading that are important for you. > 2) I was not necessarily thinking about the UI. For instance, a lot of stuff still references Preferences and break on load. So what is the point? We should have a Preferences packages with the squeak preferences? Sure it was in Deprecated 1.2. Then? Now if you do one publish it. > 3) Yeah, I do have a few DOS application that I do care about because, so far, after all those years, they're the best at doing what they were designed for an no Java (or anything else) apps have replaced them in terms of performance and features. They're mostly tools but they work great and I haven't found any decent replacement for them. Beside, this is a weak argument Stephane! Do you still need that crappy 50 years old language called COBOL ? I guess so, in some cases! No it is not. Look at Mac.

Dec. 29, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by StÃ©phane Ducasse

On Dec 29, 2011, at 7:48 PM, Benoit St-Jean wrote: > What if a class was deleted in Pharo? What if some methods are missing? What if it's referring to a Preference while we dumped this in favor of settings ? What if it's using some Morphic stuff that was cleaned up. Your comment assumes that everything on SqueakSource is outdated an unusable. You did not reply to my question: what packages do not load? > FYI, lots of packages there (that are 5 years old) ***do load cleanly*** in Squeak 4.3... > > Besides, there are LOTS of Squeak users that maintain their stuff only for Squeak without considering Pharo. How many? And we cannot force them. So what is the solution? Should we stop pharo? > Should we maintain those packages by adding some "PharoCompatibility" classes or we should start our own repository ? The way people want. Now you ****CANNOT**** imagine how this is difficult to manage a monolithic system with full of unused code and complex duplicated half done logic. > Finally, it's not because a package is 5 years old that it's not useful... If it's there and freely available, why would we throw all this code to the trash ? To reinvent the wheel ? I think we should seriously consider porting a lot of this stuff to our own repository before the distance between Squeak and Pharo gets too big. Indeed. Now nothing prevent the community to look at important packages and decide to maintain them. See the list at the end for an example. > My 2 cents. What do you mean? > > P.S. I've read this on the #pharo-project channel on IRC : "yeah, Pharo is great but nothing on SqueakSource works with it" Reply to my question: - what exact packages? - what added value? Now tell me: just compare the two next methods and tell me which you believe will let us have multitouch support for real in the future? You can also look at generateKeyboardEvent: if you are not afraid. generateMouseEvent: evtBuf "Generate the appropriate mouse event for the given raw event buffer" | position buttons modifiers type trail stamp oldButtons evtChanged | evtBuf first = lastEventBuffer first ifTrue: ["Workaround for Mac VM bug, *always* generating 3 events on clicks" evtChanged := false. 3 to: evtBuf size do: [:i | (lastEventBuffer at: i) = (evtBuf at: i) ifFalse: [evtChanged := true]]. evtChanged ifFalse: [^nil]]. stamp := evtBuf second. stamp = 0 ifTrue: [stamp := Time millisecondClockValue]. position := evtBuf third @ evtBuf fourth. buttons := evtBuf fifth. modifiers := evtBuf sixth. type := buttons = 0 ifTrue: [lastEventBuffer fifth = 0 ifTrue: [#mouseMove] ifFalse: [#mouseUp]] ifFalse: [lastEventBuffer fifth = 0 ifTrue: [#mouseDown] ifFalse: [#mouseMove]]. buttons := buttons bitOr: (modifiers bitShift: 3). oldButtons := lastEventBuffer fifth bitOr: (lastEventBuffer sixth bitShift: 3). lastEventBuffer := evtBuf. type == #mouseMove ifTrue: [trail := self mouseTrailFrom: evtBuf. ^MouseMoveEvent basicNew setType: type startPoint: (self position) endPoint: trail last trail: trail buttons: buttons hand: self stamp: stamp]. ^MouseButtonEvent basicNew setType: type position: position which: (oldButtons bitXor: buttons) buttons: buttons hand: self stamp: stamp handleMouseInputEvent: sysEvent | type oldButtons | type := sysEvent typeBasedOnPreviousEvent: self lastSystemEvent. oldButtons := self lastSystemEvent buttons. lastSystemEvent := sysEvent. type == #mouseMove ifTrue: [ ^MouseMoveEvent basicNew setType: type startPoint: self position endPoint: sysEvent trail last trail: sysEvent trail buttons: sysEvent buttons hand: self stamp: sysEvent timeStamp]. ^MouseButtonEvent basicNew setType: type position: self position which: ( oldButtons bitXor: sysEvent buttons) buttons: sysEvent buttons hand: self stamp: sysEvent timeStamp See the list at the end - XML - Soup - XMLRPC - OmniBrowser 6.2 Automatic Method Categorizer 6.3 Script Manager 6.4 Shout 6.5 OCompletion 6.6 Pharo Non Core Packages 6.7 New Inspector 6.8 Refactoring Browser 6.8.1 Programmatically Refactor Method Example 6.9 Nile 6.10 ProfStef 6.11 Metacello 6.12 Memory Monitor 6.13 Mondrian 6.14 Spy 6.15 SqueakDBX 6.16 Moose 6.17 Seaside 6.18 Pier 6.19 Magritte 6.20 Class Use Discovery 6.21 RemoteFrameBuffer 6.22 Glorp 6.23 Magma 6.24 Goods 6.25 SandstoneDB 6.26 TokyoTyrant 6.27 Cassandra 6.28 FFI 6.29 Postgres Driver 6.30 SIXX 6.31 SqueakSave 6.32 CouchDB 6.33 SPrevayler 6.34 Riak 6.35 Pharogenesis 6.36 Fuel 6.37 Monticello 6.38 Gofer 6.39 Metacello Browser 6.40 Autotest 6.41 Filesystem 6.42 HelpSystem 6.43 OSProcess

Dec. 29, 2011

[Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by Torsten Bergmann

Hi Stef >For pharo > >this is simple: create a configurationOf and publish it in >MetacelloRepository. Yes, http://www.squeaksource.com/MetacelloRepository is the common repo for the configs. >I do not have the cycles to put in place what I wanted for >Pharo1.2, Pharo1.3 distributions i.e. specific MetacelloRepositories >per version so if somebody wants to really get an impact for >Pharo he should contact me and we can discuss about the next steps. The step is simple: open the MetaRepoForPharoXX so we can copy the configs there too! If one of these configs is known to work in Pharo 1.3 it should be copied using the "copy" button of the metacello browser to the www.squeaksource.com/MetaRepoForPharo13 repo and it will automatically appear in the Configuration browser for easy load. Something like a Universe for 1.3. Unfortunately the www.squeaksource.com/MetaRepoForPharo13 is "read" only. I already asked Marcus to add me as a developer. Best would be if it would be public write. Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Dec. 29, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by StÃ©phane Ducasse

For pharo this is simple: create a configurationOf and publish it in MetacelloRepository. I do not have the cycles to put in place what I wanted for Pharo1.2, Pharo1.3 distributions i.e. specific MetacelloRepositories per version so if somebody wants to really get an impact for Pharo he should contact me and we can discuss about the next steps. Stef > > Mariano Martinez Peck wrote >> >> a clear way of knowing which project/packages are >> expected to work or not in Pharo. If you take a random package/project >> from >> SS there is no way to know that. Having a Pharo catalog/certified >> packages/projects would help here. >> > > Yes, something is needed. Squeak has revived SqueakMap and documented a > procedure. See > http://forum.world.st/How-to-publish-software-for-Squeak-4-3-td4240339.html > > -- > View this message in context: http://forum.world.st/Good-practicces-Looking-for-examples-tp4231211p424348… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 29, 2011

[Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by Torsten Bergmann

While I agree that we have to be radical with throwing out ugly code and the like if we want to reinvent the future ... but if we do not care about external packages than we just work towards a clean Pharo platform that is of no use for anyone. I dont want Pharo to be fully compatible to Squeak or older Pharo versions but we have to find a way for people to follow the Pharo train and move there code forward toward a cleaner and better state also. And to see which packages are working and which not. Otherwise anyone of us will try these packages on his own, see them crash or repair them on his own way. And yes - I liked the concept of Squeakmap - install the things that are know to work right from within your image. Thats why I implemented a Configuration Browser which is accessible from world menu "Tools" -> "ConfigurationBrowser". It is a simple tool that should easy loading without all these Gofer and install scripts. Its a simple tool - depending on Pharo version XX it points to http://www.squeaksource.com/MetaRepoForPharoXX and displays all ConfigurationOfXYZ within that repo. This worked in Pharo 1.2 and works in Pharo 1.3 also. By default in Pharo 1.3 it opens on http://www.squeaksource.com/MetaRepoForPharo13 - since this is empty and not filled by the community the browser is unfortunately empty too. In Pharo 1.2 it showed some contents since I filled http://www.squeaksource.com/MetaRepoForPharo12 with copies of configs that are know to work with Pharo 1.2. If you like you can (programmatically) open it on any repository with configs you like: (MetacelloConfigurationBrowser new) repository: 'http://www.squeaksource.com/MetacelloRepository'; open So the idea is simple: if you have a ConfigurationOfSOMEPACKAGE that is know to work in Pharo 1.3 then use the copy button of Monticello browser to copy it to http://www.squeaksource.com/MetaRepoForPharo13 So it is a simplified SqueakMap for Monticello configs. If you know Seaside is working than copy the mcz's of it's config to http://www.squeaksource.com/MetaRepoForPharo13 and others can easily load it without evaluating scripts in workspaces or search in repos. Unfortunately nobody cared to copy the configs. Anything that has to happen is that the community copies the config that are tested and that are known to work. My fault is that it looks like I missed to answer some questions on [1] and [2] or to make it more clear what the tool is all about. This simple tool will not solve the problem of porting packages but may raise the visibility of packages that are known to work in a Pharo version! Nothing more. Bye T. [1] http://forum.world.st/Configuration-Browser-is-a-mastery-td3706003.html [2] http://stackoverflow.com/questions/6880596/how-to-browse-metacello-reposito… -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

Dec. 29, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by csrabak＠bol.com.br

Em 29/12/2011 16:48, Benoit St-Jean < bstjean(a)yahoo.com > escreveu: Benoit, You rise some important points, this is my attempt to contribute: > What if a class was deleted in Pharo?Â We should get a thorough analysis of the case and understand if the deleted class does indeed makes its lacking or if the package in SS has to be re-engineered to be compatible with the Pharo view. Then two outcomes are possible: a recipe for the similar cases where the lack of the deleted class is created or we understand the deletion as a mistake and reintroduce or replace it with a new implementation of it. > What if some methods are missing?Â Same general methodology: were they suppressed but replaced by others? Or were they removed due being only specific to some package and did not belong to the places they were in the classes hierarchy? Perhaps were they just 'syntactic sugar' and thus have to be replaced by another code snippet? > What if it's referring to a Preference while we dumped > this in favor of settings ?Â What if it's using some Morphic stuff > that was cleaned up.Â Your comment assumes that everything on > SqueakSource is outdated an unusable.Â > > FYI, lots of packages there (that are 5 years old) ***do load > cleanly*** in Squeak 4.3... Makes sense, after of all there is called SqueakSource, isn't it? > Besides, there are LOTS of Squeak users that maintain their stuff > only for Squeak without considering Pharo.Â To which I think the whole Stef's post applies! If _we_ Pharo comunity long or want that package in our changed Smalltalk, we should adapt it. Our wage is that in time the package originators may become convinced of the advantages of: or switching to Pharo, or maintaining in both 'dialects'. > Should we maintain those > packages by adding some "PharoCompatibility" classes or we should > start our own repository ? I'm a firm believer that '"PharoCompatibility" classes' are no-no. We rather have a repo which has packages adapted to Pharo as Stef described. > Finally, it's not because a package is 5 years old that it's not > useful...Â If it's there and freely available, why would we throw > all this code to the trash ?Â To reinvent the wheel ?Â I think we > should seriously consider porting a lot of this stuff to our own > repository before the distance between Squeak and Pharo gets too > big. I think each package needs to be considered in isolation, no general rule can be created for all cases without incurring in the risk of going irrational... My 0.0199999.... -- Cesar Rabak

Dec. 29, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by Benoit St-Jean

1) readily available, no 2) I was not necessarily thinking about the UI.Â For instance, a lot of stuff still references Preferences and break on load. 3) Yeah, I do have a few DOS application that I do care about because, so far, after all those years, they're the best at doing what they were designed for an no Java (or anything else) apps have replaced them in terms of performance and features.Â They're mostly tools but they work great and I haven't found any decent replacement for them.Â Beside, this is a weak argument Stephane!Â Do you still need that crappy 50 years old language called COBOL ?Â I guess so, in some cases! ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) >________________________________ > From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >To: Pharo-project(a)lists.gforge.inria.fr; Benoit St-Jean <bstjean(a)yahoo.com> >Sent: Thursday, December 29, 2011 11:07:13 AM >Subject: Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps ! > >Benoit > >Let us start with some concrete questions >Â Â Â - Do you have a concrete list of package not working? >Â Â Â - Then do you prefer to have a vectorial UI with zomable facilities, clean code or just and old fuzzy bitmap. >Â Â Â Same question: do you prefer Zinc and a nice HTTP layer or and old pre internet library? >Â Â Â - Do you expect DOS applications to work nowadays? Do you care? > >Stef > > >On Dec 29, 2011, at 3:44 PM, Benoit St-Jean wrote: > >> I was wondering what is planned regarding packages available on SqueakSource and Pharo.Â More and more packages can't load in Pharo and it gets more and more frustrating not being able to load anything without having to add/modify methods/classes all over the place so those packages can load properly in Pharo.Â Are we looking at a Pharo-only kind of SqueakSource in the future ?Â > >Probably. >With quality-rules run automatically, style checking rules and some more. >And with tests of course and automatically. > >We should have a Pharo distribution. I will come. > >> Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every package is adding more complexity than what is needed.Â I know backward compatibility was thrown away from the start to avoid compromises in Pharo but how do we take care of the fact that as each day passes, less and less stuff from SqueakSource is usable in Pharo ? >> >> tia >>Â >> ----------------- >> Benoit St-Jean >> Yahoo! Messenger: bstjean >> A standpoint is an intellectual horizon of radius zero. >> (Albert Einstein) > > > >

Dec. 29, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by Benoit St-Jean

What if a class was deleted in Pharo?Â What if some methods are missing?Â What if it's referring to a Preference while we dumped this in favor of settings ?Â What if it's using some Morphic stuff that was cleaned up.Â Your comment assumes that everything on SqueakSource is outdated an unusable.Â FYI, lots of packages there (that are 5 years old) ***do load cleanly*** in Squeak 4.3... Besides, there are LOTS of Squeak users that maintain their stuff only for Squeak without considering Pharo.Â Should we maintain those packages by adding some "PharoCompatibility" classes or we should start our own repository ? Finally, it's not because a package is 5 years old that it's not useful...Â If it's there and freely available, why would we throw all this code to the trash ?Â To reinvent the wheel ?Â I think we should seriously consider porting a lot of this stuff to our own repository before the distance between Squeak and Pharo gets too big. My 2 cents. P.S.Â I've read this on the #pharo-project channel on IRC : "yeah, Pharo is great but nothing on SqueakSource works with it" Â ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) >________________________________ > From: Igor Stasenko <siguctua(a)gmail.com> >To: Pharo-project(a)lists.gforge.inria.fr; Benoit St-Jean <bstjean(a)yahoo.com> >Sent: Thursday, December 29, 2011 11:02:01 AM >Subject: Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps ! > >On 29 December 2011 15:44, Benoit St-Jean <bstjean(a)yahoo.com> wrote: >> I was wondering what is planned regarding packages available on SqueakSource >> and Pharo.Â More and more packages can't load in Pharo and it gets more and >> more frustrating not being able to load anything without having to >> add/modify methods/classes all over the place so those packages can load >> properly in Pharo.Â Are we looking at a Pharo-only kind of SqueakSource in >> the future ? >> >> Besides, having to handle platform specific (i.e. Pharo vs Squeak) for every >> package is adding more complexity than what is needed.Â I know backward >> compatibility was thrown away from the start to avoid compromises in Pharo >> but how do we take care of the fact that as each day passes, less and less >> stuff from SqueakSource is usable in Pharo ? >> >The recipe is simple: maintenance. > >If you really care, spend time maintaining packages you using. >If nobody cares to maintain the software, it is dead. >It is only a matter of time for it to get broken. >We cannot give any guarantee that something which worked fine 10 years >ago will keep working today, >without keeping everything unchanged. > >If you have a garden and planted a rose there, do you expect that 5 >years later it will still grow there, without you taking care of it? > >-- >Best regards, >Igor Stasenko. > > >

Dec. 29, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by Sean P. DeNigris

Mariano Martinez Peck wrote > > a clear way of knowing which project/packages are > expected to work or not in Pharo. If you take a random package/project > from > SS there is no way to know that. Having a Pharo catalog/certified > packages/projects would help here. > Yes, something is needed. Squeak has revived SqueakMap and documented a procedure. See http://forum.world.st/How-to-publish-software-for-Squeak-4-3-td4240339.html -- View this message in context: http://forum.world.st/Good-practicces-Looking-for-examples-tp4231211p424348… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 29, 2011