Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <001801ce351b$6772d0d0$36587270$@gmail.com>
References: <032a01ce344c$17432bc0$45c98340$@gmail.com>
	<CAJs+wW2ycPvHEUjjio-nuFe6TsOceL_37akkc_B3aoTz0COxvQ@mail.gmail.com>
	<001601ce3506$3688e460$a39aad20$@gmail.com>
	<CAJs+wW22Pte+J-Y8S5DGTes6TTPRWWnwgKDnQDXhCnJT6MaEEA@mail.gmail.com>
	<001801ce351b$6772d0d0$36587270$@gmail.com>
Date: Tue, 9 Apr 2013 07:18:36 -0500
Message-ID: 
 <CAJs+wW3YpGpKEB-bmfcc9iHYy4CMeQxaUi++bDvUaQ9q9t+OrA@mail.gmail.com>
Subject: Re: FalconJX: bugs in external dependencies (Google Closure
 Compiler), what to do?
From: Erik de Bruin <erik@ixsoftware.nl>
To: "dev@flex.apache.org" <dev@flex.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Also, the current FlexJS implementation for both MXML and AS contains
several "giant" methods that simply beg to be broken up into more
manageable sets of support functions which maybe even share some
common code (like the  emission of JSDoc type headers)... That might
also be a good way to get your feet wet without needing to change any
of the APIs.

EdB


On Tue, Apr 9, 2013 at 7:11 AM, Tigran Najaryan <tignaj@gmail.com> wrote:
>> Forking the Google code to our project doesn't seem like the best option.
> Yes, that what concerns me too.
>
>> We may consider donating your solution to the Closure project, which is
>> Open Source...
> That may be a solution in the long term but I am not sure that helps to fix
> the bug in Falcon compiler right now.
>
> Anyway submitting a patch to Closure will require more work on my part.
> Although the bug fix I propose is generic for PathUtil I still did not
> examine all the dependencies from that class in the Closure itself and am
> not sure my patch is generic enough and correct for the Closure itself.
> Honestly I would rather not digress and stay concentrated on contributing to
> Flex.
>
>
>> Keep what you have, please, but don't push it to the 'develop' branch.
>> You're probably the smartest person that will work on it, but we need to
>> take care that we don't end up with a dependency on a fork of the closure
>> tools where we actually want to be able to use their releases.
> I guess that means I will keep my patch for myself only until either
> somebody else needs it or a better way to fix this bug is found.
>
>
>> For FalconJX the main goal is to write tests for both MXML and AS parsing.
> At
>> the moment there are some areas that are written specifically to allow for
>> the correct parsing of the FlexJSTest_again example. This obviously is not
>> "ideal" ;-) We need to make sure that all code is generic (or as much as
>> possible) and that all output is properly tested so we don't kill any
> existing
>> output when refactoring or adding code. Right now, there is only 2 tests
>> specific for FlexJS MXML output, and those are "@Ignore"d.
>>
>>
>> But first, just look around, review what's there and see if what I/we did
>> makes sense.
> OK, I will spend a few more days just getting familiar with the code base
> and see if I can find and fix some other bugs before trying to make
> functional changes to the compiler.
>
> Tigran.
>


-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl