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

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

Re: [Pharo-dev] Minheadless trial

by Ben Coman

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 > > I do see osvm_main is defined here... > https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/ minheadless/common/sqVirtualMachineInterface.c#L618 > > but I'm stuck, I don't understand why its looking for "_imp_osvm_main" I see that sqMain.c ( https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… ) only defines a single function... #include "OpenSmalltalkVM.h" int main(int argc, const char **argv) { return osvm_main(argc, argv); } To check that the osvm_main function is available to be linked, at the end of CmakeLists.txt I see... # Build the VM executable(s) add_executable(${VM_EXECUTABLE_NAME} platforms/minheadless/common/sqMain.c) target_link_libraries(${VM_EXECUTABLE_NAME} ${VM_LIBRARY_NAME} ${VM_DEPENDENCIES_LIBRARIES}) Using https://stackoverflow.com/questions/9298278/cmake-print-out-all-accessible-… I found... VM_LIBRARY_NAME=PharoVMCore where that library is defined VM_CORE_LIBRARY_TYPE=STATIC add_library(${VM_LIBRARY_NAME} ${VM_CORE_LIBRARY_TYPE} ${VM_SOURCES} ${VM_INTERNAL_PLUGIN_SOURCES}) and an inspection of PharoVMCore.lib (using 7zip to expand it) shows it contains function osvm_main symbol, but not the "_imp_" prefixed symbol. Regarding the "_imp_" prefix, the next to last comment in this thread * https://software.intel.com/en-us/forums/intel-c-compiler/topic/673427, gave a hint about the __declspec() needing to be dllexport instead of dllimport. The declaration for osvm_main() in OpenSmalltalkVM.h is effectively... https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/include/OpenSmal… # define OSVM_VM_EXPORT __declspec(dllexport) # define OSVM_VM_IMPORT __declspec(dllimport) #ifdef BUILD_VM_CORE # define OSVM_VM_CORE_PUBLIC OSVM_VM_EXPORT #else # define OSVM_VM_CORE_PUBLIC OSVM_VM_IMPORT #endif OSVM_VM_CORE_PUBLIC OSVMError osvm_main(int argc, const char **argv); 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.

Aug. 6, 2018

Re: [Pharo-dev] Stdio>>#standardIOStreamNamed:forWrite: bug?

by Alistair Grant

On Mon, 6 Aug 2018 at 12:18, Damien Pollet <damien.pollet(a)gmail.com> wrote: > > Yes, they do, at least on my macOS. > > I have some doubt about #stdioIsAvailable thoughâ¦ before there was a possible value of 4 (cygwin terminal) for the file descriptor type, which is now out of the tested range, is that intentional Yep. Pharo can't write to a cygwin terminal since it uses the Windows Read/WriteConsole() functions. cygwin terminals are actually written to through pipes, and we can get the pipe information, and thus determine it is a cygwin terminal. But that's it for now. Cheers, Alistair > On Mon, 6 Aug 2018 at 12:00, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> Damien, >> >> Could you check that at least the proposed image-side changes fix your problem for *nixes? >> >> On Sat, Aug 4, 2018 at 7:13 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> Alistair Grant wrote >>> >> Tracking issue: >>> >> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/274 >>> > The issue above is for the VM changes. >>> > >>> > The issue for image changes is: >>> > https://pharo.fogbugz.com/f/cases/22296/Stdio-file-creation-fixes >>> >>> Thanks for looking into this, Alistair! Few are brave enough to dive into >>> these dark corners of the system ;-) >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>> >> >> >> -- >> >> >> >> 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 >> >> >> Web: http://guillep.github.io >> >> Phone: +33 06 52 70 66 13 > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 6, 2018

Re: [Pharo-dev] Stdio>>#standardIOStreamNamed:forWrite: bug?

by Damien Pollet

Yes, they do, at least on my macOS. I have some doubt about #stdioIsAvailable thoughâ¦ before there was a possible value of 4 (cygwin terminal) for the file descriptor type, which is now out of the tested range, is that intentional On Mon, 6 Aug 2018 at 12:00, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Damien, > > Could you check that at least the proposed image-side changes fix your > problem for *nixes? > > On Sat, Aug 4, 2018 at 7:13 PM Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> Alistair Grant wrote >> >> Tracking issue: >> >> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/274 >> > The issue above is for the VM changes. >> > >> > The issue for image changes is: >> > https://pharo.fogbugz.com/f/cases/22296/Stdio-file-creation-fixes >> >> Thanks for looking into this, Alistair! Few are brave enough to dive into >> these dark corners of the system ;-) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >> > > -- > > > > 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 > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 6, 2018

Re: [Pharo-dev] Stdio>>#standardIOStreamNamed:forWrite: bug?

by Guillermo Polito

Damien, Could you check that at least the proposed image-side changes fix your problem for *nixes? On Sat, Aug 4, 2018 at 7:13 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Alistair Grant wrote > >> Tracking issue: > >> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/274 > > The issue above is for the VM changes. > > > > The issue for image changes is: > > https://pharo.fogbugz.com/f/cases/22296/Stdio-file-creation-fixes > > Thanks for looking into this, Alistair! Few are brave enough to dive into > these dark corners of the system ;-) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- 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

Aug. 6, 2018

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

by StÃ©phane Ducasse

> On 6 Aug 2018, at 09:54, Tim Mackinnon <tim(a)testit.works> wrote: > > Hey thanks - this is Pharo 6.1, with a zero conf downloaded yesterday, and a second image from a week ago. I guess its possible that I donât have those changes - is there an easy way to check? These changes are not in Pharo 6.1 but they should because this is terrible! And a new version of the mooc is coming. > Iâm happy to try applying them - or use a different image to test with - as it seems that certain conditions really rear their head and then you just get the problem over and over. > > 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. No it is SUPER SUPER ANNOYING. > 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 > >> On 6 Aug 2018, at 09:46, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> Hi Tim, >> >> Are you on Pharo 6 or 7? If in 7, what build are you using? >> >> 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 <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 :)... >> >> I'll let Pablo and Santi answer more properly with the technical details. >> >> On my side, I think we need to better document and do some more unit tests on that dark part of the system :). >> >> On Mon, Aug 6, 2018 at 8:50 AM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: >> Hi tim >> >> We know and we made huge progress because before we could not even reproduce it. >> We spent some times on it. I thought the solution found by pablo and santiago got integrated. >> >> Stef >> >>> 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 >>>>> >>>> >>> >> >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> >> http://www.synectique.eu <http://www.synectique.eu/> / http://www.pharo.org <http://www.pharo.org/> >> 03 59 35 87 52 >> Assistant: Julie Jonas >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> >> >> >> -- >> >> 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 > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Aug. 6, 2018

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

by Guillermo Polito

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

Aug. 6, 2018

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

by Guillermo Polito

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

Aug. 6, 2018

Re: [Pharo-dev] About the infinite debugger

by Guillermo Polito

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

Aug. 6, 2018

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

by Tim Mackinnon

Hey thanks - this is Pharo 6.1, with a zero conf downloaded yesterday, and a second image from a week ago. I guess its possible that I donât have those changes - is there an easy way to check? Iâm happy to try applying them - or use a different image to test with - as it seems that certain conditions really rear their head and then you just get the problem over and over. 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 > On 6 Aug 2018, at 09:46, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi Tim, > > Are you on Pharo 6 or 7? If in 7, what build are you using? > > 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 <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 :)... > > I'll let Pablo and Santi answer more properly with the technical details. > > On my side, I think we need to better document and do some more unit tests on that dark part of the system :). > > On Mon, Aug 6, 2018 at 8:50 AM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > Hi tim > > We know and we made huge progress because before we could not even reproduce it. > We spent some times on it. I thought the solution found by pablo and santiago got integrated. > > Stef > >> 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 >>>> >>> >> > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> > http://www.synectique.eu <http://www.synectique.eu/> / http://www.pharo.org <http://www.pharo.org/> > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > > > -- > > 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

Aug. 6, 2018

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

by Guillermo Polito

Hi Tim, Are you on Pharo 6 or 7? If in 7, what build are you using? 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 :)... I'll let Pablo and Santi answer more properly with the technical details. On my side, I think we need to better document and do some more unit tests on that dark part of the system :). On Mon, Aug 6, 2018 at 8:50 AM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi tim > > We know and we made huge progress because before we could not even > reproduce it. > We spent some times on it. I thought the solution found by pablo and > santiago got integrated. > > Stef > > 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 > > > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > -- 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

Aug. 6, 2018

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

by StÃ©phane Ducasse

Hi tim We know and we made huge progress because before we could not even reproduce it. We spent some times on it. I thought the solution found by pablo and santiago got integrated. Stef > 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 >>> >> > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Aug. 6, 2018

Re: [Pharo-dev] Minheadless trial

by Ben Coman

On 6 August 2018 at 11:50, Ben Coman <btc(a)openinworld.com> wrote: > wow time flies, its been 18 months since Ronie announced his > Minheadless VM branch... > [1] http://forum.world.st/Minheadless-VM-flavour-status-update-td4928091.html In Visual Studio... > (with x64-Debug & pharo.exe selected) > I went Cmake > Build All > ==> 10 Errors, 9 Warnings, which I'll discuss in a followup post. and btw, the build finishes too quick Here are the errors... ------------------------ 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. Could be "the parenthesis around the function name" [2] Or "there's already a C standard function [of that name]" [3] The Microsoft definition returns a BOOL [4]. [2] https://software.intel.com/en-us/forums/intel-c-compiler/topic/385282 [3] https://social.msdn.microsoft.com/Forums/vstudio/en-US/2c57ada8-e1c9-4030-a… [4] https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-set… ------------------------ https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… sqInt ioSetCursorARGB(sqInt cursorBitsIndex, sqInt extentX, sqInt extentY, sqInt offsetX, sqInt offsetY) C2371 'ioSetCursorARGB': redefinition; different basic types where sqInt is "long long". but the function declaration is https://github.com/ronsaldo/opensmalltalk-vm/blob/21cc02b6bf/platforms/minh… int ioSetCursorARGB(sqInt bitsIndex, sqInt w, sqInt h, sqInt x, sqInt y); After modifying that function declaration to return 'sqInt', "Cmake > Build all" runs much longer ------------------------ 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 I do see osvm_main is defined here... https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… but I'm stuck, I don't understand why its looking for "_imp_osvm_main" I'd be glad if anyone can advise on this, and the two errors above. cheers -ben

Aug. 6, 2018

Minheadless trial

by Ben Coman

wow time flies, its been 18 months since Ronie announced his Minheadless VM branch... [1] http://forum.world.st/Minheadless-VM-flavour-status-update-td4928091.html I've been meaning this whole time to try it out. Recently in my meandering thoughts on FreeRTOS port, I guessed Minheadless might make a good starting basis to experiment with. So a quick test on Ubuntu16.04.3(Windows10-WSL)... Long ago I'd already done... git clone git@github.com:OpenSmalltalk/opensmalltalk-vm.git so I now did... cd opensmalltalk-vm git remote add ronie git@github.com:ronsaldo/opensmalltalk-vm.git git fetch ronie git checkout MinimalisticHeadless ./scripts/updateSCCSVersions cd build.minheadless.cmake/x64/pharo.stack.spur/ ./mvm VM=`pwd`/release/dist/pharo ls $VM ==> confirmed it exists cd ~/pharo wget http://files.pharo.org/image/70/latest-minimal-64.zip unzip latest-minimal-64.zip sudo $VM Pharo7.0-metacello-64bit-65cff7b.image eval "19 + 23" ==> 42 yay Particularly interesting from [1] is "using the same CMake scripts for building on the three platforms: Windows, Linux and OS X." So I thought I'd also give it a try under Windows10-VisualStudio2017. I hardly used VS before, so I'll detail what I did as a reminder for myself (and also in case someone might be able to help if I get stuck). Under a windows cmd.exe prompt (having installed git and cloned opensmalltalk-vm a long time ago) cd opensmalltalk-vm git remote add ronie git@github.com:ronsaldo/opensmalltalk-vm.git git fetch ronie git checkout -b MinimalisticHeadless ronie/MinimalisticHeadless I watched video [2] about CMake integration with Visual Studio 10. and checked the VS workloads configuration specified [2@1:13] using [3]. There is a CMakeLists.txt file in the git root folder, so.. started VS > File > Open > Folder... C:\Repos\OpenSmalltalk\opensmalltalk-vm The CMake command run ([2]@2:13) was... C:\...\cmake.exe -G "Ninja" -DCMAKE_INSTALL_PREFIX:PATH="C:\Users\Ben\CMakeBuilds\...\x86-Debug" -DCMAKE_CXX_COMPILER="C:/.../MSVC/14.14.26428/bin/HostX86/x86/cl.exe" -DCMAKE_C_COMPILER="C:/.../MSVC/14.14.26428/bin/HostX86/x86/cl.exe" -DCMAKE_BUILD_TYPE="Debug" -DCMAKE_MAKE_PROGRAM="C:\...\CMAKE\Ninja\ninja.exe" "C:\Repos\OpenSmalltalk\opensmalltalk-vm" I changed the cmake configuration [2@2:27] to "x64-Debug". For debug target [2@3:00] I chose "pharo.exe" Hey, thats pretty cool [2@4:05] that switching between targets changes the highlighting of #ifdef code. I had a moment when I was missing the "Debug and Launch Settings" menu item [2@4:40-4:55] and mentioned at [4], but maybe there was some clash with previously experimenting with git cloning opensmalltalk-vm from inside VS. After closing VS and reopening my cmd.exe git'd opensmalltalk-vm it showed up, but I didn't change any settings there. Then (with x64-Debug & pharo.exe selected) I went Cmake > Build All ==> 10 Errors, 9 Warnings, which I'll discuss in a followup post. cheers -ben [2] https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-… [3] https://docs.microsoft.com/en-us/visualstudio/install/modify-visual-studio [4] https://blogs.msdn.microsoft.com/vcblog/2016/12/20/cmake-support-in-visual-… [5] https://developercommunity.visualstudio.com/content/problem/234808/cmake-de…

Aug. 6, 2018

Re: [Pharo-dev] About the infinite debugger

by Esteban A. Maringolo

El dom., 5 de ago. de 2018 17:28, Tim Mackinnon <tim(a)testit.works> escribiÃ³: > 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â. We can change the tagline to "limitless debugging".

Aug. 5, 2018

Re: [Pharo-dev] About the infinite debugger

by Steven Costiou

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

Aug. 5, 2018

Re: [Pharo-dev] About the infinite debugger

by Tim Mackinnon

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

Aug. 5, 2018

Iceberg: Cannot Clone Pharo Repository

by Eric Gade

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

Aug. 5, 2018

Re: [Pharo-dev] Stdio>>#standardIOStreamNamed:forWrite: bug?

by Sean P. DeNigris

Alistair Grant wrote >> Tracking issue: >> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/274 > The issue above is for the VM changes. > > The issue for image changes is: > https://pharo.fogbugz.com/f/cases/22296/Stdio-file-creation-fixes Thanks for looking into this, Alistair! Few are brave enough to dive into these dark corners of the system ;-) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 4, 2018

Re: [Pharo-dev] Stdio>>#standardIOStreamNamed:forWrite: bug?

by Alistair Grant

On Sat, 4 Aug 2018 at 15:43, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > > I don't think the error handling has been changed in a long time, but > > just looking quickly at the source code, I think you're correct that it > > isn't returning the correct values. It should be returning nil for > > those handles that aren't valid. > > > > I don't have my Windows VM handy at the moment, is anyone able to > > quickly confirm? (Start pharo with Pharo.exe (not PharoConsole.exe) and > > supply the result from: > > > > File stdioHandles This does indeed fail to return nil even though stdio is not available. Instead a sqFile handle with null HANDLE* is returned. But the image can't test this as the format of sqFile is platform dependent and is private to the VM. > > I've been asking lots of questions lately and not providing much input > > (I was hoping to have File Attributes integrated by now, but MacOS file > > encoding and my inability to get the VM to compile on a Mac VM have > > frustrated me), so I'm more than happy to tidy up the stdio primitives. > > > > I'll need to check that it doesn't break anything on Squeak as well > > (I don't think any of the changes discussed should cause problems). > > Tracking issue: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/274 The issue above is for the VM changes. The issue for image changes is: https://pharo.fogbugz.com/f/cases/22296/Stdio-file-creation-fixes Cheers, Alistair

Aug. 4, 2018

Re: [Pharo-dev] Stdio>>#standardIOStreamNamed:forWrite: bug?

by Alistair Grant

On Fri, 3 Aug 2018 at 11:24, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Guille, > > On Fri, Aug 03, 2018 at 10:34:22AM +0200, Guillermo Polito wrote: > > Hi, > > > > I don't know the windows situation at all, but I'm wondering. > > > > ([ File stdioDescriptorIsATTY not ] > > on: PrimitiveFailed > > do: [ :ex | "HACK kept for retrocompatibility" Smalltalk os isWin32 ]) > > ifTrue: [ ^ self createStdioFileFor: moniker ]. > > > > the first thing I would do, just trying to keep the same behaviour, is to > > invert the test... Something like > > > > Smalltalk os isWin32 ifTrue: [ > > [ File stdioDescriptorIsATTY not ] > > on: PrimitiveFailed > > do: [ :ex | false ]) > > ifTrue: [ ^ self createStdioFileFor: moniker ]. ] > > > > Like that, this would only penalise windows in the worst case. > > True. Actually I think it would be safe to remove it completely. Unix > platforms should always have stdio, and other platforms should act > appropriately. But more below... > > > > Then a first question arises in my head: why isWin32 and not > > isWindows? Is there a reason behind that? Wouldn't that prevent > > correct behaviour in windows 64 bits? > > You're right, it should be #isWindows. > > > > My next impression is that testing for "a TTY or a file or a pipe" > > seems buggy... We should put a more intention revealing selector like > > #isInvalidStdioHandle? > > A more high level test will allow us to do any check we want in the > > background, and it allows better to understand why we check for TTY or > > File or Pipe or la mar en coche :) > > I made the change so that Damien could test that it gives the behaviour > he expects, and did say that the selector will need to be renamed. > > > > What does #stdioHandles return to the image in the case of a > > non-console windows VM? I mean, when "it is not possible"? > > > From the docs, > > https://docs.microsoft.com/en-us/windows/console/getstdhandle says we > > may have an INVALID_HANDLE_VALUE or NULL in case it fails. > > Is the file plugin is masking the error? If so, thats why we need such > > strange workarounds... > > We'd still want the ability to test what type of device stdio is > connected to. But I agree the primitive should be doing the correct > thing. > > > > - If it is an invalid handle, why not just testing for > > "isInvalidHandle" or so? We can have that on the image side and then > > dispatch to the correct thing in the file plugin maybe? > > > - Maybe the #stdioHandles primitive should just fail in the case we > > don't have correct handles? that would allow us to do a much more > > elegant approach on the image side... > > I don't think the error handling has been changed in a long time, but > just looking quickly at the source code, I think you're correct that it > isn't returning the correct values. It should be returning nil for > those handles that aren't valid. > > I don't have my Windows VM handy at the moment, is anyone able to > quickly confirm? (Start pharo with Pharo.exe (not PharoConsole.exe) and > supply the result from: > > File stdioHandles > > > I've been asking lots of questions lately and not providing much input > (I was hoping to have File Attributes integrated by now, but MacOS file > encoding and my inability to get the VM to compile on a Mac VM have > frustrated me), so I'm more than happy to tidy up the stdio primitives. > > I'll need to check that it doesn't break anything on Squeak as well > (I don't think any of the changes discussed should cause problems). Tracking issue: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/274

Aug. 4, 2018