April 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] ToolBuilder / Pharo 1.0 changes

by Andreas Raab

Hi - Here are the changes between the latest ToolBuilder from http://www.squeaksource.com/ToolBuilder vs. Pharo 1.0 (again there are additional but fairly minor edits involved): Package ToolBuilder-Kernel -------------------------- - ToolBuilderTests Removed. - UIManager * fontFromUser: -- * chooseFrom:lines:message: * chooseFrom:lines:message:title: * chooseFrom:message: * chooseFrom:message:title: * chooseFrom:values:lines:message: * chooseFrom:values:lines:message:title: * chooseFrom:values:message: * chooseFrom:values:message:title: -- * createPageTestWorkspace * checkForNewDisplaySize * composeFormFor: * grafPort * interactiveParserFor: * newDisplayDepthNoRestore: * onDebug:context:title:full: * onPrimitiveError: * onEventSensorStartup: * onSnapshot * restoreDisplay * restoreDisplayAfter: Two sets of issues that we should discuss: If you care about unloading the (very small) set of tests we should move those into a separate package, which is easy enough. Secondly, UIManager. It seems there have been three types of additions: 1) 'Genuine' user requests like fontFromUser:. Since we added a similar protocol in Squeak we should work out which protocol is preferable and use it (or even both). 2) Polymorph extensions. Assuming Gary agrees, we should move those into UIManager but I'll point out that a quick look at senders didn't reveal any users? All the references were between these methods no apparent external callers. Are these used in other packages? 3) Methods that are not about user requests (everything from creatPageTestWorkspace through restoreDisplayAfter:). I don't really like those very much (after all UIManager is all about asking users for information); is there really no better place in Pharo to put these? I can kind of see why one would stick some of those into UIManager if there is absolutely no other place but ... is there? Package ToolBuilder-Morphic --------------------------- - MorphicToolBuilderTests Removed. - MorphicUIManager * isActiveManager - presumes Morphic-only * (all the code for the new methods in UIManager) Not much new stuff here. Package Polymorph-ToolBuilder-Morphic ------------------------------------- * PSPluggableListSpec Adds icon and double click selector to the list spec. This should be folded all the way up into PluggableListSpec. The lack of these is a real oversight. That's about it for the Pharo changes. Except from the methods in UIManager that don't really belong there, there's little to worry about. The next thing I'll do is post some recommendations of how I think we can move this forward. I'll have to think about this a little though. Cheers, - Andreas

April 23, 2010

[Pharo-project] ToolBuilder / Squeak 4.1 changes

by Andreas Raab

Hi - As a first step for merging, here are the changes that are in Squeak 4.1 relative to the latest versions in the repository at http://www.squeaksource.com/ToolBuilder. The following is a pretty much complete set of changes that happened since (there are a few more minor edits but they're pretty much irrelevant for our purposes here): Package: ToolBuilder-Kernel --------------------------- - PluggableAlternateMultiSelectionListSpec This class was added as an 'alternative' multi-selection list (used only by MessageTrace; perhaps Chris can comment) - PluggableCodePaneSpec This class was added to distinguish code-editing panes from others. It implies syntax highlighting any other goodies you'd like to see in code. - PluggableListSpec * doubleClick - selector to handle double click events * keystrokePreview - selector to handle key events for filtering - PluggableTextSpec * askBeforeDiscardingEdits - whether to ask before discarding changes - PluggableWindowSpec * isDialog - if the window should behave like a dialog - UIManager: * chooseFont:for:setSelector:getSelector: - font selector dialog * confirm:label: - confirm dialog w/ both message text and label * request:initialAnswer:centerAt: - positioned #request: message All of these changes are pretty straightforward and should not cause much of an issue. Package: ToolBuilder-Morphic ---------------------------- - ListChooser This class was added to implement the chooser dialog in Morphic. - PluggableDialogWindow This class was added for dialog windows in Cobalt. - PluggableTextMorphPlus: * styler - PTMPlus has been extended to support Shout directly. - MorphicUIManager: * chooseFont: - usage of FontChooser * chooseFrom: - usage of ListChooser * confirm: - usage of UserDialogBoxMorph * informUserDuring: - usage of SystemProgressMorph There is obviously more of an issue here. Various classes have only emerged in Squeak 4.1 and won't exist in Pharo. Not sure what to do here, because it's as much of an issue between 3.x and 4.1. I'll review the Pharo changes next. Cheers, - Andreas

April 23, 2010

Re: [Pharo-project] Behavior of Rectangle

by csrabak＠bol.com.br

April 23, 2010

Re: [Pharo-project] Behavior of Rectangle

by csrabak＠bol.com.br

Yes! There it is! Thanks, -- Cesar Rabak Em 22/04/2010 17:18, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no > escreveu: On 22.04.2010 22:14, csrabak(a)bol.com.br wrote: > Alexandre, > > I can't tell why exactly, but this kind of discussion seems /dÃ©jÃ vu/ for me. . . I agree I cannot find the specific thread about it. That's because it was on the vwnc-mailing list: http://forum.world.st/vwnc-Rectangle-td1414824.html Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 22, 2010

Re: [Pharo-project] [Esug-list] Re: Talking to Steve Jobs about Scratch.

by csrabak＠bol.com.br

Em 22/04/2010 17:00, John M McIntosh <johnmci(a)smalltalkconsulting.com> escreveu: > On 2010-04-22, at 11:43 AM, StÃ©phane Ducasse wrote: > > > if we start to make the intersection between smalltalk and > > university and education then we will end up to nothing. zero ok > > one or two, now individually we can take the responsibility to say > > what we think about apple attitude and I will do it for myself. > > > > Stef > It's not just intersection of Smalltalk, let me ramble, APL, Cobol, > Fortran, Lisp, Basic, Lua , Ruby, Perl, Simula, Algol68, PL/I no > doubt there are a few more, that is what is at risk. > Or do educational institutes only dabble and teach in C++ still? John, I respect your point but I feel this is stretching into a Crusade! Scratch itself is the point still or is it to be an example of the 'liberty' we would like to have in a Commercial defined and owned by a company platform? If the former, I think the issue could eventually boils down to Apple sponsoring MIT or other institution (ESUG probably would not be interested) in doing the necessary port of Scratch [viewer for iPad] to ObjC or Javascript. I mean, in a nutshell it is the question of the availability of the Scratch application versus a certain investment done to have it in iPad. If the latter, I think we need to find first why we're so certain we (the melting pot community you mention above: from COBOL to Lua) have any "rights" to have our favorite language available or approved by Apple to run in _its_ platform? Notwithstanding the historical tie to an idea of the Dynabook et al., the iPad is an iPad! Are we so sure that iPad would be this so astonishing success in such a way that if Scratch does not come by via an iPad the majority of the teens which are the intended audience of Scratch would become orphaned of using Scratch? Let's ask ourselves, due to principles would we (instead of putting black skulls on our pages) steer away of Apple and stop doing development work for all Apple devices (the only way to have a visible effect), as was for a time a ban from FSF due the Apple's litigation on the 'look and feel' of their apps? I don't think it is reasonable nor expected. . . my 0.19999.... -- Cesar Rabak

April 22, 2010

Re: [Pharo-project] Behavior of Rectangle

by Henrik Sperre Johansen

On 22.04.2010 22:14, csrabak(a)bol.com.br wrote: > Alexandre, > > I can't tell why exactly, but this kind of discussion seems /dÃ©jÃ vu/ for me. . . I agree I cannot find the specific thread about it. That's because it was on the vwnc-mailing list: http://forum.world.st/vwnc-Rectangle-td1414824.html Cheers, Henry

April 22, 2010

Re: [Pharo-project] Behavior of Rectangle

by csrabak＠bol.com.br

Alexandre, I can't tell why exactly, but this kind of discussion seems /dÃ©jÃ vu/ for me. . . I agree I cannot find the specific thread about it. OTOH, it brings an opportunity to solve the issue 'fixing' it where it belongs: containsPoint: aPoint "Answer whether aPoint is within the receiver." ^origin <= aPoint and: [aPoint < corner] The method in question is implemented using an overloading of the #<= on Point. I don't think points could be considered comparable. . . Anyway the operator is 'overloaded' and the method comment is clearly showing the intent of the implementation: <= aPoint "Answer whether the receiver is neither below nor to the right of aPoint." ^x <= aPoint x and: [y <= aPoint y] About the impacts you see, I didn't have time to do a thorough research. Why doing (No attempt to optimize, just to put the perspective): containsPoint: aPoint "Answer whether aPoint is within the receiver." ^(origin <= aPoint and: [aPoint < corner]) or: [corner <= aPoint and: [aPoint < origin]] Has impacts in present Pharo code? -- Cesar Rabak Em 22/04/2010 16:55, Alexandre Bergel < alexandre(a)bergel.eu > escreveu: Dear List, I spend quite some time in tracking down a bug in Mondrian. I found it. The source of it stems from the following behavior in Pharo: -=-=-=-=-=-= (0@0 corner: 10@10) containsPoint: 5@5. => true (10@10 corner: 0@0) containsPoint: 5@5. => false -=-=-=-=-=-= I find the latter a bit surprising. VW returns false as well. I would expect the second expression to return true. There is also "(10@0 corner: 0@10) containsPoint: 5@5. => false" I looked in the Pharo mailing list archive, and apparently this hasn't been discussed yet. The class Rectangle is central. Modifying it (either by making "(10@10 corner: 0@0) containsPoint: 5@5" returns true or not permitting a rectangle "(10@10 corner: 0@0)" to be valid) may have some serious impact. What do you think? 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

April 22, 2010

Re: [Pharo-project] [Esug-list] Re: Talking to Steve Jobs about Scratch.

by John M McIntosh

On 2010-04-22, at 11:43 AM, StÃ©phane Ducasse wrote: > if we start to make the intersection between smalltalk and university and education > then we will end up to nothing. zero ok one or two, now individually > we can take the responsibility to say what we think about apple attitude and I will do it for myself. > > > Stef It's not just intersection of Smalltalk, let me ramble, APL, Cobol, Fortran, Lisp, Basic, Lua , Ruby, Perl, Simula, Algol68, PL/I no doubt there are a few more, that is what is at risk. Or do educational institutes only dabble and teach in C++ still? -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

April 22, 2010

[Pharo-project] Behavior of Rectangle

by Alexandre Bergel

Dear List, I spend quite some time in tracking down a bug in Mondrian. I found it. The source of it stems from the following behavior in Pharo: -=-=-=-=-=-= (0@0 corner: 10@10) containsPoint: 5@5. => true (10@10 corner: 0@0) containsPoint: 5@5. => false -=-=-=-=-=-= I find the latter a bit surprising. VW returns false as well. I would expect the second expression to return true. There is also "(10@0 corner: 0@10) containsPoint: 5@5. => false" I looked in the Pharo mailing list archive, and apparently this hasn't been discussed yet. The class Rectangle is central. Modifying it (either by making "(10@10 corner: 0@0) containsPoint: 5@5" returns true or not permitting a rectangle "(10@10 corner: 0@0)" to be valid) may have some serious impact. What do you think? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 22, 2010

Re: [Pharo-project] FEATURE: User chooses preferred location for MC directory repositories

by csrabak＠bol.com.br

Provided you install some specific package, right? Em 21/04/2010 11:14, Chris Muller < asqueaker(a)gmail.com > escreveu: Environment variables can be interrogated, at least in Linux (perhaps other OS's, I haven't tried), via OSProcess: OSProcess thisOSProcess environment Hope that helps.. On Tue, Apr 20, 2010 at 4:21 PM, Michael Roberts wrote: > i'm not sure what either of you mean. I want there to be no UI choice > and the system just looks higher up in the file system hierarchy. > > certainly environment variables or a .pharorc style file would solve this. > > thanks, > Mike > > On Tue, Apr 20, 2010 at 6:33 PM, Chris Muller wrote: >> Whether the user is required to specify a "default directory" or a >> directory to a repository, it's the same task isn't it? >> >> Once you add it once to MC, it can be "added" to any other package. >> So this defaultDirectory would seem to be a feature not worth its >> weight.. >> >> >> On Mon, Apr 19, 2010 at 6:00 PM, Sean P. DeNigris wrote: >>> >>> http://code.google.com/p/pharo/issues/detail?id=2329 >>> >>> Pharo image: Pharo 1.0 >>> >>> In Monticello Browser, when I click "+Repository" and select "directory," >>> I'd love to be taken right to the directory where I keep my local >>> repositories, instead of having to click to the same place over and over. >>> >>> I changed the following method: >>> MCDirectoryRepository class>>morphicConfigure >>> Â Â Â Â ^ (UIManager default chooseDirectoryFrom: (FileDirectory on: >>> '/path/to/my/Repositories')) ifNotNil: >>> Â Â Â Â Â Â Â Â [:directory | >>> Â Â Â Â Â Â Â Â self new directory: directory] >>> >>> How should I store the default repository directory? Â Would anyone else find >>> this helpful? >>> >>> Sean DeNigris >>> -- >>> View this message in context: http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directo… >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 22, 2010