Hi all, <div><br></div><div>I'd just like to verify I'm on the right track and not blundering into any more obvious mistakes;</div><div><br></div><div>* (default-error-port) gets either errors or the result of exceptions (or more generally display commands).</div>
<div>* exceptions halt execution and people are exceedingly unlikely to intentionally make time pass between the lines of a single error if the error would have multiple lines. </div><div>* default-error-port only gets simple byte-strings, which may contain line-breaks and neither the port nor these strings are aware of the beginning or end of a single message when that message encompasses -for example- a stack trace. There is no way to group these lines by error from the port's perspective looking just at the calls themselves.</div>
<div>*it's likely not such a hot idea for me to re-write the Scheme error handler and register my new one, even though it's cool that we can.</div><div><br></div><div>*Therefore it makes sense to assume that new messages arriving at default-error-port at the same value of "(time)" belong to the same error and that anything arriving later is a new error. If it turns out that "(time)" increments with cpu cycles and not just with frame updates we can safely call anything within a millionth of a second the "same" time, partially because exceptions halt execution, partially because anything that's outside of these assumptions probably means that we are in so much trouble that printing errors to the scene won't help us get out of it anyway, nor make it much worse as the system will probably crash, halt execution or hang before the next frame update anyway. Because of that I also don't really need to think about threading and port-blocking because multiple errors at the same time from multiple threads probably indicates a need for a more serious error-logging system than my latest obsession anyway.</div>
<div><br></div><div>Any serious omissions or blunders yet? Better ideas?</div><div><br></div><div>Thanks,</div><div>Kas.</div>