date:20081208


Author: [EMAIL PROTECTED]
Date: Mon Dec  8 18:56:00 2008
New Revision: 4273

Modified:
trunk/tools/soyc-vis/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java

Log:
Small change to cut out runAsync display until we (Lex, I) decide on how  
runAsync and SOYC should be integrated.



Modified:  
trunk/tools/soyc-vis/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java
==
---  
trunk/tools/soyc-vis/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java   
 
(original)
+++  
trunk/tools/soyc-vis/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java   
 
Mon Dec  8 18:56:00 2008
@@ -118,7 +118,7 @@



-if (GlobalInformation.fragmentToStories.size() == 1){
+if (GlobalInformation.fragmentToStories.size() != 1){
outFile.println("  ");
outFile.println("Fragments breakdown");
outFile.println("");
@@ -1172,10 +1172,9 @@

  if  
(nameToLitColl.get("string").stringLiteralToType.get(literal).compareTo(literalType)
  
== 0){

-if (literal.trim().compareTo("") == 0){
+  if (literal.trim().compareTo("") == 0){
  literal = "[whitespace only string]";
}
-

String newLiteral = "";
if(literal.length() > 80){
@@ -1229,23 +1228,18 @@
outFile.println("");
  }
  ct++;
-
}
-
-
outFile.println("");
-
-}
-
-outFile.println("");
-outFile.println("");
-
-
-outFile.println("");
-outFile.println("");
-outFile.println("");
-outFile.close();
-   }
+}
+  }
+
+  outFile.println("");
+  outFile.println("");
+
+  outFile.println("");
+  outFile.println("");
+  outFile.println("");
+  outFile.close();
  }
}


--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Why is Timer#schedule(0) bad?


I've always assumed that 0 wasn't portable and use 10 by convention.
Ideally, you'd want 0 to function like yield(), but I had a nagging
suspicious that some browsers might treat 0 as a NOP (that is, run the
code immediately without yielding)


On Mon, Dec 8, 2008 at 5:21 PM, John Tamplin <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 8, 2008 at 8:08 PM, Ray Ryan <[EMAIL PROTECTED]> wrote:
>>
>> Bob and I were just startled to see that you can't set schedule a timer to
>> zero:
>>
>>   /**
>>
>>* Schedules a timer to elapse in the future.
>>
>>*
>>
>>* @param delayMillis how long to wait before the timer elapses, in
>>
>>*  milliseconds
>>
>>*/
>>
>>   public void schedule(int delayMillis) {
>>
>> if (delayMillis <= 0) {
>>
>>   throw new IllegalArgumentException("must be positive");
>>
>> }
>>
>> ...
>>
>> 0 is JavaScript's convention for "do this in the next cycle of the event
>> pump." Why are we preventing its use?
>
> I think I remember something where one of the browsers did something
> different on 0.  Perhaps Joel or Kelly can confirm that.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Tweaks to API checker

2008-12-08 Thread Amit Manjhi

LGTM

On Mon, Dec 8, 2008 at 6:40 PM, <[EMAIL PROTECTED]> wrote:

> Reviewers: amitmanjhi,
>
> Description:
> Amit,
>
>  This patch changes the gwt build.xml file to use value rather then
> location when defining the apicheck.oldroot ant property + adds the
> removal the old setImageBase method.
>
> Please review this at http://gwt-code-reviews.appspot.com/602
>
> Affected files:
>  build.xml
>  tools/api-checker/config/gwt15_16userApi.conf
>
>
> Index: build.xml
> ===
> --- build.xml   (revision 4269)
> +++ build.xml   (working copy)
> @@ -9,7 +9,7 @@
>location="tools/api-checker/config/gwt15_16userApi.conf"/>
>-location="../gwt-1.5"/>
> +value="../gwt-1.5"/>
>
>   
> 
> Index: tools/api-checker/config/gwt15_16userApi.conf
> ===
> --- tools/api-checker/config/gwt15_16userApi.conf   (revision 4269)
> +++ tools/api-checker/config/gwt15_16userApi.conf   (working copy)
> @@ -30,3 +30,4 @@
>  java.lang.StringBuilder::append(Ljava/lang/StringBuffer;)
> OVERRIDABLE_METHOD_ARGUMENT_TYPE_CHANGE
>  
> com.google.gwt.user.client.ui.Button::Button(Ljava/lang/String;Lcom/google/gwt/user/client/ui/ClickListener;)
> OVERLOADED_METHOD_CALL
>  
> com.google.gwt.user.client.ui.ToggleButton::ToggleButton(Lcom/google/gwt/user/client/ui/Image;Lcom/google/gwt/user/client/ui/Image;Lcom/google/gwt/user/client/ui/ClickListener;)
> OVERLOADED_METHOD_CALL
> +com.google.gwt.user.client.ui.Tree::setImageBase(Ljava/lang/String;)
> MISSING
> \ No newline at end of file
>
>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Why is Timer#schedule(0) bad?

2008-12-08 Thread John Tamplin

On Mon, Dec 8, 2008 at 8:08 PM, Ray Ryan <[EMAIL PROTECTED]> wrote:

> Bob and I were just startled to see that you can't set schedule a timer to
> zero:
>
>   /**
>
>* Schedules a timer to elapse in the future.
>
>*
>
>* @param delayMillis how long to wait before the timer elapses, in
>
>*  milliseconds
>
>*/
>
>   public void schedule(int delayMillis) {
>
> if (delayMillis <= 0) {
>
>   throw new IllegalArgumentException("must be positive");
>
> }
>
> ...
>
> 0 is JavaScript's convention for "do this in the next cycle of the event
> pump." Why are we preventing its use?
>

I think I remember something where one of the browsers did something
different on 0.  Perhaps Joel or Kelly can confirm that.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Why is Timer#schedule(0) bad?

2008-12-08 Thread Bruce Johnson

I can't think of a good reason historically. IMO, it's a bug.

On Mon, Dec 8, 2008 at 8:08 PM, Ray Ryan <[EMAIL PROTECTED]> wrote:

> Bob and I were just startled to see that you can't set schedule a timer to
> zero:
>
>   /**
>
>* Schedules a timer to elapse in the future.
>
>*
>
>* @param delayMillis how long to wait before the timer elapses, in
>
>*  milliseconds
>
>*/
>
>   public void schedule(int delayMillis) {
>
> if (delayMillis <= 0) {
>
>   throw new IllegalArgumentException("must be positive");
>
> }
>
> ...
>
> 0 is JavaScript's convention for "do this in the next cycle of the event
> pump." Why are we preventing its use?
> rjrjr
>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Why is Timer#schedule(0) bad?

2008-12-08 Thread Ray Ryan

Bob and I were just startled to see that you can't set schedule a timer to
zero:

  /**

   * Schedules a timer to elapse in the future.

   *

   * @param delayMillis how long to wait before the timer elapses, in

   *  milliseconds

   */

  public void schedule(int delayMillis) {

if (delayMillis <= 0) {

  throw new IllegalArgumentException("must be positive");

}

...

0 is JavaScript's convention for "do this in the next cycle of the event
pump." Why are we preventing its use?
rjrjr

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Tweaks to API checker

2008-12-08 Thread ecc


Reviewers: amitmanjhi,

Description:
Amit,

   This patch changes the gwt build.xml file to use value rather then
location when defining the apicheck.oldroot ant property + adds the
removal the old setImageBase method.

Please review this at http://gwt-code-reviews.appspot.com/602

Affected files:
   build.xml
   tools/api-checker/config/gwt15_16userApi.conf


Index: build.xml
===
--- build.xml   (revision 4269)
+++ build.xml   (working copy)
@@ -9,7 +9,7 @@


+value="../gwt-1.5"/>


  
Index: tools/api-checker/config/gwt15_16userApi.conf
===
--- tools/api-checker/config/gwt15_16userApi.conf   (revision 4269)
+++ tools/api-checker/config/gwt15_16userApi.conf   (working copy)
@@ -30,3 +30,4 @@
  java.lang.StringBuilder::append(Ljava/lang/StringBuffer;)  
OVERRIDABLE_METHOD_ARGUMENT_TYPE_CHANGE
   
com.google.gwt.user.client.ui.Button::Button(Ljava/lang/String;Lcom/google/gwt/user/client/ui/ClickListener;)
  
OVERLOADED_METHOD_CALL
   
com.google.gwt.user.client.ui.ToggleButton::ToggleButton(Lcom/google/gwt/user/client/ui/Image;Lcom/google/gwt/user/client/ui/Image;Lcom/google/gwt/user/client/ui/ClickListener;)
  
OVERLOADED_METHOD_CALL
+com.google.gwt.user.client.ui.Tree::setImageBase(Ljava/lang/String;)  
MISSING
\ No newline at end of file



--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: getAbsoluteLeft/Top() returns incorrect value in IE when zoomed in

2008-12-08 Thread ecc


Have you checked to see what values getAbsoluteLeft/Top give in your
demo with Firefox3 and Opera? It seems like we want all the real zooming
browsers to handle this the same way.

Also, can you check what happens when you use your patched
getAbsoluteLeft + getAbsoluteTop to calculate the distance between two
widgets? For example

Widget a (absolutely positioned at (100,100) 50 px tall.

Widget b flows naturally after widget a. There are no styles on any
widget to confuse this poor example.

Widget c's height is calculated to be getAbsoluteTop(a) -
getAbsoluteTop(b)

is Widget c's height the same as widget a's?


http://gwt-code-reviews.appspot.com/807

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit] jieryn commented on revision r4272.


[google-web-toolkit] jieryn commented on revision r4272.
Details are at  
http://code.google.com/p/google-web-toolkit/source/detail?r=4272

Score: Positive

General Comment:
Great, thank you GWT-team! :-)

Respond to these comments at  
http://code.google.com/p/google-web-toolkit/source/detail?r=4272
--
You received this message because you starred this review, or because
your project has directed all notifications to a mailing list that you
subscribe to.
You may adjust your review notification preferences at:
http://code.google.com/hosting/settings

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r4272 - releases/1.6/user/super/com/google/gwt/emul/java/util


Author: [EMAIL PROTECTED]
Date: Mon Dec  8 14:52:40 2008
New Revision: 4272

Modified:
releases/1.6/user/super/com/google/gwt/emul/java/util/TreeSet.java

Log:
Updated the comment and made the instance member private.

Patch by: amitmanjhi
Review by: jat (desk review)



Modified: releases/1.6/user/super/com/google/gwt/emul/java/util/TreeSet.java
==
--- releases/1.6/user/super/com/google/gwt/emul/java/util/TreeSet.java   
(original)
+++ releases/1.6/user/super/com/google/gwt/emul/java/util/TreeSet.java  Mon  
Dec  8 14:52:40 2008
@@ -27,9 +27,9 @@
  public class TreeSet extends AbstractSet implements SortedSet,  
Serializable {

/**
-   * TreeSet is stored as a TreeMap of the requested type to a constant  
integer.
+   * TreeSet is stored as a TreeMap of the requested type to a constant  
Boolean.
 */
-  SortedMap map;
+  private SortedMap map;

public TreeSet() {
  map = new TreeMap();
@@ -65,7 +65,7 @@

@Override
public boolean add(E o) {
-// Use "this" as a convenient non-null value to store in the map
+// Use Boolean.FALSE as a convenient non-null value to store in the map
  return map.put(o, Boolean.FALSE) == null;
}


--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit] amitman...@google.com commented on revision r3853.


[google-web-toolkit] [EMAIL PROTECTED] commented on revision r3853.
Details are at  
http://code.google.com/p/google-web-toolkit/source/detail?r=3853

Score: Positive

General Comment:
Thanks for the comments. Incorporated in r4272.

Respond to these comments at  
http://code.google.com/p/google-web-toolkit/source/detail?r=3853
--
You received this message because you starred this review, or because
your project has directed all notifications to a mailing list that you
subscribe to.
You may adjust your review notification preferences at:
http://code.google.com/hosting/settings

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Add NativePreviewEvent to replace current EventPreview system

2008-12-08 Thread ecc


This is looking very nice, I think the structure is great. We have a few
issues to work on which are mentioned in in-line comments.


http://gwt-code-reviews.appspot.com/805/diff/1/5
File user/src/com/google/gwt/event/shared/GwtEvent.java (right):

http://gwt-code-reviews.appspot.com/805/diff/1/5#newcode139
Line 139: /**
Should this method be final? As we've regretted making onDetach not
final. Also, I think you meant rely

http://gwt-code-reviews.appspot.com/805/diff/1/9
File user/src/com/google/gwt/user/client/Event.java (right):

http://gwt-code-reviews.appspot.com/805/diff/1/9#newcode187
Line 187: protected void kill() {
can you document the method that requires access to kill here?

http://gwt-code-reviews.appspot.com/805/diff/1/9#newcode482
Line 482: NativePreviewEvent event = new
NativePreviewEvent(nativeEvent);
I think we might want to recycle the native event here for efficiency.

http://gwt-code-reviews.appspot.com/805/diff/1/11
File user/src/com/google/gwt/user/client/ui/DialogBox.java (left):

http://gwt-code-reviews.appspot.com/805/diff/1/11#oldcode231
Line 231:
As much as I'd really, really love to do this, I think backward
compatibility forces us to deprecate the method rather then removing it.

http://gwt-code-reviews.appspot.com/805/diff/1/11
File user/src/com/google/gwt/user/client/ui/DialogBox.java (right):

http://gwt-code-reviews.appspot.com/805/diff/1/11#newcode392
Line 392:
do we want to expose this?

http://gwt-code-reviews.appspot.com/805/diff/1/13
File user/src/com/google/gwt/user/client/ui/MenuBar.java (left):

http://gwt-code-reviews.appspot.com/805/diff/1/13#oldcode966
Line 966: public boolean onEventPreview(Event event) {
See comments from DialogBox.

http://gwt-code-reviews.appspot.com/805/diff/1/13
File user/src/com/google/gwt/user/client/ui/MenuBar.java (right):

http://gwt-code-reviews.appspot.com/805/diff/1/13#newcode967
Line 967: protected void onPreviewNativeEvent(NativePreviewEvent event)
{
See comments from DialogBox.

http://gwt-code-reviews.appspot.com/805/diff/1/12
File user/src/com/google/gwt/user/client/ui/PopupPanel.java (right):

http://gwt-code-reviews.appspot.com/805/diff/1/12#newcode464
Line 464: */
Where is the onPreviewNativeEvent for this one?

http://gwt-code-reviews.appspot.com/805/diff/1/3
File user/test/com/google/gwt/user/client/EventTest.java (right):

http://gwt-code-reviews.appspot.com/805/diff/1/3#newcode26
Line 26: public class EventTest extends GWTTestCase {
Nice Test!

I think the only thing you need to add is the interactions of code that
mixes the old and new styles.
For example:
Use adds a new style preview, then an old style preview.  What order
should they be evaluated in?

http://gwt-code-reviews.appspot.com/805

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] RR: skip runAsync cruft when there is no call to runAsync


Kelly,

Can you review the patch I attached to issue 3121?

http://code.google.com/p/google-web-toolkit/issues/detail?id=3121

In particular, does it eliminate the cruft in the trivial app you
initially tried with, and still leave the app working?

Lex

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r4270 - trunk/tools/soyc-vis/src/com/google/gwt/soyc


Author: [EMAIL PROTECTED]
Date: Mon Dec  8 14:05:13 2008
New Revision: 4270

Modified:
trunk/tools/soyc-vis/src/com/google/gwt/soyc/SoycDashboard.java

Log:
Allowing dashboard to read gzipped input, since that's what we emit.

Review by: kprobst

Modified: trunk/tools/soyc-vis/src/com/google/gwt/soyc/SoycDashboard.java
==
--- trunk/tools/soyc-vis/src/com/google/gwt/soyc/SoycDashboard.java  
(original)
+++ trunk/tools/soyc-vis/src/com/google/gwt/soyc/SoycDashboard.java Mon  
Dec  8 14:05:13 2008
@@ -25,6 +25,7 @@
  import java.util.HashSet;
  import java.util.TreeSet;
  import java.util.TreeMap;
+import java.util.zip.GZIPInputStream;
  import javax.xml.parsers.*;

  public class SoycDashboard {
@@ -37,7 +38,7 @@
public static void main(String[] args) {

  if (args.length != 1){
-  System.err.println("Usage: java com/google/gwt/soyc/SoycDashboard  
soyc-report0.xml");
+  System.err.println("Usage: java com/google/gwt/soyc/SoycDashboard  
soyc-report0.xml[.gz]");
System.exit(1);
  }

@@ -75,10 +76,12 @@
  factory.setNamespaceAware(true);
  try {
SAXParser saxParser = factory.newSAXParser();
-  InputStream in = new BufferedInputStream(new  
FileInputStream(inFileName));
+  InputStream in = new FileInputStream(inFileName);
+  if (inFileName.endsWith(".gz")) {
+in = new GZIPInputStream(in);
+  }
+  in = new BufferedInputStream(in);
saxParser.parse(in,fragmentCountHandler);
-
-
  } catch (ParserConfigurationException e) {
throw new RuntimeException("Could not parse document. ", e);
  } catch (SAXException e) {
@@ -99,10 +102,12 @@
  factoryMain.setNamespaceAware(true);
  try {
SAXParser saxParser = factoryMain.newSAXParser();
-  InputStream in = new BufferedInputStream(new  
FileInputStream(inFileName));
+  InputStream in = new FileInputStream(inFileName);
+  if (inFileName.endsWith(".gz")) {
+in = new GZIPInputStream(in);
+  }
+  in = new BufferedInputStream(in);
saxParser.parse(in,handler);
-
-
  } catch (ParserConfigurationException e) {
throw new RuntimeException("Could not parse document. ", e);
  } catch (SAXException e) {

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r4271 - in trunk: distro-source/linux distro-source/mac distro-source/windows tools/soyc-vis


Author: [EMAIL PROTECTED]
Date: Mon Dec  8 14:06:45 2008
New Revision: 4271

Modified:
trunk/distro-source/linux/build.xml
trunk/distro-source/mac/build.xml
trunk/distro-source/windows/build.xml
trunk/tools/soyc-vis/build.xml

Log:
Including gwt-soyc-vis.jar in the distribution.

Review by: kprobst

Modified: trunk/distro-source/linux/build.xml
==
--- trunk/distro-source/linux/build.xml (original)
+++ trunk/distro-source/linux/build.xml Mon Dec  8 14:06:45 2008
@@ -13,6 +13,7 @@



+  




Modified: trunk/distro-source/mac/build.xml
==
--- trunk/distro-source/mac/build.xml   (original)
+++ trunk/distro-source/mac/build.xml   Mon Dec  8 14:06:45 2008
@@ -13,6 +13,7 @@



+  




Modified: trunk/distro-source/windows/build.xml
==
--- trunk/distro-source/windows/build.xml   (original)
+++ trunk/distro-source/windows/build.xml   Mon Dec  8 14:06:45 2008
@@ -13,6 +13,7 @@



+  




Modified: trunk/tools/soyc-vis/build.xml
==
--- trunk/tools/soyc-vis/build.xml  (original)
+++ trunk/tools/soyc-vis/build.xml  Mon Dec  8 14:06:45 2008
@@ -1,21 +1,31 @@
  

-
+

-
-
-
+  
+  
+  

-
-
-
-
+  
+
+  

-
+  
+
+
+  

-
+  
+
+  
+  
+
+  
+
+  

-
-
+  
+
+  

  

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

Re: RR: CssResourceGenerator patch for GWT compiler bug (was Re: [gwt-contrib] Re: Very Strange Compiler Bug: Works in JDK1.5, fails in 1.6)


Thanks Bob.

-Ray


On Mon, Dec 8, 2008 at 1:51 PM, BobV <[EMAIL PROTECTED]> wrote:
>
> Committed at r1285 with style and comment fixes.
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: code review: issues_3166_3167_gwt16_r4353.patch

2008-12-08 Thread Ray Ryan

LGTM
Rietveld can't show inter-diff diffs, so I can't see, say, your version 1
and comments on the left and the new patch on the right. That's a shame.

rjrjr

On Tue, Dec 9, 2008 at 7:50 AM, Joel Webber <[EMAIL PROTECTED]> wrote:

> Don't know why I can't attach another patch set to that codereview
> instance, so here it is. Maybe you can attach it (or maybe I'm just dumb and
> can't figure it out).
>
>
> On Mon, Dec 8, 2008 at 3:48 PM, <[EMAIL PROTECTED]> wrote:
>
>> For reasons not clear to me, I can't seem to add an updated patch set.
>> I'll send it to the gwt-contrib thread and hope you can do it :)
>>
>>
>> http://codereview.appspot.com/8894/diff/1/9
>> File user/src/com/google/gwt/user/client/Event.java (right):
>>
>> http://codereview.appspot.com/8894/diff/1/9#newcode287
>> Line 287: * @param detail the event's detail property
>> On 2008/12/05 00:13:15, rjrjr wrote:
>>
>>> Any example of valid values of detail?
>>>
>>
>> Detail is one of those weird fields that means different things for
>> different events. It's defined as part of the DOM spec (in other words,
>> if you don't know what it is, you probably won't care).
>>
>> http://codereview.appspot.com/8894/diff/1/7
>> File user/src/com/google/gwt/user/client/impl/DOMImplIE6.java (right):
>>
>> http://codereview.appspot.com/8894/diff/1/7#newcode230
>> Line 230: evt.relatedTarget = relatedTarget;
>> On 2008/12/05 00:13:15, rjrjr wrote:
>>
>>> (Pretending I know what I'm talking about.) relatedTarget is a real
>>>
>> field in
>>
>>> correct browsers, right? Is it a bit confusing to use it here in IE,
>>>
>> where it
>>
>>> normally doesn't exist? Could we call this gwtTarget instead?
>>>
>>
>> Well, we're actually synthesizing a value that *is* identical to
>> relatedTarget on other browsers (and that IE doesn't implement), so it
>> doesn't seem unreasonable to simply synthesize it here.
>>
>> In the long run, it would make more sense to shift the public APIs to
>> use 'relatedTarget', but that's probably a task for another day.
>>
>> http://codereview.appspot.com/8894/diff/1/10
>> File user/src/com/google/gwt/user/client/ui/CustomButton.java (right):
>>
>> http://codereview.appspot.com/8894/diff/1/10#newcode746
>> Line 746: // TODO(jgw): fill in these parameters somehow.
>> On 2008/12/05 00:13:15, rjrjr wrote:
>>
>>> If this is actually possible, could you file an issue on it and point
>>>
>> to the
>>
>>> issue here? Also, do we usually put our initials in our TODOs? (I hope
>>>
>> so, but
>>
>>> thought I got scolded for doing so.)
>>>
>>
>> Whoops, I didn't mean to leave this TODO in there. I've changed this
>> comment to explain why those values are unavailable (this shouldn't
>> matter in practice, as click events often don't have useful mouse
>> coordinates).
>>
>> http://codereview.appspot.com/8894/diff/1/4
>> File user/test/com/google/gwt/user/client/ui/CustomButtonTest.java
>> (right):
>>
>> http://codereview.appspot.com/8894/diff/1/4#newcode178
>> Line 178: assertEquals("Expecting one click event", "click",
>> events.get(0));
>> On 2008/12/05 00:13:15, rjrjr wrote:
>>
>>> I guess you're doing all three (over, down, up) b/c triggerClickEvent
>>>
>> can't be
>>
>>> relied upon to do so? You might document that.
>>>
>>
>> Actually, this is intended to test that this series of events should
>> *cause* CustomButton to fire a synthetic click event. I've added
>> documentation to that effect.
>>
>> http://codereview.appspot.com/8894/diff/1/3
>> File user/test/com/google/gwt/user/client/ui/TriggerEventTest.java
>> (right):
>>
>> http://codereview.appspot.com/8894/diff/1/3#newcode30
>> Line 30: public class TriggerEventTest extends GWTTestCase {
>> On 2008/12/05 00:13:15, rjrjr wrote:
>>
>>> A thing of beauty. I have to take your word on which events bubble and
>>>
>> which
>>
>>> don't. But then again I suppose I have the word of the tests
>>>
>> themselves. :-)
>>
>>>
>>> Should you be testing capture as well? Or does GWT stay clear of that?
>>>
>>
>> We don't do event capture, because there's really no reliable way to
>> synthesize it on IE (it's sort of possible, but there are all kinds of
>> edge cases that can't be made to work sensibly).
>>
>> http://codereview.appspot.com/8894/diff/1/3#newcode57
>> Line 57: assertTrue("Expecting child to receive the event before
>> parent",
>> On 2008/12/05 00:13:15, rjrjr wrote:
>>
>>> "Expecting parent to receive the event after the child", to avoid a
>>>
>> dup message
>>
>> Done.
>>
>> http://codereview.appspot.com/8894/diff/1/3#newcode157
>> Line 157: init();
>> On 2008/12/05 00:13:15, rjrjr wrote:
>>
>>> just call this from gwtSetup rather than in each method
>>>
>>
>> Whoops, thanks. That's a lot simpler, isn't it?
>>
>> http://codereview.appspot.com/8894/diff/1/3#newcode166
>> Line 166: Event.triggerClickEvent(child, 0, 0, 0, 0, 0, false, false,
>> false, false);
>> On 2008/12/05 00:13:15, rjrjr wrote:
>>
>>> Seems like you should test all three core event types here.
>>>
>>
>> Good point. Just r

[gwt-contrib] Re: review: shouldn't soyc-vis handle compression?

2008-12-08 Thread Katharina Probst

LGTM.  Thanks, Freeland!

kathrin

On Mon, Dec 8, 2008 at 3:59 PM, Freeland Abbott <[EMAIL PROTECTED]> wrote:

> Since we generate compressed output, wouldn't it be nice to handle it as
> input?  (We don't seem to need any of the reports but report0.xml[.gz], so
> it's just the one stream insertion.)
>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

Re: RR: CssResourceGenerator patch for GWT compiler bug (was Re: [gwt-contrib] Re: Very Strange Compiler Bug: Works in JDK1.5, fails in 1.6)

2008-12-08 Thread BobV


Committed at r1285 with style and comment fixes.

-- 
Bob Vawter
Google Web Toolkit Team

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Problem with certain failure cases in GWTTestCase

2008-12-08 Thread Joel Webber

Actually, we can make this a lot easier by just going to the issue that Ray
set up here:  http://codereview.appspot.com/8894

If you could comment on the junit changes, that would be great.

On Thu, Dec 4, 2008 at 4:40 PM, Joel Webber <[EMAIL PROTECTED]> wrote:

> I've added tests to cover all the additional cases you describe, and it
> looks like everything is working "as expected", assuming that by "as
> expected" we mean "it's possible for one test to cause the next to fail if
> it leaves a pending event around". I don't see any way around this that
> doesn't involve a massive rearchitecture, and this problem has always
> existed in one way or another.
>
> --- code review request ---
> I've made the change I proposed earlier, in the attached patch. I added
> some extra test cases to the manual JUnit tests in order to make sure we
> don't screw this up in the future. Please ignore all the event triggering
> stuff in there -- I needed it to be able to exercise the JUnit failure, but
> can't commit it until I get the tests working properly.
>
> Branch: /releases/1.6
> Issue: 3167
>
> On Wed, Dec 3, 2008 at 8:39 PM, Scott Blum <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Dec 3, 2008 at 3:11 PM, Joel Webber <[EMAIL PROTECTED]> wrote:
>>
>>> So here are all the ways I can think of for a test method to complete,
>>> either synchronously or asynchronously. Those not explicitly marked as such
>>> work properly.
>>>
>>> Normal synchronous test methods:
>>> - Test method completes successfully and synchronously.
>>> - Test method triggers an exception synchronously (*not* from within an
>>> event handler).
>>>
>>> Normal asynchronous test methods:
>>> - Test method goes into async mode, returns, then passes (called
>>> finishTest()).
>>> - Test method goes into async mode, returns, then fails by triggering an
>>> exception in an event handler.
>>> - Test method goes into async mode, returns, then fails by timing out.
>>>
>>> Weird cases:
>>> - Test method triggers an exception synchronously *from an event
>>> handler*.
>>>   - As described above, the exception is thrown away from GWTTestCase's
>>> onUncaughtException().
>>> - Test method completes synchronously, then triggers an exception between
>>> test methods.
>>>   - Uncertain, but I believe it just throws away the exception, as in the
>>> above case.
>>>
>>
>> It would throw it away.  This is kind of the weirdest case, because you've
>> actually already reported a result for a case that you later discover
>> failed, and you're waiting on an XHR to see what to run next.  I suppose you
>> could immediately fail the *next* test once it's ready with a
>> PreviouslyFailedTestException.
>>
>>
>>> - Test method completes [a]synchronously, then triggers an exception
>>> during the next test method.
>>>   - The delayed exception causes the *next* test to report failure, which
>>> seems somewhat wrong.
>>>   - But the stack trace still shows the actual point where the exception
>>> occurred.
>>>
>>> What those last to "weird cases" lead me to believe is that we're not
>>> really defending against anything by throwing away uncaught exceptions, and
>>> that we should be able to allow all uncaught exceptions to 'fail' the
>>> current test (even if it ends up being the wrong one). Are there any other
>>> cases I'm missing here, or some subtle reason we can't do this?
>>>
>>
>> This seems reasonable, I just wanted to enumerate the cases and make sure
>> it makes sense.
>>
>> Other weird cases I can think of (there may be more):
>> - Test method triggers an exception synchronously after setting up an
>> async state
>> - Test method triggers an exception synchronously *from an event
>> handler* after setting up an async state (but before the method returns)
>> - Test method triggers an exception synchronously *from an event handler*,
>> then throws an exception itself synchronously.  (We report a
>> CaughtPlusUncaughtAtTheSameTimeException that contains both?) :)
>>
>>
>>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Ideas for simple but immediately-useful bits of data for SOYC

2008-12-08 Thread Bruce Johnson

The way describes is summarizes my perspective, too.

On Mon, Dec 8, 2008 at 2:15 PM, Toby Reyelts <[EMAIL PROTECTED]> wrote:

> There are a lot of ways that you can tweak JProfiler to make it run faster,
> depending upon the statistics that you're trying to collect. This is
> particularly true for CPU profiling.
>
> In contrast, I think heap profiling is the situation where you're most
> likely to run into problems. This is because we have so many small objects
> in the compiler, and the heap profilers consume a lot of space per object in
> the heap. For example, I believe John was seeing something of a 5x blowup
> using jhat, which is more parsimonious than JProfiler. I'm not sure how we
> can analyze the heap ourselves, in a better way than the existing tools. I
> think we'd be better off patching jhat (for example, to use direct
> ByteBuffers) than trying to re-invent the wheel.
>
> My personal opinion about all of this is that we're better off collecting
> statistics at a high/application-specific level, for dashboard-style use:
>   - how much total memory was used
>   - how much total time was used
>   - how many times was each optimization phase executed, and how much per
> phase
>   - etc...
>
> We need metrics that will help us quickly discern when a problem exists and
> when it was introduced. (For example, "compiler became slower in the last
> committed patch"). It seems like existing Java tools are mostly up to the
> task of teasing out the kinds of information we need to direct our
> improvements. (The querying kinds of facilities that jhat provides are
> particularly neat and useful for heap analysis.)
>
> On Mon, Dec 8, 2008 at 11:18 AM, Katharina Probst <[EMAIL PROTECTED]>wrote:
>
>>
>>> Further, Java profilers are quite effective.  If you just run the
>>> compiler or hosted mode under JProfiler, you get a great overall view
>>> of where the time is going, and further you can drill into the data to
>>> get more specific information.
>>
>>
>> Agreed, JProfiler gives lots of interesting info, but one problem is that
>> it slows everything down so dramatically - I could barely use it for
>> Showcase, and I would love to analyze (much) larger applications, because I
>> think a lot of these memory hogs don't increase linearly ...
>>
>> kathrin
>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r4269 - in releases/1.6/tools/api-checker: config src/com/google/gwt/tools/apichecker

Author: [EMAIL PROTECTED]
Date: Mon Dec  8 13:23:55 2008
New Revision: 4269

Modified:
releases/1.6/tools/api-checker/config/gwt15_16userApi.conf
 
releases/1.6/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiContainer.java
 
releases/1.6/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiPackage.java

Log:
Fixed 2 issues with the api-checker.
(1) Api checker now propagates the errors that TypeOracle encounters.
(2) Only the translatable version of LinkedHashMap_CustomFieldSerializer is  
now
checked for api compatibility.


Patch by: amitmanjhi
Review by: spoon (desk review)



Modified: releases/1.6/tools/api-checker/config/gwt15_16userApi.conf
==
--- releases/1.6/tools/api-checker/config/gwt15_16userApi.conf  (original)
+++ releases/1.6/tools/api-checker/config/gwt15_16userApi.conf  Mon Dec  8  
13:23:55 2008
@@ -1,18 +1,19 @@
  #existing API

+dirRoot_old @OLDROOT@/
  name_old gwt15userApi
  #sourceFiles and excludedFiles are specified as colon-separated list of  
files
-sourceFiles_old  
@OLDROOT@/dev/core/super:@OLDROOT@/user/super:@OLDROOT@/user/src
-excludedFiles_old  
@OLDROOT@/user/src/com/google/gwt/benchmarks:@OLDROOT@/user/src/com/google/gwt/junit:@OLDROOT@/user/src/com/google/gwt/i18n/rebind:@OLDROOT@/user/src/com/google/gwt/i18n/tools:@OLDROOT@/user/src/com/google/gwt/json:@OLDROOT@/user/src/com/google/gwt/user/rebind:@OLDROOT@/user/src/com/google/gwt/user/server:@OLDROOT@/user/src/com/google/gwt/user/tools:@OLDROOT@/user/super/com/google/gwt/benchmarks:@OLDROOT@/user/super/com/google/gwt/junit
+sourceFiles_old dev/core/super:user/src:user/super
+excludedFiles_old  
user/src/com/google/gwt/benchmarks:user/src/com/google/gwt/i18n/rebind:user/src/com/google/gwt/i18n/tools:user/src/com/google/gwt/json:user/src/com/google/gwt/junit:user/src/com/google/gwt/user/client/rpc/core/java/util/LinkedHashMap_CustomFieldSerializer.java:user/src/com/google/gwt/user/rebind:user/src/com/google/gwt/user/server:user/src/com/google/gwt/user/tools:user/super/com/google/gwt/benchmarks:user/super/com/google/gwt/junit

  ##
  #new Api

+dirRoot_new ./
  name_new gwt16userApi
  #sourceFiles and excludedFiles are specified as colon-separated list of  
files
-sourceFiles_new ./dev/core/super:./user/super:./user/src
-#:dev/core/src
-excludedFiles_new 
./user/src/com/google/gwt/benchmarks:./user/src/com/google/gwt/junit:./user/src/com/google/gwt/i18n/rebind:./user/src/com/google/gwt/i18n/tools:./user/src/com/google/gwt/json:./user/src/com/google/gwt/user/rebind:./user/src/com/google/gwt/user/server:./user/src/com/google/gwt/user/tools:./user/super/com/google/gwt/benchmarks:./user/super/com/google/gwt/junit
+sourceFiles_new dev/core/super:user/src:user/super
+excludedFiles_new  
user/src/com/google/gwt/benchmarks:user/src/com/google/gwt/i18n/rebind:user/src/com/google/gwt/i18n/tools:user/src/com/google/gwt/json:user/src/com/google/gwt/junit:user/src/com/google/gwt/user/client/rpc/core/java/util/LinkedHashMap_CustomFieldSerializer.java:user/src/com/google/gwt/user/rebind:user/src/com/google/gwt/user/server:user/src/com/google/gwt/user/tools:user/super/com/google/gwt/benchmarks:user/super/com/google/gwt/junit

  ##
  #excluded packages

Modified:  
releases/1.6/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiContainer.java
==
---  
releases/1.6/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiContainer.java
 
(original)
+++  
releases/1.6/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiContainer.java
 
Mon Dec  8 13:23:55 2008
@@ -24,6 +24,7 @@
  import com.google.gwt.core.ext.typeinfo.NotFoundException;
  import com.google.gwt.core.ext.typeinfo.TypeOracle;
  import com.google.gwt.dev.javac.CompilationUnit;
+import com.google.gwt.dev.javac.CompilationUnitInvalidator;
  import com.google.gwt.dev.javac.JdtCompiler;
  import com.google.gwt.dev.javac.TypeOracleMediator;
  import com.google.gwt.dev.javac.impl.FileCompilationUnit;
@@ -171,11 +172,11 @@
 */
public String getApiAsString() {
  StringBuffer sb = new StringBuffer();
-sb.append("Api: " + name + "\n\n");
+sb.append("Api: " + name + ", size = " + apiPackages.size() + "\n\n");
  List sortedApiPackages = new ArrayList(
  apiPackages.values());
  Collections.sort(sortedApiPackages);
-for (ApiPackage apiPackage : apiPackages.values()) {
+for (ApiPackage apiPackage : sortedApiPackages) {
sb.append(apiPackage.getApiAsString());
  }
  return sb.toString();
@@ -204,7 +205,7 @@
String getName() {
  return name;
}
-
+
boolean isApiClass(JClassType classType) {
  Boolean ret = apiClassCache.get(classType);
  if (ret != null) {
@@ -269,8 +270,8 @@
  if (file.getName().endsWith("java")) {

[gwt-contrib] [google-web-toolkit commit] r4268 - wiki


Author: [EMAIL PROTECTED]
Date: Mon Dec  8 13:08:17 2008
New Revision: 4268

Modified:
wiki/WAR_Design_1_6.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/WAR_Design_1_6.wiki
==
--- wiki/WAR_Design_1_6.wiki(original)
+++ wiki/WAR_Design_1_6.wikiMon Dec  8 13:08:17 2008
@@ -119,9 +119,9 @@

  == RPC Servlets in Hosted Mode ==

-RPC servlets present special problems with this design.  RPC servlets by  
design and convention are mounted relative to the module's base URL.   
However, we are effectively changing the module's base URL for each hosted  
mode module session.  We believe this implies N-many instances of RPC  
servlets must be instantiated simultaneously, because each instance might  
have a different serialization policy file corresponding to a different  
hosted mode session state.  N-many instances implies that this cannot be  
accomplished merely through web.xml configuration, but servlets must be  
dynamically mapped; perhaps through a servlet filter.
+RPC servlets (`RemoteServiceServlet`) present special problems with this  
design.  RPC servlets by design and convention are mounted relative to the  
module's base URL.  However, we are effectively changing the module's base  
URL for each hosted mode module session.  We believe this implies N-many  
instances of RPC servlets must be instantiated simultaneously, because each  
instance might have a different serialization policy file corresponding to  
a different hosted mode session state.  N-many instances implies that this  
cannot be accomplished merely through web.xml configuration, but servlets  
must be dynamically mapped; perhaps through a servlet filter.

-Alternatively: perhaps we could do write a pattern-match rule in the  
web.xml combined with some special magic in RemoteServiceServlet to avoid  
having to install a filter, and allow a single RPC servlet to service  
multiple module sessions at the same time.
+Alternatively: perhaps we could do write a pattern-match rule in the  
web.xml combined with some special magic in `RemoteServiceServlet` to avoid  
having to install a filter, and allow a single RPC servlet to service  
multiple module sessions at the same time.

  == Linker Stack Changes ==

@@ -152,4 +152,4 @@

  == Open Tasks ==
# Make sure app creator and samples follow this structure.
-  # Deprecate somehow GWTCompiler and GWTShell
+  # Deprecate somehow GWTCompiler and GWTShell
\ No newline at end of file

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r4267 - wiki


Author: [EMAIL PROTECTED]
Date: Mon Dec  8 13:06:21 2008
New Revision: 4267

Modified:
wiki/WAR_Design_1_6.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/WAR_Design_1_6.wiki
==
--- wiki/WAR_Design_1_6.wiki(original)
+++ wiki/WAR_Design_1_6.wikiMon Dec  8 13:06:21 2008
@@ -117,6 +117,12 @@
  # A web browser then loads the host HTML page, which loads the  
compiled selection script.
  # The compiled selection script detects that it is not running in the  
hosted browser, and therefore loads web mode normally.

+== RPC Servlets in Hosted Mode ==
+
+RPC servlets present special problems with this design.  RPC servlets by  
design and convention are mounted relative to the module's base URL.   
However, we are effectively changing the module's base URL for each hosted  
mode module session.  We believe this implies N-many instances of RPC  
servlets must be instantiated simultaneously, because each instance might  
have a different serialization policy file corresponding to a different  
hosted mode session state.  N-many instances implies that this cannot be  
accomplished merely through web.xml configuration, but servlets must be  
dynamically mapped; perhaps through a servlet filter.
+
+Alternatively: perhaps we could do write a pattern-match rule in the  
web.xml combined with some special magic in RemoteServiceServlet to avoid  
having to install a filter, and allow a single RPC servlet to service  
multiple module sessions at the same time.
+
  == Linker Stack Changes ==

  The linker stack must now support hosted mode fully and correctly.  When a  
hosted browser begins to load a GWT application, a module-session is  
created, and an initial link is performed into the module-session  
directory.  This module-session is retained throughout the life of that  
hosted browser remaining on the page.  The initial link takes only public  
resources as inputs, but should produce a selection script based on zero  
`CompilationResult`s.  In the future, we may choose to synthesize a  
`HostedModeCompilationResult` to represent the actual deferred binding  
properties of the browser associated with the module-session.
@@ -132,21 +138,18 @@
  == Open Issues ==
# How do we isolate the web app classloader to ensure same behavior in  
deployment?
# What happens to the GWT `` tag for `HostedMode`?
-# Supported programmatically?  (Can lead to deployment failure.)
-# Deprecated?
-# Ignored?
-# Validate that web.xml matches and suggest the text to add?  <---  
this one
+# Validate that web.xml matches and suggest the text to add?
+# Host new instances ourselves via a servlet Filter for active module  
sessions
# `war/qualified.ModuleName/scripts/` is likely to change in 2.0 with  
runAsync
# How will JUnit work?
  # Probably can use legacy stuff for now
# Will this design work with Maven?
# Will the module-session idea negatively impact history / backing into  
an application?
-  # How the heck do we make RPC servlets, which are based off module base  
URL, work with the rebasing for module sessions?

  == Deprecation Policy==

  The 1.6 release should deprecate the legacy entry points so that they may  
be removed entirely in the subsequent release.  Without a forcing function,  
there is no incentive for users to migrate to newer entry-points, leaving  
them as the proverbial albatross.

  == Open Tasks ==
-  # Make sure app creator and sample follow this structure.
-  # Remove the GWT module deploy-to attribute introduced in the 1.6 branch.
\ No newline at end of file
+  # Make sure app creator and samples follow this structure.
+  # Deprecate somehow GWTCompiler and GWTShell

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

Re: RR: CssResourceGenerator patch for GWT compiler bug (was Re: [gwt-contrib] Re: Very Strange Compiler Bug: Works in JDK1.5, fails in 1.6)

2008-12-08 Thread BobV


On Tue, Dec 9, 2008 at 7:41 AM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
> Should I just commit this without review, or does anyone want to review it?

I'm just getting into work in Sydney, I'll take a look at it.

-- 
Bob Vawter
Google Web Toolkit Team

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

Re: RR: CssResourceGenerator patch for GWT compiler bug (was Re: [gwt-contrib] Re: Very Strange Compiler Bug: Works in JDK1.5, fails in 1.6)

It's for the incubator code. I didn't patch GWT yet because I'm kinda
strapped for time, and it seemed like it would take a lot more time
for me to patch the compiler, rather than patch the FooBundle stuff
which is triggering it. I could submit a patch for the compiler later
if you'd like, I just needed this fix quick, as some my users said
they had deadlines approaching.

-Ray

On Mon, Dec 8, 2008 at 12:55 PM, Scott Blum <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 8, 2008 at 3:41 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
>>
>> Should I just commit this without review, or does anyone want to review
>> it?
>
> I asked Lex if he could take a look.  But I thought this was for GWT itself
> rather than incubator?
>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Fwd: review: shouldn't soyc-vis handle compression?

2008-12-08 Thread Freeland Abbott

Since we generate compressed output, wouldn't it be nice to handle it as
input?  (We don't seem to need any of the reports but report0.xml[.gz], so
it's just the one stream insertion.)

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---



soyc-compression.r4264.patch
Description: Binary data

[gwt-contrib] getAbsoluteLeft/Top() returns incorrect value in IE when zoomed in

2008-12-08 Thread jlabanca


Reviewers: ecc,

Description:
Description:

Issue 3172 reports that sub menus do not line up with the ManuBar in IE
when zoomed in:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3172

This is actually a much deeper issue where  getAbsoluteLeft/Top() return
incorrect values in IE while zoomed in.  There are two types of zoom in
IE: text zoom and page zoom.  Text zoom enlarges the text size, and
subsequently shifts the content on the page to a greater
absoluteLeft/Top, and IE works fine in this case.  Page zoom (the
default) enlarges the content on the page AND maps top and left indexes
to new coordinates.  So, when a user zooms in to 200%, the absoluteLeft
position of an element remains the same, but it appears twice as far to
the left.  Currently, GWT returns an absoluteLeft that reflects the
screen position, not the logical position.

Note that this bug also affects SuggestBox.


Fix:

We now determine the zoom multiple in IE and divide by before returning
the absoluteLeft coordinate.

The DOCTYPE actually makes a difference.  The following DOCTYPE (default
in AppHtml.htmlsrc) works fine:


However, adding the loose.dtd makes body.parentElement return the same
size as body.element.  The following DOCTYPE was used in the
code-museum, so I changed it back to the DOCTYPE from AppHtml.htmlsrc.



Testing:

Unfortunately, this isn't unit testable.  I created a code museum test
to check for this.



Please review this at http://gwt-code-reviews.appspot.com/807

Affected files:

reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/DefaultMuseum.java

reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/Issue3172.java
   reference/code-museum/src/com/google/gwt/museum/public/DefaultMuseum.html
   reference/code-museum/src/com/google/gwt/museum/public/Museum.html
   reference/code-museum/src/com/google/gwt/museum/public/SingleIssue.html
   user/src/com/google/gwt/dom/client/DOMImplIE6.java



--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r4266 - trunk/user/src/com/google/gwt/user/client/ui


Author: [EMAIL PROTECTED]
Date: Mon Dec  8 12:56:35 2008
New Revision: 4266

Modified:
trunk/user/src/com/google/gwt/user/client/ui/ListenerWrapper.java

Log:
typo correction; the ListenerWrapper for Trees should fire a StateChange  
rather than Selection for node open.  (Node close was correct.)

Review by: ecc

Modified: trunk/user/src/com/google/gwt/user/client/ui/ListenerWrapper.java
==
--- trunk/user/src/com/google/gwt/user/client/ui/ListenerWrapper.java
(original)
+++ trunk/user/src/com/google/gwt/user/client/ui/ListenerWrapper.java   Mon  
Dec  8 12:56:35 2008
@@ -460,7 +460,7 @@
  }

  public void onOpen(OpenEvent event) {
-  listener.onTreeItemSelected(event.getTarget());
+  listener.onTreeItemStateChanged(event.getTarget());
  }

  public void onSelection(SelectionEvent event) {

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

Re: RR: CssResourceGenerator patch for GWT compiler bug (was Re: [gwt-contrib] Re: Very Strange Compiler Bug: Works in JDK1.5, fails in 1.6)

2008-12-08 Thread Scott Blum

On Mon, Dec 8, 2008 at 3:41 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:

> Should I just commit this without review, or does anyone want to review it?
>

I asked Lex if he could take a look.  But I thought this was for GWT itself
rather than incubator?

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: code review: issues_3166_3167_gwt16_r4353.patch

2008-12-08 Thread jgw

For reasons not clear to me, I can't seem to add an updated patch set.
I'll send it to the gwt-contrib thread and hope you can do it :)

http://codereview.appspot.com/8894/diff/1/9
File user/src/com/google/gwt/user/client/Event.java (right):

http://codereview.appspot.com/8894/diff/1/9#newcode287
Line 287: * @param detail the event's detail property
On 2008/12/05 00:13:15, rjrjr wrote:
> Any example of valid values of detail?

Detail is one of those weird fields that means different things for
different events. It's defined as part of the DOM spec (in other words,
if you don't know what it is, you probably won't care).

http://codereview.appspot.com/8894/diff/1/7
File user/src/com/google/gwt/user/client/impl/DOMImplIE6.java (right):

http://codereview.appspot.com/8894/diff/1/7#newcode230
Line 230: evt.relatedTarget = relatedTarget;
On 2008/12/05 00:13:15, rjrjr wrote:
> (Pretending I know what I'm talking about.) relatedTarget is a real
field in
> correct browsers, right? Is it a bit confusing to use it here in IE,
where it
> normally doesn't exist? Could we call this gwtTarget instead?

Well, we're actually synthesizing a value that *is* identical to
relatedTarget on other browsers (and that IE doesn't implement), so it
doesn't seem unreasonable to simply synthesize it here.

In the long run, it would make more sense to shift the public APIs to
use 'relatedTarget', but that's probably a task for another day.

http://codereview.appspot.com/8894/diff/1/10
File user/src/com/google/gwt/user/client/ui/CustomButton.java (right):

http://codereview.appspot.com/8894/diff/1/10#newcode746
Line 746: // TODO(jgw): fill in these parameters somehow.
On 2008/12/05 00:13:15, rjrjr wrote:
> If this is actually possible, could you file an issue on it and point
to the
> issue here? Also, do we usually put our initials in our TODOs? (I hope
so, but
> thought I got scolded for doing so.)

Whoops, I didn't mean to leave this TODO in there. I've changed this
comment to explain why those values are unavailable (this shouldn't
matter in practice, as click events often don't have useful mouse
coordinates).

http://codereview.appspot.com/8894/diff/1/4
File user/test/com/google/gwt/user/client/ui/CustomButtonTest.java
(right):

http://codereview.appspot.com/8894/diff/1/4#newcode178
Line 178: assertEquals("Expecting one click event", "click",
events.get(0));
On 2008/12/05 00:13:15, rjrjr wrote:
> I guess you're doing all three (over, down, up) b/c triggerClickEvent
can't be
> relied upon to do so? You might document that.

Actually, this is intended to test that this series of events should
*cause* CustomButton to fire a synthetic click event. I've added
documentation to that effect.

http://codereview.appspot.com/8894/diff/1/3
File user/test/com/google/gwt/user/client/ui/TriggerEventTest.java
(right):

http://codereview.appspot.com/8894/diff/1/3#newcode30
Line 30: public class TriggerEventTest extends GWTTestCase {
On 2008/12/05 00:13:15, rjrjr wrote:
> A thing of beauty. I have to take your word on which events bubble and
which
> don't. But then again I suppose I have the word of the tests
themselves. :-)
>
> Should you be testing capture as well? Or does GWT stay clear of that?

We don't do event capture, because there's really no reliable way to
synthesize it on IE (it's sort of possible, but there are all kinds of
edge cases that can't be made to work sensibly).

http://codereview.appspot.com/8894/diff/1/3#newcode57
Line 57: assertTrue("Expecting child to receive the event before
parent",
On 2008/12/05 00:13:15, rjrjr wrote:
> "Expecting parent to receive the event after the child", to avoid a
dup message

Done.

http://codereview.appspot.com/8894/diff/1/3#newcode157
Line 157: init();
On 2008/12/05 00:13:15, rjrjr wrote:
> just call this from gwtSetup rather than in each method

Whoops, thanks. That's a lot simpler, isn't it?

http://codereview.appspot.com/8894/diff/1/3#newcode166
Line 166: Event.triggerClickEvent(child, 0, 0, 0, 0, 0, false, false,
false, false);
On 2008/12/05 00:13:15, rjrjr wrote:
> Seems like you should test all three core event types here.

Good point. Just refactored the test to do click, keypress, and focus.

http://codereview.appspot.com/8894/diff/1/3#newcode177
Line 177: public void onBrowserEvent(Event event) {
On 2008/12/05 00:13:15, rjrjr wrote:
> Seems like you could provide default implementations of onBrowserEvent
that do
> assertEquals(eventType, event.getType()), and get rid of a good chunk
of these
> anon classes. Perhaps even put it in a shared superclass.

Fair enough. I've gone through and factored out a few helper classes to
simplify these cases. There are still a few anonymous inners, but it's
not as ugly as before.

http://codereview.appspot.com/8894/diff/1/3#newcode233
Line 233: assertTrue("Expected parent to receive event",
listener.parentReceived);
On 2008/12/05 00:13:15, rjrjr wrote:
> shouldn't you be checking the values of the various fields as well?
You're
> proving SCREEN_X et a

Re: RR: CssResourceGenerator patch for GWT compiler bug (was Re: [gwt-contrib] Re: Very Strange Compiler Bug: Works in JDK1.5, fails in 1.6)


Should I just commit this without review, or does anyone want to review it?

-Ray

On Sat, Dec 6, 2008 at 9:32 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
> Ok, this has become a pressing issue for me, a number of Chronoscope
> users are either unwilling or unable to use -Xss to work around the
> stack overflow bug. The attached patch temporarily fixes the bug until
> a more permanent fix can be done in the compiler.
>
> To review, the CssResourceGenerator deals with template substitutions
> by splitting the template up into parts and concatenating the static
> parts with the substituted variables. When I attempted to convert GWT
> Theme CSS stylesheets to use ImmutableResourceBundle, I triggered the
> bug. The problem is, if you have one uber-long expression like
>
> return a + b + c + d +  (dozens to hundreds more);
>
> You create an unbalanced AST tree that is roughly as deep as the
> number of leaf nodes in the expression. The compiler chokes on this
> because the visitors use implicit stack recursion, and eventually the
> JVM thread's stack is exhausted leading to a stack overflow error.
>
> This patch attempts to create a more balanced tree by adding ()
> groupings every once in awhile. I haven't decided on the optimal group
> size, right now it's 20, but you end up with something like this:
>
> return (a1 + a2 + ... a20) + (a21 + a22 + ... + a30) + ...
>
> instead of this
>
> return a1 + a2 + ... a99
>
> There are other solutions, like generating StringBuilder calls, using
> JSNI and [many, element, array].join(), using locaVar +=,  or as Scott
> suggested, attacking the problem in JDT->JavaAST stage. However, this
> patch was the easier, and doesn't change the semantics of the output
> very much, except for a few unneeded parenthesis.
>
> I tested the page and it appears to work, although I haven't vetted
> the code fully.
>
> -Ray
>
>
> On Wed, Oct 22, 2008 at 2:01 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
>> Sounds like it would. I can only think of two areas where it is easy
>> for deep nesting to cause stack issues: Nested binary expressions and
>> nested blocks. Realistically, people don't tend to create giant
>> methods which nest loops/if statements/etc very deeply, but generators
>> might. This error seems very specific to the uber-concat that
>> CssResource does in the bundle.
>>
>> -Ray
>>
>>
>> On Wed, Oct 22, 2008 at 2:04 PM, Scott Blum <[EMAIL PROTECTED]> wrote:
>>> This is interesting, because Eclipse actually has a class to mitigate this
>>> problem, which we don't provide direct support for: CombinedBinaryExpression
>>> I wonder if we implemented JExpression
>>> processExpression(CombinedBinaryExpression x); to be non-recursive, if it
>>> would avoid this error?
>>> >>>
>>>
>>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] review: patch for ListenerWrapper.Tree's handle of open

2008-12-08 Thread Freeland Abbott

I think this was just a typo...

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---



treeopen.r4264.patch
Description: Binary data

[gwt-contrib] Re: Ideas for simple but immediately-useful bits of data for SOYC

2008-12-08 Thread Toby Reyelts

There are a lot of ways that you can tweak JProfiler to make it run faster,
depending upon the statistics that you're trying to collect. This is
particularly true for CPU profiling.

In contrast, I think heap profiling is the situation where you're most
likely to run into problems. This is because we have so many small objects
in the compiler, and the heap profilers consume a lot of space per object in
the heap. For example, I believe John was seeing something of a 5x blowup
using jhat, which is more parsimonious than JProfiler. I'm not sure how we
can analyze the heap ourselves, in a better way than the existing tools. I
think we'd be better off patching jhat (for example, to use direct
ByteBuffers) than trying to re-invent the wheel.

My personal opinion about all of this is that we're better off collecting
statistics at a high/application-specific level, for dashboard-style use:
  - how much total memory was used
  - how much total time was used
  - how many times was each optimization phase executed, and how much per
phase
  - etc...

We need metrics that will help us quickly discern when a problem exists and
when it was introduced. (For example, "compiler became slower in the last
committed patch"). It seems like existing Java tools are mostly up to the
task of teasing out the kinds of information we need to direct our
improvements. (The querying kinds of facilities that jhat provides are
particularly neat and useful for heap analysis.)

On Mon, Dec 8, 2008 at 11:18 AM, Katharina Probst <[EMAIL PROTECTED]>wrote:

>
>> Further, Java profilers are quite effective.  If you just run the
>> compiler or hosted mode under JProfiler, you get a great overall view
>> of where the time is going, and further you can drill into the data to
>> get more specific information.
>
>
> Agreed, JProfiler gives lots of interesting info, but one problem is that
> it slows everything down so dramatically - I could barely use it for
> Showcase, and I would love to analyze (much) larger applications, because I
> think a lot of these memory hogs don't increase linearly ...
>
> kathrin
>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r4265 - in trunk/dev/core/src/com/google/gwt/core: ext/linker/impl linker


Author: [EMAIL PROTECTED]
Date: Mon Dec  8 08:49:24 2008
New Revision: 4265

Modified:
 
trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
trunk/dev/core/src/com/google/gwt/core/linker/IFrameLinker.java

Log:
Modifies the IFrame linker so that any deferred-loaded JavaScript
files needed by runAsync are placed into subdirectories of the
main output directory.

Review by: bobv



Modified:  
trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
==
---  
trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java

(original)
+++  
trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java

Mon Dec  8 08:49:24 2008
@@ -28,6 +28,7 @@
  import com.google.gwt.dev.util.Util;
  import com.google.gwt.util.tools.Utility;

+import java.io.File;
  import java.io.IOException;
  import java.net.MalformedURLException;
  import java.net.URL;
@@ -55,6 +56,11 @@
protected static final String FRAGMENT_EXTENSION = ".cache.js";

/**
+   * A subdirectory to hold all the generated fragments.
+   */
+  protected static final String FRAGMENT_SUBDIR = "deferredjs";
+
+  /**
 * Determines whether or not the URL is relative.
 *
 * @param src the test url
@@ -111,7 +117,8 @@
throws UnableToCompleteException {
  String[] js = result.getJavaScript();
  byte[][] bytes = new byte[js.length][];
-bytes[0] = generatePrimaryFragment(logger, context, js[0],  
result.getStrongName());
+bytes[0] = generatePrimaryFragment(logger, context, js[0],
+result.getStrongName());
  for (int i = 1; i < js.length; i++) {
bytes[i] = Util.getBytes(js[i]);
  }
@@ -120,8 +127,8 @@
  toReturn.add(emitBytes(logger, bytes[0], result.getStrongName()
  + getCompilationExtension(logger, context)));
  for (int i = 1; i < js.length; i++) {
-  toReturn.add(emitBytes(logger, bytes[i], result.getStrongName()  
+ "-" + i
-  + FRAGMENT_EXTENSION));
+  toReturn.add(emitBytes(logger, bytes[i], FRAGMENT_SUBDIR +  
File.separator
+  + result.getStrongName() + File.separator + i +  
FRAGMENT_EXTENSION));
  }

  compilationStrongNames.put(result, result.getStrongName());
@@ -336,7 +343,8 @@
}

protected abstract String getModulePrefix(TreeLogger logger,
-  LinkerContext context, String strongName) throws  
UnableToCompleteException;
+  LinkerContext context, String strongName)
+  throws UnableToCompleteException;

protected abstract String getModuleSuffix(TreeLogger logger,
LinkerContext context) throws UnableToCompleteException;
@@ -345,7 +353,8 @@
LinkerContext context) throws UnableToCompleteException;

private byte[] generatePrimaryFragment(TreeLogger logger,
-  LinkerContext context, String js, String strongName) throws  
UnableToCompleteException {
+  LinkerContext context, String js, String strongName)
+  throws UnableToCompleteException {
  StringBuffer b = new StringBuffer();
  b.append(getModulePrefix(logger, context, strongName));
  b.append(js);

Modified: trunk/dev/core/src/com/google/gwt/core/linker/IFrameLinker.java
==
--- trunk/dev/core/src/com/google/gwt/core/linker/IFrameLinker.java  
(original)
+++ trunk/dev/core/src/com/google/gwt/core/linker/IFrameLinker.java Mon  
Dec  8 08:49:24 2008
@@ -87,7 +87,7 @@
  out.indentIn();
  out.print("  var script = document.createElement('script');");
  out.newlineOpt();
-out.print("  script.src = '" + strongName + "-' + frag + '" +  
FRAGMENT_EXTENSION + "';");
+out.print("  script.src = '" + FRAGMENT_SUBDIR + "/" + strongName  
+ "/' + frag + '" + FRAGMENT_EXTENSION + "';");
  out.print("   
document.getElementsByTagName('head').item(0).appendChild(script);");
  out.indentOut();
  out.newlineOpt();

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Add NativePreviewEvent to replace current EventPreview system

2008-12-08 Thread jlabanca

Reviewers: ecc,

Description:
The new NativePreviewEvent and NativePreviewHandler replaces the old
EventPreview system. Instead of firing only one EventPreview at the top
of the stack, we now fire all NativePreventHandlers. The PopupPanel,
DialogBox, MenuBar, and code museum code has been updated to use the new
NativePreviewHandler.

NativePreviewEvent has three booleans: isNativeEventCanceled,
isNativeEventConsumed, and isNativeEventBlocked. Here is a description:

isNativeEventCanceled - the most obvious of them, canceling a native
event prevents it from firing to the widgets. This is a replacement for
the return value of EventPreview.onPreviewEvent.

isNativeEventConsumed - a NativePreviewHandler can consume an event so
that other handlers cannot cancel it. This is necessary because
handlers that are lower on the stack may want to cancel an event, but
the handler at the top of the stack has priority. For example, the
popup at the top of the stack may want to use an event, but another
popup might want to cancel the event because its modal. The popup at
the top of the stack gets to choose.

isNativeEventBlocked - blocking a native event lets other handlers know
that the native event will not reach them. For example, a modal
PopupPanel will block the native event so that PopupPanels below it
cannot act on the event. However, we need to keep working through the
NativePreviewHandler stack so that all handlers can preview the event,
even if it is blocked. The handlers should respect the fact that the
native event was blocked, but they still get a change to preview what
they missed. This covers the use case where you want to know that an
event occured, but don't care if it was canceled or not.

I added extensive unit tests and some additional visual tests.

Please review this at http://gwt-code-reviews.appspot.com/805

Affected files:

reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/Issue1932.java

reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/VisualsForDialogBox.java
user/src/com/google/gwt/event/dom/client/DomEvent.java
user/src/com/google/gwt/event/logical/shared/HasNativeEvent.java
user/src/com/google/gwt/event/shared/GwtEvent.java
user/src/com/google/gwt/event/shared/HandlerManager.java
user/src/com/google/gwt/user/client/DOM.java
user/src/com/google/gwt/user/client/Event.java
user/src/com/google/gwt/user/client/EventPreview.java
user/src/com/google/gwt/user/client/ui/DialogBox.java
user/src/com/google/gwt/user/client/ui/MenuBar.java
user/src/com/google/gwt/user/client/ui/PopupPanel.java
user/test/com/google/gwt/user/UISuite.java
user/test/com/google/gwt/user/client/EventTest.java

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Safari/Chrome FocusPanel inside ScrollPanel

2008-12-08 Thread Emily Crutcher

Thanks! I've reopened 1313.

On Mon, Dec 8, 2008 at 11:43 AM, Paul Robinson <[EMAIL PROTECTED]> wrote:

>
> I have found what I think is a bug in the interaction between FocusPanel
> and ScrollPanel on Safari and Chrome. What I'm seeing is that when you
> create a FocusPanel and put it inside a ScrollPanel, clicking inside the
> focus panel cause the scroll panel to scroll to the top.
>
> I think that what's happening here is that the browser is scrolling to
> bring into view the hidden input element that FocusImplSafari creates.
>
> I'm seeing this in GWT 1.5.2. I found a similar issue here (although
> this is marked fixed):
> http://code.google.com/p/google-web-toolkit/issues/detail?id=1313
>
> Here's a code snippet that shows the necessary parts to make the bug
> happenjust run this in web mode on safari or chrome, scroll the
> window down a bit, then click on one of the labels to see the window
> scroll back to the top.
>
> public class FooPanel extends DockPanel {
>
>public FooPanel() {
>VerticalPanel ap = new VerticalPanel();
>for (int i = 0; i < 50; i++) {
>ap.add(new Label(Integer.toString(i)));
>}
>
>MyFocusPanel focus = new MyFocusPanel();
>focus.setWidget(ap);
>
>super.add(new ScrollPanel(focus), DockPanel.CENTER);
>}
> }
>
> // you can use the normal FocusPanel to show the bugthis just shows
> it's the FocusImpl that's the problem
> class MyFocusPanel extends SimplePanel {
>
>  static final FocusImpl impl = FocusImpl.getFocusImplForPanel();
>
>  public MyFocusPanel() {
>super(impl.createFocusable());
>  }
> }
>
> Paul
>
> >
>


-- 
"There are only 10 types of people in the world: Those who understand
binary, and those who don't"

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR: put runAsync deferred JS files into a subdirectory


On Fri, Dec 5, 2008 at 12:30 PM, BobV <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 5, 2008 at 12:02 PM, Lex Spoon <[EMAIL PROTECTED]> wrote:
>> Here is an updated version that puts the deferred JS files for each
>> permutation into a separate subdirectory of deferredjs.  That is,
>> where there used to be a '-', there is now a '/'.
>
> LGTM.

Thanks, Bob.  I have put this version in at revision 4265.

We can further clean up the arrangement if it seems worth it, but this
much already significantly improves the directory layout.

-Lex

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Safari/Chrome FocusPanel inside ScrollPanel

2008-12-08 Thread Paul Robinson


I have found what I think is a bug in the interaction between FocusPanel
and ScrollPanel on Safari and Chrome. What I'm seeing is that when you
create a FocusPanel and put it inside a ScrollPanel, clicking inside the
focus panel cause the scroll panel to scroll to the top.

I think that what's happening here is that the browser is scrolling to
bring into view the hidden input element that FocusImplSafari creates.

I'm seeing this in GWT 1.5.2. I found a similar issue here (although
this is marked fixed):
http://code.google.com/p/google-web-toolkit/issues/detail?id=1313

Here's a code snippet that shows the necessary parts to make the bug
happenjust run this in web mode on safari or chrome, scroll the
window down a bit, then click on one of the labels to see the window
scroll back to the top.

public class FooPanel extends DockPanel {

public FooPanel() {
VerticalPanel ap = new VerticalPanel();
for (int i = 0; i < 50; i++) {
ap.add(new Label(Integer.toString(i)));
}
   
MyFocusPanel focus = new MyFocusPanel();
focus.setWidget(ap);

super.add(new ScrollPanel(focus), DockPanel.CENTER);
}
}

// you can use the normal FocusPanel to show the bugthis just shows
it's the FocusImpl that's the problem
class MyFocusPanel extends SimplePanel {

  static final FocusImpl impl = FocusImpl.getFocusImplForPanel();

  public MyFocusPanel() {
super(impl.createFocusable());
  }
}

Paul

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] review request: shouldn't soyc-vis be in the distro?

2008-12-08 Thread Freeland Abbott

Ant script tweaks to package soyc-vis into the distribution.

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---



soyc-included.r4264.patch
Description: Binary data

[gwt-contrib] Re: Ideas for simple but immediately-useful bits of data for SOYC

2008-12-08 Thread Katharina Probst

>
>
> Further, Java profilers are quite effective.  If you just run the
> compiler or hosted mode under JProfiler, you get a great overall view
> of where the time is going, and further you can drill into the data to
> get more specific information.


Agreed, JProfiler gives lots of interesting info, but one problem is that it
slows everything down so dramatically - I could barely use it for Showcase,
and I would love to analyze (much) larger applications, because I think a
lot of these memory hogs don't increase linearly ...

kathrin

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR: put runAsync deferred JS files into a subdirectory

On Fri, Dec 5, 2008 at 11:02 PM, Bruce Johnson <[EMAIL PROTECTED]> wrote:
> Possible dumb point, but do you prefix-pad the fragments with '0'
> where necessary? For some reason it's so aesthetically yucky to see
> things mis-sorted on the command-line like this:
>
>   1.nocache.js
>   10.nocache.js
>   2.nocache.js
>
> instead of nicer, like this:
>
>   01.nocache.js
>   02.nocache.js
>   ...
>   10.nocache.js

That's a cool idea.  However, these filenames have to be computed by
the web browser, not just the compiler.  Thus, there would be a little
extra code that needs to be downloaded.  For that reason, I'd like to
commit the simpler version for now, even though the listing does not
look as nice on all platforms.

They do list in the desired order in a Mac Finder, for what that's worth.

Lex

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Ideas for simple but immediately-useful bits of data for SOYC


This kind of data is very valuable for sure.

I not sure how much it makes sense to record on a regular basis,
though.  It's already pretty easy to modify the compiler to get these
statistics whenever a developer needs them, and I've done so for
several of them in the past.  It only takes a few minutes to implement
them, so long as global variables and println's are okay.  If we
polish it up and make a clean version, it could take significantly
more time than is saved for each person to hack them up as needed.

Further, Java profilers are quite effective.  If you just run the
compiler or hosted mode under JProfiler, you get a great overall view
of where the time is going, and further you can drill into the data to
get more specific information.


Generalities aside, from the profiling I've done before, Pruning,
TypeTightening, and Inliner take the bulk of the time.  These are also
optimizers that run themselves in a loop, which would be consistent
with the theory Ray suggests that visitor overhead is significant.

That already points to one way to speed things up.  We could
restructure these things not to need to iterate so many times.  The
Simplifier class I put in a few months ago should be able to make
DeadCodeElimination run faster, if we used it more, because it can do
multiple simplifications in one pass instead of needing to iterate.
If we beefed that up enough, then DeadCodeElimination wouldn't need an
inner loop at all, because the first pass would pick up all
simplifications possible.

There are analogous changes we could make to the type tightener and
the pruner to prevent them from toggling back and forth.  In the
limit, we could probably make a single-pass analyzer that supports all
the other AST changes except for inlining.  Then the outer
optimization loop would be: analyze, clean up, inline.  Each of these
would make exactly one walk across the tree, although the analyzer
would still need to have an inner loop to propagate information.


Really, though, if we want really fast compiles, we should probably
skip the optimizer.  Imagine how fast we could get working JavaScript
on disk if we just read the Java, type checked it, and then dumped out
the corresponding JavaScript.  This could be especially slick if we
combined it with hosted-mode infrastructure to manage recompiling the
Java.

For hosted mode, I haven't looked and don't have much of an idea
what's going on.  I do know that we rerun generators more frequently
than really necessary, which should then trigger a lot of subsequent
recompiles.  Other than that, I don't know.  Running it under a
profiler should be interesting.

Overall, I see incremental options if we want to spend time in them
(make passes not iterate so much, figure out when a generator rerun
could be skipped), and I see some alternate compilation modes if we
want to get more dramatic speedups in limited time (no-optimization
web mode).

Lex

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit] jieryn commented on revision r3853.