jellinghaus-robert@CS.Yale.EDU (Rob Jellinghaus) (02/16/89)
Yale just received the Eiffel tools package, and after spending just
a short while (<1 day) playing with it, I have a couple of questions:
1) Is ee really any use? Was it just included to pique our curiosity,
or are people out there using it for production software? Considering
that I just recently started it up on a terminal with a screwed-up
termcap entry, and it went haywire and now seems to be broken, I would
doubt it....
2) The -S option in ee seems virtually useless; issuing "ee -S eiffeltest.e"
yields an "Entry not parsed" or some such message, where eiffeltest.e
is one of the demo files. Is it possible to use ee to edit valid Eiffel
files that ee did not create?
3) Do the X-based tools in the 2.1 release package function under X11R3?
We haven't had much luck getting good to come up.
4) Is version 2.2 nearing completion? Will it fix any or all of the above
problems?
5) Why is this newsgroup so inactive? I've seen several postings go
unanswered. Please, in a group with as little traffic as this, follow-up
rather than using electronic mail! (Actually, to be perfectly candid,
I'm not really expecting a response to this posting, judging from the
lack of activity on this group of late. I'm hoping, though!) The old
Eiffel mailing list was *extremely* active compared to the newsgroup,
which is rather strange considering the newsgroup *should* have a much
wider distribution.
6) *Is* there a Mac version of Eiffel in the works? (I've got a Mac II and
I sure would like to have Eiffel on it.)
Please respond to this article even if you know very little. I'd like to
confirm that there are some people who know something out there...
...and does Bertrand Meyer still read this newsgroup? If so, could we have
an Eiffel progress report? (Is Champ-de-Mars v.1 n.5 (or v.2 n.1) out yet?)
Rob Jellinghaus | "Next time you see a lie being spread or a
jellinghaus-robert@CS.Yale.EDU | bad decision being made out of sheer ignor-
ROBERTJ@{yalecs,yalevm}.BITNET | ance, pause, and think of hypertext."
{everyone}!decvax!yale!robertj | -- K. Eric Drexler, _Engines of Creation_bertrand@hub.ucsb.edu (Bertrand Meyer) (02/20/89)
In article <50825@yale-celray.yale.UUCP>, jellinghaus-robert@CS.Yale.EDU (Rob Jellinghaus) writes: > > 1) Is ee really any use? Was it just included to pique our curiosity, > or are people out there using it for production software? > 2) The -S option in ee seems virtually useless ee is still definitely in provisional form; this is clearly indicated in the manual. > 3) [Do Eiffel graphics tools work with X Windows Release 11.3?] They don't, for the reason that Eiffel 2.1 was released about four months before X11R3 first became available! All Eiffel graphic tools have been brought up to R3 (see next point). > 4) Is version 2.2 nearing completion? Will it fix any or all of the above > problems? > Version 2.2 will be released on April 15. The graphics has been extensively reworked for X11R3 and, more generally, will be at the same level of quality as the rest of the environment. ee too has been considerably improved, although not yet in final form. > 5) Why is this newsgroup so inactive? Good question. My impression is that this is just a temporary gap in activity. In any case, the newsgroup is read: after announcing that a paper on the Eiffel type system would soon be available, I received about 300 requests for the paper in a few days! (By the way, the copies will be mailed shortly.) > > 6) *Is* there a Mac version of Eiffel in the works? (I've got a Mac II and > I sure would like to have Eiffel on it.) Please see answer to another recent message. > ...and does Bertrand Meyer still read this newsgroup? > As you can see, Bertrand Meyer does read this newsgroup whenever he can. I do travel quite a bit, however, so periods occur during which I don't have access to it. (Also, because of some stupid UUCP problem we still don't get news at eiffel.com, which means I must use my account at UC Santa Barbara to get to the newsgroup; this makes it inconvenient. The problem should be fixed this week, enabling me and other people at Interactive Software Engineering to participate more effectively.) Thanks for your comments. Bertrand Meyer bertrand@eiffel.com
bertrand@hub.ucsb.edu (Bertrand Meyer) (02/20/89)
In article <50825@yale-celray.yale.UUCP>, jellinghaus-robert@CS.Yale.EDU (Rob Jellinghaus) writes: > ... could we have an Eiffel progress report? > (Is Champ-de-Mars v.1 n.5 (or v.2 n.1) out yet?) Champ-de-Mars v2n1 will be distributed with the March issue of the Journal of Object-Oriented Programming. A BRIEF PROGRESS REPORT. ----------------------- Version 2.2 will be released on April 15. It will be available, as its predecessors, on major versions of Unix, but also shortly thereafter (this is a new development) on VAX-VMS. This version brings a considerable set of improvements and extensions, but no revolutionary change. Three aspects have been emphasized in this release: - The graphics. Everything has been brought up to X Release 11.3 and many improvements have been made to the library and the tools. - The libraries, as described in Champ-de-Mars v1n4, in particular parsing, lexical analysis, string processing. The non-graphical windowing library already used for such tools as ee and the viewer will be made a part of the standard environment. - The language, also as described in the last issue of Champ-de-Mars, in particular the type system (more uniform treatment of basic and class types), the ``Out'' feature for uniform output of all objects and values, and syntactical equivalences supporting overloading for basic operators (+, < etc.). Also, to satisfy popular demand, a simple case instruction will be supported. - The tools: improvements to the viewer (ability to use variables to remember objects and pass objects as arguments to routines), ee etc. Repeated inheritance will be fully supported. To facilitate the storage and retrieval of polymorphic structures, a new facility will be offered: accept. This is particularly useful in the connection with forthcoming persistency extensions but may in fact be put to good use within the current environment. The instruction y.accept (x) [not final syntax], where the type of y is a descendant of the type of x, means: assign to y a reference to the same object as the object referred to by x if this object exists and is of a type that conforms to that of y; otherwise assign to y a void reference. This will be useful in cases in which you expect a polymorphic entity to refer to an object of a certain type; but of course you don't want to take any chances with the type system if this expectation is wrong. A typical use is: ps: STACK [POLYGON]; r: RECTANGLE; p: POLYGON; -- Of course, we assume RECTANGLE to be -- a descendant of POLYGON ... Instructions that fill the stack ps with various ... objects of type POLYGON or one of its descendants p := ps.top; r.accept (p); if r.Void then -- The top of the stack was not a -- RECTANGLE object ... Do something which does not use r ... else -- r refers to a RECTANGLE object ... Here we may refer to such RECTANGLE features ... of the object as r.diagonal etc. end Finally a language change is being contemplated with respect to the ``Create'' procedure for creating and initializing objects. This may, however, be postponed to the next version. There will be a later posting on this issue. A forthcoming posting will explain what our longer-term (end-89) plans are both with respect to development of the environment on existing platforms (Unix, VAX-VMS) and to new platforms (MS-DOS/OS-2, etc.). However to make this briefing complete it may be useful to the last section in Champ-de-Mars v1n4, which reported that we were working on persistency and concurrency. I am happy to comment that we have made progress on both of these issues. In particular, we have designed support for parallel Eiffel programming and are extremely excited about the simplicity and power of the result. I apologize for not answering earlier to postings on this subject in this newsgroup (in particular by Mikael Eriksson); this would have been inappropriate until the design was, if not complete, at least well on its way. Very briefly, the key ideas of the parallelism mechanism are: - Identical language support for coroutines and real concurrency. Only the number of physically available computing devices makes a difference. - Sequential applications may be adapted with minimal change to run in parallel for more performance. - There is no built-in notion of process; this is adequately covered by the object-oriented paradigm. A notion of processOR is needed to describe the devices (physical or abstract) used for carrying out computations. - Since the mechanism supports coroutines, discrete event simulation primitives such as those of Simula are not hard to write and will be made available in library classes. The mechanism represents an extremely simple extension of current Eiffel (three keywords). It will be described in a forthcoming installment of the Eiffel column in the JOOP (probably May). A plea to readers of this newsgroup: please do *NOT* flood me with requests for this description. Since I shall soon be sending the paper on the Eiffel Type System to those who requested it after my posting announcing it, and I figured out the same people would probably be interested in concurrency as well, I will include the draft of the parallelism JOOP column with the type paper. Disclaimer: The parallelism and persistency work should be considered as a research effort within Interactive, not as a commitment to specific product features. No parallelism is planned to be included in released versions of Eiffel until the last quarter of 1989. For persistency, the current (and already quite useful) ``store'' and ``retrieve'' facilities will remain the main Eiffel tools in the short term. This is in contrast with the policy that we have always followed so far: we never announced a feature unless it was implemented, or at least its implementation was well under way. Vaporware is pervasive in this industry and we don't feel like adding to this unpleasant and unethical practice. In the present case, the design of Eiffel Parallel appears interesting enough to be the object of a public report even though implementation is still some distance away. The present disclaimer should make it clear, however, that we are not making any false representations. -- Bertrand Meyer bertrand@eiffel.com
bertrand@hub.ucsb.edu (Bertrand Meyer) (02/21/89)
My previous posting, <1228@hub.ucsb.edu>, announced that ``Three aspects have been emphasized in [the current] release'' and then went on to describe four items. This confirms our policy of always giving users more than they expect. This use of the word ``three'' is backed by literary precedent, as in ``The Three Musketeers''. -- Bertrand Meyer bertrand@eiffel.com
ard@pdn.nm.paradyne.com (Akash Deshpande) (02/22/89)
In article <1229@hub.ucsb.edu> bertrand@hub.ucsb.edu (Bertrand Meyer) writes: >My previous posting, <1228@hub.ucsb.edu>, announced that >``Three aspects have been emphasized in [the current] release'' >and then went on to describe four items. > >This confirms our policy of always giving users more than they expect. >This use of the word ``three'' is backed by literary precedent, as >in ``The Three Musketeers''. and Monty Python's Spanish Inquisition. -Akash Akash Deshpande Paradyne Corporation uunet!pdn!ard Mail stop LG-129 (813) 530-8307 o Largo, Florida 34649-2826 Like certain orifices, every one has opinions. I haven't seen my employer's!