reccently, I want to test how does the autoscheduler "Li2018" work on GPU. Firstly, I need to load the plugin of this autoscheduler into my project with function "load_plugin("gradient_autoscheduler")" like the example: https://github.com/halide/Halide/blob/master/apps/gradient_autoscheduler/test.cpp but the biggest problem is, that I cannot generate the plugin on Windows. I have tried to add the "generate_autoscheduler" into the CMakeList.txt in the /apps folder, but it can not work. To compare with autoscheduler "Admas2019" which in the folder /apps/autoscheduler, "Li2018" need a CMakeList.txt to generate the dll plugin, Does some one know how to generate the plugin of "Li2018" on windows? Thanks in advance!
As you have noticed, we don't have a CMake configuration for Li's autoscheduler, so Windows is not supported yet. I'll put this in my TODO list, but contributions are always welcome. It shouldn't be hard to come up with a CMakeLists.txt based on the Makefile content.
Related
When I run my Unity app in the editor, it is able to read my .dlls and other custom files the .dlls need and it works fine. However, when I make a build, it only includes the .dll files in the Plugins folder of the build and not the other custom files. Is there a way to force Unity to include the other files as well? I have tried putting them both in the Plugins and Resources folder before building and in both cases it only keeps the .dlls.
The custom files are .obf, but I don't think that's relevant
It is extremely relevant. Unity does not support all type of libraries.
Here are the supported library extensions:
For Windows, you can use .dll.
For Linux, .so is supported.
For Android, you can only use .aar, rar and .so.
For iOS, .a is used but you can also use the non compiled code such as ,.m,.mm,.c and .cpp.
There is no support for .obf. If you want to add it to your project so that you can load and execute it then you are out of luck.
If you just want to make Unity include it to your final project build so that you can read it then you can. This doesn't mean you can load and execute it.
First, rename the extension from ".obf" to ".bytes". Place it in the Resources folder and read it as TextAsset with the Resources.Load function. You can the access the data with TextAsset.bytes.
TextAsset dataAsset = (TextAsset)Resources.Load("YourObfName", typeof(TextAsset));
byte[] data = dataAsset.bytes;
Not sure how helpful just reading it is but this is here to show you how to include it to the build and read it but you can't execute it unless there is a C# API to do so and I don't think that any API of such kind exist.
I'm using the Google Eclipse Plugin for GWT development.
To do the configuration stuff there's a folder .settings with two files
com.google.gdt.eclipse.core.prefs and com.google.gwt.eclipse.core.prefs.
These files are a kind of propertie-files.
Now I'm trying to set two different directories for source and output files.
But I can't find any documentation about these files.
What I got till now is this.
eclipse.preferences.version=1
jarsExcludedFromWebInfLib=
lastWarOutDir=myoutputdirectory
warSrcDir=war
warSrcDirIsOutput=false
But using this, at compilationtime it opens a filechooser-Dialog on myoutputdirectory every time, waiting for confirmation.
So I ask, is there a solution to setup a different outputdirectory or does anybody know where I can find more Information about the usage of these setting-files.
My version of that file has an absolute path to the lastWarOutDir.
Maybe it keeps prompting you because it can't find myoutputdirectory (or maybe you just changed it for privacy's sake here).
In any case, if you right-click on the project > Run As > Run Configurations, go to the (x)= Arguments tab and you will see the -war argument containing the value of lastWarOutDir.
If you want to be prompted so that you can change the directory, you could delete all of the arguments, forcing the Google plugin to reconfigure.
I hope that helps. If not, please let us know what you really want to do here.
Maybe I misunderstand your problem. But why don't you just tell the GWT compiler where to output the files using the -war (-workDir, -gen and -extra) command line option? Same thing works for the GWT development mode...
http://code.google.com/webtoolkit/doc/latest/DevGuideCompilingAndDebugging.html#DevGuideCompilerOptions
http://code.google.com/webtoolkit/doc/latest/DevGuideCompilingAndDebugging.html#What_options_can_be_passed_to_development_mode
I'm interested in Qooxdoo as a possible web development framework. I have downloaded the SDK and installed it in a central location on my PC as I expect to use it on multiple projects. I used the create-application.py script to make a new test application and added all the generated files to my version control system.
I would like to be able to collaborate on this with other developers on other PCs. They are likely to have the SDK installed in a different location. The auto-generated files in Qooxdoo seem to include the SDK path in both config.json and generator.py: if the SDK path moves, the generator.py script stops working. generator.py doesn't seem to be too much of a problem as it looks in config.json for an updated path, but I'm not sure how best to handle config.json.
The only options I've thought of so far are:
Exclude it from the VCS, but there doesn't seem to be a script to regenerate it automatically, so this could be dangerous.
Add it to the VCS but have each developer modify the path line and accept that it might need to be adjusted whenever changes are merged.
Change config.json to be a path and a single 'include' line that points to a second file that contains all the non-SDK-path related information.
Use a relative path to the SDK and keep a separate, closely located copy of the SDK for every project that uses it.
Approach 1 would be ideal if the generation script existed; approach 2 is really nasty; I couldn't get approach 3 to work and approach 4 is a bit messy as it means multiple copies of the SDK littered about the place.
The Android SDK seems to deal with this very well (using approach 1), with the SDK path in its own file with a script that automatically generates that file. As far as I can tell, Qooxdoo puts lots of other important information in config.json and the only way to automatically generate that file is to create a new project.
Is there a better/recommended way to deal with this?
As an alternative to using symlinks, you can override the QOOXDOO_PATH macro on the command line:
./generate.py source -m QOOXDOO_PATH:<local_path_to_qooxdoo>
(Depending on the shell you are using you might have to apply some proper quoting of the -m argument). This way, every programmer can use his locally installed qooxdoo SDK. You can even drop the QOOXDOO_PATH entry from config.json to enforce this.
We work with a symbolic link pointing to the sdk ... config.json contains just the path of the link.
Problem: Using genstrings to create Localizable.strings files from a project. A few weeks later, some things changed and I run genstrings again. 75% of the new file is already in the old file. How could I merge the new file with the old file, so that the old file contains all of those 25% new key-value-pairs?
I recommend Localizable Strings Merge too. I use it on my projects and it really a simple to use and powerful software.
I just found the Localization Suite. Incredible powerful tool for free. I tried it on my project and it just works. Lacks documentation though.
I use a script to run genstrings with existing translations merged automatically when I build a project. Updated strings are detected by git or another source control you use. The script supports storyboard and xib localization too.
To run the script automatically, put the script into your project root directory, and add a Run Script phase with the following line to a target build phases in your project settings.
./mergegenstrings.py PathToSourceDir
My script is based on the script in this post. I modified it to support Swift and to add the arguments.
What about 3rd party applications like BBEdit? After all Localizable.strings file is a text file. BBEdit has a find differences feature and you can merge from old to new or opposite.
If you install XCode, there is also a standard application installed to merge files called FileMerge.app, you can find it in /Developer/Applications/FileMerge.app
I'm not sure but ReSharper may help you. teake a look at it.
I'm trying to get glew to work under eclipse (mingw) in windows. Seems as if it is extremely unusual not to use Visual Studio in this context. The install instructions for glew is simply "use the project file in build/vc6/"...
The glew readme also writes:
"If you wish to build GLEW from scratch (update the extension data from
the net or add your own extension information), you need a Unix
environment (including wget, perl, and GNU make). The extension data
is regenerated from the top level source directory with:
make extensions"
In order to get glew to work in eclipse and windows I have to compile it in a unix environment? Is there no other way?
Sure, it would probably be a learning experience to pull that off (if I were to succeed) but I feel that my time is best spent actually working on my project. And even if I did manage to crosscompile everything, would it work in anything but Visual Studio?
Is the whole thing unfeasible and the best solution is to install Visual Studio?
Google haven't been of much help, I feel like I am the only one that has ever attempted to do this (is there a good reason this?).
Well if you still require some flexibility that the VS compiler doesn't always hold, you could try downloading the glew source zip file (on their main sourceforge page). Saying you have to have a Unix environment in order for it to work with eclipse is a huge mistake, as I have it working with MinGW at the moment. Just download the source, extract it, and create/put this batch file into the directory with "Makefile":
#echo on
set SYSTEM=mingw
set GLEW_DEST=C:\...[where you extracted it to]...\glew-1.7.0\usr
path = %PATH%;C:\MinGW\msys\1.0\bin;
make all
make install.all
pause
Change ...[where you extracted it to]... to the path you extracted the downloaded source zip to. Save that and run it, and you should see a "usr" folder containing all the dlls, libs, and headers you'll need. Copy those over to their respective OpenGL counterparts (or just anywhere where you'll be able to specify them in Eclipse later).
Now, in Eclipse, make a new project and at least be sure to include this somewhere:
#ifndef GLEW_STATIC
#define GLEW_STATIC
#endif //GLEW_STATIC
#include <Windows.h>
#include <GL/glew.h>
#include <GL/wglew.h>
If you put the glew headers somewhere besides the OpenGL headers, you may not have to use GL/. Now include the libraries by going into Project->Properties->C/C++ Build->Settings->Tool Settings->MinGW C++ Linker->Libraries and add the following libraries:
glew32
opengl32
glu32
glew32.dll
Add any library search paths you'll need. In my case I just used "C:\MinGW\lib" as a second measure.
Now save all your project files, use Project->Clean..., and build your project. If you don't get any glew errors and your project is prepared you should be able to run it.
Hope that works! It did for me.
Try the following:
Download the Windows 32-bit binary for GLEW here: http://glew.sourceforge.net/index.html
Follow the instruction to link your project to GLEW: http://glew.sourceforge.net/install.html
Make sure your Eclipse is also setup to compile with mingw. (I assume you've done this.)
cout << "Hello world!";