Squeak-dev November 2000

squeak-dev@lists.squeakfoundation.org

106 participants
325 discussions

Re: Event implementation
by Marcel Weiher 01 Nov '00

01 Nov '00

Thanks to Andreas's feedback, I've been able to narrow it down further: it looks like getNextEvent() is not beeing called nearly as frequently as it should during event-idleness, only about once every 3-10 seconds instead of once every 1/2 seconds as Andreas indicated. The code that does this is #ioProcess in EventSensor, which waits on the I/O semaphore for EventFrequency milliseconds (actually, EventFrequency defaults to 20 ms, so we should be checking 50 times a second). It is this wait for the Semaphore to time-out that is taking much, much longer than expected, up to 10 seconds and more. So now to track that down... Marcel

1 0

[slightly OT]: Linux on iPAQ (was: Re: Squeak 2.7 on iPAQ)
by Jörn Eyrich 01 Nov '00

01 Nov '00

Stefan Matthias Aust wrote: > On www.handhelds.org they say than you can revert from Linux to WinCE > again. This wasn't always possible but seems to be a new feature. This > might reduce the risk to create expensive computer garbage. > and Craig Latta wrote: > I've also got Squeak 2.7 working under WinCE on the iPAQ (I'll try > Linux when handhelds.org has reliable instructions for restoring the > WinCE flash). It seems there are still people grilling theirs not when trying to revert to WinCE, but already while trying to go to Linux. Like the guy on Sunday who posted under the subject "[iPAQ] iPAQ is now toast (was iPAQ will die ?)". As far as I understand it, there are different makes of flash chips, and the bootloader doesn't handle all of them equally well. Joern

1 0

Re: RE: Event implementation
by Marcel Weiher 01 Nov '00

01 Nov '00

> From: "Raab, Andreas" <Andreas.Raab(a)disney.com> > > How about Unicode? > > We are talking about specific keyboard keys here. Key up/down events report > keys the user presses on a particular keyboard. Sure. If you want to be really close to the hardware, you should probably use raw-codes, however useful those are. > I don't think Unicode has a representation for the left and the right shift key... Well, you can always use the "user defined" range (or whatever it is called). Also, I don't think any applications should rely on these being distinguishable. For example, MacOS-X/Cocoa doesn't even generate key-events for the shift keys, it generates a "flags-changed" event that does not distinguish between left and right shift keys. >and that's why we can > live without key down/up events (right now they're unused) but not without > the character events. Hmm, that's a funny distinction. Does this mean I get several different types of events for the same action? Is this Windows specific? With MacOS-X/Cocoa, a keystroke gets me two events, a key-down and a key-up. Any additional information, such as various character translations etc. are provided with those events, instead of as distinct events. > The OS does the mapping for us from the key code[s] > into the actual characters (e.g., when you use some of those multi-key > combination characters such as accents on certain keyboards) so we don't > have to know about these mappings at the Squeak level but can still respond > to whatever we find a good idea (I love the "ctrl" key as fire button). Agreed, however, I kind of like having the translation(s) accompanying the up/down events. [semaphore use] > To no good use. The semaphore is provided for two reasons: > #1 - indicating to the VM that we want to use the event driven primitive > set. > #2 - For TRULY asynchronous event notification mechanisms. E.g., if you > would run the event processing loop in a different thread than Squeak that > is the semaphore to signal. That is actually what I am doing. Cocoa has its own event loop, and I just hook into its -sendEvent: message. While it is possible to run your own event loop (and the code is there in the Squeak port), I'd rather not. > For now, this signaling actually hurts more than > it helps (the explanation takes a bit of time so I skip it for now) but it's > not too bad if your machine is fast enough. Oh, that sucks. Can I avoid this without resorting to going single-threaded again and running my own event loop? > BTW, if you've been digging in my sources, please notice that there's a call > to ioProcessEvents() in ioGetNextEvent(). Yes! In fact, that would have been my next question. > That call is IMPORTANT - if you > leave it out you will get an arbitrarily sluggish behavior. Ahh, that is probably the cause for what I am seeing. However, adding it in doesn't actually change anything, because my ioProcessEvents() implementation only does the aiPoll(), it doesn't actually look for events. Why would I get arbitrary sluggish behavior? Does this also apply to the case where OS events are being handled in another thread? Marcel

1 0

[BUG] RE: [updates] Happy Halloween
by Torsten.Bergmann＠phaidros.com 01 Nov '00

01 Nov '00

After getting the latest 100 updates I had problems to create and enter a new morphic project. It crashes in Project>>makeThumbnail since it sends #displayWorldSafely to the variable world (which is an instance of class ControlManager) After updating there is no implementor of #displayWorldSafely anymore. I compared this to an 2.8 image. The method #displayWorldSafely was formerly implemented by PasteUpMorph. Bye Torsten

1 0

Re: Code Simulation Error during debugging
by Dan Ingalls 01 Nov '00

01 Nov '00

"Larry Kellogg" <lkellogg(a)soliloquy.com> wrote... > I have been playing around with Squeak (2.7 and 2.9) and I seem to run >into Code Simulation errors while trying to debug things. It seems to happen >quite frequently. I'm on a Windows NT machine. I don't think I was doing >anything too radical, just trying to step into or over code. Any ideas? There are several of good reasons to move from the current simulating stepper to a process-faithful stepper (as some respondents suggested), but it won't happen until it's on the top of our stack, or someone else comes forward with a complete solution. Meanwhile, if folks can be specific about something fairly simple that fails, there is a reasonable chance that we could fix it. There are lots of good reasons to have a complete and reliable simulating stepper. - Dan

2 1

RE: [VM] Hooks from module into platform support code?
by Raab, Andreas 01 Nov '00

01 Nov '00

Henrik, It's entirely possible to do this but it has quite a number of implications. Such as, you have to ensure that the message you're invoking does not return outside the receiver's frame (e.g. through a non-local return). If it does (or gets prematurely terminated from a debugger) you are in deep trouble. In other words - don't even think about it unless you have 180% fool-proof exception and unwind handling system. Then, there is also quite a bit of a problem when you think about invoking multiple messages like this - if you invoke message A in process A then message B in process B and then (after the process switch) message A tries to return, you'd have to return through the C stack frame of message B. Good luck :-) Messy. That stuff's so messy. I thought about it when doing the FFI stuff but the possible complications were just way to much for me... - Andreas > -----Original Message----- > From: Henrik Gedenryd [mailto:Henrik.Gedenryd@lucs.lu.se] > Sent: Wednesday, November 01, 2000 1:38 AM > To: squeak(a)cs.uiuc.edu > Cc: recipient list not shown > Subject: Re: [VM] Hooks from module into platform support code? > > > Forgive me if I am overlooking something really obvious, but > while we're > almost on the topic, what is it prevents one from doing > ordinary message > sends from C code by having the equivalent of the exact bytecodes of a > message send as a sequence of (Slang-generated) C code? This is what I > thought that exception code was doing when it triggers a > method for block > unwinding or something. > > Is it something like the interpreter not being reentrant? > > Henrik > >

1 0

Re: Celeste with German Umlaute
by Henrik Gedenryd 01 Nov '00

01 Nov '00

Lex Spoon wrote: > Let's change the question. Does anyone *not* want this? Of course, > we need to find free fonts to use.... One could always just shuffle the glyhps from the existing Mac-derived fonts into their ISO positions. I don't know which ones would be missing, but I suspect few or no crucial ones. And then there's always the possiblity of using FreeType which handles bitmap fonts, and WIN encoded fonts to that (although I don't know much more than that this is a Windows-native <bitmap?> font format). Any word on those generic Mac clone fonts, by the way? Henrik

1 0

RE: Event implementation
by Marcel Weiher 01 Nov '00

01 Nov '00

Hi Andreas, thanks for the feedback! > On what platform?! MacOS-X, my usual haunt. [timestamp is milliseconds] Good that was what I had. > > as well as what types of events are expected. > > Whatever your OS gives you. Mouse down, mouse up, mouse move, key down, key > up [*], character. Interesting. When I provided key-down + key-up events to Squeak, keyboard input didn't work. It only works when I provide KeyChar events (which I currently do on key-down). Also, just for comparison, these are the events that are provided by MacOS-X/Cocoa: -left/right button down/up/dragged (6 in all) - the event has a clickCount field already filled in -mouse-moved -mouse-enter/mouse-leave - for user-defined tracking rectangles -key-down/key-up - raw key-code - characters (string of characters that's generated) - characters ignoring modifiers except for shift - a repeat-flag if this is the result of a repeat-action - flags-changed - any of the modified keys changed - periodic - you can set up timers that periodically post events - other: app activated/deactivated, power-off, etc. > [*] The exact semantics for what to report on key down/key up haven't been > figured out yet. My current take is to simply use the X11 key definitions How about Unicode? This is what MacOS-X currently uses, and it surprisingly has codes for the various special keys. > Yes. But remember that the button state includes more than just the button > pressed / released and it is expected that Squeak gets the full set of > "current" buttons. If you know that your system will report a single button > release at a time, then you may cache the last button state. If not you'll > have to query for it or to figure it out from the event you get. Single-button mouse... :-) Anyway, I'd be happy if it worked even that far, but it doesn't seem to want to. My ioGetNextEvent() is instrumented and duly reports the mouse-down/mouse-up events for an unmodified click, as well as the flags it sets in the event structure ( RedButtonBit set, all clear). But the clicks only sometimes cause the desired effect, for example bringing up the world-menu in morphic is particularly tricky, but there are also significant troubles and delays with any other operations involving mouse-clicks. Mouse-moved and keyboard events (as long as they are KeyChar) are fine. [no status events] -> OK, that was just a sanity check! One more thing, I just checked the Windows VM sources, and I don't see the input-event semaphore actually being used except as a flag -- no signaling. I currently signal it whenever an event has arrived. Marcel

1 0

RE: Event implementation
by Raab, Andreas 01 Nov '00

01 Nov '00

Marcel, > I've been trying to implement the event-processing VM extensions, On what platform?! > Things that I am unclear about are the exact meaning (units?) of the > timestamp value in the event structure, Milliseconds. Will be used (at some point) to determine double clicks etc. more accurately. If possible, they should be based on your system's io[Micro]MSecs() implementation, so it's easy to determine from Squeak how old this event is. > as well as what types of events are expected. Whatever your OS gives you. Mouse down, mouse up, mouse move, key down, key up [*], character. [*] The exact semantics for what to report on key down/key up haven't been figured out yet. My current take is to simply use the X11 key definitions since at least Mac/Win seem to be a subset of it and since X11 keys are 16bit and Mac/Win only 8bit the mapping is relatively straightforward and not too expensive in terms of memory. Alternatively, we could report *whatever* your system gives you wrt to key codes and do the mapping from Squeak. Both approaches have its advantages... > For example, currently I get 2 events from my > OS for a mouse-click, a mouse-down and a mouse-up, which are > translated into squeak mouse-events with the corresponding > button-flag set and cleared, respectively. Is this correct? Yes. But remember that the button state includes more than just the button pressed / released and it is expected that Squeak gets the full set of "current" buttons. If you know that your system will report a single button release at a time, then you may cache the last button state. If not you'll have to query for it or to figure it out from the event you get. > Is anything else expected, maybe some-sort of timed "MouseStillDown" > event? No. You report changes, not current state ala "yes, the mouse is still down, it's still pressed, yeah it still didn't go up, no it's still down, yeah, really, it is down, oh-why-don't-you-just-believe-me-the-mouse-IS-still-down" events. As long as the VM doesn't miss any events (which is the entire point of this exercise) Squeak is smart enough to do the rest. HTH, - Andreas

1 0

[BUG]TextIndent
by Bijan Parsia 01 Nov '00

01 Nov '00

Somewhere after 2.7 TextIndent has gone haywire. It's easy to see if you open a Scamper window on a web page with a list on it (like http://www.squeak.org/). The Bullets are flush left and depending on whether the item begins with a link or not, the item text will be indented the "proper" amount relative to the left edge (if it's a link) or to the bullet (if it's plain text). E.g.: * A Link. * Some text. Comparing the results of TextIndent class>>example in a 2.7 and a 2.8 or greater image is instructive, especially if you alter the width of the displayed paragraph. As far as I can tell, the problem lies much deeper in the bowels of CharacterScanner or rather CompositionScanner than I can yet ferret out. Cheers, Bijan Parsia.

1 0

Jump to page: