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
Hi Folks!
Exciting news today. Rather than attempting to describe everything here, let
me point you to some blog posts that hopefully you will find interesting:
GWT 1.6 and friends:
http://googlewebtoolkit.blogspot.com/2009/04/introducing-gwt-16-and-friends.html
Seriously this time, the new lang
One real issue:
- I really think toStringVerbose() and toStringSimple() should be private
methods. (Making them static and taking the object as a parameter would be
less bad also.) We have to be super careful about this particular class
because it's so magic. Any instance methods you add effect
On Tue, Apr 7, 2009 at 4:12 PM, Lex Spoon wrote:
> > 5178: Also tightened up the recursive method slightly, and managing the
> > "computed" set better. This works because once a class transitions from
> > hasClinit -> !hasClinit, there's no possible way it can ever go back.
>
> Small problem: I
Thus, then.
2009/4/6 Scott Blum
> On Mon, Apr 6, 2009 at 9:16 AM, Scott Blum wrote:
>
>> return JavaScriptObject.class.desiredAssertionStatus() ?
>> toStringVerbose()? : toStringSimple();
>>
>
> (typo, obviously)
> return JavaScriptObject.class.desiredAssertionStatus() ? toStringVerbose()
> :
Author: j...@google.com
Date: Tue Apr 7 12:01:27 2009
New Revision: 5194
Modified:
trunk/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
Log:
Add support for logging response headers, and support multiple headers
with the same name with Jetty.
Patch by: t.broyer
Review by: j
@Bob: Kudos for fixing this instead of just observing the problem and moving
on. You rock for setting this kind of example.
On Tue, Apr 7, 2009 at 1:52 PM, wrote:
>
> Author: b...@google.com
> Date: Tue Apr 7 10:47:05 2009
> New Revision: 5193
>
> Modified:
>trunk/dev/core/src/com/google/gw
> 5176: All this does is tweak the debug output of the Java AST. JSNI methods
> have proper indentation in an AST dump now (I was using AST dumps to verify
> incremental correctness.)
LGTM.
> 5177: Fairly self-explanatory; added the state to JReferenceType, but kept
> it in JTypeOracle at firs
Thanks for the pointers. Changing the set-property to
set-configuration-property is working fine now.
On Tue, Apr 7, 2009 at 1:41 PM, BobV wrote:
> On Tue, Apr 7, 2009 at 1:35 PM, Eric Ayers wrote:
> > [ERROR] The specified property 'name' is not of the correct type; found
> > 'ConfigurationPr
Author: b...@google.com
Date: Tue Apr 7 10:47:05 2009
New Revision: 5193
Modified:
trunk/dev/core/src/com/google/gwt/dev/cfg/ModuleDefSchema.java
Log:
Fix error message to include the property name when a binding vs.
configuration property mismatch occurs.
Patch by: bobv
Review by: jgw (
On Tue, Apr 7, 2009 at 1:35 PM, Eric Ayers wrote:
> [ERROR] The specified property 'name' is not of the correct type; found
> 'ConfigurationProperty' expecting 'BindingProperty'
ModuleDefSchema line 794 is producing a bad error message, that should
have included the name of the property, not the
Hi Bob,
[ERROR] The specified property 'name' is not of the correct type; found
'ConfigurationProperty' expecting 'BindingProperty'
This message came up in my project when we migrated from incubator
ImmutableResourceBundle to the new trunk ClientBundle a. By trial and
error, here's the offendin
Author: sp...@google.com
Date: Tue Apr 7 09:53:21 2009
New Revision: 5192
Modified:
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java
Log:
Removes some code accidentally committed along with r5191.
Modified:
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic
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
Oh, and... as much as I hate to suggest it, we will probably need some
way to suppress the deprecation warning.
Maybe:
Where ignore-deprecation is optional and defaults to false. I'm
tempted to say that ignore-deprecation="true" on a non-deprecated
module produces a warning, just to discourage
I have to say I'm with Isaac on this one. I think it's best to keep things
as simple as possible, and to keep the documentation in one place wherever
possible. There's nothing stopping anyone from putting URLs in the
explanatory text if they want, but I wouldn't want to have to do that in the
defau
I'd vote for a consistent message supplied by the compiler/hosted mode
and freeform text provided by the module developer. I think that works
fine for JavaDoc @deprecated. URLs and the names of successor modules
can be included in the freeform text when appropriate. Unless you're
planning to plug
He Miroslav,
Thanks for the tip:
> listeners to a container class that also implements the listener. Then
I considered it as well, it's kind of categorizing the listeners, but
doesn't work in my case.
Le me explain: the screen consists of all kind o wizard kind of
screens that the user can bro
18 matches
Mail list logo
