www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D is coming to a town near you

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
It's just me sharing a positive experience.

TL;DR I have a strong (anecdotal) evidence that D is rapidly gaining 
popularity :)

I was well aware of D certain number of D enthusiasts from Russia,
but seeing one casually going by in the wild is another thing.

In brief I was half-sleeping in a train when a young guy
takes a seat next to me. He pulls out a laptop and powers it up.

Idly wondering what I'll see this time around (HTML/JS? Python/Ruby? MS 
Word, PowerPoint?) to my surprise I notice it boots Arch linux.

Cute... and then the guy starts X11 from the console... (dubious) with 
Xfce (+1 from me, though I'm with Cinnamon now).

The next thing he does: fire up a terminal and Geany.

Command line goes like:

cd Code/D

cd <some-project>

git pull

And then he's off furiously hacking on some GTK-based project written in D.
(I omit the details, though the repo is public)
Actually it's some kind of client-server file transfer utility, alpha 
quality it seems. I even checked the repo, seems like he's involved in 
some tiny software startup.

Bottom line for me this kind of thing beats TIOBE index any day of the 
week :)

-- 
Dmitry Olshansky
Feb 20 2013
next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Wednesday, 20 February 2013 at 17:48:29 UTC, Dmitry Olshansky 
wrote:
 It's just me sharing a positive experience.

 TL;DR I have a strong (anecdotal) evidence that D is rapidly 
 gaining popularity :)

I've noticed what looks like a large increase in the postings in D learn, which to me indicates a sudden increase in the people who are checking D out. --rt
Feb 20 2013
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
21-Feb-2013 00:08, Rob T пишет:
 On Wednesday, 20 February 2013 at 19:49:51 UTC, Namespace wrote:
 Yes your additions is included in what I meant by "stabilize". We
 need to freeze the addition of new features for the "stable release
 of the language" (we currently do not have a stable release that is
 documented) and put it through the acid test of real world use so it
 can be polished up based on the feedback.

But what about the features, that should be included, but are still missing?

Missing plus new and improved features show up in the next stable release of the language. The problem though is that we do not have a stable release of the language, nor do we even have a beta release.

There are betas. Just subscribe to the right mailing list. That being said the start of new beta cycle should be listed at D.announce IMHO. -- Dmitry Olshansky
Feb 20 2013
prev sibling parent reply 1100110 <0b1100110 gmail.com> writes:
On 02/20/2013 12:42 PM, bearophile wrote:
 Rob T:

 and do a ton of boring stuff like stabilize D2/Phobos before moving on
 to D3, install better processes for documentation and developing the
 language specifications, and of course continue to improve the release
 process (it still needs a real beta and stable release), etc.

"Stabilize" is the wrong word to use. Implementing the 64 compiler is good, implementing shared libraries is good, porting D runtime/Phobos to RISC CPUs is good, replacing the GC is good, improving the floating point management by DMD is good, and so on and on. But in my opinion what's more needed now is instead to try to complete as much as possible the design and implementation of the missing/broken/incomplete parts of the core language (like finishing const/immutable design, finishing the implementation of pure, redesigning properties, fixing trusted, doing what's possible with shared, doing what's possible to finish the inference of tags like pure in templated functions, finishing the design of packages, finishing the implementation of the module system, finishing the design of operator overloading, and so on. The complete list of broken/unfinished parts scares me). Bye, bearophile

Yes. Shared Libraries Please. Thank you.
Feb 20 2013
next sibling parent reply 1100110 <0b1100110 gmail.com> writes:
On 02/20/2013 06:55 PM, H. S. Teoh wrote:
 On Thu, Feb 21, 2013 at 01:55:00AM +0100, Rob T wrote:
 On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin wrote:
 [...]
 Yes. Shared Libraries Please.

 Thank you.

+1 It's the most important issue for me. Particular feature bugs can be worked around, lack of shared library support is insurmountable for many applications.



I was playing with LuaD (https://github.com/JakobOvrum/LuaD) and was disappointed to learn that the only way to call D functions from Lua is for the lua code to be 'inside' a D module. (string l = "lua goes here"; or similar) There are a few tricks you can perform, but it placed a very real limit on its usefulness. Which is sad because other than that LuaD is beautiful.
 Yes, it's a major barrier towards adoption in a production
 environment. Walter said it's now a priority, so I cross the fingers
 and hope.

Better yet, maybe more of us should start delving into DMD's code... Currently only a small number of people really understand the compiler, which has a rather low bus factor. We need to increase that (not only to improve the bus factor, but also so that more people are aware of compiler issues and hopefully how to fix them). T

I only know enough C/C++ to know that I don't know enough... If I could, I would totally go tearing through the source right now. But some of it seems ambiguous to me. I'm afraid I'd do more harm than good.
Feb 20 2013
parent reply 1100110 <0b1100110 gmail.com> writes:
On 02/21/2013 11:13 AM, Jesse Phillips wrote:
 On Thursday, 21 February 2013 at 01:50:27 UTC, 1100110 wrote:
 I was playing with LuaD (https://github.com/JakobOvrum/LuaD) and was
 disappointed to learn that the only way to call D functions from Lua
 is for the lua code to be 'inside' a D module. (string l = "lua goes
 here"; or similar)

I don't understand "inside a D module" void someFun(string content) { ... } lua["someFun"] = &someFun; lua.doFile("SomeFileName.lua");

D starts lua, and lua finishes before D. That fits my definition of 'inside a D file' but I admit I should have chosen my phrasing better. Try lua starts D, and D finishes before lua.
Feb 22 2013
parent reply FG <home fgda.pl> writes:
Those are two different approaches:

 D starts lua, and lua finishes before D.

It's _embedding_ LUA in D. Can be easily done now.
 Try lua starts D, and D finishes before lua.

It's _extending_ LUA with D. Requires good D shared library support. :(
Feb 22 2013
parent 1100110 <0b1100110 gmail.com> writes:
On 02/22/2013 04:51 AM, FG wrote:
 Those are two different approaches:

 D starts lua, and lua finishes before D.

It's _embedding_ LUA in D. Can be easily done now.
 Try lua starts D, and D finishes before lua.

It's _extending_ LUA with D. Requires good D shared library support. :(

Thanks for setting me straight.
Feb 22 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-21 01:55, Rob T wrote:

 Yes, it's a major barrier towards adoption in a production environment.
 Walter said it's now a priority, so I cross the fingers and hope.

Several pull request from Martin Nowak have already been merged in that last couple of days which implement parts of what's needed. -- /Jacob Carlborg
Feb 20 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/21/2013 12:07 AM, Brad Roberts wrote:
 Hope is about the least likely to produce results (other than maybe
disappointment).  I highly encourage those with
 needs to actively help address them.  It doesn't take a lot of people to add a
lot of value.

I agree. Even fixing minor stuff is surprisingly helpful.
Feb 21 2013
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
21-Feb-2013 12:48, Rikki Cattermole пишет:
 On Thursday, 21 February 2013 at 00:57:46 UTC, H. S. Teoh wrote:
 On Thu, Feb 21, 2013 at 01:55:00AM +0100, Rob T wrote:
 On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin wrote:
 [...]
Yes. Shared Libraries Please.

Thank you.

+1 It's the most important issue for me. Particular feature bugs >can be worked around, lack of shared library support is >insurmountable for many applications.

Yes, it's a major barrier towards adoption in a production environment. Walter said it's now a priority, so I cross the fingers and hope.

Better yet, maybe more of us should start delving into DMD's code... Currently only a small number of people really understand the compiler, which has a rather low bus factor. We need to increase that (not only to improve the bus factor, but also so that more people are aware of compiler issues and hopefully how to fix them). T

of Optilink is a real pain.

Checkout this alternative linker: ftp://ftp.styx.cabel.net/pub/UniLink/ The only issue is that it converts debug info to some other format compatible with Borland's tools (TDS?).
 Couple of days ago I took a strong look at removing 64bit only code from
 Coff support and allowing it to compile 32bit.
 I failed yes.
 But I definitely will take another look into this.
 Hopefully learn wayy more of how it works!

-- Dmitry Olshansky
Feb 21 2013
prev sibling next sibling parent d coder <dlang.coder gmail.com> writes:
Cool I will try not to sleep when I catch a train next time. :-)
Feb 20 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Wednesday, 20 February 2013 at 17:52:46 UTC, Rob T wrote:
 On Wednesday, 20 February 2013 at 17:48:29 UTC, Dmitry 
 Olshansky wrote:
 It's just me sharing a positive experience.

 TL;DR I have a strong (anecdotal) evidence that D is rapidly 
 gaining popularity :)

I've noticed what looks like a large increase in the postings in D learn, which to me indicates a sudden increase in the people who are checking D out. --rt

I would say in late 2011 - early 2012 I hit more than usual talks about D in russian segment of the web, maybe it was growing that time. But D has been loosing position in Tiobe index for a year. And two other measures which I know: http://langpop.com/ and http://lang-index.sourceforge.net/ also do not give much preference to it.
Feb 20 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Wednesday, 20 February 2013 at 18:03:50 UTC, Maxim Fomin wrote:
 I would say in late 2011 - early 2012 I hit more than usual 
 talks about D in russian segment of the web, maybe it was 
 growing that time.

 But D has been loosing position in Tiobe index for a year. And 
 two other measures which I know: http://langpop.com/ and 
 http://lang-index.sourceforge.net/ also do not give much 
 preference to it.

When I fist investigated D about a year ago, I noticed that Google searches brought up more D1/Tango stuff than D2 stuff, and there seemed to be a ton of former D1/Tango activity that suddenly stopped when D2/Phobos came out. I also noted the same indexes that showed D was relatively noticeable on the charts, but then dropped almost out of sight. It was clear to me that a fight had happened and there was a split and many people had suddenly abandoned D causing the rapid drop off the charts. What may be underway is a resurgence around D2, so what we need to do is not repeat past mistakes, and do a ton of boring stuff like stabilize D2/Phobos before moving on to D3, install better processes for documentation and developing the language specifications, and of course continue to improve the release process (it still needs a real beta and stable release), etc. --rt
Feb 20 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Rob T:

 and do a ton of boring stuff like stabilize D2/Phobos before 
 moving on to D3, install better processes for documentation and 
 developing the language specifications, and of course continue 
 to improve the release process (it still needs a real beta and 
 stable release), etc.

"Stabilize" is the wrong word to use. Implementing the 64 compiler is good, implementing shared libraries is good, porting D runtime/Phobos to RISC CPUs is good, replacing the GC is good, improving the floating point management by DMD is good, and so on and on. But in my opinion what's more needed now is instead to try to complete as much as possible the design and implementation of the missing/broken/incomplete parts of the core language (like finishing const/immutable design, finishing the implementation of pure, redesigning properties, fixing trusted, doing what's possible with shared, doing what's possible to finish the inference of tags like pure in templated functions, finishing the design of packages, finishing the implementation of the module system, finishing the design of operator overloading, and so on. The complete list of broken/unfinished parts scares me). Bye, bearophile
Feb 20 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 20, 2013 at 07:42:41PM +0100, bearophile wrote:
[...]
 But in my opinion what's more needed now is instead to try to
 complete as much as possible the design and implementation of the
 missing/broken/incomplete parts of the core language (like finishing
 const/immutable design, finishing the implementation of pure,
 redesigning properties, fixing  trusted, doing what's possible with
 shared, doing what's possible to finish the inference of tags like
 pure in templated functions, finishing the design of packages,
 finishing the implementation of the module system, finishing the
 design of operator overloading, and so on. The complete list of
 broken/unfinished parts scares me).

Yeah, D already has enough features, but their interactions with each other still haven't been ironed out completely. The C/C++ inherited part of the language seems stable enough, barring a bug or two here and there. I've been writing small programs in D that I used to write in C/C++, and it's quite a pleasant experience. But once I get into the realm of new features introduced in D, like generic metaprogramming, functional-style code, non-trivial range APIs, const-correctness, purity, etc., I just keep running into bugs, unexpected interactions, conflicting designs, etc.. It can be quite frustrating at times. No doubt, a lot of stuff *does* work, but bugs / design issues are also quite frequent, which detracts a lot from one's experience of D. Sometimes I wonder if we're over-stretching ourselves with the amount of clever features in D, as Kernighan once said: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan Maybe D already has enough innovations, and now is the time to revisit what is already there and polish it up into the refined product that it should be. T -- Valentine's Day: an occasion for florists to reach into the wallets of nominal lovers in dire need of being reminded to profess their hypothetical love for their long-forgotten.
Feb 20 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 20, 2013 at 09:48:25PM +0400, Dmitry Olshansky wrote:
[...]
 In brief I was half-sleeping in a train when a young guy
 takes a seat next to me. He pulls out a laptop and powers it up.
 
 Idly wondering what I'll see this time around (HTML/JS? Python/Ruby?
 MS Word, PowerPoint?) to my surprise I notice it boots Arch linux.
 
 Cute... and then the guy starts X11 from the console... (dubious)
 with Xfce (+1 from me, though I'm with Cinnamon now).
 
 The next thing he does: fire up a terminal and Geany.
 
 Command line goes like:
 
 cd Code/D
 
 cd <some-project>
 
 git pull
 
 And then he's off furiously hacking on some GTK-based project written
 in D.  (I omit the details, though the repo is public) Actually it's
 some kind of client-server file transfer utility, alpha quality it
 seems. I even checked the repo, seems like he's involved in some tiny
 software startup.
 
 Bottom line for me this kind of thing beats TIOBE index any day of the
 week :)

Wait, wait, so you're saying, this random guy sitting next to you is, of all things, coding in D, and you didn't even have a conversation with him?! T -- Без труда не выловишь и рыбку из пруда.
Feb 20 2013
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
20-Feb-2013 23:00, H. S. Teoh пишет:
 On Wed, Feb 20, 2013 at 09:48:25PM +0400, Dmitry Olshansky wrote:
 [...]
 In brief I was half-sleeping in a train when a young guy
 takes a seat next to me. He pulls out a laptop and powers it up.

 Idly wondering what I'll see this time around (HTML/JS? Python/Ruby?
 MS Word, PowerPoint?) to my surprise I notice it boots Arch linux.

 Cute... and then the guy starts X11 from the console... (dubious)
 with Xfce (+1 from me, though I'm with Cinnamon now).

 The next thing he does: fire up a terminal and Geany.

 Command line goes like:

 cd Code/D

 cd <some-project>

 git pull

 And then he's off furiously hacking on some GTK-based project written
 in D.  (I omit the details, though the repo is public) Actually it's
 some kind of client-server file transfer utility, alpha quality it
 seems. I even checked the repo, seems like he's involved in some tiny
 software startup.

 Bottom line for me this kind of thing beats TIOBE index any day of the
 week :)

Wait, wait, so you're saying, this random guy sitting next to you is, of all things, coding in D, and you didn't even have a conversation with him?!

It felt like a dream I was afraid to break this nice illusion, only half-joking :) Seriously, it feels like I've lost an opportunity to get acquainted with the local D resistance cell. But what's the hell, my email is there in the open and the guy seems to peruse the NG (d coder?). -- Dmitry Olshansky
Feb 20 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
20-Feb-2013 23:36, Dmitry Olshansky пишет:

 But what's the hell, my email is there in
 the open and the guy seems to peruse the NG (d coder?).

Hmm... apparently was confused. Got to sleep more in trains instead of poking into somebody else laptops :) -- Dmitry Olshansky
Feb 20 2013
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
20-Feb-2013 23:52, Michael пишет:
 Wait, wait, so you're saying, this random guy sitting next to you is, of
 all things, coding in D, and you didn't even have a conversation with
 him?!

No time for explain, I will write it in D!!!

Obviously, I'm deeply indirect. This is typically bad for performance :) -- Dmitry Olshansky
Feb 20 2013
prev sibling next sibling parent d coder <dlang.coder gmail.com> writes:
On Thu, Feb 21, 2013 at 12:27 AM, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 But once I get into the realm of new features introduced in D, like
 generic metaprogramming, functional-style code, non-trivial range APIs,
 const-correctness, purity, etc., I just keep running into bugs,
 unexpected interactions, conflicting designs, etc.. It can be quite
 frustrating at times. No doubt, a lot of stuff *does* work, but bugs /
 design issues are also quite frequent, which detracts a lot from one's
 experience of D.

 Sometimes I wonder if we're over-stretching ourselves with the amount of
 clever features in D, as Kernighan once said:

         Debugging is twice as hard as writing the code in the first
         place. Therefore, if you write the code as cleverly as possible,
         you are, by definition, not smart enough to debug it. -- Brian
         W. Kernighan

 Maybe D already has enough innovations, and now is the time to revisit
 what is already there and polish it up into the refined product that it
 should be.

On that measure, the present state of D is goof. When I try something clever in metaprogramming for example, I generally hit a wall. Then I think again and usually I get a much simpler way and the D compiler too is happy with that. In a way the buggy facet of D compiler is helping me :-)
Feb 20 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Wednesday, 20 February 2013 at 18:42:42 UTC, bearophile wrote:
 Rob T:

 and do a ton of boring stuff like stabilize D2/Phobos before 
 moving on to D3, install better processes for documentation 
 and developing the language specifications, and of course 
 continue to improve the release process (it still needs a real 
 beta and stable release), etc.

"Stabilize" is the wrong word to use. Implementing the 64 compiler is good, implementing shared libraries is good, porting D runtime/Phobos to RISC CPUs is good, replacing the GC is good, improving the floating point management by DMD is good, and so on and on. But in my opinion what's more needed now is instead to try to complete as much as possible the design and implementation of the missing/broken/incomplete parts of the core language (like finishing const/immutable design, finishing the implementation of pure, redesigning properties, fixing trusted, doing what's possible with shared, doing what's possible to finish the inference of tags like pure in templated functions, finishing the design of packages, finishing the implementation of the module system, finishing the design of operator overloading, and so on. The complete list of broken/unfinished parts scares me). Bye, bearophile

Yes your additions is included in what I meant by "stabilize". We need to freeze the addition of new features for the "stable release of the language" (we currently do not have a stable release that is documented) and put it through the acid test of real world use so it can be polished up based on the feedback. It may be a good idea to create a team that concentrates only on releasing a stable version of the language and polishing it up, otherwise it will never get done. We cannot polish up an undefined moving target, it's as simple as that. --rt
Feb 20 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 Yes your additions is included in what I meant by "stabilize". 
 We need to freeze the addition of new features for the "stable 
 release of the language" (we currently do not have a stable 
 release that is documented) and put it through the acid test of 
 real world use so it can be polished up based on the feedback.

But what about the features, that should be included, but are still missing?
Feb 20 2013
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
 Wait, wait, so you're saying, this random guy sitting next to 
 you is, of
 all things, coding in D, and you didn't even have a 
 conversation with
 him?!

No time for explain, I will write it in D!!!
Feb 20 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Wednesday, 20 February 2013 at 19:49:51 UTC, Namespace wrote:
 Yes your additions is included in what I meant by "stabilize". 
 We need to freeze the addition of new features for the "stable 
 release of the language" (we currently do not have a stable 
 release that is documented) and put it through the acid test 
 of real world use so it can be polished up based on the 
 feedback.

But what about the features, that should be included, but are still missing?

Missing plus new and improved features show up in the next stable release of the language. The problem though is that we do not have a stable release of the language, nor do we even have a beta release. What we have can be described as a perpetual experimental release of the language. From what I can tell, we have enough already to document a stable release that will be useful in practical terms. Yes more features can and possibly should be added - but the desire to evolve and improve the language will always be there, so it never stops. We have to force a "stop" with an artificially imposed "stable" release. --rt
Feb 20 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Rob T:

 What we have can be described as a
 perpetual experimental release of the language.

Is it normal for a language to be in such state for so many years? Are other languages in such state? I am not intelligent (and experienced) enough to design the currently missing/broken parts of D. Is someone able to? And even if someone (or a group of persons) is in theory able to do it, is it possible to do it not changing most of the other parts of D? Bye, bearophile
Feb 20 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 21, 2013 at 12:16:08AM +0400, Dmitry Olshansky wrote:
 20-Feb-2013 23:52, Michael пишет:
Wait, wait, so you're saying, this random guy sitting next to you
is, of all things, coding in D, and you didn't even have a
conversation with him?!

No time for explain, I will write it in D!!!

Obviously, I'm deeply indirect. This is typically bad for performance :)

Yeah, too many pointer lookups. :-P T -- "Holy war is an oxymoron." -- Lazarus Long
Feb 20 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 20 Feb 2013 21:48:25 +0400
Dmitry Olshansky <dmitry.olsh gmail.com> wrote:

 [...]
 

Cool! I'm almost expecting to see someone reply here with "What a coincidence! I just had the opposite thing happen to me: I was riding a train in Russia, booted my laptop to Arch, started some D coding on a Git project all while some other D user kept watching my screen!" :)
Feb 20 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 20 February 2013 at 21:26:58 UTC, 1100110 wrote:
 On 02/20/2013 12:42 PM, bearophile wrote:
 Rob T:

 and do a ton of boring stuff like stabilize D2/Phobos before 
 moving on
 to D3, install better processes for documentation and 
 developing the
 language specifications, and of course continue to improve 
 the release
 process (it still needs a real beta and stable release), etc.

"Stabilize" is the wrong word to use. Implementing the 64 compiler is good, implementing shared libraries is good, porting D runtime/Phobos to RISC CPUs is good, replacing the GC is good, improving the floating point management by DMD is good, and so on and on. But in my opinion what's more needed now is instead to try to complete as much as possible the design and implementation of the missing/broken/incomplete parts of the core language (like finishing const/immutable design, finishing the implementation of pure, redesigning properties, fixing trusted, doing what's possible with shared, doing what's possible to finish the inference of tags like pure in templated functions, finishing the design of packages, finishing the implementation of the module system, finishing the design of operator overloading, and so on. The complete list of broken/unfinished parts scares me). Bye, bearophile

Yes. Shared Libraries Please. Thank you.

+1 It's the most important issue for me. Particular feature bugs can be worked around, lack of shared library support is insurmountable for many applications.
Feb 20 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin wrote:
[...]
 Yes. Shared Libraries Please.

 Thank you.

+1 It's the most important issue for me. Particular feature bugs can be worked around, lack of shared library support is insurmountable for many applications.

Yes, it's a major barrier towards adoption in a production environment. Walter said it's now a priority, so I cross the fingers and hope. --rt
Feb 20 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 21, 2013 at 01:55:00AM +0100, Rob T wrote:
 On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin wrote:
 [...]
Yes. Shared Libraries Please.

Thank you.

+1 It's the most important issue for me. Particular feature bugs can be worked around, lack of shared library support is insurmountable for many applications.

Yes, it's a major barrier towards adoption in a production environment. Walter said it's now a priority, so I cross the fingers and hope.

Better yet, maybe more of us should start delving into DMD's code... Currently only a small number of people really understand the compiler, which has a rather low bus factor. We need to increase that (not only to improve the bus factor, but also so that more people are aware of compiler issues and hopefully how to fix them). T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Feb 20 2013
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 2/20/2013 4:55 PM, Rob T wrote:
 On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin wrote:
 [...]
 Yes. Shared Libraries Please.

 Thank you.

+1 It's the most important issue for me. Particular feature bugs can be worked around, lack of shared library support is insurmountable for many applications.

Yes, it's a major barrier towards adoption in a production environment. Walter said it's now a priority, so I cross the fingers and hope. --rt

It's _a_ barrier for adoption in _some_ production environments. So are many other features for many other environments. It's really easy to over color the priorities based on your own use case. The community is large with lots of needs. Juggling priorities is a very grey process. Hope is about the least likely to produce results (other than maybe disappointment). I highly encourage those with needs to actively help address them. It doesn't take a lot of people to add a lot of value. My 2 cents, Brad
Feb 21 2013
prev sibling next sibling parent "Rikki Cattermole" <pbdadmin gmail.com> writes:
On Thursday, 21 February 2013 at 00:57:46 UTC, H. S. Teoh wrote:
 On Thu, Feb 21, 2013 at 01:55:00AM +0100, Rob T wrote:
 On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin 
 wrote:
 [...]
Yes. Shared Libraries Please.

Thank you.

+1 It's the most important issue for me. Particular feature bugs can be worked around, lack of shared library support is insurmountable for many applications.

Yes, it's a major barrier towards adoption in a production environment. Walter said it's now a priority, so I cross the fingers and hope.

Better yet, maybe more of us should start delving into DMD's code... Currently only a small number of people really understand the compiler, which has a rather low bus factor. We need to increase that (not only to improve the bus factor, but also so that more people are aware of compiler issues and hopefully how to fix them). T

usage of Optilink is a real pain. Couple of days ago I took a strong look at removing 64bit only code from Coff support and allowing it to compile 32bit. I failed yes. But I definitely will take another look into this. Hopefully learn wayy more of how it works!
Feb 21 2013
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Thursday, 21 February 2013 at 01:50:27 UTC, 1100110 wrote:
 I was playing with LuaD (https://github.com/JakobOvrum/LuaD) 
 and was disappointed to learn that the only way to call D 
 functions from Lua is for the lua code to be 'inside' a D 
 module. (string l = "lua goes here"; or similar)

I don't understand "inside a D module" void someFun(string content) { ... } lua["someFun"] = &someFun; lua.doFile("SomeFileName.lua");
Feb 21 2013
prev sibling next sibling parent "Rikki Cattermole" <pbdadmin gmail.com> writes:
On Thursday, 21 February 2013 at 17:02:06 UTC, Dmitry Olshansky 
wrote:
 21-Feb-2013 12:48, Rikki Cattermole пишет:
 On Thursday, 21 February 2013 at 00:57:46 UTC, H. S. Teoh 
 wrote:
 On Thu, Feb 21, 2013 at 01:55:00AM +0100, Rob T wrote:
 On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin 
 wrote:
 [...]
Yes. Shared Libraries Please.

Thank you.

+1 It's the most important issue for me. Particular feature bugs >can be worked around, lack of shared library support is
insurmountable


Yes, it's a major barrier towards adoption in a production environment. Walter said it's now a priority, so I cross the fingers and hope.

Better yet, maybe more of us should start delving into DMD's code... Currently only a small number of people really understand the compiler, which has a rather low bus factor. We need to increase that (not only to improve the bus factor, but also so that more people are aware of compiler issues and hopefully how to fix them). T

the usage of Optilink is a real pain.

Checkout this alternative linker: ftp://ftp.styx.cabel.net/pub/UniLink/ The only issue is that it converts debug info to some other format compatible with Borland's tools (TDS?).
 Couple of days ago I took a strong look at removing 64bit only 
 code from
 Coff support and allowing it to compile 32bit.
 I failed yes.
 But I definitely will take another look into this.
 Hopefully learn wayy more of how it works!


Been there tried that. Wasn't terribly happy with it. The removal of 64bit code generation in coff format isn't a killer for me. But it does make it harder. I can make do without it as I really only want my apps to be running on newer i5+ gear. Its more of something to learn the compiler and help the community out a bit. Since I know that there will be others that would think this is a killer for not using D.
Feb 21 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 20 February 2013 at 21:05:42 UTC, bearophile wrote:
 I am not intelligent (and experienced) enough to design the 
 currently missing/broken parts of D. Is someone able to?

If one writes a short description of problems, then it will be easier to find people and ideas. For example, I have no clue what's wrong with `shared`.
Feb 22 2013
prev sibling parent "Rob T" <alanb ucora.com> writes:
On Thursday, 21 February 2013 at 08:07:34 UTC, Brad Roberts wrote:
 On 2/20/2013 4:55 PM, Rob T wrote:
 Yes, it's a major barrier towards adoption in a production 
 environment. Walter said it's now a priority, so I cross the
 fingers and hope.
 
 --rt

It's _a_ barrier for adoption in _some_ production environments. So are many other features for many other environments. It's really easy to over color the priorities based on your own use case. The community is large with lots of needs. Juggling priorities is a very grey process.

I think there's a lot more to it than that. For example, if D supported shared libs that can be integrated with C/C++ code then adoption in a production environment becomes much less risky and much more practical. For example, instead of recoding an entire C++ app in D, one could instead include a shared lib that adds on functionality. Shared libs provide a means to migrate into D without the all or nothing approach, and that what is currently one of the major barriers towards adoption.
 Hope is about the least likely to produce results (other than 
 maybe disappointment).  I highly encourage those with
 needs to actively help address them.  It doesn't take a lot of 
 people to add a lot of value.

 My 2 cents,
 Brad

I agree, and I have tried to help in small ways. I'll try and do more when I can and as I learn more. --rt
Feb 23 2013