HDTenEightyP/NetNews huggingface dataset:
From: rme@msi.com (Richard M. Emberson)
Subject: Scheme->C Help on SPARC
Organization: Molecular Simulations, Inc.
Date: Fri, 2 Oct 1992 17:12:06 GMT


Need help getting DEC Scheme->C working of a SPARC. Which version should I use:

   01nov91.tar.Z

 or

   28sep90.tar.Z


With 28sep90.tar.Z I get the following error:

Xsccomp ../scrt/predef.sc ../scrt/objects.h ../scrt/libsc.a ../scrt/libsc_p.a SPARC Xsccomp.heap
***** COLLECT Out of space during collection

... core dump ....

With 01nov91.tar.Z I get the following error:

Xsccomp ../scrt/predef.sc ../scrt/objects.h ../scrt/libsc.a ../scrt/libsc_p.a SPARC Xsccomp.heap
"***** inside ERROR" "WRITE-CHAR" "Argument is not an OUTPUT-PORT: ~s" f734b

... core dump ....



Richard Emberson
rme@msi.com
--
Molecular Simulations, Inc.             mail: rme@msi.com
796 N. Pastoria Avenue                  uucp: uunet!msi!rme
Sunnyvale, California 94086             phone: 408/522-9233

-- 
Molecular Simulations, Inc.             mail: rme@msi.com
796 N. Pastoria Avenue                  uucp: uunet!msi!rme
Sunnyvale, California 94086             phone: 408/522-9233
Newsgroups: comp.lang.scheme.c
From: jwilliam@endor.sim.es.COM (Jerry Williams x2562)
Subject: Will scheme 6.1 run on a sparc 2?
Organization: The Internet
Date: Fri, 2 Oct 1992 22:58:44 GMT

I would like to get scheme running for a student that works here.
I see that it is set up for a sun3.  What happens with a sun4 or
am I wasting my time.  Thanks, for any help!
Jerry
From: Jonathan.Bachrach@ircam.fr (Jonathan Bachrach)
Newsgroups: comp.lang.scheme.c
Subject: 7.2 on the NeXT
Date: 6 Oct 92 20:11:01 GMT
Organization: The Internet

Does 7.2 run on the NeXT.  If not, any idea when it will?

-- jonathan bachrach

IRCAM
31, rue Saint-Merri
F75004 Paris, France
011-33-1-44784864
bachrach@ircam.fr
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.scheme
Subject: Re: substring + why so many essential procedures
Date: 28 Sep 92 15:59:07 GMT
	<BEVAN.92Sep21112540@jaguar.cs.man.ac.uk>
	<JAFFER.92Sep22121638@camelot.ai.mit.edu>
	<BEVAN.92Sep23094831@tiger.cs.man.ac.uk>
	<PK.92Sep24140627@talitiainen.cs.tut.fi> <BEVAN.92
Organization: Department of Computer Science, University of Manchester
In-reply-to: pk@cs.tut.fi's message of 28 Sep 92 13:15:52 GMT

In article <PK.92Sep28151552@talitiainen.cs.tut.fi> pk@cs.tut.fi (Kellom{ki Pertti) writes:
   If I've understood your proposal right, then these two methdods would
   be completely orthogonal. Neither rules out the other.

That's is certainly how I think of them.


   There's one thing that is unclear to me: where does the code that
   takes care of loading the necessary libraries go? Does it go to the
   application source file or does it go to a separate file?

Separate file.  This file needs to be loaded before the application.
How exactly this is achieved is undefined.  The simplest is just to
ask the user to type the commands to load it before anything else, if
more automation is required, the application could REQUIRE the
file with a dummy file being provided in the case that no changes are
required.

Seeing as nobody else has mentioned it, I'll point out one problem as
I see it with the method I propose: dealing with macros.  I can handle
writing a reader for Scheme without macros, but with macros I'm lost.
This hasn't been a problem for me so far because :-

a) I don't have access to a Scheme that has good support for macros
   (Aubry Jaffer's excellent work with SLIB notwitstanding) so I don't
   use them. 
b) The way I use REQUIRE (I require procedures not modules/libraries)
   precludes the need to do a full parse.

bevan
From: ted@nmsu.edu (Ted Dunning)
Newsgroups: comp.lang.scheme
Subject: Re: SIOD now runs on ALPHA
Date: 6 Oct 92 18:05:40 GMT
Reply-To: ted@nmsu.edu
Organization: Computing Research Lab


In article <1aj38tINNqq9@agate.berkeley.edu> bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
Path: nmsu.edu!lynx!umn.edu!spool.mu.edu!agate!anarres.CS.Berkeley.EDU!bh
   From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
   Newsgroups: comp.lang.scheme
   Date: 3 Oct 1992 03:15:41 GMT
   Organization: University of California at Berkeley
   Lines: 10
   References: <2972@mitech.com>
   NNTP-Posting-Host: anarres.cs.berkeley.edu

   gjc@mitech.com (George J. Carrette) writes:
   >Maclisp and PDP-10 UUO's come to mind.
		^^^^^^^^^^^^

   Yeah!  Go DEC!  :-)  :-)

yeah right.


i think the comment should be more like dec goes down the tubes.
hell, they don't even call themselves dec anymore.


the annual report just came out.  reorg costs are up to 1.5 BILLION
dollars last year and total losses were 2.8 billion or a bit over $20
per share.  in spite of this, total work force is only down to 110,000
from a high of about 125,000.  KO did make the point that cash flow on
operations was positive.  as the overall corporate value drops, it
becomes more and more likely that dec will be chopped into pieces and
sold at auction.

unless something very drastic happens very soon, it really doesn't
matter what technical rabbits dec pulls out of their corporate hat.
and from my contacts inside, the climate is very bad; good people are
leaving and the rest are focussing on minutiae instead of making the
company turn around.

sort that this isn't all that applicable to lisp.  it just pisses me
off that one of the finest companies that this country has ever known
was wasted for no good reason.  i expect that everybody who ever used
an pdp-8, or 11, or a decsystem 10, or 20 will have good reason to
mourn before too long.
From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
Newsgroups: comp.lang.scheme
Subject: Re: SIOD now runs on ALPHA
Date: 3 Oct 1992 03:15:41 GMT
Organization: University of California at Berkeley
NNTP-Posting-Host: anarres.cs.berkeley.edu

gjc@mitech.com (George J. Carrette) writes:
>Maclisp and PDP-10 UUO's come to mind.
             ^^^^^^^^^^^^

Yeah!  Go DEC!  :-)  :-)

[Actually I'd been under the impression that high level language people
didn't like the old UUOs because of their inline arguments, which are
hard for compilers to generate.  Are you thinking of some other attribute
of UUOs?]
From: kend@data.rain.com (Ken Dickey)
Newsgroups: comp.lang.scheme
Subject: OOP in Scheme
Date: 4 Oct 92 18:22:40 GMT
Organization: Microtek DSD, Hillsboro, OR



For those of you wanting a more detailed explanation of YASOS, see
"Scheming with Objects" in the current (October) issue of AI Expert
magazine.

Enjoy!
-Ken
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.scheme
Subject: Re: substring + why so many essential procedures
Date: 28 Sep 92 12:30:05 GMT
	<BEVAN.92Sep21112540@jaguar.cs.man.ac.uk>
	<JAFFER.92Sep22121638@camelot.ai.mit.edu>
	<BEVAN.92Sep23094831@tiger.cs.man.ac.uk>
	<PK.92Sep24140627@talitiainen.cs.tut.fi> 	<BEVAN.92
Organization: Department of Computer Science, University of Manchester
In-reply-to: thinman@netcom.com's message of 28 Sep 92 05:22:35 GMT

In article <t__pkd+.thinman@netcom.com> thinman@netcom.com (Technically Sweet) writes:
   Operating system releases for whatever computer you use don't come
   in trees.  The vendor doesn't keep splitting off different versions
   that support real-time threads, hardware graphics, etc.  They just
   keep adding features to one operating system.

This probably explains why many OSes are bloated beyond belief :-)
I much prefer the mix-n-match method i.e. define a set of
services/libraries and then include the ones you want for your
application.

bevan
From: twood@capmkt.COM (Thom Wood)
Newsgroups: comp.lang.scheme
Subject: call-with-current-continuation
Date: 6 Oct 92 01:02:53 GMT
Organization: Capital Market Technology

what is the current continuation???

given the following code


(let* ((echo (lambda lst (display lst) (newline)))
       (exit echo)
       (x 0)
       (echo-x (lambda (cc)
		   (set! x (+ x 1))
		   (echo 'x '= x)
		   (cc x))))
    (let* ((y 0)
	   (echo-y (lambda (cc)
		       (set! x (+ x 1))
		       (set! y (+ y 1))
		       (echo 'y '= y)
		       (cc y))))
	(let* ((z 0)
	       (echo-z (lambda (cc)
			   (set! y (+ y 1))
			   (set! z (+ z 1))
			   (echo 'z '= z)
			   (cc z))))
	    
	    (if (null? (call-with-current-continuation (lambda (cc) (set! exit cc) '())))
		(echo-z exit)
		(begin 
		    (set! z (+ 1 z))
		    (echo 'z '- z))))
	
	(if (< y 5)
	    (begin 
		(echo 'y '- y)
		(echo-y exit))
	    (echo 'exiting 'y)))
    
    (if (< x 5)
	(begin
	    (echo 'x '- x)
	    (echo-x exit))
	(echo 'exiting 'x))
    (echo 'done 'done 'done))



1.  will it exit?
2.  what will the output look like?


I wish to know how much of the enviroment is preserved in a continuation.
Thanks  Tom Wood
Newsgroups: comp.client-server
From: mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin)
Subject: Re: scared customers
Organization: Dept. of Computer Science, University of Waterloo
	<1992Oct5.161336.22273@mmm.serc.3m.com> <1871@sousa.ltn.dec.com>
	<1992Oct6.124600.7281@texhrc.uucp>
Distribution: na
Date: Tue, 6 Oct 1992 17:49:03 GMT

In article <1992Oct6.124600.7281@texhrc.uucp> pyeatt@Texaco.com (Larry D. Pyeatt) writes:

> I agree.  It is quite distressing to me that when I talk about using X to run
> simultaneous jobs on a dozen CPUs, people stare at me like I have two heads.
> I don't even tell them about RPCs and tossing threads out onto the network, I
> am afraid they would burn me as a witch.  I think that part of the problem
> is that there really is no _good_ language for programming that sort of thing.
> Modula-3 looks like a step in the right direction.

I like Modula-3 a lot, but while there may be great *potential* for
distributed computing in Modula-3, there isn't much available right
now.  For a really nice distributed programming language that's
available right now, check out SR, yet another fine language from The
University of Arizona.  Version 1 has been available for a few years;
version 2 is now available.  You can ftp it for free from
cs.arizona.edu.

(Disclaimer: I'm not unbiased; I've worked on SR myself.)

-mike

Newsgroups: comp.client-server
From: imp@solbourne.com (Warner Losh)
Subject: Re: scared customers
Organization: ParcPlace Boulder
Distribution: na
Date: Mon, 5 Oct 1992 23:36:41 GMT

In article <1871@sousa.ltn.dec.com> gibian@ljohub.enet.dec.com writes:
>Client/Server has been around for quite a while, but most is limited to
>file level distribution of computing environment.

X has been around for several years and uses a client server
architecture.

Maybe you forgot about it?  Or you want to foget about it....

Warner
-- 
Warner Losh		imp@parcplace.COM	ParcPlace Boulder
I've almost finished my brute force solution to subtlety.
Newsgroups: comp.client-server
From: eugene@wilbur.nas.nasa.gov (Eugene N. Miya)
Subject: Re: scared customers
Organization: NAS, NASA Ames Research Center, Moffett Field, CA
Date: Mon, 5 Oct 92 20:05:07 GMT
Distribution: na

In article <1992Oct5.161336.22273@mmm.serc.3m.com> us267384@mmm.serc.3m.com
(Steven M. Anastasi) writes:
>My opinion:  Client/server architectures fit well with the current
>mainframe/terminal based applications in place in many IS shops.
>It allows one to continue to use the mainframe as a central data
>source, possibly by front-ending it with translation tools or 
>a second, more modern, database server.

The C-S model has existed far more than 5-10 years.  Try 20-25 years,
it predated workstations by over a decade.  The problem is: it ain't easy.

My opinion: mainframes (as we know them) are dead meat.
The dinosaur analogy is a good one, but the conserative inertia lingers.
They will still be around (the so-called "soft"ware insures this).
The faster that older architecture tied applications die, the sooner
more portable implementations will come around.  Problems like 32-bit/64-bit
words, character set differences, the turn of the millenia problem, all
conspire against alot of this.

I'm not certain why the first poster used the adjective "scared."
But it can be take in many contexts.  Change will come, slowly with lots of
gotachas.

--eugene miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov
  Associate Editor, Software and Publication Reviews
  Scientific Programming
  {uunet,mailrus,other gateways}!ames!eugene
Ref: Mathematics and Plausible Reasoning, vol. 1, G. Polya
Newsgroups: comp.client-server
From: jona@iscp.bellcore.com (Jon Alperin)
Subject: Re: scared customers
Organization: Bellcore
Distribution: na
Date: Tue, 6 Oct 92 12:12:13 GMT

In article <Bvo9L5.3GI@solbourne.com>, imp@solbourne.com (Warner Losh) writes:
|> In article <1871@sousa.ltn.dec.com> gibian@ljohub.enet.dec.com writes:
|> >Client/Server has been around for quite a while, but most is limited to
|> >file level distribution of computing environment.
|> 
|> X has been around for several years and uses a client server
|> architecture.
|> 
|> Maybe you forgot about it?  Or you want to foget about it....
|> 
|> Warner
|> -- 

 Yeah,, but try to explain that the X Client runs on the network server,
talking to the X server running on a workstation client. 8-}

 Client/Server is at best ill-defined, since it assumes a host/terminal
paradigm, where the client is simply performing some (few) tasks that 
used to be handled by a host. If I place a printer directly on my
ethernet net segment, and I still use terminals connected to a central
host but allow the host to send packets directly to a printer, is this 
C?S computing?

-- 
Jon Alperin
Bell Communications Research

---> Internet: jona@iscp.bellcore.com
---> Voicenet: (908) 699-8674
---> UUNET: uunet!bcr!jona

* All opinions and stupid questions are my own *
Newsgroups: comp.client-server
From: pyeatt@Texaco.com (Larry D. Pyeatt)
Subject: Re: scared customers
Organization: Texaco
Distribution: na
Date: Tue, 6 Oct 1992 12:46:00 GMT

In article <1871@sousa.ltn.dec.com>, gibian@talent.ljo.dec.com (Marc S. Gibian) writes:
|> 
|> Client/Server has been around for quite a while, but most is limited to
|> file level distribution of computing environment.  What is slow to surface
|> is sharing of other computing resources within the network environment.
|> There are limited implementations of things like print servers and
|> information servers (just specialized file servers).  Even slower to
|> appear are common usage of compute related servers.

I agree.  It is quite distressing to me that when I talk about using X to run
simultaneous jobs on a dozen CPUs, people stare at me like I have two heads.
I don't even tell them about RPCs and tossing threads out onto the network, I
am afraid they would burn me as a witch.  I think that part of the problem
is that there really is no _good_ language for programming that sort of thing.
Modula-3 looks like a step in the right direction.

-- 
Larry D. Pyeatt                 The views expressed here are not
Internet : pyeatt@texaco.com    those of my employer or of anyone
Voice    : (713) 975-4056       that I know of with the possible
                                exception of myself.
Newsgroups: comp.client-server
From: tom@uts.cc.wayne.edu (Thomas Richard Stevenson)
Subject: Re: clinet-server benchmarks
Keywords: benchmarks,performance
Organization: Wayne State Univ.
Date: Tue, 6 Oct 1992 19:27:10 GMT

sterrett@nosc.mil (Anthony E. Sterrett) writes:


>Hi,
>	Would anyone like to share or disscuss techiques for
>benchmarking client-server systems?
>Thanks in Advance 
>Tony Sterrett
>sterrett@nosc.mil

I would. I'm just getting ready to start on a project like this,
and any information in this area would be a big help.
-- 
     ____  __   __       Tom@UTS.CC.Wayne.Edu
      /   /_/  /_        Thomas_Richard_Stevenson@MTS.CC.Wayne.Edu
     /.  /\ . __/.       Tom@CMS.CC.Wayne.Edu
                         UserTom@WayneMTS.Bitnet
Newsgroups: comp.client-server
From: virtual@schug.larc.nasa.gov (Don H. Phillips)
Subject: info on client-server implementatios sought
Organization: NASA Langley Research Center, Hampton, VA  USA
Distribution: comp.client-server
Date: Tue, 6 Oct 1992 19:29:56 GMT

      Our local IS shop is planning on replacing an application with
      a "traditional" design which utilizes a terminal emulation
      user interface, with one based on an X client-server architecture.

      The current configuration has the application, which uses an
      SQL data base (ORACLE), running on a Decstation 5000 server.
      The Decstation is attached to an ethernet which in turn is on
      a node on a FDDI backbone local area network.  With about 30
      simultaneous users, the current application is using about
      30 percent of the available cpu time on the Decstation.  In
      addition to the change in the interface, expansion of the user
      base to level which would suggest about 50 simultaneous users
      is anticipated.

      The user machines constitute a heterogeneous environment.  The
      majority of users have MacIntoshes, but Intel based PCs, Sun
      Dec, SGI, HP .... workstations are also present in the environment.
      The Macs have direct network connections (most do, all will).

      The persons responsible for setting up and operating this
      application and system would like to here of other X client-server
      implementations of similar scope.  Information on successful
      projects, problems encountered, and user satisfaction levels
      would be appreciated.

      email information to: d.h.phillips@larc.nasa.gov
-- 
      Don
      
      Donald H. Phillips       d.h.phillips@larc.nasa.gov
      (804) 864-4780
Newsgroups: comp.client-server
From: frankc@netcom.com (Frank Crowell)
Subject: Re: scared customers
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Distribution: na
Date: Wed, 7 Oct 1992 00:46:17 GMT


Another network programming language is fmpl.  Its available
at xcf.berkeley.edu; just ftp to the system and browse at src/local/fmpl.
Version 1.5 is the lastest, but there is a new (Sep 30) that is
considered experimental.

The language is OO and fairly easy to use.
From: pmsc13sg@UMASSD.EDU (Stephen Grossman)
Newsgroups: comp.client-server
Subject: Re: scared customers
Date: 5 Oct 92 16:23:23 GMT
Reply-To: pmsc13sg@UMASSD.EDU
Distribution: na
Organization: UMASS DARTMOUTH, NO. DARTMOUTH, MA.

In article <1992Oct5.131632.27931@geac.com>, allen@geac.com (Allen Septon) writes:
>Hi,
>
>I finally started this newsgroup and have yet to see a posting.
>I guess everyone is afraid to be the first poster.
>
>Our current customer base is very reluctant to jump into the new
>technology of client/server. We plan to use MS-WINDOWS based frontends
>and initially GUPTA for a database on the backend.
>
>What experience have people had with reluctant customers and how have
>you handled it.
>
>Allen
>allen@geac.com

    What is the purpose of this group?
From: gibian@talent.ljo.dec.com (Marc S. Gibian)
Newsgroups: comp.client-server
Subject: Re: scared customers
Date: 5 Oct 92 16:52:29 GMT
Reply-To: gibian@ljohub.enet.dec.com
Distribution: na
Organization: Digital Equipment Corporation


Client/Server has been around for quite a while, but most is limited to
file level distribution of computing environment.  What is slow to surface
is sharing of other computing resources within the network environment.
There are limited implementations of things like print servers and
information servers (just specialized file servers).  Even slower to
appear are common usage of compute related servers.
--
Marc S. Gibian			email: gibian@talent.ljo.dec.com
Principal Software Engineer	phone: (508) 486-6598
Digital Equipment Corporation	fax:   (508) 486-6648  or (508) 486-6100


Newsgroups: comp.client-server
From: srivasm@meaddata.com (M. C. Srivas)
Subject: Re: scared customers
Organization: Mead Data Central, Dayton OH
Date: Tue, 6 Oct 1992 13:47:57 GMT
Distribution: na

In article <1992Oct5.190119.21270@porthos.cc.bellcore.com>, jona@iscp.bellcore.com (Jon Alperin) writes:
|> In article <1992Oct5.173444.24966@meaddata.com>, srivasm@meaddata.com (M. C. Srivas) writes:
|> |> In article <DWF.92Oct5092154@hope.acl.lanl.gov>, dwf@acl.lanl.gov (David W. Forslund) writes:
|> 
|> |> millions of machines and many millions of users. What do you have in
|> |> mind when you say:
|> |> 
|> |> 	"I believe the workstation world now is moving more to
|> |> 	peer-peer computing in a truly distributed manner."
|> |> 
|> |> I find that very hard to believe.
|> |> 
|> |> -Srivas.
|> |> 
|> 
|>  Whoa....It all points to the paradigm you are using.
|>
|>  [ some examples of distr processing deleted ]

Agree with all what you say above. However, David W. Forslund's post
seemed to imply that somehow peer-peer was more scalable than c/s, and
that c/s was being abandoned for that reason. I simply questioned
why he felt so.

|> 
|> I agree with the sentiment stated above. We are moving to distributed computing
|> in a peer-to-peer paradigm for the traditional UNIX workstation. As far as souped
|> up PC's go, they are evolving towards this, but are still stuck in the more
|> traditional C/S paradigms.
|> 
|> jon

I dont agree w/ that. If I look at all the distr services I get in my
env, eg,
	- ui (x or open-windows),
	- files (nfs or afs),
	- time (rdate or dtp),
	- directory (x.500 or dns),
	- security (kerberos),
	- print (palladium as well as lpr),
	- news,
	- mail,
I find that all of them are based on the c/s paradigm. Some of these
may not use rpc's, but are client-server nevertheless.

I guess peer-to-peer makes sense in the lower layers (<= 4) of the
iso-osi stack, but above that, a c/s paradigm makes life easier for
the programmer and for system management.

There is a (false) tendency to view the c/s paradigm as all requests
going to giant, very powerful, server in the sky, which leads one to
believe that client-server will not scale well. I was refuting that
point.

-Srivas.