Squeak-dev May 2000

squeak-dev@lists.squeakfoundation.org

137 participants
680 discussions

RE: [BUG] DSA failure in LargePositiveInteger in #new: <primitive : 71>
by Jarvis, Robert P. (Contingent) 30 May '00

30 May '00

FWIW DigitalSignalAlgorithm>>remainder:mod: fails in the same way on a 2.7 image and VM. Test code following reproduces the error: dsa _ DigitalSignatureAlgorithm new initRandom: 3073858295119816861619518188919816443211816758784546085350209989871066306407 0074149469027751252808366839610325226801786119623563694795185024364922876162 51. x _ 1. y _ 1456264555551690166006364982944671635636330287773. val _ dsa remainder: x mod: y. Bob Jarvis Compuware @ Timken > -----Original Message----- > From: JArchibald(a)aol.com [mailto:JArchibald@aol.com] > Sent: Tuesday, May 30, 2000 2:25 PM > To: sr(a)evolgo.de; squeak(a)cs.uiuc.edu > Subject: Re: [BUG] DSA failure in LargePositiveInteger in #new: > <primitive: 71> > > > => 5/30/00 11:29:21 AM EDT, sr(a)evolgo.de => > << Could you please - by using the debugger - take a view > into this method > and look for the argument of this >>new: here? >> > > Stephan, > > Okay, here are the gory details (and they are very gory indeed). > > When I run DigitalSignatureAlgorithm>>generateKeySet, I get > an error in > Behavior>>new: with the following walk-back: > > ----------------------------------------------------------- > Error: a primitive has failed > > LargePositiveInteger class(Object)>>error: > LargePositiveInteger class(Object)>>primitiveFailed > LargePositiveInteger class(Behavior)>>new: > DigitalSignatureAlgorithm>>remainder:mod: > DigitalSignatureAlgorithm>>isProbablyPrime: > DigitalSignatureAlgorithm>>generateSandQ > DigitalSignatureAlgorithm>>generateQandP > DigitalSignatureAlgorithm>>generateKeySet > DigitalSignatureAlgorithm class>>generateKeySet > UndefinedObject>>DoIt > ----------------------------------------------------------- > > in method DigitalSignatureAlgorithm>>remainder:mod: the > run-down at the time > of failure for local variables is: > > instance variables: > randKey => > > 30738582951198168616195181889198164432118167587845460853502099 > 8987106630640700 > 74149469027751252808366839610325226801786119623563694795185024 > 36492287616251 > (class LargePositiveInteger) > randSeed => > 1369035390015187928040555654137399981674798064385 (class > LargePositiveInteger) > > arguments: > x => 1 (class SmallInteger) > y => > 1456264555551690166006364982944671635636330287773 (class > LargePositiveInteger) > > temporaries: > remainder => 01 (class LargePositiveInteger, size = 2) > divisor => > 1456264555551690166006364982944671635636330287773 (class > LargePositiveInteger) > shift => 0 (class SmallInteger) > quotient => nil (class UndefinedObject) > > 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. > > These are some very big numbers. Not as big as those I got in > other tests > mentioned in previous E-mails, but big enough. In any case, > the body of > DigitalSignatureAlgorithm>>remainder:mod: is attempting to do an > Integer>>new: with a negative parameter in statement > quotient _ LargePositiveInteger new: remainder > digitLength - divisor > digitLength. > There are a number of numeric operations in that routine > prior to this > statement, and my suspicion is that one of them is behaving badly. > > BTW (world), who did the DSA stuff? > > Still sincerely lost, > Jerry. > ____________________________ > > Jerry L. Archibald > systemObjectivesIncorporated > ____________________________ > > "Knowledge is something that you can use, > Belief is something that uses you." > Idries Shah >

1 0

Re: [ENH] String repeat
by David N. Smith (IBM) 30 May '00

30 May '00

At 18:29 -0400 5/29/00, David N. Smith $IBM$ wrote: >At 8:54 +0200 5/29/00, Bert Freudenberg wrote: >>On Sun, 28 May 2000, David N. Smith (IBM) wrote: >> >>> Attached is a method I've evolved over a while which does string >>> repeats: >>> >>> '0' rep: 5 ==> '00000' >> >>0. Seems useful :-) >>1. This should go up into SequencableCollection, not String. >>2. It should have a more descriptive selector (at least repeat:). > >3. Could be refactored to share the duplication code with from:to:put:. >> >>-- Bert > >Bert (and the others who replied): > >(1) Good idea; I just have never wanted it elsewhere so it stayed where I first put it. >(2) Sure, repeat: is better. >(3) I'll look at it... > >Dave All: (1) Upon a few moments contemplation I remembered why #rep: was in String; the algorithm was designed to be very fast and makes some assumptions: - The allocation of the collection is continuous (OrderedCollection is not) - A new collection can be obtained by #new: - The class of the object should not need to be known Most collections fail in some way, either as with OrderedCollection which has empty space at the front and/or end, or as in collections which have more than one index (what does it mean to #repeat: a 2D array?). (2) OK, it's now #repeat:. Much better name. (3) Hadn't seen that one; the algorithms are remarkably similar, though #from:to:put: only copies one element and #repeat: allows more than one (ie: #(1 2 3) repeat: 5). I agree that some refactoring is needed (and I added a note to that effect :-). Attached is a new version. The old #rep: method is now in ArrayedCollection and is named #repeatPrivate:. There are implementations of #repeat: in Array, ByteArray, Character, String, and Symbol. ByteArray only works for itself but no subclasses. There should be #repeat: methods for other collections, but they need a different algorithm which may well take some time to find. (Set is easy! Bag may not be.) For now, I leave it up to someone who has time to look at these. I was simply trying to share some code I had that I thought might be useful. If it isn't useful yet, I'll work on it later. Dave _______________________________ David N. Smith IBM T J Watson Research Center Hawthorne, NY _______________________________ Any opinions or recommendations herein are those of the author and not of his employer.

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 1:57:19 PM EDT, sr(a)evolgo.de => << I think I have found a possible location of the problem. There is a subtle difference in the semantics with or without the LargeIntegers module.>> With the detailed comments of values at the time of failure in my last E-mail, I have to admit I am at my limit with knowledge of complex (sic) arithmetic. I have done CRC algorithms and played around with Signature stuff, and I know how long it takes to acquire an understanding of what is actually going on inside of one of these things (and I know that I don't have that much understanding of this situation). <> Since you are not in a position to run DSA, and I am not in a position to create the right 'testus agonistus', can I offer myself up as a tester. Please let me know what tests and result content and formats you want, and I'll try to get them to you. I suppose we should take this off-line from the mailing list with all these (massive) cryptic numeric results. I would like to drag in whoever is responsible for DSA code (is it John Maloney?) for the knowledge that s/he may provide, and also ask Bob Arning if he is interested in participating in tracking this down? DSA programmer? Bob? Anyone else? Cheers, Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________ "Knowledge is something that you can use, Belief is something that uses you." Idries Shah

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 19:48:22 +0200 Stephan Rudlof <sr(a)evolgo.de> wrote: >So I would dig deeper first into >DigitalSignatureAlgorithm>>remainder:mod: to find the error. > > >Hope this helps, > >Stephan > >P.S.: I don't have the DSA module ready to run here, but I'm very >interested in every possible bug of the LargeIntegersPlugin: So I've >taken a look into it and explained my assumptions (which could be >wrong...). DSA is explicitly creating "short" LargeIntegers as well as not-exactly-normalized LargeIntegers with leading zeros. I don't know just how critical these techniques are for correctness or speed. Cheers, Bob

2 1

Re: [BUG] Celeste - names with non-ascii characters
by Bob Arning 30 May '00

30 May '00

On Tue, 30 May 2000 20:17:54 +0300 danielv(a)netvision.net.il wrote: >When showing a message from "Göran" Hultgren <gohu(a)rocketmail.com>, >Celeste cuts off the line in the TOC right after the $G. > >Anyone have any idea why? DisplayScanner>>drawString:at: quits as soon as it hits a character not in the font. Paragraphs and similar more sophisticated text operators will then draw the missing character glyph and continue. Cheers, Bob

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 11:29:21 AM EDT, sr(a)evolgo.de => << Could you please - by using the debugger - take a view into this method and look for the argument of this >>new: here? >> Stephan, Okay, here are the gory details (and they are very gory indeed). When I run DigitalSignatureAlgorithm>>generateKeySet, I get an error in Behavior>>new: with the following walk-back: ----------------------------------------------------------- Error: a primitive has failed LargePositiveInteger class(Object)>>error: LargePositiveInteger class(Object)>>primitiveFailed LargePositiveInteger class(Behavior)>>new: DigitalSignatureAlgorithm>>remainder:mod: DigitalSignatureAlgorithm>>isProbablyPrime: DigitalSignatureAlgorithm>>generateSandQ DigitalSignatureAlgorithm>>generateQandP DigitalSignatureAlgorithm>>generateKeySet DigitalSignatureAlgorithm class>>generateKeySet UndefinedObject>>DoIt ----------------------------------------------------------- in method DigitalSignatureAlgorithm>>remainder:mod: the run-down at the time of failure for local variables is: instance variables: randKey => 307385829511981686161951818891981644321181675878454608535020998987106630640700 7414946902775125280836683961032522680178611962356369479518502436492287616251 (class LargePositiveInteger) randSeed => 1369035390015187928040555654137399981674798064385 (class LargePositiveInteger) arguments: x => 1 (class SmallInteger) y => 1456264555551690166006364982944671635636330287773 (class LargePositiveInteger) temporaries: remainder => 01 (class LargePositiveInteger, size = 2) divisor => 1456264555551690166006364982944671635636330287773 (class LargePositiveInteger) shift => 0 (class SmallInteger) quotient => nil (class UndefinedObject) 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. These are some very big numbers. Not as big as those I got in other tests mentioned in previous E-mails, but big enough. In any case, the body of DigitalSignatureAlgorithm>>remainder:mod: is attempting to do an Integer>>new: with a negative parameter in statement quotient _ LargePositiveInteger new: remainder digitLength - divisor digitLength. There are a number of numeric operations in that routine prior to this statement, and my suspicion is that one of them is behaving badly. BTW (world), who did the DSA stuff? Still sincerely lost, Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________ "Knowledge is something that you can use, Belief is something that uses you." Idries Shah

1 0

Re: EToy status update?
by Mats Nygren 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! /Mats Nygren

1 0

Re: Proposal3: Make $_ a valid identifier character
by Bijan Parsia 30 May '00

30 May '00

On Tue, 30 May 2000, Richard A. O'Keefe wrote: > Richard, you misunderstood me. I questioned that the *reason*, the > *motivation*, for Smalltalk not having underscores in identifiers was that > ASCII lacked them, not that ASCII lacked them. > > I already *asked* in this thread whether anyone who was there at the time > knows about this. So point me to your received answer which allows you to state, with the absolute confidence that you do, that the *original* reason for not including the underscore, *and* the reason for it not being included in Smaltalk-80, was it's original unavailibility in ASCII. I'm prepared to believe it, obviously, but only with some suitable confirmation. > Given that Smalltalk developed on computers custom built, and mostly > intended for internal use, I find this is touch hard to believe. A > reference would be welcome. > > However, I'd put it the other way around. The identity of the old Smalltalk > character set with old ASCII is too much of a coincidence to accept as the > result of some special Smalltalk decisions, especially since the Blue Book > (p650) refers to the keyboard delivering ASCII codes (when ALTO codes were > also available). We're told on p114 of the Blue Book that > "Each [character] is associated with a code in an extended ASCII > character set". So how come the *only* non-ASCII characters shown in > the Blue Book are *precisely* the old versions of the two ASCII characters > that are *not shown*? Presumably if they were inherited from old ASCII, > and the extensions were other characters again. Nice speculation. But, while plausible, it doesn't establish your case. > For the record, I don't think your linguistics based argument is nearly as > air tight as you seemed to thing it was. I notice you didn't say a word > about the fact that I take "multi word" identifiers to be single words, > not collections of them. > > Well, that's a rather unusual way to view them. My native language (English) It's my native language too. > is not an agglutinating one, so it's practically impossible for me to Well, one of us must be horribly idiosyncratic. Which, regardless of issues of taste, makes us, without establishing which of our psycholinguistic structures is deviant (and they *both* could be), bad bases for determining what, rationally speaking, should be the case here. > mentally process multi-word identifiers as single "words", just as it's > very hard for me to hear "r" and "l" as vowels. So you have trouble with 'groundhog'? [snip] > Furthermore, I didn't see anything above about > the linguistic data on the superiority of $- to $_ as separators. > > I don't have any. I'd expect the hyphen to be the winner. > Lisp gets away with it because it doesn't have any infix operators. > None of the Fortran family (Fortran, Algol, Pascal, Ada, ...) has > adopted hyphen as word separator, not that I know of, and for the > obvious reason that it would be ambiguous with infix minus. Others have pointed out the infix _ in Squeak as it stands, and the possibility of distinguishing the minus and the hyphen. Needless to say Sequencable-Collection is still very bad, IMHO. But, let us not debate this further. [snip] > So would I. However, I note that the fact that Sequenceable_Collection > is visibly broken into chunks seems to make it easier to see and check > each of the chunks. There was so _much_ text in one great fat lump in > "SquencableCollection" that it was hard to see the typo. Which is why the lovely correction facilities of a Smalltalk IDE make life so much easier. Sicne I ma prune to tipos evan in spcede dilminted words, I don't take this is as at all decisive. >of course, we might just look at extant bodies of Smalltalk code with and > without $_ed indentifiers. That might provide a few clues. > > Given the existance of a free VisualWorks and a free Squeak, it might > actually be possible to _do_ such experiments. Of course. Realize that my strong opposition stems from engaging to port some Smalltalk code which made fairly heavy use of _s from VisualWorks to Squeak. The indentifiers which used _s tended to, imho, pointlessly to do so. The indentifiers were bad in themselves (imho) and the underscores merely...er..underscored that fact. A fully underscored set of indentifiers would not recognizably be Smalltalk. Nor would a fully hyphenated one. It might *be* Smalltalk, but it would be difficult to recognize as such. I think that is a consideration against full underscoration. I know you do not, so I'll let it drop here. > What would be particularly interesting to know, of course, would be why > some of the more commercial (NOT the same as more valuable!) Smalltalks > have already made the transition. I'll have to see if the draft ansi spec has a rationale for this. I'll note that AFAICT, systematic underscorification doesn't seem to have occured. Cheers, Bijan Parsia.

2 1

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

30 May '00

=> 5/30/00 12:00:30 PM EDT, arning(a)charm.net => << As far back as Squeak 2.5, I get (true '1' false ). >> Bob, I get the result for the evaluation (Squeak2.7@cs#2210 -- VM => '(2000.05.24 14:00:36 436,736) Squeak.exe' on Windows base: no question about Integer built-in module): -------------------------------------------------- zz _ LargePositiveInteger new: 1. zz digitAt: 1 put: 1. a _ zz = 1. b _ zz printString. c _ zz = 1. {a. b. c. zz} => (false '1' false 0 ) -------------------------------------------------- where zz is a LargePositiveInteger of size 1. I take this to be a bug in LargePositiveInteger>>digitAt:put:, but I don't quite know how to grok in fullness the rest of your comments, where in the case of evaluating -------------------------------------------------- zz _ Integer new: 1. zz digitAt: 1 put: 1. a _ zz = 1. b _ zz printString. c _ zz = 1. {a. b. c. zz} -------------------------------------------------- I get an error: Error: Integer cannot have variable sized instances which seems to agree with the code for Integer>>digitAt:put: When re-evaluating the DSA test, I am getting (of course) some very big numbers. Not as big as the tests I was hinting at in previous E-mails, but big enough. I am trying to compose a run-down on this test. In any case, the body of DigitalSignatureAlgorithm>>remainder:mod: is attempting to do an Integer>>new: with a negative parameter in statement quotient _ LargePositiveInteger new: remainder digitLength - divisor digitLength. There are a number of numeric operations in that routine prior to this statement, and my suspicion is that one of them is behaving badly. I'll have an E-mail up in a few minutes. Sincerely lost, Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________

1 0

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

30 May '00

Jerry, I think I have found a possible location of the problem. There is a subtle difference in the semantics with or without the LargeIntegers module. In Integer>> bitShift: shiftCount "Answer an Integer whose value (in twos-complement representation) is the receiver's value (in twos-complement representation) shifted left by the number of bits indicated by the argument. Negative arguments shift right. Zeros are shifted in from the right in left shifts." | rShift | <primitive: 'primDigitBitShift' module:'LargeIntegers'> shiftCount >= 0 ifTrue: [^ self digitLshift: shiftCount]. rShift _ 0 - shiftCount. ^ (self digitRshift: (rShift bitAnd: 7) bytes: (rShift bitShift: -3) lookfirst: self digitLength) normalize there is no >>normalize after calling >>digitLshift:, because in Integer>>digitLshift: the result will be created by result _ Integer new: len neg: self negative. ; and Integer>>new: chooses the correct representation (LargeInteger or SmallInteger) automatically. If the LargeIntegers module is present, a left shift converts the receiver to a LargeInteger (if necessary) and performs the left shift *without* a normalization of the result. I think this should be possible, because if there is a call of SmallInteger bitShift: arg "Primitive. Answer an Integer whose value is the receiver's value shifted left by the number of bits indicated by the argument. Negative arguments shift right. The receiver is interpreted as having 2's-complement representation. Essential. See Object documentation whatIsAPrimitive." <primitive: 17> self >= 0 ifTrue: [^ super bitShift: arg]. ^ arg >= 0 ifTrue: [(self negated bitShift: arg) negated] ifFalse: [(self bitInvert bitShift: arg) bitInvert] Integer>>bitShift: will be called after failing of <primitive: 17> with a LargePositiveInteger result and if there is a call of LargePositiveInteger>> >>bitShift: anInteger "Primitive. Answer an Integer whose value (in twos-complement representation) is the receiver's value (in twos-complement representation) shifted left by the number of bits indicated by the argument. Negative arguments shift right. Zeros are shifted in from the right in left shifts. The sign bit is extended in right shifts. Fail if the receiver or result is greater than 32 bits. See Object documentation whatIsAPrimitive." <primitive: 17> ^super bitShift: anInteger the same <primitive: 17> has been called. Now to <primitive: 17>; it is Interpreter>> primitiveBitShift | integerReceiver integerArgument shifted | integerArgument _ self popInteger. integerReceiver _ self popPos32BitInteger. successFlag ifTrue: [ integerArgument >= 0 ifTrue: [ "Left shift -- must fail if we lose bits beyond 32" self success: integerArgument <= 31. shifted _ integerReceiver << integerArgument. self success: (shifted >> integerArgument) = integerReceiver. ] ifFalse: [ "Right shift -- OK to lose bits" self success: integerArgument >= -31. shifted _ integerReceiver bitShift: integerArgument. ]. ]. successFlag ifTrue: [self push: (self positive32BitIntegerFor: shifted)] ifFalse: [self unPop: 2] which for a left shift only should fail (not in all cases though), if there is a result not fitting in a positive SmallInteger (Note: receiver is interpreted as positive integer). So my conclusion is, that the assumption, that Integer>>bitShift: only will be called if there is a LargeInteger result for left shifts, should hold. But I think this isn't true, if there is a violation of the 'normalize' constraint for all Integers, taken from the class comment of LargePositiveInteger: "Care must be taken, when new values are computed, that any result that COULD BE a SmallInteger IS a SmallInteger (see normalize)." So I would dig deeper first into DigitalSignatureAlgorithm>>remainder:mod: to find the error. Hope this helps, Stephan P.S.: I don't have the DSA module ready to run here, but I'm very interested in every possible bug of the LargeIntegersPlugin: So I've taken a look into it and explained my assumptions (which could be wrong...). JArchibald(a)aol.com wrote: > > All-- > > In attempting to further pursue the strange behavior of primitive plug-ins > (the possible failure to properly link to a plug-in module when morphic has > never been used), I decided to run some tests with DSA. This facility uses a > plug-in module and also does not require the use of morphic facilities, so it > seemed to be a natural for such tests. > > The simplest test of DSA behavior is just to attempt to generate the keys. > Among other things, this routine will nicely display its progress on the > Transcript. When evaluating an expression which does a send to > DigitalSignatureAlgorithm>>generateKeySet, I was confronted with errors in > Behavior>>new: which was accompanied by the following back-chain: > > ---------------------------------------------------------------- > Error: a primitive has failed > > LargePositiveInteger class(Object)>>error: > LargePositiveInteger class(Object)>>primitiveFailed > LargePositiveInteger class(Behavior)>>new: > DigitalSignatureAlgorithm>>remainder:mod: > DigitalSignatureAlgorithm>>isProbablyPrime: > DigitalSignatureAlgorithm>>generateSandQ > DigitalSignatureAlgorithm>>generateQandP > DigitalSignatureAlgorithm>>generateKeySet > DigitalSignatureAlgorithm class>>generateKeySet > UndefinedObject>>DoIt > ---------------------------------------------------------------- > > This test failed every time, although the algorithm clearly pursued different > twists in the logic (resulting from the use of a random seed). As a result, > the back-chain is sometimes different, i.e., longer. I got the same results > in both MVC as well as Morphic projects. An identical error occurs on both > Mac and Windows platforms. This was run on Squeak2.7@cs#2210. > > I did have a copy of Squeak2.7@cs#2005 (i.e., prior to cs#2163) sitting > around, so I ran the same test there. It _did_ complete successfully. > > Is there a possibility that this has resulted from the new implementation of > LargeIntegers? If not that, can anyone figure out what it is? > > Cheers, > Jerry. > ____________________________ > > Jerry L. Archibald > systemObjectivesIncorporated > ____________________________ > > "Sometimes you feel like a nut, > sometimes you are." :-o (this is one of the most remarkable, the famous > self-palindromic smiley. :-o is of course OIC) -- 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

1 0

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

Jump to page: