Squeak-dev March 2004

squeak-dev@lists.squeakfoundation.org

179 participants
629 discussions

[FIX] FixToUpdate5685
by dway＠mailcan.com 04 Mar '04

04 Mar '04

from preamble: "Change Set: FixToUpdate5685CursorWithMaskFix Date: 29 February 2004 Author: Karl Ramberg Postscript in update 5685 was commented out, so that the fix hadn't taken effect yet. Fixed here"!

1 0

RE: Opening several images on Os X
by Blanchard, Todd 04 Mar '04

04 Mar '04

Don't know about the carbon vm - I use the unix vm. You can invoke it from the command line. There's info in the readme file but you basically invoke the executable within the app wrapper directly which is usually something like: /Applications/Squeak.app/Contents/MacOS/squeak [options...] [imagename [args...]] This will let you invoke as many instances as you like. http://www-sor.inria.fr/~piumarta/squeak/ -----Original Message----- From: Doug Way [mailto:dway@mailcan.com] Sent: Wednesday, March 03, 2004 10:22 AM To: The general-purpose Squeak developers list Subject: Re: Opening several images on Os X Romain Robbes wrote: > I feel very chatty today ... > > Is there a way to open several images simultaneously on os X ? > When I attempt to do so, the second image file opens as a file > in the first image ... > > IIRC I use the Carbon VM, version 3.6.1 beta 5 The only way I've been able to do it is by making a copy of the VM. Drag your first image on top of the first VM, and then drag your second image on top of the second VM. I sometimes like to have 3 or 4 images running at once, so I have several copies of the VM lying around too. :) It is a little bit wacky, and you don't need to do this on Windows for example. If there's a simpler way, I'd be glad to hear about it. - Doug

2 1

Re: [BUG?] Exception handle
by Anthony Hannan 04 Mar '04

04 Mar '04

"ICHIKAWA, Yuji" <y.ich(a)f3.dion.ne.jp> wrote: > [1/0] ifCurtailed: [Transcript show: 'exception'] > doesn't work on Squeak 3.6-#5429, I guess. > Is there anything wrong? No. The debugger halts the process while the ifCurtailed: context is still on the stack, so the ifCurtailed: context hasn't been popped yet (curtailed or simply returned). Furthermore, ifCurtailed: only executes its argument if its context is curtailed (skipped over because of remote return). When you hit proceed on the debugger you are resuming through the error (not remote returning) so the ifCurtailed: context is not curtailed and hence its argument is not executed. If hit abandon on the debugger you are remote returning to the bottom of the stack (ending the process) so the ifCurtailed: context is curtailed and hence its argument is executed. If you change ifCurtailed: to ensure: you will see that its argument is always executed whether curtailed or simply returned. If you catch the error and you do a return in your handler (which is a remote return to the on:do: caller) then the ifCurtailed: context will be curtailed and you will see its argument executed. If you do a resume in your handler you will resume where the error happened just like hitting proceed on the debugger and the ifCurtailed: context will not be curtailed. Check out the following examples: [[1/0] ifCurtailed: [Transcript show: ' exception1']] on: Error do: [:ex | ex return]. [[1/0] ifCurtailed: [Transcript show: ' exception2']] on: Error do: [:ex | ex resume]. [[1/0] ensure: [Transcript show: ' exception3']] on: Error do: [:ex | ex resume]. Transcript will print exception1 and exception3. Cheers, Anthony

1 0

Please Self-Approve all *NEW* Class Comment Submissions
by Ken Causey 03 Mar '04

03 Mar '04

In the interest of improving documentation and speeding things along everyone should simply self-approve any NEW class comment submissions. This is backed by Goran and Andreas and I think we can consider it valid until otherwise cancelled. Again note this applies only to new class comments, not class comment changes, not method comments. To self-approve your class comment submission append ' ( approved )' to the end of the subject of the email submission. Why should you write a class comment and self-approve it? Just think of seeing your name and/or initials in Doug's next update mailing... Ken

1 0

RE: Squeak readable to most people on this list, but is it to everyone?
by Brent Vukmer 03 Mar '04

03 Mar '04

> I find a series of short lines with good temp > variable names far easier to read than long Smalltalk lines. > Me, too. ( And I also use parens a fair amount :)) Just trying to *read* complex code in Smalltalk still makes my eyes glaze over.. I find that I have to trace through longer / more dense lines of Smalltalk code via the Debugger, and that in those cases I explore small parts of complex expressions, trying to build up understanding of what's going on overall.

1 0

[FIX][BUG]UndefinedObject(Object)>>doesNotUnderstand: #at:ifAbsent:
by frank＠crystal-objects.com 03 Mar '04

03 Mar '04

from preamble: "Change Set: BrowserCommentPane-fc Date: 3 March 2004 Author: Frank Caggiano This changeset address the error the system was getting if you tried to browse protocol. A change introduced in 5738 SeperateClassCommentPane caused Lexicon to try and put up a class comment pane."!

1 0

[BUG]UndefinedObject(Object)>>doesNotUnderstand: #at:ifAbsent:
by frank.shearar＠rnid.org.uk 03 Mar '04

03 Mar '04

In a virgin 3.7a-5764 image, I opened up a Browser, selected the Boolean class, and tried to browse its protocol. frank 3 March 2004 4:37:43 pm VM: Win32 - a SmalltalkImage Image: Squeak3.7alpha [latest update: #5764] UndefinedObject(Object)>>doesNotUnderstand: #at:ifAbsent: Receiver: nil Arguments and temporary variables: aMessage: at: 0 ifAbsent: [] in Lexicon(MessageSet)>>selection {[]} Receiver's instance variables: nil Lexicon(MessageSet)>>selection Receiver: a Lexicon Arguments and temporary variables: Receiver's instance variables: dependents: #(a SystemWindow(1471) a PluggableListMorph<categoryList>(2413) a P...etc... contents: nil currentCompiledMethod: nil contentsSymbol: nil systemOrganizer: ('Kernel-Objects' Boolean DependentsArray False MessageSend Mo...etc... classOrganizer: nil metaClassOrganizer: nil systemCategoryListIndex: 0 classListIndex: 0 messageCategoryListIndex: 0 messageListIndex: 0 editSelection: #none metaClassIndicated: false messageList: nil autoSelectString: nil growable: nil selectedClass: nil selectedSelector: nil currentVocabulary: a FullVocabulary named "Object" categoryList: #(#'*system-support' #accessing #associating #binding #Breakpoint...etc... categoryListIndex: 1 targetClass: Boolean limitClass: Object currentQuery: nil currentQueryParameter: nil selectorsVisited: nil Lexicon>>setClassAndSelectorIn: Receiver: a Lexicon Arguments and temporary variables: csBlock: [] in Lexicon>>selectedClassOrMetaClass {[:c :s | ^ c]} Receiver's instance variables: dependents: #(a SystemWindow(1471) a PluggableListMorph<categoryList>(2413) a P...etc... contents: nil currentCompiledMethod: nil contentsSymbol: nil systemOrganizer: ('Kernel-Objects' Boolean DependentsArray False MessageSend Mo...etc... classOrganizer: nil metaClassOrganizer: nil systemCategoryListIndex: 0 classListIndex: 0 messageCategoryListIndex: 0 messageListIndex: 0 editSelection: #none metaClassIndicated: false messageList: nil autoSelectString: nil growable: nil selectedClass: nil selectedSelector: nil currentVocabulary: a FullVocabulary named "Object" categoryList: #(#'*system-support' #accessing #associating #binding #Breakpoint...etc... categoryListIndex: 1 targetClass: Boolean limitClass: Object currentQuery: nil currentQueryParameter: nil selectorsVisited: nil Lexicon>>selectedClassOrMetaClass Receiver: a Lexicon Arguments and temporary variables: c: nil s: nil Receiver's instance variables: dependents: #(a SystemWindow(1471) a PluggableListMorph<categoryList>(2413) a P...etc... contents: nil currentCompiledMethod: nil contentsSymbol: nil systemOrganizer: ('Kernel-Objects' Boolean DependentsArray False MessageSend Mo...etc... classOrganizer: nil metaClassOrganizer: nil systemCategoryListIndex: 0 classListIndex: 0 messageCategoryListIndex: 0 messageListIndex: 0 editSelection: #none metaClassIndicated: false messageList: nil autoSelectString: nil growable: nil selectedClass: nil selectedSelector: nil currentVocabulary: a FullVocabulary named "Object" categoryList: #(#'*system-support' #accessing #associating #binding #Breakpoint...etc... categoryListIndex: 1 targetClass: Boolean limitClass: Object currentQuery: nil currentQueryParameter: nil selectorsVisited: nil --- The full stack --- UndefinedObject(Object)>>doesNotUnderstand: #at:ifAbsent: Lexicon(MessageSet)>>selection Lexicon>>setClassAndSelectorIn: Lexicon>>selectedClassOrMetaClass - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Lexicon(Browser)>>classCommentText BrowserCommentTextMorph(PluggableTextMorph)>>getText BrowserCommentTextMorph(PluggableTextMorph)>>on:text:accept:readSelectio n:menu: BrowserCommentTextMorph class(PluggableTextMorph class)>>on:text:accept:readSelection:menu: Lexicon(Browser)>>buildMorphicCommentPane Lexicon(Browser)>>addLowerPanesTo:at:with: Lexicon>>openOnClass:inWorld:showingSelector: Browser(StringHolder)>>browseFullProtocol Browser(StringHolder)>>perform:orSendTo: [] in MenuItemMorph>>invokeWithEvent: {[(selArgCount := selector numArgs) = 0 ifTrue: [target perform: selector] ...]} ...etc...

3 3

Re: Back to the issue... (was RE: Squeak coding style...)
by Maarten Maartensz 03 Mar '04

03 Mar '04

Hello everybody, Göran Krampe wrote: >Hi all! >Julian Fitzell <julian(a)beta4.com> wrote: >> goran.krampe(a)bluefish.se wrote: >> > Sometimes I really do understand why some people think Squeak is a mess, >> > especially if we can't even acknowledge the fact that we need to shapen >> > things up a bit. >> >> I don't think it's anything like that. Some people want rules - they >> just want *their* rules. I happen to think general coding standards are >> a good thing, I just happen to disagree with half of your suggestions. > The important point with my posting was the embedded question: > Can we and should we try to come up with a few rules for the standard > packages? > My little examples were NOT the point at all. Forget about them! I just > whipped them up to show what I am talking about. > > And I don't want to get involved in the discussion because I know that > > *other people* will disagree with a different half. > > > > Most of those who don't want rules probably just realize the > > improbability of coming to any agreement. > Ok, so in short you think it is pointless to even *try*? And how would > we ever be able to evolve Squeak with say Traits if we can't even agree > on some simple, small coding conventions *in the standard packages*? > Again - please people, come on! Can't at least some of you say "Hey, you > got a point here. Perhaps we could try to introduce a few standard > conventions in our *standard packages*."?! And then we can take the > discussion from there. > If not - then it truly disappoints me, I really thought this community > was... capable of constructive cooperation instead of petty "No, I don't > like this or that!" or "Forget it, no point..." > regards, Göran And since he asks explicitly, I feel I should answer (if no one else except Tim Rowledge and me agree...) I am no great Squeak-code-slinger yet, and one reason is that Squeak could do with better comments. Squeak is a great programming environment and a great programming language, but it so far has not been well documented. Part of the reason is the speed with which it is being developed; part of the reason is open source cooperation; part of the reason is that many people with many outlooks and different educations and presuppositions cooperate; and part of the reason is old habits and styles, including writing code and 'forgetting' to comment it if it works - as if people new to Squeak should have to invent all wheels allover again, although indeed with the help of a working system. More to the direct point: I am a proponent of literate programming. What I did program most in is Prolog, in which the same line is peddled ('good code is self-explanatory'). Well, my own experience (some 10 years) is that also with my own code my own comments are generally useful, especially after a while. Also, they are easier to read than code, especially lots of code. After all, code is so simple-minded in structure as to be parsable by a mere inanimate machine. And at least my human mind, although it loves mathematics, just likes to have things explained on many levels, including good English, and at least my human mind is better at comprehending good English than comprehending good mathematics or good code. Next, in Squeak it should be possible, I think, to get a good idea of what an object and its methods are supposed to do by just reading the documentation (using the button for it in the Browser). And this good idea needs to be rendered in good and clear English (if English is the language you comment code in). Indeed, somebody who is a good Squeak-programmer should get good ideas how the code could or should look given merely the English documentation. Having good documentation is an act of politeness and human kindness to all future users of the code, which includes you-who-originally-wrote-it. It is what enables others to rapidly understand at least the main purpose and outline of the code, and the intentions of its maker. Moreover: Good comments of what the code is supposed and intended to do is very useful when debugging. And what it is supposed and intended to do code just cannot convey explicitly. It NEEDS a comment - for the code itself may be bugged even if it runs and passes tests. And code doesn't think, doesn't know, and doesn't have the intentions of its writer - it merely is a rendering of what he intended and thought might realize his intentions programmatically. This is also related to the reason why even most books of pure mathematics are mostly text and not mathematics. One explains in English what it is one wants to do and why it would be nice or interesting, and also where and what the fine mathematical points and clever bits are, and shows in mathematics that and how it can be done. It's the same in programming - or it should be, and could be, with better comments and a style of literate programming which could be achieved in Squeak. I have said, your honours, and am sorry if I bored you. Regards, Maarten. ------------------------------------------ Maarten Maartensz. Homepage: http://www.xs4all.nl/~maartens/ ------------------------------------------

1 0

Re: higher level languages
by Darius 03 Mar '04

03 Mar '04

Gary McGovern asks: > Can anyone say what the highest level languages will end up like? Based on my psychology training and Jef Raskin's "The Humane Interface" and Charles Simonyi's "Intentional Programming", I have some suggestions which might indicate which direction programming environments very well might go. I say environments because I don't believe a text language alone can store, transport, and convey all the concepts that bug-free, efficient, robust, and easily modifiable programming applications require. This path of discovery /will/ require some imagination on your part. ___ First, imagine you have lost the use of your figures. Therefore, you must input your programming by voice only. Why? Those who have a handicap often must focus on what are their most important needs and the most efficient way to meet those needs in any given situation. Now list what problems you think you'll encounter and create some ideas how to get around them. Carefully note how you'll need the computer to respond and represent the programming logic and data. I have my own list that I will share later. For the "real thing", I am not saying we will or should program by voice or even by natural language. This is just an exercise to illustrate how to focus on what is important and that there may be mechanisms in natural languages that we may not yet be taking advantage of in programming languages. ___ Imagine that you can still gesture with you hand (or hands, really) and the system will know exactly what you are pointing at. For the "real thing", you might be using two mice at the same time ___ Now imagine you have a 72" monitor to display your programming environment and programming logic. It will probably need to curve around you in this imaginary work environment. Why? Most of the standards and styles for navigation in the application user interfaces, the programming user interfaces, as well as the programming language syntax are a byproduct of having to reveal and re-hide, collapse, and symbolically represent information that cannot be seen. By making most data and functions visible and available all at the same time will eliminate most of the time consuming steps for navigation and the arbitrary symbols that consume so much time in explanation and education and which are so easily forgotten. For example, why do icons now have text below them or text pops up when you hover over them? A large display allows proximity and mapped location to convey additional meaning and provide additional visual clues and memory aids that are lost when everything is collapsed. For the "real thing", I am not saying we will have such large, expensive, and natural resource consuming displays. Head mounted, "augmented reality" displays will adequately simulate such a display. Such a "personal" display will make the programmer more "mobile" and programming more of a "social" activity allowing the programmer to spend more time with other developers and end users. This technology will also allow end users to be more actively involved in the creative process of application development (per Simonyi). Nor am I saying nothing can be hidden or that no visual clues added to focus our attention, just that the more there is at our finger tips, the less time spent searching and learning. ___ Here is a brief summary of other important points required for future programming environments: (I will post more details on my Squeak People diary. http://people.squeakfoundation.org/person/Socinian/ ) o Multiple views of the code, all dynamic and interactive o The importance of lists o Syntax as a grid (rather than a tile) o Explicitly representing all concepts o Powerful, context sensitive searching, filtering/collapsing, and Why? Too may classes, methods and ambiguous names to be humanly remembered o "Auto-complete" for data entry Why? Too may classes, methods and ambiguous names to be humanly remembered o Human memory as a limited, but powerful natural resource o Programming environments and applications environments will both be equally powerful environments for creativity and perhaps even be the same environment (better than Squeak & Morphic) o Reference rather than copy/paste ___ More time will be spent describing the domain and the range of the problem and why it is important than time spent on describing /how/ to solve the problem. It is the description/representation of the problem domain and the description/representation of desired effects) which are most reusable and should be separated from the "how" logic. This is required for just the same reasons that the display logic should be separated from the application logic and both of those separated from the persistence logic and the transport protocol logic. Cheers, Socinian

1 0

Improved Accuny font set from John McIntosh
by Doug Way 03 Mar '04

03 Mar '04

This is the latest (possibly final) Accuny font set from John with the improvements in character spacing. Give 'em a try. (Can be loaded via Boris' FontEditor tool. Or via the FileList, right? Hm, no, it's not as easy as it should be. Perhaps via "StrikeFont new readFromStrike2: 'Accuny12.sf2'." and additional TextStyle doits.) - Doug

5 4

← Newer
1
...
55
56
57
58
59
60
61
62
63
Older →

Jump to page: