[mcclim-devel] Statement of intent: release McCLIM on Mothering Sunday (2005-03-06)
Hi all, I'd like to use my new-found McCLIM committer powers to push a new release of McCLIM out the door. This is the schedule that Xophe came up with on #lisp a few days ago (augmented with real dates): * Freeze McCLIM proper on 2005-02-21 * Freeze Apps/ and Examples/ on 2005-02-28 * Release on 2005-03-06 If that isn't messing with anybody's plans, I'd like to stick to that schedule and upload a nice official tarball in the end. (-: If this release goes well, we could try a bi-monthly release schedule based on that - hack a 6 weeks, freeze two (or just one) weeks, release. Evidence from the mcclim-cvs list archive of the last few months suggests that this could provide usable snapshots of a steadily progressing McCLIM. Happy hacking, -- Andreas Fuchs, <asf@boinkor.net>, asf@jabber.at, antifuchs
With that in mind, would anyone who knows the architecture of the whole McCLIM megalith be willing to put up suggestions for testing? I seem to be about the only person using McCLIM on Allegro. I'd be willing to do some testing in advance of the release, but I need some coaching! Best, R
rpgoldman@real-time.com writes:
With that in mind, would anyone who knows the architecture of the whole McCLIM megalith be willing to put up suggestions for testing?
I don't know even a fraction of the architecture :) That said, although I have my own code, I catch most of the bugs by simply running the applications and demos included with McCLIM, particularly the CLIM Listener. You may try running these programs and executing a few commands. Here is a command that shakes the listener a bit (requires a fast machine...) Show Class Subclasses (class) t Before reporting a bug, you may want to double check by rebuilding McCLIM from scratch after deleting old fasl files. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Hello Andreas, Personally, I am all for it. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------
On Feb 14, 2005, at 9:37 PM, Andreas Fuchs wrote:
Hi all,
I'd like to use my new-found McCLIM committer powers to push a new release of McCLIM out the door.
This is the schedule that Xophe came up with on #lisp a few days ago (augmented with real dates):
* Freeze McCLIM proper on 2005-02-21 * Freeze Apps/ and Examples/ on 2005-02-28 * Release on 2005-03-06
Yes, this is a great idea. Of course there's some major features I'd like to get in before a release :), but that's the whole point of the time-boxed release schedule proposed here. Here are my priorities for an imminent release. Only two of these are personal tasks of mine, hint hint : Make sure McCLIM works well, out of the box, with climacs. I don't think that will be too hard -- we should be there -- but climacs is clearly the major client of McCLIM now; climacs users should be able to install and use McCLIM without problems. Fix bugs that have turned up in accepting-values and updating-output. I hope to have this fixed up today or tomorrow. Look at Paolo's bug list and see if there's any low-hanging fruit. One bug that is not low-hanging but that is extremely embarrassing is numbers-pane-layout-specifiers. Every new user tries an example that specifies the relative sizes of panes using ratios and then wonders why it doesn't work. I've looked at this problem before, wandered deep into the frame layout code, got lost and abandoned, but I would really like to have this bug fixed before a release. Someone should look at the Beagle backend, make sure that it can build and pop something up. Documenting what's missing would be good too. It would be *fabulous* if the Freetype support was useable in CMUCL and SBCL (and OpenMCL too, for I understand that its alien stuff is not too different from the others) with a minimum of user intervention. Does anyone want to take that on? For Apps and Examples: there may be examples that are so old that they should be banished, even if they do work. Some integration of the Inspector and the Listener would be nice. For the release: Some work on the documentation would be nice. I'm planning to write a chapter on "Writing a CLIM application" that would be good to include. A comprehensive list of what's missing or broken would be very useful; I think we can do this with respect to the Franz User's Guide as that would be more helpful the spec for existing CLIM users. Going function-by-function through the guide and listing differences in the McCLIM manual would be very useful, but is probably too much work before this release. That would be a great project if someone wants to take it on. asdf-install enabled! I'd be comfortable dumping support for mk:defsystem -- or any defsystem -- if that would help get things into shape for asdf.
If that isn't messing with anybody's plans, I'd like to stick to that schedule and upload a nice official tarball in the end. (-:
If this release goes well, we could try a bi-monthly release schedule based on that - hack a 6 weeks, freeze two (or just one) weeks, release. Evidence from the mcclim-cvs list archive of the last few months suggests that this could provide usable snapshots of a steadily progressing McCLIM.
Yes yes yes :) Tim
Timothy Moore <moore@bricoworks.com> writes:
Make sure McCLIM works well, out of the box, with climacs. I don't think that will be too hard -- we should be there -- but climacs is clearly the major client of McCLIM now; climacs users should be able to install and use McCLIM without problems.
I think climacs is possibly the closest thing to an application with potential users that's in the "public domain", so to speak, but let's not discount the possibility that there are some silent people working on their own apps :-) If I could be indulged in suggesting one or two relatively cosmetic fixes: one is the bouncing pointer documentation pane in the listener when mousing over a multiline (or simply long) form; another, well... am I allowed to mention the word "scrollbars"? My particular case is that sometimes, in sb-sprof-ui or in my tabcode app, I see a lot of grey at the bottom of a scrolled area where real output ought to be. (I'm afraid I don't even understand how this can happen, but I'll try to characterize it better if this is a new bug for anyone). Cheers, Christophe
On Tue, 2005-02-15 at 10:44 +0000, Christophe Rhodes wrote:
Timothy Moore <moore@bricoworks.com> writes:
Make sure McCLIM works well, out of the box, with climacs. I don't think that will be too hard -- we should be there -- but climacs is clearly the major client of McCLIM now; climacs users should be able to install and use McCLIM without problems.
I think climacs is possibly the closest thing to an application with potential users that's in the "public domain", so to speak, but let's not discount the possibility that there are some silent people working on their own apps :-)
What's so funny? :) I have this game I'm working on, which is in an almost-done state (screenshot available at <URL: http://www.ltn.lv/~jonis/wapi.png >). There are a few things I'd like to add before I release it, but I think it will happen before the next release of McCLIM. It will be public domain, as the Clones game. (And I can't wait till we have some application which uses the McCLIM's GLX backend (I have a few ideas))! -- Janis Dzerins If million people say a stupid thing, it's still a stupid thing.
Christophe Rhodes <csr21@cam.ac.uk> writes:
am I allowed to mention the word "scrollbars"? My particular case is that sometimes, in sb-sprof-ui or in my tabcode app, I see a lot of grey at the bottom of a scrolled area where real output ought to be.
Just in case anyone is confused over what I mean here, a screenshot demonstrating the problem is at <http://www-jcsu.jesus.cam.ac.uk/~csr21/mcclim-scroll-problem.png>. This screenshot was obtained by, in SBCL (mapcar #'require '(:asdf :clx :clim-clx-user :clouseau)) (clouseau:inspector (find-package "CL")) and scrolling down. Cheers, Christophe
Christophe Rhodes <csr21@cam.ac.uk> writes:
Christophe Rhodes <csr21@cam.ac.uk> writes:
am I allowed to mention the word "scrollbars"? My particular case is that sometimes, in sb-sprof-ui or in my tabcode app, I see a lot of grey at the bottom of a scrolled area where real output ought to be.
Just in case anyone is confused over what I mean here, a screenshot demonstrating the problem is at <http://www-jcsu.jesus.cam.ac.uk/~csr21/mcclim-scroll-problem.png>.
Yes, I'm familiar with this problem and confirm it. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
On Tue, 15 Feb 2005 10:44:34 +0000, Christophe Rhodes <csr21@cam.ac.uk> wrote:
am I allowed to mention the word "scrollbars"? My particular case is that sometimes, in sb-sprof-ui or in my tabcode app, I see a lot of grey at the bottom of a scrolled area where real output ought to be. (I'm afraid I don't even understand how this can happen, but I'll try to characterize it better if this is a new bug for anyone).
Here's something you might try for a possibly increased understanding of the scrollbar bug: in the inspector, inspect something particularly long and scroll down until you see the gray. Then click on a blank area of the white part of the window. This issues the command "Toggle Inspect NIL" (doesn't do anything; a minor bug) and it often makes the gray bug go away. This code might also have something to do with the inspector's version of the bug (but I don't really know what's going on, so it might not): (defmethod redisplay-frame-pane :after ((frame inspector) (pane application-pane) &key force-p) (declare (ignore force-p)) (change-space-requirements pane :height (bounding-rectangle-height (stream-output-history pane)))) This has something to do with the scrolling, but I'm not sure exactly what. -Peter
Timothy Moore <moore@bricoworks.com> writes:
On Feb 14, 2005, at 9:37 PM, Andreas Fuchs wrote: [...]
I'd like to use my new-found McCLIM committer powers to push a new release of McCLIM out the door. [...] Yes, this is a great idea. Of course there's some major features I'd
I second that.
Look at Paolo's bug list and see if there's any low-hanging fruit. One
May I suggest this one? Package lock errors when compiling/loading with CMUCL 19 or later http://mcclim.cliki.net/Bug#listener-cmucl-package-lock Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Timothy Moore <moore@bricoworks.com> writes:
include. A comprehensive list of what's missing or broken would be very useful; I think we can do this with respect to the Franz User's
In this Oct 16, 2004 blog entry: McCLIM changes and development status http://www.paoloamoroso.it/log/041016.html I provided a very rough estimate. With the same code, I now get 66 unimplemented symbols out of a total of 1920 symbols in the CLIM package. Back in October 2005, the figures were 69 and 1918 respectively. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
On Tue, 2005-02-15 at 21:26 +0000, Paolo Amoroso wrote:
Timothy Moore <moore@bricoworks.com> writes:
I provided a very rough estimate. With the same code, I now get 66 unimplemented symbols out of a total of 1920 symbols in the CLIM package. Back in October 2005, the figures were 69 and 1918 respectively.
A bit of regress it seems, but don't you accidentally have taken any screenshots back from the future? :) -- Janis Dzerins If million people say a stupid thing, it's still a stupid thing.
On 2005-02-15, Timothy Moore <moore@bricoworks.com> wrote: [reordered for temporal consistency]
asdf-install enabled! I'd be comfortable dumping support for mk:defsystem -- or any defsystem -- if that would help get things into shape for asdf.
Done! I just committed mcclim.asd to the tree. That should make every tar ball made from mcclim ASDF-INSTALLable now. I'll provide a summary of the changes (especially for authors of ASDF-enabled packages that depend on mcclim) soon.
It would be *fabulous* if the Freetype support was useable in CMUCL and SBCL (and OpenMCL too, for I understand that its alien stuff is not too different from the others) with a minimum of user intervention. Does anyone want to take that on?
I'll look into that next. There are some strange forward-references that shouldn't be happening in the code that Brian Mastenbrook ported to SBCL.
If this release goes well, we could try a bi-monthly release schedule based on that - hack a 6 weeks, freeze two (or just one) weeks, release. Evidence from the mcclim-cvs list archive of the last few months suggests that this could provide usable snapshots of a steadily progressing McCLIM.
Yes yes yes :)
(-: Have fun, -- Andreas Fuchs, <asf@boinkor.net>, asf@jabber.at, antifuchs
participants (8)
-
Andreas Fuchs -
Christophe Rhodes -
Janis Dzerins -
Paolo Amoroso -
Peter Scott -
Robert Strandh -
rpgoldman＠real-time.com -
Timothy Moore