Menu
▾
▴
Re: [Jscheme-user] Re: trimming listener output
|
From: Timothy J. H. <ti...@cs...> - 2005-04-26 18:00:10
|
Hi Rob, On Apr 20, 2005, at 6:46 PM, Robert MacIntyre wrote: > Hi, Tim, > > Sorry I've let this languish so long. Basically, I went off and did > something quick that worked for me, but now Rusty wants it too so it's > time to think about folding back in my changes, if the community likes > them. > > Tim wrote: >> The easiest thing to do as a first step is to create a public static >> int >> variable to that gives the global print depth (zero for infinite >> depth? >> zero by default?) The REPL could set it to a reasonable value for >> interactive sessions. We could specify an interactive session on >> the command line: >> >> % java -cp jscheme.jar jscheme.REPL -interactive >> >> One could also change the depth at runtime: >> >>> (set! jsint.Scheme.printDepth$ 10) 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.... The problem I take it is that you don't want to have your interactive sessions print out large result expressions.. > > I like this, and it's pretty much what I had started to implement on > my own before writing to you, but 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.... > My current solution is somewhere in between -- I hush errors > by default (actually, based on nameResults, which is on by defaul) but > set a very high limit (Integer.MAX_VALUE) for list-print length. > > I've made three changes in my version I'd like to propose to share: > > 1. When nameResults is on in readEvalWriteLoop, just return the > Throwable object when eval throws an exception. The user can then > call printStackTrace for more information, but in most cases the > toString you get is all you need. This sounds reasonable ... > > 2. Remove special toString from BacktraceException. The current > toString prints a whole stack trace. If I'd wanted that, I > woulda called printStackTrace. The default toString (class name > and message) tells you plenty, most of the time. (Sometimes the > message comes out blank, but I don't have a great fix for that > yet. Currently, I just call printStackTrace or getBaseException, > but I'd rather fix the constructor to avoid them.) This shouldn't be a problem ... > > 3. Change stringifyPair to have a maximum print length. This is sort > of like the printDepth variable Tim proposed, but more limited in > scope. In my current implementation, I have to set the max length > manually (set! Pair.maxlistprint$ 10). This should only happen when nameResults in on .. > > What do you (all) think? 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. I would like to think about another way to do it that does not involve static variables ... Best, ---Tim--- > > Robert > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Jscheme-user mailing list > Jsc...@li... > https://lists.sourceforge.net/lists/listinfo/jscheme-user |
