Something is rotten in the state of my wiki. The Ruby upgrade wasn't the panacea after all, although most pages are trouble-free now indeed. Some pages however still may go beserk at an unpredictable moment: weird error messages at submitting, and the subsequent memory leak. A quantum effect? Worn-out bits?
After many experiments with a troublesome page, I'm getting to suspect Textile-tables containing WikiWords. When WikiWords (actually their square brackets) are removed, or when Textile table-formatting is replaced by pure HTML (preserving all WikiWords), there never seems to come an end at the error-free updating of that page. Here is the problematic one: [myPage] table(in). |(nn). Volledige naam |(nn). : |(n). Bxxxxxxxxxxxxx Axxxxxxxxx (xx-xxxxxxxxxx) | |(nn). Klantgroep |(nn). : |(n). *X* | |(nn). AS/IS-code |(nn). : |(n). *XX* | |(nn). Productie-omgeving |(nn). : |(n). *X* op mainframe XXXX | |(nn). Beheercluster |(nn). : |(n). [[Cluster 1]], [[Cluster 2]] (Fxxx Xxxxx xx Xxx; Fxxx Xxxx Xxxxxxxxxx), [[Cluster 3]], [[Cluster 6]] | |(nn). Applicatiebeheer |(nn). : |(n). [[Meindert Meindertsma]] | |(nn). Techniek |(nn). : |(n). [[SAS]], [[JCL]], [[OPC]] | The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. Iteratie 1: anonimiseren. Iteratie 2. Iteratie 3. Iteratie 4. Iteratie 5. Iteratie 6. Iteratie 7. Iteratie 8. Iteratie 9. Iteratie 10. Iteratie 11 geeft: undefined method `to_sym' for nil:NilClass. [/myPage] Sorry for the Dutch frases, but you get the idea. The first iteration consisted of creating a new page, pasting text from another page and covering parts of it with x-s and a little story about a jumping fox. All next updates I did no more than adding a line "Iteratie 2." and so on. I don't have to present the HTML version, do I? I assure you it looks awful, because the whole table must be written on one logical line, without any hard returns between or inside the tags (Markdown would do a better job here, I presume). O well, there is trick: a linebreak at the end of (and within!) each table cell is harmless, but still not making a great layout in the edit page. By the way: is it safe to put HTML tags into this mail -- what if it's read through a web browser? That's why I'm a bit cautious when dealing with HMTL. Could my assumption that Textile-tables and WikiWords don't go together be true? Has anyone similar, supplemental or contrary experiences? This could be a reason to switch to Markdown, but I want to be sure before taking such a drastic step. Meindert Meindertsma. Quoting Meindert Meindertsma <[EMAIL PROTECTED]>: > John, and others, > > After 32 iterations: I give up, this Ruby version is too strong for > me, how healthy its > internal state! > > The new package also reports "ruby 1.8.4 (2005-12-24) [i386-mswin32]", > so I have to be > more precise: "1.8.4-16 preview 3" was behaving badly, the just > installed "1.8.4-17 > release candidate 2" works fine, until now. A first impression of > course, but I'm rather > confident at this moment. > > Thanks, > Meindert Meindertsma. > > Quoting John Whitley <[EMAIL PROTECTED]>: > >> [EMAIL PROTECTED] wrote: >>> Instiki takes frequent revisions of the same page by the same author >>> within a short time as multiple iterations of the same version, not as >>> separate versions. Nice feature. But after a few iterations, my >>> Instiki can't handle it anymore, and I'm getting error messages like >>> "private method `split' called for 113435111:Fixnum", "private method >>> `gsub!' called for 101855024:Fixnum", or "undefined method `+' for >>> nil:NilClass", after submitting the updated text. >> >> Ah, *that* I've seen before: it was due to a hand-built Ruby on Mac >> OS X with incorrect threading compile options. This caused Ruby's >> internal state to get completely screwed up for some (but not all) >> applications. A correctly built Ruby interpreter resolved those >> nnnn:Fixmnum problems and related bizarre issues entirely. >> >> If you're using a pure-Windows (i.e. not Cygwin) Ruby, you might want >> to check out the RubyInstaller (http://rubyinstaller.rubyforge.org/ >> wiki/wiki.pl) page for a one-click Ruby installer package for >> Windows. See if the most recent package (1.8.4-17 release candidate >> 2, built on May 3, 2006) works any better for you. >> >>> I'm using Instiki 0.11.0 and Ruby 1.8.4 [2005-12-24] on Windows 2000 >>> or XP. >> >> >> -- John >> >> >> _______________________________________________ >> Instiki-users mailing list >> [email protected] >> http://rubyforge.org/mailman/listinfo/instiki-users >> > > > > _______________________________________________ > Instiki-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/instiki-users > _______________________________________________ Instiki-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/instiki-users
