Re: [gwt-contrib] tests
On Wed, Jun 20, 2012 at 6:48 AM, Eric Ayers zun...@google.com wrote: Now, the problem with diagnosing this is that the file is set to be deleted on exit. So after the program exits, you can't see how ridiculously huge the file might have been. To test that theory, you could try commenting out this line to test it, or you could keep track of the # of bytes written and spit it out when this exception occurs. Isn't there a way to disable this with a system property or command-line flag? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] tests
I have had periodic failures like this that go away when I re-run it. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] tests
On Sat, Jun 9, 2012 at 10:26 PM, Stephen Haberman stephen.haber...@gmail.com wrote: So, is ant test supposed to run to completion on a reasonable dev machine? I don't know that I've ever had it work, and so don't generally run it. I don't run it that often (we have a distributed test farm to run everything in parallel at work), but my recollection is it took about 50min to finish on a 16G / dual Opteron desktop at work (yes, it is old) and about 40min on my home desktop (12G RAM, Core i7). I don't know that I have run it in the last few months. But I was feeling guilty tonight, so tried again, went away for awhile, and came back to my RAM (12gb) and CPUs both pegged. And lots of these in the console: [junit] Exception in thread pool-1-thread-569 java.lang.NullPointerException [junit] at com.google.gwt.dev.util.DiskCache.transferToStream(DiskCache.java:187) [junit] at com.google.gwt.dev.util.DiskCacheToken.writeObject(DiskCacheToken.java:91) At the very least, that suggests there is a bug in the DiskCache code that lets an NPE leak out. Do you have enough disk space? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Re r11031 running a static GWT app directly from the code server
On Fri, Jun 8, 2012 at 2:26 PM, Brian Slesinsky skybr...@google.com wrote: I'm definitely interested in getting simple servlets to run in Super Dev Mode in a way similar to classic Dev Mode. I haven't investigated, so I don't know if it's better to reuse the existing implementation or write a fresh one and leave behind some crud. I don't think we want to try too hard to provide a servlet container that works for arbitrary web apps. Typically it's better to use a separate process for anything complicated and avoid classpath/class loader issues. For example, for App Engine, you'll want to be using its own dev_appserver command. But perhaps I'm biased by how we do things within Google? For my personal app, I launch my jetty-based server separately, and use -noserver for DevMode. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: safari isOrHasChild impl
On Thu, Jun 7, 2012 at 4:40 PM, Thomas Broyer t.bro...@gmail.com wrote: AFAICT, Safari 2 is no longer part of the supported browsers list, so my take on it would be to clean-up the codebase and remove every safari2-specific path. There are overall a lot of cleanup (remove event listeners for instance, which have been deprecated for several *years*) +1 -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Use shared.GWT to avoid ClassNotFoundExceptions (issue1722803)
On Thu, May 31, 2012 at 12:58 PM, Rajeev Dayal rda...@google.com wrote: Seeing test failures when I patch this in. See attachment. I remember seeing that before (and unrelated to the GWT.create changes) -- are you sure you are up to date? If you are, then we need to track down the bad JSNI reference and see what is up with it. I can do that this afternoon if you don't get to it before then. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] com.google.gwt.core.client.GWTBridge
On Tue, May 29, 2012 at 4:43 PM, Jimo jponei...@gmail.com wrote: I rebuilt GWT with the latest in the source tree and am now getting a class not found exception for com.google.gwt.core.client.GWTBridge in my servlet RPC implementation. Should that class exist in gwt-servlet.jar? When I add it to that jar file, the class not found exception goes away. [It looks like GWTBridge and some related classes changed earlier this month.] Do you know what class is referencing c.g.g.client.GWTBridge? There is a shared version (which the client one derives from) that should be there, but referencing client code in the server is dangerous. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] com.google.gwt.core.client.GWTBridge
On Wed, May 30, 2012 at 7:09 PM, Jens jens.nehlme...@gmail.com wrote: You could integrate Macker (http://innig.net/macker/index.html) into your GWT ant script and define a rule that checks for any reference from *.server.* to *.client.* packages. May be helpful to detect such violations. There is a ton of stuff we would have to clean up first, and I think we will get that for free by splitting it up into smaller jar's -- you just don't even put the client stuff on the classpath for the server. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RFC: i18n APIs as they are made available to shared code
On Fri, May 11, 2012 at 1:10 PM, Brian Slesinsky skybr...@google.comwrote:
This isn't going to work because the threadlocal isn't set up yet, and
even if it were, each HTTP request could have a different locale. If
you create a new Foo for each request, you could just remove static
and call GWT.create() once for each request (or possibly multiple
times if you have multiple Foo per request). But if you create Foo
once and call a method on it, then it's more awkward.
That's a good point. We will need to work out the best practices and
carefully document it, since most client-side code tends to use something
similar to this.
This is exactly what Guice/Gin Providers are for. You could do this:
class Foo {
interface MyMessages extends Messages {
@DefaultMessage(Your {0} is on fire)
String onFire(@Example(car) String item);
}
@Inject
private final ProviderMyMessages msg;
}
Then call msg.get().onFire() instead of msg.onFire().
Without providers, I guess you'd have to call
GWT.create(MyMessages.class) at each call site, and this just fetches
from the ThreadLocal. It's more verbose.
Right, the compiler would generally inline those (unless they were complex
plural/gender messages), but we would probably need to get better caching
for the server-side case.
How interoperable are Gin/Guice? Could the shared code look exactly the
same, and use Gin for the server and Guice for the client?
Just as a style thing, maybe we can try to keep the factory getter
methods shorter?
Instead of:
localeInfo.getNumberFormatFactory().getCurrencyFormat(USD);
How about:
locale.numbers().getCurrencyFormat(USD);
Ok.
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] RFC: i18n APIs as they are made available to shared code
The existing i18n APIs have evolved over a long period of time as needs arose, so there is wide variety in the APIs. For example, some of them you get an instance by calling GWT.create (eg Messages), others have singleton instances (eg CurrencyList), others have static factory methods (eg NumberFormat), others you get via LocaleInfo (eg LocalizedNames), and some just have static methods (eg LocaleInfo.getLocaleCookieName). Some of these approaches make it hard to mock out for testing. Something I have been working on for a while and expect to land in the next couple of months is making all of the GWT APIs available to shared and server-side code. This will enable sharing of translation resources and to ensure consistency between server-rendered and client-rendered content, and also gives us the opportunity to reconsider the API as we move it from c.g.g.i18n.client to c.g.g.i18n.server -- we can make the shared API the way we want it and make the client API wrappers around that for compatibility. Of course, if we make major changes it will make it harder to move existing code to the new APIs, so we need to not make changes just for the sake of making changes. One change which I am pretty certain about is splitting the methods which deal with multiple locales out of LocaleInfo into a new class that relates to the set of locales available to the app, locale cookies/query parameters/etc, leaving LocaleInfo dealing only with a single locale. LocaleInfo would then be obtained via GWT.create (which is now usable on the server), and we would have the future option of using the Locales class to get LocaleInfo instances for other locales that the app was built for. The main question is how to get instances of locale-specific classes/interfaces appropriate to the currently executing locale. Ideally, we would choose one method and use it for everything, though there is room for doing something different if justified. Here are the options as I see them: 1. Move all factory methods to LocaleInfo. For example, CurrencyList.get() would be replaced with localeInfo.getCurrencyList(). This is a bit more problematic for cases like NumberFormat that have a lot of static factory methods, as the LocaleInfo API will get cluttered and the names will get long. This also means that if we add multi-locale support, you get the various APIs the same way, by calling methods on a LocaleInfo instance. 2. Like #1, but for the cases where there are lots of static factory methods, introduce a factory class. Something like: NumberFormat nf = localeInfo.getNumberFormatFactory().getCurrencyFormat(USD); 3. Just use GWT.create on the affected items. This would imply the creation of factory objects as in #2 where there was more than a single no-arg contructor. The advantage is there is no central directory of locale-specific APIs that has to be extended whenever something new is added (though this might hurt discoverability), and things are more consistent (just use GWT.create for everything i18n-related). However, this also means that if we ever add multi-locale support, code will have to do something fundamentally different, since you would need to be able to specify which locale you want a CurrencyList for, etc. Personally, I am leaning towards #2 -- anyone feel strongly about some other option? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RFC: i18n APIs as they are made available to shared code
On Thu, May 10, 2012 at 7:23 PM, Brian Slesinsky skybr...@google.comwrote: Could you explain how GWT.create() works on the server? How does it decide what to create? Could we configure it to call into Guice? See http://code.google.com/p/google-web-toolkit/source/detail?r=10968 for the implementation of server-side GWT.create. Essentially, you register server-side class instantiators, and it should be easy to configure it to ask Guice for the instance to use. The default configuration knows about Localizable subtypes, where it looks for pre-existing implementations for the current locale, and as a last resort, simply trying to create an instance using the default constructor. A few thoughts, from a Guice point of view: - Client-side code assumes a single locale. Server-side code that runs within an HTTP request might assume that the environment provides a locale (request scope in Guice), and that seems like the most likely place to share code. Some server-side code might work with multiple locales (in particular the code allowing you to switch locales), but that's unlikely to be shared with clients. See GwtServletBase.javahttp://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/core/server/GwtServletBase.java?spec=svn10968r=10968 -- basically, it looks for the URL parameters and cookies configured for selecting the locale and sets them in thread-local property values for the request. It should be easy to hook in Guice request scope into a similar mechanism. - If you can reach all i18n factories from LocaleInfo then declared dependencies aren't going to be very interesting. Code that uses i18n depends on LocaleInfo and code that doesn't, doesn't. More fine-grained dependencies means more verbosity and more code changes when you need to use another i18n factory, but it's also better documentation of which code uses what. So the current situation is pretty hard for mocking, relying on static factory methods. Ie, CurrencyList.get() -- there is no way to substitute another implementation without doing classloader tricks. If all of that is reached via LocaleInfo, then you only need to mock a way to get LocaleInfo, which would be simply adding a class instantiator to return your mock instead of the real one. I don't know how much this matters. Are there any big data files that we don't need to load into the JVM if we aren't using certain parts of a locale? It could be divided up that way, but I'm not sure how useful that will be. Your build step would have to exclude the parts you didn't want (or we would have to break out separate jars/targets), and then it would just be wrong if you later needed those files. On the client, it doesn't matter because GWT strips out dead code. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RFC: i18n APIs as they are made available to shared code
On Thu, May 10, 2012 at 9:08 PM, Brian Slesinsky skybr...@google.comwrote:
Okay, so GwtServletBase along with GWT.create() is a new,
undocumented, minimal server-side environment that nobody knows about
yet. (I'm not seeing any usages in google3.)
Correct, but since it was just committed Tuesday and the only real support
is has is for Localizable, I wouldn't expect any uses yet.
I'd expect most server-side code to be using other frameworks (e.g. Guice
or Spring.)
Sure, and that's fine, but that can't be used in shared code. The intent
here is to allow code like:
class Foo {
interface MyMessages extends Messages {
@DefaultMessage(Your {0} is on fire)
String onFire(@Example(car) String item);
}
private static final MyMessages msg = GWT.create(MyMessages.class);
...
}
To be used in code shared between the client and server without any
changes, and producing the same result in either case.
But if we don't use GWT.create(), this doesn't matter for most
server-side code as long as someone writes the code to inject a
LocaleInfo. If we do use GWT.create() in shared code then we also need
to make it work in whatever environment they're using. Using
GwtServletBase as an example, it looks like you'd have to set up
ServerGWTBridge in your environment, probably in some ServletFilter
that fetches providers from Guice (or whatever) and puts them into
thread locals.
Yes.
So certainly GWT.create() is better than a static method, but getting
factories from method calls on LocaleInfo is probably more convenient
than GWT.create() from a server point of view.
Which is a long way of saying I like #2.
Ok, so you are good with introducing new factory objects where there are
lots of static factory methods now, rather than moving them all up to
LocaleInfo as individual methods?
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fix this-window confusion in DevMode (issue1620805)
On Tue, May 8, 2012 at 2:38 PM, stephen.haber...@gmail.com wrote: We had to roll this back because it broke a bunch of test code Cool, I saw that, was wondering what had happened. I think that this patch is in the right, but the test code was not carefully written Good, I was hoping you thought the patch was still right. I would add that since internal test code relies on being able to call through null values in some cases, it seems likely that external code we can't test also does so. So, this would have to be treated as a breaking change. That doesn't mean that we can't do it, just that it needs to be carefully considered and communicated about when it lands. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fix this-window confusion in DevMode (issue1620805)
On Tue, May 8, 2012 at 3:23 PM, stephen.haber...@gmail.com wrote: True, although my assumption is that since this is a DevMode-only behavior (null becomes window), we're actually doing everyone a favor by fixing the behavior to match web mode, and in doing so highlighting previously-missed/potential bugs in their application code/test code. So, it seems like the consideration could be less careful than, say, a semantics change where people might still want the previous behavior. (I'm assuming for this change that the previous behavior really isn't all that desirable, once you know about it/update your code/tests accordingly...) I agree, but asking anyone to have to make changes in working code as a consequence of upgrading increases the cost, even if they are good changes. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Serialization of Final Fields in RPC (issue1380807)
On Fri, May 4, 2012 at 12:15 PM, rda...@google.com wrote: Was debating whether this one should go in for GWT 2.5, but my inclination is to skip it. Please let me know if anyone feels strongly about this. http://gwt-code-reviews.**appspot.com/1380807/http://gwt-code-reviews.appspot.com/1380807/ It has been waiting a few years, another one won't hurt. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Serialization of Final Fields in RPC (issue1380807)
On Fri, May 4, 2012 at 2:44 PM, stephen.haber...@gmail.com wrote: it looks like there's disagreement on the implementation My recollection is that zhuyi's original patch used a static variable to store the do we serialize final fields or not state. However, the variable is a per-module configuration, so putting it as static could have lead to non-determinism if multiple modules were getting compiled at the same time. I took zhuyi's work, killed the static, and instead changed various methods to pass around the context so that serialize final fields or not could be turned on/off at the right place. zhuyi incorporated that into this patch, so, no statics, so I think we're good to go. (Correct me if I'm wrong, John.) My only thought was that I wanted to go further and *always* serialize final fields, which would be cleaner as we could avoid the somewhat complex conditional behavior, but that was deemed to much of a breaking change. I haven't looked at Zhu's work in a year and a half, but my recollection was the static issue was the only problem (and perhaps needing more tests, but I don't remember when that was relative to later development). -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add support for soft permutations to SingleScriptLinker. (issue1678803)
On Thu, Apr 5, 2012 at 5:01 PM, mdemp...@google.com wrote: On 2012/04/05 20:44:10, jat wrote: It seems like there should be some test for this to make sure it keeps working. Could you extend SingleScriptLinkerTest to make sure that it handles collapsing soft permutations? Sure. Can you give me some guidance on how I should go about setting that up though? I'm pretty clueless about GWT unit tests. :( Actually, I can't think of an easy way to do it without mocking up a ton of stuff. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Synchronous RPC
On Tue, Feb 28, 2012 at 12:02 PM, Deepak Patil deepakpati...@gmail.comwrote: any comments about this ? Sorry, digging through the generated JS code is hard to follow, and there are library functions referenced but not included that would help clarify a few things. If I understand correctly, the gist is to pass a state variable to each callback, and by that value it knows which piece of code to execute, is that correct? That would also mean having to wrap all calls from non-generated code, which is what I assume those missing library functions do. If that is correct, it is an interesting approach, though it does have some cost. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Synchronous RPC
On Mon, Feb 20, 2012 at 4:05 AM, Deepak Patil deepakpati...@gmail.comwrote:
(Author of openwaf.com)
Using asynchronous RPC (GWT.runAsync) forces developer to split there code
int two parts. It becomes difficult if you want to do some sequential RPC .
BTW, runAsync is totally different from RPC -- it is about code splitting,
so only the code needed for the initial app is downloaded in the initial
download.
I understand Single threaded browser architecture wont allow us to easily
execute synchronous RPC.
For example to get time from the server using RPC code looks time below
TimerService.getTime(new AsyncCallbackString() {
public void onSuccess(String result) {
lblASync.setText(lblASync.getText()+Result
1:+result+br/);
}
public void onFailure(Throwable caught) {
}
});
Here response code goes in onSuccess method.
Just for example we want to get the server time twice synchronously. code
will look like this
**
*TimerService.getTime(new AsyncCallbackString() {*
public void onSuccess(String result) {
lblASync.setText(lblASync.getText()+Result 1:+result+br/);
* TimerService.getTime(new AsyncCallbackString() {*
public void onSuccess(String result) {
lblASync.setText(lblASync.getText()+Result
1:+result+br/);
}
public void onFailure(Throwable caught) {}
});
} public void onFailure(Throwable caught) {} });
Code looks complicated now. Now imagine if we can write simple code like
below.
lblSync.setText(lblSync.getText()+Result
1:+TimerService.getTime()+br/);
lblSync.setText(lblSync.getText()+Result
2:+TimerService.getTime()+br/);
Which does the same thing of the code above this.
I found a workaround for this. We can simulates synchronous RPC using
asynchronous http requests. Where program is *logically* blocked till you
receive any response from the server.
This is well tested for statements like for,while,if else.
Here compiler takes care of the generating some additional code which will
return from the function when RPC is made and resume the code at
appropriate location where it was blocked.
For more details please check http://openwaf.com/ExRPCSyncAsync.jsp
http://openwaf.com
The web site doesn't give implementation details, but I assume it is by
rewriting the synchronous call to be continuation-passing. Ie:
function f() {
block1;
x1 = asyncCall1();
block2;
while (asyncCall2()) {
block3;
}
return retval;
}
gets rewritten to:
function f(retCallback) {
block1;
asyncCall1(function(x1) {
block2;
loop = function(val) {
if (val) {
block3;
asyncCall2(loop);
} else {
retCallback(retval);
}
};
asyncCall2(loop);
}
}
The problem with doing this in general is that basically every call in the
app has to be rewritten in this form (if any of them might ever call an
async method), and you wind up with stack depth problems unless the VM has
tail-call elimination (which JS doesn't).
Chaining of async calls is awkward, and I don't think it is a solved
problem yet.
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: LinkedHashMap.clone()
On Sat, Jan 28, 2012 at 12:07 PM, Irfan Adilovic irfanadilo...@gmail.comwrote:
I would like to submit unit tests that test the fixes, but I cannot
bring the tests to fail with the unfixed version of LinkedHashMap (and
LinkedHashSet, which is affected in the same way, btw).
try {
dstMap = (LinkedHashMapString, String) srcMap.clone();
// fail(LinkedHashMap clone is castable to LinkedHashMap);
} catch (ClassCastException cce) {
fail(LinkedHashMap clone is not castable to LinkedHashMap);
return; /* dstMap wasn't cloned successfully */
}
By uncommenting the commented fail() above, I can verify that I am
running the correct test, as it fails there, but it should actually
fail on the second fail() in this snippet. The tested code acts as if
the .clone() implementation is already correct in LinkedHashMap/Set.
Because of this I cannot prove with a unit test, that my fix has an
effect.
Are you running your test in DevMode? In DevMode, you are using your JVM's
real JRE classes, not GWT's emulation. So, you need to run in prod mode
(ie, compiled to JS) to test GWT's JRE emulation.
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the missing plugins/xpcom/prebuilt/ff90/include/IOOPHM. (issue1631804)
On Fri, Jan 27, 2012 at 6:17 PM, Chris Conroy con...@google.com wrote: It's generated from xpidl, no? So it's just been unchanging since 36. Not guaranteed forever, but might be worth making it a build rule for if GECKO_VERSION in some range, then use this one. If it changes, code will have to update behind a build rule anyways. The file is tiny - I don't think it is worth the hassle. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Improvement to HistoryImpl
On Mon, Jan 23, 2012 at 9:06 PM, ALAA MURAD alaamu...@gmail.com wrote: I already did a test project and I replicated the class and modified it, in my test both history token and changed event received the correct token. Yes, but the question is if there is existing code out there that will notice that the URL has not been updated at the time its history change event handler is called. Given the length of time that this code has been out there, it seems likely that somebody would have written code that cares. Also, your change simply moves where the time is taken, it doesn't remove it. I agree it is nice to fire the event sooner, but I don't know if that is valuable enough to risk breaking years-old code. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] LinkedHashMap.clone()
On Mon, Jan 23, 2012 at 10:51 PM, Irfan Adilovic irfanadilo...@gmail.comwrote: I have a feeling the code was added with the intention to be enabled, but never was, as nobody came to actually implementing LinkedHashMap.clone(). What's the official situation on this? Should I file a bug and submit a patch? I no longer remember the details of that change, but in general clone() is not supported in GWT, which is why there is no Object.clone() method (see http://code.google.com/p/google-web-toolkit/issues/detail?id=1843 for more details). Particularly types can and do have Cloneable where it makes sense, so I think it is reasonable to implement it correctly here. If you want to file a patch for LinkedHashMap, see http://code.google.com/webtoolkit/makinggwtbetter.html#contributingcode -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Improvement to HistoryImpl
On Mon, Jan 23, 2012 at 5:00 PM, Aladdin alaamu...@gmail.com wrote: This is simply will pass the event to the app for processing, then it will later change it in the browser. What do you guys think ? That seems likely to break existing code that expects by the time the event is fired the browser has been updated to reflect the new history token. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adding support for Typed Arrays (issue1621803)
In the process of testing it, I found http://code.google.com/p/chromium/issues/detail?id=109785 :) -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adding support for Typed Arrays (issue1621803)
On Sat, Jan 7, 2012 at 3:03 PM, t.bro...@gmail.com wrote: That's it. I'd probably call the client class JsoTypedArray so it's harder to mix it up with shared.TypedArray (particularly when you use facilities provided by your IDE to automatically insert the 'import' clauses). Also, giving the client class a slightly uglier name is an incentive to rather code against the interface: the implementation class is a detail. I disagree -- with this approach, I can't write shared code that creates an ArrayBuffer/etc. Let me get my proof of concept code uploaded and show you what I am thinking of. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Tutorial for GWT request factory and Android
On Mon, Dec 19, 2011 at 9:17 AM, Shrivallabh shrivall...@gmail.com wrote: Hi Folks, I have an existing app built on GWT 2.4 which makes use of GWT request factory. I am planning to write an android app that exposes a subset of functionality and has a different look and feel. However, the means to fetch data remains the same - request factory. Is there any tutorial available for hooking android apps with Request factory? I have read that requestfactory-client should help us do exactly that. Any pointers will be immensely helpful. You may find this presentation useful: http://www.youtube.com/watch?v=M7SxNNC429Unoredirect=1 -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Just wondering about the protocol for code commits.....
On Wed, Dec 7, 2011 at 3:58 PM, karthik reddy karthik.ele...@gmail.comwrote: I have tacitly presumed that a LGTM from the reviewers is kinda mandatory for a commit to be made. However, I have just noticed a commit made today without a explicit LGTM. Since GWT code is committed to an internal system which also requires an LGTM, jlabanca approved it there and just didn't put the LGTM on the public review. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: FF8 Devmode Plugin (issue1589803)
On Fri, Nov 11, 2011 at 5:16 AM, t.bro...@gmail.com wrote: I'll reiterate my question: is there any plan to move to js-ctypes? or is there some better alternative? or are binary components and recompiling every 6 weeks a necessary evil? I mean, have you looked at the problem yet? and if so what's the outcome? and is there a plan on your side? If you believe js-ctypes could work, but do not have time/resources to invest in moving to them, then maybe I could try it on my side. But if you already looked at it and know that js-ctypes won't work, then I won't invest time. And if you have a plan to do the move on your side, then I'll wait too. From a brief look, it seems there is no way to get a callback when an object is no longer referenced -- this is required to free the Java object that has been wrapped on the JS side once it is no longer referenced. It also wasn't clear how to create a JS object that wraps a Java object and intercept all the methods, but I assume that part can be done in JS. Aside from that, it looks like it is just moving parts of the problem around. Instead of having FF load the correct binary based on the platform, it looks like it is up to your JS code to figure out what to load (though the examples seem inconsistent, so maybe it isn't that bad). All the calls from the plugin to the JS engine will have to be proxied through the JS code (for example, I didn't see how to allocate a JS string), which will mean a lot of boilerplate and a likely performance impact. So, assuming the finalizer problem can be overcome, I think it would be possible but would be a lot of work to get worse performance. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] How to build the GWT plugin?
On Wed, Nov 2, 2011 at 3:33 PM, salaba sal...@gmail.com wrote: I am seeing some error messages print out, so wanted to debug what is the issue. I am using Chrome, so I tried in the directory plugins/webkit/ $ ant Buildfile: build.xml BUILD FAILED It complains: Cannot find ../common.ant.xml There is one at ../../, so I copied that one to ../ $ ant Buildfile: build.xml BUILD FAILED It complains: This build file is in an inconsistent state Chrome doesn't use the WebKit plugin -- that is for Safari, and is built using xcode. For Chrome, cd plugins/npapi and run make. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: More control over split point fragments
On Wed, Oct 5, 2011 at 12:52 PM, John Patterson jdpatter...@gmail.comwrote: That seems likes a step in the right direction - but ideally there would be some algorithm that can put common code into new shared fragments. I'm sure its a lot harder than I imagine to handle all the permutations and load sequences. If some code is shared by A+B and some other code by B+C and more by A+C the algorithm should create a 3 new fragments (rather than a single left-overs) and then merge some of them if they are below some magical threshold. The basic code splitting algorithm can handle this, and more advanced split strategies were considered by Lex in his initial writeup, but none were ever implemented. There were tons of corner cases in the simple splitting scenario, so I am sure there would be even more trying to do something trickier. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: IE + SSL + Image.setURL throws an Operation Exception at runtime
On Tue, Sep 20, 2011 at 4:20 AM, DaveC david.andrew.chap...@gmail.comwrote: There was also another runtime Exception being thrown - this time the culprit was the iFrame for GWT History (the exception was thrown at the point the iframe's document was being accessed)... it was unused and removing it fixed the problem. Note that the history iframe is only unused if you don't use history (and you probably should be if you don't want people to back out of your app accidentally by hitting the back button). I find it hard to believe that no one else has seen this error??? Could it be related to your use of self-signed certs? Have you added the signing certificate as a trusted cert so you don't get a dialog when browsing to it? Also, in your example above you are loading an image from http, which will get you a mixed-mode content warning in an SSL page (and some browsers will not even fetch it by default). -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Hosted mode without plugin
On Tue, Sep 13, 2011 at 9:06 AM, Marcin Wiśnicki mwisni...@gmail.comwrote: Would it be technically possible to implement hosted mode without using browser plugin ? I'm thinking about sending messages straight from JavaScript over XHR/ Comet/WebSocket to embedded Jetty server and interacting with JS engine using eval(). Is there something that would be impossible to implement this way ? The problem is you have to block the executing JS while it makes a synchronous call to the Java code executing in the code server. As you can't allow execution to return to the browser event loop, I don't see how you could implement that in JS. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Hosted mode without plugin
On Thu, Sep 15, 2011 at 2:44 PM, Marcin Wiśnicki mwisni...@gmail.comwrote:
Is this blocking strictly necessary or would it suffice to simulate it
with continuation passing ?
The problem is the original call site is written as a blocking call, and
ultimately may have originated from Java. Ie:
void foo() {
x = bar();
}
native int bar() /*-{
var x = @Foo::baz()();
return 2 * x;
}
int baz() {
return 42;
}
Sure, you might could theoretically rewrite bar to pass a continuation to
baz, but baz is Java code, so you would have to rewrite that as well as
anything it calls, which may include JRE code. Then that passes the other
way as foo() has to know that bar doesn't return the value directly.
I really don't think this is feasible.
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Serialization of Final Fields in RPC (issue1380807)
On Thu, Sep 1, 2011 at 11:56 AM, stephen.haber...@gmail.com wrote: Thinking about it some more; it would be the easiest if GWT just started serializing final fields across the board, and only skipped them if they were marked with a GwtTransient. That is basically what the current patch does (except for ignoring sets on the client-side). Anything else requires making the server-side aware of the rpc.final.serialize value. Maybe that is easier than I'm imagining. Anyway, it'd be a breaking change, so perhaps it's not an option, but I just thought I'd mention it. There is a risk that existing users were relying on current behavior to not send sensitive data in final fields across the wire, and changing it without some form of opt-in seems a security risk. It could be adding an inherits tag that sets a config property or annotating service interfaces/etc, but it needs to be opt-in. If the server needs to behave differently depending on this setting, then either it should be included in the RPC payload or in some deploy artifact, such as the serialization policy file. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Minor dev/build.xml cleanup (issue1524804)
On Wed, Aug 24, 2011 at 3:30 PM, stephen.haber...@gmail.com wrote: http://gwt-code-reviews.**appspot.com/1524804/diff/1/**dev/build.xmlhttp://gwt-code-reviews.appspot.com/1524804/diff/1/dev/build.xml File dev/build.xml (left): http://gwt-code-reviews.**appspot.com/1524804/diff/1/** dev/build.xml#oldcode113http://gwt-code-reviews.appspot.com/1524804/diff/1/dev/build.xml#oldcode113 dev/build.xml:113: include name=guava/guava-r06/guava-**r06-rebased-2.jar / guava was already listed above and I don't see any references to swingworker in the codebase, so I assume it's legacy and can be removed? Yes, swingworker used to be used in SwingUI, but is no longer. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Changes setters/clearers com.google.gwt.dom.client.Style to return Style instead of void (issue1530803)
On Tue, Aug 23, 2011 at 12:17 AM, Daniel Bell daniel.r.b...@gmail.comwrote: Just out of curiosity, does this have to defeat the compiler optimisations? Isn't it known at compile time that those setters will always return the same Style instance? In that sense, from the compiler's point of view, isn't the situation with the setter returning the Style the same as the situation with getStyle() returning the Style? No -- it may be theoretically possible to analyze that all the methods called don't mutate the object, the current compiler doesn't do it. We have talked about producing better code for the builder pattern, but it is surprisingly difficult to get right in all situations. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
On Fri, May 27, 2011 at 4:45 AM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com wrote:
2011/5/26 Eric Ayers zun...@google.com:
Unfortunately, I tried removing the replace('$',.) and it failed
miserably. Looking at it in the debugger, those really are binary names.
e.g.:
com.google.gwt.core.client.impl.AsyncFragmentLoader$LoadingStrategy
Thanks guys for you answers. I moved on with my work-around. It would
be great if those binary names were converted to source names as soon
as possible so number of places in gwt code where we have to consider
both options is minimized.
The problem is conversion to source names is lossy -- given Foo.Bar.Baz, you
don't know where the split between the package name, enclosing class name,
and class name is (compare to Foo/Bar$Baz and Foo/Bar/Baz). I think the
only way you could avoid this problem is if you kept a structured type with
those pieces of information rather than a simple string, but that would be
expensive in terms of allocating several additional objects for every class
name in the program, plus many uses don't care about the distinctions and
just wand the source name.
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
On Fri, May 27, 2011 at 10:03 AM, Scott Blum sco...@google.com wrote: What John said. Blame Java for the fact that with some lookup oracle, it's impossible to distinguish the cases. We've always assumed that users would not use '$' in class names in places where it matters. That being said, let's assume that a user isn't allowed to have both A.B and A$B like Toby said, as the binary names would collide. Given that, I *think* the only place source type name really matters is resolving rebind requests and results. So maybe it's possible we could use only binary name or internal name everywhere and move away from using source name except in output messages. I don't think that solves the problem -- let's say we store Foo/Bar$Baz internally and convert it to a source name where needed. How do we know whether the class name is Bar$Baz or Baz inside of Bar? The problem is simply if you allow $ in a class name, binary and internal names are lossy too as they no longer encode the difference. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
On Fri, May 27, 2011 at 12:53 PM, Scott Blum sco...@google.com wrote: On Fri, May 27, 2011 at 10:12 AM, John Tamplin j...@google.com wrote: I don't think that solves the problem -- let's say we store Foo/Bar$Baz internally and convert it to a source name where needed. How do we know whether the class name is Bar$Baz or Baz inside of Bar? The problem is simply if you allow $ in a class name, binary and internal names are lossy too as they no longer encode the difference. My point is to NOT convert it to source names, do everything in binary. So when you generate source code, how do you do that? Or let's just say you want to get the simple class name -- in the example, is it Bar$Baz or Baz? The point is you don't have the information necessary to tell. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Dollar sign and binary types
On Thu, May 26, 2011 at 2:03 PM, Grzegorz Kossakowski
grzegorz.kossakow...@gmail.com wrote:
The problematic place for me is ReplaceBindings.java, lines 154-155:
// Rebinds are always on a source type name.
String reqType = type.getName().replace('$', '.');
Any comment on that one? Working-around it is possible but quite
involved. I'd love to know if I need some solid work-around or just
hack to keep me going because this will be removed upstream.
There is a common place for these in c.g.g.dev.util.Name, that provides all
the conversions between different name types. So, this should be:
String reqType = Name.BinaryName.toSourceName(type.getName())
However, that doesn't solve your problem.
The main problem is that once you get to a binary class name as a string,
you can no longer distinguish these cases. You would have to have package,
enclosing class, and class broken out separately in order to do anything
more useful with this, or at least have an oracle of possible classes you
can look up (though that would still fail if A.B and A$B were both present).
JReferenceType just takes a single string, so you can't get that
information.
However, I think in this case there is no need to replace $, since despite
the lack of documentation I believe type.getName() is actually a source name
(we have been really sloppy with the 3 types of names - a year or two ago I
started to rewrite it all with type-safe wrappers but that was rejected
because it dramatically increased memory usage in the compiler). For
example, if you look at ReferenceMapper.createType, it takes a JDT
ReferenceBinding.compoundName and creates the names by simply joining the
components with dots. My guess is if you simply remove the .replace from
that line, it will work fine (and in fact is removing a bug). I wouldn't
get your hopes up that that is the last time you will run into a problem,
because anyplace that calls Name.isSourceName, for example, will fail on a
class name with an embedded $.
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Creating a default Locator for RequestFactoryServlet
On Thu, May 26, 2011 at 2:23 PM, Thomas Broyer t.bro...@gmail.com wrote: How about simply using a ServiceLayerDecorator that overrides resolveLocator, delegating to super.resolveLocator and, if it returns null then return the default locator instead? If it were in a separate annotation, you could simply define your own interface with whatever defaults you like and then extend that interface instead of RequestContext. We use this pattern a lot for i18n Messages to get company/project-wide defaults. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] gwtc classpath
On Tue, May 24, 2011 at 9:33 AM, Grzegorz Kossakowski grzegorz.kossakow...@gmail.com wrote: 2011/5/24 Eric Ayers zun...@google.com: Yes, that class does read bytecode, but the source of the bytecode isn't usually compiled .class files from the classpath, its the result of running JDT on the sources. I think it might be confusing because I worked on a project to try to build type oracle from bytecode from any compiler, but we have kind of abandoned that effort in favor of creating an equivalent to javac that spits out more than just bytecode with each compiled class. Do you want to say that gwtc doesn't read .class files from classpath at all? Or if it does in what cases and what for? For user code (that which will be compiled by GWT), it only looks for class files from the classpath for annotations that it doesn't have the source to. In DevMode, it will also load user classes from the classpath if the visible source file is annotated with @GwtScriptOnly. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Integer calculation errors
On Sat, May 7, 2011 at 6:12 PM, Kenneth Jorgensen kenneth...@gmail.comwrote: I've been writing a cryptographic library for GWT (available at https://bitbucket.org/kennethjor/tovikov) and I ran into a few strange problems when dealing with integers. I will not be able to post code to reproduce the errors, simply because I wasn't able to do it with stand-alone code, yet the errors still happened. The first error I was getting had to do with integer rotation. I managed to fix it by implementing my own rotation functions, which can be found at https://bitbucket.org/kennethjor/tovikov/src/f49670bd090a/src/main/com/tovikov/util/IntegerUtil.java . As mentioned, I wasn't able to reproduce the errors outside of the library code, but if you want to verify the error, you can check out the library above, and in the com.tovikov.security.hash, replace all calls to IntegerUtil.rotateLeft and IntegerUtil.rotateRight with calls to Integer.rotateLeft and Integer.rotateRight respectively. Then run ant webtest and open up the compiled code in a browser, you will see that it fails on everything except MD2. The second error I wasn't able to reproduce neither, but I was able to implement a work-around. The error happened when implementing SHA-224 and SHA-256. On SHA-256 I took the test vectors from FIPS 180-2, and after applying the fix above, I was able to succeed on a single-block message, but still failed on the multi-block message given in that document. I tracked down the error to a failure in iteration 52 when processing the second block. When calculating t1 (https:// bitbucket.org/kennethjor/tovikov/src/f49670bd090a/src/main/com/tovikov/ security/hash/Sha256Hash.java#cl-175) the result is supposed to be 0xe167f8cb, but came out as 0xe167f8cc. When I took the numbers used to calculate t1 and tried to calculate it on its own (0x68f25260 + 0xd6ae79cb + 0x27a50536 + 0x391c0cb3 + 0x41061ab7) I got the right result, but in the loop for the hash the result wasn't correct. On a whim I implemented IntegerUtil.forceInt(), which converts the integer to bytes and then back again, and it all worked. I apologise if this is all a bit cryptic, but I have been comparing hexadecimals for the last 5 hours, and I brain hurts :) Hope this is still somewhat useful to the GWT developers. Oh, and my GWT version is 2.2.0, not trunk. I haven't looked at your code in detail, but GWT does not emulate integer overflow, as it would be too expensive since JS only has a single Number type which is an IEEE double. For hash functions and the like which depend on 2s-complement 32-bit math, you need to manually force it to be coerced to a 32-bit value. You can do this with either (x | 0) or ~~x -- see GWT's String.hashCode() emulation for an example. See http://code.google.com/webtoolkit/doc/2.2/DevGuideCodingBasicsCompatibility.html for details. I would be surprised if Integer.rotate* had a problem, but if you can produce a reproduction case for just that we can certainly fix it. BTW, GWT has MD5 built-in already. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Force locale to en_US for user unit tests (issue1430801)
On Thu, May 5, 2011 at 3:58 AM, Thomas Broyer t.bro...@gmail.com wrote: What I don't understand is that the tests are actually exercising DateTimeFormat, which is completely emulated and controlled, and not subject to the browser's locale (or at least it *shouldn't* be, AIUI). For the 2010-02-01 vs. 2010-02-02, I suspect some kind of daylight saving time, but yet again, the date is constructed with Date.UTC() so I think it shouldn't matter. I'll see if I can find time next week in between I/O days to look at it. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Disabling test for null on getBrowserById for DOM elements without DTD when running on Chrome 11 (issue1440801)
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Fix a class of compiler bugs related to staticImpl. (issue1428804)
On Wed, Apr 27, 2011 at 2:57 PM, Scott Blum sco...@google.com wrote: If the Java MethodInliner kept call counts, I would have special-cased it to allow inlining the static into the instance when it's the only caller. But since call counts aren't already computed, I decided it would be best to try it out as is and see if it actually increases code size in practice. Some of the design of the i18n classes assumes that most of these relay methods go away due to inlining (and in particular, how migration of client-shared is done adds lots of single-call relay methods). -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Create a utility class for checking assignability of types for use (issue1420808)
On Fri, Apr 22, 2011 at 3:45 AM, t.bro...@gmail.com wrote:
I wrote it down yesterday evening, and the method is now gone, but
anyway:
http://gwt-code-reviews.appspot.com/1420808/diff/1/user/src/com/google/gwt/uibinder/rebind/TypeOracleUtils.java
File user/src/com/google/gwt/uibinder/rebind/TypeOracleUtils.java
(right):
http://gwt-code-reviews.appspot.com/1420808/diff/1/user/src/com/google/gwt/uibinder/rebind/TypeOracleUtils.java#newcode60
user/src/com/google/gwt/uibinder/rebind/TypeOracleUtils.java:60:
JType... argTypes) {
On 2011/04/22 01:13:17, rjrjr wrote:
I don't know that I would ever use this unless it was based on
JClassType.getOverridableMethods().
getOverridableMethods would miss final and static methods. You'd have to
use getInheritableMethods instead.
The question is what should be done about protected and default access
methods? In most cases in GWT generators, unless we're sure about the
package of the caller and callee classes (as is the case when the caller
is a class that's being generated: UiBinder, EditorDelegate and other
EditorContext), we don't bother checking if the method is accessible, we
simply filter out non-public methods (see PlaceHistoryMapperWithFactory
re. the factory's methods).
Right, we discussed these things in chat and decided since we didn't have an
immediate need it was better to leave it out and then when we do have the
need for it, we will have a better idea about what API is useful.
But rather than hardcoding that choice, perhaps you should make the
first
argument a JMethod[] to let me choose the set myself?
and/or provide both:
hasCompatibleMethod(JClassType,boolean,methodName,JType...)
containsCompatibleMethod(JMethod[],boolean,methodName,JType...)
the former simply delegating to the latter.
Right, that is what i had but there was a question about whether it should
filter only public methods or include protected, and whether the API should
expose that choice, etc.
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adds back Util.toHexString() and Util.hex4() as deprecated methods. (issue1420802)
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT Private/Protected Members
On Mon, Apr 4, 2011 at 12:10 PM, Clécio Varjão cleciovar...@gmail.comwrote: One of the most frustrating thing in OO is private methods. Specially in an open source software, I believe there should not be private methods (or avoided, and use only for essential code- e.g. manipulating private fields). Protected methods could be used in favor of private methods, so developers could extended the class. Any chance of GWT move towards using Public/Protected methods instead of private methods? For instance, it is almost impossible customize Trees, SuggestBox, and others. And doing a copy-and-paste for a new class, defeats the purpose of OO. The basic problem is that defining a protected API is much harder than a public API, as you have to clarify the interactions between all the methods and define which implementation details are exposed to subclasses. Also, you generally wind up constraining the implementation, requiring breaking changes to the protected API to change the implementation. Finally, it is easy to later open up a protected API if it is justified, but it is much harder to remove it. So, in general, we err on the side of locking everything down and then opening it up as warranted. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Changes the eclipse formatter to put a space between [] and { in an (issue1411801)
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fixes to cldr eclipse projects in GWT. (issue1410802)
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Autoformat the api-checker tool source (issue1405801)
On Tue, Apr 5, 2011 at 8:35 PM, Ray Ryan rj...@google.com wrote: I don't think it's reasonable to ask Eric to tweak the auto formatter. We had that conversation already. He's just doing the same thing we have eclipse configured to do, right? Well, my understanding of the changes made to the formatter settings were: - change the line width to 100 - let lines break at method invocations So, I am not sure why there are other changes which, IMHO, look really terrible. I thought the point of doing a few small blocks of code first was specifically to look for things like this that could be improved before we run it on everything. I can't look for real right now. Did you really find something aggregious? Well, I think it is pretty egregious, but YMMV. In particular: - the loss of the space in array initialization is a change for the worse that is one checkbox to fix - the assignment breaking is harder to fix, but I think the change is net for the worse because while the old settings allowed overly long lines, they seemed to occur only rarely in field initializers, and it is easy enough to work around that by initializing them in an initializer block instead of on the same line. The current settings will screw up line breaks on assignments all over the place. - The indentation issue I am talking about is like this. Previous settings: logger.log(TreeLogger.log, A really long message + variable); while the new settings do this: logger.log(TreeLogger.log, A really long message + variable); however, I don't see where this is coming from. Regarding detecting the builder pattern, it could detect multiple invocations a.foo().bar().foo().baz() etc, but I agree the current formatter doesn't have that capability and the new setting is better than the old setting. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RR: Promoting RequestFactory to a higher package
On Fri, Mar 25, 2011 at 5:34 PM, Andrés Testi andres.a.te...@gmail.comwrote: +1 for this! Are there similar plans for com.google.gwt.i18n? GWT's i18n seems inextricably tied to GWT, so I don't see any reason to move it out. Most of the classes for the infrastructure have been placed in the server package, and eventually Messages/etc will be as well (though unfortunately it will be a breaking change for non-GWT generators since annotations can't inherit from other annotations). -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] How do I submit a patch with binary files?
On Thu, Mar 24, 2011 at 10:14 AM, Jeff Larsen larse...@gmail.com wrote: I've got a patch for TabLayoutPanel which will allow for handling tabs that scroll off the viewable area. For this I've got some horrifically ugly images that I created with MSPaint. How do I include those in a patch? SVN patches are just text files. I didn't spend any real time making these images on the assumption that you would want your graphic designer to make something that is far superior to anything I could create. I'm no artist. After uploading a patch to Rietveld, just reply to the GWTC email it sends out and attach your images as attachments. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Questions on the process of issue fixing.
On Fri, Mar 18, 2011 at 6:44 PM, Antoine DESSAIGNE antoine.dessai...@gmail.com wrote: Also I created new string messages that needs to be translated, but I didn't do anything to allow GWT contributors to translate it. I can do the French translation, but should I simply create the _FR.properties file or is there some tool somewhere that I should use ? I believe this would be the first widget included in GWT which would have text that needs to be localized -- we would need to get it localized in all Google-supported languages through our own translation team, and then the translated property files would be included in GWT. You can create a RichTextToolbar_Strings_fr.properties file for testing though. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Questions on the process of issue fixing.
On Fri, Mar 18, 2011 at 1:31 PM, Antoine DESSAIGNE antoine.dessai...@gmail.com wrote: Also, I have a more technical question: what's the right way to handle CSS and messages in the client.ui package: CssResource (with new CSS files) and Constants ? Can you describe what it is you want to do? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Promotes Gin's AsyncProvider to GWT, along with a more general (issue1387801)
On Mon, Mar 14, 2011 at 12:37 PM, Ray Ryan rj...@google.com wrote: [+google-...@googlegroups.com] What dependency? DI is a pattern, not a commitment to a particular framework. That said, I agree that taking AsyncProvider from Gin is a bit presumptuous. I meant to include the gin community on this patch, adding them now. What do you think, folks? The goal here is to sever the dependency between com.google.gwt.inject.client and GWT RPC. To me, the new AsyncCallback is just a more flexible version of the old one, and AsyncProvider seems a generally useful GWT analog to j.u.c.Future and not tied to GIN at all. Besides GWT already has DI built-in -- you can think of GWT.create as DI, since you substitute an implementation based on your module files, but you also can have generators write the implementation on the fly as well. Of course, it is highly GWT-specific. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Typo in javadocs
On Tue, Mar 8, 2011 at 6:11 AM, T tomek.maty...@gmail.com wrote: This is just a tiny issue, so I don't want to involve issuetracking. I'm dealing with i18n translation, so I decided to generate properties from default locale. I've annotated my constants with @Generate as provided in: http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/gwt/i18n/client/LocalizableResource.Generate.html Since it's not a class literal (which is fully obvious to me) I did get a ClassNotFounException in AbstractLocalizableImplCreator at gwt compile time, resulting in: Invoking generator com.google.gwt.i18n.rebind.LocalizableGenerator [ERROR] @Generate class com.google.gwt.i18n.rebind.format.Properties not found I've spent one hour looking at it again and again, and I didn't realize that the correct class name was com.google.gwt.i18n.rebind.format.Properties*Format*. It's just to improve documentation. Thanks - I am about to land an update to this area that will change the example, and I will make sure it is correct. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: add ie9 user.agent with fallback binding to ie8. (in preparation for ie9 support). (issue1369808)
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: A Class that creates a string hash out of the public API of a (issue1359802)
On Wed, Feb 16, 2011 at 11:57 PM, Scott Blum sco...@google.com wrote: To give some context, this signature is used for the purpose of deciding if a class's API has changed... *as far as other Java source files are concerned for the purposes of running javac*. It has no effect on TypeOracle or the data presented there, it's not being used to cache old TypeOracle models. Using sort order means a user can sort a file without changing its API and not have to recompile the dependent files. You can design the hash so it isn't sensitive to the order of methods/fields without having to sort. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)
On Tue, Feb 15, 2011 at 4:03 PM, Chris Conroy con...@google.com wrote: Sorry, didn't see your comment in time for the commit. I just used the same fix Kelly applied in SpeedTracer. I don't think it really matters strongly either way. As I understand it, the xs linker will soon be deprecated since the xsiframe linker provides a superset of its functionality. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Eclipse autoformatter update: allow assignments to wrap. (issue1354803)
On Fri, Feb 11, 2011 at 1:51 PM, zun...@google.com wrote: Well, I personally like the way it looks: this.myPackage = StringInterner.get().intern( (myPackage.length() == 0) ? : (myPackage + '.')); becomes: this.myPackage = StringInterner.get().intern( (myPackage.length() == 0) ? : (myPackage + '.')); This is going to cause a lot of churn... I would prefer wrapping assignments only when it is necessary to fit on the line. Ie, this example, the first version is better (and has the advantage of being the way the source is now). The real problem with assignments is when they are really long, such as field initializers, and Eclipse won't break them at all. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Follow on to svn r8671, which made the GWT code style allow whitespace (issue1346803)
On Wed, Feb 9, 2011 at 2:25 PM, Ray Ryan rj...@google.com wrote: Okay, ready for re-review. Less ambitious now. Allows foo.bar().baz().bang().imagineManyOfThese(hi mom); to wrap as: foo.bar().baz().bang() .imagineManyOfThese(hi mom); instead of what happens now: foo.bar().baz().bang().imagineManyOfThese( hi mom); One other thing to check is what sort of diffs show up if you do Ctrl-Alt-F on the whole codebase (just spot check of course). I think it is a problem if most files would change how they auto-format. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: fix for NPVariant numbers. (new webkit v8 bindings give us doubles for ints) (issue1277801)
On Tue, Jan 11, 2011 at 6:21 PM, Fabio Valbuena fabio...@google.com wrote: I have been using a 'custom' build android webkit with a couple of workarounds and the double issue is actually quite minor in the android case; I am using a change that works around the double issue. Right, but wouldn't this allow you to run on the stock browser? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: DevMode generates a default web.xml when servlet tags are present and no web.xml exists. (issue1266801)
On Fri, Jan 7, 2011 at 1:11 PM, zun...@google.com wrote: I don't see any problem with the code. Is this really something we want to happen by default? I'm concerned it will be baffling to a user why a web.xml gets created only some of the time. It seems to me that an external tool that could parse xml could create such a file if it was needed without too much work. There's nothing in here that couldn't be done in a python script with access to the module files. I think we lost useful functionality when we lost the ability to put servlet tags in a module (think about a self-contained module that contains client code and the servlet needed for the server-side piece - it would be nice to just inherit it and it works, such as for server-side script selection). Should we reconsider the decision to have web.xml authoritive and instead have a template which is used to generate the web.xml file? If there is already a web.xml file, we keep the behavior of today, and if not then we are always generating a web.xml file, whether from web-template.xml (or whatever) or creating a default one if the user didn't supply one. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: UiBinder. Support for TreeItems. (issue1233803)
On Wed, Jan 5, 2011 at 12:47 PM, Ray Ryan rj...@google.com wrote:
Taking this a bit further, if we're going to be playing with interfaces we
might as well go the whole nine yards:
interface IsTreeItem {
TreeItem asTreeItem();
}
interface HasTreeItems {
void addItem(IsTreeItem);
void addItem(Widget);
void addItem(SafeHtml);
/* No addItem(String), it's unsafe */
Taking a string is fine, but it should be interpreted as plain text not
HTML..
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: UiBinder. Support for TreeItems. (issue1233803)
On Wed, Jan 5, 2011 at 1:09 PM, Ray Ryan rj...@google.com wrote: There is an existing overload that accepts a string and interprets it as HTML, so that's not an option. And asking Konstantin to add a new addItemText(String) method seems too far outside the scope of this patch. Ok, we can always add it to the interface later after we remove the deprecated method that takes HTML. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add a warning in GWTTestCase to help users that accidentally run a GWT JUnit Test as a JUnit Test. (issue1224801)
On Tue, Dec 21, 2010 at 11:09 AM, p...@google.com wrote: On 2010/12/16 19:43:39, rdayal wrote: Is this system property required? This is a tough one, because I don't think it's strictly required, but the devjar has things such as the GWT devmode bridge and the GWT compiler. Can you think of a case where it wouldn't be set though? Let me ask some non-GPE and non-Eclipse users to add this change and confirm nothing breaks before asking for the LGTM. I believe if you are working with GWT instead of *on* GWT, and you aren't using GPE, gwt_devjar is not required and people would have no way of knowing they need to set it. Worse, the error message is going to be misleading for them. I think that error needs to occur only if GPE is being used, or else provide more explanation. gwt_devjar is needed primarily to find shared objects for native libraries (currently only used for Windows proxy support) and WebAppCreator needs it so it uses the right path for the generated build files (and GPE needs it because it calls WAC and I think it may set it automatically for GWT launch configs). -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
On Wed, Dec 8, 2010 at 2:17 PM, Ray Ryan rj...@google.com wrote: Basically we don't know exactly how we want to change the thing, but have a feeling something will be needed. Re: composition or delegation, it always happens, but I'm not sure that's a concrete issue yet. We could introduce an IsActivity interface, but I don't see anywhere in the current GWT code we would actually call it. People implement their own ActivityMappers by hand, so they could use that convention themselves. Sounds like there aren't super strong feelings on this, so today for 2.1.1 I'm inclined to - drop the interface - rename AbstractActivity to Activity - document as being forbidden from developing any non-trivial behavior - and perhaps document the intent to retroactively introduce an interface when it's had a chance to settle Last passionate objections? I still feel like there is little cost in having the interface, which is what is used in the API, and a default implementation where any new methods added will get default behavior. Then document that if you implement the interface but don't extend the default implementation, you will be broken by future updates. That lets users decide whether they care more about not being broken by updates or more about not having to extend a base class. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Isolates the portion of TypeOracleMediator that (issue1188802)
On Tue, Dec 7, 2010 at 3:11 PM, zun...@google.com wrote: On 2010/12/07 13:53:13, alexander.mitin wrote: You cannot build the TypeOracle using the class bytes using the classpath only, because of the re-rooted resources which have no compiled classes near the source file. Good point. I'm using this method of getting byteCode just for the purposes of exercising the TypeOracle build from byteCode that wasn't generated by JDT. The assumption is we will have to be smart about finding the resources needed to add to the TypeOracle just as we do today with source code - that logic isn't a part of this patch. IHM specifically excluded any super-source class or those containing JSNI from loading from bytecode, and you still have the issue of getting parameter names from interfaces/abstract methods. Also, you should be aware that if the bytecode loaded from the classpath is not from JDT, you will get subtle differences. In particular, synthetic classes/members were an issue, and especially if you refresh you need to make sure to refresh all the class files from the same compilation unit as things break badly if you mix classes from different compilers within a compilation unit. Our hope is that by using bytecode, we can delegate the work of building the information we need in the TypeOracle to some process that will run before DevMode or WebMode is invoked - such as an Eclipse plugin or a java compiler frontend. This sounds like IHM -- have you looked at the code in that branch? Basically it was working other than running into issues around synthetic code differences between javac/JDT that caused large apps to fail. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Breaking change proposed: future proofing Activity in 2.1.1
On Fri, Dec 3, 2010 at 2:58 PM, Patrick Julien pjul...@gmail.com wrote: I don't know since I don't know what your plans are, will just have to trust you. That being said, the Activity interface is currently really nice and it doesn't tie us down to a single class for inheritance. I have been very happy with the recent cases where I have used an interface for the API but provided a default implementation, with the admonishment that implementing the interface without extending the default implementation is likely to be broken in the future. That way the people that care more about being able to substitute alternate implementations or to use it without having to extend the implementation can implement the interface, and those that care more about not being broken by future updates can extend the default implementation. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Enhancement: DateTimeFormat: Add format/formatYear parameter to guess century on yyyy
On Wed, Dec 1, 2010 at 8:46 AM, HerrB92 herr...@googlemail.com wrote: I'm sorry, I don't know if there is and this is the right place to place an enhancement wish. So, thank you for reading... ;-) If a parsed date contains only a 2-digit year, then the century will be guessed based on the current century +/- 20 years (in short). If you format a date, no guessing takes place. In the current century, people tend to go back to 2-digit typing, as the 20 in 2010 shouldn't change in the next 90 years. The latest fix ensures at least, that formatting a date results in the specified digit count. But 10 will become 0010 with a pattern. This is the documented result - but may not be expected by the users. Wish: Add a parameter to formatYear() (and thus to format()) to guess the century, if a 2-digit year and - to keep it simple - a 4-digit-year pattern is provided. E.g. format(1.1.10,guessCentury=true) - 01.01.2010, if datePattern = dd.MM.. I don't think you ever want a Date to have the two-digit year -- things like which day of the week a date is, leap year or not, etc will all be wrong. So, any guessing should only be at the point the date comes into the system, whether from the user, a database, or whatever. Then when you format it for printing, you can choose to use two-digit years if you prefer. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Enhancement: DateTimeFormat: Add format/formatYear parameter to guess century on yyyy
On Wed, Dec 1, 2010 at 11:50 AM, HerrB92 herr...@googlemail.com wrote: Err, yes ... I don't ever want a 2-digit year, also. I have people, that enter 10 and expect to get 2010. Currently, you will get 0010 (with a pattern). But I think, I get the point: If there is textfield and a user enters 1.1.10 and default date parsing is used (pattern dd.MM.), you will get a valid date object - 10 years AC. My request would mean, that if .format() is applied to that date, that the century is replaced by the guessed century, if the given century equals 00. My point is that you want to fix that at the point the date is entered, not to just display the date differently, since many other things will depend on the year being correct. Ie, Date d = fixMissingCentury(dtf.parse(dateField)); where fixMissingCentury detects a first-century year and changes it according to your needs. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Issue 5663: DoubleParser rounds values to integers (issue1170801)
On Wed, Dec 1, 2010 at 11:52 AM, Ray Ryan rj...@google.com wrote: I'll get it in today, thanks very much for the patch. I suspect this is the cause of http://code.google.com/p/google-web-toolkit/issues/detail?id=5460 Note if you are going to take care of the patch, you need to make sure the double comparison avoids roundoff on all browsers (you would be surprised how much it differs, as I found out doing the BigDecimal/NumberFormat work). I would recommend .5 as the fraction, since there can't be any round-off. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: r9277 committed - Removing reference to designTime.getProvidedField()
On Mon, Nov 29, 2010 at 6:43 PM, Ray Ryan rj...@google.com wrote: Yes. So who is taking care of merging in the requiring changes from trunk? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: r9277 committed - Removing reference to designTime.getProvidedField()
Then other pieces of the change were not integrated, as this was preventing
the 2.1 branch from building.
On Nov 25, 2010 8:12 AM, Konstantin.Scheglov
konstantin.scheg...@gmail.com wrote:
No!
This change breaks @UiField(provided=true) support in GWT Designer,
important feature which we want to support for GWT 2.1.1.
On 24 ноя, 19:55, codesite-nore...@google.com wrote:
Revision: 9277
Author: gwt.mirror...@gmail.com
Date: Wed Nov 24 08:54:59 2010
Log: Removing reference to designTime.getProvidedField()
http://code.google.com/p/google-web-toolkit/source/detail?r=9277
Modified:
/releases/2.1/user/src/com/google/gwt/uibinder/rebind/UiBinderWriter.java
===
---
/releases/2.1/user/src/com/google/gwt/uibinder/rebind/UiBinderWriter.java
Fri Nov 19 05:49:25 2010
+++
/releases/2.1/user/src/com/google/gwt/uibinder/rebind/UiBinderWriter.java
Wed Nov 24 08:54:59 2010
@@ -1093,15 +1093,8 @@
// TODO why can this be null?
if (fieldWriter != null) {
- String initializer;
- if (designTime.isDesignTime()) {
-String typeName =
ownerField.getType().getRawType().getQualifiedSourceName();
-initializer = designTime.getProvidedField(typeName,
-ownerField.getName());
- } else {
-initializer = formatCode(owner.%1$s, fieldName);
- }
- fieldManager.lookup(fieldName).setInitializer(initializer);
+ fieldManager.lookup(fieldName).setInitializer(
+ formatCode(owner.%1$s, fieldName));
}
}
}
@@ -1215,4 +1208,3 @@
designTime.addDeclarations(w);
}
}
-
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Issues 5479, 5507 and 5571 (and a few other editor-related tweaks) (issue1099801)
On Thu, Nov 18, 2010 at 2:35 PM, rj...@google.com wrote: @jat, I'll be on vacation from tomorrow through Thanksgiving. Will you be able to land this for Thomas, and get it on to the 2.1.1 branch while I'm gone? Sure. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add README step to use the Google Web Toolkit SDK in the gwt-user project so that users can run ... (issue966802)
On Wed, Nov 17, 2010 at 2:43 PM, Rajeev Dayal rda...@google.com wrote: No, I don't think it will. I think the nature will be ignored. But let me verify that before putting my foot in my mouth. It has been a while so I don't remember what version, but I definitely recall having to manually edit a project file to remove the GWT nature in order to open it in an Eclipse which did not have GPE installed. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Would GWT and/or incubator be interested in Run Time UiBinding
On Mon, Nov 15, 2010 at 11:42 AM, TedM ted.malask...@gmail.com wrote: The current implementation has the following functionality 1. dynamic forms 2. dynamic workflow 3. submission of form data 4. submission of attachments 5. client and server validation And UI editor on the way. But the current implementation is a project that I'm the architect for. The prototype I put on Google App Engine is a Prototype based on a prototype that I used to sell the idea to my company. To open source this, I would like to do it in the following order. 1. Schedule a meeting with you Google guys the first or second week of December 2. Draw up my designs and clean up my prototype. 3. Then I'll meet with you guys so I can get my design and vision aligned with yours. 4. Then I'll build it to your vision What do you think? This is just a general comment from me personally -- I recognize that there are times that you need dynamic functionality, but realize that you pay a significant cost for it. Typical structures used to handle dynamic content don't optimize well, and the compiler is unable to remove a lot of code because it might be used depending on the data received from the server. Personally, when you can get away with it, you are much better off either generating static code from dynamic data (which of course means recompiling your app) or rendering the dynamic parts on the server. I don't know if either of those are feasible for your use case. Just because something is expensive doesn't meant it shouldn't be in GWT -- if what you need to do is expensive, that doesn't change the fact that you still need to do it. However, it would need to be done in a way so that most people, who do not actually need that functionality, do not wind up using it by mistake or paying the cost because some library they use does. An example is reflection -- it would be possible to implement reflection in GWT, but the problem is that then almost all of the useful optimizations the compiler does goes away. You can never remove a method that isn't referenced (including after inlining it where you can) because there might be a reflective call to it, you can no longer tighten argument types based on the callsites, etc. So, rather than promoting functionality that people definitely want but encourages them to write code that compiles poorly, we chose to leave out reflection. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Patch for Issue 5588: Fix Ant warning about includeantruntime not being set (issue1105801)
On Mon, Nov 15, 2010 at 12:30 PM, Hilco Wijbenga hilco.wijbe...@gmail.com wrote: See http://ant.1045680.n5.nabble.com/warning-includeantruntime-was-not-set-td2639463.html for more details. In short, by default Ant includes its own JARs on javac's classpath. This means the effective classpath depends on where the build is being run. (I.e. it depends on what version of Ant you're running, which extra JARs you've added, etcetera.) This means the build result will most likely be different on different machines. To guarantee a repeatable build, the build should set the classpath, not Ant. By adding includeantruntime=false we say that *we* will take care of the classpath and that Ant should not just dump everything there. It's like saying no to global variables. :-) When was that attribute added? We still have people using ant 1.6.5, so if older ants will fail we can't add that attribute. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Patch for Issue 5588: Fix Ant warning about includeantruntime not being set (issue1105801)
On Mon, Nov 15, 2010 at 1:08 PM, Hilco Wijbenga hilco.wijbe...@gmail.com wrote: In 1.8.0, it doesn't seem to affect older Ants (I just ran the build with 1.7.0). On a side note, I'm not clear why we can't mandate a particular Ant version. Ant 1.8.1 still works with JDK1.4 so no issues there. It's a best practice to provide the tools with the build where possible so we could even do that. Even if people would want to run an older Ant, they could still use GWT's Ant (whatever version it might be) for their GWT code (i.e. their Ant build could call a separate Ant build for the GWT parts). Why do we need to support older Ants? It's not like GWT works with JDK1.4. Especially on Linux distros, many of the ones still in regular use don't have newer ants available by default. If there is a good reason to require an upgrade we can do that, but absent a good reason we shouldn't require manually installing packages on those distros. By the way, are you sure the build works with 1.6.5? I just tried it (without my changes) and I get I will double check, but I believe one of the internal build systems still uses 1.6.5, though it might have been upgraded. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Test timeout in JUnitShell ? (GWT 2.0.0)
On Wed, Oct 20, 2010 at 9:22 AM, Ed post2edb...@gmail.com wrote: I couldn't hold back investigating a bit more. Like described in my last post, the timeout always occurred/started in a GWTTestCase class that contained two test cases that involve RPC calls. I did split up these test cases such that they have their own GWTTestCase class, and the timeout appearantly disappeared as I have seen it now for a week. All tests run fine now. Any idea how/why this is ? After all the debugging/work I get the feeling that there exists some deep hidden bug causing this timeout. .. It's hard to say what the problem is without seeing your code, but take a look at GWT's ValueTypeTest for an example that does very many RPCs in one test class. The important things are: - call delayTestFinish before making the async call - in all cases of the result, make sure to fail the test in some way or call finishTest -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Update the npapi plugin to support OSX. (issue1036801)
On Wed, Oct 20, 2010 at 3:25 PM, Arthur Kalmenson arthur.k...@gmail.comwrote: Is this coming with GWT 2.1? I'm guessing this is a Chrome Extension for Mac OS X The plugins are updated independently of GWT itself, and this can be used with GWT 2.0 as well. Note that Chrome on both Mac and Linux have the same restriction that they don't allow non-localhost access, which is why it isn't being pushed as an official update until that is fixed (the issue is a way to put up the dialog from the NPAPI plugin -- on Windows we cheated with a modal event loop). -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] announce: cross-site RPC using script tag.
On Tue, Oct 19, 2010 at 5:25 AM, Артём artem...@gmail.com wrote: It can be tedious to write a script tag handling JSNI every time you want to communicate with a trusted third-party server via script tag (unless, of course, you're using jQuery or similar library on the page, but even then the error handling could be a problem). Therefore I created the http://code.google.com/p/gwt-script-rpc/ project to incorporate code for such communication. Using it one can communicate with the server using the script tag by writing just a few lines of Java code, e.g. P.S. As always, any ideas are welcome here or in the issues list of the project. One area I currently unsure of is how we can help the script tag user to verify if the server he talks with is authentic (before actually trusting it to be the source of a script tag). Why not use the JSONP support built into GWT? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT 2.1 RC1 javadoc
Ok, I think all the javadoc is updated -- I had to break it into 18 pieces. Sigh. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT 2.1 RC1 javadoc
On Fri, Oct 15, 2010 at 5:58 PM, Thomas Broyer t.bro...@gmail.com wrote: Could anyone please update the online 2.1 javadoc at http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/index.html to RC1 ? (to tell the truth, I'm updating my blog posts about places and activities and either I keep the links to the M3 javadoc, which means there's a mismatch between the post and the linked doc and I'll have to revisit the articles to update the links when the doc is updated, or I update them but they'll be broken until someone updates the javadoc; if links are broken at any point in time, I'd prefer it be now with my current articles based on M3 because the javadoc would be updated to RC1, than once my articles will be updated to RC1 but not the javadoc). I was waiting on one more commit, but since the guy doing it is out sick I will go ahead an update it now, and then update it again later (I am sure there will be further Javadoc updates anyway). -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Selection Cell Option value vs Display Value
On Wed, Oct 13, 2010 at 12:10 PM, John LaBanca jlaba...@google.com wrote: Sound reasonable. Can you open an issue to create a ValueSelectionCell that takes an arbitrary type T and a SafeHtmlRenderer to convert the type T to a String. A simpler option would be to accept MapString,String with the key the select value and the value what is displayed. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Test timeout in JUnitShell ? (GWT 2.0.0)
On Tue, Oct 5, 2010 at 8:47 AM, Ed post2edb...@gmail.com wrote: There are really two apps running in this case. First, there is the one created by JUnitShell, which contacts an RPC servlet to manage running the test. The timeout you see is because that servlet didn't get contacted. Could you please give me some more info and pointers here? I find the GWT Junit code difficult to follow, especially debugging is a bit hard. Where and how does this required servlet get contacted to overcome the timeout? If I follow the service method in GWTShellServlet, I don't understand where the required contact is made. And I can't find the relation with the messageQueue in the method JUnitShell.notdone() that must contain the required info to overcome the timeout exception :( Look at the comment at the top of JUnitShell -- it explains the connections. If you need a real browser to run the test in an automated way, the recommendation would be to use -runStyle Selenium:uri and run a Selenium-RC I also use Selenium, have about 2500 tests that run through Selenium, that take about 50 hours to complete ;)... Some background info: I don't use runstyle for this. I run the tests against production ready code produced during the nigtly build. I run my tests through testNG with Maven surefire plugin. Right, but there your Selenium tests are exercising the running app. I am suggesting it can also be used for running GWTTestCases in a real browser automatically. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Test timeout in JUnitShell ? (GWT 2.0.0)
On Tue, Oct 5, 2010 at 10:12 AM, Ed post2edb...@gmail.com wrote: I found the servlet you meant: JUnitHostImpl I see that the url that touches this servlet is correctly forwarded by the proxy and received by this servlet when debugging in Eclipse: The url that touches it: / com.bv.gwt.profile.intern.ProfileGwtTest.JUnit/junithost (also appears in the logging below) However, when it's running during the nightly build and fails, I's hard to find out what went wrong as the this servlet doesn't contain debug/trace logging. It would be nice to see the path of execution in the logging such that I can see why the servlet isn't touched. Any idea's how to solve this? Or any idea about what would be going wrong ? If it works when you run it directly, yet fails in the continuous build, then something is different between the two that matters. I would suggest running the test in your continuous build environment with remote debugging enabled and attaching to it with a debugger to see what is going on. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
On Fri, Oct 1, 2010 at 1:00 PM, Damon Lundin damon.lun...@gmail.com wrote: Thanks for the help Scott. The problem is not with the delayTestFinish. Apparently our tests are throwing uncaught exceptions which causes the test to finish. The exception does appear in our logs, but it's one of these: Caused by: com.google.gwt.core.client.JavaScriptException: (Error): Unspecified error. number: -2147467259 description: Unspecified error. at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java: 237) Which are not terribly useful (if you have any useful suggestions on dealing with these, I'm all ears) so I moved on to the next exception which was an NPE in our code. That NPE is caused by the tests running on top of each other. So I guess this was my fault for not paying closer attention to the first exception. There is perhaps one possible recommendation that could come out of this and maybe that is that when a test begins (or finishes) it cancels all outstanding timers, commands and pending async callbacks (perhaps optionally). The confusion occurred here because even though the previous test threw an uncaught exception and finished allowing the next test to begin, the outstanding commands started by the previous test were still allowed to run and when they did, they messed up the shared state used by the next test. Of course now I have to go figure out what's causing this uncaught exception to be thrown :-(. And I'm also still confused why the tests pass when run one at a time. If your test code ultimately involves callbacks from the browser event loop from your own code, you need to wrap all such calls in $entry, which hooks up the uncaught exception handler and the Scheduler hooks. All of the GWT widgets/etc that do this already take care of it, but if you write your own you have to handle it. Look at JsopRequest for an example, but basically if you set a callback foo.callback = function()... then that should instead be foo.callback=$entry(function()...). -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
On Fri, Oct 1, 2010 at 1:41 PM, Damon Lundin damon.lun...@gmail.com wrote: I'm not sure I entirely understand. Are you suggesting that I need to convert all of my DeferredCommand calls to ones that use some new native method implementation so I can wrap my callbacks in $entry? No, if you are only using GWT APIs that handle the callback from the browser event loop then that is already taken care of. You didn't say what code you were using, so I thought you might be doing something yourself that needed to be wrapped. If you are only using GWT-supplied APIs, I am not sure how you aren't getting the uncaught exception handler called on those calls. Can you create a small repro case that illustrates the problem? I'm not sure how to cancel outstanding RPC calls if that's even possible. [unrelated] Define your async service interface with a return value of Request instead of void, and then you can call request.cancel() to terminate it. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
On Fri, Oct 1, 2010 at 1:59 PM, Damon Lundin damon.lun...@gmail.com wrote: On Oct 1, 12:51 pm, John Tamplin j...@google.com wrote: If you are only using GWT-supplied APIs, I am not sure how you aren't getting the uncaught exception handler called on those calls. Can you create a small repro case that illustrates the problem? I think you are misunderstanding. The uncaught exception handle *is* getting called. The uncaught exception handler that is setup by the gwttestcase is catching the exception and calling finishTest. The problem is that there are outstanding commands that continue to get executed even though that particular test case just failed and is done. Ok, then just have try/finally around your code to cleanup the state in the test before the exception catching code finishes the test. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT Compiler or widget.gwt.xml file optimisation for 2.1 ?
On Tue, Sep 14, 2010 at 3:00 AM, David david.no...@gmail.com wrote: But anyway, indeed if this is not deemed important to the GWT team I can understand. We have certainly talked about it - I think it has just been a matter of competing priorities. What is important is that we can have the eclipse plugin/browser plugins without the need for an active internet connection. You can do that, though it takes a bit of work -- basically mirror the directory off the server and unpack it, then point the Eclipse update site at the unpacked folder. I did that to install it on my home machine before it was available via any public URL. I don't know if your department that tracks software would find that acceptable or not. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT Compiler or widget.gwt.xml file optimisation for 2.1 ?
On Mon, Sep 13, 2010 at 9:11 AM, David david.no...@gmail.com wrote: It would be acceptable for testing purpose only. releases to production have to be official versions. But it would make it soo much easier to already start using features that should normally be available by the time we go to production. So if the issue is simply having network connectivity, couldn't you just checkout GWT on your own machine, build it there, and bring in the zip the same way as if there were a nightly build? It would have just as much testing as the nightly build would. I am not saying we shouldn't do a nightly build anyway (it is just the opportunity cost of what else we could be doing with that effort), but I am not sure why not having it means you can't use GWT trunk for the same testing purposes already. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Refactoring the Showcase sample to use standards mode, and make use of LayoutPanels. The new Sho... (issue837801)
On Sat, Sep 11, 2010 at 8:56 PM, jlaba...@google.com wrote: Would one of you two be able to review this Monday. I'd like to get it checked in as soon as possible. http://gwt-code-reviews.appspot.com/837801/show I started on it Friday but didn't finish it -- I will finish it Monday. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Java5 varargs not working
On Sat, Sep 11, 2010 at 8:23 PM, jarrod jarrod.carl...@gmail.com wrote: I filed a ticket for this issue... even though the documentation _says_ they're supported, I wasn't able to get varargs working across the Java-JavaScript bridge... at least not in Development mode. Worked fine when compiled, though. http://code.google.com/p/google-web-toolkit/issues/detail?id=5255 Correct, Java arrays (and varargs are shown to the calling code as an array) are opaque objects to Javascript -- all you can do with them is pass them to other Java code. The fact that it works in compiled mode is just due to current implementation details. See http://code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsJSNI.html#sharing -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adds a hack to pre-initialize the Java Graphics2D library. (issue822801)
On Tue, Aug 31, 2010 at 4:09 PM, zun...@google.com wrote: Reviewers: scottb, jat, conroy, fabbott, Description: Adds a hack to pre-initialize the Java Graphics2D library. I've noted varying times to make the first call to grab a Graphics2D object, ranging from 200ms to 6s. This runs the first call in a thread. Please make sure this doesn't interact poorly with GPE and/or GAE on a Mac. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: CurrencyList now uses pure Java in dev mode. (issue771803)
On Fri, Aug 27, 2010 at 9:50 AM, Scott Blum sco...@google.com wrote: Still, shouldn't the generator be able to detect the dups at generation time? Why do that every time you run the generator rather than once when you import the CLDR data? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: CurrencyList now uses pure Java in dev mode. (issue771803)
On Fri, Aug 27, 2010 at 11:28 AM, Scott Blum sco...@google.com wrote:
On Fri, Aug 27, 2010 at 11:21 AM, John Tamplin j...@google.com wrote:
Why do that every time you run the generator rather than once when you
import the CLDR data?
Oh, you know what, I kind of forgot that we're the only ones who actually
implement currency list.
Which actually brings up another interesting point... why have a generator
at all? Why not have the CLDR data importer produce static java files one
time?
I did do exactly that for DateTimeFormatInfo (see
DateTimeFormatInfoImpl_locale.java). When I wrote CLG, I kept the
inheritance hierarchy the same as it was originally which meant that the
actual inheritance between locales could vary depending on how things were
specified (particularly dealing with aliases and default scripts -- ie, if
you specified en_Latn_US then that would be the leaf node which inherited
from en_US rather than the other way around). For DTFI, I decided that the
differences between these were not significant and if someone was doing
something really obscure (like splitting messages into en_US and en_Latn_US
that overlaid each other) they could deal with the change, and it let us
avoid running the generator at all (and some of it was fairly expensive,
calling ICU4J to generate a localized date pattern matching various
criteria).
This could be done the same way, but the version for runtime locales would
have to generate a version that did a runtime switch between the matching
sublocales in a given permutation. So, normally you would just let
GWT.create(CurrencyListImpl.class) return CurrencyListImpl_locale (making
CurrencyList an interface and moving most of the definition to
CurrencyListImpl), but if runtime locales were in use you would have to
generate a CurrencyListImpl_runtime_en which contained something like:
class CurrencyListImpl_runtime_en implements CurrencyList {
private static final CurrencyList INSTANCE;
static {
String runtimeLocale = LocaleInfo.getCurrentLocale().getLocaleName();
if (en_US.equals(runtimeLocale)) {
INSTANCE = new CurrencyListImpl_en_US();
} else if (en_AU.equals(runtimeLocale)) {
INSTANCE = new CurrencyListImpl_en_AU();
} ... other locales supported by the app that inherit from en
} else {
INSTANCE = new CurrencyListImpl_en();
}
}
// delegate everything to INSTANCE.foo
}
So the generator algorithm would look like this:
- If runtime locales are in use, generate a runtime-selection
implementation and return that class
- Otherwise, find the best match of CurrencyListImpl_locale and return
that name
In fact, that could probably just be LocalizableGenerator's approach so
user-written Localizable subclasses would get the benefit.
In summary, yes it could happen and it would probably be a good idea, but it
is a lot of work.
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
