Fix the continue back into GTK/Event-Loop/C-code

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Fix the continue back into GTK/Event-Loop/C-code

Gwenaël Casaccio
Hi,

here is a patch that fix the continue back into GTK/Event-Loop/C-code
(with the debugger and text widget).

Cheers,
Gwen


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

0001-Makes-the-debugger-text-widget-non-blocking-and-fix-.patch (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fix the continue back into GTK/Event-Loop/C-code

Holger Freyther
On Mon, Oct 21, 2013 at 12:55:16PM +0200, Gwenaël Casaccio wrote:
> Hi,
>
> here is a patch that fix the continue back into GTK/Event-Loop/C-code
> (with the debugger and text widget).

thank you very much!


> -        self isLastContextSelected ifFalse: [ self stepToSelectedContext ].
> -        debugger step.
> -        self updateContextWidget
> +        TaskQueue uniqueInstance add: [
> +            self isLastContextSelected ifFalse: [ self stepToSelectedContext ].
> +            debugger step.
> +            self updateContextWidget ]

after having looked at the blox code, what do you think about something
like this:


        self debugWith: [debugger step]

and

        debugWith: aBlock [
                TaskQueue uniqueInstance add: [
                        self isLastContextSelected ..
                        aBlock value.
                        self updateContextWidget
                ]
        ]

?

> +    run [
> +        <category: 'accessing'>
> +
> +        [ | task sem |
> +          sem := Semaphore new.
> +          [ queue peek.
> +            [ queue isEmpty ] whileFalse: [
> +              task := queue next.
> +              [ task ensure: [ sem signal ] ] fork"At: Processor userBackgroundPriority".
> +              sem wait ] ] repeat ] fork
> +    ]

* What prevents the VM to gc this process?
* I assume the queue peek can be removed? Same for the "At:.." comment?
* After looking into "updating" code at runtime I try to avoid having
  too much code in a '[] repeat'





_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Fix the continue back into GTK/Event-Loop/C-code

Gwenaël Casaccio
On 22/10/2013 23:44, Holger Hans Peter Freyther wrote:

> On Mon, Oct 21, 2013 at 12:55:16PM +0200, Gwenaël Casaccio wrote:
>> Hi,
>>
>> here is a patch that fix the continue back into GTK/Event-Loop/C-code
>> (with the debugger and text widget).
> thank you very much!
>
>
>> -        self isLastContextSelected ifFalse: [ self stepToSelectedContext ].
>> -        debugger step.
>> -        self updateContextWidget
>> +        TaskQueue uniqueInstance add: [
>> +            self isLastContextSelected ifFalse: [ self stepToSelectedContext ].
>> +            debugger step.
>> +            self updateContextWidget ]
> after having looked at the blox code, what do you think about something
> like this:
>
>
> self debugWith: [debugger step]
>
> and
>
> debugWith: aBlock [
> TaskQueue uniqueInstance add: [
> self isLastContextSelected ..
> aBlock value.
> self updateContextWidget
> ]
> ]
>
> ?
>
>> +    run [
>> +        <category: 'accessing'>
>> +
>> +        [ | task sem |
>> +          sem := Semaphore new.
>> +          [ queue peek.
>> +            [ queue isEmpty ] whileFalse: [
>> +              task := queue next.
>> +              [ task ensure: [ sem signal ] ] fork"At: Processor userBackgroundPriority".
>> +              sem wait ] ] repeat ] fork
>> +    ]
> * What prevents the VM to gc this process?
I don't see why the vm would gc the process
> * I assume the queue peek can be removed? Same for the "At:.." comment?
even better:

+    run [
+        <category: 'accessing'>
+
+        [ | task sem |
+          sem := Semaphore new.
+          [ task := queue next.
+            [ task ensure: [ sem signal ] ] fork.
+            sem wait ] repeat ] fork
+    ]

> * After looking into "updating" code at runtime I try to avoid having
>    too much code in a '[] repeat'
yeah
>
>
>


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Fix the continue back into GTK/Event-Loop/C-code

Holger Freyther
In reply to this post by Gwenaël Casaccio
On Mon, Oct 21, 2013 at 12:55:16PM +0200, Gwenaël Casaccio wrote:
> Hi,
>
> here is a patch that fix the continue back into GTK/Event-Loop/C-code
> (with the debugger and text widget).

Good Morning,

I think I manage to break the TaskQueue

Repeat:
Open Workspace
'1234' do: [:each | each asUpperCase] ALT+D/DebugIt
Step until the BlockClosure is executed

select "each asUpperCase" CTRL+I => UndefinedObject
select "each" CTRL+I => Character

in the Inspector type
self upperCase CTRL+P Debugger comes up
self upperCase CTRL+P nothing

Result:
Stepping in the debugger is broken, DoIt's don't
appear to work either.


Proposition:
* Name the forked process (so one can identify it)
* Keep the process in a local variable so one can
  more easily find the process.

thanks
        holger



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Fix the continue back into GTK/Event-Loop/C-code

Gwenaël Casaccio
On 24/10/2013 07:40, Holger Hans Peter Freyther wrote:

> On Mon, Oct 21, 2013 at 12:55:16PM +0200, Gwenaël Casaccio wrote:
>> Hi,
>>
>> here is a patch that fix the continue back into GTK/Event-Loop/C-code
>> (with the debugger and text widget).
> Good Morning,
>
> I think I manage to break the TaskQueue
>
> Repeat:
> Open Workspace
> '1234' do: [:each | each asUpperCase] ALT+D/DebugIt
> Step until the BlockClosure is executed
>
> select "each asUpperCase" CTRL+I => UndefinedObject
> select "each" CTRL+I => Character
>
> in the Inspector type
> self upperCase CTRL+P Debugger comes up
> self upperCase CTRL+P nothing
>
> Result:
> Stepping in the debugger is broken, DoIt's don't
> appear to work either.

I think this is because it's executed in the debugger and the debugger
is not reentrant

>
> Proposition:
> * Name the forked process (so one can identify it)
> * Keep the process in a local variable so one can
>    more easily find the process.
>
> thanks
> holger
>
>


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Fix the continue back into GTK/Event-Loop/C-code

Gwenaël Casaccio
In reply to this post by Holger Freyther
On 24/10/2013 07:40, Holger Hans Peter Freyther wrote:

> On Mon, Oct 21, 2013 at 12:55:16PM +0200, Gwenaël Casaccio wrote:
>> Hi,
>>
>> here is a patch that fix the continue back into GTK/Event-Loop/C-code
>> (with the debugger and text widget).
> Good Morning,
>
> I think I manage to break the TaskQueue
>
> Repeat:
> Open Workspace
> '1234' do: [:each | each asUpperCase] ALT+D/DebugIt
> Step until the BlockClosure is executed
>
> select "each asUpperCase" CTRL+I => UndefinedObject
> select "each" CTRL+I => Character
>
> in the Inspector type
> self upperCase CTRL+P Debugger comes up
> self upperCase CTRL+P nothing
>
> Result:
> Stepping in the debugger is broken, DoIt's don't
> appear to work either.
>
>
> Proposition:
> * Name the forked process (so one can identify it)
> * Keep the process in a local variable so one can
>    more easily find the process.
Forgot to say I agree about your proposal :)
>
> thanks
> holger
>
>


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Fix the continue back into GTK/Event-Loop/C-code

Gwenaël Casaccio
In reply to this post by Holger Freyther
On 24/10/2013 07:40, Holger Hans Peter Freyther wrote:

> On Mon, Oct 21, 2013 at 12:55:16PM +0200, Gwenaël Casaccio wrote:
>> Hi,
>>
>> here is a patch that fix the continue back into GTK/Event-Loop/C-code
>> (with the debugger and text widget).
> Good Morning,
>
> I think I manage to break the TaskQueue
>
> Repeat:
> Open Workspace
> '1234' do: [:each | each asUpperCase] ALT+D/DebugIt
> Step until the BlockClosure is executed
>
> select "each asUpperCase" CTRL+I => UndefinedObject
> select "each" CTRL+I => Character
>
> in the Inspector type
> self upperCase CTRL+P Debugger comes up
> self upperCase CTRL+P nothing
>
> Result:
> Stepping in the debugger is broken, DoIt's don't
> appear to work either.
>
>
> Proposition:
> * Name the forked process (so one can identify it)
> * Keep the process in a local variable so one can
>    more easily find the process.
>
> thanks
> holger
>
>
Here is a new version with your proposal changes included inside it
and a new event loop which doesn't use ensure like the last eval patch.

Gwen



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

0001-Makes-the-debugger-text-widget-non-blocking-and-fix-.patch (38K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fix the continue back into GTK/Event-Loop/C-code

Gwenaël Casaccio
On 29/10/2013 14:58, Gwenaël Casaccio wrote:

> On 24/10/2013 07:40, Holger Hans Peter Freyther wrote:
>> On Mon, Oct 21, 2013 at 12:55:16PM +0200, Gwenaël Casaccio wrote:
>>> Hi,
>>>
>>> here is a patch that fix the continue back into GTK/Event-Loop/C-code
>>> (with the debugger and text widget).
>> Good Morning,
>>
>> I think I manage to break the TaskQueue
>>
>> Repeat:
>> Open Workspace
>> '1234' do: [:each | each asUpperCase] ALT+D/DebugIt
>> Step until the BlockClosure is executed
>>
>> select "each asUpperCase" CTRL+I => UndefinedObject
>> select "each" CTRL+I => Character
>>
>> in the Inspector type
>> self upperCase CTRL+P Debugger comes up
>> self upperCase CTRL+P nothing
>>
>> Result:
>> Stepping in the debugger is broken, DoIt's don't
>> appear to work either.
>>
>>
>> Proposition:
>> * Name the forked process (so one can identify it)
>> * Keep the process in a local variable so one can
>>    more easily find the process.
>>
>> thanks
>>     holger
>>
>>
>
> Here is a new version with your proposal changes included inside it
> and a new event loop which doesn't use ensure like the last eval patch.
>
> Gwen
>
>
I hope it's the last increment :) I've discovered that
Behavior>>#evaluate: used
valueWithUnwind and that cause an issue with the task queue. I use my onw
eval code which doesn't use valueWithUnwind.

Cheers,
Gwen


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

0001-Makes-the-debugger-text-widget-non-blocking-and-fix-.patch (39K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fix the continue back into GTK/Event-Loop/C-code

baulamon
In reply to this post by Gwenaël Casaccio
Hello,
I think this is because it's executed in the debugger and the debugger
is not reentrant