Dolphin Smalltalk v. Smalltalk MT

Forum,

We have pretty much settled on Dolphin as the Smalltalk implementation
of choice (the decision finally came down to Dolphin or MT).  But MT
does have a couple of features that are useful and productive, and I
was would like to know if perhaps the functionality already exists in
Dolphin, but maybe not so straightforward.

1. Concerning the embedding of an ActiveX component in a view, MT
offers a simple way to execute the primary verb of a control.  I can't
seem to find that funtionality in Dolphin.  I would like to use
Codejock's ActiveX-based UI controls: The CommandBars control offers a
design environment that can save to a layout file.  That envionrment is
invoked via the primary ver.  How do I do this in Dolphin?

2. Again concerning the embedding of ActiveX, MT offers a way to
interactively invoke methods on the control in situ in order to
experiment with the control.  Is there a way to do this in Dolphin?

3. It appears to me that Dolphin supports multi-threading, but the
support is obfuscated slightly by my lack of knowledge of the Smalltalk
philosophy (i.e. cooperative multi-threading and a high level of
abstraction).  MT seems to wear multi-threading on its sleeve, and its
method of invocation is almost identical to WIN32's.  Does Dolphin
support multi-threading in a manner that I would expect; i.e. in a
manner consistent with the WIN32 approach?

4. Has anyone addressed OLEDB in Smalltalk?  MT includes it in their
professional version, including MS SQL Server and MS SQL Server Express
wrappers.  On the note of database connectivity, what's the Community's
opinion on ReStore?  The website appears to be a little stale, but I'm
not sure (it might be that the product is just that solid).

Thank you.

Eric

Eric,

> 2. Again concerning the embedding of ActiveX, MT offers a way to
> interactively invoke methods on the control in situ in order to
> experiment with the control.  Is there a way to do this in Dolphin?

The ActiveX Control Browser will probably do what you want.


> 3. It appears to me that Dolphin supports multi-threading, but the
> support is obfuscated slightly by my lack of knowledge of the Smalltalk
> philosophy (i.e. cooperative multi-threading and a high level of
> abstraction).  MT seems to wear multi-threading on its sleeve, and its
> method of invocation is almost identical to WIN32's.  Does Dolphin
> support multi-threading in a manner that I would expect; i.e. in a
> manner consistent with the WIN32 approach?

Yes and no.  Dolphin has a mechanism for marking external functions (in
a DLL) as "overlapped" so they run on a separate OS thread.  Between
that to keep external code from freezing up your image and Dolphin's
"green threads", you can do very effective background processing.
AFAIK, Dolphin does not as yet allow a way to call COM component methods
on other than the main Dolphin thread.


> 4. Has anyone addressed OLEDB in Smalltalk?  MT includes it in their
> professional version, including MS SQL Server and MS SQL Server Express
> wrappers.  On the note of database connectivity, what's the Community's
> opinion on ReStore?  The website appears to be a little stale, but I'm
> not sure (it might be that the product is just that solid).

I have not used it, mostly because I had an OO-RDB mapping from my
pre-Dolphin days.  Note that ReStore wants to control the schema, which
is either a lot of help or a limitation, depending on the type of work
you do.


Have a good one,

Bill

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

Bill,

Thank you for your reply.

> The ActiveX Control Browser will probably do what you want.

I have explored this browser, but there isn't an obvious way to either
invoke the primary verb, or invoke methods in situ.

> Note that ReStore wants to control the schema...

What exactly do you mean by this?

Eric

[hidden email] escribió:
> Bill,
>
> Thank you for your reply.
>
>> The ActiveX Control Browser will probably do what you want.
>
> I have explored this browser, but there isn't an obvious way to either
> invoke the primary verb, or invoke methods in situ.

What do you mean by primary verb?
Does the control in question provides an IDispatch interface?

>> Note that ReStore wants to control the schema...
>
> What exactly do you mean by this?

With ReStore you define your domain model objects, and ReStore
creates the schema according to his own rules,
you can't define the schema, or the table names, etc.

AFAIR, it's a solid product, being the most commercial solution used for
O/R persistence (according to an online survey).

Regards,

--
Esteban

[hidden email] wrote:

> 1. Concerning the embedding of an ActiveX component in a view, MT
> offers a simple way to execute the primary verb of a control.  I can't
> seem to find that funtionality in Dolphin.

Presumably, it would involve sending
#doVerb:msg:activeSite:parentView:rectangle: to your
IOleObject with a parameter of OLEIVERB_PRIMARY (0), but I have no idea what
the other parameters should be.

(Yes, I realise that's not much help, but since I was replying anyway... ;-)


> 2. Again concerning the embedding of ActiveX, MT offers a way to
> interactively invoke methods on the control in situ in order to
> experiment with the control.  Is there a way to do this in Dolphin?

The centre pane of the ActiveX Control Browser is a full workspace, you can
execute any code you want there.  "self" is bound to the selection in the tree
on the left. Or is that not what you meant ?


> 3. It appears to me that Dolphin supports multi-threading, but the
> support is obfuscated slightly by my lack of knowledge of the Smalltalk
> philosophy (i.e. cooperative multi-threading and a high level of
> abstraction).

Dolphin is pre-emptively (not cooperatively) multitasked within a single OS
thread.  The only support for executing multiple real threads is via the
overlapped call mechanism.  That is be used to execute external calls in
separate OS threads without blocking the entire Dolphin image (only the
Smalltalk Process which made the call).  In D6 the thread is bound to the
calling Process and the same thread will be used for all future overlapped
calls by that Process.

External callback from non-Dolphin threads are marshalled across to the
Smalltalk thread transparently to the caller, but of course there is an
execution cost, and there may also be deadlock issues.


> MT seems to wear multi-threading on its sleeve,

Hence the name ;-)   MT uses OS threads, and so its threading is /very/
different from (generally superior to) Dolphins.


> and its
> method of invocation is almost identical to WIN32's.

That's an example of the general difference in philosophy between MT and
Dolphin.  Dolphin attempts to provide properly designed abstractions of
services which are ultimately implemented in the OS (or by other external
DLLs).  MT just hits you with 'em raw...

    -- chris

Please note,

>
> With ReStore you define your domain model objects, and ReStore
> creates the schema according to his own rules,
> you can't define the schema, or the table names, etc.

ReStore does define the schema and generate the database tables based
on the names of your Smalltalk classes. However, once the tables have
been generated, you can change the name of the tables. This is required
due to the fact that in Smalltalk, class names may change during design
or re-design of a given application. This allows the object world and
or mapping to stay in synch. It also allows you to create more
meaningful names for database tables.

The following is a link to the ReStore docs regarding the topic:

http://www.solutionsoft.co.uk/restore/manual/customising4.htm


I would imagine, future versions of ReStore may allow developers to
access or modify the database schema thus allowing some degree of
control. But, thats just my two cents worth.

Pax

<[hidden email]> wrote in message
news:[hidden email]...
You could use the same approach as in AXControlSite>>editControlProperties,
alternatively just add an extension method like this, and then you can do it
as simply as 'site doVerb: 0'.

!AXControlSite methodsFor!

doVerb: anInteger
 ^(self controlUnknown queryInterface: IOleObject)
  ifNil: [self controlUnknown hresultError: E_NOINTERFACE]
  ifNotNil:
   [:oleObj |
   | hr |
   hr := oleObj
      doVerb: anInteger
      msg: nil
      activeSite: (self hostInterface queryInterface: IOleClientSite)
      parentView: self
      rectangle: self clientRectangle.
   oleObj free.
   hr]! !
!AXControlSite categoriesFor: #doVerb:!public! !

Remember you always have the option in Smalltalk of extending the base
classes (or modifying them, although this is a priviledge that should be
used with caution). If you think an extension (such as the above) might be
generally useful and you want to save yourself the trouble of maintaining it
in future, you can lobby to have it included in the base release. In this
case it is already in the next minor release :-)

>
> 2. Again concerning the embedding of ActiveX, MT offers a way to
> interactively invoke methods on the control in situ in order to
> experiment with the control.  Is there a way to do this in Dolphin?

You can either generate the interface(s) and then just execute methods in an
inspector (e.g. the one in the AXControlBrowser). Generating the control
interfaces has a lot of advantages, among them is that you will get
auto-completion.

Alternatively you can use the convenience methods on IDispatch, i.e.
#invoke:[with:]*. These allow you to invoke an arbitrary method by name, and
to pass appropriate arguments. You can also make use of the "message not
understood" handling done by IDispatch - it will attempt to map messages it
does not understand onto invocations of methods in the control. However it
does this entirely through IDispatch, and does not use type info even if
available, and hence it is not really that useful. A particular problem is
that the syntax of Smalltalk does not allow one to distinguish between
property assignments and method invocations. It is possible that this will
be improved in a future release - there is quite a lot in the newsgroup
archive on the subject.

>
> 3. It appears to me that Dolphin supports multi-threading, but the
> support is obfuscated slightly by my lack of knowledge of the Smalltalk
> philosophy (i.e. cooperative multi-threading and a high level of
> abstraction).  MT seems to wear multi-threading on its sleeve, and its
> method of invocation is almost identical to WIN32's.  Does Dolphin
> support multi-threading in a manner that I would expect; i.e. in a
> manner consistent with the WIN32 approach?

Dolphin currently implements only "green threads", much akin to Win32
"fibers". You can do native API calls on other threads, however, by marking
the calls as overlapped.

>
> 4. Has anyone addressed OLEDB in Smalltalk?  MT includes it in their
> professional version, including MS SQL Server and MS SQL Server Express
> wrappers.  On the note of database connectivity, what's the Community's
> opinion on ReStore?  The website appears to be a little stale, but I'm
> not sure (it might be that the product is just that solid).

I can only speak for Dolphin, in which case I've not heard of anything,
although it could be done. The only support we have for using OLEDB is
through ADO.

Regards

Blair

Esteban,

I apologize for taking so long.  I've been swamped.

>What do you mean by primary verb?
>Does the control in question provides an IDispatch interface?

ActiveX controls sometimes define one or more verbs that allow external
connection to the control, but not necessarily interaction, as is the
case through IDispatch.  For example, with Codejock's
XtremeCommandBars, the primary verb invokes the CommandBars Designer,
where you can define your menus and/or toolbars and even save the
layout to a layout file that can be dynamically loaded or swapped out
at runtime.  Now, this is not really an integral feature of the
control, but rather a design interface onto the control.  An analogy
would be the difference between the VC and simply issuing "SomeView
show" in a workspace.

But it looks like Mr. McGlashan answered my question in detail.  It
might instructive to you as well.

>AFAIR, it's [ReStore's] a solid product, being the most commercial solution used for
>O/R persistence (according to an online survey).

Yes, it looks very promising indeed, but I think we're going to go with
Gemstone/S and GemBuilder as a longer-term solution to OODBMS.  We're
still in the evaluation phase of choosing a database paradigm.

Eric

Pax,

Thank you for the specific link.

So, it would seem that ReStore is not stale after all.  I say that
because you wrote of "future versions."  The website shows 2003 as the
last time there were any significant updates.

Eric

Chris,

I apologize for taking so long to respond.

>Presumably, it would involve sending
>#doVerb:msg:activeSite:parentView:rectangle: to your
>IOleObject with a parameter of OLEIVERB_PRIMARY (0), but I have no idea what
>the other parameters should be.

Yes, that is quite helpful, and together with Mr. McGlashan response,
tells me everything I need to know.

>The centre pane of the ActiveX Control Browser is a full workspace, you can
>execute any code you want there.  "self" is bound to the selection in the tree
>on the left. Or is that not what you meant ?

The ActiveX Control Browser is awesome!  You pointed me in the right
direction.  I simply generate the interface and load the control into
the ACB, and I'm free to play around with the control in ways I've
never been able to before (by that I mean in such a dynamic way).
Dolphin's ACB blows MT's away.

>External callback from non-Dolphin threads are marshalled across to the
>Smalltalk thread transparently to the caller, but of course there is an
>execution cost, and there may also be deadlock issues.

This one concerns me, but I'll have to table the issue for now.  We
have a laundry list entitled "Can Dolphin Do This...?"  Multi-threading
is down a ways, but in any case, out-of-process solutions are always
possible, and I'm pretty comfortable with how to get data and calls
back and forth across process boundaries.

>That's an example of the general difference in philosophy between MT and Dolphin.

I've begun to see that there is an infinitude of differences between
Dolphin and MT.  I could see purchasing MT in addition to Dolphin, but
only as a WIN32 playground.  It's very easy in MT to try out WIN32
calls in the same dynamic way that one can experiment with ActiveX
controls in the ACB, which is worth the $99 price tag of the personal
edition.  I don't mean to suggest that Dolphin can't do this, but it
would seem that MT was designed specifically with this in mind.

Thank you for your great advice and direction!

Eric

GemStone is a wonderful database system to work with, particularlly if you
are using a smalltalk client.

There are some tricks you can use with copy on update and such to make an
object model sing in GemStone.  Because the object model (Smalltalk) is so
familiar, and the support for rich structure is there you have lots of good
options for representing a problem.  The conflict free collections also make
a big difference in creating a transactional scaleable solution.  Their new
64 bit VM can handle a huge number of objects, and a ton of shared memory.

Highly recommended.

Michael


<[hidden email]> wrote in message
news:[hidden email]...

Blair,

Thank you for your reply!

>Remember you always have the option in Smalltalk of extending the base
>classes (or modifying them, although this is a priviledge that should be
>used with caution). If you think an extension (such as the above) might be
>generally useful and you want to save yourself the trouble of maintaining it
>in future, you can lobby to have it included in the base release. In this
>case it is already in the next minor release :-)

I'm beginning to catch on concerning the extensibility of Smalltalk.
I've grown so accustomed to fetters that it's going to be tough to
adapt at first.  Thank you for converting my naive question into an
addition to the base :-).  As for the code fragment you provided, I'm
still digesting it.  I'm new to the practice of Smalltalk; my knowledge
of it has been strictly theoretical, as point and counterpoint to
Eiffel.

>You can either generate the interface(s) and then just execute methods in an
>inspector (e.g. the one in the AXControlBrowser). Generating the control
>interfaces has a lot of advantages, among them is that you will get
>auto-completion.

Yes, yes!  I experimented with this for at least half a day yesterday,
and it's wonderful to be able to play with an ActiveX control so
dynamically.  MT's ActiveX browser has nothing on yours.  I see the
advantage--one could say, necessity--of generating the interface to the
control, but #invoke:with: will certainly come in handy for those
features of a control that have either not been exposed properly or not
been exposed clearly by the control's designers.

>Dolphin currently implements only "green threads", much akin to Win32
>"fibers". You can do native API calls on other threads, however, by marking
>the calls as overlapped.

This is the answer that says it all.  O.K., now I have a frame of
reference that I can work with.

>I can only speak for Dolphin, in which case I've not heard of anything,
>although it could be done. The only support we have for using OLEDB is
>through ADO.

This is sufficient for now, and ADO is quite robust, some complaints
against it notwithstanding.

Cheers.

Eric

Michael,

>GemStone is a wonderful database system to work with, particularlly if you
>are using a smalltalk client.

I've been reading the documentation over the weekend, and I'm very
excited.  I put a call into their headquarters at the suggestion of
their regional office in California concerning reporting tools.  I
should get a call back Monday.

My only concern at this point is just that: reporting tools.  Is there
some kind of [conventional] interface to the database so that reporting
tools like Crystal could get to the data?  Or are there tools out there
already?  I think GemConnect might be the answer, but I'm not sure.  It
seems to focus more on pass-through access to conventional
repositories.

Incidentally, what is the cost of GemStone/S and GemStone/S 64?  They
don't have prices on their website, which usually means one has to take
out a home equity loan :-)

Cheers.

Eric

I am not sure what the current pricing is.  I believe that they understand
that they are competing in a world of free open source databases and
commercial databases like SQL Server that start at about $1000 per server or
are $5000 for unlimited users on one box.  I would hope their pricing is in
line with the competition, with at most a small margin for their unique
position.  On large server installations I imagine the numbers are large
just like all the other commercial servers.  If you want to run on a Sun
mainframe it will cost you.

I think the GemConnect product is the only thing that might make it
available for conventional reporting uses. In general it is not a good idea
to report directly on the operational database anyway unless you oversize
the server as reporting can hig a system hard when mixed with short
interactive response time driven database transactions.  You can always have
code in GemStone that continually exports data to a reporting database that
is an SQL database using GemConnect if it does not work well enough for
directly reporting on GemStone.  I imagine they have encoutnered this many
times before.

Michael


<[hidden email]> wrote in message
news:[hidden email]...