HDTenEightyP/NetNews huggingface dataset:
From: bartlett@pa.DEC.COM ("Joel F. Bartlett")
Newsgroups: comp.lang.scheme
Subject: Scheme->C license conditions
Date: 12 Oct 92 16:21:10 GMT
Article-I.D.: jove.9210121621.AA08064
Organization: The Internet

A recent message posed a few questions about the strings attached to Scheme->C:

-- Do these terms allow use in a commercial product?  Would the seller
-- have to separate scheme-to-C from his proprietary code?  Would one
-- have to put a shrink wrap licensce on the scheme-to-C part?

It is not the intent of Digital's licensing conditions on Scheme->C to prevent
someone from using it in a commercial product.  We'd like to encourage people to
use it in any number of areas, including commercial software.  However, we've
restricted the license to discourage people from trying to go into the Scheme
business using our software.  To date, several commercial organizations have
used the software within their applications and have not found themselves
impeded by our license conditions.  More detailed answers than this require
information about the specific application and advice from Digital's legal
staff.

jfb
Newsgroups: comp.lang.scheme
From: jaffer@zurich.ai.mit.edu (Aubrey Jaffer)
Subject: Re: Looking for a scheme
Organization: M.I.T. Artificial Intelligence Lab.
Date: Fri, 9 Oct 1992 15:57:43 GMT

In article <1992Oct8.175452.5596@netcom.com> thinman@netcom.com (Technically Sweet) writes:

   I'm using DEC's Scheme->C for a project.
   FTP to gatekeeper.dec.com:pub/DEC/Scheme-to-C.

   >    1) Can serve as an application extension language,
   Nicely.
   >    2) Is public domain (can be used a commercial product),
   Not PD but can be redistributed.  See the license.

From the copyright notice:
 * This software may be distributed (but not offered for sale or transferred
 * for compensation) to third parties, provided such third parties agree to
 * abide by the terms and conditions of this notice.  

Do these terms allow use in a commercial product?  Would the seller
have to separate scheme-to-C from his proprietary code?  Would one
have to put a shrink wrap licensce on the scheme-to-C part?
Newsgroups: comp.lang.scheme
From: thinman@netcom.com (Technically Sweet)
Subject: Re: Looking for a scheme
Keywords: PD scheme
Organization: International Foundation for Internal Freedom
Date: Thu, 8 Oct 1992 17:54:52 GMT


I'm using DEC's Scheme->C for a project.
FTP to gatekeeper.dec.com:pub/DEC/Scheme-to-C.


>    1) Can serve as an application extension language,
Nicely.
>    2) Is public domain (can be used a commercial product),
Not PD but can be redistributed.  See the license.
>    3) Has an "class/object" layer ...,
I'm using an add-on object system called MEROON that's
quasi CLOS-ish.  Uses objects with data members and generic functions.
>    4) Allows one to call C and C++ code,
Has a language for declaring C structs & functions.
>    5) The object layer allows one to wrap an existing C++ class heirarchy,
Haven't tried it.  I think C++ is a horrendous botch and
wrote my own C object system.
>    6) Allows one to execute scheme scripts from C/C++ code,
Not documented in the package.  The author posted info on it.
>    7) The scheme can be compiled,
Nice.  Has an interpreter and a compiler.  A basic PI calculator
ran 1/3 as fast as the equivalent C program.  I don't know
what this means.
>    8) The scheme is reasonably portable (SPARC, Intel, Alpha, etc.).
Comes with ports for lots of machines.
>    9) The scheme implementation is reasonable compliant with R4RALS.
It says R3RS.  THe author says it's kosher with R4Rs.

I like it.  I'm planning to port it to DJGPP, the GNU 386-mode DOS compiler.
Has anyone done this yet?


-- 

Lance Norskog

Data is not information is not knowledge is not wisdom.
Newsgroups: comp.lang.scheme
From: thant@void.esd.sgi.com (Thant Tessman)
Subject: Re: MIT Scheme <--> C
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 12 Oct 92 16:14:12 GMT


In article <7530@charon.cwi.nl>, robertl@cwi.nl writes:


> I would like to interface a) to SGI's 3D-graphics library and b) to a simple
> user interface toolkit called FORMS. The graphics library consists of C
> functions, some of which return C longs/floats and/or arrays. The interface
> to the toolkit is more sophisticated; it contains some opaque type 
> definitions and callbacks.
> 
> Any suggestions ? Has someone implemented one of these interfaces 
> already ? (He ask hopefully.... any SGIers out there ?)

First, check out schemetoc/doc/index.[whatever] very carefully.  It is 
all buried in there if you look for it.

Second, this is as far as I got before they found out and 
made me do real work:


---


(module wt (main wt))

(define-c-external (winopen pointer) longint "winopen")
(define-c-external (winclose longint) void "winclose")
(define-c-external event-device longint "qdev")
(define-c-external event-value shortint "qval")
(define-c-external (readqueue) void "readqueue")
(define-c-external (setcolor shortint shortint shortint) void "RGBcolor")
(define-c-external (clear) void "clear")
(define-c-external (qdevice int) void "qdevice")
(define-c-external (rgbmode) void "RGBmode")
(define-c-external (gconfig) void "gconfig")
(define-c-external (reshapeviewport) void "reshapeviewport")

(define-constant redraw-event 528)
(define-constant inputchange-event 534)
(define-constant escape-key-device 7)

(define (wt)

  (let* ((wid (winopen "scheme")))

    (define (redraw)
      (reshapeviewport)
      (setcolor 50 100 200)
      (clear))

    (qdevice escape-key-device)
    (qdevice inputchange-event)
    (rgbmode)
    (gconfig)
    (redraw)
    
    (let loop ()
      (readqueue)
      (display "event: ") (display event-device) (newline)
      (display "value: ") (display event-value) (newline) (newline)

      (cond ((equal? event-device redraw-event)
	     (display "redraw") (newline)
	     (redraw)
	     (loop))
	    ((and (equal? event-device escape-key-device)
		  (equal? event-value 0))
	     (display "exit") (newline)
	     (winclose wid)
	     wid)
	    (else (loop))))))
From: sam2747@shuksan.boeing.com (Scott Moody)
Newsgroups: comp.client-server
Subject: Re: Client/Server - rpc
Date: 15 Oct 92 22:50:59 GMT
Distribution: usa
Organization: The Boeing Co., MMST, Seattle, Wa.
X-Newsreader: TIN [version 1.1 PL6]

It seems RPC has been branded as a total co-routine concept,
where you totally block until the callee is finished
servicing the request, then that callee (server) waits for more.

There is a reason for waiting, and that is because of the return 
parameters. A 'connection' is required in some communication
schemes. Clicking a button, and not having something happen
(even if you wait awhile), is usually better than clicking 6 buttons
and then sometime later seeing 6 things happen.

I think the RPC mechanism should be thought of as the Ada rendevous,
where one blocks until finished retrieving important information.
If there is nothing to return, then let the caller continue.

I have modified the Sun rpc mechanism to provide this 
important capability, which gets close to a threads concept.
This only required a few lines of C code.

I also modified a prototyping language to include a
	CRITIAL_START and CRITIAL_END capability, where one can
copy input parameters, and pass back anything, then both can
go on their way.

Unfortunately the caller still blocks until the server is ready
to read the message -- even if it quickly finishes a rendevous.
If you don't want to block, then provide a queing server that
performs the service of calling the desired server when it
is appropriate, and let you get on.
-- 
Scott Moody   (206) 477-4295   "There are no answers .. just cross references"
     scott@shuksan.boeing.com  
     uunet!bcstec!shuksan!scott
Newsgroups: comp.client-server
From: dwang@ad-11.naitc.com (Dontin Wang)
Subject: REQUEST: FAQ or general client/server info, plus opinions needed
Keywords: client, server, distributed computing
Organization: AC Nielsen Co.
Date:  8 Oct 92 19:15:22 GMT

Hello,
I would appreciate it if anyone can send me a FAQ for this technology, or
make some reading recommendations for the general topic of client/server.
It's been a buzz-word to me for quite a while, and I think I understand
it sometimes and then I don't.

It's kind of confusing when you toss in distributed computing, too.
For example, we're developing an application that's considered by the
people who designed it to be client/server based (I don't necessary dispute
it, I just don't know).  We have a unix database server, and a IBM PC
acting as the client.  The part in question is how we're updating
changes to the database.  We query the database and get result sets
back, let the user manipulate these result sets, and then send the result
sets back to the unix machine, where a process "walks" the result set and
updates the database accordingly (ie inserts new records, updates
changed records, deletes records marked to be deleted).  In this way, we
are able to enforce "business rules" for business data relationship
integrity (ie any credits from any account must correspond to a debit
elsewhere) on the server.  But it seems to me like the server has too
much of the application's logic embedded in it.

Is this a correct way to apply the client-server approach?  Is this a
good way to apply it?  Are there other ways?

Replies via e-mail greatly appreciated.

Thanks,
d/wang
-- 
--------------------------------------------------------------------------------
Dontin Wang
dwang@nis.naitc.com
--------------------------------------------------------------------------------
Newsgroups: comp.client-server
From: kpt@fig.citib.com (Kevin P. Tyson)
Subject: Re: Client/Server - rpc
Organization: IISA
Distribution: usa
Date: Thu, 15 Oct 1992 14:39:06 GMT

In article <7201@transfer.stratus.com> cme@ellisun.sw.stratus.com (Carl Ellison) writes:
>...
>The good point is that it's easy to program -- nothing new -- just the same
>old procedure calls.

This is mostly true.  The network interface can add complications in
the form of exceptions which would not be their in the straightup
procedure call environment.

>The bad point is that while the callee is doing its thing *and* while that
>call is being transmitted *and* while the reply is coming back, the caller
>is twiddling its thumbs -- either literally spinning or doing a task
>switch. 

I'm not sure how ONC handles this but in DCE threads are used so that
the entire process need not block.  When you use threads with rpcs you
effectively blur the line between client and server at the process
level.  For example, in our first DCE based application each user
interface process was both a client of the database server and a
server itself which exported an interface used for asynchronous
message passing between users.  It's possible for one of these
processes to be issuing calls to the database server while servcing
it's own interface simultaneously.


Best regards,
-- 
Kevin P. Tyson		Phone:  212-657-5928	Fax:    212-657-4599
E-Mail: Kevin_Tyson@fig.citib.com or kpt@iisa.com
From: cdblueth@essex.ecn.uoknor.edu (Chris D Bluethman)
Newsgroups: comp.client-server
Subject: Re: scared customers
Date: 8 Oct 92 22:35:27 GMT
Article-I.D.: constell.1992Oct8.223527.3255
Distribution: na
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK, USA

I thought I posted a message here when this group was started, but I guess it did not go through.

We use Gupta's client/server at work and I really like it.  I am really lookign forward to SQLWindows 4.0, a completely object-oriented system.  SqLBase 5.1 is also very near release.  

As for clients unwillingly to change to client/server, emphasis that the LAN environment, coupled with client/server, will probably be the definite trend in the future.  Gupta estimates the client/server market to be around $200 million currently.  Gutpa expects this figure to jump to 1 billion in the next few years.

Another thing, if the client or customer does not want to change to client/server because he likes his slow mainframe, then emphsis gateway software (which Gupta provides) that will link things like DB2 to the LAN world.

                                     


-- 
                        Chris Bluethman

*--->CompuServe: 72347.3306@compuserve.com
*--->Internet: cdblueth@essex.ecn.uoknor.edu
Newsgroups: comp.client-server
From: jeroenkw@htsa.aha.nl (Jeroen Kwast)
Subject: Client-Server
Organization: Algemene Hogeschool Amsterdam, The Netherlands
Date: Thu, 15 Oct 1992 11:16:41 GMT


Hello out there,

We were supprised to hear that a newsgroup exists about our great client-server.

If you know it please give us some comments!


						MM.
Newsgroups: comp.client-server
From: dil.admin@mhs.unc.edu (Dave Laudicina)
Subject: re: Defining Client-Server
Organization: UNC Office of Information Technology
Date: Wed, 14 Oct 1992 12:27:02 GMT

In article <1992Oct12.165832.10614@devildog.att.com>  writes:
I think you have given an excellent definition of client server.

>In order to define client-server computing we have to be practical
>about it.  It doesn't exist just for it's own sake, it accomplishes or
>enables something to happen. I believe client-server is based on moving
>processing to processors that can do it the best. By the best, I mean
>at the least cost for processing and network. This moving of processing
>can be called partitioning. An application can be partitioned to
>optimize it's performance. The pieces we partition are conventionally:

Productivity benefits and the resulting cost benefits
to the user are important as well as cost of 
processing and network. 

>o Presentation
>o Processing
>o Data
>
>Presentation is the display portion, everything necessary to draw the
>screen and present the data. This is the part the user sees. Processing
>is the unseen part of computing. The manipulation that an application
>must do to move, compute, and prepare data for Presentation or Data.
>Data is the data management piece, mostly represented by Data Base
>Management Systems, but also could include simpler file management.
>
>Using these ideas, that we want to partition the three pieces of
>computing to optimize an application, we can see how a simple example
>of client-server evolved. Look at the ATM machines. They obviously are
>mostly Presentation. They can't all be expected to have the Data piece,
>so they are probably partitioned (simplified) as follows:
>
>Client ATM's
>	Presentation
>	Processing <---+
>                   |
>Bank Server(s)     |
>	Processing <---+
>	Data
>
>The Client and Server are then communicating their transaction at a
>Processing to Processing level, using whatever protocols or method is
>available and useful for the network. The important part is that the
>servers do not have to worry about Presentation protocols on the
>ATM's.
>
>There is clearly a lot more to client-server, but the important concept
>is partitioning of Processing, Presentation, and Data.
>


Newsgroups: comp.client-server
From: berlin@is.morgan.com (Alexander Berlin)
Subject: Re: Client/Server - rpc
Organization: Morgan Stanley - IS
Distribution: usa
Date: Fri, 16 Oct 1992 20:07:19 GMT

In article <7201@transfer.stratus.com>, cme@ellisun.sw.stratus.com (Carl Ellison) writes:
|> The bad point is that while the callee is doing its thing *and* while that
|> call is being transmitted *and* while the reply is coming back, the caller
|> is twiddling its thumbs -- either literally spinning or doing a task
|> switch.  As processors get faster, the time for the callee to do its thing
|> goes down -- but the communication time doesn't (since the speed of light
|> doesn't change).  So the number of instructions wasted in the caller goes
|> up, if the caller spins.  This forces the caller to task-switch or waste
|> time.

Let me disagree. Don't forget that the speed of light is not the only source of
network communications bottleneck. In my understanding, a very little portion
of latency is due to the light speed limit. On a local network with a physical
range of say 10 miles, the light would make a roundtrip in about 0.1 msec 
(10 * 2 / 186000 ) wich is quite acceptable. 

The real delays which are in the range of 5-100 msec come
in my understanding from routers, gateways, packet switcher, network overload, ...

If I remember correctly, the theoretical speed limit of a network packet 
is something around 0.8 * c (eighty percent speed of light).

So, as processors become faster, so do the routers and gateways. We are also going
to have networks with much higher capasity which will increase the size of
packets and reduce the number of packets required.

It is my understanding that in the nearest future (10-15 years) the processors 
(and not the networks) will be the bottleneck in the RPC or any client-server
scenario.

-- 
Alex Berlin                     
berlin@is.morgan.com
From: bturner@hpcvusc (Bill Turner)
Newsgroups: comp.client-server
Subject: Re: Client/Server - rpc
Date: 13 Oct 92 22:05:03 GMT
Article-I.D.: hpcvusn.1992Oct13.220503.21827
Distribution: usa
Organization: Hewlett-Packard Company, Corvallis, Oregon USA
X-Newsreader: Tin 1.1 PL5

Carl Ellison (cme@ellisun.sw.stratus.com) wrote:
> The bad point is that while the callee is doing its thing *and* while that
> call is being transmitted *and* while the reply is coming back, the caller
> is twiddling its thumbs -- either literally spinning or doing a task
> switch.

This is why DCE requires multi-threading, at least in the server.  If
you can multi-thread your client, then you can (potentially) be doing
useful processing while waiting for the request to process.

--Bill Turner (bturner@cv.hp.com)
HP User Interface Technology Division, Corvallis
Newsgroups: comp.client-server
From: craigdo@microsoft.com (Craig Dowell)
Subject: Re: Lotus Powerbook
Date: 09 Oct 92 23:24:21 GMT
Organization: Microsoft Corporation

In article <1992Oct9.164055.11341@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:
>In article <Bvtx14.60I@comp.vuw.ac.nz>, Gavin.Flower@comp.vuw.ac.nz (Gavin Flower) writes:
>>
>> Not to mention POWER is the code name for the project to develop a
>> portable workstation for the European education market, headed by
>> Acorn Computers, based on a new ARM chipset...
>
>Funny, I thought POWER was the acronym IBM used to refer to the CPU
>architecture in the RS/6000. (No, I can't remember what it stands for.)
>Hence the PowerPC initiative with Motorola and Apple, to pack all that
>functionality onto one chip, so it's fit to use in a PC instead of a UNIX
>box.

Yeah, it's Performance Optimized With Enhanced Risc as I recall.  Pretty
lame, eh?

-- Craig

Newsgroups: comp.client-server
From: allen@geac.com (Allen Septon)
Subject: charter
Date: Fri, 9 Oct 1992 13:00:43 GMT
Organization: Geac Computer Corporation


I am sorry that I did not post this first thing to the new group.
-----------------------------------------------------------------

Results of vote for comp.client-server:
======================================

202 YES
39  NO

Name:
	comp.client-server

Status:
	unmoderated

Charter:

	An open forum to discuss topics relating to client/server technology. 
	Subscribers can discuss issues relating to programming, databases,
	communications, LAN technology, pricing, and hardware. 
	This group will be open to users of DOS, OS/2, NOVELL, UNIX, AIX,
	etc. etc. based front and backends.


Newsgroups: comp.client-server
From: jeroenkw@htsa.aha.nl (Jeroen Kwast)
Subject: Re: Client-Server
Organization: Algemene Hogeschool Amsterdam, The Netherlands
Date: Thu, 15 Oct 1992 11:38:40 GMT

In our client library section of the Magicus is I found a poem:

As colours fade
to lengthened shades
And cristal eyes
Gaze to Hades

Darkended visions
Of ancient thoughts
The faith to reason
Is what I fought

Yesterdays of bygone days
Still feel the past
The day will come
That I die at last

Crimson tears
And Blackened hearts
Let blood run free
As Satan farts...

In the mistery church is a saing soho poem:

Sear me
Misery and loneliness
Things I feel
And nothing less

I hate my father
I hate my son
As days go by
I greet the sun

Are you hungry
Eat my flesh
Eat my bones
And nothing less

This doleful chant
Of dark lament
Grievous forebodings
Of ominous sorrow

I count the stars
And see all seven
Suck my dick
And go to heaven...

And in the Donny armour shop is a book that says:

Smell my flowers
Taste my fruits
Feel my thorns
Hear my flute

My roots pierce
The earth I feel
As the wind caresses
To close my seal

I drop my seeds
To further life
To strengthen the ashes
Of my own life

Now I'm dead
My sons will tell
Where I will go
I go to hell

Please try and solve these small riddles!!

						Magicus M.

-- 
On a dark day Magicus M. said to me:  It's better to create an illusion of life,
                                      than live to create illusions.
Newsgroups: comp.client-server
From: jonny@hsr.no (Jonny Rein Eriksen)
Subject: Lotus Powerbook
Organization: Rogaland University Centre
Date: Wed, 7 Oct 1992 18:49:21 GMT

Are there anybody out there with some info on Lotus new link between Notes and 
about 40 Database-systems . I need to know a few things about this as I am
currently starting a new project which should make direct communication between
LOTUS Notes and GUPTA SQL Base possible . As you probably understand , I dont
want to do something LOTUS already has done. My Source gave me a release date
around 1'st quarter 93 ? Is this correct ?

Also I would be interested to know if Powerbook is going to support GUPTA SQL-Base


If anyone can help, please followup or E-Mail at jonny@hsr.no
From: caveh@spartacus.csl.sri.com (Caveh Jalali)
Newsgroups: comp.client-server
Subject: Re: scared customers
Date: 11 Oct 92 05:15:56 GMT
Distribution: na
Organization: Kernel Labs.  NOT!

In article <1992Oct5.131632.27931@geac.com> allen@geac.com (Allen Septon) writes:


>   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.

if i werent' a CS type, i'd be scared of it, also.  i think it's a mistake
to expose the general customer to such techno jargon unless they ask for it!
for example, when was the last time NFS was sold as a client-server file
system?

for example, NFS was accepted on the merits of its functionality/capabilities,
not architecture.

*sarcasm on*

i bet this whole issue started when SUN started to claim they were the industry
leader in client-server computing.  it looks great on paper, and probably was
worth millions on wall street.  then, others jumped on the band wagon.

beyond that, the client server model is just one of many implementation details
that helps satisfiy certain functional requrements.

*sarcasm off*

00c
--
00c -- caveh@csl.sri.com
"X is not a letter, it's a sentence."