Welcome.

    See "faq.txt" and "todo.txt" for additional information.

With the 'console' on, any line you press ENTER on will be executed as a command line.
Navigation through this console is as a standard TextArea.
Additional keyboard help may be obtained by pressing enter on the next line.
?console
Note that if you did press enter on the above line, the output did not get
inserted, but was instead appended to the end of the screen.

When the 'console' is off, then input is through the JVM's $stdin.  In this case
only what is typed matters.

When you start PJDA, it uses a command file, like /etc/profile, only the name is
'<jarname>.init.pjda' in the directory where the PJDA is loading from.  If this file
does not exist, then an error message is displayed, and the PJDA prompt is displayed
to the $STDLIST.  <jarname> is the name of the jar executed, or "", if no jar is used
(I.E. ".init.pjda").  At the end of said command file, there is a line '. ~/.init.pjda',
which does exactly what any unix person would expect it to do.  For those of you who
do not know Unix, the '. <file>' tells the system to read its command input from <file>.
File nomenclature here is the same as unix, except that in Java, '~' is defined by
System.getProperty("user.home").
For examples of this behavior, see 'pjda.init.pjda' and 'install.init.pjda'.

The default list of jars where PJDA looks for "things"(classes and scripts), without
the "jar:file:dirname($0)/" and ".jar", is "Command;local;JBase;jgmail;sh".
I can explain the behavior, but it is easier to see if you look at This.java, instead.
Just note that the file name is [.]pjda.Command.Jar.Path, and behaves in a reasonable way.
If the first non blank string begins with an '=', then the jar name[s] listed replace
the current value, so you can override the list if desired.
If the first non blank string does not begin with an '=', then the line is taken to be a
';' delimited list of jars located in the same directory where the pjda and pjda_admin
were located, or it must specify the appropriate location, just remember to leave off
the '.jar' extension.
If the 'tools.jar' is reasonably locatable(see This.java), then it will be added to
the list as well.  This way you can use the 'javac' command, and it will be made available
without any manual intervention.  If it is not available, then it will not be added to the
list.

This is the only somewhat hardcoded filename.  Package nomenclature and locations
have not been hardcoded, even in regard to required interfaces, so that package relocation,
or renaming, or various forms of "flattery";-), is simplified.  Examples of this are in
pjda.admin.Pjda(see Pjda initialization and 'BigTextArea' as well as around '(HIC)').


For help, type 'help' and press enter.

If the console is turned on, via 'console on', then a pjda.pjutil.BigTextArea, is used
for the console.  When I say BIG I don't mean 4096 characters.

Here is a brief explanation of the problems which precipitated this solution.
The Java AWT Class, TextArea, has major drawbacks in general and especially under Windows.
It is constrained to a maximum size that is really not that large.
Therefore, if one wants to have a TextArea which can contain a little more
than just a small amount of data, you must implement your own solution to this deficit.

BigTextArea, is just such a solution, with major additions.

First an abstract class pjdaTextArea was created which addressed the more mundane issues
and left the specific implementation of how to keep track of the contents undefined.

These classes override critical methods, and trap and/or consume specific keyboard events.
At all times there are three significant components:  the object holding the text above
the visible TextArea, the visible TextArea itself, and an object holding
the text below the visible TextArea.  If a pageup/pagedown/homeup/homedown
is pressed, the TextArea, and the above two objects are changed appropriately.
If the text area is resized, then the LinesPerPage is recomputed, so that
PageUp/PageDown still work as expected.

If you change when the "console on" command executes in the startup sequence, and you
execute from a jar, then you may see a VM stack overflow after the console comes up.
The JVM reports that it is due to the JIT.  This is not true.
It is due an AWT-Thread timing bug.  What is never explained is that AWT actions
are actually performed by the AWT-Thread, not your thread.  This means that there are
no atomic AWT actions.  Anything you do to affect your TextArea may not be done for
some time after the method completes.  Changes were made to address the problem and so
far it has not returned.  If you see it, please let me know.

Another important point.  Output is always appended to the screen, and as the screen
fills, the AWT-Thread gets slower and slower.  Even on 500Mhz machine, once the console
gets more than 25000 lines in it, keyboard echo gets noticeably slow.  This can be 
addressed only by reducing the number of lines of screen memory.  See screen help for 
more information.  Even with 25+K wide lines, BigTextArea was only noticeably slow only
for significant memcpy operations.  This is also the limit of memory for my machine.  I 
tried to go higher, but I got an out of memory error.  Note that this did not crash my 
application, and just dragging the scroll bar up to the top of the screen then doing a 
clear (alt-j), corrected the situation.  Not something the standard Java application can do.


jc.bat(/sh) currently uses "jikes", but can easily be modified to use "javac".
Please note that code is implemented to be compatible with javac, and not
with jikes pedantic mode.  They are mutually incompatible.
I recommend therefore, that any code development effort for this project
be done so as to compile with javac, but if you want to use jikes because
it is so dramatically faster <mantra>(open source, open source)</mantra>,
then it will still work.


Suggestions, and comments are welcome.


All I ask in return, is appropriate acknowledgement.

If you use this, or have further fixes you want included, please let me know,
I would appreciate hearing about it.

Thanks in advance,

Ken Graham.
tea_man@users.sourceforge.net