Stig E Sandoe | 20 Oct 03:00 2003
Picon
Picon

ANN: Albert v0.4.7 released

hei,

Albert, the javadoc-alike tool for Common Lisp, has made a couple of
steps further from the v0.4.6 release.  The v0.4.7 release contains
several fixes and add-ons which you might find useful when documenting
your CL software:

- Control presentation of functions/variables/etc depending on whether
  it's exported from a package.
- Support for including legal notice/licencefile.
- More precise control of presentation via configurable settings.  
- Albert is now usable with MK-Defsystem, CLISP and without any
  intermediate xml-files (ie it can be run with CL alone).
- Several bugs and issues fixed, as well as improved the lisp-reader
  to handle more situations with grace, instead of ending in an
  ERROR.  Navigation icons also updated to work properly with Internet
  Explorer. 

(See Changelog for more details. This is a 'Release Early+Often' release.)

Several known issues remain, e.g make presentation order for
'package full listing' configurable.  These will be addressed, but to
be able to make correct priorities feedback from you is needed.  To be
able to make Albert useful for Lisp projects I need to know what's
important for your lisp project and what features you need.  I'm also
interested in knowing how you use Albert and about any problems with
the current release.  Please use my mail-address or the bug/request
trackers.  

Albert has a homepage at: http://albert.sourceforge.net/
(Continue reading)

Stig E Sandoe | 20 Oct 20:41 2003
Picon
Picon

ANN: Albert v0.4.8 released (bugfix++)

Albert, the javadoc-alike tool for Common Lisp, just had a v0.4.7
release and was tested by several people.  Most attempts worked well,
but some hit show-stopper bugs.  Known show-stopper bugs have been
fixed for the v0.4.8 release, also:

- Now prints out a clickable class-hierarchy for the index, which
  should be neatly indented.

- Several small tweaks and issues fixed, as well as the mentioned few
  show-stopper bugs.  If you have problems with v0.4.7, I recommend you
  try v0.4.8.  

(See Changelog for more details. This is also a 'Release Early+Often' release.)

Albert has a homepage at: http://albert.sourceforge.net/
Known bugs are found at:  http://sourceforge.net/tracker/?atid=572559&group_id=84355
Feature requests: http://sourceforge.net/tracker/?group_id=84355&atid=572562

Several known issues remain, e.g make presentation order for 'package
full listing' configurable, or allowing classes to list methods that
are related/dispatch on that class.  These will be addressed, but to
be able to make correct priorities, feedback from you is needed.  To be
able to make Albert useful for Lisp projects I need to know what's
important for your lisp project and what features you need.  I'm also
interested in knowing how you use Albert and about any problems with
the current release.

Thanks for your interest.

--

-- 
(Continue reading)

Gary King | 27 Oct 15:07 2003
Picon

patch for class-for-type

I think that class-for-type should be defined as:

(defun class-for-type (parent type)
   (let ((class (or (find-class (find-symbol (symbol-name type) 
*package*) nil)
                    (find-class (find-symbol (symbol-name type) 
#.*package*) nil))))
     (or class
	(and (eq type :file)
	     (or (module-default-component-class parent)
		 (find-class 'cl-source-file)))
         (and (eq type :files)
	     (find-class 'cl-source-files))
	(sysdef-error (formatter "~ <at> <don't recognize component type ~A~ <at> :>")
		      type))))

The current version (1.79) puts the find-class outside of the or. The 
problem occurs when symbol-name is defined in both *package* and 
#.*package* but it is not a class in *package*. E.g., if the symbol 
module is in *package* but not as a class. In this case, I think that 
the correct behavior would be to ignore the symbol in *package* and go 
on to look at the same symbol in #.*package*.

--

-- 
Gary Warren King, Lab Manager
EKSL East, University of Massachusetts * 413 577 0176

To hold people without charge and without access to legal counsel risks 
the creation of an 'American gulag' for those detained in the course of 
the war on terror.
(Continue reading)

Gary King | 27 Oct 15:14 2003
Picon

Patch for finding the truename.

The following patch may be more baroque than necessary (it come from an 
OLD homegrown load system which has accumulated a fair degree of cruft 
over the years!). It does two things: 1. Under MCL, it allows systems 
to be defined by evaluating a buffer (instead of having to load them) 
and 2. It prints a warning message when the truename cannot be found -- 
rather than getting an error applying some function to nil later on.

Number 1 is handled because MCL has the variable 
ccl:*loading-file-source-file* which is the name of the currently 
active buffer. Number 2 is handled by adding an assertion. The code 
below defines load-truename and uses it in the defsystem macro. As I 
said above, a bunch of the conditionals in load-truename may be 
optional. I don't currently have a version of Lispworks, Allegro or 
other Lisps on which to test this.

(defun load-truename ()
   "Returns a pathname that is useful for merging with filenames to get a
complete pathname for a file in the same directory as the one currently 
being
loaded.  This function is a more portable version of the Common Lisp 
variable
*load-pathname*, since not all vendors implemented that correctly."
   (let ((pn   #+allegro (translate-logical-pathname (truename 
excl:*source-pathname*))
               #+MCL (cond (*load-pathname*
                            (translate-logical-pathname *load-pathname*))
                           (ccl:*loading-file-source-file*
                            ;; This makes it work in a fred buffer...
                            (translate-logical-pathname 
ccl:*loading-file-source-file*))
(Continue reading)

Gary King | 27 Oct 15:25 2003
Picon

A :files clause and a possible change to parse-component-form

Overall, I think ASDF is very nice. There is one thing, however, which  
I dislike: the amount of boilerplate code involved in defining a system  
with many files when the dependencies are already encoded in the file  
ordering. As an example, I'd rather type

(asdf:defsystem :eksl-utilities-base
   :version "1.0"
   :components ((:files ("package"
                         "l0-utils"
                         "anaphoric"
                         "graham"
                         "feature-case"
                         "macros"
                         "spy"
                         "timeit"
                         "utilities"
                         "string-utilities"
                         "debugging-utils"
                         "day-and-time"
                         "copy"
                         "clos-mop-utils"
                         "clos-utils"
                         "clos-mixins"
                         "class-defs"
                         "indentation"
                         "longest-subsequence"))))

Than

(asdf:defsystem :eksl-utilities-base
(Continue reading)

james anderson | 27 Oct 17:00 2003
Picon

Re: Patch for finding the truename.


On Monday, Oct 27, 2003, at 15:14 Europe/Berlin, Gary King wrote:
>
> (defun load-truename ()
>   "Returns a pathname that is useful for merging with filenames to get 
> a
> complete pathname for a file in the same directory as the one 
> currently being
> loaded.  This function is a more portable version of the Common Lisp 
> variable
> *load-pathname*, since not all vendors implemented that correctly."
>   (let ((pn   #+allegro (translate-logical-pathname (truename 
> excl:*source-pathname*))

1. why does one not want to just use *load-truename* for this?

2. wouldn't digitool be needed for this does open-mcl also define the 
ccl:*loading-file-source-file* symbol.
i recall submitting a 5.0b bug about fred behaviour, as digitool should 
really be binding *load-truename* rather than in implementation 
specific variable with parallel semantics, since they do all of the 
other things - like warning about redefinition, as if they were loading 
from a file. my memory was they they agreed - in principle, but i've 
never checked whether it made it into the release. i'm still using a 
wrapped fred command which does just that.

>               #+MCL (cond (*load-pathname*
>                            (translate-logical-pathname 
> *load-pathname*))
>                           (ccl:*loading-file-source-file*
(Continue reading)

Stig E Sandoe | 27 Oct 20:48 2003
Picon
Picon

ANN: Albert v0.4.9 released


Albert, the javadoc-alike tool for Common Lisp, continues the surge
ahead with a v0.4.9 release.  The code has been tested on a lot of new
lisp-projects and has been made more robust.  Of major new features
in this release:

- Allows inclusion of 'related methods' in presentation of classes and
  structs.  A 'related method' is a method that dispatch on that
  particular class or struct. 

- Now also handles keyword and optional parameters to methods and
  functions right.  Improvement of EXPORT-calls also improved, in
  other words the package export-lists will be more accurate.

- Can now split the variable/constant list for a package onto a separate
  page.  Also enables cvsview-linking of methods and functions, where
  info about the cvsview url has been provided.

- New and improved icons for export-status.  Very visible effect. 

- In addition comes a long list of other fixes, see Changelog for
  details.  

(This is also a 'Release Early+Often' release.)

Several known issues remain, e.g make presentation order for 'package
full listing' configurable, or making albert API docs includable in
your other docbook documentation.  These will be addressed, but to
be able to make correct priorities, feedback from you is needed.  To
have a wide enough testsuite for the albert-parser and presentation
(Continue reading)

Kevin Rosenberg | 28 Oct 01:33 2003
Picon

Re: ANN: Albert v0.4.9 released

Stig E Sandoe wrote:
> Albert, the javadoc-alike tool for Common Lisp, continues the surge

Nice work!

Duploaded.

-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
Gary King | 28 Oct 15:23 2003
Picon

Re: Patch for finding the truename.

On Monday, October 27, 2003, at 11:00 AM, james anderson wrote:

>> (defun load-truename ()
>>   "Returns a pathname that is useful for merging with filenames to 
>> get a
>> complete pathname for a file in the same directory as the one 
>> currently being
>> loaded.  This function is a more portable version of the Common Lisp 
>> variable
>> *load-pathname*, since not all vendors implemented that correctly."
>
> 1. why does one not want to just use *load-truename* for this?

AFAIK, *load-truename* is only valid when a file is being loaded. This 
function attempts to be accurate even in a buffer -- although at this 
point that is only true for Digitool's MCL. To my mind, this is very 
handy when defining systems interactively when the other choice would 
be to continually save and load the system definition file.

> 2. wouldn't digitool be needed for this does open-mcl also define the 
> ccl:*loading-file-source-file* symbol.

I don't know about OpenMCL and ccl:*loading-file-source-file*.

> i recall submitting a 5.0b bug about fred behaviour, as digitool 
> should really be binding *load-truename* rather than in implementation 
> specific variable with parallel semantics, since they do all of the 
> other things - like warning about redefinition, as if they were 
> loading from a file. my memory was they they agreed - in principle, 
> but i've never checked whether it made it into the release. i'm still 
(Continue reading)

Gary King | 28 Oct 16:47 2003
Picon

Re: Patch for finding the truename.

I agree with you completely and think that other Lisps should do 
something similar so that interaction with the editor is facilitated. 
Until this happens, then I think a work around (or set of work arounds) 
like yours or like the load-truename function is useful.

On Tuesday, October 28, 2003, at 10:36 AM, james anderson wrote:

> my point was that digitool should be binding trash 
> *loading-file-source-file* and bind *load-truename* instead.
>
> the equivalent of this.
>
> (advise ccl::selection-eval
>         (let* ((*load-pathname* (ccl::stream-pathname (first arglist)))
>                (*load-truename* (typecase *load-pathname*
>                             (pathname (truename *load-pathname*))
>                             (t nil))))
>           (:do-it))
>         :when :around
>         :name :bind-load-pathname)
>
> hen you don't need to worry everywhere about the fred buffer special 
> case.
>
> On Tuesday, Oct 28, 2003, at 15:23 Europe/Berlin, Gary King wrote:
>
>> On Monday, October 27, 2003, at 11:00 AM, james anderson wrote:
>>
>>>> (defun load-truename ()
>>>>   "Returns a pathname that is useful for merging with filenames to 
(Continue reading)


Gmane