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

Re: [Pharo-dev] Versioning with Iceberg

by Shaping

â¦Trying to have 7.0.3 as my base, not 8.0. Iâm not sure what happened with the VM crash, but I can do without the latest version for now. How do I specify the commit with Iceberg? Shaping From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of ducasse Sent: Wednesday, May 29, 2019 10:17 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] Versioning with Iceberg Hello Can you tell us what you are doing? Because if a project loads always the head then iceberg will load it. Or you should specify a specific commit. Stef On 29 May 2019, at 11:07, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: Iâm finding 7.0.3 to be more stable. How do I load a specific baseline/version with Iceberg? Iâm getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0. There are many differences. I want to commit my image changes locally for now on a 7.0.3. Shaping

May 30, 2019

Re: [Pharo-dev] Calypso idea - inherited tests

by Denis Kudriashov

Hi Ben. There are already two features that support inherited tests: - run all tests using class icon: there will be extra red method group "broken tests" which will show failed inherited tests. - toggle inheritance visibility with checkbox in third panel: you will see inherited tests and standard method icon will run them. Is it what you are looking for? or do you need anything else? ÑÑ, 29 Ð¼Ð°Ñ 2019 Ð³., 2:47 Ben Coman <btc(a)openinworld.com>: > (Just a quick share from work before that neuron goes back to sleep and I > forget it...) > > When a number of domain substitute classes need to satisfy the same tests, > its useful to define these in a superclass and have subclasses define > which domain class is being tested e.g. > TestDelaySemaphoreSchedulerMmicrosecondTeicker>>classForScheduler. > > From the Browser "all tests" can be run for each subclass by clicking the > class's test-icon, > but when that goes red, its not visible which individual test failed, and > you can't run an individual test from the Browser. > > In the same way that extension methods are shown in gray, it would be > useful > for inherited tests to be shown in gray, so each has an individual > indication and can be run separately. > > cheers -ben >

May 29, 2019

Re: [Pharo-dev] Versioning with Iceberg

by Ben Coman

On Wed, 29 May 2019 at 23:08, Shaping <shaping(a)uurda.org> wrote: > Iâm finding 7.0.3 to be more stable. > > > > How do I load a specific baseline/version with Iceberg? Iâm getting 8.0 > by default from the cloned local repo, and I prefer not to merge 7.0.3 with > 8.0. There are many differences. I want to commit my image changes > locally for now on a 7.0.3. > > > Its not completely clear what you want. You can right-click a repo > Metacello > Install baseline of..... Or right-click a repo > Repository > Remotes and select one of those branches to check out. cheers -ben

May 29, 2019

Re: [Pharo-dev] Versioning with Iceberg

by ducasse

Hello Can you tell us what you are doing? Because if a project loads always the head then iceberg will load it. Or you should specify a specific commit. Stef > On 29 May 2019, at 11:07, Shaping <shaping(a)uurda.org> wrote: > > Iâm finding 7.0.3 to be more stable. > > How do I load a specific baseline/version with Iceberg? Iâm getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0. There are many differences. I want to commit my image changes locally for now on a 7.0.3. > > Shaping

May 29, 2019

Re: [Pharo-dev] Versioning with Iceberg

by Shaping

Iâm finding 7.0.3 to be more stable. How do I load a specific baseline/version with Iceberg? Iâm getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0. There are many differences. I want to commit my image changes locally for now on a 7.0.3. Shaping

May 29, 2019

VM crash in Pharo 8.0 during save

by Shaping

I made a few cosmetic changes (labels in Calypso). They were working fine. But they were not showing up in Iceberg as changes at some point. Iâd done some earlier tests with Iceberg, and was able to make dummy-method changes, and commit to the local GitHub repo. Everything seemed to work. At some indeterminate point, the changes I made were no longer showing in Iceberg. Further, when I would save, the image would save and quit automatically without actually saving. Iâd relaunch, reapply the changes in the change set (Epicea), and re-save with the same results. When I tried Save Asâ¦ instead, I got the above crash. Also, after relaunch and on reapply, I noticed I was needing to proceed thru deprecated methods to get to a point where I could confirm all changes. AbstractListPresenter>>menu: is the deprecated method. It is hit 3 times after relaunch by the time I get to confirm the changes. The only unusual thing about this install is that I decided to put all on the RAID, not in Documents on the system drive. I had to premake the install folder in Program Files (x86), take ownership, and add permissions to get the install to work (to write files to the folder). (I would like the installer to be more graceful about installing to any folder on Windows. Can we make it so?) Canât run the .msi installer as admin and actually install. It brings up the command line options instead. As far as I can find, there are no Pharo-related files left in the user account/Documents area. I see something in the attached .dmp about a stack overflow. I would enter this bug at https://pharo.fogbugz.com/, but Iâm not sure it would get quick attention there. Shaping

May 29, 2019

Re: [Pharo-dev] Calypso idea - inherited tests

by Guillermo Polito

Hi Ben, > El 29 may 2019, a las 3:46, Ben Coman <btc(a)openinworld.com> escribiÃ³: > > (Just a quick share from work before that neuron goes back to sleep and I forget it...) > > When a number of domain substitute classes need to satisfy the same tests, > its useful to define these in a superclass and have subclasses define which domain class is being tested e.g. TestDelaySemaphoreSchedulerMmicrosecondTeicker>>classForScheduler. For a more complex scenario (but applying to this one too), we use in Spec and Iceberg parametrizable tests. Parametrizable tests define a matrix of values and then create dynamically 1 test case per configuration in the matrix. Still these matrixes do not yet have IDE support. Julien and DaynÃ© have in their roadmap to make an integration with DrTests > > From the Browser "all tests" can be run for each subclass by clicking the class's test-icon, > but when that goes red, its not visible which individual test failed, and you can't run an individual test from the Browser. Yes, Iâve seen this. I run the tests in the TestRunner as a workaround myself. > > In the same way that extension methods are shown in gray, it would be useful > for inherited tests to be shown in gray, so each has an individual indication and can be run separately. > > cheers -ben

May 29, 2019

Calypso idea - inherited tests

by Ben Coman

(Just a quick share from work before that neuron goes back to sleep and I forget it...) When a number of domain substitute classes need to satisfy the same tests, its useful to define these in a superclass and have subclasses define which domain class is being tested e.g. TestDelaySemaphoreSchedulerMmicrosecondTeicker>>classForScheduler. >From the Browser "all tests" can be run for each subclass by clicking the class's test-icon, but when that goes red, its not visible which individual test failed, and you can't run an individual test from the Browser. In the same way that extension methods are shown in gray, it would be useful for inherited tests to be shown in gray, so each has an individual indication and can be run separately. cheers -ben

May 29, 2019

OSX native title bar with Smalltalk balloon

by Ben Coman

I don't have OSX but was watching a user launch a 64bit Pharo 7.0.3 image from PharoLauncher, and noticed the "Smalltalk balloon" showing in its title bar. [image: image.png] I've only the single point of observation, so I'm curious if that is usual? cheers -ben

May 28, 2019

[Pharo 8.0] Build #301: Few fix on the AST

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

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

May 28, 2019