I have alreay read this discussion, but it didn't help me.
start with file;
file ::= primario SEP secondario SEP terziario EOF {:fm.scriviDebug();:};
Where fm.scriviDebug() is a my custom class that prints on stdout what CUP parsed.
I have no idea where is the problem.
Some infos:
I use JFLex to scan a file and passing symbols to CUP in the following way:
...
{bo} {System.out.println("[BO] ["+yytext() +"]");return symbol(sym.BO);}
{bc} {System.out.println("[BC] ["+yytext() +"]");return symbol(sym.BC);}
{sc} {System.out.println("[SC] ["+yytext() +"]");return symbol(sym.SC);}
{eq} {System.out.println("[EQ] ["+yytext() +"]");return symbol(sym.EQ);}
...
I get more than one warning of the following type:
Warning in file "Scanner.jflex" (line 115):
Expression matches the empty string, which may lead to non-termination.
.* {
This is what I get while "compiling" CUP:
Opening files...
Parsing specification from standard input...
Error at 63(73): java_cup.runtime.Symbol "EOF" has not been declared
Closing files...
------- CUP v0.10k Parser Generation Summary -------
1 error and 0 warnings
20 terminals, 14 non-terminals, and 18 productions declared,
producing 0 unique parse states.
0 terminals declared but not used.
0 non-terminals declared but not used.
0 productions never reduced.
0 conflicts detected (0 expected).
No code produced.
---------------------------------------------------- (v0.10k)
Another error after compiling CUP fails:
cannot find symbol
{ return new java_cup.runtime.Symbol(sym.EOF); }
Please, tell me if more info are required.
Related
I have the following Java class
public class HelloWorld {
public static void main(String []args) {
}
}
When I compile this file and run a sha256 on the resulting class file I get
9c8d09e27ea78319ddb85fcf4f8085aa7762b0ab36dc5ba5fd000dccb63960ff HelloWorld.class
Next I modified the class and added a blank line like this:
public class HelloWorld {
public static void main(String []args) {
}
}
Again I ran a sha256 on the output expecting to get the same result but instead I got
11f7ad3ad03eb9e0bb7bfa3b97bbe0f17d31194d8d92cc683cfbd7852e2d189f HelloWorld.class
I have read on this TutorialsPoint article that:
A line containing only white space, possibly with a comment, is known as a blank line, and Java totally ignores it.
So my question is, since Java ignores blank lines why is the compiled bytecode different for both programs?
Namely the difference in that in HelloWorld.class a 0x03 byte is replaced by a 0x04 byte.
Basically, line numbers are kept for debugging, so if you change your source code the way you did, your method starts at a different line and the compiled class reflects the difference.
You can see the change by using javap -v which will output verbose information. Like other already mentioned the difference will be in line numbers:
$ javap -v HelloWorld.class > with-line.txt
$ javap -v HelloWorld.class > no-line.txt
$ diff -C 1 no-line.txt with-line.txt
*** no-line.txt 2018-10-03 11:43:32.719400000 +0100
--- with-line.txt 2018-10-03 11:43:04.378500000 +0100
***************
*** 2,4 ****
Last modified 03-Oct-2018; size 373 bytes
! MD5 checksum 058baea07fb787bdd81c3fb3f9c586bc
Compiled from "HelloWorld.java"
--- 2,4 ----
Last modified 03-Oct-2018; size 373 bytes
! MD5 checksum 435dbce605c21f84dda48de1a76e961f
Compiled from "HelloWorld.java"
***************
*** 50,52 ****
LineNumberTable:
! line 3: 0
LocalVariableTable:
--- 50,52 ----
LineNumberTable:
! line 4: 0
LocalVariableTable:
More precisely the class file differs in the LineNumberTable section:
The LineNumberTable attribute is an optional variable-length attribute in the attributes table of a Code attribute (§4.7.3). It may be used by debuggers to determine which part of the code array corresponds to a given line number in the original source file.
If multiple LineNumberTable attributes are present in the attributes table of a Code attribute, then they may appear in any order.
There may be more than one LineNumberTable attribute per line of a source file in the attributes table of a Code attribute. That is, LineNumberTable attributes may together represent a given line of a source file, and need not be one-to-one with source lines.
The assumption that "Java ignores blank lines" is wrong. Here is a code snippet that behaves differently depending on the number of empty lines before the method main:
class NewlineDependent {
public static void main(String[] args) {
int i = Thread.currentThread().getStackTrace()[1].getLineNumber();
System.out.println((new String[]{"foo", "bar"})[((i % 2) + 2) % 2]);
}
}
If there are no empty lines before main, it prints "foo", but with one empty line before main, it prints "bar".
Since the runtime behavior is different, the .class files must be different, regardless of any timestamps or other metadata.
This holds for every language that has access to the stack frames with line numbers, not only for Java.
Note: if it's compiled with -g:none (without any debugging information), then the line numbers will not be included, getLineNumber() always returns -1, and the program always prints "bar", regardless of the number of line breaks.
As well as any line number details for debugging, your manifest may also store the build time and date. This will naturally be different every time you compile.
these are the last lines of log and io hope anybody can help me cause i am neewbie but really wanna learn this to make my own roms for me and my friends
I have search a lot of time on google but need a bit more cause i dont make any changes its the original source code sync´d 1:1
where i must make changes ? and what i must change?
im sorry for my bad english i am german.
Copy: apicheck (/home/schnittenberg/slim/out/host/linux-x86/obj/EXECUTABLES/apicheck_intermediates/apicheck)
Install: /home/schnittenberg/slim/out/host/linux-x86/bin/apicheck
Checking API: checkpublicapi-last
Checking API: checkpublicapi-current
/home/schnittenberg/slim/out/target/common/obj/PACKAGING/public_api.txt:1700: error 17: Field android.R.id.monitor_box has changed value from 16908334 to 16908337
/home/schnittenberg/slim/out/target/common/obj/PACKAGING/public_api.txt:1706: error 17: Field android.R.id.seek_bar has changed value from 16908335 to 16908338
/home/schnittenberg/slim/out/target/common/obj/PACKAGING/public_api.txt:22817: error 3: Added class SlimSeekBarPreference to package android.preference
/home/schnittenberg/slim/out/target/common/obj/PACKAGING/public_api.txt:25299: error 5: Added public field android.provider.Settings.Global.POLICY_CONTROL_SELECTED
/home/schnittenberg/slim/out/target/common/obj/PACKAGING/public_api.txt:25509: error 5: Added public field android.provider.Settings.System.USE_NON_INTRUSIVE_CALL
/home/schnittenberg/slim/out/target/common/obj/PACKAGING/public_api.txt:25511: error 5: Added public field android.provider.Settings.System.VOLUME_ADJUST_SOUND
/home/schnittenberg/slim/out/target/common/obj/PACKAGING/public_api.txt:35624: error 4: Added public method android.view.inputmethod.EditorInfo.formalTextInput
You have tried to change the API from what has been previously approved.
To make these errors go away, you have two choices:
1) You can add "#hide" javadoc comments to the methods, etc. listed in the
errors above.
2) You can update current.txt by executing the following command:
make update-api
^^^^^^^^^^^^^^^^^^
NO. NO. STOP BEING LAZY. SERIOUSLY.
DO NOT DO THIS in CM. THIS IS A LIE. IT WILL BREAK THINGS.
To submit the revised current.txt to the main Android repository,
you will need approval.
build/core/tasks/apicheck.mk:62: recipe for target '/home/schnittenberg/slim/out/target/common/obj/PACKAGING/checkpublicapi-current-timestamp' failed
make: *** [/home/schnittenberg/slim/out/target/common/obj/PACKAGING/checkpublicapi-current-timestamp] Error 38
make failed to build some targets (01:18 (mm:ss))
OUT_DIR=/home/schnittenberg/slim/out
find: "dummy": Datei oder Verzeichnis nicht gefunden
build/core/Makefile:46: warning: overriding recipe for target '/home/schnittenberg/slim/out/target/product/amami/system/etc/mkshrc'
build/core/base_rules.mk:550: warning: ignoring old recipe for target '/home/schnittenberg/slim/out/target/product/amami/system/etc/mkshrc'
No private recovery resources for TARGET_DEVICE amami
Docs droiddoc: /home/schnittenberg/slim/out/target/common/docs/doc-comment-check
frameworks/base/core/java/android/widget/SeekBar.java:43: error 101: Unresolved link/see tag "ProgressBar#setMax(int)" in android.preference.SlimSeekBarPreference
frameworks/base/telecomm/java/android/telecom/TelecomManager.java:36: error 108: Link to hidden class: PhoneAccount label=PhoneAccount
DroidDoc took 329 sec. to write docs to /home/schnittenberg/slim/out/target/common/docs/doc-comment-check
build/core/droiddoc.mk:158: recipe for target '/home/schnittenberg/slim/out/target/common/docs/doc-comment-check-timestamp' failed
make: *** [/home/schnittenberg/slim/out/target/common/docs/doc-comment-check-timestamp] Error 45
make failed to build some targets (06:51 (mm:ss)) ####
Platform: Windows 7 x64
JDK version: 7.0.25 x64 or 7.0.45 x64
JDK installation path:
C:\Java\jdk725 or default c:\Program Files\Java\jdk1.7.0_25\
Spring Framework Release: 3.2.4 or 3.2.5
UAC: enabled or disabled
gradlew build (after gradlew):
:referenceHtmlMulti FAILED
FAILURE: Build failed with an exception.
What went wrong:
Execution failed for task ':referenceHtmlMulti'.
Failed to compile stylesheet. 59 errors detected.
Try:
Run with --info or --debug option to get more log output.
Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':referen
ceHtmlMulti'.
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.ex
ecuteActions(ExecuteActionsTaskExecuter.java:69)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.ex
ecute(ExecuteActionsTaskExecuter.java:46)
..
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:130)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:48)
Caused by: javax.xml.transform.TransformerConfigurationException: Failed to comp
ile stylesheet. 59 errors detected.
at com.icl.saxon.PreparedStyleSheet.prepare(PreparedStyleSheet.java:136)
at com.icl.saxon.TransformerFactoryImpl.newTemplates(TransformerFactoryI
mpl.java:127)
at com.icl.saxon.TransformerFactoryImpl.newTransformer(TransformerFactor
yImpl.java:79)
..
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.ex
ecuteAction(ExecuteActionsTaskExecuter.java:80)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.ex
ecuteActions(ExecuteActionsTaskExecuter.java:61)
... 70 more
BUILD FAILED
My question is: why did my build fail?
The problem happens when :referenceHtmlMulti task is executing.
If we look in groovy class we will see that XSLT transformation is used to create docbook-reference. Despite the fact, that Saxon is used (TransformerFactoryImpl is selected) the choosen SAXParserFactory is org.apache.xerces.jaxp.SAXParserFactoryImpl (I wonder why not to use com.icl.saxon.aelfred.SAXParserFactoryImpl).
IF we look what implementation of xerces is used by gradle we will see xercesImpl-2.9.1.jar, which is old enough.
Now let's find class URI in xerces sources. It represents a Uniform Resource Identifier (URI). On line 1134 we can find
else if (!isURICharacter(testChar)) {
throw new MalformedURIException(
"Opaque part contains invalid character: " + testChar);
}
Now let's look how this function works:
private static boolean isURICharacter (char p_char) {
return (p_char <= '~' && (fgLookupTable[p_char] & MASK_URI_CHARACTER) != 0);
}
We can see that function will return true if char comparision will return true also. But that means rather close limits of chars (from code 0 - 126 (~)). But what about non US-ASCII character set?
Let's read RFC 2396 about non us-ascii characters (that can exist in your windows path, representing your local language or can be found in account name, under which gradle unpacks itself and works): other catagory - The Unicode characters that are not in the US-ASCII character set, are not control characters (according to the Character.isISOControl method), and are not space characters (according to the Character.isSpaceChar method) (Deviation from RFC 2396, which is limited to US-ASCII). The set of all legal URI characters consists of the unreserved, reserved, escaped, and other characters.
So. URI identification fails. And that is the place where build code fails.
There are 2 solutions:
To make your account name or path consist only of US-ASCII characters.
To patch URI class (for example, by rewriting function isURICharacter)
I'm trying to link my Android app with a JAR that was compiled with Free Pascal. I'm getting the following build error:
[2012-09-14 16:08:38 - MyApp] Dx
EXCEPTION FROM SIMULATION:
[2012-09-14 16:08:38 - MyApp] Dx local 0009: invalid
[2012-09-14 16:08:38 - Yarxi] Dx ...at bytecode offset 00015f2c
locals[0000]: Lcom/mypackage/$Core$$_fpc_nestedvars$70;
locals[0001]: I
locals[0002]: I
locals[0003]: I
locals[0004]: I
locals[0005]: I
locals[0006]: I
locals[0007]: I
locals[0008]: I
locals[0009]: <invalid>
locals[000a]: <invalid>
(..more locals... much more)
locals[06db]: <invalid>
stack[0003]: I
stack[0002]: I
stack[0001]: [I
stack[top0]: int{0x00000000 / 0}
...while working on block 5f23
...while working on method $MyMethod$944$FPR1:(Lcom/mypackage/$Core$$_fpc_nestedvars$70;)V
...while processing $MyMethod$944$FPR1 (Lcom/mypackage/$Core$$_fpc_nestedvars$70;)V
...while processing com/mypackage/Core.class
[2012-09-14 16:08:40 - MyApp] Dx 1 error; aborting
[2012-09-14 16:08:40 - MyApp] Conversion to Dalvik format failed with error 1
The error seems to be that at some point, the code tries to read local 0009, which is not initialized.
Now, Pascal does not enforce initialization of local variables. Chances are, initialization was omitted in the first place. I've retained the JVM assembly file that Free Pascal generated for me. Those are assembled with Jasmin into class files. The file is huge - I'm not pasting it here.
Can someone please help me trace back the point of error to the source? The error is at bytecode offset 00015f2c. Is there a way to translate that back into assembly file line number?
Resolved. 00015f2c (89900 decimal) is, indeed, a bytecode offset within a method. I did the following.
First, I called Jasmin directly, passing the generated .j file and the -g option (generate line numbers):
java -jar %JASM% -g Core.j
Free Pascal does not emit -g by itself. This gave me an alternative Core.class file with line numbers in it, line numbers being relative to the FPC-generated .j file. Then I used javap to disassemble the class back into another .j file:
"%JDKROOT%\javap" -l -c Core.class >Core_WithLines.j
But this new .j file contained line numbers and offsets of each individual command. I then searched for offset 89900 in the offending method (note: offsets, as generated by javap, wrap at 65536). Then I looked at the LineNumberTable below that method's body (both offsets and line numbers wrap), found the line number in the source Core.j file that corresponded to this offset. Looked back at Core.j, and there was a comment that contained the line number of the Pascal source.
There was, indeed, a function call that passed an uninitialized variable - but as a var parameter.
The issue is something of a Pascal/JVM borderline issue. The variable was uninitialized, but it was passed by ref into a function to be returned from the latter. The compiler should've abstracted that away somehow, IMHO, but FPC did not.
I have the following Velocity template in JIRA (note, extra lines kept in):
NOTE: Please REPLY-TO this email when replying to this issue.
##parse("templates/email/includes/issueplugins.vm")
#if($comment.getId())[ ${baseurl}/browse/${issue.getKey()} ] #end ##?page=${tabpanel-comment}&focusedCommentId=${comment.getId()}#action_${comment.getId()} ] #end
#if($remoteUser.fullName)
$i18n.getText("template.issue.commented.on", $remoteUser.fullName, $issue.getKey())
#dashes($!remoteUser.fullName)--------------#dashes($issue.getKey())-
#end
#if($changelog)
#changes([])
#end
#comment()
#visibility()
#parse("templates/email/text/includes/issuesummary.vm")
#parse("templates/email/text/includes/footer.vm")
There is no line following that last line. When do I this on the very last line:
##parse("templates/email/text/includes/footer.vm")
I get the following error:
An error occurred whilst rendering this message. Please contact the administrators, and inform them of this bug.
Details:
-------
org.apache.velocity.exception.ParseErrorException: Lexical error:
org.apache.velocity.runtime.parser.TokenMgrError:
Lexical error at line 20, column 51. Encountered: <EOF> after : ""
at org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:272)
at org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:202)
...
I found the following issue from 2004:
https://issues.apache.org/jira/browse/VELOCITY-272
Which seems to suggest this was a bug fixed in 1.5. Checking in my JIRA System Info, I see that JIRA 4.2.1 appears to suggest version 1.6 is in use:
Atlassian Template Renderer Velocity 1.6 Plugin - 1.1.1
When I move the line starting #if($comment.getId()) to the end, the error goes away. Am I doing something wrong here at the end of the template, or is this a bug?
EDIT
Hmm. When I did this:
#if($comment.getId())[ ${baseurl}/browse/${issue.getKey()} ] #end ##?page=${tabpanel-comment}&focusedCommentId=${comment.getId()}#action_${comment.getId()} ] #end
As the last line, with no empty line following it, I got the same error. However, if I add a line after that line (just hit ENTER once), it works.
Do Velocity template's require an ending space? I'm confused.
~/tech/atlassian/atlassian-jira-4.4.1-standalone $ find . -name "*velocity*.jar"
./atlassian-jira/WEB-INF/lib/velocity-1.4-atlassian-9.jar
./atlassian-jira/WEB-INF/lib/velocity-tools-1.3.jar
./atlassian-jira/WEB-INF/lib/atlassian-velocity-0.8.jar
And no, they haven't; see this discussion from a few days ago..