Welcome to Spring Roo. For assistance press CTRL+SPACE or type "hint" then hit ENTER.
roo> Lexical error at line 21, column 39. Encountered: "\u2013" (8211), after : ""
How to restore the index?
now, when I upgrade to Roo 1.2.1 the error message is gone but I get roo> null with the same effect: no *.aj sources are generated and woven.
The code is fine, I've checked it out on two other different machines where all .aj were generated, no error message.
Hypothesis 1: it has to do with windos/ linux character interpetation. On Linux it worked, under Windows error
Solved the mystery.
In one of the tests I declare a german constant with 'umlaute': ö is the culprit not en-dash.
So the parser for aspect generation reads this and can't cope with it. It's a bug IMHO, especially I hate the fact that the exception can't tell which sequence of characters is surounding the culprit. That would really kill debugging time.
Interestingly on Linux no problems.
Related
New to VisualStudio 2015, but not to programming. Have searched both Google and here for a lead on this, but considering the available search terms, I might not immediately uncover them.
I was looking into porting an old VB6 (200k+ LoC) to VB.Net in VS2015. Mostly just poking around to determine viability. Using a project converter, and have resolved most of the initial errors, and am familiar with how the Error List works.
However, it is throwing a new one at me. It now only has two lines of error, both showing the same thing. They both say:
" & ErrorName
That's a Quote, Ampersand, and ErrorName. That's all that show up on the error list line. No file. No line number. Double click on them does nothing.
I thought perhaps the project was corrupted, so I completely re-created it, adding all the modules, forms, classes, etc again, and it found a lot more errors to fix, which I fixed, and now these two lines show up again.
Does anyone have any indication where this is coming from, or, better yet, how to fix?
I've seen VB programmers report this misbehavior before, never with a good lead to explain the problem. It is specific to VS2015, the Roslyn integration caused many issues. In general a very buggy release, be sure to apply all available Updates, currently up to Update 3. If you have a license that includes an MSDN subscription then I recommend you install VS2012, the last "good" version of VS that was not yet affected by Microsoft's new focus on agile development.
I think the underlying issue is caused by the IDE simply not parsing the compiler error message correctly. Probably having to do with the statement with the error getting quoted in the message. Getting only part of the statement text and it fumbling quotes is a pretty good hint that this is where it went wrong.
So look at the actual output of the compiler, decent odds you'll now see the full error text. Use Tools > Options > Project and Solutions > Build and Run. Change the "MSBuild output build output verbosity" setting to Normal. After the failed build, use View > Output to see the compiler output. You'll probably have a lot of messages, consider copy/pasting the content.
If there is a problem in the source code, usually a programmer goes through the log manually and tries to identify the problem in the source code.
But is it possible to automate this process? Can we automate the process that would give the potential lines in the source code that was responsible for generating the fault.
So, for example:
If there is some problem in the log file. Then this automation tool should say that this problem has occurred due to line 30,31,32,35,38 in source code ABC
Thanks!!
It depends on the language you are using.
In Java (and probably other JVM languages) this feature is built-in: Every exception that is thrown has a reference to the stack trace, including class, method and line number of every method involved. All you need to do is something like
exception.printStackTrace();
In C and C++, you can use preprocessor macros like __FUNCTION__ or __LINE__ when throwing an exception or writing a log message, for example:
throw "Error in " + __FUNCTION__ + ", line " + std::to_string(__LINE__);
The macros will be replaced by the current function and the current line.
If you are looking for a method that works with any language and any type of logging, there is no good solution. You could run a tool like grep over all source files, that will try to find matches. However this will only work if the log messages appear as string literals in source code at the position where the message is written. This is unlikely because the messages are likely to contain variable values or constants defined somewhere else.
Assuming we are not talking about (unit) testing, because this is what they do - show you where is the problem exactly.
Then this automation tool should say that this problem has occurred due to line 30,31,32,35,38 in source code ABC
In my team we had similar discussion and what we've come with is a Top5 most likely issues document (PlayBook). After reading logs every time on failure, we've noticed that in most of the times there is a requiring pattern. So 8 out of 10 cases the issues were following one of those patterns. So it is possible to trace the latest changes (with the help from Git). If your changes are small and frequent - this approach works quite well.
I just solved a problem which took me way too much time so I thought I share the solution here in case anyone else is biting bricks because of this.
what happened?
I run Pentaho Data Integration 5.2 on CentOS 6.6.
It worked like a charme until I ran yum update the last time.
Now when I was using the graphical interface spoon crashes immediately when I would open an element (e.g. table input) and try to select the query text.
Sometimes it leaves a crash message sometimes not.
Here is the error message:
java: cairo-misc.c:380: _cairo_operator_bounded_by_source: Assertion `NOT_REACHED' failed.
./spoon.sh: line 206: 8922 Aborted (core dumped) "$_PENTAHO_JAVA" $OPT -jar "$STARTUP" -lib $LIBPATH "${1+$#}"
A colleague of mine remembered a quite similar problem he had with his Eclipse and found the solution for me which was to add the following line into spoon.sh into OPT variable:
-Dorg.eclipse.swt.internal.gtk.cairoGraphics=false
It now looks like:
OPT="$OPT $PENTAHO_DI_JAVA_OPTIONS -Djava.library.path=$LIBPATH -DKETTLE_HOME=$KETTLE_HOME -DKETTLE_REPOSITORY=$KETTLE_REPOSITORY -DKETTLE_USER=$KETTLE_USER -DKETTLE_PASSWORD=$KETTLE_PASSWORD -DKETTLE_PLUGIN_PACKAGES=$KETTLE_PLUGIN_PACKAGES -DKETTLE_LOG_SIZE_LIMIT=$KETTLE_LOG_SIZE_LIMIT -DKETTLE_JNDI_ROOT=$KETTLE_JNDI_ROOT -Dorg.eclipse.swt.internal.gtk.cairoGraphics=false"
Now it works again.
Apparently the problem was with the cairo graphics package.
I really love it when stuff doesn't work anymore after updating..
I've come across the below error. This error persists even if I try to use my code on another machine with same version of Xcode 4.2 final. Can any one help?
Console Output
error while killing target (killing anyway): warning: error on line 2184 of "/SourceCache/gdb/gdb-1708/src/gdb/macosx/macosx-nat-inferior.c" in
function "void macosx_kill_inferior_safe()":
(os/kern) failure (0x5x) quit
The debugger is crashing. Crashing debuggers are a world of pain.
Looks like you are using gdb. Try moving to lldb and see if that works around it.
If that doesn't, try nuking your derived data directory as it may be that you have a corrupt symbol that is causing the debugger to crash.
I have no idea what the error is, but googling for the file produces macosx-nat-inferior.c which describes itself as being a part of GDB. So assuming it is the same file as on your computer, then diving in to it may help solve your issue. However that message appears on line 1981 of the file I found .. so I doubt it is the same one as on your computer. But issues with GDB sound weird.
I handed in a C program which contained a lot of verbose printf debug lines. I always compiled it command line with gcc.
Now it's been turned into an Eclipse-CDT (Helios) project, and my
\n
no longer do carriage returns. I get an unreadable "staircase" in my console.
RCINAHFM. Is there a check box in the IDE I need to modify or do I need to go back and carefully modify hundreds of lines of code?
Any help greatly appreciated.
Bert
RCINAHFM=Remaining calm / I need a hug from Mom
Eclipse does not compile C all by itself. It uses an external compiler for that, usually gcc. So it’s highly unlikely that the compiled program is incorrect, unless the compiler configuration within Eclipse does something very, very weird.
If you get a “staircase”, it sounds as if the new line part is carried out, but no carriage return happens. This might happen under systems that use CR/LF as their line ending, such as DOS/Windows.
Unfortunately, you give way to little detail. Are you using Unix or Windows? Where does the program run, in an XTerm, a Windows DOS console, within the Eclipse console? If the answer is “Eclipse console”, then have you tried running it in another terminal instead; or tried running your original program in the Eclipse console? Are you using printf or some other function?