BTW, something was changed recently to use context class loader. This is corrected patch.
On Mon, Oct 6, 2008 at 10:36 AM, Mike Aizatsky <[EMAIL PROTECTED]> wrote: > Sorry, forgot to attach new patch. Here it is. > > On Mon, Oct 6, 2008 at 10:32 AM, Mike Aizatsky <[EMAIL PROTECTED]> wrote: >> Scott, >> >>> - Could briefly summarize the motivation for the >>> suite()/JJSOptimizerTestDecator design? >> >> This way the module will be compiled only once. Unfortunately >> JavaToJavaScriptCompiler doesn't have any easily extract compiling >> pass and I didn't want to seriously refactor it. >> >>> - JJSOptimizerTestCase.staticJprogram strikes me as scary.. is this >>> necessary? >> >> How else would you pass values from static context? >> >>> - Textual comparison seems like a great first step, but a bit brittle going >>> forward. I'd worry that changes in the compiler totally unrelated to an >>> optimization pass would tend to unnecessarily break tests. >> >> That's a valid point and I saw this in the fast. I don't know a >> solution for this. Writing manual tree-based checks is even more >> fragile. >> However I do believe this is better than nothing. >> >>> - Noticed many issues with things like sort order, formatting, spelling. >>> Have you looked at the GWT eclipse setup? >> >> Opened everything in Eclipse and reformatted/reorder. See the attached patch. >> >>> - Very high-level: We should talk about doing something more invasive to >>> make testing lighter weight. There's really no reason to have to setup a >>> GWT module to do a test... with some refactoring we could make it as easy as >>> providing some input source and some output source. >> >> There still be a compilation step, right? Are you sure it will be easy >> to set up all binding, intrinsic stuff, etc. without the module? >> >> On Mon, Oct 6, 2008 at 7:49 AM, Scott Blum <[EMAIL PROTECTED]> wrote: >>> Hi Mike, >> >>> I'm really glad you broke ground on this. I took a look, but wanted to ask >>> a question or two and give some high-level feedback before I dig in too >>> much. >> >>> - Could briefly summarize the motivation for the >>> suite()/JJSOptimizerTestDecator design? >> >>> - JJSOptimizerTestCase.staticJprogram strikes me as scary.. is this >>> necessary? >>> >>> - Textual comparison seems like a great first step, but a bit brittle going >>> forward. I'd worry that changes in the compiler totally unrelated to an >>> optimization pass would tend to unnecessarily break tests. >>> - Noticed many issues with things like sort order, formatting, spelling. >>> Have you looked at the GWT eclipse setup? >>> - Very high-level: We should talk about doing something more invasive to >>> make testing lighter weight. There's really no reason to have to setup a >>> GWT module to do a test... with some refactoring we could make it as easy as >>> providing some input source and some output source. >>> >> >> >> >> -- >> Regards, >> Mike >> > > > > -- > Regards, > Mike > -- Regards, Mike --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
test_framework.patch
Description: Binary data
