September 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Message browser strange new behavior

by Denis Kudriashov

I can't reproduce (or I not see it) Could you explain more? 2016-09-03 22:11 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi > > > Often I look at senders and I modify them directly in the message browser > and I do not one by one. > > Now when I recompile a method I get a new one and I lose the next one. > > Am I the only one to have this behavior. It is highly disrputing. > > Stef > > >

Sept. 4, 2016

[pharo-project/pharo-core]

by GitHub

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

Sept. 4, 2016

[pharo-project/pharo-core] e64121: 60202

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: e641210bd1705920c482de8b77d611cd3460434a https://github.com/pharo-project/pharo-core/commit/e641210bd1705920c482de8b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-04 (Sun, 04 Sep 2016) Changed paths: M Athens-Examples.package/AthensSurfaceExamples.class/class/examples/exampleDrawForm2.st M Athens-Examples.package/AthensSurfaceExamples.class/definition.st M FreeType.package/FreeTypeSystemSettings.class/class/settings/freeTypeSettingsOn_.st M FreeType.package/FreeTypeSystemSettings.class/definition.st M HelpSystem-Core.package/ClassAPIHelpBuilder.class/instance/building/build.st M HelpSystem-Core.package/CustomHelp.class/class/accessing/icon.st M HelpSystem-Core.package/CustomHelp.class/definition.st M HelpSystem-Core.package/HelpBrowser.class/class/icons/taskbarIcon.st M HelpSystem-Core.package/HelpBrowser.class/class/ui/menuOn_.st M HelpSystem-Core.package/HelpBrowser.class/class/world menu/menuCommandOn_.st M HelpSystem-Core.package/HelpBrowser.class/definition.st M HelpSystem-Core.package/HelpBuilder.class/definition.st M Komitter.package/KomitClassNode.class/class/icons/addedClassIcon.st M Komitter.package/KomitClassNode.class/class/icons/defaultClassIcon.st M Komitter.package/KomitClassNode.class/class/icons/deletedClassIcon.st M Komitter.package/KomitClassNode.class/class/icons/modifiedClassIcon.st M Komitter.package/KomitterUI.class/class/icons/historyIcon.st M Nautilus.package/AbstractNautilusUI.class/instance/icon/packageIconFor_.st M Nautilus.package/CategoryWidget.class/class/menus/categoriesMenu_.st M Nautilus.package/MethodOveridesAction.class/instance/order/privateActionIcon.st M Nautilus.package/MethodOveridesAction.class/instance/private/buildUpAndDownArrowIcon_.st M Nautilus.package/MethodWidget.class/class/menu/elementsMenu_.st A NautilusRefactoring.package/extension/ClassDescription/instance/iconNamed_.st M NautilusRefactoring.package/extension/ClassDescription/instance/instVarRefactoring_.st M NautilusRefactoring.package/extension/ClassDescription/instance/refactoringSubmenu_.st M NautilusRefactoring.package/extension/ClassDescription/instance/varRefactoringSubMenu_.st M Refactoring-Help.package/RBClassesHelp.class/class/building/buildClassHierarchyHelpFrom_.st M Refactoring-Help.package/RBClassesHelp.class/definition.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60201.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60202.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60201.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60202.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Settings-Graphics.package/GraphicFontSettings.class/class/fonts/resetAllFontToDefaultButton.st M Settings-Graphics.package/GraphicFontSettings.class/definition.st M Spec-Debugger.package/SpecDebugger.class/class/icons/taskbarIcon.st M Spec-Inspector.package/EyeAbstractInspector.class/class/accessing/taskbarIcon.st M Spec-Tools.package/DualChangeSorterApplication.class/class/icons/taskbarIcon.st M Spec-Tools.package/KeymapBrowser.class/class/accessing/taskbarIcon.st M Tool-Catalog.package/CatalogBrowser.class/class/utilities/iconFor_.st M Tool-Catalog.package/CatalogBrowser.class/class/world menu/menuCommandOn_.st M Tool-Catalog.package/CatalogBrowser.class/definition.st M Tool-Catalog.package/CatalogBrowser.class/instance/Nautilus groups support/installAndCreateGroupButton_.st M Tool-Catalog.package/CatalogBrowser.class/instance/building/refreshButton_.st M Tool-Catalog.package/CatalogBrowser.class/instance/menu/defineAllRepositoriesInMCBrowserButton_.st M Tool-Catalog.package/CatalogBrowser.class/instance/menu/defineCurrentVersionRepositoryButton_.st M Tool-Catalog.package/CatalogBrowser.class/instance/menu/installStableVersionButton_.st M Tool-Catalog.package/CatalogBrowser.class/instance/menu/installStableVersionMenuItem_.st M Tool-Catalog.package/CatalogBrowser.class/instance/menu/loadConfigurationButton_.st M Tool-Catalog.package/CatalogBrowser.class/instance/menu/loadConfigurationMenuItem_.st M Tool-Catalog.package/CatalogBrowser.class/instance/private - utilities/buildContextMenuOn_.st M Tool-Catalog.package/CatalogBrowser.class/instance/private - utilities/buildMenuOn_.st M Tool-CriticBrowser.package/CriticBrowser.class/class/menu/icon.st M Tool-DependencyAnalyser-UI.package/DAPackageDependenciesWelcome.class/class/world menu/menuCommandOn_.st M Tool-FileList.package/FileList.class/class/icons/taskbarIcon.st R Tool-FileList.package/FileList.class/class/menu/iconNamed_.st M Tool-Finder.package/FinderUI.class/class/icons/icon.st Log Message: ----------- 60202 19001 Another pass to introduce iconNamed: and avoid Smalltalk ui icons https://pharo.fogbugz.com/f/cases/19001 19002 iconNamed: in Catalog Browser https://pharo.fogbugz.com/f/cases/19002 http://files.pharo.org/image/60/60202.zip

Sept. 4, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by stepharo

And it is worth breaking all the book chapters and videos. I think that assert: closeTo: kind of solution is - simple - regular with the other assert: - incremental So maximum quality. Stef

Sept. 4, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by stepharo

> > 2016-09-03 9:22 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Denis > > can we also have > > assert: aNumber withPrecision: precision equals: otherNumber > > self > assert: (aNumber round: precision) > equals: otherNumber > > assert: aNumber closeTo: otherNumber > > assert: aNumber withPrecision: self defaultPrecision equals: otherNumber > > defaultPrecision > ^ 2 > > > We could add it but as different issue. > > Also I really want move away from assertions to should expressions. It > is much nicer to write things like this (which available in StateSpecs): > > 10.1234 should equal: 10.12 within: 0.01 "success" > 10.1234 should equal: 10.12 within: 0.001 "failure" > > Also I has idea that float assertions should always use default > precision (like 0.00000000001) without special message. > > (80.85 * 100) should equal: 8085 > > It will fail now but I want it always succeed in such cases. Because > in most cases users don't care about this. And when it has real value > users will specify concrete precision Just one step at a time please. Let us make SUnit with some simple extension.

Sept. 4, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by stepharo

Nicolas I like your ideas can you propose (code) something? Stef Le 3/9/16 Ã 09:48, Nicolas Cellier a Ã©crit : > For floating points it would be good to also have something related to > unit of least precision like I think it exists in google tests: > > assert: aFloat isWithin: anInteger ulpFrom: anotherFloat > ^(aFloat - anotherFloat) abs <= (anotherFloat ulp max: aFloat ulp) > > It's testing if the result are the same with a tolerance on least > significant bits. > (anotherFloat ulp max: aFloat ulp) is not really necessary, it's only > for making the comparison symmetric. > indeed, 2 and 2 predecessor do not have the same exponent, so do not > have the same ulp. > If we don't have symmetry, then > self assert: 2.0 predecessor predecessor isWithin: 1 ulpFrom: 2.0. > might differ from: > self assert: 2.0 isWithin: 1 ulpFrom: 2.0 predecessor predecessor . > > Note that the this message cannot be used to test for zero result > (because 0.0 ulp is the smallest denormal). > For example: > self assert: 2.0 - 2.0 predecessor isWithin: 4 ulpFrom: 0.0. > would anwer false, but it makes no sense! > One should write > self assert: 2.0 isWithin: 4 ulpFrom: 2.0 predecessor. > > 2016-09-03 9:22 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Denis > > can we also have > > assert: aNumber withPrecision: precision equals: otherNumber > > self > assert: (aNumber round: precision) > equals: otherNumber > > assert: aNumber closeTo: otherNumber > > assert: aNumber withPrecision: self defaultPrecision equals: otherNumber > > defaultPrecision > ^ 2 > > > > Le 31/8/16 Ã 14:10, Denis Kudriashov a Ã©crit : >> Hi. >> >> I am working on SUnit improvements. I open issue 19015 >> <https://pharo.fogbugz.com/f/cases/19015/Tests-should-never-hang-and-leave-f…>. >> Slice is inbox which waits your review and feedback. >> I was trying to address three problems: >> >> *1) Tests should never hang. They should be always executed >> within time limit.* >> I give them 10 minutes for now to not change existing behaviour >> of tests. At next step it should be really reduced to ~100 >> milliseconds (?). >> Any TestCase could redefine time limit by method #defaultTimeLimit. >> Or it could be specified directly in test code by >> self timeLimit: 10 seconds >> (could be changed at any time of test execution). > > would be good >> >> To implement this logic special watch dog process is running for >> given test suite to control execution time of tests. It is single >> process for full test suite. >> >> *2) When test completes all forked processes should be terminated.*** >> >> If your tested code produced zombie processes SUnit will take >> care about destroying all such garbage. >> (it not means that you don't need to clean table in #tearDown but >> any code could be broken and running tests should not produce >> dirty system). > Yes!!! > >> *3) Any failures inside forked processes should not spawn >> debugger while running tests.* >> Only when we debug tests we need debugger on forked failed processes. >> During normal run SUnit should prevent such "background >> debuggers" and mark such tests as failed. >> > Definitevely. Now when we execute tests from the testRunner and > nautilus we should get the debugger, right? > > >> To implement this behaviour SUnit will handle errors from forked >> processes by suspending them and collecting them in special >> collection. >> I introduce TestFailedByForkedProcess error to signal these kind >> of problems at the end of tests. This error is resumable and >> resume will opens debuggers of suspended failures (in fact it >> will resume suspended processes). >> So to debug background failures you will need extra Proceed >> action on debugger when TestFailedByForkedProcess is signalled. >> But in normal run such tests will be just failed by >> TestFailedByForkedProcess error. > We should really write a little doc so that I can add it to the > Sunit Chapter. > > > >> >> *Now details on how it is done:* >> >> I introduce special process specific variable >> CurrentExecutionEnvironment. It is not installed by default and >> as default value it returns DefaultExecutionEnvironment instance. >> This variable is inheritable. If your install concrete >> environment into process it will be installed to any child process. >> >> So value of variable is instance of ExecutionEnvironment >> subclasses and you can install it by: >> >> anYourExecutionEnvironment beActiveDuring: aBlock >> >> >> When block completes previous environment is restored. >> For default environment there is class side method: >> >> DefaultExecutionEnvironment beActiveDuring: aBlock >> >> >> And to reset current environment to default: >> >> DefaultExecutionEnvironment beActive. >> >> >> SUnit introduces TestExecutionEnvironment which implements all >> described behaviour for time limits and forked processes. >> To activate environment there is new method #runCaseManaged. And >> submitted slice uses it instead of simple runCase. >> >> TestCase>>runCaseManaged >> CurrentExecutionEnvironment runTestCase: self >> >> >> DefaultExecutionEnvironment will install new >> TestExecutionEnvironment and delegate processing to it. And if >> TestExecutionEnvironment is already active it will just process >> new test case. >> >> Now monkey has problem in checking slice (annoying timeout for >> loading). >> So I can't see real system impact. But it should not stop you >> from review :)) >> I think it is very important features for all our tests. And >> environment idea will lead to very interesting future. > > Indeed! >> >> Best regards, >> Denis > >

Sept. 4, 2016

Re: [Pharo-dev] About file printOn: method

by stepharo

It is raining and I will do it :) stef Le 4/9/16 Ã 02:38, monty a Ã©crit : > +1 > >> Sent: Saturday, September 03, 2016 at 10:39 AM >> From: stepharo <stepharo(a)free.fr> >> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Subject: [Pharo-dev] About file printOn: method >> >> Hi >> >> >> I will implement the following because this is too annoying. >> >> currently >> >> 'tmp/foo.txt' asFileReference >> > >> File @ tmp/foo.txt >> >> and it would be much much better to get back >> 'tmp/foo.txt' asFileReference >> >> So that we can get >> { 'tmp/foo.txt' asFileReference } >> > { 'tmp/foo.txt' asFileReference } >> >> and not >> "an Array(File @ tmp/foo.txt)" >> >> >> In addition we should turn the current printOn: method into a >> displayString method so that >> a list of fileReference can be well display with File @ tmp/foo.txt for >> example >> >> >> https://pharo.fogbugz.com/f/cases/18956 >> >> >> >

Sept. 4, 2016

Re: [Pharo-dev] could we discuss 19006

by stepharo

thanks. I had problems to see the code when merging. I will integrate it today if the system lets me doing it :). Le 4/9/16 Ã 02:19, monty a Ã©crit : > It doesn't add any new streams or other classes besides a test case. AbstractBinaryStream was already there. > > It just adds #sync to the FileSysteam API and legacy file streams, recategorizes many stream methods to make them more consistent, fixes #flush to fail when the primitive does (the correct behavior-read the comment!), and adds tests for WriteStream and LimitedWriteStream. > > The #sync addition on Unix uses ffsync(), while #flush uses fflush(). Why is #sync needed if we have #flush? From `man fflush`: > >> Note that fflush() flushes only the user-space buffers provided by the >> C library. To ensure that the data is physically stored on disk the >> kernel buffers must be flushed too, for example, with sync(2) or >> fsync(2). > (but on Windows they're implemented identically) > >> Sent: Saturday, September 03, 2016 at 3:34 PM >> From: stepharo <stepharo(a)free.fr> >> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Subject: [Pharo-dev] could we discuss 19006 >> >> Hi guys >> >> The change 19006 is adding a lot of streams AbstractBinaryStream and I >> do not really get the vision. >> >> Note that I'm not against. I just want to understand. >> >> Do we add these and remove some old ones? >> >> What is sync? >> >> Ideally I would like to throw away all the streams and use xtreams instead. >> >> So thanks for your time explaining us the idea. >> >> >> Stef >> >> >> >> >> >

Sept. 4, 2016

streamlining creation of gtInspector extensions

by Ben Coman

Just a passing thought (that I'm sorry I don't have time to explore myself right now) ... I wonder if GT devs might experiment with streamlining discover-ability of existing and creation of new extensions by being able to right-click the tabs to get a menu.... * Show Definition - which opens a browser on the right code * Create Custom Extension - which opens a dialog to create a new package "MyGTExtensions" and/or select an existing package, specify an identifier and choose a template that is created and Browser opened. The might help facilitate creating the extensions while in the "flow" of developing. At the moment I need to break context to go searching for gtInspectorXX: examples to use as a template, take time understanding each to choose which is applicable (repetitively each time I want to create an extension since they don't "stick" in my head). At times I feel a tension between taking the time to create an extension and staying in the "flow" and I think such a facility would reduce this friction. cheers -ben

Sept. 4, 2016

Re: [Pharo-dev] About file printOn: method

by monty

+1 > Sent: Saturday, September 03, 2016 at 10:39 AM > From: stepharo <stepharo(a)free.fr> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: [Pharo-dev] About file printOn: method > > Hi > > > I will implement the following because this is too annoying. > > currently > > 'tmp/foo.txt' asFileReference > > > File @ tmp/foo.txt > > and it would be much much better to get back > 'tmp/foo.txt' asFileReference > > So that we can get > { 'tmp/foo.txt' asFileReference } > > { 'tmp/foo.txt' asFileReference } > > and not > "an Array(File @ tmp/foo.txt)" > > > In addition we should turn the current printOn: method into a > displayString method so that > a list of fileReference can be well display with File @ tmp/foo.txt for > example > > > https://pharo.fogbugz.com/f/cases/18956 > > >

Sept. 4, 2016