dtynan@sultra.UUCP (Dermot Tynan) (09/21/88)
I got Barry's printer driver (running 1.2) to run. I am late in sending out
invoices, and invoices == money, so there was a major effort underway early
this morning, to get everything up and running. It worked just fine, except
for a couple of things; tabs were all over the place. I haven't had a chance
to look at the driver yet, so it might even be my printer. I fixed the
problem by quickly editing the invoices and replacing all tabs with spaces.
In the future I will probably write a QnD (quick and dirty) program to convert
them, if one doesn't exist. When I reprinted the files, I could see no traces
of missing characters, or anything, so it is looking good! One other problem I
did find, however, is that if I turn off the printer, the system hangs until I
turn it back on. Again, I'll take a closer look tonight.
All-in-all, it seemed to perform just fine. I hope to have gathered all the
1.3 diffs by the end of the week, and will implement them this weekend. So,
Barry, I'll see if there is anything obvious about why it won't work with
1.3. Thanks for the new code -- I can now print decent invoices, etc.
When running ''make'' in the background, I noticed a strange phenomenon.
If, say, I run 'make &', and then type a file; if I hit ^C (or whatever
the SIG_INT character is), make aborts. A quick look at the code showed
a call to cause_sig() (if memory serves). This signals the process
referenced by LOW_USER + line + 1 (again if mem serves), which seems to
affect make running in the background. Has anyone come across this before?
If so, what did they do to fix it? And finally, is it also present in 1.3?
Please respond by email - I'll summarize.
- Der
BTW;
I finally managed to pull something out of Vincent Broman's archive, thanks
for the help Vincent. Anyway, I kinda feel guilty about transmitting a ton
and a half of 1.3 diff files through the net, and seeing as I had some
requests from people to let them know where the diffs are, if you are in the
Bay Area, and want the stuff, let me know, and I'll send them to you. That
way, the ''cost'' is distributed.
--
Reply: dtynan@sultra.UUCP (Dermot Tynan @ Tynan Computers)
{mips,pyramid}!sultra!dtynan
Cast a cold eye on life, on death. Horseman, pass by... [WBY]brucee@runx.ips.oz (Bruce Evans) (09/25/88)
Dermot Tynan writes: >When running ''make'' in the background, I noticed a strange phenomenon. >If, say, I run 'make &', and then type a file; if I hit ^C (or whatever >the SIG_INT character is), make aborts. A quick look at the code showed I think this is fixed in 1.3. Signal handling was cleaned up. I just fixed a number of signal bugs. Try running the command while : ; echo ok; done and hitting SIG_INT a lot of times. The sig_procs counter in the kernel can be messed up in various ways, such as duplicating the signal PENDING flag for a fork, and the signal library routine has races, some fatal. >Barry, I'll see if there is anything obvious about why it won't work with >1.3. Thanks for the new code -- I can now print decent invoices, etc. There shouldn't be so much concern about the differences in 1.3. All it needed to make Barry's driver work in my system was to add the variable int old_state; replace lock() by old_state = lock() replace unlock() or restore() by restore(old_state). The 1.2 driver didn't have the unlock() but Barry's does. Well, it appears to work OK with my clone-80 unbuffered printer, but so did the old driver. I still have some major complaints. (1) I have 2 printer cards, and the driver always uses the wrong one (opposite to DOS). It should just use the word at 0x40:8 (LPT1). (2) When the printer is taken off-line, the printing job is _instantly_ aborted. It should wait forever while I adjust the paper, etc. This would make the driver simpler. (3) The busy waiting is still silly. No chance of getting the delays correct across the spectrum of machines which run Minix. I would eliminate all of the delay loops and some of the support for buffered printers. If the printer is ready as soon as it can be tested after the previous char output, OK, do another one, but limit this somehow. If a buffered printer is detected, it would be better to avoid doing any output at interrupt time, send a message and have the printer task do it. Bruce Evans Internet: brucee@runx.ips.oz.au UUCP: uunet!runx.ips.oz.au!brucee