I'm having a hard time wrapping my head around opening and reading from a simple text file in Node.js. Part of my problem is that many of the file system functions require a mysterious [mode] argument. This is apparently a four digit number that... does something. I have no idea what and I can't seem to find a good explanation. I suspect that this is something rather basic to elite node.js hackers, but I'm finding it rather mystifying. Can anyone explain what this argument does?
Related
So I've recently started using Typescript. Both for the back end (nodejs) and front end, and I'm started to feel an urge to chew on my own arm every time I have to add a new import.
Coming from the .NET world the last 15 years I've come to appreciate the more or less automatic type resolving. Especially with a background in C/C++, which whenever I return to, remind me of the #include hell that ever so often becomes the case. Given what I am now facing, I get a feeling of "those were the days".
I typically prefer to keep my code as one class -> one file (with some obv exceptions for smaller stuff). This results in a lot of files and even more imports. I recently discovered some tools that help out creating the imports but it is still really annoying.
I get it that the underlying JS needs these imports (in various ways depending on module system) But given how easy these tools resolves the imports. Would it not be possible for the compiler to simply generate them? In the rare case of ambiguity the compiler would simple give an error and the user needs to resolve it manually.
Typescript seems to be a great language otherwise but this is really close to a deal breaker for me. Or am I missing something? Can this be done in a better way?
This question already has answers here:
Avoid debugging information on golang
(2 answers)
Closed 6 years ago.
i was playing around with go sync groups and i just tried what happens if i add more groups than i mark done . and i get the runtime error i posted below.
So the question here is if go is compiled into true machine code unlike java or c# how come my file even line info can be shown in runtime errors .If file info is kept in the binary i think it can be easily decompiled .
Am i doing something wrong do i need to add some kinda env variable for prod builds or its just like c# theres no true way to hide your code
So for fun, I wrote a trivial Go program that just panic()s and tried farting around with objdump and objcopy to see where this information is. On Linux (perhaps others), Go sticks the relevant info in the ELF section .gopclntab. If you remove it, the reference to the actual program source disappears, but the runtime crashes. And there are references to a ton more runtime.* things in that section (presumably for linkage and introspection). I'm thinking it's unlikely that you can realistically run a Go program with this information totally gone.
You can remove the DWARF info for some security as mentioned elsewhere on SO and a bunch of ELF sections vanish, but your best bet if you're really worried would probably be to preprocess your sources to obfuscate identifiers and filenames before compile. But there doesn't appear to be a ready-made tool to do so.
I'm not one of the Go designers, but I'm guessing going much farther is impractical due to things like introspection (something which e.g. C can't do). Compressors like upx will obfuscate the file at rest slightly (and seem to work OK with compiled Go--maybe a caveat or two in there), but it's trivial to undo if you know it's there (to the point that any security type would take away my developer's licence for my having even mentioned it).
The reality is that the best you can realistically do is speedbump people who are really interested in messing with your code. Obfuscating sources, if you're really that motivated to do it, would be your best bet (though ultimately still futile with sufficiently determined attackers).
I have one silly question that I decided to ask here since Google didn't provide an explanation (or I am using wrong terms, which most likely is the case) and people here have proven to be really helpful before.
Let's say we have 2 different .exe files and I use CodeReflect to view the contents of both files.
First file here, it seems quite normal and easy to read. Nothing wrong with this one.
Second file which makes zero sense to me. I have no idea what's up with this, lots of random characters everywhere. Is this .exe file encrypted or something or why does it look so different? If it's encrypted, is there a simple way to attempt decrypting it?
This one confuses me a lot, I'd really appreciate to get an explanation to this.
Thanks in advance.
This is an obfuscation.
It usually helps to fight agains reverse engineers.
You can try to deobfuscate application with this: http://de4dot.com
UPD: And it was probably obfuscated with ConfuserEx v1 because I see 'ConfusedByAtrribute' element.
I'm working on a fairly simple text-editor for Haskell, and I'd like to be able to highlight static errors in code when the user hits "check."
Is there a way to use the GHC-API to do a "dry-run" of compiling a haskell file without actually compiling it? I'd like to be able to take a string and do all the checks of normal compilation, but without the output. The GHC-API would be ideal because then I wouldn't have to parse command-line output from GHC to highlight errors and such.
In addition, is it possible to do this check on a string, instead of on a file? (If not, I can just write it to a temp file, which isn't terribly efficient, but would work).
If this is possible, could you provide or point me to an example how how to do this?
This question ask the same thing, but it is from three years ago, at which time the answer was "GHC-API is new and there isn't good documentation yet." So my hope is that the status has changed.
EDIT: the "dry-run" restriction is because I'm doing this in a web-based setting where compilation happens server side, so I'd like to avoid unnecessary disk reads/write every time the user hits "check". The executable would just get thrown away anyways, until they had a version ready to run.
Just to move this to an answer, this already exists as ghc-mod, here's the homepage. This already has frontends for Emacs, Sublime, and Vim so if you need examples of how to use it, there are plenty. In essence ghc-mod is just what you want, a wrapper around the GHC API designed for editors.
I'm trying build up good habits and a robust understanding of node/javascript.
Great answers to questions often come from Stackoverflow-ers who have taken time to look closely at the source code. (No surprise there, right?)
So, I'm getting myself into the habit of always checking out the underlying source code (cavaet - just javascript source code now, maybe C in the future).
Is there way from the command line (or with Node) to jump to the source-code of some object you are using? That is quickly go to the right file and line here:
https://github.com/joyent/node/tree/master/lib
Any tips or built-in tools in Node.js I should check out?
Thank you.
I often just do a console.log(object.method.toString()); which simply prints the text of the function out, which is often good enough to learn about it.