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

[Pharo-project] [update] 10420

by Adrian Lienhard

- Issue 838: Make mouse buttons mapping platform dependent - Issue 405: Demo mode is unusable - Issue 1053: Transcript updates from foreground process not displayed in Transcript window - Issue 1063: Class var order in Monticello (bogus dirty packages) - Issue 1019: 0006579: String>>#findLastOccuranceOfString:startingAt: isBuggedWhen: [substring first=substring last (now with deprecation of old method) - Issue 1087: tallyIt nows trigger a complete profiling (also renamed tally it to profile it) - Browser label: do not print 'System Browser: <Class>' but only '<Class>' - Disable window animation for closing 35 issues left for milestone 1.0. BTW: Yesterday, Pharo was on Y Combinator Hacker News: "Pharo: a Smalltalk VM that doesn't look like a toy out of the box" (http://news.ycombinator.com/item?id=787363 ) ___________________ http://www.adrian-lienhard.ch/

Aug. 27, 2009

Re: [Pharo-project] [ANN] Pharo-Kernel

by Lukas Renggli

Great work Pavel! For many Seaside deployments I am still using the Morphic-Kernel images you made in Squeak 3.9 and can't wait to upgrade to Pharo equivalents. Cheers, Lukas 2009/8/27 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi all, > > I've prepared a set of shrinking scripts and patches that create a headless > image with only basic kernel classes from the Pharo-Core. The output image > has about 2 MB. > > It is the bleeding edge project that should help in Pharo modularization and > cleanup. It currently more or less corresponds to basic.image from the > KernelImage so it doesn't include GUI, network support, Monticello etc., > however SUnit and kernel tests are supported. > > For more information and downloads see > http://code.google.com/p/pharo/wiki/PharoKernel > > Cheers, > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Aug. 27, 2009

Re: [Pharo-project] [ANN] Pharo-Kernel

by Pavel Krivanek

No, it isn't, at least for now. In fact it is not hard, it would take about two days to prepare it, however it would be too big step and I don't see it as the priority. Priorities are integration with Pharo, network support and Monticello. -- Pavel On Thu, Aug 27, 2009 at 8:32 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > This is amazing Pavel. Is there a way to load the GUI back? > > Alexandre > > On 27 Aug 2009, at 14:24, Pavel Krivanek wrote: > > > Hi all, > > > > I've prepared a set of shrinking scripts and patches that create a > > headless image with only basic kernel classes from the Pharo-Core. > > The output image has about 2 MB. > > > > It is the bleeding edge project that should help in Pharo > > modularization and cleanup. It currently more or less corresponds to > > basic.image from the KernelImage so it doesn't include GUI, network > > support, Monticello etc., however SUnit and kernel tests are > > supported. > > > > For more information and downloads see > http://code.google.com/p/pharo/wiki/PharoKernel > > > > Cheers, > > -- Pavel > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 27, 2009

Re: [Pharo-project] [ANN] Pharo-Kernel

by Alexandre Bergel

This is amazing Pavel. Is there a way to load the GUI back? Alexandre On 27 Aug 2009, at 14:24, Pavel Krivanek wrote: > Hi all, > > I've prepared a set of shrinking scripts and patches that create a > headless image with only basic kernel classes from the Pharo-Core. > The output image has about 2 MB. > > It is the bleeding edge project that should help in Pharo > modularization and cleanup. It currently more or less corresponds to > basic.image from the KernelImage so it doesn't include GUI, network > support, Monticello etc., however SUnit and kernel tests are > supported. > > For more information and downloads see http://code.google.com/p/pharo/wiki/PharoKernel > > Cheers, > -- Pavel > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 27, 2009

Re: [Pharo-project] PBE and OB

by Alexandre Bergel

Hi David, I do not understand what I should do to load the Package Browser. Apparently, loadOBAlpha is broken in an updated 414. I tried to insert: instClass ss project: 'EnhancedOB'; install: 'OmniBrowser2'; install: 'O2-Enhancements'; install: 'O2-Morphic'; install: 'O2-Standard'. in loadOBAlpha, but this remains unsuccessful. Any hint how I can load your browser in a Core 414? Alexandre On 26 Aug 2009, at 06:01, David RÃ¶thlisberger wrote: > Hi, > > Lukas and me made it possible to load both versions of OmniBrowser > into the same image, the OB version of Colin and my OB version > providing the package browser. > As we said we duplicated the package browser OB packages to be able > to have both versions of OB in the same image. That solution is not > too nice, but in the short-term it should be fair enough until we > have real package support and can thus make the package browser more > efficient. > > To load the OB package browser packages, you need to load all > packages from this repo: > http://www.squeaksource.com/EnhancedOB/ > > You can then choose between OBSystemBrowser, O2SystemBrowser and > O2PackageBrowser. > > If you find any problems, let me know. > > Cheers, > David > > >> Excellent and thanks a lot you two. >> When you see that squeak is now doing all the same than us this is >> really important. >> I really appreciate your effort. >> On Aug 19, 2009, at 10:36 AM, David RÃ¶thlisberger wrote: >>> Hi, >>> >>> the package browser is again loadable also in latest Pharo by >>> executing 'ScriptLoader loadOBAlpha'. >>> This will load all required packages of OB as the package browser >>> needs it. This means that there will be a slighly different OB >>> code base in the image than what has been provided by Lukas' OB >>> version. >>> This also means that right now we can not use both browsers >>> (Lukas' category- and my package based) at the same time. >>> Lukas and me will work on making this possible on Monday. >>> >>> But note that you can use the system (category-based) and the >>> package browser based on the OB code base I maintained at the same >>> time; I think that's already good. I don't expect Lukas' version >>> of the system browser to be much faster. >>> >>> Cheers, >>> David >>> >>>> Excellent! >>>> I will continue to work on the package rewrite and like that for >>>> 1.1 we should have something. >>>> Stef >>>> On Aug 18, 2009, at 10:54 AM, Oscar Nierstrasz wrote: >>>>> >>>>> Hi Stef, >>>>> >>>>> I discussed with Lukas and David this morning. >>>>> >>>>> David will work this week (today?) to make sure that OB- >>>>> ENhancements can be loaded. >>>>> >>>>> Next week Monday, David and Lukas will sit together to create a >>>>> separate (renamed) package of David's OB, so the two browsers >>>>> can live in the same image, and the user can switch between >>>>> them. (Lukas estimates just an hour or so of work -- optimism >>>>> wins, I guess ;-) We can then include version this in the pharo- >>>>> dev image and in the PBE image. I will adapt the book to make >>>>> it clear that the user can switch between them. >>>>> >>>>> This is purely a stop-gap measure, as we eventually replace both >>>>> by a fast package browser (I guess) in the coming months. >>>>> >>>>> Sound ok to you? >>>>> >>>>> Cheers, >>>>> - on >>>>> >>>>> On Aug 17, 2009, at 17:05, StÃ©phane Ducasse wrote: >>>>> >>>>>> Yes now for pharo 1.0 it would be great if we could have >>>>>> fast lukas browser >>>>>> slow package browser >>>>>> all in the same image. >>>>>> >>>>>> can you check that with david? >>>>>> We do not care for speed now. >>>>>> and I will continue to work on the package but having a smooth >>>>>> integration/migration with/from the packageInfo >>>>>> >>>>> >>> >>> -- >>> ________________________________ >>> Mit freundlichen GrÃ¼ssen >>> David RÃ¶thlisberger >>> Doktorand Software Composition Group, IAM >>> UniversitÃ¤t Bern > > -- > ________________________________ > Mit freundlichen GrÃ¼ssen > David RÃ¶thlisberger > Doktorand Software Composition Group, IAM > UniversitÃ¤t Bern -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 27, 2009

[Pharo-project] [ANN] Pharo-Kernel

by Pavel Krivanek

Hi all, I've prepared a set of shrinking scripts and patches that create a headless image with only basic kernel classes from the Pharo-Core. The output image has about 2 MB. It is the bleeding edge project that should help in Pharo modularization and cleanup. It currently more or less corresponds to basic.image from the KernelImage so it doesn't include GUI, network support, Monticello etc., however SUnit and kernel tests are supported. For more information and downloads see http://code.google.com/p/pharo/wiki/PharoKernel Cheers, -- Pavel

Aug. 27, 2009

Re: [Pharo-project] Fwd: about setting and preference.

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > On Aug 27, 2009, at 4:47 PM, Lukas Renggli wrote: > > >>> I see. Let us reply alain and we talk about that at ESUG satruday or >>> sunday. >>> >> Yes, let's do that. I will arrive saturday evening. >> > > Yes it will be a busy week. > >>>> Why isn't a setting simply a variable local to the package, and the >>>> setting-description a separate object (method) that can also be >>>> packaged separately? >>>> >>> it is. Normally alain is transforming all preferences into class >>> variable of the package >>> then I imagine that we should describe the setting so that a browser >>> can browse and >>> change the value of the setting. The flow should be local to the >>> class >>> and not going via >>> a global like Preference. So probably the setting description should >>> be class extension. >>> But there is something I should understand deeper. >>> >> Maybe I am missing something, but to me it looks like the value of the >> setting is stored within its setting instance. This should be >> separate, because Seaside for example should not be forced to care >> about the settings, but an extra package might provide the >> setting-descriptions to the existing accessors so that the server can >> be started/stopped through the Pharo preference pane. >> > > Yes! > I agree it can be good to clearly separate a setting value from its specification. It means that a setting should know how to set/get the value from an object instead of directly store the value. I see at least three drawbacks: (1) the setting declaration is more complex, (2) a setter and a getter have to be implemented for each setting + the setting specification (three methods instead of only one) (3) the change notification feature is lost (see section 7.2 from the SettingManager comment) Cheers Alain > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Aug. 27, 2009

Re: [Pharo-project] Fwd: about setting and preference.

by StÃ©phane Ducasse

On Aug 27, 2009, at 4:47 PM, Lukas Renggli wrote: >> I see. Let us reply alain and we talk about that at ESUG satruday or >> sunday. > > Yes, let's do that. I will arrive saturday evening. Yes it will be a busy week. > >>> Why isn't a setting simply a variable local to the package, and the >>> setting-description a separate object (method) that can also be >>> packaged separately? >> >> it is. Normally alain is transforming all preferences into class >> variable of the package >> then I imagine that we should describe the setting so that a browser >> can browse and >> change the value of the setting. The flow should be local to the >> class >> and not going via >> a global like Preference. So probably the setting description should >> be class extension. >> But there is something I should understand deeper. > > Maybe I am missing something, but to me it looks like the value of the > setting is stored within its setting instance. This should be > separate, because Seaside for example should not be forced to care > about the settings, but an extra package might provide the > setting-descriptions to the existing accessors so that the server can > be started/stopped through the Pharo preference pane. Yes!

Aug. 27, 2009

Re: [Pharo-project] Fwd: about setting and preference.

by Lukas Renggli

> I see. Let us reply alain and we talk about that at ESUG satruday or > sunday. Yes, let's do that. I will arrive saturday evening. >> Why isn't a setting simply a variable local to the package, and the >> setting-description a separate object (method) that can also be >> packaged separately? > > it is. Normally alain is transforming all preferences into class > variable of the package > then I imagine that we should describe the setting so that a browser > can browse and > change the value of the setting. The flow should be local to the class > and not going via > a global like Preference. So probably the setting description should > be class extension. > But there is something I should understand deeper. Maybe I am missing something, but to me it looks like the value of the setting is stored within its setting instance. This should be separate, because Seaside for example should not be forced to care about the settings, but an extra package might provide the setting-descriptions to the existing accessors so that the server can be started/stopped through the Pharo preference pane. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Aug. 27, 2009

[Pharo-project] Loading packages with Gofer and Flair

by Fernando olivero

Hi, How can i specify post install actions when using Gofer and Flair protocol. If i implement SomePackageLoader>>#load, i can send the message #postInstall. SomePackageLoader >>load | config | self ensureFlairAndGofer. config := (Smalltalk at: #FLConfiguration) new. self allFor: config. config load. self postInstall. But i've also seen the FLoadable>>postLoadAction: method, but when i used i've get an erro with a description that it shouldnt be used. Thanks, Fernando

Aug. 27, 2009