Re: [Pharo-dev] Minheadless trial

[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 


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  wrote:
> 
> On 7 August 2018 at 05:12, Eliot Miranda  > 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-msvc2017
>  
> 
> 
> and the diff can be tracked here...
> https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...bencoman:MinimalisticHeadless-x64-msvc2017
>  
> 
> 
> 
> 
> On 6 August 2018 at 13:22, Ben Coman  > wrote:
> On 6 August 2018 at 11:50, Ben Coman  > 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-convention
>  
> 
> 
> 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/minheadless/windows/sqPlatformSpecific-Win32.c#L118
>  
> 
> 
> 
> 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

Re: [Pharo-dev] Minheadless trial

[Ben Coman]

 On 7 August 2018 at 05:12, Eliot Miranda  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-msvc2017

and the diff can be tracked here...
https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...bencoman:MinimalisticHeadless-x64-msvc2017



On 6 August 2018 at 13:22, Ben Coman  wrote:

> On 6 August 2018 at 11:50, Ben Coman  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-convention

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


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

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

[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

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

[Alistair Grant]

On Mon, 6 Aug 2018 at 12:18, Damien Pollet  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  
> 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  
>> 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

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

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

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

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

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

[Stéphane Ducasse]

> On 6 Aug 2018, at 09:54, Tim Mackinnon  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 > > 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 
>> 
>> 
>> 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 > > 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 >>> > wrote:
 
 bump
 
> Am 04.07.2018 um 02:28 schrieb Martin McClure  >:
> 
>> 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
> 
 
>>> 

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

[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 
wrote:

> Hi Eric,
>
> Thanks for the report. I'm looking into it.
>
> On Sun, Aug 5, 2018 at 6:20 PM Eric Gade  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
> *
>
>
> *Web:* *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
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

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

[Guillermo Polito]

Hi Eric,

Thanks for the report. I'm looking into it.

On Sun, Aug 5, 2018 at 6:20 PM Eric Gade  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
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] About the infinite debugger

[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 
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  wrote:
>
> bump
>
> Am 04.07.2018 um 02:28 schrieb Martin McClure :
>
> 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
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

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

[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  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 
> 
> 
> 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  > 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 >> > wrote:
>>> 
>>> bump
>>> 
 Am 04.07.2018 um 02:28 schrieb Martin McClure >>> >:
 
> 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 

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

[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 
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  wrote:
>
> bump
>
> Am 04.07.2018 um 02:28 schrieb Martin McClure :
>
> 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
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

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

[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  wrote:
>> 
>> bump
>> 
>>> Am 04.07.2018 um 02:28 schrieb Martin McClure :
>>> 
 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