From mikaelmills at gmail.com  Fri Feb  1 23:19:29 2008
From: mikaelmills at gmail.com (Michael Mills)
Date: Fri, 01 Feb 2008 18:19:29 -0500
Subject: [rdnzl-devel] Rdnzl Problem
Message-ID: <47A3A901.8000108@gmail.com>

Hello,
I'm having a problem with RDNZL using ECL. I'm using a send a (lisp) 
string to the simple .net gui through a callback. It most works, but the 
string gets mangled when it goes into .net.

The .net consumer looks like this:
EditBox_Results.Text = cpc(TextBox_Filename.Text);
where EditBox is a rich textbox, and cpc is a "public delegate 
System.String callback(string input);" which is set in the constructor.
The list invocation looks like this:
[Application.Run (new "CPC_interface" (new "callback" #'(lambda 
(filename) (pretty-print-cpc filename t)) ))]
where CPC_interface is my .net gui, and pretty-print-cpc is defined as:
(defun pretty-print-CPC (filename &optional (echo nil))
(handler-case
(let ( (result (calculate-page-coverage filename)) )
(format echo "Cyan: ~$ %~%Magenta: ~$ %~%Yellow: ~$ %~%Black: ~$ 
%~%Total Byte Count: ~a"
(* 100 (car result))
(* 100 (cadr result))
(* 100 (caddr result))
(* 100 (cadddr result))
(car (cddddr result)) ))
(file-error () "File Not Found") ))

for the test files I run it on, the result of pretty-print-cpc is:
Cyan: 37.50 %
Magenta: 37.50 %
Yellow: 37.50 %
Black: 12.50 %
Total Byte Count: 32

however the .net gui is displaying that as:
???????

As I mentioned before, I'm using ECL is my lisp. I'm compiling the .net 
part using Visual Studio 2005 C# targeting version 2 of the .net framework.
Any help that can be provide is appreciated.


From edi at agharta.de  Sat Feb  2 11:12:42 2008
From: edi at agharta.de (Edi Weitz)
Date: Sat, 02 Feb 2008 12:12:42 +0100
Subject: [rdnzl-devel] Rdnzl Problem
In-Reply-To: <47A3A901.8000108@gmail.com> (Michael Mills's message of "Fri,
	01 Feb 2008 18:19:29 -0500")
References: <47A3A901.8000108@gmail.com>
Message-ID: <utzkrr4r9.fsf@agharta.de>

On Fri, 01 Feb 2008 18:19:29 -0500, Michael Mills <mikaelmills at gmail.com> wrote:

> I'm having a problem with RDNZL using ECL. I'm using a send a (lisp)
> string to the simple .net gui through a callback. It most works, but
> the string gets mangled when it goes into .net.
>
> The .net consumer looks like this:
> EditBox_Results.Text = cpc(TextBox_Filename.Text);
> where EditBox is a rich textbox, and cpc is a "public delegate
> System.String callback(string input);" which is set in the
> constructor.
> The list invocation looks like this:
> [Application.Run (new "CPC_interface" (new "callback" #'(lambda
> (filename) (pretty-print-cpc filename t)) ))]
> where CPC_interface is my .net gui, and pretty-print-cpc is defined as:
> (defun pretty-print-CPC (filename &optional (echo nil))
> (handler-case
> (let ( (result (calculate-page-coverage filename)) )
> (format echo "Cyan: ~$ %~%Magenta: ~$ %~%Yellow: ~$ %~%Black: ~$
> %~%Total Byte Count: ~a"
> (* 100 (car result))
> (* 100 (cadr result))
> (* 100 (caddr result))
> (* 100 (cadddr result))
> (car (cddddr result)) ))
> (file-error () "File Not Found") ))
>
> for the test files I run it on, the result of pretty-print-cpc is:
> Cyan: 37.50 %
> Magenta: 37.50 %
> Yellow: 37.50 %
> Black: 12.50 %
> Total Byte Count: 32
>
> however the .net gui is displaying that as:
> ???????
>
> As I mentioned before, I'm using ECL is my lisp. I'm compiling the
> .net part using Visual Studio 2005 C# targeting version 2 of the
> .net framework.

I don't have ECL myself, but here are some things you could check to
isolate the problem:

1. Can you run the Apropos example that comes with RDNZL without
   problems?  It uses a delegate with the same signature.

2. Does your application work if you use LispWorks instead of ECL?

And which version of ECL are you using, BTW?

Cheers,
Edi.


From iverodin at gmail.com  Mon Feb  4 10:22:10 2008
From: iverodin at gmail.com (Iver Odin Kvello)
Date: Mon, 4 Feb 2008 11:22:10 +0100
Subject: [rdnzl-devel] Rdnzl Problem
In-Reply-To: <utzkrr4r9.fsf@agharta.de>
References: <47A3A901.8000108@gmail.com> <utzkrr4r9.fsf@agharta.de>
Message-ID: <c61534450802040222y54b78145q7578bf7d4d52bcd0@mail.gmail.com>

With this invocation, I think pretty-print-CPC would actually return NIL:

[Application.Run (new "CPC_interface" (new "callback" #'(lambda
(filename) (pretty-print-cpc filename t)) ))]

so I'm guessing it was actually called with echo set to NIL. I think I
can reproduce something like this myself,
I don't understand why I haven't seen it before, but it seems
something happens with values returned from lisp to .Net.
(This is on the 3.5 framework, however, but tested on both lispworks and ACL).

> 1. Can you run the Apropos example that comes with RDNZL without
>    problems?  It uses a delegate with the same signature.

It defines a delegate "callback" with the same signature, but it isn't
actually used; the delegate actually used is a KeyPressEventHandler,
and the closure it wraps doesn't actually return a value, and if what
I'm seeing is the same, only return-values passed from lisp to .Net
are affected.

Shortest example is, given a delegate type

  public delegate Int32  intcallback (String input);

(doing this with a return-type of String crashes my lisp)

  (setf callback (new "TestLib.intcallback" (lambda (x) (length x))))
  (invoke callback "Invoke" "hey")

returns 1762921488 . I've done a bit of debugging, and there is no
doubt that arguments are passed correctly to the lisp function, which
is called correctly, and which produces the correct value. Also, the
above result is seen not only when passing the result back to lisp
again, but also when the callback is called from .Net and for example
displayed on screen with a MessageBox. When the callback is called for
effect, there is no problem.

I've tried to return boxed values from the lisp-callback as well with
the same result. Obviously some pointer is pointing in the wrong
direction here, but I haven't gotten deep enough yet to find the
actual bug.

For the original problem, if this is the problem and not the character
encoding, it should work as a band-aid to call a .net function instead
of returning the value as a string, that is, in pretty-print-CPC do
something like

  (invoke myCPCInterface "RecievePrettyPrintedCPC" (format echo ...

Regards, Iver


From mikaelmills at gmail.com  Mon Feb  4 18:57:26 2008
From: mikaelmills at gmail.com (Michael Mills)
Date: Mon, 04 Feb 2008 13:57:26 -0500
Subject: [rdnzl-devel] Re: RDNZL problem
Message-ID: <47A76016.307@gmail.com>

I'm using the latest version of ECL (which is 0.9j). The apropos example 
works fine, but I'm having the same problem in lispworks (personal 
version 5.0)
I've tried sending an array back (suing list-to-rdnzl-array) instead of 
a string, but pretty much the same thing happens.

I've taken Iver's suggest and re-written my program to have the .net 
code call the callback which set the edit-box's value from within lisp, 
which does work.
I initial tried to mimic the apropos example and use an EventHandler 
instead of using my callback, but for some reason, RDNZL couldn't find 
the EventHanlder type when I tried to import it from the System namespace.

Thank you for your help with this problem.


From iverodin at gmail.com  Mon Feb  4 21:31:10 2008
From: iverodin at gmail.com (Iver Odin Kvello)
Date: Mon, 4 Feb 2008 22:31:10 +0100
Subject: [rdnzl-devel] Re: RDNZL problem
In-Reply-To: <47A76016.307@gmail.com>
References: <47A76016.307@gmail.com>
Message-ID: <c61534450802041331n62f28d80l94804c397564631b@mail.gmail.com>

> I initial tried to mimic the apropos example and use an EventHandler
> instead of using my callback, but for some reason, RDNZL couldn't find
> the EventHanlder type when I tried to import it from the System namespace.

Did you look in the right assembly? There is a System.dll, a
System.Core.dll and mscorlib, all defining objects in the "System"
namespace. This is good because - well, anyway, you can find
EventHandler like this:

RDNZL-USER 110 > (import-type "System.EventHandler" (load-assembly "mscorlib"))
#<RDNZL::CONTAINER System.Type #xBC2850>

RDNZL-USER 111 > (use-namespace "System")

RDNZL-USER 112 > (new "EventHandler")
#<RDNZL::CONTAINER System.EventHandler #xBC4718>

IMPORT-TYPES adds the assembly-name to the type as a prefix, which is
why that hurts right here; the princess is in another castle.

This thing is currently somewhat of an issue with generic types as
well: In System.Core there is the Func`n type which is very
convenient, but as this is defined in "System.Core.dll" and for
example System.Int32 is defined in "mscorlib.dll", this does not work:

RDNZL-USER 140 > (invoke "System.Type" "GetType"
"System.Func`2[System.Int32,System.Int32]")
Warning: Returning NULL object from .NET call
NIL

This however will work:
RDNZL-USER 142 > (invoke "System.Type" "GetType"
"System.Action`1[System.Int32]")
#<RDNZL::CONTAINER System.Type #xBC45C8>

because both types are in mscorlib.

I'm planning to add some code to handle this case a bit more
elegantly, but this perl-style hack works if this bites:

RDNZL-USER 139 > (invoke "System.Type" "GetType"
(resolve-generic-type '("System.Func" "System.Int32" "System.Int32")))
#<RDNZL::CONTAINER System.Type #xBC46C8>

where resolve-generic-type ensures all types have assembly-qualified
names like so:

(defun resolve-generic-type (generic-type-definition)
  (if (consp generic-type-definition)
      (let* ((type-args (rest generic-type-definition))
             (args (length type-args))
             (resolved-type-args (mapcar #'resolve-generic-type type-args))
             (main-type-name (format nil "~a`~d" (first
generic-type-definition) args))
             (main-type-resolved (resolve-type-name main-type-name))
             ;; The comma separates the full type name of the main
type from the assembly-name,
             ;; we need to add the parameter-type in the middle in
square parenthesis before
             ;; the assembly..
             (comma (position #\, main-type-resolved))
             (pre-type-result (when comma (subseq main-type-resolved 0 comma)))
             (post-type-result (when comma
                                 (subseq main-type-resolved comma
(length main-type-resolved)))))
        (if comma
            (format nil "~a[~{[~a]~^,~}]~a" pre-type-result
resolved-type-args post-type-result)
          (format nil "~a[~{[~a]~^,~}]" main-type-resolved resolved-type-args)))
    (resolve-type-name generic-type-definition)))


Regards, Iver


From iverodin at gmail.com  Mon Feb  4 21:35:07 2008
From: iverodin at gmail.com (Iver Odin Kvello)
Date: Mon, 4 Feb 2008 22:35:07 +0100
Subject: [rdnzl-devel] Re: RDNZL problem
In-Reply-To: <c61534450802041331n62f28d80l94804c397564631b@mail.gmail.com>
References: <47A76016.307@gmail.com>
	<c61534450802041331n62f28d80l94804c397564631b@mail.gmail.com>
Message-ID: <c61534450802041335w3807b11byead3f7427e475b48@mail.gmail.com>

The function got formatted. Here it is again:

(defun resolve-generic-type (generic-type-definition)
 (if (consp generic-type-definition)
     (let* ((type-args (rest generic-type-definition))
            (args (length type-args))
            (resolved-type-args
             (mapcar #'resolve-generic-type type-args))
            (main-type-name
             (format nil "~a`~d" (first generic-type-definition) args))
            (main-type-resolved (resolve-type-name main-type-name))
            ;; The comma separates the full
            ;; type name of the main type from the assembly-name,
            ;; we need to add the parameter-type in the middle
            ;; in square parenthesis before the assembly..
            (comma (position #\, main-type-resolved))
            (pre-type-result
             (when comma (subseq main-type-resolved 0 comma)))
            (post-type-result
             (when comma
               (subseq main-type-resolved comma
                       (length main-type-resolved)))))
       (if comma
           (format nil "~a[~{[~a]~^,~}]~a"
                   pre-type-result
                   resolved-type-args
                   post-type-result)
         (format nil "~a[~{[~a]~^,~}]"
                 main-type-resolved
                 resolved-type-args)))
   (resolve-type-name generic-type-definition)))


From edi at agharta.de  Tue Feb  5 03:01:14 2008
From: edi at agharta.de (Edi Weitz)
Date: Tue, 05 Feb 2008 04:01:14 +0100
Subject: [rdnzl-devel] Rdnzl Problem
In-Reply-To: <c61534450802040222y54b78145q7578bf7d4d52bcd0@mail.gmail.com>
	(Iver Odin Kvello's message of "Mon, 4 Feb 2008 11:22:10 +0100")
References: <47A3A901.8000108@gmail.com> <utzkrr4r9.fsf@agharta.de>
	<c61534450802040222y54b78145q7578bf7d4d52bcd0@mail.gmail.com>
Message-ID: <uir14ksxx.fsf@agharta.de>

On Mon, 4 Feb 2008 11:22:10 +0100, "Iver Odin Kvello" <iverodin at gmail.com> wrote:

> I don't understand why I haven't seen it before, but it seems
> something happens with values returned from lisp to .Net.

Iver, thanks for the analysis.  With that as a starting point, I've
managed to find the actual problem.  (And this seems to show that
Michael was the first one for a long time who actually used callbacks
into Lisp which are supposed to return something... :)

The code in DelegateAdapterBuilder.cpp creates the wrong IL code.  I
don't have the time right now to prepare a new release (maybe in the
next days), but if you want to fix this yourself, here's what to do:

1. The error is in "generateInvokeMethod" /after/ "invoke" has been
   called, i.e. when the return value is handled.

2. In case of a void return value, the code is correct.

3. In case of a value type, the correct loading form (depending on the
   type) must be emitted after the "Unbox" operation - for
   System.Int32 this would be "Ldind_I4" for example - to bring the
   actual value on the stack.

   Which loading form has to be emitted must be decided from a small
   table lookup or so - "Ldind_I1" for booleans, "Ldind_R8" for double
   floats, and so on.

4. And in the third case the code which is there (which emits
   "Ldind_I4") is bogus.  In this case nothing has to be done and the
   return value is already correct.

I've confirmed that with these changes I can use Lisp callbacks which
return System.Int32 as well as ones which return System.String.

Thanks to you and Michael for catching this one,
Edi.


From iverodin at gmail.com  Wed Feb 13 20:49:55 2008
From: iverodin at gmail.com (Iver Odin Kvello)
Date: Wed, 13 Feb 2008 21:49:55 +0100
Subject: [rdnzl-devel] Rdnzl Problem
In-Reply-To: <uir14ksxx.fsf@agharta.de>
References: <47A3A901.8000108@gmail.com> <utzkrr4r9.fsf@agharta.de>
	<c61534450802040222y54b78145q7578bf7d4d52bcd0@mail.gmail.com>
	<uir14ksxx.fsf@agharta.de>
Message-ID: <c61534450802131249h64fbd21fic68e80c93b8433e0@mail.gmail.com>

>    Which loading form has to be emitted must be decided from a small
>    table lookup or so - "Ldind_I1" for booleans, "Ldind_R8" for double
>    floats, and so on.

I tried to muck around with this myself, and discovered the Unbox_Any
opcode, present from version 2.0 of the framework; and this also seems
to work (see attached patch). Of course, I don't really know what I'm
doing, and this isn't present in version 1.0 and 1.1,  but could that
work also? It makes the fix a one-liner.

Iver
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rdnzl-cpp.patch
Type: application/octet-stream
Size: 734 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/rdnzl-devel/attachments/20080213/f549a909/attachment.obj>

From iverodin at gmail.com  Wed Feb 13 21:55:15 2008
From: iverodin at gmail.com (Iver Odin Kvello)
Date: Wed, 13 Feb 2008 22:55:15 +0100
Subject: [rdnzl-devel] Resolving assemblies in user-defined paths from lisp
	now works
Message-ID: <c61534450802131355x459a4521s774e9ff0f31ffb73@mail.gmail.com>

 With the new code, adding lisp functions to the AssemblyResolve event
handler now works,  as in the following example of loading AproposGui
directly from the examples subdirectory without using LoadFrom:

RDNZL-USER 3 > (load-assembly "AproposGui")
Warning: Returning NULL object from .NET call
NIL
RDNZL-USER 4 > (pushnew (translate-logical-pathname #P"rdnzl:examples;")
                                         *additional-assembly-directories*)
RDNZL-USER 5 > (install-assembly-resolve-handler)
#<RDNZL::CONTAINER System.ResolveEventHandler #xBD6E28>
RDNZL-USER 6 > (load-assembly "AproposGui")
#<RDNZL::CONTAINER System.Reflection.Assembly #xBD7078>

Very satisfying :)

One isn't really supposed to do this, apparently, but it's pretty
convenient, especially for stuff like AproposGui, and possibly
something to add to the examples in itself.

Regards,
Iver
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AddAssemblyPath.lisp
Type: application/octet-stream
Size: 2356 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/rdnzl-devel/attachments/20080213/f2879920/attachment.obj>

From iverodin at gmail.com  Thu Feb 14 00:21:15 2008
From: iverodin at gmail.com (Iver Odin Kvello)
Date: Thu, 14 Feb 2008 01:21:15 +0100
Subject: [rdnzl-devel] Patch for generic types in RDZNL
Message-ID: <c61534450802131621l303cd387gcc49e035e0ce0a0d@mail.gmail.com>

I've attached a patch that adds support for generic types to RDNZL;
the approach used might not be ideal, I'm not sure.

The problem with generics in RDNZL was mainly an issue in GetType
making the "BaseType?n[ParameterType1, ...,ParameterTypen]"-syntax
fail to construct the correct type if the base type and parameter
types lived in different assemblies. Here is an example:

RDNZL-USER 25 > (invoke "System.Type" "GetType" "System.Action`1[System.Int32]")
#<RDNZL::CONTAINER System.Type #xBD5B28>

RDNZL-USER 26 > (invoke "System.Type" "GetType"
"System.Action`2[System.Int32,System.Int32]")
Warning: Returning NULL object from .NET call
NIL

Even if it had worked, some syntax would have been nice to let this
interact with USE-NAMESPACE.

Now, if all the type-names involved in a generic type-name like above
were fully assembly-qualified, GetType would find the correct type.
For the above type that would be
"System.Action`2[[System.Int32, mscorlib, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.Int32,
mscorlib, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089]], System.Core, Version=3.5.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089"

To make it easier to refer to this type, and to make it interact
better with USE-NAMESPACE, I propose allowing a list (tree) to denote
generic types. Since the length of the list will encode the number of
parameters, this also allows one to drop the `n-part of the typename,
and denote the type above like this (with the System namespace used:)

  '("Action" "Int32" "Int32")

The patch implements this syntax in a particular way that might be
debatable on several points. It modifies RESOLVE-TYPE-NAME to accept a
list of this format, returning a new list of each type resolved (and
hashed). That is, a tree of type names is mapped to a tree of fully
qualified type names, with the first element in each list (and
sublist) treated specially. Further, it modifies MAKE-TYPE-FROM-NAME
so that this too accepts a tree of types, and if so, creates a closed
generic type from the base type and parameters. To do this it first
retrieves the base type, then calls MakeGenericType on it.

All functions that can take a string as a type-name is further
modified to accept also a tree, passing this on to RESOLVE-TYPE-NAME.
This allows one to do stuff like

   (new '("Func" "Int32" "String") (lambda (x) (format nil "~@r" x)))

and so forth. This all works:

 RDNZL-USER 31 > (setf f (new '("Func" "Int32" "String") (lambda (x)
(format nil "~@r" x))))
 #<RDNZL::CONTAINER System.Func`2[[System.Int32, mscorlib,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089],[System.String, mscorlib,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
#x3BDE2C8>

 RDNZL-USER 32 > (invoke f "Invoke" 2008)
 "MMVIII"


The debatable points:

 1. It might have sufficed to just have made RESOLVE-TYPE-NAME create
the fully qualified typename directly. This would have either implied
doing some string manipulation (like a function I posted earlier) or
by creating the type using MakeGenericType and returning the
AssemblyQualifiedName. The first alternative didn't feel quite right
and the second would be pretty much what I've implemented except that
the type would be thrown away after its name was resolved. I thought
perhaps it was a bit neater to modify both RESOLVE and
MAKE-TYPE-FROM-NAME, keeping the basic function of each basically like
the current implementation.

 2. Having every function accept trees makes it often neccessary to
tests for CONTAINERP, STRINGP and finally CONSP which perhaps isn't
that nice.

 3. INVOKE accepts a syntax (INVOKE (assembly . type-name) method)
where the static method named is called on the type, resolved from
type-name using only the assembly given. I extended this to also
accept generic types, but how to resolve the parameter-types isn't
then completely obvious (the implementation just uses the normal
type-lookup for parameter-types.) Also, this function already used
CONSP for the type-specifier (compatibly, though).

4. Perhaps using lists like this is to 'bland' syntactically. It might
do to have an operator like
     (generic "Func" "Int32" "String")
to return a closed generic type, and make sure all callers accepted
the resulting type-object. This would leave RESOLVE-, MAKE-TYPE-FROM
and the rest as they were, doing all the extra work in a single spot.
But this would pretty much be a type-name too, and one extra word
longer than absolutely necessary:
     (new (generic "Func" "Int32" "String") (lambda (x) ...))


If the patch looks acceptable however, I'll of course update the
documentation too.

This contains no support for generic methods. The reason is that these
are even more problematic to handle using the given interface. In
particular, GetMethod will not retrieve the method (or anything) if a
generic method is overloaded; so one has to implement a search
manually before MakeGenericMethod can be called
(http://blogs.msdn.com/yirutang/archive/2005/09/14/466280.aspx). But I
think this is still useful mostly for toying around with the newer
C#-features, so proper support can probably wait.

Regards, Iver
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rdnzl-generics.patch
Type: application/octet-stream
Size: 12418 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/rdnzl-devel/attachments/20080214/5ebda49e/attachment.obj>

From edi at agharta.de  Thu Feb 14 08:15:44 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 14 Feb 2008 09:15:44 +0100
Subject: [rdnzl-devel] Rdnzl Problem
In-Reply-To: <c61534450802131249h64fbd21fic68e80c93b8433e0@mail.gmail.com>
	(Iver Odin Kvello's message of "Wed, 13 Feb 2008 21:49:55 +0100")
References: <47A3A901.8000108@gmail.com> <utzkrr4r9.fsf@agharta.de>
	<c61534450802040222y54b78145q7578bf7d4d52bcd0@mail.gmail.com>
	<uir14ksxx.fsf@agharta.de>
	<c61534450802131249h64fbd21fic68e80c93b8433e0@mail.gmail.com>
Message-ID: <uodakoswf.fsf@agharta.de>

On Wed, 13 Feb 2008 21:49:55 +0100, "Iver Odin Kvello" <iverodin at gmail.com> wrote:

> I tried to muck around with this myself, and discovered the
> Unbox_Any opcode, present from version 2.0 of the framework; and
> this also seems to work (see attached patch).

Cool, thanks.  Just checking - the IsValueType condition is the
correct one?

> Of course, I don't really know what I'm doing, and this isn't
> present in version 1.0 and 1.1, but could that work also?

The next release of RDNZL that I'm currently working on will switch to
Visual Studio 2005 anyway as I don't have 2003 on the harddisk of my
new laptop anymore.  AFAIU this will entail switching to the 2.0
framework which I think is OK.  I don't see any particular reason to
stick with 1.x.

Thanks,
Edi.


From iverodin at gmail.com  Thu Feb 14 08:51:07 2008
From: iverodin at gmail.com (Iver Odin Kvello)
Date: Thu, 14 Feb 2008 09:51:07 +0100
Subject: [rdnzl-devel] Rdnzl Problem
In-Reply-To: <uodakoswf.fsf@agharta.de>
References: <47A3A901.8000108@gmail.com> <utzkrr4r9.fsf@agharta.de>
	<c61534450802040222y54b78145q7578bf7d4d52bcd0@mail.gmail.com>
	<uir14ksxx.fsf@agharta.de>
	<c61534450802131249h64fbd21fic68e80c93b8433e0@mail.gmail.com>
	<uodakoswf.fsf@agharta.de>
Message-ID: <c61534450802140051m2a75793bu7f4dc6a1212c331b@mail.gmail.com>

On Thu, Feb 14, 2008 at 9:15 AM, Edi Weitz <edi at agharta.de> wrote:
> On Wed, 13 Feb 2008 21:49:55 +0100, "Iver Odin Kvello" <iverodin at gmail.com> wrote:
>
>  > I tried to muck around with this myself, and discovered the
>  > Unbox_Any opcode, present from version 2.0 of the framework; and
>  > this also seems to work (see attached patch).
>
>  Cool, thanks.  Just checking - the IsValueType condition is the
>  correct one?

I think so, but I don't understand this material thoroughly.

http://msdn2.microsoft.com/en-us/library/system.reflection.emit.opcodes.unbox_any.aspx
says that:

  When applied to the boxed form of a value type, the unbox.any
instruction extracts the value contained within obj (of type O),
  and is therefore   equivalent to unbox followed by ldobj.

  When applied to a reference type, the unbox.any instruction has the
same effect as castclass  typeTok.

But we know it will be a value-type.
For ldobj (which is actually present from version 1.0 I see now) the docs say:

  The ldobj instruction copies the value pointed to by addrOfValObj
(of type &, *, or native int) to the top of the stack.
  The number of bytes copied depends on the size of the class (as
specified by the class parameter). The class parameter is a metadata
token representing the value type.

So given that the ld-operation to use only depends on the returnType,
it seems to me that it should work. Here are my tests
(with the "generic"-thing that I didn't submit a patch for) showing
returns of both IsValueType-types and a String:

RDNZL-USER(60): (setf f1 (new (generic "Func" "Int32" "Int32") #'1+))
#<RDNZL::CONTAINER System.Func`2[[System.Int32, mscorlib,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089],[System.Int32, mscorlib,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
#xdd69738>
RDNZL-USER(61): (setf f2 (new (generic "Func" "Int32" "Single")
(lambda (x) (coerce x 'single-float))))
#<RDNZL::CONTAINER System.Func`2[[System.Int32, mscorlib,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089],[System.Single, mscorlib,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
#xdd69e68>
RDNZL-USER(62): (setf f3 (new (generic "Func" "Int32" "Double")
(lambda (x) (* 1.0 x))))
#<RDNZL::CONTAINER System.Func`2[[System.Int32, mscorlib,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089],[System.Double, mscorlib,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
#xdd6a378>
RDNZL-USER(63): (setf f4 (new (generic "Func" "Int32" "String")
(lambda (x) (format nil "~@r"  x))))
#<RDNZL::CONTAINER System.Func`2[[System.Int32, mscorlib,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089],[System.String, mscorlib,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
#xdd6a888>
RDNZL-USER(64): (property (invoke "System.Type" "GetType"
"System.String") "IsValueType")
NIL
RDNZL-USER(65): (property (invoke "System.Type" "GetType"
"System.Single") "IsValueType")
T
RDNZL-USER(66): (invoke f1 "Invoke" 5)
6
RDNZL-USER(67): (invoke f2 "Invoke" 5)
5.0
RDNZL-USER(68): (invoke f3 "Invoke" 5)
5.0
RDNZL-USER(69): (invoke f4 "Invoke" 5)
"V"

Regards,
Iver


From edi at agharta.de  Thu Feb 14 10:42:04 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 14 Feb 2008 11:42:04 +0100
Subject: [rdnzl-devel] Resolving assemblies in user-defined paths from
	lisp now works
In-Reply-To: <c61534450802131355x459a4521s774e9ff0f31ffb73@mail.gmail.com>
	(Iver Odin Kvello's message of "Wed, 13 Feb 2008 22:55:15 +0100")
References: <c61534450802131355x459a4521s774e9ff0f31ffb73@mail.gmail.com>
Message-ID: <ufxvvq0oz.fsf@agharta.de>

On Wed, 13 Feb 2008 22:55:15 +0100, "Iver Odin Kvello" <iverodin at gmail.com> wrote:

> With the new code, adding lisp functions to the AssemblyResolve
> event handler now works, as in the following example of loading
> AproposGui directly from the examples subdirectory without using
> LoadFrom:
>
> RDNZL-USER 3 > (load-assembly "AproposGui")
> Warning: Returning NULL object from .NET call
> NIL
> RDNZL-USER 4 > (pushnew (translate-logical-pathname #P"rdnzl:examples;")
>                                          *additional-assembly-directories*)
> RDNZL-USER 5 > (install-assembly-resolve-handler)
> #<RDNZL::CONTAINER System.ResolveEventHandler #xBD6E28>
> RDNZL-USER 6 > (load-assembly "AproposGui")
> #<RDNZL::CONTAINER System.Reflection.Assembly #xBD7078>
>
> Very satisfying :)

Nice... :)

> One isn't really supposed to do this, apparently, but it's pretty
> convenient, especially for stuff like AproposGui, and possibly
> something to add to the examples in itself.

I'll add a link from the docs to your email.


From edi at agharta.de  Thu Feb 14 12:21:43 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 14 Feb 2008 13:21:43 +0100
Subject: [rdnzl-devel] New release 0.12.0 plus DLL 0.7.0 (Was: Rdnzl Problem)
In-Reply-To: <c61534450802131249h64fbd21fic68e80c93b8433e0@mail.gmail.com>
	(Iver Odin Kvello's message of "Wed, 13 Feb 2008 21:49:55 +0100")
References: <47A3A901.8000108@gmail.com> <utzkrr4r9.fsf@agharta.de>
	<c61534450802040222y54b78145q7578bf7d4d52bcd0@mail.gmail.com>
	<uir14ksxx.fsf@agharta.de>
	<c61534450802131249h64fbd21fic68e80c93b8433e0@mail.gmail.com>
Message-ID: <uy79nohig.fsf_-_@agharta.de>

On Wed, 13 Feb 2008 21:49:55 +0100, "Iver Odin Kvello" <iverodin at gmail.com> wrote:

> I tried to muck around with this myself, and discovered the
> Unbox_Any opcode, present from version 2.0 of the framework; and
> this also seems to work (see attached patch). Of course, I don't
> really know what I'm doing, and this isn't present in version 1.0
> and 1.1, but could that work also? It makes the fix a one-liner.

I've now released a new version which hopefully fixes this.  Thanks
for your help and thanks to Michael for discovering the bug.  A simple
test for callbacks is now included in the examples folder.

As I already announced, the new DLL and the updated C++ code are based
on Visual Studio 2005 now.

Please test!


From edi at agharta.de  Thu Feb 14 12:25:28 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 14 Feb 2008 13:25:28 +0100
Subject: [rdnzl-devel] Patch for generic types in RDZNL
In-Reply-To: <c61534450802131621l303cd387gcc49e035e0ce0a0d@mail.gmail.com>
	(Iver Odin Kvello's message of "Thu, 14 Feb 2008 01:21:15 +0100")
References: <c61534450802131621l303cd387gcc49e035e0ce0a0d@mail.gmail.com>
Message-ID: <utzkbohc7.fsf@agharta.de>

On Thu, 14 Feb 2008 01:21:15 +0100, "Iver Odin Kvello" <iverodin at gmail.com> wrote:

> If the patch looks acceptable however, I'll of course update the
> documentation too.

Thanks.  I think that looks reasonable and I've integrated this into
0.12.0 already.  I think I also updated all the relevant documentation
entries, but you might want to check if I missed something.

FWIW, the Excel example doesn't work for me anymore.  This might be
due to the changes in the C++ code (and the upgrade to VS 2005), or
due to the generic types patch, or due to something being different on
my new laptop from how it used to be before, or something entirely
different.  I don't have enough time to look into this right now, but
I'd be happy if someone else did.

Thanks,
Edi.


From edi at agharta.de  Thu Feb 14 12:28:40 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 14 Feb 2008 13:28:40 +0100
Subject: [rdnzl-devel] Rdnzl Problem
In-Reply-To: <c61534450802140051m2a75793bu7f4dc6a1212c331b@mail.gmail.com>
	(Iver Odin Kvello's message of "Thu, 14 Feb 2008 09:51:07 +0100")
References: <47A3A901.8000108@gmail.com> <utzkrr4r9.fsf@agharta.de>
	<c61534450802040222y54b78145q7578bf7d4d52bcd0@mail.gmail.com>
	<uir14ksxx.fsf@agharta.de>
	<c61534450802131249h64fbd21fic68e80c93b8433e0@mail.gmail.com>
	<uodakoswf.fsf@agharta.de>
	<c61534450802140051m2a75793bu7f4dc6a1212c331b@mail.gmail.com>
Message-ID: <upruzoh6v.fsf@agharta.de>

On Thu, 14 Feb 2008 09:51:07 +0100, "Iver Odin Kvello" <iverodin at gmail.com> wrote:

> RDNZL-USER(60): (setf f1 (new (generic "Func" "Int32" "Int32") #'1+))

Nice.  Will this (minus the "generic") also work with 0.12.0 now that
your patch is in?  Maybe you'd like to write a paragraph or two about
generic types that we can add to the documentation?  (ASCII text is
fine, doesn't have to be HTML.)

Oh, BTW, will you also be in Amsterdam?


From iverodin at gmail.com  Thu Feb 14 20:47:19 2008
From: iverodin at gmail.com (Iver Odin Kvello)
Date: Thu, 14 Feb 2008 21:47:19 +0100
Subject: [rdnzl-devel] Patch for generic types in RDZNL
In-Reply-To: <utzkbohc7.fsf@agharta.de>
References: <c61534450802131621l303cd387gcc49e035e0ce0a0d@mail.gmail.com>
	<utzkbohc7.fsf@agharta.de>
Message-ID: <c61534450802141247y20fcfa40laaa2bc56912b7540@mail.gmail.com>

>  FWIW, the Excel example doesn't work for me anymore.  This might be
>  due to the changes in the C++ code (and the upgrade to VS 2005), or
>  due to the generic types patch, or due to something being different on
>  my new laptop from how it used to be before, or something entirely
>  different.  I don't have enough time to look into this right now, but
>  I'd be happy if someone else did.

I'm seeing the same thing, no solution yet.

 I tried using 0.12.0 with the old (but patched) rdnzl.dll, with this
excel.lisp worked, but not with the newest rdznl.dll. I was first
guessing that this had something to do with the Interop stuff, as with
http://blogs.msdn.com/ptorr/archive/2004/02/05/67872.aspx, but the
problem doesn't actually occur until the code has retrieved a
Workbooks-object; this object has no methods (not even GetType.) The
object created just using 'new' on the ApplicationClass does have
methods and can be made visible, quitted and so forth.

It *should* have nothing to do with the generic types, because all
types named are simple non-generic types; and therefore the code
should work exactly as before; and indeed as noted 0.12.0 does work
with the older .dll.

When using both 0.12.0 and the new dll this happens:
RDNZL-USER(7): (range-contents :file-name (namestring
(translate-logical-pathname #P"rdnzl:examples;example.xls")))
Error: .NET error (System.Exception): Instance method not found:
Microsoft.Office.Interop.Excel.Workbooks::Open(System.String,System.Reflection.Missing,
(etc etc etc)

Other instance methods not found are GetType and so forth; basically
Workbooks is null or something. But with the older dll,
(("Last name" "First name" "Superhero") ("Kent" "Clark" "Superman")
("Wayne" "Bruce" "Batman") ("Parker" "Peter" "Spiderman"))
is returned.

This older .dll  is just the previous version, patched with the
Unbox_Any thing, and compiled with VS2008 express.

Regards, Iver


From iverodin at gmail.com  Thu Feb 14 20:53:31 2008
From: iverodin at gmail.com (Iver Odin Kvello)
Date: Thu, 14 Feb 2008 21:53:31 +0100
Subject: [rdnzl-devel] Rdnzl Problem
In-Reply-To: <upruzoh6v.fsf@agharta.de>
References: <47A3A901.8000108@gmail.com> <utzkrr4r9.fsf@agharta.de>
	<c61534450802040222y54b78145q7578bf7d4d52bcd0@mail.gmail.com>
	<uir14ksxx.fsf@agharta.de>
	<c61534450802131249h64fbd21fic68e80c93b8433e0@mail.gmail.com>
	<uodakoswf.fsf@agharta.de>
	<c61534450802140051m2a75793bu7f4dc6a1212c331b@mail.gmail.com>
	<upruzoh6v.fsf@agharta.de>
Message-ID: <c61534450802141253l43ec6bc3haddcf98325f181c8@mail.gmail.com>

>  Nice.  Will this (minus the "generic") also work with 0.12.0 now that
>  your patch is in?

Yes - this is using 0.12.0 with the latest dll:

(import-assembly "System.Core")
(import-assembly "mscorlib")
(import-assembly "System")
(use-namespace "System")

(new '("Func" "Int32" "Int32") #'1+)

(invoke *  "Invoke" 4)
=> 5

>  Maybe you'd like to write a paragraph or two about
>  generic types that we can add to the documentation?  (ASCII text is
>  fine, doesn't have to be HTML.)

I will. If the bare list syntax proves hateful, 'GENERIC' would take
the same syntax, so that'll be reusable too.

>  Oh, BTW, will you also be in Amsterdam?

I still haven't decided.

Iver


From edi at agharta.de  Fri Feb 15 00:26:20 2008
From: edi at agharta.de (Edi Weitz)
Date: Fri, 15 Feb 2008 01:26:20 +0100
Subject: [rdnzl-devel] Patch for generic types in RDZNL
In-Reply-To: <c61534450802141247y20fcfa40laaa2bc56912b7540@mail.gmail.com>
	(Iver Odin Kvello's message of "Thu, 14 Feb 2008 21:47:19 +0100")
References: <c61534450802131621l303cd387gcc49e035e0ce0a0d@mail.gmail.com>
	<utzkbohc7.fsf@agharta.de>
	<c61534450802141247y20fcfa40laaa2bc56912b7540@mail.gmail.com>
Message-ID: <umyq3m5eb.fsf@agharta.de>

On Thu, 14 Feb 2008 21:47:19 +0100, "Iver Odin Kvello" <iverodin at gmail.com> wrote:

> I'm seeing the same thing, no solution yet.
>
> I tried using 0.12.0 with the old (but patched) rdnzl.dll, with this
> excel.lisp worked, but not with the newest rdznl.dll. I was first
> guessing that this had something to do with the Interop stuff, as
> with http://blogs.msdn.com/ptorr/archive/2004/02/05/67872.aspx, but
> the problem doesn't actually occur until the code has retrieved a
> Workbooks-object; this object has no methods (not even GetType.) The
> object created just using 'new' on the ApplicationClass does have
> methods and can be made visible, quitted and so forth.
>
> It *should* have nothing to do with the generic types, because all
> types named are simple non-generic types; and therefore the code
> should work exactly as before; and indeed as noted 0.12.0 does work
> with the older .dll.
>
> When using both 0.12.0 and the new dll this happens: RDNZL-USER(7):
> (range-contents :file-name (namestring (translate-logical-pathname
> #P"rdnzl:examples;example.xls"))) Error: .NET error
> (System.Exception): Instance method not found:
> Microsoft.Office.Interop.Excel.Workbooks::Open(System.String,System.Reflection.Missing,
> (etc etc etc)
>
> Other instance methods not found are GetType and so forth; basically
> Workbooks is null or something. But with the older dll, (("Last
> name" "First name" "Superhero") ("Kent" "Clark" "Superman") ("Wayne"
> "Bruce" "Batman") ("Parker" "Peter" "Spiderman")) is returned.
>
> This older .dll is just the previous version, patched with the
> Unbox_Any thing, and compiled with VS2008 express.

Which version of the C++ source code did you use for this?  The
"official" releases before 0.7.0 were all built with VS 2003 and AFAIR
didn't even build with newer version of VS.

Have you tried to compile the DLL from the 0.7.0 source code using VS
2008?  I'm asking because I'm beginning to suspect that (my
installation of) VS 2005 is the culprit.  I've tried with Michael
Goffioul's VS 2005 version of 0.5.0 and with Matthew D Swank's VS 2005
version of 0.6.0 and both failed as well.

Strange...


From iverodin at gmail.com  Fri Feb 15 09:07:57 2008
From: iverodin at gmail.com (Iver Odin Kvello)
Date: Fri, 15 Feb 2008 10:07:57 +0100
Subject: [rdnzl-devel] Patch for generic types in RDZNL
In-Reply-To: <umyq3m5eb.fsf@agharta.de>
References: <c61534450802131621l303cd387gcc49e035e0ce0a0d@mail.gmail.com>
	<utzkbohc7.fsf@agharta.de>
	<c61534450802141247y20fcfa40laaa2bc56912b7540@mail.gmail.com>
	<umyq3m5eb.fsf@agharta.de>
Message-ID: <c61534450802150107n2ec6d957obcff2fd0fec9fc76@mail.gmail.com>

>  Which version of the C++ source code did you use for this?  The
>  "official" releases before 0.7.0 were all built with VS 2003 and AFAIR
>  didn't even build with newer version of VS.

Version 0.6.0, it did build, though I had to change one argument -
runtime library I think, to /MD, and getting this warning:

1>cl : Command line warning D9035 : option 'clr:oldsyntax' has been
deprecated and will be removed in a future release

I don't know the implications of changing the parameters I did, but
the resulting dll worked fine (ACL, LW) so I figured things were OK.

>  Have you tried to compile the DLL from the 0.7.0 source code using VS
>  2008?  I'm asking because I'm beginning to suspect that (my
>  installation of) VS 2005 is the culprit.  I've tried with Michael
>  Goffioul's VS 2005 version of 0.5.0 and with Matthew D Swank's VS 2005
>  version of 0.6.0 and both failed as well.

Yes; it compiles with no warnings or modifications, but the same error
occurs with Workbooks not having the Open (or any other) methods.

Iver


From edi at agharta.de  Fri Feb 15 16:15:01 2008
From: edi at agharta.de (Edi Weitz)
Date: Fri, 15 Feb 2008 17:15:01 +0100
Subject: [rdnzl-devel] Patch for generic types in RDZNL
In-Reply-To: <c61534450802150107n2ec6d957obcff2fd0fec9fc76@mail.gmail.com>
	(Iver Odin Kvello's message of "Fri, 15 Feb 2008 10:07:57 +0100")
References: <c61534450802131621l303cd387gcc49e035e0ce0a0d@mail.gmail.com>
	<utzkbohc7.fsf@agharta.de>
	<c61534450802141247y20fcfa40laaa2bc56912b7540@mail.gmail.com>
	<umyq3m5eb.fsf@agharta.de>
	<c61534450802150107n2ec6d957obcff2fd0fec9fc76@mail.gmail.com>
Message-ID: <uy79mb3i2.fsf@agharta.de>

On Fri, 15 Feb 2008 10:07:57 +0100, "Iver Odin Kvello" <iverodin at gmail.com> wrote:

> Version 0.6.0, it did build, though I had to change one argument -
> runtime library I think, to /MD, and getting this warning:
>
> 1>cl : Command line warning D9035 : option 'clr:oldsyntax' has been
> deprecated and will be removed in a future release

Aha!  Where did the "clr:oldsyntax" come from?  Can't find it in the
tarball.

I think the main difference between 0.6.0 and 0.7.0 is that 0.7.0
doesn't use the "old syntax" anymore.  It is based on Michael
Goffioul's port which can still be found here:

  http://weitz.de/files/RDNZL-cpp-0.5-vc8.tar.bz2

You'll see quite a lot of changes in there - ^ instead of *, uses of
cli::pin_ptr, gcnew, safe_cast, etc.  One of those must be the reason
for the problems we see, but I don't know which one...  And I don't
understand why these problems only occur with the Excel example.
(Maybe the Office library itself is an "old" system?)

Anyway, I think the changes to make the C++ compatible with the "new"
syntax are necessary - see the deprecation note you got above.  Still,
it'd be nice to have the Excel example working again.  Any C++ experts
out there?


From matthew.oconnor at calyptech.com  Tue Feb 19 05:28:39 2008
From: matthew.oconnor at calyptech.com (Matthew O'Connor)
Date: Tue, 19 Feb 2008 16:28:39 +1100
Subject: [rdnzl-devel] Developer experience GUI applications.
Message-ID: <1203398919.8498.31.camel@localhost>

Hi,

I am contemplating using RDNZL for my next project. I've started playing
with it and am very impressed. I am interested in others peoples
experiences with using for applications that work around tabular data,
like a business application.

If you could point me to any screenshots of RDNZL work it would be much
appreciated.

Regards,

Matthew




From iverodin at gmail.com  Tue Feb 19 12:08:24 2008
From: iverodin at gmail.com (Iver Odin Kvello)
Date: Tue, 19 Feb 2008 13:08:24 +0100
Subject: [rdnzl-devel] Patch for generic types in RDZNL
In-Reply-To: <uy79mb3i2.fsf@agharta.de>
References: <c61534450802131621l303cd387gcc49e035e0ce0a0d@mail.gmail.com>
	<utzkbohc7.fsf@agharta.de>
	<c61534450802141247y20fcfa40laaa2bc56912b7540@mail.gmail.com>
	<umyq3m5eb.fsf@agharta.de>
	<c61534450802150107n2ec6d957obcff2fd0fec9fc76@mail.gmail.com>
	<uy79mb3i2.fsf@agharta.de>
Message-ID: <c61534450802190408y4ed6545ay19552567be4ffd9c@mail.gmail.com>

Good news follows -

> Aha!  Where did the "clr:oldsyntax" come from?  Can't find it in the
> tarball.

I'm guessing VS put it there itself, probably. It did something or
other to the project when opened.

> Anyway, I think the changes to make the C++ compatible with the "new"
> syntax are necessary - see the deprecation note you got above.  Still,
> it'd be nice to have the Excel example working again.  Any C++ experts
> out there?

I have gotten some very kind help from a local C++ expert, and the bug
seems to be found and fixed with the attached patch. The fix is due to
Per Arild Fiskum at selvaag.no and is of course one misplaced
character (twice) in InvokeMember, specifically using != instead of ==
when testing a methodinfo-pointer against nullptr.

It only affected interface-methods, and therefore in particular COM
objects of course.

This is 0.7.0 with the patch:
RDNZL-USER(7): (range-contents :file-name +initial-filename+)
(("Last name" "First name" "Superhero") ("Kent" "Clark" "Superman")
("Wayne" "Bruce" "Batman") ("Parker" "Peter" "Spiderman"))


Iver
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rdnzl-0.7.0.patch
Type: application/octet-stream
Size: 873 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/rdnzl-devel/attachments/20080219/3d2fd8d6/attachment.obj>

From edi at agharta.de  Tue Feb 19 18:40:12 2008
From: edi at agharta.de (Edi Weitz)
Date: Tue, 19 Feb 2008 19:40:12 +0100
Subject: [rdnzl-devel] Patch for generic types in RDZNL
In-Reply-To: <c61534450802190408y4ed6545ay19552567be4ffd9c@mail.gmail.com>
	(Iver Odin Kvello's message of "Tue, 19 Feb 2008 13:08:24 +0100")
References: <c61534450802131621l303cd387gcc49e035e0ce0a0d@mail.gmail.com>
	<utzkbohc7.fsf@agharta.de>
	<c61534450802141247y20fcfa40laaa2bc56912b7540@mail.gmail.com>
	<umyq3m5eb.fsf@agharta.de>
	<c61534450802150107n2ec6d957obcff2fd0fec9fc76@mail.gmail.com>
	<uy79mb3i2.fsf@agharta.de>
	<c61534450802190408y4ed6545ay19552567be4ffd9c@mail.gmail.com>
Message-ID: <u7ih0pz77.fsf@agharta.de>

On Tue, 19 Feb 2008 13:08:24 +0100, "Iver Odin Kvello" <iverodin at gmail.com> wrote:

> I have gotten some very kind help from a local C++ expert, and the
> bug seems to be found and fixed with the attached patch.

That's wonderful!  Thanks a lot.  I'll prepare a new release tonight.

> The fix is due to Per Arild Fiskum at selvaag.no

He'll be immortalized in the ChangeLog... :)

> and is of course one misplaced character (twice) in InvokeMember,
> specifically using != instead of == when testing a
> methodinfo-pointer against nullptr.

Ah, that must have happened when porting to Visual Studio 2005.  The
code in 0.6.0 simply tested for !mi instead of mi != nullptr.  So, the
attempt to write cleaner and more idiomatic code ended up in two
errors... :)

Thanks again,
Edi.


From edi at agharta.de  Tue Feb 19 18:53:36 2008
From: edi at agharta.de (Edi Weitz)
Date: Tue, 19 Feb 2008 19:53:36 +0100
Subject: [rdnzl-devel] New releases 0.12.1/0.7.1 (Was: Patch for generic
	types in RDZNL)
In-Reply-To: <c61534450802190408y4ed6545ay19552567be4ffd9c@mail.gmail.com>
	(Iver Odin Kvello's message of "Tue, 19 Feb 2008 13:08:24 +0100")
References: <c61534450802131621l303cd387gcc49e035e0ce0a0d@mail.gmail.com>
	<utzkbohc7.fsf@agharta.de>
	<c61534450802141247y20fcfa40laaa2bc56912b7540@mail.gmail.com>
	<umyq3m5eb.fsf@agharta.de>
	<c61534450802150107n2ec6d957obcff2fd0fec9fc76@mail.gmail.com>
	<uy79mb3i2.fsf@agharta.de>
	<c61534450802190408y4ed6545ay19552567be4ffd9c@mail.gmail.com>
Message-ID: <u3aropykv.fsf_-_@agharta.de>

For the record, both tarballs have been updated.  I could confirm that
the Excel example works again on my machine.


From matthew.oconnor at calyptech.com  Mon Feb 25 02:36:11 2008
From: matthew.oconnor at calyptech.com (Matthew O'Connor)
Date: Mon, 25 Feb 2008 02:36:11 +0000
Subject: [rdnzl-devel] Developer experience GUI applications.
In-Reply-To: <1203398919.8498.31.camel@localhost>
References: <1203398919.8498.31.camel@localhost>
Message-ID: <1203906971.7017.9.camel@localhost>

Judging by the massive response I got I could have chosen the wrong
forum for my question. :-)

Is there another I should be using?

Regards,

Matthew

On Tue, 2008-02-19 at 16:28 +1100, Matthew O'Connor wrote:

> Hi,
> 
> I am contemplating using RDNZL for my next project. I've started playing
> with it and am very impressed. I am interested in others peoples
> experiences with using for applications that work around tabular data,
> like a business application.
> 
> If you could point me to any screenshots of RDNZL work it would be much
> appreciated.
> 
> Regards,
> 
> Matthew
> 
> 
> _______________________________________________
> rdnzl-devel mailing list
> rdnzl-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-devel



Matthew O'Connor
Project Leader



5/486 Lower Heidelberg Road,
Melbourne, Victoria, 3084
Australia

T:
+ 61 3 9455 8609
F:
+ 61 3 9459 9966
E:
matthew.oconnor at calyptech.com
W:
http://www.calyptech.com

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This e-mail and any file attachments are confidential to the intended
recipient(s). The e-mail and any associated
attachments may contain copyright and/or legally privileged information.
No one but the intended recipient(s) may read,
print, store, copy or forward all or any of it or its attachments. If
you receive this e-mail in error, please notify the sender.
Calyptech does not accept any liability for any loss or damage that may
occur as a result of the transmission of this 
e-mail to the recipient(s)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/rdnzl-devel/attachments/20080225/79eba6be/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 5442 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/rdnzl-devel/attachments/20080225/79eba6be/attachment.jpg>

From edi at agharta.de  Mon Feb 25 02:52:30 2008
From: edi at agharta.de (Edi Weitz)
Date: Mon, 25 Feb 2008 03:52:30 +0100
Subject: [rdnzl-devel] Developer experience GUI applications.
In-Reply-To: <1203906971.7017.9.camel@localhost> (Matthew O'Connor's message
	of "Mon, 25 Feb 2008 02:36:11 +0000")
References: <1203398919.8498.31.camel@localhost>
	<1203906971.7017.9.camel@localhost>
Message-ID: <uve4drbm9.fsf@agharta.de>

On Mon, 25 Feb 2008 02:36:11 +0000, Matthew O'Connor <matthew.oconnor at calyptech.com> wrote:

> Judging by the massive response I got I could have chosen the wrong
> forum for my question. :-)

Or maybe nobody did what you were asking for until now.  Or maybe
someone did but is not allowed to talk about the application or to
show screenshots.  Or maybe they simply didn't do it because they have
more important things to do.  Or...


From matthew.oconnor at calyptech.com  Mon Feb 25 03:20:53 2008
From: matthew.oconnor at calyptech.com (Matthew O'Connor)
Date: Mon, 25 Feb 2008 03:20:53 +0000
Subject: [rdnzl-devel] Developer experience GUI applications.
In-Reply-To: <uve4drbm9.fsf@agharta.de>
References: <1203398919.8498.31.camel@localhost>
	<1203906971.7017.9.camel@localhost>  <uve4drbm9.fsf@agharta.de>
Message-ID: <1203909653.7017.14.camel@localhost>

Sorry for getting in the way. I'll look for another forum.

On Mon, 2008-02-25 at 03:52 +0100, Edi Weitz wrote:
> On Mon, 25 Feb 2008 02:36:11 +0000, Matthew O'Connor <matthew.oconnor at calyptech.com> wrote:
> 
> > Judging by the massive response I got I could have chosen the wrong
> > forum for my question. :-)
> 
> Or maybe nobody did what you were asking for until now.  Or maybe
> someone did but is not allowed to talk about the application or to
> show screenshots.  Or maybe they simply didn't do it because they have
> more important things to do.  Or...
> _______________________________________________