I am having this problem in the image:
even if in the path displayed is correct and exists. I tryed anyway to change this variable and the files in C:\\Program Files\Java\apache-maven-2.2.1 or C:\\Program Files\Java\apache-maven-2.2.1\bin or C:\\Program Files\apache-maven-2.2.1\bin as I read in different forums.
My enviroment variables are set up as follow:
Path=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;%ROO_HOME%\bin;%M2_HOME%\bin;
M2_HOME=C:\Program Files\apache-maven-2.2.1
JAVA_HOME=C:\Program Files\Java\jdk1.6.0_18
ROO_HOME=C:\spring-roo-1.1.0.RC1
Must I do something extra?
Thanks in advance
Try without spaces in the path or between quotes.
M2_HOME="C:\Program Files\apache-maven-2.2.1"
I've not set up M2_HOME nor ROO_HOME at all (only JAVA_HOME) and everything works for me.
Try without them, they might be automatically deduced at runtime?
YMMV: I'm developing in Linux not Windows.
(Edit: of course, you'll need to fixup your PATH if you do that)
Actually, what I did was uninstall and reintall, the old 'trick'.
Worked :s
Related
I am trying to get OpenAI roboschool to run in Google Colab (have a virtual display setup that records the environment during training and displays video after). The roboschool library will import, but the environments don't show up properly (at all), when I run:
import roboschool, gym;
print("\n".join(['- ' + spec.id for spec in
gym.envs.registry.all() if spec.id.startswith('Roboschool')]))
the list is empty, and it should include the environments.
When cmake links dlls, does it do so with environment variables? Environment variables in Colab don't work as usual, and I think that may be the issue. I don't know enough to know for sure.
This output looks suspect to me, doesn't seem right that the runtime path would be removed. There are a number of these so I only grabbed two for example.
-- Set runtime path of "/content/roboschool/roboschool/cpp-
household/bullet_local_install/lib/libBulletDynamics.so.2.87" to ""
-- Set runtime path of "/content/roboschool/roboschool/cpp-
household/bullet_local_install/lib/libBullet3Geometry.so.2.87" to "
Here is the command sequence.
cmake -DBUILD_SHARED_LIBS=ON -DUSE_DOUBLE_PRECISION=1 -
DCMAKE_INSTALL_PREFIX:PATH=/content/roboschool/roboschool/cpp-
household/bullet_local_install -DBUILD_CPU_DEMOS=OFF -
DBUILD_BULLET2_DEMOS=OFF -DBUILD_EXTRAS=OFF -DBUILD_UNIT_TESTS=OFF -
DBUILD_CLSOCKET=OFF -DBUILD_ENET=OFF -DBUILD_OPENGL3_DEMOS=OFF ..
make -j4
make install
Is there a way I can override the way paths are determined for the linked libraries so they will link with the correct paths if that is correct? Seems like looking into RPATH may be a step in the right direction?
Thanks in advance. Please let me know if additional detail is necessary.
Hard to say what's going on without more details, but if you're building .so's to non-standard location that you want the python runtime to see, you have to somehow tell the runtime about the .so's location. Guessing based on the snippets you provided, maybe this (possibly after a runtime restart (ctrl-m-period)) will unblock you:
import os
os.environ['LD_LIBRARY_PATH'] = '/content/roboschool/roboschool/cpp-household/bullet_local_install/lib:' + os.environ['LD_LIBRARY_PATH']
If that doesn't do it for you, two other suggestions are:
Change your configuration to install to "standard" locations
Share a minimal notebook that reproduces the issue.
After I have fixed this warning, how can I make it an error, so it doesn't slip in again?
msbuild /p:TreatWarningsAsErrors doesn't work
No happy answer to give you here. The TreatWarningsAsErrors property only affects the C# and VB.NET compiler (not C++), it determines the value of their /warnaserror command line option.
But MSB3277 is generated by an MSBuild task, ResolveAssemblyReference, its internal LogResult() method generates the diagnostic. The only property the class has that helps treat warnings as errors conditionally is WarnOrErrorOnTargetArchitectureMismatch, not what you are trying to achieve. You can have a look-see for yourself with a decompiler, look at C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.Build.Tasks.v12.0.dll. The resource name for the localized MSB3277 message is "ResolveAssemblyReference.FoundConflicts".
So only way to get ahead here is to write a little utility that parses the log file and looks for the warning.
You can use the generic mechanism MSBuildTreatWarningsAsErrors or <MSBuildWarningsAsErrors>MSB3277</MSBuildWarningsAsErrors> (introduced in #1928) to accomplish this.
credit: rainersigwald
Run Update-Package via Package Manager Console, this will fix MSB3277, what it does it reinstall all the packages and all related assemblies they come with to the highest version possible.
More info on official docs https://learn.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages
It looks like the /warnaserror will promote all msbuild warnings to errors:
TreatWarningsAsErrors vs /warnaserror
I'm trying to get DOH testing working for my company's upcoming platform, but I can't figure out the right combination of paths. Our file structure looks like this:
/dojo15
/release
/dojo
/dojo
dojo.js
dojoExt.js
/dojo
dojo.js
/util
/doh
/js
mainLib.js
/tests
base.js
This was created by our contractors, so unfortunately there are some things I have to figure out as I'm going along.
The "release" directory is what is used on our pages.
The "util" directory doesn't exist in our release directory. (I'd like to avoid having to make a copy of it there.)
I'm not entirely sure what they did with dojoExt.js there, but it seems to be required. I was able to make a simple "hello world" sort of test, but once I did dojo.require(js.mainLib), I got an error that dojo.behavior.add is not a method. So it seems to be they made a stripped-down dojo.js and put other required code in dojoExt.js.
My guess is that DOH is using the dojo in dojo15/dojo, but I need to include dojo15/release/dojo/dojo/dojoExt.js. I've tried every combination of dojoUrl, testModule, registerModulePath I can think of...also saw "boot" and "path" from other SE questions, even though I can't see in runner.html where they would even be used, but I tried throwing them in to see if they'd magically help anyway.
At the moment I don't really have the option to move code around, so I'm hoping to work this out with files where they currently are.
Did you try the bits I suggested over at a related question? We use the bits I detailed there to pull together a completely custom layout of dojo + util. Take a look at both boot and dojoUrl. I think it's runner.js that does most of the cunning stuff, rather than runner.html.
Is the problem that you can't arrange for dojoExt.js to get loaded? How does your other code arrange for it to get loaded? Is tests/base.js your test module?
Some months ago I installed Lazarus 0.9.28 + FPC 2.2.4 to work on a new project. Some time after it I ran into some bugs related with image loading on a TImage. After googling a bit I found some information pointing to the fact that the bugs I was facing were already solved in a later version of FPC (can't remember the link now).
So I decided to download and install a newer version. This was around January and the latest stable version was not released yet, so I choose to install the snapshot Lazarus 0.9.31-29128 + FPC 2.4.2-2011-01-20. I opened my project with the new IDE and compiled it.
Luckily the bugs I faced were gone, but I have run into an IDE (?) one. After the upgrade, when I am on the code tab of some of my forms I do not see the code formatted. Instead I only see plain text, like this:
But on some forms I see the code formatted correctly, like this:
Anyone has run into this before? If yes, could you solve it and how? Or can anyone tell me what the correct way to upgrade a Lazarus project between versions is?
It is more of a nuisance than a real problem but still I would like to solve it. Any help would be appreciated.
EDIT
I noticed that in the forms where the code shows correctly highlighted the LCLVersion in the .lfm file is 0.9.28.2, while in the forms where the code shows like plain text that property in the .lfm file is 0.9.31. Could have something to do with the problem? I tried changing the value but it did not change anything.
Thanks in advance and best regards
I don't know if this is actually causing your problem, but Lazarus keeps a set of settings in application local. ($user\AppData\Local\lazarus on my vista).
This config dir is not erased upon deinstallation, and the new installation will reuse this.
In case of strange problems, remove the config dir, and let the current installation generate a new one.
First, I'm sorry but this is kind of a "give me teh codez" question. I promise to learn from your answers, though! That means that feel free to use the Socratic method if you feel it's necessary.
I'm currently developing (both maintenance and building new ones) multiple sites using Grails and the way it works is that it provides a commandline shell for executing various tasks.
This is all fine and well, but switching between versions is a bit of a nuisance, since it's all controlled by a single environment variable called GRAILS_HOME which is set to point to a directory such as C:\grails\grails-1.2.3\.
Now, what I would like to be able to do that instead of doing something like this:
grails create-app MyWebApp
grails list-plugins -repository=myPluginRepo
grails install-plugin myPlugin
and then noticing that I'm using the wrong version and that I have to go back, I'd rather do
g135 create-app MyWebApp
g135 list-plugins -repository=myPluginRepo
g135 install-plugin myPlugin
which would immediately tell me that I'm using Grails 1.3.5.
The problem I have in creating a psh script like this is that I absolutely suck at creating scripts. I did try doing this but after about five mysterious error messages from psh itself I decided to just ask for advice.
Bonus points: If I can parameterize the alias call to specify the version (something like g[1.3.5] other params) and then append the number to the environment variable value,
that'd be the most handy solution for me.
This should do it:
Function PSGrails($ver)
{
$env:GRAILS_HOME='c:\grails\grails-{0}\' -f $ver
grails $args
}
It's just a short function that sets the variable and then executes grails as above.
Run it by specifying the version number directly after the function name:
psgrails 1.3.5 create-app MyWebApp
psgrails 1.3.5 list-plugins -repository=myPluginRepo
psgrails 1.3.5 install-plugin myPlugin