Pool Dictionaries ?

I'm trying to figure out how to use Pool Dictionaries
(PDs) in Dolphin 5.1. I looked up the searchable help
http://www.object-arts.com/Search.htm, but there seems
to be precious little of it. I'd like to know:


1. How to create a new pool-dictionary?

I noticed the tool-icon 'Pool Dictionaries'
on the System Folder -window. However, this seems
to be a tool for inspecting PDs only, not for
creating them.

Choosing Help -> Help on this tool took me to
a non-available web-page at:
  http://www.object-arts.com/Lib/EducationCentre5/htm/inspector.htm



2. What is  the PACKAGE associated with a Pool-Dictionary ?

I boldly added a Dictionary to Smalltalk, and it seems I can use it
as a pool-dictionary, as long as its keys are Strings.

Right now I'm trying to save a package that uses my  PD,
but it can't be saved -  perhaps because one of its
pre-requisites is this unpackaged PD. But I don't know
how to associate it with a package.

(double-clicking on the 'unpackaged' pre-requisite causes
an error "Recursion too deep").



3.  How, why and when, should I use the class PoolDictionary
instead of plain Dictionary?

There is also a class called PoolConstantDictionary.
Both of these classes have an empty class-comment.



4. It took me some time to discover the "Pool Dictionaries"
-tool on the System Folder. Is there any reason why this tool
shouldn't be in either the main Tools -menu or the Additional
Tools -menu?



5. Are there any plans for improved Pool Dictionary support
in Dolphin 6?


Thanks
-Panu Viljamaa

"panu" <[hidden email]> wrote in message
news:[hidden email]...
Someone more experienced with pool dictionaries can comment in more detail.
However I think you are on the right track.  I believe what you need to do
is go to the Globals tab of the Package you want to add the pool dictionary
to, and then add it via the "Add Uncommitted..." context menu.  If you do a
Google groups search you can find more discussion about pool dictionaries.

Chris

Christopher J. Demers wrote:

>  I believe what you need to do
> is go to the Globals tab of the Package you want to add the pool dictionary
> to, and then add it via the "Add Uncommitted..." context menu.  If you do a
> Google groups search you can find more discussion about pool dictionaries.
>
Thanks for the help, Chris

I found one way of doing it:  I now send #addGlobalNamed:
to the package I want the  PD to go to, with the key in
Smalltalk where the PD is stored as the argument.

I'll try the "Add Uncommitted" -trick the next time.

-Panu Viljamaa

Maybe my memory (I have currently no machine to check it).

As far as I remember it's enough to specify the PoolDictionary in the
class definition. If this PD is unknown DST asks you whether it should
be created.

CU,

Udo


panu wrote:

panu wrote:

> 1. How to create a new pool-dictionary?

In any workspace evaluate

    MyPool := PoolDictionary new.

Dolphin will prompt to ask if you want to set up a global variable, answer yes.

Alternatively (and this is what I do), just evaluate

    Smalltalk at: #MyPool put: (PoolDictionary new).

In either case, you have now set up a global variable called MyPool that has a
new PoolDictionary as its value.

BTW, I have never (yet) needed or wanted a PoolDictionary as such.  What I do
often use are PoolConstantsDictionaries.  The difference is that the compiler
understands PoolConstantsDictionaries and will treat their entries as
constants, just like literals.  E.g. the Windows API uses /lots/ of defined
constants (usually #defined in various C/C++ header files), and many of those
definitions are duplicated in Dolphin as entries in Win32Constants.  The keys
of a PoolConstantDictionary are Strings and the values are normally Integers,
though I have also used Strings as values sometimes.

BTW2: I find it's better to build the things from code so that I have a record
of what the entries were and can (and do) add comments to explain the values.
If you have any of my code loaded in your image then there's a fair chance that
you'll find class-side methods called #rebuildPoolConstants hanging around.
They don't actually get run, not even when the package is installed, they are
just there for me to re-execute if I want to extend/change the constants and as
a record of why/what the entries are.

One you have created the Pool[Constants]Dictionary, you add its name to the
poolDictionaries clause of the class creation/definition expression of whatever
class(es) will use it, and save.  (I'm sure you knew that, but just for
completeness ;-)


> 2. What is  the PACKAGE associated with a Pool-Dictionary ?

The easiest way to add a Pool to a package is to select "Add
uncommitted=>Global..." from the Package Manager's File menu (or the context
menu in the package list).  That gives you a list of globals from which you can
select the name of your pool.

BTW3: a small warning -- if you decide to remove the pool later, then remove it
from the package /first/, then remove it from the class definitions, then
remove it from the global name space (Smalltalk removeKey: #MyPool), or else
you will end up with walkbacks, and will have a difficult job making your
Package objects coherent enough to save.


> 3.  How, why and when, should I use the class PoolDictionary
> instead of plain Dictionary?

AFAIK, the real difference between a Pool[Constants]Dictionary and a normal
Dictionary is that they "know" that they are going to be used as Pools, and
therefore send change notifications to the system as their contents change.
These notifications allow the system to recompile methods that might need it.
It also allows the 'changed' markers to update properly.


> 4. It took me some time to discover the "Pool Dictionaries"
> -tool on the System Folder. Is there any reason why this tool
> shouldn't be in either the main Tools -menu or the Additional
> Tools -menu?

My guess is that there's not much call for it.  For instance, I don't think
I've used the pool browser more than once or twice ever.  If I want to look at
a pool, I'm more likely just select an occurrence of its name and 'inspectIt'.
In practise, I normally just browse to the appropriate #rebuildPoolConstants
method, which is much easier to read with the related constants grouped
together.


> 5. Are there any plans for improved Pool Dictionary support
> in Dolphin 6?

I'm curious about what kind of improvement you are thinking of.  I think the
current "fashion" in Smalltalk generally is to regard PoolDictionaries as
something of a hack, to be avoided.  (I don't really agree with that attitude,
and I /definitely/ don't agree with it where PoolConstantsDictionaries are
concerned.)

    -- chris

Udo Schneider wrote:
> Maybe my memory (I have currently no machine to check it).
>
> As far as I remember it's enough to specify the PoolDictionary in the
> class definition. If this PD is unknown DST asks you whether it should
> be created.

Clever.  I hadn't realised that, thanks.

I just tied it, hoping that it would automatically add the new Pool to the
class's package.  But it seems to be a little buggy in D5.1.4, the popup asks:

    Pool dictionary 'TmpDictionary' does not exist.
    Proceed to create it as an empty constants pool.
    [Abort]  [Retry] [Ignore]

so I'm not sure which option to select ;-)

(The message could do with a question mark too)

    -- chris

> 1. How to create a new pool-dictionary?

SomeGlobalName := PoolDictionary new.

Caveat: as you noted, there is also PoolConstantsDictionary, and it's
been so long that I've forgotten which is preferred.  Though I probably
could see what I am using and recommend the opposite<g>, a search of the
archives will turn up one of Blair's posts explaining how it should work.

Then follow Chris' advice to package it.  That should fix your problem
saving the package.


> Choosing Help -> Help on this tool took me to
> a non-available web-page at:
>  http://www.object-arts.com/Lib/EducationCentre5/htm/inspector.htm

This is a known problem, and there are instructions to work around it.
For something like this, Ian's archives are likely to be your best
source of information.


> 2. What is  the PACKAGE associated with a Pool-Dictionary ?
>
> I boldly added a Dictionary to Smalltalk, and it seems I can use it
> as a pool-dictionary, as long as its keys are Strings.

That is true, but the pool and pool constants dictionaries add some
useful behavior.  The forementioned post by Blair will explain it.



> 4. It took me some time to discover the "Pool Dictionaries"
> -tool on the System Folder. Is there any reason why this tool
> shouldn't be in either the main Tools -menu or the Additional
> Tools -menu?
>
> 5. Are there any plans for improved Pool Dictionary support
> in Dolphin 6?

This is one of the times when the old saying "be careful what you ask
for because you might get it" comes to mind.  The problem I envision is
that if every gizmo that affects how Dolphin works were to appear in the
user interface, the result would be bloated.  Even in the best case, the
GUI intended to be helpful, by providing commands for common tasks,
would be overwhelming.

IMHO, creating pool dictionaries is a fairly advanced step on the way to
nerdvana (I believe we have Blair to thank for that gem).  It is also a
relatively rare action, so permantently carrying a GUI for it is
arguably inefficient.  Finally, by the time a newbie is ready to take
advantage of it, they should already be past the initial workspace shock
that is part of learning Smalltalk.

Have a good one,

Bill

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

Panu,

> I'm trying to figure out how to use Pool Dictionaries
> (PDs) in Dolphin 5.1. I looked up the searchable help
> http://www.object-arts.com/Search.htm, but there seems
> to be precious little of it. I'd like to know:

Just as a "for your information" ....

One of my goodies is a "Pool Dictionary Browser".  It provides a browser
that enables you to look at all the existing PoolConstantDictionaries, add
and package new ones, add keys and values, search for key definiions and
search the image for key references.

It can be quite useful if you are doing a lot of work with PCDs.

--
Ian

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

Chris Uppal wrote:

> I'm curious about what kind of improvement you are thinking of.

For one thing it would be nice if "Help on this tool" would
take you to an existing web-page. It would be nice to read
a piece of official documentation on "How to create a Pool
Dictionary?", instead of having to experiment and discover
a solution which may or may not be supported in the next
version of Dolphin.

So, I was able to create a PoolDictionary. But it still
doesn't show in the "Pool Dictionaries" -tool of the
System Folder. Making it appear there would be one way
of better supporting the use of Pool Dictionaries.


>  I think the
> current "fashion" in Smalltalk generally is to regard PoolDictionaries as
> something of a hack, to be avoided.


PoolDictionaries have been with Smalltalk for a long time.
They are not a 'hack'. Dolphin itself uses a lot of them,
which seems to indicate they are useful.  And whether they
are useful or not, they still are a standard part of Smalltalk.

-Panu Viljamaa

panu wrote:

> So, I was able to create a PoolDictionary. But it still
> doesn't show in the "Pool Dictionaries" -tool of the
> System Folder.

Then you have done something wrong.  Did you follow the steps as I suggested ?
That's how /I/ create PoolConstantsDictionaries, and they all appear in the
Pool Browser window OK.  (Incidentally, the "pool browser" isn't really a
separate tool, it's just an inspector opened on a list of those globals that
happen to be PoolDictionaries or PoolConstantsDictionaries -- take a look at
the code).


>  I think the
> > current "fashion" in Smalltalk generally is to regard PoolDictionaries
> > as something of a hack, to be avoided.
>
> PoolDictionaries have been with Smalltalk for a long time.

I know.


> They are not a 'hack'.

I didn't say they were, I said there was a fashion for seeing them that way.


> Dolphin itself uses a lot of them,
> which seems to indicate they are useful.

Actually, I think that you'll find that the only PoolDictionaries Dolphin uses
are part of the (hidden) /implementation/ of "class variables".  There are no
globals that are PoolDictionaries.

There are plenty of PoolConstantsDictionaries, though.  (Which, I /think/ are
not part of "classic" Smalltalk.  Presumably an innovation in one of the
side-branch Smalltalk implementations from which OA took inspiration.)

    -- chris

Hi,
"Chris Uppal" <[hidden email]> wrote Global variables ( including packages names, class names, class variables,
PDs etc.) if used frequently would flood and easily cause name conflicts in
a multi-user image system if Dolphin is used that way, that's why VW turned
to categorized them all inside the term of NameSpace in later versions.

I think name conflicts are always a pain when adopting Dolphin as a
long-running system .

I used to run it that way for time as long as I could, Dolphin will alert
'package or class alreaday installed error' when installing packages or
classes of the same names, I must carefully choose the namse or hope others
not using the same names to avoid that condition, otherwise I must open
another new image in order to install them, which violate our purpose of
using it as a 'system'.

Hope there are solutions to overcome it if this is a good Smalltalk style
( maybe DST is just built as the Basic language for Smalltalk and used to
produce deployed executables mainly).

Just a curious question....


Tk Kuo

kuo wrote:

> Hope there are solutions to overcome it if this is a good Smalltalk style
> ( maybe DST is just built as the Basic language for Smalltalk and used to
> produce deployed executables mainly).
>
> Just a curious question....

Do you find many name clashes ?  Can you give any examples ?

I use Dolphin as a long-running system too, and it hasn't been much of a
problem for me /so far/.

The three main places that clashes can happen are names of packages, names of
classes (and other globals), and names of methods.

So far I haven't seen a package name clash -- maybe I'm just lucky, but I think
an important part of it is that most people have adopted the convention
(started, IIRC, by Ian Bartholomew) of prefixing the package name with some
sort of identifier.  I use 'CU ', Ian uses 'IDB ', Steve Waring uses a more
complicated system, but it has the same effect, and so on.  And, of course,
it's not difficult to rename a package file before loading it into Dolphin.

Class name clashes: In /general/ I find that if the class is named properly
(with a good descriptive name), then there's not much chance of a class.  But
still it can happen.  More usually, what happens is that I can't use the name I
want to because someone else has already used it for something else (e.g.
TreeListPresenter, UnicodeString, ...)

Method name clashes: these can be a nuisance, I find.  There are two types:
where the meaning or the two methods is the same, and where it is different.
If the meaning is the same then I think it'd be a welcome improvement to the
package system if a new package could hide (but not destroy) an existing method
with the same name.  If they /don't/ have the same meaning, then I think the
problem gets too complicated to consider solving -- it's just something to live
with...

(There are other potential clashes too: event names, resource names, maybe a
few others, but they don't seem to be much of a problem at all)

    -- chris

"Chris Uppal" <[hidden email]>wrote:
> Do you find many name clashes ?  Can you give any examples ?
>
   How about imagining the the situation that when I wanted to install the
same package of different version again into the same running image, for the
purposes such as comparision of performance, on-line live test of different
change effects, fine tuning of various aspects, or even reconfiguration of
the MVP artitecture etc without the labors of uninstalling or running
another image in parallel ( thread?) on a slow machine without too much
system resources available.  IT is just my assumption that someday OS on
multi-processor MBs with true multitask capability is the mainstream,
Dolphin might need to grow to that extent for concurrent processing of any
tasks demanded.


Best regards,

tgg:>

kuo wrote:

> > Do you find many name clashes ?  Can you give any examples ?
> >
>    How about imagining the the situation that when I wanted to install the
> same package of different version again into the same running image, for
> the purposes such as comparision of performance, [...]

Interesting idea. I have no idea how to solve it, though.

Actually, I'd be more inclined to work with two instances of the Dolphin
program running at once (as separate OS-processes) -- I think it would be more
reliable in several ways, not just the name clash issue.  The /interesting/
thing would be linking the two images together so that you weren't forced to
duplicate every action in both image.

I think it should be possible to "fork" (in the Unix sense) the image. It would
take some mucking around, but Dolphin could save the current image to a
temporary file and then launched a new instance of itself as a "slave" child.
The slave would read its state from the temp file, then delete it.  It would
then arrange to share the original process's .SML file and would either share
the .CHG file (but readonly) or would start a new .CHG file for itself
(presumably a temp file) whilst continuing to use /existing/ source descriptors
that point to the original change file.  Lastly it would open some sort of
connection to the original process (a TCP/IP link, perhaps) and wait for
commands...

Hmmm...

    -- chris

"Chris Uppal" <[hidden email]> wrote
> Actually, I'd be more inclined to work with two instances of the Dolphin
> program running at once (as separate OS-processes) -- I think it would be
> more
> reliable in several ways, not just the name clash issue.  The
> /interesting/
> thing would be linking the two images together so that you weren't forced
> to
> duplicate every action in both image.
Good point.
Sqeak is morphing its way to become a stand-alone operation system on its
own.
Forth has such capability too, to live on a single chip, it is using its
unique Vocabulary structure to prevent name clash/conflict anomalies.
Smalltalk might use some image-based cyber space structure to set up a huge
living objects environment across the Internet ( There is a NetSqeak
implemented on Squeak with different images running on distributed
environment working as a one, the objects represented with their GUI morphs
on one image could be shared and sent easily, seamlessly and transparently
across the internet boundary to another one's image).
This won't a issue if Smalltalk is already an OS on its own.


Best regards,

Tk Kuo