This is in response to issue #2029

Regarding the .idea directory, you need to use the git rm command to make sure git knows you are intending to remove these files. Before committing make sure to run git status (just in general, as good practice) and if done correctly it will shows those files marked for deletion. Then please go ahead and do an interactive rebase of your branch so as to remove those files in the first place. This is a decent guide to the process: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

There were some issues with git on my system which is why I was unable to delete the .idea files but I fixed them and was finally able to delete the .idea files! Is there any more work that I should do on this branch or can it be merged now?

@anizami - this is a good start, but I think it would be better if we could avoid having all the if method_name logic in the _retry method. This could be solved by passing a params list/tuple to the reply method containing the samp.params. This can then be used directly to construct the callback dictionary. In addition, you could pass the SAMP method name as another parameter, and you can then get rid of the if logic for the web profile. For the standard provile, you can then also get rid of the if logic because if you can get the method in a more generic way, you could then do method(recipient_private_key, *params). Does this make sense? Let me know if anything is unclear.

@anizami - for the number of tries, this should be made a configuration item at the top of the file, following instructions from http://docs.astropy.org/en/stable/api/astropy.config.configuration.ConfigurationItem.html?highlight=configurationitem

And you definitely still need to do a git rebase--the reason for this is that this will eventually be merged into the master branch, but first it's best to clean up the history so it doesn't involve files that shouldn't have been there in the first place 💁

I'm sorry for not being able to work on this sooner, classes kept me really busy! I've worked on the changes @astrofrog suggested and I've added a configuration parameter (I hope I did it correctly, if not let me know and I'll fix it). The code does look a lot nicer without the if statements but I'm not sure how to get rid of the if statements for the Standard profile. That part of the code has
hub.samp.client.specificmethodname(...). Suggestions on how I can also pass that methodname as a parameter? I'll do a git rebase after everything looks good.

@anizami - thanks! I'll review this soon, but in the mean time, for the standard profile, you could do e.g. getattr(hub.samp.client, 'receiveCall') instead of hub.samp.client.receiveCall (which then allows you to get rid of the if statement).

@anizami - have you had a chance to try my suggestion to make use of getattr to avoid the if statements for the standard profile? Thanks for working on this by the way!

@astrofrog My bad! I thought I'd hear back from you before starting to work on removing the last code using if statements. I've also been kind of busy with another project so this slipped my mind. I'll start working on this soon and I should have it done by tomorrow night (in about 24 hours). By the way, what does it mean that Travis CI build could not complete due to an error? Does the current package have tests that GitHub automatically runs to test the code? Does this mean my code has broken something?

@anizami - the fact that quite a few of the builds are failing means it's likely real (we get flukes from time to time). You can try and run:

python setup.py test -P vo.samp

to see what the results of the tests are locally. It may be a little tricky to debug, so if you get stuck trying to figure out what went wrong, let me know!

@anizami - apart from my comment above, this looks good to me so far, so try and implement what we discussed above, and see if you can get the tests passing locally. Thanks!

@astrofrog - I'm not familiar with using getattr(...) but I think I've used it with the correct syntax. I also changed the code to access N_RETRIES using N_RETRIES(). The Travis CI build is still in progress so I'll try running the tests locally once I'm sure there are bugs.

@anizami - re: testing, it's usually a good idea to always test locally before pushing to the pull request. You will get the results a lot faster, and it will be easier to debug. It looks like most builds are failing, so this is likely a genuine error. Let me know if you don't understand the failures and need help in fixing them!

@astrofrog - I'm trying to run the tests locally but I'm running into some problems. When I type in the command 'python setup.py test -P vo.samp', I get this:

============================= test session starts =============================
platform win32 -- Python 2.7.6 -- pytest-2.5.1

Running tests with Astropy version 0.4.dev7709.
Running tests in astropy\vo\samp C:\Users\Asra Nizami[astropy]\docs\vo\samp.

Platform: Windows-7-6.1.7601-SP1

Executable: C:\Anaconda\python.exe

Full Python Version:
2.7.6 |Anaconda 1.9.1 (64-bit)| (default, Nov 11 2013, 10:49:15) [MSC v.1500 64
bit (AMD64)]

encodings: sys: ascii, locale: cp1252, filesystem: mbcs, unicode bits: 15
byteorder: little
float info: dig: 15, mant_dig: 15

Numpy: 1.8.0
Scipy: 0.13.3
Matplotlib: 1.3.1
h5py: 2.2.1

ERROR: file not found: C:\Users\Asra
============================== in 0.41 seconds ===============================
And then it just isn't running the tests. I'm not sure why this is happening. Suggestions? Do you think it's because Python has problem with the space in my user folder name 'Asra Nizami'?

Oh wait, never mind. I tried moving it to a different folder and am running the tests now. Let's see what happens.

@astrofrog- I'm still having problems running the tests locally. The tests are giving me the exception =

"Exception: Timeout while waiting for file: c:\users\asrani~1\appdata\local\temp\tmpr2bkov\0dMnFfWjcCDUZwPe"

at the test_helpers.py test.
I've been looking the test files and this is what I think is going on: the test_helpers.py file has a class Receiver, which generates random parameters and the test_standard_profile.py file creates new Receiver objects which end up using these parameters. I know from the output of the tests that it's passing the params=

params = {'parameter1': 'abcde', 'parameter2': 1331, 'verification_file': 'c:\users\asrani~1\appdata\local\temp\tmpr2bkov\0dMnFfWjcCDUZwPe'}

I'm confused about where to go from here. The directory that I have on my computer is 'C:users\Asra Nizami' and there's nothing like 'C:users\asran~1'. Do you think the tests wrong when they generate those random parameters and they're unable to run successfully on my computer? I don't think this is the reason the Travis CI build is failing though- what I'm facing only seems to be a local issue.

We need to look into this further since there are still failures, so I will remove the 1.0 milestone for now.

Since the failures are a bit weird I am going to take over the pull request (but will preserve the existing commits)

Closing, since this has been replaced by #3612 and is not the original issue (which is #2029)