sharplispers / cormanlisp Goto Github PK

client's job works well, but on exit a popup inform me about an error
and a CormanLisp_Dump.log is flushed.
If it helps: this is the very first lines

The operating system has reported a memory access violation at the address 00000008.

Registers:
EAX: 00000000
{Integer: 0}
EBX: 4326fba4
{Warning: Unknown or untagged value: 4326fba4}
ECX: 00000000
{Integer: 0}
EDX: 03070005
{Symbol: NIL}
ESI: 0084a078
{Integer: 10940f}
EDI: 03070005
{Symbol: NIL}
ESP: 4326fb60
EBP: 4326fb68
EIP: 520de44c

Environment:
Corman Common Lisp 3.1 (Patch level 2) under Windows 10 64bit

Issue:
The Format function's F directive's k parameter fails to move the decimal point of the floating point argument to the right when preceded by a tilde and 2 consecutive commas. This fails in Corman CL, but works in SBCL 1.4.14 64bit and in Clisp 2.49 when tested.

Corman CL Example1: Note the issue is that 0.1 is returned rather than 10.0

(format t "10 Percent ~,,2f ~%" .10)
10 Percent 0.1 
NIL

SBCL Example1: SBCL produces the correct result, just as Clisp does.

* (format t "10 Percent ~,,2f ~%" .10)
10 Percent 10.0
NIL

Other Format F directive k parameter scenarios seem to work fine for Corman CL...

Corman CL Example2: Corman CL correctly produces the same result as SBCL if a 0 or 1 is entered for the d parameter (decimal digits) between the two commas before the k parameter.

(format t "10 Percent ~,1,2f ~%" .10)
10 Percent 10.0 
NIL

(format t "10 Percent ~,0,2f ~%" .10)
10 Percent 10. 
NIL

SBCL Example2: The same correct results as Clisp and Corman CL.

* (format t "10 Percent ~,1,2f ~%" .10)
10 Percent 10.0
NIL

* (format t "10 Percent ~,0,2f ~%" .10)
10 Percent 10.
NIL

Reference:

1. This is the same issue found and fixed in Clozure Common Lisp. This is an oddly obscure bug to coincidentally share with another Common Lisp implementation. Perhaps the solution used to fix Clozure CL can also be used for Corman CL? Do the two Common Lisp implementations already share some code? If yes, can additional Clozure CL code be used to fix other/future Corman CL issues as they're found? See the following closed Clozure CL issue:
   The Format function's F directive's k parameter fails when preceded by a tilde and 2 commas
   Clozure/ccl#51

2. CLHS: 22.3.3.1 Tilde F: Fixed-Format Floating-Point.
   "The full form is ~w,d,k,overflowchar,padcharF. The parameter w is the width of the field to be printed; d is the number of digits to print after the decimal point; k is a scale factor that defaults to zero."
   http://www.lispworks.com/documentation/HyperSpec/Body/22_cca.htm

Also, see issue #32.

Currently CormanLisp use MFC, do you think that could be valuable to porting to QT ?

There are some issues with FASL reading/writing. Right now Corman Lisp might crash when loading RDNZL. Corman Lisp tries to produce some FASLs when trying to load RDNZL at the first time. At this point, Corman Lisp might crash.

To reproduce the bug one should remove the produced FASLs and try to load the library again.

From #42:

Perhaps, you could update that old WineHQ entry after some testing and increase the Corman Lisp "Version" number from 3.0? The old entry stated that the Program's "main window is not usable". But, your screenshot shows use!

@arbv Could you assign this issue to me?

Corman CL works quite well in HDPI mode, except for the toolbar icons, as can be seen in the screenshot above.

My system is Windows XP SP3(32bit) and run in Vbox, and VS is VS 2005 8.0.50727.42.

I running makeall.bat：

....
Compiling sys/misc-utility.lisp
Compiling sys/context-menu.lisp
Compiling sys/setf-expander.lisp
Compiling sys/sockets.lisp
Compiling sys/xp.lisp
Compiling sys/threads.lisp
Compiling sys/auto-update.lisp
Compiling sys/jumpmenu.lisp
Compiling sys/ide-menus.lisp
NIL

As shown above, then compiling sys/ide-menus.lisp is return NIL, and was interrupted by VS2005 Debugger. In the VS show in ASM code:

7813BD82  pop         esi  
7813BD83  xor         ecx,ebp 
7813BD85  pop         ebx  
7813BD86  call        78139A71 
7813BD8B  add         ebp,2B8h 
7813BD91  leave            
7813BD92  ret              
7813BD93  and         dword ptr ds:[781C4920h],0   <- break in here

Visual Studio 2013 Community Edition is the first free version of Visual Studio that could support MFC/ATL. If CormanLisp can be built in this version and run without issue, this will give much more Lispers the opportunity (and interest) to help maintaining CormanLisp.

Current status is: the VS2013 solution (src_vc12.sln) and related VC projects are ready in Git code base, and all components can be built without any compiler and linker error. And the console version of CormanLisp (clconsole.exe) even seems working well, but the IDE version has some serious issues (i.e. trying to show the About dialog will cause the whole IDE crash).

Corman Lisp is currently not executable via Wine; for some reaso, it complains that CormanLisp.exe is a DOS application.

$ wine --version
wine-3.13 (Staging)
$ wine CormanLisp.exe 
000b:fixme:winediag:start_process Wine Staging 3.13 is a testing version containing experimental patches.
000b:fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org.
winevdm: C:\Program Files\Corman Lisp\CormanLisp.exe is a DOS application, you need to install DOSBox.

Reproduction:

(macroexpand-1 '(defpackage #:foobar (:use #:does-not-exist)))

Error:

;;; An error of type SIMPLE-ERROR was detected in function CHECK-TYPE-BODY:
;;; Error: The value of P, NIL, is not of type PACKAGE
;;; Entering Corman Lisp debug loop. 
;;; Use :C followed by an option to exit. Type :HELP for help.
;;; Restart options:
;;; 1   Abort to top level.

I traced the error to a mapcar call in the defpackage macro that attempts to change a list of packages into strings via package-name. That list is generated from the package-designators in the :use subform, and if an undefined package was in that list, then the corresponding element in the package list will be a string instead of a package.

Fixing that bug (see patch), a further bug exists: The macro does not show which package didn't exist. You end up getting this error:

;;; An error of type SIMPLE-ERROR was detected in function ADD-USED-PACKAGE:
;;; Error: Not a package: NIL
;;; Entering Corman Lisp debug loop. 
;;; Use :C followed by an option to exit. Type :HELP for help.
;;; Restart options:
;;; 1   Abort to top level.

That happens because defpackage doesn't check if the package exists before or after
using find-package. The result is that NIL gets passed to use-package and no further
information is available.

This can be fixed by checking if find-package returns NIL before using it, and signalling an
error while the name of the package is still known.

Here is a diff patch to fix both problems.

Unfortunately, GitHub doesn't allow patches to be attached, so I'll have to just paste it here:

--- defpackage.lisp     2015-01-06 01:08:14.000000000 -0500
+++ /tmp/defpackage.lisp        2015-06-06 13:16:18.000000000 -0400
@@ -140,7 +140,7 @@
                         (remove-duplicates
                             (append use
                                 (mapcar #'(lambda (pkg) (canonicalize-package-designator pkg nil)) value)))))
-                               (:import-from (push value import-from))
+                       (:import-from (push value import-from))
                                (:intern (setq intern (append intern (mapcar #'string value))))
                                (:export (setq export (append export (mapcar #'string value))))
                                (:documentation
@@ -156,12 +156,20 @@
                         :nicknames ',(remove-duplicates nicknames :test #'string-equal)
                         :use nil
                         ,@(when size `(:size ,size)))) forms))
-        (setq use (mapcar (lambda (package) (package-name package)) use))   ;; list package names, not packages
+        (setq use (mapcar (lambda (package)
+                            (if (packagep package)
+                                (package-name package)
+                                 package)) use))   ;; list package names, not packages
                (when shadow
                  (push `(shadow ',shadow ',name) forms))
                (when shadowing-import-from
           (push `,(build-import-forms name shadowing-import-from t) forms))
                (when use
+          (let ((pkg (gensym)))
+                (push
+                `(loop for ,pkg in (list ,@use)
+                    unless (find-package ,pkg)
+                    do (error "No such package ~a" ,pkg)) forms))
                  (push `(use-package ',use ',name) forms))
                (when import-from
           (push `,(build-import-forms name import-from nil) forms))
@@ -174,9 +182,8 @@
                (when documentation
                  (push `(setf (documentation ',(intern (string name)) 'package) ,documentation) forms))
                (push `(find-package ',name) forms)
-
                `(eval-when (:load-toplevel :compile-toplevel :execute)
-                       ,@(nreverse forms))))
+                       ,@(nreverse forms))))

 ;; support function for DO-SYMBOLS, etc.
 (defun iterate-over-package (package func &optional external-only)

At this point in many cases (e. g. crash reports, "Lisp Worksheet" file creation, executables creation) Corman Lisp uses installation directory for output. I think this is not a good scenario for usage of the Corman Lisp in the multiuser environments (like computer classes in universities) where a user may have not enough permissions for a writing to the installation directory. It is better to modify Corman Lisp accordingly (e. g. it should use something like "%USERPFROFILE%\Documents\Corman Lisp" for output).

Also, I think Corman Lisp should look for the init file (let's name it "corman-init.lisp") in the user profile directory additionally to the system-wide init file in the installation directory ("init.lisp"). For the better compatibility with older versions it should load system-wide init file before one in the user profile directory.
It should be noted that applications created with Corman Lisp should ignore these files.

I suppose this is a valuable addition and it looks like it is certainly doable.

@sharplispers/cormanlisp-maintainers @Luis-Cervantes @xach

The Corman Lisp 3.1 is about to be released.

The release notes with the changes are here. The list is pretty huge.

I believe it is the first community release which is stable enough to be considered for any real use. It lacks some important features which make it less useful than it could be, e.g. support for modern ASDF and support for modern thread synchronisation primitives available starting from Windows Vista and Windows 7. These issues are to be addressed in the next releases.

If everything goes as planned, the release should happen in the course of the following few weeks. If you are interested, you can get the release candidate installer in the project's download section. Hopefully, it should be almost identical to the planned release. Any feedback is welcome.

Thanks to everyone who helped to make it happen!

Note to the active contributors:

I have created the corman-3_1 git branch which is going to be a maintenance branch for 3.1 release series. If you want to get some important changes into the following release, please commit them into master branch and use git cherry-pick to copy them into corman-3_1.

It is easy to reproduce.

1. Load ohello-gui (I believe any GUI application will do).
2. Execute (th:create-thread #'win::othello-gui).
3. Run (save-application "othello-gui" #'win::othello-gui :static t).

Produced executable will not be able to show window. One can kill it via Task manager.

Dear maintainers, I am so happy to see Corman Common Lisp live on! I had an issue with atan2 a while ago (2012 if you'd believe me) - and I dug it up since I remembered it. I've attached a diff (zipped) for what worked well for me - would you incorporate/improve it please?

I haven't been able to build Corman Lisp yet, and would like to discuss that if possible too. Do you have an active mailing list or forum? I just posted on https://groups.google.com/forum/#!forum/cormanlisp

math-ops atan2.zip

Hello!

According to the CLHS, make-pathname has special behaviour when given a string for its :directory argument:

If the directory is a string, it should be the name of a top level directory, and should not contain any punctuation characters; that is, specifying a string, str, is equivalent to specifying the list (:absolute str). Specifying the symbol :wild is equivalent to specifying the list (:absolute :wild-inferiors), or (:absolute :wild) in a file system that does not support :wild-inferiors.

However, on Corman CL though I see this:

?(make-pathname :directory "Users")
;;; An error of type TYPE-ERROR was detected in function SIGNAL-TYPE-ERROR:
;;; Error: Type error: datum = Users, expected type = LIST

Additionally:

?(make-pathname :directory :wild)
;;; An error of type TYPE-ERROR was detected in function SIGNAL-TYPE-ERROR:
;;; Error: Type error: datum = WILD, expected type = LIST

Unfortunately new Hardware Assisted GC crashes CL on nearly all machines I have access to. It seems that it needs some additional work.

I am going to disable it by default in master branch for now.

At this time Corman Lisp has installer project for InstallShield. InstallShield, off course, is widely used and proven solution but it is also a proprietary shareware. I think that usage of such tool for an opensource project is questionable.

MSI based installer built with WiX looks like a much better alternative (http://wixtoolset.org/releases/).

As a side effect MSI installer can be used for automatised deploying on many computers at once in some managed environments (computer classes in universities is a good example here) which is a good thing.

It should be noted that SBCL has some code to simplify WiX project generation from Lisp: https://github.com/sbcl/sbcl/blob/master/tools-for-build/wxs.lisp

It would be good to stay compatible with WinXP though, so it needs some brainstorming.

The then and else branches should be aligned.

LOAD-IMAGE in console based version of the Corman Lisp works fine.

Fast investigation revealed two possible issues:

• One probably should suspend the other Lisp threads during this operation.
• IDE always crashed in TimerProc. I believe It has something to do with internal callbacks obtained from Lisp during initialization. IDE should detect LOAD-IMAGE and reobtain addresses of this functions.

A weird bug.

Steps to reproduce:

1. Type documentation into "Lisp Worsheet";
2. Highlight the word;
3. Call documentation lookup using menu (with Right Mouse Button).

As was suggested by @Luis-Cervantes in issue #32:

2.- If we are to follow the standard, the documentation function should be redefined as a generic-function with two specializing arguments, which accept non-symbol objects and can be extended to accept :hyperspec as a doc-type.

From https://groups.google.com/d/msg/cormanlisp/_qB2KC4Nw5Q/Sgv6xoZ0CQAJ

I suspect using keyword symbols as slot-descriptors in defstruct doesn't meet HyperSpec and outcome is undefined.
I was trying it as I have a list of keyword symbols I was thinking of using to create a structure with them as slot names.

Corman Lisp handles this except for initializing the the slots when making instances. Setf to slot later works.

e.g.
;; Corman Lisp 3.1 (Patch level 2)
(defstruct book :title :pages)
BOOK
(setq book1 (make-book :title "hoho" :pages 190))
#S( BOOK :TITLE :TITLE :PAGES :PAGES )
book1
#S( BOOK :TITLE :TITLE :PAGES :PAGES )

(book-p book1)
T
(book-title book1)
:TITLE
(setf (book-title book1) "hihi")
"hihi"
(book-title book1)
"hihi"

SBCL initializes as might be expected or hoped for, but with warnings

This is SBCL 1.4.14, an implementation of ANSI Common Lisp.

• (defstruct book :title :pages)
  STYLE-WARNING: slot name of :TITLE indicates possible syntax error in DEFSTRUCT
  STYLE-WARNING: slot name of :PAGES indicates possible syntax error in DEFSTRUCT
  BOOK

• (setq book1 (make-book :title "hi" :pages 190))
  ; in: SETQ BOOK1
  ; (SETQ BOOK1 (MAKE-BOOK :TITLE "hi" :PAGES 190))
  ;
  ; caught WARNING:
  ; undefined variable: BOOK1
  ;
  ; compilation unit finished
  ; Undefined variable:
  ; BOOK1
  ; caught 1 WARNING condition
  #S(BOOK :TITLE "hi" :PAGES 190)

• book1
  #S(BOOK :TITLE "hi" :PAGES 190)

• (book-p book1)
  T

• (book-title book1)
  "hi"

• (setf (book-title book1) "hihi")
  ; in: SETF (BOOK-TITLE BOOK1)
  ; (THE BOOK BOOK1)
  ;
  ; caught WARNING:
  ; undefined variable: BOOK1
  ;
  ; compilation unit finished
  ; Undefined variable:
  ; BOOK1
  ; caught 1 WARNING condition
  "hihi"

• book1
  #S(BOOK :TITLE "hihi" :PAGES 190)

What do you think of Corman Lisp behavior?

Cheers
Nigel

The Common Lisp function FILE-NAMESTRING is not implemented in Corman Lisp. Here is a working implementation:

(defun file-namestring (pathname)
    (let ((name (pathname-name pathname))
          (type (pathname-type pathname)))
        (concatenate 'string name "." type)))

It was reported that Corman Lisp IDE changes line endings to Windows style when editing files. It should try to preserve the line ending style.

Some additional information: https://docs.microsoft.com/en-us/cpp/mfc/reference/cricheditctrl-class?view=vs-2017#setoptions (See ECO_WANTRETURN).

If you grep -i corman in the ASDF sources, you'll find many workarounds for bugs in Corman Lisp, some of them glaring. Oh, and grep for clozure instead and find all the places where corman support is missing.

If anyone feels like hacking Corman Lisp, that would be a good place to start.

Of course, once you're done, (1) push the modifications / simplifications / fixes to ASDF upstream and (2) include a pristine updated ASDF in Corman Lisp so it can be provided by (require "asdf") and if possible also (require "ASDF").

Although a proper license is no longer required, it is still necessary to go through the registration dialog, the windows registry is still modified, and licensing information show up in various parts of the IDE.

Try this:

(find-symbol "foobar" "no-such-package")

In SBCL, you would get the following error:

The name "no-such-package" does not designate any package.
      [Condition of type SB-KERNEL:SIMPLE-PACKAGE-ERROR]

But in Corman Lisp, you get this:

;;; An error of type SIMPLE-ERROR was detected in function FIND-SYMBOL:
;;; Error: Invalid package: NIL

This is much more difficult to debug. The problem, as with the defpackage bug, is that
information is lost before the error happens, so there is no information to put in the error. Here's Corman Lisp's implementation of find-symbol, found in Sys\package.lisp:

(defun find-symbol (string &optional (package *package*))
    (unless (packagep package)
        (setq package (find-package package)))
    (unless (packagep package)
        (error "Invalid package: ~A" package))
    (with-synchronization (package-sync package)
        (multiple-value-bind (sym status)
            (package-find-symbol package string)
            (if status
                (cond 
                    ((eq status 'internal)(values sym :internal))
                    ((eq status 'external)(values sym :external))
                    (t (values sym :inherited)))
                (values nil nil)))))

The problem is in the very first form in the function:

    (unless (packagep package)
        (setq package (find-package package)))

The next form checks for the error condition, but if package was the name of a nonexistent package, the form above replaces it with NIL. This would fix the problem:

    (unless (packagep package)
        (setq package (or (find-package package)
                          (error "The name \"~A\" does not designate any package." package))))

Hello!
It seems that load is not properly binding *load-pathname* and *load-truename* when calling a compiled file.

Create a file:

(print "Printing..")
(print *load-pathname*)
(print *load-truename*)
(print *compile-file-pathname*)
(print *compile-file-truename*)
(print "Done")
(terpri)

At the repl:

;; Corman Lisp 3.1  (Patch level 2)
;; Copyright (c) Corman Technologies Inc. See LICENSE.txt for license information.
;; User: Zulu.
Type :quit to exit.
?(load "test.lisp")

"Printing.."
#P"C:\Users\Zulu\test.lisp"
#P"C:\Users\Zulu\test.lisp"
NIL
NIL
"Done"
7
?(compile-file "test.lisp")

"Printing.."
NIL
NIL
#P"C:\Users\Zulu\test.lisp"
#P"C:\Users\Zulu\test.lisp"
"Done"
#P"C:\Users\Zulu\test.fasl"
NIL
NIL
?(load "test.fasl")

"Printing.."
NIL
NIL
NIL
NIL
"Done"
7
?

See: http://clhs.lisp.se/Body/v_ld_pns.htm

On Page 100 of the User Guide (from the Help menu in the IDE), it says

"If the pathname specifies a file with an extension .EXE, then the saved image is appended to the .EXE file as a .lisp segment. Any contents of the .EXE file are preserved. Note that if a .lisp segment already exists, another one will be created. This is probably not what you want. In future versions, the existing .lisp segment will be overwritten. "

This suggests that there must be an executable already present if you want to create executables with Corman Lisp. This executable would need to be pre-programmed to load itself with LOAD-IMAGE (which is documented as being able to recognize executables and load the .lisp segment) and then call TOP-LEVEL. Perhaps one of the executables that comes with the distribution is a stub meant for this purpose. If so, then the documentation is lacking. Perhaps SAVE-IMAGE should be altered so that it copies this stub to "pathname" and then adds the .lisp segment, overwriting any pre-existing file, instead of assuming that "pathname" will already point to an appropriate file.

(defun f (&key)) (f :allow-other-keys t) -> error
Note that if &key is present, a keyword argument of :allow-other-keys is always permitted

Hello, I saw your recent release so I went ahead and installed your implementation on my machine (Win10 64-bit). I only started lisping a while ago so I was still doing some basic code. I was running SBCL installed with roswell until now.
The problem is that read-line doesn't seem to block properly, thus allowing the program to continue running.
This is my code:

(defun prompt-read (prompt)
  (format *query-io* "~a: " prompt)
  (force-output *query-io*)
  (read-line *query-io*))

(defun prompt-for-data ()
   (prompt-read "String 1")
   (prompt-read "String 2")
   (or (parse-integer (prompt-read "Number 1") :junk-allowed t) 0)
   (y-or-n-p "Bool 1"))

This is the REPL:

?(prompt-for-data)
String 1: String 2: e
Number 1: 3

Bool 1(Y/N)
N
NIL

I did not have this issue with SBCL. After asking around (namely in Lisp's Discord server) I had to file this issue.

EDIT: I'm sorry but Github doesn't seem to register the text between backticks as code.
EDIT: Fixed formatting

When leaving the IDE open, I can see the Gen0 GC bar slowly filling up over time, even without me doing anything in the IDE.

Is it expected, or a possible leak of sorts?

*print-case* :capitalize behaves the same as *print-case* :downcase in Corman CL. But, it works fine in SBCL.

Corman Lisp 3.1 (Patch level 2) Example: Note that the "m" in the last "mike" is NOT properly capitalized. The entire name is lowercase as if the :downcase keyword were used instead of :capitalize.

?(defvar *name* (read))
mike
*NAME*
?*name*
MIKE
?(setq *print-case* :capitalize)
:capitalize
?*name*
mike

SBCL 1.4.14 Example: Note that the "M" in the last "Mike" is properly capitalized while the rest of the name is properly lowercase.

* (defvar *name* (read))
mike
*NAME*
* *name*
MIKE
* (setq *print-case* :capitalize)
:Capitalize
* *name*
Mike

Environment: Windows XP 32-bit OS and Windows 10 64-bit OS

Version: CormanLisp-3.1.2b.zip

Issue: Missing mfc140.dll error message appears after extracting Corman Lisp from CormanLisp-3.1.2b.zip and double-clicking on CormanLisp.exe.

Error Message: "CormanLisp.exe - Unable To Locate Component: This application has failed to start because mfc140.dll was not found. Re-installing the application may fix this problem."

Workaround: The workaround is for the user to locate and manually install the "Visual C++ Redistributable for Visual Studio 2015" as discussed here:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/ff26dc80-0fbc-4391-8460-880574e67e75/mfc140dll-missing-error-while-running-exe-file?forum=vcgeneral

@sharplispers/cormanlisp-maintainers @Luis-Cervantes @xach

As it was announced earlier, Corman Lisp 3.1 has been released!

The release can be found in the project's download section alongside the release notes.

Compared to the last release candidate it contains the following changes:

• important installer fixes and optimisations;
• documentation updates;
• new logo.

Happy New Year!

Mentioned in #42

It used to be SLIME compatible, but currently the support for Corman Lisp in SWANK is broken. The code is still there though. I haven't had time to investigate it further.

As far as I can tell, it should try to show online documentation instead of local one (see *hyperspec-internet-path*).

How to reproduce:

(setq ccl::*hyperspec-internet-path* "http://www.lispworks.com/documentation/HyperSpec/") ; 'http://' is important here, as dicovered by Luis-Cervantes
(setq ccl::*hyperspec-local-path* nil)

Try this at the REPL:

 (defun hello ()
     (format t "Hello, world!~%")
     (lisp-shutdown ""))

 (save-application "hello.exe" #'hello :console t)

The resulting hello.exe prints nothing when launched. However, the following program works fine:

(defun hello ()
    ;; Explicitly open the console.
    (with-open-file (*standard-output* "CON" :direction :output :if-exists :append)
        (format t "Hello, world!~%"))
    (lisp-shutdown ""))

Corman 3.1.2:

(make-instance 'standard-method :lambda-list '(foo)
               :function #'(lambda (foo) foo))
;;; An error of type SIMPLE-ERROR was detected in function STD-SLOT-VALUE:
;;; Error: The slot COMMON-LISP::BODY is unbound in the object #<;;; An error of type SIMPLE-ERROR was detected in function STD-SLOT-VALUE:
;;; Error: The slot COMMON-LISP::EFFECTIVE-SLOTS is missing from the class #<Standard-Class BUILT-IN-CLASS #x72CB850>.
;;; Entering Corman Lisp debug loop. 
;;; Use :C followed by an option to exit. Type :HELP for help.
;;; Restart options:
;;; 1   Abort to top level.

SBCL:

CL-USER> (make-instance 'standard-method :lambda-list '(foo)
               :function #'(lambda (foo) foo))
#<STANDARD-METHOD () {1004610F23}>

Environment:
Corman Common Lisp 3.1 (Patch level 2) under Windows 10 64bit

Issue:
The Format function's $ directive fails to display ".00" as the default when preceded by a tilde. It displays ".0" instead. This fails in Corman CL, but works in SBCL 1.4.14 64bit and in Clozure CL 1.11.5 64bit when tested.

Corman CL Example1: Note the issue is that 10.0 is returned rather than 10.00.

?(format t "10 Dollars ~$ ~%" 10)
10 Dollars 10.0
NIL

SBCL Example1: SBCL produces the correct result, just as Clozure CL does.

* (format t "10 Dollars ~$ ~%" 10)
10 Dollars 10.00
NIL

Reference:

1. CLHS: 22.3.3.4 Tilde Dollarsign: Monetary Floating-Point.
   "The full form is ~d,n,w,padchar$. The parameter d is the number of digits to print after the decimal point (default value 2); n is the minimum number of digits to print before the decimal point (default value 1); w is the minimum total width of the field to be printed (default value 0). "
   http://www.lispworks.com/documentation/lw70/CLHS/Body/22_ccd.htm

I don't know how this bug might have been introduced (I remember that Corman Lisp was working with Slime at some point), but there seems to be a problem that is easy to fix with a couple of changes (see below).

With this fix it becomes possible to (load "slime-2.0/swank-loader.lisp") and (swank:create-server) or (swank:create-server :style :spawn)

The swank server runs... until we try to connect ("M-x slime-connect" will result in errors). Slime 2.0 is still available at http://common-lisp.net/project/slime/slime-2.0.tgz

In Sys/winsock.lisp, change the make-package form (line 11) to
(defpackage "WINSOCK" (:use "COMMON-LISP" "C-TYPES") (:shadow "LISTEN"))

In Sys/sockets.lisp, specify the package winsock in the call to listen (line 474):
(winsock:listen (socket-descriptor s) SOMAXCONN))))

Example:

 (defpackage :foobar
    (:use :common-lisp)
    (:import-from #:winsock))

You'll get an error about #:winsock not being bound. The error is caused by a missing quote in the function build-import-forms, defined just above defpackage in the source (file: Sys\defpackage.lisp). The offending line of code is this:

  (push `(,(if shadowing 'shadowing-import 'import) ',symbol-names ,into-pkg-name) forms)

Add a quote in front of ,into-pkg-name to fix this bug.

I believe it would be nice to support Restart Manager API on Windows Vista and newer. It is very handy when implemented with #19.

https://msdn.microsoft.com/ru-ru/library/windows/desktop/cc948910%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

I'm trying to use the sampledll, but the exe stops with an error: ucrtbased.dll is missing.
Well: is missing because I don't have VC2015 installed and redist seems to ignore the debug version of ucrtdebug.
Does CormanLisp compile each DLL in debug mode? or I could tell it to compile as release?
Any suggestion on where to find ucrtbased.dll?

I forked my own repo, and have done a bit of work in that, which I would like to merge into the sharplispers cormanlisp tree.

I have been using Visual Studio 2015 on all my workstations at this point and went ahead and updated the code base to VS 2015. I made a new solution file, but there are 10 project files that also got updated and I don't think maintaining separate project files is that great. Do we want to update the master to build with VS 2015? I've tested quite a bit and it's working well. I've also run with the community (free) version and it builds fine.

I also have a couple bugs to check in and some enhancements that add support for more Win32 library calls.
I ported a neural net simulator program that's really cool--it has a bunch of minesweepers, each with a neural net as a brain, and they drive around trying to disarm the mines. At first they drive really badly, like driving in circles, but as they evolve (also uses a genetic algorithm) the neural net of each mine gets better at finding the mines. I plan to put that in the examples directory--it's all in one lisp file.

I also fixed the editor in the IDE so that it correctly saves and restores documents, positions etc. like it used to.

I'll check in all these changes, but just need to sort out the VS version issue above.
Roger

From #43:

Of course, there have probably been changes on the SLIME side since then, so additional work may be needed in the SWANK implementation for CCL.

The acronym CCL now collides (again) between Clozure Common Lisp and Corman Common Lisp. Are there any ideas for resolving it?