only parts of pylucene are available? - pylucene

i'm trying to port some Java Lucene code into pylucene (v 2.3.1). i'm
using the examples in
http://svn.apache.org/viewcvs.cgi/lucene/pylucene/trunk/samples/, and
most of pylucene seems to come into my python (ubuntu 12.04, pydev
2.6.0, eclipse 3.7.2) enviroment just fine. eg, i'm able execute
lucene.initVM() (showing JCC is in place) and to define a Porter
stemmer following the example taken from
.../samples/PorterStemmerAnalyzer.py via:
self.analyzer = PorterStemmerAnalyzer()
but when i try to create a new IndexWriter, it stumbles on the
last argument to its constructor:
self.writer = lucene.IndexWriter(self.store, self.analyzer, True, lucene.IndexWriter.MaxFieldLength.LIMITED)
i get this error:
AttributeError: type object 'IndexWriter' has no attribute 'MaxFieldLength'.
this is the error that has me stumped at the moment, but there are
several other hacks (from their version .../samples) i had also made
(but also worry about):
replace lucene.Version.LUCENE_CURRENT with lucene.LucenePackage
lucene.SimpleFSDirectory with lucene.MMapDirectory
in order to get this far.
http://lucene.apache.org/pylucene/features.html says "The PyLucene API
exposes all Java Lucene classes in a flat namespace in the PyLucene
module." this doesn't seem entirely right,
lucene.StopAnalyzer.ENGLISH_STOP_WORDS_SET is known to pydev while
lucene.ENGLISH_STOP_WORDS_SET is not.
so it seems i am getting part of/an old version of/...? pylucene
engaged correctly, but not all of it!? why might this be?

almost certainly the problem had to do with the most recent version of pylucene available as a .deb was 2.3.1 while pylucene is now at v. 3.6.1 !
making from the source distribution takes a bit of touch. the instructions from JohnW at
http://john.wesorick.com/2011/11/installing-pylucene-on-ubuntu-1110.html were helpful.
for what it's worth, here are the changes i wound up making, first to the JDK spec for linux2 in jcc/setup.py:
JDK = {
'darwin': JAVAHOME,
'ipod': '/usr/include/gcc',
'linux2': '/usr/lib/jvm/java-7-openjdk-amd64',
'sunos5': '/usr/jdk/instances/jdk1.6.0',
'win32': JAVAHOME,
'mingw32': JAVAHOME,
'freebsd7': '/usr/local/diablo-jdk1.6.0'
}
and then to the Makefile:
PREFIX_PYTHON=/usr
ANT=JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64 /usr/bin/ant
PYTHON=$(PREFIX_PYTHON)/bin/python
JCC=$(PYTHON) -m jcc --shared
NUM_FILES=4

I used rikb's answer and it worked, but I had to change
'linux2': '/usr/lib/jvm/java-7-openjdk-amd64',
to...
'linux2': '/usr/lib/jvm/java-6-openjdk-amd64',
Since I'm using Java 6. It appears he is too, so perhaps he hasn't used that configuration on Linux.
Also note that if you copy and paste all or part rikb's block of stuff for the Makefile you will probably have trailing spaces on each line. Then the 'sudo make' step will fail, rather mysteriously, with a message like "make: execvp: /usr: Permission denied". This is because the trailing space after "PREFIX_PYTHON=/usr " caused make to try to execute the dir /usr.

Related

How to configure the DotNet SDK used by FSAC –or– DLL Hell on Ubuntu

I'm learning F#, never having used any DotNet nor Mono before. I like the language, but I'm having a hard time with the myriad runtime versions and how to tell the various tools which version to use.
Summary: it appears DLL Hell on Ubuntu is a thing. How can I tell FSAC to run its auto-complete magic against the latest runtime version, namely Microsoft.NETCore.App 2.1.5, instead of whatever older incarnation it decided to use?
Longish explanation.
My platform is Ubuntu 18.04 amd64. I have installed the latest DotNet Core, specifically the packages dotnet-sdk-2.1 (version 2.1.403-1) and its dependencies dotnet-host, dotnet-runtime-2.1, etc. (which are all version 2.1.5-1). I also have Mono installed, because many tools apparently rely on it.
When I try to use some features that were recently added to DotNet Core, it feels like I'm uncovering a Pandora Box.
Take this example, which uses the new ProcessStartInfo.ArgumentList:
#r "System.Diagnostics.Process.dll"
open System.Diagnostics
let execute exe args =
let proc = new Process()
proc.StartInfo.FileName <- exe
for arg in args do proc.StartInfo.ArgumentList.Add arg
proc.Start() |> ignore
proc.WaitForExit()
execute "echo" ["foo"; "baz"]
If I naively try to run it with /usr/bin/fsharpi (which exec's /usr/bin/mono /usr/lib/mono/fsharp/fsi.exe) I get a "ArgumentList is not defined" error. Fair enough, I guess?
If I run it with /usr/bin/dotnet /usr/share/dotnet/sdk/2.1.403/FSharp/fsi.exe it works! It took me a long time to figure out I could even do it, but at last I'm on the right path.
But if I load the file in any IDE, such as VSCode with the Ionide plugin, or Sublime Text with the FSharp plugin, they still flag ArgumentList as invalid. Sublime's plugin also flags the #r line as invalid, but doesn't tell me why.
Focusing on Sublime's plugin and digging into the code, it appears that it relies on a tool called FsAutoComplete aka. fsac and on Linux explicitly invokes it with mono.
I tried running the FSAC tool with DotNet Core, but it fails to find some library or other:
$ cd .config/sublime-text-3/Packages/FSharp/fsac/fsac/
$ dotnet fsautocomplete.exe
A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/home/tobia/.config/sublime-text-3/Packages/FSharp/fsac/fsac/'.
Failed to run as a self-contained app. If this should be a framework-dependent app, add the /home/tobia/.config/sublime-text-3/Packages/FSharp/fsac/fsac/fsautocomplete.runtimeconfig.json file specifying the appropriate framework.
If I take a filesystem approach and search for System.Diagnostics.Process.dll, I'm baffled by the results:
/usr/lib/mono/4.5/Facades/System.Diagnostics.Process.dll
/usr/lib/mono/4.7.1-api/Facades/System.Diagnostics.Process.dll
/usr/lib/mono/xbuild/Microsoft/Microsoft.NET.Build.Extensions/net461/lib/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/2.1.403/Microsoft/Microsoft.NET.Build.Extensions/net461/lib/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/microsoft.netcore.app/2.1.0/ref/netcoreapp2.1/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/lib/net46/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/lib/net461/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/ref/net46/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/ref/net461/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/ref/netstandard1.3/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/ref/netstandard1.4/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/linux/lib/netstandard1.4/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/osx/lib/netstandard1.4/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/win/lib/net46/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/win/lib/net461/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/win/lib/netstandard1.4/System.Diagnostics.Process.dll
/usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.5/System.Diagnostics.Process.dll
Plus another dozen in my home directory, under ~/.nuget. That's insane.
To begin with, the entire /usr/share/dotnet/sdk/NuGetFallbackFolder subtree does not seem to be owned by any Deb package, which is worrisome enough. The others belong to these packages:
mono-devel: /usr/lib/mono/4.5/Facades/System.Diagnostics.Process.dll
mono-devel: /usr/lib/mono/4.7.1-api/Facades/System.Diagnostics.Process.dll
msbuild: /usr/lib/mono/xbuild/Microsoft/Microsoft.NET.Build.Extensions/net461/lib/System.Diagnostics.Process.dll
dotnet-sdk-2.1: /usr/share/dotnet/sdk/2.1.403/Microsoft/Microsoft.NET.Build.Extensions/net461/lib/System.Diagnostics.Process.dll
(*) dotnet-runtime-2.1: /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.5/System.Diagnostics.Process.dll
Running a simple Grep shows that only the last one marked with (*) knows anything about ArgumentList.
So all these other libraries are older / legacy versions, including the one in dotnet-sdk-2.1 itself.
I can only presume that the SDK, aka. the compilers and interpreters, are built against an older version of the runtime / system libraries than the one they build code against. Which is an interesting choice, to say the least.
Taking a process approach, lsof tells me that the FSAC process has only opened DLL files from inside /usr/lib/mono and from its own local directory. This is not promising.
Is there a way to tell FSAC to use the Microsoft.NETCore.App 2.1.5 runtime / system libraries for its autocomplete and linting work?

unable to execute 'x86_64-conda_cos6-linux-gnu-gcc': No such file or directory (pysam installation)

I am trying to install pysam.
After excecuting:
python path/to/pysam-master/setup.py build
This error is produced:
unable to execute 'x86_64-conda_cos6-linux-gnu-gcc': No such file or directory
error: command 'x86_64-conda_cos6-linux-gnu-gcc' failed with exit status 1
There are similar threads, but they all seem to address the problem assumig administriator rights, which I do not have. Is there a way around to install the needed files?
DISCLAIMER: This question derived from a previous post of mine.
manually installing pysam error: "ImportError: No module named version"
But since it might require a different approach, I made it a question of its own.
You can also receive the same error while installing some R packages if R was installed using conda (as I had).
Then just install the package by executing: conda install gxx_linux-64 to have that command available.
Source:
https://github.com/RcppCore/Rcpp/issues/770#issuecomment-346716808
It looks like Anaconda had a new release (4.3.27) that sets the C compiler path to a non-existing executable (quite an embarrassing bug; I'm sure they'll fix it soon). I had a similar issue with pip installing using the latest Miniconda, which I fixed by using the 4.3.21 version and ensuring I was not doing something like conda update conda.
See https://repo.continuum.io/miniconda/ which has release dates and versions.
It should now be safe to update conda. This is fixed in the following python packages for linux-64:
python-3.6.2-h0b30769_14.tar.bz2
python-2.7.14-h931c8b0_15.tar.bz2
python-2.7.13-hac47a24_15.tar.bz2
python-3.5.4-hc053d89_14.tar.bz2
The issue was as Jon Riehl described - we (Anaconda, formerly Continuum) build all of our packages with a new GCC package that we created using crosstool-ng. This package does not have gcc, it has a prefixed gcc - the missing command you're seeing, x86_64-conda_cos6-linux-gnu-gcc. This gets baked into python, and any extension built with that python goes looking for that compiler. We have fixed the issue using the _PYTHON_SYSCONFIGDATA_NAME variable that was added to python 3.6. We have backported that to python 2.7 and 3.5. You'll now only ever see python using default compilers (gcc), and you must set the _PYTHON_SYSCONFIGDATA_NAME to the appropriate filename to have the new compilers used. Setting this variable is something that we'll put into the activate scripts for the compiler package, so you'll never need to worry about it. It may take us a day or two to get new compiler packages out, though, so post issues on the conda-build issue tracker if you'd like to use the new compilers and need help getting started.
Relevant code changes are at:
py27: https://github.com/anacondarecipes/python-feedstock/tree/master-2.7.14
py35: https://github.com/anacondarecipes/python-feedstock/tree/master-3.5
py36: https://github.com/anacondarecipes/python-feedstock
The solution that worked for me was to use the conda to install the r packages:
conda install -c r r-tidyverse
or r-gggplot2, r-readr
Also ensure that the installation is not failing because of admin privileges.
It will save you a great deal of pain
After upgrading Golang to 1.19.1, I started to get:
# runtime/cgo
cgo: C compiler "x86_64-conda-linux-gnu-cc" not found: exec: "x86_64-conda-linux-gnu-cc": executable file not found in $PATH
Installing gcc_linux-64 from the same channel, has resolved it:
conda install -c anaconda gcc_linux-64
Somewhere in your $PATH (e.g., ~/bin), do
ln -sf $(which gcc) x86_64-conda_cos6-linux-gnu-gcc
Don't put this in a system directory or conda's bin directory, and remember to remove the link when the problem is resolved upstream. gcc --version should be version 6.
EDIT: I understand the sentiment in the comments against manipulating system paths, but maybe we can use a little critical thinking for the actual case in hand before reciting doctrine. What actually have we done with the command above? Nothing more than putting an executable (symlink) called x86_64-conda_cos6-linux-gnu-gcc in one's personal ~/bin directory.
If putting something in one's personal ~/bin directory broke future conda (after it fixes the C compiler path to point to gcc it embeds), then that would be a bug with conda. Would the existence of this verbosely named compiler mess with anything else? Unlikely either. Even if something did pick it up, it's just your system gcc after all...

Installing SDL in cygwin

I have Cygwin, setup version 2.8473, 64-bit. I've installed gcc-g++. I am trying to install SDL2, trying both SDL2-2.0.3 and SDL2-2.0.4. I'll talk about the problems with 2.0.3, since that's the stable release.
I read that I should run /usr/bin/set-gcc-default-3.sh, but it's not there. (gcc does seem to have been installed, as I see it working when I run make in the SDL2-2.0.3 directory.) I haven't been able to find out where to get it by searching Internet -- maybe this is it? Without it, make gives me these complaints:
Warning, configure.in is out of date
and lots of "static declaration" errors like this:
.../SDL_render_d3d11.c:135:19: error: static declaration of 'IID_IDXGIFactory2' follows non-static declaration
static const GUID IID_IDXGIFactory2 = { 0x50c83a1c, 0xe072, 0x4c48, { 0x87, 0xb
^
I wasn't able to find anything useful googling IID_IDXGIFactory2.
According to the SDL Wiki's page on installation, "As of SDL 2.0.3, the codebase still compiles on Cygwin and MingW32, but we expect these to stop working in the future." So it's no longer supported, and I'll leave it.

Cygwin Gcc error while loading shared libraries?

I have instaled Cygwin after running MinGW for a while now. But when I try to compile the console gives me:
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/cc1.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory
What does this mean?
I have the same problem and I found the solution.
According to the FAQ of Cygwin
Q: Why is C:\cygwin\usr\bin invisible from windows?
A: Because it does not really exist. In cygwin, /usr/bin is just a link to /bin.
So trying to add "C:\cygwin\usr\bin" to PATH will be in vain.
Add "C:\cygwin64\bin" to PATH instead. Hope this helps :)
You are missing a library, please run cygcheck /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/cc1.exe or ldd /usr/lib/gcc/x86_64-pc-cygwin/4.9.2/cc1.exe to see what is the missing library.
(I'd rather ask a question in the comments first, but I don't have enough reputation yet.)
Your cc1 is unable to load some DLLs it needs to start. Looking at the Cygwin source code, this can be either a library specified in LD_PRELOAD, or -- more probably -- a library the executable depends on. The ? in the error message seems to be the default return value of find_first_notloaded_dll (hookapi.cc), in case the function can't determine what library is missing.
To diagnose the issue, I suggest checking your PATH variable (or even clearing it of any non-Cygwin paths and trying the compilation again) and/or using Dependency Walker to find the missing DLLs (start it from a Cygwin shell, so it can see the same PATH). ldd (included with Cygwin) may also give some clues, but I wouldn't bet on it.
It's possible a clean re-install of Cygwin will be necessary to solve the issue.
Most likely, you are simply missing /usr/bin in the PATH variable.
Adding 'export PATH=/usr/bin:$PATH' to your .bashrc file will solve the issue.
Adding some background info. I had the same problem when building my own program and linking it against graphviz cgraph.dll. Turns out this is related to where windows searches for DLLs (see here: https://msdn.microsoft.com/en-us/library/7d83bc18.aspx) So adding the path of your missing library to PATH should fix the problem.
It is unfortunate that the message doesn't include the name of the library. Luckily cmd.exe DOES give you this name (so it's good for something after all;)
Are you including the path to your lib directory?
Looks like you are not
I'm not very familiar with Cygwin, I mainly use MinGW, but I think the error message speaks for itself
I also came this error on windows machine while executing .exe file generated by scilab2C i.e toolbox for Scilab
For Windows 32 bit Add the environment variable path as follow :
C:\cygwin\usr\i686-pc-cygwin\bin
Hope so this will solve your issue.
Just had this problem trying to compile a package with make and it wanted some cygguile dll file that was just installed along with make.
My solution was I had not only migrated my cygwin64 directory across drives because the sector sizes were mismatched for some reason even though the drivers were both under 2TB and should have been using 512 byte sector sizes.. So I had to install a new system and move files over there, might have had weird permissions on them.
Also had to patch cygwin1.dll end of Jan 2020 because of a recent input problem in ConEmu with Windows 10 1903 build, but just did it again with this working so that doesn't seem to be the issue.
Reinstalling cygwin by deleting that entire directory, taking ownership of it first.., seemed to work now...

How to link with Python3 Libs with cmake?

I have Python3 installed via brew install python3. However, cmake cannot find PythonLibs 3. Here's the header of my CMakeLists.txt.
cmake_minimum_required(VERSION 3.0)
find_package(PythonLibs 3 REQUIRED)
When I ran cmake, I got this error message
Could NOT find PythonLibs: Found unsuitable version "2.7.6", but required is at least "3" (found /usr/lib/libpython2.7.dylib)
Not sure what I did wrong.
In my experience, this happened because I was using an older version of cmake (2.8 instead of 3+) that didn't know about Python 3.4 (it gave up after 3.3.)
The solution was to go into the CMakeLists.txt file and add an "additional versions" directive ABOVE the find_package:
set(Python_ADDITIONAL_VERSIONS 3.4)
find_package(PythonLibs 3 REQUIRED)
You could probably also fix it by upgrading your version of cmake. But the above worked for me with cmake 2.8
Because you are using CMake >= 3.0, you can you find_package(Python COMPONENTS Interpreter Development) see: https://cmake.org/cmake/help/v3.12/module/FindPython.html
That would for instance give you for:
find_package(Python COMPONENTS Interpreter Development)
message("Python_FOUND:${Python_FOUND}")
message("Python_VERSION:${Python_VERSION}")
message("Python_Development_FOUND:${Python_Development_FOUND}")
message("Python_LIBRARIES:${Python_LIBRARIES}")
Results:
Python_FOUND:TRUE
Python_VERSION:3.8.0
Python_Development_FOUND:TRUE
Python_LIBRARIES:/usr/lib/x86_64-linux-gnu/libpython3.8.so
Another reason for this is that CMake can't ever find Python 3 when it is installed from brew on OSX. It looks like the CMake devs know that FindPythonLibs sucks and have a ticket to revamp it but it doesn't look like it will happen any time soon.
I believe the Python interpreter itself knows where its libraries and headers are so I think the best thing to do would be to run it to find out. To get the path to the Python interpreter I would force the user to specify it manually. One of the big issues with Python is that lots of software includes its own copy so you'll end up with 5 copies of it on your system. The chance of picking up the wrong one is just too high. Get the user to specify the correct one.

Resources