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

Re: [Pharo-project] testing ui errors in headless mode

by Tudor Girba

Hi, On 31 May 2011, at 22:32, Igor Stasenko wrote: > On 31 May 2011 23:15, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi Igor, >> >> Sorry for the late reply. >> >> >> >> On 26 May 2011, at 17:48, Igor Stasenko wrote: >> >>> On 26 May 2011 17:03, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> Hi, >>>> >>>> I tried several ways to get my head around this problem, but I do not know how to proceed. Can anyone help? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 25 May 2011, at 21:21, Tudor Girba wrote: >>>> >>>>> Hi, >>>>> >>>>> We have some smoke tests in Moose that basically spawn a UI and check for Error. >>>>> >>>>> This used to work when running headless in Pharo 1.2 but now they fail in Pharo 1.3. I believe this has to do with the new changes in the UI Manager, but I do not know what to do. >>>>> >>>>> To reproduce the problem, you can simply call a Pharo-1.3.image in headless mode and file in the attached st file that: >>>>> >>>>> - installs a simple test: >>>>> HeadlessTest>>testStartup >>>>> self shouldnt: [1 inspect] raise: Error >>> >>> Tudor, your test is wrong. >>> During image startup and in headless mode calling inspector will and >>> should raise an error. >>> Because inspecting object requires a presence of UI. >>> But there's no UI in headless mode and prohibited from use during >>> image startup phase, because >>> you cannot start asking questions from user before properly >>> initializing everything related to startup. >>> Startup is called startup on purpose: is should not be interrupted nor >>> require user's interaction. >>> >>> Assume that you don't have Morphic loaded in your image, then what you >>> expect to happen if you do >>> 1 inspect >>> ? >> >> I understand now that the test is wrong. I just wanted to offer an example of spawning a ui, but I think I found the problem like this :). >> >> Now, the thing is that my test tests that triggering the entries from a menu does not result in an error. And inspect or browse happen to be among the menu entries. Is there a way to still have this test working on the server? >> >> Should I put a guard condition in the method triggering the inspector? That sounds bad. Any other ideas? >> > > Yes, you could swallow all ErrorNonInteractive. > So if you will know that something will lead to UI interaction, you > can catch ErrorNonInteractive. > Since there is no UI you won't proceed further, but still will know > that during running the test some UI is involved. > > So, actually a following should pass: > > UIManager default isInteractive ifFalse: [ > self should: [1 inspect] raise: ErrorNonInteractive > ] > > The problem is that there is some missing protocol in > NonInteractiveUIManager (because at the time i was adding it , i > covered all methods, > but then some more stuff were added to morphic ui manager without > parallel extension to other ui managers, > so the test above can fail because you will get DNU error instead of > ErrorNonInteractive ) I tried it: testStartup self shouldnt: [[1 inspect] on: ErrorNonInteractive do: [:x | ]] raise: Error But this still fails. You can try using the attached st file. Cheers, Doru >> Cheers, >> Doru >> > > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

May 31, 2011

Re: [Pharo-project] [Pharo-users] Tiling Window Manager - status update

by laurent laffont

On Tue, May 31, 2011 at 8:25 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > I'll change Meta and stuff to match Ctrl, Cmd and Alt tonight. > > In the current bleeding edge i've splitted shortcut declaration from > settings declaration, so we can put shortcuts without putting them in > settings. And it avoids the error you had yesterday when resetting the > keymaps ;). > Cool ! Don't forget to sleep :) Laurent > > The problem with CTRL has to do with: > > > http://code.google.com/p/pharo/issues/detail?id=3748&q=events&colspec=ID%20… > > That I think is a VM bug :( > Maybe it has to be one of the first things to have a look at 1.4 > > > On Tue, May 31, 2011 at 3:16 PM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > >> Thanks Guillermo. >> >> KeyMapping is really really really important !!! >> >> Actually shortcuts using CTRL don't work and I would like CTRL + xxx >> rather META + xxx for TWM >> >> Laurent. >> >> On Tue, May 31, 2011 at 5:08 PM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> I've freezed the version of keymapping you use in TilingWindowManager >>> with number 1.7: >>> >>> Gofer it >>> squeaksource: 'ShortWays'; >>> package: 'ConfigurationOfKeymapping'; >>> load. >>> >>> (Smalltalk at: #ConfigurationOfKeymapping project version: '1.7') load. >>> >>> Because I'm doing some changes >>> >>> >>> On Mon, May 30, 2011 at 6:22 PM, laurent laffont < >>> laurent.laffont(a)gmail.com> wrote: >>> >>>> First thanks to all people that send patches (and tests !!). Still not >>>> haven't merged all of them - don't hesitate to post in repository so code is >>>> not lost. Yes I will merge layout policies. >>>> >>>> Gofer it >>>> squeaksource: 'TilingWindowManager'; >>>> package: 'TWM'; >>>> load. >>>> (Smalltalk at: #StandardUITheme) beCurrent. >>>> (Smalltalk at: #TWMBar) showTWMBar:true. >>>> >>>> Tested on PharoCore 1.2 and Pharo 1.3. >>>> >>>> Now this has support for world snapshot, that means you can arrange the >>>> windows and take a snapshot of the layout. Then you can restore these >>>> layouts later. (icons camera, <, > and trash). I'm not entirely satisfied >>>> with this, thanks for feedback. >>>> >>>> >>>> In Pharo 1.3 there's initial integration with KeyMapping. To load: >>>> >>>> >>>> Gofer it >>>> squeaksource: 'ShortWays'; >>>> package: 'ConfigurationOfKeymapping'; >>>> load. >>>> >>>> (Smalltalk at: #ConfigurationOfKeymapping project version: >>>> #bleedingEdge) load. >>>> >>>> >>>> Then in settings browser > Keymappings > Tiling Window Managers you have >>>> all actions of the dock mapped. >>>> >>>> Not all shortcuts are working, don't know why, if people can test and >>>> find good shortcuts thank you. >>>> >>>> Creating a nice Metacello Configuration for TWM will be appreciated :) >>>> >>>> >>>> Cheers, >>>> >>>> Laurent Laffont - @lolgzs <http://twitter.com/#%21/lolgzs> >>>> >>>> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ >>>> Blog: http://magaloma.blogspot.com/ >>>> Developer group: http://cara74.seasidehosting.st >>>> >>>> >>> >> >

May 31, 2011

Re: [Pharo-project] A radical proposal (to cut down dead code)

by laurent laffont

On Tue, May 31, 2011 at 9:12 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 31 May 2011 21:44, laurent laffont <laurent.laffont(a)gmail.com> wrote: > > Another idea (don't know how hard it is) is to have test coverage + > comment > > coverage in Hudson. > > Then we can start to consider that dead code = code with no test or no > > comment. > > Laurent, have you tried to run lint rule checker in pharo image? > No - I talk about test coverage, not lint. I don't think lint worth running on a full image. Test coverage is really useful. Indeed, I use test coverage on my projects every day. Lint once a year :) Laurent. > I tried once and if i remember correctly, there are like 30000 notices. > Now, what you think, is it possible for any human to visit all of them > step by step > analyze and then fix the code? It is enormous amount of data (and most > of it is just white noise, > or insignificant detail). Now how to filter that noise and address the > only things which you should take care of? > And since we're continuting development, every time you doing an > update, this stuff should be revisited, > compared and cross-checked again. And we don't have such facility: > take image A and B, and compare their lint output. > I imagine this would require a quite sophisticated database , with UI > on top of that, which will allow you to navigate > through these notices mark them as invalid, or fixed etc etc.. > What i mean that automated tools is cool. But they cannot solve all > our problems: every such issue should be analyzed and considered by > developer. > Because we're still not yet at the point, where system can reason > about itself and automatically improve itself without need of our > attention :) > If this day will come, then it will be the end of humanity (at least > in its current form - homo sapiens sapiens ;) > > > Laurent. > > > -- > Best regards, > Igor Stasenko AKA sig. > >

May 31, 2011

[Pharo-project] TilingWM - layout policies

by laurent laffont

Thanks to Stefan, Serge, Patrick and Estelle now you can choose a Layout Strategy in settings. Actually there's Horizontal (default) and Vertical (last used windows fills all remaining space) strategies. To add your own just subclass TWMLayoutStrategy and implement #tileWindows: Cheers, Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

May 31, 2011

Re: [Pharo-project] Metacello as the system evolves... (Fwd from Seaside-General: Which image for deployment?)

by StÃ©phane Ducasse

It also means that we should find somebody that do not piss on metacello and maintain a version for Seaside. Because we cannot manage complex system with a package management system and there is a cost in that but benefit too. Sad but true. Stef On May 31, 2011, at 9:55 PM, Sean P. DeNigris wrote: > The following is a conversation about not being able to load Seaside into > Pharo 1.2 via Metacello (from the Seaside-general list). Shouldn't symbolic > versions in Metacello have solved this problem? There should be different > package versions tagged stable for each system (1.2.x, 1.3...) as necessary, > no? It seems there's not much difference between: > Pharo 1.2 vs. Pharo 1.3 > and > Pharo 1.2 vs. Squeak 4.2 > > Doesn't symbolic versions finally allow us to have *one* configuration per > project that will load into any Squeak/Pharo/etc? As a Metacello user, it > would be comforting to know that there is only one configuration, or needing > to find the /right/ one replaces one problem (dependencies) with another. > > > >>> * loading Seaside via Metacello into Pharo (although I got an error in >>> Pharo >>> 1.2.2-12353) >> >> That is a known problem (see >> http://lists.squeakfoundation.org/pipermail/seaside-dev/2011-May/004786.html >> and http://www.iam.unibe.ch/pipermail/moose-dev/2011-May/008309.html) >> Some configurations that the Seaside Metacello Configuration depens on >> have been updated to Pharo 1.3 breaking all users of older versions of >> Pharo. >> >> I was told that the (Pharo?) Metacello configurations do not support >> loading into older images. So people that want to use a stable version >> of Pharo (< 1.3) cannot load Seaside with Metacello anymore. There are >> various solutions: >> >> - Move to (unstable) Pharo 1.3, use a maybe broken Seaside, and load >> the code easily with Metacello (this is what Pharo wants us to do) >> - Fix the configurations of Pharo or write our own configurations (no >> clue how that could be done) >> - Stay with (stable) Pharo and use Gofer scripts (this is what I do, >> works pretty reliable and painless) >> >> In either case you should complain in the Pharo list, there is >> something broken in the process. Personally, I am fedup with these >> forced updates and will stick with Pharo 1.2 until there is a really >> compelling reason to move forward. >> > > -- > View this message in context: http://forum.world.st/Metacello-as-the-system-evolves-Fwd-from-Seaside-Gene… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 31, 2011

Re: [Pharo-project] Metacello as the system evolves... (Fwd from Seaside-General: Which image for deployment?)

by StÃ©phane Ducasse

sean can you quote the name of the person who wrote the mail? Stef On May 31, 2011, at 9:55 PM, Sean P. DeNigris wrote: > The following is a conversation about not being able to load Seaside into > Pharo 1.2 via Metacello (from the Seaside-general list). Shouldn't symbolic > versions in Metacello have solved this problem? There should be different > package versions tagged stable for each system (1.2.x, 1.3...) as necessary, > no? It seems there's not much difference between: > Pharo 1.2 vs. Pharo 1.3 > and > Pharo 1.2 vs. Squeak 4.2 > > Doesn't symbolic versions finally allow us to have *one* configuration per > project that will load into any Squeak/Pharo/etc? As a Metacello user, it > would be comforting to know that there is only one configuration, or needing > to find the /right/ one replaces one problem (dependencies) with another. > > > >>> * loading Seaside via Metacello into Pharo (although I got an error in >>> Pharo >>> 1.2.2-12353) >> >> That is a known problem (see >> http://lists.squeakfoundation.org/pipermail/seaside-dev/2011-May/004786.html >> and http://www.iam.unibe.ch/pipermail/moose-dev/2011-May/008309.html) >> Some configurations that the Seaside Metacello Configuration depens on >> have been updated to Pharo 1.3 breaking all users of older versions of >> Pharo. >> >> I was told that the (Pharo?) Metacello configurations do not support >> loading into older images. So people that want to use a stable version >> of Pharo (< 1.3) cannot load Seaside with Metacello anymore. There are >> various solutions: >> >> - Move to (unstable) Pharo 1.3, use a maybe broken Seaside, and load >> the code easily with Metacello (this is what Pharo wants us to do) >> - Fix the configurations of Pharo or write our own configurations (no >> clue how that could be done) >> - Stay with (stable) Pharo and use Gofer scripts (this is what I do, >> works pretty reliable and painless) >> >> In either case you should complain in the Pharo list, there is >> something broken in the process. Personally, I am fedup with these >> forced updates and will stick with Pharo 1.2 until there is a really >> compelling reason to move forward. >> > > -- > View this message in context: http://forum.world.st/Metacello-as-the-system-evolves-Fwd-from-Seaside-Gene… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 31, 2011

Re: [Pharo-project] [squeak-dev] Fwd: usability of Pharo and Squeak

by Janko MivÅ¡ek

On 31. 05. 2011 18:35, Ramon Leon wrote: > Tabs would make it more like practically every other program available > that needs multiple edit windows. Tabs are better than multiple > windows. Look around, tabs won; the battle is over. Tabbed browsing of > the net or 15 instances of Firefox open? Seriously, you think multiple > windows are better? Really? Agreed, tabs won, therefore we need to implement it and this will be a big step forward for usability of our tools. Not only for newcomers, for us too. You will see sooner or later that tabbed windows are better than full ones. I had such experience from VW and other VisualWorkers would probably confirm that. Ok, a right combo of both, tabbed and full. Say two browsers windows with a reasonable amount of methods open in tabs. And adding back button .. well that would be near nirvana considering current state :) Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

May 31, 2011

Re: [Pharo-project] [Pharo-users] [PBE-Spanish] Status udpate 2011-05-31

by StÃ©phane Ducasse

Thanks thanks thanks nicolas!!! Keep pushing. Stef > Hello everyone, > > I am coordinating the group working on the Spanish translation of Pharo By Example. Our goal is to have a first rough draft of the whole book by end of June. > > I am glad to announce that the draft of the first 3 translated chapter is now available. You can find under the new section it in http://pharobyexample.org/ or with this direct link: https://gforge.inria.fr/frs/download.php/28586/PBE1-Spanish-Draft-2011-05-2… > > The current status of the translation is: > > Chapter 01: 20% > > Chapter 02: 60% > > Chapter 03: 100%, already publish > > Chapter 04: 100%, already publish > > Chapter 05: 50% > > Chapter 06: 7% > > Chapter 07: 46% > > Chapter 08: 0% > > Chapter 09: 100%, not published yet > > Chapter 11: 100%, already published > > Chapter 12: 19% > > Chapter 13: 0% > > Chapter 14: 100%, not published yet > > > > From now onwards I will send regular status updates. > If somebody is interested in collaborating (translating or reviewing), just let me know. > > Regards, > > NicoPaez. > blog: nicopaez.wordpress.com

May 31, 2011

Re: [Pharo-project] testing ui errors in headless mode

by Igor Stasenko

On 31 May 2011 23:15, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Igor, > > Sorry for the late reply. > > > > On 26 May 2011, at 17:48, Igor Stasenko wrote: > >> On 26 May 2011 17:03, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> Hi, >>> >>> I tried several ways to get my head around this problem, but I do not know how to proceed. Can anyone help? >>> >>> Cheers, >>> Doru >>> >>> >>> On 25 May 2011, at 21:21, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> We have some smoke tests in Moose that basically spawn a UI and check for Error. >>>> >>>> This used to work when running headless in Pharo 1.2 but now they fail in Pharo 1.3. I believe this has to do with the new changes in the UI Manager, but I do not know what to do. >>>> >>>> To reproduce the problem, you can simply call a Pharo-1.3.image in headless mode and file in the attached st file that: >>>> >>>> - installs a simple test: >>>> HeadlessTest>>testStartup >>>> Â Â Â self shouldnt: Â [1 inspect] raise: Â Error >> >> Tudor, your test is wrong. >> During image startup and in headless mode calling inspector will and >> should raise an error. >> Because inspecting object requires a presence of UI. >> But there's no UI in headless mode and prohibited from use during >> image startup phase, because >> you cannot start asking questions from user before properly >> initializing everything related to startup. >> Startup is called startup on purpose: is should not be interrupted nor >> require user's interaction. >> >> Assume that you don't have Morphic loaded in your image, then what you >> expect to happen if you do >> 1 inspect >> ? > > I understand now that the test is wrong. I just wanted to offer an example of spawning a ui, but I think I found the problem like this :). > > Now, the thing is that my test tests that triggering the entries from a menu does not result in an error. And inspect or browse happen to be among the menu entries. Is there a way to still have this test working on the server? > > Should I put a guard condition in the method triggering the inspector? That sounds bad. Any other ideas? > Yes, you could swallow all ErrorNonInteractive. So if you will know that something will lead to UI interaction, you can catch ErrorNonInteractive. Since there is no UI you won't proceed further, but still will know that during running the test some UI is involved. So, actually a following should pass: UIManager default isInteractive ifFalse: [ self should: [1 inspect] raise: ErrorNonInteractive ] The problem is that there is some missing protocol in NonInteractiveUIManager (because at the time i was adding it , i covered all methods, but then some more stuff were added to morphic ui manager without parallel extension to other ui managers, so the test above can fail because you will get DNU error instead of ErrorNonInteractive ). > Cheers, > Doru > -- Best regards, Igor Stasenko AKA sig.

May 31, 2011

Re: [Pharo-project] loading code from command line inovcation

by StÃ©phane Ducasse

>> > > Another detail is, that users on the commandline expect errors to go to stderr and not to some 'hidden' log file. > > Would it be possible to have that recognized on startup and have errors redirected to stderr instead of a log file? if you send code you increase the chances to get what can help you. > > Thanks > Stefan

May 31, 2011