mkcl-devel

mkcl-devel@common-lisp.net

57 discussions

[mkcl-devel] mkcl_safe_fclose failed on socket-output-stream
by Sean Champ 19 Jul '12

19 Jul '12

I was testing out a port for quicklisp on MKCL, today. The file is attached as revised from the original at http://beta.quicklisp.org/quicklisp.lisp It was a straightforward patch, focusing mostly on sockets support. Basically I just copied the quicklisp implementation package definition for SBCL, with some minor revisions. I was testing it out, then, when I encountered the following error. I'm not sure if the error may be a matter of the patched quicklisp - going by the debugger output, I'd like to assume it may be a matter of socket streams. It looks like quicklisp implements its own HTTP client. Maybe there could be a workaround possible, somewhere in that client code? I wasn't certain about sending the patch to the quicklisp developers, given this 'feature'. Looking at the debugger output, it looks like the error was in mkcl_safe_fclose failing on a socket-output-stream due to a bad FD. Here's the debugger output and backtrace. -- Sean during (quicklisp-quickstart:install) ; Fetching #<QLQS-HTTP::URL "http://beta.quicklisp.org/quickstart/asdf.lisp"> ; 159.59KB ================================================== 163,424 bytes in 0.77 seconds (206.56KB/sec) ; Fetching #<QLQS-HTTP::URL "http://beta.quicklisp.org/quickstart/quicklisp.tar"> ; 210.00KB ================================================== 215,040 bytes in 1.03 seconds (203.16KB/sec) ; Fetching #<QLQS-HTTP::URL "http://beta.quicklisp.org/quickstart/setup.lisp"> ; 4.88KB ================================================== 4,995 bytes in 0.00 seconds (5546.73KB/sec) Debugger called in: #<thread "Initial" (3737) 00000000010b7d80>. Filesystem error with pathname: #<output stream "SOCKET-OUTPUT-STREAM">. mkcl_safe_fclose() failed. OS Explanation: (errno == 9) Bad file descriptor. [...restarts...] Broken at IHS[73]> C::COMPILER-DEBUGGER. In: #<thread "Initial" (3560) 000000000164fd80>. File: "/home/user/workspaces/workspace_gpcl/3rdparty/mkcl-1.0.1/src/cmp/cmputil.lsp" (Position #4195) QL-UTIL>> :b Backtrace: IHS[117]> COMPILER-DEBUGGER IHS[116]> lambda, closure generated from compile-file IHS[114]> handle-internal-error IHS[113]> signal IHS[111]> wrapped-method-function IHS[110]> standard-compute-effective-method IHS[109]> compute-effective-method IHS[108]> compute-effective-method, closure generated from nil IHS[107]> compute-make-instance-function IHS[106]> make-instance_nil_class IHS[105]> lambda, closure generated from wrapped-method-function IHS[104]> make-condition IHS[101]> allocate-instance_nil_class IHS[100]> lambda, closure generated from wrapped-method-function IHS[99]> class-prototype_nil_class IHS[98]> lambda, closure generated from wrapped-method-function IHS[97]> compute-make-instance-function IHS[96]> make-instance_nil_class IHS[95]> lambda, closure generated from wrapped-method-function IHS[94]> make-condition IHS[91]> make-c1form* IHS[90]> c1c-inline IHS[89]> c1call-symbol IHS[88]> c1expr IHS[87]> c1stack-push-values IHS[86]> c1call-symbol IHS[85]> c1expr IHS[84]> t1/c1expr IHS[83]> c1progn IHS[82]> c1decl-body IHS[81]> c1let IHS[80]> c1call-symbol IHS[79]> c1expr IHS[78]> c1with-stack IHS[77]> c1call-symbol IHS[76]> c1expr IHS[75]> c1multiple-value-prog1 IHS[74]> c1call-symbol IHS[73]> c1expr IHS[72]> c1unwind-protect IHS[71]> c1call-symbol IHS[70]> c1expr IHS[69]> t1/c1expr IHS[68]> c1progn IHS[67]> c1decl-body IHS[66]> c1let IHS[65]> c1call-symbol IHS[64]> c1expr IHS[63]> c1call-symbol IHS[62]> c1expr IHS[61]> t1/c1expr IHS[60]> c1progn IHS[59]> c1block IHS[58]> c1call-symbol IHS[57]> c1expr IHS[56]> t1/c1expr IHS[55]> c1progn IHS[54]> c1decl-body IHS[53]> c1locally IHS[52]> c1call-symbol IHS[51]> c1expr IHS[50]> c1lambda-expr IHS[49]> c1compile-function IHS[48]> c1function IHS[47]> c1call-symbol IHS[46]> c1expr IHS[45]> c1fset IHS[44]> c1call-symbol IHS[43]> c1expr IHS[42]> t1ordinary IHS[41]> t1expr* IHS[40]> t1/c1expr IHS[39]> c1progn IHS[38]> c1eval-when IHS[37]> t1expr* IHS[36]> t1/c1expr IHS[35]> c1progn IHS[34]> t1expr* IHS[33]> t1expr* IHS[32]> t1expr IHS[31]> lambda, closure generated from compile-file IHS[30]> do-compilation-unit IHS[29]> compile-file IHS[28]> compile-file* IHS[27]> perform_nil_compile-op_cl-source-file IHS[26]> lambda, closure generated from wrapped-method-function IHS[25]> lambda, closure generated from standard-main-effective-method IHS[24]> perform-with-restarts_nil_t_t IHS[23]> lambda, closure generated from wrapped-method-function IHS[22]> perform-with-restarts_nil_compile-op_cl-source-file, closure generated from nil IHS[21]> lambda, closure generated from wrapped-method-function IHS[20]> lambda, closure generated from combine-method-functions IHS[19]> lambda, closure generated from operate_nil_t_t IHS[18]> do-compilation-unit IHS[17]> do-compilation-unit IHS[16]> operate_nil_t_t IHS[15]> lambda, closure generated from wrapped-method-function IHS[14]> lambda, closure generated from standard-main-effective-method IHS[13]> oos IHS[12]> bytecode [Evaluation of: (let ((*compile-print* nil) (*compile-verbose* nil) (*load-verbose* nil) (*load-print* nil)) (asdf:oos 'asdf:load-op "quicklisp" :verbose nil))] IHS[11]> initial-install IHS[10]> lambda IHS[9]> lambda, closure generated from wrapped-method-function IHS[8]> call-with-quiet-compilation IHS[7]> install IHS[6]> bytecode [Evaluation of: (quicklisp-quickstart:install)] IHS[5]> lambda, closure generated from interactive-loop

2 2

[mkcl-devel] a freaky error
by Kaïraba Cissé 30 Apr '12

30 Apr '12

Hi I want to understand why I get an arror when I try the following command on mkcl 1.1.0 (gnu/linux - x86) : (truename *default-pathname-defaults*) Normally, *default-pathname-defaults* must be initialzed to the current directory at start-up. But the return value is "". If we can initialized the value to "./" or get the working directory path it would be better. Cheers

2 1

[mkcl-devel] MKCL 1.1.0 RC1 is now available
by Jean-Claude Beaudoin 30 Apr '12

30 Apr '12

The latest beta version of ManKai Common Lisp, MKCL 1.1.0 RC1, is now available for general use. Its key new features are: 1. Standard Unicode support: Unicode is now a standard feature of MKCL and can be used anywhere in it. Code can use symbols with Unicode names as well as strings, in compiled or interpreted format. File names can also use any legal Unicode character if the surrounding OS allows it. This is also valid for the whole of file paths used for source code to be processed by #'compile-file. 2. MKCL is now truly embeddable for the first time! This is so thanks to the following new characteristics: 1. The whole of MKCL has been purged of calls to exit() or abort(). Thus MKCL never arbitrarily terminates the process it runs in through any of them. MKCL will always properly return control to its embedding outer context. 2. Every externally visible C symbol of MKCL is prefixed by one of the character sequences "mk", "_mk", "MK" or "_MK" in order to minimize potential clashes with embedding C code. 3. Careful attention as been devoted to assure that MKCL shares common process-wide resources with the rest of its process neighbors as fairly as possible and with little or no unilateral demands on them, waiving any pretense of monopoly. This concerns mainly environment variables, general memory management (including GC) and signal/exception handling. (In a Unix context, MKCL's code is ready to support chaining of signal handlers). 3. Finalization of objects is now done in a separate dedicated thread. This implements the finalization architecture strongly recommended by Hans Boehm, author of the conservative GC used by MKCL. Cheers, Jean-Claude Beaudoin

1 0

[mkcl-devel] Fwd: Quicklisp and MKCL
by Jean-Claude Beaudoin 03 Nov '11

03 Nov '11

---------- Forwarded message ---------- From: Jean-Claude Beaudoin <jean.claude.beaudoin(a)gmail.com> Date: Fri, Nov 4, 2011 at 12:15 AM Subject: Re: [mkcl-devel] Quicklisp and MKCL To: Kaïraba Cissé <ckairaba(a)gmail.com> On Thu, Nov 3, 2011 at 7:50 PM, Kaïraba Cissé <ckairaba(a)gmail.com> wrote: > Hi MKCL folk > I recently post the following messgae on > http://groups.google.com/group/quicklisp : > " > Hi zach > Can you just support MKCL in Quicklisp please ? > It's too painful to use just asdf. > Faithfully > " > and Zach Beane's answer was : > " > I think your best route is to ask the author of MKCL to send me some > patches to integrate MKCL support into Quicklisp. > Zach > " > > Can jean-claude extend Quicklisp to support MKCL? > 90 % of the work is already done because Quicklisp support ECL. > Faithfully > Ok, the short answer on this one is: "I am working on it folks". I know this sounds a bit cliché but it is essentially true. The longer answer is that I really want to finish plugging the holes in the Unicode support of MKCL, holes that you yourself, Kaïraba, have pointed to me a few months ago (I know "months ago". Yes the holes were that big! I basically had to rework the entire OS interface layer both for Linux and Windows.) This is motivated by the fact that real, standard, complete Unicode support seems to be pretty much expected by a large portion of the libraries available through Quicklisp. At least that is the impression I got from things I read in the ECL mailing lists... The more or less good news here is that I am almost done with this Unicode business, at least I hope I am. (I think there is about 2 more weeks to go on this.) Right next after that I will do the Quicklisp "port". And then these two things (1- complete Unicode support, 2 - Quicklisp for MKCL) will be the main features of the MKCL 1.1 version I will announce. So, what do you say of that? Cheers, Jean-Claude

1 0

[mkcl-devel] Quicklisp and MKCL
by Kaïraba Cissé 03 Nov '11

03 Nov '11

Hi MKCL folk I recently post the following messgae on http://groups.google.com/group/quicklisp : " Hi zach Can you just support MKCL in Quicklisp please ? It's too painful to use just asdf. Faithfully " and Zach Beane's answer was : " I think your best route is to ask the author of MKCL to send me some patches to integrate MKCL support into Quicklisp. Zach " Can jean-claude extend Quicklisp to support MKCL? 90 % of the work is already done because Quicklisp support ECL. Faithfully

1 0

[mkcl-devel] Fwd: Add new alias command
by Jean-Claude Beaudoin 25 Aug '11

25 Aug '11

---------- Forwarded message ---------- From: Jean-Claude Beaudoin <jean.claude.beaudoin(a)gmail.com> Date: Thu, Aug 25, 2011 at 5:28 PM Subject: Re: [mkcl-devel] Add new alias command To: Kaïraba Cissé <ckairaba(a)gmail.com> Hello Kaïraba, Using the old stand-alone REPL, are we? Weren't you using SLIME instead lately? ;-) Joke aside, I tried your piece of code in my .mkclrc and it works perfectly. Here is exactly what I inserted: (setf (cdar si::*tpl-commands*) (append (cdar si::*tpl-commands*) '(((:bye) quit :eval ":bye Exit Lisp (a la Kairaba)" ":bye &eval &optional (status 0) [Top level command]~@ ~@ Exit Lisp (Kairaba's way) without further confirmation.~%")))) And here is what I get at the command line: jean-claude@mars> mkcl-1.0.1 Loading ~/.mkclrc! Done with loading asdf ~/.mkclrc! Done with configuring asdf ~/.mkclrc! This is ManKai Common Lisp 1.0.1 Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya Copyright (C) 1993 Giuseppe Attardi Copyright (C) 2000 Juan J. Garcia-Ripoll Copyright (C) 2010-2011 Jean-Claude Beaudoin ManKai Common Lisp (MKCL) is free software, and you are welcome to redistribute and/or modify it under the terms of the GNU LGPL. See file 'Copyright' in the source code for details. Type :h for Help. Top level in: #<thread "Initial" (21173) 000000000291dd80>. > :h Top level commands: :cf Compile file. :exit or ^D Exit Lisp. :ld Load file. :step Single step form. :tr(ace) Trace function. :untr(ace) Untrace function. :w(ho-)b(inds) Show function invocations currently binding variable. :bye Exit Lisp (a la Kairaba). Help commands: :apropos Apropos. :doc(ument) Document. :h(elp) or ? Help. Type ":help help" for more information. > :bye jean-claude@mars> So the :bye command shows up right where you wanted it and works as expected. I am then a bit at a loss trying to figure out what is going wrong on your side. On Thu, Aug 25, 2011 at 10:53 AM, Kaïraba Cissé <ckairaba(a)gmail.com> wrote: > Hi jean-claude > I wanted to add new aliases in mkcl. > So, I add the following code in my .mkclrc file : > *(setf (cdar si::*tpl-commands*) > (append (cdar si::*tpl-commands*) '(((:bye) quit :eval "" ""))))* > Howerver, it doesn't work at all. > I think the issue comes from the file mkcl-1.0.1/src/lsp/top.lsp on line > 504. > We must replace the line 504 by : > *(&key ((:commands *tpl-commands*) *tpl-commands*)* > > What do you think about that ? > > Well, this is debatable here but let me very clearly stress that tpl-commands vs *tpl-commands* is not the source of your immediate concerns. Your modification in .mkclrc of a sub-part of the commands list happens well before the value of tpl-commands is sampled and it can be seen from either variables. Now, this aside, my thinking was that a call to "interactive-loop" without a :commands argument would normally be done by "top-level" or something equivalent to establish a new top-level REPL with a fresh context. This is clearly different from the debugger or the inspector that need to establish a sub-level with a sub-REPL of their own and its augmented set of commands to serve their specialized purpose. This matters of course only on recursive calls to "interactive-loop". With the code as it stands now you have the choice between setting a clean slate with a standard set of commands or keep on augmenting the inherited set of commands. If the code is modified the way you suggest we get locked into augmenting what we get from above and we lose the ability to easily reset to a standard set of commands is lost. If there is something that interferes with the customizability of the initial command set by the user it is the use of "defconstant" for the declaration of tpl-commands. It should most probably be replaced by "defparameter" or "defvar". Cheers, Jean-Claude

1 0

[mkcl-devel] Add new alias command
by Kaïraba Cissé 25 Aug '11

25 Aug '11

Hi jean-claude I wanted to add new aliases in mkcl. So, I add the following code in my .mkclrc file : *(setf (cdar si::*tpl-commands*) (append (cdar si::*tpl-commands*) '(((:bye) quit :eval "" ""))))* Howerver, it doesn't work at all. I think the issue comes from the file mkcl-1.0.1/src/lsp/top.lsp on line 504. We must replace the line 504 by : *(&key ((:commands *tpl-commands*) *tpl-commands*)* What do you think about that ?

1 0

[mkcl-devel] MKCL 1.0.1 is out.
by Jean-Claude Beaudoin 21 Jul '11

21 Jul '11

MKCL 1.0.1 is a bug fix release in the 1.0 series. It corrects a number of bugs, mostly in the area of CLOS class shared slots and unusual pathnames (like #P"..."). Enjoy, Jean-Claude Beaudoin

1 0

[mkcl-devel] Fwd: quiclisp
by Jean-Claude Beaudoin 01 Jul '11

01 Jul '11

---------- Forwarded message ---------- From: Jean-Claude Beaudoin <jean.claude.beaudoin(a)gmail.com> Date: Fri, Jul 1, 2011 at 10:01 PM Subject: Re: [mkcl-devel] quiclisp To: Robert Burghart <jestersks(a)gmail.com> Although coming from the same code set of ECL 9.6.2, MKCL and ECL should now be considered now more like close cousins than as twins. Just having MKCL as a clone of ECL, however cleaned-up, would have been pretty much pointless. This said, a good first approximation to a MKCL port would be to simply do: (push :ecl *features*) and see how far it goes with such a masquerade. ;-) But this will be less and less successful as time passes, mainly with what is in works for MKCL 1.1 (entirely revised OS runtime interface to make it fully support Unicode, C99-complete FFI, memory image dump/load). Do I hear someone say documentation... On Fri, Jul 1, 2011 at 1:22 PM, Robert Burghart <jestersks(a)gmail.com> wrote: > Very interesting. I was trying quicklisp since it shares a common root > with ECL which is supported. > > > On Fri, Jul 1, 2011 at 12:40 PM, Jean-Claude Beaudoin < > jean.claude.beaudoin(a)gmail.com> wrote: > >> >> >> On Thu, Jun 30, 2011 at 11:05 PM, Jean-Claude Beaudoin < >> jean.claude.beaudoin(a)gmail.com> wrote: >> >>> This makes, in a multi-threaded SBCL, impossible to predict the value >>> of: >>> >>> (equal (truename #P"") (truename #P"")) >>> >>> It may return T most of the time but not always since the current working >>> directory may have been changed by some other thread between the two >>> "truename" calls. >>> >>> >> After verification I have to add that the statement here above is >> partially inexact for SBCL. In fact, SBCL seems to ignore the process >> current working directory after sampling it on startup and relies entirely >> on *default-pathname-defaults* ever after. But SBCL keeps >> *default-pathname-defaults* a true global variable and if one is not careful >> to rebind it locally in its own thread then you get the same unpredictable >> behavior stated above but for a somewhat different reason >> >> >>> >>> >> >>>> _______________________________________________ >>>> mkcl-devel mailing list >>>> mkcl-devel(a)common-lisp.net >>>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mkcl-devel >>>> >>>> >>> >> >

1 0

[mkcl-devel] quiclisp
by Robert Burghart 01 Jul '11

01 Jul '11

On Windows XP SP3 I tried to load quicklisp.lisp using mkcl an it errors out near the bottom of the file at: (setf *default-pathname-defaults* (truename *default-pathname-defaults*)) Apparently *default-pathname-defaults* defaults to "". Is that intentional? From the hyperspec it says that it's implementation dependent but that many will store the path where the repl was started in.

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

mkcl-devel