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

Re: [Pharo-project] About ConfigurationOfXMLSupport

by StÃ©phane Ducasse

Then I do not understand how a stable version can be defined as stable: spec <symbolicVersion: #'stable'> spec for: #'common' version: '1.2.1'. spec for: #'gemstone' version: '1.1.8'. Because I would really prefer to get stable: spec <symbolicVersion: #stable> spec for: #gemstone version: '1.5'. spec for: #'squeak' version: '1.4'. spec for: #'pharo1.0.x' version: '1.5'. spec for: #'pharo1.1.x' version: '1.5'. spec for: #'pharo1.2.x' version: #development. Because like that we can load it in different versions. Am'I wrong? Stef On Dec 29, 2011, at 11:04 PM, StÃ©phane Ducasse wrote: > Hi guys > > I thought that XMLSupport was about parsing and XMLNode traversal. > So why the configuration contains references to SIXX and Grease Core? > > Stef >

Dec. 29, 2011

[Pharo-project] About ConfigurationOfXMLSupport

by StÃ©phane Ducasse

Hi guys I thought that XMLSupport was about parsing and XMLNode traversal. So why the configuration contains references to SIXX and Grease Core? Stef

Dec. 29, 2011

[Pharo-project] Help: #pointersTo broken (and fix, but I don't understand why it fixes)

by Mariano Martinez Peck

Hi guys. #pointersTo is broken and that's why some tests of PointerFinderTest are yellow. Few weeks ago, I changed #pointsTo: so that it does not perform primitive 142 but it delegates to a new method #instVarsInclude: which has the primitive 132 now. Before this change, if I open a workspace and execute the following: | aDate | aDate := Date new. aDate pointersTo if you execute that several times, it is ALWAYS empty. After the change, in different executions answer not only empty but some MethodContext instances whose method is (ProtoObject>>#pointsTo: "a CompiledMethod(220463104)"). Most of the times, in these MethodContext instances, the receiver are the instance variables of aDate So #pointersTo answer, for example, an Array(CompiledMethod(ProtoObject)>>pointsTo: Time(ProtoObject)>>pointsTo: Duration(ProtoObject)>>pointsTo:) This causes #pointersToExcept: to have a different behavior. If in #pointersToExcept: I replace #pointsTo: with #instVarsInclude: it works perfect. The only difference is that one includes the class and the other one doesn't. BUT, in this example, the receiver is aDate, hence, there shouldn't be any object which class is #aDate. In fact, if I put a "(anObj class == self) ifTrue: [ self halt. ]" it NEVER HALT. That makes sense. But I don't understand then why with #pointsTo: it doesnt work and with #instVarsInclude: it works perfect. Any idea? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

Dec. 29, 2011

Re: [Pharo-project] TWM doesn't work without keymappins and keymappings doesn't work

by Guillermo Polito

Oh yeah. I always do the same stupid mistake u.u . I have to start using metacello browser d: Thanks! A new configuration with both (recovered) 2.0 and 2.1 versions is in MetacelloRepository. Guille On Wed, Dec 28, 2011 at 9:54 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > Sean P. DeNigris wrote > > > > In Pharo 1.3, I get "MetacelloProjectSpecLoadError: No version found for > > '2.0' of ConfigurationOfKeymapping" > > > > It looks like Keymapping's version 2.1 overwrote 2.0. If that's what > happened, the attached fileout is fixed, but Guillermo can you check it? > > http://forum.world.st/file/n4241451/ConfigurationOfKeymapping.st > ConfigurationOfKeymapping.st > > -- > View this message in context: > http://forum.world.st/TWM-doesn-t-work-without-keymappins-and-keymappings-d… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Dec. 29, 2011

Re: [Pharo-project] Pharo Launcher app

by Fernando Olivero

Noury, i believe i could build the app targeted a snow leopard as well. Sean, how you would launch the pharo launcher written in pharo? Still need to point to a vm + image, so this was the problem i was solving with this app. I assume that writing such an app, for the remaining OS shouldn't pose a challenge. Fernando On Wed, Dec 28, 2011 at 6:28 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Noury Bouraqadi-2 wrote >> >> Sounds Cool. It's a pity that it's for Lion only. >> > > Where could we find a platform to write it in that would work on any major > modern OS... Oh, yeah, someone could write it in Pharo ;-) > > -- > View this message in context: http://forum.world.st/Pharo-Launcher-app-tp4238576p4240646.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 29, 2011

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

by StÃ©phane Ducasse

Hi torsten I'm not admin so I asked marcus to add us :). I created MetaReportForPharo14 and you are admin. So we can start to play. I would like to load your browser in 1.4. Does it make sense? Stef On Dec 29, 2011, at 10:48 PM, StÃ©phane Ducasse wrote: >> >> 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. > > Ok I will do that. I thought it was.

Dec. 29, 2011

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

by StÃ©phane Ducasse

On Dec 29, 2011, at 10:39 PM, Torsten Bergmann wrote: > 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! this is not there? > 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. Yes I know I wan that > > 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. Ok I will do that. I thought it was. > > 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

> 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