Squeak-dev August 2000

squeak-dev@lists.squeakfoundation.org

130 participants
418 discussions

Re: [BUG][!] Optimization bug in gcc! [was: Re: sinful bug]
by Stephan Rudlof 04 Aug '00

04 Aug '00

"Raab, Andreas" wrote: > > Have you tried "-fno-fast-math"?! The documentation says it "improves FP > speed by violating ANSI and IEEE rules". Doesn't work. Stephan > > - Andreas > > > -----Original Message----- > > From: Stephan Rudlof [mailto:sr@evolgo.de] > > Sent: Thursday, August 03, 2000 5:25 PM > > To: squeak(a)cs.uiuc.edu > > Cc: recipient list not shown > > Subject: Re: [BUG][!] Optimization bug in gcc! [was: Re: sinful bug] > > > > > > Stephan Rudlof wrote: > > > > > > Dear Squeakers, > > > > > > there seems to be an optimization bug in gcc, arising in > > interp.c for -O1 > > > already! > > ... > > > > But > > gcc -O3 -fno-inline -I. -I../src -I../src/CoreVM > > -DHAVE_CONFIG_H -DUNIX > > -c gnu-interp.c > > works. > > > > This means that inlining forces the bug here! > > > > > > ( > > gcc -O1 -I. -I../src -I../src/CoreVM -DHAVE_CONFIG_H -DUNIX -c > > gnu-interp.c > > doesn't work) > > > > > > Stephan > > -- 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

Squeak World Tour
by johnson＠cs.uiuc.edu 04 Aug '00

04 Aug '00

There has been a lot of discussion on this list about making Squeak better for building commercial applications. Some of us have decided to do something about it. John Sarkela is going to lead the "Squeak World Tour", which is sort of a movable refactoring party. We are planning to hold the first session at the ESUG Summer Smalltalk School in September. We will probably have at least half a dozen similar events, so those in the US don't need to think that they have to cross the Atlantic right away to participate. But southern England is supposed to be pretty scenic this time of year. And those who are closer should not miss this opportunity! For further information, see http://wiki.cs.uiuc.edu/CampSmalltalk/Squeak+World+Tour You can direct questions to John or to me. -Ralph Johnson

2 1

GCC & sin
by Andres Valloud 04 Aug '00

04 Aug '00

Another interesting link, saying something close to what we need to know. http://gcc.gnu.org/ml/gcc/1999-11/msg00521.html

1 0

[BUG] ensuring that mutual-exclusion Semaphores retain their excess signals
by Craig Latta 04 Aug '00

04 Aug '00

Hi-- Now that Squeak supports ensured behavior, Semaphore>>critical: should ensure that the receiver ends up with an excess signal, no matter what happens while evaluating the critical block (e.g., an unhandled exception). Something along the lines of: *** self wait. ^aBlock ensure: [self signal] *** And is Semaphore>>critical:ifError: really necessary anymore, given the current exception-handling system? thanks, -C -- Craig Latta composer and computer scientist craig.latta(a)netjam.org www.netjam.org crl(a)watson.ibm.com Smalltalkers do: [:it | All with: Class, (And love: it)]

1 0

Re: Large integers
by Andrew C. Greenberg 04 Aug '00

04 Aug '00

I get a substantially different result, using the LargeIntegers plugin: Time millisecondsToRun: [(855 raisedTo: 2753) \\ 3233] 155 milliseconds. Of course, if you try to print the result of 855 raisedTo: 2753 it will take a few weeks to compute the radix 10 representation. On the other hand, executing the doIt: x := 855 raisedTo: 2753 is fast, really fast. For me, printing the result of the expression: (855 raisedTo: 2753) \\ 3233 was virtually instantaneous. At 3:29 PM +0200 8/3/00, Wouter Gazendam wrote: >Hi All, > >I'm trying to build a RSA implementation in Squeak, and I came across the >following problem: >RSA works with incredibly large numbers (sometimes up to 10^1000), >PrintIt-ing the next line takes about 8 secs to run: > >(855 raisedTo: 2753) \\ 3233 > >Any ideas how to speed this up? > >Wouter Gazendam -- 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 Please use werdna(a)mucow.com instead of werdna(a)gate.net

1 0

Re: modelling program comments
by Les Tyrrell 04 Aug '00

04 Aug '00

Lex Spoon wrote: > > Jon Hylands <Jon(a)huv.com> wrote: > > > This is something we talked about a lot at Interval. The idea was to > > use the web browser as the text view for viewing/editing code, and > > being able to have embedded objects and links that do stuff like > > cross-referencing, or are pointers to more complete documentation. > > > > As an orthogonal concern, I certainly agree that all documentation > should be hyperlink-able, including comments. It's unreasonable to > think of people reading through code straight through, just like it's > unreasonable to read an encyclopedia straight through. > > In my mind, the only question is what kinds of links should be present, > and further, what kind of style programs and their documentation should > be written in to be the most helpful. > > > -Lex ByteSmiths once described and provided example code for a hyperlinking facility for VisualWorks which was implemented by creating new Text emphasis objects. Of course, there was a bit more to it than that but not much more. The biggest immediate problem was that method source text was stripped of its emphasis before being stored, this was among the biggest changes. I probably still have source code for that lying around someplace. This might be a better approach than inferring comment ownership- there are several ambiguities that exist, whereas one could simply highlight whatever expression they desired to emphasize it with a metadata emphasis. The emphasis could be visible to the eye, with special mouse-over behavior to provide access to the metadata object. - les

1 0

RE: ifNil, ifNotNil
by Eric Arseneau 04 Aug '00

04 Aug '00

> I, too, years ago implemented ifNotNil: with an optional argument. > > For Squeak, I happily use ifNotNilDo:. It is not as generic, but it saves > an argument count test. Now if only it were transformed, too... Hi Jim, I will work on the transform now. The transform will get rid of the need for testing for 0 vs 1 arguments. I am assuming that no one will mind and sees no problems with this ???

2 2

ifNil, ifNotNil
by Eric Arseneau 04 Aug '00

04 Aug '00

I hate to bring an old subject up, but I've just hit it. I found an old discussion on the form on this subject and would like to bring a different perspective. a := anObject ifNil: ['Hello'] Is an expression that makes sense and is desirable. The result of this expression is anObject if anObject is not nil, and 'Hello' if anObject is nil. It allows me to write some very simple expressions without having to do something like. a := anObject. a isNil ifTrue: [ a := 'Hello']. But the real reason I bring this up is do to an old post I think I made a few weeks ago, and I can't find it in the archive. I've just run into a problem where the parser is telling me that ifNotNil: expects a zero argument block. I added support for 0 or 1 argument blocks for this in the 2.7 I was using. Now I look in 2.8 and find that the ifNil, ifNotNil and variants get transformed and do not support the argument case. Support an argument to ifNotNil: is VERY useful. Think of the following: a := self someLongOrExpensiveOperation ifNotNil: [:value | value someThingIWantOutOfTheResult]. a isNil ... What the above allows me to do is to not need to define a temp. This becomes even more important when we starting having real block closures. When this happens, the block that is for the ifNotNil is of ZERO cost for the nil case, and cheap otherwise. Is there any problem in adding support for zero and one argument blocks for ifNotNil ???

2 1

MenuManager/MenuSpecification
by Eric Arseneau 04 Aug '00

04 Aug '00

Hello all, I'm not sure someone has covered this before, so here goes an idea and lets see where it goes. I want to release some changes I made to the debugger. I've added a couple of really useful operations to the context list. One of them being 'drop to selected frame'. This is a very indispensable operation once you get used to it. The problem with releasing it is that I have to release changes made to the menu methods within debugger. This does not seem a very good way to release these types of changes. With some of the packaging/trimming efforts we are undertaking, dependencies on things that are not necessary will and have cropped up. What I am proposing is to define a MenuManager class that allows tools to 'register' an interest in a named menu and to add to it. We would then change all of the tools to go through the MenuManager whenever they want a menu. Each menu would be broken down into named groups, this would handle the lines issue. So a possible interface could be: addInterestInMenuNamed: #debugger for: MyClass selector: #theSelectorWithWhateverArgumentsWeNeed addBlock: {some block with necessary args} toMenuNamed: #browser labelled: 'Label' inGroupNamed: #group Hockey names, but a start. Another part of the proposal would be to provide a menu specification interface. We could have tools provide a MenuSpecification to the MenuManager. Then, whenever a tool wanted its menu, the MenuManager would get all of the specifications for it, merge them into one, and then render the menu for MVC or Morphic. Does this sound like the start of a good idea ? Or am I missing something and it already exists ?

2 1

Re: [BUG] Symbol>>hash
by Henrik Gedenryd 04 Aug '00

04 Aug '00

Eric Arseneau wrote: > As far as removing the hash on Symbol, I would be careful with that. I'm > sure the VM does not care too much, but there may be some issues with > MethodDictionary. I don't know how the VM does its lookup for methods, but > I assume that it implements the hash lookup on the MethodDictionary > structure natively. Re. hashing efficiency--I looked at this a while ago, since the lookup algorithm seems really simple, it doesn't use even the simplest optimizations it seems, like double hashing, Robin Hood hashing, etc. But the thing is that the method lookup in the vm uses the exact same algorithm as MethodDictionary (for obvious reasons). And there it works extremely well. The simplicity means that the code contains no expensive operations, like long divides for better distribution or a "double hash" step size, no wrap around checks, etc. But even so, the number of visited slots in the hash table was really low, for things like finding out that a method is not there (ie. need to continue look in a superclass), and so on. Given that the cost of going to the next superclass is much higher, it would seem hard to improve that part. (Btw, this is why making the MD's more compact would probably reduce performance a great deal--you'd have to look in many more slots to get a miss.) So I was pretty impressed by that and dropped the hashing project. No doubt, extreme cases will require special measures, but the general case seems hard to improve. Henrik

1 0

← Newer
1
...
34
35
36
37
38
39
40
41
42
Older →

Jump to page: