My environment: win8 64bit, vs2010,
I follow every step in the tutorial but my own dll plugin just can't be installed, I have also installed WiX toolsets and made a msi file, but it simply do not work...
(1) I do all the work with prompt(privileged ) cmd.
(2)My files are shown in below
(3)firefox about:plugins page do not contain my dll plugin after my msi file installed..
(4) failed ..
So what is going on here?
Are you building using the prep2010x64.cmd file (or a different x64.cmd file)? if so, that's likely your issue. Many people, failing entirely to read the instructions on the firebreath website, mistakenly build using the x64 because they're running a 64 bit operating system. thing is, the browsers like firefox still are 32 bit, so the plugin needs to be built 32 bit as well.
The next question, if that doesn't help, is whether or not the regsvr32 command succeeds when you run it on the .dll.
Clarification: You figured this out, but for future readers to be very clear:
Do not use prep2010x64.cmd unless you can explain clearly why you need to -- and running a 64 bit OS does not count. Most people want to use prep2010.cmd (or whichever year).
Related
I have TeXmacs and Octave installed, both working properly otherwise. I have also added the path to octave executable (i.e. C:\Octave\Octave-5.1.0.0\mingw64\bin) to the Windows environment variables and octave runs in cmd/PowerShell terminals and Jupyter with no hassle. However, when running Octave inside TeXmacs through Toolbar > insert > session > octave it gets stuck on Busy..., the same reaction for any other commands as well:
Octave gets stuk on Busy... inside TeXmacs.
This is my environment:
TeXmacs 1.99.9
Octave 5.1.0 (installed through Chocolatey)
Windows 10 version 1809
I would appreciate if you could help me know what is the problem and how I can solve it.
P.S. I have reported this issue in the TeXmacs repo.
#Foad. I wrote an updated Octave plugin for Texmacs. I tried it on Windows, OSX and Linux, works on the systems I have access to. If you are interested to test it, you can download the zipped archive from here https://lists.gnu.org/archive/html/texmacs-dev/2019-12/msg00005.html.
To install it, unzip the archive and copy the octaveX directory in the application plugins folder, alongside all the plugins that come with the standard Texmacs installation. Won’t work if installed in ~/.Texmacs/plugins. If everything goes fine, you should find a new Insert/Session/OctaveX menu (note: I changed the session name). If not, try to refresh the plugin system with the menu Tools/Update/Plugins. If you try it, please let me know, especially if you find troubles. In case I will do my best to fix them.
A fundamental prerequisite is a working octave-cli command in a operating system shell. Should be standard on Linux, may require some additional setup on Windows (environmental variables) or OSX (.bash_profile). You can find some help and more details under the menu Help/Plug-ins/OctaveX.
Concerning the error you found, as far I understand there are some issues with the standard distributed plugin: first, a .octaverc file is missing, so several variables are not initialized, in addition the Windows version calls a not existent file. Moreover the plotting functions are quite old and are not compatibile with Octave newer than version 2 (or maybe 3, anyway a quite old version).
You could try to run the command in
%TEXMACS_PATH%/plugins/octave/bin/tm_octave.bat
from the terminal to see what happens. There is a problem with this plugin and it does not work also on Mac but I do not know enough Octave to fix it. Somehow it does not manage to find the files which are in
%TEXMACS_PATH%/plugins/octave/octave
Please try to modify tm-start.m to look like
d=getenv("TEXMACS_PATH");
if (length(d) > 0)
addpath("tm:polynomial:plot")
tmrepl
endif
In windows, octave should be run using the scripts octave.bat (in the mingw64\bin directory of the octave install) or octave.vbs (in the install directory) for the GUI
You should not run octave.exe directly.
I am currently having an issue with Octave install in Archlinux. I am not able to load the current version of Octave 4.2.1 in Arch. It shows the following message -
/usr/lib/octave/4.2.1/exec/x86_64-pc-linux-gnu/octave-gui: error while loading shared libraries: libgfortran.so.3: cannot open shared object file: No such file or directory
This problem with libgfortran.so.3 is not rare. Here are two similar problems happening in R 1 and 2. If somebody using Octave on Archlinux came across this issue, can you share how to resolve it. Thanks.
From the comments it became apparent that the solution from the referenced question R v3.4.0-2 unable to find libgfortran.so.3 on Arch needs to be appended, because the way the older GCC versions will be typically installed in Arch Linux is in a different path.
So, one must find, where the older version is installed, like
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libgfortran.so.3
(depending on the exact GCC version)
and then add the version to LD_LIBRARY_PATH or make a symlik of the library from the above path to /usr/lib64/.
I got this issue because I installed earlier additionally openblas-lapack from AUR for better octave matrix multiplication performance. Updating openblas-lapack to newest version in AUR did the trick for me.
Windows7 using VS2013 development of a plug-in, and perfect running on ie8, now transferred to Windows XP, ie8 browser can not load plug-ins.
I take the measures:
VS2013 on Windows 7, select the v120_xp, but there is no effect;
Install the XP system, VS2010 in the virtual machine,Run Firebreath demo again,the following error occurred:
Can not open the program database "d: \ firebreath-master \ build \ npapicore \ npapicore.dir \ debug \ vc100.idb"
how can i do?#taxilian
In general, it's not particularly appropriate to call out a specific person to answer a question on stackoverflow. I do monitor this tag, so I see it, but just so you are aware =]
There are three basic reasons why a plugin may not load:
The plugin is not registered correctly
This shouldn't be possible, since firebreath takes care of that for you; can't guarantee that nothing went wrong, of course. The only way to troubleshoot this is to learn how registration works and double check everything.
The plugin DLL has libraries which are not available on the system
This would be my #1 guess as to what is happening; the best way to check is to use Dependency Walker to see what dependencies it has that may not be available; ieshims.dll is a common one to see looking like it isn't there when it works, but most anything else is likely to be a problem. It's quite possible that there are dependencies added by vs2013 that aren't there with vs2010; I'd also verify that the target set in win_common.h in firebreath is correct for windows XP.
The plugin may actually be loading but then crashing immediately.
The easiest way to test this would be to add a call to __debugbreak() early in the plugin lifecycle; this will make it look like it crashed but let you attach a debugger.
If none of that helps I'd recommend using the firebreath-dev google group which is a more appropriate place for a discussion.
I have PHPStorm, but when I'm writing native function (for example str_poss, return, parent...) it very often freeze for about 10 seconds. I have no idea what I'm doing wrong. But it happen to me on Windows7 and on Ubuntu also. Has anyone same trouble? Thanks.
PHPStorm used to "lag" for me before quite often too... but I managed to fix it in the following ways (It did take a bit of tweaking/experimenting though to get it to work! But now it is blazing fast once again!)
Here is what I did to optimize it:
1) If you are on Linux - Make sure you are using Oracle Java on your system, not Open JDK
From: https://intellij-support.jetbrains.com/entries/23455956-Selecting-the-JDK-version-the-IDE-will-run-under it says:
On windows: "JDK is bundled with all the product installers and it's recommended that you will use the provided JDK version unless there are any specific issues.
32-bit JDK is located in IDE_HOME\jre directory and is used by the 32-bit product executable.
To run the IDE in 64-bit mode you will need to download and install 64-bit JDK (not JRE) distribution and install it yourself. IDE will find and use it from the registry when you run the 64-bit .exe file (available only for IntelliJ IDEA right now, other products can use the .bat file to run in 64-bit mode)."
2) Disable any plugins you do not ABSOLUTELY NEED! Especially any 3rd party plugins you may have installed**
GBC from PhpStorm 7 very slow and sluggish on netbook, optimize IDE for responsiveness? also had some insties:
3) Disable language injections: File -> Settings -> Language injections. un-check as many boxes as you're comfortable with. HTML was the real killer for me.
4) Disable inspections: File -> Settings -> Inspections. uncheck as many as you don't need.
I hope this helps!
I am on a mounted VM drive and everytime I was going back to PHPStorm it freezes for 5-10 sec.
Unchecked the box "Synchronize files on frame activation", in Settings > General > Synchronization, seems to solve the issue for me.
PHPStorm 7.1 on Linux
A solution I found which drastically increased my speed without having to disable any plugins or disable inspections (because they are useful - why would you want to disable them) was to enable OpenGL.
First of all go to: path-to-phpstorm\bin\PhpStorm64.exe.vmoptions
Then add these two lines below the others:
-Dawt.useSystemAAFontSettings=lcd
-Dawt.java2d.opengl=true
This helped me to get that 'eye' logo disappear and show a green tick on 6000 line file in 3 seconds rather than 2 minutes. Amazing how much difference it made.
If you're using JetBrains Toolbox, go into the Settings beside PhpStorm and crank up the "Maximum heap size". I find about 3000 MB is good.
If you're not using Toolbox, find and open phpstorm64.vmoptions and add this line:
-Xmx3000m
It does the same thing.
I had the same problem on Ubuntu. The IDE was freezing regularly on two different PCs (Using a desktop pc at home and a laptop at work), both have as OS Ubuntu 18. The freezing time was about 1-2 minutes.
It stopped after I restart IDE with VM-option: -Dawt.ime.disabled=true
Source: https://youtrack.jetbrains.com/issue/JBR-1923
I compiled MySQL++ with no issues. When I launched some of the executables (resetdb.exe and simple1.exe) they suggest to run to test if the installation has been successful, the first error I got was that libmysql.dll was missing.
Adding its path to the PATH environment variable did not fix the problem, even after launching a new command prompt; I had to copy the DLL in the directory where MySQL++ executables are.
Now the DLL is found, but I get this error:
simple1.exe - Application error
The application was unable to start correctly (0xc000007b).
Click OK to close the application.
even launching from the command line, I get no more information than these.
Thank you for any help!
MySQL 5.5 -
MySQL++ 3.0.9 -
Windows 7 64 bits -
MINGW32 -
GCC 4.4.0
0xC000007B is a Windows error that means the executable is corrupted. It could refer either to simple1.exe or to one of the DLLs it's linking against.
Some reasons this could happen:
You're mixing toolchains in an incompatible way. In your case, you may have built simple1.exe using pieces built by MinGW GCC and pieces built by Visual C++. MinGW should be compatible with any pure C DLL built by Visual C++, including the MySQL C API DLL. However, you may have other pieces interfering. MinGW isn't compatible with VC++ at the C++ level, but then, it shouldn't have linked at all if this were your problem.
You didn't follow the MySQL C API import library build steps in README-MinGW.txt. You either missed a step, or skipped it entirely and are trying to use the import library that shipped with MySQL.
In your previous gyrations, you ended up with a corrupt object file, which got linked in. Try saying make clean all at the top level of MySQL++ to force a complete rebuild.
You're mixing versions of MySQL or MySQL++. If you have more than one version of each on the system, make sure you're consistent in their use. That is, build the C API import library from the same DLL you run the programs against, use exrun.bat to run the examples to ensure you're using the just-built version of the MySQL++ DLL instead of another you have in your PATH, etc.
Additionally, I note that you're using an older version of MySQL++. If you were on Linux, I could understand that as some distributions still ship with 3.0.9. But since you have to build MySQL++ from source with MinGW, I don't see why you're not using 3.1.0. Did you get a binary build from somewhere?
As for your PATH problem, did you restart the MinGW shell after doing this? PATH updates don't affect running programs; they keep the value they saw when they started.