After upgrading to trunk my app stopped working. In hosted mode in
don't get any error msg, but the hosted mode browser stays empty. When
compiling I get this error:
[ERROR] Unexpected
java.lang.NoSuchFieldError:
reportUnusedDeclaredThrownExceptionIncludeDocCommentReference
at
Hi Dan,
That sounds to be a really good step in the right direction.
This mecanisms seems to cover all the nominal use cases that we would face
regarding the different o/r mapping impl.
I would just make a few remarks :
1) When you call all the setXX() methods when the object is sent back to the
Hi,
continuing from
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/c65457fa4df351c1
. Sorry for the added garbage could have known better to post it here
in the first place.
I see generators as en extension to client code therefore I expect
them to behave a bit like
This is after ant clean?
On Wed, Jul 22, 2009 at 5:14 AM, dflorey daniel.flo...@gmail.com wrote:
After upgrading to trunk my app stopped working. In hosted mode in
don't get any error msg, but the hosted mode browser stays empty. When
compiling I get this error:
[ERROR] Unexpected
Hi Scott,
Gin uses reflection because it reuses the heavy lifting from Guice, which is
not GWT-aware.
Seems like both issues could be resolved if generators were loaded in the
client code ClassLoader. Is there a technical or philosophical problem with
doing so? I can understand it might not be at
@Scott: Hasn't there been a subtle shift in this regard? With GWT 1.5,
didn't we conclude that loading classes at least for annotations would make
the most sense?
I think now that we have enhanced the CCL, for deRPC, to delegate to grey
area classes that aren't strictly in the client space, maybe
John Tamplin wrote:
On Tue, Jul 21, 2009 at 9:51 AM, mescali...@gmail.com
mailto:mescali...@gmail.com mescali...@gmail.com
mailto:mescali...@gmail.com wrote:
so I did I.
I repeated the above steps today.
ant (1.7.1) run up to some point, then I get this error:
[gwt.javac]
John Tamplin wrote:
Can you svn up in the tools directory? It sounds like perhaps you are
missing the more recent JDT.
btw,
feder...@gentoo64 ~/gwt-trunk/tools $ ls -1 lib/eclipse/jdt*
lib/eclipse/jdt-3.1.1.jar
lib/eclipse/jdt-3.1.1-src.zip
lib/eclipse/jdt-3.3.1.jar
But there is no CCL when running the compiler. We never go through the
trouble of constructing a client class loader environment for generators
to access, they just run in the system class loader. Supposing we did build
a client classloader and run the generators there, how would generators then
This would definitely be a killer feature.
A common API for something like Web Workers and App Cache (maybe
wrapper for http://code.google.com/p/webstorageportabilitylayer/) that
can seamlessly switch talk to Gears or native HTML 5 implementation
would be very nice. I think it's a lot easier to
This patch took me hours to absorb. It sounds simple to modify the
compiler to emulate stacks, but understanding precisely where the stack
updates need to happen is difficult!
The implementation is very clean. There are just two nits in the
comments.
The line number recording looks like it
I get this error when gwt-compiling my app. gwt trunk compiles just
fine.
On Jul 22, 4:13 pm, Scott Blum sco...@google.com wrote:
This is after ant clean?
On Wed, Jul 22, 2009 at 5:14 AM, dflorey daniel.flo...@gmail.com wrote:
After upgrading to trunk my app stopped working. In hosted
http://gwt-code-reviews.appspot.com/47816/diff/1/5
File dev/core/src/com/google/gwt/dev/js/JsStackEmulator.java (right):
http://gwt-code-reviews.appspot.com/47816/diff/1/5#newcode174
Line 174: * exitingEarly $stackDepeth = stackIndex - 1;
There's a typo here: stackDep_e_th
On 2009/07/22
I'm suggesting that ant clean and recompiling trunk from scratch might fix
this. Also, make sure you svn up your tools directory, just in case.
On Wed, Jul 22, 2009 at 11:27 AM, dflorey daniel.flo...@gmail.com wrote:
I get this error when gwt-compiling my app. gwt trunk compiles just
fine.
Update:
- When gwt-compiling using the Eclipse-plugin I get the error pasted
above.
- When starting hosted mode the browser page is empty with no errors
- When compiling from hosted mode browser everything works fine
- Launching compiled app in external browser works fine
On Jul 22, 5:27 pm,
I don't think getting this thing wrapped up will take too much more
work.
http://gwt-code-reviews.appspot.com/47816/diff/1/5
File dev/core/src/com/google/gwt/dev/js/JsStackEmulator.java (right):
http://gwt-code-reviews.appspot.com/47816/diff/1/5#newcode132
Line 132: // $stack[$stackDepth =
I think it is helpful if we distinguish between optional and mandatory
features.
If GWT would come with a set of widgets or library components that
behave slightly different on different browsers this might not be bad
in general. I'm aware that the general approach of GWT is to write
software
Hmmm, very strange. After deleting all the *.jdt.prefs* files in
my .settings directory everything works fine again.
No idea, never created these files but they seem to be harmful under
certain circumstances ;-)
On Jul 22, 5:37 pm, dflorey daniel.flo...@gmail.com wrote:
Update:
- When
Hey guys.
Imho having Generators in the CCL club is icing on the cake...very
cool but not really essential.
I can confirm using JavaRebel solves both problems (generator code
change, and gin module changes, @Inject added etc). For the time being
I think this is a reasonable compromise for
http://gwt-code-reviews.appspot.com/47816/diff/1/5
File dev/core/src/com/google/gwt/dev/js/JsStackEmulator.java (right):
http://gwt-code-reviews.appspot.com/47816/diff/1/5#newcode184
Line 184: * the stack depth.
Oh, right, the pop for a return has to be placed in the enclosing
finally, and it
Brian, do you know if Guice allows you to specify a ClassLoader other than
the active one?
In principle, I would be okay with GeneratorContext providing a special
other ClassLoader to generators that contained only client code; it would
have exactly what TypeOracle does.and just be another way to
Reviewers: bobv,
Description:
Freelend (fabbott) ran our test suite with assertions enabled, and found
an assertion failure in AsyncFragmentLoader. Curiously, the code likely
works in a browser, due to arrays not being bounds checked when
compiling to JavaScript, but certainly the code is not
Ready for another look. Major changes:
- No special handling for throw statements.
- Force all try/finally to be try/catch/finally to ensure that a
caught JavaScriptException would have the correct stack data as well as
code running in the finally block.
- Locations always record when
LGTM.
http://gwt-code-reviews.appspot.com/54803
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
LGTM.
http://gwt-code-reviews.appspot.com/47816/diff/3008/1037
File dev/core/src/com/google/gwt/dev/js/JsStackEmulator.java (right):
http://gwt-code-reviews.appspot.com/47816/diff/3008/1037#newcode68
Line 68: private class Bootstrap extends JsVisitor {
Bootstrap took me a few minutes to figure
Should running a web-mode test case always turn on the emulated stack
trace code?
You would get stack traces entries like:
Unknown.bx(YourClass.java:1234) regardless of which browser you're on
and the type of exception, Java-derived or native. The cost is code
bloat: 64k versus 108k for the
On Wed, Jul 22, 2009 at 4:46 PM, BobV b...@google.com wrote:
Should running a web-mode test case always turn on the emulated stack
trace code?
You would get stack traces entries like:
Unknown.bx(YourClass.java:1234) regardless of which browser you're on
and the type of exception,
On Wed, Jul 22, 2009 at 4:57 PM, Scott Blum sco...@google.com wrote:
On Wed, Jul 22, 2009 at 4:46 PM, BobV b...@google.com wrote:
Should running a web-mode test case always turn on the emulated stack
trace code?
Would always on mean that it generates code even for browsers that have
native
Revision: 5774
Author: amitman...@google.com
Date: Wed Jul 22 18:24:34 2009
Log: Temporary commit, which comments out 3 assertions I believe are flaky,
to find
out how long tests take in batching mode. Will continue to investigate these
commented out assertions.
Patch by: amitmanjhi
29 matches
Mail list logo
