How to change the version of python that pyscripter uses - pyscripter

I am a newb with python and just learning what to do.
I am using pyscripter and have been for a while whilst learning.
I am now going through an online course which is taught in 2.6, yet my pyscripter uses the latest.
I need to know how to change it to use an older version, I have seen replies about changing the PATH variable but not where it is or how to do it.
I have 3 versions of python on my machine, 25,26 and 33.

I don't know if this is the best way to do it, but those are the two ways I did it:
WAY 1 (The best of two)
Go to PyScripter>>Tools>>Options...>>Custom Parameters... and add the following values
1. PythonDir = C:\Program Files\CustomPythonInstallation
2. PythonExe = C:\Program Files\CustomPythonInstallation\python.exe
3. PythonVer = 3.3.3
Note: Adapt the Name = Value pairs above to your case.
And close the window with OK button.
Now select PyScripter>>Run>>Python Engine>>Remote and your are ready to go.
WAY 2 (The more temporary solution)
Go to PyScripter>>Run>>Configure External Run...
set the "Application:" field to your python.exe file
Close the window with OK button.
Make sure you run your scripts with PyScripter>>Run>>External Run (Alt+F9)
I hope this helped, good luck.

The easiest way I know (on Windows) is, having used the installer executable, I select from the Start menu's PyScripter folder whichever version of Python I want to run.
You can modify the PYTHONPATH (under Pyscripter>>Tools, for instance)
You can modify your External Python Interpreter with Pyscripter>>Modify Tools>>Python &Interpreter>>Modify
You can modify the default Python engine used with Pyscripter>>Options>>IDE Options>>Python Interpreter>>Python Engine Type

You can simply redirect Pyscripter to see the environment of a different Python distribution.
In Windows, do this by assigning PYTHONDLLPATH in the Pyscripter shortcut. You can r-click on the shortcut, access its properties and then set the target to:
[Pyscripter executable dir] --PYTHONDLLPATH [Python distribution dir]
See this image to help you out:
setting a shortcut target
For example, in my Win10 64-bit computer I have a Python 2.7.8 installation back from when I installed ArcGIS, which is automatically recognized by my 32-bit Pyscripter installation.
In the same computer, I also have Anaconda installed with two environments that feature two 64-bit Python distributions:
2.7.14 in "C:\ProgramData\Anaconda2"
3.6 in "C:\Users\bouzi\AppData\Local\conda\conda\envs\py3"
When I installed a 64-bit version of Pyscripter, that Pyscripter version couldn't even open, as it couldn't find the conda distributions. I had to point them to it by replacing the shortcut target to:
"C:\Program Files\PyScripterx64\PyScripter.exe" --PYTHONDLLPATH "C:\ProgramData\Anaconda2"
You can create three Pyscripter shortcuts that point to these different installations of Python within your system. It's probably not the optimal way to deal with this but it works, and allows you to combine Anaconda environments with Pyscripter.
You can also read more on opening non-standard python distributions with PyScripter from this link.

Run->Python Versions -> setup Python Versions -> Add... select folder
p.s.
python 3.7.3 - ok,
still python 3.10.5 could not be identified by PyScripter in such a way (actually works with WAY_1 Solution in this thread but pip install under such env. not succeed afterwards)

Related

Use Lua sandbox with MediaWiki under Windows

I am running a MediaWiki (1.34.1) on a Windows server. The wiki contains some Lua modules which are executed by the Scribunto extension running Lua 5.1.4.
Up to now I am using the luastandalone but I would like to use the luasandbox engine (should be faster).
With the lastest PHP luasandbox release 4.0.2 PECL provides a Windows DLL (https://pecl.php.net/package/LuaSandbox/4.0.2/windows).
With this DLL is it possible to run luasandbox under Windows?
How can I install/configure the PHP/MediaWiki/Scribunto environment to use this DLL?
Yes, it is possible to use LuaSandbox under Windows with IIS, and is in fact an especially convenient way to do so, You simply install the necessary Lua binary as a PHP extension into your existing PHP interpreter (which you know is working, because MediaWiki is implemented in PHP).
I discuss this at some length in this conversation on the MediaWiki page Extension Talk:Scribunto but I'll provide the essentials here as well:
I did finally get Lua working under IIS on Windows 10, with PHP 8.0. The trick was, I abandoned the luaStandalone binary entirely, and instead downloaded the (just released less than 2 months ago) PHP luaSandbox extension from PECL:
https://pecl.php.net/package/LuaSandbox
Click on "DLL", then choose the build that matches your PHP install (for me it was PHP 8.0, x64, non-thread safe — the details are at the very top of the long, long output of php.exe -i from a command line), and download the provided zip file. After extraction, only two files are important:
php_luasandbox.dll, a PHP extension module that goes wherever the rest of your extensions are. (For me, C:\Program Files\PHP\v8.0\ext\.)
lua5.1.dll, an embeddable Lua interpreter that gets installed in the directory where the php.exe binary lives. (For me that was C:\Program Files\PHP\v8.0\, the parent directory of the extension location).
After that, just edit your php.ini to add:
extension=php_luasandbox.dll
and edit LocalSettings.php to include:
$wgScribuntoDefaultEngine = 'luasandbox';
(making sure to remove or comment out any lines about luaStandalone).
Relaunch IIS, and that should be that. If you have MediaWiki working at all, you've already got PHP running, so using Lua that way, as a PHP extension, just makes eminent amounts of sense.
As I note in the MediaWiki discussion, there's some degree of controversy over this because the Lua developers themselves are sort of down on the notion of a "sandboxed Lua". They do not believe it to be a technically viable method of restricting Lua's access to and consumption of system resources. But on Windows, most of the restrictions they recommend imposing on the standalone binary are not available from the OS anyway, making the situation even more confusing/unclear.

Yeoman. The filename, directory name, or volume label syntax is incorrect

Reinstalled Windows 10 (Version 10.0.14393). Reinstalled the following:
Java
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
nodejs (v6.9.5)
NPM (3.10.10)
Yarn (v0.19.1)
Yeoman (installed with yarn global add yo)
When I write yo -v in cmd in any folder, runned with administrator or not, I take:
The filename, directory name, or volume label syntax is incorrect.
UPDATE:
The only workaround I found is to use the full path of yo:
C:\Users\<username>\AppData\Local\Yarn\config\global\node_modules\.bin\yo.cmd
It may be that your PATH does not point to global NPM modules yet. The FAQ and links are more helpful for gnu/linux or mac users. The PATH is a list of the places that your operating system checks whenever you type a command.
Since you are using Windows, to add the modules path temporarily (just for one session) at the prompt, just type (obviously use the correct path with your correct username and please take note of the ; separator character):
path = %path%;C:\Users\<username>\AppData\Local\Yarn\config\global\node_modules\.bin\
You should then be able to run 'yo -v' without pointing to the full path name, since the console now knows to check that folder also. If that works for you, you can add that path permanently using the instructions described on another SO post here.
Finally (and this is only slightly related to your question), since i notice you've got the Windows 10 anniversary update, if you have Linux experience, you may prefer to use "Windows subsystem for Linux", which is a bash shell (Ubuntu 14) on Windows, that you can use instead of the default command prompt. You can find it under "Add / Remove programs --> Turn Windows features on or off --> (scroll right down) --> Windows subsystem for Linux (beta)". Your local file system will be at "/mnt/c" so you can get to it from within the shell or from windows explorer. I've had fewer problems using this and since so many tutorials are written with bash (not command prompt) in mind, it's useful to use it instead of cmd.
You'll need to install dependencies in the usual way using apt-get (as it won't use the ones you've installed on the windows side) and you'll need to prefix commands that make system changes with 'sudo'. e.g.
sudo npm -g modulename

dxgettext and Windows 10

Has anyone got dxgettext running under Windows 10?
I installed dxgettext from the offical homepage under Windows 10, which worked fine.
But whenever I try to run some of the installed tools (e.g. msgfmt.exe), they don't really run, but call themselves again, generating thousands of processes and making the system crawl.
This is what happens:
I call msgfmt --help
the executable msgfmt hangs, blocking the command window
in the TaskManager I see houndreds of msgfmt.exe processes popping up
I think, I have to replace the gettext tools of the dxgettext package with some newer version but before trying to figure it out I first wanted to ask if someone else experienced similar problems and found a working solution.
My questions:
Has anyone got the tools coming with dxgettext running under Windows 10?
What steps have been necessary to get it to run?
I resolved the problem in the following way:
I downloaded https://github.com/mlocati/gettext-iconv-windows/releases/download/v0.19.8.1-v1.14/gettext0.19.8.1-iconv1.14-static-32.zip from https://mlocati.github.io/articles/gettext-iconv-windows.html
I replaced the following files from the installation directory of dxgettext with files from the zip archive:
msgattrib.exe
msgcat.exe
msgcmp.exe
msgcomm.exe
msgconv.exe
msgen.exe
msgexec.exe
msgfilter.exe
msgfmt.exe
msggrep.exe
msginit.exe
msgmerge.exe
msgunfmt.exe
msguniq.exe
xgettext.exe
Result:
Dxgettext and the tools, I use, seem to work fine. I found no problems with my workflow so far, with one exception:
If I use assemble to embed mo-files into an exe compiled with JvGnugettext.pas, I get the following error:
Pach code “6637DB2E-62E1-4A60-AC19-C23867046A89” was not found in .exe file. Are you sure the .exe file has been compiled with the correct libraries?
This may not be related to the original problem. However, it is resolved by replacing the original assemble.exe with the version from https://sourceforge.net/p/dzlib/code/HEAD/tree/buildtools/trunk/ (see answer by #dummzeuch).
The installer on the official home page is pretty old. Last time I looked it contained several outdated dlls and executables from the original gnugettext project that did not work correctly under recent Windows versions. You could take those from my buildtools repository on OSDN. These work for me. No guarantee that they work for you though.
https://osdn.net/projects/dzlib-tools/scm/svn/tree/head/buildtools/trunk/
I've been having these issues too with dxgettext 1.22, in Windows 10 1607. I changed some DLLs at first but kept having the bash.exe looping and hogging my PC to death.
So what I did was basically install latest Cygwin 32bit and replaced the appropiate DLLs. I kept the ones for gettext. Instructions:
Download and fresh install dxgettext-1.2.2.exe from http://dxgettext.po.dk/download as admin. Restart.
Download Cygwin 32bit from https://cygwin.com/install.html in a different folder from dxgettext (I took the default, c:\cygwin)
Run setup-x86.exe and select "Base" Package (Install). Next, Select Required packages just in case.
Move the following files from dxgettext folder to a backup folder (we'll use some DLL later):
cyg*.dll
bash.exe
Copy from c:\cygwin to the dxgettext folder the following files:
bash.exe (set to run as admin)
cygwin1.dll
cygiconv-2.dll
cygintl-8.dll
cygreadline7.dll
cyggcc_s-1.dll
cygncursesw-10.dll
Recover the file(s) below from the backup folder (See #4) and copy to the dxgettext folder.
cyggettextsrc-0-14-1.dll
cyggettextlib-0-14-1.dll
cygintl-3.dll
Running like this, you might get error 740 (requires elevation). So: Set ggmerge.exe,ggfmt.exe to run as admin
** EDIT** Found online this very interesting link, from a programmer who offers a free backup written in Delphi. The good thing is he adapted the dxgettext tools to run in Windows 10. This helped me a lot.
http://personal-backup.rathlev-home.de/translate.html

How to get color in Windows gitbash using bundle exec rake test

I am following Rails Tutorial. I am on section 3.7.1 and I am trying to get color in my gitbash command prompt when running bundle exec rake test. I have tried installing ansi, the win32console gem and the gem called turn and nothing seems to work.
Is it even possible to get red and green colors when running bundle exec rake test?
You definitely can get colored output to show up. But not with using the standard Windows cmd.exe or powershell. Gems won't help. You need to need add the ability to correctly interpret ANSI escape codes to your system -- something that cmd and powershell aren't able to do. (ANSI.sys was how ANSI escape codes were handled under DOS. cmd and powershell don't use it.)
You need to (1) install ANSICON and/or (2) install and use a different console/console emulator or shell that handles colors (ANSI escape codes).
(1) ANSICON is a program for Windows that interprets ANSI escape codes so that color is displayed. It kind of runs 'on top of' cmd or powershell. You can set it up so that it's always used whenever you use cmd or powershell, or use it only at specific times. Most people install this and are really happy with it.
Jason Karns wrote a blog post about installing and using ANSICON for git bash (on Windows) that folks have found helpful.
(2) Here are the popular options for alternatives to cmd/powershell. These are console emulators and tools and shell alternatives:
ConEmu - ("ConEmu-Maximus5") This is a console emulator, not a shell. You can use it with any shell (cmd, powershell, cygwin, bash, etc). But in day-to-day use, once you set it up, you use it just like you'd use cmd.exe or powershell, etc. (I use this so know more about it than the other choices. I have configurations for it to start up with different git/ruby version/rails version configurations as needed. I don't use ANSICON because I use ConEmu whenever I need to open up a console.)
Console 2 - Like ConEmu, this is a console emulator that adds functionality above and beyond cmd.exe (including displaying ANSI colors). You can use it with existing shells (e.g. powershell, etc.) Here's a SO answer that talks about using Console 2.
Console Z - a fork of Console 2 that is current and actively maintained. I haven't ever used it, but here is some info on how you'd configure Console Z to work with git bash.
You can also (or instead of) use a Unix-like shell (or suites):
Cygwin is the best known suite of Unix-like commands that runs in Windows. Comes with shells (e.g. MinTTY) that can be used and will work with ANSI codes
Babun A windows shell that sits on top of a cygwin install. Configurable; you can create configurations (e.g. for git bash or rvm or whatever) and share them as plug-ins. (Uses the mitty console.)
MinGW - A "Minimalist GNU for Windows" that has a GNU toolset for windows, focused on those tools needed for development. (IOW, it's a smaller and slightly different set than Cygwin provides.) DevKit, used to complie ruby gems into native windows code, uses MinGW.
MinSYS - "[A] contraction of "Minimal SYStem", is a Bourne Shell command line interpreter system. Offered as an alternative to Microsoft's cmd.exe, this provides a general purpose command line environment, which is particularly suited to use with MinGW, for porting of many Open Source applications to the MS-Windows platform; a light-weight fork of Cygwin-1.3, it includes a small selection of Unix tools, chosen to facilitate that objective." (From the MinGW site:)
Some searching might turn up additional options. These are the options most talked about and used (based on talking with others IRL, StackOverflow, and doing searching now and previously.)
Install and set one of those options (it won't take long), and then you'll be all set to see the helpful colors used by RSpec or git or whatever.

How to change pyscripter to use Python installed in non-standard directory

I'm trying configure PyScripter 2.5.3 to use a version of Python that is installed in a non-standard install location (i.e., c:\MyProj\Python27).
NOTE: I also have ActivePython 26 and 27 also installed, in the default locations c:\python26 and c:\python27)
I have a short program that simply dumps the python path to verify that I have the correct version:
import sys; print( "\n".join(sys.path) )
When I'm using the "desired version", I'll see "c:\MyProj\Python27\lib" show up on the path.
I've looked at several postings (one is How to change the version of python that pyscripter uses) and most just say the defaults work and the defaults do work. I'm trying to use a non-default directory.
I've used Tools | Configure Tools to set the Python Interpreter, and Command Prompt to run "MyProj" version of python.
So Tools | Python Interpreter, starts c:\MyProj\Python27\python.exe
Also Tools | Command Prompt, starts c:\MyProj\Python27\python.exe version.
But I can't get the Python IDE to use the desired version when I use "Run | Debug (F9)".
I've configured Tools | Options | IDE Options | Python engine type = peRemote.
I've also tried internal.
I've tried starting PyScripter from the command line with the following options (none of these examples worked)
...\PyScripter.exe --python27 --pythondllpath=C:\MyProj\Python27
...\PyScripter.exe --python27 --pythondllpath=C:\MyProj\Python27\python27.dll
...\PyScripter.exe --python27 --pythondllpath C:\MyProj\Python27
...\PyScripter.exe --python27 --pythondllpath C:\MyProj\Python27\python27.dll
I've tried having only my version of python on the windows PATH (removing c:\Python27)
set PATH=C:\MyProj\Python27;%PATH%
...\PyScripter.exe
This has also failed to work.
Has anyone had success at using a non-standard location? If so what steps were followed?
I don't know if this is the best way to do it, but those are the two ways I did it:
WAY 1 (The best of two)
Go to PyScripter>>Tools>>Options...>>Custom Parameters... and add the following values
1. PythonDir = C:\Program Files\CustomPythonInstallation
2. PythonExe = C:\Program Files\CustomPythonInstallation\python.exe
3. PythonVer = 3.3.3
Note: Adapt the Name = Value pairs above to your case.
And close the window with OK button.
Now select PyScripter>>Run>>Python Engine>>Remote and your are ready to go.
WAY 2 (The more temporary solution)
Go to PyScripter>>Run>>Configure External Run...
set the "Application:" field to your python.exe file
Close the window with OK button.
Make sure you run your scripts with PyScripter>>Run>>External Run (Alt+F9)
I hope this helped, good luck.
I'm using two different pythons, tried to use pyscripter with both, but it kept messing up. My simple solution was to download the standalone pyscripter that doesn't use the registry, put copies into two different directories, then set each up for the different py. You can then right click on their icons and set them to start in the proper directories. You can also make two cmd icons and set them respectively so you have a command line. The command line icon can also be set to start in your working directory, although that's normally one level below python, and if it isn't on the path, you have to type ../python to get it (or use a keyboard macro for that.) This works trouble free.
I did delete both pythons and removed them from the system path just in case pyscripter looked for them. Then I installed 2.7 and set up the first scripter. I installed 34 and set up the second. Oddly, the scripters found the correct py each time - I imagine they go for the highest one. But you can also set that in scripter options. And frankly, it may not be necessary to delete py**. If not deleting them doesn't work you can just make a fresh copy of scripter and try again, since that will be a new standalone. For all I know you can reinstall python on the path once pyscripter is set up for each. I haven't tried that. Fiddle around. You can always make a new copy of the pyscripter standalone directory if things don't work out ;')
The interactions between the registry, the path, and the installed pyscripter just led to too many headaches.
Oh, pyscripter doesn't seem to play well with 3.4 but there's a fixed exe for your 3.4 standalone, here - just replace the 3.4 standalone python.exe with this one:
https://pyscripter.googlecode.com/issues/attachment?aid=7680027000&name=PyScripter-Updated.7z&token=ABZ6GAd40xS88r5vwgY9m8Y18vSFKN8q3g%3A1421517339924

Resources