Here's the error I'm hitting
NoMethodError: undefined method `group' for Sunspot::Search::StandardSearch:
I have sunspot version 1.2.1 and solr version 3.6. I also tested the grouping functionality with the solr version installed on my server by modifying the url and it works like a breeze.
However it breaks with the current sunspot version I have. I updated the sunspot gem to version 1.3.3 but it still breaks.
I'm pretty sure the syntax is correct because I followed the examples in the documentation:
https://github.com/sunspot/sunspot
I've looked around and this is the relevant answer i've found but doesn't help. Maybe i'm missing something?
Group using Sunspot/Solr?
These are the gems i've got installed:
gem 'sunspot_rails', '1.3.1'
gem 'sunspot_solr'
EDIT
Here's the code that is breaking. It is same as the documentation. ':question' is a single value text field I want to group on.
search.group(:question).groups.each do |group|
puts group.value
end
Problem Solved
Grouping is supported in Sunspot version 2.0.0
Hence the simple fix was just including the sunspot 2.0.0 gem and a bundle install.
Related
Does anybody have any experience with defining the python version of boost-python when installing from vcpkg?
I'm trying to use OpenVDB's python interface, and while I can get it working with the default python39 boost library, I'm not able to figure out how to define which boost-python version to install with vcpkg, and/or don't know how to define the correct parameters for the cmake command line to specify a python version at that point.
The default library that boost uses is 3.9, but as I'm typically in Anaconda, and 3.9 is not a standard download, I wanted to hold the boost library to be 3.8 instead.
I've commented in the github issues for openvdb, https://github.com/AcademySoftwareFoundation/openvdb/issues/946
but as this is not an issue with that project, and more of a dependencies thing, I thought I'd ask here in case you seen this on your travels :)
Thanks in advance for your time.
Neil
I am trying to build some source code on ubuntu 16.04 where one of the classes relies hierarchy_simplify_point_set.h header file, which is part of CGAL's point set package. After following instruction on the installation page, I have installed libcgal-dev and libcgal-qt5-dev via apt-get. The package manager has installed libcgal-dev 4.7 which should include the point set library. However, the particular header file seems to be missing (it seems to have some files from the point set library and not others - I am looking in /usr/include/CGAL). Does anyone know what I am doing wrong?
ps: For good measure, I have already tried uninstalling and reinstalling both the packages, but no luck.
This header has been introduced in CGAL 4.8 while it seems you are using CGAL 4.7.
You can get the latest version of CGAL here. Since the latest versions can be used as a header-only library, simply extract the release archive somewhere and set CGAL_DIR to that location when calling cmake to configure your example and it should work directly.
I'm running Ubuntu 16.04 LTS and I want to use Mongodb with PHP. For this I thought that sudo apt-get install php5-mongo (which is enough for Ubuntu 14.04 LTS) would be enough but I was wrong. I'm getting error like this E: Unable to locate package php5-mongo.
I've just upgraded to Ubuntu 16.04 LTS and want to use mongodb with PHP. Running PHP version is PHP Version 7.0.4-7ubuntu2.
So what can I do to solve this?
I'm afraid you are a bit out of luck at the moment. The current situation is that there are two MongoDB extensions:
"php-mongo", which is the "old" one; This extension supports up to PHP 5.*, but not PHP7. Only bug fixes are planned for it;
"php-mongodb", which is the "new" one; This extension supports PHP5 as well as PHP7;
Now the problem is that the new one is not compatible with the old one, as their whole internals are completely different. Unfortunately there are very few places where examples using the new one's syntax is used, as absolute majority of Mongo-related code is written using the old extension.
As it stands at the moment, if you have moved on to PHP7 your only option is to use the "new" extension, which in turn means that your previous code will stop working.
I've seen couple attempts to create a polyfill for making the migration those two possible (example: https://github.com/alcaeus/mongo-php-adapter), however as I haven't tried it myself I can't tell how well it works.
It seems that this library http://mongodb.github.io/mongo-php-library/ is supposed to cover the gap - after giving it a shot I believe it should cover majority of the "old" functionality without updating code too much.
If some of you are still wondering to use a simple wrapper to the new library as said in this answer: https://stackoverflow.com/a/48086676/2569789
I'm maintaining one for this purpose and you can find it here: https://github.com/ThomasSquall/PHP7MongoDriver
It covers just a few methods at the today's date but I'm going to improve it constantly and I hope would like to contribute too :)
I have a package I just updated to use setuptools_scm and found the version number is wrong in readthedocs.
http://sshuttle.readthedocs.org/en/v0.77/ shows:
Version: 0.78.dev0+ng083293e.d20160304
however as version 083293e has the 0.77 tag, the version string should be just 0.77
It looks like readthedocs might be making changes to my source code before building.
I have looked at the readthedocs build logs, and it seems to have the correct version at one stage (0.77), however this is before it builds the documentation.
Processing dependencies for sshuttle==0.77
Finished processing dependencies for sshuttle==0.77
The build logs don't mention the version while building the documentation.
Is it possible to solve this?
Thanks
I see that you're building this project.
Clearly, something is mutating the repository state before the version is determined. You can replicate similar behavior by mutating one of the files prior to building the docs yourself:
(sshuttle) $ python setup.py --version
0.77
(sshuttle) $ cat >> setup.py
# a comment
(sshuttle) $ python setup.py --version
0.78.dev0+ng083293e.d20160403
In the read the docs docs, there's a description of the process.
There, you can see the steps RTD does, namely, (a) run setup.py install then (b) install requirements in requirements.txt.
I've confirmed that neither of those steps should be mutating the repo state.
What it doesn't explain, however, is where that 'version' comes from, or what update_imported_docs does. I suspect the issue lies in something subtle that read the docs is doing that modifies the repo.
Here's one place where the conf.py file gets modified.
Perhaps adding docs/conf.py to your .gitignore will allow those changes to be ignored and thus not dirty your working state when calculating the project version.
https://github.com/pypa/setuptools_scm/issues/84 has been updated to record this
we will be working with the sphinx team to provide a automated/painless version of this process
The documentation for setuptools_scm now has instructions on how to use with readthedocs:
It is discouraged to use setuptools_scm from sphinx itself, instead
use pkg_resources after editable/real installation:
from pkg_resources import get_distribution
release = get_distribution('myproject').version
# for example take major/minor
version = '.'.join(release.split('.')[:2])
The underlying reason is, that
services like readthedocs sometimes change the workingdirectory for
good reasons and using the installed metadata prevents using needless
volatile data there.
This avoids the need to use kluges as per the other answer.
When I try running Unicorn after setting up postgres (works perfectly with Trinidad and Thin) I get the following error.
dyld: lazy symbol binding failed:
Symbol not found: _rb_thread_select
Referenced from:/Users/pls/.rvm/gems/ruby-2.2.0#coinino/extensions/x86_64-darwin-13/2.2.0/do_postgres-0.10.14/do_postgres/do_postgres.bundle
Expected in: flat namespace
Datamapper connects to the database normally inside a model.rb which then is required in app.rb.
What is wrong and how do I fix it?
Edit: Looks like this is a bug in Ruby 2.2.0.
A call used by old versions of the pg gem has been removed in Ruby 2.2. More recent versions of the gem no longer use this call; I know the latest version (0.18.1) doesn't, but I don't know when that change was made. You can update the pg gem by running the following command:
bundle update pg
As long as you're doing this, you may want to run just a plain bundle update to update all of your project's gems to the most recent versions—who knows what else might be incompatible with Ruby 2.2?
As always when updating dependencies, test that the update doesn't introduce any new bugs before you deploy the new version to production. I doubt pg will cause any problems, but other gems might.
It looks like this is a bug in Ruby 2.2.0. Going to Ruby 2.1.5 gets things going without trouble.