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

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

Re: [Pharo-dev] Minheadless trial

by Esteban Lorenzano

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> 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 Ben Coman

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/ > minheadless/windows/sqPlatformSpecific-Win32.c#L80 > 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

Re: [Pharo-dev] [Vm-dev] Minheadless trial

by Eliot Miranda

Hi Ben, On Mon, Aug 6, 2018 at 12:57 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > > On 6 August 2018 at 23:54, Ben Coman <btc(a)openinworld.com> wrote: > >> >> On 6 August 2018 at 13:22, Ben Coman <btc(a)openinworld.com> wrote: >> > and ends up with 4 link errors (and 6600 warnings) >> > Pharo.exe LNK1120 - 1 unresolved external >> > Pharow.exe LNK1120 - 1unresolved external >> > sqMain.c.obj LNK2019 - unresolved external symbol >> _imp_osvm_main referenced in function main >> > sqWin32Main.c.obj LNK2019 - unresolved external symbol _imp_osvm_main >> referenced in function WinMain >> >> >> So the following change to sqMain.c fixes the link error... >> #define BUILD_VM_CORE >> #include "OpenSmalltalkVM.h" >> int >> main(int argc, const char **argv) >> { >> return osvm_main(argc, argv); >> } >> >> and similar for sqWin32Main.c. >> >> > The next roadbump is... > LNK2019 unresolved external symbol 'alloca' referenced in function > callIA32IntegralReturn -- File PharoVMCore.lib(xabicc.c.obj) > > From the root folder, doing... > find . -name xabicc.c > result in... > ./platforms/Cross/plugins/IA32ABI/xabicc.c > > > Googling for "alloca Visual Studio 2017" lead me to... > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/alloca > which indicates there is no "alloca" only "_alloca" > > Now " xabicc.c" is a stub for including platform specific C code, > and the lovely defines-highlighting of Visual Studio indicates "x64win64abicc.c" > is the active one right now, > so as a quick hack, jamming a define just above that include... > > #if i386|i486|i586|i686 > # include "ia32abicc.c" > #elif powerpc|ppc > # include "ppc32abicc.c" > #elif x86_64|x64|__x86_64|__x86_64__|_M_AMD64|_M_X64 > # if _WIN64 > # define alloca _alloca // <<<QUICK HACK > # include "x64win64abicc.c" > # else > # include "x64sysvabicc.c" > # endif > #elif __ARM_ARCH__|__arm__|__arm32__|ARM32 > # include "arm32abicc.c" > #endif > > > allows CMake > Build All > ==> Build succeeded. Yay! > > To determine a suitable permanent home for that define, doing... > grep -R " _alloca" * > from the root folder shows... > platforms/Cross/plugins/IA32ABI/arm32abicc.c:# define alloca _alloca > platforms/Cross/plugins/IA32ABI/ia32abicc.c:# define alloca _alloca > platforms/Cross/plugins/IA32ABI/ppc32abicc.c:# define alloca _alloca > platforms/Cross/plugins/SqueakFFIPrims/sqFFIPlugin.c:# define alloca > _alloca > platforms/minheadless/windows/sqPlatformSpecific-Win32.h:# define > alloca _alloca > platforms/unix/config/configure:# define alloca _alloca > platforms/win32/vm/sqPlatformSpecific.h:# define alloca _alloca > processors/ARM/gdb-7.10/include/alloca-conf.h:# define alloca _alloca > processors/IA32/bochs/bx_debug/parser.c:# define alloca _alloca > src/plugins/SqueakFFIPrims/ARM32FFIPlugin.c:# define alloca _alloca > src/plugins/SqueakFFIPrims/IA32FFIPlugin.c:# define alloca _alloca > src/plugins/SqueakFFIPrims/X64SysVFFIPlugin.c:# define alloca _alloca > src/plugins/SqueakFFIPrims/X64Win64FFIPlugin.c:# define alloca _alloca > > Interesting that there is a similar define for ia32abicc.c, > so comparing that with x64win64abicc.c (at https://www.diffchecker. > com/mqCWMaTV) > looks like it should be slotted into the latter about line 41. > Feel free to make this edit and commit > Doing that ==> Build successful. > > cheers -ben > > -- _,,,^..^,,,_ best, Eliot

Aug. 6, 2018

Re: [Pharo-dev] Minheadless trial

by Ben Coman

On 6 August 2018 at 23:54, Ben Coman <btc(a)openinworld.com> wrote: > > On 6 August 2018 at 13:22, Ben Coman <btc(a)openinworld.com> wrote: > > and ends up with 4 link errors (and 6600 warnings) > > Pharo.exe LNK1120 - 1 unresolved external > > Pharow.exe LNK1120 - 1unresolved external > > sqMain.c.obj LNK2019 - unresolved external symbol > _imp_osvm_main referenced in function main > > sqWin32Main.c.obj LNK2019 - unresolved external symbol _imp_osvm_main > referenced in function WinMain > > > So the following change to sqMain.c fixes the link error... > #define BUILD_VM_CORE > #include "OpenSmalltalkVM.h" > int > main(int argc, const char **argv) > { > return osvm_main(argc, argv); > } > > and similar for sqWin32Main.c. > > The next roadbump is... LNK2019 unresolved external symbol 'alloca' referenced in function callIA32IntegralReturn -- File PharoVMCore.lib(xabicc.c.obj) >From the root folder, doing... find . -name xabicc.c result in... ./platforms/Cross/plugins/IA32ABI/xabicc.c Googling for "alloca Visual Studio 2017" lead me to... https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/alloca which indicates there is no "alloca" only "_alloca" Now " xabicc.c" is a stub for including platform specific C code, and the lovely defines-highlighting of Visual Studio indicates "x64win64abicc.c" is the active one right now, so as a quick hack, jamming a define just above that include... #if i386|i486|i586|i686 # include "ia32abicc.c" #elif powerpc|ppc # include "ppc32abicc.c" #elif x86_64|x64|__x86_64|__x86_64__|_M_AMD64|_M_X64 # if _WIN64 # define alloca _alloca // <<<QUICK HACK # include "x64win64abicc.c" # else # include "x64sysvabicc.c" # endif #elif __ARM_ARCH__|__arm__|__arm32__|ARM32 # include "arm32abicc.c" #endif allows CMake > Build All ==> Build succeeded. Yay! To determine a suitable permanent home for that define, doing... grep -R " _alloca" * from the root folder shows... platforms/Cross/plugins/IA32ABI/arm32abicc.c:# define alloca _alloca platforms/Cross/plugins/IA32ABI/ia32abicc.c:# define alloca _alloca platforms/Cross/plugins/IA32ABI/ppc32abicc.c:# define alloca _alloca platforms/Cross/plugins/SqueakFFIPrims/sqFFIPlugin.c:# define alloca _alloca platforms/minheadless/windows/sqPlatformSpecific-Win32.h:# define alloca _alloca platforms/unix/config/configure:# define alloca _alloca platforms/win32/vm/sqPlatformSpecific.h:# define alloca _alloca processors/ARM/gdb-7.10/include/alloca-conf.h:# define alloca _alloca processors/IA32/bochs/bx_debug/parser.c:# define alloca _alloca src/plugins/SqueakFFIPrims/ARM32FFIPlugin.c:# define alloca _alloca src/plugins/SqueakFFIPrims/IA32FFIPlugin.c:# define alloca _alloca src/plugins/SqueakFFIPrims/X64SysVFFIPlugin.c:# define alloca _alloca src/plugins/SqueakFFIPrims/X64Win64FFIPlugin.c:# define alloca _alloca Interesting that there is a similar define for ia32abicc.c, so comparing that with x64win64abicc.c (at https://www.diffchecker.com/mqCWMaTV) looks like it should be slotted into the latter about line 41. Doing that ==> Build successful. cheers -ben

Aug. 6, 2018

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

by Martin McClure

On 08/06/2018 12:46 AM, Guillermo Polito wrote: > Pablo and Santi have made a fix 2 fridays ago (that I presume got > integrated last week). The fix consists on changing a bit the > exception handling during exception handling. > > https://github.com/pharo-project/pharo/pull/1621/files > > The fix seems simple, but it has a lot of information contained on it > (like the fact that the system introduces exception handlers in the > middle of the stack transparently to manage errors while stepping, or > the fact that UnhandledError does another traversal of the stack but > needs to start at the good place...). The Exception tests we had are > still green, and we can now do stepping on code that raises > exceptions. When stepping inside the DNU multiple times the debugging > experience is not as smooth as the one in Pharo 3 (before it got > broken) but this is FAR BETTER than Pharo7 since we have not > experienced new infinite debuggers anymore :)... > Thanks for the update, Guille, and the pointer to the fix. This fix smells a bit hacky, but... I don't know the internals of the debugger. It might be the best way to handle it. And I'm glad it has improved the behavior. Since I *am* familiar with the changes to exception handling, and the reasons behind those changes, I'd be happy to sit down at Camp Smalltalk in Cagliari with you or whoever knows a bit about this problem, and see whether it's possible to make a smoother fix. Regards, -Martin

Aug. 6, 2018