More Friendly Packager?

How can I make my V.5 Package Browser more friendly, less Nazi?  For
example, when I try to load a package that has one method which doesn't
compile, the whole package isn't loaded instead of loading the whole thing
of which over 99% compiles and either notifying of the uncompiled method or
leaving only it unloaded?

Reminds me of a local cop who asked for proof of insurance -- I didn't have
the correct form, but I had one with an 800 number which would have
confirmed my coverage had the cop called it as I asked -- so I got a ticket.
But as with this post, I wrote the little Nazi up to his boss!

Nazi Packager Update:  It now won't UNLOAD any of my packages because they
have "Cyclic References."  What does that mean?  More important, how do I
fix it -- there's no remove cyclic references button on the error message.

Guys, if you are going to make tools that "protect" the programmer, please
automate an escape hatch!  It seems I have to reload a fresh image every few
days of use to stay free of the Nazi guard.  Then I have to re-apply Ian's
menu change or suffer reverting to your menu "improvement."

I understand your choosing to use the packager encourage users to upgrade to
the latest Dolphin, but this other behavior is encouraging me to try to find
an alternative.  Anybody have another packager?

Since Andy responded to one person's pointed language in deciding to get rid
of Dophin 2.1, consider the same language as repeated here regarding the
packager.

One more suggestion: why not treat classes with the same name but under
different inheritance as unique and make method references prefer the local
package?  Then two packages having classes with identical names underneath
the top level one could coexist without third party vendors having to
"brand" their classes with a prefix!  This could be a great improvement to
the standard Smalltalk specification.  Where should I send it?

Kirk,

> Nazi Packager Update:  It now won't UNLOAD any of my packages because they
> have "Cyclic References."  What does that mean?  More important, how do I
> fix it -- there's no remove cyclic references button on the error message.

Look on the Wiki - there at least was a little on this up there.  They are
generally quite easy to fix once you get the hang of it.  Sometimes adding
another package and putting a few things in it will fix the problem.
Sometimes it's as simple as repacking a method or two - especially true if
you add methods to classes belonging to base system classes.  Testing
methods are notorious for causing cycles because they often reference lots
of classes and can really make a mess in hurry.

If you are simply trying to get rid of something, then you can probably
delete the classes and eventually the cycles will disappear with them.
However, I think you are better off fixing the problem.


> Guys, if you are going to make tools that "protect" the programmer, please
> automate an escape hatch!  It seems I have to reload a fresh image every
few
> days of use to stay free of the Nazi guard.  Then I have to re-apply Ian's
> menu change or suffer reverting to your menu "improvement."

I can help you with this :)   Really.  The package manager is your friend.
Look through the prerequisites for a red X - you might have to set an option
to turn it on????  Follow the unhappy icons until you spot the problem.
Honest, it gets easy to do after a while.


> I understand your choosing to use the packager encourage users to upgrade
to
> the latest Dolphin,

I doubt that was the motivation.


>  but this other behavior is encouraging me to try to find
> an alternative.  Anybody have another packager?

Well, I do a fair amount of work in Squeak, and _really_ (REALLY!!!) miss
packages.  PackageInfo comes close, but it's just not the same.

Have a good one,

Bill

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

Kirk,

the Source Tracking System (see http://www.gorisek.com) can automatically
load all the code that compiles leaving the rest in the repository for
manual intervention.

Let's say you have an old package which wont load into your current image.
With STS you can do the following:

1. import package file directly into STS source code repository
2. load imported package version ignoring all methods that don't compile
3. compare loaded code with version in the repository. Here the changes
browser will show you all differences between the loaded code and the
original package. By selecting specific change items (methods, classes) you
can manually adapt code in a way that it will compile.

With STS you can also store code with cyclic prerequisites. Later you will
just have to load both packages twice, by compiling globals first and
loading methods referencing globals in the second step.

Best regards,

David


"Kirk W. Fraser" <[hidden email]> wrote in message
news:T9h5a.32782$A%[hidden email]...
> Nazi Packager Update:  It now won't UNLOAD any of my packages because they
> have "Cyclic References."  What does that mean?  More important, how do I
> fix it -- there's no remove cyclic references button on the error message.
>
> Guys, if you are going to make tools that "protect" the programmer, please
> automate an escape hatch!  It seems I have to reload a fresh image every
few
> days of use to stay free of the Nazi guard.  Then I have to re-apply Ian's
> menu change or suffer reverting to your menu "improvement."
>
> I understand your choosing to use the packager encourage users to upgrade
to
> the latest Dolphin, but this other behavior is encouraging me to try to
find
> an alternative.  Anybody have another packager?
>
> Since Andy responded to one person's pointed language in deciding to get
rid
> of Dophin 2.1, consider the same language as repeated here regarding the
> packager.
>
> One more suggestion: why not treat classes with the same name but under
> different inheritance as unique and make method references prefer the
local
> package?  Then two packages having classes with identical names underneath
> the top level one could coexist without third party vendors having to
> "brand" their classes with a prefix!  This could be a great improvement to
> the standard Smalltalk specification.  Where should I send it?
>
>

I'm using STS to get conquered the cyclic prerequisites problems. It
worked most of the time. But sometimes, some package behaved weired, i.e.
error message would appear while loading its stored version. For example:
I'm installing SmaCC program on a fresh patched image ( using a updated
compiler DolphinCR005.dll, modified for the compiler problem in compiling
'literal byte arrays inside of literal arrays (e.g., "#(#[])")' ) and then
version it in the repository. Next, I load that version in another working
image but the error message belled while loading the package: SmaCC
Development, with the quite familir debug strings:
"Character(Object)>>error:
  Character(Object)>>mustBeBoolean
  SmaCCEdge class>>generateCharacterSetFor:
  [] in SmaCCEdge class>>initializeIsExpressions
  IdentitySet(Set)>>do:
  SmaCCEdge class>>initializeIsExpressions
  SmaCCGrammar class>>maximumCharacterValue:
  SmaCCGrammar class>>initialize
 SmaCCGrammar class(Class)>>initializeAfterLoad
  [] in Package>>initializeClasses, etc...."
Such situations occurred off and on in some packages, , maybe related to
some unique package behavior ( some initialization process not well done?
prerequisites not loaded first? I don't know). In such condition, is the
only way that I could do is to go into the cycle of uninstalling and
installing ( some of my package could not get uninstalled, its over)  or
rebuild from a fresh image? How to avoid it?


Best regards.
Tsun-kuo Kuo.




"David Gorisek" <[hidden email]> wrote you
> can manually adapt code in a way that it will compile.
>
> With STS you can also store code with cyclic prerequisites. Later you will
> just have to load both packages twice, by compiling globals first and
> loading methods referencing globals in the second step.
>
> Best regards,
>
> David

"Tsun-kuo Kuo" <[hidden email]> wrote in message
news:[hidden email]...
I don't think this has anything to do with STS. I'm guessing that your
Character class has a method that starts with "is" and that doesn't return a
boolean. When SmaCC generates a scanner, it prefers to use the is* methods
on Character to test the character instead of testing each character
separately. For example, we can use isSeparator instead of testing for a
space, cr, lf, tab, or new page. Not only does it take less code to generate
the scanner, it is also normally faster to use the is* methods.

Anyway, when you load SmaCC, it goes through all the is* methods and
generates a map of their characters to the selector. If one of the methods
doesn't return true for some character, then you'll get this error.
Depending on what your method is named, you might try:
-----------------
SmaCCEdge class>>initializeIsExpressions
 "Creates a map from sets of characters to selectors that start with 'is' on
Character. This allows generated scanners to take
 full advantage of selectors that are already implemented on Character"

    | selectors |
    IsExpressions := Dictionary new.
    selectors := Character selectors
                select: [:each | ('is*' match: each) and: [each
argumentCount = 0 and: [(each at: 3) isUppercase]]].
    selectors do:
            [:sel |
            | string |
            string := self generateCharacterSetFor: sel.
            string isEmpty ifFalse: [IsExpressions at: string put: sel]]
-----------------

In addition to testing if the selector starts with "is", it also tests that
the third letter is a capital. I had to make that change for Squeak -- they
have an #isoToSqueak which returned characters.


John Brant

"Bill Schwab" <[hidden email]> wrote
> I can help you with this :)   Really.  The package manager is your friend.
> Look through the prerequisites for a red X - you might have to set an
option
> to turn it on????  Follow the unhappy icons until you spot the problem.
> Honest, it gets easy to do after a while.
>
> Well, I do a fair amount of work in Squeak, and _really_ (REALLY!!!) miss
> packages.  PackageInfo comes close, but it's just not the same.

Bill,

I liked the packages which were mostly compatible with object fileIn/fileOut
we used to have available in Digitalk Smalltalk.  They were great because
you could always bring them into a text editor, modify anything, and end up
with a readable package.  I see no improvements in Dolphin's packaging
system, on the contrary, it is Nazi in many ways.

But since my main goal in Smalltalk is to continue developing my own
computer language, I guess I should just silently muddle through such areas
where Dolphin bites like the packager and documentation.  At least Dolphin's
code runs faster than Squeak, several hundred times faster last time I
checked, so that helps keep me swimming with the fishes.

Kirk

Kirk,

> I liked the packages which were mostly compatible with object
fileIn/fileOut
> we used to have available in Digitalk Smalltalk.  They were great because
> you could always bring them into a text editor, modify anything, and end
up
> with a readable package.  I see no improvements in Dolphin's packaging
> system, on the contrary, it is Nazi in many ways.

It seems to me that there are at least two solutions to your issues with the
Dolphin package mechanism:

1) Don't use it. If you prefer file-ins to can still use those (pretty much
exactly as they existed in Digitalk).

2) Try to fix the circular reference problems that you see rather than just
throwing up your hands and starting again from a fresh image. Personally, I
recommend this apoproach since thousands of people seem to be able to use
the package mechansim without real difficultly and without seeing it as one
of the blackest areas of computing in the last 100 years.

Cyclic prerequisites are *not* a bug in Dolphin, they are a warning that you
have one package that refers to another which refers back to the first
again. Consequently, if Dolphin tried to reload such a package it wouldn't
know which to load first. These cycles can involve several chains of
packages (not just two) like:

Package (PA) contains class A that references class C
Package (PB) contains class B that references class A
Package (PC) contains class C that references class B

Since the packages are a source code format (indeed they are actually in
standard chunk file format) it is not easily possible for Dolphin to load
them in two passes. If we could scan all the packages in the chain for
required variables and define these first before performing the second
loading and compilation pass then we could avoid the "cyclic prerequisites"
issue. However, that is not part of the design and, since it is often
trivial to remove the cycles, it shouldn't really be a concern.

Say you have classes A, B, C as above, assigned to packages PA, PB, PC
respectively. B is a subclass of A and C is a subclass of B. Hence B depends
on A being first loaded before it can compile, and similarly C depends on B.
Try it in in you Package Browser. All ok so far and you can save PA, PB, PC
without problems.

Now add a method A>>c that just answers class C (c ^C). This creates a
reference from class A forward to class C; a cycle. Now try to save packages
again and you'll get the "Cannot Save Package" message.  You said:

>Nazi Packager Update:  It now won't UNLOAD any of my packages
> because they have "Cyclic References."  What does that mean?
>More important, how do I fix it -- there's no remove cyclic references
>button on the error message.

Well actually there is, it's just that it's not (and from the above
discussion you'll see why) completely automatic. In that error message it
says click "Yes" to show the package prerequisites. So do this, or go to the
"Prerequisites" tab in the Package Browser, and try expanding the items in
the tree. You'll see that each package reports why it depends on the
previous one in the tree. Most packages are more complicated than this
example so it helps to right click over a package and choose "Show Status
Icons". This will highlight the cyclic chain(s) with red crosses.

All you have to do is to expand down this chain until you find a place where
the dependencies can be broken. In this case, when you get to package C
(three levels down) it says "A>>c references global C". One way of fixing
this would be to move this method (as a loose method) from package A to
package C. Try it. Suddenly all the red crosses disappear and the packages
will all save correctly.

> One more suggestion: why not treat classes with the same name but under
> different inheritance as unique and make method references prefer the
local
> package?  Then two packages having classes with identical names underneath
> the top level one could coexist without third party vendors having to
> "brand" their classes with a prefix!  This could be a great improvement to
> the standard Smalltalk specification.  Where should I send it?

Well, this is a known problem (and IMO probably the most serious problem)
with Smalltalk today. There is also no real solution to it since there is no
overall governing body for Smalltalk to ratify possible solutions. What you
are asking for is the concept of namespaces. Now Cincom went ahead on their
own and introduced namespaces into VW a few years back, but in our opinion
in a rather unsightly way. Also the implementation was really only a partial
solution to the problem, since classes (and other globals) can live in
separate namespaces but method selectors cannot. The up and coming
SmallScript language does handle full selector namespaces rather well but,
again, has a completely different syntax from VisualWorks.

We have never really seen it as our postion to (arrogantly?) drive the
Smalltalk language forwards by adding incompatible language features but
rather to implement ratified or "defacto" standards where they exist.
Currently, there is no ANSI standard for namespaces and we don't yet see
that a worthwhile defacto standard has emerged. This topic may be worth some
additional discussion in another thread however.

> Since Andy responded to one person's pointed language in deciding to get
rid
> of Dophin 2.1, consider the same language as repeated here regarding the
> packager.

Hmm.. seems like a rather childish way to provoke a response. But, then
again, it seems to have worked here.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Kirk,

> >Nazi Packager Update:  It now won't UNLOAD any of my packages
> > because they have "Cyclic References."  What does that mean?
> >More important, how do I fix it -- there's no remove cyclic references
> >button on the error message.
>
> Well actually there is, it's just that it's not (and from the above
> discussion you'll see why) completely automatic. In that error message it
> says click "Yes" to show the package prerequisites. So do this, or go to
the
> "Prerequisites" tab in the Package Browser, and try expanding the items in
> the tree. You'll see that each package reports why it depends on the
> previous one in the tree. Most packages are more complicated than this
> example so it helps to right click over a package and choose "Show Status
> Icons". This will highlight the cyclic chain(s) with red crosses.
>
> All you have to do is to expand down this chain until you find a place
where
> the dependencies can be broken. In this case, when you get to package C
> (three levels down) it says "A>>c references global C". One way of fixing
> this would be to move this method (as a loose method) from package A to
> package C. Try it. Suddenly all the red crosses disappear and the packages
> will all save correctly.

I forgot to mention that there is an easier way to repackage items (like
loose methods) especially if there are several of them. Try selecting the
conflicting items in the dependencies (lower) pane of the prerequisites tab.
Then use the "Package.." context menu command to move them to the
appropriate package. The dialog that appears will suggest (usually) the best
package to move them to and will do it in one operation.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Andy,

Thanks much for the excellent Packager documentation!  I would pay an extra
$100 for that quality documentation on the rest of Dolphin...  If I'm not
too unique, that would be $100 times thousands of users which I hope might
make it worth your while.

> without seeing it as one of the blackest areas of computing in the last
100 years.

Ha ha.  I doubt anything about or written in Smalltalk qualifies as that.
There are a few things in Assembler, C, C++, Cobol, and/or Fortran which
might serve in that capacity.  Some Microsoft system programs were in that
catagory which would delete user files or email if something it didn't like
happened.  (Who knows what lurks behind Windows registering your computer on
the net at login nowdays.)  And of course all viruses.

By Nazi I simply meant things that are harder to use than they should be,
could be, or were in earlier generations.  More jack-booted than conspiracy.
In some systems, it's requiring any user interaction at all instead of
automating it.  In other systems, it's inflexability that can't be changed
by the user.  I'm open to another word but "bug" seems reserved for things
that halt causing walkback or which produce incorrect results.  This is more
of an aesthetic concept where the design causes more human effort to get
around or tolerate while grinding teeth instead of appreciating and working
with rejoicing in its coolness or hotness.  Anyone have a better word for
that?

Anyway I'll try your proceedure next time I get cyclicly bound.

Thanks again,
Kirk