"Mark Derricutt" <
[hidden email]> wrote in message
news:cfhou7$
[hidden email]...
> So I'm like really new to this Dolphin lark ( installed yesterday ) and
> deployed an exe this morning that had problems.
>
> I've just rewritten it with actual real functionality and a resonably
> nice UI and went to build an exe but.....
>
> mid-way through the day I installed XP SP2 on the laptop, and now I
> Dolphin core dumps with saying that the refactoring browse has redundant
> prerequesites and can't be removed, then the image crashes...
>
> Anyone seen that?
It probably has nothing to do with XP SP2, but rather some modification you
have made (perhaps inadvertently).
Go into the Package Browser and ensure that the $ at the root of the package
tree is selected. Then switch to the 'Prerequisites' tab and right click to
bring up the context menu. Choose the Show Status Icons command. Any
packages that have a red X against them have cyclic prerequisites. If you
drill down into the prerequisites tree from there you should be able to find
where the cycle occurs. If you select the packages in the pre-reqs tree you
will see in the bottom pane a list of the dependencies that exist between
the selected package, and its parent in the tree. You can use this to find
what is causing the cyclic reference. Usually it is caused by having added a
method to a package that references a class in another package which is
itself already dependent on the first package. Cyclic references can always
be resolved, usually very easily. In most cases it is simply a matter of
making a method "loose" (that is, it extends a class defined in a
prerequisite package rather than being defined within that package). In more
complex cases it is sometimes necessary (or best) to introduce a third
package that acts as a common base for both packages. Finally you can use an
indirect symbolic reference (e.g. lookup a class by name in the Smalltalk
dictionary rather than referencing it directly), although I generally
wouldn't recommend this as it is best that all dependencies be visible as
that way the browser and deployment tools will be more helpful.
Some people have recently mentioned here that they always deploy from a
fresh image. I don't always do this during development, but it is
nevertheless very good advice. Following the discipline of deploying from a
new image helps ensure that the packaged representation of your project
fully describes the application. This allows you to separate it cleanly from
any particular image and install it in another. If your packages don't fully
describe your applicaton, you'll also have problems at deployment time since
the Lagoon system relies heavily on packaging information in deciding what
needs to be retained in the application. Another advantage is that the fresh
image won't contain any spoors from previous development experiments and
debugging. Unwanted objects can sometimes hang around in an image
indefinitely, and although they can always be tracked down and removed, this
is sometimes more effort than just starting again in a fresh environment.
Regards
Blair
Locked
