Erroneous User Interrupts

Chris Uppal wrote:

> ...  just define an empty package 'Working Set' that
> includes all your working packages as (manual) pre-requisites.  Load that, and
> the system will load everything else for you.
>

Sounds like a great tip. I assume the pre-requisites
function will then load my packages /in the correct
order/ - unless they already exist in the image.

I also assume that unloading the 'boot-strapper' package
will unload all my 'real' packages, so I'll get the
latest versions from disk when I next load the boot-
strapper. Great.

>
> Eh?  "not very stable" ??  It seems stable enough to /me/.

My image became non-functional twice yesterday, to the
point I had to reboot my machine. That's not stable
enough, for me.

Naturally if I spend more time on this, I'd learn
a way of working that 1) makes it less likely for
the image to crash or get corrupted 2) makes it
much easier to recover when it does. But, sometimes
first impressions are the ones that count.


> Have you /looked/ at the Chunk Browser yet ?

I downloaded it, 'installed' it into the dir where I
keep the image, and tried to install the 'Chunk Browser'.
I got the error "ByteArray class does not understand
#fromBase64String:". Is this typical or what?. The
stack  trace is below.

Thanks for all the help
-Panu Viljamaa


DNU Trying to install the ChunkBrowser:
-----------------------------------
ByteArray class(Object)>>doesNotUnderstand:
Package>>{unbound}doIt
Compiler class>>evaluate:for:evaluationPools:logged:ifFail:
Compiler class>>evaluate:for:evaluationPools:logged:
Compiler class>>evaluate:for:logged:
[] in ChunkSourceFiler>>fileIn
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>on:do:
ChunkSourceFiler>>fileIn
[] in Package>>fileInScript:
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>on:do:
Package>>fileInScript:
Package>>loadPAC:
[] in Package>>loadPAC
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
Package>>loadPAC
Package>>load
[] in PackageManager>>install:
BlockClosure>>ifCurtailed:
[] in PackageManager>>install:
OrderedCollection>>do:
[] in PackageManager>>install:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
PackageManager>>install:
[] in PackageSelector>>openPackageFile:
ExceptionHandlerSet(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandlerSet(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandlerSet(ExceptionHandlerAbstract)>>try:
BlockClosure>>onDo:
BlockClosure>>on:do:on:do:on:do:on:do:on:do:on:do:
PackageSelector>>openPackageFile:
[] in PackageSelector>>openPackage
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
Cursor>>showWhile:
PackageSelector>>openPackage
Symbol>>forwardTo:

Panu,

>> Eh?  "not very stable" ??  It seems stable enough to /me/.
>
>
> My image became non-functional twice yesterday, to the
> point I had to reboot my machine. That's not stable
> enough, for me.

I doubt that Dolphin itself is to blame.  If a program crashes, and you
have to reboot as a result, blame the operating system, hardware, and/or
drivers.  With that said, you can certainly throw wrenches into the
works of any Smalltalk system; Dolphin cannot (and should not try to)
shield you from that.  Clobbering an image is part of every
Smalltalker's growth.


> Naturally if I spend more time on this, I'd learn
> a way of working that 1) makes it less likely for
> the image to crash or get corrupted 2) makes it
> much easier to recover when it does. But, sometimes
> first impressions are the ones that count.

Stick with it - it gets better, a LOT better.


> I downloaded it, 'installed' it into the dir where I
> keep the image, and tried to install the 'Chunk Browser'.
> I got the error "ByteArray class does not understand
> #fromBase64String:". Is this typical or what?. The
> stack  trace is below.

Which patch level are you using?


Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

panu wrote:

> I downloaded it, 'installed' it into the dir where I
> keep the image, and tried to install the 'Chunk Browser'.
> I got the error "ByteArray class does not understand
> #fromBase64String:". Is this typical or what?. The
> stack  trace is below.

Base64String was introduced to Dolphin in patch level 4 so you need to be
using Dolphin 5.1.4 to install the ChunkBrowser.  The web site does mention
that this is the required platform...

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

panu wrote:

> Sounds like a great tip. I assume the pre-requisites
> function will then load my packages /in the correct
> order/ - unless they already exist in the image.

Unfortunately this doesn't seem to work for me.
I get a walkback when trying to install the
bootstrapper-package. It seems the loader is
looking for depended-on packages in the same
directory where the image is, not in the directory
where I install the bootstrap package from,
and keep my other packages in.

I don't want to keep images and packages in the
same directory, because although I do want to
backup the source-code, I don't want to backup
the images.

So I guess an automatically generated script
that loads the packages from where they were
most recently saved would seem like a great
solution next.  Also, it would be nice if the
script stored /relative positions/ of the
depended on packages, so we could replace them
regardless of their absolute location.

I actually had a solution like this a year or
so ago, but it got lost when starting to use
5.1. Now it exists in some old package, which
doesn't readily install, because all pre-requisites
are not present, Dolphin version is different etc.

For reasons like this I think it would be great
if an easy and bullet-proof way to load pre-requisite
packages was part of the base image itself.


-Panu Viljamaa

Bill Schwab wrote:

> Clobbering an image is part of every
> Smalltalker's growth.

Hey, what about the environment? Shouldn't it
be grown-up enough, not to crash on us?!

Cheers
-Panu Viljamaa

panu wrote:

> > Clobbering an image is part of every
> > Smalltalker's growth.
>
> Hey, what about the environment? Shouldn't it
> be grown-up enough, not to crash on us?!

You may be surprised, but I think the answer is NO.  Smalltalk, anyway, is
built on the assumption that you are capable of looking after yourself, and
therefore that it does not, and should not, prevent you from making mistakes.

E.g. a little while ago I /only just/ caught myself in time; I had typed
something like

    String := blah blah.

into a workspace, and was just about to execute it...

That level of "danger" is implicit in the concept of working in a live
environment.  If I hadn't noticed the mistaken capital letter in time then it'd
have been /my/ fault, not a flaw in the IDE.

I think you'll find that Dolphin is extremely robust (at least when running on
an OS that is itself robust -- i.e. not Win98).  Not only does it not crash "by
itself", it is remarkably resilient to abuse.  I have been doing quite a bit of
external interfacing with various more-or-less complicated and under-documented
systems.  In that sort of situation you /expect/ crashes (whatever language you
are working in).  In fact I've had very few (perhaps none) crashes that were
caused by my misapplications of external interfacing.  (I have had to suffer
crashes caused by bugs in the external code.)

In general I only rebuild my image perhaps twice a year, normally because I
think it's time I caught up with the current patchlevel (my setup makes it a
bit awkward to install patches how I want 'em, so I tend to save them up and do
it in a bunch).  I doubt if I rebuild /involuntarily/ more than once a year --
if that.

It's worth mentioning, though, that I /do/ often (several times a week) just
abandon an image without saving it.  Usually it's because I was consciously
trying something that I didn't want to make permanent (this is a handy
technique, by the way).  Sometimes its because I've started making a set of
changes and then realised that they were misguided, and the easiest way to
revert to the original position is just to exit without saving.
 Occasionally -- perhaps weekly when I'm working on something complicated
and/or new in the GUI, hardly ever under other circumstances -- I'll get the
image into such a state that I'm forced to abandon it.  If that happens, then
either (a) I remembered to save everything /before/ trying whatever it was
(good); or (b) I forgot to do so (again!), in which case I sigh deeply and fire
up the chunk browser...

To a large degree it is, as you say, a matter of experience and practise.  I
would not have been able to keep my image "healthy" for so long when I was
starting out with Dolphin.

    -- chris

panu wrote:

Ah, yes I feel /exactly/ the same way about keeping images and packages
together.

Unfortunately Dolphin has an infuriating and deeply inconvenient bug (which Ian
and I have both reported before, and which I /really wish/ OA'd fix[*]) that
causes a walkback when loading a package that is not under the image directory
but which has to install a pre-requisite package that /is/ under the image
directory.

([*] I have looked to see if I can fix it myself, but the bit of code in
question -- handling updates to the package tree component -- seems to be
written with assumptions that I've not been able to grok)

FWIW, the bug is in the Package Browser, not in the package system itself, so
you can install your bootstrap package from code, if you want to.

(BTW, packages do include relative paths to their dependents. So normally --
i.e. in the absence of the bug -- the package system will find pre-requisite
packages without having to ask you where they are)

>From another post of yours:

> I also assume that unloading the 'boot-strapper' package
> will unload all my 'real' packages, so I'll get the
> latest versions from disk when I next load the boot-
> strapper.

'fraid not.  The "is a pre-requisite of" relationship is not symmetrical, so
unloading the bootstrapper will leave all the others still loaded.  If you want
to get that effect, then you could create a similar "root" package that all
your other stuff depends on, and unload that.  I'm not convinced it's worth the
effort, though.

    -- chris

Bill Schwab wrote:

> > So write a script that /generates/ a script.  That's what I do (though
> > it's actually part of one of my own tools, not a separate script).
>
> Is this something that you have or are willing to make available?

Well the tool itself is quite big[*], and is not something I'm willing to add
to my website as a "published" tool (mainly because of the security
implications of running arbitrary code simply in order to find out what's in a
package file, but also because -- since I decided that I could not responsibly
make it generally available -- I have allowed the code to become decidedly
crufty).  Still, if you (or anyone) would like a copy then please drop me a
line.

(BTW, Bill, the last time I sent you anything, your hospital's email system
refused it -- on the grounds that it had a ZIP attachment ! -- and when I sent
it again without zipping it just vanished as into a black hole.)

I've pulled out some of the code that computes the ordered pre-requisites and
generates scripts, and attached a version to the end of this message in case
it's useful to anyone.  But do note that in many cases you won't need (or want)
that level of control; it would be sufficient, and much simpler, for your
script to load just the packages you are interested in (in any order) and let
Dolphin work out the hard stuff.

([*] it's mainly about listing all the packages, loaded or not, in nominated
folders on disk. It displays what's in them; warns of clashes with what's
already loaded, warns of packages that have been modified on-disk but not in
the image, allows you to load/unload/reload groups of packages, etc.  It has
also accumulated a number of miscellaneous package-related options that I tend
to add to the tool, simply because its a handy place for them to "live" -- the
script generation is one example of that.)

    -- chris


Listing/generating code follows:

====================
!Package class methodsFor!

addPrerequisitesOf: aPackage to: aCollection checking: aSet
 "Private - Ensure that each of the package prerequsities are satisfied
 by packages in aCollection.  If necessary packages are added to aCollection.
 The Set of packages is used for circularity checking.  It contains any
 packages which are the subject of this method deeper in the stack.
 Raises an error if any package is unsaveable."

 | checkSet preqs |
#CUadded.

 "circular prerequisites ?"
 (aSet includes: aPackage) ifTrue: [self unsaveableSignal signal: 'Cyclic
prerequisites.' with: aSet].

 "uncomitted (not in a package) prerequisites ?"
 (aPackage = self uncommitted) ifTrue: [self unsaveableSignal signal:
'Uncommitted prerequisites.' with: aSet].

 "already added ?"
 (aCollection includes: aPackage) ifTrue: [^ self].

 "look for so-far unsatisfied prerequisites"
 checkSet := (aSet copy) add: aPackage; yourself.
 preqs := aPackage prerequisites.
 preqs := preqs reject: [:each | aCollection includes: each].
 preqs do: [:each | self
    addPrerequisitesOf: each
    to: aCollection
    checking: checkSet].

 aCollection addLast: aPackage.! !
!Package class categoriesFor: #addPrerequisitesOf:to:checking:!helpers!private!
!

!Package methodsFor!

installScript
 "Answer a String that, if executed as a script, will ensure that the reciever
is
 installed.  The script refers to pre-requisite packages by their full
filename, and
 installs them in pre-requsite order, and so will never depend on Dolphin's
built-in
 package name resolution.
 Raises an error if any package is unsaveable."

#CUadded.

 ^ self class installScriptFor: (Array with: self).! !
!Package categoriesFor: #installScript!accessing!helpers!public! !

!Package class methodsFor!

installScriptFor: aCollectionOfPackages
 "Answer a String that, if executed as a script, will ensure that the
aCollectionOfPackages
 are all installed.  The script refers to pre-requisite packages by their full
filename, and
 installs them in pre-requsite order, and so will never depend on Dolphin's
built-in
 package name resolution.
 Raises an error if any package is unsaveable."

 | stream |
#CUadded.

 stream := String writeStream.

 self writeInstallScriptFor: aCollectionOfPackages on: stream.

 ^ stream contents.! !
!Package class categoriesFor: #installScriptFor:!helpers!public! !

!Package methodsFor!

orderedPrerequisites
 "Answer an OrderedCollection consisting of the reciever and all its
pre-requisite packages
 ordered in such a way that the pre-requisites of any package precede it in the
list.
 Raises an error if any package is unsaveable."

#CUadded.

 ^ self class orderedPrerequisitesOf: (Array with: self).! !
!Package categoriesFor: #orderedPrerequisites!accessing!helpers!public! !

!Package class methodsFor!

orderedPrerequisitesOf: aCollectionOfPackages
 "Answer an OrderedCollection consisting of the given packages plus all their
pre-requisite packages
 ordered in such a way that the pre-requisites of any package precede it in the
list.
 Raises an error if any package is unsaveable."

 | all |
#CUadded.

 all := OrderedCollection new.
 aCollectionOfPackages
  do: [:each | self
     addPrerequisitesOf: each
     to: all
     checking: IdentitySet new].
 "sanity check...
 all keysAndValuesDo:
  [:index :each |
  each allPrerequisites do:
   [:other || at |
   at := all indexOf: other.
   self assert: [at > 0].
   self assert: [at < index]]].
 "

 ^ all.
! !
!Package class categoriesFor: #orderedPrerequisitesOf:!helpers!public! !

!Package class methodsFor!

writeInstallScriptFor: aCollectionOfPackages on: aStream
 "Writes onto aStream a script that will ensure that the aCollectionOfPackages
 are all installed.  The script refers to pre-requisite packages by their full
filename, and
 installs them in pre-requsite order, and so will never depend on Dolphin's
built-in
 package name resolution.
 Raises an error if any package is unsaveable."

 | all |
#CUadded.

 all := (self orderedPrerequisitesOf: aCollectionOfPackages) reject: [:each |
each isSystemPackage].

 all do:
  [:each || filename packagename |
  filename := each packagePathname.
  packagename := each name.
  aStream
   nextPutAll: '(PackageManager current includesPackageNamed: ';
   print: each name;
   nextPutAll: ') ifFalse: [PackageManager current install: ';
   print: each packageFileName;
   nextPutAll: '].';
   cr].
! !
!Package class categoriesFor: #writeInstallScriptFor:on:!helpers!public! !
===============

Chris,

> Well the tool itself is quite big[*], and is not something I'm willing to add
> to my website as a "published" tool (mainly because of the security
> implications of running arbitrary code simply in order to find out what's in a
> package file, but also because -- since I decided that I could not responsibly
> make it generally available -- I have allowed the code to become decidedly
> crufty).  Still, if you (or anyone) would like a copy then please drop me a
> line.

The part you provided here is probably exactly what I would find
interesting.  I appreciate your offer, and might take you up on it in
the future.


> (BTW, Bill, the last time I sent you anything, your hospital's email system
> refused it -- on the grounds that it had a ZIP attachment ! -- and when I sent
> it again without zipping it just vanished as into a black hole.)

Sorry about that.  The black hole might have been my my fault due to my
revolving to-do list (every time I turn around, I have something else to
do<g>).  The zip file thing is indeed a problem, but there is a _very_
simple way to defeat it - change the extension.  The concern was for the
"average user" (most physicians are not very technically savy) who might
open an attachment that has not been scanned for virii.  Why would the
files not have been scanned?  Good question.  There is a one-word
answer: Novell.


> I've pulled out some of the code that computes the ordered pre-requisites and
> generates scripts, and attached a version to the end of this message in case
> it's useful to anyone.  But do note that in many cases you won't need (or want)
> that level of control; it would be sufficient, and much simpler, for your
> script to load just the packages you are interested in (in any order) and let
> Dolphin work out the hard stuff.

True.  I greatly appreciate that help when working in the IDE (no more
annoying chains of "Pacakge x not found" file prompters or whatever they
were - very slick), but I also want to be able to know that I have a
script that includes all of the packages.

All of the above leads to my recent statement: I suspect Migrate's
script generator is not quite working as intended, but Dolphin covers
for it, and the end result works.  I hope to do better, and appreciate
the look at your code.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Panu,

>> Clobbering an image is part of every Smalltalker's growth.
>
>
> Hey, what about the environment? Shouldn't it
> be grown-up enough, not to crash on us?!

It already is more than stable when not "attacked" or abused.  However,
it should not attempt to protect you from yourself, nor can it protect
against wrongs by external code.  I recommend that you read Chris'
excellent reply, and encourage you to continue using Smalltalk.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Chris Uppal wrote:

> panu wrote:
>>Hey, what about the environment? Shouldn't it
>>be grown-up enough, not to crash on us?!
>
> You may be surprised, but I think the answer is NO.  Smalltalk, anyway, is
> built on the assumption that you are capable of looking after yourself, and
> therefore that it does not, and should not, prevent you from making mistakes.


I can't really subscribe to this viewpoint.

Smalltalk was originally conceived as an environment easy enough
for children to use. So it was /not/ built on the assumption that
those who use it are "capable of looking after themselves".

Think about dynamic typing. This would seem a feature especially
designed to prevent us from making pointer errors. Think about
garbage collection; it prevents memory allocation mistakes.

Think about Dolphin XP's excellent refactoring support. It allows
you to rename a class or a method while simultaneously preventing
the error of neglecting to change the references to it.

I don't see why an environment "should not prevent us from
making mistakes", if it can do so without too many harmful
side-effects. Mistakes and errors are costly, and un-productive.

Cheers
-Panu Viljamaa

"panu" <[hidden email]> wrote in message
news:[hidden email]...
I can't really subscribe to that viewpoint. Part of the process of bringing
up a child is progressively making the transition from complete dependence
to complete independence. Depending on the age of the child, they will have
at least some independent capability to look after themselves, and as long
as they are free from physical or mental harm it is appropriate to push that
boundary in my view.

> Think about dynamic typing. This would seem a feature especially
> designed to prevent us from making pointer errors.

Yes, but it doesn't try to prevent you from making type errors.

>...Think about
> garbage collection; it prevents memory allocation mistakes.
>
> Think about Dolphin XP's excellent refactoring support. It allows
> you to rename a class or a method while simultaneously preventing
> the error of neglecting to change the references to it.

True, but some of the most useful refactorings are not always Refactorings
(e.g. inline temporary). I wouldn't want to live without them just because
they don't necessarily preserve existing behaviour.

>
> I don't see why an environment "should not prevent us from
> making mistakes", if it can do so without too many harmful
> side-effects. Mistakes and errors are costly, and un-productive.
>

They are also necessary for learning. An environment that prevents you from
making mistakes would be very sterile, and not terribly useful (witness the
Java sandbox).

Danger is a necessary adjunct of flexibility and power. We try to make the
danger levels manageable, and are always open to suggestions of specific
ways to improve on that. For example the Dolphin compiler prevents one from
assigning directly to a class global by treating the binding as constant
(try Object := nil). We think the balance between safety and power in
Dolphin is about right, you are free to disagree of course.

Regards

Blair

Panu,

> Smalltalk was originally conceived as an environment easy enough
> for children to use. So it was /not/ built on the assumption that
> those who use it are "capable of looking after themselves".

Yes, but as Blair points out, watching the image go down in flames (with
no real harm done) teaches them some very important lessons.

Besides, kids don't make pool dictionaries and create new visual widget
kits.   And if they do, they will have necessarily learned a lot before
they get to that point.

Besides, I suspect Dr. Kay surprised even himself with how inspired his
idea truly was.  For evidence of that look at Squeak which has spawned
Croquet for (I suppose) adults to collaborate on projects, and eToys for
children.  None of that would exist were it not for Smalltalk's
consistency, power, and openness.  Some danger comes along with that power.


> I don't see why an environment "should not prevent us from
> making mistakes", if it can do so without too many harmful
> side-effects. Mistakes and errors are costly, and un-productive.

As are barriers to productivity.  Even if the environment were totally
idiot proof, you would still need to protect yourself against hard drive
failures, etc.  If you are making a living with a computer, you must
protect yourself against failures of all types.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Blair McGlashan wrote:

> Danger is a necessary adjunct of flexibility and power. We try to make the
> danger levels manageable, and are always open to suggestions of specific
> ways to improve on that. For example the Dolphin compiler prevents one from
> assigning directly to a class global by treating the binding as constant
> (try Object := nil). We think the balance between safety and power in
> Dolphin is about right, you are free to disagree of course.

I'm not really arguing that the problem is Dolphin crashing
too easily. It's actually a great system. And you are going
in the right direction - /in my view/ - by preventing us from
making mistakes like "Object := nil".

What I'd see as problematic is the viewpoint that an easy to
crash system is actually good, because:
  1) It gives us more flexibility and power and
  2) It allows us to "learn".

But I'm sure that's not your viewpoint.

Regards
-Panu Viljamaa

Blair, panu

> Danger is a necessary adjunct of flexibility and power. We try to make the
> danger levels manageable, and are always open to suggestions of specific
> ways to improve on that. For example the Dolphin compiler prevents one
> from assigning directly to a class global by treating the binding as
> constant (try Object := nil). We think the balance between safety and
> power in Dolphin is about right, you are free to disagree of course.

And wouldn't you know it, about 2 hours after reading that I managed to corrupt
my change log !  For the first time /ever/ in >6 years programming with
Dolphin.

Didn't take long to rebuild, just a few minutes.

I think panu and I are talking about slightly different things: I believe that
it is a good thing that we have enough power available that we can /destroy/
the image (like running as root on Unix), whereas I suspect that panu's concern
is about being protected against Dolphin /crashing/.  The difference in
emphasis is that for panu, it's something that Dolphin is doing to him, rather
than something that he is doing to Dolphin (which is how I see it).

I know that Dolphin is very robust, so I automatically assume that if panu's
Dolphin installation is crashing, then that must be because he is /making/ it
crash.  And that assumption must be rather infuriating for panu, but I've only
just noticed I'm making it -- sorry!  It's quite probably true, but that's not
much comfort ;-)

Anyway, I wanted to make two concrete suggestions.

One is very simple, and it's easy for us to implement by ourselves, though I
think it would make a good addition to the base system.  Just arrange that
whenever the image is saved, a complete list (in any order) of the installed
package /files/ is written to an "<image-name>.packages" file in the image
folder.  That would provide a good start for fast recovery, there could even be
an option on the Package Browser: "Load all packages from
<image-name>.packages".  (Though I think that a better idea would be for the PB
to have two more generic options "Write package list" and "Load listed
packages")

The other is more complicated, unless you can think of a good way of doing it.
(I attempted this myself some time ago, but my approach didn't work, though
I've never investigated why).  The most common reason to have to abandon an
Image (in my experience) is the "machine-gun walkback syndrome" that you can
get when there's an error somewhere in some display-related code.  It would be
nice to have some option to limit the uncontrollable proliferation of
walkbacks.  Perhaps an option that made errors (or maybe just errors on the
main thread) be log-and-ignored while the walkback dialog was already showing.
Or limit it to one walkback showing /per shell/.

    -- chris