Tim,
I don't care much how the details are done so long as they work
Well, I do if it's such a critical piece of the system :-) That's basically why I put this out for discussion first.
[Re: ST oops]
Huh? It makes SmallIntegers (or potentially LPIs I guess). What's the problem with that?
Two problems basically. #1 I simply don't like hacks like "#define INT_OBJ(val) (((val) <<1) | 1)" if there might be a cleaner solution. #2 is that for time stamping an accurate mask is required and forgetting it may cause trouble. Yes, all of this can be debugged but why even bother?! There is only one situation where one might argue that exposing the internals is actually a good idea - which is when you want to return something different than an Integer (such as a string). But as I understand it, for the time being we won't have a use for anything but a number of integers so I'd rather not expose the details too much.
[Re: Latest state]
One possible problem with your 'latest state' details - I can't prove it, but I have a feeling from my ponderings that it is quite important to flush the event queue down to the event responsible for the state you are returning. Something about getting an event later that has in some sense already been handled worries me.
I had originally thought about removing the events from the queue before returning state information but the thing that bothered me about it was that a quick (even accidental) state check removes valuable information from the queue which is lost for those clients who actually rely on it. E.g., if you write a drawing program and really want to use all the mouse events coming in, some completely unrelated sender of "Sensor mousePoint" could remove all sorts of valuable information. Even worse, it could remove critical information such as a mouse up event. Therefore, a tiny little piece of bad code could affect all the good code you have. In the end, this lead me to returning some current state and obviously (e.g., if you use "[Sensor leftShiftDown] whileTrue") this state must be updated according to the latest known information.
- Andreas
In message F539F53ECAF5D111B73D00805F65BAE6854F9C@WDIGL003 you wrote:
I don't care much how the details are done so long as they work
Well, I do if it's such a critical piece of the system :-)
Like I said, "so long as they work". Everyone knows how strongly I apply the 'work' part of that.
[Re: ST oops]
Huh? It makes SmallIntegers (or potentially LPIs I guess). What's the problem with that?
Two problems basically. #1 I simply don't like hacks like "#define INT_OBJ(val) (((val) <<1) | 1)" if there might be a cleaner solution.
So call integerObjectOf: or positive32BitIntegerFor: ; for a freely declared hack to demonstrate that events can be done it's no great crime to use a macro.
#2 is that for time stamping an accurate mask is required and forgetting it may cause trouble. Yes, all of this can be debugged but why even bother?! There is only one situation where one might argue that exposing the internals is actually a good idea - which is when you want to return something different than an Integer (such as a string). But as I understand it, for the time being we won't have a use for anything but a number of integers so I'd rather not expose the details too much.
?? you've lost me. What details are being exposed that you don't like to expose? What has time stamping masks got to do with it?
[Re: Latest state]
I almost agree but not quite. I think the proper answer lies in fixing the bad code as soon as possible. The problem ought not arise and we shouldn't spend all that much time trying to work around it. I would prefer that there were no need for any compatability with InputSensor at all.
Whatever way we eventually do this, the initial version I did has had hundreds of hours of use over the last month and only two problems have surfaced, which I think demonstrates that it can be done reasonably well and so ought to be doable very well without much more fussing.
I think your 8word events, reaping process and semaphore stuff would work very well with the HandMorph (etc) changes I made. We can easily try flush/no-flush policies on the event queue and find out which provides the best nett result and then everyone relevant can get on with making the higher levels of the system properly event responsive. Then it'll be one more dumb ticklist item off the whining ninnies minds.
tim PS Neat random sigline the machine picked, eh? PPS You gotta admit I proved that event driven need not have anything to do with interrupt driven.
Tim Rowledge wrote:
[Re: Latest state]
I almost agree but not quite. I think the proper answer lies in fixing the bad code as soon as possible. The problem ought not arise and we shouldn't spend all that much time trying to work around it. I would prefer that there were no need for any compatability with InputSensor at all.
I agree (if this is what you mean :) that stuff like Sensor mousePoint ought to be deprecated when this new code allows for it. At least, it could be changed to ... world currentHand position (yah, doesn't work in MVC, I know).
Raab, Andreas wrote:
The other possible use is for debug code - e.g., something like "Sensor leftShiftDown ifTrue:[self halt]" is very convenient.
I suggested some time before that all input events should go via the hand, including leftShiftDown and such. This doesn't need to actually look at the hardware. Is there a reason that I have missed for why the above wouldn't work for this too? (Hmm, perhaps we could make a HandMorph surrogate for MVC too?)
Henrik
squeak-dev@lists.squeakfoundation.org
-
Henrik Gedenryd -
Raab, Andreas -
Tim Rowledge