August 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About the infinite debugger

by tesonep＠gmail.com

Yes, we have to check all the scenarios. The problems with the UI process is not resolved at all. On Tue, Aug 7, 2018 at 11:11 PM Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > I have more special cases where debugger hangs: > 19662 > <https://pharo.fogbugz.com/f/cases/19662/Debugger-step-through-mustBeBoolean…> > , 19928 > <https://pharo.fogbugz.com/f/cases/19928/Debugger-step-over-through-last-doI…> > , 20274 > <https://pharo.fogbugz.com/f/cases/20274/Debugger-infinite-recursion-when-te…> > . > They are still relevant > > 2018-08-07 22:01 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> Hi. >> >> Good job guys. I just checked my case 19848 >> <https://pharo.fogbugz.com/f/cases/19848/Step-over-or-though-expression-with…>. >> And it is now fixed. >> >> Thanks >> >> >> >> 2018-06-29 15:48 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >>> Hi all, >>> >>> during today's sprint we have been working with lots of people on the >>> infinite debugger problem (https://pharo.fogbugz.com/f/cases/22085/) >>> We have checked the emails sent in the latest month. Then, together with >>> Quentin, Pablo, Pavel, Yoan we have been discussing and testing hypothesis >>> all day. We have been also comparing the debuggers code between pharo 3/4 >>> (where the bug was is present) and pharo 7, but this was not necessarily >>> straight forward as the code is not the same and there is no easy diff... >>> >>> AAAAND, we have found that the problem may come from a wrong pragma >>> marker. Just removing that pragma gives us back the same behaviour as in >>> Pharo 3/4. :D >>> >>> https://github.com/pharo-project/pharo/pull/1621 >>> >>> I know that the exception handling/debugging has been modified several >>> times in the latest years (some refactorings, hiding contexts...), we >>> unfortunately don't have tests for it, so I'd like some more pair of eyes >>> on it. Ben, Martin could you take a look? >>> >>> Thanks all for the fish, >>> Guille >>> >> >> > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 8, 2018

CI Down

by Guillermo Polito

Hi all, Since yesterday evening, CI is down because of Inria network problems at the level of Paris. Inria tells us that they do not have yet an estimation of how much time it will take to fix it. Until then, there will be no CI testing PRs nor new builds. Previous Pharo builds are still available in http://files.pharo.org/, which is hosted in OVH. I'll keep you updated, Guille

Aug. 8, 2018

Re: [Pharo-dev] Minheadless trial

by Esteban Lorenzano

Hi, > On 8 Aug 2018, at 09:33, Ben Coman <btc(a)openinworld.com> wrote: > > > > On 7 August 2018 at 13:47, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > Hi Ben, > > Sorry for coming here so late, I didnât see this thread before. > I already have a working minheadless branch that was adapted to Eliotâs process. > It was working for Pharo in Linux and Mac (Windows was ongoing but not finished, thatâs why is not pushed). > > You can find this branch here: > > https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm <https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm> > > I'll have a look at it. > > Interesting part is that I didnât tackled any of the issues you are working on, so the work is easily mergeable :) > > Cheers, > Esteban > > Ps: with some changes in image, Iâm using exclusively this VM since a couple of months and it works fine. > > That is good to know. So just to be clear... > even though its name indicates "headless", you are running a full graphical Image? Yes, using SDL2 and OSWindow (with some modifications). Advantages of Pharo investment on this, even in things that seemed useless at the beginning ;) Also, the minheadless VM has a âtraditional displayâ flag that will start a word too. > I got more curious about the original announcement saying... > "minheadless is a VM variant that unifies a lot of the code for Windows, Linux and OS X.â Yes, I like what Ronie did there, even if there is still work to do, but is cool. > > So here https://docs.google.com/spreadsheets/d/183GnSKZSMSEgVQZ0Fqa7-vITqKSpAlW_Axn… <https://docs.google.com/spreadsheets/d/183GnSKZSMSEgVQZ0Fqa7-vITqKSpAlW_Axn…> > I compare... > find "platforms/Win32/vm" -exec wc {} \; > find "platforms/Unix/vm" -exec wc {} \; > find "platforms/Mac OS/vm" -exec wc {} \; > to... > find "platforms/minheadless" -exec wc {} \; > > and if nothing important has been missed it seems about 30% of the original size. > I'd expect Ronie's effort to produce this should have a massive impact on future maintainability. It depends, but this is one of the reasons why we want to move into it. Our strategy is let the less possible in the VM (ideally, just the âcoreâ VM and a great FFI support), and move all the rest into the image. Esteban > > cheers -ben > > P.S. I excluded the following presuming its common before/after. > find "platforms/Cross/vm" -exec wc {} \; > btw, its about half the size of platforms/minheadless.

Aug. 8, 2018

Re: [Pharo-dev] Minheadless trial

by Ben Coman

On 7 August 2018 at 13:47, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Ben, > > Sorry for coming here so late, I didnât see this thread before. > I already have a working minheadless branch that was adapted to Eliotâs > process. > It was working for Pharo in Linux and Mac (Windows was ongoing but not > finished, thatâs why is not pushed). > > You can find this branch here: > > https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm > I'll have a look at it. > Interesting part is that I didnât tackled any of the issues you are > working on, so the work is easily mergeable :) > > Cheers, > Esteban > > Ps: with some changes in image, Iâm using exclusively this VM since a > couple of months and it works fine. > That is good to know. So just to be clear... even though its name indicates "headless", you are running a full graphical Image? I got more curious about the original announcement saying... "minheadless is a VM variant that unifies a lot of the code for Windows, Linux and OS X." So here https://docs.google.com/spreadsheets/d/183GnSKZSMSEgVQZ0Fqa7-vITqKSpAlW_Axn… I compare... find "platforms/Win32/vm" -exec wc {} \; find "platforms/Unix/vm" -exec wc {} \; find "platforms/Mac OS/vm" -exec wc {} \; to... find "platforms/minheadless" -exec wc {} \; and if nothing important has been missed it seems about 30% of the original size. I'd expect Ronie's effort to produce this should have a massive impact on future maintainability. cheers -ben P.S. I excluded the following presuming its common before/after. find "platforms/Cross/vm" -exec wc {} \; btw, its about half the size of platforms/minheadless.

Aug. 8, 2018

Re: [Pharo-dev] About the infinite debugger

by Denis Kudriashov

I have more special cases where debugger hangs: 19662 <https://pharo.fogbugz.com/f/cases/19662/Debugger-step-through-mustBeBoolean…> , 19928 <https://pharo.fogbugz.com/f/cases/19928/Debugger-step-over-through-last-doI…> , 20274 <https://pharo.fogbugz.com/f/cases/20274/Debugger-infinite-recursion-when-te…> . They are still relevant 2018-08-07 22:01 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi. > > Good job guys. I just checked my case 19848 > <https://pharo.fogbugz.com/f/cases/19848/Step-over-or-though-expression-with…>. > And it is now fixed. > > Thanks > > > > 2018-06-29 15:48 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> Hi all, >> >> during today's sprint we have been working with lots of people on the >> infinite debugger problem (https://pharo.fogbugz.com/f/cases/22085/) We >> have checked the emails sent in the latest month. Then, together with >> Quentin, Pablo, Pavel, Yoan we have been discussing and testing hypothesis >> all day. We have been also comparing the debuggers code between pharo 3/4 >> (where the bug was is present) and pharo 7, but this was not necessarily >> straight forward as the code is not the same and there is no easy diff... >> >> AAAAND, we have found that the problem may come from a wrong pragma >> marker. Just removing that pragma gives us back the same behaviour as in >> Pharo 3/4. :D >> >> https://github.com/pharo-project/pharo/pull/1621 >> >> I know that the exception handling/debugging has been modified several >> times in the latest years (some refactorings, hiding contexts...), we >> unfortunately don't have tests for it, so I'd like some more pair of eyes >> on it. Ben, Martin could you take a look? >> >> Thanks all for the fish, >> Guille >> > >

Aug. 7, 2018

Re: [Pharo-dev] About the infinite debugger

by Denis Kudriashov

Hi. Good job guys. I just checked my case 19848 <https://pharo.fogbugz.com/f/cases/19848/Step-over-or-though-expression-with…>. And it is now fixed. Thanks 2018-06-29 15:48 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Hi all, > > during today's sprint we have been working with lots of people on the > infinite debugger problem (https://pharo.fogbugz.com/f/cases/22085/) We > have checked the emails sent in the latest month. Then, together with > Quentin, Pablo, Pavel, Yoan we have been discussing and testing hypothesis > all day. We have been also comparing the debuggers code between pharo 3/4 > (where the bug was is present) and pharo 7, but this was not necessarily > straight forward as the code is not the same and there is no easy diff... > > AAAAND, we have found that the problem may come from a wrong pragma > marker. Just removing that pragma gives us back the same behaviour as in > Pharo 3/4. :D > > https://github.com/pharo-project/pharo/pull/1621 > > I know that the exception handling/debugging has been modified several > times in the latest years (some refactorings, hiding contexts...), we > unfortunately don't have tests for it, so I'd like some more pair of eyes > on it. Ben, Martin could you take a look? > > Thanks all for the fish, > Guille >

Aug. 7, 2018

Re: [Pharo-dev] [rmod] About the infinite debugger

by Tim Mackinnon

Thanks Paul - Iâd forgotten about that option (been using the close all to right option). Itâs just jarring - but worse is that none of the debuggers (even the first one) having anything useful in them... other than the error msg in the title. So you have to start all over again. Still, it sounds like we are honing in on something. Tim Sent from my iPhone > On 7 Aug 2018, at 19:38, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > Hi Tim, > > Just in the event you didn't know there is an option in the World menu to > close all the open debuggers. > > Its in the "Windows" section, about half way down. > > > Paul > > > > Tim Mackinnon wrote >> ... >> >> On the plus side - its rare that you crash you image and then have to >> recover changes - but its just annoying when it gets in the way of >> debugging. ITs not just all the windows, its also the fact that none of >> the debugger windows actually puts you in a useful stack where you can see >> the problem - they are all stuck on DNU with a single line stack. >> >> Tim >> >> ... > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Aug. 7, 2018

Re: [Pharo-dev] Iceberg: Cannot Clone Pharo Repository

by Eric Gade

This workaround has done the trick for me for the moment (for anyone reading: you clone manually and then in Iceberg select the repository from the local filesystem). However, I'm now getting a new authentication error when trying to clone directly from my updated fork (instead of loading from filesystem). It claims I have not provided a valid set of credentials and that I should link to my ssh key or use HTTPS as the fetch method. Problem is, I've selected HTTPS already! I'm attaching a screenshot. On Mon, Aug 6, 2018 at 4:27 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > As a workaround, maybe you can try updating your fork before cloning it > from Iceberg? > > $ git clone yourFork > $ git pull from-pharo > $ git push > > On Mon, Aug 6, 2018 at 10:26 AM Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi Eric, >> >> Thanks for the report. I'm looking into it. >> >> On Sun, Aug 5, 2018 at 6:20 PM Eric Gade <eric.gade(a)gmail.com> wrote: >> >>> I am having (new) issues cloning my forked pharo repository in a fresh >>> P7 image for development. Git objects are pulled from the repository >>> successfully, but during the checkout phase the error posted below occurs >>> (I can also provide a fuel dump by request). >>> >>> Here is my current system: >>> OSX 10.13.1 (High Sierra) >>> Pharo 7.0 >>> Build information: Pharo-7.0+alpha.build.1159.sha. >>> 65cff7b3c78af7ecf3728abdd2f44bf0cbc8a548 (32 Bit) >>> >>> My fork: >>> https://github.com/darth-cheney/pharo >>> >>> Error Stack: >>> >>> ``` >>> IceUnknownCommit(Object)>>doesNotUnderstand: #adopt >>> IcePharoPlugin>>repositoryWillBeCreated: >>> [ :each | each repositoryWillBeCreated: aRepository ] in >>> IcePluginManager>>repositoryWillBeCreated: in Block: [ :each | each >>> repositoryWillBeCreated: aRepositor...etc... >>> Array(SequenceableCollection)>>do: >>> IcePluginManager>>repositoryWillBeCreated: >>> IceRepositoryCreator>>cloneRepository >>> [ self validate. >>> self isCloning >>> ifTrue: [ self cloneRepository ] >>> ifFalse: [ self addLocalRepository ] ] in IceRepositoryCreator>>createRepository >>> in Block: [ self validate.... >>> BlockClosure>>on:do: >>> IceRepositoryCreator>>createRepository >>> [ ^ IceRepositoryCreator new >>> repository: repository; >>> remote: (IceGitRemote url: self remoteUrl); >>> location: self projectLocation location; >>> createRepository ] in IceTipGitHubRepositoryPanel( >>> IceTipGitRepositoryPanel)>>newRepository in Block: [ ^ >>> IceRepositoryCreator new... >>> [ :bar | >>> bar label: aString. >>> aBlock value ] in MorphicUIManager(UIManager)>>informUser:during: in >>> Block: [ :bar | ... >>> [ :bar | aBlock value: bar ] in MorphicUIManager>>informUserDuring: in >>> Block: [ :bar | aBlock value: bar ] >>> BlockClosure>>cull: >>> [ ^ block cull: self ] in [ self prepareForRunning. >>> CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run in >>> Block: [ ^ block cull: self ] >>> [ activeProcess psValueAt: index put: anObject. >>> aBlock value ] in CurrentJob(DynamicVariable)>>value:during: in Block: >>> [ activeProcess psValueAt: index put: anObject.... >>> BlockClosure>>ensure: >>> CurrentJob(DynamicVariable)>>value:during: >>> CurrentJob class(DynamicVariable class)>>value:during: >>> [ self prepareForRunning. >>> CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run in >>> Block: [ self prepareForRunning.... >>> BlockClosure>>ensure: >>> Job>>run >>> MorphicUIManager(UIManager)>>displayProgress:from:to:during: >>> MorphicUIManager>>informUserDuring: >>> MorphicUIManager(UIManager)>>informUser:during: >>> IceTipGitHubRepositoryPanel(IceTipGitRepositoryPanel)>>newRepository >>> IceTipGitHubRepositoryPanel>>newRepository >>> IceTipRegisterRepositoryDialog>>doAccept >>> [ self doAccept. >>> true ] in IceTipRegisterRepositoryDialog(IceTipOptionDialog)>>accept in >>> Block: [ self doAccept.... >>> BlockClosure>>on:do: >>> IceTipRegisterRepositoryDialog(IceTipOptionDialog)>>accept >>> ``` >>> >>> -- >>> Eric >>> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 > -- Eric

Aug. 7, 2018

Re: [Pharo-dev] [rmod] About the infinite debugger

by Paul DeBruicker

Hi Tim, Just in the event you didn't know there is an option in the World menu to close all the open debuggers. Its in the "Windows" section, about half way down. Paul Tim Mackinnon wrote > ... > > On the plus side - its rare that you crash you image and then have to > recover changes - but its just annoying when it gets in the way of > debugging. ITs not just all the windows, its also the fact that none of > the debugger windows actually puts you in a useful stack where you can see > the problem - they are all stuck on DNU with a single line stack. > > Tim > > ... -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 7, 2018

Re: [Pharo-dev] New Iceberg Version 1.2.1

by tesonep＠gmail.com

Only adding a small detail, the Metacello expression is used to generate the project that is offered. Also I see it as the Detached head status for projects that are loaded using Metacello. Maybe we should display the dirtiness in other way, but I think that is not a problem. It is normal that a project is marked dirty while used. Cheers On Tue, Aug 7, 2018 at 4:01 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi, > > I'll write down some of the reasons of the project's design, like that I > can afterwards copy paste it in the wiki :). > > First, this design did not came up from an egg. We worked on it for about > two months. And it is thought to be backwards compatible and manage lots of > metacello particularities. It may have things that are perfectible, sure, > so let's discuss it. > > One of the main problems we saw in metacello, and that Iceberg inherited, > was the "source subdirectory" thing. This source directory had to be > specified in the CLIENT, meaning that every time we clone a repository we > should know by heart the directory chose by its developer. Moreover, we > lack a standard way to do it, so everybody does as he feels (root > directory, src, source, repository, mc....). > > This has some bad consequences: > - once a repository is referenced by some other project, it is more > complicated to change its source directory. Imagine that tomorrow we set as > standard that all git repos should have the code in src. Then voyage should > change. And all its clients too. > - Making a typo in the code subdirectory means sometimes super ugly > errors from metacello that are difficult to debug and understand (e.g., > "Cannot resolve BaselineOfMetacello WTF") > > Moreover, there was another problem that people started stumbling on: the > fact that iceberg got confused sometimes thinking that an empty project was > in filetree (to keep backwards compatibility with projects without a > .properties). > > So we decided that for this release we wanted to revert a bit that > situation. Think object: let's put the meta-data used to interpret a > project's structure inside the project itself. > The idea is that: > > - each project should contain both a .project and a .properties file. The > first can contain arbitrary project meta-data (such as the source > directory). The second contains the cypress properties, which are needed to > correctly interpret the code inside the source directory. > - a project without a .project file is an old project and cannot be > interpreted, because we don't know the source directory > - a project without a .properties file is an old project and is by > default transformed in a project with a #filetree properties file > - an old project cloned from iceberg detects the missing .project file > and gives the user the opportunity to declare it (and then commit it > explicitly) > - an old project cloned and loaded from a Metacello expression defining a > source directory will honnor the source directory defined in the Metacello > expression (for backwards compatibility, and we have ~500 tests about this). > > # About defaults values / forcing the user to define a project > > First, notice that even when the repositories you load are just marked as > "dirty". > This is because in memory we add a project to your repository. > But you're not forced to commit it. > Actually, you can still load packages and baselines from that repository > without committing. > > This is in line with Iceberg's "explicitness". We try to not do any > destructive operation without asking the user first (that's why we have > several preview windows for pushing, pulling, checkout, merge..., and why > contrastingly with monticello we show the committed changes on the commit > window...). So, instead of transparently "adding the file" we have decided > to modify the project in memory and let the user the responsibility to > commit that file. > > If there's a drawback, is that the repository is marked as dirty. Which is > a bit noisy, yes, but still I think it's not so bad compared with the > previous drawbacks. > To solve this, we could have some default values, yes, and only mark it as > dirty if the project does not follow the default value. > This could work, but right now all projects use different names for their > source directories. > So the question is, what would be a good default? I'd like to use 'src' > since this is short, well known and less alien (all these in the sense that > we do not lose anything and we have a lot to gain by using it). > However, not much repositories use 'src' so it will still produce a lot of > "noise"... > > But still! Committing that file is a one-time operation. Once people fix > their repositories adding the project meta-data, you will not see them > dirty anymore. So we can see this as a transition noise too... > > Of course, new ideas are welcome. I'll let Pablo and Esteban add their > points of view on this too. > Guille > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 7, 2018

Re: [Pharo-dev] New Iceberg Version 1.2.1

by Guillermo Polito

Hi, I'll write down some of the reasons of the project's design, like that I can afterwards copy paste it in the wiki :). First, this design did not came up from an egg. We worked on it for about two months. And it is thought to be backwards compatible and manage lots of metacello particularities. It may have things that are perfectible, sure, so let's discuss it. One of the main problems we saw in metacello, and that Iceberg inherited, was the "source subdirectory" thing. This source directory had to be specified in the CLIENT, meaning that every time we clone a repository we should know by heart the directory chose by its developer. Moreover, we lack a standard way to do it, so everybody does as he feels (root directory, src, source, repository, mc....). This has some bad consequences: - once a repository is referenced by some other project, it is more complicated to change its source directory. Imagine that tomorrow we set as standard that all git repos should have the code in src. Then voyage should change. And all its clients too. - Making a typo in the code subdirectory means sometimes super ugly errors from metacello that are difficult to debug and understand (e.g., "Cannot resolve BaselineOfMetacello WTF") Moreover, there was another problem that people started stumbling on: the fact that iceberg got confused sometimes thinking that an empty project was in filetree (to keep backwards compatibility with projects without a .properties). So we decided that for this release we wanted to revert a bit that situation. Think object: let's put the meta-data used to interpret a project's structure inside the project itself. The idea is that: - each project should contain both a .project and a .properties file. The first can contain arbitrary project meta-data (such as the source directory). The second contains the cypress properties, which are needed to correctly interpret the code inside the source directory. - a project without a .project file is an old project and cannot be interpreted, because we don't know the source directory - a project without a .properties file is an old project and is by default transformed in a project with a #filetree properties file - an old project cloned from iceberg detects the missing .project file and gives the user the opportunity to declare it (and then commit it explicitly) - an old project cloned and loaded from a Metacello expression defining a source directory will honnor the source directory defined in the Metacello expression (for backwards compatibility, and we have ~500 tests about this). # About defaults values / forcing the user to define a project First, notice that even when the repositories you load are just marked as "dirty". This is because in memory we add a project to your repository. But you're not forced to commit it. Actually, you can still load packages and baselines from that repository without committing. This is in line with Iceberg's "explicitness". We try to not do any destructive operation without asking the user first (that's why we have several preview windows for pushing, pulling, checkout, merge..., and why contrastingly with monticello we show the committed changes on the commit window...). So, instead of transparently "adding the file" we have decided to modify the project in memory and let the user the responsibility to commit that file. If there's a drawback, is that the repository is marked as dirty. Which is a bit noisy, yes, but still I think it's not so bad compared with the previous drawbacks. To solve this, we could have some default values, yes, and only mark it as dirty if the project does not follow the default value. This could work, but right now all projects use different names for their source directories. So the question is, what would be a good default? I'd like to use 'src' since this is short, well known and less alien (all these in the sense that we do not lose anything and we have a lot to gain by using it). However, not much repositories use 'src' so it will still produce a lot of "noise"... But still! Committing that file is a one-time operation. Once people fix their repositories adding the project meta-data, you will not see them dirty anymore. So we can see this as a transition noise too... Of course, new ideas are welcome. I'll let Pablo and Esteban add their points of view on this too. Guille

Aug. 7, 2018

[Pharo 7.0-dev] Build #1161: Modified the code to be similar to #select:thenDo:.

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

There is a new Pharo build available! The status of the build #1161 was: SUCCESS. The Pull Request #1651 was integrated: "Modified the code to be similar to #select:thenDo:." Pull request url: https://github.com/pharo-project/pharo/pull/1651 Issue Url: https://pharo.fogbugz.com/f/cases/22282 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 7, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #1160: Integrating Iceberg v1.2.1

by Esteban Lorenzano

yes. I find the message (SUCCESS or FAILURE) a bit misleading: it means some tests failed (usually the ones related to network problems). Cheers, Esteban > On 7 Aug 2018, at 12:32, Norbert Hartl <norbert(a)hartl.name> wrote: > > Is it the case that as soon as a mail like this (letâs assume it would have been a success) arrives at the mailing list there is a new pharo image on get.pharo.org <http://get.pharo.org/> that has it? > > Norbert > >> Am 07.08.2018 um 12:07 schrieb ci-pharo-ci-jenkins2(a)inria.fr <mailto:ci-pharo-ci-jenkins2@inria.fr>: >> >> There is a new Pharo build available! >> >> The status of the build #1160 was: FAILURE. >> >> The Pull Request #1672 was integrated: "Integrating Iceberg v1.2.1" >> Pull request url: https://github.com/pharo-project/pharo/pull/1672 <https://github.com/pharo-project/pharo/pull/1672> >> >> Issue Url: https://pharo.fogbugz.com/f/cases/22297 <https://pharo.fogbugz.com/f/cases/22297> >> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >

Aug. 7, 2018

Re: [Pharo-dev] Minheadless trial

by Ben Coman

On 7 August 2018 at 13:22, Ben Coman <btc(a)openinworld.com> wrote: > > > Next is to try loading an Image. > + Downloaded and unzipped http://files.pharo.org/image/7 0/latest-minimal-64.zip + In Visual Studio, right-clicked CMakeLists.txt > Debug and Launch Settings > pharo.exe + Edited the presented "launch.vs.json" as follows... { "version": "0.2.1", "defaults": {}, "configurations": [ { "type": "default", "project": "CMakeLists.txt", "projectTarget": "pharo.exe (dist\\pharo.exe)", "name": "pharo.exe with image (dist\\pharo.exe)", "args": [ "C:\\#Dev\\latest-minimal-64\\Pharo7.0-metacello-64bit-65cff7b.image", "s" ] }, ] } Now running "x64-Debug" and "pharo.exe with image" I find it gets hung up in... sqAllocateMemory(usqInt minHeapSize, usqInt desiredHeapSize) in call... alloc = sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto (roundUpToPage(desiredHeapSize), address, &allocBytes); with... desiredHeapSize ==> 39583744 (~39MB) address ==> 0x00007ff7d6e00000 where inside that call... void *sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto(sqInt size, void *minAddress, sqInt *allocatedSizePointer)" has... size ==> 39583744 minAddress ==> 0x00007ff7d6e00000 address ==> 0x00000000d6e00000 bytes ==> 39583744 (~39MB) delta ==> 1048576 it gets stuck the following loop... https://github.com/bencoman/opensmalltalk-vm/blob/8231b96f9b/platforms/win3… while ((usqIntptr_t)(address + bytes) > (usqIntptr_t)address) { alloc = VirtualAlloc(address, bytes, MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE); ... if (alloc >= (char *)minAddress) && (alloc <= address + delta)) return alloc; ... address += delta; } where... alloc ==> 0x00000000d6e00000 (alloc >= (char *)minAddress) ==> false. which is effectively... (does this seem normal?) ((char *)minAddress-address)/delta ==> 134,180,864 loops before exit. but... (alloc >= (char *)address) ==> true. would exit on the first pass of the loop, except... /* For some reason (large page support?) we can ask for a page-aligned * address such as 0xNNNNf000 but VirtualAlloc will answer 0xNNNN0000. * So accept allocs above minAddress rather than allocs above address */ where back one level "minAddress" is derived like this... /* choose a suitable starting point. In MinGW the malloc heap is below the * program, so take the max of a malloc and something form uninitialized * data. */ hint = malloc(1); free(hint); hint = max(hint,(char *)&fIsConsole); address = (char *)(((usqInt)hint + alignment - 1) & ~(alignment - 1)); address passed-by-value into minAddress Now I'm out of my depth trying to understand the background on that logic, but if I blindly change the loop exit condition from... (alloc >= (char *)minAddress) to... (alloc >= (char *)address) then osvm_loadImage(tempImageNameAttempt() and subsequently osvm_loadDefaultImage() succeed. So some expert attention would be good here (as time permits) In the meantime, I'll forge ahead to play with osvm_run(); cheers -ben P.S. making "#define printProbes 1" and "fIsConsole = 1;" shows... probing [00000000D6E00000,00000000D93C0000) probing [00000000D6F00000,00000000D94C0000) probing [00000000D7000000,00000000D95C0000) probing [00000000D7100000,00000000D96C0000) probing [00000000D7200000,00000000D97C0000) probing [00000000D7300000,00000000D98C0000) probing [00000000D7400000,00000000D99C0000) probing [00000000D7500000,00000000D9AC0000) probing [00000000D7600000,00000000D9BC0000)

Aug. 7, 2018

Re: [Pharo-dev] Minheadless trial

by Tim Mackinnon

Guys - do keep pushing on this - I think its quite important in this world of serverlessâ¦ it shows we are very relevant. +10 > On 7 Aug 2018, at 13:36, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Iâm slowly working on that VM because we want it to be the default for Pharo 8. > In our vision, it should be a responsibility of the image to start or not a graphical UI, so we are preparing (we have been preparing to it for years, actually) to achieve this behaviour. > To make this work, we need all platforms covered (and another huge quantity of changes here and there). > Anyway, I didnât merge because I wanted to have win64 covered, not just what we have now, and since no-one was using that VM I didnât feel pression to do it :) > > Cheers, > Esteban > > >> On 7 Aug 2018, at 08:50, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >> >> What keeps you from doing a pull request to opensmalltalk-vm ? >> >> Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> >>> Hi Ben, >>> >>> Sorry for coming here so late, I didnât see this thread before. >>> I already have a working minheadless branch that was adapted to Eliotâs process. >>> It was working for Pharo in Linux and Mac (Windows was ongoing but not finished, thatâs why is not pushed). >>> >>> You can find this branch here: >>> >>> https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm <https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm> >>> >>> Interesting part is that I didnât tackled any of the issues you are working on, so the work is easily mergeable :) >>> >>> Cheers, >>> Esteban >>> >>> Ps: with some changes in image, Iâm using exclusively this VM since a couple of months and it works fine. >>> >>> >>>> On 7 Aug 2018, at 07:22, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>>> >>>> On 7 August 2018 at 05:12, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >>>> >>>> Hi Ben, >>>> Feel free to make this edit and commit >>>> >>>> I'm pushing changes here... >>>> https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-… <https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-…> >>>> >>>> and the diff can be tracked here... >>>> https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless..… <https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless..…> >>>> >>>> >>>> ------------------------ >>>> On 6 August 2018 at 13:22, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>>> On 6 August 2018 at 11:50, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>>> >>>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… <https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea…> >>>> typedef HRESULT WINAPI (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>> C2059 sqPlatformSpecific-Win32.c:80 syntax error: '(' >>>> E0651 a calling convention may not be followed by a nested declarator. >>>> >>>> The following change reduces build errors to 1... >>>> typedef HRESULT (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>> >>>> but I'm not sure of the implications. >>>> >>>> I found the correct solution to this... >>>> "The trick is placing the [call declaration] inside the parentheses" >>>> https://stackoverflow.com/questions/4830355/function-pointer-and-calling-co… <https://stackoverflow.com/questions/4830355/function-pointer-and-calling-co…> >>>> >>>> i.e. the following compiles cleanly >>>> typedef HRESULT (WINAPI *SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>> >>>> >>>> ----------------------------- >>>> Now running the VM (without parameters) I get... >>>> Debug Assertion Failed! >>>> Program: ...\x64-Debug\dist\pharo.exe >>>> File: minkernel\crts\ucrt\src\appcrt\tran\amd64\ieee.c >>>> Line: 106 >>>> Expression: (mask&~(_MCW_DN | _MCW_EM | _MCW_RC))==0 >>>> >>>> at the call to _controlfp(FPU_DEFAULT, _MCW_EM | _MCW_RC | _MCW_PC | _MCW_IC); >>>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… <https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea…> >>>> >>>> >>>> According to https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx <https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx> >>>> x64 does not support _MCW_PC or _MCW_IC >>>> but I'm clueless about the implications of these FPU flags. >>>> Could our math guys please advise? >>>> >>>> Eliminating those two flags allows a VM run successfully without loading an Image. >>>> i.e. it successfully passes... >>>> osvm_initialize(); >>>> osvm_parseCommandLineArguments(argc, argv); >>>> osvm_initializeVM(); >>>> >>>> Next is to try loading an Image. >>>> >>>> cheers -ben >>> >

Aug. 7, 2018

Re: [Pharo-dev] Minheadless trial

by Esteban Lorenzano

Iâm slowly working on that VM because we want it to be the default for Pharo 8. In our vision, it should be a responsibility of the image to start or not a graphical UI, so we are preparing (we have been preparing to it for years, actually) to achieve this behaviour. To make this work, we need all platforms covered (and another huge quantity of changes here and there). Anyway, I didnât merge because I wanted to have win64 covered, not just what we have now, and since no-one was using that VM I didnât feel pression to do it :) Cheers, Esteban > On 7 Aug 2018, at 08:50, Norbert Hartl <norbert(a)hartl.name> wrote: > > What keeps you from doing a pull request to opensmalltalk-vm ? > > Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > >> Hi Ben, >> >> Sorry for coming here so late, I didnât see this thread before. >> I already have a working minheadless branch that was adapted to Eliotâs process. >> It was working for Pharo in Linux and Mac (Windows was ongoing but not finished, thatâs why is not pushed). >> >> You can find this branch here: >> >> https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm <https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm> >> >> Interesting part is that I didnât tackled any of the issues you are working on, so the work is easily mergeable :) >> >> Cheers, >> Esteban >> >> Ps: with some changes in image, Iâm using exclusively this VM since a couple of months and it works fine. >> >> >>> On 7 Aug 2018, at 07:22, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>> >>> On 7 August 2018 at 05:12, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >>> >>> Hi Ben, >>> Feel free to make this edit and commit >>> >>> I'm pushing changes here... >>> https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-… <https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-…> >>> >>> and the diff can be tracked here... >>> https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless..… <https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless..…> >>> >>> >>> ------------------------ >>> On 6 August 2018 at 13:22, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>> On 6 August 2018 at 11:50, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>> >>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… <https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea…> >>> typedef HRESULT WINAPI (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>> C2059 sqPlatformSpecific-Win32.c:80 syntax error: '(' >>> E0651 a calling convention may not be followed by a nested declarator. >>> >>> The following change reduces build errors to 1... >>> typedef HRESULT (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>> >>> but I'm not sure of the implications. >>> >>> I found the correct solution to this... >>> "The trick is placing the [call declaration] inside the parentheses" >>> https://stackoverflow.com/questions/4830355/function-pointer-and-calling-co… <https://stackoverflow.com/questions/4830355/function-pointer-and-calling-co…> >>> >>> i.e. the following compiles cleanly >>> typedef HRESULT (WINAPI *SetProcessDpiAwarenessFunctionPointer) (int awareness); >>> >>> >>> ----------------------------- >>> Now running the VM (without parameters) I get... >>> Debug Assertion Failed! >>> Program: ...\x64-Debug\dist\pharo.exe >>> File: minkernel\crts\ucrt\src\appcrt\tran\amd64\ieee.c >>> Line: 106 >>> Expression: (mask&~(_MCW_DN | _MCW_EM | _MCW_RC))==0 >>> >>> at the call to _controlfp(FPU_DEFAULT, _MCW_EM | _MCW_RC | _MCW_PC | _MCW_IC); >>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… <https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea…> >>> >>> >>> According to https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx <https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx> >>> x64 does not support _MCW_PC or _MCW_IC >>> but I'm clueless about the implications of these FPU flags. >>> Could our math guys please advise? >>> >>> Eliminating those two flags allows a VM run successfully without loading an Image. >>> i.e. it successfully passes... >>> osvm_initialize(); >>> osvm_parseCommandLineArguments(argc, argv); >>> osvm_initializeVM(); >>> >>> Next is to try loading an Image. >>> >>> cheers -ben >>

Aug. 7, 2018

Re: [Pharo-dev] New Iceberg Version 1.2.1

by Norbert Hartl

Forgot one thing. I find the new project feature quite intrusive. It will add those file to all repos unasked. So I have a lot of dirty projects I have no write access to. How is this supposed to work. Isnât it better to assume defaults and add an option to add project files? Norbert > Am 07.08.2018 um 12:05 schrieb tesonep(a)gmail.com: > > New Iceberg Version 1.2.1 [https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0 <https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0> + https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1 <https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1>] > Thanks to all brave users, issue reporters, and contributors :). > > This version includes the implementation of projects. > Projects are a way of defining basic metadata of the repository. > Now, this metadata just includes the source directory. > > This means that people do not need anymore to provide ALL THE TIME the source directory. > Instead, every repository includes a project file that provides it. > Iceberg will guide people to create the given file. This file is managed by Iceberg and people should not touch it from the outside or accept the consequences :). > > This version is integrated in the latest Pharo 7 images. > > #New Features > > - #866 Introduce first version of Projects > > #Infrastructure > > - #870 Improving tests of Metacello Integration > - #903 Split basic tests from metacello tests in CI > - #914 Sync Wiki with documentation directory automatically > - #934 Manually check metacello integration dialogs > - #935 Try to refrite the metacello integration tests. > - #940 Installation in new Pharo should also bootstrap pharo repository > > #Enhancements > > - #675 The History of a Method in Calypso should show a progress bar. > - #788 Show progress during network operations (fetch,push, ...) Libgit. > - #875 Tonel plugin does not delete .filetree Migration > - #897 Update to OSSubprocess 1.0.1 > - #911 Repair Checkout branch should appear in "no project found" > - #933 Fix Edit repository dialog > - #939 IceInteractiveErrorVisitor duplicates IceTipInteractiveErrorVisitor > - #944 Extract pharo repository bootstrap code into iceberg > > #Bug Fixes > > - #828 Convert sources to tonel raises an Exception > - #839 Infinite loop in IceGitLocalRepositoryType if the path is wrong > - #849 VM crash while saving credentials Credential Manager > - #851 .properties file is not create if project is imported and not cloned. > - #869 Error msg after an http timeout is unreadable > - #873 Error with credential provider Credential Manager > - #874 The integration with Metacello does not work when there is a src directory, but not project file. > - #880 Putting "." in project src field gives dnu > - #884 Edit Project Dialog tries to select 'src' folder as default, but does not handle if it does not exists > - #886 Edit Project Dialog does not allow to select the root of the repository as source directory > - #888 Could not locate repository does not have subdirectory anymore. > - #889 Loading an unborn project through metacello does not work > - #894 GitHubAPI fails when the API responds with a 204 No Content > - #901 I get a DNU projectName.... > - #902 Edit project metadata does not detect default format > - #918 Cloning pharo from a sync'ed repository does not correctly show dirty packages > - #928 Pull request cancel > - #930 Changed ivar/slot name in stateful trait not recognized as a change > - #931 DNU when trying to unload an Iceberg pkg where underlying Pharo pkg has been removed > - #932 Pharo repository forgets packages > - #938 Do not catch assertion failures > - #941 Iceberg pre-installed repository has wrong repair action > - #946 Fixing Metacello Integration Tests > - #948 Cloning from github creates an invalid remote > - #950 Iceberg v1.2.0 breaks projects Metacello Integration bug > - #951 New project window should be coherent on the vocabulary UI enhancement > - #953 Make remote request anonymous enhancement > - #952 Cannot Clone Pharo Repository Pharo plugin bug > - #955 Repair actions for repositories with fetch required are wrong UI bug > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com>

Aug. 7, 2018

Re: [Pharo-dev] New Iceberg Version 1.2.1

by Norbert Hartl

Great, thanks! I used 1.2.0 a few days ago and I had some problems: - some repos like voyage had a .properties file in the repo with content â{}â. This made the repo unusable. The only thing noticed is that in the repo view in iceberg the packages were named Voyage-Core.package instead of Voyage-Core - I had a problem that I cherry picked changes in my project and commited but then all other changes were gone, too. I need to revert and then reapply the changes with epicea in order to have it in iceberg. It can be it was influenced by the above problem but I need to check again which I will. Norbert > Am 07.08.2018 um 12:05 schrieb tesonep(a)gmail.com: > > New Iceberg Version 1.2.1 [https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0 <https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0> + https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1 <https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1>] > Thanks to all brave users, issue reporters, and contributors :). > > This version includes the implementation of projects. > Projects are a way of defining basic metadata of the repository. > Now, this metadata just includes the source directory. > > This means that people do not need anymore to provide ALL THE TIME the source directory. > Instead, every repository includes a project file that provides it. > Iceberg will guide people to create the given file. This file is managed by Iceberg and people should not touch it from the outside or accept the consequences :). > > This version is integrated in the latest Pharo 7 images. > > #New Features > > - #866 Introduce first version of Projects > > #Infrastructure > > - #870 Improving tests of Metacello Integration > - #903 Split basic tests from metacello tests in CI > - #914 Sync Wiki with documentation directory automatically > - #934 Manually check metacello integration dialogs > - #935 Try to refrite the metacello integration tests. > - #940 Installation in new Pharo should also bootstrap pharo repository > > #Enhancements > > - #675 The History of a Method in Calypso should show a progress bar. > - #788 Show progress during network operations (fetch,push, ...) Libgit. > - #875 Tonel plugin does not delete .filetree Migration > - #897 Update to OSSubprocess 1.0.1 > - #911 Repair Checkout branch should appear in "no project found" > - #933 Fix Edit repository dialog > - #939 IceInteractiveErrorVisitor duplicates IceTipInteractiveErrorVisitor > - #944 Extract pharo repository bootstrap code into iceberg > > #Bug Fixes > > - #828 Convert sources to tonel raises an Exception > - #839 Infinite loop in IceGitLocalRepositoryType if the path is wrong > - #849 VM crash while saving credentials Credential Manager > - #851 .properties file is not create if project is imported and not cloned. > - #869 Error msg after an http timeout is unreadable > - #873 Error with credential provider Credential Manager > - #874 The integration with Metacello does not work when there is a src directory, but not project file. > - #880 Putting "." in project src field gives dnu > - #884 Edit Project Dialog tries to select 'src' folder as default, but does not handle if it does not exists > - #886 Edit Project Dialog does not allow to select the root of the repository as source directory > - #888 Could not locate repository does not have subdirectory anymore. > - #889 Loading an unborn project through metacello does not work > - #894 GitHubAPI fails when the API responds with a 204 No Content > - #901 I get a DNU projectName.... > - #902 Edit project metadata does not detect default format > - #918 Cloning pharo from a sync'ed repository does not correctly show dirty packages > - #928 Pull request cancel > - #930 Changed ivar/slot name in stateful trait not recognized as a change > - #931 DNU when trying to unload an Iceberg pkg where underlying Pharo pkg has been removed > - #932 Pharo repository forgets packages > - #938 Do not catch assertion failures > - #941 Iceberg pre-installed repository has wrong repair action > - #946 Fixing Metacello Integration Tests > - #948 Cloning from github creates an invalid remote > - #950 Iceberg v1.2.0 breaks projects Metacello Integration bug > - #951 New project window should be coherent on the vocabulary UI enhancement > - #953 Make remote request anonymous enhancement > - #952 Cannot Clone Pharo Repository Pharo plugin bug > - #955 Repair actions for repositories with fetch required are wrong UI bug > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com>

Aug. 7, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #1160: Integrating Iceberg v1.2.1

by Norbert Hartl

Is it the case that as soon as a mail like this (letâs assume it would have been a success) arrives at the mailing list there is a new pharo image on get.pharo.org <http://get.pharo.org/> that has it? Norbert > Am 07.08.2018 um 12:07 schrieb ci-pharo-ci-jenkins2(a)inria.fr: > > There is a new Pharo build available! > > The status of the build #1160 was: FAILURE. > > The Pull Request #1672 was integrated: "Integrating Iceberg v1.2.1" > Pull request url: https://github.com/pharo-project/pharo/pull/1672 > > Issue Url: https://pharo.fogbugz.com/f/cases/22297 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 7, 2018

[Pharo 7.0-dev] Build #1160: Integrating Iceberg v1.2.1

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

There is a new Pharo build available! The status of the build #1160 was: FAILURE. The Pull Request #1672 was integrated: "Integrating Iceberg v1.2.1" Pull request url: https://github.com/pharo-project/pharo/pull/1672 Issue Url: https://pharo.fogbugz.com/f/cases/22297 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 7, 2018

New Iceberg Version 1.2.1

by tesonep＠gmail.com

New Iceberg Version 1.2.1 [ https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0 + https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1] Thanks to all brave users, issue reporters, and contributors :). This version includes the implementation of projects. Projects are a way of defining basic metadata of the repository. Now, this metadata just includes the source directory. This means that people do not need anymore to provide ALL THE TIME the source directory. Instead, every repository includes a project file that provides it. Iceberg will guide people to create the given file. This file is managed by Iceberg and people should not touch it from the outside or accept the consequences :). This version is integrated in the latest Pharo 7 images. #New Features - #866 Introduce first version of Projects #Infrastructure - #870 Improving tests of Metacello Integration - #903 Split basic tests from metacello tests in CI - #914 Sync Wiki with documentation directory automatically - #934 Manually check metacello integration dialogs - #935 Try to refrite the metacello integration tests. - #940 Installation in new Pharo should also bootstrap pharo repository #Enhancements - #675 The History of a Method in Calypso should show a progress bar. - #788 Show progress during network operations (fetch,push, ...) Libgit. - #875 Tonel plugin does not delete .filetree Migration - #897 Update to OSSubprocess 1.0.1 - #911 Repair Checkout branch should appear in "no project found" - #933 Fix Edit repository dialog - #939 IceInteractiveErrorVisitor duplicates IceTipInteractiveErrorVisitor - #944 Extract pharo repository bootstrap code into iceberg #Bug Fixes - #828 Convert sources to tonel raises an Exception - #839 Infinite loop in IceGitLocalRepositoryType if the path is wrong - #849 VM crash while saving credentials Credential Manager - #851 .properties file is not create if project is imported and not cloned. - #869 Error msg after an http timeout is unreadable - #873 Error with credential provider Credential Manager - #874 The integration with Metacello does not work when there is a src directory, but not project file. - #880 Putting "." in project src field gives dnu - #884 Edit Project Dialog tries to select 'src' folder as default, but does not handle if it does not exists - #886 Edit Project Dialog does not allow to select the root of the repository as source directory - #888 Could not locate repository does not have subdirectory anymore. - #889 Loading an unborn project through metacello does not work - #894 GitHubAPI fails when the API responds with a 204 No Content - #901 I get a DNU projectName.... - #902 Edit project metadata does not detect default format - #918 Cloning pharo from a sync'ed repository does not correctly show dirty packages - #928 Pull request cancel - #930 Changed ivar/slot name in stateful trait not recognized as a change - #931 DNU when trying to unload an Iceberg pkg where underlying Pharo pkg has been removed - #932 Pharo repository forgets packages - #938 Do not catch assertion failures - #941 Iceberg pre-installed repository has wrong repair action - #946 Fixing Metacello Integration Tests - #948 Cloning from github creates an invalid remote - #950 Iceberg v1.2.0 breaks projects Metacello Integration bug - #951 New project window should be coherent on the vocabulary UI enhancement - #953 Make remote request anonymous enhancement - #952 Cannot Clone Pharo Repository Pharo plugin bug - #955 Repair actions for repositories with fetch required are wrong UI bug -- Pablo Tesone. tesonep(a)gmail.com

Aug. 7, 2018

Re: [Pharo-dev] [rmod] About the infinite debugger

by tesonep＠gmail.com

Also, we have found that once the problem starts the image will present bad behavior from that on. Sometimes it can be fixed by restarting the UIProcess, but it is a brute force process. You have to do it many times. It is true that we cannot assert that the bug is not in other places. On Tue, Aug 7, 2018 at 11:14 AM Tim Mackinnon <tim(a)testit.works> wrote: > This is a good writeup - however I get infinite debuggers when not running > tests too? So Iâm wondering if there are multiple problems - or if this > hints at a wider issue? > > Its not all of the time - but when you get it it, it seems to happen over > and over again. Its possible its when using step-over though - so I will > keep an eye on that. > > Tim > > On 7 Aug 2018, at 10:51, tesonep(a)gmail.com wrote: > > Hello, > We have implemented a "patch" for Pharo 7, that is already integrated. I > have created a slice to backport the "patch" to Pharo6. > > Basically, the previous situation is the following: > > - In the normal execution everything works, the problem is during the > execution of over. > - To implement over the debugger uses Context >> runUntilErrorOrReturnFrom: > - This method adds a new context to handle exceptions in the stack trace. > It takes the receiver and replaces the sender of the context with a new > context handling the exceptions. > - This error handling (using on:do:) handles UnhandledError and Halt. > - When the MNU error gots to the nil context a UnhandledError is signal > from the last signalling context of the MNU error. > - This solution works correctly when it is not debugged when running a > test. > > When we are running a tests there is a slight difference: > > - There is one more on:do: context that catches all the Errors. This on:do > just do something and pass the exception. > - As the UnhandledError is signal from the last signalling context (the > one with the pass) it is not passing in the context inserted by > runUntilErrorOrReturnFrom:, generating an infinite debugger as the > exception is never catch. > - This only happens with the MNU, as it retries to send the same message > every time. > > I think the solution is to signal the UnhandledError always from the > original signalling context. However, I am not sure to perform that change > as it modifies the behaviour of exceptions and there are not proper tests > to guarantee the expected behavior. > > I hope the problem is well explained, if it is not please ask me to > clarify any point. > > Cheers, > > On Mon, Aug 6, 2018 at 9:59 AM Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> Hi Steven, >> >> The thing about your fix was mainly that it only worked for the case of >> running tests. We could however reproduce this bug from a playground too. >> >> At first, replacing #pass to #debug looked like a hack to me :) Just >> looking at the code of runCaseForDebug:, I felt the correct thing to do >> there was to use #pass (and let any potential caller handle the exception >> if he wants). >> Otherwise, we should be able to understand: >> - can #pass be used? is it buggy? >> - does it work on any case or it should be avoided in some cases? >> - and how can we fix it (or at least document it?)? >> >> But still, I think you were in the right direction too, because your fix >> shows a good intuition too: both #pass and #debug will do different >> things with the exception. >> - #pass will **resignal** it from the current context, >> - #debug will just open a debugger on it. >> >> So that means that probably there was a problem when the exception was >> handled in a calling context. >> >> >> >> On Mon, Aug 6, 2018 at 12:29 AM Steven Costiou <steven.costiou(a)kloum.io> >> wrote: >> >>> Hi, >>> >>> i had no answer to my comments on fogbuz (one of the first) so i assumed >>> it was not a good idea. >>> >>> In the usecases i used to reproduce the bug, replacing "ex pass" by "ex >>> debug" in runCaseForDebug:solved the problem. See the analysis on >>> fogbuz. >>> >>> Did not have any side effect, but i do not know enough about the system >>> and maybe it does. I think i already asked about that somewhere (here or on >>> discord) but no answers. >>> >>> But maybe it is wrong to do that? I'd be happy to have feedback on that. >>> >>> Steven. >>> >>> Le 2018-08-05 22:27, Tim Mackinnon a Ã©crit : >>> >>> Guys - this really needs attention - I've spend hours now trying to >>> debug some code and most of it is in closing infinite debuggers. It makes a >>> mockery of our tagline - "awesome debugging". And the extra irony is that >>> I'm debugging some file path stuff for exercism, to make it easier for >>> hopefully more people to learn Pharo. >>> >>> How can we get this fixed? >>> >>> Tim >>> >>> On 2 Aug 2018, at 21:44, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> bump >>> >>> Am 04.07.2018 um 02:28 schrieb Martin McClure <martin(a)hand2mouse.com>: >>> >>> On 07/03/2018 05:02 PM, Martin McClure wrote: >>> >>> On 06/29/2018 07:48 AM, Guillermo Polito wrote: >>> I know that the exception handling/debugging has been modified several >>> times in the latest years (some refactorings, hiding contexts...), we >>> unfortunately don't have tests for it, so I'd like some more pair of >>> eyes on it. Ben, Martin could you take a look? >>> >>> Hi Guille, >>> I'm just back from vacation last week, and about to go on vacation for >>> another week, but I'll see what I can see. >>> About the primitive pragmas for context-marking, I think some of those >>> were changed for the exception handling fix that Andres and I did a few >>> years back, so *could* be involved in this. I'd hate to see regression >>> in the exception handling in an attempt to fix this bug. >>> >>> >>> After a look at at the pull request, I'm quite sure that removing the >>> prim 199 marker is the wrong thing to do. Thanks, Pablo, for restoring >>> it! The start of execution of exception handlers must be marked in order >>> for #findNextHandlerContext to work correctly. If these contexts are not >>> marked, exceptions signaled from inside an exception handler can find >>> the wrong handler. See the code and comment in #findNextHandlerContext. >>> >>> I'm afraid that I cannot immediately help with the debugger problem, >>> since I don't know the debugger nearly as well as I do the exception >>> handling code, and I'm going on vacation for a week in 20 minutes. :-) >>> Perhaps when I get back I can take a look at it if it is still a problem >>> by then. >>> >>> Regards, >>> -Martin >>> >>> >>> >>> >> >> >> -- >> >> Guille Polito >> Research Engineer >> >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> CRIStAL - UMR 9189 >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr/>* >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io/> >> *Phone: *+33 06 52 70 66 13 >> > > > -- > Pablo Tesone. > tesonep(a)gmail.com > > > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 7, 2018

Re: [Pharo-dev] [rmod] About the infinite debugger

by Tim Mackinnon

This is a good writeup - however I get infinite debuggers when not running tests too? So Iâm wondering if there are multiple problems - or if this hints at a wider issue? Its not all of the time - but when you get it it, it seems to happen over and over again. Its possible its when using step-over though - so I will keep an eye on that. Tim > On 7 Aug 2018, at 10:51, tesonep(a)gmail.com wrote: > > Hello, > We have implemented a "patch" for Pharo 7, that is already integrated. I have created a slice to backport the "patch" to Pharo6. > > Basically, the previous situation is the following: > > - In the normal execution everything works, the problem is during the execution of over. > - To implement over the debugger uses Context >> runUntilErrorOrReturnFrom: > - This method adds a new context to handle exceptions in the stack trace. It takes the receiver and replaces the sender of the context with a new context handling the exceptions. > - This error handling (using on:do:) handles UnhandledError and Halt. > - When the MNU error gots to the nil context a UnhandledError is signal from the last signalling context of the MNU error. > - This solution works correctly when it is not debugged when running a test. > > When we are running a tests there is a slight difference: > > - There is one more on:do: context that catches all the Errors. This on:do just do something and pass the exception. > - As the UnhandledError is signal from the last signalling context (the one with the pass) it is not passing in the context inserted by runUntilErrorOrReturnFrom:, generating an infinite debugger as the exception is never catch. > - This only happens with the MNU, as it retries to send the same message every time. > > I think the solution is to signal the UnhandledError always from the original signalling context. However, I am not sure to perform that change as it modifies the behaviour of exceptions and there are not proper tests to guarantee the expected behavior. > > I hope the problem is well explained, if it is not please ask me to clarify any point. > > Cheers, > > On Mon, Aug 6, 2018 at 9:59 AM Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > Hi Steven, > > The thing about your fix was mainly that it only worked for the case of running tests. We could however reproduce this bug from a playground too. > > At first, replacing #pass to #debug looked like a hack to me :) Just looking at the code of runCaseForDebug:, I felt the correct thing to do there was to use #pass (and let any potential caller handle the exception if he wants). > Otherwise, we should be able to understand: > - can #pass be used? is it buggy? > - does it work on any case or it should be avoided in some cases? > - and how can we fix it (or at least document it?)? > > But still, I think you were in the right direction too, because your fix shows a good intuition too: both #pass and #debug will do different things with the exception. > - #pass will **resignal** it from the current context, > - #debug will just open a debugger on it. > > So that means that probably there was a problem when the exception was handled in a calling context. > > > > On Mon, Aug 6, 2018 at 12:29 AM Steven Costiou <steven.costiou(a)kloum.io <mailto:steven.costiou@kloum.io>> wrote: > Hi, > > i had no answer to my comments on fogbuz (one of the first) so i assumed it was not a good idea. > > In the usecases i used to reproduce the bug, replacing "ex pass" by "ex debug" in runCaseForDebug:solved the problem. See the analysis on fogbuz. > > Did not have any side effect, but i do not know enough about the system and maybe it does. I think i already asked about that somewhere (here or on discord) but no answers. > > But maybe it is wrong to do that? I'd be happy to have feedback on that. > > Steven. > > Le 2018-08-05 22:27, Tim Mackinnon a Ã©crit : > >> Guys - this really needs attention - I've spend hours now trying to debug some code and most of it is in closing infinite debuggers. It makes a mockery of our tagline - "awesome debugging". And the extra irony is that I'm debugging some file path stuff for exercism, to make it easier for hopefully more people to learn Pharo. >> >> How can we get this fixed? >> >> Tim >> >>> On 2 Aug 2018, at 21:44, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >>> >>> bump >>> >>>> Am 04.07.2018 um 02:28 schrieb Martin McClure <martin(a)hand2mouse.com <mailto:martin@hand2mouse.com>>: >>>> >>>>> On 07/03/2018 05:02 PM, Martin McClure wrote: >>>>>> >>>>>> On 06/29/2018 07:48 AM, Guillermo Polito wrote: >>>>>> I know that the exception handling/debugging has been modified several >>>>>> times in the latest years (some refactorings, hiding contexts...), we >>>>>> unfortunately don't have tests for it, so I'd like some more pair of >>>>>> eyes on it. Ben, Martin could you take a look? >>>>> Hi Guille, >>>>> I'm just back from vacation last week, and about to go on vacation for >>>>> another week, but I'll see what I can see. >>>>> About the primitive pragmas for context-marking, I think some of those >>>>> were changed for the exception handling fix that Andres and I did a few >>>>> years back, so *could* be involved in this. I'd hate to see regression >>>>> in the exception handling in an attempt to fix this bug. >>>> >>>> After a look at at the pull request, I'm quite sure that removing the >>>> prim 199 marker is the wrong thing to do. Thanks, Pablo, for restoring >>>> it! The start of execution of exception handlers must be marked in order >>>> for #findNextHandlerContext to work correctly. If these contexts are not >>>> marked, exceptions signaled from inside an exception handler can find >>>> the wrong handler. See the code and comment in #findNextHandlerContext. >>>> >>>> I'm afraid that I cannot immediately help with the debugger problem, >>>> since I don't know the debugger nearly as well as I do the exception >>>> handling code, and I'm going on vacation for a week in 20 minutes. :-) >>>> Perhaps when I get back I can take a look at it if it is still a problem >>>> by then. >>>> >>>> Regards, >>>> -Martin >> > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13 > > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com>

Aug. 7, 2018

Re: [Pharo-dev] [rmod] About the infinite debugger

by tesonep＠gmail.com

Hello, We have implemented a "patch" for Pharo 7, that is already integrated. I have created a slice to backport the "patch" to Pharo6. Basically, the previous situation is the following: - In the normal execution everything works, the problem is during the execution of over. - To implement over the debugger uses Context >> runUntilErrorOrReturnFrom: - This method adds a new context to handle exceptions in the stack trace. It takes the receiver and replaces the sender of the context with a new context handling the exceptions. - This error handling (using on:do:) handles UnhandledError and Halt. - When the MNU error gots to the nil context a UnhandledError is signal from the last signalling context of the MNU error. - This solution works correctly when it is not debugged when running a test. When we are running a tests there is a slight difference: - There is one more on:do: context that catches all the Errors. This on:do just do something and pass the exception. - As the UnhandledError is signal from the last signalling context (the one with the pass) it is not passing in the context inserted by runUntilErrorOrReturnFrom:, generating an infinite debugger as the exception is never catch. - This only happens with the MNU, as it retries to send the same message every time. I think the solution is to signal the UnhandledError always from the original signalling context. However, I am not sure to perform that change as it modifies the behaviour of exceptions and there are not proper tests to guarantee the expected behavior. I hope the problem is well explained, if it is not please ask me to clarify any point. Cheers, On Mon, Aug 6, 2018 at 9:59 AM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Steven, > > The thing about your fix was mainly that it only worked for the case of > running tests. We could however reproduce this bug from a playground too. > > At first, replacing #pass to #debug looked like a hack to me :) Just > looking at the code of runCaseForDebug:, I felt the correct thing to do > there was to use #pass (and let any potential caller handle the exception > if he wants). > Otherwise, we should be able to understand: > - can #pass be used? is it buggy? > - does it work on any case or it should be avoided in some cases? > - and how can we fix it (or at least document it?)? > > But still, I think you were in the right direction too, because your fix > shows a good intuition too: both #pass and #debug will do different > things with the exception. > - #pass will **resignal** it from the current context, > - #debug will just open a debugger on it. > > So that means that probably there was a problem when the exception was > handled in a calling context. > > > > On Mon, Aug 6, 2018 at 12:29 AM Steven Costiou <steven.costiou(a)kloum.io> > wrote: > >> Hi, >> >> i had no answer to my comments on fogbuz (one of the first) so i assumed >> it was not a good idea. >> >> In the usecases i used to reproduce the bug, replacing "ex pass" by "ex >> debug" in runCaseForDebug:solved the problem. See the analysis on fogbuz. >> >> Did not have any side effect, but i do not know enough about the system >> and maybe it does. I think i already asked about that somewhere (here or on >> discord) but no answers. >> >> But maybe it is wrong to do that? I'd be happy to have feedback on that. >> >> Steven. >> >> Le 2018-08-05 22:27, Tim Mackinnon a Ã©crit : >> >> Guys - this really needs attention - I've spend hours now trying to debug >> some code and most of it is in closing infinite debuggers. It makes a >> mockery of our tagline - "awesome debugging". And the extra irony is that >> I'm debugging some file path stuff for exercism, to make it easier for >> hopefully more people to learn Pharo. >> >> How can we get this fixed? >> >> Tim >> >> On 2 Aug 2018, at 21:44, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> bump >> >> Am 04.07.2018 um 02:28 schrieb Martin McClure <martin(a)hand2mouse.com>: >> >> On 07/03/2018 05:02 PM, Martin McClure wrote: >> >> On 06/29/2018 07:48 AM, Guillermo Polito wrote: >> I know that the exception handling/debugging has been modified several >> times in the latest years (some refactorings, hiding contexts...), we >> unfortunately don't have tests for it, so I'd like some more pair of >> eyes on it. Ben, Martin could you take a look? >> >> Hi Guille, >> I'm just back from vacation last week, and about to go on vacation for >> another week, but I'll see what I can see. >> About the primitive pragmas for context-marking, I think some of those >> were changed for the exception handling fix that Andres and I did a few >> years back, so *could* be involved in this. I'd hate to see regression >> in the exception handling in an attempt to fix this bug. >> >> >> After a look at at the pull request, I'm quite sure that removing the >> prim 199 marker is the wrong thing to do. Thanks, Pablo, for restoring >> it! The start of execution of exception handlers must be marked in order >> for #findNextHandlerContext to work correctly. If these contexts are not >> marked, exceptions signaled from inside an exception handler can find >> the wrong handler. See the code and comment in #findNextHandlerContext. >> >> I'm afraid that I cannot immediately help with the debugger problem, >> since I don't know the debugger nearly as well as I do the exception >> handling code, and I'm going on vacation for a week in 20 minutes. :-) >> Perhaps when I get back I can take a look at it if it is still a problem >> by then. >> >> Regards, >> -Martin >> >> >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 7, 2018

Re: [Pharo-dev] Minheadless trial

by Norbert Hartl

What keeps you from doing a pull request to opensmalltalk-vm ? > Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > Hi Ben, > > Sorry for coming here so late, I didnât see this thread before. > I already have a working minheadless branch that was adapted to Eliotâs process. > It was working for Pharo in Linux and Mac (Windows was ongoing but not finished, thatâs why is not pushed). > > You can find this branch here: > > https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm > > Interesting part is that I didnât tackled any of the issues you are working on, so the work is easily mergeable :) > > Cheers, > Esteban > > Ps: with some changes in image, Iâm using exclusively this VM since a couple of months and it works fine. > > >> On 7 Aug 2018, at 07:22, Ben Coman <btc(a)openinworld.com> wrote: >> >>> On 7 August 2018 at 05:12, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> Hi Ben, >>> Feel free to make this edit and commit >> >> I'm pushing changes here... >> https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-… >> >> and the diff can be tracked here... >> https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless..… >> >> >> ------------------------ >>> On 6 August 2018 at 13:22, Ben Coman <btc(a)openinworld.com> wrote: >>> On 6 August 2018 at 11:50, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… >>> typedef HRESULT WINAPI (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>> C2059 sqPlatformSpecific-Win32.c:80 syntax error: '(' >>> E0651 a calling convention may not be followed by a nested declarator. >>> >>> The following change reduces build errors to 1... >>> typedef HRESULT (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>> >>> but I'm not sure of the implications. >> >> I found the correct solution to this... >> "The trick is placing the [call declaration] inside the parentheses" >> https://stackoverflow.com/questions/4830355/function-pointer-and-calling-co… >> >> i.e. the following compiles cleanly >> typedef HRESULT (WINAPI *SetProcessDpiAwarenessFunctionPointer) (int awareness); >> >> >> ----------------------------- >> Now running the VM (without parameters) I get... >> Debug Assertion Failed! >> Program: ...\x64-Debug\dist\pharo.exe >> File: minkernel\crts\ucrt\src\appcrt\tran\amd64\ieee.c >> Line: 106 >> Expression: (mask&~(_MCW_DN | _MCW_EM | _MCW_RC))==0 >> >> at the call to _controlfp(FPU_DEFAULT, _MCW_EM | _MCW_RC | _MCW_PC | _MCW_IC); >> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… >> >> >> According to https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx >> x64 does not support _MCW_PC or _MCW_IC >> but I'm clueless about the implications of these FPU flags. >> Could our math guys please advise? >> >> Eliminating those two flags allows a VM run successfully without loading an Image. >> i.e. it successfully passes... >> osvm_initialize(); >> osvm_parseCommandLineArguments(argc, argv); >> osvm_initializeVM(); >> >> Next is to try loading an Image. >> >> cheers -ben >

Aug. 7, 2018