Yes, I agree.
At Thu, 3 Jan 2013 22:45:14 -0600, Robby Findler wrote:
> Sounds great to me!
>
> Robby
>
>
> On Thu, Jan 3, 2013 at 10:20 PM, Danny Yoo wrote:
>
> > On Thu, Jan 3, 2013 at 8:01 PM, Robby Findler
> > wrote:
> > > Is the documentation and testing sufficient?
> >
> > There's no d
Why not normalize this at the other end (ie, normalize the provided
string as well as the actual method) so that "GET" as well as "get"
will work?
Sam
On Fri, Jan 4, 2013 at 7:45 AM, wrote:
> jay has updated `master' from aa5f2e7875 to c07ff948ee.
> http://git.racket-lang.org/plt/aa5f2e7875..
On Thu, Jan 3, 2013 at 11:09 PM, Neil Toronto wrote:
> (In particular, platform-independent Index and Fixnum types scare me.)
Platform-independent Fixnum is easy -- just if |x| <= 2^30, then x is
a fixnum on all platforms Racket supports. [1]
Index is a little trickier, since it's not documented
At Thu, 03 Jan 2013 21:09:52 -0700, Neil Toronto wrote:
> 1. Implementation of `sqrt': most Single-Float-Complex inputs yield
> Float-Complex outputs. The type is sane, but the behavior isn't:
>
> > (sqrt 1.0f0+5.2f0i)
> - : Single-Flonum-Complex
> 1.7741590586312472+1.465482
The programmer's input is not a string. It is a match pattern, so you can
use 'or', '_', etc.
On Fri, Jan 4, 2013 at 6:30 AM, Sam Tobin-Hochstadt wrote:
> Why not normalize this at the other end (ie, normalize the provided
> string as well as the actual method) so that "GET" as well as "get"
> w
Ah, that makes sense. You could think about providing match patterns
for each of the HTTP methods, in that case -- people might be less
confused by that than strings.
On Fri, Jan 4, 2013 at 10:30 AM, Jay McCarthy wrote:
> The programmer's input is not a string. It is a match pattern, so you can
At Thu, 03 Jan 2013 21:09:52 -0700,
Neil Toronto wrote:
>
> I thought it would be helpful to find the most precise types possible
> for numeric functions. I wrote a program that infers them using a few
> thousand representative argument values, which have been chosen to
> exhibit underflow, ove
This is of tangential interest only; the site
https://sites.google.com/site/pydatalog/pypl/PyPL-PopularitY-of-Programming-Language
does what appears to be a better job of evaluating language popularity than
TIOBE--among other things, they use google trends rather than search result #s,
as Joe M
This looks like an instance of the problem Neil reported on Monday.
I'll discuss Neil's solution with Sam.
Vincent
At Thu, 3 Jan 2013 18:47:56 +0100,
Jens Axel Søgaard wrote:
>
> Ignore the previous example. Here is the example again, now
> with correct usage of case-lambda. The for/sum proble
On 01/04/2013 10:38 AM, Vincent St-Amour wrote:
At Thu, 03 Jan 2013 21:09:52 -0700,
Neil Toronto wrote:
I thought it would be helpful to find the most precise types possible
for numeric functions. I wrote a program that infers them using a few
thousand representative argument values, which have
2013/1/3 Neil Toronto :
> I solved it by not using `for/sum' and writing this ridiculous function for
> the recursive base case and the initial values in `x':
>
> (: zero-of (case-> (Real -> Real)
> (Number -> Number)))
> (define (zero-of x) 0)
>
> Fortunately, it should ge
On 01/04/2013 01:27 PM, Jens Axel Søgaard wrote:
2013/1/3 Neil Toronto :
I solved it by not using `for/sum' and writing this ridiculous function for
the recursive base case and the initial values in `x':
(: zero-of (case-> (Real -> Real)
(Number -> Number)))
(define
That's interesting. It's such a different picture than for example GitHub:
https://github.com/languages
We should hire Nate Silver to make sense of it. :)
http://fivethirtyeight.blogs.nytimes.com/author/nate-silver/
On Fri, Jan 4, 2013 at 12:49 PM, John Clements
wrote:
> This is of tan
2013/1/4 Neil Toronto :
> I gave `for/sum:' a little thought recently, though, and I couldn't think of
> how to make it work without annotations. Maybe you'll have more success. I'm
> less motivated to fix `for/sum:' than you are. :D
Here is my attempt. The only problem, is that when type checking
On Jan 4, 2013, at 6:35 PM, Jens Axel Søgaard wrote:
> Here is my attempt. The only problem, is that when type checking
> fails, the set! expression is blamed instead of user code.
That is the key problem.
_
Racket Developers list:
http://lists.racket-lang.org/dev
2013/1/5 Matthias Felleisen :
>
> On Jan 4, 2013, at 6:35 PM, Jens Axel Søgaard wrote:
>
>> Here is my attempt. The only problem, is that when type checking
>> fails, the set! expression is blamed instead of user code.
>
>
> That is the key problem.
I know which user expression it is, body-expr, I
I've caught a bug with regards to the source locations constructed by
cfg-parser, but I don't know quite what the right patch is. I do know
what the _wrong_ patch is, so maybe that will help? :)
Here's what I've kludged so far:
https://github.com/dyoo/ragg/commit/5ef0e007d4b80e95a20824a2005
This version blames the correct expression.
The error message itself is however in terms of the expanded
code and I see why that is a key problem.
/Jens Axel
for-sum.rkt
Description: Binary data
_
Racket Developers list:
http://lists.racket-lang.org/dev
18 matches
Mail list logo
