Copy Link
Add to Bookmark
Report
AIList Digest Volume 5 Issue 161
AIList Digest Tuesday, 30 Jun 1987 Volume 5 : Issue 161
Today's Topics:
Query - Mega-Monitor,
Robotics - Vectrobot Recommendation,
AI Tools - Object-Oriented Languages & CLP(R) Announcement
----------------------------------------------------------------------
Date: 26 Jun 87 15:50:15 GMT
From: stride!tahoe!unsvax!jimi!asci!brian@gr.utah.edu (Brian Douglass)
Subject: Mega-Monitor
I've been asked by a friend to research information about a super-size
monitor. Essentially, what I am looking for is a color monitor that is 10
feet by 10 feet with a resolution of say 13,000 by 13,000--don't ask me what
for because I don't know what for, I'm just the gumshoe--and any necessary
equipment to drive it. (can you imagine what kind of equipment is necessary
to drive 169 million pixels!) Basically, my friend needs to generate some very
large images with extremely fine details. Color is preferable, but not
absolute. Money is not really a concern at this moment, so lets hear anything
you got. Also, if it means building it custom, that is what my friend wants
to know. So IBM, RCA, Tektronik, HP, etc, if you're listening and have any
experience in a monitor this large I would like to hear from you, as well as
if you have any "off-the-top-of-you-head" price estimates send those along. I
fully expect to hear in the millions, but that's okay. Right now, my friend
needs to know if anybody has done this, or if anybody can do this.
I know that there are also some analog systems out and about of this type of
magnitude. Although not preferable, I would like to hear about them as well.
Please E-mail only your responses to me as I am gone periodically on business
and we keep only a days worth of news on our system for a myriad of reasons.
However, I will summarize periodically to comp.graphics the responses I do
receive, as I am sure there are others who are as fascinated as I with the
leviathan proportions of this Mega-Monitor.
Brian Douglass
Applied Systems Consultants, Inc. (ASCI)
P.O. Box 13301
Las Vegas, NV 89103
Office: (702) 733-6761
Home: (702) 871-8182
brian@asci.uucp
UUCP: {akgua,ihnp4,mirror,psivax,sdcrdcf}!otto!jimi!asci!brian
------------------------------
Date: 22 Jun 87 19:49:48 GMT
From: linus!alliant!sullivan@husc6.harvard.edu (Mike Sullivan)
Subject: Re: Search and Employ (Mobile robot)
If your work involves mobile robot navigation, or other research
in robotics requiring sturdy, reliable hardware, I recommend a small three
wheel drive, three wheel steer (synchronous drive) chassis called a
"Vectrobot". It is manufactured by a company in New Hampshire called
Real World Interface.
For info, or references call Grinnell or Curt at (603) 654-6334
#include <std/disclaimer.h>
______
/ \ \
Michael J Sullivan / \____\ Alliant
decvax!linus!alliant!sullivan / / \ ComputerSystemsCorporation
/____/_______\
------------------------------
Date: 21 Jun 87 11:42:01 GMT
From: munnari!koel.rmit.oz!rcopm@seismo.CSS.GOV (Paul Menon)
Subject: Re: Smalltalk-80 for Sun 3 ... (LONG)
In article <8706180728.AA10707@ucbvax.Berkeley.EDU>,
lcc.bill@CS.UCLA.EDU ("William J. Fulco") writes:
> I saw a really nice system, (I mean REALLY nice - with good color support)
> from Xerox PARC marketing spinoff at the 1986 AAAI show. It was running
> on a Sun 3/260 and it really sizzles.....
I can believe that, I was introduced to the 3/260 just recently. It would make
anything sprout wings.
The reason for my addition has a little to do with suns, Smalltalk, and
technology in general, so please bear with me. This is long.
I have just completed some sizable programs (well, to me they were), and
am in the "recovery stage", ie sizing up what I have done... was it all worth
while etc, etc. I have reached a few (frustrating) conclusions/opinions...
* If I leave these programs for a while, and then come back to change
them in the name of maintenance or further enhancement, I am not too
much better off than someone who has never seen the package before.
I don't mean that in the positive sense, nor would I have forgotten
the techniques I used; it is the dependence of data being spread
all over the program. It was written in Pascal. How many of you
decide to change a data structure halfway through a program, not
because of bad planning in the first place, but because a "new"
and more efficient technique requires extra "bits" embedded into
a data structure. Does "grep 'structtype' *.h *.p" ring a bell?
Not even then am I too sure if everything is covered, especially
if it belongs to an overall complex data structure with crosslinks.
No amount of documentation or cross-references will relieve the
manual task ahead. Good programming style can minimize this only to
a certain extent. C, Algol, Modula 2, perhaps even Ada suffers
from this.
* If I want to re-use techniques in another program, major surgery is
required. Some call this hacking. It's only ok if the same types are
being used by the new program. There is static binding available from
Ada, if you wish to learn such a complex language. But none of the
"standard languages" allow complete type independence. Lisp and
Prolog programs will suffer the same scalpel treatment as the others.
If you haven't already guessed where I am heading, object-oriented
programming languages will (in my opinion) relieve me of these woes. Ok says
I, which one do I use? There is the Grand-Daddy, Smalltalk-80; the pure one.
Then there are the nouveau hybrids C++, Objective-C and MacApp. Others come
in different Flavors, Loops or feathered Flamingos and Owls. Lisp and Prolog
do not satisfy my requirements because I cannot easily "build" on previous
applications experience.
I don't hold the generally dismal performance of Smalltalk aginst it.
Hardware is zooming ahead as witnessed on suns, and soon on the Mac II
(I hope). My questions to all who have not gone to sleep are...
Will Smalltalk mature from being the toy that it was? ie a full 32
bit machine with > 32000 objects etc.. Methinks this is the ideal language
to be using no matter how big or small the program. The objection to being
such an "open" system can be countered by their "change management tools", if
I may be permitted to steal the phrase.
Of the hybrids, Objective-C appears my favourite. Although I have never
used it, I delight in the similar Smalltalk syntax. It will be a good
stand-in until Smalltalk meets its hardware match. Could any user out there
please comment on Objective-C, including it's ease of use, availability,
portability (ie, which o/s's can it run on), and price?
My preference to Objective-C rather than C++ is that I "feel uncomfortable"
in the way the latter has been implemented. The extended syntax does not
"stand out", it either melds into the other hieroglphs, so I cannot pick the
wood from the trees or it further confuses my understanding of C. I wish I
had a video of me reading a C program.. I must have this perpetual frown.
Is it common? I would love to hear from C++ users, especially those who
have used C++ and Objective-C. Note that my primary preference to Objective-C
is its syntactical similarity to Smalltalk.
Why not MacApp as an interim? Why not indeed! It is another example of
brilliance on the part of Apple, and once I get over the confusion of records
and messages/methods, all should be swell. One hitch though. Apple had
deemed it necessary to inflict a licencing fee on anyone producing/marketing
software that uses MacApp, as well as restricting all such programs to
the Macintosh. I don't know whether this still holds. I have noted MacApp
being used on a 4.2 bsd system (refer to OOPSLA '86 procs pp 186 - 201). pity.
My main hope is Smalltalk. It is a pity that the ones that can really
benefit from such a system are usually the last to see it. Kids. It is
the big kids; ie those who have been ingrained or fed up with procedural
languages that get to use it. Does this make us shortsighted?
Or perhaps fatally dependent on the past?
This isn't a plug for trendy software. This is frustration with writing
applications from scratch that use (nearly) the same techniques time and
time again. I use the hardware of tomorrow, but give it the brains of
yesterday. I am supposed to build on experience; all I do is
re-invent the wheel.
If you have read the book ..
"Object Oriented Programming: An Evolutionary Approach"
Brad J. Cox.
Then a major part of my article echoes its theme. I could not have read
it at a more pertinent time.
Thankyou,
Paul Menon.
Dept of Communication & Electronic Engineering,
Royal Melbourne Institute of Technology,
124 Latrobe St, Melbourne, 3000, Australia
ACSnet: rcopm@koel UUCP: ...!seismo!munnari!koel.rmit.oz!rcopm
CSNET: rcopm@koel.rmit.oz ARPA: rcopm%koel.rmit.oz@seismo
BITNET: rcopm%koel.rmit.oz@CSNET-RELAY
PHONE: +61 3 660 2619.
------------------------------
Date: Fri, 26 Jun 87 15:18:25 est
From: munnari!moncsbruce.oz!clp@seismo.CSS.GOV (The CLP(R) Personae)
Subject: CLP(R) Distribution Announcement
(Can you please add the following announcement to the digest)
DISTRIBUTION NOTICE
___________________
We are pleased to announce the availability of our
interpreter for CLP(R), the new Constraint Logic Programming
language. This is being distributed in source code written
in C and it is compatible with most machines running UNIX,
eg. Vaxen, Pyramids and Suns. This is not intended to be a
commercial announcement and is targeted at educational or
research usage.
The distribution includes:
1. CLP(R) interpreter (source code);
2. Example CLP(R) programs;
3. Installation Manual and Programmer's Manual (hard
copies).
Further information can be found in the following papers:
1. J. Jaffar and J-L. Lassez, "Constraint Logic
Programming", Proc. 14th ACM-POPL, Munich, January
1987.
2. J. Jaffar and S. Michaylov, "Methodology and
Implementation of a CLP System", Proc. 4th ICLP,
Melbourne, May 1987.
3. N.C. Heintze, S. Michaylov and P.J. Stuckey, "CLP(R)
and Some Electrical Engineering Problems", Proc. 4th
ICLP, Melbourne, May 1987.
4. C. Lassez, K. McAloon and R. Yap, "Constraint Logic
Programming and Option Trading", IEEE Expert, Fall
Issue 1987, to appear.
If you would like a Site licence for educational or research
purposes, please send a request for more information to
either,
(a) Electronic Mail address:
ACSNET: clp@moncsbruce.oz
ARPANET,CSNET: clp@moncsbruce.oz.au
UUCP: seismo!munnari!moncsbruce.oz!clp
(b) Paper Mail address:
CLP(R) Distribution
Department of Computer Science
Monash University
Clayton
Victoria 3168
Australia
In order to cover distribution and media costs, a license
fee of $150 will apply.
------------------------------
End of AIList Digest
********************
