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.
Related
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 a stack which was originally built in Hypercard then migrated to Metacard. Obviously, it has expanded greatly over that time. Some core features broke when I tried to migrate to Runrev which is why I've waited till now to finally do that. I'm keeping it as a stack rather than an exe so I can save changes to it. I've built a standalone player to launch it and that is working. I've included the revmessagebox.rev stack in the Standalone Stack settings. This does add it but, incorrectly. I can put messages to it from my stack but, it won't run commands and it's missing all it's icons. I'm also included the revimagelibrary.rev and revtools.rev stacks in the hopes of fixing this but, no dice. I was also hoping that including revimagelibrary.rev would get my old Metacard icons to display but, no dice. I appreciate any help I can get on this.
Rich
I don't think you can. The message box is part of the IDE and requires the development environment to run. When you build a standalone your scripts etc are compiled and an interpreter for commands is no longer present.
To replicate it in a standalone you could use a simple window with a field to accept text and would require you passing the text entered to a "Do" command. The other functions present with the message box (accessed via the icons you mentioned) are also development tools and don't make much sense in a standalone.
The message box is not only integrated into the IDE, the engine also has hooks that directly support it. I'm not sure those hooks are included with the engine that is built into a standalone, so even if you adapt the existing message box for your standalone it still may not work correctly.
The solution, as others have said, is to build your own stack that functions as a pseudo-message box. It is easy to display messages in your own stack, and pretty easy to execute simple commands using the "do" command. It is somewhat more difficult to execute complex or multi-line commands. But I agree with Dunbarx that I'd assess the need for such a thing if you are planning this standalone for distribution. It's a non-standard interface element.
What James said. But note that though the msg box is indeed integral to the IDE, it is still just a stack, and that stack can be replicated to whatever extent you need.
That said, the msg box is usually used as a development tool, to test short scripts (usually one-liners), to get or set property values quickly, as a simple calculator, that sort of stuff. If you need that sort of functionality, you should probably integrate it more comprehensively into the structure of your project.
Craig Newman
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.
I work from 2 different machines. One is Windows and the other is Linux. If I alternately work on the same project but switch between both OSes, will I eventually run into compiling errors? I ask because maybe there are standards supported by one but not by the other.
That question is a pretty broad one and it depends, strictly speaking, on your tool chain. If you were to use the same tool chain (e.g. GCC/MinGW or Clang), you'd be minimizing the chance for this class of errors. If you were to use Visual Studio on Windows and GCC or Clang on the Linux side, you'd run into more issues alone because some of the headers differ. So once your program leaves the realm of strict ANSI C (C89) you'll be on your own.
However, if you aren't careful you may run into a lot of other more profane errors, such as the compiler on Linux choking on the line endings if you didn't tell your editor on the Windows side to use these.
Ah, and also keep in mind that if you want to actually cross-compile, GCC may be the best choice and therefore the first part I mentioned in my answer becomes a moot point. GCC is a proven choice on both ends. And given your question it's unlikely that you are trying to write something like a kernel mode driver - which would be fundamentally different.
That may be only if your application use some specific API.
It is entirely possible to write code that works on both platforms, with no issues to compile the code. It is, however, not without some difficulties. Compilers allow you to use non-standard features in the compiler, and it's often hard to do more fancy user interfaces (even if it's still just text) because as soon as you start wanting to do more than "read a line of text as it is entered in a shell", it's into "non-standard" land.
If you do find yourself needing to do more than what the standard C library can do, make sure you isolate those parts of the code into a separate file (or a couple of files, one for Linux/Unix style systems and one for Windows systems).
Using the same compiler (gcc) would help avoiding problems with "compiler B doesn't compile code that works fine in compiler A".
But it's far from an absolute necessity - just make sure you compile the code on both platforms and with all of your "suppoerted" compilers often enough that you haven't dug a very deep hole that is hard to get out of before you discover that "it's not working on the other system". It certainly helps if you have (at least) a virtual machine running the other OS, so you can easily try both variants.
Ideally, you want to set up an automated system, such that when you change the code [and feel that the changes are "complete"], it automatically gets built on both platforms and all compilers you want to use. And if possible, also automatically tested!
I would also seriously consider using version control - that way, when something breaks on one or the other side, you can go back and look at what the code looked like before it stopped working, and (hopefully) find the reason it broke much quicker than "Hmm, I think it's the change I made to foo.c, lets take that out... No, not that one, ok how about the change here..." - at least with version control, you can say "Ok, so version 1234 doesn't work, let's try version 1220 - ok, that works. Now try 1228, still works - so change between 1229 and 1234 - try 1232, ah, it's broken..." No editing files and you can still go to any other version you like with very little difficulty. I have used Mercurial quite a bit, git a little bit, some subversion, and worked on a project in Perforce for a few years. All of these are good - personally, I think I prefer mercurial.
As a side-effect: Most version control systems also deal with filename and line endings in the saner way than doing this manually.
If you combine your version control system with a "automated build and test-system", such as Jenkins, you can get everything very automated. Jenkins is free and runs on both Windows and Linux, and you can use it to automatically build and test your code as and when you submit the code to the version control system.
It will not create a problem until you recompile the source code in the respective OS. If you wanna run your compiled file generated by windows(.exe or .obj), into linux or vice-versa then it will definitely create a problem and wont be possible. But you can move you source code (file with extension .c/.c++) into any of the os. And sometimes it also create problems with different header files, so take care of that also. Best practice is to use single OS for you entire project, avoid multiple os until it is extremely necessary.
It's quite nice to have ghci integrated with Emacs through inferior-haskell-mode: this adds a wonderful possibility to quickly navigate to compile error locations, interactively inspect types, definitions, etc. Nevertheless, the major feature I'm missing in this setup is inability to use ghci tab-completion, which is quite helpful for completing functions available from imported modules, language extensions and ghci commands.
I assume that this functionality may be implemented rather trivially by passing raw "TAB" character to the ghci process, reading its output back and pasting the result into the Emacs buffer. Note that I haven't worked with "comint-mode" in Emacs, so I may be totally wrong.
Finally, we have come to my question: why this feature is missing from haskell-mode? Are there any obvious problems which I am unaware of, is it hard to implement, or is it just due to some historical reasons? (like "no one bothered to write it"). Do you have any workarounds for the problem? (except running ghci outside Emacs)
Check out ghc-mode that builds on top of haskell-mode and adds autocompletion and some other features.
There's also a haskell-emacs mode, which is different from haskell-mode. It also has autocompletion. Although it was quirky and not always worked when i tried it.