Re: [gwt-contrib] Re: Allow RPC stats system extensions (issue751801)

[Lex Spoon]

I don't know anything about the *current* stats support in RPC.

Judging from the revision logs, it looks like Bob might have added that
system. Added to the CC.  -Lex


On Tue, Aug 24, 2010 at 5:29 PM, Pascal Muetschard <
pmuetschard...@google.com > wrote:

> Could I please get some feedback on this and get it submitted?
> Thanks.
>
> On Aug 10, 2:13 pm, pmuetschard...@google.com wrote:
> > Reviewers: Dan Rice, scottb, Lex,
> >
> > Description:
> > This patch allows for the extension of the RPC stats system by "moving"
> > the stats methods into an object, making them non-static. This would
> > allow application developers to extend the ProxyCreator to use a
> > different implementation of the stats methods.
> >
> > Please review this athttp://gwt-code-reviews.appspot.com/751801/show
> >
> > Affected files:
> >user/src/com/google/gwt/rpc/client/impl/RpcCallbackAdapter.java
> >user/src/com/google/gwt/rpc/client/impl/RpcServiceProxy.java
> >user/src/com/google/gwt/user/client/rpc/impl/RemoteServiceProxy.java
> >
>  user/src/com/google/gwt/user/client/rpc/impl/RequestCallbackAdapter.java
> >user/src/com/google/gwt/user/client/rpc/impl/RpcStatsContext.java
> >user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

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

[gwt-contrib] Re: Faster edit-distance computation in JsFunctionClusterer (issue669801)

[Lex Spoon]

Ray, does the patch look good to you?   -Lex

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

Re: [gwt-contrib] Phasing in a new, unified linker

[Lex Spoon]

I don't have a strong opinion about it. They can be non-final, with simply
no particular effort to truly make them extensible.


> I think it might be possible to move the template JS files to
> GWT-translated code with extension points managed through rebinding and
> overriding. Until then, making changes that involve JS modifications
> effectively require you to cut and paste the whole file.
>
>
There is now some templating, by the way. You asked about the
__COMPUTE_SCRIPT_BASE__ reference. SelectionScriptLinker -- the base class
for all the linkers in the subject line -- substitutes that string for the
contents of computeScriptBase.js, a file included within gwt-user.jar. Thus,
linkers that want the standard implementation of computeScriptBase() can
simply include that string rather than copying the whole chunk of JS.

Such templating is pretty limited even in principle, however, and in
practice it's so far only done for that file and for one other one.

Incidentally, you mention moving code into Java. That strategy actually came
to pass for runAsync code fetching. Originally, linkers would emit a
function that the code loader calls to download code. Now, there is a
deferred binding, and the choice of linker causes the deferred binding
choice to differ. Thus, code loaders are now simply Java classes that
implement a simple Java interface. It's much easier to maintain.

-Lex

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

[gwt-contrib] Re: Faster edit-distance computation in JsFunctionClusterer (issue669801)

[Lex Spoon]

On Wed, Jul 28, 2010 at 6:15 PM,  wrote:

> Oh, sorry. I made this comment somewhere else. The problem is the
> endStatements() method doesn't use the regex to recognize the other
> declaration style.
>

Ah, yes! Well at the least this code should be moved to a subroutine. I
believe the version with the regex is the desired version.



>
> In addition, I believe the current regex don't match the declaration
> emitted by the cross-linker. The dot in the name prevent a match.


I thought so at first, but it's using find(). So it should still match.
Perhaps it matches too many

-Lex

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

Re: [gwt-contrib] Phasing in a new, unified linker

[Lex Spoon]

On Mon, Jul 26, 2010 at 6:56 PM, John Tamplin  wrote:
>
> Well, we do know there will be other linkers, and if there aren't extension
> points defined they will be done via cut-and-paste, which is what led to the
> current state we are in.


No question that extension points are useful. Let's add them, but only when
we have an idea of what we are supporting with them.

Note that IFrameLinker and XSLinker have several extension points, and yet
nonetheless there is a lot of cut and paste going on.  We didn't add (all
of) the ones that people really ended up needing.

-Lex

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

Re: [gwt-contrib] Phasing in a new, unified linker

[Lex Spoon]

On Mon, Jul 26, 2010 at 12:37 PM, Scott Blum  wrote:

> SGTM as far as process.
>
> Is the new linker designed to curtail extension, or to sanely encourage it?
>  The existing primary linkers ended up getting extended in brittle ways.
>

That's a good point. Let's make it a final class to start with, and open up
extension points later as issues come up. There are no known needs for
extensions at this point.

-Lex

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

[gwt-contrib] Phasing in a new, unified linker

[Lex Spoon]

Joel, Miguel, GWTers,

I am trying to phase in a new linker as the default GWT linker, and I could
use some feedback on how that is accomplished.

My first thought was to modify the cross-site linker in place, as was
started by this patch:

http://gwt-code-reviews.appspot.com/674802/show


After further thought, though, the changes in that patch are simply not
backward compatible. The most fundamental problem is that there are
currently linkers extending the XSLinker class, and any major change to
XSLinker will break these other ones. Additionally, the cross-site linker
has $wnd==window, but that's no longer true in the unified linker. Both of
these problems won't affect most apps, but an indeterminate few will be
broken by simply committing the above patch.

Here's an alternate phase-in plan that avoids the above two problems:

1. Make a new linker class and new linker name, so as not to disturb any
code inheriting from our existing linkers. Commit the above patch under the
new names. Anyone who can live without dev mode support can use it
immediately.

2. Add development mode support to the new linker.

3. Redirect the "std" linker to the new one. We could add a deprecated
"iframe" name for the iframe linker for anyone who desperately needs it.
Note that people using the "std" linker must already be using $wnd in the
necessary places.

4. Deprecate the iframe and xs linkers, and after a year or two remove them.
Users of the cross-site linker will need to make sure they use $wnd in the
right places before they change over.


A benefit of this approach is that most apps use the "std" linker and will
simply pick up the improvements without needing any changes. Updating people
currently on the cross-site linker is trickier, but I don't see any way to
get around the $wnd/window problem. Their code simply needs to be updated.

-Lex

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

Re: [gwt-contrib] proposing a hypothetically breaking change to gwt-servlet.jar: comments?

[Lex Spoon]

On Mon, Jun 28, 2010 at 3:57 PM, Freeland Abbott  wrote:
>
> So, how breaking are we willing to be to correct that?
>

My knee-jerk reaction is that we don't want to do a lot of breaking just to
tidy up the definition of gwt-servlet. The only benefit is to reduce the
size of the white list, right? That's a small benefit.

Nonetheless, we still would benefit to make gwt-servlet be based on a
whitelist rather than a blacklist. It would immediately shrink the jar size,
and it would prevent us from accidentally sprawling it even larger.

-Lex

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

Re: [gwt-contrib] proposing a hypothetically breaking change to gwt-servlet.jar: comments?

[Lex Spoon]

I think everyone is saying the same thing. Use Miroslav's suggested ASM tool
to get a first cut, and then bake the resulting whitelist into the ant
files. Then, little by little, refactor things so that the whitelist can
shrink, until all that's left is **/shared/** and **/server/** .

I'd only add that the ASM tool does get into 4+ hours of work. So if the
list Freeland has already looks pretty good, we might instead start there.

-Lex

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

Re: [gwt-contrib] Re: Can linkers access source files?

[Lex Spoon]

On Mon, Jun 21, 2010 at 10:11 AM, Marko Vuksanovic <
markovuksano...@gmail.com> wrote:

> Well, the idea is to be able to somehow analyze the input and see how
> it is related to some output. I know that it is possible to achieve
> this without messing gwt compiler itself (just run some code before
> the compiler starts its job).


It sounds like maybe you want to simply check out GWT's source code and make
some local modifications. I don't think any bounded set of hooks is going to
give you the flexibility for such general exploration. You can even upload a
forked version to a new repository if you like.

Also, if you are looking for ideas on things to hack on, be sure and check
out the issue tracker. The beauty of things on there is that in more cases
than not, there are real production problems that caused the person to post
about them. Thus, a patch for those things will immediately have at least
one user.

Lex

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

Re: [gwt-contrib] Re: Introducing the Abstractizer compiler optimization (issue 4893) (issue609801)

[Lex Spoon]

On Mon, Jun 14, 2010 at 10:37 PM, Bruce Johnson  wrote:

> 50%? That would be astonishing, but I must admit I'm skeptical :-)


I have the same question.

It seems to me there is a second kind of payoff, though, that is also worth
considering. An improved optimizer can prevent people from writing awkward
code just to appease the optimizer. On that measure, this patch looks really
good. If someone writes a method with a default implementation, and that
method is always overridden, then programmers have one less thing to worry
about if they can believe GWT will prune it.

Lex

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

Re: [gwt-contrib] Re: Introducing the Abstractizer compiler optimization (issue 4893) (issue609801)

[Lex Spoon]

On Tue, Jun 15, 2010 at 10:11 AM, Thomas Broyer  wrote:
>
> Well, probably... CodeFlowAnalyzer is a bit too complex for my very
> limited knowings of the compiler internals. I'll give it a try though
> (but I can't tell you when I'd find time to do it, it's almost all on
> my spare time)
>

Okay.

Just to spell it out a little further, for anyone that finds time, the
changes would be like:

1. Add the new set targetsOfNew.

2. Whenever a "new" is visited, add the target class to targetsOfNew.

3. Add a method callable(JMethod) that checks if the method is callable on
any of targetsOfNew.

4. Update visit(JMethodCall, Context) and rescueMethodsIfInstantiable to use
that method.

5. In Pruner, any target of a JMethodCall that is not live gets turned into
an abstract method.


It's the same logic in Abstractizer except implemented in a different place.


Just so you know, my initial concern was about Protobuf. I'm porting
> proto2 to GWT (see http://code.google.com/p/protobuf-gwt/ ), and when
> you generate code in optimize_for=SPEED mode, methods of
> GeneratedMessage whose default implementation relies on the reflection
> API (getDescriptor and the like) are overridden, and actually never
> ever called. But in current GWT, the code won't be pruned, which also
> includes all Descriptor classes and methods, even if you don't use
> them. This could potentially represent a fairly big amount of unused/
> dead code in the output JS. Obviously, when targetting GWT you should
> rather use optimize_for=LITE_RUNTIME (which I intend to implement as
> JSO overlays in the next iteration), but given that my goal is to
> share code between client-side and server-side I'd like to also
> support the "non-lite" APIs.
>

Better protobuf support would certainly be nice!

I'll review the patch for if you don't have time to do the
ControlFlowAnalyzer version.

-Lex

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

[gwt-contrib] Re: Introducing the Abstractizer compiler optimization (issue 4893) (issue609801)

[Lex Spoon]

It's a fun idea! Methods that are only there for their type signatures could
have their bodies removed.

Ideally, ControlFlowAnalyzer would be able to identify such methods, and
Pruner would remove their bodies. With that arrangement, the CFA and the
method abstracting would mutually benefit each other. It would also lead to
better code splitting.

ControlFlowAnalyzer already has a notion of "instantiable types". I believe
it needs to be improved, though, to be effective at abstracting methods. To
test that theory, set a break point in Pruner.execImpl right before it calls
setInstantiableTypes. At that point, the question is whether the
abstractable methods are marked as being called or not. I believe they will
be marked as callable.

To improve that, a new set could be added to hold the classes that are
targets of "new". Then, when ControlFlowAnalyzer visits a virtual method
call, it would have the information it needs to skip over the abstractable
methods.

I am still mulling over the general idea, but that's my initial reaction. If
push comes to shove, we could certainly add another whole-tree walk like in
this patch, and it would be an improvement. It would make a bigger
improvement, though, if we can factor it into an existing optimization.

Lex

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

Re: [gwt-contrib] Command pattern and GWT.runAsync

[Lex Spoon]

On Fri, Jun 4, 2010 at 5:13 AM, David  wrote:

> Less maintenance on the async, declarative transaction management,
> undo, batching, less web.xml tweeking, ... there are many reasons why
> we also use a command pattern.
>

With the system as it is, I believe your best bet is to make abstract class
plus *templates* of key methods. The templates are then copied down to each
subclass. An example is in GWT's showcase sample, where each content pane
implements the following method:

  @Override
  protected void asyncOnInitialize(final AsyncCallback callback) {
GWT.runAsync(CwAbsolutePanel.class, new RunAsyncCallback() {
  public void onFailure(Throwable caught) {
callback.onFailure(caught);
  }

  public void onSuccess() {
callback.onSuccess(onInitialize());
  }
});
  }

This method calls onInitialize() to do the work specific to each example
pane. You could imagine it also calling some other protected methods in key
places.

In general, it would be nicer if runAsync included some extra callbacks in
key places so that this kind of thing isn't necessary. Then whenever you
change the template, you could change it in one place instead of having to
modify all the copies in all the subclasses. Initially, the issue was that
it wasn't obvious what hook points people would want. At this point, the
issue is more a matter of priorities. To do it well would require surveying
what everyone is doing with runAsync and making sure the right hooks are
there for the majority of them.

Lex

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

Re: [gwt-contrib] Tabless

[Lex Spoon]

On Thu, Jun 3, 2010 at 12:56 PM, Ray Ryan  wrote:

> No argument. And since we've never, ever managed to actually delete a
> deprecated class so far as I know, the issue may not come up for a while…
>
>
There are some counterexamples. For example:

http://gwt-code-reviews.appspot.com/139804/show

To get deprecated things removed, it's key that users have something to
switch to.

Lex

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

Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.

[Lex Spoon]

On Tue, Jun 1, 2010 at 2:35 PM, Marko Vuksanovic
wrote:

> Class Loaders are checked in parent to child direction - so if you try to
> fetch a resource from a context class loader, system class loader is the
> first that will be checked and only after resource is not found there, next
> child will be checked... and so on... So if something is found in context
> class loader, all parent class loaders have been checked. Somebody correct
> me if I'm wrong.


I don't believe it's necessarily true for the system loader to be a parent
of the context loader. It's common, but not necessary. The only loader you
can't get away from is the boot class loader.

That said, if it's not on the context loader, you might want to ignore it if
you can get away with it. For that matter, the same goes for things not in
the resource oracle.

-Lex

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

Re: [gwt-contrib] Re: CompilePerms and classpath loading problem.

[Lex Spoon]

On Tue, Jun 1, 2010 at 11:56 AM, Ray Ryan  wrote:

> Yup. Is the fix to make it use the resource oracle?


To play it safe:

First check resource oracle.
Next check the context class loader, as in Marko's email.
Then check wherever it looks now (the system class loader?).

Lex

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

Re: [gwt-contrib] Re: Fix GWT logging in Devmode (issue437801)

[Lex Spoon]

On Wed, May 5, 2010 at 2:15 PM, Ray Ryan  wrote:

> You should be able to throw subclasses of RuntimeException, no?


For example, UnsupportedOperationException.  -Lex

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

Re: [gwt-contrib] Re: Question about CompilePerms and adding gwt module source at runtime.

[Lex Spoon]

On Tue, May 4, 2010 at 12:25 PM, Marko Vuksanovic  wrote:

> Hi Lex,
> The first solution seems interesting... could you please provide a code
> snippet just to get me started...
> Did you mean something like
>
> Thread.currentThread().setContextClassLoader(urlClassloader);
>
>
Exactly.  Where urlClassloader is a freshly made URLClassLoader that you
create.

-Lex

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

Re: [gwt-contrib] Re: Question about CompilePerms and adding gwt module source at runtime.

[Lex Spoon]

On Mon, May 3, 2010 at 7:36 AM, Marko Vuksanovic
wrote:

> I solved the problem... This had nothing to do with the GWT. The
> problem was with adding a folder to java class path dynamically.
> Although at first I thought I had done it correctly, it turned out
> that that's a little tricky...
>
> For anyone else with the same problem - here's a gist on how to solve
> it...
> http://gist.github.com/387972
>
> As you can see, a call to protected method is required in order to add
> a folder to class path.
>
>
It would also be possible to create a new class loader and set that as the
"context class loader". Then GWT should use the new one.

Alternatively, when the JVM is launched on the remote machine, pass the
extra directories in using the -classpath option.

-Lex

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

[gwt-contrib] Re: When JsStaticEval converts a number to a string, use the JS (issue335801)

[Lex Spoon]

Interesting subthreads aside, does the change in this patch LGT everyone?

On Fri, Apr 9, 2010 at 6:58 PM, John Tamplin  wrote:

> On Fri, Apr 9, 2010 at 6:29 PM, Lex Spoon  wrote:
>
>> Changing it is fine.  However, the ideal change would be to whichever way
>> takes the fewest bytes!
>>
>
> Well, not if we are using it in contexts where it is expected to be all
> digits, as in the original bug.
>
>
True.

In this particular subthread, the context is JsToStringVisitor. This class
already discards whitespace and drops comments.  It also does rewrites such
as 1.23456E5 to 123456, and those are more than fine. Emit it whichever way
is shortest.

-Lex

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

[gwt-contrib] Re: When JsStaticEval converts a number to a string, use the JS (issue335801)

[Lex Spoon]

On Fri, Apr 9, 2010 at 4:50 PM, Ray Cromwell  wrote:

> What about JS string promotion tho? Imagine the following:
>
> var x = "Hello";
> var y = 2.0041234E3
> alert(x + y);
>
> If y was originally "20041234000" but JsToStringGenerationVisitor
> serialized it in scientific notation, then this would be wrong, since
> the user would expect "Hello 20041234000". Testing this in the Chrome
> console, it works, become y=2.0041234E3 gets toStringed by the JS
> runtime as "20041234", so maybe you're right. Still doesn't make me
> feel warm and fuzzy inside.


Changing it is fine.  However, the ideal change would be to whichever way
takes the fewest bytes!

Lex

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

To unsubscribe, reply using "remove me" as the subject.

[gwt-contrib] Re: When JsStaticEval converts a number to a string, use the JS (issue335801)

[Lex Spoon]

On Fri, Apr 9, 2010 at 3:29 PM,  wrote:

> On 2010/04/09 15:16:19, jat wrote:
>
>> Do we need to also change String.valueOf(*) which just uses "" + val?
>>
>
> Good point. There might be other places where JsNumberLiteral is changed
> to a String, so we should look at that. Lex, look at
> JsToStringGenerationVisitor.visit(JsNumberLiteral x,
> JsContext ctx)   for example.


Hmm, that one should be okay, shouldn't it?  Anything will do so long as it
evaluates correctly.

John, I've been thinking about String.valueOf().  That one's tough, because
ideally we want the Java conversion.  That's generally our story with
compiled GWT code: it behaves the same as it would on a JVM.  Unfortunately,
I don't see an easy way to get the Java meaning when translating to JS.

It looks easier to say that GWT uses the JS meaning.  In that case, though,
we should try to make dev mode also use the JS meaning.

-Lex

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

To unsubscribe, reply using "remove me" as the subject.

Re: [gwt-contrib] GWT 2.0.3 Compiler Bug?

[Lex Spoon]

Hey, Jay,

I haven't replicated the problem using your example, but I think I see the
bug anyway.  There is an optimization to simplify at compile time
expressions like 2004318071+'', and it is converting the number part to a
string using the equivalent of Double.toString.  That is where the
scientific notation comes from.  However, a real JSVM apparently has a
different algorithm for turning a number into a string.

I'll work on the JsStaticEval bug.  Here's an issue for it:

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

Jay, if you can minimize the problem down to something I can replicate, I
can test that it is in fact the problem you are seeing.  Alternatively, have
you ever built and used GWT from trunk?  IF so, you could verify the fix
once it's committed.

-Lex

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

To unsubscribe, reply using "remove me" as the subject.

Re: [gwt-contrib] Re: Array implementation for Lightweight Collections. Pure Java implementation only. (issue232801)

[Lex Spoon]

On Thu, Mar 25, 2010 at 2:16 PM, Freeland Abbott  wrote:

> Am I right to think that the problem with builder.create() is that it
> implies a defensive copy, to allow you to do builder.add() afterwards, and
> we want to avoid that?  (If not, then what is the problem?)
>
> The solution to that could indeed be a more clever builder: at create()
> time, we return the existing array as an ImmutableArray, *and let go of it
> in the builder, moving it to a previousList filed or somesuch.*  If the
> user does indeed later reuse the builder with some add() (or remove() or
> whatever), we do the defensive copy then, lazily.  Presumably two
> back-to-back create() calls could just return the same list, since it's
> immutable anyway.
>

That works fine

It won't always optimize as well, though.  For a builder created in one
method, built up, and then turned into an immutable collection, anything
goes.  Unwrap the fields of the builder object, inline the add/remove/etc
methods, and use data flow for the rest.  However, for a builder passed
around to multiple methods, this looks much harder, and surely the optimizer
won't always figure it out.

For freeze, I presume it works out that in the prod-mode version the frozen
collection really is the same object?  In that case, we should get the
tightest possible code just by inlining add/remove/etc.  There isn't any
fancy inference needed to prove that add() is never called after create().

-Lex

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

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

[gwt-contrib] Re: Adds the -XdisableGflow flag. (issue260801)

[Lex Spoon]

On Tue, Mar 23, 2010 at 2:24 PM,  wrote:

> Just a thought.. but instead of a new flag, what if we redefined
> "aggressive optimizations" to mean just GFlow, since all the other
> optimizations have a lot of miles on them now.  What do you think?


I like the idea of updating the aggressive optimization flag, and started to
suggest that instead.  However, it would still probably include more than
gflow.  Potential examples would be function clustering, function deduping,
and same parameter value substitution.  So we'd likely end up wanting a
separate flag, anyway.

-Lex

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

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

[gwt-contrib] whirlwind overview of distributed GWT builds

[Lex Spoon]

I can't find them documented anywhere, so I have tossed up a brief web page.

http://code.google.com/p/google-web-toolkit/wiki/DistributedBuilds

Most GWT apps build fast enough that a distributed build isn't worth the
effort, so this is a pretty specialized topic.  However, an occasional
project has a lot of translations plus a lot of supported browsers, and when
you multiply the two numbers together you easily get over a hundred
permutations being built.  For such projects, a distributed build can help,
because the permutations can be built in parallel.

The details are on the wiki page.  Ideas about improving the page (or the
feature!) are welcome.

Lex

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

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

Re: [gwt-contrib] Re: RR : Soft permutations (issue160801)

[Lex Spoon]

On Thu, Mar 18, 2010 at 7:38 PM, John Tamplin  wrote:

> On Thu, Mar 18, 2010 at 7:25 PM,  wrote:
>
>> The main issue is that I don't believe that sharded builds will take
>> full advantage of the collapsing.  We need for Precompile to emit the
>> number of *collapsed* permutations, but it looks like it emits the
>> number before collapsing.  Also, CompilePerms needs to treat its input
>> number as an index into the collapsed permutations.
>>
>
> Wouldn't you have to run generators in precompile if you wanted to collapse
> equivalent permutations down?
>

There are different kinds of collapsing.  I mean the collapsing that this
patch adds, which not coincidentally does not depend on generator results.

Lex

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

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

Re: [gwt-contrib] Re: RR : Soft permutations

[Lex Spoon]

On Thu, Mar 18, 2010 at 12:20 PM, John Tamplin  wrote:

> On Thu, Mar 18, 2010 at 12:11 PM, Lex Spoon  wrote:
>
>> Yes, that's what I was thinking for complex cases.  For simple cases,
>> can't users already specify "en" and get a permutation with all the
>> Englishes combined?
>>
>> Perhaps I misunderstand, though.  Is the plan to stop using "en" and
>> switch to having people use "en_*" to collapse down the Englishes?
>>
>
>  Right now, people who use runtime locales for the most part they just list
> the compile-time locales they want translations for and inherit CldrLocales.
>  If we add new locales, such as recently, they don't have to change anything
> and they automatically get the localized date/time/number formats and
> currency names for each runtime locale.
>
> That is what I have been pushing to have a solution for in soft
> permutations, rather than requiring them to manually create the collapse
> lists is a problem.  Having to run some pre-compile tool is problematic,
> since how do you tell Eclipse, for example, what to run and when?
>

> Granted, runtime locales aren't going to be ported to soft permutations
> immediately, but it still shouldn't be something that is going to make life
> harder for our users when we do it.  I thought the conclusion of the
> discussion we had about that was to allow a module to specify a class that
> could synthesize module entries


It sounds like the design isn't so nailed down after all for how runtime
locales will work with soft permutations.  Let's please talk this over in a
higher-bandwidth forum.

I thought I had mentioned that developing what is essentially a macro system
is possible but will take some substantial effort.  Perhaps it's the thing
to do, but it increases the scope of what module files support.  If we don't
need it, this is a place we can save a lot of effort.


-Lex

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

Re: [gwt-contrib] Re: RR : Soft permutations

[Lex Spoon]

On Thu, Mar 18, 2010 at 12:32 PM, BobV  wrote:

> > Depending on the string name of an enum looks suboptimal.
>
> What are you referring to?
>
>
A deferred binding option is a selection from an enum.  Normally the name of
an enum is not significant.  It's only used in debuggers and for binding
identifiers to the chosen enum.

Thus, globbing on the name of a deferred binding property looks like doing
this in Java to me:

  enum Locale { EN_UK, EN_US, ES_AR, ES_ES }

  boolean useit(Locale locale) {
return locale.name().startsWith("EN_");
  }


It breaks down because the person writing the enums has to always write them
with a careful hierarchy represented in the names.  Instead of safari, g1,
nexus, and chrome, we have webkit.safari, webkit.chrome, webkit.android.g1,
webkit.android.nexus.  This is awkward when it works, but it completely
breaks down once there's another axis to classify the browsers with.  For
example, what's the glob that combines all mobile browsers?


Lex

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

Re: [gwt-contrib] Re: RR : Soft permutations

[Lex Spoon]

On Thu, Mar 18, 2010 at 9:03 AM, BobV  wrote:

> On Wed, Mar 17, 2010 at 4:06 PM, John Tamplin  wrote:
> > While that may work for some trivial cases, in many cases you will need
> more
> > nuanced control over what gets collapsed, considering locale inheritance
> and
> > aliases.
>
> That sounds like a pre-GWT-compile tool that auto-generates a chunk of
> gwt.xml.


Yes, that's what I was thinking for complex cases.  For simple cases, can't
users already specify "en" and get a permutation with all the Englishes
combined?

Perhaps I misunderstand, though.  Is the plan to stop using "en" and switch
to having people use "en_*" to collapse down the Englishes?



>
> @Lex, do you disagree with being able to write glob-like patterns at
> all in the  tag, or the way in which it's been
> implemented?
>

I'm reviewing the patch. It's a complex one and is simply taking some time.
On this little issue, though, it's the feature that I suspect we can do
better on. Depending on the string name of an enum looks suboptimal.  That's
just a principle, though.  We could evaluate it better if we had some strong
use cases to look at.

Lex

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

[gwt-contrib] Re: RR : Soft permutations

[Lex Spoon]

On Wed, Mar 17, 2010 at 2:48 PM, BobV  wrote:

> On Wed, Mar 17, 2010 at 2:33 PM,   wrote:
> > Still, what is the use case for globs other than a bare "*" ?
>
> You mean like:
>  gecko*
>  ie*
>

Those are trivial already.  Is there any new use case enabled by it?  -Lex

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

Re: [gwt-contrib] Support runAsync with the cross-site linker.

[Lex Spoon]

On Tue, Mar 16, 2010 at 11:54 AM, Eric Ayers  wrote:

> Something is screwy with riedvelt, and I can't leave a comment on
> XSTemplate.js
>
> My comment isn't really about your patch in particular, but the patterns we
> are using in the linker templates.  I wish that stanzas of code common to
> many linkers, like the calling of __gwtStatsEvent() could be extracted and
> put into the template with variable substitution.  For example, adding the
> sessionId field to the event works fine here, but there are several linkers
> outside of GWT that will need to be updated to get the same fix.
>

Yes.  Indeed, this fix originally went into the iframe linker and it was
overlooked for the cross-site linker.  Using more templating should help us
not have to duplicate code so much.

I was thinking in the short term to pull out computeScriptBase and
processMetas into their own file.  Code that wants to pull it in could
insert COMPUTE_SCRIPT_BASE or PROCESS_METAS at the place it should go.  As
well, the code can then be tested more conveniently.

Perhaps, though, we may as well define a general INCLUDE("processMetas.js")
?


Lex

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

Re: [gwt-contrib] Support runAsync with the cross-site linker.

[Lex Spoon]

On Mon, Mar 15, 2010 at 8:34 PM, Joel Webber  wrote:

> That's great news, and will really help with efforts to make our linkers
> more sane. Out of curiosity, what's the strategy for loading fragments into
> the enclosing namespace (and yes, that's the sound of me being too lazy to
> dig into the patch)?
>

No, it should be documented separately from the patch.  Here you go:

http://code.google.com/p/google-web-toolkit/wiki/CrossSiteRunAsync


-Lex

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

Re: [gwt-contrib] Re: One-line fix to SelectionScript's fallback logic for

[Lex Spoon]

2010/3/11 Miguel Méndez 

> +1 to Ray's question.  I know that you were simply doing a fix Lex, but we
> need to think about how we test these "features".
>

I agree.  I'll work out a test. -Lex

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

[gwt-contrib] Re: allow skipping unit tests in development or production mode

[Lex Spoon]

On Wed, Mar 10, 2010 at 7:17 PM,  wrote:

> LGTM on this quick and dirty solution. Eventually, we do want something
> like John suggests -- it is mostly up to you to either go with this or
> the general solution.


I feel the same way.  A quick and dirty solution would be very valuable so
that I can add tests for the cross-site linker.  However, it looks like we
ultimately want to support an or of a bunch of ands.

Did you review the implementation, Amit?  So far everyone is okay with the
API as something to work with for now.

Lex

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

[gwt-contrib] Re: Give a better error message when RunAsyncCode.runAsyncCode is passed something

[Lex Spoon]

On Tue, Mar 9, 2010 at 2:28 PM,  wrote:

> That being said, there's an inconsistency between this and the the
> existing error reporting architecture.  The general paradigm is that all
> potential user-errors are caught by the time GenerateJavaAST finishes.
> These lines in JavaToJavaScriptCompiler are meant to be the "last
> chance".
>

Hey, Scott,

You've mentioned this design principle before, and I've asserted that I
don't agree we should be slaves to it.

Before delving into the design principle, perhaps you can identify the more
concrete implications of this choice on what a developer would see from GWT?
 If there's a user-visible behavior involved, then we should be able to
converge on any changes where we can clearly help developers with a small
amount of our effort.

If it's just a matter of architecture, though, then we get into questions of
maintainability.  People differ on such questions, and even when they agree,
it's almost always better off to go with the existing design than to do a
lot of rewrites.  It's a fun thing to chat about, but it tends to go on
forever and not converge on anything that looks worth spending time on.

Regarding that maintainability question, we're talking here about a choice
between the internal JDT trees vs. our JJS trees.  Typically the code we
write against our trees is much more reliable.  I'm sure you recall the
several rounds of patch-ups that were required to stabilize both
JSORestrictionsChecker and JsniChecker (ne LongFromJsniChecker), which work
against the JDT trees.  I fully expect that if we redid ReplaceRunAsyncs to
follow that pattern, we'd repeat that history and need several rounds of
patch up for it as well.  It just doesn't make for robust software.

Not that you are arguing in favor of the JDT trees for their own sake.  You
are more arguing that as bad as they are to work with, it's worth it for a
larger design principle.  Let's consider that principle.

Overall, while I agree that the sort of issue you raise is good to think
about, your description is an oversimplification of how our compiler--or for
that matter any type-checking compiler--actually works.  The disconnect is
that checking does not happen at one time.  It happens in waves.  Those
waves can be loosely grouped as follows:

1. Syntax checking
2. Name resolution
3. Type checking
4. Other static checks

Each of these tends to be subdivided into smaller checkers.

Our own compiler already works like this.  Despite your
claim, ReplaceRunAsyncs, CodeSplitter.pickInitialLoadSequence, and
findEntryPoints all run after the point you indicate and all are allowed to
identify user errors.  What you call the "existing error reporting
architecture" is simply not being followed.  Perhaps you feel this is a
failing, that we have fallen from the proper way to do things.  Let me show
by example that this is a perfectly normal arrangement and that it reflects
the underlying design pressures.

For an outside example, look at this method in the JDT:

http://kickjava.com/src/org/eclipse/jdt/internal/compiler/Compiler.java.htm#697

Notice how type checking (unit.resolve()) is a completely separate step from
flow-based checks (unit.analyseCode()). I wasn't there, but I imagine the
folks at IBM figured: the dependencies allow the flow checks to happen
second, the flow checks are simpler if they know the type checks have
already passed, the two checkers are both complicated in their own right,
and thus it's better to write them as two separate passes.

As another outside example, here is RefChecks from the Scala compiler:

http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/compiler/scala/tools/nsc/typechecker/RefChecks.scala

This phase runs after type checking has completed.  If you look at the class
comment, you will see that many checks are being run at this stage.  Again,
I wasn't there, but I imagine the folks at EPFL made a similar calculation
as in the JDT example.

The other principle you raise is that checkers and translators should be
separated.  In many cases that leads to a better code arrangement, and when
that is true we should do so.  However, the principle doesn't generalize
very well.  Sometimes it is vastly more maintainable to write a pass that
does a transformation and emits errors as it goes.  Let me give several
examples where that is true, because we've all seen examples of the
opposite.

The starkest example is for syntax checking.  By the time a module can check
syntax for correctness, it's only a small step more complexity to translate
to ASTs, and vice versa.  The two steps may as well be combined.  Over the
years, I have run into several different ways to handle parsing.  However, I
have not yet encountered a compiler that separates syntax checking from AST
building.  It's just good engineering to combine them.

An example from our own code is doFindAdditionalTypesUsingRebinds().  By the
time it includes enough code to rebind a GWT.create to its possible
replacements, it ma

Re: [gwt-contrib] Updates the IFRame and XS selection script templates to support

[Lex Spoon]

On Mon, Mar 8, 2010 at 12:37 PM, Ian Petersen  wrote:

> Just idle curiosity here, but why did you have to make the same change
> twice?  I know you're modifying selection scripts, and maybe that
> means you need to violate DRY for some reason, but it strikes me as a
> potential refactoring.
>

Agreed.  It just grew like that over time.

To address it, I was thinking that perhaps we could pull that code out into
separate files, and then use replaceWith calls to insert the code, the same
way the linkers currently fill in __MODULENAME__.  -Lex

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

Re: [gwt-contrib] meta tag applying to just one module?

[Lex Spoon]

"Seems conceptually simpler, and doesn't introduce the idea of
module-specific meta props.  Also should be faster since it means less DOM
crawling during startup?"

Do you think any of these are blocking problems?  In particular, if we went
with the 7-line meta-prop solution, would users be harmed in any measurable
way?  -Lex

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

Re: [gwt-contrib] meta tag applying to just one module?

[Lex Spoon]

On Thu, Mar 4, 2010 at 5:16 PM, Scott Blum  wrote:

> Straw man let's say when you inject a GWT selection script, you can add
> a single line at the very top:
>
> var moduleBaseURL = "w00t/"
>
> Then at the top of computeScriptBase(), we just look to see if
> moduleBaseURL is already defined, and if so we return that.
>


1. That doesn't solve the problem.  The problem is that different modules
need different base URLs.

2. How is this better than using a meta property?  It looks identical except
that it inserts a var rather than a  tag.

-Lex

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

Re: [gwt-contrib] meta tag applying to just one module?

[Lex Spoon]

On Thu, Mar 4, 2010 at 12:47 PM, Scott Blum  wrote:

> It seems like to me, if you have any kind of process for inlining a
> selection script into a host page, that that process *ought* to be able to
> update the module base URL correctly.  I mean... if you have to generate the
> correct meta tag to do the exact same thing, while not just modify the
> selection script being inlined?  It seems to me that would avoid extra
> load-time overhead and complication, and we wouldn't have to extend meta
> props to work on a per-module basis.  Am I crazy?


Can you give more detail on what you are thinking people should do?

The way the selection scripts currently are, such a rewriter would be
brittle.  What the rewriter would need to do is recognize our
computeScriptBase() function and replace it with its own logic.  I don't see
a way to do that that won't easily break the next time we tweak our
selection script.  So, it seems we'd need to develop a less fragile way to
do rewrites of selection scripts.  I can imagine several ways to do that,
but they would all require a substantial, multi-week effort.

To contrast, the running proposal would need ~7 lines of code.  Here's the
meta tag part:

  name = name.replace("__MODULENAME__::", "");
  if (name.indexOf("::") >= 0) {
continue;
  }

Here's the base URL change:

  if (base = getMetaProp("baseUrl")) {
return;
  }


Lex

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

Re: [gwt-contrib] Re: when-linker-added

[Lex Spoon]

On Wed, Mar 3, 2010 at 6:35 PM, Lex Spoon  wrote:
>
> Sure, will do.  The discussions preceding this patch are in several
> different places.  I can summarize them on the wiki.
>
>
http://code.google.com/p/google-web-toolkit/wiki/WhenLinkerAdded<http://code.google.com/p/google-web-toolkit/wiki/WhenLinkerAdded?ts=1267724209&updated=WhenLinkerAdded>
   -Lex

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

Re: [gwt-contrib] meta tag applying to just one module?

[Lex Spoon]

On Tue, Mar 2, 2010 at 6:23 PM, Scott Blum  wrote:

> Meh.  I've always thought our selections scripts were too big and
> complicated as is.  I'd rather we could figure out a way to get rid of meta
> properties altogether. :(
>

That may be, but do we have the time for it?  Such a project would easily
take a couple of weeks.

Would you object, Scott, to extending the existing system for now?  It's a
two-hour job once we decide on a convention.

-Lex

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

Re: [gwt-contrib] Re: when-linker-added

[Lex Spoon]

On Wed, Mar 3, 2010 at 12:25 PM, Bruce Johnson  wrote:

> Is there some sort of lightweight design doc for this? I'm pretty sure I
> remember it being discussed somewhere, but we need a short writeup on the
> project wiki to capture the context.
>

Sure, will do.  The discussions preceding this patch are in several
different places.  I can summarize them on the wiki.

FWIW, the original discussion thread is here:

http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/ebca7dc3b6171ea9/0b7c699b5775c046?lnk=raot


The initial patch coming out of that discussion is here:

http://gwt-code-reviews.appspot.com/143811/show


Seeing the actual patch seems to have gotten people to really think about
the compatibility breakage involved in changing the primary linker
selection, as discussed here:

https://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/bd7936cd2f323484/87009f6a5c5b6606?lnk=raot&pli=1

Everyone then very quickly agreed to go back to when-linker-added, which is
this patch.  This one is a lot simpler and is better about compatibility.

Lex

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

Re: [gwt-contrib] meta tag applying to just one module?

[Lex Spoon]

On Tue, Mar 2, 2010 at 3:35 PM, John Tamplin  wrote:

> So, the following would mean the per-module instance is never used, right?
>
> 
> 
>
> I suppose that could work, but it makes more sense to me to say that the
> module-specific one is used in that module regardless of the ordering.
>

It would be nice.  However, this is code that will be downloaded to the
browser, so it seems we should make sure it's paying its weight.

In this case, the desired effect can be achieved by rearranging the meta
tags.  Given that, last-one-wins seems like a simple rule that would support
all the use cases.



>
> Looking at that code, I just realized that my example was wrong.  It would
>> actually be like this:
>>
>> >   name="gwt.property"
>>   value="com.google.gwt.sample.mail.Mail::baseUrl=
>> http://static-content.service.com/mail";>
>>
>
> Ok, so only the value of gwt.property values would be scoped, no other GWT
> metas?  For example, you would not be able to have separate onLoadErrorFn's
> per module?
>

Good point.  I simply hadn't thought about anything but gwt.property.

If the module goes with the name attribute, then it would apply to all GWT
meta tags, not just the meta property ones.  It would look like this:


http://static-content.service.com/mail";>


What do people think about this version?

Lex

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

Re: [gwt-contrib] meta tag applying to just one module?

[Lex Spoon]

On Tue, Mar 2, 2010 at 3:14 PM, John Tamplin  wrote:

> On Tue, Mar 2, 2010 at 2:54 PM, Lex Spoon  wrote:
>
>> The meta property system looks like a good, clean solution.  All we need
>> to do is decide on a convention for having them be module-specific.  I don't
>> know the history of this feature or what all it is intended to support, but
>> it looks awfully straightforward to allow prepending moduleName:: before the
>> property name.
>>
>
>  So, in IFrameTemplate.js for example, the changes would be:
>
>- processMetas() keeps track of which properties it has seen and keeps
>the most-specific one of each, and ignores any property with :: that 
> doesn't
>have __MODULE_NAME__ as a prefix
>
> Yes.

What would most specific be?  I was thinking the last meta tag with any
given name would be the one that counts.  That's what the existing
meta-processing code does.

Looking at that code, I just realized that my example was wrong.  It would
actually be like this:

http://static-content.service.com/mail";>


>
>- how would the base URL lookup change?  I don't see that it looks for
>a meta property anyway, instead using a  tag -- are you suggesting
>adding a check for a meta property instead of / in addition to the 
>tag check?
>
>
Yes, that's the suggestion.Function computeScriptBase would be modified
to start with the following:

if (__gwt_getMetaProperty('baseUrl')) {
 base = __gwt_getMetaProperty('baseUrl')
 return;
}


Lex

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

Re: [gwt-contrib] meta tag applying to just one module?

[Lex Spoon]

On Mon, Mar 1, 2010 at 3:55 PM, Scott Blum  wrote:

> Avoiding the larger issue of meta tags applying globally, I'd think for
> this case there should be a more direct way to do it.  What I mean is, you
> have to load the *.cache.html files from *somewhere*.  So (from the inlined
> selection script), you have to do something roughly equivalent to:
>
> iframe.src = baseUrl + strongHash + ".cache.html"
>
> It seems like... whatever process is used to inline the selection script in
> the first place, has to be able to specify the base URL, at least relative
> to the host page base url.  Am I understanding this right?
>

That's right.  It would also be possible to modify the server-side support
for inlining the script.  However, barring other changes, that would mean
people are doing regex rewrites on our selection scripts, which seems rather
brittle.

The meta property system looks like a good, clean solution.  All we need to
do is decide on a convention for having them be module-specific.  I don't
know the history of this feature or what all it is intended to support, but
it looks awfully straightforward to allow prepending moduleName:: before the
property name.

Lex

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

[gwt-contrib] meta tag applying to just one module?

[Lex Spoon]

The meta tag system is a general system for a host page to influence a
loaded GWT module.  One aspect I don't understand, however: is there an
existing way to have it apply to just one module, if multiple GWT modules
are loaded on the same page?

The reason this comes up is that I would like to make the magic base URL be
settable by the host page for people who have inlined the selection script
into the host page.  For such people, the built-in magic can do the wrong
thing.

The first idea that was suggested was to use a meta tag.  However, wouldn't
t hat by default apply to all GWT apps loaded on the page?  It might be that
one app comes from one server and the other from a different one.

If there is no other idea around, then perhaps we could bake the module into
the "name" parameter, like this:


http://static-content.service.com/mail";>

If no "::" is present, then the setting applies to every module.


Lex

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

[gwt-contrib] Re: when-linker-added

[Lex Spoon]

Hey, Bob,

This patch is ready for review.  It's to support cross-site runAsync:
LoadingStrategy is a deferred binding that will end up depending on which
linker is active.

-Lex

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

Re: [gwt-contrib] Re: RFC: sharded linking

[Lex Spoon]

On Tue, Feb 16, 2010 at 3:32 PM, Scott Blum  wrote:

> On Fri, Feb 12, 2010 at 7:00 PM, Lex Spoon  wrote:
>
>> On Fri, Feb 12, 2010 at 9:50 AM, Alex Moffat wrote:
>>
>>> Where can I read a description of what -XshardPrecompile, or see the
>>> code for it, it sounds very useful to me personally?
>>
>>
>> -XshardPrecompile is an experiment that everyone wants to change, so it
>> seems unlikely to be released in its current form.  We can talk about it if
>> it helps, but I would propose that we focus more on what we want to do for
>> real.
>>
>
> It seemed relevant because it sounded like you propose to essentially make
> -XshardPrecompile the default (only?) behavior for Precompile?  Or did I
> misread?
>

No, that's the idea.




> The reason that makes me cautious has to do with a desire for a future
> change to the Generator API to support things like minimal rebuild.  I
> imagine a world where the work each Generator does could be sharded out in a
> way that's independent of the number of permutations.
>

Are you saying that you want to not have to shard, with future developments?
 I don't think that should be a problem with this patch.  As a case in
point, the Compiler entry point *could* shard out generating and linking,
but it chooses not to.  We have the flexibility to play around with these
choices over time.


- I'm not sure why development mode wouldn't run a sharded link first.
>>>  Wouldn't it make sense if development mode works just like production
>>> compile, it just runs a single "development mode" permutation shard link
>>> before running the final link?
>>>
>>
>> Sure, we can do that. Note, though, that they will be running against an
>> empty ArtifactSet, because there aren't any compiles for them to look at.
>>  Thus, they won't typically do anything.
>>
>
> Do public resources and generated resources show up during the sharded
> phase?
>

Everyone is happy, I think, with having dev mode run a single on-shard
linking step.  So, these are just details.  FWIW, here is how it is in the
patch:

1. Resources are available via ResourceOracle.
2. Public artifacts are be there.  They are identical on all permutations,
so they aren't added to the artifact set until the final link step.
3. Generated artifacts are there for compilation, but not for development
mode.  With development mode, all linking is done before the generators run,
and generators run on demand.


--- you write (gmail just messed up my reply quotes): 
 Now that I am thinking along those lines, it almost begs the question.  If
we are willing to break the world, is this the best possible way to model
new link process?  In other words, it seems worth re-examining the design
without regard to the existing API and asking ourselves if it's the thing
we'd have designed from scratch.  Maybe you guys all already did that and
I'm the only one late to the party.

For example, if we're going from scratch, then we could avoid the transition
entirely and just mandate what the new rules are.  We wouldn't need a
@Shardable annotation since all linkers would need to be sharding aware.  We
might rather have two separate methods for sharded vs. non-sharded link than
a boolean parameter.  We might revisit the whole PRE, PRIMARY, POST thing
with regards to sharding and decide the right answer is SHARD, PRE, PRIMARY,
POST.  Or something.  I don't know what the right answers are.  All I'm
saying is, breaking things is awesome when you're doing something
revolutionary and the end result is awesome.  I just want to be sure, if
we're going to break things, that we believe we'll end up somewhere
revolutionary and awesome as opposed to evolutionary and incremental, but
less than awesome.



I initially proposed simply breaking the world.  However, at your
encouragement, this patch has developed to be backwards compatible.  As
things stand, this patch both gets a large improvement and is evolutionary.

On those specific changes:

1. @Shardable can certainly be dropped after a deprecation period.  Is there
any urgency to drop it immediately?

2. Two separate methods versus one with a boolean looks fine to me.  It's
changed back and forth as the patch developed.

3.PRE/PRIMARY/POST still appear to be useful.  All linkers care whether they
are primary or not, because there is one primary linker and it must deal
with generating a selection script.  Additionally, a few linkers care
whether they go before or after the primary linker.

4. SHARD as a separate linker order is very tempting but turns out to have
some problems. First, many linkers have both an on-shard and on-fina

[gwt-contrib] Re: conditional linkers and the primary.linker property

[Lex Spoon]

On Tue, Feb 16, 2010 at 2:28 PM, Bob Vawter  wrote:

> >  
> >
> >
> > The old style will still work for any application it already works
> > for, but will be deprecated.  An example deprecation message is as
> > follows:
> >
> >
> >  [WARN] Linker 'test1' is primary but was not added via primary.linker
> >Instead of add-linker, use:  > value='test1' />
> >If that doesn't work, contact the linker's maintainer
>
> Having had some time to reflect on this design, I really can't get
> onboard with this kind of break-fix change.  I'm beginning to think
> that an additive approach of making rebinds sensitive to
>  rather than kicking all of our linker-writers in
> the shins would be a better way to achieve the specific effect that
> you're looking for.
>


Sounds good to me.  I have an implementation of that I could polish up.

Are there any objections to dropping this patch and adding
when-linker-added?  It would be used like this:

  


  


Lex

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

Re: [gwt-contrib] RR: Two key GWT.create to avoid boilerplate

[Lex Spoon]

On Sat, Feb 13, 2010 at 6:22 PM, Ray Cromwell  wrote:

> I'm not sure how my proposal creates more boilerplate, it adds the
> ability to specify arbitrary parameters to GWT.create, e.g.
>
> GWT.create(A.class, LiteralParam1, LiteralParam2, ...)
>
>
Sweet.  It looks like everyone is in favor of this part.  Unless someone
speaks to the contrary, it sounds like the lights are green for this one, as
soon as someone has time to do it.




> public class MyLibrary {
>   @GwtCreate
>   public static  T create(Class clazz) {
>  return GWT.create(clazz);
>   }
> }
>
> Usage:
>
> MyLibrary.create(Binder.class);
>

This part has the down side that it requires a special class loader for it
to work.  To contrast, GWT.create can be intercepted using regular Java code
by using GWT.setBridge.  This has proven useful for writing test cases.  It
would be very helpful to refine this to the point that it doesn't strictly
require using a special class loader.  For example, maybe we could insist
(and verify) that the body of one of these methods has the dev mode
implementation, and that it is in a stylized form ?

Also, the proposal on the blog entry mentions a variation of @GwtCreate that
takes the generator as an argument:

@GwtCreate(generator=com.foo.BarGenerator.class)
 T create(Class clazz)

This version looks at odds with the way deferred binding normally works.
 Normally, the module file chooses the generator, and it can even choose a
different generator for each permutation of the compile.  For this, let's
try and come up with a way to distinguish the separate interface types
inherited by clazz.

It might not even be necessary, though.  Note that when looking at the above
create() call, the supplied clazz argument has already been upcast to the
Bar interface.  Thus, even though the original class implemented Bar as well
as a bunch of other generatable interfaces, this particular call should be
deferred bound however Bar is deferred bound.

Lex

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

Re: [gwt-contrib] Re: RFC: sharded linking

[Lex Spoon]

On Thu, Feb 11, 2010 at 5:42 PM, John Tamplin  wrote:

> That is exactly my point -- the C++ example sends the preprocessed source
> to the worker nodes, so they don't have to have the dependencies or the
> right include path or whatever.  The analogy here would be for GWT to send
> all of the collected source, either in its native form or as is currently
> done in a parsed AST form, to the worker nodes.
>

For GWT it's less clear what to send.  We also need to make sure that the
remote node has the generator and linker implementations and any resources
they need.

In general, we can do some of these transfers for people if it helps.
 However, perhaps we could start by leaving it up to the surrounding build
tool, and then add support to GWT as more specific needs are identified?

Lex

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

Re: [gwt-contrib] RFC: sharded linking

[Lex Spoon]

On Thu, Feb 11, 2010 at 7:43 PM, Scott Blum  wrote:

> I have a few comments, but first I wanted to raise the point that I'm not
> sure why we're having this argument about maximally sharded Precompiles at
> all.  For one thing, it's already implemented, and optional, via
> "-XshardPrecompile".  I can't think of any reason to muck with this, or why
> it would have any relevance to sharded linking.  Can we just table that part
> for now, or is there something I'm missing?
>

There are still two modes, but there's no more need for an explicit
argument.  For Compiler, precompile is never sharded.  For the three-stage
entry points, full sharding happens iff all linkers are shardable.



> - I'm not sure why development mode wouldn't run a sharded link first.
>  Wouldn't it make sense if development mode works just like production
> compile, it just runs a single "development mode" permutation shard link
> before running the final link?
>

Sure, we can do that. Note, though, that they will be running against an
empty ArtifactSet, because there aren't any compiles for them to look at.
 Thus, they won't typically do anything.



> 2) Instead of trying to do automatic thinning, we just let the linkers
> themselves do the thinning.  For example, one of the most
> serialization-expensive things we do is serialize/deserialze symbolMaps.  To
> avoid this, we update SymbolMapsLinker to do most of its work during
> sharding, and update IFrameLinker (et al) to remove the CompilationResult
> during the sharded link so it never gets sent across to the final link.
>

In addition to the other issues pointed out, note that this adds ordering
constraints among the linkers.  Any linker that deletes something must run
after every linker that wants to look at it.  Your example wouldn't work as
is, because it would mean no POST linker can look at CompilationResults.  It
also wouldn't work to put the deletion in a POST linker, for the same
reason.  We'd have to work out a way for the deletions to happen last, after
all the normal linkage activity.

Suppose, continuing that idea, we add a POSTPOST order that is used only for
deletion.  If it's really only for deletion, then the usual link() API is
overly general, because it lets linkers both add and remove artifacts during
POSTPOST, which is not desired.  So, we want a POSTPOST API that is only for
deletion.  Linkers somehow or another mark artifacts for deletion, but not
anything else.  At this point, though, isn't it pretty much the same as the
automated thinning in the initial proposal?


> The pros to this idea are (I think) that you don't break anyone... instead
you
> opt-in to the optimization.  If you don't do anything, it should still
work, but
> maybe slower than it could.

The proposal that started this thread also does not break anyone.

Lex

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

Re: [gwt-contrib] Re: RFC: sharded linking

[Lex Spoon]

On Thu, Feb 11, 2010 at 8:58 PM, Brendan Kenny  wrote:
>
> If this is indeed the direction to go in (and I'm a big fan of the
> goals as well), it's probably also worth making a more formal
> definition for "won't step on each other's toes". As a use case, I'm
> working on a PRE linker that (currently) removes CompilationResults,
> alters them based on information collected from across all
> permutations, and then emits new ones. Obviously this isn't ideal--its
> expensive and CompilationResults were written to be (mostly)
> immutable--but it's also perfectly acceptable within the current
> design of the artifactSet/linker chain. The primary linker only cares
> about the set of compilation results it receives, and if an earlier
> linker altered them, it need never know.
>

Hey, Brendan, it sounds like you are already pressing the limits of what is
doable with linkers.Can you describe in more detail what this linker
accomplishes?

For this linker to be used in distributed builds, I believe you'd really
want to come up with a way to do the JS rewrites on the sharded part.
 Otherwise, the final link node is going to have to do the JS rewrites for
the whole build sequentially.  What exact information is used as input to
the rewrites?



> It seems (and I could definitely be misinterpreting here) that in both
> the simulated sharding procedure and Scott's alternate proposal, there
> will be sections of primary and post linkers running before a non-
> shardable pre linker. If that's true, then neither will be able to
> fully honor the ordering of linkers when shardable and non-shardable
> linkers are mixed.


That's a large part of why I suggested that we phase out non-sharded
linkers.  In mixed mode, there isn't a perfect ordering to choose.  With all
sharded linkers, the order is simple and predictable.  All sharded parts run
before all final parts, and within either of those groups, PRE/PRIMARY/POST
are respected.



> Continuing to think out loud, it seems that the way to alter my linker
> is probably either to statically derive what all permutations will
> need in every shard (as opposed to just having each triggered
> generator emit an artifact and collecting them at the end), or keeping
> that the same and creating a custom primary linker, which I was hoping
> not to do as it would tend to limit adoption.
>


It might help to know that both generators and linkers have access to the
full set of *possible* values of a deferred binding, not just the values for
the current permutation.  As an example, the LocaleListLinker reads off all
possible values of "locale" and generates a file containing them:

http://code.google.com/p/google-web-toolkit-incubator/source/browse/trunk/src/com/google/gwt/libideas/linker/LocaleListLinker.java



Lex

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

Re: [gwt-contrib] Re: RFC: sharded linking

[Lex Spoon]

On Fri, Feb 12, 2010 at 9:50 AM, Alex Moffat  wrote:

> Where can I read a description of what -XshardPrecompile, or see the
> code for it, it sounds very useful to me personally?


-XshardPrecompile is an experiment that everyone wants to change, so it
seems unlikely to be released in its current form.  We can talk about it if
it helps, but I would propose that we focus more on what we want to do for
real.



> It's not in 2.0.0
> as far as I can see. My concerns about the sharded linking proposal
> came from what I understood the original flow to be from my looking at
> it and from the original sharded linkin proposal.
>

Your understanding is correct as far as I can tell.

Lex

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

Re: [gwt-contrib] Re: RFC: sharded linking

[Lex Spoon]

On Wed, Feb 10, 2010 at 11:25 AM, James Northrup
wrote:

> the usecases being described as a point of deliberation, defining
> dependancies, repository access, and bundling automation, are well solved
> items in the maven stable.  how hard can it be to define a multiproject
> descriptor, assign "channels" of build-stage progression, and have a
> top-level project build coordinated by one maven instance publish artifacts
> to sucessive build-channels served elsewhere by daemons which trigger maven
> sub-builds?
>

That's a nice idea.  Has anyone heard of a project using  Maven to support
distributed builds?

The little bit of web searching I did turned up did not look good.  People
were saying it would be logical to build that way, but that Maven has a
fundamental showstopper: the local repositories are not thread safe.
 Perhaps that has changed by now?

Maven aside, there are other options.  Hudson and Pulse should work well.

Lex

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

Re: [gwt-contrib] Re: RFC: sharded linking

[Lex Spoon]

On Wed, Feb 10, 2010 at 10:58 AM, John Tamplin  wrote:

> On Wed, Feb 10, 2010 at 10:45 AM, Lex Spoon  wrote:
>>
>> Is copying source code so inconvenient that it would be worth having a
>> slower build?  I would have thought any of the following would work to move
>> source code from one machine to another:
>>
>> 1. rsync
>> 2. jar + scp
>> 3. "svn up" on the slave machines
>>
>> Do any of those seem practical for your situation, Alex?
>>
>> Overall, it's easy to provide an extra build staging as an option, but we
>> support a number of build stagings already
>>
>
> What does make it difficult is that you can't have a pool of worker
> machines that can build any project that are asked of them without copying
> the sources to the worker for each request.  For a large project, this can
> get problematic especially when you have to send the transitive
> dependencies.
>

You assume the answer here, John.  The question is, just why is copying
source code problematic to begin with?  Can anyone put their finger on it?

One concern is that the copying might take too long.  However, is there any
project where it would take more than a few seconds?  A few seconds seems
like not a big deal for any build large enough to bother with parallel
building.

Another possible concern is the need to do some extra build configuration.
 It doesn't take much *build time* to copy the dependencies, but it takes
*developer time* to set it up.  Here I agree that it is some amount of extra
work.  However, it doesn't seem like much.  You have to know what your
dependencies are, and you have already worked out how to copy
precompilation.ser, so how much more work is it to also send over the source
code?

Overall, I see that it worries people to send source code to the
CompilePerms nodes.  Yet, it seems entirely normal to me.  When you do a
distributed build, all the remote workers must have their inputs copied over
to them over the network.


Besides, what is gained by having the user have to arrange this copying
> themselves rather than the current method of sending it as part of the
> compile process?  For example, distributed C/C++ compilers send the
> preprocessed source to the worker nodes, so they don't have to have the
> source or the same include files, we currently send the AST which is a
> representation of the source, etc.
>

Compared to the status quo, we gain much faster builds.

Compared to automatically copying, we have a fully specced out proposal.  :)
 If we try to automatically copy dependencies, how would we we know exactly
what to copy?

Lex

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

Re: [gwt-contrib] Re: RFC: sharded linking

[Lex Spoon]

I've posted a patch for review here:

http://gwt-code-reviews.appspot.com/141811

Let's make it work well for everyone it impacts.

-Lex

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

Re: [gwt-contrib] Re: RFC: sharded linking

[Lex Spoon]

What you describe, Alex, is available via the "Compiler" entry point, though
it hasn't been particularly well documented.  There is a
PermutationWorkerFactory that can create CompilePerms workers.  The default
worker factory spawns Java VMs on the same machine, but it is possible to
write a replacement worker that uses ssh or whatnot to do the work on a
separate machine.  The way to plug in a replacement worker factory is to set
the Java property gwt.jjs.permutationWorkerFactory .


That said, I thought the reason for existence of Precompile, CompilePerms,
and Link is to get the best build time but at the expense of needing extra
configuration.  We are finding that by spending a few seconds copying source
code over, we save 10+ minutes in Precompile and 10+ minutes in Link.

Is copying source code so inconvenient that it would be worth having a
slower build?  I would have thought any of the following would work to move
source code from one machine to another:

1. rsync
2. jar + scp
3. "svn up" on the slave machines

Do any of those seem practical for your situation, Alex?

Overall, it's easy to provide an extra build staging as an option, but we
support a number of build stagings already

Lex

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

[gwt-contrib] RFC: sharded linking

[Lex Spoon]

This is a design doc about speeding up the link phase of GWT.  If you don't
maintain a linker, and if you don't have a multi-machine GWT build, then
none of this should matter to you.  If you do maintain a linker, let's make
sure your linker can be updated with the proposed changes.  If you do have a
multi-machine build, or if you have some ideas about them, then perhaps you
can help us get the best speed benefit possible out of this.

I want to speed up linking for multi-machine builds in two ways:

1. Allow more parts of linking to run in parallel.  In particular, anything
that happens once per permutation and does not need information from other
permutations can run in parallel.  As an example, the iframe linker chunks
the JavaScript of each permutation into multiple 

[gwt-contrib] Re: RR : Record selected annotations in Java AST

[Lex Spoon]

I was thinking JAnnotationArgument would be a marker interface, like in the
patch you just posted. If it was in the hierarchy, it would have to be a
subtype of expression, which looks a little weird to me.


-Lex

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

Re: [gwt-contrib] Re: Server-side Class object on client-side

[Lex Spoon]

On Wed, Jan 27, 2010 at 5:14 PM, Nathan Wells  wrote:

> interface RpcService {
>
>call(Class procedureClassLiteral, AsyncCallback callback,
> Arguments args)
>
> }
>

Makes sense.

Have you considered, though, the security implications of client code
sending an arbitrary class literal to the server?  If you end up writing a
server-side check that the class literal comes from a list of class literals
that are considered safe, then you could go one step further.  Instead of
sending a class literal, send the class literal's index in that list.

Or, similarly, make up an enum that has an entry for each possible class
literal, and send an element of the enum across the wire.  Convert the enum
to a class literal on the server side.


Lex

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

[gwt-contrib] Re: Unified Backend for Optimizing Java and JavaScript

[Lex Spoon]

Neat!  That's a cool framework, Sam, and it addresses a place that GWT could
benefit from greatly.  Let's talk about how best to take advantage of it;
there is a lot of optimization work going on right now.  -Lex
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Failing to find custom field serilializers in Oracle OC4J 10.1.3.5

[Lex Spoon]

On Wed, Jan 6, 2010 at 3:24 AM, stuckagain  wrote:

> It fixes the problem. By the way, might it be that the custom field
> serializers outside of gwt-servlet are in fact broken in 2.0.0 ? I see
> a message in the GWT newsgroup where they detected the same issue ?
> When can there be a patched 2.0, this is quite critical!
>
>
> http://groups.google.com/group/google-web-toolkit/browse_thread/thread/74256de92dd7e781#
>
>
I don't know what the real problem is, but I'm sure that custom serializers
are not broken in general.  There must be something more specific going
wrong.  -Lex
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: JSNI references with * as the parameter list

[Lex Spoon]

On Tue, Jan 5, 2010 at 4:38 PM, Lex Spoon  wrote:

> The main trick is in dealing with bridge methods.  I believe they should be
> ignored, because you can't normally call them in Java.  However, we
> unfortunately currently allow them.  So, as a compromise, the latest patch
> allows *direct* access to bridge methods, but it ignores them when resolving
> a wildcard.
>


To give an example, suppose StringHolder extends Settable, like
this:

abstract class Settable {
  abstract void set(T x);
}

class StringHolder {
  void set(String x) { /*...*/ }
}


>From the point of view of source code, StringHolder has only a single set()
method, and it takes a String as an argument.  However, in the Java
bytecode, it will have two set methods: it will have the String one, and a
bridge method that takes an Object as an argument.  The Object one just
forwards to the String one.  The Object one would be used in code like this:

  void setToNull(Settable settable) {
settable.set(null);  // calls the bridge method
  }


The current patch considers @StringHolder::set(*) to be unambiguous, because
it ignores bridge methods.

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

[gwt-contrib] Re: JSNI references with * as the parameter list

[Lex Spoon]

On Tue, Jan 5, 2010 at 12:40 PM, BobV  wrote:

> > I'm not in love with the current algorithm, but what precisely shall we
> do?
>
> For a given type, collect all method signatures that could conceivably
> be invoked via that type (and its superclasses or superinterfaces) and
> succeed only if there is exactly one unique signature with the given
> method name.
>

Okay, John T. wants the same algorithm.  I like it myself, anyway.  New
patch in just a minute.

The main trick is in dealing with bridge methods.  I believe they should be
ignored, because you can't normally call them in Java.  However, we
unfortunately currently allow them.  So, as a compromise, the latest patch
allows *direct* access to bridge methods, but it ignores them when resolving
a wildcard.

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

[gwt-contrib] Re: JSNI references with * as the parameter list

[Lex Spoon]

On Tue, Jan 5, 2010 at 12:20 PM,  wrote:

> I haven't looked at this, but should JsniCheckerTest get a new case as
> well?
>
>
Sure, I'll add one.  -Lex
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: JSNI references with * as the parameter list

[Lex Spoon]

On Mon, Jan 4, 2010 at 1:26 PM,  wrote:

> http://gwt-code-reviews.appspot.com/126817/diff/2006/2007
> File dev/core/test/com/google/gwt/dev/jjs/impl/JsniRefLookupTest.java
> (right):
>
> http://gwt-code-reviews.appspot.com/126817/diff/2006/2007#newcode234
> Line 234: JMethod res = (JMethod) lookup("test.Bar::foo(*)", errors);
> It seems weird that this should work. If Bar didn't declare foo() (and
> the lookup went up to the supertype Foo), this would fail to compile.
> It breaks the otherwise-Java style of name lookups used by JSNI to care
> about where the method is declared.  It also rewards the unnecessary
> (and ugly) practice of re-defining a method overload just to make it the
> "default".


> It's simplest to explain to users that the @class::method(*) wildcard
> syntax selects the one method out of the entire supertype/superinterface
> hierarchy whose name is "method" without having to get into discussions
> about which type a method is declared on.
>

As would be expected, the trickiest part of this patch has to do with
overloading and inheritance.  These are dark corners that good code will not
rely on, but our tools have to do something with them.

I'm not in love with the current algorithm, but what precisely shall we do?
 It's certainly important, but let's be careful not to bike shed the corner
cases.

For this particular test case, I thought that if someone defines Bar and Bar
has exactly one foo method, then Bar::foo(*) should be allowed, regardless
of what Bar inherits.  It's easy enough to disallow such a reference, but
should we?  We have a choice here between supporting good code and
eliminating bad code.  I fear that if we try to eliminate all the bad code
programmers could write, we will never be able to accept any code at all.
 It's just a design guideline, though.  Does anyone else have an opinion
about this question?

If we want to rule that case out, then my next suggestion would be to count
overloads exactly as a Java compiler would.  That would mean that methods
overriding each other would not count as extra overloads.  The main
trickiness would be dealing with inheritance that includes bridge methods.
 That wouldn't be insurmountable, but it's more complicated than the current
solution.

FWIW, the current algorithm is as follows.  I think it's pretty easy to work
with.  If the user asks for Foo::bar(*), then start in class Foo and look
for methods named bar.  If you see exactly one, then that's the one they
mean.  If you see more than one, then the reference is ambiguous.  If you
see zero, then recurse into inherited superclasses and methods.


Also, on that vein, add test code for looking up wildcards on
> interfaces.


Good idea, I will.

Lex

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

[gwt-contrib] Re: JSNI references with ?? as the parameter list

[Lex Spoon]

On Wed, Dec 23, 2009 at 9:35 AM, BobV  wrote:
> One quick note while I'm looking through the code is that using "??"
> as the wildcard is confusing.  Is that one question-mark for each
> parameter, meaning up to two parameters?  Using a asterisk would be
> more in keeping with regex-esque syntax.

Okay, that's three votes for *, if you count my initial patch.  I'll
change it back.  -Lex

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

[gwt-contrib] Re:

[Lex Spoon]

On Tue, Dec 22, 2009 at 2:58 PM, BobV  wrote:
>> The main question I have, though, is how to transition to such a
>> scheme?  Users currently write explicit add-linkers all over the
>> place.
>
> Since the choice of link style is an application, as opposed to
> library, kind of choice, and the switch is a one-liner, I propose that
> we break existing users in a helpful manner.

Ray Cromwell and I just talked about this, and it looks like legacy
code should not be broken with the changes immediately foreseen.
Legacy users would have a raw add-linker, but that's all they'll need
so long as they don't use runAsync.  So it looks like it's just a
matter of emitting good deprecation messages.


> 1) Add support for "deprecated" and "error" attributes to ,
> , , ,
> , and  tags
>  - This allows messaging to be done up-front, instead of waiting for
> the entire link cycle.
>  - The messages are emitted when the definitions are used with
> , , or the rebind rule matches
>  - Library developers also get some benefit in being able to
> turn-down existing .gwt.xml "API"

Hmm, I see only two things we want users to change:

1.Set the "linker" property rather than using add-linker, for primary linkers.
2. If you define a new primary linker, set up a way for users to use
it via "linker".

Given this, a single deprecation looks like enough: check for the use
of add-linker that (a) has no conditions in it, and (b) adds a primary
linker.

Do you see a need for more deprecation?  If that's all it is, then it
seems reasonable to hard code the specific deprecations in the
compiler rather than adding a general deprecation system for module
components.


Lex

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

Re: [gwt-contrib] Re: JSNI references with ?? as the parameter list

[Lex Spoon]

On Tue, Dec 22, 2009 at 2:29 PM, John Tamplin  wrote:
> On Tue, Dec 22, 2009 at 2:24 PM,  wrote:
>>
>> Very cool. Lex, wasn't there also a proposal a while back to allow the
>> current class to be omitted if you're referring to a method in the same
>> class, e.g.
>>
>> @this::someMethod(??)(a,b)
>>
>> or
>>
>> @class::someMethod(??)(a,b) ?
>>
>> or maybe just
>>
>> @::someMethod(??)(a,b)
>
> I believe this last one was the syntax we settled on (though at the time we
> discussed * to mean any arguments).

I would like being able to leave out the class type.  It's simply
extra work and somebody has to get around to it.  Already this patch
has been implemented for months now.

Do you remember, John, if we included the :: if the class type was
left off?  I was thinking we could do @someMethod(??)(a,b), which is
more concise.

Regording * vs. ?, I used * to begin with, and there was a request to
change it to ? at the meeting.  I changed it to ?? in this patch
because potentially we'd want to use a single ? as an individual
wildcard type rather than a sequence of them.


> Also, we discussed using imports for
> class resolution, though I am not sure how hard it is to get at them for JDT
> (and it doesn't impact IHM, since we already have to read the source to get
> JSNI source anyway).

Yes, that would be good, too.  This improvement is the hardest one of
the bunch.  In theory, the JDT should provide the information via its
"scope" and/or "environment" objects.  That's good, because then we
can use the true Java naming rules including accessing inner types
from parent classes.


Lex

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

[gwt-contrib] Re:

[Lex Spoon]

On Mon, Dec 21, 2009 at 11:24 PM, BobV  wrote:
> Make add-linker accept conditionals based on module properties? Then rebinds
> and linkers can have unified predicates.

Do you mean, instead of doing this:

  

People would normally do this:

  

Then the "linker" setting influences a bunch of others?

  

  


If that's what you mean, it sounds rather elegant.  The thing users
configure are properties, and then everything else including linker
addition is rule-driven.

The main question I have, though, is how to transition to such a
scheme?  Users currently write explicit add-linkers all over the
place.


Lex

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

[gwt-contrib]

[Lex Spoon]

There are a couple of different ways that the choice of linker affects
what the compiler should do with runAsync:

1. If the code will be loaded inside a nested function, then variable
and function definitions need to be rewritten if they are referenced
on a different fragment than the one that loads them.

2. If the code could be loaded in violation of the same origin policy,
then a script tag rather than XHR needs to be used to download the
code.


One way to allow this sort of flexibility would be to add methods to
the Linker API.  However, it's hard to see what the extensions should
look like.  Unless there is a general ability to add new passes via
the Linker API, there would have to be a new method in the API for
each compiler option a linker might ever influence.

Instead, how about allowing deferred bindings to be controlled by the
linker choice?  Then, if linker A is chosen, it could flip deferred
binding B.  A specific syntax could be as follows:

  


  



This looks both simple and general.  Does this seem reasonable?  Does
anyone see a better way?

Lex Spoon

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

Re: [gwt-contrib] Revisiting the script-via- default linkage

[Lex Spoon]

On Tue, Dec 15, 2009 at 2:53 PM, John Tamplin  wrote:
> On Tue, Dec 15, 2009 at 2:48 PM, Lex Spoon  wrote:
>>
>> Ideas would be welcome about how to deal with that.
>
> Could the fragments include some JS at the end which calls a well-known "I
> loaded successfully" method?

Yes, and in fact they already do.  I'm leaning at this point toward
indicating "failure" on any of: onload, onerror,
onreadystatechange(loaded), onreadystatechange(complete).

Lex

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

Re: [gwt-contrib] Revisiting the script-via- default linkage

[Lex Spoon]

Hey, Matt,

I've now double checked on several browsers other than Opera, and I
agree that onerror works on non-IE and onreadystatechange works on IE.
 Details here:

http://blog.lexspoon.org/2009/12/detecting-download-failures-with-script.html


One tricky aspect is that I don't see how to get IE to say whether or
not the download really failed.  Sometimes the "loaded" state is
reached when loading a page that is not in cache.

Ideas would be welcome about how to deal with that.  In the
experiments I did, the callback always happens after the script
evaluation.  If that sequencing is reliable, then it will work to
always call the on-failed handler but to have AsyncFragmentLoader
quietly ignore such calls if the fragment has already loaded
successfully.  It tracks the already-loaded fragments anyway, these
days, so this would be easy to do.  As a bonus, always calling,
whether in  state "loaded" or "complete", would give good handling to
situations where the browser downloads *some* content but it's not the
real JS code, e.g. the "please log in" pages that hotel wifi networks
insert.

Lex

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

Re: [gwt-contrib] Revisiting the script-via- default linkage

[Lex Spoon]

On Wed, Dec 9, 2009 at 12:47 PM, Matt Mastracci  wrote:
> Do you know how to get onerror to fire in IE?  It didn't seem to work in my
> testing.

No, but why do you need it if you have onreadystatechanged?  It should
be no problem to hook up both callbacks.

Lex

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

[gwt-contrib] Re: Flow analysis framework definition and solver.

[Lex Spoon]

On Tue, Dec 1, 2009 at 5:59 PM, Mike Aizatsky  wrote:
>> Well, it would be sitting in svn and not being tested in any way
>> except that it compiles.  If you want to commit the pieces somewhere,
>> why don't we make an svn branch?
>
> I don't think svn branch will help much. It will only add headaches.
> What do you say if I would merge all LGTM'ed changes together into
> single git branch on my workstation? This would at least help me
> reduce the number of branches to maintain to 3: dev branch, under
> review branch, LGTM'ed branch. I can also actively export that branch
> to github if you need.

Sounds good.  Git is optional; please do if it's easy, but don't worry
if it's not.  I can patch in multiple patches just fine.



>> For using this framework to walk the callgraph, I understand that the
>> implementation is simple, but simple things often don't perform well.
>> An easily O(n^3) graph traversal is okay if n is only the size of one
>> method, but is problematic if we are talking about a whole program.
>
> I don't see where you get O(n^3). Solver algorithm complexity is O(e *
> l) where e is number of edges, and l is lattice height. For a simple
> boolean lattice l = 2, so this should be quite efficient from
> algorithmic point of view.

I said n^3 because frequently the information is a set that is
proportional to the size of the program.  For example, we'd like to
analyze "clinits that have definitely been called".   Then the lattice
height is the number of classes in the program, which is proportional
to n.

When you multiply it all out you get n^3 or n^4, depending on how big
you assume the call graphs are.


Lex

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

[gwt-contrib] Re: Flow analysis framework definition and solver.

[Lex Spoon]

On Tue, Dec 1, 2009 at 4:52 PM,   wrote:
> I can create a separate CFG changelist + CFG-based analyses changelist.
> I just worry that I will have to maintain several changelist branches +
> main branch with all the code together. I would certainly prefer to land
> this code into SVN even before it's actually plugged into compiler.

Well, it would be sitting in svn and not being tested in any way
except that it compiles.  If you want to commit the pieces somewhere,
why don't we make an svn branch?
  Shall I do that?  We can then put in the patches as they are
committed on the branch, and merge it to trunk once enough is in that
it does something.

For using this framework to walk the callgraph, I understand that the
implementation is simple, but simple things often don't perform well.
An easily O(n^3) graph traversal is okay if n is only the size of one
method, but is problematic if we are talking about a whole program.
Mostly, though, I'd simply like to divide the issue.  Since the patch
is already large, let's do the intra-proc part first.

Lex

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

Re: [gwt-contrib] Revisiting the script-via- default linkage

[Lex Spoon]

Thanks for the test code and data, Matt!  It sounds like enough
browsers are covered that error reporting is no longer a major decider
between XHR vs. script tags.

Regarding iframes, be aware that some GWT users can't use them.  I
don't know all the reasons why, but one example reason is that iframes
don't work reasonably on iPhones.  So, we need to support non-iframe
linkers for at least some use cases.


Lex

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

Re: [gwt-contrib] Revisiting the script-via- default linkage

[Lex Spoon]

On Mon, Nov 30, 2009 at 10:28 PM, Matt Mastracci  wrote:
> 2.  onerror works some of the time in some of the browsers. It fails on
> various combinations of resolve errors, error status codes and other failure
> conditions. For all browsers (except Opera) that don't support it directly,
> It can be emulated with onreadystatechange/onload and lack of a JSONP
> callback.

Can you expand on that?  IE has script-tag callbacks that should be
usable to detect download errors.  What did you get working on other
browsers?

If there's a way to detect download failures on Firefox and on
Webkit-based browser, then JSONP downloads are better than I thought.

Lex

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

Re: [gwt-contrib] Revisiting the script-via- default linkage

[Lex Spoon]

(Reposting to get it on the mailing list; first try bounced.)


Hey, Matt,

I agree with your analysis about the code-splitting issues.

I've worked out a preliminary patch to do var renaming, but I haven't
shared it yet because it's in a pretty early state.  I could share it
if you or someone is eager enough to see it that you're willing to
hack some code to get to use it.

To really get it polished up into a committable state, the main issue
will be figuring out when to enable the rewrites.Whether to enable
it or not depends on the choice of linker.

For the off-domain loading, I was thinking to look into a JSONP-like
downloader.  That, too, is something that should only optionally be
enabled, because it has worse download failure reporting.  Thus, again
the hardest part will be figuring out when to enable it.

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

Re: [gwt-contrib] Re: Allow declared RuntimeExceptions to be correctly propagated

[Lex Spoon]

On Fri, Nov 20, 2009 at 2:08 PM, BobV  wrote:
> Including declared RTE's has been there since 1.5.  Since the user has
> explicitly asked for those throwable types, I'm thinking that it's no
> worse than any other exception type.

Okay, I suppose we are stuck with it, then.  I don't immediately see
an easy way to ween people off of them if they are already using them.
 Adding a warning to STOB output would not be paid attention to.

>  What we should do as a
> sanity-check is to explicitly disallow
>
> void serviceMethod() throws Exception;
> void serviceMethod() throws RuntimeException;
>
> because that would be hideously expensive.

Tempting, but those have also been supported since at least 1.5

Lex

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

Re: [gwt-contrib] Re: Allow declared RuntimeExceptions to be correctly propagated

[Lex Spoon]

On Fri, Nov 20, 2009 at 9:01 AM, BobV  wrote:
> Thanks for the review.
>
>> My only question is anything required for STOB to handle declared
>> RuntimeExceptions, or is this only for deRPC?
>
> ProxyCreator.addRemoteServiceRootTypes() iterates over the declared
> exception types for any given RPC method.   It imposes a constraint
> that they're derived from Exception.  STOB has no mention of
> RuntimeException, nor does it have any reason to treat exception types
> differently from return types.

That looks like an accident.  It looks like the intent was never to
serialize an unchecked exception.

When John and I talked about this issue previously, we couldn't come
up with an example where you'd really need to serialize an unchecked
exception.  You could always either make it checked, or throw a
different exception instead of the unchecked one.

Are there any use cases for serializing an unchecked exception, or
could we instead have STOB skip RunTimeExceptions just like it skips
Errors?


Lex

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

[gwt-contrib] Re: Use 1-based counting for permutations in Compile Report

[Lex Spoon]

Consistency is good, but this patch breaks a different consistency!
Specifically, the symbolMaps files count permutations from 0.  So
permutation 3 in the compile report would be permutation 2 in the
symbolMaps files.  I think that consistency is more important than
that the permutation counting and split point counting use the same
numbering.  If someone reads about permutation 3 in their compile
report, they should be able to safely look at permutation 3 in the
symbol information and in any other files the compiler emits.

The easier of the two numberings to change is the permutation
numbering.  The symbol maps numbering must be coming from some
PermutationResult or something.  We could trace backward to find out
where that number originally comes from, and shift them all to be
1-based.

Making the split point numbers 0-based is certainly possible but could
touch a lot of code.  The biggest issue is that CodeSplitter already
uses split point 0, which doesn't really exist, as a convention
indicating the initial download.  If split point 0 was a real split
point, then some other number would have to be used.

Lex

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

[gwt-contrib] Re: adding new names to the blackout list

[Lex Spoon]

On Tue, Nov 17, 2009 at 3:11 PM, Freeland Abbott  wrote:
> I don't promise this is exhaustive, but it catches up to the mozilla and IE
> references, plus uneval from issue 3965.  (Which wasn't on the mozilla
> pages, despite being reserved there, so I'm in fact almost sure this
> isn't exhaustive...)


LGTM.  -Lex

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

[gwt-contrib] Re: Inline Polymorphic Function Declarations

[Lex Spoon]

I can review it.  -Lex

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

[gwt-contrib] Re: Inline Polymorphic Function Declarations

[Lex Spoon]

This is neat, Bob!  It's also timely.  I've been looking into
prefetching for runAsync code, and the folks I've talked to are
worried about locking up the browser with giant evals.  Lazy eval as
in this patch would enable people to prefetch code more aggressively.

Like you say, it likely needs to chunk more than one function at a
time.  It would be a very helpful next step on this if it could chunk,
say, 10 functions at a time rather than just one.  We would then be in
a position to tune the chunk size.

Speaking of which, unless I am mistaken we currently lack the key
performance numbers we need to make a good tuning.  Most pressingly,
we need to know the overhead for each extra call to eval, and we need
to know how gzipped script size changes with lazy eval under different
chunk sizes.

One last thing.  It would help if there was a way to eval the
functions without running the resulting functions.  That way, code
could be evalled in the background whenever the app is idle.  For
example, functions like this:

  function foo(args) { implementation; }

could be replaced with this:

  function install_foo() { install_foo = noop;
eval(code_to_install_foo_for_real); }
  function foo(args) { install_foo(); foo(args); }


Now install_foo can be called by itself during idle time.

Lex


PS -- In the implementation, Bob, I believe the class comment could
safely be expanded without becoming a wall of text.

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

[gwt-contrib] Re: Some disk-cache optimizations

[Lex Spoon]

LGTM.

Lex Spoon

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

[gwt-contrib] Re: Any plans for supporting Scala ?

[Lex Spoon]

On Mon, Oct 5, 2009 at 12:37 PM, Ray Cromwell  wrote:
>
> if I understand, Lex is not really talking about a new syntax/text
> representation, but an intermediate Java AST that has none of the
> restrictions that Java does.

I was thinking it would be a text format, but it could be a binary
format if that looks easier.

Lex

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

[gwt-contrib] Re: Any plans for supporting Scala ?

[Lex Spoon]

On Mon, Oct 5, 2009 at 12:23 PM, John Tamplin  wrote:
> Why would that be easier than just parsing Scala and building an extended
> GWT AST from the Scala AST?  It seems like inventing a new language (even if
> it is close to Java) and modifying tools on both sides to use this would be
> more work.

Parsing isn't enough.  It would also be necessary to type check, so
that the meaning of the ASTs can be understand.  After that, it would
be necessary to desugar the Scala ASTs down into Java equivalents.
That adds up to the bulk of a Scala compiler.  Especially the type
checking part would take a lot of time to reimplement.

The next best thing would be to call into the existing Scala compiler.
 However, doing it that way means that we have to figure out a way to
supply people with compatible versions of the GWT compiler and Scala
compiler.  If we don't come up with a stable API between the two code
bases, then we'll have to figure out a way to supply users binaries of
each language that work well together.  We can do that, but it will
mean people have an extra constraint when they choose which version of
GWT and which version of Scala they want to use.  Coming up with an
API looks better.

The text format would essentially be such an API.  It is unlikely to
change much over time, because both code bases are tracking Java's
glacial motion.  Further, it shouldn't be too time consuming to
develop, because it's only use would be to make two known code bases
be able to talk to each other.

Lex

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

[gwt-contrib] Re: Any plans for supporting Scala ?

[Lex Spoon]

Let me try and sum up where things are.

Regarding manpower, I spent a month or two spending 20% time on this,
following all of the threads discussed in this email.  From where
things are, I would estimate a 3-week full time effort to get a basic
version working that, for example, translated function literals the
same way that inner classes are translated.  Getting structural method
calls to work would take a little while longer, but they aren't used
that much in most Scala code.  Getting Scala function literals
translated to JavaScript function literals would require updating
GWT's IR analogous to what Max describes, and nobody has really
thought through a specific plan for that.

If anyone wants to work on this, I can give all the relevant Scala and
GWT pointers.  Just let me know.  It would involve writing some Scala
code, but would not require any deep knowledge of compilers.

Let me now update all the subthreads I see on here with what I found.
Please ping if I have overlooked something.

Decompilation does not work on Scala.  I tried all the ones I could
get my hands on, and they all fail.  It's been about a year, so if
anyone knows of a decompiler breakthrough in that time, it might be
possible now.  However, it would take large changes.  The decompiled
output I looked at was fine for 90% of the code, but the remaining 10%
included some really big problems that needed solving.

Generating Java source code from scalac might be possible, but it's
terribly difficult.  Java source code does not want to be a target
language.  Java rejects all kinds of code that are logical but that
wouldn't make sense to write by hand.  When I started on this path, I
enumerated all the problems I knew of and found a solution to all of
them.  However, along the way, more of them popped up.  None of them
were ever fatal by themselves, but there are a bunch of them.

A better tactic would be to define a modified Java source language
that does not have the restrictions.  It would be pretty much the same
as Java, but with a few changes.  A partial list of changes would be:

1. There is no rule in constructors about calling the super()
constructor as the syntactically first thing in a constructor.
2. There is a comma operator expression just like in JavaScript.
3. Any expression can be used in an expression statement, even useless
things like literals.
4. The types would all be Java erased types.
5. Probably imports would be removed.
6. Overloading and overriding would be as in Java byte code, including
override on return type.
7. That probably implies that method calls are also as in Java byte
code, and specify the full method signature.

This plan has the huge advantage that everything in the chain is under
our control.  The Scala compiler could generate this language, and GWT
could read it.

Also, per John's comments about decompiling Java, note that we could
plan to update this language to support more source languages than
just Java.  It should be much easier for them to emit what they mean
than for GWT to reverse engineer what their bytecode intended.


Lex Spoon

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

[gwt-contrib] Re: -soyc runs the dashboard, too

[Lex Spoon]

On Sat, Oct 3, 2009 at 2:30 AM, Sami Jaber  wrote:
> ping ?
> Is it possible to know when this new feature will be commited ?
> as I understand it, soyc-vis.jar will be taken out and replaced by gwtc
> -report that will generate in the same time soyc reports and the dashboard.
> can we still use the term "SOYC" in GWT 2 or it is going to be replaced by a
> more "marketing/friendly" naming as "dev mode" was replaced by OOPHM and
> "production mode" by web mode ?

It's committed to GWT's trunk.  It will hit Perforce this week or next.

The soyc-vis.jar will still exist but will be deprecated.

The option name is still -soyc.  The thinking is to rename it to
"compile report" and to update the option accordingly.

Lex

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

[gwt-contrib] Re: -soyc runs the dashboard, too

[Lex Spoon]

Cool.  Does the new code LGTY?  -Lex

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

[gwt-contrib] Re: Flattener/UnFlattener/Dataflow patch

[Lex Spoon]

Cool.  I'm in the middle of looking at the rest of it.  -Lex

On Tue, Sep 15, 2009 at 4:27 PM,   wrote:
> Ray, I was going to look at Flattener specifically, and I think Lex the
> rest of the patch.
>
> I only patched in Flattener, but I ran into lots of sort/format issues.
> Please fix those and attach an updated patch to this issue.
>
> For instructions on setting up Eclipse for GWT development, please see:
>
> http://google-web-toolkit.googlecode.com/svn/trunk/eclipse/README.txt
>
>
> http://gwt-code-reviews.appspot.com/64814
>

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

[gwt-contrib] Re: CloneStatementVisitor

[Lex Spoon]

On Fri, Sep 11, 2009 at 4:25 PM, Scott Blum  wrote:
> Gotcha.  Okay that makes sense.  At the same time, I can't help but wonder
> if the idea of retargeting to new params/locals couldn't somehow be baked
> into the Cloners to force the issue.

Conceivably a statement could be cloned and then put back in the same
method.  So, a clone of a parameter ref makes sense on its own.  It
depends on what you do with it, or with what other transformations you
do afterwards.

A check at the place the item is added into a tree would certainly
make sense, but it would probably slow down the compiles.  As one
possibility, Context.replaceMe could, if some paranoid mode flag is
turned on, verify that the inserted tree makes sense.

Lex

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

[gwt-contrib] Re: RR: STOB short circuit path must also compute some side information

[Lex Spoon]

Committed at r5982.

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

[gwt-contrib] Re: RR: STOB short circuit path must also compute some side information

[Lex Spoon]

Here is an updated patch with the method rename and the updated docs.
I'm still waiting on trunk to stabilize before committing.  -Lex

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



stobStringArrayArray2-r5972.patch
Description: Binary data

[gwt-contrib] Re: RR: STOB short circuit path must also compute some side information

[Lex Spoon]

2009/8/18 Freeland Abbott :
> Looks fine... the only comments are pretty cosmetic: changing
> checkTypeInstantiable() (and checkArrayInstantiable() also) to return
> non-boolean should probably also change its name; something like
> computeInstantiability() may be a better name.  It also may warrant more
> explicit javadoc.  It just feels very, very odd to me to have the return
> value of "check" then have additional methods to call!

Agreed!  I'll change the name to computeInstantiability.  Also, I
simply forgot about the javadoc; I'll update it.  -Lex

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

[gwt-contrib] RR: STOB short circuit path must also compute some side information

[Lex Spoon]

I'm posting directly to the list, because I got error 500 on Reitveldt.

This is a simple patch.  There is a small problem in a short-circuit
path in  SerializableTypeOracleBuilder (STOB).  The short circuit is
to check if a type has already been examined and, if so, returns "yes,
it's serializable".  The problem is that in that same place, it is
necessary to compute extra information about the queried type: the
instantiable subtypes of the request.  Currently that doesn't happen
on the short-circuit path.  The empty set is returned, leading to the
serialization policy having too few types, leading to run-time
serialization failures.

To fix this, the attached patch stores the instantiable types
information in TypeInfoComputed.  That way, the short circuit path has
the infromation available.  This percolated to a few other small
changes:

1. checkTypeInstantiable returns a whole TypeInfoComputed instead of a boolean

2. TypeInfoComputed can now handle an arbitrary JType, not just a
reference type.

3. checkTypesInstantiable no longer takes a set as an argument for
passing back the instantiable subtypes, because that information is in
the returned TypeInfoComputed.


Lex

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



stobStringArrayArray-r5972.patch
Description: Binary data