Squeak-dev January 1998

squeak-dev@lists.squeakfoundation.org

81 participants
196 discussions

Draw80 Conversion Progress Report
by John-Reed Maffeo 29 Jan '98

29 Jan '98

Sam et al, I got a sorta working version of Draw80 running under Squeak 1.3. It only sorta works because there is still a lot of tweaking required to get the drawing tools sorted out, but I got a window, I can choose different tools, and some of them almost work AND I can run it with out crashing! I have been adding compatibility code to the base image to do it, but I think that I have also learned enough in the process that I can have a go at rewriting the source code to avoid the necessity of adding methods to the base code that only alias existing methods. (e.g. Draw80 uses <foo>:mask: Squeak uses <foo>:fillColor). Known problems include: 1. Tool palette buttons appear tiny and have no icons in them. I think this is a scaling problem. I am not going to worry about it for now. 2. The view and sub views don't seem to line up correctly. The sub views seem to be shifted left the width of the tool palette. 3. There is a pull down menu on the topView that needs to be fixed so that it will display properly. 4. A whole lot (or maybe just a little) of code tweaking in the drawing methods. My development process is quite simple. I run the code and fix what breaks. I have started over from scratch three times now and each time I get faster at fixing things. Best Regards, John-Reed Maffeo

1 0

Re: Re:Case-insensitive selectors
by Reinier L.J.M.W. van Loon 29 Jan '98

29 Jan '98

What I understand from the discussion is that Mark Wai does not want to change the case-ness of words. He simply wants the method lookup to ignore case. This is not a bad idea. OTOH, what I really like about Smalltalk is the way it approaches natural language (in this case English). Capitalization is done for readability and only (IMHO) because spaces are not allowed in selectors. I.e. you would like to write 'this is how natural language looks like' but end up with 'thisIsHowNaturalLanguageLooksLike'. So, the rule I use is: 'Write it out in natural language and then replace each space and it following character with the capitalized version of that character'. This leaves no ambiguity. To repeat some examples: unsigned integer 32 bits -> UnsignedInteger32Bits -> UInt32 as lower case -> asLowerCase as array of keywords -> asArrayOfKeywords The abbreviation of UInt32 is a bit dirty but can be deduced using the rule (I never abbreviate selectors). In the case there are parameters you would write in natural language: as byte array encoding x into y -> asByteArrayEncoding: x into: y I.e. the rule is: do not capitalize after a parameter. The first rule cannot be detected by the compiler (unless you supply a dictonairy or have it look at other selectors), the second can supported by the compiler. Furthermore, I like to mention to Mark Wai that Squeak does help a bit when you save a method and it does not recognize a selector (and lets you choose another). Last but not least: I am not amused by using the underscore symbol ( _ ) for assignment. Try converting a piece of Visual Smalltalk code with symbol like: #UP_RIGHT, #DOWN_LEFT. You can't file this is in without editing! Hope this helps.

1 0

Windoze ScrollBars, 3D Borders and Titlebar available
by Sam Adams 29 Jan '98

29 Jan '98

Squeakers, Here is the first version of a goodie that will make your Squeak windows have Windoze-style 3D borders and titlebar. Thanks to Andreas Raab for the original NiceSystemView code. ftp://st.cs.uiuc.edu/Smalltalk/Squeak/Goodies/Windoze-1.3.0.cs There is also an improved version of the Windoze ScrollBar Junta available at: ftp://st.cs.uiuc.edu/Smalltalk/Squeak/Goodies/SSAPowerTools/ Each of these will work independently, but try them together for the complete experience. NOTE: I am already aware that there are some graphical glitches in collapsed windows. Enjoy! Sam S. Adams, Distinguished Engineer, IBM Research RTP 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

Re: Transcendental Numbers
by Travis Griggs 29 Jan '98

29 Jan '98

---------- > From: sqrmax(a)cvtci.com.ar > To: squeak(a)cs.uiuc.edu > Subject: Re: Transcendental Numbers > Date: Wednesday, January 28, 1998 9:26 PM > > I also liked the DD that VS does. But after seeing the coercitive approach, > I liked it more because it needed less methods. It has the drawback of > intermediate objects. But this can be avoided almost all the time, designing the > implementation in such a way that it keeps converted results only. Then, you > convert when you start only, and work with a single kind of objects... this > kind of objects will be the one that has greater coercitive power. For > instance, I had the same problem when I designed polynomials, because I wanted to add > numbers to polynomials and multiply them by objects like integers, fractions > and so. With DD in VS, I just programmed polynomial * anything and that was > it (but then I had to check all the time what was that anything). Now, with > Squeak, I added the adapt and adaptTo methods and the conversion is done only > once (and I don't have to check what argument I'm given, so I can describe > the multiplication as polynomial * aPolynomial). I think we're seeing this through a bit different eyes. It is not clear to me whether your mixed math with Polynomials was commutative. IOW, that not only could you perform: polynomial + 4 but also that you could perform: 4 + polynomial IMO, any mixed math you add to the system, should be communtative. VS, IMO, did not do a complete implementation of the DD stuff. At least as far as points goes. In 3.0.1, you could add a simple number to a point, but not a point to a number. I would argue in VS, that you hadn't done DD (not the way I understand it). To have implemented it the way I understood it, you would've done something like: Polynomial>>+ aNumber ^aNumber sumFromPolynomial Then, for any potential argument you would've implemented the sumFromPolynomial: message, *including in Polynomial itself*. That's the beauty of DD, is that there are NO isThisOrThat checks and subsequent branches. The traversal of messages ends up in the right place. -- Travis Griggs Key Technology tgriggs(a)keyww.com GO SMALLTALK - AND BEYOND!

1 0

commernts i 1.3
by n.moray＠surrey.ac.uk 29 Jan '98

29 Jan '98

A minor but irritating problem for the unsophisticated user is that if I click on "?" in the browser, I get the comments about the method, but several lines are missing at the top in almost almost every case, and the scroll bar does not seem to let me scroll up to see the initial line or two of comment. for example, if I click on the "?" for LinkedList I get exactly the following: g the items in a textual list (menu) up or down. In addition, I provide the red button activity of determining when the red button is selecting an item in the list." Neville Work email: N.Moray(a)surrey.ac.uk Home email: nmoray(a)globalnet.co.uk send messages to both if Urgent Work address: DERA Professor of Applied Cognitive Psychology, Department of Psychology, University of Surrey, Guildford, Surrey GU2 5XH United Kingdom. Phone number: +44-(0)1483-300-800 and ask for extension 2865 Fax: +44-(0)1483-32813 Home address: 10a Hampstead Hill Gardens, London NW3 2PL. Phone: +44-(0)171-431-4813 "Be well, do good work, and keep in touch" (Garrison Keiler)

2 1

Re: Case-insensitive selectors
by Mark Wai 29 Jan '98

29 Jan '98

At 07:31 AM 1/28/98 -0500, you wrote: >I personally prefer case-sensitive languages to case-insensitive >languages. If I want to have selectors or procedures named abc, Abc, >ABC, and aBc in a program I darn well expect the language to allow it >and not try to limit what can be done. I also *HATE* underscores and >dashes in identifier, selector, or procedure names. If I wanted to >PROGRAM-IN-COBOL or PROGRAM_IN_PL_1 <gag!> I'd do so. I don't. Keep >Smalltalk case-sensitive!!!! :-) If a define a class with two methods >>aBc and >>aBC, how can I tell the differences between them without going into the implementation? For more hypothetical examples, how about >>asArrayofKeywords vs >>asArrayOfKeywords >>asBytesArrayEncoding:into: vs >>asBytesArrayEncoding:Into: >>asUInt32 vs >>asUint32 There are no standards or rules at all. And people do make mistakes when typing. We use case sensitive method signature to help us to *read* the method more easily. It should not change the *meaning* of a method. Thanks. -- Mark Wai Frontier Systems Architecture Inc. mailto: mwai(a)ibm.net or:[ mwai(a)frontiersa.com] __

3 2

RE: Smalltalk Design Question
by Mark Wai 29 Jan '98

29 Jan '98

At 05:54 PM 1/28/98 -0000, Alejandro wrote: >Hi! > >Mark Wai; it is your name. >you write it as 'Mark Wai' >not 'MARK WAI' >nor 'mArk wai' >why? >If you think it is the same... consider to change YOUR Smalltalk... How do you know I prefer my name to write as 'Mark Wai' and not 'Mark WAI'? Do you know the name ordering rule in Chinese name? (see below section) What should I do if my friend writes me a letter but print my name in the envelope as 'MARK WAI'? Should I ignore my friend until they print my name correctly and throw the letter in the garbage can because I cannot recognize my own name? What should the post office do if the country is printed all lower case like usa instead of USA? Should the post office send it to a country called usa? Where is usa? Oh my, I am now regretting that I started this thread. I am also very disappointed to myself that I did not get my question stated clearly because 9 out of 10 people misunderstand and misinterpret my point. I would stop now so that messages won't flooded to everybody mailbox. I apologize for creating so many messages. I should have just quietly changed my own Smalltalk to do what I think is right (in fact I did just that). But before I leave, I want to try my best and clarify for the last time: 1) I am interested to know from the design and/or implementation point of view, why Smalltalk method lookup has to be case sensitive and why the compiler will store case sensitive selectors. 2) Point number one has nothing to do with writing all lower or upper case method name. The programmer will still have the freedom to choose any case, whether it be upper, lower or mixed case. Again, my question has nothing, NOTHING, nothing, NOTHING to do with suggesting to write all lower or upper case method. NO NO NO NO NO. Symbolic based language like Japanese or Chinese, unlike English, does not have the concept of case and therefore, case related ambiguity would not exist. When I write my name in Chinese, there is only *one* and only *one* way to write it. But as you use my name in your above example, there could be 2^7 = 128 ways of writing it with different casing in English for a simple 7 letter name. BTW, in any important forms that requires me to print my name, I always print Mark WAI instead of Mark Wai because I want to emphasis that my last name is WAI, not Mark since Chinese writes last name first instead of first name and sometimes western people confuse with that and end up putting our last name as first name and our first name as last name in their record. Quite a few of us have adopted printing our last name in all upper case to avoid confusion. So you see, there are exceptions, and these exceptions, in my opinion, should not make the same thing means differently. These exceptions are purely cosmetic, personal perference, typo mistake and for readibility reasons. If you were to build a simple GUI application that takes customer name as input, would you ask the customer exactly for each letter of their name, what case do they pefer? Or you simply use your common sense and type it? Could you make typo mistake? Could you make wrong common sense that the customer otherwise would not prefer? In any case, when you try to retrieve the customer name from the database in the future, would you match the name based on case sensitive or you would convert the comparing strings to all upper or lower case first? If you insist on case senstive searching and if you make a typo mistake the first time, are you going to create another customer record with the "correct" casing but ignoring the fact that you are in fact creating two *same* customer? (BTW, most systems that I have seen will convert the inputted name string to uppercase before storing to the database regardless how it was typed in the text widget) Similar to this example, what I was trying to bring up was the underling storing and retrieving mechanism of Smalltalk method, not the visual effect. Ok, thanks for those who provided me comments on performance aspect consideration. This confirm my thinking that performance was *not* the reason or at the very least, not the contributing factor, well, if this issue have ever considered.. Thanks. >Smalltalk evolve with every user. :-) >People write names always in the same manner (when they want to say the same). > >why to work to have less? (work to be case in-sensitive) :-) > >I want to mention some points I consider when writing Smalltalk sentences. >When I write text in a workspace, I am outside of any context, in the ether. >But when writing a method for anObject I am "the object" (the receiver) and writes upon its point of view. >anObject can name a Global object, it is outside itself and this object must be named in loud voice (then I write it's name in upperCase). >If anObject needs a part of it. This part is immediate to it and can be named in lowercase. As the part is inside itself another object can't name it. >When an object must name itself or an object known universally (Universal Concept) it can name it in lowercase because this concepts are known anywhere (like self, nil, true, false, 1, 10, $a, ...) > >And... what about message names? >When we write a sentence we begin with uppercase and then continue with lowercase upTo: $. :-) >In the case of OOP the first word is the receiver's name and it casing is governed by the preceding rules... >Then is normal that all the remaining messages will be in lowercase. > >Writing messages in UpperCase is like speaking in loud voice! :-) >And if you write messages like #ASUPPERCASE many people will be irritated. :^) > >Hope this helps. >Ale. > >Alejandro F. Reimondo >Feel free to visit Smalltalk User Group of Argentina (SUGAR) >at http://www.sugarWeb.com > >Attachment Converted: c:\internet\eudora\attach\RE Smalltalk Design Question > -- Mark Wai Frontier Systems Architecture Inc. mailto: mwai(a)ibm.net or:[ mwai(a)frontiersa.com] __

1 0

Re: multithreading support
by sqrmax＠cvtci.com.ar 29 Jan '98

29 Jan '98

Hi. >I am starting prototyping effort of add native multi-threading support >to Squeak. Any suggestions, hints, advice would be appreciated. Just a few days ago I started thinking about the same thing. For me, the main reason behind this is that I have a 2 processor computer. And if I had access to an n processor machine, and if I was able to run Squeak on it, I would like to take advantage of parallel processing. First of all, I targeted the virtual machine for making it able to run on multiple processors at once. I thought that the virtual machine was some kind of cpu I already knew, like the i80386++, the 68xxx and so on. So, as I knew all those, I concluded that I could use the same tricks the guys at Intel and Motorola came up with to improve performance on their processors, but now on the virtual machine. I thought it would be nice to implement the following things: vm1) To split the virtual machine into synchronized core parts. The first two parts I thought of were the fetch-execution thing. If one process was dedicated to look ahead for byte codes, while another one actually executed them, things would go faster (twice, like). This is exactly what the Intel guys did on the 80486 and then on all the pentiums. They gave it a different name, like Branch Prediction Buffer or so. They guess what will a jump instruction do, and tell the prefetch queue to fill itself as if the jump instruction had been executed in the predicted way. Here the picture becomes clearer. Because usually the time consuming instructions are message sends. So, just by keeping track of the methods that could be executed before the virtual machine asks for them will improve performance. vm2) To optimize the instruction set. This is a rather under development idea. The fetcher could as well translate the byte codes into some other representation that allowed faster execution (like actual native code, for instance). I don't know much about byte codes, but from what I've seen on compiled methods, pushes, pops and returns tend to occur in almost every method. We could gain extra performance if we made the virtual machine superscalar as well. To allow for that, we could take a look at the independence of consecutive byte codes, and if independent, execute them both at the same time through instruction pipelines (real machine threads). This is done on all Pentiums and also a lot of other chips. It would be great to find a way of deciding if two consecutive message sends are independent of each other or not. vm3) Split the virtual machine responsibility into a kind of virtual chipset stuff, consisting of a virtual cpu, a virtual bitblter, a virtual port manager and so on. For instance, we could decouple screen generation from what the virtual cpu is actually doing. The same goes with sound, communication and so. Some kind of separate memory image spaces and a kind of bus could be the thing to do. This was done on the Amiga. For all of you that used one, do you remember what the XT was with a similarly fast cpu? The difference was in the custom chips that released the cpu from doing heavy stuff as bitblitting, sound mixing and screen updating. Especially now, when screen updating can be so time consuming. To allow this, the Amiga used the 68000 cpu family from Motorola. Those cpus are very interesting, because besides twin data-instruction buses, orthogonal instruction set and a lot of registers they allowed asynchronous port management. That is, the cpu instructs the serial port to send a byte and continues executing instructions regardless of what the serial port is now doing. This doesn't happen on all chips. Hint: this allows building a real Smalltalk virtual machine, putting each virtual cpu on silicon. Crazy? 1) How would it be possible that several virtual cpus executed byte codes at the same time? Through something similar to Visual Smalltalk's SLLs? Maybe it's quite close to what an SLL is. Unmovable blocks of ram would be advisable for all this. For instance, for screen generation we could copy the AGP idea on new Intel motherboards. Their idea was to remove the video memory from the video card and use some kind of fast/chip ram like what the Amiga does (and did since who knows when). This is, memory for programs and data, and memory for screen, sound samples and so on. Considerable speedups could develop from this, because we would be splitting the tasks of the virtual machine into virtual cpus that execute specific byte codes designed just to do their task. This allows for independence of implementation, and also organizes primitives were they belong. Primitives for video only implemented in the video generating virtual cpu. Primitives for communications only implemented in the communication virtual cpu, and so on. This also allows flexible optimization over the hardware that is running the virtual cpus. Furthermore, every of those virtual cpus would be able to execute in parallel with all the others (except perhaps multiple "general purpose" virtual machines). What about a multiprocessor version of the GC? Execution speed can be improved if we let n virtual processors replace object pointers simultaneously on the image, provided that there is more than 1 real cpu working. But I think this can be avoided. If a virtual cpu checks what objects are linked to the new objects in the new object pool (this can be done by tracking other VMs, or by making the VMs tell this special cpu when they make something point to a new object), when the GC trigger comes a list of just what needs to be changed could be already prepared. This is more or less what I had thought about. I just love it when manufacturers tell you just a few words on how they improved speed and paint it as complicated as hell, when in fact those lines let you rethink the problem and arrive to the same conclusions on your own. This happens all the time with Intel, for instance. It's also quite astonishing to verify that there are not a lot of those ideas, and that they are not used all at once because if so, they would not make as much money as they do now... Andres.

1 0

Transcendental Numbers
by Travis Griggs 29 Jan '98

29 Jan '98

Coming from a background of hardcore number crunching programming (nuclear simulators and the type), I remember that one of my favorite mental hard ons for Smalltalk was the transcendental number system. Many modern "static system" compilers will also infer a good bit when noting mixed type math and put in implicit casts. But what has always even thrilled me more about ST is the ability to define new number systems and intermix them with the standard numeric types as appropriate. In preparation to adding a new "numeric type o thingie" I got looking at how Squeak handles mixed math. To begin with, I didn't like it, it being like the OW coercion stuff, and I being more familiar with double dispatching as implemented in VW or ST\X. So I rewrote the basic arithmetic operations (+, - , / , *) to use double dispatching. After having done this, I find myself at a crossroads of how to proceed. I've discovered that doing the double dispatching thing also has its drawbacks. Namely the number of methods required. For every new type of numeric thing one wants to add to the system, the number of required DD messages is 4(n^2). Whereas with using coercion, the number of type coercion messages is n^2. The drawback with coercion is that intermediate objects are created to complete the operation. With the simple mathematic types (Float, Integer) this is inevitable - sooner or later, you've got to get a float version of your integer. But with other "heavier" numeric types, these can be avoided by using DD. Take simple numbers combined with Points for example. To add a number to a point, you send asPoint to it, which creates a point to be soon thrown out. If you use DD though, you can avoid this creation by implementing something like: sumFromInteger: anInteger ^anInteger + x @ (anInteger + y) For points, the overhead isn't too bad, but as the new numeric types, get "heavier" you end up having to create special "intermediate" objects. VW SomeNumber is a good example of this. I've completed the DD stuff, and was about ready to put it up at the archive, but then I stumbled upon this dilemma. Did the squeak team choose coercion over DD on purpose, or is this a historical hold over? Thoughts? More methods vs. more intermediate object creation? -- Travis Griggs Key Technology tgriggs(a)keyww.com GO SMALLTALK - AND BEYOND!

1 0

RE: Smalltalk Design Question
by Alejandro F. Reimondo 29 Jan '98

29 Jan '98

Hi! Mark Wai; it is your name. you write it as 'Mark Wai' not 'MARK WAI' nor 'mArk wai' why? If you think it is the same... consider to change YOUR Smalltalk... Smalltalk evolve with every user. :-) People write names always in the same manner (when they want to say the same). why to work to have less? (work to be case in-sensitive) :-) I want to mention some points I consider when writing Smalltalk sentences. When I write text in a workspace, I am outside of any context, in the ether. But when writing a method for anObject I am "the object" (the receiver) and writes upon its point of view. anObject can name a Global object, it is outside itself and this object must be named in loud voice (then I write it's name in upperCase). If anObject needs a part of it. This part is immediate to it and can be named in lowercase. As the part is inside itself another object can't name it. When an object must name itself or an object known universally (Universal Concept) it can name it in lowercase because this concepts are known anywhere (like self, nil, true, false, 1, 10, $a, ...) And... what about message names? When we write a sentence we begin with uppercase and then continue with lowercase upTo: $. :-) In the case of OOP the first word is the receiver's name and it casing is governed by the preceding rules... Then is normal that all the remaining messages will be in lowercase. Writing messages in UpperCase is like speaking in loud voice! :-) And if you write messages like #ASUPPERCASE many people will be irritated. :^) Hope this helps. Ale. Alejandro F. Reimondo Feel free to visit Smalltalk User Group of Argentina (SUGAR) at http://www.sugarWeb.com

2 1

← Newer
1
2
3
4
5
6
7
...
20
Older →

Jump to page: