[gwt-contrib] Re: Feature idea - reference Java methods as Javascript functions

[Vitali Lovich]

On Fri, May 29, 2009 at 11:59 AM, John Tamplin  wrote:

> On Fri, May 29, 2009 at 11:31 AM, Vitali Lovich  wrote:
>
>>  The way you get a method reference in pure Java is via reflection, which
>>> in general is not feasible though there have been some discussions of
>>> allowing it when everything can be evaluated at compile time (ie, all
>>> constants for classes and method/field names) -- even that seems to be a
>>> long way away however.
>>>
>> How about through GWT.create?  Then it uses reflection to supply the
>> actual function.  Might be limited to JSNI functions unless you can compile
>> code fragments.
>>
>>>
> GWT.create takes a single class literal, so there is no way to describe a
> method.  You could have it generate an object with a callback function, but
> that is going to be a lot more boilerplate than just having a simple JSNI
> method that returns the torn-off function.
>
>
Not necessarily GWT.create - just something along those lines that provides
enough static information for it to resolve the method yet also provide
compile-time checking for that.  I'm still thinking about it - it is
difficult to think of a clean way of doing it (without the boilerplate code
as you mentioned) since overloading is what causes problems.


> I haven't actually looked at the plugin yet.
>>
>
> If you are worried about JSNI syntax or autocompletion, you really should.
> You also get a "Deploy to Google" button for AppEngine integration.
>
I'm not actually - it would just be nice to not have to drop into JSNI for
something that is seemingly so simple.

>
>
>
>> Why not create a JsFunction class that extends from JavaScriptObject to
>> represent a JS lambda function.
>>
>> However, since you can't have polymorphic dispatch on JSOs, that would
>>> reserve whatever name was chosen from all subclasses, so it would have to be
>>> something unlikely to collide.
>>>
>>
>> I'm not sure what you mean here.  Why would you need to reserve a name?
>>
>
> Because of how JSOs work (in that you can freely cast them to each other),
> JSO method calls have to be statically resolvable.  If we put a call()
> method on JavaScriptObject, no other JSO subclass could have a call method
> with the same signature (and that restriction is enforced by requiring the
> method or class to be final).  However, your suggestion of putting it on a
> JSO subclass solves that problem.
>
> The remaining complication is that you can't declare a JSNI method with
> varargs, so it is somewhat complicated to build the args list for the call.
> You would probably also have to have one for void returns and one for calls
> returning a value (it might be possible to handle that with a return type
> parameter on JsFunction like JsFunction).
>
Yeah - the varargs is the problem.  I was thinking about maybe using eval,
but I can't really see how.

I concede that there's probably no way to do all this cleanly within the
context of GWT (at least not without ugly hacks that break Java syntax).

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

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

[gwt-contrib] Re: Feature idea - reference Java methods as Javascript functions

[Vitali Lovich]

On Fri, May 29, 2009 at 11:16 AM, John Tamplin  wrote:

> On Fri, May 29, 2009 at 10:42 AM, Vitali Lovich  wrote:
>
>> I was thinking more along the lines of JavascriptFunction foo =
>> MyClass.bar.method or something like that.  That way, you could do dynamic
>> function invocation without ever needing JSNI.  It's also a lot easier to
>> write that code, maintain it, & it's IDE friendly, meaning no typos & syntax
>> checking (which is a major strength of GWT).
>>
>
> That's not legal Java, so it would defeat your purpose of getting IDE
> support/etc.
>
I know.


> The way you get a method reference in pure Java is via reflection, which in
> general is not feasible though there have been some discussions of allowing
> it when everything can be evaluated at compile time (ie, all constants for
> classes and method/field names) -- even that seems to be a long way away
> however.
>
How about through GWT.create?  Then it uses reflection to supply the actual
function.  Might be limited to JSNI functions unless you can compile code
fragments.

>
>
> For JSNI syntax checking, you can use the Google Eclipse plugin which
> supports a number of JSNI features.
>
I haven't actually looked at the plugin yet.

>
>
>
>> You have to have a JSNI method to do this now:
>>>
>>> private static native JavaScriptObject callFunc(JavaScriptObject func,
>>> int arg) /*-{
>>>func(arg);
>>> }-*/;
>>
>> Yes - hence the feature request.  I know it's non-trivial given that GWT
>> follows Java convention & wraps varargs in an array which could cause
>> problems for the JS.  Just trying to get some feedback on whether or not
>> it's a good idea.
>>
>
> The only thing I think would be feasible here would be to add some sort of
> call method on JavaScriptObject that would treat it as a torn-off function.
>

Why not create a JsFunction class that extends from JavaScriptObject to
represent a JS lambda function.

However, since you can't have polymorphic dispatch on JSOs, that would
> reserve whatever name was chosen from all subclasses, so it would have to be
> something unlikely to collide.

I'm not sure what you mean here.  Why would you need to reserve a name?


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

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

[gwt-contrib] Re: Feature idea - reference Java methods as Javascript functions

[Vitali Lovich]

On Fri, May 29, 2009 at 9:42 AM, John Tamplin  wrote:

> On Thu, May 28, 2009 at 8:18 PM, Vitali Lovich  wrote:
>
>> It would be nice if there was a way to wrap Java methods with an opaque
>> Javascript function object so that you could pass them around in the native
>> code (obviously there are issues with compiler optimizations in this case).
>>
>
> You can do this now -- in a JSNI method:
>
>   static void bar(int arg) { ... }
>
>   var f = @org.example.Foo::bar(I);
>
I was thinking more along the lines of JavascriptFunction foo =
MyClass.bar.method or something like that.  That way, you could do dynamic
function invocation without ever needing JSNI.  It's also a lot easier to
write that code, maintain it, & it's IDE friendly, meaning no typos & syntax
checking (which is a major strength of GWT).


>
> You can then pass/return it to Java/JSNI code as a JavaScriptObject, or
> directly to external Javascript that looks for a function.
>
>
>> Ideally, you would be also able to execute any Javascript function object
>> from within Java code, although that does present some problems.
>>
>
> You have to have a JSNI method to do this now:
>
> private static native JavaScriptObject callFunc(JavaScriptObject func, int
> arg) /*-{
>func(arg);
> }-*/;

Yes - hence the feature request.  I know it's non-trivial given that GWT
follows Java convention & wraps varargs in an array which could cause
problems for the JS.  Just trying to get some feedback on whether or not
it's a good idea.

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

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

[gwt-contrib] Feature idea - reference Java methods as Javascript functions

[Vitali Lovich]

It would be nice if there was a way to wrap Java methods with an opaque
Javascript function object so that you could pass them around in the native
code (obviously there are issues with compiler optimizations in this case).
Ideally, you would be also able to execute any Javascript function object
from within Java code, although that does present some problems.

Thoughts?

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

[gwt-contrib] Feature idea - compile using AppEngine

[Vitali Lovich]

When deploying to Google App Engine, it would be nice if it was possible to
have Google compile my code for me using it's super-fast servers.  Obviously
there would be a limit of 1 compilation per day/week/month etc unless the
user pays or whatever the policy google implements.  This should help if I
want to support a lot of browsers/languages once I'm happy with it's hosted
mode behaviour.
Thoughts?

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

[gwt-contrib] Re: Comment on UsingOOPHM in google-web-toolkit

[Vitali Lovich]

Worked for me.  Did you use the XPI or XPCOM one?

On Sun, May 24, 2009 at 5:11 PM,  wrote:

>
> Comment by henr...@yahoo.fr:
>
> The provided firefox plugin doesn't work for me (Linux x86_64).
>
> I had to build a new firefox plugin from SVN.
>
>
> For more information:
> http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
>
> >
>

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

[gwt-contrib] Re: Add getElementsByClassName support

[Vitali Lovich]

On Tue, May 12, 2009 at 4:26 PM,  wrote:

> Thanks for digging into this -- it'll be helpful for a lot of
> developers.
> And sorry I've taken so long to get around to reviewing -- I've been
> pretty swamped lately.
>
> I'm going to ask Ray to come back and review some of the DOM details a
> bit more, but I'd like to address a couple of broader structural
> questions myself.
>
> - It's not entirely clear to me why DOMImplStandard.ElementsByClassName
> is its own inner class.

This was so that the overhead was as low as possible.
  1) Situation 1 - Program doesn't use getElementsByClassName.  This whole
code path will be stripped out by the compiler (not a reason for the inner
class, just my thought process when I was writing this).
  2) Situation 2 - Program does use getElementsByClassName.  2 ways to
implement.  a) initialize the prototypes ahead of time with the appropriate
implementation.  b) determine the appropriate function dynamically on every
invocation.

The inner class was the only way I could think of to satisfy 2a while
supporting 1 so that there's some minimal startup code to pick the right
implementation, but the invocation is as fast as can possibly be.

Optionally, I could have made the startup code common to everyone, but then
that just adds overhead for people who will never use this function.  Or I
could have done something like

if (e.getElementsByClassName) {
   return e.getElementsByClassName(class name);
}
Element.prototype.getElementsByClassName = function() { //whatever };
document.getElementsByClassName = function() { // whatever };


>  - I also don't think it should be adding methods to the "document"
> object.
>- It runs the risk of conflicting with other js libs, and there's
> almost always a better way to hang onto those values

Considering the native versions added getElementsByClassName to the document
object, I don't see a potential conflict.  All the libraries I looked at
were fixed a while back too because they clobbered the native version with
the emulated code.  This code also checks for
document.getElementsByClassName first.  That means if a user wants to use
the JS libraries version of it (I wouldn't know why since the GWT version
would be faster & smaller), he would just have to make sure that it gets
registered first (the implementation I wrote doesn't clobber the existing
getElementsByClassName).

>
>  (remember you can add static fields to the DOMImpl classes if you
> need to).

what is this in reference to?

>
>  - This class also appears to be doing runtime detection of
> (document.evaluate). I think we should be able to make this
>solely dependent upon the browser overload and ditch the runtime
> switch.

As Ray pointed out, FF2 breaks this for us.  Just to expand, so does every
standards compliant browser at some point (a while back I was asking about
supported browser versions for particularly this reason - all the versions
had, as far as I could tell, non-XPath, followed by XPath, followed by
native getElementsByClassName, hence the reason I made it standard.

>
>
> - It would be nice to have a brief doc (even if it's just on the contrib
> list), detailing which approaches work on which browsers.

Yes - I should have written this down to begin with.  I'll have to look it
up again.
>From what I can remember I believe it went like this:
*< IE8 => DOM
IE8 => XPath through querySelectorAll (implementation still needs to be
written)
< FF2 => DOM
< FF3 => XPath through document.evaluate
*>= FF3 => native
Safari 3 => XPath
*>= Safari 3.1 => native
Safari 2 => not clear about this - might be XPath, might be DOM.  Can't find
clear documentation on this & don't have a Mac.

Opera => todo.  They don't seem to have a good changelog (at least that I
can find) of when features like this were added.

But don't hold me to any of this - it's all from memory (except for those
marked *).

>
>
> - Don't forget IE8 support (I slipped it into trunk as a new user-agent
> value recently). They added support for querySelectorAll(), which is
> nice.

Yup.  Might pose a problem with quirks mode, but no probably no more so than
any of the other XPath methods.

>
>
> - This could really use some tests. There is a lot of complex behavior
> here, and it would be nice to have some confirmation that it works :)

Yes that would be nice.  I've been on vacation for a while - this is on my
todo list.

>
>  - If you need a hand running tests across browsers, send me patches
> and I'll be glad to do it here.

Sweet :D.  I think first we need to come up with a matrix of browsers
versions.  My list:
IE6, IE8 (IE7 optional - should be functionally equivalent to IE6)
Firefox 1.5, Firefox 2, Firefox 3
Safari 2, Safari 3, Safari 4 (Safari 3.1 is optional, but should be
functionally equivalent to 4)
Opera 8.5 (first free version & about the same age as FF 1.5), Opera 9.0,
Opera 9.5
Bonus: Chrome, Konqueror

Is that a reasonable approximation?  Too much?  Too little?  Wrong versions?

>
>
>

[gwt-contrib] Re: Add getElementsByClassName support

[Vitali Lovich]

On Tue, May 12, 2009 at 4:49 PM, Joel Webber  wrote:

> On Tue, May 12, 2009 at 4:38 PM, Ray Cromwell wrote:
>
>> On Tue, May 12, 2009 at 1:26 PM,   wrote:
>> >  - This class also appears to be doing runtime detection of
>> > (document.evaluate). I think we should be able to make this
>> >solely dependent upon the browser overload and ditch the runtime
>> > switch.
>>
>>   The problem is, firefox3 has this method, but firefox2 needs to use
>> document.evaluate, so you either have to add a deferred binding just
>> for this, or you do a runtime test and cache the result, something
>> like
>>
>> public native void initGetElementsByClassName() /*-{
>>   this.getElementsByClassName = nativeTest ?
>> th...@com.google.gwt.user.client.domimpl
>> ::getElementsByClassNameNative(Ljava/lang/String;)
>> : th...@com.google.gwt.user.client.domimpl
>> ::getElementsByClassNameXPath(Ljava/lang/String;);
>> }-*/;
>>
>
> I see. That makes sense. In this case, though, it would be nice to move
> that logic into the DOMImplMozilla so that it doesn't clutter up the
> standard case.
>
> > - Don't forget IE8 support (I slipped it into trunk as a new user-agent
>> > value recently). They added support for querySelectorAll(), which is
>> > nice.
>>
> I haven't looked at IE8 yet.  It's fine to use querySelectorAll to
implement getElementsByClassName as a faster way for IE8.  Eventually,
querySelectorAll needs to make it into the API by itself, although that will
require more effort probably since the Javascript emulation of that one is
probably far more complicated.

>
>>
>> Yes, you can use querySelectorAll for this, although short-circuiting
>> to getElementsByClassName() if it's native is faster on some browsers.
>>  Again, the IE6 vs IE8 issue will crop up requiring either another
>> deferred binding, or a runtime-test.
>
> querySelectorAll would only make sense with IE8 no?  I think it's the only
browser that didn't implement both at the same time (or in any case,
getElementsByClassName probably came first).

>
>>
>> There will be some overlap between this and the Gwt Query based
>> selector stuff too.
>>
>
> Good point. If you guys could coordinate to make sure there's at least a
> chance of GwtQuery using this interface (to the extent it needs
> getElementsByClassName() at all), that would be great.
>
> -Ray
>>
>
>

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

[gwt-contrib] Re: IE8 support

[Vitali Lovich]

Is this a management issue not wanting to promote Javascript, is this an
underlying issue with improving Trident, or something else?  Will MS ever
get their act together regarding the web?  You'd think after constantly
getting spanked in any web venture, they'd just get tired and, you know,
just build a decent product.

On Wed, Apr 29, 2009 at 1:32 PM, Joel Webber  wrote:

> You got that right. I went into the update process thinking the same thing
> you did, only to discover that it's just IE7 with a bit more makeup on it :P
>
>
> On Wed, Apr 29, 2009 at 1:27 PM, Vitali Lovich  wrote:
>
>> That's annoying.
>>
>>
>> On Wed, Apr 29, 2009 at 1:07 PM, Joel Webber  wrote:
>>
>>> Not even close, unfortunately. If you look at the wiki page I wrote up:
>>>   http://code.google.com/p/google-web-toolkit/wiki/IE8Support
>>>
>>> You'll see that the actual differences are pretty minimal. They fixed a
>>> number of CSS things, added DOM storage, Ajax history, and other things like
>>> that. But their event model is still wildly different. Most of the DOM
>>> element methods and properties are still weird and different, and so forth.
>>> I'm afraid Trident remains its own beast :(
>>>
>>>
>>> On Wed, Apr 29, 2009 at 1:02 PM, Vitali Lovich wrote:
>>>
>>>> Does IE8 still have non-standards compliant behaviour?  I thought they
>>>> were supposed to introduce pretty strict standards compliance with IE8 (in
>>>> fact, some/all? legacy non-standard stuff is unavailable).  Shouldn't IE8
>>>> extend DOMImplStandard or are there still remaining issues?
>>>>
>>>>
>>>> On Mon, Apr 27, 2009 at 11:22 AM,  wrote:
>>>>
>>>>>
>>>>> http://gwt-code-reviews.appspot.com/29803/diff/1/5
>>>>> File user/src/com/google/gwt/dom/DOM.gwt.xml (right):
>>>>>
>>>>> http://gwt-code-reviews.appspot.com/29803/diff/1/5#newcode56
>>>>> Line 56: 
>>>>> On 2009/04/24 20:34:56, jlabanca wrote:
>>>>> > too many spaces
>>>>>
>>>>> Done.
>>>>>
>>>>> http://gwt-code-reviews.appspot.com/29803/diff/1/12
>>>>> File user/src/com/google/gwt/user/Form.gwt.xml (right):
>>>>>
>>>>> http://gwt-code-reviews.appspot.com/29803/diff/1/12#newcode31
>>>>> Line 31: 
>>>>> On 2009/04/24 20:34:56, jlabanca wrote:
>>>>> > Spacing, and what are those two red arrows?  »»
>>>>> "visual tab indicators".
>>>>> Cleaned up tabs.
>>>>>
>>>>> http://gwt-code-reviews.appspot.com/29803/diff/1/7
>>>>> File user/src/com/google/gwt/user/RichText.gwt.xml (right):
>>>>>
>>>>> http://gwt-code-reviews.appspot.com/29803/diff/1/7#newcode27
>>>>> Line 27: 
>>>>> On 2009/04/24 20:34:56, jlabanca wrote:
>>>>> > Remove the »», which I assume are tabs.
>>>>>
>>>>> Done.
>>>>>
>>>>> http://gwt-code-reviews.appspot.com/29803/diff/1/8
>>>>> File user/src/com/google/gwt/user/TextBox.gwt.xml (right):
>>>>>
>>>>> http://gwt-code-reviews.appspot.com/29803/diff/1/8#newcode32
>>>>> Line 32: 
>>>>> On 2009/04/24 20:34:56, jlabanca wrote:
>>>>> > Remove »»
>>>>>
>>>>> Done.
>>>>>
>>>>> http://gwt-code-reviews.appspot.com/29803/diff/1/9
>>>>> File user/src/com/google/gwt/user/UserAgent.gwt.xml (right):
>>>>>
>>>>> http://gwt-code-reviews.appspot.com/29803/diff/1/9#newcode38
>>>>> Line 38: if (v >= 8000) {
>>>>> On 2009/04/24 23:44:41, t.broyer wrote:
>>>>> > I believe "ie8" here means "X-UA-Compatibility: IE=8", so detecting
>>>>> the version
>>>>> > from the navigator.userAgent is probably not enough [1], and
>>>>> > document.documentMode should be used instead [2], otherwise the "ie8"
>>>>> > implementation would have to do a
>>>>> > quirks-vs-standards-vs-super-standards-mode-detection, which would
>>>>> make the
>>>>> > "ie6" impl quite useless.
>>>>>
>>>>> > [1] Mike Ormond reports that a document can be displayed in IE=5 or
>>>>> IE=7 mode
>>>>> > while the UA is s

[gwt-contrib] Re: IE8 support

[Vitali Lovich]

That's annoying.

On Wed, Apr 29, 2009 at 1:07 PM, Joel Webber  wrote:

> Not even close, unfortunately. If you look at the wiki page I wrote up:
> http://code.google.com/p/google-web-toolkit/wiki/IE8Support
>
> You'll see that the actual differences are pretty minimal. They fixed a
> number of CSS things, added DOM storage, Ajax history, and other things like
> that. But their event model is still wildly different. Most of the DOM
> element methods and properties are still weird and different, and so forth.
> I'm afraid Trident remains its own beast :(
>
>
> On Wed, Apr 29, 2009 at 1:02 PM, Vitali Lovich  wrote:
>
>> Does IE8 still have non-standards compliant behaviour?  I thought they
>> were supposed to introduce pretty strict standards compliance with IE8 (in
>> fact, some/all? legacy non-standard stuff is unavailable).  Shouldn't IE8
>> extend DOMImplStandard or are there still remaining issues?
>>
>>
>> On Mon, Apr 27, 2009 at 11:22 AM,  wrote:
>>
>>>
>>> http://gwt-code-reviews.appspot.com/29803/diff/1/5
>>> File user/src/com/google/gwt/dom/DOM.gwt.xml (right):
>>>
>>> http://gwt-code-reviews.appspot.com/29803/diff/1/5#newcode56
>>> Line 56: 
>>> On 2009/04/24 20:34:56, jlabanca wrote:
>>> > too many spaces
>>>
>>> Done.
>>>
>>> http://gwt-code-reviews.appspot.com/29803/diff/1/12
>>> File user/src/com/google/gwt/user/Form.gwt.xml (right):
>>>
>>> http://gwt-code-reviews.appspot.com/29803/diff/1/12#newcode31
>>> Line 31: 
>>> On 2009/04/24 20:34:56, jlabanca wrote:
>>> > Spacing, and what are those two red arrows?  »»
>>> "visual tab indicators".
>>> Cleaned up tabs.
>>>
>>> http://gwt-code-reviews.appspot.com/29803/diff/1/7
>>> File user/src/com/google/gwt/user/RichText.gwt.xml (right):
>>>
>>> http://gwt-code-reviews.appspot.com/29803/diff/1/7#newcode27
>>> Line 27: 
>>> On 2009/04/24 20:34:56, jlabanca wrote:
>>> > Remove the »», which I assume are tabs.
>>>
>>> Done.
>>>
>>> http://gwt-code-reviews.appspot.com/29803/diff/1/8
>>> File user/src/com/google/gwt/user/TextBox.gwt.xml (right):
>>>
>>> http://gwt-code-reviews.appspot.com/29803/diff/1/8#newcode32
>>> Line 32: 
>>> On 2009/04/24 20:34:56, jlabanca wrote:
>>> > Remove »»
>>>
>>> Done.
>>>
>>> http://gwt-code-reviews.appspot.com/29803/diff/1/9
>>> File user/src/com/google/gwt/user/UserAgent.gwt.xml (right):
>>>
>>> http://gwt-code-reviews.appspot.com/29803/diff/1/9#newcode38
>>> Line 38: if (v >= 8000) {
>>> On 2009/04/24 23:44:41, t.broyer wrote:
>>> > I believe "ie8" here means "X-UA-Compatibility: IE=8", so detecting
>>> the version
>>> > from the navigator.userAgent is probably not enough [1], and
>>> > document.documentMode should be used instead [2], otherwise the "ie8"
>>> > implementation would have to do a
>>> > quirks-vs-standards-vs-super-standards-mode-detection, which would
>>> make the
>>> > "ie6" impl quite useless.
>>>
>>> > [1] Mike Ormond reports that a document can be displayed in IE=5 or
>>> IE=7 mode
>>> > while the UA is still reported as MSIE 8.0
>>>
>>>
>>> http://blogs.msdn.com/mikeormond/archive/2008/09/25/ie-8-compatibility-meta-tags-http-headers-user-agent-strings-etc-etc.aspx
>>>
>>> > [2]
>>> http://msdn.microsoft.com/en-us/library/cc288325(VS.85).aspx#GetMode<http://msdn.microsoft.com/en-us/library/cc288325%28VS.85%29.aspx#GetMode>
>>>
>>> Thanks for pointing out that blog in particular. Amazing that they
>>> managed to turn quirks/standards into a 12-entry matrix :P
>>>
>>> The good news is that In "compatibility view", IE always reports its UA
>>> as MSIE 7.0, which triggers the "ie6" user-agent property.
>>>
>>> When no X-UA-Compatible header is set, we're in "normal mode" (i.e., not
>>> "compatibility view"), and no DOCTYPE is set, we end up in quirks-mode,
>>> which appears to turn off some IE8 features (I've noticed that at least
>>> IE8 history breaks, though everything else I've tried seems to work fine
>>> and all of our tests pass). The only solution I'm aware of is to either
>>> set a DOCTYPE or the X-UA-Compatible header (both of which will put you
>>> in standards-mode). I realize there are still some GWT panels that
>>> layout a bit oddly in standards-mode, and while we're working on solving
>>> this, it's going to be a problem for some apps for a while yet.
>>>
>>> I'll document this on the IE8 support wiki page for now. Before long, it
>>> will be the "right thing" to always set a DOCTYPE, which should make
>>> this problem go away.
>>>
>>> http://gwt-code-reviews.appspot.com/29803/diff/1/6
>>> File user/src/com/google/gwt/xml/XML.gwt.xml (right):
>>>
>>> http://gwt-code-reviews.appspot.com/29803/diff/1/6#newcode39
>>> Line 39: 
>>> On 2009/04/24 20:34:56, jlabanca wrote:
>>> > tabs again »»
>>>
>>> Done.
>>>
>>> http://gwt-code-reviews.appspot.com/29803
>>>
>>>
>>>
>>
>>
>>
>
> >
>

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

[gwt-contrib] Re: IE8 support

[Vitali Lovich]

Does IE8 still have non-standards compliant behaviour?  I thought they were
supposed to introduce pretty strict standards compliance with IE8 (in fact,
some/all? legacy non-standard stuff is unavailable).  Shouldn't IE8 extend
DOMImplStandard or are there still remaining issues?

On Mon, Apr 27, 2009 at 11:22 AM,  wrote:

>
> http://gwt-code-reviews.appspot.com/29803/diff/1/5
> File user/src/com/google/gwt/dom/DOM.gwt.xml (right):
>
> http://gwt-code-reviews.appspot.com/29803/diff/1/5#newcode56
> Line 56: 
> On 2009/04/24 20:34:56, jlabanca wrote:
> > too many spaces
>
> Done.
>
> http://gwt-code-reviews.appspot.com/29803/diff/1/12
> File user/src/com/google/gwt/user/Form.gwt.xml (right):
>
> http://gwt-code-reviews.appspot.com/29803/diff/1/12#newcode31
> Line 31: 
> On 2009/04/24 20:34:56, jlabanca wrote:
> > Spacing, and what are those two red arrows?  »»
> "visual tab indicators".
> Cleaned up tabs.
>
> http://gwt-code-reviews.appspot.com/29803/diff/1/7
> File user/src/com/google/gwt/user/RichText.gwt.xml (right):
>
> http://gwt-code-reviews.appspot.com/29803/diff/1/7#newcode27
> Line 27: 
> On 2009/04/24 20:34:56, jlabanca wrote:
> > Remove the »», which I assume are tabs.
>
> Done.
>
> http://gwt-code-reviews.appspot.com/29803/diff/1/8
> File user/src/com/google/gwt/user/TextBox.gwt.xml (right):
>
> http://gwt-code-reviews.appspot.com/29803/diff/1/8#newcode32
> Line 32: 
> On 2009/04/24 20:34:56, jlabanca wrote:
> > Remove »»
>
> Done.
>
> http://gwt-code-reviews.appspot.com/29803/diff/1/9
> File user/src/com/google/gwt/user/UserAgent.gwt.xml (right):
>
> http://gwt-code-reviews.appspot.com/29803/diff/1/9#newcode38
> Line 38: if (v >= 8000) {
> On 2009/04/24 23:44:41, t.broyer wrote:
> > I believe "ie8" here means "X-UA-Compatibility: IE=8", so detecting
> the version
> > from the navigator.userAgent is probably not enough [1], and
> > document.documentMode should be used instead [2], otherwise the "ie8"
> > implementation would have to do a
> > quirks-vs-standards-vs-super-standards-mode-detection, which would
> make the
> > "ie6" impl quite useless.
>
> > [1] Mike Ormond reports that a document can be displayed in IE=5 or
> IE=7 mode
> > while the UA is still reported as MSIE 8.0
>
>
> http://blogs.msdn.com/mikeormond/archive/2008/09/25/ie-8-compatibility-meta-tags-http-headers-user-agent-strings-etc-etc.aspx
>
> > [2]
> http://msdn.microsoft.com/en-us/library/cc288325(VS.85).aspx#GetMode
>
> Thanks for pointing out that blog in particular. Amazing that they
> managed to turn quirks/standards into a 12-entry matrix :P
>
> The good news is that In "compatibility view", IE always reports its UA
> as MSIE 7.0, which triggers the "ie6" user-agent property.
>
> When no X-UA-Compatible header is set, we're in "normal mode" (i.e., not
> "compatibility view"), and no DOCTYPE is set, we end up in quirks-mode,
> which appears to turn off some IE8 features (I've noticed that at least
> IE8 history breaks, though everything else I've tried seems to work fine
> and all of our tests pass). The only solution I'm aware of is to either
> set a DOCTYPE or the X-UA-Compatible header (both of which will put you
> in standards-mode). I realize there are still some GWT panels that
> layout a bit oddly in standards-mode, and while we're working on solving
> this, it's going to be a problem for some apps for a while yet.
>
> I'll document this on the IE8 support wiki page for now. Before long, it
> will be the "right thing" to always set a DOCTYPE, which should make
> this problem go away.
>
> http://gwt-code-reviews.appspot.com/29803/diff/1/6
> File user/src/com/google/gwt/xml/XML.gwt.xml (right):
>
> http://gwt-code-reviews.appspot.com/29803/diff/1/6#newcode39
> Line 39: 
> On 2009/04/24 20:34:56, jlabanca wrote:
> > tabs again »»
>
> Done.
>
> http://gwt-code-reviews.appspot.com/29803
>
> >
>

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

[gwt-contrib] Re: New shopping new life!

[Vitali Lovich]

Wow that takes me back.  I've stopped using my hotmail actively for already
about 2-3 years.  I have my thunderbird on my desktop occassionally download
& filter through all the spam for archival purposes.  It just annoys me how
locked down it is.  With gmail (not a plug, just the best web-based email
I've used so far) you get free POP & IMAP access & there are no restrictions
with forwarding (i.e. if you switch somewhere else).

Hotmail was amazing back in the day - MS has just managed to strangle every
single web-based strategy they had.

On Mon, Apr 27, 2009 at 8:42 AM, Ed  wrote:

>
> He Joel,
>
> Sorry for the trouble.
>
> Last night I came home and all of sudden my whole hotmail was changed
> and got all kind of failed mail deliveries :(...
> Yep, changed my password already.
>
> -- Ed
> >
>

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

[gwt-contrib] Re: Feature idea

[Vitali Lovich]

Yeah, probably from a compiler's perspective, the value check may be more
complicated (the value may only be available after the AST stage depending
on when optimization is done)

It can possibly bloat the resultant code (since I believe you may have to
build different implementations of each function and you may get overhead,
even if you inline).  However, I think this might be an OK tradeoff since
the assumption would be that you are optimizing for speed as opposed to size
if you use something like GWT.isLiteral.

On Mon, Apr 27, 2009 at 3:45 AM, Ray Cromwell  wrote:

>
> +1
>
> I suggested a similar feature a few days ago privately, I called it
> GWT.isLiteral(), since the underlying check is if its an AST literal
> in the compiler, although in my example, you can't do value
> comparisons, just assertions on the literal. The value checks would be
> done via traditional operators.
>
>
>
>
> On Mon, Apr 27, 2009 at 12:33 AM, Vitali Lovich  wrote:
> > Kinda like with GCC, allow detection of constant values (i.e.
> > __builtin_constant_p).  This way, you could do something like
> >
> > void addParameter (HashMap h, int size, String key, Object value)
> > {
> >if (GWT.isConstantValue(h, null)) {
> >   if (GWT.isConstantValue(size, 0))
> >  size = 10;
> >   h = new HashMap(size);
> >}
> >h.put(key, value).
> > }
> >
> > & you could have the performance of
> >
> > void addParameter (HashMap h?, int size?, String key, Object value)
> >
> > as if you wrote overloaded methods without needing to write several
> > different methods that just supply default values back & forth.
> Sometimes,
> > it's also possible to use a better algorithm if parameters have a known
> > constant value.
> >
> > >
> >
>
> >
>

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

[gwt-contrib] Feature idea

[Vitali Lovich]

Kinda like with GCC, allow detection of constant values (i.e.
__builtin_constant_p).
This way, you could do something like

void addParameter (HashMap h, int size, String key, Object value)
{
   if (GWT.isConstantValue(h, null)) {
  if (GWT.isConstantValue(size, 0))
 size = 10;
  h = new HashMap(size);
   }
   h.put(key, value).
}

& you could have the performance of

void addParameter (HashMap h?, int size?, String key, Object value)

as if you wrote overloaded methods without needing to write several
different methods that just supply default values back & forth.  Sometimes,
it's also possible to use a better algorithm if parameters have a known
constant value.

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

[gwt-contrib] Re: IE8 support

[Vitali Lovich]

Is FF3.5 on the plan as well?  Safari 4?  Opera 10?  Chrome?  Are there
guidelines on when a browser version gets its own axis (i.e. HTML5 support)
or is it just when it feels appropriate or there are significant changes?

Shouldn't then we refactor the other browsers as well to be named after the
layout engines (i.e. DOMImplGecko with DOMImplMozilla or DOMImplFirefox as
specific subclasses, or DOMImplWebkit with DOMImplSafari and/or
DOMImplChrome).

Also, I'm still trying to find a good list of supported browser versions for
browsers other than IE.  Is FF really supported all the way back to FF 0.9?
Probably not since I was told that MozillaImplOld is should disappear with
2.0, meaning presumably gecko 1.8 & earlier browsers will become
unsupported.  What about Safari & Opera.

On a side note, the number of permutations is especially important as a
developer-facing issue because time & time again on the mailing list it
comes up with people complaining about the compile time because that's how
they think they should be developing (instead of using hosted mode for
development or limiting to a specific configuration to fix a
browser-specific problem).

Adding more documentation doesn't seem to help because that doesn't seem to
be read thoroughly - this seems to be more from the jump in with both feet &
hack till it works crowd (not that there's anything wrong with that approach
:D).

Maybe have the compiler print a warning with a reference to the
documentation indicating it's not a good workflow to compile for development
if the last successfully compiled code was like in the last 5 hours.

On Thu, Apr 23, 2009 at 4:31 PM,  wrote:

>
> Reviewers: jlabanca,
>
> Description:
> This monster of a patch adds what I believe to be full support for IE8.
>
> Review strategy to make your life easier:
> - All the .gwt.xml files, with the exception of DOM and History just add
> ie8 to the existing ie6 cases.
> - The giant diff around both DOMImpl's stems from the fact that in both
> cases I renamed DOMImplIE6 to DOMImplTrident (Trident is IE's rendering
> engine), and created IE6 and IE8 subclasses. The IE8 subclasses are
> currently empty, and I pushed down a few IE6/7-only method
> implementations into the DOMImplIE6's.
> - I would save the HistoryImpl changes for last. IE8 implements the
> HTML5 standard "onhashchange" event, which is going to be the proper way
> forward on new browsers, so I refactored the implementation such that
> HistoryImpl uses that.
>   - I also ditched the no-longer-supported Safari 2 history
> implementation and collapsed the HistoryImplFrame/Safari/IE6 into a
> single HistoryImplIE6.
>   - I added a new HistoryImplTimer which uses a timer to simulate the
> "onhashchange" event (this isn't actually a change, just a slight
> refactoring -- the Mozilla and Safari implementations have always worked
> this way).
>
> Also see this document for some more detail:
>   http://code.google.com/p/google-web-toolkit/wiki/IE8Support
>
> Please review this at http://gwt-code-reviews.appspot.com/29803
>
> Affected files:
>   user/src/com/google/gwt/dom/DOM.gwt.xml
>   user/src/com/google/gwt/dom/client/DOMImplIE6.java
>   user/src/com/google/gwt/dom/client/DOMImplIE8.java
>   user/src/com/google/gwt/dom/client/DOMImplTrident.java
>   user/src/com/google/gwt/user/ClippedImage.gwt.xml
>   user/src/com/google/gwt/user/DOM.gwt.xml
>   user/src/com/google/gwt/user/Focus.gwt.xml
>   user/src/com/google/gwt/user/Form.gwt.xml
>   user/src/com/google/gwt/user/History.gwt.xml
>   user/src/com/google/gwt/user/Hyperlink.gwt.xml
>   user/src/com/google/gwt/user/Popup.gwt.xml
>   user/src/com/google/gwt/user/RichText.gwt.xml
>   user/src/com/google/gwt/user/SplitPanel.gwt.xml
>   user/src/com/google/gwt/user/TextBox.gwt.xml
>   user/src/com/google/gwt/user/Tree.gwt.xml
>   user/src/com/google/gwt/user/UserAgent.gwt.xml
>   user/src/com/google/gwt/user/Window.gwt.xml
>   user/src/com/google/gwt/user/client/impl/DOMImplIE6.java
>   user/src/com/google/gwt/user/client/impl/DOMImplIE8.java
>   user/src/com/google/gwt/user/client/impl/DOMImplTrident.java
>   user/src/com/google/gwt/user/client/impl/HistoryImpl.java
>   user/src/com/google/gwt/user/client/impl/HistoryImplFrame.java
>   user/src/com/google/gwt/user/client/impl/HistoryImplIE6.java
>   user/src/com/google/gwt/user/client/impl/HistoryImplMozilla.java
>   user/src/com/google/gwt/user/client/impl/HistoryImplSafari.java
>   user/src/com/google/gwt/user/client/impl/HistoryImplStandard.java
>   user/src/com/google/gwt/user/client/impl/HistoryImplTimer.java
>   user/src/com/google/gwt/xml/XML.gwt.xml
>   user/super/com/google/gwt/emul/EmulationWithUserAgent.gwt.xml
>
>
>
> >
>

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

[gwt-contrib] Re: Comment on UsingOOPHM in google-web-toolkit

[Vitali Lovich]

There's a link on the website to download the xpi off the web.  It does not
come with GWT  trunk (it's in a branch).  The gwt-dev-oophm.jar is built
when you build trunk.

On Thu, Apr 23, 2009 at 10:15 PM, John Tamplin  wrote:

> On Thu, Apr 23, 2009 at 9:45 PM, Freeland Abbott wrote:
>
>> On that topic, I've been quietly lobbying to move the svn/tools directory
>> into svn/trunk/..., although there's already a "tools" directory (which adds
>> to the confusion; it's different), so it would have to be named something
>> else.
>> I think it'd be a lot simpler for this sort of confusion... but the
>> downside is that every workspace you make would get its own, redundant copy
>> of some fairly large stuff.  Disk is cheap, maybe, but you also need to
>> download it all at least to start; there is a downside.u
>>
>> Thoughts?
>>
>
> It isn't small and is only getting larger.  I currently have 8 separate
> checkouts on this machine, so having to have 8 separate copies of tools
> seems excessive.
>
> I think it is fine the way it is.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
>
> >
>

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

[gwt-contrib] Re: Patch to add getElementsByClassName support

[Vitali Lovich]

I mentioned already I've uploaded http://codereview.appspot.com/44041/show

On Mon, Apr 20, 2009 at 3:45 PM, Joel Webber  wrote:

> I'll go ahead and start looking at it, but would you mind seeing if you can
> upload it to gwt-code-reviews.appspot.com? Makes it a bit easier to keep
> track of all gwt-related patches.
> Thanks,
> joel.
>
>
> On Mon, Apr 20, 2009 at 1:11 PM, Vitali Lovich  wrote:
>
>> Ok - got it to upload now.
>>
>> http://codereview.appspot.com/44041/show
>>
>>
>> On Mon, Apr 20, 2009 at 12:19 PM, Vitali Lovich wrote:
>>
>>> Oh & I missed the open issue.  Please mark 3582 a duplicate.
>>>
>>>
>>> On Mon, Apr 20, 2009 at 12:18 PM, Vitali Lovich wrote:
>>>
>>>> gwt-code-reviews
>>>>
>>>>
>>>> On Mon, Apr 20, 2009 at 12:04 PM, Ray Ryan  wrote:
>>>>
>>>>> Joel, you created an issue for this last month:
>>>>> http://code.google.com/p/google-web-toolkit/issues/detail?id=3441
>>>>>
>>>>> Vitali, was the 500 you mentioned from the issue tracker or from
>>>>> gwt-code-reviews?
>>>>>
>>>>> rjrjr
>>>>>
>>>>>
>>>>> On Mon, Apr 20, 2009 at 8:36 AM, Vitali Lovich wrote:
>>>>>
>>>>>> I signed the CLA.  Should be OK for now since I haven't started my job
>>>>>> yet.
>>>>>>
>>>>>> I'm getting a HTTP SERVER 500 error creating the issue.  I've tried
>>>>>> both upload.py & the web interface.
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 20, 2009 at 10:58 AM, Joel Webber  wrote:
>>>>>>
>>>>>>> Vitali,
>>>>>>> Thanks for taking this on. I've been meaning to do it for ages, but
>>>>>>> haven't had time. I haven't had a chance to look over the patch in 
>>>>>>> detail
>>>>>>> yet, but the general approach sounds good.
>>>>>>>
>>>>>>> To answer your earlier question about DOMImplMozilla[Old], the "old"
>>>>>>> one (not the best name, I know) maps to the user-agent "gecko", which 
>>>>>>> is the
>>>>>>> fallback for pre-gecko-1.8. Gecko 1.8 is basically Firefox 1.5 and 2.0, 
>>>>>>> and
>>>>>>> is also used to support later versions (e.g., Firefox 3 is Gecko 1.9). 
>>>>>>> Older
>>>>>>> versions of Gecko don't exist in any browser you're likely to encounter 
>>>>>>> in
>>>>>>> the wild, but is used by the hosted-mode browser on Linux. As soon as we
>>>>>>> move to out-of-process hosted mode (GWT 2.0 in all likelihood), we'll be
>>>>>>> able to ditch support for old Geckos (yay!).
>>>>>>>
>>>>>>> A couple of procedural things:
>>>>>>> - Have you had a chance to sign a CLA yet? It's just a minor
>>>>>>> procedural thing, but necessary.
>>>>>>>   (http://code.google.com/webtoolkit/makinggwtbetter.html#committers
>>>>>>> )
>>>>>>> - Could I get you to create an issue to track this?
>>>>>>> - Also, if you could upload this patch to
>>>>>>> http://gwt-code-reviews.appspot.com/ it would make it easier for
>>>>>>> everyone to view and discuss.
>>>>>>>   (Make sure to add google-web-toolkit-contribut...@googlegroups.comto 
>>>>>>> the CC list)
>>>>>>>
>>>>>>> Thanks again,
>>>>>>> joel.
>>>>>>>
>>>>>>> On Sun, Apr 19, 2009 at 6:11 AM, Vitali Lovich wrote:
>>>>>>>
>>>>>>>> Oops - missed some compile errors in the JSNI code.  This is meant
>>>>>>>> to be applied over top of the previous patches.  I've verified that if
>>>>>>>> getElementsByClassName is not used then no code related to it appears 
>>>>>>>> in the
>>>>>>>> output (compiled the GWT samples & grepped for getElementsByClassName).
>>>>>>>>
>>>>>>>> I still need to test whether or not the implementations work & write
>>>>>>>> unit tests.
>>>>>

[gwt-contrib] Quirks mode by default?

[Vitali Lovich]

Is there a compelling reason that the default HTML generated by the GWT
project creator uses quirks mode instead of strict?

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

[gwt-contrib] Re: Patch to add getElementsByClassName support

[Vitali Lovich]

Ok - got it to upload now.

http://codereview.appspot.com/44041/show

On Mon, Apr 20, 2009 at 12:19 PM, Vitali Lovich  wrote:

> Oh & I missed the open issue.  Please mark 3582 a duplicate.
>
>
> On Mon, Apr 20, 2009 at 12:18 PM, Vitali Lovich  wrote:
>
>> gwt-code-reviews
>>
>>
>> On Mon, Apr 20, 2009 at 12:04 PM, Ray Ryan  wrote:
>>
>>> Joel, you created an issue for this last month:
>>> http://code.google.com/p/google-web-toolkit/issues/detail?id=3441
>>>
>>> Vitali, was the 500 you mentioned from the issue tracker or from
>>> gwt-code-reviews?
>>>
>>> rjrjr
>>>
>>>
>>> On Mon, Apr 20, 2009 at 8:36 AM, Vitali Lovich wrote:
>>>
>>>> I signed the CLA.  Should be OK for now since I haven't started my job
>>>> yet.
>>>>
>>>> I'm getting a HTTP SERVER 500 error creating the issue.  I've tried both
>>>> upload.py & the web interface.
>>>>
>>>>
>>>> On Mon, Apr 20, 2009 at 10:58 AM, Joel Webber  wrote:
>>>>
>>>>> Vitali,
>>>>> Thanks for taking this on. I've been meaning to do it for ages, but
>>>>> haven't had time. I haven't had a chance to look over the patch in detail
>>>>> yet, but the general approach sounds good.
>>>>>
>>>>> To answer your earlier question about DOMImplMozilla[Old], the "old"
>>>>> one (not the best name, I know) maps to the user-agent "gecko", which is 
>>>>> the
>>>>> fallback for pre-gecko-1.8. Gecko 1.8 is basically Firefox 1.5 and 2.0, 
>>>>> and
>>>>> is also used to support later versions (e.g., Firefox 3 is Gecko 1.9). 
>>>>> Older
>>>>> versions of Gecko don't exist in any browser you're likely to encounter in
>>>>> the wild, but is used by the hosted-mode browser on Linux. As soon as we
>>>>> move to out-of-process hosted mode (GWT 2.0 in all likelihood), we'll be
>>>>> able to ditch support for old Geckos (yay!).
>>>>>
>>>>> A couple of procedural things:
>>>>> - Have you had a chance to sign a CLA yet? It's just a minor procedural
>>>>> thing, but necessary.
>>>>>   (http://code.google.com/webtoolkit/makinggwtbetter.html#committers)
>>>>> - Could I get you to create an issue to track this?
>>>>> - Also, if you could upload this patch to
>>>>> http://gwt-code-reviews.appspot.com/ it would make it easier for
>>>>> everyone to view and discuss.
>>>>>   (Make sure to add google-web-toolkit-contribut...@googlegroups.comto 
>>>>> the CC list)
>>>>>
>>>>> Thanks again,
>>>>> joel.
>>>>>
>>>>> On Sun, Apr 19, 2009 at 6:11 AM, Vitali Lovich wrote:
>>>>>
>>>>>> Oops - missed some compile errors in the JSNI code.  This is meant to
>>>>>> be applied over top of the previous patches.  I've verified that if
>>>>>> getElementsByClassName is not used then no code related to it appears in 
>>>>>> the
>>>>>> output (compiled the GWT samples & grepped for getElementsByClassName).
>>>>>>
>>>>>> I still need to test whether or not the implementations work & write
>>>>>> unit tests.
>>>>>>
>>>>>> Just for easy reference for myself, [].slice.call(nodeList, 0); is
>>>>>> the code to convert a nodelist into an array.
>>>>>>
>>>>>>
>>>>>> On Sun, Apr 19, 2009 at 5:47 AM, Vitali Lovich wrote:
>>>>>>
>>>>>>> Here's my second attempt at the patch (2 of 2 is just a documentation
>>>>>>> adjustment).
>>>>>>>
>>>>>>> One caveat I forgot to mention is that there is slightly different
>>>>>>> cross-platform behaviour right now.  The native implementations return
>>>>>>> NodeLists which are live whereas the Javascript implementations simply
>>>>>>> return arrays.
>>>>>>>
>>>>>>> The question is should I change it so that a JsArray is always
>>>>>>> returned (i.e. copy the node list into an array) so that semantics are
>>>>>>> constant across browsers or leave as is for performance w

[gwt-contrib] Re: Patch to add getElementsByClassName support

[Vitali Lovich]

Oh & I missed the open issue.  Please mark 3582 a duplicate.

On Mon, Apr 20, 2009 at 12:18 PM, Vitali Lovich  wrote:

> gwt-code-reviews
>
>
> On Mon, Apr 20, 2009 at 12:04 PM, Ray Ryan  wrote:
>
>> Joel, you created an issue for this last month:
>> http://code.google.com/p/google-web-toolkit/issues/detail?id=3441
>>
>> Vitali, was the 500 you mentioned from the issue tracker or from
>> gwt-code-reviews?
>>
>> rjrjr
>>
>>
>> On Mon, Apr 20, 2009 at 8:36 AM, Vitali Lovich  wrote:
>>
>>> I signed the CLA.  Should be OK for now since I haven't started my job
>>> yet.
>>>
>>> I'm getting a HTTP SERVER 500 error creating the issue.  I've tried both
>>> upload.py & the web interface.
>>>
>>>
>>> On Mon, Apr 20, 2009 at 10:58 AM, Joel Webber  wrote:
>>>
>>>> Vitali,
>>>> Thanks for taking this on. I've been meaning to do it for ages, but
>>>> haven't had time. I haven't had a chance to look over the patch in detail
>>>> yet, but the general approach sounds good.
>>>>
>>>> To answer your earlier question about DOMImplMozilla[Old], the "old" one
>>>> (not the best name, I know) maps to the user-agent "gecko", which is the
>>>> fallback for pre-gecko-1.8. Gecko 1.8 is basically Firefox 1.5 and 2.0, and
>>>> is also used to support later versions (e.g., Firefox 3 is Gecko 1.9). 
>>>> Older
>>>> versions of Gecko don't exist in any browser you're likely to encounter in
>>>> the wild, but is used by the hosted-mode browser on Linux. As soon as we
>>>> move to out-of-process hosted mode (GWT 2.0 in all likelihood), we'll be
>>>> able to ditch support for old Geckos (yay!).
>>>>
>>>> A couple of procedural things:
>>>> - Have you had a chance to sign a CLA yet? It's just a minor procedural
>>>> thing, but necessary.
>>>>   (http://code.google.com/webtoolkit/makinggwtbetter.html#committers)
>>>> - Could I get you to create an issue to track this?
>>>> - Also, if you could upload this patch to
>>>> http://gwt-code-reviews.appspot.com/ it would make it easier for
>>>> everyone to view and discuss.
>>>>   (Make sure to add google-web-toolkit-contributors@googlegroups.com to
>>>> the CC list)
>>>>
>>>> Thanks again,
>>>> joel.
>>>>
>>>> On Sun, Apr 19, 2009 at 6:11 AM, Vitali Lovich wrote:
>>>>
>>>>> Oops - missed some compile errors in the JSNI code.  This is meant to
>>>>> be applied over top of the previous patches.  I've verified that if
>>>>> getElementsByClassName is not used then no code related to it appears in 
>>>>> the
>>>>> output (compiled the GWT samples & grepped for getElementsByClassName).
>>>>>
>>>>> I still need to test whether or not the implementations work & write
>>>>> unit tests.
>>>>>
>>>>> Just for easy reference for myself, [].slice.call(nodeList, 0); is the
>>>>> code to convert a nodelist into an array.
>>>>>
>>>>>
>>>>> On Sun, Apr 19, 2009 at 5:47 AM, Vitali Lovich wrote:
>>>>>
>>>>>> Here's my second attempt at the patch (2 of 2 is just a documentation
>>>>>> adjustment).
>>>>>>
>>>>>> One caveat I forgot to mention is that there is slightly different
>>>>>> cross-platform behaviour right now.  The native implementations return
>>>>>> NodeLists which are live whereas the Javascript implementations simply
>>>>>> return arrays.
>>>>>>
>>>>>> The question is should I change it so that a JsArray is always
>>>>>> returned (i.e. copy the node list into an array) so that semantics are
>>>>>> constant across browsers or leave as is for performance with maybe a 
>>>>>> caveat
>>>>>> that the user should be careful when using with FF3, Safari 3.1 or Opera 
>>>>>> 9.5
>>>>>> & copy into an array if they need array semantics?
>>>>>>
>>>>>> Changes from first patch:
>>>>>> getElementsByClassName should now display the HTML5 behaviour in
>>>>>> quirks mode if the browser supports the native implementation or doe

[gwt-contrib] Re: Patch to add getElementsByClassName support

[Vitali Lovich]

gwt-code-reviews

On Mon, Apr 20, 2009 at 12:04 PM, Ray Ryan  wrote:

> Joel, you created an issue for this last month:
> http://code.google.com/p/google-web-toolkit/issues/detail?id=3441
>
> Vitali, was the 500 you mentioned from the issue tracker or from
> gwt-code-reviews?
>
> rjrjr
>
>
> On Mon, Apr 20, 2009 at 8:36 AM, Vitali Lovich  wrote:
>
>> I signed the CLA.  Should be OK for now since I haven't started my job
>> yet.
>>
>> I'm getting a HTTP SERVER 500 error creating the issue.  I've tried both
>> upload.py & the web interface.
>>
>>
>> On Mon, Apr 20, 2009 at 10:58 AM, Joel Webber  wrote:
>>
>>> Vitali,
>>> Thanks for taking this on. I've been meaning to do it for ages, but
>>> haven't had time. I haven't had a chance to look over the patch in detail
>>> yet, but the general approach sounds good.
>>>
>>> To answer your earlier question about DOMImplMozilla[Old], the "old" one
>>> (not the best name, I know) maps to the user-agent "gecko", which is the
>>> fallback for pre-gecko-1.8. Gecko 1.8 is basically Firefox 1.5 and 2.0, and
>>> is also used to support later versions (e.g., Firefox 3 is Gecko 1.9). Older
>>> versions of Gecko don't exist in any browser you're likely to encounter in
>>> the wild, but is used by the hosted-mode browser on Linux. As soon as we
>>> move to out-of-process hosted mode (GWT 2.0 in all likelihood), we'll be
>>> able to ditch support for old Geckos (yay!).
>>>
>>> A couple of procedural things:
>>> - Have you had a chance to sign a CLA yet? It's just a minor procedural
>>> thing, but necessary.
>>>   (http://code.google.com/webtoolkit/makinggwtbetter.html#committers)
>>> - Could I get you to create an issue to track this?
>>> - Also, if you could upload this patch to
>>> http://gwt-code-reviews.appspot.com/ it would make it easier for
>>> everyone to view and discuss.
>>>   (Make sure to add google-web-toolkit-contributors@googlegroups.com to
>>> the CC list)
>>>
>>> Thanks again,
>>> joel.
>>>
>>> On Sun, Apr 19, 2009 at 6:11 AM, Vitali Lovich wrote:
>>>
>>>> Oops - missed some compile errors in the JSNI code.  This is meant to be
>>>> applied over top of the previous patches.  I've verified that if
>>>> getElementsByClassName is not used then no code related to it appears in 
>>>> the
>>>> output (compiled the GWT samples & grepped for getElementsByClassName).
>>>>
>>>> I still need to test whether or not the implementations work & write
>>>> unit tests.
>>>>
>>>> Just for easy reference for myself, [].slice.call(nodeList, 0); is the
>>>> code to convert a nodelist into an array.
>>>>
>>>>
>>>> On Sun, Apr 19, 2009 at 5:47 AM, Vitali Lovich wrote:
>>>>
>>>>> Here's my second attempt at the patch (2 of 2 is just a documentation
>>>>> adjustment).
>>>>>
>>>>> One caveat I forgot to mention is that there is slightly different
>>>>> cross-platform behaviour right now.  The native implementations return
>>>>> NodeLists which are live whereas the Javascript implementations simply
>>>>> return arrays.
>>>>>
>>>>> The question is should I change it so that a JsArray is always returned
>>>>> (i.e. copy the node list into an array) so that semantics are constant
>>>>> across browsers or leave as is for performance with maybe a caveat that 
>>>>> the
>>>>> user should be careful when using with FF3, Safari 3.1 or Opera 9.5 & copy
>>>>> into an array if they need array semantics?
>>>>>
>>>>> Changes from first patch:
>>>>> getElementsByClassName should now display the HTML5 behaviour in quirks
>>>>> mode if the browser supports the native implementation or doesn't provide
>>>>> XPath (IE or really really old versions of FF, Safari & friends).  I'm not
>>>>> sure how to get case insensitive string matching with XPath (so quirks 
>>>>> mode
>>>>> won't work according to the HTML5 spec in FF2, Safari 3, Opera 9.4 or
>>>>> earlier).  Is it even possible to do, or should I just fall back to using
>>>>> the DOM implementation in quirks mode & make a note that performance could
>&

[gwt-contrib] Re: Patch to add getElementsByClassName support

[Vitali Lovich]

I signed the CLA.  Should be OK for now since I haven't started my job yet.

I'm getting a HTTP SERVER 500 error creating the issue.  I've tried both
upload.py & the web interface.

On Mon, Apr 20, 2009 at 10:58 AM, Joel Webber  wrote:

> Vitali,
> Thanks for taking this on. I've been meaning to do it for ages, but haven't
> had time. I haven't had a chance to look over the patch in detail yet, but
> the general approach sounds good.
>
> To answer your earlier question about DOMImplMozilla[Old], the "old" one
> (not the best name, I know) maps to the user-agent "gecko", which is the
> fallback for pre-gecko-1.8. Gecko 1.8 is basically Firefox 1.5 and 2.0, and
> is also used to support later versions (e.g., Firefox 3 is Gecko 1.9). Older
> versions of Gecko don't exist in any browser you're likely to encounter in
> the wild, but is used by the hosted-mode browser on Linux. As soon as we
> move to out-of-process hosted mode (GWT 2.0 in all likelihood), we'll be
> able to ditch support for old Geckos (yay!).
>
> A couple of procedural things:
> - Have you had a chance to sign a CLA yet? It's just a minor procedural
> thing, but necessary.
>   (http://code.google.com/webtoolkit/makinggwtbetter.html#committers)
> - Could I get you to create an issue to track this?
> - Also, if you could upload this patch to
> http://gwt-code-reviews.appspot.com/ it would make it easier for everyone
> to view and discuss.
>   (Make sure to add google-web-toolkit-contributors@googlegroups.com to
> the CC list)
>
> Thanks again,
> joel.
>
> On Sun, Apr 19, 2009 at 6:11 AM, Vitali Lovich  wrote:
>
>> Oops - missed some compile errors in the JSNI code.  This is meant to be
>> applied over top of the previous patches.  I've verified that if
>> getElementsByClassName is not used then no code related to it appears in the
>> output (compiled the GWT samples & grepped for getElementsByClassName).
>>
>> I still need to test whether or not the implementations work & write unit
>> tests.
>>
>> Just for easy reference for myself, [].slice.call(nodeList, 0); is the
>> code to convert a nodelist into an array.
>>
>>
>> On Sun, Apr 19, 2009 at 5:47 AM, Vitali Lovich  wrote:
>>
>>> Here's my second attempt at the patch (2 of 2 is just a documentation
>>> adjustment).
>>>
>>> One caveat I forgot to mention is that there is slightly different
>>> cross-platform behaviour right now.  The native implementations return
>>> NodeLists which are live whereas the Javascript implementations simply
>>> return arrays.
>>>
>>> The question is should I change it so that a JsArray is always returned
>>> (i.e. copy the node list into an array) so that semantics are constant
>>> across browsers or leave as is for performance with maybe a caveat that the
>>> user should be careful when using with FF3, Safari 3.1 or Opera 9.5 & copy
>>> into an array if they need array semantics?
>>>
>>> Changes from first patch:
>>> getElementsByClassName should now display the HTML5 behaviour in quirks
>>> mode if the browser supports the native implementation or doesn't provide
>>> XPath (IE or really really old versions of FF, Safari & friends).  I'm not
>>> sure how to get case insensitive string matching with XPath (so quirks mode
>>> won't work according to the HTML5 spec in FF2, Safari 3, Opera 9.4 or
>>> earlier).  Is it even possible to do, or should I just fall back to using
>>> the DOM implementation in quirks mode & make a note that performance could
>>> be improved drastically if quirks mode is turned off on browsers that
>>> support XPath?  Or just leave as is - it'll certainly have the same
>>> behaviour as all the other JS libraries out there.
>>>
>>> Only DOMImpl, DOMImplStandard, & DOMImplSafari now require code changes.
>>>
>>> DOMImpl: contains a native implementation using DOM.  By default this
>>> gets called.
>>> DOMImplStandard now defines getElementsByXPath.  The fastest approach is
>>> assigned* to getElementsByClassName in the Element prototype & document.
>>> overrides getElementsByClassName
>>> DOMImplSafari: getElementsByXPath calls the native one supplied by
>>> Safari.  I'm assuming that document._getElementsByXPath & document.evaluate
>>> came in with the same version of Safari (the one that implemented
>>> XPath).  If that's not the case, then I'll have to rework the code a bit.
>>>

[gwt-contrib] Re: Eclipse Plugin and OSX woes

[Vitali Lovich]

You asked on your blog how to quote spaces in bash.

"$@".  bash understands that & automatically does the right thing.

On Sun, Apr 19, 2009 at 11:50 PM, Matt Mastracci wrote:

>
> Jason,
>
> Thanks for the idea, it works well.  I blogged the full instructions
> below and included the final Python script I used to wrap the Java
> executable.  I've now managed to deploy an AppEngine project that uses
> a 1.6 JVM to run (and is compatible with 1.6-level-compiled JAR files)
> along with the supporting GWT code.
>
>
> http://grack.com/blog/2009/04/19/the-final-word-on-google-eclipse-plugin-osx-crashes/
>
>  8< 
> #!/usr/bin/env python
> import sys
> import os
>
> print sys.argv
> cmd = os.path.dirname(sys.argv[0]) + '/java_wrapped'
>
> args = ['',
> '-XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/
> DataTreeNode,forwardDeltaWith',
> '-XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/
> lookup/ParameterizedTypeBinding,',
> '-XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/
> lookup/ParameterizedMethodBinding,']
>
> args.extend(sys.argv[1:])
>
> print cmd
> print args
> print ""
>
> os.execv(cmd, args)
>  8< 
>
> On 17-Apr-09, at 12:41 PM, Jason Parekh wrote:
>
> >
> > Hey Matt,
> >
> > Unfortunately, it's not currently possible to specify arguments to the
> > JVM that runs the GWT compile.  We're aware of the demand for this
> > feature though, so expect it in a future release.
> >
> > As an absolute workaround, could you rename your java binary and
> > create a shell script in its place that launches the real java binary
> > with whichever args you want (prepended to the args given to the shell
> > script)?
> >
> > jason
> >
> > On Fri, Apr 17, 2009 at 2:34 PM, Matt Mastracci
> >  wrote:
> >>
> >> I'm running into the same JVM crash under Eclipse that I was running
> >> into from Ant a few weeks ago (
> http://grack.com/blog/2009/04/14/gwt-16-crashes-and-a-fix/
> >> ) while trying to deploy a test AppEngine+GWT project.  The output
> >> from the compiler is pretty much:
> >>
> >> Compiling module ...
> >> Invalid memory access of location  rip=01160767
> >>
> >> Any ideas where the Eclipse Plugin gets the JVM and the JVM arguments
> >> to run to GWT portion of the compile?  I tried adding the JIT
> >> overrides to the workspace JRE default JVM properties, but those
> >> don't
> >> seem to get picked up.
> >>
> >> -XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/
> >> DataTreeNode,forwardDeltaWith
> >> -XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/
> >> ParameterizedTypeBinding,
> >> -XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/
> >> ParameterizedMethodBinding,
> >>
> >> The only argument I can see in the process list is "-Xmx512m".
> >>
> >> Thoughts/ideas?
> >>
> >> Thanks,
> >> Matt.
> >>
> >>
> >>>
> >>
> >
> > >
>
>
> >
>

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

[gwt-contrib] Re: RPC HashSet & HashMap deserialization bug/limitation

[Vitali Lovich]

Verified that that test case does indeed work using regular Java
serialization.

Main.java
---
import java.io.*;

public class Main
{
   public static void main(String [] args) throws Exception
   {
   PipedOutputStream output = new PipedOutputStream();
   PipedInputStream input = new PipedInputStream(output);

   ObjectOutputStream objWriter = new ObjectOutputStream(output);
   ObjectInputStream objReader = new ObjectInputStream(input);

   objWriter.writeObject(Foo.getData());
   Foo result = (Foo) objReader.readObject();

   System.out.println(result);
   }
}


On Sun, Apr 19, 2009 at 11:04 AM, Paul Robinson  wrote:

> I've created an issue for this:
> http://code.google.com/p/google-web-toolkit/issues/detail?id=3577
>
> The issue includes a complete code example demonstrating the problem
> (written for GWT 1.6.4), together with a detailed explanation of what
> happens during deserialization to cause the effect.
>
>
> Paul
>
>
> >
>

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

[gwt-contrib] Re: Patch to add getElementsByClassName support

[Vitali Lovich]

Oops - missed some compile errors in the JSNI code.  This is meant to be
applied over top of the previous patches.  I've verified that if
getElementsByClassName is not used then no code related to it appears in the
output (compiled the GWT samples & grepped for getElementsByClassName).

I still need to test whether or not the implementations work & write unit
tests.

Just for easy reference for myself, [].slice.call(nodeList, 0); is the code
to convert a nodelist into an array.

On Sun, Apr 19, 2009 at 5:47 AM, Vitali Lovich  wrote:

> Here's my second attempt at the patch (2 of 2 is just a documentation
> adjustment).
>
> One caveat I forgot to mention is that there is slightly different
> cross-platform behaviour right now.  The native implementations return
> NodeLists which are live whereas the Javascript implementations simply
> return arrays.
>
> The question is should I change it so that a JsArray is always returned
> (i.e. copy the node list into an array) so that semantics are constant
> across browsers or leave as is for performance with maybe a caveat that the
> user should be careful when using with FF3, Safari 3.1 or Opera 9.5 & copy
> into an array if they need array semantics?
>
> Changes from first patch:
> getElementsByClassName should now display the HTML5 behaviour in quirks
> mode if the browser supports the native implementation or doesn't provide
> XPath (IE or really really old versions of FF, Safari & friends).  I'm not
> sure how to get case insensitive string matching with XPath (so quirks mode
> won't work according to the HTML5 spec in FF2, Safari 3, Opera 9.4 or
> earlier).  Is it even possible to do, or should I just fall back to using
> the DOM implementation in quirks mode & make a note that performance could
> be improved drastically if quirks mode is turned off on browsers that
> support XPath?  Or just leave as is - it'll certainly have the same
> behaviour as all the other JS libraries out there.
>
> Only DOMImpl, DOMImplStandard, & DOMImplSafari now require code changes.
>
> DOMImpl: contains a native implementation using DOM.  By default this gets
> called.
> DOMImplStandard now defines getElementsByXPath.  The fastest approach is
> assigned* to getElementsByClassName in the Element prototype & document.
> overrides getElementsByClassName
> DOMImplSafari: getElementsByXPath calls the native one supplied by
> Safari.  I'm assuming that document._getElementsByXPath & document.evaluate
> came in with the same version of Safari (the one that implemented
> XPath).  If that's not the case, then I'll have to rework the code a bit.
> Document: added isBackCompat().  Could use !isCSS1Compat() for now, but
> this ensures no code change required if other compat modes are added in the
> future ('cause !quirks is all we care about).
>
> *I'm assuming that the way I wrote it ensures that if the developer doesn't
> use getElementsByClassName, then there's 0-cost: the function is never
> registered because the GWT compiler will recognize the dead code.
>
> If it is used, then there's only the overhead of performing the
> implementation selection once on startup.
>
> Thank you,
> Vitali
>
>
> On 4/18/09, Vitali Lovich  wrote:
> > Also, what's the difference between DOMImplMozilla & DOMImplMozillaOld
> >  in terms of Firefox versions?
> >
> >  And what versions of each browser are supported?  Are all versions of
> >  Safari, FF, & Opera supported as much as possible?  Is there a minimum
> >  version for any of them?
> >
> >
> >  On Sat, Apr 18, 2009 at 4:05 AM, Vitali Lovich 
> wrote:
> >  > If I put the check in a static block, then the check is only done once
> >  > on startup, right?  Is this acceptable, or is it frowned upon because
> >  > it adds a slight penalty to the startup even if the developer never
> >  > uses the function.
> >  >
> >  > Something like,
> >  >
> >  > static {
> >  >  ensureGetElementsByClassNameRegistered();
> >  > }
> >  >
> >  > private static native void ensureGetElementsByClassNameRegistered() {
> >  >   if (!document.getElementsByClassName) {
> >  >  document.getElementsByClassName = function(element, class) {
> >  > // etc
> >  >  }
> >  >   }
> >  > }
> >  >
> >  > On Sat, Apr 18, 2009 at 3:54 AM, Ray Cromwell 
> wrote:
> >  >>
> >  >> You don't want to create a separate property just for native
> >  >> getElementsByClassName() as that would almost double the number of
> >  &g

[gwt-contrib] Re: Patch to add getElementsByClassName support

[Vitali Lovich]

Here's my second attempt at the patch (2 of 2 is just a documentation
adjustment).

One caveat I forgot to mention is that there is slightly different
cross-platform behaviour right now.  The native implementations return
NodeLists which are live whereas the Javascript implementations simply
return arrays.

The question is should I change it so that a JsArray is always returned
(i.e. copy the node list into an array) so that semantics are constant
across browsers or leave as is for performance with maybe a caveat that the
user should be careful when using with FF3, Safari 3.1 or Opera 9.5 & copy
into an array if they need array semantics?

Changes from first patch:
getElementsByClassName should now display the HTML5 behaviour in quirks mode
if the browser supports the native implementation or doesn't provide XPath
(IE or really really old versions of FF, Safari & friends).  I'm not sure
how to get case insensitive string matching with XPath (so quirks mode won't
work according to the HTML5 spec in FF2, Safari 3, Opera 9.4 or earlier).
Is it even possible to do, or should I just fall back to using the DOM
implementation in quirks mode & make a note that performance could be
improved drastically if quirks mode is turned off on browsers that support
XPath?  Or just leave as is - it'll certainly have the same behaviour as all
the other JS libraries out there.

Only DOMImpl, DOMImplStandard, & DOMImplSafari now require code changes.

DOMImpl: contains a native implementation using DOM.  By default this gets
called.
DOMImplStandard now defines getElementsByXPath.  The fastest approach is
assigned* to getElementsByClassName in the Element prototype & document.
overrides getElementsByClassName
DOMImplSafari: getElementsByXPath calls the native one supplied by
Safari.  I'm assuming that document._getElementsByXPath & document.evaluate
came in with the same version of Safari (the one that implemented
XPath).  If that's not the case, then I'll have to rework the code a bit.
Document: added isBackCompat().  Could use !isCSS1Compat() for now, but this
ensures no code change required if other compat modes are added in the
future ('cause !quirks is all we care about).

*I'm assuming that the way I wrote it ensures that if the developer doesn't
use getElementsByClassName, then there's 0-cost: the function is never
registered because the GWT compiler will recognize the dead code.

If it is used, then there's only the overhead of performing the
implementation selection once on startup.

Thank you,
Vitali

On 4/18/09, Vitali Lovich  wrote:
> Also, what's the difference between DOMImplMozilla & DOMImplMozillaOld
>  in terms of Firefox versions?
>
>  And what versions of each browser are supported?  Are all versions of
>  Safari, FF, & Opera supported as much as possible?  Is there a minimum
>  version for any of them?
>
>
>  On Sat, Apr 18, 2009 at 4:05 AM, Vitali Lovich  wrote:
>  > If I put the check in a static block, then the check is only done once
>  > on startup, right?  Is this acceptable, or is it frowned upon because
>  > it adds a slight penalty to the startup even if the developer never
>  > uses the function.
>  >
>  > Something like,
>  >
>  > static {
>  >  ensureGetElementsByClassNameRegistered();
>  > }
>  >
>  > private static native void ensureGetElementsByClassNameRegistered() {
>  >   if (!document.getElementsByClassName) {
>  >  document.getElementsByClassName = function(element, class) {
>  > // etc
>  >  }
>  >   }
>  > }
>  >
>  > On Sat, Apr 18, 2009 at 3:54 AM, Ray Cromwell 
wrote:
>  >>
>  >> You don't want to create a separate property just for native
>  >> getElementsByClassName() as that would almost double the number of
>  >> permutations (except IE where is it known not to exist)  What you
>  >> could provide is 3 implementations. IE gets raw DOM version,
>  >> Safari/Firefox/Opera get a version that checks
>  >> if(document.getElementsByClassName) exists, and if not, falls back to
>  >> document.evaluate.
>  >>
>  >> -Ray
>  >>
>  >>
>  >> On Fri, Apr 17, 2009 at 11:03 PM, Vitali Lovich 
wrote:
>  >>>
>  >>> Do you have any suggestions regarding how to do the proper deferred
>  >>> binding for the various versions?  Should I just put the typical JS
>  >>> check that regular libraries use? (i.e. if
>  >>> (!document.getElementsByClassName) { // provide fallback }.  I
thought
>  >>> the whole point of deferred binding was to get around that.
>  >>>
>  >>> What is the list of officially supported br

[gwt-contrib] Re: Patch to add getElementsByClassName support

[Vitali Lovich]

Also, what's the difference between DOMImplMozilla & DOMImplMozillaOld
in terms of Firefox versions?

And what versions of each browser are supported?  Are all versions of
Safari, FF, & Opera supported as much as possible?  Is there a minimum
version for any of them?

On Sat, Apr 18, 2009 at 4:05 AM, Vitali Lovich  wrote:
> If I put the check in a static block, then the check is only done once
> on startup, right?  Is this acceptable, or is it frowned upon because
> it adds a slight penalty to the startup even if the developer never
> uses the function.
>
> Something like,
>
> static {
>  ensureGetElementsByClassNameRegistered();
> }
>
> private static native void ensureGetElementsByClassNameRegistered() {
>   if (!document.getElementsByClassName) {
>      document.getElementsByClassName = function(element, class) {
>             // etc
>      }
>   }
> }
>
> On Sat, Apr 18, 2009 at 3:54 AM, Ray Cromwell  wrote:
>>
>> You don't want to create a separate property just for native
>> getElementsByClassName() as that would almost double the number of
>> permutations (except IE where is it known not to exist)  What you
>> could provide is 3 implementations. IE gets raw DOM version,
>> Safari/Firefox/Opera get a version that checks
>> if(document.getElementsByClassName) exists, and if not, falls back to
>> document.evaluate.
>>
>> -Ray
>>
>>
>> On Fri, Apr 17, 2009 at 11:03 PM, Vitali Lovich  wrote:
>>>
>>> Do you have any suggestions regarding how to do the proper deferred
>>> binding for the various versions?  Should I just put the typical JS
>>> check that regular libraries use? (i.e. if
>>> (!document.getElementsByClassName) { // provide fallback }.  I thought
>>> the whole point of deferred binding was to get around that.
>>>
>>> What is the list of officially supported browsers?  In particular the
>>> specific minimum version for each?
>>>
>>> I guess I'm going to have to install a virtual machine for this
>>> because Safari refuses to work in wine 1.0.19 - chrome is useable
>>> although no HTTPS sites.
>>>
>>> Is there a guide somewhere on writing & integrating the tests into
>>> GWT, or just look at existing ones in the source.
>>>
>>> On Sat, Apr 18, 2009 at 1:49 AM, Miroslav Pokorny
>>>  wrote:
>>>>
>>>> Provide some tests and make sure it works on all officially supported
>>>> browsers even if the implementation is suboptimal. There are many js
>>>> libs out there so it's not hard to find the best way to do it fir the
>>>> various browsers...
>>>>
>>>> On 18/04/2009, at 12:39 PM, Vitali Lovich  wrote:
>>>>
>>>>> Just my first attempt at adding some initial support for
>>>>> getElementsByClassName.  This is by no means tested or
>>>>>
>>>>> Newer browsers support getElementsByClassName.  This is my attempt
>>>>> at a patch.
>>>>>
>>>>> Caveats:
>>>>> There's a "bug" in that quirks mode doesn't behave properly (I don't
>>>>> know how to detect it in the deferred binding) for IE & Firefox2 &
>>>>> earlier.  According to the HTML5 spec, it's supposed to be case
>>>>> insensitive in quirks mode.  However, this "bug" behaves the exact
>>>>> same way as all the javascript wrappers do (since I based the XPath &
>>>>> RegExp code paths roughly around the implementations floating out
>>>>> there).
>>>>>
>>>>> I'm also not sure if I added the support correctly for Firefox.
>>>>> getElementsByClassName only came in with FF3 & requires the xpath
>>>>> workaround for FF2 & earlier (I believe I read xpath was introduced
>>>>> with FF 1.5).  I placed the xpath code in DOMImplMozillaOld for now
>>>>> (not sure whether or not gecko1_8 represents FF2).
>>>>>
>>>>> There's also no mention of the versions of Safari & Opera that are
>>>>> supported by GWT, so they're defaulting to using the native version
>>>>> (which will not work if they don't provide it).
>>>>>
>>>>> Safari in particular got it with version 3.1.  if earlier versions are
>>>>> supported, it's not too much work.  Simply grab the expression built
>>>>> in the FF xpath  & pass it to document._getElementsByXPath(qu

[gwt-contrib] Re: Patch to add getElementsByClassName support

[Vitali Lovich]

If I put the check in a static block, then the check is only done once
on startup, right?  Is this acceptable, or is it frowned upon because
it adds a slight penalty to the startup even if the developer never
uses the function.

Something like,

static {
  ensureGetElementsByClassNameRegistered();
}

private static native void ensureGetElementsByClassNameRegistered() {
   if (!document.getElementsByClassName) {
  document.getElementsByClassName = function(element, class) {
 // etc
  }
   }
}

On Sat, Apr 18, 2009 at 3:54 AM, Ray Cromwell  wrote:
>
> You don't want to create a separate property just for native
> getElementsByClassName() as that would almost double the number of
> permutations (except IE where is it known not to exist)  What you
> could provide is 3 implementations. IE gets raw DOM version,
> Safari/Firefox/Opera get a version that checks
> if(document.getElementsByClassName) exists, and if not, falls back to
> document.evaluate.
>
> -Ray
>
>
> On Fri, Apr 17, 2009 at 11:03 PM, Vitali Lovich  wrote:
>>
>> Do you have any suggestions regarding how to do the proper deferred
>> binding for the various versions?  Should I just put the typical JS
>> check that regular libraries use? (i.e. if
>> (!document.getElementsByClassName) { // provide fallback }.  I thought
>> the whole point of deferred binding was to get around that.
>>
>> What is the list of officially supported browsers?  In particular the
>> specific minimum version for each?
>>
>> I guess I'm going to have to install a virtual machine for this
>> because Safari refuses to work in wine 1.0.19 - chrome is useable
>> although no HTTPS sites.
>>
>> Is there a guide somewhere on writing & integrating the tests into
>> GWT, or just look at existing ones in the source.
>>
>> On Sat, Apr 18, 2009 at 1:49 AM, Miroslav Pokorny
>>  wrote:
>>>
>>> Provide some tests and make sure it works on all officially supported
>>> browsers even if the implementation is suboptimal. There are many js
>>> libs out there so it's not hard to find the best way to do it fir the
>>> various browsers...
>>>
>>> On 18/04/2009, at 12:39 PM, Vitali Lovich  wrote:
>>>
>>>> Just my first attempt at adding some initial support for
>>>> getElementsByClassName.  This is by no means tested or
>>>>
>>>> Newer browsers support getElementsByClassName.  This is my attempt
>>>> at a patch.
>>>>
>>>> Caveats:
>>>> There's a "bug" in that quirks mode doesn't behave properly (I don't
>>>> know how to detect it in the deferred binding) for IE & Firefox2 &
>>>> earlier.  According to the HTML5 spec, it's supposed to be case
>>>> insensitive in quirks mode.  However, this "bug" behaves the exact
>>>> same way as all the javascript wrappers do (since I based the XPath &
>>>> RegExp code paths roughly around the implementations floating out
>>>> there).
>>>>
>>>> I'm also not sure if I added the support correctly for Firefox.
>>>> getElementsByClassName only came in with FF3 & requires the xpath
>>>> workaround for FF2 & earlier (I believe I read xpath was introduced
>>>> with FF 1.5).  I placed the xpath code in DOMImplMozillaOld for now
>>>> (not sure whether or not gecko1_8 represents FF2).
>>>>
>>>> There's also no mention of the versions of Safari & Opera that are
>>>> supported by GWT, so they're defaulting to using the native version
>>>> (which will not work if they don't provide it).
>>>>
>>>> Safari in particular got it with version 3.1.  if earlier versions are
>>>> supported, it's not too much work.  Simply grab the expression built
>>>> in the FF xpath  & pass it to document._getElementsByXPath(query,
>>>> parent) for Safari versions that have xpath (not sure which those
>>>> are).  Not sure how to distinguish Safari pre3.1 & post3.1 in deferred
>>>> binding.
>>>>
>>>> Opera got it with 9.5.  Not sure when xPath support got into Opera
>>>> (should be a straightfoward copy of the mozilla code).  Not sure how
>>>> to distinguish the two in the deferred binding.
>>>>
>>>> Feedback would be appreciated.
>>>>
>>>> Should this go as an enhancement request in the issue tracker?
>>>>
>>>> >
>>>> diff --git a/user/src/com/googl

[gwt-contrib] Re: Patch to add getElementsByClassName support

[Vitali Lovich]

Do you have any suggestions regarding how to do the proper deferred
binding for the various versions?  Should I just put the typical JS
check that regular libraries use? (i.e. if
(!document.getElementsByClassName) { // provide fallback }.  I thought
the whole point of deferred binding was to get around that.

What is the list of officially supported browsers?  In particular the
specific minimum version for each?

I guess I'm going to have to install a virtual machine for this
because Safari refuses to work in wine 1.0.19 - chrome is useable
although no HTTPS sites.

Is there a guide somewhere on writing & integrating the tests into
GWT, or just look at existing ones in the source.

On Sat, Apr 18, 2009 at 1:49 AM, Miroslav Pokorny
 wrote:
>
> Provide some tests and make sure it works on all officially supported
> browsers even if the implementation is suboptimal. There are many js
> libs out there so it's not hard to find the best way to do it fir the
> various browsers...
>
> On 18/04/2009, at 12:39 PM, Vitali Lovich  wrote:
>
>> Just my first attempt at adding some initial support for
>> getElementsByClassName.  This is by no means tested or
>>
>> Newer browsers support getElementsByClassName.  This is my attempt
>> at a patch.
>>
>> Caveats:
>> There's a "bug" in that quirks mode doesn't behave properly (I don't
>> know how to detect it in the deferred binding) for IE & Firefox2 &
>> earlier.  According to the HTML5 spec, it's supposed to be case
>> insensitive in quirks mode.  However, this "bug" behaves the exact
>> same way as all the javascript wrappers do (since I based the XPath &
>> RegExp code paths roughly around the implementations floating out
>> there).
>>
>> I'm also not sure if I added the support correctly for Firefox.
>> getElementsByClassName only came in with FF3 & requires the xpath
>> workaround for FF2 & earlier (I believe I read xpath was introduced
>> with FF 1.5).  I placed the xpath code in DOMImplMozillaOld for now
>> (not sure whether or not gecko1_8 represents FF2).
>>
>> There's also no mention of the versions of Safari & Opera that are
>> supported by GWT, so they're defaulting to using the native version
>> (which will not work if they don't provide it).
>>
>> Safari in particular got it with version 3.1.  if earlier versions are
>> supported, it's not too much work.  Simply grab the expression built
>> in the FF xpath  & pass it to document._getElementsByXPath(query,
>> parent) for Safari versions that have xpath (not sure which those
>> are).  Not sure how to distinguish Safari pre3.1 & post3.1 in deferred
>> binding.
>>
>> Opera got it with 9.5.  Not sure when xPath support got into Opera
>> (should be a straightfoward copy of the mozilla code).  Not sure how
>> to distinguish the two in the deferred binding.
>>
>> Feedback would be appreciated.
>>
>> Should this go as an enhancement request in the issue tracker?
>>
>> >
>> diff --git a/user/src/com/google/gwt/dom/client/DOMImpl.java b/user/
>> src/com/google/gwt/dom/client/DOMImpl.java index 1d7e39b..581764b
>> 100644 --- a/user/src/com/google/gwt/dom/client/DOMImpl.java +++ b/
>> user/src/com/google/gwt/dom/client/DOMImpl.java @@ -176,6 +176,8 @@
>> abstract class DOMImpl { return 0; }-*/; + public abstract NodeList
>> getElementsByClassName(Element parent, String className); + public
>> native Element getFirstChildElement(Element elem) /*-{ var child =
>> elem.firstChild; while (child && child.nodeType != 1) diff --git a/
>> user/src/com/google/gwt/dom/client/DOMImplIE6.java b/user/src/com/
>> google/gwt/dom/client/DOMImplIE6.java index 04c205a..8c24a6c 100644
>> --- a/user/src/com/google/gwt/dom/client/DOMImplIE6.java +++ b/user/
>> src/com/google/gwt/dom/client/DOMImplIE6.java @@ -15,6 +15,8 @@ */
>> package com.google.gwt.dom.client; +import
>> com.google.gwt.core.client.JsArray; +  /** * Internet Explorer 6
>> implementation of * {...@link com.google.gwt.user.client.impl.DOMImpl}.
>> @@ -184,6 +186,31 @@ class DOMImplIE6 extends DOMImpl { } @Override
>> + public NodeList getElementsByClassName(Element parent, String
>> className) { + // TODO: detect quirks mode so that the regexps do a
>> case insensitive match as per the + // spec. when quirks mode
>> detected, pass "i" as the flags parameter + return
>> getElementsByClassName(parent, className.split(" "), "").cast(); + }
>> + +  private native JsArray getElementsByClassName(Element parent,
>> String [] cl

[gwt-contrib] Patch to add getElementsByClassName support

[Vitali Lovich]

Just my first attempt at adding some initial support for
getElementsByClassName.  This is by no means tested or

Newer browsers support getElementsByClassName.  This is my attempt at a patch.

Caveats:
There's a "bug" in that quirks mode doesn't behave properly (I don't
know how to detect it in the deferred binding) for IE & Firefox2 &
earlier.  According to the HTML5 spec, it's supposed to be case
insensitive in quirks mode.  However, this "bug" behaves the exact
same way as all the javascript wrappers do (since I based the XPath &
RegExp code paths roughly around the implementations floating out
there).

I'm also not sure if I added the support correctly for Firefox.
getElementsByClassName only came in with FF3 & requires the xpath
workaround for FF2 & earlier (I believe I read xpath was introduced
with FF 1.5).  I placed the xpath code in DOMImplMozillaOld for now
(not sure whether or not gecko1_8 represents FF2).

There's also no mention of the versions of Safari & Opera that are
supported by GWT, so they're defaulting to using the native version
(which will not work if they don't provide it).

Safari in particular got it with version 3.1.  if earlier versions are
supported, it's not too much work.  Simply grab the expression built
in the FF xpath  & pass it to document._getElementsByXPath(query,
parent) for Safari versions that have xpath (not sure which those
are).  Not sure how to distinguish Safari pre3.1 & post3.1 in deferred
binding.

Opera got it with 9.5.  Not sure when xPath support got into Opera
(should be a straightfoward copy of the mozilla code).  Not sure how
to distinguish the two in the deferred binding.

Feedback would be appreciated.

Should this go as an enhancement request in the issue tracker?

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

diff --git a/user/src/com/google/gwt/dom/client/DOMImpl.java b/user/src/com/google/gwt/dom/client/DOMImpl.java
index 1d7e39b..581764b 100644
--- a/user/src/com/google/gwt/dom/client/DOMImpl.java
+++ b/user/src/com/google/gwt/dom/client/DOMImpl.java
@@ -176,6 +176,8 @@ abstract class DOMImpl {
 return 0;
   }-*/;
 
+  public abstract NodeList getElementsByClassName(Element parent, String className);
+
   public native Element getFirstChildElement(Element elem) /*-{
 var child = elem.firstChild;
 while (child && child.nodeType != 1)
diff --git a/user/src/com/google/gwt/dom/client/DOMImplIE6.java b/user/src/com/google/gwt/dom/client/DOMImplIE6.java
index 04c205a..8c24a6c 100644
--- a/user/src/com/google/gwt/dom/client/DOMImplIE6.java
+++ b/user/src/com/google/gwt/dom/client/DOMImplIE6.java
@@ -15,6 +15,8 @@
  */
 package com.google.gwt.dom.client;
 
+import com.google.gwt.core.client.JsArray;
+
 /**
  * Internet Explorer 6 implementation of
  * {...@link com.google.gwt.user.client.impl.DOMImpl}.
@@ -184,6 +186,31 @@ class DOMImplIE6 extends DOMImpl {
   }
 
   @Override
+  public NodeList getElementsByClassName(Element parent, String className) {
+// TODO: detect quirks mode so that the regexps do a case insensitive match as per the
+// spec. when quirks mode detected, pass "i" as the flags parameter
+return getElementsByClassName(parent, className.split(" "), "").cast();
+  }
+
+  private native JsArray getElementsByClassName(Element parent, String [] classes, String flags) /*-{
+var i, j, e, c, elements = parent.all || parent.getElementsByTagName("*");
+var regexps = [], result = [];
+for (i = classes.length - 1; i >= 0; i--) {
+  c = classes[i].replace(/^\s+|\s+$/g, "");
+  if (c.length)
+regexps.push(new RegExp(new Array("(?:^|\\s)", c, "(?:\\s|$)").join(""), flags);
+}
+if (regexps.length) {
+  for (i = 0, c = elements.length; i < c; i++) {
+e = elements[i];
+for (j = regexps.length - 1; j >= 0 && regexps[j].test(e); j--) {}
+j == -1 && result.push(e);
+  }
+}
+return result;
+  }-*/;
+
+  @Override
   public native String getInnerText(Element elem) /*-{
 return elem.innerText;
   }-*/;
diff --git a/user/src/com/google/gwt/dom/client/DOMImplMozillaOld.java b/user/src/com/google/gwt/dom/client/DOMImplMozillaOld.java
index ecf52fb..5fd7312 100644
--- a/user/src/com/google/gwt/dom/client/DOMImplMozillaOld.java
+++ b/user/src/com/google/gwt/dom/client/DOMImplMozillaOld.java
@@ -15,6 +15,8 @@
  */
 package com.google.gwt.dom.client;
 
+import com.google.gwt.core.client.JsArray;
+
 /**
  * DOM implementation differences for older version of Mozilla (mostly the
  * hosted mode browser on linux). The main difference is due to changes in
@@ -114,4 +116,23 @@ package com.google.gwt.dom.client;
 
 return top + viewport.scrollTop;
   }-*/;
+
+  @Override
+  public NodeList getElementsByClassName(Element parent, String className) {
+// the cast should be safe since both it & JsArray access the underlying object the same wa

[gwt-contrib] Re: Add getElementsByTagName to DOM class patch

[Vitali Lovich]

Yes I did (since the DOM one just wraps the Document one).  It seems
like the DOM methods wrap the Document ones, so it was just surprising
it wasn't there.

On Fri, Apr 17, 2009 at 7:58 PM, Ray Cromwell  wrote:
>
> Did you look at the Document/Element classes? It's there. I think of
> the DOM classes  as semi-deprecated, in that many of the methods are
> now subsumed by overlay types.
>
> -Ray
>
>
> On Fri, Apr 17, 2009 at 4:54 PM, Vitali Lovich  wrote:
>> getElementsByTagName missing from DOM class.
>>
>> >
>>
>
> >
>

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

[gwt-contrib] Add getElementsByTagName to DOM class patch

[Vitali Lovich]

getElementsByTagName missing from DOM class.

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

diff --git a/user/src/com/google/gwt/user/client/DOM.java b/user/src/com/google/gwt/user/client/DOM.java
index 03721b8..ddbac26 100644
--- a/user/src/com/google/gwt/user/client/DOM.java
+++ b/user/src/com/google/gwt/user/client/DOM.java
@@ -751,6 +751,17 @@ public class DOM {
   }
 
   /**
+   * Gets all the elements with the given tag name within the entire
+   * document.
+   * 
+   * @param tagName the HTML tag name whose associated elements are to be retrieved
+   * @return the associated elements, or null if none is found
+   */
+  public static NodeList getElementsByTagName(String tagName) {
+return Document.get().getElementsByTagName(tagName).cast();
+  }
+
+  /**
* Gets any named property from an element, as a string.
* 
* @param elem the element whose property is to be retrieved

[gwt-contrib] Re: Comments on builder pattern?

[Vitali Lovich]

Oh, I didn't realize there was a compiler bug regarding this.  Is this an
issue regarding returning this from native?

Builder setFoo(String s)
{
setFooImpl(s); // native function that does the actual code
return this;
}

fix the issue?  More code but the inlining compiler should produce the same
optimized code here except correct (although annoying having to maintain
both interfaces to workaround the bug).

Alternatively, in the newInstance, if you initialize all the variables in
your class to undefined, then it'll fix this issue (although you're object
may be bigger than necessary), no?

On Thu, Apr 16, 2009 at 2:55 PM, Ray Cromwell  wrote:

>
> Well, for one thing, there appears to be a bug in the compiler.
> Consider the following:
>
> public void onModuleLoad() {
>Window.alert(Builder.newInstance().setFoo("Hello").setBar("World")
>.setBaz("!").toString());
>  }
>
>  static final class Builder extends JavaScriptObject {
>
>protected Builder() {
>}
>
>public static Builder newInstance() {
>  return createObject().cast();
>}
>
>public native Builder setFoo(String x) /*-{
>  this.foo = x;
>  return this;
>}-*/;
>
>public native Builder setBar(String x) /*-{
>  this.bar = x;
>  return this;
>}-*/;
>
>public native Builder setBaz(String x) /*-{
>  this.baz = x;
>  return this;
>}-*/;
>  }
>
> The output from this is:
>
>  $wnd.alert($toString($setBaz($setBar(({}.foo = 'Hello' , {}), 'World'),
> '!')));
>
> The multi-expression that is inlined in place of setFoo() does not
> yield the right 'this' value.
>
> You can workaround this bug by preventing the JsInliner from inlining,
> you can do this in several ways, one way is to violate evaluation
> order, e.g.
>
>  public native Builder setFoo(String x) /*-{
>   return x=this.foo=x, this;
>}-*/;
>
> This forces 'x' to be evaluated before 'this$static' which is the real
> first parameter of this method, so inlining is derailed.  The
> generated code then looks like this:
>
>  $wnd.alert($toString($setBaz($setBar($setFoo({}, 'Hello'), 'World'),
> '!')));
>
> function $setFoo(this$static, x){
>  return x = this$static.foo = x , this$static;
> }
>
> In an ideal world, we'd have something like this generated as JS:
>
> DraggableObjectOptions.newInstance().setLeft(10).setTop(5)
>
> becomes
>
> {left: 10, top: 5}
>
> One way to accomplish this to have your builder use 'eval' and String
> concat, e.g.
>
> static final class Builder extends JavaScriptObject {
>protected Builder() {}
>public static native Builder newInstance() /*-{
>  return "{";
>}-*/;
>
>public native Builder setFoo(int x) /*-{
>  return this + "foo:"+x+", ";
>}-*/;
>
>public native Builder setBar(int x) /*-{
>  return this + "bar: "+x+", ";
>}-*/;
>
> public native Builder setBaz(int x) /*-{
>  return this + "baz: "+x+", ";
>}-*/;
>
>public native Builder end() /*-{
>  return eval(this + "}");
>}-*/;
>  }
>
> (hosted mode version not shown)
>
>  With proper static simplification in JS, something like
> setFoo(10).setBar(20).setBaz(30) is compiled to:
>
> eval("{foo:10,bar:20,baz:30}")
>
> Of course, eval is yucky to use.
>
> -Ray
> On Thu, Apr 16, 2009 at 11:03 AM, Eric Ayers  wrote:
> > Recently I've been wrapping some of my JavaScriptObjects using the
> builder
> > pattern where an instance of the object you are setting is in the return
> > value.
> >
> >   http://galgwt-reviews.appspot.com/21604/diff/1/18?context=10
> >
> > Which you would invoke as:
> >
> >
> >   DraggableObject obj = new DraggableObject(elem,
> > DraggableObjectOptions.newInstance().setLeft(10).setTop(5));
> >
> > Can anyone think of a reason I might be shooting myself in the foot
> > performance wise or code size wise as opposed to making these strict
> setter
> > methods?  I don't want to set a bad example.
> >
> > -Eric.
> > --
> > Eric Z. Ayers - GWT Team - Atlanta, GA USA
> > http://code.google.com/webtoolkit/
> >
> > >
> >
>
> >
>

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

[gwt-contrib] Re: Comments on builder pattern?

[Vitali Lovich]

No I don't think so.  There might be some additional overhead of returning a
value instead of void, but I"m pretty sure that would be extremely
negligible to the point of never becoming an issue, regardless how hard you
try (the function invocation itself should dominate that by orders of
magnitude).

On Thu, Apr 16, 2009 at 2:03 PM, Eric Ayers  wrote:

> Recently I've been wrapping some of my JavaScriptObjects using the builder
> pattern where an instance of the object you are setting is in the return
> value.
>
>   http://galgwt-reviews.appspot.com/21604/diff/1/18?context=10
>
> Which you would invoke as:
>
>
>   DraggableObject obj = new DraggableObject(elem,
> DraggableObjectOptions.newInstance().setLeft(10).setTop(5));
>
> Can anyone think of a reason I might be shooting myself in the foot
> performance wise or code size wise as opposed to making these strict setter
> methods?  I don't want to set a bad example.
>
> -Eric.
> --
> Eric Z. Ayers - GWT Team - Atlanta, GA USA
> http://code.google.com/webtoolkit/
>
> >
>

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

[gwt-contrib] Re: RootPanel.get(string) not working any more (latest build from SVN)

[Vitali Lovich]

That's the general way to build GWT applications (attach all widgets to
RootPanel.get())

On Wed, Apr 15, 2009 at 4:43 AM, chee loong  wrote:

>
> On Wed, Apr 15, 2009 at 4:35 PM, Vitali Lovich  wrote:
>
>> Well that changes the layout doesn't it.  Depends what you want to do.  If
>> you just want to add styles using Javascript, then use the DOM class.  If
>> you actually want GWT widgets out of them, consider building the page using
>> GWT to begin with rather than trying to wrap existing HTML into GWT widgets.
>>
>>
>>
> Are you trying to said, instead of using few  to render the GWT
> widget, and consider using 1  element, and build the whole application
> wrapping with other gwt widget and loaded with that RootPanel ?
>
> >
>

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

[gwt-contrib] Re: RootPanel.get(string) not working any more (latest build from SVN)

[Vitali Lovich]

Well that changes the layout doesn't it.  Depends what you want to do.  If
you just want to add styles using Javascript, then use the DOM class.  If
you actually want GWT widgets out of them, consider building the page using
GWT to begin with rather than trying to wrap existing HTML into GWT widgets.

On Wed, Apr 15, 2009 at 4:31 AM, chee loong  wrote:

> Hi, thanks for reply,
>   For example this is the original layout, should it modified to become
> after change ?
>
>   Before
>   
> 
>  
> 
>  
> 
>  
>
>  After
>
>
>
>
>
>
>
>
>
>
> >
>

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

[gwt-contrib] Re: RootPanel.get(string) not working any more (latest build from SVN)

[Vitali Lovich]

I think the issue is broader from my understanding.  The way I interpret the
thread is that if you wrap any DOM element with a GWT widget, you cannot
wrap any child DOM elements with GWT widgets (you can have nested DOM
elements, but you can only wrap 1 of those elements with a GWT widget).

On a sidenote, couldn't the whole architecture be more light-weight by using
the existing DOM tree instead of creating a parallel widget tree that
contains the exact same structure?  Or are there technical reasons that it
was done this way?

On Wed, Apr 15, 2009 at 3:44 AM, loongest  wrote:

>
> Hi all,
>
>  I just move the project from 1.4 to 1.6. I'm facing the same
> problem as describe above. Does it mean that div tag must close and
> cannot contains other div tags ?
>
> >
>

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

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

[Vitali Lovich]

Should've mentioned this in the original post, but probably the
TokenStream.java<http://mxr.mozilla.org/mozilla/source/js/rhino/src/org/mozilla/javascript/TokenStream.java>class
is the scanner you would be interested in I believe.

On Tue, Apr 14, 2009 at 1:14 AM, Vitali Lovich  wrote:

> Hey guys,
>
> Rhino <http://www.mozilla.org/rhino/> (one of Mozilla's javascript
> engines) is written entirely in Java & supports JS 1.7 if that helps.  I'm
> sure there's a parser component in there that can be extracted if the
> license is compatible (MPL/GPL).
>
> There's also GromJS <http://www.bauk.ws/gromjs.html> (public domain I
> think).
>
> On the other hand these are probably overkill for your needs.
>
>
> On Tue, Apr 14, 2009 at 12:33 AM, Lex Spoon  wrote:
>
>>
>> On Mon, Apr 13, 2009 at 1:53 PM, John Tamplin  wrote:
>> > On Mon, Apr 13, 2009 at 3:51 PM, Scott Blum  wrote:
>> >>
>> >> If we were playing Mao, I would give you a card penalty for stating the
>> >> obvious. :-)
>> >>
>> >> But uh, reliably tracking whether or not you're in a string literal is
>> >> about as much fun as writing a JavaScript parser.  In fact, it might be
>> >> *exactly* as fun, if you know what I mean.
>> >
>> > String literals have to be known at parse time, so it seems to me all
>> you
>> > have to look for is start/stop quotes (of both sorts) while handling
>> > embedded ones of the wrong variety and escaped ones of the right
>> variety.
>> > That looks like it can be handled with a single character lookahead
>> scanner,
>> > and very little complexity -- what am I missing?
>>
>> It would be awesome if there were a simple lexer available for
>> JavaScript.  Given a token stream, brace counting would sound
>> feasible.
>>
>> However, from what I hear it's pretty complicated even to tokenize
>> JavaScript.  I don't know exactly what is so hard, but last time I
>> asked, regex literals came up.
>>
>> Lex
>>
>> >>
>>
>

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

[gwt-contrib] Re: RR : Chunk the JavaScript in the initial fragment

[Vitali Lovich]

Hey guys,

Rhino  (one of Mozilla's javascript engines)
is written entirely in Java & supports JS 1.7 if that helps.  I'm sure
there's a parser component in there that can be extracted if the license is
compatible (MPL/GPL).

There's also GromJS  (public domain I
think).

On the other hand these are probably overkill for your needs.

On Tue, Apr 14, 2009 at 12:33 AM, Lex Spoon  wrote:

>
> On Mon, Apr 13, 2009 at 1:53 PM, John Tamplin  wrote:
> > On Mon, Apr 13, 2009 at 3:51 PM, Scott Blum  wrote:
> >>
> >> If we were playing Mao, I would give you a card penalty for stating the
> >> obvious. :-)
> >>
> >> But uh, reliably tracking whether or not you're in a string literal is
> >> about as much fun as writing a JavaScript parser.  In fact, it might be
> >> *exactly* as fun, if you know what I mean.
> >
> > String literals have to be known at parse time, so it seems to me all you
> > have to look for is start/stop quotes (of both sorts) while handling
> > embedded ones of the wrong variety and escaped ones of the right variety.
> > That looks like it can be handled with a single character lookahead
> scanner,
> > and very little complexity -- what am I missing?
>
> It would be awesome if there were a simple lexer available for
> JavaScript.  Given a token stream, brace counting would sound
> feasible.
>
> However, from what I hear it's pretty complicated even to tokenize
> JavaScript.  I don't know exactly what is so hard, but last time I
> asked, regex literals came up.
>
> Lex
>
> >
>

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

[gwt-contrib] Re: TOT (rev 5208) broken?

[Vitali Lovich]

Thanks, that fixed it.

Shouldn't you be on vacation :D?

On Thu, Apr 9, 2009 at 9:44 PM, Scott Blum  wrote:

> Try an 'ant clean'
>
>
> On Thu, Apr 9, 2009 at 9:30 PM, Vitali Lovich  wrote:
>
>> I'd just like to confirm that ToT is indeed broken right now.  Same thing
>> happens when I try to run in hosted mode.
>>
>> Getting
>>  [java] Loading module ''
>>  [java][ERROR] Unexpected error while processing XML
>>  [java] java.lang.IncompatibleClassChangeError: Found interface
>> com.google.gwt.dev.jjs.SourceInfo, but class was expected
>>  [java] at
>> com.google.gwt.dev.js.ast.JsProgramFragment.(JsProgramFragment.java:28)
>>  [java] at
>> com.google.gwt.dev.js.ast.JsProgram.setFragmentCount(JsProgram.java:241)
>>  [java] at
>> com.google.gwt.dev.js.ast.JsProgram.(JsProgram.java:85)
>>  [java] at
>> com.google.gwt.dev.js.ast.JsProgram.(JsProgram.java:64)
>>  [java] at
>> com.google.gwt.dev.cfg.ModuleDefSchema.(ModuleDefSchema.java:964)
>>  [java] at
>> com.google.gwt.dev.cfg.ModuleDefLoader.nestedLoad(ModuleDefLoader.java:241)
>>  [java] at
>> com.google.gwt.dev.cfg.ModuleDefLoader$1.load(ModuleDefLoader.java:155)
>>  [java] at
>> com.google.gwt.dev.cfg.ModuleDefLoader.doLoadModule(ModuleDefLoader.java:272)
>>  [java] at
>> com.google.gwt.dev.cfg.ModuleDefLoader.loadFromClassPath(ModuleDefLoader.java:127)
>>  [java] at com.google.gwt.dev.Compiler.run(Compiler.java:176)
>>  [java] at com.google.gwt.dev.Compiler$1.run(Compiler.java:144)
>>  [java] at
>> com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:84)
>>  [java] at
>> com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:78)
>>  [java] at com.google.gwt.dev.Compiler.main(Compiler.java:151)
>>
>> Thanks
>>
>>
>>
>
> >
>

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

[gwt-contrib] TOT (rev 5208) broken?

[Vitali Lovich]

I'd just like to confirm that ToT is indeed broken right now.  Same thing
happens when I try to run in hosted mode.

Getting
 [java] Loading module ''
 [java][ERROR] Unexpected error while processing XML
 [java] java.lang.IncompatibleClassChangeError: Found interface
com.google.gwt.dev.jjs.SourceInfo, but class was expected
 [java] at
com.google.gwt.dev.js.ast.JsProgramFragment.(JsProgramFragment.java:28)
 [java] at
com.google.gwt.dev.js.ast.JsProgram.setFragmentCount(JsProgram.java:241)
 [java] at
com.google.gwt.dev.js.ast.JsProgram.(JsProgram.java:85)
 [java] at
com.google.gwt.dev.js.ast.JsProgram.(JsProgram.java:64)
 [java] at
com.google.gwt.dev.cfg.ModuleDefSchema.(ModuleDefSchema.java:964)
 [java] at
com.google.gwt.dev.cfg.ModuleDefLoader.nestedLoad(ModuleDefLoader.java:241)
 [java] at
com.google.gwt.dev.cfg.ModuleDefLoader$1.load(ModuleDefLoader.java:155)
 [java] at
com.google.gwt.dev.cfg.ModuleDefLoader.doLoadModule(ModuleDefLoader.java:272)
 [java] at
com.google.gwt.dev.cfg.ModuleDefLoader.loadFromClassPath(ModuleDefLoader.java:127)
 [java] at com.google.gwt.dev.Compiler.run(Compiler.java:176)
 [java] at com.google.gwt.dev.Compiler$1.run(Compiler.java:144)
 [java] at
com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:84)
 [java] at
com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:78)
 [java] at com.google.gwt.dev.Compiler.main(Compiler.java:151)

Thanks

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

[gwt-contrib] Re: new test which demonstrates the infinite recursion bug

[Vitali Lovich]

Right ... Stupid me.  I knew I was missing something obvious.

On Mon, Apr 6, 2009 at 8:08 PM, Ray Cromwell  wrote:

>
> callSuper() is private, so B's invocation is not polymorphic, and should
> not reference C's callSuper()
>
>
> On Mon, Apr 6, 2009 at 4:50 PM, Vitali Lovich  wrote:
>
>>
>>
>> On Mon, Apr 6, 2009 at 7:13 PM, John Tamplin  wrote:
>>
>>> The attached patch, relative to trunk r5191, adds a new tests which fails
>>> only in web mode and only for the JsniSuper case.  It appears the problem
>>> isn't directly related to super, but rather with making calls to private
>>> methods polymorphic rather than virtual dispatch.  This is the bug I ran
>>> into with the CurrencyListGenerator changes I committed and then had to roll
>>> back.
>>>
>>> Ie:
>>>
>>> public class A {
>>>   public void foo() {}
>>> }
>>>
>>> public class B extends A {
>>>   public void foo() { callSuper(); }
>>>   private void callSuper() { super.foo(); }
>>> }
>>>
>>> public class C extends B {
>>>   public void foo() { callSuper(); }
>>>   private void callSuper() { super.foo(); }
>>> }
>>>
>>> B's foo will always call B's callSuper, even when this is actually a C.
>>> We handle this properly for Java code, but not when foo is a JSNI
>>> method.
>>
>> Woudn't this cause infinite recursion when this is actually a C & using
>> virtual dispatch?
>>
>> c.foo -> c.callSuper -> b.foo -> c.callSuper -> b.foo -> c.callSuper etc.
>>
>> If it's a polymorphic call, I believe the call graph looks like:
>> c.foo -> c.callSuper -> b.foo -> b.callSuper -> a.foo
>>
>>>
>>>
>>> --
>>> John A. Tamplin
>>> Software Engineer (GWT), Google
>>>
>>>
>>>
>>
>>
>>
>
> >
>

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

[gwt-contrib] Re: new test which demonstrates the infinite recursion bug

[Vitali Lovich]

On Mon, Apr 6, 2009 at 7:13 PM, John Tamplin  wrote:

> The attached patch, relative to trunk r5191, adds a new tests which fails
> only in web mode and only for the JsniSuper case.  It appears the problem
> isn't directly related to super, but rather with making calls to private
> methods polymorphic rather than virtual dispatch.  This is the bug I ran
> into with the CurrencyListGenerator changes I committed and then had to roll
> back.
>
> Ie:
>
> public class A {
>   public void foo() {}
> }
>
> public class B extends A {
>   public void foo() { callSuper(); }
>   private void callSuper() { super.foo(); }
> }
>
> public class C extends B {
>   public void foo() { callSuper(); }
>   private void callSuper() { super.foo(); }
> }
>
> B's foo will always call B's callSuper, even when this is actually a C.
> We handle this properly for Java code, but not when foo is a JSNI method.

Woudn't this cause infinite recursion when this is actually a C & using
virtual dispatch?

c.foo -> c.callSuper -> b.foo -> c.callSuper -> b.foo -> c.callSuper etc.

If it's a polymorphic call, I believe the call graph looks like:
c.foo -> c.callSuper -> b.foo -> b.callSuper -> a.foo

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

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

[gwt-contrib] Feature request: Better compiler error message

[Vitali Lovich]

  [java]Scanning for additional dependencies:
file:/home/vlovich/workspace/sacred_heart/src/ece456/client/services/ResourceFactory.java
 [java]   Computing all possible rebind results for
'ece456.client.services.comm.rpc.StaffService'
 [java]  Rebinding
ece456.client.services.comm.rpc.StaffService
 [java] Invoking 
 [java]Generating client proxy for remote service
interface 'ece456.client.services.comm.rpc.StaffService'
 [java]   Analyzing
'ece456.client.services.comm.rpc.StaffService' for serializable types
 [java]  Analyzing methods:
 [java] public abstract void
addVisit(ece456.client.services.comm.types.DBPatientVisit visit)
throws ece456.client.services.comm.types.RPCError
 [java]Parameter:
ece456.client.services.comm.types.DBPatientVisit visit
 [java]
ece456.client.services.comm.types.DBPatientVisit
 [java]  [ERROR] Type
'ece456.client.services.comm.types.DBPatientVisit' was not
serializable and has no concrete serializable subtypes

Took me a good amount of time before I remembered I had missed the
default constructor.  At the very least it should print the
requirements for serializability - it would be nicer if it actually
told you the specific problem it found though.

Would that be possible?

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

[gwt-contrib] Re: JVM crashes when using GWT compiler under Java 6 update 7 JVM

[Vitali Lovich]

Interesting - didn't think of that, but I believe I had it set to -server
(not in the compilation of GWT, but when I ran the 32-bit hosted mode).

I'm so swamped right now I have no time to do anything but this one project
& then I have the first of my final exams Wednesday, so I dunno when I'll
get a chance to look at this.

On Thu, Apr 2, 2009 at 5:57 PM, Ray Cromwell  wrote:

>
> Another quick workaround is try to switch the jitter (from -client to
> -server). In JDK6 and below, these are in fact, separate compilers. I had
> similar crashes with Java6 on OSX at one point and switching the HotSpot
> compiler fixed them.
> -Ray
>
> On Thu, Apr 2, 2009 at 11:16 AM, Scott Blum  wrote:
>
>> This looks to me like a HotSpot problem.. the jitter is crashing trying to
>> compile some JDT code.
>> Current thread (0x08ab8800):  JavaThread "CompilerThread0" daemon
>> [_thread_in_native, id=2484, stack(0xe037f000,0xe040)]
>>
>> Current CompileTask:
>> C2:498
>>  
>> org.eclipse.jdt.internal.compiler.lookup.ParameterizedMethodBinding.(Lorg/eclipse/jdt/internal/compiler/lookup/ParameterizedTypeBinding;Lorg/eclipse/jdt/internal/compiler/lookup/MethodBinding;)V
>> (596 bytes)
>>
>> So here's how you could try to come up with a workaround / file an issue
>> against the JVM:
>>
>> - Grab our JDT 3.4.2 jar out of the GWT tools repository
>> - Open it up and find the source for ParameterizedMethodBinding
>> - Add this source file to your project (you'll need to put gwt-dev-windows
>> on your path if it's not)
>>
>> You should now be able to run a compile and repro the crash.  If you
>> *can't* repro the crash anymore, it's possible your compiler is producing a
>> slightly different .class file for that class than the class file we ship
>> (which was built by the JDT guys).
>>
>> Assuming you can repro the crash, start commenting out lines of code in
>> the offending constructor until it no longer crashes.  Or start refactoring
>> out pieces of the constructor into individual methods.  By playing around,
>> you can probably figure out what's killing it.
>>
>>
>> On Fri, Mar 27, 2009 at 2:26 PM, Vitali Lovich  wrote:
>>
>>> Ugggh... you want me to do all the work don't you :D
>>>
>>> On a separate note 5094 compilation is broken (JUnitShell fails to
>>> compile).  In 5096 the problem is resolved.
>>>
>>>
>>> On Fri, Mar 27, 2009 at 2:03 PM, Scott Blum  wrote:
>>>
>>>> I can has hs_err_pid17105.log?
>>>>
>>>>
>>>> On Fri, Mar 27, 2009 at 12:36 PM, Vitali Lovich wrote:
>>>>
>>>>>
>>>>> [java] Compiling module
>>>>> com.google.gwt.benchmarks.viewer.ReportViewer
>>>>>  [java]
>>>>> #
>>>>>  [java] # An unexpected error has been detected by Java Runtime
>>>>> Environment:
>>>>>  [java] #
>>>>>  [java] #  SIGSEGV (0xb) at pc=0x0625665c, pid=17105,
>>>>> tid=3762477968
>>>>>  [java] #
>>>>>  [java] # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode
>>>>> linux-x86)
>>>>>  [java] # Problematic frame:
>>>>>  [java] # V  [libjvm.so+0x25665c]
>>>>>  [java] #
>>>>>  [java] # An error report file with more information is saved as:
>>>>>  [java] #
>>>>> /home/vlovich/workspace/gwt/tools/benchmark-viewer/hs_err_pid17105.log
>>>>>  [java] #
>>>>>  [java] # If you would like to submit a bug report, please visit:
>>>>>  [java] #   http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>  [java] # The crash happened outside the Java Virtual Machine in
>>>>> native code.
>>>>>  [java] # See problematic frame for where to report the bug.
>>>>>  [java] #
>>>>>
>>>>> This is kind of annoying because GWT fails to build with the newer JDKs
>>>>> due to the issue mentioned before with the change to generics.  So it's a
>>>>> two step workaround:  Use the older sun JDK to compile the classes & after
>>>>> it crashes, use run ant again with the newer JDK so that the GWT compiler
>>>>> doesn't crash the VM.
>>>>>
>>>>> This also happens if I try to use the older JDK with my projects, but
>>>>> that's not really an issue since I just use the latest OpenJDK in the 
>>>>> Ubuntu
>>>>> repos.
>>>>>
>>>>> Might be relevant that I'm using 64-bit jdks.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>

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

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

[Vitali Lovich]

I think the issue is something to do with me using incubator & it
instantiating the RemoteLoggingService even though I don't use it.  It might
be due to the way incubator initializes the logger (using java's
Logger.getLogger() whereas I use log4j directly).

On Fri, Mar 27, 2009 at 11:57 AM, Scott Blum  wrote:

> Okay, I think the issue might be your using trunk then.  My patch jar was
> for 1.6, and the commit you're commenting on here (r5077 & r5078) were to
> 1.6.  So I would not expect that to be fixed in trunk.
>
>
> On Thu, Mar 26, 2009 at 9:50 PM, Vitali Lovich  wrote:
>
>>
>>
>> On Thu, Mar 26, 2009 at 3:17 PM, Scott Blum  wrote:
>>
>>> Vitali, are you positive all your stuff is in a legit state?  I ask
>>> because it looks like you're mixing trunk and 1.6 stuff together.
>>>
>>
>> Can you clarify what you mean? How can I be mixing trunk & 1.6 together?
>> I'm only using trunk.  At this point I don't event have the gwt-platform
>> directory in my project path - I just imported the GWT projects & made put
>> them on my classpath.
>>
>> When I use a stock gwt-dev-windows.jar from 1...@r5090,
>>>
>>  I'm using trunk (@ 5084 right now).  I haven't even tried stock because
>> I'm on linux 64-bit & I haven't bothered trying to get the 32-bit
>> environment set up for the old hosted mode (relying solely on OOPHM).
>>
>>
>>
>>> I can boot your project just fine whether log4j-1.2.15.jar is in
>>> WEB-INF/lib or not.  (I can run it because I couldn't actually find a
>>> version of mosaic that you compile against cleanly, but the servlets all
>>> initialized just fine.)
>>>
>>
>> Right - I forgot that the code I sent you at that point already had my
>> enhancements to mosaic (eventually a version of them should get into
>> truck).   In any case, you can just delete the code that throws up an error
>> (unless its the constructor).
>>
>> My  code runs fine (including servlets) & the logging works.  It's just
>> that error
>> that gets printed to the console when the project launches, so it's not a
>> super-important issue.  Is it possible it's a Linux-only issue?
>>
>>
>>>
>>> Here's a dump of the exact dir structure that's working for me:
>>>
>>> .classpath
>>>
>> .project
>>>
>> gwt-windows-0.0.0
>>> gwt-windows-0.0.0/gwt-dev-windows.jar
>>> gwt-windows-0.0.0/gwt-ll.dll
>>> gwt-windows-0.0.0/gwt-user.jar
>>> gwt-windows-0.0.0/swt-win32-3235.dll
>>> lib
>>> lib/ftr-gwt-library-date-0.9.9.jar
>>> lib/ftr-gwt-library-date-emul-0.9.9.jar
>>> lib/gwt-beans-binding-0.2.3.jar
>>> lib/gwt-dnd-2.5.6.jar
>>> lib/gwt-incubator-trunk-r1543.jar
>>> lib/gwt-mosaic-0.2.0-rc1.jar
>>> lib/gwtx-1.5.2.jar
>>> lib/log4j-1.2.15.jar
>>>  lib/org.cobogw.gwt-1.2.2.jar
>>> SacredHeart.launch
>>> src (omitted)
>>> war
>>> war/loading.gif
>>> war/SacredHeart.css
>>> war/SacredHeart.html
>>> war/WEB-INF
>>> war/WEB-INF/classes (omitted)
>>> war/WEB-INF/classes/ece456
>>> war/WEB-INF/classes/log4j.properties
>>> war/WEB-INF/lib
>>> war/WEB-INF/lib/gwt-servlet.jar
>>> war/WEB-INF/lib/log4j-1.2.15.jar
>>> war/WEB-INF/lib/mysql-connector-java-5.1.7-bin.jar
>>> war/WEB-INF/web.xml
>>>
>>>
>>> I attached the .project, .classpath, and launch config I'm using.  This
>>> configuration boots whether or not I have war/WEB-INF/lib/log4j-1.2.15.jar
>>> in there.
>>>
>>> On Wed, Mar 25, 2009 at 7:32 PM, Vitali Lovich wrote:
>>>
>>>>
>>>> On Wed, Mar 25, 2009 at 7:10 PM, Scott Blum  wrote:
>>>>
>>>>> On Wed, Mar 25, 2009 at 6:22 PM, Vitali Lovich wrote:
>>>>>
>>>>>> If I don't put the log4j file into my WEB-INF/lib directory, then it's
>>>>>> fine.  If it is put there, then it gets the conflicting version 
>>>>>> (regardless
>>>>>> of whether or not I launch HostedMode with log4j on the class path).  So 
>>>>>> am
>>>>>> I doing it wrong?
>>>>>>
>>>>>
>>>>> i'm confused... if you don't have log4j on the classpath, how can you
>>>>> be loading it via Launcher$AppClassLoader?  It must be hiding out in some
>>>>> other jar you have on the classpath?
>>>>>
>>>> Sorry for the confusion.  Here's what I meant:
>>>> If I add the log4j library in the WEB-INF/lib to the classpath of the
>>>> runtime configuration, I get the problem above.
>>>> If I move the log4j library out of the WEB-INF/lib directory to
>>>> somewhere else like project/lib & add it to the classpath, then it works.
>>>>
>>>>>
>>>>> Am I supposed to place it elsewhere & then copy it over to WEB-INF/lib
>>>>>> when I'm packaging it up only?
>>>>>>
>>>>>
>>>>> That's not the intent... can you send me a small sample that repros
>>>>> this?
>>>>>
>>>> I don't have time right now.  If you want I can e-mail you my project
>>>> privately.  It's a school project, so there's no confidentiality to it or
>>>> anything.  I just don't want to spam the mailing list.
>>>>
>>>> Thanks
>>>>
>>>>>
>>>>> Scott
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>

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

[gwt-contrib] Feature request: RPC automagically transferred values

[Vitali Lovich]

Hi,

I've encountered this pattern a few times, and think it would be great if
the RPC layer could be given a serializable object that is always
transferred on every RPC call.

In the GWT security documentation it says not to use cookies but instead
pass the session id manually on every RPC call, which is a real hassle to
maintain & results in a lot of boilerplate.  Instead it would be nice if the
GWT layer could do it automatically for me, and then RemoteServiceServlet
would provide it through a call like getSessionData() (templated for
convenience) which would de-serialize the object & return it.

Additionally, the server side could also set the data manually with
setSessionData() & then the user side would never even need to know about
it.

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

[gwt-contrib] Re: Please fix eclipse project files for cross-platform development

[Vitali Lovich]

Right - good point.

Thanks

On Tue, Mar 31, 2009 at 7:14 AM, Eric Ayers  wrote:

> This will be coming in GWT 2.0.
>
> Currently, each platform's hosted mode has platform specific code that is
> bundled into separate .jar files.
>
> In GWT 2.0, the hosted mode will change to not include a bundled browser or
> container for an embedded browser, but an IPC connection to a browser plugin
> of your choosing.  This will allow the gwt-dev-oophm.jar file to be platform
> agnostic.
>
> On Tue, Mar 31, 2009 at 2:54 AM, Vitali Lovich  wrote:
>
>> Hi,
>>
>> Would it be possible to update the Eclipse classpath for gwt-user to be
>> platform agnostic?
>>
>> Since Eclipse doesn't support variable project references, one way would
>> be to move .classpath to .classpath-template & provide scripts that
>> instrument the .classpath file based on the environment (requires 1 extra
>> step by the user prior to importing the project).
>>
>> Even smoother would be if this could be an ant task (something like ant
>> eclipse-config), although I'm not sure what kind of support ant might have
>> for regular expression replacement in files..
>>
>> Not super important (especially with git), but just annoying that I need
>> to maintain the project files even if I'm not working on Eclipse.  And I
>> understand if you want to keep it as less handle for Windows users.
>>
>> Thoughts?
>>
>>
>>
>
>
> --
> Eric Z. Ayers - GWT Team - Atlanta, GA USA
> http://code.google.com/webtoolkit/
>
> >
>

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

[gwt-contrib] Please fix eclipse project files for cross-platform development

[Vitali Lovich]

Hi,

Would it be possible to update the Eclipse classpath for gwt-user to be
platform agnostic?

Since Eclipse doesn't support variable project references, one way would be
to move .classpath to .classpath-template & provide scripts that instrument
the .classpath file based on the environment (requires 1 extra step by the
user prior to importing the project).

Even smoother would be if this could be an ant task (something like ant
eclipse-config), although I'm not sure what kind of support ant might have
for regular expression replacement in files..

Not super important (especially with git), but just annoying that I need to
maintain the project files even if I'm not working on Eclipse.  And I
understand if you want to keep it as less handle for Windows users.

Thoughts?

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

[gwt-contrib] Re: Public git repository

[Vitali Lovich]

Thx.  The initial checkout's a pain because Google code also limits
you to like 50 kbs/s

On Fri, Mar 27, 2009 at 6:34 PM, Scott Blum  wrote:
> We don't have a public one... but I do have a repo with the whole svn
> history in it that would git you started.  You can grab a copy from a
> personal webpage of mine...
> http://www.shaftnet.org/~sinth/gwt-repo.tgz
> Just download, unpack, checkout, and you should be g2g.  git svn fetch isn't
> so painful if you're nearly up to date already.
>
> On Fri, Mar 27, 2009 at 6:09 PM, Vitali Lovich  wrote:
>>
>> Is there by any chance a public git repository (preferably one that
>> tracks trunk fairly closely)?  git svn clone takes forever.
>>
>> Thanks
>>
>>
>
>
> >
>

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

[gwt-contrib] Public git repository

[Vitali Lovich]

Is there by any chance a public git repository (preferably one that
tracks trunk fairly closely)?  git svn clone takes forever.

Thanks

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

[gwt-contrib] Re: JVM crashes when using GWT compiler under Java 6 update 7 JVM

[Vitali Lovich]

Ok - i'm almost positive it is the same problem.  I think the
loadplugin thing is a misdirection.  The project appears to crash
compiling the code.

On Fri, Mar 27, 2009 at 3:59 PM, Vitali Lovich  wrote:
> Sorry - forgot to mention that this happened when I tried to load the
> hosted mode browser.
>
> On Fri, Mar 27, 2009 at 3:57 PM, Vitali Lovich  wrote:
>> Might be related.  Just set up my project to run under the regular
>> hosted mode w/ 32-bit JVM:
>>
>> LoadPlugin: failed to initialize shared library
>> /home/vlovich/.mozilla/plugins/libflashplayer.so
>> [/home/vlovich/.mozilla/plugins/libflashplayer.so: wrong ELF class:
>> ELFCLASS64]
>> LoadPlugin: failed to initialize shared library
>> /usr/lib/jvm/java-6-sunjre/lib/amd64/libnpjp2.so
>> [/usr/lib/jvm/java-6-sunjre/lib/amd64/libnpjp2.so: wrong ELF class:
>> ELFCLASS64]
>> #
>> # An unexpected error has been detected by Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x0625665c, pid=20124, tid=3607796624
>> #
>> # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86)
>> # Problematic frame:
>> # V  [libjvm.so+0x25665c]
>> #
>> # An error report file with more information is saved as:
>> # /home/vlovich/workspace/sacred_heart/hs_err_pid20124.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   http://java.sun.com/webapps/bugreport/crash.jsp
>> # The crash happened outside the Java Virtual Machine in native code.
>> # See problematic frame for where to report the bug.
>> #
>>
>>
>>
>> On Fri, Mar 27, 2009 at 3:07 PM, Vitali Lovich  wrote:
>>> You can also has the hs_err for the 32-bit vm
>>>
>>> On Fri, Mar 27, 2009 at 2:26 PM, Vitali Lovich  wrote:
>>>> Ugggh... you want me to do all the work don't you :D
>>>>
>>>> On a separate note 5094 compilation is broken (JUnitShell fails to
>>>> compile).  In 5096 the problem is resolved.
>>>>
>>>> On Fri, Mar 27, 2009 at 2:03 PM, Scott Blum  wrote:
>>>>>
>>>>> I can has hs_err_pid17105.log?
>>>>>
>>>>> On Fri, Mar 27, 2009 at 12:36 PM, Vitali Lovich  wrote:
>>>>>>
>>>>>>     [java] Compiling module com.google.gwt.benchmarks.viewer.ReportViewer
>>>>>>  [java] #
>>>>>>  [java] # An unexpected error has been detected by Java Runtime
>>>>>> Environment:
>>>>>>  [java] #
>>>>>>  [java] #  SIGSEGV (0xb) at pc=0x0625665c, pid=17105, tid=3762477968
>>>>>>  [java] #
>>>>>>  [java] # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode
>>>>>> linux-x86)
>>>>>>  [java] # Problematic frame:
>>>>>>  [java] # V  [libjvm.so+0x25665c]
>>>>>>  [java] #
>>>>>>  [java] # An error report file with more information is saved as:
>>>>>>  [java] #
>>>>>> /home/vlovich/workspace/gwt/tools/benchmark-viewer/hs_err_pid17105.log
>>>>>>  [java] #
>>>>>>  [java] # If you would like to submit a bug report, please visit:
>>>>>>  [java] #   http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>>  [java] # The crash happened outside the Java Virtual Machine in
>>>>>> native code.
>>>>>>  [java] # See problematic frame for where to report the bug.
>>>>>>  [java] #
>>>>>>
>>>>>> This is kind of annoying because GWT fails to build with the newer JDKs
>>>>>> due to the issue mentioned before with the change to generics.  So it's a
>>>>>> two step workaround:  Use the older sun JDK to compile the classes & 
>>>>>> after
>>>>>> it crashes, use run ant again with the newer JDK so that the GWT compiler
>>>>>> doesn't crash the VM.
>>>>>>
>>>>>> This also happens if I try to use the older JDK with my projects, but
>>>>>> that's not really an issue since I just use the latest OpenJDK in the 
>>>>>> Ubuntu
>>>>>> repos.
>>>>>>
>>>>>> Might be relevant that I'm using 64-bit jdks.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> >>>>>
>>>>
>>>>
>>>
>>
>

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

[gwt-contrib] Re: JVM crashes when using GWT compiler under Java 6 update 7 JVM

[Vitali Lovich]

Sorry - forgot to mention that this happened when I tried to load the
hosted mode browser.

On Fri, Mar 27, 2009 at 3:57 PM, Vitali Lovich  wrote:
> Might be related.  Just set up my project to run under the regular
> hosted mode w/ 32-bit JVM:
>
> LoadPlugin: failed to initialize shared library
> /home/vlovich/.mozilla/plugins/libflashplayer.so
> [/home/vlovich/.mozilla/plugins/libflashplayer.so: wrong ELF class:
> ELFCLASS64]
> LoadPlugin: failed to initialize shared library
> /usr/lib/jvm/java-6-sunjre/lib/amd64/libnpjp2.so
> [/usr/lib/jvm/java-6-sunjre/lib/amd64/libnpjp2.so: wrong ELF class:
> ELFCLASS64]
> #
> # An unexpected error has been detected by Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x0625665c, pid=20124, tid=3607796624
> #
> # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86)
> # Problematic frame:
> # V  [libjvm.so+0x25665c]
> #
> # An error report file with more information is saved as:
> # /home/vlovich/workspace/sacred_heart/hs_err_pid20124.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
>
>
>
> On Fri, Mar 27, 2009 at 3:07 PM, Vitali Lovich  wrote:
>> You can also has the hs_err for the 32-bit vm
>>
>> On Fri, Mar 27, 2009 at 2:26 PM, Vitali Lovich  wrote:
>>> Ugggh... you want me to do all the work don't you :D
>>>
>>> On a separate note 5094 compilation is broken (JUnitShell fails to
>>> compile).  In 5096 the problem is resolved.
>>>
>>> On Fri, Mar 27, 2009 at 2:03 PM, Scott Blum  wrote:
>>>>
>>>> I can has hs_err_pid17105.log?
>>>>
>>>> On Fri, Mar 27, 2009 at 12:36 PM, Vitali Lovich  wrote:
>>>>>
>>>>>     [java] Compiling module com.google.gwt.benchmarks.viewer.ReportViewer
>>>>>  [java] #
>>>>>  [java] # An unexpected error has been detected by Java Runtime
>>>>> Environment:
>>>>>  [java] #
>>>>>  [java] #  SIGSEGV (0xb) at pc=0x0625665c, pid=17105, tid=3762477968
>>>>>  [java] #
>>>>>  [java] # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode
>>>>> linux-x86)
>>>>>  [java] # Problematic frame:
>>>>>  [java] # V  [libjvm.so+0x25665c]
>>>>>  [java] #
>>>>>  [java] # An error report file with more information is saved as:
>>>>>  [java] #
>>>>> /home/vlovich/workspace/gwt/tools/benchmark-viewer/hs_err_pid17105.log
>>>>>  [java] #
>>>>>  [java] # If you would like to submit a bug report, please visit:
>>>>>  [java] #   http://java.sun.com/webapps/bugreport/crash.jsp
>>>>>  [java] # The crash happened outside the Java Virtual Machine in
>>>>> native code.
>>>>>  [java] # See problematic frame for where to report the bug.
>>>>>  [java] #
>>>>>
>>>>> This is kind of annoying because GWT fails to build with the newer JDKs
>>>>> due to the issue mentioned before with the change to generics.  So it's a
>>>>> two step workaround:  Use the older sun JDK to compile the classes & after
>>>>> it crashes, use run ant again with the newer JDK so that the GWT compiler
>>>>> doesn't crash the VM.
>>>>>
>>>>> This also happens if I try to use the older JDK with my projects, but
>>>>> that's not really an issue since I just use the latest OpenJDK in the 
>>>>> Ubuntu
>>>>> repos.
>>>>>
>>>>> Might be relevant that I'm using 64-bit jdks.
>>>>>
>>>>>
>>>>
>>>>
>>>> >>>>
>>>
>>>
>>
>

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

[gwt-contrib] Re: JVM crashes when using GWT compiler under Java 6 update 7 JVM

[Vitali Lovich]

You can also has the hs_err for the 32-bit vm

On Fri, Mar 27, 2009 at 2:26 PM, Vitali Lovich  wrote:
> Ugggh... you want me to do all the work don't you :D
>
> On a separate note 5094 compilation is broken (JUnitShell fails to
> compile).  In 5096 the problem is resolved.
>
> On Fri, Mar 27, 2009 at 2:03 PM, Scott Blum  wrote:
>>
>> I can has hs_err_pid17105.log?
>>
>> On Fri, Mar 27, 2009 at 12:36 PM, Vitali Lovich  wrote:
>>>
>>>     [java] Compiling module com.google.gwt.benchmarks.viewer.ReportViewer
>>>  [java] #
>>>  [java] # An unexpected error has been detected by Java Runtime
>>> Environment:
>>>  [java] #
>>>  [java] #  SIGSEGV (0xb) at pc=0x0625665c, pid=17105, tid=3762477968
>>>  [java] #
>>>  [java] # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode
>>> linux-x86)
>>>  [java] # Problematic frame:
>>>  [java] # V  [libjvm.so+0x25665c]
>>>  [java] #
>>>  [java] # An error report file with more information is saved as:
>>>  [java] #
>>> /home/vlovich/workspace/gwt/tools/benchmark-viewer/hs_err_pid17105.log
>>>  [java] #
>>>  [java] # If you would like to submit a bug report, please visit:
>>>  [java] #   http://java.sun.com/webapps/bugreport/crash.jsp
>>>  [java] # The crash happened outside the Java Virtual Machine in
>>> native code.
>>>  [java] # See problematic frame for where to report the bug.
>>>  [java] #
>>>
>>> This is kind of annoying because GWT fails to build with the newer JDKs
>>> due to the issue mentioned before with the change to generics.  So it's a
>>> two step workaround:  Use the older sun JDK to compile the classes & after
>>> it crashes, use run ant again with the newer JDK so that the GWT compiler
>>> doesn't crash the VM.
>>>
>>> This also happens if I try to use the older JDK with my projects, but
>>> that's not really an issue since I just use the latest OpenJDK in the Ubuntu
>>> repos.
>>>
>>> Might be relevant that I'm using 64-bit jdks.
>>>
>>>
>>
>>
>> >>
>
>

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



hs_err_pid13507.log
Description: Binary data

[gwt-contrib] Re: GWTC compiler disallows using a derivative of AsyncCallback on async interface declaration

[Vitali Lovich]

hmm... i looked and there appears to be a simple fix.

  private static String computeInternalSignature(JMethod method) {
StringBuffer sb = new StringBuffer();
sb.setLength(0);
sb.append(method.getName());
JParameter[] params = method.getParameters();
int i = 0;
for (JParameter param : params) {
  sb.append("/");
  JType paramType = param.getType();
  if (i++ == params.length - 1) {
paramType = getAsyncCallbackSignature(paramType);
  }
  sb.append(paramType.getErasedType().getQualifiedSourceName());
}
return sb.toString();
  }

getAsyncCallbackSignature simply checks to see if there's a way to
cast the paramType to AsyncCallback.  If there is, then it returns the
equivalent AsyncCallback JType.  If there isn't, it returns the
original JType.

Haven't looked at the JType API to see how getAsyncCallbackSignature
would be written.  I'll try to look at it Tuesday evening when I have
some time.

On Fri, Mar 27, 2009 at 2:10 PM, Scott Blum  wrote:
>
> I'm sure it's unintentional.  Here's where you would go to fix it:
> http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/user/rebind/rpc/RemoteServiceAsyncValidator.java#185
>
> On Fri, Mar 27, 2009 at 2:00 PM, Vitali Lovich  wrote:
>>
>> I tried to use my own custom class that extends AsyncCallback in the async 
>> interface, & the compiler told me that the async version didn't match the 
>> sync version.
>>
>> For instance:  public interface NoResultCallback extends 
>> AsyncCallback.  It's not really an issue, but I prefer to use the more 
>> precise type to get the compiler to statically check the code.
>>
>> Is this by design for a reason?
>>
>
>
> >

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

[gwt-contrib] Re: JVM crashes when using GWT compiler under Java 6 update 7 JVM

[Vitali Lovich]

Ugggh... you want me to do all the work don't you :D

On a separate note 5094 compilation is broken (JUnitShell fails to
compile).  In 5096 the problem is resolved.

On Fri, Mar 27, 2009 at 2:03 PM, Scott Blum  wrote:

> I can has hs_err_pid17105.log?
>
>
> On Fri, Mar 27, 2009 at 12:36 PM, Vitali Lovich  wrote:
>
>>
>> [java] Compiling module com.google.gwt.benchmarks.viewer.ReportViewer
>>  [java] #
>>  [java] # An unexpected error has been detected by Java Runtime
>> Environment:
>>  [java] #
>>  [java] #  SIGSEGV (0xb) at pc=0x0625665c, pid=17105, tid=3762477968
>>  [java] #
>>  [java] # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode
>> linux-x86)
>>  [java] # Problematic frame:
>>  [java] # V  [libjvm.so+0x25665c]
>>  [java] #
>>  [java] # An error report file with more information is saved as:
>>  [java] #
>> /home/vlovich/workspace/gwt/tools/benchmark-viewer/hs_err_pid17105.log
>>  [java] #
>>  [java] # If you would like to submit a bug report, please visit:
>>  [java] #   http://java.sun.com/webapps/bugreport/crash.jsp
>>  [java] # The crash happened outside the Java Virtual Machine in
>> native code.
>>  [java] # See problematic frame for where to report the bug.
>>  [java] #
>>
>> This is kind of annoying because GWT fails to build with the newer JDKs
>> due to the issue mentioned before with the change to generics.  So it's a
>> two step workaround:  Use the older sun JDK to compile the classes & after
>> it crashes, use run ant again with the newer JDK so that the GWT compiler
>> doesn't crash the VM.
>>
>> This also happens if I try to use the older JDK with my projects, but
>> that's not really an issue since I just use the latest OpenJDK in the Ubuntu
>> repos.
>>
>> Might be relevant that I'm using 64-bit jdks.
>>
>>
>>
>
> >
>

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



hs_err_pid2473.log
Description: Binary data

[gwt-contrib] GWTC compiler disallows using a derivative of AsyncCallback on async interface declaration

[Vitali Lovich]

I tried to use my own custom class that extends AsyncCallback in the async
interface, & the compiler told me that the async version didn't match the
sync version.

For instance:  public interface NoResultCallback extends
AsyncCallback.  It's not really an issue, but I prefer to use the more
precise type to get the compiler to statically check the code.

Is this by design for a reason?

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

[gwt-contrib] JVM crashes when using GWT compiler under Java 6 update 7 JVM

[Vitali Lovich]

[java] Compiling module com.google.gwt.benchmarks.viewer.ReportViewer
 [java] #
 [java] # An unexpected error has been detected by Java Runtime
Environment:
 [java] #
 [java] #  SIGSEGV (0xb) at pc=0x0625665c, pid=17105, tid=3762477968
 [java] #
 [java] # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode
linux-x86)
 [java] # Problematic frame:
 [java] # V  [libjvm.so+0x25665c]
 [java] #
 [java] # An error report file with more information is saved as:
 [java] #
/home/vlovich/workspace/gwt/tools/benchmark-viewer/hs_err_pid17105.log
 [java] #
 [java] # If you would like to submit a bug report, please visit:
 [java] #   http://java.sun.com/webapps/bugreport/crash.jsp
 [java] # The crash happened outside the Java Virtual Machine in native
code.
 [java] # See problematic frame for where to report the bug.
 [java] #

This is kind of annoying because GWT fails to build with the newer JDKs due
to the issue mentioned before with the change to generics.  So it's a two
step workaround:  Use the older sun JDK to compile the classes & after it
crashes, use run ant again with the newer JDK so that the GWT compiler
doesn't crash the VM.

This also happens if I try to use the older JDK with my projects, but that's
not really an issue since I just use the latest OpenJDK in the Ubuntu
repos.

Might be relevant that I'm using 64-bit jdks.

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

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

[Vitali Lovich]

On Thu, Mar 26, 2009 at 3:17 PM, Scott Blum  wrote:

> Vitali, are you positive all your stuff is in a legit state?  I ask because
> it looks like you're mixing trunk and 1.6 stuff together.
>

Can you clarify what you mean? How can I be mixing trunk & 1.6 together?
I'm only using trunk.  At this point I don't event have the gwt-platform
directory in my project path - I just imported the GWT projects & made put
them on my classpath.

When I use a stock gwt-dev-windows.jar from 1...@r5090,
>
I'm using trunk (@ 5084 right now).  I haven't even tried stock because I'm
on linux 64-bit & I haven't bothered trying to get the 32-bit environment
set up for the old hosted mode (relying solely on OOPHM).



> I can boot your project just fine whether log4j-1.2.15.jar is in
> WEB-INF/lib or not.  (I can run it because I couldn't actually find a
> version of mosaic that you compile against cleanly, but the servlets all
> initialized just fine.)
>

Right - I forgot that the code I sent you at that point already had my
enhancements to mosaic (eventually a version of them should get into
truck).   In any case, you can just delete the code that throws up an error
(unless its the constructor).

My  code runs fine (including servlets) & the logging works.  It's just that
error
that gets printed to the console when the project launches, so it's not a
super-important issue.  Is it possible it's a Linux-only issue?


>
> Here's a dump of the exact dir structure that's working for me:
>
> .classpath
>
.project
>
gwt-windows-0.0.0
> gwt-windows-0.0.0/gwt-dev-windows.jar
> gwt-windows-0.0.0/gwt-ll.dll
> gwt-windows-0.0.0/gwt-user.jar
> gwt-windows-0.0.0/swt-win32-3235.dll
> lib
> lib/ftr-gwt-library-date-0.9.9.jar
> lib/ftr-gwt-library-date-emul-0.9.9.jar
> lib/gwt-beans-binding-0.2.3.jar
> lib/gwt-dnd-2.5.6.jar
> lib/gwt-incubator-trunk-r1543.jar
> lib/gwt-mosaic-0.2.0-rc1.jar
> lib/gwtx-1.5.2.jar
> lib/log4j-1.2.15.jar
>  lib/org.cobogw.gwt-1.2.2.jar
> SacredHeart.launch
> src (omitted)
> war
> war/loading.gif
> war/SacredHeart.css
> war/SacredHeart.html
> war/WEB-INF
> war/WEB-INF/classes (omitted)
> war/WEB-INF/classes/ece456
> war/WEB-INF/classes/log4j.properties
> war/WEB-INF/lib
> war/WEB-INF/lib/gwt-servlet.jar
> war/WEB-INF/lib/log4j-1.2.15.jar
> war/WEB-INF/lib/mysql-connector-java-5.1.7-bin.jar
> war/WEB-INF/web.xml
>
>
> I attached the .project, .classpath, and launch config I'm using.  This
> configuration boots whether or not I have war/WEB-INF/lib/log4j-1.2.15.jar
> in there.
>
> On Wed, Mar 25, 2009 at 7:32 PM, Vitali Lovich  wrote:
>
>>
>> On Wed, Mar 25, 2009 at 7:10 PM, Scott Blum  wrote:
>>
>>> On Wed, Mar 25, 2009 at 6:22 PM, Vitali Lovich wrote:
>>>
>>>> If I don't put the log4j file into my WEB-INF/lib directory, then it's
>>>> fine.  If it is put there, then it gets the conflicting version (regardless
>>>> of whether or not I launch HostedMode with log4j on the class path).  So am
>>>> I doing it wrong?
>>>>
>>>
>>> i'm confused... if you don't have log4j on the classpath, how can you be
>>> loading it via Launcher$AppClassLoader?  It must be hiding out in some other
>>> jar you have on the classpath?
>>>
>> Sorry for the confusion.  Here's what I meant:
>> If I add the log4j library in the WEB-INF/lib to the classpath of the
>> runtime configuration, I get the problem above.
>> If I move the log4j library out of the WEB-INF/lib directory to somewhere
>> else like project/lib & add it to the classpath, then it works.
>>
>>>
>>> Am I supposed to place it elsewhere & then copy it over to WEB-INF/lib
>>>> when I'm packaging it up only?
>>>>
>>>
>>> That's not the intent... can you send me a small sample that repros this?
>>>
>> I don't have time right now.  If you want I can e-mail you my project
>> privately.  It's a school project, so there's no confidentiality to it or
>> anything.  I just don't want to spam the mailing list.
>>
>> Thanks
>>
>>>
>>> Scott
>>>
>>>
>>>
>>
>>
>>
>
> >
>

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

[gwt-contrib] OOPHM HostedMode not compatible with FF3.1?

[Vitali Lovich]

I just tested the XPCOM plugin in FF3.1 & got the following on startup:

00:00:21.687 [WARN] JSNI method '__defineStatic' returned a value of type
boolean but was declared void; it should not have returned a value at all
00:00:21.891 [WARN] JSNI method
'@com.google.gwt.dom.client.Style::setPropertyPxImpl(Ljava/lang/String;I)'
returned a value of type boolean but was declared void; it should not have
returned a value at all
00:00:21.891 [WARN] JSNI method
'@com.google.gwt.dom.client.Style::setPropertyPxImpl(Ljava/lang/String;I)'
returned a value of type boolean but was declared void; it should not have
returned a value at all
00:00:21.891 [WARN] JSNI method
'@com.google.gwt.dom.client.Element::setPropertyString(Ljava/lang/String;Ljava/lang/String;)'
returned a value of type boolean but was declared void; it should not have
returned a value at all
00:00:21.891 [WARN] JSNI method
'@com.google.gwt.dom.client.Element::setPropertyString(Ljava/lang/String;Ljava/lang/String;)'
returned a value of type boolean but was declared void; it should not have
returned a value at all
00:00:21.891 [WARN] JSNI method
'@com.google.gwt.dom.client.Element::setPropertyInt(Ljava/lang/String;I)'
returned a value of type boolean but was declared void; it should not have
returned a value at all
. etc
00:00:22.141 [ERROR] Unable to load module entry point class
ece456.client.SacredHeart (see associated exception for details)
com.google.gwt.dev.shell.HostedModeException: Something other than a Java
object was returned from JSNI method
'@com.google.gwt.user.client.impl.DOMImpl::getEventListener(Lcom/google/gwt/user/client/Element;)':
JS value of type boolean, expected java.lang.Object at
com.google.gwt.dev.shell.JsValueGlue.get(JsValueGlue.java:173) at
com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java:275)
at
com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java:91)
at com.google.gwt.user.client.impl.DOMImpl.getEventListener(DOMImpl.java) at
com.google.gwt.user.client.DOM.getEventListener(DOM.java:794) at
com.google.gwt.user.client.Event$.getEventListener(Event.java:434) at
com.google.gwt.user.client.ui.RootPanel.isElementChildOfWidget(RootPanel.java:271)
at
com.google.gwt.user.client.ui.RootPanel.detachOnWindowClose(RootPanel.java:122)
at com.google.gwt.user.client.ui.RootPanel.get(RootPanel.java:197) at
com.google.gwt.user.client.ui.RootPanel.get(RootPanel.java:137) at
com.google.gwt.user.client.ui.PopupPanel$ResizeAnimation.setState(PopupPanel.java:168)
at com.google.gwt.user.client.ui.PopupPanel.setState(PopupPanel.java:1175)
at com.google.gwt.user.client.ui.PopupPanel.show(PopupPanel.java:786) at
org.gwt.mosaic.ui.client.InfoPanel.show(InfoPanel.java:91) at
org.gwt.mosaic.ui.client.InfoPanel.show(InfoPanel.java:132) at
org.gwt.mosaic.ui.client.InfoPanel.show(InfoPanel.java:99) at
ece456.client.SacredHeart.dbg(SacredHeart.java:235) at
ece456.client.SacredHeart.onModuleLoad(SacredHeart.java:202) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616) at
com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:367) at
com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:169)
at
com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:148)
at java.lang.Thread.run(Thread.java:636)

00:00:22.141 [ERROR] Failed to load module 'sacredheart' from user agent
'Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3) Gecko/20090307
Ubuntu/8.10 (intrepid) Shiretoko/3.1b3' at localhost:54169

Loading the same page under 3.0.7 w/ the XPCOM plugin works.

Neither browser has GWT listed in about:plugins - is this correct for XPCOM?

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

2009/3/25 John Tamplin 

> What version of eclipse are you using?  I only see this when I make
> structural changes to a class.
>
That might be it.   Eclipse 3.5 & Eclipse 3.4.  I'll watch out for the kind
of change I make when this happens.

> j...@google.com (from Android)
>
> On Mar 25, 2009 8:13 PM, "Vitali Lovich"  wrote:
>
>
> > What IDE are you using?  I know there are issues with hot-swap between
> JDT and Javac, so if you ar...
> I'm seeing this problem again.  Debugging in Eclipse, change code &
> hotswapping fails.  I was wrong before though - the debugged code is
> actually stale, so this is a problem in that I have to relaunch HostedMode
> to get the changes (refreshing the page alone doesn't work)
>
> Thanks
>
> >
>

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

> What IDE are you using?  I know there are issues with hot-swap between JDT
> and Javac, so if you aren't using Eclipse you may have some hot-swap issues
> (Eclipse and GWT both use JDT), which allows you to change some classes
> without doing a refresh.  That is independent of a refresh, which is
> basically tossing the running classes and reloading them.

I'm seeing this problem again.  Debugging in Eclipse, change code &
hotswapping fails.  I was wrong before though - the debugged code is
actually stale, so this is a problem in that I have to relaunch HostedMode
to get the changes (refreshing the page alone doesn't work)

Thanks

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

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

[Vitali Lovich]

On Wed, Mar 25, 2009 at 7:10 PM, Scott Blum  wrote:

> On Wed, Mar 25, 2009 at 6:22 PM, Vitali Lovich  wrote:
>
>> If I don't put the log4j file into my WEB-INF/lib directory, then it's
>> fine.  If it is put there, then it gets the conflicting version (regardless
>> of whether or not I launch HostedMode with log4j on the class path).  So am
>> I doing it wrong?
>>
>
> i'm confused... if you don't have log4j on the classpath, how can you be
> loading it via Launcher$AppClassLoader?  It must be hiding out in some other
> jar you have on the classpath?
>
Sorry for the confusion.  Here's what I meant:
If I add the log4j library in the WEB-INF/lib to the classpath of the
runtime configuration, I get the problem above.
If I move the log4j library out of the WEB-INF/lib directory to somewhere
else like project/lib & add it to the classpath, then it works.

>
> Am I supposed to place it elsewhere & then copy it over to WEB-INF/lib when
>> I'm packaging it up only?
>>
>
> That's not the intent... can you send me a small sample that repros this?
>
I don't have time right now.  If you want I can e-mail you my project
privately.  It's a school project, so there's no confidentiality to it or
anything.  I just don't want to spam the mailing list.

Thanks

>
> Scott
>
> >
>

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

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

[Vitali Lovich]

I think I found the problem.

If I don't put the log4j file into my WEB-INF/lib directory, then it's
fine.  If it is put there, then it gets the conflicting version (regardless
of whether or not I launch HostedMode with log4j on the class path).  So am
I doing it wrong?

Am I supposed to place it elsewhere & then copy it over to WEB-INF/lib when
I'm packaging it up only?

On Wed, Mar 25, 2009 at 5:13 PM, Scott Blum  wrote:

> Hmm, but GWT doesn't use log4j internally.  Is it possible you've got
> conflicting versions, one on the system classpath and one in your war
> directory?
>
>
> On Wed, Mar 25, 2009 at 4:40 PM, Vitali Lovich  wrote:
>
>> og4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable
>> to a "org.apache.log4j.Appender" variable.
>> log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
>> log4j:ERROR [sun.misc.launcher$appclassloa...@64601bb1] whereas object of
>> type
>> log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
>> [contextloa...@null([file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/classes/,
>> file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/lib/gwt-servlet.jar,
>> file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/lib/log4j-1.2.15.jar,
>> file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/lib/mysql-connector-java-5.1.7-bin.jar])
>> /
>> com.google.gwt.dev.shell.jetty.jettylauncher$webappcontextwithreloa...@e1651fe
>> ].
>> log4j:ERROR Could not instantiate appender named "dest".
>> log4j:WARN No appenders could be found for logger
>> (org.apache.jasper.compiler.JspRuntimeContext).
>> log4j:WARN Please initialize the log4j system properly.
>>
>> Seems like GWT is loading log4j (at least partially) but then I'm using
>> the actual log4j form the website, so the class loader throws up.  This
>> could also be fixed by just bundling log4j into gwt-servlet - odds are,
>> people are going to want to use log4j on the server anyways.
>>
>>
>> On Wed, Mar 25, 2009 at 4:17 PM, Scott Blum  wrote:
>>
>>> Vitali, can you remind me what your issue is?
>>>
>>>
>>> On Wed, Mar 25, 2009 at 4:10 PM, Vitali Lovich wrote:
>>>
>>>> This didn't fix my log4j issue, but there's a workaround:
>>>>
>>>> adding -Dlog4j.ignoreTCL to the VM arguments fixes it.
>>>>
>>>> On Wed, Mar 25, 2009 at 3:51 PM, Toby Reyelts  wrote:
>>>>
>>>>> Overall, the change to treat server classes vs system classes
>>>>> separately, such that system classes are "API classes" and server classes
>>>>> are "implementation classes" looks good.
>>>>>
>>>>> I'm concerned that there will still be places where things will clash -
>>>>> such as the sharing of log4j across both server and webapps. Given the
>>>>> complexity of the situation, I understand the desire to change behavior as
>>>>> little as possible in this area, though. There's also an argument that,
>>>>> since this is the way Jetty currently functions, you're just exposing 
>>>>> Jetty
>>>>> behavior, as is.
>>>>>
>>>>> I think the situation would be simpler if GWT didn't treat the system
>>>>> classpath as a "user-level" classpath.
>>>>>
>>>>>
>>>>> On Wed, Mar 25, 2009 at 9:15 AM,  wrote:
>>>>>
>>>>>>
>>>>>> Author: sco...@google.com
>>>>>> Date: Wed Mar 25 05:43:19 2009
>>>>>> New Revision: 5078
>>>>>>
>>>>>> Modified:
>>>>>>
>>>>>>
>>>>>> releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
>>>>>>
>>>>>> Log:
>>>>>> Amending r5077:
>>>>>> - Catch ClassNotFound in outside loader and allow internal load
>>>>>> - Allow "system" resources to be loaded internally if they're not
>>>>>> found
>>>>>> externally
>>>>>> - jat suggestion to extract constant
>>>>>> - Fix comments
>>>>>>
>>>>>> Review by: tobyr (TBR)
>>>>>>
>>>>>> Modified:
>>>>>>
>>>>>> releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
>>>>>>
>>

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

[Vitali Lovich]

og4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to
a "org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
log4j:ERROR [sun.misc.launcher$appclassloa...@64601bb1] whereas object of
type
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
[contextloa...@null([file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/classes/,
file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/lib/gwt-servlet.jar,
file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/lib/log4j-1.2.15.jar,
file:/home/vlovich/workspace/sacred_heart/war/WEB-INF/lib/mysql-connector-java-5.1.7-bin.jar])
/
com.google.gwt.dev.shell.jetty.jettylauncher$webappcontextwithreloa...@e1651fe
].
log4j:ERROR Could not instantiate appender named "dest".
log4j:WARN No appenders could be found for logger
(org.apache.jasper.compiler.JspRuntimeContext).
log4j:WARN Please initialize the log4j system properly.

Seems like GWT is loading log4j (at least partially) but then I'm using the
actual log4j form the website, so the class loader throws up.  This could
also be fixed by just bundling log4j into gwt-servlet - odds are, people are
going to want to use log4j on the server anyways.

On Wed, Mar 25, 2009 at 4:17 PM, Scott Blum  wrote:

> Vitali, can you remind me what your issue is?
>
>
> On Wed, Mar 25, 2009 at 4:10 PM, Vitali Lovich  wrote:
>
>> This didn't fix my log4j issue, but there's a workaround:
>>
>> adding -Dlog4j.ignoreTCL to the VM arguments fixes it.
>>
>> On Wed, Mar 25, 2009 at 3:51 PM, Toby Reyelts  wrote:
>>
>>> Overall, the change to treat server classes vs system classes separately,
>>> such that system classes are "API classes" and server classes are
>>> "implementation classes" looks good.
>>>
>>> I'm concerned that there will still be places where things will clash -
>>> such as the sharing of log4j across both server and webapps. Given the
>>> complexity of the situation, I understand the desire to change behavior as
>>> little as possible in this area, though. There's also an argument that,
>>> since this is the way Jetty currently functions, you're just exposing Jetty
>>> behavior, as is.
>>>
>>> I think the situation would be simpler if GWT didn't treat the system
>>> classpath as a "user-level" classpath.
>>>
>>>
>>> On Wed, Mar 25, 2009 at 9:15 AM,  wrote:
>>>
>>>>
>>>> Author: sco...@google.com
>>>> Date: Wed Mar 25 05:43:19 2009
>>>> New Revision: 5078
>>>>
>>>> Modified:
>>>>
>>>>
>>>> releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
>>>>
>>>> Log:
>>>> Amending r5077:
>>>> - Catch ClassNotFound in outside loader and allow internal load
>>>> - Allow "system" resources to be loaded internally if they're not found
>>>> externally
>>>> - jat suggestion to extract constant
>>>> - Fix comments
>>>>
>>>> Review by: tobyr (TBR)
>>>>
>>>> Modified:
>>>>
>>>> releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
>>>>
>>>> ==
>>>> ---
>>>>
>>>> releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
>>>> (original)
>>>> +++
>>>>
>>>> releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
>>>> Wed Mar 25 05:43:19 2009
>>>> @@ -249,6 +249,8 @@
>>>>   */
>>>>  private class WebAppClassLoaderExtension extends WebAppClassLoader
>>>> {
>>>>
>>>> +  private static final String META_INF_SERVICES =
>>>> "META-INF/services/";
>>>> +
>>>>public WebAppClassLoaderExtension() throws IOException {
>>>>  super(bootStrapOnlyClassLoader, WebAppContextWithReload.this);
>>>>}
>>>> @@ -257,17 +259,21 @@
>>>>public URL findResource(String name) {
>>>>  // Specifically for
>>>> META-INF/services/javax.xml.parsers.SAXParserFactory
>>>>  String checkName = name;
>>>> -if (checkName.startsWith("META-INF/services/")) {
>>>> -  checkName =
>>>> checkName.substring("META-INF/services/&quo

[gwt-contrib] Re: [google-web-toolkit commit] r5078 - Amending r5077:

[Vitali Lovich]

This didn't fix my log4j issue, but there's a workaround:

adding -Dlog4j.ignoreTCL to the VM arguments fixes it.

On Wed, Mar 25, 2009 at 3:51 PM, Toby Reyelts  wrote:

> Overall, the change to treat server classes vs system classes separately,
> such that system classes are "API classes" and server classes are
> "implementation classes" looks good.
>
> I'm concerned that there will still be places where things will clash -
> such as the sharing of log4j across both server and webapps. Given the
> complexity of the situation, I understand the desire to change behavior as
> little as possible in this area, though. There's also an argument that,
> since this is the way Jetty currently functions, you're just exposing Jetty
> behavior, as is.
>
> I think the situation would be simpler if GWT didn't treat the system
> classpath as a "user-level" classpath.
>
>
> On Wed, Mar 25, 2009 at 9:15 AM,  wrote:
>
>>
>> Author: sco...@google.com
>> Date: Wed Mar 25 05:43:19 2009
>> New Revision: 5078
>>
>> Modified:
>>
>>
>> releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
>>
>> Log:
>> Amending r5077:
>> - Catch ClassNotFound in outside loader and allow internal load
>> - Allow "system" resources to be loaded internally if they're not found
>> externally
>> - jat suggestion to extract constant
>> - Fix comments
>>
>> Review by: tobyr (TBR)
>>
>> Modified:
>>
>> releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
>>
>> ==
>> ---
>>
>> releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
>> (original)
>> +++
>>
>> releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
>> Wed Mar 25 05:43:19 2009
>> @@ -249,6 +249,8 @@
>>   */
>>  private class WebAppClassLoaderExtension extends WebAppClassLoader {
>>
>> +  private static final String META_INF_SERVICES =
>> "META-INF/services/";
>> +
>>public WebAppClassLoaderExtension() throws IOException {
>>  super(bootStrapOnlyClassLoader, WebAppContextWithReload.this);
>>}
>> @@ -257,17 +259,21 @@
>>public URL findResource(String name) {
>>  // Specifically for
>> META-INF/services/javax.xml.parsers.SAXParserFactory
>>  String checkName = name;
>> -if (checkName.startsWith("META-INF/services/")) {
>> -  checkName = checkName.substring("META-INF/services/".length());
>> +if (checkName.startsWith(META_INF_SERVICES)) {
>> +  checkName = checkName.substring(META_INF_SERVICES.length());
>>  }
>>
>> -// For system/server path, just try the outside world quietly.
>> +// For a system path, load from the outside world.
>> +URL found;
>>  if (isSystemPath(checkName)) {
>> -  return systemClassLoader.getResource(name);
>> +  found = systemClassLoader.getResource(name);
>> +  if (found != null) {
>> +return found;
>> +  }
>>  }
>>
>>  // Always check this ClassLoader first.
>> -URL found = super.findResource(name);
>> +found = super.findResource(name);
>>  if (found != null) {
>>return found;
>>  }
>> @@ -303,14 +309,18 @@
>>
>>@Override
>>protected Class findClass(String name) throws
>> ClassNotFoundException {
>> -// For system/server path, just try the outside world quietly.
>> +// For system path, always prefer the outside world.
>>  if (isSystemPath(name)) {
>> -  return systemClassLoader.loadClass(name);
>> +  try {
>> +return systemClassLoader.loadClass(name);
>> +  } catch (ClassNotFoundException e) {
>> +  }
>>  }
>>
>>  try {
>>return super.findClass(name);
>>  } catch (ClassNotFoundException e) {
>> +  // Don't allow server classes to be loaded from the outside.
>>if (isServerPath(name)) {
>>  throw e;
>>}
>>
>>
>>
>
> >
>

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

[gwt-contrib] Re: OOPHM disconnects when using gwt-mosaic Viewport

[Vitali Lovich]

Gotcha.  I was stupid and for some reason thought XPCOM had something to do
with COM &  would be linux only.  I've been getting no sleep thanks to this
databases project :(.

On Tue, Mar 24, 2009 at 3:29 PM, John Tamplin  wrote:

> On Tue, Mar 24, 2009 at 3:10 PM, Vitali Lovich  wrote:
>
>> As an update, I just realized that the error
>>
>> Error: Bad NPObject as private data!
>> Source File: http://localhost:9000/module/hosted.html?module
>> Line: 84
>>
>> Keeps showing up whenever there's any kind of event (i.e. mouse move, key
>> press, window resize, etc).
>>
>> Attaching the script.
>>
>> This is probably because the OOPHM connection is broken, so it's unable to
>> deliver the events from the browser to the
>
>
> The NPAPI plugin is not really going to work -- you need to use the XPCOM
> plugin<http://code.google.com/p/google-web-toolkit/source/browse/branches/oophm/plugins/xpcom/prebuilt/oophm-xpcom.xpi>instead.
>
> The issue is that whenever window.enableScrolling is changed, Firefox
> rebuilds the page and in the process unloads and reloads the plugin.  Aside
> from losing state in the plugin, this is problematic since the unloaded
> plugin is still on the call stack, and things go bad when it returns to that
> code after a new instance of the plugin is created.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

On Tue, Mar 24, 2009 at 11:01 PM, John Tamplin  wrote:

> On Tue, Mar 24, 2009 at 10:51 PM, Vitali Lovich  wrote:
>
>> Also, this happens on every launch regardless of whether or not code was
>> actually changed.
>>
>
> Right, currently hosted mode builds TypeOracle and other things from
> source, so it has to run all the source through JDT each time you start it.
>
But it also seems to recompile client libraries as well - I get warnings
about using deprecated constructs in my client jars.

5.161:  Request for module
13.379: Refreshing module from source

I found out why it was taking so much time after the compilation loaded to
actually get into my onModuleLoad.  I was accidentally assigning icons from
an ImageBundle into instance variables.

I had created this whole Singleton delay-loaded architecture to lazy load
the services & icons (and oppurtinistically load them in the background
using timers so that the user doesn't notice it but missed the ones in the
login screen during refactoring.


>
>
>> Sorry, my mistake.  Refreshing isn't actually slow.  But if it's doing a
>> bytecode compile, why is it even taking any time on the initial startup when
>> there was no source code change & the compiled classes haven't changed?
>> Shouldn't it notice this & not do anything?
>>
>
> It should not be recompiling any classes that haven't changed, but until
> very recently it always compiled the output of generators.  Amit checked in
> a patch in the past week to avoid the recompile if the generator produces
> the same output.  Eventually, we might build in a way for generators to
> specify their dependencies (or to automatically infer them) and not even run
> the generator if its dependencies have not changed, but right now that is
> not possible.

That might be why I noticed a performance improvement.


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

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

On Tue, Mar 24, 2009 at 4:59 PM, John Tamplin  wrote:

> On Tue, Mar 24, 2009 at 3:59 PM, Vitali Lovich  wrote:
>
>> I think it might be a good idea to also reference the -localWorkers flag.
>> I find that it cuts down on my startup time significantly (especially on my
>> desktop which is quad-core, but even on my dual-core laptop).  With OOPHM I
>> find this to be particularly more annoying because the browser freezes on
>> startup while the server is compiling the code.
>>
>
> I don't know that the OOPHM document is the right place to discuss other
> compiler flags.  Also, I don't think -localWorkers will have any impact on
> hosted mode at all, since it is used to compile different permutations in
> parallel.  it will speedup web-mode compilation if you have more than one
> permutation, but nothing for hosted mode.
>

Sorry my mistake.  It was probably just the placebo effect :D.  However, it
does take about 11 seconds between when the OOPHM connection is established
(request for module in log) & when the onModuleLoad starts executing (8
seconds between Request for module & Refreshing module from source).

My IDE takes about 1 second to compile my project cleanly (same with ant).

On my laptop which takes 4 seconds to build using ant, takes 28 seconds to
go from Request for module to Refreshing module from source & then takes 7
seconds to compile.

When I run HostedMode using the release configuration, then the times drop
to 1/7 for the desktop, & 1/25 for the laptop (compilation time/module
request time).

Also, this happens on every launch regardless of whether or not code was
actually changed.


>
>
>
>> Also, perhaps a mention that every refresh of the page launches a fresh
>> compilation of the code & thus the browser locks up for a while there as
>> well.
>>
>
> It is doing a bytecode compile (including of generated code), not a
> web-mode compile, so it should be very long unless you have a really large
> app.  There is a project we call instant hosted mode which will allow reuse
> of your IDE's bytecode compilation rather than having to recompile, but it
> isn't ready yet (soon though).
>
Sorry, my mistake.  Refreshing isn't actually slow.  But if it's doing a
bytecode compile, why is it even taking any time on the initial startup when
there was no source code change & the compiled classes haven't changed?
Shouldn't it notice this & not do anything?


>
>
>
>> The other thing I noticed is that after changing client-side code  &
>> refreshing, although the debugger claims the source is out of sync, it works
>> perfectly with the changed code.
>
>
> What IDE are you using?  I know there are issues with hot-swap between JDT
> and Javac, so if you aren't using Eclipse you may have some hot-swap issues
> (Eclipse and GWT both use JDT), which allows you to change some classes
> without doing a refresh.  That is independent of a refresh, which is
> basically tossing the running classes and reloading them.

Using Eclipse.  The IDE warns me that hot swapping failed on save.  The
debugger claims the source is out of sync, but like I said, it actually hits
the breakpoints correctly & executes the changed code.

I can't reproduce it right now (I can't remember if it was a persistent
problem and it was fixed by me updating the trunk today or if it was an
intermittent problem).  If it happens again, I'll let you know.


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

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

I think it might be a good idea to also reference the -localWorkers flag.  I
find that it cuts down on my startup time significantly (especially on my
desktop which is quad-core, but even on my dual-core laptop).  With OOPHM I
find this to be particularly more annoying because the browser freezes on
startup while the server is compiling the code.

Also, perhaps a mention that every refresh of the page launches a fresh
compilation of the code & thus the browser locks up for a while there as
well.

The other thing I noticed is that after changing client-side code  &
refreshing, although the debugger claims the source is out of sync, it works
perfectly with the changed code.

On Tue, Mar 24, 2009 at 3:20 PM, John Tamplin  wrote:

> On Fri, Mar 6, 2009 at 7:27 PM, John Tamplin  wrote:
>
>> I will write up a document next week about how to use OOPHM with trunk (it
>> isn't going to be usable with 1.6).
>
>
> Sorry for the delay, but I finally got around to writing it up -- see
> UsingOOPHM on 
> the wiki.  Let me know if that doesn't address any issues you have.
>
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

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

[gwt-contrib] Re: OOPHM disconnects when using gwt-mosaic Viewport

[Vitali Lovich]

As an update, I just realized that the error

Error: Bad NPObject as private data!
Source File: http://localhost:9000/module/hosted.html?module
Line: 84

Keeps showing up whenever there's any kind of event (i.e. mouse move, key
press, window resize, etc).

Attaching the script.

This is probably because the OOPHM connection is broken, so it's unable to
deliver the events from the browser to the plugin.

On Tue, Mar 24, 2009 at 3:03 PM, Vitali Lovich  wrote:

> I'm seeing extremely similar behaviour w/ OOPHM & GWT-Mosaic.  Seems
> someone also encountered the same or similar 
> issue<http://code.google.com/p/gwt-ext/issues/detail?id=443>with gwt-ext.
>
> When I instantiate org.gwt.mosaic.ui.client.Viewport, OOPHM at some point
> decides to disconnect (I looked and it was getting a Quit in reactToMessages
> of BrowserChannel, although I couldn't determine the cause of that.).
>
> I'm attaching the simple Eclipse project test that produces this
> (comment/uncomment the last line of onModuleLoad which creates the
> Viewport).  Project created with webAppCreator.
>
> The test case needs the following files to be placed in test/
> gwt-dev-oophm.jar
> gwt-dev-linux.jar
> gwt-mosaic-0.2.0-rc1.jar
> gwt-user.jar
> gwt-incubator-trunk-r1543.jar
>
>
>
>
>

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




This html file is for hosted mode support.

[gwt-contrib] Re: Announcing GWT 1.6 Release Candidate

[Vitali Lovich]

I just tried the patch with trunk (5072) & got
java.lang.NullPointerException
at sun.misc.MetaIndex.mayContain(MetaIndex.java:243)
at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:761)
at sun.misc.URLClassPath.getResource(URLClassPath.java:185)
at sun.misc.URLClassPath.getResource(URLClassPath.java:237)
at java.lang.ClassLoader.getBootstrapResource(ClassLoader.java:1130)
at java.lang.ClassLoader.getResource(ClassLoader.java:991)
at java.lang.ClassLoader.getResource(ClassLoader.java:989)
at
com.google.gwt.dev.OophmHostedModeBase.loadImageIcon(OophmHostedModeBase.java:293)
at com.google.gwt.dev.HostedMode.getWebServerIcon(HostedMode.java:431)
at
com.google.gwt.dev.OophmHostedModeBase.openAppWindow(OophmHostedModeBase.java:495)
at com.google.gwt.dev.HostedModeBase.doStartup(HostedModeBase.java:493)
at
com.google.gwt.dev.OophmHostedModeBase.doStartup(OophmHostedModeBase.java:420)
at com.google.gwt.dev.HostedMode.doStartup(HostedMode.java:363)
at com.google.gwt.dev.HostedModeBase.startUp(HostedModeBase.java:609)
at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:402)
at com.google.gwt.dev.HostedMode.main(HostedMode.java:264)

on trying to launch OOPHM in HostedMode.  Is this patch compatible?  I'm
trying to fix the issue with the log4j that I'm getting:

log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to
a "org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
log4j:ERROR [sun.misc.launcher$appclassloa...@64601bb1] whereas object of
type
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
[contextloa...@null].
log4j:ERROR Could not instantiate appender named "O".

I think there's some interference going on due to me launching HostedMode.

On Tue, Mar 24, 2009 at 7:41 AM, Alejandro D. Garin wrote:

> Hi Scott,
>
> Yes, this fixes the problem for my configuration, the spring container
> started now :)
> Thanks.
>
>
> On 3/24/09, Scott Blum  wrote:
>>
>> Hey, can you guys do me a favor and try out a fix?
>>
>> Just take the attached jar and put it on your classpath ahead of
>> gwt-dev-.jar.  See if it fixes the "not and instance of Servlet"
>> problem (and doesn't cause other problems).
>>
>> Lemme know if that works, thanks,
>> Scott
>>
>> On Mon, Mar 23, 2009 at 9:09 PM, Alejandro D. Garin wrote:
>>
>>> Are the spring jar and its dependencies in your WEB-INF/lib folder? We
 did introduce an extra "convenience mode" recently, hence the message

>>>
>>> Hi Bruce,
>>>
>>> Yes, the spring.jar is in the lib folder, no other dependences needed.
>>> If you want I can send to you a little demo project based on the
>>> webAppCreator default example plus an Spring bean loaded in the server. The
>>> demo project work fine in 1.6.1
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
> >
>

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

[gwt-contrib] GWT & Generated HTML quirks mode

[Vitali Lovich]

In the HTML file created by GWT's project creator, it puts the browser into
quirks mode by default.

Shouldn't it put in a standards compliant mode by default (AFAIK, doesn't
Google push for standards adoption) & provide a comment saying that the user
should change it to quirks if they really really need to support a
quirks-mode browser (I'm assuming here that that pretty much includes IE
only, so perhaps make that explicit too).  With IE8 on the horizon &
supporting standards mode, that means that all major browsers will soon
support standards-compliant mode.

Thoughts?

Thanks

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

[gwt-contrib] GWT & Generated HTML quirks mode

[Vitali Lovich]

In the HTML file created by GWT's project creator, it puts the browser into
quirks mode by default.

Shouldn't it put in a standards compliant mode by default (AFAIK, doesn't
Google push for standards adoption) & provide a comment saying that the user
should change it to quirks if they really really need to support a
quirks-mode browser (I'm assuming here that that pretty much includes IE
only, so perhaps make that explicit too).  With IE8 on the horizon &
supporting standards mode, that means that all major browsers will soon
support standards-compliant mode.

Thoughts?

Thanks

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

[gwt-contrib] Re: HashSet throwing incorrect exception & possible compiler bug

[Vitali Lovich]

Thanks.  Makes sense because when I tried looking it up in the GWT HashMap
implementation, I couldn't find it :D.

On Thu, Mar 19, 2009 at 10:17 AM, Scott Blum  wrote:

> By the way, GWT doesn't actually throw CoMods in web mode.  So that's the
> real JRE you were tangling with. :-)
>
>
> On Wed, Mar 18, 2009 at 10:08 PM, Vitali Lovich  wrote:
>
>> It's actually not event listeners - it's just a simple messaging delivery
>> system I wrote.  I was more referring to me being stupid & not stepping
>> remembering that I had modified the map.  I just saw
>> ConcurrentModificationException, no obvious modification of the map within
>> the iteration, and just got confused about what's going on.
>>
>>
>> On Wed, Mar 18, 2009 at 7:18 PM, Ray Ryan  wrote:
>>
>>>
>>> FWIW, the HandlerManager class introduced in 1.6 allows concurrent
>>> mods. Because really you're not so silly to want to do that.
>>>
>>> rjrjr
>>>
>>> On Wed, Mar 18, 2009 at 3:53 PM, Vitali Lovich 
>>> wrote:
>>> > Sorry - it was my fault.  I tracked it down.  Within the listener, I
>>> was
>>> > unregistering it - stupid me.
>>> >
>>> > Thanks for your help
>>> > Vitali
>>> >
>>> >
>>> > On Wed, Mar 18, 2009 at 6:43 PM, Ray Cromwell 
>>> wrote:
>>> >>
>>> >>
>>> >> On Wed, Mar 18, 2009 at 3:31 PM, Vitali Lovich 
>>> wrote:
>>> >>>
>>> >>> Nope - still throws an exception.  Nothing in the code example above
>>> >>> modifies the hashset (I print a message when I register a listener,
>>> and I'm
>>> >>> not getting that) - I'm going to verify this though (step through the
>>> first
>>> >>> successful call)
>>> >>
>>> >> Is this happening in web mode, hosted mode, or both? Does it happen in
>>> >> hosted mode?
>>> >> -Ray
>>> >>
>>> >>>
>>> >>>>
>>> >>>> -Ray
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> > >
>>> >
>>>
>>>
>>>
>>
>>
>>
>
> >
>

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

[gwt-contrib] Re: HashSet throwing incorrect exception & possible compiler bug

[Vitali Lovich]

It's actually not event listeners - it's just a simple messaging delivery
system I wrote.  I was more referring to me being stupid & not stepping
remembering that I had modified the map.  I just saw
ConcurrentModificationException, no obvious modification of the map within
the iteration, and just got confused about what's going on.

On Wed, Mar 18, 2009 at 7:18 PM, Ray Ryan  wrote:

>
> FWIW, the HandlerManager class introduced in 1.6 allows concurrent
> mods. Because really you're not so silly to want to do that.
>
> rjrjr
>
> On Wed, Mar 18, 2009 at 3:53 PM, Vitali Lovich  wrote:
> > Sorry - it was my fault.  I tracked it down.  Within the listener, I was
> > unregistering it - stupid me.
> >
> > Thanks for your help
> > Vitali
> >
> >
> > On Wed, Mar 18, 2009 at 6:43 PM, Ray Cromwell 
> wrote:
> >>
> >>
> >> On Wed, Mar 18, 2009 at 3:31 PM, Vitali Lovich 
> wrote:
> >>>
> >>> Nope - still throws an exception.  Nothing in the code example above
> >>> modifies the hashset (I print a message when I register a listener, and
> I'm
> >>> not getting that) - I'm going to verify this though (step through the
> first
> >>> successful call)
> >>
> >> Is this happening in web mode, hosted mode, or both? Does it happen in
> >> hosted mode?
> >> -Ray
> >>
> >>>
> >>>>
> >>>> -Ray
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> > >
> >
>
> >
>

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

[gwt-contrib] Re: HashSet throwing incorrect exception & possible compiler bug

[Vitali Lovich]

Sorry - it was my fault.  I tracked it down.  Within the listener, I was
unregistering it - stupid me.

Thanks for your help
Vitali


On Wed, Mar 18, 2009 at 6:43 PM, Ray Cromwell  wrote:

>
>
> On Wed, Mar 18, 2009 at 3:31 PM, Vitali Lovich  wrote:
>
>>
>> Nope - still throws an exception.  Nothing in the code example above
>> modifies the hashset (I print a message when I register a listener, and I'm
>> not getting that) - I'm going to verify this though (step through the first
>> successful call)
>>
>
> Is this happening in web mode, hosted mode, or both? Does it happen in
> hosted mode?
>
> -Ray
>
>
>
>>
>>
>>
>>> -Ray
>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>

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

[gwt-contrib] Re: HashSet throwing incorrect exception & possible compiler bug

[Vitali Lovich]

On Wed, Mar 18, 2009 at 6:10 PM, Ray Cromwell  wrote:

>
>
> On Wed, Mar 18, 2009 at 2:57 PM, Vitali Lovich  wrote:
>
>> First major concern is that I got a ConcurrentModificationException when
>> iterating over a HashSet - this exception is completely meaningless in the
>> context of the browser (no threading).  There's also not really any
>> meaningful message in the stack trace:
>>
>
> It applies equally well to single-thread scenarios, see the JavaDoc:
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/ConcurrentModificationException.html
>
Right - I was just implying that seeing as how my code in no way actually
modifies the set while iterating over it, the concurrent modification
exception is meaningless.

<http://java.sun.com/j2se/1.5.0/docs/api/java/util/ConcurrentModificationException.html>
>
>
>> somehow fixes the problem.  Is the compiler screwing up in converting the
>> Java for-each notation into the iterator equivalent, or am I missing
>> something?
>>
>> Some background:  this succeeds the first time it is called from within an
>> event handler context (to notify the model to perform a login attempt).
>> However, it fails the second time it is called when it is called from an
>> AsyncCallback context (returning the result that it was a successful
>> login).  However, at no point is the HashSet used modified (after startup
>> where it contains currently 1 element).
>>
>
> It's possible there's a bug, but perhaps you should try wrapping things in
> Collections.unmodifableSet()/Map() to make sure it's not being modified in
> some way.
>
Nope - still throws an exception.  Nothing in the code example above
modifies the hashset (I print a message when I register a listener, and I'm
not getting that) - I'm going to verify this though (step through the first
successful call)


> -Ray
>
>
> >
>

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

[gwt-contrib] HashSet throwing incorrect exception & possible compiler bug

[Vitali Lovich]

First major concern is that I got a ConcurrentModificationException when
iterating over a HashSet - this exception is completely meaningless in the
context of the browser (no threading).  There's also not really any
meaningful message in the stack trace:

00:20:24.446 [ERROR] Uncaught exception escaped
java.util.ConcurrentModificationException: null at
java.util.HashMap$HashIterator.nextEntry(HashMap.java:810) at
java.util.HashMap$KeyIterator.next(HashMap.java:845)

The relevant code that causes this is:

  private HashMap> models;
// .
  HashSet listeners = models.get(action);
if (listeners != null) {
  for (ModelListener listener : listeners)
listener.modelUpdated(action, info);
}

Replacing it with a regular iterator:

  Iterator iterator = listeners.iterator();
  while (iterator.hasNext())
  iterator.next().modelUpdated(action, info);

somehow fixes the problem.  Is the compiler screwing up in converting the
Java for-each notation into the iterator equivalent, or am I missing
something?

Some background:  this succeeds the first time it is called from within an
event handler context (to notify the model to perform a login attempt).
However, it fails the second time it is called when it is called from an
AsyncCallback context (returning the result that it was a successful
login).  However, at no point is the HashSet used modified (after startup
where it contains currently 1 element).

Thanks

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

[gwt-contrib] Re: code review requested - add OOPHM support for HostedMode

[Vitali Lovich]

Oh I wasn't complaining.  It's not an issue at all since FF has session
restore.  Just wondering if it was a known issue & if I should file a bug.

On Tue, Mar 17, 2009 at 12:08 AM, John Tamplin  wrote:

> On Mon, Mar 16, 2009 at 11:59 PM, Vitali Lovich  wrote:
>
>> I'm not 100% sure if this is related to the patch, but I'm seeing an issue
>> in the following situation:
>>
>
> I doubt this has anything to do with the patch -- basically the issue is
> that with the plugin, Firefox is dependent upon the link to the OOPHM server
> since the plugin makes synchronous RPC calls from native code that block the
> UI event loop until it gets a response (since the calls to Java methods from
> JS and vice-versa have to be synchronous).  If that connection goes away, it
> can hang the browser until the OS notices the connection has died.  If your
> TCP connection goes to another machine, then the connection will be killed
> by the other end due to keep-alive being set, but the process running on the
> laptop won't notice for a while after it comes up -- but it should
> eventually come back.
>
> If both the OOPHM server and the browser are running on your laptop, I am
> surprised that there would be any issues here (though frequently after
> waking up everything has to be paged back in from disk so you can experience
> sluggish behavior while that happens), but this is not something that has
> been tested as far as I know.
>
> This is probably a good time to mention that OOPHM isn't the default
> because it has a lot of unpolished edges.  If you aren't willing to put up
> with them or use workarounds (like closing the OOPHM session in your browser
> before suspending if that is causing an issue), then perhaps you shouldn't
> be using it until we get it more polished.
>
> We do want to know about issues such as these, but it will probably be a
> while longer before everything is the way we want it.
>
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

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

[gwt-contrib] Re: code review requested - add OOPHM support for HostedMode

[Vitali Lovich]

I'm not 100% sure if this is related to the patch, but I'm seeing an issue
in the following situation:

Started a project in OOPHM HostedMode
Firefox 3.1 with plugin (version bumpbed to 3.1).
Put laptop to sleep
On wakeup, Firefox locks up.

Now some variables do change - the connection drops out temporarily while
the wireless is reconnecting to a different network (the laptop is moved to
a different location while it's sleeping).

Can anyone else confirm this issue?  Obviously it's not the ideal set-up
with FF3.1.

On Mon, Mar 16, 2009 at 11:42 PM, John Tamplin  wrote:

> On Mon, Mar 16, 2009 at 11:16 PM, Scott Blum  wrote:
>
>> - The whole PlatformSpecific -> CheckForUpdates stuff.. I think that looks
>> good, but can we do that first as a separate commit?
>>
>
> Ok.
>
>
>> - The BrowserListener diff seems unrelated also unless I'm missing
>> something
>>
>
> Well, I ran into the problem while testing this and it seemed like a good
> idea to fix it (the problem is avoiding a crash if the OOPHM socket was
> already in use).  It can be separated out if you prefer.
>
>
>> - HostedModeBase: why are the two old protected methods being added back
>> in?
>>
>
> Hmm, looks like merge issues or getting overzealous moving stuff up from
> OOPHM/GWTShell, along with the call to doShouldCheckForUpdates in
> doStartup().  If we are moving the CheckForUpdates changes into a separate
> commit, then this file would be unchanged for now.
>
>
>> - OophmBrowserWidgetHostImpl should just subclass BrowserWidgetHostImpl,
>> right?  This would remove a lot of duplicate code I think.
>>
>
> What code could it use?  I don't see any method which is the same as
> HostedModeBase.BrowserWidgetHostImpl?
>
>
>> - ArgHandlerStartupURLsExtra should be in GWTShell, not
>> OophmHostedModeBase
>>
>
> Ok.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

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

[gwt-contrib] Re: Changed gwt.xml not picked up buy webserver

[Vitali Lovich]

Yeah, sorry if I haven't made that clear.  I am using the patch that was
posted earlier that enables OOPHM for HostedMode.  I'll try increasing the
log level.

On Mon, Mar 16, 2009 at 11:01 PM, John Tamplin  wrote:

> On Mon, Mar 16, 2009 at 10:58 PM, Scott Blum  wrote:
>
>> There's something I'm not understanding about your setup.  You say you're
>> using HostedMode and the 1.6 project structure, but then you also said you
>> were using OOPHM.  How is that possible?  OOPHM doesn't support the new
>> project structure.
>
>
> He said he was using the patch posted earlier, so I presume he means the
> one you are reviewing.
>
> That said, that has not been thoroughly vetted so it is possible there is
> an issue there.  I have successfully refreshed a .gwt.xml change, but I
> don't have exactly the same setup as you.  Can you increase the log level
> and see if an earlier log message after refreshing gives any clues?
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
>
> >
>

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

[gwt-contrib] Re: Changed gwt.xml not picked up buy webserver

[Vitali Lovich]

I dunno - I applied the patch for hosted mode that was posted a while back.
I'm pretty sure it's hosted mode - otherwise, my project wouldn't run
without me having to redo the 1.5 project structure.  Maybe I'm not
understanding what you mean by GWTShell.  The main class that is launched is
HostedMode.

So what I was trying to do was change the theme that was being used by my
module by updating the gwt.xml file.

Then I reloaded the web-page to get it to pick up the change, but instead I
got the error "unable to find module

My set up is as follows:
MyModule.gwt.xml -> contains my project description - rename-to set to
mymodule
MyModuleHosted.gwt.xml -> contains project description w/ user-agent set & 1
localization set so that compilation is faster (renamed to same name as
MyModule).

Load ModuleHosted.

Hit website to ensure that everything is working fine.
Change the theme ( to some other valid
theme).
Hit Refresh
Message "[ERROR] Unable to find 'mymodule.gwt.xml' on your classpath; could
be a typo, or maybe you forgot to include a classpath entry for source?"

So it looks like it may be trying to lookup the wrong descriptor - instead
of trying to lookup the description of the original file it was loaded with,
it gets confused & tries to load the module name.

Thanks,

On Mon, Mar 16, 2009 at 4:34 PM, Scott Blum  wrote:

> OOPHM is still using GWTShell (I still owe John a review).  Can you give us
> a little more detail about what you're doing?  What exact errors are you
> seeing?
>
>
> On Mon, Mar 16, 2009 at 3:53 PM, Vitali Lovich  wrote:
>
>> HostedMode w/ OOPHM.  rev 5009 if that helps.
>>
>>
>> On Mon, Mar 16, 2009 at 11:41 AM, Scott Blum  wrote:
>>
>>> Is this using old-style GWTShell, or the new HostedMode?
>>>
>>> On Mon, Mar 16, 2009 at 2:30 AM, Vitali Lovich wrote:
>>>
>>>> I'm just wondering if this is a bug or expected behaviour.  If I change
>>>> the module descriptor that was used to launch the Jetty server, I am unable
>>>> to refresh the app - the webserver complains about not being able to find
>>>> the module.  Shouldn't it detect this & recompile as necessary?
>>>>
>>>> I think there might be a related bug where this failure to find the
>>>> module doesn't disconnect the server's OOPHM connection (even though the
>>>> browser made a new one because I hit refresh).
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>

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

[gwt-contrib] Re: Changed gwt.xml not picked up buy webserver

[Vitali Lovich]

HostedMode w/ OOPHM.  rev 5009 if that helps.

On Mon, Mar 16, 2009 at 11:41 AM, Scott Blum  wrote:

> Is this using old-style GWTShell, or the new HostedMode?
>
> On Mon, Mar 16, 2009 at 2:30 AM, Vitali Lovich  wrote:
>
>> I'm just wondering if this is a bug or expected behaviour.  If I change
>> the module descriptor that was used to launch the Jetty server, I am unable
>> to refresh the app - the webserver complains about not being able to find
>> the module.  Shouldn't it detect this & recompile as necessary?
>>
>> I think there might be a related bug where this failure to find the module
>> doesn't disconnect the server's OOPHM connection (even though the browser
>> made a new one because I hit refresh).
>>
>>
>>
>
> >
>

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

[gwt-contrib] Changed gwt.xml not picked up buy webserver

[Vitali Lovich]

I'm just wondering if this is a bug or expected behaviour.  If I change the
module descriptor that was used to launch the Jetty server, I am unable to
refresh the app - the webserver complains about not being able to find the
module.  Shouldn't it detect this & recompile as necessary?

I think there might be a related bug where this failure to find the module
doesn't disconnect the server's OOPHM connection (even though the browser
made a new one because I hit refresh).

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

That's not the problem.  I'm running FF3.1 beta which is firefox-3.1 on the
path (MOZ_NO_REMOTE doesn't apply since they are different profiles).  I'm
probably just going to make a symlink in $HOME/bin & have that prepended to
the environment path when launching OOPHM.

On Fri, Mar 13, 2009 at 10:17 AM, John Tamplin  wrote:

> On Fri, Mar 13, 2009 at 7:24 AM, Vitali Lovich  wrote:
>
>> Oh - one question I had is if there's a way to set the browser path?
>
>
> Right now it just execs "firefox URL", so if you set the PATH GWT sees to
> include the Firefox you want to run it will use that.  If you have multiple
> version though, you have to have different profiles and use MOZ_NO_REMOTE=1,
> so you will have to write a wrapper script for that.
>
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

Oh - one question I had is if there's a way to set the browser path?

On Fri, Mar 13, 2009 at 7:22 AM, Vitali Lovich  wrote:

> I'm getting the plugins from the gwt-oophm branch.  The current install.rdf
> says 3.0.*.  I manually set it to 3.1.*.
>
> Installs fine now in 3.1.
>
> I just built the thing from trunk, applied the previous patch for
> HostedMode, and now have my gwt 1.6 project running successfully on 64-bit
> Ubuntu 8.10.  I might try, just for the hell of it to reboot & see if it'll
> work in Windows.
>
> One comment is that even after the patch, I still need to include the
> platform specific dev (gwt-dev-linux) or there are unresolved class
> references (i.e. HostedModeBase).  I think the ant build script needs to be
> updated to pull in the appropriate files from core/.
>
> Otherwise, thanks & keep up the amazing work.
>
>
> On Mon, Mar 9, 2009 at 8:27 AM, Vitali Lovich  wrote:
>
>> *S*orry meant to put this in my previous e-mail.
>> GWT OOPHM Plugin File name: npOOPHM.dll GWT OOPHM Plugin MIME Type
>> Description Suffixes Enabled  application/x-gwt-hosted-mode Plugin to
>> allow debugging of GWT applications in hosted mode.
>> Yes
>>
>>
>> On Mon, Mar 9, 2009 at 8:26 AM, Vitali Lovich  wrote:
>>
>>> The OOPHM is registered in Firefox 3.0.  Firefox 3.1 doesn't have it
>>> registered (which used the XPCOM plugin instead of the Firefox one).
>>>
>>>
>>> On Mon, Mar 9, 2009 at 1:03 AM, Vitali Lovich  wrote:
>>>
>>>> OK - I'll check as soon as I get the chance to work on my GWT project.
>>>>
>>>>
>>>> On Sun, Mar 8, 2009 at 4:21 PM, John Tamplin  wrote:
>>>>
>>>>> On Sun, Mar 8, 2009 at 1:41 PM, Vitali Lovich wrote:
>>>>>>
>>>>>>
>>>>>> It said that the (firefox) plugin is incompatible with this version of
>>>>>> firefox.  It's probably just the version number - you need to bump it up 
>>>>>> to
>>>>>> 3.1.  Even if the ABI remains the same, AFAIK, plugins still have to have
>>>>>> their versions bumped if they specify a maximum.  The XPCOM plugin 
>>>>>> installs
>>>>>> on both.  Registering the dll does nothing for IE (I made sure to launch 
>>>>>> the
>>>>>> 32-bit version).
>>>>>>
>>>>>
>>>>> I believe the version was set to 3.*, so that should be compatible,
>>>>> though I need to check the version actually checked into the branch.
>>>>>
>>>>>
>>>>>> I didn't look in the about:plugins - just the add-ons menu.  Would
>>>>>> there be a difference?  The machine with my project is in Linux for the 
>>>>>> time
>>>>>> being (until some-time Monday), so if there is a difference, I can only
>>>>>> check after then.
>>>>>>
>>>>>
>>>>> The add-ons simply shows the XPI is installed.  The install registers a
>>>>> plugin for a specific MIME type used to access it from the hosted.html, 
>>>>> and
>>>>> that should show up in about:plugins.  if not, then it was unable to
>>>>> actually load the plugin, which in the past has tended to be library 
>>>>> version
>>>>> issues.
>>>>>
>>>>> --
>>>>> John A. Tamplin
>>>>> Software Engineer (GWT), Google
>>>>>
>>>>> >>>>>
>>>>>
>>>>
>>>
>>
>

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

I'm getting the plugins from the gwt-oophm branch.  The current install.rdf
says 3.0.*.  I manually set it to 3.1.*.

Installs fine now in 3.1.

I just built the thing from trunk, applied the previous patch for
HostedMode, and now have my gwt 1.6 project running successfully on 64-bit
Ubuntu 8.10.  I might try, just for the hell of it to reboot & see if it'll
work in Windows.

One comment is that even after the patch, I still need to include the
platform specific dev (gwt-dev-linux) or there are unresolved class
references (i.e. HostedModeBase).  I think the ant build script needs to be
updated to pull in the appropriate files from core/.

Otherwise, thanks & keep up the amazing work.

On Mon, Mar 9, 2009 at 8:27 AM, Vitali Lovich  wrote:

> *S*orry meant to put this in my previous e-mail.
> GWT OOPHM Plugin File name: npOOPHM.dll GWT OOPHM Plugin MIME Type
> Description Suffixes Enabled  application/x-gwt-hosted-mode Plugin to
> allow debugging of GWT applications in hosted mode.
> Yes
>
>
> On Mon, Mar 9, 2009 at 8:26 AM, Vitali Lovich  wrote:
>
>> The OOPHM is registered in Firefox 3.0.  Firefox 3.1 doesn't have it
>> registered (which used the XPCOM plugin instead of the Firefox one).
>>
>>
>> On Mon, Mar 9, 2009 at 1:03 AM, Vitali Lovich  wrote:
>>
>>> OK - I'll check as soon as I get the chance to work on my GWT project.
>>>
>>>
>>> On Sun, Mar 8, 2009 at 4:21 PM, John Tamplin  wrote:
>>>
>>>> On Sun, Mar 8, 2009 at 1:41 PM, Vitali Lovich wrote:
>>>>>
>>>>>
>>>>> It said that the (firefox) plugin is incompatible with this version of
>>>>> firefox.  It's probably just the version number - you need to bump it up 
>>>>> to
>>>>> 3.1.  Even if the ABI remains the same, AFAIK, plugins still have to have
>>>>> their versions bumped if they specify a maximum.  The XPCOM plugin 
>>>>> installs
>>>>> on both.  Registering the dll does nothing for IE (I made sure to launch 
>>>>> the
>>>>> 32-bit version).
>>>>>
>>>>
>>>> I believe the version was set to 3.*, so that should be compatible,
>>>> though I need to check the version actually checked into the branch.
>>>>
>>>>
>>>>> I didn't look in the about:plugins - just the add-ons menu.  Would
>>>>> there be a difference?  The machine with my project is in Linux for the 
>>>>> time
>>>>> being (until some-time Monday), so if there is a difference, I can only
>>>>> check after then.
>>>>>
>>>>
>>>> The add-ons simply shows the XPI is installed.  The install registers a
>>>> plugin for a specific MIME type used to access it from the hosted.html, and
>>>> that should show up in about:plugins.  if not, then it was unable to
>>>> actually load the plugin, which in the past has tended to be library 
>>>> version
>>>> issues.
>>>>
>>>> --
>>>> John A. Tamplin
>>>> Software Engineer (GWT), Google
>>>>
>>>> >>>>
>>>>
>>>
>>
>

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

[gwt-contrib] Re: GWT trunk compile errors rev5009

[Vitali Lovich]

Ahh - gotcha.  Wouldn't this be a backwards compatability issue with the
JDK?  I thought Sun took those seriously (or is that only for the JVM
itself)?

Also as an aside, for some reason update-alternatives for javac was
insufficient.  I have a feeling that ant looks at the java that it was run
with to find the path to javac instead of looking at the javac on the path,
so I also had to do an update-alternatives for java.



On Fri, Mar 13, 2009 at 3:58 AM, John Tamplin  wrote:

> On Fri, Mar 13, 2009 at 3:53 AM, Vitali Lovich  wrote:
>
>> Don't feel like you need to do this workaround just because I said I was
>> using OpenJDK - that's just the default install.  I have no qualms about
>> installing Sun's version (it's just an apt-get away and I'm not a GPL
>> purist).
>
>
> The problem is that the same code is making its way into Sun's 1.7 JDK, so
> if they don't fix the bug we will have to add the workaround to keep it
> possible to build with the latest JDK.
>
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

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

[gwt-contrib] Re: GWT trunk compile errors rev5009

[Vitali Lovich]

Thanks.  Didn't realize OpenJDK had that issue.  I always thought OpenJDK
was just sun's JDK stripped of all the proprietary bits - didn't realize it
could introduce new bugs.

Don't feel like you need to do this workaround just because I said I was
using OpenJDK - that's just the default install.  I have no qualms about
installing Sun's version (it's just an apt-get away and I'm not a GPL
purist).

On Fri, Mar 13, 2009 at 3:50 AM, John Tamplin  wrote:

> On Fri, Mar 13, 2009 at 3:18 AM, Vitali Lovich  wrote:
>
>> Trying to compile a freshly checked out trunk (on Linux - haven't tried on
>> Windows), and I'm getting
>>
>
> This is a known bug in OpenJDK regarding generic type inference.  A
> workaround is to introduce a temporary variable, or to use Sun's JDK
> instead.
>
> A Sun guy was working on a fix, but it didn't turn out to fix the problem
> and it isn't clear they are going to be able to fix it anytime soon
> (apparently javac and all the older compilers were subtly breaking JLS
> regarding recursive type parameters), so we will probably have to just put
> the workaround in our code.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

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

[gwt-contrib] GWT trunk compile errors rev5009

[Vitali Lovich]

Trying to compile a freshly checked out trunk (on Linux - haven't tried on
Windows), and I'm getting


[gwt.javac] Compiling 654 source files to
/home/vlovich/workspace/gwt/build/out/dev/core/bin
[gwt.javac]
/home/vlovich/workspace/gwt/dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java:106:
incompatible types
[gwt.javac] found   :
com.google.gwt.core.ext.linker.Artifact

[gwt.javac] required:
com.google.gwt.core.ext.linker.CompilationResult

[gwt.javac] for (CompilationResult compilation :
toReturn.find(CompilationResult.class))
{
[gwt.javac]
^
[gwt.javac]
/home/vlovich/workspace/gwt/dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java:229:
incompatible types
[gwt.javac] found   :
com.google.gwt.core.ext.linker.Artifact

[gwt.javac] required:
com.google.gwt.core.ext.linker.StylesheetReference

[gwt.javac]   for (StylesheetReference resource :
artifacts.find(StylesheetReference.class))
{
[gwt.javac]
^
[gwt.javac]
/home/vlovich/workspace/gwt/dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java:238:
incompatible types
[gwt.javac] found   :
com.google.gwt.core.ext.linker.Artifact

[gwt.javac] required:
com.google.gwt.core.ext.linker.ScriptReference

[gwt.javac]   for (ScriptReference resource :
artifacts.find(ScriptReference.class))
{
[gwt.javac]
^
[gwt.javac]
/home/vlovich/workspace/gwt/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardLinkerContext.java:438:
incompatible types
[gwt.javac] found   :
com.google.gwt.core.ext.linker.Artifact

[gwt.javac] required:
com.google.gwt.core.ext.linker.EmittedArtifact

[gwt.javac] for (EmittedArtifact artifact :
artifacts.find(EmittedArtifact.class))
{
[gwt.javac]
^

[gwt.javac]
/home/vlovich/workspace/gwt/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardLinkerContext.java:459:
incompatible types
[gwt.javac] found   :
com.google.gwt.core.ext.linker.Artifact

[gwt.javac] required:
com.google.gwt.core.ext.linker.impl.StandardCompilationAnalysis

[gwt.javac] for (StandardCompilationAnalysis soycFiles :
artifacts.find(StandardCompilationAnalysis.class)){

[gwt.javac]
^
[gwt.javac]
/home/vlovich/workspace/gwt/dev/core/src/com/google/gwt/core/linker/SymbolMapsLinker.java:60:
incompatible types
[gwt.javac] found   :
com.google.gwt.core.ext.linker.Artifact

[gwt.javac] required:
com.google.gwt.core.ext.linker.CompilationResult

[gwt.javac] for (CompilationResult result :
artifacts.find(CompilationResult.class))
{
[gwt.javac]
^

[gwt.javac]
/home/vlovich/workspace/gwt/dev/core/src/com/google/gwt/dev/GWTShell.java:215:
incompatible types
[gwt.javac] found   :
com.google.gwt.core.ext.linker.Artifact

[gwt.javac] required:
com.google.gwt.core.ext.linker.EmittedArtifact

[gwt.javac] for (EmittedArtifact artifact :
artifacts.find(EmittedArtifact.class))
{
[gwt.javac]
^
[gwt.javac] Note: Some input files use or override a deprecated
API.
[gwt.javac] Note: Recompile with -Xlint:deprecation for
details.

[gwt.javac] Note: Some input files use unchecked or unsafe operations.
[gwt.javac] Note: Recompile with -Xlint:unchecked for details.
[gwt.javac] 7 errors

BUILD FAILED
/home/vlovich/workspace/gwt/platforms.ant.xml:36: The following error
occurred while executing this line:
/home/vlovich/workspace/gwt/platforms.ant.xml:13: The following error
occurred while executing this line:
/home/vlovich/workspace/gwt/dev/core/build.xml:83: Compile failed; see the
compiler error output for details.


Any ideas? I perused the code, and can't see anything immediately wrong with
it.

~/workspace/gwt/dev$ javac -version
javac 1.6.0_0-internal

Using openjdk-6-sdk on Ubuntu 8.10.

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

[gwt-contrib] Scaling images in resource bundles

[Vitali Lovich]

Would it be possible to have the annotation in the image bundle also include
the desired size, so that the GWT compiler can auto-scale the source image
to the appropriate size.  That way we wouldn't have to maintain a high-res
version of the icons in addition to the scaled down version we want.

Is this a good idea?

Thanks,
Vitali

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

*S*orry meant to put this in my previous e-mail.
GWT OOPHM Plugin File name: npOOPHM.dll GWT OOPHM Plugin MIME Type
Description Suffixes Enabled  application/x-gwt-hosted-mode Plugin to allow
debugging of GWT applications in hosted mode.
Yes

On Mon, Mar 9, 2009 at 8:26 AM, Vitali Lovich  wrote:

> The OOPHM is registered in Firefox 3.0.  Firefox 3.1 doesn't have it
> registered (which used the XPCOM plugin instead of the Firefox one).
>
>
> On Mon, Mar 9, 2009 at 1:03 AM, Vitali Lovich  wrote:
>
>> OK - I'll check as soon as I get the chance to work on my GWT project.
>>
>>
>> On Sun, Mar 8, 2009 at 4:21 PM, John Tamplin  wrote:
>>
>>> On Sun, Mar 8, 2009 at 1:41 PM, Vitali Lovich  wrote:
>>>>
>>>>
>>>> It said that the (firefox) plugin is incompatible with this version of
>>>> firefox.  It's probably just the version number - you need to bump it up to
>>>> 3.1.  Even if the ABI remains the same, AFAIK, plugins still have to have
>>>> their versions bumped if they specify a maximum.  The XPCOM plugin installs
>>>> on both.  Registering the dll does nothing for IE (I made sure to launch 
>>>> the
>>>> 32-bit version).
>>>>
>>>
>>> I believe the version was set to 3.*, so that should be compatible,
>>> though I need to check the version actually checked into the branch.
>>>
>>>
>>>> I didn't look in the about:plugins - just the add-ons menu.  Would there
>>>> be a difference?  The machine with my project is in Linux for the time 
>>>> being
>>>> (until some-time Monday), so if there is a difference, I can only check
>>>> after then.
>>>>
>>>
>>> The add-ons simply shows the XPI is installed.  The install registers a
>>> plugin for a specific MIME type used to access it from the hosted.html, and
>>> that should show up in about:plugins.  if not, then it was unable to
>>> actually load the plugin, which in the past has tended to be library version
>>> issues.
>>>
>>> --
>>> John A. Tamplin
>>> Software Engineer (GWT), Google
>>>
>>> >>>
>>>
>>
>

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

The OOPHM is registered in Firefox 3.0.  Firefox 3.1 doesn't have it
registered (which used the XPCOM plugin instead of the Firefox one).

On Mon, Mar 9, 2009 at 1:03 AM, Vitali Lovich  wrote:

> OK - I'll check as soon as I get the chance to work on my GWT project.
>
>
> On Sun, Mar 8, 2009 at 4:21 PM, John Tamplin  wrote:
>
>> On Sun, Mar 8, 2009 at 1:41 PM, Vitali Lovich  wrote:
>>>
>>>
>>> It said that the (firefox) plugin is incompatible with this version of
>>> firefox.  It's probably just the version number - you need to bump it up to
>>> 3.1.  Even if the ABI remains the same, AFAIK, plugins still have to have
>>> their versions bumped if they specify a maximum.  The XPCOM plugin installs
>>> on both.  Registering the dll does nothing for IE (I made sure to launch the
>>> 32-bit version).
>>>
>>
>> I believe the version was set to 3.*, so that should be compatible, though
>> I need to check the version actually checked into the branch.
>>
>>
>>> I didn't look in the about:plugins - just the add-ons menu.  Would there
>>> be a difference?  The machine with my project is in Linux for the time being
>>> (until some-time Monday), so if there is a difference, I can only check
>>> after then.
>>>
>>
>> The add-ons simply shows the XPI is installed.  The install registers a
>> plugin for a specific MIME type used to access it from the hosted.html, and
>> that should show up in about:plugins.  if not, then it was unable to
>> actually load the plugin, which in the past has tended to be library version
>> issues.
>>
>> --
>> John A. Tamplin
>> Software Engineer (GWT), Google
>>
>> >>
>>
>

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

OK - I'll check as soon as I get the chance to work on my GWT project.

On Sun, Mar 8, 2009 at 4:21 PM, John Tamplin  wrote:

> On Sun, Mar 8, 2009 at 1:41 PM, Vitali Lovich  wrote:
>>
>>
>> It said that the (firefox) plugin is incompatible with this version of
>> firefox.  It's probably just the version number - you need to bump it up to
>> 3.1.  Even if the ABI remains the same, AFAIK, plugins still have to have
>> their versions bumped if they specify a maximum.  The XPCOM plugin installs
>> on both.  Registering the dll does nothing for IE (I made sure to launch the
>> 32-bit version).
>>
>
> I believe the version was set to 3.*, so that should be compatible, though
> I need to check the version actually checked into the branch.
>
>
>> I didn't look in the about:plugins - just the add-ons menu.  Would there
>> be a difference?  The machine with my project is in Linux for the time being
>> (until some-time Monday), so if there is a difference, I can only check
>> after then.
>>
>
> The add-ons simply shows the XPI is installed.  The install registers a
> plugin for a specific MIME type used to access it from the hosted.html, and
> that should show up in about:plugins.  if not, then it was unable to
> actually load the plugin, which in the past has tended to be library version
> issues.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

On Sun, Mar 8, 2009 at 2:13 PM, John Tamplin  wrote:

> On Sun, Mar 8, 2009 at 12:00 AM, Vitali Lovich  wrote:
>
>> Yup - using Firefox.  No warnings came up.  I grabbed the XPCOM plugin
>> from the oophm branch & it installed on both FF3.1 & FF3.0.   The one in the
>> firefox directory only installed in FF3.0.
>>
>
> That is odd, since there should be no difference between 3.0 and 3.1 as far
> as the ABI goes -- did it give you an error message?
>
It said that the (firefox) plugin is incompatible with this version of
firefox.  It's probably just the version number - you need to bump it up to
3.1.  Even if the ABI remains the same, AFAIK, plugins still have to have
their versions bumped if they specify a maximum.  The XPCOM plugin installs
on both.  Registering the dll does nothing for IE (I made sure to launch the
32-bit version).

>
>
>
>> On Windows though, the browser & JVM are still 32-bit - is this still
>> unsupported?  Is x64 Linux supported - that has a 64-bit browser & 64-bit
>> JVM.
>
>
> The JVM doesn't matter for OOPHM, what matters is the browser.  If the
> browser is 32-bit on Windows it should work.  Does it show up in
> about:plugins?

I didn't look in the about:plugins - just the add-ons menu.  Would there be
a difference?  The machine with my project is in Linux for the time being
(until some-time Monday), so if there is a difference, I can only check
after then.

>
>
> The 64-bit Linux plugin works, though I have seen weirdness on some
> distros.  I use it on 64-bit Ubuntu 8 and FC9, though for some reason the
> plugin doesn't initialize on FC10.  I suspect library version issues, and
> getting it where it installs on every distro is one of the polish things
> that needs to be done before we can replace legacy hosted mode.

Luckily I'm using Ubuntu, so I'll try this out as soon as I get back to my
GWT project.  I'm juggling my last (hopefully) 3 assignments of university
right now :D.


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

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

Yup - using Firefox.  No warnings came up.  I grabbed the XPCOM plugin from
the oophm branch & it installed on both FF3.1 & FF3.0.   The one in the
firefox directory only installed in FF3.0.

On Windows though, the browser & JVM are still 32-bit - is this still
unsupported?  Is x64 Linux supported - that has a 64-bit browser & 64-bit
JVM.

On Sat, Mar 7, 2009 at 9:36 PM, John Tamplin  wrote:

> On Sat, Mar 7, 2009 at 8:55 PM, Vitali Lovich  wrote:
>
>> I've been using Vista x64.  I'll try it out on Linux x64 once I get the
>> chance - I have to get some other stuff done before Monday.
>
>
> I don't believe the plugin has been built for Windows x86_64 in the branch
> (I built it XPCOM Windows x86_64 on my machine, but I have no way to test it
> currently).
>
> What browser are you using?  If you are using Firefox, it should have told
> you that the plugin did not support your architecture when you tried to
> install it.
>
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

I've been using Vista x64.  I'll try it out on Linux x64 once I get the
chance - I have to get some other stuff done before Monday.

On Sat, Mar 7, 2009 at 5:40 PM, John Tamplin  wrote:

> On Sat, Mar 7, 2009 at 3:41 PM, Vitali Lovich  wrote:
>
>> Wait - I'm confused.  I am running with trunk & I've been unable to get
>> OOPHM working.
>
>
> I am sure it is something simple as many people, both internally and
> externally, are successfully using it.  When I write up the detailed
> instructions that should help you get going.
>
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

Wait - I'm confused.  I am running with trunk & I've been unable to get
OOPHM working.  Thanks.

On Sat, Mar 7, 2009 at 10:50 AM, John Tamplin  wrote:

> On Sat, Mar 7, 2009 at 8:40 AM, Allahbaksh Asadullah <
> a.allahba...@gmail.com> wrote:
>
>> I am also using OOPHM from past one month. I see lot of productivity
>> improvement by that. But I am scared when I will move GWT 1.6 then I have to
>> again go back to the Hosted Mode browser. Can't we have very basic
>> functionality available for GWT 1.6. Let it be in trunk so that people
>> interested may build it themselve depending upon their need. But definately
>> I can't wait for one more quarter for OOPHM.
>
>
> I'm sorry but it would be too much work to try and port it back and then
> maintain two separate branches of OOPHM.  It is already enough of a hassle
> when we merge from 1.6->trunk, making corresponding changes to OOPHM.
>
> The answer is if you need OOPHM, you are going to need to be running
> trunk.  I realize it is not ready for production use yet, but you can still
> do debugging with trunk and do production compiles with 1.6 if necessary.
>
>
>> Is GWT 1.6 release is due on Google IO?
>>
>
> I'm not the one to comment on release schedules, but you have seen the
> announcements about the milestones and that the next public build will be a
> release candidate, so we are getting close.
>
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

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

[gwt-contrib] Re: Getting oophm working

[Vitali Lovich]

Darn.  Would there be any branch that does work?

On Fri, Mar 6, 2009 at 6:27 PM, John Tamplin  wrote:

> On Fri, Mar 6, 2009 at 6:14 PM, Bruce Johnson  wrote:
>
>> [+John Tamplin, lead dev on OOPHM]
>>
>> @John: Would you have any time to write a short wiki article about how to
>> do this? It does seem like a good way to help people in the community get
>> started trying it out.
>
>
> I will write up a document next week about how to use OOPHM with trunk (it
> isn't going to be usable with 1.6).
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
>
> >
>

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