Squeak-dev March 2001

squeak-dev@lists.squeakfoundation.org

139 participants
508 discussions

Re: [BUG] Socket assumes connection in Linux
by ajh18＠cornell.edu 31 Mar '01

31 Mar '01

Patrik Nordebo <patrik(a)nordebo.com> wrote: > Is there a way to find all uses of a primitive? CompiledMethod allInstances select: [:m | m primitive = primNum] thenCollect: [:m | m who]. Patrik, thanks for looking at this socket problem. If you have a chance please look at the socket semaphore corruption problem also. I posted a bug report about this on March 26 and its entitled "[BUG] Socket semaphore corrupted (Unix VM)". I wish I could help but I am not familiar with platform specifics. Smalltalk has happily sheltered me from those details for many years. -Anthony

4 3

Help wished? [was: Re: Genie on iPaq..comments]
by Stephan Rudlof 31 Mar '01

31 Mar '01

Nathanael, Nathanael Schärli wrote: > > I was aware of the fact that the old recognizer is using the pen trail, but > when I implemented Genie I thought it would be cool if the Genie trail would > be a real Morph and we could even use it properly on a BouncingAtomsMorph or > anything else that is moving around. However, since trails are anyway only > visible for a short time, performance is much more important than fancy > features like correct updating on top of a BouncingAtomsMorph. If we can > make it faster using a single Stroke Morph instead of multiple LineMorphs > that would be cool! Otherwise, I'll probably just switch to using the trail > pane (as turtles and the old recognizer do it). > > (Historic note: The first pre-alpha-version of Genie was using the trail > plane instead of Morphs and once more it looks as if the straight-forward > and simple approach is not so bad as it looks like :) > > As far as the delay in the lookup is concerned, I'm really thinking of > writing a primitive for it. 90% of the time is spent in the method > CRStrokeFeature>>sameClassAbsoluteStrokeDistance:forReference: that > basically iterates over the vector decompositions of two gestures and > compares them using integer arithmetic. (I avoided any floating point > operations because that is even slower on small machines). This method has < > 100 LOC and it only calls two helper methods (3 LOC each). I don't have much > experience concerning the performance gain by making a primitive out of such > a method, but I have a feeling that it could be quite a lot. > Does anyone know more? After taking a look onto it I guess a speedup of factor 5 to 10 for this method, if written as primitive. This is a conservative estimation. If you or another person haven't written it so far, I'd like to help here. Greetings, Stephan > > Nathanael > > > -----Original Message----- > > From: hmm(a)heeg.de [mailto:hmm@heeg.de] > > Sent: Thursday, March 15, 2001 2:32 PM > > To: squeak(a)cs.uiuc.edu > > Subject: Re: Genie on iPaq..comments > > > > > > Kevin Fisher wrote: > > > I'm not sure what could be the cause of the drawing > > slowness. It certainly > > > isn't system load, as I'm basically only running an > > X-server and Squeak (no > > > window managers or anything else). > > > > > > Generally Morphic is considerably slower on the iPaq, but > > as I mentioned, the > > > CharRecog pen trail isn't laggy at all by comparison. > > The difference between CharRecog and Genie is that the former > > writes its > > trail directly to the screen, while the latter contructs and > > modifies a > > Morph for the pen trail, which is of course much slower if Morphic is > > slow on your machine. I think it should be easy to retrofit > > Genie with a > > direct-to-screen trail. > > I have also noticed that the feedback is accomplished with a number of > > straight line morphs. Probably a stroke morph which just gets > > new points > > appended would make things a bit faster. This kind of morph > > might either > > invalidate the rectangle encompassing the added line segment for each > > new point, or it could draw that segment directly to screen for that > > special case. > > I will probably play with it a little bit today, maybe the > > outcome will > > be such a faster stroke morph. > > > > Cheers, > > Hans-Martin > > -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

1 0

Re: Re: [newbie] how does Object implement new?
by GeneCox 31 Mar '01

31 Mar '01

Almost everything in SmallTalk is interesting, but not its MESSclasses tree;-) To my opinion, some kind of clarifying still is in need. Since I use English as a foreign language I just try my best to explain as follows: Being a Chinese, and with a good knowledge of Eastern Philosiphy, I don't see anything of a real heirarchy in Smalltalk( or any OO children language). Sorry, I haven't read a lot, before I say this, of documents here and there on the net. I'm not afford to do that in China. Different levels of classifying or grouping have nothing to do with heirarchy at all. And keep this clear will help SmallTalk a lot as a pure class-based language. The chaos came out of mistaking objects but not their attributes to be the main role or target when the class-tree was invented. For instance, say I am a man, middle aged, tall, used to be a proffessor and now work for some ABCD company as Mananger of Marketing Department, then I am grouped into these classes: Man MidAged Tall people People who have changed job Company employees which class should I belonging to? I simply be someone who posess all these attributes. The root of the Smalltalk Classes Tree should be Atrribute, not Object. And the puzzle of multi- or singular- heirarchy will also be solved. I learned math in college, Mr Octave be the Proffessor who taught me, and I learned some music from Miss Doremi, adding to a lot of other things from other people. Here somebody will see something of Heirarchy occurses. But one will not be son of their teachers simply because he has learned something from them and objects in a Smalltalk class tree never have such teacher-student relationship. It is far more clear to look at things this way, that to treat anObject as be made up of someAttributes( relations with others), and atrributes can be grouped if they are common ones shared among some objects. (When talking about a piece of attribute particularly, it is correct to say anObject belongs to some group, but only in that aspect). And these groups can still be grouped, to an imaginaryAtrributeRoot, which represents atrributes common among all objects. Some thing else will emerge from this kind of clarifying. For Atrribute should at once be divided into two groups as knowledge and behavior. And the knowledge part of anObject's atrribute shows itself up when it gives some information to other objects or gains some from others, while the behavior part can be "seen" when the object does something to cause other objects or itself to change. Giving/gaining information, of course, is a kind of behavior. All what a SmallTalk object needs is just, and at least, these two part of attributes. Because they are not a real phisicaly object at all! For now, the knowledge part is less noticed, and thrown into some class/instance or class instance variables in a term of "data". Think it over. If it has been correct to emphases the behavior part of anObject's attributes in that all its knowledge will be invisible unless it does something(perhaps influences others), then why not take a step forward to throw away those C/I or C.I. variables? Just let object learn something, tell something, and manage its knowledge or memory. Take a look at these: Bonny keep: 10 as: #age. (or, #keep:for: --you know my English is not good ENOUGH) Bonny pop: #age ifTrue:[ Bonny awarded. Bonny age printOn: blackboard ]. Bonny age: Bonny age + 1. Bonny forget: #age. The system will manage those hiden things better than programmers, for instance, we only need to care about what the target object should know and what it will do, and decide accordinly which group should be the most efficient to reside it in, and some kind of type check can be available at once though it's free to use or not use( I use newInstance instead of new to emphasize the group-individual relationship of atrribute classifying): initialize "I will prepare my memory for everything" self keep: Number newInstance as: #age; "the programmer want this be checked" keep: nil as: #hobby; "not checked" keep: Fruit newInstance as: #favour; "not Vegetables..." keep: JavaBean UglyFace as: #afraid. "...Java?!" and system will generate some methods include "query" ones as #component and #knowledge: Bonny component. => #(#knowledge -> #(#aNumber #nil #aFruit #'a JavaBean UglyFace' #andOthers) #behavior -> #(#age #age: #hobby #hobby: #favour #favour #afraid #afraid: #sleep #run #eat #sing #etc )) Bonny knowledge. => #(#age #hobby #favour #afraid) "not knowledge-gaining/showing actions, though looks alike" If you like change, then include #behavior to report all its unique behaviors as to its "working group". At least the OO manner will be enforced, and Smalltalk objects made up of atrributes will be able to change themselves all the time, just like their model real objects( for you can always ask it to keep: something as/for: #aSelector, then make use of that!). A additional #canActAs: aPresident method would make Bonny act like a President whenever the Course would comfirm that. Yet this is not multi-heirarchy, but multi-grouping at different level for different situations or aspects and Bonny's knowledge and behavior will change. Also, this will give the system a chance to mask itself into some Language Wraper when it's in need. For example, Smalltalkers will easily use any libs available no matter which language they are originally stemed from as long as Squeak will mask the codes to run on their Virtual Machines, for instance, say Java VMs. When you browse the IBM homepage searching for NetRexx and then find that this <500k sized little thing generates some good code to make advantege of Java and JavaBeans, you may want to make a try. Tea or coffee, that's not the question. Only important thing is that some Smalltalk water, will, make it. Thanks for all of those who invented Smalltalk and have ever contributed to it! Otherwise many people would live in darkness. at 2001-03-29 17:40:00 you wrote： >On Thursday 29 March 2001 14:37, Karl Wilson wrote: >> why doesn't it say something like: >> >> ProtoObject class subclass #Object class >> >> instanceVariableNames: '' > >When you do "ProtoObject subclass: #Object ..." this method takes care >of all these little details automatically. > >> and why can't you spawn a class side heirarchy? >> >> Behavior >> ClassDescription >> Class >> ProtoObject class >> Object class > >Ooops - I had said you would reach "Behavior class" but that was wrong. >Since the system created all these metaclasses behind your back and >doesn't even bother to give them proper names, showing them like this >would probably cause more confusion. It is easy to patch the tools to >do this, but I don't think it is a good idea. > >> I am sure this will all make sense after awhile. Thanks again. > >Others have given a lot of great pointers to more information about >this than most people want to know. I prefer the alternative adopted by >the Self dialect of Smalltalk - simply design this complication out of >the language! http://www.sun.com/research/self/ > >-- Jecel Good luck! GeneCox genecox(a)21cn.com

1 0

RE: Question about BitBlit and half tone forms...
by Raab, Andreas 31 Mar '01

31 Mar '01

Rick, > OK, so I don't understand what a halftoneForm is... The halftone form is basically a mask used during the pixel transfer. It is used to mask out certain pixels (or color components) and because this can be used to achieve halftoning it's called a halftoneForm. BTW, I don't really understand what you're trying to achieve with the halftone form in your code (e.g., I don't understand what you think a halftone form is ;-) so perhaps you can explain what you were trying to do?! > If you think that the two forms are interpreted identically > during the blt... > Ummm... They don't blit the same on my system... You're right. It seems that there's some special code in BitBlt that interprets a form in the halftoneForm as "Old-style 32xN monochrome halftone Forms" which explains the effect you're seeing. It uses the height of the form (which is why your first variant works) but not the width (nor the depth) of it. And it doesn't fail if the input is not a 32xN monochrome form. The "modern style" halftoneForm is really any word array (Bitmap) which is interpreted as mentioned before (e.g., (32/depth) @ bits size). Cheers, - Andreas

1 0

RE: Question about BitBlit and half tone forms...
by ret＠deltanet.com 31 Mar '01

31 Mar '01

Hi Andreas, OK, so I don't understand what a halftoneForm is... If you think that the two forms are interpreted identically during the blt... Ummm... They don't blit the same on my system... Thank you for the information! I appreciate it!!! Cordially, -Rick- "All you've got to do is own up to your ignorance honestly, and you'll find people who are eager to fill your head with information." - Walt Disney - >>>>>>>>>> Andreas had said: >>>>>>>>>> > >The halftone form is always treated as (32/depth)@(bits size) format. E.g., >the two forms are interpreted identically during the blt. > > - Andreas

1 0

RE: Question about BitBlit and half tone forms...
by Raab, Andreas 31 Mar '01

31 Mar '01

The halftone form is always treated as (32/depth)@(bits size) format. E.g., the two forms are interpreted identically during the blt. - Andreas > -----Original Message----- > From: ret(a)deltanet.com [mailto:ret@deltanet.com] > Sent: Friday, March 30, 2001 2:22 PM > To: squeak(a)cs.uiuc.edu > Cc: recipient list not shown > Subject: Question about BitBlit and half tone forms... > > > Hello, > > I was wondering why the case of ifTrue works as expected and > the path thru ifFalse does not... > Any ideas? On macOS9 Squeak3.1alpha+3848... > > makeInterlaceImageWithLeftEye: aLeftEyeImage andRightEye: > aRightEyeImage > "I make an interlace image from a left and right eye image... > This can also be used to produce lenticular images... > All images sent are 32 bits deep..." > > | anInterlaceImage hf | > > lensHorizontal > ifTrue: [hf _ Form extent: 1 @ 2 depth: 32. > "horizontal interlace width 1 by height 2" > hf colorAt: 0 @ 0 put: Color white] > ifFalse: [hf _ Form extent: 2 @ 1 depth: 32. > "vertical interlace width 2 by height 1" > hf colorAt: 0 @ 0 put: Color white]. > > anInterlaceImage _ aRightEyeImage deepCopy. > > "Now blit the leftEyeImage onto the interlaceImage > thru the halftoneForm... " > (BitBlt > destForm: anInterlaceImage > sourceForm: aLeftEyeImage > halftoneForm: hf > combinationRule: Form paint > destOrigin: 0 @ 0 > sourceOrigin: 0 @ 0 > extent: aLeftEyeImage extent > clipRect: aLeftEyeImage boundingBox) copyBits. > ^ anInterlaceImage > > Cordially, > > -Rick- > > "We keep moving forward, opening new doors and doing new > things, because we're curious." - Walt Disney > >

1 0

smalltalk76 (was: [newbie] how does Object implement new?)
by Jecel Assumpcao Jr 31 Mar '01

31 Mar '01

On Thursday 29 March 2001 18:42, Stephen Pair wrote: >�Are there any papers (or code) for Smalltalk-76 on the web? �I'm sure >�they've been announced before (and wasn't there an implementation of >�it for Squeak?), but I've forgotten. This one is great: http://users.ipa.net/~dwighth/smalltalk/St76/Smalltalk76ProgrammingSystem.h… but doesn't mention meta-classes. On page 34 of Alan Kay's "The Early History of Smalltalk" paper there is a drawing labeled "Smalltalk-76 Metaphysics". All classes were instances of the class Class object, which was a subclass of the class Object. Little Smalltalk initially had the same design (which makes all classes have the exact same set of class methods) but has moved to a more Smalltalk-80-like system in version 4. There is a simulation in Squeak of Smalltalk-72, not 76. -- Jecel

5 6

X86 jitter???
by Elzbieta Chludzinska 31 Mar '01

31 Mar '01

How is the X86 jitter progressing? Is it ready for prime-time? Elzbieta

1 0

Re: benchmarks
by Tom 30 Mar '01

30 Mar '01

On Fri, Mar 30, 2001 at 08:04:32AM -0800, Tim Rowledge wrote: > > > But why does Squeak do poorly compared to Java (even without JIT)? Is > > > it mainly because Java has static typing and no escaping method contexts > > > (blocks)? > The top set of benchmarks are almost purely number related trivial math > tests. fib should be dominated by function calls, and arrayRounds and assocRounds by accessors or looping. If they were dominated by math, then the implementation would either be doing a really lousy job at math or a really great job at those other things. > They make no meaningful usage of anything remotely interesting to > do with control, polymorphism, varying data types, memory usage, > whatever. Yes, that's deliberate. Those uninteresting things may only make up a small fraction of the code of Lisp or Smalltalk programs, but they are also the things that often dominate inner loops (at least my inner loops) and that actually can be optimized by a good compiler/runtime. As another saying goes, for many programs, 95% of the time is spent in 5% of the code. > When you get to really complex systems the old Lisp truism almost > applies "any sufficiently complex application ends up implementing Lisp > badly" and your C-blah-glah program becomes both poorly performing and > unmaintainable. I don't get your point. As a Squeak user, I merely wanted to get a very rough impression where it stands with respect to other implementations, in particular other byte-code implementations of dynamic languages. That lets me figure out what kind of problems I can tackle in it, also in comparison to my experience with Python and Lisp. And it gives me a better idea of why things like Scamper or Morphic are a bit sluggish on my PII/300 and what I might be able to do about it. The good news is that as far as byte code interpreters go, Squeak seems to be doing pretty well. > What is 'Bistro' and why is it so much slower than Squeak on the STIC > tests? Bistro is an implementation of a Smalltalk-variant on top of Java (http://bistro.sourceforge.net/). Without declarations, it's significantly slower than Squeak; with declarations, it seems to be significantly faster. You can mix Smalltalk and Java code. Cheers, Thomas.

2 1

Re: Squeak on tinies (was Re: Squeak on iPaq-Linux Update)
by danielv＠netvision.net.il 30 Mar '01

30 Mar '01

Kevin Fisher <kgf(a)golden.net> wrote: > Well I don't have any screenshots handy (yet) but... [Pen based PDA env] Sounds very cool. I'd love to see it. > In addition to the other suggestions (such as the Lucy font), you'll probably want to stick with > flop-out scrollbars to save space on the screen. Or, if you prefer inboard, using the narrow & hidden > scrollbar options will save a fair amount of space. In my experience, the scrollers tends to flop out of the screen. Inboard, narrow, hidden works pretty well. [Bobs browser] Yup, that concept seems better for tiny screens, but I couldn't find the Class Categories, and the hierarchy tree get too big to. I think maybe I was looking for the wrong thing in a PDA - it just isn't a desktop, and not useful for the same things... Daniel

2 1

Jump to page: