Dima Pasechnik writes:
> Thanks, this is useful.
> Is the very need of DEFGENERIC an ECL bug here?
Yes, the automatically generated generic doesn't conform to the second
paragraph of http://www.lispworks.com/reference/HyperSpec/Body/m_defmet.htm
--
With best regards, Stas.
Daniel Kochmański writes:
> Hello,
>
> problem is that you define two methods #'build-hmeq, where parameter
> lists are not congruent. Quick fix is to def generic method inbefore
> like this:
>
> (defgeneric build-hmeq (keyword lrdct &key &allow-other-keys)
> (:documentation "xyz"))
>
> apparen
Daniel Kochmański writes:
> Hello,
>
> problem is that you define two methods #'build-hmeq, where parameter
> lists are not congruent. Quick fix is to def generic method inbefore
> like this:
>
> (defgeneric build-hmeq (keyword lrdct &key &allow-other-keys)
> (:documentation "xyz"))
>
> apparen
On Sat, Feb 21, 2015 at 11:57 PM, Daniel Kochmański
wrote:
> Also, is anyone aware, how to edit ecls.sourceforge.net site? (it's
> different then site accessed with SF search).
http://sourceforge.net/p/forge/documentation/Project%20Web%20Services/
and
http://sourceforge.net/p/forge/documentation/R
Daniel Kochmański writes:
> Hello,
>
> it's saturday and nobody has risen concerns about new maintainership, so
> I assume it's ok with you all - thanks for putting trust on unknown
> person.
>
> For start I need admin privileges on SF, and on wikispaces (which also
> requires subscription renewa
Daniel Herring writes:
> On Tue, 18 Feb 2014, Marco Antoniotti wrote:
>
>> what is the status of the ?environment functionality? from CLtL2 in ECL?
>>
>> (apropos ?-INFORMATION?) does not return anything.
>>
>> Any plan to include them? I would very much push for it.
>
> Hi Marco,
>
> ECL develo
Daniel Herring writes:
> Hi all,
>
> I'm having trouble with tab completion in current Slime and ECL (237af2).
>
> I've traced the root cause to Slime's swank.lisp. In particular, it
> appears that the "defvar *swank-io-package*" isn't taking effect before
> the body of "parse-package" is comp
David Creelman writes:
> Hi,
> I'm trying to get my small webserver up on my tiny machine.
> I've compiled the latest ECL and I get the following error after trying to
> use quicklisp
>
> davidc@vps:~$ ecl
> ;;; Loading "/home/davidc/quicklisp/setup.lisp"
> ;;; Loading #P"/usr/local/lib/ecl-12.12
Peter Enerccio writes:
> Hello, I was wondering if it is possible to get the stack of thrown
> condition.
> I dont think there is ansi way of doing that, however, I can see stack
> generated by conditions thrown in slime with ecl, so there must be a way to
> do it.
You can look at swank-ecl.lisp
Juan Jose Garcia-Ripoll writes:
> (rename-file "foo.exe" "faa") -> "faa.exe"
>
> Unfortunately at some point it seemed ok to follow SBCL and interpret
> physical pathnames without extension as having :type NIL and drop support
> of :unspecific, as it leads to non-readable pathnames (i.e. a single
Peter Enerccio writes:
> Hello, I am trying to pass unicode string into PARSE-NAMESTRING, however,
> it doesn't work.
>
> (parse-namestring "aAaaajあ")
>
> Cannot coerce string aAaaajあ to a base-string
>[Condition of type SIMPLE-ERROR]
>
> List of features:
> *features*
> (:SWANK :SER
Stas Boukarev writes:
> Stanislav Frolov writes:
>
>> It seems to print functions do not call print-object method for hash-table
>> and
>> other standard types. I would like to see some human-readable representation
>> of hash tables.
>>
>> (defmet
Stanislav Frolov writes:
> It seems to print functions do not call print-object method for hash-table
> and
> other standard types. I would like to see some human-readable representation
> of hash tables.
>
> (defmethod print-object ((hash hash-table) stream)
> (format stream "42"))
> ;compil
Juan Jose Garcia-Ripoll writes:
> On Fri, Jun 1, 2012 at 12:20 PM, Stas Boukarev wrote:
>
>> As per CLHS,
>> http://www.lispworks.com/documentation/lw50/CLHS/Body/04_bc.htm
>> "*" means unspecified part of the type specifier.
>>
>> (declaim (ft
Juan Jose Garcia-Ripoll writes:
> Hi Stas,
>
> i am creating tickets for both bugs. One is half-solved, but I need this to
> keep myself posted on what I do -- please apologize if I forget to report
> the bug solution to the mailing list. It seems most efficient for me to
> proceed this way.
Is i
^ and _ symbols are printed with quotes:
(print '(^ _))
=>
(|^| |_|)
Neither of them satisfy the second criterion for potential numbers:
http://www.lispworks.com/reference/HyperSpec/Body/02_caa.htm
"The token contains at least one digit."
'. is read as SI:|.|, while it should signal an error.
#.
(defmacro with ((&rest _))
(declare (ignore _)))
;;; Compiling (DEFMACRO WITH ...).
;;; Warning:
;;; in file ecl-swank-tmpfile-YmZUGu, position 0
;;; at (FSET 'WITH ...)
;;; ! The variable #:G8 is not used.
Incidentally
(defmacro with ((&rest _))
(declare (ignore _))
_)
doesn't give an
Stas Boukarev writes:
> Matthew Mondor writes:
>
>> Hello,
>>
>> Anyone also experience the above error, along with a delay, and if
>> typing during that delay, lost characters? Most notably when typing
>> inside a WITH-OPEN-FILE macro, but I know it a
Matthew Mondor writes:
> Hello,
>
> Anyone also experience the above error, along with a delay, and if
> typing during that delay, lost characters? Most notably when typing
> inside a WITH-OPEN-FILE macro, but I know it also happened in a few
> other cases, although I forgot where.
The problem i
Stanislav Frolov writes:
>>What is the value of localtime() and gmtime() in your
>>system?
>
> localtime(0):
> tm_sec 0
> tm_min 0
> tm_hour 3
> tm_mday 1
> tm_mon 0
> tm_year 70
> tm_wday 4
> tm_yday 0
> tm_stdst 0
>
> gmtime(0):
> tm_sec 0
> tm_min 0
> tm_hour 0
> tm_mday 1
> tm_mon
Stanislav Frolov writes:
> Hi!
>
> I have a problem. Ecl crashes with current slime. I tested ecls-11.1.1-r1 and
> ecls-12.2.1 from Gentoo repo and 12.7.1 from git. In different times I see
> different things: SIGSEGV, errors, infinite recursivly locks...
>
> GNU Emacs 24.1.1, all Ecl versions
As per CLHS,
http://www.lispworks.com/documentation/lw50/CLHS/Body/04_bc.htm
"*" means unspecified part of the type specifier.
(declaim (ftype (function * integer) f))
(defun f (a)
(1+ a))
and then (compile-file "file.lisp")
;;; LAMBDA: Illegal lambda list *.
--
With best regards, Stas.
--
mit.u...@gmail.com writes:
> Hi,
>
> I tried make Patch ASDF-install for ECL 12.2.1 on CentOS 6.x.
> (I wish work this patch other platform)
It's 2012, why are you still using asdf-install? Use Quicklisp instead
.
--
With best regards, Stas.
--
Raymond Toy writes:
> Does ecl have the equivalent of cmucl's (and sbcl's)
> with-float-traps-masked and vector-sap?
>
> With-float-traps-masked sets up the fpu state to mask certain
> floating-point exceptions.
>
> Vector-sap basically takes a specialized array and returns the address
> of where
Xiaofeng Yang writes:
> It is the stable release ECL 12.2.1, compiled using mingw32 with GCC 4.5.0.
>
> ECL (Embeddable Common-Lisp) 12.2.1 (git:UNKNOWN)
> Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
> Copyright (C) 1993 Giuseppe Attardi
> Copyright (C) 2000 Juan J. Garcia-Ripoll
> ECL is
Matthew Mondor writes:
> Hello,
>
> Building ECL from the git HEAD today results in an error:
>
>
> (compile-file "src:cmp;cmptypes.lsp" :output-file
> #P"BUILD:CMP;CMPTYPES.O.NEWEST" :SYSTEM-P T :C-FILE T :DATA-FILE T :H-FILE T)
> ;;;
> ;;; Compiling SRC:CMP;CMPTYPES.LSP.
> ;;; OPTIMIZE levels:
Juan Jose Garcia-Ripoll writes:
> What configuration and version (see first lines of ECL's prompt) are you
> using?
That was the latest git revision at the moment, with --enable-threads and
--enable-unicode.
--
With best regards, Stas.
-
> (require 'sockets)
;;; Loading #P"/home/stas/lisp/impl/ecl/build/sockets.fas"
Condition of type: SIMPLE-TYPE-ERROR
The value of ASDF::NAME is SOCKETS, which is not of type STRING.
While (require "sockets") works.
--
With best regards, Stas.
-
Eric Marsden writes:
>> "jgr" == Juan Jose Garcia-Ripoll
>> writes:
>
> jgr> Here is the problem: "char" in Linux is "signed char", while in OS X it
> jgr> seems to default to "unsigned char". I have changed ECL so that
> BASE-CHAR
> jgr> objects are unboxed using the explicit C
Juan Jose Garcia-Ripoll writes:
> On Sun, Mar 27, 2011 at 6:22 PM, Stas Boukarev wrote:
>>
>> The first problem I encounter when building the latest ECL is a stray
>> reference to ecl_query_all_processes_status. That's easily fixable, and
>> the attached patch
Stas Boukarev writes:
> The first problem I encounter when building the latest ECL is a stray
> reference to ecl_query_all_processes_status. That's easily fixable, and
> the attached patch does that.
>
> diff --git a/src/c/unixsys.d b/src/c/unixsys.d
> index ea46754..667de
The first problem I encounter when building the latest ECL is a stray
reference to ecl_query_all_processes_status. That's easily fixable, and
the attached patch does that.
diff --git a/src/c/unixsys.d b/src/c/unixsys.d
index ea46754..667de72 100755
--- a/src/c/unixsys.d
+++ b/src/c/unixsys.d
@@ -29
Marko Kocić writes:
> HI all,
>
> I was playing a bit with slime and its documentation facilities, and
> constructed quickly a small function to find all symbols that are not
> documented.
>
> The results are the following:
> ECL - CL package - 707 documented, 271 undocumented
> ECL - EXT packa
Stas Boukarev writes:
> Juan Jose Garcia-Ripoll writes:
>
>> What settings do you have? I do not get those errors in any of my systems?
> I can reproduce after doing (require 'bytecmp)
And its compile-file has WITH-STANDARD-IO-SYNTAX around WRITE, which
sets *print-reada
Juan Jose Garcia-Ripoll writes:
> What settings do you have? I do not get those errors in any of my systems?
I can reproduce after doing (require 'bytecmp)
--
With Best Regards, Stas.
--
Special Offer-- Download ArcSig
Anton Vodonosov writes:
> Hello.
>
> Unfortunately deleting the ~/.slime directory doesn't help.
>
> Correction, the error happens not when I load "swank-loader.lisp", but after
> that, when I
> call swan-loader:init.
>
> Here is the backtrace:
>
> Backtrace:
> > SWANK-LOADER::HANDLE-S
Stas Boukarev writes:
> Juan Jose Garcia-Ripoll writes:
>
>> Hi everybody,
>> Regarding Stas Boukarev's problems with require-ing ASDF and compiling a
>> test file that defines the ASDF package, I could not reproduce it in any
>> system with a clean new copy
Juan Jose Garcia-Ripoll writes:
> Hi everybody,
> Regarding Stas Boukarev's problems with require-ing ASDF and compiling a
> test file that defines the ASDF package, I could not reproduce it in any
> system with a clean new copy of ECL.
This is quite unfortunate, because this really is a show-sto
Juan Jose Garcia-Ripoll writes:
> Configuration flags? Platform?
Digging further:
Given file
;;;
(eval-when (:compile-toplevel :load-toplevel :execute)
(unless (find-package :asdf)
(make-package :asdf :use '(:cl
(in-package :asdf)
(print 'foo)
;;;
Start fresh ecl:
(compile-file "foo.
Juan Jose Garcia-Ripoll writes:
> Configuration flags? Platform?
Interestingly, the following succeeds:
> (make-package "ASDF")
#<"ASDF" package>
> (require 'asdf)
;;; Loading #P"/usr/local/lib/ecl-11.1.1/asdf.fas"
;;; Loading #P"/usr/local/lib/ecl-11.1.1/cmp.fas"
("ASDF" "CMP")
--
With Bes
Juan Jose Garcia-Ripoll writes:
> Configuration flags? Platform?
Linux x86, gcc 4.5.2, --enable-threads --enable-unicode
--
With Best Regards, Stas.
--
Protect Your Site and Customers from Malware Attacks
Learn about v
Juan Jose Garcia-Ripoll writes:
> I had to fix a number of bugs that were submitted during the last days.
> Unless somebody complains very loud (please, no! :-) I will tag and upload
> the 11.1.1 release this weekend.
>
When doing (require 'asdf)
I get
;;; Loading #P"/usr/local/lib/ecl-11.1.1/asd
David Dreisigmeyer writes:
> I have the following for my .eclrc:
>(require 'asdf)
>(pushnew #P"/Users/daviddreisigmeyer/.emacs.d/site-lisp/slime/"
>asdf:*central-registry* :test #'equal)
>(push "/Users/daviddreisigmeyer/.emacs.d/site-lisp/slime/"
>asdf:*central-registry*)
>
Stas Boukarev writes:
> After the commit
> "ecl_parse_number and ecl_parse_integer are splitted into separate files and
> do not rely on the C library (atoi, strtod, ...) because these functions are
> affected by the locale."
> when entering in ecl_min 0.5 i
After the commit
"ecl_parse_number and ecl_parse_integer are splitted into separate files and do
not rely on the C library (atoi, strtod, ...) because these functions are
affected by the locale."
when entering in ecl_min 0.5 i get the following:
#0 0xb7f92b0f in __gmpn_tdiv_qr () from /usr/lib/
Consider the following file:
(defun foo ())
(defun location (function)
(multiple-value-bind (file pos) (ext:compiled-function-file function)
(list file pos)))
Load it:
> (load (compile-file "foo"))
> (location #'foo)
("foo.lisp" NIL)
> (ext:compiled-function-file #'foo)
"foo.lisp"
0
--
p...@informatimago.com (Pascal J. Bourguignon) writes:
> Loading iolib, (and several other systems such as io.multiplex, etc)
> in ECL signals the following error.
>
> ASDF2 does not evaluate the :pathname argument in DEFSYSTEM forms, but
> it seems these systems expect it to be evaluated.
>
Th
47 matches
Mail list logo
