robtu@itx.isc.com (Rob Tulloh) (03/22/91)
I tried this over in comp.sys.amiga.programmer and got no takers. Anybody over here that doesn't read/get that group have any clues? Help! For those of you who have seen this already, apologies, but I would really like to get this figured out!!! On a lighter note, I think I have figured out how to stop get two copies of my .sig in my posts (changing news readers can be a challenge :-) -------------------- The machine: Amiga 500 3 MB ram 2 hard disks Workbench 1.3 (rev 34.28) The compiler: GNU gcc from abcfd20.larc.nasa.gov (I got PDC to exhibit the same behavior) The linker : good ole blink The library : arp.lib created from running Bind on arp_lib.fd distributed with ARP V39. And now the problem!!! I have encountered a problem that I need help with. I pulled the popen.lzh archive from abcfd20.larc.nasa.gov and tried to compile and run it on my system. In order to use it, I had to be able to access the ASyncRun() subroutine in the ARP library. I pulled the ARP library sources from the net and used the Bind program to convert arp_lib.fd into a library suitable for linking with (the Bind program is something that came with the PDC release I was using before I got gcc). The library seemed to build just fine (I used a68k and zlib to build it) and gcc links with it just fine. Now, the problem. I am able to run the test program that comes with the popen source code, and in the case that I read pipes - no problem. Writing to a pipe causes a [0]+00003 guru message every time. I sent e-mail to the author and got some hints on things to try (thanks Rick!), but nothing seems to work. I tried changing the pipe: device to be the ip: device since I heard there were problems with the native pipe:. I tried recompiling the code using PDC and get the same result. I am running WB 1.3 (v. 34.28) and I have 3 megs of memory installed (so I don't think it is a memory problem). I saw the thread posted about possible problems with ARP and was wondering if my problem is perhaps related to this. Anyone else out there tried to use these routines? Am I having ARP problems? ---------------- Update! I have determined that specifying pcb_Output in the PCB struct can make a difference. The docs indicate that not setting this field will force ASyncRun() to inherit the current CLI's window for output. Not so (or so it seems)! I tried setting the handle to something known like Open("ram:foo",MODE_NEWFILE) and it works like a champ. This also works when you Open() things like NIL: and pipe:foo too. Now, if I hand it the result of Output() explicitly, it still bombs. I tried pulling the pr_COS handle from the Task struct and it bombs, I dug one of the output handles from the cli struct and it bombs. I tried to open the current window again - Open("*",mumble mode) - and it still bombs!!! Also, if I set the pcb_Control flag to PRF_STDIO, ASyncRun will open a second window and then hang both the current window and the new window. Not the same as the guru, but equally useless since I still have to reboot the machine. I am perplexed as to why I can't write to standard output. Buffering the output or throwing it away is not as desirable as seeing it first hand. Has anyone else running an A500 and WB1.3 seen this behavior? Any help would be greatly appreciated! Rob Tulloh -- INTERACTIVE Systems Corp. Tel: (512) 343 0376 Ext. 116 9442 Capital of Texas Hwy. North Fax: (512) 343 0376 Ext. 161 (not a typo!) Arboretum Plaza One, Suite 700 Net: robtu@itx.isc.com (polled daily) Austin, Texas 78759 GEnie: R.TULLOH (polled monthly)