November 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] [TODO 1.4] Open Issues in 1.4

by Marcus Denker

http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.4 -- Marcus Denker -- http://marcusdenker.de

Nov. 23, 2011

[Pharo-project] World intermittently becoming a mess

by Sean P. DeNigris

Every once in a while, in my 1.3-rc image, the World becomes a mess. Specifically: * moving windows without the fast dragging setting enabled leaves a trail * previews from hovering over the task bar remain in the World and don't delete themselves when the mouse is no longer over the task bar I haven't been able to reproduce it, but it's happened a few times. Has anyone else experienced this? I opened an issue: http://code.google.com/p/pharo/issues/detail?id=5013 -- View this message in context: http://forum.world.st/World-intermittently-becoming-a-mess-tp4101204p410120… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 23, 2011

Re: [Pharo-project] Backward Compatibility

by Schwab,Wilhelm K

This sounds like a nice opportunity to climb on the native widget soap box for a moment. I am not at all convinced that native widgets would make us faster (though they might help with specific things, e.g. rendering large blocks of text), but they would force discipline on us. Imagine the cruft that would disappear if the windowing system were *completely* replaced. That is, of course, more easily said than done, and a lot of code depends on the cruft. You did say you wanted to start a discussion :) Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean(a)clipperadams.com] Sent: Wednesday, November 23, 2011 2:20 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Backward Compatibility The Pharo Manifesto (http://code.google.com/p/pharo/) lists "Not backward compatible" as one of its 4 tenants. Yet, while working through the issue tracker, I've noticed some adding/keeping complexity to keep things backward compatible - most recently http://code.google.com/p/pharo/issues/detail?id=5007. I just wanted to start a discussion because obviously the more mature Pharo gets, the harder it will be to remove things... Sean -- View this message in context: http://forum.world.st/Backward-Compatibility-tp4101111p4101111.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 23, 2011

Re: [Pharo-project] GUI Testing Library

by Alexandre Bergel

I will invite you for a couple of beers at the next esug :-) I cannot try it right now (bad internet connection), but I checked the source code. It looks good. Cheers, Alexandre On 23 Nov 2011, at 13:12, Sean P. DeNigris wrote: > > Alexandre Bergel-7 wrote >> >> I opened an issue: http://code.google.com/p/pharo/issues/detail?id=5010 >> > > Fix (although I guess there are more widgets to fix?) in 1.4 inbox > SLICE-Issue-5010-Testing-GUI-widgets-SeanDeNigris.1 > > > Alexandre Bergel-7 wrote >> >> This is very valuable. Currently it is really hard to test GUI in Pharo. >> > I think it could be very easy with a little work > > > Alexandre Bergel-7 wrote >> >> One problem I faced several times is that GUI are not uniformly managed: >> some GUI widgets use of exceptions (which is cool), some other are >> blocking the currently thread (which is not cool). >> > The hook points are in MorphicUIManager's "ui requests" protocol. For each > type of interaction (e.g. confirm), in the method that takes the most > arguments (e.g. #confirm:label:, not #confirm:), ProvideAnswerNotification > is signaled. > > > Alexandre Bergel-7 wrote >> >> For example, I can write... >> > Thanks for the examples. I wrote them into Morphic tests (incl. in fix > above) > > > Alexandre Bergel-7 wrote >> >> self should: ['/tmp' = ([UIManager default chooseDirectory] >> valueSupplyingAnswer: #('/tmp'))] >> > This works now, but the syntax is ...valueSupplyingAnswer: { 'Choose > Directory'. FileDirectory on: '/tmp' }. > > HTH, > Sean > > -- > View this message in context: http://forum.world.st/GUI-Testing-Library-tp4097866p4100236.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 23, 2011

[Pharo-project] Backward Compatibility

by Sean P. DeNigris

The Pharo Manifesto (http://code.google.com/p/pharo/) lists "Not backward compatible" as one of its 4 tenants. Yet, while working through the issue tracker, I've noticed some adding/keeping complexity to keep things backward compatible - most recently http://code.google.com/p/pharo/issues/detail?id=5007. I just wanted to start a discussion because obviously the more mature Pharo gets, the harder it will be to remove things... Sean -- View this message in context: http://forum.world.st/Backward-Compatibility-tp4101111p4101111.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 23, 2011

[Pharo-project] OB Command to Send unary class-side methods

by Sean P. DeNigris

I was adding a traditional "self myUnaryClassSideSelector" comment that was missing in Polymorph, and decided that would be the last time, so I added a command to OB: Gofer it squeaksource: 'SPDPlayground'; package: 'OBExtensions'; load. To use it: 1. Open OB (it seems only windows open after the file-in will have the new functionality) 2. Browse a class with an interesting unary class-side method (e.g. RecentMessageList, which has #openInWorld) 3. Select the method in the method pane 4. Bring up the menu and choose "Send Message" (or hit Cmd-s). Enjoy! Sean p.s. Lukas, this seems generally applicable. Will you add it to OB? -- View this message in context: http://forum.world.st/OB-Command-to-Send-unary-class-side-methods-tp4101082… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 23, 2011

[Pharo-project] [update 1.4] #14234

by Marcus Denker

14234 ----- Issue 5009: Workspace method protocol clean-up http://code.google.com/p/pharo/issues/detail?id=5009 Issue 5007: On TextEditorDialogWindow http://code.google.com/p/pharo/issues/detail?id=5007 Issue 4974: better UUID comparison http://code.google.com/p/pharo/issues/detail?id=4974 Issue 5008: FixDebuggerWhenSelectorIs>> http://code.google.com/p/pharo/issues/detail?id=5008 -- Marcus Denker -- http://marcusdenker.de

Nov. 23, 2011

Re: [Pharo-project] Building 32-bit Cairo library on Macs

by Schwab,Wilhelm K

Sig, "voodoo dances" is a good characterization. As we were discussing not long ago, it's easy, but definitely NOT simple. Congratulations on getting it working. Thanks for your efforts! Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] Sent: Wednesday, November 23, 2011 1:05 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs nevermind, after multiple painfull upgrade/clean/--enforce-variants and other voodoo dances, i got it installed. Now the question if it will work as expected and can be loaded by 32-bit VM , which is Cog :) On 23 November 2011 18:58, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > I don't think it's Linux so much as the kinds of things that Alan Kay has observed as being horribly wrong in computer science/engineering education. Produce programmers with zero (if not confused/negative) skills in engineering ("no taste" as Steve Jobs said of MS) and you get really bad software. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] > Sent: Wednesday, November 23, 2011 12:31 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs > > [snip] > > P.S. this port collection is crazy.. it still builds dependencies, > including python (OMG), and x11 libs.. > for a thing, like cairo library.. so much dependencies.. > there is something wrong with linux world. > >> Bill > > > > -- > Best regards, > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

Nov. 23, 2011

Re: [Pharo-project] Building 32-bit Cairo library on Macs

by David T. Lewis

Yay! On Wed, Nov 23, 2011 at 07:10:41PM +0100, Igor Stasenko wrote: > TADAAA: > > file /opt/local/lib/libcairo.2.dylib > /opt/local/lib/libcairo.2.dylib: Mach-O universal binary with 2 architectures > /opt/local/lib/libcairo.2.dylib (for architecture i386): Mach-O > dynamically linked shared library i386 > /opt/local/lib/libcairo.2.dylib (for architecture x86_64): Mach-O > 64-bit dynamically linked shared library x86_64 > > > -- > Best regards, > Igor Stasenko.

Nov. 23, 2011

Re: [Pharo-project] Building 32-bit Cairo library on Macs

by Igor Stasenko

TADAAA: file /opt/local/lib/libcairo.2.dylib /opt/local/lib/libcairo.2.dylib: Mach-O universal binary with 2 architectures /opt/local/lib/libcairo.2.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /opt/local/lib/libcairo.2.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 -- Best regards, Igor Stasenko.

Nov. 23, 2011