February 2008 - rdnzl-devel@common-lisp.net

[rdnzl-devel] Rdnzl Problem
by Michael Mills 25 Mar '08

25 Mar '08

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.

3 11

[rdnzl-devel] Developer experience GUI applications.
by Matthew O'Connor 25 Feb '08

25 Feb '08

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

2 3

[rdnzl-devel] Patch for generic types in RDZNL
by Iver Odin Kvello 19 Feb '08

19 Feb '08

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

2 8

[rdnzl-devel] Resolving assemblies in user-defined paths from lisp now works
by Iver Odin Kvello 14 Feb '08

14 Feb '08

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

2 1

[rdnzl-devel] Re: RDNZL problem
by Michael Mills 04 Feb '08

04 Feb '08

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.

2 2