08:33 <stellar-slack> <yaseenhamdulay> bartek: do you have any idea why horizon “rake db:migrate” would do this?

08:34 <stellar-slack> <yaseenhamdulay> == 20150310224849 CreateHistoryLedgers: migrating ============================= -- create_table(:history_ledgers) rake aborted! StandardError: An error has occurred, this and all later migrations canceled: nil is not a symbol/var/lib/gems/1.9.1/gems/memoist-0.12.0/lib/memoist.rb:102:in `alias_method'

09:02 <stellar-slack> <smn> jed: how close to production ready is the horizon stuff? yaseenhamdulay's interning with us at Praekelt Foundation and running into a bunch of code that's marked as being very early stage in various readme's. Are there any specific libs we should be focussing on that are more ready than others?

10:15 <stellar-slack> <bartek> @yaseenhamdulay @smn are you using ruby horizon or go-horizon (https://github.com/stellar/go-horizon)? I think @scott’s focus now is on go-horizon so you should try this one. I’m not working on this project but afaik, the main reason for switching to go were performance issues with SSE in ruby.

10:22 <stellar-slack> <smn> ah thanks bartek

10:22 <stellar-slack> <smn> bartek, out of interest, what timezone are you in?

10:22 <stellar-slack> <bartek> I’m in Europe :)

10:23 <stellar-slack> <smn> ah! :)

10:23 <stellar-slack> <bartek> :)

12:54 <stellar-slack> <yaseenhamdulay> how long should ledger catchup take on stellar-core?

14:55 <stellar-slack> <scott> @yaseenhamdulay: horizon (the ruby version) is only tested and confirmed compatible with ruby 2.1.5 and ruby 2.2. Looking at that error message you’re on 1.9.1

14:56 <stellar-slack> <scott> @monsieurnicolas or @graydon would be able to better answer your question regarding catchup time on stellar-core

15:10 <stellar-slack> <jed> catchup can take 5 min or so

15:14 <stellar-slack> <yaseenhamdulay> thanks guys

15:17 <stellar-slack> <jed> yaseenhamdulay: you can see the progress of the catchup if you tail the log

19:14 <stellar-slack> <graydon> yeah it tries to give an ETA; basically this takes a while because the catching-up node has to wait until the next regularly published history block checkpoint. just to keep the protocol simple and have only one code path, we use the long-term history archive blocks as our online catching-up mechanism as well.

19:15 <stellar-slack> <graydon> it's not doing anything much during that time, just waiting until the next publish event (and buffering any network activity that happens in the meantime, to replay)