This is addressed to anyone familiar with VW Smalltalk/Opentalk and Allegro
CLOS/CORBA.
I am currently working on a hobby project to use clustered computers to gang
tackle a search algorithm. My plan is to have one head machine coordinating
the work of a lot of other slave machines over a network using a high-level
object protocol. This head machine will dispatch computing jobs to the
slave machines, collate the answers, and do load balancing where necessary.
The head node will also be running an object database to store data used in
the computations.
While I have done a lot of the design already, I am having some difficulty
deciding between the following two alternatives for implementation
language/distributed object protocol:
1. VWSmalltalk + Opentalk.
2. Allegro Lisp/CLOS + CORBA.
My initial instinct is to use CLOS, as my logic and domain model are
possibly too hairy for even Smalltalk to handle cleanly. However, the VW
Opentalk tool, which I have toyed with, seems _much_ easier to use than the
Allegro's CORBA facilities, on which I have only read some tutorials.
So my question is this: how easy is it to use the Allegro's CORBA facilities
for a project such as this, particularly when compared to Opentalk?
-Kris
From: Philip Lijnzaad
Subject: Re: Smalltalk + Opentalk or CLOS + CORBA? Long Question.
Date:
Message-ID: <u7snxhaiff.fsf@o2-3.ebi.ac.uk>
On Mon, 20 Mar 2000 04:16:49 GMT,
"Kris" == Kris Prieb <·············@post.harvard.edu> writes:
Kris> While I have done a lot of the design already, I am having some difficulty
Kris> deciding between the following two alternatives for implementation
Kris> language/distributed object protocol:
Kris> 1. VWSmalltalk + Opentalk.
Kris> 2. Allegro Lisp/CLOS + CORBA.
I have no experience with either (but I do with java/C++ etc. + CORBA), but
if OpenTalk is SmallTalk only, then go for the CORBA solution: it allows
adding clients and servers written in different languages. Could be useful
for 'legacy' code (or number crunching code or whatever). Also, CORBA can be
obtained from various places, and is known to scale well (because a
distributed object, which is an abstraction, does not have to be represented
by exactly one implementation language object and vice versa: one distributed
object can be served by several implementation objects, and one
implementation object can 'pose' as several distributed objects).
Cheers,
Philip
--
Not getting what you want is sometimes a wonderful stroke of luck.
-----------------------------------------------------------------------------
Philip Lijnzaad, ········@ebi.ac.uk | European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
From: ········@my-deja.com
Subject: Re: Smalltalk + Opentalk or CLOS + CORBA? Long Question.
Date:
Message-ID: <8bdhm8$40q$1@nnrp1.deja.com>
I cannot claim deep familiarity with Allegro, but maintain a
CORBA ORB (DST) and am actively involved in elaborating
Opentalk.
Opentalk is
[1] easier, because you do not have to deal with IDL,
[2] potentially faster than the competing CORBA
option, because it has a very small core,
[3] more flexible, because it does need to maintain
close fidelity to the CORBA specification, and
[4] potentially more useful, because it now supports
[a] remote inspection,
[b] remote browsing (more than less), and
[c] distributed debugging (barring a known
glitch in remote 'proceed'),
and will -- but only if the Fates allow -- support
interesting additional functionality of this kind in
the next release.
Opentalk's drawbacks are
[1] that it is new and raw at every level except the
communication core (which has been stable for
a long while),
[2] that it is now incomplete, particularly in regard to
supporting all possible remote browser operations,
and
[3] that it won't work in a heterogeneous environment.
'Hope this helps. Personally, I'd like you to use Opentalk,
but it's your call.
In article <·····················@typhoon.ne.mediaone.net>,
"Kris Prieb" <·············@post.harvard.edu> wrote:
> This is addressed to anyone familiar with VW Smalltalk/Opentalk and Allegro
> CLOS/CORBA.
>
>....
>
> So my question is this: how easy is it to use the Allegro's CORBA facilities
> for a project such as this, particularly when compared to Opentalk?
>
> -Kris
Sent via Deja.com http://www.deja.com/
Before you buy.
Thanks Philip and lutomski for your helpful comments on my query!
I've looked more deeply into CORBA, particularly the IDL bindings to CLOS
and it just gets hairier and hairier so I am probably going to go with
Opentalk, mostly for the reasons you mentioned, lutomski. I have no need
for connection to legacy systems or for language interoperability so that is
not an issue.
Lutomski, that's so cool that you are involved in the beta testing of
Opentalk! Do you have any guesses as to:
1. when it might be released?, and
2. with what kind of functionality?
As regards the first question, I am kind of operating on the assumption it
will occur by the summer of 2000. Think this is a safe assumption?
As regards the second question, lack of remote browsing and debugging really
doesn't bother me as I will have easy console access to all the machines I
will be developing on. What I am most concerned with is the core non-IDE
functionality. I want to be able to write distributed apps that work. Do
you know if the current beta is already functionally complete in that sense?
Is it already possible to develop distributed apps with the beta or is there
still some missing functionality preventing this or making this a bad idea
somehow? I guess my question really is: Can I go ahead and use the beta and
expect the resulting image to work with the production release?
Thanks for any info proffered!
Kris
<········@my-deja.com> wrote in message ·················@nnrp1.deja.com...
> I cannot claim deep familiarity with Allegro, but maintain a
> CORBA ORB (DST) and am actively involved in elaborating
> Opentalk.
>
> Opentalk is
> [1] easier, because you do not have to deal with IDL,
> [2] potentially faster than the competing CORBA
> option, because it has a very small core,
> [3] more flexible, because it does need to maintain
> close fidelity to the CORBA specification, and
> [4] potentially more useful, because it now supports
> [a] remote inspection,
> [b] remote browsing (more than less), and
> [c] distributed debugging (barring a known
> glitch in remote 'proceed'),
> and will -- but only if the Fates allow -- support
> interesting additional functionality of this kind in
> the next release.
>
> Opentalk's drawbacks are
> [1] that it is new and raw at every level except the
> communication core (which has been stable for
> a long while),
> [2] that it is now incomplete, particularly in regard to
> supporting all possible remote browser operations,
> and
> [3] that it won't work in a heterogeneous environment.
>
> 'Hope this helps. Personally, I'd like you to use Opentalk,
> but it's your call.
>
>
> In article <·····················@typhoon.ne.mediaone.net>,
> "Kris Prieb" <·············@post.harvard.edu> wrote:
> > This is addressed to anyone familiar with VW Smalltalk/Opentalk and
Allegro
> > CLOS/CORBA.
> >
> >....
> >
> > So my question is this: how easy is it to use the Allegro's CORBA
facilities
> > for a project such as this, particularly when compared to Opentalk?
> >
> > -Kris
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
From: ········@my-deja.com
Subject: Re: Smalltalk + Opentalk or CLOS + CORBA? Long Question.
Date:
Message-ID: <8bgkdj$hso$1@nnrp1.deja.com>
I cannot make promises about release dates or functionality.
It's just not my job.
The non-IDE, core piece is complete on the assumption that
you do not need specialized server connection types (that,
for example, use a process farm rather than forking a new
process for every request) or other such sophistications.
If you do need them, they are not hard to make within the
present GenericProtocol hierarchy. It was built to support
easy extension.
There is no serious lacuna in the core, that we know about,
hindering the development of an Opentalk application. I
have built custom Opentalk plugin images, used Opentalk to
see inside of headless images, et cetera.
As I said, the core has been stable for a while. If your
code only sparsely relies on the machinery outside of the
core -- the machinery now in the 'RemoteTools' parcels is
considered to be the labile, non-core section of the code
-- you *should* find it quite easy to migrate to the com-
ing release.
Make sure you start with the latest beta refresh, the one
put out on or shortly after 17Feb00.
In article <······················@typhoon.ne.mediaone.net>,
"Kris Prieb" <·············@post.harvard.edu> wrote:
> Thanks Philip and lutomski for your helpful comments on my query!
>
> .... Do you have any guesses as to:
>
> 1. when it might be released?, and
> 2. with what kind of functionality?
>
> .... Do you know if the current beta is already functionally
>complete in that sense? Is it already possible to develop
>distributed apps with the beta or is there still some missing
>functionality preventing this or making this a bad idea somehow?
>I guess my question really is: Can I go ahead and use the beta
>and expect the resulting image to work with the production
>release?
>
> ....
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Courageous
Subject: Re: Smalltalk + Opentalk or CLOS + CORBA? Long Question.
Date:
Message-ID: <38DB271F.F78A3C39@san.rr.com>
> Thanks Philip and lutomski for your helpful comments on my query!
> I've looked more deeply into CORBA, particularly the IDL bindings to CLOS
> and it just gets hairier and hairier...
You know, if you're willing to wite your lisp objects with
:type tags in the slot definitions, it isn't to hard to use
some of the more esoteric CLOS/MOP functions to write some
kind of simple serializer which will generically serialize
lisp objects into some portable format. With a little work,
you can get these same serializations read into C++ or Java
very easily; as long as the transaction count isn't high,
the serializations can just be plain text. Or you can just
use the lisp s-expression format and write your C++ or Java
deserializers to understand that...
C/
On Mon, 20 Mar 2000 04:16:49 GMT, "Kris Prieb"
<·············@post.harvard.edu> wrote:
> I am currently working on a hobby project to use clustered computers to gang
> tackle a search algorithm. My plan is to have one head machine coordinating
I wish I had all that metal for my hobby projects :) Have (de)fun,
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: dave linenberg
Subject: Re: Smalltalk + Opentalk or CLOS + CORBA? Long Question.
Date:
Message-ID: <38DAD98C.CAF795DB@home.com>
Kris Prieb wrote:
> This is addressed to anyone familiar with VW Smalltalk/Opentalk and Allegro
> CLOS/CORBA.
>
> I am currently working on a hobby project to use clustered computers to gang
> tackle a search algorithm
The usual methodology for high powered distributed computing is to use
something like PVM or MPI.
Other solutions could involve java (see ObjectSpace's Voyager product for some
good insight into distributed computing/ agent technology). (I have been told
that Allegro 6.0 will support Java, and I recall point & click solutions came
out with a product that currently supports the windows and sun platforms.) or
corba.
Of course, corba is supported by several lisps.
And don't forget that Lisp has remote procedure call packages as well as
support Berkely sockets and threads.
The point is, there are _a_lot_ of ways to skin a cat when you talk about
distributed computing. None of them I have looked at are all that elegant.
They are certainly all worth looking at - in order to gain an understanding- of
the issues involved in distributed computing, and at which level of complexity/
elegance/ speed you need for your particular application.
I can say that since I started learning Lisp, I never really *want* to go back
to C/C++, (or any language, for that matter) except to write foreign function
interfaces to Lisp!!
Dave Linenberg
Thanks for the advice, Dave!
-Kris
"dave linenberg" <········@home.com> wrote in message
······················@home.com...
>
> The usual methodology for high powered distributed computing is to use
> something like PVM or MPI.
>
Yeah, I thought about that, but it seems too hairy. I want to stick to with
higher-level object protocols and languages. Programming ease and
maintenance are bigger factors for me than performance - hence LISP or
Smalltalk only! I figure I can always add more machines to the cluster if
things are too slow. The algorithm I am thinking of is very easily
parallelized.
> Other solutions could involve java (see ObjectSpace's Voyager product for
some
> good insight into distributed computing/ agent technology). (I have been
told
> that Allegro 6.0 will support Java, and I recall point & click solutions
came
> out with a product that currently supports the windows and sun platforms.)
or
> corba.
Yes, I've read some amazing things about Voyager.
> And don't forget that Lisp has remote procedure call packages as well as
> support Berkely sockets and threads.
Could you refer me to some info on these packages? I'd like to look into
that some more.
>
> The point is, there are _a_lot_ of ways to skin a cat when you talk about
> distributed computing. None of them I have looked at are all that
elegant.
>
You might want to look at Opentalk for Visualworks. If you like Smalltalk
and are willing to forego language interoperability you can get a
wall-to-wall Smalltalk solution that doesn't require the use of IDL or
CORBA. I've only toyed with it though so I may not be aware of more subtle
difficulties. I believe IBM's VA Smalltalk has a similar non-CORBA
solution.
> I can say that since I started learning Lisp, I never really *want* to go
back
> to C/C++, (or any language, for that matter) except to write foreign
function
> interfaces to Lisp!!
I have similar sentiments, but it seems like once you throw CORBA and IDL
into the mix things become very unlispy and hairy. What I'd really like is
for the LISP vendors to come up with a LISP-only distributed computing
solution that keeps that lispy feel.
On Fri, 24 Mar 2000 05:45:16 GMT, "Kris Prieb"
<·············@post.harvard.edu> wrote:
> "dave linenberg" <········@home.com> wrote in message
> ······················@home.com...
[...]
> higher-level object protocols and languages. Programming ease and
> maintenance are bigger factors for me than performance - hence LISP or
> Smalltalk only! I figure I can always add more machines to the cluster if
> things are too slow. The algorithm I am thinking of is very easily
> parallelized.
You may be interested in the following paper:
"NetCLOS and Parallel Abstractions - Actor and Structure Oriented
Programming on Workstation Clusters with Common Lisp"
Lothar Hotz and Michael Trowe
Email: hotz AT informatik DOT uni-hamburg DOT de
Proceedings of the European Lisp User Group Meeting '99
Abstract:
In this paper, we describe an extension of Common Lisp which allows the
definition of parallel programs within that functional and
object-oriented language. In particular, the extensions are the
introducing of active objects, sending synchronous and asynchronous
messages between them, automatic and manual distribution of active
objects to object spaces, and transparent object managing. With these
extensions, object-oriented parallel programming on a workstation cluster
using different Common Lisp images is possible. These concepts are
implemented as an extension of Allegro Common Lisp subsumed by the name
NetCLOS. Furthermore, it is shown how NetCLOS can be used to realize
parallel abstractions for implementing parallel AI methods at a highly
abstract level.
> > And don't forget that Lisp has remote procedure call packages as well as
> > support Berkely sockets and threads.
> Could you refer me to some info on these packages? I'd like to look into
Martin Cracauer has a document reviewing most--if not all--Common Lisp
thread interfaces at his Web site:
http://www.cons.org/cracauer/
look for the document titled "Thread Interfaces for Common Lisp"
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
"Paolo Amoroso" <·······@mclink.it> wrote in message
·································@4ax.com...
>
> You may be interested in the following paper:
>
> "NetCLOS and Parallel Abstractions - Actor and Structure Oriented
> Programming on Workstation Clusters with Common Lisp"
> Lothar Hotz and Michael Trowe
> Email: hotz AT informatik DOT uni-hamburg DOT de
> Proceedings of the European Lisp User Group Meeting '99
>
This is exactly the kind of thing I am looking for. Thanks for the tip!
Kris
In article <·····················@typhoon.ne.mediaone.net>,
·············@post.harvard.edu says...
> 1. VWSmalltalk + Opentalk.
> 2. Allegro Lisp/CLOS + CORBA.
IMHO you should also think about using Mozart <http://www.mozart-oz.org>,
a language/system with a strong bias on distributed search programming.
--
Roberto Lupi
"Roberto Lupi" <············@ascu.unian.it> wrote in message
·······························@news.ac.freefast.it...
> In article <·····················@typhoon.ne.mediaone.net>,
> ·············@post.harvard.edu says...
> > 1. VWSmalltalk + Opentalk.
> > 2. Allegro Lisp/CLOS + CORBA.
>
> IMHO you should also think about using Mozart <http://www.mozart-oz.org>,
> a language/system with a strong bias on distributed search programming.
>
> --
> Roberto Lupi
Thanks. I took a look, but I think I need something with more of the
typical bells and whistles: IDE, GUI builder, database connections, etc.
-Kris
[Message reposted, in the previous one the URL was mangled]
In article <·····················@typhoon.ne.mediaone.net>,
·············@post.harvard.edu says...
> 1. VWSmalltalk + Opentalk.
> 2. Allegro Lisp/CLOS + CORBA.
IMHO you should also think about using Mozart[1],
a language/system with a strong bias on distributed search programming.
[1] http://www.mozart-oz.org
--
Roberto Lupi
From: dave linenberg
Subject: Re: Smalltalk + Opentalk or CLOS + CORBA? Long Question.
Date:
Message-ID: <38DE3980.DA4CB3C8@home.com>
Or take a look at erlang!!
http://www.erlang.org/
dave linenberg
Roberto Lupi wrote:
> [Message reposted, in the previous one the URL was mangled]
>
> In article <·····················@typhoon.ne.mediaone.net>,
> ·············@post.harvard.edu says...
> > 1. VWSmalltalk + Opentalk.
> > 2. Allegro Lisp/CLOS + CORBA.
>
> IMHO you should also think about using Mozart[1],
> a language/system with a strong bias on distributed search programming.
>
> [1] http://www.mozart-oz.org
>
> --
> Roberto Lupi