Re: [Jscheme-user] Re: trimming listener output

[Robert M. <rma...@bb...>]

> I'm having second thoughts about using the static variable here.
> If it would be possible to use a local variable (e.g. associated to
> an Evaluator) or a thread local variable (which could be inherited
> by children threads) that would be better....

Turns out this is the big thing I had changed in my local tree since
the time I sent my last message.  In my revised implementation, REPL
print length is controlled by an instance variable on Evaluator called
"replPrintLength".  It defaults to -1 (unlimited), and I've changed
our project interactive startup routine to set it to 10.  The syntax
is a bit ugly, but it seems to work.  (The tryCatch is there in case
the current jscheme jar doesn't have the variable.  Could probably
make this a bit prettier by providing a method on the java side.)

  (tryCatch
   (begin
     (.replPrintLength$ (Scheme.currentEvaluator) 10)
     (display {(print length set to [(.replPrintLength$ (Scheme.currentEvaluator))])\n}))
   (lambda (e)
      (display "(unable to set print length limit)\n")))

> The problem I take it is that you don't want to have your interactive
> sessions print out large result expressions..

Exactly.  I was concerned that my original implementation had effects
outside the REPL loop, so that's why I changed it.  My changes now
affect more central functions (like readEvalWriteLoop and write) but I
think they're much safer and cleaner than before.

> > I'd rather have the REPL assume interactive by default, if it won't
> > break too much legacy stuff out there.
> 
> On the other hand, if you use a switch "--interactive"
>    % java -jar jscheme.jar --interactive
> or just a "-i" switch
>   % java -cp lib/jscheme.jar jscheme.REPL -i file1.scm ... '(command a1 
> a2 ...)'
> 
> then it won't break any legacy stuff and will only be marginally  more 
> complex to handle....

I'm mostly concerned with new jscheme users here -- is there some way
that we can make it so that if they do the obvious thing "out of the
box" to start up an interactive jscheme session, they get the
interactive-style REPL, without breaking legacy scripts?

> I think it looks fine, but my only request would be to have it be
> off by default, but allow a simple switch "-i" to turn in on.  This
> would make the code fully backward compatible.  We can let users try
> it out on their code bases (we've got three fairly large projects
> using JScheme) and if noone reports any problems we could make it
> the default behavior later.

Sounds like a good plan in general.  I think change #2 (normal
toString for BacktraceException) can stand on its own, and shouldn't
be affected by -i.  I'm backing off turning on change #3 (generalized
to replPrintLength) by default, although I'd like to figure out a way
that doesn't require new users to know about "-i".

Not sure about change #1 (avoid stack trace when nameResults is on).
It shouldn't affect normal non-interactive results much more than
nameResults already does (and that's on by default).  Error logs may
end up with less information, but how much do people depend on the
top-level error handler for offline debugging (instead of having their
own error handler)?  Sigh, probably more than they should.  So, do I
need to add an interactive flag in addition to nameResults?  I think
exception handling control needs to be separate from replPrintLength.

Regards,
	Rob