- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Monticello Browser Model

by Sean P. DeNigris

Sean P. DeNigris wrote > > So I ended up with the really ugly: > > browser := MCWorkingCopyBrowser new. > wrapper := MCDependentsWrapper with: wc model: browser. > browser workingCopySelectionWrapper: wrapper. > which works if each statement is executed individually, but not all at once. Ha ha ha! Sean -- View this message in context: http://forum.world.st/Monticello-Browser-Model-tp4101637p4101657.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 23, 2011

Re: [Pharo-project] Monticello Browser Model

by StÃ©phane Ducasse

On Nov 23, 2011, at 10:14 PM, Sean P. DeNigris wrote: > MCWorkingCopyBrowser has #workingCopy:, which I thought would allow me to > programmatically select a working copy. Unfortunately, it doesn't update the > UI. > > Poking around, I found that there are two mechanisms to update the working > copy list selection - #workingCopySelection: and > #workingCopySelectionWrapper: - and they are not connected. So I ended up > with the really ugly: > > browser := MCWorkingCopyBrowser new. > wrapper := MCDependentsWrapper with: wc model: browser. > browser workingCopySelectionWrapper: wrapper. wonderful isn't > So my question is: is it worth it to open an issue/work on this? Yes > Will Ring/RPackage/other-new-thing replace this tool anytime soon? Not at this level for now we will work on the layer below. Because MC uses FilePackage and other abstractions to collect and represent information. Stef > > Sean > > -- > View this message in context: http://forum.world.st/Monticello-Browser-Model-tp4101637p4101637.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 23, 2011

[Pharo-project] Monticello Browser Model

by Sean P. DeNigris

MCWorkingCopyBrowser has #workingCopy:, which I thought would allow me to programmatically select a working copy. Unfortunately, it doesn't update the UI. Poking around, I found that there are two mechanisms to update the working copy list selection - #workingCopySelection: and #workingCopySelectionWrapper: - and they are not connected. So I ended up with the really ugly: browser := MCWorkingCopyBrowser new. wrapper := MCDependentsWrapper with: wc model: browser. browser workingCopySelectionWrapper: wrapper. So my question is: is it worth it to open an issue/work on this? Will Ring/RPackage/other-new-thing replace this tool anytime soon? Sean -- View this message in context: http://forum.world.st/Monticello-Browser-Model-tp4101637p4101637.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 23, 2011

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

by StÃ©phane Ducasse

On Nov 23, 2011, at 9:45 PM, Igor Stasenko wrote: > On 23 November 2011 21:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> 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. >> > > since i installed ports before, and since my system is 64 bit, most of > packages are built using 64bit arch. > now, since i insisted to also have 32bit libs (obviously to be able to > use cairo with VM), i had to reinstall all dependents of cairo (a lot) > with +universal flag. > > so, the basic rule, is whenever you install anything using ports, add > +universal option, to make sure that it will produce 'fat' binaries > containing both 32bit and 64bit versions. > (of course it doubles the compilation time ;) > > >> 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 :( >> > > hehe.. to build cairo, for some strange reason it had to rebuild xml, > python, perl, x11 lib and dozen of other stuff. > > rephrasing famous Alan's Kay note: by saying "modularity" i didn't had > C dynamic libraries in mind :) > > now given that cairo library having so much/deep strange dependencies, > i am not sure whether we should > a) build it on build server > b) bundle it with VM > > a), because port seems to be working, and it is external to our > project and maintained by people we do not know. > b, because otherwise it may require to bundle VM with 32-bit versions > of a lot of libs, which normally can be found in any unix system, and > should be installed by user(s) , not us. Indeed we should not :) Now when we will ship pharo it would be good to have a lib included. > >> Stef > > > -- > Best regards, > Igor Stasenko. >

Nov. 23, 2011

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

by Igor Stasenko

On 23 November 2011 21:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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. > since i installed ports before, and since my system is 64 bit, most of packages are built using 64bit arch. now, since i insisted to also have 32bit libs (obviously to be able to use cairo with VM), i had to reinstall all dependents of cairo (a lot) with +universal flag. so, the basic rule, is whenever you install anything using ports, add +universal option, to make sure that it will produce 'fat' binaries containing both 32bit and 64bit versions. (of course it doubles the compilation time ;) > 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 :( > hehe.. to build cairo, for some strange reason it had to rebuild xml, python, perl, x11 lib and dozen of other stuff. rephrasing famous Alan's Kay note: by saying "modularity" i didn't had C dynamic libraries in mind :) now given that cairo library having so much/deep strange dependencies, i am not sure whether we should a) build it on build server b) bundle it with VM a), because port seems to be working, and it is external to our project and maintained by people we do not know. b, because otherwise it may require to bundle VM with 32-bit versions of a lot of libs, which normally can be found in any unix system, and should be installed by user(s) , not us. > Stef -- Best regards, Igor Stasenko.

Nov. 23, 2011

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