I downloaded Gurobi and verified that my license is working.
I'm trying to add the Gurobi package to Julia, but it seems that the dll file can't be found, even though my GUROBI_HOME variable is okay.
Here is the output of Pkg.build("Gurobi") :
Found GUROBI_HOME = C:\gurobi902\win64
Does this point to the correct install location?
on Windows, this might be C:\Program Files\gurobi810\win64\
alternatively, on Windows, this might be C:/Program Files/gurobi810/win64/
on OSX, this might be /Library/gurobi810/mac64/
on Unix, this might be /home/my_user/gurobi810/linux64/
Note: this has to be a full path, not a path relative to your current
directory or your home directory.
We're going to look for the Gurobi library in this directory:
C:\gurobi902\win64\bin
That directory has the following files:
C:\gurobi902\win64\bin\grbcluster.exe
C:\gurobi902\win64\bin\grbgetkey.exe
C:\gurobi902\win64\bin\grbprobe.exe
C:\gurobi902\win64\bin\grbtune.exe
C:\gurobi902\win64\bin\grb_ts.exe
C:\gurobi902\win64\bin\gurobi.bat
C:\gurobi902\win64\bin\gurobi.env
C:\gurobi902\win64\bin\gurobi90.dll
C:\gurobi902\win64\bin\Gurobi90.NET.dll
C:\gurobi902\win64\bin\Gurobi90.NET.XML
C:\gurobi902\win64\bin\gurobi90_light.dll
C:\gurobi902\win64\bin\GurobiJni90.dll
C:\gurobi902\win64\bin\gurobi_cl.exe
C:\gurobi902\win64\bin\pysetup.bat
C:\gurobi902\win64\bin\vslauncher.exe
C:\gurobi902\win64\bin\vswhere.exe
We were looking for (but could not find) a file named like
libgurobiXXX.so, libgurobiXXX.dylib, or gurobiXXX.dll. You
should update your GUROBI_HOME environment variable to point to the
correct location.
Have you tried to look for the specific dll in your hard disk and update the GARUBI_HOME accordingly, as per error message? Did you double-check that this specific dll exists on that folder?
Related
I'm looking to compile OCCT 7.5 in Windows 10 (x64 via VS2019) for use with FreeCAD, to enable exporting glTF files, which requires RapidJSON support (in OCCT). I've checked out OCCT 7.5.3 and RapidJSON 1.1.0 from their git repos, then grabbed the FreeCAD libpack 12.5.2 (for OCCT 7.5). I started from FreeCAD's build docs, then attempted to follow OCCT's build docs.
When configuring the OCCT project in CMake-GUI, I've been able to find what I think are correct values for some variables (e.g. those regarding FREETYPE) within the FreeCAD libpack, as well as RapidJSON, but still get some errors in the config, seemingly no matter what values I try:
Could not find headers of used third-party products:
3RDPARTY_TCL_INCLUDE_DIR 3RDPARTY_TK_INCLUDE_DIR
...
Could not find DLLs of used third-party products: 3RDPARTY_TCL_DLL_DIR
3RDPARTY_TK_DLL_DIR
I've tried using *.lib, *.h and *.dll files found within the FreeCAD Libpack (and their corresponding directories) for *_LIBRARY/INCLUDE/DLL variables, but nothing is found. I see
Info: TCL is used by OCCT
Could NOT find Tclsh (missing: TCL_TCLSH)
even though tclsh86t.exe exists in the libpack/bin directory.
What should the 3RDPARTY_TCL_* & 3RDPARTY_TK_* CMake variables be set to, to use the FreeCAD libpack?
The problem was my lack of familiarity with CMake and Cmake-gui: the gui opened a dialog for a FILEPATH when specifying a PATH variable. I naively thought, "I don't know CMake, so I'll trust the gui". Totally wrong.
I manually edited the 3RDPARTY_* variable entries to point to the correct directories (or libs, when needed) in the FreeCAD libpack, using the variable name and description/hint for each to determine what the variable's value should be. Below are my entries, for reference:
I did need to check "Advanced", to edit the FREETYPE_LIBRARY_DEBUG & FREETYPE_LIBRARY_RELEASE variables (CMake set them to separate libs found in a jdk directory, presumably because it was added to the system path at some point).
I am using an API called Piepan, which allows me to write Lua scripts for Mumble bots. For context, it is written in Golang using an alternative mumble implementation called Gumble. Piepan scripts are executed via cmd prompt through a piepan.exe.
I can require most libraries, like inspect.lua, and I can easily require luasocket in non-piepan scripts (scripts executed via lua.exe), but if I try to require luasocket (or what I really want, a redis library that depends on luasocket), I get an error. This is less of an error and more of a missing feature from the API, which the creator acknowledges. The creator suggests to someone else with this problem that they simply use Gumble, but I cannot do that as I am only a Lua programmer.
Here's the code of me just trying to require luasocket:
local socket = require ("include-test.socket")
(I've also tried include-test.socket.core and just socket.core)
In accordance with this stackoverflow answer, I moved my files to resemble the user's own directory, so it looks like this:
Piepan folder
-piepan exe and dlls (not luasocket dlls)
-include-test (folder)
--Script for piepan
--socket.lua
--socket folder
---core.dll
Despite the directory looking how I imagine it should based on other users' Q/As, I get this error:
.\include-test\socket.lua:13: module socket.core not found:
no field package.preload['socket.core']
Lstat : The system cannot find the path specified.
GetFileAttributesEx .\socket\core.lua: The system cannot find the path specified.
GetFileAttributesEx C:\Users\Michael\piepan\lua\socket\core.lua: The system cannot find the path specified.
GetFileAttributesEx C:\Users\Michael\piepan\lua\socket\core\init.lua: The system cannot find the path specified.
GetFileAttributesEx C:\Program Files (x86)\Lua\5.1\lua\socket\core.luac: The system cannot find the path specified.,
I've also tried including the following line, inspired by this stackoverflow answer.
package.cpath = package.cpath .. ';include-test/?.dll'
to no avail.
I am looking for any available solution, whether that be moving around dlls or compiling the original Piepan w/ extra files as needed.
(To clarify, I need a workaround that allows me to require the redis library within the same script I run through piepan. Using an outside script with the redis library to then, say, launch piepan and do something there, is not helpful to me.)
I am trying to make a naoqi package with qipkg (I dont know if this problem is specific to aldebaran naoqi or if it is a general windows problem)
qipkg make-package Pepper-Demo.pml
but I get the folowing error:
NotInPath Could not find executable: lrelease
qipkg deploy-package is working as it should.
I solved it with the folowing steps:
Check if there is a .exe file called lrelease in the folder at:
C:\Program Files (x86)\Softbank Robotics\Choregraphe Suite 2.5\bin
If not, search for the file on your computer using search in file explorer.
The error message displayed in which folders it searched for.
Go to the first folder it searched in (or create it) and paste the lrelease file.
After wasting some time to figure out what goes wrong, I finally have to ask for help. I want to use appledocs from Gentle Bytes. I followed every step of the quick install guide, but I´m not able to compile the project.
Here is what I´ve done:
1. cloned it from git://github.com/tomaz/appledoc.git
2. installed the templates to ~/Library/Application Support/appledoc
3. tried to compile the project
Everytime I try to compile, I get following error:
ERROR: AppledocException: At least one directory or file name path is required, use 'appledoc --help'
What do I have to do now?
Sounds like you've compiled it just fine and are now running the program. If it's a command-line program try command-option-R in Xcode to provide some arguments (i.e. names of files that you want to process).
The error means you didn't give it source paths: after all switches, you must give it at least one path to your source files. Can be either file or directory. In later case it will recursively scan the dir. Here's example
appledoc <options> ~/MyProject
Above example will use ~/MyProject directory as a source. You can also add multiple source paths. Note that you need to give the tool few options, see this page for minimum command line and other usage examples.
You either have to copy appledoc executable to one of directories in your path, as suggested by Caleb, or use full path to it when invoking (for example: /path/to/appledoc)
In a .LST file for my VB6 installer there are two lines as follow:
File1=#VB6STKIT.DLL,$(WinSysPathSysFile),......
File2=#wshom.ocx,$(WinSysPath),.....
After installing my application, I found out that both go to the same \Windows\System32 folder. Do you know what is the difference between both paths?
Thanks
This dates back from VB4, I think, a version that could still generate 16-bit executables. Where the system directory was c:\windows\system, the synonym of $(WinSysPath). $(WinSysPathSysFile) is c:\windows\system32. There should be no difference on a 32-bit operating system, but worth a check. wshom.ocx really does belong in system32. It is already there on any recent operating system.
They both go to the same system folder (The windows folder if it's not writable). The latter just marks it as a system file so it's not uninstalled.
Snippets from Setup1.bas in the PDW:
fSystem As Boolean 'whether the file is a system file (i.e. should be installed but never removed)
If InStr(strInitialDestDir, gstrWINSYSDESTSYSFILE) Then
sFile.fSystem = True
End If
Case gstrWINSYSDEST, gstrWINSYSDESTSYSFILE
strResolved = gstrWinSysDir