I'm trying to reduce the startup overhead imposed by Typed Racket, and
I'm running into a mystifying problem
If you look here at https://gist.github.com/3098628 you'll see two
small files, `tnull.rkt` and `rlnull.rkt`. The former is an empty
file written in `typed/racket/base`. The latter is an
I get about the same results, and if I try
time racket -W debug -t tnull.rkt
time racket -W debug -t rlnull.rkt
then I see substantially more GC time for the former.
I think the difference is GC variance due to the order that modules get
loaded. If I try
time racket -W debug -l racket/base -
On Thu, Jul 12, 2012 at 11:49 AM, Matthew Flatt wrote:
>
> I think the difference is GC variance due to the order that modules get
> loaded. If I try
>
> time racket -W debug -l racket/base -t tnull.rkt
> time racket -W debug -l racket/base -t rlnull.rkt
>
> then the times are extremely close, a
Robby, could you share w/ us why you don't like the tool designation for the
Optimization Coach and the Future Visualizer? Or if you can't articulate the
dislike for 'tool', can you say what a better word is?
Eli, could you share w/ us why
tool/optimization-coach .. with everything in it fo
On Thu, Jul 12, 2012 at 1:14 PM, Matthias Felleisen
wrote:
>
> Robby, could you share w/ us why you don't like the tool designation for the
> Optimization Coach and the Future Visualizer? Or if you can't articulate the
> dislike for 'tool', can you say what a better word is?
- I think the creat
On Jul 12, 2012, at 2:19 PM, Robby Findler wrote:
> On Thu, Jul 12, 2012 at 1:14 PM, Matthias Felleisen
> wrote:
>>
>> Robby, could you share w/ us why you don't like the tool designation for the
>> Optimization Coach and the Future Visualizer? Or if you can't articulate the
>> dislike for 't
On 2012-07-10 13:39:37 -0600, Matthew Flatt wrote:
> > - combinator-parser [...]
> > - test-box-recovery [...]
> > - tex2page [...]
>
> These seem fine with me, because I think they have no current users.
>
> We've had enough versions with the test-box recovery tool that if
> someone really needs i
On Thu, Jul 12, 2012 at 1:28 PM, Matthias Felleisen
wrote:
>
> On Jul 12, 2012, at 2:19 PM, Robby Findler wrote:
>
>> On Thu, Jul 12, 2012 at 1:14 PM, Matthias Felleisen
>> wrote:
>>>
>>> Robby, could you share w/ us why you don't like the tool designation for
>>> the Optimization Coach and the
At Thu, 12 Jul 2012 13:08:21 -0400, Sam Tobin-Hochstadt wrote:
> On Thu, Jul 12, 2012 at 11:49 AM, Matthew Flatt wrote:
> >
> > I think the difference is GC variance due to the order that modules get
> > loaded. If I try
> >
> > time racket -W debug -l racket/base -t tnull.rkt
> > time racket -W
20 minutes ago, Robby Findler wrote:
> On Thu, Jul 12, 2012 at 1:28 PM, Matthias Felleisen
> wrote:
> >
> > On Jul 12, 2012, at 2:19 PM, Robby Findler wrote:
> >
> >> On Thu, Jul 12, 2012 at 1:14 PM, Matthias Felleisen
> >> wrote:
> >>>
> >>> Robby, could you share w/ us why you don't like the to
An hour and a half ago, Matthias Felleisen wrote:
>
> Eli, could you share w/ us why
>
> tool/optimization-coach .. with everything in it for this software
> tool/future-visualizer .. with everything in it for this software
>
> is a bad idea? Perhaps I am old but I do see a lot of value in a
I spent some time working with taxonomies and ontologies, and switched
to generally preferring that the permanent names for things be in a flat
namespace, and that any organizations (e.g., hierarchical) be separate,
indirect, and more fluid.
One possible exception is when there is a strong, ex
On Jul 12, 2012, at 3:53 PM, Eli Barzilay wrote:
>
> I think that the single directory is ultimately easier to deal
> with, even when there is a package system that can keep track of
> files in different places. There are *many* advantages that you can
> get out of it. To name a few:
> -
On Jul 10, 2012, at 11:33 PM, Eli Barzilay wrote:
> On Saturday, Matthias Felleisen wrote:
>>
>> The more general idea is that there is an alternative design space
>> out there where you want 'boxes' that signal errors when touched by
>> strict functions. You need these every time you want trans
On Thu, Jul 12, 2012 at 3:20 PM, Matthew Flatt wrote:
> Of course, we usually optimize for long-term performance, and it's
> sometimes tricky to balance short-term and long-term performance. Does
> the difference that you see still matter when a program does something
> useful?
If I run the Shoot
Jay's recent commit message, which should probably have been sent as an inquiry
to the list.
Begin forwarded message:
> Changing contracts on gl-context<%> and applying it to the gl-context% object.
> |
> | I updated and noticed that this was now failing because interface
> | contracts are no
On 2012-07-12 19:38:44 -0400, Matthias Felleisen wrote:
> > | I updated and noticed that this was now failing because interface
> > | contracts are not check structurally (any more?).
I don't think this is a case of checking structurally or not. It is
not valid, for example, for the following beha
Ya I was about to forward it too but was distracted by kids.
Sent from my iPhone
On 2012/07/12, at 19:39, Matthias Felleisen wrote:
>
> Jay's recent commit message, which should probably have been sent as an
> inquiry to the list.
>
>
> Begin forwarded message:
>
>> Changing contracts on gl-co
On Thu, Jul 12, 2012 at 7:57 PM, Asumu Takikawa wrote:
> On 2012-07-12 19:38:44 -0400, Matthias Felleisen wrote:
>> > | I updated and noticed that this was now failing because interface
>> > | contracts are not check structurally (any more?).
>
> I don't think this is a case of checking structural
This is a bad backwards incompatibility. I'll fix it.
At Thu, 12 Jul 2012 19:38:44 -0400, Matthias Felleisen wrote:
>
> Jay's recent commit message, which should probably have been sent as an
> inquiry
> to the list.
>
>
> Begin forwarded message:
>
> > Changing contracts on gl-context<%> a
On 2012-07-12 20:19:34 -0400, Jay McCarthy wrote:
> First, the interface wasn't even being associated with the class. This
> was the source of my structural/not comment.
Ah, I see. This interface was actually defined with `class->interface`
before and I forgot to update the class to use the new se
On Thu, Jul 12, 2012 at 3:57 PM, Matthias Felleisen
wrote:
> All I regret is that we have a very shallow structure now, and I think it
> would have helped if we had stuck to about a dozen or so categories after all.
I think the "modern" experience is that a flat hierarchy (or perhaps
one with fo
22 matches
Mail list logo
