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 .
Why C++ coders still endure long compile times when they could test code in > an instant through live coding ? Well in games C++ live coding is actually > very popular, so some are already aware of the huge advantages of live > coding. > 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). > Another shock for me is how simple it is to implement an image file format > for other languages. The shock was that the OS already uses image files > like pharo image that calls them "memory mapped files" they are used for > sharing memory which in turn is what is used for DLLs. The advantage over > the pharo image is that it crash prone, because it is handled by the OS and > not the language or the VM. Which means that even if your app crashes the > image is still saved and you lose no live data which is not the case with > pharo image. The disadvantage is that of course they are not OOP friendly > as the pharo image is and they are not language specific as pharo image is. > 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 2017-05-10 16:48 GMT-03:00 p...@highoctane.be <p...@highoctane.be>: > Or BeanShell > > http://www.beanshell.org/ > > or Groovy > https://zeroturnaround.com/rebellabs/scripting-your-java- > application-with-groovy/ > > or Spring-Shell > https://projects.spring.io/spring-shell/ > > Example app I am using (and extending) for Hadoop work: > https://github.com/sequenceiq/ambari-shell > > When one looks inside a command, this is something easily achievable with > pragmas. > > https://github.com/sequenceiq/ambari-shell/blob/master/src/ > main/java/com/sequenceiq/ambari/shell/commands/BasicCommands.java > > There is nothing extraordinary in these pieces of tech ("pas de quoi > casser trois pattes à un canard" in French). > > But we need our own house in order on the CLI. GSoC time! > > Phil > > > > > On Wed, May 10, 2017 at 7:38 PM, blake watson <dsblakewat...@gmail.com> > wrote: > >> There is a Java REPL. You could Google that. >> >> There's also a some kind of commercial hot/live compiler tool called >> "JRebel". Haven't tried it (don't code Java). >> >> On Wed, May 10, 2017 at 4:29 AM, askoh <as...@askoh.com> wrote: >> >>> Kilon: >>> >>> 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? >>> >>> Thanks, >>> Aik-Siong Koh >>> >>> On May 10, 2017, at 3:20 AM, kilon.alios [via Smalltalk] <[hidden email] >>> <http:///user/SendEmail.jtp?type=node&node=4946427&i=0>> wrote: >>> >>> Just to remind people here that all languages with long compile times >>> can be avoided live coding style through the use of dynamically linked >>> libraries known as DLLs on windows, shared libraries on linux (*.so) and >>> macos (*.dylib) . Also Swift in particular comes with a live coding >>> environment called "Playgrounds" which is also very flexible. >>> >>> Haskell do not know if they have something similar to Playgrounds but I >>> will be surprise if they do not have something at least inferior. All >>> languages support DLLs including ours. >>> >>> Live coding is actually super easy to implement and believe me I was >>> sceptical about it at first and if I had read this post I am making now I >>> would call me crazy. But after implementing live coding in python, C and >>> C++ , now I am a believer. Of course the real question here is if its that >>> easy why people do not use it . From what I have found out, it has not >>> occurred to them as it did not occur to me. >>> >>> Why C++ coders still endure long compile times when they could test code >>> in an instant through live coding ? Well in games C++ live coding is >>> actually very popular, so some are already aware of the huge advantages of >>> live coding. >>> >>> I think this is an advantage of Pharo , that introduces to live coding, >>> a so simple idea yet so essential without you having to think about it >>> yourself or be already aware of it. >>> >>> With other language you will have to find a tutorial or article that >>> mentions this ability. >>> >>> Another shock for me is how simple it is to implement an image file >>> format for other languages. The shock was that the OS already uses image >>> files like pharo image that calls them "memory mapped files" they are used >>> for sharing memory which in turn is what is used for DLLs. The advantage >>> over the pharo image is that it crash prone, because it is handled by the >>> OS and not the language or the VM. Which means that even if your app >>> crashes the image is still saved and you lose no live data which is not the >>> case with pharo image. The disadvantage is that of course they are not OOP >>> friendly as the pharo image is and they are not language specific as pharo >>> image is. >>> >>> Again I would not have known any of this if I had not been playing with >>> shared memory as an IPC and I also see coders rarely if ever mentioning >>> them. >>> >>> >>> >>> On Wed, May 10, 2017 at 4:09 AM Pierce Ng <[hidden email] >>> <http:///user/SendEmail.jtp?type=node&node=4946404&i=0>> wrote: >>> >>>> On Tue, May 09, 2017 at 06:59:08PM +0200, Stephan Eggermont wrote: >>>> > I don't know. I do know that I can't use something with the >>>> > ridiculous compile times of Haskell or Swift. That just kills flow >>>> > and productivity. >>>> >>>> You could hop onto an office chair and engage your colleague in sword >>>> fighting. >>>> That's a plus! :-) >>>> >>>> Pierce >>>> >>>> >>> >>> ------------------------------ >>> If you reply to this email, your message will be added to the discussion >>> below: >>> http://forum.world.st/Smalltalkers-will-eventually-win-So-sa >>> ys-this-old-C-programmer-tp4945895p4946404.html >>> To unsubscribe from Smalltalkers will, eventually, win. So says this old >>> C++ programmer., click here. >>> NAML >>> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >>> >>> >>> ------------------------------ >>> View this message in context: Re: Smalltalkers will, eventually, win. >>> So says this old C++ programmer. >>> <http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-programmer-tp4945895p4946427.html> >>> >>> Sent from the Pharo Smalltalk Users mailing list archive >>> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at >>> Nabble.com. >>> >> >> >
