Python code generation bug in switch statement

[joel-arthur]

In SuitesRunner.hx the following function is defined.

private function isSync(funcs : Iterable) : Bool {
for (f in funcs) switch f {
case Async(): return false;
case Sync():
}
return true;
}

On my Windows Server 2008 machine, this gets turned into the below in python:

def isSync(self,funcs):
# C:\HaxeToolkit\haxe\lib\buddy/2,2,0/buddy/SuitesRunner.hx:306
# C:\HaxeToolkit\haxe\lib\buddy/2,2,0/buddy/SuitesRunner.hx:306
tmp = HxOverrides.iterator(funcs)
while tmp.hasNext():
if ((tmp.next().index) == 0):
return False
elif ((tmp.next().index) == 1):
pass
else:
pass
# C:\HaxeToolkit\haxe\lib\buddy/2,2,0/buddy/SuitesRunner.hx:310
return True

When run I get this error do to the multiple tmp.next() calls:

File "C:\Users\administrator.HOSTINTEGRATION\Desktop\Haxe\solidfire-sdk-haxe\bin\RunTests.py", line 8040, in isSync
elif ((tmp.next().index) == 1):
AttributeError: 'NoneType' object has no attribute 'index'

Updating the code to the following fixes the issue:

private function isSync(funcs : Iterable) : Bool {
for (f in funcs) switch f {
case Async(_): return false;
default:
}
return true;
}

This does not happen on my Windows 10 PC or on Mac.

Using Python 3.5 and Buddy 2.2.0, and Haxe 3.2 on all machines.

I will open a bug with the haxe project, but I wasnt sure if you wanted to work around the issue in the mean time.

[joel-arthur]

Let me know if you would rather open the Issue since you know more about the code base. I have not had time to look into what the Async() and Sync() cases actually are doing or where they are defined.

[ciscoheat]

Thanks for reporting, it should be a python bug probably, but can you try with 3.3 as well, now when it's in RC, to see if it's fixed there already?

[ciscoheat]

I was making an update anyway, so I added this fix in the latest version. Can you confirm that it works?

[joel-arthur]

Hi Andreas,

The update is working for me. Thank you for the quick turnaround!

I have 2 unrelated questions for you whenever you have time. No rush.

1.  When an exception is thrown in a beforeEach, I don’t actually see the error. It ends up looking like this:
   

Traceback (most recent call last):
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 15807, in
RunTests.main()
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 6314, in main
startRun(_hx_local_4)
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 6307, in _hx_local_3
runner.run().then(_hx_local_2)
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 8694, in run
self.runDescribes(_hx_local_0)
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 8812, in runDescribes
processBuddySuites()
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 8781, in _hx_local_8
processBuddySuites1()
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 8808, in _hx_local_8
cb(None)
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 8692, in _hx_local_0
_g.startRun()
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 8882, in startRun
self.reporter.start().then(_hx_local_6)
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 13253, in then
promhx_base_AsyncBase.immediateLinkUpdate(self,next,f1)
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 13022, in immediateLinkUpdate
next.handleError(e)
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 13283, in handleError
self._handleError(error)
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 12949, in _handleError
promhx_base_EventLoop.continueOnNextLoop()
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 13899, in continueOnNextLoop
promhx_base_EventLoop.f()
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 13888, in f
fn()
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 12946, in _hx_local_3
update_errors(error)
File "C:\Users\joela\repos\solidfire-sdk-haxe\bin\RunTests.py", line 12922, in _hx_local_2
raise _HxException(e)
main._HxException: 'NoneType' object has no attribute 'error'

If I wrap everything in a try/catch the error is apparent.

Is there a better way I should be doing this? Or would this try/catch method be preferable?

2. So in my project I have many suites. My main file to kick off tests looks like this (simple example of what I have):

import Setup;
import buddy.*;
using buddy.Should;

class RunTests implements Buddy<[

    #if(Suite1 || all)
    Suite1,
    #end

    #if(Suite2 || all)
    Suite2,
    #end

    #if(Suite3 || all)
    Suite3,
    #end


    //needed because we need to ensure the last suite has no comma
    DummySuite

]>
{
static function main()
{
}
}

class DummySuite extends BuddySuite { public function new() {} }

Basically I can then compile with “–D Suite1” or “–D all” to run different suites.

What I am wondering here is if there is a way to dynamically create a list of suites to feed into RunTests to clean this up a bit and remove the need for the DummySuite. As you can imagine this gets increasingly complex with more suites

Thank you so much for all your work on this project. I truly appreciate it.

From: Andreas [mailto:[email protected]]
Sent: Tuesday, June 7, 2016 7:41 AM
To: ciscoheat/buddy [email protected]
Cc: Arthur, Joel [email protected]; Author [email protected]
Subject: Re: [ciscoheat/buddy] Python code generation bug in switch statement (#55)

I was making an update anyway, so I added this fix in the latest version. Can you confirm that it works?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/55#issuecomment-224283394, or mute the threadhttps://github.com/notifications/unsubscribe/AOZHbYefsgc4_lKRrGORwZzcrNjju1Bnks5qJXTPgaJpZM4IvR8V.

[ciscoheat]

Thanks for the catch! It was a problem in the before/after error handling actually. I've fixed it and have released a new version.

The dynamically suite creation is interesting, how would you like it to work? Where should it happen?

[joel-arthur]

Oh wow great! Thank you for taking care of that so quickly.

I am out on vacation through the weekend, but I'll be thinking of how this could work. I would imagine passing an array of suites to some function would work, but I'm not sure how that would look.

Thanks again!

Joel

---

From: Andreas <[email protected]mailto:[email protected]>
Sent: Thursday, June 9, 2016 6:15 AM
Subject: Re: [ciscoheat/buddy] Python code generation bug in switch statement (#55)
To: ciscoheat/buddy <[email protected]mailto:[email protected]>
Cc: Author <[email protected]mailto:[email protected]>, Arthur, Joel <[email protected]mailto:[email protected]>

Thanks for the catch! It was a problem in the before/after error handling actually. I've fixed it and have released a new version.

The dynamically suite creation is interesting, how would you like it to work? Where should it happen?

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/55#issuecomment-224877089, or mute the threadhttps://github.com/notifications/unsubscribe/AOZHbTi2az9oZW2TNtCWNJgdxoJCKad4ks5qKAPWgaJpZM4IvR8V.

[joel-arthur]

Forgot to ask if there is a way to fail a test if the before fails.

Thanks!

Get Outlook for iOShttps://aka.ms/o0ukef

On Thu, Jun 9, 2016 at 6:15 AM -0600, "Andreas" <[email protected]mailto:[email protected]> wrote:

Thanks for the catch! It was a problem in the before/after error handling actually. I've fixed it and have released a new version.

The dynamically suite creation is interesting, how would you like it to work? Where should it happen?

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/55#issuecomment-224877089, or mute the threadhttps://github.com/notifications/unsubscribe/AOZHbTi2az9oZW2TNtCWNJgdxoJCKad4ks5qKAPWgaJpZM4IvR8V.

[ciscoheat]

Not at the moment, for now I'd like to regard failures outside the actual test as a deeper issue that won't be handled by Buddy. I'll put it on the list for future features.