- Pharo-dev - lists.pharo.org

[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

[Pharo-project] About the migration from PackageInfo to RPackage
by StÃ©phane Ducasse Aug. 5, 2012

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

[Pharo-project] What is the plan with Pharo changes?
by Mariano Martinez Peck Aug. 4, 2012

Aug. 4, 2012

Hi guys. PLEASE: I DON'T WANT TO START A WAR. I am just concerned about Pharo and it's future. I am totally in favor of making progress even if it breaks compatibility. I am all in favor of having to spend time and effort in updating projects to use latest Pharo changes. Today I faced a couple of problems with Metacello and Pier. Most problems were related to: 1) SystemChangeNotifier -> SystemAnnouncer 2) FileDirectory -> FileSystem so...after a couple of fixes, I was able to make them both to work in last Pharo version. So, DO NOT GO OFFTOPIC please. My question is, how can we make sure that we are not all trying to updated existing packages? I mean, I have updated Metacello (a part of it) and Pier. So what do we do? where do I commit without affecting all those not using Pharo 2.0 ? how can others take advantage of it? thanks guys. -- Mariano http://marianopeck.wordpress.com

6 18

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

Aug. 4, 2012

Philippe, Cami provided a port of FileTree to Pharo-2.0 within an hour... Getting FileTree to run is not the issue ... for me ... FileTree was written to be very _dependent_ on FileDirectory and needs to be rewritten... I think the Pharo folks are correct that most applications will not be hit nearly as hard by the removal of FileDirectory. Dale ----- Original Message ----- | From: "Philippe Marschall" <philippe.marschall(a)gmail.com> | To: "Seaside - general discussion" <seaside(a)lists.squeakfoundation.org> | Cc: Pharo-project(a)lists.gforge.inria.fr | Sent: Saturday, August 4, 2012 10:27:42 AM | Subject: Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes? | | On Sat, Aug 4, 2012 at 11:21 AM, Mariano Martinez Peck | <marianopeck(a)gmail.com> wrote: | > Hi all. I am answering to all together: | > | > Stef: Yes, I imported and loaded the Pier of DBX website in Pharo | > 2.0 with | > seaside and magritte. With 5 minutes of opening debuggers and | > change things | > I was able to correctly make it work (at least, my app, I didn't | > run all | > tests to see). | > | > Dale: We don't want to just help you with "hacks", that why I send | > this | > email and several others, to see what others think so that can find | > better | > and non-hacky solutions. So, let's try to find good solutions: | > | > 1) does it help if we put back FildeDirectory and we remove it | > later ? so | > that you have time to update Metacello and that we can still use | > Metacello | > :) | > 2) for the SystemChangeNotifier does it make sense to delegate to | > the | > closures? [ xx ] valueWithoutSystemNotifications. Or we add a | > #doSilently: | > and we add a MetacelloPharo20Platform that overrides the behavior. | > 3) as Janko said, what about improving/using Grease/Sport for this | > purpose? | > do they provide something for this? could this be added? | > 4) Should we integrate Metacello in the image with our changes | > until you | > have time and find a good solution that works everywhere? Maybe if | > we do 1) | > it is not very necessary. | > | > 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 | - extension methods are now present on String | - different Float number printing | | 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. | | 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

Re: [Pharo-project] 'self halt' safety net
by Fernando Olivero Aug. 4, 2012

Aug. 4, 2012

What about a Nautilus plugin, that allows browsing all the methods that send #halt, #flag:,#log:? (the "development" messages). Since finding all the halts, doesn't seem something that needs to be performed all the time, an optional Nautilus plugin would suffice. Fernando On Sat, Aug 4, 2012 at 3:02 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Mariano Martinez Peck wrote >> >>> Another thought, are there any plans for a "breakpoint" facility, so that >>> I don't dirty a package by only inserting 'self halt' to aid debugging. >> it already exists. Right click on a method -> Add breakpoint >> > > I, too would love to have the features you suggest. However, as it stands, I > would strongly advise against using breakpoints (someone definitely let me > know, maybe this is not still a problem in 2.0). In my experience, they are > incredibly buggy. Historically: > * if you add a breakpoint in one tool, and try to disable it in another, it > may still be active; and who remembers what tool they enabled it in??? > * there is very little feedback as to when a breakpoint is enabled > - no icon in the browsers > - the menu item was "toggle breakpoint" instead of dynamically "enable" > vs. "disable" > > In all, I found it very confusing to figure out when a breakpoint was > enabled, and how to disable. Of course, anyway, these are not breakpoints as > typically offered by an IDE, which can be attached to any statement, but > only at the method level. > > Cheers, > Sean > > > > -- > View this message in context: http://forum.world.st/self-halt-safety-net-tp4643012p4643070.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

3 2