Author: kpro...@google.com
Date: Mon Dec 15 18:47:24 2008
New Revision: 4344
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/linker/CompilationAnalysis.java
trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/StandardCompilationAnalysis.java
trunk/dev/core/src/com/google/g
Thank you! Committed as revision 4344.
kathrin
On Mon, Dec 15, 2008 at 6:08 PM, Lex Spoon wrote:
>
> On Mon, Dec 15, 2008 at 4:47 PM, Katharina Probst wrote:
>> Hi Lex,
>>
>> I've made all the changes you requested except the first, which we
>> have decided not to do for now (reason: SourceIn
Sony, even if this doesn't make it into the incubator there is nothing
stopping you from placing it in your own Google Code project and publicizing
it here and on users. I imagine there are a lot of DSL fans out there who
might be interested.
rjrjr
On Tue, Dec 16, 2008 at 9:29 AM, Sony wrote:
>
On Mon, Dec 15, 2008 at 4:47 PM, Katharina Probst wrote:
> Hi Lex,
>
> I've made all the changes you requested except the first, which we
> have decided not to do for now (reason: SourceInfo does not contain a
> pointer to the node, so instead we would have to keep JMethod around
> until link tim
> This isn't a compiler bug, it's caused by hosted mode being perhaps slightly
> overeager? The deal is, the custom field serializer for Arrays.asList()
> (com.google.gwt.user.client.rpc.core.java.util.Arrays.ArrayList_CustomFieldSerializer),
> has a method getArray0() that uses a JSNI reference
For more info on this topic refer to my Article: Fluent DSL for Rich
UI
on theServerSide.com:
http://www.theserverside.com/news/thread.tss?thread_id=52241
on my blog: http://sonymathew.blogspot.com/2008/12/fluent-dsl-for-rich-ui.html
Thanks
Sony
On Oct 27, 11:55 am, Sony wrote:
> dflorey, Is
> Bob, do you have any idea how hard it would be to trigger off of
> module settings rather than a command line flag? I believe this will
> require threading through the module meta-data into parts of the
> compiler that currently don't have access to it.
I looked at making it deferred-binding
Thanks. Committed as r1319.
On Mon, Dec 15, 2008 at 5:14 PM, Emily Crutcher wrote:
> LGTM.
>
> On Mon, Dec 15, 2008 at 4:51 PM, Isaac Truett wrote:
>>
>> Good enough for me. Here's the patch for building demos off of the jar:
>>
>> Index: build.xml
>> ===
LGTM.
On Mon, Dec 15, 2008 at 4:51 PM, Isaac Truett wrote:
>
> Good enough for me. Here's the patch for building demos off of the jar:
>
> Index: build.xml
> ===
> --- build.xml (revision 1316)
> +++ build.xml (working copy)
> @
Good enough for me. Here's the patch for building demos off of the jar:
Index: build.xml
===
--- build.xml (revision 1316)
+++ build.xml (working copy)
@@ -371,8 +371,7 @@
vmMaxMemory="${gwtc.vm.maxMemory}">
Hi Lex,
I've made all the changes you requested except the first, which we
have decided not to do for now (reason: SourceInfo does not contain a
pointer to the node, so instead we would have to keep JMethod around
until link time, which seemed overkill).
Please let me know what you think.
Thanks
The reasons I would prefer to use the gwt-incubator.jar is because that
gives us a quick sanity check that the gwt-incubator jar is actually
including everything needed to run the demos!
>
>
> + project.src and project.bin can be overridden, if desired (super
> could be overridden if it used a var
This change addresses gwt-incubator issue #208. The build-demos Ant
target fails to compile demos that depend on super-source. The change
(see below) places 'super' in the classpath before src. Another
solution, suggested by Emily, is to use the fully formed
gwt-incubator.jar instead of the indivi
John, could you review the following change?
GWT has a fatal error if you try to redefine the same property twice. This
means that gen2 logging and libideas.logging cannot live side by side, it
also spells trouble for any project using gwt-log or other solutions.
This code change renames the logg
Author: amitman...@google.com
Date: Mon Dec 15 11:25:42 2008
New Revision: 4342
Modified:
releases/1.6/distro-source/linux/build.xml
releases/1.6/distro-source/mac/build.xml
releases/1.6/distro-source/windows/build.xml
Log:
Adds api-checker to the distro.
Patch by: amitmanjhi
Review
Thanks Eric. Commited as r4342. Yes, it is meant to patch against 1.6. The
trunk build files in the distro have additional lines for soyc, which caused
the patch to fail.
On Mon, Dec 15, 2008 at 1:59 PM, Eric Ayers wrote:
> LGTM, Assuming its meant to patch against 1.6 (didn't work when I
> trie
LGTM, Assuming its meant to patch against 1.6 (didn't work when I
tried to apply it against trunk)
On Mon, Dec 15, 2008 at 10:39 AM, Amit Manjhi wrote:
> Hi Eric,
>
> Please review the attached patch to the build files that add api-checker to
> the distro.
>
> Regards,
> Amit
>
--
Eric Z. Ay
Sorry Joel, it was a typo. Should be com.google.gwt.xml.client.*
instead of com.google.gwt.dom.client.*
- Andrés
On 15 dic, 14:31, Joel Webber wrote:
> @mP: I completely agree that it's worth seeing if these things can be done
> *without* changing the compiler. In this case, though, I'd have t
On Mon, Dec 15, 2008 at 11:11 AM, Bruce Johnson wrote:
> One thing we need to reconcile before it gets away from us: for things like
> this (and anticipated additional settings), should these be command-line
> compiler flags or module settings?
> I am more in favor of using module settings (speci
@mP: I completely agree that it's worth seeing if these things can be done
*without* changing the compiler. In this case, though, I'd have to agree
with your "Cons" section, that it's pretty weird to have two versions of a
class. Makes debugging really suck, too :)
@Andrés: This would indeed make
One thing we need to reconcile before it gets away from us: for things like
this (and anticipated additional settings), should these be command-line
compiler flags or module settings?
I am more in favor of using module settings (specifically, deferred binding
properties that the compiler is sensiti
Hi Eric,
Please review the attached patch to the build files that add api-checker to
the distro.
Regards,
Amit
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index: distro
Actually, hold off on this review please. In my haste, forgot to update
MenuBar and SuggestBox to take advantage of the new alwaysAutoHide
boolean.
http://gwt-code-reviews.appspot.com/814
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Con
On Sun, Dec 14, 2008 at 6:45 PM, Cameron Braid wrote:
> a) bug in compiler - see attached oophm-stacktrace.txt
>
This isn't a compiler bug, it's caused by hosted mode being perhaps slightly
overeager? The deal is, the custom field serializer for Arrays.asList()
(com.google.gwt.user.client.rpc.c
I'm not sure I agree with your basic premise, for instance, ironically
enough, the first Google link for the keywords "java example custom events"
is indeed another example of a happy event:
(
http://www.javaworld.com/javaworld/javaqa/2002-03/01-qa-0315-happyevent.html
).
That said, I am not oppos
Thanks for responses.
We will create own jar with LocalizableResource, Messages, Constants,
and ConstantsWithLookup for usage of the same interfaces in GWT, Swing
and server side.
With regards
Marek
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-
I was trying to demonstrate the practical difference that runAsync
would make when compared to a monolithic deployment to someone today,
and there was no simple way to turn off runAsync that wasn't the
-disableAggressiveOptimizations flag.
This patch adds an undocumented flag -disableRunAsync th
27 matches
Mail list logo
