Hi Ray, > >>>>>> "Peter" == Peter Denno <[EMAIL PROTECTED]> writes: > > Peter> (defun show-restarts (restarts &optional (s *error-output*)) > Peter> (when restarts > Peter> (format s "~&Restarts:~%") <---------------------- > [snip] > Peter> SUGGESTION: Remove ~& from the format directive. > > ~& only puts in a newline if the printer thinks we're not at the > beginning of a new line. Harmless. >
Removing ~& is not the ideal way to go about it, but if you remove the ~& here it prints one fewer empty line. And I am hoping that we agree that that is good. If so, I leave it to the developers to do it right. [snip] > > Peter> (defvar *gc-verbose* nil) ; In ./code/gc.lisp or ./code/gengc.lisp > > Newbies should know things are consing. But garbage collection isn't new anymore. Many popular languages have it and most programmers (at least the ones who might be attracted to lisp) know that it takes place occassionally. Printing the message seems excessively pedagogical. With regards to most of what we are talking about, my opinion is this: Let them focus on THEIR problem first, and if subsequently GC or some lispy thing becomes their most immediate problem, they can go read about what they are doing wrong. > Peter> (defvar ext::*top-level-auto-declare* t) ; In ./code/eval.lisp > > Newbies should know what happens when you define things at toplevel > and wonder why things don't behave the same anymore. (I've been > bitten by this many times when I just wanted to do something quick and > named a variable X, which is also used on other code.) So you are saying that the PRESENCE of the warning means you are safe, right? When you get the warning, you are declaring a new special and therefore will not be affecting existing definitions. Things will behave as they had. When you DON'T get the warning, you may be setting a special defined elsewhere, and thing might not behave the same anymore. I don't think newbies are going to follow that line of reasoning. More likely, when they see a warning, they are going to think they are doing something wrong. Maybe the warning should read, "Good choice of names, this special isn't used elsewhere". ...I must be missing something! I think there is a real problem of a related sort elsewhere: ~/> lisp -noinit * (defun hello () dlkfj) HELLO * ...Here, I wouldn't mind a warning that dlkfj is assumed special. > Anyway, those are my opinions. And this is just a thought. Seeing that I am not nearly ready to help with the development of the code, I thought I'd offer some marketing advice based on my recent experience. -- I have discussed this with another cmucl user who would also very much like to see cmucl quieter out of the box. I believe that most open source projects get no more than a day to prove their worth to a new user -- maybe just an hour. If you can make that hour less shocking, they might stick with it. If I were to come to cmlcu from Java or Python I think I'd be bewildered. It was pretty tough for me just coming from lispworks. I think what cmucl newbies need is not lots of compiler warnings, runtime warnings, and gc messages but a simple tutorial with a "Tips and Tricks" section -- maybe it should talk about the ilisp interface too. That is part of the typical total experience, I suppose. I'd be happy to contribute to the development of such a document, but I'd like to be able to begin it by saying that you can learn a lot more about what cmucl is doing by setting such and such variables, rather than beginning by telling them about the *gc* message and why I worry about their special variable declarations. PS The Documentation section of the the cmucl webpage already has a section called "Tips and Tricks". The first bullet of that section reads: "On GNU/Linux systems running kernel 2.2 or greater, CMUCL-compiled files can be made directly executable by the kernel by registering them with the binfmt_misc module. " --- Well, THAT is NOT what I have in mind! -- Best Regards, - Peter Peter Denno National Institute of Standards and Technology, Manufacturing System Integration Division, 100 Bureau Drive, Mail Stop 8264 Tel: +1 301-975-3595 Gaithersburg, MD, USA 20899-8264 FAX: +1 301-975-4694
