Custom Query (1030 matches)
Results (772 - 774 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #321 | fixed | Style-warning can't be used from user program | ||
| Description |
Doing (princ (make-condition 'style-warning)) Results in a strange error: Slot CCL::WARNING-TYPE is unbound in #<STYLE-WARNING #x896DB36> Style-warning has no standard slots. |
|||
| #320 | fixed | DEAD-MACPTR referenced in saved currency-converter application | ||
| Description |
It was reported in http://clozure.com/pipermail/openmcl-devel/2008-July/008420.html that a saved CurrencyConverter application (presumably built from the trunk as of roughly the date of that message) references a DEAD-MACPTR during "early application initialization". The current 1.2 version doesn't seem to be affected by this. |
|||
| #319 | fixed | RUN-PROGRAM and stream encodings | ||
| Description |
Many standard programs (many GNU tools, including GCC) produce output in UTF-8 or some other non-empty encoding. CCL::MONITOR-EXTERNAL-PROCESS just interprets each octet it receives as a character-code; ideally, there should be some way of specifying how those octets encode characters. Non-interactive input to external processes sometimes involves writing a lisp stream's contents to a temporary file and passing a descriptor to that file as the subprocess' standard input; similarly, there should be some way of ensuring that that input is encoded according to the external program's expectations. How significant a problem this is may depend on how visible it is, which in turn depends on lots of factors ("locales", terminal/Emacs settings) outside of the lisp's control. It seems desirable that the lisp offer a way of doing (its part of) this right. |
|||
