You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by OmPrakash Muppirala <bi...@gmail.com> on 2013/07/24 20:08:57 UTC
[REQUEST] A tutorial on how to fix bugs for the Flex SDK
I would like to compile a comprehensive tutorial on how to fix, test and
submit patches to the Flex SDK. I feel that some important pieces re
missing for more users to contribute to the SDK. Here are a few things we
may want to concentrate on:
a) Get latest code. Does [1] have the most current information?
b) Set up development environment (With at least FB. IntelliJ would be a
bonus)
c) Walk through an 'easyfix' bug from JIRA and fix it
d) Test the changes. Checkintests, Mustella, Alex's patch server, etc.
e) Generate a patch file and submit
Justin, Mark, Erik, Alex, etc. who have been regularly fixing bugs, can you
please take some of these up and help me compile/edit the tutorial?
Thanks,
Om
[1] http://flex.apache.org/dev-sourcecode.html
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Yep I can help out there.
Justin
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Alex Harui <ah...@adobe.com>.
On 7/25/13 10:50 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>Cool, this is new to me. The source-path route sound like the
>"easiest" to adopt (for anyone, not just noobs like me ;-)). Are there
>any drawbacks?
Compile time will take longer as it is re-compiling each of the source
files in the source-path instead of reading ABC from the pre-compiled SWC.
But for me it isn't that noticeable.
I've hit other occasional compiler issues where it can't resolve some
class constants that are used as optional parameters in method signatures.
I think I've generally gotten around them, but I honestly don't remember
how.
I think there are some changes that can't be made this way. Maybe change
to CSS and properties, or maybe metadata. I honestly don't remember the
details here either. But 99% of the time this is how I code. In fact,
I'm working out that resource module issue this way.
>Also, does this mean that you don't even have to build
>and decorate the SDK, but can work straight off the code you get from
>git?
Yes. At least for me, because I build from the command-line when working
in this configuration. I don't know if FB will cache anything and get in
your way. But because I can skip building SWCs I believe it saves me more
time even if each compile is slower.
I still go back to full builds when I need to use FB for things like
profiling. But because I use FDB to debug because it is usually more
efficient, I generally only use FB for code editing.
>
>EdB
>
>
>
>On Thu, Jul 25, 2013 at 7:11 PM, OmPrakash Muppirala
><bi...@gmail.com> wrote:
>>>
>>> Like maybe just having folks point a source-path to their local working
>>> copies. Source-path is supposed to
>>> take precedence over anything found in the library path. It slows down
>>> compilation, of course, but also means you don't have to build the SWCs
>>> before testing your changes.
>>>
>>>
>> Well, this is exactly what I do today. I isolate the problem to a
>> particular project in the frameworks folder and add that project's src
>>as a
>> source path to my test project. There maybe dependencies and I work
>> through to add all the relevant src directories until the compile
>>errors go
>> away. This makes it much easier for me to work on the SDK code while
>> testing it without having to recompile all the swcs all the time.
>>
>> I wasnt sure what the correct/better way was.
>>
>> Thanks,
>> Om
>>
>>
>>
>>> -Alex
>>>
>>> On 7/25/13 6:16 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>
>>> >There is a gap between how you build the SDK and how you make and test
>>> >changes to the SDK:
>>> >
>>> >(working from memory here) After you build the SDK ('ant main') you
>>> >run the script 'ide/constructFlexForIDE' to prepare the SDK for use in
>>> >Flash Builder. You then create your test application (in which you
>>> >will reproduce the bug) to use this newly build and prepared SDK.
>>> >
>>> >Now a question to all of you: can we make an app (or extend the
>>> >Installer) so the steps to prepare a system for building the SDK are
>>> >performed automatically?
>>> >
>>> >- I think we can download and launch the installers (not sure if we
>>> >can poll for completion, though)
>>> >- we can create an env.properties with all the paths set, bypassing
>>> >the need to set system wide variables in obscure settings panes/files
>>> >- we can create a preset directory structure to hold the source files
>>> >and their dependencies (AIR SDK, playerglobal etc.)
>>> >- we can find and edit mm.cfg and create a FlashPlayerTrust file
>>> >- etc.
>>> >
>>> >Does anyone see any major obstacles that I'm overlooking?
>>> >
>>> >EdB
>>> >
>>> >
>>> >
>>> >On Thu, Jul 25, 2013 at 1:31 PM, Justin Mclean
>>><ju...@classsoftware.com>
>>> >wrote:
>>> >> Hi,
>>> >>
>>> >> I took some notes while fixing this bug.
>>> >> https://issues.apache.org/jira/browse/FLEX-33165
>>> >>
>>> >> Any feedback and questions welcome.
>>> >>
>>> >> Bug information
>>> >> Note that it's marked as "easyfix" and a RTE. Generally these sort
>>>of
>>> >>bugs don't take much to fix. Looking at the report you can see it's
>>>for
>>> >>a mobile project and Adobe Flex 4.6 so the line numbers are not
>>>going to
>>> >>match up to the current development branch. Search for the line of
>>>code
>>> >>where the error occurs, as the code may of change first look for the
>>> >>function name. You can see that the error is now on line 1581.
>>> >>
>>> >> Reproduce the Bug
>>> >> There is no sample code so you need to work out how to reproduce
>>>it, so
>>> >>create a new sample mobile project containing a horizontal spark list
>>> >>and run it. See if it can reproduce the issue using the 4.6 SDK. No
>>> >>luck. (See the JIRA issue for the code used)
>>> >>
>>> >> Try and work out how to generate the RTE. Looking at the snapElement
>>> >>method it looks like the error would only occur when scrollProperty
>>>is
>>> >>null and that could happen if both canScrollHorizontally and
>>> >>canScrollVertically are false. It's possible that this could happen
>>>when
>>> >>size changes removes the scrollbars when screen orientation changes.
>>> >>This is probably why the bug is hard to reproduce as it depends on
>>>the
>>> >>amount of content in the list and the screen size. The easy way to
>>> >>simulate this is to turn off both horizontal scrolling and vertical
>>> >>scrolling and call the mx_internal method. Modify the code to call
>>>the
>>> >>method directly with both scroll bar policy off and smapping set to
>>> >>something other than none. Bingo we have the RTE!
>>> >>
>>> >> protected function init(event:FlexEvent):void
>>> >> {
>>> >> list.scroller.mx_internal::snapElement(10, false);
>>> >> }
>>> >>
>>> >> <s:List id="list" dataProvider="{listdata}" width="100%"
>>> >>height="100%" verticalScrollPolicy="off" horizontalScrollPolicy="off"
>>> >>scrollSnappingMode="center">
>>> >> <s:layout>
>>> >> <s:HorizontalLayout />
>>> >> </s:layout>
>>> >> </s:List>
>>> >>
>>> >>
>>> >> Test in the develop branch
>>> >> Change to using the latest develop branch and see if the issue still
>>> >>exists and yes it does.
>>> >>
>>> >> Fix the bug
>>> >> To fix add a null check and recompile the spark project by changing
>>>to
>>> >>the frameworks/projects/spark directory and run ant to compile, this
>>> >>should only take less than a min to compile.
>>> >>
>>> >> Clean the FB project so it picks up the framework change. Sometime
>>>it
>>> >>will cache the swc and may require swapping to and old SDK and then
>>> >>back again. Double check you are using the SDK you made the change
>>>in.
>>> >>
>>> >> Test the Change
>>> >> Run the program again and/or text code path in the debugger to see
>>>that
>>> >>the issue has been fixed. Play about with the sample application to
>>>make
>>> >>sure nothing else has been broken.
>>> >>
>>> >> Running mustella tests
>>> >> A change to the scroller class could effect a lot of tests but we
>>>can
>>> >>run the basic tests to make sure and assume the CI will pick up any
>>> >>other issues. For a change like this I wouldn't expect any issues or
>>> >>side effects as the RTE would normally occur, but it's best to be
>>>safe.
>>> >>
>>> >> ./mini_run.sh tests/gumbo/components/ScrollBar
>>> >> ./mini_run.sh tests/gumbo/components/Scroller
>>> >>
>>> >> Both sets of test pass as expected.
>>> >>
>>> >> [java] =====================================================
>>> >> [java] Passes: 122
>>> >> [java] Fails: 0
>>> >> [java] =====================================================
>>> >>
>>> >> [java] =====================================================
>>> >> [java] Passes: 74
>>> >> [java] Fails: 0
>>> >> [java] =====================================================
>>> >>
>>> >>
>>> >> Commit the change
>>> >> If you are a committer you can directly commit the change via a git
>>> >>push. If you are not not a committer you would need to generate a
>>>patch
>>> >>file and add it to the JIRA issue. Make sure you generate the patch
>>>from
>>> >>the base SDK directory like so.
>>> >>
>>> >> git diff frameworks/projects/spark/src/spark/components/Scroller.as
>>> >>
>>> >> diff --git
>>>a/frameworks/projects/spark/src/spark/components/Scroller.as
>>> >>b/frameworks/projects/spark/
>>> >> index 9f91412..c48222d 100644
>>> >> --- a/frameworks/projects/spark/src/spark/components/Scroller.as
>>> >> +++ b/frameworks/projects/spark/src/spark/components/Scroller.as
>>> >> @@ -1579,7 +1579,8 @@ public class Scroller extends
>>>SkinnableComponent
>>> >> }
>>> >> else
>>> >> {
>>> >> - viewport[scrollProperty] = snapScrollPosition;
>>> >> + if (scrollProperty)
>>> >> + viewport[scrollProperty] = snapScrollPosition;
>>> >>
>>> >> return null;
>>> >> }
>>> >>
>>> >> Update JIRA
>>> >> Mark the bug as resolved noting down the Apache Flex versions it has
>>> >>been fixed in.
>>> >>
>>> >> Hope that was helpful,
>>> >> Justin
>>> >
>>> >
>>> >
>>> >--
>>> >Ix Multimedia Software
>>> >
>>> >Jan Luykenstraat 27
>>> >3521 VB Utrecht
>>> >
>>> >T. 06-51952295
>>> >I. www.ixsoftware.nl
>>>
>>>
>
>
>
>--
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Cool, this is new to me. The source-path route sound like the
"easiest" to adopt (for anyone, not just noobs like me ;-)). Are there
any drawbacks? Also, does this mean that you don't even have to build
and decorate the SDK, but can work straight off the code you get from
git?
EdB
On Thu, Jul 25, 2013 at 7:11 PM, OmPrakash Muppirala
<bi...@gmail.com> wrote:
>>
>> Like maybe just having folks point a source-path to their local working
>> copies. Source-path is supposed to
>> take precedence over anything found in the library path. It slows down
>> compilation, of course, but also means you don't have to build the SWCs
>> before testing your changes.
>>
>>
> Well, this is exactly what I do today. I isolate the problem to a
> particular project in the frameworks folder and add that project's src as a
> source path to my test project. There maybe dependencies and I work
> through to add all the relevant src directories until the compile errors go
> away. This makes it much easier for me to work on the SDK code while
> testing it without having to recompile all the swcs all the time.
>
> I wasnt sure what the correct/better way was.
>
> Thanks,
> Om
>
>
>
>> -Alex
>>
>> On 7/25/13 6:16 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>> >There is a gap between how you build the SDK and how you make and test
>> >changes to the SDK:
>> >
>> >(working from memory here) After you build the SDK ('ant main') you
>> >run the script 'ide/constructFlexForIDE' to prepare the SDK for use in
>> >Flash Builder. You then create your test application (in which you
>> >will reproduce the bug) to use this newly build and prepared SDK.
>> >
>> >Now a question to all of you: can we make an app (or extend the
>> >Installer) so the steps to prepare a system for building the SDK are
>> >performed automatically?
>> >
>> >- I think we can download and launch the installers (not sure if we
>> >can poll for completion, though)
>> >- we can create an env.properties with all the paths set, bypassing
>> >the need to set system wide variables in obscure settings panes/files
>> >- we can create a preset directory structure to hold the source files
>> >and their dependencies (AIR SDK, playerglobal etc.)
>> >- we can find and edit mm.cfg and create a FlashPlayerTrust file
>> >- etc.
>> >
>> >Does anyone see any major obstacles that I'm overlooking?
>> >
>> >EdB
>> >
>> >
>> >
>> >On Thu, Jul 25, 2013 at 1:31 PM, Justin Mclean <ju...@classsoftware.com>
>> >wrote:
>> >> Hi,
>> >>
>> >> I took some notes while fixing this bug.
>> >> https://issues.apache.org/jira/browse/FLEX-33165
>> >>
>> >> Any feedback and questions welcome.
>> >>
>> >> Bug information
>> >> Note that it's marked as "easyfix" and a RTE. Generally these sort of
>> >>bugs don't take much to fix. Looking at the report you can see it's for
>> >>a mobile project and Adobe Flex 4.6 so the line numbers are not going to
>> >>match up to the current development branch. Search for the line of code
>> >>where the error occurs, as the code may of change first look for the
>> >>function name. You can see that the error is now on line 1581.
>> >>
>> >> Reproduce the Bug
>> >> There is no sample code so you need to work out how to reproduce it, so
>> >>create a new sample mobile project containing a horizontal spark list
>> >>and run it. See if it can reproduce the issue using the 4.6 SDK. No
>> >>luck. (See the JIRA issue for the code used)
>> >>
>> >> Try and work out how to generate the RTE. Looking at the snapElement
>> >>method it looks like the error would only occur when scrollProperty is
>> >>null and that could happen if both canScrollHorizontally and
>> >>canScrollVertically are false. It's possible that this could happen when
>> >>size changes removes the scrollbars when screen orientation changes.
>> >>This is probably why the bug is hard to reproduce as it depends on the
>> >>amount of content in the list and the screen size. The easy way to
>> >>simulate this is to turn off both horizontal scrolling and vertical
>> >>scrolling and call the mx_internal method. Modify the code to call the
>> >>method directly with both scroll bar policy off and smapping set to
>> >>something other than none. Bingo we have the RTE!
>> >>
>> >> protected function init(event:FlexEvent):void
>> >> {
>> >> list.scroller.mx_internal::snapElement(10, false);
>> >> }
>> >>
>> >> <s:List id="list" dataProvider="{listdata}" width="100%"
>> >>height="100%" verticalScrollPolicy="off" horizontalScrollPolicy="off"
>> >>scrollSnappingMode="center">
>> >> <s:layout>
>> >> <s:HorizontalLayout />
>> >> </s:layout>
>> >> </s:List>
>> >>
>> >>
>> >> Test in the develop branch
>> >> Change to using the latest develop branch and see if the issue still
>> >>exists and yes it does.
>> >>
>> >> Fix the bug
>> >> To fix add a null check and recompile the spark project by changing to
>> >>the frameworks/projects/spark directory and run ant to compile, this
>> >>should only take less than a min to compile.
>> >>
>> >> Clean the FB project so it picks up the framework change. Sometime it
>> >>will cache the swc and may require swapping to and old SDK and then
>> >>back again. Double check you are using the SDK you made the change in.
>> >>
>> >> Test the Change
>> >> Run the program again and/or text code path in the debugger to see that
>> >>the issue has been fixed. Play about with the sample application to make
>> >>sure nothing else has been broken.
>> >>
>> >> Running mustella tests
>> >> A change to the scroller class could effect a lot of tests but we can
>> >>run the basic tests to make sure and assume the CI will pick up any
>> >>other issues. For a change like this I wouldn't expect any issues or
>> >>side effects as the RTE would normally occur, but it's best to be safe.
>> >>
>> >> ./mini_run.sh tests/gumbo/components/ScrollBar
>> >> ./mini_run.sh tests/gumbo/components/Scroller
>> >>
>> >> Both sets of test pass as expected.
>> >>
>> >> [java] =====================================================
>> >> [java] Passes: 122
>> >> [java] Fails: 0
>> >> [java] =====================================================
>> >>
>> >> [java] =====================================================
>> >> [java] Passes: 74
>> >> [java] Fails: 0
>> >> [java] =====================================================
>> >>
>> >>
>> >> Commit the change
>> >> If you are a committer you can directly commit the change via a git
>> >>push. If you are not not a committer you would need to generate a patch
>> >>file and add it to the JIRA issue. Make sure you generate the patch from
>> >>the base SDK directory like so.
>> >>
>> >> git diff frameworks/projects/spark/src/spark/components/Scroller.as
>> >>
>> >> diff --git a/frameworks/projects/spark/src/spark/components/Scroller.as
>> >>b/frameworks/projects/spark/
>> >> index 9f91412..c48222d 100644
>> >> --- a/frameworks/projects/spark/src/spark/components/Scroller.as
>> >> +++ b/frameworks/projects/spark/src/spark/components/Scroller.as
>> >> @@ -1579,7 +1579,8 @@ public class Scroller extends SkinnableComponent
>> >> }
>> >> else
>> >> {
>> >> - viewport[scrollProperty] = snapScrollPosition;
>> >> + if (scrollProperty)
>> >> + viewport[scrollProperty] = snapScrollPosition;
>> >>
>> >> return null;
>> >> }
>> >>
>> >> Update JIRA
>> >> Mark the bug as resolved noting down the Apache Flex versions it has
>> >>been fixed in.
>> >>
>> >> Hope that was helpful,
>> >> Justin
>> >
>> >
>> >
>> >--
>> >Ix Multimedia Software
>> >
>> >Jan Luykenstraat 27
>> >3521 VB Utrecht
>> >
>> >T. 06-51952295
>> >I. www.ixsoftware.nl
>>
>>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by OmPrakash Muppirala <bi...@gmail.com>.
>
> Like maybe just having folks point a source-path to their local working
> copies. Source-path is supposed to
> take precedence over anything found in the library path. It slows down
> compilation, of course, but also means you don't have to build the SWCs
> before testing your changes.
>
>
Well, this is exactly what I do today. I isolate the problem to a
particular project in the frameworks folder and add that project's src as a
source path to my test project. There maybe dependencies and I work
through to add all the relevant src directories until the compile errors go
away. This makes it much easier for me to work on the SDK code while
testing it without having to recompile all the swcs all the time.
I wasnt sure what the correct/better way was.
Thanks,
Om
> -Alex
>
> On 7/25/13 6:16 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
> >There is a gap between how you build the SDK and how you make and test
> >changes to the SDK:
> >
> >(working from memory here) After you build the SDK ('ant main') you
> >run the script 'ide/constructFlexForIDE' to prepare the SDK for use in
> >Flash Builder. You then create your test application (in which you
> >will reproduce the bug) to use this newly build and prepared SDK.
> >
> >Now a question to all of you: can we make an app (or extend the
> >Installer) so the steps to prepare a system for building the SDK are
> >performed automatically?
> >
> >- I think we can download and launch the installers (not sure if we
> >can poll for completion, though)
> >- we can create an env.properties with all the paths set, bypassing
> >the need to set system wide variables in obscure settings panes/files
> >- we can create a preset directory structure to hold the source files
> >and their dependencies (AIR SDK, playerglobal etc.)
> >- we can find and edit mm.cfg and create a FlashPlayerTrust file
> >- etc.
> >
> >Does anyone see any major obstacles that I'm overlooking?
> >
> >EdB
> >
> >
> >
> >On Thu, Jul 25, 2013 at 1:31 PM, Justin Mclean <ju...@classsoftware.com>
> >wrote:
> >> Hi,
> >>
> >> I took some notes while fixing this bug.
> >> https://issues.apache.org/jira/browse/FLEX-33165
> >>
> >> Any feedback and questions welcome.
> >>
> >> Bug information
> >> Note that it's marked as "easyfix" and a RTE. Generally these sort of
> >>bugs don't take much to fix. Looking at the report you can see it's for
> >>a mobile project and Adobe Flex 4.6 so the line numbers are not going to
> >>match up to the current development branch. Search for the line of code
> >>where the error occurs, as the code may of change first look for the
> >>function name. You can see that the error is now on line 1581.
> >>
> >> Reproduce the Bug
> >> There is no sample code so you need to work out how to reproduce it, so
> >>create a new sample mobile project containing a horizontal spark list
> >>and run it. See if it can reproduce the issue using the 4.6 SDK. No
> >>luck. (See the JIRA issue for the code used)
> >>
> >> Try and work out how to generate the RTE. Looking at the snapElement
> >>method it looks like the error would only occur when scrollProperty is
> >>null and that could happen if both canScrollHorizontally and
> >>canScrollVertically are false. It's possible that this could happen when
> >>size changes removes the scrollbars when screen orientation changes.
> >>This is probably why the bug is hard to reproduce as it depends on the
> >>amount of content in the list and the screen size. The easy way to
> >>simulate this is to turn off both horizontal scrolling and vertical
> >>scrolling and call the mx_internal method. Modify the code to call the
> >>method directly with both scroll bar policy off and smapping set to
> >>something other than none. Bingo we have the RTE!
> >>
> >> protected function init(event:FlexEvent):void
> >> {
> >> list.scroller.mx_internal::snapElement(10, false);
> >> }
> >>
> >> <s:List id="list" dataProvider="{listdata}" width="100%"
> >>height="100%" verticalScrollPolicy="off" horizontalScrollPolicy="off"
> >>scrollSnappingMode="center">
> >> <s:layout>
> >> <s:HorizontalLayout />
> >> </s:layout>
> >> </s:List>
> >>
> >>
> >> Test in the develop branch
> >> Change to using the latest develop branch and see if the issue still
> >>exists and yes it does.
> >>
> >> Fix the bug
> >> To fix add a null check and recompile the spark project by changing to
> >>the frameworks/projects/spark directory and run ant to compile, this
> >>should only take less than a min to compile.
> >>
> >> Clean the FB project so it picks up the framework change. Sometime it
> >>will cache the swc and may require swapping to and old SDK and then
> >>back again. Double check you are using the SDK you made the change in.
> >>
> >> Test the Change
> >> Run the program again and/or text code path in the debugger to see that
> >>the issue has been fixed. Play about with the sample application to make
> >>sure nothing else has been broken.
> >>
> >> Running mustella tests
> >> A change to the scroller class could effect a lot of tests but we can
> >>run the basic tests to make sure and assume the CI will pick up any
> >>other issues. For a change like this I wouldn't expect any issues or
> >>side effects as the RTE would normally occur, but it's best to be safe.
> >>
> >> ./mini_run.sh tests/gumbo/components/ScrollBar
> >> ./mini_run.sh tests/gumbo/components/Scroller
> >>
> >> Both sets of test pass as expected.
> >>
> >> [java] =====================================================
> >> [java] Passes: 122
> >> [java] Fails: 0
> >> [java] =====================================================
> >>
> >> [java] =====================================================
> >> [java] Passes: 74
> >> [java] Fails: 0
> >> [java] =====================================================
> >>
> >>
> >> Commit the change
> >> If you are a committer you can directly commit the change via a git
> >>push. If you are not not a committer you would need to generate a patch
> >>file and add it to the JIRA issue. Make sure you generate the patch from
> >>the base SDK directory like so.
> >>
> >> git diff frameworks/projects/spark/src/spark/components/Scroller.as
> >>
> >> diff --git a/frameworks/projects/spark/src/spark/components/Scroller.as
> >>b/frameworks/projects/spark/
> >> index 9f91412..c48222d 100644
> >> --- a/frameworks/projects/spark/src/spark/components/Scroller.as
> >> +++ b/frameworks/projects/spark/src/spark/components/Scroller.as
> >> @@ -1579,7 +1579,8 @@ public class Scroller extends SkinnableComponent
> >> }
> >> else
> >> {
> >> - viewport[scrollProperty] = snapScrollPosition;
> >> + if (scrollProperty)
> >> + viewport[scrollProperty] = snapScrollPosition;
> >>
> >> return null;
> >> }
> >>
> >> Update JIRA
> >> Mark the bug as resolved noting down the Apache Flex versions it has
> >>been fixed in.
> >>
> >> Hope that was helpful,
> >> Justin
> >
> >
> >
> >--
> >Ix Multimedia Software
> >
> >Jan Luykenstraat 27
> >3521 VB Utrecht
> >
> >T. 06-51952295
> >I. www.ixsoftware.nl
>
>
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Clever ;-)
The thing is, you need to download the SDK to get the README. I think Om's
idea is to write up an article or steps page on the website or Wiki,
outlining the entire process of working on the SDK, something that doesn't
belong in the README at all.
EdB
On Thursday, July 25, 2013, Tom Chiverton wrote:
> On 25/07/2013 15:06, Erik de Bruin wrote:
>
>> IIRC following the README won't give you an SDK that you can use in
>> Flash Builder. That's why I indicated that a novice contributor might
>> benefit from a pointer to the 'ide/constructForIDE' script, which
>> would get his SDK in shape to be used to fix bugs the way you
>> describe.
>>
>> EdB
>>
> So write up a patch for the README ;)
>
> Tom
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Tom Chiverton <tc...@extravision.com>.
On 25/07/2013 15:06, Erik de Bruin wrote:
> IIRC following the README won't give you an SDK that you can use in
> Flash Builder. That's why I indicated that a novice contributor might
> benefit from a pointer to the 'ide/constructForIDE' script, which
> would get his SDK in shape to be used to fix bugs the way you
> describe.
>
> EdB
So write up a patch for the README ;)
Tom
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Erik de Bruin <er...@ixsoftware.nl>.
IIRC following the README won't give you an SDK that you can use in
Flash Builder. That's why I indicated that a novice contributor might
benefit from a pointer to the 'ide/constructForIDE' script, which
would get his SDK in shape to be used to fix bugs the way you
describe.
EdB
On Thu, Jul 25, 2013 at 3:47 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> There is a gap between how you build the SDK and how you make and test
>> changes to the SDK
> Not really once you have a working SDK set up you can just change it and recompile sub projects as required.
>
>> (working from memory here) After you build the SDK ('ant main') you
>> run the script 'ide/constructFlexForIDE' to prepare the SDK for use in
>> Flash Builder.
> Yep but there are other ways to do the same thing.
>
> The bits you need to set up and compile the initial SDK are basically the same as you need to test it.
> Java
> Ant
> Flash Player Globals
> AIR SDK
>
> Only exception is the Debug Flash Player which is required for the mustella tests.
>
> But this is all in the README and fairly well documented.
>
>> You then create your test application (in which you
>> will reproduce the bug) to use this newly build and prepared SDK.
> I generally have several SDKs, a clean develop branch, official releases (4.9.1, 4.8, 4.6 etc), and dev branch I'm playing about with. I often switch between them to see what works and doesn't work on what versions.
>
>> Now a question to all of you: can we make an app (or extend the
>> Installer) so the steps to prepare a system for building the SDK are
>> performed automatically?
> May be tricky given what it needs to download and set up (see list above).
>
>> - we can create an env.properties with all the paths set
> We could provide better samples which would be a start, but generally I do most things via command line and don't use evn.properties.
>
> Here's my the environment vars I've set up (for OSX), they depend on where you extract the required downloads obviously.
> ANT_HOME=/usr/share/ant
> PLAYERGLOBAL_HOME=/Users/justinmclean/Documents/player/
> AIR_HOME=/Users/justinmclean/Documents/air/mac/AdobeAIRSDK/
> TLF_HOME=/Users/justinmclean/Documents/ApacheFlexTLFGit
> FLASHPLAYER_DEBUGGER=/Users/justinmclean/Documents/Adobe Flash Builder 4.6/Apache Flex/in/player/11.1/mac/Flash Player Debugger.app/Contents/MacOS/Flash Player Debugger
> PIXELBENDER_HOME=/Applications/Utilities/Adobe Utilities-CS5.localized/Pixel Bender Toolkit 2/
>
> TLF_HOME may not needed to be set depending on how TLF is checked out.
>
>> - we can find and edit mm.cfg and create a FlashPlayerTrust file
>> - etc.
> For 99% of general testing, fixes, patches etc that's not required.
>
> Thanks,
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> There is a gap between how you build the SDK and how you make and test
> changes to the SDK
Not really once you have a working SDK set up you can just change it and recompile sub projects as required.
> (working from memory here) After you build the SDK ('ant main') you
> run the script 'ide/constructFlexForIDE' to prepare the SDK for use in
> Flash Builder.
Yep but there are other ways to do the same thing.
The bits you need to set up and compile the initial SDK are basically the same as you need to test it.
Java
Ant
Flash Player Globals
AIR SDK
Only exception is the Debug Flash Player which is required for the mustella tests.
But this is all in the README and fairly well documented.
> You then create your test application (in which you
> will reproduce the bug) to use this newly build and prepared SDK.
I generally have several SDKs, a clean develop branch, official releases (4.9.1, 4.8, 4.6 etc), and dev branch I'm playing about with. I often switch between them to see what works and doesn't work on what versions.
> Now a question to all of you: can we make an app (or extend the
> Installer) so the steps to prepare a system for building the SDK are
> performed automatically?
May be tricky given what it needs to download and set up (see list above).
> - we can create an env.properties with all the paths set
We could provide better samples which would be a start, but generally I do most things via command line and don't use evn.properties.
Here's my the environment vars I've set up (for OSX), they depend on where you extract the required downloads obviously.
ANT_HOME=/usr/share/ant
PLAYERGLOBAL_HOME=/Users/justinmclean/Documents/player/
AIR_HOME=/Users/justinmclean/Documents/air/mac/AdobeAIRSDK/
TLF_HOME=/Users/justinmclean/Documents/ApacheFlexTLFGit
FLASHPLAYER_DEBUGGER=/Users/justinmclean/Documents/Adobe Flash Builder 4.6/Apache Flex/in/player/11.1/mac/Flash Player Debugger.app/Contents/MacOS/Flash Player Debugger
PIXELBENDER_HOME=/Applications/Utilities/Adobe Utilities-CS5.localized/Pixel Bender Toolkit 2/
TLF_HOME may not needed to be set depending on how TLF is checked out.
> - we can find and edit mm.cfg and create a FlashPlayerTrust file
> - etc.
For 99% of general testing, fixes, patches etc that's not required.
Thanks,
Justin
Re: print issues FLEX-23252 and FLEX-13628 was [REQUEST] tutorial....
Posted by Marcus Fritze <ma...@googlemail.com>.
Hi Alex,
thank again for your big help.
Ok, I updated the https://issues.apache.org/jira/browse/FLEX-13628 and attached a possible fix. I have tested this here with my example and it's working without any problems.
In this fix, the calculation is correct when using default ItemRenderer, custom ItemRenderer or even colspan.
Maybe, you or someone else will look over the patch and check if everything is ok. (I hope I created the patch file correct. I used "diff" in terminal on OS X to create this file.
Later, I will test this issue in the PrintDataGrid (not the PrintAdvancedDataGrid) if this issue is also in this component and maybe should be fixed.
Thanks.
Marcus
Am 18.03.2014 um 16:00 schrieb Alex Harui <ah...@adobe.com>:
> Glad things are getting better.
>
> If the default renderer is just a textfield, then it should handle wordWrap and variableRowHeight correctly. It is more complex renderers with children that often need the child tied to the explicitWidth.
>
> I'm not surprised that column spanning has bugs in this kind of scenario. Try overriding that mx_internal method and see if you can come up with a better calculation.
>
> Often, the last row is just one or two pixels too tall. TextFields usually have a couple of blank rows of pixels below the glyphs so while it looks like it will fit, the math says it doesn't.
>
> -Alex
Re: print issues FLEX-23252 and FLEX-13628 was [REQUEST]
tutorial....
Posted by Alex Harui <ah...@adobe.com>.
Glad things are getting better.
If the default renderer is just a textfield, then it should handle wordWrap and variableRowHeight correctly. It is more complex renderers with children that often need the child tied to the explicitWidth.
I'm not surprised that column spanning has bugs in this kind of scenario. Try overriding that mx_internal method and see if you can come up with a better calculation.
Often, the last row is just one or two pixels too tall. TextFields usually have a couple of blank rows of pixels below the glyphs so while it looks like it will fit, the math says it doesn't.
-Alex
From: Marcus Fritze <ma...@googlemail.com>>
Reply-To: "dev@flex.apache.org<ma...@flex.apache.org>" <de...@flex.apache.org>>
Date: Tuesday, March 18, 2014 6:47 AM
To: "dev@flex.apache.org<ma...@flex.apache.org>" <de...@flex.apache.org>>
Subject: Re: print issues FLEX-23252 and FLEX-13628 was [REQUEST] tutorial....
First of all, sorry for my late response. Alex, you are my hero! This solves the issue a "little bit". But to be honest, not completely.
Ok for documentation:
Now, in my MXAdvancedDataGridItemRenderer I use:
override public function set explicitWidth(value:Number):void
{
super.explicitWidth = value;
this.label.width = value;
}
With this function the height of the calculated ItemRenderer for printing is correct. I think we have to update / change code the Default ItemRenderer which are used for PrintDataGrid and PrintAdvancedDataGrid that the height is calculated correct when someone is using only the Default ItemRenderer and wordWrap="true" variableRowHeight="true" for the Print(Advanced)DataGrid. I will test this, when my print works.
But there is still a print issue when I use colspan for some columns. I am currently investigating this issue.
It seems that the every time the width and height of the columns (<mx:columns>) will be calculated in the AdvancedDataGridBaseEx measureHeightOfItemsUptoMaxHeight function, but rendererProviders for colspan are not considered during this calculation. But I think during this calculation we should look if there will be used maybe another ItemRenderer for colspan. So if the Colspan-ItemRenderer is used, the Width and Height is of course not the same as the height and width of the column-ItemRenderer. (I hope every body understand what I mean. ;-) )
It's funny that I found this in the AdvancedDataGridBase.as Line 1600:
/**
* @private
* This grid just returns the column size,
* but could handle column spanning.
*/
mx_internal function getWidthOfItem(item:IListItemRenderer,
col:AdvancedDataGridColumn, visibleColumnIndex:int):Number
{
return col.width;
}
Yea, I think this would definitively very helpful if this could handle column spanning. ;-)
And a small issue when I print, the "pagebreak" of the PrintAdvacedDataGrid is 1 row "too early". When I look at my next page, the first row would perfectly fit on the previous page. Ok, currently this doesn't bother me too much, but this maybe can also be fixed.
Any help appreciated. Thanks
Marcus
Am 14.03.2014 um 20:42 schrieb Alex Harui <ah...@adobe.com>>:
It looks to me that the Label's width is not tied to the explicitWidth of the renderer at measure time, only at layout time.
You can try binding label's width to "{explicitWidth - 14}". If you think the binding is too slow, then override the explicitWidth setter and set the Label's width then.
HTH,
-Alex
Re: print issues FLEX-23252 and FLEX-13628 was [REQUEST] tutorial....
Posted by Marcus Fritze <ma...@googlemail.com>.
First of all, sorry for my late response. Alex, you are my hero! This solves the issue a "little bit". But to be honest, not completely.
Ok for documentation:
Now, in my MXAdvancedDataGridItemRenderer I use:
override public function set explicitWidth(value:Number):void
{
super.explicitWidth = value;
this.label.width = value;
}
With this function the height of the calculated ItemRenderer for printing is correct. I think we have to update / change code the Default ItemRenderer which are used for PrintDataGrid and PrintAdvancedDataGrid that the height is calculated correct when someone is using only the Default ItemRenderer and wordWrap="true" variableRowHeight="true" for the Print(Advanced)DataGrid. I will test this, when my print works.
But there is still a print issue when I use colspan for some columns. I am currently investigating this issue.
It seems that the every time the width and height of the columns (<mx:columns>) will be calculated in the AdvancedDataGridBaseEx measureHeightOfItemsUptoMaxHeight function, but rendererProviders for colspan are not considered during this calculation. But I think during this calculation we should look if there will be used maybe another ItemRenderer for colspan. So if the Colspan-ItemRenderer is used, the Width and Height is of course not the same as the height and width of the column-ItemRenderer. (I hope every body understand what I mean. ;-) )
It's funny that I found this in the AdvancedDataGridBase.as Line 1600:
/**
* @private
* This grid just returns the column size,
* but could handle column spanning.
*/
mx_internal function getWidthOfItem(item:IListItemRenderer,
col:AdvancedDataGridColumn, visibleColumnIndex:int):Number
{
return col.width;
}
Yea, I think this would definitively very helpful if this could handle column spanning. ;-)
And a small issue when I print, the "pagebreak" of the PrintAdvacedDataGrid is 1 row "too early". When I look at my next page, the first row would perfectly fit on the previous page. Ok, currently this doesn't bother me too much, but this maybe can also be fixed.
Any help appreciated. Thanks
Marcus
Am 14.03.2014 um 20:42 schrieb Alex Harui <ah...@adobe.com>:
> It looks to me that the Label's width is not tied to the explicitWidth of the renderer at measure time, only at layout time.
>
> You can try binding label's width to "{explicitWidth - 14}". If you think the binding is too slow, then override the explicitWidth setter and set the Label's width then.
>
> HTH,
> -Alex
Re: print issues FLEX-23252 and FLEX-13628 was [REQUEST]
tutorial....
Posted by Alex Harui <ah...@adobe.com>.
It looks to me that the Label's width is not tied to the explicitWidth of the renderer at measure time, only at layout time.
You can try binding label's width to "{explicitWidth - 14}". If you think the binding is too slow, then override the explicitWidth setter and set the Label's width then.
HTH,
-Alex
From: Marcus Fritze <ma...@googlemail.com>>
Reply-To: "dev@flex.apache.org<ma...@flex.apache.org>" <de...@flex.apache.org>>
Date: Friday, March 14, 2014 12:31 PM
To: "dev@flex.apache.org<ma...@flex.apache.org>" <de...@flex.apache.org>>
Subject: Re: print issues FLEX-23252 and FLEX-13628 was [REQUEST] tutorial....
This is my ItemRenderer code:
<?xml version="1.0" encoding="utf-8"?>
<s:MXAdvancedDataGridItemRenderer xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx"
focusEnabled="false">
<fx:Script>
<![CDATA[
import mx.controls.advancedDataGridClasses.AdvancedDataGridListData;
import scripts.utils.Utils;
override public function set data(value:Object):void
{
super.data = value;
if(value != null)
{
var _listData:AdvancedDataGridListData = listData as AdvancedDataGridListData;
if(value.ist_aktuell == "ja")
this.lblData.setStyle("fontWeight", "bold");
else
this.lblData.setStyle("fontWeight", "normal");
switch(_listData.dataField)
{
case "fileNumber":
lblData.text = ""; //addedFilesToList.toString();
addedFilesToList++;
break;
case "referenz_name":
lblData.text = value[_listData.dataField];
break;
case "dokument_name":
lblData.text = value[_listData.dataField];
break;
case "file_index":
lblData.text = value[_listData.dataField];
break;
case "status":
lblData.text = value.status_code + " [" + value.version + "]";
break;
case "datum":
lblData.text = Utils.timestamp_to_time(value.ersteller_zeit_utc, "DD.MM.YY", false);
break;
}
}
}
]]>
</fx:Script>
<s:Label id="lblData" top="0" left="0" right="0" bottom="0" paddingTop="5" paddingLeft="7" paddingRight="7" paddingBottom="5" backgroundColor="0xFF0000"/>
</s:MXAdvancedDataGridItemRenderer>
Am 14.03.2014 um 20:06 schrieb Alex Harui <ah...@adobe.com>>:
What does your renderer code look like? If the height of the Label cannot be completely determined from the explicitWidth of the renderer, then measuredHeight will not compute correctly.
Re: print issues FLEX-23252 and FLEX-13628 was [REQUEST] tutorial....
Posted by Marcus Fritze <ma...@googlemail.com>.
This is my ItemRenderer code:
<?xml version="1.0" encoding="utf-8"?>
<s:MXAdvancedDataGridItemRenderer xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx"
focusEnabled="false">
<fx:Script>
<![CDATA[
import mx.controls.advancedDataGridClasses.AdvancedDataGridListData;
import scripts.utils.Utils;
override public function set data(value:Object):void
{
super.data = value;
if(value != null)
{
var _listData:AdvancedDataGridListData = listData as AdvancedDataGridListData;
if(value.ist_aktuell == "ja")
this.lblData.setStyle("fontWeight", "bold");
else
this.lblData.setStyle("fontWeight", "normal");
switch(_listData.dataField)
{
case "fileNumber":
lblData.text = ""; //addedFilesToList.toString();
addedFilesToList++;
break;
case "referenz_name":
lblData.text = value[_listData.dataField];
break;
case "dokument_name":
lblData.text = value[_listData.dataField];
break;
case "file_index":
lblData.text = value[_listData.dataField];
break;
case "status":
lblData.text = value.status_code + " [" + value.version + "]";
break;
case "datum":
lblData.text = Utils.timestamp_to_time(value.ersteller_zeit_utc, "DD.MM.YY", false);
break;
}
}
}
]]>
</fx:Script>
<s:Label id="lblData" top="0" left="0" right="0" bottom="0" paddingTop="5" paddingLeft="7" paddingRight="7" paddingBottom="5" backgroundColor="0xFF0000"/>
</s:MXAdvancedDataGridItemRenderer>
Am 14.03.2014 um 20:06 schrieb Alex Harui <ah...@adobe.com>:
> What does your renderer code look like? If the height of the Label cannot be completely determined from the explicitWidth of the renderer, then measuredHeight will not compute correctly.
>
Re: print issues FLEX-23252 and FLEX-13628 was [REQUEST]
tutorial....
Posted by Alex Harui <ah...@adobe.com>.
What does your renderer code look like? If the height of the Label cannot be completely determined from the explicitWidth of the renderer, then measuredHeight will not compute correctly.
-Alex
From: Marcus Fritze <ma...@googlemail.com>>
Reply-To: "dev@flex.apache.org<ma...@flex.apache.org>" <de...@flex.apache.org>>
Date: Friday, March 14, 2014 10:06 AM
To: "dev@flex.apache.org<ma...@flex.apache.org>" <de...@flex.apache.org>>
Subject: print issues FLEX-23252 and FLEX-13628 was [REQUEST] tutorial....
Thanks for your question.
I attached a image to https://issues.apache.org/jira/browse/FLEX-13628
In the AdvancedDataGridBaseEx.as Line 3056 the item.getExplicitOrMeasuredHeight() is every time 20.
So when you look at my example image, the Label in the ItemRenderer has 2 lines. But the calculated 20 is only correct, when the Label has 1 line.
I really have no idea and of course not that experience in the "Flex internal functions", but I think the setupRendererFromData function in the AdvancedDataGridBaseEx.as doesn't "create" a correct ItemRenderer with the correct sizes. Especially when ItemRenderer has a Label with variable multiline data.
In this setupRendererFromData function we set the explicitWidth for the ItemRenderer, but it seems that the text-calculating of the Label (in the function createTextLinesFromTextBlock Label.as 904) inside this ItemRenderer uses still the maxWidth = 10000 as innerWidth when calculating the height.
I am also wondering that a lot of explicitHeight and measuredHeight values are NaN in and after running the setupRendererFromData function. So maybe the ItemRenderer is not setup correctly? Really, I have no clue.
Am 14.03.2014 um 17:25 schrieb Alex Harui <ah...@adobe.com>>:
What is wrong with the label height calculation?
On 3/14/14 9:17 AM, "Marcus Fritze" <ma...@googlemail.com>> wrote:
Am 13.03.2014 um 20:40 schrieb Alex Harui <ah...@adobe.com>>:
And if you are using an IDE like IntelliJ or FB, then the easiest path
is
to use monkey-patching. Create a test project, point the source-path to
include the modified AdvancedDataGridBaseEx.as and see if it works.
Thanks, this is working very good.
But, the problem with the AdvancedDataGridBaseEx.as seem to be a bigger
problem.
It seem that the height of the text in Label inside a ItemRenderer is not
calculated correct.
print issues FLEX-23252 and FLEX-13628 was [REQUEST] tutorial....
Posted by Marcus Fritze <ma...@googlemail.com>.
Thanks for your question.
I attached a image to https://issues.apache.org/jira/browse/FLEX-13628
In the AdvancedDataGridBaseEx.as Line 3056 the item.getExplicitOrMeasuredHeight() is every time 20.
So when you look at my example image, the Label in the ItemRenderer has 2 lines. But the calculated 20 is only correct, when the Label has 1 line.
I really have no idea and of course not that experience in the "Flex internal functions", but I think the setupRendererFromData function in the AdvancedDataGridBaseEx.as doesn't "create" a correct ItemRenderer with the correct sizes. Especially when ItemRenderer has a Label with variable multiline data.
In this setupRendererFromData function we set the explicitWidth for the ItemRenderer, but it seems that the text-calculating of the Label (in the function createTextLinesFromTextBlock Label.as 904) inside this ItemRenderer uses still the maxWidth = 10000 as innerWidth when calculating the height.
I am also wondering that a lot of explicitHeight and measuredHeight values are NaN in and after running the setupRendererFromData function. So maybe the ItemRenderer is not setup correctly? Really, I have no clue.
Am 14.03.2014 um 17:25 schrieb Alex Harui <ah...@adobe.com>:
> What is wrong with the label height calculation?
>
> On 3/14/14 9:17 AM, "Marcus Fritze" <ma...@googlemail.com> wrote:
>
>>
>> Am 13.03.2014 um 20:40 schrieb Alex Harui <ah...@adobe.com>:
>>>
>>> And if you are using an IDE like IntelliJ or FB, then the easiest path
>>> is
>>> to use monkey-patching. Create a test project, point the source-path to
>>> include the modified AdvancedDataGridBaseEx.as and see if it works.
>>
>> Thanks, this is working very good.
>>
>> But, the problem with the AdvancedDataGridBaseEx.as seem to be a bigger
>> problem.
>> It seem that the height of the text in Label inside a ItemRenderer is not
>> calculated correct.
>
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Alex Harui <ah...@adobe.com>.
What is wrong with the label height calculation?
On 3/14/14 9:17 AM, "Marcus Fritze" <ma...@googlemail.com> wrote:
>
>Am 13.03.2014 um 20:40 schrieb Alex Harui <ah...@adobe.com>:
>>
>> And if you are using an IDE like IntelliJ or FB, then the easiest path
>>is
>> to use monkey-patching. Create a test project, point the source-path to
>> include the modified AdvancedDataGridBaseEx.as and see if it works.
>
>Thanks, this is working very good.
>
>But, the problem with the AdvancedDataGridBaseEx.as seem to be a bigger
>problem.
>It seem that the height of the text in Label inside a ItemRenderer is not
>calculated correct.
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Marcus Fritze <ma...@googlemail.com>.
Am 13.03.2014 um 20:40 schrieb Alex Harui <ah...@adobe.com>:
>
> And if you are using an IDE like IntelliJ or FB, then the easiest path is
> to use monkey-patching. Create a test project, point the source-path to
> include the modified AdvancedDataGridBaseEx.as and see if it works.
Thanks, this is working very good.
But, the problem with the AdvancedDataGridBaseEx.as seem to be a bigger problem.
It seem that the height of the text in Label inside a ItemRenderer is not calculated correct.
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Alex Harui <ah...@adobe.com>.
Well, most of the committers are working from a git repo. You can work
from a binary distribution, because you can then use IntelliJ or FB to
write your code, but it is easier just to use the InstallApacheFlex
installer to set up your binary distribution (unless you're on Linux, in
which cas you would use Ant).
And if you are using an IDE like IntelliJ or FB, then the easiest path is
to use monkey-patching. Create a test project, point the source-path to
include the modified AdvancedDataGridBaseEx.as and see if it works.
-Alex
From: Marcus Fritze <ma...@googlemail.com>
Reply-To: "dev@flex.apache.org" <de...@flex.apache.org>
Date: Thursday, March 13, 2014 12:33 PM
To: "dev@flex.apache.org" <de...@flex.apache.org>
Subject: Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Am 13.03.2014 um 18:32 schrieb Alex Harui <ah...@adobe.com>:
So, what is the easies way for working on the SDK? I want to fix a bug.
Well, I'm tempted to have you follow this:
https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide
because this sets up your environment like most of the other committers.
Yes, thats clear. So I found in the README "Building the Framework in a
Binary Distribution".
So this is the best way, right?
I only want to change / test something in AdvancedDataGridBaseEx.as and
would like to see if it fixes
https://issues.apache.org/jira/browse/FLEX-23252
https://issues.apache.org/jira/browse/FLEX-13628
Thanks.
Marcus
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Marcus Fritze <ma...@googlemail.com>.
Am 13.03.2014 um 18:32 schrieb Alex Harui <ah...@adobe.com>:
>> So, what is the easies way for working on the SDK? I want to fix a bug.
> Well, I'm tempted to have you follow this:
> https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide
> because this sets up your environment like most of the other committers.
Yes, thats clear. So I found in the README "Building the Framework in a Binary Distribution".
So this is the best way, right?
I only want to change / test something in AdvancedDataGridBaseEx.as and would like to see if it fixes
https://issues.apache.org/jira/browse/FLEX-23252
https://issues.apache.org/jira/browse/FLEX-13628
Thanks.
Marcus
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Alex Harui <ah...@adobe.com>.
On 3/13/14 9:45 AM, "Marcus Fritze" <ma...@googlemail.com> wrote:
>https://cwiki.apache.org/confluence/display/FLEX/2.1+Flash+Builder
>
>Correct me when I am wrong, but it seems that is not a complete tutorial
>how to setup the SDK for compiling the SDK.
That's about how to use Apache Flex in Flash Builder.
>
>So, what is the easies way for working on the SDK? I want to fix a bug.
Well, I'm tempted to have you follow this:
https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide
because this sets up your environment like most of the other committers.
However, you can always create a monkey-patch and then generate a Git
patch from the differences.
-Alex
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Marcus Fritze <ma...@googlemail.com>.
Hi,
I am bringing up this issue, because I want to fix a bug in the SDK. So I have to compile the SDK for my self.
What is currently the easiest way for doing this? I looked at the wiki in the "Helping Out" section:
https://cwiki.apache.org/confluence/display/FLEX/2.1+Flash+Builder
Correct me when I am wrong, but it seems that is not a complete tutorial how to setup the SDK for compiling the SDK.
So, what is the easies way for working on the SDK? I want to fix a bug.
Thanks.
Marcus
Am 02.08.2013 um 13:19 schrieb Kessler CTR Mark J <ma...@usmc.mil>:
> I've tossed in the rough structure [1]. I'm going to move any related pages under the structure for now. This should allow different people to start adding content when they get time to.
>
> On a side note, I think we may need to clean up the existing pages. It's sort of random what's in there now. I may do a bit of that later.
>
>
> [1] https://cwiki.apache.org/confluence/display/FLEX/Helping+Out
>
> -Mark
>
> -----Original Message-----
> From: omuppi1@gmail.com [mailto:omuppi1@gmail.com] On Behalf Of OmPrakash Muppirala
> Sent: Friday, August 02, 2013 2:18 AM
> To: dev@flex.apache.org
> Subject: Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
>
> Thanks for all the ideas and tutorial content so far. I think the
> structure that Mark suggested looks great.
>
> Can someone please volunteer to compile this info into a wiki page from
> which we can start filling in content slowly? Please let us know, we can
> get you access to our wiki site here [1]
>
> Thanks,
> Om
>
> [1] https://cwiki.apache.org/confluence/display/FLEX/Apache+Flex+Wiki
>
RE: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
I've tossed in the rough structure [1]. I'm going to move any related pages under the structure for now. This should allow different people to start adding content when they get time to.
On a side note, I think we may need to clean up the existing pages. It's sort of random what's in there now. I may do a bit of that later.
[1] https://cwiki.apache.org/confluence/display/FLEX/Helping+Out
-Mark
-----Original Message-----
From: omuppi1@gmail.com [mailto:omuppi1@gmail.com] On Behalf Of OmPrakash Muppirala
Sent: Friday, August 02, 2013 2:18 AM
To: dev@flex.apache.org
Subject: Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Thanks for all the ideas and tutorial content so far. I think the
structure that Mark suggested looks great.
Can someone please volunteer to compile this info into a wiki page from
which we can start filling in content slowly? Please let us know, we can
get you access to our wiki site here [1]
Thanks,
Om
[1] https://cwiki.apache.org/confluence/display/FLEX/Apache+Flex+Wiki
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by OmPrakash Muppirala <bi...@gmail.com>.
Thanks for all the ideas and tutorial content so far. I think the
structure that Mark suggested looks great.
Can someone please volunteer to compile this info into a wiki page from
which we can start filling in content slowly? Please let us know, we can
get you access to our wiki site here [1]
Thanks,
Om
[1] https://cwiki.apache.org/confluence/display/FLEX/Apache+Flex+Wiki
On Mon, Jul 29, 2013 at 9:29 AM, Marcus Fritze <marcus.fritze@googlemail.com
> wrote:
> I think a written tutorial with good screenshots is a must. It's also
> easier to update the text over the years if something changes.
>
> But the video is definitely a plus and a good guide.
>
> The video should be something like this:
>
> Compiling and Contributing to Apache Flex with IntelliJ by Nicholas
> Kwiatkowski
>
> http://www.youtube.com/watch?v=5COE3hYqCJk
>
> This is for IntelliJ 11.1, but not working with the latest IntelliJ
> version (and maybe because of the change of the source code location
> git/svn).
>
> I think there are a lot of developers out there who want to help, but
> don't know how.
> Like me, I have created some issues in the JIRA, but I have no idea how to
> compile / patch the SDK.
>
> I would really like to help and fix bugs in the SDK, but I don't know how.
> I am waiting for the tutorial.
>
> This would be very good for the project, if everybody knows how to compile
> / patch the SDK. So everybody can fix the bugs you have found yourself.
> Maybe more people, who are just Flex developers / user, contribute to this
> project.
>
> Thanks!
>
> Marcus Fritze
>
> Am 29.07.2013 um 11:18 schrieb "Sugan Naicker" <Su...@Dev-X.co.za>:
>
> > Great idea Jude! Simple and effective.
> >
> > Rgs,
> >
> > Sugan
> >
> > -----Original Message-----
> > From: jude [mailto:flexcapacitor@gmail.com]
> > Sent: 29 July 2013 05:41 AM
> > To: dev@flex.apache.org
> > Subject: Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
> >
> > I have a suggestion on this tutorial writing thing. If anyone of you that
> > have this environment setup can record and upload a raw unedited video I
> can
> > edit it or rerecord it and republish it. What I'm thinking is that you
> could
> > log out and then log back in as guest, then go through recording the
> entire
> > process of setting up the environment and testing as a fresh new user.
> >
> > I use Camtasia on Mac to do screen recordings like this but there are
> many
> > others out there. It may be turn out to be a really long video; that's
> > alright. The reason is that it may be easier to show people how to set
> it up
> > than work on typing everything up. A video demonstration doesn't require
> any
> > writing per se. We can also capture small details that sometimes get left
> > out of tutorials and then make sure these details get into the tutorials.
> > This does *not* have to be edited at all.
> >
> >
> > On Fri, Jul 26, 2013 at 2:53 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> Hmm. The source path is really
> >> "/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spa
> >> rk/sr c" (with "/src")? And you aren't using RSLs?
> >> What does a link report say for which Label.as it used?
> >>
> >> On 7/26/13 11:57 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >>
> >>> It was :-(
> >>>
> >>> EdB
> >>>
> >>>
> >>>
> >>> On Fri, Jul 26, 2013 at 4:10 PM, Alex Harui <ah...@adobe.com> wrote:
> >>>>
> >>>>
> >>>> On 7/26/13 2:41 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >>>>
> >>>>> Ok, this is what I tried:
> >>>>>
> >>>>> I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
> >>>>> folder. In "project properties/Flex Build Path" on the "Source path"
> >>>>> tab I added the folder
> >>>>> "/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/
> >>>>> spark
> >>>>> ",
> >>>>> thinking this will allow me to work on the classic Spark components.
> >>>>>
> >>>>> In my project, I add a Label in MXML. I cmd click on 'Label' to get
> >>>>> me into the Label source.
> >>>> Check which Label.as it opened up. It may not be the one from git.
> >>>>
> >>>>> I place a trace statement in the constructor. I save, clean the
> >>>>> project (just to be sure) and launch the project in debug mode...
> >>>>> No trace statement shows up :-( When I try to put a breakpoint in
> >>>>> the source, it complains there is no code on that line.
> >>>>>
> >>>>> What am I doing wrong?
> >>>>>
> >>>>> EdB
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Fri, Jul 26, 2013 at 1:38 AM, Alex Harui <ah...@adobe.com>
> wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 7/25/13 3:37 PM, "Justin Mclean" <ju...@classsoftware.com>
> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>>> but also means you don't have to build the SWCs before testing
> >>>>>>>> your changes.
> >>>>>>>
> >>>>>>> Perhaps I missing the point but if you make a change you will
> >>>>>>> have to recompile that project, you just don't have to recompile
> >>>>>>> the entire SDK.
> >>>>>> You are correct, but in my workflow, I don't even have to stop to
> >>>>>> compile a single project.
> >>>>>>
> >>>>>> For this resource module RTE I just worked on, I changed the
> >>>>>> files, compiled the test case without running any ant scripts,
> >>>>>> and repeated until it all worked. Then I go run a full build and
> >>>>>> start up mustella.
> >>>>>>
> >>>>>> -Alex
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Ix Multimedia Software
> >>>>>
> >>>>> Jan Luykenstraat 27
> >>>>> 3521 VB Utrecht
> >>>>>
> >>>>> T. 06-51952295
> >>>>> I. www.ixsoftware.nl
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Ix Multimedia Software
> >>>
> >>> Jan Luykenstraat 27
> >>> 3521 VB Utrecht
> >>>
> >>> T. 06-51952295
> >>> I. www.ixsoftware.nl
> >>
> >>
> >
>
>
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Marcus Fritze <ma...@googlemail.com>.
I think a written tutorial with good screenshots is a must. It's also easier to update the text over the years if something changes.
But the video is definitely a plus and a good guide.
The video should be something like this:
Compiling and Contributing to Apache Flex with IntelliJ by Nicholas Kwiatkowski
http://www.youtube.com/watch?v=5COE3hYqCJk
This is for IntelliJ 11.1, but not working with the latest IntelliJ version (and maybe because of the change of the source code location git/svn).
I think there are a lot of developers out there who want to help, but don't know how.
Like me, I have created some issues in the JIRA, but I have no idea how to compile / patch the SDK.
I would really like to help and fix bugs in the SDK, but I don't know how. I am waiting for the tutorial.
This would be very good for the project, if everybody knows how to compile / patch the SDK. So everybody can fix the bugs you have found yourself.
Maybe more people, who are just Flex developers / user, contribute to this project.
Thanks!
Marcus Fritze
Am 29.07.2013 um 11:18 schrieb "Sugan Naicker" <Su...@Dev-X.co.za>:
> Great idea Jude! Simple and effective.
>
> Rgs,
>
> Sugan
>
> -----Original Message-----
> From: jude [mailto:flexcapacitor@gmail.com]
> Sent: 29 July 2013 05:41 AM
> To: dev@flex.apache.org
> Subject: Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
>
> I have a suggestion on this tutorial writing thing. If anyone of you that
> have this environment setup can record and upload a raw unedited video I can
> edit it or rerecord it and republish it. What I'm thinking is that you could
> log out and then log back in as guest, then go through recording the entire
> process of setting up the environment and testing as a fresh new user.
>
> I use Camtasia on Mac to do screen recordings like this but there are many
> others out there. It may be turn out to be a really long video; that's
> alright. The reason is that it may be easier to show people how to set it up
> than work on typing everything up. A video demonstration doesn't require any
> writing per se. We can also capture small details that sometimes get left
> out of tutorials and then make sure these details get into the tutorials.
> This does *not* have to be edited at all.
>
>
> On Fri, Jul 26, 2013 at 2:53 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> Hmm. The source path is really
>> "/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spa
>> rk/sr c" (with "/src")? And you aren't using RSLs?
>> What does a link report say for which Label.as it used?
>>
>> On 7/26/13 11:57 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>>> It was :-(
>>>
>>> EdB
>>>
>>>
>>>
>>> On Fri, Jul 26, 2013 at 4:10 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>>>
>>>> On 7/26/13 2:41 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>>>
>>>>> Ok, this is what I tried:
>>>>>
>>>>> I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
>>>>> folder. In "project properties/Flex Build Path" on the "Source path"
>>>>> tab I added the folder
>>>>> "/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/
>>>>> spark
>>>>> ",
>>>>> thinking this will allow me to work on the classic Spark components.
>>>>>
>>>>> In my project, I add a Label in MXML. I cmd click on 'Label' to get
>>>>> me into the Label source.
>>>> Check which Label.as it opened up. It may not be the one from git.
>>>>
>>>>> I place a trace statement in the constructor. I save, clean the
>>>>> project (just to be sure) and launch the project in debug mode...
>>>>> No trace statement shows up :-( When I try to put a breakpoint in
>>>>> the source, it complains there is no code on that line.
>>>>>
>>>>> What am I doing wrong?
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 26, 2013 at 1:38 AM, Alex Harui <ah...@adobe.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 7/25/13 3:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>> but also means you don't have to build the SWCs before testing
>>>>>>>> your changes.
>>>>>>>
>>>>>>> Perhaps I missing the point but if you make a change you will
>>>>>>> have to recompile that project, you just don't have to recompile
>>>>>>> the entire SDK.
>>>>>> You are correct, but in my workflow, I don't even have to stop to
>>>>>> compile a single project.
>>>>>>
>>>>>> For this resource module RTE I just worked on, I changed the
>>>>>> files, compiled the test case without running any ant scripts,
>>>>>> and repeated until it all worked. Then I go run a full build and
>>>>>> start up mustella.
>>>>>>
>>>>>> -Alex
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ix Multimedia Software
>>>>>
>>>>> Jan Luykenstraat 27
>>>>> 3521 VB Utrecht
>>>>>
>>>>> T. 06-51952295
>>>>> I. www.ixsoftware.nl
>>>>
>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>
>>
>
RE: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Sugan Naicker <Su...@Dev-X.co.za>.
Great idea Jude! Simple and effective.
Rgs,
Sugan
-----Original Message-----
From: jude [mailto:flexcapacitor@gmail.com]
Sent: 29 July 2013 05:41 AM
To: dev@flex.apache.org
Subject: Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
I have a suggestion on this tutorial writing thing. If anyone of you that
have this environment setup can record and upload a raw unedited video I can
edit it or rerecord it and republish it. What I'm thinking is that you could
log out and then log back in as guest, then go through recording the entire
process of setting up the environment and testing as a fresh new user.
I use Camtasia on Mac to do screen recordings like this but there are many
others out there. It may be turn out to be a really long video; that's
alright. The reason is that it may be easier to show people how to set it up
than work on typing everything up. A video demonstration doesn't require any
writing per se. We can also capture small details that sometimes get left
out of tutorials and then make sure these details get into the tutorials.
This does *not* have to be edited at all.
On Fri, Jul 26, 2013 at 2:53 PM, Alex Harui <ah...@adobe.com> wrote:
> Hmm. The source path is really
> "/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spa
> rk/sr c" (with "/src")? And you aren't using RSLs?
> What does a link report say for which Label.as it used?
>
> On 7/26/13 11:57 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
> >It was :-(
> >
> >EdB
> >
> >
> >
> >On Fri, Jul 26, 2013 at 4:10 PM, Alex Harui <ah...@adobe.com> wrote:
> >>
> >>
> >> On 7/26/13 2:41 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >>
> >>>Ok, this is what I tried:
> >>>
> >>>I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
> >>>folder. In "project properties/Flex Build Path" on the "Source path"
> >>>tab I added the folder
> >>>"/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/
> >>>spark
> >>>",
> >>>thinking this will allow me to work on the classic Spark components.
> >>>
> >>>In my project, I add a Label in MXML. I cmd click on 'Label' to get
> >>>me into the Label source.
> >> Check which Label.as it opened up. It may not be the one from git.
> >>
> >>>I place a trace statement in the constructor. I save, clean the
> >>>project (just to be sure) and launch the project in debug mode...
> >>>No trace statement shows up :-( When I try to put a breakpoint in
> >>>the source, it complains there is no code on that line.
> >>>
> >>>What am I doing wrong?
> >>>
> >>>EdB
> >>>
> >>>
> >>>
> >>>On Fri, Jul 26, 2013 at 1:38 AM, Alex Harui <ah...@adobe.com> wrote:
> >>>>
> >>>>
> >>>> On 7/25/13 3:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> >>>>
> >>>>>Hi,
> >>>>>
> >>>>>> but also means you don't have to build the SWCs before testing
> >>>>>>your changes.
> >>>>>
> >>>>>Perhaps I missing the point but if you make a change you will
> >>>>>have to recompile that project, you just don't have to recompile
> >>>>>the entire SDK.
> >>>> You are correct, but in my workflow, I don't even have to stop to
> >>>>compile a single project.
> >>>>
> >>>> For this resource module RTE I just worked on, I changed the
> >>>>files, compiled the test case without running any ant scripts,
> >>>>and repeated until it all worked. Then I go run a full build and
> >>>>start up mustella.
> >>>>
> >>>> -Alex
> >>>>
> >>>
> >>>
> >>>
> >>>--
> >>>Ix Multimedia Software
> >>>
> >>>Jan Luykenstraat 27
> >>>3521 VB Utrecht
> >>>
> >>>T. 06-51952295
> >>>I. www.ixsoftware.nl
> >>
> >
> >
> >
> >--
> >Ix Multimedia Software
> >
> >Jan Luykenstraat 27
> >3521 VB Utrecht
> >
> >T. 06-51952295
> >I. www.ixsoftware.nl
>
>
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by jude <fl...@gmail.com>.
I have a suggestion on this tutorial writing thing. If anyone of you that
have this environment setup can record and upload a raw unedited video I
can edit it or rerecord it and republish it. What I'm thinking is that you
could log out and then log back in as guest, then go through recording the
entire process of setting up the environment and testing as a fresh new
user.
I use Camtasia on Mac to do screen recordings like this but there are many
others out there. It may be turn out to be a really long video; that's
alright. The reason is that it may be easier to show people how to set it
up than work on typing everything up. A video demonstration doesn't require
any writing per se. We can also capture small details that sometimes get
left out of tutorials and then make sure these details get into the
tutorials. This does *not* have to be edited at all.
On Fri, Jul 26, 2013 at 2:53 PM, Alex Harui <ah...@adobe.com> wrote:
> Hmm. The source path is really
> "/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark/sr
> c" (with "/src")? And you aren't using RSLs?
> What does a link report say for which Label.as it used?
>
> On 7/26/13 11:57 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
> >It was :-(
> >
> >EdB
> >
> >
> >
> >On Fri, Jul 26, 2013 at 4:10 PM, Alex Harui <ah...@adobe.com> wrote:
> >>
> >>
> >> On 7/26/13 2:41 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> >>
> >>>Ok, this is what I tried:
> >>>
> >>>I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
> >>>folder. In "project properties/Flex Build Path" on the "Source path"
> >>>tab I added the folder
> >>>"/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark
> >>>",
> >>>thinking this will allow me to work on the classic Spark components.
> >>>
> >>>In my project, I add a Label in MXML. I cmd click on 'Label' to get me
> >>>into the Label source.
> >> Check which Label.as it opened up. It may not be the one from git.
> >>
> >>>I place a trace statement in the constructor. I
> >>>save, clean the project (just to be sure) and launch the project in
> >>>debug mode... No trace statement shows up :-( When I try to put a
> >>>breakpoint in the source, it complains there is no code on that line.
> >>>
> >>>What am I doing wrong?
> >>>
> >>>EdB
> >>>
> >>>
> >>>
> >>>On Fri, Jul 26, 2013 at 1:38 AM, Alex Harui <ah...@adobe.com> wrote:
> >>>>
> >>>>
> >>>> On 7/25/13 3:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> >>>>
> >>>>>Hi,
> >>>>>
> >>>>>> but also means you don't have to build the SWCs before testing your
> >>>>>>changes.
> >>>>>
> >>>>>Perhaps I missing the point but if you make a change you will have to
> >>>>>recompile that project, you just don't have to recompile the entire
> >>>>>SDK.
> >>>> You are correct, but in my workflow, I don't even have to stop to
> >>>>compile
> >>>> a single project.
> >>>>
> >>>> For this resource module RTE I just worked on, I changed the files,
> >>>> compiled the test case without running any ant scripts, and repeated
> >>>>until
> >>>> it all worked. Then I go run a full build and start up mustella.
> >>>>
> >>>> -Alex
> >>>>
> >>>
> >>>
> >>>
> >>>--
> >>>Ix Multimedia Software
> >>>
> >>>Jan Luykenstraat 27
> >>>3521 VB Utrecht
> >>>
> >>>T. 06-51952295
> >>>I. www.ixsoftware.nl
> >>
> >
> >
> >
> >--
> >Ix Multimedia Software
> >
> >Jan Luykenstraat 27
> >3521 VB Utrecht
> >
> >T. 06-51952295
> >I. www.ixsoftware.nl
>
>
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Alex Harui <ah...@adobe.com>.
Hmm. The source path is really
"/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark/sr
c" (with "/src")? And you aren't using RSLs?
What does a link report say for which Label.as it used?
On 7/26/13 11:57 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>It was :-(
>
>EdB
>
>
>
>On Fri, Jul 26, 2013 at 4:10 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>> On 7/26/13 2:41 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>>>Ok, this is what I tried:
>>>
>>>I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
>>>folder. In "project properties/Flex Build Path" on the "Source path"
>>>tab I added the folder
>>>"/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark
>>>",
>>>thinking this will allow me to work on the classic Spark components.
>>>
>>>In my project, I add a Label in MXML. I cmd click on 'Label' to get me
>>>into the Label source.
>> Check which Label.as it opened up. It may not be the one from git.
>>
>>>I place a trace statement in the constructor. I
>>>save, clean the project (just to be sure) and launch the project in
>>>debug mode... No trace statement shows up :-( When I try to put a
>>>breakpoint in the source, it complains there is no code on that line.
>>>
>>>What am I doing wrong?
>>>
>>>EdB
>>>
>>>
>>>
>>>On Fri, Jul 26, 2013 at 1:38 AM, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>>>
>>>> On 7/25/13 3:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>>>>
>>>>>Hi,
>>>>>
>>>>>> but also means you don't have to build the SWCs before testing your
>>>>>>changes.
>>>>>
>>>>>Perhaps I missing the point but if you make a change you will have to
>>>>>recompile that project, you just don't have to recompile the entire
>>>>>SDK.
>>>> You are correct, but in my workflow, I don't even have to stop to
>>>>compile
>>>> a single project.
>>>>
>>>> For this resource module RTE I just worked on, I changed the files,
>>>> compiled the test case without running any ant scripts, and repeated
>>>>until
>>>> it all worked. Then I go run a full build and start up mustella.
>>>>
>>>> -Alex
>>>>
>>>
>>>
>>>
>>>--
>>>Ix Multimedia Software
>>>
>>>Jan Luykenstraat 27
>>>3521 VB Utrecht
>>>
>>>T. 06-51952295
>>>I. www.ixsoftware.nl
>>
>
>
>
>--
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Erik de Bruin <er...@ixsoftware.nl>.
It was :-(
EdB
On Fri, Jul 26, 2013 at 4:10 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 7/26/13 2:41 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>Ok, this is what I tried:
>>
>>I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
>>folder. In "project properties/Flex Build Path" on the "Source path"
>>tab I added the folder
>>"/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark",
>>thinking this will allow me to work on the classic Spark components.
>>
>>In my project, I add a Label in MXML. I cmd click on 'Label' to get me
>>into the Label source.
> Check which Label.as it opened up. It may not be the one from git.
>
>>I place a trace statement in the constructor. I
>>save, clean the project (just to be sure) and launch the project in
>>debug mode... No trace statement shows up :-( When I try to put a
>>breakpoint in the source, it complains there is no code on that line.
>>
>>What am I doing wrong?
>>
>>EdB
>>
>>
>>
>>On Fri, Jul 26, 2013 at 1:38 AM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>>
>>> On 7/25/13 3:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>>>
>>>>Hi,
>>>>
>>>>> but also means you don't have to build the SWCs before testing your
>>>>>changes.
>>>>
>>>>Perhaps I missing the point but if you make a change you will have to
>>>>recompile that project, you just don't have to recompile the entire SDK.
>>> You are correct, but in my workflow, I don't even have to stop to
>>>compile
>>> a single project.
>>>
>>> For this resource module RTE I just worked on, I changed the files,
>>> compiled the test case without running any ant scripts, and repeated
>>>until
>>> it all worked. Then I go run a full build and start up mustella.
>>>
>>> -Alex
>>>
>>
>>
>>
>>--
>>Ix Multimedia Software
>>
>>Jan Luykenstraat 27
>>3521 VB Utrecht
>>
>>T. 06-51952295
>>I. www.ixsoftware.nl
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Ok, I'm stuck again.
I did New Project and added the spark/src folder as indicated above. I
added one Label to the app. Now when I try to run, I get the error
Error: Skin for Main cannot be found.
I tried adding some other source directories to the source path, to no avail.
I'm less and less sure this is method will be easier to set up for a
novice contributor...
EdB
On Fri, Jul 26, 2013 at 12:48 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Ok, when I tried
>
> "/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark/src"
> instead of what I had
>
> "/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark"
>
> I now get some of the errors Om was mentioning.
>
> To be continued...
>
> EdB
>
>
>
> On Fri, Jul 26, 2013 at 12:42 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>> That setting was on the default: "Use SDK default (merged into code)",
>> so I guess I did.
>>
>> EdB
>>
>>
>>
>> On Fri, Jul 26, 2013 at 12:02 PM, Frédéric Thomas
>> <we...@hotmail.com> wrote:
>>> Hi Erik,
>>>
>>> Did you make sure you have the "merge in the code" option checked ?
>>>
>>> -----Message d'origine----- From: Erik de Bruin
>>> Sent: Friday, July 26, 2013 11:41 AM
>>> To: dev@flex.apache.org
>>> Subject: Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
>>>
>>>
>>> Ok, this is what I tried:
>>>
>>> I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
>>> folder. In "project properties/Flex Build Path" on the "Source path"
>>> tab I added the folder
>>> "/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark",
>>> thinking this will allow me to work on the classic Spark components.
>>>
>>> In my project, I add a Label in MXML. I cmd click on 'Label' to get me
>>> into the Label source. I place a trace statement in the constructor. I
>>> save, clean the project (just to be sure) and launch the project in
>>> debug mode... No trace statement shows up :-( When I try to put a
>>> breakpoint in the source, it complains there is no code on that line.
>>>
>>> What am I doing wrong?
>>>
>>> EdB
>>>
>>>
>>>
>>> On Fri, Jul 26, 2013 at 1:38 AM, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>>>
>>>>
>>>> On 7/25/13 3:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>> but also means you don't have to build the SWCs before testing your
>>>>>> changes.
>>>>>
>>>>>
>>>>> Perhaps I missing the point but if you make a change you will have to
>>>>> recompile that project, you just don't have to recompile the entire SDK.
>>>>
>>>> You are correct, but in my workflow, I don't even have to stop to compile
>>>> a single project.
>>>>
>>>> For this resource module RTE I just worked on, I changed the files,
>>>> compiled the test case without running any ant scripts, and repeated until
>>>> it all worked. Then I go run a full build and start up mustella.
>>>>
>>>> -Alex
>>>>
>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Ok, when I tried
"/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark/src"
instead of what I had
"/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark"
I now get some of the errors Om was mentioning.
To be continued...
EdB
On Fri, Jul 26, 2013 at 12:42 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> That setting was on the default: "Use SDK default (merged into code)",
> so I guess I did.
>
> EdB
>
>
>
> On Fri, Jul 26, 2013 at 12:02 PM, Frédéric Thomas
> <we...@hotmail.com> wrote:
>> Hi Erik,
>>
>> Did you make sure you have the "merge in the code" option checked ?
>>
>> -----Message d'origine----- From: Erik de Bruin
>> Sent: Friday, July 26, 2013 11:41 AM
>> To: dev@flex.apache.org
>> Subject: Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
>>
>>
>> Ok, this is what I tried:
>>
>> I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
>> folder. In "project properties/Flex Build Path" on the "Source path"
>> tab I added the folder
>> "/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark",
>> thinking this will allow me to work on the classic Spark components.
>>
>> In my project, I add a Label in MXML. I cmd click on 'Label' to get me
>> into the Label source. I place a trace statement in the constructor. I
>> save, clean the project (just to be sure) and launch the project in
>> debug mode... No trace statement shows up :-( When I try to put a
>> breakpoint in the source, it complains there is no code on that line.
>>
>> What am I doing wrong?
>>
>> EdB
>>
>>
>>
>> On Fri, Jul 26, 2013 at 1:38 AM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>>
>>>
>>> On 7/25/13 3:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>>>
>>>> Hi,
>>>>
>>>>> but also means you don't have to build the SWCs before testing your
>>>>> changes.
>>>>
>>>>
>>>> Perhaps I missing the point but if you make a change you will have to
>>>> recompile that project, you just don't have to recompile the entire SDK.
>>>
>>> You are correct, but in my workflow, I don't even have to stop to compile
>>> a single project.
>>>
>>> For this resource module RTE I just worked on, I changed the files,
>>> compiled the test case without running any ant scripts, and repeated until
>>> it all worked. Then I go run a full build and start up mustella.
>>>
>>> -Alex
>>>
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Erik de Bruin <er...@ixsoftware.nl>.
That setting was on the default: "Use SDK default (merged into code)",
so I guess I did.
EdB
On Fri, Jul 26, 2013 at 12:02 PM, Frédéric Thomas
<we...@hotmail.com> wrote:
> Hi Erik,
>
> Did you make sure you have the "merge in the code" option checked ?
>
> -----Message d'origine----- From: Erik de Bruin
> Sent: Friday, July 26, 2013 11:41 AM
> To: dev@flex.apache.org
> Subject: Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
>
>
> Ok, this is what I tried:
>
> I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
> folder. In "project properties/Flex Build Path" on the "Source path"
> tab I added the folder
> "/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark",
> thinking this will allow me to work on the classic Spark components.
>
> In my project, I add a Label in MXML. I cmd click on 'Label' to get me
> into the Label source. I place a trace statement in the constructor. I
> save, clean the project (just to be sure) and launch the project in
> debug mode... No trace statement shows up :-( When I try to put a
> breakpoint in the source, it complains there is no code on that line.
>
> What am I doing wrong?
>
> EdB
>
>
>
> On Fri, Jul 26, 2013 at 1:38 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>>
>> On 7/25/13 3:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>>
>>> Hi,
>>>
>>>> but also means you don't have to build the SWCs before testing your
>>>> changes.
>>>
>>>
>>> Perhaps I missing the point but if you make a change you will have to
>>> recompile that project, you just don't have to recompile the entire SDK.
>>
>> You are correct, but in my workflow, I don't even have to stop to compile
>> a single project.
>>
>> For this resource module RTE I just worked on, I changed the files,
>> compiled the test case without running any ant scripts, and repeated until
>> it all worked. Then I go run a full build and start up mustella.
>>
>> -Alex
>>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Frédéric Thomas <we...@hotmail.com>.
Hi Erik,
Did you make sure you have the "merge in the code" option checked ?
-----Message d'origine-----
From: Erik de Bruin
Sent: Friday, July 26, 2013 11:41 AM
To: dev@flex.apache.org
Subject: Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Ok, this is what I tried:
I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
folder. In "project properties/Flex Build Path" on the "Source path"
tab I added the folder
"/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark",
thinking this will allow me to work on the classic Spark components.
In my project, I add a Label in MXML. I cmd click on 'Label' to get me
into the Label source. I place a trace statement in the constructor. I
save, clean the project (just to be sure) and launch the project in
debug mode... No trace statement shows up :-( When I try to put a
breakpoint in the source, it complains there is no code on that line.
What am I doing wrong?
EdB
On Fri, Jul 26, 2013 at 1:38 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 7/25/13 3:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>>Hi,
>>
>>> but also means you don't have to build the SWCs before testing your
>>>changes.
>>
>>Perhaps I missing the point but if you make a change you will have to
>>recompile that project, you just don't have to recompile the entire SDK.
> You are correct, but in my workflow, I don't even have to stop to compile
> a single project.
>
> For this resource module RTE I just worked on, I changed the files,
> compiled the test case without running any ant scripts, and repeated until
> it all worked. Then I go run a full build and start up mustella.
>
> -Alex
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Justin,
I was trying out the method Om and Alex describe. I'm familiar with
the setup you use, as it is the one I use and have had no problems
with. I was interested in the 'direct' method because on paper (in
email) it sounds easier. But I was unable to get the setup to work. I
was hoping Om or Alex could give a little more detail on the way they
have set up their dev systems.
EdB
On Fri, Jul 26, 2013 at 12:56 PM, Justin Mclean
<ju...@classsoftware.com> wrote:
> Hi,
>
>> I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
>> folder. In "project properties/Flex Build Path" on the "Source path"
>> tab
> Should be no need to do this it should pick up the source automatically.
>
> For instance in the new SDK I just installed command clicking of a framework class takes you right to the code.
>
> If you want the SDK source tree to show up in FB just import it a a general project, that way features like "link with editor' etc will work.
>
>> I cmd click on 'Label' to get me into the Label source. I place a trace statement in the constructor. I
>> save, clean the project (just to be sure) and launch the project in
>> debug mode... No trace statement shows up :-(
> This is because you're not recompiled the spark project (assuming it was a spark label) you need to run ant in frameworks/projects/spark via the command line or if you have the SDK in a FB project you can right click on the build.xml and run as ant project - assuming you have all the env vars set up in FB.
>
> Thanks,
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Tom Chiverton <tc...@extravision.com>.
On 26/07/2013 11:56, Justin Mclean wrote:
> Hi,
>
>> I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
>> folder. In "project properties/Flex Build Path" on the "Source path"
>> tab
> Should be no need to do this it should pick up the source automatically.
Sounds like might have both the .swc and the framework source path added
? I tend to do one or the other...
Tom
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
> folder. In "project properties/Flex Build Path" on the "Source path"
> tab
Should be no need to do this it should pick up the source automatically.
For instance in the new SDK I just installed command clicking of a framework class takes you right to the code.
If you want the SDK source tree to show up in FB just import it a a general project, that way features like "link with editor' etc will work.
> I cmd click on 'Label' to get me into the Label source. I place a trace statement in the constructor. I
> save, clean the project (just to be sure) and launch the project in
> debug mode... No trace statement shows up :-(
This is because you're not recompiled the spark project (assuming it was a spark label) you need to run ant in frameworks/projects/spark via the command line or if you have the SDK in a FB project you can right click on the build.xml and run as ant project - assuming you have all the env vars set up in FB.
Thanks,
Justin
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Alex Harui <ah...@adobe.com>.
On 7/26/13 2:41 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>Ok, this is what I tried:
>
>I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
>folder. In "project properties/Flex Build Path" on the "Source path"
>tab I added the folder
>"/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark",
>thinking this will allow me to work on the classic Spark components.
>
>In my project, I add a Label in MXML. I cmd click on 'Label' to get me
>into the Label source.
Check which Label.as it opened up. It may not be the one from git.
>I place a trace statement in the constructor. I
>save, clean the project (just to be sure) and launch the project in
>debug mode... No trace statement shows up :-( When I try to put a
>breakpoint in the source, it complains there is no code on that line.
>
>What am I doing wrong?
>
>EdB
>
>
>
>On Fri, Jul 26, 2013 at 1:38 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>> On 7/25/13 3:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>>
>>>Hi,
>>>
>>>> but also means you don't have to build the SWCs before testing your
>>>>changes.
>>>
>>>Perhaps I missing the point but if you make a change you will have to
>>>recompile that project, you just don't have to recompile the entire SDK.
>> You are correct, but in my workflow, I don't even have to stop to
>>compile
>> a single project.
>>
>> For this resource module RTE I just worked on, I changed the files,
>> compiled the test case without running any ant scripts, and repeated
>>until
>> it all worked. Then I go run a full build and start up mustella.
>>
>> -Alex
>>
>
>
>
>--
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Ok, this is what I tried:
I created a new project in FB. It uses the 4.10 SDK in the FB/sdks
folder. In "project properties/Flex Build Path" on the "Source path"
tab I added the folder
"/Users/erik/Documents/ApacheFlex/git/flex-sdk/frameworks/projects/spark",
thinking this will allow me to work on the classic Spark components.
In my project, I add a Label in MXML. I cmd click on 'Label' to get me
into the Label source. I place a trace statement in the constructor. I
save, clean the project (just to be sure) and launch the project in
debug mode... No trace statement shows up :-( When I try to put a
breakpoint in the source, it complains there is no code on that line.
What am I doing wrong?
EdB
On Fri, Jul 26, 2013 at 1:38 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 7/25/13 3:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>>Hi,
>>
>>> but also means you don't have to build the SWCs before testing your
>>>changes.
>>
>>Perhaps I missing the point but if you make a change you will have to
>>recompile that project, you just don't have to recompile the entire SDK.
> You are correct, but in my workflow, I don't even have to stop to compile
> a single project.
>
> For this resource module RTE I just worked on, I changed the files,
> compiled the test case without running any ant scripts, and repeated until
> it all worked. Then I go run a full build and start up mustella.
>
> -Alex
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Alex Harui <ah...@adobe.com>.
On 7/25/13 3:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> but also means you don't have to build the SWCs before testing your
>>changes.
>
>Perhaps I missing the point but if you make a change you will have to
>recompile that project, you just don't have to recompile the entire SDK.
You are correct, but in my workflow, I don't even have to stop to compile
a single project.
For this resource module RTE I just worked on, I changed the files,
compiled the test case without running any ant scripts, and repeated until
it all worked. Then I go run a full build and start up mustella.
-Alex
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> but also means you don't have to build the SWCs before testing your changes.
Perhaps I missing the point but if you make a change you will have to recompile that project, you just don't have to recompile the entire SDK.
Justin
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Alex Harui <ah...@adobe.com>.
Just wondering: Should there be different processes for different kinds
of people?
For example, if you don't have any interest in becoming a committer but
have one null check to add, should we support a workflow where you monkey
patch in the null and submit the whole file to the mustella patch tester
and then JIRA? Then folks don't really need to go through all of these
steps.
But if you are interested, then hopefully you will be motivated enough to
go through these steps and hopefully even learn to work without converting
your source tree to an FB-compatible folder because of the license-mixing
that goes on. In the back of my mind, I've been wondering if we can find
a better way than we have now. Like maybe just having folks point a
source-path to their local working copies. Source-path is supposed to
take precedence over anything found in the library path. It slows down
compilation, of course, but also means you don't have to build the SWCs
before testing your changes.
-Alex
On 7/25/13 6:16 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>There is a gap between how you build the SDK and how you make and test
>changes to the SDK:
>
>(working from memory here) After you build the SDK ('ant main') you
>run the script 'ide/constructFlexForIDE' to prepare the SDK for use in
>Flash Builder. You then create your test application (in which you
>will reproduce the bug) to use this newly build and prepared SDK.
>
>Now a question to all of you: can we make an app (or extend the
>Installer) so the steps to prepare a system for building the SDK are
>performed automatically?
>
>- I think we can download and launch the installers (not sure if we
>can poll for completion, though)
>- we can create an env.properties with all the paths set, bypassing
>the need to set system wide variables in obscure settings panes/files
>- we can create a preset directory structure to hold the source files
>and their dependencies (AIR SDK, playerglobal etc.)
>- we can find and edit mm.cfg and create a FlashPlayerTrust file
>- etc.
>
>Does anyone see any major obstacles that I'm overlooking?
>
>EdB
>
>
>
>On Thu, Jul 25, 2013 at 1:31 PM, Justin Mclean <ju...@classsoftware.com>
>wrote:
>> Hi,
>>
>> I took some notes while fixing this bug.
>> https://issues.apache.org/jira/browse/FLEX-33165
>>
>> Any feedback and questions welcome.
>>
>> Bug information
>> Note that it's marked as "easyfix" and a RTE. Generally these sort of
>>bugs don't take much to fix. Looking at the report you can see it's for
>>a mobile project and Adobe Flex 4.6 so the line numbers are not going to
>>match up to the current development branch. Search for the line of code
>>where the error occurs, as the code may of change first look for the
>>function name. You can see that the error is now on line 1581.
>>
>> Reproduce the Bug
>> There is no sample code so you need to work out how to reproduce it, so
>>create a new sample mobile project containing a horizontal spark list
>>and run it. See if it can reproduce the issue using the 4.6 SDK. No
>>luck. (See the JIRA issue for the code used)
>>
>> Try and work out how to generate the RTE. Looking at the snapElement
>>method it looks like the error would only occur when scrollProperty is
>>null and that could happen if both canScrollHorizontally and
>>canScrollVertically are false. It's possible that this could happen when
>>size changes removes the scrollbars when screen orientation changes.
>>This is probably why the bug is hard to reproduce as it depends on the
>>amount of content in the list and the screen size. The easy way to
>>simulate this is to turn off both horizontal scrolling and vertical
>>scrolling and call the mx_internal method. Modify the code to call the
>>method directly with both scroll bar policy off and smapping set to
>>something other than none. Bingo we have the RTE!
>>
>> protected function init(event:FlexEvent):void
>> {
>> list.scroller.mx_internal::snapElement(10, false);
>> }
>>
>> <s:List id="list" dataProvider="{listdata}" width="100%"
>>height="100%" verticalScrollPolicy="off" horizontalScrollPolicy="off"
>>scrollSnappingMode="center">
>> <s:layout>
>> <s:HorizontalLayout />
>> </s:layout>
>> </s:List>
>>
>>
>> Test in the develop branch
>> Change to using the latest develop branch and see if the issue still
>>exists and yes it does.
>>
>> Fix the bug
>> To fix add a null check and recompile the spark project by changing to
>>the frameworks/projects/spark directory and run ant to compile, this
>>should only take less than a min to compile.
>>
>> Clean the FB project so it picks up the framework change. Sometime it
>>will cache the swc and may require swapping to and old SDK and then
>>back again. Double check you are using the SDK you made the change in.
>>
>> Test the Change
>> Run the program again and/or text code path in the debugger to see that
>>the issue has been fixed. Play about with the sample application to make
>>sure nothing else has been broken.
>>
>> Running mustella tests
>> A change to the scroller class could effect a lot of tests but we can
>>run the basic tests to make sure and assume the CI will pick up any
>>other issues. For a change like this I wouldn't expect any issues or
>>side effects as the RTE would normally occur, but it's best to be safe.
>>
>> ./mini_run.sh tests/gumbo/components/ScrollBar
>> ./mini_run.sh tests/gumbo/components/Scroller
>>
>> Both sets of test pass as expected.
>>
>> [java] =====================================================
>> [java] Passes: 122
>> [java] Fails: 0
>> [java] =====================================================
>>
>> [java] =====================================================
>> [java] Passes: 74
>> [java] Fails: 0
>> [java] =====================================================
>>
>>
>> Commit the change
>> If you are a committer you can directly commit the change via a git
>>push. If you are not not a committer you would need to generate a patch
>>file and add it to the JIRA issue. Make sure you generate the patch from
>>the base SDK directory like so.
>>
>> git diff frameworks/projects/spark/src/spark/components/Scroller.as
>>
>> diff --git a/frameworks/projects/spark/src/spark/components/Scroller.as
>>b/frameworks/projects/spark/
>> index 9f91412..c48222d 100644
>> --- a/frameworks/projects/spark/src/spark/components/Scroller.as
>> +++ b/frameworks/projects/spark/src/spark/components/Scroller.as
>> @@ -1579,7 +1579,8 @@ public class Scroller extends SkinnableComponent
>> }
>> else
>> {
>> - viewport[scrollProperty] = snapScrollPosition;
>> + if (scrollProperty)
>> + viewport[scrollProperty] = snapScrollPosition;
>>
>> return null;
>> }
>>
>> Update JIRA
>> Mark the bug as resolved noting down the Apache Flex versions it has
>>been fixed in.
>>
>> Hope that was helpful,
>> Justin
>
>
>
>--
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Erik de Bruin <er...@ixsoftware.nl>.
There is a gap between how you build the SDK and how you make and test
changes to the SDK:
(working from memory here) After you build the SDK ('ant main') you
run the script 'ide/constructFlexForIDE' to prepare the SDK for use in
Flash Builder. You then create your test application (in which you
will reproduce the bug) to use this newly build and prepared SDK.
Now a question to all of you: can we make an app (or extend the
Installer) so the steps to prepare a system for building the SDK are
performed automatically?
- I think we can download and launch the installers (not sure if we
can poll for completion, though)
- we can create an env.properties with all the paths set, bypassing
the need to set system wide variables in obscure settings panes/files
- we can create a preset directory structure to hold the source files
and their dependencies (AIR SDK, playerglobal etc.)
- we can find and edit mm.cfg and create a FlashPlayerTrust file
- etc.
Does anyone see any major obstacles that I'm overlooking?
EdB
On Thu, Jul 25, 2013 at 1:31 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> I took some notes while fixing this bug.
> https://issues.apache.org/jira/browse/FLEX-33165
>
> Any feedback and questions welcome.
>
> Bug information
> Note that it's marked as "easyfix" and a RTE. Generally these sort of bugs don't take much to fix. Looking at the report you can see it's for a mobile project and Adobe Flex 4.6 so the line numbers are not going to match up to the current development branch. Search for the line of code where the error occurs, as the code may of change first look for the function name. You can see that the error is now on line 1581.
>
> Reproduce the Bug
> There is no sample code so you need to work out how to reproduce it, so create a new sample mobile project containing a horizontal spark list and run it. See if it can reproduce the issue using the 4.6 SDK. No luck. (See the JIRA issue for the code used)
>
> Try and work out how to generate the RTE. Looking at the snapElement method it looks like the error would only occur when scrollProperty is null and that could happen if both canScrollHorizontally and canScrollVertically are false. It's possible that this could happen when size changes removes the scrollbars when screen orientation changes. This is probably why the bug is hard to reproduce as it depends on the amount of content in the list and the screen size. The easy way to simulate this is to turn off both horizontal scrolling and vertical scrolling and call the mx_internal method. Modify the code to call the method directly with both scroll bar policy off and smapping set to something other than none. Bingo we have the RTE!
>
> protected function init(event:FlexEvent):void
> {
> list.scroller.mx_internal::snapElement(10, false);
> }
>
> <s:List id="list" dataProvider="{listdata}" width="100%" height="100%" verticalScrollPolicy="off" horizontalScrollPolicy="off" scrollSnappingMode="center">
> <s:layout>
> <s:HorizontalLayout />
> </s:layout>
> </s:List>
>
>
> Test in the develop branch
> Change to using the latest develop branch and see if the issue still exists and yes it does.
>
> Fix the bug
> To fix add a null check and recompile the spark project by changing to the frameworks/projects/spark directory and run ant to compile, this should only take less than a min to compile.
>
> Clean the FB project so it picks up the framework change. Sometime it will cache the swc and may require swapping to and old SDK and then back again. Double check you are using the SDK you made the change in.
>
> Test the Change
> Run the program again and/or text code path in the debugger to see that the issue has been fixed. Play about with the sample application to make sure nothing else has been broken.
>
> Running mustella tests
> A change to the scroller class could effect a lot of tests but we can run the basic tests to make sure and assume the CI will pick up any other issues. For a change like this I wouldn't expect any issues or side effects as the RTE would normally occur, but it's best to be safe.
>
> ./mini_run.sh tests/gumbo/components/ScrollBar
> ./mini_run.sh tests/gumbo/components/Scroller
>
> Both sets of test pass as expected.
>
> [java] =====================================================
> [java] Passes: 122
> [java] Fails: 0
> [java] =====================================================
>
> [java] =====================================================
> [java] Passes: 74
> [java] Fails: 0
> [java] =====================================================
>
>
> Commit the change
> If you are a committer you can directly commit the change via a git push. If you are not not a committer you would need to generate a patch file and add it to the JIRA issue. Make sure you generate the patch from the base SDK directory like so.
>
> git diff frameworks/projects/spark/src/spark/components/Scroller.as
>
> diff --git a/frameworks/projects/spark/src/spark/components/Scroller.as b/frameworks/projects/spark/
> index 9f91412..c48222d 100644
> --- a/frameworks/projects/spark/src/spark/components/Scroller.as
> +++ b/frameworks/projects/spark/src/spark/components/Scroller.as
> @@ -1579,7 +1579,8 @@ public class Scroller extends SkinnableComponent
> }
> else
> {
> - viewport[scrollProperty] = snapScrollPosition;
> + if (scrollProperty)
> + viewport[scrollProperty] = snapScrollPosition;
>
> return null;
> }
>
> Update JIRA
> Mark the bug as resolved noting down the Apache Flex versions it has been fixed in.
>
> Hope that was helpful,
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I took some notes while fixing this bug.
https://issues.apache.org/jira/browse/FLEX-33165
Any feedback and questions welcome.
Bug information
Note that it's marked as "easyfix" and a RTE. Generally these sort of bugs don't take much to fix. Looking at the report you can see it's for a mobile project and Adobe Flex 4.6 so the line numbers are not going to match up to the current development branch. Search for the line of code where the error occurs, as the code may of change first look for the function name. You can see that the error is now on line 1581.
Reproduce the Bug
There is no sample code so you need to work out how to reproduce it, so create a new sample mobile project containing a horizontal spark list and run it. See if it can reproduce the issue using the 4.6 SDK. No luck. (See the JIRA issue for the code used)
Try and work out how to generate the RTE. Looking at the snapElement method it looks like the error would only occur when scrollProperty is null and that could happen if both canScrollHorizontally and canScrollVertically are false. It's possible that this could happen when size changes removes the scrollbars when screen orientation changes. This is probably why the bug is hard to reproduce as it depends on the amount of content in the list and the screen size. The easy way to simulate this is to turn off both horizontal scrolling and vertical scrolling and call the mx_internal method. Modify the code to call the method directly with both scroll bar policy off and smapping set to something other than none. Bingo we have the RTE!
protected function init(event:FlexEvent):void
{
list.scroller.mx_internal::snapElement(10, false);
}
<s:List id="list" dataProvider="{listdata}" width="100%" height="100%" verticalScrollPolicy="off" horizontalScrollPolicy="off" scrollSnappingMode="center">
<s:layout>
<s:HorizontalLayout />
</s:layout>
</s:List>
Test in the develop branch
Change to using the latest develop branch and see if the issue still exists and yes it does.
Fix the bug
To fix add a null check and recompile the spark project by changing to the frameworks/projects/spark directory and run ant to compile, this should only take less than a min to compile.
Clean the FB project so it picks up the framework change. Sometime it will cache the swc and may require swapping to and old SDK and then back again. Double check you are using the SDK you made the change in.
Test the Change
Run the program again and/or text code path in the debugger to see that the issue has been fixed. Play about with the sample application to make sure nothing else has been broken.
Running mustella tests
A change to the scroller class could effect a lot of tests but we can run the basic tests to make sure and assume the CI will pick up any other issues. For a change like this I wouldn't expect any issues or side effects as the RTE would normally occur, but it's best to be safe.
./mini_run.sh tests/gumbo/components/ScrollBar
./mini_run.sh tests/gumbo/components/Scroller
Both sets of test pass as expected.
[java] =====================================================
[java] Passes: 122
[java] Fails: 0
[java] =====================================================
[java] =====================================================
[java] Passes: 74
[java] Fails: 0
[java] =====================================================
Commit the change
If you are a committer you can directly commit the change via a git push. If you are not not a committer you would need to generate a patch file and add it to the JIRA issue. Make sure you generate the patch from the base SDK directory like so.
git diff frameworks/projects/spark/src/spark/components/Scroller.as
diff --git a/frameworks/projects/spark/src/spark/components/Scroller.as b/frameworks/projects/spark/
index 9f91412..c48222d 100644
--- a/frameworks/projects/spark/src/spark/components/Scroller.as
+++ b/frameworks/projects/spark/src/spark/components/Scroller.as
@@ -1579,7 +1579,8 @@ public class Scroller extends SkinnableComponent
}
else
{
- viewport[scrollProperty] = snapScrollPosition;
+ if (scrollProperty)
+ viewport[scrollProperty] = snapScrollPosition;
return null;
}
Update JIRA
Mark the bug as resolved noting down the Apache Flex versions it has been fixed in.
Hope that was helpful,
Justin
RE: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Sugan Naicker <Su...@Dev-X.co.za>.
Hi,
This would be great. Yes, this would encourage more involved.
Regards.
Sugan
-----Original Message-----
From: omuppi1@gmail.com [mailto:omuppi1@gmail.com] On Behalf Of OmPrakash
Muppirala
Sent: 24 July 2013 08:09 PM
To: dev@flex.apache.org
Subject: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
I would like to compile a comprehensive tutorial on how to fix, test and
submit patches to the Flex SDK. I feel that some important pieces re
missing for more users to contribute to the SDK. Here are a few things we
may want to concentrate on:
a) Get latest code. Does [1] have the most current information?
b) Set up development environment (With at least FB. IntelliJ would be a
bonus)
c) Walk through an 'easyfix' bug from JIRA and fix it
d) Test the changes. Checkintests, Mustella, Alex's patch server, etc.
e) Generate a patch file and submit
Justin, Mark, Erik, Alex, etc. who have been regularly fixing bugs, can you
please take some of these up and help me compile/edit the tutorial?
Thanks,
Om
[1] http://flex.apache.org/dev-sourcecode.html
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Sumudu Chinthaka <cs...@gmail.com>.
bid thumbs up for this
there are lot of people who want to contribute to flex and this would
really help them to get started
Regards
Sumudu
On Thu, Jul 25, 2013 at 5:22 AM, Mark Kessler
<ke...@gmail.com>wrote:
> Where are we assembling this information? We can use our wiki since it
> already has some of this started... Git information [1], Bug fixing [2].
> Well just have to layout the structure before we start.
>
> It's a lot of work up front to get started. Setting up to build the
> nightly sdk can be daunting at first. Setting up a developing environment
> (which I assume they have already if there working with Flex). Then they
> can try to help out.
>
>
> TL Getting started
> ....Setting up nightly SDK
> ........Installer way
> ........Setting up Manually
> ....Setting up IDEs (if desired)
> ........Flash Builder
> ........IntelliJ Idea
> ........FlashDevelop
> ....Creating Accounts for anything required.
> ........JIRA account
> ....Bug hunting
> ........How to select easy bugs (filtering n such)
> ....Bug Fixing
> ........How to identify what needs to be fixed.
> ........Ways we should fix things (asdoc, comments, code style matching,
> ...)
> ........Test application to test the problem and when it's fixed
> ....Testing
> ........ChekinTests
> ........Mustella for component(s)
> ........
> ....Patch
> ........Creating patch file
> ........Adding patch to issue.
> ........Adding test application to issue.
>
>
> [1]
> https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide
> [2] https://cwiki.apache.org/confluence/display/FLEX/Bug+Fixing
>
>
>
>
> On Wed, Jul 24, 2013 at 2:08 PM, OmPrakash Muppirala
> <bi...@gmail.com>wrote:
>
> > I would like to compile a comprehensive tutorial on how to fix, test and
> > submit patches to the Flex SDK. I feel that some important pieces re
> > missing for more users to contribute to the SDK. Here are a few things
> we
> > may want to concentrate on:
> >
> > a) Get latest code. Does [1] have the most current information?
> > b) Set up development environment (With at least FB. IntelliJ would be a
> > bonus)
> > c) Walk through an 'easyfix' bug from JIRA and fix it
> > d) Test the changes. Checkintests, Mustella, Alex's patch server, etc.
> > e) Generate a patch file and submit
> >
> > Justin, Mark, Erik, Alex, etc. who have been regularly fixing bugs, can
> you
> > please take some of these up and help me compile/edit the tutorial?
> >
> > Thanks,
> > Om
> >
> > [1] http://flex.apache.org/dev-sourcecode.html
> >
>
Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Posted by Mark Kessler <ke...@gmail.com>.
Where are we assembling this information? We can use our wiki since it
already has some of this started... Git information [1], Bug fixing [2].
Well just have to layout the structure before we start.
It's a lot of work up front to get started. Setting up to build the
nightly sdk can be daunting at first. Setting up a developing environment
(which I assume they have already if there working with Flex). Then they
can try to help out.
TL Getting started
....Setting up nightly SDK
........Installer way
........Setting up Manually
....Setting up IDEs (if desired)
........Flash Builder
........IntelliJ Idea
........FlashDevelop
....Creating Accounts for anything required.
........JIRA account
....Bug hunting
........How to select easy bugs (filtering n such)
....Bug Fixing
........How to identify what needs to be fixed.
........Ways we should fix things (asdoc, comments, code style matching,
...)
........Test application to test the problem and when it's fixed
....Testing
........ChekinTests
........Mustella for component(s)
........
....Patch
........Creating patch file
........Adding patch to issue.
........Adding test application to issue.
[1]
https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide
[2] https://cwiki.apache.org/confluence/display/FLEX/Bug+Fixing
On Wed, Jul 24, 2013 at 2:08 PM, OmPrakash Muppirala
<bi...@gmail.com>wrote:
> I would like to compile a comprehensive tutorial on how to fix, test and
> submit patches to the Flex SDK. I feel that some important pieces re
> missing for more users to contribute to the SDK. Here are a few things we
> may want to concentrate on:
>
> a) Get latest code. Does [1] have the most current information?
> b) Set up development environment (With at least FB. IntelliJ would be a
> bonus)
> c) Walk through an 'easyfix' bug from JIRA and fix it
> d) Test the changes. Checkintests, Mustella, Alex's patch server, etc.
> e) Generate a patch file and submit
>
> Justin, Mark, Erik, Alex, etc. who have been regularly fixing bugs, can you
> please take some of these up and help me compile/edit the tutorial?
>
> Thanks,
> Om
>
> [1] http://flex.apache.org/dev-sourcecode.html
>