[gwt-contrib] Re: Change the superclass of the translatable version of (issue1565803)
LGTM
On Oct 6, 2011 5:07 PM, wrote:
> Reviewers: rjrjr,
>
> Description:
> Change the superclass of the translatable version of
> junit.framework.AssertionFailedError to match the JVM version,
> for consistency when catching java.lang.AssertionError in
> testing tools.
>
> Fixes issue 6863.
>
>
> Please review this at http://gwt-code-reviews.appspot.com/1565803/
>
> Affected files:
> M
>
user/super/com/google/gwt/junit/translatable/junit/framework/AssertionFailedError.java
>
>
> Index:
>
user/super/com/google/gwt/junit/translatable/junit/framework/AssertionFailedError.java
> ===
> ---
>
user/super/com/google/gwt/junit/translatable/junit/framework/AssertionFailedError.java
> (revision 10689)
> +++
>
user/super/com/google/gwt/junit/translatable/junit/framework/AssertionFailedError.java
> (working copy)
> @@ -18,7 +18,7 @@
> /**
> * Translatable version of JUnit's AssertionFailedError.
> */
> -public class AssertionFailedError extends Error {
> +public class AssertionFailedError extends AssertionError {
>
> public AssertionFailedError() {
> }
>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: More control over split point fragments
On 06/10/2011 07:27, Alan Leung wrote:
I have studied Lex Spoon's writeup extensively a few weeks back. While
I do believe it is beneficial to leftover code size,
when I bought it up with some of the internal projects, they believe
the cache-ability lost with multiple leftover fragments is not
something they'd trade off.
I don't really understand this point. Smaller fragments are still
strongly cachable - there are just more download requests, no? In a
multi-page app it is likely that most of the code in the left overs
fragment (used in other pages) will not be needed.
That's why I went down the fragment merging route.
Im about to make some very naive suggestions out of desperation to get
my website running fast again. The left overs size is killing it.
What about if we could define a list of package names (patterns) that
would be kept in the same fragment? I would like to keep all
gwt.client.ui classes together.
If there were some annotation like @DoNotSplit that stopped code from a
single class being distributed amongst multiple fragments that would
give more control of where code ends up.
@DoNotSplit
class WidgetFactory
{
// async provider pattern to access
Label lable()
{
return new Label();
}
}
Or what about a @KeepCodeHere annotation! That would force all code
generated from a certain statement to remain in the current fragment -
not move to the left overs.
@KeepCodeHere Label label = new Label();
That would essentially make the fragment an "initial fragment" for any
other fragment that also used a label or any of its class hierarchy.
This would at least keep the code for the label() method with the
fragment for the WidgetFactory - currently it ends up in the fragment
that calls the label() method - or most likely in the left overs
fragment because label() will be called from multiple places.
Still, it would be much nicer if GWT could figure out what common code
to put in an exclusive fragment that is guaranteed to be loaded before
another (i.e. put code in W that is common to W1 and W2).
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Change the superclass of the translatable version of (issue1565803)
Reviewers: rjrjr,
Description:
Change the superclass of the translatable version of
junit.framework.AssertionFailedError to match the JVM version,
for consistency when catching java.lang.AssertionError in
testing tools.
Fixes issue 6863.
Please review this at http://gwt-code-reviews.appspot.com/1565803/
Affected files:
M
user/super/com/google/gwt/junit/translatable/junit/framework/AssertionFailedError.java
Index:
user/super/com/google/gwt/junit/translatable/junit/framework/AssertionFailedError.java
===
---
user/super/com/google/gwt/junit/translatable/junit/framework/AssertionFailedError.java
(revision 10689)
+++
user/super/com/google/gwt/junit/translatable/junit/framework/AssertionFailedError.java
(working copy)
@@ -18,7 +18,7 @@
/**
* Translatable version of JUnit's AssertionFailedError.
*/
-public class AssertionFailedError extends Error {
+public class AssertionFailedError extends AssertionError {
public AssertionFailedError() {
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: gwt issues marked as "patcheswelcome" don't show up under open issues
You make some good points, so we have reverted it back to "open". -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: gwt issues marked as "patcheswelcome" don't show up under open issues
Is there a way to add patcheswelcome to the dropdown of the issue tracker? I think people will not find these issues and know to work on them. If I went to the issue tracker hoping to work on something where I would be able to help out the gwt community, I would start looking at open issues. I would not look at closed issues, closed issues would indicate to me that they are either not going to be done, and that is by design, or those issues are fixed. I would probably never know these issues existed. These issues seem like they are still open, just that they aren't issues that the gwt team will devote time to implement. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: gwt issues marked as "patcheswelcome" don't show up under open issues
At least for the moment, that is intentional. As you probably know, the GWT issue tracker has not had a lot of love lately, and we would like to fix that. We are undertaking a multi-week project to triage as many of the open issues as we can. We would like to close stale, invalid, fixed & duplicate issues, assign owners as appropriate, or mark issues as "PatchesWelcome" if it is something that we think is a reasonable idea but not something we (the GWT development team) are going to commit to. By treating "PatchesWelcome" as a closed state, we are, in essence, making a positive indication that, while we are happy to look at a patch, we are not going to address this ourselves (similar to "NotPlanned"). We are willing to be convinced otherwise, if folks think it is a bad idea. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] gwt issues marked as "patcheswelcome" don't show up under open issues
All the issues marked patcheswelcome are reasonably hidden from view because they do not show up as open anymore. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Make client-side JUnit 3 classes available without GWTTestCase. (issue1564803)
LGTM http://gwt-code-reviews.appspot.com/1564803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: More control over split point fragments
On Thursday, 6 October 2011 01:02:10 UTC+7, John A. Tamplin wrote: > > The basic code splitting algorithm can handle this, > Can you give some more details? I have not seen a solution to this problem yet. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Firefox 7 DevMode Plugin (issue1560803)
On 2011/10/05 09:13:29, tbroyer wrote: http://gwt-code-reviews.appspot.com/1560803/diff/3001/plugins/xpcom/Makefile File plugins/xpcom/Makefile (right): http://gwt-code-reviews.appspot.com/1560803/diff/3001/plugins/xpcom/Makefile#newcode125 plugins/xpcom/Makefile:125: ifeq ($(BROWSER),ff70) On 2011/10/05 07:34:06, acleung wrote: > On 2011/10/04 23:11:19, conroy wrote: > > so, i'm responsible for starting the cascade here, but I think now would be a > > good opportunity to clean up this section of the makefile by consolidating all > > the option settings for ff40+ rather than copy pasting this stanza every 6 > weeks > > It seems like GNU Make doesn't have any other fancy control flow like > switch-case. It doesn't even have something like if-greater-than. We would have > to use shell's expr. Since we still have to set -DGECKO_VERSION, I think this is > still cleaner. How about moving the MOZALLOC_DLLFLAGS, MOZJS_DLLFLAGS and ALLARCHCFLAGS befire the "ifeq ($(BROWSER),ff40)"? That would leave only the GECKO_VERSION and CFLAGS in each version-specific ifeq/endif block, as with ff3 to ff36 blocks. LGTM I think tbroyer's suggestions are worth considering. It might clean things up to change the if-else sequence to just a set of independent if statements concluded by checking that *some* GECKO_VERSION got set. I won't hold this CL up on this cosmetic change though, so feel free to defer this or just punt it back onto me. http://gwt-code-reviews.appspot.com/1560803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Activity
Hi, Recently GWT development activity seems to have slowed down. Also hardly any Twitter or blog posts. Is this a slowdown after Google IO / Google Plus / GWT 2.4? Or is something else going on? Thanks, Mathias -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] More control over split point fragments
On 05/10/2011 23:53, Ray Cromwell wrote:
You could try making a split point which contains other split points,
something like this:
I = Initial Fragment
W - Split point from which all Widget using splitpoints exist
W1 - Widget using split point 1
W2 - Widget using split point 2
G - Split point from which all GQuery using code exists
G1 - GQuery split point page 1
I don't remember if this is so, but if all Widget using code ends up
exclusive to W, then it won't be in the leftovers fragment.
Yes this is how I would like it to work but unfortunately it puts all
the common code from W1 and W2 into the leftovers fragment and not the
common "parent" W
My test code below creates a Lable and a Button in different split
points that have a common parent split point:
public void onModuleLoad()
{
GWT.runAsync(Widget.class, new Callback()
{
@Override
public void onSuccess()
{
GWT.runAsync(Label.class, new Callback()
{
@Override
public void onSuccess()
{
RootPanel.get().add(new Label("Hello"));
}
});
GWT.runAsync(Button.class, new Callback()
{
@Override
public void onSuccess()
{
RootPanel.get().add(new Button("World"));
}
});
}
});
}
The left overs fragment contains 25K of code and each of the 3 split
points contain a trivial 1K or 2K
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
