November 2015 - ecl-devel - mailman3.common-lisp.net

Re: [Ecls-list] threading failures
by Daniel Kochmański 22 Jan '16

22 Jan '16

Hello, that's probably my fault, sorry. I've migrated bugs manually and probably missed this one (I remember this bug! but can't find anywhere). I'm adding it to regression tests in repository, thanks! Yes, old reports are unfortunately lost. As a sienote, please use ecl-devel(a)common-lisp.net mailing list – I'm closing the old one today. You can subscribe here https://mailman.common-lisp.net/listinfo/ecl-devel . All archives before 2015-08-10 are imported to the new one and gmane stream is redirected (if you use it). Regards, Daniel James M. Lawrence writes: > Hello, the threading bugs I reported a while ago appear to have not > survived the migration from sourceforge, and the old pages are now > 404'd. There were a number of test cases, including > > (defun test (message-count worker-count) > (let ((to-workers (mp:make-semaphore)) > (from-workers (mp:make-semaphore))) > (loop repeat worker-count > do (mp:process-run-function > "test" > (lambda () > (loop > (mp:wait-on-semaphore to-workers) > (mp:signal-semaphore from-workers))))) > (loop > (loop repeat message-count > do (mp:signal-semaphore to-workers)) > (loop repeat message-count > do (mp:wait-on-semaphore from-workers)) > (assert (zerop (mp:semaphore-count to-workers))) > (assert (zerop (mp:semaphore-count from-workers))) > (format t ".") > (finish-output)))) > > (defun run () > (test 10000 64)) > > RUN will eventually hang on all versions of ECL I've tried, including > the latest. Another test case was a variant of the above using a > homemade semaphore. I can rewrite that and other test cases, but > before doing so I'd like to know whether the old reports are really > lost or have survived in some form. > > Best, > lmj > > ------------------------------------------------------------------------------ > _______________________________________________ > Ecls-list mailing list > Ecls-list(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ecls-list -- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi

3 11

Re: Inspecting intermediate C files
by Daniel Kochmański 26 Nov '15

26 Nov '15

Hi, I'm not sure if I miss something, but this mail seems to be sent to the ecl-devel-owner(a)common-lisp.net . Correct ML address is ecl-devel(a)common-lisp.net . I'm fast forwarding the mail there. Brian Beckman writes: > Hello -- > > I am experimenting with ECL for actual embedded applications > (in the sense of "embedded systems," i.e., small computers running > disconnected controller software. > > The hardware team insists on inspecting the generated C code from > the ECL compiler. I found, in the ECL manual, directions for > producing .o files, .a files, .fasl files, and standalone executables. > I also found prose that says that it is possible to emit the > actual .c and .h files. However, I can't find instructions on how > to emit the actual .c and .h files. Generated code is readable, but it's a generated code after all. It's not pretty. > > I can (compile-file "hello.lisp" :system-p t), but that produces > only a .o file. I need to see the .c and .h files. My hardware > team won't permit ECL-generated code until they can visually read > and inspect the generated .c and .h files. To prevent ECL from deleting these intermediate files you need to set special variable c::*delete-files* to nil. (setf c::*delete-files* nil) Intermediate files are *.c, *.h and *.data . The last one contains some untranslatable expressions (rare occasion – if you work with infinities for instance) and debugging/reflection information (like the path to the source file). This problem has been tacled by Earl Ducaine here: https://github.com/earl-ducaine/stupid-ecl-tricks-1 . > > Can you help me figure out how to generate them? I can't find > the instructions in the manual. I am starting to read the source > code, but perhaps you can give me correct pointers into the manual > or some other kind of instructions. I'm now in-process of revising manual and rewriting it into texi sources. I'll keep in mind to document this. It would be great if you could file an issue on gitlab.com/embeddable-common-lisp/ecl/issues (with the label "documentation"). Thanks! > > Thanks! Regards, Daniel -- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi

2 1

iolib and close
by Alessandro Serra 26 Nov '15

26 Nov '15

Dear all, compiling "iolib-tests" I received the following error: #<IPv4 datagram socket, closed 00000000050f3660> is not of type STREAM. [Condition of type TYPE-ERROR] I have seen that in "clos/streams.lsp" the following method is defined: (defmethod close ((stream t) &key abort) (declare (ignore abort)) (bug-or-error stream 'close)) Removing the method above with: (remove-method #'gray:close (find-method #'gray:close '() '(t))) I was able to compile iolib-tests and run the tests. Did 71 checks. Pass: 59 (83%) Skip: 0 ( 0%) Fail: 12 (16%) Regards, Alessandro

2 1

ffi:defcallback with cxx
by hiro hiro 14 Nov '15

14 Nov '15

Hello, I compiled ecl16.0.0 with option "--with-cxx". Then I use ffi:defcallback function like (ffi:defcallback yyyy :void () ..... ) then compile-file (compile-file "xxxxx.lisp" :c-file "xxxxx.cpp" :system-p t) I received error message as follows (freebsd10.1 clang++) xxxxx.cpp:162:8: error: no matching function for call to 'ecl_make_foreign_data' T0 = ecl_make_foreign_data(ECL_SYM("POINTER-VOID",1381),0,ecl_callback_0) I try as follows in src/cmp/cmpcbk.lsp & src/new-cmp/cmpc-cbk.lsp line 44 from: ,(format nil "ecl_make_foreign_data(@':pointer-void,0,~a)" c-name) to: ,(format nil "ecl_make_foreign_data(@':pointer-void,0,(void*)~a)" c-name) after that, I did not receive error message and ffi:callback work fine. Would you let me know what your thoughts are on this matter. hirohiro447

4 4

[ecl-android v0.0.1]
by Daniel Kochmański 10 Nov '15

10 Nov '15

Dear all, for the last few weeks I was working on the ECL Android integration. I've managed to create a basic app which is swank-capable. More info here: https://common-lisp.net/project/ecl/ I'll appreciate all the feedback :) Regards, Daniel -- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi

4 12

ECL & IPhone Port
by Evrim Ulu 07 Nov '15

07 Nov '15

Dear List, I've been one of the Android port and I am glad to see that Daniel is working in order to merge the port into the master branch soon. I know that he's building other nice perks for Android devs. In the meantime, I would like to proceed into building a sound IPhone port. In this regard, I am looking for capital to fund the development. Please contact me if you like to see support for IPhone platform on the master branch. Best, evrim.

1 0

GC and Threading
by Bix 06 Nov '15

06 Nov '15

Hi, just two quick question: 1. Is it possible to disable the threading model and have multiple thread to eval the code or have one ECL per thread? 2. Can the garbage collector be disabled at all and have the memory managed in a reference counting fashion? I like to embed the ECL in my multithread application but I've got very restrictive constrain about thread and memory: * I can not spawn new thread but I've got concurrent thread to execute ecl call. * A component that bring GC would probably not be accepted and I'm wondering if there is an alternative to that in ECL, or at least have more control how/when GC will be run. Can you point me out where to look in the source code to understand those aspect of ECL? Thanks in advance. f.

5 7