Squeak-dev February 1999

squeak-dev@lists.squeakfoundation.org

148 participants
356 discussions

RE: Squeak in IEEE Software
by Peter Crowther 02 Feb '99

02 Feb '99

[Dan Ingalls] > However it is simple to state the ideal: every fundamental relationship > or process should only be described in one place. To the extent that > something appears in N places, there are N times as many chances to get it > wrong one way or another. > .... including debugging. N copies of code means N different times finding the same bug, as you *always* forget to update your other versions. It's one of my pet peeves about strongly typed languages such as C++; even with templates, there are times when you have to write subtly different versions of the same code to handle different derived classes. And I'm not going to say *anything* about Visual Basic, as I'd like to keep my Microsoft certifications... > The lines of code thing is just plain confusing. Generally less is > better, and I just don't think you cn compare systems this way. > Unfortunately, people *do* compare systems this way and will continue to do so until at least twenty years after a better method of comparison is described. I last looked at the O-O metrics world three or four years ago, and there was no real agreement on what 'good' metrics were for O-O code. Does anyone know whether there's any more agreement? How do you measure 'progress' in projects written in O-O languages? How does a non-technical manager know whether his/her developers are on target? - Peter

1 0

Problem with colors.
by Francisco A. Lizarralde 02 Feb '99

02 Feb '99

Hi ! When I try this code to draw a Quadrangle filled with a transparent color, it draws filled with a white color. " q := Quadrangle origin: ( aView displayTransform: (30@30)) corner: (aView displayTransform: (70@70)). q insideColor: Color transparent." but when I put "q insideColor: nil", it works. Later I tried to do the same with "borderColor" but it doesn't work. Could anybody tell me what am I doing wrong ? Thanks in advance. Francisco.

1 0

Re[3]: Squeak in IEEE Software
by Jerome.Garcia＠wj.com 02 Feb '99

02 Feb '99

At 2/1/99 11:05 PM John Brant wrote: > A good percentage of the code could be recognized. There would probably be 3-4 common ways of doing it that would catch 95% of all cases. The Smalllint tool from the Refactoring Browser doesn't catch the case above (since #streamContents: doesn't exist in VA or VW), but it catches many other ones: using do: instead of #collect: or #select:, using #whileTrue: instead of #to:do:, using #ifTrue:ifFalse: instead of #min: or #max:, etc. Overall, there are over 60 different checks that Smalllint performs and many of them are the "grammar" type checks as above. The complete list of checks is at: http://st-www.cs.uiuc.edu/~brant/RefactoringBrowser/LintChecks.html > Thanks for the pointer to LintChecks and the good news. It seems one should then be able to extend such a tool to provide suggestions for the naive. When writing code, it would be nice to be able to get a popup menu or something that would lead me right to the sample of code that I need at the moment. I am thinking of something like an interactive version of an identification key such as the great one in "All That the Rain Promises, and More ... : A Hip Pocket Guide to Western Mushrooms" by David Arora. I mention it simply because it makes a sometimes difficult search process so much easier. Jerome

1 0

Re[2]: Squeak in IEEE Software
by John Brant 02 Feb '99

02 Feb '99

At 01:12 PM 2/1/99 -0800, Jerome Garcia wrote: >On Mon, 1 Feb 1999, Dan Ingalls wrote: > >> The lines of code thing is just plain confusing. Generally less is >> better, and I just don't think you cn compare systems this way. >> Consider... >> >> | strm | >> strm := WriteStream new on: (String new: 10). >> tempNames do: [:n | strm nextPutAll: n; space]. >> tempStr := strm contents. >> versus... >> tempStr := String streamContents: >> [:strm | tempNames do: [:n | strm nextPutAll: n; space]]. >> > These lines of code and Jake Hamby's response remind me of the many > times over the past thirty years when I was learning an new language > or environment and wished that I could put the development tool in > "nag" mode. When I wrote the first set, it would say "Nonsense. That > is crummy code. Do it like this...". Sort of like a grammer checker. > Of course, I would like to be able to tell it where to go if I didn't > agree :-) > > Much of the poor code I seen has been the result of someone working > under a tight deadline, remembering how they did something in a > previous language, and doing it the same way because they did not have > time to discover how to do it correctly. I may be naive in thinking > that it should be possible for a development environment to give > active guidance but I would still like to see it happen. Does anyone > happen to have a good guess as to in what percentage of code snippets > such as the above it would be possible to programmatically recognize > that the first is equivalent to the second and recomend the second? A good percentage of the code could be recognized. There would probably be 3-4 common ways of doing it that would catch 95% of all cases. The Smalllint tool from the Refactoring Browser doesn't catch the case above (since #streamContents: doesn't exist in VA or VW), but it catches many other ones: using do: instead of #collect: or #select:, using #whileTrue: instead of #to:do:, using #ifTrue:ifFalse: instead of #min: or #max:, etc. Overall, there are over 60 different checks that Smalllint performs and many of them are the "grammar" type checks as above. The complete list of checks is at: http://st-www.cs.uiuc.edu/~brant/RefactoringBrowser/LintChecks.html Adding new checks to Smalllint is relatively easy. Many times it just requires writing some pseudo Smalltalk that matches some real Smalltalk code. For example, one of the pseudo Smalltalk code snippets for detecting when someone is using a whileTrue: instead of to:do: is: | `@temps | `@.Statements1. [`index <= `@stop] whileTrue: [| `@BlockTemps | `@.BlockStatements. `index := `index + 1]. `@.Statements2 There are three other possibilities that it uses for the rule. As far as the usefulness of such a system; I find Smalllint very useful. Even though I've been working in Smalltalk for several years now, I still write stupid code (although less frequently :)). The biggest problem with these "grammar" checkers is that as you become better the hit-to-miss ratio gets too low and most people stop using them. John Brant

1 0

Windows MIDI utilizes software MIDI, not Mac
by Mark Guzdial 01 Feb '99

01 Feb '99

Some of us have been playing with Squeak MIDI here, and a Windows user was saying that he gets great MIDI quality "by choosing the third menu item" when MIDIPort requests from user the right port. Third menu item? On my Mac, I can only choose which serial port that I might have a hardware synthesizer on. So, I tried Virtual PC. In Windows Squeak, I also get the option of SoundBlaster MIDI, or Yamaha MIDI, or whatever other software synthesizers that are available. It sounds great! The Mac has such a software MIDI synthesizer built-in, available through QuickTime. Is it possible to be able to access it the same way that Windows Squeakers can access their software synthesizer? I'm trying to dig through the Sources and the QuickTime docs (http://developer.apple.com/techpubs/quicktime/qtdevdocs/REF/tp_qtma_aboutqt… tm#22202) but I'm not quite grokking it. Thanks for any tips! Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

1 0

FileStream
by David Farber 01 Feb '99

01 Feb '99

if i try to open a FileStream on a file that is not in the local directory, the open fails. i.e. FileStream fileNamed: 'email\mbox1.txt' returns nil. (the folder émail' exists; 'mbox1.txt' does not and i want it to be created). if this is appropriate behaviour, what do i need to do to open a FileStream on a file that is not in the local directory? what about the case where neither the path nor the file exists and i want to create both? thanks, dave -- j. david farber oo architect+mentor numenor labs incorporated in sunny boulder colorado dfarber(a)numenor.com www.numenor.com

3 2

Re: Help - MW.zip entry garbled
by Leandro Caniglia 01 Feb '99

01 Feb '99

>try > >http://www.sugarweb.com/Miniatures/files/Morphic/MorphicWrappers.zip Stop! That wasn't the same last "official" version of MW for 2.3. I've just uploaded a copy of the MW.zip package from MathMorphs to SugarWeb under the name MorphicWrappers.zip (i.e., same location and name as above). Please, consider downloading them again. Saludos, Leandro PS: This is our MW "documentation" MW installation guide: - Extract the archive in your Squeak directory - From the file list, file in 'MW-fileMeIn2.3.cs' - After installation, use the "update code from server" menu item and save your image. Getting started with MW We have not a MW documentation other than the two lessons for the EventRecorderMorph. Basically the MWs are very simple. The main features are: 1. Writing on the air facility + When a MW is in focus, self is the wrapped object + Up and down arrows run on the history of typing + There is one history thread by each of the classes of the wrapped objects + A final period $. prevents the result to be grabbed to the hand. Example: ellipse color: Color red. <enter> "with final $." is different from ellipse color: Color red <enter> "without final $." + When no MW is in focus, self is the World 2. Deleting MWs + Backspace remove the MW in focus (if any) 3. Naming + You can name a MW placing the hand on it and writing: name _ self<enter> + You can name a nonMW morph from the talk to me option of the red halo 4. Double clicking menu + Selecting a method, sends the wrapped object the corresponding message 5. Dropping arguments + By dragging and dropping one or more MW on a given MW, they are saved as arguments and showed as satellites. + The double click menu shows the messages with the same number of args as those dropped on the wrapper. + Once you have sent a message, the arguments will remain a few seconds and then disappear 6. Changing the wrapper + SimpleMorphicWrappers and BitmappedMorphicWrappers can wrap any object. + Dropping an ImageMorph or a ScketchMorph over a BMW changes the picture. + If you have a graphic file (.bmp, gif, etc) in the Squeak directory with the name of a class, then the BMW for objects of that class will automatically use that graph. + Instances of Form use BMW by default. + Classes and Metaclasses can use ClassMorphicWrappers (in fact they use them by default) + You can add new special wrappers for the classes you want 7. Programming with MW + Edit methods with ClassMorphicWrappers. + Edit the method aClass|selector writing on the air: aClass | #selector <enter> or aClass >> #selector <enter> + Copy methods from a CMW to another by dragging and Shift+Dropping (then accept (s) the copy) + Move methods by dragging and Control+Shift+Dropping + Add inst vars, class vars, pools by dropping their names (symbols) on the target CMW + Change the category of a class, dropping the name of the category on the CMW (use a dash $- if the category is a new one) + Shift+Drop a CMW on another to make the former a subclass of the second (inst and class vars are handled as expected) Hope this helps. Leandro

1 0

STP12_2_3 on Windows
by Pennell's 01 Feb '99

01 Feb '99

Has anybody else downloaded the STP12 collection for Squeak 2.3 and run it on Windows? The image loads and seems to run, but the source pointers seem to be wacked. -david

2 1

RE: Squeak in IEEE Software
by Peter Crowther 01 Feb '99

01 Feb '99

> But lets not forget the community, > fun, hacker ethic component as well. The latter, more than the former, > drives > some of these movements. > Absolutely. I'd say the *majority* of the open source developments are driven this way. I'm working with multi-user environments because I enjoy the interaction they generate; I am writing my own because I enjoy the challenge; I am using Squeak because it is an infinitely malleable tool for the job [and I'll have to hack some of it into little tiny pieces to make it malleable enough]. On a not-totally-unrelated note, I think a large number of the open source developers would otherwise be artisans or craftspeople --- designers and builders. I craft programs, my father crafted computer hardware, my ancestors crafted furniture, pianos, maintained steam engines for ships and mill equipment... I don't see that there's necessarily any difference between a well-crafted piece of glassware or furniture and a well-crafted piece of software. - Peter

1 0

RE: Squeak in IEEE Software
by Kevin Fisher 01 Feb '99

01 Feb '99

On Mon, 01 Feb 1999, Peter Crowther wrote: >> >I have a different opinion: the problem is not the IS managers [the >technical ones, anyway], it's the finance departments and non-technical >managers who see a product that doesn't say 'Microsoft' on the box. >Nobody >ever got sacked for buying Microsoft --- it ain't IBM any more. > I have to agree heartily there. Wasn't there an article recently in some engineering magazine about how engineers and scientists are starting to revolt against the top-down institution of NT? I wish I could remember where that article was...very revealing. I think first heard about it on slashdot.org.. A good friend of mine who works for a large motor company is going through the pointy-headed-boss gauntlet right now. The company higher-ups (suit-and-tied types) are the ones who get to say what technology gets used in the company infrastructure....all Microsoft, surprise surprise. The techie types have said again and again that the NT based solutions they have are expensive and difficult to manage...they want to do it all under Linux because it is cheaper and more reliable. However the real surprise is that the higher-ups seem to be having a change of heart...they are now evaluating Linux, and looking into accepting it in the company infrastructure. >> >This is good. If you can get the same functionality into fewer lines of >code, you will have fewer defects --- by his own arguments. If, by >contrast, commercial UNIXes have c. 10M LOC, but only exercise the same >100k >LOC or so as Linux does, the reliability figures are comparable. Either >way, I disagree with his conclusions. Same here. Plus, the high LOC count in microsoft software certainly doesn't mean that they've gotten a handle on things either...our NT servers crash regularly while our Linux servers click on for months at a time, rarely (if ever) needing to be rebooted. Personally I have zero faith that Microsoft will ever get the bugs out of their software (especially with their habit of late of denying security holes and bugs...yikes). > >Commercial UNIXes are full of bloat that never gets used. Linux isn't >(yet). > True, but Linux also comes with lots of nice bloat-reducing features like kernel modules. Even if the featureset of Linux continues to grow you should still be able to pare the system down to just what you need, and have a nice lean and mean kernel...I can't say the same thing about NT (I just think about the size of NT 5 -er- WIndows 2000 and I shudder...) >> Lewis believes that as the programming tasks get more complex, >> only commercial programmers will be able to put in the time and >effort. >> >This is where re-use comes in. Problem is, you have to know what's out >there to re-use. I haven't found a central component store for open >source >software in the same way that there are indexed central sources for COM >components --- maybe I should create one. Anyone know where I should be >looking? > Hmm, I know this isn't exactly what you mean but you could search at freshmeat.net. But freshmeat is more of a 'what's new, what's just been released' type of site. There seem to be a LOT of CVS servers out there for all the respective Linux projects underway. Maybe a meta-catalogue of all the CVS servers would help get the ball rolling. >> >>From memory, but without references, several have looked at >well-designed >C++, and a couple have touched Smalltalk. Again, the advantage of >Smalltalk >and the other fine-grain O-O languages is fewer LOC to accomplish the >same >end; so, assuming the defect density is (at worst) no higher than with >conventional code, we get more reliable functionality. > >"Lies, damn lies and statistics". It's amazing what you can do to an >argument with a bit of thought and some statistical Ju-Jitsu :-). > > - Peter ohh, too much to think about this early on a monday morning... (what, it's noon already??) >-- >Peter Crowther, MCSE+I, MCSD, MCT, CCI, LLAHN

1 0

Jump to page: