[gwt-contrib] IntelliJ IDEA project config
Hello, I've been developing apps with GWT for over a decade, and have been tinkering with the GWT internals quite a bit. I'm hoping to finally start contributing my work to the project. I use IntelliJ IDEA for all my work (not a fan of Eclipse), and I was wondering if anyone already has working IDEA project files that I could borrow? I could set it up myself, but it would be nice to not have to start from scratch, with stuff like code styles and module layouts (there are some tricky bits here, such as everything under gwt/user/super/com/google/gwt/emul/ <https://github.com/gwtproject/gwt/tree/master/user/super/com/google/gwt/emul>, where package names don't correspond to the actual directory tree) Would appreciate any help I could get from the community! Thanks, Alex Epshteyn https://github.com/aepshteyn -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/8e18faa8-1999-41fd-8fde-9b1ad5d5c7cb%40googlegroups.com. 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
Hi Colin, please find my answers inline: On Tue, Aug 20, 2013 at 11:35 PM, Colin Alworth 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.
[gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
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: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
> > 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.
[gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
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.
[gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
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, a
[gwt-contrib] I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
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: [gwt-contrib] Re: Linker bug with useSourceMaps
Thanks Thomas! I appreciate it. I'll give it a try! On Wed, Apr 10, 2013 at 5:01 PM, Thomas Broyer 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.
Re: [gwt-contrib] Re: Linker bug with useSourceMaps
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 wrote: > 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
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. Alex On Wed, Apr 10, 2013 at 2:34 PM, Thomas Broyer wrote: > > > On Wednesday, April 10, 2013 8:03:41 PM UTC+2, Alex Epshteyn wrote: >> >> 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<https://developers.google.com/web-toolkit/makinggwtbetter> >> still valid? >> > > Apart from the Rietveld/Gerrit part, they're OK. > > >> I'm a little confused because that document says "Upload the patch to >> the Rietveld instance at >> http://gwt-code-reviews.**appspot.com/<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/<https://gwt-review.googlesource.com/> >> > > Yes, we're switching from SVN and Rietveld to Git and Gerrit, so if you > can use Git, please do. > Feel free to ask for guidance here if needed. Setting up your Git for use > with Gerrit requires a few special invocations so if you have a problem > don't hesitate to ask (we'll then use that in our new docs). > > -- > -- > 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] Re: Linker bug with useSourceMaps
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
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. name="compiler.useSourceMaps" value="true"/>)
>
> However, something like
>
>
>
>
>
> 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] Linker bug with useSourceMaps
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. )
However, something like
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] RPC payload question: Why use fully qualified class names?
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
[gwt-contrib] Re: I've implemented Java stack trace support for web mode
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, jay 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 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 wrote: >> > On Wed, May 6, 2009 at 4:49 PM, Alex Epshteyn >> > 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 &
[gwt-contrib] Re: I've implemented Java stack trace support for web mode
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 wrote: > On Wed, May 6, 2009 at 4:49 PM, Alex Epshteyn > 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
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 wrote: > On Wed, May 6, 2009 at 4:15 PM, Alex Epshteyn > 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] Re: I've implemented Java stack trace support for web mode
Yes, we discussed it some time ago. How is that coming along? Alex On Wed, May 6, 2009 at 8:56 AM, Joel Webber wrote: > @bob: Weren't you doing some work to produce map files automatically and get > back a clean stack trace on the server? Is that something available in > trunk? > > On Wed, May 6, 2009 at 4:28 AM, Alex Epshteyn > wrote: >> >> 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 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 >> > >> > 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 >> >> 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
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 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 > 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 >> 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
> 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 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] I've implemented Java stack trace support for web mode
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: Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets
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 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 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 element."
Alex
On Fri, Jan 23, 2009 at 1:25 AM, Ray Cromwell 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.
>
>
> 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
> 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
>> 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?
>> >
[gwt-contrib] Re: Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets
Ray, I'm not arguing against Bob's gwt-gadgets library, if that's what you want to use. I just wanted to point out that it's easy to write social gadgets without it. It's too heavyweight for my liking, but I shouldn't have said anything about that in the first place because that's not the point of this thread. I agree that the difference between container implementations is a big problem with opensocial. I guess you could argue that gwt-gadgets could do for the container differences what GWT did for browser differences. 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 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, probably 90% of the work is workarounds of > unsupported or broken features. > -Ray > On Thu, Jan 22, 2009 at 2:17 PM, Alex Epshteyn > wrote: >> >> 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 >> 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 annotatio
[gwt-contrib] Re: Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets
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 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 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 >> 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
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 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 > 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 -~--~~~~--~~--~--~---
[gwt-contrib] Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets
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: RR : Pluggable CompilePerms workers
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.ThreadedPermutationWorkerFactory"and "-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 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 wrote: > > > On Thu, Nov 20, 2008 at 8:58 PM, Scott Blum 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: RR : Pluggable CompilePerms workers
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 wrote: > On Thu, Nov 20, 2008 at 8:58 PM, Scott Blum 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
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 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 > 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 wrote: > > > > On Tue, Jan 13, 2009 at 4:10 PM, gregor > > > 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
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 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 wrote: > > > On Tue, Jan 13, 2009 at 4:10 PM, gregor > > 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 -~--~~~~--~~--~--~---
