Hello guys and girls,
So, Netbeans (like most IDE's) use dots (.) to organize decimal places, right?
I dont know why but my IDE began to use comma (,) to organize decimal places... even the outputs showed in the console are using commas. How can i change it back to default settings and start using dot in decimal places again?
PS: When i try to enter a number using dot and the decimal places (4.5, for example) i get this error message:
Exception in thread "main" java.util.InputMismatchException
at java.base/java.util.Scanner.throwFor(Scanner.java:939)
at java.base/java.util.Scanner.next(Scanner.java:1594)
at java.base/java.util.Scanner.nextDouble(Scanner.java:2564)
at EstruturasDeControle.If.main(If.java:16)
Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)
at org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:764)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:711)
at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:289)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Scanning input which expects a comma rather than a period as the separator for decimal values (or vice versa) is directly related to the Locale being used.
There are three ways of specifying the Locale to resolve your problem:
You can specify the locale to be used by default as a parameter when NetBeans is started:
--locale <language[:country[:variant]]>
For example: --locale en:US for American English, and --locale fr:FR for French.
This setting will apply for the current NetBeans session only.
You can permanently set the default locale used by NetBeans, by specifying it in the file etc/netbeans.conf within your NetBeans installation directory:
Open that file in any text editor.
Locate the line containing the text netbeans_default_options
Add the values to specify the language and country of the locale. for example, to set the locale to US English:
-J-Duser.language=en -J-Duser.country=US
See the article Change UI language to English on Netbeans IDE for more details.
You can dynamically specify the Locale to be used at the application level within the code. For example, in your case you could set the locale used by your application's Scanner by calling useLocale().
Your code code might look like this:
Scanner scanner = new Scanner(System.in);
scanner.useLocale(Locale.US); // US locale, so period is expected for numeric input.
...
scanner.useLocale(Locale.FR); // France locale, so comma is expected for numeric input.
All three approaches can resolve your problem, and you can use any or all of them. Your specific needs determine the one(s) to be used.
Related
I have configured my init.cli script like this:
set abc=sometext
/subsystem=naming/binding=java\:global\/ABC:add(binding-type=object-factory, module=net.flexoptix.jbossTools, class=net.flexoptix.jbossTools.PropertiesFactory,\
environment=[ABC=$abc])
The problem is that value ABC in the brackets is not substituted by value sometext.
I tried to find something useful but without success. Do you have any idea how to solve it?
I have found this post https://access.redhat.com/solutions/321513 (second method) but I am not sure if it's great solution.
I have found that the problem is the property substitution isn't being performed. To enable this, you need to edit the jboss-cli.xml, in the bin directory, and change the following property to "true":
<resolve-parameter-values>true</resolve-parameter-values>
By default, this is false, and must be enabled when trying to use the --properties option for property substitution when running CLI scripts.
So I have changed the following code:
/subsystem=naming/binding=java\:global\/ABC:add(binding-type=object-factory, module=net.flexoptix.jbossTools, class=net.flexoptix.jbossTools.PropertiesFactory,\
environment=[ABC=${abc}])
And it works!
while learning Gate, I encountered the following problem:
Minipar throws exception when it sees uncommen characters like Ö, Ü, Ä.
For example in the sentence "Batten disease (also known as Spielmeyer-Vogt-Sjögren-Batten disease ) is a rare, fatal autosomal recessive neurodegenerative disorder that begins in childhood." (from a wiki article)
The annotation Minipar got before it stopped working is "Batten disease (also known as Spielmeyer-Vogt-Sj" which is exactly before the character ö, so this makes me guessing that this is a case worth attention while using Gate. Because the same pipeline processed several other articles like a breeze.
In Messages Tab, it reprots:
gate.util.InvalidOffsetException
at gate.annotation.AnnotationSetImpl.getNodes(AnnotationSetImpl.java:773)
at gate.annotation.AnnotationSetImpl.add(AnnotationSetImpl.java:802)
at minipar.Minipar.runMinipar(Minipar.java:419)
at minipar.Minipar.execute(Minipar.java:527)
at gate.util.Benchmark.executeWithBenchmarking(Benchmark.java:291)
at gate.creole.ConditionalSerialController.runComponent(ConditionalSerialController.java:154)
at gate.creole.SerialController.executeImpl(SerialController.java:153)
at gate.creole.ConditionalSerialAnalyserController.executeImpl(ConditionalSerialAnalyserController.java:129)
at gate.creole.AbstractController.execute(AbstractController.java:75)
at gate.util.Benchmark.executeWithBenchmarking(Benchmark.java:291)
at gate.gui.SerialControllerEditor$RunAction$1.run(SerialControllerEditor.java:1619)
at java.lang.Thread.run(Unknown Source)
gate.creole.ExecutionException: gate.util.InvalidOffsetException
at minipar.Minipar.runMinipar(Minipar.java:491)
at minipar.Minipar.execute(Minipar.java:527)
at gate.util.Benchmark.executeWithBenchmarking(Benchmark.java:291)
at gate.creole.ConditionalSerialController.runComponent(ConditionalSerialController.java:154)
at gate.creole.SerialController.executeImpl(SerialController.java:153)
at gate.creole.ConditionalSerialAnalyserController.executeImpl(ConditionalSerialAnalyserController.java:129)
at gate.creole.AbstractController.execute(AbstractController.java:75)
at gate.util.Benchmark.executeWithBenchmarking(Benchmark.java:291)
at gate.gui.SerialControllerEditor$RunAction$1.run(SerialControllerEditor.java:1619)
at java.lang.Thread.run(Unknown Source)
Caused by: gate.util.InvalidOffsetException
at gate.annotation.AnnotationSetImpl.getNodes(AnnotationSetImpl.java:773)
at gate.annotation.AnnotationSetImpl.add(AnnotationSetImpl.java:802)
at minipar.Minipar.runMinipar(Minipar.java:419)
... 9 more
gate.creole.ExecutionException: Document doesn't have sentence annotations. please run tokenizer, sentence splitter and then Minipar
at minipar.Minipar.saveGateSentences(Minipar.java:194)
at minipar.Minipar.execute(Minipar.java:525)
at gate.util.Benchmark.executeWithBenchmarking(Benchmark.java:291)
at gate.creole.ConditionalSerialController.runComponent(ConditionalSerialController.java:154)
at gate.creole.SerialController.executeImpl(SerialController.java:153)
at gate.creole.ConditionalSerialAnalyserController.executeImpl(ConditionalSerialAnalyserController.java:129)
at gate.creole.AbstractController.execute(AbstractController.java:75)
at gate.util.Benchmark.executeWithBenchmarking(Benchmark.java:291)
at gate.gui.SerialControllerEditor$RunAction$1.run(SerialControllerEditor.java:1619)
at java.lang.Thread.run(Unknown Source)
I'd to thank Ian for his warm support once again.
Matt
This appears to be an encoding-related issue of some sort, but unfortunately I can't do any debugging myself as the minipar parser binary no longer appears to be available from the usual download page - I get a small (less than 2kB) greyscale JPEG image instead of a multi-MB .tgz.
There's a few things you could try off the top of my head. The GATE Minipar wrapper writes the input file for the parser and reads the parser's output using whatever is the default encoding on the system where you're running. My speculation is that the parser is producing its output in a different encoding (possibly related to the encoding of the original training data?).
The GATE wrapper writes its input to a temporary file which you should be able to find in your temporary directory as long as you leave GATE Developer running in the background (the temp files are deleted when Developer exits). I would try running minipar-windows.exe on that file from the command line and seeing what the output looks like
C:\path\to\minipar-windows.exe -p C:\path\to\minipar\data -file GATESentencesNNNNNN.txt
The output may give you a clue as to what's failing. If it looks right and you can determine the encoding it's trying to use you could set your GATE Developer to use that as its default encoding (if you're using gate.exe to start it then you do this by adding a line -Dfile.encoding=ISO-8859-1 or whatever to gate.l4j.ini) and see if that helps. If so we can consider adding a parameter to the PR to specify the encoding to use when exchanging data with the parser executable.
I use this to set my maximum line width to 80:
org.eclipse.jdt.core/org.eclipse.jdt.core.formatter.lineSplit=80
Let's face it, Eclipse's formatter is not strict.
It has a very high success rate, and format things very nicely indeed, but it is not 100% strict, sometimes it leaves lines > 80 characters and so it is useless for a project that just lints and refuses code not strictly matching the 80 columns limit and requires Eclipse code auto-formatting.
These 2 things, Eclipse-based formatting and lint, can only really work together when the success rate is 100%. If not, even changing the code by hand triggers a "reformat/reflow" on save and the check-in bombs and refuses the commit.
I cannot disable the formatting on the client and I cannot circumvent the linting.
Is there any way at all to just make the wonderful Eclipse formatter 100% strict? Something like "considerTheLimitSeriously=true"?
Notice: it's eminently "unstrict" in lines with method signatures, but not only.
Sorry, there's no way to make the formatter 100% strict when it comes to line splitting. According to JLS 3.8. Identifiers:
An identifier is an unlimited-length sequence of Java letters and Java digits, the first of which must be a Java letter.
So it's possible that some lines cannot be split without causing a compile error.
The best you can do is set the formatting as strict as possible, then look at specific lines in your code to see where this is failing. On the Eclipse main menu go to Window > Preferences, then go to the Java > Code Style > Formatter tab, then click Edit. There you'll find a Line Wrapping tab where you can customize the line wrapping rules.
I am debugging my program with apache mina 2.0.2. The specific library is irrelevant.
The problem is that Eclipse can see internal structure of some classes and cannot see one of the others. No apparent differences visible for me: both classes have both code and source.
You can see that Eclipse draws arrow near AbstractPollingConnector class and does not so near AbstractPollingProcessor.
Of course Eclipse can't set line breakpoints inside "bad" classes.
What is the reason of it and what to do?
I guess, it depends whether the referenced classes were compiled with the debugger options on or off. According an older Javac manual, the -g switch seems related:
-g
Generate all debugging information, including local variables. By default, only line number and >source file information is generated.
-g:none
Do not generate any debugging information.
-g:{keyword list}
Generate only some kinds of debugging information, specified by a comma separated list of >keywords. Valid keywords are:
source
Source file debugging information
lines
Line number debugging information
vars
Local variable debugging information
So i started working with emacs as a programming editor, well i was wondering how you set the language path for a language? Im using python and its giving a error saying searching for directory: no such file or directory,python.
There is no general mechanism, it depends upon the specific language support mode.
For Python, there is the variable python-python-command. It's default value is just python, but if that doesn't work on your system, you can set it to a path (e.g. with M-x customize-variable).
You can also change the python command without changing the configuration by invoking run-python with a prefix, i.e. C-u M-x run-python.