Glyph Lefkowitz wrote:
> 
> Hi!
> 
> I'm new to Squeak, and to Smalltalk.  It seems like a very elegant platform
> for development, and Squeak's media stuff in particular is very interesting
> to me.  Kudos to the team that has been toiling for decades to make this
> happen, and to all those who have written tutorials, which I have been
> vociferously reading for the past few days ;).
> 
> Although the possibilities of the development environment seem vast, I'm
> confused by a few things.  I know that there are people working on some of
> these things, but trying to find working code has involved lots of broken
> links and blind alleys on the web, so here are my questions.
> 
> I realize this is probably still a thorny problem in Squeak, but I'm curious
> what the conventional approaches are to distribution.  I want to write an
> application which contains standard application-style stuff; and I would like
> to create both a "standalone" application that non-developers can use as well
> as something that can be loaded into a Squeak image so that fellow developers
> can use it without running multiple VMs at once.

I assume you've already looked at the Squeak FAQ item (on the Swiki) about building executables?  Granted, the FAQ item only partly answers your questions.  (See http://minnow.cc.gatech.edu/squeak/squeakFaq .)

> The two major issues I have are figuring out how to segregate my app from the
> rest of the system, and understanding what base system functionality is
> actually supported and what is just a temporal artifact.
> 
> Is there the notion of a change-sub-set somewhere?

No.  I agree that changesets as they are currently implemented are kind of inadequate for organizing a large application.  (I've often wanted to break up Whisker into sub-changesets myself, but I don't want people to have to file in several changesets as part of loading Whisker.)

Some people were working on addressing this issue by adding the concept of modules to Squeak.
See http://groups.yahoo.com/group/squeak/message/25779 and the followup replies.  Also, the Stable Squeak project addresses this somehow, but I'm not sure exactly how offhand.

(Actually, introducing the concept of sub-changesets might not be all *that* difficult... it's kind of tempting to try to put something together.  On the other hand, true modules which could be unloaded would be nicer still, so it may be better to just focus on that.)

> I would like to be able
> to file out changesets for other programmers working on the project (is there
> a better way to do collaborative development than just filing out changesets
> to each other?), and still have a final "this is everything I've done to the
> base image" changeset to distrubute when I'm done.
> 
> Is there a SqC "blessed" way to distribute apps that will eventually reach an
> end-user?

Not really... I think probably the closest thing to a blessed method for this is:  Take a fresh image, load your application changeset(s), and then run portions of majorShrink as appropriate until the image is down to a more reasonable size, with your application still successfully running.  Then distribute the vm/image bundle to end-users.

> The other problem that I'm having I don't know how to discover which pieces
> of squeak are going to change out from under me while I'm working.  Ideally,
> I'd like to write software that will last for 100 years, and still run on a
> relatively current and supported environment :) but failing that, I'd like to
> at least not do anything that will be stomped on in the next major version of
> Squeak.  The only significant application I've been able to get working in
> Squeak so far (whisker) seems highly sensitive to the order in which it is
> filed in with respect to other changesets (SyntaxHilighting.cs in
> particular), and breaks completely if I upgrade to 3.1alpha.  I'm not so much
> interested in burdening Squeak with bad assumptions I've gleaned from other
> environments, but I would like my code not to break all the time for reasons
> that I don't understand.  The in-code documentation is spotty, so what
> conventions should I follow?

There's not really any guaranteed way to ensure that your code will be forward-compatible with future versions of Squeak.  (Although that's true of most programming environments, but perhaps more true with Squeak than with others.  Squeak Central is changing/improving Squeak at a fairly rapid pace, relative to something like Python or Java.)

However, you can follow some rules to make it more likely that your code will work with future releases... for example, try to avoid replacing existing methods in the image with your own versions.  Also (of lesser importance), subclassing (from classes other than Object) in general will make your code more dependent on the superclass not changing, of course.  But this is a tradeoff, because you'll have to write more stuff from scratch if you try too hard to avoid inheritance.

As the author of Whisker, I tried to avoid replacing existing base image methods, but I think I'm still probably replacing 3 or 4 total.  Sometimes it just saves too much work to completely avoid this... in these cases I'd rather deal with having one or two things break as Squeak moves forward, than have to write and maintain a bunch of additional code myself to work around a problem.  I'm also subclassing the hierarchy widgets, so Whisker is a bit sensitive to base image changes in that area.  (This is what changed recently in 3.1alpha to make it incompatible... update 3850 (event handling in list morphs), actually.  Hey, Whisker did make it through 350 updates in 3.1alpha before hitting a problem. :) )

Updating Whisker to work with new Squeak versions hasn't been too big a deal... there's often a few tweaks which need to be made.  One thing I should do more often is to refactor things in the base image so that my code depends on it less, and then post the refactorings to the list for inclusion.

Also, to be fair, you shouldn't really expect things to work perfectly in an alpha release.  You normally shouldn't use 3.1alpha unless you're contributing fixes/enhancements to the base image, or if you really want to play around with something that was recently released.

> Finally, the user interface is really a big hurdle to clear; I can deal with
> the different look, or even the chunky performance, but I can't switch or
> close windows with a keystroke, just about every browse it/implementors of
> it/senders of it/references to it(etc) operation spawns a new window.  Are
> there any changesets that address some of those workflow-streamlining issues?
> Or give me emacs-style keybindings in the editor? ^_^ I saw a lengthy rant on
> the wiki, but again, no code to accompany it.

There have been discussions in the past about adding keyboard controls for more things.  Someone created an alt-tab like goodie for bringing up windows awhile back.  The other key item would be keyboard support for shifting window pane focus.  There is an existing method (ParagraphEditor class>>initializeCmdKeyShortcuts) for customizing key bindings to be emacs-like, already.

As for workflow-streamlining, Whisker attempts to address that somewhat, but there's still a lot more that it could do. :)

> Thanks for any comments, and I look forward to hacking in this exciting and
> powerful (yet alien) environment! :)

Welcome aboard,

- Doug Way
  dway at riskmetrics.com