Squeak-dev November 1999

squeak-dev@lists.squeakfoundation.org

164 participants
545 discussions

[Q] Project: Better performance for LargeIntegers
by Stephan Rudlof 02 Nov '99

02 Nov '99

Agree: > > Andrew, David (thank you for the hint with the compile times) > > and Dean have > > favorized Plugins as implementation choice (for different reasons). > > > I think this is a possible variant which makes sense, too. > > But also I think > > that's not the main point: > > - it should be possible for a non C-freak just by reading sources in > > Smalltalk to get a working idea how its possible to make LargeInteger > > computations in Smalltalk > > => this is the didactic approach; > > Plugins, as various people have proposed, would be written in > Smalltalk, in Squeak. > You are right. I'm just thinking sometimes in the world of so called 'user primitives' written for a VW-image some time ago... > > - its interesting to have LargeInt arithmetics __as fast as possible__ > > without the coercion to follow the 'didactic' implementation line > > => cryptographic, maths, random generators, advertising > > (for people who > > compare Squeak with other Smalltalks); > > Plugins should have no meaningful overhead, particularly if > implemented as byteArrays. > It's the first step and possibly good enough. But I'm not so sure that ByteArrays are the end. The 'didactic' approach should be the standard implementation in the standard classes (with less changes as possible), not the eventually more tuned Plugins. And now - after these discussions - I would not remove the 'didactic' standard code for a primitive (e.g. for saving image space). The intent for me is to point out the importance of understandability of basic concepts. I don't bother about a few bytes of mem more or less (correct English?). And reading source code in plugins is possible of course and at first similar to the current implementation. But it's not a full and specialized (in style) Smalltalk and therefore a kind of indirection, isn't it? > > - then it should be as portable as possible, so don't try > > near assembler > > programming. > > Again, plugins should be highly portable. Frankly, I don't > understand Stephan's objections on any of these points. I know that plugins should be highly portable, but there were some other mails, too, and I wanted to give kind of a summarize. > > > Some personal remarks: > > I want to start this around mid of November (then I have some > > holidays, now > > I'm working for money and writing these mails ;-)). But after > > start I have > > to > > - compile Squeak first; > > Why? To become familiar with the environment. > > > - understand the plugin mechanism with a simple example, not > > 'primitive' ;-) > > example, what I first have written; > > Examples can be found in the image. There is also some doco on the Swiki. > Ok, but at least for me there is a way from - just seeing a new system, - become familiar with it, - try this and that and then - become productive. And please do not underestimate the costs - my costs, if you want - _beside_ the core problems! By the way: it's interesting to come back/forward to other paths after one year VC++6.0...

1 0

RE: [Q] Project: Better performance for LargeIntegers
by agree＠carltonfields.com 02 Nov '99

02 Nov '99

> * Space/performance tradeoff - I'd like to see what this is > before making decisions. I'm interested in both large Squeak > systems on high-end desktop machines AND tiny Squeak systems > running in my wristwatch or shirt pocket. It might well be > that the space hit is not that large and that fast > LargeInteger support on a tiny machine might be very useful, > especially if the machine lacks good floating-point support. Implemented as a Plugin, the tradeoff becomes optional for each user. You get to have the best in both worlds with the same image. (The primitive runs just as fast, except perhaps for the first call in each session, when the system opens the DLL or shared library). > * Simple implementations: I'd much prefer a very > high-performance implementation. I don't want to take a huge > hit when an integer exceeds 30 bits. IE, if it's going to be > done it would be good if the final version was extremely fast. The existing model is particularly simple, so any implementation, even if it followed the present approach, will be much, much faster. > * Optimizing special cases: There are lots of applications > where one only needs 32 or 64 bits. (See below). These cases > probably should be special. I agree. In particular, I imagine that the vast majority of bignums are created in fairly simple smallint overflow scenarios (for example, copying elements to and from a variableWordSubclass representing values larger than a SmallInteger). I note with sadness, at times, the contortions found in some image code designed solely to avoid overflow when adding or shifting SmallIntegers. It would be nice if there was an intermediate object somewhere between multiple precision and SmallInteger arithmetic that would not have a substantial cost as compared to the largeInteger work. Perhaps by using the floating-point mantissa trick for IntermediateInteger values. > * Other users of integers: For example, the random number > generator in Squeak uses floating-point to get around the 30 > bit small integer limit. Virtually all well-tested generators > are for 32 bit integers and it is a very major bit of work to > create a 30 bit generator. Dan and I found a major > performance improvement using floating-point numbers as > 'integers' when generating random numbers. If large integers > handled 32-bit integers well, then the algorithm could be > switched back, especially on small machines where > floating-point support is poor or missing.

1 0

RE: [Q] Project: Better performance for LargeIntegers
by agree＠carltonfields.com 02 Nov '99

02 Nov '99

> Andrew, David (thank you for the hint with the compile times) > and Dean have > favorized Plugins as implementation choice (for different reasons). > > I think this is a possible variant which makes sense, too. > But also I think > that's not the main point: > - it should be possible for a non C-freak just by reading sources in > Smalltalk to get a working idea how its possible to make LargeInteger > computations in Smalltalk > => this is the didactic approach; Plugins, as various people have proposed, would be written in Smalltalk, in Squeak. > - its interesting to have LargeInt arithmetics __as fast as possible__ > without the coercion to follow the 'didactic' implementation line > => cryptographic, maths, random generators, advertising > (for people who > compare Squeak with other Smalltalks); Plugins should have no meaningful overhead, particularly if implemented as byteArrays. > - then it should be as portable as possible, so don't try > near assembler > programming. Again, plugins should be highly portable. Frankly, I don't understand Stephan's objections on any of these points. > Some personal remarks: > I want to start this around mid of November (then I have some > holidays, now > I'm working for money and writing these mails ;-)). But after > start I have > to > - compile Squeak first; Why? > - understand the plugin mechanism with a simple example, not > 'primitive' ;-) > example, what I first have written; Examples can be found in the image. There is also some doco on the Swiki.

1 0

[Q] Project: Better performance for LargeIntegers
by Stephan Rudlof 01 Nov '99

01 Nov '99

Dear Squeakers, I have changed my mind a little bit after studying some Squeak sources. Now I plan to implement LargeInteger primitives (20-39) _without_ changing the representation of LargeIntegers by extending the Interpreter arithmetic primitives using the CCodeGenerator. This avoids some problems dealing with different platforms. In a later step changing the representation to bigger 'digits' (16,32,.. bits?) _could_ be interesting. What do you think? Stephan P.S.: Is [Q] the right string to get attention from Squeak Central? > -----Original Message----- > From: Stephan Rudlof [mailto:stephan.rudlof@ipk.fhg.de] > Sent: Dienstag, 26. Oktober 1999 11:24 > To: squeak > Subject: RE: Better integer performance possible? > > > Dan, Michael and others, > > > There are three reasons LargeInts are slower: > > > > It is all written in ST (no primitive support) > > The inner loops runs byte by byte > > [FYI, they were written when Squeak had 12-bit smallInts > > -- can you guess out why?] > > Squeak does not have a JIT -- yet. > > > > If I'd have the freedom to change the representation of LargeInts I would > like to implement this stuff as primitives in C. > > > We would happily invite a replacement LargeInt package into > > Squeak if it were at least as simple and understandable (I cannot > > imagine this not being the case!!), and if it did not add a > > significant overhead to the VM. > > And change some Smalltalk methods to call the new primitives. > > Timeline: Because I'm a new squeaker - but familiar with VW > Smalltalk - and > haven't change implementations of a VM - but implemented user > primitives for > VW Smalltalk - I'm planning quiet some time to become familiar with it. I > could start in the mid of November - then I will have holidays - > and I think > I could finish around christmas. > > What do you think? > > Greetings, > > Stephan Rudlof > > sr (stephan.rudlof(a)ipk.fhg.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 > > > -----Original Message----- > > From: Dan Ingalls [mailto:Dan.Ingalls@disney.com] > > Sent: Montag, 25. Oktober 1999 22:32 > > To: squeak(a)cs.uiuc.edu > > Subject: Re: Better integer performance possible? > > > > > > Stephan Rudlof <stephan.rudlof(a)ipk.fhg.de> wrote... > > > > >The integer performance of Squeak is poor compared with other > Smalltalks, > > >especially for big ints (~ factor 500) and not so much for > small ones (~ > > >factor 3). > > > > > >What's the reason? Does anybody know if improvements are possible? > > > > There are three reasons LargeInts are slower: > > > > It is all written in ST (no primitive support) > > The inner loops runs byte by byte > > [FYI, they were written when Squeak had 12-bit smallInts > > -- can you guess out why?] > > Squeak does not have a JIT -- yet. > > > > There is one reason SmallInts are slower: > > > > Squeak does not have a JIT -- yet. > > Also, in the factorial example, it may matter that > > Squeak allocates real objects for all contextx > > > > Ask Ian about Jitter -- he has been having fun with it recently. > > When he's done, I think the SmallInt comparison will be much > > better. LargeInts will be similarly better, but not like the > > Dolphin numbers. I personally have not ever found LargeInt speed > > to be a concern in any useful code. > > > > We would happily invite a replacement LargeInt package into > > Squeak if it were at least as simple and understandable (I cannot > > imagine this not being the case!!), and if it did not add a > > significant overhead to the VM. > > > > - Dan > > > > PS: I know Squeak's bytecode speed got better on Windows in a > > recent VM, so 2.6 may be somewhat faster than 2.5. > > > > >WinNT Dolphin Smalltalk Version 2.1 Patch Level 2: > > > > > >Time millisecondsToRun: [2000 factorial]. "big ints" > > > 76 75 76 > > >Time millisecondsToRun: [1000 timesRepeat: [12 factorial]]. > "small ints" > > > 11 11 10 > > > > > >WinNT Squeak 2.5: > > >Time millisecondsToRun: [2000 factorial]. "big ints" > > > 34520 34520 35080 > > >Time millisecondsToRun: [1000 timesRepeat: [12 factorial]]. > "small ints" > > > 30 30 30 > > > > > >Stephan > > > > > > > > > > > >

5 11

Off to OOPSLA
by Dan Ingalls 01 Nov '99

01 Nov '99

Folks - Most of Squeak Central is heading off to OOPSLA this week, so we're turnin' out the lights. If we don't respond, it doesn't necessarily mean we're not interested. - Dan

1 0

RE: [UPDATES] More for 2.7alpha -- enjoy
by agree＠carltonfields.com 01 Nov '99

01 Nov '99

> 1591projRevert-tkLU -- Ted Kaehler -- 31 October 1999 This is all really cool, but what does it mean? In particular, If I open a project, then a browser and changes something in an outer or sibling project, say class String, save the project, make some more changes to String, and then revert, will the second round of changes truly be undone? How will nested projects behave in this regard? What happens when I: create and edit a new class ClassA, created in project A, save project A, go to sibling project B, make changes in project B to ClassA, save project B, restore project A, and then restore project B? Thanks for all this cool stuff. It will be even neater to know how it all works.

1 0

[ENH] Click-Move-Click Menu Selection
by Bert Freudenberg 01 Nov '99

01 Nov '99

--747459867-1960201971-941482736=:10762 Content-Type: TEXT/PLAIN; charset=US-ASCII >From the Preamble: Allows click-move-click menu selection (as suggested by Kevin McGee) in addition to the down-move-up style. Enjoy! /bert --747459867-1960201971-941482736=:10762 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="clickMenu-bf.1Nove856pm.cs" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.96.991101195856.10762B(a)balloon.cs.uni-magdeburg.de> Content-Description: J0Zyb20gU3F1ZWFrMi42IG9mIDExIE9jdG9iZXIgMTk5OSBbbGF0ZXN0IHVw ZGF0ZTogIzE1NzhdIG9uIDEgTm92ZW1iZXIgMTk5OSBhdCA4OjU2OjMzIHBt JyENIkNoYW5nZSBTZXQ6CQljbGlja01lbnUtYmYNRGF0ZToJCQkxIE5vdmVt YmVyIDE5OTkNQXV0aG9yOgkJCUJlcnQgRnJldWRlbmJlcmcNDUFsbG93cyBj bGljay1tb3ZlLWNsaWNrIG1lbnUgc2VsZWN0aW9uIChhcyBzdWdnZXN0ZWQg YnkgS2V2aW4gTWNHZWUpIGluIGFkZGl0aW9uIHRvIHRoZSBkb3duLW1vdmUt dXAgc3R5bGUuIiENDQ0hSW5wdXRTZW5zb3IgbWV0aG9kc0ZvcjogJ21vdXNl JyBzdGFtcDogJ2JmIDExLzEvMTk5OSAyMDoxMichDXdhaXRCdXR0b24NCSJX YWl0IGZvciB0aGUgdXNlciB0byBwcmVzcyBhbnkgbW91c2UgYnV0dG9uIGFu ZCB0aGVuIGFuc3dlciB3aXRoIHRoZSANCWN1cnJlbnQgbG9jYXRpb24gb2Yg dGhlIGN1cnNvci4iDQ0JW3NlbGYgYW55QnV0dG9uUHJlc3NlZF0gd2hpbGVG YWxzZToNCQlbKERlbGF5IGZvck1pbGxpc2Vjb25kczogNTApIHdhaXRdLg0J XnNlbGYgY3Vyc29yUG9pbnQhICENDSFJbnB1dFNlbnNvciBtZXRob2RzRm9y OiAnbW91c2UnIHN0YW1wOiAnYmYgMTEvMS8xOTk5IDIwOjIyJyENd2FpdE5v QnV0dG9uDQkiV2FpdCBmb3IgdGhlIHVzZXIgdG8gcmVsZWFzZSBhbnkgbW91 c2UgYnV0dG9uIGFuZCB0aGVuIGFuc3dlciB3aXRoIHRoZSANCWN1cnJlbnQg bG9jYXRpb24gb2YgdGhlIGN1cnNvci4iDQ0JW3NlbGYgYW55QnV0dG9uUHJl c3NlZF0gd2hpbGVUcnVlOg0JCVsoRGVsYXkgZm9yTWlsbGlzZWNvbmRzOiA1 MCkgd2FpdF0uDQlec2VsZiBjdXJzb3JQb2ludCEgIQ0NDSFNZW51SXRlbU1v cnBoIG1ldGhvZHNGb3I6ICdldmVudHMnIHN0YW1wOiAnYmYgMTEvMS8xOTk5 IDE5OjIwJyENbW91c2VVcDogZXZ0DQkiSGFuZGxlIGEgbW91c2UgdXAgZXZl bnQuIE1lbnUgaXRlbXMgZ2V0IGFjdGl2YXRlZCB3aGVuIHRoZSBtb3VzZSBp cyBvdmVyIHRoZW0uIg0NCXwgbW91c2VJbk1lIHwNCW1vdXNlSW5NZSBfIHNl bGYgYm91bmRzSW5Xb3JsZCBjb250YWluc1BvaW50OiBldnQgY3Vyc29yUG9p bnQuDQlzZWxmIGRlc2VsZWN0SXRlbS4NCXNlbGYgaXNJbk1lbnUNCQlpZlRy dWU6DQkJCVsobW91c2VJbk1lIGFuZDogW3NlbGYgc2VsZWN0b3IgPSAjdG9n Z2xlU3RheVVwOl0pDQkJCQlpZkZhbHNlOiBbb3duZXIgZGVsZXRlSWZQb3BV cEZyb206IHNlbGYgZXZlbnQ6IGV2dF0uDQkJCXN1Yk1lbnUgaWZOaWw6DQkJ CQlbbW91c2VJbk1lIGlmVHJ1ZToNCQkJCQlbZXZ0IGhhbmQgd29ybGQgZGlz cGxheVdvcmxkLg0JCQkJCW93bmVyIGludm9rZUl0ZW06IHNlbGYgZXZlbnQ6 IGV2dF1dXQ0JCWlmRmFsc2U6ICANCQkJW3NlbGYgaW52b2tlV2l0aEV2ZW50 OiBldnRdDQkJCQ0JCQkNISAhDQ0NIU1lbnVNb3JwaCBtZXRob2RzRm9yOiAn Y29udHJvbCcgc3RhbXA6ICdiZiAxMS8xLzE5OTkgMjA6NTUnIQ1kZWxldGVJ ZlBvcFVwRnJvbTogaXRlbSBldmVudDogZXZ0DQkiUmVtb3ZlIHRoaXMgbWVu dSBmcm9tIHRoZSBzY3JlZW4gaWYgc3RheVVwIGlzIG5vdCB0cnVlLCBidXQg b25seSBpZiB0aGUgdXNlciBkaWQgbW92ZSB0aGUgbW91c2Ugc2luY2UgaW52 b2tpbmcgbWUuIFRoaXMgYWxsb3dzIGZvciBjbGljay1tb3ZlLWNsaWNrIHNl bGVjdGlvbiBzdHlsZS4iDQ0JKHN0YXlVcCBub3QgYW5kOiBbKGV2dCBjdXJz b3JQb2ludCBkaXN0OiBvcmlnaW5hbEV2ZW50IGN1cnNvclBvaW50KSA8IDJd KQ0JCWlmVHJ1ZTogW15ldnQgaGFuZCBuZXdNb3VzZUZvY3VzOiBpdGVtICJE byB0cmFja2luZyBhbmQgZGVsZXRlIG9uIG5leHQgY2xpY2siXS4NCXNlbGYg ZGVsZXRlSWZQb3BVcC4NISAhDQ0NIVBvcFVwTWVudSBtZXRob2RzRm9yOiAn YmFzaWMgY29udHJvbCBzZXF1ZW5jZScgc3RhbXA6ICdiZiAxMS8xLzE5OTkg MjA6NDQnIQ1zdGFydFVwV2l0aENhcHRpb246IGNhcHRpb25Pck5pbCBhdDog bG9jYXRpb24NCSJEaXNwbGF5IHRoZSBtZW51LCB3aXRoIGNhcHRpb24gaWYg c3VwcGxpZWQuIFdhaXQgZm9yIHRoZSBtb3VzZSBidXR0b24gdG8gZ28gZG93 biwgdGhlbiB0cmFjayB0aGUgc2VsZWN0aW9uIGFzIGxvbmcgYXMgdGhlIGJ1 dHRvbiBpcyBwcmVzc2VkLiBXaGVuIHRoZSBidXR0b24gaXMgcmVsZWFzZWQs IGFuc3dlciB0aGUgaW5kZXggb2YgdGhlIGN1cnJlbnQgc2VsZWN0aW9uLCBv ciB6ZXJvIGlmIHRoZSBtb3VzZSBpcyBub3QgcmVsZWFzZWQgb3ZlciBhbnkg bWVudSBpdGVtLiBMb2NhdGlvbiBzcGVjaWZpZXMgdGhlIGRlc2lyZWQgdG9w TGVmdCBvZiB0aGUgbWVudSBib2R5IHJlY3RhbmdsZS4iDQl8IG1heEhlaWdo dCB8DQltYXhIZWlnaHQgXyBEaXNwbGF5IGhlaWdodCozLy80Lg0Jc2VsZiBm cmFtZUhlaWdodCA+IG1heEhlaWdodCBpZlRydWU6DQkJW14gc2VsZiBzdGFy dFVwU2VnbWVudGVkOiBtYXhIZWlnaHQgd2l0aENhcHRpb246IGNhcHRpb25P ck5pbCBhdDogbG9jYXRpb25dLg0NCVdvcmxkIGlmTm90TmlsOg0JCVtzZWxl Y3Rpb24gXyBDdXJzb3Igbm9ybWFsIHNob3dXaGlsZToNCQkJWyhNVkNNZW51 TW9ycGggZnJvbTogc2VsZiB0aXRsZTogY2FwdGlvbk9yTmlsKSBpbnZva2VB dDogbG9jYXRpb24gaW46IFdvcmxkXS4NCQleIHNlbGVjdGlvbl0uDQ0JZnJh bWUgaWZOaWw6IFtzZWxmIGNvbXB1dGVGb3JtXS4NCUN1cnNvciBub3JtYWwg c2hvd1doaWxlOg0JCVtzZWxmIGRpc3BsYXlBdDogbG9jYXRpb24NCQkJd2l0 aENhcHRpb246IGNhcHRpb25Pck5pbA0JCQlkdXJpbmc6IFsgfCBkaWROb3RN b3ZlIHwNCQkJCQlkaWROb3RNb3ZlIF8gdHJ1ZS4NCQkJCQlTZW5zb3IgYW55 QnV0dG9uUHJlc3NlZCBpZkZhbHNlOg0JCQkJCQlbZGlkTm90TW92ZSBfIGZh bHNlLg0JCQkJCQlTZW5zb3Igd2FpdEJ1dHRvbl0uDQkJCQkJc2VsZiBtYW5h Z2VNYXJrZXIuDQkJCQkJKGRpZE5vdE1vdmUgYW5kOiBbc2VsZWN0aW9uID0g MF0pIGlmVHJ1ZToNCQkJCQkJWyB8IGRvd25Qb3MgfA0JCQkJCQlkb3duUG9z IF8gU2Vuc29yIGN1cnNvclBvaW50Lg0JCQkJCQlbZGlkTm90TW92ZSBhbmQ6 IFtTZW5zb3IgYW55QnV0dG9uUHJlc3NlZF1dIHdoaWxlVHJ1ZToNCQkJCQkJ CVsoZG93blBvcyBkaXN0OiBTZW5zb3IgY3Vyc29yUG9pbnQpIDwgMiBpZkZh bHNlOg0JCQkJCQkJCVtkaWROb3RNb3ZlIF8gZmFsc2VdXS4NCQkJCQkJZGlk Tm90TW92ZSBpZlRydWU6IFtTZW5zb3Igd2FpdEJ1dHRvbl1dLg0JCQkJCVtT ZW5zb3IgYW55QnV0dG9uUHJlc3NlZF0gd2hpbGVUcnVlOiBbc2VsZiBtYW5h Z2VNYXJrZXJdXV0uDQ0JXiBzZWxlY3Rpb24hICENDQ0= --747459867-1960201971-941482736=:10762--

1 0

[UPDATES] More for 2.7alpha -- enjoy
by Dan Ingalls 01 Nov '99

01 Nov '99

1588modalPickerFix-sw -- Scott Wallace -- 28 October 1999 Makes the 'erase pixels of color' and 'recolor pixels of color' features of SketchMorphs work again -- these had been broken by the remake of the ColorPickerMorph a while back. The resulting pseudo-modal UI is still weird but at least the features once again work." 1589updatingFixes-sw -- Scott Wallace -- 31 October 1999 Miscellaneous fixes to the smart-updating mechanism, including: The current selection in any list pane no longer is lost if the corresponding list gets changed, unless the revised list does not contain the element. Inspect lists now properly update *and* retain proper values when inspectee structure changes." 1590mvcSmartUpdating-sw -- Scott Wallace -- 31 October 1999 Brings the smart-updating features (implemented earlier for morphic) to the primary mvc tools, viz. browsers and inspectors. The updating takes place automatically when you activate a window -- but of course if there are unsubmitted changes in the window, they will not be discarded; instead, you will get a warning of the conflict when you try to submit. MVC tools benefitting from this update are: the standard browsers (system, system-category, class, message-category), all message-list browsers, and versions browsers, and Inspectors. In the case of Inspectors, note that the field list is updated *and* the value pane is updated when the window is activated. Tools that do *not* yet incorporate the smart-updating include: protocol browsers hierarchy browsers inheritance browsers Incidentally fixed in this update: * cmd-f shortcut for find-class in the sys-category-list pane now works." 1591projRevert-tkLU -- Ted Kaehler -- 31 October 1999 Allows the user to save a version of a Project, and revert back to it later. In any project (but the top one), choose 'save for future revert' to save that state of the project. Make changes in the project, exit and enter freely, at any later time, choose 'revert to saved copy'. This feature only works even if you do *not* enable sending projects to disk. (Preferences enable: #projectsSentToDisk) If you want it to revert and never ask for confirmation when you leave the project, Project current projectParameters at: #revertWithoutAsking put: true. Watch out, this is very dangerous!!! People who turn on this feature and then complain that Squeak is broken will be laughed at. Segment files aren't erased so agessively now, because they may be revert segments. The Transcript is always pointed at from outside. Thus it is not in the reveted stegment. I fix up its owner pointer via a hack. The text in the Transcript *will* reflect changes made after the revert copy was saved. Please just ignore this. Everything else has been truly reverted." 1592misc-tkLV -- Ted Kaehler -- 31 October 1999 [ ] In findClass in the Browser, if you put a period after the name, it now finds just that name exactly. When you search for 'morph', you get more than one menu full of names. If you now search for 'morph.', you go right to class Morph. [ ] Previously, if you edited text in the code pane, and you pressed the Instance/Class/Comment buttons, it would discard your changes without asking. Now it asks. The mechanism for this was there already (askBeforeChanging), but it was not hooked up. [ ] In the InterpreterSimulator, you could not read any file system directory in which the file path contained a single-quote. A method in the simulator was de-String-ifying the path by simply removing the beginning and ending single-quotes. This fixes it."

1 0

[FIX] SequenceableCollections as hash keys
by John Sarkela 01 Nov '99

01 Nov '99

Hello, Whilst debugging some first and follow set closures it was discovered that SequenceableCollections redefine #= and do not redefine #hash. (For newbies, it should be an invariant that at all times objects that are equivalent have identical hash values.) I addressed this problem with the following implementation of #hash along with a mildly optimized implementation of #=. BTW, a quick port of TGen will be following in the next few days. Still tracking down some gotcha's, but it is creating LL parsers and created its first LR parser last night. Cheers, John Sarkela CTO The Fourth Estate, Inc. -----------------------------------file in the following------------------------------------- 'From Squeak2.6 of 11 October 1999 [latest update: #1559] on 1 November 1999 at 6:19:23 am'! !SequenceableCollection methodsFor: 'comparing' stamp: 'tfei 10/31/1999 10:49'! hash "Answer an integer hash value for the receiver such that, -- the hash value of an unchanged object is constant over time, and -- two equal objects have equal hash values." ^self size! ! 'From Squeak2.6 of 11 October 1999 [latest update: #1559] on 1 November 1999 at 6:19:21 am'! !SequenceableCollection methodsFor: 'comparing' stamp: 'tfei 10/31/1999 10:46'! = otherCollection "Answer true if the receiver is equivalent to the <otherCollection>. First test for identity, then rule out different species and sizes of collections. As a last resort, examine each element of the receiver and the <otherCollection>." | index | self == otherCollection ifTrue: [^true]. (self species == otherCollection species) ifFalse: [^false]. index := self size. index ~= otherCollection size ifTrue: [^false]. [index > 0] whileTrue: [(self at: index) = (otherCollection at: index) ifFalse: [^false]. index := index - 1]. ^true! !

1 0

Re: ClearType - a clarification
by Peter William Lount 01 Nov '99

01 Nov '99

Hi, Woops. I did find the Woz web site, but I didn't find any comments on his web site that relate to Sub Pixel Rendering or Clear Type. http://www.woz.org/ All the best, Peter William Lount

1 0

Jump to page: