[gwt-contrib] Re: Fix Firefox 3.6 devmode plugin infinite install loop. (issue1642803)

[Chris Conroy]

LGTM

On Mon, Feb 13, 2012 at 5:55 PM,  wrote:

> On 2012/02/13 22:41:01, conroy wrote:
>
>> On 2012/02/13 22:24:15, acleung wrote:
>> > On 2012/02/13 21:21:54, conroy wrote:
>> > > FYI
>> > >
>> > > can you provide some more context on the problem and why this
>>
> fixes it?
>
>> > >
>> > > Note taht FF has poor handling of switching down between
>>
> incompatible
>
>> versions
>> > > in the same install location. So, if you point 3.6 at a user
>>
> directory that
>
>> > had
>> > > 7 installed, it will ask you to reinstall all your plugins--even
>>
> the
>
>> backwards
>> > > compatible ones. But, if you just have a naked 3.6 install and
>>
> then upgrade,
>
>> > > you're fine.
>> >
>> >
>> > I am actually not really sure myself. I added what I know in the
>>
> comment which
>
>> > basically came from trail-and-error.
>> >
>> > I am going to try opening an issue with them and see what they said.
>>
> I saw a
>
>> few
>> > related issue about infinite restarts that was fixed in later
>>
> version of
>
>> add-on
>> > manager.
>> >
>> > I did all my tests on clean profiles (wiping ~/.mozilla)
>> >
>> > -Alan
>>
>
>  FYI
>>
>
>  I'm confused why this is a problem for 3.6 *now* though. We aren't
>>
> changing the
>
>> 3.6 binaries, and the spec for the manifest in the XPI changed long
>>
> ago. Is this
>
>> just an issue from that switchover that we are just now aware of?
>>
>
>
> That's correct, we didn't change the binary. However, the validator
> still checks the new install.rdf and probably thinks strictCompatibility
> is an invalid property.
>
> I see a few similar bugs:
> https://bugzilla.mozilla.org/**show_bug.cgi?id=720175
>
>
> http://gwt-code-reviews.**appspot.com/1642803/
>

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

[gwt-contrib] Re: Add the missing plugins/xpcom/prebuilt/ff90/include/IOOPHM. (issue1631804)

[Chris Conroy]

It's generated from xpidl, no? So it's just been unchanging since 36. Not
guaranteed forever, but might be worth making it a build rule for if
GECKO_VERSION in some range, then use this one. If it changes, code will
have to update behind a build rule anyways.

On Fri, Jan 27, 2012 at 6:12 PM, Alan Leung  wrote:

> Is that a coincident or has this been decided?
>
> On Fri, Jan 27, 2012 at 2:59 PM,  wrote:
>
>> LGTM
>>
>> note that ff36 and after all share the same IOOPHM.h. We should
>> consolidate all of these to just one file for ff36+
>>
>> http://gwt-code-reviews.**appspot.com/1631804/
>>
>
>

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

[gwt-contrib] Re: Firefox 6 DevMode Plugin (issue1523805)

[Chris Conroy]

FYI Rietveld doesn't show binaries. I can look at the Cl for those though.
On Aug 23, 2011 8:00 PM,  wrote:
>
> On 2011/08/23 23:57:49, acleung wrote:
>
> Hmmm All the binaries are dropped.
>
>
>
> http://gwt-code-reviews.appspot.com/1523805/

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

[gwt-contrib] Re: Update the Missing Plugin page for FF5 support (issue1465807)

[Chris Conroy]

To accurately capture the matrix of platforms/versions would make the string
unintelligible to most. It's already a bit confusing with the PPC(3.x only),
but the firefox-old message caputres the problem of unsupported new versions
as well.

On Mon, Jun 27, 2011 at 3:51 PM,  wrote:

> On 2011/06/27 19:47:26, conroy wrote:
>
>> True, but I don't want that to be a listing of every version we ever
>> support. Instead, I'll just keep PPC marked as 3.x and the bifurcation
>>
> of
>
>> platform support can be inferred by the platforms that firefox
>>
> supports at
>
>> the various versions. I have re-exported and updated the firefox-old
>>
> message
>
>> to note that 5.0 as the upper bound.
>>
>
>  On Mon, Jun 27, 2011 at 3:42 PM,  wrote:
>>
>
>  >
>> > http://gwt-code-reviews.**apps**pot.com/1465807/diff/1/**
>> >
>>
>
> plugins/MissingPlugin/war/MissingPlugin.html code-reviews.appspot.com/**1465807/diff/1/plugins/**MissingPlugin/war/**
> MissingPlugin.html
> >
>
>> > File plugins/MissingPlugin/war/MissingPlugin.html (right):
>> >
>> > http://gwt-code-reviews.**apps**pot.com/1465807/diff/1/**
>> >
>>
>
> plugins/MissingPlugin/war/MissingPlugin.html#newcode84 ttp://gwt-code-reviews.**appspot.com/1465807/diff/1/**
> plugins/MissingPlugin/war/**MissingPlugin.html#newcode84
> >
>
>  > plugins/MissingPlugin/war/MissingPlugin.html:84: "platforms" :
>>
> "Win x86,
>
>> >
>> > Linux x86/x86_64, Mac x86/PPC(3.x only)/x86_64 (4.0+) only",
>> > can we safely say 4.0+? it seems ff versions are coming faster more
>> > furious then ever...
>> >
>> >
>> >
>>
>
> http://gwt-code-reviews.**apps**pot.com/1465807/%3Chttp://gwt-**
> code-reviews.appspot.com/**1465807/
> >
>
>> >
>>
>
> fine by me. LGTM
> just wanted to bring up that users will see/expect that missingplugin
> saying we support all FF versions but then potentially having the
> install failing. we probably need to keep an eye on the groups a clarify
> in the case it happens. go for it.
>
>
> http://gwt-code-reviews.**appspot.com/1465807/
>

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

[gwt-contrib] Re: [google-web-toolkit] r10387 committed - Add Linux support for FF5 (Gecko 5.0) in the xpcom plugin....

[Chris Conroy]

http://code.google.com/p/google-web-toolkit/source/detail?r=10391 should
unbreak FF4 and (and all the previous FF versions). Things are still
unstable, and I'm waiting on Mozilla to release an x86_64 OSX Gecko SDK.

If you like living dangerously, feel free to test the new XPI on Linux.

On Fri, Jun 24, 2011 at 11:15 AM, Thomas Broyer  wrote:

> On Fri, Jun 24, 2011 at 4:58 PM, Chris Conroy  wrote:
> > This is definitely temporary (and clearly not tested widely) as it only
> > supports Linux. You saw the extra permission prompt because this build
> > include's codefu's latest work of making the code server part of the
> > security model. Thanks for the heads up though. I'll ping back on this
> > thread when there's something a bit more stable to play with.
>
> Koen Maes has it working in FF5:
> https://twitter.com/#!/komasoftware/status/84268196655398913
> So I decided to upgrade to FF5 and it works (tested on another project
> though, with a different config: "ant editor-hosted" from Apache Wave,
> vs. –previously, in FF4– our mavenized project, launched from Eclipse
> with the GPE).
> My Eclipse is still unusable
> (https://twitter.com/#!/tbroyer/status/84266308585275393 ) so I cannot
> test with the GPE yet, but there's no reason it wouldn't work (btw,
> Apache Wave is using GWT 2.1.1 and our project a patched trunk@9848;
> but that shouldn't matter)
>

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

[gwt-contrib] Re: [google-web-toolkit] r10387 committed - Add Linux support for FF5 (Gecko 5.0) in the xpcom plugin....

[Chris Conroy]

This is definitely temporary (and clearly not tested widely) as it only
supports Linux. You saw the extra permission prompt because this build
include's codefu's latest work of making the code server part of the
security model. Thanks for the heads up though. I'll ping back on this
thread when there's something a bit more stable to play with.

On Fri, Jun 24, 2011 at 4:16 AM, Thomas Broyer  wrote:

> I tried the XPI from this commit in Firefox 4.0.1 on Ubuntu 11.04 (to check
> that it worked before upgrading to Firefox 5) and guess what: it failed!
>
> First, it prompted me to allow the "web and code server combination" again
> (I'm debugging in -noserver mode) despite being already there in the
> extension's preferences (and I didn't notice any change in the preferences
> after allowing it).
>
> Then when, as I was given a blank page, reloading it would still give me
> the same blank page. Looking at the Console view in Eclipse showed a couple
> lines per attempts (reloads):
> Connection received from localhost:32884
>[ERROR] Unexpected message type QUIT; expecting LoadModule
> Connection received from localhost:32887
>[ERROR] Unexpected message type QUIT; expecting LoadModule
> Connection received from localhost:32888
>[ERROR] Unexpected message type QUIT; expecting LoadModule
> Connection received from localhost:32889
>[ERROR] Unexpected message type QUIT; expecting LoadModule
>
> Is this expected with this "temporary" version?
>

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

Re: [gwt-contrib] GWT DevMode support for Chrome hosted Webapps/Extensions

[Chris Conroy]

Mark,

This is something we are interested in supporting at some point in the
future. The issue tracking it is here:
http://code.google.com/p/google-web-toolkit/issues/detail?id=5577

On Sun, Feb 20, 2011 at 7:16 PM, Mark Renouf  wrote:

> Hi all,
>
> I'm just writing to let everyone know I got this working. I was initially
> worried that Extesions/WebApps would not have access to the GWT DevMode
> plugin, but since Flash is supported I realized that this should work.
>
> It turns out there's just a few gotchas in making it work. The default
> loader script of the IFrame linker computes an absolute url for
> referencing the content source url. This happens to cause problems since
> the base url of a chrome extension/webapp is "chrome-extension:// hash>/..." and chrome rejects any absolute url that is not "http" or
> "https" or "file" and provided in the manifest.
>
> Luckily there is a meta override:
> 
>
> Which forces the injected IFrame source to become
> /module/hosted.html?module
>
> The second issue was the temporary source URL assigned to the IFrame before
> the content source is injected. It's initially set to "javascript:", which
> violates the same constraint mentioned above. Patching the function
> "maybeInjectFrame()" to assign "#" to iframe.src makes it all work.
>
> My manifest.json looks like this:
>
> {
> "name": "GWT DevMode Host page",
> "description": "Connect to GWT DevMode instance for Chrome Extension
> development",
> "version": "1",
> "app": {
> "launch": {
> "local_path": "index.html?gwt.codesvr=127.0.0.1:9997"
> }
> },
> ...other stuff...
> }
>
> Perhaps this might be better addressed in a custom linker... I don't know
> when I might have time to hack something together, but hopefully this info
> helps others.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

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

[gwt-contrib] Re: Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)

[Chris Conroy]

Actually, it does work.

On Tue, Feb 15, 2011 at 4:49 PM, Kelly Norton  wrote:
> I could be wrong, but I don't think the xsiframe linker is going to work
> here.
>
> On Tue, Feb 15, 2011 at 4:46 PM, Kelly Norton  wrote:
>>
>> xsiframe is fine if it works. But you'll have to check it because these
>> are not the normal xs restrictions.
>>
>> On Tue, Feb 15, 2011 at 4:28 PM, Unnur Gretarsdottir 
>> wrote:
>>>
>>> All google3 projects are being switched to xsiframe in a few weeks
>>> (currently blocked by lack of a Blaze push).  Deprecation/deletions of
>>> other linkers for regular GWT will soon follow, but to be honest, will
>>> be a GWT 3.0 thing at the very earliest.
>>>
>>> It's not a burning issue, but I do recommend that you do not switch to
>>> the xs linker at this point. It doesn't install in an iframe, and
>>> switching from being iframe installed vs. not has proven painful for
>>> some teams.  Right now - if you're using the std linker (default),
>>> your compliant with being installed in an iframe, so if you start
>>> using xs, pick up some code dependencies that assume non-iframe, and
>>> then need to switch back to iframe based (xsiframe), you may see some
>>> issues.  Or maybe not
>>>
>>> It's also possible that xs does not support DevMode - I can't remember
>>> off the top of my head.  If you care about that, then xsiframe
>>> definitely does support it.
>>>
>>> - Unnur
>>>
>>> On Tue, Feb 15, 2011 at 1:09 PM, John Tamplin  wrote:
>>> > On Tue, Feb 15, 2011 at 4:03 PM, Chris Conroy 
>>> > wrote:
>>> >>
>>> >> Sorry, didn't see your comment in time for the commit. I just used the
>>> >> same fix Kelly applied in SpeedTracer. I don't think it really matters
>>> >> strongly either way.
>>> >
>>> > As I understand it, the xs linker will soon be deprecated since the
>>> > xsiframe
>>> > linker provides a superset of its functionality.
>>> >
>>> > --
>>> > John A. Tamplin
>>> > Software Engineer (GWT), Google
>>> >
>>
>>
>>
>> --
>> If you received this communication by mistake, you are entitled to one
>> free ice cream cone on me. Simply print out this email including all
>> relevant SMTP headers and present them at my desk to claim your creamy
>> treat. We'll have a laugh at my emailing incompetence, and play a game of
>> ping pong. (offer may not be valid in all States).
>>
>
>
>
> --
> If you received this communication by mistake, you are entitled to one free
> ice cream cone on me. Simply print out this email including all relevant
> SMTP headers and present them at my desk to claim your creamy treat. We'll
> have a laugh at my emailing incompetence, and play a game of ping pong.
> (offer may not be valid in all States).
>
>

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

[gwt-contrib] Re: Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)

[Chris Conroy]

Sorry, didn't see your comment in time for the commit. I just used the
same fix Kelly applied in SpeedTracer. I don't think it really matters
strongly either way.

On Tue, Feb 15, 2011 at 3:56 PM,   wrote:
>
> http://gwt-code-reviews.appspot.com/1356803/diff/1/2
> File
> plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml
> (right):
>
> http://gwt-code-reviews.appspot.com/1356803/diff/1/2#newcode12
> plugins/npapi/DevModeOptions/src/com/google/gwt/devmodeoptions/DevModeOptions.gwt.xml:12:
> 
> I think you want to use xsiframe instead, as it is intended to be the
> one-size-fits-all linker.  Talk to unnurg if you have any difficulties
> using it instead.
>
> http://gwt-code-reviews.appspot.com/1356803/show
>

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

Re: [gwt-contrib] [google-web-toolkit] r9640 committed - Public: (by t.bro...@gmail.com):

[Chris Conroy]

correction

Public (by t.bro...@gmail.com):
Description:
http://code.google.com/p/google-web-toolkit/issues/detail?id=4916
<http://www.google.com/url?sa=D&q=http%3A//code.google.com/p/google-web-toolkit/issues/detail%3Fid%3D4916>

Remove old workaround code from DOMImplSafari for something that's been
fixed in Safari for a while makes it hard to work with optgroups in
select elements.

Reviewed by rj...@google.com
http://gwt-code-reviews.appspot.com/1313801/show
<http://www.google.com/url?sa=D&q=http%3A//gwt-code-reviews.appspot.com/1313801/show>

is the right description

The GIN friendliness change is r9603.

On Thu, Jan 27, 2011 at 6:56 PM, Chris Conroy  wrote:

> The real log message (now correct in svn) for this change is:
>
>
> Public (t.bro...@gmail.com):
>
> Addresses http://code.google.com/p/google-web-toolkit/issues/detail?id=5563
>
> For GIN friendliness, make the PlaceHistoryMapperGenerator return null
> when it encounters a concrete implementation. (Returning null from
> a code generator results in a new Foo() call.)
>
>
> On Thu, Jan 27, 2011 at 6:25 PM,  wrote:
>
>> Revision: 9640
>> Author: rj...@google.com
>> Date: Thu Jan 27 09:39:02 2011
>> Log: Public: (by t.bro...@gmail.com):
>> http://code.google.com/p/google-web-toolkit/source/detail?r=9640
>>
>> Modified:
>>  /trunk/user/src/com/google/gwt/dom/client/DOMImplSafari.java
>>  /trunk/user/test/com/google/gwt/dom/client/SelectTests.java
>>
>> ===
>> --- /trunk/user/src/com/google/gwt/dom/client/DOMImplSafari.java
>>  Wed Dec  1 10:08:22 2010
>> +++ /trunk/user/src/com/google/gwt/dom/client/DOMImplSafari.java
>>  Thu Jan 27 09:39:02 2011
>> @@ -276,36 +276,6 @@
>> return false;
>>   }-*/;
>>
>> -  /*
>> -   * The 'options' array cannot be used due to a bug in the version of
>> WebKit
>> -   * that ships with GWT (http://bugs.webkit.org/show_bug.cgi?id=10472).
>> The
>> -   * 'children' array, which is common for all DOM elements in Safari,
>> does not
>> -   * suffer from the same problem. Ideally, the 'children' array should
>> be used
>> -   * in all of the traversal methods in the DOM classes. Unfortunately,
>> due to a
>> -   * bug in Safari 2 (http://bugs.webkit.org/show_bug.cgi?id=3330), this
>> will
>> -   * not work. However, this bug does not cause problems in the case of
>> 
>> -   * elements, because their descendent elements are only one level deep.
>> -   */
>> -  @Override
>> -  public void selectClear(SelectElement select) {
>> -select.setInnerText("");
>> -  }
>> -
>> -  @Override
>> -  public native int selectGetLength(SelectElement select) /*-{
>> -return select.children.length;
>> -  }-*/;
>> -
>> -  @Override
>> -  public native NodeList selectGetOptions(SelectElement
>> select) /*-{
>> -return select.children;
>> -  }-*/;
>> -
>> -  @Override
>> -  public native void selectRemoveOption(SelectElement select, int index)
>> /*-{
>> -select.removeChild(select.children[index]);
>> -  }-*/;
>> -
>>   @Override
>>   public void setScrollLeft(Document doc, int left) {
>> // Safari always applies document scrolling to the body element, even
>> in
>> ===
>> --- /trunk/user/test/com/google/gwt/dom/client/SelectTests.java Sun Jul 19
>> 11:17:55 2009
>> +++ /trunk/user/test/com/google/gwt/dom/client/SelectTests.java Thu Jan 27
>> 09:39:02 2011
>> @@ -15,6 +15,8 @@
>>  */
>>  package com.google.gwt.dom.client;
>>
>> +import com.google.gwt.junit.DoNotRunWith;
>> +import com.google.gwt.junit.Platform;
>>  import com.google.gwt.junit.client.GWTTestCase;
>>
>>  /**
>> @@ -127,4 +129,45 @@
>> assertTrue(opt1.isSelected());
>> assertTrue(opt2.isSelected());
>>   }
>> -}
>> +
>> +  /**
>> +   * optgroups
>> +   *
>> +   * @see http://code.google.com/p/google-web-toolkit/issues/detail?id=4916";>Issue
>> 4916
>> +   */
>> +  @DoNotRunWith(Platform.HtmlUnitBug)
>> +  public void testOptGroups() {
>> +Document doc = Document.get();
>> +SelectElement select = doc.createSelectElement();
>> +doc.getBody().appendChild(select);
>> +
>> +OptionElement opt0 = doc.createOptionElement();
>> +OptionElement opt1 = doc.createOptionElement();
>> +OptionElement opt2 = doc.createOptionEle

Re: [gwt-contrib] [google-web-toolkit] r9640 committed - Public: (by t.bro...@gmail.com):

[Chris Conroy]

The real log message (now correct in svn) for this change is:


Public (t.bro...@gmail.com):

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

For GIN friendliness, make the PlaceHistoryMapperGenerator return null
when it encounters a concrete implementation. (Returning null from
a code generator results in a new Foo() call.)


On Thu, Jan 27, 2011 at 6:25 PM,  wrote:

> Revision: 9640
> Author: rj...@google.com
> Date: Thu Jan 27 09:39:02 2011
> Log: Public: (by t.bro...@gmail.com):
> http://code.google.com/p/google-web-toolkit/source/detail?r=9640
>
> Modified:
>  /trunk/user/src/com/google/gwt/dom/client/DOMImplSafari.java
>  /trunk/user/test/com/google/gwt/dom/client/SelectTests.java
>
> ===
> --- /trunk/user/src/com/google/gwt/dom/client/DOMImplSafari.javaWed
> Dec  1 10:08:22 2010
> +++ /trunk/user/src/com/google/gwt/dom/client/DOMImplSafari.javaThu
> Jan 27 09:39:02 2011
> @@ -276,36 +276,6 @@
> return false;
>   }-*/;
>
> -  /*
> -   * The 'options' array cannot be used due to a bug in the version of
> WebKit
> -   * that ships with GWT (http://bugs.webkit.org/show_bug.cgi?id=10472).
> The
> -   * 'children' array, which is common for all DOM elements in Safari,
> does not
> -   * suffer from the same problem. Ideally, the 'children' array should be
> used
> -   * in all of the traversal methods in the DOM classes. Unfortunately,
> due to a
> -   * bug in Safari 2 (http://bugs.webkit.org/show_bug.cgi?id=3330), this
> will
> -   * not work. However, this bug does not cause problems in the case of
> 
> -   * elements, because their descendent elements are only one level deep.
> -   */
> -  @Override
> -  public void selectClear(SelectElement select) {
> -select.setInnerText("");
> -  }
> -
> -  @Override
> -  public native int selectGetLength(SelectElement select) /*-{
> -return select.children.length;
> -  }-*/;
> -
> -  @Override
> -  public native NodeList selectGetOptions(SelectElement
> select) /*-{
> -return select.children;
> -  }-*/;
> -
> -  @Override
> -  public native void selectRemoveOption(SelectElement select, int index)
> /*-{
> -select.removeChild(select.children[index]);
> -  }-*/;
> -
>   @Override
>   public void setScrollLeft(Document doc, int left) {
> // Safari always applies document scrolling to the body element, even
> in
> ===
> --- /trunk/user/test/com/google/gwt/dom/client/SelectTests.java Sun Jul 19
> 11:17:55 2009
> +++ /trunk/user/test/com/google/gwt/dom/client/SelectTests.java Thu Jan 27
> 09:39:02 2011
> @@ -15,6 +15,8 @@
>  */
>  package com.google.gwt.dom.client;
>
> +import com.google.gwt.junit.DoNotRunWith;
> +import com.google.gwt.junit.Platform;
>  import com.google.gwt.junit.client.GWTTestCase;
>
>  /**
> @@ -127,4 +129,45 @@
> assertTrue(opt1.isSelected());
> assertTrue(opt2.isSelected());
>   }
> -}
> +
> +  /**
> +   * optgroups
> +   *
> +   * @see http://code.google.com/p/google-web-toolkit/issues/detail?id=4916";>Issue
> 4916
> +   */
> +  @DoNotRunWith(Platform.HtmlUnitBug)
> +  public void testOptGroups() {
> +Document doc = Document.get();
> +SelectElement select = doc.createSelectElement();
> +doc.getBody().appendChild(select);
> +
> +OptionElement opt0 = doc.createOptionElement();
> +OptionElement opt1 = doc.createOptionElement();
> +OptionElement opt2 = doc.createOptionElement();
> +OptGroupElement group1 = doc.createOptGroupElement();
> +opt0.setText("foo");
> +opt1.setText("bar");
> +opt2.setText("baz");
> +opt0.setValue("0");
> +opt1.setValue("1");
> +opt2.setValue("2");
> +group1.setLabel("group1");
> +
> +select.appendChild(opt0);
> +select.appendChild(group1);
> +group1.appendChild(opt1);
> +select.appendChild(opt2);
> +
> +assertEquals("3 options expected", 3,
> select.getOptions().getLength());
> +assertEquals("[0] == opt0", opt0, select.getOptions().getItem(0));
> +assertEquals("[1] == opt1", opt1, select.getOptions().getItem(1));
> +assertEquals("[2] == opt2", opt2, select.getOptions().getItem(2));
> +
> +select.remove(1);
> +assertNull("null parent expected when removed",
> opt1.getParentElement());
> +
> +select.add(opt1, opt0);
> +assertEquals("[0] == opt1", opt1, select.getOptions().getItem(0));
> +assertEquals("[1] == opt0", opt0, select.getOptions().getItem(1));
> +}
> +}
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

[gwt-contrib] Re: TreeItemTest got upset by Safari 3. (issue1270801)

[Chris Conroy]

LGTM
On Jan 7, 2011 7:12 PM,  wrote:
> Reviewers: conroy,
>
> Description:
> TreeItemTest got upset by Safari 3.
> Review by: con...@google.com
>
> Please review this at http://gwt-code-reviews.appspot.com/1270801/show
>
> Affected files:
> M user/test/com/google/gwt/user/client/ui/TreeItemTest.java
>
>
> Index: user/test/com/google/gwt/user/client/ui/TreeItemTest.java
> ===
> --- user/test/com/google/gwt/user/client/ui/TreeItemTest.java (revision
> 9517)
> +++ user/test/com/google/gwt/user/client/ui/TreeItemTest.java (working
copy)
> @@ -23,7 +23,7 @@
> */
> public class TreeItemTest extends GWTTestCase {
>
> - private static final String html = "helloworld";
> + private static final String HTML = "helloworld";
>
> @Override
> public String getModuleName() {
> @@ -60,8 +60,8 @@
>
> public void testAddItemSafeHtml() {
> TreeItem item = new TreeItem("foo");
> - TreeItem child = item.addItem(SafeHtmlUtils.fromSafeConstant(html));
> - assertEquals(html, child.getHTML().toLowerCase());
> + TreeItem child = item.addItem(SafeHtmlUtils.fromSafeConstant(HTML));
> + assertEquals(HTML, child.getHTML().toLowerCase());
> }
>
> /**
> @@ -72,7 +72,9 @@
> String text = "Sometext";
> TreeItem item = root.addTextItem(text);
> assertEquals(text, item.getText());
> - assertEquals("Some
text", item.getHTML());
> + // Normalize the html for ancient safari 3
> + String html = item.getHTML().replace(">", ">");
> + assertEquals("Some
text", html);
> }
>
> public void testAsTreeItem() {
> @@ -159,8 +161,8 @@
>
> public void testInsertItemSafeHtml() {
> TreeItem item = new TreeItem("foo");
> - TreeItem child = item.insertItem(0,
> SafeHtmlUtils.fromSafeConstant(html));
> - assertEquals(html, child.getHTML().toLowerCase());
> + TreeItem child = item.insertItem(0,
> SafeHtmlUtils.fromSafeConstant(HTML));
> + assertEquals(HTML, child.getHTML().toLowerCase());
> }
>
> /**
> @@ -199,15 +201,15 @@
> }
>
> public void testSafeHtmlConstructor() {
> - TreeItem item = new TreeItem(SafeHtmlUtils.fromSafeConstant(html));
> + TreeItem item = new TreeItem(SafeHtmlUtils.fromSafeConstant(HTML));
>
> - assertEquals(html, item.getHTML().toLowerCase());
> + assertEquals(HTML, item.getHTML().toLowerCase());
> }
>
> public void testSetSafeHtml() {
> TreeItem item = new TreeItem("foo");
> - item.setHTML(SafeHtmlUtils.fromSafeConstant(html));
> - assertEquals(html, item.getHTML().toLowerCase());
> + item.setHTML(SafeHtmlUtils.fromSafeConstant(HTML));
> + assertEquals(HTML, item.getHTML().toLowerCase());
> }
>
> /**
>
>

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

Re: [gwt-contrib] Re: Experimental framework for generator result caching in dev mode. (issue1227801)

[Chris Conroy]

Just a general comment: We should take care to make sure that anything
that's cached across a refresh doesn't pin the TypeOracle or
CompilingClassLoader (any reference to a type, for example, will do that).

On Fri, Dec 17, 2010 at 9:16 AM,  wrote:

> http://gwt-code-reviews.appspot.com/1227801/show
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

[gwt-contrib] Re: Guard against invalid dispIds in JavaDispatchImpl (issue1172801)

[Chris Conroy]

Welcome to rietveld's horribly broken interdiff handling. At least this is a
somewhat innocuous error...I'm pretty sure I've seen its interdiff swallow
actual changes.

(New files were added, and since they aren't in the baseline patch rietveld
confusingly does not provide a 'diff to patchset 1' for them, when it could
easly just diff against /dev/null)

On Wed, Dec 8, 2010 at 7:38 PM,  wrote:

> So what actually changed?  It looks the same as patch set 1.
>
>
>
> http://gwt-code-reviews.appspot.com/1172801/show
>

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

[gwt-contrib] Re: Fixes two issues (issue1181802)

[Chris Conroy]

that's a link to this review :P

On Thu, Dec 2, 2010 at 5:39 PM,  wrote:

> This is actually a repost of tboryer's patch originally submitted at:
>
>
> http://gwt-code-reviews.appspot.com/1181802
>
> On 2010/12/02 22:33:23, rchandia wrote:
>
>
>
>
> http://gwt-code-reviews.appspot.com/1181802/show
>

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

Re: [gwt-contrib] Re: Would GWT and/or incubator be interested in Run Time UiBinding

[Chris Conroy]

Sorry for the delay in responding.

I think that while this pattern may be useful for some users, it's probably
not something we would want to encourage everyone to use by making it part
of GWT proper. There are nontrivial runtime costs, you lose static analysis,
and this seems ripe for XSRF if not handled with great care, etc..

In the general case, it would be a lot better to use the existing tools to
accomplish the same thing: have the form designer install GPE and use
DevMode refresh to iterate. Also note that GWT Designer may suit your
needs: http://code.google.com/webtoolkit/tools/gwtdesigner/index.html


On Thu, Nov 18, 2010 at 12:33 AM, TedM  wrote:

> Hi Chris,
>
> I did what you said.
>
> 1. I took a couple of hours and I started up a Google Code project
> called gwt-binding-fly.  In it I added enough source to convey how
> easy and simple the solution is.
> http://code.google.com/p/gwt-binding-fly/
> 2. I removed all the GXT stuff and made it pure GWT, with enough
> flexibility to work with GXT and SmartGWT.
> 3. I also made a video walking you through the demo and the code.
> http://www.youtube.com/watch?v=R1OFfmUI6ko
>
> If you or anyone else has any questions or comments please send them
> my way.
>
> Ted Malaska
>
> On Nov 15, 11:13 am, Chris Conroy  wrote:
> > Ted, this is the right list for this sort of thing.
> >
> > I can't speak to the specifics of your project at the moment--though
> > you'd probably get a better response if you included a design doc
> > and/or code.
> >
> >
> >
> >
> >
> >
> >
> > On Sun, Nov 14, 2010 at 9:08 PM, TedM  wrote:
> >
> > > Thanks,
> >
> > > I wasn't thinking in the line of GWTDesigner.  The problem that I'm
> > > solving at work is related to dynamic form definition.  I want my
> > > business user to be able to define forms and send them out, without
> > > compiling and without things software installed on their locals.  I'm
> > > going to make a UI that plays through the browser (using GWT) that
> > > will allow a non-technical person to design these forms.
> >
> > > personally think this idea would be a great addition to GWT, but I
> > > don't want to start writing the OS version until I can talk to a GWT
> > > or incubator guy.
> >
> > > The out comes of that talk will be one of the following.
> > > 1. They like the idea, and maybe I can bounce my architectural ideas
> > > off them and then I build it with there input.
> > > 2. They already have this on their road map and don't need my help
> > > 3. They think it doesn't have value.
> >
> > > Do you know how I can get in contact with someone from GWT?
> >
> > > --
> > >http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

[gwt-contrib] Re: In CompilingClassLoader, refuse to load a class if its compilation unit has errors. (issue1167801)

[Chris Conroy]

First of a handful of related patches for improving DevMode error handling.

On Tue, Nov 30, 2010 at 8:34 PM,  wrote:

> Reviewers: scottb,
>
> Description:
> In CompilingClassLoader, refuse to load a class if its compilation unit
> has errors.
>
>
> Please review this at http://gwt-code-reviews.appspot.com/1167801/show
>
> Affected files:
>  M dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
>
>
> Index: dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
> ===
> --- dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
> (revision 9312)
> +++ dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
> (working copy)
> @@ -1070,6 +1070,13 @@
>  */
> while (toInject.size() > 0) {
>   CompilationUnit unit = toInject.remove(0);
> +  if (unit.isError()) {
> +logger.log(TreeLogger.ERROR,
> +"Cannot inject JSNI code in compilation unit "
> ++ unit.getTypeName() + " at " +
> unit.getDisplayLocation()
> ++ " for class " + className);
> +return null;
> +  }
>   if (!alreadyInjected.contains(unit)) {
> injectJsniMethods(unit);
> alreadyInjected.add(unit);
> @@ -1136,6 +1143,12 @@
>
> CompilationUnit unit = (compiledClass == null)
> ? getUnitForClassName(lookupClassName) : compiledClass.getUnit();
> +
> +if (unit != null && unit.isError()) {
> +  logger.log(TreeLogger.ERROR, "Cannot load class " + className + "
> because it has errors.");
> +  return null;
> +}
> +
> if (emmaAvailable) {
>   /*
>* build the map for anonymous classes. Do so only if unit has
> anonymous
>
>
>

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

Re: [gwt-contrib] Re: png compression

[Chris Conroy]

Paul,

Thanks for reporting this and pinging back. Sorry your first message got
lost in the shuffle.

On Wed, Nov 24, 2010 at 5:50 AM, Paul Robinson  wrote:

>  No reply on this, so I've just created issue 5651 so it doesn't get lost.
> It would be nice if the GWT compiler could produce png image bundles in
> compressed format.
>
> Background: The png file format has support for the deflate algorithm
> built-in, but png files don't *have* to use it. So some png files will
> contain compressed data, while others will not. GWT with an out-of-the-box
> JDK do not generate compressed png files.
>
> http://code.google.com/p/google-web-toolkit/issues/detail?id=5651
>
> Thanks,
> Paul
>
>
> On 03/11/10 00:13, Paul Robinson wrote:
>
> I've just started using this colour picker:
> http://code.google.com/p/auroris/wiki/ColorPicker
>
> One of the warnings its documentation provides is that when you compile it
> with GWT, the images it contains are compiled into a png file that is about
> 1MB. Whereas, if you then open that file in any image processing software
> and re-save it, it compresses down to around 110kb.
>
> The problem is that during the compile, GWT's ImageBundleBuilder uses
> javax.imageio.Imageio.write(BufferedImage, "png", outputStream), and with an
> out-of-the-box JDK installation, the javax.imageio.Imageio stuff does not
> support png compression. (png has support for the deflate algorithm
> built-in, but it seems you don't *have* to use it when writing out png
> files)
>
> However, by installing an additional package to add to my JDK, I managed to
> get a gwt compile to produce compressed png files:
>
> http://download.java.net/media/jai-imageio/builds/release/1.1/INSTALL-jai_imageio.html#Manual
>
> Some of my small png files got slightly bigger, but that 1MB png got much
> smaller.
>
> This is a known bug in the JDK, and there's a bug report here:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4829970
>
> but that's a very old bug report, so may not be fixed any time soon.
>
> Is this something that GWT could address, so that this would work correctly
> out-of-the-box?
>
> Thanks,
> Paul
>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

[gwt-contrib] Re: Update JUnit from DeferredCommand to Scheduler. (issue1145801)

[Chris Conroy]

LGTM.

FYI rietveld is unhappy with the patch for some reason: it's giving me
"error: old chunk mismatch" if I try to view the diff there.

On Tue, Nov 23, 2010 at 5:31 PM,  wrote:

> Reviewers: conroy,
>
> Message:
> Because DeferredCommand is deprecated.
>
>
>
> Please review this at http://gwt-code-reviews.appspot.com/1145801/show
>
> Affected files:
>
>  
> user/super/com/google/gwt/junit/translatable/com/google/gwt/junit/client/impl/GWTRunner.java
>
>
> Index:
> user/super/com/google/gwt/junit/translatable/com/google/gwt/junit/client/impl/GWTRunner.java
> diff --git
> a/user/super/com/google/gwt/junit/translatable/com/google/gwt/junit/client/impl/GWTRunner.java
> b/user/super/com/google/gwt/junit/translatable/com/google/gwt/junit/client/impl/GWTRunner.java
> index
> 4bcca0b7790ce6da85364c676615381e963cfc02..882a22a82e957fcfa1d919acfd11764dede08ed4
> 100644
> ---
> a/user/super/com/google/gwt/junit/translatable/com/google/gwt/junit/client/impl/GWTRunner.java
> +++
> b/user/super/com/google/gwt/junit/translatable/com/google/gwt/junit/client/impl/GWTRunner.java
> @@ -17,14 +17,13 @@ package com.google.gwt.junit.client.impl;
>
>  import com.google.gwt.core.client.EntryPoint;
>  import com.google.gwt.core.client.GWT;
> +import com.google.gwt.core.client.Scheduler;
>  import com.google.gwt.http.client.UrlBuilder;
>  import com.google.gwt.junit.client.GWTTestCase;
>  import com.google.gwt.junit.client.impl.JUnitHost.ClientInfo;
>  import com.google.gwt.junit.client.impl.JUnitHost.InitialResponse;
>  import com.google.gwt.junit.client.impl.JUnitHost.TestBlock;
>  import com.google.gwt.junit.client.impl.JUnitHost.TestInfo;
> -import com.google.gwt.user.client.Command;
> -import com.google.gwt.user.client.DeferredCommand;
>  import com.google.gwt.user.client.Timer;
>  import com.google.gwt.user.client.Window;
>  import com.google.gwt.user.client.rpc.AsyncCallback;
> @@ -252,7 +251,7 @@ public abstract class GWTRunner implements EntryPoint {
> ++currentTestIndex;
> if (currentTestIndex < currentBlock.getTests().length) {
>   // Run the next test after a short delay.
> -  DeferredCommand.addCommand(new Command() {
> +  Scheduler.get().scheduleDeferred(new Scheduler.ScheduledCommand() {
> public void execute() {
>   doRunTest();
> }
>
>
>

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

Re: [gwt-contrib] Re: TypeOracle becomes interfaces (issue1113801)

[Chris Conroy]

die getReloadCount. die!

On Wed, Nov 17, 2010 at 9:37 AM,  wrote:

> LGTM
>
> thanks for taking the time to make an easy to review diff.
>
>
> http://gwt-code-reviews.appspot.com/1113801/diff/1/17
> File dev/core/src/com/google/gwt/core/ext/typeinfo/JRawType.java
> (right):
>
> http://gwt-code-reviews.appspot.com/1113801/diff/1/17#newcode2
> dev/core/src/com/google/gwt/core/ext/typeinfo/JRawType.java:2: *
> Copyright 2008 Google Inc.
> date
>
> http://gwt-code-reviews.appspot.com/1113801/diff/1/19
> File dev/core/src/com/google/gwt/core/ext/typeinfo/JType.java (right):
>
> http://gwt-code-reviews.appspot.com/1113801/diff/1/19#newcode21
> dev/core/src/com/google/gwt/core/ext/typeinfo/JType.java:21: public
> interface JType {
> General comment: as a part of this refactoring effort, I feel it would
> be helpful to finish documenting these interfaces.   It won't be as
> simple to read anymore as just reading the method body, seeing as we
> will have multiple implementations.
>
> http://gwt-code-reviews.appspot.com/1113801/diff/1/32
> File dev/core/src/com/google/gwt/dev/javac/typemodel/JClassType.java
> (right):
>
> http://gwt-code-reviews.appspot.com/1113801/diff/1/32#newcode704
> dev/core/src/com/google/gwt/dev/javac/typemodel/JClassType.java:704: //
> TODO: Rename this to isRaw
> Do we still want to do this?  TODO(name?)
>
> http://gwt-code-reviews.appspot.com/1113801/diff/1/48
> File dev/core/src/com/google/gwt/dev/javac/typemodel/TypeOracle.java
> (right):
>
> http://gwt-code-reviews.appspot.com/1113801/diff/1/48#newcode525
> dev/core/src/com/google/gwt/dev/javac/typemodel/TypeOracle.java:525:
> public long getReloadCount() {
> Unrelated, but it looks like we're continuing to maintain dead code.  I
> see it is implemented elsewhere, but in the end, does this method have
> any callers? (I can't find it)
>
>
> http://gwt-code-reviews.appspot.com/1113801/show
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

[gwt-contrib] Re: In a previous patch, I fixed the doc.findElements... function to be document.findElements, which... (issue1118801)

[Chris Conroy]

LGTM.

It does trigger an error on Chrome as well.

On Wed, Nov 17, 2010 at 4:25 AM,  wrote:

> Reviewers: conroy,
>
> Description:
> In a previous patch, I fixed the doc.findElements... function to be
> document.findElements, which uncovered
> this bug where we were calling append rather than appendChild, which
> hoses on Safari. I'm not sure why
> it was ok for Chrome, which is where we tested the original fix...
>
>
> Please review this at http://gwt-code-reviews.appspot.com/1118801/show
>
> Affected files:
>  M dev/core/src/com/google/gwt/core/ext/linker/impl/devmode.js
>
>
> Index: dev/core/src/com/google/gwt/core/ext/linker/impl/devmode.js
> ===
> --- dev/core/src/com/google/gwt/core/ext/linker/impl/devmode.js (revision
> 9233)
> +++ dev/core/src/com/google/gwt/core/ext/linker/impl/devmode.js (working
> copy)
> @@ -215,8 +215,8 @@
>   obj.CLASSID = 'CLSID:1D6156B6-002B-49E7-B5CA-C138FB843B4E';
>
>   var dochead = document.getElementsByTagName('head')[0];
> -  dochead.append(embed);
> -  dochead.append(obj);
> +  dochead.appendChild(embed);
> +  dochead.appendChild(obj);
>  }
>
>  function findPluginObject() {
>
>
>

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

Re: [gwt-contrib] Re: Would GWT and/or incubator be interested in Run Time UiBinding

[Chris Conroy]

Ted, this is the right list for this sort of thing.

I can't speak to the specifics of your project at the moment--though
you'd probably get a better response if you included a design doc
and/or code.

On Sun, Nov 14, 2010 at 9:08 PM, TedM  wrote:
>
> Thanks,
>
> I wasn't thinking in the line of GWTDesigner.  The problem that I'm
> solving at work is related to dynamic form definition.  I want my
> business user to be able to define forms and send them out, without
> compiling and without things software installed on their locals.  I'm
> going to make a UI that plays through the browser (using GWT) that
> will allow a non-technical person to design these forms.
>
> personally think this idea would be a great addition to GWT, but I
> don't want to start writing the OS version until I can talk to a GWT
> or incubator guy.
>
> The out comes of that talk will be one of the following.
> 1. They like the idea, and maybe I can bounce my architectural ideas
> off them and then I build it with there input.
> 2. They already have this on their road map and don't need my help
> 3. They think it doesn't have value.
>
> Do you know how I can get in contact with someone from GWT?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] Re: Internal compiler error with GWT 2.1.0 RC1 when using generics

[Chris Conroy]

Actually, to get a more accurate picture than just looking at JConsole
graphs, you could add -verbose:gc to the jvm flags and report back
with the before and after logs that produces.

On Wed, Nov 10, 2010 at 2:26 PM, Chris Conroy  wrote:
> Yves,
>
> You say this error did not occur before your most recent change. It
> would be useful to get an idea for the memory usage before this
> change: it could be that your app is just very large and you were
> already on the edge of an OOME, your change really necessitates more
> memory, or this is a pathological case.
>
>
> Here are a few things to try for gathering more useful information:
>
> -Try attaching jconsole to the compile in the before and after
> scenario and see how the memory usage compares between both.
>
> -add -XX:-HeapDumpOnOutOfMemoryError to the JVM args for your failing
> compile. There may be some interesting data in the resulting dump. If
> you can share the heap dump with us (you can send me a link off list
> if you like), then I can take a look.
>
> -Of course, make sure you are using the latest version of the GWT
> compiler. The 2.1 compiler contains some changes that will reduce the
> memory footprint of your compile.
>
> On Wed, Nov 10, 2010 at 1:20 PM, Scott Blum  wrote:
>> Hmmm what happens if you turn down the log level, say to "WARN"?
>> Are you invoking from the command line, or are you using the Google Plugin
>> for Eclipse?
>>
>> On Wed, Nov 10, 2010 at 4:16 PM, yves  wrote:
>>>
>>> Scott,
>>> Thx for the tip. Anyway I can't allocate more than -Xmx1590M and I get
>>> exactly the same error.
>>> Yves
>>>
>>>
>>> On 9 nov, 07:47, Scott Blum  wrote:
>>> > Hmm can you increase your virtual memory?
>>> >
>>> > On Mon, Nov 8, 2010 at 5:13 PM, yves  wrote:
>>> > > I can't, I only have 2GB RAM, I get this error as from -Xmx1024M
>>> > >     [java] Error occurred during initialization of VM
>>> > >     [java] Could not reserve enough space for object heap
>>> > >     [java] Could not create the Java virtual machine.
>>> >
>>> > > and the log level is INFO
>>> > > Yves
>>> >
>>> > > On 8 nov, 22:53, Scott Blum  wrote:
>>> > > > What if you turn the heap up to -Xmx2048M?
>>> >
>>> > > > What log level are you using?
>>> >
>>> > > > On Mon, Nov 8, 2010 at 4:44 PM, yves  wrote:
>>> > > > > Hi,
>>> >
>>> > > > > I had a class named "ResultNode" and the project compiled fine.
>>> > > > > In order to improve the code, I changed this class by adding
>>> > > > > generic
>>> > > > > stuff like that : ResultNode>.
>>> > > > > Of course I adapted the entire project where needed to take
>>> > > > > advantage
>>> > > > > of this change.
>>> >
>>> > > > > Now I get an "Internal compiler error"
>>> >
>>> > > > > This is produced with java memory settings "-Xmx768M" and
>>> > > > > "-Xss32M" .
>>> > > > > (usually the settings are -Xmx128M and default value for -Xss and
>>> > > > > I
>>> > > > > never had such problem).
>>> >
>>> > > > > BTW : a "javac" compilation on the project is succesfull, so it is
>>> > > > > not
>>> > > > > a java error.
>>> >
>>> > > > > Any suggestion ? If more information is needed do not hesitate to
>>> > > > > ask.
>>> > > > > Thanks in advance
>>> > > > > Yves
>>> >
>>> > > > >     [java] Compiling module com.mycompany.myproject.MyProject
>>> > > > >     [java]    [ERROR] Errors in
>>> > > > > 'file:/C:/java/workspace/MyProject/
>>> > > > > src/com/mycompany/myproject/client/model/AppActivityMapper.java'
>>> > > > >     [java]       [ERROR]  Internal compiler error
>>> > > > >     [java] java.lang.OutOfMemoryError: Java heap space
>>> > > > >     [java]     at java.util.Arrays.copyOf(Arrays.java:2882)
>>> > > > >     [java]     at
>>> >
>>> > >
>>> > > java.lang.AbstractStringBuilder.expandCapacity(Abst

Re: [gwt-contrib] Re: Internal compiler error with GWT 2.1.0 RC1 when using generics

[Chris Conroy]

Yves,

You say this error did not occur before your most recent change. It
would be useful to get an idea for the memory usage before this
change: it could be that your app is just very large and you were
already on the edge of an OOME, your change really necessitates more
memory, or this is a pathological case.


Here are a few things to try for gathering more useful information:

-Try attaching jconsole to the compile in the before and after
scenario and see how the memory usage compares between both.

-add -XX:-HeapDumpOnOutOfMemoryError to the JVM args for your failing
compile. There may be some interesting data in the resulting dump. If
you can share the heap dump with us (you can send me a link off list
if you like), then I can take a look.

-Of course, make sure you are using the latest version of the GWT
compiler. The 2.1 compiler contains some changes that will reduce the
memory footprint of your compile.

On Wed, Nov 10, 2010 at 1:20 PM, Scott Blum  wrote:
> Hmmm what happens if you turn down the log level, say to "WARN"?
> Are you invoking from the command line, or are you using the Google Plugin
> for Eclipse?
>
> On Wed, Nov 10, 2010 at 4:16 PM, yves  wrote:
>>
>> Scott,
>> Thx for the tip. Anyway I can't allocate more than -Xmx1590M and I get
>> exactly the same error.
>> Yves
>>
>>
>> On 9 nov, 07:47, Scott Blum  wrote:
>> > Hmm can you increase your virtual memory?
>> >
>> > On Mon, Nov 8, 2010 at 5:13 PM, yves  wrote:
>> > > I can't, I only have 2GB RAM, I get this error as from -Xmx1024M
>> > >     [java] Error occurred during initialization of VM
>> > >     [java] Could not reserve enough space for object heap
>> > >     [java] Could not create the Java virtual machine.
>> >
>> > > and the log level is INFO
>> > > Yves
>> >
>> > > On 8 nov, 22:53, Scott Blum  wrote:
>> > > > What if you turn the heap up to -Xmx2048M?
>> >
>> > > > What log level are you using?
>> >
>> > > > On Mon, Nov 8, 2010 at 4:44 PM, yves  wrote:
>> > > > > Hi,
>> >
>> > > > > I had a class named "ResultNode" and the project compiled fine.
>> > > > > In order to improve the code, I changed this class by adding
>> > > > > generic
>> > > > > stuff like that : ResultNode>.
>> > > > > Of course I adapted the entire project where needed to take
>> > > > > advantage
>> > > > > of this change.
>> >
>> > > > > Now I get an "Internal compiler error"
>> >
>> > > > > This is produced with java memory settings "-Xmx768M" and
>> > > > > "-Xss32M" .
>> > > > > (usually the settings are -Xmx128M and default value for -Xss and
>> > > > > I
>> > > > > never had such problem).
>> >
>> > > > > BTW : a "javac" compilation on the project is succesfull, so it is
>> > > > > not
>> > > > > a java error.
>> >
>> > > > > Any suggestion ? If more information is needed do not hesitate to
>> > > > > ask.
>> > > > > Thanks in advance
>> > > > > Yves
>> >
>> > > > >     [java] Compiling module com.mycompany.myproject.MyProject
>> > > > >     [java]    [ERROR] Errors in
>> > > > > 'file:/C:/java/workspace/MyProject/
>> > > > > src/com/mycompany/myproject/client/model/AppActivityMapper.java'
>> > > > >     [java]       [ERROR]  Internal compiler error
>> > > > >     [java] java.lang.OutOfMemoryError: Java heap space
>> > > > >     [java]     at java.util.Arrays.copyOf(Arrays.java:2882)
>> > > > >     [java]     at
>> >
>> > >
>> > > java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:
>> > > > > 100)
>> > > > >     [java]     at
>> > > > >
>> > > > > java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
>> > > > >     [java]     at
>> > > java.lang.StringBuilder.append(StringBuilder.java:119)
>> > > > >     [java]     at
>> >
>> > >
>> > > com.google.gwt.dev.util.log.PrintWriterTreeLogger.doBranch(PrintWriterTreeLogger.java:
>> > > > > 59)
>> > > > >     [java]     at
>> >
>> > >
>> > > com.google.gwt.dev.util.log.AbstractTreeLogger.branch(AbstractTreeLogger.java:
>> > > > > 126)
>> > > > >     [java]     at
>> > > > > com.google.gwt.core.ext.TreeLogger.branch(TreeLogger.java:222)
>> > > > >     [java]     at
>> >
>> > >
>> > > com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:
>> > > > > 939)
>> > > > >     [java]     at
>> >
>> > >
>> > > com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkTypeArgument(SerializableTypeOracleBuilder.java:
>> > > > > 1412)
>> > > > >     [java]     at
>> >
>> > >
>> > > com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtype(SerializableTypeOracleBuilder.java:
>> > > > > 1219)
>> > > > >     [java]     at
>> >
>> > >
>> > > com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.checkSubtypes(SerializableTypeOracleBuilder.java:
>> > > > > 1309)
>> > > > >     [java]     at
>> >
>> > >
>> > > com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.computeTypeInstantiability(SerializableTypeOracleBuilder.java:
>> > > > > 1011)
>> > > > >     [java]     at
>>

[gwt-contrib] Re: Experimental version of GeoLocation API (issue1060801)

[Chris Conroy]

Ah yes, I'm used to seeing far fewer arguments and still find the syntax
unpleasant
You know a syntax is ugly when a method signature looks like a toddler snuck
up and smashed some keys when you weren't looking :P

Sorry for the brain fart there.

On Thu, Oct 28, 2010 at 3:16 PM,  wrote:

> That translates to an arglist of:
>
> A Java object of this type:
>
> "Lcom/google/gwt/experimental/geolocation/Geolocation$Handler;"
> Followed by seven doubles: "DDD"
> Followed by four booleans: ""
> Followed by a double: "D"
>
>
> On 2010/10/28 18:55:51, conroy wrote:
>
>> http://gwt-code-reviews.appspot.com/1060801/diff/10001/11003#newcode98
>>
>
>
> user/src/com/google/gwt/experimental/geolocation/impl/GeolocationImpl.java:98:
>
>
> @com.google.gwt.experimental.geolocation.impl.GeolocationImpl::success(Lcom/google/gwt/experimental/geolocation/Geolocation$Handler;DDDD)(
>
>> my JNI-JSNI-fu fails me here: ';DDDD'
>>
>
>
>
> http://gwt-code-reviews.appspot.com/1060801/show
>

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

[gwt-contrib] Re: Update the npapi plugin to support OSX. (issue1036801)

[Chris Conroy]

I'm glad you mention this: In the latest version of the patch I'm nuking
Makefile.mac (amongst other cruft) since unused bits like this laying around
just cause confusion.

XP_MACOSX is set higher up in the Makefile on the OS==mac check. I set
XP_UNIX there so that linux and mac can share it.

On Wed, Oct 20, 2010 at 4:00 PM,  wrote:

> On 2010/10/20 19:44:12, conroy wrote:
>
>> http://gwt-code-reviews.appspot.com/1036801/diff/6001/7001
>> File plugins/npapi/Makefile (right):
>>
>
>  http://gwt-code-reviews.appspot.com/1036801/diff/6001/7001#newcode47
>> plugins/npapi/Makefile:47: CFLAGS += -DBROWSER_NPAPI -DXP_UNIX
>>
> -fshort-wchar
>
>> On 2010/10/20 19:31:06, fabiomfv wrote:
>> > out of curiosity, why are we defining XP_UNIX for a presumably mac
>>
> build?
>
>  Mac is a variant of Unix. The other npapi plugin code I looked at all
>>
> defined
>
>> XP_UNIX for both linux and mac builds.
>>
>
> I guess want I really meant was why we don't need XP_MACOSX explicitly
> and only XP_UNIX? for instance, looking at makefile.mac it seems they
> refer to both.
>
>
>
> http://gwt-code-reviews.appspot.com/1036801/show
>

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

[gwt-contrib] Re: remove packages.properties on an ant clean (issue973801)

[Chris Conroy]

+cc:rice (meant to cc him originally)

thanks

On Fri, Oct 8, 2010 at 5:07 PM,   wrote:
> LGTM
>
>
> http://gwt-code-reviews.appspot.com/973801/show
>

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

Re: [gwt-contrib] Re: If Java optimizers are not run to full completion (part of another proposed patch), (issue897803)

[Chris Conroy]

Comparing reference equality for Integer objects in Java is a bit of a
minefield...

Integer x = 1;
Integer y = 1;
System.out.println("1==1? " + (x==y ? "yes" : "no"));

x = 127;
y = 127;
System.out.println("127==127? " + (x==y ? "yes" : "no"));

x = 128;
y = 128;
System.out.println("128==128? " + (x==y ? "yes" : "no"));

the above code produces:
1==1? yes
127==127? yes
128==128? no

because Java interns integers from -127 to 127.

On Thu, Sep 23, 2010 at 4:36 PM, Scott Blum  wrote:

> This actually gives me pause.  What kind of code can leave primitives on
> one side but not the other?
>
> I'm concerned because in Java, I think this should be true:
>
> Integer.valueOf(1) == 1
>
> Because the RHS gets autoboxed.  If we're translating this as-is into JS
> triple-equals without boxing it, the test would fail.
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] Re: Adds a way to tune the optimization level in steps from (issue915802)

[Chris Conroy]

Out of curiosity, which optimizer improves performance with a size increase
side-effect? That might be worth exploring if the trade-off is sensible.

How does setting the number of passes to 3 affect optimizations that don't
have an effect on code size? (I know this is harder to measure, but it's
worth thinking about since that's essentially a hidden dimension on this
graph)

On Thu, Sep 23, 2010 at 3:55 PM, Eric Ayers  wrote:

> On Thu, Sep 23, 2010 at 3:48 PM, Chris Conroy  wrote:
>
>> Why does the compiled size increase from 8 to 9? That would seem to
>> indicate a bug with the optimizer in that step.
>>
>
> Optimizers don't just reduce code size - they also attempt to improve
> performance.
>
>
>> On Thu, Sep 23, 2010 at 3:41 PM, Eric Ayers  wrote:
>>
>>> The attached graph shows an analysis of code size to compile time for
>>> building a large application.  The code size is the total number of bytes
>>> output for .cache.js files for all permutations added together.
>>>
>>> Somewhere between passes 2 to 4 is a "sweet spot", where further
>>> optimization passes appear to be returning only marginal improvements.   At
>>>  3 optimization passes,  Another way to verify that besides just the code
>>> size metric is to look at the statistics I added in a week ago that show how
>>> much the tree changes on each pass.  When we looked at the same application,
>>> Changes were measured in the thousands on the first pass or two, then
>>> trickled down into the tens in later passes.
>>>
>>> Previously, I had another implementation of this feature where the
>>> DataflowOptimizer and SameParameterValueOptimizer were automatically turned
>>> off until level 6 or higher (you can flip these off with a separate command
>>> line flag).  In that case, code size was nearly the same, and compile time
>>> was 220 seconds at optimization level 3.
>>>
>>> full optimization: 300s
>>> 3 passes only: 250s
>>> 3 passes - aggressive optimizations: 220s
>>>
>>> -Eric.
>>>
>>> On Thu, Sep 23, 2010 at 3:32 PM,  wrote:
>>>
>>>> Reviewers: scottb, fabbott, Lex,
>>>>
>>>> Description:
>>>> Adds a way to tune the optimization level in steps from
>>>> draft optimize to full optimization (the current default)
>>>>
>>>> Preliminary testing shows that optimization level '3'
>>>> can give almost as good code size results (within 5%)
>>>> as full optimization, with about 20% reduction in compile time.
>>>>
>>>>
>>>> Please review this at http://gwt-code-reviews.appspot.com/915802/show
>>>>
>>>> Affected files:
>>>>  M dev/core/src/com/google/gwt/dev/Precompile.java
>>>>  M dev/core/src/com/google/gwt/dev/jjs/JJSOptions.java
>>>>  M dev/core/src/com/google/gwt/dev/jjs/JJSOptionsImpl.java
>>>>  M dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
>>>>  M dev/core/src/com/google/gwt/dev/util/arg/ArgHandlerDraftCompile.java
>>>>  A dev/core/src/com/google/gwt/dev/util/arg/ArgHandlerOptimize.java
>>>>  D dev/core/src/com/google/gwt/dev/util/arg/OptionDraftCompile.java
>>>>  A dev/core/src/com/google/gwt/dev/util/arg/OptionOptimize.java
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Eric Z. Ayers
>>> Google Web Toolkit, Atlanta, GA USA
>>>
>>>  --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>
>>
>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>
>
>
> --
> Eric Z. Ayers
> Google Web Toolkit, Atlanta, GA USA
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] Re: Adds a way to tune the optimization level in steps from (issue915802)

[Chris Conroy]

Why does the compiled size increase from 8 to 9? That would seem to indicate
a bug with the optimizer in that step.

On Thu, Sep 23, 2010 at 3:41 PM, Eric Ayers  wrote:

> The attached graph shows an analysis of code size to compile time for
> building a large application.  The code size is the total number of bytes
> output for .cache.js files for all permutations added together.
>
> Somewhere between passes 2 to 4 is a "sweet spot", where further
> optimization passes appear to be returning only marginal improvements.   At
>  3 optimization passes,  Another way to verify that besides just the code
> size metric is to look at the statistics I added in a week ago that show how
> much the tree changes on each pass.  When we looked at the same application,
> Changes were measured in the thousands on the first pass or two, then
> trickled down into the tens in later passes.
>
> Previously, I had another implementation of this feature where the
> DataflowOptimizer and SameParameterValueOptimizer were automatically turned
> off until level 6 or higher (you can flip these off with a separate command
> line flag).  In that case, code size was nearly the same, and compile time
> was 220 seconds at optimization level 3.
>
> full optimization: 300s
> 3 passes only: 250s
> 3 passes - aggressive optimizations: 220s
>
> -Eric.
>
> On Thu, Sep 23, 2010 at 3:32 PM,  wrote:
>
>> Reviewers: scottb, fabbott, Lex,
>>
>> Description:
>> Adds a way to tune the optimization level in steps from
>> draft optimize to full optimization (the current default)
>>
>> Preliminary testing shows that optimization level '3'
>> can give almost as good code size results (within 5%)
>> as full optimization, with about 20% reduction in compile time.
>>
>>
>> Please review this at http://gwt-code-reviews.appspot.com/915802/show
>>
>> Affected files:
>>  M dev/core/src/com/google/gwt/dev/Precompile.java
>>  M dev/core/src/com/google/gwt/dev/jjs/JJSOptions.java
>>  M dev/core/src/com/google/gwt/dev/jjs/JJSOptionsImpl.java
>>  M dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
>>  M dev/core/src/com/google/gwt/dev/util/arg/ArgHandlerDraftCompile.java
>>  A dev/core/src/com/google/gwt/dev/util/arg/ArgHandlerOptimize.java
>>  D dev/core/src/com/google/gwt/dev/util/arg/OptionDraftCompile.java
>>  A dev/core/src/com/google/gwt/dev/util/arg/OptionOptimize.java
>>
>>
>>
>
>
> --
> Eric Z. Ayers
> Google Web Toolkit, Atlanta, GA USA
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

Re: [gwt-contrib] Re: Always use unix-style line endings in Generators. (issue776803)

[Chris Conroy]

Yeah, that's why I qualified it with partially. I guess the logical answer
if he's getting different behavior would be that he is in fact not compiling
the same code or is using a different version of the SDK.

On Fri, Aug 20, 2010 at 3:16 PM, John Tamplin  wrote:

> On Fri, Aug 20, 2010 at 3:12 PM, Chris Conroy  wrote:
>
>> well, that would at least partially explain this:
>> http://groups.google.com/group/google-web-toolkit/browse_thread/thread/5d026150c1d31b6f?hl=en#
>
>
> That might explain why the compiled code was different, but wouldn't
> explain why he was getting different behavior.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Chris Conroy
Software Engineer
Google, Atlanta

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

Re: [gwt-contrib] Re: Always use unix-style line endings in Generators. (issue776803)

[Chris Conroy]

well, that would at least partially explain this:
http://groups.google.com/group/google-web-toolkit/browse_thread/thread/5d026150c1d31b6f?hl=en#

On Fri, Aug 20, 2010 at 2:48 PM,  wrote:

> LGTM if you scatter some notes explaining why.
>
>
> On 2010/08/20 18:25:49, bobv wrote:
>
>> Change LGTM, but why is this a problem in practice?  Isn't the
>>
> generated source
>
>> transient?
>>
>
>
>
> http://gwt-code-reviews.appspot.com/776803/show
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>



-- 
Chris Conroy
Software Engineer
Google, Atlanta

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