August 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Monticello changes not working
by Mariano Martinez Peck Aug. 5, 2012

Aug. 5, 2012

Hi guys. I am the only one that noticies that "Changes" is showing whatever but the correct changes? I think this is a stop-the-world-issue because I cannot commit anything because I cannot really see and make sure of what I changed. You should not merge ether if you cannot clearly see what has been changed. thanks -- Mariano http://marianopeck.wordpress.com

5 6

[Pharo-project] Config browser
by Schwab,Wilhelm K Aug. 5, 2012

Aug. 5, 2012

Just getting to 1.4 summer (apologies to those down under) and noted a long list of configs that seem to load cleanly - huge progress!!

1 0

[Pharo-project] ODBC schema acess - please test
by Schwab,Wilhelm K Aug. 5, 2012

Aug. 5, 2012

see OdbcConnection>>tables, #columnsForTable:owner:, #serverName, etc.

1 0

[Pharo-project] Question on KeyMapping
by GOUBIER Thierry Aug. 5, 2012

Aug. 5, 2012

Hi, is there a reason for, when dispatching among targets in KMDispatcher, 1- the instanceTarget is at the back of the list of keymapObservers (so that you can't override a class shortcut with an instance one (except randomly, see 2) ?) 2- the list of keymapObservers is a Set ? (so that target matching order is as random as possible, given that's a first matched dispatch ?) Thierry

1 0

[Pharo-project] Spec default row layout
by Sean P. DeNigris Aug. 5, 2012

Aug. 5, 2012

SpecLayout composed newRow: [ :spec1 | spec1 add: #debugModeSwitch ] height: 30; newRow: [ :spec2 | spec2 add: #jobListModel ] "origin: 0@0 corner: 1@1 offsetOrigin: 0@30 offsetCorner: 0@0"; yourself. If I uncomment the comment, it lays out okay. With that part commented out, the second row covers the whole window and blocks out the first. I was expecting that adding a row would begin where the previous left off (i.e. that the 30 offset would be implied). Could that be made the default? -- View this message in context: http://forum.world.st/Spec-default-row-layout-tp4643245.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 5

[Pharo-project] Configuration Browser feedback
by Ben Coman Aug. 5, 2012

Aug. 5, 2012

Just thinking that the second tab of the Configuration Browser being called "Untrusted" is a bit harsh and not really socially engaging. "Community" has a better feel to me. And perhaps not "Configurations" for the first tab either, since both tabs are configurations. Perhaps "Core" or "Supported" or "Vetted" or "Gold" or something similar. Also, what would be really fantastic would be some description of each configuration being displayed in a pane on the right hand side. There are A LOT of configurations listed there - which is great - but I don't feel inclined to go looking up every single one to see if they interest me. Sometimes what gets people interested in trying out new things is that it just catches their eye in casual browsing. I guess a pre-requisite of that would be the ConfigurationOf file containing such a description, as well as perhaps something on the back end server that caches those descriptions into one file. cheers -ben

5 5

[Pharo-project] [ENH]: FileReference subclasses
by Sean P. DeNigris Aug. 5, 2012

Aug. 5, 2012

Thoughts? Comments? Opinions? Issue 6525: [ENH]: FileReference subclasses http://code.google.com/p/pharo/issues/detail?id=6525 Different types of files have different behaviors. Currently, we need to add all those behaviors (e.g. #fileIn) to FileReference, even though they only make sense with a fraction of instances. I propose that we match the filename against FileReference subclasses. The following is a conversation starter. It works with strings... Usage: '/Users/sean/start.st' asFileReference. "anStFileReference" '/Users/sean/start.unknown' asFileReference. "aFileReference" 'file:///Users/me.st' asUrl asFileReference "not handled by current implementation, will default to aFileReference" For example, I can create a custom .st file subclass, with: StFileReference>>isClassFor: aResolvable (aResolvable isKindOf: String) ifFalse: [ ^ false ]. "just a hack to avoid DNU" ^ aResolvable endsWith: '.st'. Enhancing the following method will catch aString asFileReference, but not e.g. aFileUrl asFileReference: FileSystem>>referenceTo: aResolvable "Answer a reference to the argument from the context of the receiver filesystem. Example: FSFilesystem disk referenceTo: 'plonk.taz'" | referenceClass | referenceClass := FileReference allSubclasses detect: [ :e | e isClassFor: aResolvable ] ifNone: [ FileReference ]. ^ referenceClass fileSystem: self path: (self pathFromObject: aResolvable). -- View this message in context: http://forum.world.st/ENH-FileReference-subclasses-tp4643116.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 4

Aug. 5, 2012

Hi guys PackageInfo has a large APi that is often not used. So I would suggest that we reduce the PackageInfo API first because it will lower the stress on RPackage to be offer a compatible interface. All the methods in the compatibility should somehow disappear or only serve as purpose to help temporary backwards compat. What do you think? Stef

5 17

[Pharo-project] RPackage does not update extension methods to removed classes
by Mariano Martinez Peck Aug. 5, 2012

Aug. 5, 2012

Hi Stef. I notice that RPackage does not update the extension methods of removed classes. It is easy to reproduce in Pharo 2.0 by doing: (RPackageOrganizer default packageNamed: 'FreeType') allDefinedExtensionMethods (this fails because FreeType used to have a extension method in TTCFont which was removed) Or step by step: 1) Create package PackageX. 2) Create package PackageY and ClassY. 3) Create in ClassY a extension method with category *PackageX. If you now browse the instVar "classExtensionSelectors" of PackageX you will see ClassY. 4) Remove ClassY 5) notice that 'classExtensionSelectors' from PackageX still references ClassY. In fact, if you ask its extension methods you will have a KeyNotFound #ClassY in Smalltalk globals ;) So...I guess this is a bug. If true, I open an issue. Cheers, -- Mariano http://marianopeck.wordpress.com

2 7

Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes?
by stephane ducasse Aug. 4, 2012

Aug. 4, 2012

Hi Philippe sounds quite good to me >> Thanks for considering this a friendly and positive thread. > > So instead of lamenting the state of the world I went ahead and wrote > some code. To find out what breaks in Seaside I created new packages > for every Pharo package that didn't work. So I ended up with: > > - Grease-Pharo20-Core > - Grease-Tests-Pharo20-Core > - Seaside-Pharo20-Core > - Seaside-Tests-Pharo20-Core > - Javascript-Pharo20-Core > > You can find them in the Seaside 3.1 repository [1]. I'm not really > sure this was a clever idea but it sounded better than writing a long > mail. > > Things I ran into: > - file system (obviously) > - SystemAnnouncer > - BlockContext is gone BlockContext has been abandoned some earth cycles ago already :) > - extension methods are now present on String > - different Float number printing this is strange > File system and SystemAnnouncer are only used by file library. > > Right now two tests fail because the GRPackage dependencies are > inconsistent due to a mix of Pharo and Pharo20 packages. The rest > seems to work, also functionally. So this is a good news. > > Things I didn't test or even load: > - OB tooling > - Slime/SLint tooling > > [1] http://www.squeaksource.com/Seaside31 > > Cheers > Philippe > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >

1 0