Squeak-dev January 1999

squeak-dev@lists.squeakfoundation.org

143 participants
293 discussions

Generating class listings with class comments?
by wirth＠almaden.ibm.com 26 Jan '99

26 Jan '99

Seems to me I saw a recent msg to this list that provided some code for generating class hierarchies that contained the class comments (which would be very useful, e.g., in learning Morphic :-). But I can't find the message now (by simple keyword searches). Did I imagine that? Suppose I could just write it myself... (Note to Ted K: Have your online documentation tools gotten anywhere yet?) Mike Wirth

1 0

minneStore port
by Andrzej Turowski 26 Jan '99

26 Jan '99

Hi, My first pass at porting minneStore (with the help of Monty Kamath) is available at: http://www.turowski.com/minneStore.zip There are a couple of hacks in the code (FlavorCompatibility) right now but it works. We will be cleaning up the FlavorCompatibility code a bit this weekend. Cheers, Andrzej

3 2

Re: Benchmarks for Comparing Squeak Builds
by johnm＠wdi.disney.com 26 Jan '99

26 Jan '99

Interesting results; thanks for posting them! Note that the Squeak 2.3 VM is noticably faster than 2.2. But Ian's new Jitter should eventually make that gain look like peanuts. I wonder why Squeak does so poorly on Puzzle? Could you send me the source code for that one? Thanks! -- John

1 0

RE: Morphic, dataflow and encapsulation
by Joseph Whitesell 25 Jan '99

25 Jan '99

You might also peruse the "Is building software with highly visual development tools any easier or just confusing?" thread on comp.lang.smalltalk. A good spot to look at is Mike Silverstein's 12/04/98 post. I hope he doesn't mind if I quote him here: "...I agree completely. We have found that visual programming with connections works well as long as you limit their use to defining simple notification and dependency relationships. As a general rule of thumb, you have gone too far with VA connections if their usage starts to smell like logic, firing order starts to really matter, or you intend to use inheritance for adding or altering relationships." Joe Whitesell ---- I'd be interested in hearing the evidence supporting the case for visual programming representations. I agree with Ralph that the burden of proof is on the proponents, but of the evidence that I've read, it seems to me that a stronger statement can be made: That visual programming is as hard or harder than textual programming. ------ <references annotation=true> First, there's the work by Marion Petre (replicated by Tom Moher) that shows that even "experts" at visual programming environments are actually much better at textual programming languages: Petre, M., & Green, T. R. G. (1990, ). Where to draw the line with text: Some claims by logic designers about graphics in notation. Paper presented at the INTERACT'90, Cambridge, England, 27-31 August. Moher, T. G., Mak, D. C., Blumenthal, B., & Leventhal, L. M. (1993). Comparing the comprehensibility of textual and graphical programs: The case for Petri Nets. In C. R. Cook, J. C. Scholtz, & J. C. Spohrer (Eds.), Empirical Studies of Programmers: Fifth Workshop . Norwood, NJ: Ablex. She has gone on to do a nice analysis suggesting that visual forms are just as hard to deal with as textual forms. Petre, M., & Green, T. R. G. (1993). Learning to read graphics: Some evidence that 'seeing' an information display is an acquired skill. Journal of Visual Languages and Computing, 4, 55-70. There's the more recent work on KidSim/Cocoa which showed that students have all the same problems programming in textual forms as they do in visual rules. (Clayton Lewis at CHI96 or CHI7 -- I don't have the reference here.) Finally, there's all the work on algorithm animations which, thus far, has not shown any learning benefits. Stasko, J. T., Badre, A., & Lewis, C. (1993). Do algorithm animations assist learning? An empirical study and analysis, Proceedings of INTERCHI'93 (pp. 61-66). Amsterdam, The Netherlands: ACM. </references) ------------ Does anyone know of any evidence that supports the benefit of visual representations for programs? I'm not saying that there are no benefits of visual representations. The challenge is figuring out what those benefits are. Mark At 2:20 PM -0600 1/25/99, Ralph E. Johnson wrote: >At 3:56 AM 1/25/99, Hrefna "GumundsdÛttir" wrote: >>On Saturday, January 23, 1999 6:56 PM, Andrew C. Greenberg >>> I'd be pleased to be educated to the contrary, but it seems to me that >>> Jen's suggestion that graphics are always better for "really large" >>> programs, indeed, even "always good" for large programs need not always >>be >>> the case. >> >>It may a bit 'strong' to say that graphics are 'always good', but can you >>point out an area where this does not hold? > >You have it backward. People have been saying for decades that >visual representations for programs are essential. The proponents >of VPLs and CASE tools make similar arguments. UML is the latest >example. However, there is NOT ONE EXAMPLE of a system that delivers >on its promises. Very specialized systems like Stella or GUI builders >are certainly useful, and general purpose systems like LabView are >good for non programmers. AVL is a nice system, but it has problems, >and I bet I could make a better system in Smalltalk that was text-based. >Andy's point was that, as a programmer, he had yet to find a system that >was as fast and powerful for him as textual programming.

1 0

Re: Morphic, dataflow and encapsulation
by Bruce Cohen 25 Jan '99

25 Jan '99

Hrefna "GumundsdÛttir" <hrefnag(a)mmedia.is> wrote: >> But a visual representation gives you the needed overview if the system >> large. You would make relatively low-level components by programming >> textually, but the wiring them together visually. To make this possible you >> have to have a good dataflow model. That's what I'm hoping to find in >> Fabric. I would say that all our programming efforts boil down to data >> manipulation so we need a direct way to visualize this, else we lose track >> of what we have accomplished or are trying to do when the system gets >> really large. I don't entirely agree that "all our programming efforts boil down to data manipulation", since this ignores programming for embedded and other systems whose job is to react to input stimuli with some action. Yes, you could couch this as data manipulation by saying the task is to transform input data into output data, but I suspect that view is not a very effective way to reason about reactive systems. In general, I agree that a dataflow model of programming is very useful, and a tool that presents it visually can be both useful and fun to use. But I'd caution against thinking of it as a panacea for the problems of developing complex or large-scale systems. We have some experience with visual programming tools here at GemStone; we shipped a commercial tool called GeODE running in our Smalltalk VM for a number of years. My own experience with GeODE was very positive; it allowed me to build up some useful tools, and to debug applications in fairly complex client-server architectures. And I've no question that it was a godsend for many of our customers (you should have heard the howls from them when the product was discontinued), but by the end it had used up the efforts of four engineers over 2-3 years, and it was still not a complete tool, but more of an advanced prototype. And in the process, we found we had to provide nearly equal support for three different programming models: visual dataflow graph wiring, textual event-script programming, and traditional class-based Smalltalk programming, and these three models had to be rather tightly integrated so you could build a complete application out of pieces developed in any of the models. >From what I've seen so far of Morphic (disclaimer: I've only spent a few hours playing with it so far), it has potential to surpass GeODE in the long term, but doing so will take considerable effort, because this is a large problem domain. Some of the things I think are very promisinmg are: Explicit support of a generic scripting model Relatively easy ways to extend the Morphic tools Easy access to standard Smalltalk programming from the Morphic tools A good start at an integrated debugging environment ----------------------------------------------------------------------------- Engineering is never having to say you're finished. ----------------------------------------------------------------------------- Bruce Cohen, | email: cohenb(a)gemstone.com GemStone Systems, Inc. | phone: (503)533-3602 20575 NW Von Neumann Drive | fax: (503)629-8556 Beaverton, OR USA 97006 | web: http://www.gemstone.com

1 0

my thoughts on a clean build
by merlyn＠stonehenge.com 25 Jan '99

25 Jan '99

So, if a person from another planet was given just a working VM and the Squeak.sources file, how much would they be missing? Is there anyway to ask the image? :) -- Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095 Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying Email: <merlyn(a)stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn(a)teleport.com) Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A> Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

3 2

Embedding Sound in SqueakPages books
by Mark Guzdial 25 Jan '99

25 Jan '99

If you modify RecordingControlsMorph>>makeTile so that newStyleTile is false (see below), tiles made with RecordingControlsMorph actually CONTAIN their sound, rather than simply refer to them by name. These tiles (InterimSoundMorphs, as opposed to SoundTiles) can be dragged into SqueakPages and saved -- and the sound is saved with them! See the second page of the Welcome book at http://minnow.cc.gatech.edu/squeakpages.1 The InterimSoundMorphs also work with the SoundSequencerMorph that Dan and John demoed at OOPSLA'97. Mark makeTile | newStyleTile sndName tile | recorder pause. newStyleTile _ false. "Change is here" newStyleTile ifTrue: [ sndName _ FillInTheBlank request: 'Please enter a name this sound' initialAnswer: 'sound'. sndName isEmpty ifTrue: [^ self]. sndName _ SampledSound unusedSoundNameLike: sndName. SampledSound addLibrarySoundNamed: sndName samples: recorder condensedSamples samplingRate: recorder samplingRate. tile _ SoundTile new literal: sndName] ifFalse: [ tile _ InterimSoundMorph new sound: (SampledSound samples: recorder condensedSamples samplingRate: recorder samplingRate)]. self world hands first attachMorph: tile. -------------------------- 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

re: headless version for Unix
by Lex Spoon 25 Jan '99

25 Jan '99

Miles Fidelman <mfidelman(a)ntcorp.com> wrote: > Thanks Georg, > > > >So... I was wondering if anybody has tried any kind of headless port to > > >the Unix environment. > > > > Compile with -DHEADLESS and you are set. For further information go to > > http://macos.tuwien.ac.at:9009/Server.home and search for "headless". > > The archive was very helpful, but raised another question: is there an > easy way to configure a headless Squeak to startup taking commands from > stdin and writing a transcript to stdout? > For the executing commands part, there are three main ways: 1) add code to SystemDictionary>>processStartUpList. The code will execute when the image starts. (and also after a snapshot....) 2) from a workspace, execute something like the following (be sure to highlight the whole thing before hitting "do-it"): Smalltalk snapshot: true andQuit: true. myObject doMyStuff. 3) add a small hook to SystemDictionary>>processStartUpList such that, if a filename is specified on Squeak's command line, then file in the specified file. For output, many systems will let you access stdout as a special file like /dev/stdout. If that's not available on your particular Unix, you can still write to a file and do a "tail -f" on it. Overall, Squeak seems good at executing arbitrary smalltalk code, but it doesn't play so well as a generic Unix utility because of its inability to use stdin and stdout. Lex

2 1

problems building 2.2, 2.3beta under Solaris 2.6
by Miles Fidelman 25 Jan '99

25 Jan '99

I just tried to build both 2.2. and 2.3beta under Solaris 2.6. In both cases, the builds quit somewhere in the middle with undefined symbol errors. Any thoughts on how to proceed with porting to 2.6 (I'm not much of a C person - most of my coding days were spent in assembler and higher-level languages). Thanks, Miles Fidelman

5 5

RE: Morphic, dataflow and encapsulation
by Hrefna "GumundsdÛttir" 25 Jan '99

25 Jan '99

On Saturday, January 23, 1999 6:56 PM, Andrew C. Greenberg [SMTP:werdna@gate.net] wrote: > > But a visual representation gives you the needed overview if the system > > large. You would make relatively low-level components by programming > > textually, but the wiring them together visually. To make this possible you > > have to have a good dataflow model. That's what I'm hoping to find in > > Fabric. I would say that all our programming efforts boil down to data > > manipulation so we need a direct way to visualize this, else we lose track > > of what we have accomplished or are trying to do when the system gets > > really large. > > Is this really true for "really large" systems? My experience with > so-called graphic or visual programs is almost exactly the opposite -- they > make short work (with some costs) for putting programs "in-the-small" > together, but as you grow the world, direct manipulation becomes a painful > burden and What-You-See-Is-All-You-Get seems to take over. I take it that you are referring to Visual Programming Languages (VPL). That's not what I had in mind. VPLs do have scaling problems in some current implementations, but I was thinking about visual data manipulation, i.e. visually manipulating the flow of data between components. It could be argued that this approach has the same scaling problems as the VPLs but I firmly believe that it is possible to represent the information in a useful and productive manner, both for small and large systems. Some of the problems VPLs have had is the lack of screen real estate, clear representation of logic and how to document the code. I feel that VPLs are taking the visual representation to a too low a level. Textual programming is fine for low level components but when it comes to assembling them together (perhaps into larger components), I would think that a visual approach would be of great help. > > I am reminded of early implementations of the game, Empire. This is a > wonderful, visual world with lovely tactical displays early on. As the > "empire" becomes more complex, however, playing the game at a tactical > level becomes onerous and coneptually unmanageable. Of course, shifting to > strategical views is a valid game-design solution to keep games fun, but > what when the TACTICS are important to the overall product, as in a > computer program. > > On the other hand, I have always had confidence that I can easily automate > programming processes as systems grow, when the programs are text-based. Could you do this 'easily'? > > I'd be pleased to be educated to the contrary, but it seems to me that > Jen's suggestion that graphics are always better for "really large" > programs, indeed, even "always good" for large programs need not always be > the case. It may a bit 'strong' to say that graphics are 'always good', but can you point out an area where this does not hold? > > What is beautiful about text is that it can embody an amazing amount of > semantic information in a concise fashion. I hated losing that as we moved > toward early GUI OS systems, and have been gratified as scripting GUIs > became recognized as critically important to their utility. The hybrid > approach (scripting atop graphic-representations atop meat-and-potato-code) > seems to me in many ways more flexible than the "graphics" v. "text" > ideological debate. I partly agree. Much of the semantic information would be in the components (which could be programmed textually). You just need to know what a component needs for input to produce your desired output. You really don't need to know how it does it. What I feel is missing in the current hybrid approach is a clear way of showing _how_ the information flows. It's not easy to get this knowledge by looking at a (long, perhaps complex) script. If you had a visual representation of this you would just have to glance at it and you would know what kind of information is flowing where.

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
30
Older →

Jump to page: