Squeak-dev July 2000

squeak-dev@lists.squeakfoundation.org

121 participants
566 discussions

Re: [ENH] Alternative EventSensor
by Tim Rowledge 30 Jul '00

30 Jul '00

Actually, I can't see any huge diferences at all in the basic workings. > * InputSensor compatibility I had the impression I had managed that as well > > * Decoupling Morphic and Events OK, makes sort of sense but hardly matters one way or the other. > > * A somewhat different event format A useful small change - like my code's comment said:- >>> since most events will be keyboard or mouse related, it seem reasonable to try to optimise for them. >>> Thus we will start off with a simple Array-like grouping of:- >>> event type >>> mouse pos x >>> mouse pos y >>> button state >>> keypress >>> which seems quite easy to live with for for most platforms. Adding some extra room for other more complex events in the future is a no brainer. > > [snip] Thus, whenever you ask for "Sensor mousePoint" you > will get the latest mouse position regardless of the events still in the > queue. This is useful since most users of Sensor use want to see a quick > snapshot of the current state rather than an outdated state from possibly > several hundred milliseconds before. Same in my code, unless there is a relevant event in the queue. 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. > > Events itself are read in by a process running at #lowIOPriority. This > process waits either waits for a specified amount of milliseconds between > looking for more events or can be triggered by an event semaphore. You may > ask why I'm using two mechanisms here but the answer is simple. Most VMs > will not support true asynchronous notifications about events so we do have > to poll at some point. If, however, the VM does support async event > notification, the semaphore can be used to signal incoming events. The > design of the EventSensor allows for both mechanisms. Just like the InterruptEventSensor class I included... > > User interrupts. These are handled by the ioProcess running in EventSensor. That's a good improvement, essential if we really want to use a process to reap events. As I said in explanatory email. > > I'm sending this CS as a base for discussions. Ok, so it's fine so far as it goes. It'll certainly work ok on the platforms I know anything about (though I _still_ can't find a way to get my &^%^ing Acorn to give me mouseUp events!) pretty well. I think the changes to HandMorph etc that I included to improve their event behaviour are also very important. Without code analogous to that, there is very little point ot having any sort of event handling in the VM or anywhere else! > I'm still trying to > figure out how to prevent the C support code from creating raw oops (another > thing I don't like is that with Tims implementation you have to create oops > yourself). Huh? It makes SmallIntegers (or potentially LPIs I guess). What's the problem with that? What else is one going to use? Just change the prim I wrote for primitiveNextEventInto() to handle an eight element array. I don't care much how the details are done so long as they work and we get them into the system asap. The middle level details are important to make any of it worth it. The higher level details of making a whole load of code behave with events is much more work and much more important. tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Several nuts over fruitcake minimum.

1 0

RE: [ENH] Alternative EventSensor
by Raab, Andreas 30 Jul '00

30 Jul '00

> I like that you're sending key down and up events. However, I > don't fully understand what they're supposed to be. Are you > looking to have raw keycodes (OS specific)? Or just the same > old (pre-mapped) codes from the VM? Depends on the interpretation of the character code. For now, I'm assuming that every key is reported in current Mac Roman encoding. This is mainly for compatibility. > I find the VM's mapping of keys to be a weak spot of the > current implementation. There are a number of keys I just can't > use, or that don't work the way I'd like > (for instance, I don't seem to have a forward delete key in Squeak). There are plenty of ways in which this could be handled. Such as using character codes > 255 for encoding these special keys. I haven't put any effort into this because I figure somebody will hopefully assemble a list of the keys we want to have reported which we could then just define as "the standard". > And I can't get raw key information (for instance, to > differentiate between a keypad "1" and a main keyboard "1"). Again, this is an issue that should be handled using extended character codes. One could for instance define that the lower eight bits of the character code represent the character to be generated if a client doesn't really care for a more specific representation. E.g., if you report the main keyboard "1" as 16r31 and the keypad "1" as 16r131 then you could extract the actual character by just extracting the lower bits. If you're interested in more specific information you could have a look at the numeric keycode to distinguish between the two. > I wonder, also, what happens on key down events? Is there > both a key down and a character event generated? Yes. The idea is that the VM reports: - a single key down event - possibly multiple character events (if the key is pressed long enough to activate the OS autorepeat) - a single key up event So if you press a key shortly, you'll get keydown, character, keyup. If you press it for a longer time you get keydown, character*, keyup. > And what about keyboard auto-repeat? It's often > distinguishable from the initial key press, at least at the OS level. > You only have key down and up (as well as cooked char) events. This can be handled by examining the sequence of key events generated. It might well be possible to cover this issue at the VM level but I'd rather leave it to the ST code itself to deal with this matter. > > I'm still trying to figure out how to prevent the C > > support code from creating raw oops (another > > thing I don't like is that with Tims implementation you > > have to create oops yourself). > > Why not just pass a ByteArray to the primitive and let it > stuff in raw bytes instead of an Array (which you'd have to > create oops for)? I don't really like ByteArrays here - too much interpretation imposed to the ST side where we really only need a handful of Integers. Note that I don't mind creating a couple of SmallIntegers from within the VM; the thing I don't like is that the C support code (e.g., a VM porter) has to know how to create ST oops. This can lead to fatal and hard to track down errors (such as when you have to mask the time stamp for matching the VM's assumption about what number of bits is reported by ioMSecs) so I'd rather pass out a plain C structure which the C support code fills in and the primitive code in the VM will map these into the appropriate ST representation. - Andreas

1 0

RE: [BUG][Events] processor time wasted
by Pennell, David 30 Jul '00

30 Jul '00

I've seen 3 or 4 open Package Browser's start chewing up to 25% of my 500 MHz PIII. I haven't had time to look. Closing them and reopening fixes the problem for a while. -david > -----Original Message----- > From: Bob Arning [mailto:arning@charm.net] > Sent: Friday, July 28, 2000 3:38 PM > To: squeak(a)cs.uiuc.edu; tim(a)sumeru.stanford.edu > Subject: Re: [BUG][Events] processor time wasted > > > On Fri, 28 Jul 2000 11:46:20 -0700 Tim Rowledge > <tim(a)sumeru.stanford.edu> wrote: > >So the 'waste' time is high with change sorters but not browsers? Now > >that's pretty wierd. Does anyone have any idea what change > sorters might > >be doing that is so different to browsers? > > They do a little more work on #activate. You might also check > to see roughly how often ChangeSorter>>update is being called > under these circumstances. > > Cheers, > Bob >

1 0

AF_UNIX sockets?
by Ned Konz 29 Jul '00

29 Jul '00

Is there no support in Socket for AF_UNIX (Unix domain, a/k/a FIFO) sockets? It seems that there is an assumption that sockets are always AF_INET. I see constructors for UDP and TCP sockets, but none for Unix domain ones. I realize that existing stream protocols should work with these, but it would be nice to have a unified interface (perhaps if host is nil, port could be the name of the socket?). What brings this up is that I'm looking at the MySQL stuff in Comanche, and felt that the Unix domain socket connection might be faster than the existing TCP socket connection. -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

1 0

Re: Block closures
by Stephan Rudlof 29 Jul '00

29 Jul '00

Vassili Bykov wrote: > > Eliot's OOPSLA paper describes that improvement, as well as gives a good > intro to closure implementation in VW in general: > > http://www.squeak.org/oopsla99_vmworkshop/oopsla99-contexts.pdf I have to put some water into the wine here... ;-( The paper is interesting and stands in the tradition of and is related to earlier VW implementations, which have extended the ST80 specification. It addresses the realization of very fast block closures, so far so good. But to reach this goal, native stack layout is used and different kind of mappings of ST contexts to native stack frames. I think this fits good into JIT-Compiler work, but *** this isn't a platform independent approach ***. Moreover I don't see a realization just by changing the interpreter and ST contexts, methods and related things. To reach platform independence, we should use a slower, but compatible realization of block closures. More sophisticated techniques should be applied after a working common variant. BTW: Are there any papers describing BlockClosures without referring to native stack layout? Greetings, Stephan > -- > Vassili Bykov > VisualWorks development > vassili(a)parcplace.com > > > -----Original Message----- > > From: Tim Rowledge [mailto:tim@sumeru.stanford.edu] > > Sent: Thursday, July 27, 2000 2:29 PM > > To: squeak(a)cs.uiuc.edu > > Subject: Re: Block closures > > > > > > Mats, if you're serious about this, do yourself a big favour > > and talk to > > Eliot Miranda about his recent (as in a year or so ago) > > improvements to > > block handling in VW; he's explained it to me but I couldn't for the > > life of me explain it to you and get it right. Basically I > > think it ... > > oh hell, get him to explain it. > > > > And don't forget to talk with Ian Piumarta to make sure he isn't > > duplicating the work (he said at ECOOP he'd tackle it soon) > > and that you > > don't do anything that will break the jitter. Craig Latta did some > > pretty serious planning with Ian some time ago on this subject so he > > might some useful input for you as well. And don't forget the > > VM changes > > you'll need. > > > > And don't forget to work out howto get there from here; the > > bit that has > > always put me off trying anything. I'd suggest using the > > SystemTracer to > > clone a new image with BlockClosures rather than trying to manage with > > both styles. At least with Squeak you can simulate the new system and > > have a decent debugger. > > > > tim > > > > -- > > Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim > > To err is human; to forgive, beyond the scope of the Operating System. > > -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

2 1

Re: [GOODIE] Squeak as Web Browser Plugin
by Hans-Martin Mosner 29 Jul '00

29 Jul '00

Mikesch, you might want to look ate the ideas I have for the SCAN repository regarding users and code signing. Basically, I use the DSA to generate a public key pair, and every item in the SCAN database is signed by its owner. What' missing is a certification infrastructure; I was thinking of something like the web of trust model in PGP. User keys could be certified either by other users, or (weaker) by servers which interact through the user's e-mail address. That way, you would have some kind of initial certification that a public key belongs to an e-mail address, and for many purposes, this is well enough connected to a real user. If you need more input, just mail me directly. Hans-Martin

2 1

[SF] OSProcess module added to SourceForge
by David T. Lewis 29 Jul '00

29 Jul '00

VM-hackers, I added the Unix plugin for OSProcess to SourceForge. It's not yet fully checked out, and it will require an update to the OSProcess package to support new module naming conventions, but you should be able to build a pluggable VM with OSProcess now. If you use it, update your UnixOSProcessAccessor class (code is on SF) so that it uses the new module name. Dave

1 0

Final 2.8?
by David N. Smith (IBM) 29 Jul '00

29 Jul '00

Have I missed an announcement about the final 2.8 release, or it is still pending? Dave _______________________________ David N. Smith IBM T J Watson Research Center Hawthorne, NY _______________________________ Any opinions or recommendations herein are those of the author and not of his employer.

1 0

Re: Compiler, was Re: Block closures
by Mats Nygren 29 Jul '00

29 Jul '00

Dan Ingalls <Dan.Ingalls(a)disney.com> wrote: > Mats Nygren <nygren(a)sics.se> wrote: > [snip] > [about Visitor in compiler] > Yes, and you could probably clean up printing this way. I've already begun that and can see the end of it. Thats what got me into this, I figured since I was looking a little at the compiler I might as well do this. You'll see the printing stuff in August/September, I hope you'll like it. There is (at least) two important open question: 1) How to handle #storeOn:. It should be in the same syntax as everything else. Right now any old object can write any character directly, that will never make it to a system where the user can choose between different syntaxes. I have some structure on this but it needs to be worked out in detail for Squeak. In short let it be possible for all objects to be created from somehting {}-like. For example "Point { 2. 4 }" or "Point value: { 2. 4 }". One or a few abstract schemes like that. (And some special cases defined by class and syntax together .. 2 @ 4 is ok just as long as not every class has sme special trick) Then this can be done indirectly and use the ordinary possibility of writing a syntactic structure with "pluggable" syntax. This demands of all syntaxes that something like that is available. That is reasonable. So a kind of limited protocol for the objects is called for. This is reasonable to, why should Array know about the notation (ascii codes, is comma used, what parentheses if any are used, ..). This approach should for example be able to make #storeOn: produce xml the buzz-acronym of the week/month/year/.. In short any object should be able to serialize in a humanreadable form of the users choice. 2) How to handle the scope of the syntax preference. If it (the serialized object) is going outside of the users preferences it should use the standard syntax. (Or some other syntax, the preferred syntax of the receiver) How do we know where the users preference ends? at least as big as image? possibly bigger, local fileOuts possibly smaller, could want different syntaxes for different parts of the systems, projects? Well, some thinking is necessary here. Not completely unlike some other issues, how to get binary data to work in another image. I have left these difficulties for the future (or others or both). > [snip] > The Parser .. > > This sounds good too. > > - Dan Thanks for the encouragement. /Mats

2 1

Re: Window Frames for system windows
by Ned Konz 29 Jul '00

29 Jul '00

Henrik Gedenryd wrote: > I just realized that the dominating dpi size hasn't changed significantly > since the bitmapped displays were invented. But it'll have to once > everything is 32 bit color, or how else would you improve your product? The switch to LCD monitors has brought an immediate improvement of resolution along one axis using subpixel addressing. I'd love to see it working on my Windows/CE device (I could go to a nicer looking font). -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
57
Older →

Jump to page: