IIRC, one of your ideas was to expand module code to a typed and an
untyped submodule, and have them provide the same identifiers. Somehow -
doesn't matter exactly for now - untyped clients would get the untyped
identifiers, and typed clients would get the typed identifiers.
I've had some expe
On 12/17/2012 05:48 PM, Robby Findler wrote:
I'm not sure about this change. If I pass in a buggy function, I'm not
sure I'd want the errors to get swallowed.
The errors are almost always division by zero or some similar
mathematical domain error, because plotted functions get sent exact
rati
Begin forwarded message:
> From: Matthias Felleisen
> Subject: Re: [racket-dev] Typed versions of untyped collections
> Date: December 17, 2012 6:44:19 PM EST
> To: Neil Toronto
> Cc: dev@racket-lang.org
>
>
> Okay. I propose we figure out how to allow people programming in Typed
> Racket,
Fine. I give up.
Robby
On Mon, Dec 17, 2012 at 7:55 PM, Sam Tobin-Hochstadt wrote:
> I, perhaps unsurprisingly, disagree. If `listt.rkt` re-provided
> everything from `list.rkt`, then it would continue to work. These
> decisions are made entirely on the basis of the particular identifiers
> in
I, perhaps unsurprisingly, disagree. If `listt.rkt` re-provided
everything from `list.rkt`, then it would continue to work. These
decisions are made entirely on the basis of the particular identifiers
involved -- which module is loaded has nothing to do with it.
But regardless of exactly how type
I'm not sure about this change. If I pass in a buggy function, I'm not sure
I'd want the errors to get swallowed.
How about making the plot but putting a red thing on it (and maybe showing
the error text on mouseover)?
Or maybe making this optional behavior?
Robby
On Mon, Dec 17, 2012 at 6:02
That is what I meant to be asking for. I put too much of what I guess would
be a good approach into my messages, tho. Sorry about that.
Robby
On Mon, Dec 17, 2012 at 5:44 PM, Matthias Felleisen wrote:
>
> Okay. I propose we figure out how to allow people programming in Typed
> Racket,
> and dep
Not an expert, don't even do much in this area much these days.
Historically, I have seen a number of REST URL API patterns, more often
then not (when these things were less tepid than they are now) in the
Semantic Web area (e.g. MS OData) where parens, which as I recall is
allowed by the RFC, are
Okay. I propose we figure out how to allow people programming in Typed Racket,
and deploy two copies of the code without performance overhead for either T or U
code.
_
Racket Developers list:
http://lists.racket-lang.org/dev
On 12/17/2012 04:32 PM, Matthias Felleisen wrote:
On Dec 17, 2012, at 6:10 PM, Neil Toronto wrote:
`plot' is written in untyped Racket. There's no performance problem with typed
plots at all; in fact, using `plot/typed' from TR code ends up checking exactly
the same contracts for the same p
On Dec 17, 2012, at 6:10 PM, Neil Toronto wrote:
>>>
>>> `plot' is written in untyped Racket. There's no performance problem with
>>> typed plots at all; in fact, using `plot/typed' from TR code ends up
>>> checking exactly the same contracts for the same plots. `plot/typed' is
>>> just anoth
On 12/17/2012 03:55 PM, Matthias Felleisen wrote:
On Dec 17, 2012, at 5:43 PM, Neil Toronto wrote:
On 12/17/2012 02:44 PM, Matthias Felleisen wrote:
My understanding is that
-- Neil created a single file P, I believe it is typed
-- he tells you to load plot/typed/ for the typed version
On Dec 17, 2012, at 5:43 PM, Neil Toronto wrote:
> On 12/17/2012 02:44 PM, Matthias Felleisen wrote:
>>
>> My understanding is that
>>
>> -- Neil created a single file P, I believe it is typed
>> -- he tells you to load plot/typed/ for the typed version
>> -- he tells you to load plot/ for t
On 12/17/2012 02:44 PM, Matthias Felleisen wrote:
My understanding is that
-- Neil created a single file P, I believe it is typed
-- he tells you to load plot/typed/ for the typed version
-- he tells you to load plot/ for the untyped version
Somewhere in this arrangement a call in some u
My understanding is that
-- Neil created a single file P, I believe it is typed
-- he tells you to load plot/typed/ for the typed version
-- he tells you to load plot/ for the untyped version
Somewhere in this arrangement a call in some untyped client to a function f
from P will cross a
On 12/17/2012 04:30 AM, Jens Axel Søgaard wrote:
2012/12/17 Ryan Culpepper :
I'd like to make bit-vectors serializable so I can replace sql-bits with
them. I'll deprecate the current sql-bits names but keep them around for a
while.
The issue is that bit-vectors are implemented using fxvectors,
For the purposes of this conversation, I don't think it is fair to stop
after the comma in your sentence, Eric. :)
Robby
On Mon, Dec 17, 2012 at 3:29 PM, Eric Dobson wrote:
> It is getting exactly the same file as R, except there is a special file
> in the TR code that gives types to some bindi
It is getting exactly the same file as R, except there is a special file in
the TR code that gives types to some bindings (all of the ones from
racket). Your new module's bindings are not in this file.
https://github.com/plt/racket/blob/master/collects/typed-racket/base-env/base-env.rkt
On Mon,
I don't understand Matthias's performance comments. If, in TR (require
plot) actually gives me a typed version of the library and in R (require
plot) gives me the untyped version of the library, then I am avoiding the
performance the untyped/typed performance overhead properly. If, on the
other han
At Mon, 17 Dec 2012 15:51:38 -0500, Sam Tobin-Hochstadt wrote:
> On Mon, Dec 17, 2012 at 3:27 PM, Robby Findler
> wrote:
> > I've long thought something along these lines is a good idea, but perhaps
> > what I think is a good idea isn't what Matthias and Sam think is the bad
> > idea.
> >
> > I th
I don't think so. What it has is a declaration that says "don't check the
types."
What I am proposing is
-- check the types
-- and generate an untyped version from this file.
#lang typed/racket #:check-and-generate untyped-foo.rkt
(: x Integer)
(define x 10)
would generate
#lang rack
On Mon, Dec 17, 2012 at 3:27 PM, Robby Findler
wrote:
> I've long thought something along these lines is a good idea, but perhaps
> what I think is a good idea isn't what Matthias and Sam think is the bad
> idea.
>
> I think that it makes sense for 'require' in typed-racket to look in a
> differen
It sounds like an easier solution would be to switch from boxes to a
mutable struct with one field that overrides equal? and hash-code.
Ryan
On 12/17/2012 03:38 PM, J. Ian Johnson wrote:
Short message: is there any chance of getting egal and egal hashes
any time soon?
Longer message: I have
I think TR does have some of this facility already.
Robby
On Mon, Dec 17, 2012 at 2:41 PM, Matthias Felleisen wrote:
>
> When Neil created his library, I proposed that he create one piece of
> source code and 'generate' both the typed and untyped module from it.
>
> If we foresee this kind of l
When Neil created his library, I proposed that he create one piece of source
code and 'generate' both the typed and untyped module from it.
If we foresee this kind of library to become more common, we should probably
provide the capability as an abstraction from TR.
-- Matthias
On Dec 1
Short message: is there any chance of getting egal and egal hashes any time
soon?
Longer message: I have a situation where I key my hashes with immutable
structs, but something they contain has a box that later is updated and never
changed. I'd really like for the struct value before the set-bo
On Dec 17, 2012, at 3:12 PM, Vincent St-Amour wrote:
> It's related to `begin-encourage-inline' from `racket/performance-hint'
> but since `define-inline' depends on `syntax/parse', I'm hesitant to put
> it there.
It sounds like this is where it belongs.
> The new Optimization Coach will rec
I've long thought something along these lines is a good idea, but perhaps
what I think is a good idea isn't what Matthias and Sam think is the bad
idea.
I think that it makes sense for 'require' in typed-racket to look in a
different place than 'require' in untyped racket looks so that one can
wri
At Mon, 17 Dec 2012 15:00:04 -0500,
stamo...@racket-lang.org wrote:
> b715a6f Vincent St-Amour 2012-12-14 11:39
> :
> | Add define-inline.
> |
> | Drop-in replacement for define that guarantees inlining.
> :
> M collects/meta/props | 2 ++
> A collects/unstable/inline.r
Just now, David Vanderson wrote:
> No guru here, but my experience has been that every url encoder is
> slightly different - I don't think there's a broad consensus on edge
> cases. I'd say go for it.
The problem is not just being different from others, it's the
possibility of old code breaking..
No guru here, but my experience has been that every url encoder is
slightly different - I don't think there's a broad consensus on edge
cases. I'd say go for it.
On 12/17/2012 06:59 AM, Eli Barzilay wrote:
For many people there is a constant source of annoyance when you
copy+paste doc URLs in
20 minutes ago, Sam Tobin-Hochstadt wrote:
> On Mon, Dec 17, 2012 at 12:59 AM, Neil Toronto wrote:
> >
> > On 12/16/2012 06:41 PM, Eli Barzilay wrote:
> >>
> >> 10 minutes ago, Neil Toronto wrote:
> >>>
> >>> I think I'd rather have a convention in Typed Racket that (require foo)
> >>> imports `fo
On Mon, Dec 17, 2012 at 12:59 AM, Neil Toronto wrote:
>
> On 12/16/2012 06:41 PM, Eli Barzilay wrote:
>>
>> 10 minutes ago, Neil Toronto wrote:
>>>
>>> I think I'd rather have a convention in Typed Racket that (require foo)
>>> imports `foo/typed' when it exists.
>>
>>
>> +14. I think it came up
p.s. Also the current docs[1] say this in the second paragraph:
The URI encoding uses allows a few characters to be
represented as-is: a through z, A through Z, 0-9, -,
_, ., !, ~, *, ', ( and ).
But this in the final sentence:
In additon, since there appear to be some brain-dea
Although I'm hardly a web "expert", I think net/uri-codec is currently
a little confusing.
I get the impression that it was originally written prior to 2005,
because the detailed introduction talks only about RFCs 1738 and
2396.[1]
It looks like perhaps functions such as uri-path-segment-encode w
Eric,
I incorporated you changes into
http://code.google.com/r/sergeykhorev-vim-mzscheme/source. Can you try it
on Mac?
Bram,
>
> Please let me know what I should include in the distribution. The patch
> was missing changes to configure.in.
>
I will send you a cumulative patch once it is test
I love this idea, since it also (at least impliticly) demonstrates how
to work with Racket's GUI layer, which could also be useful to new users.
Matthias Felleisen writes:
> We had a freshman two years back who implemented an ftp server. I think he
> (and others like him) would have enjoyed a tu
For many people there is a constant source of annoyance when you
copy+paste doc URLs into a markdown context as with stackoverflow and
others. The problem is that these URLs have parens in them and at
least in Chrome, the copied URL still has them -- and because markdown
texts use parens for URLs
On 2012-12-17 09:54:36 -0500, Matthias Felleisen wrote:
> It has serious performance implications for untyped modules that
> require plot -- and these should not be hidden.
My understanding (possibly wrong), was that the typed submodule would
only be required from another typed module in this prop
On Dec 17, 2012, at 12:59 AM, Neil Toronto wrote:
> On 12/16/2012 06:41 PM, Eli Barzilay wrote:
>> 10 minutes ago, Neil Toronto wrote:
>>> I think I'd rather have a convention in Typed Racket that (require foo)
>>> imports `foo/typed' when it exists.
>>
>> +14. I think it came up in the past, b
We had a freshman two years back who implemented an ftp server. I think he (and
others like him) would have enjoyed a tutorial on ftp (server and client). It
may belong into the systems tutorial -- Matthias
On Dec 16, 2012, at 10:19 PM, Chen Xiao wrote:
> Hi, I use the new ftp client api(no
Sergey Khorev wrote:
> Looks good except one thing: you really wouldn't want to gc environment
> (see MZ_GC_CHECK) before registering it with MZ_REGISTER_STATIC.
>
> BTW are there any guarantees that MZ_REGISTER_STATIC doesn't trigger
> garbage collection?
Please let me know what I should incl
2012/12/17 Ryan Culpepper :
> I'd like to make bit-vectors serializable so I can replace sql-bits with
> them. I'll deprecate the current sql-bits names but keep them around for a
> while.
>
> The issue is that bit-vectors are implemented using fxvectors, which are
> serializable, but simply serial
43 matches
Mail list logo
