unit test failed with as3-signal 0.8

[thanhbv]

2/42 failed:

1. failure message="Expected: [<[class SampleCommandA]>, <[class SampleCommandC]>] but: was [<[class SampleCommandC]>,<[class SampleCommandA]>]" type="org.robotlegs.base::GuardedSignalCommandMapTests.three_commands_with_different_guards_fire_correctly"
2. failure message="Expected: [<[class SampleCommandA]>, <[class SampleCommandC]>] but: was [<[class SampleCommandC]>,<[class SampleCommandA]>]" type="org.robotlegs.base::GuardedSignalCommandMapTests.signal_values_passed_to_guards"

[thanhbv]

I want to update as3-signal to 0.8, SwiftSuspenders to 1.6.0.

updating SwiftSuspenders is OK (42/42 test passed), but updating as3-signals cause 2/42 test cases failed as above.

How to reproduce:

• git latest signals-extensions-CommandSignal source (cf791cc)
• replace build/bin/as3-signals-v0.7.swc by as3-signals-v0.8.swc
• ant

[Stray]

I'm not able to recreate this - updating to the signals 0.8 swc hasn't changed anything.
However - the error you're reporting is an order-of-operations error - for some reason the last-added command is firing first.

I've pushed to my fork, which now has the SS1.6 and Signals 0.8 swcs in. Can you grab the source from my fork and confirm that it's still giving you the error?

If you're still seeing the problem, can you raise an issue on the Signals repo, as signals should fire in the order in which they're added - so we might need Mr Penner's help here too.

Thx

Stray

[thanhbv]

Oh, sorry :D,
I use the latest signals source (2be6d9874f65223f2d2c), not the v0.8 tag.
signals-extensions-CommandSignal with signals v0.8 => 42/42 passed

[Stray]

This issue is indeed in the current source. Joa's new linked-list implementation runs backward through the signals. Robert is aware of the issue and the next release will either provide a work-around (an option to run signals in order added) or it will be official that they run backwards and we'll manage the ordering internally in the SCM itself.

[neilmanuell]

I wrote a PrioritySignal that is basically a Signal that will execute with a) a given priority or b) in the order in which it was added. it is in the head here https://github.com/robertpenner/as3-signals/tree/master/src/org/osflash/signals.

if the order of a signal's execution is paramount, use the PrioritySignal, the dispatching will be suboptimal, but the order will be correct
tests are there too

can this issue be closed?