Status of target languages for SWIG 4 #1437
Comments
|
The table above was taken from a discussion on the swig-devel mailing list. This Github issue is for finalizing which target languages will be deleted in SWIG 4.0 and which will be marked as experimental. To summarise this discussion, the languages marked 'Disable' will be disabled in SWIG 4.0 (if already in master) and will not work at all. Unless someone puts in the effort for the language to become 'Experimental', the source code and library files for each of these languages will be deleted in SWIG 4.1 if in master, otherwise the branch will be deleted. A language has a status of 'Experimental' if it is in a mediocre state, but not up to the expected level with regard to completeness, features, documentation, examples and testing. The exact criteria for 'Supported' and 'Experimental' are now documented, see b324d9d. The 'Disable' modules are in a very sub-standard state with no sign of anyone changing this. |
|
Please discuss any amendments to the table over the next couple of weeks before we release SWIG 4. I've changed COM's status to Disable as I don't know of any interest in this module and it is technology that has long since been superceded. @vadz pointed out in the mailing list discussion that Chicken is dropping support for SWIG https://lists.gnu.org/archive/html/chicken-users/2016-10/msg00018.html so I've also changed Chicken's status to Disable. @ojwb, you mentioned on this email discussion that the HHVM module is in a fairly good state barring documentation. If @ng420 or you can add documentation, then it can possibly migrate to Experimental status. What is its test-suite like? I expect that OCaml will migrate from Experimental to Supported soon given the stirling work that @ZackerySpytz is currently putting into the OCaml language module. |
|
I think the HHVM testsuite was in good shape. I don't think I'm the right person to write docs for it, as I really don't know much about HHVM, and even less about "Hack", which is the language which is HHVM's focus now (see https://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html). For the GSoC project I provided support on the SWIG side, and ng420 already knew quite a lot about HHVM having previously interned at facebook (and had some support from the HHVM devs). Unfortunately @ng420 started working full-time for facebook after the project which seems to have swallowed all his spare time. I'm not sure what his current status is though, as I haven't spoken to him for quite a while. Perhaps we should see if the HHVM devs are interested in filling in the missing docs and updating the examples and tests to use Hack instead of the PHP dialect HHVM supports - I'd think having a way to automate wrapping of C/C++ libraries for use from Hack would be useful. @ng420 Can suggest anyone to talk to who might be interested? |
|
As for other languages, I think Tcl is in much better shape than "2006-02-09" date might suggest - I think this mostly reflects that Tcl has had a very stable C extension API for a long time. I think at this point CI coverage is really the key indicator for whether to keep support for a language. With that if a patch breaks something we'll likely see before it's even merged, rather than months or years later when it's not fresh in people's minds, and we probably can't just revert it. If there are no tests for a language then we can't easily tell if it works at all; if there are tests for a language but nobody cares enough to make them work in CI that seems a strong hint that nobody really cares about SWIG supporting that language. |
|
The Fortran branch referenced on the table is an ancient one unrelated to #1195 . I remember looking at it and seeing it had almost nothing more than a skeleton Module file. I can't even find the branch now. |
|
The table is nice but I think it could be useful to also have a clear list of "first tier" languages (Python, C#, Java, ...) because this information is not immediately obvious from the table. Also, I'm definitely not going to work on COM any more, we don't use it any longer as we use .NET interop with SWIG-generated C# bindings instead. As for C, I still would very much like to find a couple of weeks to get back to it one day to make it really usable, but I have no idea when/whether it's going to happen... |
|
Note: The (experimental) MATLAB module is actually MATLAB/Octave bilingual. |
|
@ng420, I'm hoping to release 4.0.0 in February and if you are able to provide documentation it may provide a future for your HHVM module. |
|
@vadz, I'm not sure about a 1st tier table because the variability among the target languages doesn't make this very easy. For example, everyone thinks of Python as being in the 1st tier, but it is quite lacking compared to say D, which is definitely not first tier, with regards to namespace (nspace feature) support. It also does not have full support for nested classes nor enum classes. The next most mature language that might be considered a 1st tier language is Java, but it is also missing various libraries and features compared to Python. All that an attempt to put languages into tiers would achieve is creating 10 tiers with lots of overlap for 10 different languages. If someone want to create a table of features supported, that would be more useful, and rather nice but tricky to maintain. |
|
@jaeandersson, after 4.0.0 is released, I'd be interested in an effort to merge matlab into master if it meets one of the two statuses. |
|
Exactly the fact that it's not that easy is the reason why I think it would be useful to people looking at SWIG to see up front which modules are mature and are being actively maintained and which are not. Of course, this is somewhat subjective but I'd say that Python, Java, C#, PHP and maybe Ruby satisfy both criteria. Other languages probably satisfy the former one, but I'm not sure which ones. To make this slightly more objective, while the amount of activity might not be the best indicator of the "tier" a module belongs to, it does show that the 3 ones I mentioned initially clearly stand out: looking at the total number of commits touching various files under while looking at the commits since 3.0.12 also shows |
|
I've changed Common Lisp CFFI to 'Disable' after looking at the glycerine fork as the status is still well below meeting the 'Experimental' standard. There are no runtime tests in the test-suite for example and nobody has shown interest in improving it. Merging in the glycerine fork in #877 showed some hope, but nothing materialised. |
|
As far as I can make out, there is no 'alisp' executable on Ubuntu/Debian. This is the program that is required in configure.ac for running/testing Allegrocl. There thus seems to be little chance of running the test-suite so I propose to Disable Allegrocl too unless someone can get the test-suite working in the next day or two. |
|
Allegro Common Lisp is proprietary, with a partly hobbled freeware version for non-commercial use - see https://en.wikipedia.org/wiki/Allegro_Common_Lisp for details (and a link to the download page at https://franz.com/downloads/clp/survey). So you won't find it in the Debian or Ubuntu main repositories. It doesn't seem to be in non-free/multiverse either (I guess either the licence doesn't allow redistribution, or else it's too esoteric for anyone to have packaged it). |
|
BTW, if we're going to start removing target languages I think we should tag open issues for them before closing them so that if someone later steps forward to resurrect such a target language it's easy to find the previously open issues (and not have them conflated with issues which were already dealt with). E.g. for CFFI if we tag with (say) "closed-by-removal" (and add tag |
Three status: Disabled, Experimental and Supported. Any target language classified as 'Experimental' will issue new warning 524 SWIGWARN_LANG_EXPERIMENTAL. Any target language classified as 'Disabled' will error out. Languages will be classified in forthcoming commits. Issue #1437
|
All the languages that will be disabled on master for SWIG 4.0 have now been disabled, see #1447. @ojwb, finding associated issues for the disabled languages are detailed in this issue. I didn't really follow your tag approach, I don't think tags are as useful as a plain search and I think we've got too many tags already! |
|
@ojwb, your info about Allegro was useful, thanks. BTW, all the common lisp variants are now disabled and I've updated the table above as such. Shame that there were so many and none of them in any state anywhere near being good enough to keep. |
|
a8f927d brings MzScheme/Racket up to Experimental status. |
|
I've now setup OCaml as an experimental language. @ZackerySpytz, OCaml only just falls short of the Supported status with all the focus you've put on OCaml recently. Note that the Travis setup for experimental languages is to put the language tests under the 'allow_failures' section of .travis.yml. So be aware that the build won't break if there are problems in the OCaml tests/examples. There are only a handful of OCaml test-case failures now so it feels like it is nearly in a great shape to be a supported language. If you'd like to take on the official OCaml maintainer role and fix the last few tests to get it into the supported status, that would be great. Let me know. |
|
All the languages in master are now setup as discussed. I don't have time to pull in the other Experimental languages into master for 4.0.0. I'll do these after this release using new issues, so closing this issue. |
[1] "Last Maintainer Change" column contains the date of the last non-trivial change done by the language maintainer (this is mostly to not count pure maintenance changes by William and Olly, although I do count William's changes for C#, Python and Ruby, which he seems to be maintaining as well, and Olly's changes for PHP). "Antiquity" refers to the period before the global merges/moves (not tracked by cvs in use back then) done at the end of 2002. I didn't bother manually tracking further back in time, no changes since 15 years is a good enough proof of being dead to me. This information was up to date in Feb 2017.
[2] "Test Suite" column contains "CI" if the language is already tested by Travis-CI. "Fail" means that either it is being already tested by Travis-CI but marked as "allow failures" or that I tested it myself (mzscheme) and at least some tests pass -- hopefully this means that it could be made to pass by marking some tests as failing and so be checked by CI. "Bad" means that the test suite doesn't really exist, i.e. there are no language-specific tests and the generic tests don't pass anyhow. "No" means that no tests can be run for this language at all, i.e. there is even no makefile support.
[3] master if not specified
[4] Supported/Standard target language module if not specified
The text was updated successfully, but these errors were encountered: