I'm trying to put together a notebook showing ideas in many different languages. I'm able to do Python, Ruby, Javascript, Scala, and Java (and a few more, from BeakerX), and while I can make a C/C++ notebook (using Xeus-Cling) it's unclear to me if there's any cell magic to put a C/C++ in with all the others.
I don't need interop between the languages / data produced by blocks in different languages, although that'd be nice.
%%ruby
puts "Hello World"
# Hello World
%%scala
println("Hello, world")
%%xcpp # bad guess...? doesn't work
#include <stdio.h>
printf("Hello, World!");
> UsageError: Cell magic `%%xcpp` not found.
X-C's docs indicate that there probably isn't (existing) cell magic to do this, but I want to check that (and that there's not an alternative to X-C that already does this) before diving in and figuring out to make it happen. If there's not existing cell magic, I'd appreciate pointers to making it.
Related
Program compiles, but freezes after starting. If replace the format and include with 32-bit versions or comment out the MessageBox, then everything works fine.
format PE64 GUI
include 'E:\Fresh\include\win64a.inc'
entry start
section '.data' data readable writeable
text db 'Hello world!',0
section '.text' code readable executable
start:
invoke MessageBox,0,text,text,0
invoke ExitProcess,0
section '.idata' import data readable writeable
library kernel32,'KERNEL32.DLL', user32, 'USER32.DLL'
import kernel32, ExitProcess, 'ExitProcess'
import user32, MessageBox, 'MessageBoxA'
Your stack is not aligned to 16 bytes, as the ABI requires. Add and rsp, -16 to the beginning of your code, and it will work.
Regarding this exchange in the comments:
Ruslan: What does the disassembly look like? Are invoke macros expanded as expected?
rancid_rot: Not sure, there is MessageBox in cs instead of ds. And mov rcx,0 instead push 0.
I'd recommend avoiding invoke and similar macros until you learn what they should expand to. Otherwise you think you write in assembly, but actually you write in a high-level language only resembling assembly, not even knowing what code you will get in the end—thus defying the whole purpose of using an assembler.
To actually learn to call functions in Win64 assembly, see the documentation on Win64 calling conventions.
Simple question here, just can't seem to pass it google in a way it can understand.
Say I wanted to execute a line of actual programming code (c++ or java or python... etc) like SetCursorPos or printf from the command prompt command line. I vaguely imagine I would have to invoke the compiler and pass the command to it like a parameter, where from it would then be converted into machine language and passed to... where exactly?
Okay so that was kind of two questions.
How to run actual code from the command line and
what exactly is happening when a fully compiled program, or converted line of code (presuming these are essentially binary containers at that point), is executed?
Question one takes priority obviously. Unfortunately, I can not find any documentation on it, just a bunch of stuff vaguely related to it.
How to run actual code from the command line
Without delving into the vast amounts of blurriness between them, there are two major categories of language implementations: interpreters and compilers.
With many interpreters (or implementations with implicit compilation, such as V8 JavaScript's jit compiler, or pretty much anything with a repl), running a single line from the command line should be fairly trivial. CPython (the standard implementation of Python) has the -c command option:
$ python -c 'print("Hello, world!")'
Hello, world!
Language implementations with explicit compilation steps will tend to be decidedly less simple. In particular, the compiler would need to either accept source either from directly out of the argument list, or from standard input (via piping or redirection). On the output side, your compiler would have to support immediately executing that program, or outputting it to standard out, so that an operating system feature (if it exists) can execute it from a pipe.
To my knowledge, most explicit compilers are not designed with such usage in mind. In such cases, your best bet is to see if there is a REPL available for the language in question, preferably one as compatible with your compiler as possible, or to create (or find) a wrapper that makes it look like your language has a REPL. The wrapper would:
Accept input along the lines of CPython above.
Create a temporary source file behind the scenes with the code to be run and any necessary boilerplate.
Pass that file to the compiler.
Automatically run the resulting executable.
Delete the source file and executable. These may be cleaned up by the operating system later instead, if they're in a temp directory.
From the point of view of the user, this should look pretty similar to the CPython example, as they wouldn't have to interact with or see the compiler or temporary files.
Perl does not have a C style preprocessor level "include" function. That is how it is, and there are numerous sites that explain how to more or less emulate the same sort of behavior.
The one thing I couldn't find on any of these sites is any explanation for WHY perl does not have this functionality. Given that Perl often provides many different ways to accomplish the same thing, it is a curious omission.
Can somebody please explain why the decision was made to exclude this sort of functionality?
Perl already has require, do, eval and here documents among other things. It doesn't need a builtin preprocessor, if you need one that badly, there are filters. http://perldoc.perl.org/perlfilter.html
In general, nobody wants #include, even C and C++ programmers would mostly be happy to give it up in exchange for:
Faster compiles
Clean module system
#include is legacy, period. If a mainstream language designer announced tomorrow that they were adding #include to (your favorite language here) you'd probably see mass hysteria, laughing, and loss of confidence in that designer.
Language designers don't implement #include in any new language, there are simply better ways to do it. In general the trend is to attempt to achieve single pass lexing. Preprocessing requires you to incrementally expand #includes and potentially revisit the same characters repeatedly. It has been wrought with problems, and is one of the reasons that C++ is such dog to compile. It was ok in the 60s and 70s when memory and CPU were tiny and languages and problems were simpler, as were codebases. Nowadays, you want to be able to compile a "library" once, store its type metadata with it so the compiler can access it efficiently without rescanning it. That is what Microsoft does anyway with precompiled headers.
So what would #include be good for?
Modules ? No. See above. Modules are compiled once, export their metadata efficiently, they don't pollute the namespace of the clients, they don't recursively inject other includes, they can be distributed in binary form, among umpteen other advantages that I'm not even smart enough to think of.
Including macros ? No. Replace with constants, inlining and generic programming. All of which can be precompiled and expored from a module.
Splicing in generated code ? Better ways to do it anyway. See modules.
The only useful functionality for the preprocessor, IMO, is conditional compilation.
#ifdef _WIN32_
// do windowsy stuff
#else
#endif
Again, Perl can do this with do, eval or require as well.
Perl doesn't have or lack it any more than C does.
The C preprocessor was designed such that it and C need to know as little as possible about each other. There is no reason why you can't use it with Perl.
So why don't Perl programmers do it?
As codenhein explains, it's generally a bad idea to use an include mechanism with a compiler that don't know anything about each other, as it leaves you open to some crazy errors that neither can diagnose; the fact that C programmers are used to it doesn't change that.
I'm an experienced C++/.NET/Java Windows/web programmer trying to learn (Common) Lisp. I'm reading Practical Common Lisp and using SLIME.
I'm getting the Lisp language easily enough, but I'm having trouble groking the mechanics of development. One of my issues is dealing with Emacs. I have no experience with it and find it generally confusing with hard to find/figure out commands.
Specific questions:
I get the REPL, but I don't quite get how I can use it effectively. When I need to change a function I have to retype the defun and make changes (tedious and error prone). How can I do this better?
How do I get from entering code at the REPL to actually having a program? I'm used to the C model where you have code files that you can review, edit and recompile. I know Lisp has something similar (via the load function), but how does one get a function I just defined and tested into a file to be saved? I'm hoping there's a better method than my current select+copy+paste.
How do you debug errors? Is there any ability to step into code like I would with other languages?
As long as the S-expression is valid, I don't get any errors when entering a (defun ...). It's not until I try to use it that I find out it's not valid. Is there any way to get errors sooner (i.e. compile the code)?
Is there some IDE that would be more familiar to me or allow me to play with the language easier?
Should I switch to learning Scheme instead?
Any tips would be greatly appreciated!
-I get the REPL, but don't quite get how I can use it effectively. When I
need to change a function I have to
retype the defun and make changes
(tedious and error prone). How can I
do this better?
-How do I get from entering code at the REPL to actually having a program?
I'm used to the C model where you have
code files that you can review, edit
and recompile. I know lisp has
something similar (via the load
function), but how does one get a
function I just defined and tested
into a file to be saved? I'm hoping
there's a better method than my
current select+copy+paste.
Load SLIME. Enter code in your .lisp file, and then run slime-eval-buffer to load all your code into Lisp. Then, for a specific function you are hacking on C-e, C-j to redefine it in your running Lisp.
-How do you debug errors? Is there any ability to step into code like I would with other languages?
Yes. (trace 'my-function) - or some variant on that - and when my-function is called, it will break into the debugger.
-As long as the S-expression is valid, I don't get any errors when entering a
(defun ...). It's not until I try to
use it that I find out it's not valid.
Is there any way to get errors sooner
(i.e. compile the code)?
To some degree, that is a characteristic of dynamic languages (Python, Perl, Ruby, Lisp, etc.). Try SBCL for better error-checking.
-Is there some IDE that would be more familiar to me or allow me to play with the language easier?
Emacs is the free IDE for Lisp. Allegro has a free edition I believe; I've never tried it though..
-Should I switch to learning Scheme instead?
Nah, Scheme is not as pragmatic a language.
I'm an experienced C++/.NET/Java Windows/Web programmer trying to learn (Common) Lisp. I'm reading Practical Common Lisp and using SLIME.
One can also use the LispWorks Personal Edition for learning Lisp. It has some limitations and the full product is commercial, but it is quite a bit easier to use.
I get the REPL, but don't quite get how I can use it effectively. When I need to change a function I have to retype the defun and make changes (tedious and error prone). How can I do this better?
The REPL has a history. With keyboard commands you can get back prior input and change it. Other than that just edit a Lisp file and compile code from there. In Lisp you can compile/eval individual expressions and definitions. Typical IDEs like SLIME, LispWorks or Allegro CL allow you to run code also from normal Lisp text windows - additionally to executing expressions in the REPLA (aka Listener).
How do I get from entering code at the REPL to actually having a program? I'm used to the C model where you have code files that you can review, edit and recompile. I know Lisp has something similar (via the load function), but how does one get a function I just defined and tested into a file to be saved? I'm hoping there's a better method than my current select+copy+paste.
Copy and paste in one thing. But the correct way is to work from a text file in an editor window. One can compile/load expressions, the editor buffer or the associated file.
How do you debug errors? Is there any ability to step into code like I would with other languages?
See STEP, TRACE and related. SLIME, LispWorks and Allegro CL have lots of additional features.
As long as the S-expression is valid, I don't get any errors when entering a (defun ...). It's not until I try to use it that I find out it's not valid. Is there any way to get errors sooner (i.e. compile the code)?
For many cases one uses a compiler. The compiler will find a range of errors and also will note when something is unusual (for example a function does not exist or a variable has not been defined).
-Is there some IDE that would be more familiar to me or allow me to play with the language easier?
LispWorks, Allegro CL are the best under Windows. There are some alternatives like Corman Lisp (I don't know it is maintained right now) or even Ufasoft Lisp.
Should I switch to learning Scheme instead?
Not really.
It doesn't sound like you're really using SLIME, or at least not in the way it was intended to be used. ("have to retype the defun", "the C model where you have code files")
I recommend watching some SLIME screencasts (or, even better, watching a Lisp programmer use SLIME for a few minutes, if you have one handy). The SLIME webpage has a couple.
It sounds like you'd really enjoy the DrRacket IDE. Racket is closer to Scheme than to Common Lisp, but you could dip your toes into the Lisp family without the speed bump of the Emacs style of development.
If you port code over from one language to another, how can this be detected?
Say you were porting code from c++ to Java, how could you tell?
What would be the difference between a program designed and implemented in Java, and a near identical program ported over to Java?
If the porting is done properly (by people expert in both languages and ready to translate the source language's idioms into the best similar idioms of the target language), there's no way you can tell that any porting has taken place.
If the porting is done incompetently, you can sometimes recognize goofily-transliterated idioms... but that can be hard to distinguish from people writing a new program in a language they know little just goofily transliterating the idioms from the language they do know;-).
Depending on how much effort was put into the intention to hide the porting it could be very easy to impossible to detect.
I would use pattern recognition for this task. Think about the "features" which would indicate code-similarities. Extract these feature from each code and compare them.
e.g:
One feature could be similar symbol names. Extract all symbols using ctags or regular expressions, make all lower-case, make uniq sort of both lists and compare them.
Another possible feature:
List of class + number of members e.g:
MyClass1 10
...
List of method + sequence of controll blocks. e.g:
doSth() if, while, if, ix, case
...
Another easy way, is to represent the code as a picture - e.g. load the code as text in Word and set the font size to 1. Human beings are very good on comparing pictures. For another Ideas of code Visualization you may check http://www.se-radio.net/2009/03/episode-130-code-visualization-with-michele-lanza/