Re: Is D right for me?
On 19-ott-10, at 22:41, Fawzi Mohamed wrote: [...] sorry I forgot the projects in there, the project is at http://dsource.org/projects/blip the code is actually at http://github.com/fawzi/blip I hope to do a release in the next days. It needs hwloc (tested with 1.x) and libev (tested with 3.9). forgot to add that by default the build script also needs lapack (for linalg ops on NArray), but that is not needed if one is interested only in the parallel/io part Windows will need some porting, but on max and linux it works correctly (as far as I tested). I havent done any real optimization yet (waiting to have a more complete test suite, and I have switched off reuse of non recursive tasks, thus allocating a bit too much at a low level). feedback is appreciated :) ciao Fawzi
Re: Is D right for me?
On 19-ott-10, at 22:04, Andrei Alexandrescu wrote: On 10/12/10 7:01 CDT, Fawzi Mohamed wrote: [...] I very much agree that IO should be scalable. In my opinion this is possible if one has a robust framework for smp parallelization. This is what I have been working on with blip http://dsource.org/ blip . Seeing your recent comments about fixing druntime, I wanted to take a look at this other work but the page seems to be in error. Did you migrate blip somewhere else? sorry I forgot the projects in there, the project is at http://dsource.org/projects/blip the code is actually at http://github.com/fawzi/blip I hope to do a release in the next days. It needs hwloc (tested with 1.x) and libev (tested with 3.9). Windows will need some porting, but on max and linux it works correctly (as far as I tested). I havent done any real optimization yet (waiting to have a more complete test suite, and I have switched off reuse of non recursive tasks, thus allocating a bit too much at a low level). feedback is appreciated :) ciao Fawzi
Re: Is D right for me?
Andrei Alexandrescu schrieb: On 10/12/10 7:01 CDT, Fawzi Mohamed wrote: On 12-ott-10, at 13:04, Denis Koroskin wrote: On Tue, 12 Oct 2010 02:32:55 +0400, Andrei Alexandrescu wrote: On 10/11/2010 12:38 PM, Daniel Gibson wrote: But parts of phobos are deprecated or will be deprecated and there still is no alternative for them. That may prevent people from writing "real" projects in D2 (or D at all) - who wants to use classes that will be deprecated soon? Sure, that old stuff will not be removed and can still be used, but I personally feel a bit uncomfortable with using deprecated code. Agreed. Maybe this is a good time to sart making a requirements list for streams. What are the essential features/feature groups? Andrei For me, I/O should be scalable (and thus support async operations) so I came up with my own implementation. I've tried building it on top of std.concurrency, but it doesn't scale either. So, once again, I had to implement my own message passing mechanism. I can implement existing std.concurrency interface on top of my own one without sacrificing anything, but not vice-versa). I very much agree that IO should be scalable. In my opinion this is possible if one has a robust framework for smp parallelization. This is what I have been working on with blip http://dsource.org/blip . Seeing your recent comments about fixing druntime, I wanted to take a look at this other work but the page seems to be in error. Did you migrate blip somewhere else? Thanks, Andrei http://dsource.org/projects/blip (he forgot projects/ in the URL)
Re: Is D right for me?
On 10/12/10 7:01 CDT, Fawzi Mohamed wrote: On 12-ott-10, at 13:04, Denis Koroskin wrote: On Tue, 12 Oct 2010 02:32:55 +0400, Andrei Alexandrescu wrote: On 10/11/2010 12:38 PM, Daniel Gibson wrote: But parts of phobos are deprecated or will be deprecated and there still is no alternative for them. That may prevent people from writing "real" projects in D2 (or D at all) - who wants to use classes that will be deprecated soon? Sure, that old stuff will not be removed and can still be used, but I personally feel a bit uncomfortable with using deprecated code. Agreed. Maybe this is a good time to sart making a requirements list for streams. What are the essential features/feature groups? Andrei For me, I/O should be scalable (and thus support async operations) so I came up with my own implementation. I've tried building it on top of std.concurrency, but it doesn't scale either. So, once again, I had to implement my own message passing mechanism. I can implement existing std.concurrency interface on top of my own one without sacrificing anything, but not vice-versa). I very much agree that IO should be scalable. In my opinion this is possible if one has a robust framework for smp parallelization. This is what I have been working on with blip http://dsource.org/blip . Seeing your recent comments about fixing druntime, I wanted to take a look at this other work but the page seems to be in error. Did you migrate blip somewhere else? Thanks, Andrei
Re: Is D right for me?
On 2010-10-15 01:22, Sean Kelly wrote: Jacob Carlborg Wrote: Thread.getThis() calls pthread_getspecific which is just three instructions on Mac OS X, so I guess that's not why it's so slow. The only thing I can think of is first moving the if statement into the assert and then trying to inline as much of the function calls. Swapping the assert and the executable code would save you a jump, but inlining the call to ___tls_get_addr would be be a bit trickier. We'd probably have to expose Thread.sm_this as an extern (C) symbol, move the function to object.d and explicitly do the pthread_getspecific call there. If that would be enough for the compiler to inline the calls then it shouldn't be too hard to test, but I'm worried that the call generation may happen too late. I guess it wouldn't be too hard to figure out from looking at the asm output though (PIC code weirdness notwithstanding). I think it would save more than just a jump. When compiling in release mode the compiler have to generate code for the if statement but with an assert it can just skip it. See the assembly at the bottom. I was thinking about inlining Thread.getThis() as a first step. Then inlining pthread_getspecific as a second step. I don't know if we can inline pthread_getspecific due to license issues but at least there is an inline version available. Then of course inlining the call to __tls_get_addr could help as well. Both of the following versions are compiled with "dmd -c -O -release". ___tls_get_addr in thread.d compiled with if statement: ___tls_get_addr: pushEBP mov EBP,ESP pushEAX mov EDX,EAX pushEBX call L2000 L2000: pop EBX cmp 03AAh[EBX],EDX ja L2011 cmp 03AEh[EBX],EDX ja L2012 L2011: hlt L2012: mov -4[EBP],EDX call L217E mov EAX,054h[EAX] add EAX,-4[EBP] sub EAX,03AAh[EBX] pop EBX mov ESP,EBP pop EBP ret nop 22 lines for the above code, the same compiled with an assert instead: ___tls_get_addr: pushEBP mov EBP,ESP sub ESP,8 mov -4[EBP],EAX call L216E mov EAX,054h[EAX] add EAX,-4[EBP] call L200D L200D: pop ECX sub EAX,038Dh[ECX] mov ESP,EBP pop EBP ret This is just 13 lines of code, I can tell you that I don't know assembly but I can see the number of instructions are a lot more in the version with the if statement than the one with the assert. -- /Jacob Carlborg
Re: Is D right for me?
On 2010-10-14 23:11, Walter Bright wrote: Jacob Carlborg wrote: As I said, the static TLS data is put in the object file like any other data. No, it isn't. It has to go into segregated sections so it can be distinguished from regular static data. Fixup records are different for them, and some special code sequences are used to access them. I don't know if we misunderstand each other here but I was trying to say that the TLS data is put in the object like any other data, just in a different section with a different flag. That is at least how I understand it from reading: http://www.akkadia.org/drepper/tls.pdf I can see that the linker could/would be a problem. Of course the compiler needs to be updated but there should be any problems updating dmd. I guess you're referring to gcc. I also have to say that I haven't fully understood what the linker does in this case, with the TLS data. On Linux, the linker understands the special TLS sections, and the special relocation fixups to reference them. It also patches the specific TLS access code sequences emitted by the compiler differently depending on whether the result is to go into an executable or a shared library. Ok, thanks for the explanation. On OSX, none of this happens. -- /Jacob Carlborg
Re: Is D right for me?
Jacob Carlborg Wrote: > > Thread.getThis() calls pthread_getspecific which is just three > instructions on Mac OS X, so I guess that's not why it's so slow. The > only thing I can think of is first moving the if statement into the > assert and then trying to inline as much of the function calls. Swapping the assert and the executable code would save you a jump, but inlining the call to ___tls_get_addr would be be a bit trickier. We'd probably have to expose Thread.sm_this as an extern (C) symbol, move the function to object.d and explicitly do the pthread_getspecific call there. If that would be enough for the compiler to inline the calls then it shouldn't be too hard to test, but I'm worried that the call generation may happen too late. I guess it wouldn't be too hard to figure out from looking at the asm output though (PIC code weirdness notwithstanding).
Re: Is D right for me?
On 2010-10-14 20:12, Walter Bright wrote: Jacob Carlborg wrote: On 2010-10-13 20:18, Walter Bright wrote: Furthermore, OSX has no documented way to allocate TLS static data in the object file. I spent considerable effort figuring out a way to do this and get around the numerous bugs in the OSX linker that tried to stop me. I just read a bit about how TLS is implemented on linux, just of curiosity what was the problem, the linker, runtime, loader or all? On linux the static TLS data is put in the the object file like any other data. The only difference is it has a different name of the section/segment and an additional flag. Then of course the linker, runtime and loader know about these sections and make any necessary initializations when the application loads. The linker, runtime, and loader do not know about any TLS sections under OSX, and do not do any necessary initializations. The linker bugs were because it behaved erratically when laying out named sections that were not the usual sections emitted by gcc. Can't the necessary initializations be done early in the start up process of the D runtime or is it already to late when application receives control? Since you have non-standard sections in the object file I assume you solved it. Anyhow, the source is here: http://www.dsource.org/projects/druntime/browser/trunk/src/core/thread.d and the function you're interested in is ___tls_get_addr. You're welcome to make improvements to it. That doesn't seem to be a lot of code to optimize, is Thread.getThis() slow? I've already been 'round the block on that code a few times. If you want to have a go at it, perhaps I missed something and you'll see it. Thread.getThis() calls pthread_getspecific which is just three instructions on Mac OS X, so I guess that's not why it's so slow. The only thing I can think of is first moving the if statement into the assert and then trying to inline as much of the function calls. -- /Jacob Carlborg
Re: Is D right for me?
Jacob Carlborg wrote: As I said, the static TLS data is put in the object file like any other data. No, it isn't. It has to go into segregated sections so it can be distinguished from regular static data. Fixup records are different for them, and some special code sequences are used to access them. I can see that the linker could/would be a problem. Of course the compiler needs to be updated but there should be any problems updating dmd. I guess you're referring to gcc. I also have to say that I haven't fully understood what the linker does in this case, with the TLS data. On Linux, the linker understands the special TLS sections, and the special relocation fixups to reference them. It also patches the specific TLS access code sequences emitted by the compiler differently depending on whether the result is to go into an executable or a shared library. On OSX, none of this happens.
Re: Is D right for me?
On 2010-10-14 17:51, Sean Kelly wrote: Jacob Carlborg wrote: On 2010-10-13 20:18, Walter Bright wrote: Jacob Carlborg wrote: I don't know how you have implemented TLS on Mac OS X but it does support TLS via the Posix API pthreads. This is the only page from Apple's documentation I could find for now (I'm certain I've seen a better page) http://developer.apple.com/macosx/multithreadedprogramming.html . Yeah, I know about pthreads TLS, but that's wholly inadequate. According to these: http://lifecs.likai.org/2010/05/mac-os-x-thread-local-storage.html and http://lists.apple.com/archives/darwin-dev/2005/Sep/msg5.html the implementation of TLS in the Posix API on Mac OS X should be as fast as the EFL implementation. As the blog post mentions, there is an inline version of pthread_getspecific. I also have to add that I have no idea if the pthreads can be used to implement TLS in the compiler. With gcc on OSX, try this: __thread int x; It will fail. Furthermore, OSX has no documented way to allocate TLS static data in the object file. I spent considerable effort figuring out a way to do this and get around the numerous bugs in the OSX linker that tried to stop me. I just read a bit about how TLS is implemented on linux, just of curiosity what was the problem, the linker, runtime, loader or all? On linux the static TLS data is put in the the object file like any other data. The only difference is it has a different name of the section/segment and an additional flag. Then of course the linker, runtime and loader know about these sections and make any necessary initializations when the application loads. On OSX the object file format lacks a way to specify a TLS data section, and so the linker would need upgrading as well. And the compiler, since it needs to generate the object files. As I said, the static TLS data is put in the object file like any other data. I can see that the linker could/would be a problem. Of course the compiler needs to be updated but there should be any problems updating dmd. I guess you're referring to gcc. I also have to say that I haven't fully understood what the linker does in this case, with the TLS data. -- /Jacob Carlborg
Re: Is D right for me?
Jacob Carlborg wrote: On 2010-10-13 20:18, Walter Bright wrote: Furthermore, OSX has no documented way to allocate TLS static data in the object file. I spent considerable effort figuring out a way to do this and get around the numerous bugs in the OSX linker that tried to stop me. I just read a bit about how TLS is implemented on linux, just of curiosity what was the problem, the linker, runtime, loader or all? On linux the static TLS data is put in the the object file like any other data. The only difference is it has a different name of the section/segment and an additional flag. Then of course the linker, runtime and loader know about these sections and make any necessary initializations when the application loads. The linker, runtime, and loader do not know about any TLS sections under OSX, and do not do any necessary initializations. The linker bugs were because it behaved erratically when laying out named sections that were not the usual sections emitted by gcc. Anyhow, the source is here: http://www.dsource.org/projects/druntime/browser/trunk/src/core/thread.d and the function you're interested in is ___tls_get_addr. You're welcome to make improvements to it. That doesn't seem to be a lot of code to optimize, is Thread.getThis() slow? I've already been 'round the block on that code a few times. If you want to have a go at it, perhaps I missed something and you'll see it.
Re: Is D right for me?
Jacob Carlborg wrote: > On 2010-10-13 20:18, Walter Bright wrote: >> Jacob Carlborg wrote: >>> I don't know how you have implemented TLS on Mac OS X but it does >>> support TLS via the Posix API pthreads. This is the only page from >>> Apple's documentation I could find for now (I'm certain I've seen a >>> better page) >>> http://developer.apple.com/macosx/multithreadedprogramming.html . >> >> Yeah, I know about pthreads TLS, but that's wholly inadequate. >> >>> According to these: >>> http://lifecs.likai.org/2010/05/mac-os-x-thread-local-storage.html > > > and >>> http://lists.apple.com/archives/darwin-dev/2005/Sep/msg5.html > > > the >>> implementation of TLS in the Posix API on Mac OS X should be as fast >>> as the EFL implementation. As the blog post mentions, there is an >>> inline version of pthread_getspecific. I also have to add that I > > > have >>> no idea if the pthreads can be used to implement TLS in the > > > compiler. >> >> With gcc on OSX, try this: >> >> __thread int x; >> >> It will fail. Furthermore, OSX has no documented way to allocate TLS >> static data in the object file. I spent considerable effort figuring > > out >> a way to do this and get around the numerous bugs in the OSX linker > > that >> tried to stop me. > > I just read a bit about how TLS is implemented on linux, just of > curiosity what was the problem, the linker, runtime, loader or all? On > linux the static TLS data is put in the the object file like any other > data. The only difference is it has a different name of the > section/segment and an additional flag. Then of course the linker, > runtime and loader know about these sections and make any necessary > initializations when the application loads. > On OSX the object file format lacks a way to specify a TLS data section, and so the linker would need upgrading as well. And the compiler, since it needs to generate the object files.
Re: Is D right for me?
On 2010-10-13 20:18, Walter Bright wrote: Jacob Carlborg wrote: I don't know how you have implemented TLS on Mac OS X but it does support TLS via the Posix API pthreads. This is the only page from Apple's documentation I could find for now (I'm certain I've seen a better page) http://developer.apple.com/macosx/multithreadedprogramming.html . Yeah, I know about pthreads TLS, but that's wholly inadequate. According to these: http://lifecs.likai.org/2010/05/mac-os-x-thread-local-storage.html and http://lists.apple.com/archives/darwin-dev/2005/Sep/msg5.html the implementation of TLS in the Posix API on Mac OS X should be as fast as the EFL implementation. As the blog post mentions, there is an inline version of pthread_getspecific. I also have to add that I have no idea if the pthreads can be used to implement TLS in the compiler. With gcc on OSX, try this: __thread int x; It will fail. Furthermore, OSX has no documented way to allocate TLS static data in the object file. I spent considerable effort figuring out a way to do this and get around the numerous bugs in the OSX linker that tried to stop me. I just read a bit about how TLS is implemented on linux, just of curiosity what was the problem, the linker, runtime, loader or all? On linux the static TLS data is put in the the object file like any other data. The only difference is it has a different name of the section/segment and an additional flag. Then of course the linker, runtime and loader know about these sections and make any necessary initializations when the application loads. There's good reason for Windows, Linux, FreeBSD, etc. to support the declaration of TLS in the C source code. BTW, the dates on the second article postdate the D TLS implementation by years. Perhaps Apple has improved things. The third article just points out problems with the TLS. Anyhow, the source is here: http://www.dsource.org/projects/druntime/browser/trunk/src/core/thread.d and the function you're interested in is ___tls_get_addr. You're welcome to make improvements to it. That doesn't seem to be a lot of code to optimize, is Thread.getThis() slow? -- /Jacob Carlborg
Re: Is D right for me?
On Wednesday, October 13, 2010 10:37:43 klickverbot wrote: > On 10/13/10 6:56 PM, Jonathan M Davis wrote: > > I wouldn't think that it would be a problem, but I'm no expert, and we've > > had problems in the past because Tango devs thought that proposed Phobos > > code was too similar to Tango. So, as I understand it, unless we get > > specific permission from the Tango devs which wrote a particular module, > > we're trying to not have code in Phobos which is an API which is at all > > close to Tango's. That way we can avoid potential conflicts with the > > Tango devs. > > > > - Jonathan M Davis > > We had this over and over again, but I still think it should be noted > that the disaster around SOHO's code was not entirely made up by »the > Tango devs«, but originated from a single developer's phone call to > Walter Bright and was then exaggerated by large parts of the D > community, including both »sides« – your statement(s) makes it look a > bit as if it was all Tango at fault there… I never "the" Tango devs, just Tango devs, so I'm not claiming anything about all Tango devs. I'm not even really saying whether code was or wasn't copied, but there are Tango devs who are very sensitive to anything that looks like it might have been copied from Tango, and we want to avoid any misunderstandings or issues that could arise from any Tango dev thinking that we're swiping their code. So, we avoid doing anything that even looks similar, and many of us never look at the Tango API at all, let alone the code. Whether any copying of any kind has ever taken place is irrelevant at this point. What matters is that we don't want to cause issues between the Phobos and Tango folks, so we need to generally avoid anything that makes it look like we might be swiping anything from Tango. - Jonathan M Davis
Re: Is D right for me?
Jacob Carlborg wrote: I don't know how you have implemented TLS on Mac OS X but it does support TLS via the Posix API pthreads. This is the only page from Apple's documentation I could find for now (I'm certain I've seen a better page) http://developer.apple.com/macosx/multithreadedprogramming.html . Yeah, I know about pthreads TLS, but that's wholly inadequate. According to these: http://lifecs.likai.org/2010/05/mac-os-x-thread-local-storage.html and http://lists.apple.com/archives/darwin-dev/2005/Sep/msg5.html the implementation of TLS in the Posix API on Mac OS X should be as fast as the EFL implementation. As the blog post mentions, there is an inline version of pthread_getspecific. I also have to add that I have no idea if the pthreads can be used to implement TLS in the compiler. With gcc on OSX, try this: __thread int x; It will fail. Furthermore, OSX has no documented way to allocate TLS static data in the object file. I spent considerable effort figuring out a way to do this and get around the numerous bugs in the OSX linker that tried to stop me. There's good reason for Windows, Linux, FreeBSD, etc. to support the declaration of TLS in the C source code. BTW, the dates on the second article postdate the D TLS implementation by years. Perhaps Apple has improved things. The third article just points out problems with the TLS. Anyhow, the source is here: http://www.dsource.org/projects/druntime/browser/trunk/src/core/thread.d and the function you're interested in is ___tls_get_addr. You're welcome to make improvements to it.
Re: Is D right for me?
Jacob Carlborg Wrote: > On 2010-10-13 07:17, Walter Bright wrote: > > Denis Koroskin wrote: > >> Either way, it needs some language support, because currently TLS > >> implemented on compiler level rather than library level. I proposed > >> this change in past, but no one responded. > > > > Using TLS needs operating system support, and there's special linker > > support for it and the compiler has to generate TLS references in > > certain ways in order for it to work. > > > > There is no such support in OSX for TLS, and it is done manually by the > > library. However, TLS access is 10 times slower than on Linux/Windows. > > > > Without doing TLS in the operating system standard way, you tend to get > > hosed if you link with a shared library/DLL that has TLS. > > I don't know how you have implemented TLS on Mac OS X but it does > support TLS via the Posix API pthreads. This is the only page from > Apple's documentation I could find for now (I'm certain I've seen a > better page) > http://developer.apple.com/macosx/multithreadedprogramming.html . Using the Posix API here is tricky because it isn't always documented where the memory resides, so enabling GC scanning of it can be tricky. Also, default initialization gets a bit weird, etc. What we really need is for OSX to support the __thread storage class. We're not alone though, so I think it's likely we'll see it implemented in a future release.
Re: Is D right for me?
Daniel Gibson Wrote: > Walter Bright schrieb: > > Jacob Carlborg wrote: > >> On 2010-10-13 07:29, Walter Bright wrote: > >>> Simen kjaeraas wrote: > Jonathan M Davis wrote: > > So, whatever we put in Phobos, we do it > > without looking at Tango. > > You know, we might consider asking them for permission. That way, there > should be no problems. > >>> > >>> I have, on many occasions. > >> > >> Druntime is basically the Tango runtime so apparently that worked out. > > > > The authors of some parts of Tango have graciously agreed to transfer > > their code into Phobos. This includes the work done by Sean (druntime) > > and Don (math). > > We should probably just ask the author if the stream code (Kris, according to > their API doc) :) Please excuse me if I don't hold my breath :-)
Re: Is D right for me?
Walter Bright schrieb: Jacob Carlborg wrote: On 2010-10-13 07:29, Walter Bright wrote: Simen kjaeraas wrote: Jonathan M Davis wrote: So, whatever we put in Phobos, we do it without looking at Tango. You know, we might consider asking them for permission. That way, there should be no problems. I have, on many occasions. Druntime is basically the Tango runtime so apparently that worked out. The authors of some parts of Tango have graciously agreed to transfer their code into Phobos. This includes the work done by Sean (druntime) and Don (math). We should probably just ask the author if the stream code (Kris, according to their API doc) :)
Re: Is D right for me?
Jacob Carlborg wrote: On 2010-10-13 07:29, Walter Bright wrote: Simen kjaeraas wrote: Jonathan M Davis wrote: So, whatever we put in Phobos, we do it without looking at Tango. You know, we might consider asking them for permission. That way, there should be no problems. I have, on many occasions. Druntime is basically the Tango runtime so apparently that worked out. The authors of some parts of Tango have graciously agreed to transfer their code into Phobos. This includes the work done by Sean (druntime) and Don (math).
Re: Is D right for me?
On 10/13/10 6:56 PM, Jonathan M Davis wrote: I wouldn't think that it would be a problem, but I'm no expert, and we've had problems in the past because Tango devs thought that proposed Phobos code was too similar to Tango. So, as I understand it, unless we get specific permission from the Tango devs which wrote a particular module, we're trying to not have code in Phobos which is an API which is at all close to Tango's. That way we can avoid potential conflicts with the Tango devs. - Jonathan M Davis We had this over and over again, but I still think it should be noted that the disaster around SOHO's code was not entirely made up by »the Tango devs«, but originated from a single developer's phone call to Walter Bright and was then exaggerated by large parts of the D community, including both »sides« – your statement(s) makes it look a bit as if it was all Tango at fault there…
Re: Is D right for me?
retard schrieb: Tue, 12 Oct 2010 10:35:03 -0700, Jonathan M Davis wrote: On Tuesday, October 12, 2010 04:08:13 Simen kjaeraas wrote: Jonathan M Davis wrote: Except that copying Tango is taboo. We want to avoid any possible accusation of copying Tango's code or design. There have been issues in the past where Tango devs thought that we might be doing that, and we just don't want to risk any sort of problems with the Tango folks. So, whatever we put in Phobos, we do it without looking at Tango. You know, we might consider asking them for permission. That way, there should be no problems. That can be done, to be sure, but we definitely can't just look at their code - or even API - and create something similar, and from what I recall, most cases of trying to get permission have a been a problem (primarily due to there being multiple authors, I think). If there's only one author for the stream code in Tango, that would be easier. Regardless, the point is that we can't just go and look at the Tango API and use it to give ourselves ideas on what to do with Phobos. I doubt the copyright law can protect API definitions. In that case projects like Wine (winehq.org) couldn't exist. What do you think? The problem is that for the windows API you don't see the implementation, so you can't have stolen the code. Tango's code however is available to anyone so it's a lot harder to prove that you only looked at their API documention and not at their code. And it's quite probable that your implementation looks similar to theirs - for standard stuff most programmers (that may have seen any code doing something similar) will produce similar code - how do you prove that you just did it the way that occurred natural to you and didn't copy their code? So to be safe you have two possibilities: 1. don't model you API after Tango's 2. clone their API, look at their code and make sure yours is ridiculously different Else it may turn out like the SHOO time code disaster...
Re: Is D right for me?
On Wednesday, October 13, 2010 09:49:19 retard wrote: > Tue, 12 Oct 2010 10:35:03 -0700, Jonathan M Davis wrote: > > On Tuesday, October 12, 2010 04:08:13 Simen kjaeraas wrote: > >> Jonathan M Davis wrote: > >> > Except that copying Tango is taboo. We want to avoid any possible > >> > accusation of > >> > copying Tango's code or design. There have been issues in the past > >> > where Tango > >> > devs thought that we might be doing that, and we just don't want to > >> > risk any > >> > sort of problems with the Tango folks. So, whatever we put in Phobos, > >> > we do it > >> > without looking at Tango. > >> > >> You know, we might consider asking them for permission. That way, there > >> should be no problems. > > > > That can be done, to be sure, but we definitely can't just look at their > > code - or even API - and create something similar, and from what I > > recall, most cases of trying to get permission have a been a problem > > (primarily due to there being multiple authors, I think). If there's > > only one author for the stream code in Tango, that would be easier. > > > > Regardless, the point is that we can't just go and look at the Tango API > > and use it to give ourselves ideas on what to do with Phobos. > > I doubt the copyright law can protect API definitions. In that case > projects like Wine (winehq.org) couldn't exist. What do you think? I wouldn't think that it would be a problem, but I'm no expert, and we've had problems in the past because Tango devs thought that proposed Phobos code was too similar to Tango. So, as I understand it, unless we get specific permission from the Tango devs which wrote a particular module, we're trying to not have code in Phobos which is an API which is at all close to Tango's. That way we can avoid potential conflicts with the Tango devs. - Jonathan M Davis
Re: Is D right for me?
Tue, 12 Oct 2010 10:35:03 -0700, Jonathan M Davis wrote: > On Tuesday, October 12, 2010 04:08:13 Simen kjaeraas wrote: >> Jonathan M Davis wrote: >> > Except that copying Tango is taboo. We want to avoid any possible >> > accusation of >> > copying Tango's code or design. There have been issues in the past >> > where Tango >> > devs thought that we might be doing that, and we just don't want to >> > risk any >> > sort of problems with the Tango folks. So, whatever we put in Phobos, >> > we do it >> > without looking at Tango. >> >> You know, we might consider asking them for permission. That way, there >> should be no problems. > > That can be done, to be sure, but we definitely can't just look at their > code - or even API - and create something similar, and from what I > recall, most cases of trying to get permission have a been a problem > (primarily due to there being multiple authors, I think). If there's > only one author for the stream code in Tango, that would be easier. > > Regardless, the point is that we can't just go and look at the Tango API > and use it to give ourselves ideas on what to do with Phobos. I doubt the copyright law can protect API definitions. In that case projects like Wine (winehq.org) couldn't exist. What do you think?
Re: Is D right for me?
On 2010-10-13 07:29, Walter Bright wrote: Simen kjaeraas wrote: Jonathan M Davis wrote: So, whatever we put in Phobos, we do it without looking at Tango. You know, we might consider asking them for permission. That way, there should be no problems. I have, on many occasions. Druntime is basically the Tango runtime so apparently that worked out. -- /Jacob Carlborg
Re: Is D right for me?
On 2010-10-13 07:17, Walter Bright wrote: Denis Koroskin wrote: Either way, it needs some language support, because currently TLS implemented on compiler level rather than library level. I proposed this change in past, but no one responded. Using TLS needs operating system support, and there's special linker support for it and the compiler has to generate TLS references in certain ways in order for it to work. There is no such support in OSX for TLS, and it is done manually by the library. However, TLS access is 10 times slower than on Linux/Windows. Without doing TLS in the operating system standard way, you tend to get hosed if you link with a shared library/DLL that has TLS. I don't know how you have implemented TLS on Mac OS X but it does support TLS via the Posix API pthreads. This is the only page from Apple's documentation I could find for now (I'm certain I've seen a better page) http://developer.apple.com/macosx/multithreadedprogramming.html . According to these: http://lifecs.likai.org/2010/05/mac-os-x-thread-local-storage.html and http://lists.apple.com/archives/darwin-dev/2005/Sep/msg5.html the implementation of TLS in the Posix API on Mac OS X should be as fast as the EFL implementation. As the blog post mentions, there is an inline version of pthread_getspecific. I also have to add that I have no idea if the pthreads can be used to implement TLS in the compiler. -- /Jacob Carlborg
Re: Is D right for me?
On Wed, 13 Oct 2010 09:17:58 +0400, Walter Bright wrote: Denis Koroskin wrote: Either way, it needs some language support, because currently TLS implemented on compiler level rather than library level. I proposed this change in past, but no one responded. Using TLS needs operating system support, and there's special linker support for it and the compiler has to generate TLS references in certain ways in order for it to work. There is no such support in OSX for TLS, and it is done manually by the library. However, TLS access is 10 times slower than on Linux/Windows. Without doing TLS in the operating system standard way, you tend to get hosed if you link with a shared library/DLL that has TLS. Aha. Thanks for pointing that out, it never occurred to me before. Means I need to investigate Fibers for D2 then (thats the proper way anyway albeit less portable).
Re: Is D right for me?
Simen kjaeraas wrote: Jonathan M Davis wrote: So, whatever we put in Phobos, we do it without looking at Tango. You know, we might consider asking them for permission. That way, there should be no problems. I have, on many occasions.
Re: Is D right for me?
Denis Koroskin wrote: Either way, it needs some language support, because currently TLS implemented on compiler level rather than library level. I proposed this change in past, but no one responded. Using TLS needs operating system support, and there's special linker support for it and the compiler has to generate TLS references in certain ways in order for it to work. There is no such support in OSX for TLS, and it is done manually by the library. However, TLS access is 10 times slower than on Linux/Windows. Without doing TLS in the operating system standard way, you tend to get hosed if you link with a shared library/DLL that has TLS.
Re: Is D right for me?
Denis Koroskin Wrote: > On Tue, 12 Oct 2010 02:32:55 +0400, Andrei Alexandrescu > wrote: > > For me, I/O should be scalable (and thus support async operations) so I > came up with my own implementation. > I've tried building it on top of std.concurrency, but it doesn't scale > either. So, once again, I had to implement my own message passing > mechanism. I can implement existing std.concurrency interface on top of my > own one without sacrificing anything, but not vice-versa). ... > Unlike std.concurrency, it is easy (and encouraged) to have as many > mailboxes as you need. Mailboxes can forward events to other mailboxes, > e.g. so that you can poll() only one mailbox (and not every single one of > them). Pretty cool. I'm not sure I would consider poll() scalable though. Or at least not to the levels where my concept of "scalable" applies. That aside, I think the correct approach is to have an IO API that stands by itself and then provide a few adaptors for integrating it with messaging in different ways. That will allow performance-minded folks to do their to-the-metal programming and convenience-minded folks to unify IO with the rest of their message-passing. This is one thing that I feel Erlang got wrong. The IO-messaging integration is too magic, and ends up being problematic (try handing control of a socket from one process to another, for example, without losing any in-flight messages in the process). In short, I think I agree with you than std.concurrency isn't exactly right for this. At least as the default interface at any rate.
Re: Is D right for me?
On Tuesday, October 12, 2010 04:08:13 Simen kjaeraas wrote: > Jonathan M Davis wrote: > > Except that copying Tango is taboo. We want to avoid any possible > > accusation of > > copying Tango's code or design. There have been issues in the past where > > Tango > > devs thought that we might be doing that, and we just don't want to risk > > any > > sort of problems with the Tango folks. So, whatever we put in Phobos, we > > do it > > without looking at Tango. > > You know, we might consider asking them for permission. That way, there > should be no problems. That can be done, to be sure, but we definitely can't just look at their code - or even API - and create something similar, and from what I recall, most cases of trying to get permission have a been a problem (primarily due to there being multiple authors, I think). If there's only one author for the stream code in Tango, that would be easier. Regardless, the point is that we can't just go and look at the Tango API and use it to give ourselves ideas on what to do with Phobos. - Jonathan M Davis
Re: Is D right for me?
On Tue, 12 Oct 2010 16:01:30 +0400, Fawzi Mohamed wrote: On 12-ott-10, at 13:04, Denis Koroskin wrote: On Tue, 12 Oct 2010 02:32:55 +0400, Andrei Alexandrescu wrote: On 10/11/2010 12:38 PM, Daniel Gibson wrote: But parts of phobos are deprecated or will be deprecated and there still is no alternative for them. That may prevent people from writing "real" projects in D2 (or D at all) - who wants to use classes that will be deprecated soon? Sure, that old stuff will not be removed and can still be used, but I personally feel a bit uncomfortable with using deprecated code. Agreed. Maybe this is a good time to sart making a requirements list for streams. What are the essential features/feature groups? Andrei For me, I/O should be scalable (and thus support async operations) so I came up with my own implementation. I've tried building it on top of std.concurrency, but it doesn't scale either. So, once again, I had to implement my own message passing mechanism. I can implement existing std.concurrency interface on top of my own one without sacrificing anything, but not vice-versa). I very much agree that IO should be scalable. In my opinion this is possible if one has a robust framework for smp parallelization. This is what I have been working on with blip http://dsource.org/blip . The API is fixed, and seem to work correctly in all the cases I tested. It has not been optimized so it still has obvious optimizations, but I wanted to have a bit more of code using it, before thinking about optimization (so that I will be able to catch wrong optimizations with a high probability). Indeed I have already a rather large amount of code using it, and had still cases where bugs were *very* rare and difficult to locate. Still I already used it for example to build a socket server that uses all available threads efficiently to implement rpc between processes. One important thing in my opinion is that idle work should not use resources: waiting for i/o, waiting for events uses basically no cpu. All this is with D 1.0, and tango (even if I did try to reduce and encapsulate the dependence on tango as much as possible). For example when using sockets one does not see the blocking by default (for a webserver one will likely want to add some timeout), and the processor transparently switches to fibers that have work to do. The programmer has to just think about tasks and things that can be executed in parallel, if possible, the optimal scheduling and mapping to threads is done automatically. Fawzi I'm using a thread pool at this moment, however I was thinking about implementing some kind of green threads recently. In D2, there is a local/shared separation, and OS threads should be able switch D local context, i.e. forward access to local variables through custom TLS class reference, and swap that reference to reuse same thread for many "green threads". Conceptually it is different from Fibers (i.e you must return instead of just call yield() at any time), but it is also easier to implement and pretty much portable to any platform. Either way, it needs some language support, because currently TLS implemented on compiler level rather than library level. I proposed this change in past, but no one responded.
Re: Is D right for me?
On 12-ott-10, at 13:04, Denis Koroskin wrote: On Tue, 12 Oct 2010 02:32:55 +0400, Andrei Alexandrescu > wrote: On 10/11/2010 12:38 PM, Daniel Gibson wrote: But parts of phobos are deprecated or will be deprecated and there still is no alternative for them. That may prevent people from writing "real" projects in D2 (or D at all) - who wants to use classes that will be deprecated soon? Sure, that old stuff will not be removed and can still be used, but I personally feel a bit uncomfortable with using deprecated code. Agreed. Maybe this is a good time to sart making a requirements list for streams. What are the essential features/feature groups? Andrei For me, I/O should be scalable (and thus support async operations) so I came up with my own implementation. I've tried building it on top of std.concurrency, but it doesn't scale either. So, once again, I had to implement my own message passing mechanism. I can implement existing std.concurrency interface on top of my own one without sacrificing anything, but not vice-versa). I very much agree that IO should be scalable. In my opinion this is possible if one has a robust framework for smp parallelization. This is what I have been working on with blip http://dsource.org/blip . The API is fixed, and seem to work correctly in all the cases I tested. It has not been optimized so it still has obvious optimizations, but I wanted to have a bit more of code using it, before thinking about optimization (so that I will be able to catch wrong optimizations with a high probability). Indeed I have already a rather large amount of code using it, and had still cases where bugs were *very* rare and difficult to locate. Still I already used it for example to build a socket server that uses all available threads efficiently to implement rpc between processes. One important thing in my opinion is that idle work should not use resources: waiting for i/o, waiting for events uses basically no cpu. All this is with D 1.0, and tango (even if I did try to reduce and encapsulate the dependence on tango as much as possible). For example when using sockets one does not see the blocking by default (for a webserver one will likely want to add some timeout), and the processor transparently switches to fibers that have work to do. The programmer has to just think about tasks and things that can be executed in parallel, if possible, the optimal scheduling and mapping to threads is done automatically. Fawzi
Re: Is D right for me?
Jonathan M Davis wrote: Except that copying Tango is taboo. We want to avoid any possible accusation of copying Tango's code or design. There have been issues in the past where Tango devs thought that we might be doing that, and we just don't want to risk any sort of problems with the Tango folks. So, whatever we put in Phobos, we do it without looking at Tango. You know, we might consider asking them for permission. That way, there should be no problems. -- Simen
Re: Is D right for me?
On Tue, 12 Oct 2010 02:32:55 +0400, Andrei Alexandrescu
wrote:
On 10/11/2010 12:38 PM, Daniel Gibson wrote:
But parts of phobos are deprecated or will be deprecated and there still
is no alternative for them.
That may prevent people from writing "real" projects in D2 (or D at all)
- who wants to use classes that will be deprecated soon?
Sure, that old stuff will not be removed and can still be used, but I
personally feel a bit uncomfortable with using deprecated code.
Agreed. Maybe this is a good time to sart making a requirements list for
streams. What are the essential features/feature groups?
Andrei
For me, I/O should be scalable (and thus support async operations) so I
came up with my own implementation.
I've tried building it on top of std.concurrency, but it doesn't scale
either. So, once again, I had to implement my own message passing
mechanism. I can implement existing std.concurrency interface on top of my
own one without sacrificing anything, but not vice-versa).
Classes implemented so far: FileStream (file i/o), MemoryStream (e.g.
async memcpy) and SocketStream.
None of the streams support range interface explicitly (by design).
Instead, range interface can be achieved by StreamReader (InputStream) and
StreamWriter (OutputStream) adaptors.
Here it is in case you want to take a look and borrow ideas:
Stream: http://bitbucket.org/korDen/io/src/tip/io/stream.d
Mailbox: http://bitbucket.org/korDen/io/src/tip/io/mailbox.d
AsyncRequest: http://bitbucket.org/korDen/io/src/tip/io/async.d
Unlike std.concurrency, it is easy (and encouraged) to have as many
mailboxes as you need. Mailboxes can forward events to other mailboxes,
e.g. so that you can poll() only one mailbox (and not every single one of
them). And the main difference from std.concurrency is that it allows
event processing in a different thread context. For example, you can
process network message as soon as it arrives (which is done in a
background thread), parse it and then dispatch to main thread. This is how
my HttpRequest (which uses SocketStream) works.
Here is an example:
import io.http;
import io.mailbox;
import std.stdio;
import std.file;
void main()
{
auto host = "нигма.рф"; // supports international domain names, too
auto connection = new HttpConnection(host);
version (Wait) {
auto request = connection.execute(new HttpRequest(host, "/"));
request.wait(); // blocks until completed
std.file.write("out.html", request.response.contents);
} else {
// use thread-unique mailbox for event handing, similar to
std.concurrency.getTid()
connection.execute(new HttpRequest(host, "/"), mailbox);
bool done = false;
void onComplete(HttpResponseRequest request)
{
std.file.write("out.html", request.response.contents);
done = true;
}
mailbox.registerHandler!(HttpResponseRequest)(&onComplete);
version (Loop) {
while (!done) {
mailbox.poll(); // doesn't block
// do something useful (e.g. show progress bar) while not done
}
} else {
mailbox.poll(long.max);
assert(done);
}
}
connection.close();
}
Re: Is D right for me?
On Tuesday 12 October 2010 02:45:33 pipe dream wrote: > Andrei Alexandrescu Wrote: > > On 10/11/2010 12:38 PM, Daniel Gibson wrote: > > > But parts of phobos are deprecated or will be deprecated and there > > > still is no alternative for them. > > > That may prevent people from writing "real" projects in D2 (or D at > > > all) - who wants to use classes that will be deprecated soon? > > > Sure, that old stuff will not be removed and can still be used, but I > > > personally feel a bit uncomfortable with using deprecated code. > > > > Agreed. Maybe this is a good time to sart making a requirements list for > > streams. What are the essential features/feature groups? > > You could take a look at Tango's I/O by Kris Bell. It seems to have an > efficient and clean design. Except that copying Tango is taboo. We want to avoid any possible accusation of copying Tango's code or design. There have been issues in the past where Tango devs thought that we might be doing that, and we just don't want to risk any sort of problems with the Tango folks. So, whatever we put in Phobos, we do it without looking at Tango. - Jonathan M Davis
Re: Is D right for me?
Andrei Alexandrescu Wrote: > On 10/11/2010 12:38 PM, Daniel Gibson wrote: > > But parts of phobos are deprecated or will be deprecated and there still > > is no alternative for them. > > That may prevent people from writing "real" projects in D2 (or D at all) > > - who wants to use classes that will be deprecated soon? > > Sure, that old stuff will not be removed and can still be used, but I > > personally feel a bit uncomfortable with using deprecated code. > > Agreed. Maybe this is a good time to sart making a requirements list for > streams. What are the essential features/feature groups? You could take a look at Tango's I/O by Kris Bell. It seems to have an efficient and clean design.
Re: Is D right for me?
Andrei Alexandrescu schrieb: On 10/11/2010 12:38 PM, Daniel Gibson wrote: But parts of phobos are deprecated or will be deprecated and there still is no alternative for them. That may prevent people from writing "real" projects in D2 (or D at all) - who wants to use classes that will be deprecated soon? Sure, that old stuff will not be removed and can still be used, but I personally feel a bit uncomfortable with using deprecated code. Agreed. Maybe this is a good time to sart making a requirements list for streams. What are the essential features/feature groups? Andrei Maybe something like the following (I hope it's not too extensive): * Input- Output- and InputAndOutput- Streams - having InputStream and OutputStream as an interface like in the old design may be a good idea - implementing the standard operations that are mostly independent from the data source/sink like read/write for basic types, strings, ... in mixin templates is probably elegant to create streams that are both Input and Output (one mixin that implements most of InputStream and one that implements most of OutputStream) * Two kinds of streams: 1. basic streams: reading/writing from/to: * network (socket) * files * just memory (currently MemoryStream) * Arrays/Ranges? * ... 2. streams wrapping other streams: * for buffering - buffer input/output/both - with the possibility to peek? * to modify data when it's read/written (e.g. change endianess - important for networking!) * custom streams.. e.g. could parse/create CSV (comma seperated values) data or similar * Also there are different types of streams: seekable, resettable (a network stream is neither), ... * functionality/methods needed/desirable: - low level access * void read(void *buf, size_t len) // read *exactly* len bytes into buf * void write(void *buf, size_t len) // write *exactly* len bytes from buf to stream - convenient methods to read/write basic types in binary (!) from/to stream * read() (like int readInt()) or T read(T)() (like int read!int()) - with enforcing T is somehow basic (certainly no Object or pointer) - could use read(void *buf, size_t len) like in old implementation * void write( val ) or void write(T)( T val ) - again T should be basic type - could use write(void *buf, size_t len) like in old implementation - convenient methods to read/write arrays of T (T should again be a basic type) * T[] readArray(T)( size_t len) // return array of T's containing len T's - probably both alternatives make sense - the first one to write into an existing array (-slice), the second one for convenience if you want a new array anyway * void read(T)( T[] array ) // read array.length T's into array - maybe name this readArray(T)(..) as well for consistency? * void writeArray(T)( T[] array ) - special cases for strings? * void writeString(char[] str) // same for wchar and dchar - could write str into the stream with its length (as ushort xor uint xor ulong, _not_ size_t!) prepended * char[] readString() // same for wchar and dchar - read length of the string and then the string itself that will be returned - all that array/string/low level stuff but reading *at most* len (or array.length) values and returning the amount actually read ( readUpTo() ?) * useful e.g. for parsing http (you don't know how long the header is etc) * the same for write? don't see much use for that though.. - some way to determine whether the stream * is at its definite end (eof on file, socket closed or something like that) * currently empty (for input stream) - just doing a read() would block ? - Output streams need flush() - for Input streams skip(size_t noBytes) or even skip(T)(size_t noElems) may be handy to just throw away data we're not interested in without having it copied around - especially for non-seekable streams (network..) Cheers, - Daniel
Re: Is D right for me?
On 10/11/2010 12:38 PM, Daniel Gibson wrote: But parts of phobos are deprecated or will be deprecated and there still is no alternative for them. That may prevent people from writing "real" projects in D2 (or D at all) - who wants to use classes that will be deprecated soon? Sure, that old stuff will not be removed and can still be used, but I personally feel a bit uncomfortable with using deprecated code. Agreed. Maybe this is a good time to sart making a requirements list for streams. What are the essential features/feature groups? Andrei
Re: Is D right for me?
Walter: > The way varargs works for the C ABI is inefficient, clumsy, and frankly won't > work for what D needs. So I'm going to have two varargs - one for extern (C) > which is compatible with the C ABI and one for extern (D) which will push > things > on the stack as for 32 bits. Recently I have seen something related on Reddit: http://blog.nelhage.com/2010/10/amd64-and-va_arg/ http://www.reddit.com/r/programming/comments/dmm05/til_va_arg_on_amd64_is_way_more_complex_than_i/ > The only remaining nuisance for the D method is that some types have to be > aligned more strictly than the stack. That means TypeInfo will have to be > extended to provide an alignment size for the type. Is this somewhat related to this enhancement request "Guarantee alignment of stack-allocated variables on x86"? http://d.puremagic.com/issues/show_bug.cgi?id=2278 Bye, bearophile
Re: Is D right for me?
Iain Buclaw wrote: I'm actually rather curious how DMD plans on doing varargs in 64bit. Not least because I don't think their current method of "calculating" the address of the _argptr takes 64bit parameter passing into account. I'm working on it now. It's a bitch. The way varargs works for the C ABI is inefficient, clumsy, and frankly won't work for what D needs. So I'm going to have two varargs - one for extern (C) which is compatible with the C ABI and one for extern (D) which will push things on the stack as for 32 bits. The only remaining nuisance for the D method is that some types have to be aligned more strictly than the stack. That means TypeInfo will have to be extended to provide an alignment size for the type.
Re: Is D right for me?
Andrei Alexandrescu schrieb: On 10/10/10 20:59 CDT, Jonathan M Davis wrote: On Sunday 10 October 2010 17:27:55 Daniel Gibson wrote: bioinfornatics schrieb: LDC support 64 bit ;) as well as GDC. But both currently lack an up-to-date D2 compiler (but the GDC guys are at least working on it, seems like they're currently at 2.029 - which is great - about 3 months ago they were still at 2.018 and in between was the big 2.020 update that introduced druntime). I agree with walter that 64bit support in DMD is very important, especially for D2: I started a project a few months ago that might have benefited from D2s features (especially ranges), but I decided to use D1 because no 64bit compiler for D2 was in sight. I am btw a bit worried about "upgrading" code from D1 to D2 some day because of the heavy (still ongoing) changes, especially in phobos. I read that for example std.stream is going to be deprecated and replaced by either something with ranges or something like std.stdio (whoever was right about that, maybe even both?). This means that all my (file/network) IO-Code would have to be rewritten sooner or later.. But, currently lacking an alternative to std.stream/std.socketstream for networking, I would have had the same problems even if I had started the project with D2... A stream solution is in the works (it's discussed periodically on the Phobos list), but they haven't sorted out quite what they want to do with it yet. The Phobos API in general is in flux, though pieces of it are likely to stay more or less unchanged from what they currently are. But there's far from any kind of guarantee that much of anything from the D1 Phobos is going to survive in the D2 Phobos. They're looking to make Phobos as good as they can, and they aren't yet worried about keeping its API stable (though they don't make changes unless they think that it's actually benificial, so things don't change willy-nilly). I'm sure that the time will come, however, when Phobos' API will stabilize, and projects will be able to rely on it staying the same. I think that the reality of the matter is that porting D1 code to D2 code is going to be just like, if not exactly like, porting code from one library to another rather than an upgrade like you'd get between Qt3 and Qt4 (which had plenty of changes). I'm sure that the split between D1 and D2 is going to cause a lot of problems for people looking to port code from one to the other, but it will be better for newly written code, so it's a definite tradeoff. I wouldn't look forward to porting a project from D1 to D2 though. I think it's a bit hasty to speak on behalf of all of Phobos' participants. Phobos 2 is indeed different from Phobos 1 but backward-incompatible changes to Phobos 2 are increasingly rare. Andrei But parts of phobos are deprecated or will be deprecated and there still is no alternative for them. That may prevent people from writing "real" projects in D2 (or D at all) - who wants to use classes that will be deprecated soon? Sure, that old stuff will not be removed and can still be used, but I personally feel a bit uncomfortable with using deprecated code. Cheers, - Daniel
Re: Is D right for me?
On 2010-10-11 06:54, Jonathan M Davis wrote: On Sunday 10 October 2010 21:26:28 Andrei Alexandrescu wrote: I think it's a bit hasty to speak on behalf of all of Phobos' participants. Phobos 2 is indeed different from Phobos 1 but backward-incompatible changes to Phobos 2 are increasingly rare. Sorry if I overstepped my bounds on that. It's just that from what I've seen, the Phobos devs have been quite willing to make backwards incompatible changes if they thought that they were an improvement, though they aren't done all that frequently. Backwards compatability is considered, but improvements to the API seem to override it. Regardless, the result is that if you wrote your code for dmd 2.040 or something similar and ended up trying to update it to 2.050, you'd likely have a number of changes to make, though porting from Phobos 1 would be far worse. If Phobos were completely stable or at least never made backwards-compatability breaking changes, that wouldn't be the case. I fully expect that as Phobos matures, such breaking changes will become quite rare if not outright nonexistent, but they do still happen. Actually deprecating and replacing the modules that are intended to be deprecated and replace will help a lot with that, but that obviously takes time. - Jonathan M Davis I think it's time to separate the compiler, the language and phobos in the releases. One idea is the use three numbers to indicate a release of phobos, major, minor and build, like this: 2.4.3. Increment the build number when a implementation detail is changed the doesn't change the API. Increment the minor number when a backwards compatible API change is made and increment the major number when a API change is made that break backwards compatibility. -- /Jacob Carlborg
Re: Is D right for me?
== Quote from Daniel Gibson (metalcae...@gmail.com)'s article > bioinfornatics schrieb: > > LDC support 64 bit ;) > as well as GDC. > But both currently lack an up-to-date D2 compiler (but the GDC guys are > at least working on it, seems like they're currently at 2.029 - which is > great - about 3 months ago they were still at 2.018 and in between was > the big 2.020 update that introduced druntime). Merging frontend is one thing, implementing the new features the frontend offers is another (though I think I've so far covered everything there ;). I'm actually rather curious how DMD plans on doing varargs in 64bit. Not least because I don't think their current method of "calculating" the address of the _argptr takes 64bit parameter passing into account.
Re: Is D right for me?
On Sun, 10 Oct 2010 00:46:47 -0700, Jonathan M Davis wrote: working on the project without getting too frustrated over it. QtD is a huge service to the D community. It is. Qt bindings were the first thing I looked for when I started with the language, even with my current project not using any GUI.
Re: Is D right for me?
On Sunday 10 October 2010 21:26:28 Andrei Alexandrescu wrote: > > A stream solution is in the works (it's discussed periodically on the > > Phobos list), but they haven't sorted out quite what they want to do > > with it yet. The Phobos API in general is in flux, though pieces of it > > are likely to stay more or less unchanged from what they currently are. > > But there's far from any kind of guarantee that much of anything from > > the D1 Phobos is going to survive in the D2 Phobos. They're looking to > > make Phobos as good as they can, and they aren't yet worried about > > keeping its API stable (though they don't make changes unless they think > > that it's actually benificial, so things don't change willy-nilly). I'm > > sure that the time will come, however, when Phobos' API will stabilize, > > and projects will be able to rely on it staying the same. > > > > I think that the reality of the matter is that porting D1 code to D2 code > > is going to be just like, if not exactly like, porting code from one > > library to another rather than an upgrade like you'd get between Qt3 and > > Qt4 (which had plenty of changes). I'm sure that the split between D1 > > and D2 is going to cause a lot of problems for people looking to port > > code from one to the other, but it will be better for newly written > > code, so it's a definite tradeoff. I wouldn't look forward to porting a > > project from D1 to D2 though. > > I think it's a bit hasty to speak on behalf of all of Phobos' > participants. Phobos 2 is indeed different from Phobos 1 but > backward-incompatible changes to Phobos 2 are increasingly rare. Sorry if I overstepped my bounds on that. It's just that from what I've seen, the Phobos devs have been quite willing to make backwards incompatible changes if they thought that they were an improvement, though they aren't done all that frequently. Backwards compatability is considered, but improvements to the API seem to override it. Regardless, the result is that if you wrote your code for dmd 2.040 or something similar and ended up trying to update it to 2.050, you'd likely have a number of changes to make, though porting from Phobos 1 would be far worse. If Phobos were completely stable or at least never made backwards-compatability breaking changes, that wouldn't be the case. I fully expect that as Phobos matures, such breaking changes will become quite rare if not outright nonexistent, but they do still happen. Actually deprecating and replacing the modules that are intended to be deprecated and replace will help a lot with that, but that obviously takes time. - Jonathan M Davis
Re: Is D right for me?
On 10/10/10 20:59 CDT, Jonathan M Davis wrote: On Sunday 10 October 2010 17:27:55 Daniel Gibson wrote: bioinfornatics schrieb: LDC support 64 bit ;) as well as GDC. But both currently lack an up-to-date D2 compiler (but the GDC guys are at least working on it, seems like they're currently at 2.029 - which is great - about 3 months ago they were still at 2.018 and in between was the big 2.020 update that introduced druntime). I agree with walter that 64bit support in DMD is very important, especially for D2: I started a project a few months ago that might have benefited from D2s features (especially ranges), but I decided to use D1 because no 64bit compiler for D2 was in sight. I am btw a bit worried about "upgrading" code from D1 to D2 some day because of the heavy (still ongoing) changes, especially in phobos. I read that for example std.stream is going to be deprecated and replaced by either something with ranges or something like std.stdio (whoever was right about that, maybe even both?). This means that all my (file/network) IO-Code would have to be rewritten sooner or later.. But, currently lacking an alternative to std.stream/std.socketstream for networking, I would have had the same problems even if I had started the project with D2... A stream solution is in the works (it's discussed periodically on the Phobos list), but they haven't sorted out quite what they want to do with it yet. The Phobos API in general is in flux, though pieces of it are likely to stay more or less unchanged from what they currently are. But there's far from any kind of guarantee that much of anything from the D1 Phobos is going to survive in the D2 Phobos. They're looking to make Phobos as good as they can, and they aren't yet worried about keeping its API stable (though they don't make changes unless they think that it's actually benificial, so things don't change willy-nilly). I'm sure that the time will come, however, when Phobos' API will stabilize, and projects will be able to rely on it staying the same. I think that the reality of the matter is that porting D1 code to D2 code is going to be just like, if not exactly like, porting code from one library to another rather than an upgrade like you'd get between Qt3 and Qt4 (which had plenty of changes). I'm sure that the split between D1 and D2 is going to cause a lot of problems for people looking to port code from one to the other, but it will be better for newly written code, so it's a definite tradeoff. I wouldn't look forward to porting a project from D1 to D2 though. I think it's a bit hasty to speak on behalf of all of Phobos' participants. Phobos 2 is indeed different from Phobos 1 but backward-incompatible changes to Phobos 2 are increasingly rare. Andrei
Re: Is D right for me?
On Sunday 10 October 2010 17:27:55 Daniel Gibson wrote: > bioinfornatics schrieb: > > LDC support 64 bit ;) > > as well as GDC. > > But both currently lack an up-to-date D2 compiler (but the GDC guys are > at least working on it, seems like they're currently at 2.029 - which is > great - about 3 months ago they were still at 2.018 and in between was > the big 2.020 update that introduced druntime). > > I agree with walter that 64bit support in DMD is very important, > especially for D2: I started a project a few months ago that might have > benefited from D2s features (especially ranges), but I decided to use D1 > because no 64bit compiler for D2 was in sight. > > I am btw a bit worried about "upgrading" code from D1 to D2 some day > because of the heavy (still ongoing) changes, especially in phobos. > I read that for example std.stream is going to be deprecated and > replaced by either something with ranges or something like std.stdio > (whoever was right about that, maybe even both?). This means that all my > (file/network) IO-Code would have to be rewritten sooner or later.. > But, currently lacking an alternative to std.stream/std.socketstream for > networking, I would have had the same problems even if I had started the > project with D2... A stream solution is in the works (it's discussed periodically on the Phobos list), but they haven't sorted out quite what they want to do with it yet. The Phobos API in general is in flux, though pieces of it are likely to stay more or less unchanged from what they currently are. But there's far from any kind of guarantee that much of anything from the D1 Phobos is going to survive in the D2 Phobos. They're looking to make Phobos as good as they can, and they aren't yet worried about keeping its API stable (though they don't make changes unless they think that it's actually benificial, so things don't change willy-nilly). I'm sure that the time will come, however, when Phobos' API will stabilize, and projects will be able to rely on it staying the same. I think that the reality of the matter is that porting D1 code to D2 code is going to be just like, if not exactly like, porting code from one library to another rather than an upgrade like you'd get between Qt3 and Qt4 (which had plenty of changes). I'm sure that the split between D1 and D2 is going to cause a lot of problems for people looking to port code from one to the other, but it will be better for newly written code, so it's a definite tradeoff. I wouldn't look forward to porting a project from D1 to D2 though. - Jonathan M Davis
Re: Is D right for me?
bioinfornatics schrieb: LDC support 64 bit ;) as well as GDC. But both currently lack an up-to-date D2 compiler (but the GDC guys are at least working on it, seems like they're currently at 2.029 - which is great - about 3 months ago they were still at 2.018 and in between was the big 2.020 update that introduced druntime). I agree with walter that 64bit support in DMD is very important, especially for D2: I started a project a few months ago that might have benefited from D2s features (especially ranges), but I decided to use D1 because no 64bit compiler for D2 was in sight. I am btw a bit worried about "upgrading" code from D1 to D2 some day because of the heavy (still ongoing) changes, especially in phobos. I read that for example std.stream is going to be deprecated and replaced by either something with ranges or something like std.stdio (whoever was right about that, maybe even both?). This means that all my (file/network) IO-Code would have to be rewritten sooner or later.. But, currently lacking an alternative to std.stream/std.socketstream for networking, I would have had the same problems even if I had started the project with D2...
Re: Is D right for me?
LDC support 64 bit ;)
Re: Is D right for me?
Jonathan M Davis wrote: Of course, projects like QtD suffer from the same sort of problem as a compiler does in that it's not necessarily very useful until it's complete. Lots of people may be interested in using QtD, but if it's not at least close to done, it's not going to be useable enough to use in any major project, so people won't use, they won't report bugs on it, and the won't give any kind of feedback on the project. So, the poor QtD people then have to get a _lot_ of code done before they see any kind of positive feedback from the community, and when they _do_ start getting feedback, much of it is likely to be negative because feature X hasn't been implemented yet or feature Y is buggy. A lot of people have given up on D for similar reasons. Hopefully enough of the problems that they were having with dmd get fixed soon enough that they're able to actually continue working on the project without getting too frustrated over it. Things sure have changed. Back in the 80's, people were able to get real projects done with absolutely *terrible* compilers. Compilers have steadily gotten better, and so have expectations.
Re: Is D right for me?
Gour D. wrote: (64bit dmd, do you hear me?) Don't I know it. 64 bit support is absolutely essential for D's future.
Re: Is D right for me?
On Sun, 10 Oct 2010 00:46:47 -0700 >> "Jonathan" == Jonathan M Davis wrote: Jonathan> Yes, a lack of positive feedback can be frustrating even if Jonathan> you have the best code ever. And as much as the developers of Jonathan> QtD likely want to use it for their own stuff, it's likely Jonathan> not worth doing it just for themselves. It's just too much Jonathan> work. Well, I tried to do my little 'homework'...wrote to the QtD devs explaining them that their project is essential to adopting D for our project. Moreover, informed them that only for the sake of trying QtD I've created 32bit chroot on my machine(64bit dmd, do you hear me?) and got some help on #qtd in order to build "hello world" (instructions at http://www.dsource.org/projects/qtd/wiki/BuildLinux are now up-to-date). Lastly, I told devs that despite of current status of QtD, we have decided to 'gamble' and will use D/QtD for our project. The next step is to order Andrei's book, start learning the language, experiment with non-GUI stuff and try to help (in any way) to push QtD further. Jonathan> QtD is a huge service to the D community. Indeed! Coming from Haskell community where all the GUI libs (bindings) are in hands of just few devs, I sincerely hope that users of D will recognize importance of QtD for the success of language itself and help the project to become complete and fully usable asap. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
On Saturday 09 October 2010 12:44:37 Walter Bright wrote: > Gour D. wrote: > > Walter> Few things work better than customers letting a company know > > Walter> they are interested in such-and-such a product. > > Even a non-paying customer in the open-source world? > > At least it shows interest. No emails tells the open source developer > "nobody cares, so I'll just abandon it". Yes, a lack of positive feedback can be frustrating even if you have the best code ever. And as much as the developers of QtD likely want to use it for their own stuff, it's likely not worth doing it just for themselves. It's just too much work. Of course, projects like QtD suffer from the same sort of problem as a compiler does in that it's not necessarily very useful until it's complete. Lots of people may be interested in using QtD, but if it's not at least close to done, it's not going to be useable enough to use in any major project, so people won't use, they won't report bugs on it, and the won't give any kind of feedback on the project. So, the poor QtD people then have to get a _lot_ of code done before they see any kind of positive feedback from the community, and when they _do_ start getting feedback, much of it is likely to be negative because feature X hasn't been implemented yet or feature Y is buggy. A lot of people have given up on D for similar reasons. Hopefully enough of the problems that they were having with dmd get fixed soon enough that they're able to actually continue working on the project without getting too frustrated over it. QtD is a huge service to the D community. - Jonathan M Davis
Re: [YES]Re: Is D right for me?
Gour D. wrote: On Tue, 05 Oct 2010 19:26:58 -0400 "Jesse" == Jesse Phillips wrote: Jesse> But I can not state that cross-platform GUI is available for D Jesse> at this time. Despite of that we've decided to take a risk and choose with D & (hopefully it will become ready) QtD. We're glad to hear that. Welcome aboard! -- Simen
Re: Is D right for me?
Gour D. wrote: Walter> Few things work better than customers letting a company know Walter> they are interested in such-and-such a product. Even a non-paying customer in the open-source world? At least it shows interest. No emails tells the open source developer "nobody cares, so I'll just abandon it". Well, I'm going to send email to two people considering them important for QtD, based on what I could deduce... Good!
[YES]Re: Is D right for me?
On Tue, 05 Oct 2010 19:26:58 -0400 >> "Jesse" == Jesse Phillips wrote: Jesse> But I can not state that cross-platform GUI is available for D Jesse> at this time. Despite of that we've decided to take a risk and choose with D & (hopefully it will become ready) QtD. Thanks to all who replied and see you in newer threads. ;) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
On Thu, 7 Oct 2010 15:36:36 + (UTC) >> "bioinfornatics" == wrote: bioinfornatics> For me i will use D1 while ldc do not support D2 or if bioinfornatics> GDC come a GCC project and support D2. Until this is bioinfornatics> not done a big community part do not go to D2. Hmm...based on that I saw, I consider that D2 features are much more compelling when comparing D with Haskell...Hopefully, in a few months some things may change in D2 arena... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
For me i will use D1 while ldc do not support D2 or if GDC come a GCC project and support D2. Until this is not done a big community part do not go to D2.
Re: Is D right for me?
On Fri, 08 Oct 2010 00:24:52 +1100 >> "Justin" == Justin Johansson wrote: Justin> I think that long are the days that a single individual (or Justin> corporation) can "own" a language. It will be an unwinnable Justin> battle so long as the governance of D is under the auspices of Justin> a single mortal. I agree that, based on my short research about D, I see several places with the label 'room for improvement' like (more) open development process, using of DVCS, planning releases, better organized web sites, up-to-date wiki, more docs etc. Still, I believe that things are improving or, at least, there are still people enthused with D. That's why I'm curious how to proceed my evaluation phase in order to be able to properly decide for our project? (Running 108 variations of "Hello world" is not adequate test, neither of the language, nor for the tools.) So, my question is whether is there some option to get more complete coverage of the language (D2) besides TDPL book which will require some time to arrive here in Croatia (I found that book is worthy purchase no matter what we decide about D eventually)? Justin> There is too much risk for investors of time let alone pecuniary Justin> investors under the current regime. I agree here...this is e.g. one of the reasons to cautious to invest my time in learning & using ConTeXt (http://www.pragma-ade.com/) seeing it practically as one-man-band mostly pushed by one developer (Hans Hagen), no matter how talented he is and I'll continue using LyX/LaTeX. btw, my question on SO (http://stackoverflow.com/questions/3863111/haskell-or-d-for-gui-desktop-application or http://is.gd/fPK36) got one nice response from Don Stewart who wrote: "Let's tease out some requirements here, and I'll try to make the Haskell case. Perhaps the D fans or others could try to do the same.", so it would be nice, at least for other users, that some more experienced D user writes The Case for D (no pun intended). Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
On 7/10/2010 1:35 AM, Andrei Alexandrescu wrote: On 10/6/10 7:24 CDT, Simen kjaeraas wrote: Jacob Carlborg wrote: Well that's the problem, fixing those bugs and you will encounter new bugs. So we should all just give up, then? Yes, there are bugs, and yes, fixing them will reveal new ones. But the only reasonable thing to do is to try and fix those bugs that cause the most headaches, and continue doing so. I agree that that looked like an unwinnable battle while D was also evolving rapidly. Now that the language is stabilizing I expect the rate and the absolute number of bugs will decrease. Andrei I think that long are the days that a single individual (or corporation) can "own" a language. It will be an unwinnable battle so long as the governance of D is under the auspices of a single mortal. There is too much risk for investors of time let alone pecuniary investors under the current regime. Justin
Re: Is D right for me?
Jacob Carlborg wrote: DWT would be better, in that case: http://wxd.sourceforge.net/#dwt Since SWT 3.4 (currently stable version is 3.6) there has been a Cocoa port available. DWT is a port of the Cocoa version. Yeah, that page is a bit outdated. But I'll try to fix. When it was first written, it was Phobos and Carbon :-) --anders
Re: Is D right for me?
On 2010-10-06 20:53, Gour D. wrote: On Wed, 06 Oct 2010 20:35:57 +0400 "Denis" == "Denis Koroskin" wrote: Denis> Did you try DWT2? http://hg.dsource.org/projects/dwt2 No, but 'doob' on #dwt (it seems this is Jacob Carlborg) replied my question: "hi, is dwt available for d2?" with "no, not currently", so I bet I saved some time trying it for myself. Sincerely, Gour Exactly, hopefully I can get DWT to work with D2. -- /Jacob Carlborg
Re: Is D right for me?
On 2010-10-06 20:50, Anders F Björklund wrote: DWT would be better, in that case: http://wxd.sourceforge.net/#dwt --anders Since SWT 3.4 (currently stable version is 3.6) there has been a Cocoa port available. DWT is a port of the Cocoa version. -- /Jacob Carlborg
Re: Is D right for me?
On 2010-10-06 14:24, Simen kjaeraas wrote: Jacob Carlborg wrote: Well that's the problem, fixing those bugs and you will encounter new bugs. So we should all just give up, then? Yes, there are bugs, and yes, fixing them will reveal new ones. But the only reasonable thing to do is to try and fix those bugs that cause the most headaches, and continue doing so. I just think it has been show several times that D2 is not ready to be used just yet. -- /Jacob Carlborg
Re: Is D right for me?
Gour D. wrote: Anders> http://wxwidgets.blogspot.com/2010/07/gsoc-2010-mid-term.html Anders> Anders> And http://wiki.wxwidgets.org/WxQt for the current state of the Anders> port. Thank you for those links. It is very nice to see wxQT getting a nice shape, but the problem is with wxD - it's D1 only and I'm sure that, considering we don't have D1 legacy, there is no reasonable to think about D1 (especially in comparison with Haskell's features). wxD should build with D2 and Tango, just that I don't feel like supporting them any more. It only does the 2.6 version API, too. That mostly means it was written for GDC (with Phobos) and wx 2.8; not that it couldn't be updated to D2 and wx3, if you wanted to ? http://wxd.sourceforge.net/#d2 http://wxd.sourceforge.net/#tango It's not a port (from C++), though. And that is a design decision. Also means all languages can share the system wxWidgets libraries. If you wanted to *port* it to D, you would need to also port all the system headers too (some of which are in C++ and Objective-C) DWT would be better, in that case: http://wxd.sourceforge.net/#dwt The idea was to have an open source compiler and GUI and IDE bundle. Cross-platform, so that it would work on Windows, Macintosh, Unix. I think if you are starting over with D2, that Qt is a better choice. It is LGPL now, and looks native enough. And it doesn't need porting. http://wxd.sourceforge.net/#screenshots http://wxd.sourceforge.net/#codeblocks --anders
Re: Is D right for me?
On Wed, 06 Oct 2010 20:35:57 +0400 >> "Denis" == "Denis Koroskin" wrote: Denis> Did you try DWT2? http://hg.dsource.org/projects/dwt2 No, but 'doob' on #dwt (it seems this is Jacob Carlborg) replied my question: "hi, is dwt available for d2?" with "no, not currently", so I bet I saved some time trying it for myself. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
On Wed, 06 Oct 2010 20:31:17 +0400, Gour D. wrote: On Wed, 06 Oct 2010 09:35:13 +0200 "Jacob" == Jacob Carlborg wrote: Jacob> Have you considered DWT? It's a port of the Eclipse project SWT, Jacob> a cross-platform GUI library. The windows and linux ports are Jacob> usable, although a little behind SWT. As for Mac OS X, the Cocoa Jacob> port is a work in progress, somethings are usable and somethings Jacob> are not. I got same suggestion on #d yesterday and went to see it today. Interesting, but, afaics, no port for D2 which rules it out. Sincerely, Gour Did you try DWT2? http://hg.dsource.org/projects/dwt2
Re: Is D right for me?
On Wed, 06 Oct 2010 09:35:13 +0200 >> "Jacob" == Jacob Carlborg wrote: Jacob> Have you considered DWT? It's a port of the Eclipse project SWT, Jacob> a cross-platform GUI library. The windows and linux ports are Jacob> usable, although a little behind SWT. As for Mac OS X, the Cocoa Jacob> port is a work in progress, somethings are usable and somethings Jacob> are not. I got same suggestion on #d yesterday and went to see it today. Interesting, but, afaics, no port for D2 which rules it out. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
On Wed, 06 Oct 2010 09:30:36 +0200 >> "Anders" == Anders F Björklund wrote: Anders> http://wxwidgets.blogspot.com/2010/07/gsoc-2010-mid-term.html Anders> Anders> And http://wiki.wxwidgets.org/WxQt for the current state of the Anders> port. Thank you for those links. It is very nice to see wxQT getting a nice shape, but the problem is with wxD - it's D1 only and I'm sure that, considering we don't have D1 legacy, there is no reasonable to think about D1 (especially in comparison with Haskell's features). Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
On 10/6/10 7:24 CDT, Simen kjaeraas wrote: Jacob Carlborg wrote: Well that's the problem, fixing those bugs and you will encounter new bugs. So we should all just give up, then? Yes, there are bugs, and yes, fixing them will reveal new ones. But the only reasonable thing to do is to try and fix those bugs that cause the most headaches, and continue doing so. I agree that that looked like an unwinnable battle while D was also evolving rapidly. Now that the language is stabilizing I expect the rate and the absolute number of bugs will decrease. Andrei
Re: Is D right for me?
Jacob Carlborg wrote: Well that's the problem, fixing those bugs and you will encounter new bugs. So we should all just give up, then? Yes, there are bugs, and yes, fixing them will reveal new ones. But the only reasonable thing to do is to try and fix those bugs that cause the most headaches, and continue doing so. -- Simen
Re: Is D right for me?
On 2010-10-06 11:43, Simen kjaeraas wrote: Jacob Carlborg wrote: Probably a compiler that is working better, one with fewer bugs. Of course. And knowing which bugs those are, one could perhaps fix them. Well that's the problem, fixing those bugs and you will encounter new bugs. BTW, I wonder why Andrei asked anyway, he already asked this in the thread "QtD is suspended" in the announce newsgroup and got an answer: http://www.digitalmars.com/d/archives/digitalmars/D/announce/QtD_is_suspended_19259.html#N19265 -- /Jacob Carlborg
Re: Is D right for me?
On Tue, 05 Oct 2010 16:24:02 -0400, Gour D. wrote: On Tue, 05 Oct 2010 23:59:07 +0400 "Denis" == "Denis Koroskin" <2kor...@gmail.com> wrote: Denis> ...increasingly more people are unsatisfied with D2 and talking Denis> about a fork so I wouldn't be surprised to see one sooner or Denis> later (!) Unsatisfied that D2 changed (too) much or with bugs and development in general? To me, it looks very early to fork D2... I think the blog mentions forking D1 and adding certain useful features from D2. Forking D1 might be the only way to add new features to it. I think many yearn for some of the useful, stable features of D2, but aren't willing to put up with the not-yet-cooked features of D2. You don't have a choice at the moment, if you want D2 features, you must use D2, and the only up-to-date implementation of it -- dmd. On top of that, phobos is a long way from being finished, but it is progressing rapidly, there are many good developers working on it (as opposed to DMD which has 3). I personally do not share that pessimistic view, and I don't think I'll ever go back to D1 anyways, since the D1 phobos library is pretty underpowered. D2/phobos2 will get there, perhaps in a year or so. -Steve
Re: Is D right for me?
Jacob Carlborg wrote: Probably a compiler that is working better, one with fewer bugs. Of course. And knowing which bugs those are, one could perhaps fix them. -- Simen
Re: Is D right for me?
On 2010-10-05 22:38, Gour D. wrote: As I wrote earlier, besides sqlite3 bindings and using existent C-lib which needs to be bound to D, we need to write lot of native libs for our app, but it all fails without proper GUI. Sincerely, Gour Have you considered DWT? It's a port of the Eclipse project SWT, a cross-platform GUI library. The windows and linux ports are usable, although a little behind SWT. As for Mac OS X, the Cocoa port is a work in progress, somethings are usable and somethings are not. http://dsource.org/projects/dwt -- /Jacob Carlborg
Re: Is D right for me?
Gour D. wrote:
Moreover, we were told by dev working on gtk port for Mac that wx is
more suitable if Mac OS is important for us.
Probably right, even though wxWidgets for Cocoa is still in alpha.
GTK+ "works" (especially X11), but it doesn't really look "native".
wxWidgets for Carbon ("wxMac") is stable, but it is 32-bit only...
You can find old wx bindings for D at http://wxd.sourceforge.net/
Since there is no wxQt, Qt emerged as clean winner here...
But see http://wxwidgets.blogspot.com/2010/07/gsoc-2010-mid-term.html
And http://wiki.wxwidgets.org/WxQt for the current state of the port.
--anders
Re: Is D right for me?
On 2010-10-05 18:29, Andrei Alexandrescu wrote: On 10/5/10 9:37 CDT, Gour D. wrote: On Tue, 05 Oct 2010 16:01:41 +0200 "Don" == Don wrote: Don> I would estimate the truck factor as between 2.0 and 2.5. Two Don> years ago, the truck factor was 1.0, but not any more. Nice, nice...Still SO people say: "Neither Haskell nor D is popular enough for it to be at all likely that you will ever attract a single other developer to your project..." :-) If developer attraction is a concern, you're likely better off with D. Programmers who have used at least one Algol-like language (C, C++, Java, C#) will have no problem feeling comfortable in D. With Haskell you'd need to stick with "the choir". If just QtD hadn't been suspended... I agree that's a bummer. I suggest you write the developers and ask what would revive their interest. The perspective of a solid client is bound to be noticeable. Andrei Probably a compiler that is working better, one with fewer bugs. -- /Jacob Carlborg
Re: Is D right for me?
On Tue, 05 Oct 2010 16:06:00 -0700 >> "Walter" == Walter Bright wrote: Walter> Few things work better than customers letting a company know Walter> they are interested in such-and-such a product. Even a non-paying customer in the open-source world? Well, I'm going to send email to two people considering them important for QtD, based on what I could deduce... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
On Tue, 05 Oct 2010 22:46:26 +0200 >> "Daniel" == Daniel Gibson wrote: Daniel> What about using gtk instead of qt? I was considering gtk on haskell-side as well, but considering we'd like to have 'lite' version of the application available on mobile platform (Meego), it seems that it's better to have (more) common codebase provided by Qt. Moreover, we were told by dev working on gtk port for Mac that wx is more suitable if Mac OS is important for us. Since there is no wxQt, Qt emerged as clean winner here... Well it's à la Gnus. You have never seen it or you are thinking something else? -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
> Jesse> But for a GUI library, you would probably need to choose one > Jesse> and progress it as you do the project. > > This is a big problem for a desktop GUI project making the whole > project very uncertain right from the beginning... What I meant was that there is something created and functioning (I really don't know how much) which may be just what you need. But I can not state that cross-platform GUI is available for D at this time.
Re: Is D right for me?
Gour D. wrote: Andrei> I agree that's a bummer. I suggest you write the developers and Andrei> ask what would revive their interest. The perspective of a Andrei> solid client is bound to be noticeable. You think that D beginner with a open-source project is "solid client"? Otoh, there is nothing to lose... Few things work better than customers letting a company know they are interested in such-and-such a product.
Re: Is D right for me?
Gour D. schrieb: On Tue, 05 Oct 2010 16:14:49 -0400 "Jesse" == Jesse Phillips wrote: Jesse> You will have to support the libraries you use or wait Jesse> patiently. I am not saying there isn't code to use or people Jesse> willing/working to support that code. I mean that we are a small Jesse> community and have had some ruff hills to clime. Right. I'm ready to help, according to my skills, the projects providing bindings as I'd do to e.g. help qthaskell project, but with Haskell one, at least, does not start from the scratch. Here, I'd choose D, it is not certain that QtD will be revived at any time in the future. What about using gtk instead of qt? GtkD is, according to their homepage ( http://www.dsource.org/projects/gtkd ) and http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries stable and usable. BTW: the quotation style of your email/ng-client is strange.
Re: Is D right for me?
On 10/5/10 14:59 CDT, Denis Koroskin wrote: http://h3.gd/devlog/?p=22 - increasingly more people are unsatisfied with D2 and talking about a fork so I wouldn't be surprised to see one sooner or later (!) I'm confused. Reading through the link reveals exactly two people mentioning that a fork would be good. That doesn't quite qualify for "increasingly more people" in normal conversation. Andrei
Re: Is D right for me?
On Tue, 05 Oct 2010 16:14:49 -0400 >> "Jesse" == Jesse Phillips wrote: Jesse> Every language you choose will have its issue, and your listed Jesse> requirements are basically set up so the answer is 'none.' Not Jesse> one language fulfills every requirement for various reasons. True. Jesse> It sounds to me like you want to use Haskel but due to the loss Jesse> in potential help you are looking at D. Well, I'm somewhat familiar with Haskell and have zero experience with D. Not even knowing which build system one use to develop. Jesse> You will have to support the libraries you use or wait Jesse> patiently. I am not saying there isn't code to use or people Jesse> willing/working to support that code. I mean that we are a small Jesse> community and have had some ruff hills to clime. Right. I'm ready to help, according to my skills, the projects providing bindings as I'd do to e.g. help qthaskell project, but with Haskell one, at least, does not start from the scratch. Here, I'd choose D, it is not certain that QtD will be revived at any time in the future. Jesse> Lots of libraries/tools were written for D1, lots of libraries Jesse> were written using Tango (D1 only). Even when effort was taken Jesse> to support D2, the result was a broken library on a future Jesse> compiler release (it was expected as it was clearly stated, no Jesse> longer the issue). Otoh, GHC is quite stable and 7.0 is just around the corner... Jesse> So even if something claims support for D2 it may require work Jesse> to bring it up to the latest language specs. But the community Jesse> is working, things are progressing. And I don't think D will be Jesse> dieing. But I already heard rumors about the fork of D2? Jesse>The more libraries D has, the more users will come and Jesse> use the language resulting in more libraries. Right now we are Jesse> missing some vital libraries that everyone wants, but no one Jesse> wants to make/maintain (usually do to time issues). I'm following Haskell community for quite some time and I know when there was no Hackage at all, iow I can understand what it means 'young' community. However, it looks that D1 --> D2 has brought different winds, altgough it will probably pay off later. Jesse> In relation to compilers[1] I would not worry about it. By the Jesse> time your project reaches a stage that must work an more Jesse> platforms, it is likely that LDC and GDC, and maybe even DMD Jesse> will be updated for D2 and a multitude of platforms. Correct. Having choice for compiler is great and makes one peaceful. Jesse> But for a GUI library, you would probably need to choose one Jesse> and progress it as you do the project. This is a big problem for a desktop GUI project making the whole project very uncertain right from the beginning... Jesse> I do not wish to discourage you from choosing D, but feel it is Jesse> always good to know what to expect. And really you could Jesse> probably start your project, test the components you wish to Jesse> use. It should be pretty obvious if you find something you Jesse> couldn't live with. As I wrote earlier, besides sqlite3 bindings and using existent C-lib which needs to be bound to D, we need to write lot of native libs for our app, but it all fails without proper GUI. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
On Tue, 05 Oct 2010 23:59:07 +0400 >> "Denis" == "Denis Koroskin" <2kor...@gmail.com> wrote: Denis> ...increasingly more people are unsatisfied with D2 and talking Denis> about a fork so I wouldn't be surprised to see one sooner or Denis> later (!) Unsatisfied that D2 changed (too) much or with bugs and development in general? To me, it looks very early to fork D2... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
Denis Koroskin: > http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=103453 Yes, among the things D2 is designed to support, a there's a lack of built-in (or user-defined) basic features to create GUIs. But the good thing is that (I think) all the useful features here are additive changes. Bye, bearophile
Re: Is D right for me?
Every language you choose will have its issue, and your listed requirements are basically set up so the answer is 'none.' Not one language fulfills every requirement for various reasons. It sounds to me like you want to use Haskel but due to the loss in potential help you are looking at D. You say there were a few people who didn't get on board because of Haskel, ask them if instead D was used would the join. If not go with Haskel, if yes than I wish to make on thing clear. You will have to support the libraries you use or wait patiently. I am not saying there isn't code to use or people willing/working to support that code. I mean that we are a small community and have had some ruff hills to clime. Lots of libraries/tools were written for D1, lots of libraries were written using Tango (D1 only). Even when effort was taken to support D2, the result was a broken library on a future compiler release (it was expected as it was clearly stated, no longer the issue). So even if something claims support for D2 it may require work to bring it up to the latest language specs. But the community is working, things are progressing. And I don't think D will be dieing. The more libraries D has, the more users will come and use the language resulting in more libraries. Right now we are missing some vital libraries that everyone wants, but no one wants to make/maintain (usually do to time issues). In relation to compilers[1] I would not worry about it. By the time your project reaches a stage that must work an more platforms, it is likely that LDC and GDC, and maybe even DMD will be updated for D2 and a multitude of platforms. But for a GUI library, you would probably need to choose one and progress it as you do the project. I do not wish to discourage you from choosing D, but feel it is always good to know what to expect. And really you could probably start your project, test the components you wish to use. It should be pretty obvious if you find something you couldn't live with. 1. http://www.wikiservice.at/d/wiki.cgi?D__Tutorial/StartingWithD/Compiler
Re: Is D right for me?
On Tue, 05 Oct 2010 20:29:03 +0400, Andrei Alexandrescu wrote: On 10/5/10 9:37 CDT, Gour D. wrote: On Tue, 05 Oct 2010 16:01:41 +0200 "Don" == Don wrote: Don> I would estimate the truck factor as between 2.0 and 2.5. Two Don> years ago, the truck factor was 1.0, but not any more. Nice, nice...Still SO people say: "Neither Haskell nor D is popular enough for it to be at all likely that you will ever attract a single other developer to your project..." :-) If developer attraction is a concern, you're likely better off with D. Programmers who have used at least one Algol-like language (C, C++, Java, C#) will have no problem feeling comfortable in D. With Haskell you'd need to stick with "the choir". If just QtD hadn't been suspended... I agree that's a bummer. I suggest you write the developers and ask what would revive their interest. The perspective of a solid client is bound to be noticeable. Andrei I've heard from one of the developers that one of the most frustrating parts was inability of having struct default ctors (http://d.puremagic.com/issues/show_bug.cgi?id=3852), and dtors that aren't called (http://d.puremagic.com/issues/show_bug.cgi?id=3516). I also know they also had *huge* issues with optlink (http://d.puremagic.com/issues/show_bug.cgi?id=2436 and many others), but those hopefully got fixed. I'll try to talk eldar into sharing his development experience and the issues they came across. Until then you may be interested in reading these posts: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=103453 http://h3.gd/devlog/?p=22 - increasingly more people are unsatisfied with D2 and talking about a fork so I wouldn't be surprised to see one sooner or later (!)
Re: Is D right for me?
On Tue, 05 Oct 2010 11:29:03 -0500 >> "Andrei" == Andrei Alexandrescu >> wrote: Andrei> If developer attraction is a concern, you're likely better off Andrei> with D. Programmers who have used at least one Algol-like Andrei> language (C, C++, Java, C#) will have no problem feeling Andrei> comfortable in D. With Haskell you'd need to stick with "the Andrei> choir". Yeah, I'm aware of it... btw, let me personally congatulate for a great talk at Google! Andrei> I agree that's a bummer. I suggest you write the developers and Andrei> ask what would revive their interest. The perspective of a Andrei> solid client is bound to be noticeable. You think that D beginner with a open-source project is "solid client"? Otoh, there is nothing to lose... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
On 10/5/10 9:37 CDT, Gour D. wrote: On Tue, 05 Oct 2010 16:01:41 +0200 "Don" == Don wrote: Don> I would estimate the truck factor as between 2.0 and 2.5. Two Don> years ago, the truck factor was 1.0, but not any more. Nice, nice...Still SO people say: "Neither Haskell nor D is popular enough for it to be at all likely that you will ever attract a single other developer to your project..." :-) If developer attraction is a concern, you're likely better off with D. Programmers who have used at least one Algol-like language (C, C++, Java, C#) will have no problem feeling comfortable in D. With Haskell you'd need to stick with "the choir". If just QtD hadn't been suspended... I agree that's a bummer. I suggest you write the developers and ask what would revive their interest. The perspective of a solid client is bound to be noticeable. Andrei
Re: Is D right for me?
On Tue, 05 Oct 2010 16:01:41 +0200 >> "Don" == Don wrote: Don> I would estimate the truck factor as between 2.0 and 2.5. Two Don> years ago, the truck factor was 1.0, but not any more. Nice, nice...Still SO people say: "Neither Haskell nor D is popular enough for it to be at all likely that you will ever attract a single other developer to your project..." :-) If just QtD hadn't been suspended... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
On Tue, 05 Oct 2010 16:00:48 +0200 >> "Daniel" == Daniel Gibson wrote: Daniel> > So, both gdc & ldc are open-source? Daniel> Daniel> Yes. Nice. It means that, in the future, we could target ARM as well (for MeeGo). Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
Gour D. schrieb: On Tue, 05 Oct 2010 15:39:30 +0200 "Daniel" == Daniel Gibson wrote: Daniel> try http://bitbucket.org/goshawk/gdc/wiki/Home :-) Ahh, this looks much better. Thanks. ;) Daniel> I don't think it's as serious, because afaik Walter is not the Daniel> only one developing the dmd compiler (and thus familiar with Daniel> it) and, more importantly, there are alternative D compilers Daniel> (gdc and ldc, with at least gdc being actively developed). So, both gdc & ldc are open-source? Yes. What about standard libs? They're open source, too (boost license for phobos, is said to be even more liberal than BSD license, there is an alternative standard lib for D1 - tango[1] - that uses a BSD license and the "Academic Free License v3.0"[2]). Also, there are already several people maintaining/developing Phobos (not just Walter and Andrei Alexandrescu). Cheers, - Daniel [1] http://www.dsource.org/projects/tango/ [2] http://www.dsource.org/projects/tango/wiki/LibraryLicense
Re: Is D right for me?
Daniel Gibson wrote: Gour D. schrieb: On Tue, 05 Oct 2010 12:52:22 +0200 "Simen" == "Simen kjaeraas" wrote: Simen> I believe GDC supports ARM. Hmm, baes on http://dgcc.sourceforge.net/ it looks it is not overly active? try http://bitbucket.org/goshawk/gdc/wiki/Home :-) Simen> The bus-factor of D is sadly close to 1. If Walter should choose Simen> to leave, we have a problem. On the other hand, I don't think a Simen> mere bus would keep him from continuing the project. Uhh...this is almost like a showstopper or, at least, very strong anti-adoption pattern. :-( I don't think it's as serious, because afaik Walter is not the only one developing the dmd compiler (and thus familiar with it) and, more importantly, there are alternative D compilers (gdc and ldc, with at least gdc being actively developed). So even if Walter, for whatever reason, stops developing D, there is - IMHO - a good chance that others will continue his efforts and keep D alive. Look at the changelog for the last three releases. During that time, Walter has worked almost exclusively on the backend for the 64-bit compiler. If there were no community involvement, there would have been almost no progress on the 32-bit compiler. Yet the rate of compiler bug fixing has not fallen. I would estimate the truck factor as between 2.0 and 2.5. Two years ago, the truck factor was 1.0, but not any more.
Re: Is D right for me?
LDC is free compiler last revision use dmdfe 1.063 and soon the ladt dmdfe ldc support 32, 64 and arm and works on linux, mac OS X and windows LDC is wrote in c++ using LLVM, all people who whant help this project are welcome. They are a D2 experimental branch (you can too come for help this part )
Re: Is D right for me?
On Tue, 05 Oct 2010 15:39:30 +0200 >> "Daniel" == Daniel Gibson wrote: Daniel> try http://bitbucket.org/goshawk/gdc/wiki/Home :-) Ahh, this looks much better. Thanks. ;) Daniel> I don't think it's as serious, because afaik Walter is not the Daniel> only one developing the dmd compiler (and thus familiar with Daniel> it) and, more importantly, there are alternative D compilers Daniel> (gdc and ldc, with at least gdc being actively developed). So, both gdc & ldc are open-source? What about standard libs? Daniel> So even if Walter, for whatever reason, stops developing D, Daniel> there is - IMHO - a good chance that others will continue his Daniel> efforts and keep D alive. This is not so disheartening. :-) btw, I've asked similar/same question on SO http://stackoverflow.com/questions/3863111/haskell-or-d-for-gui-desktop-application if you want to contribute (I'm not much advised for D, so far). ;) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
Daniel Gibson Wrote: > Gour D. schrieb: > > On Tue, 05 Oct 2010 12:52:22 +0200 > >>> "Simen" == "Simen kjaeraas" wrote: > > > > Simen> I believe GDC supports ARM. > > > > Hmm, baes on http://dgcc.sourceforge.net/ it looks it is not overly > > active? > > try http://bitbucket.org/goshawk/gdc/wiki/Home :-) > > > > > Simen> The bus-factor of D is sadly close to 1. If Walter should choose > > Simen> to leave, we have a problem. On the other hand, I don't think a > > Simen> mere bus would keep him from continuing the project. > > > > Uhh...this is almost like a showstopper or, at least, very strong > > anti-adoption pattern. :-( > > > > I don't think it's as serious, because afaik Walter is not the only one > developing the dmd compiler (and thus familiar with it) and, more > importantly, there are alternative D compilers (gdc and ldc, with at > least gdc being actively developed). > > So even if Walter, for whatever reason, stops developing D, there is - > IMHO - a good chance that others will continue his efforts and keep D alive. > > Cheers, > - Daniel I've also heard there is an unannounced compiler in the works.
Re: Is D right for me?
Gour D. schrieb: On Tue, 05 Oct 2010 12:52:22 +0200 "Simen" == "Simen kjaeraas" wrote: Simen> I believe GDC supports ARM. Hmm, baes on http://dgcc.sourceforge.net/ it looks it is not overly active? try http://bitbucket.org/goshawk/gdc/wiki/Home :-) Simen> The bus-factor of D is sadly close to 1. If Walter should choose Simen> to leave, we have a problem. On the other hand, I don't think a Simen> mere bus would keep him from continuing the project. Uhh...this is almost like a showstopper or, at least, very strong anti-adoption pattern. :-( I don't think it's as serious, because afaik Walter is not the only one developing the dmd compiler (and thus familiar with it) and, more importantly, there are alternative D compilers (gdc and ldc, with at least gdc being actively developed). So even if Walter, for whatever reason, stops developing D, there is - IMHO - a good chance that others will continue his efforts and keep D alive. Cheers, - Daniel
Re: Is D right for me?
On Tue, 05 Oct 2010 12:52:22 +0200 >> "Simen" == "Simen kjaeraas" wrote: Simen> This is a big problem for D at this point. The language is no Simen> longer evolving (much), and we're at a point in time where Simen> libraries and toolchain parts need to be written. That's nice to hear and it's solvable. Simen> It will. Latest news (2 days ago) say it's now getting as far as Simen> main(), which is good. Great! Simen> I believe GDC supports ARM. Hmm, baes on http://dgcc.sourceforge.net/ it looks it is not overly active? Simen> There's a list here: Simen> http://www.wikiservice.at/d/wiki.cgi?DatabaseBindings Simen> Simen> However, most of those are for D1, and a large percentage seem Simen> to be abandoned. :-( Simen> SQLite seems to be well supported, with 7 projects claiming Simen> support. Why so many? Similar to Haskell where one can find bunch of libs doing practically the same thing, but most of them half-baked. Simen> I'm sure you can. D also supports programming styles closer to Simen> those of FP, making such a transition easier (I hope :p) This is certainly bonus. Simen> > a) maintainable code Simen> Simen> This is likely a bit subjective, and much more dependent upon the Simen> programmers themselves than the language used. I agree. Otoh, afaict, D use modules/packages, so code can be nicely organized, as well as in Haskell. Simen> - Contract programming in the form of pre and post contracts for Simen>functions[1]. Simen> - Class invariants[2]. Simen> - Built in unit testing[3]. Simen> - Documentation comments[4]. Simen> Simen> Of course, other features of D may increase maintainability, but Simen> those are the ones most directly associated with it. Not bad.;) Simen> > b) decent performance Simen> Simen> D is generally as fast as C, though some abstractions of course Simen> cost more than others. This is, probably, more than we'd need, but definitely no fear as with e.g. Python & co. Simen> > c) higher-level programming and suitable for general Simen> > programming tasks Simen> Simen> My impression (not having used Haskell), D wins hands down on the Simen> latter, and is a bit weaker on the former. Still, I believe, D provides much more comfortable higher-order experience than C++. Simen> > d) good library support (database stuff, data structures, Qt Simen> > GUI...) Simen> Simen> Likely Haskell is better here (as noted above, D has some Simen> problems in this regard). Lack of GUI libs for D2 is serious concern atm. Simen> The bus-factor of D is sadly close to 1. If Walter should choose Simen> to leave, we have a problem. On the other hand, I don't think a Simen> mere bus would keep him from continuing the project. Uhh...this is almost like a showstopper or, at least, very strong anti-adoption pattern. :-( It is even worse than Haskell where GHC has bus-factor >=2 and there are other compilers like uhc, lhc, jhc...there is even Haskell committee working on Haskell' (prime) standard. Simen> Here I can't help. I don't know Haskell. Thanks a lot. It is helpful, although with a little discouraging end. :-( Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
Gour D. wrote: D, from the other side, is younger language, community is not so big, language is, afaict, evolving very rapidly and it's not easy to tell which compiler to use, which libs etc. This is a big problem for D at this point. The language is no longer evolving (much), and we're at a point in time where libraries and toolchain parts need to be written. Moreover, I'm a bit worried on the state of GUI libs available for D, especially about QtD. Moreover, 64-bit is not ready (yet), although I'm told it should come soon. It will. Latest news (2 days ago) say it's now getting as far as main(), which is good. What about ARM if we want to target MeeGo in the future? I believe GDC supports ARM. I also did not research what is the state of database support...Now we're thinking to use sqlite3 as back-end. There's a list here: http://www.wikiservice.at/d/wiki.cgi?DatabaseBindings However, most of those are for D1, and a large percentage seem to be abandoned. SQLite seems to be well supported, with 7 projects claiming support. I also have experience that some potential developers did not join our team since Haskell was to hard to grok for them (coming from C++), so D might be an easier path with less steep learning curve, but I also wonder about myself whether I could pick D quickly enough (I'll buy book, of course) after long exposure to Haskell and FP. I'm sure you can. D also supports programming styles closer to those of FP, making such a transition easier (I hope :p) So, can you offer some advice, what could be better choice between Haskell & D for our planned project with the following features: a) maintainable code This is likely a bit subjective, and much more dependent upon the programmers themselves than the language used. That said, D supports a variety of features that boost maintainability: - Contract programming in the form of pre and post contracts for functions[1]. - Class invariants[2]. - Built in unit testing[3]. - Documentation comments[4]. Of course, other features of D may increase maintainability, but those are the ones most directly associated with it. b) decent performance D is generally as fast as C, though some abstractions of course cost more than others. c) higher-level programming and suitable for general programming tasks My impression (not having used Haskell), D wins hands down on the latter, and is a bit weaker on the former. d) good library support (database stuff, data structures, Qt GUI...) Likely Haskell is better here (as noted above, D has some problems in this regard). e) vibrant community and active development so that there is some guarantee that the language won't fall in oblivion if some devs leave the project, iow. 'bus-factor > 2' ? The bus-factor of D is sadly close to 1. If Walter should choose to leave, we have a problem. On the other hand, I don't think a mere bus would keep him from continuing the project. (It would be nice if someone familiar with both languages can share...) Here I can't help. I don't know Haskell. In closing, [1]: http://digitalmars.com/d/2.0/dbc.html [2]: http://digitalmars.com/d/2.0/class.html#invariants [3]: http://digitalmars.com/d/2.0/unittest.html [4]: http://digitalmars.com/d/2.0/ddoc.html -- Simen
