digitalmars.D - How about a compatibility list?
- Saaa (10/10) Mar 27 2009 Select compiler :
- Christopher Wright (2/14) Mar 27 2009 Who is going to do the work of reviewing these libraries for compatibili...
- Saaa (2/4) Mar 27 2009 The people :)
- Nick Sabalausky (4/8) Mar 27 2009 I would think some of that work could be automated. Of course, setting u...
- Brad Roberts (5/15) Mar 27 2009 It'd likely take roughly the same amount of work to update a list as to
- dsimcha (10/14) Mar 28 2009 That assumes that the person doing it is a major dev on the library and ...
- Christopher Wright (6/15) Mar 28 2009 You would need an acceptance testing framework. Otherwise you couldn't
- Lutger (4/21) Mar 28 2009 I don't think that is needed to make such a list useful. Even if only so...
- Don (5/27) Mar 28 2009 A non-compatibility list might be enough, and it's a lot less work. (Ie,...
- Christopher Wright (4/25) Mar 28 2009 But then it isn't automated. This branch of the discussion is
- Saaa (4/6) Mar 29 2009 Yeah of course that would be awesome, but how difficult is it to set up ...
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:).
Mar 27 2009
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?
Mar 27 2009
Who is going to do the work of reviewing these libraries for compatibility?The people :) like in the wine database.
Mar 27 2009
"Saaa" <empty needmail.com> wrote in message news:gqjjp3$jrg$1 digitalmars.com...I would think some of that work could be automated. Of course, setting up the automation could mean a fair bit of work...Who is going to do the work of reviewing these libraries for compatibility?The people :) like in the wine database.
Mar 27 2009
Nick Sabalausky wrote:"Saaa" <empty needmail.com> wrote in message news:gqjjp3$jrg$1 digitalmars.com...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. - BradI would think some of that work could be automated. Of course, setting up the automation could mean a fair bit of work...Who is going to do the work of reviewing these libraries for compatibility?The people :) like in the wine database.
Mar 27 2009
dsimcha <dsimcha yahoo.com> == Quote from Brad Roberts (braddr puremagic.com)'s articleIt'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. - BradThat 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.
Mar 28 2009
Nick Sabalausky wrote:"Saaa" <empty needmail.com> wrote in message news:gqjjp3$jrg$1 digitalmars.com...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 would think some of that work could be automated. Of course, setting up the automation could mean a fair bit of work...Who is going to do the work of reviewing these libraries for compatibility?The people :) like in the wine database.
Mar 28 2009
Christopher Wright wrote:Nick Sabalausky wrote: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."Saaa" <empty needmail.com> wrote in message news:gqjjp3$jrg$1 digitalmars.com...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 would think some of that work could be automated. Of course, setting up the automation could mean a fair bit of work...Who is going to do the work of reviewing these libraries for compatibility?The people :) like in the wine database.
Mar 28 2009
Lutger wrote:Christopher Wright wrote: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.Nick Sabalausky wrote: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."Saaa" <empty needmail.com> wrote in message news:gqjjp3$jrg$1 digitalmars.com...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 would think some of that work could be automated. Of course, setting up the automation could mean a fair bit of work...Who is going to do the work of reviewing these libraries for compatibility?The people :) like in the wine database.
Mar 28 2009
Lutger wrote:Christopher Wright wrote: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.Nick Sabalausky wrote: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."Saaa" <empty needmail.com> wrote in message news:gqjjp3$jrg$1 digitalmars.com...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 would think some of that work could be automated. Of course, setting up the automation could mean a fair bit of work...Who is going to do the work of reviewing these libraries for compatibility?The people :) like in the wine database.
Mar 28 2009
I would think some of that work could be automated. Of course, setting up the automation could mean a fair bit of work...Yeah of course that would be awesome, but how difficult is it to set up a thing like the wine database?(serious question) As mentioned by dsimcha: For me, writing a review: no problem, creating a patch: big problem.
Mar 29 2009