Squeak-dev May 2000

squeak-dev@lists.squeakfoundation.org

137 participants
680 discussions

Re: Proposal3: Make $_ a valid identifier character
by Richard A. O'Keefe 31 May '00

31 May '00

>Not true. Model 33 teletypes were still in use in the 70s (left arrow >and up arrow, NOT _ and ^). DEC-10 Prolog, developed in the late 70s, >was initially upper-case-only because printers with lower case letters >were not sufficiently widely available at that time; by 1979 lower case >was the default. The unavailability of lower case printers, of course, letters doesn't support your argument that technology of the times dictated the choice of using lower case for space separation. Once again, I do wish people would read and think before posting. That particular fragment *obviously* does not and is not intended to support that claim. It was, in context, obviously intended to refute (and succeeded in refuting) the counterclaim that ASCII-67 was universally adopted. While not intended as such, the long delay before we could rely on lower case supports the converse claim: that languages like PL/I and Burroughs Algol and (early) DEC-10 Prolog used low-line separation because they couldn't use baStudlyCaps. As far as I have been able to discover from the Alto manuals I've been able to dredge up, the Alto character set really *was* ASCII-63. *That* is the basis of my claim that Smalltalk used baStudlyCaps because it had to. Smalltalk was implemented on Altos. There was a series of Smalltalks; I've seen a Smalltalk-72 manual. (Not that I remember anything about it.)

1 0

Re: [BUG] DSA failure in LargePositiveInteger in #new: <primitive: 71>
by Stephan Rudlof 31 May '00

31 May '00

While implementing the LargeIntegersPlugin I have relied on the assumption that all LargeIntegers are correctly normalized as stated in the LargePositiveIntegers class comment: --- I represent positive integers of more than 30 bits (ie, >= 1073741824). These values are beyond the range of SmallInteger, and are encoded here as an array of 8-bit digits. Care must be taken, when new values are computed, that any result that COULD BE a SmallInteger IS a SmallInteger (see normalize). Note that the bit manipulation primitives, bitAnd:, bitShift:, etc., = and ~= run without failure (and therefore fast) if the value fits in 32 bits. This is a great help to the simulator. --- So comparisons of *not* *normalized* LargeIntegers with SmallIntegers can lead to wrong results (see also below): I have exploited the condition, that if there is a comparison of a *normalized* LargeInteger with a SmallInteger they cannot be #= ! If we would cancel the normalization assumption, many methods could be wrong - independently if they are in the LargeIntegersPlugin or in ST. So I think the DSA implementation has to be fixed to ensure the #normalize precondition, if Integer and its subclasses methods are used. John: What does the author of the DSA implementation think about this topic (rising a long thread...)? Greetings, Stephan Bob Arning wrote: > > On Tue, 30 May 2000 14:24:49 EDT JArchibald(a)aol.com wrote: > >and the argument to LargePositiveInteger>>new: is -18 (in statement mentioned > >in next paragraph). LargePositiveInteger>>new: works only if the parameter to > >#new: is >= 0. Since we are getting a negative value there, something in the > >new implementation of LargeInteger is causing this routine to go whacko. > > Jerry, > > Here is a bit more detail. In DigitalSignatureAlgorithm>>isProbablyPrime:, there is the following: > > [snip] > z _ self raise: a to: m mod: p. > couldBePrime _ z = 1. > [couldBePrime] whileFalse: [ > z = 1 ifTrue: [Transcript show: 'failed!'; cr. ^ false]. "not prime" > z = pMinusOne > ifTrue: [couldBePrime _ true] > ifFalse: [ > (j _ j + 1) < b > ifTrue: [z _ self remainder: (z * z) mod: p] > ifFalse: [Transcript show: 'failed!'; cr. ^ false]]]]. "not prime" > [snip] > > What can happen here is that z can be a one-byte LargePositiveInteger with a value of 1. Unfortunately, this is not equal to 1 with the new plugin. Because comparing a not normalized LargePositiveInteger with a SmallInteger leads to a wrong result. Stephan > So couldBePrime is set to false and eventually we get to > > z _ self remainder: (z * z) mod: p > > with z still this "short" LargeInteger 1. Clearly, this method was trying very hard not to send #remainder:mod: with the first argument equal to 1, but this one slips right through both tests. So we wind up doing something like: > > DigitalSignatureAlgorithm new remainder: 1 mod: 2342342344234 > > which creates the walkback that you are seeing. Now the comment in #remainder:mod: states > > "Answer the remainder of dividing x by y, where x and y are both large positive integers of at least two digits." > > so the walkback may be a design feature of this method and a bug elsewhere. > > Note that if you change the line in #isProbablyPrime: to: > > z _ (self raise: a to: m mod: p) normalize. > > then DSA will generate the keys without a walkback. Whether things are really correct at that point, I don't know, but the walkback doesn't happen. > > Cheers, > Bob -- 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 1

Re: Proposal3: Make $_ a valid identifier character
by Richard A. O'Keefe 31 May '00

31 May '00

From: Bert Freudenberg <bert(a)isgnw.CS.Uni-Magdeburg.De> So provided that we want explicit word separators, I would suggest using a hyphen instead of the dash/minus sign, which is typographically correct, esthetically nice and also resolves the parser problem. Fortunately, Squeak's MacRoman character set already has that glyph: (Character value: 16rD0). For input, a minus inserted after a letter would produce a hyphen, while after any other letter it would become a minus. If Squeak were all alone in the world, that would be just about *perfect*. But it isn't. There are other Smalltalks, and a Smalltalk standard. I don't really like _any_ barriers to swiping useful code that happened to have been written for other Smalltalks. Do you?

1 0

[ENH]Latest benchmarks package
by Tim Rowledge 31 May '00

31 May '00

Thanks to Helge, my minor porting job on the old Green Book benchmarks has been brought up to 2.8 capability. http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas/sqBenchmarks.cs Just FYI, my 5 year old Acorn, running a 200MHz cpu with 16Kb(count'em!) caches, 16MHz memory and no FPU compiled with a four year old compiler gets:- BitBLT 158.3333333333333 TextScanning 31200.0 ClassOrganizer 238.1889763779527 PrintDefinition 555.5555555555555 PrintHierachy 1162.790697674418 AllCallsOn 48.7540628385699 AllImplementors 179.5580110497238 Inspect 298.360655737705 Compiler 524.705882352941 Decompiler 248.0 KeyboardLookAhead 236.1111111111111 KeyboardSingle 262.019230769231 TextDisplay 126.1083743842364 TextFormatting 404.9295774647886 TextEditing 362.2317596566523 Performance Rating 367.0434379525636261594634083 and 0 tinyBenchmarks returns 10322580 bytecodes/sec and 373349 sends.sec whereas my brand new 600MHz pentium3 with 1Mb caches, 133MHz memory and an fpu compiled on the latest gcc gets BitBLT 1257.48502994012 TextScanning 43943.661971831 ClassOrganizer 1495.488814732419 PrintDefinition 4607.046070460704 PrintHierachy 7507.50750750751 AllCallsOn 313.7583015217277 AllImplementors 1791.62072767365 Inspect 2721.29186602871 Compiler 4188.580015026296 Decompiler 1798.404641044235 KeyboardLookAhead 3143.491124260355 KeyboardSingle 2625.2408477842 TextDisplay 734.155434470892 TextFormatting 3954.607977991747 TextEditing 2136.708860759493 Performance Rating 2600.91381625157627578 and 0 tinyBenchmarks returns 44475330 bytecodes/sec and 1458439 sends.sec Not too bad. -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim It's 10 o'clock. Do you know where your child processes are?

1 0

RE: [Win32][3D] Fearless alpha testers wanted
by Raab, Andreas 31 May '00

31 May '00

Folks, Thanks to all of you guys who actually tried the stuff I put up on the webpage I got some very valuable feedback. The bottom line is that this stuff does require a little more work (several people had problems some of which I know how to solve and some of which I don't). Since I've got enough feedback for the first round of tests I've retracted the zip file from the server. I'll need to get back into the C compiler and try to fix those problems before we can get into the next round. I'll keep you posted. - Andreas

1 0

Re: EToy status update?
by Eric Scharff 30 May '00

30 May '00

>Dan Ingalls <Dan.Ingalls(a)disney.com> wrote: > > [many things about EToys and ST-80] > > Hope this helps > > > > - Dan > >This is great! Thank you! Indeed, this is invaluable. Many thanks! -Eric

1 0

Re: [BUG] DSA failure in LargePositiveInteger in #new: <primitive: 71>
by Bob Arning 30 May '00

30 May '00

On Tue, 30 May 2000 20:47:09 +0200 Stephan Rudlof <sr(a)evolgo.de> wrote: >It would be interesting to implement the DSA algorithm in plain ST by >using - indirectly by arithmetic operations - the LargeIntegers module >and *not* using the DSA module. Then to compare the speed of this >implementation with - an older running - DSA module using >implementation. I took three of the existing routines that compared DSA math to Squeak math and converted them to run either one or the other. Here are the results the dsa plugin results: 100,000 multiply took 11,751 ms 100,000 remainder took 14,296 ms 100,000 divide took 15,318 ms the large integer plugin results: 100,000 multiply took 10,600 ms 100,000 remainder took 16,298 ms 100,000 divide took 20,248 ms Note that each iteration of the loop above includes the creation of new random input numbers. With that moved outside the loop (and hoping that neither plugin is particularly sensitive to the exact data used) reveals: dsa plugin 100,000 multiply took 1,656 ms 100,000 remainder took 3,546 ms 100,000 divide took 4,577 ms integer plugin 100,000 multiply took 1,142 ms 100,000 remainder took 5,986 ms 100,000 divide took 9,565 ms The integer plugin times are considerably longer since I included both c // d and c \\ d to parallel the fact that DSA returns both when doing a divide. I have also modified the normal DSA methods to use standard Squeak arithmetic, but beyond the single test "DigitalSignatureAlgorithm example" which was successful, I'm not sure how else to validate the changes. Cheers, Bob

2 1

[ENH] Confirmation Dialogs (v3)
by russell.allen＠firebirdmedia.com 30 May '00

30 May '00

Hi everyone, Here is my third version of my MacOS X-ish modal dialogs. Changes are: + images are included in the change set (thanks Bert) + the part of the dialog with the text etc has a opaque background to make it easier to read Once again, all comments, feedback requested! :) Russell ---------------------------------------- Russell Allen russell.allen(a)firebirdmedia.com ----------------------------------------

1 0

Re: [BUG] DSA failure in LargePositiveInteger in #new: <primitive: 71>
by JArchibald＠aol.com 30 May '00

30 May '00

=> 5/30/00 3:24:12 PM EDT, arning(a)charm.net => << What can happen here is that z can be a one-byte LargePositiveInteger with a value of 1. Unfortunately, this is not equal to 1 with the new plugin. >> [and of course Bob is producing answers before the question is even asked -- :-) ] Stephan, Shouldn't we assume full coercions for the entire family of Integer classes? Somehow this (lack of) equality doesn't seem correct. Getting closer, Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________

1 0

Pluginized VM on Linux?
by Mats Nygren 30 May '00

30 May '00

Hi! Is the new VM ported to Linux yet? I volunteer to work with this, if wanted, but it will take some time to get into the details. /Mats Nygren

3 2

← Newer
1
2
3
4
5
6
7
8
9
...
68
Older →

Jump to page: