Custom Query (1630 matches)

I'd appreciate clarification as to whether this is a bug or acceptable.

Basically in ##sys#print, although outchr and outstr both respect the print limit, only outchr can actually exit. Much output is built from multiple calls to outstr so you can get very odd results. Furthermore outstr does not truncate anything under 3 chars so random parts of the output may show up.

Note that if you change outstr to exit when the limit is exceeded, it may not print the final ... depending on the last chunk length. In fact, not truncating when len <= 3 is only appropriate if we're done printing the whole object, which we cannot currently detect.

Below find some examples.

Example 1:

#;1> (current-output-port)
#<output port "(stdout)">
#;3> (##sys#with-print-length-limit 5 (lambda () (print (current-output-port))))
#<out......">

Explanation 1:

#<output port \"        -> #<out...
(stdout)                -> ...
">                      -> ">          (not truncated by outstr, len <= 3)

Example 2:

#;5> (use srfi-4)
#;7> (make-u8vector 5 255)
#u8(255 255 255 255 255)
#;8> (##sys#with-print-length-limit 5 (lambda () (print (make-u8vector 100 255))))
#u8(255...

Explanation 2:

#u8(        -> #u8(
255         -> 255       (exceeds print limit, but length < 3)
<space>     -> ...        (outchr truncates space to ... and exits)

Example 3:

#;9> (##sys#with-print-length-limit 5 (lambda ()
      (print (u8vector->blob (make-u8vector 20 255)))))
#${ffffffffffffffffffffffffffffffffffffffff...

Explanation 3:

The bytes are all printed with outstr (which does not truncate them or exit) and there is no outchr to exit. The entire bytevector is printed, and the final } is truncated to "..." by outchr (!)

Example 4:

#;10> (##sys#with-print-length-limit 5 (lambda ()
        (print (u8vector->blob (make-u8vector 20 0)))))
#${00...

Explanation 4:

Bytes are printed with outstr, but leading zeros are printed with outchr, which detects the limit and bails.

Using things like csc -cflags in shell scripts is mostly unusable, as the quoted include path (-I" ... ") is taken verbatim and not recognized by gcc due to the quotes.

Even though this is fundamentally based on the completely useless and insane shell quoting rules of sh and it's bastards, the code in csc doesn't make it any better, by using various ways of quoting ("qs", "quotewrap", "quote-option") and a tangled labyrinth of variables and thoughtlessly written crap code.

csc needs a complete rewrite. Ideally with lots of stuff removed to makes it less complex (like deployment) and a single point where options are prepared shell and shell-quoted as necessary.

This will necessarily break lots of stuff. It doesn't matter. It has to be.

$ csi -R srfi-4

CHICKEN (c)2008-2011 The Chicken Team (c)2000-2007 Felix L. Winkelmann Version 4.7.0 windows-cygwin-x86 [ manyargs dload ptables ] compiled 2012-12-27 on LNGNYCL-FDB00M1 (CYGWIN_NT-5.1)

; loading library srfi-4 ...

Error: (load-library) unable to load library srfi-4 "No such process"

Call history:

<syntax> (##core#require-extension (srfi-4) #t) <syntax> (##core#begin (##core#begin (##sys#load-library (quote srfi-4) #f)) (##core#undefined)) <syntax> (##core#begin (##sys#load-library (quote srfi-4) #f)) <syntax> (##sys#load-library (quote srfi-4) #f) <syntax> (quote srfi-4) <syntax> (##core#quote srfi-4) <syntax> (##core#undefined) <eval> (##sys#load-library (quote srfi-4) #f) <--

It also fails in 4.8.0 and the Git head.