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

Re: [Pharo-dev] 2 seconds default time limit for tests

by Esteban Lorenzano

> On 16 Feb 2017, at 13:49, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > I vote for not introducing during code-freeze. +1: not in code freeze. > > We can discuss it for Pharo 7, I'm not against actually. But I have some concerns: > > - How does it work when we are debugging? > I mean, imagine I'm running a test, a debugger is open, and I start working on it. How do these timeout currently work in this scenario? I imagine that the test runner should detect you entered into a "I'm debugging" mode and should not kill your test, but this is not clear to me how this works right now. > > - Also, how can we better document these things? Because I was bitten a couple of times by this timeouts and the "I kill your process but I do not tell you", and it was not nice because it was completely silent or obscure. > > Guille > > On Thu, Feb 16, 2017 at 1:33 PM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > Hi. > > In Pharo 6 we introduced time limit for tests. Currently it is set to 1 minute by default. And concrete test cases or single tests can redefine it with suitable value. There is also setting to change default limit globally which should help to not adopt external projects immediately if current limit is bad for them. > > There is issue 19105 <https://pharo.fogbugz.com/f/cases/19105/Default-time-limit-for-tests-should…> to make limit really small. It will set default limit for 2 seconds. Slow tests are already marked with bigger value. So it is safe for integration > > Here I ask for your agreement with this change. Or disagreement if there are good reasons to not do this. > > I hope following story will convince you that default time limit should be small: > > I worked on tests for new project and I got hanging tests. These tests were waiting for some event which not happens because of bugs. They will be failed after 1 minutes due to timeout. > > But when you work on code you of course do not want to wait 1 minute. So it always forces manual interrupt of running tests. But then you could not run full test suite to see all problem tests. And also it is not really easy to detect current running test after interrupt. You need analyze stack in debugger and if you just close debugger information is lost. > > So to fix it I change default timeout in each of my test cases. > If you will work on similar code you will need same approach to comfortably detect and fix "synchronization" bugs. > > So this was my story. I am sure default behaviour with small time limit will make SUnit much better. > Common case is that unit tests are supposed to be fast. Users expect it by default. And if something is going wrong fast tests should fail fast. > When user wrote slow test it is expected to know that test is slow. And for such rare cases user can mark slow tests explicitly. But SUnit should not expect tests to be slow by default. > > I think it is really good improvement for Pharo 6. It makes TDD in Pharo better. > > Best regards, > Denis >

Feb. 16, 2017

blog post about Calypso navigation model

by Denis Kudriashov

Hello. I wrote blog post about Calypso navigation model http://dionisiydk.blogspot.fr/2017/02/calypso-navigation-model.html. Questions and feedback are welcome. Best regards, Denis

Feb. 16, 2017

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Association: Join or Renew now!

by denker

> On 16 Feb 2017, at 10:43, denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > Yes, we are planning to extend the profiles to have space for > -> website I have added a field for the website. Marcus

Feb. 16, 2017

Re: [Pharo-dev] 2 seconds default time limit for tests

by Guillermo Polito

I vote for not introducing during code-freeze. We can discuss it for Pharo 7, I'm not against actually. But I have some concerns: - How does it work when we are debugging? I mean, imagine I'm running a test, a debugger is open, and I start working on it. How do these timeout currently work in this scenario? I imagine that the test runner should detect you entered into a "I'm debugging" mode and should not kill your test, but this is not clear to me how this works right now. - Also, how can we better document these things? Because I was bitten a couple of times by this timeouts and the "I kill your process but I do not tell you", and it was not nice because it was completely silent or obscure. Guille On Thu, Feb 16, 2017 at 1:33 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > In Pharo 6 we introduced time limit for tests. Currently it is set to 1 > minute by default. And concrete test cases or single tests can redefine it > with suitable value. There is also setting to change default limit globally > which should help to not adopt external projects immediately if current > limit is bad for them. > > There is issue 19105 > <https://pharo.fogbugz.com/f/cases/19105/Default-time-limit-for-tests-should…> to > make limit really small. It will set default limit for 2 seconds. Slow > tests are already marked with bigger value. So it is safe for integration > > Here I ask for your agreement with this change. Or disagreement if there > are good reasons to not do this. > > I hope following story will convince you that default time limit should be > small: > > I worked on tests for new project and I got hanging tests. These tests > were waiting for some event which not happens because of bugs. They will be > failed after 1 minutes due to timeout. > > But when you work on code you of course do not want to wait 1 minute. So > it always forces manual interrupt of running tests. But then you could not > run full test suite to see all problem tests. And also it is not really > easy to detect current running test after interrupt. You need analyze stack > in debugger and if you just close debugger information is lost. > > So to fix it I change default timeout in each of my test cases. > If you will work on similar code you will need same approach to > comfortably detect and fix "synchronization" bugs. > > So this was my story. I am sure default behaviour with small time limit > will make SUnit much better. > Common case is that unit tests are supposed to be fast. Users expect it by > default. And if something is going wrong fast tests should fail fast. > When user wrote slow test it is expected to know that test is slow. And > for such rare cases user can mark slow tests explicitly. But SUnit should > not expect tests to be slow by default. > > I think it is really good improvement for Pharo 6. It makes TDD in Pharo > better. > > Best regards, > Denis >

Feb. 16, 2017

2 seconds default time limit for tests

by Denis Kudriashov

Hi. In Pharo 6 we introduced time limit for tests. Currently it is set to 1 minute by default. And concrete test cases or single tests can redefine it with suitable value. There is also setting to change default limit globally which should help to not adopt external projects immediately if current limit is bad for them. There is issue 19105 <https://pharo.fogbugz.com/f/cases/19105/Default-time-limit-for-tests-should…> to make limit really small. It will set default limit for 2 seconds. Slow tests are already marked with bigger value. So it is safe for integration Here I ask for your agreement with this change. Or disagreement if there are good reasons to not do this. I hope following story will convince you that default time limit should be small: I worked on tests for new project and I got hanging tests. These tests were waiting for some event which not happens because of bugs. They will be failed after 1 minutes due to timeout. But when you work on code you of course do not want to wait 1 minute. So it always forces manual interrupt of running tests. But then you could not run full test suite to see all problem tests. And also it is not really easy to detect current running test after interrupt. You need analyze stack in debugger and if you just close debugger information is lost. So to fix it I change default timeout in each of my test cases. If you will work on similar code you will need same approach to comfortably detect and fix "synchronization" bugs. So this was my story. I am sure default behaviour with small time limit will make SUnit much better. Common case is that unit tests are supposed to be fast. Users expect it by default. And if something is going wrong fast tests should fail fast. When user wrote slow test it is expected to know that test is slow. And for such rare cases user can mark slow tests explicitly. But SUnit should not expect tests to be slow by default. I think it is really good improvement for Pharo 6. It makes TDD in Pharo better. Best regards, Denis

Feb. 16, 2017

Re: [Pharo-dev] Code Completion in Pharo

by Guillermo Polito

Hi Lukas, This is cool and an interesting topic. Something that I would like is to see wether we can merge the auto-completion with the AST-based suggestion mechanism (right click on a piece of code -> suggestions), that provides suggestions for refactorings and code browsing. I mean, you can see auto-completion as a particular suggestion to add a word where the current cursor is placed. A somehow related question is to apply type inference mechanisms to enhance the suggested completions. You can check the work done lately on type inferencers for Pharo in here: http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_An%20extensible%20constr… Guille On Tue, Feb 14, 2017 at 6:57 PM, <komarlu2(a)fit.cvut.cz> wrote: > Hello to all, > > I am a student at the Faculty of Information Technology of the Czech > Technical University in Prague and I decided to make Code Completion in > Pharo the topic of my Bachelor's degree and try to improve it. > > If you have suggestions on what should change / how to change it so you > would be satisfied with it, I will appreciate any input on this topic. It > would mean a lot to me if you could find two minutes and take this survey > (there are only like 7 questions, so it won't take longer than those 2 > minutes): > > https://docs.google.com/forms/d/e/1FAIpQLSd7lx6gIN079-vMvMwRsnA_AX_e_ > 7sZEz2XJQ4059nk_-LV6w/viewform > > Regards > > > Lukas >

Feb. 16, 2017

Re: [Pharo-dev] [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

by Cyril Ferlicot D.

On 16/02/2017 11:06, Peter Uhnak wrote: > Hi, > > recently (couple of days ago) sometimes when I start Pharo there's a box at the bottom "Debug console" with the following info > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > # Debug console > # To close: F2 -> 'debug options' -> 'show output console' > # To disable: F2 -> 'debug options' -> 'show console on errors' > LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. > > ) > LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. > > ) > LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. > > ) > LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. > > ) > LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. > > ) > LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. > > ) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > I have Windows 10 & VM Version: Cog Spur VM 5.0 (release) from Feb 3 2017 (downloaded from files.pharo.org) > > This error results in Athens (and Roassal) not working, although Pharo itself seems fine. > > Reopening the image has no effect, and the only resolution is to do a system reboot. > > > There is also crash.dmp from Feb 12 (possibly the day it started) containing > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Sun Feb 12 23:10:24 2017 > > Exception code: C0000005 > Exception addr: 0040BDD0 > Access violation (write access) at 00AFF43C > EAX:FFFFFFFF EBX:74329850 ECX:549D7EBE EDX:00AFF43C > ESI:74315F70 EDI:00489DB9 EBP:0887FF94 ESP:0887FF54 > EIP:0040BDD0 EFL:00010206 > FP Control: 0000027F > FP Status: 00000000 > FP Tag: 0000FFFF > > > Crashed in some other thread > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Makes me wonder whether the SurfacePlugin.dll didn't somehow get corrupted... but then again there's no modification date change on the dll file, nor would it explain why rebooting fixes it. > > Thanks, > Peter > Hi, I got the same problem with the latest vm some weeks ago on Windows 7. It vanished by downloading a new vm some days after. I did not try with the current latest. I'll maybe have the time to try this week end. -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Feb. 16, 2017

[pharo-project/pharo-core] 03cd61: 60396

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 03cd61e0aae1f586d4890c320a7bd01e00fc78dc https://github.com/pharo-project/pharo-core/commit/03cd61e0aae1f586d4890c32… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-16 (Thu, 16 Feb 2017) Changed paths: M Kernel-Tests.package/ClassHierarchyTest.class/instance/tests/testObjectFormatInstSize.st M Metacello-ToolBox.package/MetacelloToolBox.class/instance/api-configuration/updateVersionMethodForVersion_projectAttributes_updateProjects_updatePackages_versionSpecsDo_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60395.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60396.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60395.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60396.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60396 19716 The method Pragma>>#selector called from MetacelloToolBox https://pharo.fogbugz.com/f/cases/19716 19713 improve #testObjectFormatInstSize https://pharo.fogbugz.com/f/cases/19713 http://files.pharo.org/image/60/60396.zip

Feb. 16, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60396 Home: https://github.com/pharo-project/pharo-core

Feb. 16, 2017

[VM] Windows VM SurfacePlugin.dll LoadLibrary failure

by Peter Uhnak

Hi, recently (couple of days ago) sometimes when I start Pharo there's a box at the bottom "Debug console" with the following info ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Debug console # To close: F2 -> 'debug options' -> 'show output console' # To disable: F2 -> 'debug options' -> 'show console on errors' LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin) (998: Invalid access to memory location. ) LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location. ) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I have Windows 10 & VM Version: Cog Spur VM 5.0 (release) from Feb 3 2017 (downloaded from files.pharo.org) This error results in Athens (and Roassal) not working, although Pharo itself seems fine. Reopening the image has no effect, and the only resolution is to do a system reboot. There is also crash.dmp from Feb 12 (possibly the day it started) containing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sun Feb 12 23:10:24 2017 Exception code: C0000005 Exception addr: 0040BDD0 Access violation (write access) at 00AFF43C EAX:FFFFFFFF EBX:74329850 ECX:549D7EBE EDX:00AFF43C ESI:74315F70 EDI:00489DB9 EBP:0887FF94 ESP:0887FF54 EIP:0040BDD0 EFL:00010206 FP Control: 0000027F FP Status: 00000000 FP Tag: 0000FFFF Crashed in some other thread ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Makes me wonder whether the SurfacePlugin.dll didn't somehow get corrupted... but then again there's no modification date change on the dll file, nor would it explain why rebooting fixes it. Thanks, Peter

Feb. 16, 2017