Submit at 5256.
On Fri, Apr 17, 2009 at 3:03 PM, Lex Spoon wrote:
> On Fri, Apr 17, 2009 at 12:02 PM, Freeland Abbott
> wrote:
> > Right, and I also checked that in fact the errors ought to have been
> caught
> > anyway.
> >
> > Validating the tests, will submit (as I think you okayed) when th
On Fri, Apr 17, 2009 at 12:02 PM, Freeland Abbott wrote:
> Right, and I also checked that in fact the errors ought to have been caught
> anyway.
>
> Validating the tests, will submit (as I think you okayed) when they're
> proven still unchanged.
Yes, please go ahead! -Lex
--~--~-~--~--
Right, and I also checked that in fact the errors ought to have been caught
anyway.
Validating the tests, will submit (as I think you okayed) when they're
proven still unchanged.
On Fri, Apr 17, 2009 at 2:50 PM, Lex Spoon wrote:
> On Thu, Apr 16, 2009 at 7:02 PM, Freeland Abbott
> wrote:
> >
On Thu, Apr 16, 2009 at 7:02 PM, Freeland Abbott wrote:
> On Thu, Apr 16, 2009 at 5:27 PM, Lex Spoon wrote:
>> >> I wouldn't expect TypeExposureComputer to need to report any problems.
>> >> Did you run any any cases where it should? Barring an argument to the
>> >
>> > Not directly, no, but i
On Thu, Apr 16, 2009 at 5:27 PM, Lex Spoon wrote:
> >> I wouldn't expect TypeExposureComputer to need to report any problems.
> >> Did you run any any cases where it should? Barring an argument to the
> >
> > Not directly, no, but it's needed for pass-through to e.g.
> > STOB.shouldConsiderFiel
On Thu, Apr 16, 2009 at 11:13 AM, Freeland Abbott wrote:
> On Tue, Apr 14, 2009 at 1:30 AM, Lex Spoon wrote:
>>
>> Can you verify that the same RPC decisions are being made? For
>> example, does the code size look about the same, and the RPC policy
>> files exactly the same? In particular, I'm
Can you verify that the same RPC decisions are being made? For
example, does the code size look about the same, and the RPC policy
files exactly the same? In particular, I'm worried about the new TICs
being added for things like wildcard types and type parameters. After
a few minutes of poking,
On Thu, Apr 9, 2009 at 6:40 PM, Freeland Abbott wrote:
> Isn't that achieved by the auxiliary warnings? Or do you mean you want them
> all listed in the one error message, or am I misunderstandinging the
> scenario you describe?
Mainly it looks helpful to put it in one place. I picture the
sce
Isn't that achieved by the auxiliary warnings? Or do you mean you want them
all listed in the one error message, or am I misunderstandinging the
scenario you describe?
On Thu, Apr 9, 2009 at 3:26 PM, Lex Spoon wrote:
> Thanks!
>
> The overall report layout is a big improvement. We are going to
Thanks!
The overall report layout is a big improvement. We are going to see
fewer messages where all we can do is decode the messages for people.
I like the three message levels. Cool.
Looking at the report, I still have a slight preference for listing
out the subtypes that were tried if ther
On Wed, Apr 8, 2009 at 2:51 AM, Freeland Abbott wrote:
> On Wed, Apr 8, 2009 at 2:38 AM, Lex Spoon wrote:
>> On Mon, Apr 6, 2009 at 8:48 PM, Freeland Abbott
>> wrote:
>> > There's no special recursion I had to provoke; if you put logging in
>> > instead
>> > of my short circuit, I think DynaTab
On Wed, Apr 8, 2009 at 2:38 AM, Lex Spoon wrote:
> On Mon, Apr 6, 2009 at 8:48 PM, Freeland Abbott
> wrote:
> > There's no special recursion I had to provoke; if you put logging in
> instead
> > of my short circuit, I think DynaTable reconsiders java.lang.String
> > something like 23 times befor
On Mon, Apr 6, 2009 at 8:48 PM, Freeland Abbott wrote:
>> The main thing is that many problems are still logged via TreeLogger
>> and not stored in the ProblemReport. Shouldn't we jump over
>> consistently to the new system rather than have a mix? Are there any
>
> Probably; I was worried that
Thanks, Lex!
On Tue, Apr 7, 2009 at 8:01 AM, Lex Spoon wrote:
> This is a big improvement on the logging. I really like the
> gist of it. I think it should have a second iteration, though.
>
> I reluctantly agree about dropping most all warnings. Once we have a
> way to suppress warnings, the
This is a big improvement on the logging. I really like the
gist of it. I think it should have a second iteration, though.
I reluctantly agree about dropping most all warnings. Once we have a
way to suppress warnings, then we can talk about how to put them back
in.
The main thing is that many
15 matches
Mail list logo
