April 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Ho to spare a Pharo desktop application user from seeing the debugger?

by Igor Stasenko

On 15 April 2013 00:39, Cameron Sanders <camsanders(a)aol.com> wrote: > Not unreasonable. What if you are out of memory? Can you restart? Exception > is fine at the highest level. > well, most programs pay little attention on consumed resources. and usually there is no monitoring for consumption. when you meet such situation, usual behavior is crash with sound of thousands of breaking glasses :) > I recommend employing [] on: Error do: [] at various intermediate to high > levels of application code -- as distinguished from "library" level objects > and packages. > > At application level, trapping Errors (in bulk!) can lead to much cleaner > fault-tolerant code without branching for the dozens of reasons something > could fail. And then tabulate those errors and present them (electively) for > the user... or to a system log-file. > > -Cam > > > > > On Sat, Apr 13, 2013 at 2:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 13 April 2013 18:41, MartinW <wm(a)fastmail.fm> wrote: >> > I deploy a Pharo desktop application and i want to spare the user from >> > seeing >> > the debugger, because most users would not know what to do with it. >> > >> > My solution for the moment is to place an [] on: Exception do: [] around >> > my >> > application's entrance point: >> > [ "main application workflow" ] on: Exception do: [ self inform: >> > 'Something >> > has gone wrong...'. "and restart application"] >> > >> > Do you think, this an acceptable solution? Are there others? >> > M. >> > >> >> Fairly acceptable. >> You need to handle error condition in one way or another, if you don't >> wanna >> show debugger to user. >> >> But if your application spawns multiple threads, then it will still >> pop up debugger >> if error will happen in one of those threads (unless of course you >> also wrap everything with exception handler).. >> actually handling unexpected (exceptional) cases is a good practice :) >> >> >> > -- >> > View this message in context: >> > http://forum.world.st/Ho-to-spare-a-Pharo-desktop-application-user-from-see… >> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

April 14, 2013

Re: [Pharo-users] Ho to spare a Pharo desktop application user from seeing the debugger?

by Cameron Sanders

Not unreasonable. What if you are out of memory? Can you restart? Exception is fine at the highest level. I recommend employing [] on: Error do: [] at various intermediate to high levels of application code -- as distinguished from "library" level objects and packages. At application level, trapping Errors (in bulk!) can lead to much cleaner fault-tolerant code without branching for the dozens of reasons something could fail. And then tabulate those errors and present them (electively) for the user... or to a system log-file. -Cam On Sat, Apr 13, 2013 at 2:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 13 April 2013 18:41, MartinW <wm(a)fastmail.fm> wrote: > > I deploy a Pharo desktop application and i want to spare the user from > seeing > > the debugger, because most users would not know what to do with it. > > > > My solution for the moment is to place an [] on: Exception do: [] around > my > > application's entrance point: > > [ "main application workflow" ] on: Exception do: [ self inform: > 'Something > > has gone wrong...'. "and restart application"] > > > > Do you think, this an acceptable solution? Are there others? > > M. > > > > Fairly acceptable. > You need to handle error condition in one way or another, if you don't > wanna > show debugger to user. > > But if your application spawns multiple threads, then it will still > pop up debugger > if error will happen in one of those threads (unless of course you > also wrap everything with exception handler).. > actually handling unexpected (exceptional) cases is a good practice :) > > > > -- > > View this message in context: > http://forum.world.st/Ho-to-spare-a-Pharo-desktop-application-user-from-see… > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > -- > Best regards, > Igor Stasenko. > >

April 14, 2013

Videos: MongoDB

by Stephan Eggermont

Taming MongoDB from Pharo https://www.youtube.com/watch?v=LOFygLIRLY8 now uploading: Pharo from the CommandLine

April 14, 2013

Another spec question

by Paul Davidowitz

Is it correct to speculate that Pharo spec is based on VisualWorks spec? If so, can someone please elaborate? Thanks, -Paul

April 14, 2013

Re: [Pharo-users] TreeListMorph or MorphTreeMorph

by Hilaire Fernandes

Le 14/04/2013 17:37, Benjamin a Ã©crit : > But a new implementation is in the starting block :) > Ben I just started to write a few notes to get the logic, and was thinking I could wrote a small note on the colaboractive book. Hilaire -- Dr. Geo http://drgeo.eu

April 14, 2013

Re: [Pharo-users] TreeListMorph or MorphTreeMorph

by Hilaire Fernandes

Le 14/04/2013 17:37, Benjamin a Ã©crit : > But a new implementation is in the starting block :) > Ben Ohoh, will it be compatible? Or should I wait? Hilaire -- Dr. Geo http://drgeo.eu

April 14, 2013

The Rationale behind Spec - questions

by Kenneth Payne

As a newcomer to smalltalk and Pharo I must say I love it - but I'm a little mystified by Spec. Just as I've got my head around Polymorph and can build an interface with UITheme builder, the paradigm has changed and Spec is the new standard way to create a UI. I read on a post that Polymorph is a UI framework but Spec is a UI description framework. But Spec isn't just a description like a XML representation of a UI - it brings new UI objects to the party - ButtonModel, LabelModel etc. But none of these have the rich properties of the corresponding Morphic objects. A ButtonModel looks nothing like a button, for example, and the LabelModel has nothing to set a font for the label. And it's not a description it's just more code. The only way I can see to create a rich interface using Spec is to create the interface using Morphs (and composite Morphs) and then using Spec mainly just to assemble and position them. So can someone wiser than I answer these questions for me: One, what is the purpose of Spec - what problem is it trying to solve? Two, what advantages are there to building a UI in Spec rather than building it directly in Polymorph? Three, why are the objects caled ButtonModel, LableModel etc when they are not models but UI components? Four, am I supposed to be assembling morphs using Spec? It works so is it right? To sum up, I'm quite sure Spec is an important new feature but at the moment I'm just not getting it. Can anyone help me on this?

April 14, 2013

Re: [Pharo-users] TreeListMorph or MorphTreeMorph

by stephane ducasse

On Apr 14, 2013, at 5:37 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > I must agree :) > > But a new implementation is in the starting block :) I love to hear that because if we get the same speed up than with the list and the new textMorph then it will be really really exciting.

April 14, 2013

Re: [Pharo-users] TreeListMorph or MorphTreeMorph

by Benjamin

no idea, sorry. Ask Alain Plantec :) Ben On Apr 14, 2013, at 2:39 PM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > > > is TMorphTreeModel trait dropped because I see it in the comment but it > is not used by the MorphTreeModel? > > Thanks > > Hilaire > > > Le 14/04/2013 14:26, Benjamin a Ã©crit : >> MorphTreeMorph i would say >> >> Ben >> >> On Apr 14, 2013, at 2:15 PM, Hilaire Fernandes >> <hilaire.fernandes-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org >> <mailto:hilaire.fernandes-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote: >> >>> Hi, >>> >>> We have two players in town. >>> I want to use a tree morph. On some nodes I want different font, on >>> other ones I want custom morph. >>> >>> Which one should I investigate on? >>> >>> Thanks >>> >>> Hilaire >>> >>> >>> -- >>> Dr. Geo http://drgeo.eu >>> >>> >> > > > -- > Dr. Geo http://drgeo.eu > >

April 14, 2013

Re: [Pharo-users] TreeListMorph or MorphTreeMorph

by Benjamin

I must agree :) But a new implementation is in the starting block :) Ben On Apr 14, 2013, at 2:43 PM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > is TMorphTreeModel trait dropped because I see it in the comment but it > is not used by the MorphTreeModel? > > Thanks > > Hilaire > > Le 14/04/2013 14:26, Benjamin a Ã©crit : >> MorphTreeMorph i would say >> >> Ben >> >> On Apr 14, 2013, at 2:15 PM, Hilaire Fernandes >> <hilaire.fernandes(a)gmail.com >> <mailto:hilaire.fernandes@gmail.com>> wrote: >> >>> Hi, >>> >>> We have two players in town. >>> I want to use a tree morph. On some nodes I want different font, on >>> other ones I want custom morph. >>> >>> Which one should I investigate on? >>> >>> Thanks >>> >>> Hilaire >>> >>> >>> -- >>> Dr. Geo http://drgeo.eu >>> >>> >> > > > -- > Dr. Geo http://drgeo.eu > >

April 14, 2013