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.
Related
Is there a way to make intellisense work for additional modules (anything outside the prelude) like Quicktest or Random in VS Code?
I am using:
VSCode: Version 1.55.0
the extension "Haskell v1.2.0" (with haskel-language-server)
ghci: GHCi, version 8.10.3: https://www.haskell.org/ghc/
stack: Version 2.5.1, Git revision d6ab861544918185236cf826cb2028abb266d6d5 x86_64 hpack-0.33.0
tried it direct on Windows10 and with WSL2 (Debian).
VSCode says:
Could not find module ‘Test.QuickCheck’
It is not a module in the current program, or in any known package.not found
So, no autocomplete etc..
I think the reason is that I've installed Quicktest via stack, and that stack uses its own "isolated" ghc. So I looked for a way to configure the VSCode extension to use the ghc of my stack environment, without success.
I've also tingled with haddock and cabal, without success.
Does anybody using VS-Code to code haskell and have autocomplete, documentation on mouse over, wingman, ...?
I was having this problem with some local modules. I was able to fix it by placing a hie.yaml file in the project's root directory and reloading VSCode. Admittedly I don't really know what it does. I generated it using implicit-hie which you can install with stack.
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?
I'm starter Z3 so my question may be too basic.
But If you let me know some information for my question, I'm very happy.
I searched before history in this site.
But I couldn't get detailed information for me. ( because maybe..my question is too basic..)
[using Visual C++]
1) First of all, I downloaded "z3 4.3.0 for window" at codePlex site.
But this file doesn't have example file(test_capi.c).
So I got "z3-89c1785b73225a1b363c0e485f854613121b70a7.zip" for example file.
( I cannot remember what I can get... :( )
I succeeded compiling python file as codeplex site quide.
But I cannot compile test_capi.c using Visual C++.
I also added "test_capi.c" at "z3 4.3.0 for window" folder but I cannot also compile.
Lastly, I just tried using "test_capi.vcxproj" of "z3-src-4.1.1" and this is succeeded.
I cannot understand.
If i want to test "my file", what file is needed at "z3 4.3.0 for window"?
Or
Do I have to use only "z3 4.1.1" for visual c++ and add "my file" at some location of "z3 4.1.1"? ( All files of Z3 4.1.1 is needed?? AND what is the Some location?)
I read other some comment - "Z3 4.3.0" is simplified.
I understood this comment that I can use only "z3 4.3.0" and test successfully.
But as i told you, I cannot compile.
Please give me some information..
[using gcc in ubuntu]
First of all, I downloaded "z3-4.3.2.07d56bdc705c-x86-ubuntu-12.04.zip" from codeplex site.
Because I tried git command for getting source code but i cannot find source code.
( I also don't know the reason..)
Anyway... "z3-4.3.2.07d56bdc705c-x86-ubuntu-12.04.zip" doesn't have any example file and only bin & include folder is existed.
So I also used "z3 4.1.1" but i cannot compile using below command.
gcc -fopenmp -o test_capi -I ../../Include -L ../../lib test_capi.c -lz3-gmp
Error is "cannot find -lz3-gmp."
In some comment, I found "use "sudo install"" but i don't know how i can install lz3.
(Of course only "sudo install" doesn't work and "sudo apt-get install z3" also doesn't work...)
For compiling "test_capi.c" using gcc, could you explain in detail..?
I'm confused many kinds of guide but i couldn't get basic information for me.
Thank you in advance and I hope to get information...even if my question is too basic..
First, you should use only one version of the source code. Version 4.1.1 is very old and newer versions do not come with test_capi.vcxproj anymore, instead everything is done via the Makefile. For the very latest version please use the unstable branch (e.g., by selecting unstable here and then clicking download.)
The examples can be compiled by calling nmake examples (on Windows) or make examples (on Linux) in the build directory. The makefile has a target called _ex_c_example which shows how to call the compiler for the C example. The various variables that this target uses are defined in build/config.mk. Note that these variables are set to different values on Windows and Linux (this file is produced by python scripts/mk_make.py).
The git command on many Linux distributions is not compatible with the codeplex git server (for a fix see here), but of course this is not necessary if you download the source code from the webpage directly.
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.
It's not often two things I love so much come together to cause me so much annoyance (besides my kids). I've written a Haskell program at work that uses libraries like text, xml-enumerator, attoparsec-text, etc. I have it working properly on my Windows machine at work, my Ubuntu virtual machine at work (32-bit), my Ubuntu desktop (32-bit again) and an EC2 instance running Ubuntu (64-bit).
Our client is running CentOS 5.3, 64-bit. I can't for the life of me get this executable to run properly. I tried creating a static executable using:
ghc --make myprog.hs -optl-static -optl-pthread
But when I try to run that executable on the CentOS server, I get an error message:
openFile: invalid argument (Invalid argument)
I'm assuming this is related to the bug described here. I've tried compiling from both 32 and 64 bit Ubuntu, tried static and shared builds, nothing works (though I occasionally get segfaults instead of the above error message). I can try downloading CentOS 5.3 and creating a virtual machine for it, but it will take a while to download, and I'm not sure which version of GHC will work on it (I tried getting GHC 7 on their server, but I ran into a libc issue).
At this point, I've come up with a few possible approaches, but I'd like to avoid these if at all possible:
Rewrite in a different language (the thought of doing this in Java makes me queasy, though it could be a nice time to try out Cal/OpenQuark).
Maybe try out an alternate compiler, like jhc. But I'm not quite certain how to get started installing all the dependencies for this program in jhc; if people have experience and know that text/attoparsec/etc work in jhc, I'd love to hear it.
Hack of all hacks: build a Windows executable, install wine on their server and run it that way.
As a total aside, these are the situations where I really wish we had a JVM backend for GHC. I suppose I could try out LambdaVM as well. But I'd love to hear community advice on what to do here.
This simple example "works for me":
$ cat A.hs
main = print "yes"
$ ghc -O2 --make -static -optc-static -optl-static A.hs -fvia-C -optl-pthread
$ ldd A
not a dynamic executable
$ ./A
"yes"
(and I've used this process, via .cabal, to ship executables for clients in the past couple of years).
I think the best bet is to file bugs, and get this working. The IHG can also fund work like this, but I'm fairly sure the GHC team would consider this a high priority, if you're trying to ship products.
It is related to the old glibc library in CentOS. You have to compile with the same version of glibc as installed on CentOS.
I had exactly the same problem. Haskell executable compiled on arch (or ubuntu) won't run on CentOS. In my case though i was lucky, because our admin just removed CentOS and installed Arch for application server.
I found out the problem. It seems that the link to the Biohaskell page is accurate: this is a problem loading iconv. This occurs when calling openFile, but not when calling openBinaryFile. Since xml-enumerator uses the latter, it worked just fine. Switching over the rest of the code to use openBinaryFile instead (via Data.Enumerator.Binary.enumFile) got everything to work.
This is a good workaround for my use case, but the bug still exists.