Squeak-dev May 2000

squeak-dev@lists.squeakfoundation.org

137 participants
680 discussions

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

30 May '00

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: Could you please - by using the debugger - take a view into this method and look for the argument of this >>new: here? This method has nothing to do with the LargeIntegers module: Behavior>> new: anInteger "Primitive. Answer an instance of the receiver (which is a class) with the number of indexable variables specified by the argument, anInteger. Fail if the class is not indexable or if the argument is not a positive Integer. Essential. See Object documentation whatIsAPrimitive." <primitive: 71> self isVariable ifFalse: [ self error: self printString, ' cannot have variable sized instances']. (anInteger isInteger and: [anInteger >= 0]) ifTrue: [ "arg okay; space must be low" Smalltalk signalLowSpace. ^ self basicNew: anInteger "retry if user proceeds" ]. self primitiveFailed For me it is interesting, *why* this method fails for you. Stephan > 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

Re: Seeking help on Font Display
by Dan Ingalls 30 May '00

30 May '00

>I built a font using BitFont from a publicly available font called >Ypatia whose contents are mostly Greek letters >(http://coweb.cc.gatech.edu:8888/cs2340/uploads/ypatia.zip). It's >behaving oddly, and I'm not sure how to fix it. > >The problem is that this works: >('g' asParagraph textStyle: (TextStyle named: 'Ypatia')) display >But this displays nothing at all: >('G' asParagraph textStyle: (TextStyle named: 'Ypatia')) display > >All the capital letters are blank. ' G ', however, works fine, as >does any text typed into a TextMorph or Workspace. Swapping >'NewYork' or 'ComicBold' for 'Ypatia', also works. > >My suspicion is that I've screwed up the font definition somehow that >the bounds aren't being computed correctly, but I'm starting to get >lost trying to find and fix the bug. Does anyone have any >suggestions or have had similar experiences? Mark - My suggestion is first to examine (TextStyle named: 'Ypatia') defaultFont fontDisplay. If only one thing looks wrong, I would go after it with the various widthOf:, edit:, etc. methods available. I sure don't know what caused the problem. Also, naturally, inspect the font to check that minAscii, maxAscii, etc are reasonable. Good luck - Dan

2 1

Re: Proposal3: Make $_ a valid identifier character
by Andrew C. Greenberg 30 May '00

30 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. -- Andrew C. Greenberg acg(a)netwolves.com V.P. Eng., R&D, 813.885.2779 (office) Netwolves Corporation 813.885.2380 (facsimile) www.netwolves.com

1 0

Re: Proposal3: Make $_ a valid identifier character
by Andrew C. Greenberg 30 May '00

30 May '00

At 5:31 PM +1200 5/30/2000, Richard A. O'Keefe wrote: > Ahem. Squeak derives from Smalltalk 80, named after the year 1980. > >So what? I've seen VMS sites still using printers in the early 80s >where _ printed as <-. Your thesis, as expressly stated and reiterated, was that Smalltalk didn't include low lines "because it simply _couldn't_. The fact that it was possible to have used Smalltalk on machines that "couldn't" in 1980 does not prove your point any more than the fact that it is equally possible to use those machines today. -- Andrew C. Greenberg acg(a)netwolves.com V.P. Eng., R&D, 813.885.2779 (office) Netwolves Corporation 813.885.2380 (facsimile) www.netwolves.com

1 0

Re: Proposal3: Make $_ a valid identifier character
by Karl Ramberg 30 May '00

30 May '00

Stefan Matthias Aust wrote: > Henrik Gedenryd wrote: > > > > Stefan Matthias Aust wrote: > > > > > PROPOSAL > > > > > > For better ANSI compatibility, I propose to allow _ (actually it's printed > > > as <- with the default font in Squeak) in identifiers. > > > > May a curse be placed on you for reopening that syntax thread. > > And may you all carefully read the proposal before staring flaming. > It's not > a matter of whether to use _ or := but just the extension of the system > to > allow _ as valid character for literals as required by ANSI Smalltalk. > > And you don't even have to use this feature (as some other people tend > to > think here on this list just because it's possible. You always have to > freedom of choice. However, get achieve this freedom, you need this > alternative first) The main reason, as already said, is compatibility > which is IMHO a good thing. > > bye > -- > Stefan Matthias Aust Projektleiter/Softwareentwicklung > Baltic Online Computer GmbH, Alter Markt 1-2, 24103 Kiel > Fon: +49 (0) 431-54003-0 Fax: -99 http://www.baltic-online.de That's true, but if we now want to keep the old style, can't the filein convert underscores to uppercase or something ? Same with fileout, convert to ansi ? Isn't this what computers are good at in the first place ? ;-) Karl Karl

1 0

Re: Who wants to refactor #deepCopy?
by Stefan Matthias Aust 30 May '00

30 May '00

Henrik Gedenryd wrote: > > Stefan Matthias Aust wrote: > > > Anybody looked at copy, clone, deepCopy, veryDeepCopy recently? > > > * I think, deepCopy doesn'T really work and only veryDeepCopy (a stupid > > name, sorry) works. So why it is still included? > > > Look at Dolphin Smalltalk for a cleaner, IMHO much better implementation of > > #deepCopy. > > I always use vDC as I know it does the full job with handling shared > instances and so on, never deepCopy. It's in the blue book, though, so it > should probably not be removed. What's wrong with deepCopy in your view? Being in the Blue Book is no reason to keep a method which - as you said, too - obviously doesn't work corectly for all cases. I dislike the fact that instead of fixing it, there were introducted another set of methods (vDC) > #fullCopy seems to be an outdated predecessor of vDC though, and could > probably be removed. Yes, you're right. I overlooked that method until now. > > * What's that check-variables-every-10-minutes mess?! (see DeepCopier) > > Since the project swapping mechanism relies on vDC, it is essential that it > is right. This checks that vDC is up to date in that each class's > implementation of vDCInner: and ...FixupWith: handle all instance variables. Still, if it's a requirement for projects so either remove that requirement or check this only when switching project (or otherwise accessing this) but not on fileOut and every 10 minutes otherwise. A comment in the affected classes plus some code like that strange warning when overwriting #new could have been a better approach I think. But perhaps I still doesn't really have understand the problem here. All I can say is that the code smells... The current way of doing it sounds like a hack for me. I really appreciate your work to make it faster, but still, I think the whole idea is stupid. bye -- Stefan Matthias Aust Projektleiter/Softwareentwicklung Baltic Online Computer GmbH, Alter Markt 1-2, 24103 Kiel Fon: +49 (0) 431-54003-0 Fax: -99 http://www.baltic-online.de

1 0

Question about drag'n drop
by Karl Ramberg 30 May '00

30 May '00

Hi, thanks for making the d&d browser. Now I just cant wait for the support in changeset browsers etc. But there is one thing I wonder about: When I edit a method, then click on another method before saving, it brings up a dialog whether or not I will like to save. That's all good, but when I click the yes or no button the next thing that happens is that the method I clicked is hanging onto the cursor. Is that really wanted ? I would much rather have the method or what ever I clicked in the first place selected like before. It's very rear I use d&d compared to reading other methods. Is this hard to change back ? Karl

1 0

Re: Proposal3: Make $_ a valid identifier character
by Bert Freudenberg 30 May '00

30 May '00

[in short: proposal to use char #D0 as word separator] Hi folks, I don't really need word separators at all - my native language is German, which just concatenates words to assemble complex ones: Sequencablecollection. To enhance readability in extraordinary complex or ambiguous words, a hyphen is used: Sequencable-Collection. Now, typographically, there are more than one hyphen-like glyphs (a horizontal line in about the middle of the row). One is used to concatenate words. It is as thick as the letters, and relatively short (about the width of a "t"). Another one is used to separate parts of sentences (n-dash, as opposed to English's use of an m-dash). The last one is the minus sign, which is identical to the horizontal bar of the plus sign. In TeX, the three "dashes" are typed as -, --, and ---, respectively. A - in math mode is distinuished from the normal one. See attached image. 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. -- Bert

1 0

Re: Proposal3: Make $_ a valid identifier character
by JArchibald＠aol.com 30 May '00

30 May '00

=> 5/30/00 4:33:27 AM, Henrik.Gedenryd(a)lucs.lu.se => << My personal opinion in the matter withheld at the request of myself. >> I have a similar opinion, also withheld at my request. Jerry. ____________________________ Jerry L. Archibald systemObjectivesIncorporated ____________________________

1 0

Proposal3: Make $_ a valid identifier character
by Stefan Matthias Aust 30 May '00

30 May '00

PROPOSAL For better ANSI compatibility, I propose to allow _ (actually it's printed as <- with the default font in Squeak) in identifiers. These are valid identifiers: _ab ab_ a_b These are valid symbols #_ #_abc #abc_ #_: #abc_: (#_ already works, but that's probably just a bu^H^Hfeature) BACKWARD COMPATIBILITY ISSUES This one is tough. Currently, $_ is used as assignment operator. ":=" is a valid alternative, but nearly every method in the system uses "_" and probably a lot of people prefer this over ":=", even if the latter has the advantage that it works with standard-ANSI fonts. It would be however trivial, to automatically change all methods to use ":=" instead of "_". The only case where this fails might be places where code is constructed from string and then compiled. However, only that strange, dreaded Morphic player stuff uses this feature I think. So I don't care :-) Here's want I'd suggest: A previously valid assignment abc_abc is declared illegal. The assignment operator now must be to be surounded by spaces or other syntax characters. So abc_12 is now interpreted as abc_ 12 (probably illegal) and not as abc := 12 Fortunately, the current image already uses the convention to add a space before and after an assignment operator in nearly all places. Once one has a small piece of code to locate these cases, it should be easy to fix. Furthermore, only code that needs to be recompiled is affected, so even if we overlook some places, it doesn't break the system (it might break the pretty printer, though). Now, the single identifier _ is declared illegal - opposted to ANSI. Hopefully, nobody really want to call a variable or unary method simply "_". This allows us to still treat _ as assignment for backward compatibility. We might want to add a switch (Smalltalk ansiConformance, Smalltalk ansiConformance: aBoolean) which answers whether we want strict conformance or better the backward compatibility workaround. ADVANTAGES ANSI conformance as well as conform with VisualWorks, Dolphin ST, VisualAge and probabyl also other Smalltalk systems. Well, not 100% conformance but hopefully close enough to easily convert existing code to Squeak. IMPLEMENTATION ISSUES Doable. A year ago or so, I did this change (and posted it even to this list) and I can probably dig out that code. It's again a scanner issue. bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf

4 3

← Newer
1
...
6
7
8
9
10
11
12
...
68
Older →

Jump to page: