My familiarity with .NET in this regard is fairly limited, but I was wondering what would be required to expose modules written in Common Lisp on top of .NET to other .NET modules.
I'm afraid the answer might be some CLR Lisp implementation, of which there are few (if any) that are very mature that I know of.
Basically, I have a fairly involved (LispWorks) Common Lisp module that was originally the entry point for a number of applications, which itself made calls to .NET components. The requirement has come up that I expose some of it's features to a .NET application and I'd like to avoid reimplementing all of it in C#.
I'm not sure this is even an RDNZL question, but given that is my starting point I cannot help but wonder whether people have encountered the same issue given the nature of the problem RDNZL is solving.
What I know is that for example LispWorks can deliver Lisp DLLs which look like C DLLs (with the corresponding entry points) from the outside. Maybe there's a way to "wrap" such a "C DLL" so that it can be used from .NET?
Just a wild thought, Edi.
On Thu, Apr 22, 2010 at 5:54 PM, Joerthan Panest joerthan.panest@gmail.com wrote:
My familiarity with .NET in this regard is fairly limited, but I was wondering what would be required to expose modules written in Common Lisp on top of .NET to other .NET modules.
I'm afraid the answer might be some CLR Lisp implementation, of which there are few (if any) that are very mature that I know of.
Basically, I have a fairly involved (LispWorks) Common Lisp module that was originally the entry point for a number of applications, which itself made calls to .NET components. The requirement has come up that I expose some of it's features to a .NET application and I'd like to avoid reimplementing all of it in C#.
I'm not sure this is even an RDNZL question, but given that is my starting point I cannot help but wonder whether people have encountered the same issue given the nature of the problem RDNZL is solving.
rdnzl-devel mailing list rdnzl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-devel
Alternatively, it might be possible to (ab)use the delegate support in RDNZL to get what you need - simply define the delegate signatures you require in an interface class on the C# side, then use RDNZL to create an interface object and attach lisp closures (I do something like this to implement LISP callbacks for a somewhat misdesigned .NET library). It might even be possible to generate some sort of reverse RDNZL this way :-)
Alternatively, create some sort of RPC interface for your LISP code.
On Apr 22, 2010, at 19:58 , Edi Weitz wrote:
What I know is that for example LispWorks can deliver Lisp DLLs which look like C DLLs (with the corresponding entry points) from the outside. Maybe there's a way to "wrap" such a "C DLL" so that it can be used from .NET?
Just a wild thought, Edi.
On Thu, Apr 22, 2010 at 5:54 PM, Joerthan Panest joerthan.panest@gmail.com wrote:
My familiarity with .NET in this regard is fairly limited, but I was wondering what would be required to expose modules written in Common Lisp on top of .NET to other .NET modules.
I'm afraid the answer might be some CLR Lisp implementation, of which there are few (if any) that are very mature that I know of.
Basically, I have a fairly involved (LispWorks) Common Lisp module that was originally the entry point for a number of applications, which itself made calls to .NET components. The requirement has come up that I expose some of it's features to a .NET application and I'd like to avoid reimplementing all of it in C#.
I'm not sure this is even an RDNZL question, but given that is my starting point I cannot help but wonder whether people have encountered the same issue given the nature of the problem RDNZL is solving.
rdnzl-devel mailing list rdnzl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-devel
rdnzl-devel mailing list rdnzl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-devel
On Thu, Apr 22, 2010 at 3:18 PM, Raymond Wiker rwiker@gmail.com wrote:
Alternatively, it might be possible to (ab)use the delegate support in RDNZL to get what you need - simply define the delegate signatures you require in an interface class on the C# side, then use RDNZL to create an interface object and attach lisp closures (I do something like this to implement LISP callbacks for a somewhat misdesigned .NET library).
This seems like the sort of solution that would fit best. Do you have any examples of this, off hand? Is the library you mention Open Source or otherwise available for review, by any chance?
It might even be possible to generate some sort of reverse RDNZL this way :-)
It looks like I am on the path, but I definitely lack the understanding to tackle that.
Alternatively, create some sort of RPC interface for your LISP code.
Yes, this is one option I've looked at but I think it is less elegant than the above.
Thank you.
On Thu, Apr 22, 2010 at 4:46 PM, Joerthan Panest joerthan.panest@gmail.comwrote:
On Thu, Apr 22, 2010 at 3:18 PM, Raymond Wiker rwiker@gmail.com wrote:
Alternatively, it might be possible to (ab)use the delegate support in RDNZL to get what you need - simply define the delegate signatures you require in an interface class on the C# side, then use RDNZL to create an interface object and attach lisp closures (I do something like this to implement LISP callbacks for a somewhat misdesigned .NET library).
This seems like the sort of solution that would fit best. Do you have any examples of this, off hand? Is the library you mention Open Source or otherwise available for review, by any chance?
I see the key press event handler example in the RDNZL docs.
Thanks for the information.
I've been trying to figure out a way to make this sort of approach work.
On Thu, Apr 22, 2010 at 3:18 PM, Raymond Wiker rwiker@gmail.com wrote:
Alternatively, it might be possible to (ab)use the delegate support in RDNZL to get what you need - simply define the delegate signatures you require in an interface class on the C# side, then use RDNZL to create an interface object and attach lisp closures (I do something like this to implement LISP callbacks for a somewhat misdesigned .NET library).
Ok, I create a shared .NET DLL that defines the interface and all needed classes. I can deliver a "C DLL" with LispWorks that is able to instantiate the types and interface as well as register callbacks with these types that it has instantiated.
The fundamental issue that I cannot work around here is that there is no clear way to pass along the previously instantiated from the .NET application through to any functions exposed by the Lisp DLL.
On Apr 24, 2010, at 16:45, Joerthan Panest wrote:
I've been trying to figure out a way to make this sort of approach work.
On Thu, Apr 22, 2010 at 3:18 PM, Raymond Wiker rwiker@gmail.com wrote: Alternatively, it might be possible to (ab)use the delegate support in RDNZL to get what you need - simply define the delegate signatures you require in an interface class on the C# side, then use RDNZL to create an interface object and attach lisp closures (I do something like this to implement LISP callbacks for a somewhat misdesigned .NET library).
Ok, I create a shared .NET DLL that defines the interface and all needed classes. I can deliver a "C DLL" with LispWorks that is able to instantiate the types and interface as well as register callbacks with these types that it has instantiated.
The fundamental issue that I cannot work around here is that there is no clear way to pass along the previously instantiated from the .NET application through to any functions exposed by the Lisp DLL.
If I understand you correctly, it should(?) be as simple as defining a delegate on a class, and a setter for the delegate. You can then add a lisp delegate to an object known by (or created from) Lisp. The arguments to the delegate could then include arbitrary .NET objects.
This is not a general solution in the way that RDNZL works (in the opposite direction), but then again... the callback you define could have the semantics of #'apply, with the first argument being a string that names a function, and the second argument being a list of parameters (not needed if C# supports functions with a variable number of arguments).
On Sat, Apr 24, 2010 at 1:03 PM, Raymond Wiker rwiker@gmail.com wrote:
If I understand you correctly, it should(?) be as simple as defining a delegate on a class, and a setter for the delegate.
Yes.
You can then add a lisp delegate to an object known by (or created from) Lisp.
Created by Lisp is already solved via RDNZL. The problem is the "known by" part that assumes it was passed in to begin with. I'm reading up on marshaling between managed and unmanaged code, so hopefully I'll have something to share.
Yes, that makes sense to me. I wasn't very clear with my actual request. I can create presumably create such a wrapper, but there would be no way to pass .NET objects in, would there?
Thank you, Joerthan
On Thu, Apr 22, 2010 at 1:58 PM, Edi Weitz edi@agharta.de wrote:
What I know is that for example LispWorks can deliver Lisp DLLs which look like C DLLs (with the corresponding entry points) from the outside. Maybe there's a way to "wrap" such a "C DLL" so that it can be used from .NET?
Just a wild thought, Edi.
On Thu, Apr 22, 2010 at 5:54 PM, Joerthan Panest joerthan.panest@gmail.com wrote:
My familiarity with .NET in this regard is fairly limited, but I was wondering what would be required to expose modules written in Common Lisp
on
top of .NET to other .NET modules.
I'm afraid the answer might be some CLR Lisp implementation, of which
there
are few (if any) that are very mature that I know of.
Basically, I have a fairly involved (LispWorks) Common Lisp module that
was
originally the entry point for a number of applications, which itself
made
calls to .NET components. The requirement has come up that I expose some
of
it's features to a .NET application and I'd like to avoid reimplementing
all
of it in C#.
I'm not sure this is even an RDNZL question, but given that is my
starting
point I cannot help but wonder whether people have encountered the same issue given the nature of the problem RDNZL is solving.
rdnzl-devel mailing list rdnzl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-devel
rdnzl-devel mailing list rdnzl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-devel
Yes, that makes sense to me. I wasn't very clear with my actual request. I can create presumably create such a wrapper, but there would be no way to pass .NET objects in, would there?
FWIW, something I read mentioned the tools TLBIMP and TLBEXP for interop between .Net and COM.
pt
-
Edi Weitz -
Joerthan Panest -
Paul Tarvydas -
Raymond Wiker