Why was benchmarking removed in GWT 2.6?

[Alex Epshteyn]

This seemed like a very useful feature back in the day, and I'm really 
curious to know the reasoning behind its removal in release 2.6.0 (RC1) 
.

Does anyone remember?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/1fb9859a-4906-464b-97af-acb5782ab553n%40googlegroups.com.

Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

The license is Apache 2.0 (same as GWT).  There's no patch file. I guess 
you could probably diff it against the GWT source tree yourself.

On Thursday, November 9, 2017 at 3:05:16 AM UTC-5, Lars wrote:
>
> Thanks for sharing this... what is the license of it and is there a patch 
> file (containing only the differences to the GWT SDK) or only the modified 
> classes?
>
> Am Mittwoch, 8. November 2017 04:30:20 UTC+1 schrieb Alex Epshteyn:
>>
>> This project is now on GitHub: 
>> https://github.com/aepshteyn/gwt-stack-trace-kit
>>
>> You can download 
>> <https://github.com/aepshteyn/gwt-stack-trace-kit/releases/download/v1.0/gwt-2.5.0-StackTracePatch.zip>
>>  
>> the stack-trace-enabled GWT 2.5.0 SDK from the project releases.
>>
>> If anyone would like to continue this effort and port this over to the 
>> latest GWT branch, I'll do my best to help!
>>
>> On Wednesday, July 17, 2013 at 4:56:40 PM UTC-4, Alex Epshteyn wrote:
>>>
>>> Dear fellow GWT users,
>>>
>>> I would like to announce that I have finally solved what I always 
>>> thought to be GWT's greatest weakness: its lack of debugging information 
>>> for client-side exceptions in production.  
>>>
>>> With my patch, your deployed app will be able to report stack traces 
>>> like this:
>>>
>>> com.google.gwt.core.client.JavaScriptException: (TypeError) : a is null
>>>
>>> com.google.gwt.dom.client.DOMImplMozilla.$getBodyOffsetLeft(DOMImplMozilla.java:145)
>>>  
>>>
>>> com.google.gwt.user.client.ui.PopupPanel.$setPopupPosition(Document.java:1287)
>>>
>>> com.google.gwt.user.client.ui.PopupPanel.setPopupPosition(PopupPanel.java:884)
>>> com.google.gwt.user.client.ui.PopupPanel.PopupPanel(PopupPanel.java:453) 
>>>
>>> com.typeracer.commons.client.widgets.EnhancedPopup.EnhancedPopup(EnhancedPopup.java:32)
>>>
>>> com.typeracer.commons.client.widgets.PopupWithIcon.PopupWithIcon(PopupWithFocusableTextBox.java:28)
>>>  
>>>
>>> com.typeracer.main.client.controller.TyperacerUncaughtExceptionHandler$1.execute(TyperacerUncaughtExceptionHandler.java:55)
>>>  
>>>
>>> com.google.gwt.core.client.impl.SchedulerImpl.runScheduledTasks(SchedulerImpl.java:50)
>>>  
>>> etc... :-)
>>>
>>>
>>> instead of the current state of affairs that looks like this:
>>>
>>> lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName:  
>>> http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html 
>>> stack: @
>>> http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 
>>> Rub@
>>> http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423 
>>> dSb@
>>> http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190 
>>> tA@
>>> http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 
>>> Xmb@
>>> http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289 
>>> etc... :-(
>>>
>>>
>>> I am asking the community to support me in finishing this effort and 
>>> integrating my patch into GWT.  Please take a look and what I've done, and 
>>> consider making a donation:
>>>
>>> http://igg.me/at/gwt-stack-traces/x/3494291
>>>
>>> I am an indie developer and I just need some funding to continue this 
>>> work.  I'm looking for both grassroots and corporate sponsorship for my 
>>> quest of improving GWT's error reporting and debugging support.
>>>
>>> I've written a detailed white paper ( http://goo.gl/YGsrQ ) that 
>>> describes how my solution works and why it is necessary.  I welcome 
>>> your feedback!
>>>
>>> Thanks!
>>> Alex
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

This project is now on GitHub: 
https://github.com/aepshteyn/gwt-stack-trace-kit

You can download 
<https://github.com/aepshteyn/gwt-stack-trace-kit/releases/download/v1.0/gwt-2.5.0-StackTracePatch.zip>
 
the stack-trace-enabled GWT 2.5.0 SDK from the project releases.

If anyone would like to continue this effort and port this over to the 
latest GWT branch, I'll do my best to help!

On Wednesday, July 17, 2013 at 4:56:40 PM UTC-4, Alex Epshteyn wrote:
>
> Dear fellow GWT users,
>
> I would like to announce that I have finally solved what I always thought 
> to be GWT's greatest weakness: its lack of debugging information for 
> client-side exceptions in production.  
>
> With my patch, your deployed app will be able to report stack traces like 
> this:
>
> com.google.gwt.core.client.JavaScriptException: (TypeError) : a is null
>
> com.google.gwt.dom.client.DOMImplMozilla.$getBodyOffsetLeft(DOMImplMozilla.java:145)
>  
>
> com.google.gwt.user.client.ui.PopupPanel.$setPopupPosition(Document.java:1287)
>
> com.google.gwt.user.client.ui.PopupPanel.setPopupPosition(PopupPanel.java:884)
> com.google.gwt.user.client.ui.PopupPanel.PopupPanel(PopupPanel.java:453) 
>
> com.typeracer.commons.client.widgets.EnhancedPopup.EnhancedPopup(EnhancedPopup.java:32)
>
> com.typeracer.commons.client.widgets.PopupWithIcon.PopupWithIcon(PopupWithFocusableTextBox.java:28)
>  
>
> com.typeracer.main.client.controller.TyperacerUncaughtExceptionHandler$1.execute(TyperacerUncaughtExceptionHandler.java:55)
>  
>
> com.google.gwt.core.client.impl.SchedulerImpl.runScheduledTasks(SchedulerImpl.java:50)
>  
> etc... :-)
>
>
> instead of the current state of affairs that looks like this:
>
> lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName:  
> http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html 
> stack: @
> http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 
> Rub@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423
>  
> dSb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190
>  
> tA@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 
> Xmb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289
>  
> etc... :-(
>
>
> I am asking the community to support me in finishing this effort and 
> integrating my patch into GWT.  Please take a look and what I've done, and 
> consider making a donation:
>
> http://igg.me/at/gwt-stack-traces/x/3494291
>
> I am an indie developer and I just need some funding to continue this 
> work.  I'm looking for both grassroots and corporate sponsorship for my 
> quest of improving GWT's error reporting and debugging support.
>
> I've written a detailed white paper ( http://goo.gl/YGsrQ ) that 
> describes how my solution works and why it is necessary.  I welcome your 
> feedback!
>
> Thanks!
> Alex
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Development Mode will not be supported in Firefox 27+

[Alex Epshteyn]

As of now, quite sadly, the GWT plugin is no longer supported in the latest 
of versions of Firefox nor Chrome (starting with 35). I've been using GWT 
since 2006, and I think it's a sad state of affairs that after so much work 
went into GWT's OOPHM (a.k.a Development Mode), we're back to Internet 
Explorer being the only browser that can be used for GWT debugging on 
Windows.  I think that SuperDevMode goes against the original do 
everything from your IDE spirit of GWT, but I digress...

The main reason I'm posting this is to describe my workaround to save some 
time for anyone who still wants to use dev mode under Chrome and Firefox 
(which I'm guessing is the majority of the people here):

The hack I came up with (for Windows) was to install portable versions of 
Chromium and Firefox.

Portable Firefox 24: 
http://portableapps.com/apps/internet/firefox-portable-esr
Portable Chromium 35: http://crportable.sourceforge.net/

Then you need to manually install the GWT plugin into Chromium, since it's 
now disabled on the Chrome Web Store:
1. download the file GWT-Developer-Plugin_v1.0.11357.crx from 
http://chrome-extension-downloader.com/ (entering ID number 
jpjpnpmbddbjkfaccnmhnkdgjideieim into the search field)
2. drag and drop the downloaded file into the chrome://extensions/ tab to 
install the plugin

The good thing about this Chromium build is that it seems to be immune from 
Google's auto-updater, but for a limited time, you can also still get 
Google Chrome 35 Portable at 
http://portableapps.com/apps/internet/google_chrome_portable, and follow 
the same procedure for manually installing the GWT plugin.

I'm hoping that this hack will allow many of us to keep using the old dev 
mode for a long time to come, and I'm also hoping that the GWT project 
members will not abandon dev mode support.  

Question for GWT project members: I understand that both FF and Chrome are 
getting rid of the NSAPI, which enabled the GWT plugin.  Are there really 
no other ways to keep supporting dev mode on the latest versions of those 
browsers?  Has anyone looked into Native Client 
(https://developer.chrome.com/native-client)?

Best,
Alex

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Google Chrome 35 GWT plugin incompatibility

[Alex Epshteyn]

Although the GWT plugin for Chrome can no longer be installed from the 
chrome store since version 35, you can still install it manually (at least 
under Windows) and it works just fine.

I posted the instructions here: 
https://groups.google.com/d/msg/google-web-toolkit/QSEjbhhHB4g/tQSwltonVMIJ and 
my post also contains instructions for installing compatible portable 
versions of Firefox and Chromium on Windows, which will allow us to 
continue using the dev mode plugins on those browsers for (hopefully) at 
least a couple more years.

Hope this helps!

On Thursday, May 22, 2014 5:48:01 AM UTC-4, Алексей Волков wrote:

 Chrome just updated to 35.0.1916.114 and thats broke the GWT development 
 plugin stating: Sorry, the GWT Developer Plugin no longer works with Chrome 
 on Linuxccseferf 

 I am running Linux Mint 16 with default depositories and autimatic 
 updates, is it possible to get GWT plugin back to work?



-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

Hi Colin, please find my answers inline:

On Tue, Aug 20, 2013 at 11:35 PM, Colin Alworth niloc...@gmail.com wrote:

 I got a tweet from you asking for a donation (or rather a 'partner', which
 apparently means 'money'), but couldn't frame a useful response in 140
 chars, so since this thread is coming back, I thought to do so here
 instead.


Yes, I wanted to see if Sencha would be interested in funding this project.
 I agree, 140 chars is not enough :)  Just couldn't find your contact info
other than Twitter.

What license are you offering these code samples under - if it isn't
 something open and available, what is the benefit to an advance copy of the
 jar if I, an author of a library and several open source tools and
 applications, cannot provide it to my customers or other downstream users?


That's a good point which I hadn't considered.  I'd be willing to
immediately release the code under the same license as GWT if the project
gets funded.

(For anyone who's just joining this thread now, here's the link to my
project on IndieGoGo: http://igg.me/at/gwt-stack-traces/x/3494291)


 We've found that https://gist.github.com/niloc132/3906501 goes a heck of
 a long ways toward offering optional debug info - if not enabled, the user
 gets the normal-size application with zero size or performance hit, and by
 redirecting to a slightly different url, the full trace info can be pulled
 out (with the quirks you mention of course*), which typically goes a long
 ways toward identifying the real issue.


Yes, and you'd still be able to use that same config with my patch, except
the debug permutation will be much smaller, cleaner, and more accurate.  In
fact, the overhead is so insignificant now, that I have that debug
configuration enabled for all users on my site (typeracer.com).


 * How often have you needed to know which line of Impl.java or
 DOMImpl.java a stack trace intersects? To make your case more effectively,
 you might consider using code where it is meaningful to see those lines,
 something other than the equivelent of
 java.lang.reflect.Method.invoke(Method.java:601). Perhaps some real life
 JSNI, or an annoying IE6-9 focus() or setAttribute issue?


Certainly.  At the time of writing I only had a few artificial examples
available.  But now that I've been gathering real data from my users in
production for a month, I will add an appendix with much better real-world
examples.  I'll update this thread when I finish doing that (most likely
tomorrow).


 You touch briefly on the risk of '[exposing] your application’s
 implementation details', but unless I am mistaken, the extra metadata
 included in the file:line ints should still be enough to take apart an app
 and map it to discrete files and reconstruct methods, even un-inlining (as
 you mention) to pull out clearer details. My understanding was that the
 premise of the sourceMap was to work entirely from the stack to allow the
 actual source to be obfuscated, and avoid any other metadata from being
 left in the compiled output. Combine this with the fact that many of those
 classes are publicly available (GWT itself, etc), and it seems that you
 could reverse out a significant portion of the app - the secret sauce.
 Can you comment on using this for public applications and any reverse
 engineering attempts you've made?


Let me first just clarify how my implementation obfuscates file names (I
think you understood it correctly, but I just want to be sure).  So in my
implementation of stack emulation, the filenames are obfuscated, so you
have strings like '23:234'. The decoding table for this cipher is not
published (it's written as a new file in the same directory as the
symbolMap).  So the only thing that you can reconstruct is that the
obfuscated JavaScript expression X is on line '234' of file '23'.  I
understand that you can use this info to separate the JS output into
discrete files, but I'm just not overly concerned with that, because I
don't think it's that much more helpful to have many obfuscated files with
prettier whitespacing instead of just one lump file.  If necessary, I
suppose you could modify the compiler to add some additional obfuscating
salt to the output.

Thanks for your questions!
Alex

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

Hi Colin, please find my answers inline:

On Tue, Aug 20, 2013 at 11:35 PM, Colin Alworth niloc...@gmail.com wrote:

 I got a tweet from you asking for a donation (or rather a 'partner', which
 apparently means 'money'), but couldn't frame a useful response in 140
 chars, so since this thread is coming back, I thought to do so here
 instead.


Yes, I wanted to see if Sencha would be interested in funding this project.
 I agree, 140 chars is not enough :)  Just couldn't find your contact info
other than Twitter.

What license are you offering these code samples under - if it isn't
 something open and available, what is the benefit to an advance copy of the
 jar if I, an author of a library and several open source tools and
 applications, cannot provide it to my customers or other downstream users?


That's a good point which I hadn't considered.  I'd be willing to
immediately release the code under the same license as GWT if the project
gets funded.

(For anyone who's just joining this thread now, here's the link to my
project on IndieGoGo: http://igg.me/at/gwt-stack-traces/x/3494291)


 We've found that https://gist.github.com/niloc132/3906501 goes a heck of
 a long ways toward offering optional debug info - if not enabled, the user
 gets the normal-size application with zero size or performance hit, and by
 redirecting to a slightly different url, the full trace info can be pulled
 out (with the quirks you mention of course*), which typically goes a long
 ways toward identifying the real issue.


Yes, and you'd still be able to use that same config with my patch, except
the debug permutation will be much smaller, cleaner, and more accurate.  In
fact, the overhead is so insignificant now, that I have that debug
configuration enabled for all users on my site (typeracer.com).


 * How often have you needed to know which line of Impl.java or
 DOMImpl.java a stack trace intersects? To make your case more effectively,
 you might consider using code where it is meaningful to see those lines,
 something other than the equivelent of
 java.lang.reflect.Method.invoke(Method.java:601). Perhaps some real life
 JSNI, or an annoying IE6-9 focus() or setAttribute issue?


Certainly.  At the time of writing I only had a few artificial examples
available.  But now that I've been gathering real data from my users in
production for a month, I will add an appendix with much better real-world
examples.  I'll update this thread when I finish doing that (most likely
tomorrow).


 You touch briefly on the risk of '[exposing] your application’s
 implementation details', but unless I am mistaken, the extra metadata
 included in the file:line ints should still be enough to take apart an app
 and map it to discrete files and reconstruct methods, even un-inlining (as
 you mention) to pull out clearer details. My understanding was that the
 premise of the sourceMap was to work entirely from the stack to allow the
 actual source to be obfuscated, and avoid any other metadata from being
 left in the compiled output. Combine this with the fact that many of those
 classes are publicly available (GWT itself, etc), and it seems that you
 could reverse out a significant portion of the app - the secret sauce.
 Can you comment on using this for public applications and any reverse
 engineering attempts you've made?


Let me first just clarify how my implementation obfuscates file names (I
think you understood it correctly, but I just want to be sure).  So in my
implementation of stack emulation, the filenames are obfuscated, so you
have strings like '23:234'. The decoding table for this cipher is not
published (it's written as a new file in the same directory as the
symbolMap).  So the only thing that you can reconstruct is that the
obfuscated JavaScript expression X is on line '234' of file '23'.  I
understand that you can use this info to separate the JS output into
discrete files, but I'm just not overly concerned with that, because I
don't think it's that much more helpful to have many obfuscated files with
prettier whitespacing instead of just one lump file.  If necessary, I
suppose you could modify the compiler to add some additional obfuscating
salt to the output.

Thanks for your questions!
Alex

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

Hello folks,

I just wanted to remind everyone that the last day to fund this project is 
this Friday, August 23.

I've been using this framework in production in my app now for 2 months, 
and it works great.  Have logged 70,000 perfect stack traces so far! 
 Already fixed 3 major bugs in my GWT-based UI code that I would NEVER 
found otherwise.

Let's get this capability into GWT by the end of the year.  Please donate!

Thanks,
Alex



On Wednesday, July 17, 2013 4:56:40 PM UTC-4, Alex Epshteyn wrote:

 Dear fellow GWT users,

 I would like to announce that I have finally solved what I always thought 
 to be GWT's greatest weakness: its lack of debugging information for 
 client-side exceptions in production.  

 With my patch, your deployed app will be able to report stack traces like 
 this:

 com.google.gwt.core.client.JavaScriptException: (TypeError) : a is null

 com.google.gwt.dom.client.DOMImplMozilla.$getBodyOffsetLeft(DOMImplMozilla.java:145)
  

 com.google.gwt.user.client.ui.PopupPanel.$setPopupPosition(Document.java:1287)

 com.google.gwt.user.client.ui.PopupPanel.setPopupPosition(PopupPanel.java:884)
 com.google.gwt.user.client.ui.PopupPanel.PopupPanel(PopupPanel.java:453) 

 com.typeracer.commons.client.widgets.EnhancedPopup.EnhancedPopup(EnhancedPopup.java:32)

 com.typeracer.commons.client.widgets.PopupWithIcon.PopupWithIcon(PopupWithFocusableTextBox.java:28)
  

 com.typeracer.main.client.controller.TyperacerUncaughtExceptionHandler$1.execute(TyperacerUncaughtExceptionHandler.java:55)
  

 com.google.gwt.core.client.impl.SchedulerImpl.runScheduledTasks(SchedulerImpl.java:50)
  
 etc... :-)


 instead of the current state of affairs that looks like this:

 lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName:  
 http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html 
 stack: @
 http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 
 Rub@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423
  
 dSb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190
  
 tA@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 
 Xmb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289
  
 etc... :-(


 I am asking the community to support me in finishing this effort and 
 integrating my patch into GWT.  Please take a look and what I've done, and 
 consider making a donation:

 http://igg.me/at/gwt-stack-traces/x/3494291

 I am an indie developer and I just need some funding to continue this 
 work.  I'm looking for both grassroots and corporate sponsorship for my 
 quest of improving GWT's error reporting and debugging support.

 I've written a detailed white paper ( http://goo.gl/YGsrQ ) that 
 describes how my solution works and why it is necessary.  I welcome your 
 feedback!

 Thanks!
 Alex


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

Hello folks,

I just wanted to remind everyone that the last day to fund this project is 
this Friday, August 23.

I've been using this framework in production in my app now for 2 months, 
and it works great.  Have logged 70,000 perfect stack traces so far! 
 Already fixed 3 major bugs in my GWT-based UI code that I would NEVER 
found otherwise.

Let's get this capability into GWT by the end of the year.  Please donate!

Thanks,
Alex



On Wednesday, July 17, 2013 4:56:40 PM UTC-4, Alex Epshteyn wrote:

 Dear fellow GWT users,

 I would like to announce that I have finally solved what I always thought 
 to be GWT's greatest weakness: its lack of debugging information for 
 client-side exceptions in production.  

 With my patch, your deployed app will be able to report stack traces like 
 this:

 com.google.gwt.core.client.JavaScriptException: (TypeError) : a is null

 com.google.gwt.dom.client.DOMImplMozilla.$getBodyOffsetLeft(DOMImplMozilla.java:145)
  

 com.google.gwt.user.client.ui.PopupPanel.$setPopupPosition(Document.java:1287)

 com.google.gwt.user.client.ui.PopupPanel.setPopupPosition(PopupPanel.java:884)
 com.google.gwt.user.client.ui.PopupPanel.PopupPanel(PopupPanel.java:453) 

 com.typeracer.commons.client.widgets.EnhancedPopup.EnhancedPopup(EnhancedPopup.java:32)

 com.typeracer.commons.client.widgets.PopupWithIcon.PopupWithIcon(PopupWithFocusableTextBox.java:28)
  

 com.typeracer.main.client.controller.TyperacerUncaughtExceptionHandler$1.execute(TyperacerUncaughtExceptionHandler.java:55)
  

 com.google.gwt.core.client.impl.SchedulerImpl.runScheduledTasks(SchedulerImpl.java:50)
  
 etc... :-)


 instead of the current state of affairs that looks like this:

 lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName:  
 http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html 
 stack: @
 http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 
 Rub@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423
  
 dSb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190
  
 tA@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 
 Xmb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289
  
 etc... :-(


 I am asking the community to support me in finishing this effort and 
 integrating my patch into GWT.  Please take a look and what I've done, and 
 consider making a donation:

 http://igg.me/at/gwt-stack-traces/x/3494291

 I am an indie developer and I just need some funding to continue this 
 work.  I'm looking for both grassroots and corporate sponsorship for my 
 quest of improving GWT's error reporting and debugging support.

 I've written a detailed white paper ( http://goo.gl/YGsrQ ) that 
 describes how my solution works and why it is necessary.  I welcome your 
 feedback!

 Thanks!
 Alex


-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

Alfredo: thanks for your $25 contribution!  I've just emailed you my patch 
along with a small demo project.

Would be great if we could get more people to pitch in with some funding. 
 Any corporate takers?

Johannes: IndieGoGo asked me to come up with perks to offer to people who 
contribute money to the campaign.  I set up a $25 perk that offers my 
patch, and the only thing additional commodity I could offer for bigger 
contributions is my time.  I'm not a consultant and I'm not looking to sell 
any services beyond getting this patched finished up and integrated into 
GWT.


On Wednesday, July 24, 2013 3:31:08 AM UTC-4, Johannes Barop wrote:

 Hi,

 2013/7/23 Alfredo Quiroga-Villamil law...@gmail.com javascript:

 Looking at the donations made so far and obviously at first glance it 
 doesn't look like this work has the significance to many that one might 
 expect. I really feel like the amount of work, complexity of the issue at 
 hand and the overall contribution of the work made by +Alex* *


 I have no problem donating money for real OpenSource efforts. As Stephen 
 noticed: Alex does it wrong. I have the impression that he only want's to 
 sell his consulting services. Besides that other individuals here did 
 much greater work and would deserve the money. 

 -- 
 Johannes Barop - Software Development  Consulting
 Alsterdorfer Straße 573
 DE-22335 Hamburg

 E-Mail: j...@barop.de javascript:
 Phone.: +49 40 807 907 37
 Fax : +49 40 807 907 39
 Mobile: +49 176 491 551 38

 Web: http://www.barop.de

 

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

 I do not think you will get very far trying to ransom your bug fixes. 
 I get that Kickstarter/etc. is great for new/potential projects, but 
 you're basically saying well, I already built/fixed this, but crap, it 
 would have been nice to get paid for it 


I can appreciate how it might seem that way, but I hope you can appreciate 
the fact that I had to actually build it first in order to know if it's 
achievable. 

It's more like I already built this for myself, but I want to raise money 
in order to modify it for general consumption and maintain it thereafter, 
because I don't want to spend so much extra time working on something that 
people don't really care about.


On Saturday, July 20, 2013 1:12:03 AM UTC-4, Stephen Haberman wrote:

 Hi Alex, 

  By the way, who wants to try it?  Please get it touch with me (alex 
  at typeracer.com), and I will email you my patch so you can see for 
  yourself how awesome it is. 

 Instead of emailing a patch, how about just uploading it here: 

 https://gwt-review.googlesource.com/#/ 

 I do not think you will get very far trying to ransom your bug fixes. 

 I get that Kickstarter/etc. is great for new/potential projects, but 
 you're basically saying well, I already built/fixed this, but crap, it 
 would have been nice to get paid for it That's not really how open 
 source works. 

 And, FWIW, if you're serious about crowdsourcing some GWT compiler 
 consulting, I think the GWT moonshot concept would be much sexier and 
 (relatively) more likely to get funded. Granted, it is also more work. 

 - Stephen 



-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

In response to some of the concerns expressed in this thread, I'd like to 
clarify that by using my patch, you will not be making any trade-offs 
versus what you previously had with GWT's old implementation: my patch will 
give you all pros and no cons.

Here's why:

There are two ways to get perfect stack traces in production: 1) via a 
compiler-generated source map file in a browser that provides JS stack 
traces with column numbers (only Chrome right now) and 2) via stack 
emulation for all other browsers.  My project implements both solutions, 
along with lots of improvements to their existing implementations in GWT. 
 So if anyone is already using any of the following: stack emulation, 
symbol maps, source maps, StackTraceDeobfuscator, etc., my patch will make 
those things better for you without requiring you to use other pieces that 
you don't need.  For example, you could configure it to only use solution 
#1: which gives you perfect stack traces for Chrome and doesn't increase 
the size of your code.  Or you could additionally enable solution #2, which 
will cover all the other browsers, with only 45% overhead in code size for 
those other browsers.  Personally, I think that 45% is totally worth it 
(especially compared to the 100% overhead incurred in the original 
solution), and I'm using it in my app, but if you don't want any overhead, 
you can just take the freebie for Chrome and leave the rest as before.

By the way, who wants to try it?  Please get it touch with me (alex at 
typeracer.com), and I will email you my patch so you can see for yourself 
how awesome it is.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

In response to some of the concerns expressed in this thread, I'd like to 
clarify that by using my patch, you will not be making any trade-offs 
versus what you previously had with GWT's old implementation: my patch will 
give you all pros and no cons.

Here's why:

There are two ways to get perfect stack traces in production: 1) via a 
compiler-generated source map file in a browser that provides JS stack 
traces with column numbers (only Chrome right now) and 2) via stack 
emulation for all other browsers.  My project implements both solutions, 
along with lots of improvements to their existing implementations in GWT. 
 So if anyone is already using any of the following: stack emulation, 
symbol maps, source maps, StackTraceDeobfuscator, etc., my patch will make 
those things better for you without requiring you to use other pieces that 
you don't need.  For example, you could configure it to only use solution 
#1: which gives you perfect stack traces for Chrome and doesn't increase 
the size of your code.  Or you could additionally enable solution #2, which 
will cover all the other browsers, with only 45% overhead in code size for 
those other browsers.  Personally, I think that 45% is totally worth it 
(especially compared to the 100% overhead incurred in the original 
solution), and I'm using it in my app, but if you don't want any overhead, 
you can just take the freebie for Chrome and leave the rest as before.

By the way, who wants to try it?  Please get it touch with me (alex at 
typeracer.com), and I will email you my patch so you can see for yourself 
how awesome it is.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

Dear fellow GWT users,

I would like to announce that I have finally solved what I always thought 
to be GWT's greatest weakness: its lack of debugging information for 
client-side exceptions in production.  

With my patch, your deployed app will be able to report stack traces like 
this:

com.google.gwt.core.client.JavaScriptException: (TypeError) : a is null
com.google.gwt.dom.client.DOMImplMozilla.$getBodyOffsetLeft(DOMImplMozilla.java:145)
 
com.google.gwt.user.client.ui.PopupPanel.$setPopupPosition(Document.java:1287)
com.google.gwt.user.client.ui.PopupPanel.setPopupPosition(PopupPanel.java:884)
com.google.gwt.user.client.ui.PopupPanel.PopupPanel(PopupPanel.java:453) 
com.typeracer.commons.client.widgets.EnhancedPopup.EnhancedPopup(EnhancedPopup.java:32)
com.typeracer.commons.client.widgets.PopupWithIcon.PopupWithIcon(PopupWithFocusableTextBox.java:28)
 
com.typeracer.main.client.controller.TyperacerUncaughtExceptionHandler$1.execute(TyperacerUncaughtExceptionHandler.java:55)
 
com.google.gwt.core.client.impl.SchedulerImpl.runScheduledTasks(SchedulerImpl.java:50)
 
etc... :-)


instead of the current state of affairs that looks like this:

lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName: 
 http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html 
stack: 
@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 
Rub@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423 
dSb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190 
tA@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 
Xmb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289 
etc... :-(


I am asking the community to support me in finishing this effort and 
integrating my patch into GWT.  Please take a look and what I've done, and 
consider making a donation:

http://igg.me/at/gwt-stack-traces/x/3494291

I am an indie developer and I just need some funding to continue this work. 
 I'm looking for both grassroots and corporate sponsorship for my quest of 
improving GWT's error reporting and debugging support.

I've written a detailed white paper ( http://goo.gl/YGsrQ ) that describes 
how my solution works and why it is necessary.  I welcome your feedback!

Thanks!
Alex

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

Thanks for all your questions.  Here are my answers.

So, something like this has been used at least internally for quite a long 
 time -- what exactly did you have to change in StackTraceDeobfuscator?

 
Quite a few things, actually.  I go into great detail about that, including 
diffs of some stack traces, in my paper: http://goo.gl/YGsrQ  In short, my 
solution is prettier, more efficient, and more accurate than what you've 
been using.

I'm not sure that's going to be worth using in a performance-sensitive 
 application.  Also, how much does this affect compilation time?


Performance was critical to my application as well, and that's why I put in 
a lot of extra effort to make my solution almost 50% more efficient than my 
predecessor's work.  I'm already using it in production on typeracer.com. 
 You can visit my site and see that it's very fast.

The impact on compilation time is negligible (less than 1 second per 
permutation).

Do you plan to maintain that code if it is integrated into GWT or will it 
 be a one time contribution and other people have to wrap their head around 
 it again if your solution needs to be adjusted? 


Yes, I will maintain the code regardless, even if it doesn't get integrated 
into GWT, because my app is already using it in production, and I consider 
it of high importance to my business.  If my project gets funded, then I 
will work on integrating it into GWT and maintaining that code thereafter. 
 Otherwise, if there's not enough interest from the community, I'm not sure 
I'll bother integrating it.  Either way, my work is pretty self-contained 
and only touches a handful of existing classes: JsStackEmulator, 
StackTraceDeobfuscator, and StackTraceCreator.
 

 I ask this because GWT will drop support for IE6/7 relatively soon and 
 probably by the end of 2014 drop support for IE8. Also Opera has switched 
 to Blink/V8 which makes the opera permutation obsolete in the near future. 
 So by the end of 2014 (GWT 3.x) Firefox, Safari, Chrome and Opera are 
 likely to support SourceMaps and in case of IE9+ stack trace emulation is 
 probably not needed.


In addition to fixing and optimizing stack emulation, my code makes lots of 
improvements to the SourceMaps-based approach as well.  That said, right 
now, only one browser supports SourceMaps-based stack traces.  Let me be 
clear: my project is not about just any one solution, like stack emulation 
or SourceMaps: it's to make perfect Java stack traces available in any 
browser that can run your GWT app.  My code lays the foundation to make 
that happen with minimal future effort, even as browsers evolve.
 

 So by the end of next year a bunch of your code can probably be deleted 
 and other code refactored/optimized to fit this situation. Have you thought 
 about that?


I don't think any of my code will have to be deleted.  I've introduced a 
selection property that selects whether the browser supports the 
SourceMaps-based stack traces or not, and introduces stack emulation only 
if needed.  Otherwise, it uses the SourceMaps-optimized solution, which 
carries no overhead.

What sort of approach does the current emulated stack implementation use, 
 as opposed to the suggested function enter/exit approach?  Is there a 
 relative speed hit involved with it too?  


My approach to stack emulation is the same as before, just more accurate 
and more optimized.  The cool thing is that in Chrome and any future 
browsers which provide both line and column numbers in Javascript stack 
traces, my code will give you perfect equivalent Java stack traces with 
absolutely no performance penalty (you can read about how it works in my 
paper: http://goo.gl/YGsrQ )

Because if so, bring on the new implementation ASAP :)


I'm hoping to!   Please consider making a donation and spread the word 
about my campaign: http://igg.me/at/gwt-stack-traces/x/3494291 :)

Thanks guys.  Any other questions?   (I'm really excited to be having this 
discussion with all of you, after working on it in isolation for so long).

- Alex Epshteyn



On Wednesday, July 17, 2013 10:48:02 PM UTC-4, mark.e...@gmail.com wrote:

 If you use emulated stack traces (including line numbers) in current GWT 
 your app size will roughly increase by 100%. So 45% is a lot better of what 
 GWT gives you today.


 ...

 Really.  I had not seen that mentioned anywhere.  What sort of approach 
 does the current emulated stack implementation use, as opposed to the 
 suggested function enter/exit approach?  Is there a relative speed hit 
 involved with it too?  Because if so, bring on the new implementation ASAP 
 :)
  

 On Wednesday, July 17, 2013 7:54:28 PM UTC-4, Jens wrote:


 I certainly applaud the obvious time, effort, and care that you've put 
 into these improvements, but 45% size and 22-44% execution speed overhead 
 sounds like a rather painful penalty to pay.  I'm not sure that's going to 
 be worth using in a performance-sensitive application.


 If you use emulated

[gwt-contrib] I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

Dear fellow GWT users,

I would like to announce that I have finally solved what I always thought 
to be GWT's greatest weakness: its lack of debugging information for 
client-side exceptions in production.  

With my patch, your deployed app will be able to report stack traces like 
this:

com.google.gwt.core.client.JavaScriptException: (TypeError) : a is null
com.google.gwt.dom.client.DOMImplMozilla.$getBodyOffsetLeft(DOMImplMozilla.java:145)
 
com.google.gwt.user.client.ui.PopupPanel.$setPopupPosition(Document.java:1287)
com.google.gwt.user.client.ui.PopupPanel.setPopupPosition(PopupPanel.java:884)
com.google.gwt.user.client.ui.PopupPanel.PopupPanel(PopupPanel.java:453) 
com.typeracer.commons.client.widgets.EnhancedPopup.EnhancedPopup(EnhancedPopup.java:32)
com.typeracer.commons.client.widgets.PopupWithIcon.PopupWithIcon(PopupWithFocusableTextBox.java:28)
 
com.typeracer.main.client.controller.TyperacerUncaughtExceptionHandler$1.execute(TyperacerUncaughtExceptionHandler.java:55)
 
com.google.gwt.core.client.impl.SchedulerImpl.runScheduledTasks(SchedulerImpl.java:50)
 
etc... :-)


instead of the current state of affairs that looks like this:

lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName: 
 http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html 
stack: 
@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 
Rub@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423 
dSb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190 
tA@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 
Xmb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289 
etc... :-(


I am asking the community to support me in finishing this effort and 
integrating my patch into GWT.  Please take a look and what I've done, and 
consider making a donation:

http://igg.me/at/gwt-stack-traces/x/3494291

I am an indie developer and I just need some funding to continue this work. 
 I'm looking for both grassroots and corporate sponsorship for my quest of 
improving GWT's error reporting and debugging support.

I've written a detailed white paper ( http://goo.gl/YGsrQ ) that describes 
how my solution works and why it is necessary.  I welcome your feedback!

Thanks!
Alex

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

[Alex Epshteyn]

Thanks for all your questions.  Here are my answers.

So, something like this has been used at least internally for quite a long 
 time -- what exactly did you have to change in StackTraceDeobfuscator?

 
Quite a few things, actually.  I go into great detail about that, including 
diffs of some stack traces, in my paper: http://goo.gl/YGsrQ  In short, my 
solution is prettier, more efficient, and more accurate than what you've 
been using.

I'm not sure that's going to be worth using in a performance-sensitive 
 application.  Also, how much does this affect compilation time?


Performance was critical to my application as well, and that's why I put in 
a lot of extra effort to make my solution almost 50% more efficient than my 
predecessor's work.  I'm already using it in production on typeracer.com. 
 You can visit my site and see that it's very fast.

The impact on compilation time is negligible (less than 1 second per 
permutation).

Do you plan to maintain that code if it is integrated into GWT or will it 
 be a one time contribution and other people have to wrap their head around 
 it again if your solution needs to be adjusted? 


Yes, I will maintain the code regardless, even if it doesn't get integrated 
into GWT, because my app is already using it in production, and I consider 
it of high importance to my business.  If my project gets funded, then I 
will work on integrating it into GWT and maintaining that code thereafter. 
 Otherwise, if there's not enough interest from the community, I'm not sure 
I'll bother integrating it.  Either way, my work is pretty self-contained 
and only touches a handful of existing classes: JsStackEmulator, 
StackTraceDeobfuscator, and StackTraceCreator.
 

 I ask this because GWT will drop support for IE6/7 relatively soon and 
 probably by the end of 2014 drop support for IE8. Also Opera has switched 
 to Blink/V8 which makes the opera permutation obsolete in the near future. 
 So by the end of 2014 (GWT 3.x) Firefox, Safari, Chrome and Opera are 
 likely to support SourceMaps and in case of IE9+ stack trace emulation is 
 probably not needed.


In addition to fixing and optimizing stack emulation, my code makes lots of 
improvements to the SourceMaps-based approach as well.  That said, right 
now, only one browser supports SourceMaps-based stack traces.  Let me be 
clear: my project is not about just any one solution, like stack emulation 
or SourceMaps: it's to make perfect Java stack traces available in any 
browser that can run your GWT app.  My code lays the foundation to make 
that happen with minimal future effort, even as browsers evolve.
 

 So by the end of next year a bunch of your code can probably be deleted 
 and other code refactored/optimized to fit this situation. Have you thought 
 about that?


I don't think any of my code will have to be deleted.  I've introduced a 
selection property that selects whether the browser supports the 
SourceMaps-based stack traces or not, and introduces stack emulation only 
if needed.  Otherwise, it uses the SourceMaps-optimized solution, which 
carries no overhead.

What sort of approach does the current emulated stack implementation use, 
 as opposed to the suggested function enter/exit approach?  Is there a 
 relative speed hit involved with it too?  


My approach to stack emulation is the same as before, just more accurate 
and more optimized.  The cool thing is that in Chrome and any future 
browsers which provide both line and column numbers in Javascript stack 
traces, my code will give you perfect equivalent Java stack traces with 
absolutely no performance penalty (you can read about how it works in my 
paper: http://goo.gl/YGsrQ )

Because if so, bring on the new implementation ASAP :)


I'm hoping to!   Please consider making a donation and spread the word 
about my campaign: http://igg.me/at/gwt-stack-traces/x/3494291 :)

Thanks guys.  Any other questions?   (I'm really excited to be having this 
discussion with all of you, after working on it in isolation for so long).

- Alex Epshteyn



On Wednesday, July 17, 2013 10:48:02 PM UTC-4, mark.e...@gmail.com wrote:

 If you use emulated stack traces (including line numbers) in current GWT 
 your app size will roughly increase by 100%. So 45% is a lot better of what 
 GWT gives you today.


 ...

 Really.  I had not seen that mentioned anywhere.  What sort of approach 
 does the current emulated stack implementation use, as opposed to the 
 suggested function enter/exit approach?  Is there a relative speed hit 
 involved with it too?  Because if so, bring on the new implementation ASAP 
 :)
  

 On Wednesday, July 17, 2013 7:54:28 PM UTC-4, Jens wrote:


 I certainly applaud the obvious time, effort, and care that you've put 
 into these improvements, but 45% size and 22-44% execution speed overhead 
 sounds like a rather painful penalty to pay.  I'm not sure that's going to 
 be worth using in a performance-sensitive application.


 If you use emulated

Re: Exception reporting is broken in GWT: would you support a kickstarter project to fix it?

[Alex Epshteyn]

Hi Thomas,

Thanks for chiming in and providing the extra info.  Good to know.

I'd like to ask, however, the reasons for planning to remove support for
IE6/7/8?  Why would we do that?  It's already there and doesn't require too
much maintenance.

As of today, nearly 8% of my site's visitors are on IE8 and close to 1% are
still on IE7.  These are pretty big numbers for a high traffic website, and
would translate into lost revenue if the browsers weren't supported.  I
can't imagine Google pulling support for a browser with that kind of usage
for one of its products. .  Here's the full data:
https://docs.google.com/spreadsheet/ccc?key=0AvMlWdpkpAA6dGdpa3lsZTVQWl9qcFJrWmZCZ0ZZb0E#gid=0

Also, as you guys can see from the data, stack emulation is still required
for 54% of my site's traffic.

While I'd like to see users upgrading to the latest browsers as much as any
developer, let's be realistic: WinXP is not going away any time soon
(Microsoft dropping support for it isn't going to make people like my dad
go out and buy a new computer).  Google Analytics is shows that 80% of my
users are on Windows and 21% of those are still on Windows XP: that is a
very big number!



On Thu, May 23, 2013 at 5:13 AM, Thomas Broyer t.bro...@gmail.com wrote:



 On Wednesday, May 22, 2013 11:53:47 PM UTC+2, Alex Epshteyn wrote:

 Thanks for your comment.  Let me respond to your points:

 1) I've seen this point discussed before, and the standard
 counter-argument is that the spirit of OSS is free as in freedom, not
 beer.  Lots of developers get paid to work on OSS projects.

 2) This is actually one of the reasons I'm thinking about raising funds.
  I am already on the verge of using my patch inside my own GWT-based app,
 but if I get some funding I'd be able to justify taking the extra time to
 make sure the patch will pass the review process.


 +1 to those 2 points.


  3) I must point out that your third argument is not in the spirit of
 GWT, which aims to support as many browsers as possible.


 That's not entirely true. GWT only ever supported the 4 major browser
 engines: Trident (IE), WebKit (SquirrelFish / V8; aka Safari / Chromium),
 Gecko (Firefox) and Presto (Opera).

 Jens is right: we'll soon remove support for IE6 and 7, and then for IE8
 (not long after MS drops support for WinXP).
 GWT never really supported Opera, and the level of support was only
 against the latest version. Now that Opera is moving from Presto to
 Chromium, that means one less platform to support in the very near future
 (by the next GWT release, but we'll probably keep the opera permutation
 along for one more release).

 As of today, you will not get good stack traces with GWT on any modern
 browser, including WebKit.  By relevant information, I assume you mean
 sourcemaps support.  Well, Chrome is the only browser that currently
 supports sourcemaps but GWT's existing support for generating stack traces
 with that information is very buggy, and this is one of the things I'm
 working on improving.  I'm also not optimistic that sourcemaps will achieve
 universal support any time soon, if ever.


 Chromium has it for a while (hence Chrome –all platforms–, Opera for
 Android –though what matters is the remote debugger, not the browser– and
 Opera.next), and Firefox is starting to roll it out [1,2] in 23 (currently
 Aurora channel) and I'm told the next Safari should have it too [3].
 Will IE ever have it? I believe so, particularly now that MS is pushing
 languages that compile to JS (TypeScript, which can generate sourcemaps).
 Obviously that would only be available in IE11 (or later), but it seems
 like it would be possible to have support in your IDE with the help of an
 IE plugin [4] for IE8/9/10 (would it work in Windows 8 though?)

 That said, source maps support in the browser is related to, but different
 from stack trace resymbolization.

 [1]
 https://hacks.mozilla.org/2013/05/firefox-developer-tool-features-for-firefox-23/
 [2]
 https://hacks.mozilla.org/2013/05/compiling-to-javascript-and-debugging-with-source-maps/
 [3]
 http://stackoverflow.com/questions/16446114/is-it-possible-to-enable-javascript-source-maps-in-safari-6
 [4] http://wiki.eclipse.org/JSDT/Debug/IE

 --
 You received this message because you are subscribed to a topic in the
 Google Groups Google Web Toolkit group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/google-web-toolkit/hP8cQ7AdDUc/unsubscribe?hl=en
 .
 To unsubscribe from this group and all its topics, send an email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email

Re: Exception reporting is broken in GWT: would you support a kickstarter project to fix it?

[Alex Epshteyn]

Fair enough, but I'm curious to know why leaving the code that supports
legacy browsers would interfere with implementing new features.  For
example, if you want to implement a new widget called XPanel, it think it's
perfectly fine to say that this widget doesn't support IE6/7/8, and leave
it up to userland to chose whether to use the new widget and how to work
around it for new browsers.

Do you have a specific example?  I'm curious.


On Thu, May 23, 2013 at 5:54 PM, Jens jens.nehlme...@gmail.com wrote:

 To simplify the code base and moving on (HTML 5) I would say.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Exception reporting is broken in GWT: would you support a kickstarter project to fix it?

[Alex Epshteyn]

One of the big problems with deployed GWT apps has always been the
impossibility of tracing JavaScript exceptions back to the Java source
code.  What we need is a true equivalent of Java stack traces.

There was an effort made by the GWT team a couple years ago to solve
this problem ( 
https://code.google.com/p/google-web-toolkit/wiki/WebModeExceptions
), and it was a good start, but unfortunately they gave up without
producing an adequate solution. If you've ever tried to use the
compiler.emulatedStack.recordLineNumbers setting, you know that it is
badly broken: the line numbers and file names reported in the stack
traces are incorrect most of the time, while the the resulting
compiled JavaScript is 70-90% larger than the original.  The way this
feature is currently implemented, the compiler puts instrumentations
in the wrong places most of the time, doesn't do enough to optimize
for code size, and does not provide enough information via symbol maps
for StackTraceDeobfuscator.  On Chrome, theoretically we could use
compiler.useSourceMaps instead, but that feature is badly broken too.

I have spent the last 2 months working on this problem full time, and
I almost have the perfect solution ready.  But I'm an indie developer,
and I can't really afford to go unpaid much longer, because I've
already put business aside for two months to work on this (originally
I thought it would take a week, but I kept finding more and more bugs
and tricky problems to solve, which is why I'm guessing the original
developers gave up on seeing this project through to fruition).

If I started a crowdfunding campaign to help me fund this work to
completion, would you or your employer be willing to contribute?  The
original Google Atlanta team did an amazing job developing GWT for 10+
years, but those guys are all gone, and Google has not had a dedicated
team working on GWT since last summer, so I think it will be up to the
user community to fund its future development from now on.

My goal is perfect JavaScript stack traces with exact Java line
numbers, with only a 50-60% output size increase and similar
performance metrics.  For browsers that support sourcemaps (only
Chrome for now), there will be no output size increase at all, because
I intend to fix all the bugs associated with the
compiler.useSourceMaps feature as well.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Exception reporting is broken in GWT: would you support a kickstarter project to fix it?

[Alex Epshteyn]

Thanks for your comment.  Let me respond to your points:

1) I've seen this point discussed before, and the standard counter-argument
is that the spirit of OSS is free as in freedom, not beer.  Lots of
developers get paid to work on OSS projects.

2) This is actually one of the reasons I'm thinking about raising funds.  I
am already on the verge of using my patch inside my own GWT-based app, but
if I get some funding I'd be able to justify taking the extra time to make
sure the patch will pass the review process.

3) I must point out that your third argument is not in the spirit of GWT,
which aims to support as many browsers as possible.

As of today, you will not get good stack traces with GWT on any modern
browser, including WebKit.  By relevant information, I assume you mean
sourcemaps support.  Well, Chrome is the only browser that currently
supports sourcemaps but GWT's existing support for generating stack traces
with that information is very buggy, and this is one of the things I'm
working on improving.  I'm also not optimistic that sourcemaps will achieve
universal support any time soon, if ever.



On Wed, May 22, 2013 at 4:38 PM, Jens jens.nehlme...@gmail.com wrote:

 I dont think you will get paid for it, because:

 1.) Its somewhat not in the spirit of open source software
 2.) Your patch must go through review and there is no guarantee that it
 will be committed
 3.) GWT will remove IE6/7 support soon and probably in 2014 also IE8
 support. Also Opera moves to WebKit. That means that there is probably no
 need for StackTrace emulation anymore in the near future as modern browsers
 provide the relevant information.

 -- J.

 --
 You received this message because you are subscribed to a topic in the
 Google Groups Google Web Toolkit group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/google-web-toolkit/hP8cQ7AdDUc/unsubscribe?hl=en
 .
 To unsubscribe from this group and all its topics, send an email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Exception reporting is broken in GWT: would you support a kickstarter project to fix it?

[Alex Epshteyn]

Correction: when I said that a browser needs to support sourcemaps to
generate accurate stack traces, that wasn't entirely accurate.  What a
browser needs to support is the stack property of exception objects,
which provides a JavaScript stack trace with both line and column numbers.
 It's the GWT compiler that uses a sourcemap to derive original Java line
numbers and filenames from the browser-provided line and column numbers.
 This functionality is currently broken in GWT, however, and Chrome is
currently the only browser that provides column numbers.  And even if more
browsers add column info in the future, it's almost certain that their
stack trace formats will all be different, so we'll have to patch GWT every
time a new browser adds the support.  My proposed project will leave us in
good shape to be able to do that easily.


On Wed, May 22, 2013 at 5:53 PM, Alex Epshteyn alexander.epsht...@gmail.com
 wrote:

 Thanks for your comment.  Let me respond to your points:

 1) I've seen this point discussed before, and the standard
 counter-argument is that the spirit of OSS is free as in freedom, not
 beer.  Lots of developers get paid to work on OSS projects.

 2) This is actually one of the reasons I'm thinking about raising funds.
  I am already on the verge of using my patch inside my own GWT-based app,
 but if I get some funding I'd be able to justify taking the extra time to
 make sure the patch will pass the review process.

 3) I must point out that your third argument is not in the spirit of GWT,
 which aims to support as many browsers as possible.

 As of today, you will not get good stack traces with GWT on any modern
 browser, including WebKit.  By relevant information, I assume you mean
 sourcemaps support.  Well, Chrome is the only browser that currently
 supports sourcemaps but GWT's existing support for generating stack traces
 with that information is very buggy, and this is one of the things I'm
 working on improving.  I'm also not optimistic that sourcemaps will achieve
 universal support any time soon, if ever.



 On Wed, May 22, 2013 at 4:38 PM, Jens jens.nehlme...@gmail.com wrote:

 I dont think you will get paid for it, because:

 1.) Its somewhat not in the spirit of open source software
 2.) Your patch must go through review and there is no guarantee that it
 will be committed
 3.) GWT will remove IE6/7 support soon and probably in 2014 also IE8
 support. Also Opera moves to WebKit. That means that there is probably no
 need for StackTrace emulation anymore in the near future as modern browsers
 provide the relevant information.

 -- J.

 --
 You received this message because you are subscribed to a topic in the
 Google Groups Google Web Toolkit group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/google-web-toolkit/hP8cQ7AdDUc/unsubscribe?hl=en
 .
 To unsubscribe from this group and all its topics, send an email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Linker bug with useSourceMaps

[Alex Epshteyn]

I'm trying to fix a bug ( 
https://code.google.com/p/google-web-toolkit/issues/detail?id=8100
), and I could use some expert advice.  I'm a long time GWT user (7
years), but only recently started hacking the internals, and I need
help on this one.

Background:

SelectionScriptLinker.splitPrimaryJavaScript attempts to check whether
the property compiler.useSourceMaps is true and if it is, the
method avoids splitting the javascript into chunks (which would
destroy the accuracy of the line numbers in the source map).

The Problem:

This method tries to get the property value from
LinkerContext.getProperties, which is not a PropertyOracle, and hence
it can't return the correct property value for the current
permutation.  In fact, it will return a null value unless the property
has a static value for all permutations (e.g. set-property
name=compiler.useSourceMaps value=true/)

However, something like

  set-property name=compiler.useSourceMaps value=true
when-property-is name=user.agent value=safari/
  /set-property

will not work because SelectionScriptLinker.splitPrimaryJavaScript can
only read static property values.

Could someone advise me on how to fix this bug?

Here's is there relevant source code for quick reference:

  public static String splitPrimaryJavaScript(StatementRanges ranges,
String js,
  int charsPerChunk, String scriptChunkSeparator, LinkerContext
context) {
boolean useSourceMaps = false;
for (SelectionProperty prop : context.getProperties()) {
  if (USE_SOURCE_MAPS_PROPERTY.equals(prop.getName())) {
String str = prop.tryGetValue();
useSourceMaps = str == null ? false :
Boolean.parseBoolean(str);
break;
  }
}

// TODO(cromwellian) enable chunking with sourcemaps
if (charsPerChunk  0 || ranges == null || useSourceMaps) {
  return js;
}
...

-- 
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] Re: Linker bug with useSourceMaps

[Alex Epshteyn]

Okay, I found a pretty good solution. Solved the problem by adding a
method isSourceMapsEnabled to CompilationResult, which gets passed all
the way from Link to SelectionScriptLinker.  The value is set in Link
via the permutation's property oracles.  I tested this and it works
well!

Now, how can I contribute this patch?  Long time user, first time
contributor.  I signed the CLA many years ago, but haven't submitted
anything until now.

Are the instructions on 
https://developers.google.com/web-toolkit/makinggwtbetter
still valid?

I'm a little confused because that document says Upload the patch to
the Rietveld instance at http://gwt-code-reviews.appspot.com/; whereas
I'm seeing all the messages in this group coming from a system called
Gerrit at https://gwt-review.googlesource.com/



On Apr 10, 2:39 am, Alex Epshteyn alexander.epsht...@gmail.com
wrote:
 I'm trying to fix a bug 
 (https://code.google.com/p/google-web-toolkit/issues/detail?id=8100
 ), and I could use some expert advice.  I'm a long time GWT user (7
 years), but only recently started hacking the internals, and I need
 help on this one.

 Background:

 SelectionScriptLinker.splitPrimaryJavaScript attempts to check whether
 the property compiler.useSourceMaps is true and if it is, the
 method avoids splitting the javascript into chunks (which would
 destroy the accuracy of the line numbers in the source map).

 The Problem:

 This method tries to get the property value from
 LinkerContext.getProperties, which is not a PropertyOracle, and hence
 it can't return the correct property value for the current
 permutation.  In fact, it will return a null value unless the property
 has a static value for all permutations (e.g. set-property
 name=compiler.useSourceMaps value=true/)

 However, something like

   set-property name=compiler.useSourceMaps value=true
     when-property-is name=user.agent value=safari/
   /set-property

 will not work because SelectionScriptLinker.splitPrimaryJavaScript can
 only read static property values.

 Could someone advise me on how to fix this bug?

 Here's is there relevant source code for quick reference:

   public static String splitPrimaryJavaScript(StatementRanges ranges,
 String js,
       int charsPerChunk, String scriptChunkSeparator, LinkerContext
 context) {
     boolean useSourceMaps = false;
     for (SelectionProperty prop : context.getProperties()) {
       if (USE_SOURCE_MAPS_PROPERTY.equals(prop.getName())) {
         String str = prop.tryGetValue();
         useSourceMaps = str == null ? false :
 Boolean.parseBoolean(str);
         break;
       }
     }

     // TODO(cromwellian) enable chunking with sourcemaps
     if (charsPerChunk  0 || ranges == null || useSourceMaps) {
       return js;
     }
 ...

-- 
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Linker bug with useSourceMaps

[Alex Epshteyn]

Gotcha.  I will certainly have more than one patch to contribute now that
I've really dived into the GWT compiler internals, so I might as well start
working with the new git-based system to make things easier for everyone.
 I've already made quite a few other enhancements and bug fixes to the
whole web mode exceptions reporting toolchain, which are going into the
next release of my product, TypeRacer, and I'm eager to contribute those
back to GWT.  I'll probably write up a blog post about my experiments and
enhancements in the coming weeks.

Anyways, could you guys provide me with some command line examples of the
whole process using git, starting from checking out the code to submitting
a patch for review?  Thanks in advance.  I'm eager to get started!


On Wed, Apr 10, 2013 at 3:39 PM, Matthew Dempsky mdemp...@google.comwrote:

 On Wed, Apr 10, 2013 at 12:22 PM, Alex Epshteyn 
 alexander.epsht...@gmail.com wrote:

 Thanks Thomas!  Is it possible to still use SVN by any chance?


 We'll continue accepting patches from Rietveld, just it's a bit more work
 for us to merge them.

 --
 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups Google Web Toolkit Contributors group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/google-web-toolkit-contributors/QaHTo59D_GY/unsubscribe?hl=en
 .
 To unsubscribe from this group and all its topics, send an email to
 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Linker bug with useSourceMaps

[Alex Epshteyn]

Thanks Thomas!  I appreciate it.  I'll give it a try!



On Wed, Apr 10, 2013 at 5:01 PM, Thomas Broyer t.bro...@gmail.com wrote:



 On Wednesday, April 10, 2013 9:22:18 PM UTC+2, Alex Epshteyn wrote:

 Thanks Thomas!  Is it possible to still use SVN by any chance? I haven't
 made the leap over to git yet as I'm still using an older version of
 IntelliJ without git support. If not, could you help me out with some
 command-line examples of how to submit my patch using git and Gerrit.


 It's actually rather easy (this is for Linux/Mac, adapt for Windows if
 needed):

1. svn checkout http://google-web-toolkit.googlecode.com/svn/tools/tools/  
  # dependencies are here until we move to Maven
2. git clone https://gwt.googlesource.com/gwt
3. cd gwt
4. One-time setup specific to Gerrit: download
https://gwt-review.googlesource.com/tools/hooks/commit-msg into
.git/hooks/commit-msg and make sure the file is executable (chmod +x)
5. You're ready to hack; below is standard Git:
   1. git checkout -b feature-branche master   # create a
   branch off of master for your feature
   You'll then use git branch to list your branches, and git
   checkout my-branch to switch branches.
   2. …hack hack hack…
   3. Use git status, git add and git commit to commit your files (add
   --help for help); or try git gui or git citool for a GUI (that's 
 what I
   use)
   With Gerrit, each commit will be reviewed independently, so unless
   you really mean to have 2 commits, you'll git commit --amend your one 
 and
   only commit for a given feature/fix (first create a commit with git
   commit, then if you need to update it, use git commit --amend). Only 
 use
   this locally (before you git push, see below) or when working with
   commits under review in Gerrit. Updating a review is just a matter of
   amending the commit and pushing it again.
6. To push your commit for review: git push origin
feature-branch:refs/for/master
If you're on the feature-branch, your can also use git push origin
HEAD:refs/for/master (HEAD corresponds to the currently checked out
commit); refs/for/master means this is intended to be merged into master
Note: you'll have to generate a password from the Gerrit web UI to be
able to push.
7. Last, but not least, to stay up-to-date:
   1. git checkout master
   2. git pull
   3. Note: do only ever git pull when on the master branch.
   4. If you need update a branch to a newer master (because there's
   been changes that would conflict with your changes)
  1. git checkout my-branch
  2. git rebase master
  Git will tell you if there are conflicts and should tell you
  what to do. Hint: git mergetool to resolve conflicts, then git 
 rebase
  --continue when done.
   8. Once your change has been merged (or if you want to delete your
work):
   1. git branch -D my-branch# generally done from master

  --
 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups Google Web Toolkit Contributors group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/google-web-toolkit-contributors/QaHTo59D_GY/unsubscribe?hl=en
 .
 To unsubscribe from this group and all its topics, send an email to
 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gwt-contrib] RPC payload question: Why use fully qualified class names?

[Alex Epshteyn]

Hi guys,

I'm sorry I'm not up-to-date on recent GWT development efforts, but
does the current version of the GWT-RPC serialization scheme still use
fully qualified class names in the payload string? (e.g.
com.example.foo.Foo in the method signature part of the payload, and
then again as com.example.foo.Foo/12345 in the argument part of the
payload.

If so, then I bet payload sizes can be reduced dramatically by using a
lookup table for class names.  I'd be willing to work on a patch of
this.

Once again, I apologize if this has already been addressed (my company
still uses GWT 1.5).

Thanks,
Alex

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

Re: How to override module stylesheet definitions

[Alex Epshteyn]

Thanks Fred, I think the easiest solution is to wait for 2.0

On Mon, Aug 31, 2009 at 3:44 PM, Fred Sauerfre...@google.com wrote:
 As a heads up, if you build gwt-dnd from trunk (which requires using GWT 2.0
 features form trunk) the stylesheet in injected via StyleInjector which
 avoids the extra HTTP round trip for gwt-dnd.css incurred by the stylesheet
 src=.../ configuration you mention below.
 Hope that helps.
 Fred

 On Mon, Aug 17, 2009 at 10:39 PM, Alex Epshteyn
 alexander.epsht...@gmail.com wrote:

 Surprisingly was unable to find any prior discussions about this...

 I'm optimizing my app's load time by merging all my stylesheets into a
 single CSS file (then minifying it with YUI compressor), to reduce the
 number of HTTP requests.  I'd like to also concatenate all the
 stylesheets from third party libraries I'm using into this single CSS
 file, but don't see a way to undefine the stylesheet module XML
 elements in these third party modules.

 For example, I'm using Fred Sauer's gwt-dnd library, whose module XML
 contains

 stylesheet src=gwt-dnd.css/

 This line instructs the browser to request gwt-dnd.css when this
 module is loaded, but I don't want this to happen.

 Any ideas?




 --
 Fred Sauer
 Developer Advocate
 Google Inc.
 1600 Amphitheatre Parkway
 Mountain View, CA 94043
 fre...@google.com



 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en
-~--~~~~--~~--~--~---

How to override module stylesheet definitions

[Alex Epshteyn]

Surprisingly was unable to find any prior discussions about this...

I'm optimizing my app's load time by merging all my stylesheets into a
single CSS file (then minifying it with YUI compressor), to reduce the
number of HTTP requests.  I'd like to also concatenate all the
stylesheets from third party libraries I'm using into this single CSS
file, but don't see a way to undefine the stylesheet module XML
elements in these third party modules.

For example, I'm using Fred Sauer's gwt-dnd library, whose module XML
contains

stylesheet src=gwt-dnd.css/

This line instructs the browser to request gwt-dnd.css when this
module is loaded, but I don't want this to happen.

Any ideas?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

[gwt-contrib] Re: I've implemented Java stack trace support for web mode

[Alex Epshteyn]

Jay, I've been using this code in production since early June.  Works
well.  I'm still using 1.5 for that particular project, but there's no
reason it wouldn't work with 1.6, because the code isn't even aware of
GWT, so it's agnostic of versions.

Not ready to release publicly yet, but if you really want it, email me
off-forum.

Alex

On Thu, Jul 2, 2009 at 12:33 PM, jayjay.gin...@gmail.com wrote:

 Did anything come of this? Alex -- does your approach work with GWT
 1.6? And, have you decided to contribute this anywhere? I'll
 understand if you aren't willing, but I figured it can't hurt to ask.

 jay

 On May 7, 1:24 pm, Alex Epshteyn alexander.epsht...@gmail.com wrote:
 Hi Bob,

  Could you provide some numbers in terms of raw and gzipped
  before/after bytes?

 This is the OBF compiled js size of a TypeRacer module before and
 after instrumentation (raw/gz): 382/118 vs. 505/142 which can be
 further reduced by using shortened identifiers instead of method name
 strings (it doesn't make much difference when gzipped, though).

 In terms of inlining, I've implemented the optimization of not
 instrumenting simple getters and setters, which are guaranteed not to
 raise an exception.  Everything else will probably not be eligible for
 inlining.  But I do provide an annotation which you can use to exclude
 your hot methods from instrumentation.

  I looked at implementing perfect stack traces as an AST visitor, but
  decided that the size cost, speed cost for inlining, and potential
  data-leakage for large apps would outweigh the marginal gain of having
  line-level resolution in deployed apps.

 I'm not sure if that's necessarily the case. However, the capability
 you've implemented may very well be sufficient.  I'm looking forward
 to testing out your code when I have more time.

  Those tradeoffs do make sense
  for development and QA versions of an app, but there was only a
  limited amount of time allocated for implementing stack traces.

 Yes, I can tell you from experience that what I did was pretty hairy
 and definitely took a good amount of time.  There are lots of corner
 cases to consider when rewriting a Java AST, as you probably know.
 Just to give a tiny example - you can't insert anything before a
 super() statement.  But at this point I have them all covered.

 I'm not yet sure if I'll be open-sourcing my code.  I need to support
 my business, which isn't making much from online ad revenue, and I was
 hoping  some of the enterprises using GWT might be happy to pay for my
 stack trace system.  There are a few commercial tools in the GWT
 space, such aswww.instantiations.com/GWTDesigner, but I'm not sure
 how successful they are.  I'd love to get some feedback from you guys
 about this idea.  I can go both ways at this point.

  Your approach sounds complementary to the existing implementation.

 That's what I was hoping.

 Thanks,
 Alex



 On Thu, May 7, 2009 at 9:50 AM, BobV b...@google.com wrote:
  On Wed, May 6, 2009 at 4:49 PM, Alex Epshteyn
  alexander.epsht...@gmail.com wrote:
  I'm using static code rewriting at the Java source level to maintain a
  virtual stack.  It's actually working out very well so far.  Getting
  surprisingly good results for code size, efficiency, and correctness.

  Could you provide some numbers in terms of raw and gzipped
  before/after bytes?  Also, how does this interact with method and
  function inlining?

  I want to decide whether it's worth the effort to continue developing
  my system.   So my questions are does StackTraceCreator work with all
  browsers and is your symbol translation system ready to be used?  Are
  there any limitations with your approach?  Perhaps there is some area
  where my technique could provide better information to the programmer?

  StackTraceCreator is invoked in Throwable's initalizer and will
  extract as much data as the browser provides.  On Mozilla, you'll get
  a full stack trace.  On other browsers it crawls the caller chain, but
  since the caller chain isn't a proper series of activation records,
  and there's a limitation on reentrant functions.  In the end, it
  provides method-level resolution.  The symbol map file has enough data
  to cook a respectable StackTraceElement that makes IDE integration not
  unreasonable.

  I looked at implementing perfect stack traces as an AST visitor, but
  decided that the size cost, speed cost for inlining, and potential
  data-leakage for large apps would outweigh the marginal gain of having
  line-level resolution in deployed apps.  Those tradeoffs do make sense
  for development and QA versions of an app, but there was only a
  limited amount of time allocated for implementing stack traces.

  Your approach sounds complementary to the existing implementation.

  --
  Bob Vawter
  Google Web Toolkit Team
 


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

Re: Problems with ImageBundle in IE8 when not in compatibility mode

[Alex Epshteyn]

BE CAREFUL when copying code from this page - Thomas Broyer's comment
has an error.

The correct meta tag to add is

meta http-equiv=X-UA-Compatible content=IE=EmulateIE7 /

be sure the first attribute is http-equiv, not name!

(wasted 20 minutes on this)

I can confirm that this tag fixes the problem with ImabeBundle.

Be sure to read http://msdn.microsoft.com/en-us/library/cc288325.aspx
for more info.  As it says, this meta tag must appear before any
element in in the head except title and/or other meta tags.
(This makes sense, because the browser needs to process this tag prior
to interpreting the stylesheets).



On May 1, 8:38 am, Ken Kahn toont...@googlemail.com wrote:
 Thanks to both of you. Fixed my problem as well.

 I noticed that the Rich Text sample in the GWT Showcase usesImageBundleand it 
 seems to work fine inIE8without compatibility
 mode. I have yet to find time to track down what is different in my
 case.

 -ken

 On Apr 30, 3:31 am, Dominik Steiner dominik.j.stei...@googlemail.com
 wrote:

  Thanks for the tip Thomas,

  just to amend/aggragate something i found out that you have to add the
  meta tag to the head section before any other elements and the meta
  tag i added was

  meta http-equiv=X-UA-Compatible content=IE=EmulateIE7 

  HTH

  Dominik

  On 15 Apr., 03:56, Thomas Broyer t.bro...@gmail.com wrote:

   On 14 avr, 18:41, toont...@googlemail.com toont...@googlemail.com
   wrote:

Greetings,

Only inIE8with compatibility mode off do I see the images in the
   ImageBundledisplayed in the right location but other images from the
bundle are displayed to the left of the displayed image. In other
words it isn't clipping the bundle to the left. In compatibility mode
it works fine and it works in IE7, FF3, Opera, and Safari.

This a problem in 1.6.4 and 1.5.3.

   Other things will break inIE8'ssuper standards mode.

I've looked for previous discussions of this and found

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

where Janie says I'm trying to track down an issue with ImageBundles
that I'm having inIE8.  This email is not about that issue... . But
then nothing more about this.

Suggestions?

   AskIE8to use the appropriate mode by including the corresponding
   HTTP response header or meta to your HTML host page; e.g.

      meta name=X-UA-Compatible content=IE=EmulateIE7

   Seehttp://msdn.microsoft.com/en-us/library/cc288325(VS.85).aspx
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

[gwt-contrib] Re: I've implemented Java stack trace support for web mode

[Alex Epshteyn]

Hi Bob,

 Could you provide some numbers in terms of raw and gzipped
 before/after bytes?

This is the OBF compiled js size of a TypeRacer module before and
after instrumentation (raw/gz): 382/118 vs. 505/142 which can be
further reduced by using shortened identifiers instead of method name
strings (it doesn't make much difference when gzipped, though).

In terms of inlining, I've implemented the optimization of not
instrumenting simple getters and setters, which are guaranteed not to
raise an exception.  Everything else will probably not be eligible for
inlining.  But I do provide an annotation which you can use to exclude
your hot methods from instrumentation.

 I looked at implementing perfect stack traces as an AST visitor, but
 decided that the size cost, speed cost for inlining, and potential
 data-leakage for large apps would outweigh the marginal gain of having
 line-level resolution in deployed apps.

I'm not sure if that's necessarily the case. However, the capability
you've implemented may very well be sufficient.  I'm looking forward
to testing out your code when I have more time.

 Those tradeoffs do make sense
 for development and QA versions of an app, but there was only a
 limited amount of time allocated for implementing stack traces.

Yes, I can tell you from experience that what I did was pretty hairy
and definitely took a good amount of time.  There are lots of corner
cases to consider when rewriting a Java AST, as you probably know.
Just to give a tiny example - you can't insert anything before a
super() statement.  But at this point I have them all covered.

I'm not yet sure if I'll be open-sourcing my code.  I need to support
my business, which isn't making much from online ad revenue, and I was
hoping  some of the enterprises using GWT might be happy to pay for my
stack trace system.  There are a few commercial tools in the GWT
space, such as www.instantiations.com/GWTDesigner , but I'm not sure
how successful they are.  I'd love to get some feedback from you guys
about this idea.  I can go both ways at this point.

 Your approach sounds complementary to the existing implementation.

That's what I was hoping.

Thanks,
Alex


On Thu, May 7, 2009 at 9:50 AM, BobV b...@google.com wrote:
 On Wed, May 6, 2009 at 4:49 PM, Alex Epshteyn
 alexander.epsht...@gmail.com wrote:
 I'm using static code rewriting at the Java source level to maintain a
 virtual stack.  It's actually working out very well so far.  Getting
 surprisingly good results for code size, efficiency, and correctness.

 Could you provide some numbers in terms of raw and gzipped
 before/after bytes?  Also, how does this interact with method and
 function inlining?

 I want to decide whether it's worth the effort to continue developing
 my system.   So my questions are does StackTraceCreator work with all
 browsers and is your symbol translation system ready to be used?  Are
 there any limitations with your approach?  Perhaps there is some area
 where my technique could provide better information to the programmer?

 StackTraceCreator is invoked in Throwable's initalizer and will
 extract as much data as the browser provides.  On Mozilla, you'll get
 a full stack trace.  On other browsers it crawls the caller chain, but
 since the caller chain isn't a proper series of activation records,
 and there's a limitation on reentrant functions.  In the end, it
 provides method-level resolution.  The symbol map file has enough data
 to cook a respectable StackTraceElement that makes IDE integration not
 unreasonable.

 I looked at implementing perfect stack traces as an AST visitor, but
 decided that the size cost, speed cost for inlining, and potential
 data-leakage for large apps would outweigh the marginal gain of having
 line-level resolution in deployed apps.  Those tradeoffs do make sense
 for development and QA versions of an app, but there was only a
 limited amount of time allocated for implementing stack traces.

 Your approach sounds complementary to the existing implementation.

 --
 Bob Vawter
 Google Web Toolkit Team


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

[gwt-contrib] Re: I've implemented Java stack trace support for web mode

[Alex Epshteyn]

Hi Joel, thanks for the pointer!  StackTraceCreator looks pretty cool,
but I don't think there's any overlap with my work.

If I understand correctly, when you're running code compiled with OBF
it would give you a trace with elements like abc(), def(), ghi().

Here is what you get with my framework (actual output from an
exception in an OBF'd app in running in web mode):

java.lang.IllegalStateException: Should not reach this point
StackTesterWidget.thirdMethod(StackTesterWidget.java:39)
StackTesterWidget.secondMethod(StackTesterWidget.java:35)
StackTesterWidget.firstMethod(StackTesterWidget.java:31)
.onClick(StackTesterWidget.java:23)

In my case this information doesn't come from the
FF-Opera-etc-specific exception support.  It's maintained separately
from the browser.

Alex


On Tue, May 5, 2009 at 11:39 PM, Joel Webber j...@google.com wrote:
 Alex,
 Do check out com.google.gwt.core.client.impl.StackTraceCreator (in trunk).
 If I'm understanding your proposal correctly, there may be a great deal of
 overlap there.
 Cheers,
 joel.

 On Tue, May 5, 2009 at 6:47 PM, Alex Epshteyn alexander.epsht...@gmail.com
 wrote:

  Are there any new developments on this front in the core GWT code?

 The reason I ask is to be sure that I'm not duplicating your efforts
 and wasting my time.

 On Tue, May 5, 2009 at 4:31 PM, Alex Epshteyn
 alexander.epsht...@gmail.com wrote:
  I have a working implementation which produces stack traces
  representing the original Jave source code when Javascript exceptions
  occur in web mode.   I plan to deploy this in production on my site,
  typeracer.com in my next release.
 
  I'd like to polish up my implementation over the next few weeks,
  measure performance, and present it at Google I/O at the end of the
  month.
 
  We've talked about adding similar features to the GWT compiler in the
  past on this forum, but my site couldn't wait (I was getting too many
  cryptic exceptions logged from users), so I decided to go ahead and do
  it my way.  I ended up doing it externally to GWT, without any changes
  to the GWT compiler or any other code.
 
  Are there any new developments on this front in the core GWT code?




 


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

[gwt-contrib] Re: I've implemented Java stack trace support for web mode

[Alex Epshteyn]

I'm using static code rewriting at the Java source level to maintain a
virtual stack.  It's actually working out very well so far.  Getting
surprisingly good results for code size, efficiency, and correctness.

 The symbol maps are emitted into the -aux directory.

So compiling with the latest trunk will emit mappings from the OBF
symbols to original Java symbols?

I want to decide whether it's worth the effort to continue developing
my system.   So my questions are does StackTraceCreator work with all
browsers and is your symbol translation system ready to be used?  Are
there any limitations with your approach?  Perhaps there is some area
where my technique could provide better information to the programmer?

Thanks,
Alex



On Wed, May 6, 2009 at 4:22 PM, BobV b...@google.com wrote:
 On Wed, May 6, 2009 at 4:15 PM, Alex Epshteyn
 alexander.epsht...@gmail.com wrote:
 Yes, we discussed it some time ago. How is that coming along?

 The symbol maps are emitted into the -aux directory.

 @Alex, what technique are you using?

 --
 Bob Vawter
 Google Web Toolkit Team


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

[gwt-contrib] I've implemented Java stack trace support for web mode

[Alex Epshteyn]

I have a working implementation which produces stack traces
representing the original Jave source code when Javascript exceptions
occur in web mode.   I plan to deploy this in production on my site,
typeracer.com in my next release.

I'd like to polish up my implementation over the next few weeks,
measure performance, and present it at Google I/O at the end of the
month.

We've talked about adding similar features to the GWT compiler in the
past on this forum, but my site couldn't wait (I was getting too many
cryptic exceptions logged from users), so I decided to go ahead and do
it my way.  I ended up doing it externally to GWT, without any changes
to the GWT compiler or any other code.

Are there any new developments on this front in the core GWT code?
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: I've implemented Java stack trace support for web mode

[Alex Epshteyn]

 Are there any new developments on this front in the core GWT code?

The reason I ask is to be sure that I'm not duplicating your efforts
and wasting my time.

On Tue, May 5, 2009 at 4:31 PM, Alex Epshteyn
alexander.epsht...@gmail.com wrote:
 I have a working implementation which produces stack traces
 representing the original Jave source code when Javascript exceptions
 occur in web mode.   I plan to deploy this in production on my site,
 typeracer.com in my next release.

 I'd like to polish up my implementation over the next few weeks,
 measure performance, and present it at Google I/O at the end of the
 month.

 We've talked about adding similar features to the GWT compiler in the
 past on this forum, but my site couldn't wait (I was getting too many
 cryptic exceptions logged from users), so I decided to go ahead and do
 it my way.  I ended up doing it externally to GWT, without any changes
 to the GWT compiler or any other code.

 Are there any new developments on this front in the core GWT code?

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

[gwt-contrib] Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets

[Alex Epshteyn]

Background:

OpenSocial containers provide the method gadget.io.makeRequest because
gadget scripts aren't able to use XHR due to the SOP.  Furthermore, I
believe, OpenSocial containers don't expose the _IG_GetCachedUrl(url)
method that the gwt-gadgets library uses.

Now, regarding the gwt-gadgets library, to be blunt, it simply scares
me.  I don't want all the gadget stuff brought into the Java
programming language with interfaces and annotations.  Having the
bootsrap and gadget.xml generated with a custom linker is scary and
unnecessary.  This is just asking for trouble with a leaky
abstraction.

The RPC Problem:

It's very easy to write a Google Gadget with GWT without using the gwt-
gadgets library.  Simply write your gadget.xml by hand (there's not
much to it, really), write your GWT app the traditional way, compile
it with the XS linker, and write a script tag referencing
your .nocache.js script in your gadget.xml.  You can call all the
OpenSocial and Gadgets API methods from your GWT code using JSNI (JSO
overlay types could simplify things a bit).

The only problem is RPC.  Currently using GWT-RPC in an OpenSocial
container seems impossible.   You'd have to write a JSON service.

The Proposed Solution:

This is just a rough sketch, but I think this can be accomplished as
follows:

1) Subclass RequestBuilder to use gadgets.io.makeRequest

2) Subclass RemoteServiceProxy and override the protected method
doPrepareRequestBuilder to return an instance of your custom
RequestBuilder subclass.

3) Modify ProxyCreator to allow setting a custom superclass for the
generated proxy class.  I.e. allow chaning this line:
composerFactory.setSuperclass(RemoteServiceProxy.class.getSimpleName
());

(Perhaps with a system property defining the class name for starters).
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets

[Alex Epshteyn]

Success - I got this to work!  Now running GWT-RPC through
OpenSocial's gadget.io.makeRequest!

Only two lines of code had to be changed in GWT to make the RPC system
pluggable.  Here is a patch against trunk.  Could someone review and
approve?

The other half consists of custom RequestBuilder and
RemoteServiceProxy subclasses.  I will continue testing and polishing
those and will share them later.

Alex






On Thu, Jan 22, 2009 at 5:17 PM, Alex Epshteyn
alexander.epsht...@gmail.com wrote:
 Yes, the option to extend RPC and gadgets are two separate ideas.

 Code generation is one of the core features of GWT, and nothing new is being
 added to the Java programming language, as the syntax is part of the Java
 language.

 The reason GWT works is because HTML and Javascript evolve very
 slowly.  A tight Java binding to a fast-changing Javascript API like
 Gadgets or OpenSocial is asking for trouble because you won't be able
 to keep updating the Java code fast enough.

 Alex


 On Thu, Jan 22, 2009 at 5:08 PM, Ray Cromwell cromwell...@gmail.com wrote:

 I think there are two issues. One is providing hooks to allow the RPC call
 to be dispatched via a customized mechanism. This can range from
 makeRequest() with POST, to cross-domain JSONP, to ProtocolBuffer
 RpcChannel. I've brought up this issue time and time again, as I've been an
 early adopter of writing complex GWT apps inside of Gadgets. I think it
 would be useful to revisit the RPC design in the future to make it easier to
 plugin custom methods, not just for Gadgets/makeRequest, but also for stuff
 like JSON wireformats and ProtocolBuffers.
 The issue of the GadgetLinker manifest generation is separate. I happen to
 like the concept, but dislike the current implementation. I like the
 auto-generation of the manifest, the type safety of dependency-injected
 interfaces. However, the current system is too inflexible. It doesn't
 support multiple Gadget views, it doesn't support optional feature
 requirements. That is, if you require an optional feature in the manifest,
 the feature interfaces will still get injected even if they weren't loaded.
 Simply put, I don't find using annotations, generators, and linkers scary.
 Code generation is one of the core features of GWT, and nothing new is being
 added to the Java programming language, as the syntax is part of the Java
 language.
 On a wider now, realistically, GALGWT needs official bindings for non-legacy
 Gadgets and OpenSocial. I've implemented JSOs for most of those privately as
 Gadget features, but it would be nice to have an officially sanctioned
 Google binding.

 -Ray

 On Thu, Jan 22, 2009 at 1:13 PM, Alex Epshteyn
 alexander.epsht...@gmail.com wrote:

 Background:

 OpenSocial containers provide the method gadget.io.makeRequest because
 gadget scripts aren't able to use XHR due to the SOP.  Furthermore, I
 believe, OpenSocial containers don't expose the _IG_GetCachedUrl(url)
 method that the gwt-gadgets library uses.

 Now, regarding the gwt-gadgets library, to be blunt, it simply scares
 me.  I don't want all the gadget stuff brought into the Java
 programming language with interfaces and annotations.  Having the
 bootsrap and gadget.xml generated with a custom linker is scary and
 unnecessary.  This is just asking for trouble with a leaky
 abstraction.

 The RPC Problem:

 It's very easy to write a Google Gadget with GWT without using the gwt-
 gadgets library.  Simply write your gadget.xml by hand (there's not
 much to it, really), write your GWT app the traditional way, compile
 it with the XS linker, and write a script tag referencing
 your .nocache.js script in your gadget.xml.  You can call all the
 OpenSocial and Gadgets API methods from your GWT code using JSNI (JSO
 overlay types could simplify things a bit).

 The only problem is RPC.  Currently using GWT-RPC in an OpenSocial
 container seems impossible.   You'd have to write a JSON service.

 The Proposed Solution:

 This is just a rough sketch, but I think this can be accomplished as
 follows:

 1) Subclass RequestBuilder to use gadgets.io.makeRequest

 2) Subclass RemoteServiceProxy and override the protected method
 doPrepareRequestBuilder to return an instance of your custom
 RequestBuilder subclass.

 3) Modify ProxyCreator to allow setting a custom superclass for the
 generated proxy class.  I.e. allow chaning this line:
 composerFactory.setSuperclass(RemoteServiceProxy.class.getSimpleName
 ());

 (Perhaps with a system property defining the class name for starters).



 



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



rpc_hooks.patch
Description: Binary data

[gwt-contrib] Re: Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets

[Alex Epshteyn]

I agree that an environment variable isn't ideal, but could you
explain the annotations you listed?  Is that a proposed future way to
access module properties from inside a generator?
GeneratorContext.getPropertyOracle() is the way to get these at
runtime, correct?

So do you want me to add define-property
name=gwt.rpc.proxySuperClass values=com.foo.Bar/ to
/com/google/gwt/user/RemoteService.gwt.xml ?

I'm fine with that, except I'm not sure about the values attribute.  I
don't want end-user modules to be forced to choose from a pre-defined
set of values for this property.  I want to support providing
arbitrary subclasses of RemoteServiceProxy.

From the docs:

define-property name=property_name values=property_values :
Define a property and allowable values (comma-separated identifiers).
This element is typically used to generate a value that will be
evaluated by a rule using a when... element.

Alex

On Fri, Jan 23, 2009 at 1:25 AM, Ray Cromwell cromwell...@gmail.com wrote:

 Agreed. I used a similar patch in my own implementation a few weeks ago,
 although yours is simpler. One thing I'd suggest though is to get the
 superclass setting either from a module property, or from something in the
 type system, or runtime, rather than the environment.
 e.g.
 define-property name=gwt.rpc.proxySuperClass values=com.foo.Bar/
 set-property name=gwt.rpc.proxySuperClass value=com.foo.Bar/
 which is kind of an abuse of the property system, but allows compiling
 different permutations of the app for different environments (e.g. gadget vs
 non-gadget versions) There was some discussion awhile ago of adding new
 kinds of properties which specify configuration.
 @GwtProxySuperClass(com.foo.Bar)
 public interface MyService extends RemoteService { ... }

 which allows specifying the transport, but does not allow more than 1
 transport at a time for the same type (without creating subinterfaces)
 However you could easily do something like:

 @GwtProxySuperClass(GadgetProxy)
 public MyGadgetService extends MyService {...}
 @GwtProxySuperClass(ProtoBufProxy)
 public MyProtoBufService extends MyService {...}
 Using environment properties doesn't seem GWT-like to me, since it kind of
 buries flags deep inside implementation code that most users won't see and
 moves it to build scripts. This is one of the things I always disliked about
 Sun's use of -D parameters all over the JRE code, since finding out a
 complete list of all these magic variables and exactly what they do is often
 difficult. GWT's idiom is usually to embed build specific switches via
 deferred binding properties.
 -Ray

 On Thu, Jan 22, 2009 at 8:27 PM, Alex Epshteyn
 alexander.epsht...@gmail.com wrote:

 Anyhow, let's get this thread back on track to being a discussion
 about allowing RPC over non-XHR proxy channels like
 gadgets.io.makeRequst.  You can use my RPC code with or without the
 gwt-gadgets library.

 I'd like to get this patch into trunk if no one objects.

 Alex




 On Thu, Jan 22, 2009 at 8:38 PM, Ray Cromwell cromwell...@gmail.com
 wrote:
 
  I don't quite understand this point. Any JSO you create is going to be
  tightly bound to the underlying Gadget/OpenSocial APIs, so what's the
  difference between a JSO binding which is isn't dependency injected, vs
  one
  that is, with regard to keeping up with API changes?  Are you arguing
  against using GWT JSOs to call OpenSocial APIs, or just trying to argue
  against GadgetLinker injecting the reference for you? There seems to be
  little difference between writing a native method to get the initial
  reference to an Overlay type, or having it injected for you, with
  respect to
  fast evolving specs. All the GadgetLinker does is construct an
  instance of
  a type that you tell it and it wouldn't be hard to modify it so inject
  JSO
  Overlays.
  To me, the only issue that controls whether or not you can keep in sink
  is
  whether you have access to the mapping source. And even then, that isn't
  the
  biggest issue with OpenSocial programming. The actual specs
  0.6/0.7/0.8/0.81/0.9 etc aren't changing that fast, in fact, I wish
  they'd
  change faster.
  The real problem with OpenSocial programming, which hits Java
  programmers
  just as hard as JavaScript programmers, is poor container
  implementations,
  and the fact that the spec is designed in a way that virtually
  everything is
  optional to implement. Quick, which containers support notifications,
  requestShareApp, or activities? Which support OAuth?
 
  IMHO, a generator which could parse idiomatic JsDoc/Javascript ala Bob's
  JS
  Interop, and with some extra annotations, automatically generate JSO
  bindings, would actually be superior to writing JSOs by hand to keep
  them in
  sink, or even programming Javascript by hand. Why? Because everytime the
  spec is updated, if there was a mismatch, you could detect errors.
  However, none of that really matters much, since unless you decide to
  target
  a single OS container

[gwt-contrib] Re: RR : Pluggable CompilePerms workers

[Alex Epshteyn]

I spent quite a bit of time trying out this new permutation worker
framework (mostly spent stepping through it in my debugger, as I was
having issues).  Here are my thoughts:

1). The mechanism for designating the number of threads or processes
needs to be cleaned up or rethought.  The parameter -localWorkers N
ends up spawning 1 ThreadedPermutationWorker and N-1
ExternalPermutationWorkers.  This is counter-intuitive, because when I
set something to N, I'm expecting to see N homogeneous objects.

That's because if you don't specify a value for
gwt.jjs.permutationWorkerFactory, the default is to start creating
threaded workers up to maxThreads and use external workers for the
rest.

I have a dual-core CPU, so I wanted to use 2 threads.   I eventually
figured out that the way to accomplish this is to either

a). set -Dgwt.jjs.maxThreads=2 *and* -localWorkers 2
simultaneously, or
b). set -
Dgwt.jjs.permutationWorkerFactory=com.google.gwt.dev.ThreadedPermutationWorkerFactoryand
-localWorkers 2

A better way of managing this would be to have two command-line
parameters, nProcesses and n nThreadsPerProcess.

2).  I couldn't get ExternalPermutationWorkerFactory to work:

java.net.ConnectException: Connection refused: connect
at com.google.gwt.dev.CompilePermsServer.run
(CompilePermsServer.java:243)

3).  Finally, I'm sorry to say this, but this framework is mostly
useless if you have fewer than 8 cores and more than one module to
compile.

There is very little performance gain when I compile with 2 threads
instead of 1 (only 10% per module on a dual-core CPU with 5
permutations per module).

Although the permutations can now be compiled using possibly more than
one thread, the modules are still processed sequentially.

If you have more than one output module (and I suspect most developers
for whom compiler speed is an issue fall into this category), then
it's much faster to run the compiler in parallel (i.e. invoke multiple
instances of the complier with 1 module each, instead of one compiler
process with a list of modules).  This gives you a 100% boost on a
dual-core CPU.  I've been doing this using the ForTask from ant-
contrib for the past half year and it halved my build time.

In other words, the task of compiling modules is embarrassingly
parallel, but the the task of generating permutations within a module
doesn't seem to be so.

So basically, as much as this new framework looks cool, it's totally
useless to me when I have to build more than one module.

If I had a computer with 2 quad-core CPUs (like Bob ;) ), on the other
hand, I might spawn 2 compiler instances with 4 threads each.

Some food for thought here - perhaps you should think about using the
external workers for modules and threads for permutations.

Alex

On Jan 21, 6:45 pm, Alex Epshteyn alexander.epsht...@gmail.com
wrote:
 This stuff looks great, guys.  Is there any chance of actually setting
 up a distributed build cluster using this code?

 Back when I had an older laptop, I've thought about the idea of
 spawning one or more EC2 instances to do builds.  Now, with a top of
 the line laptop, I was happy for a while, but I still only have 2
 cores, and build times are starting to bother me again.

 On Nov 24 2008, 12:00 pm, Lex Spoon sp...@google.com wrote:

  On Thu, Nov 20, 2008 at 8:58 PM, Scott Blum sco...@google.com wrote:
   - We ended up going with Lex's ThreadPoolExecutor stuff.  Mainly because 
   he
   was physically here, and I think both of the TPE-based implementations 
   suck.

  Well, we eliminated TPE itself.  However, we went with message-passing
  coordination rather than checking multiple counters and queues and/or
  checking the interrupted states.

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

[gwt-contrib] Re: C:\GWT_source\common.ant.xml:209: cannot launch command svn info

[Alex Epshteyn]

How exactly does the svninfo task contribute to the build?  I'm
still getting a gwt-windows-0.0.0 directory as output.  Would be nice
to have a revision number there instead.

On Jan 12, 11:00 pm, Freeland Abbott gwt.team.fabb...@gmail.com
wrote:
 I've actually never had trouble getting a command-line client, but that's
 beside the point.
 We can make no svn and also not compatible messages be non-blocking
 errors, though as I mentioned that raises the question of whether anything
 should be blocking... and if not, whether we're getting anything out of
 branding desk builds anyway.  (That is, should be make it optional, or
 remove it and let the build robot assert its value and everybody else not
 brand at all?)

 I'm negatively biased on SvnKit, mostly because of workspace compatibility:
 if I use whatever-I-like to create my workspace, it'd have to be
 compatible with the SvnKit from our tools checkout, right?  At if SvnKit
 got over-eager to update my workspace, the other tool would then lose, yes?
  At least with, say, TortoiseSVN and my command-line svn, I got them both,
 know about them, and can see why the problem exists.

 I'm increasingly coming to think that all svninfo errors should be
 non-blocking, with a non-default property for the robot to instead say no,
 I really care.  And that'd likely mean that only robot builds would have
 branding, in which case maybe we should just go there.

 On Mon, Jan 12, 2009 at 10:25 PM, Ian Petersen ispet...@gmail.com wrote:

  On Tue, Jan 13, 2009 at 4:10 PM, gregor greg.power...@googlemail.com
  wrote:

   Well, finding a windows command line svn client looks easier said
   than done. I've spent over an hour now trying to find a free one (I've
   got no use for it at the moment apart from this issue), and it's not
   at all clear that there is one that will do the job without messing
   about with 30 day trials for Syncro and the like.

  Is there a reason you can't use one of the binaries listed here?
 http://subversion.tigris.org/getting.html#windows

  I'm pretty sure I've usedhttp://www.sliksvn.com/en/downloadbefore.

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

[gwt-contrib] Re: C:\GWT_source\common.ant.xml:209: cannot launch command svn info

[Alex Epshteyn]

I see that the rev number is inserted into About.properties.  It would
be nice if this also appeared in the output directory name.  Having
gwt.version = 0.0.0 isn't very useful.   It's a bit annoying to look
for the rev number and manually rename the directory after every
build.



On Jan 18, 6:42 pm, Alex Epshteyn alexander.epsht...@gmail.com
wrote:
 How exactly does the svninfo task contribute to the build?  I'm
 still getting a gwt-windows-0.0.0 directory as output.  Would be nice
 to have a revision number there instead.

 On Jan 12, 11:00 pm, Freeland Abbott gwt.team.fabb...@gmail.com
 wrote:

  I've actually never had trouble getting a command-line client, but that's
  beside the point.
  We can make no svn and also not compatible messages be non-blocking
  errors, though as I mentioned that raises the question of whether anything
  should be blocking... and if not, whether we're getting anything out of
  branding desk builds anyway.  (That is, should be make it optional, or
  remove it and let the build robot assert its value and everybody else not
  brand at all?)

  I'm negatively biased on SvnKit, mostly because of workspace compatibility:
  if I use whatever-I-like to create my workspace, it'd have to be
  compatible with the SvnKit from our tools checkout, right?  At if SvnKit
  got over-eager to update my workspace, the other tool would then lose, yes?
   At least with, say, TortoiseSVN and my command-line svn, I got them both,
  know about them, and can see why the problem exists.

  I'm increasingly coming to think that all svninfo errors should be
  non-blocking, with a non-default property for the robot to instead say no,
  I really care.  And that'd likely mean that only robot builds would have
  branding, in which case maybe we should just go there.

  On Mon, Jan 12, 2009 at 10:25 PM, Ian Petersen ispet...@gmail.com wrote:

   On Tue, Jan 13, 2009 at 4:10 PM, gregor greg.power...@googlemail.com
   wrote:

Well, finding a windows command line svn client looks easier said
than done. I've spent over an hour now trying to find a free one (I've
got no use for it at the moment apart from this issue), and it's not
at all clear that there is one that will do the job without messing
about with 30 day trials for Syncro and the like.

   Is there a reason you can't use one of the binaries listed here?
  http://subversion.tigris.org/getting.html#windows

   I'm pretty sure I've usedhttp://www.sliksvn.com/en/downloadbefore.

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

Re: Problem in developing opensocial application in GWT

[Alex Epshteyn]

Hi Yasser,

I'm actually not using GWT in directly my OS gadget - I have an iframe
inside the gadget that loads my GWT app.

However, I'm sure you can use GWT RPC quite easily in the gadget - as
long as your compiled JS has the same URL as your RPC server.

Best,
Alex

(I'm CC-ing this message to the group so that others can also
contribute to this discussion)

On Wed, Jan 14, 2009 at 11:40 PM, Yasser Sultan sultan.yas...@gmail.com wrote:
 Hi Alexander,
 I got your email id from GWT group. You had mentioned that the opensocial
 application Typeracer has been developed in GWT. This app is really fabulous
 and fun to race against friends! As I am also a social applications
 developer and nowadays I am developing a new application in GWT I have few
 questions for you. I will be grateful if you could spare some time to answer
 these queries.

 I am having problem in deploying GWT application in an opensocial container.
 The main obstacle is making RPC from client side to server side. So I want
 to ask whether you are using RPC to communicate with server or some other
 form like JSON ?

 With best regards
 Yasser Sultan


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Who's Using GWT?

[Alex Epshteyn]

http://play.typeracer.com

Too many tips and tricks to enumerate here :)

On Dec 11, 8:39 pm, Sumit Chandel sumitchan...@google.com wrote:
 Hello everyone,

 We've recently updated the GWT homepage to include a page displaying a
 non-exhaustive list of applications that are built with GWT. We were
 also able to capture a few developers on video for those who happened
 to be around the Google Mountain View area and developed awesome
 applications using GWT. Check out more details on both of these at the
 link below:

 Who's Using GWT?:http://code.google.com/webtoolkit/app_gallery.html

 It's great that we were able to catch some of our local developers on
 video, but we know there are other great stories out there from other
 developers in the community. So, I thought it would be cool if I
 stickied this Groups thread for community members to share their
 experience with everyone.

 Feel free to post up your own GWT application(s), along with your most
 loved / requested features and any tips and tricks you've come across
 as you developed your applications that you'd like to share with the
 rest of the community. Looking forward to hearing from you.

 Cheers,
 -Sumit Chandel
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Native GWT Compiler

[Alex Epshteyn]

Thanks, Sumit.  Can this arg also be used for GWTShell?

On Thu, Dec 11, 2008 at 2:46 PM, Sumit Chandel sumitchan...@google.com wrote:
 Hi Alex, Dobes,

 There is a flag that you need to pass in to have the compiler run in
 multi-threaded mode.

 The flag is:

 -localWorkers N, where N is some number greater than 1, depending on how
 many threads you want to use to compile your GWT application. Sorry for not
 mentioning this earlier.

 Hope that helps,
 -Sumit Chandel

 On Tue, Dec 9, 2008 at 11:50 PM, Alex Epshteyn
 alexander.epsht...@gmail.com wrote:

 Does anyone know the answer to this question asked by Dobes:

  I checked out the trunk and I'm running thecompilerfrom it, but I'm
  not seeing any performance boost and only one CPU core is being used.
  Is there a command-line switch to turn on multiple threads?

 That's why I was reluctant spending at least an hour trying this
 myself - I didn't believe it would actually be enabled by default.


 On Nov 24, 7:29 am, Dobes dob...@gmail.com wrote:
  I checked out the trunk and I'm running thecompilerfrom it, but I'm
  not seeing any performance boost and only one CPU core is being used.
  Is there a command-line switch to turn on multiple threads?
 
  On Nov 12, 10:56 am, Alex Epshteyn alexander.epsht...@gmail.com
  wrote:
 
   Hi Sumit,
 
   This multithreadedcompilersounds intriguing.  Could you provide some
   guidance about how to get it and use it?
 
   Thanks,
   Alex
 
   On Oct 13, 1:08 pm, Sumit Chandel sumitchan...@google.com wrote:
   Hi Rauf,
There are currently no plans to rewrite the GWTcompileras a native
   compiler. There are plans to speedup compilation time with the
current GWT
   compiler, however, and the team is in the know about long compilation
times
that some developers have been experiencing when moving their
projects form
1.4.x to 1.5.
 
The new multi-threadedcompileris available in trunk if you're
interested
in checking it out to see if it helps speed up your application
compile
time.
 
From benchmarks we've run and what some developers have been
reporting, the
new multi-threaded compilation has been showing significant
improvements in
compilation speed, so you should be getting faster results for your
own
project as well.
 
Hope that helps,
-Sumit Chandel
 
On Wed, Oct 8, 2008 at 2:36 PM, Rauf Issa grandlo...@gmail.com
wrote:
 
 Any plans to write a native GWTCompilerlike jikes for java? I know
 there are plans to improve GWTcompilerperformance in the upcoming
 1.6 release of GWT by multi-threading but I am not sure that will
 make
 enough difference. A nativecompilerlike jikes would be better and
 much faster.
 
 Our product, JobServer (job scheduling engine) uses GWT for its
 GUI
 SDK and we compile GWT components on the fly the first time the
 GWT is
 used. This frees the developer from doing the GWTcompilerif they
 do
 not want to. This works very well but the initial GWT compiling of
 the
 GWT UI components can take minutes sometimes and is annoying. I
 would
 really like this to be more like compiling JSP pages for example.
 
 Anyway I can only hope that GWT compiling gets faster (right now
 it is
 getting slower with all the advanced optimizations done in GWT 1.5
 :)
 
 Rauf Issa
http://www.grandlogic.com
 JobServer - The Most Comprehensive Java Job Scheduling Platform



 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: GWT hosted mode in infinity loop when debugging

[Alex Epshteyn]

Matic,

I just started having the exact same problem!  I'm using IntelliJ not
Eclipse, though.  The debugger just keeps looping.  When I forcibly
pause the process, I see that it's always somewhere in the RPC service
instantiation process and never finishes it (i.e. GWT.create()).

I don't think this is an Eclipse or IntelliJ problem.   Perhaps
something strange introduced in GWT 1.5.3?

I have no idea how to solve this.  I've tried cleaning everything,
restarting IDE, computer, cleaning all GWT directories, etc.   I can
only run the project now, not debug it.

Alex

On Oct 31, 2:42 pm, maticpetek maticpe...@gmail.com wrote:
 Hello,
    I'm developing one project in GWT for more then a year now. Of
 course I add new code all the time. But one week ago debug mode stop
 working. When I run my project in Eclipse in debug mode, GWT hosted
 mode is started but then java process start using 100% CPU time and
 takes infinity time (ok, after 30 minutes I kill the process). If i
 run my project in run mode, everything works OK and it start in couple
 of seconds.
    I'm using OS X Leopard / Eclipse 3.3 / GWT 1.4.62. I also update on
 Eclipse 3.4 / GWT 1.5.2 and Eclipse 3.3 / GWT 1.5.2, but nothing
 change - debug mode was still fell in infinity loop. I check log file
 directory in .gwt-logs and .settings, but nothing is their. I
 thing something must be wrong with my code in GWT compiler, because I
 am developing (debugging( some other project on some machine, Eclipse
 and GWT without any problem.
    Could you please help me somehow. I'm really tired of debugging my
 code with GWT.log(). Thank you.

 Regards,
    Matic
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: GWT hosted mode in infinity loop when debugging

[Alex Epshteyn]

I think I just solved the problem by reverting my IntelliJ project
files to an earlier state.  It wasn't any new code that I had written
- looks like just the project files got out of whack somehow.  Good to
back those up often.

On Thu, Dec 11, 2008 at 8:34 PM, Alex Epshteyn
alexander.epsht...@gmail.com wrote:

 Matic,

 I just started having the exact same problem!  I'm using IntelliJ not
 Eclipse, though.  The debugger just keeps looping.  When I forcibly
 pause the process, I see that it's always somewhere in the RPC service
 instantiation process and never finishes it (i.e. GWT.create()).

 I don't think this is an Eclipse or IntelliJ problem.   Perhaps
 something strange introduced in GWT 1.5.3?

 I have no idea how to solve this.  I've tried cleaning everything,
 restarting IDE, computer, cleaning all GWT directories, etc.   I can
 only run the project now, not debug it.

 Alex

 On Oct 31, 2:42 pm, maticpetek maticpe...@gmail.com wrote:
 Hello,
I'm developing one project in GWT for more then a year now. Of
 course I add new code all the time. But one week ago debug mode stop
 working. When I run my project in Eclipse in debug mode, GWT hosted
 mode is started but then java process start using 100% CPU time and
 takes infinity time (ok, after 30 minutes I kill the process). If i
 run my project in run mode, everything works OK and it start in couple
 of seconds.
I'm using OS X Leopard / Eclipse 3.3 / GWT 1.4.62. I also update on
 Eclipse 3.4 / GWT 1.5.2 and Eclipse 3.3 / GWT 1.5.2, but nothing
 change - debug mode was still fell in infinity loop. I check log file
 directory in .gwt-logs and .settings, but nothing is their. I
 thing something must be wrong with my code in GWT compiler, because I
 am developing (debugging( some other project on some machine, Eclipse
 and GWT without any problem.
Could you please help me somehow. I'm really tired of debugging my
 code with GWT.log(). Thank you.

 Regards,
Matic
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Native GWT Compiler

[Alex Epshteyn]

Does anyone know the answer to this question asked by Dobes:

 I checked out the trunk and I'm running thecompilerfrom it, but I'm
 not seeing any performance boost and only one CPU core is being used.
 Is there a command-line switch to turn on multiple threads?

That's why I was reluctant spending at least an hour trying this
myself - I didn't believe it would actually be enabled by default.


On Nov 24, 7:29 am, Dobes [EMAIL PROTECTED] wrote:
 I checked out the trunk and I'm running thecompilerfrom it, but I'm
 not seeing any performance boost and only one CPU core is being used.
 Is there a command-line switch to turn on multiple threads?

 On Nov 12, 10:56 am, Alex Epshteyn [EMAIL PROTECTED]
 wrote:

  Hi Sumit,

  This multithreadedcompilersounds intriguing.  Could you provide some
  guidance about how to get it and use it?

  Thanks,
  Alex

  On Oct 13, 1:08 pm, Sumit Chandel [EMAIL PROTECTED] wrote: Hi Rauf,
   There are currently no plans to rewrite the GWTcompileras a native
  compiler. There are plans to speedup compilation time with the current GWT
  compiler, however, and the team is in the know about long compilation times
   that some developers have been experiencing when moving their projects 
   form
   1.4.x to 1.5.

   The new multi-threadedcompileris available in trunk if you're interested
   in checking it out to see if it helps speed up your application compile
   time.

   From benchmarks we've run and what some developers have been reporting, 
   the
   new multi-threaded compilation has been showing significant improvements 
   in
   compilation speed, so you should be getting faster results for your own
   project as well.

   Hope that helps,
   -Sumit Chandel

   On Wed, Oct 8, 2008 at 2:36 PM, Rauf Issa [EMAIL PROTECTED] wrote:

Any plans to write a native GWTCompilerlike jikes for java? I know
there are plans to improve GWTcompilerperformance in the upcoming
1.6 release of GWT by multi-threading but I am not sure that will make
enough difference. A nativecompilerlike jikes would be better and
much faster.

Our product, JobServer (job scheduling engine) uses GWT for its GUI
SDK and we compile GWT components on the fly the first time the GWT is
used. This frees the developer from doing the GWTcompilerif they do
not want to. This works very well but the initial GWT compiling of the
GWT UI components can take minutes sometimes and is annoying. I would
really like this to be more like compiling JSP pages for example.

Anyway I can only hope that GWT compiling gets faster (right now it is
getting slower with all the advanced optimizations done in GWT 1.5 :)

Rauf Issa
   http://www.grandlogic.com
JobServer - The Most Comprehensive Java Job Scheduling Platform
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Multithreaded GWT Compiler

[Alex Epshteyn]

(Just changing the title of this thread to match actual discussion
subject).

On Dec 10, 2:50 am, Alex Epshteyn [EMAIL PROTECTED]
wrote:
 Does anyone know the answer to this question asked by Dobes:

  I checked out the trunk and I'm running thecompilerfrom it, but I'm
  not seeing any performance boost and only one CPU core is being used.
  Is there a command-line switch to turn on multiple threads?

 That's why I was reluctant spending at least an hour trying this
 myself - I didn't believe it would actually be enabled by default.

 On Nov 24, 7:29 am, Dobes [EMAIL PROTECTED] wrote:

  I checked out the trunk and I'm running thecompilerfrom it, but I'm
  not seeing any performance boost and only one CPU core is being used.
  Is there a command-line switch to turn on multiple threads?

  On Nov 12, 10:56 am, Alex Epshteyn [EMAIL PROTECTED]
  wrote:

   Hi Sumit,

   This multithreadedcompilersounds intriguing.  Could you provide some
   guidance about how to get it and use it?

   Thanks,
   Alex

   On Oct 13, 1:08 pm, Sumit Chandel [EMAIL PROTECTED] wrote: Hi Rauf,
There are currently no plans to rewrite the GWTcompileras a native
   compiler. There are plans to speedup compilation time with the current 
   GWT
   compiler, however, and the team is in the know about long compilation 
   times
that some developers have been experiencing when moving their projects 
form
1.4.x to 1.5.

The new multi-threadedcompileris available in trunk if you're interested
in checking it out to see if it helps speed up your application compile
time.

From benchmarks we've run and what some developers have been reporting, 
the
new multi-threaded compilation has been showing significant 
improvements in
compilation speed, so you should be getting faster results for your own
project as well.

Hope that helps,
-Sumit Chandel

On Wed, Oct 8, 2008 at 2:36 PM, Rauf Issa [EMAIL PROTECTED] wrote:

 Any plans to write a native GWTCompilerlike jikes for java? I know
 there are plans to improve GWTcompilerperformance in the upcoming
 1.6 release of GWT by multi-threading but I am not sure that will make
 enough difference. A nativecompilerlike jikes would be better and
 much faster.

 Our product, JobServer (job scheduling engine) uses GWT for its GUI
 SDK and we compile GWT components on the fly the first time the GWT is
 used. This frees the developer from doing the GWTcompilerif they do
 not want to. This works very well but the initial GWT compiling of the
 GWT UI components can take minutes sometimes and is annoying. I would
 really like this to be more like compiling JSP pages for example.

 Anyway I can only hope that GWT compiling gets faster (right now it is
 getting slower with all the advanced optimizations done in GWT 1.5 :)

 Rauf Issa
http://www.grandlogic.com
 JobServer - The Most Comprehensive Java Job Scheduling Platform
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Your opinion sought: Jetty or Tomcat?

[Alex Epshteyn]

I've been mulling this over the past couple of weeks, and now I want
to retract my initial objection about Jetty :)  Mainly because, as
Arthur and others pointed out, it's expected to speed up unit tests
(which would be a huge win).  And you don't need -noserver for most of
the unit tests you might want to run - the default settings should be
sufficient.  Therefore this is one area where even the -noserver
crowd can benefit from a faster embedded server.

On Tue, Nov 25, 2008 at 11:51 PM, AB [EMAIL PROTECTED] wrote:

 I am using -noserver so it doesnt matter and even if I wasnt, i could
 live with either.
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Your opinion sought: Jetty or Tomcat?

[Alex Epshteyn]

 mentioned. There's also been some research into making the compiler faster.
 I can't say as much about the Java line from JavaScript exception feature,
 but it sounds like it would be a great feature to have (and a great
 candidate as a Request For Enhancement on the Issue Tracker).

 Issue Tracker:
 http://code.google.com/p/google-web-toolkit/issues/list

 Cheers,
 -Sumit Chandel

 On Fri, Nov 21, 2008 at 3:54 PM, Alex Epshteyn
 [EMAIL PROTECTED] wrote:

 Bruce,

 I might be too late in replying to this thread, but I want to phrase
 my objections to what you've proposed.

 A. Regarding Jetty:

 I think this will be a waste of time for everyone.  Switching
 underlying servers is a no value added task (using Six Sigma
 vocabulary).

 1).  Many developers are using -noserver so for them this will make no
 difference.

 2).  Many other developers have customized the embedded Tomcat to suit
 our needs (I spent hours customizing it so that I don't have to run
 with -noserver).   It will take hours to re-adjust again if you switch
 underlying servers.

 3). Why?  What's the benefit of switching to Jetty?  Tomcat startup is
 like 5 seconds tops, which accounts for maybe 10% of the hosted mode
 startup time.  You should speed up the compiler if you want to speed
 up hosted mode.   I don't understand what Jetty has to offer here.
 I'd be happy if you proved me wrong here, though.

 B. Regarding the output directory structure:

 I feel the same way about this as I do about Jetty.  I think this is a
 waste of time - no real value added to GWT.  Most of us will have to
 re-tweak our ant build configs which is always a waste of time.

 C. Final thoughts

 I'm really looking forward to seeing something of substance in the
 roadmap for 1.6, because between what you've written here and what's
 marked with 1_6_RC on the issue tracker, I see nothing of any value
 except minor bug fixes.

 Here are the top 3 features that I think would add real value to GWT:

 1). A way to get meaningful Java line number from Javascript
 exceptions thrown in a deployed production app (compiled with -style
 OBF)

 2). Out-of-process hosted mode (to enable using different browsers in
 hosted mode).

 3). A Declarative UI framework (one was started by Joel W. but seems
 to have been abandoned).

 4). Speed up compilation

 Java 5 support would have been #1 on this list a year ago.  You guys
 did a great job with GWT 1.5 - it included at least 2 giant leaps
 (Java 5 and the JSO/DOM framework), and I hope to see another big leap
 like that on the roadmap instead of features that add little value to
 GWT, like Tomcat vs. Jetty.

 In the end, if you decide to go forward with Jetty, I can come to
 terms with that, but I will need a good reason to upgrade to 1.6, like
 one of the 4 items on my list.

 Thanks for your time,
 Alex

 
  On Oct 13, 4:48 pm, Bruce Johnson [EMAIL PROTECTED] wrote:
 
   Hi everyone,
   Hope you're enjoying 1.5.
 
   The GWT team has started putting together a 1.6 roadmap, which we'll
   publish
   as soon as we have it nailed down. Two of the areas we want to work on
   for
   1.6 are some improvements tohostedmodestartup time and a friendlier
   output directory structure (something that looks more .war-like).
 
   As part of this effort, we've all but decided toswitchthehostedmode
  embeddedHTTPserverfromTomcattoJetty. Would this break you? (And if so,
   how mad would you be if we did it anyway?) We figure most people who
   really
   care about the web.xml and so on are already using -noserver to have
   full
   control over theirserverconfig.
 
   Thanks,
   Bruce



 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Your opinion sought: Jetty or Tomcat?

[Alex Epshteyn]

Bruce,

I might be too late in replying to this thread, but I want to phrase
my objections to what you've proposed.

A. Regarding Jetty:

I think this will be a waste of time for everyone.  Switching
underlying servers is a no value added task (using Six Sigma
vocabulary).

1).  Many developers are using -noserver so for them this will make no
difference.

2).  Many other developers have customized the embedded Tomcat to suit
our needs (I spent hours customizing it so that I don't have to run
with -noserver).   It will take hours to re-adjust again if you switch
underlying servers.

3). Why?  What's the benefit of switching to Jetty?  Tomcat startup is
like 5 seconds tops, which accounts for maybe 10% of the hosted mode
startup time.  You should speed up the compiler if you want to speed
up hosted mode.   I don't understand what Jetty has to offer here.
I'd be happy if you proved me wrong here, though.

B. Regarding the output directory structure:

I feel the same way about this as I do about Jetty.  I think this is a
waste of time - no real value added to GWT.  Most of us will have to
re-tweak our ant build configs which is always a waste of time.

C. Final thoughts

I'm really looking forward to seeing something of substance in the
roadmap for 1.6, because between what you've written here and what's
marked with 1_6_RC on the issue tracker, I see nothing of any value
except minor bug fixes.

Here are the top 3 features that I think would add real value to GWT:

1). A way to get meaningful Java line number from Javascript
exceptions thrown in a deployed production app (compiled with -style
OBF)

2). Out-of-process hosted mode (to enable using different browsers in
hosted mode).

3). A Declarative UI framework (one was started by Joel W. but seems
to have been abandoned).

4). Speed up compilation

Java 5 support would have been #1 on this list a year ago.  You guys
did a great job with GWT 1.5 - it included at least 2 giant leaps
(Java 5 and the JSO/DOM framework), and I hope to see another big leap
like that on the roadmap instead of features that add little value to
GWT, like Tomcat vs. Jetty.

In the end, if you decide to go forward with Jetty, I can come to
terms with that, but I will need a good reason to upgrade to 1.6, like
one of the 4 items on my list.

Thanks for your time,
Alex


 On Oct 13, 4:48 pm, Bruce Johnson [EMAIL PROTECTED] wrote:

  Hi everyone,
  Hope you're enjoying 1.5.

  The GWT team has started putting together a 1.6 roadmap, which we'll publish
  as soon as we have it nailed down. Two of the areas we want to work on for
  1.6 are some improvements tohostedmodestartup time and a friendlier
  output directory structure (something that looks more .war-like).

  As part of this effort, we've all but decided toswitchthehostedmode
 embeddedHTTPserverfromTomcattoJetty. Would this break you? (And if so,
  how mad would you be if we did it anyway?) We figure most people who really
  care about the web.xml and so on are already using -noserver to have full
  control over theirserverconfig.

  Thanks,
  Bruce
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Native GWT Compiler

[Alex Epshteyn]

I interpreted available in trunk to mean that it's a separate
version of the compiler in the trunk.  Has it replaced the single-
threaded compiler and can just be built and used as usual?

Alex

On Nov 12, 2:20 pm, eric [EMAIL PROTECTED] wrote:
 get it : The new multi-threaded compiler is available in trunk if
 you're interested

 use it : like the google web toolkit .

 regards .

 Le mercredi 12 novembre 2008 à 10:56 -0800, Alex Epshteyn a écrit :

  Hi Sumit,

  Thismultithreadedcompiler sounds intriguing.  Could you provide some
  guidance about how to get it and use it?

  Thanks,
  Alex

  On Oct 13, 1:08 pm, Sumit Chandel [EMAIL PROTECTED] wrote:
   Hi Rauf,
   There are currently no plans to rewrite the GWT compiler as a native
   compiler. There are plans to speedup compilation time with the current GWT
   compiler, however, and the team is in the know about long compilation 
   times
   that some developers have been experiencing when moving their projects 
   form
   1.4.x to 1.5.

   The new multi-threaded compiler is available in trunk if you're interested
   in checking it out to see if it helps speed up your application compile
   time.

   From benchmarks we've run and what some developers have been reporting, 
   the
   new multi-threaded compilation has been showing significant improvements 
   in
   compilation speed, so you should be getting faster results for your own
   project as well.

   Hope that helps,
   -Sumit Chandel

   On Wed, Oct 8, 2008 at 2:36 PM, Rauf Issa [EMAIL PROTECTED] wrote:

Any plans to write a native GWT Compiler like jikes for java? I know
there are plans to improve GWT compiler performance in the upcoming
1.6 release of GWT by multi-threading but I am not sure that will make
enough difference. A native compiler like jikes would be better and
much faster.

Our product, JobServer (job scheduling engine) uses GWT for its GUI
SDK and we compile GWT components on the fly the first time the GWT is
used. This frees the developer from doing the GWT compiler if they do
not want to. This works very well but the initial GWT compiling of the
GWT UI components can take minutes sometimes and is annoying. I would
really like this to be more like compiling JSP pages for example.

Anyway I can only hope that GWT compiling gets faster (right now it is
getting slower with all the advanced optimizations done in GWT 1.5 :)

Rauf Issa
   http://www.grandlogic.com
JobServer - The Most Comprehensive Java Job Scheduling Platform
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Native GWT Compiler

[Alex Epshteyn]

Hi Sumit,

This multithreaded compiler sounds intriguing.  Could you provide some
guidance about how to get it and use it?

Thanks,
Alex

On Oct 13, 1:08 pm, Sumit Chandel [EMAIL PROTECTED] wrote:
 Hi Rauf,
 There are currently no plans to rewrite the GWT compiler as a native
 compiler. There are plans to speedup compilation time with the current GWT
 compiler, however, and the team is in the know about long compilation times
 that some developers have been experiencing when moving their projects form
 1.4.x to 1.5.

 The new multi-threaded compiler is available in trunk if you're interested
 in checking it out to see if it helps speed up your application compile
 time.

 From benchmarks we've run and what some developers have been reporting, the
 new multi-threaded compilation has been showing significant improvements in
 compilation speed, so you should be getting faster results for your own
 project as well.

 Hope that helps,
 -Sumit Chandel

 On Wed, Oct 8, 2008 at 2:36 PM, Rauf Issa [EMAIL PROTECTED] wrote:

  Any plans to write a native GWT Compiler like jikes for java? I know
  there are plans to improve GWT compiler performance in the upcoming
  1.6 release of GWT by multi-threading but I am not sure that will make
  enough difference. A native compiler like jikes would be better and
  much faster.

  Our product, JobServer (job scheduling engine) uses GWT for its GUI
  SDK and we compile GWT components on the fly the first time the GWT is
  used. This frees the developer from doing the GWT compiler if they do
  not want to. This works very well but the initial GWT compiling of the
  GWT UI components can take minutes sometimes and is annoying. I would
  really like this to be more like compiling JSP pages for example.

  Anyway I can only hope that GWT compiling gets faster (right now it is
  getting slower with all the advanced optimizations done in GWT 1.5 :)

  Rauf Issa
 http://www.grandlogic.com
  JobServer - The Most Comprehensive Java Job Scheduling Platform
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Image Anchor widget.

[Alex Epshteyn]

Filed a bug for this: 
http://code.google.com/p/google-web-toolkit/issues/detail?id=3080

On Sep 29, 7:33 am, Marcelo Emanoel [EMAIL PROTECTED] wrote:
 try this:

 code

 import com.google.gwt.dom.client.AnchorElement;
 import com.google.gwt.dom.client.DivElement;
 import com.google.gwt.dom.client.Document;
 import com.google.gwt.user.client.Event;
 import com.google.gwt.user.client.ui.Image;
 import com.google.gwt.user.client.ui.Widget;

 public class ImageLink extends Widget {

     private Image img;
     private String url;
     private String target;

     private DivElement element;
     private AnchorElement aEl;

     public ImageLink(Image img, String url){
         initElements();
         setImg(img);
         setUrl(url);
     }

     private void initElements() {
         element = Document.get().createDivElement();
         aEl = Document.get().createAnchorElement();

         element.appendChild(aEl);
         setElement(element);

         sinkEvents(Event.MOUSEEVENTS);
         setTarget(_blank);
     }

     public void onBrowserEvent(Event event) {
         if(event.getTypeInt() == Event.ONMOUSEOVER){
             aEl.getStyle().setProperty(cursor, hand);
         }
         super.onBrowserEvent(event);
     }

     public ImageLink(){
         this(null, );
     }

     /**
      * @return the img
      */
     public Image getImg() {
         return img;
     }

     /**
      * @param img the img to set
      */
     public void setImg(Image img) {
         this.img = img;
         aEl.appendChild(img.getElement());
     }

     /**
      * @return the url
      */
     public String getUrl() {
         return url;
     }

     /**
      * @param url the url to set
      */
     public void setUrl(String url) {
         this.url = url;
         aEl.setHref(url);
     }

     /**
      * @return the target
      */
     public String getTarget() {
         return target;
     }

     /**
      * @param target the target to set
      */
     public void setTarget(String target) {
         this.target = target;
         aEl.setTarget(target);
     }

 }

 /code

 then you use your ImageBundle and pass the image to this widget...
 hope it helps you :)

 On Sep 26, 6:17 pm, Jean-Lou Dupont [EMAIL PROTECTED] wrote:

  The work-around for anybody who cares:  add a 'click listener' to the
  Anchor widget and do the navigation manually.
  Yet another reason why I don't like IE as much as the others...

  On Sep 26, 11:43 am, Jean-Lou Dupont [EMAIL PROTECTED] wrote:

   How would I go in creating a cross-browser Image Anchor ( i.e. a
   href=#somewhereimg src=somegraphic.png/a ) using an image
   bundle?

   I am having some troubles with IE6: there is an extra tag called
   clipper (e.g. clipperclass=gwt-Image ... ) that seems to be
   created with a style attribute that prevents the image from being
   clickable i.e. navigating to the anchor's link when clicked.

   Thanks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---