The Specified Compiler Compliance - anylogic

I use Anylogic University 8.7.6 and I found the following warning when opened an Anylogic model I've created before.
Description: The compiler compliance specified is 1.8 but a JRE 11 is used.
Should I do anything regarding this warning?
Thank you.

Somewhere in your old project, it was specified that Java 8 was used. You can either change the Java AnyLogic should be using (not advised) in the settings in the screenshot below
Or you can safely ignore the warning and save your model.

Related

Unwanted "warning" stops the loading of my Netlogo model when using the extraWidget extension

Every time I attempt to load a Netlogo model that uses the extraWidget extension the loading stops and I receive a warning. The warning explains that the extraWidget extension was created with the Netlogo extension API 6.0 and the version of Netlogo I'm using is API 6.1. I must click 'Continue" each time to complete the loading.
Is there a way to remove this warning?
Thanks
Rudy
Unfortunately your options here aren't great. There is no flag or configuration to have NetLogo skip the warning.
Downgrade to NetLogo 6.0.4. This is easy to do, but you'll miss out on any 6.1.0 and 6.1.1 features/fixes. You can get it at the NetLogo downloads page: https://ccl.northwestern.edu/netlogo/download.shtml
Fork the eXtraWidgets repository and update the NetLogo version it uses to 6.1.0 in order to build your own jar that won't cause the error to be thrown. I believe this is the line that would need to be updated, but you'd also need to get the proper development tools (sbt and a Java 8 JDK) installed and figure out how to do the compile and packaging of the extension.
(eXtraWidgets author here)
I have updated the extension for NetLogo 6.1.1.
The release is here if you want to give it a spin.

error: unable to spawn process (Argument list too long) in Xcode Build

I am getting this error:
"error: unable to spawn process (Argument list too long)
** ARCHIVE FAILED **
The following build commands failed:
CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler
(1 failure)
Exitcode =65 "
I went through this link:
Xcode export localization throws error "Argument list too long"
This article provides a good temporary solution of the problem stating to reduce the path hierarchy. But this does not seem to be an appropriate approach. Can anyone provide me with a different approach to the solution for this problem?
In my case, it was about custom configurations in .xcconfig files.
My config files were including Pods configurations like:
// Development.xcconfig
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.debug (development).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.debug (development).xcconfig"
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.release (development).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.release (development).xcconfig"
// Production.xcconfig
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.debug (production).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.debug (production).xcconfig"
#include "Pods/Target Support Files/Pods-MyProject/Pods-MyProject.release (production).xcconfig"
#include "Pods/Target Support Files/Pods-MyProjectTests/Pods-MyProjectTests.release (production).xcconfig"
This produced the error you mentioned, when I added Firebase pods into my Podfile.
So to make this compile again I had to:
remove all inclusion (#include ...),
set them explicitly in the Project -> Info -> Configuration, as follows:
Quick tip:
If you don't want manually setting up corresponding target configurations (those with red icon), mark them as None and run pod install. This will automatically change it for you.
A few days ago I faced a similar challenge. I want to provide details and share my research with SO community.
First of all I found this thread and I followed the link in the asked question.
And yes, thats right, the answer marked in the link is correct, but the solutions to this problem did not suit me.
Problem
In my case, I had this problem when I changed the folder hierarchy in my project to be more convenient and suitable for me.
#oOEric option did not suit me, because according to the rules, the hierarchy of groups in Xcode should coincide with the hierarchy of folders in the system.
But I've already had about 1680 swift files to compiling.
The problem was that I had too long path to the compiled files and their number was too large.
Research
Then I start research and found swift jira with the same bug.
Here some links:
Main
Linked Issue 1
Linked Issue 2
Linked Issue 3
Bug on Open Radar
But here I didn't find some solutions for me.
Most of all I was pleased with this response of the swift developers.
Again, this is an Xcode-side issue, not a Swift-side issue. Commenting here won't make the Xcode engineers work any faster!
(We're not all the same people at Apple.)
Okey, after this answer, I was finally convinced that if it is an Xcode bug, then the solution should be sought in Xcode.
Solutions
Temporary solution
You need to move your project higher in the hierarchy of your system.
I choose this one, because I have really big project and the use of other solutions will require more than one day from me.
In my case, I conducted an experiment and calculated that the length of the path to the project should be no more than 50 characters.
But this is a temporary solution. If your project grows further, you will have to shorten the path or use other solutions.
Cocoa Touch Framework target
This solution is suitable for files that do not use dependencies.
First of all you need to add Cocoa Touch Framework as a target to you main project.
This target should be added automatically to Embedded Binaries and Linked Framework and Libraries.
After this you need to find some files without dependencies and change target membership to your "TestTarget".
Don't forget classes, properties, methods, enums, protocols from cocoa touch framework should have open or public access.
And don't forget clean your DerivedData folder.
Modular iOS
This solution has a more integrated approach.
If you want to use any dependencies in your Cocoa Touch Frameworks you should go to this guide and make more complex refactoring for your big project!
Link to solution
I think this is the best solution.
I hope this big answer will help someone!
I solved this by setting build system to Legacy build system
in file-> workspace setting -> select workspace setting
I solved this by reducing the hierarchy of groups in Xcode.
e.g. original files at project_name/project_name/About/Model/Text
I removed the groups "Model", "Text" and moved files under project_name/project_name/About/
I made simple script for temporary fix that problem. https://github.com/gregoryvit/flatter
It simply move all swift files in Xcode project to root group.
Error - unable to spawn process (Argument list too long)
There are many reason for this error. Some of these are mentioned below:
Your project might have many swift files (say more than 2000)
Most of the Swift source files may be deeply nested inside directories
Many of these files have absolute paths with more than 150 characters (eg. /Macintosh HD⁩/⁨Users⁩/jayprakashnd⁩/⁨mySampleProject/Module1…)
Xcode swift complier takes the absolute paths of all source files while so compiling, the ARG_MX limit is reached and build fails.
This has been fixed in Xcode 11 wherein a flag is used to set unlimited number of swift files.
Solutions:
Switch to Xcode 11 and add USE_SWIFT_RESPONSE_FILE to YES in build settings - User Defined Section
If you cannot switch to Xcode 11 then take a new checkout of your project in Macintosh HD⁩ ▸ ⁨Users⁩ directory with folder name as minimal as possible.
Solution 2 worked for me like a charm!
It happened to me when I use Xcode 11 beta version using Live Preview. Then I solved it by restarting Xcode after that error has gone.
I have fixed this issue, moving my folder of My Xcode project to the mac root and changing my name Folder to less characters.
Terminal: cd /
Change name folder to BX (example).
xcode11
-build setting
-user-defined
-add setting: USE_SWIFT_RESPONSE_FILE
-setValue: YES
Doing this you enable xcode to have more files than is allowed. But im not sure if this always solve the problem.
I have changed build type to legacy and it also resolved problem for me, both locally and on our CI builder. For me it was caused during checking Podfile.lock and Manifest.lock. Probably this could be skipped in our pipeline since we are always installing pods on CI.
If you faced this issue on your Flutter project while building in Release mode (or Archive) check out my this answer: https://stackoverflow.com/a/61446892/5502121
Long story short:
set your build system to New Build System in File > Project Settings…
remove ios and build_ios folders
run flutter create . to init new ios module
run pod install
run flutter pub get
check your Xcode build config (it should be Release mode and General iOS Device)
and you're good to go
I have the same problem. I fix it using a temporary solution, however that work for me.
My solution is to change the Derived Data folder to a directory with a shorter path.
The Steps is as the following:
Xcode -> File -> Workspace Settings... -> Select Custom Location for Derived Data and give a shorter path as the location.

IntelliJ and Eclipse gives different result

For some reason my project gives the below error in eclipse:
No error in IntelliJ. Any ideas?
Using IntelliJ:
IntelliJ IDEA 2016.2.5
Build #IC-162.2228.15, built on October 14, 2016
JRE: 1.8.0_112-release-287-b2 x86
JVM: OpenJDK Server VM by JetBrains s.r.o
The reason behind different results is that Different IDEs use different inspection tools.
In your particular question Eclipse shows an error, while Intellij shows a warning. So anyhow both are suggesting that something has gone wrong here.
Besides it's a warning or an error, the point both are making is Not to use key duplication in json. The reason is when you refers the value via the key then key duplication causes problems.
Since JSON is just a markup language and creates no problems for project build, Intellij would just make a warning and not an error. Since key duplication does make no sense though, Eclipse would mark up as an error. Anyway not to worry about whether warning or error, just catch the point they are making. :))

Error while Debugging using Eclipse for DS-5

I am using DS5 evaluation version. I created a simple hello world C project in eclipse for DS5. Project type chosen while creating the project is Bare Metal executable->Empty project. Tool chains ARM Compiler 5 was selected. I complied the code and generated the axf file. When i right click on the axf file and select debug as->debug configurations->Connection tab->ARM FVP VE_Cortex_A7x1->Bare Metal Debug->Debug Cortex-A7 and click on debug I am facing the error as in the image.
Please let me know how to resolve the same.
The reason you're seeing that error is that the evaluation version of DS-5 Professional Edition gives you access to the Cortex-A8 and Cortex-A9 FVPs, not the Cortex-A7 one.
Extra FVPs need to be purchased separately from ARM.

Eclipse #ifdef error using JNI, Android NDK and Vuforia

With Vuforia's ImageTargets sample application, I tried using OpenGL ES 1.1 by setting USE_OPENGL_ES_1_1 to true in jni/Android.mk and uncommenting and changing the corresponding line in AndroidManifest.xml (). After converting the project so that it has a C++ perspective and associating ndk-build and the proper include directories, I could successfully run the application on my Android device.
However, the problem is that once I open up jni/ImageTargets.cpp, I get several errors from Eclipse, all from places where OpenGL ES 2.0 code would execute, the first one being:
Description Resource Path Location Type Symbol 'vertexHandle' could
not be resolved ImageTargets.cpp /ImageTargets/jni line 402 Semantic
Error
Sure enough, vertexHandle is defined at the top of the ImageTargets.cpp, inside the "#ifdef USE_OPENGL_ES_2_0" block. Because USE_OPENGL_ES_2_0 is not defined (per Android.mk), the code should be able to compile successfully, and sure enough, ndk-build does not report any problems. So it seems that only Eclipse reports the problems and when I run the project, Eclipse says, "Your project contains error(s), please fix them before running your application." And thus, I cannot run my application anymore. In a sense, it's kind of strange that this never occurred until I opened ImageTargets.cpp and Eclipse "discovered" the errors.
The best work-around I've found so far is to just delete or comment out those lines (that should not be causing problems because USE_OPENGL_ES_2_0 is not supposed to be defined)... Is there a better way to deal with this problem? Did I miss a setting in Eclipse that should solve this?
I've found a solution: go to the project properties -> C/C++ Build -> Discovery Options -> Check "Automate discovery of paths and symbols"