Exception when deploying hello world

When I try to deploy the Hello World example the stripper crashes with
"Number does not understand #@".

Regards

Carsten Haerle

Carsten Haerle wrote:

> When I try to deploy the Hello World example the stripper crashes with
> "Number does not understand #@".

It seems to work OK for me.  Are you deploying from a clean image ?

    -- chris

It is a base 5.1.4 image with STS and Tools+ installed. Maybe this is the
cause?

"Chris Uppal" <[hidden email]> schrieb im
Newsbeitrag news:[hidden email]...

Carsten Haerle wrote:

> > It seems to work OK for me.  Are you deploying from a clean image ?
[...]
> It is a base 5.1.4 image with STS and Tools+ installed. Maybe this is the
> cause?

No idea, but it looks very suspicious to me -- that is certainly /not/ what I
mean be a "clean image".

The rest of this post is about clean deployment, which may or may not be
relevant to the problem you are seeing.

Here's how I did it for years, with no problems whatever (except a certain
boredom):

Create a new completely clean image.  Don't add /anything/ to it, and indeed
remove all the sample packages, and other "fluff".  Save that as
'deployment.img".  Set up Windows shortcut so you can launch that image with 1
click.

In that image, turn off the "save image on deploy" option in Lagoon (very
important!).  Set it up carefully so that the Package Browser is the only open
window, and from there save and exit.  Now make a copy of the image and keep it
safe -- that will be the master for when you want to re-create the deployment
image.

(Actually, at this point I add some 3rd party libraries -- /not/ IDE extensions
or tools -- that I use often.  That saves a little time in deployment, but the
important reason is as a workaround for the infuriating bug in package loading
that has been mentioned here a couple of times (by me and Ian B, IIRC))

Now, with that set up, a deployment is a matter of only about 6 keystrokes.

1) From your working image save the packages (having to remember to do this is
the only real problem with this approach).

2) Fire up the deployment image.  (There is no need to close your working
image -- this way of doing it actually causes /less/ disruption to your work
than trying to make "dirty" deployment work (even if it did work)).

3) The deployment image comes up with the PB on top, use that to load your main
deployment package (which will load the others if the prerequisites are right).

4) Select deploy from the package menu.

5) Press the deploy button in Lagoon (the deployment settings are stored in the
package, and you've already ensured that they are correct).

6) Wait for the "finished" message box and OK it.  Done.

I went into all that detail because it seems that there's a certain reluctance
among Dolphin programmers to use clean-image deployment, and I suspect that's
because it looks like a hassle.  I've tried to illustrate how to set things up
so that its actually Very Simple Indeed.

Of course, even that gets tedious after a year or two.  Various people have
automated it in various ways.  Bill has published code (suite-builder) which
makes it easy to build collections of related applications; it is on his
website.  At least one regular (sorry, I forget who) has created a completely
unattended build process (I don't know how they got around the problem of the
last "OK" button).  I have written a small tool that lives in the deployment
image and uses data from the registry to reduce steps 3 through 5 to a
single-click selection from a list of "deployable" packages (I'll add it to my
website if anyone is interested in trying it).  No doubt you can come up with
your own solution that would suit your ways of working even better.

Sorry to be off-topic, but I hope this has helped (someone) anyway.

    -- chris

Chris,

The idea of a clean image deployment is a good one and to be
recommended but...


[snip]

> 2) Fire up the deployment image.  (There is no need to close your
> working image -- this way of doing it actually causes less disruption
> to your work than trying to make "dirty" deployment work (even if it
> did work)).

[snip]

I have to take some (small) exception to the above since it could be
construed to mean that deployment doesn't actually work out of the box
from a standard "dirty" Dolphin development image. It quite plainly
does providing you haven't loaded anything into the image that breaks
the system and you haven't got any zombie (headless) objects lurking in
the image from your previous development attempts. One way to reduce
the likelihood of the latter is to do a "Panic" from the System Folder
just before deployment.

As you know, I am an inveterate believer in the use of a "dirty" image.

http://groups.google.com/groups?q=bonkers+dolphin&hl=en&lr=&ie=UTF-8&c2c
off=1&selm=80hfv7%24h1j%241%40lure.pipex.net&rnum=2

Since I wrote the above, my standard Dolphin image has grown a lot
larger. My current image (which I use for Dolphin development and for
some internal applications) has 265 packages loaded in it and is 49Mb
(74Mb including the CHG and SML files). The last time I booted this
image from scratch was around 4 weeks ago and yet I haven't (touch
wood) trashed it or been prevented from deploying applications from
within it. I regularly (well about 5 times so far since the image was
booted) have to deploy a 1Mb executable application and have had no
problems in doing so, although I do always perform a "Panic" first.

Having said this, I would recommend Chris' technique of clean building
for whenever you have to deploy an application for final distribution
(after all it is effectively what we do when we build a new release of
Dolphin). However, if you are producing internal builds of an
application for testing etc. there should be nothing to stop you
deploying directly from your development image if you, as I do, find
this to be more convenient.

Best regards,

Andy Bower
Dolphin Support
www.object-arts.com

Andy,

> > 2) Fire up the deployment image.  (There is no need to close your
> > working image -- this way of doing it actually causes less disruption
> > to your work than trying to make "dirty" deployment work (even if it
> > did work)).
[...]
> I have to take some (small) exception to the above since it could be
> construed to mean that deployment doesn't actually work out of the box
> from a standard "dirty" Dolphin development image.

I probably made the implementation sound less reliable than it is, my apologies
if I mislead anyone.  However I /do/ think that it's a risky practise -- there
is always a chance that it will go wrong, even though the implementation itself
is sound.  Admittedly the chance is small[*], but it's an extra unknown that
you just don't need.  Especially since tracking down problems in a deployed exe
can be so very time-consuming.

([*] Or rather, I accept that it is small -- I, personally, have never had a
dirty deploy work: I tried it once or twice years ago and gave up on it then,
so I've never tried again...)

My own position is that since it's both easier /and/ (potentially) more
reliable to deploy from a clean image, you'd have to be "bonkers" ;-) to do
anything else.

Actually, I'd be interested to know why you /do/ do it.  It sounds...

> I regularly (well about 5 times so far since the image was
> booted) have to deploy a 1Mb executable application and have had no
> problems in doing so, although I do always perform a "Panic" first.

...as though it's disrupting your workflow more than doing a clean deploy would
?


> As you know, I am an inveterate believer in the use of a "dirty" image.

Indeed; as am I.


> Since I wrote the above, my standard Dolphin image has grown a lot
> larger. My current image (which I use for Dolphin development and for
> some internal applications) has 265 packages loaded in it and is 49Mb
> (74Mb including the CHG and SML files). The last time I booted this
> image from scratch was around 4 weeks ago and yet I haven't (touch
> wood) trashed it or been prevented from deploying applications from
> within it.

My working image is now nearly 4 months old  (nah nah!), has 290 packages
loaded at the minute, and is about 21Mb.  (My packages must be smaller than
yours ;-)   In fact it's old enough now that the .chg file is bigger than the
.img file; perhaps it's time I considered doing a "compress changes"...

    -- chris

Andy,

> As you know, I am an inveterate believer in the use of a "dirty" image.
>
> http://groups.google.com/groups?q=bonkers+dolphin&hl=en&lr=&ie=UTF-8&c2c
> off=1&selm=80hfv7%24h1j%241%40lure.pipex.net&rnum=2

One of the more memorable posts in the archive :)


> Since I wrote the above, my standard Dolphin image has grown a lot
> larger. My current image (which I use for Dolphin development and for
> some internal applications) has 265 packages loaded in it and is 49Mb
> (74Mb including the CHG and SML files). The last time I booted this
> image from scratch was around 4 weeks ago and yet I haven't (touch
> wood) trashed it or been prevented from deploying applications from
> within it. I regularly (well about 5 times so far since the image was
> booted) have to deploy a 1Mb executable application and have had no
> problems in doing so, although I do always perform a "Panic" first.

FWIW, I deploy from "dirty" images on a regular basis, and have no
problems with it.  One caveat (relevant or not - your call) is that I
tend to "sneak up on things" that I consider to be dangerous.  By that,
I mean that I get the image ready, save it, and then exit w/o saving if
anything goes wrong.  Examples include changes to external interfacing,
and (especially???) any changes to presenter startup code, and view
drawing code.  The latter is less of a problem for me now, because I
have developed a standard way of generating graphics, and have usually
tested it "headless", then by displaying bitmaps in image presenters.
The code is usually fairly idiot proof before I turn it loose on
#onPaintRequired:.

Have a good one,

Bill


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