- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

by tesonep＠gmail.com

Hi Everyone, I have created the PR in Pharo, so the CI runs the bootstrap with the latest VM (March 15th). Running the process fails during execution of the tests in 32bits OSX. It crashes the VM with a segmentation fault. I could reproduce the crash, running the tests from the command line, and also running OCBytecodeGeneratorTest test. I am attaching the crash.dmp with both executions (from the commandLine and headful), both are in the same point. Cheers, Pablo On Sat, Mar 31, 2018 at 3:52 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > I will try to promote then the one of 15 march. Weâll see next week. > > but then, this is part of my observation: We cannot know which VMs are > > stable, and thatâs because the *process* to make them stable is very > âhuman > > dependentâ: We consider a version stable when it builds on CI and Eliot > says > > is stable. But since Eliot does not use Pharo (not a critic, a reality), > > that may be not true for Pharo. And thatâs actually what happens, Pharo > > crashes. > > Hi esteban > > What would be a way to fix the process and make your work easier? > > If you do not know what can be a release candidate then who can? > We should really improve this situation. > > Stef > > > > I tried to avoid a bit this problem with our fork and nightly builds that > > runs the pharo tests (to knew about problems as early as possible). But > to > > be honest I didnât have the time (and the will) to work on it recently, > then > > pharo fork is in practice stalled. I will revive that eventuallyâ¦ but > just > > when I find the time and the spirit to do it. > > > > > > to one more up to date than 2017 08 27 (in fact more up-to-date than > > opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri > Jan 19 > > 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can > result > > in image corruption in large images, and can occur (as it has here) at > > start-up, causing one's work to be irretrievably lost. > > > > > > Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that are > > triggered either by the automated test suite or the bootstrap process. > > > > > > The blocks I can see at the moment are: > > > > - Multiple builds have failed with an internal compiler error on the > > sista builds. > > -- The earliest occurrence I could find was commit 1f0a7da, but it may > > have been earlier. > > - Even if the Mac builds show success in travis, they aren't making it > > on to files.pharo.org. > > > > > > latest VM copied into files.pharo.org is 16/03. > > we need to see whatâs happening there. > > > > -- I haven't ever worked with this code. > > > > Not directly related, but: > > - Bintray hasn't been updated since 8 March 2018. > > > > > > I think it could also be useful for files.pharo.org to have release > > candidate links available, which would help people to focus testing on > > a particular VM. They would need to be manually maintained, but I > > think the benefits would be worthwhile. > > > > > > all VMs are available to test. > > justâ¦ not available *directly* to general users. > > nowâ¦ I could have a 70rc link in vm subdir. But since I cannot know > which VM > > is RC I find it pointless at this moment. > > > > cheers, > > Esteban > > > > > > > > Cheers, > > Alistair > > > > > > -- Pablo Tesone. tesonep(a)gmail.com

March 31, 2018

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

by Alistair Grant

On Sat, Mar 31, 2018 at 02:42:33PM +0200, Esteban Lorenzano wrote: > > Hi, > > > On 31 Mar 2018, at 11:45, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > On 23 March 2018 at 21:52, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > Pharo urgently needs to upgrade the VM > > > I couldn't agree more, and I know Esteban wants to release a new VM. > I did quite a bit of testing on a VM from 15 March that I thought > would make a good candidate before realising that the Mac VMs aren't > available. > > > I will try to promote then the one of 15 march. We?ll see next week. There were a few builds on the 15th, the VMs I tested were: http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-201… http://files.pharo.org/vm/pharo-spur32/linux/pharo-linux-i386threaded-20180… > but then, this is part of my observation: We cannot know which VMs are stable, > and that?s because the *process* to make them stable is very ?human dependent?: > We consider a version stable when it builds on CI and Eliot says is stable. But > since Eliot does not use Pharo (not a critic, a reality), that may be not true > for Pharo. And that?s actually what happens, Pharo crashes. > I tried to avoid a bit this problem with our fork and nightly builds that runs > the pharo tests (to knew about problems as early as possible). But to be honest > I didn?t have the time (and the will) to work on it recently, then pharo fork > is in practice stalled. I will revive that eventually? but just when I find the > time and the spirit to do it. > > > > to one more up to date than 2017 08 27 (in fact more up-to-date than > opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri > Jan 19 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes > can result in image corruption in large images, and can occur (as it > has here) at start-up, causing one's work to be irretrievably lost. > > > Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that are > triggered either by the automated test suite or the bootstrap process. > > > The blocks I can see at the moment are: > > - Multiple builds have failed with an internal compiler error on the > sista builds. > -- The earliest occurrence I could find was commit 1f0a7da, but it may > have been earlier. > - Even if the Mac builds show success in travis, they aren't making it > on to files.pharo.org. > > > latest VM copied into files.pharo.org is 16/03. > we need to see what?s happening there. > > > -- I haven't ever worked with this code. > > Not directly related, but: > - Bintray hasn't been updated since 8 March 2018. > > > I think it could also be useful for files.pharo.org to have release > candidate links available, which would help people to focus testing on > a particular VM. They would need to be manually maintained, but I > think the benefits would be worthwhile. > > > all VMs are available to test. > just? not available *directly* to general users. > now? I could have a 70rc link in vm subdir. But since I cannot know which VM is > RC I find it pointless at this moment. I didn't mean that we would always be looking to release a new version, but there have been multiple occassions in the past when you've asked people to try a particular VM to see if it solves a problem. In those instances, marking it as RC would make it simpler for others to contribute to the testing and give you more confidence to promote it to stable. Actually, if the link existed all the time, but most of the time it was the same as the stable version, I'd probably just use it as my download link, which would mean that I'm testing the RC whenever it comes out, and stay with it while it is stable and there isn't a new RC. Cheers, Alistair

March 31, 2018

Re: [Pharo-dev] Roadmap to Pharo 7 Release

by Peter UhnÃ¡k

What does this means for end users? I use Glamour extensively... does it mean that I will have to abandon all that code, or just that I need to load Glamour explicitly? Thanks, Peter On Sat, Mar 31, 2018 at 4:01 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Iceberg :) > And all the user of Glamour that are not GT. > > Stef > > On Tue, Mar 27, 2018 at 9:28 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> Since Glamour is not really maintained anymore and source of some > >> leaks and problems, we want to remove any users > >> except GTTools. > > > > > > Can you please provide more info on this? What exactly is going to be > > removed? > > > > Thanks, > > Peter > >

March 31, 2018

Re: [Pharo-dev] Roadmap to Pharo 7 Release

by Stephane Ducasse

Iceberg :) And all the user of Glamour that are not GT. Stef On Tue, Mar 27, 2018 at 9:28 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> Since Glamour is not really maintained anymore and source of some >> leaks and problems, we want to remove any users >> except GTTools. > > > Can you please provide more info on this? What exactly is going to be > removed? > > Thanks, > Peter

March 31, 2018

Re: [Pharo-dev] Calypso: how to see two different methods (without diff) side by side?

by Stephane Ducasse

super! On Tue, Mar 27, 2018 at 11:12 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi Stef. > > I found very simple way how to support it. So maybe next release if there > will be time. > > Best regards, > Denis > > 2018-03-27 21:15 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Hi denis >> >> I do not really use a method diff but I would love to be able to see >> two methods >> side by side. >> >> Stef >> >

March 31, 2018

Re: [Pharo-dev] Why calypso inverse the hierarchy?

by Stephane Ducasse

Hi denis having the selected class or the hiearchy in the other way is both ok for me. On Tue, Mar 27, 2018 at 11:44 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi Stef > > 2018-03-27 23:11 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Hi denis >> >> Calypso asked me where I want to install a method. > > > Normally this dialog appears when you edit a method which class is not > selected in the browser. > For example if you enable superclass method visibility and edit one of > inherited methods. > But give me your scenario. > >> >> And I do not really appreciate that I get the inheritance tree reserved. > > > There is setting for this. And I am not against to change default value or > hardcode this part. > > Originally it was simple list with selected class at the bottom. Then there > was issue The currently edited class should be the first option when > overriding methods. > Idea that first item should be the most common case which is selected class. > At the end I realized that I can easily show hierarchy which I though is > better than simple list. And I reused existing hierarchy from method > visibility list. > > So there are two points for this dialog: > - do we want selected class to be first? > - do we want hierarchical view? > > Best regards, > Denis > >> To me it will destroy students. >> On my own code which is super stupid I had to think twice. I cannot >> image students. >> >> Then when working on code that is not ours it is be super difficult to >> understand anything. >> >> How can I set that superclass should be higher than subclasses? >> >> Stef > >

March 31, 2018

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

by Stephane Ducasse

> I will try to promote then the one of 15 march. Weâll see next week. > but then, this is part of my observation: We cannot know which VMs are > stable, and thatâs because the *process* to make them stable is very âhuman > dependentâ: We consider a version stable when it builds on CI and Eliot says > is stable. But since Eliot does not use Pharo (not a critic, a reality), > that may be not true for Pharo. And thatâs actually what happens, Pharo > crashes. Hi esteban What would be a way to fix the process and make your work easier? If you do not know what can be a release candidate then who can? We should really improve this situation. Stef > I tried to avoid a bit this problem with our fork and nightly builds that > runs the pharo tests (to knew about problems as early as possible). But to > be honest I didnât have the time (and the will) to work on it recently, then > pharo fork is in practice stalled. I will revive that eventuallyâ¦ but just > when I find the time and the spirit to do it. > > > to one more up to date than 2017 08 27 (in fact more up-to-date than > opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri Jan 19 > 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can result > in image corruption in large images, and can occur (as it has here) at > start-up, causing one's work to be irretrievably lost. > > > Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that are > triggered either by the automated test suite or the bootstrap process. > > > The blocks I can see at the moment are: > > - Multiple builds have failed with an internal compiler error on the > sista builds. > -- The earliest occurrence I could find was commit 1f0a7da, but it may > have been earlier. > - Even if the Mac builds show success in travis, they aren't making it > on to files.pharo.org. > > > latest VM copied into files.pharo.org is 16/03. > we need to see whatâs happening there. > > -- I haven't ever worked with this code. > > Not directly related, but: > - Bintray hasn't been updated since 8 March 2018. > > > I think it could also be useful for files.pharo.org to have release > candidate links available, which would help people to focus testing on > a particular VM. They would need to be manually maintained, but I > think the benefits would be worthwhile. > > > all VMs are available to test. > justâ¦ not available *directly* to general users. > nowâ¦ I could have a 70rc link in vm subdir. But since I cannot know which VM > is RC I find it pointless at this moment. > > cheers, > Esteban > > > > Cheers, > Alistair > >

March 31, 2018

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

by Esteban Lorenzano

Hi, > On 31 Mar 2018, at 11:45, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > On 23 March 2018 at 21:52, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Pharo urgently needs to upgrade the VM > > I couldn't agree more, and I know Esteban wants to release a new VM. > I did quite a bit of testing on a VM from 15 March that I thought > would make a good candidate before realising that the Mac VMs aren't > available. I will try to promote then the one of 15 march. Weâll see next week. but then, this is part of my observation: We cannot know which VMs are stable, and thatâs because the *process* to make them stable is very âhuman dependentâ: We consider a version stable when it builds on CI and Eliot says is stable. But since Eliot does not use Pharo (not a critic, a reality), that may be not true for Pharo. And thatâs actually what happens, Pharo crashes. I tried to avoid a bit this problem with our fork and nightly builds that runs the pharo tests (to knew about problems as early as possible). But to be honest I didnât have the time (and the will) to work on it recently, then pharo fork is in practice stalled. I will revive that eventuallyâ¦ but just when I find the time and the spirit to do it. > >> to one more up to date than 2017 08 27 (in fact more up-to-date than opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri Jan 19 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can result in image corruption in large images, and can occur (as it has here) at start-up, causing one's work to be irretrievably lost. > > Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that are > triggered either by the automated test suite or the bootstrap process. > > > The blocks I can see at the moment are: > > - Multiple builds have failed with an internal compiler error on the > sista builds. > -- The earliest occurrence I could find was commit 1f0a7da, but it may > have been earlier. > - Even if the Mac builds show success in travis, they aren't making it > on to files.pharo.org. latest VM copied into files.pharo.org <http://files.pharo.org/> is 16/03. we need to see whatâs happening there. > -- I haven't ever worked with this code. > > Not directly related, but: > - Bintray hasn't been updated since 8 March 2018. > > > I think it could also be useful for files.pharo.org to have release > candidate links available, which would help people to focus testing on > a particular VM. They would need to be manually maintained, but I > think the benefits would be worthwhile. all VMs are available to test. justâ¦ not available *directly* to general users. nowâ¦ I could have a 70rc link in vm subdir. But since I cannot know which VM is RC I find it pointless at this moment. cheers, Esteban > > Cheers, > Alistair

March 31, 2018

[Pharo 7.0-dev] Build #747: 21668-Mark-deprecated-classes-as-deprecated

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

There is a new Pharo build available! The status of the build #747 was: SUCCESS. The Pull Request #1169 was integrated: "21668-Mark-deprecated-classes-as-deprecated" Pull request url: https://github.com/pharo-project/pharo/pull/1169 Issue Url: https://pharo.fogbugz.com/f/cases/21668 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 31, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-03-19

by Juraj Kubelka

Hi Pavel, > On Mar 26, 2018, at 10:37, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: > > Then I started to work on the changes metamodel for Ring with the goal > to be able to record, reproduce and revert (almost) all changes that > the user does in the model. The main goal of it is to be able to get > comparisons of two models and compute loading order of the changes so > it will be more easy to replace the Monticello metamodel and the > metamodel for code differences with a single solid solution based on > Ring. I am interested in playing with the recording-reproduce-and-revert feature. Is it possible? How do you compare it with Epicea? May your work replace Epicea (or part of it) or is it different? Cheers, Juraj

March 31, 2018