This seems to be a simple matter and maybe it's solved already, but I'm not sure how to do it. I'd like to keep arbitrary unresolved expressions for later evaluation. Note that I still don't know which expressions are already defined.
For example, suppose I have the expression...
{{source.path}}/mainmenu{{ext}}"
...and the context defines ext as .js, but source.path is still undefined. What I get is/mainmenu.js", but I'd like to get {{source.path}}/mainmenu.js" instead so that I can evaluate {{source.path}} at a later time. HandlebarsConfiguration.UnresolvedBindingFormatter seemed promising, but it doesn't handle the complete original expression. HandlebarsConfiguration.ExpressionNameResolver also didn't help.
So, is it possible to do this at all? Thanks in advance for any help.
Related
I obfuscated this script using some site
But i'm wondering how to deobfuscate it? can someone help me?
i tried using most decompilers and a lot of ways but none has worked
local howtoDEOBFUSCATEthis_Illll='2d2d341be85c64062f4287f90df25edffd08ec003b5d9491e1db542a356f64a488a1015c2a6b6d4596f2fa74fd602d30b0ecb05f4d768cd9b54d8463b39729eb1fe84630c0f8983f1a0087681fe4f2b322450ce07b
something like that for an example.
the whole script: https://pastebin.com/raw/fDGKYrH7
First reformat into a sane layout. a newline before every local and end will do a lot. Then indenting the functions that become visible is pretty easy.
After that use search replace to inline constants. For example: local howtoDEOBFUSCATEthis_IlIlIIlIlIlI=8480; means you can replace every howtoDEOBFUSCATEthis_IlIlIIlIlIlI with 8480. Though be careful about assignments to it. If there are any then it's better to rename the variable something sensible.
If an identifier has no match you can delete the statement.
Eventually you get to functions that are actually used.
Looking at the code it seems to be an interpreter implementation. I believe it's a lua interpreter
Which means that you'll need to verify that and decompile what the interpreter executes.
In code that I help maintain, I have found multiple examples of code that looks like this:
Description := IfThen(Assigned(Widget), Widget.Description, 'No Widget');
I expected this to crash when Widget was nil, but when I tested it, it worked perfectly.
If I recompile it with "Code inlining control" turned off in Project - Options - Compiler, I do get an Access Violation.
It seems that, because IfThen is marked as inline, the compiler is normally not evaluating Widget.Description if Widget is nil.
Is there any reason that the code should be "fixed", as it doesn't seem to be broken? They don't want the code changed unnecessarily.
Is it likely to bite them?
I have tested it with Delphi XE2 and XE6.
Personally, I hate to rely on a behavior that isn't contractual.
The inline directive is a suggestion to the compiler.
If I understand correctly what I read, your code would also crash if you build using runtime packages.
inlining never occurs across package boundaries
Like Uli Gerhardt commented, it could be considered a bug that it works in the first place. Since the behavior isn't contractual, it can change at any time.
If I was to make any recommendation, I would flag that as a low priority "fix". I'm pretty sure some would argue that if the code works, it doesn't need fixing, there is no bug. At that point, it becomes more of a philosophical question (If a tree falls in a forest and no one is around to hear it, does it make a sound?)
Is there any reason that the code should be "fixed", as it doesn't seem to be broken?
That's really a question that only you can answer. However, to answer it then you need to understand fully the implications of reliance on this behaviour. There are two main issues that I perceive:
Inlining of functions is not guaranteed. The compiler may choose not to inline, and in the case of runtime packages or DLLs, a function in another package cannot be inlined.
Skipping evaluation of an argument only occurs when the compiler is sure that there are no side effects associated with evaluation of the argument. For instance, if the argument involved a function call, the compiler will ensure that it is always evaluated.
To expand on point 2, consider the statement in your question:
Description := IfThen(Assigned(Widget), Widget.Description, 'No Widget');
Now, if Widget.Description is a field, or is a property with a getter that reads a field, then the compiler decides that evaluation has no side effects. This evaluation can safely be skipped.
On the other hand, if Widget.Description is a function, or property with a getter function, then the compiler determines that there may be side effects. And so it ensures that Widget.Description is evaluated exactly once.
So, armed with this knowledge, here are a couple of ways for your code to fail:
You move to runtime packages, or the compiler decides not to inline the function.
You change the Description property getter from a field getter to a function getter.
If it were me, I would not like to rely on this behaviour. But as I said right at the top, ultimately it is your decision.
Finally, the behaviour has been changed from XE7. All arguments to inline functions are evaluated exactly once. This is in keeping with other languages and means that observable behaviour is no longer affected by inlining decisions. I would regard the change in XE7 as a bug fix.
It already has been fixed - in XE7 and confirmed that this was supposed to be wrong behavior.
See https://quality.embarcadero.com/browse/RSP-11531
I just splited a project in a few libraries.
And I have the strange error in the title.
I can't explain myself why it is the case.
Also, this error used to show up only in FSI.exe
I thought it was because of pb with loading dll in fsi but there is more to this.
It might be a stupid error (probably is..) but if anyone encoutered this sybillin error message before and knows what happens, I'd be glad to hear it.
UPDATE
I thought it was namespace issues, but it is not.
This issue is very odd. Please ignore it if you did not experienced it. I am still trying to pinpoint the exact origin.
Without more information it's hard to know for sure. One way this could happen is if you end up redefining a type in FSI without redefining some things that depend on it. Then those things expect the old version of the type, but you end up creating instances of the new version, which are not compatible. For instance, given this code:
type MyType<'a>() = class end
let myFun (_:MyType<int>) = 0
let result = myFun (MyType())
If I send the first two lines to FSI, then the first line again by itself, and then the third line, I get something similar to your error message. The solution is to re-evaluate all dependent definitions.
I've got MMM-mode set up to edit .html.erb files, but indentation does not work in the ruby sections, and all the different electric behaviours of ruby-mode do the wrong thing. I've changed this sub-mode from ruby-moode to fundamental-mode, and it works much better.
I want to still use ruby-mode's font-locking though, is this possible/easy? Any hints on where to start.
Elisp is comfortable to me, but I don't have too much time right now to dig too deeply myself. Hopefully someone will have a snippet?
I see you haven't yet found an answer. Dunno whether it will be better for this, but you might consider using MuMaMo instead of MMM.
To answer the question, you would define a major mode deriving from fundamental-mode, and in its body just copy the font-lock-related lines from the ruby-mode definition body, the ones setting font-lock- variables and also syntax-propertize-function. Naturally , you need to (require 'ruby-mode) somewhere.
But for .html.erb files I can now recommend using mmm-erb, which was not available when this question was asked.
I've been using Netbeans for Rails and like it a lot, considering how little I paid for it. But something that bothers me is that when I'm editing an RHTML or ERB file, it doesn't do the code autocomplete - or at least not reliably. Sometimes it shows the appropriate variables and methods that are available on an object after you type the dot operator. Sometimes it ignores the instance variables. Is there a solution for this? (Please don't say RadRails).
Oh and one more thing in case anyone has solved this: considering how often I have to type <% when I'm in a Rails template, I wish there was some hotkey for autotyping the tag . . . ? I always have to stop and look down at my keyboard to find the < and % keys before I can type the tag so it's not as trivial as it might sound.
I believe you're looking for something like this:
http://ruby.netbeans.org/codetemplates-rhtml.html
Type in one of the triggers, then hit the tab key to expand it to the code as given.
Also, you might want to explore using HAML. It's much easier on the hands.