I'm trying to get tcl/tk working in Windows 7 64bit. I've followed the readme on the main tcl's website and what I've done so far is run the make file found in the tcl8.6.1 .zip file you can get off of the tcl website. I was able to compile it with the terminal window in Visual Studio C++ 2010 professional. The make file creates a folder inside your downloaded and extracted tcl folder that you can then run and compile tcl scripts from that specific location but from nowhere else. I want to be able to compile and run tcl scripts from any directory since I'll be doing a bit of tcl/tk programming in the near future.
Stuff I've tried:
1. Copying the tclsh86t.dll file + tclsh86t.exe file to system32
2. Editing the TCL_LIBRARY environment variable but it doesn't exist :/
Any ideas?
I figured it out. In Windows:
Open a file explorer
Right click on "computer" select "properties"
Select "Advanced System Settings"
Select "Environment Variables" in the "Advanced" tab.
Edit the "Path" variable to have the location of "tclsh86t.exe" available when compiling the latest version of tcl.
When you re-open your command line, you should be able to use tclsh86t.exe from anywhere. In my case, tcl was complaining that it couldn't find a usable init.tcl file. So, I went and grabbed one from the tcl distribution and put it where it was looking and then it was fine. You can alternatively edit your TCL_Library environment variable to point to wherever it is on your PC.
Related
My problem is with Octave on Windows.
I am trying to open an .m file with Octave GUI, but I don't want to run it immediatly.
Currently, when I do this, an Octave GUI window opens, as a Notepad++ window (which is empty?). This Octave window is already set to the path where my .m file was located.
Then, I have to click on "file-->open...--> myfile.m" to make the code appear in the editor tab. From there I can modify it (some parameters I want to change for example), or launch it directly.
Is there any way to directly get the file opened in Octave GUI (in the editor tab, without having to do "file-->open-->...")? Or a simple script.bat file to configure for doing this purpose?
You must unistall the older version first. Then install the newer one. If you installed newer one first and then uninstalled the older one, then it will not work. So now you must uninstall and reinstall the newer one. Then the following will work.
Select "Microsoft Windows Based Script Host" for .m files.
It is usually located in C:\Windows\System32 and named as <wscript.exe>
GNU Octave - Bugs: bug #47696, Can't set Octave as default app...
--> You have to select "Microsoft Windows Based Script Host" for .m files. Check whether the description changes to "GNU Octave Script".
I recently installed vs15 - preview (Stripped down version of visual studio 2015).
I am able to compile C/C++ sources from inside the IDE, but I am not able to compile with the command line interface cl.exe. It can't find the c stdlib headers. I tried to use vcvars32.bat to set the proper reg values but seemingly it cant find the "Common Tools Folder".
"ERROR: Cannot determine the location of the VS Common Tools folder."
The script uses the env. variable "%VS150COMNTOOLS%".
If I try to run "cd %VS150COMNTOOLS%" from the cmd line, it can't find the path, so this seems to be the main problem.
How can manually set %VS150COMNTOOLS% to the right path? how can I set the cmd linker settings manually (Without telling the cl.exe every time I call it)?
Okay, I solved it by adding the path to the include directories and lib directories to the env. variables as "INCLUDE", "LIB". It works now, whyever the script was not able to set those values properly. I am not fluent in reading .bat let away writing in, I assume the directory structure, which is different for the vs15 preview when compared to the full version, had not been adapted yet.
I want to be able to program LUA in Visual Studio 2013 Ultimate. I have BabeLua to try to do this. In the program there is a tab called settings. Within that tab there are 5 textboxes that I do not understand
LUA Scripts Folder -
Folder where the files are stored? (Documents/Visual Studio 2013/ Projects)?
Lua exe Path
Working Path
Command line
Setting Name
Can someone give me an explanation to all of these Fields?
This prompt seems to be slightly different than the one I am seeing with the latest update of babelua, but regardless:
Lua scripts folder: This should be the explicit path to some file folder where your script is located.
Lua exe path: explicitly provide the path to your exe (which you can download from here.
Note: be sure to download the windows 32 Bit version, even if your machine happens to be 64 bit. There appears to be some sort of bug
that prevents Babelua from running in debug mode with the 64 bit
version.
Working path: I just provide the same path to the folder containing the lua exe.
Command line: This is where you provide the name of the script(s) you want to run. If you wrote a file in your project called "script.lua" you would provide the name of that file, with the extension, in this area.
Lua project name: This is different than the "setting name" prompt you have, but its rather self-explanatory.
Example:
Lua scripts folder: C:\Users\kevin1michael\Documents\LuaScripts
Lua exe path: C:\Users\kevin1michael\Documents\Lua\32BitLua\lua5.1.exe
Working path: C:\Users\kevin1michael\Documents\Lua\32BitLua
Command line: script1.lua
Lua project name: Project1
Using Advanced Installer, I have created and run a simple installer that contains a single .exe.
This .exe started as an executable jar (w/ splashscreen) and was built into a Windows .exe using Launch4j.
Once the application is installed (in C:\Program Files (x86)...), I can't execute it from the installation directory. However, if I copy the .exe to anywhere else, Desktop, or any other directories created by other installers, the .exe will start perfectly.
This appears to be a folder or application permissions issue. Comparing the permissions between this folder and the one created by Advanced Installer, the permissions and settings are identical.
The ONLY difference I see, between the installed .exe and the same .exe copied to another folder, is that the "Edit Permissions" button has an admin shield on it (one originally installed by AI).
Is there a setting in Advanced Installer that will allow my .exe to run once installed, or is this just trickery employed by AI to get you to pay for a more robust version? I am unable to make any changes in the OS that enable this file to run in the directory created by AI.
If the executable fails to run from Program Files but does works from another folder it most probably happens that your EXE needs write access to that folder. If you launch it with the option "Run as administrator" it should work. This is not caused by a limitation from Advanced Installer.
Starting with Vista onward you can embed a manifest file into an executable file, that specifies for the OS the execution level, so you can set the level to "RequireAdministrator", thus your will EXE will always behave as you launch it with the option "Run as administrator" when launched from a shortcut or double-clicked.
The cause of this error was that the target directory included an exclamation mark. "!".
I had switched to using InnoInstaller and it was working in an initial version, until I later switched the target dir to include the exclamation mark, and it was broken in the same way. (Removing it fixed.)
Have no idea why this was causing the problem, just an fyi.
I used Mingw_get_inst and installed the MinGW compiler suite following the instructions on the howto page. I used the GUI installer. I then changed the path to include C:\MingW; . When I go to Start menu -> all programs -> MingW the only file that exists inside of there is a uninstaller. The howto page says a shell should be there... can someone help me get this working?
Howto page on Mingw.org: http://www.mingw.org/wiki/Getting_Started
simply you could run it from the following batch file:
e.g. C:\MinGW\msys\1.0\msys.bat (if you installed your mingw in c drive)
for more info. about mysys, check this
Look at the install logs for your Mingw.
I have 2 bin dirs in my (single) installation of Mingw
C:\MinGW\msys\1.0\bin
and
C:\MinGW\bin
A lot has changed about Mingw in the last 2-3 years and I think some documentation you might find easily via google is out-of-date.
Try asking for help at mingw mail groups via Nabble (very easy to use)
IHTH
Adding the shell link is easy if you have MSYS installed.
Open your Start menu and right-click on "All Program" and choose either "Open" or "Open All Users" depending on which you want to set the shortcut for. Open the MinGW folder if it already exists, or create it (or an MSYS folder, as you wish) if it does not.
Open another Explorer window and navigate to your MSYS folder, in the default installation this is C:\MinGW\msys\1.0
Right-drag msys.bat from the MSYS explorer window to the start menu explorer window. Choose "Create shortcut" when prompted as to what you wish to do. Optionally, you may want to change the shortcut to use one of the MSYS icons from the MSYS folder.
According to older MSYS documentation, the shortcut should be set to start in the MSYS bin folder, in the default installation this is C:\MinGW\msys\1.0\bin. I'm not certain of what happens if you don't do this; the shell opens either way.
Et voilà! You now have a shell link for MSYS in your Start menu.
If you didn't have the shortcut, the other postinstall bits may not have run either. The easy way to check this is to look in C:\MinGW\msys\1.0\etc (or the appropriate path for your installation). If there is an fstab file, then the postinstall bits ran appropriately. If not, then go to C:\MinGW\msys\1.0\postinstall and run pi.bat. This will make the mingw folder available from the msys shell. Things won't work right without doing this.
Update from March 2018: The MSYS postinstall is now a Lua script, and it won't create a shortcut by default. Best I can tell, you now must do so manually in all cases.
Look for the postinstall directory, run the batch file pi.bat in there and
answer the file path questions with the correct case sensitivity.
Then gcc is found.
CNTRL-SHIFT click and drag the msys shortcut onto the desktop.
This fixes it.
Pity the installation script is broken...
Go to your windows search and go to Apps and Features and then search for it, you can find the file location and then you can probably see docs and other files :)