From edi at agharta.de  Wed Feb  1 00:49:03 2006
From: edi at agharta.de (Edi Weitz)
Date: Wed, 01 Feb 2006 01:49:03 +0100
Subject: [rdnzl-devel] New release 0.9.0 / Experimental support for SBCL
Message-ID: <uoe1rewe8.fsf@agharta.de>

ChangeLog:

  Version 0.9.0
  2006-02-01
  Experimental support for SBCL/Win32

Download:

  <http://weitz.de/files/RDNZL.tar.gz>

Cheers,
Edi.



From edi at agharta.de  Wed Feb  1 12:09:22 2006
From: edi at agharta.de (Edi Weitz)
Date: Wed, 01 Feb 2006 13:09:22 +0100
Subject: [rdnzl-devel] New release 0.9.1
In-Reply-To: <uoe1rewe8.fsf@agharta.de> (Edi Weitz's message of "Wed, 01 Feb
	2006 01:49:03 +0100")
References: <uoe1rewe8.fsf@agharta.de>
Message-ID: <uoe1rb7rh.fsf@agharta.de>

ChangeLog:

  Version 0.9.1
  2006-02-01
  Added missing WIDE-CHAR support for SBCL/Win32

Download:

  <http://weitz.de/files/RDNZL.tar.gz>

Cheers,
Edi.


From jim at sokoloff.com  Wed Feb  8 19:31:10 2006
From: jim at sokoloff.com (Jim Sokoloff)
Date: Wed, 8 Feb 2006 14:31:10 -0500 (EST)
Subject: [rdnzl-devel] Problem with invoking static member
Message-ID: <Pine.LNX.4.62.0602081430200.5301@sequoia.oankali.net>

(Apologies if this posts twice; I outsmarted myself with
mailman, and I tried to cancel the first one that mailman
thought was posted by a non list member.)

Hi,

I'm having trouble invoking a static member on a class.

I've reduced the case to the following simple test case,
and I suspect I may be missing somewhat simple. (I'm
far from a Lisp wizard. Far...)


Basically, I'm trying to load a C# assembly, and be able
to call a static method on it. I can call instance methods
without issue, but make-type-from-name is not working the
way I expect it should, and therefore, calling static
methods fails.

Any help would be appreciated!

--Jim

Source code and sample interaction below:

Lisp interaction: (win32, using slime and clisp-2.38, but I doubt it makes any 
difference) Some output trimmed for legibility.

CL-USER> (load "/c/vp/devenv/lib/clisp/rdnzl-0.9.1/load.lisp")
CL-USER> (in-package :rdnzl)
RDNZL> (enable-rdnzl-syntax)
RDNZL> (setq lisp-sample-assembly (import-assembly
                         [System.Reflection.Assembly.LoadFrom 
"C:\\temp\\bin\\Debug\\LispSample1.dll"]))
RDNZL> (setq p (new (import-type "LispSample1.Parrot" lisp-sample-assembly) 
"Bob"))
#<CONTAINER LispSample1.Parrot #x2929E6A8>
RDNZL> (ffi-call-with-args %invoke-instance-member p "SayHello" '(42))

47
RDNZL> (resolve-type-name "LispSample1.Parrot")

"LispSample1.Parrot, LispSample1, Version=1.0.2230.24825, Culture=neutral, 
PublicKeyToken=null"

;; To me, it appears that that worked.

RDNZL> (make-type-from-name (resolve-type-name "LispSample1.Parrot"))

#<CONTAINER NULL #x2929E540>

RDNZL> ;;   ^^^^ This appears to be as close to the root of the problem as ;; I 
am able to get

RDNZL> (invoke p "SayHello" 17)

22
;; this worked (There is stdout output, but my slime discards it.)

RDNZL> (invoke p "StaticSayHello" "Bill" 17)

; Evaluation aborted
;; failed - .NET error (System.Exception): Instance method not found: 
LispSample1.Parrot::StaticSayHello(System.String,System.Int32)
;; Of course, it's not an instance method...

RDNZL> (invoke "LispSample1.Parrot" "StaticSayHello" "Bill" 17)
Trying to call function %INVOKE-STATIC-MEMBER with NULL object #<CONTAINER 
NULL #x292961E0>.


C# class is here, compiled into an assembly:
C:\temp\bin\Debug\LispSample1.dll
using System;

namespace LispSample1
{
 	public class Parrot
 	{
 		private string m_name;
 		public Parrot(string name)
 		{
 			m_name = name;
 		}
 		public int SayHello(int value)
 		{
 			Console.WriteLine("Hello {0}.", m_name);
 			return value + 5;
 		}
 		static public int StaticSayHello(string name, int value)
 		{
 			Console.WriteLine("Hello {0}.", name);
 			return value * 2;
 		}
 	}
}



From edi at agharta.de  Wed Feb  8 20:42:02 2006
From: edi at agharta.de (Edi Weitz)
Date: Wed, 08 Feb 2006 21:42:02 +0100
Subject: [rdnzl-devel] Problem with invoking static member
In-Reply-To: <Pine.LNX.4.62.0602081430200.5301@sequoia.oankali.net> (Jim
	Sokoloff's message of "Wed, 8 Feb 2006 14:31:10 -0500 (EST)")
References: <Pine.LNX.4.62.0602081430200.5301@sequoia.oankali.net>
Message-ID: <uek2dshut.fsf@agharta.de>

Hi!

On Wed, 8 Feb 2006 14:31:10 -0500 (EST), Jim Sokoloff <jim at sokoloff.com> wrote:

> I'm having trouble invoking a static member on a class.
>
> I've reduced the case to the following simple test case, and I
> suspect I may be missing somewhat simple. (I'm far from a Lisp
> wizard. Far...)
>
> Basically, I'm trying to load a C# assembly, and be able to call a
> static method on it. I can call instance methods without issue, but
> make-type-from-name is not working the way I expect it should, and
> therefore, calling static methods fails.

Your problem can be best described with this short C# program:

  using System;
  using System.Reflection;

  public class Test {
    public static void Main() {
      // insert correct path to LispSample1.dll here
      Assembly a = Assembly.LoadFrom("C:\\Documents and Settings\\edi\\Desktop\\LispSample1.dll");
      Type t1 = a.GetType("LispSample1.Parrot");
      String s = t1.FullName;
      Type t2 = Type.GetType(s);
      try {
        Console.WriteLine("Success: " + t2.Name);
      } catch (NullReferenceException) {
        Console.WriteLine("Failed");
      }
    }
  }

If I run this, I get "Failed" on the console.  This is because
Type.GetType can't create the type from the name although the name is
fully qualified.  This happens because you use Assembly.LoadFrom and
this is obviously unrelated to RDNZL.

I can't cite chapter and verse in the .NET documentation but I
immediately recognized the problem because I was bitten by it myself.

If you put your DLL into a folder where the system will find it and
then use it like AproposGui is used in the RDNZL examples, everything
should work fine.  At least it works for me, I just tested it with LW.

HTH,
Edi.


From jim at sokoloff.com  Thu Feb  9 19:20:59 2006
From: jim at sokoloff.com (Jim Sokoloff)
Date: Thu, 9 Feb 2006 14:20:59 -0500 (EST)
Subject: [rdnzl-devel] Problem with invoking static member
In-Reply-To: <uek2dshut.fsf@agharta.de>
References: <Pine.LNX.4.62.0602081430200.5301@sequoia.oankali.net>
	<uek2dshut.fsf@agharta.de>
Message-ID: <Pine.LNX.4.62.0602091402190.9699@sequoia.oankali.net>

It turns out that I don't have the freedom to
co-locate my .net assembly with clisp.exe
(because I have to have different versions of
the assembly loaded on a single machine in
different processes for dev, test, load-test,
and prod).


I'll propose the following patch (attached) to invoke:

Currently it takes an object (for an instance method)
or a type name (for a static method).

After this patch, object can also a cons of a loaded
assembly and a type name, and it will call a static
method on the type from that assembly.

So, in the previous transcript, the call which failed:
(invoke "LispSample1.Parrot" "StaticSayHello" "Bob" 15)

becomes:
(invoke (cons lisp-sample-assembly "LispSample1.Parrot")
         "StaticSayHello" "Bob" 15)

which now works.

Hopefully this patch (or a variant form) will be acceptable.

Thanks for RDNZL! :)
---Jim


diff -u c:\temp\rdNZL-0.9.1\container.lisp 
c:\vp\devenv\lib\clisp\rdNZL-0.9.1\container.lisp
--- c:\temp\rdNZL-0.9.1\container.lisp	2006-01-31 15:02:56.000000000 
-0500
+++ c:\vp\devenv\lib\clisp\rdNZL-0.9.1\container.lisp	2006-02-09 
13:59:03.984125000 -0500
@@ -163,6 +163,13 @@
     (ffi-call-with-foreign-string* %make-type-from-name
                                    name)))

+(defun make-type-from-assembly-and-name (assembly name)
+  "Returns the .NET type with the name NAME from a specific assembly."
+   (ffi-call-with-args %invoke-instance-member
+                       assembly
+                       "GetType"
+                       (list name)))
+
  (defun get-object-as-string (container)
    "Get a string representation of the object denoted by CONTAINER.
  Uses 'ToString' internally."
@@ -320,6 +327,13 @@
                                       (make-type-from-name 
(resolve-type-name object))
                                       method-name
                                       args))
+                ((and (consp object)
+                      (container-p (car object))
+                      (stringp (cdr object)))
+                 (ffi-call-with-args %invoke-static-member
+                                     (make-type-from-assembly-and-name 
(car object) (cdr object))
+                                     method-name
+                                     args))
                  (t (error "Don't know how to invoke ~A on ~S." 
method-name object)))))
      ;; if some of the arguments were pass-by-reference reset them to
      ;; their underlying types


From edi at agharta.de  Mon Feb 13 19:33:13 2006
From: edi at agharta.de (Edi Weitz)
Date: Mon, 13 Feb 2006 20:33:13 +0100
Subject: [rdnzl-devel] New version 0.9.2 (Was: Problem with invoking static
	member)
In-Reply-To: <Pine.LNX.4.62.0602091402190.9699@sequoia.oankali.net> (Jim
	Sokoloff's message of "Thu, 9 Feb 2006 14:20:59 -0500 (EST)")
References: <Pine.LNX.4.62.0602081430200.5301@sequoia.oankali.net>
	<uek2dshut.fsf@agharta.de>
	<Pine.LNX.4.62.0602091402190.9699@sequoia.oankali.net>
Message-ID: <ur767m4ue.fsf_-_@agharta.de>

On Thu, 9 Feb 2006 14:20:59 -0500 (EST), Jim Sokoloff <jim at sokoloff.com> wrote:

> I'll propose the following patch (attached) to invoke:
>
> Currently it takes an object (for an instance method) or a type name
> (for a static method).
>
> After this patch, object can also a cons of a loaded assembly and a
> type name, and it will call a static method on the type from that
> assembly.

Thanks Jim, I've uploaded a new version (0.9.2) which incorporates
your patch.

Cheers,
Edi.


From s8ctxw402 at sneakemail.com  Fri Feb 17 05:49:16 2006
From: s8ctxw402 at sneakemail.com (Dan Muller)
Date: Fri, 17 Feb 2006 00:49:16 -0500
Subject: [rdnzl-devel] (no subject)
Message-ID: <22468-24587@sneakemail.com>

My first post to this list...

I started playing around with RDNZL, Direct3D 9.0, and the evaluation 
version of LispWorks for Windows about a week ago. Very nice! But I've 
run into an interesting problem.

Direct3D uses single floats throughout its interface, but in LispWorks 
for Windows, all floating point types are equivalent to double-float. 
So I've got this rather difficult situation, where RDNZL can never find 
a method if it takes a single float argument! Even if it could find it, 
a down-conversion from double to single float would be needed, which 
probably shouldn't occur implicitly.

I tried explicitly calling System.Convert.ToSingle, but by the time I 
can get my hands on the return value, it has been turned back into a 
double! I haven't been able to figure out a way around this without 
modifying RDNZL, or writing some sort of .NET function that returned a 
boxed single. But I'm not sure that the latter wouldn't be unboxed, or 
that it would give the correct type for the method lookup in RDNZL.

Any ideas?

-- 
Dan Muller


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From edi at agharta.de  Fri Feb 17 13:15:32 2006
From: edi at agharta.de (Edi Weitz)
Date: Fri, 17 Feb 2006 14:15:32 +0100
Subject: [rdnzl-devel] New version 0.9.3 (Was: (no subject))
In-Reply-To: <22468-24587@sneakemail.com> (Dan Muller's message of "Fri, 17
	Feb 2006 00:49:16 -0500")
References: <22468-24587@sneakemail.com>
Message-ID: <uslqi86tn.fsf@agharta.de>

On Fri, 17 Feb 2006 00:49:16 -0500, "Dan Muller" <s8ctxw402 at sneakemail.com> wrote:

> My first post to this list...

Hi... :)

> Direct3D uses single floats throughout its interface, but in
> LispWorks for Windows, all floating point types are equivalent to
> double-float. So I've got this rather difficult situation, where
> RDNZL can never find a method if it takes a single float argument!
> Even if it could find it, a down-conversion from double to single
> float would be needed, which probably shouldn't occur implicitly.
>
> I tried explicitly calling System.Convert.ToSingle, but by the time
> I can get my hands on the return value, it has been turned back into
> a double! I haven't been able to figure out a way around this
> without modifying RDNZL, or writing some sort of .NET function that
> returned a boxed single. But I'm not sure that the latter wouldn't
> be unboxed, or that it would give the correct type for the method
> lookup in RDNZL.

Yeah, tough call.  I don't see an easy general solution but for the
moment I've uploaded version 0.9.3 which offers the following
workaround:

  <http://weitz.de/rdnzl/#*coerce-double-floats-to-single*>

You should be able to (temporarily) rebind this variable to T for
single float arguments.  Well, UNLESS your .NET method's signature
contains both System.Single /and/ System.Double.

Let me know if that helps or if you have a better idea.

Cheers,
Edi.


From edi at agharta.de  Fri Feb 17 19:12:17 2006
From: edi at agharta.de (Edi Weitz)
Date: Fri, 17 Feb 2006 20:12:17 +0100
Subject: [rdnzl-devel] Re: New version 0.9.3
In-Reply-To: <29921-75407@sneakemail.com> (Dan Muller's message of "Fri, 17
	Feb 2006 13:21:14 -0500")
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com>
Message-ID: <u64nd94vi.fsf@agharta.de>

[Re-routing to the mailing list.]

On Fri, 17 Feb 2006 13:21:14 -0500, "Dan Muller" <s8ctxw402 at sneakemail.com> wrote:

> I'll try it out tonight and let you know how it works.

Good.

> I'm thinking that a cleaner solution might be an optional
> target-type argument to BOX, although that requires RDNZL to pick
> the conversion needed.

Yeah, maybe.  The advantage of my workaround is that you don't have to
call BOX explicitely because RDNZL calls it as needed.  So, you should
be able to just INVOKE a method with arguments like 3.4d2 and RDNZL
will convert it to a System.Single automatically.

> Or a perhaps even more generally, a way to call a method of an
> object or type with some arguments, but get the return value without
> conversion, boxed if necessary. With that, I could have called
> System.Convert.ToSingle and gotten a boxed Single back. Perhaps
> calling it INVOKE-RETURNING-CONTAINER.

But you'd have to do this for PROPERTY and FIELD as well.  And you'd
lose the advantages of the special reader syntax.  A bit messy.

> Thanks a lot for writing RDNZL. This is ever so much easier than
> fooling around with FFIs to call C or C++ APIs.
>
> As I'm going along, I'm writing a few small utilities to help with
> various common tasks. When I've had more experience with this, I'll
> offer them for inclusion in RDNZL.

That would be nice.

Cheers,
Edi.


From s8ctxw402 at sneakemail.com  Fri Feb 17 22:04:40 2006
From: s8ctxw402 at sneakemail.com (Dan Muller)
Date: Fri, 17 Feb 2006 17:04:40 -0500
Subject: [rdnzl-devel] Re: New version 0.9.3
In-Reply-To: <u64nd94vi.fsf@agharta.de>
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
Message-ID: <22203-77278@sneakemail.com>

Edi Weitz opined:
>
> On Fri, 17 Feb 2006 13:21:14 -0500, "Dan Muller" 
> <s8ctxw402 at sneakemail.com> wrote:
>
>> I'm thinking that a cleaner solution might be an optional
>> target-type argument to BOX, although that requires RDNZL to pick
>> the conversion needed.
>
> Yeah, maybe.  The advantage of my workaround is that you don't have to
> call BOX explicitely because RDNZL calls it as needed.  So, you should
> be able to just INVOKE a method with arguments like 3.4d2 and RDNZL
> will convert it to a System.Single automatically.

True. Although as you pointed out, you can run into trouble when both 
single and double floats are wanted by the same method. I think that 
this would work in general, because .NET would implicitly up-convert a 
single to a double again; but at that point some precision would be 
lost unnecessarily. One can also imagine situations where a method 
taking a single is overloaded by a method taking a double, and the 
latter becomes completely inaccessible -- just the opposite of what 
you'd want to have happen if your Lisp uses only doubles!

Also, I wonder about similar problems that could arise involving other types.

>> Or perhaps even more generally, a way to call a method of an
>> object or type with some arguments, but get the return value without
>> conversion, boxed if necessary. With that, I could have called
>> System.Convert.ToSingle and gotten a boxed Single back. Perhaps
>> calling it INVOKE-RETURNING-CONTAINER.
>
> But you'd have to do this for PROPERTY and FIELD as well.  And you'd
> lose the advantages of the special reader syntax.  A bit messy.

Again, true, but I'm thinking here mainly of low-level mechanisms with 
which one could address any similar problems, with precise control. How 
to make them convenient requires some more thought.

-- 
Dan

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From edi at agharta.de  Fri Feb 17 22:25:16 2006
From: edi at agharta.de (Edi Weitz)
Date: Fri, 17 Feb 2006 23:25:16 +0100
Subject: [rdnzl-devel] Re: New version 0.9.3
In-Reply-To: <22203-77278@sneakemail.com> (Dan Muller's message of "Fri, 17
	Feb 2006 17:04:40 -0500")
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com>
Message-ID: <umzgp62sz.fsf@agharta.de>

On Fri, 17 Feb 2006 17:04:40 -0500, "Dan Muller" <s8ctxw402 at sneakemail.com> wrote:

> Although as you pointed out, you can run into trouble when both
> single and double floats are wanted by the same method.

Once could do something like this (although it's not pretty)

  (defun single (float)
    (let ((*coerce-double-floats-to-single* t))
      (box float)))

  (invoke object method-name float1 (single float2))

where the first argument is supposed to be a System.Double and the
second one a System.Single.


From s8ctxw402 at sneakemail.com  Sat Feb 18 02:14:02 2006
From: s8ctxw402 at sneakemail.com (Dan Muller)
Date: Fri, 17 Feb 2006 21:14:02 -0500
Subject: [rdnzl-devel] Re: New version 0.9.3
In-Reply-To: <umzgp62sz.fsf@agharta.de>
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com> <umzgp62sz.fsf@agharta.de>
Message-ID: <3502-90854@sneakemail.com>

Quoth Edi Weitz:
[Hide Quoted Text]
> One could do something like this (although it's not pretty)
>
>  (defun single (float)
>    (let ((*coerce-double-floats-to-single* t))
>      (box float)))
>
>  (invoke object method-name float1 (single float2))
>
> where the first argument is supposed to be a System.Double and the
> second one a System.Single.
>

Ooh, good point! This will be handy for experimenting with different
ways of arranging this.

I verified that your change works by passing a float where before I was
passing an integer. (The method wants a single, but .NET was doing the
method lookup and implicit int-to-single conversion fine, and I
happened to just need an integer value there.) But the other function
that was giving me fits, Mesh.Cylinder, is blowing up for some other
reason. At least it's getting called now -- progress! I'm pausing to
download the latest DX9 SDK, since mine was rather old. Best to fight
with fresh bugs rather than old ones, I always say...

-- 
Dan

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From edi at agharta.de  Sat Feb 18 08:46:00 2006
From: edi at agharta.de (Edi Weitz)
Date: Sat, 18 Feb 2006 09:46:00 +0100
Subject: [rdnzl-devel] Re: New version 0.9.3
In-Reply-To: <3502-90854@sneakemail.com> (Dan Muller's message of "Fri, 17
	Feb 2006 21:14:02 -0500")
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com> <umzgp62sz.fsf@agharta.de>
	<3502-90854@sneakemail.com>
Message-ID: <uoe15jbqv.fsf@agharta.de>

On Fri, 17 Feb 2006 21:14:02 -0500, "Dan Muller" <s8ctxw402 at sneakemail.com> wrote:

> But the other function that was giving me fits, Mesh.Cylinder, is
> blowing up for some other reason. At least it's getting called now
> -- progress!

Just to be sure: Are you using a version of LispWorks which can deal
with foreign callbacks?  This /could/ be the reason for strange things
happening even if you yourself don't use a callback.

See recent discussions on this mailing list and here:

  <http://weitz.de/lw-callbacks/>

Cheers,
Edi.


From s8ctxw402 at sneakemail.com  Sat Feb 18 15:48:48 2006
From: s8ctxw402 at sneakemail.com (Dan Muller)
Date: Sat, 18 Feb 2006 10:48:48 -0500
Subject: [rdnzl-devel] Re: New version 0.9.3
In-Reply-To: <uoe15jbqv.fsf@agharta.de>
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com> <umzgp62sz.fsf@agharta.de>
	<3502-90854@sneakemail.com> <uoe15jbqv.fsf@agharta.de>
Message-ID: <19234-07610@sneakemail.com>

Edi Weitz edi-at-agharta.de |RDNZL-devel/via Sneakemail| wrote:

> On Fri, 17 Feb 2006 21:14:02 -0500, "Dan Muller" 
> <s8ctxw402 at sneakemail.com> wrote:
>
>> But the other function that was giving me fits, Mesh.Cylinder, is
>> blowing up for some other reason. At least it's getting called now
>> -- progress!
>
> Just to be sure: Are you using a version of LispWorks which can deal
> with foreign callbacks?  This /could/ be the reason for strange things
> happening even if you yourself don't use a callback.
>
> See recent discussions on this mailing list and here:
>
>  <http://weitz.de/lw-callbacks/>
>

Thanks, but I don't think I'm running into this -- yet. I'll keep it in mind.

I was mistaken when I said that the float coercion is working. After 
struggling with Mesh.Cylinder to no avail, I wrote a very small test 
assembly in C#:

using System;
using System.Collections.Generic;
using System.Text;
using System.Windows.Forms;

namespace ClassLibrary1
{
    public class Class1
    {
        public Class1()
        {
        }
        public static void Yop()
        {
            MessageBox.Show("I am here! I am here!");
        }
        public static void ShowSingle(Single f)
        {
            MessageBox.Show(f.ToString());
        }
        public static void ShowDouble(Double f)
        {
            MessageBox.Show(f.ToString());
        }
    }
}

(I'm using VS 2005, thus .NET 2.0. Not that it should make much difference.)

Yop is used as a sanity check, and it works. I can successfully call 
ShowDouble with *c-d-f-t-s* nil. I can call both ShowDouble and 
ShowSingle with *c-d-f-t-s* t, but *both* show an incorrect result.

I haven't fetched the source for the RDNZL DLL yet, but I think that's 
my next step.

BTW, do you know any way (in Lispworks!) of forcing an assebmly to 
unload, so I don't have to restart the Lisp image whenever an assembly 
is changed?

-- 
Dan

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From s8ctxw402 at sneakemail.com  Sat Feb 18 17:07:34 2006
From: s8ctxw402 at sneakemail.com (Dan Muller)
Date: Sat, 18 Feb 2006 12:07:34 -0500
Subject: [rdnzl-devel] Re: New version 0.9.3
In-Reply-To: <19234-07610@sneakemail.com>
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com> <umzgp62sz.fsf@agharta.de>
	<3502-90854@sneakemail.com> <uoe15jbqv.fsf@agharta.de>
	<19234-07610@sneakemail.com>
Message-ID: <11800-80793@sneakemail.com>

Replying to myself with more information...

Dan Muller s8ctxw402-at-sneakemail.com |RDNZL-devel/via Sneakemail| wrote:
> Edi Weitz edi-at-agharta.de |RDNZL-devel/via Sneakemail| wrote:
>
> I was mistaken when I said that the float coercion is working. After 
> struggling with Mesh.Cylinder to no avail, I wrote a very small test 
> assembly in C#:
>
> [code elided]
>
> (I'm using VS 2005, thus .NET 2.0. Not that it should make much difference.)

Hrrrm. Since you're using Managed C++, I'm not able to compile the 
RDNZL DLL. The solution converts up to VS8 OK. But, as you probably 
know, Managed C++ was replaced by C++/CLR. The conversion adds the 
necessary compiler option to support the old syntax, but the 
multi-threaded run-time library setting is incompatible with it 
(Configuration Properties/C++/Code Generation/Runtime library). Oh 
well. Just providing this as an FYI.

> Yop is used as a sanity check, and it works. I can successfully call 
> ShowDouble with *c-d-f-t-s* nil. I can call both ShowDouble and 
> ShowSingle with *c-d-f-t-s* t, but *both* show an incorrect result.

Delving deeper, I find that with *c-d-f-t-s* t, [ToString (box 5.5)] 
return "0", and [ToString (box 5.4)] returns something ugly that isn't 
5.4. In BOX*, you call MakeDotNetContainerFromFloat, but what you 
actually end up passing it is a double. This is where a down-conversion 
needs to happen. Poking around in the LW FLI documentation, I 
eventually figured out a simple change that fixes this.

In port-lw.lisp, FFI-MAP-TYPE, change :float to :lisp-float. This 
causes any Lisp float type (only double on Windows!) to be converted to 
a single float in FLI calls. So this is how we get LispWorks to do the 
implicit down-conversion for us when calling foreign functions that 
take singles.

Another good test is (box (unbox 5.4)). This didn't work before, and 
now it does.

This doesn't fix the overall problem yet, though. This test, using the 
assembly I gave in the previous email, still gives bad results:

(eval-when (:compile-toplevel :load-toplevel)
  (asdf:operate 'asdf:load-op :rdnzl))
(use-package :rdnzl)

;; This approach doesn't work
;(import-types "ClassLibrary1")

; Do this instead?
(import-type "ClassLibrary1.Class1" (load-assembly "ClassLibrary1"))

(use-namespace "ClassLibrary1")
(enable-rdnzl-syntax)
(defun rtest ()
  [Yop "Class1"]
  [ShowDouble "Class1" 1.0]             ; correct
  [ShowDouble "Class1" 7.267]           ; correct
  (let ((*coerce-double-floats-to-single* t))
    (declare (special *coerce-double-floats-to-single*))
    [ShowDouble "Class1" 1.0]           ; shows incorrectly
    [ShowDouble "Class1" 7.267]         ; shows incorrectly
    [ShowSingle "Class1" 1.0]           ; shows incorrectly
    [ShowSingle "Class1" 7.267]))       ; shows incorrectly

So I'm still working on it. Probably has to with the way that return 
values are handled...

-- 
Dan

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From s8ctxw402 at sneakemail.com  Sat Feb 18 17:16:44 2006
From: s8ctxw402 at sneakemail.com (Dan Muller)
Date: Sat, 18 Feb 2006 12:16:44 -0500
Subject: [rdnzl-devel] Re: New version 0.9.3
In-Reply-To: <11800-80793@sneakemail.com>
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com> <umzgp62sz.fsf@agharta.de>
	<3502-90854@sneakemail.com> <uoe15jbqv.fsf@agharta.de>
	<19234-07610@sneakemail.com> <11800-80793@sneakemail.com>
Message-ID: <18685-66476@sneakemail.com>

Dan Muller s8ctxw402-at-sneakemail.com |RDNZL-devel/via Sneakemail| wrote:
> Replying to myself with more information...

And again, to retract something. Sorry for the noise...

> In port-lw.lisp, FFI-MAP-TYPE, change :float to :lisp-float. This 
> causes any Lisp float type (only double on Windows!) to be converted 
> to a single float in FLI calls. So this is how we get LispWorks to do 
> the implicit down-conversion for us when calling foreign functions 
> that take singles.

This didn't fix anything, I made an error in testing. I'll shut up now 
until all my test cases pass...

-- 
Dan

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From edi at agharta.de  Sat Feb 18 22:17:18 2006
From: edi at agharta.de (Edi Weitz)
Date: Sat, 18 Feb 2006 23:17:18 +0100
Subject: [rdnzl-devel] New version 0.9.4
In-Reply-To: <11800-80793@sneakemail.com> (Dan Muller's message of "Sat, 18
	Feb 2006 12:07:34 -0500")
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com> <umzgp62sz.fsf@agharta.de>
	<3502-90854@sneakemail.com> <uoe15jbqv.fsf@agharta.de>
	<19234-07610@sneakemail.com> <11800-80793@sneakemail.com>
Message-ID: <uek20fh1t.fsf_-_@agharta.de>

On Sat, 18 Feb 2006 12:07:34 -0500, "Dan Muller" <s8ctxw402 at sneakemail.com> wrote:

> In port-lw.lisp, FFI-MAP-TYPE, change :float to :lisp-float.

Yep, thanks, that (and adding :LANGUAGE :ANSI-C) did the trick!  I've
uploaded 0.9.4 which should work now.

Could you please test?  I'm a bit in a hurry because we're moving to a
new flat on Wednesday... )

Thanks for your help,
Edi.


From edi at agharta.de  Sat Feb 18 22:18:27 2006
From: edi at agharta.de (Edi Weitz)
Date: Sat, 18 Feb 2006 23:18:27 +0100
Subject: [rdnzl-devel] Re: New version 0.9.3
In-Reply-To: <19234-07610@sneakemail.com> (Dan Muller's message of "Sat, 18
	Feb 2006 10:48:48 -0500")
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com> <umzgp62sz.fsf@agharta.de>
	<3502-90854@sneakemail.com> <uoe15jbqv.fsf@agharta.de>
	<19234-07610@sneakemail.com>
Message-ID: <uaccofgzw.fsf@agharta.de>

On Sat, 18 Feb 2006 10:48:48 -0500, "Dan Muller" <s8ctxw402 at sneakemail.com> wrote:

> BTW, do you know any way (in Lispworks!) of forcing an assebmly to
> unload, so I don't have to restart the Lisp image whenever an
> assembly is changed?

No, sorry, but this sounds like a .NET question and not like a
LW-specific question, doesn't it?


From edi at agharta.de  Sat Feb 18 22:22:32 2006
From: edi at agharta.de (Edi Weitz)
Date: Sat, 18 Feb 2006 23:22:32 +0100
Subject: [rdnzl-devel] "C++/CLR" (Was: New version 0.9.3)
In-Reply-To: <11800-80793@sneakemail.com> (Dan Muller's message of "Sat, 18
	Feb 2006 12:07:34 -0500")
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com> <umzgp62sz.fsf@agharta.de>
	<3502-90854@sneakemail.com> <uoe15jbqv.fsf@agharta.de>
	<19234-07610@sneakemail.com> <11800-80793@sneakemail.com>
Message-ID: <u64ncfgt3.fsf_-_@agharta.de>

On Sat, 18 Feb 2006 12:07:34 -0500, "Dan Muller" <s8ctxw402 at sneakemail.com> wrote:

> Hrrrm. Since you're using Managed C++, I'm not able to compile the
> RDNZL DLL. The solution converts up to VS8 OK. But, as you probably
> know, Managed C++ was replaced by C++/CLR. The conversion adds the
> necessary compiler option to support the old syntax, but the
> multi-threaded run-time library setting is incompatible with it
> (Configuration Properties/C++/Code Generation/Runtime library). Oh
> well. Just providing this as an FYI.

Eeek!  Does this mean I can throw away RDNZL if I upgrade to the new
Visual Studio?  Actually, I have the CDs/DVDs already lying around
here but didn't find the time to install it yet.

I'd be VERY happy if someone knowledgeable enough with Managed C++ and
C++/CLR could enlighten me...

> ;; This approach doesn't work
> ;(import-types "ClassLibrary1")

   (import-types "ClassLibrary1" "Class1")

works for me if the DLL is in the LispWorks folder.

>     (declare (special *coerce-double-floats-to-single*))

That's not necessary.  The variable is globally special.

Cheers,
Edi.


From s8ctxw402 at sneakemail.com  Sat Feb 18 23:13:31 2006
From: s8ctxw402 at sneakemail.com (Dan Muller)
Date: Sat, 18 Feb 2006 18:13:31 -0500
Subject: [rdnzl-devel] Re: New version 0.9.3
In-Reply-To: <uaccofgzw.fsf@agharta.de>
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com> <umzgp62sz.fsf@agharta.de>
	<3502-90854@sneakemail.com> <uoe15jbqv.fsf@agharta.de>
	<19234-07610@sneakemail.com> <uaccofgzw.fsf@agharta.de>
Message-ID: <11777-86794@sneakemail.com>

Edi Weitz edi-at-agharta.de |RDNZL-devel/via Sneakemail| wrote:

> On Sat, 18 Feb 2006 10:48:48 -0500, "Dan Muller" 
> <s8ctxw402 at sneakemail.com> wrote:
>
>> BTW, do you know any way (in Lispworks!) of forcing an assebmly to
>> unload, so I don't have to restart the Lisp image whenever an
>> assembly is changed?
>
> No, sorry, but this sounds like a .NET question and not like a
> LW-specific question, doesn't it?

I don't really know -- could involve all of RDNZL, .NET, and the Lisp 
implementation. Just thought you might know of a technique offhand, for 
some Lisp implementations, since you're sure to have run into this 
while working on RDNZL. <shrug>

-- 
Dan

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From s8ctxw402 at sneakemail.com  Sat Feb 18 23:20:21 2006
From: s8ctxw402 at sneakemail.com (Dan Muller)
Date: Sat, 18 Feb 2006 18:20:21 -0500
Subject: [rdnzl-devel] Re: "C++/CLR" (Was: New version 0.9.3)
In-Reply-To: <u64ncfgt3.fsf_-_@agharta.de>
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com> <umzgp62sz.fsf@agharta.de>
	<3502-90854@sneakemail.com> <uoe15jbqv.fsf@agharta.de>
	<19234-07610@sneakemail.com> <11800-80793@sneakemail.com>
	<u64ncfgt3.fsf_-_@agharta.de>
Message-ID: <15284-77778@sneakemail.com>

Edi Weitz edi-at-agharta.de |RDNZL-devel/via Sneakemail| wrote:

> On Sat, 18 Feb 2006 12:07:34 -0500, "Dan Muller" 
> <s8ctxw402 at sneakemail.com> wrote:
>
>> Hrrrm. Since you're using Managed C++, I'm not able to compile the
>> RDNZL DLL. The solution converts up to VS8 OK. But, as you probably
>> know, Managed C++ was replaced by C++/CLR. The conversion adds the
>> necessary compiler option to support the old syntax, but the
>> multi-threaded run-time library setting is incompatible with it
>> (Configuration Properties/C++/Code Generation/Runtime library). Oh
>> well. Just providing this as an FYI.
>
> Eeek!  Does this mean I can throw away RDNZL if I upgrade to the new
> Visual Studio?  Actually, I have the CDs/DVDs already lying around
> here but didn't find the time to install it yet.
>
> I'd be VERY happy if someone knowledgeable enough with Managed C++ and
> C++/CLR could enlighten me...
>
>> ;; This approach doesn't work
>> ;(import-types "ClassLibrary1")
>
>   (import-types "ClassLibrary1" "Class1")
>
> works for me if the DLL is in the LispWorks folder.
>
>>     (declare (special *coerce-double-floats-to-single*))
>
> That's not necessary.  The variable is globally special.
>
> Cheers,
> Edi.
>
>
>



-- 
Dan

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From s8ctxw402 at sneakemail.com  Sat Feb 18 23:33:48 2006
From: s8ctxw402 at sneakemail.com (Dan Muller)
Date: Sat, 18 Feb 2006 18:33:48 -0500
Subject: [rdnzl-devel] Re: New version 0.9.4
In-Reply-To: <uek20fh1t.fsf_-_@agharta.de>
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com> <umzgp62sz.fsf@agharta.de>
	<3502-90854@sneakemail.com> <uoe15jbqv.fsf@agharta.de>
	<19234-07610@sneakemail.com> <11800-80793@sneakemail.com>
	<uek20fh1t.fsf_-_@agharta.de>
Message-ID: <19374-25907@sneakemail.com>

Edi Weitz edi-at-agharta.de |RDNZL-devel/via Sneakemail| wrote:

> On Sat, 18 Feb 2006 12:07:34 -0500, "Dan Muller" 
> <s8ctxw402 at sneakemail.com> wrote:
>
>> In port-lw.lisp, FFI-MAP-TYPE, change :float to :lisp-float.
>
> Yep, thanks, that (and adding :LANGUAGE :ANSI-C) did the trick!  I've
> uploaded 0.9.4 which should work now.
>
> Could you please test?  I'm a bit in a hurry because we're moving to a
> new flat on Wednesday... )

Yes, this passes my small test. Interestingly, the rounding effect is visible.

With *c-d-f-t-s* set to NIL:
[ShowDouble "Class1" 7.267] -> displays 7.267

With *c-d-f-t-s* set to T:
[ShowDouble "Class1" 7.267] -> displays 7.26700019836426
[ShowSingle "Class1" 7.267] -> displays 7.267

> Thanks for your help,
> Edi.

And thank you for yours!

Good luck with the move. :)

-- 
Dan Muller

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From edi at agharta.de  Sat Feb 18 23:48:18 2006
From: edi at agharta.de (Edi Weitz)
Date: Sun, 19 Feb 2006 00:48:18 +0100
Subject: [rdnzl-devel] Re: "C++/CLR"
In-Reply-To: <15284-77778@sneakemail.com> (Dan Muller's message of "Sat, 18
	Feb 2006 18:20:21 -0500")
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com> <umzgp62sz.fsf@agharta.de>
	<3502-90854@sneakemail.com> <uoe15jbqv.fsf@agharta.de>
	<19234-07610@sneakemail.com> <11800-80793@sneakemail.com>
	<u64ncfgt3.fsf_-_@agharta.de> <15284-77778@sneakemail.com>
Message-ID: <u1wy0fcu5.fsf@agharta.de>

On Sat, 18 Feb 2006 18:20:21 -0500, "Dan Muller" <s8ctxw402 at sneakemail.com> wrote:

???


From s8ctxw402 at sneakemail.com  Sun Feb 19 01:24:21 2006
From: s8ctxw402 at sneakemail.com (Dan Muller)
Date: Sat, 18 Feb 2006 20:24:21 -0500
Subject: [rdnzl-devel] Re: "C++/CLR" (Was: New version 0.9.3)
In-Reply-To: <u64ncfgt3.fsf_-_@agharta.de>
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com> <umzgp62sz.fsf@agharta.de>
	<3502-90854@sneakemail.com> <uoe15jbqv.fsf@agharta.de>
	<19234-07610@sneakemail.com> <11800-80793@sneakemail.com>
	<u64ncfgt3.fsf_-_@agharta.de>
Message-ID: <14111-97095@sneakemail.com>

Let me try this again ... this stupid web-mail application ate the 
contents of my previous reply to this. :(

Edi Weitz edi-at-agharta.de |RDNZL-devel/via Sneakemail| wrote:
> On Sat, 18 Feb 2006 12:07:34 -0500, "Dan Muller" 
> <s8ctxw402 at sneakemail.com> wrote:
>
>> Hrrrm. Since you're using Managed C++, I'm not able to compile the
>> RDNZL DLL. The solution converts up to VS8 OK. But, as you probably
>> know, Managed C++ was replaced by C++/CLR. The conversion adds the
>> necessary compiler option to support the old syntax, but the
>> multi-threaded run-time library setting is incompatible with it
>> (Configuration Properties/C++/Code Generation/Runtime library). Oh
>> well. Just providing this as an FYI.
>
> Eeek!  Does this mean I can throw away RDNZL if I upgrade to the new
> Visual Studio?  Actually, I have the CDs/DVDs already lying around
> here but didn't find the time to install it yet.
>
> I'd be VERY happy if someone knowledgeable enough with Managed C++ and
> C++/CLR could enlighten me...

Good news, sort of. I found out that you can use the /MD 
(Multi-Threaded DLL) switch instead of /MT (Multi-Threaded). At least, 
it compiles. The downside is that the file MSVCR80.DLL must be 
available at run-time.

A correction on my terminology: It's C++/CLI, not C++/CLR.

I've looked fairly extensively at C++/CLI while studying the 
possibility of porting some C++ code at my day job. Syntactically, it's 
a vast improvement over Managed C++. If you ever decide you'd like to 
port RDNZL to it, let me know. Schedule permitting, I'd be glad to 
help, or even just do it for you -- it's not a very large project.

>> ;; This approach doesn't work
>> ;(import-types "ClassLibrary1")
>
>   (import-types "ClassLibrary1" "Class1")
>
> works for me if the DLL is in the LispWorks folder.
>

I haven't had time to figure this out yet. I did have the DLL there, 
otherwise it wouldn't have loaded the other way.

>>     (declare (special *coerce-double-floats-to-single*))
>
> That's not necessary.  The variable is globally special.

Thanks!

-- 
Dan

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From edi at agharta.de  Sun Feb 19 09:39:03 2006
From: edi at agharta.de (Edi Weitz)
Date: Sun, 19 Feb 2006 10:39:03 +0100
Subject: [rdnzl-devel] C++/CLI (Was: "C++/CLR")
In-Reply-To: <14111-97095@sneakemail.com> (Dan Muller's message of "Sat, 18
	Feb 2006 20:24:21 -0500")
References: <22468-24587@sneakemail.com> <uslqi86tn.fsf@agharta.de>
	<29921-75407@sneakemail.com> <u64nd94vi.fsf@agharta.de>
	<22203-77278@sneakemail.com> <umzgp62sz.fsf@agharta.de>
	<3502-90854@sneakemail.com> <uoe15jbqv.fsf@agharta.de>
	<19234-07610@sneakemail.com> <11800-80793@sneakemail.com>
	<u64ncfgt3.fsf_-_@agharta.de> <14111-97095@sneakemail.com>
Message-ID: <uy807y9fs.fsf_-_@agharta.de>

On Sat, 18 Feb 2006 20:24:21 -0500, "Dan Muller" <s8ctxw402 at sneakemail.com> wrote:

> Good news, sort of. I found out that you can use the /MD
> (Multi-Threaded DLL) switch instead of /MT (Multi-Threaded). At
> least, it compiles. The downside is that the file MSVCR80.DLL must
> be available at run-time.

I googled a bit and found this here:

  Affected User Scenario:
  Users will need to replace /MT with /MD for their code targeting
  .NET

  Description:
  There is no support in the CRT for statically linking managed
  applications.

  Customer Workaround:
  Customer needs to change /MT to /MD and link dynamically to the CRT.

  Rationale:
  There is no support in the C Runtime Library to statically link to a
  managed application.  All managed applications have to be
  dynamically linked; thus the reason to make the two compiler options
  conflict.

  <http://www.codeproject.com/managedcpp/WhidbeyBreakingChanges.asp>

> I've looked fairly extensively at C++/CLI while studying the
> possibility of porting some C++ code at my day job. Syntactically,
> it's a vast improvement over Managed C++. If you ever decide you'd
> like to port RDNZL to it, let me know. Schedule permitting, I'd be
> glad to help, or even just do it for you -- it's not a very large
> project.

Thanks for offering!  I might try it myself, but most likely not
before April.  Feel free to work on it... :)

>>> ;; This approach doesn't work
>>> ;(import-types "ClassLibrary1")
>>
>>   (import-types "ClassLibrary1" "Class1")
>>
>> works for me if the DLL is in the LispWorks folder.
>
> I haven't had time to figure this out yet. I did have the DLL there,
> otherwise it wouldn't have loaded the other way.

Hmm, so you didn't provide any types to import.  If you didn't get an
error message, it means the assembly was loaded but with zero types
imported.

Cheers,
Edi.


From s8ctxw402 at sneakemail.com  Fri Feb 24 02:32:25 2006
From: s8ctxw402 at sneakemail.com (Dan Muller)
Date: Thu, 23 Feb 2006 21:32:25 -0500
Subject: [rdnzl-devel] Type lookup problems, and solutions.
Message-ID: <16468-90626@sneakemail.com>

(Gruess Gott, Edi, hoffentlich war der Umzug nicht allzu anstrengend!)

Remember that problem I was having importing some types? I'm not sure 
why, but on my system, System.Type.GetTypes is more picky than RDNZL 
seems to expect:

;;;
;;; To demonstrate these failing tests, start with a clean Lisp image,
;;; then load RDNZL, then load this file.  Assemblies can't be
;;; unloaded except by unloading their containing application domain,
;;; and you can't unload the default application domain.
;;;
;;; It's possible that the tests are sensitive to the assemblies
;;; available on my machine, but I can't find an indication in
;;; Microsoft's documentation of why that might be the case.
;;;
(in-package :cl-user)
(use-package :rdnzl)
(import-assembly "System.Windows.Forms")

;; This fails, because the system doesn't find the type.
;; Comment it out and try reloading to move on to the next test.
(new "System.Windows.Forms.Form")

;; This fails, too. Same problem.
;; Comment it out and try reloading to move on to the next test.
(import-type "System.Windows.Forms.Form")

;; I also tried direct calls to System.Type.GetType with various
;; abbreviations of the fully qualified type name, leaving off
;; trailing pieces of the full assembly name. None of these succeeded.

;; This succeeds.
(import-type "System.Windows.Forms.Form"
             (load-assembly "System.Windows.Forms"))

;; This succeeds, because RDNZL now remembers what assembly it found
;; Form in.
(let ((form
       ;; This fails, because the system doesn't find the type.
       (new "System.Windows.Forms.Form")))
  (invoke form "Dispose"))

<end of test code>

I spent a lot of time poking around in RDNZL and the .NET framework, 
and reading documentation. The documentation is for 2.0, FWIW, but I 
was careful to look only at classes and methods that were available in 
1.1. What follows is a rather lengthy discussion of some possible 
improvements/fixes I've come up with. This goes rather beyond fixing 
the immediate problem, but please give it some consideration.

- Have IMPORT-TYPE always retrieve and cache the assembly-qualified
name of the type.

Downside: This will include the exact version.  This means that in
a delivered application involving a saved image, there is no way to
use an updated version of a used assembly. (Haven't tested for
this, though.) Might be an acceptable short-term fix, though.

- Have IMPORT-ASSEMBLY supply the assembly to IMPORT-TYPE. Good
idea, since it's currently inconsistent about this vis-a-vis
IMPORT-TYPES. But it doesn't address the problem described above.

- In MAKE-TYPE-FROM-NAME, do the following. If the name is
assembly-qualified (contains an unquoted paren), then use
System.Type.GetType() as before. Otherwise, call
System.Reflection.Assembly.GetType() on each assembly returned by
System.AppDomain.CurrentDomain.GetAssemblies(). The search should
be exhaustive in order to detect ambiguities, which should be
signaled as errors. In IMPORT-TYPE, don't accept
assembly-qualified names, and cache the actual type object
instead of the fully-qualified name. During shutdown, discard
these type object references.  During initialization, do the
lookups again. (Changes to assemblies that introduce ambiguities
will cause an error during initialization.)

Downsides: Names given to RDNZL for resolution must not be
assembly-qualified. (Or, perhaps better, detect these and don't
cache them.) It is not possible for the system to deal
predictably with like-named types in multiple assemblies. All
loaded assemblies would be searched, even if they were not loaded
via RDNZL. The latter problem might be a liability for advanced
uses, e.g. involving dynamic assemblies that are being built by
the application.

I tried creating a C# console application that used two assemblies
with conflicting type names. You get an error only if you actually
reference the conflicting type name. The error documentation
explains how C# allows this problem to be worked around, using a
compiler switch that assigns a prefix to all namespaces in a given
assembly:

http://msdn2.microsoft.com/en-us/library/64wh5743.aspx

AFAIK, implementing a similar solution requires work on the
compiler's part. I have not noticed any direct support for this
aliasing in the .NET framework. So a similar solution in RDNZL
would require tracking assemblies. However, this might be
desirable in order to address the other problem mentioned above.

If RDNZL would track loaded assemblies, only those assemblies
would be searched for type name matches. If we associate an
optional alias with an assembly (e.g. via an optional argument to
LOAD-ASSEMBLY), then that assembly would only be searched if the
type name includes the prefix, and only after removing the
prefix.

As a further enhancement, I'd like to actually get rid of the
need for importing entirely. It doesn't seem unreasonable to
search for a type regardless of whether it has been imported or
not, provided that it is then always cached in *TYPE-HASH*. This
way *TYPE-HASH* builds up information about all types referenced
via RDNZL. Users can still make calls to primitives like
System.Type.GetType() if they ever want to bypass such
activity. This is also true for LOAD-ASSEMBLY, if it starts
tracking assemblies. Of course, the aliasing wouldn't work if you
bypass RDNZL.

I have prototyped some of the low-level pieces needed for these
changes, entirely in Lisp using RDNZL. I didn't want to put more
work into it unless I'm sure there's interest in including it in
RDNZL. (Or at least, I'll do the work differently if there
isn't.) I'm particularly uncertain about issues related to saving
and loading Lisp images, something I've never tried out, although
I think I understand the basic concerns there.

-- 
Dan Muller

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From s8ctxw402 at sneakemail.com  Sat Feb 25 00:34:03 2006
From: s8ctxw402 at sneakemail.com (Dan Muller)
Date: Fri, 24 Feb 2006 19:34:03 -0500
Subject: [rdnzl-devel] Type lookup problems, and solutions.
In-Reply-To: <16468-90626@sneakemail.com>
References: <16468-90626@sneakemail.com>
Message-ID: <11600-64036@sneakemail.com>

Dan Muller s8ctxw402-at-sneakemail.com |RDNZL-devel/via Sneakemail| wrote:
> Remember that problem I was having importing some types? I'm not sure 
> why, but on my system, System.Type.GetTypes is more picky than RDNZL 
> seems to expect:
> [lots more stuff elided]

On further reflection, I've decided to work on this as a separate 
package layered on top of RDNZL, so that I can try implementing some 
other features that I'd like, related to the management of package 
use-lists and the timing of type resolution, which would be very 
intrusive to incorporate into RDNZL.

> - Have IMPORT-TYPE always retrieve and cache the assembly-qualified
> name of the type.
>
> Downside: This will include the exact version.  This means that in
> a delivered application involving a saved image, there is no way to
> use an updated version of a used assembly. (Haven't tested for
> this, though.) Might be an acceptable short-term fix, though.
>
> - Have IMPORT-ASSEMBLY supply the assembly to IMPORT-TYPE. Good
> idea, since it's currently inconsistent about this vis-a-vis
> IMPORT-TYPES. But it doesn't address the problem described above.

I suggest using one of these techniques for now in RDNZL. In any case, 
I'll be able to work around my type resolution problem in the package 
I'll build, which will have its own type object cache.

I have a local copy of RDNZL with some of the changes that I described, 
which I'm going to set aside for now.

-- 
Dan

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.