Squeak-dev February 1999

squeak-dev@lists.squeakfoundation.org

148 participants
356 discussions

[Enhancement] to Browser (addition of '** all **' and 'reclassi fy...')
by Norton, Chris 25 Feb '99

25 Feb '99

Hi Folks! Carl Gundel and I have come up with a nifty little enhancement to the Squeak system browser. Here's a portion of the ChangeSet preamble that describes our enhancements: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change Set: Browser ENH Classify Date: 24 February 1999 Author: Chris Norton & Carl Gundel This change set includes the following feature enhancements to the Browser: 1. Addition of a virtual '** all **' message category 2. Addition of an automatic '** unclassified ** category 3. Addition of a new browser feature for message pane: 'reclassify...' NOTE: These features were inspired to some degree by ParcPlace/Digitalk's VisualSmalltalk Enterprise (TM) Package Browser. We really like some of the behavior in that browser, so we borrowed some of their good ideas. We just want to make sure we have given credit where credit is due! :-) [ truncated the detailed description of the changes ] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We think this enhancement will improve the usability of the browser(s). I know that we use all three parts of the enhancement regularly. We hope you enjoy it! ---==> Chris Norton and Carl Gundel PS> If you folks like the feature, perhaps someone at "Squeak Central" can put it into the next release? I have not had the pleasure of submitting any new Squeak code before this, so I am not sure about the procedure one must follow to make this happen. Thanks! --> Chris <<Brow_ENH.cs>> Content-Type: application/octet-stream; name="Brow_ENH.cs" Content-Disposition: attachment; filename="Brow_ENH.cs" Attachment converted: Anon:Brow_ENH.cs (????/----) (000072BE)

1 0

Re: Problem report from Mark G.
by Dan Ingalls 25 Feb '99

25 Feb '99

Mark Guzdial <guzdial(a)cc.gatech.edu> wrote (to PWS interest)... >>Is anyone else running a Squeak 2.2 image on a 2.3 VM for a PWS? I decided >>to try it -- I didn't want to try to reconfigure a new image yet, but I >>wanted to get the speed boost of the 2.3 VM. >> >>It died immediately with a weird subscript error. It took some hunting to >>find that the curly brace construct that Georg uses that I borrowed (see >>"{header . query}" at the bottom of PWS>>readRequest:) was choking under >>the 2.3 VM. I replaced with Array with:with: and it all works well. The >>weird part is that the same code still exists in the 2.3 VM and STILL >>WORKS! Weird... Yes, your same PWS code works in 2.3, but the underlying code where you found the "weird subscript error" is different. Versions earlier than 2.3 final access to fields above the stack pointer of contexts. This is OK in VMs 2.2 and earlier, but it's a no-no in 2.3 and later. These, um, archaisms occur in ContextPart>>pop, pop: and push:, and were, um, modernized in CS 460RealStackPtr-di.cs. These methods are only used by the stepping simulator (debugger step command) and by the brace construct. It's likely that filing in just those methods from that changeSet would make a 2.2 image completely happy with the 2.3 interpreter. - Dan

1 0

Re: Building Squeak for Solaris 5.6 [was: Re: Need help building 2.3 VM.]
by R. A. Harmon 25 Feb '99

25 Feb '99

At 06:49 PM 2/23/99 -0500, Bill Cattey wrote: >Information! > >The Squeak 2.3 VM builds fine under: > gcc version egcs-2.91.57 19980901 (egcs-1.1 release) >but does not build correctly under > gcc version 2.8.1 [snip] There seems to be a great deal of difficulty in building the VM for various configurations. The UNIX applications I ported to DOS invariably had a readme (or config.txt?) file with a whole list of configurations supported, and asked anyone who built a new one to add to the list. Is there a similar approach to the VM build for Squeak available in one place? I seem to remember seeing something about a learn or teach utility that helped to build the makefile or something. I think a lot of UNIX utilities are available in Windows equivalents. Anybody know what the utility was? -- Richard A. Harmon "The only good zombie is a dead zombie" harmonra(a)webname.com E. G. McCarthy

3 2

Vortex
by Markus Kohler 25 Feb '99

25 Feb '99

Hi all, Anyone here that has experience with Vortex (http://www.cs.washington.edu/research/projects/cecil/www/Release/index.html) ? It's a compiler framework that supports Cecil,Java,C++ and Smalltalk. They have a frontend for Visualworks, and I'm wondering what it does and if it really produces code that is faster than Visualworks. Markus -- Markus Kohler mailto:markus_kohler@hp.com

1 0

Announcing http://www.smalltalk.org
by Peter William Lount 25 Feb '99

25 Feb '99

Hi Fellow Squeakers, I am pleased to announce that http://www.smalltalk.org is up and running with a simple web page. We are setting up the site to become a primary entry into the virtual world of Smalltalk. We are planning to have a comprehensive and massive collections of links to Smalltalk resources on and off the net. Please send us links to relevant Smalltalk and Object technology materials at links(a)smalltalk.org or visit http://www.smalltalk.org and enter them into Monty's editable Smalltalk links page. Please link to us from your web sites. We are also seeking ideas(a)smalltalk.org and suggestions(a)smalltalk.org for the site. Please contribute. We are planning to put Smalltalk behind the website and implement some cool apps. Enjoy. All the best, Peter William Lount peter(a)smalltalk.org "www.smalltalk.org" and "smalltalk.org" are trademarks of Peter William Lount.

1 0

Re: Optimizing Squeak
by Helge Horch 25 Feb '99

25 Feb '99

At 14:09 24.02.99 -0800, John wrote: >Note that part of Smalltalk/V's impressive speed for a simple interpreter was >based on a carefully designed bytecode set. I've never been able to find out >much about this bytecode set. Don't. Make. Me. Fire. Up. V/DOS. I used to know someone who had too much time on his hands in 1988. So I don't think that the bytecode set was *so* unusual. It might have amounted to the following: 1.) push opcodes: 0, 1, byteOop, wordOop, nil, false, true, receiver, 5 fixed stack offsets, byte-indexed stack offset, symbol, ivar 1 to 4, ivar byte-indexed, literalReference, Block with 0/1/byte #args and skip, selector; 2.) pop opcodes: 2 fixed stack offsets, byte-indexed stack offset, ivar 1-2, ivar byte-indexed, stack byte-indexed, literalReference; 3.) sends: value, value:, x, y, +, -, ==, <, <=, >, =, //, \\, bitAnd:, bitShift:, @, anySelector with 0/1/2/n args, sendToSuper; 4.) jumps: on false/true/unconditional, respective offsets byte+0/16r100/16r200/16r300; 5.) misc: drop, dup, ret tos, ret receiver. I was told that the a86 code was impressive, bytecodes not being indexed but direct offsets into code. No, it was in a different country. And besides, the wench is dead. >which would explain why they hid the compiler classes from the user. Thanks, Dejanews: http://www.dejanews.com/getdoc.xp?AN=185791543 In other words, sometime in 1996 Eric Clayberg revealed the secret behind the classes with the funny names. SCNR, Helge P.S. Anyone wanting to part with his copy of METHODS or Widgets/V-Mac?

1 0

Re: Optimizing Squeak
by ted creedon 25 Feb '99

25 Feb '99

1 0

RE: Optimizing Squeak
by George Bosworth 25 Feb '99

25 Feb '99

<johnm(a)wdi.disney.com> wrote: >Note that part of Smalltalk/V's impressive speed for a simple interpreter was >based on a carefully designed bytecode set. I've never been able to find out >much about this bytecode set. It may be that Digitalk considered it trade secret, >which would explain why they hid the compiler classes from the user. John, Smalltalk/V (actually Methods since it predates Smalltalk/V and shares the same engine) did two things 1.) the byte codes were carefully picked to match the 8088 and were relatively few in number. 2.) The byte codes were the byte offset from the table base address directly rather than an index into a jump table, i.e. the byte codes were implemented in-line in the table (hence the need for a small number of bytecodes). This meant that a byte code dispatch was reduced to loading a byte into AL and then doing a JMP AX+tablebase. Sort of a direct threaded code scheme, but done in byte, that was tuned to the specifics of the 8088 instruction set (what a nightmare) ---george bosworth

1 0

Coding
by Andres Valloud 25 Feb '99

25 Feb '99

Hi. I've implemented arithmetic coding together with finite state and context models. Currently it's ok with rational arithmetic (S*L*O*W) and still buggy with floating point arithmetic. I'm taking a rest from it since I spent about a year with it, getting about 3+k bytes/sec with floating point arithmetic (still buggy, but the complexity doesn't change with it). No integer arithmetic neither blending models yet. Anyway, I found a lot of material in a book titled Text Compression that stresses the idea of this model for data compression. 1. A coder that knows how to encode and decode the results of 2. A probabilistic model that gives probabilities telling how probable are the events possible. This model has resulted an EXCELLENT idea, although it was meant for C language. It's a model codecs in Squeak don't follow, I guess for execution speed reasons. But nevertheless I'd like to tell briefly how the splitting of the model and the coder turns out to be a good idea. All compression schemes have two main components. They're the model and the coder. The last one has to write a stream of symbols based on what the first predicts about something that actually happens. With this vague idea in mind, let's see what happens. There's a finite amount of states that can happen at any given time, like one value of a byte, more than 110v in the electrical line, whatever. And there's a *finite* amount, it's very important for this that the amount of states is finite and determined before start. The sequence of finite amount of states that can happen one at a time, at any given time, will be our source; while the state list will be our alphabet. The whole idea of compression is to describe our source in terms of an alphabet, in a sequence of shorter length than the source which we will call the destination. We're assuming for the moment that the I/O alphabets are the same (or at least isomorphic somehow). Roughly speaking, ad hoc techniques are not a good idea when compression in the general case is to be achieved, because they only work in a very specific environment. Adaptive schemes are a must. The whole idea is that there's a model that is fed all the events that have already happened, and based on this predicts with a certain probability the occurrence of any of the symbols (states) of the alphabet. How the model comes up with the prediction is not important, the thing is that we're fed with predictions. These predictions (probability of the symbol that actually happened) are subsequently sent to the coder, that somehow writes enough information about what happened to be able to decode it later. How this is done is a matter of the coder, and it doesn't care about the procedence of the predictions. Examples! Examples! Huffman coding, roughly speaking. The probabilities are given by the frequencies of the symbols, that update a frequency tree. The coder chooses a certain bit sequence for each of the symbols that actually happen. This is an example that's quite illustrative, since Huffman coding is thought to be a single thing process most of the time. LZ, token replacement in general. The model says when in the past have the sequences happened and the coder writes tokens referring to previous repeated sequences. LZ, dictionary based in general. This is tantamount to alphabet translation. The model keeps the new alphabet and the coder writes symbols in the new alphabet instead. Probabilistic model driving an arithmetic coder. Writes bits corresponding to probabilities supplied by the probabilistic model. The beauty of all this is that when done properly one just implements coders and then uses them with various models without both sides knowing what's going on. Any comments? Andres.

1 0

RE: getting started
by Raab, Andreas 25 Feb '99

25 Feb '99

> Isn't one of the goals of Squeak Central to be able to create animated > games with Morphic? Seems to me that the fastest cpu available wouldn't be > too fast. > I entirely disagree - you can make fast running games from Morphic since there are basically two things to minimize: a) The overhead of traversing huge morphic hierarchies (easy to do in a game - just cache your guys) b) Minimizing overdraw (again, easy to do if you know the particular type of game) We're currently not doing an extremely good job on both parts since Morphic is designed to be general and not just another game API - but as a matter of fact, simple *drawing* in Morphic is not at all slower than in MVC. The difference in the speed you *feel* when using Morphic vs. MVC comes basically from three points: a) Using 1 bit deep bitmap caches in MVC for windows in the background b) The pretty long turnaround cycle for the interaction loop (e.g., HandMorph>>processEvents) c) The interactivity pause (20 msecs in Morphic vs. 10 msecs in MVC) In a game, you usually don't have multiple windows so point a) doesn't count. For point c) you can simply turn off the interactivity pause (nobody expects a game to leave some processor cycles for other apps ;-) and while there is no such easy solution for b) I found that in itself this doesn't hurt that much. Andreas -- PLEASE NOTE NEW EMAIL ADRESS! +===== Andreas Raab ========= (andreasr(a)wdi.disney.com) ==+ | Walt Disney Imagineering Phone: +1 818 544 5016 I I Glendale, CA Fax: +1 818 544 4544 I +======< http://isgwww.cs.uni-magdeburg.de/~raab >========+

1 0

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

Jump to page: