[gwt-contrib] Re: split up long var lines

2009-05-21 Thread Lex Spoon

On Wed, May 20, 2009 at 3:13 PM, Ray Cromwell cromwell...@gmail.com wrote:
 As a practical example, ClientBundle can already generate deep
 expressions for Css resource injection that exhaust the stack space of
 the JVM when compiling. You end up with something like:

 var cssText = a + b + c + . (hundreds)

 which produces a very deeply nested binary expression tree.

Good example.  That would be a problem if there can be in the
neighborhood of 10,000 of them.  Hundreds wouldn't be a problem.

In general, it would take a few days' work to write a general
un-deepener.  We can do that if it starts to look like an important
enough problem.  In this case, it looks much easier to modify the
generator.

Lex

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



[gwt-contrib] [google-web-toolkit commit] r5451 - Edited wiki page through web user interface.

2009-05-21 Thread codesite-noreply

Author: b...@google.com
Date: Thu May 21 06:43:38 2009
New Revision: 5451

Modified:
wiki/CssResource.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/CssResource.wiki
==
--- wiki/CssResource.wiki   (original)
+++ wiki/CssResource.wiki   Thu May 21 06:43:38 2009
@@ -3,7 +3,7 @@

  wiki:toc max_depth=2 /

-See also the CssResourceCookbook
+See also the CssResourceCookbook and StyleInjector.

  =Goals=

@@ -236,11 +236,10 @@
  .hookClass{} /* Empty and stripped, but left for future expansion */
  }}}
* The function just returns the CSS class name, but verifies that the  
CSS class exists in the stylesheet.
-* _TODO_: Add an @external annotation to allow a binding to a  
site-wide css file
-  * No typos.
+  * Accessing class names through the interface ensures that there can be  
no typos in code that consumes the CssResource.
* For obfuscation, we'll use a Adler32 checksum of the source css file  
expressed in base36 as a prefix (7 chars). The developer can override this  
with the `CssResource.obfuscationPrefix` deferred-binding property.
  * `set-configuration-property name=CssResource.obfuscationPrefix  
value=empty /` can be used for minimal-length selector names, but this  
is only recommended when the GWT module has total control over the page.
-  * The `...@external` at-rule can be used to selectively disable obfuscation  
for named selectors; see below for additional detail.
+  * The `...@external` at-rule can be used to selectively disable obfuscation  
for named selectors; see [#External_and_legacy_scopes additional detail].

  = Unplanned use cases =

@@ -576,4 +575,4 @@
* Other meta-classes
  * @Opacity
  * @RoundedCorners
-  * Can we generalize the meta-classes into an extensible Java  
provider API?
+  * Can we generalize the meta-classes into an extensible Java  
provider API?
\ No newline at end of file

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



[gwt-contrib] [google-web-toolkit commit] r5452 - Copy StyleInjector wiki page from incubator and update with current information.

2009-05-21 Thread codesite-noreply

Author: b...@google.com
Date: Thu May 21 06:53:08 2009
New Revision: 5452

Added:
wiki/StyleInjector.wiki

Log:
Copy StyleInjector wiki page from incubator and update with current  
information.


Added: wiki/StyleInjector.wiki
==
--- (empty file)
+++ wiki/StyleInjector.wiki Thu May 21 06:53:08 2009
@@ -0,0 +1,51 @@
+#summary A utility class for injecting CSS styleshees
+
+= Goal =
+
+  * Provide a cross-browser abstraction for injecting additional CSS at  
runtime.
+
+= Details =
+
+StyleInjector is part of the `com.google.gwt.dom.user` package.
+
+Define your ClientBundle and CssResource:
+{{{
+public interface Resources extends ClientBundle {
+  public static final Resources INSTANCE =
+  GWT.create(Resources.class);
+
+  @ImageOptions(repeatStyle = RepeatStyle.Horizontal)
+  @Source(myBackground.png)
+  public ImageResource backgroundFunction();
+
+  @Source(myCss.css)
+  public CssResource css();
+}
+}}}
+
+The CSS contents (see CssResource for more information):
+{{{
+...@sprite .some .selector {
+  gwt-image: 'backgroundFunction';
+}
+}}}
+
+In your `onModuleLoad`:
+{{{
+StyleInjector.injectStylesheet(Resources.INSTANCE.css().getText());
+}}}
+
+
+You now have your stylesheet applied to the document while taking  
advantage of strongly-named or inlined resource URLs.  Because the standard  
I18N-style of resource naming is applied to the `ImageResource` instance,  
it is possible to provide localized CSS background images without the need  
for multiple, per-locale stylesheets.  It is now possible to have  
`myBackground_fr.png` and `myBackground_en.png` substituted based on the  
`locale` deferred binding property.
+
+It is possible to update the contents of a previously-injected stylesheet  
using the `setContents()` method:
+{{{
+StyleElement elt = StyleInjector.injectStylesheet(CSS contents);
+StyleInjector.setContents(elt, New CSS contents);
+}}}
+
+= Caveats =
+
+Certain browsers have an upper bound on the total number of stylesheets  
that can be injected.  In this case, StyleInjector will append to  
previously-created stylesheets when `injectStylesheet` is called.  If the  
developer wishes to maintain relative ordering of CSS content, the  
`injectStylesheetAtEnd` and `injectStylesheetAtStart` methods should be  
used instead of `injectStylesheet`.
+
+In general, it is more efficient to concatenate the output of multiple  
CssResource instances before injecting the CSS to reduce the amount of time  
the CSS is re-parsed by the browser.

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



[gwt-contrib] [google-web-toolkit commit] r5453 - Edited wiki page through web user interface.

2009-05-21 Thread codesite-noreply

Author: b...@google.com
Date: Thu May 21 06:55:33 2009
New Revision: 5453

Modified:
wiki/StyleInjector.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/StyleInjector.wiki
==
--- wiki/StyleInjector.wiki (original)
+++ wiki/StyleInjector.wiki Thu May 21 06:55:33 2009
@@ -46,6 +46,6 @@

  = Caveats =

-Certain browsers have an upper bound on the total number of stylesheets  
that can be injected.  In this case, StyleInjector will append to  
previously-created stylesheets when `injectStylesheet` is called.  If the  
developer wishes to maintain relative ordering of CSS content, the  
`injectStylesheetAtEnd` and `injectStylesheetAtStart` methods should be  
used instead of `injectStylesheet`.
+Certain browsers have an upper bound on the total number of stylesheets  
that can be injected.  In this case, StyleInjector will append to  
previously-created stylesheets when `injectStylesheet()` is called.  If the  
developer wishes to maintain relative ordering of CSS content, the  
`injectStylesheetAtEnd()` and `injectStylesheetAtStart()` methods should be  
used instead of `injectStylesheet()`.

-In general, it is more efficient to concatenate the output of multiple  
CssResource instances before injecting the CSS to reduce the amount of time  
the CSS is re-parsed by the browser.
+In general, it is more efficient to concatenate the output of multiple  
CssResource instances before injecting the CSS to reduce the number of  
times the CSS is re-parsed by the browser.
\ No newline at end of file

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



[gwt-contrib] [google-web-toolkit commit] r5454 - RadioButtons were not sinking click events

2009-05-21 Thread codesite-noreply

Author: rj...@google.com
Date: Thu May 21 08:03:33 2009
New Revision: 5454

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

Log:
RadioButtons were not sinking click events
Issue: 3679
Reviewer: scottb


Modified: trunk/user/src/com/google/gwt/user/client/ui/RadioButton.java
==
--- trunk/user/src/com/google/gwt/user/client/ui/RadioButton.java   
(original)
+++ trunk/user/src/com/google/gwt/user/client/ui/RadioButton.java   Thu May 
 
21 08:03:33 2009
@@ -63,7 +63,8 @@
public RadioButton(String name) {
  super(DOM.createInputRadio(name));
  setStyleName(gwt-RadioButton);
-
+
+sinkEvents(Event.getTypeInt(ClickEvent.getType().getName()));
  sinkEvents(Event.getTypeInt(MouseUpEvent.getType().getName()));
  sinkEvents(Event.getTypeInt(BlurEvent.getType().getName()));
  sinkEvents(Event.getTypeInt(KeyDownEvent.getType().getName()));

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



[gwt-contrib] [google-web-toolkit commit] r5455 - Cherry pick of trunk r5454

2009-05-21 Thread codesite-noreply

Author: rj...@google.com
Date: Thu May 21 08:06:03 2009
New Revision: 5455

Modified:
releases/1.6/user/src/com/google/gwt/user/client/ui/RadioButton.java

Log:
Cherry pick of trunk r5454


Modified:  
releases/1.6/user/src/com/google/gwt/user/client/ui/RadioButton.java
==
--- releases/1.6/user/src/com/google/gwt/user/client/ui/RadioButton.java
 
(original)
+++ releases/1.6/user/src/com/google/gwt/user/client/ui/RadioButton.java
 
Thu May 21 08:06:03 2009
@@ -63,7 +63,8 @@
public RadioButton(String name) {
  super(DOM.createInputRadio(name));
  setStyleName(gwt-RadioButton);
-
+
+sinkEvents(Event.getTypeInt(ClickEvent.getType().getName()));
  sinkEvents(Event.getTypeInt(MouseUpEvent.getType().getName()));
  sinkEvents(Event.getTypeInt(BlurEvent.getType().getName()));
  sinkEvents(Event.getTypeInt(KeyDownEvent.getType().getName()));

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



[gwt-contrib] [google-web-toolkit commit] r5456 - Record cherry pick of 5454

2009-05-21 Thread codesite-noreply

Author: rj...@google.com
Date: Thu May 21 08:06:34 2009
New Revision: 5456

Modified:
releases/1.6/branch-info.txt

Log:
Record cherry pick of 5454


Modified: releases/1.6/branch-info.txt
==
--- releases/1.6/branch-info.txt(original)
+++ releases/1.6/branch-info.txtThu May 21 08:06:34 2009
@@ -60,6 +60,7 @@
  /trunk revision c4820 was merged (r5439) into this branch
  /trunk revision c5230 was merged (r5440) into this branch
  /trunk revision c5347 was merged (r5443) into this branch (removes broken  
test from c5333)
+/trunk revision c5454 was merged (r5455) into this branch (radio button  
fix)

  The next merge into trunk will be:
  svn merge -r5430:  
https://google-web-toolkit.googlecode.com/svn/releases/1.6 .

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



[gwt-contrib] [google-web-toolkit commit] r5457 - Rollback cherry pick of broken 5454

2009-05-21 Thread codesite-noreply

Author: rj...@google.com
Date: Thu May 21 08:19:10 2009
New Revision: 5457

Modified:
releases/1.6/branch-info.txt
releases/1.6/user/src/com/google/gwt/user/client/ui/RadioButton.java

Log:
Rollback cherry pick of broken 5454


Modified: releases/1.6/branch-info.txt
==
--- releases/1.6/branch-info.txt(original)
+++ releases/1.6/branch-info.txtThu May 21 08:19:10 2009
@@ -60,7 +60,6 @@
  /trunk revision c4820 was merged (r5439) into this branch
  /trunk revision c5230 was merged (r5440) into this branch
  /trunk revision c5347 was merged (r5443) into this branch (removes broken  
test from c5333)
-/trunk revision c5454 was merged (r5455) into this branch (radio button  
fix)

  The next merge into trunk will be:
  svn merge -r5430:  
https://google-web-toolkit.googlecode.com/svn/releases/1.6 .

Modified:  
releases/1.6/user/src/com/google/gwt/user/client/ui/RadioButton.java
==
--- releases/1.6/user/src/com/google/gwt/user/client/ui/RadioButton.java
 
(original)
+++ releases/1.6/user/src/com/google/gwt/user/client/ui/RadioButton.java
 
Thu May 21 08:19:10 2009
@@ -63,8 +63,7 @@
public RadioButton(String name) {
  super(DOM.createInputRadio(name));
  setStyleName(gwt-RadioButton);
-
-sinkEvents(Event.getTypeInt(ClickEvent.getType().getName()));
+
  sinkEvents(Event.getTypeInt(MouseUpEvent.getType().getName()));
  sinkEvents(Event.getTypeInt(BlurEvent.getType().getName()));
  sinkEvents(Event.getTypeInt(KeyDownEvent.getType().getName()));

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



[gwt-contrib] Re: split up long var lines

2009-05-21 Thread spoon

Thanks, Joel.  Committed at r5459.

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

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



[gwt-contrib] [google-web-toolkit commit] r5459 - Per issue 3455, split up very long var lines to avoid a bug in

2009-05-21 Thread codesite-noreply

Author: sp...@google.com
Date: Thu May 21 08:48:10 2009
New Revision: 5459

Added:
 
trunk/dev/core/src/com/google/gwt/dev/js/JsBreakUpLargeVarStatements.java
(contents, props changed)
trunk/user/src/com/google/gwt/core/CompilerParameters.gwt.xml
(contents, props changed)
Modified:
trunk/dev/core/src/com/google/gwt/dev/CompilePerms.java
trunk/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
trunk/user/src/com/google/gwt/core/Core.gwt.xml
trunk/user/test/com/google/gwt/emultest/EmulSuite.gwt.xml

Log:
Per issue 3455, split up very long var lines to avoid a bug in
the beta version of Safari 4.

This also adds a CompilerParameters module.  It looks useful for testing to  
be
able to tune way down compiler settings such as this one.

Review by: jgw



Modified: trunk/dev/core/src/com/google/gwt/dev/CompilePerms.java
==
--- trunk/dev/core/src/com/google/gwt/dev/CompilePerms.java (original)
+++ trunk/dev/core/src/com/google/gwt/dev/CompilePerms.java Thu May 21  
08:48:10 2009
@@ -184,7 +184,8 @@
Permutation permutation, UnifiedAst unifiedAst)
throws UnableToCompleteException {
  return JavaToJavaScriptCompiler.compilePermutation(logger, unifiedAst,
-permutation.getRebindAnswers(), permutation.getId());
+permutation.getRebindAnswers(), permutation.getPropertyOracles(),
+permutation.getId());
}

/**

Modified:  
trunk/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java 
 
(original)
+++ trunk/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java 
 
Thu May 21 08:48:10 2009
@@ -15,6 +15,7 @@
   */
  package com.google.gwt.dev.jjs;

+import com.google.gwt.core.ext.PropertyOracle;
  import com.google.gwt.core.ext.TreeLogger;
  import com.google.gwt.core.ext.UnableToCompleteException;
  import com.google.gwt.core.ext.linker.ArtifactSet;
@@ -81,6 +82,7 @@
  import com.google.gwt.dev.jjs.impl.TypeMap;
  import com.google.gwt.dev.jjs.impl.TypeTightener;
  import com.google.gwt.dev.js.EvalFunctionsAtTopScope;
+import com.google.gwt.dev.js.JsBreakUpLargeVarStatements;
  import com.google.gwt.dev.js.JsIEBlockSizeVisitor;
  import com.google.gwt.dev.js.JsInliner;
  import com.google.gwt.dev.js.JsNormalizer;
@@ -173,13 +175,14 @@
 *  {...@link #precompile(TreeLogger, WebModeCompilerFrontEnd,  
String[], JJSOptions, boolean)}
 * @param rebindAnswers the set of rebind answers to resolve all  
outstanding
 *  rebind decisions
+   * @param propertyOracles All property oracles corresponding to this  
permutation.
 * @return the output JavaScript
 * @throws UnableToCompleteException if an error other than
 *   {...@link OutOfMemoryError} occurs
 */
public static PermutationResult compilePermutation(TreeLogger logger,
UnifiedAst unifiedAst, MapString, String rebindAnswers,
-  int permutationId) throws UnableToCompleteException {
+  PropertyOracle[] propertyOracles, int permutationId) throws  
UnableToCompleteException {
  try {
if (JProgram.isTracingEnabled()) {
   
System.out.println();
@@ -291,6 +294,8 @@
// Work around an IE7 bug,
// http://code.google.com/p/google-web-toolkit/issues/detail?id=1440
JsIEBlockSizeVisitor.exec(jsProgram);
+
+  JsBreakUpLargeVarStatements.exec(jsProgram, propertyOracles);

// (12) Generate the final output text.
String[] js = new String[jsProgram.getFragmentCount()];

Added:  
trunk/dev/core/src/com/google/gwt/dev/js/JsBreakUpLargeVarStatements.java
==
--- (empty file)
+++  
trunk/dev/core/src/com/google/gwt/dev/js/JsBreakUpLargeVarStatements.java   
 
Thu May 21 08:48:10 2009
@@ -0,0 +1,106 @@
+/*
+ * Copyright 2009 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License); you may  
not
+ * use this file except in compliance with the License. You may obtain a  
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,  
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations  
under
+ * the License.
+ */
+package com.google.gwt.dev.js;
+
+import com.google.gwt.core.ext.BadPropertyValueException;
+import com.google.gwt.core.ext.ConfigurationProperty;
+import com.google.gwt.core.ext.PropertyOracle;
+import com.google.gwt.dev.jjs.InternalCompilerException;
+import 

[gwt-contrib] Re: split up long var lines

2009-05-21 Thread spoon


http://gwt-code-reviews.appspot.com/33826/diff/1/4
File user/src/com/google/gwt/core/CompilerParameters.gwt.xml (right):

http://gwt-code-reviews.appspot.com/33826/diff/1/4#newcode25
Line 25: set-configuration-property name='compiler.max.vars.per.var'
value='4900' /
Okay, I'll change it to half.

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

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



[gwt-contrib] [google-web-toolkit commit] r5460 - Resubmitting radio button fix to sink click events, this time

2009-05-21 Thread codesite-noreply

Author: rj...@google.com
Date: Thu May 21 08:59:40 2009
New Revision: 5460

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

Log:
Resubmitting radio button fix to sink click events, this time
with required import line.

Issue: 3679
Reviewer: scottb


Modified: trunk/user/src/com/google/gwt/user/client/ui/RadioButton.java
==
--- trunk/user/src/com/google/gwt/user/client/ui/RadioButton.java   
(original)
+++ trunk/user/src/com/google/gwt/user/client/ui/RadioButton.java   Thu May 
 
21 08:59:40 2009
@@ -18,6 +18,7 @@
  import com.google.gwt.dom.client.Element;
  import com.google.gwt.dom.client.EventTarget;
  import com.google.gwt.event.dom.client.BlurEvent;
+import com.google.gwt.event.dom.client.ClickEvent;
  import com.google.gwt.event.dom.client.KeyDownEvent;
  import com.google.gwt.event.dom.client.MouseUpEvent;
  import com.google.gwt.event.logical.shared.ValueChangeEvent;
@@ -63,7 +64,8 @@
public RadioButton(String name) {
  super(DOM.createInputRadio(name));
  setStyleName(gwt-RadioButton);
-
+
+sinkEvents(Event.getTypeInt(ClickEvent.getType().getName()));
  sinkEvents(Event.getTypeInt(MouseUpEvent.getType().getName()));
  sinkEvents(Event.getTypeInt(BlurEvent.getType().getName()));
  sinkEvents(Event.getTypeInt(KeyDownEvent.getType().getName()));

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



[gwt-contrib] [google-web-toolkit commit] r5462 - Record cherry pick of trunk c5460

2009-05-21 Thread codesite-noreply

Author: rj...@google.com
Date: Thu May 21 09:27:58 2009
New Revision: 5462

Modified:
releases/1.6/branch-info.txt

Log:
Record cherry pick of trunk c5460


Modified: releases/1.6/branch-info.txt
==
--- releases/1.6/branch-info.txt(original)
+++ releases/1.6/branch-info.txtThu May 21 09:27:58 2009
@@ -60,6 +60,7 @@
  /trunk revision c4820 was merged (r5439) into this branch
  /trunk revision c5230 was merged (r5440) into this branch
  /trunk revision c5347 was merged (r5443) into this branch (removes broken  
test from c5333)
+/trunk revision c5460 was merged (r5461) into this branch (radio button  
fix)

  The next merge into trunk will be:
  svn merge -r5430:  
https://google-web-toolkit.googlecode.com/svn/releases/1.6 .

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



[gwt-contrib] Re: Patch for issue 3279

2009-05-21 Thread dannydaemonic

Thanks for taking the time to listen, and for reviewing the code.  If I
come across as overly defensive, it's only due to the amount of time
I've invested in this code.  It's not due to any dislike for you, or
illusions of grandeur.  I appreciate the patience you've shown me.

 How about refactoring BitSet.java as follows. I have introduced 3
private methods to do the handling

As a side note, two of those three methods already exist with slightly
different names.  Methods that operate on an array of integers, instead
of an array of bits use the prefix raw.  I could change this to a
suffix of Word if you prefer it.

I had thought about storing all the indexes in a separate array before,
but this simplification comes at the expense of O(N) memory usage.  Sure
it's N/32, but that's still O(N).

If the code size and complexity are a serious problem, I can factor the
core of nextSetBit into a raw static method.  This method finds the next
element in the array by interleaving property checks and index
increments.  This method can then be called in a simple loop to operate
over the data for those bitwise operators, and in Java opposed to
JavaScript.  This favors dense arrays, but that usage is likely more
common.  It will be slower, but should be comparable in speed.  What do
you think?

 You probably want to introduce another java method and use it instead
of  5 in the code

I use  5 and  5 in both Java and Javascript.  I mention this in
the comment at the top of the class.  This is done to be readably
consistent between Java and JavaScript.  I can make static functions for
these, but that makes the JSNI code harder to read.  Have you considered
this?

The JSNI methods that use  5 or  5 include:
getLength(JsArrayInteger array)
clear(JsArrayInteger array, int bitIndex)
flip(JsArrayInteger array, int bitIndex)
get(JsArrayInteger array, int bitIndex)
set(JsArrayInteger array, int bitIndex)
nextSetBit(int fromIndex)

I've also replied to some of your comments in place.


http://gwt-code-reviews.appspot.com/33815/diff/9/1007
File user/super/com/google/gwt/emul/java/util/BitSet.java (right):

http://gwt-code-reviews.appspot.com/33815/diff/9/1007#newcode176
Line 176: }-*/;
On 2009/05/21 18:39:08, amit wrote:
 avoid using Log?

Integer::heighestOneBit doesn't calculate log2, so the only other option
is to bit twiddle the highest bit out.  When I tried this it was
slightly slower for some reason, but this method isn't called frequently
enough to make a difference.  It will be 3 or 4 more lines of code.  Is
this preferable?

http://gwt-code-reviews.appspot.com/33815/diff/9/1007#newcode498
Line 498: // the code used is faster than the following:
I'd imagine it's not uncommon in an /interpreted/ language that 1
instruction, whatever it is, is faster than 4 or 5 other instructions.
And a multiply is likely compiled away to shifts in JIT compiled VMs.

Are you asking me to site a published paper on this version of the
algorithm?  I googled and found this algorithm in an AMD reference:
www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF
  It's listed in chapter 8, on page 180.

The BitSet test unit I wrote shows this code to be twice as fast as
calling Integer::bitCount.  However, I looked up Integer::bitCount's
source and replaced my code with that, and it's nearly as fast.

The obvious conclusion here is that a majority of this gain is from
inlining.  Future versions of GWT may inline this for us, so I will
concede your point and replace this with Integer::bitCount unless you
say otherwise.

http://gwt-code-reviews.appspot.com/33815/diff/9/1005
File user/test/com/google/gwt/emultest/java/util/BitSetTest.java
(right):

http://gwt-code-reviews.appspot.com/33815/diff/9/1005#newcode117
Line 117: .cardinality());
 i.e., don't break between the object and its method name during an
invocation.

Oops, I don't normally break between an object and it's method.  I
formatted the code with eclipse and didn't catch this.

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

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



[gwt-contrib] Re: Patch for issue 3279

2009-05-21 Thread amitmanjhi

O(N) temporary memory usage, which having the three native methods
approach (getWordPositions, setWord, getWord) is likely to have, is a
reasonable tradeoff to make since it will greatly enhance readability.
Your approach of using array indexing already saves a lot of memory as
it only uses O(N) memory where N is the number of set bits. Trying to
optimize some temporary memory, by making the code much harder to read,
is a premature optimization.

Using nextSetBit() repeatedly is a non-starter since compared to the
integer-by-integer approach, every operation will be bit-by-bit. This
will be x-times slower, where x is the average number of bits set in an
integer.

So, I recommend refactoring all code such that getWordPositions,
getWord, and setWord are the *only* 3 JSNI methods. I *think* this is
possible. Thoughts? The Gwt compiler will also be able to optimize
better with only 3 Jsni methods.

For example, with cardinality, the method could be (Gwt Compiler will do
the necessary inlining):

   public int cardinality() {
 JsArrayInteger positions = getWordPositions(this.array);
 int count = 0;
 for (int i = 0; i  positions.length(); i++) {
   count += Integer.bitCount(positions.get(i));
 }
 return count;
   }

Finally, an implementation for length() without log can be:
   public int length() {
 JsArrayInteger positions = getWordPositions(this.array);
 int max = -1;
 for (int i = 0; i  positions.length(); i++) {
   int position = positions.get(i);
   if (position  max) {
 max = position;
   }
 }
 if (max == -1) {
   return 0;
 }
 // compute the position of the leftmost bit
 int wordValue = getWord(this.array, max);
 int position = max * 32;
 int offsets[] = {16, 8, 4, 2, 1};
 int intValues[] = {0x, 0xFF00, 0xF0, 0xC, 0x2};
 for (int i = 0; i  offsets.length; i++) {
   if ((wordValue  intValues[i]) != 0) {
 position = position + offsets[i];
 wordValue = wordValue  offsets[i];
   }
 }
 position += wordValue;
 return position;
   }

Note that I have not run any of the samples, but you should get the
basic idea. Looking forward to your patch with these changes.

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

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



[gwt-contrib] Re: Patch for issue 3279

2009-05-21 Thread dannydaemonic

 Using nextSetBit() repeatedly is a non-starter since compared to the
 integer-by-integer approach, every operation will be bit-by-bit. This
will be
 x-times slower, where x is the average number of bits set in an
integer.

I guess I wasn't clear in this regard, I was talking about just
refactoring out a method that's just the core of nextSetBit, perhaps
with the name nextValue.  This would find the next integer index into
the array, it would not operate on the bit level.  This is would be very
fast for dense arrays since the first thing it would check would be the
next index, and it'd find it.

 So, I recommend refactoring all code such that getWordPositions,
getWord, and
 setWord are the *only* 3 JSNI methods. I *think* this is possible.
Thoughts? The
 Gwt compiler will also be able to optimize better with only 3 Jsni
methods.

There are two other methods I think are essential

One to set the length(JsArrayInteger array, int length) {
 array.length = length;
}

and one to delete(JsArrayInteger array, int index) {
   delete array[index];
}

I also don't think methods like trimToSize are nearly as efficient in
Java, it's not hard to read, and I don't think there's much the compiler
can optimize there.

This is a large class.  How about I start by getting rid of as many JSNI
methods as I can.

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

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



[gwt-contrib] Add mhtml support to ClientBundle

2009-05-21 Thread bobv

Reviewers: rjrjr, jgw,

Description:
This patch adds support for bundling ClientBundle resources into a
single mhtml document to reduce the total number of round trips required
in IE6.  It furthermore enables the use of data: urls for IE8.

Specifics:
   - The mhtml format is defined in rfc 2557; it's basically a MIME
multipart message.
   - The new support is added by creating a new MhtmlResourceContext and
a trivial MhtmlClientBundleGenerator to load the new context
implementation when the ie6 user.agent is in use.
   - Moved the maximum size constant and base64 encoding function from
InlineResourceContext to AbstractResourceContext


I verified that the mhtml approach works in regular IE6 as well as IE8
in compatibility mode, both with ImageResource+Image widget and
imageresour...@sprite approaches.

The data: URL approach was verified with IE8 in standards mode.

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

Affected files:
   user/src/com/google/gwt/resources/Resources.gwt.xml

user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java

user/src/com/google/gwt/resources/rebind/context/AbstractResourceContext.java

user/src/com/google/gwt/resources/rebind/context/InlineResourceContext.java

user/src/com/google/gwt/resources/rebind/context/MhtmlClientBundleGenerator.java
   user/src/com/google/gwt/resources/rebind/context/MhtmlResourceContext.java

user/src/com/google/gwt/resources/rebind/context/StaticResourceContext.java



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