HDTenEightyP/NetNews huggingface dataset:
From: smb3u@kiptron.psyc.virginia.edu (Steven M. Boker)
Subject: Re: More on ND compression (followup survey)
Organization: University of Virginia, Department of Psychology
Date: Sat, 11 Apr 1992 22:02:31 GMT

In article <1992Apr11.170249.9411@cs.mcgill.ca> samurai@uriel.cs.mcgill.ca (Darcy Brockbank) writes:
>
>NeXT picked up my postings about the first ND survey (re: do you 
>need compression?) and asked for the letters you all sent me.
>AS well, it was remarked that it would be very useful to them if
>developers could state why compression is needed... I quote:
>
>"It would be very useful to know why people need compression in terms of
>application. It would also be useful to know what kind of resolutions and what 
>kind of compression ratios are desired again related to the application."
>

Our group is interested in putting scientific visualizations directly 
onto videotape using the Dimension card.  For our needs, compression doesn't
have to happen in real time.  Uncompression does have to happen in
real time.

Here are the numbers as far as I can see.  512x650x24x30 bits per second
need to be sent to the video.  Thats just under 30Mbytes/second.  I would
hate to have to rely on more than .25Mbytes/second sustained transfer
from my hard disk, although twice that is possible under ideal conditions.
Thus 120/1 compression ratio would be good and 60/1 compression might
just barely work under ideal conditions.

People have worked these numbers out many times before.  In fact I've
heard them from NeXT people when the dimension was first announced.
I thought that this was what we were promised when we placed our order
for the Dimension card in the first place.  Is there some sort of
collective amnesia happening here?

Steve

-- 
 #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#
 #  Steve Boker           #             "Two's bifurcation                  #
 #  smb3u@virginia.edu    #             but three's chaotic"                #
 #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#
From: dkoski@cs.arizona.edu (David Koski)
Newsgroups: comp.sys.next.programmer
Subject: super speed & gcc2.1
Date: 17 Apr 92 20:22:16 GMT
Organization: U of Arizona CS Dept, Tucson

In one of the gnu.gcc groups there was mention that -fstrength-reduce (which
used to speed programs up quite a bit, although results varied by program)
did not do very good optimization.  I checked this out, and in fact
-fstrength-reduce (using gcc 2.1) really sucks.

I used dhrystone 1.1 to see what kind of difference it might make.  First,
I tried the old gcc (v 1.36, the one that comes with the system).
$OPT is a variable that turns on ALL optimization for cc.  $OPT2 turns
on ALL optimization (except loop unrolling) for gcc (v 2.1).  $LOOP2 turns
on loop unrolling.

gorgatron% cc $OPT dry.c
a.out
gorgatron% a.out
Dhrystone time for 500000 passes = 16
This machine benchmarks at 30581 dhrystones/second
gorgatron% gcc $OPT2 dry.c
gorgatron% a.out
Dhrystone time for 500000 passes = 13
This machine benchmarks at 36945 dhrystones/second

So, clearly gcc 2.1 generates better code.  Now let's try some stuff with
-fno-strength-reduce.

gorgatron% gcc -O -O2 -fno-strength-reduce dry.c
agorgatron% a.out
Dhrystone time for 500000 passes = 13
This machine benchmarks at 37831 dhrystones/second
gorgatron% gcc $OPT2 -fno-strength-reduce dry.c  
gorgatron% a.out
Dhrystone time for 500000 passes = 13
This machine benchmarks at 38071 dhrystones/second
gorgatron% gcc $LOOP2 $OPT2 -fno-strength-reduce dry.c
gorgatron% a.out
Dhrystone time for 500000 passes = 11
This machine benchmarks at 43041 dhrystones/second

43041! Not bad.  So turning strength reduction off seems to be a performance
win (at least for this program).

David Koski
Newsgroups: comp.sys.next.programmer
From: Jim De Arras <jmd@banana.handheld.com>
Subject: Re: More on ND compression (followup survey)
Organization: Hand Held Products, Inc.
Date: Mon, 13 Apr 1992 00:44:49 GMT

In article <CNH5730.92Apr12170251@calvin.tamu.edu> cnh5730@calvin.tamu.edu
(Charles N. Herrick) writes:
>In article <1992Apr12.150556.10435@cube.handheld.com> jmd@banana.handheld.com
(Jim De Arras) writes:
>   I'm glad to see NeXT is looking into this issue.
>   A peaceful settlement would
>   be best.  I understand under Virginia law, I could probably make bait and
>   swiitch stick.  I think enough other states are able to do so, 
>   also, so that a class action suit for fraud could be possible.
>
>Hope this won't come to pass. All of us would be badly-served by this.
>
>	chuck <cnh5730@calvin.tamu.edu>
>--
> <->   My personal opinion, speaking only as myself, an individual :-)   <->
>	<->	Not an official document of anyone	<->
>	     <-> from: a SUN SPARC1+ w/ SUNos 4.1 <->
> 	    Charles N. Herrick <cnh5730@calvin.tamu.edu>
>
>
I agree, but I must explore all my alternatives.   NeXT has mis-led (read LIED
to) me (and others, I believe) about the ND board.  They did NOT deliver what
they sold.  For a while, it looked like they were still behind the product, and
would fix the lack of compression, swapfile leak, etc., but now it has become
obvious to this thick-headed person that NeXT has pretty much told me where I
can stick it.  A multi-media project my company had has been canceled due to my
decision to buy a NeXTdimension system, rather than add Raduis-TV and a bunch
of other boards to a Mac FX, which would have produced a much more capable
multi-media system than the NeXTdimension has turned out to be, though far less
than was it was promised to be.  I'm smarting from my failure to deliver, based
on NeXT's published specs.  The ND is not 'color done right'.  It makes a
pretty picture, but that's about it.

I am by no means threatening legal action at this time.

Jim De Arras
From: strobel@phys.washington.edu (Nicolas Strobel)
Newsgroups: comp.sys.next.programmer
Subject: PSsetfont and PSxyshow examples needed
Summary: request for example code using PSsetfont and PSxyshow
Keywords: PSsetfont PSxyshow
Date: 10 Apr 92 09:04:05 GMT
Article-I.D.: dirac.strobel.702896645
Distribution: world,local
Organization: University of Washington

Yo!
I need an example program that uses the 
PSsetfont() and PSxyshow() (or PSxshow() or PSyshow()) functions.

The manuals are not that helpful on what is wanted or how to set up the
arguments for these commands. None of the code in NextDeveloper/Examples
uses them. NextAnswers did not have any examples either. Yes, I want to
use these functions and do not want to use the Font class methods. Can
someone send me some working example code?

Thanks!

Nick Strobel
strobel@phast.phys.washington.edu
Newsgroups: comp.sys.next.programmer
From: bryan@ad.cise.nsf.gov (Bryan Thompson)
Subject: lockf - is it broken
Organization: National Science Foundation
Date: Wed, 8 Apr 1992 15:35:15 GMT

I am trying to port the Faircom ctree+ ISAM package to the next and I am  
encountering a problem with lockf() - basically, lockf() persists in claiming  
that it is being passed an invalid argument -- frankly it looks like lockf() is  
broken.

So, is lockf() broken?  If not, what can be done to make this code run?  I have  
included a small program with an abundance of trace statements and a sample of  
the output that it generates for me. I am using version 2.1 of the NeXT OS and  
the 'NeXT Release 2.0 (v31.1) -- GNU version 1.36' version of gcc.

------- cut here ---------
#include <stdio.h>
#include <sys/fcntl.h>
#include <stdlib.h>
#define BCREATE (O_RDWR | O_CREAT | O_EXCL)

void MyCreate(void)
{
int retval = open("tmp",BCREATE,0666);		/* Create file. */
perror("create:"); printf("retval = %d.\n", retval);
if (retval > -1) {							/* Open  
ok. */
	int lockval = lockf(retval,F_TLOCK,0L);	/* Attempt lock on file. */
	perror("lock:");	printf("lockval = %d.\n", lockval);
	if (lockval) printf("lock failed.\n");
	close(retval);
	} else {
	printf("create failed:");
	}
printf("done");
}

main()
{
MyCreate();
}
------ cut here ------

My output is:
create:: Error 0
retval = 3.
lock:: Invalid argument
lockval = -1.
lock failed.

This is aggravating, help is greatly appreatiated.

Bryan Thompson
bryan@ad.cise.nsf.gov
From: jdoenias@next.com (Josh Doenias)
Newsgroups: comp.sys.next.programmer
Subject: Re: NeXT-cc bug report
Date: 15 Apr 92 21:52:54 GMT

> In article <1992Apr7.084848.29747@reswi.en.open.de> 
> ralf@reswi.en.open.de (Ralf E. Stranzenbach) writes:
> the following code fragment did _not_ compile properly:
> 	void some_function (char * s)
> 	{
> 		char * d;
> 		d = strcpy (alloca (strlen (s) + 1), s);
> 		printf ("%s copied as %s\n", s, d);
> 	}

This is indeed a bug, of which NeXT is aware.
It is bug #19987 in our software bug database, and has been fixed for  
the 3.0 release of NeXTSTEP. (Ever wonder why the capitalization  
scheme for NeXTSTEP changes every fifteen minutes?  I Do.)

-- josh.


-- NewsGrazer, a NeXTstep(tm) news reader, posting --
M>UQR=&8P7&%N<VE[7&9O;G1T8FQ<9C!<9FUO9&5R;B!#;W5R:65R.WT*7&UA
M<F=L,3(P"EQM87)G<C$R,`I<<&%R9%QT>#$Q-3)<='@R,S`T7'1X,S0U-EQT
M>#0V,#A<='@U-S8P7'1X-CDQ,EQT>#@P-C1<='@Y,C$V7'1X,3`S-CA<='@Q
M,34R,%QF,%QB,%QI,%QU;#!<9G,R-%QF8S!<8V8P(#X@26X@87)T:6-L92`\
M,3DY,D%P<C<N,#@T.#0X+C(Y-S0W0')E<W=I+F5N+F]P96XN9&4^(%P*/B!R
M86QF0')E<W=I+F5N+F]P96XN9&4@*%)A;&8@12X@4W1R86YZ96YB86-H*2!W
M<FET97,Z7`H^('1H92!F;VQL;W=I;F<@8V]D92!F<F%G;65N="!D:60@7VYO
M=%\@8V]M<&EL92!P<F]P97)L>3I<"CX@"79O:60@<V]M95]F=6YC=&EO;B`H
M8VAA<B`J(',I7`H^(`E<>UP*/B`)"6-H87(@*B!D.UP*/B`)"60@/2!S=')C
M<'D@*&%L;&]C82`H<W1R;&5N("AS*2`K(#$I+"!S*3M<"CX@"0EP<FEN=&8@
M*"(E<R!C;W!I960@87,@)7-<7&XB+"!S+"!D*3M<"CX@"5Q]7`I<"E1H:7,@
M:7,@:6YD965D(&$@8G5G+"!O9B!W:&EC:"!.95A4(&ES(&%W87)E+EP*270@
M:7,@8G5G(",Q.3DX-R!I;B!O=7(@<V]F='=A<F4@8G5G(&1A=&%B87-E+"!A
M;F0@:&%S(&)E96X@9FEX960@9F]R('1H92`S+C`@<F5L96%S92!O9B!.95A4
M4U1%4"X@*$5V97(@=V]N9&5R('=H>2!T:&4@8V%P:71A;&EZ871I;VX@<V-H
M96UE(&9O<B!.95A44U1%4"!C:&%N9V5S(&5V97)Y(&9I9G1E96X@;6EN=71E
;<S\@($D@1&\N*5P*7`HM+2!J;W-H+EP*"GT*
`
Newsgroups: comp.sys.next.programmer
From: schildba@spot.Colorado.EDU (Wolfgang Schildbach)
Subject: violent crashes
Organization: University of Colorado, Boulder
Date: Mon, 13 Apr 1992 23:27:53 GMT

Hi,

every once in a while it happens to me that upon executing my code
the NeXT just kills *ALL* my processes, logs me out and leaves me
with the login screen. My understanding of UNIX is that no matter
how nasty a program, it should never infringe on other processes.

What could cause these nasty crashes?

Ciao W.


Newsgroups: comp.sys.next.programmer
From: Henry Flurry <henry_flurry@imagine.com>
Subject: X DPS extensions on NeXT
Keywords: DPS
Reply-To: Henry Flurry <henry_flurry@imagine.com>
Organization: Imagine Multimedia, Inc., Ann Arbor, MI, USA
Date: Wed, 15 Apr 1992 19:00:06 GMT

Does anyone know if any of the X programs for the NeXT emulate the X DPS  
extensions?  These are extensions which allow you to open Display  
PostScript contexts within X and draw postscript.

It strikes me that it would be fairly simple to do, but perhaps no one  
has done it.

If there is a product out there which has this, then they've got an  
immediate sale.

Thanks!

- Henry Flurry
- Imagine Multimedia, Inc.
- henry_flurry@imagine.com
Newsgroups: comp.sys.next.programmer
From: jscherer@novell.com
Subject: Printed Circuit Board Program..
Reply-To: jscherer@novell.com
Organization: Novell, Inc.
Date: Wed, 8 Apr 1992 17:00:58 GMT


I have found the source code for a PCB program writen for BSD.  Most of  
it compiles, however there is a small linking error (undefinded  
symbols).  This program was designed to be used with an AED-512 graphic  
terminal and a Versatec V-80 electrostatic plotter.  I seems that  
porting this to the NeXT would not be all that hard.  

If some brave person wants this code with hopes of porting it, send me  
email & I will send it to you.  If there is enough response I will post  
it to one of the archive sites.



-------====== jscherer@tsnext.novell.com =====-------
-------======		John Scherer               =====-------
-------======            NeXT Mail OK!             =====-------
Newsgroups: comp.sys.next.programmer
From: scotty@gagetalker.com (Scott Turner)
Subject: Re: Virtual memory devours my disk
Organization: L5 Computing
Date: Thu, 9 Apr 1992 01:30:43 GMT

In article <1992Apr7.201330.10720@leland.Stanford.EDU>  
magnus@Kimura.Stanford.EDU (Magnus Nordborg) writes:
|> I fail to see why this is so awful. If you specify a "hiwat" mark so that
|> the swap file cannot fill the whole partition, you have basically turned
|> the swap file into a swap partition. We use a lot of swap on our system,
|> and on the SPARCs we need to set aside 300MB as a separate partition,
|> whereas on the NeXT, we can at least sometimes use that space...
Because the NeXT doesn't work the swapfile like a "normal" swap partition
when hiwat is set. On my slab programs will start dying when hiwat is hit,
as they should. BUT they start dying long before the swapfile is really
exhausted, ie swapfile hits hiwat but there is STILL ROOM IN THE SWAPFILE!
Worse, if I hit it the wrong way, my slab turns into a boat anchor and must be
recovered via pulling the power cord.

And the box is a real slug after it hits hiwat, if it survives to keep running
that is. You can kill everything, log out, log back in, and the slab is still
in slug mode. It doesn't seem to be very efficent at processing the swapfile
for free pages. Which isn't a surprise since it starts killing processes before
the swapfile is truly exhausted.

The swapfile is the single largest fault I've found with my slab. And as
luck would have it, it is a MAJOR fault in what would otherwise be a really
nice diamond. It is also *THE* reason that I haven't upgraded from my mono
slab. The more I try to live with this fault on my mono machine the more I
can't picture living with it on a ND or a color slab. Hey NeXT, do me,
and my local NeXT dealer, a favor and FIX THIS!!!

I mean I'm using a DOS box to review images processed on my slab because
viewing them on my slab is too damaging to the horsepower of my slab. And if
I had a color slab I would STILL be using the DOS box because of this swapfile
mess. So why buy a color NeXT?

Scotty
From: isbell@cats.ucsc.edu (Art Isbell)
Newsgroups: comp.sys.next.programmer
Subject: Re: Any way to edit inactive NetInfo and default data base files?
Summary: Try a simple C program using NXSetDefaultsUser.
Keywords: defaults
Date: 13 Apr 92 16:54:49 GMT
Organization: Cubic Solutions - NeXT software development and consulting


In article <1992Apr8.173016.25134@cubetech.com> andrew@cubetech.com writes:
>In article <rlbvqINNmqf@agate.berkeley.edu> izumi@pinoko.berkeley.edu (Izumi  
>Ohzawa) writes:
>
>>  Also, is there a way to edit default database without logging in as
>>  the owner of that account?
>
>You could always rename your default database and symbolically link the other  
>guy's database to your .NeXT directory...  Then dwrite away...
>
Another possible solution is suggested by the documentation for
NXSetDefaultsUser().  I've never tried this, but a simple Objective-C program
should do the job if you have read and write permissions to the user's defaults
database.

-- 

Art Isbell                                                      Cubic Solutions
NeXT Registered Developer              NeXT software development and consulting
Email: isbell@cats.UCSC.EDU                                Voice: (408)335-1154
USmail: 95018-9442                                           Fax: (408)335-2515
Newsgroups: comp.sys.next.programmer
From: ckminer@LANCE.ColoState.Edu (Chris Miner)
Subject: User Path
Date: Sat, 11 Apr 1992 09:13:59 GMT
Distribution: na
Organization: Colorado State U. Engineering College
Keywords: DPSDoUserPath


I've this code for a drawSelf:: implementation-

- drawSelf:(const NXRect *)rects :(int)rectCount
{
	float coords[8] = {50.0, 50.0, 100.0, 0.0, 0.0, 100.0, -100.0, 0.0};
	char ops[5] = {dps_moveto, dps_rlineto, 
				dps_rlineto, dps_rlineto,
				dps_closepath};
	short bbox[4] = {0, 0, 200, 200};

	PSsetgray(0.0);
	NXRectFill(rects);
	PSsetgray(1.0);
	DPSDoUserPath(coords, 8, dps_float, ops, 5, bbox, dps_ustroke);
	return self;
}

The problem is it only works for short coords and dps_short instead of
float coords and dps_float.  I noticed the Draw, Graph and Lines
examples use floats.  Any answers on this?

	Chris 
	ckminer@longs.lance.colostate.edu

Newsgroups: comp.sys.next.programmer
From: spiff@jimi.cs.unlv.edu(Wendy Cook)
Subject: Adobe Purple Book Examples
Organization: UNLV
Date: Fri, 10 Apr 92 04:37:32 GMT


Hey.

Does anyone know where the Adobe Purple book examples
are ARCHIVED??  I have ftp capability.

Thanks in advance.  Email ok.

(M - is this the same M Carling 13/26 children from EXPO?  If so,
drop in to my Mail and say Hey. to me...)

-Wendy

--
**************************************************************************
Life's Little Destruction Book:
Rule 74: Don't leave a message at the beep.
Rule 265: Kvetch.
**************************************************************************
Wendy Cook
spiff@jimi.cs.unlv.edu
wkcook@athena.mit.edu
**************************************************************************
From: drew@fnbc.com (Drew Davidson)
Newsgroups: comp.sys.next.programmer
Subject: Re: Pipes, Child Processes and Other Uglies
Date: 8 Apr 92 15:16:18 GMT
Reply-To: drew@fnbc.com
Organization: First National Bank Of Chicago, Chicago IL, USA

In article <1992Apr7.170318.19742@noose.ecn.purdue.edu>  
songer@ei.ecn.purdue.edu (Christopher M Songer) writes:
> Hi!
>      It's possible this belongs on one of the UNIX groups, but it
> touches on some NeXT stuff so I thought I'd try here first. I'm in
> the midst of doing an App that uses Allegro for some NLP stuff. I'm
> spawning a cl process and making its stdin one end of a pipe, and its
> stdout another end of a pipe like this:
> 
> if((pid = fork()) == 0) {
> 	fclose(stdin);
> 	dup(cl_stdin);
> 	fclose(stdout);
> 	dup(cl_stdout);
> 	execl(...);
> 	}
> 
>      Here's my problem. Common Lisp can respond to commands in its
> own sweet time. I don't want to sit around polling on the file
> descriptor all the time. This would hose the user interface. What
> I want to happen is this:
> 
>      When the OS detects something to be read on the descriptor it
> wakes up a thread (or whatever) and the thread takes care of all my I/O.
> I think maybe the SIGIO signal sort of does this -- but it seems awefully
> crufty to me. (Not thread based at all, and who wants to poll ALL the
> possible descriptors.)
> 
>      One thing I've considered is using a thread with a realtively
> low priority to watch the file descriptor and buffer what comes through.
> Once we have a complete response from Lisp, send a message (or put an
> event in the Event Queue???) to process it. But I'm not sure that it
> is safe to use an objc messge from a thread and I'm not sure how to
> put an event in the event queue. I don't really want to have to subclass
> Application if I can help it.
> 
>      Anyway, suggestions on how to handle this are more then apprecaited.
> Thanks!
> -Chris
> songer@ecn.purdue.edu
> chris%broadsword.UUCP@ecn.purdue.edu

A very good solution to this problem is contained in  
/NextDevelopers/Examples/Subprocess.  It does exactly what you want and uses  
DPSAddFD() to tie into the stdin/stdout of the subprocess.  I have modified  
this further to separate the stdout from stderr (the Subprocess object blends  
them together), allow pausing and resuming the process and some other neat-o's.

--
+--------------------------------+------------------------------------------+
|        Drew  Davidson          | "Whining is anger coming through a small |
|         Software Guy           |  opening."                               |
| First National Bank of Chicago |            - Stuart Smalley              |
|     drew@fnbc.com  (NeXTmail)  |              Caring Nurturer             |
+--------------------------------+------------------------------------------+
From: daj@ccrma.stanford.edu
Newsgroups: comp.sys.next.programmer
Subject: Music Kit teaching materials available
Date: 6 Apr 92 03:57:04 GMT
Article-I.D.: Princeto.1992Apr6.035704.21773
Organization: Princeton University
Originator: news@ernie.Princeton.EDU

For the last few years, I've been teaching a class on programming with the  
Music Kit at Stanford and Princeton.  I am making my teaching materials  
available to anyone who wants them by anonymous ftp.  Log in to  
ccrma-ftp.stanford.edu and look on the directory /dist/ftp/pub. The file   
music-kit-class.tar.Z contains a concise summary of what you need to know to  
write Music Kit applications.  A knowledge of C (but not Objective C) is  
assumed.   It also contains a number of programming examples and exercises.  
Feel free to grab it.

By the way, the latest issue of NeXTWorld Extra has a report on the details of  
the change in status of the Music Kit. Although it is not an official  
announcement and thus its accuracy is not assured, of particular interest are  
the following claims:

* Stanford's Center for Computer Research in Music and Acoustics (CCRMA) will  
be supporting the Music Kit (bug fixes, new features, ports, etc.) 
* NeXT will support this venture via CCRMA's Industrial Affiliates program.
* The Music Kit, DSP libraries and related software and documentation will be  
available as source code!
-----------
David Jaffe
From: ajamison@talus.ogi.edu
Newsgroups: comp.sys.next.programmer
Subject: Re: Problems with Workspace's -getFileIconFor: TIFF:TIFFLength:ok:.
Date: 7 Apr 92 15:52:02 GMT
Article-I.D.: talus.1992Apr7.155202.18548
Organization: Talus Corporation

In article <3502@rosie.NeXT.COM> aozer@next.com (Ali Ozer) writes:
> done that, the problem goes away. Your bug sounds like that problem, and if
> they're the same, then, yes, it's a NXImage bug, and it's fixed in 3.0. 

Yeah, right.  Will they fix the lockFocus as well, or maybe the Bitmap  
rendering, or maybe the screen rendering, or maybe the fact that the NXImage  
object is too slow to render most images.

I had to re-write the NXImage object because NeXT didn't do it right the first  
time, the damn thing is too slow rendering and god forbid you actually want to  
make a bitmap of anything at any size.  It's great if you want to render an  
image that is only, say, 512k x 360k.  Now, let me ask you this, have you tried  
rendering, let alone locking focus on, a 2k x 2k image that has 700 dpi worth  
of data?  Takes a bit of time eh?

I hope NeXT has changed the NXImage class drastically, otherwise we, as a  
platform, are doomed for any type of high-end imaging.

Also, something else to think about, I've seen a person who was working on an  
image rendering project on a color station with 16MB RAM, and I've seen the  
computer crash because the damn thing rendered so many reps, it wasn't funny.

I seriously hope that these problems have been fixed, re-writing the NXImage  
object wasn't fun...

J. Alexander Jamison, disgruntled programmer
Sr. Systems Engineer
Talus Imaging and Communications Corp.