- mkcl-devel - mailman3.common-lisp.net

compile on arm
by Tomas Hlavaty 15 Oct '15

15 Oct '15

Hi, I get an error when compiling on ARM: gcc -L/nix/store/s2ldc3kwqwmiiags6pjibwdjlwdhbs8w-gmp-5.1.3/lib -o mkcl_min c/cinit.o c/all_symbols.o mkclmin.a mkclgc.a -lgmp -pthread -lrt -ldl -lm mkclmin.a(ffi.o): In function `mkcl_fficall_prepare': /tmp/nix-build-mkcl-1.1.9.drv-0/mkcl-86768cc/src/c/ffi.d:729: undefined reference to `mkcl_fficall_prepare_extra' mkclmin.a(ffi.o): In function `mk_si_call_cfun': /tmp/nix-build-mkcl-1.1.9.drv-0/mkcl-86768cc/src/c/ffi.d:788: undefined reference to `mkcl_fficall_push_arg' /tmp/nix-build-mkcl-1.1.9.drv-0/mkcl-86768cc/src/c/ffi.d:792: undefined reference to `mkcl_fficall_execute' mkclmin.a(ffi.o): In function `mk_si_make_dynamic_callback': /tmp/nix-build-mkcl-1.1.9.drv-0/mkcl-86768cc/src/c/ffi.d:810: undefined reference to `mkcl_dynamic_callback_make' collect2: error: ld returned 1 exit status Makefile:258: recipe for target 'mkcl_min' failed make[1]: *** [mkcl_min] Error 1 make[1]: Leaving directory '/tmp/nix-build-mkcl-1.1.9.drv-0/mkcl-86768cc/src' Makefile:86: recipe for target 'all' failed make: *** [all] Error 2 builder for ■/nix/store/jc4fcn4vnmj9zbid9xkr9cg5kfy36yav-mkcl-1.1.9.drv■ failed with exit code 2 Any ideas what could be wrong? It works with the same build configuration on x86_64. Regards, Tomas

2 2

Cannot open file "/dev/urandom" OS Explanation: (errno == 0) Success
by Tomas Hlavaty 22 Apr '15

22 Apr '15

Hi Jean-Claude, it is not possible to open /dev/urandom: (with-open-file (s "/dev/urandom" :element-type '(unsigned-byte 8)) (read-byte s)) Filesystem error with pathname: "/dev/urandom". Cannot open file OS Explanation: (errno == 0) Success [Condition of type SI:OS-FILE-ERROR] but this works: (with-open-file (s "/etc/passwd" :element-type '(unsigned-byte 8)) (read-byte s)) Thank you, Tomas

2 3

Re: a few issues
by Jean-Claude Beaudoin 20 Apr '15

20 Apr '15

Hello Tomas, Most of your issues should be fixed now in git master head (on github). On Mon, Apr 6, 2015 at 2:50 AM, Tomas Hlavaty <tom(a)logand.com> wrote: > Hi Jean-Claude, > > thanks for your quick reply. I have tried with the latest git commit > 7ac4fb07d43418c1b8ce3876584aadb22850b1da again and here are some notes. > > Jean-Claude Beaudoin <jean.claude.beaudoin(a)gmail.com> writes: > > On Sun, Apr 5, 2015 at 3:31 PM, Tomas Hlavaty <tom(a)logand.com> > > 1) there is a bug in coerce: > > > > (coerce #(1 2 3) 'list) => (3 2 1) > > > > This is a known bug in mkcl-1.1.9 (and a few previous minor versions). > > Fixed in current git head (future mkcl-1.1.10). > > This now works, thank you! > > > 2) what is the status of slime with mkcl? The swank backend which > > comes with the latest slime works except a few things: > > > > a) when I recompile a function/macro (C-c C-c), i get an error > > about an integer not being a stream; maybe stream/fd issue? > > > > 15482 is not of type STREAM. > > > > Sounds bad. I'll try to look into it. Do you have a more precise > > /concise test case code for this? (BTW, I usually recompile a whole > > file at a time since it generates better code through file scoped > > optimizations) > > With the latest mkcl, after starting mkcl from slime, i now get > > #<a SWANK/GRAY::SLIME-OUTPUT-STREAM 140431551121664> is not of type STREAM. > [Condition of type TYPE-ERROR] > > Restarts: > 0: [ABORT] Abort this computation: (SI:TOP-APPLY #<compiled-closure > 7fb8bd2cb3c0>). > 1: [TERMINATE-THREAD] Terminate this thread: #<thread "auto-flush-thread" > active detached (14806) 0x7fb88b7ae700 7fb8bd5b6000>. > > Backtrace: > 0: DEBUG-IN-EMACS > 1: LAMBDA, closure generated from INVOKE-SLIME-DEBUGGER > 2: LAMBDA, closure generated from INVOKE-SLIME-DEBUGGER > 3: CALL-WITH-BINDINGS > 4: INVOKE-SLIME-DEBUGGER > 5: LAMBDA, closure generated from SWANK-DEBUGGER-HOOK > 6: SWANK-DEBUGGER-HOOK > 7: AUTO-FLUSH-LOOP > 8: LAMBDA, closure generated from OPEN-STREAMS > 9: LAMBDA, closure generated from SPAWN > 10: NIL > > but after hitting #\q the slime debugger closes and slime works. This > error did not pop up with mkcl 1.1.9 and is new on the HEAD. > > Should be fixed in git head. Not really a new bug, just revealed itself on that occasion... > Pressing C-c C-c on a function (compile function in slime), I get: > > 1462 is not of type STREAM. > [Condition of type TYPE-ERROR] > > Restarts: > 0: [ABORT] Abort compilation. > 1: [*ABORT] Return to SLIME's top level. > 2: [ABORT] Abort this computation: (SI:TOP-APPLY #<compiled-closure > 7fb8a4c95d20>). > 3: [TERMINATE-THREAD] Terminate this thread: #<thread "worker" active > detached (17554) 0x7fb89e70c700 7fb8a460b000>. > > Backtrace: > 0: DEBUG-IN-EMACS > 1: INVOKE-SLIME-DEBUGGER > 2: LAMBDA, closure generated from SWANK-DEBUGGER-HOOK > 3: SWANK-DEBUGGER-HOOK > 4: LAMBDA, closure generated from SWANK-COMPILE-STRING > 5: LAMBDA, closure generated from LAMBDA > 6: LAMBDA, closure generated from COLLECT-NOTES > 7: MEASURE-TIME-INTERVAL > 8: COLLECT-NOTES > 9: LAMBDA, closure generated from COMPILE-STRING-FOR-EMACS > 10: CALL-WITH-BUFFER-SYNTAX > 11: COMPILE-STRING-FOR-EMACS > 12: BYTECODE [Evaluation of: ] > 13: EVAL-FOR-EMACS > 14: LAMBDA, closure generated from LAMBDA > 15: CALL-WITH-BINDINGS > 16: LAMBDA, closure generated from LAMBDA > 17: CALL-WITH-BINDINGS > 18: LAMBDA, closure generated from SPAWN-WORKER-THREAD > 19: LAMBDA, closure generated from SPAWN > 20: NIL > > I usually recompile functions only, as optimisations are not interessant > for me during development and also compiling the whole file via slime > leaves fasls around in the wrong places. > > I am not sure how could I make the test case more precise. Simply hit > C-c C-c on a lisp function when in slime-mode and this will pop up. > Should be fixed in git head. > > > b) trace doesn't seem to work; maybe not a slime issue but a > > general mkcl issue? > > > > cl:trace is tied to the bytecode compiler (more or less a.k.a. "the > > interpreter") which in turn is currently on the chopping block. The > > future of the current cl:trace code is therefore quite bleak. (It is > > pretty much a bad piece of legacy that really needs to be redone if > > you want my opinion.) > > OK but it is a shame, because cl:trace is one of the most useful > debugging tools in Lisp. > BTW, are you sure you turned off any "trace preventing" optimization before trying cl:trace? You need to have done the equivalent of (proclaim '(optimize (debug 3) (safety 3) (speed 1)) before compilation of any code that you expect to trace through, otherwise there may be some inlining or "fast-call" done by the compiler that will prevent good use of cl:trace. > > > I know that there is a slime in the mkcl sources (does it work > > better than the latest slime from git?), but it is really > > inconvenient to have separate slime just for mkcl. > > > > The code of my adaptation of slime for mkcl (the one in mkcl sources) > > got partially pushed into the main slime git repository a few months > > ago without my personal involvement, I discovered this situation while > > reading the slime release notes. I have yet to audit the merged code > > and try to get the missing pieces accepted into the main slime code > > line. I'll try to do this for the release of mkcl-1.1.10. > > I see. That would be great. > > > 3) I have issues with mkcl:run-program; which somehow > > returns > > > > (values #<two-way stream> nil nil) > > > > What is the exact code that produces this result? Somehow I cannot > > remember how to get "nil" as second and third value. For my part I > > always get a process tracking object as second value and a fixnum as > > third value. > > > > which seems rather odd. I haven't debugged the issue > > completely yet, as tracing doesn't seem to work on > > mkcl:run-program but if i run the same command from the slime > > repl with multiple-value-list, i get > > > > (values #<two-way stream> #<process> nil) > > > > Are there known issues with mkcl:run-program? > > > > Again, how do you get "nil" as third value? All I get is a > > fixnum in that position. > > Your exact testcase code? > > I think specifying ":wait nil" will get you NIL as third value: > > (multiple-value-list (RUN-PROGRAM "sha1sum" '("/etc/passwd") :INPUT > NIL :OUTPUT :STREAM :ERROR NIL :WAIT NIL :SEARCH T)) > > The problem I am seing is that I get nil as the second value. I haven't > identified the issue yet. > I more carefully re-read the code of mkcl:run-program and I can now say that NIL as third value is indeed a "feature" of asynchronous execution (:wait nil). But what I cannot understand is NIL as second value of mkcl:run-program; It should be impossible to get that, ever, by construction. Do you have an easy way to reproduce that case? Regards, Jean-Claude

2 5

a few issues
by Tomas Hlavaty 06 Apr '15

06 Apr '15

Hi, 1) there is a bug in coerce: (coerce #(1 2 3) 'list) => (3 2 1) 2) what is the status of slime with mkcl? The swank backend which comes with the latest slime works except a few things: a) when I recompile a function/macro (C-c C-c), i get an error about an integer not being a stream; maybe stream/fd issue? 15482 is not of type STREAM. b) trace doesn't seem to work; maybe not a slime issue but a general mkcl issue? I know that there is a slime in the mkcl sources (does it work better than the latest slime from git?), but it is really inconvenient to have separate slime just for mkcl. 3) I have issues with mkcl:run-program; which somehow returns (values #<two-way stream> nil nil) which seems rather odd. I haven't debugged the issue completely yet, as tracing doesn't seem to work on mkcl:run-program but if i run the same command from the slime repl with multiple-value-list, i get (values #<two-way stream> #<process> nil) Are there known issues with mkcl:run-program? Thank you, Tomas

2 1

external process status
by Tomas Hlavaty 28 Mar '15

28 Mar '15

Hi, is there something like ext:external-process-status / sb-ext:process-status / ccl:external-process-status on mkcl? Thank you, Tomas

2 2

[Mkcl-devel] Metaclass migration is not an error! Was: [Asdf-devel] Program with metaclass on MKCL.
by Jean-Claude Beaudoin 05 Dec '14

05 Dec '14

On Thu, Dec 4, 2014 at 11:06 PM, Jean-Claude Beaudoin < jean.claude.beaudoin(a)gmail.com> wrote: > > On Thu, Dec 4, 2014 at 5:20 AM, D. Martinez <denis.martinez(a)live.com> > wrote: > >> Hello. Being new to "serious" CL programming I am hitting a brick wall >> right now in one CLOS project. >> After some time of infructuous searching I cannot find the source of my >> problem, which may be of either MKCL or ASDF but I lack the knowledge to >> debug this. Mr. JCB, who I have seen active on this list, may (hopefully!) >> be able to shed some light on the issue. >> >> > This is definitely a MKCL 1.1.X bug, and one of the "unexpected > consequence" variety. ASDF is not concerned by this problem. It may have > helped in revealing the issue but nothing more, and it played only an > incidental role in the matter. > > > I further checked the ANSI CL spec along with the MOP spec and I could not find any justification in them for signaling an error when migrating a class from one metaclass to another. MKCL inherited this error signaling behavior from its original fork away from ECL and I fail to understand the reason for its existence. Therefore I simply removed it and adjusted the rest of the surrounding method accordingly. This change is now on the MKCL git repo master head. With this modification your sample code compiles and loads without error, as is, and without any further adjustment to MKCL. Cheers, JCB

1 0

Re: [Mkcl-devel] [Asdf-devel] Program with metaclass on MKCL.
by Jean-Claude Beaudoin 05 Dec '14

05 Dec '14

On Thu, Dec 4, 2014 at 5:20 AM, D. Martinez <denis.martinez(a)live.com> wrote: > Hello. Being new to "serious" CL programming I am hitting a brick wall > right now in one CLOS project. > After some time of infructuous searching I cannot find the source of my > problem, which may be of either MKCL or ASDF but I lack the knowledge to > debug this. Mr. JCB, who I have seen active on this list, may (hopefully!) > be able to shed some light on the issue. > > This is definitely a MKCL 1.1.X bug, and one of the "unexpected consequence" variety. ASDF is not concerned by this problem. It may have helped in revealing the issue but nothing more, and it played only an incidental role in the matter. This bug is fixed in MKCL 1.2.0 (currently only in my own private branch) but I do not plan to back port this fix to MKCL 1.1.X, the change-set would just be way too large. Pascal Bourguignon is right in pointing out the fact that CL:COMPILE-FILE on MKCL 1.1.X is persistently polluting the global environment of its running image with by-products of the compilation (structures, classes, symbols, etc.). This has been an hereditary defect of the KCL family from its origins (circa 1984) until now. MKCL 1.2.0 features, among other things, a vastly improved separation between the global environment and the (transient) compilation environment. And the code you provided compiles and loads in it exactly as you would expect, without error, because of that separation. MKCL 1.2.0 has been in the works for far too long (almost two years now) but it is not quite ready for release yet (I need to finish 2 major features and add a new one). I hope to be able to initiate its release process in 2 to 3 months from now. In the meantime there is a workaround for this bug possible in MKCL 1.1.X. It is simple but not without some drawback. All you need to do is to bind special (dynamic) variable clos::*redefine-class-in-place* to T before doing any call (direct or indirect) to cl:load. Something like this would do, I tested it in my current MKCL 1.1.10 git: (let ((clos::*redefine-class-in-place* t)) (asdf::load-system :hello)) With this the global environment pollution of CL::COMPILE-FILE is paved over, and you can merrily attend the rest of your business. The drawback is that by doing so you may wake up cl:update-instance-for-redefined-class and its friend of the class redefinition protocol. And that protocol is definitely thread-unsafe! If you are sure not to share among threads any instance of your classes that would exist through the compilation/redefinition step of the said classes then you are safe. Otherwise you may witness surprising and unexpected results and I waive any responsibility into that since you have been warned. Regards, JCB P.S.: Bug reports of the quality of yours are a treat, thank you so much.

1 0

[Mkcl-devel] C-based runtime of MKCL passes Coverity scan.
by Jean-Claude Beaudoin 24 Oct '14

24 Oct '14

Hello all, I am happy to announce you that the C-based runtime of MKCL has passed with great success the scrutiny of the source code scanning tool of Coverity. After a bit more than a week of use of that tool, Coverity now reports a defect density of 0.01 per 1000 lines for MKCL C-runtime on Linux and a defect density of 0.00 per 1000 lines for MKCL C-runtime on Microsoft Windows (Win32 and Win64). The code submitted to Coverity for these results currently sits in our Github repository on head of the master branch. This code will be the basis of upcoming version 1.1.10. I hope to release 1.1.10 in a few weeks, after some updates to its "contrib" bundle. Cheers, Jean-Claude Beaudoin

1 0

[Mkcl-devel] Example of embedding MKCL?
by Arto Bendiken 01 Oct '14

01 Oct '14

Good morning, I'm wondering if there is somewhere any example of embedded use of MKCL from a C/C++ program? I have not yet located one anywhere. Attempting to proceed based on examples written for ECL is painful, as more has changed than just naming. I have not yet managed to get something as simple as [1] ported and to run after half an hour of effort. Also, I should mention that I noticed that MKCL built from Git will install the shared library as /usr/local/lib/mkcl_1.1.10.so, without the customary lib- prefix. This means that in any case the -lmkcl linker flag will be ineffective without the manual creation of a /usr/local/lib/libmkcl.so symlink. Is MKCL still meant to usable embedded into C/C++ programs, or has it been evolving in other directions? Thanks, Arto [1] http://cwndr.ws/posts/Calling-Lisp-from-C-using-ECL.html -- Arto Bendiken | @bendiken | http://ar.to

2 1

Re: [Mkcl-devel] [Bug] [fixed] (coerce obj 'list) returns reversed list
by Jean-Claude Beaudoin 07 Sep '14

07 Sep '14

On Sat, Sep 6, 2014 at 1:16 PM, Jean-Claude Beaudoin < jean.claude.beaudoin(a)gmail.com> wrote: > > On Fri, Sep 5, 2014 at 10:24 PM, 金舜琳 <3han5chou7(a)gmail.com> wrote: > >> >> Hi, there >> >> I found a bug. >> mkcl returns: >> (print (coerce "string" 'list)) ; => (#\g #\n #\i #\r #\t #\s) >> but CLHS http://clhs.lisp.se/Body/f_coerce.htm specifies `coerce` to >> return the same sequence as origin. >> >> > Thank you very much for your bug report. I will apply your patch shortly. > > Your patch as now been applied to the code of MKCL, if not in its letter at least in its spirit. (Final code should be more efficient). The patch currently sits on the commit list head of MKCL's git repository (master branch). Thank you again, Jean-Claude Beaudoin

1 0