Squeak-dev August 2002

squeak-dev@lists.squeakfoundation.org

175 participants
535 discussions

Is this right (Process>>interruptName:)
by Ned Konz 29 Aug '02

29 Aug '02

I just saw this code in Process>>interruptName: and I'm wondering how it's supposed to work: projectProcess == Processor activeProcess ifTrue: [projectProcess suspend] Unless I'm missing something (which is very possible), this would suspend the execution of the method altogether and not bring up a debugger. Is there some magic here that I need to learn about? Thanks, -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE

1 0

[BUG] Process>>debugWithTitle: no longer works (help!)
by Ned Konz 29 Aug '02

29 Aug '02

Hi experts, When I made the ProcessBrowser, I also made a debugWithTitle: method in Process that allowed debugging of any process: running or not, UI or not. It used to work in MVC and Morphic. (it's what the ProcessBrowser uses for its "debug" action). However, more recent changes to Debugger (or something) have broken this functionality, at least in MVC. I've looked at Debugger, but I can't quite figure out what's wrong. Could someone who's familiar with the debugger code (Andreas? Scott? Dan? Ted?) point me in the right direction? Here's a test that ought to work in both MVC and Morphic. This should be two separate DoIts. p := [[123.4 printString ] repeat] forkAt: 30. p debugWithTitle: 'oops' In Morphic, this usually (well, often at least) works OK (though I have seen a "Recursive not understood error encountered" crash). In MVC, a notifier will be raised. If you choose Debug, you will be able to interact with the Debugger briefly. Try stepping once or twice, and then click on one of the lines in the stack pane. You see the context flash into view and then get erased. At some point the whole MVC environment is likely to stop working properly. I suspect that my code should be changed to correctly handle both environments. But I don't know what changes are necessary. Is there something we can do to make it possible to debug an arbitrary process in MVC and Morphic? Thanks, -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE

1 0

Re: [BUG]Collection>>removeAll:
by Martin Wirblat 29 Aug '02

29 Aug '02

David Griswold wrote: > I made a clear argument that all programs in Smalltalk (or in any > imperative language for that matter) have a universal, *implied* constraint > that you shouldn't change objects that are being used by something that > assumes that they remain the same. This language-wide constraint clearly > excludes (x removeAll: x), and the specification for removeAll: doesn't > override that. and > Programmers should read this additional constraint into all ANSI > specifications, so that removeAll: has the implied language "the argument > can be any collection that is invariant during the execution of this > method". (x removeAll: x) will NOT change x during its own execution of the part which relies on x being invariant, IF IMPLEMENTED PROPERLY. => There is NO violation on principle of the mentioned language-wide constraint by (x removeAll: x). This differs from the iterator-methods with blocks where it can NOT be guaranteed for ALL possible pieces of code in the block, that this constraint will not be violated, whereas #removeAll: can be implemented with the guaranty to work correctly with ALL possible arguments. => Therefore there is also no reason to assume that (x removeAll: x) is violating / has to violate this language-wide constraint. Such an assumption may stem from the current wrong implementation or from 'analogous' thinking of changing a collection while iterating over it, but it has no validity, meaning no programmer has to make such an assumption. => Therefore (a removeAll: b) can and should handle perfectly well a == b without raising an exception, which itself has to be considered introducing a new error because it stops the program when the programmer has all rights to expect the opposite. Some had the abstract argument of not to change the semantics of Collection: Changing #removeAll: in the proposed way would not change semantics of Collection, it would extend them, so that they stay completely compatible with existing semantics. There will be no confused programmer and no program becoming buggy. The programmer can ignore the ability of (a #removeAll: b) to handle a == b, explicitly test on identity and write the code which could be written once inside the method many times outside of it. But that would be the opposite of what the inventors of Smalltalk had in mind when creating the paradigm 'everything is a method' which allows for high reusability. The core system should be as universal, elegant and mighty as possible. If a change in this direction is possible without breaking anything, we should certainly make it. The whole Squeak system is work in progress - many parts of it are improvised or experimental - preserving the history of some other parts up to the smallest detail under nearly all circumstances would be funny. Furthermore I find it difficult to call something semantics which is at least a programmers trap, and as I showed above is - IMO - a real error. One last thought: May it be that some opinions and ideas in this thread have their subliminal roots only in a counter reaction to some specific person's destructive dialog mode which I would characterize as a bulldozer coming from all sides tearing each sentence of all others to pieces? regards, Martin

2 1

Info about Morph
by subroto mukherjee 29 Aug '02

29 Aug '02

Hi I'm looking for some information about Morphic environment. Can anybody give me any reference to online info about it ?

2 1

Re: [BUG]Collection>>removeAll:
by Richard A. O'Keefe 29 Aug '02

29 Aug '02

NEW RESULTS! There are people in this mailing list who are of the opinion that the quirk in the implementation of #removeAll: is not a bug but an obvious precondition that programmers should always have been aware of, so it doesn't need fixing. I am deeply indebted to mwai(a)geico.com for telling me that |coll| coll := OrderedCollection with: 1 with: 2. coll removeAll: coll coll inspect --> OrderedCollection() _works_ in IBM Smalltalk, despite IBM Smalltalk having the same implementation of #removeAll:. This raised the extremely interesting possibility that it might have worked in Squeak once upon a time. I decided to look for evidence. If IBM Smalltalk got it right despite having the same #removeAll:, the difference must be in #remove:ifAbsent:. Here is how #remove:ifAbsent: works in Squeak. remove: oldObject ifAbsent: absentBlock |index| index := firstIndex. [index <= lastIndex] whileTrue: [ oldObject = (array at: index) ifTrue: [self removeIndex: index. ^oldObject] ifFalse: [index := index + 1]]. ^absentBlock value removeIndex: removedIndex array replaceFrom: removedIndex to: lastIndex - 1 with: array startingAt: removedIndex + 1. array at: lastIndex put: nil. lastIndex := lastIndex - 1. Now removeIndex: is NOT original Holy Writ, it was changed by 'ar' in 2002.05.22. Presumably it was changed in order to exploit the #replaceFrom:to:with:startingAt: primitive (105). I have no idea what used to be there before. While the comment on Array>>replaceFrom:to:with:startingAt: does not say so, I presume that the primitive does the same as SequenceableCollection>>replaceFrom:to:with:startingAt:, only faster. That's a pity, because that means that we can only move array elements DOWN to fill a hole, not UP, so that the first element of an ordered collection is the most expensive one to remove. A consequence of this is that oc removeAll: (oc copy) takes quadratic time, when it _could_ take linear time. Suppose we decide to make removing the _first_ element cheap by changing removeIndex: to removeIndex: removedIndex removedIndex = firstIndex ifTrue: [ array at: firstIndex put: nil. firstIndex := firstIndex + 1. ^self]. array replaceFrom: removedIndex to: lastIndex - 1 with: array startingAt: removedIndex + 1. array at: lastIndex put: nil. lastIndex := lastIndex - 1. NOW anOrderedCollection removeAll: anOrderedCollection works. Without any change to #removeAll: at all! Now, I don't _know_ whether removing the first element of an ordered collection used to be cheap, but if ever it was, then nobody would have thought to document the hole in the implementation of OrderedCollection>>removeAll: because there wouldn't have _been_ any hole, aliasing or no aliasing. In the absence of <primitive: 105>, how might removeIndex: have been written? Obviously, to do the fewest moves: removeIndex: removedIndex (lastIndex + firstIndex) // 2 < removedIndex ifTrue: [ removedIndex + 1 to: lastIndex do: [:index | array at: index - 1 put: array at: index]. array at: lastIndex put: nil. lastIndex := lastIndex - 1] ifFalse: [ removedIndex - 1 to: 1 by: -1 do: [:index | array at: index + 1 put: array at: index]. array at: firstIndex put: nil. firstIndex := firstIndex + 1]. And there would not have been any hole in the implementation of OrderedCollection>>removeAll:. So the "don't change it" brigade may be fighting to preserve a bug which was introduced comparatively recently. I'm checking this stuff in Squeak 2.8. I notice that OrderedCollection>>removeallSuchThat: used #removeIndex: to remove elements, thus taking a method that _could_ very easily have been linear time and making it take quadratic time. That was added or changed by 'sma' in 2002.05.12. It looks as though all the methods in OrderedCollection that call #removeIndex: went in at about the same time. At any rate, it is now clear that Squeak cannot be precisely compatible with *both* VW (where coll removeAll: coll is said not to work) *and* IBM Smalltalk (where it is said to work). So we might as well be compatible with the one that works.

3 2

Re: Debugger for Windows VM
by Anthony Hannan 29 Aug '02

29 Aug '02

Taking strip out of the make allowed cygwin gdb to read the debugging info; thanks guys. But now gdb runs really, really slow, after it gets past opening the Squeak window (to slow to use). Any ideas? Do I have to fix majorShrink and run it on a shrunken image? Would that even help? Cheers, Anthony

1 0

RE: [BUG]Collection>>removeAll:
by Richard A. O'Keefe 29 Aug '02

29 Aug '02

Valloud Andres <Andres.Valloud(a)oya.state.or.us> wrote: When you write x in x\x or xUx, you don't refer to the actual set, Yes you do. That's how mathematics works. you refer to a definition. No you don't. You can refer to a definition because you wrote something like x = {e | e has some property} y = {e1, ..., en} Not often. In the case of the first, not _ever_ in modern set theory. That's what they call an 'impredicative' definition and it leads to well known paradoxes. More typically, in a theorem or a program, some of the sets are *PARAMETERS* whose definitions you do NOT have access to. Similarly, in the Smalltalk case we are considering, the x and y variables are extremely likely to be parameters whose defining code may not yet have existed at the time we wrote ours. Named "sets" are just shorthands for their definitions, No, that's classes. Read a book on modern set theory. You will discover that almost no sets have definitions. (Simple reason: definitions are countable, sets aren't. It's not even that there are infinitely many more sets than definitions, it's worse than that.) (Aren't I lucky that I've been revising set theory recently?)

2 1

Re: [BUG]Collection>>removeAll:
by Richard A. O'Keefe 29 Aug '02

29 Aug '02

Allen Wirfs-Brock <Allen_Wirfs-Brock(a)Instantiations.com> wrote: I must have missed the messages where you quoted the standard, but I did consult the actual text of the actual standard (not a draft). The words are what they are and I see how you could interpret them such that they allow the position you are taking. GOOD. Thank you very much. However, as a very active participant in the drafting of the standard, I can tell you that it was not the committee's intent to require this! At least in this country, when they interpret a law, judges are required to interpret the text of the law itself, in the light of other laws and how courts have interpreted them and the law in question. But they are NOT allowed to consider Parliament's intent. The same is generally held to apply to programming language standards, at least that's how it has been done in the case of C and Ada. Indeed, there is a very clear clash between the C89 standard and the express intent of the people who wrote it, and the text of the standard was held to be definitive, NOT the authors' intent. The reason for this is obvious. People trying to implement what the standard says, and people trying to use the standard as reference material to determine what they can expect, have in the past been most unlikely to have access to the authors or any other way of determining their intent other than the text itself. Nor can we always appeal to prior art. Sometimes a standard extends the coverage of things. That's the case in ANSI C, for example. Before the ANSI standard, malloc(0) was undefined and so was free(NULL). In many systems, they didn't work. The ANSI C standard said they had to. The prior art for #removeAll: may well have been broken; although you will search textbooks and reference manuals in vain for any hint of this. Someone with access to the ANSI Smalltalk standard discovering this could reasonably conclude that it was the intent of the ANSI committee that the bug be fixed. Indeed, the _only_ thing about #removeAll: that makes the "fixed" interpretation implausible is returning the argument instead of the receiver, and someone noting that the return value is unspecified in ANSI Smalltalk could again reasonably conclude that this removed the only barrier to an exceptionless reading. This is an issue we missed. And #addAll:, and whether #hash may be applied to cyclic objects, and ... This is another reason why we have to work with the text, rather than with the intent of the committee. If somebody had brought it up in committee we would have said something explicitly, one way or another. And I can assure you that it is extremely likely that what would have been said, is that the case where the receiver and the argument are the same object is undefined. Oh, I believe you. But it didn't happen. We have to live with the standard as it *is*, not as it might have been, and the standard as it is does not allow any exception. The only requirement is that the receiver be of a type where #removeAll: is defined (the same types where #remove: is defined) argument be a collection. No other limitations are mentioned. In the standard "undefined" means that implementations can do anything they want and that programmers should not depend upon any specific result. This would have been done to accommodate existing existing implementations (probably all of them, at the time) that "fail" in this case. I was intimately involved with the Prolog standard. (I was even invited to be the UK editor, but my Australian employers wouldn't release my time without reimbursement, and the LPA didn't have the money for that.) The Prolog standard made few if any concessions to existing implementations. Some of the early drafts even broke fundamental operations, like insisting that integer(X) signal an error for unbound X instead of failing. As the person who invented the predicate atom_chars/2 in 1984 and implemented it in Quintus Prolog, I am still very upset that the ISO Prolog committee saw fit to redefine it in a seriously incompatible way in the standard. As noted above, although the ANSI C89 standard had as an explicit goal to preserve as much existing code as possible, they still changed quite a lot of things, and did make changes that broke code. (For example, the rules for mixing signed and unsigned integers changed. I _still_ have to deal with pre-standard code where I can't be sure which parts are affected by that one and which are not.) So people reading standards can never assume that the standard would not have broken an existing implementation. Other standards committees have taken the explicit view that they need to worry about existing _users_ but not so much about existing _implementations_. I particularly note that a large chunk of Richard Harmon's work on "ANSIfying" Squeak concerns the Date and Time classes. The ANSI Smalltalk committee were not content to define a minimal 'existing consensus' standard there. Some of Harmon's work concerns the collection classes. Once again, a Squeaker looking at the standard _without_ access to the committee's intent would have no reason to believe that the committee would not have extended the coverage of a Collection method. The words that appear in the standard are what they are. However, you are using them to justify a position that was not intended by the collective authors. Yes. That's how you HAVE to read standards. That's how the C, Ada, Fortran, Pascal, Prolog, &c standards *DO* get read. You do not, indeed, you must not, consider the authors' intent. You do have to consider the normal use of language. You are entitled to assume a Gricean maxim "if there were an exception they would have told me." I don't see any reason to be bound by the intent of the committee in a case where you tell me they didn't _have_ any intent. As for what they _might_ have decided had they realised that there was an issue that needed standardising, Allen Wirfs-Brock speaks with considerable authority. (And also about Smalltalk in general.) Had the committee decided as he surmises they might have, then we would be in possession of an explicit warning "don't do that", just as we are in fact in possession of an explicit warning "don't expect the return value to be anything in particular." Sadly, they didn't. So we have to deal with the standard as it is, not as it might have been. Perhaps one day there will be a revised standard. Perhaps one day there will be different people on the committee, and they will speak for Smalltalk programmers rather than Smalltalk implementors. Perhaps. Perhaps. Until "one day", we have to deal with the standard as it is, not as it may become. So yes, I unashamedly interpret the ANSI Smalltalk using the same approach that one is supposed to use for other programming language standards. And yes, when a commonsense reading of a specification is something that can be cheaply implemented without exceptions or corner cases, and _especially_ when there turn out to be several different ways to so implement it some of which are cheaper than the existing way, I think it perverse to adopt a reading without ground in the text itself so that implementors can refrain from fixing their bugs. In the case of C and Ada at least, there are continuing committees whose job is to resolve questions about the standard. If a vendor and customer disagree about how to read the standard, they submit their questiions to the "interpretation" committee, and the answer they receive is authoritative, becoming in effect an extension of the standard. Is there such a thing for Smalltalk? It doesn't have to include the original standard authors. Some overlap is desirable, but some people who _don't_ know what was intended so that they can more easily see what is actually there are also important. Is there any work on a revised standard that might include a few more classes? Directory access methods that would make sense for UNIX, Windows, and MacOS would be nice. (For Quintus I designed Prolog interfaces that would make sense for UNIX, Windows, MacOS, VMS, and VM/CMS. Not all of that was implemented. VMS and CMS have both changed since then, making it easier, if anything.) Maybe a priority queue collection? I suppose we may never get agreement on how to handle Unicode in Smalltalk, but it's nice to dream...

2 1

Comanche on Windows 3.2.2 VM
by Kevin Fisher 29 Aug '02

29 Aug '02

Hi Folks: I'm still having some odd "broken sockets" running Comanche on the Windows VM (on Win2K). Basically, I've got a fairly recent VM (3.2.2, May 26 2002). I recently migrated my ComSwiki from an older Win2K machine to my brand-spanking new machine...I just copied everything over directly. But now, for some reason, images are being randomly broken when you view a page (if you click reload, you get different broken images every single time). If I edit a page from a different host and click "save", I randomly get an error dialog saying "document contains no data". If I go back and click "save" again, it will save properly though. My Linux-based ComSwiki (based on the same "Harvest" setup scripts) has no such difficulties...it only happens on Win2K. When I originally set up this ComSwiki on my old Win2K box, I had the same problem--but this was cured by a VM update. This same update has no effect on my current ComSwiki. Any ideas?

1 0

Multiple VMs
by Stephen Pair 29 Aug '02

29 Aug '02

This is just a random thought that just occurred to me... One thing that would be nice to have is support for multiple interpreters in the image, with the VM building tools, and even the platform compilation environments. Generally speaking, when modifying the interpreter, I first copy ObjectMemory and all of it's subclasses (not the best reuse, but there's often no clear way to subclass the existing hierarchy). It would be nice if VMMaker allowed you to select an interpreter class to generate, and then generated it to a file named something other than interp.c (like interp-mynewvm.c). Then it would be great if the make tools could see that and build one executable vm for each interpreter source file it sees...it could named them like the interp source file (like "squeak-mynewvm" in this example). If the build tools see multiple interp source files, a vm will be created for each one. Just a thought. - Stephen

1 0

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

Jump to page: