Squeak-dev December 2000

squeak-dev@lists.squeakfoundation.org

96 participants
272 discussions

Re: RE: Ascii Equivalents for KeyUp/KeyDown events
by Lex Spoon 01 Dec '00

01 Dec '00

> > Having a potentially different codes for every keyboard seems too > > extreme. It either means that each application must do its own > > translation, > > No! 99.9% of applications should be able to do just fine with the > Unicode standard mapped characters. Furthermore, some special keys ( > cursor, function ) could be mapped to codes that can be fitted into > the 'private' Unicode range, which has been defined for exactly that > sort of purpose (or translated to escape-sequences, or both). Well, we basically agree -- the A key should generate the same result on all platforms. The only question is what encoding to use. I think we may as well use the XFree86 definitions, since they have been worked out already and they've been used on a wide variety of keyboards. It's not just the work of coming up with all the codes (XFree has about 1300). It's the subsequent effort to check that the codes make sense on a variety of keyboards. The shift key issue doesn't seem real important, though in fact I do support the distinction even if we do end up defining a new set of codes. I'd like to pass in the distinction for the same reason I'd like to see Fn keys passed in -- most keyboards have them, even if Squeak software can't totally rely on them being prosent. But it's not that important, anyway; most code is probably *not* going to react differently to left-shift and right-shift, anyway. In short, it seems like a lot of work to do a good job of defining a new set of codes, and the X guys have already gone through that effort. Maybe there are nits to pick with it, but it seems like a fine set of codes to at least start with. -Lex

1 0

RE: Pentium 4 tinyBenchmark results
by Peter Crowther 01 Dec '00

01 Dec '00

> From: Dan Ingalls [mailto:Dan.Ingalls@disney.com] > When J3 runs on Jan's P4, it's gonna be smokin'. Any feel for when an x86 version will happen? Knowing the developers, they'll have made it as easy as possible to retarget, but the brain-damage inherent in the x86 architecture presumably means there's a lot of work yet --- RISC processors are much easier to target than CISC? - Peter

1 0

Re: Any Squeakers CSCWing?
by Jeff Szuhay 01 Dec '00

01 Dec '00

>Any Squeak folk going to CSCW (Computer Supported Collaborative Work) >in Philadelphia this next week? Any interest in a highly informal >BOF (i.e., an opportunity to see one another's faces and chat)? > Hmmm... That would be a five hour drive for me (but much less than driving to Atlanta from Pittsburgh). What day were you thinking of meeting? Jeff 8-) -- ************************************************** Jeff Szuhay A randomly-directed www.szuhay.org chaotical wetware pattern jeff(a)szuhay.org recognizer/generator. You must not lose faith in humanity. Humanity is an ocean; if a few drops of the ocean are dirty, the ocean does not become dirty. -- Mohandas K. Gandhi (1869-1948)

1 0

Re: Pentium 4 tinyBenchmark results
by Jan Bottorff 01 Dec '00

01 Dec '00

At 01:52 PM 12/1/2000 +0100, you wrote: >¿What platform (Win/Linux) have you tested on? ¿Shouldn't the VM be >recompiled for the P4, to take advantage of the new architecture? At the moment, I only have Win2000 on the P4. I'm not sure the compilers even have P4 optimization yet.

1 0

RE: Ascii Equivalents for KeyUp/KeyDown events
by Bert Freudenberg 01 Dec '00

01 Dec '00

On Fri, 1 Dec 2000, Peter Crowther wrote: > > From: Bert Freudenberg [mailto:bert@isg.cs.uni-magdeburg.de] > > my current setup > > maps the left and right Windows keys to Meta-L and Meta-R (0xFFE7, > > 0xFFE8). > > And the Windows menu key? (the one to the right of the right-Windows key)? > I'm not arguing --- I'm interested! It's just called Menu (0xFF67). Win keyboards are not the first ones sporting a menu key. For example, Sun keybords have undo/redo keys for a long time - I guess we'll see those soon enough :) > > After all, regular keyboards are not that uncommon ;^) > > It's a fair point B-). Sorry for pushing for the 100% rather than 99.999% > solution; I'm doing some secure Web development at the moment and have to > assume that the users are Machiavellian (sp?) in the extreme. There are > certain advantages to that exquisite, open, personal computing environment! So you should deal with raw keycodes, and have Machiavelli type them in everytime the application is run: "Please press A". "Thank you for pressing A. Now please press B". :)) -- Bert

1 0

RE: Question: How do I delete a simple line
by Steffen.Mueller＠phaidros.com 01 Dec '00

01 Dec '00

Hallo Hans-Martin, I want to drag a line very fast from one point to another and I hoped I could use the same method like in SystemWindow (see doFastFrameDrag). I'm afraid 'restore display' is not the right method to do this. Steffen -----Original Message----- From: Hans-Martin Mosner [mailto:hmm@heeg.de] Sent: Freitag, 1. Dezember 2000 11:33 To: squeak(a)cs.uiuc.edu Subject: Re: Question: How do I delete a simple line Steffen.Mueller(a)phaidros.com wrote: > Hallo, > > I use > > aForm := Form extent: 2 @ 2. > aForm fillBlack. > (Line > from: 10 @ 10 > to: 100@100 > withForm: aForm) > displayOn: Display > at: 0 @ 0 > clippingBox: Display boundingBox > > to draw a nonmorphic line. > > How do I delete this line from display? > > Steffen Just do a 'restore display' from the desktop menu :-) Painting on the display is destructive, pixels behind the line are lost. The windows know how to redraw themselves, however, so you can get a clean desktop again by executing 'Display restore'. If you want to play around with nonmorphic graphics, you should use Display restoreAfter: ["some graphics"] This paints your stuff, waits for a mouse button to be pressed, and restores the display. Cheers, Hans-Martin

2 1

Re: Pentium 4 tinyBenchmark results
by Bert Freudenberg 01 Dec '00

01 Dec '00

On Fri, 1 Dec 2000, Jan Bottorff wrote: > My system is a 1.4 Ghz P4 on the Intel D850 motherboard and 128 MBytes of > 800 Mhz Rambus memory. Fry's was selling the motherboard+processor+128 MB > memory for $1199. > 0 tinyBenchmarks = '118,408,880 bytecodes/sec; 3,085,422 sends/sec' Wow! I sure would like to see the numbers for a 1.2 GHz Athlon with DDR-RAM ("266" MHz). It most certainly beats this if weighted with the price, but I wonder if anyone can give absolute numbers? -- Bert

1 0

RE: Life implementations of a Turing Machine
by Peter Crowther 01 Dec '00

01 Dec '00

> From: Mike Rutenberg [mailto:mdr@scn.org] > Subject: Life implementations of a Turing Machine > It might be slow, but it would be unique! 11,040 generations per Turing machine step, and regenerating delay-line memory bits. Yes, it would be slow --- but it's a beautiful thing to watch if you can find a monitor large enough. My 1280x1024 shows about two thirds of the pattern. Gives a whole new meaning to being able to see inside the machine, anyway! Given the Life terminology with patterns like 'Queen bee', would altering the VM on this be debugging, bugging or re-bugging? - Peter

1 0

Transcript problems!
by jchludzinski＠worldkey.net 01 Dec '00

01 Dec '00

To avoid having multiple Processes concurrently writing (#show:) to the Transcript, I have an class (#StringPump) with an instance of SharedQueue on which the Processes place Strings (using #nextPut:). A separate Process (part of #StringPump) retrieves the Strings (using #next) and writes the String to the Transcript: run | nextValue | [true] whileTrue: [nextValue _ self sharedQ next. Transcript cr; show: nextValue] This resulted in an error with the following call stack: MessageNotUnderstood: stringIndex UndefinedObject(Object)>>doesNotUnderstand: TextMorphEditor(ParagraphEditor)>>selectionInterval PluggableTextMorph>>scrollSelectionIntoView: PluggableTextMorph>>scrollSelectionIntoView PluggableTextMorph>>handleEdit: PluggableTextMorph>>update: [] in TranscriptStream(Object)>>changed: Array(SequenceableCollection)>>do: TranscriptStream(Object)>>changed: TranscriptStream>>endEntry TranscriptStream>>show: StringPump>>run [] in StringPump class>>new: [] in BlockContext>>newProcess Any suggestions on how I can have multiple threads write to the Transcript (concurrently) - without problems? I have also seen another error concerning indices and #endEntry. ---John

1 0

Re: Ascii Equivalents for KeyUp/KeyDown events
by Marcel Weiher 01 Dec '00

01 Dec '00

> From: "Lex Spoon" <lex(a)cc.gatech.edu> > I'm sure someone will post a more thorough response, but note that not > all keys *have* an ASCII code. What is ASCII for F1, or up-arrow? Several possible solutions: 1. Use Unicode instead of ASCII and define private characters for special keys 2. Assocate strings with the event and generate an equivalent escape-sequence (you still know that it was a single key because it comes in one event) 3. You still have the raw keyboard code... AFAIK, MacOS-X/Cocoa does all of these at the same time. Marcel

2 6

Jump to page: