I'm wondering if it was possible to raise syntax error (or at least warning) in eclipse environment when a specific regex is find ? (Like for example, each time there is the world "dummy" in the code, an error is risen)
Thanks in advance !
Julien.
The short answer is "no". At least, not without some non-trivial tinkering.
Related
I have googled around and looked online and I understand a few criteria would need to be met in order to get this function to work, however, I don't understand why it's able to work in the first place.
Context:
I have a Perl script that I want to integrate into a Perl module. The situation is that I'm new to the language and I'm a bit unsure the difference and I don't understand why this error is coming up in the first place.
The Perl module is this:
https://github.com/slic3r/Slic3r/blob/master/lib/Slic3r/Print/SupportMaterial.pm
I thought I could just add the script into the module and be done, but unfortunately, that is not the case due to the error message. Now to what I know so far as someone new to Perl, you need to declare them "my ..." or remove use strict. I am somewhat interested in the latter since the script is working correctly. Does anyone have any help or tips?
Now to what I know so far as someone new to Perl, you need to declare them "my ..." or remove use strict. I am somewhat interested in the latter since the script is working correctly. Does anyone have any help or tips?
Declaring the variables with my is the right approach. use strict does an number of things - forcing variable declaration is only one of them.
No serious Perl programmer would consider writing code without use strict and use warnings. Removing them is a bad idea.
Is there a way to get ScalaStyle (or any other automation tool) to fix some of the warnings it finds?
For example --
Line contains a tab (shock!!)
There should be a space before the plus (+) sign
File must end with newline character
At a stretch
Public method must have explicit type
As of right now, Scalastyle does not have a way to automatically fix errors. However, it looks like Scalafix might. This is from their documentation:
A scalafix “Rule” can report lint messages and provide auto-fix patches to violations of some kind of rule/coding style/convention/breaking change.
Sounds promising! I have not had a chance to use it yet, but since this question has gotten no replies in almost three years, it seemed worth adding this as a possible solution to your problem if anyone else has a similar issue.
As a Perl beginner I am sometimes getting compilation errors and have to search a lot to find it. In the end it is just a missing semicolon at the end of a line. Some syntax errors with missing semicolon are checked by Perl but not in general. Is there a way to get this check?
edit:
I know about Perl::Critic but can't use it atm. And I don't know if it checks for missing semicolon in general.
Because semicolons actually mean something in Perl and aren't just there for decoration, it's not possible for any tool (even the Perl interpreter itself) to know in every case whether you actually meant to leave off the semi-colon or not. Thus, there's no general-case answer to your question; you'll just need to go through your code and make sure it's correct.
As mentioned in my comments, there are various tricks you can try with your editor to expedite the process of finding potentially-incorrect lines; you must, however, either examine and fix these by hand or risk introducing new problems.
The syntax check is perl -c, but that's no different than attempting to run the program outright. Due to its flexible/undecidable syntax, one cannot generally do what you want. That's the downside of comfort and expressiveness.
Upgrade to the latest stable Perl, the parser's error messages got better/more exact over the last years and will correctly recognise many circumstances of a missing semicolon.
Rule of thumb that works for many parsers/other languages: if the error makes no sense, look a couple of lines before.
use diagnostics; usually gives you a nice hint, same as use warnings;. Try to keep a consistent coding style, check perlstyle.
Also you can use Perl::Critic online.
Also as general advice learn how to use packages and modules, try to group code into subs and study the syntax of arrays, lists and hashes. A common mistake is forgetting the ; after an anonymous hashref assignment:
my $hashref = { a => 5, b => 10};
I know I risk asking a speculative question, however, inspired by this recent question I wonder which editor does the best job of syntax highlighting Perl. Being well aware of the difficulties (impossibilities) of parsing Perl I know there will not be a perfect case. Still I wonder if there is a clear leader in faithful representation.
N.B. I use gedit and it works fine, but with known issues.
Komodo Edit does a good job and also scans your modules (including those installed via CPAN) and does well at generating autocomplete data for them.
I'm a loyal vim user and rarely encounter anything odd with the native syntax.vim, except for these cases (I'll edit in more if/when I find them; others please feel free also):
!!expression is better written !!!!expression (everything after two ! is rendered as a comment quoted string; four ! brings everything back to normal)
m## or s### renders everything after the # as a comment; I usually use {} as a delimiter when avoiding / for leaning toothpick syndrome
some edge cases for $hash{key} where key is not a simple alphanumeric string - although it's safer to enclose such key names in '' anyway so as to not have to look up the exact cases for when a bareword is treated as a key name
I haven't used it, but Padre should be good since it's written in Perl. IIRC It uses PPI for parsing
jEdit...with the tweaks that I have amassed over the years. It's got the most customizable syntax highlighting I've ever seen.
I use Emacs in CPerl mode. I think it does a terrific job, although similar to Ether's answer, it's not perfect. What's more, I usually use Htmlize to publish highlighted code to the web. It's kind of annoying to use fancier forums like this one that do their own syntax highlighting, since it's not really any easier and the results aren't as good.
In the spirit of the latest podcast where Joel mentioned he'd like some simple questions with possibly interesting answers ...
In the environments we have to programme in today we can't rely on the order of execution of our langauage statements. Is that true? Should we be concerned?
Will 30 GOTO 10 always go to 10?*
*I didn't use 20 on purpose ;)
[edit] for the four people voting for closure of this question ...
"Runtime compilers use profiling information to help optimize the code being compiled. The JVM is permitted to use information specific to the execution in order to produce better code, which means that the compiling method M in one program may generate different code than compiling M in another"
(from Java concurrency in practice, 2006, Goetz et al)
.. have a look at "monomorphic call transformation"
[edit]
and another edit, your processor is allowed to swap the order of execution of statements ...
No, it will not. But it will always behave as if it did. One of the basic rules in compiler design is the "as if" rule. Your compiler can make whatever changes it likes, as long as the result is going to behave as if you'd followed the language rules.
GOTO 10 may decide to jump to some other location, as long as the compiler can guarantee that it won't change the outcome of the program.
So no, it shouldn't worry you.
Not if you've got
40 COMEFROM 30
somewhere in your code.
Well, it won't if it doesn't execute, for example if there's a 20 GOTO 40.
In BASIC, yes. In other languages, it will generate a compile error.
What are you trying to say? Anyone claiming to be a programmer should know (especially after your hint) that it depends on what's on lines 10 and 20, and anyone who's been on SO for longer than a week should realize that this question doesn't seem to add much.
We should rely on the code doing exactly what we tell it to. If we tell it to GOTO 10 on line 30, but also tell it to skip line 30, we shouldn't be the least surprise when line 30 is skipped. We told the program to.
True, if you consider multi-core CPUs executing a BASIC program, one of the cores might accidentally miss the GOTO (hint: "TLB Bug") and continue as if it weren't there.