Select compiler :
dmd 2.026

Get list of compatible libraries:
dwt2 (link to dsource project page or alike)
status: bronze : base compiles, but misses most implementations.
..
etc.

To me this would be very useful; not only can I better choose my compiler, I also get to see what is still around as only projects with people using them get reviewed (I think:).

Saaa wrote:
> Select compiler :
> dmd 2.026
> 
> Get list of compatible libraries:
> dwt2 (link to dsource project page or alike)
> status: bronze : base compiles, but misses most implementations.
> ..
> etc.
> 
> To me this would be very useful; not only can I better choose my compiler, I also get to see what is still around as only projects with people using them get reviewed (I think:). 

Who is going to do the work of reviewing these libraries for compatibility?

> Who is going to do the work of reviewing these libraries for compatibility?
The people :)
 like in the wine database.

"Saaa" <empty@needmail.com> wrote in message news:gqjjp3$jrg$1@digitalmars.com...
>
>> Who is going to do the work of reviewing these libraries for compatibility?
> The people :)
> like in the wine database.

I would think some of that work could be automated. Of course, setting up the automation could mean a fair bit of work...

Nick Sabalausky wrote:
> "Saaa" <empty@needmail.com> wrote in message news:gqjjp3$jrg$1@digitalmars.com...
>>> Who is going to do the work of reviewing these libraries for compatibility?
>> The people :)
>> like in the wine database.
> 
> I would think some of that work could be automated. Of course, setting up the automation could mean a fair bit of work...
> 

It'd likely take roughly the same amount of work to update a list as to actually keep the libraries functional and useful.  It goes without saying which of the two paths would provide the most value.

- Brad

Nick Sabalausky wrote:
> "Saaa" <empty@needmail.com> wrote in message news:gqjjp3$jrg$1@digitalmars.com...
>>> Who is going to do the work of reviewing these libraries for compatibility?
>> The people :)
>> like in the wine database.
> 
> I would think some of that work could be automated. Of course, setting up the automation could mean a fair bit of work...

You would need an acceptance testing framework. Otherwise you couldn't tell whether the project does more than compile.

Granted, for D1 certainly, there have been only few changes that cause semantic changes without syntactic changes. But in D2, that is not necessarily the case.

== Quote from Brad Roberts (braddr@puremagic.com)'s article

> It'd likely take roughly the same amount of work to update a list as to
> actually keep the libraries functional and useful.  It goes without
> saying which of the two paths would provide the most value.
> - Brad

That assumes that the person doing it is a major dev on the library and therefore already understands how the existing code works.  If not, it could be much easier just to black box test the thing and update the compatibility DB.

For me personally, the main reason why I don't write more patches than the very few I do write is because the initial barrier to entry of having to understand how a large codebase works just to fix a small bug is more than I have time for.  When the bug is in some standard library module that is only 1k line of code or something and can easily be understood in isolation, I sometimes do write patches for bugs I want fixed.

Christopher Wright wrote:

> Nick Sabalausky wrote:
>> "Saaa" <empty@needmail.com> wrote in message news:gqjjp3$jrg$1@digitalmars.com...
>>>> Who is going to do the work of reviewing these libraries for compatibility?
>>> The people :)
>>> like in the wine database.
>> 
>> I would think some of that work could be automated. Of course, setting up the automation could mean a fair bit of work...
> 
> You would need an acceptance testing framework. Otherwise you couldn't tell whether the project does more than compile.
> 
> Granted, for D1 certainly, there have been only few changes that cause semantic changes without syntactic changes. But in D2, that is not necessarily the case.

I don't think that is needed to make such a list useful. Even if only some people vote for compatibility with compilers and could post comments, that would be useful to track down the state of affairs.

Lutger wrote:
> Christopher Wright wrote:
> 
>> Nick Sabalausky wrote:
>>> "Saaa" <empty@needmail.com> wrote in message news:gqjjp3$jrg$1@digitalmars.com...
>>>>> Who is going to do the work of reviewing these libraries for compatibility?
>>>> The people :)
>>>> like in the wine database.
>>> I would think some of that work could be automated. Of course, setting up the automation could mean a fair bit of work...
>> You would need an acceptance testing framework. Otherwise you couldn't tell whether the project does more than compile.
>>
>> Granted, for D1 certainly, there have been only few changes that cause semantic changes without syntactic changes. But in D2, that is not necessarily the case.
> 
> I don't think that is needed to make such a list useful. Even if only some people vote for compatibility with compilers and could post comments, that would be useful to track down the state of affairs.
> 
A non-compatibility list might be enough, and it's a lot less work. (Ie, "compatible" only means "hasn't yet been shown to be incompatible"). Any inactive project, once marked as non-compatible, is obviously going to stay that way.

Lutger wrote:
> Christopher Wright wrote:
> 
>> Nick Sabalausky wrote:
>>> "Saaa" <empty@needmail.com> wrote in message news:gqjjp3$jrg$1@digitalmars.com...
>>>>> Who is going to do the work of reviewing these libraries for compatibility?
>>>> The people :)
>>>> like in the wine database.
>>> I would think some of that work could be automated. Of course, setting up the automation could mean a fair bit of work...
>> You would need an acceptance testing framework. Otherwise you couldn't tell whether the project does more than compile.
>>
>> Granted, for D1 certainly, there have been only few changes that cause semantic changes without syntactic changes. But in D2, that is not necessarily the case.
> 
> I don't think that is needed to make such a list useful. Even if only some people vote for compatibility with compilers and could post comments, that would be useful to track down the state of affairs.

But then it isn't automated. This branch of the discussion is particularly about automating the process. For that, you do in fact need to test the code somehow besides just compiling it.