See also the LilyCoreChangelog entry.

---

In the following list, the [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

---

• [done] Apparently there is a problem with the source-code for MOO that we have been using all these years, which Coke come across. The source in lily/moo/moo-1.8.1.g1.tar.gz both compiles and works fine on my older FreeBSD boxes. On newer versions of FreeBSD it also compiles perfectly fine, but then various network-related built-in verbs fail. "That Shouldn't Happen!" And the exact nature of the problems are different on different platforms. I think we need to pin down the problems here in case we need to make some changes to lilyCore to solve them. I think it's 95% likely that the problem is in the MOO code itself, but I'd like to know that for sure before 2.8.1 is released. -- gad/Dec 07/2005
  • The recent reboot of the lily server @RPI included switching the server to a newer release of FreeBSD. That, in turn, triggered a number of frustratingly intermittent bugs, which forced me to spend a good deal of time trying to figure out where the problem was. It turns out that the problem wasn't with FreeBSD 5.x (or a new gcc, or OS support for IPv6, or...), the problem was a few obscure bugs in LambdaMOO itself. I have found two places where LambdaMOO frees a struct of information, and then pulls a value out of that struct. This will probably work 99.9% of the time, except that I happened to have FreeBSD's malloc-debugging turned on in the new system. (that debugging causes memory to be written-over as soon it is freed). I have now fixed these bugs in RPI's production server, I am also side-stepping any others for the moment by explicitly turning off that malloc-debugging in the 'restart.sh' script. -- gad/Jun 05/2006
  • The new snapshot of LambdaMOO source, with these (and other) bug fixes, is available in the file lily/moo/moo-1.8.1.g2.tar.gz from public ftp from lily.acm.rpi.edu. -- gad/Jun 05/2006
  • Now, this breakthrough doesn't mean release 2.8.0 of the lilycoreDB is imminent, but it is true that I have been very uneasy about making any release when it looked like we couldn't even recreate a reliable version of lambdaMOO! -- gad/Jun 04/2006

• [done] 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
    • This was actually completed some time ago, available as an option called 'urlx' (alternative to the 'url' option). At some point I will add a user-settable option to set which behavior/format users will see by default. I have some more ideas on URL-handling, but what has been done so far is good enough for the 2.8.0 release. -gad/Nov 28/2005

• [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

-- This Wiki page initially created by moving entries from NeededForRelease280 to this page; GaranceDrosehn - 28 Nov 2005

to top