# Recent Posts

412 posts found

 posted 3 years ago xabier 8 posts Forum: Instiki – Topic: Debian installation I’m afraid I need more dumb-proof directions… or maybe I need to convince myself that I shouldn’t be trying this installation without knowing some Ruby basics. posted 3 years ago distler 105 posts Forum: Instiki – Topic: Debian installation Hmm. Well, I’m thinking of ditching mongrel in favour of thin, which is being maintained. You might try changing that line in the Gemfile and seeing if that fixes your error. It would be one more motivation for making the switch. posted 3 years ago xabier 8 posts Forum: Instiki – Topic: Debian installation I’m trying to install Instiki (both current and development versions) on a machine that runs Linux Mint Debian Edition LMDE 201403. This distribution is based on Debian, so I guess I’m running into Debian-based errors too. This is part of the output of the bundling command I get: Installing mongrel (1.2.0.pre2) with native extensions /usr/lib/ruby/1.9.1/rubygems/installer.rb:562:in 'rescue in block in build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError) /usr/bin/ruby1.9.1 extconf.rb checking for main() in -lc... yes creating Makefile make compiling http11.c http11.c: In function ‘http_field’: http11.c:193:3: error: format not a string literal and no format arguments [-Werror=format-security] VALIDATE_MAX_LENGTH(flen, FIELD_NAME); ^ http11.c:194:3: error: format not a string literal and no format arguments [-Werror=format-security] VALIDATE_MAX_LENGTH(vlen, FIELD_VALUE); ^ http11.c: In function ‘request_uri’: http11.c:235:3: error: format not a string literal and no format arguments [-Werror=format-security] VALIDATE_MAX_LENGTH(length, REQUEST_URI); ^ http11.c: In function ‘fragment’: http11.c:246:3: error: format not a string literal and no format arguments [-Werror=format-security] VALIDATE_MAX_LENGTH(length, FRAGMENT); ^ http11.c: In function ‘request_path’: http11.c:257:3: error: format not a string literal and no format arguments [-Werror=format-security] VALIDATE_MAX_LENGTH(length, REQUEST_PATH); ^ http11.c: In function ‘query_string’: http11.c:268:3: error: format not a string literal and no format arguments [-Werror=format-security] VALIDATE_MAX_LENGTH(length, QUERY_STRING); ^ http11.c: In function ‘HttpParser_execute’: http11.c:439:5: error: format not a string literal and no format arguments [-Werror=format-security] VALIDATE_MAX_LENGTH(http_parser_nread(http), HEADER); ^ cc1: some warnings being treated as errors make: *** [http11.o] Error 1 I understand that there are issues with Debian’s Ruby packaging. Or at least there were the last time this webpage was updated, but that was long ago. Any updating on this? Is it a stupid error? Thanks a lot. posted 3 years ago sykstan 3 posts Forum: Instiki – Topic: installation problems (mac osx lion) Thank you for your help, it works now!! Ruby 2.0.0-p353 is the version of Ruby I got, and then everything ran smoothly as promised on the website, in stark contrast to previous attempts. I was even contemplating learning Ruby to try and understand what was going on. As you can probably tell, I have been attacking this problem in my spare time, so the replies are a bit distant in between. posted 3 years ago admin 58 posts Forum: Instiki – Topic: installation problems (mac osx lion) Googling around, that sounds like an antiquated version of RubyGems. If so, gem update --system should fix it. On the other hand, since you have JewelryBox, you could just use it to install Ruby 2.0 or 2.1 (both of which should work with the development version of Instiki), which come pre-installed with a more modern version of RubyGems. posted 3 years ago sykstan 3 posts Forum: Instiki – Topic: installation problems (mac osx lion) Hello, Sorry for getting back so late, only just had time to come back to this. The latest development version does not make a difference, exact same error message. I’ve tried git pull https://github.com/parasew/instiki.git, downloading the tarball linked, and also from the Instiki website. None have worked so far. The ruby bundle install --path vendor/bundle command worked fine, but running ./instiki spits back the above message. Any ideas? posted 3 years ago distler 105 posts edited 3 years ago Forum: Heterotic Beast – Topic: Rails 3.1.0 Heterotic Beast is now a Rails 3.2 application. (There’s an updated acts_as_state_machine gem, among other things which make this transition smooth.) This forum is currently running on Rails 3.2.16. posted 3 years ago distler 105 posts Forum: Instiki – Topic: Ruby 2.0 and 2.1 The current development version of Instiki runs (and the next release will run) just fine on Ruby 2.0 and 2.1. This is important for (among others) MacOSX Mountain Lion users, whose default version of Ruby is 2.0. posted 3 years ago admin 58 posts Forum: Instiki – Topic: Bugs I’m working on updating my branch of Maruku, to incorporate various improvements from trunk. In particular, there are improvements to the table code. So you should check it out… posted 3 years ago Andrew Stacey 118 posts Forum: Instiki – Topic: Bugs There’s a bug with maruku’s table handling: it doesn’t like whitespace at the end of the line (a previous version did, and it would seem to me that whitespace here should be fine). This causes tables that used to render to no longer do so. The fix is to modify the regexp for splitting cells: line 515 of lib/maruku/input/parse_block.rb should read:  if (/^[|].*[|]\s*\$/ =~ s)  (I notice that this isn’t the same as the version of maruku on github, so don’t know if this would be superseded by updating to the latest version from there.) posted 3 years ago admin 58 posts Forum: Instiki – Topic: installation problems (mac osx lion) You need the latest development version ( .tar.gz, bzr or git). posted 3 years ago sykstan 3 posts Forum: Instiki – Topic: installation problems (mac osx lion) Hello there, I’m having the same problem with my installation. The default Ruby that came with my iMac is 1.8.7, but the gem nokogiri needed >=1.9.2, so I got Ruby 1.9.3p484 using JewelryBox. This time the bundler installed, but running ./instiki comes back with  /Users/tans/Downloads/instiki/vendor/rails/railties/lib/rails/gem_dependency.rb:21:in add_frozen_gem_path’: undefined method source_index' for Gem:Module (NoMethodError) from /Users/tans/Downloads/instiki/config/boot.rb:62:in load_initializer’ from /Users/tans/Downloads/instiki/config/boot.rb:126:in run' from /Users/tans/Downloads/instiki/config/boot.rb:26:in boot!’ from /Users/tans/Downloads/instiki/config/boot.rb:139:in ' from /Users/tans/.rvm/rubies/ruby-1.9.3-p484/lib/ruby/site_ruby/1.9.1/rubygems/core_ext/kernel_require.rb:55:in require’ from /Users/tans/.rvm/rubies/ruby-1.9.3-p484/lib/ruby/site_ruby/1.9.1/rubygems/core_ext/kernel_require.rb:55:in require' from /Users/tans/Downloads/instiki/script/server:3:in ' from ./instiki:6:in load' from ./instiki:6:in
' 
How did you manage to get it up and running? Thank you. posted almost 4 years ago admin 58 posts Forum: Instiki – Topic: Windows 8 and Instiki posted almost 4 years ago slym 1 post Forum: Instiki – Topic: Windows 8 and Instiki I followed the instructions given on the instiki.org and this is what I get: C:\instiki-0.19.6>ruby instiki C:/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/source. rb:571:in load_spec_files': http://github.com/distler/file_signature.git (at ma ster) is not checked out. Please run bundle install (Bundler::GitError) from C:/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bu ndler/source.rb:385:in local_specs’ from C:/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bu ndler/source.rb:554:in specs' from C:/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bu ndler/definition.rb:356:in converge_locked_specs’ from C:/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bu ndler/definition.rb:345:in each' from C:/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bu ndler/definition.rb:345:in converge_locked_specs’ from C:/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bu ndler/definition.rb:143:in resolve' from C:/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bu ndler/definition.rb:90:in specs’ from C:/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bu ndler/definition.rb:135:in specs_for' from C:/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bu ndler/definition.rb:124:in requested_specs’ from C:/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bu ndler/environment.rb:23:in requested_specs' from C:/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bu ndler/runtime.rb:11:in setup’ from C:/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bu ndler.rb:107:in setup' from ./config/../config/preinitializer.rb:18 from ./config/boot.rb:28:in load’ from ./config/boot.rb:28:in preinitialize' from ./config/boot.rb:10:in boot!’ from ./config/boot.rb:124 from ./script/server:3:in require' from ./script/server:3 from instiki:6:in load’ from instiki:6 I tried different versions of Ruby but with no success. Please help! posted almost 4 years ago xabier 8 posts Forum: Instiki – Topic: installation problems (mac osx lion) Up and running again… Awesome! Thank you so much posted almost 4 years ago distler 105 posts edited almost 4 years ago Forum: Instiki – Topic: installation problems (mac osx lion) Well, that was fun… I think I have instiki now running successfully on Ruby 1.8.7 Ruby 1.9.3 Ruby 2.0.0 It was quite a juggling act getting it to work on all three. But I think I’ve succeeded. Let me know if you encounter further problems. (In an attempt to eat my own dogfood, I have switched this forum and the copy of Instiki running on Golem, to run under Ruby 2.0.0.) posted almost 4 years ago xabier 8 posts Forum: Instiki – Topic: installation problems (mac osx lion) In this case the bundle gets installed (…). But when I tried to run instiki I got this: /Users/Xabier/Documents/Trabajo/Investigacion/instiki-svn/vendor/rails/railties/lib/rails/gem_dependency.rb:21:in ‘add_frozen_gem_path’: undefined method ‘source_index’ for Gem:Module (NoMethodError)… I’m running into the same error with Ruby 1.9.3-p448 and the development version of instiki. posted almost 4 years ago xabier 8 posts edited almost 4 years ago Forum: Instiki – Topic: installation problems (mac osx lion) Please try again. I did! That output is from a few hours ago :) I’ll try with 1.9.x and post the results. posted almost 4 years ago distler 105 posts edited almost 4 years ago Forum: Instiki – Topic: installation problems (mac osx lion) I actually had tried the development version, too… Please try again. The relevant feature of the development version is that it changes. (only I was prompted to update Ruby when I first tried to run the bundler; which I did; my current version is 2.0.0) Oh! I haven’t tested Instiki on Ruby 2.0. Works fine on 1.9.x, but there may be issues with 2.0. posted almost 4 years ago xabier 8 posts Forum: Instiki – Topic: installation problems (mac osx lion) Thank you Jacques! I actually had tried the development version, too, but I didn’t remember the outcome -only that it didn’t work either. In this case the bundle gets installed (only I was prompted to update Ruby when I first tried to run the bundler; which I did; my current version is 2.0.0). But when I tried to run instiki I got this: /Users/Xabier/Documents/Trabajo/Investigacion/instiki-svn/vendor/rails/railties/lib/rails/gem_dependency.rb:21:in 'add_frozen_gem_path': undefined method 'source_index' for Gem:Module (NoMethodError) from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-svn/config/boot.rb:47:in 'load_initializer' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-svn/config/boot.rb:111:in 'run' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-svn/config/boot.rb:11:in 'boot!' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-svn/config/boot.rb:124:in '' from /Users/Xabier/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/site_ruby/2.0.0/rubygems/core_ext/kernel_require.rb:51:in 'require' from /Users/Xabier/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/site_ruby/2.0.0/rubygems/core_ext/kernel_require.rb:51:in 'require' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-svn/script/server:3:in '' from ./instiki:6:in 'load' from ./instiki:6:in '
' I’m afraid I don’t understand what is going on here. Sorry for my illiteracy, I’m just a devoted Instiki final user … posted almost 4 years ago distler 105 posts Forum: Instiki – Topic: installation problems (mac osx lion) Thanks for the bug report. The latest development version ( .tar.gz, bzr or git) should fix this problem. posted almost 4 years ago xabier 8 posts edited almost 4 years ago Forum: Instiki – Topic: installation problems (mac osx lion) Hi, I’m running into problems when trying to install Instiki on my Mac (OS X Lion). Ruby version seems to be 1.8.7. A previous version of Instiki (I think it was 0.19.4) worked fine. This problem appeared when I re-installed the developer tools from the App Store, but this might as well be a coincidence. I’m trying the three last versions and in every case I get this output when I try to run ruby bundle install --path vendor bundle: Fetching http://github.com/distler/file_signature.git remote: Counting objects: 339, done. remote: Compressing objects: 100% (241/241), done. remote: Total 339 (delta 128), reused 279 (delta 68) Receiving objects: 100% (339/339), 218.79 KiB | 289 KiB/s, done. Resolving deltas: 100% (128/128), done. Fetching http://github.com/distler/maruku.git remote: Counting objects: 6916, done. remote: Compressing objects: 100% (3505/3505), done. remote: Total 6916 (delta 3472), reused 6758 (delta 3331) Receiving objects: 100% (6916/6916), 2.37 MiB | 330 KiB/s, done. Resolving deltas: 100% (3472/3472), done. Fetching source index for http://rubygems.org/ /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/source.rb:253:in ‘fetch_all_remote_specs’: undefined method ‘list’ for #Gem::SpecFetcher:0x10dff3b98 (NoMethodError) from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/source.rb:234:in 'remote_specs' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/source.rb:231:in 'each' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/source.rb:231:in 'remote_specs' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/source.rb:165:in 'fetch_specs' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/source.rb:70:in 'specs' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/definition.rb:159:in 'index' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/definition.rb:158:in 'each' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/definition.rb:158:in 'index' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/index.rb:7:in 'build' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/definition.rb:157:in 'index' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/definition.rb:151:in 'resolve' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/definition.rb:90:in 'specs' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/definition.rb:85:in 'resolve_remotely!' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/installer.rb:43:in 'run' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/installer.rb:8:in 'install' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/cli.rb:220:in 'install' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/vendor/thor/task.rb:22:in 'send' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/vendor/thor/task.rb:22:in 'run' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/vendor/thor/invocation.rb:118:in 'invoke_task' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/vendor/thor.rb:263:in 'dispatch' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/lib/bundler/vendor/thor/base.rb:386:in 'start' from /Users/Xabier/Documents/Trabajo/Investigacion/instiki-0.19.6/vendor/plugins/bundler/gems/bundler-1.0.18/bin/bundle:13 from bundle:21:in 'load' from bundle:21 Any ideas? Many thanks! posted 4 years ago Andrew Stacey 118 posts Forum: Instiki – Topic: Bugs With the above changes, then expire_caches triggers an error when renaming a page. I think it is due to expiring pages that redirect to the given page. This is called in expire_caches in after_save. If the page name has changed, then the function self.pages_redirected_to in wiki_references.rb is called with the old name but that no longer exists in the database. So the page = web.page(page_name) returns null. I’ve put in a conditional to test for this which at least removes the error but I don’t know if there are some caches that aren’t now being expired that ought to be - I’ll check the logs to trace this.  def self.pages_redirected_to(web, page_name) names = [] redirected_pages = [] if web.has_page?(page_name) page = web.page(page_name) redirected_pages.concat page.redirects redirected_pages.concat Thread.current[:page_redirects][page] if Thread.current[:page_redirects] && Thread.current[:page_redirects][page] end redirected_pages.uniq.each { |name| names.concat self.pages_that_reference(web, name) } names.uniq end  posted 4 years ago Andrew Stacey 118 posts Forum: Instiki – Topic: Bugs I’ve put those changes in place and will keep an eye on what happens. Incidentally, when manually clearing out the cache I note that / in page names gets translated into subfolders. So a page name Sandbox/Set creates a folder Sandbox with a file Set.cache. Should the page name be completely sanitised under such circumstances? posted 4 years ago distler 105 posts Forum: Instiki – Topic: Bugs Since I’ve not had much success reproducing your bug, why don’t we see whether implementing your suggestion fixes it for you? Apply the following patch:  === modified file 'app/controllers/revision_sweeper.rb' --- app/controllers/revision_sweeper.rb 2011-09-21 04:46:36 +0000 +++ app/controllers/revision_sweeper.rb 2013-05-30 05:11:33 +0000 @@ -7,15 +7,15 @@ observe Revision, Page def before_save(record) - if record.is_a?(Revision) - expire_cached_page(record.page.web, record.page.name) - expire_cached_revisions(record.page) + if record.is_a?(Page) + expire_cached_page(record.web, record.name) + expire_cached_revisions(record) end end def after_save(record) - if record.is_a?(Revision) - expire_caches(record.page) + if record.is_a?(Page) + expire_caches(record) end end  posted 4 years ago Andrew Stacey 118 posts Forum: Instiki – Topic: Bugs Spoke too soon. The cache bug is not dead. I shoved in a load of logger.info statements to the revise method of page.rb and to the before_save and after_save methods of revision_sweeper.rb to see what was happening. I noticed that the cache sweep only happens when a revision is saved, not when a page is saved. At least, that’s how I interpret the if record.is_a?(Revision) conditional. Anyway, what I found was interesting. I got different behaviour depending on whether I was creating a new revision or updating an old one (to switch between the two I used two author strings). Here’s the “same author” sequence of events:  Processing WikiController#edit (for 127.0.0.1 at 2013-05-29 21:56:25) [GET] Cache Bug Log: Before save page called for previous name. Cache Bug Log: After save page called for previous name. Processing WikiController#save (for 127.0.0.1 at 2013-05-29 21:56:32) [POST] Cache Bug Log: Renaming 'previous name' to 'current name'. Cache Bug Log: Updating previous revision. Cache Bug Log: Before save revision called for previous name. Cache Bug Log: After save revision called for previous name. Cache Bug Log: Saving new page. Cache Bug Log: Before save page called for current name. Cache Bug Log: After save page called for current name. Cache Bug Log: Before save page called for previous name. Cache Bug Log: After save page called for previous name. Processing WikiController#show (for 127.0.0.1 at 2013-05-29 21:56:33) [GET]  As I said above, only the Before save revision and After save revision actually seem to do any cache sweeping. So in this sequence, the previous name and only the previous name gets swept. This is okay, but not optimal: if there is a stale cache file then renaming a page to the name of a stale file means that the stale file doesn’t get swept (I checked this). But here’s what happens when I change the author name to force a new revision:  Processing WikiController#edit (for 127.0.0.1 at 2013-05-29 21:57:34) [GET] Cache Bug Log: Before save page called for previous name. Cache Bug Log: After save page called for previous name. Processing WikiController#save (for 127.0.0.1 at 2013-05-29 21:57:45) [POST] Cache Bug Log: Renaming 'previous name' to 'current name'. Cache Bug Log: Creating new revision. Cache Bug Log: Saving new page. Cache Bug Log: Before save page called for current name. Cache Bug Log: Before save revision called for current name. Cache Bug Log: After save revision called for current name. Cache Bug Log: After save page called for current name. Cache Bug Log: Before save page called for previous name. Cache Bug Log: After save page called for previous name. Processing WikiController#show (for 127.0.0.1 at 2013-05-29 21:57:45) [GET]  Notice that the Saving new page message now occurs before the save revision steps. The Saving new page message was inserted just before the save statement in the revise method. So this ought to happen after the new revision is created. However, it would appear that the new revision is not actually saved until the page is saved. With this sequence then the before_save and after_save functions for the revision are called with the current name meaning that the old name does not get swept. This is “the cache bug”. Looking at the two different sequences of events, it would seem that the safest place to sweep the cache is when before_save is called when saving a page, not a revision. Moreover, as the before_save and after_save are always called with the same page name then it seems overkill to put the sweep in both. Of course, my analysis may well be incorrect as instiki (well, ruby-on-rails) is very much a black box to me so I have no idea as to what’s going on under the bonnet. Incidentally, the above was carried out using sqlite as the database, but I got the same results with mysql with the updated gem. posted 4 years ago distler 105 posts Forum: Instiki – Topic: Bugs I put 2.9.1 in the Gemfile but I don’t know if that’s the minimum value. Might as well assume that 2.9.1 is the minimum (since we know that it works). I updated the instructions accordingly. Interestingly, bundle won’t update to the latest version unless you specify such a minimum. Correct. If you don’t specify a version, then any version is supposed to suffice. posted 4 years ago Andrew Stacey 118 posts Forum: Instiki – Topic: Bugs I put 2.9.1 in the Gemfile but I don’t know if that’s the minimum value. Interestingly, bundle won’t update to the latest version unless you specify such a minimum. Comparing the logs, then it would appear that something in the mysql module was returning the updated page name when instiki was expecting the old page name, so when instiki swept the cache using what it thought was the old page name, it was actually using the new one and thus the old cache page wasn’t being deleted. posted 4 years ago distler 105 posts Forum: Instiki – Topic: Bugs Poking around, I discovered that my fresh install was using version 2.9.1 of the mysql gem but the live installs were using 2.8.1. If there’s a minimum version number for the gem that we should be using (no version number is currently specified), then that would be good to know, so that the Gemfile` can be updated, accordingly. Curious, though, that this “cache bug” of yours would seem to have nothing to do with … caching. posted 4 years ago Andrew Stacey 118 posts Forum: Instiki – Topic: Bugs I think I’ve killed the cache bug! I did a fresh install of Instiki+MySQL on a debian virtual machine and … no cache bug. So I went back to my live installs and … cache bug. Poking around, I discovered that my fresh install was using version 2.9.1 of the mysql gem but the live installs were using 2.8.1. So, on a hunch, I updated to 2.9.1 and tried reproducing the cache bug … and it had gone. I don’t know if I’ve well and truly killed it, but the steps I put above were reliably showing it for me on the nlab and on mathsnotes and now that I’ve updated the mysql gem then those steps no longer exhibit it so I figure that’s enough for a small celebration.