Squeak-dev June 1998

squeak-dev@lists.squeakfoundation.org

83 participants
130 discussions

Start a nNew thread

Anyone porting to Amiga?
by B. Peterson 03 Jun '98

03 Jun '98

As the subject says - has anyone ported or started porting Squeak to Amiga OS? Brad

1 0

Wednesday's updates
by Dan Ingalls 03 Jun '98

03 Jun '98

The following updates are now out. These include fixes for recently reported problems... Accidental redefinition of existing classes (#84) No easy way to turn sound on and off (#84) BookMorph page turning broken by change to do: (#80) Enjoy ---------------------- 078sw_pasteFix.cs Fixes bug in paste-morph feature that dropped user into debugger when trying to paste an object that had been previously named. 079sw_DropFixes.cs Fixes long-standing bug in BookMorph accept-drop code that sometimes allowed unwanted and inappropriate dropping of objects *above* the page controls, for example. Comparable bulletproofing is also added to PasteUpMorph, to avoid the phenomenon of objects being dropped 'successfully' but not being visible on the page after drop -- which could happen in drops on a page of a book in a tabbed complex, for example. 080jhmDoFixes.cs Reinstates Object>do: with a notifier saying that it has become obsolete. Fixes two cases where do: was still being sent to a non-collection. Such uses should now use in: rather than do:. It may take a while to find and fix any other such uses of do:. Non-collection objects now understand 'asOrderedCollection'." 081jhmRepaintFix.cs Fixes a problem with re-painting an existing SketchMorph when it is rotated. It was appearing in the upper left of the World, rather than allowing painting in place. 082jhmRepaintFixTwo.cs This filein really fixes the problems with painting a rotated morph. Really!! No, I mean it!! This time for sure!! Also fixes the world halo being too big when objects are off the screen. 083jhmTranslucency.cs A first cut at support translucent colors in Morphic, based on code by Michael Stevens. There are a number of unresolved issues having to do with translucency, including: 1. If any pixel is painted multiple times, it gets gradually darker. This results in various artifacts such as darker bands in the middle of ellipses and strange effects during resizing. 2. The hand caching code must be disabled in 32-bits. 3. It is slightly more expensive to decide what combination rule to use; this affects performance at all depths. The slowdown seems to be under five percent. 4. Images cannot be translucent. 5. Translucency only works with when the Display is in 32-bit mode. It would be nice if it worked at 16 bits and it might potentially be useful at 8 bits, at least for translucent grays. (There may not be enough color gradations in 8-bits to get good color blending) 084SqueakTweaks-June2.cs Installs a help-menu item for turning sound on and off. Warns of redefining a class when not looking at it in the browser. >From John-Reed Maffeo: A fix to pluggable buttons in FormMenuView.

1 0

floatarray primitives
by Aik-Siong Koh 03 Jun '98

03 Jun '98

I am looking for floatarray which are implemented in primitives for speed. I want to use them for intensive vector and matrix type calculations. Thanks in advance Aik-Siong Koh

4 3

Native Windows - was RE: Squeak Team plans
by jim benson 03 Jun '98

03 Jun '98

How do I hook up Squeak windows to native windows -- Maloney wrote: > It's not really very complex. Currently, BitBlt notices if its > destination is the Display object, and if so it tells the VM that > which rectangle of the Display has changed. The VM then copies this > to the screen. > > To handle multiple windows, you'd have multiple DisplayScreen objects, > > one per native window. You'd need to make BitBlt check to see if > the destination was any of the DisplayScreen objects associated with > a window and do a similar copy-to-the-real-window if so. > > Look at the implementation and callers of ioShowDisplay(). > > -- John And, of course, John was right. A day and couple of primitives later, move the Squeak views to the origin of the window, and voila -- There be Squeak in native windows. Alas, I still need one more push. I have brought Squeak events internal to the image, I do my message dispatching, etc. Here is where I am stuck. Should each of the native windows maintain their own ControlManager? As I understand it... Each project has its own ControlManager instance, which keeps track of all the View/Controllers in the project. Thjs instance is stored in the global variable ScheduledControllers. When you run Squeak there is only one native window into which each view is displayed. I 'll call this the SqueakWindow. Switching projects switches the ControlManager instance, and you get a different view list for each project. So with my newfound empowerment, I open a native window browser, and schedule it in ScheduledControllers. I reset the native window to be the window on the screen and a new DisplayScreen becomes the place where the associated view is projected. However, all of the scheduled views still want to display onto the global variable Display. Fortunately, in the native window only the new browser shows, because it is on top. All looks good until... You try to update the original native window. The new browser shows up there too, at the origin. ( Smiley/Frowny faces omitted / expletives deleted ). So here are the questions -- How do I fix this? Should I maintain a ControlManager for each native window and hop back and modify Project to keep track of multiple control managers? Should I make the ControlManager instance screenController change when a native window takes control? Associate a display with a view, and make the view only display on its associated view. Any insights would be appreciated. jim

1 0

Book metaphor for a Morphic-based browser alternative
by Sam Adams 02 Jun '98

02 Jun '98

Squeakers, Here's a random idea for a new kind of browser. Each method is a page in a book, the variable definitions are on a page, the class comments, etc. The pages are formatted to suit their contents. Any page may be edited, which affects the associated method, variable def, inheritance relation, etc. Pages may be annotated (like margin notes) by attaching text or graphics (or hyperlinks) to page elements or page locations. These annotations, unlike margin notes, can be switched on or off as desired. This is similar to a comment system Ken Auer and I once developed for a ST80-based graphical CASE tool. But back to the book metaphor. A class is like a section in a book. Small books my contain only a single class, larger books might represent families of classes like collections or frameworks like PWS or MVC. A book might also represent a collection of code fragments and objects, like a collection of workspaces. Other bookish concepts might be exploited such as tables of contents, index, bibliography, book shelves, libraries, archives, trilogies, encyclopedia, etc. The metaphor is stretched a bit when you think of multiple copies of the same book being open to the same page and then a change in one book affects them all. but hey, no metaphor is perfect. Anyway, this sounded like a straightforward hack using BookMorphs with connections back to the Browser models. My current tasks have kept me away from active Squeaking, so I thought some of your Morphic experimenters might like to take this on. Regards, Sam Sam S. Adams, Distinguished Engineer, IBM Network Computing Software Division tie line 444-0736, outside 919-254-0736, email: ssadams(a)us.ibm.com <<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>

1 0

Update O76: Form Transition Broken
by Matt Rosen 02 Jun '98

02 Jun '98

The Morphic environment is really getting usable. Ran into a minor problem, however. Update 076 for Squeak 2.0, among other things, replaced Object>do: with Object>in: The method below now needs to be changed to use in: instead of do: (it is invoked by turning a page in a book morph, for example). Form (transitions) wipeImage: otherImage at: topLeft clippingBox: clipBox rectForIndex: rectForIndexBlock | index thisRect clipRect | index _ 0. clipRect _ topLeft extent: otherImage extent. clipBox ifNotNil: [clipRect _ clipRect intersect: clipBox]. [(thisRect _ rectForIndexBlock value: (index _ index+1)) == nil] whileFalse: [thisRect in: [:r | self copyBits: r from: otherImage at: topLeft + r topLeft clippingBox: clipRect rule: Form over fillColor: nil. Display forceDisplayUpdate]]. -- Matt Rosen, Director for Technical Services San Joaquin Delta College

1 0

st browser of Java code
by Jason Karney 02 Jun '98

02 Jun '98

Hi, Does anybody have a Java class browser for Squeak? -- Jason Karney -- NetGenics Research Team jason(a)netgenics.com [STOP] Okay, you were there yesterday, but Where do you want to go tomorrow?

4 4

RE: floatarray primitives
by Griggs, Travis 02 Jun '98

02 Jun '98

> -----Original Message----- > From: Eric King [mailto:rex@smallandmighty.com] > Sent: Tuesday, June 02, 1998 6:21 AM > To: squeak(a)cs.uiuc.edu > Subject: Re: floatarray primitives > > > :I am looking for floatarray which are implemented in > primitives for speed. > :I want to use them for intensive vector and matrix type calculations. > > I'm also interested in some capabilities like this, but > I don't think it's > very high on the Squeak team's to-do list, and I haven't > found any third > parties who've attempted this yet. There's also the question > as to how much > such a library would bloat the Squeak VM. > Personally, I think a high-speed & portable math > library would be a > wonderful addition to Squeak and go a long way towards increasing its > performance. I am willing to help out on such a project but > how should such > a library be structured? Matrix routines seem like a good > place to start, > but what sorts of matrix routines? You mention a floatarray > class, should > it be strictly one dimensional for simplicity, or n-dimensional for > generality? (I'm a voxel person, so I have an interest in seeing fast > support for 3D arrays ;)) Have any of you looked at ST/X. I'm not suggesting you use ST/X necessarily, I recognize that the goal is to do this in Squeak. But it is interesting how ST/X solves this. ST/X does have FloatArray. In fact, it has a TypedArray classes for each kind of base C number type. The difference in ST/X is there inline-C. I'm not a VM/C hacker, otherwise I'd love to see something like this benefit the Squeak community. ST/X has a processing program called STC, that takes Smalltalk source and turns it into ANSI (maybe K&R actually) source. This is similiar in principle to the C translation capabilities of Squeak. IMO, STC has the edge, because it does not require you to write your Smalltalk in a C like way, or restrict use of certain Smalltalk constructs. You can do blocks, and all of the other cool Smalltalk stuff that we love. What this means is that you can also embedd fragments of code in your Smalltalk code, that are not meant to be translated, because they are written in C already. When the parser/compiler sees a method that has the embedded C tokens in it, it automatically converts the entire method to C and compiles it using your favorite C compiler, right there while you watch. Rather than interpreted, or JIT'ed, it's force compiled. I have found this to be extremely cool as I have played with it. A long time ago, since we do alot of numerical processing where I work, we taught collections how to add, multiply, subtract, divide, etc, ala numeric vectors. Adding this behavior, as primitives, was so easy, it made me laugh. In VW, to do this, we had to code up a DLL, an ExternalInterface, blah, blah, blah. I looked at doing the same thing in Squeak. STP even posted a good description of how to write your own primitives. But that required rebooting the image, recompiling the VM, picking a prim number, c'mon.... In ST/X I just typed in the simple C loop to add the argument to the recievers elements, and return the new array as an object, hit the accept button, and was off and running. Ultimately, I would love to see this kind of approach to the Smalltalk-C bridge in Squeak. The down side, is that you leave the developer open to write C code in methods. It's fair to argue that this is just as portable as the current philosophy, since the Squeak CTranslator converts things to C anyway. The upside, is that you can change (at least some of) the VM on the fly. For grins one day, I changed the basicNew C code to add 2 bytes of fluff to each object, and print out the memory address of the new object to STDOUT. I hit accept, and tada, STDOUT started scrolling tons of numbers. I didn't have to reboot the VM, decide that this was esoteric primitive number 666. It was an extremely vindicating feeling. I could not have done this in Squeak. Anyway, if you want to do FloatArray primitives, that IMO is the way to do it. -- Travis Griggs Key Technology, Inc. tgriggs(a)keyww.com To Smalltalk! - and Beyond!

1 0

Rug Beport - Bug Fix / PluggableButtonView action:
by John-Reed Maffeo (rlpa80) 02 Jun '98

02 Jun '98

I have found and fixed a small bug in Squeak. FormMenuView was sending the message actionSelector:#turnOn to an instance of PluggableButtonView, but PBV did not understand. Browsing through the protocol for PBV I found a method that included action: but there was no seperate action: method or actionSelector:. I figured that the method for PBV should be action, so I wrote one and made the changes to FormMenuView to replace actionSelector: with action:. If this is acceptable to Squeak Central, please add it to the code base. John-Reed Maffeo Squeak Guru Wannabe (level 2?) 'From Squeak 2.0 of May 22, 1998 on 1 June 1998 at 9:58:53 pm'! !FormMenuView methodsFor: 'private' stamp: 'jrm 6/1/1998 21:57'! makeColorConnections: indexInterval | connector buttonCache button aSwitchView | connector _ Object new. "a dummy model for connecting dependents" indexInterval do: [:index | buttonCache _ FormButtons at: index. buttonCache initialState = #true ifTrue: [button _ OneOnSwitch newOn] ifFalse: [button _ OneOnSwitch newOff]. button onAction: [model changeTool: buttonCache value]. button connection: connector. aSwitchView _ self makeViews: buttonCache for: button. aSwitchView borderWidthLeft: 1 right: 0 top: 1 bottom: 1; action: #turnOn]. aSwitchView borderWidth: 1. ! ! !FormMenuView methodsFor: 'private' stamp: 'jrm 6/1/1998 21:56'! makeConnections: indexInterval | connector buttonCache button aSwitchView | connector _ Object new. "a dummy model for connecting dependents." indexInterval do: [:index | buttonCache _ FormButtons at: index. buttonCache initialState = #true ifTrue: [button _ OneOnSwitch newOn] ifFalse: [button _ OneOnSwitch newOff]. button onAction: [model changeTool: buttonCache value]. button connection: connector. aSwitchView _ self makeViews: buttonCache for: button. aSwitchView borderWidthLeft: 1 right: 0 top: 1 bottom: 1; action: #turnOn]. aSwitchView borderWidth: 1. ! ! !PluggableButtonView methodsFor: 'accessing' stamp: 'jrm 6/1/1998 21:53'! action: aSymbol "Set actionSelector to be the action defined by aSymbol." actionSelector _ aSymbol ! !

1 0

Versant, anyone?
by Les Tyrrell 02 Jun '98

02 Jun '98

Has anyone done anything to try and get the Versant OODB up and running with Squeak? After all, the Smalltalk version is a file-in with a DLL... les

1 0