Squeak-dev June 2000

squeak-dev@lists.squeakfoundation.org

134 participants
686 discussions

RE: A new default look for Squeak, revisited
by Pennell, David 03 Jul '00

03 Jul '00

Me too. I like the window titles a lot. -david -----Original Message----- From: Tim Rowledge To: squeak(a)cs.uiuc.edu Sent: 6/29/00 4:45 PM Subject: Re: A new default look for Squeak, revisited This I like; simple (possibly a bit less of the translucency, hmm?) clean and your fonts stuff is looking good. Gimme! -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: SD: Self Destruct

6 12

Re: Better solution [was: Re: [BUG][Linux] VM2.8 port eats processorcycles]
by Stephan Rudlof 02 Jul '00

02 Jul '00

"David T. Lewis" wrote: > > On Thu, Jun 29, 2000 at 10:15:28PM +0200, Bert Freudenberg wrote: > > On Thu, 29 Jun 2000, Tim Rowledge wrote: > > > > > > nanosleep(&sleepTime, &reminderTime); > > > Excellent - do you know if it actually portable to most unices, or is it > > > likely to be a hit and miss affair? > > > > It's a POSIX standard function. I checked (the manpages) on Irix and > > SunOS. For Suns, it seems you have to link with libposix4 though ... > > > > -- Bert > > > It will be somewhat hit and miss. > For example, BDSI does not seem to have it. > > bash-2.02$ uname > BSD/OS > bash-2.02$ man nanosleep > man: no entry for nanosleep in the manual. Raivis Bucis wrote: > > : On Fri, 30 Jun 2000, David T. Lewis wrote: > : > : Maybe in BSD there is some other short sleep than usleep? > > Yes. Look at select or poll (without any descriptor). > > Raivis Hmm, select() seems to be the gcd of all platforms. Probably we should use this instead of nanosleep(). But what is the better variant: To force to initialize the Socket module, which leads to indirectly calling select(), or to call it directly in ioRelinquishProcessorForMicroseconds(int microSeconds)? I prefer the latter, because the Socket module could be nonexistent. But we have to handle the case where microSeconds are 0, because select() could block then (this is errorneous in my previous nanosecond() proposal, too). Other opinions? Greetings, Stephan >From the man page: SELECT(2) Linux Programmer's Manual SELECT(2) NAME select, FD_CLR, FD_ISSET, FD_SET, FD_ZERO - synchronous I/O multiplexing SYNOPSIS #include <sys/time.h> #include <sys/types.h> #include <unistd.h> int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); FD_CLR(int fd, fd_set *set); FD_ISSET(int fd, fd_set *set); FD_SET(int fd, fd_set *set); FD_ZERO(fd_set *set); DESCRIPTION select waits for a number of file descriptors to change status. ... NOTES Some code calls select with all three sets empty, n zero, and a non-null timeout as a fairly portable way to sleep with subsecond precision. ... -- 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

2 2

A new default look for Squeak, revisited
by Henrik Gedenryd 02 Jul '00

02 Jul '00

A few days ago there was a call for us to come up with suggestions for a new defult look. For what it's worth, in the absence of others, I've included a couple of pictures of the look I have put together myself when I've been bored with my 'real' job, mostly to play around with translucency. There is not really any conscious design behind this, except to keep it simple, I guess. I don't like things that are flashy at first but become too much in the long run. I've included two images here that I've tried to keep small. One puts together most of the look's elements in a small space, so it looks rather messy to get it all into a small space. (And yes, it shows the general problem with tranlucency as well.) The other, really tiny one, shows what the 'window resizing dot' looks like, here I have placed the arrow on the line between two panes in a browser. (The dot is normally yellow.) I did it as an experiment with translucent gradients. I've placed a bigger, less cramped image on the web, which should give a better impression of what it actually looks like to work with (220k): http://www.lucs.lu.se/people/Henrik.Gedenryd/Squeak/bigedit.jpg A second one looks pretty much the same, but with more menus to illustrate how well the translucency works for text on text: http://www.lucs.lu.se/people/Henrik.Gedenryd/Squeak/largewmenu.jpg Speaking in general (and I'm not sure my ad hoc toying around is a good example of this), I think an interface should exploit the unique capabilities of Squeak, and not try to imitate something else (and imitations are only either bad, or at best similar to the original, which isn't very exciting anyway). Perhaps the translucency (& when combined with gradients) are examples of this. Oh, yeah, morphs & windows should be translucent when dragged--but I haven't quite figured the best way to do that yet. To digress a little, to improve also the quality (and not merely apply lipstick), Squeak should become more object- and less window/widget-oriented also in the interface, towards Direct Manipulation. Eg. today's menus are mostly merely lightly glorified typed commands--and in some confused arrangement, (help menu->preferences, projects in at lest 3 places, etc.) For instance, instead of a change set browser (two in fact) where you can see the sets, there should be change set morphs that _are_ the sets, and so on. But back to the issue at hand. If people would like this included in the distribution, I'll package it up as a change set. (It's quite simple in fact, to 95% some changed color parameters in various places.) The font is the only thing that can't be expected to work generally (yet), and (as usual) it is intended for LCD screens anyway. I can browse the X11 fonts et al and see what I find. Secondly, the window titles are an unrelated feature, which I nevertheless can include. They merely describe what's in the window (good when it's collapsed or partially covered) instead of writing "System Browser" etc. in five places on the screen. If you want that, I can include it as well. (I'll leave the close box on the left as well, it just ended up on the right at one point). Henrik

2 3

[VM] SourceForge status
by Stephan Rudlof 02 Jul '00

02 Jul '00

VM-Hackers, what is the status of your SourceForge efforts? I have looked into http://sourceforge.net/projects/squeak/ and it seems to be *empty*. I have just made an improvement (not tested yet) for Tim's VM2.8 Linux port and would like to have the ability to - see the versions of other platforms, - post it there (after some testing, of course)... When do you think there is a first source tree? Who is/feels responsible to start with it? Possibly Tim's port would be a good start... Greetings, Stephan -- 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

4 4

[ENH] String splitting
by FWr＠phaidros.com 01 Jul '00

01 Jul '00

Hi folks, I just looked for a method to split a string at all occurences of a given character. Unfortunately I couldn't find a method for this problem. So I wrote one myself. Maybe it will be of interest for others. Frank Frank Winkler Phaidros Software AG 03677 677 9286 privat Tel. 03677 206615, 0170 821 7624 Java, the best argument for Smalltalk since C++.

4 3

RE: [Q] Using FFI to call standard Windows dialogs
by Torsten.Bergmann＠phaidros.com 01 Jul '00

01 Jul '00

Ohhh no - you try to call the API with a window handle as a parameter, but the the API is defined like the following: BOOL PrintDlg( LPPRINTDLG lppd // initialization data ); So you have to call it with the address of a PRINTDLG structure. This structure contains informations used to initialize the dialog box (including the handle to the owner window). See http://www.msdn.microsoft.com/library/default.asp?URL=/library/psdk/winui/co mmdlg3_7xwy.htm How to do it in Squeak: - create a new subclass Win32PRINTDLG of ExternalStructure - implement the class method #fields to define the fields of the struct like: Win32PRINTDLG(class)>>fields "Win32PRINTDLG defineFields" ^#( #(#lStructSize 'long') #(#hwndOwner 'long') ... ) see http://www.msdn.microsoft.com/library/default.asp?URL=/library/psdk/winui/co mmdlg3_7xwy.htm for the structure definition (note that any structure member is a long (4 bytes), except nFromPage, nToPage, nMinPage, nMaxPage, nCopies (only two bytes) - evaluate "Win32PRINTDLG defineFields" to create accessor methods on the instance side - create an API call method shellPrintDialog: aWin32PRINTDLG "Displays a print dialog box" <apicall: bool 'PrintDlgA' (Win32PRINTDLG*) module: 'comdlg32.dll'> ^self externalCallFailed This should work. If the API call goes wrong it returns FALSE (= 0). I personally dont like the way Squeak calls API functions. In Smalltalk MT you only write: WINAPI PrintDlg: PRINTDLG new That's a little bit easier ;) Hope this helps Torsten BTW: It's interesting that you mail address is Kronos.com - my nickname is Cronos -----Original Message----- From: Norton, Chris [mailto:chrisn@Kronos.com] Sent: Freitag, 30. Juni 2000 04:26 To: Squeak (E-mail) Subject: [Q] Using FFI to call standard Windows dialogs Hi Folks. I was experimenting with FFI on my Windows NT box and I kept crashing my image (virtual memory dumps). Can anybody help me with this call? ~~~~~~~~~~~~~~~~~~~~~~~~~~ Win32Shell>> shellPrintDialog: aHWND "Win32Shell new shellPrintDialog: Win32Window getFocus" <apicall: bool 'PrintDlgA' (Win32Window) module: 'comdlg32.dll'> ^self externalCallFailed ~~~~~~~~~~~~~~~~~~~~~~~~~~ I'm trying to launch the print dialog. Thanks for your thoughts! ---==> Chris PS> And my next question is, of course, how do I get a document to print once I've got the dialog launching from Squeak (e.g. how do I provide the dialog with a document to print?)...

3 2

Breaking from a do-loop???
by jchludzinski＠worldkey.net 01 Jul '00

01 Jul '00

I'm writing some numerical code and need to know: How would I accomplish a "break" (a la 'C') from a ST do-loop? Use an exception? ---John

3 2

Re: Belling the cat of complexity (was: Ship it with Squeak)
by john.g.gardner＠ca.pwcglobal.com 30 Jun '00

30 Jun '00

Hi Tim, Thanks for your reply. However, I believe that my point #2 and #3 still refer to different aspects of tailoring the Squeak environment. #2 refers to building up the Squeak image for a specific set of requirements, such as creating a development image for creating text processing programs versus a development environment for creating a full-blown GUI program. #3 refers to creating a production image, irrespective of the type of development image one created. The requirement here is to strip out all classes and methods that are not specifically called by the program (same functionality as C++ compilers). This process includes stripping out the all of the development tools. The stripping process may remove only parts of modular plugins or categories as well as entire subsystems. The goal is to create a "runtime" image for the user. Thanks, John. Tim Rowledge <tim(a)sumeru.stanford.edu> on 06/30/2000 01:43:01 PM Please respond to squeak(a)cs.uiuc.edu To: squeak(a)cs.uiuc.edu cc: Subject: Re: Belling the cat of complexity (was: Ship it with Squeak) > 2. A modular Squeak, built up from a core functionality using images or plugins. > > 3. A packaging utility which strips unnecessary classes from the distribution > and wraps some installation functionality around a shipping product. Purely in a spirit of minor nitpicking in order to try to keep things simple, I must point out that a decent solution to 2) makes 3) unneccessary. -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- During evolution his ancestors were in the control group. ---------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

6 5

Re: Testing Celeste
by Bob Arning 30 Jun '00

30 Jun '00

On Fri, 30 Jun 2000 10:17:29 -0700 Alan Kay <Alan.Kay(a)disney.com> wrote: >P.S. I haven't seen the <thorn> notation before today ....... There is an interesting bi-directional translating feature in Squeak these days. Having acquired mappings for iso characters, a number of them map to $? (I guess because we lack an equivalent). The side effect of this is that '?' asHtml once upon a time was ---> '?' but now it comes back as ---> 'þ' which may cause interesting glitches in non-Squeakified recipients. Below is a list of html entities that map to characters in the first 128 positions. Some are obviously correct and necessary, but perhaps we should do something special for those that map to $?. Cheers, Bob 'thorn' $? 63 'quot' $" 34 'curren' $? 63 'gt' $> 62 'yacute' $y 121 'Yacute' $Y 89 'shy' $- 45 'amp' $& 38 'ETH' $? 63 'sup2' $2 50 'sup3' $3 51 'sup1' $1 49 'frac14' $? 63 'frac12' $? 63 'frac34' $? 63 'lt' $< 60 'eth' $? 63 'brvbar' $| 124 'THORN' $? 63 'times' $* 42

1 0

Re: Belling the cat of complexity (was: Ship it with Squeak)
by john.g.gardner＠ca.pwcglobal.com 30 Jun '00

30 Jun '00

I agree. It also looks like many people on this list agree with the following principles: 1. Squeak should be open and usable by everyone, with base class/VM changes submitted for everyone's benefit. 2. A modular Squeak, built up from a core functionality using images or plugins. 3. A packaging utility which strips unnecessary classes from the distribution and wraps some installation functionality around a shipping product. I would like to add the following principles: a) Fully documented classes. If we are taking the time to create the class/method, surely we can take a few minutes to describe its purpose. b) The ability to lock your image when you are distributing a product, to prevent reverse engineering of code. *** Please note: this is only for a production image. This does not apply to the development image and contributions made to it. c) The ability to combine the VM and the image file into one executable for shipping a product. This may help with b). d) Leveraging the "update from server" functionality as a way to update customers with new features or patches. My personal position is this: 1. I would like to see that Squeak becomes a viable tool for creating software products for sale. An open source version of Smalltalk is a powerful competitor to Java, C++ and commercial Smalltalk. 2. As open source, we would still freely contribute new functionality to the base class or VM. 3. Right now, today, I still find more functionality in public domain versions of Java/IDE than Squeak. And yet, Squeak is a better environment for development. 4. It appears that Squeak suffers from class bloat and bolt-on functionality through categories. I saw this start to happen with Java after version 1.0. My spirit is with Squeak, but my wallet is still with Java. This won't change until Squeak incorporates the changes outlined above, to become a superior language to Java, C++ and others. Thanks, John. Paul Fernhout <pdfernhout(a)kurtz-fernhout.com> on 06/29/2000 10:17:47 AM Please respond to squeak(a)cs.uiuc.edu To: squeak(a)cs.uiuc.edu cc: Subject: Belling the cat of complexity (was: Ship it with Squeak) Squeakers- There is an old story of how a bunch of mice get together and a have a long debate about what to do about the cat who they live in terror of. The cat is so quiet it can sneak up on a mouse before it knows it and devour it. After long deliberation they hit upon a great idea -- if the cat had a bell around its neck, they would all hear when it was coming and could scurry to safety in advance. The mice relax, all satisfied, until one of them asks, "Well, who is now going to bell the cat?" Squeak complexity in 2.8 has become a complex cat from the simple kitten complexity of 1.13(?) in 1996. Back then, Dan Ingalls wrote on 10 Nov 1996 those prescient words: "The Squeak team has an interest in doing the world's simplest application construction framework, but I suspect that we will get sucked up with enough other things that this won't happen in the next two months (but who knows...)." Squeak 2.8's complexity is now quiet (in terms of walkbacks) and stealthy (in terms of growing between releases without a complaint). And the complexity could be deadly. Witness the recent issue Stefan raised about some Squeak fonts possibly violating a Microsoft EULA. The question should never even arise of the legal integrity of the core release. We might as well just leap right into those jaws of complexity. I appreciate all the comments on "Ship it with Squeak". There were many, many useful suggestions and comments. I have read them all with great interest. Les Tyrrell put the issues very eloquently, and makes me realize this issue for shipping is really best put as "managing complexity in Squeak to reduce the risk of unexpected behavior in an application to an acceptable level". The complexity in Squeak comes in two areas: code issues and license issues. The complexity of the code mudball has been discussed at length. The complexity of the license issue comes up occasionally, and Stefan's point about licenses is an example. Using software without a clear "title" is like buying a house without a "title search" -- someone can always come along later and make a claim against the house. People can always make claims, the issue is that a title search (and related insurance) reduces the risk to the point to reasonable levels. I would recommend looking at the (older) Python submission guidelines for some ideas on what to ask from contributors: http://www.python.org/patches/bugrelease.html http://www.python.org/patches/wetsign.html These are basically statements of originality and disclaimers of contributor's liability. If all contributions to Squeak came with such disclaimers, the licensing concerns would be greatly reduced. The legality of contributions flows through from contributors to CNRI to official legal releases. Now that Guido has moved to the private Pythonlabs, things have changed to: http://www.python.org/patches/ and I don't know the exact status of what is signed to ensure the contributions legal. Who would replace CNRI here in the Squeak case (if anyone) is an issue. A mouse probably can't bell a cat. It's just too hard. But maybe, just maybe, a mouse could bell a kitten. I brainstormed some with Doug Flower about steps to bootstrap Squeak towards usability in business. What came out of that was a sense that a Squeak useable in many of the same areas of Perl might be a good start. He and many others who know Smalltalk have an immediate business need for such sorts of activity. Such a system would be useful if it only was able to read, write, and process text files. And enhanced version might handle sockets and other text streams. Ideally, this system would have an end-user GUI useable for setting parameters for such operations (in dialog fashion), but that is less essential since parameter files could handle this. The reason why this application area is interesting is that it is of real business need, but it does not have all the deployment issues that shipping applications does. A Squeak operating in this area can have more rough edges and still be very useful. People are already doing this with Squeak, and might see the benefit to a smaller size system they could leave with clients or carry on a floppy. So that is what I think makes a good first step towards belling the cat of complexity -- trying to first bell the kitten of file handling utility applications. How should I proceed on this? Here is one approach, although obviously it may have problems and another might be better. Think of this as a "harvesting" process. The Squeak community has generated much useful work -- the time is ripe to harvest it into a stable, legal platform. My first impulse is actually to go all the way back to the first Squeak release (or possibly the last one done at Apple if it is pure Apple code with just minor patches). Then, that version can be reintegrated with later patches that people have made, as long as the contributors are willing to agree to something like the Python disclaimers. Note, these disclaimers might be rewritten to be just general disclaimers, not specific to giving special rights to a company. The disclaimers might also put rights under a Squeak-like license, not as broad a license as Python, depending on what people on this list have to say. One reasons for going all the way back to Apple code is that frankly, I don't know what license Disney changes are really under. Unlike the GPL, the Squeak license names a company. I don't think just including the Apple license with a distribution really says anything about the licensing of your changes. I raised this issue a year or two ago on this list and don't recall getting a decent answer. That uncertainty is probably acceptable for playing around but makes business use harder to accept or promote. [Optional: Of course if one goes back that far (to the orginal release), perhaps one might ask Apple to change the license to one more like Python's so Squeak could be more easily used in embedded systems with specialized VMs. I had a problem with this in terms of legal approaval -- an awkward workaround is to use pipes to communicate from the VM to services, but ultimately the real workaround was to use Python with a less restricitive license. Python shows you don't need a draconian license to get people who want to contribute to contribute. The value to Apple is simply in making a system that helps keep the Mac on a level playing field with all other systems. Also, then Squeak would finally be compatible with GPL'd code.] Such a system would have as its first priority modularizing the image. Such an effort might include tools to assist this process, such as the wonderful effort by the 4th Estate. The effort to manage complexity would take precedence over bug fixes, GUIs, event handling, or anything else. It would also include building the image from scratch -- where every last byte was known and accounted for. Once this old Squeak was modularized, then fixes would be made purely from the standpoint of stability. These would focus primarily on stability of utility related code, and secondarily on stability of development tools. Code would need to be added to handle common text manipulations, including XML input and output. GUI changes would be a minimum needed to control file manipulation. Later, after this stable base existed, one could add all sorts of bells and whistles -- in a modular fashion. I'm sure people will say this would be a lot of work -- perhaps too much for one person. You might be right. Frankly, I still may personally decide that working in another platform instead might be easier, or might say being cross-platform has too high a cost for the rewards. In that case, putting a Squeak-like cross-platform GUI underpinning to Python might be another choice, because I can control the code I write -- I can't control what others do with their license. So it may make sense in the end to just start instead from a system with a clear legal standing and go from there adding Squeak like features. I love Smalltalk -- I'd rather make Squeak work. It is just that the effort does seem substantial. It's easy to say "just do it and it's done" when your salary and your employees' salaries are paid for with other people's money, where those deep pocketed people actually expect you to do unexpected things and trust you to accomplish them whatever it costs. It's also easy to say "just do it and it's done" when there are no legal complexities to worry about -- e.g. you're not in the risk situation where you do it and it's not done because you legally can't ship it. Also, reprising Squeak's evolution Squeak from the start would entail bothering a lot of people on the list to submit patches they already submitted, and even trying to get people making major contributions to sign some sort of actual paper document (exact form to be decided). This certainly isn't fun work for an introvert. I just don't see another way to proceed that handles issues related to the code and legal complexities of producing a minimal Squeak useable for things like XML processing or rewriting text files. There most likely needs to be a legal audit trail of the legitimacy of submissions, and that trail must be guarded by someone who would not let stuff like Microsoft fonts in no matter what the EULA says. The Squeak development process so far has been great in terms of generating code, but not so great in terms of managing complexity of that code or the surrounding legal issues. So maybe now has come the time to harvest the results of all that productive effort? And as any Object Tech Center person would say, Object harvesting is itself a time-consuming process. In summary: If we can't even get together a simple and reliable version of Squeak without a substantial GUI for text file handling which does not have substantial legal issues, then there is no hope for a version of Squeak for shipping cross-platform apps with GUIs. If a utility version of Squeak that is legally sound can be produced, it might serve to bootstrap a more substantial system which could be used to deploy applications. And, hopefully, every time complexity increased in that release, a little bell would ring and we'd know what was coming. More comments appreciated. Thanks again for those who responded to the last post. -Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com ---------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

2 1

Jump to page: