Re: [Flora-development] [Xsb-development] XSB and Flora-2 wrappers for .NET and Python
Brought to you by:
kifer
Menu
▾
▴
Re: [Flora-development] [Xsb-development] XSB and Flora-2 wrappers for .NET and Python
|
From: <gon...@gm...> - 2007-01-18 09:05:10
|
Dear Markus, I'll be happy to coordinate my project with yours. In fact, since I'm already hosting a version control server and a project management page, I'll create an account so you can also commit code and edit wiki pages on the project. I'll be adding LGPL headers to my source code as well and we can then work out how to merge our examples and source. It seems like an excellent idea. Please send me an individual mail or other contact so we can set up details of your account like username and password. Regarding the problem I'm facing... I finally managed to track it down. I haven't yet tried it on VB.NET, but XSB output can be silenced if you pass it the command-line options "-n --quietload". However, on VC# it's a bit more tricky, but I think I figured it out. Apparently it has to do with loading the XSB dll and the unmanaged code debugger. It seems that there are different behaviours in the .NET debugger for managed vs. unmanaged code. In C++, since it's more easy to deal with unmanaged code, the debugger always has this option turned on. On C# it appears it's off by default. On Visual Studio 2005, you solve this by just going to the Project Settings -> Debug and checking "Enable unmanaged code debugger". However, on the VC# Express edition this option isn't available! I'm yet to understand exactly why this happens, since this option should be for stepping out through unmanaged code and not for when you just want to debug managed DLLs, but apparently it influences how XSB's dll is loaded... I'll post some messages around Microsoft's newsgroups to see if I can get to grips with some way to deal with this. For now, Visual Studio 2005 users will have no problem debugging it. Best regards, Gon=E7alo On 1/18/07, Markus Schatten <msc...@fo...> wrote: > Dear Gon=E7alo, > > I had a similar problem (Memory Access Violation error) when I tried to > run xsb_init from a windows application (VB.NET) without a console > window. After hours and hours of searching without any success I started = a > long try-fail approach. After playing with the code I figured out that > xsb_init tries to write some messages to standard output (console) and > .NET didn't allow that if there was no console present. After starting th= e > app from console all errors where gone. I don't know if this fixes your > problem but I hope it helps. > > I wanted to ask you if you were maybe interested in coordinating our two > projects to create a wrapper for XSB and Flora-2? I took a look at your > code, and since you took a different approach (I created a C# Class > Library which imports functions exported in xsb.dll) and I think your one > is more intuitive for .NET programmers I propose I change my examples in > VB.NET and C# to use your interface and add them to the wrapper. Maybe it > would be a good idea to create a more intuitive way of using Flora-2 from > .NET (not through flora_query/4 etc. but through an interface like the on= e > you created for XSB). So what do you say? > > Best regards > > -- > Markus Schatten, dipl. inf. > e-mail: mar...@fo... > http://www.tiaktiv.hr > > > On Wed, 17 Jan 2007, Gon=E7alo Lopes wrote: > > > Dear all, > > > > Now for the single issue with XSBDotNet so far. Apparently, when > > running a debug session of a XSBDotNet application in Visual Studio C# > > Express, there is a memory access violation when calling xsb_init. I > > don't know why this happens, but it is very specific, in that if you > > run the executable there is no problem, if running the Visual C++ > > Express debugger things also work fine. > > > > I don't understand why it would crash specifically with this debugger > > environment, but maybe it has something to do with the C# debugger > > changing specific parameters that influence some behaviour on the XSB > > side, causing it to crash (i.e. changing some stack sizes). > > > > I'm sorry for the technical blowout, but I can't seem to workaround > > this very specific issue. Otherwise, all XSBDotNet applications work > > fine on every environment. > > > > Best regards, > > > > Gon=E7alo > > > > > > On 1/17/07, Gon=E7alo Lopes <gon...@gm...> wrote: > >> Dear Markus, David et al, > >> > >> It's great to find growing support and interest on a .NET interface. > >> I've set up a management page for my current source code at > >> http://articaserv.ath.cx/XSBDotNet. The SVN code can be offloaded from > >> the repository using any SVN client at > >> svn://articaserv.ath.cx/XSBDotNet. I can also make a binary release > >> available to those who just want to try it out "out-of-the-box". I'll > >> definitely work on proper documentation and usually I try to use a > >> unit testing methodology. > >> > >> So far, all the tests I've made have been successful, but there are > >> bound to be issues, especially where the multithreaded engine is > >> concerned. I'll post one of these issues in the following e-mail. > >> Right now, I'll just post two small code snippets of what XSBDotNet > >> offers so far for the .NET programmer (in C#): > >> > >> static void Main(string[] args) > >> { > >> XSBPrologEngine engine =3D XSBPrologEngine.Instance; > >> engine.Command("consult(basics)."); > >> QueryHandle handle =3D engine.Query("member(X,[1,2,3])."); > >> foreach (PrologAnswer answer in handle) > >> { > >> PrologTerm groundedTerm =3D answer.QueryTerm; > >> System.Console.Out.WriteLine( > >> "Answer: {0}", > >> groundedTerm.GetFunctorArgument(1).GetIntValue() > >> ); > >> } > >> } > >> > >> As you can see, the PrologEngine instance is a singleton, since for > >> now you can only call xsb_init once. There is support for commands and > >> queries, supporting both strings and PrologTerms built from C#. The > >> result from a query is in fact an enumeration of all the possible > >> answers, containing both the terms from reg1 and reg2. At each step of > >> the foreach cycle, a backtrack is issued and a new answer, if any, is > >> produced. It is also possible to terminate the enumeration at any > >> given time by just closing the handle. > >> > >> Now a small example of defining a C# method to run as a XSB predicate: > >> > >> static bool HelloFromDotNet(PrologTerm[] arguments) > >> { > >> if (arguments.Length !=3D 0) > >> { > >> arguments[0].BindAtom("hello"); > >> return true; > >> } > >> else return false; > >> } > >> > >> static void Main(string[] args) > >> { > >> XSBPrologEngine engine =3D XSBPrologEngine.Instance; > >> engine.RegisterManagedPredicate("hellodotnet", HelloFromDo= tNet); > >> QueryHandle hello =3D engine.Query("managed(hellodotnet(X)= )."); > >> foreach (PrologAnswer answer in hello) > >> { > >> System.Console.Out.WriteLine( > >> "Echo: {0}", > >> answer.QueryTerm.GetFunctorArgument(1).GetAtomName= () > >> ); > >> } > >> } > >> > >> As you see, the only requirement for the C# method is that it returns > >> bool and receives an array of PrologTerm representing the arguments of > >> the goal. Then, it's only necessary to register the function with the > >> XSBPrologEngine, passing it the name of the Prolog predicate being > >> implemented by the function. > >> > >> engine.RegisterManagedPredicate("hellodotnet", HelloFromDotNet); > >> > >> After that, the method can be called from XSB by use of the managed/1 > >> predicate, which receives a goal to execute inside .NET framework: > >> > >> QueryHandle hello =3D engine.Query("managed(hellodotnet(X))."); > >> > >> It is of course admissible to "inline" the predicate with something li= ke: > >> > >> hellodotnet(X) :- managed(hellodotnet(X)). > >> > >> for greater declarativity (there are some other solutions to go around > >> this, but I aimed for implementation simplicity first). > >> > >> That's it for now. > >> > >> Best regards, > >> > >> Gon=E7alo > >> > >> > >> On 1/17/07, David Warren <wa...@cs...> wrote: > >>> Markus and Gon=E7alo (et al.), > >>> > >>> I really appreciate your willingness to contribute to the XSB effort. > >>> I have essentially no knowledge of .NET, so we'll have to depend on > >>> you two. And it's good that there are two of you with knowledge and > >>> interest to determine the best interface. > >>> > >>> One important thing to keep in mind is that XSB, and the environments > >>> in which it runs, are both evolving. So code that works today may no= t > >>> work tomorrow. The best solution is to make the code transparent and > >>> to incorporate tests of it somehow into the XSB testsuite. Then > >>> changes that affect your code can be caught early and they (or your > >>> code) can be fixed before problems accumulate. We will have to think > >>> about how to include your subsystem in the XSB system. We don't like > >>> to distribute broken code, which means we will need to find a way to > >>> ensure that it stays up-to-date. > >>> > >>> Of course, good documentation is also a requirement :-). > >>> > >>> Good luck and keep us posted on your progress, > >>> -David > >>> > >>> ---------------------------------------------------------------------= ---- > >>> Take Surveys. Earn Cash. Influence the Future of IT > >>> Join SourceForge.net's Techsay panel and you'll get the chance to sha= re your > >>> opinions on IT & business topics through brief surveys - and earn cas= h > >>> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CI= D=3DDEVDEV > >>> _______________________________________________ > >>> Xsb-development mailing list > >>> Xsb...@li... > >>> https://lists.sourceforge.net/lists/listinfo/xsb-development > >>> > >> > > > > -----------------------------------------------------------------------= -- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share= your > > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID= =3DDEVDEV > > _______________________________________________ > > Flora-development mailing list > > Flo...@li... > > https://lists.sourceforge.net/lists/listinfo/flora-development > > > |