Didier Verna | 24 Jan 11:09 2015
X-Face
Face
Picon
Picon
Picon
Picon

[2nd CfP] European Lisp Symposium 2015, April 20-21, London


		 ELS'15 - 8th European Lisp Symposium
		    Goldsmiths College, London, UK

			  April 20-21, 2015

	       http://www.european-lisp-symposium.org/

	  Sponsored by EPITA, Franz Inc. and Lispworks Ltd.

Recent news:

- Submission deadline in less than a month now!
- Programme committee has been announced (see below)
- Venue information now available on the web site

The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp and Lisp-inspired
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP,
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We
encourage everyone interested in Lisp to participate.

The 8th European Lisp Symposium invites high quality papers about
novel research results, insights and lessons learned from practical
applications and educational perspectives. We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.

Topics include but are not limited to:
(Continue reading)

Jared C. Davis | 20 Jan 01:48 2015
Picon

run-program with :error :stream?

Hi,

I'm new to ECL.  I have some questions about the ext:run-program.

According to the documentation at:

   http://ecls.sourceforge.net/new-manual/rn01re63.html

It sounds as though run-program can take :error :stream.  However, when I try
to run:

   (ext:run-program "echo" (list "hello")
                    :input :stream
                    :output :stream
            :error :stream)

I seem to hit an error:

   Debugger received error of type: SIMPLE-ERROR
   Invalid :ERROR argument to EXT:RUN-PROGRAM:
   :STREAM

Is there some other command I should use besides ext:run-program that might
allow me to get all three stdin/out/err streams?

I'm using x86-64 Linux with the ECL 13.5.1 release from the sourceforge project
page.  Perhaps I should use a newer version of ECL from Git?

Thanks!

Jared

--
Jared C. Davis <jared-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org>
11410 Windermere Meadows
Austin, TX 78759
http://www.cs.utexas.edu/users/jared/
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
daiyanh | 14 Jan 00:09 2015
Picon

Re: Runtime bug in compiled code

BTW recently the Windows API seemed have changed.
The following code, for example,
(baz "arabic" :format :iso-8859-6)
used to work just few months ago.  Now it doesn’t.  Instead this
(baz "arabic" :format :utf-8)
must be used.  Meaning input format is now utf-8 regardless of
encoding format of the original srt.
My setup is the same as before; nothing is changed.  Go figure…

Sent from Windows Mail

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Daniel Kochmański | 3 Jan 09:33 2015
Picon

[PATCH] ffi: implement si_unload_foreign_module

From: Daniel Kochmanski <dkochmanski <at> gmail.com>

Hey,

this patch adds support for si:unload-foreign-module, so it could be
called from cffi. For now cffi returns an error on unload call, what
prevents from loading libs which use it (for example IOlib).

In function ecl_library_close - I'm not sure if first condition is
ever met, because refcount doesn't increase on calling load-foreign-library.

After this patch is merged into ecl, I'll issue small patch to cffi to
actually use new functionality.

Best Regards,
Daniel Kochmański

---
 src/c/ffi.d           | 27 +++++++++++++++++++++++++++
 src/c/ffi/libraries.d | 18 +++++++++++++-----
 src/c/symbols_list.h  |  1 +
 src/c/symbols_list2.h |  1 +
 src/h/external.h      |  3 ++-
 5 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/src/c/ffi.d b/src/c/ffi.d
index 6adb964..24800e0 100644
--- a/src/c/ffi.d
+++ b/src/c/ffi.d
 <at>  <at>  -729,6 +729,33  <at>  <at>  si_load_foreign_module(cl_object filename)
 }

 cl_object
+si_unload_foreign_module(cl_object module)
+{
+#if !defined(ENABLE_DLOPEN)
+	FEerror("SI:UNLOAD-FOREIGN-MODULE does not work when ECL is statically linked", 0);
+#else
+	cl_object output = ECL_NIL;
+
+	if (ecl_unlikely(ecl_t_of(module) != t_codeblock)) {
+		FEerror("UNLOAD-FOREIGN-MODULE: Argument is not a foreign module: ~S ",
+                        1, module);
+        }
+# ifdef ECL_THREADS
+	mp_get_lock(1, ecl_symbol_value( <at> 'mp::+load-compile-lock+'));
+	ECL_UNWIND_PROTECT_BEGIN(ecl_process_env()) {
+# endif
+		if (ecl_likely(ecl_library_close(module))) output = ECL_T;
+# ifdef ECL_THREADS
+	(void)0; /* MSVC complains about missing ';' before '}' */
+	} ECL_UNWIND_PROTECT_EXIT {
+		mp_giveup_lock(ecl_symbol_value( <at> 'mp::+load-compile-lock+'));
+	} ECL_UNWIND_PROTECT_END;
+# endif
+	 <at> (return output)
+#endif
+}
+
+cl_object
 si_find_foreign_symbol(cl_object var, cl_object module, cl_object type, cl_object size)
 {
 #if !defined(ENABLE_DLOPEN)
diff --git a/src/c/ffi/libraries.d b/src/c/ffi/libraries.d
index 9adb734..26aaf3e 100644
--- a/src/c/ffi/libraries.d
+++ b/src/c/ffi/libraries.d
 <at>  <at>  -205,7 +205,7  <at>  <at>  dlopen_wrapper(cl_object block)
 		set_library_error(block);
 }

-static void
+static int
 dlclose_wrapper(cl_object block)
 {
         if (block->cblock.handle != NULL) {
 <at>  <at>  -219,7 +219,9  <at>  <at>  dlclose_wrapper(cl_object block)
                 FreeLibrary(block->cblock.handle);
 #endif
                 block->cblock.handle = NULL;
+		return TRUE;
         }
+	return FALSE;
 }

 static cl_object
 <at>  <at>  -419,18 +421,23  <at>  <at>  ecl_library_error(cl_object block) {
 	return block->cblock.error;
 }

-void
+bool
 ecl_library_close(cl_object block) {
         const cl_env_ptr the_env = ecl_process_env();
+	bool success = TRUE;
         ECL_WITH_GLOBAL_LOCK_BEGIN(the_env) {
                 ecl_disable_interrupts();
-                if (block->cblock.refs != ecl_make_fixnum(1)) {
+		/* is it ever a case? no matter how many times i call
+		   load-foreign-module it seems that block->cblock.refs = 1 */
+                if (block->cblock.refs > ecl_make_fixnum(1)) {
                         block->cblock.refs = ecl_one_minus(block->cblock.refs);
                         block = ECL_NIL;
                 } else if (block->cblock.handle != NULL) {
-                        GC_call_with_alloc_lock(dlclose_wrapper, block);
+                        success = GC_call_with_alloc_lock(dlclose_wrapper, block);
                         cl_core.libraries = ecl_remove_eq(block, cl_core.libraries);
-                }
+                } else {	/* block not loaded */
+			success = FALSE;
+		}
                 ecl_enable_interrupts();
         } ECL_WITH_GLOBAL_LOCK_END;
 	if (block != ECL_NIL && block->cblock.self_destruct) {
 <at>  <at>  -438,6 +445,7  <at>  <at>  ecl_library_close(cl_object block) {
                         unlink((char*)block->cblock.name->base_string.self);
                 }
         }
+	return success;
 }

 void
diff --git a/src/c/symbols_list.h b/src/c/symbols_list.h
index 47851b5..5a5f64c 100755
--- a/src/c/symbols_list.h
+++ b/src/c/symbols_list.h
 <at>  <at>  -1485,6 +1485,7  <at>  <at>  cl_symbols[] = {
 {SYS_ "FREE-FOREIGN-DATA", SI_ORDINARY, si_free_foreign_data, 1, OBJNULL},
 {SYS_ "MAKE-FOREIGN-DATA-FROM-ARRAY", SI_ORDINARY, si_make_foreign_data_from_array, 1, OBJNULL},
 {SYS_ "LOAD-FOREIGN-MODULE", SI_ORDINARY, si_load_foreign_module, 1, OBJNULL},
+{SYS_ "UNLOAD-FOREIGN-MODULE", SI_ORDINARY, si_unload_foreign_module, 1, OBJNULL},
 {SYS_ "NULL-POINTER-P", SI_ORDINARY, si_null_pointer_p, 1, OBJNULL},
 {SYS_ "SIZE-OF-FOREIGN-ELT-TYPE", SI_ORDINARY, si_size_of_foreign_elt_type, 1, OBJNULL},
 {SYS_ "ALIGNMENT-OF-FOREIGN-ELT-TYPE", SI_ORDINARY, si_alignment_of_foreign_elt_type, 1, OBJNULL},
diff --git a/src/c/symbols_list2.h b/src/c/symbols_list2.h
index 5d99c94..70fdd1a 100644
--- a/src/c/symbols_list2.h
+++ b/src/c/symbols_list2.h
 <at>  <at>  -1485,6 +1485,7  <at>  <at>  cl_symbols[] = {
 {SYS_ "FREE-FOREIGN-DATA","si_free_foreign_data"},
 {SYS_ "MAKE-FOREIGN-DATA-FROM-ARRAY","si_make_foreign_data_from_array"},
 {SYS_ "LOAD-FOREIGN-MODULE","si_load_foreign_module"},
+{SYS_ "UNLOAD-FOREIGN-MODULE","si_unload_foreign_module"},
 {SYS_ "NULL-POINTER-P","si_null_pointer_p"},
 {SYS_ "SIZE-OF-FOREIGN-ELT-TYPE","si_size_of_foreign_elt_type"},
 {SYS_ "ALIGNMENT-OF-FOREIGN-ELT-TYPE","si_alignment_of_foreign_elt_type"},
diff --git a/src/h/external.h b/src/h/external.h
index e3dee77..8b79f4a 100755
--- a/src/h/external.h
+++ b/src/h/external.h
 <at>  <at>  -618,7 +618,7  <at>  <at>  extern ECL_API cl_object ecl_make_codeblock();
 extern ECL_API cl_object ecl_library_open(cl_object filename, bool force_reload);
 extern ECL_API void *ecl_library_symbol(cl_object block, const char *symbol, bool lock);
 extern ECL_API cl_object ecl_library_error(cl_object block);
-extern ECL_API void ecl_library_close(cl_object block);
+extern ECL_API bool ecl_library_close(cl_object block);
 extern ECL_API void ecl_library_close_all(void);

 /* ffi/mmap.d */
 <at>  <at>  -650,6 +650,7  <at>  <at>  extern ECL_API cl_object si_null_pointer_p(cl_object f);
 extern ECL_API cl_object si_size_of_foreign_elt_type(cl_object tag);
 extern ECL_API cl_object si_alignment_of_foreign_elt_type(cl_object tag);
 extern ECL_API cl_object si_load_foreign_module(cl_object module);
+extern ECL_API cl_object si_unload_foreign_module(cl_object module);
 extern ECL_API cl_object si_find_foreign_symbol(cl_object var, cl_object module, cl_object type,
cl_object size);
 extern ECL_API cl_object si_call_cfun(cl_narg, cl_object fun, cl_object return_type, cl_object
arg_types, cl_object args, ...);
 extern ECL_API cl_object si_make_dynamic_callback(cl_narg, cl_object fun, cl_object sym, cl_object
return_type, cl_object arg_types, ...);
--

-- 
2.2.1

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Ecls-list mailing list
Ecls-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
daiyanh | 1 Jan 14:33 2015
Picon

Re: Runtime bug in compiled code

Another example from http://www.cliki.net/diff
In the diff.lisp file,

(defmacro do-file-lines ((line-var pathname-var &optional result) &body body)
  (let ((stream-var (gensym)))
    `(with-open-file (,stream-var ,pathname-var :direction :input
                      :element-type 'character)
      (do-stream-lines (,line-var ,stream-var ,result)
        , <at> body))))

(defun diff::intern-files (&rest files)
  (let ((interner (diff::make-interner))
        (interned-files nil))
    (dolist (file files (values interner (nreverse interned-files)))
      (let ((interned-file nil))
        (diff::do-file-lines (line file)
          (let ((code (diff::intern-string interner line)))
            (push code interned-file)))
        (push (coerce (nreverse interned-file) 'simple-vector) interned-files)))))

The compiled code refuses to run, presumably choking at the macro expansion above.
If I eval the lower diff::intern-files by c-x c-e, the code runs fine.

Sent from Windows Mail

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Polos Ruetz | 11 Dec 19:11 2014
Picon

EQL (ECL + Qt) in Slime: how it works

Hi,

this might be of common interest for ECL users, so please see attached
file if you want to know more.

Cheers,

Paul

EQL (ECL + Qt) in Slime -- how does it work?

  • Start swank using the EQL executable, running the swank server in an ECL thread, and using the main thread for the Qt main event loop.

  • Wrap every internal EQL function in a macro, which will call the function either directly (if called from GUI/main thread), or, if called from another ECL thread, will wrap the function call in a closure.

  • This closure will be passed to a queued, blocking Qt function running in the GUI thread, which will in turn call the closure.

The crucial part is passing a Lisp closure from an ECL thread to Qt and calling it from C++ in the GUI/main thread.

This is trivial in ECL/Qt, since both ECL and Qt use/wrap native C threads, and Qt offers a nice utility with Q_INVOKABLE.

First let's wrap the actual Lisp function, e.g. (foo x y) in a closure, so we only need to pass one ECL closure pointer to C++.

No need to pass Lisp arguments to C++, they are in the closure; no return value needed from C++, Lisp return values will be assigned in the closure:

;; in some ECL thread (let (values) (run-in-gui-thread ;; in ECL main/GUI thread (lambda () (setf values (multiple-value-list (foo x y))))) ;; back in some ECL thread (values-list values))

Here the implementation of the ECL function run-in-gui-thread (embedded in Qt):

cl_object run_in_gui_thread(cl_object closure) // define ECL function { QMetaObject::invokeMethod( caller, // any object from GUI thread "runInGuiThread", // see Q_INVOKABLE Qt::BlockingQueuedConnection, // blocking for return values Q_ARG(void*, closure)); // 'closure' is just a pointer return Cnil; }

Now the Lisp closure will run in the GUI/main thread, and the implementation of the Qt function runInGuiThread is as simple as:

Q_INVOKABLE void runInGuiThread(void* closure) // note Q_INVOKABLE { cl_funcall(1, (cl_object)closure); // ECL function call }

After introducing a macro qrun*, and wrapping all EQL functions int it (see "slime/thread-safe.lisp"), we are done!

(Please note that the above code is a stripped down version, see sources for the actual implementation.)


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Ecls-list mailing list
Ecls-list@...
https://lists.sourceforge.net/lists/listinfo/ecls-list
Didier Verna | 5 Dec 08:24 2014
Face
Picon
Picon
Picon
Picon

[CfP] ELS 2015, 8th European Lisp Symposium, Apr. 20-21, London


		 ELS'15 - 8th European Lisp Symposium
		    Goldsmiths College, London, UK

			  April 20-21, 2015

	       http://www.european-lisp-symposium.org/

	  Sponsored by EPITA, Franz Inc. and Lispworks Ltd.

The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp and Lisp-inspired
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP,
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We
encourage everyone interested in Lisp to participate.

The 8th European Lisp Symposium invites high quality papers about
novel research results, insights and lessons learned from practical
applications and educational perspectives. We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.

Topics include but are not limited to:

- Context-, aspect-, domain-oriented and generative programming
- Macro-, reflective-, meta- and/or rule-based development approaches
- Language design and implementation
- Language integration, inter-operation and deployment
- Development methodologies, support and environments
- Educational approaches and perspectives
- Experience reports and case studies

We invite submissions in the following forms:

  Papers: Technical papers of up to 8 pages that describe original
    results or explain known ideas in new and elegant ways.

  Demonstrations: Abstracts of up to 2 pages for demonstrations of
    tools, libraries, and applications.

  Tutorials: Abstracts of up to 4 pages for in-depth presentations
    about topics of special interest for at least 90 minutes and up to
    180 minutes.

  The symposium will also provide slots for lightning talks, to be
  registered on-site every day.

All submissions should be formatted following the ACM SIGS guidelines
and include ACM classification categories and terms. For more
information on the submission guidelines and the ACM keywords, see:
http://www.acm.org/sigs/publications/proceedings-templates and
http://www.acm.org/about/class/1998.

Important dates:

  - 22 Feb 2015: Submission deadline
  - 15 Mar 2015: Notification of acceptance
  - 29 Mar 2015: Early registration deadline
  - 05 Apr 2015: Final papers
  - 20-21 Apr 2015: Symposium

Programme chair:
    Julian Padget, University of Bath, UK

Local chair:
    Christophe Rhodes, Goldsmiths, University of London, UK

Programme committee:

    To be announced

Search Keywords:

#els2015, ELS 2015, ELS '15, European Lisp Symposium 2015,
European Lisp Symposium '15, 8th ELS, 8th European Lisp Symposium,
European Lisp Conference 2015, European Lisp Conference '15

--

-- 
My new Jazz CD entitled "Roots and Leaves" is out!
Check it out: http://didierverna.com/records/roots-and-leaves.php

Lisp, Jazz, Aïkido: http://www.didierverna.info

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Ecls-list mailing list
Ecls-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Arto Bendiken | 15 Oct 16:45 2014
Picon

Coverity Scan defect report for ECL

Good afternoon,

As noted to Matt in the other thread, I've registered the ECL project
with the Coverity Scan [1] static analysis cloud service—offered free
of charge to open-source projects—and have had them crunch through the
C portions of the code base.

Submitting a first build of HEAD to them yesterday, Coverity reported
639 defects [2]. I've triaged a number of the defects and thus far
eliminated or mitigated 23 of them through various means; see the
recent commits to HEAD. Note that in commit messages, CID means
Coverity ID—the identifier for a defect report in Coverity Scan.

The breakdown by category for the remaining 616 outstanding defect
reports is as follows:

• Control flow issues: 249
• API usage errors: 233
• Memory - illegal accesses: 83
• Uninitialized variables: 20
• Integer handling issues: 8
• Error handling issues: 8
• Code maintainability issues: 7
• Memory - corruptions: 3
• Insecure data handling: 1
• Null pointer dereferences: 1
• Incorrect expression: 1
• Security best practices violations: 1
• Resource leaks: 1

That perhaps looks more intimidating than is the reality. Many of
these are duplicate issues, i.e., the same class of report applies to
multiple locations in the code base. This is particularly the case for
defects reported in the generated C code under the build/ directory.

Also, a minority of the defect reports are false positives. To reduce
such cases, I've defined a so-called modeling file for Coverity Scan.
It's committed at src/c/coverity/model.c [3]. It could use some more
work to describe more of the ECL functions tagged with the
'ecl_attr_noreturn' attribute, which would reduce false positives
about missing return and break statements.

While I've tackled some of the lowest-hanging fruit, many of the
remaining defects are rather subtle, involving excessively convoluted
control flow. Coverity finds them because they trace execution through
all possible branches in the control flow graph, annotating the
problematic sequence of branches in the defect reports.

In one such case I partially addressed [4], I felt it risky to do more
than add a sanity-check assertion that will catch the uninitialized
pointer read if control should indeed ever flow in the unlikely(?)
sequence of branches identified by Coverity. Perhaps someone with more
experience with that piece of code can do better.

To view the defect reports and help quash these bugs, you can register
a free account with the Coverity Scan service and then request access
to the project there [2]. Unless there any objections, I would just go
ahead and give out access to anyone who asks to contribute to fixing
these issues. (In case there should be valid security concerns for
more restricted access, please do let me know soonest.)

Cheers,
Arto

[1] https://scan.coverity.com
[2] https://scan.coverity.com/projects/3235
[3] https://sourceforge.net/p/ecls/ecl/ci/03e4303ff8d76325036f4e603687a6d3dc36001b
[4] https://sourceforge.net/p/ecls/ecl/ci/633c3a5f63a602ce18c54bfe88922d8644cbe619

--

-- 
Arto Bendiken |  <at> bendiken | http://ar.to

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Ecls-list mailing list
Ecls-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Matthew Mondor | 15 Oct 00:44 2014
Picon

NUL-termination bug in SOCKET-BIND and SOCKET-CONNECT


> Fixed a NUL-termination bug in SOCKET-BIND and SOCKET-CONNECT. by Arto Bendiken http://sourceforge.net/p/ecls/ecl/ci/fa48714dd86d4bf2c3c1f0210cca3e7875771e92/
>
> http://sourceforge.net/p/ecls/ecl/ci/fa48714dd86d4bf2c3c1f0210cca3e7875771e92/tree/contrib/sockets/sockets.lisp?diff=633c3a5f63a602ce18c54bfe88922d8644cbe619
>
> The backslash in '\0' got lost on the way to the generated C file
> (build/ext/sockets.c). There may be more of these issues elsewhere
> in the code base.
> This resolves CIDs 66405 and 66413 (Buffer not null terminated).

Hmm this is quite peculiar...  it makes me wonder if it's not a
compiler issue.

I couldn't find bugs 66405/66413, where can I read these?  Thanks.

And thanks for working on improving ECL,
--

-- 
Matt

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Picon

Link .o or .so to a running ECL program

Hello all,

I am wondering if it is possible to link a pure C compiled file, in .o
or .so (or .dll) formats, into a running Lisp process and how I can do that.

The case is a am running ECL via Emacs+Slime and it would be very useful
to link some modules written in C to bind then via uffi or native ffi.

Regards,

JRM

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
Arto Bendiken | 21 Sep 16:38 2014
Picon

Patch queue housecleaning

Howdy,

In preparation for submitting some ECL patches of my own, I triaged
each of the patches currently in open/accepted state over at
SourceForge's patch tracker:

https://sourceforge.net/p/ecls/patches/

Looks like the patch queue could use some housecleaning, as the oldest
ticket has been open since 2010. My conclusions are as follows:

Tickets that can be closed as wont-fix, lacking a response from the
submitter for the past two years:

https://sourceforge.net/p/ecls/patches/8/

Tickets that can be closed because their attached patches have already
been merged previously:

https://sourceforge.net/p/ecls/patches/29/
https://sourceforge.net/p/ecls/patches/30/
https://sourceforge.net/p/ecls/patches/31/
https://sourceforge.net/p/ecls/patches/34/

Patches that ought to be merged, being trivial and obviously correct:

https://sourceforge.net/p/ecls/patches/33/
https://sourceforge.net/p/ecls/patches/37/

Patches that probably ought to be merged, but I'm not qualified to say:

https://sourceforge.net/p/ecls/patches/35/

In summary, with about 10 minutes of effort by someone with commit
bits and ticket admin privileges, the current patch queue could be
wholly emptied.

Cheers,
Arto

--

-- 
Arto Bendiken |  <at> bendiken | http://ar.to

------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk

Gmane