[ENH] Alternative EventSensor

Tim Rowledge tim at sumeru.stanford.edu
Sun Jul 30 03:27:24 UTC 2000


In message <F539F53ECAF5D111B73D00805F65BAE6854F9C at 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, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Software engineer: One who engineers others into writing the code for him/her.





More information about the Squeak-dev mailing list