May 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] [regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 1 regressions found. Zinc.Tests.ZnClientTests.testRedirect

May 14, 2013

[Pharo-project] [regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 1 regressions found. Zinc.Tests.ZnClientTests.testRedirect

May 14, 2013

[Pharo-project] [regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 1 regressions found. Zinc.Tests.ZnClientTests.testRedirect

May 14, 2013

[update 3.0] #30127

by Marcus Denker

30127 ----- 10617 fix accessor RBMethodNode>>#compilationContext in Image https://pharo.fogbugz.com/f/cases/10617 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Core-MarcusDenker.148.diff

May 14, 2013

Re: [Pharo-dev] [Pharo-users] success story: NTed

by Norbert Hartl

Hi Nico, > I do have one question: what was your experience with Amber? > as an overall statement I would say it was a pleasure to use amber to develop the app. The initial setup until the class browser opens is easy. Learning how to create packages and knowing that code persistence is based on packages is also quite ok because amber includes a WebDav Server that can be started from the downloaded amber repo. So no big problems in starting. Thinks that go less smooth: - the web app I'm developing is checked into git. Amber puts all files (js and st) in the same directory. This makes managing files in version control system a bit cumbersome. - all code is put in the same directory. The amber code checked out from the repository is in the same place as the code that I produced myself. Again you need to do additional steps to do to clean it up - tools for combining code are missing. That is not a big problem because a simple cat on the console can solve this but would be nice not have to. - I prepared two different locations on my web server for the same app. One that is used to develop (the WebDav server access it) and one where only the combined javascript source code is used. This is needed to test the target deployment. Something that could ease this would be wonderful What keeps me from using it in every project: - The startup times for amber can be quite huge. All the class initialization is a lot of stuff that burns CPU cycle. On an iphone you don't notice really but on the Nexus 7 tablet it takes 2-4 seconds for initialization and the first page to appear. This is a not a problem for desktop browsers but for mobile ones where I find amber extremely good for. I only used amber in pre pre 1.0 versions and I know there have been optimizations that I didn't test, yet. And the annoying "You didn't ask for but I add it anyway wishlist": - I need to test Helios because I think it solves a lot of issues with the current browser. I don't know how it is supposed to work that you have a second window with the IDE that accesses a page. But I'm sure it works flawlessly or I misunderstood it from the screenshots - retarget files on the disc. I would like to have different paths on disc for separate packages. - amber using websockets to connect to a backend pharo server. This can be used for comfortable code management, amber support for state transport client->server and server->client and to replicate console log to the pharo transcript (or whatever). This is important on mobile devices where sometimes you cannot access the browser console. - it would be fine to have support for obfuscation. It is not only for hiding code but also for making it smaller thus saving bandwidth and startup times. This could be the case if the produced javascript code would be work with google closure compiler. Even better would be to have visitor for AST/IR to make it even more effective/less dangerous. Norbert Am 14.05.2013 um 15:32 schrieb Nicolas Petton <petton.nicolas(a)gmail.com>: > Nico > > > On May 14, 2013, at 11:37 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I think my last post of this message fell into the time the old mailing list dies. So here it is again >> >> --- >> >> We (@2denker in cooperation with a local university) built a monitoring tool for disaster scenario recovery rehearsals. Several times a year universities, red cross, THW und hospitals are planning a rehearsal together. For this an environment is prepared for a simulated disaster (car accidents, explosions in civil areas, â¦). The local environment is prepared to look real as well as film make-up artist prepare people for injuries (broken legs, open head, â¦). >> The rehearsal should improve the coordination of several hospitals, firemenâ¦as well as the quickest possible treatment for the injured. >> >> One important part of the rehearsal is monitoring of what happens. This is achieved by installing a local position system and using our tool. Every injured person gets a wireless tablet. On the tablet there are UI elements that indicate treatment done to them. Whenever a doctor comes visiting the injured person activates the corresponding UI button. The events are transmitted to a server and are prepared for another analysis software. The tablet enables the HQ to make contact to individual persons or groups. The tablet measures times of needed treatments and instructs the injured to be dead if measurements weren't taken in time. >> >> Technically it is done in smalltalk solo. >> >> The server is a pharo image. It has >> >> - web admin interface with complex forms for managing injuries, injured, groups, etc. For this we used seaside because it is best suited for this job. Forms are done with magritte, magritte-bootstrap. The interface also displays the live incoming events and other data >> - a static file server that delivers static resources to client tablets >> - a websocket connector that is used by the clients to connect to the server >> - a http handler to export data to other analysis tools >> >> The client is done with amber smalltalk. It >> >> - loads the web page containing amber from the server >> - connects back to the server >> - downloads a UI spec for the injured using the tablet to display personalized UI elements >> - stores events on the tablet in case the injured is offline >> - measures times to instruct the injured >> >> If you have any questions please don't hesitate to ask. >> >> Norbert > > -- > Nicolas Petton > http://www.nicolas-petton.fr > >

May 14, 2013

Re: [Pharo-dev] about theme and friends

by Gary Chambers

Please do bear in mind having multiple themes concurrently in use. Whilst we have a theme for the devolopment environment, instances of applications can have their own etc. Regards, Gary ----- Original Message ----- From: Benjamin To: Discusses Development of Pharo Sent: Tuesday, May 14, 2013 4:22 PM Subject: Re: [Pharo-dev] about theme and friends Ok, my bad :) This is a massive refactoring, but indeed, it may be cool :) Ben On May 14, 2013, at 5:18 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: On May 14, 2013, at 5:13 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: The problem is the overlapping. For settings, different project do not define the same settings. But for tools, it's different By example, Browser, and Nautilus will try to register to default browser. I'm not talking about this level. No registration about tools. UITheme does not deal with that. The current theme should push to all the widgets that the defaultColor is blue. Ben On May 14, 2013, at 4:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: esteban I discussed with damien and I think that now I got the solution. In fact the architecture should be the same than the one of settings. Every widget should have custom hooks and setter, getter and default values. The hooks should be annotated or registered seomwhere. Then the widget code simply uses the hooks normally. Now a theme changes should push new values onto these hooks. This will lead to a flow that is totally different. Nobody should write UITheme builder or even Smalltalk ui theme. I will try to build a small experiment but I'm sure that this is the solution Nobody call settings nowadays (as it was the case with Preferences in the past). Stef

May 14, 2013

Re: [Pharo-dev] Killing respondsTo:

by Benjamin

Something like self performIfExists: #blah would reduce the noise a lot :) Then in this methods, we do what we want ^^ Ben On May 14, 2013, at 5:32 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 14 May 2013 16:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi >> >> I'm in favor killing all the respondsTo: >> >> acceptTextMorphs >> "Accept any text morphs except for those that have no edits." >> >> self allMorphs do: [:p | >> ((p respondsTo: #accept) and: [ >> (p respondsTo: #hasUnacceptedEdits) and: [ >> p hasUnacceptedEdits]]) ifTrue: [p accept]] > > They're a step up from #isKindOf:. It looks like you need is something > that says "does this object respond to a particular set of messages > (i.e., a Protocol)?". (No, Nicolas, I don't mean a message category! > :) ) > > But in this particular case the solution looks like making a > #insertADecentNameHere that particular classes of things can implement > as "^ self hasUnacceptedEdits ifTrue: [self accept]" > > frank >

May 14, 2013

Re: [Pharo-project] Stick figure in Pharo smalltalk

by Hilaire Fernandes

Le 08/05/2013 21:18, Sean P. DeNigris a Ã©crit : >> man := Morph new. >> head := CircleMorph new color: Color black . >> body := LineMorph new. >> man addMorph: head. >> man addMorph: body. >> man openInWindow. >> >> it will give you a circle and a line in a window, but the line i can >> adjust the point property. I wondering if anyone could pt. me in the right >> direction. To do what? sending #betSticky message, is it what you are looking for? Hilaire -- Dr. Geo http://drgeo.eu

May 14, 2013

Re: [Pharo-dev] Killing respondsTo:

by Frank Shearar

On 14 May 2013 16:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > I'm in favor killing all the respondsTo: > > acceptTextMorphs > "Accept any text morphs except for those that have no edits." > > self allMorphs do: [:p | > ((p respondsTo: #accept) and: [ > (p respondsTo: #hasUnacceptedEdits) and: [ > p hasUnacceptedEdits]]) ifTrue: [p accept]] They're a step up from #isKindOf:. It looks like you need is something that says "does this object respond to a particular set of messages (i.e., a Protocol)?". (No, Nicolas, I don't mean a message category! :) ) But in this particular case the solution looks like making a #insertADecentNameHere that particular classes of things can implement as "^ self hasUnacceptedEdits ifTrue: [self accept]" frank

May 14, 2013

Re: [Pharo-dev] Killing respondsTo:

by Guillermo Polito

Me too, do you have free the friday afternoon to sprint on them? :D On Tue, May 14, 2013 at 5:21 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi > > I'm in favor killing all the respondsTo: > > acceptTextMorphs > "Accept any text morphs except for those that have no edits." > > self allMorphs do: [:p | > ((p respondsTo: #accept) and: [ > (p respondsTo: #hasUnacceptedEdits) and: [ > p hasUnacceptedEdits]]) ifTrue: [p accept]] > > :) > > And there are too many Smalltalk references in the system > >

May 14, 2013