- rdnzl-announce@lists.common-lisp.net - mailman3.common-lisp.net

[rdnzl-announce] New version 0.9.5
by Edi Weitz 24 May '06

24 May '06

ChangeLog: Version 0.9.5 2006-05-24 Fixed delivery scripts and IMPORT statement for LW Download: http://weitz.de/files/RDNZL.tar.gz

1 0

[rdnzl-announce] New version 0.9.4
by Edi Weitz 18 Feb '06

18 Feb '06

On Sat, 18 Feb 2006 12:07:34 -0500, "Dan Muller" <s8ctxw402(a)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.

1 0

[rdnzl-announce] New version 0.9.3 (Was: (no subject))
by Edi Weitz 17 Feb '06

17 Feb '06

On Fri, 17 Feb 2006 00:49:16 -0500, "Dan Muller" <s8ctxw402(a)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.

1 0

[rdnzl-announce] New version 0.9.2 (Was: Problem with invoking static member)
by Edi Weitz 13 Feb '06

13 Feb '06

On Thu, 9 Feb 2006 14:20:59 -0500 (EST), Jim Sokoloff <jim(a)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.

1 0

[rdnzl-announce] New release 0.9.0 / Experimental support for SBCL
by Edi Weitz 01 Feb '06

01 Feb '06

ChangeLog: Version 0.9.0 2006-02-01 Experimental support for SBCL/Win32 Download: <http://weitz.de/files/RDNZL.tar.gz> Cheers, Edi.

1 1

[rdnzl-announce] Re: New versions 0.8.0/0.5.0
by Edi Weitz 16 Jan '06

16 Jan '06

On Mon, 16 Jan 2006 00:58:59 +0000, "lisp" <lisp(a)spikeisland.com> wrote: > I am happy to report that this works! Great! > If you run the function gc-test below in a LWW DLL image, you can > see the delegate adapter for the Click event being reclaimed and > releasing the closure from the callback hash table. > > If you open a process browser window *before* running this, you will > see the process created by LWW to handle the callback from .NET's gc > thread. Inspecting this process's arguments reveals > (rdnzl:%foreign-callable/releasedelegateadapter). This process is > used for all subsequent callbacks from the gc thread. If you kill > it, a new one will be created for the next gc callback. > > If you run this code in a conventional .exe LWW image you do not get > the callback from .NET's gc thread. Thanks for the detailed info. I'll try this tomorrow. > I have run into a further problem - with LWW this time I think. As > far as I can tell, LWW will occasionally run a foreign callback on > the wrong thread resulting in a stack overflow exception condition > being raised. With a form running in a new process and generating > event callbacks, the listener process occasionally reports a stack > overflow and shows the callback happening in *its* backtrace - > presumably confusing the stack check. I've not yet been able to > verify this or reproduce it reliably. > > Any thoughts or suggestions would be welcome... No idea. But it would be /very/ helpful if you could reproduce this and submit a bug report to LispWorks support. As you'll know they're currently working on the 5.0 release which will have some changes in the threading code as well. It'd be nice if they could fix that before they release the new version. Thanks again, Edi.

1 0

[rdnzl-announce] New versions 0.8.0/0.5.0 (was: bug in delegate adapter release mechanism)
by Edi Weitz 13 Jan '06

13 Jan '06

Hi Dominic! On Fri, 13 Jan 2006 00:29:08 +0000, "lisp" <lisp(a)spikeisland.com> wrote: > I've tracked down what looks to be a bug in the mechanism for > releasing delegate adapters. > > The foreign callable ReleaseDelegateAdapter is declared with a > return type of ffi-void-pointer but tries to return the result of > remhash - a boolean. On LWW (at least) this results in: > > Condition: T cannot be converted to foreign type :POINTER. Call to > SYSTEM::FOREIGN-CALLABLE-ENTRY-POINT-NEW-PROCESS-AUX (offset 21) > SYSTEM::FUNC : RDNZL::%FOREIGN-CALLABLE/RELEASEDELEGATEADAPTER > > I would suggest changing it (and the corresponding initialisation > and DLL code) to have a void return type: > > (ffi-define-callable (ReleaseDelegateAdapter ffi-void) > ((index ffi-integer)) ;; remove entry from hash table if CLR is done with it > (remhash index *callback-hash*)) > > Also, in DelegateAdapter.cpp you have a comment on the destructor > that it doesn't appear to be working: > > // the destructor notifies Lisp that this instance is no longer used - > // at least in theory, this doesn't seem to work right now > DelegateAdapter::~DelegateAdapter() { release(indexIntoLisp); } > > This may have beeen the caused by the callback/threading issues > discussed recently. At least it has certainly worked for me here > (hence this bug report) when using a DLL based LWW image (many > thanks for your recent example of this). Perhaps the .NET GC is > running in a different thread, so the callback was failing in a > normal .EXE image? Makes perfect sense to me. I've updated both the Lisp and the C++ code according to your recommendations - see ChangeLogs below. However, I'm a bit in a hurry and I couldn't figure out an easy example which shows that ReleaseDelegateAdapter is actually called - at least not from a DLL-based LWW image. Could you please check if it works and report back to the list if possible? Thanks a lot, Edi. Lisp code: ---------- Version 0.8.0 2006-01-13 Fix mechanism which releases delegate adapters (thanks to Dominic Robinson) Updated to DLL version 0.5.0 <http://weitz.de/files/RDNZL.tar.gz> C++ code (optional): -------------------- Version 0.5.0 2006-01-13 Fix mechanism which releases delegate adapters (thanks to Dominic Robinson) <http://weitz.de/files/RDNZL_cpp.tar.gz>

1 0

[rdnzl-announce] New version 0.7.1/0.4.1
by Edi Weitz 21 Nov '05

21 Nov '05

This fixes a bug where single floats were always boxed as double floats. Thanks to Andrew Wolven for catching it. <http://weitz.de/files/RDNZL.tar.gz> <http://weitz.de/files/RDNZL_cpp.tar.gz> Cheers, Edi.

1 0

[rdnzl-announce] New version 0.7.0
by Edi Weitz 08 Jul '05

08 Jul '05

Changelog: Version 0.7.0 2005-07-08 In WRAP-CLOSURE, prevent callbacks from being able to throw over .NET stack frames (Charles A. Cox) Modify UNMANGLE-NAME to work in case-preserving readtable-case mode (Charles A. Cox) Don't redefine in util.lisp what's already there (for LispWorks) Download: <http://weitz.de/files/RDNZL.tar.gz> Have fun, Edi.

1 0

[rdnzl-announce] New version 0.6.0
by Edi Weitz 03 Jan '05

03 Jan '05

Hi and Happy New Year! This new version of RDNZL has preliminary support for "direct calls" - see <http://weitz.de/rdnzl/#direct>. They currently don't work with Corman Lisp but we'll see... Here's the full Changelog entry: Version 0.6.0 2005-01-03 Support for "direct calls" Fixed typo (forgot RESOLVE-TYPE-NAME) in FIELD Fixed thinko in OR-ENUMS Make sure SETF accessors in container.lisp return NEW-VALUE Download: <http://weitz.de/files/RDNZL.tar.gz>. Here's the Changelog entry for the C++ source code: Version 0.4.0 2005-01-03 Added interface functions for "direct calls" Added ChangeType code to setDotNetContainerTypeFromString Download: <http://weitz.de/files/RDNZL_cpp.tar.gz>. Cheers, Edi.

1 1