Langutils

[peter]

From
Re: [pro] CL-PDF in ACL 64bit - anyone know how to get 64bit ZLIB?
At 5:27 AM +0100 14/8/22, Nick Levine wrote:
There should be no "try to build" with quicklisp - it's supposed to Just Work.

Not only does Langutils not work (although it can seem to load OK in
some contexts), but it can be tricky to unpick such as
langutils-tokenize::tokenize-stream with its many layers of macro and
readtable optimizations.

It doesn't seem so obvious as to where to find who might have
unpicked this already. Or find documentation behind a system and its
design intent. I.e. although perhaps nothing should be in Quicklisp
unless pure and solid, it can be quite a goose chase to try to hunt
down remedies when that does not seem the case.

[Nick Levine]

Date: Fri, 22 Aug 2014 12:28:47 +0100
Not only does Langutils not work (although it can seem to load OK in
some contexts), but it can be tricky to unpick such as
langutils-tokenize::tokenize-stream with its many layers of macro
and readtable optimizations.

Googling leads straight to http://common-lisp.net/project/langutils/
and thence to langutils-devel-***@public.gmane.org, which might be a good
place to ask about this.

It doesn't seem so obvious as to where to find who might have
unpicked this already. Or find documentation behind a system and its
design intent. I.e. although perhaps nothing should be in Quicklisp
unless pure and solid, it can be quite a goose chase to try to hunt
down remedies when that does not seem the case.

I don't _think_ it's Quicklisp's concern to ensure how well things
work, only that loading one doesn't break another. Some QL libraries
come with test-suites, and others do not.

But I agree that library quality / support are important parts of
library discovery: if you don't know which ones are generally thought
of as good, or which ones have an active support network, how can you
ever choose between them? Solving the library discovery problem is
probably rather people-intensive, which I imagine is why nobody's done
it. I'm told other languages suffer from this too.

- nick

[Zach Beane]

Post by Nick Levine

Post by peter
It doesn't seem so obvious as to where to find who might have
unpicked this already. Or find documentation behind a system and its
design intent. I.e. although perhaps nothing should be in Quicklisp
unless pure and solid, it can be quite a goose chase to try to hunt
down remedies when that does not seem the case.

I don't _think_ it's Quicklisp's concern to ensure how well things
work, only that loading one doesn't break another. Some QL libraries
come with test-suites, and others do not.

Your thought is correct. When wearing my Quicklisp dist maintainer hat,
I do not judge the quality or necessity of a library. If someone submits
a library to Quicklisp, and it builds, I add it. (In some circumstances,
I do ask the submitter what might distinguish a library from the many
similar libraries already availble, but even then I do not reject the
library.)

Post by Nick Levine
But I agree that library quality / support are important parts of
library discovery: if you don't know which ones are generally thought
of as good, or which ones have an active support network, how can you
ever choose between them? Solving the library discovery problem is
probably rather people-intensive, which I imagine is why nobody's done
it. I'm told other languages suffer from this too.

I think quickdocs.org helps. I would also like to see some mechanism for
incorporating user feedback (e.g. "I tried this library on LispWorks and
it keeps crashing" or "The documentation doesn't match the code any
more" or "This is great, it solved my problem and it's really fast") and
rating. Building such a thing would take a generous expenditure of time
and effort, so I understand why it hasn't popped into existence already.

Zach

[Erik Huelsmann]

Hi Zach,

Post by Zach Beane

Post by Nick Levine
But I agree that library quality / support are important parts of
library discovery: if you don't know which ones are generally thought
of as good, or which ones have an active support network, how can you
ever choose between them? Solving the library discovery problem is
probably rather people-intensive, which I imagine is why nobody's done
it. I'm told other languages suffer from this too.

I think quickdocs.org helps. I would also like to see some mechanism for
incorporating user feedback (e.g. "I tried this library on LispWorks and
it keeps crashing" or "The documentation doesn't match the code any
more" or "This is great, it solved my problem and it's really fast") and
rating. Building such a thing would take a generous expenditure of time
and effort, so I understand why it hasn't popped into existence already.

Do you also see a role for cl-test-grid here, which tests quicklisp
packaged libraries on a large number of platforms and may thus provide
potential users with the insights they need for their platforms?

Bye,


Erik.

[Zach Beane]

Post by Erik Huelsmann
Hi Zach,

Post by Zach Beane

Post by Nick Levine
But I agree that library quality / support are important parts of
library discovery: if you don't know which ones are generally thought
of as good, or which ones have an active support network, how can you
ever choose between them? Solving the library discovery problem is
probably rather people-intensive, which I imagine is why nobody's done
it. I'm told other languages suffer from this too.

I think quickdocs.org helps. I would also like to see some mechanism for
incorporating user feedback (e.g. "I tried this library on LispWorks and
it keeps crashing" or "The documentation doesn't match the code any
more" or "This is great, it solved my problem and it's really fast") and
rating. Building such a thing would take a generous expenditure of time
and effort, so I understand why it hasn't popped into existence already.

Do you also see a role for cl-test-grid here, which tests quicklisp
packaged libraries on a large number of platforms and may thus provide
potential users with the insights they need for their platforms?

Yes, very much so. It would be good to know, at a glance, that some
library has been tested already and is known not to work on your chosen
platform.

It would also be helpful to make that information fairly detailed, on
further clicking, so you can make in informed decision about how
accurate it might be (how recently was it tested?), and what work it
might take to get it to work, or at least to the next failure point.

For example, if some project fails to build on SBCL because it uses the
LispWorks MP package, someone could see that and decide to try updating
it to use bordeaux-threads instead. That might lead to a working
project, or it might lead to a new failure, but at least it's some basis
for making a decision about what to do.

Zach

[Anton Vodonosov]

Post by Zach Beane

 Do you also see a role for cl-test-grid here, which tests quicklisp
 packaged libraries on a large number of platforms and may thus provide
 potential users with the insights they need for their platforms?

Yes, very much so. It would be good to know, at a glance, that some
library has been tested already and is known not to work on your chosen
platform.
It would also be helpful to make that information fairly detailed, on
further clicking, so you can make in informed decision about how
accurate it might be (how recently was it tested?), and what work it
might take to get it to work, or at least to the next failure point.
For example, if some project fails to build on SBCL because it uses the
LispWorks MP package, someone could see that and decide to try updating
it to use bordeaux-threads instead. That might lead to a working
project, or it might lead to a new failure, but at least it's some basis
for making a decision about what to do.

BTW, for those who don't know, latest build results collected by cl-test-grid
for each library Quicklisp may be found here:
http://common-lisp.net/project/cl-test-grid/library/