www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DREPL will be back soon.

reply "deadalnix" <deadalnix gmail.com> writes:
I'm talking about:
https://drepl.dawg.eu/

It has been several days already that it is coming soon. How soon 
is soon ?
Mar 16 2015
parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Monday, 16 March 2015 at 21:36:45 UTC, deadalnix wrote:
 I'm talking about:
 https://drepl.dawg.eu/

 It has been several days already that it is coming soon. How 
 soon is soon ?
It's a different topic (and hope you will forgive my hijacking your thread - I don't know the answer, but guess you will hear back soon enough - hijack or no), but I was thinking about how one could make the REPL more useful as something closer to the ipython notebook. What do you/others think about having the REPL serialize any variables (optionally only those that are declared in a certain way, or part of a particular struct) to RAM disk or SSD and reload them at each stage rather than calculating them (ie compiling the generating statements) from scratch each time. The overhead would be modest in the trivial case, but it would allow you to use the REPL to explore larger data sets that take time to generate. Simple example here: http://nbviewer.ipython.org/gist/twiecki/3962843 (This data doesn't take long to generate, but larger data sets might).
Mar 16 2015
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2015-03-17 at 00:55 +0000, Laeeth Isharc via Digitalmars-d
wrote:
[=E2=80=A6]
 What do you/others think about having the REPL serialize any=20
 variables (optionally only those that are declared in a certain=20
 way, or part of a particular struct) to RAM disk or SSD and=20
 reload them at each stage rather than calculating them (ie=20
 compiling the generating statements) from scratch each time.  The=20
 overhead would be modest in the trivial case, but it would allow=20
 you to use the REPL to explore larger data sets that take time to=20
 generate.
=20
 Simple example here:
 http://nbviewer.ipython.org/gist/twiecki/3962843
=20
 (This data doesn't take long to generate, but larger data sets=20
 might).
I believe too many people over-rate REPLs, they are 1960s solutions to interactive computing when there were no better solution. Editor + fast compilation, is a far better solution for most of the situations that people think REPLs are great for. These days systems like Jupyter show that you can create documents with executable fragments, a much better solution generally. For me the problem with REPLs for most people's use of them revolves around all the hidden persistent mutable state: it's a batch processing solution to an interactive computing problem. Your case though is one that exactly fits this situation. So this is a case where REPLs may well be the right way forward. The question is I guess how to render visualizations of the data. Jupyter is trying but it is also trying, there should be better, I do not have a vision for what it might be though :-( --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Mar 17 2015