I'm working on reverse engineering / decompiling an APK file - I was able to use:
http://www.decompileandroid.com/
I'm sure APK tool is a better option (I'd love to hear the reasons why though) but in this instance it worked - sorta.
My problem - and the root of my question/post: is I ended up with over 4000 eclipse errors when I import the source (thankfully they seem to be just a small handful of similar/related errors repeated many many times).
That being said - is there a better method of going about this in order to avoid these errors? (shown below)
Eclipse Errors:
https://docs.google.com/document/d/1gwbZuJ8duQ37JRGeTdqIrv0o_DBNL_xWRxrG9Xxxwy4/edit?usp=sharing
I do not know of any Java decompiler that will reliably produce output that can be "round-tripped" (decompiled, then recompiled). There are a few in active development, my own included, for which you could submit bug reports. In the case of Procyon, type inference has become increasingly broken over time, particularly where generics are concerned. Then there are a host of other problems that primarily affect classes converted from Android format.
JARs created by tools like dex2jar tend to be much harder to process because they produce tricky exception handler tables, oddly ordered blocks, local variable slot sharing, etc. I would recommend trying a few different combinations of tools: straight Android decompilers as well as different dex-to-jar rewriters paired with various Java decompilers. You may find that one combination of tools consistently yields better results than others.
That said, I will reiterate my usual advice: never trust the output from a decompiler. Do not assume it is correct, even if it compiles cleanly.
This one is related to my previous post. My problem is that after I put messages in ValidationMessages.properties in languages other than English (Ukrainian and Czech in my case) I got messed up characters in the end. The encoding of all those ValidationMessages.properties files in the bundle is UTF-8, the same as I use for the other translations, and those work well.
I had a similar issue when reading UTF-8 properties files server-side using the ResourceBundle class. Java assumes that properties files are ISO-8859-1, while GWT assumes they are UTF-8. Oddly enough, there is no "one liner" way to tell java to read it as UTF-8. I ended up implementing this solution for reading it server-side and it works well for me, despite it not being as simple as one would hope.
After taking a look on the Hibernate Validation library and its contents I noticed that there are default translations for languages like Czech and Hungarian and they use JavaScript Unicode notation (like \u0000) for special characters. Looks ugly but works.
I don't know what exactly solved the problem, but as I moved from the GWT Validation to the Hibernate Validation libraries it helped.
I know TextWrangler shows the option, but it doesn't actually do anything. So what I want is autocomplete, either with a key combination, or while I type.
Syntax coloring/highlighting is a requirement as well, though I know Xcode and TextWrangler have that.
You might want to use Lua Development Tools for this purpose. It has syntax coloring, plus it is doing smart autocomplete, depending on what your actual context is (required modules, ...)
It is an Eclipse Technology project, and it is Open Source! (EPL license).
Project web page - http://www.eclipse.org/koneki/ldt
Installation via Eclipse Marketplace - http://marketplace.eclipse.org/content/lua-development-tools-koneki
I don't know if you have seen this page, but it seems a good place to start:
http://lua-users.org/wiki/LuaEditorSupport
If I search for "completion" I get:
Decoda (Win)
LuaEdit (Win)
DForD (Win)
NsEditor (Win)
Visual Studio + LuaLite
Eclipse + LuaEclipse or LunarEclipse (java)
I personally use Vim + SuperTab (which only auto-fills with things that you have previously written).
There's a nice plugin for IntelliJ IDEA for Lua. IntelliJ IDEA is really nice, though kind of biggish.
Aside of that there is also TextAdept which is a lot smaller, and 100% configurable in Lua.
And probably a bunch of others.
If you want full (semantic) autocompletion, you should try lua-inspect (source code), which can be installed in the SciTE editor, and also into ViM using vim-lua-inspect.
It uses Metalua to fully parse the source code into AST and then performs code analysis. Apart from simple keyword-based syntax highlighters, it can:
differentiate between local/global variables, parameters and unused variables
jump to the definition of a variable/function
autocomplete table members
correctly rename variables/functions (not only definitions but also uses)
Even though it is not yet stable, and tends to hang on large scripts, it is very usable for standard Lua programs, mainly for it's intelligent autocompletion and renaming.
I am working on writing an IDE for Scala and need some help. I would like to implement coding assistance so that I could present a list of options when a user presses a period (".") or a space (" "). e.g. if projects is a List, as soon as user types "projects." or "projects ", I would like to show all methods of scala.List that he could use (regular IDE stuff). I know that scala.tools.nsc.interactive package provides this capability, but I am unable to figure out how to do it. Besides, it seems that the interactive package would use REPL and would be slow for this purpose. Is that a fair assumption, and if yes, are there any alternatives?
Also, is there a way I could get a call reference tree for a literal/ method (where all is the method referred to in a code base) ?
Thanks and Best regards
Aishwarya
Well, your best bet is going through the same set of links I provided in answer to this question, even though the questions are different.
Yes, the presentation compiler under scala.tools.nsc.interactive is where the reusable functionality would be.
The presentation compiler is used by Eclipse and ENSIME. May be ENSIME itself which in addition to providing emacs support also provides a server as a backend for an editor would be a good avenue.
The presentation compiler is not slow. It was designed from the ground up to provide good performance for Eclipse and it has largely delivered on this goal.
For some of the presentation compiler capabilities, see scala.tools.nsc.interactive.CompilerControl.
For another project using ENSIME, look at Daniel Spiewak's plugin for jEdit.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
As some of you might know I am the lead developer of Padre, The Perl IDE. In the first year of its development, Padre became an acceptable text editor with some extra features for Perl development.
I'd like to ask the Stack Overflow community for some help in driving the project further to turn it into an exceptional IDE for Perl development. So I'd be glad to read what do you think are the most important features of an IDE that are still missing from Padre?.
Especially I'd be interested in people who currently use Eclipse+EPIC, Komodo, Visual Studio, or any of the text editors for programmers.
The most important feature of an IDE for Perl development (including Padre) is:
an interactive debugger that actually works. E.g. remembering breakpoints, ability to drill down into complicated data structures, and copy (to clipboard) should work on watched variables - including a menu command Copy Special that allows putting it in various formats; say CSV, XML or tab-separated.
The two most invaluable features I find:
line-by-line debugging, watchpoints, breakpoints, and so on, so I can properly debug my code.
code completion so I don't have to go looking up docs (even online).
OK, here's my third answer, although I hate to say it.
The competition is pretty easy to install. Padre isn't. I tried to update to the latest release today and, once again, got failing tests.
I am a heavy Perl EPIC user and my biggest gripe is not being able to jump to a function that is clearly defined in the current context (usually by pressing F3). It is pretty
much hit or miss at this point.
Stability. People turn away quickly if their editor crashes and they lose their work.
I work with Komodo. I also use other editors but I come back to Komodo most of the time. A good IDE shoud have:
A good Debugger. Breakpoints, watch lists, everything you need.
Remote debugging. Threads debugging capability.
Syntax highlighting including weighted fonts as well ( I was pretty disappointed by Oxygen, for example, an XSLT IDE, where I can not use bold fonts to emphasize reserved terms)
Syntax completion.
Project management tools, preferable extendable by plugins.
Good VCS integration. This is something that I absolutely love in Eclipse: You instantly see what files have local changes and which aren't added to the repository yet. And you get to browse the different versions and have a nice diff view just one mouse click away.
A project manager. It's essential for me to be able to define the set of files and folders that comprise a particular codebase. Sessions are useful but not a replacement.
Testing integration.
Perl has great unit testing tools. When I run my test suite and get a failure, I want to see the code for the test that failed.
Having a good way to jump through test results and see the code for the failed test along with the expected and actual results would be a great boon.
The first thing I look for is some kind of overview of the currently active file. I'd like to see methods/functions and, if possible, the used modules and especially any use base statements.
You solved that pretty well in Padre.
Visual-Studio style refactoring for variables and function names and extraction of functions.
Visual studio searches your whole module for all references and allows you to see all changed lines in case you do not want to change one instance (for whatever reason)...
The question seems more debatable than answerable.
Risking myself of being accused copyright abuser, I will post contents that I remember from the book "Interactive programming environments" by David R. Barstow, Howard E. Shrobe, Erik Sandewall.
It will not be exactly the same, as I have read the book many years ago and I've jotted down it in another language.
PRINCIPLES OF A GOOD INTERACTIVE PROGRAMMING ENVIRONMENT
1: Know the user
+ Know the previous knowledge and practice of the user
2: Minimize the memorization
+ Selection and not characters entering
+ Names and not numbers
+ Predictable behavior: the user should have a previous impression of what the system will do
+ Possible access and changing of the parameters of the system
3: Optimization of operations
+ Fast execution of common operations
+ Inertia of visualization: the screen should change the less possible
+ Memorization of system operation in user's memory
+ The meaning of specific operations should have a simple relationship with the state of the system
+ The system must be prepared to accept more than 10 followed commands per second, so that it can operate on the user's muscular memory
+ The system should be prepared to organize the parameters of a command
4: Engineer for the errors
+ Provide good error messages.
+ Engineer it to remove away the common errors.
+ The system should provide reversible actions.
+ Redundancy: the operations should have more than one way of being done.
+ Integrity of data structures.
The ability to configure and run external (command-line) tools. Plug-ins are great but end-users won't necessarily want to author one just to integrate with an external tool. Allowing users to configure their own tools provides a great deal of extensibility with minimal barriers to entry.
My editor of choice is UltraEdit. It's not an IDE, but through its support for user tools, I've been able to integrate IDE features such as lint, version control, debugging, and more.
This can be possibly achieved via use strict; but could be as well a valuable feature even if not use'd explicitly, namely:
the other day we spent about 10-20 minutes debugging the following behavior:
my %hash;
$hash->{'key1'} = value1;
# on reading in a different module
print $hash{'key1'}; # is, of course, empty, but was so easy to overlook in the code above
resume:
proper Perl type safety brought in by the IDE.
It might be already implemented in Padre, though, as it turned out not in Eclipse+EPIC
I use emacs. I would like a system that helps me refactor code, especially when I'm working on ugly 1999 code that uses the begin-at-the-beginning-go-to-the-end philosophy combined with duplicate-and-modify.
I looked at Eclipse, but I can't work with a system that requires me to create a project before I can make a one-character correction to a file.
I looked at Padre, but it's slow and crashes.
I looked at Kod which claims to be configured by CSS, but I can't find a man page that will tell me where to put the CSS.
Integration of a read-eval-print loop. As a heavy Emacs user, I very much appreciate Sepia. Very useful for trying things out before I commit them to code.
Ability to create and debug XS code.
The ability to use my own choice of editor (which it may have, as far as I know). That has a chance of winning over the vim/emacs people.
I don't know if Padre can do this, but the ability to split the screen is very important to me. As a VIM user, I constantly split my screen to look at another file while coding.
Line ending policies for files, by directory, and project-wide.
So, for a given project or directory, I'd like to make all line endings be LF only. While in another directory I may wish to have a mix of CRLF and LF files.
I work a lot on stuff that goes back and forth between Unix and Win32 environments.
The typical solution of automatically converting all files back and forth as one moves from platform to platform hasn't worked well for me.
When a file gets created in the wrong format by accident, it can be a real pain.