[racket-users] Converting a list to a syntax object non-recursively?
Is there any way to create a new syntax object containing a list without recursively converting the list’s elements to syntax objects as well? I have some code where I wanted to use syntax objects as a convenient mechanism to tag arbitrary datums with source location information (and they will be used as syntax objects later), but that code expects datum->syntax followed by syntax-e to return the original datum, which obviously isn’t the case if datum->syntax recursively wraps datums as well. Is there any way to construct a new syntax object without this recursive behavior? If not, is there any reason something like that does not exist? Nothing intuitively comes to mind as a reason why that would violate someone to violate any guarantees, unless some code for some reason always assumes syntax objects will always be recursively wrapped. To be perfectly clear: I am not intending to use this “shallow syntax object” as the result of a syntax transformer, or even during expansion at all. These are syntax objects I’m manipulating purely at read-time, not expansion-time. Alexis -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: Running racket on a #lang-less module-less file?
William's remark is spot on about my use-case. There exists a language that wasn't initially designed with racket in mind, but could easily be a racket #lang. To interop with code already written in this language, I wanted an easy way to run files that don't have the #lang line. If I were designing the language Racket-first, I wouldn't need this feature. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] HTTP Headers use byte->string/utf-8
On Fri, May 6, 2016 at 11:49 AM, Tim Brownwrote: > > 1. I think Eli points out in issue where \277 and \276 are not ci=? >to each other. No -- my comment there is about \277 and \277 (itself), which are neither `bytes-ci=?` nor not because the implementation assumes that the two bytes to compare are both in utf-8 and therefore we get an exception instead of an answer. The source of the comment is that this was (I think) at some point in unstable, as a candidate to move to racket/bytes (hence my comment about the memory requirement, which is relevant in that context). [BTW, looking at that SO answer and the RFC it seems to me that latin-1 is wrong too for the values, which should remain opaque...] -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] HTTP Headers use byte->string/utf-8
You should not be using request-headers or request-bindings if you don't want them to be interpreted as UTF-8. The documentation for web-server/http/bindings explicitly says, "We recommend against their use, but they are provided for compatibility with old code." Jay On Fri, May 6, 2016 at 11:49 AM, Tim Brownwrote: > Sorry, Jay; I’ve just tested this and I hit: > > Servlet (@ /...) exception: > bytes->string/utf-8: string is not a well-formed UTF-8 encoding > string: #"timmeh \351" > > context...: > > /usr/local/racket/extra-pkgs/web-server/web-server-lib/web-server/http/bindings.rkt:9:7 >loop > > /usr/local/racket-6.5/share/racket/collects/racket/contract/private/arrow-val-first.rkt:357:18 > > > This is in web-server/http/bindings.rkt (where I count no less than five > `bytes->string/utf-8`s); and I really do think that that should be > bytes->string/latin-1 both because it covers all 256 code points AND > it is what HTTP asks for. > > That would fix my issue (I hope). > > > > Also, looking at byte-upcase / bytes-ci=? in > web-server-lib/web-server/private/util ; can I make a couple of > suggestions: > > 1. I think Eli points out in issue where \277 and \276 are not ci=? >to each other. I’m not sure of his specific example; because in >Latin-1, they are "3/4" and an upside down "?" -- which I wouldn’t >personally consider ci=? But further up the character set; I would >say that \311 E' and \350 e' ARE ci=? : but only in Latin-1. > >So should there not be a byte-upcase/latin-1 and byte-upcase/ascii-7 >and a bytes-ci=?/latin-1 and bytes-ci=?/latin-1 > > 2. Since this is implemented in a web-server / HTTP context (and for the >reasons I set out above w.r.t. the bindings); should util.rkt not use >bytes-ci=?/latin-1 ? > > > Since I have an ISO-8859-1 table in front of me: > > (define (byte-upcase/latin-1 b) > (if ((or (<= 97 b 12) ; ascii-7: a-z range >(<= 224 b 246) ; latin-1: a` to o" > ; latin-1: -:- is not the lower case of x >(<= 248 254)) ; latin-1: o/ to |p > (- b 32)) ; 97 - 65 = 32 >b)) > > > On 05/05/16 18:46, Jay McCarthy wrote: >> Hi Tim, >> >> I consider this an error. The Web server tries to avoid interpreting >> anything as UTF-8 unless asked by the servlet. Header comparison >> incorrectly converted to UTF-8 and I just pushed a fix. Can you verify >> that it works now with your workload? >> >> Jay > - D 64:33 > > > -- > Tim Brown CEng MBCS > > City Computing Limited · www.cityc.co.uk > City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB > T:+44 20 8770 2110 · F:+44 20 8770 2130 > > City Computing Limited registered in London No:1767817. > Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE > VAT No: GB 918 4680 96 -- Jay McCarthy Associate Professor PLT @ CS @ UMass Lowell http://jeapostrophe.github.io "Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great." - D 64:33 -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] HTTP Headers use byte->string/utf-8
Sorry, Jay; I’ve just tested this and I hit: Servlet (@ /...) exception: bytes->string/utf-8: string is not a well-formed UTF-8 encoding string: #"timmeh \351" context...: /usr/local/racket/extra-pkgs/web-server/web-server-lib/web-server/http/bindings.rkt:9:7 loop /usr/local/racket-6.5/share/racket/collects/racket/contract/private/arrow-val-first.rkt:357:18 This is in web-server/http/bindings.rkt (where I count no less than five `bytes->string/utf-8`s); and I really do think that that should be bytes->string/latin-1 both because it covers all 256 code points AND it is what HTTP asks for. That would fix my issue (I hope). Also, looking at byte-upcase / bytes-ci=? in web-server-lib/web-server/private/util ; can I make a couple of suggestions: 1. I think Eli points out in issue where \277 and \276 are not ci=? to each other. I’m not sure of his specific example; because in Latin-1, they are "3/4" and an upside down "?" -- which I wouldn’t personally consider ci=? But further up the character set; I would say that \311 E' and \350 e' ARE ci=? : but only in Latin-1. So should there not be a byte-upcase/latin-1 and byte-upcase/ascii-7 and a bytes-ci=?/latin-1 and bytes-ci=?/latin-1 2. Since this is implemented in a web-server / HTTP context (and for the reasons I set out above w.r.t. the bindings); should util.rkt not use bytes-ci=?/latin-1 ? Since I have an ISO-8859-1 table in front of me: (define (byte-upcase/latin-1 b) (if ((or (<= 97 b 12) ; ascii-7: a-z range (<= 224 b 246) ; latin-1: a` to o" ; latin-1: -:- is not the lower case of x (<= 248 254)) ; latin-1: o/ to |p (- b 32)) ; 97 - 65 = 32 b)) On 05/05/16 18:46, Jay McCarthy wrote: > Hi Tim, > > I consider this an error. The Web server tries to avoid interpreting > anything as UTF-8 unless asked by the servlet. Header comparison > incorrectly converted to UTF-8 and I just pushed a fix. Can you verify > that it works now with your workload? > > Jay - D 64:33 -- Tim Brown CEng MBCSCity Computing Limited · www.cityc.co.uk City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB T:+44 20 8770 2110 · F:+44 20 8770 2130 City Computing Limited registered in London No:1767817. Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE VAT No: GB 918 4680 96 -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.