- rdnzl-devel@common-lisp.net - mailman3.common-lisp.net

[rdnzl-devel] New patch for a COPY-CONTAINER operator
by Iver Odin Kvello 18 May '07

18 May '07

Here are a couple of patches to implement the COPY-CONTAINER operator I missed. I hope I got things right with the formatting and the diffs and so forth. I did test the thing for the getting-the-lease-object problem, and it worked as it should, in that (cast (invoke (cast (copy-container w) "System.MarshalByRefObject") "GetLifetimeService") "System.Runtime.Remoting.Lifetime.ILease") .. will return the correct lease for the remote object w. A potential issue: I had to rename the copier-function of the CONTAINER-struct to be able to use the COPY-CONTAINER name. I couldn't think of a good alternative, and the struct-copy function wasn't actually in use, so I figured maybe it was ok. Regards, Iver Odin Kvello iok(a)selvaag.no

2 2

[rdnzl-devel] A patch for CAST to enable casting to types from assemblies loaded using LoadFrom
by Iver Odin Kvello 11 May '07

11 May '07

Hello, Here is another set of patches that fixes a small issue with CAST: the current CAST uses GetType with an assembly-qualified type-name only, and therefore will not work with types in an assembly loaded using System.Reflection.Assembly.LoadFrom and similar. The patch makes CAST use a Type-object directly if passed one instead of a type-name, like NEW already did. That is, one can do (setf assembly (invoke "System.Reflection.Assembly" "LoadFrom" url)) (setf mytype (invoke assembly "GetType" sometypename)) (cast someobject mytype) This should be the minimal neccessary support for these kinds of assemblies in case they are needed for an application. Regards, Iver Odin Kvello iok(a)selvaag.no

1 0

[rdnzl-devel] A possible bugfix for a possible bug in IMPORT-ASSEMBLY
by Iver Odin Kvello 27 Apr '07

27 Apr '07

I think there is a bug in IMPORT-ASSEMBLY, in that the documentation says "Imports all public types of the assembly ASSEMBLY \(a string or a CONTAINER). If ASSEMBLY is a string then the assembly is first loaded with LOAD-ASSEMBLY. Returns ASSEMBLY as a CONTAINER." However, it doesn't seem to actually import the public types when the ASSEMBLY argument isn't passed to IMPORT-TYPE. Passing the assembly fixes this. Iver Odin Kvello iok(a)selvaag.no

2 1

[rdnzl-devel] A question about CAST
by Iver Odin Kvello 27 Apr '07

27 Apr '07

Hello, We've recently started using RDNZL for integration between an internal application written in ACL 7.0 and a CAD system using a .Net-based extension-layer in the latter; using .Net Remoting for communicating between the two systems. We've found that RDNZL works robustly, reliably and is very easy to use. Thank you very much for creating it. I have a question with regards to the action of the CAST operator: Currently, when CAST'ing from one .Net class to another, the type of the container is destructively updated; and there doesn't seem to be any way of copying a container so that a reference to the same object but with another type can be created. That is, I'd like to do something like (cast foo "SomeType")) (setq bar (copy-container foo)) (cast bar "SomeOtherType")) without the last operating also setting the type of FOO to SomeOtherType [1] Is there some idiom that would work like this that I've missed? If not, I guess the functionality would have to be added at the C++ level, which I haven't really looked at yet. Any pointers would be appreciated. Iver Odin Kvello iok(a)selvaag.no [1] The actual situation that came up was this: We have a remote object - actually a transparent proxy - of an interface-type WALL, and we need to get a reference to its lease. However, to to this we must cast the object to MarshalByRefObject, and if we use CAST to get this, it is impossible to CAST back to the original interface type. We did find a workaround: using System.Runtime.Remoting.RemotingServices.GetRealProxy, another copy of the transparent proxy is easily obtained, and that can be cast to a MBRO instead. But a copy/cast-operator would have been nicer.

2 5

[rdnzl-devel] Re: Rdnzl Excel/Access
by Edi Weitz 12 Jan '07

12 Jan '07

[Please use the mailing list.] Hi, On Thu, 11 Jan 2007 14:14:22 -0800 (PST), Jacobite <jacobite1607(a)yahoo.com> wrote: > I noticed your posted on Corman Lisp forum and I had a question that > you might be able to answer. I have been trying to learn .net > programming in Corman Lisp, playing with your example of reading > from an Microsoft Excel file. I happened to notice that Excel stayed > open in the background. My questions are: > > 1- How do you close Excel cleanly? > 2- Also how do I write to the excel file and save it? > 3- How do you switch which Sheet tabs you are on? > 4- Can you point me in the direction of example program, such as the > Excel example on your webpage, that shows reading/writing to > Microsoft Access. > > By the way your examples have worked beautifully. Any help you could > provide would be greatly appreciated. I'm afraid I can't be very helpful here as all your question are more related to Office automation than to RDNZL itself. I just adapted an existing C# example (see link from RDNZL website) and that's what you should probably do as well if you're looking for more. There's most likely /lots/ of C# code out there which does what you want. If you've found something and if you have problems adapting the C# code to Lisp, ask on the mailing list and I'll try to help. Cheers, Edi.

1 0

[rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking
by Edi Weitz 27 Dec '06

27 Dec '06

[Please use the mailing list.] On Mon, 25 Dec 2006 13:17:28 -0800, "Richard Fateman" <fateman(a)cs.berkeley.edu> wrote: > We're using Allegro CL, and microsoft's ink routines, which > ultimately return to us "strokes" which we can decompose as arrays > of points, each containing an X and a Y. > > This decomposition, as we have written it, crosses the lisp - .net > boundary too often. Presumably with the right magic, we can just > access the arrays once. Suggestions? (I'd rather do this > extraction in Lisp....) > > ;;; Here's our way convert a stroke to a list of (x . y) points. > > (defun decode-one-stroke (as) ;a stroke > (let ((netarray > [GetPoints as]) > (list-of-points nil)) > (do-rdnzl-array (v netarray (nreverse list-of-points)) > (push (cons [%X v ][%Y v]) list-of-points) > ))) Have you tried "direct calls"? http://weitz.de/rdnzl/#direct This might yield a noticeable performance gain, but the main problem of crossing the boundary too often will still be there. Right now, there's no way to overcome this. You'd have to write low level C++ code using something like (the equivalent of) LispWork's WITH-DYNAMIC-LISP-ARRAY-POINTER on the Lisp side to get a .NET array into the Lisp world in one fell swoop. But this would solve only half of it, as you'd still have to get at the x/y coordinates of each point, crossing the boundary once again. ATM I have no idea how a general solution could look like. Cheers, Edi.

2 1

[rdnzl-devel] Re: small example for rdnzl using windows
by Edi Weitz 01 Dec '06

01 Dec '06

On Wed, 29 Nov 2006 22:11:02 -0800, "Richard Fateman" <fateman(a)cs.berkeley.edu> wrote: > An example that displays some of the possibilities for using rdnzl > for a drop-down menu cascade showing lisp trees is in > http://www.cs.berkeley.edu/~fateman/speech-lisp/outline.lisp > > Feel free to redistribute if it catches your fancy. You can put your > blurb in there if you want. > > Maybe you would want to polish it up some. I'm hardly a .NET > expert. The application, suitably elaborated would be used for > displaying huge mathematical expressions in some more understandable > way. Thanks Richard, I'm too busy right now to do anything with the code, but I've added a link to the example section of the RDNZL website. Cheers, Edi.

1 0

RE: [rdnzl-devel] RDNZL C++ used in non-LISP environment
by Goffioul Michael 27 Oct '06

27 Oct '06

> > The import lib file is created by VS200X when building the DLL. > > So, I don't need to include it, right? It depends on the target. You could think about providing RDNZL in a binary package, with the header and the import library file. Especially if you want it to be usable with other compilers like MinGW; then the user won't probably have VS200X installed. Michael.

1 0

RE: [rdnzl-devel] RDNZL C++ used in non-LISP environment
by Goffioul Michael 26 Oct '06

26 Oct '06

> > To ease my work, I created a header file and import > library, such that > > my octave module is linked with the RDNZL DLL. So I > wondered if these > > files could not be provided in some stand-alone RDNZL.DLL package, > > such that it could be used by anybody. The import library only > > publishes C function, so you can even think of providing such a > > library for MinGW compiler (although I didn't try). > > > > What do you think? > > Sounds good to me. Do I understand correctly that I'd just > have to add one or two files to the C++ source code as it is > now? Then you should just send them and I'll make a new > release. (And maybe you should provide some text which can > be added to the README file.) The header can be created by: grep -E '__declspec(dllexport)' *.h | sed -e 's/dllexport/dllimport/g' The import lib file is created by VS200X when building the DLL. Michael.

2 1

[rdnzl-devel] RDNZL C++ used in non-LISP environment
by Goffioul Michael 25 Oct '06

25 Oct '06

Hi all, Recently, I had the idea to try to bridge .NET with Octave (the Matlab clone). Instead of re-inventing the wheel, I wondered "why not try to re-use RDNZL DLL?". And it worked pretty well. Actually, RDNZL provides everything you need to bridge a C/C++ application with .NET, without having to handle the managed part yourself. It's not really bound to LISP. To ease my work, I created a header file and import library, such that my octave module is linked with the RDNZL DLL. So I wondered if these files could not be provided in some stand-alone RDNZL.DLL package, such that it could be used by anybody. The import library only publishes C function, so you can even think of providing such a library for MinGW compiler (although I didn't try). What do you think? Michael.

2 1