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

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #68 on issue 3583 by Benjamin...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 I trie din a 12335 with the two last cs (FixWorkspaceAgain and FixSHWorkspace) I type a := 1 here 'a' appears in red, as expected. Then above this line I add | a | this line is in grey, and a turn in grey too in the expression, as expected too :s So either it works or I haven't understood what you've done ... (see attachments for screenshots) Attachments: Screen shot 2011-02-15 at 11.28.37 AM.png 14.2 KB Screen shot 2011-02-15 at 11.28.58 AM.png 14.4 KB

Feb. 15, 2011

[Pharo-project] RPackage images

by Torsten Bergmann

Is there any documentation available on RPackage already? Or a help book? -- Schon gehÃ¶rt? GMX hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://www.gmx.net/de/go/toolbar

Feb. 15, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #67 on issue 3583 by Benjamin...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 I was wrong in the name of the cs. What I said was about FixSHWorkspace. FixWorkspaceAgain make shout works in 1.2 core + shout (a method was not removed as it should have been) I take a look at your problem

Feb. 15, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #66 on issue 3583 by tudor.gi...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 Thanks for the clarifications. The problem I described happens in Pharo 1.2 (dev)

Feb. 15, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #65 on issue 3583 by Benjamin...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 In fact, without the FixWorkspaceAgain cs, shout (should) works in: - 1.2 core + Shout - 1.3 core + Shout But not in 1.2 Dev due to SHWorkspace. So now it should work in: - 1.2 core + Shout - 12. Dev - 1.3 Core - Probably 1.3 Dev too For your problem, it happens in which image ? 1.2 core, 1.2 dev or 1.3 core ? I will check that, and try to fix it because it's time to finally close this entry ^^

Feb. 15, 2011

Re: [Pharo-project] RPackage images

by Tudor Girba

Thanks Cyrille. It is also useful to announce that Moose now relies on RPackage to import models out of Smalltalk code. Cheers, Doru On 15 Feb 2011, at 10:38, Cyrille Delaunay wrote: > We have now an hudson job that build images with RPackage integrated and that run all the tests in the image: > > https://pharo-ic.lille.inria.fr/hudson/view/Pharo-TaskForces/job/Pharo%20RP… > > Feel free to use it and report any problem. > See also: > > http://code.google.com/p/pharo/issues/detail?id=3609&q=RPackage&colspec=ID%… -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

Feb. 15, 2011

[Pharo-project] Loading Seaside into Pharo 1.2 core

by Torsten Bergmann

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

Feb. 15, 2011

[Pharo-project] RPackage images

by Cyrille Delaunay

We have now an hudson job that build images with RPackage integrated and that run all the tests in the image: https://pharo-ic.lille.inria.fr/hudson/view/Pharo-TaskForces/job/Pharo%20RP… Feel free to use it and report any problem. See also: http://code.google.com/p/pharo/issues/detail?id=3609&q=RPackage&colspec=ID%…

Feb. 15, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #64 on issue 3583 by tudor.gi...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 As I understand, FixWorkspaceAgain.1.cs should be integrated in Pharo, and the latest version of SHWorkspace should work in both 1.2 and 1.3. I tested it, but there still is a problem - I type: a := 1. - a appears red because it's not defined yet. - I do it. - Whatever I do afterwards, a still appears like undefined.

Feb. 15, 2011

Re: [Pharo-project] Working with weak announcements...

by StÃ©phane Ducasse

Igor now the problem is how much time do you expect it may take to introduce ephemerons? Else having well documented patterns is also important. Stef On Feb 14, 2011, at 10:33 PM, Igor Stasenko wrote: > On 14 February 2011 21:52, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> 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? >> > > Don't even try doing it until we will have ephemerons support at VM side :) > > I explained this few days ago to Stephane, and also i mentioned about > this maybe half of year ago when i took a look at announcements. > > With ephemerons you can have: > - reference a block strongly only if subscriber , which held weakly is alive. > > Once subscribed dies, you start referencing block weakly. > > In terms on GC it means, that during mark phase, you are visiting a > references which reachable through block closure only if your > subscriber are already marked as 'live'. > > So, this means that you can do weak subscriptions like following: > > > self weakOn: Foo do: [:announcement | self bar ]. > > A 'self' is a subscriber. But if you create a subscription from a pair of: > <subscriber> and <block> > without using ephemerons you should make sure that reference to > subscriber are not reachable through given block. > Otherwise, a weak reference become strong one, because you referencing > a block strongly and therefore subscriber too, > since block referencing subscriber through one of its vars. > > So, without ephemerons you have to invent some workarounds by > rewriting above code with something like: > > > self weakOn: Foo do: [:announcement :myself | > myself bar > ]. > > in the above, a block no longer referencing receiver (a subsriber), > and instead it will be passed as extra argument > to the block. > > ( except that still, you will have a problem, if closure keeps a > reference to home context, which in own turn referencing subscriber > through context's receiver.. so without emphemerons you should be > really careful) > > And of course, i think that the usefulness of Announcements is quite > limited without proper weak subscription support, > because weak subscriptions makes things a lot more easier: you don't > have to explicitly unsubscribe some object, once you no longer using > it , > which as to me means that about 99% of all subscriptions in system > will be weak ones , simply to prevent potential problems with hanging > references, and because you don't have to worry about unsubscribing. > > And of course, without weak-block subscriptions, the ease of use of > subscription mechanism is a bit limited. > So, instead of writing simple and cool: > > self weakOn: Foo do: [:announcement | self bar ]. > > > you must do more elaborate (and IMO less elegant) > > self weakOn: Foo send: #handleFooAnnouncement: . > > and then in #handleFooAnnouncement: you making 'self bar' > > P.S. the #weakOn: ... is not part of Announcements protocol , it is > just an example of 'meta-message' to reveal an intent to create a weak > subscription to some announcer by using receiver as a subscriber. > > >> best, >> Esteban >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Feb. 15, 2011