You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2015/07/16 21:20:04 UTC
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Hi Mihai,
We have seen mustella test failures that appear to be related to your
changes. Can you take a look?
[java] =====================================================
[java] Failed:
[java] =====================================================
[java] LangPacks/Japanese/tests/runtimeErrorTests
JA_RTE_Sort_FindCondition Failed
AssertMethodValue%20%28method%20cannot%20be%20shown%29%28body%3Astep%201%29
%20%20method%20returned%20Error%20%231063%3A%20Argument%20count%20mismatch%
20on%20runtimeErrorTests/cmpFn%28%29.%20Expected%202%2C%20got%203.%2C%20exp
ected%20%u691C%u7D22%u57FA%u6E96%u306B%u306F%u3001%27field1%27%20%u306B%u30
44%u305F%u308B%u3059%u3079%u3066%u306E%u30BD%u30FC%u30C8%u30D5%u30A3%u30FC%
u30EB%u30C9%u304C%u542B%u307E%u308C%u3066%u3044%u308B%u5FC5%u8981%u304C%u30
42%u308A%u307E%u3059%u3002
[java] LangPacks/Japanese/tests/runtimeErrorTests
JA_RTE_Sort_FindRestriction Failed
AssertMethodValue%20%28method%20cannot%20be%20shown%29%28body%3Astep%201%29
%20%20method%20returned%20Error%20%231063%3A%20Argument%20count%20mismatch%
20on%20runtimeErrorTests/cmpFn%28%29.%20Expected%202%2C%20got%203.%2C%20exp
ected%20%u691C%u7D22%u6761%u4EF6%u306B%u306F%u3001%u6700%u4F4E%201%20%u3064
%u306E%u30BD%u30FC%u30C8%u30D5%u30A3%u30FC%u30EB%u30C9%u5024%u304C%u542B%u3
07E%u308C%u3066%u3044%u308B%u5FC5%u8981%u304C%u3042%u308A%u307E%u3059
[java] gumbo/components/DataGrid/Integrations/DataGrid_layout_test001
listCollection_getItemIndex_afterSort Failed AssertMethodValue (method
cannot be shown)(body:step 2) method returned 3, expected -1
[java]
resources/ResourceManager/Methods/ResourceManager_Methods_loadResourceModul
e RTL_Method_loadResourceModule_SameLocaleSameBundle Failed
AssertMethodValue (method cannot be shown)(body:step 11) method returned
null, expected Shut down
[java]
spark/collections/Sort/Other/SF_module_sparkButtonBar_global_tester
SortField_module_sparkButtonBar_localeStyle_global_test1 Failed
SetProperty, propertyName = globalLocal(setup:step 3) Timeout waiting for
change from NVModule.child.globalSort
[java] spark/collections/Sort/Other/SF_module_sparkButtonBar_tester
SortField_module_sparkButtonBar_localeStyle_classSelector_test22 Failed
AssertStyleValue(body:step 1) NVModule.child.classSort.locale ru-RU !=
ja-JP
[java] spark/collections/Sort/Other/SF_module_sparkButtonBar_tester
SortField_module_sparkButtonBar_localeStyle_IDSelector_test23 Failed
AssertStyleValue(body:step 1) NVModule.child.idSortField.locale ru-RU !=
fr-CA
[java] spark/collections/Sort/Methods/SF_sort_findItem_tester
SortField_findItem_field_error_test21 Failed AssertMethodValue (method
cannot be shown)(body:step 2) method returned noError, expected Error:
Find criteria must contain all sort fields leading up to age .
[java] spark/collections/Sort/Methods/SF_sort_findItem_tester
SortField_findItem_field_error_script_test22 Failed AssertMethodValue
(method cannot be shown)(body:step 2) method returned noError, expected
Error: Find criteria must contain all sort fields leading up to age .
Thanks,
-Alex
On 7/16/15, 11:38 AM, "mihaic@apache.org" <mi...@apache.org> wrote:
>Repository: flex-sdk
>Updated Branches:
> refs/heads/develop ece249f87 -> f14f5f8ae
>
>
>FLEX-34854 FLEX-34884
>Adding unit test to make sure that the changes in FLEX-34854 haven't
>changed anything about findItem.
>
>
>Project: http://git-wip-us.apache.org/repos/asf/flex-sdk/repo
>Commit: http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/f14f5f8a
>Tree: http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/f14f5f8a
>Diff: http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/f14f5f8a
>
>Branch: refs/heads/develop
>Commit: f14f5f8aeef8d916dd3e5b25c06bedf69779a24a
>Parents: ece249f
>Author: Mihai Chira <mi...@apache.org>
>Authored: Thu Jul 16 20:37:02 2015 +0200
>Committer: Mihai Chira <mi...@apache.org>
>Committed: Thu Jul 16 20:37:02 2015 +0200
>
>----------------------------------------------------------------------
> .../framework/tests/FLEX_34854_Tests.as | 9 -
> .../framework/tests/FLEX_34884_Tests.as | 394 +++++++++++++++++++
> 2 files changed, 394 insertions(+), 9 deletions(-)
>----------------------------------------------------------------------
>
>
>http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/f14f5f8a/frameworks/p
>rojects/framework/tests/FLEX_34854_Tests.as
>----------------------------------------------------------------------
>diff --git a/frameworks/projects/framework/tests/FLEX_34854_Tests.as
>b/frameworks/projects/framework/tests/FLEX_34854_Tests.as
>index 2eec5f6..803e8ab 100644
>--- a/frameworks/projects/framework/tests/FLEX_34854_Tests.as
>+++ b/frameworks/projects/framework/tests/FLEX_34854_Tests.as
>@@ -220,15 +220,6 @@ package {
> assertEquals("the new item should have been moved to the end
>of the list", _sut.length - 1, _sut.getItemIndex(newItem));
> }
>
>- private function assertIndexesAre(indexes:Array):void
>- {
>- assertEquals(indexes.length, _sut.length);
>-
>- for(var i:int = 0; i < _sut.length; i++)
>- {
>-
>assertEquals(ListCollectionView_FLEX_34854_VO(_sut.getItemAt(i)).index,
>indexes[i]);
>- }
>- }
>
>
> private static function generateVOs(no:int, reverse:Boolean =
>false):IList
>
>http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/f14f5f8a/frameworks/p
>rojects/framework/tests/FLEX_34884_Tests.as
>----------------------------------------------------------------------
>diff --git a/frameworks/projects/framework/tests/FLEX_34884_Tests.as
>b/frameworks/projects/framework/tests/FLEX_34884_Tests.as
>new file mode 100644
>index 0000000..7bfe80c
>--- /dev/null
>+++ b/frameworks/projects/framework/tests/FLEX_34884_Tests.as
>@@ -0,0 +1,394 @@
>+/////////////////////////////////////////////////////////////////////////
>///////
>+//
>+// Licensed to the Apache Software Foundation (ASF) under one or more
>+// contributor license agreements. See the NOTICE file distributed with
>+// this work for additional information regarding copyright ownership.
>+// The ASF licenses this file to You under the Apache License, Version
>2.0
>+// (the "License"); you may not use this file except in compliance with
>+// the License. You may obtain a copy of the License at
>+//
>+// http://www.apache.org/licenses/LICENSE-2.0
>+//
>+// Unless required by applicable law or agreed to in writing, software
>+// distributed under the License is distributed on an "AS IS" BASIS,
>+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>implied.
>+// See the License for the specific language governing permissions and
>+// limitations under the License.
>+//
>+/////////////////////////////////////////////////////////////////////////
>///////
>+
>+package {
>+ import mx.collections.ArrayList;
>+ import mx.collections.ComplexFieldChangeWatcher;
>+ import mx.collections.ComplexSortField;
>+ import mx.collections.IList;
>+ import mx.collections.ListCollectionView;
>+ import mx.collections.Sort;
>+ import mx.collections.SortField;
>+
>+ import org.flexunit.assertThat;
>+
>+ import org.flexunit.asserts.assertEquals;
>+
>+ public class FLEX_34884_Tests {
>+ private var _sut:ListCollectionView;
>+
>+ private static const MILLISECONDS_IN_A_SECOND:Number = 1000;
>+ private static const MILLISECONDS_IN_A_MINUTE:Number =
>MILLISECONDS_IN_A_SECOND * 60;
>+ private static const MILLISECONDS_IN_AN_HOUR:Number =
>MILLISECONDS_IN_A_MINUTE * 60;
>+ private static const MILLISECONDS_IN_A_DAY:Number =
>MILLISECONDS_IN_AN_HOUR * 24;
>+
>+ [Before]
>+ public function setUp():void
>+ {
>+ _sut = new ListCollectionView(new ArrayList());
>+ }
>+
>+ [After]
>+ public function tearDown():void
>+ {
>+ _sut = null;
>+ }
>+
>+ [Test]
>+ public function
>getItemIndex_finds_first_item_in_simple_sorted_non_filtered_list():void
>+ {
>+ //given
>+ var from0To4:IList = generateVOs(5);
>+ _sut.addAll(from0To4); //values: Object0, Object1, Object2,
>Object3, Object4
>+
>+ const sortByIndexAscending:Sort = new Sort();
>+ sortByIndexAscending.fields = [new SortField("index", false,
>false, true)];
>+ _sut.sort = sortByIndexAscending;
>+ _sut.refresh(); //values (unchanged): Object0, Object1,
>Object2, Object3, Object4
>+
>+ //when
>+ var item0:FLEX_34884_VO = from0To4.getItemAt(0) as
>FLEX_34884_VO;
>+ var item0Index:int = _sut.getItemIndex(item0);
>+
>+ //then
>+ assertEquals(0, item0Index);
>+ }
>+
>+ [Test]
>+ public function
>getItemIndex_finds_last_item_in_simple_descending_sorted_non_filtered_list
>():void
>+ {
>+ //given
>+ var from0To4:IList = generateVOs(5);
>+ _sut.addAll(from0To4); //values: Object0, Object1, Object2,
>Object3, Object4
>+
>+ const sortByIndexDescending:Sort = new Sort();
>+ sortByIndexDescending.fields = [new SortField("index",
>false, true, true)];
>+ _sut.sort = sortByIndexDescending;
>+ _sut.refresh(); //values: Object4, Object3, Object2,
>Object1, Object0
>+
>+ //when
>+ var item0:FLEX_34884_VO = from0To4.getItemAt(0) as
>FLEX_34884_VO;
>+ var item0Index:int = _sut.getItemIndex(item0);
>+
>+ //then
>+ assertEquals(_sut.length - 1, item0Index);
>+ }
>+
>+ [Test]
>+ public function
>getItemIndex_finds_second_to_last_item_in_simple_descending_sorted_non_fil
>tered_list():void
>+ {
>+ //given
>+ var from0To4:IList = generateVOs(5);
>+ _sut.addAll(from0To4); //values: Object0, Object1, Object2,
>Object3, Object4
>+
>+ const sortByIndexDescending:Sort = new Sort();
>+ sortByIndexDescending.fields = [new SortField("index",
>false, true, true)];
>+ _sut.sort = sortByIndexDescending;
>+ _sut.refresh(); //values: Object4, Object3, Object2,
>Object1, Object0
>+
>+ //when
>+ var item1:FLEX_34884_VO = from0To4.getItemAt(1) as
>FLEX_34884_VO;
>+ var item1Index:int = _sut.getItemIndex(item1);
>+
>+ //then
>+ assertEquals(_sut.length - 2, item1Index);
>+ }
>+
>+ [Test]
>+ public function
>getItemIndex_finds_second_to_last_item_in_simple_no_fields_non_unique_sort
>ed_list():void
>+ {
>+ //given
>+ var from0To4:IList = generateVOs(5);
>+ _sut.addAll(from0To4); //values: Object0, Object1, Object2,
>Object3, Object4
>+
>+ const emptySort:Sort = new Sort(null, null, false);
>+ _sut.sort = emptySort;
>+ _sut.refresh(); //values should be unchanged
>+
>+ //when
>+ var item1:FLEX_34884_VO = from0To4.getItemAt(1) as
>FLEX_34884_VO;
>+
>+ //then
>+ var item1Index:int = _sut.getItemIndex(item1);
>+ assertEquals(1, item1Index);
>+ }
>+
>+ [Test]
>+ public function
>getItemIndex_finds_second_to_last_item_in_simple_no_fields_unique_sorted_l
>ist():void
>+ {
>+ //given
>+ var from0To4:IList = generateVOs(5);
>+ _sut.addAll(from0To4); //values: Object0, Object1, Object2,
>Object3, Object4
>+
>+ const emptySort:Sort = new Sort(null, null, true);
>+ _sut.sort = emptySort;
>+ _sut.refresh(); //values should be unchanged
>+
>+ //when
>+ var item1:FLEX_34884_VO = from0To4.getItemAt(1) as
>FLEX_34884_VO;
>+
>+ //then
>+ var item1Index:int = _sut.getItemIndex(item1);
>+ assertEquals(1, item1Index);
>+ }
>+
>+ [Test]
>+ public function
>getItemIndex_finds_second_to_last_date_in_simple_no_fields_unique_sorted_l
>ist_of_dates():void
>+ {
>+ //given
>+ var yesterday:Date = new Date();
>+ yesterday.setTime(yesterday.getTime() -
>MILLISECONDS_IN_A_DAY);
>+
>+ var today:Date = new Date();
>+
>+ var tomorrow:Date = new Date();
>+ tomorrow.setTime(tomorrow.getTime() + MILLISECONDS_IN_A_DAY);
>+
>+ _sut.addItem(tomorrow);
>+ _sut.addItem(today);
>+ _sut.addItem(yesterday);
>+
>+ //when
>+ const emptySort:Sort = new Sort(null, null, true);
>+ _sut.sort = emptySort;
>+ _sut.refresh(); //values: yesterday, today, tomorrow
>+
>+ //then
>+ assertEquals(0, _sut.getItemIndex(yesterday));
>+ assertEquals(1, _sut.getItemIndex(today));
>+ assertEquals(2, _sut.getItemIndex(tomorrow));
>+ }
>+
>+ [Test]
>+ public function
>getItemIndex_finds_second_to_last_date_in_simple_no_fields_non_unique_sort
>ed_list_of_dates():void
>+ {
>+ //given
>+ var yesterday:Date = new Date();
>+ yesterday.setTime(yesterday.getTime() -
>MILLISECONDS_IN_A_DAY);
>+
>+ var today:Date = new Date();
>+
>+ var tomorrow:Date = new Date();
>+ tomorrow.setTime(tomorrow.getTime() + MILLISECONDS_IN_A_DAY);
>+
>+ _sut.addItem(tomorrow);
>+ _sut.addItem(today);
>+ _sut.addItem(yesterday);
>+ _sut.addItem(today);
>+
>+ //when
>+ const emptySort:Sort = new Sort(null, null, true);
>+ _sut.sort = emptySort;
>+ _sut.refresh(); //values: yesterday, today, today, tomorrow
>+
>+ //then
>+ assertEquals(0, _sut.getItemIndex(yesterday));
>+ var todayIndex:int = _sut.getItemIndex(today);
>+ assertThat(todayIndex == 1 || todayIndex == 2);
>+ assertEquals(3, _sut.getItemIndex(tomorrow));
>+ }
>+
>+ [Test]
>+ public function
>getItemIndex_finds_first_item_in_complex_sorted_non_filtered_list():void
>+ {
>+ //given
>+ var from0To4:IList = generateVOs(5);
>+ _sut.addAll(from0To4); //values[address.street]: Street0,
>Street1, Street2, Street3, Street4
>+
>+ const sortByIndexAscending:Sort = new Sort();
>+ sortByIndexAscending.fields = [new
>ComplexSortField("address.street", false, false, false)];
>+ _sut.sort = sortByIndexAscending;
>+ _sut.refresh(); //values[address.street] (unchanged):
>Street0, Street1, Street2, Street3, Street4
>+
>+ //when
>+ var item0:FLEX_34884_VO = from0To4.getItemAt(0) as
>FLEX_34884_VO;
>+ var item0Index:int = _sut.getItemIndex(item0);
>+
>+ //then
>+ assertEquals(0, item0Index);
>+ }
>+
>+ [Test]
>+ public function
>getItemIndex_finds_last_item_in_complex_descending_sorted_non_filtered_lis
>t():void
>+ {
>+ //given
>+ var from0To4:IList = generateVOs(5);
>+ _sut.addAll(from0To4); //values[address.street]: Street0,
>Street1, Street2, Street3, Street4
>+
>+ const sortByIndexDescending:Sort = new Sort();
>+ sortByIndexDescending.fields = [new
>ComplexSortField("address.street", false, true, false)];
>+ _sut.sort = sortByIndexDescending;
>+ _sut.refresh(); //values: Street4, Street3, Street2,
>Street1, Street0
>+
>+ //when
>+ var item0:FLEX_34884_VO = from0To4.getItemAt(0) as
>FLEX_34884_VO;
>+ var item0Index:int = _sut.getItemIndex(item0);
>+
>+ //then
>+ assertEquals(_sut.length - 1, item0Index);
>+ }
>+
>+ [Test]
>+ public function
>getItemIndex_finds_item_in_complex_descending_sorted_list_after_its_reposi
>tioned_due_to_its_sort_field_changing():void
>+ {
>+ //given
>+ var from0To4:IList = generateVOs(5);
>+ _sut.addAll(from0To4); //values[address.street]: Street0,
>Street1, Street2, Street3, Street4
>+
>+ const sortByIndexDescending:Sort = new Sort();
>+ sortByIndexDescending.fields = [new
>ComplexSortField("address.street", false, true, false)];
>+ _sut.sort = sortByIndexDescending;
>+ _sut.refresh(); //values: Street4, Street3, Street2,
>Street1, Street0
>+
>+ _sut.complexFieldWatcher = new ComplexFieldChangeWatcher();
>+
>+ //when
>+ var item0:FLEX_34884_VO = from0To4.getItemAt(0) as
>FLEX_34884_VO;
>+ var item999:FLEX_34884_VO = item0;
>+ item999.address.street = "Street999";
>+
>+ //then
>+ var item999Index:int = _sut.getItemIndex(item0);
>+ assertEquals(0, item999Index);
>+ }
>+
>+ [Test]
>+ public function
>getItemIndex_finds_item_in_complex_descending_sorted_list_after_its_reposi
>tioned_in_middle_due_to_its_sort_field_changing():void
>+ {
>+ //given
>+ var from0To4:IList = generateVOs(5);
>+ _sut.addAll(from0To4); //values[address.street]: Street0,
>Street1, Street2, Street3, Street4
>+
>+ const sortByIndexDescending:Sort = new Sort();
>+ sortByIndexDescending.fields = [new
>ComplexSortField("address.street", false, true, false)];
>+ _sut.sort = sortByIndexDescending;
>+ _sut.refresh(); //values[address.street]: Street4, Street3,
>Street2, Street1, Street0
>+
>+ _sut.complexFieldWatcher = new ComplexFieldChangeWatcher();
>+
>+ //when
>+ var item2:FLEX_34884_VO = from0To4.getItemAt(2) as
>FLEX_34884_VO;
>+ item2.address.street = "Street9"; //values[address.street]:
>Street9, Street4, Street3, Street1, Street0
>+
>+ var item0:FLEX_34884_VO = from0To4.getItemAt(0) as
>FLEX_34884_VO;
>+ item0.address.street = "Street2"; //values[address.street]:
>Street9, Street4, Street3, Street2, Street1
>+
>+ //then
>+ var street2Index:int = _sut.getItemIndex(item0);
>+ assertEquals(3, street2Index);
>+ }
>+
>+ [Test]
>+ public function
>getItemIndex_finds_newly_inserted_item_in_complex_descending_sorted_list()
>:void
>+ {
>+ //given
>+ var from0To4:IList = generateVOs(5);
>+ _sut.addAll(from0To4); //values[address.street]: Street0,
>Street1, Street2, Street3, Street4
>+
>+ const sortByIndexDescending:Sort = new Sort();
>+ sortByIndexDescending.fields = [new
>ComplexSortField("address.street", false, true, false)];
>+ _sut.sort = sortByIndexDescending;
>+ _sut.refresh(); //values[address.street]: Street4, Street3,
>Street2, Street1, Street0
>+
>+ _sut.complexFieldWatcher = new ComplexFieldChangeWatcher();
>+
>+ //when
>+ var newItem:FLEX_34884_VO = generateOneObject(9);
>+ _sut.addItemAt(newItem, _sut.length - 1);
>//values[address.street]: Street9, Street4, Street3, Street2, Street1,
>Street0
>+
>+ //then
>+ assertEquals(0, _sut.getItemIndex(newItem));
>+ }
>+
>+ [Test]
>+ public function
>getItemIndex_finds_newly_inserted_item_in_complex_descending_sorted_list_a
>fter_its_sort_field_changes():void
>+ {
>+ //given
>+ var from0To4:IList = generateVOs(5);
>+ _sut.addAll(from0To4); //values[address.street]: Street0,
>Street1, Street2, Street3, Street4
>+
>+ const sortByIndexDescending:Sort = new Sort();
>+ sortByIndexDescending.fields = [new
>ComplexSortField("address.street", false, true, false)];
>+ _sut.sort = sortByIndexDescending;
>+ _sut.refresh(); //values[address.street]: Street4, Street3,
>Street2, Street1, Street0
>+
>+ _sut.complexFieldWatcher = new ComplexFieldChangeWatcher();
>+
>+ //when
>+ var newItem:FLEX_34884_VO = generateOneObject(1);
>+ _sut.addItemAt(newItem, _sut.length - 1);
>//values[address.street]: Street4, Street3, Street2, Street1, Street1,
>Street0
>+
>+ newItem.address.street = "Street3";
>//values[address.street]: Street4, Street3, Street3, Street2, Street1,
>Street1, Street0
>+
>+ //then
>+ var newItemIndex:int = _sut.getItemIndex(newItem);
>+ assertThat(newItemIndex == 1 || newItemIndex == 2);
>+ }
>+
>+ private static function generateVOs(no:int, reverse:Boolean =
>false):IList
>+ {
>+ return generateObjects(no, reverse, generateOneObject);
>+ }
>+
>+ private static function generateObjects(no:int, reverse:Boolean,
>generator:Function):IList
>+ {
>+ var result:Array = [];
>+ for(var i:int = 0; i < no; i++)
>+ {
>+ result.push(generator(i));
>+ }
>+
>+ if(reverse)
>+ result.reverse();
>+
>+ return new ArrayList(result);
>+ }
>+
>+ private static function generateOneObject(i:Number):FLEX_34884_VO
>+ {
>+ return new FLEX_34884_VO(i, "Object", "Street");
>+ }
>+ }
>+}
>+
>+[Bindable]
>+class FLEX_34884_VO
>+{
>+ public var name:String;
>+ public var address:FLEX_34884_AddressVO;
>+ public var index:Number;
>+
>+ public function FLEX_34884_VO(index:Number, namePrefix:String,
>streetPrefix:String)
>+ {
>+ this.index = index;
>+ this.name = namePrefix + index;
>+ this.address = new FLEX_34884_AddressVO(streetPrefix + index);
>+ }
>+}
>+
>+[Bindable]
>+class FLEX_34884_AddressVO
>+{
>+ public var street:String;
>+
>+ public function FLEX_34884_AddressVO(street:String)
>+ {
>+ this.street = street;
>+ }
>+}
>\ No newline at end of file
>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Mihai Chira <mi...@gmail.com>.
1. Good to know about these tools. I now made sure that the IntelliJ
project is using the correct SDK (which I have rebuilt before also
rebuilding the mustella SWF), and I get the same problem: I only reach
the constructors of TestCase and mx.modules.ModuleLoader. I think it's
that no one calls UnitTester.runTests() to actually start the test.
So I added "UnitTester.init(o)" in the static init method. This worked.
2. The next problem was an error with the excludes:
TypeError: Error #1009: Cannot access a property or method of a null
object reference.
at ExcludeFileLocation$/postProcessData()[C:\Users\evolverine\workspace\flex-sdk\mustella\as3\src\mustella\ExcludeFileLocation.as:210]
at ExcludeFileLocation$/completeHandler2()[C:\Users\evolverine\workspace\flex-sdk\mustella\as3\src\mustella\ExcludeFileLocation.as:203]
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at flash.net::URLLoader/onComplete()
This happened because of the logic in
ExcludeFileLocation.loadExcludeFile, in which it assumes that url is a
fully qualified path - but when running it from IntelliJ it's actually
"app:/SF_module_sparkButtonBar.swf". So it can't load the excludes.
Solution: I added "UnitTester.waitForExcludes = false;" in the static
init() method, before the (above) call to UnitTester.init().
3. Next problem: the runTests() method is now executed, but the
UnitTester.includeList has wrong values (e.g.
"spark/collections/Sort/Other/null$SortField_module_sparkButtonBar_localeStyle_global_test1"
- notice the "null").
3.1. At this point I realise that "UnitTester.init(o)" is not needed
because it's called by ScriptRunner. So I remove it and it keeps
working as before.
3.2. I discover mustella/classes/CurrentIncludeList.as, which seems to
be generated by GetExcIncCase.java. Anyone know why the last part of
the includes lines is "null"? Maybe I'm running the mini_run script
with wrong parameters? (It's "$ mini_run.sh
-caseName=SortField_module_sparkButtonBar_localeStyle_global_test1
tests/spark/collections/Sort/Other/SF_module_sparkButtonBar_global_tester.mxml".)
Solution: I manually edit the CurrentIncludeList.as file to contain
correct includes.
Result: didn't work; the includeList still has values with "null" at the end.
Solution 2: hammer the correct test in by adding the line
"includeList["spark/collections/Sort/Other/SF_module_sparkButtonBar_global_tester$SortField_module_sparkButtonBar_localeStyle_global_test1"]
= 1;" in UnitTester.runTests.
Result: works.
4. The DispatchMouseClickEvent TestStep is run, but SetProperty isn't.
>From what I could tell from debugging, the
assets\CustomSparkButtonBarModule.swf module is correctly loaded, and
dispatches the "ready" event that DispatchMouseClickEvent is
instructed to wait for, but for some reason the test run fails before
it's received. At this point my knowledge of mustella as code is
limiting my ability to debug this further without spending hours on
it.
Ideas?
On 19 July 2015 at 07:15, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 7/18/15, 3:05 PM, "Mihai Chira" <mi...@gmail.com> wrote:
>
>>> The swf should hit breakpoints in the sort code. Is it not doing that?
>>I could only break the app on the constructors of UnitTester and
>>TestCase. Nothing in SortField or Sort (I didn't test the
>>constructors, just other methods that should have been called - even
>>if the bug was still there, that is). But the clue is that I can't get
>>any breakpoint to stop in ResetComponent, DispatchMouseClickEvent or
>>SetProperty.
>
> Makes me think your line numbers aren’t matching up. If the mustella.swc
> is old or the debugger is looking at sources in a different version of
> Flex SDK, then line numbers won’t match and you will miss hitting
> breakpoints. Often, the constructors are still at the same line, but more
> important code has moved as lines get added.
>
> If you swfdump -abc the SWF you can see more about what went into it and
> compare line numbers.
>
> -Alex
>
>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Alex Harui <ah...@adobe.com>.
On 7/18/15, 3:05 PM, "Mihai Chira" <mi...@gmail.com> wrote:
>> The swf should hit breakpoints in the sort code. Is it not doing that?
>I could only break the app on the constructors of UnitTester and
>TestCase. Nothing in SortField or Sort (I didn't test the
>constructors, just other methods that should have been called - even
>if the bug was still there, that is). But the clue is that I can't get
>any breakpoint to stop in ResetComponent, DispatchMouseClickEvent or
>SetProperty.
Makes me think your line numbers aren’t matching up. If the mustella.swc
is old or the debugger is looking at sources in a different version of
Flex SDK, then line numbers won’t match and you will miss hitting
breakpoints. Often, the constructors are still at the same line, but more
important code has moved as lines get added.
If you swfdump -abc the SWF you can see more about what went into it and
compare line numbers.
-Alex
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Mihai Chira <mi...@gmail.com>.
> The swf should hit breakpoints in the sort code. Is it not doing that?
I could only break the app on the constructors of UnitTester and
TestCase. Nothing in SortField or Sort (I didn't test the
constructors, just other methods that should have been called - even
if the bug was still there, that is). But the clue is that I can't get
any breakpoint to stop in ResetComponent, DispatchMouseClickEvent or
SetProperty.
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Alex Harui <ah...@adobe.com>.
The swf should hit breakpoints in the sort code. Is it not doing that?
I can usually use fdb on the swf.
Sent from my LG G3, an AT&T 4G LTE smartphone
------ Original message------
From: Mihai Chira
Date: Sat, Jul 18, 2015 12:49 PM
To: dev@flex.apache.org;
Subject:Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854 FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854 haven't changed anything about findItem.
Now I'm stuck because although I can run the swf that was generated at
the previous step in debug mode in IntelliJ, the most further
breakpoint which I can catch is in the TestCase.as constructor. Which
implies, to me, that the test case in the mxml file is defined and
created, but not executed. Do I need to change the code to get it to
execute somehow (maybe using that static function init()?), and then
regenerate the SWF?
On 18 July 2015 at 21:39, Mihai Chira <mi...@gmail.com> wrote:
> Yep, it's pretty clear which ones are still failing.
>
> I'm looking, for instance, at
> SF_module_sparkButtonBar_global_tester.mxml, whose only test case
> should run perfectly. I made a sample app which does (seemingly) the
> same thing, and the Sort and SortField do return the correct locale
> value ("ru-RU"). So in order to figure out why in mustella it's
> failing I'd need to debug it. I'm following the instructions on the
> wiki now.
>
> FYI while doing so I got an error about cygwinshell:
> "java.io.IOException: Cannot run program "${cygwinshell}":
> CreateProcess error=2, The system cannot find the file specified". And
> when I trace it with <echo> I get
>
> [echo] shell = ${cygwinshell}
> [echo] cygwinshell = ${cygwinshell}
>
> It worked only when I changed [1] into [2] in mustella/build.xml
> (basically to use the git shell).
>
>
> [1] <available file="/cygwin/bin/sh.exe" property="cygwinshell"
> value="/cygwin/bin/sh.exe"/>
> <available file="/cygwin64/bin/sh.exe" property="cygwinshell"
> value="/cygwin64/bin/sh.exe"/>
>
> [2] <property name="cygwinshell" value="c:\Program Files (x86)\Git\bin\sh.exe"/>
>
>
> On 17 July 2015 at 15:09, Alex Harui <ah...@adobe.com> wrote:
>> I wasn’t able to reset mustella until just now so it might be hard to find
>> your results in the 100’s of errors in build # 1533. Hopefully build #
>> 1534 will be cleaner.
>>
>> FWIW, my magic incantation that resets mustella is to log into the server,
>> open ApacheFlex/dependencies/FlashPlayer_Debug and click on and close each
>> debug player. No idea why it works. Maybe Tom can try that some day to
>> see if it works for him as well.
>>
>> -Alex
>>
>> On 7/17/15, 3:16 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>
>>>Cool, thanks for the link. I'll take a look tonight or tomorrow at the
>>>results.
>>>On 16 Jul 2015 22:53, "Alex Harui" <ah...@adobe.com> wrote:
>>>
>>>> The link at [1] is the build server that is currently down. It doesn’t
>>>> run mustella.
>>>>
>>>> Mustella tests are at http://flex-mustella.cloudapp.net and failures are
>>>> sent to commits@
>>>>
>>>> Every couple of days, we start getting weird failures that requires
>>>> fiddling with the mustella server. It looks like we’re in that funky
>>>> state right now so I will try to deal with that in about 3 hours so the
>>>> next run after that should show the effects of your changes.
>>>>
>>>> -Alex
>>>>
>>>> On 7/16/15, 1:48 PM, "Mihai Chira" <mi...@gmail.com> wrote:
>>>>
>>>> >At least one of the failures should now be fixed. If others are left,
>>>> >I'll tackle them in the next few days.
>>>> >How can I monitor the test results? The bookmark I have for the build
>>>> >server is this[1] and it doesn't seem to be working. Sorry if there
>>>> >was a url change that I didn't catch.
>>>> >
>>>> >[1] http://apacheflexbuild.cloudapp.net:8080/job/flex-sdk_test/
>>>> >
>>>> >On 16 July 2015 at 21:52, Mihai Chira <mi...@gmail.com> wrote:
>>>> >>> changes. Can you take a look?
>>>> >>
>>>> >> on it
>>>>
>>>>
>>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Mihai Chira <mi...@gmail.com>.
Now I'm stuck because although I can run the swf that was generated at
the previous step in debug mode in IntelliJ, the most further
breakpoint which I can catch is in the TestCase.as constructor. Which
implies, to me, that the test case in the mxml file is defined and
created, but not executed. Do I need to change the code to get it to
execute somehow (maybe using that static function init()?), and then
regenerate the SWF?
On 18 July 2015 at 21:39, Mihai Chira <mi...@gmail.com> wrote:
> Yep, it's pretty clear which ones are still failing.
>
> I'm looking, for instance, at
> SF_module_sparkButtonBar_global_tester.mxml, whose only test case
> should run perfectly. I made a sample app which does (seemingly) the
> same thing, and the Sort and SortField do return the correct locale
> value ("ru-RU"). So in order to figure out why in mustella it's
> failing I'd need to debug it. I'm following the instructions on the
> wiki now.
>
> FYI while doing so I got an error about cygwinshell:
> "java.io.IOException: Cannot run program "${cygwinshell}":
> CreateProcess error=2, The system cannot find the file specified". And
> when I trace it with <echo> I get
>
> [echo] shell = ${cygwinshell}
> [echo] cygwinshell = ${cygwinshell}
>
> It worked only when I changed [1] into [2] in mustella/build.xml
> (basically to use the git shell).
>
>
> [1] <available file="/cygwin/bin/sh.exe" property="cygwinshell"
> value="/cygwin/bin/sh.exe"/>
> <available file="/cygwin64/bin/sh.exe" property="cygwinshell"
> value="/cygwin64/bin/sh.exe"/>
>
> [2] <property name="cygwinshell" value="c:\Program Files (x86)\Git\bin\sh.exe"/>
>
>
> On 17 July 2015 at 15:09, Alex Harui <ah...@adobe.com> wrote:
>> I wasn’t able to reset mustella until just now so it might be hard to find
>> your results in the 100’s of errors in build # 1533. Hopefully build #
>> 1534 will be cleaner.
>>
>> FWIW, my magic incantation that resets mustella is to log into the server,
>> open ApacheFlex/dependencies/FlashPlayer_Debug and click on and close each
>> debug player. No idea why it works. Maybe Tom can try that some day to
>> see if it works for him as well.
>>
>> -Alex
>>
>> On 7/17/15, 3:16 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>
>>>Cool, thanks for the link. I'll take a look tonight or tomorrow at the
>>>results.
>>>On 16 Jul 2015 22:53, "Alex Harui" <ah...@adobe.com> wrote:
>>>
>>>> The link at [1] is the build server that is currently down. It doesn’t
>>>> run mustella.
>>>>
>>>> Mustella tests are at http://flex-mustella.cloudapp.net and failures are
>>>> sent to commits@
>>>>
>>>> Every couple of days, we start getting weird failures that requires
>>>> fiddling with the mustella server. It looks like we’re in that funky
>>>> state right now so I will try to deal with that in about 3 hours so the
>>>> next run after that should show the effects of your changes.
>>>>
>>>> -Alex
>>>>
>>>> On 7/16/15, 1:48 PM, "Mihai Chira" <mi...@gmail.com> wrote:
>>>>
>>>> >At least one of the failures should now be fixed. If others are left,
>>>> >I'll tackle them in the next few days.
>>>> >How can I monitor the test results? The bookmark I have for the build
>>>> >server is this[1] and it doesn't seem to be working. Sorry if there
>>>> >was a url change that I didn't catch.
>>>> >
>>>> >[1] http://apacheflexbuild.cloudapp.net:8080/job/flex-sdk_test/
>>>> >
>>>> >On 16 July 2015 at 21:52, Mihai Chira <mi...@gmail.com> wrote:
>>>> >>> changes. Can you take a look?
>>>> >>
>>>> >> on it
>>>>
>>>>
>>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Mihai Chira <mi...@gmail.com>.
Yay! Thank you.
On 10 December 2015 at 17:52, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 12/10/15, 1:00 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>
>>Finding "FAIL: .*Sort" in the old reports highlights about 21 lines,
>>and in the new ones none. So I guess the sorting bugs have been fixed?
>>Or should we wait until we restart mustella for a confirmation?
>
> I think you have resolved all of the sorting problems. Congratulations!
>
> -Alex
>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Alex Harui <ah...@adobe.com>.
On 12/10/15, 1:00 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>Finding "FAIL: .*Sort" in the old reports highlights about 21 lines,
>and in the new ones none. So I guess the sorting bugs have been fixed?
>Or should we wait until we restart mustella for a confirmation?
I think you have resolved all of the sorting problems. Congratulations!
-Alex
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Mihai Chira <mi...@gmail.com>.
Finding "FAIL: .*Sort" in the old reports highlights about 21 lines,
and in the new ones none. So I guess the sorting bugs have been fixed?
Or should we wait until we restart mustella for a confirmation?
On 8 December 2015 at 17:19, Alex Harui <ah...@adobe.com> wrote:
> Thanks for sticking with it. I have my fingers crossed.
>
> -Alex
>
> On 12/8/15, 7:58 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>
>>Just pushed another commit. Locally all the mustella tests in the
>>spark/Collections/Sort/Other are now passing, fingers crossed that all
>>the other sort-related ones will also pass.
>>The lesson: moving from inheritance to composition can be super
>>complicated! Events, the new class member using "this" instead of the
>>parent, framework classes calling functions via object["initialized"]
>>instead of an interface, etc. Still worth it, though, to remove code
>>duplication (in this case the mx versions of Sort and SortField were
>>mostly - and imperfectly - copy-pasted in their spark counterparts.
>>This meant that a change to one had to be reflected in the other,
>>which usually didn't happen. It also meant that tests would have
>>needed duplication as well, etc).
>>
>>On 3 December 2015 at 15:51, Mihai Chira <mi...@gmail.com> wrote:
>>> In the end it's an improvement, but in the end 5 test cases are still
>>> failing. Right now I'm travelling, and won't be able to take another
>>> look until Saturday. Does someone else want to help out?
>>>
>>> On 3 December 2015 at 15:18, Alex Harui <ah...@adobe.com> wrote:
>>>> Excellent! Thanks, -Alex
>>>>
>>>> On 12/3/15, 6:01 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>>>
>>>>>About to commit and push a fix for this in the next hour. (It took me
>>>>>so long because my HDD had bad sectors which caused lots of pain in
>>>>>the last few days.)
>>>>>
>>>>>On 24 November 2015 at 18:03, Alex Harui <ah...@adobe.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 11/24/15, 8:41 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>>>>>
>>>>>>>Yes, but the earliest I can do that is on Monday. I hope that still
>>>>>>>works
>>>>>>>regarding the release. (And I hope I'll manage to solve it, but we'll
>>>>>>>see.)
>>>>>>>On 24 Nov 2015 08:19, "Alex Harui" <ah...@adobe.com> wrote:
>>>>>>
>>>>>> I don't know of any plans to cut an RC this week, so I think Monday
>>>>>>should
>>>>>> be ok.
>>>>>>
>>>>>> Thanks,
>>>>>> Alex
>>>>>>
>>>>
>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Alex Harui <ah...@adobe.com>.
Thanks for sticking with it. I have my fingers crossed.
-Alex
On 12/8/15, 7:58 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>Just pushed another commit. Locally all the mustella tests in the
>spark/Collections/Sort/Other are now passing, fingers crossed that all
>the other sort-related ones will also pass.
>The lesson: moving from inheritance to composition can be super
>complicated! Events, the new class member using "this" instead of the
>parent, framework classes calling functions via object["initialized"]
>instead of an interface, etc. Still worth it, though, to remove code
>duplication (in this case the mx versions of Sort and SortField were
>mostly - and imperfectly - copy-pasted in their spark counterparts.
>This meant that a change to one had to be reflected in the other,
>which usually didn't happen. It also meant that tests would have
>needed duplication as well, etc).
>
>On 3 December 2015 at 15:51, Mihai Chira <mi...@gmail.com> wrote:
>> In the end it's an improvement, but in the end 5 test cases are still
>> failing. Right now I'm travelling, and won't be able to take another
>> look until Saturday. Does someone else want to help out?
>>
>> On 3 December 2015 at 15:18, Alex Harui <ah...@adobe.com> wrote:
>>> Excellent! Thanks, -Alex
>>>
>>> On 12/3/15, 6:01 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>>
>>>>About to commit and push a fix for this in the next hour. (It took me
>>>>so long because my HDD had bad sectors which caused lots of pain in
>>>>the last few days.)
>>>>
>>>>On 24 November 2015 at 18:03, Alex Harui <ah...@adobe.com> wrote:
>>>>>
>>>>>
>>>>> On 11/24/15, 8:41 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>>>>
>>>>>>Yes, but the earliest I can do that is on Monday. I hope that still
>>>>>>works
>>>>>>regarding the release. (And I hope I'll manage to solve it, but we'll
>>>>>>see.)
>>>>>>On 24 Nov 2015 08:19, "Alex Harui" <ah...@adobe.com> wrote:
>>>>>
>>>>> I don't know of any plans to cut an RC this week, so I think Monday
>>>>>should
>>>>> be ok.
>>>>>
>>>>> Thanks,
>>>>> Alex
>>>>>
>>>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Mihai Chira <mi...@gmail.com>.
Just pushed another commit. Locally all the mustella tests in the
spark/Collections/Sort/Other are now passing, fingers crossed that all
the other sort-related ones will also pass.
The lesson: moving from inheritance to composition can be super
complicated! Events, the new class member using "this" instead of the
parent, framework classes calling functions via object["initialized"]
instead of an interface, etc. Still worth it, though, to remove code
duplication (in this case the mx versions of Sort and SortField were
mostly - and imperfectly - copy-pasted in their spark counterparts.
This meant that a change to one had to be reflected in the other,
which usually didn't happen. It also meant that tests would have
needed duplication as well, etc).
On 3 December 2015 at 15:51, Mihai Chira <mi...@gmail.com> wrote:
> In the end it's an improvement, but in the end 5 test cases are still
> failing. Right now I'm travelling, and won't be able to take another
> look until Saturday. Does someone else want to help out?
>
> On 3 December 2015 at 15:18, Alex Harui <ah...@adobe.com> wrote:
>> Excellent! Thanks, -Alex
>>
>> On 12/3/15, 6:01 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>
>>>About to commit and push a fix for this in the next hour. (It took me
>>>so long because my HDD had bad sectors which caused lots of pain in
>>>the last few days.)
>>>
>>>On 24 November 2015 at 18:03, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>>>
>>>> On 11/24/15, 8:41 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>>>
>>>>>Yes, but the earliest I can do that is on Monday. I hope that still
>>>>>works
>>>>>regarding the release. (And I hope I'll manage to solve it, but we'll
>>>>>see.)
>>>>>On 24 Nov 2015 08:19, "Alex Harui" <ah...@adobe.com> wrote:
>>>>
>>>> I don't know of any plans to cut an RC this week, so I think Monday
>>>>should
>>>> be ok.
>>>>
>>>> Thanks,
>>>> Alex
>>>>
>>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Mihai Chira <mi...@gmail.com>.
In the end it's an improvement, but in the end 5 test cases are still
failing. Right now I'm travelling, and won't be able to take another
look until Saturday. Does someone else want to help out?
On 3 December 2015 at 15:18, Alex Harui <ah...@adobe.com> wrote:
> Excellent! Thanks, -Alex
>
> On 12/3/15, 6:01 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>
>>About to commit and push a fix for this in the next hour. (It took me
>>so long because my HDD had bad sectors which caused lots of pain in
>>the last few days.)
>>
>>On 24 November 2015 at 18:03, Alex Harui <ah...@adobe.com> wrote:
>>>
>>>
>>> On 11/24/15, 8:41 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>>
>>>>Yes, but the earliest I can do that is on Monday. I hope that still
>>>>works
>>>>regarding the release. (And I hope I'll manage to solve it, but we'll
>>>>see.)
>>>>On 24 Nov 2015 08:19, "Alex Harui" <ah...@adobe.com> wrote:
>>>
>>> I don't know of any plans to cut an RC this week, so I think Monday
>>>should
>>> be ok.
>>>
>>> Thanks,
>>> Alex
>>>
>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Alex Harui <ah...@adobe.com>.
Excellent! Thanks, -Alex
On 12/3/15, 6:01 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>About to commit and push a fix for this in the next hour. (It took me
>so long because my HDD had bad sectors which caused lots of pain in
>the last few days.)
>
>On 24 November 2015 at 18:03, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>> On 11/24/15, 8:41 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>
>>>Yes, but the earliest I can do that is on Monday. I hope that still
>>>works
>>>regarding the release. (And I hope I'll manage to solve it, but we'll
>>>see.)
>>>On 24 Nov 2015 08:19, "Alex Harui" <ah...@adobe.com> wrote:
>>
>> I don't know of any plans to cut an RC this week, so I think Monday
>>should
>> be ok.
>>
>> Thanks,
>> Alex
>>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Mihai Chira <mi...@gmail.com>.
About to commit and push a fix for this in the next hour. (It took me
so long because my HDD had bad sectors which caused lots of pain in
the last few days.)
On 24 November 2015 at 18:03, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 11/24/15, 8:41 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>
>>Yes, but the earliest I can do that is on Monday. I hope that still works
>>regarding the release. (And I hope I'll manage to solve it, but we'll
>>see.)
>>On 24 Nov 2015 08:19, "Alex Harui" <ah...@adobe.com> wrote:
>
> I don't know of any plans to cut an RC this week, so I think Monday should
> be ok.
>
> Thanks,
> Alex
>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Alex Harui <ah...@adobe.com>.
On 11/24/15, 8:41 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>Yes, but the earliest I can do that is on Monday. I hope that still works
>regarding the release. (And I hope I'll manage to solve it, but we'll
>see.)
>On 24 Nov 2015 08:19, "Alex Harui" <ah...@adobe.com> wrote:
I don't know of any plans to cut an RC this week, so I think Monday should
be ok.
Thanks,
Alex
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Mihai Chira <mi...@gmail.com>.
Yes, but the earliest I can do that is on Monday. I hope that still works
regarding the release. (And I hope I'll manage to solve it, but we'll see.)
On 24 Nov 2015 08:19, "Alex Harui" <ah...@adobe.com> wrote:
> Hey Mihai,
>
> I think the Mustella runs are a bit more stable and we're trying to clean
> up failures and get a release out. Can you find some time to look at the
> sort failures again?
>
> Thanks,
> -Alex
>
> On 7/18/15, 12:39 PM, "Mihai Chira" <mi...@gmail.com> wrote:
>
> >Yep, it's pretty clear which ones are still failing.
> >
> >I'm looking, for instance, at
> >SF_module_sparkButtonBar_global_tester.mxml, whose only test case
> >should run perfectly. I made a sample app which does (seemingly) the
> >same thing, and the Sort and SortField do return the correct locale
> >value ("ru-RU"). So in order to figure out why in mustella it's
> >failing I'd need to debug it. I'm following the instructions on the
> >wiki now.
> >
> >FYI while doing so I got an error about cygwinshell:
> >"java.io.IOException: Cannot run program "${cygwinshell}":
> >CreateProcess error=2, The system cannot find the file specified". And
> >when I trace it with <echo> I get
> >
> >[echo] shell = ${cygwinshell}
> >[echo] cygwinshell = ${cygwinshell}
> >
> >It worked only when I changed [1] into [2] in mustella/build.xml
> >(basically to use the git shell).
> >
> >
> >[1] <available file="/cygwin/bin/sh.exe" property="cygwinshell"
> >value="/cygwin/bin/sh.exe"/>
> ><available file="/cygwin64/bin/sh.exe" property="cygwinshell"
> >value="/cygwin64/bin/sh.exe"/>
> >
> >[2] <property name="cygwinshell" value="c:\Program Files
> >(x86)\Git\bin\sh.exe"/>
> >
> >
> >On 17 July 2015 at 15:09, Alex Harui <ah...@adobe.com> wrote:
> >> I wasn’t able to reset mustella until just now so it might be hard to
> >>find
> >> your results in the 100’s of errors in build # 1533. Hopefully build #
> >> 1534 will be cleaner.
> >>
> >> FWIW, my magic incantation that resets mustella is to log into the
> >>server,
> >> open ApacheFlex/dependencies/FlashPlayer_Debug and click on and close
> >>each
> >> debug player. No idea why it works. Maybe Tom can try that some day to
> >> see if it works for him as well.
> >>
> >> -Alex
> >>
> >> On 7/17/15, 3:16 AM, "Mihai Chira" <mi...@gmail.com> wrote:
> >>
> >>>Cool, thanks for the link. I'll take a look tonight or tomorrow at the
> >>>results.
> >>>On 16 Jul 2015 22:53, "Alex Harui" <ah...@adobe.com> wrote:
> >>>
> >>>> The link at [1] is the build server that is currently down. It
> >>>>doesn’t
> >>>> run mustella.
> >>>>
> >>>> Mustella tests are at http://flex-mustella.cloudapp.net and failures
> >>>>are
> >>>> sent to commits@
> >>>>
> >>>> Every couple of days, we start getting weird failures that requires
> >>>> fiddling with the mustella server. It looks like we’re in that funky
> >>>> state right now so I will try to deal with that in about 3 hours so
> >>>>the
> >>>> next run after that should show the effects of your changes.
> >>>>
> >>>> -Alex
> >>>>
> >>>> On 7/16/15, 1:48 PM, "Mihai Chira" <mi...@gmail.com> wrote:
> >>>>
> >>>> >At least one of the failures should now be fixed. If others are left,
> >>>> >I'll tackle them in the next few days.
> >>>> >How can I monitor the test results? The bookmark I have for the build
> >>>> >server is this[1] and it doesn't seem to be working. Sorry if there
> >>>> >was a url change that I didn't catch.
> >>>> >
> >>>> >[1] http://apacheflexbuild.cloudapp.net:8080/job/flex-sdk_test/
> >>>> >
> >>>> >On 16 July 2015 at 21:52, Mihai Chira <mi...@gmail.com> wrote:
> >>>> >>> changes. Can you take a look?
> >>>> >>
> >>>> >> on it
> >>>>
> >>>>
> >>
>
>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Alex Harui <ah...@adobe.com>.
Hey Mihai,
I think the Mustella runs are a bit more stable and we're trying to clean
up failures and get a release out. Can you find some time to look at the
sort failures again?
Thanks,
-Alex
On 7/18/15, 12:39 PM, "Mihai Chira" <mi...@gmail.com> wrote:
>Yep, it's pretty clear which ones are still failing.
>
>I'm looking, for instance, at
>SF_module_sparkButtonBar_global_tester.mxml, whose only test case
>should run perfectly. I made a sample app which does (seemingly) the
>same thing, and the Sort and SortField do return the correct locale
>value ("ru-RU"). So in order to figure out why in mustella it's
>failing I'd need to debug it. I'm following the instructions on the
>wiki now.
>
>FYI while doing so I got an error about cygwinshell:
>"java.io.IOException: Cannot run program "${cygwinshell}":
>CreateProcess error=2, The system cannot find the file specified". And
>when I trace it with <echo> I get
>
>[echo] shell = ${cygwinshell}
>[echo] cygwinshell = ${cygwinshell}
>
>It worked only when I changed [1] into [2] in mustella/build.xml
>(basically to use the git shell).
>
>
>[1] <available file="/cygwin/bin/sh.exe" property="cygwinshell"
>value="/cygwin/bin/sh.exe"/>
><available file="/cygwin64/bin/sh.exe" property="cygwinshell"
>value="/cygwin64/bin/sh.exe"/>
>
>[2] <property name="cygwinshell" value="c:\Program Files
>(x86)\Git\bin\sh.exe"/>
>
>
>On 17 July 2015 at 15:09, Alex Harui <ah...@adobe.com> wrote:
>> I wasn’t able to reset mustella until just now so it might be hard to
>>find
>> your results in the 100’s of errors in build # 1533. Hopefully build #
>> 1534 will be cleaner.
>>
>> FWIW, my magic incantation that resets mustella is to log into the
>>server,
>> open ApacheFlex/dependencies/FlashPlayer_Debug and click on and close
>>each
>> debug player. No idea why it works. Maybe Tom can try that some day to
>> see if it works for him as well.
>>
>> -Alex
>>
>> On 7/17/15, 3:16 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>>
>>>Cool, thanks for the link. I'll take a look tonight or tomorrow at the
>>>results.
>>>On 16 Jul 2015 22:53, "Alex Harui" <ah...@adobe.com> wrote:
>>>
>>>> The link at [1] is the build server that is currently down. It
>>>>doesn’t
>>>> run mustella.
>>>>
>>>> Mustella tests are at http://flex-mustella.cloudapp.net and failures
>>>>are
>>>> sent to commits@
>>>>
>>>> Every couple of days, we start getting weird failures that requires
>>>> fiddling with the mustella server. It looks like we’re in that funky
>>>> state right now so I will try to deal with that in about 3 hours so
>>>>the
>>>> next run after that should show the effects of your changes.
>>>>
>>>> -Alex
>>>>
>>>> On 7/16/15, 1:48 PM, "Mihai Chira" <mi...@gmail.com> wrote:
>>>>
>>>> >At least one of the failures should now be fixed. If others are left,
>>>> >I'll tackle them in the next few days.
>>>> >How can I monitor the test results? The bookmark I have for the build
>>>> >server is this[1] and it doesn't seem to be working. Sorry if there
>>>> >was a url change that I didn't catch.
>>>> >
>>>> >[1] http://apacheflexbuild.cloudapp.net:8080/job/flex-sdk_test/
>>>> >
>>>> >On 16 July 2015 at 21:52, Mihai Chira <mi...@gmail.com> wrote:
>>>> >>> changes. Can you take a look?
>>>> >>
>>>> >> on it
>>>>
>>>>
>>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Mihai Chira <mi...@gmail.com>.
Yep, it's pretty clear which ones are still failing.
I'm looking, for instance, at
SF_module_sparkButtonBar_global_tester.mxml, whose only test case
should run perfectly. I made a sample app which does (seemingly) the
same thing, and the Sort and SortField do return the correct locale
value ("ru-RU"). So in order to figure out why in mustella it's
failing I'd need to debug it. I'm following the instructions on the
wiki now.
FYI while doing so I got an error about cygwinshell:
"java.io.IOException: Cannot run program "${cygwinshell}":
CreateProcess error=2, The system cannot find the file specified". And
when I trace it with <echo> I get
[echo] shell = ${cygwinshell}
[echo] cygwinshell = ${cygwinshell}
It worked only when I changed [1] into [2] in mustella/build.xml
(basically to use the git shell).
[1] <available file="/cygwin/bin/sh.exe" property="cygwinshell"
value="/cygwin/bin/sh.exe"/>
<available file="/cygwin64/bin/sh.exe" property="cygwinshell"
value="/cygwin64/bin/sh.exe"/>
[2] <property name="cygwinshell" value="c:\Program Files (x86)\Git\bin\sh.exe"/>
On 17 July 2015 at 15:09, Alex Harui <ah...@adobe.com> wrote:
> I wasn’t able to reset mustella until just now so it might be hard to find
> your results in the 100’s of errors in build # 1533. Hopefully build #
> 1534 will be cleaner.
>
> FWIW, my magic incantation that resets mustella is to log into the server,
> open ApacheFlex/dependencies/FlashPlayer_Debug and click on and close each
> debug player. No idea why it works. Maybe Tom can try that some day to
> see if it works for him as well.
>
> -Alex
>
> On 7/17/15, 3:16 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>
>>Cool, thanks for the link. I'll take a look tonight or tomorrow at the
>>results.
>>On 16 Jul 2015 22:53, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>> The link at [1] is the build server that is currently down. It doesn’t
>>> run mustella.
>>>
>>> Mustella tests are at http://flex-mustella.cloudapp.net and failures are
>>> sent to commits@
>>>
>>> Every couple of days, we start getting weird failures that requires
>>> fiddling with the mustella server. It looks like we’re in that funky
>>> state right now so I will try to deal with that in about 3 hours so the
>>> next run after that should show the effects of your changes.
>>>
>>> -Alex
>>>
>>> On 7/16/15, 1:48 PM, "Mihai Chira" <mi...@gmail.com> wrote:
>>>
>>> >At least one of the failures should now be fixed. If others are left,
>>> >I'll tackle them in the next few days.
>>> >How can I monitor the test results? The bookmark I have for the build
>>> >server is this[1] and it doesn't seem to be working. Sorry if there
>>> >was a url change that I didn't catch.
>>> >
>>> >[1] http://apacheflexbuild.cloudapp.net:8080/job/flex-sdk_test/
>>> >
>>> >On 16 July 2015 at 21:52, Mihai Chira <mi...@gmail.com> wrote:
>>> >>> changes. Can you take a look?
>>> >>
>>> >> on it
>>>
>>>
>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Alex Harui <ah...@adobe.com>.
I wasn’t able to reset mustella until just now so it might be hard to find
your results in the 100’s of errors in build # 1533. Hopefully build #
1534 will be cleaner.
FWIW, my magic incantation that resets mustella is to log into the server,
open ApacheFlex/dependencies/FlashPlayer_Debug and click on and close each
debug player. No idea why it works. Maybe Tom can try that some day to
see if it works for him as well.
-Alex
On 7/17/15, 3:16 AM, "Mihai Chira" <mi...@gmail.com> wrote:
>Cool, thanks for the link. I'll take a look tonight or tomorrow at the
>results.
>On 16 Jul 2015 22:53, "Alex Harui" <ah...@adobe.com> wrote:
>
>> The link at [1] is the build server that is currently down. It doesn’t
>> run mustella.
>>
>> Mustella tests are at http://flex-mustella.cloudapp.net and failures are
>> sent to commits@
>>
>> Every couple of days, we start getting weird failures that requires
>> fiddling with the mustella server. It looks like we’re in that funky
>> state right now so I will try to deal with that in about 3 hours so the
>> next run after that should show the effects of your changes.
>>
>> -Alex
>>
>> On 7/16/15, 1:48 PM, "Mihai Chira" <mi...@gmail.com> wrote:
>>
>> >At least one of the failures should now be fixed. If others are left,
>> >I'll tackle them in the next few days.
>> >How can I monitor the test results? The bookmark I have for the build
>> >server is this[1] and it doesn't seem to be working. Sorry if there
>> >was a url change that I didn't catch.
>> >
>> >[1] http://apacheflexbuild.cloudapp.net:8080/job/flex-sdk_test/
>> >
>> >On 16 July 2015 at 21:52, Mihai Chira <mi...@gmail.com> wrote:
>> >>> changes. Can you take a look?
>> >>
>> >> on it
>>
>>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Mihai Chira <mi...@gmail.com>.
Cool, thanks for the link. I'll take a look tonight or tomorrow at the
results.
On 16 Jul 2015 22:53, "Alex Harui" <ah...@adobe.com> wrote:
> The link at [1] is the build server that is currently down. It doesn’t
> run mustella.
>
> Mustella tests are at http://flex-mustella.cloudapp.net and failures are
> sent to commits@
>
> Every couple of days, we start getting weird failures that requires
> fiddling with the mustella server. It looks like we’re in that funky
> state right now so I will try to deal with that in about 3 hours so the
> next run after that should show the effects of your changes.
>
> -Alex
>
> On 7/16/15, 1:48 PM, "Mihai Chira" <mi...@gmail.com> wrote:
>
> >At least one of the failures should now be fixed. If others are left,
> >I'll tackle them in the next few days.
> >How can I monitor the test results? The bookmark I have for the build
> >server is this[1] and it doesn't seem to be working. Sorry if there
> >was a url change that I didn't catch.
> >
> >[1] http://apacheflexbuild.cloudapp.net:8080/job/flex-sdk_test/
> >
> >On 16 July 2015 at 21:52, Mihai Chira <mi...@gmail.com> wrote:
> >>> changes. Can you take a look?
> >>
> >> on it
>
>
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Alex Harui <ah...@adobe.com>.
The link at [1] is the build server that is currently down. It doesn’t
run mustella.
Mustella tests are at http://flex-mustella.cloudapp.net and failures are
sent to commits@
Every couple of days, we start getting weird failures that requires
fiddling with the mustella server. It looks like we’re in that funky
state right now so I will try to deal with that in about 3 hours so the
next run after that should show the effects of your changes.
-Alex
On 7/16/15, 1:48 PM, "Mihai Chira" <mi...@gmail.com> wrote:
>At least one of the failures should now be fixed. If others are left,
>I'll tackle them in the next few days.
>How can I monitor the test results? The bookmark I have for the build
>server is this[1] and it doesn't seem to be working. Sorry if there
>was a url change that I didn't catch.
>
>[1] http://apacheflexbuild.cloudapp.net:8080/job/flex-sdk_test/
>
>On 16 July 2015 at 21:52, Mihai Chira <mi...@gmail.com> wrote:
>>> changes. Can you take a look?
>>
>> on it
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Mihai Chira <mi...@gmail.com>.
At least one of the failures should now be fixed. If others are left,
I'll tackle them in the next few days.
How can I monitor the test results? The bookmark I have for the build
server is this[1] and it doesn't seem to be working. Sorry if there
was a url change that I didn't catch.
[1] http://apacheflexbuild.cloudapp.net:8080/job/flex-sdk_test/
On 16 July 2015 at 21:52, Mihai Chira <mi...@gmail.com> wrote:
>> changes. Can you take a look?
>
> on it
Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34854
FLEX-34884 Adding unit test to make sure that the changes in FLEX-34854
haven't changed anything about findItem.
Posted by Mihai Chira <mi...@gmail.com>.
> changes. Can you take a look?
on it