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

[Pharo-project] object format of true, false, nil and others...

by StÃ©phane Ducasse

Hi imagine that I want to bootstrap our nice kernel. I will need to somehow create a new nil, true, false, instances of new classes Undefined, True, False. Such instances will then be put on the SpecialObjectArray somehow. Now I can create a dummy object playing such roles and then use SystemTracer to substitute my placeholder with the true nil falseâ¦. or another trick to swap them. Now anybody has other ideas? Stef

Nov. 23, 2011

[Pharo-project] experience with large images?

by Alexandre Bergel

Hi! Apparently, without configuring anything, the Pharo image cannot go over 500 Mb. Can this limit be moved up, to, let's say, 4Gb? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 23, 2011

Re: [Pharo-project] Monticello Browser Model

by Sean P. DeNigris

StÃ©phane Ducasse wrote > >> So my question is: is it worth it to open an issue/work on this? > Yes > Issue 5016: MCWorkingCopyBrowser Cleanup http://code.google.com/p/pharo/issues/detail?id=5016 -- View this message in context: http://forum.world.st/Monticello-Browser-Model-tp4101637p4101691.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 23, 2011

Re: [Pharo-project] [Zinc] ZnTooManyRedirects exception

by Jan van de Sandt

Hello Sven, Yes, this is exactly what I need. Thanks very much for the quick fix! I know that resuming the exception also works. That was the solution that I used until now. But the new solution is much nicer. Jan. On Wed, Nov 23, 2011 at 5:37 PM, Sven Van Caekenberghe <sven(a)beta9.be>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] Building 32-bit Cairo library on Macs

by Schwab,Wilhelm K

I'm going to have to run down that dynamic library quote - I vaguely recall seeing it, but obviously need a refresher course. I *think* I know what he means by it. Though I will admit that when the boundaries are correct, libraries have their uses. All too often though, one ends up with (as here) myriad dependencies that don't seem to have any direct applicability and certainly make life complicated. However, AccesIO (http://www.accesio.com) makes a nice A/D board and they have a library that has been very helpful. The board is perhaps the only USB device, other than external drives, that hasn't been a major pain at some point. Get the firmware and rules installed correctly, and it just works. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Wednesday, November 23, 2011 4:02 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs 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] 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