Discussion:
Puzzled
(too old to reply)
Pharo4Stef
2014-04-03 17:41:41 UTC
Permalink
Hi guys

I need your brain cells.

When I execute the test

testBasic
| context process debugger printedString |
context := [ 20 factorial ] asContext.

process := Process
forContext: context
priority: Processor userInterruptPriority.

debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.

self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive
ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic']
ifFalse: [ '[...] in DebuggerTest>>testBasic' ].
self assert: debugger stack selectedItem printString = printedString.

debugger send.
debugger send.
self assert: debugger code getText = (Integer>>#factorial) sourceCode.
self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.

two times my image (latest get totally unusable).
I thought that may be the process should be terminated
so I added

process terminate

But nothing changes. I tried to debug the code but not chance.
I tried self halt after [ 20 factorial ] asContext.

I tried to execute the beginning in a workspace and not as a test to eliminate problem.
But again no chance.


So did I miss something obvious?

Stef
Pharo4Stef
2014-04-03 18:49:01 UTC
Permalink
even using ensure: to make sure that the process is terminated it is not really working.
I have the impression that there is a problem and that the tests does not really finishes but this is really difficult to debug.
Post by Pharo4Stef
Hi guys
I need your brain cells.
When I execute the test
testBasic
| context process debugger printedString |
context := [ 20 factorial ] asContext.
process := Process
forContext: context
priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive
ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic']
ifFalse: [ '[...] in DebuggerTest>>testBasic' ].
self assert: debugger stack selectedItem printString = printedString.
debugger send.
debugger send.
self assert: debugger code getText = (Integer>>#factorial) sourceCode.
self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable).
I thought that may be the process should be terminated
so I added
process terminate
But nothing changes. I tried to debug the code but not chance.
I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem.
But again no chance.
So did I miss something obvious?
Stef
Pharo4Stef
2014-04-03 19:05:50 UTC
Permalink
When I use

| context process |
context := [ 20 factorial ] asContext.

process := Process
forContext: context
priority: Processor userInterruptPriority.
[
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.

] ifCurtailed: [ process terminate]

I do not get any extra process hanging around.

now if I do



| context process |
context := [ 20 factorial ] asContext.

process := Process
forContext: context
priority: Processor userInterruptPriority.
[
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
Transcript show: debugger stack selectedIndex

] ifCurtailed: [ process terminate]


But then when I do


| context process debuggerg |
context := [ 20 factorial ] asContext.

process := Process
forContext: context
priority: Processor userInterruptPriority.
[
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
Transcript show: debugger stack selectedIndex; cr.
] ensure: [ process terminate]

I get processes stuck trying to open the log fiel ro something like that.


Now I do not understand because when I ask the setter to stack (to get what is set in this variable) the system
tells me that there is no store.

Stef
Post by Pharo4Stef
even using ensure: to make sure that the process is terminated it is not really working.
I have the impression that there is a problem and that the tests does not really finishes but this is really difficult to debug.
Post by Pharo4Stef
Hi guys
I need your brain cells.
When I execute the test
testBasic
| context process debugger printedString |
context := [ 20 factorial ] asContext.
process := Process
forContext: context
priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive
ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic']
ifFalse: [ '[...] in DebuggerTest>>testBasic' ].
self assert: debugger stack selectedItem printString = printedString.
debugger send.
debugger send.
self assert: debugger code getText = (Integer>>#factorial) sourceCode.
self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable).
I thought that may be the process should be terminated
so I added
process terminate
But nothing changes. I tried to debug the code but not chance.
I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem.
But again no chance.
So did I miss something obvious?
Stef
Pharo4Stef
2014-04-03 19:13:36 UTC
Permalink
| context process debugger |
context := [ 20 factorial ] asContext.

process := Process
forContext: context
priority: Processor userInterruptPriority.
[
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
Transcript show: debugger stack class ; cr
] ensure: [ process terminate]


When I look at some of the stuck processes

SpecDebugger>>initializePresenter
super initializePresenter.
self flag: 'some of this logic could be moved to the stack widget'.
self flag: 'The toolbar should not be updated when the list changes, but when an action is perormed.'.
self stack whenListChanged: [ :aList |
aList isEmpty ifFalse: [ self stack setSelectedItem: aList first ].
"Updating the toolbar will result in changing the button widgets.
If the widget hasn't been opened, there will be no spec, which leads to an error."
self spec ifNotNil: [
self updateToolbar ] ].

self stack whenSelectedItemChanged: [:aContext |
self updateCodeFromContext: aContext.
self updateInspectorsFromContext: aContext.
self stack updateForSelectionChanged ].

self contextInspector initializeAutoRefresh.

^^^^^^^^^^^^^^^^^^^^^^^^^^^

And initializeAutoRefresh does not exist in the latest image.
I have no idea why the debugger may work may be this method is not used at all.

Can somebody else confirm because I have the impression to fall into a rat nest.
stef
Pharo4Stef
2014-04-03 19:34:49 UTC
Permalink
ok now I understand: an endless loop inside the debugger creation. I do not understand why we did not address it with clement
because we open the debugger and other when we fixed the logic of the inspector (to avoid polling refresh).

Stef
Post by Pharo4Stef
| context process debugger |
context := [ 20 factorial ] asContext.
process := Process
forContext: context
priority: Processor userInterruptPriority.
[
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
Transcript show: debugger stack class ; cr
] ensure: [ process terminate]
When I look at some of the stuck processes
SpecDebugger>>initializePresenter
super initializePresenter.
self flag: 'some of this logic could be moved to the stack widget'.
self flag: 'The toolbar should not be updated when the list changes, but when an action is perormed.'.
self stack whenListChanged: [ :aList |
aList isEmpty ifFalse: [ self stack setSelectedItem: aList first ].
"Updating the toolbar will result in changing the button widgets.
If the widget hasn't been opened, there will be no spec, which leads to an error."
self spec ifNotNil: [
self updateToolbar ] ].
self stack whenSelectedItemChanged: [:aContext |
self updateCodeFromContext: aContext.
self updateInspectorsFromContext: aContext.
self stack updateForSelectionChanged ].
self contextInspector initializeAutoRefresh.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
And initializeAutoRefresh does not exist in the latest image.
I have no idea why the debugger may work may be this method is not used at all.
Can somebody else confirm because I have the impression to fall into a rat nest.
stef
Clément Bera
2014-04-03 20:50:31 UTC
Permalink
Hey,

I remembered removing the initializeAutoRefresh code from the debugger.
Perhaps I didn't commit that package. Or I forgot this one.
Post by Pharo4Stef
ok now I understand: an endless loop inside the debugger creation. I do
not understand why we did not address it with clement
because we open the debugger and other when we fixed the logic of the
inspector (to avoid polling refresh).
Stef
Post by Pharo4Stef
| context process debugger |
context := [ 20 factorial ] asContext.
process := Process
forContext: context
priority: Processor userInterruptPriority.
[
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
Transcript show: debugger stack class ; cr
] ensure: [ process terminate]
When I look at some of the stuck processes
SpecDebugger>>initializePresenter
super initializePresenter.
self flag: 'some of this logic could be moved to the stack widget'.
self flag: 'The toolbar should not be updated when the list
changes, but when an action is perormed.'.
Post by Pharo4Stef
self stack whenListChanged: [ :aList |
aList isEmpty ifFalse: [ self stack setSelectedItem: aList
first ].
Post by Pharo4Stef
"Updating the toolbar will result in changing the button
widgets.
Post by Pharo4Stef
If the widget hasn't been opened, there will be no spec,
which leads to an error."
Post by Pharo4Stef
self spec ifNotNil: [
self updateToolbar ] ].
self stack whenSelectedItemChanged: [:aContext |
self updateCodeFromContext: aContext.
self updateInspectorsFromContext: aContext.
self stack updateForSelectionChanged ].
self contextInspector initializeAutoRefresh.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
And initializeAutoRefresh does not exist in the latest image.
I have no idea why the debugger may work may be this method is not used
at all.
Post by Pharo4Stef
Can somebody else confirm because I have the impression to fall into a
rat nest.
Post by Pharo4Stef
stef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140403/34944638/attachment.html>
Pharo4Stef
2014-04-04 06:30:18 UTC
Permalink
I?m sorry but I will stop working on this issue since I do not have time for pharo anymore this week and the next one.
Apparently I?m the only one to care about this bogus logic so let it be but be prepared to have too many hanging process around.
Stef
Hey,
I remembered removing the initializeAutoRefresh code from the debugger. Perhaps I didn't commit that package. Or I forgot this one.
ok now I understand: an endless loop inside the debugger creation. I do not understand why we did not address it with clement
because we open the debugger and other when we fixed the logic of the inspector (to avoid polling refresh).
Stef
Post by Pharo4Stef
| context process debugger |
context := [ 20 factorial ] asContext.
process := Process
forContext: context
priority: Processor userInterruptPriority.
[
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
Transcript show: debugger stack class ; cr
] ensure: [ process terminate]
When I look at some of the stuck processes
SpecDebugger>>initializePresenter
super initializePresenter.
self flag: 'some of this logic could be moved to the stack widget'.
self flag: 'The toolbar should not be updated when the list changes, but when an action is perormed.'.
self stack whenListChanged: [ :aList |
aList isEmpty ifFalse: [ self stack setSelectedItem: aList first ].
"Updating the toolbar will result in changing the button widgets.
If the widget hasn't been opened, there will be no spec, which leads to an error."
self spec ifNotNil: [
self updateToolbar ] ].
self stack whenSelectedItemChanged: [:aContext |
self updateCodeFromContext: aContext.
self updateInspectorsFromContext: aContext.
self stack updateForSelectionChanged ].
self contextInspector initializeAutoRefresh.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
And initializeAutoRefresh does not exist in the latest image.
I have no idea why the debugger may work may be this method is not used at all.
Can somebody else confirm because I have the impression to fall into a rat nest.
stef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140404/6e788c63/attachment.html>
Sven Van Caekenberghe
2014-04-04 06:36:10 UTC
Permalink
It is hard for everyone to get a complex issue cleanly integrated.
Post by Pharo4Stef
I?m sorry but I will stop working on this issue since I do not have time for pharo anymore this week and the next one.
Apparently I?m the only one to care about this bogus logic so let it be but be prepared to have too many hanging process around.
Stef
Hey,
I remembered removing the initializeAutoRefresh code from the debugger. Perhaps I didn't commit that package. Or I forgot this one.
ok now I understand: an endless loop inside the debugger creation. I do not understand why we did not address it with clement
because we open the debugger and other when we fixed the logic of the inspector (to avoid polling refresh).
Stef
Post by Pharo4Stef
| context process debugger |
context := [ 20 factorial ] asContext.
process := Process
forContext: context
priority: Processor userInterruptPriority.
[
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
Transcript show: debugger stack class ; cr
] ensure: [ process terminate]
When I look at some of the stuck processes
SpecDebugger>>initializePresenter
super initializePresenter.
self flag: 'some of this logic could be moved to the stack widget'.
self flag: 'The toolbar should not be updated when the list changes, but when an action is perormed.'.
self stack whenListChanged: [ :aList |
aList isEmpty ifFalse: [ self stack setSelectedItem: aList first ].
"Updating the toolbar will result in changing the button widgets.
If the widget hasn't been opened, there will be no spec, which leads to an error."
self spec ifNotNil: [
self updateToolbar ] ].
self stack whenSelectedItemChanged: [:aContext |
self updateCodeFromContext: aContext.
self updateInspectorsFromContext: aContext.
self stack updateForSelectionChanged ].
self contextInspector initializeAutoRefresh.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
And initializeAutoRefresh does not exist in the latest image.
I have no idea why the debugger may work may be this method is not used at all.
Can somebody else confirm because I have the impression to fall into a rat nest.
stef
Camille Teruel
2014-04-04 07:21:11 UTC
Permalink
I tried on my machine in latest image and no matter how many times I run this test, this test still passes and I don't notice any slowdown nor image freeze.
But I see the hanging processes.
Adding 'process terminate' at the end works for me.
Post by Pharo4Stef
Hi guys
I need your brain cells.
When I execute the test
testBasic
| context process debugger printedString |
context := [ 20 factorial ] asContext.
process := Process
forContext: context
priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive
ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic']
ifFalse: [ '[...] in DebuggerTest>>testBasic' ].
self assert: debugger stack selectedItem printString = printedString.
debugger send.
debugger send.
self assert: debugger code getText = (Integer>>#factorial) sourceCode.
self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable).
I thought that may be the process should be terminated
so I added
process terminate
But nothing changes. I tried to debug the code but not chance.
I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem.
But again no chance.
So did I miss something obvious?
Stef
Pharo4Stef
2014-04-04 10:37:24 UTC
Permalink
Thanks camille apparently I restarted from a clean image but may be I merged.
Could you try loading the latest version of 12460 and let me know?
Post by Camille Teruel
I tried on my machine in latest image and no matter how many times I run this test, this test still passes and I don't notice any slowdown nor image freeze.
But I see the hanging processes.
Adding 'process terminate' at the end works for me.
Post by Pharo4Stef
Hi guys
I need your brain cells.
When I execute the test
testBasic
| context process debugger printedString |
context := [ 20 factorial ] asContext.
process := Process
forContext: context
priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive
ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic']
ifFalse: [ '[...] in DebuggerTest>>testBasic' ].
self assert: debugger stack selectedItem printString = printedString.
debugger send.
debugger send.
self assert: debugger code getText = (Integer>>#factorial) sourceCode.
self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable).
I thought that may be the process should be terminated
so I added
process terminate
But nothing changes. I tried to debug the code but not chance.
I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem.
But again no chance.
So did I miss something obvious?
Stef
Camille Teruel
2014-04-04 10:46:49 UTC
Permalink
Post by Pharo4Stef
Thanks camille apparently I restarted from a clean image but may be I merged.
Could you try loading the latest version of 12460 and let me know?
It works, but we still need to add 'process terminate' at the end.
I open another bug entry (since it is not related to issue 12460).
Post by Pharo4Stef
Post by Camille Teruel
I tried on my machine in latest image and no matter how many times I run this test, this test still passes and I don't notice any slowdown nor image freeze.
But I see the hanging processes.
Adding 'process terminate' at the end works for me.
Post by Pharo4Stef
Hi guys
I need your brain cells.
When I execute the test
testBasic
| context process debugger printedString |
context := [ 20 factorial ] asContext.
process := Process
forContext: context
priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive
ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic']
ifFalse: [ '[...] in DebuggerTest>>testBasic' ].
self assert: debugger stack selectedItem printString = printedString.
debugger send.
debugger send.
self assert: debugger code getText = (Integer>>#factorial) sourceCode.
self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable).
I thought that may be the process should be terminated
so I added
process terminate
But nothing changes. I tried to debug the code but not chance.
I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem.
But again no chance.
So did I miss something obvious?
Stef
Camille Teruel
2014-04-04 10:53:10 UTC
Permalink
Fix in inbox

https://pharo.fogbugz.com/f/cases/13170/
Post by Camille Teruel
Post by Pharo4Stef
Thanks camille apparently I restarted from a clean image but may be I merged.
Could you try loading the latest version of 12460 and let me know?
It works, but we still need to add 'process terminate' at the end.
I open another bug entry (since it is not related to issue 12460).
Post by Pharo4Stef
Post by Camille Teruel
I tried on my machine in latest image and no matter how many times I run this test, this test still passes and I don't notice any slowdown nor image freeze.
But I see the hanging processes.
Adding 'process terminate' at the end works for me.
Post by Pharo4Stef
Hi guys
I need your brain cells.
When I execute the test
testBasic
| context process debugger printedString |
context := [ 20 factorial ] asContext.
process := Process
forContext: context
priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive
ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic']
ifFalse: [ '[...] in DebuggerTest>>testBasic' ].
self assert: debugger stack selectedItem printString = printedString.
debugger send.
debugger send.
self assert: debugger code getText = (Integer>>#factorial) sourceCode.
self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable).
I thought that may be the process should be terminated
so I added
process terminate
But nothing changes. I tried to debug the code but not chance.
I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem.
But again no chance.
So did I miss something obvious?
Stef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140404/7367e38b/attachment.html>
Eliot Miranda
2014-04-05 17:30:25 UTC
Permalink
Hi Stef,

I think it is because forContext:priority: does not schedule the
process, just creates it. The debugger code steps the process but after
stepping the process is still not runnable. So the process terminate is
unnecessary; the process should not have been added to the run queue and
should juts be GCed. Since it is not the question is what refers to the
process after the test has run.

To debug, I would rewrite the test as such:

testBasic
| process debugger printedString |
process := Process
forContext: [ 20 factorial ] asContext
priority: Processor activePriority.

debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.

self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive
ifTrue: [ '[ 20 factorial ] in
DebuggerTest>>testBasic']
ifFalse: [ '[...] in DebuggerTest>>testBasic' ].
self assert: debugger stack selectedItem printString =
printedString.

debugger send.
debugger send.
self assert: debugger code getText = (Integer>>#factorial)
sourceCode.
self assert: debugger stack selectedItem printString =
'SmallInteger(Integer)>>factorial'.

^process

and then chase pointers on the result to see what is holding onto the
process. Sicne the process is never runnable there's no need to set its
priority to anything special.

However, one should also be able to replace the "process terminate" with
"process resume" to get it to run to termination (provided its priority
stays at Processor userInterruptPriority).

HTH
Post by Pharo4Stef
Hi guys
I need your brain cells.
When I execute the test
testBasic
| context process debugger printedString |
context := [ 20 factorial ] asContext.
process := Process
forContext: context
priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive
ifTrue: [ '[ 20 factorial ] in
DebuggerTest>>testBasic']
ifFalse: [ '[...] in DebuggerTest>>testBasic' ].
self assert: debugger stack selectedItem printString =
printedString.
debugger send.
debugger send.
self assert: debugger code getText = (Integer>>#factorial) sourceCode.
self assert: debugger stack selectedItem printString =
'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable).
I thought that may be the process should be terminated
so I added
process terminate
But nothing changes. I tried to debug the code but not chance.
I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem.
But again no chance.
So did I miss something obvious?
Stef
--
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140405/a71a1a45/attachment.html>
Eliot Miranda
2014-04-05 17:31:43 UTC
Permalink
Post by Eliot Miranda
Hi Stef,
I think it is because forContext:priority: does not schedule the
process, just creates it. The debugger code steps the process but after
stepping the process is still not runnable. So the process terminate is
unnecessary; the process should not have been added to the run queue and
should juts be GCed. Since it is not the question is what refers to the
process after the test has run.
(Since it is not GCed, the question is "what refers to the process after
the test has run?").
Post by Eliot Miranda
testBasic
| process debugger printedString |
process := Process
forContext: [ 20 factorial ] asContext
priority: Processor activePriority.
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive
ifTrue: [ '[ 20 factorial ] in
DebuggerTest>>testBasic']
ifFalse: [ '[...] in DebuggerTest>>testBasic' ].
self assert: debugger stack selectedItem printString =
printedString.
debugger send.
debugger send.
self assert: debugger code getText = (Integer>>#factorial) sourceCode.
self assert: debugger stack selectedItem printString =
'SmallInteger(Integer)>>factorial'.
^process
and then chase pointers on the result to see what is holding onto the
process. Sicne the process is never runnable there's no need to set its
priority to anything special.
However, one should also be able to replace the "process terminate" with
"process resume" to get it to run to termination (provided its priority
stays at Processor userInterruptPriority).
HTH
Post by Pharo4Stef
Hi guys
I need your brain cells.
When I execute the test
testBasic
| context process debugger printedString |
context := [ 20 factorial ] asContext.
process := Process
forContext: context
priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive
ifTrue: [ '[ 20 factorial ] in
DebuggerTest>>testBasic']
ifFalse: [ '[...] in DebuggerTest>>testBasic' ].
self assert: debugger stack selectedItem printString = printedString.
debugger send.
debugger send.
self assert: debugger code getText = (Integer>>#factorial) sourceCode.
self assert: debugger stack selectedItem printString =
'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable).
I thought that may be the process should be terminated
so I added
process terminate
But nothing changes. I tried to debug the code but not chance.
I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem.
But again no chance.
So did I miss something obvious?
Stef
--
best,
Eliot
--
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140405/453f2303/attachment-0001.html>
Pharo4Stef
2014-04-05 19:08:43 UTC
Permalink
In fact there was an error in the debugger code => endless loop in another thread it was strange because the test was not returning
Post by Eliot Miranda
Hi Stef,
I think it is because forContext:priority: does not schedule the process, just creates it. The debugger code steps the process but after stepping the process is still not runnable. So the process terminate is unnecessary; the process should not have been added to the run queue and should juts be GCed. Since it is not the question is what refers to the process after the test has run.
testBasic
| process debugger printedString |
process := Process
forContext: [ 20 factorial ] asContext
priority: Processor activePriority.
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive
ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic']
ifFalse: [ '[...] in DebuggerTest>>testBasic' ].
self assert: debugger stack selectedItem printString = printedString.
debugger send.
debugger send.
self assert: debugger code getText = (Integer>>#factorial) sourceCode.
self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
^process
and then chase pointers on the result to see what is holding onto the process. Sicne the process is never runnable there's no need to set its priority to anything special.
However, one should also be able to replace the "process terminate" with "process resume" to get it to run to termination (provided its priority stays at Processor userInterruptPriority).
HTH
Hi guys
I need your brain cells.
When I execute the test
testBasic
| context process debugger printedString |
context := [ 20 factorial ] asContext.
process := Process
forContext: context
priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new
process: process
controller: nil
context: context.
debugger stack expand.
self assert: debugger stack selectedIndex = 1.
printedString := OpalCompiler isActive
ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic']
ifFalse: [ '[...] in DebuggerTest>>testBasic' ].
self assert: debugger stack selectedItem printString = printedString.
debugger send.
debugger send.
self assert: debugger code getText = (Integer>>#factorial) sourceCode.
self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable).
I thought that may be the process should be terminated
so I added
process terminate
But nothing changes. I tried to debug the code but not chance.
I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem.
But again no chance.
So did I miss something obvious?
Stef
--
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140405/1e881c1c/attachment.html>
Continue reading on narkive:
Loading...