March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Seaside working on Pharo

by Damien Cassou

On Wed, Mar 4, 2009 at 4:54 PM, Bruce O'Neel <squeak(a)pckswarms.ch> wrote: > and all should be good. Â The problem is that growSize isn't set, and, newer versions > gcc seem to set it to 0, rather than some random number not 0. > > If the above code doesn't work justset growSize to something, say, 50000000 should > do the job. Â Ie, each grow would be 50meg. Thank you -- Damien Cassou http://damiencassou.seasidehosting.st

March 4, 2009

Re: [Pharo-project] What's the problem people? :)

by StÃ©phane Ducasse

> >>> Hi Pharaos (and Squeak-dev)! :) >> >> Hi goran >> >> are you planning to come finally to esug that we drink beer together? >> This year there will >> be a wine tasting social event :) >> > I hope i can join you :) normally we will have a lecture and practice to taste wine Lecture made by an expert in wine :) And this will be normally for any ESUG attendee. Stef

March 4, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by Igor Stasenko

My 2 cents: i don't care what is the name of software i running , be it Squeak or Pharo. I care only about 2 things: a) if i like something (because it works well), i want it to be in my image by a single mouse click b) if i dislike something (because its crap) , i want to be able to unload it by a single mouse click if software works different than in (a) like (can't load/unload without problems), this is automatically falls to category (b) :) -- Best regards, Igor Stasenko AKA sig.

March 4, 2009

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by StÃ©phane Ducasse

creating a unix vm. stef On Mar 4, 2009, at 5:34 PM, Igor Stasenko wrote: > 2009/3/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> may be we should slowly think that we should get some people > > err.. get people for what? > >> - Show quoted text - >> On Mar 4, 2009, at 4:25 PM, Bruce O'Neel wrote: >> >>> Hi, >>> >>> There seem to be three solutions (in best to worst order). >>> >>> - someone (Ian maybe) needs to rebuild the Unix VM with a VMMaker >>> from within the last two years. Apparently the bug has been fixed >>> for a >>> while. >>> >>> - pass a fixed memory size to the VM >>> >>> -memory 200m >>> >>> or so does the trick. >>> >>> - patch the existing C source code. >>> >>> cheers >>> >>> bruce >>> >>> On Tue, Mar 03, 2009 at 09:19:13AM +0100, Tudor Girba wrote: >>>> Hi, >>>> >>>> I am not sure I got the summary of the discussion related to the >>>> problem of deploying a Pharo-based image to seasidehosting. Is >>>> there >>>> any conclusion? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Problem solving efficiency grows with the abstractness level of >>>> problem understanding." >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2009

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas

by StÃ©phane Ducasse

Hi alain > Hi all, > Here is a Preference engine based on pragma. > please, check it and tell me if it is ok or not. > If you prefer squeak version, this will be difficult :) I reread all the emails you exchanged with gary and igor. What is a parentNode in AbtsractPreferenceValue? This is when you have a composite preference? I understood when reading the code of PrefProvider2 > no problem but tell me > that I stop working on this. > > The set of system preferences constitutes a tree of preferences. > The model for the tree is implemented by the PreferenceNode hierarchy. > (see PrefCore2). This is the only mandatory part. > The tree can be visualized with a PreferenceTree UI built on top of > PrefCore2 (see PrefTool2 and snapshot). > Examples of preference declaration are given in PrefProvider2. > in order to open the tree: > PreferenceTree open I have two naive questions: - I imagine that we will be able to reuse the Preference browser and that we do not have to rebuild one? because the pragma preference collector could be put there? Or is it better to rewrite everything? - second I was wondering why you only use <preference> and not <preference:zork:> like in andreas solution? Gary mentioned that some objects can be more complex than mere literal. I was wondering if for the interface it would not be better to have cascaded selector instead of methods with multiple argument. PreferenceNode name: 'HTTP proxy' description: 'http proxy name and port' parent: #networkPreferenceNode vs PreferenceNode new name: 'HTTP proxy' ; description: 'http proxy name and port' ; parent: #networkPreferenceNode So can I summarize your approach as follow? - packages can defined locally their preferences (by construction this will be better since people will have to think about preferences value as their stuff. not the one of preference so this will help the flow to be local --- good. - preferences are not centralized anymore (youpi) - tools can register to get notified when preferences changes - preferences can be complex objects - preferences are structured in preferences tree. Sounds cool to me. I will let the other give their point of view. I'm leaving on vacation now. Stef PS: test should be "self test" PrefChangeListener new inspect. UIPreferences gradientButtonLook value: UIPreferences gradientButtonLook value not. UIPreferences gradientButtonLook value: UIPreferences gradientButtonLook value not. UIPreferences gradientButtonLook value: UIPreferences gradientButtonLook value not.

March 4, 2009

Re: [Pharo-project] Fwd: On the OTDebugger...

by Dale Henrichs

----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | So we should proceed that way: | - Put a big warning + the expression to switch debugger in the pharo- | | dev | - then we follow what dale is saying | - I will produce a list of important features we need to have | -- copy stack | -- chase pointer | ... in OT For 'copy stack', check out 'error report' in OB-Tools-dkh.65. Part of the error report is a stack dump ... I could change the name and/or produce only a stack. Dale

March 4, 2009

Re: [Pharo-project] Mac Carbon VM 4.0.0b1 Closure Compiler Aware with Alien support

by Adrian Lienhard

Do the major VMs (Unix, Mac, Win) support this *now*? What is the required work to include the closure changes (are they published somewhere?)? I'd like to avoid that we get a dependency on VMs that would delay version 1.0. If everything is ready, though, I would also vote for including them now. Cheers, Adrian On Mar 4, 2009, at 17:25 , StÃ©phane Ducasse wrote: > Hi pharoers > > what do we do with the closure compiler? > Do we integrate it now or in 1.1 > > Stef > > On Mar 3, 2009, at 6:48 AM, John M McIntosh wrote: > >> Yes it compiles, yes after a bit of poking I could take a Squeak3.9- >> final-7067.image and build a closure aware image. >> No I could not do that without poking a bit, however I hope that >> we'll >> resolve the problems in a day or two. >> >> Yes, I could take a Pharo0.1Core-10243.image and after more poking >> could generate a closure aware Pharo image. >> >> At this time the 4.0.0b1 VM is not publicly available, another day or >> two of cross checking is required, I've asked the Pharo >> team to review my changes and the changes from Eliot. I've also asked >> Eliot to supply some fixes so we can recompile >> the Squeak3.9-final-7067 image without problems. >> >> I cannot speak for the 3.10 or 3.11 images, other parties will need >> to >> pursue any work to make them closure aware. >> >> Tomorrow I'll poke at making the iPhone VM closure aware, however any >> iPhone image relies on the Pharo team resolving >> what the change sets should be to make the image closure aware. >> >> -- >> = >> = >> = >> = >> = >> = >> ===================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> >> Corporate Smalltalk Consulting Ltd. http:// >> www.smalltalkconsulting.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

March 4, 2009

Re: [Pharo-project] A point a.k.a excuse to you

by CÃ©drick BÃ©ler

2009/3/4 Keith Hodges <keith_hodges(a)yahoo.co.uk>: > Schwab,Wilhelm K wrote: >> Keith, >> >> I have never met Stef; I know him only through correspondence, direct and otherwise. Â Come to think of it, I probably know him pretty well. Â I *never* got any sense that he was the problem with Squeak. Â I don't buy it; I saw him trying to fix the problems I have described, and failing that, he started Pharo. >> >> Bill >> > I didnt say that he "was" the problem. I said he was the custodian of > the process (one development team bottleneck) that you called a black hole. I saw them more as prisoners, not custodians... you can object in Pharo, it's the same as squeak but... not the same size, same interests and again... a quick decision process, quick integration... Let's see what BPP will do but meanwhile, I'm happy with the reactivity... last one for me on this thread... time to go ;) bye > > Keith > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- CÃ©drick

March 4, 2009

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas

by Alain Plantec

Argh, I forgot to say that, for one preference, only one method must be written. example for gradientButtonLook: UIPreferences>>gradientButtonLook <preference> ^ GradientButtonLook ifNil: [GradientButtonLook := PreferenceValue name: 'Gradient look for buttons' description: 'Gradient look for buttons' parent: #uiPreferenceNode type: #Boolean default: false] You can note the use of a minimal pragma form. We finally prefered objects over flat pragma declaration. This allow the use of a composite pattern for the tree and for one-to-many preference declaration. As an example: UIPreferences>>themePreference <preference> ^ ThemePreference ifNil: [ThemePreference := MultiplePreferenceValue name: 'UITheme' description: 'The theme to use for UI look and feel' parent: #uiPreferenceNode type: #UITheme default: UIThemeWatery2 values: { FixedPreferenceValue name: 'Standard Squeak' description: 'Standard Squeak style' type: #UITheme value: UIThemeStandardSqueak. FixedPreferenceValue name: 'Watery 2' description: 'Similar to a nice OS' type: #UITheme value: UIThemeWatery2}] You can also have range: FreeTypePreferences>>glyphContrast <preference> ^ GlyphContrast ifNil: [GlyphContrast := RangePreferenceValue name: 'Glyph contrast' description: 'Change the contrast level for glyphs. This is an integer between 1 and 100. (the default value is 50)' parent: #freeTypePreferenceNode type: #Integer default: 50 range: (1 to: 100)] Multiple and range preference value are not so easy to describe well if we only make use of literals (pragma constraint). Other point, how to use preferences. Example of a preference reading and changing: gradientLook := UIPreferences gradientButtonLook value. UIPreferences gradientButtonLook value: true. Last but not least point is that it provides system level preference change notification. to see it in action, load PrefListener2 package (the version I have attached to this mail, previous version was not ok) Cheers alain Alain Plantec a Ã©crit : > Hi all, > Here is a Preference engine based on pragma. > please, check it and tell me if it is ok or not. > If you prefer squeak version, no problem but tell me > that I stop working on this. > > The set of system preferences constitutes a tree of preferences. > The model for the tree is implemented by the PreferenceNode hierarchy. > (see PrefCore2). This is the only mandatory part. > The tree can be visualized with a PreferenceTree UI built on top of > PrefCore2 (see PrefTool2 and snapshot). > Examples of preference declaration are given in PrefProvider2. > in order to open the tree: > PreferenceTree open. > Thank to Gary for its help. > > cheers > alain > >> >> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 4, 2009

Re: [Pharo-project] Mac Carbon VM 4.0.0b1 Closure Compiler Aware with Alien support

by Igor Stasenko

2009/3/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi pharoers > > what do we do with the closure compiler? > Do we integrate it now or in 1.1 > in 0.1 :) > Stef > - Show quoted text - > On Mar 3, 2009, at 6:48 AM, John M McIntosh wrote: > >> Yes it compiles, yes after a bit of poking I could take a Squeak3.9- >> final-7067.image and build a closure aware image. >> No I could not do that without poking a bit, however I hope that we'll >> resolve the problems in a day or two. >> >> Yes, I could take a Pharo0.1Core-10243.image and after more poking >> could generate a closure aware Pharo image. >> >> At this time the 4.0.0b1 VM is not publicly available, another day or >> two of cross checking is required, I've asked the Pharo >> team to review my changes and the changes from Eliot. I've also asked >> Eliot to supply some fixes so we can recompile >> the Â Squeak3.9-final-7067 image without problems. >> >> I cannot speak for the 3.10 or 3.11 images, other parties will need to >> pursue any work to make them closure aware. >> >> Tomorrow I'll poke at making the iPhone VM closure aware, however any >> iPhone image relies on the Pharo team resolving >> what the change sets should be to make the image closure aware. >> >> -- >> = >> = >> = >> = >> = >> ====================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> >> Corporate Smalltalk Consulting Ltd. Â http:// >> www.smalltalkconsulting.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 > -- Best regards, Igor Stasenko AKA sig.

March 4, 2009