HDTenEightyP/NetNews huggingface dataset:
From: jogl@merry.imsd.rwth-aachen.de (Joachim Glaubrecht  #Alwd#)
Subject: WANTED: mini-RS232-LAN (PD/SHAREWARE)
Organization: Institut f. Med. Statistics @ Dokumentation
Date: Mon, 27 Jul 92 08:08:28 GMT



hi,
 
for a medical institut with nearly no budget i'm looking
for a simple (cheep) RS232-"LAN".

the idea:

PC A and B are connected via RS232.
PC B can use PC A's HardDisk as own drive D:.

are there ANY PD/SHAREWARE prgs. that can do such a job ?
 
-- 
  ___             ____________________________________
 /  /  _____     !  jogl@tolkien.imsd.rwth-aachen.de  !
 __/__/_/ Gl     ! Inst. f. Med. Stat. & Doku. (IMSD) !
/_/              !___Aachen__Germany__Europe__Earth___!
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: Your chance to contribute to new POSIX archive format
Date: 25 Jul 1992 18:21:38 -0700
Organization: U of Toronto Zoology
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: henry@zoo.toronto.edu (Henry Spencer)

>Submitted-by: Christophe.Wolfhugel@univ-lyon1.fr (Christophe Wolfhugel)
>The current limit of around 100-128 characters for the filename
>is catastrophic. Simply too short!

Actually, the 1003.1 tar format accommodates 255.  Still a bit tight
for some people.

>Also I guess users would appreciate: the ability to archive
>in absolute format and restore in relative...

This is really a user-interface issue, not a format issue.  There's no
reason why tar couldn't have had some sort of renaming facility from
the start (and we certainly are long overdue to have it added).
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry


Volume-Number: Volume 28, Number 61
From: david@mks.com (David Rowley)
Newsgroups: comp.std.unix
Subject: Re: Your chance to contribute to new POSIX archive format
Date: 26 Jul 1992 13:50:52 -0700
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
NNTP-Posting-Host: ftp.uu.net
Summary: Address correction for IEEE
X-Submissions: std-unix@uunet.uu.net

Submitted-by: david@mks.com (David Rowley)

Actually, if you want more info on joining POSIX working groups, etc
contact:

	Lisa Granoien
	IEEE Computer Society
	1730 Massachusetts Ave NW
	Washington, DC 20036-1903
	(202) 371-0101
	FAX: (202) 728-9614

David.

-- 
David Rowley
Mortice Kern Systems Inc.
35 King Street North, Waterloo, ON, Canada N2J 2W9
519/884-2251, FAX 519/884-8861, david@mks.com


Volume-Number: Volume 28, Number 63
From: Christophe.Wolfhugel@univ-lyon1.fr (Christophe Wolfhugel)
Newsgroups: comp.std.unix
Subject: Re: Your chance to contribute to new POSIX archive format
Date: 25 Jul 1992 13:52:31 -0700
Organization: INSA Informatique, Lyon, France
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: Christophe.Wolfhugel@univ-lyon1.fr (Christophe Wolfhugel)

david@mks.com (David Rowley) writing about PAX:
> larger field sizes for dates, times, file lengths, etc.

And also, something that nor tar nor cpio have: large file names.

The current limit of around 100-128 characters for the filename
is catastrophic. Simply too short!

Also I guess users would appreciate: the ability to archive
in absolute format and restore in relative. Not all users do
relative archives. And one knows how dangerous an absolute
archive can be. Even when I get a tape from the oustide I prefer
being able to restore it in relative mode, without having to
check before it all files on the archive are or not absolute.

-- 
Christophe Wolfhugel    |    Email: Christophe.Wolfhugel@univ-lyon1.fr
   "No keybord, press F1 to continue"


Volume-Number: Volume 28, Number 60
From: mark@alsvid.une.edu.au (Mark Garrett Internet: mark@arvak.une.edu.au Phone: +61 66 20 3859)
Newsgroups: comp.std.unix
Subject: Re: Your chance to contribute to new POSIX archive format
Date: 30 Jul 1992 22:53:03 -0700
Organization: University of New England - Northern Rivers (Lismore)
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: mark@alsvid.une.edu.au (Mark Garrett Internet: mark@arvak.une.edu.au Phone: +61 66 20 3859)

>From article <14sun2INNqk@ftp.UU.NET>, by henry@zoo.toronto.edu (Henry Spencer):
>>Submitted-by: Christophe.Wolfhugel@univ-lyon1.fr (Christophe Wolfhugel)
>>The current limit of around 100-128 characters for the filename
>>is catastrophic. Simply too short!
> 


I'd very much agree with this statement. In BSD file names can be nearly 1
block long (1024 characters - inode) 100-128 is very short. 

	Since I just come into this discussion ; By file name length
does this refer only to each directory/file name or the full path?

	Or does the standard have other means of recording the files path +
a file name of 100-128 characters?

	Why is it necessary to have fixed length filenames anyway? I would
have thought it was just as easy to have a variable length file name in the
range of 1-2^16 or even 1-2^32 as if was to have 1-128 or 255.


> Actually, the 1003.1 tar format accommodates 255.  Still a bit tight


	I've tripped up on this little beauty even in standards BSD tar
while copying directories (i.e tar cf - . | (cd /dir;tar xpf -) where
the directory path exceeds the limit on filename. Which is very
easy to find in copying user directories.


	Cheers
		Mark :)
-- 
Mark Garrett	Internet:  mark@arvak.une.edu.au	Phone: 	+61 66 20 3859
   University of New England, Northern Rivers, Lismore NSW Australia.


Volume-Number: Volume 28, Number 68
From: glenn@rainier.berkeley.edu (Glenn Hoogerwerf)
Newsgroups: comp.std.unix
Subject: XPG4 Question
Date: 30 Jul 1992 15:28:49 -0700
Organization: Tandem Computers, Inc.
Reply-To: hoogerwerf_glenn@tandem.com (Glenn Hoogerwerf)
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: glenn@rainier.berkeley.edu (Glenn Hoogerwerf)

    After reviewing the XPG4 snapshot, I am left with the following
question.  If a utility is marked as TO BE WITHDRAWN in XPG4, does
this open the utility up as being waiverable.  In other words, does
one have to implement pax, tar, and cpio, instead of just pax.  
Another example is cc and c89.  It seems unreasonable that one 
would have to implement a dead interface, such as cc, if it is going
away in the next release.  I realize that many of the interfaces
might consist of shells that turn around and call the POSIX.2 
interface, but in the case of lint or dis, life is not that simple.

- Glenn Hoogerwerf
-- 
---------------------------------------------------------------------|
Glenn Hoogerwerf                GUARDIAN POSIX project
Tandem Computers, Inc.		
10600 N. Tantau Avenue		PHONE:  (408) 285-2662
Cupertino, CA   95014		EMAIL: hoogerwerf_glenn@tandem.com

Volume-Number: Volume 28, Number 67
From: djm@eng.umd.edu (David J. MacKenzie)
Newsgroups: comp.std.unix
Subject: Re: Your chance to contribute to new POSIX archive format
Date: 25 Jul 1992 18:22:04 -0700
Organization: Project GLUE, University of Maryland
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: djm@eng.umd.edu (David J. MacKenzie)

   And also, something that nor tar nor cpio have: large file names.

   The current limit of around 100-128 characters for the filename
   is catastrophic. Simply too short!

POSIX.1 cpio format has no limit on the length of pathnames, although
some existing implementations may place artificial limits on the
length.  POSIX.1 tar format has a limit of 100 to 256 bytes, depending
on where slashes are located in the path.

   Also I guess users would appreciate: the ability to archive
   in absolute format and restore in relative. Not all users do
   relative archives. And one knows how dangerous an absolute
   archive can be. Even when I get a tape from the oustide I prefer
   being able to restore it in relative mode, without having to
   check before it all files on the archive are or not absolute.

As GNU tar has demonstrated, the handling of leading slashes in
pathnames is independent of the archive format.  It's a trivial bit or
two of code in the archiving program that can be used with any format.


Volume-Number: Volume 28, Number 62
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: Your chance to contribute to new POSIX archive format
Date: 29 Jul 1992 15:15:09 -0700
Organization: U of Toronto Zoology
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: henry@zoo.toronto.edu (Henry Spencer)

>Submitted-by: les@chinet.chi.il.us (Leslie Mikesell)
>[822 as archive format]... Other data types can be identified
>to the extent possible and the type of encoding/encryption/compression
>can be noted per-item...
>One thing that is needed here is to be able to generate multi-part
>archives, possibly spliting files across media...

One thing that disturbs me about this suggestion is that the participants
don't seem to be aware of RFC 1341, which extends RFC 822 in a number of
ways that are relevant to this discussion.  RFC 1342 is also noteworthy.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry


Volume-Number: Volume 28, Number 66
Newsgroups: comp.std.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: bitwise logical operations on pointers
Organization: TauMetric Corporation
Date: Fri, 24 Jul 1992 17:52:09 GMT

rgp@seiko.mpd.tandem.com (Ramon Pantin) writes:

>Somewhere along the evolution of C this type of expressions where made illegal:
>	char	*p = ...;
>	p &= ~1;

>the workaround:
>	p = (char *) ((int)p & ~1);

>makes my code:
>	- harder to write
>	- less portable because it assumes that there is an integral type
>	  (if not "int", "long") that has enough precision (bits) so that
>	  the casts will be harmless.

You could use 'unsigned long' rather than 'int' to improve the chances of
the code working.

The workaround is not less portable, since bitwise operations on pointers
are not portable at all.  Any such messing with pointers has to be
confined to machine-specific modules to have any hope of porting your
program.  If it makes sense to bit-twiddle a pointer, nothing prevents
a compiler from providing an extension to do so -- the Standard only
requires the compiler to have a way to diagnose such code as an error.

The reason the C Standard makes such twiddling illegal is that there is
no way to specify semantics for it (in the context of a programming-
language Standard).  It doesn't make any sense to me to say that a
construct is completely legal but has no defined semantics.

Those things in the C Standard which have undefined behavior are
those which are in general infeasible to detect at compile time.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.std.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Alternatives to operator.()
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 25 Jul 1992 09:55:03 GMT

cok@sunshine.Kodak.COM (David Cok) writes:

>In article <9220614.4939@mulga.cs.mu.OZ.AU> fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>
>>The more I think about this the more I like it.
>>In fact I would say that is is *better* than just allowing
>>	r.invalidate_cache();
>>since you *want* meta-operations to stand out as being semantically different
>>to standard operations. This method allows you to clearly seperate the two.
>>Also in general you might want to control access to meta-operations, and
>>having this seperation also makes that easier.
>
>No, I don't want meta-operations to stand out.  I want to be able to design
>interfaces in which construction, copying, destruction, conversion all happen
>silently and automatically where the interface designs them to.  The same
>would apply to operator. if it were allowed to be overloaded.

But these operations *would* be silent and automatic for the SmartRef
class I was thinking of. It's only meta-operations like invalidate_cache()
that would stand out. (Maybe I don't understand what you mean?)

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.std.c++
From: mat@mole-end
Subject: Re: Alternatives to operator.()
Summary: May I suggest ...
Organization: :
Date: Tue, 21 Jul 1992 09:47:10 GMT

In article <1992Jul20.235728.29058@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
 
> In case you've forgotten, I've answered these "objections" repeatedly.
     
> |      2) Your operator.() proposal continues to require forwarding functions
> |         for member operators and conversion operators in the target class,
> |         even though the requirement of forwarding functions was one of the
> |         most significant criticisms you advanced against the status quo.
 
> My operator.() proposal DOES NOT require forwarding functions unless
> the implementor of the reference class DESIRES to use forwarding functions.
> The functions that the implementor of the reference class might *desire*
> to implement are those small set of functions that ARM currently requires
> the LHS to be a member, . . .
 
> |      3) Your operator.() proposal requires use of circumlocutions to access
> |         members of the smart reference object.
> 
> My proposal DOES NOT require use of circumlocutions to access members of
> the smart reference object.  Circumlocations are POSSIBLE, if the implementor
> of the reference class so desires.  . . .

Perhaps concrete examples might make these points clearer?  I know they
take more time than stating the points, and often take up many lines, but
they have a marvellous way of clearing things up.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
Newsgroups: comp.std.c++
From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Alternatives to operator.()
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 24 Jul 1992 04:37:40 GMT

To expand a little on my previous post:

>Alternatively you could define one function on smartrefs that returns
>a smartref-controller:
>
>	Smartref r;
>	control(r).invalidate_cache();
>	control(r).query_status();
>
>This looks like a nice way of doing it to me, since it visually flags
>the use of meta-operations, while still allowing the normal "." syntax.

The more I think about this the more I like it.
In fact I would say that is is *better* than just allowing
	r.invalidate_cache();
since you *want* meta-operations to stand out as being semantically different
to standard operations. This method allows you to clearly seperate the two.
Also in general you might want to control access to meta-operations, and
having this seperation also makes that easier.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: rgp@seiko.mpd.tandem.com (Ramon Pantin)
Newsgroups: comp.std.c++
Subject: bitwise logical operations on pointers
Date: 24 Jul 92 04:39:46 GMT

Somewhere along the evolution of C this type of expressions where made illegal:
	char	*p = ...;
	p &= ~1;

the workaround:
	p = (char *) ((int)p & ~1);

makes my code:
	- harder to write
	- less portable because it assumes that there is an integral type
	  (if not "int", "long") that has enough precision (bits) so that
	  the casts will be harmless.

I understand that (in theory) any code that does bitwise logical
operations (|, &, ~, etc.) is not portable because it is somehow interpreting
the representation of the pointer while doing such manipulations.  In practice,
for the type of work that I do (writing operating systems) and for the class
of machines that I'm interested in (machines with large flat virtual
address spaces)
I don't need to worry about machines with bizare addressing machanisms.

Could the people in the ANSI C++ committe consider allowing these traditional
K&R expressions back into the ANSI C++ language?

Do I have to write a _proposal_ for this?

Does anybody know what was the rationale for making these expressions illegal
in ANSI-C ?

Ramon Pantin
From: hendrik@vedge.UUCP (Hendrik Boom)
Newsgroups: comp.std.c++
Subject: Re: New operators wish list
Date: 23 Jul 92 13:52:26 GMT
Organization: Visual Edge Software, St. Laurent, Quebec

hwrvo@kato.lahabra.chevron.com (W.R. Volz) writes:
: In article <658@manutius.UUCP>, garyp@manutius.UUCP (Gary Powell) writes:
: 
: .i.e, x (op)= y;  <==>   x = x (op) y;

Because x <= y is not the same as x = x < y.
-- 
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work:	hendrik@vedge.com,  iros1!vedge!hendrik
at home:	uunet!altitude!ozrout!topoi!hendrik
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: abstraction (was: Re: Give me a break)
Date: 23 Jul 92 18:05:35 GMT
Organization: Microsoft Corporation

In article <1992Jul23.020241.11513@cmcl2.nyu.edu> checker@acf3.nyu.edu (Christopher Hecker) writes:
|Hmm, I'm not sure you want to make this argument.  Carried to its
|extreme, we could say, why are so many people using OWL?

How many people ARE using it?  If many people are using it, why aren't the
other compiler vendors licensing it?

Newsgroups: comp.std.c++
From: pjl@sparc1.cs.uiuc.edu (Paul Lucas)
Subject: Re: New operators wish list
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Tue, 21 Jul 1992 16:06:35 GMT

In <658@manutius.UUCP> garyp@manutius.UUCP (Gary Powell) writes:

>Ok, Ok Ok...lets cut the relgion and get to the meat of the matter.

>It appears to me that there are a large number of folks who want the following
>new operators added to the language.

>1) ||=

>   where:  x ||= y   <==>  x = x || y

>   Seems resonable as it matches all the "Blah"= operators.

*****>	I would assume (hope?) that the semantics would be similar to
	plain ol' || in that if x is already true, y will not be
	evaluated.

>2) &&=

>   where:  x &&= y   <==>  x = x && y

>   Also seems reasonable for the same issue as #1.

*****>	Same idea.

>3) ===

>   where x === y   <==> x = x == y

>   I have more trouble looking at this one, but again it still fits the
>   "blah"= operator rule.  So it maybe that I just haven't thought about
>   it long enough. Anyway I recommend it.

*****>	Is this _that_ useful?  For completeness you'd also have to add:

		x !== y
		x <== y
		x >== y
		x <= y		// oops! <= is already an operator!
		x >= y		// ditto

	How about implication?

		x => y	 <==>   !x || y
	
	And of course:

		x =>= y  <==>	x = x => y

	:)  Seriously, I think we're going into operator overload (pun
	intended).  Operators are like Lays (TM) potato chips: you can't
	eat...er...add just one because if you add operator @ someone
	will want (and complain until the cows come home) that operators
	!@ and @= don't exist.

>4) some set of chars yet to be determined which bind tighter than the * and /
>   for which x power y  is x raised to the power of y.

*****>	I'm not gonna touch this one; basically, I don't care because
	I'll probably only have occasion to use it even less that I use
	floats or doubles...and that's not a lot.

>   This seems reasonable but again has the problem of what do we do with
>   the odd ball arguments of y and x?

*****>	Hopefully the same things that pow() does so code that switches
	from pow() to whatever won't break.

>   I recommend we define it as an operator but leave its implementation alone
>   and let everyone overload it as they see fit. And I don't care which
>   set or single character is chosen. My reasoning is that the current
>   arguments don't seem to be converging.  Maybe someone else (I'm sure I'll
>   see heat on this one.) would care to summarize the arguments on this.

>5) "."
>   Lets add this.  I mean really, no one's code will break if we have it,
>   the earth will not shake and the sky fall down.  If it turns out to be
>   not as useful as Jim claims..so what?  We'll drop it from language "D"
>   the next generation.

[ ...other commentary deleted... ]
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.std.c++
From: pjl@sparc1.cs.uiuc.edu (Paul Lucas)
Subject: Re: How do I... (regarding overloading)
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Tue, 21 Jul 1992 23:29:59 GMT

In <1992Jul21.144856.583@ualr.edu> choate@acs.harding.edu (Brad S. Choate) writes:

*****>	For starters, this type of question belongs in comp.lang.c++.

>Ok... I'm new at this business, so this should be easy for some of the experts
>out there.

>I know about operator overloading and I can implement it to some degree without
>consulting the manuals too much, but I'm stuck on this one:

>    a[1]=x;

>Ok.  "a" is an object that I have created and I've overloaded the [] operator
>to allow me to return a value at position "1" (in this case) from my object.
>However, in this case, I'm not needing output, I'm trying to _assign_ a value
>to that position.  I know how to overload the "=" operator, but _how_ do you
>do _both_ operators at the same time?

*****>	operator= has got nothing to do with it unless the thing that []
	returns is itself a class object (in which case operator= would
	be overloaded in _that_ class--whether operator= is overloaded
	in _this_ class is irrelevant...unless you're doing something
	non-canonical).  operator[] should return a reference to the
	thing...that's it; the assignment just happens.  

		class IntVect {
			int *v;
		public:
			// ...
			int &operator[]( int i ) { return v[i]; }
		};
	
	This is a naive example in that it doesn't do bounds-checking nor
	automatic "growing."
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.std.c++
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.std.c++
Subject: Re: New operators wish list
Date: 23 Jul 1992 07:03:21 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: rbbb

In article <658@manutius.UUCP> garyp@manutius.UUCP (Gary Powell) writes:
>5) "."
>   Lets add this.  I mean really, no one's code will break if we have it,
>   the earth will not shake and the sky fall down.  If it turns out to be
>   not as useful as Jim claims..so what?  We'll drop it from language "D"
>   the next generation.

It would be nice if it were so easy to undo an addition.  (You were
joking, right?)

>Lets get on with it.  Like it or not many of us have to work with C++ even
>though language "X" is better at some other task.  Lets add the features folks
>clamor for.

Those people that I know who dislike C++, dislike it because they
believe it contains too many features (that cannot now be removed).
I know that I don't use the entire language, and neither do the people
that I work with (in fact, we have informal coding standards along the
lines of "avoid X, Y, and Z".)

>We still have a lot of other pressing problems, like how to incorporate 
>persistance, and how to do good garbage collection, and how to at run time
>create objects whose type isn't known until after the program is running.

Don't hold your breath.  Adding persistence will be very hard, because
(if I understand the work going on at U Mass. to add persistence to
Modula-3) persistence is equivalent to having an accurate compacting
garbage collector.  Maybe you are using a different definition of
persistence.  There are other ways to implement garbage collection, so
adding that alone should be easier.  (It has been done for friendly
users, but there are still some hazards involving the optimizer that
people are working on).

David Chase
Sun
(dchase@eng.sun.com)
Newsgroups: comp.std.c++