HDTenEightyP/NetNews huggingface dataset:
From: edmunds@vaxr.llnl.gov
Newsgroups: comp.lang.ada
Subject: Re: Why ADA?
Date: 15 Apr 92 18:50:08 GMT
Organization: LLNL_LIS


  adimaio@vms.eurokom.ie writes:
  > Let's wait for C++ results on large projects. They are likely to come back
  > asking for Ada ...

  I read a paper by one Fred Wild of Cadre, the large CASE tools company,
the title of which is "A Comparison of Experience with the Maintenance of
Object-Oriented Systems: Ada vs. C++".  He does a point-by-point comparison
of various features in both languages, based on his experience in writing
a large project internally in C++.  He concludes with a strong preference
for Ada.  The particular feature of C++ that he found most troublesome
in practice was inheritance.  If anyone's interested, I can quote the
article at more length....

  My own experience, which includes many years of large and small systems,
development in both C and Ada, by myself and with others, has left me with 
these opinions:
  1.  Given a project of any size, my time from start to *debugged* product
is less in Ada, and my confidence level in the product is significantly
higher.
  2.  You can get very nice, tight, elegant data structures in C more
easily than in Ada.
  3.  Most of the people who complain about Ada have never used it
extensively.  Ada is a very rich language, and takes longer to learn
than any other I've used (when I say "learn", I don't mean just being
able to coerce it to write Pascal-Ada, or FORTRAN-Ada, or whatever).
  4.  *Everyone* I know who has learned Ada after knowing C says that
their C programming has improved significantly by having been "forced"
to use Ada's features.
  5.  The number of programs that I have written in C that run correctly
the first time I try them is much smaller than the number of programs
that run correctly the first time after getting them through the Ada compiler.

-- Dave Edmunds
From: rjg@rutabaga.Rational.COM (Bob Geiger)
Newsgroups: comp.lang.ada
Subject: Re: Life cycle costs for FORTRAN+Ada vs. Ada
Date: 9 Apr 92 23:51:07 GMT
Organization: Rational, Santa Clara, CA

In article <1992Apr4.190401.22260@aero.org> jordan@aero.org (Larry M. Jordan) writes:

>Is it "reasonable" to:
>
>[1] Develop in FORTRAN and "migrate" to Ada?
>    o Is conversion/translation of the developed FORTRAN to Ada viable?
>    o Or is it better to have a trained Ada programmer to reimplement
>      from "language independent" algorithmic descriptions of working
>      code?

This first option of conversion from Fortran to Ada is the only
one I strongly advise against. This conversion, whether automated
or manual, is likely to yield "Adatran" (Fortran-like Ada) - with
inherently poor maintainability, understandability, portability
(and several other well-known "-bilities"). I have seen this happen
and it's not a pretty sight. Avoid it if possible.
The second will work, and seems most useful if you need to deliver
a design document that describes these algorithms. If you're just
going to use them to implement in Ada, then why waste time expressing
the algorithm in a language independent way?

>[2] Or, Require the untrained to develop in Ada from the start? 
>    o Take an initial productivity hit an train scientists in Ada?
>    o And/Or have a knowledgable Ada programmer(s), who might be
>      unfamiliar with the applications area,  work closely with
>      the scientists, monitoring what's going on to guarantee "good"
>      Ada?

I prefer the second option here. Put together the heads of the
Ada expert(s) and the scientists. I have found that a little
guidance can help speed the learning curve for Ada rookies. The
reason for this is not to help teach the nuts and bolts of the
language - anyone who knows Fortran can write with a similar
style in Ada. The trick is to grasp the new capabilities of
information hiding, abstraction, and object-orientedness (or at
least object-basedness :-) ).

Hope this helps,

Bob

===========================================================================
| Bob Geiger (rjg@rational.com)        Rational                           |
| Technical Consultant                 3320 Scott Blvd.                   |
| (408) 496-3743                       Santa Clara, CA 95054-3197         |
===========================================================================
--
===========================================================================
| Bob Geiger (rjg@rational.com)        Rational                           |
| Technical Consultant                 3320 Scott Blvd.                   |
| (408) 496-3743                       Santa Clara, CA 95054-3197         |
From: re@giordano.enpc.fr (Rolf EBERT)
Newsgroups: comp.lang.ada
Subject: need info on evaluations of Ada compilers on SPARC
Date: 6 Apr 92 09:11:18 GMT
Organization: Ecole Nationale des Ponts et Chaussees

As the subject already says, i'm interested in results of evaluations you 
made to chose ad Ada compiler for SPARC-stations. 

What criteria did you use (speed, code size, error messages, library
maintainance, ...), what were your mesured results, and specially *what are your
personal opinions* about the products?  Are you satisfied by the choice you 
finally made?

I'm asking this for our laboratory where we are going to develop a simulation 
environment. So we probably will have heavy needs in "scientific" math packages.
Are there floating around any PD-packages like Linpack, Eispack, and Minpack in
Ada? (didn't find in ASR on simtel-20)


If there is any interest, i can summarize the answers for the net, but please
send messages directly to me.


Rolf



-----------------------------------------------------------------------------
Rolf Ebert     Groupe Informatique et Systemes Energetiques     GISE EMP-ENPC
Tel: +33 1 43044098 app 3475 FAX: +33 1 43046364            La Courtine Cedex
Internet: ebert@enpc.fr                                F-93167 Noisy le Grand
-----------------------------------------------------------------------------
Newsgroups: comp.lang.ada
Subject: Re: Open comment to Ted Holden
From: frank@evax2.engr.arizona.edu (Frank Manning)
Date: 12 Apr 92 16:56:11 MST
Reply-To: frank@evax2.engr.arizona.edu
Distribution: world,local
Organization: University of Arizona, College of Engineering and Mines, Tucson

In article <2724@fedfil.UUCP> news@fedfil.UUCP (news) writes:

>Several points:  The commercial software venders are now adhering
>to standards, the most serious from the perspective of languages 
>being C/C++.  The argument you give would pertain in a situation
>in which Borland, MicroSoft, Ashton-Tate et. al. were each hawking
>their very own language.  The reality is quite different.  The choice
>is between the standard North American programming language (C/C++)
>which everybody uses and which is well understood by most serious
>programmers, and the flakey piece of garbage known as Ada.

Well, I personally have had good experiences with Ada. I suppose we will
have to agree to disagree.

As far as standards go, I agree that having an ANSI standard has helped in
the C world, as it has with Ada. Imitation is the sincerest form of
flattery, you know.

I'm not sure I would agree that, overall, standardization is a good
argument to use in favor of C/C++ because there is no finalized standard
for C++, the last I heard. When Microsoft released its version, it was
entertaining to watch a brief fight instantly erupt in comp.lang.c++
between Microsoft and Borland over whose compiler was "more standard".

But that brings up a deeper issue. Borland, Microsoft and Ashton-Tate do,
in fact, have a history of hawking their very own languages -- Turbo
Pascal, QuickBASIC, Fortran and so forth. That's not necessarily a bad
thing -- languages advance by that kind of rich, creative, freewheeling
chaos. But you also need the stability of a rigid, comprehensive standard
like Ada. I think you need both worlds, frankly.

>The problems mentioned in that large post of mine are real enough. Some
>very bright people have been wasting their lives spending 12 hours working
>around Ada and one hour solving their own problem (to the extent possible
>WITH Ada)..

As opposed to spending half as much time writing C and twice as much time
debugging and stomping on rogue pointers  *8=)

-- Frank Manning                                -- Nietzsche is pietzsche.
-- College of Engineering and Mines             --
-- Civil Engineering 100, University of Arizona --
-- Tucson, AZ  85721    frank@evax2.arizona.edu --
Newsgroups: comp.lang.ada,comp.unix.aix
From: skip@tacky.cs.olemiss.edu (Skip 'AdaX' Sauls)
Subject: Re: Motif binding for IBM AIX Ada/6000 ?
Organization: University of Mississippi, Dept. of Computer Science
Date: Wed, 15 Apr 1992 14:23:36 GMT

In article <1992Apr15.173248.16717@grace.dsir.govt.nz> srghdxp@grace.dsir.govt.nz writes:
>Does anyone know of a Motif binding for IBM AIX Ada/6000 ?
>I believe that this compiler is developed by Telesoft and that
>Systems Engineering Research Corp are developing a Motif binding.
>However I am interested in any comparative offerings from other
>commercial/non-commercial sources.
>Thanks  David Pairman, DSIR Physical Sciences, New Zealand
>ph 64 4 5690281  fax 64 4 5690067

We are using the STARS Motif bindings on an RS/6000 and can make them
available to anyone who wants them.  

Skip Sauls                     //    Graduate Student & Instructor
skip@tacky.cs.olemiss.edu    \X/     CS Department, University of Mississippi
From: cole@concert.net (Derrick C. Cole)
Newsgroups: comp.lang.tcl
Subject: Tcl_snmp
Date: 16 Apr 92 20:28:36 GMT
Organization: MCNC Data Operations

Greetings!

Has anyone successfully implemented the Tcl_snmp code as supplied by
phk@data.fls.dk?  I _think_ I've installed it properly, and can enable
tracing (set snmp_debug 1), but that's it.  No errors, help, or apparent
success at using this helpful-to-me module.  I'm running tk1.4 along with
tcl6.2 extended.

Can anyone help?

Thanks!
Derrick Cole
-- 
GCC 2.0 is to C as SVR4 is to Unix.
                              -- Dick Dunn
======
Newsgroups: comp.lang.tcl
From: karl@NeoSoft.com (Karl Lehenbauer)
Subject: Re: car and cdr in tcl?
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Mon, 13 Apr 1992 13:20:52 GMT

In article <1992Apr13.044050.1311@news.media.mit.edu> wave@waits.media.mit.edu (Michael B. Johnson) writes:
>In other words, tcl equivalents of car and  cdr from LISP?

proc car {list} {
    return [lindex $list 0]
}

proc cdr {list} {
    return [lrange $list 1 end]
}

-- 
-- Email info@NeoSoft.com for info on getting Internet access.
     "Trust me.  I know what I'm doing." -- Sledge Hammer
From: kennykb@dssv01.crd.ge.com (Kevin B. Kenny)
Newsgroups: comp.lang.tcl
Subject: Re: Tcl exec: grabbing output and exit status ?
Date: 13 Apr 92 21:45:47 GMT
Reply-To: kennykb@crd.ge.com
Organization: GE R&D, Information Architectures & Management Program


In article <1992Apr13.141913.21305@bmerh2.bnr.ca>, mpm@bnr.ca (Mike Mogridge)
writes:

|> I'm using the tcl command exec to execute a un*x command and I want
|> to save the output from the command as well as get the exit code
|> from the application.  The exec command will give me the output;
|> eg. set data [exec ls].  I would also like the return code; if I
|> was at the csh prompt I'd do a ls; echo $status.
|> 
|> How can I get both pieces of information?  The Extended Tcl stuff has a
|> system command that will return the exit code of the command but *not* the
|> output.

if [catch {exec ls} data] {
	# The exec got an error, and $errorCode has its termination status
} else {
	# The exec succeeded
}
# In any case, `data' contains all the output from the child process.


73 de ke9tv/2, Kevin
Newsgroups: comp.lang.tcl
From: t4mhoff@srv.PacBell.COM (Todd Hoff)
Subject: tcl vs embedded perl
Keywords: n
Organization: Pacific * Bell
Distribution: all
Date: Fri, 10 Apr 1992 21:05:10 GMT

>Certainly PERL is more widely used, for now at least.  But some people feel, 
>as Dale Worley (worley@compass.com) fairly eloquently said: "In my opinion, 
>Perl's biggest weaknesses are (1) its syntax is fantastically complex
>(consider the multiple meanings of / and $), and (2) it is a collection of 
>features more than a coherent language for expressing algorithms."

Good points. I've been much more productive in tcl than I was in perl.


>Tcl has the X-windows Tk toolkit, and further, there is a large, existing
>body of experience in embedding Tcl -- only time will tell if PERL is 
>appropriate for this use, and if they "got it right" in terms of creating
>a good interface for it.

PERL also has large body of experience, wide support, a lot of code,
and a very active news group. Perhaps the activity is due to its 
complexity?

>A standard would be nice?  You mean merge them or something?  Goodness,
>they are totally different languages, reflecting widely divergent design
>philosophies.  Merging them would be like trying to mix oil and water.

Oh no! god no. I mean perl and tcl accomplish similar tasks. I
can't see learning both at a master level. I certainly can't see
a diverse and somewhat transitory group of programmers doing working
fluently in both. I showed people how easy it was to extend tcl
with your own commands. They were impressed.

-- 
Thanx
Todd
t4mhoff@srv.pacbell.com
What the thinker thinks the prover proves (someone)
Newsgroups: comp.lang.tcl
From: mgc@cray.com (M. G. Christenson)
Subject: patch to tkScrollbar.c
Reply-To: mgc@cray.com
Organization: Cray Research, Inc.
Date: 7 Apr 92 13:39:16 CDT

There is a bug in tkScrollbar.c which prevents grabbing the slider
when it is very small.  The following patch fixes the problem.

*** ../tk-1.4/tkScrollbar.c	Tue Mar 10 12:51:42 1992
--- tkScrollbar.c	Tue Apr	 7 13:04:18 1992
***************
*** 907,913 ****
		+ scrollPtr->totalUnits/2)/scrollPtr->totalUnits;
	diff = sliderLast - sliderFirst - 2*scrollPtr->borderWidth;
	if (diff < 0) {
!	    sliderLast += diff;
	    if (sliderLast > length) {
		sliderFirst -= sliderLast-length;
		sliderLast = length;
--- 907,913 ----
		+ scrollPtr->totalUnits/2)/scrollPtr->totalUnits;
	diff = sliderLast - sliderFirst - 2*scrollPtr->borderWidth;
	if (diff < 0) {
!	    sliderLast -= diff;
	    if (sliderLast > length) {
		sliderFirst -= sliderLast-length;
		sliderLast = length;

Newsgroups: comp.lang.tcl
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Failed file.test 15-4 through 15-8 on SCO Xenix 2.3.4
Organization: Sequoia Peripherals, Inc.
Date: Wed, 8 Apr 92 03:15:37 GMT

I had no problems building the TCL library and it passed all
but one of the tests with flying colors. It seems to have
problems with error handling as the tests it failed (see Subject
line) are all catches. I'd really appreciate any fixes or
suggestions any of you have...


-- 
Dave Eisen    dkeisen@leland.Stanford.EDU   Sequoia Peripherals: (415) 967-5644
      There's something in my library to offend everybody.
        --- Washington Coalition Against Censorship
From: mpm@bnr.ca (Mike Mogridge)
Newsgroups: comp.lang.tcl
Subject: Tcl exec: grabbing output and exit status ?
Date: 13 Apr 92 14:19:13 GMT
Organization: Bell-Northern Research, Ottawa, Canada

I'm using the tcl command exec to execute a un*x command and I want to save
the output from the command as well as get the exit code from the application.
The exec command will give me the output; eg. set data [exec ls].  I would
also like the return code; if I was at the csh prompt I'd do a ls; echo $status.

How can I get both pieces of information?  The Extended Tcl stuff has a
system command that will return the exit code of the command but *not* the
output.

Ideas?
Mike.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Mike Mogridge               | "Just once I wish we could encounter an      <
> Bell-Northern Research Ltd. |  alien menace that wasn't immune to bullets."<
> P.O. Box 3511 Station C     |       -The Brigadier, Doctor Who.            <
> Ottawa, ONT, Canada K1Y 4H7 |  INTERNET: mpm@bnr.ca                        <
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Newsgroups: comp.lang.tcl
From: rme@msi.com (Richard Emberson)
Subject: Common strings
Keywords: strings
Organization: Molecular Simulations, Inc.
Date: Wed, 15 Apr 1992 15:51:21 GMT


Ticklers,

  I'm currently working new product development and we're integrating using TCL
(the subset I'm focused on now is a TCL layer over InterViews - a C++ toolkit,
anyway...). It struck me that I was using the string:

     "wrong # args: should be \""

alot of places in my code. Running "strings" on my executable and on the library
showed this to be all to true.

  I am now in the process of defining only one string

     static const char* wrongNosArgsStr = "wrong # args: should be \"";

declaring it as an extern where needed and just using it - thus saving memory.

Could the same strategy be used by the TCL "support" group.

  The string  "wrong # args:" appears 57 times in the extended tcl library.
  The string  "wrong # arg:" appears 1 time in the extended tcl library.
  The string  "wrong # arg: should be" appears 102 times in the extended tcl library.

there are probably many other repeated-use-strings.


Richard Emberson
rme@msi.com
From: heimir@plusplus.is (Heimir Thor Sverrisson)
Newsgroups: comp.lang.tcl
Subject: Tcl for MS-Windows?
Keywords: Tcl, MS-Windows
Date: 11 Apr 92 19:31:52 GMT
Organization: Plusplus Inc., Reykjavik, Iceland

Has anyone ported Tcl to Microsoft Windows 3.X, or is planning
to do so?
--
Heimir Thor Sverrisson			heimir@plusplus.is
-- 
Heimir Thor Sverrisson		|		heimir@plusplus.is
Plusplus Inc.			|
Laugavegi 13			|		Tel: +354-1-620 250
108 Reykjavik, ICELAND		|		Fax: +354-1-622 819
Newsgroups: comp.lang.tcl
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: Failed file.test 15-4 through 15-8 on SCO Xenix 2.3.4 (solved)
Organization: Sequoia Peripherals, Inc.
Date: Thu, 9 Apr 92 14:33:39 GMT

In article <1992Apr8.031537.5785@leland.Stanford.EDU> dkeisen@leland.Stanford.EDU (Dave Eisen) writes:
>I had no problems building the TCL library and it passed all
>but one of the tests with flying colors. It seems to have
>problems with error handling as the tests it failed (see Subject
>line) are all catches. I'd really appreciate any fixes or
>suggestions any of you have...

The problem was not with Tcl, but with the test script. It was upset
that the error message for unknown file operations didn't include
the word "readlink" even though the code was compiled to exclude
this operation because Xenix doesn't have symlinks.



-- 
Dave Eisen    dkeisen@leland.Stanford.EDU   Sequoia Peripherals: (415) 967-5644
      There's something in my library to offend everybody.
        --- Washington Coalition Against Censorship
From: v040376@autspc1.stortek.com (Jeff Hanson)
Newsgroups: comp.lang.tcl
Subject: binding number keys in Tk
Date: 13 Apr 92 23:41:46 GMT
Organization: Storage Technology Corp.
Originator: v040376@autspc1

I am trying to bind the number keys on the keyboard in an entry widget 
using tk1.4. But when I specify the keysym for the 1, 2, or 3 keys I get
an error from bind. The error is : 

 specified button "1" for non-button event

It appears that tk is assuming "1" is shorthand for button-1 as is stated 
in the bind man page. I verified the keysym for the number keys using 
xmodmap -pk and I am able to bind other keys such as the keypad number keys
(using KP_1 for a keysym). Here is the command I am using for the binding:

	bind myentry <KeyPress-1> {%W insert cursor "%A"}

My questions are then am I doing something wrong, or is there a bug in the 
tk code with respect to this feature. If this is a problem then is there a
way to circumvent it to get the functionality I desire ( my desired end 
goal is to have an entry widget which only accepts numbers as input).
Here are my system particulars:

OS: ISC 2.2
X: MetroLink X11R4
Tk ver 1.4 
Tcl ver 6.2
HW: AST 386/33 premium

Thanks in advance,
-Jeff Hanson



-- 
"These are not the views of StorageTek, so blame me."
Jeff Hanson                                /\    /\/\   
StorageTek - Louisville, Co.              /  \/\/  \ \ 
Jeff_Hanson@stortek.com                  /   / /    \ \
Newsgroups: comp.lang.tcl
From: axel@cs.tu-berlin.de (Axel Mahler)
Subject: TCL interface to gnuplot ??
Organization: /home/stone/axel/.organization
Date: Mon, 13 Apr 1992 13:16:28 GMT

Has anyone interfaced Gnuplot to TCL ??
Gnuplot looks like the typical example of a complex application 
coming with its own configuration-/command language. 

Axel.
--
===============================================================================
Axel Mahler, Tech.Univ. Berlin
E-Mail: axel@cs.tu-berlin.de (axel@db0tui62.bitnet)
Voice: +49-30-314-73487
Newsgroups: comp.lang.tcl
From: thf@zelator.in-berlin.de (Thomas Funke)
Subject: Re: Compiling on the NeXT
Organization: Puplic-Access-Xenix-System
Date: Tue, 07 Apr 92 17:46:02 GMT
Keywords: Compiling NeXT

In <1705@nic.cerf.net> root@interzone.cerf.net (Operator) writes:



>Has anyone had any luck compiling tcl on the Next?

Sure. No problems except the usual scanf/printf incomatibilities.
BTW: NeXT uses TCL (secretly ?) for their installation scripts !


-- 
-----------------------------------------------------------------------
Thomas Funke, Gasteinerstr. 29, 1000 Berlin 31, Germany, +49-30-8618224  
** Registered NeXT Developer **
E-mail:  thf@zelator.in-berlin.de
-----------------------------------------------------------------------
From: jeff@ncifcrf.gov (Jeff Garlough)
Newsgroups: comp.lang.tcl
Subject: Tcl'ing (on) a Cray?
Date: 7 Apr 92 17:24:53 GMT
Distribution: na
Organization: NCI Supercomputer Facility, Frederick, MD

Has anyone built tcl on a Cray? 

I get a core dump when I try to run tclTest, eg, 
nciymp{jeff}77% tclTest
% cd tests
% source all
append.test
Bus error (core dumped)


Some details:
Cray Y-MP 
UNICOS 6.1
tcl6.2

I included the patches found in porting.notes and ran make. Make fails
to compile due to "the type of 'open' is not compatible with its
previously declared type", and the same problem with unlink. No
problem, just comment these out and re-make. Moved the library and
make tclTest and viola' :-) ... core dump.

Re-compiling with TCL_MEM_DEBUG defined produces:
nciymp{jeff}81% tclTest
low guard byte 0 is 0x0
low guard byte 1 is 0x0
low guard byte 2 is 0x0
low guard byte 3 is 0x0
low guard byte 4 is 0x0
low guard byte 5 is 0x0
low guard byte 6 is 0x0
low guard byte 7 is 0x0
total mallocs                     98
total frees                        0
current packets allocated         98
current bytes allocated         4333
maximum packets allocated         98
maximum bytes allocated         4333
low guard failed at 11ebc, tclHash.c 929
Allocated at ((NULL) 0)
Memory validation failureIOT trap (core dumped)

Thanks for any help in advance, 

Jeff Garlough
jeff@ncifcrf.gov
Newsgroups: comp.lang.tcl
From: othar@guard.Berkeley.EDU (Othar Hansson)
Newsgroups: comp.lang.tcl
Subject: TCL Workshop in the summer?
Date: 7 Apr 1992 02:09:09 GMT
Organization: University of California at Berkeley
Distribution: ucb
NNTP-Posting-Host: guard.berkeley.edu
Originator: othar@guard.berkeley.edu

I remember someone posted a while back regarding an upcoming TCL
Workshop.  Is that still in the works?  Can someone in the know repost
the information?  (change the distribution first.)

Thanks,
- Othar