Re: [Pharo-dev] [rmod] About the infinite debugger
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
Re: [Pharo-dev] Minheadless trial
On 6 August 2018 at 11:50, Ben Coman 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/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. 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-a058-6a7afd2fd29f/a-calling-convention-may-not-be-followed-by-a-nested-declarator?forum=vcgeneral [4] https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-setprocessdpiawarenesscontext https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minheadless/common/sqWindow-Dispatch.c#L68 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/minheadless/windows/sqPlatformSpecific-Win32.h#L117 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/minheadless/common/sqVirtualMachineInterface.c#L618 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
Re: [Pharo-dev] About the infinite debugger
El dom., 5 de ago. de 2018 17:28, Tim Mackinnon 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".
Re: [Pharo-dev] About the infinite debugger
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
Re: [Pharo-dev] About the infinite debugger
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 >> >
[Pharo-dev] Iceberg: Cannot Clone Pharo Repository
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