digitalmars.D - too early for D2 and too late for D1
- Gour-Gadadhara Dasa (33/33) Apr 17 2011 Hello!
- Gary Whatmore (3/3) Apr 17 2011 Gour-Gadadhara Dasa Wrote:
- Daniel Gibson (2/7) Apr 17 2011 Do you have a split personality or why do you write "we"?
- Andrej Mitrovic (9/9) Apr 17 2011 Gour, please disregard the troll above.
- Gary Whatmore (2/13) Apr 17 2011 W-T-F, why are you defending *other* languages? In every young language ...
- Caligo (3/3) Apr 17 2011 D2 is ready. There are some compiler bugs that might cause problems,
- Gour-Gadadhara Dasa (12/14) Apr 17 2011 Well, http://d-programming-language.org/ page says: "D is a
- Andrej Mitrovic (7/7) Apr 17 2011 For what it's worth, the examples from Mark's book still compile with
- Gour-Gadadhara Dasa (11/18) Apr 17 2011 Mark has provided examples for Python 3.
- Andrej Mitrovic (6/8) Apr 17 2011 But you've opened this topic because D2 is not ready, and now you want
- Gour-Gadadhara Dasa (12/15) Apr 17 2011 Fortunately, Python comes with the big "batteries included" so that
- jasonw (5/9) Apr 17 2011 That's certainly true, if you think of the potential D2 provides. In 5 -...
- Adam D. Ruppe (6/8) Apr 17 2011 My clients and I would disagree :-)
- Walter Bright (2/6) Apr 17 2011 Hopefully in time for the D article contest!
- Andrei Alexandrescu (3/11) Apr 17 2011 Don't forget the iPad2 contest...
- Nick Sabalausky (11/19) Apr 17 2011 Yea. Java and C# might be more mature than D right now, but D is just su...
- Ary Manzana (3/11) Apr 17 2011 Please do so! :-)
- Caligo (16/25) Apr 17 2011 20 years D will be a serious contestant and mature implementations beat...
- jasonw (4/23) Apr 17 2011 I'd like to be more optimistic, but I'm comparing the development to pro...
- Jerry (7/13) May 03 2011 I would challenge this statement somewhat. I do high-performance
- Walter Bright (8/14) May 03 2011 My experience in tuning D code for speed is that if you write "C++" code...
- Adam D. Ruppe (32/37) May 03 2011 Anecdote: Friday, I was asked to justify my decision to use D to a
- Walter Bright (5/42) May 03 2011 This is an awesome case history of exactly what we are trying to achieve...
- Peter Alexander (18/21) May 04 2011 How do you manage to change a pass-by-value to pass-by-reference by
- Walter Bright (5/11) May 04 2011 alias Vec3!T* V;
- dsimcha (13/16) May 03 2011 +1000. IMHO one of D's biggest accomplishments is how far it pushes the...
- Russel Winder (40/46) May 04 2011 =20
- dsimcha (9/27) May 04 2011 True but somewhat irrelevant. The problem with this is that you're
- Paulo Pinto (57/63) May 04 2011 Not sure about the sometimes, but nowadays they can be very fast.
- Gour-Gadadhara Dasa (10/14) Apr 17 2011 In my case, I'm going to write desktop application and there is no
- Daniel Gibson (31/45) Apr 17 2011 Do you really think in "10 -- 20 years" somebody will care of your code
- Walter Bright (2/7) Apr 17 2011 On 16 bit DOS computers, you can't use C++ STL or even exception handlin...
- jasonw (2/10) Apr 17 2011 I'd like to hear your comments about the 32-bit D2 and minimal executabl...
- Walter Bright (2/7) Apr 17 2011 Are you talking about static linking, or using shared libraries?
- jasonw (2/10) Apr 17 2011 I mentioned static binaries, but I meant statically linked binaries. So ...
- Walter Bright (4/17) Apr 17 2011 Many D features, such as the GC, are simply going to require a significa...
- Jacob Carlborg (7/33) Apr 18 2011 This is quite a big advantage C and C++ have. The runtime will almost
- Andrej Mitrovic (34/34) Apr 17 2011 I'm not defending other languages, I'm recommending them. I'm also
- dsimcha (16/17) Apr 17 2011 While I'm not endorsing the rude tone of the rest of this post, this is
- Gour-Gadadhara Dasa (17/27) Apr 17 2011 :-)
- Walter Bright (4/5) Apr 17 2011 Gour-Gadadhara Dasa has done nothing to merit such inexcusable rudeness.
- Andrew Wiley (14/42) Apr 17 2011 Frankly, if your definition of "not ready" is that the compiler isn't
- Gour-Gadadhara Dasa (19/29) Apr 17 2011 First of all, there is no 64bit compiler for FreeBSD. I was
- Walter Bright (2/4) Apr 17 2011 I'd also like to know which bugzilla entry has that patch!
- Gour-Gadadhara Dasa (11/12) Apr 17 2011 See:=20
- Walter Bright (3/9) Apr 17 2011 I clicked around that for a while, but can't seem to find the patch file...
- Andrej Mitrovic (2/15) Apr 17 2011 http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.p...
- Daniel Gibson (2/20) Apr 17 2011 This should probably be mentioned at the bitbucket wiki.
- David Nadlinger (12/22) Apr 17 2011 Ah, sorry, this was a side effect of QtD currently being in limbo
- Nick Sabalausky (7/28) Apr 17 2011 I've had need for a feature like that, too. Luckily in my case, I only
- KennyTM~ (3/28) Apr 17 2011 The patch is now integrated into dmd :)
- Walter Bright (2/3) Apr 17 2011 Got it, tanks!
- Iain Buclaw (6/16) Apr 17 2011 Emphasis on the word 'might' O:)
- Gour-Gadadhara Dasa (11/15) Apr 17 2011 The guy on #D.gdc told me he was able to build dmd on 64bit FreeBSD,
- Ulrik Mikaelsson (24/33) Apr 17 2011 I just want to add one thing. I am, too, trying to develop "real" open
- Gour-Gadadhara Dasa (26/34) Apr 17 2011 I agree.=20
- Jonathan M Davis (24/64) Apr 17 2011 It's normal to have to deal with a new toolchain when dealing with a new...
Hello! My first post to this newsgroup was a little bit more than 6 months ago and today I've decided to leave D and use C(P)ython + Qt for our open-source project of writing multi-platform desktop application. The D community is very nice and supportive, Walter, Andrei & co. are working hard, but, imho, D is not ready (yet). Recently, after switching from Linux to (Free)PC-BSD I even lost ability to have working compiler on x86_64 (none of the compilers is available in ports). The crucial thing is that D's ecosystem is simply not ready for day-to-day GUI programming and there is no clear roadmap so that one can anticipate when to expect that something will be done. Let me say, that I really like what D has on its plate, but language needs libraries to be successful, otherwise it is only promise-land. I've become tired for programming language's ecosystem to become mature...waited too long with Haskell and arrived to D hoping it is more pragmatic for day-to-day usage, but the situation seems even worse...Yeah, I know...I arrived at the wrong time during D1 --> D2 transition... That's, why I believe that the mantra in the subject, which I coined in IRC the other day, holds true. I'm thankful to all the members of this group for every piece of advice and input I received, as well to Andrei (his book is on my shelf - I even put it in the hardcover), but I want to code my project *today*, have plenty of (GUI) choices, lot of docs, tools and clear roadmap where the certain projects are going. I hope I might re-evaluate D2 sometime in the future for some other project... Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
Gour-Gadadhara Dasa Wrote: One thing, go hang yourself. We don't like loser talk from people who only waste our time. Everyone agrees here D2 is the right tool for the job. Why did you come here to rant about D? - G.W.
Apr 17 2011
Am 17.04.2011 20:18, schrieb Gary Whatmore:Gour-Gadadhara Dasa Wrote: One thing, go hang yourself. We don't like loser talk from people who only waste our time. Everyone agrees here D2 is the right tool for the job. Why did you come here to rant about D? - G.W.Do you have a split personality or why do you write "we"?
Apr 17 2011
Gour, please disregard the troll above. If you're going with Python and Qt, I'd wholeheartedly recommend this book: http://www.qtrac.eu/pyqtbook.html Making GUIs with PyQT is dead simple. And Nokia already has that new LGPL(I think?)-licensed binding in place - http://www.pyside.org. So your decision might not be bad at all. What type of desktop app are you building? Does it need to be very-high performance? Python itself isn't too bad with Qt, I don't think it was slow in any way the last time I used it.
Apr 17 2011
Andrej Mitrovic Wrote:Gour, please disregard the troll above. If you're going with Python and Qt, I'd wholeheartedly recommend this book: http://www.qtrac.eu/pyqtbook.html Making GUIs with PyQT is dead simple. And Nokia already has that new LGPL(I think?)-licensed binding in place - http://www.pyside.org. So your decision might not be bad at all. What type of desktop app are you building? Does it need to be very-high performance? Python itself isn't too bad with Qt, I don't think it was slow in any way the last time I used it.W-T-F, why are you defending *other* languages? In every young language community the first users have to make sacrifices and build the ecosystem. That's how it goes. If we keep telling them Python is a better choice, nobody will implement the badly needed libraries.
Apr 17 2011
D2 is ready. There are some compiler bugs that might cause problems, but they will go away hopefully soon. And I don't think GUI programming is the first reason people come to D.
Apr 17 2011
On Sun, 17 Apr 2011 13:51:49 -0500 Caligo <iteronvexor gmail.com> wrote:And I don't think GUI programming is the first reason people come to D.Well, http://d-programming-language.org/ page says: "D is a multi-paradigm programming language that combines a principled approach with a focus on *practicality*." and in my case I've *practical* need to write GUI app. :-) Sincerely, Gour=20 --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
For what it's worth, the examples from Mark's book still compile with Python 2.7 and the latest PyQt bindings. And PyQt itself comes with examples that are stored in Python\lib\site-packages\pyqt4\examples\ . I don't think a lot has changed that breaks backward-compatibility since the book was published. I don't really know what benefits you would have from Python 3.x, I think 2.7 got some 3.x features backported to that version as well..
Apr 17 2011
On Sun, 17 Apr 2011 21:45:59 +0200 Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:For what it's worth, the examples from Mark's book still compile with Python 2.7 and the latest PyQt bindings. And PyQt itself comes with examples that are stored in Python\lib\site-packages\pyqt4\examples\ . I don't think a lot has changed that breaks backward-compatibility since the book was published.Mark has provided examples for Python 3.I don't really know what benefits you would have from Python 3.x, I think 2.7 got some 3.x features backported to that version as well..Well, I believe that 2.7 is, similar to D1, dead-end, while 3.x is the future, as D2. ;) Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
On 4/17/11, Gour-Gadadhara Dasa <gour atmarama.net> wrote:Well, I believe that 2.7 is, similar to D1, dead-end, while 3.x is the future, as D2. ;)But you've opened this topic because D2 is not ready, and now you want to switch to Python 3 which might not be ready yet as well? E.g. see: python3wos.appspot.com I know a year or two ago there was a severe lack of libraries for Py3. Maybe things are better now, but I haven't checked. It's your call. :)
Apr 17 2011
On Sun, 17 Apr 2011 22:44:20 +0200 Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:But you've opened this topic because D2 is not ready, and now you want to switch to Python 3 which might not be ready yet as well? E.g. see: python3wos.appspot.comFortunately, Python comes with the big "batteries included" so that besides pyQt & pytz, no need for anything else. Moreover, the majority of stuff from the above list is Plone, Zope & Django stuff which we do not care about. Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
Gour-Gadadhara Dasa Wrote:Well, http://d-programming-language.org/ page says: "D is a multi- paradigm programming language that combines a principled approach with a focus on *practicality*." and in my case I've *practical* need to write GUI app.That's certainly true, if you think of the potential D2 provides. In 5 -- 20 years D will be a serious contestant and mature implementations beat C++ and traditional languages in many domains. Currently DMD produces much slower executables especially for high performance computing so you would be a total idiot to use D if the project time frame is less than 2 years. If you want to build some fortune 500 website from scratch, D doesn't deliver of millions worth funding backing them. If you build a desktop application, D isn't the best choice, but you can still argue to your boss to use it instead because of your personal "productivity" issues. There's no other logical reason to use D instead of C++/Qt or some other mature GUI toolkit. Bloated executables aren't suitable for embedded platforms either, but in 10 -- 20 years we will have a D compiler that targets platforms with less than 4 MB of RAM+ROM. I find it unlike that we have a reliable D compiler for very small 32-bit embedded devices in 5 years.
Apr 17 2011
jasonw wrote:If you want to build some fortune 500 website from scratch, D doesn't deliver the functionality you need right now.My clients and I would disagree :-) I've been using D, almost exclusively, to write business websites for quite a while now. There's a lot of big advantages there over more traditional web languages. I'm hoping to write up an article detailing some of it in the near future.
Apr 17 2011
On 4/17/2011 1:00 PM, Adam D. Ruppe wrote:I've been using D, almost exclusively, to write business websites for quite a while now. There's a lot of big advantages there over more traditional web languages. I'm hoping to write up an article detailing some of it in the near future.Hopefully in time for the D article contest!
Apr 17 2011
On 04/17/2011 03:00 PM, Adam D. Ruppe wrote:jasonw wrote:Don't forget the iPad2 contest... AndreiIf you want to build some fortune 500 website from scratch, D doesn't deliver the functionality you need right now.My clients and I would disagree :-) I've been using D, almost exclusively, to write business websites for quite a while now. There's a lot of big advantages there over more traditional web languages. I'm hoping to write up an article detailing some of it in the near future.
Apr 17 2011
"Adam D. Ruppe" <destructionator gmail.com> wrote in message news:iofgtn$1ifg$1 digitalmars.com...jasonw wrote:better langauge anyway (IMO) that I find D's immaturity to be a huge As far as the maturity of PHP though...PHP has *never* been anything that even remotely resembed "mature" (or "stable" for that matter), and I don't believe for a second that it ever will be. It is popular, heavily used, and has a big ecosystem, but it's like a metropolitan city that's built in a really big playground sandbox using silly putty instead of mortar. It's like VB or COBOL: A toy that businesses have mistaken for a serious langauge.If you want to build some fortune 500 website from scratch, D doesn't deliver the functionality you need right now.My clients and I would disagree :-) I've been using D, almost exclusively, to write business websites for quite a while now. There's a lot of big advantages there over more traditional web languages. I'm hoping to write up an article detailing some of it in the near future.
Apr 17 2011
On 4/18/11 4:00 AM, Adam D. Ruppe wrote:jasonw wrote:Please do so! :-) I'm very curious about this.If you want to build some fortune 500 website from scratch, D doesn't deliver the functionality you need right now.My clients and I would disagree :-) I've been using D, almost exclusively, to write business websites for quite a while now. There's a lot of big advantages there over more traditional web languages. I'm hoping to write up an article detailing some of it in the near future.
Apr 17 2011
On Sun, Apr 17, 2011 at 2:52 PM, jasonw <user webmails.org> wrote:Gour-Gadadhara Dasa Wrote:20 years D will be a serious contestant and mature implementations beat C+= + and traditional languages in many domains. Currently DMD produces much sl= ower executables especially for high performance computing so you would be = a total idiot to use D if the project time frame is less than 2 years.Well, http://d-programming-language.org/ page says: "D is a multi- paradigm programming language that combines a principled approach with a focus on *practicality*." and in my case I've *practical* need to write GUI app.That's certainly true, if you think of the potential D2 provides. In 5 --=If you want to build some fortune 500 website from scratch, D doesn't del=undreds of millions worth funding backing them.If you build a desktop application, D isn't the best choice, but you can =still argue to your boss to use it instead because of your personal "produc= tivity" issues. There's no other logical reason to use D instead of C++/Qt = or some other mature GUI toolkit.Bloated executables aren't suitable for embedded platforms either, but in=10 -- 20 years we will have a D compiler that targets platforms with less = than 4 MB of RAM+ROM. I find it unlike that we have a reliable D compiler f= or very small 32-bit embedded devices in 5 years.5 to 20 years? 10 to 20 years? How do you come up with those big and depressing numbers? I personally think within 2 to 4 years there is going to be an explosion of software written in D.
Apr 17 2011
Caligo Wrote:On Sun, Apr 17, 2011 at 2:52 PM, jasonw <user webmails.org> wrote:I'd like to be more optimistic, but I'm comparing the development to projects such as LLVM. The ultimate performance goal isn't static. The leading compilers and languages are getting better so the goal is also going higher with every new release of GCC, Fortran compilers, and LLVM. Don't get me wrong, D is already much faster than many "toy" languages. Faster C/C++/Fortran users will only switch if D provides concrete performance improvements over their *existing* toolchains. It has taken LLVM several years and they're not yet even on par with GCC in all benchmarks. The web application issue depends on the amount of libraries. It's a community issue. The main embedded issue is code bloat. Nobody has come up with a proof of concept solution to typeinfo and template bloat. It's impossible to think it will be solved without proof of concept in less than 5 years. You disagree?Gour-Gadadhara Dasa Wrote:5 to 20 years? 10 to 20 years? How do you come up with those big and depressing numbers?Well, http://d-programming-language.org/ page says: "D is a multi- paradigm programming language that combines a principled approach with a focus on *practicality*." and in my case I've *practical* need to write GUI app.That's certainly true, if you think of the potential D2 provides. In 5 -- 20 years D will be a serious contestant and mature implementations beat C++ and traditional languages in many domains. Currently DMD produces much slower executables especially for high performance computing so you would be a total idiot to use D if the project time frame is less than 2 years. If you want to build some fortune 500 website from scratch, D doesn't deliver of millions worth funding backing them. If you build a desktop application, D isn't the best choice, but you can still argue to your boss to use it instead because of your personal "productivity" issues. There's no other logical reason to use D instead of C++/Qt or some other mature GUI toolkit. Bloated executables aren't suitable for embedded platforms either, but in 10 -- 20 years we will have a D compiler that targets platforms with less than 4 MB of RAM+ROM. I find it unlike that we have a reliable D compiler for very small 32-bit embedded devices in 5 years.
Apr 17 2011
jasonw <user webmails.org> writes:Don't get me wrong, D is already much faster than many "toy" relevant is that the C/C++/Fortran users will only switch if D provides concrete performance improvements over their *existing* toolchains. It has taken LLVM several years and they're not yet even on par with GCC in all benchmarks.I would challenge this statement somewhat. I do high-performance programming in C++. I don't expect D compilers to generate faster code than C++, but to rather that they will achieve parity. What I do expect is that D will make it significantly easier to write and maintain this fast code. That is worth quite a bit. Developer time is important even when writing high-performance code.
May 03 2011
On 5/3/2011 7:58 PM, Jerry wrote:I would challenge this statement somewhat. I do high-performance programming in C++. I don't expect D compilers to generate faster code than C++, but to rather that they will achieve parity. What I do expect is that D will make it significantly easier to write and maintain this fast code. That is worth quite a bit. Developer time is important even when writing high-performance code.My experience in tuning D code for speed is that if you write "C++" code in D, you will get the same performance as C++. However, D makes it a *lot* easier to reorganize/refactor code to try and make it run faster, and this makes for better algorithms and hence faster code. For example, should I pass an object around by ref or by value? In C++, I've got to convert all my -> to . or vice versa, throughout the code. With D, I just change the alias declaration.
May 03 2011
Walter Bright wrote:My experience in tuning D code for speed is that if you write "C++" code in D, you will get the same performance as C++. However, D makes it a *lot* easier to reorganize/refactor code to try and make it run faster, and this makes for better algorithms and hence faster code.Anecdote: Friday, I was asked to justify my decision to use D to a company exec. He pointed me to some benchmarks that had ruby vs python vs php vs C++ and asked how D would stack up. (The benchmark was sorting an array of integers, nothing really fancy.) Of them, Python had the shortest code, but C++ was the fastest, by far. Not really surprising. I first ported C++ to D. Equal lines of code, equal performance. The optimized builds did show D lagging ~20% behind g++ though. But, 20% behind g++ is still about 8x faster than the interpreted languages, so not bad. But, then I made a few minor tweaks. Slicing instead of copying. Array operations and foreach instead of iterator loops, stuff like that. The D code was now the shortest of all - even beating Python by a couple lines - while being just as readable and editable as the "productivity languages". And, to my surprise, the standard compile actually *beat* the optimized C++ build, running twice as fast! I was expecting it to be about equal, but instead, it just spanked it. Shorter code, easier to read code *AND* faster code, it beat all the competition in all the categories. Very pleasing result for everyone involved. Now, I dislike benchmarks as a general rule. Real world code is a lot more complex than these trivial things realize. But hell, when they work /for/ me, I won't complain. (Also, while a weaker comparison, I find this same trend continues to apps as a whole too. My D web app is about 1/8 the size in code of the smallest open source PHP program I found with similar features. 40% faster too. But Perpetually Hideous Programs are, well, perpetually hideous. Beating PHP is no great feat.)
May 03 2011
This is an awesome case history of exactly what we are trying to achieve with D. Any chance you could make an article out of this? Brief is ok. Essentially showing the different language versions, then what you did to the D one that kicked ass. On 5/3/2011 8:42 PM, Adam D. Ruppe wrote:Walter Bright wrote:My experience in tuning D code for speed is that if you write "C++" code in D, you will get the same performance as C++. However, D makes it a *lot* easier to reorganize/refactor code to try and make it run faster, and this makes for better algorithms and hence faster code.Anecdote: Friday, I was asked to justify my decision to use D to a company exec. He pointed me to some benchmarks that had ruby vs python vs php vs C++ and asked how D would stack up. (The benchmark was sorting an array of integers, nothing really fancy.) Of them, Python had the shortest code, but C++ was the fastest, by far. Not really surprising. I first ported C++ to D. Equal lines of code, equal performance. The optimized builds did show D lagging ~20% behind g++ though. But, 20% behind g++ is still about 8x faster than the interpreted languages, so not bad. But, then I made a few minor tweaks. Slicing instead of copying. Array operations and foreach instead of iterator loops, stuff like that. The D code was now the shortest of all - even beating Python by a couple lines - while being just as readable and editable as the "productivity languages". And, to my surprise, the standard compile actually *beat* the optimized C++ build, running twice as fast! I was expecting it to be about equal, but instead, it just spanked it. Shorter code, easier to read code *AND* faster code, it beat all the competition in all the categories. Very pleasing result for everyone involved. Now, I dislike benchmarks as a general rule. Real world code is a lot more complex than these trivial things realize. But hell, when they work /for/ me, I won't complain. (Also, while a weaker comparison, I find this same trend continues to apps as a whole too. My D web app is about 1/8 the size in code of the smallest open source PHP program I found with similar features. 40% faster too. But Perpetually Hideous Programs are, well, perpetually hideous. Beating PHP is no great feat.)
May 03 2011
On 4/05/11 4:08 AM, Walter Bright wrote:For example, should I pass an object around by ref or by value? In C++, I've got to convert all my -> to . or vice versa, throughout the code. With D, I just change the alias declaration.How do you manage to change a pass-by-value to pass-by-reference by changing an alias? e.g. struct Vec3(T) { ... } T dot(Vec3!T a, Vec3!T b) { return a.x * b.x + a.y * b.y + a.z * b.z; } /* lots more functions that pass Vec3 by value */ How would you change Vec3!T to be passed by reference by changing an alias param? P.S. In C++, you'd change T dot(Vec3<T> a, Vec<T> b) to T dot(Vec3<T> const& a, Vec3<T> const& b) No need to change . to ->
May 04 2011
On 5/4/2011 12:55 PM, Peter Alexander wrote:On 4/05/11 4:08 AM, Walter Bright wrote:alias Vec3!T* V; T dot(V a, V b); Now I can change V to whatever I want, pointer or value, without having to edit anything but the alias.For example, should I pass an object around by ref or by value? In C++, I've got to convert all my -> to . or vice versa, throughout the code. With D, I just change the alias declaration.How do you manage to change a pass-by-value to pass-by-reference by changing an alias?
May 04 2011
On 5/3/2011 10:58 PM, Jerry wrote:What I do expect is that D will make it significantly easier to write and maintain this fast code. That is worth quite a bit. Developer time is important even when writing high-performance code.+1000. IMHO one of D's biggest accomplishments is how far it pushes the ability to write fast code and write code fast in the same language. In fact, that's the single biggest reason I use it. Even if current implementations aren't quite as fast as C++, they're a lot faster than probably anything else with similar productivity. Equivalently, D is probably a lot more productive than anything with similar performance. is that they both have abstractions you can't get beneath in your most performance-critical code. If you're writing code from scratch (as opposed to something that would benefit from tons of libraries that D doesn't have yet), I also think they're not as productive because they don't make metaprogramming easy.
May 03 2011
On Tue, 2011-05-03 at 23:14 -0400, dsimcha wrote: [ . . . ]=20is that they both have abstractions you can't get beneath in your most==20performance-critical code. If you're writing code from scratch (as=20 opposed to something that would benefit from tons of libraries that D=20 doesn't have yet), I also think they're not as productive because they==20don't make metaprogramming easy.Groovy/Scala/Java/Clojure on the JVM, and indeed Python on the PVM, if there is a small piece of code that is truly performance critical and you can't get the JVM/JIT to make it fast enough and native code can then you call out to C or C++ -- real performance data not speculation is required here though. Of course this is far, far easier with Python. Much of the "need flexibility"/"developer time is more important than run time because I am just using APIs that are already optimized" HPC-ish stuff is now happening in Python with C/C++/Fortran libraries, cf. NumPy, SciPy. Why is D not an up-front contender here more widely than it is? Ease of creating GUIs and rendering data mostly I would suggest. It's so much about data visualization rather than computation these days. Python has easy connection to Qt, GTK, wxWidgets, etc. QtDesigner, Glade, and wxGlade make laying out the UI easy, generating XML specification. Then the dynamic aspects of Python make it trivial to read in XML and instantiate all the widgets and connect up the events. C, C++, Go, and D are not even in the race except for systems such as games where the timings are so critical, assembly language is a real contender. I wonder if D could get more traction by adding dataflow to the evolving actor and data parallelism stuff. With Groovy/GPars (dynamic languages make metaprogramming really trivial btw) we are seeing a take up of dataflow as well as actor model and data parallelism. There are even commercial Java dataflow frameworks that are storming the analytics using JVM world. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 04 2011
On 5/4/2011 3:13 AM, Russel Winder wrote:On Tue, 2011-05-03 at 23:14 -0400, dsimcha wrote: [ . . . ]True but somewhat irrelevant. The problem with this is that you're still writing the critical bits in C/C++, and furthermore a dialect of C/C++ that requires a well-defined ABI. In my experience, when mixing languages there's always friction along the borders. Furthermore, when you do something like this you have to specify types explicitly. D and C++ are the only languages I'm aware of that let you write efficient generic code. After using D, C++ seems half-assed in this area. D is the only language I'm aware of that lets you do it **well**.is that they both have abstractions you can't get beneath in your most performance-critical code. If you're writing code from scratch (as opposed to something that would benefit from tons of libraries that D doesn't have yet), I also think they're not as productive because they don't make metaprogramming easy.Groovy/Scala/Java/Clojure on the JVM, and indeed Python on the PVM, if there is a small piece of code that is truly performance critical and you can't get the JVM/JIT to make it fast enough and native code can then you call out to C or C++ -- real performance data not speculation is required here though. Of course this is far, far easier with Python. Much of the "need flexibility"/"developer time is more important than run time because I am just using APIs that are already optimized" HPC-ish stuff is now happening in Python with C/C++/Fortran libraries, cf. NumPy, SciPy.
May 04 2011
Not sure about the sometimes, but nowadays they can be very fast. Regarding .Net/CLR, the bytecode only exists as portable assembly. When a an assembly (.dll/.exe )file is loaded the complete code is JITed before execution starts. Another possibility is to use ahead of time compilation and thanks to ngen, already deploy the assembly in native code. If you think that the JIT is not doing a good work compiling your code, you can step down to C++/CLI which is able to blend native code and managed. On the Java world, usually the methods are only compiled after a certain threshold has been reached, most JVMs allow to customize this threshold via a non standard parameter. if you set it to zero, you get the same behavior as in .Net. If you are also not happy with the JITed code, you can turn to a real compiler like the Excelsior JET. http://www.excelsior-usa.com/jet.html -- Paulo "Russel Winder" <russel russel.org.uk> wrote in message news:mailman.24.1304493198.14074.digitalmars-d puremagic.com... On Tue, 2011-05-03 at 23:14 -0400, dsimcha wrote: [ . . . ]is that they both have abstractions you can't get beneath in your most performance-critical code. If you're writing code from scratch (as opposed to something that would benefit from tons of libraries that D doesn't have yet), I also think they're not as productive because they don't make metaprogramming easy.Groovy/Scala/Java/Clojure on the JVM, and indeed Python on the PVM, if there is a small piece of code that is truly performance critical and you can't get the JVM/JIT to make it fast enough and native code can then you call out to C or C++ -- real performance data not speculation is required here though. Of course this is far, far easier with Python. Much of the "need flexibility"/"developer time is more important than run time because I am just using APIs that are already optimized" HPC-ish stuff is now happening in Python with C/C++/Fortran libraries, cf. NumPy, SciPy. Why is D not an up-front contender here more widely than it is? Ease of creating GUIs and rendering data mostly I would suggest. It's so much about data visualization rather than computation these days. Python has easy connection to Qt, GTK, wxWidgets, etc. QtDesigner, Glade, and wxGlade make laying out the UI easy, generating XML specification. Then the dynamic aspects of Python make it trivial to read in XML and instantiate all the widgets and connect up the events. C, C++, Go, and D are not even in the race except for systems such as games where the timings are so critical, assembly language is a real contender. I wonder if D could get more traction by adding dataflow to the evolving actor and data parallelism stuff. With Groovy/GPars (dynamic languages make metaprogramming really trivial btw) we are seeing a take up of dataflow as well as actor model and data parallelism. There are even commercial Java dataflow frameworks that are storming the analytics using JVM world. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 04 2011
On Sun, 17 Apr 2011 15:52:36 -0400 jasonw <user webmails.org> wrote:If you build a desktop application, D isn't the best choice, but you can still argue to your boss to use it instead because of your personal "productivity" issues. There's no other logical reason to use D instead of C++/Qt or some other mature GUI toolkit.In my case, I'm going to write desktop application and there is no 'boss' - it's going to be open-source. :-) Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
Am 17.04.2011 21:52, schrieb jasonw:Gour-Gadadhara Dasa Wrote:*Much* slower? Really? What benchmarks are you citing?Well, http://d-programming-language.org/ page says: "D is a multi- paradigm programming language that combines a principled approach with a focus on *practicality*." and in my case I've *practical* need to write GUI app.That's certainly true, if you think of the potential D2 provides. In 5 -- 20 years D will be a serious contestant and mature implementations beat C++ and traditional languages in many domains. Currently DMD produces much slower executables especially for high performance computing so you would be a total idiot to use D if the project time frame is less than 2 years.If you want to build some fortune 500 website from scratch, D doesn't deliver of millions worth funding backing them. If you build a desktop application, D isn't the best choice, but you can still argue to your boss to use it instead because of your personal "productivity" issues. There's no other logical reason to use D instead of C++/Qt or some other mature GUI toolkit. Bloated executables aren't suitable for embedded platforms either, but in 10 -- 20 years we will have a D compiler that targets platforms with less than 4 MB of RAM+ROM. I find it unlike that we have a reliable D compiler for very small 32-bit embedded devices in 5 years.Do you really think in "10 -- 20 years" somebody will care of your code runs in an embedded platform with only 4MB of RAM+ROM? Memory etc is so cheap that these platforms will get more powerful. Why should it take so long to have such a compiler? On the one hand: Why are D executables so "bloated"? 1. Phobos and druntime is statically compiled in. On a really limited embedded platform you wouldn't use Phobos anyway, but write your own standardlib and runtime that suit your needs (it's not like anybody would use full C++ with STL on such a platform. Well, probably not even C++ at all or only a very limited subset). 2. Garbage from templates/CTFE. You just could use less templates and stuff for your embedded platform.. also I think this will be fixed soon(ish). Don just fixed many things in CTFE, maybe this already fixes bloat, but I'm not sure. So how long could it take until there's "a D compiler that targets platforms with less than 4 MB of RAM+ROM"? I'd say anywhere between right now and never. Maybe someone already decided to develop such a compiler and told nobody yet (right now). Or someone starts now or soon and has it ready in a year or two. If nobody is interesting in developing such a compiler, we'll never have one. So: It will be there once somebody develops it. If he takes LDC or GDC (or maybe even DMD) as a basis maybe something like that could be done relatively fast (if the team is big enough and has time etc). As mentioned before, Phobos would probably not be used on such platforms, so there's no need to wait for Phobos to become more mature/complete until developing such a compiler. Cheers, - Daniel
Apr 17 2011
On 4/17/2011 1:27 PM, Daniel Gibson wrote:1. Phobos and druntime is statically compiled in. On a really limited embedded platform you wouldn't use Phobos anyway, but write your own standardlib and runtime that suit your needs (it's not like anybody would use full C++ with STL on such a platform. Well, probably not even C++ at all or only a very limited subset).On 16 bit DOS computers, you can't use C++ STL or even exception handling.
Apr 17 2011
Walter Bright Wrote:On 4/17/2011 1:27 PM, Daniel Gibson wrote:I'd like to hear your comments about the 32-bit D2 and minimal executables issue. If I use dietlibc and gcc, the minimal (static) binary is about 0.2 kilobytes. DMD should have some switch (-embedded) which leaves out all the cruft I don't need. I'd like to use the cool new features and start with this kind of minimal executables. 0.5 - 50 kilobyte range is optimal.1. Phobos and druntime is statically compiled in. On a really limited embedded platform you wouldn't use Phobos anyway, but write your own standardlib and runtime that suit your needs (it's not like anybody would use full C++ with STL on such a platform. Well, probably not even C++ at all or only a very limited subset).On 16 bit DOS computers, you can't use C++ STL or even exception handling.
Apr 17 2011
On 4/17/2011 1:46 PM, jasonw wrote:I'd like to hear your comments about the 32-bit D2 and minimal executables issue. If I use dietlibc and gcc, the minimal (static) binary is about 0.2 kilobytes. DMD should have some switch (-embedded) which leaves out all the cruft I don't need. I'd like to use the cool new features and start with this kind of minimal executables. 0.5 - 50 kilobyte range is optimal.Are you talking about static linking, or using shared libraries?
Apr 17 2011
Walter Bright Wrote:On 4/17/2011 1:46 PM, jasonw wrote:I mentioned static binaries, but I meant statically linked binaries. So yes, a situation where everything, including the standard library, is statically linked.I'd like to hear your comments about the 32-bit D2 and minimal executables issue. If I use dietlibc and gcc, the minimal (static) binary is about 0.2 kilobytes. DMD should have some switch (-embedded) which leaves out all the cruft I don't need. I'd like to use the cool new features and start with this kind of minimal executables. 0.5 - 50 kilobyte range is optimal.Are you talking about static linking, or using shared libraries?
Apr 17 2011
On 4/17/2011 1:54 PM, jasonw wrote:Walter Bright Wrote:Many D features, such as the GC, are simply going to require a significant amount of code in the library. It is possible to cut down the library size if you are willing to eschew some features.On 4/17/2011 1:46 PM, jasonw wrote:I mentioned static binaries, but I meant statically linked binaries. So yes, a situation where everything, including the standard library, is statically linked.I'd like to hear your comments about the 32-bit D2 and minimal executables issue. If I use dietlibc and gcc, the minimal (static) binary is about 0.2 kilobytes. DMD should have some switch (-embedded) which leaves out all the cruft I don't need. I'd like to use the cool new features and start with this kind of minimal executables. 0.5 - 50 kilobyte range is optimal.Are you talking about static linking, or using shared libraries?
Apr 17 2011
On 2011-04-17 22:27, Daniel Gibson wrote:Am 17.04.2011 21:52, schrieb jasonw:This is quite a big advantage C and C++ have. The runtime will almost always be available on the platform and you can link to it dynamically. You can use Tango as a dynamic library on Mac OS X and a Hello World application will be the same size as a Hello World application written in C. -- /Jacob CarlborgGour-Gadadhara Dasa Wrote:*Much* slower? Really? What benchmarks are you citing?Well, http://d-programming-language.org/ page says: "D is a multi- paradigm programming language that combines a principled approach with a focus on *practicality*." and in my case I've *practical* need to write GUI app.That's certainly true, if you think of the potential D2 provides. In 5 -- 20 years D will be a serious contestant and mature implementations beat C++ and traditional languages in many domains. Currently DMD produces much slower executables especially for high performance computing so you would be a total idiot to use D if the project time frame is less than 2 years.If you want to build some fortune 500 website from scratch, D doesn't deliver of millions worth funding backing them. If you build a desktop application, D isn't the best choice, but you can still argue to your boss to use it instead because of your personal "productivity" issues. There's no other logical reason to use D instead of C++/Qt or some other mature GUI toolkit. Bloated executables aren't suitable for embedded platforms either, but in 10 -- 20 years we will have a D compiler that targets platforms with less than 4 MB of RAM+ROM. I find it unlike that we have a reliable D compiler for very small 32-bit embedded devices in 5 years.Do you really think in "10 -- 20 years" somebody will care of your code runs in an embedded platform with only 4MB of RAM+ROM? Memory etc is so cheap that these platforms will get more powerful. Why should it take so long to have such a compiler? On the one hand: Why are D executables so "bloated"? 1. Phobos and druntime is statically compiled in. On a really limited embedded platform you wouldn't use Phobos anyway, but write your own standardlib and runtime that suit your needs (it's not like anybody would use full C++ with STL on such a platform. Well, probably not even C++ at all or only a very limited subset).
Apr 18 2011
I'm not defending other languages, I'm recommending them. I'm also recommending D when its appropriate. But nobody is forced to use just one programming language. I use at least half a dozen languages throughout my average week; C, C++, Python, Delphi (rarely), D, AHK, batch (hehe, ok that one doesn't count :p), some ASM which I'm just playing around with for now, and probably other languages. Gour doesn't have to quit D, he can use some time-out for a while and see what Python has to offer. In the meantime the D ecosystem will likely grow. Now, these arguments aside, onto the technical side of things. You could build a GUI in Python and then link to D via callback functions. It shouldn't be a problem with either Python's ctypes or Cython, whichever might be easier to use. Python+Qt has been stable for a long while now, so it's really not a bad choice as a GUI language. And it has good documentation and books to learn from, and plenty of example code too. I'm not sure what that would do to performance (linking Python with D), but then again I don't know what type of desktop app Gour is building. On the other hand, I've seen Python being used in a realtime app that is linked with C++. For example Ableton Live (a fairly popular music sequencer) uses the Boost C++ Python binding for a big part of their application. They use it to interface with various MIDI and sequencing hardware, and various hardware manufacturers develop their own Ableton-specific Python scripts that add support to their special hardware so it works nicely in Ableton Live. I believe they might also be using Python to run their GUI, but I can't be sure since I've only heard that offhand from some people commenting about it. Now, there's a Python binding project for D1, PyD, with exception support and various other nice things. I don't know whether anyone will work on a D2 version. But from looking at its source it doesn't look *too* complicated. In fact there's a good part of that code seems to be implementation of common functions which were missing in D1 Phobos, but are here in Phobos2. So maybe it wouldn't be too hard to port that to D2 some day. But I don't know the details.
Apr 17 2011
On 4/17/2011 2:37 PM, Gary Whatmore wrote:In every young language community the first users have to make sacrifices and build the ecosystem. That's how it goes.While I'm not endorsing the rude tone of the rest of this post, this is an extremely good point. According to Wikipedia, Python is about 8 years older than D. I imagine that 8 years ago people were saying the same things about Python that they say about D now. Back then, everyone was using Perl for Python's niche and probably (I wasn't a programmer back then) saying how Python's ecosystem is too immature, Perl is good enough despite its warts, there's so much existing code written in it, etc. There will always be a tradeoff between using the latest and greatest language that the ecosystem hasn't caught up with yet and using an older language with tons of legacy baggage, bad-in-hindsight or outdated design decisions and great, mature tools and libraries. D is strongly in the former category. Java and C++ are in the latter. Python is somewhere in between. Ironically, unlike the real trolls we deal with, Gour seems to understand this. All he's saying is that D2 does not embody the tradeoff he wants to make right now.
Apr 17 2011
On Sun, 17 Apr 2011 20:26:49 +0200 Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:Gour, please disregard the troll above.:-)If you're going with Python and Qt, I'd wholeheartedly recommend this book: http://www.qtrac.eu/pyqtbook.htmlYeah...I just got reply from Mark if he is planning 2nd ed. or the first one is still not obosolete.Making GUIs with PyQT is dead simple. And Nokia already has that new LGPL(I think?)-licensed binding in place - http://www.pyside.org.=20I know about, although I may try with PyQt due to py3k support.So your decision might not be bad at all.Well, it's not ideal, but some kind of compromise.What type of desktop app are you building? Does it need to be very-high performance?=20Vedic astrology program. Performance *might* be issue, although we'll use Swiss Ephmeris C-library and try to compensate possible lack of speed by using Cython.Python itself isn't too bad with Qt, I don't think it was slow in any way the last time I used it.Thank you for kind words. ;) Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
On 4/17/2011 11:18 AM, Gary Whatmore wrote:One thing, go hang yourself. We[...]Gour-Gadadhara Dasa has done nothing to merit such inexcusable rudeness. I appreciate his polite and thoughtful post about why D is not the right solution for his needs at this time.
Apr 17 2011
On Sun, Apr 17, 2011 at 4:37 AM, Gour-Gadadhara Dasa <gour atmarama.net> wrote:Hello! My first post to this newsgroup was a little bit more than 6 months ago and today I've decided to leave D and use C(P)ython + Qt for our open-source project of writing multi-platform desktop application. The D community is very nice and supportive, Walter, Andrei & co. are working hard, but, imho, D is not ready (yet). Recently, after switching from Linux to (Free)PC-BSD I even lost ability to have working compiler on x86_64 (none of the compilers is available in ports).Frankly, if your definition of "not ready" is that the compiler isn't packaged for you, D isn't the right community to begin with.The crucial thing is that D's ecosystem is simply not ready for day-to-day GUI programming and there is no clear roadmap so that one can anticipate when to expect that something will be done.The problem with ecosystems is that there is never a roadmap unless your development follows the Microsoft model, where everything is benevolently dictated. That works, but D isn't Microsoft.Let me say, that I really like what D has on its plate, but language needs libraries to be successful, otherwise it is only promise-land.D has libraries, it's just a matter of downloading, building, and reporting bugs rather than installing, reading a book, and firing up the UI designer. They're rough, but they're there.I've become tired for programming language's ecosystem to become mature...waited too long with Haskell and arrived to D hoping it is more pragmatic for day-to-day usage, but the situation seems even worse...Yeah, I know...I arrived at the wrong time during D1 --> D2 transition... That's, why I believe that the mantra in the subject, which I coined in IRC the other day, holds true. I'm thankful to all the members of this group for every piece of advice and input I received, as well to Andrei (his book is on my shelf - I even put it in the hardcover), but I want to code my project *today*, have plenty of (GUI) choices, lot of docs, tools and clear roadmap where the certain projects are going. I hope I might re-evaluate D2 sometime in the future for some other project...I'm (and I think I can say we're) sad to see you go, and hopefully you'll look to D in the future, but in the present, choose the right tool for the job. It's unwise to do anything else. (Unless you're a college student with too much time on his hands, but I'm pretty sure that's not your situation)
Apr 17 2011
On Sun, 17 Apr 2011 15:11:43 -0500 Andrew Wiley <debio264 gmail.com> wrote:Frankly, if your definition of "not ready" is that the compiler isn't packaged for you, D isn't the right community to begin with.First of all, there is no 64bit compiler for FreeBSD. I was researching about gdc and Iain Buclaw told me (on IRC) that there might be problem with dmd runtime on FreeBSD. Moreover, "QtD requires a patched dmd compiler.", so I simply do not have time to fight such things.D has libraries, it's just a matter of downloading, building, and reporting bugs rather than installing, reading a book, and firing up the UI designer. They're rough, but they're there.Can you name me some serious GUI application using e.g. QtD & sqlite database badck-end written in D2?I'm (and I think I can say we're) sad to see you go, and hopefully you'll look to D in the future, but in the present, choose the right tool for the job. It's unwise to do anything else./me nods(Unless you're a college student with too much time on his hands, but I'm pretty sure that's not your situation)Right. I'm not college student, want to program in my free time and desire to write open-source application instead of building ecosystem for what I anyway do not have required skills. :-) Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
On 4/17/2011 1:34 PM, Gour-Gadadhara Dasa wrote:Moreover, "QtD requires a patched dmd compiler.", so I simply do not have time to fight such things.I'd also like to know which bugzilla entry has that patch!
Apr 17 2011
On Sun, 17 Apr 2011 13:45:06 -0700 Walter Bright <newshound2 digitalmars.com> wrote:I'd also like to know which bugzilla entry has that patch!See:=20 https://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatch Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
On 4/17/2011 1:55 PM, Gour-Gadadhara Dasa wrote:On Sun, 17 Apr 2011 13:45:06 -0700 Walter Bright<newshound2 digitalmars.com> wrote:I clicked around that for a while, but can't seem to find the patch file dmd.dmd-version.patchI'd also like to know which bugzilla entry has that patch!See: https://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatch
Apr 17 2011
On 4/18/11, Walter Bright <newshound2 digitalmars.com> wrote:On 4/17/2011 1:55 PM, Gour-Gadadhara Dasa wrote:http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=rawOn Sun, 17 Apr 2011 13:45:06 -0700 Walter Bright<newshound2 digitalmars.com> wrote:I clicked around that for a while, but can't seem to find the patch file dmd.dmd-version.patchI'd also like to know which bugzilla entry has that patch!See: https://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatch
Apr 17 2011
Am 18.04.2011 00:27, schrieb Andrej Mitrovic:On 4/18/11, Walter Bright <newshound2 digitalmars.com> wrote:This should probably be mentioned at the bitbucket wiki.On 4/17/2011 1:55 PM, Gour-Gadadhara Dasa wrote:http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=rawOn Sun, 17 Apr 2011 13:45:06 -0700 Walter Bright<newshound2 digitalmars.com> wrote:I clicked around that for a while, but can't seem to find the patch file dmd.dmd-version.patchI'd also like to know which bugzilla entry has that patch!See: https://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatch
Apr 17 2011
On 4/18/11 12:34 AM, Daniel Gibson wrote:Ah, sorry, this was a side effect of QtD currently being in limbo between Bitbucket (DVCS hosting) and DSource (wiki, issue tracker). I just replaced the Bitbucket Wiki frontpage with a link to DSource until someone finds time to properly migrate all the contents – the patch was not the only dead link… As for the patch itself, it is more or less just a quick hack to be able to access e.g. the module a declaration is in, which is needed for some parts of the enum handling code – Max Samukha knows the details. It should also be noted that you don't necessarily need to patch DMD if your application builds fine without the patch. DavidThis should probably be mentioned at the bitbucket wiki.http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=rawhttps://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatchI clicked around that for a while, but can't seem to find the patch file dmd.dmd-version.patch
Apr 17 2011
"David Nadlinger" <see klickverbot.at> wrote in message news:ioftkj$2811$1 digitalmars.com...On 4/18/11 12:34 AM, Daniel Gibson wrote:I've had need for a feature like that, too. Luckily in my case, I only needed to get the name of the current module (within some mixed-in code), so I was able to hack my way through with a dummy var and some mangle/demangle gymnastics. I definitely agree that a more general "get module of symbol" is needed.Ah, sorry, this was a side effect of QtD currently being in limbo between Bitbucket (DVCS hosting) and DSource (wiki, issue tracker). I just replaced the Bitbucket Wiki frontpage with a link to DSource until someone finds time to properly migrate all the contents - the patch was not the only dead link. As for the patch itself, it is more or less just a quick hack to be able to access e.g. the module a declaration is in, which is needed for some parts of the enum handling code - Max Samukha knows the details.This should probably be mentioned at the bitbucket wiki.http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=rawhttps://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatchI clicked around that for a while, but can't seem to find the patch file dmd.dmd-version.patch
Apr 17 2011
On Apr 18, 11 07:34, David Nadlinger wrote:On 4/18/11 12:34 AM, Daniel Gibson wrote:The patch is now integrated into dmd :) https://github.com/D-Programming-Language/dmd/commit/2e261cd640e5266c569ad224ffbfe229a0315d97Ah, sorry, this was a side effect of QtD currently being in limbo between Bitbucket (DVCS hosting) and DSource (wiki, issue tracker). I just replaced the Bitbucket Wiki frontpage with a link to DSource until someone finds time to properly migrate all the contents – the patch was not the only dead link… As for the patch itself, it is more or less just a quick hack to be able to access e.g. the module a declaration is in, which is needed for some parts of the enum handling code – Max Samukha knows the details. It should also be noted that you don't necessarily need to patch DMD if your application builds fine without the patch. DavidThis should probably be mentioned at the bitbucket wiki.http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=rawhttps://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatchI clicked around that for a while, but can't seem to find the patch file dmd.dmd-version.patch
Apr 17 2011
On 4/17/2011 3:27 PM, Andrej Mitrovic wrote:http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=rawGot it, tanks!
Apr 17 2011
== Quote from Gour-Gadadhara Dasa (gour atmarama.net)'s article--Sig_/Ckct3lX7w5hlz_Hd5UDhpMB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 17 Apr 2011 15:11:43 -0500 Andrew Wiley <debio264 gmail.com> wrote:Emphasis on the word 'might' O:) There should be little reason why the compiler won't build/work sweet as roses - as no one's tested though, there may be some gaps in the C bindings that trigger static asserts, throw undefined identifier errors, or evoke some wacky occurrences in runtime.Frankly, if your definition of "not ready" is that the compiler isn't packaged for you, D isn't the right community to begin with.First of all, there is no 64bit compiler for FreeBSD. I was researching about gdc and Iain Buclaw told me (on IRC) that there might be problem with dmd runtime on FreeBSD.
Apr 17 2011
On Sun, 17 Apr 2011 21:49:34 +0000 (UTC) Iain Buclaw <ibuclaw ubuntu.com> wrote:There should be little reason why the compiler won't build/work sweet as roses - as no one's tested though, there may be some gaps in the C bindings that trigger static asserts, throw undefined identifier errors, or evoke some wacky occurrences in runtime.The guy on #D.gdc told me he was able to build dmd on 64bit FreeBSD, but the 'application' crashes due to GC. (He, according to his own words, wanted to use D, but went back to C.)=20 Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
2011/4/17 Gour-Gadadhara Dasa <gour atmarama.net>On Sun, 17 Apr 2011 15:11:43 -0500 Andrew Wiley <debio264 gmail.com> wrote:I just want to add one thing. I am, too, trying to develop "real" open source applications in my free time, as well as practical closed source applications at work. The problem I have been facing even since the start, and are still facing, is that even if _I_ can be motivated to overcome these hurdles, I cannot expect everyone else to feel the same motivation for a new "obscure" C-like language. * At work, I have a hard time explaining to my co-workers why they need 3 hand-rolled, "this particular version" of compilers and libraries they've never heard of, just to compile my simple 200-line Mpeg analyzer. * At my free time it's even worse. Finding people able and willing to spend some time on MY pet project for free is hard enough in itself. Explaining to them why they must first spend an afternoon dealing with dependencies drive away the few that got past the first criteria. My view, is the D community right now are thinking long and hard about their own needs, and less of the needs of their users. (For a language, the application programmer IS the user.) Maybe even rightly so, getting things language-wise right from the start IS important! However, if it is desirable to attract developers that want to use D for productivity right now, there are a lot of practical issues that needs addressing, rough edges to smoothen, and hardly any of them lie in the language itself.Frankly, if your definition of "not ready" is that the compiler isn't packaged for you, D isn't the right community to begin with.First of all, there is no 64bit compiler for FreeBSD. I was researching about gdc and Iain Buclaw told me (on IRC) that there might be problem with dmd runtime on FreeBSD. Moreover, "QtD requires a patched dmd compiler.", so I simply do not have time to fight such things.
Apr 17 2011
On Sun, 17 Apr 2011 23:54:30 +0200 Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> wrote:My view, is the D community right now are thinking long and hard about their own needs, and less of the needs of their users. (For a language, the application programmer IS the user.) Maybe even rightly so, getting things language-wise right from the start IS important! However, if it is desirable to attract developers that want to use D for productivity right now, there are a lot of practical issues that needs addressing, rough edges to smoothen, and hardly any of them lie in the language itself.I agree.=20 Shortly after I joined this place, Walter sent a post listing different ways how community can help D. Here it is: * Write articles about D and post them online in various forums * Go through bugzilla and submit patches for bugs * Provide D interfaces (.di files) to popular C libraries * Integrate D support for your favorite editor * Write convoluted code to try and break the compiler * Contribute to the GDC and LDC projects *Write library modules for an area that you know well Interestingly enough, it's not listed 'write general-purpose application in D...so that others can see D is useful for writing practical applications' and that just the way I thought I could contribute :-) Anyway, enough talk. I wish all success to D2 so that we might consider it as viable alternative for our project(s) in not so distant future. Bye... ;) Sincerely, Gour --=20 =E2=80=9CIn the material world, conceptions of good and bad are all mental speculations=E2=80=A6=E2=80=9D (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 17 2011
2011/4/17 Gour-Gadadhara Dasa <gour atmarama.net>It's normal to have to deal with a new toolchain when dealing with a new programming language. It doesn't matter how mature a programming language and its toolchain are; if you're not familiar with it, then you have some learning to do. That's true of any programming language. Now, that's obviously a hurdle, but it's one that you always have to deal with when dealing with a new programming language, no matter how good it is or isn't. It's true that if the language were more mature, it would probably be easier to install and set up the compiler and standard libraries (particularly since Linux distros would then be set up to just install them all properly if you tell it to install the appropriate package or packages), but there are _always_ issues with getting someone to use a new language. As for improvements to D, its libraries, and its toolchain, those improvements _are_ happening. All you have to do is look at the changelog to see that work is being done. However, there are only so many people involved, and it takes time. So, no, in many ways, D is not ready for prime time, but it's getting there. D is very useable at this point, but there's a still a lot of work to be done for it, and whether it'll do what you're looking for and do it well enough depends entirely on what you're trying to do. GUI applications would be one area where it's definitely behind, but GUI libraries are one of the hardest and most complicated types of libraries out there, so they're likely to be behind. We'll get there, but it takes time. D continues to improve, but it still has a ways to go. But if you're willing to put up with its issues as it matures, it's well worth using. - Jonathan M DavisOn Sun, 17 Apr 2011 15:11:43 -0500 Andrew Wiley <debio264 gmail.com> wrote:I just want to add one thing. I am, too, trying to develop "real" open source applications in my free time, as well as practical closed source applications at work. The problem I have been facing even since the start, and are still facing, is that even if _I_ can be motivated to overcome these hurdles, I cannot expect everyone else to feel the same motivation for a new "obscure" C-like language. * At work, I have a hard time explaining to my co-workers why they need 3 hand-rolled, "this particular version" of compilers and libraries they've never heard of, just to compile my simple 200-line Mpeg analyzer. * At my free time it's even worse. Finding people able and willing to spend some time on MY pet project for free is hard enough in itself. Explaining to them why they must first spend an afternoon dealing with dependencies drive away the few that got past the first criteria. My view, is the D community right now are thinking long and hard about their own needs, and less of the needs of their users. (For a language, the application programmer IS the user.) Maybe even rightly so, getting things language-wise right from the start IS important! However, if it is desirable to attract developers that want to use D for productivity right now, there are a lot of practical issues that needs addressing, rough edges to smoothen, and hardly any of them lie in the language itself.Frankly, if your definition of "not ready" is that the compiler isn't packaged for you, D isn't the right community to begin with.First of all, there is no 64bit compiler for FreeBSD. I was researching about gdc and Iain Buclaw told me (on IRC) that there might be problem with dmd runtime on FreeBSD. Moreover, "QtD requires a patched dmd compiler.", so I simply do not have time to fight such things.
Apr 17 2011