- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Interrupt a locked pharo image from outside

by Pavel Krivanek

You may use: kill -USR1 <pid> Cheers, -- Pavel 2015-04-21 16:36 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi all, > > anybody knows if it would be possible to generate an external interruption > (a signal) from outside the Pharo process which would trigger a Ctrl+. > interrupt? > > OSProcess 4.5.13 has a tendancy to lock the image on some linux systems > (ubuntu 14.10 at least), and it would be nice to be able to interrupt it to > be able to see where it is blocked. > > "killall pharo" or Ctrl+C does not give much information :( > > Thanks, > > Thierry

April 21, 2015

Re: [Pharo-dev] missing packages in the Pharo50 repository

by Pavel Krivanek

2015-04-21 15:21 GMT+02:00 stepharo <stepharo(a)free.fr>: > @esteban Pavel is not stupid. So we could ask him what are his scenarios. > > @Pavel So pavel can you explain what and why you need? > > And yes we will have to have another level of tooling because > now it can be really difficult I simply wanted to make a local Pharo FileTree repository to have a free hands for testing of system configurations. Something like a personal Pharo fork. The fact that this packages are all missing because they are already handled by configurations is welcomed information. However I think that repositories of this project should be in the list of default repositories. Maybe we should add copy of the configurations to the Pharo50 repository too. Cheers, -- Pavel > > @esteban > we should add the repositories to the projects because we should be able to > publish > in this repositories. Else it will be again the time of the guy fixing a > problem that will be consumed. > > Or we can also simply say to people that we do not care of their time, but I > would prefer that we pay attention. > In that case this is simple for me I will not fix or even look at code that > is not in the > main system and with this approach we will all have lost something. > > > Stef >

April 21, 2015

Interrupt a locked pharo image from outside

by Thierry Goubier

Hi all, anybody knows if it would be possible to generate an external interruption (a signal) from outside the Pharo process which would trigger a Ctrl+. interrupt? OSProcess 4.5.13 has a tendancy to lock the image on some linux systems (ubuntu 14.10 at least), and it would be nice to be able to interrupt it to be able to see where it is blocked. "killall pharo" or Ctrl+C does not give much information :( Thanks, Thierry

April 21, 2015

Re: [Pharo-dev] Fwd: exception handling problem when running tests in Nautilus

by Otto Behrens

Thanks. I do <alt>jc on a method sometimes when I have changed a method. So sometimes I so <alt>jm and then immediately <alt>jc to check all the tests in the class. > Indeed, Nautilus logic to run test differs a bit from the TestRunner logic. Does it really have to be? > For example, if your test fails, it is run a second time to open a debugger but it could do side effects. This has been a problem for me for a long time. I would *love* it if Nautilus runs a single test in debug mode (and not a second time). It is especially painful when running selenium tests in our environment, because firefox is launched on every test suite run, which makes running a single test relatively expensive. I suppose solving the problem of tests running a long time is first prize. > Why don't you just run your tests from the test runner or using MyTestClass run: #testSelector ? Because I normally run the tests that I work on while I'm in the Nautilus browser (using shortcut keys). Why would I want to launch a different browser, search for the class I'm working on and run the tests there? I could be missing it totally here. I'm quite interested to know how other people work. A sort of work flow, to the point of running tests. To run all my tests take a long time. There are quite a few. > We will need to clean this kind of logic that should not be part of Nautilus. Could you open a bug entry for that? https://pharo.fogbugz.com/f/cases/15374/exception-handling-when-running-tes… Is this the right place? > > Regards, > Christophe. > > Le 21 avr. 2015 Ã 15:34, Otto Behrens a Ã©crit : > >> I realised I may have posted this on the wrong list. Is there anyone >> that can help with this one please? >> >> >> ---------- Forwarded message ---------- >> From: Otto Behrens <otto(a)finworks.biz> >> Date: Sun, Apr 19, 2015 at 10:08 AM >> Subject: exception handling problem when running tests in Nautilus >> To: pharo-users(a)lists.pharo.org >> >> >> Hi, >> >> Thanks everyone for the new Pharo and all the work done. I like Spotter! >> >> I gave Pharo 4 a try today and ran into a problem with running tests >> in a TestCase (test class -> run tests). I just get the debugger >> popping up with WARequestContextNotFound. >> >> In the setUp of our test case, we call WACurrentRequestContext value, >> but handle the error when we do not have a context, for example: >> >> [ WACurrentRequestContext value. true ] >> on: WARequestContextNotFound >> do: [ :e | false ] >> >> This handler: "[ :e | false ]" is never called. What influences this >> is the exception handling in: >> >> AbstractNautilusUI >> #runTestsOfClass:notifying: >> >> Firstly, I think that it may be slighly better to call "e pass" or "e >> outer" in stead of "e defaultAction", as this would give another outer >> handler a chance to do something. The defaultAction is called when >> there are no more outer handlers anyway. >> >> After trying this, it did not help my cause. And I think that this is >> because the WACurrentRequestContext is a Notification and not an >> Error. >> >> I then replaced Exception with Error in the handler in >> AbstractNautilusUI. This seem to work. What also works is to >> completely remove the exception handling in AbstractNautilusUI >> >> #runTestsOfClass:notifying: >> >> What is a bit strange is the inconsistency in this exception handling >> when running a suite or an individual test. Perhaps this kind of code >> could be better on the TestSuite and not in the Nautilus UI? >> >> Can anyone please help? Should I be doing something else? >> >> Cheers >> Otto >> >

April 21, 2015

Re: [Pharo-dev] Fwd: exception handling problem when running tests in Nautilus

by Nicolai Hess

2015-04-21 16:03 GMT+02:00 Christophe Demarey <Christophe.Demarey(a)inria.fr>: > Indeed, Nautilus logic to run test differs a bit from the TestRunner logic. > > We will need to clean this kind of logic that should not be part of > Nautilus. > Just for reference: 13024 <https://pharo.fogbugz.com/default.asp?13024> Discrepancy between TestRunner and Nautilus test running for method #shouldNotImplementMethod 14864 <https://pharo.fogbugz.com/default.asp?14864> Nautillus do not launch the test cases on some classes 12851 <https://pharo.fogbugz.com/default.asp?12851> Test is executed twice when failling > > Regards, > Christophe. > > Le 21 avr. 2015 Ã 15:34, Otto Behrens a Ã©crit : > > > I realised I may have posted this on the wrong list. Is there anyone > > that can help with this one please? > > > > > > ---------- Forwarded message ---------- > > From: Otto Behrens <otto(a)finworks.biz> > > Date: Sun, Apr 19, 2015 at 10:08 AM > > Subject: exception handling problem when running tests in Nautilus > > To: pharo-users(a)lists.pharo.org > > > > > > Hi, > > > > Thanks everyone for the new Pharo and all the work done. I like Spotter! > > > > I gave Pharo 4 a try today and ran into a problem with running tests > > in a TestCase (test class -> run tests). I just get the debugger > > popping up with WARequestContextNotFound. > > > > In the setUp of our test case, we call WACurrentRequestContext value, > > but handle the error when we do not have a context, for example: > > > > [ WACurrentRequestContext value. true ] > > on: WARequestContextNotFound > > do: [ :e | false ] > > > > This handler: "[ :e | false ]" is never called. What influences this > > is the exception handling in: > > > > AbstractNautilusUI >> #runTestsOfClass:notifying: > > > > Firstly, I think that it may be slighly better to call "e pass" or "e > > outer" in stead of "e defaultAction", as this would give another outer > > handler a chance to do something. The defaultAction is called when > > there are no more outer handlers anyway. > > > > After trying this, it did not help my cause. And I think that this is > > because the WACurrentRequestContext is a Notification and not an > > Error. > > > > I then replaced Exception with Error in the handler in > > AbstractNautilusUI. This seem to work. What also works is to > > completely remove the exception handling in AbstractNautilusUI >> > > #runTestsOfClass:notifying: > > > > What is a bit strange is the inconsistency in this exception handling > > when running a suite or an individual test. Perhaps this kind of code > > could be better on the TestSuite and not in the Nautilus UI? > > > > Can anyone please help? Should I be doing something else? > > > > Cheers > > Otto > > > >

April 21, 2015

Re: [Pharo-dev] Fwd: exception handling problem when running tests in Nautilus

by Christophe Demarey

Indeed, Nautilus logic to run test differs a bit from the TestRunner logic. For example, if your test fails, it is run a second time to open a debugger but it could do side effects. Why don't you just run your tests from the test runner or using MyTestClass run: #testSelector ? We will need to clean this kind of logic that should not be part of Nautilus. Could you open a bug entry for that? Regards, Christophe. Le 21 avr. 2015 Ã 15:34, Otto Behrens a Ã©crit : > I realised I may have posted this on the wrong list. Is there anyone > that can help with this one please? > > > ---------- Forwarded message ---------- > From: Otto Behrens <otto(a)finworks.biz> > Date: Sun, Apr 19, 2015 at 10:08 AM > Subject: exception handling problem when running tests in Nautilus > To: pharo-users(a)lists.pharo.org > > > Hi, > > Thanks everyone for the new Pharo and all the work done. I like Spotter! > > I gave Pharo 4 a try today and ran into a problem with running tests > in a TestCase (test class -> run tests). I just get the debugger > popping up with WARequestContextNotFound. > > In the setUp of our test case, we call WACurrentRequestContext value, > but handle the error when we do not have a context, for example: > > [ WACurrentRequestContext value. true ] > on: WARequestContextNotFound > do: [ :e | false ] > > This handler: "[ :e | false ]" is never called. What influences this > is the exception handling in: > > AbstractNautilusUI >> #runTestsOfClass:notifying: > > Firstly, I think that it may be slighly better to call "e pass" or "e > outer" in stead of "e defaultAction", as this would give another outer > handler a chance to do something. The defaultAction is called when > there are no more outer handlers anyway. > > After trying this, it did not help my cause. And I think that this is > because the WACurrentRequestContext is a Notification and not an > Error. > > I then replaced Exception with Error in the handler in > AbstractNautilusUI. This seem to work. What also works is to > completely remove the exception handling in AbstractNautilusUI >> > #runTestsOfClass:notifying: > > What is a bit strange is the inconsistency in this exception handling > when running a suite or an individual test. Perhaps this kind of code > could be better on the TestSuite and not in the Nautilus UI? > > Can anyone please help? Should I be doing something else? > > Cheers > Otto >

April 21, 2015

Fwd: exception handling problem when running tests in Nautilus

by Otto Behrens

I realised I may have posted this on the wrong list. Is there anyone that can help with this one please? ---------- Forwarded message ---------- From: Otto Behrens <otto(a)finworks.biz> Date: Sun, Apr 19, 2015 at 10:08 AM Subject: exception handling problem when running tests in Nautilus To: pharo-users(a)lists.pharo.org Hi, Thanks everyone for the new Pharo and all the work done. I like Spotter! I gave Pharo 4 a try today and ran into a problem with running tests in a TestCase (test class -> run tests). I just get the debugger popping up with WARequestContextNotFound. In the setUp of our test case, we call WACurrentRequestContext value, but handle the error when we do not have a context, for example: [ WACurrentRequestContext value. true ] on: WARequestContextNotFound do: [ :e | false ] This handler: "[ :e | false ]" is never called. What influences this is the exception handling in: AbstractNautilusUI >> #runTestsOfClass:notifying: Firstly, I think that it may be slighly better to call "e pass" or "e outer" in stead of "e defaultAction", as this would give another outer handler a chance to do something. The defaultAction is called when there are no more outer handlers anyway. After trying this, it did not help my cause. And I think that this is because the WACurrentRequestContext is a Notification and not an Error. I then replaced Exception with Error in the handler in AbstractNautilusUI. This seem to work. What also works is to completely remove the exception handling in AbstractNautilusUI >> #runTestsOfClass:notifying: What is a bit strange is the inconsistency in this exception handling when running a suite or an individual test. Perhaps this kind of code could be better on the TestSuite and not in the Nautilus UI? Can anyone please help? Should I be doing something else? Cheers Otto

April 21, 2015

Re: [Pharo-dev] WhatsUp from: 2015-04-20 until: 2015-04-30

by stepharo

>> Hi phil >> >> just that you know what we are doing >> >> - Mathieu Lacatou an intern from Thales should be visiting the team for >> 10 days to pair program with esteban >> about the OSWindow multi-windowing support >> >> - JB and Merwan are extending the OSWindow touch support, like >> generating scroll events >> >> - JB is working on Woden and adding some shadders for 3D demoes. > I will have a new guy from Senegal starting to work tomorrow in my lab > on using GPU and Wooden for doing SPH&epidemiological modeling. > How to coordinate all these activities ? Cool :) I do not know For now he should have a look at Woden, JB planned to make a CI. But he was blocked because of a bug in the old version of Metacello that we use. So as soon as Metacello is updated, JB can continue his build. Stef >

April 21, 2015

Re: [Pharo-dev] Roadmap

by stepharo

Le 20/4/15 20:47, Dmitri Zagidulin a Ã©crit : > Sounds great. What is 'leading char'? the fact that a string encodes its language. Stef > > On Mon, Apr 20, 2015 at 1:44 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > >> Similar question - are there any roadmap plans to add Dictionary >> literals to Pharo? > We discussed about object format but right now I think that we > would like to (without thinking too much) > - take advantage of Athens > - continue to improve the tools > - put the bootstrap in production > - make SDL2 working for real and OSwindow > - clean spec > - FFI FFI FFI and again FFI > - continue the remodularisation effort > > If I would open a new work place it would be > - to integrate Xtream and get rid of the old streams. > - clean/remove leading char > > Stef > >> >> On Mon, Apr 20, 2015 at 1:20 PM, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> >> >> Le 20/4/15 16:39, Dmitri Zagidulin a Ã©crit : >>> I would love to see two things in Pharo 5: >>> >>> 1) Fix for mouse scrolling (at least on Mac OS X, though I >>> think it does the same on Linux etc) in the class pane. >>> While mouse-scrolling (either via a mouse wheel or >>> two-finger scrolling on the touchpad) through the classes, >>> the focus frequently and erratically jumps to the package >>> pane, and the package pane starts scrolling instead. The >>> focus also sometimes jumps when you reach the end of the >>> class list (and, again, the package pane starts scrolling >>> instead). >> >> Yes >> >>> >>> 2) A button in the debugger that copies the error message to >>> the clipboard (you can sort of do it currently by editing >>> the title of the error window, but that's really awkward). >> >> it should be easy to do. >> >>> >>> I also have a question. Are there currently any roadmap >>> plans for namespaces or modules for Pharo? I saw a brief >>> discussion about it a few years back >>> (http://forum.world.st/Pharo-and-Namespaces-td4636635.html >>> ), and wanted to see if it's still on the table. >> >> Yes but not for Pharo 50. >> >> Stef >>> >>> >>> >>> On Mon, Apr 20, 2015 at 2:58 AM, stepharo <stepharo(a)free.fr >>> <mailto:stepharo@free.fr>> wrote: >>> >>> Hi >>> >>> if you have suggestions please let us know. Now usually >>> suggestions often comes with time allocation ;) >>> We have definitively a list of points we want to see >>> addressed. >>> >>> Stef >>> >>> Le 19/4/15 23:19, Torsten Bergmann a Ã©crit : >>> >>> Do we have a roadmap for Pharo 5 already? >>> >>> >>> >>> >>> >>> >> >> > >

April 21, 2015

Re: [Pharo-dev] TDD and BDD

by Christophe Demarey

Le 21 avr. 2015 Ã 13:44, Sean P. DeNigris a Ã©crit : > Miguel Moquillon wrote >> BDD and TDD stands for different purposes with different actors... > > While that's unfortunately often true in practice, there is no difference > philosophically. [T|B]DD "done right" always focuses on the user. But > because of the word "test" in TDD, many tests (including many in our image) > became incomprehensible from a "how do I use this library" POV, tested > internal implementation details, etc. So BDD was invented to make the focus > on behaviors explicit and to guide us all toward best practice. It also > quite nicely unified acceptance testing and unit testing. > > The "In order to..." that you're describing is the outer, high-level > acceptance test that in Ruby for example might be written with Cucumber. But > once one has a failing acceptance test, the next step in BDD is to drop down > into e.g. RSpec and write something a lot closer to a unit test, often > mocking out collaborators to drive creation of an API. this one is often called the outside - in loop (ref: http://dannorth.net/whats-in-a-story/) Even is the outside - in loop is not used, I find valuable to encourage people to name (and write) their unit tests in terms of behavior.

April 21, 2015