This is revelation to me. I am enduring 10 minute turnaround for every edit > I make in *.java, xml, jsp, js files. 4 minute compile and 6 minute web > server update. How can I get that shortened to 10 seconds say? What links > can help? What search terms to google? >
10 minutes o_O wow, I can feel your suffering I do not know Java, I know it but only the very bare bones. What you should be looking for is any way of dynamic linking. Usually that means the ability to reload code on runtime, thats what DLLs are doing. Generally dynamic languages do this out of the box, for example python can reload its modules on runtime so live coding in python is very simple. Only a single command. Dynamic linking is a very basic functionality because its used for supporting scripting , plugins, addons , in short anything dynamic. I just googled "java dynamic code loading" which is what live coding is and this article came up , enjoy http://www.javaworld.com/article/2071777/design-patterns/add-dynamic-java-code-to-your-application.html "Kilion, In Haskell (a language that I love, just as Smalltalk) you have the REPL. The workflow is, while you are working on the project, you periodically load that file into the REPL and check. After that you compile. Haskell works with a strong type inference feature, however most Haskellers will say that the best practice is to annotate all functions. Also if you are on macOS you have: http://haskellformac.com/ which is awesome, really a great piece of software. There was even a project called Kronos that was essentially the same as IPython but with a Haskell kernel I don't know the status of that project as of today" Problem with a REPL is that it makes me feel disconnected. I prefer working inside my source code directly and in an instant , no delays , no compromises and multi steps. hence why I love to live code. Plus why bother with a REPL when you can just live code ? I see no advantage but you can enlighten me :) "Hi kilon, Some weeks ago I tried the C live programming technique for the Ludum Dare. It works very well. For that occasion I wrote this short article https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world/a-diabolical-game-for-a-diabolical-experiment . The game ended pretty well in my opinion: https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world ." Bookmarked to check when I log in my Windows (I use mainly macos) "I work for a video game company that is using Unreal Engine 4, we do not use the C++ live coding features. I do not like the way that they implemented live coding, and the bindings for their Blueprint visual language. We all hate the long compilation times of UE4, the fact that they use their own undocumented makefile system which is using a bunch C# files for building their project. We also do not like the fact that from time to time, we see that we are missing some #includes because of the unity builds that are done by the unreal build system (merging several .cpp before compiling them)." Yes the live coding feature of Unreal is far from impressive, do not know why they made it so limited and focused only for their editor. Also the inability to not be able to change blueprints run time is annoying too as is the build system. But I can still do my own way of live coding with C++ which is much more simple and much more flexible. "The biggest problem of these other language language is the lack of reflection information at runtime. The second other problem, is the lack of #become:, for swapping objects when their data layout changes. Elf files, PE files (.exe, .dll) and other executable formats are process images with a symbol table and relocation metadata. If the operating system allowed to modify in an easy way the symbol table of the current loaded process, it could be even cooler. In Linux, dlopen is implemented in terms of open() and mmap(). Best regards, Ronie" Reflection is indeed another beast and an area I have not touched yet. To be fair however, I rarely use reflection and I avoid meta programming. On the matter of symbol table its my understanding that DLLs come with their own symbol tables. It appears to me that you try to modify the executable , that's not my way of doing live coding with C++. Also to be clear about, my way of live coding is strictly Spartan. Which means that in the main loop the only thing that it should be in are: 1) the detection of changes to source code text files (usually checking the date and time format , plus size of the source code file should be enough) 2) the trigger of the relevant DLL compilation source code (simple commands passed to command line, this also means the compilation is automatic) 3) the reload of the DLL after compilation (again one command) 4) the capture of exception that will not allow the executable or the DLL to crash even if the DLL does something very bad ( a couple of lines of code) 5) and finally a singe pointer to a memory location that will be passed to DLLs (yeap a single one , it could be an array though if more flexibility is required for organisation puproses, again a couple of lines of code) In short only a dozen of lines of code will go in the executable that will be written once and never being changed. Coding will happen exclusively inside the source code of fhe DLLs and nowhere else. DLLs also will have to fully manage the memory. As you can imagine what we reload here is the entire DLL which means also that the DLL should be short if we do not want long compile times that defeats the purpose of live coding which turn it means big code will have to be broke down to many DLLs. But then we are Smalltalkers we love it brake down things to small stuff :D
