HDTenEightyP/NetNews huggingface dataset:
From: susan@widget.esd.sgi.com (Susan Dahlberg)
Subject: Re: Borderless GL window
Organization: Silicon Graphics Inc.
Date: Mon, 12 Oct 92 22:10:04 GMT

In article <1bckj5INN54u@network.ucsd.edu>, surles@boris.sdsc.edu (Mark Surles) writes:
> I cannot create a borderless window under IRIX 4.0.X.  Could someone look
> at the following code and tell me what I'm doing wrong?  It worked under 
> the previous operating system.  I compiled this with:
> 
>                 cc -o foo foo.c -lgl_s
> 
> Thanks,
> 
> Mark Surles
> surles@sdsc.edu
> 
> /*****************************************************************************/
> #include <stdio.h>
> #include <gl.h>
> #include <unistd.h>
> 
> main()
> {
>   noborder();
>   winopen(NULL);
>   winconstraints();
>   sleep(10);
> }


You found an old bug that got fixed in IRIX 4.0.X.

From the winopen man page:
     winopen sets the graphics state of the new window (this includes window
     constraints) to its default values;
So when you call winconstraints, you are setting to the defaults.
Either remove the winconstraints or put in a noborder call 
after the winopen.

     Susan                        opinions are mine
From: kestas@lith.UUCP (Kestutis Sliupas)
Subject: X on DECNET?
Newsgroups: comp.sys.sgi
Date: 16 Oct 92 23:23:09 GMT
Distribution: world
Organization: Vacaville, CA

Hi:
	At work, we have several Iris Crimsons hooked into the
corporate DECNET with 4DDN. Is it possible to open a X window and
run a application on the corporate VAX in the window? The 4DDN docs
seem to say no...
	It would be great to run MDL MACCS in a window. The program
does support the Digital X-windows product. The problem seems to be
communicating via 4DDN.
	Any advice would be greatly appreciated.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 Kestutis Sliupas             x    ( Witty bon-mot goes here )
 uucp!..!infopro!lith!kestas  x  (510) 231-1540 (work) USA CA PST 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
From: derek@iris40.houst.sgi.com (Derek Spears)
Newsgroups: comp.sys.sgi
Subject: Re: GL function MAPW
Date: 12 Oct 92 23:46:02 GMT
Reply-To: derek@iris40.houst.sgi.com (Derek Spears)
Organization: sgi


	Gl guru -- NOT! However, there is a simple example of mapw
	in /usr/people/4Dgifts/examples/grafix/mapw.c
	Basically, the view object is a display list object created
	with makeobj that contains your viewing transforms. mapw needs
	this in order to transform screen coord into world coords.

_____________________________________________________________________________

	Derek Spears			Thats it. No cute pictures.
	Applications Support		No fiery political statements.
	Silicon Graphics Inc.		Nothing about water skiing.

	derek@sgi.com			Oh wait.....
	(713) 293-9292			"Water Ski till ya drop!"
Newsgroups: comp.sys.sgi
From: kotzo@casbah.acns.nwu.edu (Nick Kotzamanis)
Subject: Running X Programs
Keywords: X
Organization: Northwestern University, Evanston, Illinois, USA
Date: Wed, 14 Oct 1992 19:47:58 GMT

Hi Netters,

	I'm having a problem running X programs (is's a CAD program) over
the net and setting the display to my SGI (4d/35 PI).  I have set up the
display variable correctly and did an xhost +.  I know that I'm doing this
correctly because when I do it on an RS/6000 it seems to work fine.

	I'm running OS 4.0.5 and hinv says that I have this graphics
hardware:

Graphics board:  GR1.2 Bit-Plane, Z-buffer options installed

	The error that I'm getting from the remote machine is:

could not allocate enough colors only 4 available.

	As far as I know the SGI's have more that 4 colors?  Is there a way
that I can increase the number of colors for "X" programs to use?  Just how
"X" compatible are the SGI's?

	Thanks in advanced.
From: HERBER@fnal.fnal.gov (Randolph J. Herber, CD/DCD/USS, x2966)
Newsgroups: comp.sys.sgi
Subject: Not lost space in /debug -- read `man dbg' or `man debug'
Date: 11 Oct 92 16:26:27 GMT

+Date: Fri, 9 Oct 92 21:39:31 -0400
+From: Arka Mukherjee <arka@spiro.princeton.edu>

+Dave,

+I'm having a problem that I just can't figure out.

+In my /debug directory, I have a bunch of files that are taking   
+up quite a bit of space.

+spiro 2# du /debug
+62452   /debug

+...............................

+What's going on here? 

+Arka

This is a FAQ (Frequently Asked Question).  The simple answer is read
the manual pages `man dbg' (also found as `man debug').  The complex
answer is that /debug is a pseudo-filesystem representing the processes
in the system (the filenames are the PIDs of the processes) and the
system swap space.  These "files" go away if you are not running the
system.  Their primary purpose is use by debuggers.

Randolph J. Herber, herber@fnalf.fnal.gov, +1 708 840 2966
(Speaking for myself and not for US, US DOE, FNAL nor URA.)
(Product, trade, or service marks herein belong to their respective owners.)
From: lgt1@ohm.york.ac.uk (Laurence Tyler (Guest - CompServ))
Newsgroups: comp.sys.sgi
Subject: Re: Fortran and Irix V4.0.5 bug
Date: 15 Oct 92 13:25:28 GMT
Organization: Electronics Department, University of York, UK

In <1992Oct14.102132.27972@c1.nkw.ac.uk> k_ejm@c1.nkw.ac.uk (Ed Marchewicz) writes:

>There appears to be a problem with the Fortran shareable i/o library
>(libI77_s) in version 4.0.5 and 4.0.5F of Irix.

[example code deleted]

>Execution of knack produces core dump if run under Irix V4.0.5 but
>works correctly under Irix V4.0.4 and 4.0.4.
>if -lI77 is used instead, file fred is correctly produced.

>Has anyone else come across this problem and more importantly, does
>a patch exist ?
>Replies by Email please and I'll summarise.

I had a similar problem upgrading from 3.3.x to 4.0.5 - the fortran
upgrade got a bit messy, and somewhere along the line the libI77_s
file from the ftn 3.4.1 kit I installed replaced the version that
came with the operating system *even though the os version was
the correct one*. I can only conclude that either I did something in
the wrong order (though I don't think that was the case) or the
installation info had a bug in it.

In any case, I saw the same problem, and rather that try
re-installing the eoe kit (which wouldn't necessarily work anyway),
I opted for simply copying the file from another machine with the
same fortran and Irix releases, that did work. All you need to do is
locate a copy of the correct libI77_s file for 4.0.5 and copy it to
/usr/lib with the appropriate permissions.

This is a rather dodgy solution (though it works), and you should be
alert next time you upgrade either fortran or Irix to see that the
problem doesn't recur.



-- 
Laurence Tyler (Systems Group)
University of York Computing Service, UK
email: lgt1@york.ac.uk
From: james@sam.contex.com (James McQueston)
Newsgroups: comp.sys.sgi
Subject: Re: file size limit (2^31?)
Date: 9 Oct 92 16:23:05 GMT
Organization: Xyvision Design Systems

In article <1992Oct9.112912.25349@cc.ic.ac.uk> cmaae47@cc.ic.ac.uk writes:
> ...
>It really is as easy as I said, make the 'long' type in C a 64 bit quantity
>and recompile. 'Long long' does not help, nor does it help to make off_t 
>an aggregate type, unless the C compiler overloads arithmetic operators for 
>it transparently. Only badly written software will fail (unfortunately 
>there is a lot of it).
>
>                                        Thomas 
> ...
>*   email: cmaae47 @ cc.ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic.cc on Janet)

Thomas is correct.  SGI, please heed his point that "long long" is no help.

Those that have suffered through with SGI's early machines and compilers
will remember the C doubles that were IEEE single precision (technically
legal at the time), but the real horror was that double precision was
available but called "long double."

_Please_ (he begs while on his knees in a supplicating position) don't
introduce "long long" except as a 128 bit quantity.


-- 
-----
James H. McQueston		james@contex.com
Xyvision Color Systems, Inc.	(617) 246-1776 x 5523 (office, voicemail)
Wakefield MA 01880-1291		(617) 245-4471        (lab phone direct)
From: fredv@abba.acs.uci.edu (Fred Velijanian)
Subject: serial lines on 4D/35
Newsgroups: comp.sys.sgi
Organization: University of California, Irvine
Date: 9 Oct 92 20:51:36 GMT

We're trying to connect an ASCII terminal to a 4D/35. We're using
the ttyd4 port which has a mac type connector. We're using a 
mac cable with RS232 on one end, and it doesn't work. We only get
a "login" prompt, but there is no response to keyboard key presses.
The /etc/inittab file looks ok (the graphics system manager updated
it) and getty is running.

Any ideas?

Thanks

Fred Velijanian
University of California, Irvine
fredv@uci.edu
Organization: Penn State University
Date: Thu, 15 Oct 1992 16:08:31 EDT
From: <SML108@psuvm.psu.edu>
Newsgroups: comp.sys.sgi
Subject: Environmental variable problems

Hi, frequently when I am logged onto the console, our IRIS 4D/220 seems to
forget its terminal emulation for curses.  Despite the fact that under
both printenv and set TERM and term are set to iris-ansi, vi does not
work right: it looks right, but screws up as soon as one hits one of
the cursor keys.  This is fixed by typing set term=iris-ansi followed
by tput init.  Does anyone know what's going on here?

Scott
Newsgroups: comp.sys.sgi
From: pphilp@vizbiz.com
Subject: Inventor render caching and editable transformations
Organization: Visible Decisions Inc
Date: Tue, 13 Oct 1992 17:25:38 GMT


I am having some problems getting render 
The simplest way to describe our performance problem is to think of our
application as a set of polygons.  One of the key attributes
of these polygons is the height, which is time variant.  My implementation
is to create a singe Separator node for a polygon (coordinates and a FaceSet).
I instantiate this node 1000 times for each of the polygons.  The structure
is:

Separator (FaceSetNode)
   SoCoordinate3
   FaceSet

Separator (GLRenderCaching OFF here).
   Transform
   Separator (GLRenderCaching ON here).
      FaceSetNode

I implement changing the height by editing the scaleFactor in the Transform.

With caching off I can put this data into an ExaminerViewer and spin it a 1 fps.

With caching on I can spin at 3 fps.

With caching off I can edit the heights at 0.9 fps.

With caching on I can edit the heights at 0.5 fps.

This is the problem - I need to achieve a frame rate for editing the heights
which is quite close to the frame rate I achieve for spinning the polygons.  It
seems when we edit the transform the cache is being thrown away.  

This is the key performance issue for this project.  Any help or suggestions you have
will be appreciated.

Thanks,
Paul



Paul Philp
Visible Decisions      65 Front St. West,         
Suite 110-140                                     _____
Toronto, Ontario,      CANADA  M5J 1E6           |     | 
pphilp@vizbiz.com                                |  *  |          
vox: (416) 864-4342    fax: (416) 864-3918       |_____|
From: fine@sofine.detroit.sgi.com (Steve Fine)
Newsgroups: comp.sys.sgi
Subject: Golf Simulator
Date: 16 Oct 92 14:57:06 GMT
Organization: Silicon Graphics, Inc.

I have a request for a golf simulator.

Has anyone out there in net land seen one for SGI??

Thanks

-- 

----------------------------------------------------
Steve Fine                              fine@sgi.com
Systems Engineer, Great Lakes District (Detroit, MI)
These opinions are mine blah blah blah.........
----------------------------------------------------
From: k_ejm@c1.nkw.ac.uk (Ed Marchewicz)
Newsgroups: comp.sys.sgi
Subject: Fortran and Irix V4.0.5 bug
Date: 14 Oct 92 10:21:32 GMT
Organization: Natural Environment Research Council
Originator: k_ejm@kwsa

There appears to be a problem with the Fortran shareable i/o library
(libI77_s) in version 4.0.5 and 4.0.5F of Irix.

The following simple program may be used to demonstrate the problem :-

        program knack
        open(unit=1,file='fred',status='new')
        write(1,*)'Library is OK'
        end

To compile and link use:

	f77 -o knack knack.f -lI77_s

Execution of knack produces core dump if run under Irix V4.0.5 but
works correctly under Irix V4.0.4 and 4.0.4.
if -lI77 is used instead, file fred is correctly produced.

Has anyone else come across this problem and more importantly, does
a patch exist ?
Replies by Email please and I'll summarise.
Newsgroups: comp.sys.sgi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Information/Referrence on MIPS assembler wanted
Keywords: Indigo, Programming, Assembler, MIPS, Processor, R3000, R4000
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 15 Oct 1992 15:03:56 GMT

In article <3047@contex.contex.com>, frank@marvin.contex.com (Frank Perdicaro) writes:
> >...
> RISC assembly coding is hard to do well compared to, say, VAX assembly
> coding.  Much can be learned from looking at compiler output.  
> Good luck.


Looking at compiler output is good for learning good and bad ideas on
any system.  In IRIX, the `dis` command is very useful, because it
lets you see what is really generated, not just what the compiler
told the assembler.


However, most experienced assembly language writers appear to find
writing good RISC assembly code easier than writing good CISC assembly
code for exactly the same reasons that compiler writers find it easier
to write compilers that emit good RISC binaries than to write compilers
that emit good CISC binaries.

I think there are in general only two complexities with RISC code, any
"exposures of the pipeline" and the large number of registers.

Good CISC code requires the you to know a more complicated set of
addressing modes and opcodes.  You do have fewer registers to track,
which some might consider a conceptual advantage.  Good coders decades
ago worried about cycle counts in just the same way they now worry
about RISC pipeline stalls, cache stalls, delay slots, and so on -- at
least I did and do.

There are far fewer people who use assembly language today than in
decades past.  Those who do use significant amounts of assembly
language write far less of it.  Perhaps that is the germ behind the
notion that things are harder today.  Another possibility is that
today's assemblers, at least in the UNIX world, are very primitive and
hard to use compared to the good old days of the mid-1970's.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.sys.sgi
From: wlin@magnus.acs.ohio-state.edu (Weihung Lin)
Subject: X/MOTIF Problem on IRIS Indigo
Followup-To: whl@gauss.eng.ohio-state.edu
Summary: How to set Motif topLevelShellWidget to desired position
Keywords:  Motif, ShellWidget
Organization: The Ohio State University
Distribution: usa
Date: Thu, 15 Oct 1992 19:05:07 GMT


     I had some problem to set the topLevelShellWidgetClass to the desired
position. I tried "XtSetArg" function to set "XmNx" and "XmNy", it did not
work. Later I tried to set "ClientAutoPlace" to False. It did not work either.
If someone has this kind programming experience before, please give me some
suggestion. 

Thanks for your help!

Weihung Lin
From: haider@netcom.com (Jamal Haider)
Newsgroups: comp.sys.sgi
Subject: NEC VR4000 RISC CPU
Date: 16 Oct 92 02:19:07 GMT
Distribution: na
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

Newsgroups: all
Subject: NEC Vr-4000 RISC seminar
Summary: 
Followup-To: 
Distribution: 
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Keywords:RISC 


Let NEC give you the facts about RISC processors.  Join us at
the "Vr4000: The Processor for today, tomorrow and beyond" seminar.
Learn why the Vr4000 is and will continue to be the performance 
and price leader through the 90's.

    NEC Electronics will provide you with the opportunity to learn 
why the MIPS R4000 architecture is not only the architecture of choice
for today, but is also the cornerstone for future advances 
in microprocessor development.  Today, NEC's Vr4000 integrates 
a high performance 64 bit CPU with a primary cache and a floating
point unit all on one single die.  Versions of the Vr4000 with 
secondary cache interface and multiprocessor support are also 
available.  At our free seminar we'll take you through future 
migration paths, discuss packaging trends, pricing and performance,
and provide you with a detailed technical analysis.
4000 RISC-based systems offer a much higher level of 
graphical and computational performance compared to X86 systems. 

    If you design CISC or RISC systems, you can't afford to miss 
this seminar.  Join us at one of the following locations and learn 
why the Vr4000 should be your processor of choice for leading 
edge workstations, powerful PC's, multiprocessor and embedded 
control systems.

Locations:       October 20,1992 LeBaron Hotel San Jose California
                 October 22,1992 Burlington Marriott, Boston, Massachusetts
                 November 4, 1992 Red Lion, Costa Mesa, California

Signup:         Please call (415)695-6159 or fax 1(800)729-9288
 
Agenda:
9:00 - 9:15 NEC Company Profile
9:15 - 9:30 MIPS, An Open Architecture
9:30 - 10:00 NEC RISC Products
10:00 - 10:15 MIPS Architecture Review

10:15 - 10:30 Break

10:30 - 11:00 VR4000, The processor of choice for multiple platforms
11:00 - 11:30 VR4000 RISC Architecture
11:30 - 12:00 VR4000 Implementation

12:00 - 1:00 Complimentary Lunch

1:00 - 2:00 VR4000 Implementation
2:00 - 2:30 VR4000 Performance / Competitive Analysis

2:30 - 2:45 Break

2:45 - 3:00 Mips Development Tools
3:00 - 3:45 Third Party Development Tools
3:45 - 4:00 Future of MIPS Architecture
4:00 - 5:00 System Demonstrations

See you at this seminar!!!!!!!!
From: petit@CAM.ORG (Francois Petitclerc)
Newsgroups: comp.sys.sgi
Subject: Freedom of Press on 4D/120S
Summary: Does Freedom of Press run on a 4D/120S?
Keywords: R2000
Date: 16 Oct 92 19:29:11 GMT
Organization: Communications Accessibles Montreal, Quebec Canada

We are in the process of buying an old Iris 4D/120S with an afterburner option.
The machine runs on the old R2000 chip.  The main use of this machine will be
to run rendering software, primarly Freedom of Press.

Does anyone know if Freedom of Press will run on this machine?

Francois Petitclerc
SYGRAF    
e-mail: petit@cam.org

-- 
Francois Petitclerc                |     "There are no ordinary moments."
                                   |     - Dan Millman,
petit@cam.org                      |     Way of the Peaceful Warrior
From: steve@snoopy.tamu.edu (Steve Rikli)
Newsgroups: comp.sys.sgi
Subject: serial port communications
Date: 13 Oct 92 15:55:35 GMT
Article-I.D.: tamsun.1992Oct13.155535.24669
Distribution: na
Organization: College of Architecture, Texas A&M University

Background:  4d/240, IRIX4.0.1 .

We're trying to read data from a serial port, ttyf4, and the read
function continuously returns 0 as the number of bytes read.  To quote
from the man page for 'read':

	When attempting to read a file associated with a tty that has no data
	currently available:

		If O_NDELAY is set, the read will return a 0.

		If O_NONBLOCK is set, the read will return a -1 and set errno to
		EAGAIN.

		If O_NDELAY and O_NONBLOCK are clear, the read will block until
		data becomes available.

We aren't setting O_NDELAY or O_NONBLOCK, and what we want is for read to 
"block until data becomes available", but this isn't happening.

Just for completeness, there's no getty process running on port 4, the entry
in /etc/inittab looks like:

	t4:23:off:/etc/getty -N ttyd4 co_9600	# port 4

Is there something we need to do to the port?  Other?  Have I provided 
enough information to be of any help?

Any assistence would be appreciated.

cheers,
sr.
--
|| Steve Rikli 	           |||  Visualization Lab               ||
|| steve@archone.tamu.edu  |||  Texas A&M University            ||
|| (409) 845-3465          |||  College Station, TX  77843-3137 ||
Newsgroups: comp.sys.sgi
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: bug in SCSI tape driver or tps man page ?
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 7 Oct 92 05:04:11 GMT

In <3022@contex.contex.com> jeff@hobbes.contex.com (Jeff Carey) writes:
| In article <qnjuo2c@sgi.sgi.com> jeremy@classic.asd.sgi.com (Jeremy Higdon) writes:
| >In article <3007@contex.contex.com>, jeff@hobbes.contex.com (Jeff Carey) writes:
| >>...
| >> Logically, it seems I would end up between the last two ending filemarks.
| >> But, in practice it seems I am after the last of both filemarks.
| >
| >I would have said between the last two filemarks.  How do you determine
| >that it is after the last two filemarks?  I refer you to the man page:
| >
| >     1.  If the first read after an open or following a BSF encounters a
| >...
| 
| I am determining it to be after both ending filemarks by doing a read which
| returns a -1, "No space left on device."  The read immediately follows the
| FSF sequence (no impinging close, open, or BSF), which is not included in
| the cases above that would cause it to skip the filemark.

As Jeremy said, the bug about not remembering that we are at a FM
could cause this.  The FM would be skipped, the read retried, and
would of course fail and return -1 (and mt stat would report that
you are at EOD).

| So far I tally the following problems:
| 1. "man tps" "TAPE MOVEMENT CRITERIA" note 4. inconsistency.
| 2. your above-mentioned tape driver bug which makes it act inconsistently
| 	with "man tps" "TAPE MOVEMENT CRITERIA" note 1.
| 3. my above-mentioned "what-I-believe-to-be-a-bug" bug concerning the FSF
| 	to the end of a tape.

I think they are basicly all the same bug (or the same set of underlying
causes, if you prefer).
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: suneel@mips.com (Suneel Jain)
Newsgroups: comp.sys.sgi
Subject: Re: mysterious as1 warning during f77 compile
Date: 9 Oct 1992 23:17:51 GMT
Organization: Silicon Graphics Computer Systems
NNTP-Posting-Host: limca.mti.sgi.com

In article <1992Oct9.204546.28477@daffy.cs.wisc.edu> brianp@ssec.wisc.edu (Brian Paul) writes:
>
>Does anyone know what might cause the following message during a f77 compile:
>
>as1: Warning: , line 0: Floating exception in conversion to binary
>
>the compilation is successful and the executable runs fine but I'd like
>eliminate this warning.  BTW, this happens on a Crimson VGX running 4.0.5
>but does not happen on a 340VGX running 4.0.1.
>
>Thanks,
>-Brian


You have a floating point literal in your source that is either too big
or too small. When the assembler tries to convert it from the ascii 
string to a binary floating point number, it gets an error. The 
warning is reporting this fact.

-- 
Suneel Jain 

EMAIL :	suneel@mti.sgi.com 		
PHONE : 1-415-390-4281
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: reading a remote tape device on a... sun.
Date: 7 Oct 92 04:34:31 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <32922@adm.brl.mil> wim@fss.fokker.nl (Wim Elhorst) writes:
| I have an installation tape cartridge in SGI format. My SGI Crimson on
| which I want to install this software has no tape drive. The only tape
| drive capable of reading the tape is connected to a sun in our network.
| 
| Now, how do I specify locally on the crimson the (no rewind) remote tape
| device ?

The syntax you show is correct, but as you note, because of
the byte swapping, you won't be able to get it to work.  You could
get the public domain rmt package from ftp.uu.net, and hack it so
that the data all passes through swab() before going over the wire,
but that is about the best I can offer.

--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.sys.sgi