Discussion:
[sword-devel] c# unit test patch
Daniel Hughes
2014-09-02 11:07:59 UTC
Permalink
Attached is a patch which fixes one of the locale unit tests. This
test was assuming that english 'en' was the always the first locale
and this simply is not always the case. Meaning this test would pass
sometimes on some boxes but not on others.
-------------- next part --------------
Index: bindings/csharp/tests/ManagerTests.cs
===================================================================
--- bindings/csharp/tests/ManagerTests.cs (revision 3254)
+++ bindings/csharp/tests/ManagerTests.cs (working copy)
@@ -14,6 +14,7 @@
using System;
using NUnit.Framework;
using System.IO;
+using System.Collections.Generic;
using System.Linq;

namespace Sword.Tests
@@ -84,13 +85,23 @@
public void AvailableLocales_Get_DoesntCrash()
{
//act
- var availableLocales = _manager.AvailableLocales.ToArray();
+ string[] availableLocales = _manager.AvailableLocales.ToArray();

//Assert
- Assert.That (availableLocales[0].Contains("en"));
+ Assert.That (availableLocales.Length > 0);
}

[Test]
+ public void AvailableLocales_Get_ContainsEnglish()
+ {
+ //act
+ string[] availableLocales = _manager.AvailableLocales.ToArray();
+
+ //Assert
+ Assert.That (availableLocales.Any(locale => locale == "en"));
+ }
+
+ [Test]
public void DefaultLocale_SetToEn_DoesntCrash()
{
//act
Jon Behrens
2014-09-02 22:24:54 UTC
Permalink
Praise God - after a week of fooling with this, I have finally gotten
the C# binding example to work. Here's how I did it.

Starting with a clean Linux Mint 17 install (Ubuntu derivative), install
the following software (Thanks Troy for the list)

subversion //Probably only needed if you don't download the tar file
automake
libtool
g++
zlib1g-dev
libicu-dev
libcurl4-openssl-dev
libclucene-dev

monodevelop
mono-complete

Go to http://crosswire.org/sword/develop/index.jsp and download and
extract the files into a directory ~/sword-1.7.3 in this case.

Rename the directory from sword-1-7.3 to sword - this will prevent
getting a library named sword-1.7.3.so. Not necessarily a problem, but
you would have to change the name of the library that the examples are
searching for.

Edit the file usrinst.sh. Near the top of the file is a line:

OPTIONS="--disable-shared $OPTIONS"

Comment that line out - or remove it, I suppose. This will get the make
to generate a shared library in addition to the static one.

Open the INSTALL file in a window so you can refer to it and follow the
instructions.

If the examples in ~/sword/examples/cmdline work, you've got everything
set up properly.

Now edit /etc/environment and add the line:

LD_LIBRARY_PATH="/usr/lib"

Assuming you've not changed the location of libsword.so from the default.

$ source /etc/environment

Now open monodevelop and open the project file in ~/sword/bindings/csharp

There are three projects in the solution. Expand Sword.tests and edit
the References. Remove nunit.core and nunit.framework. In the Assembly
tree, check nunit.core and nunit.framework. For some reason these
packages in the as-shipped solution cause the compile to fail. Removing
and replacing them fixes that problem.

Build the solution and run the LookupExample.
Daniel Hughes
2014-09-03 00:55:53 UTC
Permalink
Can you please send me your updated project files (with the nunit
references changed). So I can diff them with mine.

The root of this issue is that monodevelop bundles nunit but there is
also separate nunit debian packages. Monodevelop doesn't handle this
conflict well.

MonoDevelop on linux creates package hints in the project files which
may be causing the problem. Not 100% sure though so need you updated
project files.

Cheers,
Daniel Hugehs

On Wed, Sep 3, 2014 at 10:24 AM, Jon Behrens <jbb at crimsonthread.com> wrote:
> Praise God - after a week of fooling with this, I have finally gotten the C#
> binding example to work. Here's how I did it.
>
> Starting with a clean Linux Mint 17 install (Ubuntu derivative), install the
> following software (Thanks Troy for the list)
>
> subversion //Probably only needed if you don't download the tar file
> automake
> libtool
> g++
> zlib1g-dev
> libicu-dev
> libcurl4-openssl-dev
> libclucene-dev
>
> monodevelop
> mono-complete
>
> Go to http://crosswire.org/sword/develop/index.jsp and download and extract
> the files into a directory ~/sword-1.7.3 in this case.
>
> Rename the directory from sword-1-7.3 to sword - this will prevent getting a
> library named sword-1.7.3.so. Not necessarily a problem, but you would have
> to change the name of the library that the examples are searching for.
>
> Edit the file usrinst.sh. Near the top of the file is a line:
>
> OPTIONS="--disable-shared $OPTIONS"
>
> Comment that line out - or remove it, I suppose. This will get the make to
> generate a shared library in addition to the static one.
>
> Open the INSTALL file in a window so you can refer to it and follow the
> instructions.
>
> If the examples in ~/sword/examples/cmdline work, you've got everything set
> up properly.
>
> Now edit /etc/environment and add the line:
>
> LD_LIBRARY_PATH="/usr/lib"
>
> Assuming you've not changed the location of libsword.so from the default.
>
> $ source /etc/environment
>
> Now open monodevelop and open the project file in ~/sword/bindings/csharp
>
> There are three projects in the solution. Expand Sword.tests and edit the
> References. Remove nunit.core and nunit.framework. In the Assembly tree,
> check nunit.core and nunit.framework. For some reason these packages in the
> as-shipped solution cause the compile to fail. Removing and replacing them
> fixes that problem.
>
> Build the solution and run the LookupExample.
>
>
>
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
Jon Behrens
2014-09-03 16:23:56 UTC
Permalink
Hi Daniel
Here's my project directory.
Also, is anyone that you know of actively developing a Sword front end
in C#?
Best
Jon

On 09/02/2014 06:55 PM, Daniel Hughes wrote:
> Can you please send me your updated project files (with the nunit
> references changed). So I can diff them with mine.
>
> The root of this issue is that monodevelop bundles nunit but there is
> also separate nunit debian packages. Monodevelop doesn't handle this
> conflict well.
>
> MonoDevelop on linux creates package hints in the project files which
> may be causing the problem. Not 100% sure though so need you updated
> project files.
>
> Cheers,
> Daniel Hugehs
>
> On Wed, Sep 3, 2014 at 10:24 AM, Jon Behrens <jbb at crimsonthread.com> wrote:
>> Praise God - after a week of fooling with this, I have finally gotten the C#
>> binding example to work. Here's how I did it.
>>
>> Starting with a clean Linux Mint 17 install (Ubuntu derivative), install the
>> following software (Thanks Troy for the list)
>>
>> subversion //Probably only needed if you don't download the tar file
>> automake
>> libtool
>> g++
>> zlib1g-dev
>> libicu-dev
>> libcurl4-openssl-dev
>> libclucene-dev
>>
>> monodevelop
>> mono-complete
>>
>> Go to http://crosswire.org/sword/develop/index.jsp and download and extract
>> the files into a directory ~/sword-1.7.3 in this case.
>>
>> Rename the directory from sword-1-7.3 to sword - this will prevent getting a
>> library named sword-1.7.3.so. Not necessarily a problem, but you would have
>> to change the name of the library that the examples are searching for.
>>
>> Edit the file usrinst.sh. Near the top of the file is a line:
>>
>> OPTIONS="--disable-shared $OPTIONS"
>>
>> Comment that line out - or remove it, I suppose. This will get the make to
>> generate a shared library in addition to the static one.
>>
>> Open the INSTALL file in a window so you can refer to it and follow the
>> instructions.
>>
>> If the examples in ~/sword/examples/cmdline work, you've got everything set
>> up properly.
>>
>> Now edit /etc/environment and add the line:
>>
>> LD_LIBRARY_PATH="/usr/lib"
>>
>> Assuming you've not changed the location of libsword.so from the default.
>>
>> $ source /etc/environment
>>
>> Now open monodevelop and open the project file in ~/sword/bindings/csharp
>>
>> There are three projects in the solution. Expand Sword.tests and edit the
>> References. Remove nunit.core and nunit.framework. In the Assembly tree,
>> check nunit.core and nunit.framework. For some reason these packages in the
>> as-shipped solution cause the compile to fail. Removing and replacing them
>> fixes that problem.
>>
>> Build the solution and run the LookupExample.
>>
>>
>>
>>
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

-------------- next part --------------
A non-text attachment was scrubbed...
Name: csharp.tar.gz
Type: application/gzip
Size: 35889 bytes
Desc: not available
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140903/5c3584cf/attachment-0001.bin>
Jon Behrens
2014-09-05 17:50:51 UTC
Permalink
Hello
Having gotten the C# binding examples to work in Linux, I thought I'd
try the same thing in
Windows. I built libsword.dll using the instructions at:

http://crosswire.org/wiki/Tutorial:Compiling_%26_Installing_SWORD_on_Windows

After renaming the icu directory to icu-sword so the make file could
find it, everything builds
using Visual Studio 2013.

So then copy the Linux directory /bindings/csharp to a Windows directory
and open the project
in VS2013. Again everything builds properly.

When I try and run the lookup example, I get an exception saying that
libsword.dll is a program
with an incorrect format. In the trace below, the error is listed as in
CSSword, but it occurs when
CSSword tries to access libsword.dll

Anyone have any idea what's going on?

Best,
Jon

{"An attempt was made to load a program with an incorrect format.
(Exception from HRESULT: 0x8007000B)"}
[System.BadImageFormatException]: {"An attempt was made to load a
program with an incorrect format. (Exception from HRESULT: 0x8007000B)"}
Data: {System.Collections.ListDictionaryInternal}
HelpLink: null
HResult: -2147024885
InnerException: null
Message: "An attempt was made to load a program with an incorrect
format. (Exception from HRESULT: 0x8007000B)"
Source: "CSSword"
StackTrace: " at
Sword.NativeMethods.org_crosswire_sword_SWMgr_new()\r\n at
Sword.Manager..ctor() in
n:\\development\\swordCsharp\\csharp\\Manager.cs:line 28"
TargetSite: {IntPtr org_crosswire_sword_SWMgr_new()}
Daniel Hughes
2014-09-06 12:32:33 UTC
Permalink
Your the first person to try the bindings on windows.

It could be the calling convention.

The bindings are written to use Cdecl calling convention.

It may be that Visual studio has built sword using the stdcall calling
convention.

I will need someone who knows more about c/c++ and the calling
conventions to comment on this.

You can try changing the calling convention in the bindings by editing
them in the NativeMethods.cs class to confirm this.

However if it turns out that sword does use a different calling
convention on windows to linux then that could be a problem. It may be
that you need to tell Visual Studio to build sword using Cdecl calling
convention.



On Sat, Sep 6, 2014 at 5:50 AM, Jon Behrens <jbb at crimsonthread.com> wrote:
> Hello
> Having gotten the C# binding examples to work in Linux, I thought I'd try
> the same thing in
> Windows. I built libsword.dll using the instructions at:
>
> http://crosswire.org/wiki/Tutorial:Compiling_%26_Installing_SWORD_on_Windows
>
> After renaming the icu directory to icu-sword so the make file could find
> it, everything builds
> using Visual Studio 2013.
>
> So then copy the Linux directory /bindings/csharp to a Windows directory and
> open the project
> in VS2013. Again everything builds properly.
>
> When I try and run the lookup example, I get an exception saying that
> libsword.dll is a program
> with an incorrect format. In the trace below, the error is listed as in
> CSSword, but it occurs when
> CSSword tries to access libsword.dll
>
> Anyone have any idea what's going on?
>
> Best,
> Jon
>
> {"An attempt was made to load a program with an incorrect format. (Exception
> from HRESULT: 0x8007000B)"}
> [System.BadImageFormatException]: {"An attempt was made to load a
> program with an incorrect format. (Exception from HRESULT: 0x8007000B)"}
> Data: {System.Collections.ListDictionaryInternal}
> HelpLink: null
> HResult: -2147024885
> InnerException: null
> Message: "An attempt was made to load a program with an incorrect
> format. (Exception from HRESULT: 0x8007000B)"
> Source: "CSSword"
> StackTrace: " at
> Sword.NativeMethods.org_crosswire_sword_SWMgr_new()\r\n at
> Sword.Manager..ctor() in
> n:\\development\\swordCsharp\\csharp\\Manager.cs:line 28"
> TargetSite: {IntPtr org_crosswire_sword_SWMgr_new()}
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
Jon Behrens
2014-09-11 02:27:09 UTC
Permalink
OK, I've narrowed things down a bit.

First, the problem may very well be with Windows 8.1 which doesn't
always play nice
with Win32 applications. After following all the directions, Dependency
Walker shows
mixed mode x86 and x64 libraries which causes it to give up.

I've rattled up a Windows 7 virtual machine which I'm going to try and
use with VS2010.

Couple of things with the Tutorial on compiling and installing Sword
with Windows here:
http://crosswire.org/wiki/Tutorial:Compiling_%26_Installing_SWORD_on_Windows

Everything's fine until I get down to CLucine. There it says to:

set BOOST_BUILD_PATH=$dir$\boost\tools\build\v2

That directory doesn't exist and CMake complains that it can't find
Boost (the Boost directory
does exist, just not that subdirectory). Does anyone know what's
actually being looked for here?

The project file for Sword is for VS2012, I've got VS2010 and VS2013. I
can probably hive out a
VS2010 file from VS2013, but if anyone has a VS2010 project file, that
would be a blessing.
(VS2013 won't run under Windows7.)

When I was squirreling around with Win8.1 and VS2013, I found the
following linker errors
in the Sword project file:

../../../curl/builds/libcurl-vc10-x86-release-static-ipv6-sspi-spnego-winssl/lib
(should be ...libcurl-vc-x86... the 10 is wrong)
../../../icu-sword/lib
(should be ...icu... icu-sword is wrong unless you rename the icu
directory)

Thanks for any help
Be blessed,
Jon

On 9/6/2014 6:32 AM, Daniel Hughes wrote:
> Your the first person to try the bindings on windows.
>
> It could be the calling convention.
>
> The bindings are written to use Cdecl calling convention.
>
> It may be that Visual studio has built sword using the stdcall calling
> convention.
>
> I will need someone who knows more about c/c++ and the calling
> conventions to comment on this.
>
> You can try changing the calling convention in the bindings by editing
> them in the NativeMethods.cs class to confirm this.
>
> However if it turns out that sword does use a different calling
> convention on windows to linux then that could be a problem. It may be
> that you need to tell Visual Studio to build sword using Cdecl calling
> convention.
>
>
>
> On Sat, Sep 6, 2014 at 5:50 AM, Jon Behrens <jbb at crimsonthread.com> wrote:
>> Hello
>> Having gotten the C# binding examples to work in Linux, I thought I'd try
>> the same thing in
>> Windows. I built libsword.dll using the instructions at:
>>
>> http://crosswire.org/wiki/Tutorial:Compiling_%26_Installing_SWORD_on_Windows
>>
>> After renaming the icu directory to icu-sword so the make file could find
>> it, everything builds
>> using Visual Studio 2013.
>>
>> So then copy the Linux directory /bindings/csharp to a Windows directory and
>> open the project
>> in VS2013. Again everything builds properly.
>>
>> When I try and run the lookup example, I get an exception saying that
>> libsword.dll is a program
>> with an incorrect format. In the trace below, the error is listed as in
>> CSSword, but it occurs when
>> CSSword tries to access libsword.dll
>>
>> Anyone have any idea what's going on?
>>
>> Best,
>> Jon
>>
>> {"An attempt was made to load a program with an incorrect format. (Exception
>> from HRESULT: 0x8007000B)"}
>> [System.BadImageFormatException]: {"An attempt was made to load a
>> program with an incorrect format. (Exception from HRESULT: 0x8007000B)"}
>> Data: {System.Collections.ListDictionaryInternal}
>> HelpLink: null
>> HResult: -2147024885
>> InnerException: null
>> Message: "An attempt was made to load a program with an incorrect
>> format. (Exception from HRESULT: 0x8007000B)"
>> Source: "CSSword"
>> StackTrace: " at
>> Sword.NativeMethods.org_crosswire_sword_SWMgr_new()\r\n at
>> Sword.Manager..ctor() in
>> n:\\development\\swordCsharp\\csharp\\Manager.cs:line 28"
>> TargetSite: {IntPtr org_crosswire_sword_SWMgr_new()}
>>
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
Peter Von Kaehne
2014-09-11 09:14:26 UTC
Permalink
> Gesendet: Donnerstag, 11. September 2014 um 03:27 Uhr
> Von: "Jon Behrens" <jbb at crimsonthread.com>

> ../../../icu-sword/lib
> (should be ...icu... icu-sword is wrong unless you rename the icu
> directory)

Do not know much about the rest and what I am saying here might be wrong too - but there are two versions of ICU floating about - official ICU which we near always compile against and then a CrossWire maintained icu-sword fork which has various features which might or might not be useful to various people. I think mostly improved transliterators, which are submitted to ICU but might not yet be in official builds. Chris Little is the man who knows most about that. He is doing his PhD thesis at this moment, so might need a direct approach before he answers.

So, whatever the exact role of CrossWire's ICU is, if there is a reference to icu-sword then it refers to our own version which should be a compile time option, but not a necessity.
Yours

Peter
Jon Behrens
2014-09-11 14:22:15 UTC
Permalink
Thank you Peter.
For my purposes at this time which is to get Sword so I can write C# in
either Linux
or Windows, the official version of ICU should be fine and changing the
linker is easy
enough.
Regards
Jon
On 9/11/2014 3:14 AM, Peter Von Kaehne wrote:
>> Gesendet: Donnerstag, 11. September 2014 um 03:27 Uhr
>> Von: "Jon Behrens" <jbb at crimsonthread.com>
>> ../../../icu-sword/lib
>> (should be ...icu... icu-sword is wrong unless you rename the icu
>> directory)
> Do not know much about the rest and what I am saying here might be wrong too - but there are two versions of ICU floating about - official ICU which we near always compile against and then a CrossWire maintained icu-sword fork which has various features which might or might not be useful to various people. I think mostly improved transliterators, which are submitted to ICU but might not yet be in official builds. Chris Little is the man who knows most about that. He is doing his PhD thesis at this moment, so might need a direct approach before he answers.
>
> So, whatever the exact role of CrossWire's ICU is, if there is a reference to icu-sword then it refers to our own version which should be a compile time option, but not a necessity.
> Yours
>
> Peter
>
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
Daniel Hughes
2014-09-25 09:40:13 UTC
Permalink
bump

On Tue, Sep 2, 2014 at 11:07 PM, Daniel Hughes <trampster at gmail.com> wrote:
> Attached is a patch which fixes one of the locale unit tests. This
> test was assuming that english 'en' was the always the first locale
> and this simply is not always the case. Meaning this test would pass
> sometimes on some boxes but not on others.
Loading...