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

Re: [Pharo-project] Backward Compatibility

by Guillermo Polito

On Wed, Nov 23, 2011 at 5:21 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > well, normally, there should be a simple keyboard shortbut to accept a > dialog (not just text in it). > so you don't need to touch mouse every time, everywhere to proceed. > cmd-s/ctrl-s seems like a logical choice for dialogs with text entry > in this case. > for other cases - enter key would suffice. and esc for canceling it. > > I think alt+enter is more common to non smalltalkers for example (I associate cmd+s or ctrl+s to save, not to accept), and we should reduce the entry barrier ;) Guille

Nov. 23, 2011

Re: [Pharo-project] Backward Compatibility

by Igor Stasenko

On 23 November 2011 21:11, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 23.11.2011 21:08, Henrik Sperre Johansen wrote: >> >> On 23.11.2011 20:20, Sean P. DeNigris wrote: >>> >>> 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. >>> >> I don't get it, I don't see how ctrl-s does anyhing in the original >> case... >> You click OK without accepting the contents first, and it still returns >> the modified text. >> Why not just remove the yellow "this editor has unaccepted contents" >> marker for this type of dialog? >> >> Altering ctrl-s to do an accept of the input isn't really what I'd expect >> from an input dialog... >> >> Cheers, >> Henry >> > And igor thinks it should, so I guess opinions differ :) well, normally, there should be a simple keyboard shortbut to accept a dialog (not just text in it). so you don't need to touch mouse every time, everywhere to proceed. cmd-s/ctrl-s seems like a logical choice for dialogs with text entry in this case. for other cases - enter key would suffice. and esc for canceling it. > My point was I'd expect ok/cancel dialogs to act consistently, and afaik, > the rest do not accept on a cmd-s, do they? > > Either way, I don't think it's a big enough difference to bother with a > setting. > right. i would live with or without this feature (and i hope others too), which means that it doesn't deserves any setting. > Then again, it's a bikeshed, so I'll shut up from now on. > > Cheers, > Henry > > -- Best regards, Igor Stasenko.

Nov. 23, 2011

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

by StÃ©phane Ducasse

Igor since we will want to have that on the build server ;) can you tell a bit what you did that I try on my machine. about portâ¦.. people make me laugh when they say that GTK is available one day it took 8 h to get it installed on my machine and it did not work at all :( Stef On Nov 23, 2011, at 7:05 PM, Igor Stasenko wrote: > 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] [Zinc] ZnTooManyRedirects exception

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=5014 :) On Nov 23, 2011, at 5:37 PM, Sven Van Caekenberghe wrote: > Jan, > > On 23 Nov 2011, at 14:12, Sven Van Caekenberghe wrote: > >> Let me think a bit about this, and I will come back to you. > > I added some new features so that now this should work: > > testRedirectDontFollow > | client | > (client := ZnClient new) > dontFollowRedirects; > get: 'http://www.pharo-project.org'. > self assert: client response isRedirect. > client > enforceHttpSuccess: true; > get: 'http://www.pharo-project.org'. > self assert: client response isRedirect. > client close > > I think this will cover your use case, please let me know how it goes. > > I discovered that I more ore less already had something that came close: > > testRedirect > | client response | > client := ZnClient new url: 'http://www.pharo-project.org'. > self assert: (client get; isSuccess). > client > close; > maxNumberOfRedirects: 0; > url: 'http://www.pharo-project.org'. > self should: [ client get ] raise: ZnTooManyRedirects. > client close. > response := [ ZnClient new beOneShot; maxNumberOfRedirects: 0; get: 'http://www.pharo-project.org'; response ] > on: ZnTooManyRedirects do: [ :exception | exception resume ]. > self assert: response isRedirect > > Resuming the exception gave a true redirect response. > > But that code is not very nice/handy, and it would not work when combined with enforceHttpSuccess: true. > > These are new commits: > > ==================== Summary ==================== > > Name: Zinc-HTTP-SvenVanCaekenberghe.221 > Author: SvenVanCaekenberghe > Time: 23 November 2011, 5:30:09 pm > UUID: 4df9982e-63e1-49ea-bfb0-2f9cb43f6f0b > Ancestors: Zinc-HTTP-SvenVanCaekenberghe.220 > > added new #followsRedirects boolean option to ZnClient > because setting #maxNumberOfRedirects to 0 did not work well > for an example see the ZnClientTests>>#testRedirectDontFollow > Thx Jan van de Sandt for reporting this > > ==================== Summary ==================== > > Name: Zinc-Tests-SvenVanCaekenberghe.115 > Author: SvenVanCaekenberghe > Time: 23 November 2011, 5:31:22 pm > UUID: eb8c67e4-bdf2-4741-b149-78bdaf5d4970 > Ancestors: Zinc-Tests-SvenVanCaekenberghe.114 > > added ZnClientTests>>#testRedirectDontFollow to test > the new #followsRedirects boolean option to ZnClient, > including under the case of #enforceHttpSuccess: true > > Regards, > > Sven

Nov. 23, 2011

Re: [Pharo-project] Backward Compatibility

by Henrik Sperre Johansen

On 23.11.2011 21:08, Henrik Sperre Johansen wrote: > On 23.11.2011 20:20, Sean P. DeNigris wrote: >> 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. >> > I don't get it, I don't see how ctrl-s does anyhing in the original > case... > You click OK without accepting the contents first, and it still > returns the modified text. > Why not just remove the yellow "this editor has unaccepted contents" > marker for this type of dialog? > > Altering ctrl-s to do an accept of the input isn't really what I'd > expect from an input dialog... > > Cheers, > Henry > And igor thinks it should, so I guess opinions differ :) My point was I'd expect ok/cancel dialogs to act consistently, and afaik, the rest do not accept on a cmd-s, do they? Either way, I don't think it's a big enough difference to bother with a setting. Then again, it's a bikeshed, so I'll shut up from now on. Cheers, Henry

Nov. 23, 2011

Re: [Pharo-project] Backward Compatibility

by Igor Stasenko

On 23 November 2011 20:20, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > 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... > i think this is overestimated . i think pressing cmd-s on dialog with single text entry should work as if you pressed ok (and accepted the modified text, of course). because for 'not accepting' there is a cancel button, normally. As for keeping things compatible or not, my own vision is following: - if you can improve thing while keeping it compatible, no problem - if you cannot, but making changes will require a lot of effort, maybe it is better to keep things as is, and do just cosmetic changes, until - at some point you can find time/people who can make an overhaul and rewrite the stuff, without caring about compatibility, but caring about making things working :) > 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. > > -- Best regards, Igor Stasenko.

Nov. 23, 2011

Re: [Pharo-project] Backward Compatibility

by Henrik Sperre Johansen

On 23.11.2011 20:20, Sean P. DeNigris wrote: > 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. > I don't get it, I don't see how ctrl-s does anyhing in the original case... You click OK without accepting the contents first, and it still returns the modified text. Why not just remove the yellow "this editor has unaccepted contents" marker for this type of dialog? Altering ctrl-s to do an accept of the input isn't really what I'd expect from an input dialog... Cheers, Henry

Nov. 23, 2011

Re: [Pharo-project] World intermittently becoming a mess

by Alexandre Bergel

Yes, I experienced this a couple of times. I think it has to do with the UI Thread. This happened when I was debugging a Roassal visualization Alexandre On 23 Nov 2011, at 16:38, Sean P. DeNigris wrote: > 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. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 23, 2011

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

by Marcus Denker

Just 6. Three of them have suggested solutions that just need to be checked: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.3 -- Marcus Denker -- http://marcusdenker.de

Nov. 23, 2011

[Pharo-project] Call for feedback: assessing the test coverage with Hapao

by Alexandre Bergel

Dear All, As you may know, Vanessa and I have been working on a visual tool to help people increase the test coverage. The website contains screenshots, documents and screencast: http://hapao.dcc.uchile.cl/ Hapao is easy to install: -=-=-=--=-=-=--=-=-=--=-=-=- Gofer new squeaksource: 'Spy'; package: 'ConfigurationOfSpy'; load. (Smalltalk at: #ConfigurationOfSpy) project lastVersion load -=-=-=--=-=-=--=-=-=--=-=-=- And then get it from the world menu. We crucially need feedback. This is necessary to target serious conferences. It does not take long to try. If you are developing right now, then you can let Hapao help you focus where you write new unit tests. You can leave your feedback on: https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dDRKMzh4VzZBZ… We need feedback before the end of the month. Thanks to all! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 23, 2011