When I try to build my project (I have tried building for Android and Universal Windows Platform), building fails due to a MINUS SIGN (U+2212) character being used in the generated C++ as a negative sign. I am in Unity 2020.2/Android 11 SDK/GPGS 10; I built successfully with Unity 2019/Android 10 SDK/GPGS 9.
I have searched for “−” (and “2212” for good measure) in all asset, cs, meta, prefab, txt, unity, and xml files in the project and found nothing (other than a coincidental file ID 616832212, sprite ID 9561e3c67a82d7f448852212eb8fac6b, and binary files that technically match). I also tried having Unity reinstall packages and rebuild Library; no luck.
For a UWP build, I opened [build output directory]\Il2CppOutputProject\Source\il2cppOutput\Generic8.cpp and confirmed the “−” character appears in that way repeatedly in the file—e.g.,
19990:IL_0063:
19991: {
19992: return (int32_t)(−1);
19993: }
19994:}
The error for an Android build is:
Exception: Unity.IL2CPP.Building.BuilderFailedException: C:\[path to project folder]\Library\Il2cppBuildCache\Android\armeabi-v7a\il2cppOutput\Assembly-CSharp.cpp:20814:155: warning: treating Unicode character <U+2212> as identifier character rather than as '-' symbol [-Wunicode-homoglyph]
AndroidClient_InvokeCallbackOnGameThread_TisUIStatus_t34F64DC1927A392210216047169D4E196183BD14_m78B26B077A1A979B11C5596B45DC6E9A1A2929B6(L_1, ((int32_t)<U+2212>3), /*hidden argument*/AndroidClient_InvokeCallbackOnGameThread_TisUIStatus_t34F64DC1927A392210216047169D4E196183BD14_m78B26B077A1A979B11C5596B45DC6E9A1A2929B6_RuntimeMethod_var);
^~~~~~~~
C:\[path to project folder]\Library\Il2cppBuildCache\Android\armeabi-v7a\il2cppOutput\Assembly-CSharp.cpp:20814:155: error: non-ASCII characters are not allowed outside of literals and identifiers
AndroidClient_InvokeCallbackOnGameThread_TisUIStatus_t34F64DC1927A392210216047169D4E196183BD14_m78B26B077A1A979B11C5596B45DC6E9A1A2929B6(L_1, ((int32_t)<U+2212>3), /*hidden argument*/AndroidClient_InvokeCallbackOnGameThread_TisUIStatus_t34F64DC1927A392210216047169D4E196183BD14_m78B26B077A1A979B11C5596B45DC6E9A1A2929B6_RuntimeMethod_var);
^~~~~~~~
(And then the same thing continues to repeat for dozens more instances.)
I got the same issue, switching to UK (from Sweden) solved it
(not physically, changed in System settings: Language/Region)
Related
I have problems translating Modelica models with Dymola 2020: When I try to translate the models, the following error message appears:
"unknown internal error in Dymola".
The model was translating and simulating a couple of days ago, and the same model still runs on the computer of other colleagues. I didn't change the compiler in between nor the Dymola version. I've also restarted the computer but the problem persists.
Also, other models are still translating, so not all models are affected by this error.
Does anyone have a clue how to debug this error? Thank you very much for all hints!
The most likely explanation would be some weird setting of some flag.
You can see if you have any odd settings of normal flags by:
Dymola 2020: Edit>Options>General>Flags... Check "Non-default"
Dymola 2020x: Tools>Options>General>Flags... Check "Non-default"
(If it is a non-Boolean setting it is a bit messier.)
That is assuming it is really the same model and there is no difference in any model in the path (including working directory).
Frankly speaking, if you get "unknown internal error in Dymola" you should report it to technical support at Dassault Systèmes (through your reseller), and let them debug it.
It is not your job to debug such errors.
Have you tried to delete the content from the working directory (WD)?
Sometimes there are artifacts, which mess up the compilation of a specific model.
You can check where it is, using the
GUI, File -> Working Directory -> Copy Path and paste it in the Explorer
Command line typing cd, which returns the path to the WD
Then make sure that there are no important files in the WD (usually .mo files) and finally delete the full content of the directory.
Note: You should ensure that the WD is a local path (otherwise performance can take a serious hit). Besides that it is usually a good idea to have the WD separated form the directory where models are stored.
After updating from unity 2018.1 to Unity 2018.3, there is a bunch of error messages about text mesh pro. Here are the error messages
/Users/administrator/Dropbox/Sebastian/home/coding/Unity/Experimental Project/Library/PackageCache/com.unity.textmeshpro#1.3.0/Scripts/Runtime/TMP_Text.cs(4929,40): error CS0121: The call is ambiguous between the following methods or properties: TMPro.TMPro_ExtensionMethods.Multiply(this UnityEngine.Color32, UnityEngine.Color32)' andTMPro.TMPro_ExtensionMethods.Multiply(this UnityEngine.Color32, UnityEngine.Color32)'
/Users/administrator/Dropbox/Sebastian/home/coding/Unity/Experimental Project/Library/PackageCache/com.unity.textmeshpro#1.3.0/Scripts/Runtime/TMPro_Private.cs(3552,92): error CS0121: The call is ambiguous between the following methods or properties: TMPro.TMPro_ExtensionMethods.Compare(this UnityEngine.Color32, UnityEngine.Color32)' andTMPro.TMPro_ExtensionMethods.Compare(this UnityEngine.Color32, UnityEngine.Color32)'
Multiple plugins with the same name 'tmpro_plugin' (found at 'Packages/com.unity.textmeshpro/Plugins/64 Bit Plugins/TMPro_Plugin.bundle' and 'Assets/Downloaded Assets/TextMesh Pro/Plugins/64 Bit Plugins/TMPro_Plugin.bundle'). That means one or more plugins are set to be compatible with Editor. Only one plugin at the time can be used by Editor.
you have 2 folders of TMP in your project, one was probably added from the packages after the upgrade.
find them and remove the new one for a quick fix...
or do this: http://blog.collectivemass.com/2018/09/upgrading-textmesh-pro/
In the SuiteCloud Eclipse IDE for NetSuite, what is the Ignore List setting under Preferences > NetSuite > Validation? Is it a single file that behaves like, say, a .gitignore? Or is it an explicit list of files to ignore?
I suspect this setting is why Eclipse is always building libraries and other files I've explicitly told it not to in my NetSuite projects.
Can anyone provide some clarity on the usage of this field?
Attempt 1
I tried setting this preference to a single file with the following contents:
**/*.min.js
**/*.lib.js
**/docs/**
**/Third Party/**
**/node_modules/**
**/bower_components/**
**/*jquery*
**/*moment*
**/*lodash*
But that does not seem to work as expected. Files that should be caught by these regexes are still validated. One of them in particular (docstrap.lib.js) crashes the entire IDE every single time when the SuiteScript validator encounters it.
Attempt 2
I tried to put a similar string of regexes directly into the field itself:
**/*.min.js,**/*.lib.js,**/docs/**,...
but this just yields an error directly in the dialog itself: Value must be an existing file
Attempt 3
Created a new SuiteScript project with only blanket.min.js in the project root. Added an ignore file with the following contents:
/blanket.min.js
./blanket.min.js
*blanket.min.js
blanket.min.js
"blanket.min.js"
*blanket*
**/blanket*
*/blanket*
.\blanket.min.js
**\blanket*
*\blanket*
\blanket.min.js
\blanket*
.\blanket*
C:\Development\Projects\validator-test\blanket.min.js
C:/Development/Projects/validator-test/blanket.min.js
blanket.min.js still gets validated. Completely lost as to how this ignore file should be formatted.
The ignore list is used by the SuiteCloud IDE (IDE) to avoid having errors in the IDE for non-standard script ids in SuiteScript 1.0 APIs.
As an example...
nlapiLogRecord('customrecord_foo');
Since customrecord_foo is a non-standard record, it will be marked as an error by the IDE.
To tell the IDE to ignore customrecord_foo, the ignore list can be used.
It's a text file, with one script id per line.
customrecord_foo
customrecord_bar
The specified non-standard script ids in the ignore list file will not be flagged as an error by the IDE.
What might cause
new Font(Font.HELVETICA, 11f, Font.BOLD)
or
BaseFont.createFont(BaseFont.HELVETICA, 'Cp1252', BaseFont.NOT_EMBEDDED)
to start returning the following??
com.itextpdf.text.DocumentException: No message found for 1.not.found.as.resource
itext 5.5.6 jar on Max OSX 10.10
It seems that you are not using the "pre-canned" jar, but that you have created your own jar. That self-made jar only contains the Java class files. It misses resources such as the language (.lng) and the Adobe Font Metrics (.afm) files.
If the above assumption is wrong, then at least this is right:
Instead of the actual error message, you get the key to an error message that is stored in a .lng file: 1.not.found.as.resource. This key is used to find the actual error message in the language of your OS (English, Dutch and Portuguese are supported; the default is English).
The actual error message (should en.lng be found) would have been: "Helvetica not found as a resource" (the 1 in 1.not.found.as.resource is a placeholder). This message tells you that the file Helvetica.afm can't be found. This file contains the metrics of every glyph in the font Helvetica (regular). Without those metrics, you can't create a proper PDF.
This explains what happens. Your question doesn't contain sufficient information to explain why it happens. All of this shouldn't be a problem when using the correct jar with a JDK that knows how to read resources from a jar. The fact that you write "What might cause ... to start returning the following" indicates that it has worked for you before. Think of what you have changed between the last time it worked and the first time it stopped working (e.g. changing the OS, changing the JVM,...). That will probably be the culprit.
Here's what I'm currently using, which I think gets the job done, but there's got to be a better way:
func isWindows() bool {
return os.PathSeparator == '\\' && os.PathListSeparator == ';'
}
As you can see, in my case all I need to know is how to detect windows but I'd like to know the way to detect any platform/os.
Play:
http://play.golang.org/p/r4lYWDJDxL
Detection at compile time
If you're doing this to have different implementations depending on the OS, it is more useful to
have separate files with the implementation of that feature and add build tags to each
of the files. This is used in many places in the standard library, for example in the os package.
These so-called "Build constraints" or "Build tags" are explained here.
Say you have the constant PATH_SEPARATOR and you want that platform-dependent, you
would make two files, one for Windows and one for the (UNIX) rest:
/project/path_windows.go
/project/path_unix.go
The code of these files would then be:
path_windows.go
// +build windows
package project
const PATH_SEPARATOR = '\\'
path_unix.go
// +build !windows
package project
const PATH_SEPARATOR = '/'
You can now access PATH_SEPARATOR in your code and have it platform dependant.
Detection at runtime
If you want to determine the operating system at runtime, use the runtime.GOOS
variable:
if runtime.GOOS == "windows" {
fmt.Println("Hello from Windows")
}
While this is compiled into the runtime and therefore ignores the environment,
you can nevertheless be relatively certain that the value is correct.
The reason for this is that every platform that is worth distinguishing needs
rebuilding due to different executable formats and thus has a new GOOS value.
Have you looked at the runtime package? It has a GOOS const: http://golang.org/pkg/runtime/#pkg-constants
It's 2022 and the correct answer for go 1.18+ is:
At runtime you want:
if runtime.GOOS == "windows" {
// windows specific code here...
}
If you need to determine the filesystem path separator character
Use: os.PathSeparator
Examples:
c:\program files
/usr/local/bin
If you need the Path List separator as used by the PATH environment variable
Use: os.PathListSeparator
Examples:
/usr/local/bin:/usr/local:
"C:\windows";"c:\windows\system32";
Since this is an older question and answer I have found another solution.
You could simply use the constants defined in the os package. This const returns a rune so you would need to use string conversion also.
string(os.PathSeparator)
string(os.PathListSeparator)
Example: https://play.golang.org/p/g6jnF7W5_pJ
I just stumbled on this looking for something else and noticed the age of this post so I'll add a more updated addition. If you're just trying to handle the correct filepath I would use filepath.Join(). Its takes all of the guesswork out of os issues. If there is more you need, other than just filepath, using the runtime constants (runtime.GOOS & runtime.GOARCH) are the way to go: playground example
I tested in Go 1.17.1 which really worked for me.
package main
import (
"fmt"
"runtime"
)
func main(){
fmt.Println(runtime.GOOS)
}
Output:
darwin
With regards to detecting the platform, you can use Distribution Detector project to detect the Linux distribution being run.
The first answer from #nemo is the most apropiate, i just wanted to point out that if you are currently a user of gopls language server the build tags may not work as intended.
There's no solution or workaround up to now, the most you can do is change your editor's lsp configs (vscode, neovim, emacs, etc) to select a build tag in order to being able to edit the files with that tag without errors.
Editing files with another tag will not work, and trying to select multiple tags fails as well.
This is the current progress of the issue github#go/x/tools/gopls