Ltk seems like a fantastic idea. I don't personally use it, but I like that there's a fairly simple and easy option for people who want to make a GUI with Common Lisp.
Unfortunately, it doesn't build on SBCL any more. SBCL exports sb-ext:exit (eventually replacing sb-ext:quit), and a package in Ltk triggers a package lock conflict because of it. I've emailed Peter Herth about the build failure, but a few months have passed and the problem persists.
Does anyone who reads this blog use Ltk? Would you be upset if Ltk is dropped from Quicklisp until the issue is fixed?
I do and would be upset. Also AFAIK, some neat systems like ABLE depend on it.
ReplyDeleteAn alternative not dissimilar to LTK is GTK-server.
ReplyDeleteI've wandered around looking for GUIs that don't require elaborate building and configuring FFIs, and LTK pretty much fits that bill pretty well.
ReplyDeleteI sent in a patch to the mailing list that hacks around the SBCL build failure, but I've not gotten a response. I suppose I should follow up soon to try and push it through.
I have used it in the past and I would prefer that it stay in quicklisp, or that it is excluded for only a short time.
ReplyDeleteAll that's needed is to add
ReplyDelete#+sbcl (:shadow #:exit)
to the defpackage form. The ltk author was active on the list just five days ago, so I assume the issue will be resolved soon.
Here's another Ltk user. I would miss it.
ReplyDeleteIf it doesn't build than it should be removed...
ReplyDeleteI do. I'd be upset very much.
ReplyDeleteany package that doesn't build should be removed until it has been fixed
ReplyDeleteI use it, would miss it, and I think that this will be resolved soon. Those that do use it probably are all running a self-patched version as it is right now.
ReplyDeleteThat said, if dropping a package here and there reduces any headache for you, especially if the maintainer has not shown a willingness to fix things, I say drop it for the time being. Having Quicklisp be a place where I can trust that the libraries will work is an important strength that I wouldn't want to lose.
Is is only a problem with SBCL? Then it should stay. Quicklisp is claimed to be implementation agnostic, so problem with one particular implementation shouldnt trigger an exclusion for _all_ implementations.
ReplyDeleteYou should make an statement about which implementations are officially supported and whether users of implementations other than SBCL can expect to have systems thrown out solely because they dont work with your preferred implementation.
Maybe the effort to support all existing implementations is too great related to the expected benefit, maybe the common lisp community is too small and should focus all effort on one implementation to maximize impact, but this should be clearly communicated.
ABLE, ABLE, ABLE!!!
ReplyDeleteAnyway, SBCL balking at several packages loaded through Quicklisp was what made me switch to ClozureCL.
So:
- should every offending package author run to fix it or having it ditched from Quicklisp?
- should SBCL team decide to relax a bit (maybe using some commandline option)?
- should Quicklisp just support SBCL as the de-facto implementation
or...
- should Quicklisp try to redefine package definitions on the fly for those non-sbcl-compliant packages, as someone suggested before: >> #+sbcl (:shadow #:exit)<< ?
Clearly the last option is not the lightest one for Quicklisp author (btw, thanx a lot, you are a hero!) but I hope it to be the one that will prevail in some way (ql:quickload-hacked), after all having a safe running package is good, having 700+ of them is much, much better!
Also, LTK is a popular one...
Cheers,
N.
Well, I would simply "spam" (read: annoy) offending authors who don't want to correct such trivial errors.
ReplyDeleteThe causes such authors don't intervene are probably trivial, and easy to overcome...
It was fixed on July 29.
ReplyDelete