|
|
|
<
< |
See also ChangeLog?
|
|
Garance is the pumpkin for the 2.8.0 release.
|
|
<
< |
If you'd like to claim one of these items, grab a copy of the latest test core from ftp://ftp.lily.org/lily/, make the changes, test 'em out, and get them back to garance (as a moo DB is fine) with notes about what you changed. (and, add a note to the item below to indicate you're working on it.)
|
>
> |
If you'd like to claim one of these items, grab a copy of the latest test core from ftp://ftp.lily.org/lily/, make the changes, test 'em out, and get them back to garance (as a moo DB is fine) with notes about what you changed. (and, add a note to the item below to indicate you're working on it.)
|
|
(you should probably contact me to see about the mooDB to start from, as there have been a lot of changes from even the most recent snapshot that is available at ftp://lily.acm.rpi.edu/lily/core/ ... - Garance)
|
|
>
> |
You've probably been wondering why this Wiki entry has been so quiet for the past nine or ten months. Well, even though there are only a few more "little things" left to do, I have been having a lot of trouble getting myself motivated to finish off those last details. It now seems to me that my biggest misgiving is that there are a few more "BIG CHANGES" that I really want to get done before making this release.
Right now this release incorporates a huge number of improvements over the previous official release, but it will be a major headache for any existing lily-site to upgrade to. I expect that is pretty much unavoidable, so that doesn't really bother me. What does bother me is that the next release will probably just as much of a nighmare to upgrade to as this one will be. IMO, as it stands right now this release does not do enough to make the next release any easier for people at other (non-RPI) sites. So, I want to make at least some changes which will improve on that situation before making this an official release. -- gad/Nov 28/2005
|
|
Issues that need to be resolved before that release is cut:
|
|
<
< |
- Improve the handling of 'URL' matching & output.
- URL matching only shows a single URL for events which have multiple URL's. (important to fix)
- URL matching does not include the non-URL context of the event. (not as important)
- This was actually by design, "url" was supposed to be urls only. FYI, -Coke
- Maybe I'll add another keyword for this, like 'urlcontext' or something. I find that if I'm looking for some URL that was sent a few days ago, a plain-URL listing gives me a nice list of URL's, but then I can't tell which one I want to use.
- Suggestion, just use "context", which would then work with any restrictive keyword to show the context -Coke
|
>
> |
- I should note that I have something specific in mind to accomplish what I wrote (above) on Nov 28th. I even have a rough outline of it in a text file I have at home. It is probably a bad sign that the last three times I've connected here to write up the details, something has interrupted me for long enough that I just cancel the 'edit' here on the TWiki page. And as I type this, I suspect my UPS may be melting down . So this may very well be a fourth time. Anyway, if I ever do get the time to write my plans up, they will appear as ReorgToSupportSites?. Those plans have several specific steps, which will be listed as sub-entries under this entry... -- gad/Dec 05/2005
|
|
- Remove some of the old objects/verbs which are no longer used, and which just confuse people (like me...) who are trying to figure out what the present code is doing.
|
|
|
|
<
< |
-
- In the following section, [done] means that I think it's fixed well-enough for release, but other people should check the results to see if I missed (or broke) something. -gad
|
|
-
- There are other items I want to fix up before release, but I don't have the list sitting in front of me at the moment. -gad
- Some of these items will probably slip to a later release (NeededForRelease281), if I run out of time or energy, but I wanted to at least write them down... -gad
|
|
<
< |
- [done] Improve the handling of 'URL' matching & output.
- I would like to handle '/review disc last 2url' the same as '/review disc last 2e url', and in particular I'd like to support '/review disc last url' (much less important)
- This might be as easy as having "last" with no valid arguments default to "last 1e". -Coke
- Yeah. I almost said "this is not important, but since it is the easiest thing to do it may end up getting done first..."
 -gad
- I have now implemented this, supporting three new forms: 'last url' (no count given), 'last 2url' (count given with 'url' in same arg), and 'last 3 urls' (count given, with 'url' as the next arg). It was a bit harder than I originally expected, because once I started on it, I felt it was important to support all three forms. -gad/Nov 05/2004
- [done] Finish merging the help-information that's in the various cores I have been merging for the past few months.
- Ghim did do a lot of good work to merge some things from the RPI core to the 'cr7' core, but there's still a lot of differences, and there's some help information from the devCore which should also be included.
- Mainly I just need to spruce up my splitcore script so it's easy for me to see the differences, and then merge them from one core to another. I thought up a fairly reasonable way to do that last night, so now I just need to implement it...
- I have not made those changes to splitcore yet, but I did implement a '$rebuild help' ability. This just sorts a list of help-related "indexed-list" variables, thus making it much easier for me to figure out the differences between help entries in two cores. I still need to do the splitcore changes so it's easy to copy entries between cores, but this helps enough that I can at least update some of the help entries by hand. The '$rebuild help' ability is not installed at RPI yet, but it is installed in my development cores. There's a few more things on it that I want to polish up first, even though it's pretty usable as it is. - gad/Jan 01/2004
- Well, I think I have the help-information sync'ed up between the cr7 and RPI cores, except for the help on '/rename -disc'. I also found a lot of bogus entries on the main lily_help index, and (eventually) realized those were caused by the behavior of ?gethelp. It was creating topics if you asked for a topic that didn't already exist, which was particularly bad if you had the right name but forgot to specify the non-lily index. I've modified ?gethelp to be much smarter about various issues. -gad/Jan 01/2004
- that doesn't mean the help information is all perfect, just that it's the same on both cores, taking the best from each one. It's also in better shape than it was, partially due to me deleting all the bogus help entries.
- While there is plenty of room for improvement in various help entries, this item was just about merging the best help from the available cores. That is done now. Also, I added an entry to the "programmers help" index, and fixed the /help command so programmers will have a pointer to it. Thus, that status of /help is good enough for a release, IMO. - gad/Jan 03/2004
- [done] Add a new /set option: strict_sendlist . This is similar to the send_member option in devCore, but not quite the same.
- initial cut of this has been installed at RPI, but there are a few loose ends. At the very least, the descriptions of it could be improved (ie, what you're told when setting the option ON or OFF), and I haven't added any /help info yet. - gad/Dec 24/2003
- CoKe added the help entry for strict_sendlist, and after starting at the screen for a half-hour I came up with adequate one-line status messages when you /set the value on or off. I also improved the way group-expansion is handled when strict_sendlist is requested. So, I think this is now good-enough for a release. - gad/Jan 03/2004
- [done] Various fixes to the systemCleanup processing.
- I fixed a few problems which occasionally caused an exception (caught in a try/except clause) in the test core. - gad
- Since systemCleanup is running all the time, and successfully captured (with all it's state) in a checkpoint, there was a problem where you would get systemCleanup the second you restarted a checkpoint, if the checkpoint was from more than $cleanupInterval seconds old. I now have it so a systemCleanup with never occur less than $cleanupInterval seconds after a snapshot has been restarted. -gad/Jan 02/2004
- [done] We must fix BugOrFeatureOfAliasCmd (users can alias to non-command routines on $command_mode)
- I have added a '/message' command to RPI, so people can /alias directly to a legitimate command instead of using the 'feature' part of this. -gad/Dec 25/2003
- If you wonder why I was so keen about this, it gave any user a way to get around disabled commands. -gad
- I have installed a complete rewrite of /alias at RPI, which fixes this bug (among many other changes). The new /alias command probably adds a few things that it would be nice to document in /help, but that isn't a requirement for release. Assuming there are no bugs found in the new /alias, I think this is in good shape. -gad/Dec 26/2003
- [done] The new /review command needs to include date stamps in all reviews.
- This is almost as easy as forcing "event sysmsg" to be assumed everywhere, except for "last 10e". This is almost as easy as emitting fake sysmsg whenever a date boundary is changed. -Coke
- See NewReviewTimestamps for a description of a different tactic that I've been working on, and as of very-early on Dec 16th I've got it pretty much working the way I want it to. Hope to have it installed at RPI before the end of the week. -gad
- Later that same day, I felt the changes were in a pretty solid state, so I did install them at RPI. -gad/Dec 16/2003
- [done] I would like to fix the problems where a call to read() is interrupted due to the user's session being redirected to a new connection. This most often appears as problems in chooseBlurb or chooseName, but really it can happen with any code that calls read().
- I suspect this will have to wait for some later release, as I haven't figured out any good way to fix the problem.
- It's like the old connection leaves read() in such a state that the first time the new connection calls read(), it wakes up whatever process had been executing in the old connection -- but in a way that the read() can not succeed. There are various ways to "kinda" get around this, but so far I haven't come up with anything that I'm particularly happy with. I have almost convinced myself that this could be a bug in lambdaMOO itself. Or it might be something we just need to reset in the disfunc() verb. -gad
- I sent a few messages to the lambdaMOO mailing list, and it is highly likely that we see this problem because we're trying to do read() calls in the middle of the user_connected() processing. The connection is in a kind of funny state when that verb is called. It's "kinda" logged in, but not completely. There are special-case rules for how read() works in that verb, and (for instance) the rules change if a suspend() is called for any reason before read() is called. It is also possible that we're hitting a bug in lambdaMOO, but even that would be because we're trying to get away with a pretty special edge case. -gad
- I have figured out a fairly good way to avoid this problem, and have put try/except clauses around almost all the calls to read(), except for some in $transfer processing and in jabber support. The main mistake in previous attempts was not realizing that it was the previous connection which was writing the errors to the new connection. That, and calling boot_user() instead of kill_task(). You only need to kill the task left over from the old connection, you don't want to log the user off... -gad/dec 23/2003
|
>
> |
The remaining entries in the original "must do" list have been moved to a ReadyForRelease280 entry, simply to make this web page smaller and less-intimidating. -- gad/Nov 28/2005
|
|
|
|
<
< |
-- initial version by CoKe - 04 Dec 2003
|
>
> |
-- initial version of this list by CoKe - 04 Dec 2003
|
|
-- list updated frequently by GaranceDrosehn (aka -gad)
|