On Wed, Sep 4, 2013 at 11:49 AM, Erik de Bruin wrote:
> The way I read that article is that each slave runs a separate job. So
> we'd still have to split a Mustella run up in a lot of separate jobs
> (i.e. flex-sdk_mustella-spark.components.Label or something). I don't
> see (yet) how we would co
On Wed, Sep 4, 2013 at 12:02 PM, Erik de Bruin wrote:
> How would the master read the 'results.txt' from the slave's workspace?
>
> EdB
>
>
The 'out' directory of all the slaves should be publicly readable. We
could copy flashlog.txt to 'out' after mustella finishes running. After
all the slave
How would the master read the 'results.txt' from the slave's workspace?
EdB
On Wed, Sep 4, 2013 at 8:56 PM, OmPrakash Muppirala
wrote:
> On Wed, Sep 4, 2013 at 11:49 AM, Erik de Bruin wrote:
>
>> The way I read that article is that each slave runs a separate job. So
>> we'd still have to spli
The way I read that article is that each slave runs a separate job. So
we'd still have to split a Mustella run up in a lot of separate jobs
(i.e. flex-sdk_mustella-spark.components.Label or something). I don't
see (yet) how we would collect the results from all the runs and
combine them into a repo
I'll read up on the distributed builds. But I do have to wonder about
the workload that goes with maintaining multiple VMs. Just the one we
have now needs "constant" monitoring, as the Flash Player tends to
crash, Windows tends to update and the Jenkins slave applet doesn't
always play nice.
EdB
On Wed, Sep 4, 2013 at 10:32 AM, Alex Harui wrote:
> I don't know anything about Jenkins, but how would you get multiple
> instances of FP writing to separate flashlog.txt files? Are you saying
> there'd be different Vms with different logins/usernames?
>
>
Yes, that is correct. Right now there
I don't know anything about Jenkins, but how would you get multiple
instances of FP writing to separate flashlog.txt files? Are you saying
there'd be different Vms with different logins/usernames?
-Alex
On 9/4/13 10:24 AM, "OmPrakash Muppirala" wrote:
>On Wed, Sep 4, 2013 at 10:15 AM, Alex Har
On Wed, Sep 4, 2013 at 10:15 AM, Alex Harui wrote:
> Thanks for trying. The compile should have distributed to the extra
> cores, but the run phase doesn't. One reason is because the flashlog.txt
> is captured so only one player instance should run at a time. In theory,
> we don't need that an
Thanks for trying. The compile should have distributed to the extra
cores, but the run phase doesn't. One reason is because the flashlog.txt
is captured so only one player instance should run at a time. In theory,
we don't need that any more since it was mainly used to catch uncaught
exceptions,
I upgraded the VM, it now runs on 4 cores instead of 2 and has 7 GB of
memory. This shaved roughly an hour, hour and a half from the run
time. Not sure if my Azure account "free credits" will stretch to a
month with this config, if not, I'll go back to the 'old' config as
the improvement is not as
On 9/4/13 9:17 AM, "Kessler CTR Mark J" wrote:
>Is the test for [1] misspelled? "Sesision" vs "Session"?
There are lots of spelling mistakes in test names, but shouldn't affect
the test itself.
-Alex
Is the test for [1] misspelled? "Sesision" vs "Session"?
[1] gumbo/components/DataGrid/Properties/DataGrid_Properties_editable
Editable_startItemEditorSesision_inValidParams Failed Timed out
-Original Message-
From: flex.muste...@gmail.com [mailto:flex.muste...@gmail.com]
Sent: Wednes
12 matches
Mail list logo