On Thu, 31 May 2012 23:57:11 +0400 red plait <redpl...@gmail.com> wrote:
> It seems that under xp (both 32 and 64 bit) elc.dll cannot be loaded > with LoadLibrary: http://redplait.blogspot.com/2012/05/ecldll.html > I think __declspec(thread) for GC_thread_key must be rewritten to use > explicit TLS allocation scheme to solve this problem I didn't know about your blog, but after reading the article ``"embeddable" cl'' I agree with Juan that it appears to be an unfair evaluation. Although a few issues might be directly ECL related, most didn't seem to be related to ECL... The "famous REPL" is probably SLIME, or simply the general fact that Lisp is designed to support live interactive development. About the debugger, SLIME also improves things there, and is used by most lispers. Lisp also allows you to hook in your own debugger if you cared to, it's a standard feature of the language to allow this, ECL is no different, and SLIME exploits this feature. If you compile to C, you also have access to the C debugger of your implementation. You even have access to the C generated source if you use (setf c::*delete-files* nil) before building your project. It's possible that the bytecode be more easy to debug using the native debugger than C-compiled code. I know of no implementation including CFFI, most either provide UFFI or their own more specialized FFI implementation, such as ECL which supports both UFFI natively and directly embedded C code elegantly (ECL deserves its name here, BTW, see the symbols of the FFI and C packages, and the documentation on the web site). Or install CFFI and its dependencies. ECL can also build decently sized final executables or libraries, one of its strong points (also doing its name justice). Other than being embeddable in a C/C++ application. Quicklisp is one of the attempts at providing easily installable third party software. It's not part of the implementations that I know, but is third party software. Note that unlike Ruby or Perl, Common Lisp is a standard, like C, with multiple implementations. A lot of in-house software is closed source or implementation-dependent, and the language is powerful enough to allow quick development of custom libraries. A fraction of libraries were developed to be portable accross implementations and publically distributable, and it is more work involved for a small community to include every wanted feature in portable, easy to install libraries, in a common repository, as the community is fragmented accross both implementations and ideology. Over time, however, the collection grows and with a tool like Quicklisp it might get closer. And even if Quicklisp exists, not all lispers use it, it's not a standard. The aforementionned SLIME is also not a standard, and some commercial Lisp implementations offer sophisticated GUI IDEs. Registry access and OLE automation and VS integration? You seem to be looking for .Net or an implementation that depends on it, or for a commercial implementation with particularily good Windows support. Although you might want to consider Clojure or ABCL, if some Java implementation has already what you need (I hear that there's an effort to support the .Net common runtime for Clojure too). For all these Windows integration features, there has to be a decent financial incentive. As far as I know, this is neither a commercial project with the funds and workforce necessary, nor a Windows-centric implementation, although there is effort to support Windows for the basic features ECL provides, like threads, sockets and unicode which are expected in a modern Lisp implementation (these are not even part of the standard requirements). Also, ECL attempts to be easily portable, and most OS-specific extra functionality it could include would not be portable elsewhere (there is POSIX for that, yet Windows requires extra software to comply, and POSIX has no notion of those Windows features). Registry access and OLE are exemples of features that wouldn't benefit ECL on other systems, and are best provided as contribution libraries. Consider ECL as a building block, not a panacea. Although I decided to reply, I won't keep on debating after this post (or reading the blog, not particularily yours, there are very few I track), but I thought that the necessary minutes of my time to type this might perhaps be worth it, assuming all you needed were clues to find what you need. If you already knew all of the above, please accept my apologies, but it was not evident from what I read. It's also possible that ECL (or Lisp) is not what you need, it'll be for you to decide. Note that I don't officially represent the project and am only one of its users. As such, Juan, please feel free to correct my claims as needed :) -- Matt ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
