RE: FalconJX mxmlc error

[Tigran Najaryan]

Erik,

Sorry, that still does not work. Different error this time though!

I tried this command line:

mxmlc env.PLAYERGLOBAL_HOME="C:/Program Files (x86)/Adobe/Adobe Flash
Builder 4.6/sdks/4.9.0/frameworks/libs/player" ^
playerglobal.version=11.1 ^
-load-config=D:/WORK/Projects/ApacheFlex/repo/sdk/trunk/frameworks/flex-conf
ig.xml ^
-library-path+=D:/WORK/Projects/ApacheFlex/repo/asjs/branches/develop/framew
orks/as/libs/FlexJSUI.swc ^
-js-output-type=FLEXJS ^
-closure-lib=D:/WORK/Projects/ApacheFlex/dependencies/GoogleClosure/library
^
-sdk-js-lib=D:/WORK/Projects/ApacheFlex/repo/asjs/branches/develop/framework
s/js/FlexJS/src ^
D:\WORK\Projects\ApacheFlex\repo\asjs\branches\develop\examples\FlexJSTest_a
gain\FlexJSTest.mxml

and get the following output:

Using Flex SDK: D:\WORK\Projects\ApacheFlex\repo\sdk\branches\develop
command line
unknown configuration variable 'closure-lib'.

Then I removed the "-closure-lib" parameter, run again and got this:

Using Flex SDK: D:\WORK\Projects\ApacheFlex\repo\sdk\branches\develop
command line
unknown configuration variable 'sdk-js-lib'.


Then removed the -sdk-js-lib parameter, run again and got this:

Using Flex SDK: D:\WORK\Projects\ApacheFlex\repo\sdk\branches\develop
command line
default arguments may not be interspersed with other options.


I then tried mxmlc -help and mxmlc -help list to see what command line
options are supported but both result in this exception:

Exception in thread "main" java.lang.UnsupportedOperationException
at
org.apache.flex.compiler.internal.driver.as.ASBackend.getSourceFileHandlerIn
stance(ASBackend.java:70)
at org.apache.flex.compiler.clients.MXMLJSC.(MXMLJSC.java:201)
at org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:169)



I also tried looking for the command line options implementation in the
source code. The string "sdk-js-lib" does not exist anywhere in the
repo/falcon/trunk/compiler.jx/src/*

The text "closure-lib" is present in JSGoogConfiguration.java which if I
understand it correct will only be used when the GoogBackend is used which
in turn will be only used if js-output-type is set to "goog". Am I reading
the source code incorrectly or there is just no way for "closure-lib" and
"sdk-js-lib" parameters to work when -js-output-type=FLEXJS is used?

Anything else I can try?


BTW, what IDE do you use for FalconJX development? Command line is cool but
I'd prefer something like Eclipse when I finally get to the point where I
can change a source and debug.

Thanks,
Tigran.


-Original Message-
From: Erik de Bruin [mailto:e...@ixsoftware.nl] 
Sent: Friday, April 05, 2013 4:20 PM
To: dev@flex.apache.org
Subject: Re: FalconJX mxmlc error

Tigran,

Being a work in progress, FalconJx works only with a very specific set of
inputs. To build FlexJS, use these (add/change paths to match your
setup):

+env.PLAYERGLOBAL_HOME=[pathToGlobalPlayerSWCRoot]
+playerglobal.version=11.1
-load-config="/Applications/Adobe Flash Builder
4.7/sdks/4.9.1/frameworks/flex-config.xml"
-library-path+=[pathToFlexUISWC]
-js-output-type=FLEXJS
-closure-lib=[pathToGoogleClosureLibRoot]
-sdk-js-lib=[pathToFlexJSSrc]
[pathToProjectMainMXML]

And yes, I do agree that better documentation would help. Maybe you can keep
notes while you are working on getting this to run on your system. We could
use those as the basis for a wiki page.

HTH,

EdB

On Fri, Apr 5, 2013 at 3:38 AM, Tigran Najaryan  wrote:
> OK, I built FalconJX but how do I use it properly? Simply running 
> mxmlc without a command line gives an error:
>
> D:\WORK\Projects\ApacheFlex\repo\falcon\trunk\compiler.jx\bin>mxmlc
> Using Flex SDK: D:\WORK\Projects\ApacheFlex\repo\sdk\branches\develop
> Exception in thread "main" java.lang.UnsupportedOperationException
> at
> org.apache.flex.compiler.internal.driver.as.ASBackend.getSourceFileHan
> dlerIn
> stance(ASBackend.java:70)
> at
org.apache.flex.compiler.clients.MXMLJSC.(MXMLJSC.java:201)
> at 
> org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:169)
>
>
> Looks like it selects AS backend where getSourceFileHandlerInstanceI() 
> is not implemented.
>
> From the MXMLJSC.java I can see it expects a -js-output-type= parameter.
> Calling with any of -js-output-type=flexjs, -js-output-type=good or 
> -js-output-type=amd results in another error in 
> WorkspaceProblemFormatter.java but I do not even have the source file 
> in my org/apache/flex/compiler/clients/problems directory.
>
> Here is the error:
>
> D:\WORK\Projects\ApacheFlex\repo\falcon\trunk\compiler.jx\bin>mxmlc
> -js-output-type=flexjs
> D:\WORK\Projects\ApacheFlex\repo\falcon\trunk\compiler.js\tests\TestAp
> p.as Using Flex SDK: 
> D:\WORK\Projects\ApacheFlex\repo\sdk\branches\develop
> Exception in thread "main" com.google.common.collect.ComputationException:
> java.lang.IllegalAccessError: tried to access method 
> com.google.common.collect.MapMaker.maximumSize(I)Lcom/google/common/co
> llect/
> MapMaker; from c

Re: Welcome our newest Apache Flex committer Harbs

[Cyrill Zadra]

Welcome and congratulations Harbs!

On Sat, Apr 6, 2013 at 4:07 PM, Justin Mclean  wrote:
> Hi,
>
> The Project Management Committee (PMC) for Apache Flex
> has asked Harbs to become a committer and we are pleased to
> announce that he has accepted.
>
> Harbs has been contributing to Apache Flex for many months on the
> mailing list and in JIRA and elsewhere including this blog post a few
> months back.
> http://printui.com/blog/2013/01/flex-flash/
>
> He's just checked in an improved version of the spark colour picker.
>
> Congratulations
> Justin Mclean
> for the Flex PMC
>

Welcome our newest Apache Flex committer Harbs

[Justin Mclean]

Hi,

The Project Management Committee (PMC) for Apache Flex
has asked Harbs to become a committer and we are pleased to
announce that he has accepted.

Harbs has been contributing to Apache Flex for many months on the
mailing list and in JIRA and elsewhere including this blog post a few
months back.
http://printui.com/blog/2013/01/flex-flash/

He's just checked in an improved version of the spark colour picker.

Congratulations
Justin Mclean
for the Flex PMC

Re: Apache Flex oustanding bugs

[Dev Khadka]

On 4/6/2013 10:09 AM, Justin Mclean wrote:

Hi,

There are currently:
1 unassigned unresolved blocker bugs
20 unassigned  unresolved  critical bugs
2901 unassigned unresolved major bugs

It may be that some of these have already been fixed, should not be at priority 
etc etc but I'd assume most of them are outstanding. Are there any developer or 
committer with a little spare time about to put in some effort to help reduce 
this number?

I can't see us making a release while we are in this state which is what we 
should be trying to do on a regular basis. We need to be supporting current 
users of the SDK.

Justin

+1  I agree

Apache Flex oustanding bugs

[Justin Mclean]

Hi,

There are currently:
1 unassigned unresolved blocker bugs
20 unassigned  unresolved  critical bugs
2901 unassigned unresolved major bugs

It may be that some of these have already been fixed, should not be at priority 
etc etc but I'd assume most of them are outstanding. Are there any developer or 
committer with a little spare time about to put in some effort to help reduce 
this number? 

I can't see us making a release while we are in this state which is what we 
should be trying to do on a regular basis. We need to be supporting current 
users of the SDK.

Justin

[jira] [Assigned] (FLEX-33451) The release build due to the Git migration is broken

[Justin Mclean (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLEX-33451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Mclean reassigned FLEX-33451:


Assignee: (was: Justin Mclean)

> The release build due to the Git migration is broken
> 
>
> Key: FLEX-33451
> URL: https://issues.apache.org/jira/browse/FLEX-33451
> Project: Apache Flex
>  Issue Type: Bug
>  Components: .Unspecified - Framework
>Affects Versions: Adobe Flex SDK Next
>Reporter: Frédéric THOMAS
>Priority: Critical
>  Labels: Git, TLF, build, documentation
>
> The release build due to the Git migration is broken:
> - TLF external build
> - Build Number
> - ASDoc for the experimental lib
> - Building process (.gitignore, empty.properties)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FLEX-33451) The release build due to the Git migration is broken

[Justin Mclean (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLEX-33451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13624325#comment-13624325
 ] 

Justin Mclean commented on FLEX-33451:
--

"ant release" now works but need more testing.

Ant in the asdoc directory fails and I have no idea how to fix. This stops up 
creating asdocs to include in the release. Can someone take a look at this?

> The release build due to the Git migration is broken
> 
>
> Key: FLEX-33451
> URL: https://issues.apache.org/jira/browse/FLEX-33451
> Project: Apache Flex
>  Issue Type: Bug
>  Components: .Unspecified - Framework
>Affects Versions: Adobe Flex SDK Next
>Reporter: Frédéric THOMAS
>Assignee: Justin Mclean
>Priority: Critical
>  Labels: Git, TLF, build, documentation
>
> The release build due to the Git migration is broken:
> - TLF external build
> - Build Number
> - ASDoc for the experimental lib
> - Building process (.gitignore, empty.properties)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

AIR 3.7 support for Apache Flex

[Justin Mclean]

Hi,

Just a heads up/prgress on AIR 3.7 support from Adobe: 

"Our official 3.7 release is scheduled for next week (if all goes as planned.)  
If you can hang on that long we'll have a build that you'll be able to simply 
overlay as you would normally expect.
 
We are working to improve/correct this situation and include both SDK releases 
in our upcoming AIR 3.8 betas."

Thanks,
Justin

1.http://forums.adobe.com/message/5171561#5171561

Re: [VOTE] Release InstallApacheFlex 2.5.4 - RC5

[Cyrill Zadra]

+1

Successfully installed installer and flex on Windows 7 (64bit) - Language German

Thank you!

Cyrill

On Sat, Apr 6, 2013 at 12:35 PM, Frédéric THOMAS
 wrote:
>
> *Issues addressed in this Release Candidate:*
>
> 1.  Enable Flex SDK download stats tracking
> 2.  https://issues.apache.org/jira/browse/FLEX-33426 (UI fix for license
> screen (show regular checkboxes))
> 3.  https://issues.apache.org/jira/browse/FLEX-33151 (Auto-update logic fix)
> 4.  French and Dutch language locale fixes.
> 5.  Added the SDK version number to be downloaded in the window title.
> 6.  https://issues.apache.org/jira/browse/FLEX-33202 (more issues).
> 7.  https://issues.apache.org/jira/browse/FLEX-33419 (added germain
> language).
>
> This is the first official release of the InstallApacheFlex AIR application.
> The official Apache distribution is the source kit which can contain only
> source.
>
> The source distributions for Windows and Mac are available here:
>
> https://dist.apache.org/repos/dist/dev/flex/installer/2.5/RC5/sources/
>
> The binary distributions as a convenience for the respective platforms,
> available here:
>
> https://dist.apache.org/repos/dist/dev/flex/installer/2.5/RC5/binaries/
>
> Along with the installer, we are releasing the 'badge installer' that can be
> embedded in our site as well as third-party websites.  Here is a preview:
>
> http://flex.apache.org/installer.html
>
> *Before voting please review the section,*
> "What are the ASF requirements on approving a release?" at
> http://www.apache.org/dev/release.html#approving-a-release
>
> *Please vote to approve this release:*
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Regards,
> Om & Justin & Fred
> Apache Flex PMC members + Release managers

Re: Broken release build and git revision numbers

[Justin Mclean]

HI,

The one minor down side is that it's now it harder to tell exactly where a SDK 
was build from (no revision number n flex-describtion.xml). There would be a 
branch with the same version number so it's a minor annoyance.

Justin

Git release instructions

[Justin Mclean]

Hi,

Can someone with more git experience than me please update the instructions 
here:
https://cwiki.apache.org/confluence/display/FLEX/Release+Guide+for+the+SDK

It sort of important that we make how to make a release. :-)

I'm marked with FIXME where changes need to be made.

Thanks,
Justin

Re: Git needs a KISSa

[Gordon Smith]

Your link says "Merge is perfectly fine for managing your code." The only 
drawback it mentions is a more cluttered log. It has far stronger warnings 
about misusing rebase.

How could anyone read this conclusion


 1.  Merge works great, but creates lots of empty merge commits when you are 
working on a team.
 2.  Rebase keeps things tidy, but is destructive and potentially dangerous if 
you don’t know what you are doing.

and not conclude that merge is better for non-experts?

- Gordon

Sent from my iPad

On Apr 5, 2013, at 7:12 PM, "Gordon Smith" 
mailto:gosm...@adobe.com>> wrote:

Unfortunately that won't prevent it.

Please explain why not.

-  Gordon

Sent from my iPad

On Apr 5, 2013, at 6:21 PM, "Michael A. Labriola" 
mailto:labri...@digitalprimates.net>> wrote:

Gordon and Justin,

I agree that it would be bad to edit 2 files, do a 'git pull' followed by a 
'git status', and see changes to 200 files from other people mingling with your 
changes to 2. The simple way to prevent this is to commit your changes before 
pulling in other people's changes (I think).

Unfortunately that won't prevent it. For now, it's more about just educating 
everyone about merges.

Read this (and the comments if you are brave). [1] What Fred was advocating was 
a rebase workflow. What Gordon is proposing is mostly a merge workflow. That 
latter can work, we use it often, but it puts the onus on the developer doing 
the merge. Incidentally, this is why is most larger open source projects... see 
linux (or even what we did on FlexUnit in git) have a very few number of people 
who knew git well that managed the actual develop and master branches.

The rest of the community happily worked from their own forks (which is 
basically just a server side copy of git all to your own) and just pulled in 
changes from develop, they didn't push to develop. That was the question I was 
originally asking Fred as to if there was a technical reason that we were setup 
this way. Incidentally, Fred did an excellent job on the wiki pages and making 
his case.

I understand why everyone can see git as a pain right now. I really do. 
Ultimately the active committers on this list need to decide the correct route 
for the project. From my experience, this is the best analogy I can give. 
Please indulge me one last time.

SVN was like a nail and everyone got good at using a hammer to put that nail 
into the wall. Git is a screw. When you start, it's natural to try to pound the 
screw into the wall the same way you did a nail. You can make it work, but it 
will seem cumbersome and inelegant compared to the ease of the nail. You won't 
see any advantages and it won't get any better, although you can make it work. 
If, however, you can begin to see that the screw works differently (and btw, 
that's the big thing git and SVN are honestly night and day in how they work 
and their workflow) and begin carrying the right tool, soon you can see that 
the screw has some advantages. It doesn't replace a nail but for certain 
applications it's much more useful. Look at the success of open source projects 
on github, linux and many others and I promise, we aren't all crazy. There are 
growing pains, but they are not insurmountable.

I personally wish we had more of a github fork model here where a couple of 
people have the keys to the castle. To be honest, that's what I was envisioning 
when I voted for git. It may not be possible at this point or ever, but the 
result is putting the onus on everyone learning more about git than they might 
otherwise need and having a miserable experience. So, read my link. Ask 
questions and I will answer here whenever possible.

Mike

[1] 
http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/

Re: Git needs a KISSa

[Gordon Smith]

> Unfortunately that won't prevent it. 

Please explain why not.

-  Gordon

Sent from my iPad

On Apr 5, 2013, at 6:21 PM, "Michael A. Labriola" 
 wrote:

> Gordon and Justin,
> 
>> I agree that it would be bad to edit 2 files, do a 'git pull' followed by a 
>> 'git status', and see changes to 200 files from other people mingling with 
>> your changes to 2. The simple way to prevent this is to commit your changes 
>> before pulling in other people's changes (I think).
> 
> Unfortunately that won't prevent it. For now, it's more about just educating 
> everyone about merges.
> 
> Read this (and the comments if you are brave). [1] What Fred was advocating 
> was a rebase workflow. What Gordon is proposing is mostly a merge workflow. 
> That latter can work, we use it often, but it puts the onus on the developer 
> doing the merge. Incidentally, this is why is most larger open source 
> projects... see linux (or even what we did on FlexUnit in git) have a very 
> few number of people who knew git well that managed the actual develop and 
> master branches.
> 
> The rest of the community happily worked from their own forks (which is 
> basically just a server side copy of git all to your own) and just pulled in 
> changes from develop, they didn't push to develop. That was the question I 
> was originally asking Fred as to if there was a technical reason that we were 
> setup this way. Incidentally, Fred did an excellent job on the wiki pages and 
> making his case. 
> 
> I understand why everyone can see git as a pain right now. I really do. 
> Ultimately the active committers on this list need to decide the correct 
> route for the project. From my experience, this is the best analogy I can 
> give. Please indulge me one last time.
> 
> SVN was like a nail and everyone got good at using a hammer to put that nail 
> into the wall. Git is a screw. When you start, it's natural to try to pound 
> the screw into the wall the same way you did a nail. You can make it work, 
> but it will seem cumbersome and inelegant compared to the ease of the nail. 
> You won't see any advantages and it won't get any better, although you can 
> make it work. If, however, you can begin to see that the screw works 
> differently (and btw, that's the big thing git and SVN are honestly night and 
> day in how they work and their workflow) and begin carrying the right tool, 
> soon you can see that the screw has some advantages. It doesn't replace a 
> nail but for certain applications it's much more useful. Look at the success 
> of open source projects on github, linux and many others and I promise, we 
> aren't all crazy. There are growing pains, but they are not insurmountable. 
> 
> I personally wish we had more of a github fork model here where a couple of 
> people have the keys to the castle. To be honest, that's what I was 
> envisioning when I voted for git. It may not be possible at this point or 
> ever, but the result is putting the onus on everyone learning more about git 
> than they might otherwise need and having a miserable experience. So, read my 
> link. Ask questions and I will answer here whenever possible.
> 
> Mike
> 
> [1] 
> http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/
> 

Re: [VOTE] Release InstallApacheFlex 2.5.4 - RC5

[Nicholas Kwiatkowski]

+1

Used binary distro on Windows (7/64) + MacOS (10.8.3/64).  All in English.
 Worked just fine.

MD5 Hash matches.  Good job guys!

-Nick

On Fri, Apr 5, 2013 at 9:35 PM, Frédéric THOMAS wrote:

>
> *Issues addressed in this Release Candidate:*
>
> 1.  Enable Flex SDK download stats tracking
> 2.  
> https://issues.apache.org/**jira/browse/FLEX-33426(UI
>  fix for license
> screen (show regular checkboxes))
> 3.  
> https://issues.apache.org/**jira/browse/FLEX-33151(Auto-update
>  logic fix)
> 4.  French and Dutch language locale fixes.
> 5.  Added the SDK version number to be downloaded in the window title.
> 6.  
> https://issues.apache.org/**jira/browse/FLEX-33202(more
>  issues).
> 7.  
> https://issues.apache.org/**jira/browse/FLEX-33419(added
>  germain
> language).
>
> This is the first official release of the InstallApacheFlex AIR
> application.
> The official Apache distribution is the source kit which can contain only
> source.
>
> The source distributions for Windows and Mac are available here:
>
> https://dist.apache.org/repos/**dist/dev/flex/installer/2.5/**RC5/sources/
>
> The binary distributions as a convenience for the respective platforms,
> available here:
>
> https://dist.apache.org/repos/**dist/dev/flex/installer/2.5/**
> RC5/binaries/
>
> Along with the installer, we are releasing the 'badge installer' that can
> be
> embedded in our site as well as third-party websites.  Here is a preview:
>
> http://flex.apache.org/**installer.html
>
> *Before voting please review the section,*
> "What are the ASF requirements on approving a release?" at
> http://www.apache.org/dev/**release.html#approving-a-**release
>
> *Please vote to approve this release:*
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Regards,
> Om & Justin & Fred
> Apache Flex PMC members + Release managers
>

Re: Git needs a KISSa

[Justin Mclean]

Hi,

> Incidentally, this is why is most larger open source projects... see linux 
> (or even what we did on FlexUnit in git) have a very few number of people who 
> knew git well that managed the actual develop and master branches.
Could that work for us? (With committers pushing to develop that is?) Could 
someone who a git expert "clean up" the log on develop from time to time as 
required? Would anyone want to do that?

> It doesn't replace a nail but for certain applications it's much more useful. 
> Look at the success of open source projects on github, linux and many others 
> and I promise, we aren't all crazy.
I don't think that the issue. Most of us know some git and get what the 
benefits are (local branches, offline commits etc etc). I used git successfully 
on other projects and on my own projects and it was not this complex and there 
were minimal issues.

> I personally wish we had more of a github fork model here where a couple of 
> people have the keys to the castle.
Which is probably against the Apache Way.

> [1] 
> http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/
And this is the problem I run into  again and agin when reading about git. if 
you read the conclusion to me it's saying you need to be really really careful 
using rebase. It seems to me having a slightly  messy log is the lesser evil.

Thanks,
Justin

Re: Git remote branches

[Justin Mclean]

Hi,

> It won't affect your local branch. That will stay intact and viable.  
Even when it tracking the remote branch?

>> I suspect you mean changes to merge
Yep. However the remote branch has already been merged into develop (which I 
may or may not know depend on how close attention I've been paying to the 
commit log) - seems like potential for confusion on which version is the 
correct one here.

Thanks,
Justin

[VOTE] Release InstallApacheFlex 2.5.4 - RC5

[Frédéric THOMAS]

*Issues addressed in this Release Candidate:*

1.  Enable Flex SDK download stats tracking
2.  https://issues.apache.org/jira/browse/FLEX-33426 (UI fix for license
screen (show regular checkboxes))
3.  https://issues.apache.org/jira/browse/FLEX-33151 (Auto-update logic fix)
4.  French and Dutch language locale fixes.
5.  Added the SDK version number to be downloaded in the window title.
6.  https://issues.apache.org/jira/browse/FLEX-33202 (more issues).
7.  https://issues.apache.org/jira/browse/FLEX-33419 (added germain
language).

This is the first official release of the InstallApacheFlex AIR application.
The official Apache distribution is the source kit which can contain only
source.

The source distributions for Windows and Mac are available here:

https://dist.apache.org/repos/dist/dev/flex/installer/2.5/RC5/sources/

The binary distributions as a convenience for the respective platforms,
available here:

https://dist.apache.org/repos/dist/dev/flex/installer/2.5/RC5/binaries/

Along with the installer, we are releasing the 'badge installer' that can be
embedded in our site as well as third-party websites.  Here is a preview:

http://flex.apache.org/installer.html

*Before voting please review the section,*
"What are the ASF requirements on approving a release?" at
http://www.apache.org/dev/release.html#approving-a-release

*Please vote to approve this release:*

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for at least 72 hours.

Regards,
Om & Justin & Fred
Apache Flex PMC members + Release managers 

RE: Broken release build and git revision numbers

[Michael A. Labriola]

>Can any Git experts please comment if there an alternative to doing this this 
>way.

If you have a moment, take a look at git describe as an idea. It basically 
gives you the latest tag and a number of commits since then and a hash. Its not 
a simple sequence, but see if it helps.

This one is okay.

http://alblue.bandlem.com/2010/11/automatically-tagging-builds-with-git.html

Read Me:

http://git-scm.com/book/en/Distributed-Git-Maintaining-a-Project#Generating-a-Build-Number

RE: Git remote branches

[Michael A. Labriola]

>ie :  origin/FLEX-33451 is still a remote branch - should this be removed and 
>if so what the safest way of doing that?

It can be removed although it won't hurt anything to hang around for a while. I 
honestly google the method to remove it most times:

http://gitready.com/beginner/2009/02/02/push-and-delete-branches.html

>If it is removed what happens to my local branch? 

It won't affect your local branch. That will stay intact and viable.  A branch 
isn't really a separate thing in git. All a branch really is at the end of the 
day is a text file that contains a unique identifier to the commit from which 
it started and a couple of text files describing the tree of the file system. 
So, those can exist locally or be pushed to the server but they are pretty much 
independent.

>Say I still had changes to commit - what then?

Do you mean uncommitted local changes to that branch? If so, commit them :) 
Remember in git land you can commit every 30 seconds. I suspect you mean 
changes to merge in though and honestly that's fine. You can work on your local 
branch for as long as you want and then merge in when ready. If I am missing 
the point, just ask again

Mike

Broken release build and git revision numbers

[Justin Mclean]

Hi,

When we were using SVN the SVN revision number was used in various places. This 
needs to be a number (so hashes are out) and may need to be numerically 
increasing ie current number bigger than last number (not 100% on that).

This effects:
- Version numbers in framework XML description files. eg flex-config.xml.
- Version.as files in the SDK.
- Names of framework RSL files.

For now I'm going to do this:





ie set the build number to the current date.


Can any Git experts please comment if there an alternative to doing this this 
way.

Do any IDEs use the build number form the config is any way that may be broken 
by this approach?

Can anyone see any issue (even minor) with this approach? 

This is a major change to how the SDK is builds, configures and names things so 
could have subtle and unknown side effects.

Thanks,
Justin

RE: Git needs a KISSa

[Michael A. Labriola]

Gordon and Justin,

>I agree that it would be bad to edit 2 files, do a 'git pull' followed by a 
>'git status', and see changes to 200 files from other people mingling with 
>your changes to 2. The simple way to prevent this is to commit your changes 
>before pulling in other people's changes (I think).

Unfortunately that won't prevent it. For now, it's more about just educating 
everyone about merges.

Read this (and the comments if you are brave). [1] What Fred was advocating was 
a rebase workflow. What Gordon is proposing is mostly a merge workflow. That 
latter can work, we use it often, but it puts the onus on the developer doing 
the merge. Incidentally, this is why is most larger open source projects... see 
linux (or even what we did on FlexUnit in git) have a very few number of people 
who knew git well that managed the actual develop and master branches.

The rest of the community happily worked from their own forks (which is 
basically just a server side copy of git all to your own) and just pulled in 
changes from develop, they didn't push to develop. That was the question I was 
originally asking Fred as to if there was a technical reason that we were setup 
this way. Incidentally, Fred did an excellent job on the wiki pages and making 
his case. 

I understand why everyone can see git as a pain right now. I really do. 
Ultimately the active committers on this list need to decide the correct route 
for the project. From my experience, this is the best analogy I can give. 
Please indulge me one last time.

SVN was like a nail and everyone got good at using a hammer to put that nail 
into the wall. Git is a screw. When you start, it's natural to try to pound the 
screw into the wall the same way you did a nail. You can make it work, but it 
will seem cumbersome and inelegant compared to the ease of the nail. You won't 
see any advantages and it won't get any better, although you can make it work. 
If, however, you can begin to see that the screw works differently (and btw, 
that's the big thing git and SVN are honestly night and day in how they work 
and their workflow) and begin carrying the right tool, soon you can see that 
the screw has some advantages. It doesn't replace a nail but for certain 
applications it's much more useful. Look at the success of open source projects 
on github, linux and many others and I promise, we aren't all crazy. There are 
growing pains, but they are not insurmountable. 

I personally wish we had more of a github fork model here where a couple of 
people have the keys to the castle. To be honest, that's what I was envisioning 
when I voted for git. It may not be possible at this point or ever, but the 
result is putting the onus on everyone learning more about git than they might 
otherwise need and having a miserable experience. So, read my link. Ask 
questions and I will answer here whenever possible.

Mike

[1] 
http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/

[jira] [Assigned] (FLEX-33451) The release build due to the Git migration is broken

[Justin Mclean (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLEX-33451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Mclean reassigned FLEX-33451:


Assignee: Justin Mclean

> The release build due to the Git migration is broken
> 
>
> Key: FLEX-33451
> URL: https://issues.apache.org/jira/browse/FLEX-33451
> Project: Apache Flex
>  Issue Type: Bug
>  Components: .Unspecified - Framework
>Affects Versions: Adobe Flex SDK Next
>Reporter: Frédéric THOMAS
>Assignee: Justin Mclean
>Priority: Critical
>  Labels: Git, TLF, build, documentation
>
> The release build due to the Git migration is broken:
> - TLF external build
> - Build Number
> - ASDoc for the experimental lib
> - Building process (.gitignore, empty.properties)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: Git needs a KISS

[Gordon Smith]

>> Okay, at its heart, the danger Fred was worried about is that, using a merge 
>> workflow, the person who pulls the changes needs to make sure they commit 
>> all changes... even files they didn't touch, because they 'inherit' the 
>> merge.

> Do you have any advice on how to get around this issue in a simple way?

I agree that it would be bad to edit 2 files, do a 'git pull' followed by a 
'git status', and see changes to 200 files from other people mingling with your 
changes to 2. The simple way to prevent this is to commit your changes before 
pulling in other people's changes (I think).

- Gordon


-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com] 
Sent: Friday, April 05, 2013 4:07 PM
To: dev@flex.apache.org
Subject: Re: Git needs a KISS

Hi,

> Okay, at its heart, the danger Fred was worried about is that, using a merge 
> workflow, the person who pulls the changes needs to make sure they commit all 
> changes... even files they didn't touch, because they 'inherit' the merge.
Do you have any advice on how to get around this issue in a simple way?

 I would of though that those changes would of already been in develop (99% of 
git pulls/git push are going to be from develop right?). Could this issue occur 
in the develop branch? If so is it easy to recognise that it has occurred and 
what would be the steps to fix it?

> For those new to git, if you are using this workflow, take a look at 
> SmartGit. 
Thanks for the pointer will give it a go.

Thanks,
Justin

Re: Git needs a KISS

[Robert Brendler]

For those new to git ... this is a nice read:
http://tom.preston-werner.com/2009/05/19/the-git-parable.html

Am 06.04.2013 01:06, schrieb Justin Mclean:
> Hi,
>
>> Okay, at its heart, the danger Fred was worried about is that, using a merge 
>> workflow, the person who pulls the changes needs to make sure they commit 
>> all changes... even files they didn't touch, because they 'inherit' the 
>> merge.
> Do you have any advice on how to get around this issue in a simple way?
>
>  I would of though that those changes would of already been in develop (99% 
> of git pulls/git push are going to be from develop right?). Could this issue 
> occur in the develop branch? If so is it easy to recognise that it has 
> occurred and what would be the steps to fix it?
>
>> For those new to git, if you are using this workflow, take a look at 
>> SmartGit. 
> Thanks for the pointer will give it a go.
>
> Thanks,
> Justin


-- 
_ FORMER 03 GmbH
_ infanteriestraße 19 haus 6
_ 80797 muenchen

_ robert.brend...@former03.de
_ www.former03.de

_ fon 089.322112.28
_ fax 089.322112.11

_ geschäftsführer
_ sebastian fiedler
_ gert zellentin

_ handelsregister
_ HRB München 148468

_ steuer
_ ust.-id DE 229107876

_ TWITTER: http://twitter.com/FORMER03
_ FACEBOOK: http://www.facebook.com/former03
_ GOOGLE+: https://plus.google.com/109396067810508286409/posts
_ YOUTUBE: http://www.youtube.com/former03gmbh

Git remote branches

[Justin Mclean]

Hi,

Just noticed this:

 git branch -r
  origin/FLEX-33451
  origin/HEAD -> origin/master
  origin/develop
  origin/master
  origin/patches
  origin/release4.9

ie :  origin/FLEX-33451 is still a remote branch - should this be removed and 
if so what the safest way of doing that?

If it is removed what happens to my local branch? Say I still had changes to 
commit - what then?

 git branch
  FLEX-33451
* develop
  master

Thanks,
Justin

Re: [DICUSS] Release InstallApacheFlex 2.5.4 - RC5 (was: Release InstallApacheFlex 2.5.3 - RC4)

[Justin Mclean]

Hi,

> Is it ok ? Can I process to a Vote ?
Good to go you can call fro a vote.

Justin

Re: Still confused by git

[Justin Mclean]

Hi,

> after 450 emails in March + 3 Wiki pages written to make the people 
> understand and have a good workflow using Git and reading noone cars or wants 
> to learn
I for one appreciated the effort and I have learnt a lot form it. It is a lot 
to take on and it's seemed to become very complex very quickly. I think a 
little patience all around is all that's needed.

Thanks,
Justin

Re: [DICUSS] Release InstallApacheFlex 2.5.4 - RC5 (was: Release InstallApacheFlex 2.5.3 - RC4)

[Justin Mclean]

Hi,

> Is it ok ? Can I process to a Vote ?

Sorry having build issues - not sure if it git related or not. Once I'll sort 
out I'll put up unless someone beats me to it.

Justin

Re: Git needs a KISS

[Justin Mclean]

Hi,

> Okay, at its heart, the danger Fred was worried about is that, using a merge 
> workflow, the person who pulls the changes needs to make sure they commit all 
> changes... even files they didn't touch, because they 'inherit' the merge.
Do you have any advice on how to get around this issue in a simple way?

 I would of though that those changes would of already been in develop (99% of 
git pulls/git push are going to be from develop right?). Could this issue occur 
in the develop branch? If so is it easy to recognise that it has occurred and 
what would be the steps to fix it?

> For those new to git, if you are using this workflow, take a look at 
> SmartGit. 
Thanks for the pointer will give it a go.

Thanks,
Justin

[jira] [Comment Edited] (FLEX-33451) The release build due to the Git migration is broken

[Justin Mclean (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLEX-33451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13624148#comment-13624148
 ] 

Justin Mclean edited comment on FLEX-33451 at 4/5/13 10:57 PM:
---

Not completed yet. No need to open new issue it's better to keep all info in 
one issue.

  was (Author: jmclean):
Not completed yet. No need to open new issue better if it's keep all in 
issue.
  
> The release build due to the Git migration is broken
> 
>
> Key: FLEX-33451
> URL: https://issues.apache.org/jira/browse/FLEX-33451
> Project: Apache Flex
>  Issue Type: Bug
>  Components: .Unspecified - Framework
>Affects Versions: Adobe Flex SDK Next
>Reporter: Frédéric THOMAS
>Priority: Critical
>  Labels: Git, TLF, build, documentation
>
> The release build due to the Git migration is broken:
> - TLF external build
> - Build Number
> - ASDoc for the experimental lib
> - Building process (.gitignore, empty.properties)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (FLEX-33435) Fix web site pages to describe how to use GIT to check out and build Apache Flex rather than SVN

[Justin Mclean (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLEX-33435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Mclean reopened FLEX-33435:
--

  Assignee: (was: Frédéric THOMAS)

Documentation for making a release still not complete

> Fix web site pages to describe how to use GIT to check out and build Apache 
> Flex rather than SVN 
> -
>
> Key: FLEX-33435
> URL: https://issues.apache.org/jira/browse/FLEX-33435
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Web Site
>Reporter: Justin Mclean
>
> Pages that need updating include:
> http://flex.apache.org/dev-faq.html
> http://flex.apache.org/dev-sourcecode.html
> http://flex.apache.org/download-source.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (FLEX-33451) The release build due to the Git migration is broken

[Justin Mclean (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLEX-33451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Mclean reopened FLEX-33451:
--

  Assignee: (was: Frédéric THOMAS)

Not completed yet. No need to open new issue better if it's keep all in issue.

> The release build due to the Git migration is broken
> 
>
> Key: FLEX-33451
> URL: https://issues.apache.org/jira/browse/FLEX-33451
> Project: Apache Flex
>  Issue Type: Bug
>  Components: .Unspecified - Framework
>Affects Versions: Adobe Flex SDK Next
>Reporter: Frédéric THOMAS
>Priority: Critical
>  Labels: Git, TLF, build, documentation
>
> The release build due to the Git migration is broken:
> - TLF external build
> - Build Number
> - ASDoc for the experimental lib
> - Building process (.gitignore, empty.properties)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] [Commented] (FLEX-33273) CSSCondition.matchesStyleClient() is slow and creates excessive garbage

[Om]

Send a blank email to dev-unsubscr...@flex.apache.org to unsubscribe from
the dev list.

Thanks,
Om

On Fri, Apr 5, 2013 at 11:57 AM, sujith Reddy  wrote:

> Please remove me out of these emails.
> I entered here by mistake.
>
> Thanks,
> Sujith
>
>
> On Mon, Feb 4, 2013 at 8:07 PM, RJ Camarillo (JIRA) 
> wrote:
>
> >
> > [
> >
> https://issues.apache.org/jira/browse/FLEX-33273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570902#comment-13570902
> ]
> >
> > RJ Camarillo commented on FLEX-33273:
> > -
> >
> > I don't see the changes for this in the trunk. Was it reverted?
> >
> > > CSSCondition.matchesStyleClient() is slow and creates excessive garbage
> > > ---
> > >
> > > Key: FLEX-33273
> > > URL: https://issues.apache.org/jira/browse/FLEX-33273
> > > Project: Apache Flex
> > >  Issue Type: Improvement
> > >  Components: Styles
> > >Affects Versions: Adobe Flex SDK 4.1 (Release), Adobe Flex SDK 4.5
> > (Release), Adobe Flex SDK 4.5.1 (Release), Adobe Flex SDK 4.6 (Release)
> > >Reporter: Maurice Nicholson
> > >Assignee: Frédéric THOMAS
> > >  Labels: patch, performance
> > > Attachments: FLEX-33273.patch, PerformanceTest.zip
> > >
> > >
> > > CSSCondition.matchesStyleClient() is called *very* frequently during
> > layout of components in many different scenarios.
> > > I've done a lot of profiling of Flex apps and it comes up again and
> > again.
> > > The current implementation is slow and creates unnecessary garbage
> > (which slows down the runtime further, since it needs to collect the
> > garbage instead of doing more useful things).
> > > Here is the current implementation:
> > > {code}
> > > public function
> > matchesStyleClient(object:IAdvancedStyleClient):Boolean
> > > {
> > > var match:Boolean = false;
> > > if (kind == CSSConditionKind.CLASS)
> > > {
> > > if (object.styleName != null && object.styleName is String)
> > > {
> > > // Look for a match in a potential list of styleNames
> > > var styleNames:Array = object.styleName.split(/\s+/);
> > > for (var i:uint = 0; i < styleNames.length; i++)
> > > {
> > > if (styleNames[i] == value)
> > > {
> > > match = true;
> > > break;
> > > }
> > > }
> > > }
> > > }
> > > else if (kind == CSSConditionKind.ID)
> > > {
> > > if (object.id == value)
> > > match = true;
> > > }
> > > else if (kind == CSSConditionKind.PSEUDO)
> > > {
> > > if (object.matchesCSSState(value))
> > > match = true;
> > > }
> > > return match;
> > > }
> > > {code}
> > > Here is what I suggest instead:
> > > {code}
> > > public function
> > matchesStyleClient(object:IAdvancedStyleClient):Boolean
> > > {
> > > var match:Boolean = false;
> > > if (kind == CSSConditionKind.CLASS)
> > > {
> > > const styleName:String = object.styleName as String;
> > > if (styleName)
> > > {
> > > // Look for a match in a potential list of styleNames
> > > FIND:
> > > {
> > > var index:int = styleName.indexOf(value);
> > > if (index == -1)
> > > {
> > > break FIND;
> > > }
> > > if (index != 0 && styleName.charAt(index - 1) != '
> ')
> > > {
> > > break FIND;
> > > }
> > > const next:int = index + value.length;
> > > if (next != styleName.length &&
> > styleName.charAt(next) != ' ')
> > > {
> > > break FIND;
> > > }
> > > match = true;
> > > }
> > > }
> > > }
> > > else if (kind == CSSConditionKind.ID)
> > > {
> > > if (object.id == value)
> > > match = true;
> > > }
> > > else if (kind == CSSConditionKind.PSEUDO)
> > > {
> > > if (object.matchesCSSState(value))
> > > match = true;
> > > }
> > > return match;
> > > }
> > > {code}
> > > There are obviously more concise ways to express this code, but the
> > above seems to match the current style more or less.
> > > Here is the output from a benchmark I created using Grant Skinner's
> > PerformanceTest v2 Beta, comparing the current version and the suggest

Re: [jira] [Commented] (FLEX-33273) CSSCondition.matchesStyleClient() is slow and creates excessive garbage

[sujith Reddy]

Please remove me out of these emails.
I entered here by mistake.

Thanks,
Sujith


On Mon, Feb 4, 2013 at 8:07 PM, RJ Camarillo (JIRA)  wrote:

>
> [
> https://issues.apache.org/jira/browse/FLEX-33273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570902#comment-13570902]
>
> RJ Camarillo commented on FLEX-33273:
> -
>
> I don't see the changes for this in the trunk. Was it reverted?
>
> > CSSCondition.matchesStyleClient() is slow and creates excessive garbage
> > ---
> >
> > Key: FLEX-33273
> > URL: https://issues.apache.org/jira/browse/FLEX-33273
> > Project: Apache Flex
> >  Issue Type: Improvement
> >  Components: Styles
> >Affects Versions: Adobe Flex SDK 4.1 (Release), Adobe Flex SDK 4.5
> (Release), Adobe Flex SDK 4.5.1 (Release), Adobe Flex SDK 4.6 (Release)
> >Reporter: Maurice Nicholson
> >Assignee: Frédéric THOMAS
> >  Labels: patch, performance
> > Attachments: FLEX-33273.patch, PerformanceTest.zip
> >
> >
> > CSSCondition.matchesStyleClient() is called *very* frequently during
> layout of components in many different scenarios.
> > I've done a lot of profiling of Flex apps and it comes up again and
> again.
> > The current implementation is slow and creates unnecessary garbage
> (which slows down the runtime further, since it needs to collect the
> garbage instead of doing more useful things).
> > Here is the current implementation:
> > {code}
> > public function
> matchesStyleClient(object:IAdvancedStyleClient):Boolean
> > {
> > var match:Boolean = false;
> > if (kind == CSSConditionKind.CLASS)
> > {
> > if (object.styleName != null && object.styleName is String)
> > {
> > // Look for a match in a potential list of styleNames
> > var styleNames:Array = object.styleName.split(/\s+/);
> > for (var i:uint = 0; i < styleNames.length; i++)
> > {
> > if (styleNames[i] == value)
> > {
> > match = true;
> > break;
> > }
> > }
> > }
> > }
> > else if (kind == CSSConditionKind.ID)
> > {
> > if (object.id == value)
> > match = true;
> > }
> > else if (kind == CSSConditionKind.PSEUDO)
> > {
> > if (object.matchesCSSState(value))
> > match = true;
> > }
> > return match;
> > }
> > {code}
> > Here is what I suggest instead:
> > {code}
> > public function
> matchesStyleClient(object:IAdvancedStyleClient):Boolean
> > {
> > var match:Boolean = false;
> > if (kind == CSSConditionKind.CLASS)
> > {
> > const styleName:String = object.styleName as String;
> > if (styleName)
> > {
> > // Look for a match in a potential list of styleNames
> > FIND:
> > {
> > var index:int = styleName.indexOf(value);
> > if (index == -1)
> > {
> > break FIND;
> > }
> > if (index != 0 && styleName.charAt(index - 1) != ' ')
> > {
> > break FIND;
> > }
> > const next:int = index + value.length;
> > if (next != styleName.length &&
> styleName.charAt(next) != ' ')
> > {
> > break FIND;
> > }
> > match = true;
> > }
> > }
> > }
> > else if (kind == CSSConditionKind.ID)
> > {
> > if (object.id == value)
> > match = true;
> > }
> > else if (kind == CSSConditionKind.PSEUDO)
> > {
> > if (object.matchesCSSState(value))
> > match = true;
> > }
> > return match;
> > }
> > {code}
> > There are obviously more concise ways to express this code, but the
> above seems to match the current style more or less.
> > Here is the output from a benchmark I created using Grant Skinner's
> PerformanceTest v2 Beta, comparing the current version and the suggested
> version:
> > {noformat}
> > Comparing speed of matching a string in space delimited string. 100
> loops.
> > Test   Old ms
> New ms Speedup  Old mem  New mem  Change
> > matchesStyleClient(styleName: "foo", value: "foo")1006.00
> 181.00   -82.0   123.00 0.00  -100.0
> > matchesStyleClient(styleName: "foo bar", value: "foo")   

RE: Git needs a KISS

[Michael A. Labriola]

>I think we made a serious mistake by pushing the nvie branching model 
>(http://nvie.com/posts/a-successful-git-branching-model/) 

First, we aren't using that branching model. Not even close. That model defines 
a viable workflow that we use successfully on many projects open and internal 
(5 to 500 people). What we have is a single git repo, and people who are new to 
git fighting over how to use the develop branch. I disagree with a lot of what 
you have said in the rest of your message honestly. However, I am not actively 
committing code and others are. I do think you can keep things simple. To be 
clear, there is a danger in what you mentioned, and it was what Fred was trying 
to address. So, let me mainly discuss that.

>>
1. Edit your files. No Git command required.
2. Merge in other people's work with 'git pull'.
3. If there a merge conflicts, fix them by editing. No Git command required.
4. See what files you've changed or added with 'git status'.
5. See what you've changed in a file with 'git diff '.
6. Commit (to your local repo) what you've done with 'git commit -a'.
7. Share what you've done (in the public repo) with 'git push'.
>>

Okay, at its heart, the danger Fred was worried about is that, using a merge 
workflow, the person who pulls the changes needs to make sure they commit all 
changes... even files they didn't touch, because they 'inherit' the merge. So, 
the thing that just needs to be made exceptionally clear on step 6 is that... 
even if they don't believe they touched the file they need to make sure it 
gets committed.

For those new to git, if you are using this workflow, take a look at SmartGit. 
Its free to work on open source projects AND, mostly importantly, it would work 
find with the workflow you are proposing. It also handles merges well, which is 
going to be needed in this model.

That my 2 cents. You can take this any way you want, I simply wanted to 
elucidate the one major danger that Fred was trying to fix. If users aren't 
careful in step 6, they end up committing a merge without someone elses change.

Mike

Flex SDK & Video access via CameraRoll/CameraUI & local video access

[Christian M. Cepel]

I'm not certain how things stand with Apache incubating Flex and Adobe
developing AIR.

I'm wondering if this is something on the radar as far as the SDK
development team goes, and if so, where it might stand, what we might
expect.  The below is specifically regarding iOS, but the non-existing API
methods of course

Specifically, the SDK lacks any way to

   - CameraRoll.browseForVideo() similar to CameraRoll.browseForImage()
   - Using the CameraUI to take a video creates a file in the system tmp
   that is not immediately available w/o first using FileIO to move it
   elsewhere.
   - Directly/simply accessing local video on the filesystem without
   involving a far more complex server/streaming model that is simply
   unnecessary (so far as I understand things)
   - Harvest frame BitmapData directly for display of thumbnails

I've, personally had no luck with using Video or StageVideo to simply
display a video file on the local file system that was -created/captured-
using the delegated system level functionality.  More directly stated...
Native Video format doesn't seem to be playable on the device that created
it (though this may just be my shortcomings as a developer).

So... I can create videos using the delegated system camera util, but not
play them.  I can create videos outside of my software using the system
camera which are then stored in the system CameraRoll, but I can in no ways
use the existing native functionality to browse and select those videos in
the way I can images.

Is any of this being addressed?

ANEs seem to be my only solution, but I've not found what I need so far and
I've absolutely no time to dedicate to learning a new technology.

Cheers.

-- 
// Christian M. Cepel - Programmer/Analyst, Sr., University of Missouri


*And the wrens have returned, and are nesting;*

*In the hollow of that oak, where his heart once had been.*

*And he lifts up his arms in a blessing, for being born again.*

Rich Mullins, The Color Green, A Liturgy, a Legacy, & a Ragamuffin Band

Re: Git needs a KISS

[Om]

On Fri, Apr 5, 2013 at 10:27 AM, Gordon Smith  wrote:

> KISS = Keep It Simple, Stupid
>
> We've gotten ourselves in a hole where contributors are overwhelmed by the
> complexity of our recommended Git workflows and command lines. We need to
> dig ourselves out, and quickly, before we lose momentum.
>
> I don't think we should move back to Subversion, but I think we accept
> that many people would prefer a radically simpler approach to Git which is
> more like the one we were used to in Subversion.
>
> I think we made a serious mistake by pushing the nvie branching model (
> http://nvie.com/posts/a-successful-git-branching-model/) Just looking at
> the first diagram makes me want to close the page. This is overkill if all
> you're doing is fixing a bug or adding a test or something simple. The only
> part of nvie that should be mandatory is "Don't' do any work on the
> 'master' branch". It should be fine for most contributors to check out the
> 'develop' branch and do all their work there.
>
> Most contributors shouldn't need to worry about using Git's "stage" or
> "index". They can just "commit all". You only need to stage things when you
> DON'T want to commit everything you've done. How often is that?
>
> We SHOULD NOT CARE if there are extra merge commits in the log. That's the
> way Git naturally works. Using obscure and controversial command line
> options to "keep the log clean" is not worth it, especially if it makes it
> harder for people to use visual Git clients. Many people, including me, do
> not enjoy working on the command line (although that's how I'm currently
> using Git).
>
> With a KISS approach, what most people need to know to use Git each day,
> after they've cloned the repo and checked out the develop branch, can be
> really simple:
>
> 1. Edit your files. No Git command required.
> 2. Merge in other people's work with 'git pull'.
> 3. If there a merge conflicts, fix them by editing. No Git command
> required.
> 4. See what files you've changed or added with 'git status'.
> 5. See what you've changed in a file with 'git diff '.
> 6. Commit (to your local repo) what you've done with 'git commit -a'.
> 7. Share what you've done (in the public repo) with 'git push'.
>
> Note: There are only 7 steps. It's lore in cognitive science that people
> can remember 7 things but not necessarily more.
>
> Note: The only command-line option is -a to commit all your changes. All
> of these commands are probably available through any Git GUI.
>
> If you are working on a significant feature with a group of people over a
> period of time, then learning more about Git so that you can work together
> on a separate branch makes sense.  But many contributors just want to make
> small changes, and the above workflow should suffice.
>
> If this KISS approach resonates, I'd like to have a poll on it.
>
> - Gordon
>
>

+1 to everything you said :-)

The key here is that there are people here with varying level of expertise
with Git.  Expecting a newbie to learn and understand the uber commands is
not reasonable.  Let us roll with the KISS strategy, let everyone get
onboard with the Git philosophy.  All the advanced commands can be learned
as needed.

Thanks,
Om

Git needs a KISS

[Gordon Smith]

KISS = Keep It Simple, Stupid

We've gotten ourselves in a hole where contributors are overwhelmed by the 
complexity of our recommended Git workflows and command lines. We need to dig 
ourselves out, and quickly, before we lose momentum.

I don't think we should move back to Subversion, but I think we accept that 
many people would prefer a radically simpler approach to Git which is more like 
the one we were used to in Subversion.

I think we made a serious mistake by pushing the nvie branching model 
(http://nvie.com/posts/a-successful-git-branching-model/) Just looking at the 
first diagram makes me want to close the page. This is overkill if all you're 
doing is fixing a bug or adding a test or something simple. The only part of 
nvie that should be mandatory is "Don't' do any work on the 'master' branch". 
It should be fine for most contributors to check out the 'develop' branch and 
do all their work there.

Most contributors shouldn't need to worry about using Git's "stage" or "index". 
They can just "commit all". You only need to stage things when you DON'T want 
to commit everything you've done. How often is that?

We SHOULD NOT CARE if there are extra merge commits in the log. That's the way 
Git naturally works. Using obscure and controversial command line options to 
"keep the log clean" is not worth it, especially if it makes it harder for 
people to use visual Git clients. Many people, including me, do not enjoy 
working on the command line (although that's how I'm currently using Git).

With a KISS approach, what most people need to know to use Git each day, after 
they've cloned the repo and checked out the develop branch, can be really 
simple:

1. Edit your files. No Git command required.
2. Merge in other people's work with 'git pull'.
3. If there a merge conflicts, fix them by editing. No Git command required.
4. See what files you've changed or added with 'git status'.
5. See what you've changed in a file with 'git diff '.
6. Commit (to your local repo) what you've done with 'git commit -a'.
7. Share what you've done (in the public repo) with 'git push'.

Note: There are only 7 steps. It's lore in cognitive science that people can 
remember 7 things but not necessarily more.

Note: The only command-line option is -a to commit all your changes. All of 
these commands are probably available through any Git GUI.

If you are working on a significant feature with a group of people over a 
period of time, then learning more about Git so that you can work together on a 
separate branch makes sense.  But many contributors just want to make small 
changes, and the above workflow should suffice.

If this KISS approach resonates, I'd like to have a poll on it.

- Gordon

Re: [DISCUSS] How do we want to handle Whiteboard?

[Om]

On Thu, Apr 4, 2013 at 11:23 PM, Justin Mclean wrote:

> Hi,
>
> Assuming we get the git hub mirrors up and working there nothing stopping
> anyone from using github to supply patches and diff in the usual way. A git
> hub pull request can be converted directly into a patch file and applied
> easily.
>
> There's one outstanding issue in how do we close pull requests, I asked
> this before but no one seem to know the answer.
>
>
I am confused, how is this related to the current topic under discussion?


> I don't think it would be possible to use github for the "official"
> whiteboards as it brings up a number of issues for infra and the ASF ie
> knowing who contributed, licensing issues etc etc basically the normal
> issues for bit of donated code.
>

GitHub keeps track of everything.  Code that goes into the whiteboard is
generally unstructured, experimental code.  Only the committer decides when
that goes into an official repo.  This has to be done manually and the
commit comments should have all the information about who contributed to
this piece of code.  Which means that we cannot bring the GitHub history
with us as well.  I dont see the need for that.  If someone wants to see
the history, they can always go to the relevant GitHub repo and look at it.


Thanks,
Om


>
> Thanks,
> Justin

Re: [DISCUSS] How do we want to handle Whiteboard?

[Nicholas Kwiatkowski]

A lot of the people who currently have whiteboards have copies of the SDK
in there...  Would it still be possible to work on a private copy of the
SDK in the whiteboard?   The way I see it happening would be that you would
fork the main SDK, and work on it in your own fork rather than the
whiteboard...  The other issue would be to bring the code back to the asf
repo -- I could see that as problematic as well.

-Nick

On Fri, Apr 5, 2013 at 2:23 AM, Justin Mclean wrote:

> Hi,
>
> Assuming we get the git hub mirrors up and working there nothing stopping
> anyone from using github to supply patches and diff in the usual way. A git
> hub pull request can be converted directly into a patch file and applied
> easily.
>
> There's one outstanding issue in how do we close pull requests, I asked
> this before but no one seem to know the answer.
>
> I don't think it would be possible to use github for the "official"
> whiteboards as it brings up a number of issues for infra and the ASF ie
> knowing who contributed, licensing issues etc etc basically the normal
> issues for bit of donated code.
>
> Thanks,
> Justin

Re: Website staging?

[Nicholas Kwiatkowski]

One day we need to clean up the wiki.  It's half really-old crap that
should be purged (or updated), and half really useful stuff.  The problem
is that if you just glance at it, you see stale stuff and write it off.  We
should get better at that.

-Nick

On Fri, Apr 5, 2013 at 10:14 AM, Harbs  wrote:

> I gotta remember to look at the wiki more… ;-)
>
> Thanks!
>
> On Apr 5, 2013, at 5:10 PM, Nicholas Kwiatkowski wrote:
>
> > Information about the website, and how to update your about page profile
> is
> > here :
> >
> https://cwiki.apache.org/confluence/display/FLEX/Updating+your+profile+on+Team+page
> >
> > But yes, there is a staging server, and there is a script to push it to
> > production.
> >
> > -Nick
> >
> > On Fri, Apr 5, 2013 at 9:35 AM, Harbs  wrote:
> >
> >> I'm adding my personal info to the "about" page. Is this supposed to be
> >> deployed to some staging are first, or does it get pushed out directly
> to
> >> the live site?
> >>
> >> Harbs
>
>

Re: Website staging?

[Harbs]

I gotta remember to look at the wiki more… ;-)

Thanks!

On Apr 5, 2013, at 5:10 PM, Nicholas Kwiatkowski wrote:

> Information about the website, and how to update your about page profile is
> here :
> https://cwiki.apache.org/confluence/display/FLEX/Updating+your+profile+on+Team+page
> 
> But yes, there is a staging server, and there is a script to push it to
> production.
> 
> -Nick
> 
> On Fri, Apr 5, 2013 at 9:35 AM, Harbs  wrote:
> 
>> I'm adding my personal info to the "about" page. Is this supposed to be
>> deployed to some staging are first, or does it get pushed out directly to
>> the live site?
>> 
>> Harbs

Re: Website staging?

[Nicholas Kwiatkowski]

Information about the website, and how to update your about page profile is
here :
https://cwiki.apache.org/confluence/display/FLEX/Updating+your+profile+on+Team+page

But yes, there is a staging server, and there is a script to push it to
production.

-Nick

On Fri, Apr 5, 2013 at 9:35 AM, Harbs  wrote:

> I'm adding my personal info to the "about" page. Is this supposed to be
> deployed to some staging are first, or does it get pushed out directly to
> the live site?
>
> Harbs

Re: Website staging?

[Harbs]

Thanks. Very helpful.

On Apr 5, 2013, at 4:47 PM, Erik de Bruin wrote:

> Any changes you commit to SVN (don't ask ;-)) will be automatically
> pushed to the staging site by the 'buildbot'. You can view the staging
> area here:
> 
> http://flex.staging.apache.org/
> 
> Once you're satisfied with the changes, you can promote them here:
> 
> https://cms.apache.org/flex/publish
> 
> HTH,
> 
> EdB
> 
> 
> 
> On Fri, Apr 5, 2013 at 8:35 AM, Harbs  wrote:
>> I'm adding my personal info to the "about" page. Is this supposed to be 
>> deployed to some staging are first, or does it get pushed out directly to 
>> the live site?
>> 
>> Harbs
> 
> 
> 
> -- 
> Ix Multimedia Software
> 
> Jan Luykenstraat 27
> 3521 VB Utrecht
> 
> T. 06-51952295
> I. www.ixsoftware.nl

Re: Website staging?

[Erik de Bruin]

Any changes you commit to SVN (don't ask ;-)) will be automatically
pushed to the staging site by the 'buildbot'. You can view the staging
area here:

http://flex.staging.apache.org/

Once you're satisfied with the changes, you can promote them here:

https://cms.apache.org/flex/publish

HTH,

EdB



On Fri, Apr 5, 2013 at 8:35 AM, Harbs  wrote:
> I'm adding my personal info to the "about" page. Is this supposed to be 
> deployed to some staging are first, or does it get pushed out directly to the 
> live site?
>
> Harbs



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Website staging?

[Harbs]

I'm adding my personal info to the "about" page. Is this supposed to be 
deployed to some staging are first, or does it get pushed out directly to the 
live site?

Harbs

Re: Still confused by git

[Harbs]

In my quest to understand what's going on, maybe you can explain something to 
me.

Most of your commits are flat in the graph, but a couple of them show as 
branches that are remerged. One example is FLEX-33451

Can you explain to me why that is?

On Apr 5, 2013, at 4:01 PM, Frédéric THOMAS wrote:

> That's a good idea, I'm going to sit on the sideline too until at least PMCs 
> want to learn the 10 basic commands and know how to use Git as describe, I 
> just wonder how are going to react contributors and committers if even PMCs 
> don't show the good example, well, to say the truth, I'm fed up, after 450 
> emails in March + 3 Wiki pages written to make the people understand and have 
> a good workflow using Git and reading noone cars or wants to learn, I don't 
> want to fight anymore and not even work on the SDK tree.
> 
> Well, I already did my boxes closing the resolved JIRA, unassigned the others 
> and committed my remote branch.
> 
> I wish you a lot of pleasure.
> 
> -Fred
> 
> -Message d'origine- From: Nicholas Kwiatkowski
> Sent: Friday, April 05, 2013 2:11 PM
> To: dev@flex.apache.org
> Subject: Re: Still confused by git
> 
> +1 on this.  I've been sitting on the sidelines the last few weeks for that
> reason.  I know there are a lot of standards that still need to be figured
> out, and since I'm very green with GIT, I don't really have the time at the
> moment to learn all the command line (i've been really busy with personal
> and professional stuff the last few weeks as well).  My goal is not to use
> the command line, but use my IDE like I did before.  Dropping to the
> command line and typing 10 commands every time I want to do something is a
> pain in the rear for those things that my IDE should be doing for me (I
> usually have a dozen command prompt windows open at any given time, but
> those are for truly interactive things).
> 
> -Nick
> 
> On Fri, Apr 5, 2013 at 5:44 AM, Justin Mclean wrote:
> 
>> Hi,
>> 
>> > There's also been a lot of discussion on when to rebase and when not.
>> I'm not clear on whether there has been a consensus on that.
>> I don't believe there is a consensus but that's mostly around how
>> important it is to keep a "clean" history and with respect to  Frederic
>> obvious knowledge in this area we still need to come up with a way people
>> new to git can contribute without knowing every intricate details of
>> obscure options to git commands. In part because not everyone will use the
>> command line.
>> 
>> Thanks,
>> Justin 
> 

Re: Still confused by git

[Nicholas Kwiatkowski]

That's not what I meant.  It's in my plans to learn GIT, but I'm not going
to be productive learning a new workflow with my 80+ hours of my FT job the
last three weeks.  My cheese was moved, and while I was trying to catch up
the were still discussions about how to do things and what the standards
were while I was trying to learn it.  For me, the problem was the 450
emails over multiple threads that I couldn't keep up on.

Personally I hate that everything relies on gitbash to do most commands
under Windows.  on my machine it's broken (hell, copy/paste only works half
the time), so I'm always in the mode of trying to translate how to do X in
an environment I'm not familiar with, on a complex project I could easily
blow up, into something that at least lets me access my storage device
where I'm supposed to be working.  Nothing against you -- you've been
helping out A LOT, but I'm just not up to speed yet.

-Nick

On Fri, Apr 5, 2013 at 9:01 AM, Frédéric THOMAS wrote:

> That's a good idea, I'm going to sit on the sideline too until at least
> PMCs want to learn the 10 basic commands and know how to use Git as
> describe, I just wonder how are going to react contributors and committers
> if even PMCs don't show the good example, well, to say the truth, I'm fed
> up, after 450 emails in March + 3 Wiki pages written to make the people
> understand and have a good workflow using Git and reading noone cars or
> wants to learn, I don't want to fight anymore and not even work on the SDK
> tree.
>
> Well, I already did my boxes closing the resolved JIRA, unassigned the
> others and committed my remote branch.
>
> I wish you a lot of pleasure.
>
> -Fred
>
> -Message d'origine- From: Nicholas Kwiatkowski
> Sent: Friday, April 05, 2013 2:11 PM
>
> To: dev@flex.apache.org
> Subject: Re: Still confused by git
>
> +1 on this.  I've been sitting on the sidelines the last few weeks for that
> reason.  I know there are a lot of standards that still need to be figured
> out, and since I'm very green with GIT, I don't really have the time at the
> moment to learn all the command line (i've been really busy with personal
> and professional stuff the last few weeks as well).  My goal is not to use
> the command line, but use my IDE like I did before.  Dropping to the
> command line and typing 10 commands every time I want to do something is a
> pain in the rear for those things that my IDE should be doing for me (I
> usually have a dozen command prompt windows open at any given time, but
> those are for truly interactive things).
>
> -Nick
>
> On Fri, Apr 5, 2013 at 5:44 AM, Justin Mclean **
> wrote:
>
>  Hi,
>>
>> > There's also been a lot of discussion on when to rebase and when not.
>> I'm not clear on whether there has been a consensus on that.
>> I don't believe there is a consensus but that's mostly around how
>> important it is to keep a "clean" history and with respect to  Frederic
>> obvious knowledge in this area we still need to come up with a way people
>> new to git can contribute without knowing every intricate details of
>> obscure options to git commands. In part because not everyone will use the
>> command line.
>>
>> Thanks,
>> Justin
>>
>
>

Re: Still confused by git

[Harbs]

I'm sorry if I caused you to be fed up. I don't think it's that no-one cares or 
wants to learn. It's just that most of us have never used git before, and we 
have no clue what we're doing. It's a bit unnerving learning on such a big code 
base. I'm sure learning the basics of of git on a small project would be a lot 
easier…

On Apr 5, 2013, at 4:01 PM, Frédéric THOMAS wrote:

> That's a good idea, I'm going to sit on the sideline too until at least PMCs 
> want to learn the 10 basic commands and know how to use Git as describe, I 
> just wonder how are going to react contributors and committers if even PMCs 
> don't show the good example, well, to say the truth, I'm fed up, after 450 
> emails in March + 3 Wiki pages written to make the people understand and have 
> a good workflow using Git and reading noone cars or wants to learn, I don't 
> want to fight anymore and not even work on the SDK tree.
> 
> Well, I already did my boxes closing the resolved JIRA, unassigned the others 
> and committed my remote branch.
> 
> I wish you a lot of pleasure.
> 
> -Fred
> 
> -Message d'origine- From: Nicholas Kwiatkowski
> Sent: Friday, April 05, 2013 2:11 PM
> To: dev@flex.apache.org
> Subject: Re: Still confused by git
> 
> +1 on this.  I've been sitting on the sidelines the last few weeks for that
> reason.  I know there are a lot of standards that still need to be figured
> out, and since I'm very green with GIT, I don't really have the time at the
> moment to learn all the command line (i've been really busy with personal
> and professional stuff the last few weeks as well).  My goal is not to use
> the command line, but use my IDE like I did before.  Dropping to the
> command line and typing 10 commands every time I want to do something is a
> pain in the rear for those things that my IDE should be doing for me (I
> usually have a dozen command prompt windows open at any given time, but
> those are for truly interactive things).
> 
> -Nick
> 
> On Fri, Apr 5, 2013 at 5:44 AM, Justin Mclean wrote:
> 
>> Hi,
>> 
>> > There's also been a lot of discussion on when to rebase and when not.
>> I'm not clear on whether there has been a consensus on that.
>> I don't believe there is a consensus but that's mostly around how
>> important it is to keep a "clean" history and with respect to  Frederic
>> obvious knowledge in this area we still need to come up with a way people
>> new to git can contribute without knowing every intricate details of
>> obscure options to git commands. In part because not everyone will use the
>> command line.
>> 
>> Thanks,
>> Justin 
> 

RE: Still confused by git

[Kessler CTR Mark J]

   Well the GUI's offer the same commands, they just have check boxes n such to 
select the different options of the command.  I don't think it should matters 
if people learn the command line or GUI versions.  Understanding what the  
commands do will happen more with practice.   Reading the GIT online resources 
for the diagrams (example of one command [1])  helps to small degree.

   Should we setup a junk repo for people to play with the commands? (a shared 
one like on a GITHub repo).  I know people could go out and setup their own.  
But I mean a structured one with populated content that gets reset to a known 
state weekly or after its been used.  It could allow for practiced scenarios.


[1] http://git-scm.com/book/en/Git-Branching-Rebasing 

-Mark

-Original Message-
From: Nicholas Kwiatkowski [mailto:nicho...@spoon.as] 
Sent: Friday, April 05, 2013 8:11 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

+1 on this.  I've been sitting on the sidelines the last few weeks for that
reason.  I know there are a lot of standards that still need to be figured
out, and since I'm very green with GIT, I don't really have the time at the
moment to learn all the command line (i've been really busy with personal
and professional stuff the last few weeks as well).  My goal is not to use
the command line, but use my IDE like I did before.  Dropping to the
command line and typing 10 commands every time I want to do something is a
pain in the rear for those things that my IDE should be doing for me (I
usually have a dozen command prompt windows open at any given time, but
those are for truly interactive things).

-Nick

Re: Still confused by git

[Frédéric THOMAS]

That's a good idea, I'm going to sit on the sideline too until at least PMCs 
want to learn the 10 basic commands and know how to use Git as describe, I 
just wonder how are going to react contributors and committers if even PMCs 
don't show the good example, well, to say the truth, I'm fed up, after 450 
emails in March + 3 Wiki pages written to make the people understand and 
have a good workflow using Git and reading noone cars or wants to learn, I 
don't want to fight anymore and not even work on the SDK tree.


Well, I already did my boxes closing the resolved JIRA, unassigned the 
others and committed my remote branch.


I wish you a lot of pleasure.

-Fred

-Message d'origine- 
From: Nicholas Kwiatkowski

Sent: Friday, April 05, 2013 2:11 PM
To: dev@flex.apache.org
Subject: Re: Still confused by git

+1 on this.  I've been sitting on the sidelines the last few weeks for that
reason.  I know there are a lot of standards that still need to be figured
out, and since I'm very green with GIT, I don't really have the time at the
moment to learn all the command line (i've been really busy with personal
and professional stuff the last few weeks as well).  My goal is not to use
the command line, but use my IDE like I did before.  Dropping to the
command line and typing 10 commands every time I want to do something is a
pain in the rear for those things that my IDE should be doing for me (I
usually have a dozen command prompt windows open at any given time, but
those are for truly interactive things).

-Nick

On Fri, Apr 5, 2013 at 5:44 AM, Justin Mclean 
wrote:



Hi,

> There's also been a lot of discussion on when to rebase and when not.
I'm not clear on whether there has been a consensus on that.
I don't believe there is a consensus but that's mostly around how
important it is to keep a "clean" history and with respect to  Frederic
obvious knowledge in this area we still need to come up with a way people
new to git can contribute without knowing every intricate details of
obscure options to git commands. In part because not everyone will use the
command line.

Thanks,
Justin 

Re: [DICUSS] Release InstallApacheFlex 2.5.4 - RC5 (was: Release InstallApacheFlex 2.5.3 - RC4)

[Frédéric THOMAS]

Is it ok ? Can I process to a Vote ?

-Fred

-Message d'origine- 
From: Frédéric THOMAS

Sent: Thursday, April 04, 2013 10:20 PM
To: dev@flex.apache.org
Subject: [DICUSS] Release InstallApacheFlex 2.5.4 - RC5 (was: Release 
InstallApacheFlex 2.5.3 - RC4)


Hi Justin,

I Just checked in the updated version of the installer RC5 with the release
builds for windows, could you build the Mac version please.

Thanks,
-Fred

-Message d'origine- 
From: Frédéric THOMAS

Sent: Monday, April 01, 2013 9:00 AM
To: dev@flex.apache.org
Subject: Re: [DICUSS] Release InstallApacheFlex 2.5.3 - RC4

Ok, let's keep the same quality :) I go for a RC5, just the time for more
testing though, I wouldn't like to do another RC after each typo issue.

-Fred

-Message d'origine- 
From: Alex Harui

Sent: Monday, April 01, 2013 8:37 AM
To: dev@flex.apache.org
Subject: Re: [DICUSS] Release InstallApacheFlex 2.5.3 - RC4




On 3/31/13 11:16 PM, "Frédéric THOMAS"  wrote:


Some German typo only.

Yeah, so you and Justin have to decide on whether to run another RC.  How
would you feel if there was a typo only in French?  At Adobe we would not
release with a known typo, but this isn't Adobe and isn't the main SDK.

--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: FalconJX mxmlc error

[Erik de Bruin]

Tigran,

Being a work in progress, FalconJx works only with a very specific set
of inputs. To build FlexJS, use these (add/change paths to match your
setup):

+env.PLAYERGLOBAL_HOME=[pathToGlobalPlayerSWCRoot]
+playerglobal.version=11.1
-load-config="/Applications/Adobe Flash Builder
4.7/sdks/4.9.1/frameworks/flex-config.xml"
-library-path+=[pathToFlexUISWC]
-js-output-type=FLEXJS
-closure-lib=[pathToGoogleClosureLibRoot]
-sdk-js-lib=[pathToFlexJSSrc]
[pathToProjectMainMXML]

And yes, I do agree that better documentation would help. Maybe you
can keep notes while you are working on getting this to run on your
system. We could use those as the basis for a wiki page.

HTH,

EdB

On Fri, Apr 5, 2013 at 3:38 AM, Tigran Najaryan  wrote:
> OK, I built FalconJX but how do I use it properly? Simply running mxmlc
> without a command line gives an error:
>
> D:\WORK\Projects\ApacheFlex\repo\falcon\trunk\compiler.jx\bin>mxmlc
> Using Flex SDK: D:\WORK\Projects\ApacheFlex\repo\sdk\branches\develop
> Exception in thread "main" java.lang.UnsupportedOperationException
> at
> org.apache.flex.compiler.internal.driver.as.ASBackend.getSourceFileHandlerIn
> stance(ASBackend.java:70)
> at org.apache.flex.compiler.clients.MXMLJSC.(MXMLJSC.java:201)
> at org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:169)
>
>
> Looks like it selects AS backend where getSourceFileHandlerInstanceI() is
> not implemented.
>
> From the MXMLJSC.java I can see it expects a -js-output-type= parameter.
> Calling with any of -js-output-type=flexjs, -js-output-type=good or
> -js-output-type=amd results in another error in
> WorkspaceProblemFormatter.java but I do not even have the source file in my
> org/apache/flex/compiler/clients/problems directory.
>
> Here is the error:
>
> D:\WORK\Projects\ApacheFlex\repo\falcon\trunk\compiler.jx\bin>mxmlc
> -js-output-type=flexjs
> D:\WORK\Projects\ApacheFlex\repo\falcon\trunk\compiler.js\tests\TestApp.as
> Using Flex SDK: D:\WORK\Projects\ApacheFlex\repo\sdk\branches\develop
> Exception in thread "main" com.google.common.collect.ComputationException:
> java.lang.IllegalAccessError: tried to access method
> com.google.common.collect.MapMaker.maximumSize(I)Lcom/google/common/collect/
> MapMaker; from class
> org.apache.flex.compiler.clients.problems.WorkspaceProblemFormatter$FileLine
> Info
> at
> com.google.common.collect.MapMaker$ComputingMapAdapter.get(MapMaker.java:887
> )
> at
> org.apache.flex.compiler.clients.problems.WorkspaceProblemFormatter.getLineT
> ext(WorkspaceProblemFormatter.java:207)
> at
> org.apache.flex.compiler.clients.problems.WorkspaceProblemFormatter.format(W
> orkspaceProblemFormatter.java:132)
> at
> org.apache.flex.compiler.clients.problems.ProblemPrinter.printProblems(Probl
> emPrinter.java:90)
> at
> org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:225)
> at org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:171)
> Caused by: java.lang.IllegalAccessError: tried to access method
> com.google.common.collect.MapMaker.maximumSize(I)Lcom/google/common/collect/
> MapMaker; from class
> org.apache.flex.compiler.clients.problems.WorkspaceProblemFormatter$FileLine
> Info
> at
> org.apache.flex.compiler.clients.problems.WorkspaceProblemFormatter$FileLine
> Info.(WorkspaceProblemFormatter.java:258)
> at
> org.apache.flex.compiler.clients.problems.WorkspaceProblemFormatter$1.apply(
> WorkspaceProblemFormatter.java:103)
> at
> org.apache.flex.compiler.clients.problems.WorkspaceProblemFormatter$1.apply(
> WorkspaceProblemFormatter.java:98)
> at
> com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference
> .compute(ComputingConcurrentHashMap.java:356)
> at
> com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.comput
> e(ComputingConcurrentHashMap.java:182)
> at
> com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrC
> ompute(ComputingConcurrentHashMap.java:151)
> at
> com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingC
> oncurrentHashMap.java:67)
> at
> com.google.common.collect.MapMaker$ComputingMapAdapter.get(MapMaker.java:883
> )
> ... 5 more
>
>
>
> Also tried compiling the FlexJSTest_again and get exact same error message.
>
>
> Did I build FalconJX incorrectly or am I using it incorrectly?
>
> Thanks.
>
>
>
> -Original Message-
> From: Alex Harui [mailto:aha...@adobe.com]
> Sent: Thursday, April 04, 2013 5:59 PM
> To: dev@flex.apache.org
> Subject: Re: Error compiling TestApp sample using FalconJS
>
> The classpaths may have changed to break just running mxmlc from the bin
> directory.  I would recommend getting set up on FalconJX instead if you are
> planning to contribute code going forward.  If you want to try to use
> FalconJS for now, then use the FlexJSOverlay.zip as it sets up the classes
> in the class path properly.
>
>

[jira] [Closed] (FLEX-33273) CSSCondition.matchesStyleClient() is slow and creates excessive garbage

[JIRA]

 [ 
https://issues.apache.org/jira/browse/FLEX-33273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frédéric THOMAS closed FLEX-33273.
--


> CSSCondition.matchesStyleClient() is slow and creates excessive garbage
> ---
>
> Key: FLEX-33273
> URL: https://issues.apache.org/jira/browse/FLEX-33273
> Project: Apache Flex
>  Issue Type: Improvement
>  Components: Styles
>Affects Versions: Adobe Flex SDK 4.1 (Release), Adobe Flex SDK 4.5 
> (Release), Adobe Flex SDK 4.5.1 (Release), Adobe Flex SDK 4.6 (Release)
>Reporter: Maurice Nicholson
>Assignee: Frédéric THOMAS
>  Labels: patch, performance
> Attachments: FLEX-33273.patch, mx.styles - inlined.zip, 
> PerformanceTest.zip
>
>
> CSSCondition.matchesStyleClient() is called *very* frequently during layout 
> of components in many different scenarios.
> I've done a lot of profiling of Flex apps and it comes up again and again.
> The current implementation is slow and creates unnecessary garbage (which 
> slows down the runtime further, since it needs to collect the garbage instead 
> of doing more useful things).
> Here is the current implementation:
> {code}
> public function matchesStyleClient(object:IAdvancedStyleClient):Boolean
> {
> var match:Boolean = false;
> if (kind == CSSConditionKind.CLASS)
> {
> if (object.styleName != null && object.styleName is String)
> {
> // Look for a match in a potential list of styleNames 
> var styleNames:Array = object.styleName.split(/\s+/);
> for (var i:uint = 0; i < styleNames.length; i++)
> {
> if (styleNames[i] == value)
> {
> match = true;
> break;
> }
> }
> }
> }
> else if (kind == CSSConditionKind.ID)
> {
> if (object.id == value)
> match = true;
> }
> else if (kind == CSSConditionKind.PSEUDO)
> {
> if (object.matchesCSSState(value))
> match = true;
> }
> return match;
> }
> {code}
> Here is what I suggest instead:
> {code}
> public function matchesStyleClient(object:IAdvancedStyleClient):Boolean
> {
> var match:Boolean = false;
> if (kind == CSSConditionKind.CLASS)
> {
> const styleName:String = object.styleName as String;
> if (styleName)
> {
> // Look for a match in a potential list of styleNames 
> FIND:
> {
> var index:int = styleName.indexOf(value);
> if (index == -1)
> {
> break FIND;
> }
> if (index != 0 && styleName.charAt(index - 1) != ' ')
> {
> break FIND;
> }
> const next:int = index + value.length;
> if (next != styleName.length && styleName.charAt(next) != 
> ' ')
> {
> break FIND;
> }
> match = true;
> }
> }
> }
> else if (kind == CSSConditionKind.ID)
> {
> if (object.id == value)
> match = true;
> }
> else if (kind == CSSConditionKind.PSEUDO)
> {
> if (object.matchesCSSState(value))
> match = true;
> }
> return match;
> }
> {code}
> There are obviously more concise ways to express this code, but the above 
> seems to match the current style more or less.
> Here is the output from a benchmark I created using Grant Skinner's 
> PerformanceTest v2 Beta, comparing the current version and the suggested 
> version:
> {noformat}
> Comparing speed of matching a string in space delimited string. 100 loops.
> Test   Old ms   New 
> ms Speedup  Old mem  New mem  Change
> matchesStyleClient(styleName: "foo", value: "foo")1006.00   
> 181.00   -82.0   123.00 0.00  -100.0
> matchesStyleClient(styleName: "foo bar", value: "foo")2107.00   
> 206.80   -90.2   115.00 0.00  -100.0
> matchesStyleClient(styleName: "bar foo", value: "foo")2099.80   
> 232.30   -88.9   117.00 0.00  -100.0
> matchesStyleClient(styleName: "baz foo bar", value: "foo")3193.80   
> 251.30   -92.1   119.00 0.00  -100.0
> matchesStyleClient(styleName: "foobar", value: "foo") 1169.50   
> 192.00   -83.6   112.00 0.00  -100.0
> matchesStyleClient(styleNa

[jira] [Closed] (FLEX-33376) Missing locales in apache and experimental libs avoid its use in Maven

[JIRA]

 [ 
https://issues.apache.org/jira/browse/FLEX-33376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frédéric THOMAS closed FLEX-33376.
--


> Missing locales in apache and experimental libs avoid its use in Maven
> --
>
> Key: FLEX-33376
> URL: https://issues.apache.org/jira/browse/FLEX-33376
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Internationalization
>Affects Versions: Apache Flex 4.9.0
>Reporter: Frédéric THOMAS
>Assignee: Frédéric THOMAS
>  Labels: bundle, locale, maven
> Fix For: Apache Flex 4.10.0
>
>
> Most of the locales for the apache and experimental libs are not generated, 
> this avoid any maven project using missing locales to compile if the project 
> use the apache lib, common-framework.pom or the air-framework.pom.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FLEX-33386) Style Declaration Matching Tuning - Inlining

[JIRA]

 [ 
https://issues.apache.org/jira/browse/FLEX-33386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frédéric THOMAS updated FLEX-33386:
---

Assignee: (was: Frédéric THOMAS)

> Style Declaration Matching Tuning - Inlining
> 
>
> Key: FLEX-33386
> URL: https://issues.apache.org/jira/browse/FLEX-33386
> Project: Apache Flex
>  Issue Type: Improvement
>  Components: Styles
>Reporter: RJ Camarillo
>Priority: Minor
>  Labels: Performance, easyfix
> Fix For: Adobe Flex SDK Next
>
> Attachments: mx.styles - inlined.zip
>
>
> One of the most executed calls during the lifetime of a Flex UIComponent is 
> the matching of style declarations (i.e. state change, component 
> initialization, etc).
> As such, it is one that the community has monkey-patched often in order to 
> attain speed-ups even for just a little.
> This is one of the improvements done to achieve that end. Instead of doing 
> method calls to the different style classes (i.e. CSSCondition, CSSSelector, 
> CSSStyleDeclaration), the StyleProtoChain class has been modified to perform 
> matching inline as much as possible.
> The implementation is not perfect and I'm sure it can be improved further 
> with the help of the bigger community. For example, the 
> matchingDecls.sortOn("selectorIndex", Array.NUMERIC) call could be improve to 
> use one of the faster sort algorithms out there. There are also some methods 
> calls that are not inlined.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (FLEX-33377) Focus can be transferred from a modal window to a non-modal window open in the background if clicked on some specific dimension of the non-modal window in the background i

[JIRA]

 [ 
https://issues.apache.org/jira/browse/FLEX-33377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frédéric THOMAS closed FLEX-33377.
--


> Focus can be transferred from a modal window to a non-modal window open in 
> the background if clicked on some specific dimension of the non-modal window 
> in the background i.e. by clicking on the extreme left i.e. x=0 dimension of 
> the application.
> -
>
> Key: FLEX-33377
> URL: https://issues.apache.org/jira/browse/FLEX-33377
> Project: Apache Flex
>  Issue Type: Bug
>  Components: mx: Window
>Affects Versions: Adobe Flex SDK 4.6 (Release)
> Environment: Web application, flex SDK 4.6. and 4.9
> Flash player version: 11.5.502.146
> Mozilla firefox and IE
>Reporter: rahul singh rawat
>Assignee: Frédéric THOMAS
>Priority: Minor
> Attachments: Modal_mxTest.fxp, Modal_mxTest-MonkeyPatched.fxp
>
>
> Focus can be transferred from a modal window to a non-modal window open in 
> the background if clicked ONLY on some specific dimension of the non-modal 
> window in the background i.e. by clicking on the extreme left i.e. x=0 
> dimension of the application. Issue varies with flash player versions and 
> browser used. The non-modal window is coded to listen to a click event.
> However it can be easily reproduced with any browser or flash player version 
> by setting the x dimension of the non-modal window between-10 to 0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (FLEX-33387) Mailing list archive links on website point to incubator lists

[JIRA]

 [ 
https://issues.apache.org/jira/browse/FLEX-33387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frédéric THOMAS closed FLEX-33387.
--


> Mailing list archive links on website  point to incubator lists
> ---
>
> Key: FLEX-33387
> URL: https://issues.apache.org/jira/browse/FLEX-33387
> Project: Apache Flex
>  Issue Type: Bug
>Reporter: Kees van Dieren
>Assignee: Frédéric THOMAS
>Priority: Minor
>  Labels: Website, easyfix
>
> The page http://flex.apache.org/community-mailinglists.html contains links to 
> the mailing lists.
> They still point to the incubator mailing lists:
> http://markmail.org/search/+list:org.apache.incubator.flex-users
> http://mail-archives.apache.org/mod_mbox/incubator-flex-users/
> http://markmail.org/search/+list:org.apache.incubator.flex-dev
> http://mail-archives.apache.org/mod_mbox/incubator-flex-dev/
> http://markmail.org/search/+list:org.apache.incubator.flex-commits
> http://mail-archives.apache.org/mod_mbox/incubator-flex-commits/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (FLEX-33422) Typo in the French translation for the SDK Installer: "Installation terminer"

[JIRA]

 [ 
https://issues.apache.org/jira/browse/FLEX-33422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frédéric THOMAS closed FLEX-33422.
--


> Typo in the French translation for the SDK Installer: "Installation terminer"
> -
>
> Key: FLEX-33422
> URL: https://issues.apache.org/jira/browse/FLEX-33422
> Project: Apache Flex
>  Issue Type: Bug
>  Components: InstallApacheFlex
> Environment: apache-flex-sdk-installer-2.0.2-bin.exe
>Reporter: Frédéric Leroy
>Assignee: Frédéric THOMAS
>Priority: Trivial
>  Labels: easyfix, french, installer, translation
>
> "Installation terminer" should be: "Installation terminée"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (FLEX-33435) Fix web site pages to describe how to use GIT to check out and build Apache Flex rather than SVN

[JIRA]

 [ 
https://issues.apache.org/jira/browse/FLEX-33435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frédéric THOMAS resolved FLEX-33435.


Resolution: Fixed

> Fix web site pages to describe how to use GIT to check out and build Apache 
> Flex rather than SVN 
> -
>
> Key: FLEX-33435
> URL: https://issues.apache.org/jira/browse/FLEX-33435
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Web Site
>Reporter: Justin Mclean
>Assignee: Frédéric THOMAS
>
> Pages that need updating include:
> http://flex.apache.org/dev-faq.html
> http://flex.apache.org/dev-sourcecode.html
> http://flex.apache.org/download-source.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (FLEX-33435) Fix web site pages to describe how to use GIT to check out and build Apache Flex rather than SVN

[JIRA]

 [ 
https://issues.apache.org/jira/browse/FLEX-33435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frédéric THOMAS closed FLEX-33435.
--


> Fix web site pages to describe how to use GIT to check out and build Apache 
> Flex rather than SVN 
> -
>
> Key: FLEX-33435
> URL: https://issues.apache.org/jira/browse/FLEX-33435
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Web Site
>Reporter: Justin Mclean
>Assignee: Frédéric THOMAS
>
> Pages that need updating include:
> http://flex.apache.org/dev-faq.html
> http://flex.apache.org/dev-sourcecode.html
> http://flex.apache.org/download-source.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (FLEX-33316) checkintests fails on no english OS

[JIRA]

 [ 
https://issues.apache.org/jira/browse/FLEX-33316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frédéric THOMAS closed FLEX-33316.
--


> checkintests fails on no english OS
> ---
>
> Key: FLEX-33316
> URL: https://issues.apache.org/jira/browse/FLEX-33316
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Mustella
>Reporter: Frédéric THOMAS
>Assignee: Frédéric THOMAS
>Priority: Trivial
>  Labels: mustella, test
>
> checkintests fails on no english OS, feel free to use this jira tickect to 
> link with your commit if you checked in a fix for your language.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Still confused by git

[Nicholas Kwiatkowski]

+1 on this.  I've been sitting on the sidelines the last few weeks for that
reason.  I know there are a lot of standards that still need to be figured
out, and since I'm very green with GIT, I don't really have the time at the
moment to learn all the command line (i've been really busy with personal
and professional stuff the last few weeks as well).  My goal is not to use
the command line, but use my IDE like I did before.  Dropping to the
command line and typing 10 commands every time I want to do something is a
pain in the rear for those things that my IDE should be doing for me (I
usually have a dozen command prompt windows open at any given time, but
those are for truly interactive things).

-Nick

On Fri, Apr 5, 2013 at 5:44 AM, Justin Mclean wrote:

> Hi,
>
> > There's also been a lot of discussion on when to rebase and when not.
> I'm not clear on whether there has been a consensus on that.
> I don't believe there is a consensus but that's mostly around how
> important it is to keep a "clean" history and with respect to  Frederic
> obvious knowledge in this area we still need to come up with a way people
> new to git can contribute without knowing every intricate details of
> obscure options to git commands. In part because not everyone will use the
> command line.
>
> Thanks,
> Justin

[jira] [Resolved] (FLEX-33316) checkintests fails on no english OS

[JIRA]

 [ 
https://issues.apache.org/jira/browse/FLEX-33316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frédéric THOMAS resolved FLEX-33316.


Resolution: Fixed

> checkintests fails on no english OS
> ---
>
> Key: FLEX-33316
> URL: https://issues.apache.org/jira/browse/FLEX-33316
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Mustella
>Reporter: Frédéric THOMAS
>Assignee: Frédéric THOMAS
>Priority: Trivial
>  Labels: mustella, test
>
> checkintests fails on no english OS, feel free to use this jira tickect to 
> link with your commit if you checked in a fix for your language.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (FLEX-33327) RuntimeLocale.as for the Apache Flex Installer needs to be updated for the French language

[JIRA]

 [ 
https://issues.apache.org/jira/browse/FLEX-33327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frédéric THOMAS closed FLEX-33327.
--


> RuntimeLocale.as for the Apache Flex Installer needs to be updated for the 
> French language
> --
>
> Key: FLEX-33327
> URL: https://issues.apache.org/jira/browse/FLEX-33327
> Project: Apache Flex
>  Issue Type: Improvement
>  Components: InstallApacheFlex
>Affects Versions: InstallApacheFlex 1.1
>Reporter: Frédéric THOMAS
>Assignee: Frédéric THOMAS
>Priority: Minor
>
> RuntimeLocale.as for the Apache Flex Installer needs to be updated for the 
> French language

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (FLEX-33327) RuntimeLocale.as for the Apache Flex Installer needs to be updated for the French language

[JIRA]

 [ 
https://issues.apache.org/jira/browse/FLEX-33327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frédéric THOMAS resolved FLEX-33327.


Resolution: Fixed

> RuntimeLocale.as for the Apache Flex Installer needs to be updated for the 
> French language
> --
>
> Key: FLEX-33327
> URL: https://issues.apache.org/jira/browse/FLEX-33327
> Project: Apache Flex
>  Issue Type: Improvement
>  Components: InstallApacheFlex
>Affects Versions: InstallApacheFlex 1.1
>Reporter: Frédéric THOMAS
>Assignee: Frédéric THOMAS
>Priority: Minor
>
> RuntimeLocale.as for the Apache Flex Installer needs to be updated for the 
> French language

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (FLEX-33451) The release build due to the Git migration is broken

[JIRA]

 [ 
https://issues.apache.org/jira/browse/FLEX-33451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frédéric THOMAS closed FLEX-33451.
--


> The release build due to the Git migration is broken
> 
>
> Key: FLEX-33451
> URL: https://issues.apache.org/jira/browse/FLEX-33451
> Project: Apache Flex
>  Issue Type: Bug
>  Components: .Unspecified - Framework
>Affects Versions: Adobe Flex SDK Next
>Reporter: Frédéric THOMAS
>Assignee: Frédéric THOMAS
>Priority: Critical
>  Labels: Git, TLF, build, documentation
>
> The release build due to the Git migration is broken:
> - TLF external build
> - Build Number
> - ASDoc for the experimental lib
> - Building process (.gitignore, empty.properties)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (FLEX-33451) The release build due to the Git migration is broken

[JIRA]

 [ 
https://issues.apache.org/jira/browse/FLEX-33451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frédéric THOMAS resolved FLEX-33451.


Resolution: Fixed

> The release build due to the Git migration is broken
> 
>
> Key: FLEX-33451
> URL: https://issues.apache.org/jira/browse/FLEX-33451
> Project: Apache Flex
>  Issue Type: Bug
>  Components: .Unspecified - Framework
>Affects Versions: Adobe Flex SDK Next
>Reporter: Frédéric THOMAS
>Assignee: Frédéric THOMAS
>Priority: Critical
>  Labels: Git, TLF, build, documentation
>
> The release build due to the Git migration is broken:
> - TLF external build
> - Build Number
> - ASDoc for the experimental lib
> - Building process (.gitignore, empty.properties)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FLEX-33451) The release build due to the Git migration is broken

[JIRA]

[ 
https://issues.apache.org/jira/browse/FLEX-33451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13623561#comment-13623561
 ] 

Frédéric THOMAS commented on FLEX-33451:


- ASDoc for the experimental lib (Not fixed, just commented at the moment
- Build Number (Not fixed)

Please, open a new issue for those 2 remaining ones, the branch relative to 
this one had been merged

> The release build due to the Git migration is broken
> 
>
> Key: FLEX-33451
> URL: https://issues.apache.org/jira/browse/FLEX-33451
> Project: Apache Flex
>  Issue Type: Bug
>  Components: .Unspecified - Framework
>Affects Versions: Adobe Flex SDK Next
>Reporter: Frédéric THOMAS
>Assignee: Frédéric THOMAS
>Priority: Critical
>  Labels: Git, TLF, build, documentation
>
> The release build due to the Git migration is broken:
> - TLF external build
> - Build Number
> - ASDoc for the experimental lib
> - Building process (.gitignore, empty.properties)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Still confused by git

[Harbs]

Okay. I did it. It looks like I slightly messed up the last step. Sorry about 
that.

I used SourceTree for the last step because I was not interested in typing my 
password into Terminal. I think there's a checkbox to push all tags that I 
should have unchecked…

Thanks for the hand-holding on this… :-)

Harbs

On Apr 5, 2013, at 12:31 PM, Frédéric THOMAS wrote:

> You right Harbs, that currently looks something I dislike at the point I 
> won't work anymore on that tree.
> 
> Well, for your case (I assume you updated your .gitconfig as shown in the 
> Wiki) :
> 
> -Checkout the develop branch: git co develop
> -If you have some modified files in your working tree, save them first: git 
> stash -u "my current work"
> -Be sure the branch is up to date before to start working on it: git pull 
> --rebase
> -create the branch you will work on, assuming your create a JIRA first: git 
> co -b "FLEX-"
> -get back the work you save on this branch: git stash pop
> -Edit/add files/dirs
> -Add them to the staged area(also called index) and commit, you've got 2 
> choices, either you do 1 commit or more:
> 1- To add all of them in a once, that's in order to do only one commit:
>   - git add .
>   - git ci -m "FLEX-: Fixed this"
> 2- To add them one by one, that's in order to make more commits
>   - git add  
>   - git ci -m "FLEX-: Fixed this in my 1rst commit"
>   - git add  
>   - git ci -m "FLEX-: Fixed this in my 2nd commit"
> - check all the files are committed: git st
> - If there are more repeat the add/commit steps, otherwise, go back on the 
> develop branch: git co develop
> - rebase your work on what the others did: git pull --rebase
> - Merge your branch to the develop one: git merge --no-ff  FLEX-
> - you can now push: git push
> - you can remove your local branch if you want now it is unused: git br -d 
> FLEX-
> 
> 
> I hope that helps
> 
> -Fred
> 
> -Message d'origine- From: Harbs
> Sent: Friday, April 05, 2013 11:06 AM
> To: dev@flex.apache.org
> Subject: Re: Still confused by git
> 
> Hi Fred,
> 
> I've read those pages. (I see now you've updated them.) Conceptually, I sort 
> of got the idea of how to do things, but I find that until I actually do 
> something once, I don't quite "get" it… If someone could walk me through this 
> once, I think I'l be a lot more comfortable that I'm doing things right.
> 
> There's also been a lot of discussion on when to rebase and when not. I'm not 
> clear on whether there has been a consensus on that. Looking at the graph, it 
> seems to me that not everyone is working exactly the same way. (unless I 
> don't know how to read the graph, which is also possible…)
> 
> 
> On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote:
> 
>> Hi Harbs,
>> 
>> Check the wiki first for a complete workflow guideline and git setup, if you 
>> need more info, ask them after you reviewed this wiki pages [1] [2], there 
>> are even interactive tutorials really well done. [1] [2]
>> 
>> I advice that to everybody, for myself, until everyone understood and 
>> applied the basics written in the wiki, I won't touch the SDK anymore.
>> 
>> -Fred
>> 
>> [1] 
>> https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide
>> [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage
>> 
>> 
>> 
>> -Message d'origine- From: Harbs
>> Sent: Friday, April 05, 2013 10:14 AM
>> To: dev@flex.apache.org
>> Subject: Still confused by git
>> 
>> I've tried to follow all the git discussions. But, after all the discussions 
>> on how to use git, I'm still confused on the basics.
>> 
>> Here's what I need to know right now:
>> Right now I have a number of files I've edited outside my working directory 
>> related to ColorPicker inside experimental. I'd like to commit this work to 
>> the develop branch. It probably makes sense to create a branch to indicate 
>> the work I'm doing on this. (or not?)
>> 
>> I'm using SourceTree on Mac. I'd rather not mess with the command line.
>> 
>> So far I've checked out develop and master. The index view shows a bunch of 
>> modified and deleted files. I have not yet touched any of the git folders on 
>> my machine.
>> 
>> How do I?
>> 1) Make sure my working copy is up to date?
>> 2) Make sure my working coy is the correct branch? (Does that make sense?)
>> 3) Create a new branch? (Or do I?)
>> 4) Get my changes up to origin?
>> 
>> I've seen a lot of talk about switching between branches, but this stuff is 
>> all very fuzzy to me and kind of scary… ;-)
>> 
>> Harbs
> 

Re: Still confused by git

[Harbs]

I'm already stuck with the second step:
git pull --rebase
Cannot pull with rebase: Your index contains uncommitted changes.
Please commit or stash them.

I do not want any changes -- since I did not make any! What do I do?

On Apr 5, 2013, at 12:31 PM, Frédéric THOMAS wrote:

> You right Harbs, that currently looks something I dislike at the point I 
> won't work anymore on that tree.
> 
> Well, for your case (I assume you updated your .gitconfig as shown in the 
> Wiki) :
> 
> -Checkout the develop branch: git co develop
> -If you have some modified files in your working tree, save them first: git 
> stash -u "my current work"
> -Be sure the branch is up to date before to start working on it: git pull 
> --rebase
> -create the branch you will work on, assuming your create a JIRA first: git 
> co -b "FLEX-"
> -get back the work you save on this branch: git stash pop
> -Edit/add files/dirs
> -Add them to the staged area(also called index) and commit, you've got 2 
> choices, either you do 1 commit or more:
> 1- To add all of them in a once, that's in order to do only one commit:
>   - git add .
>   - git ci -m "FLEX-: Fixed this"
> 2- To add them one by one, that's in order to make more commits
>   - git add  
>   - git ci -m "FLEX-: Fixed this in my 1rst commit"
>   - git add  
>   - git ci -m "FLEX-: Fixed this in my 2nd commit"
> - check all the files are committed: git st
> - If there are more repeat the add/commit steps, otherwise, go back on the 
> develop branch: git co develop
> - rebase your work on what the others did: git pull --rebase
> - Merge your branch to the develop one: git merge --no-ff  FLEX-
> - you can now push: git push
> - you can remove your local branch if you want now it is unused: git br -d 
> FLEX-
> 
> 
> I hope that helps
> 
> -Fred
> 
> -Message d'origine- From: Harbs
> Sent: Friday, April 05, 2013 11:06 AM
> To: dev@flex.apache.org
> Subject: Re: Still confused by git
> 
> Hi Fred,
> 
> I've read those pages. (I see now you've updated them.) Conceptually, I sort 
> of got the idea of how to do things, but I find that until I actually do 
> something once, I don't quite "get" it… If someone could walk me through this 
> once, I think I'l be a lot more comfortable that I'm doing things right.
> 
> There's also been a lot of discussion on when to rebase and when not. I'm not 
> clear on whether there has been a consensus on that. Looking at the graph, it 
> seems to me that not everyone is working exactly the same way. (unless I 
> don't know how to read the graph, which is also possible…)
> 
> 
> On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote:
> 
>> Hi Harbs,
>> 
>> Check the wiki first for a complete workflow guideline and git setup, if you 
>> need more info, ask them after you reviewed this wiki pages [1] [2], there 
>> are even interactive tutorials really well done. [1] [2]
>> 
>> I advice that to everybody, for myself, until everyone understood and 
>> applied the basics written in the wiki, I won't touch the SDK anymore.
>> 
>> -Fred
>> 
>> [1] 
>> https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide
>> [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage
>> 
>> 
>> 
>> -Message d'origine- From: Harbs
>> Sent: Friday, April 05, 2013 10:14 AM
>> To: dev@flex.apache.org
>> Subject: Still confused by git
>> 
>> I've tried to follow all the git discussions. But, after all the discussions 
>> on how to use git, I'm still confused on the basics.
>> 
>> Here's what I need to know right now:
>> Right now I have a number of files I've edited outside my working directory 
>> related to ColorPicker inside experimental. I'd like to commit this work to 
>> the develop branch. It probably makes sense to create a branch to indicate 
>> the work I'm doing on this. (or not?)
>> 
>> I'm using SourceTree on Mac. I'd rather not mess with the command line.
>> 
>> So far I've checked out develop and master. The index view shows a bunch of 
>> modified and deleted files. I have not yet touched any of the git folders on 
>> my machine.
>> 
>> How do I?
>> 1) Make sure my working copy is up to date?
>> 2) Make sure my working coy is the correct branch? (Does that make sense?)
>> 3) Create a new branch? (Or do I?)
>> 4) Get my changes up to origin?
>> 
>> I've seen a lot of talk about switching between branches, but this stuff is 
>> all very fuzzy to me and kind of scary… ;-)
>> 
>> Harbs
> 

Re: Still confused by git

[Frédéric THOMAS]

SourceTree gives you access to the command line, I suggest you to start with 
the command line, once those basics commands known, that will then become 
easy to do it in sourceTree, in more, I can't teach you how to do that with 
sourceTree unless I do a screencast.


-Fred

-Message d'origine- 
From: Harbs

Sent: Friday, April 05, 2013 12:02 PM
To: dev@flex.apache.org
Subject: Re: Still confused by git

Thanks. I'll have to figure out how to translate that into the GUI of 
SourceTree. I'm not sure if I have the time today to play around with this. 
I'll probably get to it on Sunday…


How do I know which branch the working copy is using and how do I switch? I 
started looking at tutorials, but this stuff is really not intuitive to me… 
:-( I'm just hoping I'll be glad I learned git when this is all over… ;-)


Harbs

On Apr 5, 2013, at 12:33 PM, Frédéric THOMAS wrote:


oops, reverse the 2 furst steps:


-If you have some modified files in your working tree, save them first: 
git stash -u "my current work"

-Checkout the develop branch: git co develop

-Fred

-Message d'origine- From: Frédéric THOMAS
Sent: Friday, April 05, 2013 11:31 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

You right Harbs, that currently looks something I dislike at the point I
won't work anymore on that tree.

Well, for your case (I assume you updated your .gitconfig as shown in the
Wiki) :
-If you have some modified files in your working tree, save them first: 
git

stash -u "my current work"
-Be sure the branch is up to date before to start working on it: git
pull --rebase
-create the branch you will work on, assuming your create a JIRA first: 
git

co -b "FLEX-"
-get back the work you save on this branch: git stash pop
-Edit/add files/dirs
-Add them to the staged area(also called index) and commit, you've got 2
choices, either you do 1 commit or more:
1- To add all of them in a once, that's in order to do only one commit:
  - git add .
  - git ci -m "FLEX-: Fixed this"
2- To add them one by one, that's in order to make more commits
  - git add  
  - git ci -m "FLEX-: Fixed this in my 1rst commit"
  - git add  
  - git ci -m "FLEX-: Fixed this in my 2nd commit"
- check all the files are committed: git st
- If there are more repeat the add/commit steps, otherwise, go back on the
develop branch: git co develop
- rebase your work on what the others did: git pull --rebase
- Merge your branch to the develop one: git merge --no-ff  FLEX-
- you can now push: git push
- you can remove your local branch if you want now it is unused: git br -d
FLEX-


I hope that helps

-Fred

-Message d'origine- From: Harbs
Sent: Friday, April 05, 2013 11:06 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

Hi Fred,

I've read those pages. (I see now you've updated them.) Conceptually, I 
sort

of got the idea of how to do things, but I find that until I actually do
something once, I don't quite "get" it… If someone could walk me through
this once, I think I'l be a lot more comfortable that I'm doing things
right.

There's also been a lot of discussion on when to rebase and when not. I'm
not clear on whether there has been a consensus on that. Looking at the
graph, it seems to me that not everyone is working exactly the same way.
(unless I don't know how to read the graph, which is also possible…)


On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote:


Hi Harbs,

Check the wiki first for a complete workflow guideline and git setup, if 
you need more info, ask them after you reviewed this wiki pages [1] [2], 
there are even interactive tutorials really well done. [1] [2]


I advice that to everybody, for myself, until everyone understood and 
applied the basics written in the wiki, I won't touch the SDK anymore.


-Fred

[1] 
https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide
[2] 
https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage




-Message d'origine- From: Harbs
Sent: Friday, April 05, 2013 10:14 AM
To: dev@flex.apache.org
Subject: Still confused by git

I've tried to follow all the git discussions. But, after all the 
discussions on how to use git, I'm still confused on the basics.


Here's what I need to know right now:
Right now I have a number of files I've edited outside my working 
directory related to ColorPicker inside experimental. I'd like to commit 
this work to the develop branch. It probably makes sense to create a 
branch to indicate the work I'm doing on this. (or not?)


I'm using SourceTree on Mac. I'd rather not mess with the command line.

So far I've checked out develop and master. The index view shows a bunch 
of modified and deleted files. I have not yet touched any of the git 
folders on my machine.


How do I?
1) Make sure my working copy is up to date?
2) Make sure my working coy is the correct branch? (Does that make 
sense?)

3) Create a new branch? (Or do I?)
4) Get my cha

RE: Still confused by git

[Kessler CTR Mark J]

I still recommend Tortoise Git [1] to all new people running Windows... no 
command line needed (thank goodness).  Just need to install MSysGit [2] as a 
pre-requisite and you're up and running.


[1] http://code.google.com/p/tortoisegit/
[2] http://code.google.com/p/msysgit/downloads/list?q=net+installer


-Mark

-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com] 
Sent: Friday, April 05, 2013 5:45 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

Hi,

> There's also been a lot of discussion on when to rebase and when not. I'm not 
> clear on whether there has been a consensus on that.
I don't believe there is a consensus but that's mostly around how important it 
is to keep a "clean" history and with respect to  Frederic obvious knowledge in 
this area we still need to come up with a way people new to git can contribute 
without knowing every intricate details of obscure options to git commands. In 
part because not everyone will use the command line.

Thanks,
Justin

Re: Still confused by git

[Harbs]

Thanks. I'll have to figure out how to translate that into the GUI of 
SourceTree. I'm not sure if I have the time today to play around with this. 
I'll probably get to it on Sunday…

How do I know which branch the working copy is using and how do I switch? I 
started looking at tutorials, but this stuff is really not intuitive to me… :-( 
I'm just hoping I'll be glad I learned git when this is all over… ;-)

Harbs

On Apr 5, 2013, at 12:33 PM, Frédéric THOMAS wrote:

> oops, reverse the 2 furst steps:
> 
> 
> -If you have some modified files in your working tree, save them first: git 
> stash -u "my current work"
> -Checkout the develop branch: git co develop
> 
> -Fred
> 
> -Message d'origine- From: Frédéric THOMAS
> Sent: Friday, April 05, 2013 11:31 AM
> To: dev@flex.apache.org
> Subject: Re: Still confused by git
> 
> You right Harbs, that currently looks something I dislike at the point I
> won't work anymore on that tree.
> 
> Well, for your case (I assume you updated your .gitconfig as shown in the
> Wiki) :
> -If you have some modified files in your working tree, save them first: git
> stash -u "my current work"
> -Be sure the branch is up to date before to start working on it: git
> pull --rebase
> -create the branch you will work on, assuming your create a JIRA first: git
> co -b "FLEX-"
> -get back the work you save on this branch: git stash pop
> -Edit/add files/dirs
> -Add them to the staged area(also called index) and commit, you've got 2
> choices, either you do 1 commit or more:
> 1- To add all of them in a once, that's in order to do only one commit:
>   - git add .
>   - git ci -m "FLEX-: Fixed this"
> 2- To add them one by one, that's in order to make more commits
>   - git add  
>   - git ci -m "FLEX-: Fixed this in my 1rst commit"
>   - git add  
>   - git ci -m "FLEX-: Fixed this in my 2nd commit"
> - check all the files are committed: git st
> - If there are more repeat the add/commit steps, otherwise, go back on the
> develop branch: git co develop
> - rebase your work on what the others did: git pull --rebase
> - Merge your branch to the develop one: git merge --no-ff  FLEX-
> - you can now push: git push
> - you can remove your local branch if you want now it is unused: git br -d
> FLEX-
> 
> 
> I hope that helps
> 
> -Fred
> 
> -Message d'origine- From: Harbs
> Sent: Friday, April 05, 2013 11:06 AM
> To: dev@flex.apache.org
> Subject: Re: Still confused by git
> 
> Hi Fred,
> 
> I've read those pages. (I see now you've updated them.) Conceptually, I sort
> of got the idea of how to do things, but I find that until I actually do
> something once, I don't quite "get" it… If someone could walk me through
> this once, I think I'l be a lot more comfortable that I'm doing things
> right.
> 
> There's also been a lot of discussion on when to rebase and when not. I'm
> not clear on whether there has been a consensus on that. Looking at the
> graph, it seems to me that not everyone is working exactly the same way.
> (unless I don't know how to read the graph, which is also possible…)
> 
> 
> On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote:
> 
>> Hi Harbs,
>> 
>> Check the wiki first for a complete workflow guideline and git setup, if you 
>> need more info, ask them after you reviewed this wiki pages [1] [2], there 
>> are even interactive tutorials really well done. [1] [2]
>> 
>> I advice that to everybody, for myself, until everyone understood and 
>> applied the basics written in the wiki, I won't touch the SDK anymore.
>> 
>> -Fred
>> 
>> [1] 
>> https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide
>> [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage
>> 
>> 
>> 
>> -Message d'origine- From: Harbs
>> Sent: Friday, April 05, 2013 10:14 AM
>> To: dev@flex.apache.org
>> Subject: Still confused by git
>> 
>> I've tried to follow all the git discussions. But, after all the discussions 
>> on how to use git, I'm still confused on the basics.
>> 
>> Here's what I need to know right now:
>> Right now I have a number of files I've edited outside my working directory 
>> related to ColorPicker inside experimental. I'd like to commit this work to 
>> the develop branch. It probably makes sense to create a branch to indicate 
>> the work I'm doing on this. (or not?)
>> 
>> I'm using SourceTree on Mac. I'd rather not mess with the command line.
>> 
>> So far I've checked out develop and master. The index view shows a bunch of 
>> modified and deleted files. I have not yet touched any of the git folders on 
>> my machine.
>> 
>> How do I?
>> 1) Make sure my working copy is up to date?
>> 2) Make sure my working coy is the correct branch? (Does that make sense?)
>> 3) Create a new branch? (Or do I?)
>> 4) Get my changes up to origin?
>> 
>> I've seen a lot of talk about switching between branches, but this stuff is 
>> all very fuzzy to me and kind of scary… ;-)
>> 
>> Harbs
> 

Re: Still confused by git

[Frédéric THOMAS]

I mean git status, but if you want to follow the commands I wrote, update 
your .gitconfig as described in the wiki


-Fred

-Message d'origine- 
From: Harbs

Sent: Friday, April 05, 2013 11:59 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

git: 'st' is not a git command. See 'git --help'.

Did you mean one of these?
status
reset
stage
stash
svn

On Apr 5, 2013, at 12:41 PM, Frédéric THOMAS wrote:

The index view shows a bunch of modified and deleted files. I have not 
yet touched any of the git folders on my machine


I just noticed you wrote that, can you show me the result of 'git st' ?

-Fred

-Message d'origine- From: Frédéric THOMAS
Sent: Friday, April 05, 2013 11:33 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

oops, reverse the 2 furst steps:


-If you have some modified files in your working tree, save them first: 
git

stash -u "my current work"
-Checkout the develop branch: git co develop

-Fred

-Message d'origine- From: Frédéric THOMAS
Sent: Friday, April 05, 2013 11:31 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

You right Harbs, that currently looks something I dislike at the point I
won't work anymore on that tree.

Well, for your case (I assume you updated your .gitconfig as shown in the
Wiki) :
-If you have some modified files in your working tree, save them first: 
git

stash -u "my current work"
-Be sure the branch is up to date before to start working on it: git
pull --rebase
-create the branch you will work on, assuming your create a JIRA first: 
git

co -b "FLEX-"
-get back the work you save on this branch: git stash pop
-Edit/add files/dirs
-Add them to the staged area(also called index) and commit, you've got 2
choices, either you do 1 commit or more:
1- To add all of them in a once, that's in order to do only one commit:
  - git add .
  - git ci -m "FLEX-: Fixed this"
2- To add them one by one, that's in order to make more commits
  - git add  
  - git ci -m "FLEX-: Fixed this in my 1rst commit"
  - git add  
  - git ci -m "FLEX-: Fixed this in my 2nd commit"
- check all the files are committed: git st
- If there are more repeat the add/commit steps, otherwise, go back on the
develop branch: git co develop
- rebase your work on what the others did: git pull --rebase
- Merge your branch to the develop one: git merge --no-ff  FLEX-
- you can now push: git push
- you can remove your local branch if you want now it is unused: git br -d
FLEX-


I hope that helps

-Fred

-Message d'origine- From: Harbs
Sent: Friday, April 05, 2013 11:06 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

Hi Fred,

I've read those pages. (I see now you've updated them.) Conceptually, I 
sort

of got the idea of how to do things, but I find that until I actually do
something once, I don't quite "get" it… If someone could walk me through
this once, I think I'l be a lot more comfortable that I'm doing things
right.

There's also been a lot of discussion on when to rebase and when not. I'm
not clear on whether there has been a consensus on that. Looking at the
graph, it seems to me that not everyone is working exactly the same way.
(unless I don't know how to read the graph, which is also possible…)


On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote:


Hi Harbs,

Check the wiki first for a complete workflow guideline and git setup, if 
you need more info, ask them after you reviewed this wiki pages [1] [2], 
there are even interactive tutorials really well done. [1] [2]


I advice that to everybody, for myself, until everyone understood and 
applied the basics written in the wiki, I won't touch the SDK anymore.


-Fred

[1] 
https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide
[2] 
https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage




-Message d'origine- From: Harbs
Sent: Friday, April 05, 2013 10:14 AM
To: dev@flex.apache.org
Subject: Still confused by git

I've tried to follow all the git discussions. But, after all the 
discussions on how to use git, I'm still confused on the basics.


Here's what I need to know right now:
Right now I have a number of files I've edited outside my working 
directory related to ColorPicker inside experimental. I'd like to commit 
this work to the develop branch. It probably makes sense to create a 
branch to indicate the work I'm doing on this. (or not?)


I'm using SourceTree on Mac. I'd rather not mess with the command line.

So far I've checked out develop and master. The index view shows a bunch 
of modified and deleted files. I have not yet touched any of the git 
folders on my machine.


How do I?
1) Make sure my working copy is up to date?
2) Make sure my working coy is the correct branch? (Does that make 
sense?)

3) Create a new branch? (Or do I?)
4) Get my changes up to origin?

I've seen a lot of talk about switching between branches, but this stuff 
is all very fuzzy to 

Re: Still confused by git

[Harbs]

git: 'st' is not a git command. See 'git --help'.

Did you mean one of these?
status
reset
stage
stash
svn

On Apr 5, 2013, at 12:41 PM, Frédéric THOMAS wrote:

>> The index view shows a bunch of modified and deleted files. I have not yet 
>> touched any of the git folders on my machine
> 
> I just noticed you wrote that, can you show me the result of 'git st' ?
> 
> -Fred
> 
> -Message d'origine- From: Frédéric THOMAS
> Sent: Friday, April 05, 2013 11:33 AM
> To: dev@flex.apache.org
> Subject: Re: Still confused by git
> 
> oops, reverse the 2 furst steps:
> 
> 
> -If you have some modified files in your working tree, save them first: git
> stash -u "my current work"
> -Checkout the develop branch: git co develop
> 
> -Fred
> 
> -Message d'origine- From: Frédéric THOMAS
> Sent: Friday, April 05, 2013 11:31 AM
> To: dev@flex.apache.org
> Subject: Re: Still confused by git
> 
> You right Harbs, that currently looks something I dislike at the point I
> won't work anymore on that tree.
> 
> Well, for your case (I assume you updated your .gitconfig as shown in the
> Wiki) :
> -If you have some modified files in your working tree, save them first: git
> stash -u "my current work"
> -Be sure the branch is up to date before to start working on it: git
> pull --rebase
> -create the branch you will work on, assuming your create a JIRA first: git
> co -b "FLEX-"
> -get back the work you save on this branch: git stash pop
> -Edit/add files/dirs
> -Add them to the staged area(also called index) and commit, you've got 2
> choices, either you do 1 commit or more:
> 1- To add all of them in a once, that's in order to do only one commit:
>   - git add .
>   - git ci -m "FLEX-: Fixed this"
> 2- To add them one by one, that's in order to make more commits
>   - git add  
>   - git ci -m "FLEX-: Fixed this in my 1rst commit"
>   - git add  
>   - git ci -m "FLEX-: Fixed this in my 2nd commit"
> - check all the files are committed: git st
> - If there are more repeat the add/commit steps, otherwise, go back on the
> develop branch: git co develop
> - rebase your work on what the others did: git pull --rebase
> - Merge your branch to the develop one: git merge --no-ff  FLEX-
> - you can now push: git push
> - you can remove your local branch if you want now it is unused: git br -d
> FLEX-
> 
> 
> I hope that helps
> 
> -Fred
> 
> -Message d'origine- From: Harbs
> Sent: Friday, April 05, 2013 11:06 AM
> To: dev@flex.apache.org
> Subject: Re: Still confused by git
> 
> Hi Fred,
> 
> I've read those pages. (I see now you've updated them.) Conceptually, I sort
> of got the idea of how to do things, but I find that until I actually do
> something once, I don't quite "get" it… If someone could walk me through
> this once, I think I'l be a lot more comfortable that I'm doing things
> right.
> 
> There's also been a lot of discussion on when to rebase and when not. I'm
> not clear on whether there has been a consensus on that. Looking at the
> graph, it seems to me that not everyone is working exactly the same way.
> (unless I don't know how to read the graph, which is also possible…)
> 
> 
> On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote:
> 
>> Hi Harbs,
>> 
>> Check the wiki first for a complete workflow guideline and git setup, if you 
>> need more info, ask them after you reviewed this wiki pages [1] [2], there 
>> are even interactive tutorials really well done. [1] [2]
>> 
>> I advice that to everybody, for myself, until everyone understood and 
>> applied the basics written in the wiki, I won't touch the SDK anymore.
>> 
>> -Fred
>> 
>> [1] 
>> https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide
>> [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage
>> 
>> 
>> 
>> -Message d'origine- From: Harbs
>> Sent: Friday, April 05, 2013 10:14 AM
>> To: dev@flex.apache.org
>> Subject: Still confused by git
>> 
>> I've tried to follow all the git discussions. But, after all the discussions 
>> on how to use git, I'm still confused on the basics.
>> 
>> Here's what I need to know right now:
>> Right now I have a number of files I've edited outside my working directory 
>> related to ColorPicker inside experimental. I'd like to commit this work to 
>> the develop branch. It probably makes sense to create a branch to indicate 
>> the work I'm doing on this. (or not?)
>> 
>> I'm using SourceTree on Mac. I'd rather not mess with the command line.
>> 
>> So far I've checked out develop and master. The index view shows a bunch of 
>> modified and deleted files. I have not yet touched any of the git folders on 
>> my machine.
>> 
>> How do I?
>> 1) Make sure my working copy is up to date?
>> 2) Make sure my working coy is the correct branch? (Does that make sense?)
>> 3) Create a new branch? (Or do I?)
>> 4) Get my changes up to origin?
>> 
>> I've seen a lot of talk about switchi

Re: Still confused by git

[Justin Mclean]

Hi,

> There's also been a lot of discussion on when to rebase and when not. I'm not 
> clear on whether there has been a consensus on that.
I don't believe there is a consensus but that's mostly around how important it 
is to keep a "clean" history and with respect to  Frederic obvious knowledge in 
this area we still need to come up with a way people new to git can contribute 
without knowing every intricate details of obscure options to git commands. In 
part because not everyone will use the command line.

Thanks,
Justin

Re: Still confused by git

[Frédéric THOMAS]

The index view shows a bunch of modified and deleted files. I have not yet 
touched any of the git folders on my machine


I just noticed you wrote that, can you show me the result of 'git st' ?

-Fred

-Message d'origine- 
From: Frédéric THOMAS

Sent: Friday, April 05, 2013 11:33 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

oops, reverse the 2 furst steps:


-If you have some modified files in your working tree, save them first: git
stash -u "my current work"
-Checkout the develop branch: git co develop

-Fred

-Message d'origine- 
From: Frédéric THOMAS

Sent: Friday, April 05, 2013 11:31 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

You right Harbs, that currently looks something I dislike at the point I
won't work anymore on that tree.

Well, for your case (I assume you updated your .gitconfig as shown in the
Wiki) :
-If you have some modified files in your working tree, save them first: git
stash -u "my current work"
-Be sure the branch is up to date before to start working on it: git
pull --rebase
-create the branch you will work on, assuming your create a JIRA first: git
co -b "FLEX-"
-get back the work you save on this branch: git stash pop
-Edit/add files/dirs
-Add them to the staged area(also called index) and commit, you've got 2
choices, either you do 1 commit or more:
 1- To add all of them in a once, that's in order to do only one commit:
   - git add .
   - git ci -m "FLEX-: Fixed this"
 2- To add them one by one, that's in order to make more commits
   - git add  
   - git ci -m "FLEX-: Fixed this in my 1rst commit"
   - git add  
   - git ci -m "FLEX-: Fixed this in my 2nd commit"
- check all the files are committed: git st
- If there are more repeat the add/commit steps, otherwise, go back on the
develop branch: git co develop
- rebase your work on what the others did: git pull --rebase
- Merge your branch to the develop one: git merge --no-ff  FLEX-
- you can now push: git push
- you can remove your local branch if you want now it is unused: git br -d
FLEX-


I hope that helps

-Fred

-Message d'origine- 
From: Harbs

Sent: Friday, April 05, 2013 11:06 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

Hi Fred,

I've read those pages. (I see now you've updated them.) Conceptually, I sort
of got the idea of how to do things, but I find that until I actually do
something once, I don't quite "get" it… If someone could walk me through
this once, I think I'l be a lot more comfortable that I'm doing things
right.

There's also been a lot of discussion on when to rebase and when not. I'm
not clear on whether there has been a consensus on that. Looking at the
graph, it seems to me that not everyone is working exactly the same way.
(unless I don't know how to read the graph, which is also possible…)


On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote:


Hi Harbs,

Check the wiki first for a complete workflow guideline and git setup, if 
you need more info, ask them after you reviewed this wiki pages [1] [2], 
there are even interactive tutorials really well done. [1] [2]


I advice that to everybody, for myself, until everyone understood and 
applied the basics written in the wiki, I won't touch the SDK anymore.


-Fred

[1] 
https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide

[2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage



-Message d'origine- From: Harbs
Sent: Friday, April 05, 2013 10:14 AM
To: dev@flex.apache.org
Subject: Still confused by git

I've tried to follow all the git discussions. But, after all the 
discussions on how to use git, I'm still confused on the basics.


Here's what I need to know right now:
Right now I have a number of files I've edited outside my working 
directory related to ColorPicker inside experimental. I'd like to commit 
this work to the develop branch. It probably makes sense to create a 
branch to indicate the work I'm doing on this. (or not?)


I'm using SourceTree on Mac. I'd rather not mess with the command line.

So far I've checked out develop and master. The index view shows a bunch 
of modified and deleted files. I have not yet touched any of the git 
folders on my machine.


How do I?
1) Make sure my working copy is up to date?
2) Make sure my working coy is the correct branch? (Does that make sense?)
3) Create a new branch? (Or do I?)
4) Get my changes up to origin?

I've seen a lot of talk about switching between branches, but this stuff 
is all very fuzzy to me and kind of scary… ;-)


Harbs

Re: Still confused by git

[Frédéric THOMAS]

oops, reverse the 2 furst steps:


-If you have some modified files in your working tree, save them first: git 
stash -u "my current work"

-Checkout the develop branch: git co develop

-Fred

-Message d'origine- 
From: Frédéric THOMAS

Sent: Friday, April 05, 2013 11:31 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

You right Harbs, that currently looks something I dislike at the point I
won't work anymore on that tree.

Well, for your case (I assume you updated your .gitconfig as shown in the
Wiki) :
-If you have some modified files in your working tree, save them first: git
stash -u "my current work"
-Be sure the branch is up to date before to start working on it: git
pull --rebase
-create the branch you will work on, assuming your create a JIRA first: git
co -b "FLEX-"
-get back the work you save on this branch: git stash pop
-Edit/add files/dirs
-Add them to the staged area(also called index) and commit, you've got 2
choices, either you do 1 commit or more:
 1- To add all of them in a once, that's in order to do only one commit:
   - git add .
   - git ci -m "FLEX-: Fixed this"
 2- To add them one by one, that's in order to make more commits
   - git add  
   - git ci -m "FLEX-: Fixed this in my 1rst commit"
   - git add  
   - git ci -m "FLEX-: Fixed this in my 2nd commit"
- check all the files are committed: git st
- If there are more repeat the add/commit steps, otherwise, go back on the
develop branch: git co develop
- rebase your work on what the others did: git pull --rebase
- Merge your branch to the develop one: git merge --no-ff  FLEX-
- you can now push: git push
- you can remove your local branch if you want now it is unused: git br -d
FLEX-


I hope that helps

-Fred

-Message d'origine- 
From: Harbs

Sent: Friday, April 05, 2013 11:06 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

Hi Fred,

I've read those pages. (I see now you've updated them.) Conceptually, I sort
of got the idea of how to do things, but I find that until I actually do
something once, I don't quite "get" it… If someone could walk me through
this once, I think I'l be a lot more comfortable that I'm doing things
right.

There's also been a lot of discussion on when to rebase and when not. I'm
not clear on whether there has been a consensus on that. Looking at the
graph, it seems to me that not everyone is working exactly the same way.
(unless I don't know how to read the graph, which is also possible…)


On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote:


Hi Harbs,

Check the wiki first for a complete workflow guideline and git setup, if 
you need more info, ask them after you reviewed this wiki pages [1] [2], 
there are even interactive tutorials really well done. [1] [2]


I advice that to everybody, for myself, until everyone understood and 
applied the basics written in the wiki, I won't touch the SDK anymore.


-Fred

[1] 
https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide

[2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage



-Message d'origine- From: Harbs
Sent: Friday, April 05, 2013 10:14 AM
To: dev@flex.apache.org
Subject: Still confused by git

I've tried to follow all the git discussions. But, after all the 
discussions on how to use git, I'm still confused on the basics.


Here's what I need to know right now:
Right now I have a number of files I've edited outside my working 
directory related to ColorPicker inside experimental. I'd like to commit 
this work to the develop branch. It probably makes sense to create a 
branch to indicate the work I'm doing on this. (or not?)


I'm using SourceTree on Mac. I'd rather not mess with the command line.

So far I've checked out develop and master. The index view shows a bunch 
of modified and deleted files. I have not yet touched any of the git 
folders on my machine.


How do I?
1) Make sure my working copy is up to date?
2) Make sure my working coy is the correct branch? (Does that make sense?)
3) Create a new branch? (Or do I?)
4) Get my changes up to origin?

I've seen a lot of talk about switching between branches, but this stuff 
is all very fuzzy to me and kind of scary… ;-)


Harbs

Re: Still confused by git

[Frédéric THOMAS]

You right Harbs, that currently looks something I dislike at the point I 
won't work anymore on that tree.


Well, for your case (I assume you updated your .gitconfig as shown in the 
Wiki) :


-Checkout the develop branch: git co develop
-If you have some modified files in your working tree, save them first: git 
stash -u "my current work"
-Be sure the branch is up to date before to start working on it: git 
pull --rebase
-create the branch you will work on, assuming your create a JIRA first: git 
co -b "FLEX-"

-get back the work you save on this branch: git stash pop
-Edit/add files/dirs
-Add them to the staged area(also called index) and commit, you've got 2 
choices, either you do 1 commit or more:

 1- To add all of them in a once, that's in order to do only one commit:
   - git add .
   - git ci -m "FLEX-: Fixed this"
 2- To add them one by one, that's in order to make more commits
   - git add  
   - git ci -m "FLEX-: Fixed this in my 1rst commit"
   - git add  
   - git ci -m "FLEX-: Fixed this in my 2nd commit"
- check all the files are committed: git st
- If there are more repeat the add/commit steps, otherwise, go back on the 
develop branch: git co develop

- rebase your work on what the others did: git pull --rebase
- Merge your branch to the develop one: git merge --no-ff  FLEX-
- you can now push: git push
- you can remove your local branch if you want now it is unused: git br -d 
FLEX-



I hope that helps

-Fred

-Message d'origine- 
From: Harbs

Sent: Friday, April 05, 2013 11:06 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

Hi Fred,

I've read those pages. (I see now you've updated them.) Conceptually, I sort 
of got the idea of how to do things, but I find that until I actually do 
something once, I don't quite "get" it… If someone could walk me through 
this once, I think I'l be a lot more comfortable that I'm doing things 
right.


There's also been a lot of discussion on when to rebase and when not. I'm 
not clear on whether there has been a consensus on that. Looking at the 
graph, it seems to me that not everyone is working exactly the same way. 
(unless I don't know how to read the graph, which is also possible…)



On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote:


Hi Harbs,

Check the wiki first for a complete workflow guideline and git setup, if 
you need more info, ask them after you reviewed this wiki pages [1] [2], 
there are even interactive tutorials really well done. [1] [2]


I advice that to everybody, for myself, until everyone understood and 
applied the basics written in the wiki, I won't touch the SDK anymore.


-Fred

[1] 
https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide

[2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage



-Message d'origine- From: Harbs
Sent: Friday, April 05, 2013 10:14 AM
To: dev@flex.apache.org
Subject: Still confused by git

I've tried to follow all the git discussions. But, after all the 
discussions on how to use git, I'm still confused on the basics.


Here's what I need to know right now:
Right now I have a number of files I've edited outside my working 
directory related to ColorPicker inside experimental. I'd like to commit 
this work to the develop branch. It probably makes sense to create a 
branch to indicate the work I'm doing on this. (or not?)


I'm using SourceTree on Mac. I'd rather not mess with the command line.

So far I've checked out develop and master. The index view shows a bunch 
of modified and deleted files. I have not yet touched any of the git 
folders on my machine.


How do I?
1) Make sure my working copy is up to date?
2) Make sure my working coy is the correct branch? (Does that make sense?)
3) Create a new branch? (Or do I?)
4) Get my changes up to origin?

I've seen a lot of talk about switching between branches, but this stuff 
is all very fuzzy to me and kind of scary… ;-)


Harbs

Re: Still confused by git

[Harbs]

Hi Fred,

I've read those pages. (I see now you've updated them.) Conceptually, I sort of 
got the idea of how to do things, but I find that until I actually do something 
once, I don't quite "get" it… If someone could walk me through this once, I 
think I'l be a lot more comfortable that I'm doing things right.

There's also been a lot of discussion on when to rebase and when not. I'm not 
clear on whether there has been a consensus on that. Looking at the graph, it 
seems to me that not everyone is working exactly the same way. (unless I don't 
know how to read the graph, which is also possible…)


On Apr 5, 2013, at 11:29 AM, Frédéric THOMAS wrote:

> Hi Harbs,
> 
> Check the wiki first for a complete workflow guideline and git setup, if you 
> need more info, ask them after you reviewed this wiki pages [1] [2], there 
> are even interactive tutorials really well done. [1] [2]
> 
> I advice that to everybody, for myself, until everyone understood and applied 
> the basics written in the wiki, I won't touch the SDK anymore.
> 
> -Fred
> 
> [1] https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide
> [2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage
> 
> 
> 
> -Message d'origine- From: Harbs
> Sent: Friday, April 05, 2013 10:14 AM
> To: dev@flex.apache.org
> Subject: Still confused by git
> 
> I've tried to follow all the git discussions. But, after all the discussions 
> on how to use git, I'm still confused on the basics.
> 
> Here's what I need to know right now:
> Right now I have a number of files I've edited outside my working directory 
> related to ColorPicker inside experimental. I'd like to commit this work to 
> the develop branch. It probably makes sense to create a branch to indicate 
> the work I'm doing on this. (or not?)
> 
> I'm using SourceTree on Mac. I'd rather not mess with the command line.
> 
> So far I've checked out develop and master. The index view shows a bunch of 
> modified and deleted files. I have not yet touched any of the git folders on 
> my machine.
> 
> How do I?
> 1) Make sure my working copy is up to date?
> 2) Make sure my working coy is the correct branch? (Does that make sense?)
> 3) Create a new branch? (Or do I?)
> 4) Get my changes up to origin?
> 
> I've seen a lot of talk about switching between branches, but this stuff is 
> all very fuzzy to me and kind of scary… ;-)
> 
> Harbs 

[jira] [Commented] (FLEX-33236) Calling automationManager2.getChildren() on Spark DataGrid causes memory leak

[Peter Celuch (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLEX-33236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13623470#comment-13623470
 ] 

Peter Celuch commented on FLEX-33236:
-

Can anyone take a look at this issue? Being able to automate testing should be 
priority #1. Untestable framework is useless in enterprise applications.

> Calling automationManager2.getChildren() on Spark DataGrid causes memory leak
> -
>
> Key: FLEX-33236
> URL: https://issues.apache.org/jira/browse/FLEX-33236
> Project: Apache Flex
>  Issue Type: Bug
>  Components: AgentAPI, Spark: DataGrid
>Affects Versions: Adobe Flex SDK 4.6 (Release)
> Environment: Windows 7, Flash Builder 4.x, Internet Explorer 9
>Reporter: Tigran Najaryan
>  Labels: automation
> Attachments: MemoryLeakTest.fxp
>
>
> To reproduce:
> 1. Import attached project to Flash Builder and run in Profile mode. 
> 2. Let the application load in browser and click "getAutomationChildrenArray" 
> button. 
> 3. Watch how on every attempt to get children the total memory shown in flash 
> Builder Profiler view grows and never goes down.
> The problem can be also seen clearly without profiler. Just watch 
> "iexplore.exe" process memory consumption in Task Manager.
> The problem only occurs if there are item renderers that are not visible.
> Possibly caused by GridColumnHeaderGroupLayout/getHeaderRendererAt() creating 
> item renderer at line 597 via call to allocateVisualElement and never 
> releasing it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Still confused by git

[Frédéric THOMAS]

Btw, I just updated 
https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide 
with few more aliases.


-Fred

-Message d'origine- 
From: Frédéric THOMAS

Sent: Friday, April 05, 2013 10:29 AM
To: dev@flex.apache.org
Subject: Re: Still confused by git

Hi Harbs,

Check the wiki first for a complete workflow guideline and git setup, if you
need more info, ask them after you reviewed this wiki pages [1] [2], there
are even interactive tutorials really well done. [1] [2]

I advice that to everybody, for myself, until everyone understood and
applied the basics written in the wiki, I won't touch the SDK anymore.

-Fred

[1]
https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide
[2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage



-Message d'origine- 
From: Harbs

Sent: Friday, April 05, 2013 10:14 AM
To: dev@flex.apache.org
Subject: Still confused by git

I've tried to follow all the git discussions. But, after all the discussions
on how to use git, I'm still confused on the basics.

Here's what I need to know right now:
Right now I have a number of files I've edited outside my working directory
related to ColorPicker inside experimental. I'd like to commit this work to
the develop branch. It probably makes sense to create a branch to indicate
the work I'm doing on this. (or not?)

I'm using SourceTree on Mac. I'd rather not mess with the command line.

So far I've checked out develop and master. The index view shows a bunch of
modified and deleted files. I have not yet touched any of the git folders on
my machine.

How do I?
1) Make sure my working copy is up to date?
2) Make sure my working coy is the correct branch? (Does that make sense?)
3) Create a new branch? (Or do I?)
4) Get my changes up to origin?

I've seen a lot of talk about switching between branches, but this stuff is
all very fuzzy to me and kind of scary… ;-)

Harbs

FalconJX mxmlc error

[Tigran Najaryan]

OK, I built FalconJX but how do I use it properly? Simply running mxmlc
without a command line gives an error:

D:\WORK\Projects\ApacheFlex\repo\falcon\trunk\compiler.jx\bin>mxmlc
Using Flex SDK: D:\WORK\Projects\ApacheFlex\repo\sdk\branches\develop
Exception in thread "main" java.lang.UnsupportedOperationException
at
org.apache.flex.compiler.internal.driver.as.ASBackend.getSourceFileHandlerIn
stance(ASBackend.java:70)
at org.apache.flex.compiler.clients.MXMLJSC.(MXMLJSC.java:201)
at org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:169)


Looks like it selects AS backend where getSourceFileHandlerInstanceI() is
not implemented. 

>From the MXMLJSC.java I can see it expects a -js-output-type= parameter.
Calling with any of -js-output-type=flexjs, -js-output-type=good or
-js-output-type=amd results in another error in
WorkspaceProblemFormatter.java but I do not even have the source file in my
org/apache/flex/compiler/clients/problems directory. 

Here is the error:

D:\WORK\Projects\ApacheFlex\repo\falcon\trunk\compiler.jx\bin>mxmlc
-js-output-type=flexjs
D:\WORK\Projects\ApacheFlex\repo\falcon\trunk\compiler.js\tests\TestApp.as
Using Flex SDK: D:\WORK\Projects\ApacheFlex\repo\sdk\branches\develop
Exception in thread "main" com.google.common.collect.ComputationException:
java.lang.IllegalAccessError: tried to access method
com.google.common.collect.MapMaker.maximumSize(I)Lcom/google/common/collect/
MapMaker; from class
org.apache.flex.compiler.clients.problems.WorkspaceProblemFormatter$FileLine
Info
at
com.google.common.collect.MapMaker$ComputingMapAdapter.get(MapMaker.java:887
)
at
org.apache.flex.compiler.clients.problems.WorkspaceProblemFormatter.getLineT
ext(WorkspaceProblemFormatter.java:207)
at
org.apache.flex.compiler.clients.problems.WorkspaceProblemFormatter.format(W
orkspaceProblemFormatter.java:132)
at
org.apache.flex.compiler.clients.problems.ProblemPrinter.printProblems(Probl
emPrinter.java:90)
at
org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:225)
at org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:171)
Caused by: java.lang.IllegalAccessError: tried to access method
com.google.common.collect.MapMaker.maximumSize(I)Lcom/google/common/collect/
MapMaker; from class
org.apache.flex.compiler.clients.problems.WorkspaceProblemFormatter$FileLine
Info
at
org.apache.flex.compiler.clients.problems.WorkspaceProblemFormatter$FileLine
Info.(WorkspaceProblemFormatter.java:258)
at
org.apache.flex.compiler.clients.problems.WorkspaceProblemFormatter$1.apply(
WorkspaceProblemFormatter.java:103)
at
org.apache.flex.compiler.clients.problems.WorkspaceProblemFormatter$1.apply(
WorkspaceProblemFormatter.java:98)
at
com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference
.compute(ComputingConcurrentHashMap.java:356)
at
com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.comput
e(ComputingConcurrentHashMap.java:182)
at
com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrC
ompute(ComputingConcurrentHashMap.java:151)
at
com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingC
oncurrentHashMap.java:67)
at
com.google.common.collect.MapMaker$ComputingMapAdapter.get(MapMaker.java:883
)
... 5 more



Also tried compiling the FlexJSTest_again and get exact same error message.


Did I build FalconJX incorrectly or am I using it incorrectly?

Thanks.



-Original Message-
From: Alex Harui [mailto:aha...@adobe.com] 
Sent: Thursday, April 04, 2013 5:59 PM
To: dev@flex.apache.org
Subject: Re: Error compiling TestApp sample using FalconJS

The classpaths may have changed to break just running mxmlc from the bin
directory.  I would recommend getting set up on FalconJX instead if you are
planning to contribute code going forward.  If you want to try to use
FalconJS for now, then use the FlexJSOverlay.zip as it sets up the classes
in the class path properly.

Re: Still confused by git

[Frédéric THOMAS]

Hi Harbs,

Check the wiki first for a complete workflow guideline and git setup, if you 
need more info, ask them after you reviewed this wiki pages [1] [2], there 
are even interactive tutorials really well done. [1] [2]


I advice that to everybody, for myself, until everyone understood and 
applied the basics written in the wiki, I won't touch the SDK anymore.


-Fred

[1] 
https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide

[2] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage



-Message d'origine- 
From: Harbs

Sent: Friday, April 05, 2013 10:14 AM
To: dev@flex.apache.org
Subject: Still confused by git

I've tried to follow all the git discussions. But, after all the discussions 
on how to use git, I'm still confused on the basics.


Here's what I need to know right now:
Right now I have a number of files I've edited outside my working directory 
related to ColorPicker inside experimental. I'd like to commit this work to 
the develop branch. It probably makes sense to create a branch to indicate 
the work I'm doing on this. (or not?)


I'm using SourceTree on Mac. I'd rather not mess with the command line.

So far I've checked out develop and master. The index view shows a bunch of 
modified and deleted files. I have not yet touched any of the git folders on 
my machine.


How do I?
1) Make sure my working copy is up to date?
2) Make sure my working coy is the correct branch? (Does that make sense?)
3) Create a new branch? (Or do I?)
4) Get my changes up to origin?

I've seen a lot of talk about switching between branches, but this stuff is 
all very fuzzy to me and kind of scary… ;-)


Harbs 

Still confused by git

[Harbs]

I've tried to follow all the git discussions. But, after all the discussions on 
how to use git, I'm still confused on the basics.

Here's what I need to know right now:
Right now I have a number of files I've edited outside my working directory 
related to ColorPicker inside experimental. I'd like to commit this work to the 
develop branch. It probably makes sense to create a branch to indicate the work 
I'm doing on this. (or not?)

I'm using SourceTree on Mac. I'd rather not mess with the command line.

So far I've checked out develop and master. The index view shows a bunch of 
modified and deleted files. I have not yet touched any of the git folders on my 
machine.

How do I?
1) Make sure my working copy is up to date?
2) Make sure my working coy is the correct branch? (Does that make sense?)
3) Create a new branch? (Or do I?)
4) Get my changes up to origin?

I've seen a lot of talk about switching between branches, but this stuff is all 
very fuzzy to me and kind of scary… ;-)

Harbs

[jira] [Created] (FLEX-33476) Get Involved Page Outdated

[Harbs (JIRA)]

Harbs created FLEX-33476:


 Summary: Get Involved Page Outdated
 Key: FLEX-33476
 URL: https://issues.apache.org/jira/browse/FLEX-33476
 Project: Apache Flex
  Issue Type: Documentation
Reporter: Harbs
Priority: Minor


The "Get Involved" page here https://flex.apache.org/community-getinvolved.html 
refers to svn instead of git.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: General Questions on committing code

[Justin Mclean]

Hi,

> Besides adding dataProvider support to make it functionally equivalent to the 
> mx one, I added support for "no color" and proper handling of null objects in 
> the dataProvider (to indicate "no color"). Although it seems to work 
> correctly for my personal use, I have not done extensive testing. Should I 
> commit the code as-is, and hope it works/will be better tested later? Wait? 
> Something else? I'm just not sure on proper procedure here…
Policy is commit first and review second.Having more eyes on it will improve 
the quality. The experimental namespace is exactly for components like that 
that ie functional but not fully tested.

> Also, is there a policy on code formatting? Do we care that all code 
> formatting styles match?
It's nice that the code formatting matches the existing SDK code where possible 
(and yes there's inconsistencies).

> If yes, is there a document on this somewhere?
There was some Adobe documentation a search of the mailing list should find it.

Thanks,
Justin