• deadalnix (4/4) Mar 16 2015 I'm talking about:
• Laeeth Isharc (18/22) Mar 16 2015 It's a different topic (and hope you will forgive my hijacking
• Russel Winder via Digitalmars-d (27/41) Mar 17 2015 On Tue, 2015-03-17 at 00:55 +0000, Laeeth Isharc via Digitalmars-d

"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 ?

"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).

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