2006-11-10
KBK is attempting to edit this page by deleting all text and then reconstructing it in bits, because there appears to be a Wikit bug preventing changes to it.
Please don't mess with it until this message is removed.
Suspicion arises that the following problem has recurred.
Lars H, 25 Nov 2004: The Tcl'ers page has been spammed, and I don't seem to be able to restore the previous contents. I did report the spammer on chongqed.org, though.
Lars H, 22 Dec 2004: Another "not being able to save contents" problem with a particular page. This time page 12559 (Wiki Spamming), shortly before [clock format 1103726997]. Pressing the "Save" button, I get a page claiming "Page saved", but apparently my changes haven't been saved, because the page is exactly the same after I reload it. I also tried editing from another browser, but that made no change: It's claimed the changes were saved, and they were not.
[Wiki Fire Brigade]
On this page: Things that don't work as expected in this Wikit implementation
LV This is more of a warning about people using the wikit than the wikit software having problems itself. I discovered this week that the lynx text web browser is at least one web browser which does not handle unicode properly. It is 8 bit safe; but not unicode safe. Thus, when a lynx user edits wiki pages with unicode on the page, it is likely to damage the page. I don't know about other browsers like Mozilla, Firefox, Opera, Netscape, Safari, or Internet Explorer.
Lars H: Now (27 April 2005) you notice? If you're speaking of the slight distorsion of just about anything non-ASCII that you (AFAICT from having read WikiDiff) have been causing these last months, then the problem has been observed several times before. I've made at least one comment about it below.
Whether "8 bit safe; but not unicode safe" is a proper description of it is another matter. The sequence of bytes sent back and forth indeed seems to be preserved as it should, but what is lost is information about the encoding. It goes out UTF-8-encoded, but when it comes back it is for some reason interpreted as being latin1-encoded, and that is all that went wrong. (It is usually possible to ungarble Wiki page contents by subjecting them to a [encoding convertfrom utf-8].) What should be examined by someone who has access to one of these faulty browsers is however whether the problem is that the browser sticks an incorrect encoding header on the data, or whether it is Wikit that in the absence of an encoding specification defaults to the wrong encoding.
LV I didn't say I just noticed the problem - I said I just discovered that lynx is one of the problems. Before this week, I was under the (now known to be mistaken) believe that because lynx was 8 bit safe, that made it unicode safe. I now know that is wrong. What I still don't know is how many browsers have the same problem. I know that old versions of Netscape has problems with long lines, as does lynx. I don't know what similar problems Mozilla, Firefox, IE, Safari, etc. introduce.
LES on April 23, 2005: I was looking for the K combinator and tried to access http://mini.net/tcl/K (or [L1 ]), but wikit tells me that "This is not a valid URL for this site". Why?
Derek Peschel Good question, but I've been seeing the same problem on the 27th, when I was trying to merge two versions of a page. I was trying to search for links to the not-yet-merged page too.
How much state about my session does Wikit keep, either on the server or in cookies? If I knew that, it might be easier to understand why certain things happen.
LV April 12, 2005 For some reason, the wiki URL searching doesn't seem to be working. I am using
http://wiki.tcl.tk/ProperIntegers
which should take me to a wiki page selection web page. Instead, it tells me that the term isn't found. However, if I go to search and type in Proper Integers, then I get the pages sought.
MG If you enter ProperIntegers in the search field (without the space, as you did it on the URL), it doesn't find anything, either. Try using one of these
http://wiki.tcl.tk/Proper+Integers http://wiki.tcl.tk/Proper%20Integers http://wiki.tcl.tk/Proper Integers (if you're not using an old browser that won't translate the space)
LV However, my notation is the documented manner (see Searching and bookmarking URLs on the Tcl'ers Wiki) by which the search urls should work - and in fact, some search terms do work properly that way. However, the search box was never intended to work that way. One of the little pecularities of this Wikit.
However, thank you for the other methods of notation - I was able to use one of those to get things to work for me in the short term. I just hope the bug that this phrase exhibits can be fixed.
PJR April 11, 2005
I just downloaded wikit and there seems to be an error in:
wikit.vfs/lib/wikit/image.tcl
line 9 has:
export LocalImages
instead of:
namespace export LocalImages
NJG March 25, 2005
On January 5th I placed a request on the Tcl'ers page concerning the handling of accented characters. A couple of days ago I noticed that an even more extensive damage had been done, now the title of my personal page had been busted as well. It seems as if some houskeeping program read in the wiki conent as if it were in some 8-bit character set (e.g. Windows-1250/52) and then wrote it back as UTF-8.
CLN 2005-02-23 Why are half the items in today's Recent Changes not links?
SEH --I just wrapped a wikit starpack using the latest tclkit for linux-x86. I dropped it into my web server's home directory (/home/www-admin) and gave it executable permissions. I wrote a short script called wikit.cgi for the cgi-bin directory:
#!/usr/bin/env sh exec /home/www-admin/wikit
and tried going to: localhost/cgi-bin/wikit.cgi/
After a long pause I got a 500 error and the error log said: "can't lock: wikit.lock"
I double-checked permissions, and another script in the cgi-bin folder writes to this same directory, so it doesn't seem to be a server config problem or permissions problem. Any ideas?
SEH 2005/02/16 -- Today I downloaded the starpack wikit.exe from the sdarchive and dropped it into the cgi-bin folder of my apache server on Windows 2000. I went to localhost/cgi-bin/wikit.exe/, but nothing happened except a small window popped up resembling the kind of window that appears when you do "package require Tk" in a console. When I closed that window the browser finally returned with the "My Wiki" page. Every time I click on a link the GUI window re-appears, and the call to wikit.exe doesn't return with the expected page in the browser until I manually close the window. What's up?
JSI 16feb05 The Wikit.exe from sdarchive is created using tclkit.exe, which contains TK for Wikit in local mode. For WiKit under CGI tclkitsh.exe (without TK) is the better choice. You can create your own starpack using SDX.KIT and tclkitsh.exe and wikit.kit. For example:
tclkit.exe sdx.kit unwrap wikit.kit tclkit.exe sdx.kit wrap wikit.exe -runtime tclkitsh.exe ren wikit.exe wikitsh.exe dir wi*.exe: 16.02.2005 21:05 1.199.025 wikitsh.exe
If you don't need to use Apache (for CSS or .HTACCESS or such), then simply use the embedded webserver: "wikit.exe -httpd 8081" and navigate to http://localhost:8081 . For further details search the Wiki or drop a note here.
SEH -- Thanks for the help, but wouldn't it be infinitely preferable for wikit.exe simply not to load Tk if it detects the presence of env(SCRIPT_NAME) and so goes into CGI mode? Then wikit would work regardless of which tclkit was used to wrap it, and newbies like me could get to work immediately instead of having to go through a cycle of asking for assistance.
Investigating and verifying which flavor of tclkit was used to create a starpack is pretty fine work for a product that's supposed to require zero configuration. It should Just Work, regardless.
jcw - I don't know who wrapped wikit.exe, so I can't comment on their choice. The issue is not Tclkit's fault, but Redmond's: in Windows, it's not possible to launch a command-line tclkitsh.exe and make it become a GUI as in Unix - the exe has a flag which tells the loader whether it's a DOS-box style app or whether it's a GUI app (which does not work conveniently from the command line).
The current wikit.exe was no doubt created for local mode GUI-based use, someone would just need to create and upload a wikitsh.exe to simplify the server/CGI case... OTOH, it's a simple case of starkit/starpack wrapping - is it really a good idea to manage lots of binaries when the wrap process for starkits is so straightforward?
BTW, you could also get tclkitsh.exe, get wikit.kit, and write a little batch file to launch one with the other.
SEH -- I just downloaded a fresh tclkitsh.exe and wikit.kit, then unwrapped and wrapped it roughly as instructed at http://www.equi4.com/259 , i.e. in my case the wrap command was: "tclkitsh.exe sdk.kit wrap wikit.exe". I got the error message "file in use, cannot be prefix: tclkitsh.exe". From this I gather that the runtime running the wrapping process can't be the one provided as the runtime included in the starpack.
I copied tclkitsh.exe to the above directory, then tried "tclkitsh.exe sdk.kit wrap wikit.exe -runtime ../tclkitsh.exe" and got a wikit.exe and a wikit.bat.
I tried to go to localhost/cgi-bin/wikit.bat/, but got an internal server error message. I opened it up and saw:
@tclkit wikit.exe %1 %2 %3 %4 %5 %6 %7 %8 %9
Two problems suggest themselves: first, tclkit is perversely used instead of tclkitsh, thus tempting return of the original window popup problem. Second, wikit.exe is called instead of wikit.kit as expected.
I tried "tclkit wikit.exe" on a command line just to see if this could work, and in fact it didn't, I got an error message. Same with "tclkitsh wikit.exe".
I changed wikit.bat to read:
@tclkitsh wikit.kit %1 %2 %3 %4 %5 %6 %7 %8 %9
and went to localhost/cgi-bin/wikit.bat/ again, and I got to the My Wiki intro page.
I then deleted wikit.tkd and tried simply localhost/cgi-bin/wikit.exe/, and at last successfully got to my zero-configuration Wikit CGI page.
JSI 17feb05 Congratulations, no kidding. Hint One: Don't delete wikit.tkd, this file contains the wiki-pages (->your work). It is automatically created with initial content on first startup. "Don't try this at home": Edit or create some pages, then delete the wikit.tkd and then revisit your Wikit: All your work is gone. Hint Two: The original wikit.exe from sdarchive can do two things, which are not possible via CGI: Rename pages and edit ALL of the first nine pages, some of them are readonly via CGI.
JSI 13feb05 IMO this page here could/should be shorter. Some entries are quite ancient. Should we for example refactor solved problems to some sort of Wikit-FAQ or split it into separate pages "Wikit Problems 1999", "Wikit Problems 2000", "Wikit Problems 2001",...?
jcw - I'm all for it. Feel free split and re-org further.
Lars H, 25 Nov 2004: The Tcl'ers page has been spammed, and I don't seem to be able to restore the previous contents. I did report the spammer on chongqed.org, though.
Lars H, 22 Dec 2004: Another "not being able to save contents" problem with a particular page. This time page 12559 (Wiki Spamming), shortly before [clock format 1103726997]. Pressing the "Save" button, I get a page claiming "Page saved", but apparently my changes haven't been saved, because the page is exactly the same after I reload it. I also tried editing from another browser, but that made no change: It's claimed the changes were saved, and they were not.
RHS 23Nov2004 There seems to be an issue when html links are placed inside preformed text. For example, the following:
<a href="http://a.site.net/apage">UhOh</a>
It shows up with an actual link labelled UhOh, whereas it should not. I'm not sure how to actually display that text without running into an error, but look at the source for the page to see that its just a normal href.
LES 24Nov2004 If you don't mind my piggybacking on your report, I also found some trouble creating char2ent because the XML numeric codes for special characters are rendered as the characters when the page is displayed. I did some experimenting and tried to escape this or that character, but could not achieve what I wanted. That is bad because if you copy and paste the code off the wiki, it won't work.
LES on June 4, 2004: I wonder why wikit no longer displays accented characters correctly: [L2 ]. It used to.
jcw - I'm afraid I messed up badly, and I apologize for that. Reinhard Max has helped figure this out recently, and we came to the conclusion that in one of my batch jobs (rename or re-pack) I must have copied pages with incorrect encodings set. As a result about two dozen pages appear to have been damaged. We started fixing it for about a dozen pages - and AFAIK everything changed from now on should be correct. The only remaining problem is when browsers mess up in an edit, but such edits can be reverted if needed.
Several pages - including 9453 - are very hard for me to fix because I don't know their languages. Please fix where you can (and if there is any regression from now on, send me a very scornful email).
LES Not the end of the world. That's what we deserve for relying on computers. I recorded my editing in UltraEdit and came up with this macro:
InsertMode ColumnModeOff HexOff UnixReOff Find "��¢" Replace All "â" Find "��©" Replace All "é" Find "����" Replace All "í" Find "��£" Replace All "ã" Find "��§" Replace All "ç" Find "��µ" Replace All "õ" Find "��º" Replace All "ú" Find "��¡" Replace All "á" Find "��³" Replace All "ó" Find "�� " Replace All "à" Find "��¼" Replace All "ü" Find "��ª" Replace All "ê" Find "â?¦" Replace All "..."
Maybe it can be reused in other pages. Of course there is a "right way" to do it, but I have to confess my ignorance about encoding manipulation. Maybe, someday...
Lars H: For the record, the most common case of browsers messing up the encoding seems to consist of mistaking UTF-8 for latin1. One example of this can be found in http://mini.net/tclrevs/3283-27-26 where each byte of a UTF-8 character has been mistaken for a separate latin1 character. (It doesn't exactly help that WikiDiff/tclrevs also do this display error, though. Not to mention that it makes it hard to copy back the old contents.)
The big issue is of course how to detect that something is an encoding error in the browser and not deliberate editing (e.g. fixing previous encoding errors). One way might be to have a known string containing non-ASCII characters that the browser is supposed to send back, because then it would be possible to see whether something was garbled. As I recall it, Wikit is already sending some fixed strings (e.g. a time stamp) with each edited page that has to be sent back as it were (or else the edit is rejected). Perhaps something similar could be done to check that all characters used on the page would have survived the trip?