November 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 03478d: 50476

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 03478dae50cdd47c2e344f679f2e6c9a87f13e83 https://github.com/pharo-project/pharo-core/commit/03478dae50cdd47c2e344f67… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-27 (Fri, 27 Nov 2015) Changed paths: M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/morphic ui/repositories.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/morphic ui/repositoryGroup.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/morphic ui/repositoryList.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/morphic ui/repositorySelection.st A MonticelloGUI.package/MCWorkingCopyBrowserTest.class/README.md A MonticelloGUI.package/MCWorkingCopyBrowserTest.class/definition.st A MonticelloGUI.package/MCWorkingCopyBrowserTest.class/instance/running/setUp.st A MonticelloGUI.package/MCWorkingCopyBrowserTest.class/instance/tests/testDefault.st A MonticelloGUI.package/MCWorkingCopyBrowserTest.class/instance/tests/testRepositories.st A MonticelloGUI.package/MCWorkingCopyBrowserTest.class/instance/tests/testRepositoriesIncludeCache.st A MonticelloGUI.package/MCWorkingCopyBrowserTest.class/instance/tests/testRepositoryList.st M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/error handling/unusedVariable_.st R OpalCompiler-Core.package/OCUnusedVariableWarning.class/README.md R OpalCompiler-Core.package/OCUnusedVariableWarning.class/definition.st R OpalCompiler-Core.package/OCUnusedVariableWarning.class/instance/accessing/node_.st R OpalCompiler-Core.package/OCUnusedVariableWarning.class/instance/correcting/defaultAction.st R OpalCompiler-Tests.package/OCCompilerExceptionsTest.class/instance/tests/testUnusedVariable.st A Reflectivity-Tools.package/SemanticWarningIconStyler.class/README.md A Reflectivity-Tools.package/SemanticWarningIconStyler.class/definition.st A Reflectivity-Tools.package/SemanticWarningIconStyler.class/instance/defaults/highlightColor.st A Reflectivity-Tools.package/SemanticWarningIconStyler.class/instance/defaults/iconFor_.st A Reflectivity-Tools.package/SemanticWarningIconStyler.class/instance/defaults/iconLabel_.st A Reflectivity-Tools.package/SemanticWarningIconStyler.class/instance/testing/shouldStyleNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50475.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50476.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50475.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50476.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Debugger.package/SpecDebugger.class/definition.st M Spec-Debugger.package/SpecDebugger.class/instance/initialization/initialize.st R Spec-Debugger.package/SpecDebugger.class/instance/private/onWidgetBuilt.st Log Message: ----------- 50476 17151 MCWorkingCopyBrowser needs some love https://pharo.fogbugz.com/f/cases/17151 17154 Add a highlight to tempvar declarations when they are unused https://pharo.fogbugz.com/f/cases/17154 15543 Add a menu to add the Meta catalog of Pharo to MC https://pharo.fogbugz.com/f/cases/15543 17091 SpecDebugger has unused vars https://pharo.fogbugz.com/f/cases/17091 http://files.pharo.org/image/50/50476.zip

Nov. 27, 2015

Re: [Pharo-dev] Bug with latest image of Pharo 5

by Dimitris Chloupis

yes as always you are correct I lost the names of all my temporary variables but I got that fixed by reimporting the filetree repository. Thank you for your efforts they never go unnoticed. By the way this is a fresh image that does this, I use a startup script to load all my libraries. Maybe one of those libs does something funky to the changes file. Epicea looks interesting. The one thing that makes me wonder is how needed the image file format really is. I get it that is there to store the complete live enviroment but even in that case it can still be broken to individual files each with a specific role, some binary and some text. Afterall there is no reason why state cannot be stored even in text files. In any case I know you guys have many good ideas to improve the situation and I am sure with time you will. On Fri, Nov 27, 2015 at 7:37 PM Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 27 Nov 2015, at 13:32, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > Marcus you are awesome thank, so all I had to do was erase my > Ephestos.changes file and now I can browse addMiscExtraTo: and I have no > MNUs or red boxes of doom. > > > > There was something fishy about my changes file, I found addMiscExtraTo: > in PharoV4.sources and in Ephestos.changes, the issue is that I never > touched that method , so why should it be in changes file ? I thought > changes are for the things you change in the image. > > > > But no complains , it looks like now the problem is gone. > > > > The .changes does not only have the changes that you did, but in addition > all changes that we did to Pharo since the release of Pharo4â¦ > > The whole mechanism is not very goodâ¦ we really should replace it. The > good news is that we are working on the first step > already: Epicea will be used for recording changes, so after that we re > free to simplify source storage as it will now overlap anymore > with change history recording. > > Be careful with an image where you delete the .changes: all methods that > point to that file will be decompiledâ¦ losing comments and much more. > > The best thing is to re-create an image from the release (loading your > code). > > Marcus >

Nov. 27, 2015

Re: [Pharo-dev] Bug with latest image of Pharo 5

by Marcus Denker

> On 27 Nov 2015, at 13:32, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Marcus you are awesome thank, so all I had to do was erase my Ephestos.changes file and now I can browse addMiscExtraTo: and I have no MNUs or red boxes of doom. > > There was something fishy about my changes file, I found addMiscExtraTo: in PharoV4.sources and in Ephestos.changes, the issue is that I never touched that method , so why should it be in changes file ? I thought changes are for the things you change in the image. > > But no complains , it looks like now the problem is gone. > The .changes does not only have the changes that you did, but in addition all changes that we did to Pharo since the release of Pharo4â¦ The whole mechanism is not very goodâ¦ we really should replace it. The good news is that we are working on the first step already: Epicea will be used for recording changes, so after that we re free to simplify source storage as it will now overlap anymore with change history recording. Be careful with an image where you delete the .changes: all methods that point to that file will be decompiledâ¦ losing comments and much more. The best thing is to re-create an image from the release (loading your code). Marcus

Nov. 27, 2015

Re: [Pharo-dev] Bug with latest image of Pharo 5

by Dimitris Chloupis

Marcus you are awesome thank, so all I had to do was erase my Ephestos.changes file and now I can browse addMiscExtraTo: and I have no MNUs or red boxes of doom. There was something fishy about my changes file, I found addMiscExtraTo: in PharoV4.sources and in Ephestos.changes, the issue is that I never touched that method , so why should it be in changes file ? I thought changes are for the things you change in the image. But no complains , it looks like now the problem is gone. On Fri, Nov 27, 2015 at 5:26 PM Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 27 Nov 2015, at 12:15, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > I found how to easily reproduce it every time > > > > 1) Open Spotter and search for addMiscExtrasTo: , locate it at Morph > class, then press enter to open it in browser > > 2) Boom MNU > > > > looking at > > [..] inAstCache > > at: aCompiledMethod > > ^ self at: aCompiledMethod ifAbsentPut: > > [ aCompiledMethod parseTree doSemanticAnalysisIn: aCompiledMethod > methodClass ] > > > > The problem here is even though aCompiledMethod returns the correct > method in this case > > > > Morph>>#addMiscExtrasTo: > > > > the aCompiledMethod parseTree returns nil and this is why it MNUs with > doSemanticAnalysisIn: complaining about a nil receiver which is the case > > > > > > anyone have a clue why its nil ? > > > > if I try to browser parseTree it again gives me a MNU and redbox of doom > makes it impossible to view the method. > > > > I think it happens because the text it reads from the .changes or .sources > is somehow corrupted. > > We should not return #nil but fall back on the decompiler in #parseTreeâ¦ > > Marcus > > >

Nov. 27, 2015

Re: [Pharo-dev] Debugging a failing test doesn't include the full stack

by Esteban A. Maringolo

Thank you Guille! Now... how do we fix it? It affects Pharo 4 too. Regards! Esteban A. Maringolo 2015-11-27 11:01 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: > I debugged and found the reason of the error. > > https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop > > The cause, in two words, is that the debugger is not aware of process > suspension and the debugger depends on it. So having a debugger that tries > to open a debugger creates an endless loop that should be stopped with > process suspension in the normal case. > > > On 25 nov 2015, at 9:32 p.m., Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > 2015-11-25 6:32 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > Iâve seen this problem tons of times since Pharo4. But the worst is that I > never found a way to reproduce it. > > To me there is some side effect somewhere. Because it does not happen in a > fresh image, but once you have it, you have it all the time. > > > I thought it had to do with how GLORP handles the exceptions and/or > block unwinding. But it doesn't seem so. > > There is a bug report for this: > https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop > > > > Esteban A. Maringolo > >

Nov. 27, 2015

Re: [Pharo-dev] Bug with latest image of Pharo 5

by Marcus Denker

> On 27 Nov 2015, at 12:15, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > I found how to easily reproduce it every time > > 1) Open Spotter and search for addMiscExtrasTo: , locate it at Morph class, then press enter to open it in browser > 2) Boom MNU > > looking at > [..] inAstCache > at: aCompiledMethod > ^ self at: aCompiledMethod ifAbsentPut: > [ aCompiledMethod parseTree doSemanticAnalysisIn: aCompiledMethod methodClass ] > > The problem here is even though aCompiledMethod returns the correct method in this case > > Morph>>#addMiscExtrasTo: > > the aCompiledMethod parseTree returns nil and this is why it MNUs with doSemanticAnalysisIn: complaining about a nil receiver which is the case > > > anyone have a clue why its nil ? > > if I try to browser parseTree it again gives me a MNU and redbox of doom makes it impossible to view the method. > I think it happens because the text it reads from the .changes or .sources is somehow corrupted. We should not return #nil but fall back on the decompiler in #parseTreeâ¦ Marcus

Nov. 27, 2015

Re: [Pharo-dev] Bug with latest image of Pharo 5

by Dimitris Chloupis

I found how to easily reproduce it every time 1) Open Spotter and search for addMiscExtrasTo: , locate it at Morph class, then press enter to open it in browser 2) Boom MNU looking at [..] inAstCache at: aCompiledMethod ^ self at: aCompiledMethod ifAbsentPut: [ aCompiledMethod parseTree doSemanticAnalysisIn: aCompiledMethod methodClass ] The problem here is even though aCompiledMethod returns the correct method in this case Morph>>#addMiscExtrasTo: the aCompiledMethod parseTree returns nil and this is why it MNUs with doSemanticAnalysisIn: complaining about a nil receiver which is the case anyone have a clue why its nil ? if I try to browser parseTree it again gives me a MNU and redbox of doom makes it impossible to view the method. Deadends everywhere . On Fri, Nov 27, 2015 at 2:17 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > well the blue theme I am using is called Nireas, made by me. Its inspired > from best computer ever, Amiga 500 > > > [image: amigaos_1-0b3_workbench_2012.png] > > ^ that's Amiga's OS > > On Fri, Nov 27, 2015 at 2:11 PM Christophe Demarey < > Christophe.Demarey(a)inria.fr> wrote: > >> >> Le 27 nov. 2015 Ã 12:28, Nicolai Hess a Ã©crit : >> >> >> >> Wow what an awful bug, it turned you whole screen in ugly blue! >> :) >> >> >> like a windows system error >> >> [image: How to fix blue screen error in windows???] >> >

Nov. 27, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 27, 2015

[pharo-project/pharo-core] 9edc5e: 50475

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 9edc5efc93fcbb97c7787a46db7e5fac6b37741e https://github.com/pharo-project/pharo-core/commit/9edc5efc93fcbb97c7787a46… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-27 (Fri, 27 Nov 2015) Changed paths: R DebuggerActions.package/DebugAction.class/instance/actions/notifyDebugger.st A DebuggerActions.package/DebugAction.class/instance/actions/notifyDebuggingActionExecuted.st M DebuggerActions.package/DebugAction.class/instance/actions/postAction.st M DebuggerActions.package/DebugActionExecuted.class/README.md M DebuggerActions.package/DebugActionExecuted.class/class/as yet unclassified/forDebuggingAction_.st M DebuggerActions.package/DebugActionExecuted.class/definition.st A DebuggerActions.package/DebugActionExecuted.class/instance/accessing/action.st A DebuggerActions.package/DebugActionExecuted.class/instance/accessing/action_.st R DebuggerActions.package/DebugActionExecuted.class/instance/as yet unclassified/actionId_.st M Komitter.package/KomitClass.class/README.md R Komitter.package/KomitClass.class/class/instance creation/new.st M Komitter.package/KomitClass.class/class/instance creation/trackedClass_.st M Komitter.package/KomitClass.class/class/instance creation/trackedClass_forExtension_.st M Komitter.package/KomitClass.class/instance/initialize/initialize.st M Komitter.package/KomitClass.class/instance/protocol/flush.st M Komitter.package/KomitDefinition.class/README.md M Komitter.package/KomitDefinition.class/class/instance creation/definition_.st R Komitter.package/KomitDefinition.class/class/instance creation/new.st M Komitter.package/KomitMethod.class/README.md M Komitter.package/KomitMethod.class/class/instance creation/method_.st R Komitter.package/KomitMethod.class/class/instance creation/new.st M Komitter.package/KomitObject.class/README.md R Komitter.package/KomitPackage.class/class/instance creation/new.st M Komitter.package/KomitPackage.class/class/instance creation/package_.st R Komitter.package/KomitPackage.class/class/instance creation/removePackage_.st A Komitter.package/KomitPackage.class/class/removing/removePackage_.st M Komitter.package/KomitableObject.class/instance/accessing/entities_.st M Komitter.package/KomitableObject.class/instance/initialize/initialize.st M Komitter.package/Komitter.class/README.md M Komitter.package/Komitter.class/instance/initialize/initialize.st M Morphic-Base.package/MenuItemMorph.class/instance/events/activateOwnerMenu_.st M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/error handling/uninitializedVariable_.st R OpalCompiler-Core.package/OCUninitializedVariableWarning.class/README.md R OpalCompiler-Core.package/OCUninitializedVariableWarning.class/definition.st R OpalCompiler-Core.package/OCUninitializedVariableWarning.class/instance/accessing/node_.st R OpalCompiler-Core.package/OCUninitializedVariableWarning.class/instance/correcting/openMenuIn_.st R OpalCompiler-Tests.package/OCCompilerExceptionsTest.class/instance/tests/testUndefinedVariable.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50474.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50475.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50474.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50475.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions-Tests.package/SugsMenuBuilderTest.class/instance/suggstions-by-selection/testNoSuggestionForSelfNode.st M SmartSuggestions-Tests.package/SugsMenuBuilderTest.class/instance/suggstions-by-selection/testNoSuggestionForSuperNode.st Log Message: ----------- 50475 17143 With QA warning for uninitialised Variables, we can remove it from the Compiler https://pharo.fogbugz.com/f/cases/17143 17104 Cleaning Komitter code https://pharo.fogbugz.com/f/cases/17104 17038 DebugActionExecuted should be triggered for every debugging action https://pharo.fogbugz.com/f/cases/17038 17115 DNU when draging an element of PopupChoiceDialogWindow. https://pharo.fogbugz.com/f/cases/17115 17102 two tests in SugsMenuBuilderTest failing https://pharo.fogbugz.com/f/cases/17102 http://files.pharo.org/image/50/50475.zip

Nov. 27, 2015

Re: [Pharo-dev] Debugging a failing test doesn't include the full stack

by Guillermo Polito

I debugged and found the reason of the error. https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop <https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop> The cause, in two words, is that the debugger is not aware of process suspension and the debugger depends on it. So having a debugger that tries to open a debugger creates an endless loop that should be stopped with process suspension in the normal case. > On 25 nov 2015, at 9:32 p.m., Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > 2015-11-25 6:32 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> Iâve seen this problem tons of times since Pharo4. But the worst is that I >> never found a way to reproduce it. >> >> To me there is some side effect somewhere. Because it does not happen in a >> fresh image, but once you have it, you have it all the time. > > I thought it had to do with how GLORP handles the exceptions and/or > block unwinding. But it doesn't seem so. > > There is a bug report for this: > https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop > > > > Esteban A. Maringolo >

Nov. 27, 2015