I need to use fantom for a University project. I downloaded the fantom environment, and fantomIDE to go with it. It all works great.
My problem:
I have created a project named test to test some things and check all goes and runs. When I checked the fantom installation folders I fond a file named after my test project, and running it resulted with the test code.
I don't want every class I create to be exported to the installation folder of fantom (mostly because I don't want to crowd the name space with to many pods).
Is this by design? Can I prevent this from happening?
Add a blank file called fan.props to the root directory of your project folder. This is a non-documented shortcut to create a PathEnv.
You can verify your setup by doing a fan -version:
andy:~/proj/draft$ fan -version
Fantom Launcher
Copyright (c) 2006-2013, Brian Frank and Andy Frank
Licensed under the Academic Free License version 3.0
Java Runtime:
java.version: 1.6.0_65
java.vm.name: Java HotSpot(TM) 64-Bit Server VM
java.vm.vendor: Apple Inc.
java.vm.version: 20.65-b04-462
java.home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
fan.platform: macosx-x86_64
fan.version: 1.0.65
fan.env: util::PathEnv
fan.home: /Users/andy/proj/fantom/dev
Env Path:
/Users/andy/proj/draft (work)
/Users/andy/proj/fantom/dev (home)
Related
I could not load a 3D object using Java3D 1.5.1. I tried a few examples like:
(1) HelloUniverse.java from https://www.cs.utexas.edu/~scottm/cs324e/CodeSamples/HelloUniverse.java
The major error for this and other Java 3D Applications is "no J3D in java.library.path" like this screenshot
Errors with Java3D Applications
I have put "j3dcore-ogl.dll" in C:\Window and other system folders, but when I run "regsvr32 j3dcore-ogl.dll", I got 'The module "j3dcore-ogl.dll" was loaded but the entry-point DllRegisterServer was not found.' I tried but failed to find an OpenGL driver for my Graphic Card. I tried but failed to switch to the DirectX option as documented in the "Java3D/1.5.1/README.html".
(2) Mykeynavbeh.java (Toy Plane) from https://sites.google.com/site/java3dapplets/home/source-code-toyplane
The major error from this and other Java 3D Applets is "Could not find or load main class sun.applet.AppletViewer" like this screenshot
Errors with Java3D Applets
I changed my JRM to JavaSE-8 but has no effect. The author, Mykeynavbeh or fukinotou11d (his username here and on Youtube Channel) seems have been running these applets and application with a PC successfully. I really wish someone like him could help me out. Thank you all in advance. Perry
[1] Is j3dcore-ogl.dll in C:\Program Files (x86)\Java\jdkx.x.x\jre\bin? (For the 64-bit version, Program Files)
Please check
j3dcore-d3d.dll
j3dcore-ogl.dll
j3dcore-ogl-cg.dll
j3dcore-ogl-chk.dll
are in the above bin folder,
and
j3dcore.jar
j3dutils.jar
vecmath.jar
are in C:\Program Files (x86)\Java\jdkx.x.x\jre\lib\ext
If the required files are in the correct directories, I think Java3D programs should work fine using Java3D 1.5.1 in Java8.
If they are not in the above folders, probably something wrong with the installer for Java 3D (for the 64-bit installer, sometimes one of the required .dlls was missing), or you didn't reinstall Java3D after the new JDK is installed, for example after updating JDK from 1.7 to 1.8.
If you can't find these files in the above folders, try the following manually:
Copy these .dll files from C:\Program Files (x86)\Java\Java3D\x.x.x\bin
to C:\Program Files (x86)\Java\jdkx.x.x\jre\bin.
Copy these .jar files from C:\Program Files (x86)\Java\Java3D\x.x.x\lib\ext to C:\Program Files (x86)\Java\jdkx.x.x\jre\lib\ext.
Please install (copy) the above files while watching my video,
"How to Put a MetasequoiaLE(Free) Model into Java 3D_2," 1:34
https://youtu.be/AXhPFOupwUM
because their locations are a little hard to find.
[2] You may want to use Java3D 1.6. Java3D 1.5.1 is no longer maintained. On the other hand, Java3D 1.6 is actively maintained by devoted developers. Native libraries (.dll) are wrapped up in jogamp-fat.jar, so you don't have to worry about .dll files.
[3] https://sites.google.com/site/java3dapplets/home/source-code-toyplane
This program is a java application extending the Applet class, and not an applet to be executed in an AppletViewer or on a web browser. It can be executed as an ordinary java program as it is in Java8, and can be distributed as a .jar file.
I used to display applets in that website. The site name "Java3D Applets" comes from this. Sorry for the confusion and misleading. I removed those applets because they could not be used any more, and instead started posting there simple Java 3D application source code. Google notified that starting September 1, 2021, the Classic Google Sites would no longer be viewable, so I moved the contents of the old site to the new site, and rearranged the site:
https://sites.google.com/view/flying-java-3d/home
I'm new to C++ and Allegro 5 but have been able to follow tutorials online and am able to build and compile several smaller projects successfully.
I cannot however get the demo project named Cosmic Protector to run and would like to at least learn what is wrong.
Unfortunately, I can't give you much to go on.
A window opens briefly and then closes, leaving the console open with the message..
process 6400 exited with code 255
If you have this demo running in VC 2017 with the latest release of Allegro 5 (5.2.4) installed via Nuget, I'd like to know that even.
The source for this program is available at...
https://github.com/liballeg/allegro5/tree/master/demos/cosmic_protector
Thank you, Jack
The allegro example programs and demos are usually built with CMake alongside the Allegro library. I just tested the CMake build of Allegro 5 with VS2017 on Windows 10 and it builds the Cosmic Protector demo successfully. You have to move the allegro dlls into the same directory as the exe, but other than that it runs perfectly.
As to why it's not working for you, cosmic protector depends on a data directory that holds it's resources. The working directory may be wrong, which would cause it to be unable to find resources. The data dir needs to be copied alongside the executable.
You can set the working directory to $(OutDir) under Debugging in Project->Properties and then it should find any data in the same directory as the exe.
How are you building cosmic protector?
Thanks to BugSquasher, I now have this working.
Here's how...
Start Visual Studio 2017
Create New Project of type Windows Console Application.
Name project CosmicProtector and save it in appropriate place on my HDD.
Disable precompiled headers and delete the any .h and .cpp
files associated with the new project regarding precompiled headers.
(for example pch.h)
Install Allegro 5.2.4 via Nuget.
In Visual Studio, navigate to Project Settings/Properties and ensure all
Allegro addons are enabled.
Copy the Cosmic Protector SRC and Header files and paste them into my
project directory.
Next in Visual Studio Project, Add the Source and Header files
respectively.
Rather stupidly, the step I had missed and that your reply brought my attention to was...
Copy the data directory and paste this into my project directory in the
applicable location.
Now build...
The project built right away, except for some errors reported in Game.cpp, GUI.cpp and Render.cpp
One error in Game.cpp, this being an instance of...
error C4996 'snprintf': This function or variable may be unsafe. Consider using snprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
To address this I have changed the instance of snprintf to sprintf_s.
Three errors in GUI.cpp, were instances of...
Error C4996 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
To address all of these I changed each instance of strcpy to strcpy_s.
And one error in GUI.cpp, this being an instance of...
error C4996 'snprintf': This function or variable may be unsafe. Consider using snprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
To address this I have changed the instance of snprintf to sprintf_s.
One error in Render.cpp, this being an instance of...
error C4996 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
To address this I have changed the instance of sprintf to sprintf_s.
Then build and it works:)
Thank you so much for your reply as I had moved on to other things but will find it very useful I think being able to build and run this demo.
It's only your reply that has brought me back to it and this time, I am successful:)
I am new to JMeter. I believe I have installed it successfully and I am running through the script recorder setup (http://jmeter.apache.org/usermanual/jmeter_proxy_step_by_step.pdf). When I start the JMeter proxy server which is used to intercept the browser requests a file called ApacheJMeterTemporaryRootCA.crt should be generated in jmeter/bin folder. It isn't. So, I cannot move on to Install the JMeter CA certificate for HTTPS recording, or for that matter configure my browser. Is there any known reason why the JMeter certificate would fail to be generated?
I solved it by removing ApacheJMeterTemporaryRootCA.crt, ApacheJMeterTemporaryRootCA.usr and proxyserver.jks from the bin directory of JMeter.
https://mail-archives.apache.org/mod_mbox/jmeter-issues/201401.mbox/%3Cbug-56057-58895#https.issues.apache.org/bugzilla/%3E
You are probably using Java 6 , in this case no ApacheJMeterTemporaryRootCA is generated.
To know if you are using Java 7:
- If HTTPS Domains is read only you are in JDK6
- If HTTPS Domains is writable you are using JDK7
Ensure you follow this:
https://wiki.apache.org/jmeter/TestRecording210
http://jmeter.apache.org/usermanual/component_reference.html#HTTP%28S%29_Test_Script_Recorder
Need to remove proxyserver.jks to create new certificate if you have removed ApacheJMeterTemporaryRootCA.crt, ApacheJMeterTemporaryRootCA.usr from bin . I did same too and got the certificate.
I was having the same issue - the root certificate was not found under the jmeter/bin directory. It was created in this path
C:\VTRoot\HarddiskVolume3\Users{UserName}\Downloads\apache-jmeter-2.12\bin
I had to import it to firefox
Windows 7 Professional - 64 bit
Java 7 - 64 bit
Jmeter Version 2.12
We had the same problem. It appeared that the keytool.exe file that was being called by JMeter to generate the certificate, was located in a directory that had no write access. Initially the certificate is generated relatively to the location of keytool.exe (which is in java/bin), and then it is moved into the jmeter/bin directory.
We were able to fix it by copying the java installation directory into de jmeter directory and set write access. Then start JMeter with java pointing to the copied version.
Don't forget to remove proxyserver.jks before you try again
I had a similar issue please follow below steps,
1.Reinstall java, update the environment variables JAVA_HOME
2.Check the java version and make sure you don't get anything extra other than
C:>java -version
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) Client VM (build 25.144-b01, mixed mode)
in case if you find anything addition , remove them from environment variables.
5.Run Jmeter , you should be getting root certification
don't go complex solution lets try it easily
check your jdk version java -version> if version is less then jdk6 then update you jdk
2.download the missing file (gist.github.com/9ef114c53b83e553b635.git)
3 and add it however you know
In my case,
I extracted JMeter in C: drive (Windows 10 program files folder).
Running JMeter.bat as Administrator solved that issue for me.
Otherwise extracting in other drives also help.
I'm to use nunit-console to run all of the tests in my solution.
I did this:
c:\some\path>nunit-console-x86.exe MySolution.sln
NUnit-Console version 2.6.2.12296
Copyright (C) 2002-2012 Charlie Poole.
Copyright (C) 2002-2004 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov.
Copyright (C) 2000-2002 Philip Craig.
All Rights Reserved.
Runtime Environment -
OS Version: Microsoft Windows NT 6.1.7601 Service Pack 1
CLR Version: 2.0.50727.5466 ( Net 3.5 )
ProcessModel: Default DomainUsage: Default
Execution Runtime: net-3.5
Could not load file or assembly 'MyNamespace.Administration, Version=0.0.0.1, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
So, I decided to try nunit-x86.exe I did File > Open Project > MySolution.sln and got this:
---------------------------
NUnit
---------------------------
Test load failed!
System.IO.FileNotFoundException : Could not load file or assembly
'MyNamespace.Administration, Version=0.0.0.1, Culture=neutral,
PublicKeyToken=null' or one of its dependencies. The system cannot
find the file specified.
For further information, use the Exception Details menu item.
---------------------------
OK
---------------------------
The exception can be found here
What is happening and how do I fix it? (without having to maintain a MySolution.nunit file)
More information
MyNamespace.Administration is not even one of the dlls that contains tests, which means that nunit fails trying to load it to look for tests to run. Knowing this I edited the file created by nunit-x86.exe (MySolution.nunit) and removed all dlls that did not have tests. Sure enough, the tests work (in both gui and console). This is not acceptable for me because it would mean that I have to keep yet another configuration file. Nunit supporting .sln files was supposed to avoid this.
My tests run fine using TestDriven.Net (but I really need to run them using nunit-console)
I have looked at this answer but I cannot make sense of what the fusion log viewer says. Would posting that log help? Assembly binding Log Viewer, lists 3 files being created:
nunit-agent-x86.exe, this one seems to be trying to find MyNamespace.Administration.dll/EXE inside the nunit directories
Tests_24398275 x2 - one looking for nunit.core in my project folders and another looking for unit.core.interfaces inside my project folders. I would pay little attention to these two since they also appear in my manually edited .nunit project).
(per andreister comment) The problem seems to be with the project/assembly itself and not the creation method. If I create a .nunit project and try to add MyNamespace.Administration to it (using 'Add Assembly...' or 'Add VS project...') it fails.
Calling nunit-console-x86 somepath/bin/Debug/MyNamespace.Administration.dll directly works.
Reposting my reply on nunit-discuss:
The NUnit feature of loading VS solutions is really fairly limited and intended to work with simple projects or as a quick way to create an NUnit project file - i.e. load the solution and save as an NUnit project, then edit the xml file that is created. Since the solution file format doesn't indicate which files are tests, NUnit attempts to load each project to check if it contains any tests. (This is the same thing that Visual Studio 2012 and later does when using the test explorer window, btw.)
As you suggest, I think the particular assembly fails to load because of having a dependency that is one level up. When loading either a VS solution file or an NUnit project file, NUnit sets the application base to the directory containing the solution or project. That's why an NUnit project file one level up works.
The designers' intent in this sort of situation is that you would create an NUnit project file. I recognize that this is somewhat inconvenient, since it gives you another configuration file to maintain. I'm open to suggestions regarding the use of globs either on the command line or within the project file. Any such changes would probably go into the next major upgrade, NUnit 3.0.
Unfortunately, even after posting on nunit-discuss group I was unable to find a proper solution for this problem.
nunit-discuss group confirmed that my tests are failing because of having a dependency that is one level up.
I did however found an acceptable work-around.
Since calling the .dlls directly didn't have the same issues.
I could do this with globs, but I'm on windows... but I have git bash installed.
Taking advantage of my somewhat rigid project structure and naming convention I managed to do this:
"C:\Program Files (x86)\Git\bin\bash.exe" -c 'nunit-console-x86.exe //framework=net-4.5 //xml:nunitresults.xml MysolutionFolder/Tests/*/bin/Debug/*.Tests.dll'
Please note that I took advantage of my naming convention. This is very important to do in order to reduce the number of arguments.
When I did nunit-console-x86 MysolutionFolder/*/*/bin/Debug/*.dll instead of MysolutionFolder/Tests/*/bin/Debug/*.Tests.dll I got an error from nunit-console-x86 saying Bad file number.
Besides, it's faster if I just provide the right files.
If you have a more recent version of bash (4.0+, I think) you can instead use the following command (note the use of **):
"C:\Program Files (x86)\Git\bin\bash.exe" -c 'nunit-console-x86.exe //framework=net-4.5 //xml:nunitresults.xml MysolutionFolder/**/bin/Debug/*.Tests.dll'
Which is shorter and more permissive on the project structure.
Running Ubuntu Oneric 11.10 with 1 GB RAM and 250 GB HDD Dell Inspiron Laptop.
I got some demo code from a tutorial to read XML. When I compile it, I get this message:
"The type or namespace name '.Xml' does not exist in the namespace 'System'. Are you missing an assembly reference?" (using System.Xml;)
I have the library in this path: /usr/lib/mono/gac/System.Xml/4.0.0.0_b77a5c561934e089/System.Xml.dll
Are you using MonoDevelop to build your application? If so, make sure that there is a reference to System.Xml in your project.
In case you are hardcore enough to "manually" use dmcs to build your application (or you are using a Makefile or some other automated build process), make sure you pass /r:/usr/lib/mono/4.0/System.Xml.dll as one of the arguments to your dmcs build command.
Only for didatic purposes, here is the references editing option in MonoDevelop, in which you should choose to add a reference:
Note: your distro could have installed System.Xml.dll in another path, so please verify.
Your monodoc problem is an entirely different issue and probably means either a directory or file is missing from the installed docs or there is a bug in monodoc entirely