Forum: Instiki – Topic: installation problems (mac osx lion)

Up and running again… Awesome! Thank you so much

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.)

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.

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.

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.

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 '<top (required)>' 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 '<top (required)>' from ./instiki:6:in 'load' from ./instiki:6:in '<main>' I’m afraid I don’t understand what is going on here. Sorry for my illiteracy, I’m just a devoted Instiki final user …

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.

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!

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

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?

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
 

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.

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.

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.

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.

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.

Forum: Instiki – Topic: Windows installation not working

So any tips on migrating an already running wiki on a different server?

The advantage of SQLite3 is that the entire database is in a single file, db/production.db.sqlite3 … which makes it easy to transfer.

   bundle exec rake upgrade_instiki

will, among other things, perform the necessary database migrations (assuming the previous one is not too old).

Forum: Instiki – Topic: Windows installation not working

I got it working! YIPPIE! I had to do a complete reinstall with a different version of ruby and devkit.

So any tips on migrating an already running wiki on a different server? I see Instiki created a “WEBS” folder which includes a folder with the name of the wiki. Does everything belong in the folder where the name of the file is ie. “ACES” or does it stay in the “WEBS” folder.

Forum: Instiki – Topic: Windows installation not working

Well im writing up simple documentation as i figure things out one at a time. I can send it too you if you want once everything is up and running.

Yes, if i run the command “bundle install –path vendor/bundle” when it gets to the Fetching source index for Rubygems etc on where it reads the gemfile it will always stop on a gem name saying it cannot find the gem gemname <>=version in any of the gem sources listed in your Gemfile.
If i manually type in Gem install gem name it will work. I have a feeling its the syntax or something inside the gemfile. I had to do the same for Rake and itextomml. Which brings me up to another issue i ran into.

Im getting an error when trying to install itextomml… Im wondering if its maybe the version of ruby i have installed or something. Something with the timezone.

(Building native extensions. This could take a while… ERROR: Error installing itextomml: ERROR: Failed to build gem native extension. C:/Ruby187/bin/ruby.exe extconf.rb creating Makefile

make gcc -I. -I/C/Ruby187/lib/ruby/1.8/i386-mingw32 -I/C/Ruby187/lib/ruby/1.8/i386-mingw32 -I. -g -O2 -DFD_SETSIZE=256 -Ditex2MML_CAPTURE -c itex2MML ruby.c In file included from c:/Ruby187/lib/ruby/1.8/i386-mingw32/ruby.h:755:0, from itex2MML_ruby.c:832: c:/Ruby187/lib/ruby/1.8/i386-mingw32/missing.h:29:8: error: redefinition of ‘struct timezone’ In file included from c:/Ruby187/lib/ruby/1.8/i386-mingw32/win32/win32.h:57:0, from c:/Ruby187/lib/ruby/1.8/i386-mingw32/defines.h:186, from c:/Ruby187/lib/ruby/1.8/i386-mingw32/ruby.h:37, from itex2MML_ruby.c:832: c:\rubydevkit\mingw\bin../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/time.h:260:8: note: originally defined here make: *** [itex2MML_ruby.o] Error 1)

Forum: Instiki – Topic: Windows installation not working

Never had so much trouble for something that is supposed to be so simple.. ugh..

Hopefully, you pain will be someone else’s gain, if the Windows installation instructions can be improved, based on your experience.

However looks like every gem listed on the gem file i have to install manually…

I don’t understand.

bundle install –path vendor/bundle

doesn’t install the gems in in the vendor/bundle/ruby/* ?

Or it does install them, but then Instiki can’t find them?

Forum: Instiki – Topic: Windows installation not working

Thanks for the response.. I have installed sqlite3 per your direction and looks like it has passed the sqlite3 portion of the install.. However looks like every gem listed on the gem file i have to install manually including “rake, nokogiri, and itextomml” however im getting errors now with itextomml so that would be a bit to troubleshoot.

Never had so much trouble for something that is supposed to be so simple.. ugh..

Forum: Instiki – Topic: Windows installation not working

The sqlite3 rubygem won’t compile without thelibsqlite3 C-library. (Unlike many rubygems, which are pure Ruby, this one contains a C extension that links to the aforementioned library.)

Windows (unlike other operating systems) doesn’t come with that library installed. Some Ruby installers, for Windows, install it; evidently, some don’t. For those, you’ll have to install it yourself.

If you google around, you’ll find plenty of useful advice on this topic. Unfortunately (since i don’t have any familiarity with Windows), I’m not a useful source for such advice. But, yes, as far as I can tell, installing the Windows SQLite3 package is a prerequisite for getting the sqlite3 rubygem installed.

How does this installation work? What i gather you use “GIT” to download all the packages or i think bundles is the term and then ruby installs them on the system?

Bundler lets you manage/install rubygems, without installing them on the system. Instead, they are installed in your application’s vendor/bundle directory.

But that’s not where (as far as I can tell) your problem lies.

Forum: Instiki – Topic: Windows installation not working

thanks for the reply. I currently have Ruby 1.8.7-p371 installed with the dev kit.

So are you saying i need to download and install that package then attempt to run “ruby bundle install –path vendor/bundle” again?

Im completly new to everything here.. I have aquired this outdated windows server that i had to upgrade to 2008r2. A week ago i just learned what ruby is so you really have to bear with me.

How does this installation work? What i gather you use “GIT” to download all the packages or i think bundles is the term and then ruby installs them on the system? If thats the case, then my problem is when ruby is tries downloading the package from rubygems.org repository as it cant locate sqlite3. Even though i could manually go to the rubygems website and locate sqlite3.

Could i download this manually from rubygems.org and maybe install it?

Forum: Instiki – Topic: Windows installation not working

I don’t know what Ruby installation you have for Windows, but presumably, you are missing the SQLite3 precompiled binaries for Windows.

Presumably, the Windows Installation Instructions could be improved.

Forum: Instiki – Topic: Windows installation not working

I have figured out the above error.. however, now i recieve an error from the gemfile when trying to download the bundles:

D:\instiki-0.19.6>ruby bundle install –path vendor/bundle Updating http://github.com/distler/file_signature.git Updating http://github.com/distler/maruku.git Fetching source index for http://rubygems.org/ Could not reach rubygems repository http://rubygems.org/ Could not find gem ‘sqlite3 (>= 0)’ in any of the gem sources listed in your Gemfi

It cant find sqlite3 in the repository however if i try to modify the gemfile in anyway and give sqlite3 a version number or somthing i receive an syntax error. How should I contruct the gemfile and maybe force it to find the specific version thats in rubygems.org

This is the sqlite portion of the gemfile now:

“source “http://rubygems.org”gem “sqlite3”, :require => “sqlite3”

If i follow the syntax from the other bundles ie.. :require => “sqlite3” , “~> 1.3.7”

Forum: Instiki – Topic: instiki without database?

Maybe You’re right, I’m not a programmer or linux specialist. But I’ve minimum to install the sqlite libraries and perhaps other dependent packages, too. And because of older packages, maybe the need of compiling…

Keep it simple :)

antonio

Forum: Instiki – Topic: instiki without database?

I’m not sure why you think the Madeleine Persistence Layer (which, I believe, is what 0.9.2 uses) is lighter-weight than Sqlite3.

You do need to store the data somewhere. And, with Sqlite3,

• there’s no separate database process
• the data is stored in a single file, db/production.db.sqlite3.

Forum: Instiki – Topic: Feature Requests

Thanks.

Forum: Instiki – Topic: instiki without database?

what a pity; well, version 0.9.2 works ok for my usage.

I’m using a small and older linux installation (puppylinux 4.1.2) on a thin client with CF-Card. I tried some perl-wikis without database and QuickiWiki (the original from Ward Cunningham) but it’s a bit outdated :) . Newer perl-wikis have problems with hiawatha (webserver security) and/or maybe perl 5.8.8. So I give ruby-wikis a try and instiki works nice

antonio

Forum: Instiki – Topic: instiki without database?

No.

You need some database. But the default sqlite3 is as lightweight as humanly possible.