Re: [Pharo-dev] Minheadless trial

2018-08-05 Thread Ben Coman 
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

2018-08-05 Thread Esteban A. Maringolo 
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

2018-08-05 Thread 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  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

2018-08-05 Thread 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  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

2018-08-05 Thread 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