HDTenEightyP/NetNews huggingface dataset:
From: dillon@overload.Berkeley.CA.US (Matthew Dillon)
Newsgroups: comp.sys.next.misc
Subject: Re:   Recovering ROM monitor password
Distribution: world
Date: 12 Oct 92 11:19:55 PST
Organization: Not an Organization

>In article <1992Oct12.031200.15821@cube.handheld.com> jmd@cube.handheld.com (Jim De Arras) writes:
>>In article <dillon.0p24@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US

>>     current == no heat.  For example, diodes are often used in battery
>>     charging circuits like this:
>>
>>	+12V from supply ----*DIODE*----x----> system power
>>					|
>>	+!2V from battery --------------/
>>
>>     When AC is available it charges the battery.  When AC is not available
>>..

>Where did you get this dangerous mis-information!!  Do not EVER, repeat, EVER
>attempt to charge a standard lithium cell.  You are looking at a nasty mess at
>BEST, if the seals blow, and a VERY REAL, blow a hole in the board and you,
>explosion if the seals fail to blow.  Lithium cells do not take a joke!

    Silly person, you didn't read the article very closely.  The above was
    an EXAMPLE of what is one of the most common charging configurations
    for batteries... a regulator and a diode.  It has nothing to do with
    lithium cells (the above circuit is actually used to charge lead-acid
    gel cells).  To charge a lithium cell, and you *can* do it, you have to
    be much more careful.

    The above example was simply illustrative of one of many uses DIODES
    are put to, in response to an earlier comment by someone who was
    worried that reverse biasing a diode would destroy it eventually, which
    is nonsense.

>>     I presume that NeXT is using a similar circuit to power the real time
>>     clock and prevent the battery from trying to power the system +5.
>>
>Let's hope not!

    Believe it or not people use trickle charge circuits all the time to
    extend the life of lithium batteries in backup situations.	This is
    usually necessary only when the battery would discharge due to current
    requirements long before it's normal shelf life expires.  With a proper
    charging circuit you can extend the lithium batteries backup
    capabilities all the way to its shelf life limit (5yr or 10yr usu).  In
    applications where the shelf life would expire before the nominal mAH
    of the battery is used up such a circuit is not required.

>(Will this topic ever end?  :-) )  I cannot let dangerous misinformation remain
>as the final word, though.  When it comes to putting batteries in ANYTHING
>backwards, "Just say no!"
>
>Jim

				    -Matt
--

    Matthew Dillon		dillon@Overload.Berkeley.CA.US
    1005 Apollo Way		uunet.uu.net!overload!dillon
    Incline Village, NV. 89451	ham: KC6LVW (no mail drop)
    USA 			Sandel-Avery Engineering (702)831-8000
From: basiji@stein.u.washington.edu (David Basiji)
Newsgroups: comp.sys.next.misc
Subject: floppy patch needed!
Date: 15 Oct 92 19:01:04 GMT
Article-I.D.: u.1992Oct15.190104.5388
Organization: University of Washington


Where can I find the patch to allow the reliable ejection of floppies?
I searched both sonata and cs.orst but couldn't find it.  Is it readily
available?

Thanks,
David Basiji
basiji@u.washington.edu
From: al@expovision (Andre_Lalonde)
Newsgroups: comp.sys.next.misc
Subject: NewsGrazer Latest Version
Keywords: NewsGrazer
Date: 6 Oct 92 05:27:32 GMT
Reply-To: al%expovision@CAM.ORG
Organization: Edition Electronique Expovision inc.

I have Release 2.0 of NewsGrazer (version 72.2).
Can someone tell me if this is the latest (and best ) version compatible  
with NeXTStep 3.0?
- Andre
al%expovision@CAM.ORG
Newsgroups: comp.sys.next.misc
From: ede978e@monu6.cc.monash.edu.au (Robert D. Nicholson)
Subject: Re: Recovering ROM monitor password
Organization: Monash University, Caulfield Campus
Date: Sun, 11 Oct 1992 11:16:21 GMT

dillon@overload.Berkeley.CA.US (Matthew Dillon) writes:

>>In article <1992Oct8.025357.9551@cube.handheld.com> jmd@cube.handheld.com (Jim De Arras) writes:
>>>In article <1ask66INN2ga@ustores.ustores.missouri.edu>
>>
>>I would NEVER put the battery in backwards!  If they have a protection diode,
>>it will do nothing.  If not, you run the risk of damaging the clock chip, or of
>>exploding caps or even (remotely) blowing the battery seals!

>    If the battery is connected directly to the RTC chip then you are
>    definitely forward biasing the static discharge diodes internal to the
>    device, about 50 ohms per pin (in parallel) if you reverse the battery.
>    This would destroy the RTC chip rather quickly.

>    if there is a protection diode across the batterly leads (and not
>    inline) to protect the RTC chip, the battery will be shorted and can,
>    literally, explode.

>    On the otherhand, if NeXT has inserted a diode in series with the
>    battery, then nothing will happen at all because the diode will be
>    reverse biased.

>    I don't know what RTC chip the NeXT is using.  Most RTC chips, like the
>    ones from Dallas Semiconductor, draw picoamps (on the order of 300pA or
>    less).  Therefore, the bypass capacitors alone would be able to retain
>    enough voltage to run the RTC for several minutes.	The best solution
>    is to take out the battery and short the battery terminals on the
>    motherboard together for a second or two to discharge the bypass
>    capacitors.

>    NOTE:  I HAVE NOT TRIED THIS MYSELF but it's certainly safer then
>    putting the battery in backwards!

>					-Matt

>>> --
>>> Bill Canning 		usbill@ustores.ustores.missouri.edu (Internet)
>>> (314) 882-2131			muccgw.usbill@ssgate.missouri.edu
>>(cc:Mail)
>>> [314] 882=4699 (Fax) 	CSPECWC@MIZZOU1 (BITNET)
>>
>>Jim
>>
>>--
>>Jim De Arras		 | The opinions expressed herein are
>>Hand Held Products, Inc.| not necessarily those of Hand
>>804.784.3090 voice	 | Held Products, Inc., and may not
>>804.784.3147 FAX	 | even be mine. Use at your own risk

>--

>    Matthew Dillon		dillon@Overload.Berkeley.CA.US
>    1005 Apollo Way		uunet.uu.net!overload!dillon
>    Incline Village, NV. 89451	ham: KC6LVW (no mail drop)
>    USA 			Sandel-Avery Engineering (702)831-8000

The best suggestion is to use HardwarePassword.app by eps and not
stuff around with batteries and the like.

Newsgroups: comp.sys.next.misc
From: jim@ljkiraly.lerc.nasa.gov (L J "Jim" Kiraly)
Subject: Re: Fax and 3.0--More Trouble!
Organization: NASA/LeRC
Date: Thu, 8 Oct 1992 20:15:48 GMT

I am running 3.0 with a Dove FAX, and the "date" field on any cover sheet is  
being filled with formatting codes instead the the date.  Has anyone else  
esperienced this?  Anybody have a fix?  (I have added a dateless cover sheet  
which works fine- but would like to get the mdate field to work as well...

--
__________________________________________________________________
Jim Kiraly- jim@ljkiraly.lerc.nasa.gov- NASA Lewis Research Center
----------------- NeXT Mail preferred ----------------------------
From: mek@guinan.psu.edu (Mark E. Kotanchek)
Newsgroups: comp.sys.next.misc
Subject: Re: Workspace Disk Eject bug: Workaround available from NeXT
Date: 13 Oct 92 20:35:19 GMT
Article-I.D.: atlantis.ry21Hiw44a
Organization: Penn State Center for Academic Computing

In article <5369@rosie.NeXT.COM> Matt_Watson@next.com writes:
> NeXT has made available an RTFD document containing a brief description  
> along with a workaround for a 3.0 Workspace bug affecting the  
Disk->eject  
> menu.  It is available via anonymous FTP at NeXT.COM (129.18.1.2) in the  
> /pub/Binaries directory as DiskEjectFix.compressed.  It will uncompress  
> into an RTFD document which includes the executable program, and a  
> description of how to install it.  A checksum (using /usr/bin/sum) of  
> DiskEjectFix.compressed returns:
> 
> 64183   8
> 
> Briefly, it is an executable that installs itself in the (undocumented)  
> Workspace LaunchPaths default the first time it is launched.  Subsequent  
> logins will cause this daemon to be executed, tickling the Workspace to  
> initialize data which, when uninitialized, leads to this bug.
> 
> ...

I just ran into this "disk eject problem" trying to install Appsoft Draw  
and Concurrence under 2.1. Thus, the question, "Does this bug fix work for  
2.1 as well as 3.0?" I've never had this type of problem before so I was  
also wondering what has changed?

Thanks,

Mark.
--
Mark Kotanchek
Guidance & Control Dept - 363 ASB
Applied Research Lab/Penn State
P.O. Box 30
State College, PA 16804
Newsgroups: comp.sys.next.misc
From: dnanian@uw.com (Dave Nanian)
Subject: Re: floppy patch needed!
Reply-To: dnanian@uw.com (Dave Nanian)
Organization: UnderWare, Inc.
Date: Fri, 16 Oct 1992 15:11:54 GMT

In article <1992Oct15.190104.5388@u.washington.edu>  
basiji@stein.u.washington.edu (David Basiji) writes:
> 
> Where can I find the patch to allow the reliable ejection of floppies?
> I searched both sonata and cs.orst but couldn't find it.  Is it readily
> available?
> 
> Thanks,
> David Basiji
> basiji@u.washington.edu
I'm, unfortunately, without FTP access; could someone mail me the ejection  
patch and whatever instructions there are to apply it?

Many thanks!
--
Dave Nanian, UnderWare, Inc. (dnanian@uw.com, uunet!uw!dnanian)
NeXT Mail Preferred, but any mail cheerfully accepted.
From: matthews@oberon.umd.edu (Mike Matthews)
Newsgroups: comp.sys.next.misc
Subject: Re: Call for Volunteers *warning*
Date: 11 Oct 92 12:22:04 GMT
Organization: /etc/organization

In article <1992Oct10.235001.3605@pencom.com> ricardo@chuy (Ricardo Parada) writes:
>I was doing part 2 and had to stop for a while and when I wanted to come  
>back to it to finish it the app had dissappeared.  I wasted about 40 min.

I ran it, and it froze in the between-section countdown.  When into gdb and
attached the process, and it's stuck forever and ever in sigpause() so I
don't think they're using signals very wisely.

Almost sounds like a classic == vs. (a - b) < epison type deal, but I'm not
how real numbers can come into play with signals (not knowing much about them).
Either that or NeXTstep sometimes "undoes" their signals or something.

>+ Ricardo J. Parada
------
Mike Matthews, matthews@oberon.umd.edu (NeXTmail accepted)
------
Ass: The masculine of "lass".
From: bill@markov.math.mcgill.ca (Bill Anderson)
Newsgroups: comp.sys.next.misc
Subject: Re: Reading & writing mac floppies
Date: 8 Oct 92 17:46:44 GMT
Organization: McGill University

I've just got NeXTStep 3.0 up and running. I do a lot of file swapping  
between this NeXT and a Macintosh, and used to use FloppyWorks.  
FloppyWorks had file filters and one could set the file/creator info when  
transferring from NeXT to Mac. There doesn't seem to be any provision for  
this in 3.0. If someone out there has any ideas about this, would they  
please let me know?

Thanks,
Bill Anderson
From: js3b+@andrew.cmu.edu (James Vincent Schultz)
Newsgroups: comp.sys.next.programmer
Subject: help with streams please
Date: 8 Oct 92 05:12:39 GMT
Article-I.D.: andrew.4ep3D7i00iUxE1J0Yj
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA


I'm just starting out as a NeXT programmer, so please forgive me if I'm
missing something obvious.

I'd like to use the NXReadTypes & NXWriteTypes functions to temporarily store
some instance variables in memory.  I looked in NeXT Concepts and the
NeXTStep Reference to come up with the idea of opening a memory stream,
converting that to a typed stream, and passing that to my object.

This is great except that you have to open a stream NX_READONLY or
NX_WRITEONLY.  I can't figure out how to do both.  I want to write to a
stream, then come back a while later and read the values back.

How can I read & write a stream?

Thanks in advance,
James



--
James Schultz
Carnegie Mellon University
js3b+@andrew.cmu.edu
Newsgroups: comp.sys.next.programmer
From: ede978e@monu6.cc.monash.edu.au (Robert D. Nicholson)
Subject: Re: loadNibSection return value
Organization: Monash University, Caulfield Campus
Date: Mon, 12 Oct 1992 13:52:20 GMT

aozer@next.com (Ali Ozer) writes:

>In article <BvrGB9.15x@oceania.com> chris@oceania.com writes:
>>The method:
>>window = [NXApp loadNibSection:"NibFile.nib" owner:self];
>>currently returns a window pointer to one of the windows in the nib section.  Does anyone
>>know if this is a stable "feature"?  Current documentation doesn't mention anything
>>about the return value, other than it won't be nil if the nib section is loaded 
>>correctly.

>No! I mean, YES, I know if this is a stable feature or not, and NO, it isn't.
>This method is not documented to return a window, so don't rely on it. Use outlets.

>Ali, Ali_Ozer@NeXT.com







What does it return since, all *_main.m files use the return value in a if 
statement.  So I guess in this case its checking if the file was found on
disk I guess????
From: thomson@zarda.macc.wisc.edu (Don Thomson)
Newsgroups: comp.sys.next.programmer
Subject: C++ header files under 3.0?
Date: 13 Oct 92 15:51:38 GMT
Organization: University of Wisconsin Academic Computing Center

I was hoping with 3.0 that I'd be able to simply compile C++ applications
without going out and retrieving any additional pieces of the development
environment myself.  That appears not to be the case, as the compiler is not
finding the C++ header files, so presumably they're not included.  Would
someone provide a rundown on what all one needs to do to successfully compile
and link C++ applications under 3.0?  Thanks.....
--
 
----- Don Thomson ----- MACC, 1210 W. Dayton, Madison, WI  53706 -------------
    (608) 262-0138      thomson@macc.wisc.edu / thomson@wiscmacc.bitnet
Newsgroups: comp.sys.next.programmer
From: andylee@oahu.cs.ucla.edu (Andy Lee)
Subject: How to Get Screen Snap Shots?
Organization: UCLA, Computer Science Department
Date: Mon, 12 Oct 92 22:31:18 GMT

(I am still using NS2.1.)  How do I take a snap shot of the screen
with the mouse pointer in the midst of doing something?  I tried to
use Grab, but the "Grab Selection" and "Grab Window" options doesn't
capture the mouse pointer.  And I couldn't figure out how to use the
"Grab Screen" option - I don't have any documentation on Grab.

I am writting a manual for an X window program (using co-Xist), and
need to make screen shots to illustrate various user interface
objects.

Any help would be greatly appreciated!

-- 
+----------------------------------------------------------------------------+
| Andy A. Lee         | UCLA MS Graduate Student, AI Neural Networks         |
| andylee@cs.ucla.edu | Down-to-Earth Idealist & Independent NeXT Developer  |
| (310)824-7131       | "If you don't watch your figure, who will?" - TV Ad. |
From: michael@stb.info.com (Michael Gersten)
Newsgroups: comp.sys.next.programmer
Subject: Re: [NXApp run]
Date: 8 Oct 92 02:47:45 GMT
Organization: STB BBS, La, Ca, 310 397 3137

In article <1992Sep1.002728.15172@fcom.cc.utah.edu> burchard@horizon.math.utah.edu (Paul Burchard) writes:
>> In article <1992Aug25.092051@fdr.jsc.nasa.gov> shirley@fdr.jsc.nasa.gov (Bill  
>> Shirley [CSC]) writes:
>> > 
>> > Does the -run method of Application NEED to be invoked.
>> > I need a little bit more control over the event loop.
>
>There really should be a way to "flush" NXApp, dispatching all pending events  
>and performing any other NXApp chores, and then returning.  I do not know of  
>any way to kludge this with the current API (the modal loop methods almost fit  
>the bill but they all discard some events).
>
>I would suggest NeXT add the following method to NXApp to achieve this:
>
>	- flushEvents:(int)mask waitFor:(double)timeout threshold:(int)level
>
>with parameters analogous to -getNextEvent:waitFor:threshold:.  Anyone at NeXT  
>listening?

Can't you do this by putting a stop message in the queue and then calling
[NXApp run]? The run will return if a 'stop' is seen, but can you call
run from within run (I.e., is it re-entrant), or do you have to re-write the
main() routine?

I agree that 'flushEvents' would be a cleaner way, but cleaner yet would
be '[NXApp flushEvents]'.

		Michael
-- 
		Michael Gersten		michael@stb.info.com
HELLO! I'm a signature virus! Join in the fun and copy me into yours!
ex:.-1,. w $HOME/.signature
Newsgroups: comp.sys.next.programmer
From: shanega@athena.mit.edu (Shane G. Artis)
Subject: Using NeXT 3D kit to dump tesselated surfaces
Keywords: RenderMan, rendering, tesselation, graphics
Organization: Massachusetts Institute of Technology
Date: Sun, 11 Oct 1992 22:12:40 GMT

	Hi, I've found by using the 3D kit on RIB files that I can produce
good wireframe views of the 3D images by choosing a wireframe model.
My goal is to dump RIB primitives and composite solids into polygonal
patches which I can render with a ray-tracer (instead of prman which
doesn't support ray-tracing).  Is there any way to get at the (x,y,z)
coordinate data of the wireframe solids being drawn on the screen by
methods such as renderSelf:, or using the RenderMan interface commands
directly?  

	This would make the 3DKit a high-quality surface tesselator
for solids, patches, NURBS, and so on which is a useful ability.  Any
clues would be appreciated. My instinct is to use the
convertPoints:fromSpace methods and their ilk found in the N3DShape
and N3DCamera objects, but I don't see an immediate or even sneaky
low-level way to get at the points.

	Help much appreciated!

Regards,

Shane
From: aozer@next.com (Ali Ozer)
Newsgroups: comp.sys.next.programmer
Subject: Re: NXImage - problem forcing image depth (2.x)
Date: 11 Oct 92 22:35:24 GMT
Organization: Next Computer, Inc.

In article <1992Oct09.132830.14359@infko.uucp> Detlev Droege writes:
>I'm writing a program to convert 24-bit-color images (color reduction).
>Therefore I need to load the image with its full color. Because these images
>are large I've compressed them with "compress"; to load them I'm setting up a
>pipe to "zcat" and decompress them into a stream. From this stream I
>instantiate an new NXImage with following piece of code:
>	--- generate 'userStream'
>	localImage = [NXImage alloc];
>		// some flags to force loading 24-bit rgb-images
>	[localImage setDataRetained:YES];
>	[localImage setCacheDepthBounded:NO];
>	[localImage setColorMatchPreferred:NO];
>	[localImage setScalable:YES];
>	[localImage setMatchedOnMultipleResolution:NO];
>	[localImage initFromStream:userStream];
>	--- close and remove 'userStream'

First of all, the code above has one big problem: It allocs and uses an
object without an init. This is not right; all objects need to be alloced
then init'ed (once) before they can be used. In fact, the best way to
use alloc & init is to nest them, because the convention is that if an init
method fails to init for some reason, it will free the object and return nil:

	myObject = [[Class allocFromZone:...] init];

In the case of the above code, if you need to do the loading from stream
after setting all the other params, you should use loadFromStream: instead.
initFromStream: is equivalent to init + loadFromStream:.

To get back to the original problem... If you wish to load an image
into an NXImage, and would like the image to keep its original depth,
the correct method to use is setCacheDepthBounded:, with a NO
argument. This tells the NXImage to make the cache deep enough to hold
the image in its full glory. This is done correctly in the above code.
I suspect the reason this isn't working for you must be the wrong
order in which init is done; one of the things init does is to set all
the flags to their default values. Moving init to the right place should
solve the problem.

If you don't need the image cached, but would just like to munge through
the image data, you can also just use the NXBitmapImageRep class. This will
give you the data in its original depth, even if it's a depth not
supported by the windowserver (such as 1 or 4 bit grayscale)...

Ali, Ali_Ozer@NeXT.com
From: xepo@csd4.csd.uwm.edu (Scott R Violet)
Newsgroups: comp.sys.next.programmer
Subject: How the heck do I alloc a simple window?
Date: 16 Oct 1992 16:44:03 GMT
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Distribution: usa
NNTP-Posting-Host: 129.89.7.4
Originator: xepo@csd4.csd.uwm.edu


HI,
	I have been programming on the NeXT off and on for a while
now.  And I just recently wanted to make a small little window without
using IB.  But, I have had no luck at all!!!  I was wondering if
anyone could possibly give me some suggestions on why the following
chuck of code might not work.  It compiles fine, but upon running it I
get a bus error.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#import <appkit/Window.h>
#import <appkit/graphics.h>

void main() {
  id duhWindow;
  NXRect duhRect = {{10.0, 10.0}, {100.0, 100.0}};
  duhWindow = [[Window alloc] initContent:&duhRect
		style:NX_TITLEDSTYLE
		backing:NX_BUFFERED
		buttonMask:NX_ALLBUTTONS
		defer:NO];

}

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

I then compiled it in the following way:
> cc test.m -lNeXT_s

Any suggestions on why this would give me a bus error?
NOTE: I am doing this under 3.0.
Thanks in advance,
-- 

		-Scott Violet (xepo@csd4.csd.uwm.edu)
From: zazula@pri.com (Ralph Zazula)
Newsgroups: comp.sys.next.programmer
Subject: Re: Distributed Objects over SLIP
Keywords: abs(0-27)*100/0 = infinity
Date: 15 Oct 92 22:11:19 GMT
Reply-To: zazula@pri.com
Distribution: world,local

In article <1992Oct15.205136.27472@mcs.anl.gov>  writes:
> In article <1992Oct15.110731.3848@arizona.edu> paul@nextus.tucson.az.us (Paul  
> Tognato-Haddad) writes:
> > Simple question is it possible to run an app that uses Distributed Objects  
> > over a SLIP conection?
> 
> Yes, but the performance is really bad.  There appears to be a lot of  
protocol  
> going on that SLIP deals badly with. My simple benchmark involved passing 108  
> byte packets between a client and server, and timing the overall throughput. 
> 
> With the client and server on the same machine, I got a throughput of about  
> 5KBytes/sec. Over the SLIP line, I got 27 BYTES/sec (!). There was an average  
> of 4 seconds per packet. 
> 
Yes, but one might point out that 27Bytes/s is *infinitely* better than  
0Bytes/s.  So, please do post the details for those us who want this  
unmeasurable performance improvement.

Thanks,
Ralph
---
Ralph Zazula
Pinnacle Research, Inc.
zazula@pri.com (NeXT Mail)
(602)529-1135
From: aozer@next.com (Ali Ozer)
Newsgroups: comp.sys.next.programmer
Subject: Re: loadNibSection return value
Date: 14 Oct 92 18:17:07 GMT
Organization: Next Computer, Inc.

In article <1992Oct12.135220.27053@monu6.cc.monash.edu.au> Robert D. Nicholson writes:
>aozer@next.com (Ali Ozer) writes:
>>In article <BvrGB9.15x@oceania.com> chris@oceania.com writes:
>>>The method:
>>>window = [NXApp loadNibSection:"NibFile.nib" owner:self];
>>>currently returns a window pointer to one of the windows in the nib section.
>>This method is not documented to return a window, so don't rely on it. 
>>Use outlets.
>What does it return since, all *_main.m files use the return value in a if 
>statement.  So I guess in this case its checking if the file was found on
>disk I guess????

Oops, I guess I should've said what it does return. The return value does
indicate success of the load operation (nil on failure, non-nil on success); 
so you can write code like

- showInfo:sender
{
    if (!infoPanel) {
	if (![self loadNibSection:"Info.nib" owner:self withNames:NO]) {
	    NXLogError ("Couldn't find Info.nib");
	}	
    }
    [infoPanel makeKeyAndOrderFront:sender];
    return self;
}

Ali, Ali_Ozer@NeXT.com

Newsgroups: comp.sys.next.programmer