www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Right now, what's the most important for the success and adoption

reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
I wanted to probe the D community of the following issue:

Right now, what would the most important thing for the success and 
adoption of D? In other words, if one had to use D to develop a medium 
or large scale software, what would be the most important things to 
have, that we currently don't have (or aren't good enough)?
(I'm not talking only about language features, in case you didn't get that)

I ask this on the onset of seeing several people commenting on how they 
can't wait until we have AST macros, or how the feature X would be 
awesome to have, while me, now that I actually started to some coding in 
D (even if in a very small project), would actually rate those a much 
lower priority versus other things I'd like to have in the D ecosphere. 
  I'll do some more comments on this but first I'd like to hear about 
other people's opinions.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 28 2007
next sibling parent Extrawurst <spam extrawurst.org> writes:
if i had to narrow it down to just the most important for me i would say:

1) FAR more bugfixes, thats what makes development in D most annoying. ( 
phobos as well as dmd )

that is by far the most important to me right now!

2) speaking of standard libs: i dream of having just one! no decision 
anymore whether to use phobos or better tango!
3) some innovative new parrallel coding abilities included in language. 
(i think thats a placer where u can really seperate from any other 
compiled languages today)

--Extrawurst

Bruno Medeiros schrieb:
 I wanted to probe the D community of the following issue:

 Right now, what would the most important thing for the success and 
 adoption of D? In other words, if one had to use D to develop a medium 
 or large scale software, what would be the most important things to 
 have, that we currently don't have (or aren't good enough)?
 (I'm not talking only about language features, in case you didn't get 
 that)

 I ask this on the onset of seeing several people commenting on how 
 they can't wait until we have AST macros, or how the feature X would 
 be awesome to have, while me, now that I actually started to some 
 coding in D (even if in a very small project), would actually rate 
 those a much lower priority versus other things I'd like to have in 
 the D ecosphere.  I'll do some more comments on this but first I'd 
 like to hear about other people's opinions.
Sep 28 2007
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Bruno Medeiros wrote:
 I wanted to probe the D community of the following issue:
 
 Right now, what would the most important thing for the success and 
 adoption of D? In other words, if one had to use D to develop a medium 
 or large scale software, what would be the most important things to 
 have, that we currently don't have (or aren't good enough)?
 (I'm not talking only about language features, in case you didn't get that)
- Good TDD tools. unittest {} is primitive. Thomas Kuehne's unittest walker is an improvement. I want a mocks library. (I tried writing one, but there's ICE on anonymous delegates with template parameters, and I haven't figured how to get around that.) I want an Assert library that can give better error messages: int[] foo = [1, 2, 3]; int bar = 4; Assert(foo, Contains(bar)); // error: expected to contain: 4 but was: [1, 2, 3] Assert(foo, Is(bar)); // error: expected same as: 4 (0xdeadbeef) but was: [1, 2, 3] (0xfeedb00c) That can be done without much trouble, but it's less important. - A good GUI library. I don't know what's out there that's production-ready. It should seem native to the language. MinWin is best in that regard, most likely. - An enterprise library. Specifically, it should support dependency injection and anonymous event hookup. Ideally, it would use some sort of decorator on events to decide whether to hook them up. I don't want to have to go to two separate places to maintain one event listener or publisher. Other than that, using D is pleasure, so I have no requests.
 I ask this on the onset of seeing several people commenting on how they 
 can't wait until we have AST macros, or how the feature X would be 
 awesome to have, while me, now that I actually started to some coding in 
 D (even if in a very small project), would actually rate those a much 
 lower priority versus other things I'd like to have in the D ecosphere. 
  I'll do some more comments on this but first I'd like to hear about 
 other people's opinions.
Right now, D lacks libraries. Half the people here are working on libraries of some sort. AST macros make their job easier. Chris Wright.
Sep 28 2007
prev sibling next sibling parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Fri, 28 Sep 2007 13:30:08 +0100, Bruno Medeiros
<brunodomedeiros+spam com.gmail> wrote:

I wanted to probe the D community of the following issue:

Right now, what would the most important thing for the success and 
adoption of D? In other words, if one had to use D to develop a medium 
or large scale software, what would be the most important things to 
have, that we currently don't have (or aren't good enough)?
(I'm not talking only about language features, in case you didn't get that)

I ask this on the onset of seeing several people commenting on how they 
can't wait until we have AST macros, or how the feature X would be 
awesome to have, while me, now that I actually started to some coding in 
D (even if in a very small project), would actually rate those a much 
lower priority versus other things I'd like to have in the D ecosphere. 
  I'll do some more comments on this but first I'd like to hear about 
other people's opinions.
1. More bugfixes in D 1.0. I would be happy to call it stable some day. 2. The problem with RAII (destructors are useless: http://www.digitalmars.com/d/archives/digitalmars/D/learn/destructors_7525.html and other threads) 3. GUI
Sep 28 2007
parent reply downs <default_357-line yahoo.de> writes:
Max Samukha wrote:
 
 1. More bugfixes in D 1.0. I would be happy to call it stable some
 day.
 2. The problem with RAII (destructors are useless:
 http://www.digitalmars.com/d/archives/digitalmars/D/learn/destructors_7525.html
 and other threads)
 3. GUI
Seconded, especially the first. And the second. Third would be nice too :) --downs
Sep 29 2007
parent reply Patrick Kreft <patrick_kreft gmx.net> writes:
downs schrieb:
 Max Samukha wrote:
 1. More bugfixes in D 1.0. I would be happy to call it stable some
 day.
 2. The problem with RAII (destructors are useless:
 http://www.digitalmars.com/d/archives/digitalmars/D/learn/destructors_7525.html
 and other threads)
 3. GUI
Seconded, especially the first. And the second. Third would be nice too :) --downs
Hmm Second isnt an issue. I think it was misunderstood. Yeah D have GC and RAII, that means that u can explicit call a destructor and this will be executed. That is why Sun think about RAII in Java and C++ get GC in C++0x or maybe not. Look: import std.stdio; import std.thread; class Type { this() { writefln("Create"); } ~this() { writefln("Delete"); } } int ThreadLoop() { int i; Type t; while(i < 1000) { writefln(i); if(i == 0) { t = new Type(); } if(i == 500) { delete t; } i++; } return 0; } void main() { auto t = new Thread(ThreadLoop); } Type is delete ever if i = 500;
Sep 29 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Patrick Kreft wrote:
 downs schrieb:
 Max Samukha wrote:
 1. More bugfixes in D 1.0. I would be happy to call it stable some
 day.
 2. The problem with RAII (destructors are useless:
 http://www.digitalmars.com/d/archives/digitalmars/D/learn/destructors_7525.html

 and other threads)
 3. GUI
Seconded, especially the first. And the second. Third would be nice too :) --downs
Hmm Second isnt an issue. I think it was misunderstood. Yeah D have GC and RAII, that means that u can explicit call a destructor and this will be executed.
No, it's not misunderstood. It's *because* D uses garbage collection that destructors are nearly useless. An example from the thread: class MyClass { OtherClass a; this() { a = new OtherClass; } ~this() { delete a; } } This code is very dangerous because by the time ~this is executed, a may already have been deleted. It may not have been. You *cannot* tell. 'a' will *probably* exist if you explicitly delete the object, or you use RAII, but the problem is that as soon as you miss an object, or decide to let the GC handle a single instance, the code becomes dangerous and you can't rely on it. This is solved slightly by having forcibly scoped class instances, but these instances are themselves incredibly restricted precisely because they can't escape their scope; meaning you can't return them out of functions. The problem, in a nutshell, is that because of the GC, a destructor cannot safely act on or modify *any* GC-allocated memory, since you never know when it's going to be destroyed. -- Daniel P.S. Insert general disclaimers about how there are corner cases and exceptions to the above, but I'm far to lazy to point them all out.
Sep 29 2007
parent reply "Patrick Kreft" <patrick_kreft gmx.net> writes:
Am 29.09.2007, 16:03 Uhr, schrieb Daniel Keep  
<daniel.keep.lists gmail.com>:

 Patrick Kreft wrote:
 downs schrieb:
 Max Samukha wrote:
 1. More bugfixes in D 1.0. I would be happy to call it stable some
 day.
 2. The problem with RAII (destructors are useless:
 http://www.digitalmars.com/d/archives/digitalmars/D/learn/destructors_7525.html

 and other threads)
 3. GUI
Seconded, especially the first. And the second. Third would be nice too :) --downs
Hmm Second isnt an issue. I think it was misunderstood. Yeah D have GC and RAII, that means that u can explicit call a destructor and this will be executed.
No, it's not misunderstood. It's *because* D uses garbage collection that destructors are nearly useless. An example from the thread: class MyClass { OtherClass a; this() { a = new OtherClass; } ~this() { delete a; } } This code is very dangerous because by the time ~this is executed, a may already have been deleted. It may not have been. You *cannot* tell. 'a' will *probably* exist if you explicitly delete the object, or you use RAII, but the problem is that as soon as you miss an object, or decide to let the GC handle a single instance, the code becomes dangerous and you can't rely on it. This is solved slightly by having forcibly scoped class instances, but these instances are themselves incredibly restricted precisely because they can't escape their scope; meaning you can't return them out of functions. The problem, in a nutshell, is that because of the GC, a destructor cannot safely act on or modify *any* GC-allocated memory, since you never know when it's going to be destroyed. -- Daniel P.S. Insert general disclaimers about how there are corner cases and exceptions to the above, but I'm far to lazy to point them all out.
I know so long exist an instance of MyClass so her resource will exist too, or the GC is useless cuz he make man class useless. Or i can not use that: class MyClass { OtherClass a; this() { a = new OtherClass; } void doit() { a.call() // scasm: opps a was deleted from GC Error eh? } ~this() { delete a; } } Look an http://www.digitalmars.com/d/garbage.html the GC use Reference counting that mean so long a is not noll, it will never delete. -- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
Sep 29 2007
next sibling parent reply downs <default_357-line yahoo.de> writes:
Patrick Kreft wrote:
 I know so long exist an instance of MyClass so her resource will exist
 too, or the GC is useless cuz he make man class useless.
... Yes. We know that. That's not the problem. The problem is that _when the destructor is called_ (emphasis), the GC might already have cleaned up your member variables. So you can't do clean-up in the destructor on _anything_ but local variables. Strings might be gone. AAs might be gone. To sum it up, it sucks. Hope that made things clearer. --downs
Sep 29 2007
parent reply downs <default_357-line yahoo.de> writes:
downs wrote:
 Patrick Kreft wrote:
 I know so long exist an instance of MyClass so her resource will exist
 too, or the GC is useless cuz he make man class useless.
... Yes. We know that. That's not the problem. The problem is that _when the destructor is called_ (emphasis), the GC might already have cleaned up your member variables. So you can't do clean-up in the destructor on _anything_ but local variables.
Erm. Sorry, it's early in the morning. By "local variables" I mean member variables that are a part of the class instance, i.e. that don't reference separate memory on the heap.
  --downs
--downs
Sep 29 2007
parent reply "Patrick Kreft" <patrick_kreft gmx.net> writes:
Am 30.09.2007, 08:24 Uhr, schrieb downs <default_357-line yahoo.de>:

 downs wrote:
 Patrick Kreft wrote:
 I know so long exist an instance of MyClass so her resource will exist
 too, or the GC is useless cuz he make man class useless.
... Yes. We know that. That's not the problem. The problem is that _when the destructor is called_ (emphasis), the GC might already have cleaned up your member variables. So you can't do clean-up in the destructor on _anything_ but local variables.
Erm. Sorry, it's early in the morning. By "local variables" I mean member variables that are a part of the class instance, i.e. that don't reference separate memory on the heap.
  --downs
--downs
Somewhat is confusing me, why D call my destructor if i never delete it o.O
Sep 30 2007
next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 9/30/07, Patrick Kreft <patrick_kreft gmx.net> wrote:
 Somewhat is confusing me, why D call my destructor if i never delete it o.O
There is no guarantee that the destructor will /ever/ be called - not even when your program exits! For example, if you have static/global data which happens by accident to look like it might be a pointer to an object on the heap, then the destructor for that object will not be called - ever.
Sep 30 2007
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 9/30/07, Patrick Kreft <patrick_kreft gmx.net> wrote:
 Somewhat is confusing me, why D call my destructor if i never delete it o.O
Conversely, of course, D /might/ your object's destructor at any time, so long as it can be sure you're not using it any more.
Sep 30 2007
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Patrick Kreft wrote:
 Am 29.09.2007, 16:03 Uhr, schrieb Daniel Keep
 I know so long exist an instance of MyClass so her resource will exist
 too, or the GC is useless cuz he make man class useless.
Yes.
 Or i can not use that:
  class MyClass
  {
      OtherClass a;
      this() {
         a = new OtherClass;
      }
 
      void doit()
      {
     a.call() // scasm: opps a was deleted from GC Error eh?
      }
I really hope that "scasm" isn't meant to be "sarcasm". That line is fine, but...
      ~this() {
         delete a;
      }
This is wrong for exactly the reasons I stated before. The problem is that you *cannot guarantee what order objects are destroyed it*. This means that by the time "delete a" is called, "a" may have already been destroyed. To put it in more concrete terms, the GC is free to destroy objects (assuming the instance of MyClass is called "this") either: 1. "this" followed by "a", which means ~this works just fine, *or* 2. "a" followed by "this", which will probably cause a segfault. You *cannot* tell which of those two will happen. In general, you *must not* attempt to delete, read or write fields or call member functions of objects inside a destructor. As downs said, it sucks.
  }
 
 Look an http://www.digitalmars.com/d/garbage.html
 the GC use Reference counting that mean so long a is not noll, it will
 never delete.
Um, *no*. The D garbage collector does *not* use reference counting; I have no idea where you got that from. The D garbage collector uses a conservative mark-and-sweep algorithm, which means when a collection occurs, it scans memory starting at the roots (which are the call stack and global data). -- Daniel
Sep 30 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Daniel Keep wrote:
 
 Patrick Kreft wrote:
 Am 29.09.2007, 16:03 Uhr, schrieb Daniel Keep
 I know so long exist an instance of MyClass so her resource will exist
 too, or the GC is useless cuz he make man class useless.
Yes.
 Or i can not use that:
  class MyClass
  {
      OtherClass a;
      this() {
         a = new OtherClass;
      }

      void doit()
      {
     a.call() // scasm: opps a was deleted from GC Error eh?
      }
I really hope that "scasm" isn't meant to be "sarcasm". That line is fine, but...
      ~this() {
         delete a;
      }
This is wrong for exactly the reasons I stated before. The problem is that you *cannot guarantee what order objects are destroyed it*. This means that by the time "delete a" is called, "a" may have already been destroyed. To put it in more concrete terms, the GC is free to destroy objects (assuming the instance of MyClass is called "this") either: 1. "this" followed by "a", which means ~this works just fine, *or* 2. "a" followed by "this", which will probably cause a segfault. You *cannot* tell which of those two will happen. In general, you *must not* attempt to delete, read or write fields or call member functions of objects inside a destructor. As downs said, it sucks.
  }

 Look an http://www.digitalmars.com/d/garbage.html
 the GC use Reference counting that mean so long a is not noll, it will
 never delete.
Um, *no*. The D garbage collector does *not* use reference counting; I have no idea where you got that from. The D garbage collector uses a conservative mark-and-sweep algorithm, which means when a collection occurs, it scans memory starting at the roots (which are the call stack and global data). -- Daniel
And if you want to know why this is true, here's the way I understand it. If I'm wrong someone please correct me. Basically when asked to collect, the GC first goes through and does "mark" phase where it marks things that it finds are still referred to (I think this is a recursive thing, starting with global variables and stack variables, marking what they refer to, then marking what those things refer to and so on.) Then the next step is "sweep". The GC goes through *all* the memory it knows about and any objects that aren't now marked must be unreachable, so it just reclaims them in the order it finds them. This is why an object and the thing it points to could be reclaimed in any order. The sweep phase doesn't attempt to reclaim memory in any sort of top-down manner. I presume it does not work that way because trying to do so would slow down the GC. --bb
Sep 30 2007
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bruno Medeiros" wrote
I wanted to probe the D community of the following issue:

 Right now, what would the most important thing for the success and 
 adoption of D? In other words, if one had to use D to develop a medium or 
 large scale software, what would be the most important things to have, 
 that we currently don't have (or aren't good enough)?
 (I'm not talking only about language features, in case you didn't get 
 that)
Dynamic library support. Without it, D executables are going to be unreasonably large. Imagine a large project like gnome or KDE implemented in only statically linked format. Everything in the language is acceptable as-is. I have little nitpicks, but It's just that I didn't have the ability to discuss/affect the design of those languages :) -Steve
Sep 28 2007
parent reply "Craig Black" <cblack ara.com> writes:
 Dynamic library support.  Without it, D executables are going to be
 unreasonably large.  Imagine a large project like gnome or KDE implemented 
 in only statically linked format.
Specifically what does D lack with regard to dynamic libraries? I know it can load DLL's at runtime. Does it lack support for load-time dynamic linking? If this is the case, that is a very big problem. -Craig
Sep 28 2007
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Craig Black" wrote
 Dynamic library support.  Without it, D executables are going to be
 unreasonably large.  Imagine a large project like gnome or KDE 
 implemented in only statically linked format.
Specifically what does D lack with regard to dynamic libraries? I know it can load DLL's at runtime. Does it lack support for load-time dynamic linking? If this is the case, that is a very big problem.
I think the problem is BUILDING dynamic libraries from D. I don't think D has any problems linking against dynamic libraries written in other languages, as the linker is the same as the C++/C linker. For example, both tango and phobos are static libs. I personally don't understand the reasons, as I don't really understand the intricacies of compiling/linking, but it doesn't seem to be supported from the command line that I can tell. -Steve
Sep 28 2007
parent reply Patrick Kreft <patrick_kreft gmx.net> writes:
Steven Schveighoffer schrieb:
 "Craig Black" wrote
 Dynamic library support.  Without it, D executables are going to be
 unreasonably large.  Imagine a large project like gnome or KDE 
 implemented in only statically linked format.
Specifically what does D lack with regard to dynamic libraries? I know it can load DLL's at runtime. Does it lack support for load-time dynamic linking? If this is the case, that is a very big problem.
I think the problem is BUILDING dynamic libraries from D. I don't think D has any problems linking against dynamic libraries written in other languages, as the linker is the same as the C++/C linker. For example, both tango and phobos are static libs. I personally don't understand the reasons, as I don't really understand the intricacies of compiling/linking, but it doesn't seem to be supported from the command line that I can tell. -Steve
Cuz Dynamic lib are platfrom feature. On Windows are DLL. Linux have shared libs, and its incompatible.
Sep 28 2007
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Patrick Kreft" wrote
 Cuz Dynamic lib are platfrom feature.
 On Windows are DLL. Linux have shared libs, and its incompatible.
I'm sorry, no, that argument falls flat on its face. 1. Other languages have solved this problem 2. DMD.exe is "incompatible" with dmd the linux compiler, so how do you explain the co-existance of those? -Steve
Sep 28 2007
parent reply Patrick Kreft <patrick_kreft gmx.net> writes:
Steven Schveighoffer schrieb:
 "Patrick Kreft" wrote
 Cuz Dynamic lib are platfrom feature.
 On Windows are DLL. Linux have shared libs, and its incompatible.
I'm sorry, no, that argument falls flat on its face. 1. Other languages have solved this problem 2. DMD.exe is "incompatible" with dmd the linux compiler, so how do you explain the co-existance of those? -Steve
Hmm, i didnt get what do u wanne say. Your previous speaker complain about not portable dynamic library. DLL arent running on Linux. CLR and Java are others situation. That is why the most lib are static libs, same situation like C++.
Sep 28 2007
parent reply "Craig Black" <craigblack2 cox.net> writes:
"Patrick Kreft" <patrick_kreft gmx.net> wrote in message 
news:fdjoh7$rdk$1 digitalmars.com...
 Steven Schveighoffer schrieb:
 "Patrick Kreft" wrote
 Cuz Dynamic lib are platfrom feature.
 On Windows are DLL. Linux have shared libs, and its incompatible.
I'm sorry, no, that argument falls flat on its face. 1. Other languages have solved this problem 2. DMD.exe is "incompatible" with dmd the linux compiler, so how do you explain the co-existance of those? -Steve
Hmm, i didnt get what do u wanne say. Your previous speaker complain about not portable dynamic library. DLL arent running on Linux. CLR and Java are others situation. That is why the most lib are static libs, same situation like C++.
It is true that load time D dynamic libraries would be different on linux/windows. However, that does not prevent us from being able to compile a DLL on Windows and an SO on linux. That would be fine. What Steven and I are trying to understand is why it seems that can't be done with DMD.
Sep 28 2007
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Craig Black wrote:
 
 "Patrick Kreft" <patrick_kreft gmx.net> wrote in message 
 news:fdjoh7$rdk$1 digitalmars.com...
 Steven Schveighoffer schrieb:
 "Patrick Kreft" wrote
 Cuz Dynamic lib are platfrom feature.
 On Windows are DLL. Linux have shared libs, and its incompatible.
I'm sorry, no, that argument falls flat on its face. 1. Other languages have solved this problem 2. DMD.exe is "incompatible" with dmd the linux compiler, so how do you explain the co-existance of those? -Steve
Hmm, i didnt get what do u wanne say. Your previous speaker complain about not portable dynamic library. DLL arent running on Linux. CLR and Java are others situation. That is why the most lib are static libs, same situation like C++.
It is true that load time D dynamic libraries would be different on linux/windows. However, that does not prevent us from being able to compile a DLL on Windows and an SO on linux. That would be fine. What Steven and I are trying to understand is why it seems that can't be done with DMD.
I think the problems with DLL usage and D were discussed extensively between Kris and Walter. Something about objs, DLL, COMDATS and templates, but I don't recall exactly what the problem was. I think this thread is were they discussed that: http://www.digitalmars.com/d/archives/digitalmars/D/Lib_change_leads_to_larger_executables_49170.html#N49204 If someone could post a short, understandable summary of what the problem is, it would be nice. Even nicer would be to document that somewhere, such as the wiki. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 28 2007
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Craig Black wrote:
 Dynamic library support.  Without it, D executables are going to be
 unreasonably large.  Imagine a large project like gnome or KDE implemented 
 in only statically linked format.
Specifically what does D lack with regard to dynamic libraries? I know it can load DLL's at runtime. Does it lack support for load-time dynamic linking? If this is the case, that is a very big problem. -Craig
Note: the following may be completely wrong :P I am, by no means, an expert on this, but here's how I understand it: Basically, there are two problems. The first is that Windows uses DLLs. DLLs cannot import symbols from the host they're being loaded into. This means that a D DLL cannot get access to the host's garbage collector, and must run its own. This is a *huge* problem because you now can't share memory between the host and the DLL because the GC's are going to collect memory they can't see. If the DLL passes an array back to the host, that array could be collected at *any moment* by the DLL's GC. It gets more fun when you factor in threads: the D GC has to "stop the world" when it collects. But this means that the DLL GC can't stop the host's threads from running and vice versa. This means there's no way for either host or library to safely collect garbage without potentially crashing the other. Yay! On linux, the problem is one of codegen: the dmd compiler can't generate position independent code, which is required for SO libraries. I believe that GDC is able to do so, however. That said, I don't use linux, so I could easily be wrong. What was supposed to save us from this was DDL: it basically implemented user-supported (as opposed to kernel-supported) dynamic libraries. However, the maintainer has been very busy, and it's languished; I don't think the current release compiles under D 1.0 yet. I believe that one of two things need to happen for good dynamic library support for D: 1. Walter finds time to change phobos from a static library to a dynamic one, thus introducing us to the wonders of DLL hell on Windows because phobos tends to change with each new compiler release *and* add position-independent code gen to the linux compiler. Or 2. We all start to chip in and get DDL back on its feet. Personally, I think 2 is the way to go :) -- Daniel
Sep 28 2007
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:fdkb16$1duo$1 digitalmars.com...

 Basically, there are two problems.  The first is that Windows uses DLLs.
 DLLs cannot import symbols from the host they're being loaded into.
 This means that a D DLL cannot get access to the host's garbage
 collector, and must run its own.

 This is a *huge* problem because you now can't share memory between the
 host and the DLL because the GC's are going to collect memory they can't
 see.  If the DLL passes an array back to the host, that array could be
 collected at *any moment* by the DLL's GC.
Actually, I think this was solved a while ago; basically you can set the GC to use a different GC than the one defined in the DLL. That is, you can hook the DLL's GC into the host app. But even if this is solved, there's a much more sinister problem with DLLs, for the same reason (no linking to host symbols): typeinfo. Basically, if you have a library that defines class A, and your host app uses class A and you make a DLL that uses class A, the class A in the host app is not the same class A as in the DLL. This breaks just about everything OOP.
  2. We all start to chip in and get DDL back on its feet.

 Personally, I think 2 is the way to go :)
I totally agree. Pragma, don't be too proud to ask for help :)
Sep 28 2007
next sibling parent Jascha Wetzel <firstname mainia.de> writes:
Jarrett Billingsley wrote:
 But even if this is solved, there's a much more sinister problem with DLLs, 
 for the same reason (no linking to host symbols): typeinfo.  Basically, if 
 you have a library that defines class A, and your host app uses class A and 
 you make a DLL that uses class A, the class A in the host app is not the 
 same class A as in the DLL.  This breaks just about everything OOP.
if that were so, it would be a bug in the runtime. comparing typeinfos shouldn't rely on their instances being singletons. and as far as i see it in the code, they don't. they just use it as a shortcut if the compared typeinfos happen to be the same instance. therefore this shouldn't be a problem.
Sep 29 2007
prev sibling parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Jarrett Billingsley Wrote:

 "Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
 news:fdkb16$1duo$1 digitalmars.com...
 
 Basically, there are two problems.  The first is that Windows uses DLLs.
 DLLs cannot import symbols from the host they're being loaded into.
 This means that a D DLL cannot get access to the host's garbage
 collector, and must run its own.

 This is a *huge* problem because you now can't share memory between the
 host and the DLL because the GC's are going to collect memory they can't
 see.  If the DLL passes an array back to the host, that array could be
 collected at *any moment* by the DLL's GC.
Actually, I think this was solved a while ago; basically you can set the GC to use a different GC than the one defined in the DLL. That is, you can hook the DLL's GC into the host app. But even if this is solved, there's a much more sinister problem with DLLs, for the same reason (no linking to host symbols): typeinfo. Basically, if you have a library that defines class A, and your host app uses class A and you make a DLL that uses class A, the class A in the host app is not the same class A as in the DLL. This breaks just about everything OOP.
  2. We all start to chip in and get DDL back on its feet.

 Personally, I think 2 is the way to go :)
I totally agree. Pragma, don't be too proud to ask for help :)
I don't get what the problem is. C++ must have had to solve the same problem long ago. Surely its just a matter of requiring libraries to exposes a particular interface for the runtime to hook into? It seems like something too obvious to have been omitted from the D language specification. Bruce.
Sep 29 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bruce Adams" <tortoise_74 yeah.who.co.uk> wrote in message 
news:fdmmfq$28di$1 digitalmars.com...

 I don't get what the problem is. C++ must have had to solve the same 
 problem long ago. Surely its just a matter of requiring libraries to 
 exposes a particular interface for the runtime to hook into?
 It seems like something too obvious to have been omitted from the D 
 language specification.
C++ has neither a GC (well, I guess it might get one in 0x but..) nor TypeInfo the way D has it. Neither problem exists in C++, so it never was a problem there to begin with.
Sep 30 2007
parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Jarrett Billingsley Wrote:

 "Bruce Adams" <tortoise_74 yeah.who.co.uk> wrote in message 
 news:fdmmfq$28di$1 digitalmars.com...
 
 I don't get what the problem is. C++ must have had to solve the same 
 problem long ago. Surely its just a matter of requiring libraries to 
 exposes a particular interface for the runtime to hook into?
 It seems like something too obvious to have been omitted from the D 
 language specification.
C++ has neither a GC (well, I guess it might get one in 0x but..) nor TypeInfo the way D has it. Neither problem exists in C++, so it never was a problem there to begin with.
I was using c++ as an example. How about java? Java has GC and good reflection and jar class files can be loaded dynamically. How does it solve this problem? I'm guessing by requiring dynamically loadable classes/libraries to support a particular interface. So what I'm saying is. What is the definition in D of: interface dynamicallyLoadable { }; For D to support shared libraries properly this should be well thought out and ideally published as part of the language specification (probably the ABI). Bruce.
Sep 30 2007
parent reply 0ffh <spam frankhirsch.net> writes:
Bruce Adams wrote:
 I was using c++ as an example. How about java? Java has GC and good 
 reflection and jar class files can be loaded dynamically. How does it 
 solve this problem?
Yeah, Java has a trick there: It does not compile to binary! Pfrrrtz! :) Check out DDL. It addresses your concern, and is actively being developed. Regards, Frank
Sep 30 2007
parent Robert Fraser <fraserofhenight gmail.com> writes:
0ffh Wrote:

 Check out DDL. It addresses your concern, and is actively being developed.
Nope, besides a single commit about a month or two back, I think pragma has been off DDL since pre-1.0. He said in a blog post he plans to return to it soon, after he does TracForums and some other stuff, so... Personally, I think this is one of the most interesting, and in a way important, D projects out there, so I hope he gets back to it soon.
Sep 30 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Daniel Keep wrote:
 On linux, the problem is one of codegen: the dmd compiler can't generate
 position independent code, which is required for SO libraries.
Yes dmd can, with the -fPIC switch.
Sep 28 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:
 Daniel Keep wrote:
 On linux, the problem is one of codegen: the dmd compiler can't generate
 position independent code, which is required for SO libraries.
Yes dmd can, with the -fPIC switch.
Ah, well; I stand corrected! Like I said, I don't use linux, so I can only parrot what I've heard others complain about in the past. :P Sorry about that. -- Daniel
Sep 28 2007
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Daniel Keep wrote:

 
 
 Walter Bright wrote:
 Daniel Keep wrote:
 On linux, the problem is one of codegen: the dmd compiler can't generate
 position independent code, which is required for SO libraries.
Yes dmd can, with the -fPIC switch.
Ah, well; I stand corrected! Like I said, I don't use linux, so I can only parrot what I've heard others complain about in the past. :P Sorry about that. -- Daniel
Well, afaik, noone has verified that this actually works. Rather the opposite, I think, -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Sep 29 2007
prev sibling next sibling parent reply Regan Heath <regan netmail.co.nz> writes:
Bruno Medeiros wrote:
 I wanted to probe the D community of the following issue:
 
 Right now, what would the most important thing for the success and 
 adoption of D? In other words, if one had to use D to develop a medium 
 or large scale software, what would be the most important things to 
 have, that we currently don't have (or aren't good enough)?
 (I'm not talking only about language features, in case you didn't get that)
 
 I ask this on the onset of seeing several people commenting on how they 
 can't wait until we have AST macros, or how the feature X would be 
 awesome to have, while me, now that I actually started to some coding in 
 D (even if in a very small project), would actually rate those a much 
 lower priority versus other things I'd like to have in the D ecosphere. 
  I'll do some more comments on this but first I'd like to hear about 
 other people's opinions.
IMO the biggest issue is libraries. First and foremost is the phobos/tango thing (I realise the guys involved are working on this one, so this is not a dig!) The next thing that bothers me is the many, many, many, ..., many, many different build systems and inter-dependencies that the available libraries for D use. In my idea world I would be able to use DSSS (or similar) to obtain and build a library without having to first install: rake perl ... and download; ..some 3rd party library.. ..this other library.. and _then_ figure out how to correctly install, build and use those tools and libraries. I once thought it would be cool to write a gui in D... after many frustrating hours download this, that, the other, and trying to decipher the arcane methods of building each of them I simply gave up. Granted, I'm primarily a windows developer, not a hardened hacker* like many unix devs. I'm not used to, nor do I like to, actually _build_ every tool and library that I want to use. I would vastly prefer a simple binary download in almost every case. *This definition of the word: http://en.wikipedia.org/wiki/Hacker#Academic_hackers Of course libraries which rely are essentially a C/C++ port will perhaps always be a bit complicated especially if you want the latest version of the C/C++ library - requiring you to download it and figure out how to build it etc - but even these could come in a semi pre-built form. So, in many cases I reckon if we could all just agree to use a certain build process, with standard build tools (like dsss, bud, rebuild, etc) then life would be much easier for people like me who just want to get up and running in as little time as possible. Regan
Sep 28 2007
parent Ingo Oeser <ioe-news rameria.de> writes:
Regan Heath wrote:

 The next thing that bothers me is the many, many, many, ..., many, many
 different build systems and inter-dependencies that the available
 libraries for D use.
 
 In my idea world I would be able to use DSSS (or similar) to obtain and
 build a library without having to first install:
    rake
    perl
    ...
 
In an professional D environment we would have tools to create *.msi files for windows, *.dmg for MacOS and LSB-3.1 compiliant *.rpm for Linux. That would resolve most of these issues. And one could start with DMD/DMC and GDC in these formats to enable the user to compile the rest. Any Windows programmer worth its money should be able to create a proper *.msi file. Instead of getting things done, people reinvent the wheel all the time, make it triangular and call it "the D way". As much as I like creativeness, cooperation would be more needed than new shapes of a wheel. Best Regards Ingo Oeser
Sep 28 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Bruno Medeiros wrote:
 I wanted to probe the D community of the following issue:
 
 Right now, what would the most important thing for the success and 
 adoption of D? In other words, if one had to use D to develop a medium 
 or large scale software, what would be the most important things to 
 have, that we currently don't have (or aren't good enough)?
1. A solid debugging environment 2. A robust and stable standard library D is at the point now where the addition of new language features are more a matter of convenience than anything. That said, I think struct ctors, dtors, and copy semantics would be quite useful, and some form of const semantics may help in selling D for use in a large project, depending on the background and needs of the team. Sean
Sep 28 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
Sean Kelly wrote:
 Bruno Medeiros wrote:
 I wanted to probe the D community of the following issue:

 Right now, what would the most important thing for the success and 
 adoption of D? In other words, if one had to use D to develop a medium 
 or large scale software, what would be the most important things to 
 have, that we currently don't have (or aren't good enough)?
1. A solid debugging environment
Let me extend this by adding: 1b. A tools developer with a support contract. The build team for a large project doesn't want to be dead in the water if something doesn't work. Unix development teams may be fairly used to the open source model, but Windows development teams are not. Having the phone number of a support rep tends to make the Windows people feel much more secure. In fact, I feel fairly confident that the chances of using D for Windows development at my current company would be basically nil for this reason alone. With a sufficiently stable compiler and solid debugging features I think it would be possible for Unix projects however. Sean
Sep 28 2007
prev sibling parent reply Jascha Wetzel <firstname mainia.de> writes:
Sean Kelly wrote:
 1. A solid debugging environment
can you elaborate on what ddbg should improve on it's share of the debugging environment?
Sep 28 2007
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
Right now, what's the most important for the success and adoption of D?

In a word: INFORMATION.

By that I mean, information directly accessible from the Digital Mars
D website. Information such as: what debuggers are available, what GUI
libs are available, etc..

I say this because so far this thread seems to consist of one person
saying X, and another person saying "We've already got that. Haven't
you heard of Acme Widgets implementation of X?". Seems to me that D
already has far more than people realise.
Sep 28 2007
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Janice Caron wrote:
 Right now, what's the most important for the success and adoption of D?
 
 In a word: INFORMATION.
 
 By that I mean, information directly accessible from the Digital Mars
 D website. Information such as: what debuggers are available, what GUI
 libs are available, etc..
 
What do you mean? The DMD front page has a menu section entitled "Tools" which lists some of the tools available, Like "Editors" and "More Tools". Hum, but I guess that section could be updated. A direct link to the http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries entry could be added , as well as link to http://www.prowiki.org/wiki4d/wiki.cgi?DebugEnvironments , and remove the "Windows Debugger" entry. Also, rename the "Editors" link to "Editors and IDEs" Another possible change, is to replate the "C .h to D .d" link with the http://www.prowiki.org/wiki4d/wiki.cgi?PortingOverview entry. I guess we could further discuss some updates to this menu section, if Walter is interested in changing it. (?) -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 28 2007
prev sibling next sibling parent reply Matti Niemenmaa <see_signature for.real.address> writes:
Jascha Wetzel wrote:
 Sean Kelly wrote:
 1. A solid debugging environment
can you elaborate on what ddbg should improve on it's share of the debugging environment?
Platform support is one thing. Of course, one can use gdb, but I'd prefer something with better D support---and there's the fact that I'm used to ddbg from the Windows side. I realize what I'm saying and that you're probably aware of this already, but from my point of view it's the only important thing where ddbg can improve. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Sep 28 2007
parent reply Jascha Wetzel <firstname mainia.de> writes:
Matti Niemenmaa wrote:
 Jascha Wetzel wrote:
 Sean Kelly wrote:
 1. A solid debugging environment
can you elaborate on what ddbg should improve on it's share of the debugging environment?
Platform support is one thing. Of course, one can use gdb, but I'd prefer something with better D support---and there's the fact that I'm used to ddbg from the Windows side. I realize what I'm saying and that you're probably aware of this already, but from my point of view it's the only important thing where ddbg can improve.
There is zerobugs, which is supposed to support D properly on the posix platforms. I don't know how well it works, because i haven't tried it. But since you only mentioned GDB, i suppose you haven't tried it, either. A debugger is a pretty system dependent tool. Porting it to posix is a major change. AFAIK writing code that's that close to the OS is also concerned with a lot of different versions and flavors of unix. I'd consider doing that if there were absolutely no other acceptable way to debug D on posix, but unless zerobugs is discontinued, i don't see the need.
Sep 30 2007
parent Carlos Santander <csantander619 gmail.com> writes:
Jascha Wetzel escribió:
 
 There is zerobugs, which is supposed to support D properly on the posix 
 platforms. I don't know how well it works, because i haven't tried it. 
 But since you only mentioned GDB, i suppose you haven't tried it, either.
 
It only has downloads for Linux on x86 and x64 (or whatever you want to call it). No Mac OS X, no PPC, and no signs of them ever coming given that Zero is closed source. -- Carlos Santander Bernal
Sep 30 2007
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Jascha Wetzel wrote:
 Sean Kelly wrote:
 1. A solid debugging environment
can you elaborate on what ddbg should improve on it's share of the debugging environment?
I was speaking in general terms. I feel that the design of the language is pretty solid, so it's largely down to tool and library support to increase acceptance. I tried ddbg for the first time yesterday and all in all it's pretty nice. However, it would be helpful if the pretty printing facilities were improved. From the console, I had trouble figuring out how to print any variables by name, and inside Code::Blocks I couldn't figure out a way to pretty print info about class instances (structs and basic types weren't a problem though). Sean
Sep 29 2007
parent reply Jascha Wetzel <firstname mainia.de> writes:
Sean Kelly wrote:
 I tried ddbg for the first time yesterday and all in all it's pretty 
 nice.  However, it would be helpful if the pretty printing facilities 
 were improved.  From the console, I had trouble figuring out how to 
 print any variables by name, and inside Code::Blocks I couldn't figure 
 out a way to pretty print info about class instances (structs and basic 
 types weren't a problem though).
On the command line = varname = object.member print the values, t varname t object.member print the types of these expressions. lsv prints the values of all local variables. The docs give more examples for expressions including casts, array access/slicing, dereferencing, etc. Is that what you were looking for? If so, how would you expect the help text to describe these commands in an obvious way? Last time i checked, Code::Blocks had a few problems with parsing the value output of structs, objects and arrays (everything with nesting curly braces). weird things tend to happen there... If in doubt, you need to use the command line.
Sep 30 2007
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jascha Wetzel wrote:

 Last time i checked, Code::Blocks had a few problems with parsing the 
 value output of structs, objects and arrays (everything with nesting 
 curly braces). weird things tend to happen there...
 If in doubt, you need to use the command line.
Would this be a simple fix for Code::Blocks ? Is there a bug for it ? http://developer.berlios.de/bugs/?group_id=5358 --anders
Sep 30 2007
parent reply Jascha Wetzel <firstname mainia.de> writes:
Anders F Björklund wrote:
 Jascha Wetzel wrote:
 
 Last time i checked, Code::Blocks had a few problems with parsing the 
 value output of structs, objects and arrays (everything with nesting 
 curly braces). weird things tend to happen there...
 If in doubt, you need to use the command line.
Would this be a simple fix for Code::Blocks ? Is there a bug for it ?
the fix wasn't obvious to me after looking at the source. it seemed that i would have to debug CB to find the problem. this bug is part of the problems: http://developer.berlios.de/bugs/?func=detailbug&bug_id=9014&group_id=5358
Sep 30 2007
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jascha Wetzel wrote:

 Last time i checked, Code::Blocks had a few problems with parsing the 
 value output of structs, objects and arrays (everything with nesting 
 curly braces). weird things tend to happen there...
 If in doubt, you need to use the command line.
Would this be a simple fix for Code::Blocks ? Is there a bug for it ?
the fix wasn't obvious to me after looking at the source. it seemed that i would have to debug CB to find the problem. this bug is part of the problems: http://developer.berlios.de/bugs/?func=detailbug&bug_id=9014&group_id=5358
OK. If anyone else finds it, CB patches happily accepted. (and bug reports and feature requests are also useful...) I don't use DMD or Ddbg much myself, mostly since I don't use Windows much. So it's usually done with GDC and GDB... --anders
Sep 30 2007
prev sibling parent Sean Kelly <sean f4.ca> writes:
Jascha Wetzel wrote:
 Sean Kelly wrote:
 I tried ddbg for the first time yesterday and all in all it's pretty 
 nice.  However, it would be helpful if the pretty printing facilities 
 were improved.  From the console, I had trouble figuring out how to 
 print any variables by name, and inside Code::Blocks I couldn't figure 
 out a way to pretty print info about class instances (structs and 
 basic types weren't a problem though).
On the command line = varname = object.member print the values, t varname t object.member print the types of these expressions. lsv prints the values of all local variables. The docs give more examples for expressions including casts, array access/slicing, dereferencing, etc. Is that what you were looking for? If so, how would you expect the help text to describe these commands in an obvious way?
Ah, it was the '=' and 't' I missed. They were in the 'expressions' category and for some reason I just skipped right over it. 'lsv' is actually fine for displaying local variables, and I'd used that before. I think the docs are actually fine as-is. I simply didn't spend enough time with ddbg.
 Last time i checked, Code::Blocks had a few problems with parsing the 
 value output of structs, objects and arrays (everything with nesting 
 curly braces). weird things tend to happen there...
 If in doubt, you need to use the command line.
No worries. I normally debug C++ code with emacs anyway, but I wanted to check out the Code::Blocks integration as an alternative. Sean
Sep 30 2007
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Bruno Medeiros wrote:
 I wanted to probe the D community of the following issue:
 
 Right now, what would the most important thing for the success and 
 adoption of D? In other words, if one had to use D to develop a medium 
 or large scale software, what would be the most important things to 
 have, that we currently don't have (or aren't good enough)?
 (I'm not talking only about language features, in case you didn't get that)
 
 I ask this on the onset of seeing several people commenting on how they 
 can't wait until we have AST macros, or how the feature X would be 
 awesome to have, while me, now that I actually started to some coding in 
 D (even if in a very small project), would actually rate those a much 
 lower priority versus other things I'd like to have in the D ecosphere. 
  I'll do some more comments on this but first I'd like to hear about 
 other people's opinions.
1. tango/phobos issue. Walter cannot continue to be responsible for the entire standard library as well as the compiler. 2. bugfixes for D1.0 3. gui library 4. other libraries I don't believe that the lack of new language features is seriously holding anyone back.
Sep 28 2007
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 9/28/07, Don Clugston <dac nospam.com.au> wrote:
 Walter cannot continue to be responsible for the entire
 standard library as well as the compiler.
Why not? He's done a damn good job so far.
Sep 28 2007
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.314.1190992928.16939.digitalmars-d puremagic.com...
 On 9/28/07, Don Clugston <dac nospam.com.au> wrote:
 Walter cannot continue to be responsible for the entire
 standard library as well as the compiler.
Why not? He's done a damn good job so far.
I suppose that's why there's an effort to make an alternative stdlib, then? Or maybe those who are making Tango are just a bunch of unreasonable implacable jerks. Fact is there's a pretty large contingent of people who _don't_ think Walter's done a damn good job with Phobos, myself included. There are threads upon threads about this topic already, however.
Sep 28 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:
 "Janice Caron" <caron800 googlemail.com> wrote in message 
 news:mailman.314.1190992928.16939.digitalmars-d puremagic.com...
 On 9/28/07, Don Clugston <dac nospam.com.au> wrote:
 Walter cannot continue to be responsible for the entire
 standard library as well as the compiler.
Why not? He's done a damn good job so far.
I suppose that's why there's an effort to make an alternative stdlib, then? Or maybe those who are making Tango are just a bunch of unreasonable implacable jerks. Fact is there's a pretty large contingent of people who _don't_ think Walter's done a damn good job with Phobos, myself included. There are threads upon threads about this topic already, however.
I think he did a good job writing and pulling together contributions to form a credible basic library to make writing apps possible. But now to go on to the next stage, people want more out of their standard library. Like containers for goodness sake -- linked lists, sets, queues and dequeues, etc. --bb
Sep 28 2007
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Janice Caron wrote:
 On 9/28/07, Don Clugston <dac nospam.com.au> wrote:
 Walter cannot continue to be responsible for the entire
 standard library as well as the compiler.
Why not?
Because he's overworked. Look through the change log for changes to Phobos. It's hardly changed in the past two years. Walter's got enough work to do with language and compiler development. I was one of the contributors to Phobos, but I found that typically it took a couple of compiler releases before typos got sorted out. It was horribly inefficient.
 He's done a damn good job so far.
I joined the Tango team simply because there was a repository I could access. Not because I was irritated with Walter.
Sep 28 2007
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 9/29/07, Don Clugston <dac nospam.com.au> wrote:
 Janice Caron wrote:
 On 9/28/07, Don Clugston <dac nospam.com.au> wrote:
 Walter cannot continue to be responsible for the entire
 standard library as well as the compiler.
Why not?
Because he's overworked.
"Responsible for" does not mean the same thing as "must do all the work". "Responsible for" means he is the captain; he gets the final say. Legally, Phobos is Walter's copyrighted work. Morally, it's his work and he's entitled to control it. If Walter wishes to relinquish his control, that's up to him. He is entitled to give away power, but you are not entitled to take it. When you say "cannot continue to be responsible for", it sounds like you're planning some sort of military coup or mutiny!
 Look through the change log for changes to Phobos. It's hardly changed in the
 past two years. Walter's got enough work to do with language and compiler
 development.
That's not relevant. Walter wrote Phobos. It's his code, period. He /is/ responsible for it, and /can/ continue to be responsible for it, indefinitely, even if he never changes another line of code.
 I was one of the contributors to Phobos, but I found that typically it took a
 couple of compiler releases before typos got sorted out. It was horribly
 inefficient.
Again, that's not relevant. Walter wrote Phobos, so it's his code, and he is responsible for it.
 I joined the Tango team simply because there was a repository I could access.
 Not because I was irritated with Walter.
Good for you. But that has nothing whatsoever to do with whether or not Walter has responsibility for Phobos.
Sep 28 2007
next sibling parent downs <default_357-line yahoo.de> writes:
I think you're talking past each other.
The issue seems to be with the meaning of the word "responsible".

Of course, Walter is responsible _for_ phobos, seeing as he made it.
The question, however, is if Walter also has a responsibility _towards_
phobos, namely to maintain and develop it, and if he has, whether he's
fulfilling that responsibility (many would argue that he isn't).

I hope that clears things up a little.
 --downs
Sep 29 2007
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Janice Caron wrote:

 "Responsible for" does not mean the same thing as "must do all the
 work". "Responsible for" means he is the captain; he gets the final
 say. Legally, Phobos is Walter's copyrighted work. Morally, it's his
 work and he's entitled to control it.
Ehrm, Phobos is Open Source licensed (zlib/png license / public domain) which means that you can use and modify it under those license terms... GDC already ships a modified version of Phobos (it's called "gPhobos") The D *specification*, however, it's Walter's copyrighted work and not available under any such license except for the frontend implementation. And that implementation part is Free Software, under GPLv1 or Artistic. So while Digital Mars Inc. keeps the copyright on all three parts of D, they're available under very different licensing terms for each part: * D - Copyrighted (not redistributable) * DMD - GPL/Artistic (and copyrighted too) * Phobos - zlib/png (some of it copyrighted, some it public domain) Having the D 1.0 specification, now that it's finished/done (right ?), being available/distributable under an open license would be great too. --anders PS. http://www.digitalmars.com/d/archives/digitalmars/D/20669.html
Sep 29 2007
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Janice Caron wrote:
 On 9/29/07, Don Clugston <dac nospam.com.au> wrote:
 Janice Caron wrote:
 On 9/28/07, Don Clugston <dac nospam.com.au> wrote:
 Walter cannot continue to be responsible for the entire
 standard library as well as the compiler.
Why not?
Because he's overworked.
"Responsible for" does not mean the same thing as "must do all the work". "Responsible for" means he is the captain; he gets the final say. Legally, Phobos is Walter's copyrighted work. Morally, it's his work and he's entitled to control it. If Walter wishes to relinquish his control, that's up to him. He is entitled to give away power, but you are not entitled to take it. When you say "cannot continue to be responsible for", it sounds like you're planning some sort of military coup or mutiny!
 Look through the change log for changes to Phobos. It's hardly changed in the
 past two years. Walter's got enough work to do with language and compiler
 development.
That's not relevant. Walter wrote Phobos. It's his code, period. He /is/ responsible for it, and /can/ continue to be responsible for it, indefinitely, even if he never changes another line of code.
That is exactly true, and it's unacceptable for a standard library. You've missed the point. The original question, was, "what's most important for the success of D". And my answer is, a standard library that continues to be developed.
 I was one of the contributors to Phobos, but I found that typically it took a
 couple of compiler releases before typos got sorted out. It was horribly
 inefficient.
Again, that's not relevant. Walter wrote Phobos, so it's his code, and he is responsible for it.
 I joined the Tango team simply because there was a repository I could access.
 Not because I was irritated with Walter.
Good for you. But that has nothing whatsoever to do with whether or not Walter has responsibility for Phobos.
Again --- that was not the question! You're assuming that forever, (1) Walter is the only person who can develop Phobos AND (2) Phobos is the standard library. It is crucial to the future of D that one of these two changes.
Sep 29 2007
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 9/30/07, Don Clugston <dac nospam.com.au> wrote:
 That is exactly true, and it's unacceptable for a standard library. You've
 missed the point. The original question, was, "what's most important for the
 success of D". And my answer is, a standard library that continues to be
developed.
I didn't miss that point. It's just a question of language. The original poster said /the/ standard library, and /the/ standard library is Phobos. I would love for a third-party library to come along and sit beside Phobos and become established as /a/ standard. Unfortunately, the only contender for that role right now appears to be Tango, which requires one to rip out the D runtime and replace it before it will work, rendering it utterly incompatible with Phobos. Libraries should be standalone things (in my opinion). That is, if I want a String class, I should just be able to import a module, and nothing else. I'm sure a string module probably exists within Tango, but if I can't import it without first having to render Phobos useless then I'm never going to use it. So I would be more than happy if there could be some third-party modules which we could import without interfering with Phobos, and if this collection of modules became known as a "standard" because of it's fantastic utility - great!
 Again --- that was not the question! You're assuming that forever,
 (1) Walter is the only person who can develop Phobos AND
 (2) Phobos is the standard library.
 It is crucial to the future of D that one of these two changes.
Apart from the word "forever", that is correct. I do assume that currently (1) and (2) are the case. (1) can only change if Walter delegates, or makes Phobos open source or something, and /that's up to him/. (2) is true because Walter says so, but that doesn't prevent addtional third party libraries from existing, and nor does it stop any combination of them becoming seen as "standard".
Sep 29 2007
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Janice Caron wrote:

 ... or makes Phobos open source or something ...
Phobos *is* open source. --anders
Sep 30 2007
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 9/30/07, Anders F Björklund <afb algonet.se> wrote:
 Janice Caron wrote:

 ... or makes Phobos open source or something ...
Phobos *is* open source.
Guess I meant "or something" then! :-) Hopefully, the intent of my post won't have been misunderstood though. Phobos is Walter's until (if) he relinquishes those rights, and that is as it should be. But that doesn't stop others from creating libraries that aren't called "Phobos", but that might still end up becoming "standards".
Sep 30 2007
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Janice Caron wrote:

 Hopefully, the intent of my post won't have been misunderstood though.
 Phobos is Walter's until (if) he relinquishes those rights, and that
 is as it should be. But that doesn't stop others from creating
 libraries that aren't called "Phobos", but that might still end up
 becoming "standards".
Honestly, I have no idea what the intent of your post was meant to be. But DMD has / had a lot of hardcoded dependencies on Phobos internals. The decision to fork the DMD runtime library was made in 2004 or so... If you need some background, then look for "Phobos Rising" or "Ares" ? Fortunately, the involved parties are now working on healing the fork. At least to make lowlevel rt/gc pluggable, even if stdlib/API differs. I would like Phobos to improve, even if Tango exists as an alternative. Decoupling the runtime and standard library is a good thing either way. Hopefully the differences between DMD/GDC and Phobos/gPhobos will also grow smaller (they are mostly about portability to Unix, and to 64-bit) If nothing else, then just because it's annoying in the end to have to write code for both "version(linux)" (DMD) and "version(Unix)" (GDC)... --anders
Sep 30 2007
parent reply Sean Kelly <sean f4.ca> writes:
Anders F Björklund wrote:
 
 Hopefully the differences between DMD/GDC and Phobos/gPhobos will also
 grow smaller (they are mostly about portability to Unix, and to 64-bit)
 If nothing else, then just because it's annoying in the end to have to
 write code for both "version(linux)" (DMD) and "version(Unix)" (GDC)...
The differences between the DMD and GDC runtimes in Tango are smaller than phobos/internal vs. gphobos/internal, but additional work is still required. To do so would be fairly simple though--nearly all of the differences are in the memory allocation routunes in internal/gc.d (lifetime.d in Tango). Sean
Sep 30 2007
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Sean Kelly wrote:

 Hopefully the differences between DMD/GDC and Phobos/gPhobos will also
 grow smaller (they are mostly about portability to Unix, and to 64-bit)
 If nothing else, then just because it's annoying in the end to have to
 write code for both "version(linux)" (DMD) and "version(Unix)" (GDC)...
The differences between the DMD and GDC runtimes in Tango are smaller than phobos/internal vs. gphobos/internal, but additional work is still required. To do so would be fairly simple though--nearly all of the differences are in the memory allocation routunes in internal/gc.d (lifetime.d in Tango).
Then again to support Tango, I would also need to add "version(Posix)" to the mix - but it's good to hear that DMD and GDC runtimes are closer. --anders
Sep 30 2007
prev sibling next sibling parent Jason House <jason.james.house gmail.com> writes:
1. A single standard library or, at a minimum, interoperability between
standard libraries

2. "One click installer" for the trio of compiler, standard library, and build
tool. (does not exist yet)

3. Support for Windows, Linux, Mac, 32 bit, and 64 bit at equal levels.
(Mac and 64 bit are currently lacking)

4. Active support for standard libraries and build tools.
(This is why I'd vote for Tango as the standard library - everyone admits that
Walter is busy working on D instead of focusing on Phobos)
Sep 28 2007
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
I'd like to see some kind of interoperability with C++.

If D calling C++ is too complex (which it seems to be), another option
that might be better is being able to somehow call D from C++, without
having to worry about writing extern(C) wrappers. Even if it is a limited
subset of the language, I'd probably be happy.

Perhaps a tool to take a D file and convert it into an appropriate C++ or C
header - being able to read struct and function declarations without needing
to do much manual work.


The reason I want to see this is I could write some code in C++, using
its vast array of features and libraries (namely: Qt is what I want
most. I'd prefer to use it than any homegrown D GUI library, for a few
reasons), while still being able to write much of my application logic
in D.



But since I put it this way, that doesn't require any change to the language;
just a simple code generator would be able to do most the work. Hmmm.







That is the big one on my mind right now. I'm *very* happy with D as it is
now, although, I do have some minor things I'd like to see, it is nothing
that is stopping me from using it on most my projects today.



-- 
Adam D. Ruppe
http://arsdnet.net
Sep 28 2007
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
I'll often get the comment from non-D programmers that the reason they 
don't use D is because D lacks feature X, and X is a requirement for 
their needs. I point out the fact that the programming language they do 
use also lacks feature X. Obviously, X is not the real reason.

The real reason is because D is new and different, and their peers 
aren't using D. They worry about being the sucker that adopts the new 
technology and winds up being embarrassed. They're not early adopters. 
Some have flat out told me they won't consider adopting D until they see 
more projects done by more people in D.

More features won't help. More libraries and more tools help indirectly 
by showing that more people are using D.

What will help a lot in making D seem "real" is to up our presence. This 
means more web pages that mention D, more articles, that talk about 
doing things in D. Magazine articles, like getting one in DDJ, are a BIG 
win here. Getting stuff on Digg, Reddit, and Slashdot help a lot. When 
programmers constantly are seeing "D" in the ordinary course of their 
work, that comfort level will be there, and they'll get on the bandwagon.

As an aside, at the Astoria Seminar http://www.astoriaseminar.com I 
decided not to bring up D because it was a C++ conference and I didn't 
want people to be annoyed thinking I was using it as a platform to sell 
D. But a lot of the people had heard about D, were interested, and asked 
me a lot of questions about it. They were genuinely interested. So I 
think the pump is primed, we just have to always look for opportunities 
to mention D.
Sep 28 2007
next sibling parent Ary Manzana <ary esperanto.org.ar> writes:
Walter Bright escribió:
 The real reason is because D is new and different, and their peers 
 aren't using D. They worry about being the sucker that adopts the new 
 technology and winds up being embarrassed. They're not early adopters. 
 Some have flat out told me they won't consider adopting D until they see 
 more projects done by more people in D.
Humm... That somehow reminds me of Esperanto... I guess people never change...
Sep 28 2007
prev sibling next sibling parent "Craig Black" <craigblack2 cox.net> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fdjjt6$1j4o$1 digitalmars.com...
 I'll often get the comment from non-D programmers that the reason they 
 don't use D is because D lacks feature X, and X is a requirement for their 
 needs. I point out the fact that the programming language they do use also 
 lacks feature X. Obviously, X is not the real reason.

 The real reason is because D is new and different, and their peers aren't 
 using D. They worry about being the sucker that adopts the new technology 
 and winds up being embarrassed. They're not early adopters. Some have flat 
 out told me they won't consider adopting D until they see more projects 
 done by more people in D.

 More features won't help. More libraries and more tools help indirectly by 
 showing that more people are using D.
When you say "features" won't help I would have to partially disagree. I believe the features that are in D now are what makes it so appealing and why it's as popular as it is. I think more features will help, but features alone won't get us there. It's a combination of things that facilitates language popularity including IDE's, libraries, compiler features and bug fixes, overall maturity, etc. I say this specifically because I really like the progressive development of the D language and I don't want that to slow down.
 What will help a lot in making D seem "real" is to up our presence. This 
 means more web pages that mention D, more articles, that talk about doing 
 things in D. Magazine articles, like getting one in DDJ, are a BIG win 
 here. Getting stuff on Digg, Reddit, and Slashdot help a lot. When 
 programmers constantly are seeing "D" in the ordinary course of their 
 work, that comfort level will be there, and they'll get on the bandwagon.

 As an aside, at the Astoria Seminar http://www.astoriaseminar.com I 
 decided not to bring up D because it was a C++ conference and I didn't 
 want people to be annoyed thinking I was using it as a platform to sell D. 
 But a lot of the people had heard about D, were interested, and asked me a 
 lot of questions about it. They were genuinely interested. So I think the 
 pump is primed, we just have to always look for opportunities to mention 
 D.
Yes publicity and marketing is important to get more people interested. But the technology needs to mature as well. Another thing that should not be underestimated is interoperability with C++. However, I think this can be achieved using a wrapper generator. For example, a wrapper generator is used for MOGRE for the OGRE C++ library. This is much more practical than porting a huge C++ code base. The same technology could be employed to provide C++ API's to the D community.
Sep 28 2007
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 I'll often get the comment from non-D programmers that the reason they 
 don't use D is because D lacks feature X, and X is a requirement for 
 their needs. I point out the fact that the programming language they do 
 use also lacks feature X. Obviously, X is not the real reason.
 
 The real reason is because D is new and different, and their peers 
 aren't using D. They worry about being the sucker that adopts the new 
 technology and winds up being embarrassed. They're not early adopters. 
 Some have flat out told me they won't consider adopting D until they see 
 more projects done by more people in D.
 
 More features won't help. More libraries and more tools help indirectly 
 by showing that more people are using D.
 
 What will help a lot in making D seem "real" is to up our presence. This 
 means more web pages that mention D, more articles, that talk about 
 doing things in D. Magazine articles, like getting one in DDJ, are a BIG 
 win here. Getting stuff on Digg, Reddit, and Slashdot help a lot. When 
 programmers constantly are seeing "D" in the ordinary course of their 
 work, that comfort level will be there, and they'll get on the bandwagon.
 
I wasn't really asking about dissemination or marketing. The question was more like: assuming a person that is already knowledgeable of D, and in control of what language and tools to use in his/her team, what issues would matter the most in adopting D. (and how that compare to other languages) -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 28 2007
parent Derek Parnell <derek psych.ward> writes:
On Fri, 28 Sep 2007 23:25:08 +0100, Bruno Medeiros wrote:

 I wasn't really asking about dissemination or marketing. The question 
 was more like: assuming a person that is already knowledgeable of D, and 
 in control of what language and tools to use in his/her team, what 
 issues would matter the most in adopting D. (and how that compare to 
 other languages)
(1) Stability. New releases are not going to break existing code. (2) Continuity. There will be compilers, linkers and other tools existing and maintained for the next 5-10 years. (3) Commerical Ability. I would want to be able to use commercial and open-source third party systems: databases (especiialy these), GUI, IDE, Debuggers, internet protocols (low and high level), etc ... I do not want to have to write these from scratch or to write 'connectivity' code. (4) Third Party Libraries. Especially those applicable to the industry that I'm targetting my software for. Such as Finance, Banking, Manufacturing, CRM, Accounting, Inventory, Purchasing, General Ledger, ... (5) Training. That there exists, outside of DigitalMars, material and courses that can educate my team in all aspects of D, from beginners to advanced. (6) Community. A vibrant community of peers that my team could relate to and particpate in. Face-to-Face contact is an essential ingredient in making these work. And these are just a few of my favourite things :-) -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Sep 28 2007
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
For what little it's worth, a few more weeks and assuming they don't
make me change it or reject it outright, you can cite my honours thesis.
 :)  Incidentally, D gets a glowing recommendation; I'm actually having
trouble coming up with drawbacks of using D, since it won't look
reasonable and balanced otherwise.  :3

	-- Daniel
Sep 28 2007
parent reply "nick.b" <nick.barbalich gmail.com> writes:
Daniel Keep wrote:
 For what little it's worth, a few more weeks and assuming they don't
 make me change it or reject it outright, you can cite my honours thesis.
  :)  Incidentally, D gets a glowing recommendation; I'm actually having
 trouble coming up with drawbacks of using D, since it won't look
 reasonable and balanced otherwise.  :3
 
 	-- Daniel
Daniel What exactly is our honours thesis about ? Nick
Sep 28 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
nick.b wrote:
 Daniel Keep wrote:
 For what little it's worth, a few more weeks and assuming they don't
 make me change it or reject it outright, you can cite my honours thesis.
  :)  Incidentally, D gets a glowing recommendation; I'm actually having
 trouble coming up with drawbacks of using D, since it won't look
 reasonable and balanced otherwise.  :3

     -- Daniel
Daniel What exactly is our honours thesis about ? Nick
<nazi type="grammar">I have *no* idea what *your* honours thesis is about.</nazi> Mine, on the other hand (:P) is (and the title was nailed down *yesterday* mind you) "The Application of Microsimulation to Epidemic Modelling". Basically, I'm writing a program that simulates the spread of an infection by modelling the individual carriers, how they move around, interact with other individuals, etc. It's a bit like a zero-player version of The Sims crossed with Theme Hospital and no graphics. Vaguely. :P -- Daniel
Sep 28 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply to Daniel,


 It's a bit like a zero-player version of The Sims crossed with Theme
 Hospital and no graphics.  Vaguely. :P
 
No graphics!!! Then how are you going to use it to woo CNN with scare stories and whip the nation into a pandemic panic so that your sisters-in-law's uncle can make a fortune with his wood fired generate patent when everyone turns into a survivalist in the boonies? Oh... wait a minute... that was the lame screen play I sent to Hollywood. Sorry. <G>
 -- Daniel
 
Sep 28 2007
prev sibling parent reply "nick.b" <nick.barbalich gmail.com> writes:
Daniel Keep wrote:
 
 nick.b wrote:
 Daniel Keep wrote:
 For what little it's worth, a few more weeks and assuming they don't
 make me change it or reject it outright, you can cite my honours thesis.
  :)  Incidentally, D gets a glowing recommendation; I'm actually having
 trouble coming up with drawbacks of using D, since it won't look
 reasonable and balanced otherwise.  :3

     -- Daniel
Daniel What exactly is our honours thesis about ? Nick
<nazi type="grammar">I have *no* idea what *your* honours thesis is about.</nazi> Mine, on the other hand (:P) is (and the title was nailed down *yesterday* mind you) "The Application of Microsimulation to Epidemic Modelling". Basically, I'm writing a program that simulates the spread of an infection by modelling the individual carriers, how they move around, interact with other individuals, etc. It's a bit like a zero-player version of The Sims crossed with Theme Hospital and no graphics. Vaguely. :P -- Daniel
Daniel Correction. The "our" should of been a "your". Sorry for this. Should of checked the reply more carefully. I thought the thesis might of been about "D". Nick
Sep 29 2007
parent downs <default_357-line yahoo.de> writes:
nick.b wrote:
 Daniel
 
 Correction.  The "our" should of been a "your".
 Sorry for this. Should of checked the reply more carefully.
 
 I thought the thesis might of been about "D".
 
 Nick
Is the "of" sarcasm? I honestly can't tell ... --downs
Sep 29 2007
prev sibling parent janderson <askme me.com> writes:
 More features won't help.
i think a feature that brings in a segment of the market that otherwise would have no real need for D would defiantly help D. For instance right now there is a search on for a language that will make parallel coding easier. D doesn't standout from other languages in this regard. Anyway the bottom line is the more segments of the market D can excel at the better its chances are. -Joel
Sep 30 2007
prev sibling next sibling parent BCS <BCS pathlink.com> writes:
Bruno Medeiros wrote:
 I wanted to probe the D community of the following issue:
 
 Right now, what would the most important thing for the success and 
 adoption of D? In other words, if one had to use D to develop a medium 
 or large scale software, what would be the most important things to 
 have, that we currently don't have (or aren't good enough)?
 (I'm not talking only about language features, in case you didn't get that)
 
 I ask this on the onset of seeing several people commenting on how they 
 can't wait until we have AST macros, or how the feature X would be 
 awesome to have, while me, now that I actually started to some coding in 
 D (even if in a very small project), would actually rate those a much 
 lower priority versus other things I'd like to have in the D ecosphere. 
  I'll do some more comments on this but first I'd like to hear about 
 other people's opinions.
 
without reading others comments: -IDE -Debugger (at least as good as c++ on Linux, ideally as good as VS) -Phobos vs. Tango resolution
Sep 28 2007
prev sibling next sibling parent reply div0 <div0 users.sourceforge.net> writes:
Bruno Medeiros wrote:
 I wanted to probe the D community of the following issue:
 
 Right now, what would the most important thing for the success and 
 adoption of D? In other words, if one had to use D to develop a medium 
 or large scale software, what would be the most important things to 
 have, that we currently don't have (or aren't good enough)?
 (I'm not talking only about language features, in case you didn't get that)
 
 I ask this on the onset of seeing several people commenting on how they 
 can't wait until we have AST macros, or how the feature X would be 
 awesome to have, while me, now that I actually started to some coding in 
 D (even if in a very small project), would actually rate those a much 
 lower priority versus other things I'd like to have in the D ecosphere. 
  I'll do some more comments on this but first I'd like to hear about 
 other people's opinions.
 
As close a copy of stl as possible in D. Learning a whole lot of new containers classes isn't going to enthuse most c++ programmers.
Sep 28 2007
parent reply Bruce Adams <tortoise_74 yahoo.co.uk> writes:
div0 Wrote:

 
 As close a copy of stl as possible in D.
 
 Learning a whole lot of new containers classes isn't going to enthuse 
 most c++ programmers.
I'd modify that. We want the equivalent containers and algorithms but in a D style. Cloning things exactly woulld probably result in an inelegant solution. There's already at least one open ticket related to this. http://d.puremagic.com/issues/show_bug.cgi?id=1420 Given the number of open source STL implementations around it shouldn't be too difficult to do. I'd volunteer but I don't have enough time right now and my D may not be up to it. In my job very little development gets down without a ticket. I don't know why more people don't add their bug reports there rather than complaining on these groups? Hold back on the (unnecessary) feature requests mind. Bruce.
Sep 28 2007
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bruce Adams wrote:

 div0 Wrote:
 
 As close a copy of stl as possible in D.

 Learning a whole lot of new containers classes isn't going to enthuse 
 most c++ programmers.
I'd modify that. We want the equivalent containers and algorithms but in a D style. Cloning things exactly woulld probably result in an inelegant solution. There's already at least one open ticket related to this. http://d.puremagic.com/issues/show_bug.cgi?id=1420 Given the number of open source STL implementations around it shouldn't be too difficult to do. I'd volunteer but I don't have enough time right now and my D may not be up to it. In my job very little development gets down without a ticket. I don't know why more people don't add their bug reports there rather than complaining on these groups? Hold back on the (unnecessary) feature requests mind.
Because it was *specifically* requested that only bug reports should go into the Bugzilla, and that feature requests should be made elsewhere ? That might have changed now, and it certainly is useful to be able to track those RFE things too, but that's how it started out at least... --anders
Sep 29 2007
parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Anders F Björklund Wrote:

 Bruce Adams wrote:
 
 div0 Wrote:
 
 As close a copy of stl as possible in D.

 Learning a whole lot of new containers classes isn't going to enthuse 
 most c++ programmers.
I'd modify that. We want the equivalent containers and algorithms but in a D style. Cloning things exactly woulld probably result in an inelegant solution. There's already at least one open ticket related to this. http://d.puremagic.com/issues/show_bug.cgi?id=1420 Given the number of open source STL implementations around it shouldn't be too difficult to do. I'd volunteer but I don't have enough time right now and my D may not be up to it. In my job very little development gets down without a ticket. I don't know why more people don't add their bug reports there rather than complaining on these groups? Hold back on the (unnecessary) feature requests mind.
Because it was *specifically* requested that only bug reports should go into the Bugzilla, and that feature requests should be made elsewhere ? That might have changed now, and it certainly is useful to be able to track those RFE things too, but that's how it started out at least... --anders
I wasn't suggesting bugzilla be used for (mostly) unnecessary feature requests just observing that there a fair few bug are mentioned here and don't as far I know have a bugzilla cross reference.
Sep 29 2007
prev sibling next sibling parent reply Robert Fraser <fraserofhenight gmail.com> writes:
BCS Wrote:

 -IDE
You're the first one in the topic to mention this. I agree with you quite a bit on this, as all the current IDEs, while sufficient for writing code, still have their faults. For example, no IDE at present can do code completion with this: mixin(ctFunction()); char[] ctFunction() { return "struct Foo { int bar,baz; }"; } Foo foo; foo. // Here's where I'd want code completion to come up and suggest "bar" and "baz" } That's a trivial example, but all the compile-time stuff (templates, CTFE, mixins, etc.) is hard to debug properly because there's no real way to see the compile-time results. IDEs that have the compiler's complete semantic knowledge about these things can provide a whole host of features targeted at a mostly D-specific problem (I know C++ has templates, too, and I'm not sure what IDEs do to make working with them easier). That's why I'm working on Descent (or, at least, will get back to it next week some time), with the hope that Descent can bridge the gap between very effective, feature-rich IDEs without full semantic knowledge (Mmrnhrnm or however you spell it is a really good example of it) and the compiler itself. Instant problem reporting and quick-fix functionality are also planned, so another piece to that bridge will be there as well.
Sep 28 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply to Robert,

 BCS Wrote:
 
 -IDE
 
You're the first one in the topic to mention this. I agree with you quite a bit on this, as all the current IDEs, while sufficient for writing code, still have their faults. For example, no IDE at present can do code completion with this: mixin(ctFunction()); char[] ctFunction() { return "struct Foo { int bar,baz; }"; } Foo foo; foo. // Here's where I'd want code completion to come up and suggest "bar" and "baz" } That's a trivial example, but all the compile-time stuff (templates, CTFE, mixins, etc.) is hard to debug properly because there's no real way to see the compile-time results. IDEs that have the compiler's complete semantic knowledge about these things can provide a whole host of features targeted at a mostly D-specific problem (I know C++ has templates, too, and I'm not sure what IDEs do to make working with them easier).
That reminds me of another thing -compile time debugging Figuring out what exactly is happening at compile time is a nightmare. Things I'd like to see include: - Breakpoint debugging of template work - Step through of template selection (list the overload options and list why each one did or didn't match) - visual unrolling of tuple foreach and static ifs - "what if" mode for templates (select a template, force the parameters to different things, and see what happens, all without change code) These tools would all have to be part of a IDE for them to be useful tools.
Sep 28 2007
prev sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
I've recorded a video that shows what Descent will be able to do in the 
next releases. This shows more or less why me and Robert think a good 
IDE will improve development speed in D.

http://esperanto.org.ar/descent/descent.html

Of course, the functionality is the same as DMD, but being able to 
detect errors without having to compile helps a lot. Also, as you can 
see, you can evaluate compile-time functions on-the-fly by writing 
static asserts that fail.

Enojy!
Ary

P.D.: The video starts with "Let's start by defining a function..." (it 
got cut in the recording).

Robert Fraser escribió:
 BCS Wrote:
 
 -IDE
You're the first one in the topic to mention this. I agree with you quite a bit on this, as all the current IDEs, while sufficient for writing code, still have their faults. For example, no IDE at present can do code completion with this: mixin(ctFunction()); char[] ctFunction() { return "struct Foo { int bar,baz; }"; } Foo foo; foo. // Here's where I'd want code completion to come up and suggest "bar" and "baz" } That's a trivial example, but all the compile-time stuff (templates, CTFE, mixins, etc.) is hard to debug properly because there's no real way to see the compile-time results. IDEs that have the compiler's complete semantic knowledge about these things can provide a whole host of features targeted at a mostly D-specific problem (I know C++ has templates, too, and I'm not sure what IDEs do to make working with them easier). That's why I'm working on Descent (or, at least, will get back to it next week some time), with the hope that Descent can bridge the gap between very effective, feature-rich IDEs without full semantic knowledge (Mmrnhrnm or however you spell it is a really good example of it) and the compiler itself. Instant problem reporting and quick-fix functionality are also planned, so another piece to that bridge will be there as well.
Sep 30 2007
parent reply div0 <div0 users.sourceforge.net> writes:
Ary Manzana wrote:
 I've recorded a video that shows what Descent will be able to do in the 
 next releases. This shows more or less why me and Robert think a good 
 IDE will improve development speed in D.
 
 http://esperanto.org.ar/descent/descent.html
 
 Of course, the functionality is the same as DMD, but being able to 
 detect errors without having to compile helps a lot. Also, as you can 
 see, you can evaluate compile-time functions on-the-fly by writing 
 static asserts that fail.
 
 Enojy!
 Ary
 
 P.D.: The video starts with "Let's start by defining a function..." (it 
 got cut in the recording).
Whilst that is admittedly very cool, I'd rather be able to click: Project -> Build All and have that work...
Sep 30 2007
parent reply Robert Fraser <fraserofhenight gmail.com> writes:
div0 Wrote:

 Ary Manzana wrote:
 I've recorded a video that shows what Descent will be able to do in the 
 next releases. This shows more or less why me and Robert think a good 
 IDE will improve development speed in D.
 
 http://esperanto.org.ar/descent/descent.html
 
 Of course, the functionality is the same as DMD, but being able to 
 detect errors without having to compile helps a lot. Also, as you can 
 see, you can evaluate compile-time functions on-the-fly by writing 
 static asserts that fail.
 
 Enojy!
 Ary
 
 P.D.: The video starts with "Let's start by defining a function..." (it 
 got cut in the recording).
Whilst that is admittedly very cool, I'd rather be able to click: Project -> Build All and have that work...
It's all integrated. That is to say, that what we're doing now (getting the errors and what not) is all part of porting in complete (i.e. what the compiler sees) semantic functionality. Given that we can do incremental building a la DSSS (even if your import statements are in a CTFE mixin!). We'll also be getting those oft-requested features like code completion, go-to definition and refactoring. The error marking shown in that video is just the first step, since it's being put in with the rest of the semantic code. So, patience, patience...
Oct 01 2007
parent div0 <div0 users.sourceforge.net> writes:
Robert Fraser wrote:
 div0 Wrote:
 
 Ary Manzana wrote:
 I've recorded a video that shows what Descent will be able to do in the 
 next releases. This shows more or less why me and Robert think a good 
 IDE will improve development speed in D.

 http://esperanto.org.ar/descent/descent.html

 Of course, the functionality is the same as DMD, but being able to 
 detect errors without having to compile helps a lot. Also, as you can 
 see, you can evaluate compile-time functions on-the-fly by writing 
 static asserts that fail.

 Enojy!
 Ary

 P.D.: The video starts with "Let's start by defining a function..." (it 
 got cut in the recording).
Whilst that is admittedly very cool, I'd rather be able to click: Project -> Build All and have that work...
It's all integrated. That is to say, that what we're doing now (getting the errors and what not) is all part of porting in complete (i.e. what the compiler sees) semantic functionality. Given that we can do incremental building a la DSSS (even if your import statements are in a CTFE mixin!). We'll also be getting those oft-requested features like code completion, go-to definition and refactoring. The error marking shown in that video is just the first step, since it's being put in with the rest of the semantic code. So, patience, patience...
Sweet!
Oct 01 2007
prev sibling next sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
I think the key ingredients of the success of a language are the 
language itself, the available libraries (both standard and not), and 
development tools(compiler, build tools, debuggers, IDEs).

In D's current state, for me the most important things affecting usage 
of D would by far be an IDE (with semantic features) and an integrated 
debugger. This outweighs by a large margin any upcoming or imaginable 
language features or changes D might have (even though I can think of a 
lot of them I'd like to see).

One of the reasons I made this thread is because I'm surprised that few 
people also consider and IDE and/or debugger to be the top issues.

Last semester I had a game programming college course whose work 
consisted entirely in making a game engine (no exams or anything else). 
I had the full choice of language to use, and although I know D (and its 
ecosystem) pretty well, I chose to do the project in C++. Why? Although 
I find the D language quite superior to C++, bottomline I would be 
significantly more productive in C++ due to the quality of Visual Studio 
C++ 2005, namely having "intellisense" and the high quality VS debugger, 
which were both highly superior to what D had available at the time.
If I had the same choice now, things might be different. With Mmrnmhrm's 
latest semantic functionality, which I think is "pretty close" to VS 
2005's semantic capabilites, I think I would be fine in that regard. As 
for debugging, I'm still trying out Descent+ddbg, so I don't know how 
solid that is yet.
But even if now I would prefer D over C++, I would still be rating IDE 
and debugger functionality above any others. I guess if were to do other 
kinds of development other than game programming (like server 
programming) it might increase the importance of other issues, like 
libraries, or compiler issues, but I'd likely still rank IDE and 
debugger pretty high, and language features/changes low* .

* relatively low, I'm not saying language features/changes are not 
important.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 28 2007
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
I can't really disagree with what anyone else has said so far, so I'll
throw in something new:

A new D compiler that is 100% independent of the DigitalMars code base.
 Doesn't have to be efficient, doesn't have to have awesome code
generation, but it needs to exist and it needs to be conformant.

And it needs to be written in D itself. :)

Why?  Take a look at how changes get added to Python.  Someone comes
along, and thinks "hey, X would be a useful feature!"  They introduce
the feature to the newsgroup, write up a Python Enhancement Proposal,
and discuss it.  In D's case, we stop about here (albeit without any
kind of formal proposal system).  With Python, they then typically go
off and write a patch to the interpreter to implement the change so that
people can experiment with it to see if it's useful or not.  Having an
easy to modify D compiler written in D would make this much easier, and
allow proposed features to actually be prototyped instead of those
long-winded entirely hypothetical threads on the NG where people argue
endlessly about a feature they can't actually test.

There's also the benefit that implementing the language spec will force
the language to be completely defined; it'll highlight holes, and ensure
the spec makes sense.

Also, we can finally say to people: "yes, D does have a compiler
implemented in D itself."  Not that it really matters, but perception
does. :)

Anyway, just thought I'd add something instead of just parroting.  Now
if you'll excuse me, I'm off to get some biscuits...

	-- Daniel
Sep 28 2007
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Daniel Keep wrote:
 I can't really disagree with what anyone else has said so far, so I'll
 throw in something new:
 
 A new D compiler that is 100% independent of the DigitalMars code base.
  Doesn't have to be efficient, doesn't have to have awesome code
 generation, but it needs to exist and it needs to be conformant.
 
 And it needs to be written in D itself. :)
 
 Why?  Take a look at how changes get added to Python.  Someone comes
 along, and thinks "hey, X would be a useful feature!"  They introduce
 the feature to the newsgroup, write up a Python Enhancement Proposal,
 and discuss it.  In D's case, we stop about here (albeit without any
 kind of formal proposal system).  With Python, they then typically go
 off and write a patch to the interpreter to implement the change so that
 people can experiment with it to see if it's useful or not.  Having an
 easy to modify D compiler written in D would make this much easier, and
 allow proposed features to actually be prototyped instead of those
 long-winded entirely hypothetical threads on the NG where people argue
 endlessly about a feature they can't actually test.
 
 There's also the benefit that implementing the language spec will force
 the language to be completely defined; it'll highlight holes, and ensure
 the spec makes sense.
 
 Also, we can finally say to people: "yes, D does have a compiler
 implemented in D itself."  Not that it really matters, but perception
 does. :)
 
 Anyway, just thought I'd add something instead of just parroting.  Now
 if you'll excuse me, I'm off to get some biscuits...
 
 	-- Daniel
While a D compiler in D itself might be interesting in some ways, it'd be, well, highly non-trivial to produce. Instead of investing man years of effort duplicating the front end, optimizer, and code generator that lives in dmd, how about finding a project that is in need of developers and work on it instead? It's not like there aren't tons or that we're overflowing with manpower to spend on redundancies. For those interested in experimenting with adding features to D can pick up gdc and play around _right now_. For an awful large subset of changes, they would be isolated to the front end parts exclusively and wouldn't need to get terribly involved with the gcc layers. Doing that has the additional advantage of having the potential to actually produce a diff that Walter can use as a basis for actually adopting the change. Anyway, just my opinions. Later, Brad
Sep 28 2007
parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Brad Roberts Wrote:

 Daniel Keep wrote:
 I can't really disagree with what anyone else has said so far, so I'll
 throw in something new:
 
 A new D compiler that is 100% independent of the DigitalMars code base.
  Doesn't have to be efficient, doesn't have to have awesome code
 generation, but it needs to exist and it needs to be conformant.
 
 And it needs to be written in D itself. :)
 
 Why?  Take a look at how changes get added to Python.  Someone comes
 along, and thinks "hey, X would be a useful feature!"  They introduce
 the feature to the newsgroup, write up a Python Enhancement Proposal,
 and discuss it.  In D's case, we stop about here (albeit without any
 kind of formal proposal system).  With Python, they then typically go
 off and write a patch to the interpreter to implement the change so that
 people can experiment with it to see if it's useful or not.  Having an
 easy to modify D compiler written in D would make this much easier, and
 allow proposed features to actually be prototyped instead of those
 long-winded entirely hypothetical threads on the NG where people argue
 endlessly about a feature they can't actually test.
 
 There's also the benefit that implementing the language spec will force
 the language to be completely defined; it'll highlight holes, and ensure
 the spec makes sense.
 
 Also, we can finally say to people: "yes, D does have a compiler
 implemented in D itself."  Not that it really matters, but perception
 does. :)
 
 Anyway, just thought I'd add something instead of just parroting.  Now
 if you'll excuse me, I'm off to get some biscuits...
 
 	-- Daniel
While a D compiler in D itself might be interesting in some ways, it'd be, well, highly non-trivial to produce. Instead of investing man years of effort duplicating the front end, optimizer, and code generator that lives in dmd, how about finding a project that is in need of developers and work on it instead? It's not like there aren't tons or that we're overflowing with manpower to spend on redundancies. For those interested in experimenting with adding features to D can pick up gdc and play around _right now_. For an awful large subset of changes, they would be isolated to the front end parts exclusively and wouldn't need to get terribly involved with the gcc layers. Doing that has the additional advantage of having the potential to actually produce a diff that Walter can use as a basis for actually adopting the change. Anyway, just my opinions. Later, Brad
A classic quesiton often asked when a new language is dreamed up is what is the compiler written in. If it isn't written in the new language a school of thought says you should run away. The essence of the argument is, if your shiny new language is so much better to write easily readable, enhanceable and bug free code why aren't you using it for the compiler for which that is so important. Also writing a full scale compiler is a big enough project to test the metal of your new language. I don't know about the gdc front end itself but gcc for all its power is not pretty to look at on the insides. However it is written in C so there's no reason a gdc clone couldn't be written in D. My understanding was that gdc was based on part of dmd with whatever machinations good and bad lurk beneath that beasts exterior. It could be so much prettier in D. [asbestos suit] While we're at it why don't we rewrite the linux kernel in D too :) [/asbestos suit]
Sep 29 2007
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Daniel,

 I can't really disagree with what anyone else has said so far, so I'll
 throw in something new:
 
 A new D compiler that is 100% independent of the DigitalMars code
 base.
 Doesn't have to be efficient, doesn't have to have awesome code
 generation, but it needs to exist and it needs to be conformant.
 And it needs to be written in D itself. :)
 
[...]
 Having an easy to modify D compiler written in D would make this much
 easier, and allow proposed features to actually be prototyped
That just about sums up a project I'm working on. (I'm doing it for fun so arguments about good use of time don't apply) The current state is, lexer works, mostly. Grammar is extracted from the docs and I'm working on a way to pound it into shape for dparse (cut it into small paces and reform it without direct left recursion) That's something like 9 months of my spare time so don't expect anything "real soon".
Sep 28 2007
prev sibling parent reply "Aziz K." <aziz.kerim gmail.com> writes:
Daniel Keep wrote:
 A new D compiler that is 100% independent of the DigitalMars code base=
.
  Doesn't have to be efficient, doesn't have to have awesome code
 generation, but it needs to exist and it needs to be conformant.

 And it needs to be written in D itself. :)
Could it possibly be that you are looking for something like this?: = http://code.google.com/p/dil/
 There's also the benefit that implementing the language spec will forc=
e
 the language to be completely defined; it'll highlight holes, and ensu=
re
 the spec makes sense.
I have a bug report regarding this here: = http://d.puremagic.com/issues/show_bug.cgi?id=3D1351 I still have to write one regarding the assembler page, but I'm a bit la= zy = at the moment :-)
 Also, we can finally say to people: "yes, D does have a compiler
 implemented in D itself."  Not that it really matters, but perception
 does. :)
That's what I think, too. By the way, my compiler (only front-end with n= o = semantic analysis yet) has over 13000 lines as I speak, and it's pretty = = awesome code :P Regards, Aziz
Sep 29 2007
parent reply Jascha Wetzel <firstname mainia.de> writes:
Aziz K. wrote:
 That's what I think, too. By the way, my compiler (only front-end with 
 no semantic analysis yet) has over 13000 lines as I speak, and it's 
 pretty awesome code :P
for the sake of competition, since we're talking about a lexer and parser, here is one that has about 2000 lines of easily maintainable code ;) http://seatd.mainia.de/
Sep 29 2007
next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Jascha Wetzel wrote:
 Aziz K. wrote:
 That's what I think, too. By the way, my compiler (only front-end with 
 no semantic analysis yet) has over 13000 lines as I speak, and it's 
 pretty awesome code :P
for the sake of competition, since we're talking about a lexer and parser, here is one that has about 2000 lines of easily maintainable code ;) http://seatd.mainia.de/
Hum, I've just realized that project also has a lot in common with what I'm doing right in the Mmrnmhrm IDE (semantic functionality), more than I'd thought. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 29 2007
parent reply Jascha Wetzel <firstname mainia.de> writes:
Bruno Medeiros wrote:
 Jascha Wetzel wrote:
 Aziz K. wrote:
 That's what I think, too. By the way, my compiler (only front-end 
 with no semantic analysis yet) has over 13000 lines as I speak, and 
 it's pretty awesome code :P
for the sake of competition, since we're talking about a lexer and parser, here is one that has about 2000 lines of easily maintainable code ;) http://seatd.mainia.de/
Hum, I've just realized that project also has a lot in common with what I'm doing right in the Mmrnmhrm IDE (semantic functionality), more than I'd thought.
unfortunately i'm not sure whether we can join forces, because of the different platforms/approaches we use - Java vs. D/native, manually implemented vs. automatically generated lexer/parser. but since i'm mainly targeting (compact) editors (like SciTE and soon Vim) and you are aiming at a full scale IDE, we won't stand in each other's way, either.
Sep 29 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Jascha Wetzel wrote:
 Bruno Medeiros wrote:
 Jascha Wetzel wrote:
 Aziz K. wrote:
 That's what I think, too. By the way, my compiler (only front-end 
 with no semantic analysis yet) has over 13000 lines as I speak, and 
 it's pretty awesome code :P
for the sake of competition, since we're talking about a lexer and parser, here is one that has about 2000 lines of easily maintainable code ;) http://seatd.mainia.de/
Hum, I've just realized that project also has a lot in common with what I'm doing right in the Mmrnmhrm IDE (semantic functionality), more than I'd thought.
unfortunately i'm not sure whether we can join forces, because of the different platforms/approaches we use - Java vs. D/native, manually implemented vs. automatically generated lexer/parser. but since i'm mainly targeting (compact) editors (like SciTE and soon Vim) and you are aiming at a full scale IDE, we won't stand in each other's way, either.
Well, I wasn't implying we should join forces, I was just pointing that out. Like you said, we're taking different approaches, although I think the most significant issue is that you'll be using D and me Java (so that you have more language features available). I dont' see Lexer/parser issues having much impact as semantic functionality works from the AST onward (and I use my own AST, not DMD's one). One thing though that we could share is test cases for semantic functionality. I've made some for Mmrnmhrm and hope to add and improve them in the future, as long as I have available time. The test I have are available here, but I'm currently in the process of cleaning them up and making them less brittle (less offset dependent) : http://www.dsource.org/projects/descent/browser/trunk/mmrnmhrm.tests/testdata http://www.dsource.org/projects/descent/browser/trunk/mmrnmhrm.tests/testdata/sampleSrc3 http://www.dsource.org/projects/descent/browser/trunk/mmrnmhrm.tests/src-core/dtool/tests/ref http://www.dsource.org/projects/descent/browser/trunk/mmrnmhrm.tests/src-core/mmrnmhrm/tests/core/ref http://www.dsource.org/projects/descent/browser/trunk/mmrnmhrm.tests/src/mmrnmhrm/tests/core/ref -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 30 2007
parent Jascha Wetzel <firstname mainia.de> writes:
Bruno Medeiros wrote:
 Well, I wasn't implying we should join forces
sure, but it's an obvious thought when two similar open projects in their early phase exist.
 One thing though that we could share is test cases for semantic 
 functionality. I've made some for Mmrnmhrm and hope to add and improve 
 them in the future, as long as I have available time.
that's a nice idea, thanks. i haven't organized my test cases, yet. i'll let you know when that changes.
Sep 30 2007
prev sibling parent reply Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Jascha Wetzel wrote:

 Aziz K. wrote:
 That's what I think, too. By the way, my compiler (only front-end with
 no semantic analysis yet) has over 13000 lines as I speak, and it's
 pretty awesome code :P
for the sake of competition, since we're talking about a lexer and parser, here is one that has about 2000 lines of easily maintainable code ;) http://seatd.mainia.de/
Your web page says "It provides access to an AST and an ASG of a D source file". So does the ASG part mean that it creates pointers from identifiers to declarations using the D scope rules? Is it possible to modify that data structure later or should one just clone the AST if further processing is needed? Comparing LOC is a bit pointless since the SEATD parser is machine generated - dil could be made shorter too with e.g. the coming macros without losing much readability. You mentioned compact editors in the other thread. One downside of SEATD is that the resulting binary is about twice as large as my vim binary. Doesn't sound very compact to me, but maybe that wasn't the point.
Sep 29 2007
parent Jascha Wetzel <firstname mainia.de> writes:
Jari-Matti Mäkelä wrote:
 Your web page says "It provides access to an AST and an ASG of a D source
 file". So does the ASG part mean that it creates pointers from identifiers
 to declarations using the D scope rules?
It creates a separate graph that interconnects Declaration objects (among others) that in turn point to the identifiers and line/column numbers in the source file. Search and enumeration of this graph is done by applying the D scope rules.
 Is it possible to modify that data
 structure later or should one just clone the AST if further processing is
 needed?
It will be the preferred way to modify the ASG with simply operations and generate a new (full or partial) AST from the modified ASG when required. As of now (v0.01.2 alpha) no modification is supported, though.
 Comparing LOC is a bit pointless since the SEATD parser is machine
 generated - dil could be made shorter too with e.g. the coming macros
 without losing much readability.
I don't think it's pointless. We're talking about 6 times the size. Maintaining that much code is considerably more work. SEATD's ~2000 LOC already include some semantic analysis. Plus, the grammar definition has significantly less technical detail to deal with and is therefore less error prone.
 You mentioned compact editors in the other
 thread. One downside of SEATD is that the resulting binary is about twice
 as large as my vim binary. Doesn't sound very compact to me, but maybe that
 wasn't the point.
With "compact" i was referring to the editors, to set them apart from a feature rich IDE. You still have a point there, though. SEATD's binary is indeed pretty big (190kb with UPX, 905kb without). That is partially because it's a D binary and therefore carries around the Tango runtime and a lot of TypeInfos. But the generated parser still has potential to improve in size, too. Until now i was concerned with performance optimization only. The binary size is a minor issue, though.
Sep 29 2007
prev sibling next sibling parent reply 0ffh <spam frankhirsch.net> writes:
Bruno Medeiros wrote:
 I wanted to probe the D community of the following issue:
 
 Right now, what would the most important thing for the success and 
 adoption of D? In other words, if one had to use D to develop a medium 
 or large scale software, what would be the most important things to 
 have, that we currently don't have (or aren't good enough)?
Well, I sure can't tell... maybe stuff like that, whatever the reason? Lester Martin wrote in "digitalmars.D.announce" about "Re: D Installler":

 easily.
Regards, Frank
Sep 29 2007
parent 0ffh <spam frankhirsch.net> writes:
0ffh wrote:
 Well, I sure can't tell... maybe stuff like that, whatever the reason?
To those who might be prone to get me wrong: What is it, that is easier about the other languages? Is it libs, or IDEs or GUIs for IDEs or just the GUIs - or is the present state really better than it looks to some, because it is not sufficiently advertised? What is the right level to answer those questions? Why do I not have any answers? :-p Regards, Frank
Sep 29 2007
prev sibling parent Clay Smith <clayasaurus gmail.com> writes:
Bruno Medeiros wrote:
 I wanted to probe the D community of the following issue:
 
 Right now, what would the most important thing for the success and 
 adoption of D? In other words, if one had to use D to develop a medium 
 or large scale software, what would be the most important things to 
 have, that we currently don't have (or aren't good enough)?
 (I'm not talking only about language features, in case you didn't get that)
 
 I ask this on the onset of seeing several people commenting on how they 
 can't wait until we have AST macros, or how the feature X would be 
 awesome to have, while me, now that I actually started to some coding in 
 D (even if in a very small project), would actually rate those a much 
 lower priority versus other things I'd like to have in the D ecosphere. 
  I'll do some more comments on this but first I'd like to hear about 
 other people's opinions.
 
* General bug fixes
Oct 02 2007