IRC channel logs
2023-07-12.log
back to list of logs
<lloda>i can't debug it tho - there's no backtrace. I don't understand the control flow in call-with-truncating-output-string :-\ <lloda>tbh i don't understand why the error is there. Why isn't that just str <wingo>lloda: ok so here is the deal. when i first rewrote pretty-print i added call-with-truncating-output-string <wingo>the idea being, say you write an enormous string to an output port; really the port should detect when you have written too many chars and stop the producer from making more chars <wingo>it does so by aborting to a prompt. but it collects the chars that were written into a string. this will be more chars than the limit, because that's how you know you've passed the limit, right? <wingo>so that was the expectation when you would get to truncate-string, that the partial string that was written was at least as big as the limit <wingo>but then as an afterthought i said also "well really it should also be on the same line" <wingo>hence the port-line check; it is 0 until the first newline is written <wingo>but in that case perhaps the partial string is less than the limit <wingo>that's the error that's triggering. probably that error check should be replaced by something that checks if the string has a newline in it, and if so it truncates to the first line of the string <wingo>if there's no newline the error check could still be there but it's not doing much for us ;) <lloda>i'm having trouble isolating the failure case atm <wingo>well. somehow you had a truncated-print of something with a newline <wingo>which may have been during the backtrace <wingo>because the backtrace uses truncated-print <lloda>i'm having to fix pk to see anything bc it seems current-output-port is being redirected in pretty-print, although i can't see where <lloda>oh there's also warn i guess that would have worked <lloda>so if you don't allow newlines, it's normal that you fail with a short string so i would just remove the (error ...). Either print str or the bail out string "#". But why aren't newlines allowed? allow-newline? is always #f <lloda>port-line > 0 seems fine for are-there-newlines check, but i don't see why they can't be allowed <wingo>well, truncated-print is really about single-line output <wingo>it doesn't have the whole pretty-print logic to choose how to lay out multiple lines <lloda>would be convenient to have the option :-\ <wingo>but what would you want it to do for a list? use multiple lines, right? <wingo>like `(a a a a a ...many... a a a ) <wingo>so really what you would be looking for would be the logic in pretty-print, but truncating, sometimes. <lloda>well my use case is a struct that uses a custom printer so all truncated-print has to do is clip the string if exceeds width (length before the patch) <lloda>so if truncated-print always prints at most one line, it is less useful as a generic repl limiter <lloda>i accept that's not what it's meant for, but i don't know what else i could use <wingo>so you want to limit the repl output to truncate instead of wrapping. probably i guess you would want to do so by putting … in the last column or so? <lloda>that shows that the output was truncated so yes <wingo>in that case i would write a custom text output port that wraps the stdout and just stops sending characters to the inferior port when there are too many, and only starts outputting again when newline is written or so <wingo>and use that as the repl output port <lloda>what if an object prints as x\n a million times? i want that truncated all the same <flatwhatson>you could count lines output as well as chars output, to truncate lines at a max length and also truncate the entire output at max lines <flatwhatson>i guess byte-sink->output-port is basically a custom output port <lloda>i think i'll go with the custom port and ditch ~@y <lloda>sometimes you do need to look into what you're printing however, and truncate the pieces rather than the whole. i think i'll miss that <lloda>shouldn't call-with-truncating-output-string close the port on failure as well <wingo>lloda: it could but there is really no point tbh, the only reason it is closed on success is to force output <wingo>like what would closing the port do for you. not much, i would think <lloda>using custom port for the repl worked fine btw