- Pharo-dev - lists.pharo.org

[Pharo-project] Default code browser
by Alexandre Bergel Dec. 19, 2009

Dec. 19, 2009

Hi! I saw many people using the package browser instead of OBSystemBrowserAdaptor, even if this last is faster and has less bug. I am just wondering whether reverting the default browser to O2PackageBrowser is not something we should consider. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

13 30

[Pharo-project] OCompletion and the O2PackageBrowser search panel problem
by Adrian Lienhard Dec. 19, 2009

Dec. 19, 2009

There is an issue with OCompletion and the O2PackageBrowser in the latest 1.0 dev image. I created issue 1635: OCompletion +O2PackageBrowser: mercury search bar backspace delete error. http://code.google.com/p/pharo/issues/detail?id=1635 Adrian

1 0

[Pharo-project] Seaside2.8 and Seaside3.0 configs online in MetacelloRepository
by Dale Henrichs Dec. 19, 2009

Dec. 19, 2009

Just published ConfigurationOfSeaside28 to http://www.squeaksource.com/MetacelloRepository. In a pharo dev image: Gofer new squeaksource: 'MetacelloRepository'; addPackage: 'ConfigurationOfSeaside28'; load. (Smalltalk at: #ConfigurationOfSeaside28) perform: #load. ConfigurationOfSeaside28 was published a while ago, but I'll mention the Seaside3.0 config for completeness: Gofer new squeaksource: 'MetacelloRepository'; addPackage: 'ConfigurationOfSeaside30'; load. (Smalltalk at: #ConfigurationOfSeaside30) perform: #load. Note that Seaside2.8 and Seaside3.0 cannot be loaded into the same image as there are class name conflicts. Both of these configurations have been successfully loaded into 'Pharo1.0rc1 #10493' and 'Squeak3.10.2-trunk' (Squeak requires manual load of configuration package:). I will be integrating ConfigurationOfSeaside28 for use with GLASS. ConfigurationOfSeaside30 is already integrated into GLASS (for GemStone/S 2.4). Dale

1 0

[Pharo-project] Need someone to commit on RoelTyper
by Mariano Martinez Peck Dec. 19, 2009

Dec. 19, 2009

Hi FrÃ©d! I fixed the _ in assignment problem in RoelTyper. I don't have access to commit as I am not as developer and the global setting in ss is read. I attach the .mcz. Can you commit it please or give me access? Thanks Mariano

1 1

[Pharo-project] Pharo IDE usability (was Re: Pharo for Professional Development)
by CÃ©drick BÃ©ler Dec. 19, 2009

Dec. 19, 2009

> > > Yep, IDE tools in Pharo are at least a few years behind what you can find > in other IDEs, at least in terms of usability. > yes and this is sad because in term of real possiblities, this is far better to me... > This is a known problem :) and there already has been a stream of > propositions, enhancements, and talks about this (I myself did a > presentation at ESUG 2009 about what I wanted). > Yes It was interesting :) I agreed on most of them (especially the "in context search" which is essential to me) > The issue was also discussed at the last Pharo sprint, and the major > problem is simply lack of resources: nobody has the time nor the money to > invest at least 2 or 3 months full work, in order to do a major clean > up/rewrite of the graphical framework for dev tools (which would be a good > first step). Now there is Morphic which is low-level, OB which is > complicated, Glamour which needs enhancements... > Yes I know all that ! That why it probably better to discuss first. Maybe the proposition to pay someone (the count me in stuff) could be used for that. Because to me this is not just a problem but the BIG problem (at least so that newcommers don't leave with a bad feeling). Pay someone for 3 months is easier than for 12 :). And you could count me in for that (to give a contribution and also to participate) :) Every Dolphin users seems enligthened by their tools. Couldn't we mimic them ? Laurent just made propositions, you too in your ESUG presentation. We should collect, organize and provide a clear view of what we expect. Then maybe pay someone or simply create a project but with clear goals. Then make this tool rock solid (even in alpha or unstable ;) ) > > However, the primary annoyance right now is the dichotomy between the OB > new framework and the O2 derived for David's work. The problem is that now, > whenever the tools changed in OB (especially refactoring support), O2 can > not follow and it breaks the tools in the package browser. > > 1) Remove O2SystemBrowser from the menu. Does anybody uses this browser? > It's the same as OBSystemBrowser, so I guess people either use > OBSystemBrowser or O2PackageBrowser. > 2) How can we backport changes from O2 into OB? > I use OB. I gave up on the package browser to have a snappier reaction. But, with all due respect, these are projects. The abstraction behind OB make some operations difficult. IMO, this could be easier to use classic rigid tool (as we ( I ) want only one big coding tool). But I actually don't care of what's behind as far as it works as defined in the future specs. > > About the taskbar: I'm more and more convinced that the taskbar does not > work well for me, in particular does not scale. I would prefer something > like the Mac Os dock. On the other hand, Algernon is a great tool to > navigate quickly to a class (unfortunately, it does not support yet the > queries as in a Mercury panel). > Mercury seems quite broken to me. I've stopped looking at it and using it. Mercury and Algernon by the way need also some kind of uniformisation. Do we start some actions in the direction of that ? What other thinks ? CÃ©drick

6 7

Re: [Pharo-project] [squeak-dev] The Trunk: Kernel-dtl.331.mcz
by Eliot Miranda Dec. 19, 2009

Dec. 19, 2009

Hi David, Interesting! To my mind that definition is incorrect. I would expect the sender of a block to be the sender of the enclosing method, in which case the definition would arguably be BlockClosure methods for accessing sender ^self home sender A block activation's caller would be it's sender slot, so within a block you might refer to thisContext caller. But what is arguably a bug in my implementation is that within a block activation thisContext sender refers to the caller (the sender of value: to the activation's block) not to the sender of the enclosing method. I think I may have screwed up badly here and that the correct implementations should be *MethodContext methods for accessing* *caller* ^closureOrNil ifNil: [self error: 'this is a method activation and so has no caller'] ifNotNil: [sender] *sender* ^closureOrNil ifNil: [sender] ifNotNil: [closureOrNil outerContext sender] *BlockClosure methods for accessing* *sender* * ^outerContext sender* and either *BlockClosure methods for accessing* *caller* * "Since a BlockClosure is by definition not an activation it does not have a caller.* * It has a sender because it is always created within the context of a method."* ^nil or *BlockClosure methods for accessing* *caller* ^self error: 'this is an inactive block and so has no caller' I believe the pre-closure definitions are *ContextPart methods for accessing* *sender* ^sender *BlockContext methods for accessing* *caller* ^sender which to my mind is missing *BlockContext methods for accessing* *sender* ^home sender What do people think the right definitions should be? On Fri, Dec 18, 2009 at 8:36 PM, <commits(a)source.squeak.org> wrote: > David T. Lewis uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-dtl.331.mcz > > ==================== Summary ==================== > > Name: Kernel-dtl.331 > Author: dtl > Time: 18 December 2009, 11:32:44 am > UUID: 20ffffda-86bc-47a7-8eae-cd11b55aa65e > Ancestors: Kernel-bs.330 > > Add BlockClosure>>sender required for MessageTally class>>tallySends: > > Harvested from Pharo (nice 4/14/2009 19:09). > > =============== Diff against Kernel-bs.330 =============== > > Item was added: > + ----- Method: BlockClosure>>sender (in category 'debugger access') ----- > + sender > + "Answer the context that sent the message that created the > receiver." > + > + ^outerContext sender! > > >

1 0

[Pharo-project] pharoImage 64 bits
by Laval Jannik Dec. 19, 2009

Dec. 19, 2009

Hi all, I made a pharoImage 64 bits, based on 11088. I would like to put it on inria gforge but I do not have administrator access. Now in this image there are 14 test failures, and 65 test errors. So it works on a VM5.0 - 64x64. For now, it is available on: http://jannik-laval.eu/assets/files/pharo64/ Cheers --- Jannik Laval ---

4 4

[Pharo-project] Issue 1633: Object allSubInstances appears to loop forever
by Stan Shepherd Dec. 19, 2009

Dec. 19, 2009

Pharo image: Pharo | Pharo-core PharoCore1.0rc1 Latest update: #10502 VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074] Steps to reproduce: 1.Object allSubInstances It appears to be repeatedly adding its current context. ...Stan OrderedCollection>>addLast: Receiver: an OrderedCollection(an Object an Object an Object an Object an Object an Object an Object...etc... Arguments and temporary variables: newObject: [] in Object class(Behavior)>>allSubInstances Receiver's instance variables: array: an Array(an Object an Object an Object an Object an Object an Object an ...etc... firstIndex: 1 lastIndex: 1173805 OrderedCollection>>add: Receiver: an OrderedCollection(an Object an Object an Object an Object an Object an Object an Object...etc... Arguments and temporary variables: newObject: [] in Object class(Behavior)>>allSubInstances Receiver's instance variables: array: an Array(an Object an Object an Object an Object an Object an Object an ...etc... firstIndex: 1 lastIndex: 1173805 [] in Object class(Behavior)>>allSubInstances Receiver: Object Arguments and temporary variables: aCollection: [] in Object class(Behavior)>>allSubInstances x: an OrderedCollection(an Object an Object an Object an Object an Object an Ob...etc... Receiver's instance variables: superclass: ProtoObject methodDict: a MethodDictionary(size 408) format: 2 instanceVariables: nil organization: ('*DynamicBindings' binding binding: hasBinding removeBinding) ('...etc... subclasses: {BalloonState. StandardFileMenuResult. UndefinedObject. Boolean. Fi...etc... name: #Object classPool: a Dictionary(#DependentsFields->a WeakIdentityKeyDictionary(MCWorkin...etc... sharedPools: nil environment: Smalltalk category: #'Kernel-Objects' traitComposition: {} localSelectors: nil ... -- View this message in context: http://n2.nabble.com/Issue-1633-Object-allSubInstances-appears-to-loop-fore… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 5

[Pharo-project] [update 1.1] #11107
by Marcus Denker Dec. 18, 2009

Dec. 18, 2009

Issue 1627: Preferences Migration Part11 Pass 1 finished !!!! All core preferences are migrated. SLICE-PreferencesMigrationPart11-AlainPlantec.11 is in inbox * migrates "windows color" "keyboard" "security" "scrolling" "keyboard" "services" "updates" groups * removes WindowColorRegistry class * ProjectLauncher readDocumentAtStartup: is here again * each model specifies its preferred color for squeak ui themes with a #patchworkUIThemeColor method * added "Kernel-SystemSettings" package

4 4

[Pharo-project] MorphTreeMorph>>mouseEnter: broken in Moose
by Oscar Nierstrasz Dec. 18, 2009

Dec. 18, 2009

I get an infinite loop of exceptions in the Moose Finder when I load Moose into the latest Pharo. LazyMorphTreeMorph does not understand keyboardFocusOnMouseDown ... Sleuthing shows: MorphTreeMorph>>mouseEnter: event "Changed to take keyboardFocusOnMouseDown preference into account." super mouseEnter: event. self wantsKeyboardFocus ifFalse: [^self]. self keyboardFocusOnMouseDown ifFalse: [self takeKeyboardFocus] But keyboardFocusOnMouseDown is not implemented anywhere in the system. What gives? Alain, it seems this method comes from you. What gives? I am unsure what to do ... - on

3 3