I'm trying to work through the quick start tutorial of the Zend Framework version 1.8.2, but I'm getting an error when running this code:
zf.sh create project quickstart
error: expecting `'{'' in /Users/andrew/Sites/_library/ZendFramework-1.8.2/library/Zend/Tool/Framework/Client/Console.php on line 63
I'm doing this on Mac OS X 10.4. Is there an error in Zend Tool? or am I doing something wrong? Or is my environment not set up correctly to run this script?
I tried this on my other computer and got
-bash: zf.sh: command not found
I think this one is a separate problem, but not sure what to do
to the second problem:
$ chmod +x zf.sh
or place it to /usr/bin (or where the other executables lives, don't know where it is in OS X)
or use
$ sh ./zf.sh
first problem:
which PHP version do you use? The problem exists maybe at multi interface implementation.
you can still manually create the folder structure that Zend_Tool does, the quickstart guide does give examples of the naming conventions and there are numerous other examples. in order to better understand the framework, doing this manually can be good since your forced to think about the files your creating and how they are used.
Related
I'm trying to get Perl's Finance::Quote module working after MacOS upgrade to 11.4. One of the dependencies is B::Keywords. B::Keywords installation fails a test with this error:
> sudo cpan B::Keywords
[...]
Can't open /System/Library/Perl/5.30/darwin-thread-multi-2level/CORE/keywords.h: No such file or directory at t/11keywords.t line 25
Digging around, I see that keywords.h exists on my system in this location:
/System/Volumes/Data/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Perl/5.30/darwin-thread-multi-2level/CORE/keywords.h
Is there a way to tell cpan (or cpanm, or some other installation tool) where to look for these headers? Or, any other approach to get this working would be welcome.
It seems like they removed the keywords.h from the CORE directory (relative to the path given from $Config{archlibexp}) for the system perl on macOS 10.14, see this bug report.
The reason you are not able to install B::Keywords is due to a failed test 11keywords.t see line 24. Some possible solutions:
Install the module without running the tests (sudo cpan -T B::Keywords)
Submit an issue at the GitHub issue tracker so the author of the module can fix the problem.
Install the module with perlbrew instead of using the system perl (I tested this and it worked fine here).
Since I installed according to the guide here on wsl2 ubuntu 20.04, I've been having errors related to libstc++.so.6, specifically GLIBCXX_3.4.26 not found (required by ...) where ... refers to different files within /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/ ending in .so, .so.1, .so.6 and so on (for instance, when running paraFoam the error would appear with respect to about 20 such files). I am able to successfully visualize the cavity tutorial (in paraview installation on windows).
I could get the errors to go away by doing what the user laborg suggested on Jan 4 for a similar problem with julia (see here), specifically copy libstdc++.so.6 from /usr/lib/x86_64-linux-gnu to /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/.
The questions is whether this copy-paste solution is recommended; will it come back and haunt me later? Is the libstdc++.so.6 from system installation going to be an issue if used in the lib64 folder of openfoam?
An additional info concerning openfoam installation, foamInstallationTest shows *not installed* errors against flex, wmake, gcc, g++, icoFoam and *critical error* for gcc, g++, icoFoam; but I as given here, foamInstallationTest is not meant for installation from the tar file. Openfoam installation seems to be alright based on the running of the cavity tutorial.
ok, please don't do copy past operation to solve this problem. The error means that you haven't installed the pre request libraries in your ubuntu. It seems that you have missed the first step in the tutorial.
It is not recommended but it will not hurt as long as the GLIBC versions returned from this command
strings /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6 | grep GLIBC
are a subset of the GLIBC versions from this command.
strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBC
which was no doubt the case for your Ubuntu setup.
A less risky route would be to redirect the soft link /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6 to point to your other libstdc++.so.6 (that way you retain both versions)
ln -sf /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6
Then, if you hit an issue, you can always reset the link back to its original target. Of course /usr/lib/x86_64-linux-gnu/libstdc++.so.6 is itself a soft link, but you can point to it all the same or you can point to its target.
I believe the issue you are hitting is a derivative of the one mentioned here https://www.cfd-online.com/Forums/main/229027-persistence-glibcxx_3-4-26-not-found.html, which would point towards the fact that it is not an installation error on your part but an issue related to the packaging of the OpenFoam binaries. I agree it would screw up the wsl2 setup owing to the way OpenFoam prepends everything to paths. Of course the safest route is to compile from source using the Ubuntu system's gcc and thereby bypass the ThirdParty.
Seeing as you are using Ubuntu in the WSL instance, could also just install the Ubuntu package directly:
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
This problem comes from this line in the tutorial:
echo "source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc" >> ~/.bashrc
This will point to OpenFOAM's libstdc++ everytime you open a terminal (or start a WSL2 session). If your workflow is not related to OpenFOAM, that can be an issue. If you remove or comment that line in your ~/.bashrc things should get back to normal. You can use nano in WSL2.
nano ~/.bashrc
Then comment:
#source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc
However, as OpenFOAM uses that bashrc, you will need to source the OpenFOAM bashrc in each terminal before using openFOAM.
source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc
My personal choice is to keep that line commented and, if I have a long work session using OpenFOAM, I just use nano to uncomment it, so every shell that I open works without sourcing again.
There are more elegant or complex approaches, but I prefer this one.
This answer should be valid with the 2006 version too, the link you shared points to 2012, so I guess they just updated the tutorial. If you installed 2006, just make sure when you source comment/uncomment to use the correct name.
In the same manner, if you followed another tutorial with another tool and sourced another library, you may experience issues.
Just start by taking a look at your bashrc and cleaning it.
I was using APKTool and have been doing a lot of trials, using all the versions of APKTool. However, upon to my dismay, it won't work. Whenever I use it it will just be:
-bash: ./apktool: No such file or directory
I don't know what to do, as I tried using "./" as what websites are telling me, but still it just gives me this.
What should I do to fix this error. Thanks :)
-----Edit (December 23, 2015)-------
I have found the solution to the problem and it was just a redownload of APKTool itself. It also helped when I gained an understanding of Terminal and the Command Line Tools. I advice you to do the same thing too.
Perhaps you should reinstall apktool. You can find how to do it here:
http://ibotpeaches.github.io/Apktool/install/
Using "./" means that you want to run file located in current folder. Since you mentioned "bash" your apktool should be probably installed in "/usr/local/bin" so when you complete the installation do not add "./" just type "apktool" to run it.
If you want to check where apktool is installed run "which apktool"
or simply use the apktool online: http://www.javadecompilers.com/apktool
No installation - no hassle!
I'm following a guide from The Mathematica Journal that describes how to use Mathematica with the Lego Mindstorms NXT. I have some trouble getting started and got stuck with the SerialIO package.
I use Mac OSX and I have installed the package to:
/Applications/Mathematica.app/AddOns/ExtraPackages/SerialIO/
The command Needs["SerialIO`"] gives me the following error message:
LinkOpen::linke: Could not find MathLink executable.
And trying
SetDirectory[FileNameJoin[{$InstallationDirectory, "AddOns", "ExtraPackages", "SerialIO", $SystemID}]];
Does not help either, it gives:
SetDirectory::cdir: Cannot set current directory to /Applications/Mathematica.app/AddOns/ExtraPackages/SerialIO/MacOSX-x86-64.
There seem to be some problem with the alias/symbolic link in the SerialIO folder. By default they pointed to an absolute directory on the machine that this library was built on:
MacOSX-x86-64 -> /Files/schofield/Packages/SerialIO/Build/Mac/build/Deployment/Package/SerialIO/MacOSX
I tried deleting the alias and creating a symbolic link in the terminal:
ln -s MacOSX MacOSX-x86-64
Running the SetDirectory command again result in... no result, so I guess thats good. The commands seem to have been loaded as when typing Serial it want to autocomplete to SerialOpen etc.
However, using the command mybrick = SerialOpen["name of serial port"] does not put the NXT in connected mode (<> on NXT display). Does anyone else got it to work?
There was a problem in SerialIO in combination with Mathematica9. After some correspondence in may 2013, Wolfram Support find the problem and updated SerialIO for me. It seems logical that they also update SerialIO on their site. Please have a try and download SerialIO again and update. My OS is MaxOSX.
I'm trying to deploy my site using Fabric and Mercurial. In the Windows command line, running hg push works perfectly with no problems.
But when I try writing
local("hg push")
in a fabfile and running it, I get the error:
'"hg push"' is not recognized as an internal or external command, operable program or batch file.
Googling gave me an idea that it might be a problem with the PATH variable in Python subprocesses, for example here: Why would an "command not recognized" error occur only when a window is populated?.
Can you help me out? Is the bug in Fabric or in my own code?
Thanks.
As Chris R mentions, we don't do a ton of Windows support as none of the core devs are Windows users; we have to rely on reports and suggestions from our more savvy Windows users.
It sounds like this could be related to this recently fixed, but not released, bug -- it will be in Fabric 1.0.2 which should be out soon. If you're feeling brave, you can test it out now via:
pip install -e git+git://github.com/bitprophet/fabric#1.0#egg=Fabric
If you then do fab -V, it should say it's 1.0.2a -- if so, running your fabfile may work better. Please let us know if you do this!
It sounds like the you need to add Mercurial to the Fabric process's PATH.
Maybe something like:
fabric.context_managers.path(<path to your hg.exe>)
run('hg push')
See the docs for the path context manager. It wasn't clear if path applies to local commands, but run commands are explicitly referenced.
Neither of the fixes provided worked, but changing
local("hg push")
to
os.system("hg push")
solved the problem.