Hi all, after wrapping the current implementation which I test and packaged in the experimental polymorph image I tried to install it in the newest Pharo image and it doesn't work (freezes). Anyone a suggestion what might have changed in the area of event handling or process management? I started going through the different classes but maybe somebody has a hint where to look? As reward there will be no more EventSensor and EventTicklerProcess :-) Thanks Michael
2008/11/22 Michael Rueger <m.rueger@acm.org>:
Hi all,
after wrapping the current implementation which I test and packaged in the experimental polymorph image I tried to install it in the newest Pharo image and it doesn't work (freezes).
Anyone a suggestion what might have changed in the area of event handling or process management? I started going through the different classes but maybe somebody has a hint where to look?
There some problems reported recently with class defs/traits. Maybe you were unlucky with it :)
As reward there will be no more EventSensor and EventTicklerProcess :-)
Awaiting release!
Thanks
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Michael Rueger wrote:
Hi all,
after wrapping the current implementation which I test and packaged in the experimental polymorph image I tried to install it in the newest Pharo image and it doesn't work (freezes).
It actually doesn't freeze but seems to hang in a delay in WorldState... alt-. pops a debugger, but so input events are fetched from the VM, but Morphic doesn's seem to pick them up anymore... OK, more hunting... Michael
gets weirder... mouse move events work (buttons react to mouse over) typing in the debugger works, but no mouse clicks... Michael
Hi all, finally got it. Turned out to be related to the host window/menu work, the window index slot needed to be set to 1 if 0. Sigh... Attached is a change set that installs the new logic into a recent Pharo image. I'm not sure if and how we can get the install into a package load, but this version is for the adventurous types anyways :-) A few remarks about the new sensor architecture (need to put this into the class comments). First what's not changed, which is the morphic side. HandMorph still polls for nextEvent and also all old polling methods are still supported and heavily used in the image. Basically the input event handling has been split into two parts: one event fetcher and event handlers. The event fetcher fetches events from the even and currently still polls. Next step will be to get the input semaphore signaling working. The event fetcher then signals the event to all registered event handlers. In the current version there are two: the new morphic sensor and the user interrupt handler. Events currently are handled multiple times (rather their copies), we might need to change that later. There needs to be some work done on how the user interrupt handler works, I had some problems with launching the debugger, but that might have been a problem in my development image. It would be helpful though, if the VM would provide information about the interrupted process as it does (or should do?) for the low space watcher. So much for now, questions welcome and happy testing :-) Michael
The problem with your .cs that it can't work on windoze VM because it never signals input semaphore :( eventLoop "Fetch pending raw events from the VM. This method is run at high priority." [true] whileTrue: [ | eventBuffer type | inputSemaphore wait. <<<<< will stall here forever. An old EventSensor periodically polls events manually at some predefined period. As temporary measure, i suggest to put "self waitForInput" instead of "inputSemaphore wait" to make it easy to switch between old/new versions without intruding into the rest of code. 2008/11/22 Michael Rueger <m.rueger@acm.org>:
The event fetcher fetches events from the even and currently still
from the VM that is
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Nov 21, 2008, at 11:18 PM, Michael Rueger wrote:
Hi all,
after wrapping the current implementation which I test and packaged in the experimental polymorph image I tried to install it in the newest Pharo image and it doesn't work (freezes).
Anyone a suggestion what might have changed in the area of event handling or process management? I started going through the different classes but maybe somebody has a hint where to look?
For process management there is the special array stuff and the per process variable that marcus havrested.
As reward there will be no more EventSensor and EventTicklerProcess :-)
:) We would love this christams gift.
Thanks
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
My freeze was a bit similar. apple . did not work but I was surpirse to see a browser coming back to life. On Nov 21, 2008, at 11:34 PM, Michael Rueger wrote:
Michael Rueger wrote:
Hi all, after wrapping the current implementation which I test and packaged in the experimental polymorph image I tried to install it in the newest Pharo image and it doesn't work (freezes).
It actually doesn't freeze but seems to hang in a delay in WorldState... alt-. pops a debugger, but so input events are fetched from the VM, but Morphic doesn's seem to pick them up anymore... OK, more hunting...
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Nov 22, 2008, at 3:31 AM, Michael Rueger wrote:
Hi all,
finally got it. Turned out to be related to the host window/menu work, the window index slot needed to be set to 1 if 0. Sigh...
Attached is a change set that installs the new logic into a recent Pharo image. I'm not sure if and how we can get the install into a package load, but this version is for the adventurous types anyways :-)
we do not have to only use mcz :)
A few remarks about the new sensor architecture (need to put this into the class comments).
First what's not changed, which is the morphic side. HandMorph still polls for nextEvent and also all old polling methods are still supported and heavily used in the image.
Basically the input event handling has been split into two parts: one event fetcher and event handlers.
The event fetcher fetches events from the even and currently still polls. Next step will be to get the input semaphore signaling working.
The event fetcher then signals the event to all registered event handlers. In the current version there are two: the new morphic sensor and the user interrupt handler.
Events currently are handled multiple times (rather their copies), we might need to change that later.
There needs to be some work done on how the user interrupt handler works, I had some problems with launching the debugger, but that might have been a problem in my development image. It would be helpful though, if the VM would provide information about the interrupted process as it does (or should do?) for the low space watcher.
So much for now, questions welcome and happy testing :-)
Michael <new-sensor-mir.cs.gz>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing? Stef On Nov 22, 2008, at 3:33 AM, Michael Rueger wrote:
The event fetcher fetches events from the even and currently still
from the VM that is
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi mike I read the code with emacs (without chekcing the differences) 1- Here I have a question =================== in this comment EventSensor = InputEventSensor? I found it confusing to me especially when you know a little to the previous architecture and the the new one. !InputEventSensor commentStamp: 'mir 8/14/2008 14:16' prior: 0! An InputEventSensor is xxxxxxxxx. EventSensor is a replacement for InputSensor based on a set of (optional) event primitives. An EventSensor updates its state when events are received so that all state based users of Sensor (e.g., Sensor keyboard, Sensor leftShiftDown, Sensor mouseButtons) will work exactly as before, by moving the current VM mechanisms into EventSensor itself. An optional input semaphore is part of the new design. 2- I saw a method defined on Controller But there are no reference to this class in pharo. So we could remove Controller I imagine 3- could you tell me what kind of code we would have to change? So that I can evaluate the task? On Nov 22, 2008, at 3:31 AM, Michael Rueger wrote:
Hi all,
finally got it. Turned out to be related to the host window/menu work, the window index slot needed to be set to 1 if 0. Sigh...
Attached is a change set that installs the new logic into a recent Pharo image. I'm not sure if and how we can get the install into a package load, but this version is for the adventurous types anyways :-)
A few remarks about the new sensor architecture (need to put this into the class comments).
First what's not changed, which is the morphic side. HandMorph still polls for nextEvent and also all old polling methods are still supported and heavily used in the image.
Basically the input event handling has been split into two parts: one event fetcher and event handlers.
The event fetcher fetches events from the even and currently still polls. Next step will be to get the input semaphore signaling working.
The event fetcher then signals the event to all registered event handlers. In the current version there are two: the new morphic sensor and the user interrupt handler.
Events currently are handled multiple times (rather their copies), we might need to change that later.
There needs to be some work done on how the user interrupt handler works, I had some problems with launching the debugger, but that might have been a problem in my development image. It would be helpful though, if the VM would provide information about the interrupted process as it does (or should do?) for the low space watcher.
So much for now, questions welcome and happy testing :-)
Michael <new-sensor-mir.cs.gz>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/11/22 Stéphane Ducasse <stephane.ducasse@inria.fr>:
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing?
As soon as possible. I want to continue hacking hostwindows based on this new code. :)
Stef On Nov 22, 2008, at 3:33 AM, Michael Rueger wrote:
The event fetcher fetches events from the even and currently still
from the VM that is
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Stéphane Ducasse wrote:
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing?
this version is really meant to be smoke tested, it needs some work on the comments and on the user interrupt handling. So please load it into your images, make sure you always have backups and see how it holds up. If it turns out to be reasonably stable we can push it.
1- Here I have a question =================== in this comment EventSensor = InputEventSensor?
the comment is only a copy from EventSensor, needs to be rewritten. If somebody has a better suggestion for naming this class I'm open to suggestions.
2- I saw a method defined on Controller But there are no reference to this class in pharo. So we could remove Controller I imagine
It is superclass of other classes, so I'm not sure.
3- could you tell me what kind of code we would have to change?
Not sure what you mean? For now no code in the image needs to be changed. Michael
I just loaded your changeset and have something to report :) It looks like it having bigger poll periods than old sensor, or works slower. An overall performance feels a bit more sluggish comparing to old implementation. Just open a window with long text and hold down the up/down key and see the difference. Or try to resize browser window - you can notice its not so smooth as in old image. 2008/11/22 Michael Rueger <m.rueger@acm.org>:
Stéphane Ducasse wrote:
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing?
this version is really meant to be smoke tested, it needs some work on the comments and on the user interrupt handling.
So please load it into your images, make sure you always have backups and see how it holds up. If it turns out to be reasonably stable we can push it.
1- Here I have a question =================== in this comment EventSensor = InputEventSensor?
the comment is only a copy from EventSensor, needs to be rewritten. If somebody has a better suggestion for naming this class I'm open to suggestions.
2- I saw a method defined on Controller But there are no reference to this class in pharo. So we could remove Controller I imagine
It is superclass of other classes, so I'm not sure.
3- could you tell me what kind of code we would have to change?
Not sure what you mean? For now no code in the image needs to be changed.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2008/11/22 Igor Stasenko <siguctua@gmail.com>:
I just loaded your changeset and have something to report :)
It looks like it having bigger poll periods than old sensor, or works slower. An overall performance feels a bit more sluggish comparing to old implementation. Just open a window with long text and hold down the up/down key and see the difference. Or try to resize browser window - you can notice its not so smooth as in old image.
... which can be fixed easily by reducing poll period from 100ms to 10ms in InputEventPollingFetcher>>eventLoop
2008/11/22 Michael Rueger <m.rueger@acm.org>:
Stéphane Ducasse wrote:
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing?
this version is really meant to be smoke tested, it needs some work on the comments and on the user interrupt handling.
So please load it into your images, make sure you always have backups and see how it holds up. If it turns out to be reasonably stable we can push it.
1- Here I have a question =================== in this comment EventSensor = InputEventSensor?
the comment is only a copy from EventSensor, needs to be rewritten. If somebody has a better suggestion for naming this class I'm open to suggestions.
2- I saw a method defined on Controller But there are no reference to this class in pharo. So we could remove Controller I imagine
It is superclass of other classes, so I'm not sure.
3- could you tell me what kind of code we would have to change?
Not sure what you mean? For now no code in the image needs to be changed.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On Nov 22, 2008, at 7:13 PM, Igor Stasenko wrote:
I just loaded your changeset and have something to report :)
It looks like it having bigger poll periods than old sensor, or works slower. An overall performance feels a bit more sluggish comparing to old implementation. Just open a window with long text and hold down the up/down key and see the difference. Or try to resize browser window - you can notice its not so smooth as in old image.
I got the same feeling but I have the impression that it was less important than what igor reported. But I had the impression that everything was a bit slower
2008/11/22 Michael Rueger <m.rueger@acm.org>:
Stéphane Ducasse wrote:
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing?
this version is really meant to be smoke tested, it needs some work on the comments and on the user interrupt handling.
So please load it into your images, make sure you always have backups and see how it holds up. If it turns out to be reasonably stable we can push it.
1- Here I have a question =================== in this comment EventSensor = InputEventSensor?
the comment is only a copy from EventSensor, needs to be rewritten. If somebody has a better suggestion for naming this class I'm open to suggestions.
2- I saw a method defined on Controller But there are no reference to this class in pharo. So we could remove Controller I imagine
It is superclass of other classes, so I'm not sure.
3- could you tell me what kind of code we would have to change?
Not sure what you mean? For now no code in the image needs to be changed.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
and looks like InputEventFetcher>>eventLoop contains syntax errors, a window variable shown in red color by my browser. :) 2008/11/22 Igor Stasenko <siguctua@gmail.com>:
2008/11/22 Igor Stasenko <siguctua@gmail.com>:
I just loaded your changeset and have something to report :)
It looks like it having bigger poll periods than old sensor, or works slower. An overall performance feels a bit more sluggish comparing to old implementation. Just open a window with long text and hold down the up/down key and see the difference. Or try to resize browser window - you can notice its not so smooth as in old image.
... which can be fixed easily by reducing poll period from 100ms to 10ms in InputEventPollingFetcher>>eventLoop
2008/11/22 Michael Rueger <m.rueger@acm.org>:
Stéphane Ducasse wrote:
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing?
this version is really meant to be smoke tested, it needs some work on the comments and on the user interrupt handling.
So please load it into your images, make sure you always have backups and see how it holds up. If it turns out to be reasonably stable we can push it.
1- Here I have a question =================== in this comment EventSensor = InputEventSensor?
the comment is only a copy from EventSensor, needs to be rewritten. If somebody has a better suggestion for naming this class I'm open to suggestions.
2- I saw a method defined on Controller But there are no reference to this class in pharo. So we could remove Controller I imagine
It is superclass of other classes, so I'm not sure.
3- could you tell me what kind of code we would have to change?
Not sure what you mean? For now no code in the image needs to be changed.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
Stéphane Ducasse wrote:
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing?
this version is really meant to be smoke tested, it needs some work on the comments and on the user interrupt handling.
Ok I will test it
So please load it into your images, make sure you always have backups and see how it holds up. If it turns out to be reasonably stable we can push it.
1- Here I have a question =================== in this comment EventSensor = InputEventSensor?
the comment is only a copy from EventSensor, needs to be rewritten. If somebody has a better suggestion for naming this class I'm open to suggestions.
2- I saw a method defined on Controller But there are no reference to this class in pharo. So we could remove Controller I imagine
It is superclass of other classes, so I'm not sure.
I will check.
3- could you tell me what kind of code we would have to change?
Not sure what you mean? For now no code in the image needs to be changed.
I was already thinking about the next steps. I was wondering what kind of patterns the code to change was looking like.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Here the further changes to fix above. 2008/11/22 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Nov 22, 2008, at 7:13 PM, Igor Stasenko wrote:
I just loaded your changeset and have something to report :)
It looks like it having bigger poll periods than old sensor, or works slower. An overall performance feels a bit more sluggish comparing to old implementation. Just open a window with long text and hold down the up/down key and see the difference. Or try to resize browser window - you can notice its not so smooth as in old image.
I got the same feeling but I have the impression that it was less important than what igor reported. But I had the impression that everything was a bit slower
2008/11/22 Michael Rueger <m.rueger@acm.org>:
Stéphane Ducasse wrote:
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing?
this version is really meant to be smoke tested, it needs some work on the comments and on the user interrupt handling.
So please load it into your images, make sure you always have backups and see how it holds up. If it turns out to be reasonably stable we can push it.
1- Here I have a question =================== in this comment EventSensor = InputEventSensor?
the comment is only a copy from EventSensor, needs to be rewritten. If somebody has a better suggestion for naming this class I'm open to suggestions.
2- I saw a method defined on Controller But there are no reference to this class in pharo. So we could remove Controller I imagine
It is superclass of other classes, so I'm not sure.
3- could you tell me what kind of code we would have to change?
Not sure what you mean? For now no code in the image needs to be changed.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Stéphane Ducasse wrote:
3- could you tell me what kind of code we would have to change?
Not sure what you mean? For now no code in the image needs to be changed.
I was already thinking about the next steps. I was wondering what kind of patterns the code to change was looking like.
The big question is whether we really want to clean up Morphic as it is or start putting in a new UI framework. The new input event architecture allows us to plug in in other UI and event systems without the need to touch Morphic. So one of the next things I will try to do is get Miro loaded into Morphic and also my ySqueak (formerly iSqueak) framework. But the latter relies on a lot more system changes than Miro IIRC, so it might take some time. Michael
2008/11/22 Michael Rueger <m.rueger@acm.org>:
Igor Stasenko wrote:
Here the further changes to fix above.
Thanks, nice refactoring!
There is no need though to keep the delay in a class variable, the instance variable would be just fine.
Well, its on class side because if you type: InputEventFetcher default eventPollPeriod: xx may not work, depending on what type of event fetcher currently working. While InputEventPollingFetcher eventPollPeriod: xx will work always.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2008/11/22 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Stéphane Ducasse wrote:
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing?
this version is really meant to be smoke tested, it needs some work on the comments and on the user interrupt handling.
Ok I will test it
So please load it into your images, make sure you always have backups and see how it holds up. If it turns out to be reasonably stable we can push it.
1- Here I have a question =================== in this comment EventSensor = InputEventSensor?
the comment is only a copy from EventSensor, needs to be rewritten. If somebody has a better suggestion for naming this class I'm open to suggestions.
2- I saw a method defined on Controller But there are no reference to this class in pharo. So we could remove Controller I imagine
It is superclass of other classes, so I'm not sure.
I will check.
3- could you tell me what kind of code we would have to change?
Not sure what you mean? For now no code in the image needs to be changed.
I was already thinking about the next steps. I was wondering what kind of patterns the code to change was looking like.
A next stage, would be to refactor MorphicEvent & subclasses and move them into category Kernel-Events and then change EventSensor to convert raw events into nice XXXEvent instances, so the rest of image wouldn't have to deal with raw event buffers anymore.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Indeed
I was wondering what kind of patterns the code to change was looking like.
The big question is whether we really want to clean up Morphic as it is or start putting in a new UI framework. The new input event architecture allows us to plug in in other UI and event systems without the need to touch Morphic. So one of the next things I will try to do is get Miro loaded into Morphic and also my ySqueak (formerly iSqueak) framework. But the latter relies on a lot more system changes than Miro IIRC, so it might take some time.
Ok I know that alain was looking for a layout engine. Stef
I read it correctly :) Stef On Nov 22, 2008, at 7:46 PM, Michael Rueger wrote:
Michael Rueger wrote:
So one of the next things I will try to do is get Miro loaded into Morphic and also my ySqueak (formerly iSqueak) framework. But the latter
into Pharo of course
Need...more...caffeine....
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Igor Stasenko wrote:
A next stage, would be to refactor MorphicEvent & subclasses and move them into category Kernel-Events and then change EventSensor to convert raw events into nice XXXEvent instances, so the rest of image wouldn't have to deal with raw event buffers anymore.
Yes, although a thought would be to add a separate API on the new sensor for fetching the "real" events and migrate the system over step by step. And for those events we might want to use the new event hierarchy from Miro and ySqueak, they turned out to be almost identical :-) Michael
Well I've not had a enough coffee to understand all the implications yet. (a) I wonder how fast getNextEvent is being called because that on some platforms calls aioPoll() to service socket interrupts. Some study will be required to understand the impact. (b) A smoke test of CPU usage shows that a pharo image with only the pharo graphic showing. runs with about 20% LESS CPU usage from an idle VM perspective. 1.8% of the cpu versus 2.2% for example. On 21-Nov-08, at 6:31 PM, Michael Rueger wrote:
Hi all,
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Unexplained SyntaxErrors are often, in my experience, a sign of multiple processes concurrently trying to access the changes file... Have the improvements we supplied for RemoteString been applied? Regards, Gary. ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Saturday, November 22, 2008 6:20 PM Subject: Re: [Pharo-project] New sensor code
and looks like InputEventFetcher>>eventLoop contains syntax errors, a window variable shown in red color by my browser. :)
2008/11/22 Igor Stasenko <siguctua@gmail.com>:
2008/11/22 Igor Stasenko <siguctua@gmail.com>:
I just loaded your changeset and have something to report :)
It looks like it having bigger poll periods than old sensor, or works slower. An overall performance feels a bit more sluggish comparing to old implementation. Just open a window with long text and hold down the up/down key and see the difference. Or try to resize browser window - you can notice its not so smooth as in old image.
... which can be fixed easily by reducing poll period from 100ms to 10ms in InputEventPollingFetcher>>eventLoop
2008/11/22 Michael Rueger <m.rueger@acm.org>:
Stéphane Ducasse wrote:
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing?
this version is really meant to be smoke tested, it needs some work on the comments and on the user interrupt handling.
So please load it into your images, make sure you always have backups and see how it holds up. If it turns out to be reasonably stable we can push it.
1- Here I have a question =================== in this comment EventSensor = InputEventSensor?
the comment is only a copy from EventSensor, needs to be rewritten. If somebody has a better suggestion for naming this class I'm open to suggestions.
2- I saw a method defined on Controller But there are no reference to this class in pharo. So we could remove Controller I imagine
It is superclass of other classes, so I'm not sure.
3- could you tell me what kind of code we would have to change?
Not sure what you mean? For now no code in the image needs to be changed.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
--------------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 24.11.2008, at 12:09, Gary Chambers wrote:
Unexplained SyntaxErrors are often, in my experience, a sign of multiple processes concurrently trying to access the changes file... Have the improvements we supplied for RemoteString been applied?
Yes. Marcus
Regards, Gary.
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Saturday, November 22, 2008 6:20 PM Subject: Re: [Pharo-project] New sensor code
and looks like InputEventFetcher>>eventLoop contains syntax errors, a window variable shown in red color by my browser. :)
2008/11/22 Igor Stasenko <siguctua@gmail.com>:
2008/11/22 Igor Stasenko <siguctua@gmail.com>:
I just loaded your changeset and have something to report :)
It looks like it having bigger poll periods than old sensor, or works slower. An overall performance feels a bit more sluggish comparing to old implementation. Just open a window with long text and hold down the up/down key and see the difference. Or try to resize browser window - you can notice its not so smooth as in old image.
... which can be fixed easily by reducing poll period from 100ms to 10ms in InputEventPollingFetcher>>eventLoop
2008/11/22 Michael Rueger <m.rueger@acm.org>:
Stéphane Ducasse wrote:
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing?
this version is really meant to be smoke tested, it needs some work on the comments and on the user interrupt handling.
So please load it into your images, make sure you always have backups and see how it holds up. If it turns out to be reasonably stable we can push it.
1- Here I have a question =================== in this comment EventSensor = InputEventSensor?
the comment is only a copy from EventSensor, needs to be rewritten. If somebody has a better suggestion for naming this class I'm open to suggestions.
2- I saw a method defined on Controller But there are no reference to this class in pharo. So we could remove Controller I imagine
It is superclass of other classes, so I'm not sure.
3- could you tell me what kind of code we would have to change?
Not sure what you mean? For now no code in the image needs to be changed.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
--------------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
Perhaps two processes are *writing* to the change log at the same time then (shudders). Regards, Gary. ----- Original Message ----- From: "Marcus Denker" <denker@iam.unibe.ch> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Monday, November 24, 2008 11:13 AM Subject: Re: [Pharo-project] New sensor code On 24.11.2008, at 12:09, Gary Chambers wrote:
Unexplained SyntaxErrors are often, in my experience, a sign of multiple processes concurrently trying to access the changes file... Have the improvements we supplied for RemoteString been applied?
Yes. Marcus
Regards, Gary.
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Saturday, November 22, 2008 6:20 PM Subject: Re: [Pharo-project] New sensor code
and looks like InputEventFetcher>>eventLoop contains syntax errors, a window variable shown in red color by my browser. :)
2008/11/22 Igor Stasenko <siguctua@gmail.com>:
2008/11/22 Igor Stasenko <siguctua@gmail.com>:
I just loaded your changeset and have something to report :)
It looks like it having bigger poll periods than old sensor, or works slower. An overall performance feels a bit more sluggish comparing to old implementation. Just open a window with long text and hold down the up/down key and see the difference. Or try to resize browser window - you can notice its not so smooth as in old image.
... which can be fixed easily by reducing poll period from 100ms to 10ms in InputEventPollingFetcher>>eventLoop
2008/11/22 Michael Rueger <m.rueger@acm.org>:
Stéphane Ducasse wrote:
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing?
this version is really meant to be smoke tested, it needs some work on the comments and on the user interrupt handling.
So please load it into your images, make sure you always have backups and see how it holds up. If it turns out to be reasonably stable we can push it.
1- Here I have a question =================== in this comment EventSensor = InputEventSensor?
the comment is only a copy from EventSensor, needs to be rewritten. If somebody has a better suggestion for naming this class I'm open to suggestions.
2- I saw a method defined on Controller But there are no reference to this class in pharo. So we could remove Controller I imagine
It is superclass of other classes, so I'm not sure.
3- could you tell me what kind of code we would have to change?
Not sure what you mean? For now no code in the image needs to be changed.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
--------------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I saw signs of that problem in the recent past. stef On Nov 24, 2008, at 12:25 PM, Gary Chambers wrote:
Perhaps two processes are *writing* to the change log at the same time then (shudders).
Regards, Gary.
----- Original Message ----- From: "Marcus Denker" <denker@iam.unibe.ch
To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Monday, November 24, 2008 11:13 AM Subject: Re: [Pharo-project] New sensor code
On 24.11.2008, at 12:09, Gary Chambers wrote:
Unexplained SyntaxErrors are often, in my experience, a sign of multiple processes concurrently trying to access the changes file... Have the improvements we supplied for RemoteString been applied?
Yes.
Marcus
Regards, Gary.
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com
To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Saturday, November 22, 2008 6:20 PM Subject: Re: [Pharo-project] New sensor code
and looks like InputEventFetcher>>eventLoop contains syntax errors, a window variable shown in red color by my browser. :)
2008/11/22 Igor Stasenko <siguctua@gmail.com>:
2008/11/22 Igor Stasenko <siguctua@gmail.com>:
I just loaded your changeset and have something to report :)
It looks like it having bigger poll periods than old sensor, or works slower. An overall performance feels a bit more sluggish comparing to old implementation. Just open a window with long text and hold down the up/down key and see the difference. Or try to resize browser window - you can notice its not so smooth as in old image.
... which can be fixed easily by reducing poll period from 100ms to 10ms in InputEventPollingFetcher>>eventLoop
2008/11/22 Michael Rueger <m.rueger@acm.org>:
Stéphane Ducasse wrote:
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing?
this version is really meant to be smoke tested, it needs some work on the comments and on the user interrupt handling.
So please load it into your images, make sure you always have backups and see how it holds up. If it turns out to be reasonably stable we can push it.
1- Here I have a question =================== in this comment EventSensor = InputEventSensor?
the comment is only a copy from EventSensor, needs to be rewritten. If somebody has a better suggestion for naming this class I'm open to suggestions.
2- I saw a method defined on Controller But there are no reference to this class in pharo. So we could remove Controller I imagine
It is superclass of other classes, so I'm not sure.
3- could you tell me what kind of code we would have to change?
Not sure what you mean? For now no code in the image needs to be changed.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
--------------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/11/24 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I saw signs of that problem in the recent past.
me too. Its because the interface which managing .changes file stream is not protected by synchronizing object.
stef
On Nov 24, 2008, at 12:25 PM, Gary Chambers wrote:
Perhaps two processes are *writing* to the change log at the same time then (shudders).
Regards, Gary.
----- Original Message ----- From: "Marcus Denker" <denker@iam.unibe.ch> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Monday, November 24, 2008 11:13 AM Subject: Re: [Pharo-project] New sensor code
On 24.11.2008, at 12:09, Gary Chambers wrote:
Unexplained SyntaxErrors are often, in my experience, a sign of multiple processes concurrently trying to access the changes file... Have the improvements we supplied for RemoteString been applied?
Yes.
Marcus
Regards, Gary.
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Saturday, November 22, 2008 6:20 PM Subject: Re: [Pharo-project] New sensor code
and looks like InputEventFetcher>>eventLoop contains syntax errors, a window variable shown in red color by my browser. :)
2008/11/22 Igor Stasenko <siguctua@gmail.com>:
2008/11/22 Igor Stasenko <siguctua@gmail.com>:
I just loaded your changeset and have something to report :)
It looks like it having bigger poll periods than old sensor, or works slower. An overall performance feels a bit more sluggish comparing to old implementation. Just open a window with long text and hold down the up/down key and see the difference. Or try to resize browser window - you can notice its not so smooth as in old image.
... which can be fixed easily by reducing poll period from 100ms to 10ms in InputEventPollingFetcher>>eventLoop
2008/11/22 Michael Rueger <m.rueger@acm.org>:
Stéphane Ducasse wrote:
so how do we proceed? We try to load it, play with it then? integrate it into pharo and you continue hacking and fixing?
this version is really meant to be smoke tested, it needs some work on the comments and on the user interrupt handling.
So please load it into your images, make sure you always have backups and see how it holds up. If it turns out to be reasonably stable we can push it.
1- Here I have a question =================== in this comment EventSensor = InputEventSensor?
the comment is only a copy from EventSensor, needs to be rewritten. If somebody has a better suggestion for naming this class I'm open to suggestions.
2- I saw a method defined on Controller But there are no reference to this class in pharo. So we could remove Controller I imagine
It is superclass of other classes, so I'm not sure.
3- could you tell me what kind of code we would have to change?
Not sure what you mean? For now no code in the image needs to be changed.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
--------------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (6)
-
Gary Chambers -
Igor Stasenko -
John M McIntosh -
Marcus Denker -
Michael Rueger -
Stéphane Ducasse