How can I make emacs libraries use request.el instead of url.el? - http

Some libraries, e.g. xml-rpc, directly use url-retrieve. I want them to instead use request.el, so that I can choose curl as my backend. Is there an easy shim-layer I can install?
I'm looking for something like curl-for-url, which transparently rebinds url-http with a compatible implementation. (curl-for-url itself doesn't actually work very well, though.)

You could do this using advice, but you will need to use the
ad-get-arg/ad-get-args functions to extract the arguments url-retrieve was
called with and determine how you want to process them and pass them to the
retrieve function. The one which will likely be problematic is the callback
function. However, provided you can setup the buffer with the downloaded
data in the same way, with the same name as url-retrieve, you should be able to
apply the callback manually after the call to request and you have setup the
buffers as necessary.
It will be a fair bit of work and you will need to dig deep into both the url.el
and request.el libraries. It is also likely to be a bit fragile.
One concern I would have is the use of monkey patching by request.el. From the
project page, it looks like this code has not been updated since Emacs version
25.1 and the current official emacs is 25.2. This is one of the problems with
monkey patching - you need to keep versions in sync to avoid version
incompatibility issues.
It also seems odd to me to have someone who has patches to fix known bugs if
those patches have not been applied to the mainstream version - especially when
there has been a more recent release of the mainstream version.
The first thing I would do is upgrade to emacs 25.2 and then determine if using
request.el is as justified. I would also verify the problems you experience are
actually due to url-retrieve or are perhaps due to callbacks being passed to
that function. If it is a problem with the callbacks, you may be better off
using advice to fix those callbacks rather than replace the underlying
problems.
If you only have issues in some situations where url-retrieve is used, it may
also be easier to go up one level and look at the things which are using it and
perhaps use something like advice to replace the call to url-retrieve with
request at that level.
Someone might be able to provide more specific recommendations if you provide
more detail on the precise reasons you cannot or do not want to use the
url.el library.

Related

What are my chances to get some basic web interaction from a program using Lua for scripts extensibility?

I'm very lost with this matter, so sorry if I'm asking for something too obvious or something, but I've been trying to get some low level info about it and, for what I've seen till now, I wouldn't even know where to start...
Anyway, the case is I'm trying to develop a tool script in Lua that I'd like at some point could be able to do some very basic interaction with a webpage, e.g. for downloading/looking for updates and little more. I'm already aware Lua can't do any of this per se (even I think it totally should at this time of life, but that would be another discussion 🙄), and the only ways I've read about pass for using external libraries/packages like LuaSocket or lua-http.
Well, besides all that external kind of stuff are far beyond my current capabilities in all the senses, how could I make them work anyway if I'm constrained to only can really do what the main app (Moho in this case, internally running Lua 5.2) allows me to do? Or as far as I know at least, because I remember at some point they added the possibility of extending some Lua possibilities by allowing access to a folder called modules where supposedly you could put your own libraries or whatever, not sure if even in form of DLLs, but besides that would also be another level to me, and there is zero documentation on that regard, once again I wouldn't even know where to start... Plus, if I'm going to have to build my own Lua compilation and include a lot of extra files, etc. for such a simple update checking feature... well, as much as I'd like its implementation, it simply could not worth all the mess.
So, once exposed, what do you think are really my changes of getting this super-basic internet interaction from my pure Lua script? Are really 0 as I'm afraid, or do you think I could not be considering other possible ways even if they were not the more efficient or recommendable?

Why does Gremlin JavaScript use "from_" mapping instead of "from"?

I struggled with this for hours before finding out that you have to use from_ instead of from when using gremlin javascript.
After digging through the source code I finally found out that the code is using from_ instead of from (see code). Since I'm a newbie this comes off as strange because its counterpart to is still to (and not to_, see code here)
I googled everywhere but couldn't find the reason why this works this way, and feel uneasy about using the underscore version since most of the times underscores denote private methods that users should not really trust.
Also, is there an official documentation page for gremlin javascript somewhere I'm missing? I'm concerned I may run into these problems in the future and there's not really an official documentation for the JavaScript version and I may need to go through the same struggle. I like gremlin, but if the JavaScript version is not stable and should not be used, I might as well look into other alternatives than Tinkerpop suites.
Gremlin Language Variants (GLVs) are given some latitude in terms of how they implement the Gremlin language so that it feels as close to the syntax and programming idioms of the native language and thus avoid too much pollution from Java. In other words, if you're using gremlin-javascript it should feel like your coding in JS and not Java. So, you will see slight differences among GLVs from time to time.
So, with respect to from_ specifically, we typically use an underscore when we have a conflict in a native language with a reserved keyword. In Java from is fully acceptable, but in other languages it is not. For Javascript, from is currently not a reserved word, but we are preparing for the eventual form of import ... from which is coming in the future.
As for documentation, I'm not aware of too much more than what you have already found on the TinkerPop web site. We hope to have more examples and information available in our next release.

What is the Purpose of Deprecated Code?

I was changing out some PHP code the other day because it was deprecated, and no longer worked. I understand the meaning of deprecated code based on an answer I found here: https://stackoverflow.com/a/8111799/1810777
But several question came to mind:
I was wondering what is the purpose of deprecating code?
Why not just leave it in use, instead of recommending others to use
new alternatives?
Does it slow stuff down?
I couldn't find anywhere else online that talked about it. I'm just really wondering why code that used to work well, isn't useful anymore. Thanks!
It means that in a future release it's going to be removed.
This allows an API developer to give people time to migrate to the new version / method of doing whatever rather than just pulling the rug out from under them. Both the new and the old versions are available for a limited time.
As for why not leave it there forever ... because there's a new, better way to do it. You can't support legacy code forever (if you value your sanity and your budget). All support has a cost (be that tech support hours, bug fixes, regression testing, etc)

Good method to handle large amounts of unused or deprecated feature implemenations in code

Currently we are facing following Problem in our Application:
Around 40 % of the Code that is in the Application is never used. That means the Code would be there, and maybe functional, but the Frontend Feature has been shut off so the Users cannot reach the Functionality anymore or other Methods are replacing the old, now deprecated Methods.
What i am currently doing is removing all the old code while not trying to break anything, manually.
The Question is:
Would you remove the old Code, or hope that it may awake some time ... zombie - like
Do you think that it is worth the Effort to remove the Code (less work to find stuff in the clutter, better test coverage, easier for other people to find their way)
Should we keep the Code somewhere, as a reference? ( We are using Version Control, but i find it is pretty hard to find old code in the Revision Jungle ... any tips for that? )
Do you have arguments for convincing the team / management / developers that wrote said code?
Reasons to not deprecate and then delete Code?
TL;DR: Delete unused code or leave it as it is? Discuss!
u
If you are certain that the code is unused, definitely delete it. I assume you have a version control system, so if you ever need it again, you can still find the code back.
Deleting the unused code will make the project easier to maintain, and your team probably will end up saving time in the long run (nobody will re-read the code to try and understand what it was used for, nobody will end up changing said code thinking it may still be used...)
However, if your code contains a public API that is distributed, you will probably want to mark the classes/methods deprecated for some time before effectively deleting the code, so the callers have some time to adapt (or inform you of the issue).
Would you remove the old Code, or hope that it may awake some time ... zombie - like
I'd definitely remove it. I hate having to work out if functions ever get called.
Do you think that it is worth the Effort to remove the Code (less work to find stuff in the clutter, better test coverage, easier for other people to find their way)
Yes, definitely worth the effort.
Should we keep the Code somewhere, as a reference?
Um, you are using version control softwarev, aren't you?

make your Jar not to be decompiled

How can I package my Java application into an executable jar that cannot be decompiled (for example , by Jadclipse)?
You can't. If the JRE can run it, an application can de-compile it.
The best you can hope for is to make it very hard to read (replace all symbols with combinations of 'l' and '1' and 'O' and '0', put in lots of useless code and so on). You'd be surprised how unreadable you can make code, even with a relatively dumb translation tool.
This is called obfuscation and, while not perfect, it's sometimes adequate.
Remember, you can't stop the determined hacker any more than the determined burglar. What you're trying to do is make things very hard for the casual attacker. When presented with the symbols O001l1ll10O, O001llll10O, OO01l1ll10O, O0Ol11ll10O and O001l1ll1OO, and code that doesn't seem to do anything useful, most people will just give up.
First you can't avoid people reverse engineering your code. The JVM bytecode has to be plain to be executed and there are several programs to reverse engineer it (same applies to .NET CLR). You can only make it more and more difficult to raise the barrier (i.e. cost) to see and understand your code.
Usual way is to obfuscate the source with some tool. Classes, methods and fields are renamed throughout the codebase, even with invalid identifiers if you choose to, making the code next to impossible to comprehend. I had good results with JODE in the past. After obfuscating use a decompiler to see what your code looks like...
Next to obfuscation you can encrypt your class files (all but a small starter class) with some method and use a custom class loader to decrypt them. Unfortunately the class loader class can't be encrypted itself, so people might figure out the decryption algorithm by reading the decompiled code of your class loader. But the window to attack your code got smaller. Again this does not prevent people from seeing your code, just makes it harder for the casual attacker.
You could also try to convert the Java application to some windows EXE which would hide the clue that it's Java at all (to some degree) or really compile into machine code, depending on your need of JVM features. (I did not try this.)
GCJ is a free tool that can compile to either bytecode or native code. Keeping in mind, that does sort of defeat the purpose of Java.
A little late I know, but the answer is no.
Even if you write in C and compile to native code, there are dissasemblers / debuggers which will allow people to step through your code. Granted - debugging optimized code without symbolic information is a pain - but it can be done, I've had to do it on occasion.
There are steps that you can take to make this harder - e.g. on windows you can call the IsDebuggerPresent API in a loop to see if somebody is debugging your process, and if yes and it is a release build - terminate the process. Of course a sufficiently determined attacker could intercept your call to IsDebuggerPresent and always return false.
There are a whole variety of techniques that have cropped up - people who want to protect something and people who are out to crack it wide open, it is a veritable arms race! Once you go down this path - you will have to constantly keep updating/upgrading your defenses, there is no stopping.
This not my practical solution but , here i think good collection or resource and tutorials for making it happen to highest level of satisfaction.
A suggestion from this website (oracle community)
(clean way), Obfuscate your code, there are many open source and free
obfuscator tools, here is a simple list of them : [Open source
obfuscators list] .
These tools make your code unreadable( though still you can decompile
it) by changing names. this is the most common way to protect your
code.
2.(Not so clean way) If you have a specific target platform (like windows) or you can have different versions for different platforms,
you can write a sophisticated part of your algorithms in a low level
language like C (which is very hard to decompile and understand) and
use it as a native library in you java application. it is not clean,
because many of us use java for it's cross-platform abilities, and
this method fades that ability.
and this one below a step by step follow :
ProtectYourJavaCode
Enjoy!
Keep your solutions added we need this more.

Resources