HDTenEightyP/NetNews huggingface dataset:
From: bpja@codex.oz.au (Brett Adam)
Newsgroups: comp.sys.next.programmer
Subject: Re: lockf - is it broken
Date: 12 Apr 92 04:27:51 GMT
Organization: Codex Software Development Pty. Ltd.

In article <1992Apr8.153515.3244@n1.nsf.gov> bryan@ad.cise.nsf.gov (Bryan  
Thompson) writes:
> 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?

Yes.

We went through the same long tirade and finally, NeXT admitted that they had  
'disabled' lockf due to potential problems with NFS.

Wait until 3.0 - maybe it's fixed - maybe it isn't.

BTW. We've built the faircom stuff on the NeXT and it all works well.
-- 
---------------------------------------------------------------
Brett Adam                 Codex Software Development Pty. Ltd.
NeXTMail: bpja@codex.oz.au                  AppleLink: AUST0335
(Preferred.)                                 (Only if you must) 
Xref: sparky comp.sys.next.programmer:3323 sci.math.symbolic:1203
From: engelsma@golden.cps.msu.edu (Engelsma Jonathan)
Newsgroups: comp.sys.next.programmer,sci.math.symbolic
Subject: Re: Linking a C program to Mathematica (ver. 1.2)
Date: 8 Apr 92 13:26:58 GMT
Organization: Dept. of Computer Science, Michigan State University

In article <1992Apr4.002423.7852@athena.mit.edu>, shanega@athena.mit.edu (Shane G. Artis) writes:
|> Hi!  Does anybody have any code fragments or code files that give a
|> good example of linking a C program to Mathematica's Kernel, when
|> running on a NeXT computer with Mathematica version 1.2?  I need
|> to establish a two-way link and send matrices back and forth, as
|> well as perform various other common Mathematica operations upon my
|> data (both symbolic and numerical).
|>
|> Any suggestions/code?
|>

I found a small tech report from wolfram in the manuals that came
with our Sun version of mathematica that was quite useful.  It is
entitled: Mathlink External Communication in Mathematica.   I 
suppose you would need to contact Wolfram to get a copy.  Can 
somebody listening comment on the availibility of this tech report?

-------------------------------------------------------------------------
Jonathan R. Engelsma                            Michigan State University
                                                     Department of
E-mail:   engelsma@cps.msu.edu                     Computer Science
	  uunet!frith!engelsma	
	  uunet!frith!jresys!engelsma (home)	
-------------------------------------------------------------------------
Newsgroups: comp.sys.next.programmer
From: smb3u@kiptron.psyc.virginia.edu (Steven M. Boker)
Subject: Re: Virtual memory devours my disk
Organization: University of Virginia, Department of Psychology
Date: Sun, 5 Apr 1992 16:16:32 GMT

In article <264@moene.UUCP> toon@moene.uucp (Toon Moene) writes:
>In article <giDLiB2w165w@midiline.la.ca.us> dylan@midiline.la.ca.us  
>(Comrade D) writes:
>
>[ ... essentially ... ]
>
>> the problem.  The shortest summary is, "Yes, it's a problem of varying 
>> extents and it's not one NeXT plans on fixing any time soon."
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> For virtual memory, NeXTStep uses a "stack-oriented" scheme that has 
>> terrible side-effects for me.  (See NeXTanswers sysadmin.569 on this 
>> scheme.)
>
>[ ... describing NeXTStep as adding new paged out pages only at the
>      end of the file ...]
>
>This is horrible.  As the NeXTanswers item says (paraphrased): "if a long  
>running process [like the WindowServer - TM] is adding another page to the  
>swap file, it can not be truncated EVEN IF ALL INTERMEDIATE PAGES ARE  
>FREED".  Well, there you have it.  And we thought we got a hot new OS  
>architecture at hand in our lovely black boxes.  EVEN VMS CAN DO THIS  
>BETTER.   
>

This is in fact horrible.  And I was doubly horrified to hear that 3.0
was not intending to address the _Number_One_Weakness_ of the operating
system as perceived by the users here.  Having to reboot your machine
several times a day under what my users consider to be "normal" conditions
is, to them, a considerable inconvenience.  Why NeXT hasn't put major
effort into this achilles heel is beyond me.

Steve


-- 
 #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#
 #  Steve Boker           #             "Two's bifurcation                  #
 #  smb3u@virginia.edu    #             but three's chaotic"                #
 #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#
Xref: sparky comp.sys.next.programmer:3430 comp.sys.next.misc:14038
From: zeno@hardy.u.washington.edu (King of SPAM)
Newsgroups: comp.sys.next.programmer,comp.sys.next.misc
Subject: Multiple virtual modems?
Date: 13 Apr 92 19:34:09 GMT
Distribution: usa
Organization: University of Washington, Seattle

I was wondering if anyone had written an application which takes one
physical modem and makes it into a larger number of virtual modems for
unix->unix connections.  (for instance, so I could dial into my local
unix workstation at 9600 baud and run some program there, then run
some program locally which would create /dev/vmodem0, /dev/vmodem1 and
/dev/vmodem2, both of which would have a connection and could potentially
be used by more than one window and/or user)  

Yes, I know about 'screen'.  Also, due to routing difficulties SLIP is 
improbable for me at this time.






-- 
Sean T. Lamont                           |   "Don't oppress me, It's
zeno@cac.washington.edu                  |    'computer of color!' "
zeno@niss.soc.washington.edu (NeXT mail) |            -My slab
-Department of Computer Science-------------Department of Music Technology----
Newsgroups: comp.sys.next.programmer
From: larry@netcom.com (Larry Cordner)
Subject: Re: User Path
Date: Sat, 11 Apr 92 21:45:28 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Keywords: DPSDoUserPath

In article <1992Apr11.091359.65305@yuma.acns.colostate.edu> ckminer@LANCE.ColoState.Edu (Chris Miner) writes:
>
>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?


The easy answer is that the bbox argument should be defined as a float, if you
want to use, float coords, dps_float.  The types of bbox and coords, need to
be the same as the type passed to DPSDoUserPath().


The more difficult question is, why is this so?  The answer lies in the way 
DPSDoUserPath() processes its arguments.  DPSDoUserPath() takes its arguments
and turns them into an array that contains two PostScript binary object
sequences.  The first of these sequences is a concatenation of the bbox and
coords arguments, and its type is the type passed to DPSDoUserPath().  In your
example, the one that doesn't work, the type would be dps_float.  Since bbox
is defined as short, and it is encoded as type dps_float, bbox doesn't have
enough bytes in it, so random bytes are used to fill in.  (Actually the bytes
aren't random they're the eight bytes that follow bbox in memory.  In your
case, the first five bytes come from the ops array, and the other three come
from whatever is after the ops array in memory.)


It's the same old story, a function wants a float and you give it a short.  The
function doesn't know you only passed a short and grabs a float sized object.
Maybe the function survives maybe it doesn't.  In your case if you take a look
at the console, you'll see a bunch of DPS client library errors.

BTW: I could find no mention in the docs, that says the bbox, coords and the
type passed to DPSDoUserPath() all need to be the same.  But from what I've
seen they apparently do!



Hope this helps,

larry cordner
larry@netcom.com

P.S. If you need more details about what is going on, send me mail.
     I have a long and drawn out description of this, including a break down
     of the binary encoded user paths that are sent to the server, this really
     shows the problem.
From: dh10+@andrew.cmu.edu (David Christian Homan)
Newsgroups: comp.sys.next.programmer
Subject: Leaving the Internet
Date: 15 Apr 92 07:07:34 GMT
Organization: Senior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Hey folks ---

	I'm leaving the "andrew.cmu.edu" cell of the Internet sometime in May
or June due to my imminent graduation from this hell hole I have come to
love so much over the past four years.  

	Since I don't want to miss all the exciting action that happens here on
comp.sys.next.programmer (Automatic Garbage Collection threads, in
particular...), I am planning on putting myself back on the net through
someone like PSI when I move.  So, I would like to hear from anyone who
has gone through this process and the main things I'm interested in are:

	1.  What service do you have? (SLIP, dialup, leased line, etc...)
	2.  Who did you get it from?
	3  Is it "worth" it?
	4.  How can I make this tax deductible????
	5. How "painful" was the process?

	Of course, #4 is the really important question.  It's the deciding
factor between $39 a month at 2400 baud, or $250 a month at 14,400baud.

	Sigh,  you know, you never TRULY appreciate something until someone is
just about to take it away from you --- and then you find out how much
it costs....

	Send mail directly to me at:

	dhoman@cmu.edu

	I don't want to clutter the board... If anyone is interested in a
"summary" of the responses, I will compile them into a file and leave it
at some ftp site.  (Probably sonata - unless anyone wants to volunteer a
site.)

Thanks a lot....

- David.

	
Newsgroups: comp.sys.next.programmer
From: coco@ihcoco.att.com (Felix A. Lugo)
Subject: /dev/sg0
Organization: AT&T Bell Laboratories, Naperville, IL
Date: Wed, 15 Apr 1992 20:32:48 GMT

Hi,
	I'm using /dev/sg0 to request a SCSI inquiry of all available
	devices on the bus.  Here's the algorithm I'm using:

		- open /dev/sg0 for read/write
		- LOOP (loop:= 0 ; loop < 8; loop:=loop+1)
			- set lun:=0 and target:=loop  --  ioctl (SGIOCSTL)
			- send inquiry command -- ioctl (SGIOCREQ)
			- print results
		- close /dev/sg0

	The above procedure works properly, but every now and then, it fails
	to detect ALL SCSI devices!

	BTW, I've checked the SG(4) man page, and some SCSI examples from
	the net.  They all display the same behavior!

	What's going on?  Is it a NeXT problem, or am I missing something
	in the above algorithm?

---

===========================================================================
Felix A. Lugo

E-Mail: (NeXTmail preferred)			Felix_A_Lugo@ATT.COM
						coco@ihcoco.att.com
     AT&T NeXT User Group			nug@ihcoco.att.com
     HOME NeXTcube				home@ihcoco.att.com
===========================================================================
From: songer@ei.ecn.purdue.edu (Christopher M Songer)
Newsgroups: comp.sys.next.programmer
Subject: Pipes, Child Processes and Other Uglies
Summary: Medic!
Date: 7 Apr 92 17:03:18 GMT
Organization: Purdue University Engineering Computer Network

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
Newsgroups: comp.sys.next.programmer,sci.math.symbolic
From: fletcher@socrates.umd.edu (Charles Fletcher)
Subject: MathLink (Update and semi-apology)
Keywords: MathLink
Organization: University of Maryland University College
Date: Fri, 10 Apr 1992 15:00:15 GMT

Well in the last couple of days I have come across a couple of things
that make me believe MathLink almost works (I still stand by my original
accessment and wouldn't bet the farm on it, but the simple examples
can be made to work.) These two things are:

1) Chuck Fleming posted a simple MathLink example (in connection with
ObjC on the NeXT) which works. Looking at his code I noticed some things
which were missing from mine.

2) I got to look at the most recent MathLink docs (although they are 
still stamped Preliminary. You should look for the WRI Tech Report on
MathLink with the Blue and White cover. This is probably free for the asking.)

Here is the key (to me at least):

   while (MLNextPacket(mylink) != RETURNPKT) MLNewPacket(mylink);

If you don't have this in your examples, you don't have the latest stuff.

I have now gotten the two simple examples in the docs and one of my own
working. Maybe there is hope.

Charlie

-- 
*********************************************************************
*	NeXTMail to:		*	...to confer, converse, and *
*	charlie@technosci.com	*	otherwise hobnob with my    *
*				*	fellow wizards.		    *
From: aozer@next.com (Ali Ozer)
Newsgroups: comp.sys.next.programmer
Subject: Re: broken PostScript for colorimage
Date: 4 Apr 92 01:02:35 GMT
Distribution: usa
Organization: Next Computer, Inc.

In article <1992Apr3.072512.22668@csus.edu> eps@cs.sfsu.edu writes:
>In article <3414@rosie.NeXT.COM> aozer@next.com (Ali Ozer) writes:
>>3.0 writes the data inline (as binary if possible) and reads it with
>>readhexstring; this solves the VM problem.
>It seems to me that the current method would be superior for very
>small images (e.g. icons) where VM consumption isn't the issue.
>Speed and performance are important!!

Yeah, except most printers don't garbage collect, and if you happen to
write out a dozen or so "small" images, you might still eat up a
significant piece of the PostScript VM available in the printer.

Ali
From: simsong (Simson L. Garfinkel)
Newsgroups: comp.sys.next.programmer
Subject: Re: -=?=- dumping text into an invisible text object -=?=-
Date: 13 Apr 92 12:54:15 GMT
Reply-To: simsong@next.cambridge.ma.us
Organization: NeXTWORLD Magazine

Although the new code works, it's still much slower than what I suggested.  the  
added overhead of having the window server create a new window, create a new  
text object, and then destroy them is quite significant.  You're much better  
off simply having an extra Text object on your existing window and moving it  
off to 1e30 where nobody can see it.
-- 

................................................................simson
From: simsong (Simson L. Garfinkel)
Newsgroups: comp.sys.next.programmer
Subject: Re: Files in my home directory, and other ruminations
Date: 13 Apr 92 12:56:22 GMT
Reply-To: simsong@next.cambridge.ma.us
Organization: NeXTWORLD Magazine

Instead of using dot-files, store things with the defaults system.

'nuf said.
-- 

................................................................simson
From: michael@stb.info.com
Newsgroups: comp.sys.next.programmer
Subject: Help: Memory control for another thread
Date: 8 Apr 92 20:35:17 GMT
Organization: STB BBS, La, Ca, 310 319 3778


I need help with something.

I want to do an emulation of another 68000 based machine. I've decided to
go at the hardware level, and really simulate the other machine.

The idea is that I will have several threads, one will be executing the
native code for the other machine, and accessing memory; and a second
one that will start up the first one, set up its memory map so that the
addresses for #1 that correspond to hardware are trapped by the #2,
and it will then return the results to the first one.

I need help with this.

Specifically, what I've come up with so far is that I can mark addresses
as not readable or not writable, so that an attempt will trap, and I can
set the thread exception to be my other thread. But I still need to determine
what address was being accessed, and if it was a write, what value was going
there; or if it was a read, I need to be able to return a value. This is
what I don't know how to do.

Any ideas?

		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

-- 
		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: mcgredo@bluto.ie.orst.edu (Don McGregor)
Subject: NXBrowser highlighting probs
Reply-To: mcgredo@bluto.ie.orst.edu
Organization: Oregon State University - Univ. Computing Services
Date: Tue, 7 Apr 1992 06:00:45 GMT


I've got a problem with a subclass of NXBrowserCell.

I've reimplemented the drawInside:inView: method and am using it in a normal  
NXBrowser.  The highlighting of selected cells seems to work inconsistently. 

I can select a cell fine the first time, and then I can deselect it.   
Highlighting works correctly in both instances.  But after that, I can't  
highlight the cell again.  The cell is being selected OK (I can tell because  
the next column in the NXBrowser is changing) but the cell isn't being  
highlighted after the first selection.

The relevant code in the drawInside:inView: method looks like

 PSsetgray((cFlags1.highlighted || cFlags1.state) ? NX_WHITE : NX_LTGRAY);
 NXRectFill(cellFrame);

Can anyone point me in the direction of what might be causing something like  
this?

--
Don McGregor             | "I like maxims that don't encourage behavior
mcgredo@bluto.ie.orst.edu|  modification"   --Calvin
Newsgroups: comp.sys.next.programmer
From: scotty@gagetalker.com (Scott Turner)
Subject: Re: violent crashes
Organization: L5 Computing
Date: Wed, 15 Apr 1992 02:04:02 GMT

In article <1992Apr13.232753.25043@ucsu.Colorado.EDU>  
schildba@spot.Colorado.EDU (Wolfgang Schildbach) writes:
|> 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.
I've seen this as well. It appears that killing postscript/windowserver
with some sort of nasty postscript can cause this.

Killing all your processes and restarting the window server makes sense,
without a working postscript you aren't going to see very much.

Of course, if postscript didn't die in the first place...

Note, I've had some weirdness out of these restarts. The mail program lock's
the mail file. And when it gets killed it doesn't always seem to unlock the
file before dying. Which brings up an alert panel after you log back in and
run it again.

Scotty
Newsgroups: comp.sys.next.programmer
From: abbas@osf.org (Abbas Birjandi)
Subject: Modula-3 port to NeXT
Organization: Open Software Foundation
Date: Wed, 15 Apr 1992 16:55:49 GMT

I am looking for a port of Modula-3 for NeXT.  I was wondering
1) if there exist such a port; 2) if it is public domain and
can be ftp-ed.

please resond directly to abbas@osf.org , if there will be
any interest I post the summary,

Thanks.

Abbas

Newsgroups: comp.sys.next.programmer
From: mdm@wdl1.wdl.loral.com (Mike D Marchionna)
Subject: Manipulating any window with an NeXTstep application
Keywords: DPS context window
Organization: Loral Western Development Labs
Date: Mon, 13 Apr 1992 20:28:45 GMT

This may be impossible, but I am trying to write a NeXTstep application that
can tell me the size and location of every window on the screen and let me
reposition them through my NeXTstep application.  I am trying to do this
with the DPS operators using the context of the NXApp object.  I know it is
possible to write straight postscript code that can manipulate all the windows
on the screen (e.g. the gravity demo within scene, and the icon alignment 
utility), but I'm having little luck doing similar things with my App. via 
the DPS functions.

For example the IconAlign postscript code uses the screenlistcount and
screenlist operators to get all the window numbers of all the currently
displayed windows.  It then uses those window numbers with currentwindowbounds
and movewindow operators.  I can get the window list with the
DPSscreenlistcount and DPSscreenlist functions, but when I try to use
the window numbers I get in the window list I always get a range check error.
For example if I wanted to print out a list of all the windows on screen
giving thier location and size I tried to do something like this.

- ListWindows:sender

{	/* Local Variables */
	DPSContext   context;
	int			 index;
	int			 winCount;
	int		    *winList;
	float		 winX, winY;
	float		 winW, winH;

/* BEGIN ListWindows */
context = [NXApp context];

DPSscreenlistcount(context, 0, &winCount);

winList = (int*)malloc(winCount * sizeof(int));
DPSscreenlist(context, 0, winCount, winList);

for (index = 0; index < winCount; winCount++)
	{
	DPScurrentwindowbounds(context, winList[index],
						   &winX, &winY, &winW, winH);
	printf("Window:%d (%d,%d) [%d,%d]\n",
		   winList[index], winX, winY, winW, winH);
	}
return(self);
}/* END ListWindow */

This always gives me a range check error and hangs the App at the 
DPScurrentwindowbounds call.  Strangely I am still able to quit the App.
normally.  If I substitute 0 for winList[index] the call works, but
obviously is not what I need.  Can anybody explain why this doesn't work, and
maybe suggest an approach that would.  I need to repeatedly get the size
and location of all the windows on screen and also to move them from with
my NeXTstep application.  Any suggestions or pointers greatly appreciated.

--MDM

-- 
 _________________________________________________________________________ 
(  _______________________________   Brain, and brain!  What is brain!    ) 
 \________________________________)        --Star Trek (Spock's Brain)   /
El_Rayo_X_______________________________________________________________/ 
Newsgroups: comp.sys.next.programmer