1) A generator uses the SystemCL. Not recommended because it won't see
changes in client code unless hot-replace is working.
2) A generator uses TypeOracle. Recommended; changes are picked up on
refresh.
3) A generator uses the TypeOracleClassLoader. Useful for interacting with
On Fri, Jul 24, 2009 at 6:01 AM, Alen Vrecko alen_vre...@yahoo.com wrote:
1) A generator uses the SystemCL. Not recommended because it won't see
changes in client code unless hot-replace is working.
2) A generator uses TypeOracle. Recommended; changes are picked up on
refresh.
3)
I think it'd be reasonable. Patches welcome, particularly as you have the
reproduction case. ;-)
On Fri, Jul 24, 2009 at 10:33 AM, mescali...@gmail.com mescali...@gmail.com
wrote:
ok
sorry for all this bugspam
I finally solved this issue.
it turns out that Gentoo has many ant tasks
in GIN's case we could then do
ctx.getTypeOracleClassLoader().useSystemFor().startingWith
(com.google.gwt.inject.).create(); and not worry about any
surprises.
That seems, complicated and unnecessary. If you really, really need the
SystemCL version of a class, you'd just access it
Hey all,
We've been struggling with the issue of RPC forward/backward
incompatibility for a little while and I thought I'd bring it to the
list for discussion.
As some of you know, one of our use-cases for GWT is embedding the
compiled JS in a Firefox extension. Unfortunately, the
Reviewers: jgw,
Description:
Description:
=
WindowImplIE needs to embed a script tag on the outer window in order to
sink events on the outer window from within an iframe, which means we
need the init event methods as strings. Previously, we did this by
writing a JSNI black that
This patch is an improvement either way, but it doesn't fix the tests.
It looks like various tests are causing an infinite loop. Looking into
it now.
http://gwt-code-reviews.appspot.com/51814
--~--~-~--~~~---~--~~
On 2009/07/24 17:27:00, jlabanca wrote:
This patch is an improvement either way, but it doesn't fix the tests.
It looks
like various tests are causing an infinite loop. Looking into it now.
LGTM.
http://gwt-code-reviews.appspot.com/51814
One thing this setup won't do is to minify the JS.
http://gwt-code-reviews.appspot.com/51814
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Reviewers: scottb,
Message:
Review requested.
Description:
Rhino's Node.getLineno() only returns useful data for JS statements.
This patch changes GWT's JsParser to provide statement-level line number
resolution for JsExpressions.
Please review this at http://gwt-code-reviews.appspot.com/51816
Mostly LGTM.
http://gwt-code-reviews.appspot.com/51816/diff/1/2
File dev/core/src/com/google/gwt/dev/js/JsParser.java (right):
http://gwt-code-reviews.appspot.com/51816/diff/1/2#newcode159
Line 159: SourceInfo toReturn = program.createSourceInfo(lineno,
parent.getFileName());
Why can't we use
http://gwt-code-reviews.appspot.com/51816/diff/1/2
File dev/core/src/com/google/gwt/dev/js/JsParser.java (right):
http://gwt-code-reviews.appspot.com/51816/diff/1/2#newcode159
Line 159: SourceInfo toReturn = program.createSourceInfo(lineno,
parent.getFileName());
Will change.
http://gwt-code-reviews.appspot.com/51816/diff/1/2
File dev/core/src/com/google/gwt/dev/js/JsParser.java (right):
http://gwt-code-reviews.appspot.com/51816/diff/1/2#newcode159
Line 159: SourceInfo toReturn = program.createSourceInfo(lineno,
parent.getFileName());
BTW: I didn't necessarily mean
Reviewers: robertvawter_google.com,
Description:
Description:
===
JsStackEmulator#baseName() does not handle urls from the file system
(eg. file:whatever). This can result in an infinite loop in
StackTraceCreator.
Fix:
Fixed the parser based on bob's suggestion.
Please review
LGTM
http://gwt-code-reviews.appspot.com/51817
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Something wrong with my windows env. I rebuilt successfully on a
different windows env.
On Jul 24, 9:24 am, Freeland Abbott fabb...@google.com wrote:
Huh.
Well, if you look in dev/core/build.xml, you should see the rules for
building alldeps.jar; I'd edit that block heavily to add some more
On 24-Jul-09, at 6:39 PM, BobV wrote:
I have a design wave going on about how to add this to the new RPC
implementation. Here's a cruddy copy-and-paste of the current state
of the document.
Bob, this is awesome!
Is the plan to land this as part of deRPC, or is this a future feature
that
Also, will this be supported on methods themselves? For instance, can
I mark a new method parameter as @Optional so that older clients don't
need to provide it? Conversely, could we remove a parameter from a
method and still support clients sending data with the old signature?
I could go
The deRPC code went into trunk a week or so ago, and no initial fires
have been reported. I'd like to get folks on GWTC to give it a
shakedown.
Quickstart (for vanilla configurations):
- Inherit com.google.gwt.rpc.Rpc in your gwt.xml file
- Change your remote service interfaces to extend
On 24-Jul-09, at 9:11 PM, BobV wrote:
Also, will this be supported on methods themselves? For instance,
can
I mark a new method parameter as @Optional so that older clients
don't
need to provide it? Conversely, could we remove a parameter from a
method and still support clients
20 matches
Mail list logo
