From edi@agharta.de Fri Sep 29 18:04:17 2006 From: Edi Weitz To: html-template-devel@common-lisp.net Subject: [html-template-devel] Re: Question about html-template Date: Sat, 30 Sep 2006 00:04:10 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5851035791688459686==" --===============5851035791688459686== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, 29 Sep 2006 17:25:39 -0400, "Jonathon McKitrick" wrote: > I added that to the example code above, but when I get the > backtrace, you can see that EXTERNAL-FORMAT was LATIN-1, even though > in 'create-template-printer' the same keyword arg is UTF-8, UNICODE, > or whatever other value I pass in. No, I can't see it, because I didn't see a backtrace yet. Did you make sure that after changing the external format the template was really read again, i.e. did you clear the template cache? Besides, my /guess/ is that the error is signaled when you're writing to the Araneida stream - something one could probably see in the backtrace. Try to create a test case without Araneida, so you can be sure it doesn't affect the result. --===============5851035791688459686==-- From jmckitrick@gmail.com Fri Sep 29 19:03:24 2006 From: Jonathon McKitrick To: html-template-devel@common-lisp.net Subject: [html-template-devel] Re: Re: Question about html-template Date: Fri, 29 Sep 2006 19:03:20 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5468934115515740973==" --===============5468934115515740973== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 9/29/06, Edi Weitz wrote: > No, I can't see it, because I didn't see a backtrace yet. encoding error on stream # (:EXTERNAL-FORMAT :LATIN-1): the character with code 8226 cannot be encoded. [Condition of type SB-INT:STREAM-ENCODING-ERROR] Restarts: 0: [OUTPUT-NOTHING] Skip output of this character. 1: [ABORT-RESPONSE] Abort this response and answer another request 2: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (SB-INT:STREAM-ENCODING-ERROR # 8226) 1: (SB-IMPL::STREAM-ENCODING-ERROR-AND-HANDLE # 8226) 2: (SB-IMPL::OUTPUT-BYTES/LATIN-1 # " --- html snipped ---
Copyright (c) 2006 Reed Larkey Group Inc.   =E2=80=A2   Website d= esigned by Bartosz Brzezinski
" # :START 0 :END NIL) 6: ((LAMBDA (VALUES)) NIL) 7: ((SB-PCL::FAST-METHOD HTML-TEMPLATE:FILL-AND-PRINT-TEMPLATE (PATHNAME T)) # # #P"web/am01/index.html" NIL (:STREAM #)) 8: ((SB-PCL::FAST-METHOD ARANEIDA:HANDLE-REQUEST-RESPONSE (AJAX::MY-RLG-HANDLER (EQL :GET) T)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (3)) :ARG-INFO (3)) # :GET #) 9: ((SB-PCL::FAST-METHOD ARANEIDA:HANDLE-REQUEST (ARANEIDA:HANDLER T)) # # # #) 10: ((SB-PCL::FAST-METHOD ARANEIDA:HANDLE-REQUEST (ARANEIDA:HANDLER T)) # # # #) 11: ((LABELS ARANEIDA::DO-IT) # #) 12: (ARANEIDA::SERVE-EVENT-HTTP-LISTENER-ACCEPT-ONE-REQUEST #) 13: (SB-IMPL::SUB-SERVE-EVENT NIL 0) 14: (SB-SYS:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL) 15: (SB-IMPL::REFILL-BUFFER/FD #) 16: (SB-IMPL::INPUT-CHAR/UTF-8 # NIL #:EOF-OBJECT) 17: (READ-CHAR # NIL #:EOF-OBJECT #) 18: (READ-CHAR # NIL #:EOF-OBJECT #) 19: (READ-PRESERVING-WHITESPACE # NIL (NIL) T) 20: (READ-PRESERVING-WHITESPACE # NIL (NIL) NIL) 21: (READ # NIL (NIL) NIL) 22: (SB-IMPL::REPL-READ-FORM-FUN # #) 23: (SB-IMPL::REPL-FUN NIL) 24: ((LAMBDA NIL)) 25: ((LAMBDA NIL)) 26: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #) 27: (SB-IMPL::TOPLEVEL-REPL NIL) 28: (SB-IMPL::TOPLEVEL-INIT) 29: ((LABELS SB-IMPL::RESTART-LISP)) > Besides, my /guess/ is that the error is signaled when you're writing > to the Araneida stream - something one could probably see in the > backtrace. Try to create a test case without Araneida, so you can be > sure it doesn't affect the result. Without araneida, the text of the file, including the special characters, prints ok to the slime output buffer, which is in utf-8 encoding. If that matters. --=20 Jonathon McKitrick Independent Software Consultant --===============5468934115515740973==-- From edi@agharta.de Fri Sep 29 19:21:24 2006 From: Edi Weitz To: html-template-devel@common-lisp.net Subject: [html-template-devel] Re: Question about html-template Date: Sat, 30 Sep 2006 01:21:17 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7198861227657860487==" --===============7198861227657860487== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, 29 Sep 2006 19:03:20 -0400, "Jonathon McKitrick" wrote: > encoding error on stream # This is the stream the error was signaled for. > 7: ((SB-PCL::FAST-METHOD HTML-TEMPLATE:FILL-AND-PRINT-TEMPLATE > (PATHNAME T)) # # > #P"web/am01/index.html" NIL (:STREAM # constant string" {128ACFB1}>)) This is the (Araneida) stream you gave as the STREAM keyword argument to FILL-AND-PRINT-TEMPLATE. They're obviously identical. So, you'll have to specify a fitting external format in Araneida. (Don't know how to do that.) > Without araneida, the text of the file, including the special > characters, prints ok to the slime output buffer, which is in utf-8 > encoding. If that matters. It confirms my guess that HTML-TEMPLATE has nothing to do with this problem. Cheers, Edi. --===============7198861227657860487==-- From jmckitrick@gmail.com Fri Sep 29 21:06:20 2006 From: Jonathon McKitrick To: html-template-devel@common-lisp.net Subject: [html-template-devel] Re: Question about html-template Date: Fri, 29 Sep 2006 21:06:16 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7333383256857795582==" --===============7333383256857795582== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 9/29/06, Edi Weitz wrote: > It confirms my guess that HTML-TEMPLATE has nothing to do with this > problem. Well, at least that narrows it down, thanks. The only reason I suspected html-template, is because araneida serves the exact same page without any problem when it is served as a regular static file. It must handle the cases differently. -- Jonathon McKitrick Independent Software Consultant --===============7333383256857795582==--