Sorry for not having been active, including on this list.
On Sun, 15 Feb 2015 21:55:20 +0100 Daniel Kochmański <jackdan...@hellsgate.pl> wrote: > most of you have probably noticed, that ECL is unmaintained for quite a > while. Some spontaneous attempts are made, like submitting a patch, or > answering question - what is great, but insufficient. Many important bug > fixes last on git head, a few potential improvements wait in patch > queue. The other words - ECL starts to smell funny, what's a shame, > since it's a great project. Earlier on this list archives I also have a TODO which might perhaps serve as inspiration (I could possibly attempt to find it). Unfortunately, some changes made to ECL broke some of my code (most notably the conformance fix for strings, which is suboptimal to work with C FFI; actually some of ECL's code broke too with this change), and since I have no time to develop proper solutions to the problem (like good ideas derived from CLISP as previously discussed with PJB), I consider my personal copy as a fork already. Although I still use ECL actively (that fork at least), I'm unlikely to have time to help soon, I'm sorry about that. An issue also made me reconsider ECL for future projects, but this has more to do with boehm-gc bugs on NetBSD (heap growing bugs when multithreaded) than with ECL itself, and I've not have had time to seriously look at it either, but know some workarounds like not using stdio and initially growing the heap. Previously we had decided to remain on SF when previous maintainership changed, and I don't think that SF is what prevents development; but since as I previously said I won't be able to help in a decent amount of time, feel free to move the project elsewhere if other active members agree. Please make a clear announcement here about where to locate the new resources (mailing list, repository, problem reports), if/when moving. I would also suggest to ensure that an archive of this mailing list remain if possible (as necessary keeping the ECL project on SF with clear information that it's deprecated and where to find it officially). As for swank, I'm not sure it should be part of ECL, that comes with third-party SLIME, and there are no established API versions for guarenteed compatibility between the two when upgrading one of the parts. To me, ASDF and QuickLisp are also third-party and I don't use them, but it would make sense for them to be supported natively, if only to make ECL more popular and easy to use. The ECL-provided libgmp, libffi and libgc probably include portability fixes, although I personally don't use them anymore either (building ECL to depend on OS/package-installed ones instead). I suspect that if ECL binary builds were supported and distributed, it might be a good thing to keep them around and update them as necessary. There also was the previous discussion on LGPLv3, which allows relicensing under GPLv3 or AGPLv3. It however does not seem to be a problem unless the official ECL itself decided to change its license. The project already depending on libraries under the LGPL variants, a less restricted license such as MIT/BSDL would not make much difference for ECL; upgrading to LGPLv3 might be the best choice. Please don't choose the GPLv3 or AGPLv3 for the official project however, which would be counterproductive to the way ECL is intended/designed to be used. Thanks, -- Matt ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list