Apache Flex Installer Problem

2015-11-19 Thread Buranello Alan
i try to install apache flex js 0.5.0, but:

Installer version 3.2.0 (windows)
Using Locale: it_IT
Fetched the SDK download mirror URL from the CGI.
SDK version Apache FlexJS 0.5.0
AIR version 19.0
Flash Player version 19.0
Creating Apache FlexJS home
Creating temporary directory
Downloading Apache FlexJS from:http://ftp.wayne.edu/apache/
flex/flexjs/0.5.0/binaries/apache-flex-flexjs-0.5.0-bin.zip
Verifying Apache FlexJS MD5 Signature
The Apache FlexJS MD5 Signature of the downloaded files matches the
reference. The file is valid.
Uncompressing: C:\Users\Alan\Documents\Lavoro\Informatica\Flex
JS\temp\apache-flex-flexjs-0.5.0-bin.zip
Finished uncompressing: C:\Users\Alan\Documents\Lavoro\Informatica\Flex
JS\temp\apache-flex-flexjs-0.5.0-bin.zip
Java is C:\ProgramData\Oracle\Java\javapath\java.exe
Installing Apache Flex Falcon Compiler from:
http://www.apache.org/dyn/mirrors/mirrors.cgi/flex/falcon/0.5.0/binaries/apache-flex-falconjx-0.5.0-bin.zip
Installing Apache Flex Falcon Compiler from:
http://apache.panu.it/flex/falcon/0.5.0/binaries/apache-flex-falconjx-0.5.0-bin.zip
Validating download: C:\Users\Alan\Documents\Lavoro\Informatica\Flex
JS/in/apache-flex-falconjx-0.5.0-bin.zip
FalconJX download failed


-- 

*Alan Buranello*

*alan.burane...@sipe.it *

-- 


--
*SIPE s.r.l.* Via Colombo, 4 - 30037 Scorzè (VE)

www.sipe.it

Tel. :+39 041 5848111
Fax :+39 041 5840177  
--

Privacy 


do-while-false

2015-11-19 Thread Harbs
There’s a coding pattern that I like to use which I picked up from the InDesign 
SDK. When there’s some code which needs a lot of conditions to be executed, 
it’s hard to write the conditions in a way that’s easily human readable.

You can either do:
if(conditiona && conditionb && conditionc &&conditiond(
{
//do something
}

or:
if(conditiona){
  if(conditionb){
if(conditionc){
  if(conditiond){
// do something
  }
}
  }
}

Both of these are kind of hard on the eyes and make fixes error-prone.

The do-while-false solution is much more ledgible than both of these and it 
goes like this:

do{
if(!conditiona){break};
if(!conditionb){break};
if(!conditionc){break};
if(!conditiond){break};
//do something
}while(false);

The reason it works is that do-while-false executes exactly once, and break 
leaves the “loop”.

The pattern reverses the logic and instead of checking when you *should* 
execute the code, it checks when you should bail out. The reason I like this 
pattern is because it makes for much flatter code and each condition stands on 
its own. That makes it easy to read and fix conditions at a later point.

How do folks feel about trying to use this pattern?

What prompted this post is commit b29975c which attempts to make a mess of 
conditions for invalidateSkinState() a bit clearer.

Thoughts?
Harbs

Re: do-while-false

2015-11-19 Thread Maxim Solodovnik
I personally prefer

if(conditiona && conditionb && conditionc &&conditiond)
{
//do something
}

it is shorter and more clear to me
not sure about performance, but I guess "if(conditiona && conditionb &&
conditionc &&conditiond)" should produce better native code

On Thu, Nov 19, 2015 at 2:16 PM, Harbs  wrote:

> There’s a coding pattern that I like to use which I picked up from the
> InDesign SDK. When there’s some code which needs a lot of conditions to be
> executed, it’s hard to write the conditions in a way that’s easily human
> readable.
>
> You can either do:
> if(conditiona && conditionb && conditionc &&conditiond(
> {
> //do something
> }
>
> or:
> if(conditiona){
>   if(conditionb){
> if(conditionc){
>   if(conditiond){
> // do something
>   }
> }
>   }
> }
>
> Both of these are kind of hard on the eyes and make fixes error-prone.
>
> The do-while-false solution is much more ledgible than both of these and
> it goes like this:
>
> do{
> if(!conditiona){break};
> if(!conditionb){break};
> if(!conditionc){break};
> if(!conditiond){break};
> //do something
> }while(false);
>
> The reason it works is that do-while-false executes exactly once, and
> break leaves the “loop”.
>
> The pattern reverses the logic and instead of checking when you *should*
> execute the code, it checks when you should bail out. The reason I like
> this pattern is because it makes for much flatter code and each condition
> stands on its own. That makes it easy to read and fix conditions at a later
> point.
>
> How do folks feel about trying to use this pattern?
>
> What prompted this post is commit b29975c which attempts to make a mess of
> conditions for invalidateSkinState() a bit clearer.
>
> Thoughts?
> Harbs




-- 
WBR
Maxim aka solomax


Re: do-while-false

2015-11-19 Thread Justin Mclean
Hi,

I prefer:

if (giveItName()) {
….
}

giveItName() {
return condition1 && condition2 && condition3;
}

Thanks,
Justin

Re: do-while-false

2015-11-19 Thread piotrz
Hi Harbs,

Really extraordinary way of use do-while. I love it and I'm ok with using it
in invalidateSkinState!

Thanks for sharing it!

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/do-while-false-tp50229p50232.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.


[Anounce] Apache Flex BlazeDS 4.7.2 released

2015-11-19 Thread Christofer Dutz

The Apache Flex team is pleased to annonce the release of Apache Flex
BlazeDS 4.7.2.

Apache Flex BlazeDS is the server-based Java remoting and web messaging
technology that enables developers to easily connect to back-end
distributed
data and push data in real-time to Adobe(r) Flex(r) and Adobe AIR(tm)
applications
for more responsive rich Internet application (RIA) experiences..

Apache Flex BlazeDS 4.7.2 is the third release of BlazeDS from the Apache
Software Foundation and introduces a new configuration option to allow
expansion of external xml entities. Users are able to enable this feature
by setting "allowXmlExternalEntityExpansion" to true.

The source packages can be downloaded from
http://www.us.apache.org/dist/flex/BlazeDS/4.7.2/
or one of Apache's mirror sites. Maven artifacts have been published to
Apaches Maven Repository
(https://repository.apache.org/content/repositories/releases/org/apache/flex/blazeds/)
and are
available from Maven Central.

For detailed information about Apache Flex please visit
http://flex.apache.org/


Re: Apache Flex Installer Problem

2015-11-19 Thread Tom Chiverton

Can you retrieve this file manually ?
Are you behind a proxy or firewall that could block it ?
Can you try again ?

Tom

On 19/11/15 08:09, Buranello Alan wrote:

Installing Apache Flex Falcon Compiler from:
http://apache.panu.it/flex/falcon/0.5.0/binaries/apache-flex-falconjx-0.5.0-bin.zip
Validating download: C:\Users\Alan\Documents\Lavoro\Informatica\Flex
JS/in/apache-flex-falconjx-0.5.0-bin.zip
FalconJX download failed




Mustella fixing (was Re: Next Flex SDK release)

2015-11-19 Thread Tom Chiverton

OK. The last run failed, and was not in progress.

I ran all four players in that folder and closed them.

Let's see what happens on the next run

Tom

On 18/11/15 22:52, Alex Harui wrote:

The mustella server has caught legitimate issues, most recently with some
sort behavior changes.  But yeah, it usually starts failing with a lot of
bitmap failures after a couple of days.  I would like someone else to try
my magic potion for getting Mustella back in order.  It is:

-log into the server,
-open ApacheFlex/dependencies/FlashPlayer_Debug and click on and close
each debug player.

It might help to make sure there isn't a run in progress or at least note
that a run is in progress so you'll know not to worry if the next run
report isn't clean.

-Alex


On 11/18/15, 2:17 AM, "Tom Chiverton"  wrote:


I've never seen a 'real' failure. It always seems to be Mustella
screwing itself up.

I don't have a Windows machine to chase them down with.

Tom

On 18/11/15 07:22, Justin Mclean wrote:

Hi,


The flex-sdk_mustella Jenkin's task does not currently pass:
http://flex-mustella.cloudapp.net/ 

Does anyone know if the machine just need a bit of maintaince or are
these do to real failures?

I can see that the RC jobs have not run successfully for 7 months and
flex sdks muscle has been broken for 1 1/2 months.

Thanks,
Justin

__
This email has been scanned by the Symantec Email Security.cloud
service.
For more information please visit http://www.symanteccloud.com
__


__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__





RE: do-while-false

2015-11-19 Thread Kessler CTR Mark J
Let me see if I can reformat into all the examples so we can have a real sample 
for people.  Below shows the original, what was committed.  Then shows the last 
few examples. Hopefully this won't get word wrapped to badly or have font 
issues.

The original was changed to better group the sets of conditions and added 
brackets to be able to see the "do something" separated from the conditions 
better.  My input for it would be; what you choose will be based on the current 
code and will vary with each case.  


Original:

if (prompt != null && prompt != "" && skin && skin.currentState &&
(skin.currentState.indexOf("WithPrompt") != -1 && text.length != 0 ||
 skin.currentState.indexOf("WithPrompt") == -1 && text.length == 0))
invalidateSkinState();


Commited:

if (prompt != null && prompt != "" && skin && skin.currentState)
{
if (skin.currentState.indexOf("WithPrompt") != -1 && text.length != 0 ||
skin.currentState.indexOf("WithPrompt") == -1 && text.length == 0)
{
invalidateSkinState();
}
}



example 1:

if (prompt != null)
{
if (prompt != "")
{
if (skin)
{
if (skin.currentState)
{
if (skin.currentState.indexOf("WithPrompt") != -1 && 
text.length != 0 ||
skin.currentState.indexOf("WithPrompt") == -1 && 
text.length == 0)
{
invalidateSkinState();
}
}
}
}
}


example 2:
do
{
if(prompt == null){break};
if(prompt == ""){break};
if(!skin){break};
if(!skin.currentState){break};
if(skin.currentState.indexOf("WithPrompt") == -1 && text.length != 0 ||
   skin.currentState.indexOf("WithPrompt") != -1 && text.length == 
0){break};

invalidateSkinState()
break;
} while(false);



-Mark

-Original Message-
From: Harbs [mailto:harbs.li...@gmail.com] 
Sent: Thursday, November 19, 2015 3:16 AM
To: dev@flex.apache.org
Subject: do-while-false

There’s a coding pattern that I like to use which I picked up from the InDesign 
SDK. When there’s some code which needs a lot of conditions to be executed, 
it’s hard to write the conditions in a way that’s easily human readable.

You can either do:
if(conditiona && conditionb && conditionc &&conditiond(
{
//do something
}

or:
if(conditiona){
  if(conditionb){
if(conditionc){
  if(conditiond){
// do something
  }
}
  }
}

Both of these are kind of hard on the eyes and make fixes error-prone.

The do-while-false solution is much more ledgible than both of these and it 
goes like this:

do{
if(!conditiona){break};
if(!conditionb){break};
if(!conditionc){break};
if(!conditiond){break};
//do something
}while(false);

The reason it works is that do-while-false executes exactly once, and break 
leaves the “loop”.

The pattern reverses the logic and instead of checking when you *should* 
execute the code, it checks when you should bail out. The reason I like this 
pattern is because it makes for much flatter code and each condition stands on 
its own. That makes it easy to read and fix conditions at a later point.

How do folks feel about trying to use this pattern?

What prompted this post is commit b29975c which attempts to make a mess of 
conditions for invalidateSkinState() a bit clearer.

Thoughts?
Harbs


Re: do-while-false

2015-11-19 Thread Maxim Solodovnik
I believe example2 need to be reformatted to match example1
do
{
if(prompt == null)
{
 break
};
if(prompt == "")
{
 break
};
if(!skin){
 break
};
if(!skin.currentState)
{
 break
};
if(skin.currentState.indexOf("WithPrompt") == -1 && text.length != 0 ||
   skin.currentState.indexOf("WithPrompt") != -1 && text.length == 0)
{
 break
};

invalidateSkinState()
break;
} while(false);

and most probably second if need to divided into 2 ifs :)

On Thu, Nov 19, 2015 at 6:51 PM, Kessler CTR Mark J <
mark.kessler@usmc.mil> wrote:

> Let me see if I can reformat into all the examples so we can have a real
> sample for people.  Below shows the original, what was committed.  Then
> shows the last few examples. Hopefully this won't get word wrapped to badly
> or have font issues.
>
> The original was changed to better group the sets of conditions and added
> brackets to be able to see the "do something" separated from the conditions
> better.  My input for it would be; what you choose will be based on the
> current code and will vary with each case.
>
>
> Original:
>
> if (prompt != null && prompt != "" && skin && skin.currentState &&
> (skin.currentState.indexOf("WithPrompt") != -1 && text.length != 0 ||
>  skin.currentState.indexOf("WithPrompt") == -1 && text.length == 0))
> invalidateSkinState();
>
>
> Commited:
>
> if (prompt != null && prompt != "" && skin && skin.currentState)
> {
> if (skin.currentState.indexOf("WithPrompt") != -1 && text.length != 0
> ||
> skin.currentState.indexOf("WithPrompt") == -1 && text.length == 0)
> {
> invalidateSkinState();
> }
> }
>
>
>
> example 1:
>
> if (prompt != null)
> {
> if (prompt != "")
> {
> if (skin)
> {
> if (skin.currentState)
> {
> if (skin.currentState.indexOf("WithPrompt") != -1 &&
> text.length != 0 ||
> skin.currentState.indexOf("WithPrompt") == -1 &&
> text.length == 0)
> {
> invalidateSkinState();
> }
> }
> }
> }
> }
>
>
> example 2:
> do
> {
> if(prompt == null){break};
> if(prompt == ""){break};
> if(!skin){break};
> if(!skin.currentState){break};
> if(skin.currentState.indexOf("WithPrompt") == -1 && text.length != 0 ||
>skin.currentState.indexOf("WithPrompt") != -1 && text.length ==
> 0){break};
>
> invalidateSkinState()
> break;
> } while(false);
>
>
>
> -Mark
>
> -Original Message-
> From: Harbs [mailto:harbs.li...@gmail.com]
> Sent: Thursday, November 19, 2015 3:16 AM
> To: dev@flex.apache.org
> Subject: do-while-false
>
> There’s a coding pattern that I like to use which I picked up from the
> InDesign SDK. When there’s some code which needs a lot of conditions to be
> executed, it’s hard to write the conditions in a way that’s easily human
> readable.
>
> You can either do:
> if(conditiona && conditionb && conditionc &&conditiond(
> {
> //do something
> }
>
> or:
> if(conditiona){
>   if(conditionb){
> if(conditionc){
>   if(conditiond){
> // do something
>   }
> }
>   }
> }
>
> Both of these are kind of hard on the eyes and make fixes error-prone.
>
> The do-while-false solution is much more ledgible than both of these and
> it goes like this:
>
> do{
> if(!conditiona){break};
> if(!conditionb){break};
> if(!conditionc){break};
> if(!conditiond){break};
> //do something
> }while(false);
>
> The reason it works is that do-while-false executes exactly once, and
> break leaves the “loop”.
>
> The pattern reverses the logic and instead of checking when you *should*
> execute the code, it checks when you should bail out. The reason I like
> this pattern is because it makes for much flatter code and each condition
> stands on its own. That makes it easy to read and fix conditions at a later
> point.
>
> How do folks feel about trying to use this pattern?
>
> What prompted this post is commit b29975c which attempts to make a mess of
> conditions for invalidateSkinState() a bit clearer.
>
> Thoughts?
> Harbs
>



-- 
WBR
Maxim aka solomax


Re: Apache Flex Installer Problem

2015-11-19 Thread Alex Harui
Hi Alan,

I'm sorry you are still having problems.  If you still are unsuccessful
after trying Tom's suggestions below, please also:

1) look in the destination folder for a folder called "in" and see if the
apache-flex-falconjx-0.5.0-bin.zip is in there (it might be in a
subfolder) and what size it is, and what the contents of the
apache-flex-falconjx-0.5.0-bin.zip.md5 file is, if it is there as well.
2) uninstall the Apache Flex Installer 3.2 and try Apache Flex Installer
3.1 from here: http://archive.apache.org/dist/flex/installer/3.1/binaries/

Thanks,
-Alex

On 11/19/15, 3:20 AM, "Tom Chiverton"  wrote:

>Can you retrieve this file manually ?
>Are you behind a proxy or firewall that could block it ?
>Can you try again ?
>
>Tom
>
>On 19/11/15 08:09, Buranello Alan wrote:
>> Installing Apache Flex Falcon Compiler from:
>> 
>>http://apache.panu.it/flex/falcon/0.5.0/binaries/apache-flex-falconjx-0.5
>>.0-bin.zip
>> Validating download: C:\Users\Alan\Documents\Lavoro\Informatica\Flex
>> JS/in/apache-flex-falconjx-0.5.0-bin.zip
>> FalconJX download failed
>



Re: do-while-false

2015-11-19 Thread Harbs
To be clear, I think Mark’s code was a nice compromise between approach #1 and 
approach #2.

In this case following Flex code formatting style, do-while-false should look 
something like this:

do
{
   if(prompt == null)
break;

   if(prompt == "")
break;

   if(!skin)
break;

   if(!skin.currentState)
break;

   if(skin.currentState.indexOf("WithPrompt") == -1 && text.length != 0)
break;

   if(skin.currentState.indexOf("WithPrompt") != -1 && text.length == 0)
break;

   invalidateSkinState();
} while(false);

An additional advantage here is that you can break up the OR statement into two 
separate conditions.

I’m also not proposing using this pattern all the time. Sure. For a few simple 
conditions if(a && b) is the simplest way to go. There are times when nested 
ifs make sense as well. If there’s a set of conditions which are used in a 
number of places, a function call like Justin mentions make the most sense 
there.

On Nov 19, 2015, at 3:19 PM, Maxim Solodovnik  wrote:

> I believe example2 need to be reformatted to match example1
> do
> {
>if(prompt == null)
>{
> break
>};
>if(prompt == "")
>{
> break
>};
>if(!skin){
> break
>};
>if(!skin.currentState)
>{
> break
>};
>if(skin.currentState.indexOf("WithPrompt") == -1 && text.length != 0 ||
>   skin.currentState.indexOf("WithPrompt") != -1 && text.length == 0)
>{
> break
>};
> 
>invalidateSkinState()
>break;
> } while(false);
> 
> and most probably second if need to divided into 2 ifs :)
> 
> On Thu, Nov 19, 2015 at 6:51 PM, Kessler CTR Mark J <
> mark.kessler@usmc.mil> wrote:
> 
>> Let me see if I can reformat into all the examples so we can have a real
>> sample for people.  Below shows the original, what was committed.  Then
>> shows the last few examples. Hopefully this won't get word wrapped to badly
>> or have font issues.
>> 
>> The original was changed to better group the sets of conditions and added
>> brackets to be able to see the "do something" separated from the conditions
>> better.  My input for it would be; what you choose will be based on the
>> current code and will vary with each case.
>> 
>> 
>> Original:
>> 
>> if (prompt != null && prompt != "" && skin && skin.currentState &&
>>(skin.currentState.indexOf("WithPrompt") != -1 && text.length != 0 ||
>> skin.currentState.indexOf("WithPrompt") == -1 && text.length == 0))
>>invalidateSkinState();
>> 
>> 
>> Commited:
>> 
>> if (prompt != null && prompt != "" && skin && skin.currentState)
>> {
>>if (skin.currentState.indexOf("WithPrompt") != -1 && text.length != 0
>> ||
>>skin.currentState.indexOf("WithPrompt") == -1 && text.length == 0)
>>{
>>invalidateSkinState();
>>}
>> }
>> 
>> 
>> 
>> example 1:
>> 
>> if (prompt != null)
>> {
>>if (prompt != "")
>>{
>>if (skin)
>>{
>>if (skin.currentState)
>>{
>>if (skin.currentState.indexOf("WithPrompt") != -1 &&
>> text.length != 0 ||
>>skin.currentState.indexOf("WithPrompt") == -1 &&
>> text.length == 0)
>>{
>>invalidateSkinState();
>>}
>>}
>>}
>>}
>> }
>> 
>> 
>> example 2:
>> do
>> {
>>if(prompt == null){break};
>>if(prompt == ""){break};
>>if(!skin){break};
>>if(!skin.currentState){break};
>>if(skin.currentState.indexOf("WithPrompt") == -1 && text.length != 0 ||
>>   skin.currentState.indexOf("WithPrompt") != -1 && text.length ==
>> 0){break};
>> 
>>invalidateSkinState()
>>break;
>> } while(false);
>> 
>> 
>> 
>> -Mark
>> 
>> -Original Message-
>> From: Harbs [mailto:harbs.li...@gmail.com]
>> Sent: Thursday, November 19, 2015 3:16 AM
>> To: dev@flex.apache.org
>> Subject: do-while-false
>> 
>> There’s a coding pattern that I like to use which I picked up from the
>> InDesign SDK. When there’s some code which needs a lot of conditions to be
>> executed, it’s hard to write the conditions in a way that’s easily human
>> readable.
>> 
>> You can either do:
>> if(conditiona && conditionb && conditionc &&conditiond(
>> {
>> //do something
>> }
>> 
>> or:
>> if(conditiona){
>>  if(conditionb){
>>if(conditionc){
>>  if(conditiond){
>>// do something
>>  }
>>}
>>  }
>> }
>> 
>> Both of these are kind of hard on the eyes and make fixes error-prone.
>> 
>> The do-while-false solution is much more ledgible than both of these and
>> it goes like this:
>> 
>> do{
>> if(!conditiona){break};
>> if(!conditionb){break};
>> if(!conditionc){break};
>> if(!conditiond){break};
>> //do something
>> }while(false);
>> 
>> The reason it works is that do-while-false executes exactly once, and
>> break leaves the “loop”.
>> 
>> The pattern reverses the logic and instead of checking when you *should*
>> execute the code, it checks when you should bail

Re: do-while-false

2015-11-19 Thread Harbs
Of course there’s no reason not to mix and match. In this case, I’d probably 
join similar conditions like this:

do
{
  if(prompt == null || prompt == "")
   break;

  if(!skin || !skin.currentState)
   break;

  if(skin.currentState.indexOf("WithPrompt") == -1 && text.length != 0)
   break;

  if(skin.currentState.indexOf("WithPrompt") != -1 && text.length == 0)
   break;

  invalidateSkinState();
} while(false);

On Nov 19, 2015, at 9:08 PM, Harbs  wrote:

> To be clear, I think Mark’s code was a nice compromise between approach #1 
> and approach #2.
> 
> In this case following Flex code formatting style, do-while-false should look 
> something like this:
> 
> do
> {
>   if(prompt == null)
>break;
> 
>   if(prompt == "")
>break;
> 
>   if(!skin)
>break;
> 
>   if(!skin.currentState)
>break;
> 
>   if(skin.currentState.indexOf("WithPrompt") == -1 && text.length != 0)
>break;
> 
>   if(skin.currentState.indexOf("WithPrompt") != -1 && text.length == 0)
>break;
> 
>   invalidateSkinState();
> } while(false);
> 
> An additional advantage here is that you can break up the OR statement into 
> two separate conditions.
> 
> I’m also not proposing using this pattern all the time. Sure. For a few 
> simple conditions if(a && b) is the simplest way to go. There are times when 
> nested ifs make sense as well. If there’s a set of conditions which are used 
> in a number of places, a function call like Justin mentions make the most 
> sense there.
> 
> On Nov 19, 2015, at 3:19 PM, Maxim Solodovnik  wrote:
> 
>> I believe example2 need to be reformatted to match example1
>> do
>> {
>>   if(prompt == null)
>>   {
>>break
>>   };
>>   if(prompt == "")
>>   {
>>break
>>   };
>>   if(!skin){
>>break
>>   };
>>   if(!skin.currentState)
>>   {
>>break
>>   };
>>   if(skin.currentState.indexOf("WithPrompt") == -1 && text.length != 0 ||
>>  skin.currentState.indexOf("WithPrompt") != -1 && text.length == 0)
>>   {
>>break
>>   };
>> 
>>   invalidateSkinState()
>>   break;
>> } while(false);
>> 
>> and most probably second if need to divided into 2 ifs :)
>> 
>> On Thu, Nov 19, 2015 at 6:51 PM, Kessler CTR Mark J <
>> mark.kessler@usmc.mil> wrote:
>> 
>>> Let me see if I can reformat into all the examples so we can have a real
>>> sample for people.  Below shows the original, what was committed.  Then
>>> shows the last few examples. Hopefully this won't get word wrapped to badly
>>> or have font issues.
>>> 
>>> The original was changed to better group the sets of conditions and added
>>> brackets to be able to see the "do something" separated from the conditions
>>> better.  My input for it would be; what you choose will be based on the
>>> current code and will vary with each case.
>>> 
>>> 
>>> Original:
>>> 
>>> if (prompt != null && prompt != "" && skin && skin.currentState &&
>>>   (skin.currentState.indexOf("WithPrompt") != -1 && text.length != 0 ||
>>>skin.currentState.indexOf("WithPrompt") == -1 && text.length == 0))
>>>   invalidateSkinState();
>>> 
>>> 
>>> Commited:
>>> 
>>> if (prompt != null && prompt != "" && skin && skin.currentState)
>>> {
>>>   if (skin.currentState.indexOf("WithPrompt") != -1 && text.length != 0
>>> ||
>>>   skin.currentState.indexOf("WithPrompt") == -1 && text.length == 0)
>>>   {
>>>   invalidateSkinState();
>>>   }
>>> }
>>> 
>>> 
>>> 
>>> example 1:
>>> 
>>> if (prompt != null)
>>> {
>>>   if (prompt != "")
>>>   {
>>>   if (skin)
>>>   {
>>>   if (skin.currentState)
>>>   {
>>>   if (skin.currentState.indexOf("WithPrompt") != -1 &&
>>> text.length != 0 ||
>>>   skin.currentState.indexOf("WithPrompt") == -1 &&
>>> text.length == 0)
>>>   {
>>>   invalidateSkinState();
>>>   }
>>>   }
>>>   }
>>>   }
>>> }
>>> 
>>> 
>>> example 2:
>>> do
>>> {
>>>   if(prompt == null){break};
>>>   if(prompt == ""){break};
>>>   if(!skin){break};
>>>   if(!skin.currentState){break};
>>>   if(skin.currentState.indexOf("WithPrompt") == -1 && text.length != 0 ||
>>>  skin.currentState.indexOf("WithPrompt") != -1 && text.length ==
>>> 0){break};
>>> 
>>>   invalidateSkinState()
>>>   break;
>>> } while(false);
>>> 
>>> 
>>> 
>>> -Mark
>>> 
>>> -Original Message-
>>> From: Harbs [mailto:harbs.li...@gmail.com]
>>> Sent: Thursday, November 19, 2015 3:16 AM
>>> To: dev@flex.apache.org
>>> Subject: do-while-false
>>> 
>>> There’s a coding pattern that I like to use which I picked up from the
>>> InDesign SDK. When there’s some code which needs a lot of conditions to be
>>> executed, it’s hard to write the conditions in a way that’s easily human
>>> readable.
>>> 
>>> You can either do:
>>> if(conditiona && conditionb && conditionc &&conditiond(
>>> {
>>> //do something
>>> }
>>> 
>>> or:
>>> if(conditiona){
>>> if(conditionb){
>>>   if(conditionc){
>>> if(conditiond){
>>> 

Re: do-while-false

2015-11-19 Thread Alex Harui
I don't think there is any reason to mandate any particular style.  If
that's the way you want to write some code, that's fine with me.

IMO, my brain thinks "loop" when it sees "do" as in, "something in here
may need to be done more than once", so if you do use this style, could
you try to remember to add a comment after the do?

do // while-false
{

Note that once you reversed the logic of the if conditions, you could also
code this section as an if-else chain.

if (prompt == null);
else if (prompt == "");
else if (!skin);
else if (!skin.currentState);
else if (skin.currentState.indexOf("WithPrompt") == -1 && text.length !=
0);
else if (skin.currentState.indexOf("WithPrompt") != -1 && text.length ==
0);
else
  invalidateSkinState();

But to me, just using whitespace seems sufficient:

if (!((prompt == null) ||
  (prompt === "") ||  // this code needs to be tested if the prompt is
"0"
  (!skin) ||
  (!skin.currentState) ||
  (skin.currentState.indexOf("WithPrompt") == -1 && text.length != 0)
||
  (skin.currentState.indexOf("WithPrompt") != -1 && text.length == 0)))

invalidateSkinState();

Or the original reformatted with white space:

if (prompt != null &&
prompt != "" &&
skin && 
skin.currentState &&
(skin.currentState.indexOf("WithPrompt") != -1 && text.length != 0 ||
 skin.currentState.indexOf("WithPrompt") == -1 && text.length == 0))
invalidateSkinState();


There is very little optimization in the compiler, so you have to
hand-optimize your code.  A smart compiler might not set up the do loop,
but our compilers will.  But that would rarely affect performance and only
adds a few bytes per usage, although it could add up for 1000's of usages.
 A smart compiler or smart runtime might inline the function that you
could wrap all the conditions into as some suggested because if it turns
out to be inside an important loop, you wouldn't want to pay for the
function call overhead.

Anyway, always interesting to see different code approaches.

-Alex

On 11/19/15, 11:08 AM, "Harbs"  wrote:

>To be clear, I think Mark’s code was a nice compromise between approach
>#1 and approach #2.
>
>In this case following Flex code formatting style, do-while-false should
>look something like this:
>
>do
>{
>   if(prompt == null)
>break;
>
>   if(prompt == "")
>break;
>
>   if(!skin)
>break;
>
>   if(!skin.currentState)
>break;
>
>   if(skin.currentState.indexOf("WithPrompt") == -1 && text.length != 0)
>break;
>
>   if(skin.currentState.indexOf("WithPrompt") != -1 && text.length == 0)
>break;
>
>   invalidateSkinState();
>} while(false);
>
>An additional advantage here is that you can break up the OR statement
>into two separate conditions.
>
>I’m also not proposing using this pattern all the time. Sure. For a few
>simple conditions if(a && b) is the simplest way to go. There are times
>when nested ifs make sense as well. If there’s a set of conditions which
>are used in a number of places, a function call like Justin mentions make
>the most sense there.
>
>On Nov 19, 2015, at 3:19 PM, Maxim Solodovnik 
>wrote:
>
>> I believe example2 need to be reformatted to match example1
>> do
>> {
>>if(prompt == null)
>>{
>> break
>>};
>>if(prompt == "")
>>{
>> break
>>};
>>if(!skin){
>> break
>>};
>>if(!skin.currentState)
>>{
>> break
>>};
>>if(skin.currentState.indexOf("WithPrompt") == -1 && text.length != 0
>>||
>>   skin.currentState.indexOf("WithPrompt") != -1 && text.length == 0)
>>{
>> break
>>};
>> 
>>invalidateSkinState()
>>break;
>> } while(false);
>> 
>> and most probably second if need to divided into 2 ifs :)
>> 
>> On Thu, Nov 19, 2015 at 6:51 PM, Kessler CTR Mark J <
>> mark.kessler@usmc.mil> wrote:
>> 
>>> Let me see if I can reformat into all the examples so we can have a
>>>real
>>> sample for people.  Below shows the original, what was committed.  Then
>>> shows the last few examples. Hopefully this won't get word wrapped to
>>>badly
>>> or have font issues.
>>> 
>>> The original was changed to better group the sets of conditions and
>>>added
>>> brackets to be able to see the "do something" separated from the
>>>conditions
>>> better.  My input for it would be; what you choose will be based on the
>>> current code and will vary with each case.
>>> 
>>> 
>>> Original:
>>> 
>>> if (prompt != null && prompt != "" && skin && skin.currentState &&
>>>(skin.currentState.indexOf("WithPrompt") != -1 && text.length != 0
>>>||
>>> skin.currentState.indexOf("WithPrompt") == -1 && text.length == 0))
>>>invalidateSkinState();
>>> 
>>> 
>>> Commited:
>>> 
>>> if (prompt != null && prompt != "" && skin && skin.currentState)
>>> {
>>>if (skin.currentState.indexOf("WithPrompt") != -1 && text.length !=
>>>0
>>> ||
>>>skin.currentState.indexOf("WithPrompt") == -1 && text.length ==
>>>0)
>>>{
>>>in

Re: Mustella fixing (was Re: Next Flex SDK release)

2015-11-19 Thread Alex Harui
Looks like Tom also has the magic, although I did reboot the server as
well to get past the repo access errors, but rebooting in the past wasn't
enough.

Air and Mobile are passing, and I would say the SDK errors are probably
real errors:  There are some Sort errors left over from some changes we
made, and a bunch of chart errors potentially due to this change:

commit 636859085bbd6794ce6b3950727e20c5aa2a665d
Author: OmPrakash Muppirala 
Date:   Wed Sep 9 18:00:24 2015 -0700

Fix for https://issues.apache.org/jira/browse/FLEX-34909 (Embedded
fonts not working on charts)

I took a look at one of the bad.png files from Charts and the fonts were
rendering differently, although I also think I saw a small difference in
the chart lines as well.  For Charts, it would be a good idea to verify
that the fonts are embedded and being used correctly before cutting new
baselines.  Any volunteers?


Thanks,
-Alex

On 11/19/15, 3:38 AM, "Tom Chiverton"  wrote:

>OK. The last run failed, and was not in progress.
>
>I ran all four players in that folder and closed them.
>
>Let's see what happens on the next run
>
>Tom
>
>On 18/11/15 22:52, Alex Harui wrote:
>> The mustella server has caught legitimate issues, most recently with
>>some
>> sort behavior changes.  But yeah, it usually starts failing with a lot
>>of
>> bitmap failures after a couple of days.  I would like someone else to
>>try
>> my magic potion for getting Mustella back in order.  It is:
>>
>> -log into the server,
>> -open ApacheFlex/dependencies/FlashPlayer_Debug and click on and close
>> each debug player.
>>
>> It might help to make sure there isn't a run in progress or at least
>>note
>> that a run is in progress so you'll know not to worry if the next run
>> report isn't clean.
>>
>> -Alex
>>
>>
>> On 11/18/15, 2:17 AM, "Tom Chiverton"  wrote:
>>
>>> I've never seen a 'real' failure. It always seems to be Mustella
>>> screwing itself up.
>>>
>>> I don't have a Windows machine to chase them down with.
>>>
>>> Tom
>>>
>>> On 18/11/15 07:22, Justin Mclean wrote:
 Hi,

> The flex-sdk_mustella Jenkin's task does not currently pass:
> http://flex-mustella.cloudapp.net/
>
 Does anyone know if the machine just need a bit of maintaince or are
 these do to real failures?

 I can see that the RC jobs have not run successfully for 7 months and
 flex sdks muscle has been broken for 1 1/2 months.

 Thanks,
 Justin

 __
 This email has been scanned by the Symantec Email Security.cloud
 service.
 For more information please visit http://www.symanteccloud.com
 __
>>
>> __
>> This email has been scanned by the Symantec Email Security.cloud
>>service.
>> For more information please visit http://www.symanteccloud.com
>> __
>>
>