Re: [racket-users] Text-compatible collapsing of S-expressions
Unfortunately I'm afraid there isn't anything like that currently. Robby On Tue, Oct 20, 2015 at 11:20 AM, JCG wrote: > The DrRacket editor allows me to nicely collapse s-expressions. However, the > format of the file ceases to be useful source text, rendering it useless in > non-current-racket-GUI environments. > > Have I overlooked something that allows me to make use of the code folding > while maintaining compatibility with most other tools that expect normal > source text? > > Thanks in advance. > John > > -- > 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. -- 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] Testing environment variable changes
My concern, and hence the entangled code, was one of compatibility (I'll defer to you guys whether that is a necessity). I'm not sure if I'd want to be able to arbitrarily change current-proxy-servers on the fly (something that has proven difficult, highlighted by the hoops I have to jump through in the tests). On the other hand it's probably not necessary, since proxy servers are a fixed feature of the network configuration. Mostly. Just another 2¢ worth. Tim On 20 October 2015 18:46:05 BST, Jay McCarthy wrote: >I'd want Matthew and Sam's input on this, but I personally don't see >anything wrong with have to parameterize with a promise: > >(parameterize ([c-p-s (delay '())]) ) > >It seems a lot cleaner than having the effectful behavior and using >the parameter like a global variable (which I like to pretend they >aren't.) > >The docs and tests look fine otherwise if the other crew like this >design. > >Jay > >On Mon, Oct 19, 2015 at 10:16 AM, Tim Brown >wrote: >> Jay, >> >> PR#1089 has changes to allow current-proxy-servers and >> current-no-proxy-servers to be loaded from the environment. >> >> I’m doing testing through a sandbox, because I’m not comfortable that >> it’s necessary to spawn a process and Matthew’s suggestion seems to >> make my promises be forced once :-( >> >> I jump through several (maybe too many) hoops to capture from the >> environment. current-proxy-servers is a parameter; what you suggest >> below doesn’t seem to give a parameter that anyone currently using >> c-p-s in their code will be able to (e.g.) “parameterize” against. >> >> I hope this isn’t all too clumsy in the net library. >> >> Regards, >> >> Tim >> >> On 19/10/15 12:56, Jay McCarthy wrote: >>> On Mon, Oct 19, 2015 at 6:16 AM, Tim Brown >wrote: Folks, I’m coming close to writing unit tests for my “URL proxies from the environment” code. Following suggestions from Sam and Jay, I’m considering using a >promise to get and parse the environment variables... along the line of: (define add-no-proxies-from-environment-promise (delay (define no-proxy-from-env (no-proxy-server-entry-from-environment "plt_no_proxy" "no_proxy")) ...)) >>> >>> You can't put define inside the delay. You are delaying the parsing >>> code. Take the exact same parsing code you already have, change the >>> variable name, and wrap it in a delay. Then redefine the old name as >>> force: >>> >>> (define current-proxy (make-parameter (parse-env-vars))) >>> >>> => >>> >>> (define current-proxy-promise (make-parameter (delay >(parse-env-vars >>> (define (current-proxy) (force (current-proxy-promise))) >>> And then, at some point, this promise is forced. Are there any suggestions on how I can test based on one >environment setting, putenv some environment variables then test again? I can do this out of a sandbox, but would this be a usual approach? >>> >>> I suggest you do what I said before, where you have an outer program >>> that sets the env then runs another inner program that just reads >the >>> env and prints it, so the outer one can compare the output. >>> >>> Jay >>> Tim -- 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 -- 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. >>> >>> >>> >> >> >> -- >> 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." > -
Re: [racket-users] Testing environment variable changes
I'd want Matthew and Sam's input on this, but I personally don't see anything wrong with have to parameterize with a promise: (parameterize ([c-p-s (delay '())]) ) It seems a lot cleaner than having the effectful behavior and using the parameter like a global variable (which I like to pretend they aren't.) The docs and tests look fine otherwise if the other crew like this design. Jay On Mon, Oct 19, 2015 at 10:16 AM, Tim Brown wrote: > Jay, > > PR#1089 has changes to allow current-proxy-servers and > current-no-proxy-servers to be loaded from the environment. > > I’m doing testing through a sandbox, because I’m not comfortable that > it’s necessary to spawn a process and Matthew’s suggestion seems to > make my promises be forced once :-( > > I jump through several (maybe too many) hoops to capture from the > environment. current-proxy-servers is a parameter; what you suggest > below doesn’t seem to give a parameter that anyone currently using > c-p-s in their code will be able to (e.g.) “parameterize” against. > > I hope this isn’t all too clumsy in the net library. > > Regards, > > Tim > > On 19/10/15 12:56, Jay McCarthy wrote: >> On Mon, Oct 19, 2015 at 6:16 AM, Tim Brown wrote: >>> Folks, >>> >>> I’m coming close to writing unit tests for my “URL proxies from the >>> environment” code. >>> >>> Following suggestions from Sam and Jay, I’m considering using a promise >>> to get and parse the environment variables... along the line of: >>> >>> (define add-no-proxies-from-environment-promise >>> (delay >>> (define no-proxy-from-env >>> (no-proxy-server-entry-from-environment "plt_no_proxy" >>> "no_proxy")) >>> ...)) >> >> You can't put define inside the delay. You are delaying the parsing >> code. Take the exact same parsing code you already have, change the >> variable name, and wrap it in a delay. Then redefine the old name as >> force: >> >> (define current-proxy (make-parameter (parse-env-vars))) >> >> => >> >> (define current-proxy-promise (make-parameter (delay (parse-env-vars >> (define (current-proxy) (force (current-proxy-promise))) >> >>> >>> And then, at some point, this promise is forced. >>> >>> Are there any suggestions on how I can test based on one environment >>> setting, putenv some environment variables then test again? >>> >>> I can do this out of a sandbox, but would this be a usual approach? >> >> I suggest you do what I said before, where you have an outer program >> that sets the env then runs another inner program that just reads the >> env and prints it, so the outer one can compare the output. >> >> Jay >> >>> Tim >>> >>> -- >>> 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 >>> >>> -- >>> 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. >> >> >> > > > -- > 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&C 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.
[racket-users] Text-compatible collapsing of S-expressions
The DrRacket editor allows me to nicely collapse s-expressions. However, the format of the file ceases to be useful source text, rendering it useless in non-current-racket-GUI environments. Have I overlooked something that allows me to make use of the code folding while maintaining compatibility with most other tools that expect normal source text? Thanks in advance. John -- 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] Re: Probabilities in log-space and rounding errors
Thanks Paolo, yes, I saw that indeed and it is most likely relevant. I was hoping my problem would be sufficiently more specific; in particular, I'd like to detect whether the value being above 0 is likely a rounding error (in which case I can just round it down to 0 again) or likely a mistake on my part in my equations or in their implementation. On Tue, Oct 20, 2015 at 2:24 PM, Paolo Giarrusso wrote: > On Tuesday, October 20, 2015 at 12:15:21 PM UTC+2, Laurent Orseau wrote: > > The built-in log-space arithmetic operations are wonderful. (Thanks so > much Neil!) > > > > > > It sometimes happens that after some log-operations where the result is > very close to 0 that it actually goes slightly above 0 as a result of > floating point errors, and thus is not a log-probability anymore, which > gave me a few headaches. > > > > > > > > One obvious approach is to surround the result with a check, and if it > is positive but not, say, above 1e-8 then round it down to 0, otherwise > raise an exception if positive. > > > > > > But this feels like a hack and I was wondering if there was any "good" > way to ensure that any correct log-space operation remains a > log-probability (i.e., never goes above 0). > > > > > > Thanks, > > Laurent > > If lg+ is involved, this discussion in the docs seems relevant — apologies > if you've seen that already: > > http://docs.racket-lang.org/math/flonum.html#%28def._%28%28lib._math%2Fflonum..rkt%29._lg-%29%29 > ? > > After explaining that a good solution is an open research problem, docs > state: > > Further, catastrophic cancellation is unavoidable when logx and logy > themselves have error, which is by far the common case. [...] There are > currently no reasonably fast algorithms for computing lg+ and lg- with low > relative error. For now, if you need that kind of accuracy, use > math/bigfloat. > > Disclaimer: not an expert here, might well be missing something. > > -- > 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. > -- 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: Probabilities in log-space and rounding errors
On Tuesday, October 20, 2015 at 12:15:21 PM UTC+2, Laurent Orseau wrote: > The built-in log-space arithmetic operations are wonderful. (Thanks so much > Neil!) > > > It sometimes happens that after some log-operations where the result is very > close to 0 that it actually goes slightly above 0 as a result of floating > point errors, and thus is not a log-probability anymore, which gave me a few > headaches. > > > > One obvious approach is to surround the result with a check, and if it is > positive but not, say, above 1e-8 then round it down to 0, otherwise raise an > exception if positive. > > > But this feels like a hack and I was wondering if there was any "good" way to > ensure that any correct log-space operation remains a log-probability (i.e., > never goes above 0). > > > Thanks, > Laurent If lg+ is involved, this discussion in the docs seems relevant — apologies if you've seen that already: http://docs.racket-lang.org/math/flonum.html#%28def._%28%28lib._math%2Fflonum..rkt%29._lg-%29%29 ? After explaining that a good solution is an open research problem, docs state: > Further, catastrophic cancellation is unavoidable when logx and logy > themselves have error, which is by far the common case. [...] There are > currently no reasonably fast algorithms for computing lg+ and lg- with low > relative error. For now, if you need that kind of accuracy, use math/bigfloat. Disclaimer: not an expert here, might well be missing something. -- 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] Probabilities in log-space and rounding errors
The built-in log-space arithmetic operations are wonderful. (Thanks so much Neil!) It sometimes happens that after some log-operations where the result is very close to 0 that it actually goes slightly above 0 as a result of floating point errors, and thus is not a log-probability anymore, which gave me a few headaches. One obvious approach is to surround the result with a check, and if it is positive but not, say, above 1e-8 then round it down to 0, otherwise raise an exception if positive. But this feels like a hack and I was wondering if there was any "good" way to ensure that any correct log-space operation remains a log-probability (i.e., never goes above 0). Thanks, Laurent -- 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.
