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

[rdnzl-devel] Re: New version 0.10.4
by Edi Weitz 05 Sep '06

05 Sep '06

Hi Michael! On Mon, 4 Sep 2006 12:26:03 +0200, "Goffioul Michael" <goffioul(a)imec.be> wrote: > BTW, another function improvement idea: I got to a situation where I > needed to import a type from an assembly whose DLL name didn't match > the namespace name, hence I couldn't use import-types. However, as > import-type requires an assembly object, I had to load it manually. > This is not a big deal, just annoying. Would it be possible to > provide a more flexible type importing function where you could > easily decouple the DLL and namespace names? (for instance by adding > an ":assembly" keyword to the import-types function) Yeah, I think that should be no big deal. I can do it, but not in the next days because I'm busy with other things. Feel free to submit a patch (preferably with updated documentation) in the meantime... :) Cheers, Edi.

1 0

[rdnzl-devel] FW: [Fwd: example apropos.lisp failed to load in ECL]
by Goffioul Michael 04 Sep '06

04 Sep '06

________________________________ From: Dean O'Connor [mailto:dean.oconnor@ite.com.au] Sent: Wednesday 30 August 2006 17:10 To: Goffioul Michael Subject: [Fwd: example apropos.lisp failed to load in ECL] hello michael I subscribe to the ECL mail list and was having a look at RDNZL. Pretty cool stuff. I just noticed an loading error for one of the examples. I tried to send the below info to the mail list but got rejected cause I wasn't subscribed - and don't really want to for just this one small thing. I assume you are, and was wondering if you'd mind posting this sometime. ps. I was very impressed by RDNZL. One of the few lisp packages I've downloaded and run (as per documentation) without hassle in ECL. cheers dean. -------- Original Message -------- Subject: example apropos.lisp failed to load in ECL Date: Thu, 31 Aug 2006 00:49:08 +1000 From: Dean O'Connor <dean.oconnor(a)ite.com.au> <mailto:dean.oconnor@ite.com.au> To: rdnzl-devel(a)common-lisp.net hello just trying out your RDNZL examples with ECL and noticed that apropos.lisp failed to load. RDNZL-USER> (load "examples/apropos.lisp") ;;; Loading "F:/projects/lisp/RDNZL-0.10.3/examples/apropos.lisp" (:CORMANLISP :ECL) is not a valid feature expression. Broken at LOAD. RDNZL-USER>> This change worked for me in ECL. In function copy-to-clipboard, I changed this line: #+(:cormanlisp :ecl) (setq apropos-text (lf-to-crlf apropos-text)) to this: #+(or :cormanlisp :ecl) (setq apropos-text (lf-to-crlf apropos-text)) Cheers deano

2 1

[rdnzl-devel] New release 0.10.3
by Edi Weitz 25 Aug '06

25 Aug '06

ChangeLog: Version 0.10.3 2006-08-25 Added Excel example Fixed bug in AREF* Changed package handling in system definition (thanks to Christophe Rhodes) Download: http://weitz.de/files/RDNZL.tar.gz Cheers, Edi.

1 0

[rdnzl-devel] New version 0.10.2
by Edi Weitz 10 Aug '06

10 Aug '06

Sorry, next one... ChangeLog: Version 0.10.2 2006-08-10 More DSPEC definitions for LispWorks Download: http://weitz.de/files/RDNZL.tar.gz These changes only affect LispWorks users.

1 0

[rdnzl-devel] New version 0.10.1
by Edi Weitz 10 Aug '06

10 Aug '06

ChangeLog: Version 0.10.1 2006-08-10 DSPEC definitions for LispWorks Download: http://weitz.de/files/RDNZL.tar.gz These changes only affect LispWorks users who want to browse the RDNZL source code.

1 0

[rdnzl-devel] Re: RDNZL-cpp for Visual C++ 2005
by Edi Weitz 12 Jun '06

12 Jun '06

The previously reported problem with COM Interop http://common-lisp.net/pipermail/rdnzl-devel/2006-June/000094.html was solved by Michael by recompiling the C++ code (after porting it to a newer version of Visual Studio). If you're interested in using the C++ code with VS 2005, Michael's port is available here: http://weitz.de/files/RDNZL-cpp-0.5-vc8.tar.bz2 Below is his description of what had to be changed. Cheers, Edi. On Fri, 9 Jun 2006 16:53:31 +0200, "Goffioul Michael" <michael.goffioul(a)swing.be> wrote: > I don't know if you're interested, but I ported the RDNZL C++ library to > visual c++ 2005 (express edition) (aka msvc8). I did it because I needed > to change the default threading attribute of the DLL to single mode, > which > required re-compilation, and I only had that version of the compiler. > As far as I could test it, it works (I tested it with a project of mine > and > ECL). As of this compiler version, a lot of CLR related stuffs have > changed. > Most of the modifications I had to do were: > - replace *-pointer to managed object to ^-pointer > - replace C-style array of managed objects to cli::array<type^> objects > - replace the use of '0' as null pointer to managed object with > 'nullptr' > - replace __gc class attribute with ref > - remove __nogc attribute (according to the doc, it's not needed > anymore) > - replace __pin attribute with pin_ptr<type> objects > - use safe_cast for managed object casting > - create String^ object explicitely from __wchar_t* > - replace "new" on managed type with "gcnew" > - slightly change how GCHandle references are used, because the compiler > counldn't find the op_explicit() member in GCHandle class > - remove the tricks that were required to avoid dead-lock when loading a > mixed assembly > - problably other small things I don't remember

1 0

[rdnzl-devel] Re: Problem using RDNZL with COM Interop
by Edi Weitz 12 Jun '06

12 Jun '06

Hi Michael! On Thu, 8 Jun 2006 10:16:49 +0200, "Goffioul Michael" <goffioul(a)imec.be> wrote: > I'm trying to use RDNZL im my project (for the GUI) and I faced a > problem related to COM interop (I think). The symptom is the > following: in my assembly for the GUI, I use FolderBrowserDialog to > request a directory from the user; however when the dialog appear, > the directory tree is not present and the dialog only contains 3 > buttons; looking on the web and testing a little, it appears that > it's due to the fact that the main program does not use > single-thread apartment state (STAThreadAttribute), which is > required with some COM components. > > While, it's well explained how to set this attribute in a plain > C#/C++ application, this is less evident in the context of RDNZL as > I don't know where is exactly the "main entry point" for the managed > part of the code. In recent version of VC compiler (VC++-2005), > there's a /CLRTHREADATTRIBUTE flag to specify it, however I couldn't > recompile the RDNZL library with such a compiler, because apparently > lot of things have been deprecated since VC++-2003 regarding managed > code in DLL. > > Would you have any solution for this problem? Thanks. I don't have an immediate fix for this, so I'm forwarding your question to the RDNZL mailing list - maybe someone there knows what to do. Cheers, Edi.

1 0

[rdnzl-devel] New version 0.10.0 (ECL support)
by Edi Weitz 12 Jun '06

12 Jun '06

ChangeLog: Version 0.10.0 2006-06-12 ECL port (provided by Michael Goffioul) Download: http://weitz.de/files/RDNZL.tar.gz

1 0

[rdnzl-devel] 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-devel] Arbitary path for assembly
by Oyvin Halfdan Thuv 25 Apr '06

25 Apr '06

I saw an earlier post about importing assemblies from an arbitary path. The answer was to tell the CLR where to look for it. Does anyone know how to do that? For now I get e.g. "Assembly "AproposGUI" not found" when loading the apropos example (no matter where I copy the dll). -- Øyvin

2 4