- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: [Moose-dev] Re: ConfigurationOfMetacello and OB
by Lukas Renggli March 4, 2010

March 4, 2010

Sorry, forgot to add the Pharo list ... ---------- Forwarded message ---------- From: Lukas Renggli <renggli(a)gmail.com> Date: 4 March 2010 20:13 Subject: Re: [Moose-dev] Re: ConfigurationOfMetacello and OB To: Related to the development of Moose and other related tools <moose-dev(a)iam.unibe.ch> I am looking into this. I reply to the Pharo list, I think the Moose list is the wrong one. The refactoring engine seems to work well. All tests pass. OmniBrowser is more difficult. There are 7 tests failing, and there are 8 errors. There is a large number of deprecated code that OB is calling. What am I supposed to do so that OB continues to work in Pharo 1.0 and 1.1? Can I expect that people have the deprecated warnings disabled? - How are menus registered? TheWorldMenu does not exist any longer. - What is the replacement for #intialExtent? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch -- Lukas Renggli http://www.lukas-renggli.ch

5 9

Re: [Pharo-project] [Moose-dev] Re: Fwd: Re: ConfigurationOfMetacello and OB
by Lukas Renggli March 4, 2010

March 4, 2010

> Yes, an OBPlatform for each major version... Well, the problem is that ... OBPlatform OBMorphicPlatform OBShoutPlatform That doesn't really work without an explosion of classes and I don't feel like changing all that :-( Lukas > > > Dale > -- Lukas Renggli http://www.lukas-renggli.ch

2 3

Re: [Pharo-project] ConfigurationOfMetacello and OB
by Dale Henrichs March 4, 2010

March 4, 2010

Alexandre, You _can_ load Metacello without requiring OB. The current default is to _not_ include the tools (at one point in time OB was required, but with more recent versions that is no longer the case). I just loaded ConfigurationOfMetacello into PharoCore-1.1-11239 this morning: Gofer new gemsource: 'metacello'; package: 'ConfigurationOfMetacello'; load. ConfigurationOfMetacello project latestVersion load ...doesn't help with not being able to load OB though:) Dale ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | Hi all, | | Installing ConfigurationOfMetacello requires the installation of OB. | | However, OB does not properly install in Core 1.1. | Is there something we can do against that? It would be great to do | so. | | Cheers, | Alexandre | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | 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

1 0

[Pharo-project] ConfigurationOfMetacello and OB
by Alexandre Bergel March 4, 2010

March 4, 2010

Hi all, Installing ConfigurationOfMetacello requires the installation of OB. However, OB does not properly install in Core 1.1. Is there something we can do against that? It would be great to do so. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

[Pharo-project] String>>beginsWith: with empty strings issue
by Gabriel Cotelli March 4, 2010

March 4, 2010

Hi, I noticed that 'pharo' beginsWith: '' returns false. Is that Ok? I expect that this returns true, because the empty string is a prefix (and suffix) of any other string. Similar behavior exhibits endsWith:. This seems a bug to me. What do you think? In case we acknowledge it's a bug I can post an entry in the issue tracker and tonight upload a SLICE with the fix. Regards, Gabriel

4 8

[Pharo-project] about code formatting in pharo
by Torsten Bergmann March 4, 2010

March 4, 2010

>what do you mean by now used? >Did they change that recently? According to http://planetmisc.squeak.org/ a new package Compiler-cmm.131.mcz is now in Squeak inbox and may find its way into trunk ... >I don't like Beck's rule "3. Rectangular Block" vs. >So for me personally, Beck's rule 3 is the one that looks better. And there we have them: discussions on what looks better :) Bye T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

10 15

[Pharo-project] SmalltalkImage current vs Smalltalk : plan B
by Nicolas Cellier March 4, 2010

March 4, 2010

For now, plan A has more votes than plan B. plan A: move all SmalltalkImage methods back into SystemDictionary in trunk. Let SmalltalkImage current ^Smalltalk for crossfork compatibility plan B: Smalltalk class = SmalltalkImage, Smalltalk globals class = SystemDictionary. Use messages indirections like: Smalltalk vm imagePath Smalltalk commandLine optionAt: 2. etc... (see previous thread) At 1st step, they are not much different: both unify Smalltalk and SmalltalkImage current API. Also Plan A is much simpler, thus attractive. But: - Plan A is essentially coming back to 3.8 statu quo. - Plan B is essentially introducing message indirections Advantages of plan B I see for the future: - cleaner separation of concerns - less vulnerable to refactoring (thanks to messages indirection) - compatibility with other forks (Pharo + Cuis + Squeak3.8 + ...) easier thru messages Last, I do not desesperate to sell plan B to other forks. See the outline pf plan B below. So do you still buy plan A ? Nicolas ------------------------------------------ OUTLINE OF PLAN B : ------------------------------------------ PART I - Fusion of the 2 APIs in 1 1) add a globals instance variable to SmalltalkImage 2) initialize this instance variable SmalltalkImage current globals: Smalltalk 3) implement SystemDictionary methods in use to SmalltalkImage, and redirect them through globals MessageSentToGlobalFinder testMessagesSentToSmalltalk may help 4) initialize Smalltalk at: Smalltalk put: SmalltalkImage current. PART II - Refactoring 1) add a few messages in SmalltalkImage (vm ^self) 2) refactor users of SmalltalkImage current -> Smalltalk vm (or Smalltalk commandLine or...) This is the compatibility layer which will enable cross fork compatibility PART III - Provide cross fork compatibility layers: simple, Cuis and Pharo and Squeak3.8 and... just have to respond to Smalltalk vm (and a few others) either ^self or ^SmalltalkImage current or whatever they prefer PART IV - deeper refactorings 1) split SmalltalkImage at will (no precipitation good Rationale SHALL be provided). 2) introduce other Smalltalk hooks for not so well known classes (SystemNavigation / SourceFiles etc...)

3 4

March 4, 2010

Hi guys We just released a new chapter for Pharo by Example Vol.2 on Exceptions http://pharobyexample.org/ Let us know what you think. Stef

8 20

[Pharo-project] Problems using java code importer with inFusion under windows
by Fabrizio Perin March 4, 2010

March 4, 2010

Hi, i was using moose in windows and i had an error trying to use the function "import from Java source with inFusion". Seems that OSProcess doesn't work properly. To reproduce the error just try to import java code using this function in the Moose panel in windows. In Mac i never had problem using that cool function. Anybody can help me to figure out where the problem is? Thanks in advance for the support, Fabrizio PS: Here the stack trace: --- The full stack --- UndefinedObject(Object)>>doesNotUnderstand: #nextPutAll: ExternalWindowsOSProcess>>value ExternalWindowsOSProcess class>>command: WindowsProcess>>command: WindowsProcess>>waitForCommand: OSProcess class>>waitForCommand: MooseImportFromJavaSourceFilesWizard>>validateImportation [] in MooseImportFromJavaSourceFilesWizard>>performTerminateButtonAction [] in ProgressInitiationException>>defaultAction BlockClosure>>ensure: ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: PSUIManager(MorphicUIManager)>>displayProgress:at:from:to:during: MooseImportFromJavaSourceFilesWizard>>performTerminateButtonAction WizardLastPane>>terminateButtonAction PluggableButtonMorphPlus(PluggableButtonMorph)>>performAction PluggableButtonMorphPlus>>performAction [] in PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: Array(SequenceableCollection)>>do: PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: PluggableButtonMorphPlus>>mouseUp: PluggableButtonMorphPlus(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableButtonMorphPlus(Morph)>>handleEvent: PluggableButtonMorphPlus(Morph)>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: [] in PasteUpMorph>>becomeActiveDuring: BlockClosure>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess [] in BlockClosure>>newProcess

7 8

[Pharo-project] Quickly getting the method call stack depth
by Alexandre Bergel March 3, 2010

March 3, 2010

Dear List, I was wondering whether there is a fast way to know the method call stack depth. Something like what follows does the job: -=-=-=-=-=-=-=-=-=-=-=-= | depth running | depth := 0. running := thisContext. [ running sender notNil ] whileTrue: [ running := running sender. depth := depth + 1]. depth -=-=-=-=-=-=-=-=-=-=-=-= But it is rather slow. Anyone has a suggestion? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

6 12