[Openmcl-devel] Reducing interpreter output (to verbose)

[Frank Sonnemans]

Thanks for pointing out the existence of the *print-length* variable, works
like a charm. This will save me from quite a few emacs/ilisp crashes and
long wait periods.

Thanks again for the support.

Regards,


Frank


On 03-2-5 17:44, "Gary Byers" <gb at clozure.com> wrote:

> 
> 
> On Fri, 2 May 2003, Frank Sonnemans wrote:
> 
>> Is there any way in openmcl to reduce the amount of data printed. I am
>> calling some functions from the read-eval loop, which return a large list of
>> structures. Currently openmcl prints the entire list, which takes very long
>> when working with emacs and ilisp.
>> 
>> I believe that ACL would only print the first couple of elements of such a
>> list to avoid this problem. Question is how to emulate that feature in
>> openmcl.
>> 
> 
> One can control this in any CL implementation via the variables *PRINT-LEVEL*,
> *PRINT-LENGTH*, etc.  The standard specifies that the initial value of these
> variables is NIL; I have mixed feelings (not too strong either way) as to
> whether the repl should establish its own bindings of standard printer
> control variables.  In OpenMCL, entering a break loop does something like
> (WITH-STANDARD-IO-SYNTAX-PLUS-A-FEW-SPECIAL-CASES ...), but you can do:
> 
> ? (setq *print-length* 5)
> 5
> ? (produce-very-long-list)
> (FIRST FIVE ELEMENTS OF A ...)
> 
> 
> If the REPL was binding *PRINT-LENGTH* (to something like
> CCL:*LISTENER-PRINT-LENGTH*) for you, then you could achieve the same
> effect by setting that other variable at the appropriate time.  In that
> case, you might see something like:
> 
> ? (setq ccl:*listener-print-length* 5)
> 5
> ? (print (produce-very-long-list))
> (FIRST FIVE ELEMENTS OF A LIST THAT\'S SO LONG THAT I DON\'T FEEL LIKE TYPING
> THE WHOLE THING)
> (FIRST FIVE ELEMENTS OF A ...)
> 
> or you might see other behavior, depending on when that binding took place.
> 
> It's clear that the user should have control over this, since any
> inappropriate printing behavior should be the user's fault.
> 
> 
>> Regards,
>> 
>> 
>> Frank
>> 
>> 
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>> 
>> 
> 


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel