I see that at this point in time Smalltalk and Lisp machines have become completely memory-holed (oh wait, Smalltalk & Lisp are interactive, thus "interpreted", thus obviously not compiled! I'll show myself out)
Nim – Natively compiled language with hot code-reloading at runtime [video]
11–20 of 118 posts
Re: Nim – Natively compiled language with hot code-reloading at runtime [video]
#12(Natively compiled) Erlang might want to have a word with you.
Educate me if I am wrong, but there are natively compiled Erlang modules, but no longer any natively compiled Erlang. It only runs on the BEAM, and ever since BEAM/C fell out of use in OTP R5 no native code is generated.
It even runs bare metal IoT https://www.grisp.org/
(and https://github.com/nerves-project is cool too for other embedded work)
Re: Nim – Natively compiled language with hot code-reloading at runtime [video]
#13Could be a cool feature, but I wouldn't say "first". Been done in C for years:
* Safe and Automatic Live Update for Operating Systems, https://www.cs.vu.nl/~giuffrida/papers/asplos-2013.pdf
* Automating Live Update for Generic Server Programs, https://www.cs.vu.nl/~giuffrida/papers/lu_tse16.pdf
And I'm sure hot code reloading has been done in Forth for decades.
Re: Nim – Natively compiled language with hot code-reloading at runtime [video]
#14(Natively compiled) Erlang might want to have a word with you.
Educate me if I am wrong, but there are natively compiled Erlang modules, but no longer any natively compiled Erlang. It only runs on the BEAM, and ever since BEAM/C fell out of use in OTP R5 no native code is generated.
BEAM is still present but HiPE interfaces with it using some specific ABI that allows mixing AOT compiled native modules (just machine code) and the BEAM register machine. I'm not sure if there are new caveats as I regard HiPE as a compatibility feature rather than something under active development (I may be wrong but it seems to fail to compile all of OTP's Erlang code now).
The overhead of that context switch is a bit high but it allows the code loading facilities of the BEAM to reload HiPE compiled modules. This works because all processes yield to the scheduler, which acts as a kind of code-swap safe-point. The usual module-local vs module-remote call rules apply here when old versions are purged.
Re: Nim – Natively compiled language with hot code-reloading at runtime [video]
#15I only skimmed the video, but I couldn't see him describing it doing type reloading. Perhaps that is what he is planning on implementing. It is very hard to implement (especially if you can't control the compiler) but very useful for general code reloading. Of course everything is relative, and even if I think it is "very hard" it might be a weekend project for someone else. Generally though, code reloading is one of the hardest things to implement in a vm.
The holy grail of code reloading is to upgrade the code of a HTTP server while it is running and without disturbing any requests being processed. Very few languages except for Erlang are able to do that correctly. Some languages claim to support that, but when you experiment with them you discover "quirks" making it impossible in practice.
Re: Nim – Natively compiled language with hot code-reloading at runtime [video]
#16You can hotpatch C function too : https://news.ycombinator.com/item?id=11403263
Re: Nim – Natively compiled language with hot code-reloading at runtime [video]
#17+1 Nim is a really nice and simple language. Extremely easy FFI and Python-like. For me, using Nim and Julia to write small "scripts" for my data science (student) works (processing 10Gb-20Gb of data) makes me feel quite productive compared to something like Go (too `ugly` for me), Python (too slow)
Re: Nim – Natively compiled language with hot code-reloading at runtime [video]
#18Can someone give me some pointers to reading material on this.
I'm aware of hot code reloading for interpreted languages, google just gives links to web page loading. I'm also aware of it at the OS level. I don't really understand why you'd want this in a compiled language.
Re: Nim – Natively compiled language with hot code-reloading at runtime [video]
#19I remember using "edit and continue" in Visual C++ 6, seems that this feature still exists in newer versions[1], but I don't know what limitations it has.
[1] https://docs.microsoft.com/en-us/visualstudio/debugger/edit-...
Re: Nim – Natively compiled language with hot code-reloading at runtime [video]
#20Afaik Common Lisp would be the first, wouldn't it?
Lisp in 1962 did it, it had a compiler and the implementation could mix interpreted and compiled code.
One takes an interpreted function, which can be defined at runtime, compile it to assembler and have the assembler generate machine code in binary program space. The Lisp system then notes that this is now a compiled function.
http://www.softwarepreservation.org/projects/LISP/book/LISP%...
> The LISP Compiler is a program written in LISP that translates S-expression definitions of functions into machine language subroutines. It is an optional feature that makes programs run many times faster than they would if they were to be interpreted at run time by the interpreter.
> When the compiler is called upon to compile a function, it looks for an EXPR or FEXPR on the property list of the function name. The compiler then translates this S-expression into an S-expression that represents a subroutine in the LISP Assembly Language (LAP). LAP then proceeds to assemble this program into binary program space. Thus an EXPR, or an FEXPR, has been changed to a SUBR or an FSUBR, respectively.
...
> 1. It is not necessary to compile all of the functions that are used in a particular run. The interpreter is designed to link with compiled functions. Compiled functions that use interpreted functions will call the interpreter to evaluate these at run time.
> 2. The order in which functions are compiled is of no significance. It is not even necessary to have all of the functions defined until they are actually used at run time. (Specialforms are an exception to this rule. They must be defined before any function that calls them is compiled. )