Hello, Matthew Mondor writes:
> 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). I would appreciate it. Even if I have few ideas by myself, it would point me to some more crucial changes on the list, which I haven't anticipated. > > 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. Could you share your personal fork along with shortage of your discussion? > > 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). I do agree that it would be a shame to just drop resources. SF has downs, and apparently we have two versions of page (one accessible via SF search, and one under address ecls.sourceforge.net. I think it's bad, especially when they present different news set. > > 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. Regarding libgmp, libffi and libgc - I think we need to keep it, but as separate repositories attached to project (present in source tarballs tough). > > 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. That goes in line with my personal opinion. > > Thanks, Thank you for sharing your thoughts, Daniel -- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi ------------------------------------------------------------------------------ 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