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

Re: [Pharo-dev] DrTest - strange UI effect and some feedback

by Julien Delplanque

Hello Torsten, First of all, thanks for your feedback. Le 22/11/19 Ã 09:15, Torsten Bergmann a Ã©critÂ : > Hi, > > DrTest is integrated into Pharo 8 now - but there seems to be a strange bug > in overlapping widgets when one uses the grouping selection box. > > See attached screenshot. > > I opened an issue for that: https://github.com/pharo-project/pharo/issues/5205 > for Pharo. Dont know if that is known bug or even already fixed in the original repo > of DrTest. Would be good if the authors (Julien or Dayne) could check. I am not sure what causes this bug, I will need to check with Spec2 developers because I think as Spec2 users we do not have control on such behaviour of the droplist. > > Additional feedback: > > It's really a nice tool - but I see myself still switching back to old TestRunner again. > Two reasons: > > 1. Compared to the regular TestRunner where one is able to see the failing tests > directly in DrTest one always has to have additional clicks in the > grouping tree on the left before getting the final results. > > So the default grouping of the results as a tree could be disturbing because it > requires more clicking around. > > Would be a nice addition if there would be an additional "no grouping" mode as well > so the results are just shown in a list like in reglar TestRunner. I agree with you, an additional iteration needs to be done on the grouping feature. We will take your feedback into account. > > 2. The old TestRunner had (after filtering the package) an additional useful context menu > with "Select all" and "Select none", "Select inversion", .... which allowed > easier focusing on the test classes I want to check. > Would be nice if a similar one could be added. For "Select all" it is possible to do it via Cmd+A or Ctrl+A, as it is the standard for list selection in UI frameworks. For the "Select none" I am not sure that we want to support that action because it feels a bit odd. Why would one want to have nothing selected? But if one can justify why this is needed, we can add it of course. "Select inversion" could be added but again I think this is a bit odd feature. Now you have to know that DrTests is a side project for me and for right now I can not allocate that much time on it. So I will do my best to fix urgent issues ASAP. I already have a great list of issues since the integration (which is normal). :-) However, until next friday, I am in a rush for another deadline. Julien

Nov. 22, 2019

Re: [Pharo-dev] DrTest - strange UI effect and some feedback

by ducasse

Yes we are not really happy (this is why we will move it to preview for the release since it will probably happen sooner that planned). I also detected that the executable comment execution looks not working. S > On 22 Nov 2019, at 09:15, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > DrTest is integrated into Pharo 8 now - but there seems to be a strange bug > in overlapping widgets when one uses the grouping selection box. > > See attached screenshot. > > I opened an issue for that: https://github.com/pharo-project/pharo/issues/5205 > for Pharo. Dont know if that is known bug or even already fixed in the original repo > of DrTest. Would be good if the authors (Julien or Dayne) could check. > > Additional feedback: > > It's really a nice tool - but I see myself still switching back to old TestRunner again. Me too. :) We all share your analysis. > Two reasons: > > 1. Compared to the regular TestRunner where one is able to see the failing tests > directly in DrTest one always has to have additional clicks in the > grouping tree on the left before getting the final results. > > So the default grouping of the results as a tree could be disturbing because it > requires more clicking around. > > Would be a nice addition if there would be an additional "no grouping" mode as well > so the results are just shown in a list like in reglar TestRunner. > > 2. The old TestRunner had (after filtering the package) an additional useful context menu > with "Select all" and "Select none", "Select inversion", .... which allowed > easier focusing on the test classes I want to check. > Would be nice if a similar one could be added. Yes we agreed on that. Tx torsten > > Thanks > T. > > <drtest.png>

Nov. 22, 2019

DrTest - strange UI effect and some feedback

by Torsten Bergmann

Hi, DrTest is integrated into Pharo 8 now - but there seems to be a strange bug in overlapping widgets when one uses the grouping selection box. See attached screenshot. I opened an issue for that: https://github.com/pharo-project/pharo/issues/5205 for Pharo. Dont know if that is known bug or even already fixed in the original repo of DrTest. Would be good if the authors (Julien or Dayne) could check. Additional feedback: It's really a nice tool - but I see myself still switching back to old TestRunner again. Two reasons: 1. Compared to the regular TestRunner where one is able to see the failing tests directly in DrTest one always has to have additional clicks in the grouping tree on the left before getting the final results. So the default grouping of the results as a tree could be disturbing because it requires more clicking around. Would be a nice addition if there would be an additional "no grouping" mode as well so the results are just shown in a list like in reglar TestRunner. 2. The old TestRunner had (after filtering the package) an additional useful context menu with "Select all" and "Select none", "Select inversion", .... which allowed easier focusing on the test classes I want to check. Would be nice if a similar one could be added. Thanks T.

Nov. 22, 2019

About dashed lines in Athens

by milton mamani

Hi to all I was playing with Athens and I found and error that you can reproduce with the next script in Pharo8x64 macOs ```Smalltalk AthensSurfaceExamples openViewOn: [ :can | can pathTransform restoreAfter: [ can pathTransform translateX: 30 Y: 30. can pathTransform rotateByDegrees: 35. can setPaint: Color red. can setStrokePaint: Color black. can setShape: (-20@ -20 corner: 20@ 20). can draw. ]. ]. AthensSurfaceExamples openViewOn: [ :can | can pathTransform restoreAfter: [ can pathTransform translateX: 30 Y: 30. can pathTransform rotateByDegrees: 35. can setPaint: Color red. (can setStrokePaint: Color black) width: 6; dashes: #(4) offset: 0. can setShape: (-20@ -20 corner: 20@ 20). can draw. ]. ]. AthensSurfaceExamples openViewOn: [ :can | can pathTransform restoreAfter: [ can pathTransform translateX: 30 Y: 30. can pathTransform rotateByDegrees: 35. can setPaint: Color red. can setStrokePaint: Color black. can setShape: (-20@ -20 corner: 20@ 20). can draw. ]. ]. ``` The previous examples opens 3 windows The first the line is normal The second the line is dashed The third one should be normal, but it is dashed Why because there is a cache for the color black in the methods `setStrokePaint:` I think that we need to fix this, Cheers, Milton

Nov. 21, 2019

[Pharo 8.0] Build #999: ProtoObject: #mustBeBooleanDeOptimize

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #999 was: FAILURE. The Pull Request #5195 was integrated: "ProtoObject: #mustBeBooleanDeOptimize" Pull request url: https://github.com/pharo-project/pharo/pull/5195 Issue Url: https://github.com/pharo-project/pharo/issues/ProtoObjectmustBeBooleanDeOpt… Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 21, 2019

Re: [Pharo-dev] GildaVM - a Non-Blocking I/O Architecture for the Cog VM

by pmissech

Hi Ben It was accepted at IWST 2019, so there you go =] https://esug.github.io/2019-Conference/cfpIWST2019.html or direct download linkhttp://esug.github.io/2019-Conference/articles/2019-08-26-IWST19.zip Pierre On 21/11/2019 06:06, Ben Coman wrote: > I saw an interesting tweet on "GildaVM: a Non-Blocking I/O > Architecture for the Cog VM" [1] > which shows the VM running multiple interpreter-threads. > Where is the paper shown on page 23 available? > > Side thought, ifÂ "usually, 1% of objects survive their first > scavenge" [2] > as a "breadth-first traversal of objects from the remembered table (a > table holding all old objects referencing new objects) and the stack" > > that implies only a small percentage object mutations were in old > space (??) > > which makes wonder if each interpreter-thread had its "own" new-space, > then scavenging each new-space could run independently in > parallel-native-threads? > Thus a global lock may only(?) be needed to mutate a shared old-space > and minimizeÂ Â . > > This ignores the execution-engine needing to update method-lookup tables. > Could native-threads start with their own copy of a warmed up JIT and > then work independently? > > cheers -ben > > > [1] > https://www.slideshare.net/esug/gildavm-a-nonblocking-io-architecture-for-t… > > [2] > https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle… > >

Nov. 21, 2019

GildaVM - a Non-Blocking I/O Architecture for the Cog VM

by Ben Coman

I saw an interesting tweet on "GildaVM: a Non-Blocking I/O Architecture for the Cog VM" [1] which shows the VM running multiple interpreter-threads. Where is the paper shown on page 23 available? Side thought, if "usually, 1% of objects survive their first scavenge" [2] as a "breadth-first traversal of objects from the remembered table (a table holding all old objects referencing new objects) and the stack" that implies only a small percentage object mutations were in old space (??) which makes wonder if each interpreter-thread had its "own" new-space, then scavenging each new-space could run independently in parallel-native-threads? Thus a global lock may only(?) be needed to mutate a shared old-space and minimize . This ignores the execution-engine needing to update method-lookup tables. Could native-threads start with their own copy of a warmed up JIT and then work independently? cheers -ben [1] https://www.slideshare.net/esug/gildavm-a-nonblocking-io-architecture-for-t… [2] https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle…

Nov. 21, 2019

[Pharo 8.0] Build #992: 5085-Move-clap-into-BaselineOfBaseLibraries-2

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #992 was: SUCCESS. The Pull Request #5175 was integrated: "5085-Move-clap-into-BaselineOfBaseLibraries-2" Pull request url: https://github.com/pharo-project/pharo/pull/5175 Issue Url: https://github.com/pharo-project/pharo/issues/5085 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 20, 2019

[Pharo 7.0] Build #174: Backport - Fix nextVersion for cases where an entry with basename only exists inâ¦

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #174 was: SUCCESS. The Pull Request #5122 was integrated: "Backport - Fix nextVersion for cases where an entry with basename only exists inâ¦" Pull request url: https://github.com/pharo-project/pharo/pull/5122 Issue Url: https://pharo.fogbugz.com/f/cases/fix Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 20, 2019

[Pharo 8.0] Build #991: spellCheckAstCore

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #991 was: SUCCESS. The Pull Request #5176 was integrated: "spellCheckAstCore" Pull request url: https://github.com/pharo-project/pharo/pull/5176 Issue Url: https://github.com/pharo-project/pharo/issues/spellCheckAstCore Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 20, 2019