I have been using these SDL2 bindings. Although I can execute my compiled program, I cannot open a window from GHCi, no matter what I try. I've tried out the examples from the repository, but they have the same issue. The error message I keep getting is:
*** Exception: SDLCallFailed {sdlExceptionCaller = "SDL.Video.getWindowSurface", sdlFunction = "SDL_GetWindowSurface", sdlExceptionError = "Invalid window"}
If it's of any relevance I'm on macOS. I'm also not necessarily married to this library, and if there is a way to create a window from GHCi with a different library, I'd be interested.
I was using stack, and this fixed my issues:
stack ghci --ghci-options '-fno-ghci-sandbox'
I'm not exactly sure why this works, but I have a hunch it has something to do with ghci spawning threads, and SDL2 wanting the window in the main thread. If anyone has a better understanding of these things I'm very interested.
Related
My program has a very specific error that took me a while to track down - now I don't know how to fix it. My code is very long and in many files and I don't see much point in posting it here.
In the IDE, everything runs fine, in both Debug and Release (with the runtime library set to either /MTd or /MT, respectively, so I'm assuming all dependencies are included).
However, when I run the standalone, I get a crash. At first I thought it was a dependency problem but it doesn't seem so.
At some point in the code, I am accessing a vector via a method call: t->GetList(), where GetList is defined as std::vector<T*> & GetList() and the method simply returns a member variable (simply defined as std::vector<T*> field in the class).
It turns out, if I print out the size of the list while running from the IDE, I get 0 (which is the correct answer in this case).
However, when doing the same thing running from standalone, I get the size as 467467353.
I tried changing the method declaration to std::vector<T*> * GetList() and doing return &field; and updating the rest of the code but this didn't fix anything.
I then tried replacing the member variable field with a pointer, and in the constructor instantiating a new vector and deleting it in the destructor. Still no luck.
So I made a simple test case program that simply made a class with a vector field, and a method to return a reference to it. Then in main I would create an instance variable and getting the vector and printing the size. This worked both in VC++ and as a standalone - both returned zero.
This is driving me nuts and I can't figure out why I'm getting different behaviour. Why is the standalone running differently, and what should I be looking at to fix this?
Thanks
Okay so it was literally a bug in my code that was very well hidden. I was dynamically casting to a wrong type.
Somehow it slipped past when I was running on Windows and OSX in both Debug and Release, and as a standalone on OSX. Good thing I found it.
I've had to move my stuff from a failing hard drive, so I've had to set up and reinstall everything again. And I've run into a couple problems.
So I've got two errors here. The first error that I get is when I open flashdevelop to begin working. I get the error of:
Can't Find Haxelib.exe
And of course, I've installed haxe and haxelib and everything else that's needed pre-setup. However, when I run, the flash and html5 targets work fine regardless. I don't know why that error shows up. Any ideas?
My second problem is that I've installed the necessary stuff for the windows runtime. However, when I try to run the exe in or outside of flashdevelop, the program freezes and gives me the:
This program is not responding.
error that you sometimes see when you crash a program. However, I have my neko stuff set up and it compiles fine, it just crashes on start. I have the background set to neko. I have just a sample hello world FlxText object like this:
hello = new FlxText(0, 0, 100, "Hello World!");
#if neko
hello.color = 0xffffff;
#else
hello.color = 0xffffffff;
#end
add(hello);
Any idea what could be causing the start crashes? It also has me wondering if the two aren't related some how.
Thanks in advance!
Using windows 8, haxe, haxeflixel, windows & neko runtimes.
I had this posted on another forum. The not responding error is fixed easily by adding:
<window allow-shaders="false"/>
In the projects xml file. The haxelib error still shows but it may be a non issue.
Things to try:
Make sure you use Haxe 3 and OpenFL (I think there is no sense of using Haxe 2 or NME).
Check if Haxe on PATH is Haxe 3 and check that OpenFL work fine. (Just open "cmd" and type "haxe" there to see version of Haxe available and type "openfl" there to test if it works, also check "haxelib")
Check FlashDevelop Haxe SDK
Trace your haxelibs here(use haxelib list in cmd)
This program is not responding.
This may mean, that you don't have some .dll in bin folder.(Depending on what you use in your project).
Or this may be connected somehow with your GPU drivers. Or it can be anything other. To get more info about that crash, try compiling to neko, and print output here.
Make sure you have latest haxelibs installed (haxelib upgrade and haxelib selfupdate)
To help you I need more info, print FlashDevelop output here.
I'm trying to compile some code in Real World Haskell - Chapter 24. LineCount.hs.
I have not made any changes to the code.
However, when I do:
ghc -O2 --make -threaded LineCount.hs
(as instructed in the book), I get the message:
MapReduce.hs:6:7: Not in scope: `rnf'
What might I be doing wrong?
A quick search showed up that there was some trouble with the packages parallel and strict-concurrency in the past, and that reinstalling them would fix the issue. However, I tried that and it didn't work. Moreover, it is noted there that that issue was fixed sometime in 2010:
https://groups.google.com/forum/?fromgroups=#!msg/happs/gOieP4xfpNc/nrasm842JlUJ
Note: I get various other errors when compiling other files in the same chapter. For example, on compiling Strat.hs I get: Module Control.Parallel.Strategies' does not exportparZipWith'. On compiling LineChunks.hs I get: Module Control.Parallel.Strategies' does not exportrnf'.
Honestly, as a novice Haskell programmer I expected to run into trouble once I started modifying code - but I didn't expect to have trouble with code from a book!
The function is no longer called rnf. It's called rdeepseq now. Just replace it. :)
You can find the contents of the parallel package online by googling "control parallel strategies hackage", or clicking here.
I developed an application using a recent Glade, so I need it to load the UI from XML at runtime, using the GtkBuilder. If I try to run this on a distro which has too old a Gtk (e.g. RHEL 5), it will fail like this
undefined symbol: gtk_builder_new
which is normal and expected. But I wonder if there is a way to catch that error and instead display a GUI error dialog saying something like "your version of Gtk is not new enough"? This is an error that happens before my main() starts, so really the question is, is there a way to handle runtime linking errors? While googling, I found a mention of the concept of a linker plugin but I didn't find details about that yet. It sounds like something which would have to exist outside my application anyway, so maybe that's going a bit far.
I could use dlopen() to load Gtk, but that's ridiculous because I'd have to give the full path to it, and then I'd have to call dlsym() a lot to link every function that I need. ld-linux.so does the search for me. Is there a way I can use ld-linux.so to tell me the path to libgtk without actually loading it, then I check whether the version is new enough (or just whether gtk_builder_new exists), then finish the runtime linking if it's OK?
Well, it doesn't work that way on a Linux distro. What you're basically doing is bypassing the package manager.
The good way is to build your software on the target distro. At configuration time (call to ./configure) you will see that the requirements to use your software are not met. Or if you have no configure script, the compiler will yell at link time.
Then, it's the packager's job to fill in the requirement of the package. If in the .spec file of your RPM package you require gtk >= 2.16, then at installation time, the user will be shown the dialog telling him that some dependencies are missing, and he will see that his GTK version is too old.
You seem to be talking about the situation where you have compiled against headers with a recent enough version, but are running on a system where your library is not recent enough.
GTK provides a facility for checking that you have linked against a new enough version of the library. For example, if you need at least GTK 2.12 (which is the version in which GtkBuilder was introduced) you can use this code which will even display a nice GUI error dialog:
if (gtk_major_version < 2 || gtk_minor_version < 12) {
GtkWidget *dialog = gtk_message_dialog_new(NULL, GTK_DIALOG_MODAL,
GTK_MESSAGE_ERROR, GTK_BUTTONS_CLOSE,
"Your version of GTK is too old to run this program.");
gtk_message_dialog_format_secondary_text(GTK_MESSAGE_DIALOG(dialog),
"You need at least version 2.12.0; your version is %d.%d.%d.",
gtk_major_version, gtk_minor_version, gtk_micro_version);
gtk_dialog_run(GTK_DIALOG(dialog));
gtk_widget_destroy(dialog);
exit(-1);
}
Here is a workaround which might help: Rename your exe and create a bash script which calls it.
Now you can do this:
EXE=...name-of-your-real-executable...
LOG=logfile
$EXE > "$LOG" 2>&1 || {
if grep "undefined symbol: gtk_builder_new" "$LOG" ; then
... show error message ...
fi
}
[EDIT] Alternatively, you can create a really small test program which just contains a call to gtk_builder_new and run that during installation or in the test script.
That way, you don't need to check for a specific error message (which might get translated on non-English systems). If this small test program fails, you can be sure it's because of this missing symbol and nothing else.
I am trying to build an old version of an application which consists of VC++ projects that were written in Visual Studio 2003.
My OS is Windows 7 Enterprise (64-bit).
When I try and build the solution I get the following errors:
error C4772: #import referenced a type from a missing type library; '__missing_type__' used as a placeholder
fatal error C1084: Cannot read type library file: 'Smegui.tlb': Error loading type library/DLL.
They both complain about the following import statement:
#import "Smegui.tlb" no_implementation
This is not a case of the file path being incorrect as renaming the Smegui.tlb file causes the compiler to throw another error saying it cannot find the library.
Smegui is from another application that this one depends on. I thought perhaps I was missing a dll but there is no such thing as Smegui.dll.
All I know about .tlb files is that they are a type library and you can create them from an assembly using tlbexp.exe or regasm.exe (the later also registers the assembly with COM)
There is also an Apache Ant build script which uses a custom task to invoke devenv.com to build the projects. This is the same script that the build server originally used to build the application. It gives me the same errors when I try and run it.
The strangest thing about this is that I knew it ought to work seeing as it is all freshly checked out from subversion. I tried many different combinations of admin vs user elevation, VS vs Ant build, cleaning, release.
I have got it to build successfully about 5 times but the build seems to be non-deterministic.
If anyone can shed some light on how this tlb stuff even works or what this error might mean I would greatly appreciate it.
I found a far more reliable solution: open the tlb with oleview.exe and then close it.
Not sure what this actually does but it works every time.
I think oleview is actually one of the samples included with Visual Studio but I haven't had the time to debug it and see what it is doing.
I ran into this error because one type library was trying to load a dependent type library, which it could not find. Even though the dependent type library was in the same directory, and even though that directory was in the searchable path, the compiler would error loading the first type library, but not mention the dependent type library in the error.
To find the pseudo-missing type library, I ran Process Monitor (procman64.exe) during the compile. This showed that after the reported type library had successfully loaded, a dependent type library could not be found. It even showed all of the places that it was looking for the dependent type library, none of which were where it should have been looking (e.g.: ).
The fix was to add a <PreBuildEvent> to the project to copy the dependent .tlb file to one of the directories that was actually being searched.
<PreBuildEvent>
<Command>copy /Y ..\Lib\Interop\CWSpeechRecLib.tlb .\</Command>
</PreBuildEvent>
http://msdn.microsoft.com/en-us/library/sce74ah7%28VS.71%29.aspx
smegui.tlb is referencing some other tlb that the compiler can't find. If you have the .idl for smegui you might be able to figure out what the other is. I suspect the missing tlb is something that original build machine had registered but that your machine doesn't have registered.
A type library is a binary description of a set of interfaces, coclasses and enums. They're usually generated for COM components, in the case of tlbexp and regasm the tlb is created from the assembly metadata. For native COM components they are usually generated from an idl (Interface Description Language) file by the midl tool.
Edit:
I just noticed you're on x64 Windows. Are you building the project with a new version of Visual Studio? If so, are you targeting x86 or x64? If the latter, it may simply be a 32bit component that the compiler can't find (or less likely, a x64 component the x86 compiler can't find if you are targeting x86), for WOW64 the registry is virtualized for x86 vs. x64 applications.
Well I finally found out why I managed to get it to build sometimes and not others... sort of.
So long as I ran the build script with elevated administrator permissions and let that get as far as it could until that error occurred, then run the build script again as a protected administrator succeeded. Those steps must be done in that exact order with no other steps in between. If I try build in Visual Studio it does not work (although I did get it to succeed once). Probably some kind of virtualisation issue although it still doesn't quite make sense.
Well I don't need help on this any more and I know it's probably impossible to fully answer this question without knowing exactly what the build is doing. However if anyone does have any more thoughts I would happily receive them.
Cheers,
Steiny