Squeak-dev June 1999

squeak-dev@lists.squeakfoundation.org

139 participants
408 discussions

[ANN] SmallInterfaces Squeak port
by Masashi Umezawa 30 Jun '99

30 Jun '99

Hi Squeakers, I ported the "SmallInterfaces" extension to Squeak. "SmallInterfaces" introduces the notion of "interface" in Smalltalk. It is originally developed by Benny Sadeh in VisualWorks3.0 NC. Main features: * create and use interfaces in Smalltalk. * generating stub implementation classes from interfaces. * generating interfaces from classes. * some GUI support for interface browsing. http://brain.cs.uiuc.edu/VisualWorks.SmallInterfaces (original) http://www.mars.dti.ne.jp/~umejava/smalltalk/stClasses/smallinterfaces/ (Squeak Port) Enjoy! --- [:masashi | ^umezawa] "self become: self new"

1 0

Re: [ALL] Lobbying - Smalltalk KILLER APP!
by Tim Olson 30 Jun '99

30 Jun '99

>But I don't understand how an interpreted server can have processes >as lightweight as compiled lightweight processes. Is this after some >hypothetical compiler has sped up frequently used code paths or >something? I think I understand parts of that direction, but it does >not seem to get much discussion here. An interesting point is that as the number of threads goes up and the work done per thread between context switches goes down, at some point interpretive code can actually outperform native code, especially if the host machine has a lot of registers which must be saved and restored during native context switches. For example, a lightweight (user-mode) thread on a PowerPC processor would take maybe 70-80 cycles (save and restore 32 general-purpose registers and a few others). An interpreter, on the other hand, may only have to save and restore a couple of registers (instruction pointer and heap pointer). -- tim

1 0

RE: Ramblings on how to optimize Squeak for modern CPU bit manipulation (Was Re: I was wondering ...
by Lawson English 29 Jun '99

29 Jun '99

Further refinements to my pixel-handling primitives idea: In addtion to the 128-bit AltiVec simulation/primitives, it would be useful to implement: A set of quick and dirty AlitiVec-like primitives that only operate on single pixes at the various standard screen depths -32, 16, 8. A full-blown single-pixel equivalent of the Altivec simulator that would allow one to manipulate a single pixel's color channels one-pixel-at-a-time. E.g., C-based methods to separate color channels into 16 or 32-bit values, and manipulate them simultaneously or separately, as well as methods to convert them back to 8/5/whatever bits per channel and repack them into a single pixel. The idea is to create a bunch of primitives that can manipulate pixels efficiently for color-handling, as well as to speedup DSP-like operations. The simulator (32 or 128-bit) would store intermediate values in virtual registers so that no conversion or other data-related overhead would be incurred until you needed to manipulate the data using standard SmallTalk. The 128-byte simulator/primitives would be suitable for long streams of pixels or other data. The 32-bit simulator/primitives would be suitable for short segments of data (or for handling edge conditions in a long stream in a machine that has an AltiVec-like device handy). For MMX, perhaps an intermediate 64-bit version could be implemented as well, or facilities created to handle 64-bit segments from within the 128-bit version? Comments? Criticisms? I haven't benchmarked any of this, but my intutition says that the time-savings from doing this could be quite good, especially during the prototyping phase of pixel/DSP algorithms. I said: [refinements to my idea include] >1) a set of quick and dirty primitives that can be called as standalones; >2) a full-blown (more or less) AltiVec simulator that uses a single set of >32 "registers" that are accessed by index, rather than by providing a >Smalltalk byteArray every time you use it. ---------------------------------------------------------------------- Use your imagination. ----------------------------------------------------------------------

2 1

Re: [FIX] error in #replaceColor:withColor:
by Bob Arning 29 Jun '99

29 Jun '99

On Tue, 29 Jun 1999 10:38:38 -0700 Dan Ingalls <Dan.Ingalls(a)disney.com> wrote: >The fix below is shorter, faster and better -- I'll include in next updates. Dan, Thanks a million. This second one is fast and perfect as far as I can tell. (The first one still had a little glitch that I have been trying to diagnose, but you fixed it first. Big surprise!). Cheers, Bob

1 0

Re: Squeak swiki down....
by Mark Guzdial 29 Jun '99

29 Jun '99

No, not related -- the Transcript just got munged. Happens sometimes with the multi-threading when too many processes are trying to write too much to the Transcript at once. It is slightly related to the UploadSwiki -- which, because it's still experimental, prints out extra stuff to the Transcript. I killed the Transcript, opened a new one, and dropped some of the Transcript status messages. Seems to be working fine now. Mark >That sounds a bit like the fork Bug with the debugger that Bob Arning fixed. >Has this bug-fix >been filed into the Swiki Smalltalk?? > >>I'm getting "Message not understood: last" from the Squeak swiki: >> >> http://minnow.cc.gatech.edu/squeak.1 >> >>(Upload swiki strikes again?) >> >>-- Dwight >> >> -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

1 1

Re: [ENH] OS-level events
by Peter William Lount 29 Jun '99

29 Jun '99

Hi Lex, Excellent!!!!!!! This is cool. I looked over the source and it looks great. It would be useful to include a time stamp with each event, if possible. Usually the OS includes a "time that the event occured" field in its event stream. This is important for calculating things like double, tripple (NeXTStep used this to select a whole line of text for example), and quadripple (NeXTStep used this to select a whole paragraph of text for example) mouse clicks and for determining the time between events. Many user interface components can make use of the events times. If the time is missing then lots of things can't be done. The time should be the time the OS recorded the event not the time that the Squeak VM pulled it off of the event queue. Also, some OSs provide extra information such as if it was a double click (by the users preference settings in the OS), a repeat key event, and modifier keys (I think you have this). Each keyboard event should also report the mouse position and button status (I think that you do this). Also, some OSs may have more information than others. Another important piece of information associated with the event is which Window it is part of. This allows the user to click on another window thereby activating it and now the events get "consumed" by that window. It would be cool if the use or squeak applications could control the size of the event queue. I guess this can be done from Smalltalk code. With OS-level events it's possible to produce a "event recorder" to "playback event sequences" for automated GUI help systems (shows a quick sequence on how to do something), demos, and testing of applications. An excellent reference implementation of Event Queues is NeXTStep and OpenStep (now MaxOSX). (This rather long url points to the MacOSX NSEvent class documentation. You may have to remove the line breaks and paste this into your web browsers address field manually). http://developer.apple.com/techpubs/macosxserver/System/Library/Frameworks/A ppKit.framework/Versions/C/Resources/English.lproj/Documentation/Reference/O bjC_classic/Classes/NSEvent.html Will this important change make it into the Mac and Windows versions for the release of the next VM? Awesome Lex. Thanks. All the best, Peter William Lount peter(a)smalltalk.org http://www.smalltalk.org

1 0

SGML Parser
by Wallace Chigona 29 Jun '99

29 Jun '99

Hi, I am looking for a Squek SGML Parser. If someone has an idea where I can get it from, or has it please advise. Nice day -- [Wallace Chigona]-------[ chigona(a)isg.cs.uni-magdeburg.de ] Universitaet Magdeburg, Institut fuer Simulation und Graphic url: http://isgwww.cs.uni-magdeburg.de/~chigona

1 0

[ENH] OS-level events
by Lex Spoon 29 Jun '99

29 Jun '99

I worked some the last two weekend on a system to tunnel OS-level events up into Squeak, at least when using Morphic. It functions on Unix, though it can use some more work. Hopefully it can be a starting point for a more complete system (I plan to finish up the image support, but it takes extra code on the individual ports to make this useful). The relevant files are on the swiki at: http://minnow.cc.gatech.edu/squeak/attachment/Input+Events.cs http://minnow.cc.gatech.edu/squeak/attachment/sqXWindow.c-events I started to post them to the list, but read some light flamage and decided against it :) In the middle, I mean, remainder, of this message, I will describe why one would want such a system, describe how the system works, and finally, address compatibility with MVC and with old images. WHY BOTHER? In short, it sucks to click too fast and for Squeak not to notice, or to double click on something and it triggers as a single click. It also sucks having to hold the mouse button down half a second on buttons and menus to make sure they trigger. Since most OS's supply mouse events anyway, and since Morphic is already built on top of (internally-generated) events, it seems blindingly appropriate to tunnel the OS-level events up and have Morphic use those instead of it's own internally-generated events. Also note, the keyboard already works using events. Squeak doesn't constantly poll the keyboard state to see if any keys are pressed down; it assumes the VM has a keyboard buffer, and it sends queries to the buffer instead. The real effect of the below changeset is to do the same thing for mouse actions. THE SYSTEM By "input event" I mean one of the following five kinds of events: 1. Mouse move, mouse down, mouse up 2. Key down, key up The first piece in the changeset below, is a hierarchy of classes used to represent these events in a Squeak image. They are missing some obvious functionality, but they do implement the critical functionality of creating a MorphicEvent that contains the same information. The second piece is an image-VM interface to poll the events. The way this is done below is by: 1. Adding a few methods to Interpretter (and regenerating interp.c). The new methods call new io* functions in platform-specific files. 2. Adding methods to InputSensor which use these new primitives. I used name-based primitives, which may cause problems on some platforms, but which is really cool for experimental work :) The io* functions fill in an array of five integers. I figure it is easier to let Squeak code in the image build up real objects from these five integers, rather than trying to do something similar in the C files. After that, the final piece was to actually add support to the platform specific files for events. I did this for Unix, because that's what I use all the time. The sqXWindow.c file in the next message, records all keystroke and mouse events that come in, and adds the needed io* methods to go through that queue. Finally, a quick change to MorphicHand.handleEvents to use "Sensor nextEvent asMorphicEvent" instead of deriving MorphicEvents from the mouse states, and it all actually works. COMPATIBILITY The core of the traditional input interfaces are: 1. Queries directed specifically to the keyboard, ie "keyboard peek" and "keyboard next" 2. Queries to the mouse position and button state First, the latter is actually useful even when you are using events. I simply left that interface alone, and had it report the latest state of the mouse (even if there are events of the queue that report an earlier state). Dealing with the keyboard is trickier. If someone reads a key via the old interface, the key really should be taken off the input queue, so that the same key doesn't show up twice if you switch to an events-using Morphic project. Furthermore, if the image uses only the traditional interfaces, then the input queue needs to be trimmed down at some point so that it doesn't grow forever. The solution used in following sqXWindow.c is simple: stop using the old keyboard buffer, and instead have traditional keyboard queries simply drop events from the front of the stack until a key event is found. The assumption behind this scheme is, if someone is using the traditional keyboard interface, then they aren't going to be interested in the mouse events anyway, and so dumping them is safe and even recommended. If they break this assumption, then they are screwballs and deserve the chaos that they get :) Lex Spoon

1 0

Re: [FIX] error in #replaceColor:withColor:
by Dan Ingalls 29 Jun '99

29 Jun '99

Without having spent a lot of time, I offer the code below. It seems to work well enough to do the right thing for... ((Form extent: 5 @ 5 depth: 32) fillWhite; replaceColor: Color white withColor: Color red) displayAt: 0@0 .... and, more to the point, it allows FMP to run in 32 bits. I'm not sure the colors are quite right, though, and the creation of terrain tiles takes a much longer time. Might require a tweak to FMP, and possibly to my fix below as well. - Dan --------------------------- !Form methodsFor: 'image manipulation' stamp: 'di 6/29/1999 09:48'! replaceColor: oldColor withColor: newColor "Replace one color with another everywhere is this form" | cm newInd target ff rgb val | cm _ Bitmap new: (1 bitShift: (depth min: 15)). depth = 32 ifTrue: ["32-bit pix vals for 32k color map..." 1 to: cm size do: [:i | rgb _ i-1. val _ (rgb bitAnd: 16r1F) + ((rgb bitAnd: 16r3E0) bitShift: 8) + ((rgb bitAnd: 16r7C00) bitShift: 16). cm at: i put: val]] ifFalse: [1 to: cm size do: [:i | cm at: i put: i - 1]]. newInd _ newColor pixelValueForDepth: depth. cm at: (oldColor pixelValueForDepth: (depth min: 16))+1 put: newInd. target _ newColor isTransparent ifTrue: [ff _ Form extent: self extent depth: depth. ff fillWithColor: newColor. ff] ifFalse: [self]. (BitBlt toForm: target) sourceForm: self; sourceOrigin: 0@0; combinationRule: Form paint; destX: 0 destY: 0 width: width height: height; colorMap: cm; copyBits. newColor = Color transparent ifTrue: [target displayOn: self].! ! --------------------------- >It seems that Form>>replaceColor:withColor: has a problem when depth = 32. Evaluating: > > (Form extent: 5 @ 5 depth: 32) > replaceColor: Color white withColor: Color red. > >results in: > > subscript is out of bounds: 4294967296 > >Cheers, >Bob

1 0

Re: FMP, the game - requirements
by Bob Arning 29 Jun '99

29 Jun '99

I should have mentioned: 1. This runs only in a Morphic project. 2. Display depth 16 is *strongly* recommended. 8 will work, but some visual effects are either missing or less attractive. 32 bits does *not* work for now. Cheers, Bob

1 0

Jump to page: