Squeak-dev June 1999

squeak-dev@lists.squeakfoundation.org

139 participants
408 discussions

Adding new instance variables to Behavior...
by Kevin R. Powell 24 Jun '99

24 Jun '99

I was working on a quick and dirty namespace implementation for squeak and discovered a small problem. If I add a new instance variable called namespace to Behavior I get an error when the Dictionary class is being recompiled (looks like the Dictionary class's instance variable offsets are one off with respect to Behaviors new added inst. var.) I had to redefine Behavior>>superclass: aClass to the following to get this kind of change to proceed at all: superclass: aClass "Change the receiver's superclass to be aClass." (aClass == nil or: [(aClass isKindOf: Behavior) or: [(aClass isKindOf: Metaclass) or: [aClass == Metaclass]]]) ifTrue: [superclass _ aClass] ifFalse: [self error: 'superclass must be a class-describing object'] I am doing this on Windows/NT using 2.4c with all updates applied, however this looks like something that should blow up on any OS type. Kevin

2 1

AW: Squeak and COM
by Torsten.Bergmann＠phaidros.com 24 Jun '99

24 Jun '99

>Has anyone implemented any COM capabilities into Squeak? Is anyone thinking >about this? Any work-in-progress? My company is working with SmalltalkMT (http://www.objectconnect.com) to use COM functiality. I's very impressive how easily we can handle the complexity of COM with Smalltalk as a more natural language. It's very easy to create COM Servers, ActiveX Controls, Automation Clienst/Servers, ... And the resulting executable is fast and small as his C++ counterpart. The Win32 Source of the Squeak VM has defined some functions for COM to use DirectX (see sqWin32DirectX.c). But it's work in progress of Andreas. I don't think it is very hard to bridge to COM by wrapping the COM library (Ole32.dll) and use COM in Squeak like SmalltalkMT does. But you get too platform dependent. You need EntireX on other platforms to use COM. And you have the problem of Garbage Collection, because in COM you have to manage the lifetime of components by yourself (AddRef(), Release()). But at this time COM is the best way to deal with components. It's language independent. JavaBeans/EJB is limited to Java . CORBA is not really a component model (it deals with objects). But it's interesting because of the powerfull facilities. We need the language independence and power of COM, the facilities of CORBA and the platform independence of Java. Maybe Squeak will be the right platform but we have to do a lot for this. We need exchangable components in Squeak which are independent from implementation. Mixing code by loading different change sets wont be the right way. Torsten

3 2

Morphic tutorials 2 and 3?
by Nathan Young 24 Jun '99

24 Jun '99

I saw a recent posting saying that there were second and third morphic tutorials out there. I can't seem to find them or the post I read about them in. Was I dreaming?? ----->Nathan -- ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ Nathan Young nathan(a)ncyoung.com (805) 686-2830

1 0

Re: Tutorial on Morphic, Part I
by Jerome.Garcia＠wj.com 24 Jun '99

24 Jun '99

Ted and John, I finally found time to play with your tutorial on the Morphic Graphics system. It is really great and will be really useful when I try to convince my nieces and nephews (not to mention their parents) to use Squeak. Thanks much. Jerome ______________________________ Reply Separator _________________________________ Subject: Tutorial on Morphic, Part I Author: "Ted K." <Ted.Kaehler(a)disney.com> at INTERNET Date: 6/14/99 3:09 AM Folks, What a delight to see so much interest in documentation for Squeak. Here is the first of a three-part tutorial on the Morphic Graphics system in Squeak. The tutorial is by John Maloney (as he taught it to a class), edited by Ted Kaehler and Dwight Hughes. http://www.squeak.org/tutorials/morphic-tutorial-1.html (Please email me your changes and suggestions privately.) Don't forget about the other documentation at: http://minnow.cc.gatech.edu/squeakDoc.1 and http://minnow.cc.gatech.edu/squeak.1 --Ted. Ted Kaehler, Walt Disney Imagineering, R&D (home) 3415 Cork Oak Way, Palo Alto, CA 94303. voice (650) 424-1070 http://www.webPage.com/~kaehler2/ Remember, we are the lowest form of intelligence that can do this sort of thing.

1 0

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

23 Jun '99

>[About adding cutting-edge bit-flipping to Squeak] > >The general direction is to make the best of the best that is generally >portable. > >Nobody'd stop you from implementing anything for your favorite platform >(and >it'd make a bunch of XYZ-platform-users happy) but it probably won't go >main-squeak-stream. > >On the other hand, if you can significantly improve what's there, in a LCD >(maybe GCD is more appropriate ;-) manner, we'd all be very happy. I think that I can make a case for a GCD implementation. Consider AltiVec: handles 32 128-bit registers which can be manipulated as 4 longs or 8 shorts or 16 bytes, or 4 floats, using one instruction that manipulates all of these in parallel. On an AltiVec (G4) PowerPC, an AltiVec Smalltalk primitive would map directly to the single AltiVec instruction (which generally takes 2 cycles or so to execute). That's an obvious speedup for G4 PowerPC users. HOWEVER, the AltiVec instructions were designed specifically by Motorola and Apple to handle several important generalized problems, including bitmap manipulation for advanced graphics AND DSP applications to replace Motorola's older DSP chips. A set of Smalltalk primitives that models an ISA that was designed to handle advanced graphics and DSP operations, regardless of whether these are implemented using single instructions, or a larger C-based simulation, would be VERY worthwhile, don't you agree? I mean, imagine being able to reimplement the Squeak MIDI using powerful primitives designed for that purpose. The savings might be enormous. ---------------------------------------------------------------------- Use your imagination. ----------------------------------------------------------------------

1 0

The Importance of Style Distinctions
by Peter William Lount 23 Jun '99

23 Jun '99

Hi, I do care about style. I do think that style is important. I just don't think that a "style rule" that says "if you have more than N variables then you have a BAD or POORLY WRITTEN method" is a rule that I would follow. RELATIVE IMPORTANCE OF RULES AND GUIDELINES I think that other "style rules" like "names of variables" is "MORE" important. I am reducing the importance of the "temporary variable count" rule to be less than the importance of the "variable name" rule. STYLE GUIDELINES VS STYLE RULES I consider "style" to be a "suggestion" or "guideline" that is taken with a grain of salt. I don't think that "style" should be enforced as if it's "rigid rules" or "laws". I think of styles as guidelines that provide suggestions for improvement and quality acceptance. COMPLYING WITH A STYLE Certainly you can be "compliant with" or "using" a "style". Certainly it would be valid to say that some program (or portion thereof) does not meet the "criteria for A PARTICULAR style". For example, if asked to attend a "formal tuxedo" party and you arrived in "punk style" clothing you would not be meeting the requested style. ONLY ONE SMALLTALK SYTLE? I think that there is MORE THAN ONE "Smalltalk Style". If you have identified, as others have done, elements of a "Smalltalk Style" that you have "encoded" by some means "into rules" this is fine. I have no objection to your "Definition of Smalltalk Style" as long as you don't force it on me (and others) as "THE ONE AND ONLY VALID SMALLTALK STYLE". This is all I am saying. MANY SMALLTALK STYLES So far we've identified a few differing styles of writing Smalltalk code. STRICK SMALLTALK STYLE There seems to be a "Strict Smalltalk Style Rules" that says that it's "bad" style to write "methods with more than 5 or 10 temporary variables". Actually, this "Strict Smalltalk Style Rules" seems to go further and say that all such methods "MUST" be re-factored at all costs to meet the style rules. Correct me if I am mis-stating this. Actually, I would like to know your "defintion of your Smalltalk Style". If you had to name you style what would you name it. I certainly don't have an objection to your saying something like "according to Strick Smalltalk Style Rules method x is poorly written, due to too many temporary variables, and must be rewritten in order to comply." SMALLTALK STYLE GUIDELINES Another style, "Smalltalk Style Guidelines", is more relaxed about the issue of the number of temporaries. A guideline would say something like "if you have more than 5 or 10 temporary variables you may wish to CONSIDER refactoring the method". It's a "hint" or "indicator" for you but it is not manditory. IMPORTANT DISTINCTION Certainly the "distinction" of "counting variables" is something that can provide information about the "complexity" of a method. I think we are disagreeing on the "action" that "must" or "could" be taken in the light of the information gained from this "counting variables distinction". FUZZY LOGIC and THINKING I think "Style" is too fuzzy to have "definate rules" that "must" be applied. This is why I use the term "guidelines" instead to "suggest" potential "improvements". I also wonder if all of the "rules" in a "style" are even self consistent and non-contradictory? All the best, Peter William Lount http://www.smalltalk.org peter(a)smalltalk.org

1 0

The Importance of Style Distinctions
by Peter William Lount 23 Jun '99

23 Jun '99

1 0

[Newbie Q] COM, beans, and Squeak
by Jeff Szuhay 23 Jun '99

23 Jun '99

One of the coolest things about COM and Java Beans are the ability to plug modules into an application or an enviroment. What is the Squeak approach for this? Is anybody working on a "Squeak Droplets" or some such component architecture? 8-) --************************************************** Jeff Szuhay <mailto:jeffs@pstnet.com> Lead Macintosh Engineer voice: 412/271-5040 x227 Psychology Software Tools <http://www.pstnet.com/>

1 0

Re: Thoughts on the nature of programming...Asynchronous Events
by Daniel Vainsencher 23 Jun '99

23 Jun '99

>Could it possibly work? This is one of those situations that really requires >massive parallel processing. This is not coincidential - a very deep, hard to overcome difference between evolution (in the broad sense of natural systems) and code is that evolution has many, many atoms *all* working in parallel *every microsecond*, at *many levels* simultanously, to create stable, interesting systems. It doesn't deal with complexity "differently" than us - it mostly doesn't care, because it's processing power isn't scarce. For the same reason, the *huge* coupling in natural system is not that big a problem. Of course the fun part is that it does manage to create subsystems that use higher level heuristics (like us), but those have inherent problems, the chief being scarcity. The wrongness of programming is that it is an optimization of a resource that is scarce but becoming less so (computing/thinking power). Such an optimization gets old fast and has no alternative to being a "premature optimization", a Bad Idea (tm). Obviously, we should strive to pay as little as possible in lost expressiveness, and we do that by continuously trading the proliferating computing power for the constained brain power, and both combined for expressive "stuff". Squeak does this in quite a few different ways, and every new one posted is a wonder. Daniel

1 0

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

23 Jun '99

Bruce O'Neel <beoneel(a)mindspring.com> said: >>front-end to the GNU Objective-C compiler... Best of both worlds: >>interactive testing of algorithms within Squeak and then direct-compile >via >>the Obj-C compiler. Give Java a run for its money... > >Hmm, I already find Squeak to be faster than java on my choice of >platforms (Mac). Yes, I'm sure if you pick the right combo of tests >maybe java is faster but Squeak is quite fast for me. It's even more >impressive when you keep in mind how much of it is Squeak and how little >is compiled c... I'm hitting the performance wall right now, simply examining how to extend BitBlt to handle GX-like color. There appears to be too many levels of indirection inherent in the current implementation of BitBlt do what I'd like efficiently. Alternatively, a set of more powerful bit-manipulation primitives for Smalltalk might work almost as well, and would be far easier to implement. The current Smalltalk bit-manipulation primitives are, well, primitive compared to what is available in today's processors, especially when you look at what MMX and AltiVec and other SIMD instruction set architectures can do. It should be possible to create a set of bit-manipulation primitives that can be mapped directly to modern processors or to efficient C simulations of the same. What should a generic set of higher-level bit-handlers be able to do and how high-level should we go? Should multi-word manipulation be supported, for instance? PowerPC's AltiVec handles 32 128-bit registers and can manipulate them as 4 32-bit, 8 16-bit, or 16 8-bit registers in parallel, either as fixed or float representations. Is it worth attempting to provide direct Smalltalk access to these capabilities? Should we go with LCD manipulation and specify that only 32-bit registers would be supported, or should we aim towards the highest-level and require other Squeak implementations on other CPU families to implement the capabilities in C? Comments? ---------------------------------------------------------------------- Use your imagination. ----------------------------------------------------------------------

2 1

← Newer
1
...
7
8
9
10
11
12
13
...
41
Older →

Jump to page: