ecl-devel

ecl-devel@common-lisp.net

1 participants
232 discussions

Ecl fails to compile under visual studio enterprise 2015
by lucaregini＠yahoo.it 01 Sep '16

01 Sep '16

Hi All,I have attempted unsuccesfully to compile Ecl under VS 2015 enterprise.I have simply run the nmake command from a VS2015 x86 command prompt with the makefile left untouched.This is what I am getting: ../ecl/ecl.h(33): warning C4005: 'va_copy': macro redefinition../ecl/config.h(450): warning C4005: 'isnan': macro redefinition ../../src/c/file.d(5324): error C2039: '_cnt': is not a member of '_iobuf' Any clue?Regards,Luca

3 2

Problems with quicklisp under windows
by lucaregini＠yahoo.it 01 Sep '16

01 Sep '16

I have downloaded and installed the prebuild version of ECL 16.1.2 for windows. The installation folder has been set to C:\ecl. When I try to run (require 'ecl-quicklisp) I am getting the following errors: > (require 'ecl-quicklisp) ;;; Loading #P"C:/ECL/ecl-quicklisp.fas" Condition of type: SIMPLE-ERROR LOAD: Could not load file #P"C:/ECL/ecl_quicklisp.fas" (Error: "The operation completed successfully. ") Regards,L

2 1

quicklisp without gcc
by Peter Münster 16 Aug '16

16 Aug '16

Hello, I would like to use quicklisp on a mips target without gcc. Thanks to the howto¹ by Attila Lendvai, I've installed ecl successfully on the target (an Asus router), but installing quicklisp fails: --8<---------------cut here---------------start------------->8--- ; Fetching #<url "http://beta.quicklisp.org/asdf/2.26/asdf.lisp"> ; 194.07KB ================================================== 198,729 bytes in 0.19 seconds (1016.08KB/sec) Condition of type: FILE-ERROR Filesystem error with pathname #P"SYS:CMP.NEWEST". Either 1) the file does not exist, or 2) we are not allowed to access the file, or 3) the pathname points to a broken symbolic link. Available restarts: 1. (RESTART-TOPLEVEL) Go back to Top-Level REPL. Broken at QL-SETUP::ASDF-FASL-PATHNAME. In: #<process TOP-LEVEL>. File: #P"/home/peter/quicklisp/setup.lisp" (Position #0) --8<---------------cut here---------------end--------------->8--- How could this problem be solved please? TIA for any hints, -- Peter ¹ https://www.mail-archive.com/ecl-devel@common-lisp.net/msg00033.html

2 9

Sleeping process not reported as sleeping
by Elias Pipping 03 Aug '16

03 Aug '16

Dear list, I’m trying to find out how different lisp compilers handle external processes(*). As a part of that, I’ve created a short piece of code that launches an external process, sends it SIGSTOP, asks its about its well-being, and allows its to go about its business again by sending SIGCONT. I would expect that ext:external-process-status consequently reports (1) :running before SIGSTOP is sent (2) then :stopped (3) then :running again once SIGCONT was received (4) and finally :exited. Indeed, that is what `ps` would do if you ran it on the command line (so I’ve added that to the example for comparison). Here’s the output of my script: external status: [S] (expected: [S]) internal status: RUNNING (expected: running) external status: [T] (expected: [T]) internal status: RUNNING (expected: stopped) external status: [S] (expected: [S]) internal status: RUNNING (expected: running) external status: [ ] (expected: [] or [Z]) internal status: EXITED (expected: exited) My expectations aren’t met in (2) and (3): Even though according to https://common-lisp.net/project/ecl/manual/rn01re63.html the status of a process can be :stopped, and the process is clearly stopped, it is not reported as such. So I’d like to ask: Is this a bug or intentional? Elias Pipping (*) I’ve already sent very similar messages to openmcl-devel and sbcl-devel. PS: Here’s the script that I used (the aforementioned messages used an earlier version): ;; careful with cmucl. it doesn't actually sleep when external processes ;; are around https://gitlab.common-lisp.net/cmucl/cmucl/issues/26 #+clozure (use-package :ccl) #+sbcl (use-package :sb-ext) #+cmu (use-package :ext) #+clozure (setf (fdefinition 'process-output) #'external-process-output-stream) #+ecl (setf (fdefinition 'process-output) #'ext:external-process-output) #+ecl (setf (fdefinition 'run-program) #'(lambda (&rest rest) (nth-value 2 (apply #'ext:run-program rest)))) (defconstant +sigstop+ #+clozure (symbol-value (read-from-string "#$SIGSTOP")) #+cmu (unix:unix-signal-number :sigstop) #+ecl ext:+sigstop+ #+sbcl (progn (require :sb-posix) (symbol-value (find-symbol (symbol-name :sigstop) (find-package :sb-posix))))) (defconstant +sigtstp+ #+clozure (symbol-value (read-from-string "#$SIGTSTP")) #+cmu (unix:unix-signal-number :sigtstp) #+ecl ext:+sigtstp+ #+sbcl (progn (require :sb-posix) (symbol-value (find-symbol (symbol-name :sigtstp) (find-package :sb-posix))))) (defconstant +sigcont+ #+clozure (symbol-value (read-from-string "#$SIGCONT")) #+cmu (unix:unix-signal-number :sigcont) #+ecl ext:+sigcont+ #+sbcl (progn (require :sb-posix) (symbol-value (find-symbol (symbol-name :sigcont) (find-package :sb-posix))))) (defun internal-status (process) #+clozure (external-process-status process) #+(or sbcl cmu) (process-status process) #+ecl (ext:external-process-status process)) (defun external-kill (pid signal) (run-program "/usr/bin/env" (list "kill" (format nil "-~a" signal) (format nil "~a" pid)))) ;; ecl does not support writing to a string stream (defun external-status (pid) (let* ((arg-list (list "ps" "-h" "-p" (format nil "~a" pid) "-o" "state")) (process (run-program "/usr/bin/env" arg-list :output :stream)) (output (process-output process)) ; we expect a single letter (target (make-string 1))) (read-sequence target output) target)) (defun get-pid (process) #+clozure (ccl::external-process-pid process) #+ecl (ext:external-process-pid process) #+(or sbcl cmu) (process-pid process)) (let* ((p (run-program "/usr/bin/env" '("sleep" "3") :wait nil)) (pid (get-pid p))) (format t "external status: [~a] (expected: [S])~%" (external-status pid)) (format t "internal status: ~a (expected: running)~%" (internal-status p)) (external-kill pid +sigstop+) (sleep 1) (format t "external status: [~a] (expected: [T])~%" (external-status pid)) (format t "internal status: ~a (expected: stopped)~%" (internal-status p)) (external-kill pid +sigcont+) (sleep 1) (format t "external status: [~a] (expected: [S])~%" (external-status pid)) (format t "internal status: ~a (expected: running)~%" (internal-status p)) (sleep 3) (format t "external status: [~a] (expected: [] or [Z])~%" (external-status pid)) (format t "internal status: ~a (expected: exited)~%" (internal-status p)))

1 0

Printing a custom representation of hash table at the repl
by Diogo Franco 08 Jul '16

08 Jul '16

Hello, ecl does not specialize the print-object method on hash-tables: > (find-method #'print-object '() '(hash-table t)) > Debugger received error of type: SIMPLE-ERROR > There is no method on the generic function PRINT-OBJECT that agrees on > qualifiers NIL and specializers (HASH-TABLE T) After reading the hyperspec carefully, I think this is ok, it only requires it on standard-object and structure-object. However, i still thought that specializing on hash-table would work, but it doesn't: >> (defmethod print-object ((obj hash-table) stream) (princ "its working" > stream)) > #<standard-method PRINT-OBJECT (#<The BUILT-IN-CLASS HASH-TABLE> #<The > BUILT-IN-CLASS T>)> > >> (make-hash-table) > #<hash-table 000000000493ee40> Shouldn't we still dispatch the call to this method? And if not, what's the best way in ecl to customize the printable representation of a hash-table? I've tried: > > (set-pprint-dispatch 'hash-table (lambda (s obj) (princ "its working" > s))) > NIL > > (make-hash-table) > its working But this sometimes gives an error: > Debugger received error of type: SIMPLE-ERROR > Tried to modified a read-only pprint dispatch table: > #<pprint-dispatch-table 0000000003375210> > Error flushed. Thanks!

3 2

Re: ecl-devel Digest, Vol 12, Issue 1
by Diogo Franco 06 Jul '16

06 Jul '16

I did it right before loading the .fasb file. In my case, i'm building a monolithic fasl with all the dependencies in it, is this your use case as well? On 6 July 2016 at 16:20, Alexander Artemenko <svetlyak.40wt(a)gmail.com> wrote: > Hi, Diogo! > > I've tried to add (require :sb-bsd-sockets) but with no luck. In which > place it should be added? > > On Wed, Jul 6, 2016 at 4:20 PM, Diogo Franco <diogoalexfranco(a)gmail.com> > wrote: > >> Hello Alexander, >> >> Take a look at this issue: >> https://gitlab.com/embeddable-common-lisp/ecl/issues/216 >> >> Daniel's suggestion of requiring :sb-bsd-sockets worked for me. I think >> this an ecl specific version of sb-bsd-sockets that works. >> >> Best regards, >> Diogo Franco >> >> On 6 July 2016 at 13:00, <ecl-devel-request(a)common-lisp.net> wrote: >> >>> Send ecl-devel mailing list submissions to >>> ecl-devel(a)common-lisp.net >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://mailman.common-lisp.net/listinfo/ecl-devel >>> or, via email, send a message with subject or body 'help' to >>> ecl-devel-request(a)common-lisp.net >>> >>> You can reach the person managing the list at >>> ecl-devel-owner(a)common-lisp.net >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of ecl-devel digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Using Hunchentoot from a binary, compiled with ECL >>> (Alexander Artemenko) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Tue, 5 Jul 2016 16:49:59 +0300 >>> From: Alexander Artemenko <svetlyak.40wt(a)gmail.com> >>> To: ecl-devel(a)common-lisp.net >>> Subject: Using Hunchentoot from a binary, compiled with ECL >>> Message-ID: >>> <CA+GmUUJsHW0fao= >>> Pz-BBL1o1s4gSKoVESDhgkJ5+jZTzQusTnQ(a)mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Hello, everybody! >>> >>> I continue to test ECL and wanted to create a small webservice, compiled >>> into a binary. >>> >>> But I discovered, that my binary fails with this error: >>> >>> Condition of type: SIMPLE-ERROR >>> Package ((SB-BSD-SOCKETS . #<SB-BSD-SOCKETS package>)) referenced in >>> compiled file >>> NIL >>> but has not been created >>> Available restarts: >>> >>> 1. (IGNORE) Ignore the error, and try the operation again >>> >>> This error is similar to cffi and uiop problem, I wrote recently ( >>> https://mailman.common-lisp.net/pipermail/ecl-devel/2016-June/011119.html >>> ). >>> >>> But a trick with making package immutable, like this >>> (asdf:register-immutable-system >>> "SB-BSD-SOCKETS") does not work now. >>> >>> Tested on Ubuntu ECL 16.1.4 and OSX 16.1.2. >>> >>> Full example is available in https://github.com/svetlyak40wt/test-ecl in >>> branch try-web-app. To build a binary, you need to issue ./bootstrap && >>> ./build commands, and after them, run ./test-ecl. >>> >>> Why do I have this problem and how to fix it? >>> >>> -- >>> Alexander Artemenko (a.k.a. Svetlyak 40wt) >>> Blog: http://dev.svetlyak.ru >>> Photos: http://svetlyak.ru >>> Jabber: svetlyak.40wt(a)gmail.com >>>

1 0

Re: ecl-devel Digest, Vol 12, Issue 1
by Diogo Franco 06 Jul '16

06 Jul '16

Hello Alexander, Take a look at this issue: https://gitlab.com/embeddable-common-lisp/ecl/issues/216 Daniel's suggestion of requiring :sb-bsd-sockets worked for me. I think this an ecl specific version of sb-bsd-sockets that works. Best regards, Diogo Franco On 6 July 2016 at 13:00, <ecl-devel-request(a)common-lisp.net> wrote: > Send ecl-devel mailing list submissions to > ecl-devel(a)common-lisp.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.common-lisp.net/listinfo/ecl-devel > or, via email, send a message with subject or body 'help' to > ecl-devel-request(a)common-lisp.net > > You can reach the person managing the list at > ecl-devel-owner(a)common-lisp.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ecl-devel digest..." > > > Today's Topics: > > 1. Using Hunchentoot from a binary, compiled with ECL > (Alexander Artemenko) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 5 Jul 2016 16:49:59 +0300 > From: Alexander Artemenko <svetlyak.40wt(a)gmail.com> > To: ecl-devel(a)common-lisp.net > Subject: Using Hunchentoot from a binary, compiled with ECL > Message-ID: > <CA+GmUUJsHW0fao= > Pz-BBL1o1s4gSKoVESDhgkJ5+jZTzQusTnQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello, everybody! > > I continue to test ECL and wanted to create a small webservice, compiled > into a binary. > > But I discovered, that my binary fails with this error: > > Condition of type: SIMPLE-ERROR > Package ((SB-BSD-SOCKETS . #<SB-BSD-SOCKETS package>)) referenced in > compiled file > NIL > but has not been created > Available restarts: > > 1. (IGNORE) Ignore the error, and try the operation again > > This error is similar to cffi and uiop problem, I wrote recently ( > https://mailman.common-lisp.net/pipermail/ecl-devel/2016-June/011119.html > ). > > But a trick with making package immutable, like this > (asdf:register-immutable-system > "SB-BSD-SOCKETS") does not work now. > > Tested on Ubuntu ECL 16.1.4 and OSX 16.1.2. > > Full example is available in https://github.com/svetlyak40wt/test-ecl in > branch try-web-app. To build a binary, you need to issue ./bootstrap && > ./build commands, and after them, run ./test-ecl. > > Why do I have this problem and how to fix it? > > -- > Alexander Artemenko (a.k.a. Svetlyak 40wt) > Blog: http://dev.svetlyak.ru > Photos: http://svetlyak.ru > Jabber: svetlyak.40wt(a)gmail.com >

1 0

Using Hunchentoot from a binary, compiled with ECL
by Alexander Artemenko 05 Jul '16

05 Jul '16

Hello, everybody! I continue to test ECL and wanted to create a small webservice, compiled into a binary. But I discovered, that my binary fails with this error: Condition of type: SIMPLE-ERROR Package ((SB-BSD-SOCKETS . #<SB-BSD-SOCKETS package>)) referenced in compiled file NIL but has not been created Available restarts: 1. (IGNORE) Ignore the error, and try the operation again This error is similar to cffi and uiop problem, I wrote recently ( https://mailman.common-lisp.net/pipermail/ecl-devel/2016-June/011119.html). But a trick with making package immutable, like this (asdf:register-immutable-system "SB-BSD-SOCKETS") does not work now. Tested on Ubuntu ECL 16.1.4 and OSX 16.1.2. Full example is available in https://github.com/svetlyak40wt/test-ecl in branch try-web-app. To build a binary, you need to issue ./bootstrap && ./build commands, and after them, run ./test-ecl. Why do I have this problem and how to fix it? -- Alexander Artemenko (a.k.a. Svetlyak 40wt) Blog: http://dev.svetlyak.ru Photos: http://svetlyak.ru Jabber: svetlyak.40wt(a)gmail.com

1 0

Please, help me with cffi linkage
by Alexander Artemenko 16 Jun '16

16 Jun '16

Hi, everybody! Some time ago, I wrote about a problem when building a binary with dependencies. Yesterday I've created a repository with minimal example: https://github.com/svetlyak40wt/test-ecl-crash It demostrates, how a programm, compiled with ECL is crashed because of it's dependency from CFFI. If you remove dependency – everything go well. Please, help me to resolve this issue. -- Alexander Artemenko (a.k.a. Svetlyak 40wt) Blog: http://dev.svetlyak.ru Photos: http://svetlyak.ru Jabber: svetlyak.40wt(a)gmail.com

2 1

[ecl quarterly volume 4]
by Daniel Kochmański 15 Jun '16

15 Jun '16

Dear all, finally I've assembled the next issue of ECL Quarterly. https://common-lisp.net/project/ecl/posts/ECL-Quarterly-Volume-IV.html Any feedback is very welcome :-) Best regards, Daniel -- Daniel Kochmański ;; aka jackdaniel | Poznań, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi

1 0

← Newer
1
...
15
16
17
18
19
20
21
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

ecl-devel