You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(8) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2002 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
(2) |
Sep
(3) |
Oct
|
Nov
|
Dec
(8) |
2003 |
Jan
(5) |
Feb
(4) |
Mar
(14) |
Apr
|
May
(27) |
Jun
(10) |
Jul
(3) |
Aug
(28) |
Sep
(27) |
Oct
(3) |
Nov
(14) |
Dec
(19) |
2004 |
Jan
(32) |
Feb
(15) |
Mar
(21) |
Apr
(69) |
May
(18) |
Jun
(15) |
Jul
(23) |
Aug
(14) |
Sep
(38) |
Oct
(20) |
Nov
(76) |
Dec
(27) |
2005 |
Jan
(24) |
Feb
(32) |
Mar
(39) |
Apr
(65) |
May
(69) |
Jun
(37) |
Jul
(32) |
Aug
(28) |
Sep
(28) |
Oct
(17) |
Nov
(30) |
Dec
(24) |
2006 |
Jan
(45) |
Feb
(38) |
Mar
(19) |
Apr
(26) |
May
(19) |
Jun
(29) |
Jul
(13) |
Aug
(26) |
Sep
(53) |
Oct
(46) |
Nov
(40) |
Dec
(85) |
2007 |
Jan
(45) |
Feb
(51) |
Mar
(69) |
Apr
(48) |
May
(75) |
Jun
(35) |
Jul
(35) |
Aug
(25) |
Sep
(11) |
Oct
(16) |
Nov
(9) |
Dec
(59) |
2008 |
Jan
(36) |
Feb
(17) |
Mar
(28) |
Apr
(13) |
May
(1) |
Jun
(25) |
Jul
(24) |
Aug
(52) |
Sep
(19) |
Oct
(52) |
Nov
(43) |
Dec
(80) |
2009 |
Jan
(33) |
Feb
(30) |
Mar
(18) |
Apr
(15) |
May
(29) |
Jun
(58) |
Jul
(48) |
Aug
(35) |
Sep
(52) |
Oct
(59) |
Nov
(46) |
Dec
(31) |
2010 |
Jan
(26) |
Feb
(45) |
Mar
(55) |
Apr
(59) |
May
(8) |
Jun
(24) |
Jul
(43) |
Aug
(31) |
Sep
(43) |
Oct
(33) |
Nov
(41) |
Dec
(19) |
2011 |
Jan
(17) |
Feb
(31) |
Mar
(5) |
Apr
(31) |
May
(17) |
Jun
(28) |
Jul
(15) |
Aug
(38) |
Sep
(21) |
Oct
(25) |
Nov
(21) |
Dec
(21) |
2012 |
Jan
(9) |
Feb
(22) |
Mar
(17) |
Apr
(16) |
May
(58) |
Jun
(13) |
Jul
(40) |
Aug
(12) |
Sep
(10) |
Oct
(10) |
Nov
(14) |
Dec
(4) |
2013 |
Jan
(9) |
Feb
(8) |
Mar
(17) |
Apr
(10) |
May
|
Jun
(9) |
Jul
(1) |
Aug
(7) |
Sep
(8) |
Oct
(22) |
Nov
(9) |
Dec
(6) |
2014 |
Jan
(30) |
Feb
(55) |
Mar
(38) |
Apr
(15) |
May
(7) |
Jun
(17) |
Jul
(15) |
Aug
(13) |
Sep
(21) |
Oct
(29) |
Nov
(7) |
Dec
(10) |
2015 |
Jan
(11) |
Feb
(19) |
Mar
(32) |
Apr
(17) |
May
(5) |
Jun
(3) |
Jul
(9) |
Aug
(7) |
Sep
(19) |
Oct
(3) |
Nov
(31) |
Dec
(23) |
2016 |
Jan
(11) |
Feb
(5) |
Mar
(8) |
Apr
(10) |
May
(15) |
Jun
(1) |
Jul
(11) |
Aug
(9) |
Sep
(11) |
Oct
(1) |
Nov
(26) |
Dec
(7) |
2017 |
Jan
(18) |
Feb
(19) |
Mar
(40) |
Apr
(6) |
May
(12) |
Jun
(1) |
Jul
(14) |
Aug
(21) |
Sep
(27) |
Oct
(22) |
Nov
(42) |
Dec
(3) |
2018 |
Jan
(9) |
Feb
(7) |
Mar
(31) |
Apr
(5) |
May
(7) |
Jun
|
Jul
(6) |
Aug
(34) |
Sep
(2) |
Oct
(8) |
Nov
(29) |
Dec
(7) |
2019 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(62) |
May
(18) |
Jun
(12) |
Jul
(30) |
Aug
(8) |
Sep
(4) |
Oct
(8) |
Nov
(6) |
Dec
(12) |
2020 |
Jan
(24) |
Feb
(4) |
Mar
(11) |
Apr
(16) |
May
(6) |
Jun
(59) |
Jul
(51) |
Aug
(18) |
Sep
(32) |
Oct
(19) |
Nov
(12) |
Dec
(29) |
2021 |
Jan
(11) |
Feb
(27) |
Mar
(30) |
Apr
(10) |
May
(29) |
Jun
(14) |
Jul
(10) |
Aug
(3) |
Sep
(12) |
Oct
(10) |
Nov
(18) |
Dec
(19) |
2022 |
Jan
(11) |
Feb
(8) |
Mar
(21) |
Apr
(30) |
May
(3) |
Jun
(2) |
Jul
(16) |
Aug
(9) |
Sep
(4) |
Oct
(2) |
Nov
(17) |
Dec
(10) |
2023 |
Jan
(16) |
Feb
(21) |
Mar
(42) |
Apr
(8) |
May
(7) |
Jun
(32) |
Jul
(3) |
Aug
(22) |
Sep
(11) |
Oct
(3) |
Nov
(16) |
Dec
(12) |
2024 |
Jan
(8) |
Feb
(15) |
Mar
(32) |
Apr
(31) |
May
(23) |
Jun
(51) |
Jul
(13) |
Aug
(19) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Kevin B. <kt...@ne...> - 2024-08-22 13:58:29
|
Hi all, I'm attempting to get sb-threads working on NetBSD and I'm running into some errors when running tests. SBCL compiles without concern and I'm not sure if threading will work completely without the tests fully succeeding. Here is where it fails: // Running /usr/pkgsrc/lang/sbcl/work/sbcl-2.4.7/tests/gethash-concurrency.pure.lisp in COMPILE evaluator mode ::: SKIPPED-BROKEN (HASH-TABLE :UNSYNCHRONIZED) Test broken on this platform ::: Running (HASH-TABLE :SYNCHRONIZED) ::: Success (HASH-TABLE :SYNCHRONIZED) ::: Running (HASH-TABLE :PARALLEL-READERS-EQ-TABLE) ::: Success (HASH-TABLE :PARALLEL-READERS-EQ-TABLE) ::: Running (HASH-TABLE :PARALLEL-READERS-EQL-TABLE) [1] Trace/BPT trap (core dumped) (set -u; if [ ${#} -gt 0 ]; then "${SBCL_RUNTI... test failed, expected 104 return code, got 133 I've tried looking to see what that error number means but no dice. If I skip the test, it fails later with the same error doing something related to threads. Anyone able to point me in the right direction here? Regards, kev |
From: Raimondas K. <ra...@gm...> - 2024-08-20 21:17:04
|
I have a server that processes files, given a directory name. The directory and file names are supposed to all be encoded in UTF-8. Once in a while though, a file with wonky name comes in and the processing thread is thrown into debugger, for instance: * (DIRECTORY #P"/some-directory/*.*" ) debugger invoked on a SB-INT:C-STRING-DECODING-ERROR in thread #<THREAD "main thread" RUNNING {1001090003}>: :UTF-8 c-string decoding error: the octet sequence #(233 32 84) cannot be decoded. Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-IMPL::READ-FROM-C-STRING/UTF-8 #.(SB-SYS:INT-SAP #X006DEB5B) CHARACTER) (I'm not controlling the server from REPL, so that is not the actual experience with the server, my command just hangs) This is with SBCL 2.3.2. Any advise on how to deal with such errors in a way that would allow reporting an error? =R. |
From: Richard M K. <kr...@pr...> - 2024-08-14 14:28:57
|
steve gonedes writes: > I am having some trouble using the print-function with defstruct. I > cannot remember how to handle the warnings. if one could point me to the > manual. any ideas - run into this problem often. Hi Steve, tl;dr (1) don't worry about it, (2) use the interpreter, (3) tell the compiler more about what you're doing, (4) compile your code in file, (5) load your code from a file. (For clarity: - Each of your two forms refers to a function defined by the other (the definition of PRINT-JTMS refers to JTMS-TITLE, and structure definition for JTMS refers to PRINT-JTMS). So there's an interdependency between the forms. - SBCL's EVAL invokes the compiler by default. In the context of the top level loop, when the evaluator calls the compiler on a form, the form is compiled "separately" and using only the knowledge the compiler has accumulated so far in the Lisp session. - SBCL implicitly proclaims DEFSTRUCT accessors as inlinable. When a function is proclaimed inline, the compiler tries to be helpful by letting the user know if there were previously-compiled calls that weren't inlined. I believe these explain the style warnings you've observed.) Below are several options. Each transcript uses a fresh SBCL session in order to demonstrate the effects under the compiler's initial knowledge of your structure & printer function (i.e., none). (1) Don't worry about it until/unless you have to. (What not to worry about and when you might have to are hard to characterize, though.) (2) If this sort of REPL interaction matters to you, you might configure EVAL to use the interpreter instead of the compiler. (But note that this controls EVAL, not your REPL per se. So LOAD on a source file will also use the interpreter, which might not be what you want. You could rebind the relevant special around LOAD if that matters. Or maybe there's a way to control what function SLIME's REPL calls as its evaluator; IDK.) -- $ sbcl --noinform --no-userinit * (setq sb-ext:*evaluator-mode* :interpret) :INTERPRET * (defun print-jtms (jtms stream ignore) (declare (ignore ignore)) (format stream "#<JTMS: ~A>" (jtms-title jtms))) PRINT-JTMS * (defstruct (jtms (:copier nil) (:print-function print-jtms)) (title nil) (node-counter 0) ;; unique namer for nodes. (just-counter 0) ;; unique namer for justifications. (nodes nil) ;; list of all tms nodes. (justs nil) ;; list of all justifications (debugging nil) ;; debugging flag (contradictions nil) ;; list of contradiction nodes. (assumptions nil) ;; list of assumption nodes. (checking-contradictions T) ;; For external systems (node-string nil) (contradiction-handler nil) (enqueue-procedure nil)) JTMS * (make-jtms) #<JTMS: NIL> -- (3) Tell the compiler more about what you're doing. (3a) Inform the compiler that JTMS-TITLE will be a function, and that you don't want it inlined in the print function -- $ sbcl --noinform --no-userinit * (declaim (ftype function jtms-title)) (JTMS-TITLE) * (defun print-jtms (jtms stream ignore) (declare (ignore ignore)) (locally (declare (notinline jtms-title)) (format stream "#<JTMS: ~A>" (jtms-title jtms)))) PRINT-JTMS * (defstruct (jtms (:copier nil) (:print-function print-jtms)) (title nil) (node-counter 0) ;; unique namer for nodes. (just-counter 0) ;; unique namer for justifications. (nodes nil) ;; list of all tms nodes. (justs nil) ;; list of all justifications (debugging nil) ;; debugging flag (contradictions nil) ;; list of contradiction nodes. (assumptions nil) ;; list of assumption nodes. (checking-contradictions T) ;; For external systems (node-string nil) (contradiction-handler nil) (enqueue-procedure nil)) JTMS * (make-jtms) #<JTMS: NIL> -- (3b) Inform the compiler that PRINT-JTMS will be a function and define the structure first -- $ sbcl --noinform --no-userinit * (declaim (ftype function print-jtms)) (PRINT-JTMS) * (defstruct (jtms (:copier nil) (:print-function print-jtms)) (title nil) (node-counter 0) ;; unique namer for nodes. (just-counter 0) ;; unique namer for justifications. (nodes nil) ;; list of all tms nodes. (justs nil) ;; list of all justifications (debugging nil) ;; debugging flag (contradictions nil) ;; list of contradiction nodes. (assumptions nil) ;; list of assumption nodes. (checking-contradictions T) ;; For external systems (node-string nil) (contradiction-handler nil) (enqueue-procedure nil)) JTMS * (defun print-jtms (jtms stream ignore) (declare (ignore ignore)) (format stream "#<JTMS: ~A>" (jtms-title jtms))) PRINT-JTMS * (make-jtms) #<JTMS: NIL> -- (4) The file compiler is allowed & able to consider a file's forms together as a unit. So it's possible to compile a file containing your 2 forms without any style warnings: (4a) Put the structure definition first if you care about inlining the accessor: -- $ cat foo.lisp (in-package "CL-USER") (defstruct (jtms (:copier nil) (:print-function print-jtms)) (title nil) (node-counter 0) ;; unique namer for nodes. (just-counter 0) ;; unique namer for justifications. (nodes nil) ;; list of all tms nodes. (justs nil) ;; list of all justifications (debugging nil) ;; debugging flag (contradictions nil) ;; list of contradiction nodes. (assumptions nil) ;; list of assumption nodes. (checking-contradictions T) ;; For external systems (node-string nil) (contradiction-handler nil) (enqueue-procedure nil)) (defun print-jtms (jtms stream ignore) (declare (ignore ignore)) (format stream "#<JTMS: ~A>" (jtms-title jtms))) $ sbcl --noinform --no-userinit * (compile-file "foo.lisp") ; compiling file "/home/me/foo.lisp" (written 14 AUG 2024 09:06:27 AM): ; wrote /home/me/foo.fasl ; compilation finished in 0:00:00.038 #P"/home/me/foo.fasl" NIL NIL * (load *) T * (make-jtms) #<JTMS: NIL> -- (4b) Use the recently-restored block compilation feature: -- $ cat bar.lisp (in-package "CL-USER") (defun print-jtms (jtms stream ignore) (declare (ignore ignore)) (format stream "#<JTMS: ~A>" (jtms-title jtms))) (defstruct (jtms (:copier nil) (:print-function print-jtms)) (title nil) (node-counter 0) ;; unique namer for nodes. (just-counter 0) ;; unique namer for justifications. (nodes nil) ;; list of all tms nodes. (justs nil) ;; list of all justifications (debugging nil) ;; debugging flag (contradictions nil) ;; list of contradiction nodes. (assumptions nil) ;; list of assumption nodes. (checking-contradictions T) ;; For external systems (node-string nil) (contradiction-handler nil) (enqueue-procedure nil)) $ sbcl --noinform --no-userinit * (compile-file "bar.lisp" :block-compile t) ; compiling file "/home/me/bar.lisp" (written 14 AUG 2024 09:11:51 AM): ; wrote /home/me/bar.fasl ; compilation finished in 0:00:00.033 #P"/home/me/bar.fasl" NIL NIL * (load *) T * (make-jtms) #<JTMS: NIL> -- (5) Even without compiling a source file, LOAD can be made quieter by deferring style warnings using WITH-COMPILATION-UNIT. This transcript uses the same foo.lisp as in (4a), with the structure definition before the definition of PRINT-JTMS: -- $ sbcl --noinform --no-userinit * (with-compilation-unit () (load "foo.lisp")) T * (make-jtms) #<JTMS: NIL> -- Finally, I suspect that most folks nowadays probably load most of their code from files first, and interact with Lisp at a REPL only afterward. Because that workflow teaches the compiler about a codebase, users who work that way likely won't encounter style warnings for these sorts of "bootstrapping" reasons very often. IOW, when such users do see style warnings, e.g., about undefined functions, they're a bit more salient. Hope some of those help, Richard |
From: <2Qd...@po...> - 2024-08-10 22:46:50
|
On 2024-08-10 at 18:03:49 -0400, steve gonedes <sgo...@gm...> wrote: > I am having some trouble using the print-function with defstruct. I cannot > remember how to handle the warnings. if one could point me to the manual. > any ideas - run into this problem often. I'm no expert, but I notice two things. > ; SLIME 2.26.1 > CL-USER> (defun print-jtms (jtms stream ignore) > (declare (ignore ignore)) > (format stream "#<JTMS: ~A>" (jtms-title jtms))) Have a look at PRINT-UNREADABLE-OBJECT, which takes care of some of what you're doing yourself for you. This is totally separate from DEFSTRUCT and PRINT-FUNCTION. > STYLE-WARNING: > Previously compiled call to COMMON-LISP-USER::JTMS-TITLE could not be > inlined because the structure definition for COMMON-LISP-USER::JTMS was not > yet seen. To avoid this warning, DEFSTRUCT should precede references to the > affected > functions, or they must be declared locally notinline at each call site. Make sure you define your structures first, so that your print functions have full knowledge of the structures and the accessors. You're on your own when it comes to changing your structure definitions and making sure that all the supporting functions recompiled (I keep restarting my REPL over and over until my structures stabilize). HTH |
From: steve g. <sgo...@gm...> - 2024-08-10 22:04:07
|
I am having some trouble using the print-function with defstruct. I cannot remember how to handle the warnings. if one could point me to the manual. any ideas - run into this problem often. ; SLIME 2.26.1 CL-USER> (defun print-jtms (jtms stream ignore) (declare (ignore ignore)) (format stream "#<JTMS: ~A>" (jtms-title jtms))) ; in: DEFUN PRINT-JTMS ; (JTMS-TITLE JTMS) ; ; caught STYLE-WARNING: ; undefined function: COMMON-LISP-USER::JTMS-TITLE ; ; compilation unit finished ; Undefined function: ; JTMS-TITLE ; caught 1 STYLE-WARNING condition PRINT-JTMS CL-USER> ; No value CL-USER> (defstruct (jtms (:copier nil) (:print-function print-jtms)) (title nil) (node-counter 0) ;; unique namer for nodes. (just-counter 0) ;; unique namer for justifications. (nodes nil) ;; list of all tms nodes. (justs nil) ;; list of all justifications (debugging nil) ;; debugging flag (contradictions nil) ;; list of contradiction nodes. (assumptions nil) ;; list of assumption nodes. (checking-contradictions T) ;; For external systems (node-string nil) (contradiction-handler nil) (enqueue-procedure nil)) STYLE-WARNING: Previously compiled call to COMMON-LISP-USER::JTMS-TITLE could not be inlined because the structure definition for COMMON-LISP-USER::JTMS was not yet seen. To avoid this warning, DEFSTRUCT should precede references to the affected functions, or they must be declared locally notinline at each call site. JTMS CL-USER> (create-jtms) ; in: CREATE-JTMS ; (CREATE-JTMS) ; ; caught STYLE-WARNING: ; undefined function: COMMON-LISP-USER::CREATE-JTMS ; ; compilation unit finished ; Undefined function: ; CREATE-JTMS ; caught 1 STYLE-WARNING condition ; Evaluation aborted on #<UNDEFINED-FUNCTION CREATE-JTMS {10070C7903}>. CL-USER> (make-jtms) #<JTMS: NIL> CL-USER> (defstruct (jtms (:copier nil) (:print-function print-jtms)) (title nil) (node-counter 0) ;; unique namer for nodes. (just-counter 0) ;; unique namer for justifications. (nodes nil) ;; list of all tms nodes. (justs nil) ;; list of all justifications (debugging nil) ;; debugging flag (contradictions nil) ;; list of contradiction nodes. (assumptions nil) ;; list of assumption nodes. (checking-contradictions T) ;; For external systems (node-string nil) (contradiction-handler nil) (enqueue-procedure nil)) |
From: steve g. <sgo...@gm...> - 2024-08-08 23:25:13
|
On 8/7/24 09:13, sbc...@li... wrote: > Send Sbcl-help mailing list submissions to oh no, not again. |
From: steve g. <sgo...@gm...> - 2024-08-08 23:22:02
|
On 8/6/24 09:02, sbc...@li... wrote: > Send Sbcl-help mailing list submissions to > sbc...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/sbcl-help > or, via email, send a message with subject or body 'help' to > sbc...@li... > > You can reach the person managing the list at > sbc...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Sbcl-help digest..." > > > Today's Topics: > > 1. Re: Reason behind semicolumns (i.e. "inline comments") in > system output? (Andreas Franke) > 2. Re: Reason behind semicolumns (i.e. "inline comments") in > system output? (Richard M Kreuter) > > > > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help the use of quotations used to be represented by the reader-case. this is a pain in the ass. case will only slow down the reader. not to mention 2 reader macros for #'e and #'E. LISP is case insensitive on input. period. |
From: steve g. <sgo...@gm...> - 2024-08-08 23:17:42
|
On 8/5/24 09:11, sbc...@li... wrote: > Send Sbcl-help mailing list submissions to > sbc...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/sbcl-help > or, via email, send a message with subject or body 'help' to > sbc...@li... > > You can reach the person managing the list at > sbc...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Sbcl-help digest..." > > > Today's Topics: > > 1. Reason behind semicolumns (i.e. "inline comments") in system > output? (Jan J.) > > > one use of comments for/debugging is to make copy and pasting easier. I always felt that they provided a more professional way of determining input from user vs output/input of the lisp. i think every lisp program and C program I have ever written has similar cruft. (defparameter *debugging-rules* t) (defmacro debugging-rules (msg &rest args) `(when *debugging-rules* (format *debug-io* ,msg ,@args))) (defun insert-new (tre fact) (assert fact () "Can't assert NIL.") (let ((dbclass (get-dbclass tre fact))) ;;; ----- (debugging-rules "~%;; insert-new fact: ~w" fact) ;;;; ------ (cond ((member fact (dbclass-facts dbclass) :test #'equal) nil) ((zerop (tre-depth tre)) (push fact (dbclass-facts dbclass))) ((member fact (tre-local-data tre) :test #'equal) nil) (t (push fact (tre-local-data tre)))))) I don't have any C at the moment but i use GCC and varadic macros and asprintf a whole lot. you must recompile the entire program when doing this though. |
From: Shubhamkar A. <shu...@ya...> - 2024-08-08 11:32:35
|
Thanks a ton! Shubhamkar / digikar |
From: Stas B. <sta...@gm...> - 2024-08-07 22:49:15
|
Fixed. Thanks. On Wed, Aug 7, 2024 at 5:34 AM Shubhamkar Ayare <shu...@ya...> wrote: > > Okay, here's the example stripped away from my libraries and reproduceable > in a > fresh SBCL 2.4.7. Below, ARRAY-STORAGE-SUM/ROW-MAJOR-AREF compiles, but > ARRAY-STORAGE-SUM/AREF does not. The compilation is also successful if we > remove > the (DECLARE (TYPE ARRAY ARRAY)) from ARRAY-STORAGE-SUM/AREF. > > > (in-package :cl-user) > > (deftype size () `(unsigned-byte 62)) > > (declaim (inline cl-array-offset)) > (declaim (ftype (function (cl:array) size) cl-array-offset)) > (defun cl-array-offset (array) > (declare (optimize speed) > (type cl:array array)) > (loop :with total-offset :of-type (signed-byte 61) := 0 > :if (typep array 'cl:simple-array) > :do (return total-offset) > :else > :do (multiple-value-bind (displaced-to offset) > (cl:array-displacement array) > (declare (type (signed-byte 61) offset)) > (incf total-offset offset) > (setq array displaced-to)))) > > (declaim (inline array-storage) > (ftype (function (cl:array) (cl:simple-array * 1)))) > (defun array-storage (array) > (declare (optimize speed)) > (loop :with array := array > :do (typecase array > ((cl:simple-array * (*)) (return array)) > (cl:simple-array (sb-ext:array-storage-vector array)) > (t (setq array (cl:array-displacement array)))))) > > (defun array-storage-sum/row-major-aref (array) > (declare (type array array)) > (let ((asv (array-storage array)) > (offset (cl-array-offset array)) > (sum 0)) > (loop :for i :from offset :below (+ offset (array-total-size > array)) > :do (incf sum (row-major-aref asv i))) > sum)) > > (defun array-storage-sum/aref (array) > (declare (type array array)) > (let ((asv (array-storage array)) > (offset (cl-array-offset array)) > (sum 0)) > (loop :for i :from offset :below (+ offset (array-total-size > array)) > :do (incf sum (aref asv i))) > sum)) > |
From: Shubhamkar A. <shu...@ya...> - 2024-08-07 02:35:05
|
Okay, here's the example stripped away from my libraries and reproduceable in a fresh SBCL 2.4.7. Below, ARRAY-STORAGE-SUM/ROW-MAJOR-AREF compiles, but ARRAY-STORAGE-SUM/AREF does not. The compilation is also successful if we remove the (DECLARE (TYPE ARRAY ARRAY)) from ARRAY-STORAGE-SUM/AREF. (in-package :cl-user) (deftype size () `(unsigned-byte 62)) (declaim (inline cl-array-offset)) (declaim (ftype (function (cl:array) size) cl-array-offset)) (defun cl-array-offset (array) (declare (optimize speed) (type cl:array array)) (loop :with total-offset :of-type (signed-byte 61) := 0 :if (typep array 'cl:simple-array) :do (return total-offset) :else :do (multiple-value-bind (displaced-to offset) (cl:array-displacement array) (declare (type (signed-byte 61) offset)) (incf total-offset offset) (setq array displaced-to)))) (declaim (inline array-storage) (ftype (function (cl:array) (cl:simple-array * 1)))) (defun array-storage (array) (declare (optimize speed)) (loop :with array := array :do (typecase array ((cl:simple-array * (*)) (return array)) (cl:simple-array (sb-ext:array-storage-vector array)) (t (setq array (cl:array-displacement array)))))) (defun array-storage-sum/row-major-aref (array) (declare (type array array)) (let ((asv (array-storage array)) (offset (cl-array-offset array)) (sum 0)) (loop :for i :from offset :below (+ offset (array-total-size array)) :do (incf sum (row-major-aref asv i))) sum)) (defun array-storage-sum/aref (array) (declare (type array array)) (let ((asv (array-storage array)) (offset (cl-array-offset array)) (sum 0)) (loop :for i :from offset :below (+ offset (array-total-size array)) :do (incf sum (aref asv i))) sum)) |
From: Shubhamkar A. <shu...@ya...> - 2024-08-07 01:24:01
|
I will submit once I strip it down to a minimal example. -------- Original message --------From: Stas Boukarev <sta...@gm...> Date: 07/08/24 01:07 (GMT+05:30) To: Shubhamkar Ayare <shu...@ya...> Cc: sbc...@li... Subject: Re: [Sbcl-help] Potential infinite loop in sb-c::array-type-upgraded-element-type with sb-kernel:union-type Submit the original form.On Tue, Aug 6, 2024 at 10:36 PM Shubhamkar Ayare via Sbcl-help <sbc...@li...> wrote:I discovered the above function calls while trying to debug a stuck-on-compilation issue in one of my libraries.Thanks for pointing out that this function call is not supposed to happen! So, the bug must lie in whatever macroexpansion and compiler macroexpansion my library is performing. I will debug that part.-------- Original message --------From: Douglas Katzman <do...@go...> Date: 07/08/24 00:20 (GMT+05:30) To: Shubhamkar Ayare <shu...@ya...> Cc: sbc...@li... Subject: Re: [Sbcl-help] Potential infinite loop in sb-c::array-type-upgraded-element-type with sb-kernel:union-type In both usages you are calling the function in ways that it should not be called by the compiler.NULL hits the member-type case and the (mapcar #'ctype-of) returns the same object, so it recurses on the same arg that it was called with; i.e. there is no base case to the recursion.In the second example you're just plain calling it wrong.What point are you trying to make by exercising an internal function incorrectly though?On Tue, Aug 6, 2024 at 2:36 PM Shubhamkar Ayare via Sbcl-help <sbc...@li...> wrote: On SBCL 2.4.7 (and also 2.4.4 and 2.4.5), the following seems to result in an infinite loop. It never returns despite running for 10 seconds. (sb-c::array-type-upgraded-element-type (sb-kernel:specifier-type '(or array null))) By contrast, the following returns almost immediately: (sb-c::array-type-upgraded-element-type '(or array null)) Is the difference of behavior a bug? Best, Shubhamkar / digikar _______________________________________________ Sbcl-help mailing list Sbc...@li... https://lists.sourceforge.net/lists/listinfo/sbcl-help _______________________________________________ Sbcl-help mailing list Sbc...@li... https://lists.sourceforge.net/lists/listinfo/sbcl-help |
From: Stas B. <sta...@gm...> - 2024-08-06 19:37:13
|
Submit the original form. On Tue, Aug 6, 2024 at 10:36 PM Shubhamkar Ayare via Sbcl-help < sbc...@li...> wrote: > I discovered the above function calls while trying to debug a > stuck-on-compilation issue in one of my libraries. > > Thanks for pointing out that this function call is not supposed to happen! > So, the bug must lie in whatever macroexpansion and compiler macroexpansion > my library is performing. I will debug that part. > > -------- Original message -------- > From: Douglas Katzman <do...@go...> > Date: 07/08/24 00:20 (GMT+05:30) > To: Shubhamkar Ayare <shu...@ya...> > Cc: sbc...@li... > Subject: Re: [Sbcl-help] Potential infinite loop in > sb-c::array-type-upgraded-element-type with sb-kernel:union-type > > In both usages you are calling the function in ways that it should not be > called by the compiler. > > NULL hits the member-type case and the (mapcar #'ctype-of) returns the > same object, so it recurses on the same arg that it was called with; i.e. > there is no base case to the recursion. > In the second example you're just plain calling it wrong. > > What point are you trying to make by exercising an internal function > incorrectly though? > > On Tue, Aug 6, 2024 at 2:36 PM Shubhamkar Ayare via Sbcl-help < > sbc...@li...> wrote: > >> >> On SBCL 2.4.7 (and also 2.4.4 and 2.4.5), the following seems to result >> in an >> infinite loop. It never returns despite running for 10 seconds. >> >> (sb-c::array-type-upgraded-element-type (sb-kernel:specifier-type >> '(or array null))) >> >> By contrast, the following returns almost immediately: >> >> (sb-c::array-type-upgraded-element-type '(or array null)) >> >> Is the difference of behavior a bug? >> >> Best, >> Shubhamkar / digikar >> >> >> _______________________________________________ >> Sbcl-help mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-help >> > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help > |
From: Shubhamkar A. <shu...@ya...> - 2024-08-06 19:34:24
|
I discovered the above function calls while trying to debug a stuck-on-compilation issue in one of my libraries.Thanks for pointing out that this function call is not supposed to happen! So, the bug must lie in whatever macroexpansion and compiler macroexpansion my library is performing. I will debug that part. -------- Original message --------From: Douglas Katzman <do...@go...> Date: 07/08/24 00:20 (GMT+05:30) To: Shubhamkar Ayare <shu...@ya...> Cc: sbc...@li... Subject: Re: [Sbcl-help] Potential infinite loop in sb-c::array-type-upgraded-element-type with sb-kernel:union-type In both usages you are calling the function in ways that it should not be called by the compiler.NULL hits the member-type case and the (mapcar #'ctype-of) returns the same object, so it recurses on the same arg that it was called with; i.e. there is no base case to the recursion.In the second example you're just plain calling it wrong.What point are you trying to make by exercising an internal function incorrectly though?On Tue, Aug 6, 2024 at 2:36 PM Shubhamkar Ayare via Sbcl-help <sbc...@li...> wrote: On SBCL 2.4.7 (and also 2.4.4 and 2.4.5), the following seems to result in an infinite loop. It never returns despite running for 10 seconds. (sb-c::array-type-upgraded-element-type (sb-kernel:specifier-type '(or array null))) By contrast, the following returns almost immediately: (sb-c::array-type-upgraded-element-type '(or array null)) Is the difference of behavior a bug? Best, Shubhamkar / digikar _______________________________________________ Sbcl-help mailing list Sbc...@li... https://lists.sourceforge.net/lists/listinfo/sbcl-help |
From: Douglas K. <do...@go...> - 2024-08-06 18:50:44
|
In both usages you are calling the function in ways that it should not be called by the compiler. NULL hits the member-type case and the (mapcar #'ctype-of) returns the same object, so it recurses on the same arg that it was called with; i.e. there is no base case to the recursion. In the second example you're just plain calling it wrong. What point are you trying to make by exercising an internal function incorrectly though? On Tue, Aug 6, 2024 at 2:36 PM Shubhamkar Ayare via Sbcl-help < sbc...@li...> wrote: > > On SBCL 2.4.7 (and also 2.4.4 and 2.4.5), the following seems to result in > an > infinite loop. It never returns despite running for 10 seconds. > > (sb-c::array-type-upgraded-element-type (sb-kernel:specifier-type '(or > array null))) > > By contrast, the following returns almost immediately: > > (sb-c::array-type-upgraded-element-type '(or array null)) > > Is the difference of behavior a bug? > > Best, > Shubhamkar / digikar > > > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help > |
From: Shubhamkar A. <shu...@ya...> - 2024-08-06 18:35:44
|
On SBCL 2.4.7 (and also 2.4.4 and 2.4.5), the following seems to result in an infinite loop. It never returns despite running for 10 seconds. (sb-c::array-type-upgraded-element-type (sb-kernel:specifier-type '(or array null))) By contrast, the following returns almost immediately: (sb-c::array-type-upgraded-element-type '(or array null)) Is the difference of behavior a bug? Best, Shubhamkar / digikar |
From: Richard M K. <kr...@pr...> - 2024-08-05 15:59:56
|
Jan J. via Sbcl-help <sbc...@li...> wrote: > Is there any particular reason as to why some REPL output has > semicolumns prefixing it, as though it is trying to comment it out? I believe it's an informal custom. ANSI requires whatever messages COMPILE-FILE and LOAD print when VERBOSE is true to be in the form of a comment, and SLIME implements comment formatting. but I doubt the custom is very consistently observed. > I am curious about the source/history of this convention. I don't know exactly, but here's some "just so" storytelling. - Lisp development is canonically an interaction with a long-running session. A minimal interactive environment would have one channel for input from the user and one channel for output to the user. In such an environment, if there's ever a need to transmit information other than a user program's "primary" output, prefixing any "non-primary" output (e.g., non-interactive error and warning reports, diagnostics, timings, tracing, progress reports, GC notices, etc.) with a semicolon makes it easier for a user to distinguish things. - The custom might remain useful even where it's not absolutely necessary. For example, even if "primary" and "non-primary" outputs could technically go to distinct windows, users might like them co-mingled to make the sequential execution order clear. - It's pretty ordinary to write Lisp programs that process programs. A "processor" and "processee" might each have "primary" output. For example, a compiler might have something to say about code in a file, and the code in the file might have its own things to say during compilation. If a processor shares its output stream with its processee, having the processor prefix its output with a semicolon (or just differently many semicolons than its processee) makes it easier for a user to discern origins. Regards, Richard |
From: Andreas F. <a.f...@gm...> - 2024-08-05 15:35:31
|
I seem to recall that the motivation for prefixing arbitrary REPL output with semicolons (";") was to preserve readability of readably-printed expressions (or sequences thereof) even if they were "interrupted" by such messages. HTH, Andreas |
From: Jan J. <jou...@pr...> - 2024-08-05 00:38:59
|
Is there any particular reason as to why some REPL output has semicolumns prefixing it, as though it is trying to comment it out? Example (SLIME): - CL-USER> (error 123) ; Evaluation aborted on #<TYPE-ERROR expected-type: ; (OR STRING FUNCTION SYMBOL CONDITION SB-PCL::CONDITION-CLASS) ; datum: 123>. CL-USER> ; No valueCL-USER> I always assumed it was just a way for the implementation to differentiate between its own "system" messages, and the rest of the Lisp messages. I am curious about the source/history of this convention. |
From: Grégory V. <g.v...@gm...> - 2024-07-26 11:49:24
|
Hello, Yes, install ccl-bin with ‘ros install ccl-bin’ and, as suggested by Jerôme, switch to and from with: ros use sbcl (or sbcl-bin, depending on your settings) Or ros use ccl-bin ‘ros use’ alone will list you the installed CL on your system. Personnally I own the two CL versions in Roswell but I prefer system wide CL. Greg Le ven. 26 juil. 2024 à 11:00, Jérôme Radix <jer...@gm...> a écrit : > Hello, > > have you tried something like : > ros use ccl/system > > ? > > Regards, > Jérôme. > > Le ven. 26 juil. 2024 à 06:44, Christopher Stacy <cs...@dt...> a > écrit : > >> OK, I have it semi-figured out. >> >> After frobbing around, I now have the old ASDF searching >> ~/.config/common-lisp >> working in all Lisps. >> This looks like it was perhaps my own typos. >> (Which I didn't see, even when I posted my transcripts, duh!) >> >> Now I am left with one minor issue, >> which is that I have two quicklisp trees. >> There's one in my home directory that is >> required by CCL, and the one under .roswell >> is required for the Roswell SBCL. >> >> I tried swapping and linking games, and that >> just results in one or the other of the repls >> crashing (infinite loop) while SLIME is trying >> to get going. >> >> I wish there was a way to have just one Quickisp. >> >> My main remaining questions about Roswell are: >> 1, Should I install the CCL there, too? >> 2. Could I still use CCL and SBCL in the same Emacs, >> at the same time, like I do now when CCL is not under >> Roswell? Right now I just do "ros -Q run" and I get SBCL. >> Is there a way to pick? >> 3. Roswell is using ASDF to dump the binary standalone programs, >> right? That wasn't something ASDF used to do, but I am guessing >> that some functions in UIOP are what's getting called. >> >> At least I can compile my old and new programs again now. >> >> THANKS! >> >> >> >> >> _______________________________________________ >> Sbcl-help mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-help >> > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help > |
From: Jérôme R. <jer...@gm...> - 2024-07-26 08:59:28
|
Hello, have you tried something like : ros use ccl/system ? Regards, Jérôme. Le ven. 26 juil. 2024 à 06:44, Christopher Stacy <cs...@dt...> a écrit : > OK, I have it semi-figured out. > > After frobbing around, I now have the old ASDF searching > ~/.config/common-lisp > working in all Lisps. > This looks like it was perhaps my own typos. > (Which I didn't see, even when I posted my transcripts, duh!) > > Now I am left with one minor issue, > which is that I have two quicklisp trees. > There's one in my home directory that is > required by CCL, and the one under .roswell > is required for the Roswell SBCL. > > I tried swapping and linking games, and that > just results in one or the other of the repls > crashing (infinite loop) while SLIME is trying > to get going. > > I wish there was a way to have just one Quickisp. > > My main remaining questions about Roswell are: > 1, Should I install the CCL there, too? > 2. Could I still use CCL and SBCL in the same Emacs, > at the same time, like I do now when CCL is not under > Roswell? Right now I just do "ros -Q run" and I get SBCL. > Is there a way to pick? > 3. Roswell is using ASDF to dump the binary standalone programs, > right? That wasn't something ASDF used to do, but I am guessing > that some functions in UIOP are what's getting called. > > At least I can compile my old and new programs again now. > > THANKS! > > > > > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help > |
From: Christopher S. <cs...@dt...> - 2024-07-26 04:43:26
|
OK, I have it semi-figured out. After frobbing around, I now have the old ASDF searching ~/.config/common-lisp working in all Lisps. This looks like it was perhaps my own typos. (Which I didn't see, even when I posted my transcripts, duh!) Now I am left with one minor issue, which is that I have two quicklisp trees. There's one in my home directory that is required by CCL, and the one under .roswell is required for the Roswell SBCL. I tried swapping and linking games, and that just results in one or the other of the repls crashing (infinite loop) while SLIME is trying to get going. I wish there was a way to have just one Quickisp. My main remaining questions about Roswell are: 1, Should I install the CCL there, too? 2. Could I still use CCL and SBCL in the same Emacs, at the same time, like I do now when CCL is not under Roswell? Right now I just do "ros -Q run" and I get SBCL. Is there a way to pick? 3. Roswell is using ASDF to dump the binary standalone programs, right? That wasn't something ASDF used to do, but I am guessing that some functions in UIOP are what's getting called. At least I can compile my old and new programs again now. THANKS! |
From: Christopher S. <cs...@dt...> - 2024-07-26 01:20:19
|
sThis is more about ASDF than a particular Lisp. I haven't been using CL for a while, and it seems that the theory of using ASDF has changed a bit. I also in that past used Quicklisp, just to fetch external packages. ASDF and QL seem to have become friends since those days. So, I am having the same issue in both SBCL and CCL. (My SBCL is installed with Roswell, the CCL is not, and they both seem to behave the exactly the same.) There are no user init files. What used to work, and doesn't anymore, was to just put certain magic files under ~/.config/common-lisp/source-registry.conf.d For example, under there was "Firemacs.conf", which contained this line: (:directory "~cstacy/F/defsys/") And in that directory was (a link to) the ASD file (in the superior "F" directory). None of that works anymore. I tried fiddling those a little in case they were not quite right, but didn't get anywhere. I don't think anything is even looking in the ".config" directory. Now I have read online that you're not supposed to touch or pay attention to asdf:*central-registry* and files (?) just go under quicklisp. Or something. So here's what I have tried today. ;; In a fresh Lisp of either flavor CL-USER> asdf:*central-registry* (#P"/Users/cstacy/quicklisp/quicklisp/") CL-USER> (asdf:find-system :fm nil) NIL ;; Same thing for "FM" and ':fm Listing ~/quicklisp/local-projects/ fm/ system-index.txt Lisring ~/quicklisp/local-projects/fm/ fm.conf Connents: (:directory "~/Hack/FM/defsys/") Listing ~/Hack/FM/defsys/ fm.asd -> ../v/2/src/s/fm.asd Contnts: (in-package #:cl-user) (asdf:defsystem :fm :serial t :components ((:file "pkgdcl") ... How is this all supposed to work these days? Thanks! PS. Extra credit question. I discovered Roswell the other day. I suspect its just calling some new capability of ASDF to actually dump an image? If so, what is it I need Roswell for again? (Until yesterday I just built everything from source, and it all worked fine. CCL is still the version I built and works fine.) I'm not really using it for shebang scripts. And confusingly it has its own copy of Quicklisp and local-projects. I did try linking that local projects to my toplevel one; that did nothing. I don't want multiple copies of the repository, either, and I am not always using Roswell, anyway. THANKS AGAIN! |
From: steph.tougard <ste...@pm...> - 2024-07-16 10:39:15
|
Thanks for the help, at this point I applied Christophe solution and it worked fine. But I know it's not a long term solution because UCS-2 SMS are sent in UTF-8 so I'll encounter some problems when I'll work on this part. I'll be sure to keep the list updated on my progress if I reach this point, it's a personal project (there are very good SMPP servers and the world does need another one, there are just none in CL). On Tuesday, July 16th, 2024 at 4:49 PM, Jérôme Radix <jer...@gm...> wrote: > Hi Steph, > > here is a little strace output (strace.out) showing that : > - you effectively have 22 bytes > - (length answer) returns 21 because of character C2 which is more than 127 and this mess FORMAT and UTF-8 (see Christophe answer) > > To help you see the characters in your answer string, in rbind, replace in sbcl : > (format t "~A (~A)~%" answer (length answer)) > by > (format t "~A (~A)~%" (sb-ext:string-to-octets answer) (length (sb-ext:string-to-octets answer))) > > it prints : > #(0 0 0 21 194 128 0 0 1 0 0 0 0 0 0 0 1 83 77 80 80 0) (22) > > I would be glad to see your final solution, > > Regards, > Jérôme. > > Le mar. 16 juil. 2024 à 10:00, Marco Antoniotti <mar...@un...> a écrit : > >> Hi Stephane >> >> you may want to have a look at babel and maybe cl-pack for encoding and decoding. I am sure there are others around and some of them may suffer from some bit rot. >> >> All the best >> >> Marco >> >> On Tue, Jul 16, 2024 at 9:49 AM Christophe Rhodes <cs...@ca...> wrote: >> >>> "steph.tougard via Sbcl-help" <sbc...@li...> writes: >>> >>>> For those who don't know, SMPP is a binary protocol over TCP to send >>>> SMS. Unlike SMPP or HTTP, each frame is sent or received between the >>> >>> SMPP is a binary protocol, but your Lisp code uses characters and >>> strings. This means that there will be an encoding step on the Lisp >>> side, to convert from characters to binary. >>> >>> In most lisps nowadays, the default encoding scheme is probably utf-8, >>> which encodes the ASCII repertoire (the first 128 characters of Unicode) >>> as single bytes, but uses multiple bytes for all other characters. >>> >>> I would guess that the string that you are attempting to send contains a >>> character with char-code greater than 127, and that your stream is set >>> up to convert characters using utf-8. >>> >>> You are using usocket, which does not allow users to specify external >>> formats directly. You could try setting >>> sb-ext:*default-external-format* to :latin-1 before starting your >>> server, or you could send binary (rather than string) data to your >>> socket, performing the character to binary conversion yourself rather >>> than making it implicit. >>> >>> Christophe >>> >>> _______________________________________________ >>> Sbcl-help mailing list >>> Sbc...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbcl-help >> >> -- >> >> Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 >> DISCo, University of Milan-Bicocca U14 2043 http://dcb.disco.unimib.it >> Viale Sarca 336 >> I-20126 Milan (MI) ITALY >> _______________________________________________ >> Sbcl-help mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-help |
From: Jérôme R. <jer...@gm...> - 2024-07-16 09:49:38
|
Hi Steph, here is a little strace output (strace.out) showing that : - you effectively have 22 bytes - (length answer) returns 21 because of character C2 which is more than 127 and this mess FORMAT and UTF-8 (see Christophe answer) To help you see the characters in your answer string, in rbind, replace in sbcl : (format t "~A (~A)~%" answer (length answer)) by (format t "~A (~A)~%" (sb-ext:string-to-octets answer) (length (sb-ext:string-to-octets answer))) it prints : #(0 0 0 21 194 128 0 0 1 0 0 0 0 0 0 0 1 83 77 80 80 0) (22) I would be glad to see your final solution, Regards, Jérôme. Le mar. 16 juil. 2024 à 10:00, Marco Antoniotti <mar...@un...> a écrit : > Hi Stephane > > you may want to have a look at *babel* and maybe *cl-pack* for encoding > and decoding. I am sure there are others around and some of them may > suffer from some bit rot. > > All the best > > Marco > > On Tue, Jul 16, 2024 at 9:49 AM Christophe Rhodes <cs...@ca...> > wrote: > >> "steph.tougard via Sbcl-help" <sbc...@li...> writes: >> >> > For those who don't know, SMPP is a binary protocol over TCP to send >> > SMS. Unlike SMPP or HTTP, each frame is sent or received between the >> >> SMPP is a binary protocol, but your Lisp code uses characters and >> strings. This means that there will be an encoding step on the Lisp >> side, to convert from characters to binary. >> >> In most lisps nowadays, the default encoding scheme is probably utf-8, >> which encodes the ASCII repertoire (the first 128 characters of Unicode) >> as single bytes, but uses multiple bytes for all other characters. >> >> I would guess that the string that you are attempting to send contains a >> character with char-code greater than 127, and that your stream is set >> up to convert characters using utf-8. >> >> You are using usocket, which does not allow users to specify external >> formats directly. You could try setting >> sb-ext:*default-external-format* to :latin-1 before starting your >> server, or you could send binary (rather than string) data to your >> socket, performing the character to binary conversion yourself rather >> than making it implicit. >> >> Christophe >> >> >> _______________________________________________ >> Sbcl-help mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-help >> > > > -- > Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 > DISCo, University of Milan-Bicocca U14 2043 http://dcb.disco.unimib.it > Viale Sarca 336 > I-20126 Milan (MI) ITALY > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help > |