As of May 2016, does ghc-mod support projects compiled with ghcjs?
I realise that in a lot of cases, the source is the same, but this is not the case when working with ghcjs-dom library.
I currently have 2 project folders, configured with stack. From outside these folders:
ghc-mod check folder1/executable/Main.hs
works perfectly. The stack.yaml file here specifies ghc-7.10.2
ghc-mod check folder2/executable/Main.hs
fails. The stack.yaml file here specifies ghcjs-0.2.0.0_ghc-7.10.2
Is this expected behaviour? I can't tell frrm the feature requests and wikis what the current state is.
Not currently - https://github.com/ghcjs/ghcjs/issues/271
Note that this is actually pretty tricky as ghc-mod would need to be linked with ghcjs. As far as I know ghcjsi is the only such tool to work with ghcjs
Related
My goal is to connect the open-source CBC solver with Pyomo in Spyder. I am working on a Windows 10 machine and it is not an option for me to use the NEOS server due to company policy.
I have downloaded the binaries from Bintray (https://bintray.com/coin-or/download/Cbc#files) that include a cbc.exe file. However when trying to run it, several errors come up stating that I am missing files (among other libbz2-1.dll and zlib1.dll). I do not know much about linux or software development but after a lot of time on google I understand that these are used for unpacking data among other things. I found all files except zlib1.dll in a developer chat on the same subject and zlib1.dll I found on another page. However when running I now get the error: “The application was unable to start correctly (0xc000007b).
I have also tried downloading MSYS2 MinGW and followed instructions from CBC. I don’t know if I require this or if it is only for developers.
Can anyone tell me what to do? I suspect other people than myself want to use CBC in Pyomo as an alternative to GLPK.
If you already have the .exe file, make sure it is in your current working folder (set as the working directory in Spyder, simply opening your file is not enough) and call it using the SolveFactory function:
opt = SolverFactory("cbc.exe")
results = opt.solve(model)
It works for me.
You will find some general information here where i outlined some approaches.
While this was targeted at Clp, it also applies to Cbc.
It's a bit strange as i observed too, that some libs are not statically linked (zlib) while it's certainly doable. But as mentioned in the thread, this should not be the case anymore (see the restriction about which files are fully statically linked) and therefore your observation is strange (and you did not say, which file you downloaded).
So i would trying one of the following (in this order):
Try again with your source, but stick to the master-versions (see first link) as the maintainer only guaranteed fully-static builds for those!
Use the builds from AMPL
(tested and works for me; generally recommended in terms of quality/stability of builds)
Use the builds from coin-or/pulp, another modelling-tool for python
(tested and works for me)
Compile from source using mingw64
(Use any build and provide some external dll of zlib and co -> hard to debug)
Of course i completely ignored other potential issues:
license-stuff (what's part of those builds)
not sure if a company can afford to use binaries not build themself in regards to legal stuff
version-compatibility with python
does every version of Cbc work
cbc version + configuration
modern version
compiled with multi-threading
...
I've used Buildroot quite a bit over the years, and I've always managed to find solutions to the obstacles I've hit. But this one has me going in circles.
I've added a git-sourced python tool as a host package to my Buildroot build for an ARM target. I have completed the work on the package/Config.in.host and the package/toolname/Config.in.host as well as package/toolname/toolname.mk files. Everything looks to be in order. I have compared the work with what the add_new_package.wizard outputs.
The new option DOES appear in the menuconfig.
It is NOT available as a make target, although I do have target-side packages I have included that ARE valid make targets. i.e. I can run:
make target-side-package-name
and those packages are built just fine.
I cannot run:
make host-side-package-name as I get the error "No rule to make target".
So there must be something I'm doing incorrectly with the host package, although I clearly am doing the right things with the target packages.
Everything points to Buildroot simply ignoring my host package, other than sticking it into the menuconfig. My hours of searching on the webs have led to not one single post about someone having this same problem. I'm missing something obvious I would think.
My question is - what debugging can I do, where can I look to find out what is keeping Buildroot from properly recognizing my new package?
EDIT: I believe I understand now that part of the problem is the build order, and perhaps I can fix one issue with dependency directives. My target package that relies on the host package was being built first. I had assumed as common sense would dictate that host packages would be dealt with first, but that is apparently not true.
EDIT: Posting the .mk file
TOOLNAME_VERSION = 2
TOOLNAME_SITE = $(call github,devname,toolname,$(TOOLNAME_VERSION))
TOOLNAME_SETUP_TYPE = setuptools
TOOLNAME_LICENSE = GPL-3.0
TOOLNAME_LICENSE_FILES = LICENSE
HOST_TOOLNAME_DEPENDENCIES = host-python-library
$(eval $(host-python-package))
TOOLNAME = $(HOST_DIR)/usr/bin/toolname
As I hinted before, it is now running just fine so I know it's mostly set up correctly, the remaining problem is the make target is missing. Per the Buildroot manual, I should have one available.
I have now discovered that the missing make target is in fact making it impossible to build other packages dependent upon this one. The build of the dependent package now fails because "No rule to make" on the toolname package it is made to depend upon through
TARGET_PACKAGE_DEPENDENCIES = toolname
Can you post your toolname.mk? It sounds like you forgot to add the $(eval $(host-python-package)) line.
Hallelujah! The answer is that the make target name is NOT toolname, but is instead host-toolname. The root cause of the problem is the lack of mention of this nuance in section 8.12.5 of the Buildroot documentation. I stumbled across the answer while researching package dependencies in Chapter 17, where it does identify proper use for that specific case.
I'm just trying to get my foot inside the OSX world after recently getting a MAC.
Over the past months i haven't successfully built a working VST 2.4 yet. I simply dont get why: the projects in the vst examples work (somewhat) out of the box, but my own projects fail to work.
I've mirrored every build setting exactly (including info.plist and pkginfo), double checked that the contents of the vst.app is identical, correctly gets build as vst with correct extensions etc., and the code is virtually the same, however my vst doesn't get recognized in any of the hosts i tried.
The commandline even is identical for the build.
I've tested my VST with the included minihost vst tester, and it passes and works - but still wont be recognized. I even checked the exported symbols with nm and they look correct (ie. createEffectInstance is correctly exported).
What gives? There must be some hidden build setting somewhere that i haven't discovered that seems to disqualify my VST.
Probably the most obvious but overlooked setting: are you building as 32 or 64 bit? You need to make sure that the bitness matches your host, otherwise the plugin won't be loaded (which, btw, might explain why the plugin could load in your self-built minihost and not another sequencer). To ensure compatibility with most hosts, I'd go for 32-bit build.
Also, here's a tutorial I wrote on the subject awhile back. However, you claim that you are doing everything correct with the Info.plist and whatnot, but perhaps you missed a small step:
http://teragonaudio.com/article/Making-a-VST-plugin-from-scratch-with-Xcode.html
Another potentially useful tool is MrsWatson (disclaimer: I'm the author of that program). It's a command-line VST host which can be used to provide diagnostic information about VST's, and also is designed for plugin testing and debugging. Because of the 32/64 bit difficulties with plugins, on Mac OSX the program ships separate 32 & 64 bit binaries rather than using a universal binary.
You should try running the following command on your plugin:
mrswatson --verbose --plugin /path/to/wherever/you/put/the/plugin.vst --display-info
If you see a list of parameters and other info, then it should be kosher and able to be loaded in most sequencers. Hope this gets you on the right track!
Try using your debugger to watch what Dispatcher() calls your host makes. Check if there are any differences between your plugin and the included example projects. In my experience a host will usually abort loading a plugin immediately after a Dispatcher() call raises an exception or returns a result the host doesn't like for whatever reason.
I am building a win32 executable. The compiler is the latest version of MinGW. The library dependencies are GLUT and libpng.
I first tested on a windows 7 machine, and had to obtain libpng3.dll and freeglut32.dll. However, on XP, I had to (in addition) acquire zlib1.dll.
The XP machine was a VM with a fresh install, so I suspect a fresh win7 machine may also be lacking zlib1.
My question is how do I go about finding out which dll's I need to distribute? How do I know, a priori, which dynamic libraries are needed for my program to run on a particular system? I suppose this is what installer programs are for... I'm guessing that what the installer does is look through the system to find out which dependencies are unsatisfied, and then provides them. So this way if I were to distribute my program I could check if the user's machine already has zlib1.dll, and I won't install zlib1.dll if it's already found in the system directory. However I never found a document that said to me specifically, "libpng requires zlib", and so, until such point as I tested the executable on a machine lacking zlib, I was unaware of this dependency. How can I create my dependency list without having a fresh install of each version of every operating system to test on?
One idea I have is to decompile the executable, or through some method examine the linking process, to find all the libraries that are being linked at runtime. The problem now becomes figuring out which of these are supposed to already be there, and which of them I could be expected to provide in the distribution.
edit: Okay, I looked, and the installation of libpng I downloaded did provide zlib1.dll inside its bin directory. So not including it is pretty much my fault. In any case, Daniel's answer is definitive.
Dependendy Walker shows all deps of your program.
The correct answer to this question, in my view, is to start at the source rather than to reverse engineer the solution with Dependency Walker, awesome and useful tool though it undoubtedly is.
The problem with Dependency Walker is that it only tells you what one particular run of the program requires on the OS on which you run it. If you have any dynamic loading dependencies in your app then you would only pick those up if you made sure you profiled the app with Dep. Walker and forced it through those dynamic loads.
My preferred approach to this problem is to start with your own source code and analyse and understand what it depends upon. It's often easy enough to do so because you know it well.
You need to understand what are the deployment requirements for your compiler. You usually have options of linking statically and dynamically to the C++ runtime. Obviously a dynamic link results in a deployment requirement.
You will also likely link to 3rd party code. One example would be Windows components. These typically don't need deployment, you can take them as already being in place. Sometimes that's not true, e.g. GDI+ on Windows 2000.
Sometimes you will link statically to 3rd party code (again easy), but if you link dynamically then that implies a deployment requirement.
I have a custom framework that, following the advice in Apple's Framework Programming Guide >> Installing your framework I install in /Library/Frameworks. I do this by adding a Run Script build phase with the following script:
cp -R build/Debug/MyFramework.framework /Library/Frameworks
In my projects I then link against /Library/Frameworks/MyFramework and import it in my classes like so:
#import <MyFramework/MyFramework.h>
This works very well, except that I always see the following message in my debugger console:
Loading program into debugger…
sharedlibrary apply-load-rules all
warning: Unable to read symbols for "/Users/elisevanlooij/Library/Frameworks/MyFramework.framework/Versions/A/MyFramework" (file not found).
warning: Unable to read symbols from "MyFramework" (not yet mapped into memory).
Program loaded.
Apparently, the compiler first looks in /Users/elisevanlooij/Library/Frameworks, can't find MyFramework, then looks in /Library/Frameworks, does find MyFramework and continues on its merry way. So far this has been more of an annoyance than a real problem, but when runnning unit tests, gdb stops on the (file not found) and refuses to continue. I have solved the problem by adding an extra line to the Run Script Phase
cp -R build/Debug/MyFramework.framework ~/Library/Frameworks
but it feels like sello-taping something that shouldn't be broken in the first place. How can I fix this?
In the past months, I've learned a lot more about frameworks, so I'm rewriting this answer. Please note that I'm talking about installing a framework as part of the development workflow.
The preferred location for installing a public framework (i.e. a framework that will be used by more than one of your apps or bundles) is /Library/Frameworks[link text] because "frameworks in this location are discovered automatically by the compiler at compile time and the dynamic linker at runtime."[Framework Programming Guide]. The most elegant way to do this is in the Deployment section of the Build settings.
As you work on your framework, there are times when you do want to update the framework when you do a build, and times when you don't. For that reason, I change the Deployment settings only in the Release Configuration. So:
Double-click on the framework target to bring up the Target info window and switch to the Build tab.
Select Release in the Configuration selectbox.
Scroll down to the Deployment section and enter the following values:
Deployment Location = YES (click the checkbox)
Installation Build Products Location = /
Installation Directory = /Library/Frameworks
The Installation Build Products Location serves as the root of the installation. Its default value is some /tmp directory: if you don't change it to the system root, you'll never see your installed framework since it's hiding in the /tmp.
Now you can work on your framework as you like in the Debug configuration without upsetting your other projects and when you are ready to publish all you need to do is switch to Release and do a Build.
Xcode 4 Warning
Since switching to Xcode 4, I've experienced a number of problems with my custom framework. Mostly, they are linking warnings in GDB that do not really interfere with the usefulness of the framework, except when running the built-in unit-test. I have submitted a technical support ticket to Apple a week ago, and they are still looking into it. When I get a working solution I will update this answer since the question has proven quite popular (1 kViews and counting).
There's not much reason to put a framework into Library/Frameworks, and it's a lot of work: You'd need to either do it for the user in an Installer package, which is a tremendous hassle to create and maintain, or have installation code in your app (which could only install to ~/L/F, unless you expend the time and effort necessary to make your app capable of installing to /L/F with root powers).
Much more common is what Apple calls a “private framework”. You'll bundle this into your application bundle.
Even frameworks intended for general use by any applications (e.g., Sparkle, Growl) are, in practice, built to be used as private frameworks, simply because the “right” way of installing a single copy of the framework to Library/Frameworks is such a hassle.
The conventional way to do this is to have your framework project and its clients share a common build directory. Xcode will search for framework headers and link against framework binaries in the build folder first, before any other location. So an app project that compiles and links against the header will pick up the most-recently-built one, rather than whatever's installed.
You can then remove the cp -r and instead use the Install Location build setting to place your build product in the final location, using xcodebuild install DSTROOT=/ at the command line. But you'll only need to do this when you're finished, not every time you rebuild the framework.
Naturally, when you distribute your framework it should be installed in /Library/Frameworks; however it seems odd to me that you're doing that with the test/debug versions of your framework.
My first instinct would be to install test versions under ~/Library, as it just makes setting up your test and debug environment that much simpler. If possible, I would expect the debug/test framework to be located in the build tree of the version I'm testing, in which case it's installed as a Private Framework for testing purposes. That would make your life much simpler when it comes time to deal with multiple versions of your framework.
Ultimately, it doesn't matter where the framework is located as long as your application or test suite loads the correct version. Choose the location that makes testing/debugging/development easiest.