Re: [Flora-development] [Xsb-development] XSB and Flora-2 wrappers for .NET and Python
Brought to you by:
kifer
From: <gon...@gm...> - 2007-01-17 16:20:49
|
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", HelloFromDotNe= t); > 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 like: > > 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 not > > 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 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 > > _______________________________________________ > > Xsb-development mailing list > > Xsb...@li... > > https://lists.sourceforge.net/lists/listinfo/xsb-development > > > |