digitalmars.D - Can D be Interpreted?
- Jeroen Bollen (4/4) Dec 26 2013 Are there any programs allowing to interpret D and run it
- Jernej Krempus (2/6) Dec 26 2013 No, there is currently no REPL for D.
- Iain Buclaw (5/9) Dec 26 2013 I've been tempted to implement D in Guile - which is a cool extension
- Martin Nowak (4/8) Dec 26 2013 I've experimented with a D REPL based on shared libraries.
- Jacob Carlborg (5/13) Dec 27 2013 You mean like Dscanner:
- Martin Nowak (6/9) Feb 11 2014 This worked for now, but in the longer term I'm aiming at
- thedeemon (4/6) Dec 26 2013 If you don't mean interactively, then "rdmd prog.d" will act just
- =?UTF-8?B?UsOpbXkgTW91w6t6YQ==?= (16/20) Dec 26 2013 To execute a D source file as one would do with a Python script, you can...
- bearophile (9/10) Dec 26 2013 I'd like a good REPL in the default distributions, because it's
- Manu (11/20) Dec 26 2013 In my experience with vibe.d, it's a massive pain in the arse that it's
- Joseph Rushton Wakeling (3/18) Dec 26 2013 Could it be workable to have a minimal server + plugins design
- Adam D. Ruppe (5/7) Dec 26 2013 You could also just use CGI, which doesn't require any restart
- Manu (3/11) Jan 01 2014 Compile times are very slow even in my simple web applications when ther...
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (5/9) Jan 01 2014 Why doesn't D support some kind of partial evaluation instead?
- David Nadlinger (6/10) Jan 01 2014 Not really. You'd probably still need a powerful constant
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (4/7) Jan 01 2014 Why is that? You could just aggregate them and execute them in a
- deadalnix (6/13) Jan 06 2014 It is not possible as semantic analysis of a given piece of code
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (6/8) Jan 06 2014 You don't need a powerful interpreter to fold trivial things
- deadalnix (5/13) Jan 06 2014 This is done that way because it is simpler. At some point SDC
- deadalnix (3/13) Jan 05 2014 That is still what SDC does :D
- Manu (8/22) Jan 01 2014 Yeah, that's come up before. I've thought about it, but I haven't tried ...
- Martin Nowak (5/15) Dec 26 2013 If vibe.d is linked as library (instead of compiled with you app) you
- ponce (3/18) Dec 27 2013 I remember some people using http://www.dsource.org/projects/ddl
- Sean Kelly (5/12) Feb 11 2014 Changes aren't very frequent in my experience. Even when I'm
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
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
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
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
On 2013-12-27 01:43, Martin Nowak wrote:On 12/26/2013 08:15 PM, Iain Buclaw wrote:You mean like Dscanner: https://github.com/Hackerpilot/Dscanner/ -- /Jacob CarlborgI'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 27 2013
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
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
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
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
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,ntI'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=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
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
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
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: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.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)
Jan 01 2014
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
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
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
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: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.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 06 2014
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
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: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.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
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:That is still what SDC does :DWhy 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 05 2014
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: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! :PIn 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?
Jan 01 2014
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
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
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