SqueakMap 5:th release!

squeak-dev at lists.squeakfoundation.org squeak-dev at lists.squeakfoundation.org
Sat Oct 5 13:58:29 UTC 2002


Okay, I just posted the latest version as described in the email. I also
posted a change to make the World>open menu dynamic. This is important
so that package can add themselves there.

I posted these as ENH, and would really like people to test them - as
far as I know, they're in good enough shape to be added into the 3.2
update stream - I've tested loading them into a fresh 4956 + SqueakMap
release 5 (don't forget it's included fix), and everything loads find
(and even unloads fine...)

BTW, Goran, it'll be easier for people to test things if you could could
make two separate one file releases for the model and the browser... 

Daniel Vainsencher

danielv at netvision.net.il wrote:
> goran.hultgren at bluefish.se wrote:
> > Hmmm. I agree about the problem - I also noticed the problem but
> > "ignored" it to give it more thought.
> I also use that tactic... problem with it is it looks like dirty socks
> from the outside... ;-)
> 
> > > This also makes versionLabels less meaningful. Currently, for JDepper,
> > > #versionLable -> (->) if it is uninstalled. It would be better if there
> > > was always something on the right, and always something on the left if
> > > the package is installed. Which would automatically happen if time
> > > stamps were used when needed.
> > 
> > Yes, but the problem I have with stamps is that just correcting a
> > spelling mistake in a registration would trigger a "new version". I
> > don't like that. 
> Hmm, only if the author never bothers to version his stuff. Sounds fair
> enough to me - the current behavior means that the unversioned package
> will never be upgradable. I prefer too many updates to none. Don't like
> machines second-guessing you? then just version your stuff :-)
> 
> And it's simple ...
> 
> > SqueakMap copy the
> > documentpart of the download url (before known extensions) automatically
> > into the version field.
> That sounds like a reasonable heuristic, though that too will sometime
> not yield version information (I'll be filing out logical module, which
> are slightly extended System Categories, and don't version fileouts
> (though maybe they should)).
>  
> > So, when you register a package you could use an url like:
> > 
> > ftp://yaddayadda/dir/mycoolthing.1.cs.gz
> > 
> > ...and if you check "Use download filename as version name" then the
> > version field would become "mycoolthing.1".
> > 
> > And then make the version field mandatory of course. What do you say? I
> > think this is good - having an undisputed version field is probably a
> > good thing as long as people don't find it annoying to update it. This
> > way it is simple even for very small packages like single small
> > changesets.
> With this I agree, time stamps are just another way to get those.
>  
> > > Probably the time stamps should be quite short, though, or it'll make a
> > > mess. (04aug02 is pretty complete, unambigous on both sides sides of the
> > > atlantic, and pretty short).
> > How about then having a third checkbox. No, wait. Let's make it a three
> > choice radio button instead! :-)
> Ahhhh!!!! Nooooo!!! no more war, no more check boxes ;-) Please, let's
> stick with something that doesn't require the user to do anything.
> Especially not to make decisions. I'll settle for "version, or else I'll
> use your file version field, or else your timestamp". Sounds like that
> will do something intelligent no matter how little the user cares...
> 
> > > About the installers and handling of existing changesets - 
> > > a. It would be nice to have the option of reusing the same changeset (by
> > > leaving the name unchanged).
> > 
> > Do you mean when an install of a cs clashes with an existing cs of same
> > name?
> > So are you proposing to install the cs "into" the existing one? Explain
> > further, please.
> Yes, exactly. This should not be a silent default, but it should be
> possible, by leaving the same name.
> 
> > >A decorator could be used to set policy without knowing about the
> > > exception.
> > I will look into that. Could you elaborate on that last sentence?
> (Hmm, assuming probably some but not everyone knows what a Decorator
> is...)
> 
> Suppose you decide to make Installers raise exceptions to notify their
> clients of problems, so sophisticated ones can do whatever they want.
> You still anticipate that most clients will want your nice gui behavior.
> So you make a subclass of SMInstaller, that holds a reference to an
> Installer and forwards the requests to it, but catches the exceptions,
> applying the GUI behavior. 
> 
> A client wanting a "raw", exception throwing Installer would do 
> SMInstaller forPackage:directory: 
> and one wanting a nice GUI'd version would simply do 
> SMPromptingInstaller forPackage:directory: 
> and get very similar behavior.
> 
> A partial implementation of SMPromptingInstaller>>download would then
> look like this, for example:
> 	[actualInstaller download] 
> 		on: CantDownloadPackageWithNoUrlException 
> 		do: [self inform: 'Package lacks a download url, can not download.'.
> ^false].
> 	^true
> To complete, just handle all the other exceptions. 
> 
> That's a (marginal, but still pretty) application of the Decorator
> design pattern. The nice thing is that other people can create different
> wrappers, and they can be reused too. 
> 
> But then again, YAGNI.
> 
> A simpler solution might be to create exceptions with defaultActions. 
> 
> <ok, no more OO preaching for today ;-)>
> 
> > > While I'm at it, about the package registration form - can you please either 
> > > hide mail addresses or not make the mandatory, or something similarly 
> > > protective of our privacy?
> > 
> > I have a plan for the emails - read on:
> > http://anakin.bluefish.se:8000/gohu/15
> I read that, I meant now ;-) For now I'll just cheat a little.
>  
> Daniel Vainsencher



More information about the Squeak-dev mailing list