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

[Pharo-project] [update 1.2] #12336
by StÃ©phane Ducasse Feb. 16, 2011

Feb. 16, 2011

12336 ----- Issue 3583: Shout should only be active in code panes. - FixWorkspaceAgain.1 - FixWorkspace1.2.1 - PrepareFixWorkspaceMenu.2 - FixWorkspaceMenu.2.cs Thanks Benjamin van Ryseghem. Stef (just spent one hour on that...)

1 0

[Pharo-project] Issue 3714 in pharo: CS removeSelector does not dirty packages
by pharo＠googlecode.com Feb. 16, 2011

Feb. 16, 2011

Status: Accepted Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3714 by stephane...(a)gmail.com: CS removeSelector does not dirty packages http://code.google.com/p/pharo/issues/detail?id=3714 Workspace removeSelector: #embeddedInMorphicWindowLabeled:! does not make the package dirty. This can be normal because this is a low level API method. Now this expression is saved in the changeset when we remove a method. So the task to do is: - check if there is another API method that raise the correct notification of changes - change ChangeSorter to use this api

1 1

[Pharo-project] Apparently removeSelector: does not dirty packages...
by StÃ©phane Ducasse Feb. 16, 2011

Feb. 16, 2011

For example Workspace removeSelector: #embeddedInMorphicWindowLabeled:! does not make the package dirty. This can be normal because this is a low level API method. Now this expression is saved in the changeset when we remove a method. So the task to do is: - check if there is another API method that raise the correct notification of changes - change ChangeSorter to use this api http://code.google.com/p/pharo/issues/detail?id=3714 Stef

1 0

[Pharo-project] Loading Seaside into Pharo 1.2 core
by Torsten Bergmann Feb. 16, 2011

Feb. 16, 2011

Dale wrote: >I am presently working on Seaside 3.0.4 which will correctly load into >Pharo1.2, According to his mail Mike wants to load it into a Pharo1.2-Core (maybe for minimal deployment) - not into a Pharo1.2-Developer image. So the expression (ConfigurationOfSeaside30 project version: '3.0.3') load. will only work in a Pharo 1.2 (dev image) since it requires various tools (like OB) that are only in the dev image and there seem to be no explicit dependencies defined. Otherwise it should load into Core too, should'nt it? Still this is more or less for a typical "seaside development scenario". However - for a "deployment scenario on a core image" one has to find out the groups required. That depends on what the seaside application uses. Think of the following: one wants to use a minimal Pharo core 1.2 image and just run a simple Seaside webapp on it. For such a minimal app you need to: "Load the config" Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. "Load the base seaside packages and Comanche as server" ((Smalltalk at: #ConfigurationOfSeaside30) project version: '3.0.3') load: #('Base' 'Seaside-Adaptors-Comanche'). You can then start the web server: WAKom startOn: 80 but you will not be able to see more than http://localhost/files as Dale already mentioned. Now implement a simple Seaside component: WAComponent subclass: #MyAppFrontPage instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'MyApp-Web-UI' with the following rendering method on the instance side: renderContentOn: html html text: 'HelloWorld' And register it: WAAdmin register: MyAppFrontPage asApplicationAt: 'myapp'. You can browse it at: http://localhost/myapp If you want to make it the default entry point: WADispatcher default defaultName: 'myapp' This allows you to access it directly on: http://localhost All this is summarized and done in the attached changeset. Just drop it into a fresh core 1.2 image or file it in using the file browser, then see some loading magic and after its finished point your browser to http://localhost Have fun T. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

3 3

[Pharo-project] Are the tests in PharoOneClick finishing
by StÃ©phane Ducasse Feb. 16, 2011

Feb. 16, 2011

Hi guys I'm trying to push 1.2 to get it out and the tests do not finish when I run them using the latest oneClick. Can somebody try and let me know. Stef

2 2

Re: [Pharo-project] Working with weak announcements...
by Tudor Girba Feb. 15, 2011

Feb. 15, 2011

Hi Esteban, I started to refactor all usages of on:do: and when:do: into on:send:to: in the core of Glamour. I am almost finished. Now the only question is if we want to distinguish between WeakAnnouncer and Announcer. Is there a performance penalty or another kind of drawback in merging the two and use the WeakAnnouncer implementation only? The other thing is that we need to add on:send:to:with: and on:send:to:withAll: because we need to handle extra parameters (given that we cannot access local variables). Cheers, Doru On 15 Feb 2011, at 13:45, Esteban Lorenzano wrote: > Well... not exactly, still something to do: the weak associations on weakannouncer are getting a lot of pairs #selector->nil and we need to think in a way to clean this. But this is doable :) > In other order of things, I think we should explicitly forbid the use of #on:do: and #when:do: until the fix for blocks is ready. > > Cheers, > Esteban > > El 14/02/2011, a las 6:55p.m., Tudor Girba escribiÃ³: > >> Aha. Thanks a lot. Ok, let's do that. Is it true that the Lukas' Announcements already provide the support for on:send:to: ? >> >> Cheers, >> Doru >> >> >> On 14 Feb 2011, at 22:04, Esteban Lorenzano wrote: >> >>> Hi, >>> Well, this means, in the mean time, if we want to solve our issue 492 using weak announcements, we need to replace all #on:do: calls for #on:send:to: >>> :( >>> >>> Cheers, >>> Esteban >>> >>> Inicio del mensaje reenviado: >>> >>>> De: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>> Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00 >>>> Para: Pharo-project(a)lists.gforge.inria.fr >>>> Asunto: Re: [Pharo-project] Working with weak announcements... >>>> Responder a: Pharo-project(a)lists.gforge.inria.fr >>>> >>>> good question :) >>>> >>>> On FHi, >>>>> I'm working with weak announcements, >>>> >>>> good we need that. >>>> Igor was telling me that the right anwser are ephemerons (but for that: gc change is required). >>>> Now it would be good to have first a solution at image level >>>> >>>>> trying to make it work, and I have a problem in #on:do: protocol (or #when:do:) >>>>> I try to explain: >>>>> >>>>> This method receives a block, not an object/selector, so I can't create a WeakMessageSend which is the appropriate message to handle in other cases. >>>>> Well, the real question is... how can I produce a "Weak BlockClosure reference" who can die if receiver dies? >>>>> I tried some hacks (really ugly hacks, btw), but fail completely. >>>>> Any idea? >>>>> >>>>> best, >>>>> Esteban >>>> >>>> >>> >> >> -- >> www.tudorgirba.com >> >> "Problem solving efficiency grows with the abstractness level of problem understanding." >> >> >> > -- www.tudorgirba.com "Reasonable is what we are accustomed with."

2 6

[Pharo-project] shout and Pharo 1.2 or 1.3
by Hilaire Fernandes Feb. 15, 2011

Feb. 15, 2011

I have been reading the related discussion in the bug tracker. It is not clear to me if finally shout will eventually work with 1.2. I am going to prepare a DrGeo public release where I want shout, I am wondering if I should just use early 1.3 Pharo to do (where shout works nicely). Are there any reason or pitfall I should be aware of before doing so? Thanks hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

2 2

[Pharo-project] Cog builds on Hudson
by Igor Stasenko Feb. 15, 2011

Feb. 15, 2011

I modified the Cog config made by Marcus to sync with my changes in scripts. https://pharo-ic.lille.inria.fr/hudson/view/Cog/ i also added a new target for building - Stack VM (except that it not works now, because Hudson can't pick up the built artifacts despite VM built successfully -- lets wait for Marcus to fix that , since i'm not expert in Hudson :) ). Adding another two is also a piece of cake - just copy existing configuration and change destination directory and configuration class used for generating sources and build config. The script i made for Hudson can work even for macs, it takes 3 arguments: - git repo url - working subdirectory name where to place everything - cmake configuration class name (which build to perform) that's all you need to build VM from scratch using Hudson -- Best regards, Igor Stasenko AKA sig.

2 2

[Pharo-project] Working with weak announcements...
by Esteban Lorenzano Feb. 15, 2011

Feb. 15, 2011

Hi, I'm working with weak announcements, trying to make it work, and I have a problem in #on:do: protocol (or #when:do:) I try to explain: This method receives a block, not an object/selector, so I can't create a WeakMessageSend which is the appropriate message to handle in other cases. Well, the real question is... how can I produce a "Weak BlockClosure reference" who can die if receiver dies? I tried some hacks (really ugly hacks, btw), but fail completely. Any idea? best, Esteban

5 8

[Pharo-project] [COTDC] 11 - ColorMappingCanvas
by laurent laffont Feb. 15, 2011

Feb. 15, 2011

Today: ColorMappingCanvas Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

4 8