C Sharp AI

[Petah]

I have recently been very interested in creating an AI using C#. I downloaded the CSAI source but there is one problem. When I try and run the compiled AI i get an error about and incorrect Global AI version. Does any one know how to fix this? What would be really great if a complete Visual Studio solution was included with the CSAI source.

[Agon]

The .Net interface for ais is old and broken with newer versions.
btw: I'm interested, too.

[DJ]

I'd love to see this working again as well, if I remember rightly there were some problems with it but I believe the work on the Java interface may have got passed those.

Best bet would be to message hugh perkins and see if you can rekindle his interest. A few emails from some interested parties might get him back on board

[jcnossen]

IIRC the problems where mostly:

- for the linux part, mono is very undocumented and therefore really hard to interface with
- for the windows part, Hugh Perkins used a C++/CLI layer to communicate between C++ spring and C# AI. This is the best way here, because to start the CLR from native code requires using undocumented MS API's, which is pure horror

- the fact that you need 2 different interfaces for the 2 platforms would make maintaining a C# binding very time consuming. You need multiple people for it probably.

So your best bet is to wait for someone to write a GCC-CIL backend, so we can compile spring to CIL
Which is why java would probably be a better choice

[Agon]

Hm, google could help:

http://www.mono-project.com/Summer2005#GCC_CIL
https://forgesvn1.novell.com/svn/gcc-cil/trunk/
http://gcc-cil.blogspot.com/

And what about this?
http://www.mono-project.com/Interop_wit ... _Libraries

[jcnossen]

That is nothing new. gcc-cil has been inactive for some time AFAIK.
The mono interop docs might have improved a bit since the last time I checked, but the problems are still the same (no one to create and maintain the mono binding)

[Agon]

Mono is available for windows, too.
This means only one interface is needed.
Or do you I miss something?

Edit:
Found another GCC-CLI:
http://gcc.gnu.org/projects/cli.html

[jcnossen]

Mono is available for windows, too.
This means only one interface is needed.
Or do you I miss something?

True.
I'm not saying things are impossible, I've just reiterated the problems that Hugh Perkins encountered.

- Either interface would need maintainers
- The one that is written only works on windows
- The potential mono multiplatform one is hard to write, but if you have the time/motivation to do so, please go ahead.

I think you gcc-cli link is about converting CLI code to native using gcc. gcc-cil that i mentioned would produce cil from C++ using gcc, so spring compiled to CIL would run on both MS .NET and mono.

Either way porting spring code to fully run on CLR would probably be harder than writing a mono binding. I only mentioned it because it is in theory a solution, but not a realistic one

[Agon]

I would help with Linux support and some coding if someone could help.
But active help only available at the beginning of summer (End of exams).

Info: I have no clue what to do in detail. I need to learn before I can do something ....

[imbaczek]

Learning by doing is the best way here; there aren't many people who know the ins and outs of Spring's AI API, and those who know have limited time, if any.

[hughperkins]

Yes, so, everything jcnossen says is true.

Also, prior to starting the C# AI, mono seemed to be Microsoft-independent, and somewhere near the end of writing it, there was the whole Novell-Microsoft thing; and mono no longer has much street-cred (as far as I know?).

Java is slower than C#, but speed is not that important; at least, a 50% speed reduction is not going to be a killer as far as AI being good or not.

Java doesnt make JNI (Java Native Invocation) terribly easy however. It's a C interface AFAIK, which raises similar issues to interfacing with Mono: Mono presents a C API to whatever-you-want-to-connect-it-to; whereas Spring is written in C++, with classes, objects and so on.

Also, right at the start of C# AI, it was only a step to go from Spring to C#, which went like this:

Spring (written in Visual C++ )
-> .dll , written in managed C++, calling into
-> C# class library, in .Net C#

The .dll was separate from Spring to avoid having to modify Spring itself, and because Spring is built using unmanaged C++; or something like that.

Spring is now compiled using gcc, mingw on Windows. mingw cannot directly call into a managed C++ .dll across a C++ interface, because their...well, it just cant.

So, we need one more dll in the mix which converts from Spring's C++ interface to a Microsoft C++ interface. Starting to sound complicated right? And that's why no-one ever maintains it

If I was going to do it again, I would probably use Java since Java is now opensource (I think?), and mono is looking distinctly less open-sourced, as far as patents and all that go.

But I'm not going to do it again, so I'll have a whirl at getting the C# interfaces working again.

[hughperkins]

Kindof vaguely got the thing building again. Doesnt quite run again yet; havent looked into why yet. Probably something simple like a file in the wrong directory or something, but would need someone to add debugging code into the various dlls to find where the issue is (something like the "WriteLine" function in AbicProxy.cpp ). Or direct debugging if you know how to get that working?

The chain of things is:
- spring / tasclient load up ...
- csaiabic.dll, which downgrades the interface to a C interface, then calls...
- csailoader.dll, which is in managed c++, upgrades back to a C++ interface, using abicwrapper headers, then loads...
- csai.dll, which is a standard c# assembly

There's also a project called "CSAIInterfaces.dll" which contains a C# version of the various spring AI interfaces. It is used to generate most of the leg work involved in the various dlls above, so that we dont have to write them entirely by hand...

[Agon]

Yes, so, everything jcnossen says is true.

Also, prior to starting the C# AI, mono seemed to be Microsoft-independent, and somewhere near the end of writing it, there was the whole Novell-Microsoft thing; and mono no longer has much street-cred (as far as I know?).

I don´t really understand what you want to say.
Mono is open source (MIT).
Mono will reach in the next time 2.0 and full support of .Net 2.0 methods. And some parts of .Net 3.0. As I know full support of c# 3.0.
Mono popularity increases because of more libraries, wrappers and applications.

Java is slower than C#, but speed is not that important; at least, a 50% speed reduction is not going to be a killer as far as AI being good or not.

This is basically right. There was a small test for c#, Java and C.
C# was mostly faster than java.
And one time it was faster than C.
http://jeffreystedfast.blogspot.com/200 ... mfile.html

If I was going to do it again, I would probably use Java since Java is now opensource (I think?), and mono is looking distinctly less open-sourced, as far as patents and all that go.

But I'm not going to do it again, so I'll have a whirl at getting the C# interfaces working again.

As I wrote above mono is totally open source because of MIT license (I think more free and open source is not possible.)

Java has different licenses for jdk and se or how are they named.
From special license to GPLv2. Basically I have no idea about java.

Personally I would be happy about a mono binding for the spring ai.
But I don´t know if I will write a AI for spring in C# if a wrapper is available. Maybe with a team.

[hughperkins]

Hmmm, well...

I don´t really understand what you want to say.
Mono is open source (MIT).
Mono will reach in the next time 2.0 and full support of .Net 2.0 methods. And some parts of .Net 3.0. As I know full support of c# 3.0.
Mono popularity increases because of more libraries, wrappers and applications.

I guess there are two issues:
* patent burden / issues for mono; which is/are unclear afaik?
* what the community thinks about mono; again, I'm somewhat out of the loop on this

This is basically right. There was a small test for c#, Java and C.
C# was mostly faster than java.
And one time it was faster than C.

Yes, in general, and particularly for things like AIs, choice of algorithm is going to have a much greater affect on speed than choice of language (at least for Java vs C# vs C++).

Personally I would be happy about a mono binding for the spring ai.

Ok... so, I did actually make some mono bindings. They were sufficiently advanced that the C# AI would run with them. You can find them in the "AI\Global\CSAI\MonoLoader" directory.

Again, they do follow this concept of breaking things down to a c interface and building back up again. It may we worth just going down the swig path as for JAI; I havent had time to check how JAI is progressing.

Basically, to load CSAI with Mono, one would swap out the "CSAILoader" component for the "MonoLoader" component/dll. It has worked before; it should run ok right now.

[hughperkins]

I kindof almost got the monoloader building again: pretty much it compiles, just need to figure out the linking bit at the end.

You'll need to get the latest svn build, and set up your environment to get spring to build, then download mono and nant.

[hughperkins]

To be honest, if we're actually going to focus on Mono, which does seem to make sense, we could actually merge this hideous chain of dlls together:

- either one loader dll, which calls the ai dll, or
- just create one single ai dll, yay!

The single dll would basically contain:
- everything from ABICompatibilityLayer
- AbicWrappers is *not* required (I think)
- the stuff from MonoLoader
- The AI itself, ie CSAI2 or similar

We'd probably still want to create the CSAIInterfaces.dll assembly. This is a straight .net/mono class-library; with a bunch of AI interface files; which is used to generate the other xxx_generated files. It's a pretty small assembly.

[jcnossen]

Nice to see you back hugh!

The single dll would basically contain:
- everything from ABICompatibilityLayer
- AbicWrappers is *not* required (I think)
- the stuff from MonoLoader
- The AI itself, ie CSAI2 or similar

Then you lose the ability to use the same .NET CIL binary on different platforms right? Can you merge native dll's with CIL dll's, or do i not understand what you mean?

I guess maintainability is the most important thing for spring AI though: If JAI is working out and is easier to maintain, then Java is probably the best choice for new AI projects.

[Agon]

Hmmm, well...

I don´t really understand what you want to say.
Mono is open source (MIT).
Mono will reach in the next time 2.0 and full support of .Net 2.0 methods. And some parts of .Net 3.0. As I know full support of c# 3.0.
Mono popularity increases because of more libraries, wrappers and applications.

I guess there are two issues:
* patent burden / issues for mono; which is/are unclear afaik?
* what the community thinks about mono; again, I'm somewhat out of the loop on this

As far as I know Novell has a agreement with MS about patents.
Besides every developer who wants to publish code to mono was never allowed to look at MS .Net code.
I don´t know what the Linux community currently thinks about it.
I think a few like mono, a few hate mono and a few are sceptic about Novell and Microsofts part. But after some time they will mostly accept it. Gnome/GTK uses mono in a few apps (Banshee, Gimp, ...), nowadays

Easiest would be for the end-ai-developer (mono) to have a dll which has everything which is needed to implement a ai like a interface, some methods to get informations and to give commands.
And a loader which loads ether a c++, java, "mono/.Net" .dll or .jar file. Maybe it could be written so that it is easier to implement new languages.

Ah yeah, what about something like D-Bus? To make it easier to communicate with new language ais?

[hughperkins]

Nice to see you back hugh!

The single dll would basically contain:
- everything from ABICompatibilityLayer
- AbicWrappers is *not* required (I think)
- the stuff from MonoLoader
- The AI itself, ie CSAI2 or similar

Then you lose the ability to use the same .NET CIL binary on different platforms right? Can you merge native dll's with CIL dll's, or do i not understand what you mean?

Yeah, actually, now that I've thought about it a little (the last post was after thinking for about 30 seconds , it'd have to be two dlls anyway, since the mono assembly would presumably be a separate dll from the gcc loader dll?

What we can do though is lose the whole gcc<->msvc bit, which chops out a dll from the chain, so we have:
- loader dll (gcc)
- ai assembly (mono)

I guess maintainability is the most important thing for spring AI though.

Seems to be the most important thing generally really, not just spring, everywhere...

[AF]

The reason the C interface nver lifted off to begin with was because it lacked the support fo any fo the major working AIs of the time.

In order to support the interface it would have required thousands of minor code edits that would take a hefty amount of time and resources out of AI developers that were already under heavy loads from existing and older projects, and in the end there was not a great enough incentive to adopt this workload when everything currently worked as is.

With regards to Java and JNI, may I point people to the JNA project. The problem of C++ interfaces will not be fixable using more C++ interfaces, it doesn't just affect JNI it also affects C++ AIs due to binary ABI compatibility between compilers.

So I propose a better solution.

What we do is that we stop extending the C++ interface using C++ functions. Jelmer and everyone agreed upon a basic method fo extending the AI interface yet people have now been flouting those designs for the last year, and ignoring the HandleEvent() and GetValue() type methods in favour fo brand new dedicated methods.

What I am proposing is that we move functionality into these methods out of the dedicated methods one by one until the vast majority of the AI interface uses them. But we do it in such a way that the existing API remains, only instead of it being a direct API to spring, it will act as a wrapper. This way it would be far easier to take the C++ API out and put in a C API and it would not affect the C++ AIs because their C++ API is just a set of wrapper classes for a C API.

It also means anyone working with the AI interface would have a single interface to maintain and work with, and anyone could use any compiler they want, or even rebuild the AI interface wrapper so it worked better.

This should also help rejuvenate the AI community by making C++ AIs far more viable, and it should allow for Java and C# AI loaders to work without being broken every few weeks.