to report problems and issues with wubwikit; this will allow us to track them more carefully.This page is being obsoleted.LV 2007 Oct 15ARRRRGGG!!!Okay, besides Lynx not being able to handle Unicode correctly, now I discover that the Firefox 2.0 on Windows XP , set to Unicode character encoding, apparently doesn't work right either. I tried to make a change on the XOTcl page, and Wubwiki reports that the resulting page had an invalid character.Sigh.[AlbrechtMucha] There where strange character combinations around "Publisher-Subscriber" in the middle of the document. The same message came with firefox in Linux.
LVSo, I don't know if this is a problem or just a strange behavior. Maybe someone in the know can comment.I see, on a regular basis, entries on the Recent Changes page without a user field specified. There is always an IP address. But I thought that in this latest incarnation of the wiki code, page changes required a user "name".Is there perhaps a bug that allows that field to be empty or just contain a space or something?
CMcC bug in closing a connection resulting in infinite loop leading to memory exhaustion causing process to exit. Side effect - the logs were 2Gb and this size prevented the daemon from restarting. 2Jul07
CMcC Problem with page saving seemes to be fixed. The intent is to redirect to the newly edited page, but getting Create to redirect is subtle. There's really no good way to do this. Currently using the SeeOther 303 HTTP response, because 201 isn't implemented by any browsers. Added a meta-redirect as well. Erk.
KBK Implementing history required several pages to be renumbered; this was necessary because the database corruption of 17 March 2006 and subsequent restoration on a new machine caused multiple copies of some pages to appear, that then went their separate ways and caused conflicts when trying to merge the change logs from the old and new machines. A list of Pages renumbered on 12 June 2007 is available.KBK Owing to various problems that happened over the years, the Wiki is known to have a number of Pages containing invalid UTF-8 sequences. People who are interested in improving the Wiki are invited to attempt to repair the text of these pages.LV Wiki gnomes - I am not a good candidate to attempt to fix the invalid utf-8, given the limited fonts I have here and even worse the limited knowledge I have of other languages. Would some of you multi-lingual types take a crack at that? Or, at the very least, see if you can determine who entered the data originally and email them requesting they update their contribution?
New Problems edit
Please add new observations at the issue tracking link here: [1].- MJ 18 Jun 2007 - The links to the revisions on an annotated page use _rev instead of _revision e.g. http://wiki.tcl.tk/_rev/3330?V=55&A=1 instead of http://wiki.tcl.tk/_revision/3330?V=55&A=1. CMcC Fixed.
- escargo 18 Jun 2007 - Some edits were lost from the 15th and 16th. There is no tracking I can find of when errors have forced lossage of changes. Could a list of outages be created somewhere, so we know when we might have to add changes back in? (One hopes such a list would be small and then eventually not growing.)
- Lars H, 2007-06-16: There seems to be some Unicode problems again. I just painstakingly repaired De elva reglerna, but the characters are still wrong when I view them. Looks like the wiki interpreted utf-8 bytesequences as iso8859-1 when it saved them, because it is equally wrong when I press "Edit" again.
- lv 2007 june 13 - on http://wiki.tcl.tk/2352 , there is, in the section "Where did the term "Batteries Included" come from?, a link to the web.archive.org cache. This website uses a peculiar method of URLs, where http: appears at least twice in the URL. This causes the current wiki renderer heartburn - we get:
g[62]http://web.archive.org/web/19990116233107/http://www.sunworld.com/swol-12-1998/swol-12-regex.html#1instead of [62]in lynx, and even the GUI browsers don't like the rendered html. Lars H: This looks like the same problem as in the old wiki. The problem then was that the links-in-free-text parser was used also for links-within-brackets, which meant every kind of link ends at the first thing that looks like "punctuation". The extra garbage you see is because there is some pre- and postprocessing of bracketed material which conversely assumes everything between the brackets is turned into a link. When these assumptions collide, markup internal to the parser survives to the output.
- lv 2007 june 13 - It is rather strange - today I have begun seeing commits of page changes return [edit conflicts]. Note that the change conflict was with myself - and I wasn't editing the page on another window... Also note that my changes are actually in the shown page! CMcC Either a bug caused by db corruption, or a fault in the tcl - keep an eye on it after the db changes, and we'll assess the problem if it recurs.
- lv 2007 June 13 - wow - today has been like Christmas, with all the great stuff appearing on the wiki! Congratulations! I notice what appears, to my ignorant eye, that some sort of (I suspect browser related) damage has happened over on http://wiki.tcl.tk/34 betwen version 1134 and 1135. At least, the delta shows kanji used to be there, and afterwards, not-kanji...
- escargo 13 Jun 2007 - Wiki history has come back! The delta symbol after the Changes line escaped my notice for a bit, but it's good. However, I did find a little problem here: http://wiki.tcl.tk/_revision/19612?V=0&A=1 -- the HTML link has unescaped square brackets around it, which I don't think should be the case. CMcC No, I think it ought - didn't want to expose the naked URL. -- escargo Since the brackets are clickable, and clicking them leads to an error (/_revision/_edit/19613 Not Found The entity '/_revision/_edit/19613' doesn't exist.), I think making the brackets clickable is wrong. CMcC Oh, I see what you mean - the delta version has clickable brackets ... I see. Thanks for picking that up.
- escargo 13 Jun 2007 - It appears that you can't use [Changes] or [Recent Changes] in the body of page to refer to those special pages in the wiki. CMcC it's called [Recent] for some reason ... should it not be? -- escargo It appears as [Changes] at the bottom of the page...., and when you click on it the title of the page is Recent Changes. CMcC Would calling it [Recent Changes] be best? -- escargo I think linking to a page by using its visible title is the best choice. LV If a change is made here, I hope that the search facility will find the same page. Right now, if I use search for Recent Changes all that appears is the page discussing an RSS feed for page 4... CMcC noticed that too. Suspect the problem is that keyword search doesn't handle multi-word input for some reason. If so, then making that consistent is quite a bit of work, and goes down the action queue accordingly. Or maybe it's a problem related to the chess* problem. I think it isn't multi-word - I can type
- HZe 2007 June 10 - is it correct that the new Wikit is not indexed by Google anymore? Or is it just not yet in Google's index? CMcC as far as I know it's being indexed.
- LV http://wiki.tcl.tk/chess* I got a page - but not the page I expected. I expected a search result page. Instead, I got a page called "chess hazlett". Note that this is despite the fact that there is a page called "chess" which has the word chess in it. aa Try it again with different capitalization -- http://wiki.tcl.tk/Chess* -- and the results are more like what one would expect. Is that a useful clue for finding and correcting the problem?
- Steve Blinkhorn I notice that page loading now often stalls, but cancelling the page download and repeating the request results in immediate service. Firefox on NetBSD, as it happens, but seems to me wiki.tcl.tk-specific. It happened when I tried to save this comment as well. CMcC I expect this to have been fixed, and also expect the wiki to be faster now than it was. Steve Blinkhorn 22nd May: still happening - I now routinely click twice (not a double-click) to get a page.
- LV When I get http://mini.net/tcl/cgi-bin/wikit.gz , I get an old, pre-March 17th version of the wiki. When I try http://wiki.tcl.tk/cgi-bin/wikit.gz , I get nothing. Where do I go to get the latest version of the wikit?
- MG Not a problem, per se, but on the Edit page, there used to be a very helpful list of the basic markups available shown at the bottom. Any chance something like that could be added back in?
Solved Problems edit
- Daily sigsegv - Fixed seems the problem really was running out of swap. Increased the swap size to 1Gb from 512Mb and it's working happily. Served over 15,000 pages and there's no evidence of decreasing available virtual memory.
- RS would like the edit area widened - best to do with CSS? As a %? CMcC done
- stevel: need to install ImageMagick - done, captcha should now work.
- some pages (specifically search and edit pages) aren't being properly decoded. That's why you see the title: stuff at the top, and no CSS colouring
- implicit search is different from explicit search, as per the original wikit.
- fixed Caching problem.
- rss feed now available at /rss.xml
- removed some killed pages from recent changes.
- encoding problem on searching.
- LV 2007 June 05 - when I went to create a page for the ftp::get tcl code, the wiki thought it saw a URI and turned it into a link rather than a page reference. Should the URI identification code think that :: be a delimiter rather than :// ?
- Lynx unfriendliness - fixed
- Unicode editing - fixed (please inform if not)
- EMJ 13 jun 2007 - http://wiki.tcl.tk/_ref/2187 gives a server error - since this is Category Category it is just slightly important. CMcC fixed thanks for spotting it.
- LV 2007 June 10 - today, when I attempted to edit the XChat Plugins page, the wiki changed all the newlines to () Makes the page very difficult to read. I wonder if it will do the same here. CMcC Sorry about that - glitch, fixed.
- Lars H, 2007-06-16: In the dislocate page, there is in the middle of a code block (grey background, monowidth font, etc.) fairly far down two hyperlinked brackets, as for a wiki reference to a page not yet created. JSI, 2007-06-18 inserting some leading spaces and a missing closing bracket didn't solve it. jdc, 2007-06-18. The piece of code was within === markup (fix font block). Removing the === markup or replacing it by ====== markup (code block, no need for leading space) solves the problem.
Improvements edit
- moved login form to edit page (where necessary)
- added localhost console
- made able to run under daemon package
- added search entry to each page
- fixed x-system encoding problem.
- distinguished non-routable IP sources more carefully
Planned Enhancements edit
- there is a facility for the server to go idle and then perform some script - the server responds to new requests with a 'try again later' message, and waits for the termination of existing pipelines, then executes the nominated script. This is to allow maintenance operations while minimising disruption, and partly-completed transactions. Unfortunately, it doesn't work properly because some connections aren't correctly detected as broken by the server. This needs to be fixed as a matter of some priority.
- implement wikit functionality wrt IMG headers
Wishlist
- RS: how about counting page visits? Have a "Most often visited" score?
- Lars H: When the revisions are back up, make hyperlinks in the Recent Changes page directly to the diff over (say) the last 24h, last 48h and the last 7 days. This would make it easier to catch up on what has happened.
- Not a problem - yet - but an observation. The new wiki software has added at least two things to the pages that a text web browsers see. The search box is right beside a new link not intended for use by users. The proximity of the two links is pretty close. I suggest that perhaps it would be worthwhile to force some space or some other kind of delimiter between these, so as to help reduce the possibility of accidentally hitting the wrong thing. CMcC good idea.
- Replace the category links with a tagging system, with a preset list of tags that can be used, plus a relatively trivial means for requesting new tags. The idea is that with a fixed vocabulary, displayable on the edit page, people might be able to do some of the marking themselves, and we have less problem with typos, etc. It would be important to provide some sort of tag search capability similar to how the categories make use of the wikit's page reference list searching.
Remaining Problems edit
In Summary (ordered by importance)- Revision History - requires decisions + human resources
Revision history
LV So, what are the issues outstanding for returning access to revision history?Search Encoding solved
- searching with spaces in search term (in the url) fails, the spaces are encoded as %20
Unicode solved
- unicode isn't working - utf-8 isn't being properly handled. Symptomatic: ;charset= is duplicated sometimes.
- LV When I attempt to modify the Windows Inspection Tool Set wikit page - http://wiki.tcl.tk/15501 , my attempts fail, using either lynx on Solaris or Windows Firefox, Netscape, or Internet Explorer, because of an "invalid character" being written out. I wonder what browser I'm going to have to use to edit the page... Looks like I don't have an option- that's all the editors I have.
- LV I'm told on the wiki chat that the problem is that the wikit is sending incorrect html/headers, and in theory once that is corrected, the problem goes away. Perhaps this is why bad characters got into the wikit initially. There are two problems. The wiki db contains bad characters and the wikit is sending incorrect html/headers.
- Wiki contains bad UTF-8 - need to get together a list of pages for wikignomes to fix.
- Wiki contains bad UTF-8 in some titles - need to fix those somehow. LV If the page has no references, then perhaps having an administrative form to change the title. If there are references to the title, then things become more complex.
- fix encoding of transmitted data
- fix current contents which are badly encoded.
Lynx Unfriendliness pending
CMcC I've just discovered that (it appears) some clients can sit idle for 20s while sending a header. I'm surprised by that, though perhaps I shouldn't be. The response to this situation is going to change, and now the connection will be dropped when all traffic bound for the client has been sent. See if that helps.LV It doesn't appear to be helping. I am still seeing 20-30 second delays before completing the display of pages. But I am also seeing a few seconds delays before a page begins displaying. The weirdness here is that it isn't consistent - sometimes, a page starts displaying right away, and other times there is a long delay before the page begins to display. In both cases, the 20+ second delay between completion of page display and closing of connection continues.CMcC is this in Lynx? Which browser?LV Yes, this is lynx. I sent you an email from the primary lynx developer. I'm using lynx 2.8.7dev.4 right now.LV Wow - just a little while later, and what a difference! I emailed Colin, thanking him and telling him that it is like heaven now!CMcC Thank you for your patient help in tracking it down, LVLV access by lynx text web browser seems to work strangely - for example, when going to page 4, the page is displayed, but the browser then seems to sit waiting on something from the server for a minute or so before returning to the user for input.CMcC I thought this was related to the x-system problem, but it definitely is not that - that problem's been fixed, but the lynx unfriendliness persists.LV More info on this problem. What I see, if I check the status, is the message that 18 of 22k of a page has been sent back to lynx. However, if I tell lynx to stop waiting for info from the server, the entire wiki page is present. I don't know what other 4 k of data is being help up, but if this is load related, then the load on the wiki must be horrendous, because about 65% of the pages I visit result in this behavior.CMcC It sounds like Lynx is expecting more input than it's getting. I wonder if this is related to the Unicode problem? If the encoding was bollocksd (which it is) and graphical browsers were more savvy to the brokenness than Lynx is, that might account for it.CMcC 3May07 - reported that lynx v 2.8.5 can access the wiki with no problems. Raises the question, what's changed between 2.8.5 and 2.8.7? Secondly, I can't get lynx to even access the wiki from here, no connection arrives at the wiki machine at all. Something screwy going on with 2.8.7 dev versions?LV 2007 May 17 - for several weeks, lynx users were enjoying access to the wikit. However, today I notice the problem is back. I don't know if it returned today, or late yesterday...
Disappearing pages? edit
NEM: I created the page invoke yesterday, but it vanished by today. I've recreated it, but my user page (Neil Madden) still shows the link as yet to be created. Likewise the title of the invoke page was not a link, indicating that no pages refer to it (that will probably change now that I've linked to it from here).LV Even in the previous incarnation of the wikit, I noticed cases where I would create a link to a page, then use that link to go to the new page, come back and find the link still marked as yet to be created. And the weird thing was that it wasn't consistent. Editing the page with the original link on it seems to resolve the situation. What concerns me more is that this is not the first time I've noticed someone saying that the page they created disappeared. However, the last point in this section says that there was a database problem yesterday - perhaps those types of events are causing the loss?CMcC I expect that the problem might be caused by the fact that I'm restarting the wikit several times per day, adding enhancements, fixing problems and such. If this is so, the problem is inherently self-limiting to the extent that the number of bugs and hence the frequency of restarts moves monotonically and asymptotically toward 0 per day average.There is a facility for the console to send the wiki server idle, such that it will defer new connections, and wait until current connections go away. However, until I have the connection stuff properly sorted out (which is what /_activity is supposed to facilitate) the go_idle is relatively ineffective (because some connections got wedged open.)Now the connection wedging seems to be ameliorated, if not completely cured, it's likely that (if the problem is actually due to uncoordinated restarts) the problem concerning NEM will disappear.IF, on the other hand, as LV suggests, there's a deeper problem preexisting in the Wikit, we'll burn that bridge when we come to it.LV Colin, I'm not certain I understand why restarting the server would cause pages to be renumbered or possibly to disappear. Surely as new pages are created, the contents are still be cached up for future source code incorporation...Caching fixed
- although the wiki (as written) accepts any host field that's thrown at it, it caches with what it believes to be the definitive hostname, and then can't invalidate the cache entry from anything but the definitive host. This should be reasonably easy to fix. It's most noticeable with /4
- LV I'm seeing problems with the Recent Pages page not being updated, even if I start a brand new browser. EMJ and other changed pages as well, only clearing the browser cache helps (Firefox and IE). KJN I get the same problem. Holding down the Shift key while clicking the Refresh icon makes the problem go away. This suggests that it is an HTTP header problem: the server must respond correctly to a conditional GET with an If-Modified-Since client header. CMcC what I think is happening is that the in-server cache isn't clearing all pages matching the URL ignoring the host component, but is finding cached versions regardless of host. This means that some cache entries get 'stuck' in the cache (e.g. someone edits via puretcl.com - the recent changes page is cached under that host, it doesn't get invalidated by anything but a puretcl.com edit.) This is a bug.
Revision History
since it isn't listed on the page yet, the revisions link isn't leading to the ability to see revisions yet. what about the wiki history server - is that available? if not, the wikignomes need to have access so we can repair things.CMcC the wikit backend is still storing all the mods, but there's nothing checking them into CVS, nor is there any interface to CVS. It's a temporary situation, but will have to be dealt with eventually because the revision history intermediat storage mechanism is whole-page, and it's going to get out of control eventually.I think, personally, that a metakit (or other) solution based on the tcllib diff/merge list primitives would be better than running off a CVS, although CVS has the advantage of keeping the data in a more tangible form.CMcC would be happy to talk to anyone about the prospects for implementation. LV Feel free to use the TclersWiki mailing list to discuss any issues you wish to discuss. If you'd rather discuss in private email, then perhaps you could post a "call for discussion" on TclersWiki.Non-Problems
- Lars H, cosmetic issue: In page foot of the old Wikit, the page-specific items "Edit" and "Revisions" would appear on one line, while the wiki-global ("The Tcler's Wiki", "About", "Changes", "Search", and "Help") were on another. This was perhaps by accident (the "Edit" used to include the entire page title, so it was fairly long), but I find it harder to spot the link I'm looking for in the new arrangement.
- is there an rss feed for this wiki? No, there isn't. LV Actually, this isn't a non-problem. The wiki used to provide the Recent Changes page as an RSS feed, and there were people subscribed and using that feed. So this could certainly be labelled a low priority issue. Or a "to be considered". Or even a "no longer supported function" (which would be unfortunate). But it isn't a "non-problem". rss now available at wiki.tcl.tk/rss.xml
- LV when I visit the wiki with a GUI browser, there is a blank spot at the bottom of some pages - it looks like perhaps an image that isn't being displayed. I wonder whether that is the object that lynx is getting held up on.
- Wiki Home page not displayed - 'can't reproduce' - works for me.
http://wiki.tcl.tk/2?Q=testand the Search page, with nothing in the search phrase box (and an unlabeled search box at the bottom of the page. Then I did as CMcC suggested, went back to the front page, and did a shift refresh (in Firefox) and now search works as expected.alove Also, when I do a search, go to a page link and then click the "back" button in my browser, I get the error "Page expired". I'm using IE6 on Windows 2000. I imagine this due to caching, which you are working on.CMcC Caching appears to be completely working now.LV What I'm seeing, at least in firefox is the msg "The page you are trying to view contains POSTDATA that has expired from cache. If you resend the data, any action the form carried out (such as a search or online purchase) will be repeated. To resend the data, click OK. Otherwise, click Cancel."CMcC I (fairly arbitrarily) chose to use POST instead of GET for searches. It doesn't make much difference, serverside, in this case. If there's consensus that it be changed back to GET, that can be done.
- AM With Firefox on Linux I sometimes get a timeout message. Here is the scenario: I search for a particular term. Find the page I am interested in and view that. Then some (long?) time later I go back to the page with the search result, Then I get the message. LV Can you provide us the exact worded message you get?
Sundry, Ongoing, TODO
- PT: (minor) missing image wiki-img.gif which is loaded from the CSS as a background.
- Pages seem to be taking a long time to load - depends on load. There are a few spiders prowling around, they've been quarantined, see if it helps
Search should be different from implicit search fixed
In Search field type wikit and redirects to http://wiki.tcl.tk/1 instead of giving search results.CMcC isn't that correct behavior? /1 is a page entitled 'wikit', isn't that the defined behavior of wikit, or am I missing something? Would you like searches via /2 to return something different?Jeff Smith With wikit run under cgi, searches via /2 would display, in the results, all the pages with the search string in the page title. It seems that with WubWikit if the search string matches a specific page title a redirection to that page is happening.Please reconsider this decision. Right now, search is useless because of this behavior. Before, if I wanted to look at what pages had the word graph in them, for instance, I could type graph in the search entry widget and get the list. Now it appears to be impossible to do such a thing. Not only is exact matches doing the mapping, but if I type grap, because there is a page called graph, that is what is displayed, rather than the search results page.CMcC A search via /2 for 'kw' is currently, I believe, precisely the same as a search using /kw. As far as I can see, and by design the behaviour you refer to only occurs when a search term yields precisely one match or when a page title is exactly matched by the search term. I understand you are saying that you would prefer a search via page /2 to always return a search results page, and not to try for exact title match. Is this correct? I seem to recall that this was a feature of the original wikit, and I can see its usefulness. In the meantime, searching for 'kw*' will return a larger set of values.JSI Searching and bookmarking URLs on the Tcl'ers Wiki says ...The following URL is an instruction to look for a page titled "hawaii": http://purl.org/tcl/wiki/hawaii . Assuming there is a page titled "hawaii" (case is ignored), the above URL will lead directly to that page... So if a page named hawaii already exists, then http://wiki.tcl.tk/hawaii should jump to this page and http://wiki.tcl.tk/2?hawaii should find all pages with hawaii in their name.CMcC You're right - thanks for pointing it out and sticking to your guns. Fixed - please test.Jeff Smith seem to be working correctly now :) However another input text box is appearing at the end of each page. Ah! just realised it is a search entry at the end of each page. Very nice!!Proxy Issues
- In Recent Changes the IP Address is displaying the internal private IP Address. Jeff Smith I am behind a firewall and on our internal network we use a private IP addressing scheme as per RFC 1918. In the past when I posted, the outside (Internet side) IP address of the firewall would be displayed in the Recent changes. Now the internal private IP address of my PC is displayed. This could be confusing if you needed to block the IP address for some reason. CMcC Ah, now I get it. So your edit is showing up as like 192.168.1.100 or something. I see the problem - your access is via a proxy, and we're picking up the proxied address. Thanks. fixed
- Polipo 1.0.1 configured with disableVia=false can't access the Tcl Wiki; it fails with "504 Proxy loop detected." Juliusz Chroboczek, author of Polipo, says this is because Wub echoes the client's Via header in the reply. Older versions of Polipo, such as 0.9.9, don't have the disableVia option and always fail. [2] CMcC Yes, it echoed Via because I didn't correctly filter it out of the response dict. Should be fixed now.
Please use http://code.google.com/p/wikitcl/issues/list
to report problems and issues, this will allow us to track them more carefully.
