I am new to Antlr4 and trying to generate a parser for PL/SQL with the g4 file I downloaded from Github. However, I encounter a problem while using the auto-generated codes in IntellJ IDEA with the Antlr plugin. I have the parser file in my directory but it still pops up errors stating that cannot resolve symbol 'PlSqlParser'. What should I do with it to fix this error?
Cannot resoleve symbol
PlSqlParser in the directory
I'll answer my own question here. It seems to be that IDEA is ignoring this parser file since the size of it is too large. I fixed it by editing the custom properties.
Related
package com.yada.yada
What happens with IntelliJ when I create Java class 'ss' in com.yada.yada without package statement? - RED "Missing Package Statement".
What happens when I create Kotlin file in com.yada.yada without package statement? - "Keep going bro until your DI framework will fail to scan your deps during runtime"
Why IJ package validation is non-mandatory for Kotlin? I just wasted an hour trying to figure out what's wrong with package scan only to realise this was the show stopper. Would Java 9 jigsaw quadruple the chaos for Kotlin sparked by such malformed files/classes with no warning messages? Well, you bet it will!
Please return back the "warning" statement for Kotlin. P.S. registration/login methods are not sufficient for myself to access Intellij bugtracker(and I am genuinely pissed off with one time access password resets, 1000 resources and 980 passwords I don't remember or care to) therefore making this public on stackoverflow.
If anybody going to defend this behaviour please explain why? Maybe I am missing something, otherwise please reply with open bug(preferably somebody from JetBrains) and I will accept it.
The missing inspection warning for files with no package statement is a bug; the corresponding YouTrack issue is here.
I'm not sure this post is appropriate here, but to answer the actual question, the official documentation states that:
If the package is not specified, the contents of such a file belong to
"default" package that has no name.
Since with Kotlin your files don't have to be in folders that match their packages, not having a package declaration has to be an option so that you can have files that are organized in folders, but you don't wish to put them in packages - this way they can have the same package as if they weren't nested in any folders, and were just in the root of the project.
I do concede that it's a bit odd there is a warning for your package declaration not matching the folder your file is in, but you don't get this if you just omit the package declaration altogether. I suppose this is assumed to be intentional.
This shouldn't generally be a problem because IDEs will generate the appropriate package declaration for the folder you've created your file in by default. I'm not sure how you created a file without a package declaration if you're using IntelliJ, unless you did it in the root src folder instead of inside a package folder.
I tried modifying the VehicleRoutingSolutionPainter.java file in Optaplanner to display some other information too. However, building using Maven by executing mvn -DskipTests clean install throws following build error:
Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.15:check on project optaplanner-examples: Failed during checkstyle execution
I then removed the edits I made to the java file. However, it still throws the same error. How do I make modifications to the java file?
Thanks
Checkstyle is (packaged into) a Maven plugin used for checking code formatting issues -- OptaPlanner uses it in order for the code to look uniform all across the code base. You have two options on how to proceed:
If you just want to make edits for your own purpose (and don't care about code formatting, I suggest out-commenting the maven-checkstyle-plugin in the main OptaPlanner pom.xml file (currently lines 83-171 in the file).
Or, you can fix the formatting errors that checkstyle reports (see the checkstyle log and/or the lines below the error you posted in the console). You will have to do this if you want your changes to get merged back into OptaPlanner source code.
The reason why when you reverted the changes checkstyle was still unhappy is, that you probably left in some excessive whitespace, or failed to add a new line at the end of the file, or something similar.
Some valid IDL files, build as IDL Projects and install but some or all of their contents do not appear in the SCA Explorer/Target SDR/IDL Repository. I believe that the IDL parser used to build the tree in the IDL Repository is different from that used by the omniORB idl2cpp (omniidl) during building and it rejects some valid IDL. The cases I have found all use a value of a const previously defined. e.g.,
const Algorithm ALG_NONE = 0
const Algorithm ALG_LPC = ALG_NONE + 3
The second line can occur in the same file or in a file that includes the file containing the first line.
The file containing the first line is accepted if the second line is not in the same file, but the file containing the second line is rejected and none of its contents appear in the IDL Repository tree. It appears that it rejects a const appearing as a value on the right side of an assignment statement. These files however are valid and are accepted as valid by omniidl. But they cannot be used in RedHawk because they cannot be selected for a component interface.
I am not very familiar with RedHawk IDE sources or Eclipse plugins and so have not been able to find where the syntax for the parser is specified. I see "eclipsecorba" appearing in plugin lists so I assume that RedHawk is using the Eclipse CORBA Plugin (aka ECP) and that its parser is the one being used to build the tree. So I suspect that the parser error is in that package rather than in code added by RedHawk.
Can anyone confirm this and suggest where I might look in the ECP code for this? Should I report this as a ECP bug to the ECP group on SourceForge? I am not sure how active it is since it appears that the latest version is from 2008.
This seems to be a bug in the IDL editor, the IDL you have is legal. Would recommend you to report this to ECP but given the long inactivity of that project probably it will not fixed soon. I do know that one of our Remedy IT engineers has created a more modern IDL editor for Eclipse but due to lack of funding this work is not available publicly.
I'm using
flite1.4-iphone
in my application for text to speech. I'm following this link- see here
but i get the error
Lexical or preprocessor Issue: flite.h not found
Yes i searched google for this and apply all the solutions that i found like- close Xcode and reopen, clean project etc etc, but still cant found solution.
Can anyone help me please?
Thanks.
The problem is that the compiler cannot find flite.h; looking at sfoster/iPhone TTS, it seems the file is supplied in the flite-1.4-iphone/include/ directory.
To make the compiler find the file, add the directory where flite.h is in (e.g., $(SRCROOT)/flite-1.4-iphone/include/ to the project's Header Search Paths. (see this SO Q&A for details on how to modify the path).
I have created a WiX project that installs a bunch of different EXEs and DLLs. Unfortunately when I build the project I receive the following warning for each one of them:
ICE60: The file fileName is not a
Font, and its version is not a
companion file reference. It should
have a language specified in the
Language column.
I have found examples and possible solutions for this and each time it is suggested to set the DefaultLanguage tag to 0 in order to fix the warning. Once doing that I then get this warning:
The DefaultLanguage '0' was used for
file 'fileName' which has no language
or version. For unversioned files,
specifying a value for DefaultLanguage
is not neccessary and it will not be
used when determining file versions.
Remove the DefaultLanguage attribute
to eliminate this warning.
How can I handle this warning?
I beileve you are stuck with the warning until the executables are updated. Not helpful, I know, but I would focus on fixing the executables rather than trying to hack the Windows Installer.
The answer is to use something besides Wix. Having an test for a condition which the developer has no means to solve anyway, is a fruitless search for perfection that just results in wasting peoples time. In the end, your installer will work fine with this warning, and the warning being there will lead to you missing some other warning because you over looked it in the stream of useless output produced by this warning.
There is no value in demanding language when there is no net use of that language to fix the users life. The executable still run, they still produce the same results and they still have no support for language. So, why would this test, with an unquenchable warning, really add value to the developer or users life?