flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: [REQUEST] A tutorial on how to fix bugs for the Flex SDK
Date Thu, 25 Jul 2013 17:11:06 GMT
>
> 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" <erik@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 <justin@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message