On 10/20/14, 2:42 AM, "Tom Chiverton" wrote:
>If the .png's are different sizes, is it the fault of the version of the
>Player on the machine ?
Hard to say. I just ran the TileLayout tests on 11.7/3.7 on my Windows 7
machine and they all passed. I’m also pretty sure we’ve seen 11.7/3.7
pass o
If the .png's are different sizes, is it the fault of the version of the
Player on the machine ?
Tom
On 20/10/14 10:07, Erik de Bruin wrote:
I think it’s time, yes … Maybe we start by figuring out when the last good
run was, and which commits have been made since?
I think it’s time, yes … Maybe we start by figuring out when the last good
run was, and which commits have been made since?
EdB
On Mon, Oct 20, 2014 at 10:10 AM, Tom Chiverton wrote:
> On 16/10/14 19:35, Alex Harui wrote:
>
>> this particular incantation has worked both times. I did look and
On 16/10/14 19:35, Alex Harui wrote:
this particular incantation has worked both times. I did look and saw
Still failing, so I think we need a closer look at why the outputs are
different sizes to the expected ?
Tom
On 10/16/14, 10:26 AM, "Erik de Bruin" wrote:
>What you are describing is actually the expected result: the versions.txt
>file has the last combo that succeeded (11.1/3.7) and the log shows the
>last combo that was run: 11.7/3.7.
OK, I didn’t realize that. Anyway, that’s where we got stuck twic
What you are describing is actually the expected result: the versions.txt
file has the last combo that succeeded (11.1/3.7) and the log shows the
last combo that was run: 11.7/3.7.
EdB
On Thu, Oct 16, 2014 at 7:20 PM, Alex Harui wrote:
>
>
> On 10/16/14, 10:06 AM, "Erik de Bruin" wrote:
>
>
On 10/16/14, 10:06 AM, "Erik de Bruin" wrote:
>That can’t be it. That player combo has been part of the test suite runs
>since the beginning of time. Maybe it’s time to delete some workspaces
>(the
>files in them, at least ;-)) and see if a fresh start from Git solves
>something?
Well, twice in
Oops, that’s me discrediting myself as a bonafide software engineer by
saying stuff like: “That can’t be it.”
;-)
EdB
On Thu, Oct 16, 2014 at 7:06 PM, Erik de Bruin wrote:
> That can’t be it. That player combo has been part of the test suite runs
> since the beginning of time. Maybe it’s tim
That can’t be it. That player combo has been part of the test suite runs
since the beginning of time. Maybe it’s time to delete some workspaces (the
files in them, at least ;-)) and see if a fresh start from Git solves
something?
EdB
On Thu, Oct 16, 2014 at 6:05 PM, Alex Harui wrote:
> On 10/
On 10/16/14, 8:59 AM, "Tom Chiverton" wrote:
>On 15/10/14 16:53, Alex Harui wrote:
>> versions.txt file has:
>> FLASH_VERSION=11.1
>>AIR_VERSION=3.7
>What in this means it's gone wrong and needs removing ?
Don’t know for sure, but I think we want the AIR SWF version to match the
Flash SWF ver
On 15/10/14 16:53, Alex Harui wrote:
versions.txt file has:
FLASH_VERSION=11.1
AIR_VERSION=3.7
What in this means it's gone wrong and needs removing ?
Tom
The symptoms are the same as the last time things went bad. The
versions.txt file has:
FLASH_VERSION=11.1
AIR_VERSION=3.7
I’m going to cancel all jobs and delete that file and see if it gets it
act together, so ignore the next failure.
-Alex
On 10/15/14, 6:54 AM, "Erik de Bruin" wrote:
>Th
The last one really spectacularly!
EdB
On Wed, Oct 15, 2014 at 3:02 PM, Tom Chiverton wrote:
> On 14/10/14 15:51, Alex Harui wrote:
>
>> In general we don’t worry until two or three runs fail in a row.
>>
> Five in a row have now failed.
>
> Tom
>
--
Ix Multimedia Software
Jan Luykenstra
On 14/10/14 15:51, Alex Harui wrote:
In general we don’t worry until two or three runs fail in a row.
Five in a row have now failed.
Tom
In general we don’t worry until two or three runs fail in a row. I’ve
seen the player/air combination appear to get confused and cause strange
results.
On 10/14/14, 3:30 AM, "Tom Chiverton" wrote:
>I was reading
>http://flex-mustella.cloudapp.net/job/flex-sdk_mustella/lastFailedBuild/co
>nsole
I was reading
http://flex-mustella.cloudapp.net/job/flex-sdk_mustella/lastFailedBuild/console
and it's odd that
http://flex-mustella.cloudapp.net/job/flex-sdk_mustella/ws/mustella/tests/spark/styles/local/baselines/focusBlendMode_typeSelector.png.bad.png
and
http://flex-mustella.cloudapp.net/job/
47.n4.nabble.com/MUSTELLA-Help-diagnose-Mustella-failures-tp21123p36181.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
t;Unexpected Trace: Uwaga! B��d protoko�u HTTP dotycz�cy ��dania wys�ania,
>12029: /runid.properties?0.4312801482155919139538342
>Unexpected Trace: Uwaga! B��d protoko�u HTTP dotycz�cy ��dania wys�ania,
>12029: /step_timeout
>results: FAILED
>I:\flexsdk\flex-repo\flex-sdk\build.xml:1677: Java returned: 1
>
>
>
>
>
>-
>Apache Flex Committer
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>http://apache-flex-development.247.n4.nabble.com/MUSTELLA-Help-diagnos
>e-Mustella-failures-tp21123p36147.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
otoko�u HTTP dotycz�cy ��dania wys�ania,
12029: /step_timeout
results: FAILED
I:\flexsdk\flex-repo\flex-sdk\build.xml:1677: Java returned: 1
-
Apache Flex Committer
piotrzarzyck...@gmail.com
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/MUSTELLA-H
iew this message in context:
>http://apache-flex-development.247.n4.nabble.com/MUSTELLA-Help-diagnos
>e-Mustella-failures-tp21123p36144.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
pache Flex Committer
piotrzarzyck...@gmail.com
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/MUSTELLA-Help-diagnose-Mustella-failures-tp21123p36144.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
I think I saw some tests in the TLF repo, but I've never tried to run them.
On 3/20/14 12:34 AM, "Justin Mclean" wrote:
>HI,
>
>> This exactly what I did run checkintests from ant and got that error
>>after
>> all passed tests.
>>
>> Fix -> https://issues.apache.org/jira/browse/FLEX-34057
>
>Wh
:
>http://apache-flex-development.247.n4.nabble.com/MUSTELLA-Help-diagnos
>e-Mustella-failures-tp21123p36111.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
p://apache-flex-development.247.n4.nabble.com/MUSTELLA-Help-diagnose-Mustella-failures-tp21123p36115.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
HI,
> This exactly what I did run checkintests from ant and got that error after
> all passed tests.
>
> Fix -> https://issues.apache.org/jira/browse/FLEX-34057
While the mustella test may pick up something obvious. It may be better to run
the TLF tests (depending on where your change is) howev
2
Piotr
-
Apache Flex Committer
piotrzarzyck...@gmail.com
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/MUSTELLA-Help-diagnose-Mustella-failures-tp21123p36111.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
after
>all passed tests.
>
>Fix -> https://issues.apache.org/jira/browse/FLEX-34057
>
>Piotr
>
>
>
>-
>Apache Flex Committer
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>http://apache-flex-development.247.n4.nabble.com/MUSTELLA
.n4.nabble.com/MUSTELLA-Help-diagnose-Mustella-failures-tp21123p36107.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
HI,
> I've fixed some bug in sdk. Now I would like to run mustella tests, so based
> on point 7 (Bug fixing) from wiki I should run chackintests??
Run checkin test first by doing:
ant checkintests
The mustella tests can be run from the mustella directory using mini_run.sh but
you generally only
247.n4.nabble.com/MUSTELLA-Help-diagnose-Mustella-failures-tp21123p36094.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Set the launch URL to be something like 'http://a.a' and while it is
waiting to connect, launch another debug enabled SWF.
Tom
On 09/09/2013 04:37, Alex Harui wrote:
way more efficient to use FDB (for me). Supposedly there is a way to
create a generic project in FB, launch it in the debugger,
Ah, sorry. Forgot that this is a mobile test so you can't just launch it
in FDB because it needs AIR.
I have tried a couple of different workflows for mobile. For this test, I
started fdb and just typed run. Then I went to the mustella folder, typed
./mini_run.sh -rerun -timeout-6 and whate
Hi,
> From Finder or FB or command-line?
command line.
$fdb
(fdb) run SkinnablePopUpContainerSKEffects.swf
Attempting to launch and connect to Player using URL
SkinnablePopUpContainerSKEffects.swf
This result in the same blank swf:
fdb ./tests/mobile/SkinnablePopupContainerSK/ss/*.swf
Attemptin
On 9/8/13 8:49 PM, "Justin Mclean" wrote:
>HI,
>
>> OK, let's try to get you set up. Let us know what errors or failure
>> conditions you are hitting.
>No error occurs, swf launches but is blank and debugger hangs. Not really
>much to go on.
Puzzling. How are you launching? From Finder or FB
HI,
> OK, let's try to get you set up. Let us know what errors or failure
> conditions you are hitting.
No error occurs, swf launches but is blank and debugger hangs. Not really much
to go on.
> I can't imagine setting up an FB project for every test SWF.
No but you could set up as required for
On 9/8/13 5:16 PM, "Justin Mclean" wrote:
>Hi,
>
>> if ("softKeyboardRect" in FlexGlobals.topLevelApplication)
>>
>> isn't right because the application's softkeyboard rect is an
>>mx_internal
>> variable and "in" only tests public variables.
>
>Thanks for that, fixed it by changing it t
Hi,
> if ("softKeyboardRect" in FlexGlobals.topLevelApplication)
>
> isn't right because the application's softkeyboard rect is an mx_internal
> variable and "in" only tests public variables.
Thanks for that, fixed it by changing it to be a try catch, the tests now pass.
> Mustella was
> Was finally able to get the mobile tests to run the mobile tests and can
> repeat the two failures. I had to revert to 11.1 and AIR 3.1 - are we sure
> that these test have been tested on laters versions of air?
AIR 3.7 is the oldest version of the AIR SDK on the Mustella VM. It
currently runs
Found some time to look into it now that you put some boundaries around
the possibilities. It turns out that the change you made:
if ("softKeyboardRect" in FlexGlobals.topLevelApplication)
isn't right because the application's softkeyboard rect is an mx_internal
variable and "in" only te
Hi,
Was finally able to get the mobile tests to run the mobile tests and can repeat
the two failures. I had to revert to 11.1 and AIR 3.1 - are we sure that these
test have been tested on laters versions of air?
I can't see why those two tests are failing but it's likely to do with that
that t
On 9/5/13 3:04 AM, "Erik de Bruin" wrote:
>Alex, you wrote:
>
>"That's why I've invested my time on other mustella tools. If you
>compile every test, then run MustellaDependencyDB, it will create a
>database of dependencies such that, if you run MustellaTestChooser, it
>will generate a list of
I reproduced the failures on Mac and AIR3.4. My run took 77 minutes but
my computer was slow. Totals: 3958 passes, 2 failures. Did you see that
many tests run? And more importantly, did the tests that we see fail
pass? Maybe the tests never ran.
My local.properties only has target_os_name=and
Alex, you wrote:
"That's why I've invested my time on other mustella tools. If you
compile every test, then run MustellaDependencyDB, it will create a
database of dependencies such that, if you run MustellaTestChooser, it
will generate a list of tests that need to be run based on the changed
file
Also, all tests are run against at least AIR 3.7.
EdB
On Thu, Sep 5, 2013 at 11:46 AM, Erik de Bruin wrote:
> The VM runs Windows, maybe that is a factor?
>
> EdB
>
>
>
> On Thu, Sep 5, 2013 at 11:44 AM, Justin Mclean
> wrote:
>> Hi,
>>
>> OK no idea what's going on here but if I run the mob
The VM runs Windows, maybe that is a factor?
EdB
On Thu, Sep 5, 2013 at 11:44 AM, Justin Mclean wrote:
> Hi,
>
> OK no idea what's going on here but if I run the mobile tests like so on OSX:
>
> ./mini_run.sh -mobile tests/mobile
>
> I get zero failures after about it runs for about 25 minut
Hi,
OK no idea what's going on here but if I run the mobile tests like so on OSX:
./mini_run.sh -mobile tests/mobile
I get zero failures after about it runs for about 25 minutes.
The local.properties file contains this:
use_apollo=true
run_mobile_tests=true
target_os_name=android
device_name=
>> If so, Justin, can you revert some of your recent checkins in those areas?
> Sorry but I'm not going to revert a checkin that actually fixes a bug and
> when is it most likely that the test is now not working. If the fix had
It's that "most likely" part that worries us...
EdB
--
Ix Multi
On 9/4/13 8:24 PM, "Justin Mclean" wrote:
>Hi,
>
>> I'm willing to help out, but it helps if you have done some basic
>>research
>> on any test failures
>That already been done - see other threads. It looks like the DG issue
>been fixed (that was one failing test) and you looked at the popup is
Hi,
> I'm willing to help out, but it helps if you have done some basic research
> on any test failures
That already been done - see other threads. It looks like the DG issue been
fixed (that was one failing test) and you looked at the popup issue (the other
2 failing tests) and couldn't see any
On 9/4/13 3:39 PM, "Justin Mclean" wrote:
>HI,
>
>> At Adobe, if new failures appeared and it was in tests that could have
>> been affected by code you changed, you had to revert or fix immediately.
>
>We are not at Adobe, other committers should be willing to help out on
>bug fixing and testin
I'll fiddle around with the test since I'll be confirming two JIRA issues
that revolve around DataGrids and will have to run the Mustella for them
anyways. Probably for the best anyways, my Mustella knowledge revolves
only around running the tests lol.
-Mark
On Wed, Sep 4, 2013 at 6:39 PM, Just
HI,
> At Adobe, if new failures appeared and it was in tests that could have
> been affected by code you changed, you had to revert or fix immediately.
We are not at Adobe, other committers should be willing to help out on bug
fixing and testing in a collaborative way. We want to encourage peopl
From: Justin Mclean [mailto:jus...@classsoftware.com]
> Sent: Wednesday, September 04, 2013 4:48 AM
> To: dev@flex.apache.org
> Subject: Re: Mustella failures
>
> Hi,
>
> > So, what do you suggest?
> 3. Having a way to be easily able debug mustella tests in the debugger
would be a great help.
On 9/4/13 7:52 AM, "Kessler CTR Mark J" wrote:
>Well the only way to get more love to Mustella is to make it easier to
>use / understand. A large part of that is taking it out of the command
>line and into a GUI. The heavy performance hits while it's running is a
>separate issue, but could be
or (1) in the java to
make it slightly less aggressive?
-Mark
-Original Message-
From: omup...@gmail.com [mailto:omup...@gmail.com] On Behalf Of OmPrakash
Muppirala
Sent: Wednesday, September 04, 2013 10:45 AM
To: dev@flex.apache.org
Subject: RE: Mustella failures
On Sep 4, 2013 2:
On 9/4/13 1:48 AM, "Justin Mclean" wrote:
>Hi,
>
>> So, what do you suggest?
>1. Have more contributors/committers that have more time to fix and test
>bugs?
>2. Nicely ask the full time Adobe people to put a bit more resources onto
>this as they know and understand it best?
I'm willing to spen
track each test
independently.
-Mark
-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com]
Sent: Wednesday, September 04, 2013 4:48 AM
To: dev@flex.apache.org
Subject: Re: Mustella failures
Hi,
> So, what do you suggest?
3. Having a way to be easily able debug muste
Hi,
> So, what do you suggest?
1. Have more contributors/committers that have more time to fix and test bugs?
2. Nicely ask the full time Adobe people to put a bit more resources onto this
as they know and understand it best?
3. Having a way to be easily able debug mustella tests in the debugger
So, what do you suggest? Should we just use Mustella for legacy tests,
and use something different going forward?
IMHO it is not wise to add features or fix bugs without a test case,
even if the fixes "look ok".
We cannot leave its as is, because getting 6 emails a day that
Mustella has failed wi
Hi,
From what I can see the tests are in error and the fixes ok, I've not had the
bandwidth to debug and fix. Debugging mustella tests isn't easy and sadly
generally no one wants to fix them.
Justin
We need to talk process for a bit. Keeping the various Jenkins jobs in
good working order requires significant resources. I'm more than happy
to keep doing that, but if no-one is paying attention to the
information those jobs provide, what is the point?
The situation for the past month (!) is that
On 6/13/13 3:45 AM, "Justin Mclean" wrote:
>Hi,
>
>> In my version of the test case, after you hit "grouped data" and "expand
>> all", if you were to pause the app and examine the renderers in question
>> in the debugger, they all have their invalidateDisplayListFlag set to
>> true.
>
>Not 100%
Hi,
> In my version of the test case, after you hit "grouped data" and "expand
> all", if you were to pause the app and examine the renderers in question
> in the debugger, they all have their invalidateDisplayListFlag set to
> true.
Not 100% sure that is the issue in UI Text Field notice the cal
On 6/12/13 9:50 AM, "Justin Mclean" wrote:
>Hi,
>
>> IMO, it is risky to leave the ADG's renderers in this state.
>Fair enough and I'm sure you know more about the ADG innards than me.
>
>> But the question is, what about some third-party who extended the
>>renderer and added another style
>>
Hi,
> IMO, it is risky to leave the ADG's renderers in this state.
Fair enough and I'm sure you know more about the ADG innards than me.
> But the question is, what about some third-party who extended the renderer
> and added another style
> not in this list?
They could override the setStyle me
On 6/12/13 1:22 AM, "Justin Mclean" wrote:
>HI,
>
>> Well, I'm not sure it is only an issue with the test.
>
>From a quick look it the setStyle that's not causing everything to
>refresh. The extra validateNow fixed that but was also called when
>scrolling, editing etc etc slowing the ADG down.
Hi,
The test passes with that change, I'm not going to have any internet access for
a while so I've checked the change in. Revert if you feel it's not the right
solution.
Thanks,
Justin
HI,
> Well, I'm not sure it is only an issue with the test.
From a quick look it the setStyle that's not causing everything to refresh. The
extra validateNow fixed that but was also called when scrolling, editing etc
etc slowing the ADG down.
Then perhaps a simple solution would to be this?
On 6/11/13 3:36 PM, "Justin Mclean" wrote:
>Hi,
>
>Given that there's only an issue with the test and it work fine in the
>browser and in 99% of cases (an assumption but not an unreasonable one)
>the performance is significantly better I think we try and get the test
>to pass rather than adding
Hi,
Given that there's only an issue with the test and it work fine in the browser
and in 99% of cases (an assumption but not an unreasonable one) the performance
is significantly better I think we try and get the test to pass rather than
adding back the validateNow.
Thanks,
Justin
compareBitmap does its thing.
>As far as I can see the text shouldn't be changed/reversed/RTL or
>anything as only the layoutDirection is changed. All that should do is
>show columns in reverse order.
>>
>> I can put this on my list of things to dig into after I get other
>&g
Did you sync first? I changed the test so it would pass. Did you run ant main
before running the test that failed?
Sent via the PANTECH Discover, an AT&T 4G LTE smartphone.
Justin Mclean wrote:
Hi,
I'm not seeing this but I am getting another error.
[java] ==
Hi,
I'm not seeing this but I am getting another error.
[java] =
[java] Failed:
[java] =
[java] LangPacks/Japanese/tests/runtimeErrorTests
JA_RTE_FlexVersion_VersionAl
Hi,
I had Jenkins add other.locales target in order to try to make some test pass,
but it then caused more LangPacks tests to run and found some new failures.
I'm fixing the tests, but as I was fixing a test that used a custom character
in DateValidator, the fixed seemed to be to supply an inpu
ersed/RTL or anything as
only the layoutDirection is changed. All that should do is show columns in
reverse order.
>
> I can put this on my list of things to dig into after I get other mustella
> failures on the VM resolved. Let me know.
If you could that would be a great help.
Thanks,
Justin
y is that now that validateNow isn't being
called it gets validated and the text is "fixed" on some later frame,
which could be after compareBitmap does its thing.
I can put this on my list of things to dig into after I get other mustella
failures on the VM resolved. Let me know.
-Alex
The validate now was being called multiple times - removing it
significantly improved performance.
Why is the text reversed in the bitmap only the columns should be in
reverse order.
IIRC, you added or removed a validateNow()? That could affect timing, so
the CompareBitmap may need or not need to WaitForLayoutManager. But if
waiting helps, consider that this could mean an app that's busy so the
frame rate slows might see a flicker.
On 6/8/13 2:34 AM, "Justin Mclean" wrote:
Hi,
>> 1) ADG mirroring. The failing bitmap shows the text flipped (as if viewed
>> in a mirror).
Look closer at the test it setting the layout direction RTL not the direction
so only the columns should be reverse order not the text.
Look like there's an issue with the test as the same code
Hi,
> 1) ADG mirroring. The failing bitmap shows the text flipped (as if viewed
> in a mirror). I think mirrored in Flex is supposed to flip everything but
> text widgets so the font glyphs themselves are not mirrored, just laid out
> RTL or LTR depending on the characters.
I did ask about this
A fourth test is also failing because of the DividedBox changes:
[java] MarshallPlan/ManagerTests/MP_CursorManager_Tests
MP_CursorManager_DividedBox_compatibility Failed Timed out
On 6/7/13 11:00 AM, "Alex Harui" wrote:
>Hi Folks,
>
>On last night's Mac run, some new failures showed up.
Hi Folks,
On last night's Mac run, some new failures showed up. If you made changes
in these areas, please review your work.
1) ADG mirroring. The failing bitmap shows the text flipped (as if viewed
in a mirror). I think mirrored in Flex is supposed to flip everything but
text widgets so the f
OSX 10.6.8 FP 11.2. So far, I haven't hit anything that looks version or
platform specific.
On 5/14/13 12:09 AM, "Justin Mclean" wrote:
> Hi,
>
>> I¹ve spent today working through the 200+ mustella failures from a
>> ³mini_run.sh all² run.
>
> Much
Hi,
> I’ve spent today working through the 200+ mustella failures from a
> “mini_run.sh –all” run.
Much appreciated!
What OS/Flash version are you targeting out of interest?
Justin
I’ve spent today working through the 200+ mustella failures from a “mini_run.sh
–all” run.
I’m down to about 62 failures. Hopefully I’ll get through them tomorrow. The
vast majority are related to use of callLater in Spark
TextInput/TextArea/RichEditableText. It looks like there is a
I figured out where the problem came from. The wiki page for Mustella [1]
has the wrong path for the location of the trust cfg files. I was blindly
following along and was misled - even though I had fixed the same issue on
the Apache Jenkins server a while ago :-)
The correct path is:
C:\Users\Y
Also, try c:\apacheflex in the trust file. I'm not sure if it knows how to
handle just drive names.
On 2/27/13 1:41 PM, "Alex Harui" wrote:
> If you run mustella on your own windows machine what kind of paths to do you
> see?
>
>
> On 2/27/13 12:36 PM, "Om" wrote:
>
>> I do have the trust
If you run mustella on your own windows machine what kind of paths to do you
see?
On 2/27/13 12:36 PM, "Om" wrote:
> I do have the trust file here:
>
> C:\Users\Administrator\AppData\Roaming\Macromedia\Flash
> Player#Security\FlashPlayerTrust\flex.cfg
>
> The contents of flex.cfg are:
>
> ==
I do have the trust file here:
C:\Users\Administrator\AppData\Roaming\Macromedia\Flash
Player#Security\FlashPlayerTrust\flex.cfg
The contents of flex.cfg are:
===
c:
C|
===
This would be the most permissive setting - even this does not fix the
issue.
I am wondering if the file
You need to put a FlashPlayerTrust file in the appropriate place with the
appropriate settings. We had this issue with Jenkins.
On 2/27/13 12:19 PM, "Om" wrote:
> The player had a security dialog that was preventing it from opening. I
> fixed that. Now I am getting this:
>
> Hello from excl
The player had a security dialog that was preventing it from opening. I
fixed that. Now I am getting this:
Hello from excludes at: Wed Feb 27 12:16:30 GMT-0800 2013
excludes loadTryFile Wed Feb 27 12:16:30 GMT-0800 2013
Exclude: try load from:
file:///C|/apacheflex/mustella/tests/ExcludeListWin.
The player is not running the SWFs. It isn't even getting far enough to
generate a log file.
I hit this once after a new install when the security dialog came up to ask
if it was ok to run the player.exe and never ran the actual player.
On 2/27/13 11:28 AM, "Om" wrote:
> I am trying to run Mu
I am trying to run Mustella on Chris' Win 2008 server. I tried a couple of
tests to see if things work. I did run it 3 times and it fails always.
Peter/Alex, can one of you help out?
Here is what I am running:
Administrator@WIN-2LPF6H9B0Z1 /cygdrive/c/apacheflex/mustella
$ ./mini_run.sh tests/
93 matches
Mail list logo
