Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <20121216075221.15055u1pxpd8yjnp@franklin.liquidweb.com>
Date: Sun, 16 Dec 2012 07:52:21 -0500
From: Michael Schmalle <apache@teotigraphix.com>
To: flex-dev@incubator.apache.org
Subject: Re: Falcon SDKSWCTests
References: 
 <CAOAmsm58DHwAfZUCuQ-vh9g9qOS95owftvH+Og4PQL8efwxfjQ@mail.gmail.com>
 <CCE7697D.49B0E%aharui@adobe.com>
 <CAOAmsm5PgfCAdOP12_P-nxn+QoYbkOSkAKfFVYBgJd-iFn2ZRQ@mail.gmail.com>
 <CAOAmsm5BXrJdPxTEQxW-YM8fFK=AYjX6fb2UQa7M31kRRJpxnw@mail.gmail.com>
 <CAOAmsm5h5DPXnw6Z4cAkGBmhCLivVzxFcce5AtjHfEAfN3Kcvg@mail.gmail.com>
 <149F8129B58B2D418508E63117D9C5419B5B623E12@nambx05.corp.adobe.com>
 <CAOAmsm6a8pwzy8PPF2UNHbC1hM=7iHpZhQihbOJRTif2_KLJ_Q@mail.gmail.com>
 <CAOAmsm77bV0SsiRn+6e0m9gXAUv_MEU6TchcdEFMZKy2Tai=YA@mail.gmail.com>
 <149F8129B58B2D418508E63117D9C5419B5B6247E6@nambx05.corp.adobe.com>
 <CAOAmsm49-t0eb5550DF-LJ7vUNaRkYLRtF66TKz-qaGaXZ0sVw@mail.gmail.com>
 <CAOAmsm5EpSFdERxmZryEmYCodVA7vXONgL2wiCXK6XB4o1ipTQ@mail.gmail.com>
 <149F8129B58B2D418508E63117D9C5419B5B62483D@nambx05.corp.adobe.com>
 <CAOAmsm7V3Ui56cUuYDGfwtu5yZuph1Ac=1aEYEBKLY3v_P90OA@mail.gmail.com>
 <149F8129B58B2D418508E63117D9C5419B5B624842@nambx05.corp.adobe.com>
 <CAOAmsm7J3QsjVcj1F0scznh1NmvvFgkZNiFcQS86yRPgCpTBpg@mail.gmail.com>
 <CAOAmsm772F0c-jcSyXj6nv=AE9bJ--Y5Ci+GZ2oCwrXjsJDAXw@mail.gmail.com>
In-Reply-To: 
 <CAOAmsm772F0c-jcSyXj6nv=AE9bJ--Y5Ci+GZ2oCwrXjsJDAXw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=ISO-8859-1;
 DelSp="Yes";
 format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.8)


Quoting Chema Balsas <jbalsas@gmail.com>:

> Hi, I've checked the rest of functional tests and created jira issues to
> keep track of them so anyone can check where we stand.
>
> I have fixes for several of them, but want to run mustella tests before
> committing anything. In the meantime, there are several errors that may
> require Gordon's attention.
>
> In advancedgrids, we get a Warning: Metadata was not bound to a definition.
> This comes from something like:
>
> var a:Object = array[cellRow]
>                              [cellColumn];

I looked at one of these and I would say the code is wrong. Dynamic  
member access needs to NOT have a newline. I know the one in the  
datagrid was separated by a newline, this needs to be changed.

This is just another example where the Falcon grammar is a lot  
stricter, which is GOOD.

Are there other metadata warnings that are all on one line?


> Is it possible that something has changed in the lexical analysis? Although
> just a warning, it looks like this could potentially break lots of code...
>
> Some of the projects (mobiletheme, spark and sparkskins) throw lots  
> of "Error:
> Generated byte code contains an operand stack underflow." messages.
>
> In mx, Falcon can't work around embed directives in an mx:Object
> /Users/jbalsas/Documents/dev/apache/flex/sdk/branches/develop/frameworks/projects/mx/src/mx/controls/RichTextEditor.mxml:1053
> Error: Type * cannot be embedded
>                         <mx:Object
> icon="@Embed('assets/icon_align_left.png')" action="left"/>
>
> In spark, Falcon throws a java error
>
> Error: Internal error in ABC generator subsystem, when generating code for:
> /Users/jbalsas/Documents/dev/apache/flex/sdk/branches/develop/frameworks/projects/spark/src/spark/utils/TextFlowUtil.as:
> java.lang.NullPointerException
> at
> org.apache.flex.compiler.internal.as.codegen.ClassDirectiveProcessor.finishClassDefinition(ClassDirectiveProcessor.java:536)
> at
> org.apache.flex.compiler.internal.as.codegen.GlobalDirectiveProcessor.declareClass(GlobalDirectiveProcessor.java:423)
> at
> org.apache.flex.compiler.internal.as.codegen.DirectiveProcessor.processNode(DirectiveProcessor.java:206)
>
>
> Should we log some of this issues to keep track of them as well?


I would say log anything that is stopping SWCs from being created.

Mike


>
> Cheers,
> Chema
>
> 2012/12/15 Chema Balsas <jbalsas@gmail.com>
>
>> As a workaround, try adding "-locale=" to the compiler options for the
>>> tests that compile the SWCs, with a TODO that it should not be necessary.
>>
>>
>> That did fix the issue, at least temporarily. I'll add the TODO and a JIRA
>> issue to track this, and go on fixing the rest of errors.
>>
>> Cheers,
>> Chema
>>
>> 2012/12/15 Gordon Smith <gosmith@adobe.com>
>>
>>> While driving home I realized what's probably causing the resource bundle
>>> problems. SDK SWCs like mx.swc get compiled for "no locale" (-locale=)
>>> because they're not supposed to have any resource bundles inside. The
>>> resource bundles go into other resource bundle SWCs like en_US/mx_rb.swc,
>>> which gets compiled for, say, the en_US locale.
>>>
>>> So the problem may be that Falcon is defaulting to the en_US locale
>>> rather than to no locale. As a workaround, try adding "-locale=" to the
>>> compiler options for the tests that compile the SWCs, with a TODO that it
>>> should not be necessary.
>>>
>>> - Gordon
>>>
>>>
>>> -----Original Message-----
>>> From: Chema Balsas [mailto:jbalsas@gmail.com]
>>> Sent: Friday, December 14, 2012 5:27 PM
>>> To: flex-dev@incubator.apache.org
>>> Subject: Re: Falcon SDKSWCTests
>>>
>>> >
>>> > I'd like to fix these since they shouldn't be hard to fix.
>>>
>>>
>>> Fix them we will, then ;)
>>>
>>> Somehow <compc> is finding either the source code for the bundles on the
>>> > source path, or the compiled code for the bundles on the library path.
>>>
>>>
>>> This may have something to do with "addApplicationParentToSourcePath()"
>>> inside ResourceBundlePath in <compc>... I assume Falcon isn't doing this,
>>> but is it going to? It's easy to modify the compile-config files to get
>>> these, and it does show the dependencies more explicitly. What do  
>>> you think?
>>>
>>> Cheers,
>>> Chema
>>>
>>> 2012/12/15 Gordon Smith <gosmith@adobe.com>
>>>
>>> > I'm not sure what's going on with the resource bundle issue, but I
>>> > don't think it's an example of Falcon being pickier. Somehow <compc>
>>> > is finding either the source code for the bundles on the source path,
>>> > or the compiled code for the bundles on the library path.
>>> >
>>> > > I see several "duplicated variables" warnings ahead. Do we want to
>>> > > fix
>>> > them or ignore them?
>>> >
>>> > I'd like to fix these since they shouldn't be hard to fix. (The
>>> > problem with fixing the previous problem with Version.as is that Alex
>>> > would kill us if we removed all the includes of Version.as.)
>>> >
>>> > - Gordon
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: Chema Balsas [mailto:jbalsas@gmail.com]
>>> > Sent: Friday, December 14, 2012 5:05 PM
>>> > To: flex-dev@incubator.apache.org
>>> > Subject: Re: Falcon SDKSWCTests
>>> >
>>> > Also, I've already fixed some warnings, but I'd like to ask before
>>> > going and fix some more. We've already set to ignore
>>> > DuplicateQNameInSourcePathProblem. Should we stick to ignore warnings,
>>> > or try and fix them to end up with a cleaner/safer sdk code?
>>> >
>>> > For instance, I see several "duplicated variables" warnings ahead. Do
>>> > we want to fix them or ignore them?
>>> >
>>> > Cheers,
>>> > Chema
>>> >
>>> > 2012/12/15 Chema Balsas <jbalsas@gmail.com>
>>> >
>>> > > That's usually a configuration problem. Does the -source-path
>>> > > include
>>> > >> bundles/{locale}, and is -locale set to en_US ?
>>> > >
>>> > >
>>> > > You're right, that is the case. I was setting the locale, but the
>>> > > bundles folder is not in the source-path. How's that compc doesn't
>>> > > complain? Is this another place where Falcon is pickier?
>>> > >
>>> > > Take the mx project. Other than its bundles, it uses some from
>>> > > framework, so we need to add both folders to the source-path in
>>> > > compile-config.xml where none was used before. Is this the expected
>>> > > behavior or am I missing something?
>>> > >
>>> > > Cheers,
>>> > > Chema
>>> > >
>>> > > 2012/12/14 Gordon Smith <gosmith@adobe.com>
>>> > >
>>> > >> That's usually a configuration problem. Does the -source-path
>>> > >> include bundles/{locale}, and is -locale set to en_US ?
>>> > >>
>>> > >> - Gordon
>>> > >>
>>> > >> -----Original Message-----
>>> > >> From: Chema Balsas [mailto:jbalsas@gmail.com]
>>> > >> Sent: Friday, December 14, 2012 1:23 PM
>>> > >> To: flex-dev@incubator.apache.org
>>> > >> Subject: Re: Falcon SDKSWCTests
>>> > >>
>>> > >> Right now there's one recurring error when trying to compile almost
>>> > >> every missing swc.
>>> > >>
>>> > >> Error: Unable to resolve resource bundle 'core'
>>> > >> >
>>> > >> > [ResourceBundle("core")]
>>> > >> >
>>> > >>
>>> > >> This happens for several bundles. I've been trying to figure out
>>> > >> the reason, but this is still beyond my reach. It looks like Falcon
>>> > >> never does resolve these dependencies (but I'm not really sure what
>>> > >> I'm looking at here...). Gordon, do you think this is a
>>> > >> configuration problem and have any idea on how this could be
>>> > >> addressed? Or is maybe something missing in Falcon?
>>> > >>
>>> > >> Also, currently we're only checking the compile targets. Should we
>>> > >> also check the bundle ones?
>>> > >>
>>> > >> Cheers,
>>> > >> Chema
>>> > >>
>>> > >>
>>> > >> 2012/12/11 Chema Balsas <jbalsas@gmail.com>
>>> > >>
>>> > >> > Nice! That fixed other 5 tests for free and made other 2 easy to
>>> fix.
>>> > >> >
>>> > >> > I've committed the changes to the sdk and sdkswctests. We now
>>> > >> > have
>>> > >> > 18 out of 29 tests passing. I'll try to start looking over the
>>> > >> > hard ones over the week.
>>> > >> >
>>> > >> > Cheers,
>>> > >> > Chema
>>> > >> >
>>> > >> >
>>> > >> > 2012/12/10 Gordon Smith <gosmith@adobe.com>
>>> > >> >
>>> > >> >> > I've just commited some changes into rpc, authoringsupport,
>>> > >> >> > framework
>>> > >> >> and mobilecomponents so that they compile properly in falcon.
>>> > >> >> I've enabled those tests and now we have 11 out of 29 working.
>>> > >> >>
>>> > >> >> Nice progress!
>>> > >> >>
>>> > >> >> > Warning: mx.core.Version is defined by multiple files:
>>> > >> >>
>>> > >> >> This is an example where Falcon is pickier but since it's just a
>>> > >> >> warning I don't think we should try to fix it. Let's change the
>>> > >> >> tests to ignore this warning. You should be able to do this by
>>> > >> >> changing the SWC tests to run with the additional command-line
>>> > >> >> argument
>>> > >> -ignore-problems=... .
>>> > >> >>
>>> > >> >> - Gordon
>>> > >> >>
>>> > >> >>
>>> > >> >> -----Original Message-----
>>> > >> >> From: Chema Balsas [mailto:jbalsas@gmail.com]
>>> > >> >> Sent: Monday, December 10, 2012 2:20 PM
>>> > >> >> To: flex-dev@incubator.apache.org
>>> > >> >> Subject: Re: Falcon SDKSWCTests
>>> > >> >>
>>> > >> >> Hi,
>>> > >> >>
>>> > >> >> I've just commited some changes into rpc, authoringsupport,
>>> > >> >> framework and mobilecomponents so that they compile properly in
>>> > >> >> falcon. I've enabled those tests and now we have 11 out of 29
>>> > working.
>>> > >> >>
>>> > >> >> @Gordon One recurrent issue for other projects is
>>> > >> >>
>>> > >> >> Warning: mx.core.Version is defined by multiple files:
>>> > >> >> > /Users/jbalsas/Documents/dev/apache/flex/sdk/branches/develop/
>>> > >> >> > fr ame wor ks/projects/automation_agent/src/mx/core/Version.as
>>> > >> >>
>>> > >> >>
>>> > >> >> Is this something Falcon will take care of, or do we need to
>>> > >> >> figure out anoter way around like in the config files for example?
>>> > >> >>
>>> > >> >> Cheers,
>>> > >> >> Chema
>>> > >> >>
>>> > >> >> 2012/12/7 Chema Balsas <jbalsas@gmail.com>
>>> > >> >>
>>> > >> >> > Following with this, I've checked and in CompcTask, an
>>> > >> >> > include-config
>>> > >> >> > (ifSpec) is added with createElem instead of with
>>> > >> >> > createElemAllowAppend. Is there a reason for this? I've
>>> > >> >> > checked and changing it and adding 'append="true"' in the ant
>>> > >> >> > task to the include-file tag does fix this I don't know if
>>> > >> >> > there's something else
>>> > >> >> to take into account though.
>>> > >> >> >
>>> > >> >> > We won't be using it for now, but do you think we should try
>>> > >> >> > to fix this, or at least document it somewhere?
>>> > >> >> >
>>> > >> >> >
>>> > >> >> > 2012/12/7 Chema Balsas <jbalsas@gmail.com>
>>> > >> >> >
>>> > >> >> >> Yes, I already have it and it's working. I've accessed my
>>> > >> >> >> account through ssh to verify it and I've also checked, and I
>>> > >> >> >> have access to the apache commiters repository, but not ours.
>>> > >> >> >>
>>> > >> >> >>
>>> > >> >> >> 2012/12/7 Alex Harui <aharui@adobe.com>
>>> > >> >> >>
>>> > >> >> >>>
>>> > >> >> >>>
>>> > >> >> >>>
>>> > >> >> >>> On 12/7/12 9:22 AM, "Chema Balsas" <jbalsas@gmail.com> wrote:
>>> > >> >> >>>
>>> > >> >> >>> > Oh, that explains it then... and how unfortunate
>>> > >> >> >>> >
>>> > >> >> >>> > From Gordon's comment, I assumed we were going to stop
>>> > >> >> >>> > including the version.properties file (at least for now).
>>> > >> >> >>> > That was exactly what I was about to commit, but it seems
>>> > >> >> >>> > I still don't have access to the svn repository.
>>> > >> >> >>> >
>>> > >> >> >>> Did you get an email asking about what you want your apache
>>> > >> >> >>> id to
>>> > >> be?
>>> > >> >> >>>
>>> > >> >> >>> --
>>> > >> >> >>> Alex Harui
>>> > >> >> >>> Flex SDK Team
>>> > >> >> >>> Adobe Systems, Inc.
>>> > >> >> >>> http://blogs.adobe.com/aharui
>>> > >> >> >>>
>>> > >> >> >>>
>>> > >> >> >>
>>> > >> >> >
>>> > >> >>
>>> > >> >
>>> > >> >
>>> > >>
>>> > >
>>> > >
>>> >
>>>
>>
>>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com