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

All integrations blocked on "16061 DNU when running ProfStef tests"

by Marcus Denker

> We need to fix > > 16061 DNU when running ProfStef tests > https://pharo.fogbugz.com/f/cases/16061/ > > > Running tests leads to a DNU in a forked process which is not a test failure but instead terminates all > test runs on the build server as âsuccessâ as soon as the image quits due to the DNU. > > Marcus >

July 29, 2015

Re: [Pharo-dev] About "compileSilently"

by Marcus Denker

Not known, but the whole #prepareDebuggerExample method is very strange. We should remove it. > On 29 Jul 2015, at 16:05, roberto.minelli(a)usi.ch wrote: > > Hi, > > I donât know if this is related, but recently happens something super strange to my images. > > From time to time, in one of my commits the author is suddenly changed to âAutoGenTutorialâ and, if I donât spot this, from now on the Pharo image stops recording my changes. > > This is very frustrating.. is this a known issue? > > Thanks a lot, > RM > > >> On 30 May 2015, at 06:01, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> >> >> 2015-05-28 21:14 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> Le 28/05/2015 20:40, Nicolai Hess a Ã©crit : >> >> >> 2015-05-28 16:55 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>>: >> >> >> >> 2015-05-28 16:49 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>>: >> >> How silent should "compileSilently" be? >> >> no trace in the system : >> 15314 <https://pharo.fogbugz.com/default.asp?15314> >> compileSilently and method history / changes file >> >> not half silenlty >> 13023 <https://pharo.fogbugz.com/default.asp?13023> >> Test Cases should not do things half silently >> >> not "SystemAnnouncer-silent" >> 10560 <https://pharo.fogbugz.com/default.asp?10560> >> SystemAnnouncer and compileSilently >> >> >> ? >> >> What do you think, what granularity of "silent" do we need. >> I see at least three different use cases: >> >> - just an ordinary compile >> >> >> ? Silent means that: Core infrastructure is not updated properly >> (i.e. RPackage) and tools (Browsers) can end desynchronised with the >> methods. >> >> - compile for tests >> >> >> Probably the one... But I wonder if this is a good idea anyway. I'd >> believe most tests using silently are using it wrongly and shouldn't >> be using it in the first place. >> >> - compile autogenerated methods. >> >> >> This one may not be silent. If the auto-generated method will be >> visible (saved in a package, can be browsed, etc...) then it >> shouldn't be silent. >> >> >> >> What about compiled method for which the source did not change? >> >> Hum. I see what you mean. >> >> I do silent compilation when I install tracing probes inside methods, to make sure they don't appear as changed in browsers... But I don't create new methods. I guess this will be the same with the MetaLinks Marcus is preparing. >> >> But, yes, as I said: methods or changes that are not visible then you can make them silent. >> >> But in a different case, such as compiling a SmaCC parser, you want that code to be visible. >> >> >> For NativeBoost generated methods, I may want to have that code visible too. >> I just don't want the code to be marked as "changed" after a recompilation. >> >> For example, a subclass of NativeBoosts NBExternalStructure or NBExternalArray must be recompiled when used in a new session, or when the structure >> changed. >> >> The compiler installs the generated accessor methods and you may want to see that code - just to make sure the structure change was applied. >> But you really don't want this code in a changeset, because whenever you use this code in another image or in a new session it >> will be recompiled anyway. >> >> >> >> I am interested on this for issue 15315, everytime you open spotter, >> you'll get a new >> >> "method: PharoSyntaxTutorial divideTwoByZero; AutoGenTutorial 5/28/2015 >> 20:34" >> >> in you changes file. >> >> This one makes for some annoying noise in the changes. But as I say below, maybe it doesn't matter. >> >> Another case are autogenerated methods from NativeBoost. >> For example, open a fresh image and execute code that triggers >> NativeBoost to install native functions for this session. >> (EllipseMorph new openInSceneView) >> >> And now look at your list of recent changes. >> I get about 30 entries for athens/cairo methods. >> >> One of the thing to consider is what you use the changes for. If it is to recover from crashes, then what you just need to make sure is that replaying all since the last save is ok... even if you have multiple times the same method source saved in it. >> >> Yes, you are right. It does not hurt to have this in the changes file. (But it does not have any use to be there). >> >> >> True changes management is happening in the packages these days, and most code written in the changes shouldn't be recorded there imho (oh, well, apart for the source pointer, of course). >> >> And other uses it could have (recording all do its, for example) is reimplemented / duplicated elsewhere in the system anyway. >> >> Thierry >

July 29, 2015

Re: [Pharo-dev] About "compileSilently"

by roberto.minelli＠usi.ch

Hi, I donât know if this is related, but recently happens something super strange to my images. >From time to time, in one of my commits the author is suddenly changed to âAutoGenTutorialâ and, if I donât spot this, from now on the Pharo image stops recording my changes. This is very frustrating.. is this a known issue? Thanks a lot, RM > On 30 May 2015, at 06:01, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-05-28 21:14 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Le 28/05/2015 20:40, Nicolai Hess a Ã©crit : > > > 2015-05-28 16:55 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>>: > > > > 2015-05-28 16:49 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>>: > > How silent should "compileSilently" be? > > no trace in the system : > 15314 <https://pharo.fogbugz.com/default.asp?15314> > compileSilently and method history / changes file > > not half silenlty > 13023 <https://pharo.fogbugz.com/default.asp?13023> > Test Cases should not do things half silently > > not "SystemAnnouncer-silent" > 10560 <https://pharo.fogbugz.com/default.asp?10560> > SystemAnnouncer and compileSilently > > > ? > > What do you think, what granularity of "silent" do we need. > I see at least three different use cases: > > - just an ordinary compile > > > ? Silent means that: Core infrastructure is not updated properly > (i.e. RPackage) and tools (Browsers) can end desynchronised with the > methods. > > - compile for tests > > > Probably the one... But I wonder if this is a good idea anyway. I'd > believe most tests using silently are using it wrongly and shouldn't > be using it in the first place. > > - compile autogenerated methods. > > > This one may not be silent. If the auto-generated method will be > visible (saved in a package, can be browsed, etc...) then it > shouldn't be silent. > > > > What about compiled method for which the source did not change? > > Hum. I see what you mean. > > I do silent compilation when I install tracing probes inside methods, to make sure they don't appear as changed in browsers... But I don't create new methods. I guess this will be the same with the MetaLinks Marcus is preparing. > > But, yes, as I said: methods or changes that are not visible then you can make them silent. > > But in a different case, such as compiling a SmaCC parser, you want that code to be visible. > > > For NativeBoost generated methods, I may want to have that code visible too. > I just don't want the code to be marked as "changed" after a recompilation. > > For example, a subclass of NativeBoosts NBExternalStructure or NBExternalArray must be recompiled when used in a new session, or when the structure > changed. > > The compiler installs the generated accessor methods and you may want to see that code - just to make sure the structure change was applied. > But you really don't want this code in a changeset, because whenever you use this code in another image or in a new session it > will be recompiled anyway. > > > > I am interested on this for issue 15315, everytime you open spotter, > you'll get a new > > "method: PharoSyntaxTutorial divideTwoByZero; AutoGenTutorial 5/28/2015 > 20:34" > > in you changes file. > > This one makes for some annoying noise in the changes. But as I say below, maybe it doesn't matter. > > Another case are autogenerated methods from NativeBoost. > For example, open a fresh image and execute code that triggers > NativeBoost to install native functions for this session. > (EllipseMorph new openInSceneView) > > And now look at your list of recent changes. > I get about 30 entries for athens/cairo methods. > > One of the thing to consider is what you use the changes for. If it is to recover from crashes, then what you just need to make sure is that replaying all since the last save is ok... even if you have multiple times the same method source saved in it. > > Yes, you are right. It does not hurt to have this in the changes file. (But it does not have any use to be there). > > > True changes management is happening in the packages these days, and most code written in the changes shouldn't be recorded there imho (oh, well, apart for the source pointer, of course). > > And other uses it could have (recording all do its, for example) is reimplemented / duplicated elsewhere in the system anyway. > > Thierry

July 29, 2015

Re: [Pharo-dev] Event handling insanity

by Thierry Goubier

Le 28/07/2015 23:40, Igor Stasenko a Ã©crit : > > > On 28 July 2015 at 22:27, Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>> wrote: > > Hi Igor, > > Le 28/07/2015 18:35, Igor Stasenko a Ã©crit : > > > > On 27 July 2015 at 18:31, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com> > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@gmail.com>>> wrote: > > Le 27/07/2015 15:42, Igor Stasenko a Ã©crit : > > Nothing here is about things to fix, > but rather about how impossible to debug event handling in > system that > runs and relies on very same events.. > > > Esay Igor, just use a code event tracer as for example > Jejak, and > all you describe below won't happen. Or an event logger, or > metalinks, or anything. > > I don't understand. You have the tools, why don't you use them? > > > Perhaps because i unaware of them? > And while i agree that using robust tools would help, i don't > see how > tools can help with "unkilling" an image which you just killed > by own > hand because of mistake you made :) > > > That one is hard to recover from. We can only trace (and use an > external logging tool), or remote exception/debugging capacity. > > Yeah, anyways that's orthogonal to event tracing. One tools for this, > another for that.. Sure tools are handy, and i am not opposed to use > them if it could save my time and effort. Yes, this is the hard part with tools. There is a required investment, and, specially for the tool developper, if there is little traction, then he just keep them for himself ;) > About Jejak, i only found this: > http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html > > > The current version is hosted on github, at > http://github.com/ThierryGoubier/Jejak > > Where i can read bout it? It sounds very useful indeed. > > > There is no real paper on it; I can send you the technical report I > wrote on it in 2007 at UBO, but it focuses more on how it was > implemented (especially optimised) for VisualWorks. > > > This time i remember Stef's words: if it has no docs it doesn't exists. > He said this about things i do, and not caring documenting it well. > But same applies to situation when i want to use something, isn't? See, > i would happily use anything that could help me in my adventure, unless > it will means delving into separate adventure of 'discover by yourself > and do some (re)search in code about how this or that great tool works > and how to use it'. Yes, Stef is right, in a way. Documentation is also written in response to a community; if there is no response, then the documentation is not written or rots away as the Pharo versions come and go. > That's the answer to your original question, why me (or other people) > don't using a great tools lying and waiting for them. Yes. It also makes a view on efforts reinventing the wheel here and there, or not progressing much apart as engineering efforts. Engineering efforts are necessary, but, in themselves, they are a bit disappointing if you know the state of the art in that particular field. > Nobody cares about writing docs (including myself), that's why i don't > dare asking people why they not using them. Because i know the answer :) Yes and no. I told you: some of it is community response. Given the effort and response to the Metalink work underway, I thought that the pharo community was aware of what they could / should enable as tooling ;) Regards, Thierry

July 29, 2015

Fwd: Freezing Bloc UI

by Peter UhnÃ¡k

... I should really stop clicking <Reply> instead of <Reply to all>.... sorry for the double mails Nicolai. Platform - Debian Linux 64 bit (mix of stable/testing/experimental) Font - DejaVu Sans Regular 10 (I wanted to use Source Sans Pro, but my system is behaving weirdly about this font, so I used DejaVu, but in principle its same) libcairo2 1.14.2-2 Morphic is screen from Morphic world (with hinting on normal) Pango/Cairo generated with this script http://pastebin.com/Fx0r4XWJ (I found the code in this discussion http://ubuntuforums.org/archive/index.php/t-2120175.html ) Bloc is from Bloc world. Apart from antialiasing, in âthe Bloc one you can also see that kerning is wrong; noticeable for example in q-uic-k, br-o-wn, l-azy or Config-uration. Peter On Tue, Jul 28, 2015 at 11:36 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-07-28 20:51 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> So apparently Firefox uses Pango on top of Cairo to render fonts. Is that >> something we can apply? >> Because the results from pangocairo looks much better than what is >> currently in Bloc. >> > > Can you show an example. > with some info about: > what platform > cairo version > the font > > >> >> Or maybe I should be looking into Athens-based solution? >> What is Athens thens? I thought that it's vector canvas, but that's what >> cairo is. Is athens just Smalltalk binding? Where is the line? >> > > Yes, Athens is the API and cairo is the backend. All rendering happens > through cairo (and freetype). > > >> >> Thanks, >> Peter >> >> On Tue, Jul 28, 2015 at 8:47 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >>> but I don't know if we will do this ever or if it is possible at all. >>>>> >>>> >>> What do you mean not possible? That Bloc will have ugly jagged font >>> without kerning? >>> >>> I mean whole Firefox (Gecko) is rendered on Cairo, so surely the issue >>> can't be in Cairo. So maybe we just need to implement/wrap/bridge something >>> somewhere? >>> >>> So if I want usable fonts I will need to start studying athens/cairo >>> internals? >>> >>> Peter >>> >> >> >

July 29, 2015

Re: [Pharo-dev] Disabling Rubric in Nautilus (+VM crash)

by Nicolai Hess

2015-07-29 8:55 GMT+02:00 Jan Vrany <jan.vrany(a)fit.cvut.cz>: > On Wed, 2015-07-22 at 14:55 +0200, stepharo wrote: > > Jan do you have a scenario where we can see the performance issue? > > > > Hmm...actually not reproducible one. Here's the story: > > It happened me couple times that the CPU (core) usage was 100% when > I typed in Nautilus. When I stopped typing, CPU usage went to 5% > (which is "normal" IIUC). > > I saved the image when it exhibited the performance problem, but the > other day it failed to open at all. VM crashed before opening the > window (log attached if anyone's interested - from the trace it looks > like freetype plugin's doing something wrong. > > Funny enough after not having time for this for couple days, > I tried again and the (i) the image does start and (ii) it does no > longer exhibit the poor performance. > > I'm bloody sure nothing changed in my system meanwhile (no VM change, > no upgrade of system libraries, etc). The image that crashed used no > FFI calls except those done by system as shipped. So in the end > something else seems to be broken and Rubric performance could be > just a consequence. Maybe I suspected the wrong guy. Sorry about that. > Yes and no, the 5.0 Image has a problem with loading FT-Fonts at startup -> it crash crash, but not always. and there are some (other) issues with Nautilus (fast table, it is now disabled again,and some issues with rubric text for the code panel (slow and/or no highlighting)). nicolai > > Best, Jan > > > > > > Le 22/7/15 10:03, Jan Vrany a Ã©crit : > > > On Tue, 2015-07-21 at 23:38 +0200, Franck Warlouzet wrote: > > > > Hello Jan, > > > > > > > > On Pharo 5, I don't think so (unless you want to reload the very > > > > old > > > > commits from nautilus). PluggableTextMorph will be remove so we > > > > will > > > > not put an option to switch between Rubric or that. > > > Right. Is there a way to dig out an older image prior the switch? > > > > > > > What do not you like with Rubric ? > > > It's not that I don't like it, but in my very case it burns > > > my CPU. Looks like a performance problem. > > > > > > Thanks! Jan > > > > > > > Franck > > > > > > > > > From: jan.vrany(a)fit.cvut.cz > > > > > To: pharo-dev(a)lists.pharo.org > > > > > Date: Tue, 21 Jul 2015 22:19:05 +0100 > > > > > Subject: [Pharo-dev] Disabling Rubric in Nautilus > > > > > > > > > > Hi there, > > > > > > > > > > is there a way to disable Rubric in Nautilus and get back > > > > > to PluggableTextMorph or whichever beast was used before? > > > > > Quick search in settings did not help. > > > > > > > > > > Jan > > > > > > > > > > > >

July 29, 2015

Re: [Pharo-dev] Disabling Rubric in Nautilus (+VM crash)

by Jan Vrany

On Wed, 2015-07-22 at 14:55 +0200, stepharo wrote: > Jan do you have a scenario where we can see the performance issue? > Hmm...actually not reproducible one. Here's the story: It happened me couple times that the CPU (core) usage was 100% when I typed in Nautilus. When I stopped typing, CPU usage went to 5% (which is "normal" IIUC). I saved the image when it exhibited the performance problem, but the other day it failed to open at all. VM crashed before opening the window (log attached if anyone's interested - from the trace it looks like freetype plugin's doing something wrong. Funny enough after not having time for this for couple days, I tried again and the (i) the image does start and (ii) it does no longer exhibit the poor performance. I'm bloody sure nothing changed in my system meanwhile (no VM change, no upgrade of system libraries, etc). The image that crashed used no FFI calls except those done by system as shipped. So in the end something else seems to be broken and Rubric performance could be just a consequence. Maybe I suspected the wrong guy. Sorry about that. Best, Jan > > Le 22/7/15 10:03, Jan Vrany a Ã©crit : > > On Tue, 2015-07-21 at 23:38 +0200, Franck Warlouzet wrote: > > > Hello Jan, > > > > > > On Pharo 5, I don't think so (unless you want to reload the very > > > old > > > commits from nautilus). PluggableTextMorph will be remove so we > > > will > > > not put an option to switch between Rubric or that. > > Right. Is there a way to dig out an older image prior the switch? > > > > > What do not you like with Rubric ? > > It's not that I don't like it, but in my very case it burns > > my CPU. Looks like a performance problem. > > > > Thanks! Jan > > > > > Franck > > > > > > > From: jan.vrany(a)fit.cvut.cz > > > > To: pharo-dev(a)lists.pharo.org > > > > Date: Tue, 21 Jul 2015 22:19:05 +0100 > > > > Subject: [Pharo-dev] Disabling Rubric in Nautilus > > > > > > > > Hi there, > > > > > > > > is there a way to disable Rubric in Nautilus and get back > > > > to PluggableTextMorph or whichever beast was used before? > > > > Quick search in settings did not help. > > > > > > > > Jan > > > > > > > >

July 29, 2015

[pharo-project/pharo-core]

by GitHub

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

July 29, 2015

[pharo-project/pharo-core] c487f5: 50197

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c487f5e6f6dcd3f9f20b1f31de426f1ef8731301 https://github.com/pharo-project/pharo-core/commit/c487f5e6f6dcd3f9f20b1f31… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-07-29 (Wed, 29 Jul 2015) Changed paths: M Graphics-Primitives.package/Color.class/instance/accessing/brightness.st A Graphics-Primitives.package/Color.class/instance/accessing/chroma.st A Graphics-Primitives.package/Color.class/instance/accessing/hslSaturation.st A Graphics-Primitives.package/Color.class/instance/accessing/hsvSaturation.st A Graphics-Primitives.package/Color.class/instance/accessing/lightness.st M Graphics-Primitives.package/Color.class/instance/accessing/saturation.st A Graphics-Primitives.package/Color.class/instance/private/privateMaxComponent.st A Graphics-Primitives.package/Color.class/instance/private/privateMinComponent.st M OpalCompiler-Core.package/OCASTTranslator.class/instance/visitor-double dispatching/visitBlockNode_.st M ProfStef-Core.package/AbstractTutorial.class/class/tutorial metainfo/contentsOfTutorials.st M ProfStef-Core.package/HowToMakeYourOwnTutorial.class/README.md M ProfStef-Core.package/HowToMakeYourOwnTutorial.class/instance/lessons/createLessonFactoryMethods.st M ProfStef-Core.package/HowToMakeYourOwnTutorial.class/instance/lessons/implementTutorial.st M ProfStef-Core.package/HowToMakeYourOwnTutorial.class/instance/lessons/runYourTutorial.st M ProfStef-Core.package/HowToMakeYourOwnTutorial.class/instance/lessons/subclassAbstractTutorial.st M ProfStef-Core.package/LessonView.class/instance/gui/buildText.st M ProfStef-Core.package/PharoSyntaxTutorial.class/instance/lessons/basicTypesSymbol.st M ProfStef-Core.package/PharoSyntaxTutorial.class/instance/lessons/blocks.st M ProfStef-Core.package/PharoSyntaxTutorial.class/instance/lessons/doingVSPrinting.st M ProfStef-Core.package/ProfStef.class/README.md A ProfStef-Core.package/ProfStef.class/class/as yet unclassified/goToNextLesson.st R Reflectivity-Tests.package/CoverageDemoTest.class/instance/test/testCoverageAST.st R Reflectivity-Tests.package/CoverageDemoTest.class/instance/test/testCoverageMethod.st A Reflectivity-Tests.package/CoverageDemoTest.class/instance/tests/testCoverageAST.st A Reflectivity-Tests.package/CoverageDemoTest.class/instance/tests/testCoverageControlFlow.st A Reflectivity-Tests.package/CoverageDemoTest.class/instance/tests/testCoverageMethod.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterBlock.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeBlock.st M Reflectivity-Tests.package/ReflectivityExamples.class/instance/examples/exampleBlock.st A Reflectivity-Tests.package/ReflectivityExamples.class/instance/examples/exampleIfTrueIfFalse.st M Reflectivity.package/MetaLink.class/instance/link api/arguments_.st A Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitBlockNode_.st A Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitInlinedBlockNode_.st R Reflectivity.package/RFReification.class/instance/as yet unclassified/genForRBGlobalNode.st R Reflectivity.package/RFReification.class/instance/as yet unclassified/genForRBInstanceVariableNode.st R Reflectivity.package/RFReification.class/instance/as yet unclassified/genForRBLiteralValueNode.st A Reflectivity.package/RFReification.class/instance/generate/genForRBGlobalNode.st A Reflectivity.package/RFReification.class/instance/generate/genForRBInstanceVariableNode.st A Reflectivity.package/RFReification.class/instance/generate/genForRBLiteralValueNode.st A Reflectivity.package/RFReification.class/instance/generate/genForRBSelfNode.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50196.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50197.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50196.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50197.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-MorphicAdapters.package/MorphicDiffAdapter.class/instance/spec protocol/contextClass_.st M Spec-MorphicAdapters.package/MorphicDiffAdapter.class/instance/spec protocol/leftText_.st M Spec-MorphicAdapters.package/MorphicDiffAdapter.class/instance/spec protocol/rightText_.st M Tool-Diff.package/DiffChangeMorph.class/instance/actions/newDiffMorph.st A Tool-Diff.package/DiffJoinMorph.class/instance/drawing/drawOnAthensCanvas_.st A Tool-Diff.package/DiffMapMorph.class/instance/nil/drawOnAthensCanvas_.st M Tool-Diff.package/DiffMorph.class/definition.st M Tool-Diff.package/DiffMorph.class/instance/accessing colors/additionColor.st M Tool-Diff.package/DiffMorph.class/instance/accessing colors/matchColor.st M Tool-Diff.package/DiffMorph.class/instance/accessing/contextClass.st M Tool-Diff.package/DiffMorph.class/instance/accessing/contextClass_.st A Tool-Diff.package/DiffMorph.class/instance/accessing/defaultTitle.st R Tool-Diff.package/DiffMorph.class/instance/accessing/dstText.st R Tool-Diff.package/DiffMorph.class/instance/accessing/dstText_.st R Tool-Diff.package/DiffMorph.class/instance/accessing/font_.st A Tool-Diff.package/DiffMorph.class/instance/accessing/selectedClassOrMetaClass.st R Tool-Diff.package/DiffMorph.class/instance/accessing/srcText.st R Tool-Diff.package/DiffMorph.class/instance/accessing/srcText_.st A Tool-Diff.package/DiffMorph.class/instance/actions/applyHighlights.st A Tool-Diff.package/DiffMorph.class/instance/actions/applyJoin.st A Tool-Diff.package/DiffMorph.class/instance/actions/applyMap.st A Tool-Diff.package/DiffMorph.class/instance/actions/applyPrettyPrinter.st A Tool-Diff.package/DiffMorph.class/instance/actions/calculateDifference.st A Tool-Diff.package/DiffMorph.class/instance/actions/calculateJoinMappings.st M Tool-Diff.package/DiffMorph.class/instance/actions/calculatedJoinMappings.st A Tool-Diff.package/DiffMorph.class/instance/actions/calibrateScrollbar.st R Tool-Diff.package/DiffMorph.class/instance/actions/from_to_contextClass_.st A Tool-Diff.package/DiffMorph.class/instance/actions/join_selected_.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/applyHighlights.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/applyJoin.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/applyMap.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/calculateDifference.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/calculateJoinMappings.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/calibrateScrollbar.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/defaultTitle.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/dstScroll_.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/hideOrShowScrollBar.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/join_selected_.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/mapClicked_.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/oldText.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/setText.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/srcScroll_.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/updateJoinOffsets.st R Tool-Diff.package/DiffMorph.class/instance/as yet unclassified/vScroll_.st A Tool-Diff.package/DiffMorph.class/instance/event handling/horizontalDestScroll_.st A Tool-Diff.package/DiffMorph.class/instance/event handling/horizontalSourceScroll_.st A Tool-Diff.package/DiffMorph.class/instance/event handling/mapClicked_.st A Tool-Diff.package/DiffMorph.class/instance/event handling/verticalScroll_.st R Tool-Diff.package/DiffMorph.class/instance/geometry/extent_.st M Tool-Diff.package/DiffMorph.class/instance/initialization/addMainMorphsWith_.st M Tool-Diff.package/DiffMorph.class/instance/initialization/initialize.st R Tool-Diff.package/DiffMorph.class/instance/instance creation/from_to_.st A Tool-Diff.package/DiffMorph.class/instance/instance-creation/destTextModel.st A Tool-Diff.package/DiffMorph.class/instance/instance-creation/from_to_.st A Tool-Diff.package/DiffMorph.class/instance/instance-creation/from_to_contextClass_.st M Tool-Diff.package/DiffMorph.class/instance/instance-creation/newDstMorph.st M Tool-Diff.package/DiffMorph.class/instance/instance-creation/newJoinMorph.st M Tool-Diff.package/DiffMorph.class/instance/instance-creation/newJoinSectionFrom_to_.st M Tool-Diff.package/DiffMorph.class/instance/instance-creation/newMatchJoinSectionFrom_to_.st M Tool-Diff.package/DiffMorph.class/instance/instance-creation/newScrollbarMorph.st M Tool-Diff.package/DiffMorph.class/instance/instance-creation/newSrcMorph.st R Tool-Diff.package/DiffMorph.class/instance/instance-creation/newText.st A Tool-Diff.package/DiffMorph.class/instance/instance-creation/sourceTextModel.st A Tool-Diff.package/DiffMorph.class/instance/private/hideOrShowScrollBar.st R Tool-Diff.package/DiffMorph.class/instance/update/updateText.st A Tool-Diff.package/DiffMorph.class/instance/updating/updateJoinOffsets.st A Tool-Diff.package/DiffMorph.class/instance/updating/vScroll_.st A Tool-Diff.package/DiffMorph.class/instance/user interface/updateText.st M Tool-Diff.package/JoinSection.class/instance/as yet unclassified/clicked.st M Tool-Diff.package/JoinSection.class/instance/as yet unclassified/createHighlightsFrom_to_.st M Tool-FileList.package/FileList.class/definition.st A Tool-FileList.package/FileList.class/instance/accessing/brevityState.st M Tool-FileList.package/FileList.class/instance/accessing/fileListIndex_.st M Tool-FileList.package/FileList.class/instance/file menu action/get.st M Tool-FileList.package/FileList.class/instance/initialization/initialize.st M Tool-FileList.package/FileList.class/instance/morphic ui/morphicViewOnFile_.st M Tool-FileList.package/FileList.class/instance/private/fileEncoding_.st A Tool-FileList.package/FileList.class/instance/updating/changedContents.st A Tool-FileList.package/FileList.class/instance/updating/whenTextAccepted_.st M Tool-FileList.package/FileList.class/instance/user interface/morphicFileContentsPane.st A Tool-FileList.package/FileList.class/instance/user interface/sourceTextModel.st M Tool-ProcessBrowser.package/ProcessBrowser.class/class/instance creation/open.st M Tool-ProcessBrowser.package/ProcessBrowser.class/definition.st M Tool-ProcessBrowser.package/ProcessBrowser.class/instance/accessing/selectedClass.st M Tool-ProcessBrowser.package/ProcessBrowser.class/instance/accessing/stackListIndex_.st M Tool-ProcessBrowser.package/ProcessBrowser.class/instance/initialization/initialize.st M Tool-ProcessBrowser.package/ProcessBrowser.class/instance/initialization/startCPUWatcher.st M Tool-ProcessBrowser.package/ProcessBrowser.class/instance/initialization/stopCPUWatcher.st M Tool-ProcessBrowser.package/ProcessBrowser.class/instance/process actions/explorePointers.st M Tool-ProcessBrowser.package/ProcessBrowser.class/instance/process list/processNameList.st M Tool-ProcessBrowser.package/ProcessBrowser.class/instance/stack list/browseContext.st M Tool-ProcessBrowser.package/ProcessBrowser.class/instance/stack list/changeStackListTo_.st M Tool-ProcessBrowser.package/ProcessBrowser.class/instance/stack list/stackNameList.st M Tool-ProcessBrowser.package/ProcessBrowser.class/instance/updating/setUpdateCallbackAfter_.st A Tool-ProcessBrowser.package/ProcessBrowser.class/instance/views/browsedEnvironment.st A Tool-ProcessBrowser.package/ProcessBrowser.class/instance/views/build.st R Tool-ProcessBrowser.package/ProcessBrowser.class/instance/views/openAsMorph.st A Tool-ProcessBrowser.package/ProcessBrowser.class/instance/views/refactor.st Log Message: ----------- 50197 16058 Clean ProfStef https://pharo.fogbugz.com/f/cases/16058 16055 Color HSL accessors https://pharo.fogbugz.com/f/cases/16055 16056 Cleaning ProcessBrowser https://pharo.fogbugz.com/f/cases/16056 15948 Removing PluggableTextMorph from FileList https://pharo.fogbugz.com/f/cases/15948 15903 Use Rubric in DiffMorph https://pharo.fogbugz.com/f/cases/15903 16059 support #before on Blocks... https://pharo.fogbugz.com/f/cases/16059 http://files.pharo.org/image/50/50197.zip

July 29, 2015

Re: [Pharo-dev] Event handling insanity

by Igor Stasenko

On 28 July 2015 at 22:27, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Igor, > > Le 28/07/2015 18:35, Igor Stasenko a Ã©crit : > >> >> >> On 27 July 2015 at 18:31, Thierry Goubier <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>> wrote: >> >> Le 27/07/2015 15:42, Igor Stasenko a Ã©crit : >> >> Nothing here is about things to fix, >> but rather about how impossible to debug event handling in >> system that >> runs and relies on very same events.. >> >> >> Esay Igor, just use a code event tracer as for example Jejak, and >> all you describe below won't happen. Or an event logger, or >> metalinks, or anything. >> >> I don't understand. You have the tools, why don't you use them? >> >> >> Perhaps because i unaware of them? >> And while i agree that using robust tools would help, i don't see how >> tools can help with "unkilling" an image which you just killed by own >> hand because of mistake you made :) >> > > That one is hard to recover from. We can only trace (and use an external > logging tool), or remote exception/debugging capacity. > > Yeah, anyways that's orthogonal to event tracing. One tools for this, another for that.. Sure tools are handy, and i am not opposed to use them if it could save my time and effort. > About Jejak, i only found this: >> http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html >> > > The current version is hosted on github, at > http://github.com/ThierryGoubier/Jejak > > Where i can read bout it? It sounds very useful indeed. >> > > There is no real paper on it; I can send you the technical report I wrote > on it in 2007 at UBO, but it focuses more on how it was implemented > (especially optimised) for VisualWorks. > > This time i remember Stef's words: if it has no docs it doesn't exists. He said this about things i do, and not caring documenting it well. But same applies to situation when i want to use something, isn't? See, i would happily use anything that could help me in my adventure, unless it will means delving into separate adventure of 'discover by yourself and do some (re)search in code about how this or that great tool works and how to use it'. That's the answer to your original question, why me (or other people) don't using a great tools lying and waiting for them. Nobody cares about writing docs (including myself), that's why i don't dare asking people why they not using them. Because i know the answer :) Thierry > > -- Best regards, Igor Stasenko.

July 28, 2015