Allow Java devices to customize action errors

[simonc]

(11-08-2012 12:26 PM)simoncn Wrote:  I'm attaching a zip file containing diffs for the following:

Thanks. I've applied these locally so they should be on github this evening.

[simoncn]

(13-08-2012 08:44 AM)simonc Wrote:  Thanks. I've applied these locally so they should be on github this evening.

I've found a small typo in the code changes for Invocation.c. In line 172:

Code:

printf("Unable to find constructor for class org/openhome/net/controlpoint/proxyError\n");

'proxyError' should be 'ProxyError'. It's only an error message, so it doesn't affect the correct functioning of the code, but it can be confusing if this error message is displayed (as it was for me during recent testing).

I've also tracked down the reason for double-spacing in code sections where recent patches have been applied. If a file contains a mixture of Unix-style LF line endings and Windows-style CR/LF line endings, the text editor I'm using displays the CR/LF lines as double-spaced. I've produced the recent patches using Windows, so the code I've provided has contained CR/LF line endings, but the files on Github seem to use LF line endings as the standard.

Do you see this problem when you view lines 137 through 192 of Invocation.c in a test editor? It affects a few other places as well, and I'd be happy to produce a complete list of these.

[simonc]

You're not getting much of a break on your holiday

(22-08-2012 10:20 PM)simoncn Wrote:  I've found a small typo in the code changes for Invocation.c. In line 172:

I've fixed this locally; it should be on github this evening.

(22-08-2012 10:20 PM)simoncn Wrote:  I've also tracked down the reason for double-spacing in code sections where recent patches have been applied. If a file contains a mixture of Unix-style LF line endings and Windows-style CR/LF line endings, the text editor I'm using displays the CR/LF lines as double-spaced. I've produced the recent patches using Windows, so the code I've provided has contained CR/LF line endings, but the files on Github seem to use LF line endings as the standard.

Do you see this problem when you view lines 137 through 192 of Invocation.c in a test editor? It affects a few other places as well, and I'd be happy to produce a complete list of these.

I was prompted to fix the line endings in Invocation.c when I applied your suggested change so this file is consistent again. Don't worry about listing other files - the check_ws.py script in the ohdevtools repo will do this (and optionally fix them) for us. I've been periodically running it to fix line endings. We'll probably change to using pre-commit rules to validate line endings in future.

[simoncn]

(23-08-2012 08:24 AM)simonc Wrote:  You're not getting much of a break on your holiday

Email first thing in the morning, sightseeing and walking during the day, out for dinner, then a couple of hours programming (better than watching TV!)

[simoncn]

(23-08-2012 08:24 AM)simonc Wrote:  I was prompted to fix the line endings in Invocation.c when I applied your suggested change so this file is consistent again. Don't worry about listing other files - the check_ws.py script in the ohdevtools repo will do this (and optionally fix them) for us. I've been periodically running it to fix line endings. We'll probably change to using pre-commit rules to validate line endings in future.

There are still some of these line ending problems lurking in the code. I found a block of double-spaced code today in OpenHome/Net/Bindings/Java/Invocation.c, starting around line 137. Do you see this problem when you look at this file?

[simonc]

(01-10-2012 12:45 PM)simoncn Wrote:  There are still some of these line ending problems lurking in the code. I found a block of double-spaced code today in OpenHome/Net/Bindings/Java/Invocation.c, starting around line 137. Do you see this problem when you look at this file?

Yep, I can see a mix of line endings too. I'll tidy these up in the next couple of days.

I could fix this properly by using a .gitattribute file to ensure line endings are converted on commit. This'd make things awkward for you if you currently have a repo with local changes to ohNet files. Once you'd resolved any conflicts once, things would work correctly. Do you think the small amount of hassle this could cause is worth it?

[simoncn]

(01-10-2012 12:50 PM)simonc Wrote:  

(01-10-2012 12:45 PM)simoncn Wrote:  There are still some of these line ending problems lurking in the code. I found a block of double-spaced code today in OpenHome/Net/Bindings/Java/Invocation.c, starting around line 137. Do you see this problem when you look at this file?

Yep, I can see a mix of line endings too. I'll tidy these up in the next couple of days.

I could fix this properly by using a .gitattribute file to ensure line endings are converted on commit. This'd make things awkward for you if you currently have a repo with local changes to ohNet files. Once you'd resolved any conflicts once, things would work correctly. Do you think the small amount of hassle this could cause is worth it?

I don't have a local Git repo, so this wouldn't be an issue for me. At the moment I just download the .tar.gz file when I need to pick up a new level of the code.

What's the best way to fix this where it occurs in the current codebase? Do you have a script that can scan all the files? If not, I could look through the files in Bindings/Java to see what I can find.

[simonc]

(01-10-2012 02:13 PM)simoncn Wrote:  I don't have a local Git repo, so this wouldn't be an issue for me. At the moment I just download the .tar.gz file when I need to pick up a new level of the code.

What's the best way to fix this where it occurs in the current codebase? Do you have a script that can scan all the files? If not, I could look through the files in Bindings/Java to see what I can find.

I have a script which fixes things. I'll run it in the next day or so. Then add a .gitattribute file to prevent this recurring.

[simonc]

This evenings build should normalise line endings for most source files. (JavaScript is outstanding but that hopefully won't bother you.)

[simoncn]

Thanks very much!