2008-12-22T02:37:48Z bug://report/15 2010-04-08T05:48:05Z dherring <table cellspacing="0" cellpadding="3" border="0"> <tr> <td><strong>Bug ID:</strong></td> <td>15</td> </tr> <tr> <td><strong>Summary:</strong></td> <td>add portability guidelines for authors</td> </tr> <tr> <td><strong>Product/Component/Version:</strong></td> <td>LibCL Website/0.1</td> </tr> <tr> <td><strong>Status:</strong></td> <td>Confirmed</td> </tr> <tr> <td><strong>Severity:</strong></td> <td>Enhancement</td> </table> <p>The website (and tarballs?) should collect common portability gotchas.<br /> <br /> A few to start with:<br /> - Don't use #+nil; there are reasonable ways to get :nil in *features*. Use #-(and) or #+(or) instead.<br /> - Encode source files in ASCII or UTF-8 (i.e. not Latin-1).<br /> - Don't use a LOOP variable-clause after a main-clause (e.g. FOR after WHILE); it isn't portable (e.g. ECL).<br /> - Use TYPE in compound declarations. Example: (declare (type (array * (2)) x)) not (declare ((array * (2)) x))<br /> - Be sensitive of implementations where 'x is lowercase and 'X is uppercase. Use symbols instead of strings.<br /> - The third argument to DEFINE-MODIFY-MACRO is a symbol, not a lambda expression.</p>

The website (and tarballs?) should collect common portability gotchas.<br /> <br /> A few to start with:<br /> - Don't use #+nil; there are reasonable ways to get :nil in *features*. Use #-(and) or #+(or) instead.<br /> - Encode source files in ASCII or UTF-8 (i.e. not Latin-1).<br /> - Don't use a LOOP variable-clause after a main-clause (e.g. FOR after WHILE); it isn't portable (e.g. ECL).<br /> - Use TYPE in compound declarations. Example: (declare (type (array * (2)) x)) not (declare ((array * (2)) x))<br /> - Be sensitive of implementations where 'x is lowercase and 'X is uppercase. Use symbols instead of strings.<br /> - The third argument to DEFINE-MODIFY-MACRO is a symbol, not a lambda expression.

bug://report/17 2010-02-14T05:15:53Z dherring <table cellspacing="0" cellpadding="3" border="0"> <tr> <td><strong>Bug ID:</strong></td> <td>17</td> </tr> <tr> <td><strong>Summary:</strong></td> <td>Fix Flexichain for modern ECL</td> </tr> <tr> <td><strong>Product/Component/Version:</strong></td> <td>LibCL Distribution/2009-09-all</td> </tr> <tr> <td><strong>Status:</strong></td> <td>Confirmed</td> </tr> <tr> <td><strong>Severity:</strong></td> <td>Moderate</td> </table> <p>ECL added support for weak pointers on 20090903.<br /> <br /> From the ChangeLog,<br /> + - ECL now implements weak pointers. The interface is<br /> + (ext:make-weak-pointer value) =&gt; weak-pointer<br /> + (ext:weak-pointer-value weak-pointer) =&gt; value<br /> <br /> I believe this was the only thing keeping flexichain and its dependents from being supported on ECL.</p>

ECL added support for weak pointers on 20090903.<br /> <br /> From the ChangeLog,<br /> + - ECL now implements weak pointers. The interface is<br /> + (ext:make-weak-pointer value) =&gt; weak-pointer<br /> + (ext:weak-pointer-value weak-pointer) =&gt; value<br /> <br /> I believe this was the only thing keeping flexichain and its dependents from being supported on ECL.

bug://report/16 2010-01-17T05:13:42Z dherring <table cellspacing="0" cellpadding="3" border="0"> <tr> <td><strong>Bug ID:</strong></td> <td>16</td> </tr> <tr> <td><strong>Summary:</strong></td> <td>master symbol index</td> </tr> <tr> <td><strong>Product/Component/Version:</strong></td> <td>LibCL Distribution/0.1</td> </tr> <tr> <td><strong>Status:</strong></td> <td>Confirmed</td> </tr> <tr> <td><strong>Severity:</strong></td> <td>Enhancement</td> </table> <p>The current library index is a start, but it would be nice to have a way of browsing (both within the editor and from the web) all symbols.<br /> <br /> Thus an index could be generated during make-dist.sh.<br /> - run compile-libcl (into .tmp as now)<br /> - iterate over all the packages in libcl<br /> - for each symbol, collect boundp, fboundp, docstrings, etc.<br /> - dump a DB file<br /> - dump HTML/PDF files and indices<br /> <br /> Then LibCL could provide an apropos to interact with this database before loading any packages.</p>

The current library index is a start, but it would be nice to have a way of browsing (both within the editor and from the web) all symbols.<br /> <br /> Thus an index could be generated during make-dist.sh.<br /> - run compile-libcl (into .tmp as now)<br /> - iterate over all the packages in libcl<br /> - for each symbol, collect boundp, fboundp, docstrings, etc.<br /> - dump a DB file<br /> - dump HTML/PDF files and indices<br /> <br /> Then LibCL could provide an apropos to interact with this database before loading any packages.

bug://report/5 2010-01-17T04:19:42Z dherring <table cellspacing="0" cellpadding="3" border="0"> <tr> <td><strong>Bug ID:</strong></td> <td>5</td> </tr> <tr> <td><strong>Summary:</strong></td> <td>index.html does not list library versions</td> </tr> <tr> <td><strong>Product/Component/Version:</strong></td> <td>LibCL Distribution/2009-09-all</td> </tr> <tr> <td><strong>Status:</strong></td> <td>Confirmed</td> </tr> <tr> <td><strong>Severity:</strong></td> <td>Minor</td> </table> <p>Currently, index.html lists the libraries, licenses, etc. However it does not tell which version of each library is included.<br /> <br /> The current information is all included in packages.lisp. I need to find a way of scraping version information as part of make-dist.<br /> <br /> [suggested by Peter Seibel]</p>

Currently, index.html lists the libraries, licenses, etc. However it does not tell which version of each library is included.<br /> <br /> The current information is all included in packages.lisp. I need to find a way of scraping version information as part of make-dist.<br /> <br /> [suggested by Peter Seibel]

bug://report/14 2010-01-17T04:18:21Z dherring <table cellspacing="0" cellpadding="3" border="0"> <tr> <td><strong>Bug ID:</strong></td> <td>14</td> </tr> <tr> <td><strong>Summary:</strong></td> <td>library rating and feedback system</td> </tr> <tr> <td><strong>Product/Component/Version:</strong></td> <td>LibCL Website/0.1</td> </tr> <tr> <td><strong>Status:</strong></td> <td>Confirmed</td> </tr> <tr> <td><strong>Severity:</strong></td> <td>Enhancement</td> </table> <p>Bug reports and wishlist items are fairly heavyweight. It would be nice if people could easily give a &quot;thumbs up&quot; to libraries they like, leave a review, etc.<br /> <br /> Please contact dherring if you would like to write the web code.</p>

Bug reports and wishlist items are fairly heavyweight. It would be nice if people could easily give a &quot;thumbs up&quot; to libraries they like, leave a review, etc.<br /> <br /> Please contact dherring if you would like to write the web code.

bug://report/7 2010-01-16T04:27:40Z Samium Gromoff <table cellspacing="0" cellpadding="3" border="0"> <tr> <td><strong>Bug ID:</strong></td> <td>7</td> </tr> <tr> <td><strong>Summary:</strong></td> <td>bordeaux-threads unfortunately named in the package index</td> </tr> <tr> <td><strong>Product/Component/Version:</strong></td> <td>LibCL Website/0.1</td> </tr> <tr> <td><strong>Status:</strong></td> <td>Closed</td> </tr> <tr> <td><strong>Severity:</strong></td> <td>Trivial</td> </table> <p>Of all packages listed on <a href="http://libcl.com/libcl-current/index.html,">http://libcl.com/libcl-current/index.html,</a> only bordeaux-threads<br /> has its name in a non-canonical form -- that is, including a whitespace instead of a hyphen.<br /> <br /> This hurts machine parseability, a little.</p>

Of all packages listed on <a href="http://libcl.com/libcl-current/index.html,">http://libcl.com/libcl-current/index.html,</a> only bordeaux-threads<br /> has its name in a non-canonical form -- that is, including a whitespace instead of a hyphen.<br /> <br /> This hurts machine parseability, a little.

bug://report/6 2009-11-01T02:33:13Z Scott L. Burson <table cellspacing="0" cellpadding="3" border="0"> <tr> <td><strong>Bug ID:</strong></td> <td>6</td> </tr> <tr> <td><strong>Summary:</strong></td> <td>ASDF-Binary-Locations 0.3.9 has an Allegro fix</td> </tr> <tr> <td><strong>Product/Component/Version:</strong></td> <td>LibCL Distribution/2009-09-all</td> </tr> <tr> <td><strong>Status:</strong></td> <td>Unconfirmed</td> </tr> <tr> <td><strong>Severity:</strong></td> <td>Moderate</td> </table> <p>ASDF-Binary-Locations 0.3.9 has a fix I suggested for Allegro (generate different names for<br /> 8-bit and International Allegro). Would be good to merge it into LibCL.<br /> </p>

ASDF-Binary-Locations 0.3.9 has a fix I suggested for Allegro (generate different names for<br /> 8-bit and International Allegro). Would be good to merge it into LibCL.<br />

bug://report/4 2009-02-11T04:39:44Z dherring <table cellspacing="0" cellpadding="3" border="0"> <tr> <td><strong>Bug ID:</strong></td> <td>4</td> </tr> <tr> <td><strong>Summary:</strong></td> <td>packages missing defgeneric statements</td> </tr> <tr> <td><strong>Product/Component/Version:</strong></td> <td>LibCL Distribution/0.1</td> </tr> <tr> <td><strong>Status:</strong></td> <td>Confirmed</td> </tr> <tr> <td><strong>Severity:</strong></td> <td>Trivial</td> </table> <p>clem, ch-image, cxml, puri-tests are some of the major offenders</p>

clem, ch-image, cxml, puri-tests are some of the major offenders

bug://report/3 2008-12-22T03:00:01Z dherring <table cellspacing="0" cellpadding="3" border="0"> <tr> <td><strong>Bug ID:</strong></td> <td>3</td> </tr> <tr> <td><strong>Summary:</strong></td> <td>libcl doesn't tag the git repos</td> </tr> <tr> <td><strong>Product/Component/Version:</strong></td> <td>LibCL Distribution/0.1</td> </tr> <tr> <td><strong>Status:</strong></td> <td>Confirmed</td> </tr> <tr> <td><strong>Severity:</strong></td> <td>Moderate</td> </table> <p>This doesn't affect snapshots, alphas, or betas (where the collection of SHA1 ids is sufficient); but release builds of libcl should tag all git repos with their directory name.<br /> These tags will ensure that the proper git tree is always available (fetch/push --tags), especially in the case of branch switches.<br /> <br /> Alternatively, it probably makes more sense to have a parent project which used submodules to track the libcl sources and upstream libraries...</p>

This doesn't affect snapshots, alphas, or betas (where the collection of SHA1 ids is sufficient); but release builds of libcl should tag all git repos with their directory name.<br /> These tags will ensure that the proper git tree is always available (fetch/push --tags), especially in the case of branch switches.<br /> <br /> Alternatively, it probably makes more sense to have a parent project which used submodules to track the libcl sources and upstream libraries...

bug://report/2 2008-12-22T02:37:48Z dherring <table cellspacing="0" cellpadding="3" border="0"> <tr> <td><strong>Bug ID:</strong></td> <td>2</td> </tr> <tr> <td><strong>Summary:</strong></td> <td>compile-libcl uses reader-macros to determine which packages to load</td> </tr> <tr> <td><strong>Product/Component/Version:</strong></td> <td>LibCL Distribution/0.1</td> </tr> <tr> <td><strong>Status:</strong></td> <td>Closed</td> </tr> <tr> <td><strong>Severity:</strong></td> <td>Moderate</td> </table> <p>This works, but it would be better if the structure was reworked to a more general mechanism.<br /> <br /> The biggest problem is things like<br /> #-test :package1<br /> #-test :package-depending-on-package1<br /> <br /> But there are also problems where we need to test something not in *features* (e.g. cl-l10n's requirement that files are read using utf-8).<br /> <br /> Maybe compile-libcl should use an extension of the libcl-packages database...<br /> (libcl-package<br /> ; &lt;current stuff&gt;<br /> :package :package-depending-on-package1<br /> ;; both tests must pass. nil indicates no test required<br /> :feature-test &quot;(and ecl (not unicode))&quot; ; as a string for special reading<br /> :test (lambda () ...) ; must be runnable before anything is compiled<br /> ;; this package will be compiled after its dependencies, and not at all if their tests fail<br /> :depends-on '(:package1))<br /> <br /> Additionally, pass/fail could be logged to drive an implementation-compatibility table.</p>

This works, but it would be better if the structure was reworked to a more general mechanism.<br /> <br /> The biggest problem is things like<br /> #-test :package1<br /> #-test :package-depending-on-package1<br /> <br /> But there are also problems where we need to test something not in *features* (e.g. cl-l10n's requirement that files are read using utf-8).<br /> <br /> Maybe compile-libcl should use an extension of the libcl-packages database...<br /> (libcl-package<br /> ; &lt;current stuff&gt;<br /> :package :package-depending-on-package1<br /> ;; both tests must pass. nil indicates no test required<br /> :feature-test &quot;(and ecl (not unicode))&quot; ; as a string for special reading<br /> :test (lambda () ...) ; must be runnable before anything is compiled<br /> ;; this package will be compiled after its dependencies, and not at all if their tests fail<br /> :depends-on '(:package1))<br /> <br /> Additionally, pass/fail could be logged to drive an implementation-compatibility table.