Re: [gwt-contrib] Inlining nocache.js
Thanks Matt, that does the trick.
Actually I'm just post processing a template host html page with an ant
task before deployment, that solves the decoupling concern.
On 17.12.2009 21:06, Matt Mastracci wrote:
If it's the same error we ran into, it's that there are things that look like
HTML script and comment tags in the linker script that throw the parser off.
Note how we broke up the script start tags and comment start/end tags the
same way as the script end tags:
XSLinker:
var compiledScriptTag = 'script src=\\' + base + strongName +
'.cache.js\\/scr + ipt';
$doc.write('script!--\n'
+ 'window.__gwtStatsEvent window.__gwtStatsEvent({'
+ 'moduleName:__MODULE_NAME__, sessionId:$sessionId,
subSystem:startup,'
+ 'evtGroup: loadExternalRefs, millis:(new Date()).getTime(),'
+ 'type: end});'
+ 'window.__gwtStatsEvent window.__gwtStatsEvent({'
+ 'moduleName:__MODULE_NAME__, sessionId:$sessionId,
subSystem:startup,'
+ 'evtGroup: moduleStartup, millis:(new Date()).getTime(),'
+ 'type: moduleRequested});'
+ 'document.write(' + compiledScriptTag + ');'
+ '\n--/script');
Our linker:
var compiledScriptTag = 'scr'+'ipt src=\\' + base + strongName +
'\\/scr + ipt';
$doc.write('scr'+'ipt!-'+'-\n'
+ 'window.__gwtStatsEvent window.__gwtStatsEvent({'
+ 'moduleName:__MODULE_NAME__, subSystem:startup,'
+ 'evtGroup: loadExternalRefs, millis:(new Date()).getTime(),'
+ 'type: end});'
+ 'window.__gwtStatsEvent window.__gwtStatsEvent({'
+ 'moduleName:__MODULE_NAME__, subSystem:startup,'
+ 'evtGroup: moduleStartup, millis:(new Date()).getTime(),'
+ 'type: moduleRequested});'
+ 'document.write(' + compiledScriptTag + ');'
+ '\n-'+'-/scr'+'ipt');
We've had inlining working on dotspots.com in GWT trunk for a while now, but
I'm considering going back to an external nocache.js so we can more easily
decouple our static content from the GWT code.
Matt.
On 2009-12-17, at 12:40 PM, George Georgovassilis wrote:
Some time ago we discussed [1] inlining nocache.js into the host page
to speed up initial page load, which I find quite worthwhile a read.
While back in the 1.7 days I managed to inline nochache.js with a
modest effort of post processing (escaping some javascript), 2.0
defeats me. I can't find a way to inline the GWT 2.0 compiler's
nocache.js into the host page without always running into some
javascript syntax error, which prohibits the entire code from loading.
Any hints?
[1]
http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/8127c586073b1711/2eeb884f6f5cdcbf?lnk=gstq=inline#2eeb884f6f5cdcbf
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: wrong DTD generated for modules in GEP
Hi, Small question: Is there a reason why GWT is still using a DTD instead of a schema ? In Schema's you can put a lot extra information (inline docs) and eclipse also supports completions with schemas if you put the schema in the XML repository. David On Thu, Dec 17, 2009 at 11:59 PM, Fushion menno.van.gange...@gmail.com wrote: This one is better: http://google-web-toolkit.googlecode.com/svn/releases/2.0/distro-source/core/src/gwt-module.dtd On 17 dec, 16:56, Arthur Kalmenson arthur.k...@gmail.com wrote: Hey everyone, I just noticed that the DTD used in the GWT modules generated by the GEP is incorrect. It points tohttp://google-web-toolkit.googlecode.com/svn/tags/2.0.0/distro-source... which doesn't exist. Looks like the fix would be pretty easy though, just create a 2.0.0 tag in the repo, becausehttp://google-web-toolkit.googlecode.com/svn/tags/2.0.0-rc1/distro-so... works. All the best, -- Arthur Kalmenson -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: uibinder and bnudled CSS
Right, I got the warning but did not understand what it related to. Thanks a lot On 17 déc, 23:20, John Huss johnth...@gmail.com wrote: I think you have to escape the css attributes that start with a dash like this: \-moz-box-shadow: 2px 2px 5px #000; You should be getting a warning about it in dev mode if you are not - making sure you having logging on at a good level. John On Dec 17, 6:03 am, nicolas.deloof nicolas.del...@gmail.com wrote: Hi I'm migrating some nice HTML-fragment to GWT. Thanks to UiBinder this is really easy and I get a nice result in few hours. I notice the uiBinder seems to rewrite the CSS rules according to browser support (I may be wrong) : my CSS uses CSS3 box-shadow : box-shadow: 2px 2px 5px #000; -moz-box-shadow: 2px 2px 5px #000; -webkit-box-shadow: 2px 2px 5px #000; This works fine on my Chrome browser, but when I use the uibinder version I dont' have shadows anymore. The CSS rule filter should not remove any -webkit* rule when targeting a webkit based browser, sould'it ? Also the box-shadow is supported by recent webkit browsers (it is on chrome 4, but this is in the dev channel) 2nd question : If my CSS uses background-image: url(...), can I include those images in my ClientBundle and still make references to them in my CSS fragement ? Cheers, Nicolas -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: now.. afetr GWT 2.0?
Arthur, No, we are not closing DevMode. Our client app is not small. Refreshing DevMode in 2.0 takes 20-30 seconds on a decent multi-core workstation. Often, we are only able to refresh a handful of times before we start running into out-of-memory exceptions and browser crashes (FF 3.5.6). I don't want to sound unappreciative - DevMode in 2.0 is MUCH MUCH faster than before. We are very excited about this. However, I rarely need to use the debugger in the actual client. Most of the time I just want to refresh the layout or test the usability of a widget. For this, DevMode is overkill and, in fact, useless for testing real world UI latency. Draft Compile is a wonderful idea but even it takes over a minute to compile a single permutation of our app. At the end of the day, all i want to do is make a small change to a widget and refresh my browser to test the layout, look and feel, and usability. over and over and over. Sometimes i might need to debug my ui logic but not most of the time. Brad -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] New member posting policy
Dear Contributors, Unfortunately, the GWT Contributors Group has been getting a lot of spam attacks as of late and most spam posts have been making it through. To fight against these spam attacks, we will be temporarily moderating messages posted by new members to the group. The GWT contributor forum will still be as accessible as ever, we will post any message relevant to GWT without hesitation. We're only putting this moderation policy in place to deal with the spam. Thanks, Chris Ramsdale -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: now.. afetr GWT 2.0?
same problems unfortunately 2009/12/18 Brad Leupen qcomps...@gmail.com Arthur, No, we are not closing DevMode. Our client app is not small. Refreshing DevMode in 2.0 takes 20-30 seconds on a decent multi-core workstation. Often, we are only able to refresh a handful of times before we start running into out-of-memory exceptions and browser crashes (FF 3.5.6). I don't want to sound unappreciative - DevMode in 2.0 is MUCH MUCH faster than before. We are very excited about this. However, I rarely need to use the debugger in the actual client. Most of the time I just want to refresh the layout or test the usability of a widget. For this, DevMode is overkill and, in fact, useless for testing real world UI latency. Draft Compile is a wonderful idea but even it takes over a minute to compile a single permutation of our app. At the end of the day, all i want to do is make a small change to a widget and refresh my browser to test the layout, look and feel, and usability. over and over and over. Sometimes i might need to debug my ui logic but not most of the time. Brad -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Trivial fix for issue 3956 (REGRESSION: r5292 broke Opera support for History)
Reviewers: jgw, Description: This is a *really* trivial fix. Please review this at http://gwt-code-reviews.appspot.com/126812 Affected files: user/src/com/google/gwt/user/History.gwt.xml Index: user/src/com/google/gwt/user/History.gwt.xml === --- user/src/com/google/gwt/user/History.gwt.xml(revision 7333) +++ user/src/com/google/gwt/user/History.gwt.xml(working copy) @@ -30,7 +30,13 @@ /any /replace-with - !-- Safari has yet another slightly different implementation. -- + !-- Opera has yet another slightly different implementation. -- + replace-with class=com.google.gwt.user.client.impl.HistoryImplTimer + when-type-is class=com.google.gwt.user.client.impl.HistoryImpl/ + when-property-is name=user.agent value=opera/ + /replace-with + + !-- Safari is almost like Opera, but again slightly different. -- replace-with class=com.google.gwt.user.client.impl.HistoryImplSafari when-type-is class=com.google.gwt.user.client.impl.HistoryImpl/ when-property-is name=user.agent value=safari/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7334 committed - Tagging 2.0.0-rc2.
Revision: 7334 Author: sco...@google.com Date: Fri Dec 18 07:07:21 2009 Log: Tagging 2.0.0-rc2. http://code.google.com/p/google-web-toolkit/source/detail?r=7334 Added: /tags/2.0.0-rc2 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7335 committed - Tagging 2.0.0.
Revision: 7335 Author: sco...@google.com Date: Fri Dec 18 07:07:53 2009 Log: Tagging 2.0.0. http://code.google.com/p/google-web-toolkit/source/detail?r=7335 Added: /tags/2.0.0 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Use cellIndex and sectionRowIndex in HTMLTable::getCellForEvent
Reviewers: jgw,
Description:
See
http://groups.google.com/group/google-web-toolkit-contributors/t/a0b141cf7ea77a56
This is done by using com.google.gwt.dom.DOM's TableCellElement and
TableRowElement, so I also changed everything (exception
public/protected APIs) from com.google.gwt.user.client.Element to
com.google.gwt.dom.client.Element.
Note that I therefore replaced DOM.insertChild(parent, newChild, index)
with:
if (index parent.getChildCount()) {
parent.insertBefore(newChild, parent.getChild(insert));
} else {
parent.appendChild();
}
which is *not* strictly equivalent but works the same here because we
have full control over the generated DOM (DOM.insertChild deals with
Elements only, while the new code is all about nodes, whether they're
elements, or text or comment nodes).
This patch also includes an unrelated very small change to
DOMImplStandard (don't get the nextSibling in cases we might not even
use it).
Ran DOMTest in Chrome Dev Channel; and FlexTableTest and GridTest in IE6
and Chrome (all tests run in -prod mode)
Please review this at http://gwt-code-reviews.appspot.com/125806
Affected files:
user/src/com/google/gwt/user/client/impl/DOMImplStandard.java
user/src/com/google/gwt/user/client/impl/ElementMapperImpl.java
user/src/com/google/gwt/user/client/ui/HTMLTable.java
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Using cellIndex and rowIndex/sectionRowIndex to get cells' position in tables
On Dec 16, 3:16 pm, Joel Webber j...@google.com wrote: Thomas, Your assessment that this is an accidental legacy is basically correct. This code should definitely be optimized -- if you could file an issue, that would be helpful. Hopefully it makes little difference in practice, because of the infrequent nature of click events, but it would still be good to get it fixed. Patch sent for review: http://gwt-code-reviews.appspot.com/125806 Tell me if you also want an issue filed on the project's issue tracker. I'm also sure that it will ultimately be more efficient to build up HTML strings than to build a table programatically (no matter how silly that may be). I'm starting to do a lot of experiments on DOM and HTML parsing speed that tentatively support this view. We will ultimately need to find a way to support this mechanism in the core GWT widgets, which we'll be looking into this year. That's good news Joel! (if it could just be simpler than the bulk loaders from the incubator, bulk loader's API looks a bit over-engineered to me) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: now.. afetr GWT 2.0?
Thanks for the feedback Brad. We've talked internally about an idea for instant compile where the workflow would be essentially like hosted mode, except it would very quickly translate your code into JavaScript with zero optimizations. It sounds like there might be some interest in this. (Of course, we also want to make hosted mode much faster than it is even in 2.0!) On Fri, Dec 18, 2009 at 9:50 AM, Brad Leupen qcomps...@gmail.com wrote: Arthur, No, we are not closing DevMode. Our client app is not small. Refreshing DevMode in 2.0 takes 20-30 seconds on a decent multi-core workstation. Often, we are only able to refresh a handful of times before we start running into out-of-memory exceptions and browser crashes (FF 3.5.6). I don't want to sound unappreciative - DevMode in 2.0 is MUCH MUCH faster than before. We are very excited about this. However, I rarely need to use the debugger in the actual client. Most of the time I just want to refresh the layout or test the usability of a widget. For this, DevMode is overkill and, in fact, useless for testing real world UI latency. Draft Compile is a wonderful idea but even it takes over a minute to compile a single permutation of our app. At the end of the day, all i want to do is make a small change to a widget and refresh my browser to test the layout, look and feel, and usability. over and over and over. Sometimes i might need to debug my ui logic but not most of the time. Brad -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] wrong DTD generated for modules in GEP
The 2.0.0 release has been tagged. The DTD references should be correct now. Thanks for pointing this out! On Thu, Dec 17, 2009 at 10:56 AM, Arthur Kalmenson arthur.k...@gmail.comwrote: Hey everyone, I just noticed that the DTD used in the GWT modules generated by the GEP is incorrect. It points to http://google-web-toolkit.googlecode.com/svn/tags/2.0.0/distro-source/core/src/gwt-module.dtd which doesn't exist. Looks like the fix would be pretty easy though, just create a 2.0.0 tag in the repo, because http://google-web-toolkit.googlecode.com/svn/tags/2.0.0-rc1/distro-source/core/src/gwt-module.dtd works. All the best, -- Arthur Kalmenson -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Fix two CompileReport XML issues
Reviewers: Lex, Description: Hi Lex, could you review this patch for me? It fixes two XML issues in the CompileReport: 1) There was a bug in the escapeXML method that would let all special characters after the first one slip through. This is now fixed. 2) Because of the difference in encoding for Java and for HTML as displayed in the browser, some characters were not displayed properly. Thanks! kathrin Please review this at http://gwt-code-reviews.appspot.com/126813 Affected files: dev/core/src/com/google/gwt/core/ext/soyc/impl/SizeMapRecorder.java dev/core/src/com/google/gwt/soyc/MakeTopLevelHtmlForPerm.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: wrong DTD generated for modules in GEP
On Fri, Dec 18, 2009 at 5:09 AM, David david.no...@gmail.com wrote: Hi, Small question: Is there a reason why GWT is still using a DTD instead of a schema ? In Schema's you can put a lot extra information (inline docs) and eclipse also supports completions with schemas if you put the schema in the XML repository. The main reason is that someone who knew DTDs well put one together. Completions based on the DTD should still work in eclipse so long as the DTD URL can be resolved. They don't necessarily have to be part of eclipse's catalog. David On Thu, Dec 17, 2009 at 11:59 PM, Fushion menno.van.gange...@gmail.com wrote: This one is better: http://google-web-toolkit.googlecode.com/svn/releases/2.0/distro-source/core/src/gwt-module.dtd On 17 dec, 16:56, Arthur Kalmenson arthur.k...@gmail.com wrote: Hey everyone, I just noticed that the DTD used in the GWT modules generated by the GEP is incorrect. It points tohttp:// google-web-toolkit.googlecode.com/svn/tags/2.0.0/distro-source... which doesn't exist. Looks like the fix would be pretty easy though, just create a 2.0.0 tag in the repo, becausehttp:// google-web-toolkit.googlecode.com/svn/tags/2.0.0-rc1/distro-so... works. All the best, -- Arthur Kalmenson -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: now.. afetr GWT 2.0?
Scott, That sounds great! It's reassuring to know y'all are thinking about this. I know it's not an easy problem to solve. Brad -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: now.. afetr GWT 2.0?
shortly, you intend to make a kind of incremental compilationnot of course in .class but .js. It seems good to me. 2009/12/18 Brad Leupen qcomps...@gmail.com Scott, That sounds great! It's reassuring to know y'all are thinking about this. I know it's not an easy problem to solve. Brad -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: now.. afetr GWT 2.0?
- Wrap Google Closure Library (http://code.google.com/closure/ library/) On 16 Dic, 18:01, Bruce Johnson br...@google.com wrote: Working on a draft one. What do folks here think is important? On Wed, Dec 16, 2009 at 7:42 AM, tfreitas tfrei...@gmail.com wrote: What about roadmap? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] GWT meetup group
I'd like to introduce GWT meeting group, so all GWT developers can meet each other. See details here: http://www.meetup.com/GWT-developement/ Peter -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: now.. afetr GWT 2.0?
Hey Brad, Sorry about that, I've just seen a number of people in the IRC channel asking about why DevMode was so slow and it turned out they had been closing it after each check. I just wanted to throw that comment up there for those that didn't know. I guess our apps haven't got to that size yet All the best, -- Arthur Kalmenson On Fri, Dec 18, 2009 at 9:50 AM, Brad Leupen qcomps...@gmail.com wrote: Arthur, No, we are not closing DevMode. Our client app is not small. Refreshing DevMode in 2.0 takes 20-30 seconds on a decent multi-core workstation. Often, we are only able to refresh a handful of times before we start running into out-of-memory exceptions and browser crashes (FF 3.5.6). I don't want to sound unappreciative - DevMode in 2.0 is MUCH MUCH faster than before. We are very excited about this. However, I rarely need to use the debugger in the actual client. Most of the time I just want to refresh the layout or test the usability of a widget. For this, DevMode is overkill and, in fact, useless for testing real world UI latency. Draft Compile is a wonderful idea but even it takes over a minute to compile a single permutation of our app. At the end of the day, all i want to do is make a small change to a widget and refresh my browser to test the layout, look and feel, and usability. over and over and over. Sometimes i might need to debug my ui logic but not most of the time. Brad -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fix two CompileReport XML issues
LGTM. If we work much more on this area, though, here's an alternative approach. Instead of working around Unicode obscurities, we could encode strings using a Java-like encoding. For example, 0 would become \u, and \ would become \\. Going that way, reading and writing these XML files would be lossless. Additionally, we should have fewer questions about whether we have nailed the last obscure Unicode problem or if more are lurking. http://gwt-code-reviews.appspot.com/126813/diff/1/2 File dev/core/src/com/google/gwt/core/ext/soyc/impl/SizeMapRecorder.java (right): http://gwt-code-reviews.appspot.com/126813/diff/1/2#newcode153 Line 153: continue; These continues are implied, aren't they? They could be left out to make the code shorter. http://gwt-code-reviews.appspot.com/126813 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Using cellIndex and rowIndex/sectionRowIndex to get cells' position in tables
On Fri, Dec 18, 2009 at 10:16 AM, Thomas Broyer t.bro...@gmail.com wrote: On Dec 16, 3:16 pm, Joel Webber j...@google.com wrote: Thomas, Your assessment that this is an accidental legacy is basically correct. This code should definitely be optimized -- if you could file an issue, that would be helpful. Hopefully it makes little difference in practice, because of the infrequent nature of click events, but it would still be good to get it fixed. Patch sent for review: http://gwt-code-reviews.appspot.com/125806 Tell me if you also want an issue filed on the project's issue tracker. Cool, thanks. I'll have a look this afternoon. I'm also sure that it will ultimately be more efficient to build up HTML strings than to build a table programatically (no matter how silly that may be). I'm starting to do a lot of experiments on DOM and HTML parsing speed that tentatively support this view. We will ultimately need to find a way to support this mechanism in the core GWT widgets, which we'll be looking into this year. That's good news Joel! (if it could just be simpler than the bulk loaders from the incubator, bulk loader's API looks a bit over-engineered to me) I agree. They evolved over time through a couple of different authors. I think we can do something a lot simpler. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Arrays implement Serializable and Cloneable
http://gwt-code-reviews.appspot.com/125803/diff/1/3 File dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java (right): http://gwt-code-reviews.appspot.com/125803/diff/1/3#newcode480 Line 480: } Will do. http://gwt-code-reviews.appspot.com/125803/diff/1/3#newcode1032 Line 1032: allArrayTypes.add(arrayType); I agree the rule is just kinda crammed in there. It is how it is specced, though. Check out the following link. They really just list out two extra rules for Serializable and Cloneable that come out of nowhere: http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.10.3 I like that canTriviallyCast and the JType hierarchy can follow the JLS fairly closely, because subtyping rules are tricky to rederive. We're still stuck deriving canTheoreticallyCast, strongerType, and generalizeType ourselves, and it's simply on us to make sure they are consistent with canTriviallyCast. I would love a way to do those three more systematically, but as it stands we just have to be careful. The good news is that the difficulty stops at those four methods. The rest of the compiler can reason about the type system by breaking questions down to these four basic methods. For example, the present patch does not need to touch CastNormalizer http://gwt-code-reviews.appspot.com/125803 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: now.. afetr GWT 2.0?
Has everyone responding in this thread been checking the issue tracker, staring issues they want to see resolved, and entering new issues where they don't yet exist in the tracker? I know several of the requests mentioned in this thread are already in there. http://code.google.com/p/google-web-toolkit/issues/list On Fri, Dec 18, 2009 at 11:18 AM, Chris chrish...@gmail.com wrote: I would encourage any effort to get an instant compile feature in dev mode. When designing the GUI and tweaking a widget here or there or css, a quick turn around would be a huge win. Right now, tweaking the GUI is a cumbersome process. Chris On Dec 18, 10:16 am, Scott Blum sco...@google.com wrote: Thanks for the feedback Brad. We've talked internally about an idea for instant compile where the workflow would be essentially like hosted mode, except it would very quickly translate your code into JavaScript with zero optimizations. It sounds like there might be some interest in this. (Of course, we also want to make hosted mode much faster than it is even in 2.0!) On Fri, Dec 18, 2009 at 9:50 AM, Brad Leupen qcomps...@gmail.com wrote: Arthur, No, we are not closing DevMode. Our client app is not small. Refreshing DevMode in 2.0 takes 20-30 seconds on a decent multi-core workstation. Often, we are only able to refresh a handful of times before we start running into out-of-memory exceptions and browser crashes (FF 3.5.6). I don't want to sound unappreciative - DevMode in 2.0 is MUCH MUCH faster than before. We are very excited about this. However, I rarely need to use the debugger in the actual client. Most of the time I just want to refresh the layout or test the usability of a widget. For this, DevMode is overkill and, in fact, useless for testing real world UI latency. Draft Compile is a wonderful idea but even it takes over a minute to compile a single permutation of our app. At the end of the day, all i want to do is make a small change to a widget and refresh my browser to test the layout, look and feel, and usability. over and over and over. Sometimes i might need to debug my ui logic but not most of the time. Brad -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: now.. afetr GWT 2.0?
Arthur, It's a good tip, especially when hot swap tells you that you need to restart. For our app, we resorted to creating sandbox GWT entry points to develop widgets in isolation. This gave us usable compile/refresh times but I still long for the days when I could just press F5 to refresh the whole thing. :) Another wish list item: a less API-invasive approach to protecting against XSRF attacks (see: http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications). It seems to me that XSRF checks could be baked into the RPC plumbing, perhaps triggered by annotations on the RPC service interface. Brad -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: now.. afetr GWT 2.0?
On Fri, Dec 18, 2009 at 11:25 AM, Brad Leupen qcomps...@gmail.com wrote: Another wish list item: a less API-invasive approach to protecting against XSRF attacks (see: http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications ). It seems to me that XSRF checks could be baked into the RPC plumbing, perhaps triggered by annotations on the RPC service interface. The plan for this is at http://code.google.com/p/google-web-toolkit/wiki/RpcAuth though I have no timetable for when it will get implemented. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fix two CompileReport XML issues
Thanks, Lex! I had thought about the approach you suggest here, and maybe that's the right (safe) way to go -- the only problem with it is that if you have a unicode character in your string, it wouldn't display properly in the browser. In other words, for \u00CA you wouldn't see Ê, but rather \u00CA. Unless you are suggesting that we'd do another escaping pass for display in the browser? kathrin On Fri, Dec 18, 2009 at 11:07 AM, sp...@google.com wrote: LGTM. If we work much more on this area, though, here's an alternative approach. Instead of working around Unicode obscurities, we could encode strings using a Java-like encoding. For example, 0 would become \u, and \ would become \\. Going that way, reading and writing these XML files would be lossless. Additionally, we should have fewer questions about whether we have nailed the last obscure Unicode problem or if more are lurking. http://gwt-code-reviews.appspot.com/126813/diff/1/2 File dev/core/src/com/google/gwt/core/ext/soyc/impl/SizeMapRecorder.java (right): http://gwt-code-reviews.appspot.com/126813/diff/1/2#newcode153 Line 153: continue; These continues are implied, aren't they? They could be left out to make the code shorter. http://gwt-code-reviews.appspot.com/126813 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7336 committed - Sort and format.
Revision: 7336
Author: sp...@google.com
Date: Fri Dec 18 09:13:44 2009
Log: Sort and format.
http://code.google.com/p/google-web-toolkit/source/detail?r=7336
Modified:
/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java
/trunk/dev/core/test/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizerTest.java
===
---
/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java
Wed Nov 11 11:58:14 2009
+++
/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java
Fri Dec 18 09:13:44 2009
@@ -51,11 +51,11 @@
parameterValues.put(((JParameterRef) x.getLhs()).getParameter(),
null);
}
}
-
+
@Override
public void endVisit(JMethodCall x, Context ctx) {
JMethod method = x.getTarget();
-
+
if (x.canBePolymorphic() || rescuedMethods.contains(method)) {
return;
}
@@ -112,27 +112,27 @@
rescuedMethods.add(x);
} else {
JMethod staticImpl = program.staticImplFor(x);
-if (staticImpl != null
-
staticImpl.getEnclosingType().getMethods().contains(staticImpl)) {
+if (staticImpl != null
+
staticImpl.getEnclosingType().getMethods().contains(staticImpl)) {
// instance method is still alive.
rescuedMethods.add(x);
}
}
return true;
}
-
+
private boolean equalLiterals(JValueLiteral l1, JValueLiteral l2) {
Object v1 = l1.getValueObj();
Object v2 = l2.getValueObj();
-
+
if (v1 == v2) {
return true;
}
-
+
if (v1 == null || v2 == null) {
return false;
}
-
+
return v1.equals(v2);
}
}
@@ -167,23 +167,22 @@
/**
* Parameter values.
*
- * If doesn't contain a parameter, then its value is unknown.
- * If contains parameter, and value is null - the parameter's value is
not the
- * same across all calls.
- * If value is not null - the parameter's value is the same across all
calls.
+ * If doesn't contain a parameter, then its value is unknown. If contains
+ * parameter, and value is null - the parameter's value is not the same
across
+ * all calls. If value is not null - the parameter's value is the same
across
+ * all calls.
*/
- private MapJParameter, JValueLiteral parameterValues =
-new IdentityHashMapJParameter, JValueLiteral();
+ private MapJParameter, JValueLiteral parameterValues = new
IdentityHashMapJParameter, JValueLiteral();
+
+ private final JProgram program;
/**
- * These methods should not be tried to optimized due to their
polymorphic
+ * These methods should not be tried to optimized due to their
polymorphic
* nature.
*
* TODO: support polymorphic calls properly.
*/
private SetJMethod rescuedMethods = new HashSetJMethod();
-
- private final JProgram program;
private SameParameterValueOptimizer(JProgram program) {
this.program = program;
@@ -200,8 +199,8 @@
}
JValueLiteral valueLiteral = parameterValues.get(parameter);
if (valueLiteral != null) {
-SubstituteParameterVisitor substituteParameterVisitor =
- new SubstituteParameterVisitor(parameter, valueLiteral);
+SubstituteParameterVisitor substituteParameterVisitor = new
SubstituteParameterVisitor(
+parameter, valueLiteral);
substituteParameterVisitor.accept(parameter.getEnclosingMethod());
madeChanges |= substituteParameterVisitor.didChange();
}
===
---
/trunk/dev/core/test/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizerTest.java
Wed Nov 11 11:58:14 2009
+++
/trunk/dev/core/test/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizerTest.java
Fri Dec 18 09:13:44 2009
@@ -10,39 +10,6 @@
* Test for SameParameterValueOptimizer.
*/
public class SameParameterValueOptimizerTest extends OptimizerTestBase {
- public void testSameParameter() throws Exception {
-assertOptimize(foo, static void foo(int i) { int j = i; },
-foo(1); foo(1);).into(
-public static void foo(int i){,
- int j = 1;,
-});
- }
-
- public void testDifferentParameter() throws Exception {
-assertOptimize(foo, static void foo(int i) { int j = i; },
-foo(1); foo(2);).into(
-public static void foo(int i){,
- int j = i;,
-});
- }
-
- public void testNonConstParameter() throws Exception {
-assertOptimize(foo, static int foo(int i) { return i; },
-foo(foo(1));).into(
-public static int foo(int i){,
- return i;,
-});
- }
-
- private OptimizationResult assertOptimize(String methodName,
- String methodDecl, String codeSnippet) throws
UnableToCompleteException {
-addSnippetClassDecl(methodDecl);
-JProgram program =
[gwt-contrib] SameParameterValueOptimizer needs a cast for numeric literals
Reviewers: bobv,
Description:
Otherwise, it can end up treating, for example, an integer as a long.
Please review this at http://gwt-code-reviews.appspot.com/126814
Affected files:
dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java
dev/core/test/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizerTest.java
Index:
dev/core/test/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizerTest.java
===
---
dev/core/test/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizerTest.java
(revision 7336)
+++
dev/core/test/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizerTest.java
(working copy)
@@ -40,6 +40,12 @@
public static int foo(int i){, return i;, });
}
+ public void testNumericCast() throws Exception {
+assertOptimize(foo, static void foo(long i) { long j = i; },
+foo(1); foo(1);).into(public static void foo(long i){,
+ long j = 1L;, });
+ }
+
public void testSameParameter() throws Exception {
assertOptimize(foo, static void foo(int i) { int j = i; },
foo(1); foo(1);).into(public static void foo(int i){,
Index:
dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java
===
---
dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java
(revision 7336)
+++
dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java
(working copy)
@@ -173,7 +173,6 @@
* all calls.
*/
private MapJParameter, JValueLiteral parameterValues = new
IdentityHashMapJParameter, JValueLiteral();
-
private final JProgram program;
/**
@@ -183,9 +182,11 @@
* TODO: support polymorphic calls properly.
*/
private SetJMethod rescuedMethods = new HashSetJMethod();
+ private final Simplifier simplifier;
private SameParameterValueOptimizer(JProgram program) {
this.program = program;
+simplifier = new Simplifier(program);
}
private boolean execImpl(JNode node) {
@@ -200,7 +201,7 @@
JValueLiteral valueLiteral = parameterValues.get(parameter);
if (valueLiteral != null) {
SubstituteParameterVisitor substituteParameterVisitor = new
SubstituteParameterVisitor(
-parameter, valueLiteral);
+parameter, simplifier.cast(parameter.getType(), valueLiteral));
substituteParameterVisitor.accept(parameter.getEnclosingMethod());
madeChanges |= substituteParameterVisitor.didChange();
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: SameParameterValueOptimizer needs a cast for numeric literals
LGTM http://gwt-code-reviews.appspot.com/126814 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Arrays implement Serializable and Cloneable
http://gwt-code-reviews.appspot.com/125803/diff/1/3 File dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java (right): http://gwt-code-reviews.appspot.com/125803/diff/1/3#newcode1032 Line 1032: allArrayTypes.add(arrayType); LGTM then. Maybe we could just drop a one-line future-proofer comment around JTypeOracle(330) to the effect that Clonable/Serializable can theoretically cast through array types? http://gwt-code-reviews.appspot.com/125803 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7337 committed - Call servlet.log(message) instead of servlet.log(message, (Throwable) ...
Revision: 7337
Author: r...@google.com
Date: Fri Dec 18 10:10:29 2009
Log: Call servlet.log(message) instead of servlet.log(message, (Throwable)
null)
to avoid NPEs in some servlet containers.
Review by: bobv
http://code.google.com/p/google-web-toolkit/source/detail?r=7337
Modified:
/trunk/user/src/com/google/gwt/user/server/rpc/HybridServiceServlet.java
/trunk/user/src/com/google/gwt/user/server/rpc/RemoteServiceServlet.java
===
---
/trunk/user/src/com/google/gwt/user/server/rpc/HybridServiceServlet.java
Wed Oct 28 09:10:53 2009
+++
/trunk/user/src/com/google/gwt/user/server/rpc/HybridServiceServlet.java
Fri Dec 18 10:10:29 2009
@@ -86,8 +86,7 @@
+ strongName
+ ' for module '
+ moduleBaseURL
- + '; a legacy, 1.3.3 compatible, serialization policy will
be used. You may experience SerializationExceptions as a result.,
- null);
+ + '; a legacy, 1.3.3 compatible, serialization policy will
be used. You may experience SerializationExceptions as a result.);
serializationPolicy = RPC.getDefaultSerializationPolicy();
}
===
---
/trunk/user/src/com/google/gwt/user/server/rpc/RemoteServiceServlet.java
Mon Oct 26 14:02:26 2009
+++
/trunk/user/src/com/google/gwt/user/server/rpc/RemoteServiceServlet.java
Fri Dec 18 10:10:29 2009
@@ -71,7 +71,7 @@
+ , is not in the same web application as this servlet,
+ contextPath
+ . Your module may not be properly configured or your client
and server code maybe out of date.;
- servlet.log(message, null);
+ servlet.log(message);
} else {
// Strip off the context path from the module base URL. It should be
a
// strict prefix.
@@ -146,8 +146,7 @@
+ strongName
+ ' for module '
+ moduleBaseURL
- + '; a legacy, 1.3.3 compatible, serialization policy will
be used. You may experience SerializationExceptions as a result.,
- null);
+ + '; a legacy, 1.3.3 compatible, serialization policy will
be used. You may experience SerializationExceptions as a result.);
serializationPolicy = RPC.getDefaultSerializationPolicy();
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7338 committed - When SameParameterValueOptimizer substitutes a value...
Revision: 7338
Author: sp...@google.com
Date: Fri Dec 18 10:24:21 2009
Log: When SameParameterValueOptimizer substitutes a value
for a parameter, it now casts the value to the type
of the parameter. This prevents, for example,
treating an integer as a long.
Review by: scottb
http://code.google.com/p/google-web-toolkit/source/detail?r=7338
Modified:
/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java
/trunk/dev/core/test/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizerTest.java
===
---
/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java
Fri Dec 18 09:13:44 2009
+++
/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizer.java
Fri Dec 18 10:24:21 2009
@@ -173,7 +173,6 @@
* all calls.
*/
private MapJParameter, JValueLiteral parameterValues = new
IdentityHashMapJParameter, JValueLiteral();
-
private final JProgram program;
/**
@@ -183,9 +182,11 @@
* TODO: support polymorphic calls properly.
*/
private SetJMethod rescuedMethods = new HashSetJMethod();
+ private final Simplifier simplifier;
private SameParameterValueOptimizer(JProgram program) {
this.program = program;
+simplifier = new Simplifier(program);
}
private boolean execImpl(JNode node) {
@@ -200,7 +201,7 @@
JValueLiteral valueLiteral = parameterValues.get(parameter);
if (valueLiteral != null) {
SubstituteParameterVisitor substituteParameterVisitor = new
SubstituteParameterVisitor(
-parameter, valueLiteral);
+parameter, simplifier.cast(parameter.getType(), valueLiteral));
substituteParameterVisitor.accept(parameter.getEnclosingMethod());
madeChanges |= substituteParameterVisitor.didChange();
}
===
---
/trunk/dev/core/test/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizerTest.java
Fri Dec 18 09:13:44 2009
+++
/trunk/dev/core/test/com/google/gwt/dev/jjs/impl/SameParameterValueOptimizerTest.java
Fri Dec 18 10:24:21 2009
@@ -39,6 +39,12 @@
assertOptimize(foo, static int foo(int i) { return i;
}, foo(foo(1));).into(
public static int foo(int i){, return i;, });
}
+
+ public void testNumericCast() throws Exception {
+assertOptimize(foo, static void foo(long i) { long j = i; },
+foo(1); foo(1);).into(public static void foo(long i){,
+ long j = 1L;, });
+ }
public void testSameParameter() throws Exception {
assertOptimize(foo, static void foo(int i) { int j = i; },
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7339 committed - Add Richard Zschech to CLA-SIGNERS.
Revision: 7339 Author: j...@google.com Date: Fri Dec 18 11:27:58 2009 Log: Add Richard Zschech to CLA-SIGNERS. http://code.google.com/p/google-web-toolkit/source/detail?r=7339 Modified: /CLA-SIGNERS === --- /CLA-SIGNERSWed May 13 14:19:20 2009 +++ /CLA-SIGNERSFri Dec 18 11:27:58 2009 @@ -23,3 +23,4 @@ saschah (Sascha Haeberling) spacelenny (David Evans) t.bro...@gmail.com (Thomas Broyer) +rich...@zschech.net (Richard Zschech) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Fixes JSORestrictions crash in bad units
Reviewers: bobv,
Message:
Bob, can you review this please?
Description:
In rare cases, the old code would crash with a null scope.
Please review this at http://gwt-code-reviews.appspot.com/126815
Affected files:
M dev/core/src/com/google/gwt/dev/javac/JSORestrictionsChecker.java
Index: dev/core/src/com/google/gwt/dev/javac/JSORestrictionsChecker.java
diff --git
a/dev/core/src/com/google/gwt/dev/javac/JSORestrictionsChecker.java
b/dev/core/src/com/google/gwt/dev/javac/JSORestrictionsChecker.java
index
1e9cb0fd14c203f20bf331ecdbe394c2768ea04c..20cb17850c7c4027ae934b37d5e26bde9a54c225
100644
--- a/dev/core/src/com/google/gwt/dev/javac/JSORestrictionsChecker.java
+++ b/dev/core/src/com/google/gwt/dev/javac/JSORestrictionsChecker.java
@@ -85,8 +85,19 @@ public class JSORestrictionsChecker {
@Override
public void endVisit(AllocationExpression exp, BlockScope scope) {
+ // In rare cases we might not be able to resolve the expression.
+ if (exp.type == null) {
+return;
+ }
+ TypeBinding resolvedType = exp.resolvedType;
+ if (resolvedType == null) {
+if (scope == null) {
+ return;
+}
+resolvedType = exp.type.resolveType(scope);
+ }
// Anywhere an allocation occurs is wrong.
- if (exp.type != null isJsoSubclass(exp.type.resolveType(scope))) {
+ if (isJsoSubclass(resolvedType)) {
errorOn(exp, ERR_NEW_JSO);
}
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fixes JSORestrictions crash in bad units
LGTM http://gwt-code-reviews.appspot.com/126815 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7340 committed - Fixes JSORestrictions crash in bad units....
Revision: 7340
Author: sco...@google.com
Date: Fri Dec 18 14:16:56 2009
Log: Fixes JSORestrictions crash in bad units.
In rare cases, the old code would crash with a null scope.
Review by: bobv
http://code.google.com/p/google-web-toolkit/source/detail?r=7340
Modified:
/trunk/dev/core/src/com/google/gwt/dev/javac/JSORestrictionsChecker.java
===
---
/trunk/dev/core/src/com/google/gwt/dev/javac/JSORestrictionsChecker.java
Tue Nov 10 20:42:30 2009
+++
/trunk/dev/core/src/com/google/gwt/dev/javac/JSORestrictionsChecker.java
Fri Dec 18 14:16:56 2009
@@ -85,8 +85,19 @@
@Override
public void endVisit(AllocationExpression exp, BlockScope scope) {
+ // In rare cases we might not be able to resolve the expression.
+ if (exp.type == null) {
+return;
+ }
+ TypeBinding resolvedType = exp.resolvedType;
+ if (resolvedType == null) {
+if (scope == null) {
+ return;
+}
+resolvedType = exp.type.resolveType(scope);
+ }
// Anywhere an allocation occurs is wrong.
- if (exp.type != null isJsoSubclass(exp.type.resolveType(scope))) {
+ if (isJsoSubclass(resolvedType)) {
errorOn(exp, ERR_NEW_JSO);
}
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on WhyWidgetIsAClass in google-web-toolkit
Comment by m...@google.com: This doesn't make sense to me. This is a purely mechanical change isn't it? Why wouldn't this work: rename Widget to BaseWidget; create an interface Widget that contains all the public methods in BaseWidget; change BaseWidget to implement Widget; change parameters of type BaseWidget to Widget. Done. What am I missing? For more information: http://code.google.com/p/google-web-toolkit/wiki/WhyWidgetIsAClass -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: now.. afetr GWT 2.0?
Hi all, I wish the GWT team would focus on all the things that force us to use such awful third-party libraries as Ext-GWT: -more appealing built-in themes -richer components, like data grids with remote pagination -data binding Ext-GWT is full of annoyances but it has good looking widgets, easy-to- use grids (after you have fixed the quirks) and kind-of-working data binding. I would drop it in a blink if GWT offered those features. Of course I wouldn't mind if the compiler was faster, but so far we can manage with dev mode and the occasional GWT compilation. Olivier -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: now.. afetr GWT 2.0?
Definitely, the most important thing for me is fix the bugs and above all publish an excellent documentation and ... +1 for Databinding Validation +1 for a nice DataGrid +1 for nicer widgets Great job on GWT 2.0 On 16 dez, 10:42, tfreitas tfrei...@gmail.com wrote: What about roadmap? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: now.. afetr GWT 2.0?
I would like more control over which classes/packages were actually sucked into a module for compilation. I appreciate there are workarounds like sticking diff java files under diff src dirs but that's ugly. I don't like how including a particular package also sucks in sub packages. I think it wouldbe better if it only did the specific pkg. Further ctrl over individually classes within an included pkg would be great. I have noticed rhat google collections marks a few classes with various annonations like gwt-compatible and gwt-not-compatible. It would be great if the compiler honoured these. Even finer grained ctrl over individual methods would be great.i f it worked like suppress warnings but instructed the compiler to ignore invompatible code that would be great. - Use cases include stuff like a class with lots of static helpers some intended just for the server others that also are useful under gwt. - sometimes it's usegful to overload a method to take types that are irrelevant or wrong in gwt - eg inputstream. Again one could take that helper and stick it somewhere else buts it's ugly to have the disconnect when they really belong together. Hyh On 19/12/2009, at 3:29 AM, Mauro mauro.no...@gmail.com wrote: Definitely, the most important thing for me is fix the bugs and above all publish an excellent documentation and ... +1 for Databinding Validation +1 for a nice DataGrid +1 for nicer widgets Great job on GWT 2.0 On 16 dez, 10:42, tfreitas tfrei...@gmail.com wrote: What about roadmap? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
