[comp.os.os2] uEMACS

lance@vax1.acs.udel.EDU (Daniel A Lentz) (12/18/89)

  Many thanks to everyone who responded to my previous question about 'good
reading material.'
	The winner? Microsoft's Programming OS/2 & Programming PM. 
(and, of course, the one vote for the newspaper...) :-)

Now, for a couple of things that have been nagging at me...


1. When I use the version of uEMACS posted here recently, all works fine for
about an hour, and then I get a protection violation, causing all of my work
to be lost in never-never land. I'm using uEMACS under PM with ASAVE set.
I DON'T have the same file open twice. The other programs running are
File System, TimeLine (clock program), ScrnBlnk, and AnyWhere (file finder).
Is it me? And, is there any way to make OS/2 be more reasonable about the
violation? It seems to me that it wouldn't hurt anything if OS/2 gave a
menu something like DOS's Abort, Retry, Ignore. (Then again, I'm pretty
stupid!) Since the violation was intercepted by the OS, what could it hurt
just to ignore it and let the program run? 
	By the way, I use EE 1.1


2. If you know of any good archive sites for OS/2 stuff, mail them to me. IF
there's enough response (> two) I'll compile them and post here.


 
-- 
                 _    __   _ __   __   __               lance@vax1.acs.udel.edu
o o o          _//   /  ) ' )  ) /  ) /  `    /         o o o o o o o o o o o o
o o o          /    /--/   /  / /    /--     /           o o o o o o o o o o o 
o o o         /___ /  (_  /  ( (__/ (___,   o           o o o o o o o o o o o o

rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) (12/20/89)

In article <5345@udccvax1.acs.udel.EDU> lance@vax1.acs.udel.EDU (Daniel A Lentz) writes:
>1. When I use the version of uEMACS posted here recently, all works fine for
>about an hour, and then I get a protection violation, causing all of my work
>to be lost in never-never land. I'm using uEMACS under PM with ASAVE set.

(I compiled and posted uEMACS)

What was the exact situation, what were you doing at the moment of the
protection fault inside the editor ?

After posting it, I found one bug: When you point with the mouse pointer
into the command line of uEMACS and press the right mouse button, you
get a protection fault. I'm working on it and will repost the .EXE when
fixed (need time ...). 

Was it this bug ?

It is a 'golden rule' not to work over hours without saving !
uEMACS was ported from the Unix and DOS versions and may have bugs, but
I did not find other than the one described above until now.

Kai Uwe Rommel,
Munich
rommel@lan.informatik.tu-muenchen.dbp.de

kulokari@cc.helsinki.fi (12/21/89)

A serious problem in the published implementations of uEmacs on OS/2  (I have
seen  two; the first was posted by Sugih Jamin) is that the mouse/keyboard
handler uses busy loop (polling) and therefore hogs the system resources.
This shows very clearly if you monitor the CPU usage with some of the
utilities available, and background tasks slow down to a crawl.

Busy loop is a no-no in OS/2, instead you must use threads and semaphores. I
have done so in my own version, which I will probably post in the near
future. I have also completely rewritten the display handler.

There seems to be some bugs in the search routines. I will try to fix
these, too. Version 3.10 is quite buggy.

Hannu Kulokari
CC, U of Helsinki
Finland
Internet: kulokari@cc.helsinki.fi
Bitnet: kulokari@finuh

lance@vax1.acs.udel.EDU (Daniel A Lentz) (12/22/89)

	I could be wrong, but I'm almost certain that this was the problem.
Thanks!

-- 
                 _    __   _ __   __   __               lance@vax1.acs.udel.edu
o o o          _//   /  ) ' )  ) /  ) /  `    /         o o o o o o o o o o o o
o o o          /    /--/   /  / /    /--     /           o o o o o o o o o o o 
o o o         /___ /  (_  /  ( (__/ (___,   o           o o o o o o o o o o o o

jamin@cogsci.berkeley.edu (Sugih Jamin) (12/22/89)

In article <1654.2590d3f4@cc.helsinki.fi> kulokari@cc.helsinki.fi writes:
>A serious problem in the published implementations of uEmacs on OS/2  (I have
>seen  two; the first was posted by Sugih Jamin) is that the mouse/keyboard
>handler uses busy loop (polling) and therefore hogs the system resources.

I noticed.  It was a quick and dirty job for lack of an editor.
I'm looking forward to your version.  Thanks.

sugih

rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) (01/02/90)

I know about the busy loop problem. But I already tried to use to
separate threads for keyboard and mouse input. I was surprised to see
that the MouReadEventQueue() call apears to use busy wait too when the
MOUSE_WAIT mode is used. When my mouse thread waited for an event, my
other thread waiting for keyboard input was blocked !?! Any hints ?
Currently I use the MOUSE_NOWAIT mode and make some DosSleep() calls
between the MouReadEventQueue() calls.

Kai Uwe Rommel
rommel@lan.informatik.tu-muenchen.dbp.de