Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!uflorida!mephisto!rutgers!faatcrl!jprad
From: jprad@faatcrl.UUCP (Jack Radigan)
Newsgroups: comp.sys.amiga
Subject: Re: JrComm 1.0
Message-ID: <1490@faatcrl.UUCP>
Date: 17 Jul 90 04:08:43 GMT
References: <31705@cup.portal.com>
Distribution: na
Organization: FAA Technical Center, Atlantic City NJ
Lines: 71

Sullivan@cup.portal.com (sullivan - segall) writes:

>Using a VT100 four color screen, an internal modem, and other such 
>commonplace options, JrComm dies with a doubly freed structure 
>(Guru 8100 0008 at 2BC7D0.)  In fact I haven't been able to find
>a single default configuration other than the initial start up on 
>the workbench that doesn't crash this program.

An 81000008 is, according to the alerts.h header, a semaphore corrupt
guru.  It seems to be happening with systems that have a 2091 or when
you use a custom screen *and* also change the priority of th task during
startup.

Why this guru occurs when both a custom screen *and* you change priority
at the same time is currently beyond me.  If you just change the screen
or just change the priority this guru does not occur, very strange.

>JrComm 1.0 is also given to locking up.  Generally this is accomplished
>by entering a state where the cursor is still flashing and the modem is
>still communicating, but the menues are forever lost.  Not too bad if
>all you wanted was a straight VT100 (or TTY, or SKYTERM, or Amiga) 
>terminal, but a little shy of the downloads, dialing, palettes,
>and reconfigurability I had hoped for.

Could you please give me some sequence of events so that I can try to
duplicate this?  I've not had this reported before.

>What I'd still like to see:

>	*	Something a little more robust

I'm working on it, promise!  :-)  Seriously, I'm quite embarrased about the
problems that remain.

>	*	Row and column counters on the status line
>	*	Row and column limits (ie 80 x 25) also
>	*	The ability to limit rows and columns (even if my
>		workbench is morerowed, I don't neccessarily want
>		my terminal to be non-standard.)

Hmm, doable.

>	*	The ability to reset the text to default output
>		modes.  (There is a clearscreen option that does
>		NOT do this correctly.)

Do you mean a VT100 reset?  For the moment, opening the terminal requester
does this.  (I know, something "better"...).

>And of course in my dream-land there is also ARexx support without
>which I can't write scripts.

  Yes, eventually this too.

>JRComm lives in a sort of unusual netherworld between the gratuitous
>complexity of commercial communications packages, and the featureless
>public domain.  JrComm 1.0 could easily be the finest terminal program
>available for shareware for any machine, but is limited by its roughness,
>and its lack of a defineable market niche.  

Uh, thanks.  (I guess)... :-)

>For all that JrComm has going for it, I truly hope that the rough
>corners will be smoothed out.  I'll be waiting anxiously for 1.1.

1.01 will be a bug fix, 1.1 will add XPR.  Scripts and ARexx somewhat
farther down the road.

Fair enough?

  -jack-