www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Can D be Interpreted?

reply "Jeroen Bollen" <jbinero gmail.com> writes:
Are there any programs allowing to interpret D and run it 
similarly to how you would run a Python application? It doesn't 
need to have the whole Window support, just console application 
using just the standard Phobos library is more than enough.
Dec 26 2013
next sibling parent Jernej Krempus <jkrempus gmail.com> writes:
On Thu, 26 Dec 2013 18:50:25 +0000, Jeroen Bollen wrote:

 Are there any programs allowing to interpret D and run it similarly to
 how you would run a Python application? It doesn't need to have the
 whole Window support, just console application using just the standard
 Phobos library is more than enough.
No, there is currently no REPL for D.
Dec 26 2013
prev sibling next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 26 December 2013 18:50, Jeroen Bollen <jbinero gmail.com> wrote:
 Are there any programs allowing to interpret D and run it similarly to how
 you would run a Python application? It doesn't need to have the whole Window
 support, just console application using just the standard Phobos library is
 more than enough.
I've been tempted to implement D in Guile - which is a cool extension language platform. Implementing D ontop of its VM would make it effectively a REPL (with one or two features missing). But when will I ever get time to do this? Probably never. :)
Dec 26 2013
parent reply Martin Nowak <code dawg.eu> writes:
On 12/26/2013 08:15 PM, Iain Buclaw wrote:
 I've been tempted to implement D in Guile - which is a cool extension
 language platform.  Implementing D ontop of its VM would make it
 effectively a REPL (with one or two features missing).  But when will
 I ever get time to do this? Probably never.:)
I've experimented with a D REPL based on shared libraries. The biggest issue is the lack of a D parser library, other than that the approach works fine.
Dec 26 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-27 01:43, Martin Nowak wrote:
 On 12/26/2013 08:15 PM, Iain Buclaw wrote:
 I've been tempted to implement D in Guile - which is a cool extension
 language platform.  Implementing D ontop of its VM would make it
 effectively a REPL (with one or two features missing).  But when will
 I ever get time to do this? Probably never.:)
I've experimented with a D REPL based on shared libraries. The biggest issue is the lack of a D parser library, other than that the approach works fine.
You mean like Dscanner: https://github.com/Hackerpilot/Dscanner/ -- /Jacob Carlborg
Dec 27 2013
parent "Martin Nowak" <code dawg.eu> writes:
On Friday, 27 December 2013 at 15:28:36 UTC, Jacob Carlborg wrote:
 On 2013-12-27 01:43, Martin Nowak wrote:
 You mean like Dscanner:

 https://github.com/Hackerpilot/Dscanner/
This worked for now, but in the longer term I'm aiming at integrating the REPL with the compiler. That is make it a compilation driver that use libdmd to generate the shared libraries. http://forum.dlang.org/post/ldc9vh$25eq$1 digitalmars.com
Feb 11 2014
prev sibling next sibling parent "thedeemon" <dlang thedeemon.com> writes:
On Thursday, 26 December 2013 at 18:50:27 UTC, Jeroen Bollen 
wrote:
 Are there any programs allowing to interpret D and run it 
 similarly to how you would run a Python application?
If you don't mean interactively, then "rdmd prog.d" will act just as "python prog.py" or "ruby prog.rb" etc.
Dec 26 2013
prev sibling parent reply =?UTF-8?B?UsOpbXkgTW91w6t6YQ==?= <remy.moueza gmail.com> writes:
To execute a D source file as one would do with a Python script, you can 
use rdmd.
On Linux, you can make your can directly execute D source file by 
changing its mode (chmod u+x file.d) and adding a "shebang" first line 
like:


Don't forget to add the "--shebang" option or your file won't be 
executed properly.

There also have been several projects to make a D REPL, the most recent 
one being dabble: https://github.com/callumenator/dabble but it only 
works on Windows. The principle is to compile the code one enter on the 
REPL line and dynamically load it.

Burton Radons had written an article on how to dynamically load some 
Windows executable code, if you are interested in how this works: 
http://members.shaw.ca/burton-radons/The%20Joy%20and%20Gibbering%20Terror%20of%20Custom-Loadin
%20Executables.html 


On 12/26/2013 07:50 PM, Jeroen Bollen wrote:
 Are there any programs allowing to interpret D and run it similarly to
 how you would run a Python application? It doesn't need to have the
 whole Window support, just console application using just the standard
 Phobos library is more than enough.
Dec 26 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Rémy Mouëza:

 There also have been several projects to make a D REPL,
I'd like a good REPL in the default distributions, because it's an useful tool to speed up coding, to test and try things, it's very useful if you want to use D for exploratory coding, and it's kind of standard if you want to use a language for interactive mathematics (iPython with matPlotLib, Julia language, Mathematica, Sage, Scala etc). I'd like Walter to comment on this. Bye, bearophile
Dec 26 2013
parent reply Manu <turkeyman gmail.com> writes:
On 27 December 2013 06:59, bearophile <bearophileHUGS lycos.com> wrote:

 R=C3=A9my Mou=C3=ABza:


  There also have been several projects to make a D REPL,

 I'd like a good REPL in the default distributions, because it's an useful
 tool to speed up coding, to test and try things, it's very useful if you
 want to use D for exploratory coding, and it's kind of standard if you wa=
nt
 to use a language for interactive mathematics (iPython with matPlotLib,
 Julia language, Mathematica, Sage, Scala etc). I'd like Walter to comment
 on this.
In my experience with vibe.d, it's a massive pain in the arse that it's compiled. It seems to me that web dev involves squillions of micro-changes and tweaks, and it's bloody annoying to compile and reboot the server every time. vibe.d apps should be compiled for deployment, but a JIT option while developing/tweaking/tuning would speed up development by about 934x. I think that's the main hold-up for vibe.d compared to popular competition; the iteration time is just not good, but otherwise it's awesome.
Dec 26 2013
next sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Thursday, 26 December 2013 at 22:01:40 UTC, Manu wrote:
 In my experience with vibe.d, it's a massive pain in the arse 
 that it's
 compiled.
 It seems to me that web dev involves squillions of 
 micro-changes and
 tweaks, and it's bloody annoying to compile and reboot the 
 server every
 time.
 vibe.d apps should be compiled for deployment, but a JIT option 
 while
 developing/tweaking/tuning would speed up development by about 
 934x.
 I think that's the main hold-up for vibe.d compared to popular 
 competition;
 the iteration time is just not good, but otherwise it's awesome.
Could it be workable to have a minimal server + plugins design akin to what you did with Remedy for game functionality?
Dec 26 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 26 December 2013 at 23:37:07 UTC, Joseph Rushton 
Wakeling wrote:
 Could it be workable to have a minimal server + plugins design 
 akin to what you did with Remedy for game functionality?
You could also just use CGI, which doesn't require any restart for changes, and can also easily enough compile and cache lazily (like or even with rdmd)
Dec 26 2013
parent reply Manu <turkeyman gmail.com> writes:
On 27 December 2013 09:55, Adam D. Ruppe <destructionator gmail.com> wrote:

 On Thursday, 26 December 2013 at 23:37:07 UTC, Joseph Rushton Wakeling
 wrote:

 Could it be workable to have a minimal server + plugins design akin to
 what you did with Remedy for game functionality?
You could also just use CGI, which doesn't require any restart for changes, and can also easily enough compile and cache lazily (like or even with rdmd)
Compile times are very slow even in my simple web applications when there are lots of templates sadly. Hopefully CTFE gets much faster in the future.
Jan 01 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 1 January 2014 at 09:40:45 UTC, Manu wrote:
 Compile times are very slow even in my simple web applications 
 when there
 are lots of templates sadly. Hopefully CTFE gets much faster in 
 the future.
Why doesn't D support some kind of partial evaluation instead? With llvm you get to JIT for free, seems to be an overall simpler solution than having an interpreter in the compiler (or equally complex, but more powerful)
Jan 01 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 1 January 2014 at 10:27:48 UTC, Ola Fosheim Grøstad 
wrote:
 Why doesn't D support some kind of partial evaluation instead? 
 With llvm you get to JIT for free, seems to be an overall 
 simpler solution than having an interpreter in the compiler (or 
 equally complex, but more powerful)
Not really. You'd probably still need a powerful constant folder/interpreter to avoid firing up the LLVM JIT for every single trivial CTFE invocation. David
Jan 01 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 1 January 2014 at 22:44:31 UTC, David Nadlinger 
wrote:
 Not really. You'd probably still need a powerful constant 
 folder/interpreter to avoid firing up the LLVM JIT for every 
 single trivial CTFE invocation.
Why is that? You could just aggregate them and execute them in a single run.
Jan 01 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 1 January 2014 at 22:52:34 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 1 January 2014 at 22:44:31 UTC, David Nadlinger 
 wrote:
 Not really. You'd probably still need a powerful constant 
 folder/interpreter to avoid firing up the LLVM JIT for every 
 single trivial CTFE invocation.
Why is that? You could just aggregate them and execute them in a single run.
It is not possible as semantic analysis of a given piece of code can depend of the CTFE of another. Also JITing for trivial thing that could be constant folded is much slower.
Jan 06 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 6 January 2014 at 14:58:58 UTC, deadalnix wrote:
 Also JITing for trivial thing that could be constant folded is 
 much slower.
You don't need a powerful interpreter to fold trivial things (+-*/?:). If it is a separate pass there is no reason for not being able to building a dependency graph and use a JIT on multiple expressions. It sounds trivial to me, if it isn't simple in the DMD front-end then it is a structural issue.
Jan 06 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 6 January 2014 at 15:20:32 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 6 January 2014 at 14:58:58 UTC, deadalnix wrote:
 Also JITing for trivial thing that could be constant folded is 
 much slower.
You don't need a powerful interpreter to fold trivial things (+-*/?:). If it is a separate pass there is no reason for not being able to building a dependency graph and use a JIT on multiple expressions. It sounds trivial to me, if it isn't simple in the DMD front-end then it is a structural issue.
This is done that way because it is simpler. At some point SDC will probably get a constant folder, but for now, supporting more D functionalities is more important.
Jan 06 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 1 January 2014 at 22:44:31 UTC, David Nadlinger 
wrote:
 On Wednesday, 1 January 2014 at 10:27:48 UTC, Ola Fosheim 
 Grøstad wrote:
 Why doesn't D support some kind of partial evaluation instead? 
 With llvm you get to JIT for free, seems to be an overall 
 simpler solution than having an interpreter in the compiler 
 (or equally complex, but more powerful)
Not really. You'd probably still need a powerful constant folder/interpreter to avoid firing up the LLVM JIT for every single trivial CTFE invocation. David
That is still what SDC does :D
Jan 05 2014
prev sibling parent Manu <turkeyman gmail.com> writes:
On 27 December 2013 09:37, Joseph Rushton Wakeling <
joseph.wakeling webdrake.net> wrote:

 On Thursday, 26 December 2013 at 22:01:40 UTC, Manu wrote:

 In my experience with vibe.d, it's a massive pain in the arse that it's
 compiled.
 It seems to me that web dev involves squillions of micro-changes and
 tweaks, and it's bloody annoying to compile and reboot the server every
 time.
 vibe.d apps should be compiled for deployment, but a JIT option while
 developing/tweaking/tuning would speed up development by about 934x.
 I think that's the main hold-up for vibe.d compared to popular
 competition;
 the iteration time is just not good, but otherwise it's awesome.
Could it be workable to have a minimal server + plugins design akin to what you did with Remedy for game functionality?
Yeah, that's come up before. I've thought about it, but I haven't tried it out. It sounds good in theory, but it will be interesting to see if there are any significant inconveniences introduced by the DLL boundary. I have so many things pending on my short-list. I need to find time for all this stuff I wanna do! :P
Jan 01 2014
prev sibling next sibling parent Martin Nowak <code dawg.eu> writes:
On 12/26/2013 11:01 PM, Manu wrote:
 In my experience with vibe.d, it's a massive pain in the arse that it's
 compiled.
 It seems to me that web dev involves squillions of micro-changes and
 tweaks, and it's bloody annoying to compile and reboot the server every
 time.
 vibe.d apps should be compiled for deployment, but a JIT option while
 developing/tweaking/tuning would speed up development by about 934x.
 I think that's the main hold-up for vibe.d compared to popular
 competition; the iteration time is just not good, but otherwise it's
 awesome.
If vibe.d is linked as library (instead of compiled with you app) you easily get down from 3s to 1s for compilation. For bigger apps separate compilation would help. Combined with inotify watches this should work out fine in the longer term.
Dec 26 2013
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
 In my experience with vibe.d, it's a massive pain in the arse 
 that it's
 compiled.
 It seems to me that web dev involves squillions of 
 micro-changes and
 tweaks, and it's bloody annoying to compile and reboot the 
 server every
 time.
 vibe.d apps should be compiled for deployment, but a JIT option 
 while
 developing/tweaking/tuning would speed up development by about 
 934x.
 I think that's the main hold-up for vibe.d compared to popular 
 competition;
 the iteration time is just not good, but otherwise it's awesome.
I remember some people using http://www.dsource.org/projects/ddl for faster iterations (eg. Thomas Stachowiak in his PhD shader tool).
Dec 27 2013
prev sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 26 December 2013 at 22:01:40 UTC, Manu wrote:
 In my experience with vibe.d, it's a massive pain in the arse 
 that it's compiled.
 It seems to me that web dev involves squillions of 
 micro-changes and
 tweaks, and it's bloody annoying to compile and reboot the 
 server every
 time.
Changes aren't very frequent in my experience. Even when I'm working on new code I'm not restarting my dev server very often. That said, having a means of zero downtime upgrades is crucial, and plugins are a handy way to do that.
Feb 11 2014