Squeak-dev October 1998

squeak-dev@lists.squeakfoundation.org

107 participants
209 discussions

getting my whiskers wet
by Lyn A Headley 26 Oct '98

26 Oct '98

hello, I've just started with squeak and I must say I'm quite impressed with the system. I have a couple of questions, though, so I hope people won't mind if I fire away. Is there a way to ask a browser to display all method names (across all classes) which contain a certain substring? sort of like the "find class" option, but for methods. Maybe I'll take this on as my first project if it hasn't been done yet. What's the scoop on exception handling? Is there any? I've seen a few vague comments about wishing for a unified mechanism, could someone shed some light on that? How do I declare a local variable at the beginning of a block? I thought this looked fine, but squeak complained: a := [ | b | b := 0. [b < 10000] whileTrue: [ b := b + 1 ] ] last one: are people satisfied with the representation of the namespace for primitives as a flat array? Coming from a Python background, I really appreciate the benefits of a modular C-extension mechanism, and I was just wondering if the team had any plans to head in such a direction... -Lyn

2 1

Re: XRe: Structure of objects and execution (with effects on visual programming, and reversible debugging, )
by Ralph Johnson 26 Oct '98

26 Oct '98

There are systems in which you edit parse trees directly, not source. They are called "syntax directed editors". The Cornell Program Synthesizer was written about 18 years ago, and worked for PL/C. Of course, Lisp systems are even older, but this was the first system I know about that worked on a language with a complex syntax. Systems that only let you edit parse trees can be inflexible and a pain in the neck. The best systems let you do both. This is sort of what the Refactoring Browser does. -Ralph

1 0

Re: CrLfFileStream as default?
by lex＠cc.gatech.edu 26 Oct '98

26 Oct '98

Dwight Hughes <dwighth(a)ipa.net> wrote: > I would also like to see it handle pathological files -- I seem to run > into a number of source files that have (for example) LF in one part, CR > in another, CRLF in another, and, just for fun, mutants like LFCRLF, > CRLFLF, CRLFCR, and CRCRLF sprinkled here and there. Perhaps > CrLfFileStream should simply chomp all of the above combinations into a > single CR on a read (which seems to be the "right thing" in most cases > I've seen), and only bother with line end conventions when filing out. > > I guess I'm wondering if this would be useful to others or if I'm just > lucky. > I think it would be, though I think you're quite "lucky" if you are actually seeing things quite as bad as you describe! It's easy to do. I think you only need to change next and next: and remove references to lineEndConvention: CrLfFileStream.next | char nextC | char _ super next. self isBinary ifTrue: [^ char ]. char = Cr ifTrue: [ "funny code because of how peek is implemented" nextC _ super next. super position: super position - 1. nextC = Lf ifTrue: [super next]. ^ Cr]. char = Lf ifTrue: [^ Cr]. ^ char CrLfFileStream.next: n | string | string _ super next: n. string size = 0 ifTrue: [ ^string ]. self isBinary ifTrue: [ ^string ]. string _ string withSqueakLineEndings. string size = n ifTrue: [ ^string ]. "string shrunk due to embedded crlfs; make up the difference" ^string, (self next: n - string size) There is still a problem with using CrLfFileStream as the default, however: dealing with file positions. Right now, file positions in a CrLfFileStream will sometimes jump up by 2 even though you've only read 1 Squeak-visible character. Either this needs to be sanctioned like it is in C (yick!), or code needs to be added to keep up with the "virtual" position in the file. With the latter approach, it's interesting that the position in ASCII mode is different than the position in binary mode. But a file with mixed modes is a strange beast indeed, I would think. If there is any Squeak binary data in a file, then the whole file may as well be considered a binary file, yes? Lex > -- Dwight > > Lex Spoon wrote: > > > > If a file has a CRLF pair in it, and CrLfFileStream converts that to a CR, then the idea of "position" gets messed up. It looks like 1 character, but "file position" will act like 2 characters have gone by. For CrLfFileStream to go the final mile, it should probably have some code to make positions truly transparent to the user. > > > > Other than that, CrLfFileStream seems very nice. I've been using it as the default for several months now and found it nothing but convenient. > > > > Lex > > > > "Pennell" <pennell(a)tiac.net> wrote: > > > Dan - thanks for adding this in 2.2. Is there any reason not to make this > > > the default? > > > If you don't change the default for 2.2, can you add it as a preference? > > > > > > - david

2 1

XRe: Structure of objects and execution (with effects on visual programming, and reversible debugging, )
by R. A. Harmon 25 Oct '98

25 Oct '98

I think editing the parse tree idea is a good one. At 07:26 PM 10/24/98 -0500, Dwight Hughes wrote: [snip] >On comments: if comments were considered as a peculiar type of language >construct rather than just another form of whitespace, then it could be >inserted into the tree along with the rest of the nodes; the >CommentNodes could act as placeholders and be placed at the proper >position in the tree for source reconstruction. [snip] I've always thought of comments as like Post-It notes -- select the code they apply to (decorate?). For twenty years I've wondered why humans have to insure that the syntax in a whole bunch of code is correct and then give it to the compiler so it can tell you that you got it wrong. I've wanted a smart editor that will present me with a list of possible next things, and then let me select the one I want. I wouldn't have to go looking around for how I spelled a variable or class name, or forget a bracket or period. Computers seem much better at "remembering" large bunches of stuff than humans. As a COBOL programmer the only time I typed in a new program was when I moved to a new job. I'd type the first one and then copy it until I left. I never could remember the right format of all those sections. I also want an auxiliary project dictionary (or something) like the auxiliary document dictionary in WordPerfect. When I work on my novel then spell check it, the auxiliary dictionary has all my character names and other words unique to my novel. I don't have to tell the spell-checker to ignore them. Coupled with the smart editor above, when I ask for the list of possible next things, if a variable is appropriate, a list of from project auxiliary dictionary is one of the items I can select. I've wonder nearly twenty years why the parse tree wasn't kept and edited. Seems it would make lots of things easier on us humans--searching where a variable is used or a function called, etc. On the mainframe editor, I always had trouble remembering what the three letter commands were. It seems like programmers and their tools are like the cobbler's children and their shoes--everybody else comes first. Keeping and editing source code seems analogous to keeping and editing a text file to maintain you database data--a tedious and error-prone method. I really think information about a project or program should be in the source and have full text formatting capabilities. Smalltalk source poses an interesting problem in that the development environment would be HUGE if this were done, but I think fast and efficient storage out of ram might be found. One of the reasons I chose Squeak was that it had text formatting capabilities built in. Now, who has the email address of the Programmer's Tool Faerie, or all you folks keeping that close to you chest along with that of the Languange Faerie? -- Richard A. Harmon "The only good zombie is a dead zombie" harmonra(a)webname.com E. G. McCarthy

1 0

Re: Morphic halos in Windows?
by lex＠cc.gatech.edu 25 Oct '98

25 Oct '98

Andreas Raab <raab(a)isgnw.CS.Uni-Magdeburg.De> wrote: > Folks, > > As a general rule I heavily recommend using 3 button mouses - it makes > life much easier if you're in a Smalltalk system and it isn't *that* > expensive. Yeah, like < $10 if you go to an el-cheapo store and avoid the ergonometric mice. I find it fairly amazing that people pay $80+ just to get a few extra bumps and curves on their mouse. Apparently people do, though, because in fancier stores you can't even *find* cheap 3-button mice. Once, an el-cheapo store-owner even *gave* me a 3-button mouse, just to get me out of his store; the profit wasn't worthwhile to even bother going through the motions of selling me the thing. Lex

1 0

Convolution kernels
by Russell A.Shotts 25 Oct '98

25 Oct '98

Hi- Can anyone provide pointers to graphics and image processing related code in Smalltalk? My immediate need is support for covolution kernels, but anything would be a welcome addition to the toolbox. Thanks. _______________________________________ Russ Shotts -- rshotts(a)usinternet.com

1 0

Wavelet Analysis in Smalltalk?
by Dan Ingalls 25 Oct '98

25 Oct '98

Folks - I took a run at this once before, but didn't get very far due to time constraints. This time I'm determined to complete the project. I want to find forward and inverse fast wavelet transforms written in Smalltalk, or written clearly enough in some other language that they are easy to transcribe. A possible better alternative would be to find code for a wavelet packet transform that would subsume these, and provide a further facility for choosing optimum wavelet bases for a given data domain. My intention is to make a wavelet analysis package available in Squeak, and thus to the Smalltalk community generally, so any help in this direction would benefit many people. Thanks in advance for any help you can give. - Dan

1 0

de-precompilation...
by michal starke 24 Oct '98

24 Oct '98

hi! is there any easy/standard way of: (i) telling whether a given MessageNode is precompiled (i thought special>0 would do that, but apparently that's true even in some non-precompiled cases) (ii) reconstructing the non-precompiled version if it is precompiled? thanks, michal

1 0

Re: Re[8]: Does Squeak include a generic node class?
by Les Tyrrell 24 Oct '98

24 Oct '98

re: aspect-oriented programming It's been a few years since I looked at this, I'll have to refresh my memory on it. There my be some good similarities in it. The motivation came from the things I saw when I had run my analysis tools on various classes... a recognition that certain "patterns" appeared over and over again. Perhaps an important point: 1) In Smalltalk, we can only interact with objects by sending them messages. 2) We do not know that a message will be understood, but we do expect it to be understood. 3) The result of a message send, if it is understood, is always an object. (3) is actually rather important. It allows one to create objects as results of message sends, and then send messages to those objects... newThing := ( someObject hasPropertyX ) ifTrue: [ someObject propertyX ] ifFalse: [ someObject differentResult ]. How many objects are there? At first glance, maybe one... someObject. But this is wrong... there are a lot of objects here, much more than what I was used to thinking about... < someObject > < someObject hasPropertyX > < someObject propertyX > < someObject differentResult > < ( someObject hasPropertyX ) ifTrue: [ someObject propertyX ] ifFalse: [ someObject differentResult ] > We could also include < newThing >, even though it is a variable that does not itself result from a message send ( assignment is a bit different ). Each of these things is an object. And out of this list, we see that we send messages only to some, while the rest are more or less passive ( we build them, but do not interact with them other than to toss them around ). < someObject > hasPropertyX propertyX differentResult < ( someObject hasPropertyX ) > ifTrue:ifFalse: These sets of messages represent portions of an expectation signature... these are messages we think we can send to these objects. So that is the sort of thing I was doing when I was thinking about these patterns... the one above is similar to a very common one, but we see that due to condition (3) there are actually many variations of this one... since the pattern is object based, not variable based, and objects could be obtained in many ways. This sort of analysis generates a huge amount of information, much greater than the original source code. So... when I was thinking of patterns, I was motivated by the recognition that there were things occurring over and over, and it would be great if there were some way of automatically recognizing them and saying something like 'type x lazy instantiation of y' rather than the horde of information I was seeing. And then, if it were possible to recognize these things, then it would also be possible to use them in synthesis as well as analysis, so that they would become first-class building blocks, parameterized or whatever to match the particular case in question. That's basically it... but a great deal of work remains to be done to make it useful. les

1 0

Re: Structure of objects and execution (with effects on visual programming, and reversible debugging, )
by Les Tyrrell 24 Oct '98

24 Oct '98

Actually, I believe we already have a somewhat compact representation of the parse tree in the compiled methods- unless you need to guarantee uniqueness of a particular parse tree in multiple, disparate uses it is probably sufficient to regenerate it from the compiled method. That being done, then I am definitely in the camp that the Parse trees have been neglected, and that in particular the parse tree enumerators are very powerful tools. I'm willing to write enumerators for Squeak, and actually have started on this. It shouldn't take much effort. In my case, I want to write software analysis tools to enable me to determine what batches of messages are being sent to various entities... with a parse tree enumerator, this is trivial- walk the tree, gather the message sends, note to which objects the messages are sent. There is a whole heapin' horde of information available to tools like that. And in systems like VisualWorks and Squeak, it's easy to build those tools. The biggest problem is dealing with the sheer mass of analysis results. I've written a pretty formatter for VisualWorks before... so I am aware of the various problems that crop up, such as the displacement of the comments ( or loss ) and the ambiguity in determining just which statement a comment actually belongs to ( the VisualWorks belief is actually that the commment comes AFTER the statement, whereas most people appear to put them before the statement ). It would not surprise me to see similar behavior in Squeak. The biggest hurdles deal with comments ( where do they REALLY belong ) and parser optimizations ( what you get isn't what you wrote, but better ). If people don't mind the parser rewriting their code ( as long as it is correct ) then there really isn't much of a problem. So here is my list of things that I either know or think a parse tree enumerator could do: 1) create alternate representations of your code... 1) text ( formatted ) 2) graphical ( such as Randy Griffen's ) 2) analyse your code ( in lotso ways ) 3) generate the compiled method ? 4) generate the C translation nodes ? I'd be happy to pitch in on this, I've been through much of it before with VisualWorks. les

1 0

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

Jump to page: