www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - End user experience with D

reply "Ludovit Lucenic" <llucenic gmail.com> writes:
Hello everybody,

I read this very lively Manu's thread (Had another 48hr game jam 
this weekend..., 
http://forum.dlang.org/thread/mailman.680.1378001151.1719.digitalm
rs-d puremagic.com) 
and am about to share my own D experience as someone who 
discovered D less than a year ago looking for a useful 
alternative to nowadays standards.

I'd like to point out that the thoughts I write here form an 
essay rather than some well structured discussion contribution. 
However, please read on and you may find it interesting after all.

Imagine someone (a developer/programmer or a software engineer) 
being in a search for something that is more appropriate to 
address his professional needs. Someone who do this on his own, 
is genuinely interested in software science, has something to 
offer and who understands the corporate motivations behind all 
the fancy languages/frameworks (most of which are not free/libre 
software at all) that have all the design-shortcomings that are 
20+ years old. And (in contrast with corporate attitude) someone 
who as a human being seeks inner fulfilment in exchange of mutual 
respect, results, in learning and support.

But from the beginning. In my most recent job I lead development 
of a platform that enables better software design using a 
complete new approach (or paradigm) based on encapsulating 
software components into so called configurations or 
configuration patterns, while having all the OOP-like features as 
inheritance, polymorphism etc. in this (configuration) dimension 
as well. The inventor of the idea behind this concept had found 
investors that make an effort to make big business out of this 
here in Slovakia. I feel lucky I have had this opportunity of 
being a part of this endeavour since its to-mature phase. But as 
the time passed by I realized I felt tired of being in restraint 
of the fear of "the idea cannot leak or even losing the platform 
implementation" that was constantly imprinted upon us. As such, 
it had many impacts on our proficiency as software engineers. So 
I quit this job.

A couple of months before I have decided to resign I had tried to 
prove the concept of what we've been dealing with in the company 
in some technology other than Java and its servlets engine. I 
studied the current possibilities and that was the point I came 
to know D. I ever thought that some lower level approach, no VMs 
and some language constructs would outperform the implementation 
of this 'code the architecture with software component 
configurations' concept in Java we had, though it was a decent 
one.

To explain a little more on how my intention relates to D, I dare 
to claim that this new paradigm has potential of becoming next 
standard in software architecture design. Especially for larger 
projects. It will definitively address at least two of the three 
major goals of D Walter spoke about in his DConf intro talk this 
year: large scale project support (in this case: on architectural 
level) and the performance D would lend to this paradigm would 
ensure industry quality of modern systems.

After reading Andrei's book I sat down to computer and it took me 
about 5 man-days to design and program this concept in D. No 
previous experience with D at all. Technically, it was about an 
engine interpreting tree (stored e.g. in XML), where the target 
software application had stored its architecture. Polymorphism, 
hierarchy and everything on level of configuration patterns. 
Awesome. Actually this experience contributed to my ultimate 
decision on quitting :-) Walter et al., please be aware of how 
your work does change people's careers and lives :-D

To get that far I needed a web server in D. Technically, it was 
not necessary, but it might had been convenient as I was 
accustomed to the web interface for this platform. I have read 
everything that was at hand at that time and ended up with that 
only Mango would suite my needs the best. It 'just' needed to 
port it from D1 to D2. Somehow neither Adam D. Ruppe's web stuff 
nor vibe.d server were not able to target my intention to have 
latest D2 compiler support (Dec 2012/Jan 2013) and so did 
anything else I might have found. The mission also was to compile 
the tango on my Ubuntu, than to port and compile mango, link it 
with tango, create my own project and compile and link it with 
these libraries. While doing this I came across all the notorious 
in the community: dead dsource.org, only D1 version of majority 
of D code I could use, phobos vs. tango incompatibility and so 
on... Real pain that substituted the initial enthusiasm I felt 
almost instantly about D as a software engineer by heart. But my 
conviction to go on was stronger...

The first thing before I get into coding in D was desperately 
looking for an IDE. From my experience, Eclipse and Visual Studio 
have learned me to such comfort. In this case though it was not 
only about the comfort. The concept rely on some higher level of 
abstraction that even takes time to visualize in mind, not 
speaking about track in the code without using decoded memory. 
Getting 0x00FE67ED in debugger instead of a dynamic class 
instance with some details on some interface parameter or local 
variable, not speaking of global variables is just no-go.
I had three computers at my disposal at that time, two with 
Ubuntu and one with Windows 7, later upgraded to 8. I tried 
everything I found: Code::Blocks plugin, DDT, VisualD, Mono-D and 
maybe some others. I was looking for an eclipse-like debugging 
experience the people familiar with Java have. Desperately: 
WinDBG, Mago, Visual Studio Debugger, MonoDevelop.Debugger.GDB, 
CLI of GDB. No way except for DIY.

In order to at least finish my proof-of-concept project I chose 
Mono-D and contacted Alexander Bothe asking him for support in 
assistance with building a GDB add-in for MonoDevelop that would 
support D (I mean useful support, not the declared one in GDB 
announcements). The results of the joint effort, by the way, is 
at my GitHub 
(https://github.com/llucenic/MonoDevelop.Debugger.Gdb.D). I 
recently started a new job, where I am to switch to Windows 
platform (please keep this in mind ! people may change the 
platform along the career roads, even if their preference stays 
the same - free software in my case). After, it took me a while 
until I managed to update the Gdb.D Mono-D add-in in order to be 
used in a Xamarin Studio (MonoDevelop successor) along with 
Mono-D on Windows. When I got that far I came to the point that 
DMD on Windows does not generate debug info that GDB can read and 
make use of. So I started to get working executable of GDC and/or 
LDC as alternatives that should be (at least in theory) capable 
of cooperation with GDB on Windows. None of these efforts have 
been successful so far, the details of which we discuss in GDC 
and LDC forums respectively.

All in all, to sum things up I list all my fundamental show 
stoppers so far:
  1) only D1 version of majority of D code I could use, phobos vs. 
tango incompatibility, ... (valid for January 2013)
  2) missing IDE - comfort and primarily handling higher level 
abstraction necessity,
  3) debugger not capable of basic memory interpretation - as 
said, interface/class instances visualized just as memory address,
  4) GDB not working with DMD on Windows,
  5) not able to compile GDC on Windows,
  6) LDC complaining a lot of linkage errors when integrated in 
Xamarin Studio (with Mono-D) on Windows (not tried on Unix)

I am addressing these issues on their respective forums in 
particular, just need comment on the show stopper number 4. Why 
is it not possible, or what would it take to support GDB debug 
info format in DMD back-end on Windows ?

These issues are basically hindering me immensely in achieving my 
ultimate goal, which I think may contribute essentially to the D 
coming up.
I am enthusiastic about D, but I cannot estimate how long it will 
take until all this confusion and obstacles roll over me :-)
Hope it never happens, but I will definitively need a lot of 
support and help with making my intention reality.

After all, I consider this D community is pretty much about 
philosophy. I value highly (actually, one of my major reasons to 
go for D) Walter's motivation on creating a language out of love. 
Although, there surely is some pragmatic aspect in all this as 
well. And this makes D so special (at least for me).
When we get older, at some time we are going to pose the 
question: 'Did it all make sense ?" I guess with this language we 
say: 'it Did'

I wish you found this posting at least of some value.
Thank you for your time.

Kind regards,
Ludovit
Sep 01 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 1 September 2013 at 20:47:56 UTC, Ludovit Lucenic 
wrote:

 Somehow neither Adam D. Ruppe's web stuff nor vibe.d server 
 were not able to target my intention to have latest D2 compiler 
 support (Dec 2012/Jan 2013)


Do you remember exactly what it was? I often skip every other dmd 
release so if it was blah is deprecated that's probably what it 
was.
Sep 01 2013
next sibling parent reply "Ludovit Lucenic" <llucenic gmail.com> writes:
On Sunday, 1 September 2013 at 21:27:56 UTC, Adam D. Ruppe wrote:

 On Sunday, 1 September 2013 at 20:47:56 UTC, Ludovit Lucenic 
 wrote:

 Somehow neither Adam D. Ruppe's web stuff nor vibe.d server 
 were not able to target my intention to have latest D2 
 compiler support (Dec 2012/Jan 2013)


 Do you remember exactly what it was? I often skip every other 
 dmd release so if it was blah is deprecated that's probably 
 what it was.


Sorry, Adam, for not being maybe completely explicit on that
statement. Unfortunately, I cannot recall the exact problem with
the usage of your code.
But the feeling I recall (which still persists) is that your code
did not what I needed/wished to have, not that it would do things
wrong that it did.

My intention was not to criticize anything. I wanted to share the
impressions, enthusiasm, pains, obstacles and winnings I achieved
while I was doing my research. Let everybody create his/her own
opinion. And maybe someone gets inspired to move things further
at least in one of the areas I mentioned :-)

Ludovit
Sep 02 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 2 September 2013 at 07:22:31 UTC, Ludovit Lucenic 
wrote:

 But the feeling I recall (which still persists) is that your 
 code did not what I needed/wished to have, not that it would do 
 things wrong that it did.


Yeah, I often write just what I need and then leave it at that.

But if you ever have feature requests, I might be able to add it 
if I'm not too busy with other stuff/it isn't too hard for me to 
slap together.
Sep 02 2013
parent "Ludovit Lucenic" <llucenic gmail.com> writes:
On Monday, 2 September 2013 at 13:30:07 UTC, Adam D. Ruppe wrote:

 On Monday, 2 September 2013 at 07:22:31 UTC, Ludovit Lucenic 
 wrote:

 But the feeling I recall (which still persists) is that your 
 code did not what I needed/wished to have, not that it would 
 do things wrong that it did.


 Yeah, I often write just what I need and then leave it at that.

 But if you ever have feature requests, I might be able to add 
 it if I'm not too busy with other stuff/it isn't too hard for 
 me to slap together.


Thank you very much for your willingness. I appreciate that a lot.
I reconsider using some of your code later when I fix my 
debugging problems.
The mango library (at least the necessary part of it) I ported to 
D2 might have become corrupted by me doing the remedy engineer 
with little-to-no D experience :-) I don't trust this ported 
mango code that much... So, there's a big probability I let you 
know someday.

Ludovit
Sep 02 2013
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 1 September 2013 at 21:27:56 UTC, Adam D. Ruppe wrote:

 On Sunday, 1 September 2013 at 20:47:56 UTC, Ludovit Lucenic 
 wrote:

 Somehow neither Adam D. Ruppe's web stuff nor vibe.d server 
 were not able to target my intention to have latest D2 
 compiler support (Dec 2012/Jan 2013)


 Do you remember exactly what it was? I often skip every other 
 dmd release so if it was blah is deprecated that's probably 
 what it was.


Same question applies to vibe.d - I have been working on it quite 
intensively somewhere around Jan/Feb 2013 and am extremely 
surprised to hear any issues of that kind have existed. Most 
frustrating type of a problem is the one that never gets reported 
upstream.
Sep 02 2013
parent reply "Ludovit Lucenic" <llucenic gmail.com> writes:
On Monday, 2 September 2013 at 12:14:30 UTC, Dicebot wrote:

 On Sunday, 1 September 2013 at 21:27:56 UTC, Adam D. Ruppe 
 wrote:

 On Sunday, 1 September 2013 at 20:47:56 UTC, Ludovit Lucenic 
 wrote:

 Somehow neither Adam D. Ruppe's web stuff nor vibe.d server 
 were not able to target my intention to have latest D2 
 compiler support (Dec 2012/Jan 2013)


 Do you remember exactly what it was? I often skip every other 
 dmd release so if it was blah is deprecated that's probably 
 what it was.


 Same question applies to vibe.d - I have been working on it 
 quite intensively somewhere around Jan/Feb 2013 and am 
 extremely surprised to hear any issues of that kind have 
 existed. Most frustrating type of a problem is the one that 
 never gets reported upstream.


The words I chose were rather confusing. I am sorry for that. I 
meant that vibe.d offered me something I could not really use 
because I was looking for something else. I wanted a standalone 
server that would offer some kind of 'servlet' configuration and 
I wanted to generate the output page on my very own. I found that 
vibe.d offers some kind of "template processing" engine and that 
really has not fit my need.
Thank you for your comment and once again, sorry for that 
confusion.

Ludovit
Sep 02 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 2 September 2013 at 13:30:38 UTC, Ludovit Lucenic 
wrote:

 Same question applies to vibe.d - I have been working on it 
 quite intensively somewhere around Jan/Feb 2013 and am 
 extremely surprised to hear any issues of that kind have 
 existed. Most frustrating type of a problem is the one that 
 never gets reported upstream.


 The words I chose were rather confusing. I am sorry for that. I 
 meant that vibe.d offered me something I could not really use 
 because I was looking for something else. I wanted a standalone 
 server that would offer some kind of 'servlet' configuration 
 and I wanted to generate the output page on my very own. I 
 found that vibe.d offers some kind of "template processing" 
 engine and that really has not fit my need.
 Thank you for your comment and once again, sorry for that 
 confusion.


Oh, for a moment I thought you had issues with vibe.d not 
supporting latest dmd version.

Anyway, if you have contacted devs you may have been pleasantly 
surprised :) For example, template processing engine your are 
speaking about (Diet) is an additional feature and not required 
at all. You can have request handlers that generate HTTP bodies 
manually and even have request handlers that render raw TCP.

And even if something wasn't supported, asking about it have had 
a good chance to make it implemented pretty fast :)

You're welcome.
Sep 02 2013
parent reply "Ludovit Lucenic" <llucenic gmail.com> writes:
On Monday, 2 September 2013 at 13:40:49 UTC, Dicebot wrote:

 On Monday, 2 September 2013 at 13:30:38 UTC, Ludovit Lucenic 
 wrote:

 Same question applies to vibe.d - I have been working on it 
 quite intensively somewhere around Jan/Feb 2013 and am 
 extremely surprised to hear any issues of that kind have 
 existed. Most frustrating type of a problem is the one that 
 never gets reported upstream.


 The words I chose were rather confusing. I am sorry for that. 
 I meant that vibe.d offered me something I could not really 
 use because I was looking for something else. I wanted a 
 standalone server that would offer some kind of 'servlet' 
 configuration and I wanted to generate the output page on my 
 very own. I found that vibe.d offers some kind of "template 
 processing" engine and that really has not fit my need.
 Thank you for your comment and once again, sorry for that 
 confusion.


 Oh, for a moment I thought you had issues with vibe.d not 
 supporting latest dmd version.

 Anyway, if you have contacted devs you may have been pleasantly 
 surprised :) For example, template processing engine your are 
 speaking about (Diet) is an additional feature and not required 
 at all. You can have request handlers that generate HTTP bodies 
 manually and even have request handlers that render raw TCP.

 And even if something wasn't supported, asking about it have 
 had a good chance to make it implemented pretty fast :)

 You're welcome.


Thank you, Dicebot.

I may reconsider inspecting the vibe.d code as well :-D
Pleasant surprises I like the most. I guess I could not find the 
things you write about from the documentation. May be my fault, 
may be one of its.

But to the point. I guess we come together to the core of my 
posting and that is: however a newbie comes to the D to try it 
out, things mostly do not work out of the box. I wanted to do 
_my_ job and I have had hard time to figure out what tools, what 
already made code to use, how to reuse tango/mango, etc...
I mean, the D is worth it, therefore I hang around even after the 
months.
But in order to implement my intention, I am struggling all over 
again and again with what does not work for me in a 
'find-download-install-learn-reuse' way. I would have been at 
least two months ahead with my project by now.

I found only today, that there is something like 
http://code.dlang.org ! Looks perfect, why have not I come 
accross this site already ? Well, that's the question.

Ludovit
Sep 02 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/2/13 7:00 AM, Ludovit Lucenic wrote:

 I found only today, that there is something like http://code.dlang.org !
 Looks perfect, why have not I come accross this site already ? Well,
 that's the question.


I wanted to make sure it's stable before we announce it more broadly. 
Maybe that time has come.

Andrei
Sep 03 2013
parent "Ludovit Lucenic" <llucenic gmail.com> writes:
On Tuesday, 3 September 2013 at 16:12:13 UTC, Andrei Alexandrescu 
wrote:

 On 9/2/13 7:00 AM, Ludovit Lucenic wrote:

 I found only today, that there is something like 
 http://code.dlang.org !
 Looks perfect, why have not I come accross this site already ? 
 Well,
 that's the question.


 I wanted to make sure it's stable before we announce it more 
 broadly. Maybe that time has come.

 Andrei


Andrei,
:-D sometimes I have troubles being not too patient...

It's just pity there's so much valuable D stuff all over the 
place, but not a single go-to-point to find out. I would 
recommend elaborated concepts, alphas, betas, release candidates, 
everything be on the Wiki (with the status declared loudly, of 
course). It might help people to join efforts from the very 
beginning of their respective projects, not for example three or 
four half-working web servers ;-) Actually this is a point I 
decribed in this thread. New people just have to overcome huge 
'uncertainty' to become daptized so to speak (a word play on 
baptized by D).

Regards,
Ludovit

p.s. folks, have you ever noticed the :-D smiley having two 
beautiful connotations in the context of D community ;-)
Sep 03 2013
prev sibling next sibling parent reply "Ramon" <spam thanks.no> writes:
Ludovit Lucenic

For the IDE and GDB issues I fully agree. And I'add less than 
comfortable (~"semi automatic"; from what I know) C library 
bindings.

While one may discuss about IDE or cli, I feel that an IDE is at 
least an immensely helpful starting point.
I agree that one should be able to do programming with no more 
than a simple editor, a compiler/linker, and a debugger (!). 
Newcomers, however, (and even many seasoned programmers) handily 
profit from an IDE (and I don't mean Eclipse which I count as a 
moloch that, to make things worse, is based on java).

I also feel that any modern language just *must* have a 
comfortable way to use C libraries.

Finally and possibly most importantly, basically not having fully 
working  debugger support is a very serious lack. I may be wrong 
(actually I hope to be wrong) but from what I know, this issue 
doesn't seem to be seen as having very high priority.

I'm more and more getting the impression that D could be a 
programmers dreams come true if only it were practically and 
productively useable. Sure, it's not D's fault. But in the end we 
need a fully working debugger, some good editor support (say, on 
a Scintilla/Scite level), preferably at least one cross platform 
non-java IDE (like Code:Blocks) and easy access to C libraries in 
order to actually and productively work with a language.

D's bias toward Windows doesn't help either.

Looking at it from a marketing perspective, i.e. looking for what 
potential users (read: "the large crowd out there") would look 
for, I see that the creators of D have done an excellent job 
that, however reminds of a Porsche engine on a makeshift chassis.

Frankly, if we want D to attract developers and to get the 
position it undoubtedly deserves that will not be achieved so 
much by finetuning D or even phobos but by being able to offer a 
well-rounded and well useable package (and soon after good docs 
for what we have so far).

A+ -R
Sep 01 2013
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Sunday, 1 September 2013 at 22:21:10 UTC, Ramon wrote:

 D's bias toward Windows doesn't help either.


Did you mean against? I've found D to be much nicer on Linux.
Sep 01 2013
parent "Ramon" <spam thanks.no> writes:
On Sunday, 1 September 2013 at 22:27:43 UTC, Brian Schott wrote:

 On Sunday, 1 September 2013 at 22:21:10 UTC, Ramon wrote:

 D's bias toward Windows doesn't help either.


 Did you mean against? I've found D to be much nicer on Linux.


Well, I can't comment on Windoze as I avoid it like the plague. 
But I'm under the impression (basically from reading here in the 
forum and looking at D related tools, IDEs, etc) that there is a 
certain bias toward Windows.

Which would be OK as most users (?) seem to work on Windoze *if* 
D marketed itself as a language for Windows.

As for linux, yes, you are right. I didn't experience any 
problems with DMD itself. Installed like a charm, worked like a 
charm.

But: I remember my first days and the conditio sine qua non that 
there are tools for linux, too. Well, there seems to ... yet, I'm 
still unable to reasonably debug. which, from what I saw/read 
seems to be a problem on the D side.

A+ -R
Sep 01 2013
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 1 September 2013 at 22:21:10 UTC, Ramon wrote:

 Finally and possibly most importantly, basically not having 
 fully working  debugger support is a very serious lack.


Maybe it is because I write 100% bug free code the first time 
every time ( :-) ) but I've found the gdb support, at least on 
Linux, to be really pretty good.

I compile with -gc -debug - the "pretend to be C" option is 
something I started doing years ago and might not be necessary 
anymore, but I've found it to be plenty good enough anyway.


 D's bias toward Windows doesn't help either.


If anything, I don't think D goes far enough in its Windows 
support. It works well there, sure, even the optlink things 
others complain about don't bother me, but there's a lot of stuff 
it could easily do and doesn't, at least not without grabbing 
additional downloads.

On Linux, dmd works quite excellently, as do gdc and ldc.
Sep 01 2013
next sibling parent reply "Ramon" <spam thanks.no> writes:
On Sunday, 1 September 2013 at 23:22:30 UTC, Adam D. Ruppe wrote:

 On Sunday, 1 September 2013 at 22:21:10 UTC, Ramon wrote:

 Finally and possibly most importantly, basically not having 
 fully working  debugger support is a very serious lack.


 Maybe it is because I write 100% bug free code the first time 
 every time ( :-) ) but I've found the gdb support, at least on 
 Linux, to be really pretty good.

 I compile with -gc -debug - the "pretend to be C" option is 
 something I started doing years ago and might not be necessary 
 anymore, but I've found it to be plenty good enough anyway.


 D's bias toward Windows doesn't help either.


 If anything, I don't think D goes far enough in its Windows 
 support. It works well there, sure, even the optlink things 
 others complain about don't bother me, but there's a lot of 
 stuff it could easily do and doesn't, at least not without 
 grabbing additional downloads.

 On Linux, dmd works quite excellently, as do gdc and ldc.


-gc? Hmmm ... I'll try that. Thanks for the tip ;)

For the rest: Frankly, I'm not even sure, I should follow that 
kind of discussion (like in Manu's thread) anymore. I don't mean 
to offend someone but it strikes me as ... uhm ... brains not 
used at their full power ... when "there is no really properly 
and fully working IDE" (which is pretty close to a killer for 
many) gt thrown in - and seriously - discussed with stuff like 
"nenene, in Windows Visual Blah 2010 it worked and now 
Intellisense works only with handish settings, nenene".
Even worse, while I'm still hoping for a promising statement by a 
heavy-weight like e.g. W. Bright along the line "Yep, we really, 
seriously need some working cross platform IDE, preferably an 
easy to install one" ... one seems quite happy to seriously 
adress nitty-bitties for Windows Whatever 2012 (c) (tm) $$$.

Maybe perfection must be three, the catholic way, a triplet. 
Maybe we need another incarnation of Andrei A. (who brought great 
stuff to D) but this third guy bringing good useabilty to D.
Sep 01 2013
next sibling parent reply Peter Williams <pwil3058 bigpond.net.au> writes:
On 02/09/13 09:36, Ramon wrote:

 On Sunday, 1 September 2013 at 23:22:30 UTC, Adam D. Ruppe wrote:

 On Sunday, 1 September 2013 at 22:21:10 UTC, Ramon wrote:

 Finally and possibly most importantly, basically not having fully
 working  debugger support is a very serious lack.


 Maybe it is because I write 100% bug free code the first time every
 time ( :-) ) but I've found the gdb support, at least on Linux, to be
 really pretty good.

 I compile with -gc -debug - the "pretend to be C" option is something
 I started doing years ago and might not be necessary anymore, but I've
 found it to be plenty good enough anyway.


 D's bias toward Windows doesn't help either.


 If anything, I don't think D goes far enough in its Windows support.
 It works well there, sure, even the optlink things others complain
 about don't bother me, but there's a lot of stuff it could easily do
 and doesn't, at least not without grabbing additional downloads.

 On Linux, dmd works quite excellently, as do gdc and ldc.


 -gc? Hmmm ... I'll try that. Thanks for the tip ;)

 For the rest: Frankly, I'm not even sure, I should follow that kind of
 discussion (like in Manu's thread) anymore. I don't mean to offend
 someone but it strikes me as ... uhm ... brains not used at their full
 power ... when "there is no really properly and fully working IDE"
 (which is pretty close to a killer for many) gt thrown in - and
 seriously - discussed with stuff like "nenene, in Windows Visual Blah
 2010 it worked and now Intellisense works only with handish settings,
 nenene".
 Even worse, while I'm still hoping for a promising statement by a
 heavy-weight like e.g. W. Bright along the line "Yep, we really,
 seriously need some working cross platform IDE, preferably an easy to
 install one" ... one seems quite happy to seriously adress nitty-bitties
 for Windows Whatever 2012 (c) (tm) $$$.

 Maybe perfection must be three, the catholic way, a triplet. Maybe we
 need another incarnation of Andrei A. (who brought great stuff to D) but
 this third guy bringing good useabilty to D.


IMHO, the IDE should only be a wrapper around the core functionality and 
never be so closely integrated that the core is unusable without the 
IDE.  Personally, I just like using a configurable editor (e.g.  Geany, 
emacs and so on) which knows (or can be taught) how to do various useful 
things that an IDE might offer.

If you want an IDE then create one but make it an "add on" and don't 
expect everyone to use it.

Cheers
Peter
PS I especially hate IDEs that try to force me to create "projects".
PPS I especially like IDEs that have built in terminal editors so that 
you can do command line stuff without the need for a separate window.
Sep 01 2013
parent reply "Ramon" <spam thanks.no> writes:
On Monday, 2 September 2013 at 04:00:37 UTC, Peter Williams wrote:

 IMHO, the IDE should only be a wrapper around the core 
 functionality and never be so closely integrated that the core 
 is unusable without the IDE.  Personally, I just like using a 
 configurable editor (e.g.  Geany, emacs and so on) which knows 
 (or can be taught) how to do various useful things that an IDE 
 might offer.

 If you want an IDE then create one but make it an "add on" and 
 don't expect everyone to use it.

 Cheers
 Peter
 PS I especially hate IDEs that try to force me to create 
 "projects".
 PPS I especially like IDEs that have built in terminal editors 
 so that you can do command line stuff without the need for a 
 separate window.


I perfectly agree. An IDE should be optional - but it should
exist.

And btw: With IDE I don't necessarily mean a fully blown Eclipse
like thing. A smart developer oriented editor (like Geany) with a
reasonable interface to a *working* debugger is good enough.
Sep 01 2013
parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 02/09/13 14:12, Ramon wrote:

 On Monday, 2 September 2013 at 04:00:37 UTC, Peter Williams wrote:

 IMHO, the IDE should only be a wrapper around the core functionality
 and never be so closely integrated that the core is unusable without
 the IDE.  Personally, I just like using a configurable editor (e.g.
 Geany, emacs and so on) which knows (or can be taught) how to do
 various useful things that an IDE might offer.

 If you want an IDE then create one but make it an "add on" and don't
 expect everyone to use it.

 Cheers
 Peter
 PS I especially hate IDEs that try to force me to create "projects".
 PPS I especially like IDEs that have built in terminal editors so that
 you can do command line stuff without the need for a separate window.


 I perfectly agree. An IDE should be optional - but it should
 exist.


OK, but why are you putting the onus on Walter to create it.  He's 
looking after the core technology and probably has enough to do already. 
  Surely someone (such as you) who wants an IDE should be the person to 
create it.


 And btw: With IDE I don't necessarily mean a fully blown Eclipse
 like thing. A smart developer oriented editor (like Geany) with a
 reasonable interface to a *working* debugger is good enough.


I agree there.  I tried to use Eclipse way back when it first came out 
and it was already to complicated (and too Java centric) for my taste. 
If I recall correctly it was also one of those that insisted on 
"projects" and all source files in its own directory tree.

Peter
PS I too like GUIs for doing some things and if there isn't one 
available (that suits my way of working) I knock one up myself using a 
PyGTK wrapper around the command line interface (e.g. gquilt and gwsmhg 
for quilt and Mercurial respectively) and when it's working I make it 
public just in case it scratches someone else's itch.
Sep 01 2013
prev sibling parent "Ludovit Lucenic" <llucenic gmail.com> writes:
On Sunday, 1 September 2013 at 23:36:11 UTC, Ramon wrote:

 On Sunday, 1 September 2013 at 23:22:30 UTC, Adam D. Ruppe 
 wrote:

 On Sunday, 1 September 2013 at 22:21:10 UTC, Ramon wrote:

 Finally and possibly most importantly, basically not having 
 fully working  debugger support is a very serious lack.


 Maybe it is because I write 100% bug free code the first time 
 every time ( :-) ) but I've found the gdb support, at least on 
 Linux, to be really pretty good.

 I compile with -gc -debug - the "pretend to be C" option is 
 something I started doing years ago and might not be necessary 
 anymore, but I've found it to be plenty good enough anyway.


 D's bias toward Windows doesn't help either.


 If anything, I don't think D goes far enough in its Windows 
 support. It works well there, sure, even the optlink things 
 others complain about don't bother me, but there's a lot of 
 stuff it could easily do and doesn't, at least not without 
 grabbing additional downloads.

 On Linux, dmd works quite excellently, as do gdc and ldc.


 -gc? Hmmm ... I'll try that. Thanks for the tip ;)

 For the rest: Frankly, I'm not even sure, I should follow that 
 kind of discussion (like in Manu's thread) anymore. I don't 
 mean to offend someone but it strikes me as ... uhm ... brains 
 not used at their full power ... when "there is no really 
 properly and fully working IDE" (which is pretty close to a 
 killer for many) gt thrown in - and seriously - discussed with 
 stuff like "nenene, in Windows Visual Blah 2010 it worked and 
 now Intellisense works only with handish settings, nenene".
 Even worse, while I'm still hoping for a promising statement by 
 a heavy-weight like e.g. W. Bright along the line "Yep, we 
 really, seriously need some working cross platform IDE, 
 preferably an easy to install one" ... one seems quite happy to 
 seriously adress nitty-bitties for Windows Whatever 2012 (c) 
 (tm) $$$.

 Maybe perfection must be three, the catholic way, a triplet. 
 Maybe we need another incarnation of Andrei A. (who brought 
 great stuff to D) but this third guy bringing good useabilty to 
 D.


A 'D usability roadmap' defined from within the community would
make things definitively easier and better to follow.
Sep 02 2013
prev sibling next sibling parent reply "Ludovit Lucenic" <llucenic gmail.com> writes:
On Sunday, 1 September 2013 at 23:22:30 UTC, Adam D. Ruppe wrote:

 On Sunday, 1 September 2013 at 22:21:10 UTC, Ramon wrote:

 Finally and possibly most importantly, basically not having 
 fully working  debugger support is a very serious lack.


 Maybe it is because I write 100% bug free code the first time 
 every time ( :-) ) but I've found the gdb support, at least on 
 Linux, to be really pretty good.


You don't mean it, do you ? :-D


 I compile with -gc -debug - the "pretend to be C" option is 
 something I started doing years ago and might not be necessary 
 anymore, but I've found it to be plenty good enough anyway.


 D's bias toward Windows doesn't help either.


 If anything, I don't think D goes far enough in its Windows 
 support. It works well there, sure, even the optlink things 
 others complain about don't bother me, but there's a lot of 
 stuff it could easily do and doesn't, at least not without 
 grabbing additional downloads.

 On Linux, dmd works quite excellently, as do gdc and ldc.


I wish we could say the same for them running on Windows...
Sep 02 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 2 September 2013 at 07:52:09 UTC, Ludovit Lucenic 
wrote:

 You don't mean it, do you ? :-D


I don't use a debugger too often, I actually prefer to do asserts 
(and then, when possible, leave them there after the debugging is 
finished) and printf stuff.

But when I do use gdb, I don't have big problems with it. For me 
at least, the stack trace works with file and line numbers, 
disassembly and register dumping works, breakpoints work, getting 
variable contents usually (but not always) works.

So I just generally find it good enough.


 I wish we could say the same for them running on Windows...


Aye.
Sep 02 2013
parent "Ludovit Lucenic" <llucenic gmail.com> writes:
On Monday, 2 September 2013 at 13:33:29 UTC, Adam D. Ruppe wrote:

 On Monday, 2 September 2013 at 07:52:09 UTC, Ludovit Lucenic 
 wrote:

 You don't mean it, do you ? :-D


 I don't use a debugger too often, I actually prefer to do 
 asserts (and then, when possible, leave them there after the 
 debugging is finished) and printf stuff.

 But when I do use gdb, I don't have big problems with it. For 
 me at least, the stack trace works with file and line numbers, 
 disassembly and register dumping works, breakpoints work, 
 getting variable contents usually (but not always) works.

 So I just generally find it good enough.


 I wish we could say the same for them running on Windows...


 Aye.


Adam, I totally agree with you except for the point on "getting 
variable contents usually (but not always) works". In my case 
this point barely worked. Maybe I did something wrong or used 
older version of GDB (which I don't think was the case). Anyway, 
to comfortably browse the variables'/parameters'/globals' in 
memory while debugging I had to start working on something like 
Gdb.D for Mono-D (mentioned earlier). GDB alone was not giving me 
even the least help in this memory examination. I mean, write a 
code where you have classes, interfaces, you passed variables 
like this to functions and put a breakpoint in such a function. I 
always got 0x0012F64E and such values out of GDB...

Ludovit
Sep 02 2013
prev sibling parent reply "Paolo Invernizzi" <paolo.invernizzi gmail.com> writes:
On Sunday, 1 September 2013 at 23:22:30 UTC, Adam D. Ruppe wrote:

 On Sunday, 1 September 2013 at 22:21:10 UTC, Ramon wrote:

 Finally and possibly most importantly, basically not having 
 fully working  debugger support is a very serious lack.


 Maybe it is because I write 100% bug free code the first time 
 every time ( :-) ) but I've found the gdb support, at least on 
 Linux, to be really pretty good.

 I compile with -gc -debug - the "pretend to be C" option is 
 something I started doing years ago and might not be necessary 
 anymore, but I've found it to be plenty good enough anyway.


 D's bias toward Windows doesn't help either.


 If anything, I don't think D goes far enough in its Windows 
 support. It works well there, sure, even the optlink things 
 others complain about don't bother me, but there's a lot of 
 stuff it could easily do and doesn't, at least not without 
 grabbing additional downloads.

 On Linux, dmd works quite excellently, as do gdc and ldc.


Adam,

Me and my colleague are working full time for a project with DMD 
2.063: I'm on OSX, so it's a different story, but he is on linux 
(Ubuntu 13.04 64bit).

He is VERY interested in being able to use the debugger, first of 
all from command line (just to understand at first glance what is 
working and what not...).

I've read a lot of thread about debugging, mainly related to 
stack-trace or sigfault, but what we are rely missing is the 
ability to set a break (usually that's work, at least in OSX), 
AND being able to inspect locals.

I think we are not alone searching for such informations, so can 
you point me somewhere in the wiki, in the documentation, or 
similar, when there's a clear information about what version of 
gdb to use, what it is available as functionality and what not, 
and what compiler flags to use?

If there's not such a place, does it worth considering to open a 
page related to that?

- Paolo
Sep 02 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 2 September 2013 at 12:00:43 UTC, Paolo Invernizzi 
wrote:

 ability to set a break (usually that's work, at least in OSX), 
 AND being able to inspect locals.


Here's what happens with me:

dmd test30.d -debug -gc
gdb test30
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
[...]
This GDB was configured as "x86_64-slackware-linux".
[...]
(gdb) break test30.d:13
Breakpoint 1 at 0x8070846: file test30.d, line 13.
(gdb) r
Starting program: /home/me/test30
[Thread debugging using libthread_db enabled]

Breakpoint 1, _Dmain () at test30.d:13
13              assert(0, s);
(gdb) print s
$1 = {length = 7, ptr = 0xf7cf7fe0 "test 10\b"}
(gdb) c
Continuing.
core.exception.AssertError test30.d(13): test 10
[...]
Program exited with code 01.



So you can see there that the breakpoint worked and the local 
variable check while not perfect (I hear the newer gdb works 
better, but I haven't updated mine since 2010), is good enough to 
get an idea of what is going on.


Setting breakpoints by function name is harder because you need 
to know the mangled version (again maybe this works better in 
future gdbs but not on mine). For extern(C) that's easy, it is 
just the name:

(gdb) break gc_malloc
Breakpoint 1 at 0x8079058

gc_malloc is extern(C) so it knows the name.


For a D function, or worse yet, a template, getting the mangled 
name is a pain. I've never actually bothered with this before, I 
just prefer to use the file and line number.

But if you wanted to, you could pragma(msg, funcname.mangleof) to 
get it from the compiler, then:

(gdb) break _D6test3015__T8myformatTiZ8myformatFNaNbNexAyaxiZAya
Breakpoint 1 at 0x8070870: file test30.d, line 4.
(gdb) r
Starting program: /home/me/test30
[Thread debugging using libthread_db enabled]

Breakpoint 1, 
_D6test3015__T8myformatTiZ8myformatFNaNbNexAyaxiZAya (
     _param_1=10, fmt=...) at test30.d:4
4                       return format(fmt, t);



So that works, it is just extremely awkward compared to the 
file+line number.







Another thing I do is compile every D file at once. dmd -gc 
-debug a.d everything.d here.d so.d on.d etc.d


Maybe that helps me too.


 I think we are not alone searching for such informations, so 
 can you point me somewhere in the wiki, in the documentation, 
 or similar, when there's a clear information about what version 
 of gdb to use, what it is available as functionality and what 
 not, and what compiler flags to use?


I don't really know except what works for me.

But Iain in another thread said gdb 4.6 or 4.7 works best though.
Sep 02 2013
parent "Paolo Invernizzi" <paolo.invernizzi gmail.com> writes:
On Monday, 2 September 2013 at 13:44:40 UTC, Adam D. Ruppe wrote:

 On Monday, 2 September 2013 at 12:00:43 UTC, Paolo Invernizzi 
 wrote:

 ability to set a break (usually that's work, at least in OSX), 
 AND being able to inspect locals.


 Here's what happens with me:

 dmd test30.d -debug -gc
 gdb test30
 GNU gdb (GDB) 7.1
 Copyright (C) 2010 Free Software Foundation, Inc.
 [...]
 This GDB was configured as "x86_64-slackware-linux".
 [...]
 (gdb) break test30.d:13
 Breakpoint 1 at 0x8070846: file test30.d, line 13.
 (gdb) r
 Starting program: /home/me/test30
 [Thread debugging using libthread_db enabled]

 Breakpoint 1, _Dmain () at test30.d:13
 13              assert(0, s);
 (gdb) print s
 $1 = {length = 7, ptr = 0xf7cf7fe0 "test 10\b"}
 (gdb) c
 Continuing.
 core.exception.AssertError test30.d(13): test 10
 [...]
 Program exited with code 01.


<snip>


 Another thing I do is compile every D file at once. dmd -gc 
 -debug a.d everything.d here.d so.d on.d etc.d


 Maybe that helps me too.


Thank you Adam, we will try this for sure!


 I think we are not alone searching for such informations, so 
 can you point me somewhere in the wiki, in the documentation, 
 or similar, when there's a clear information about what 
 version of gdb to use, what it is available as functionality 
 and what not, and what compiler flags to use?


 I don't really know except what works for me.

 But Iain in another thread said gdb 4.6 or 4.7 works best 
 though.


This week we are pretty busy, but the next one I'll try to insert 
some informations in the wiki (if it is possible!), so that at 
least we can have some central point to share the _actual_ status 
of the debuggers functionalities versus the current versions of 
DMD at least...

- Paolo
Sep 02 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-02 14:00, Paolo Invernizzi wrote:


 Me and my colleague are working full time for a project with DMD 2.063:
 I'm on OSX, so it's a different story, but he is on linux (Ubuntu 13.04
 64bit).


The debugging experience is even worse on Mac OS X.

-- 
/Jacob Carlborg
Sep 02 2013
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Monday, 2 September 2013 at 14:22:15 UTC, Jacob Carlborg wrote:

 On 2013-09-02 14:00, Paolo Invernizzi wrote:


 Me and my colleague are working full time for a project with 
 DMD 2.063:
 I'm on OSX, so it's a different story, but he is on linux 
 (Ubuntu 13.04
 64bit).


 The debugging experience is even worse on Mac OS X.


I can confirm! I use http://cgdb.github.io/ on Mac OS. The pain, 
the pain.... :/
Sep 02 2013
parent reply "Paolo Invernizzi" <paolo.invernizzi gmail.com> writes:
On Monday, 2 September 2013 at 18:30:45 UTC, Gary Willoughby 
wrote:

 On Monday, 2 September 2013 at 14:22:15 UTC, Jacob Carlborg 
 wrote:

 On 2013-09-02 14:00, Paolo Invernizzi wrote:


 Me and my colleague are working full time for a project with 
 DMD 2.063:
 I'm on OSX, so it's a different story, but he is on linux 
 (Ubuntu 13.04
 64bit).


 The debugging experience is even worse on Mac OS X.


 I can confirm! I use http://cgdb.github.io/ on Mac OS. The 
 pain, the pain.... :/



Actually I use lldb: at least it has some pretty tabbed 
autocomplete on files and function number.
If you know the module, you can start with something like 
'D4test' and tab to have the symbols.

It works also over file:number so at least you can set some break 
and check the calling frames (sometime is useful, and I don't 
think this is possible with the usual flooding of 'writeln', or 
no?).

What actually really doesn't work at all is printing locals:

   (gdb) info local
   No symbol table info available.

*sigh*

- Paolo
Sep 02 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-02 21:36, Paolo Invernizzi wrote:


 Actually I use lldb: at least it has some pretty tabbed autocomplete on
 files and function number.
 If you know the module, you can start with something like 'D4test' and
 tab to have the symbols.

 It works also over file:number so at least you can set some break and
 check the calling frames (sometime is useful, and I don't think this is
 possible with the usual flooding of 'writeln', or no?).

 What actually really doesn't work at all is printing locals:

    (gdb) info local
    No symbol table info available.


DMD doesn't output correct DWARF on Mac OS X. Or it's the regular 
section names that is the problem. They're missing an underscore.

http://d.puremagic.com/issues/show_bug.cgi?id=8172
http://d.puremagic.com/issues/show_bug.cgi?id=8207

-- 
/Jacob Carlborg
Sep 03 2013
parent "Paolo Invernizzi" <paolo.invernizzi gmail.com> writes:
On Tuesday, 3 September 2013 at 07:12:17 UTC, Jacob Carlborg 
wrote:

 On 2013-09-02 21:36, Paolo Invernizzi wrote:


 What actually really doesn't work at all is printing locals:

   (gdb) info local
   No symbol table info available.


 DMD doesn't output correct DWARF on Mac OS X. Or it's the 
 regular section names that is the problem. They're missing an 
 underscore.

 http://d.puremagic.com/issues/show_bug.cgi?id=8172
 http://d.puremagic.com/issues/show_bug.cgi?id=8207


Indeed an underscore is missing, as I have to set breakpoints 
using 'D4test....' instead of '_D4test', but I have no idea about 
why the symbol table is related to that...

- Paolo
Sep 03 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Sep 02, 2013 at 12:21:08AM +0200, Ramon wrote:
[...]

 D's bias toward Windows doesn't help either.


[...]

I'm confused by this statement. I don't do development on Windows
either, but my impression during the time I've been around here is that
Windows support is actually lagging behind Linux. It was only very
recently that we got 64-bit support on Windows. And optlink often comes
up as a nagging point (along with COFF vs. whatever it is the other
format is called), but Linux users use the system linker and never have
this problem.

So, all things considered, it would appear to me rather that D is more
biased towards Linux. :)

As for the whole "need better IDE support" issue, I think it's the same
with every other issue that has come up in the D community: it takes
*somebody* to champion the cause and do whatever it takes to make it
happen. Like Andrei with Phobos, Iain with GDC, Don with CTFE, etc..
Being an opensource community, the dynamics here are rather different
from, say, a corporate-backed language: what somebody cares about enough
to do something about it, is what gets implemented and supported.
Dictating that people work on feature X, or officially declaring support
for feature X, generally doesn't have very much actual effect. The core
devs have enough on their hands already (too much, in fact -- Phobos
pulls, for example, need much more manpower to review so that turnaround
time isn't as slow as it currently is). What is needed is *somebody*
from the community with the urge to do something about it, to go ahead
and do it, and then submit the pull requests, etc., to get it
integrated. I'm sure Walter & co will be more than happy to merge such
requests.


T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for
Volkswagen.
Sep 01 2013
prev sibling next sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 02/09/13 14:24, H. S. Teoh wrote:

 On Mon, Sep 02, 2013 at 12:21:08AM +0200, Ramon wrote:
 [...]

 D's bias toward Windows doesn't help either.


 [...]

 I'm confused by this statement.


I think this may be a reference to parts of Phobos which are a bit 
Windowsish with Posix tacked on rather than Posix with special cases for 
Windows' lack of support for some features.
Sep 01 2013
prev sibling parent reply "Ludovit Lucenic" <llucenic gmail.com> writes:
On Sunday, 1 September 2013 at 22:21:10 UTC, Ramon wrote:

 Ludovit Lucenic

 While one may discuss about IDE or cli, I feel that an IDE is 
 at least an immensely helpful starting point.


I would add to it, that IDE could also solve some of the problems
discussed e.g. on the Panel talk in DConf. I mean the code
upgrade automation once the compiler comes in newer version. We
solved this (in the job mentioned) by having an IDE that did an
automatic upgrade on the project opened. I absolutely agree with
Walter that it seems weird to have a compiler which modifies the
code :-) But having an IDE that does this is pretty much
convenient. Not talking about the whole bunch of other minor 'D
UX' issues that could be managed easily with a little help of an
IDE.


 I agree that one should be able to do programming with no more 
 than a simple editor, a compiler/linker, and a debugger (!). 
 Newcomers, however, (and even many seasoned programmers) 
 handily profit from an IDE (and I don't mean Eclipse which I 
 count as a moloch that, to make things worse, is based on java).


I did not meant Eclipse is 'the way'. I said eclipse-like
debugging user experience is still something worth taking
inspiration from. Anyway I am persuaded having IDE written in D
fits the needs the best. Just look at all the relevant IDEs
around. Every and each of them is used primarily to target the
language the IDE is written in :-) MonoDevelop for Mono, Visual
Studio for .Net, Code::Blocks for C++, Eclipse for Java... Have
you noticed it ?



 Finally and possibly most importantly, basically not having 
 fully working  debugger support is a very serious lack. I may 
 be wrong (actually I hope to be wrong) but from what I know, 
 this issue doesn't seem to be seen as having very high priority.


I got to admit this is the most surprising thing about the D I
came across. Well, let's not complain about it, let's do
something with it. I assume the GDB is cross-platform solution
for debugging that seems to be furthest. Therefore I chose
MonoDevelop to improve its debugging capabilities (at least I had
something to start with) and add the visualization needed by some
of us.
However, I don't think I can move things much forward on Windows
unless we have ready to use GDC/LDC executables (that one can
download and install easily on Win platform) which would by-pass
the DMD/GDB/Win problem then. Moreover, I don't like to code in



 I'm more and more getting the impression that D could be a 
 programmers dreams come true if only it were practically and 
 productively useable. Sure, it's not D's fault. But in the end 
 we need a fully working debugger, some good editor support 
 (say, on a Scintilla/Scite level), preferably at least one 
 cross platform non-java IDE (like Code:Blocks) and easy access 
 to C libraries in order to actually and productively work with 
 a language.


Could not express it better!


 D's bias toward Windows doesn't help either.


Absolutely disagree. My experience is quite the opposite. I mean,
you might be referring the VisualD stuff, but regarding the
debugging, it is not mature enough anyway.


 Looking at it from a marketing perspective, i.e. looking for 
 what potential users (read: "the large crowd out there") would 
 look for, I see that the creators of D have done an excellent 
 job that, however reminds of a Porsche engine on a makeshift 
 chassis.


I am idealist myself too, but got to admit: perfect analogy.


 Frankly, if we want D to attract developers and to get the 
 position it undoubtedly deserves that will not be achieved so 
 much by finetuning D or even phobos but by being able to offer 
 a well-rounded and well useable package (and soon after good 
 docs for what we have so far).

 A+ -R


The work with D has to bring joy, but sometimes it leads to
confusion. We're strong, we will come through, but have anyone
already see the tunnel ? Not speaking of the light :-)

Ludovit
Sep 02 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-02 09:48, Ludovit Lucenic wrote:


 However, I don't think I can move things much forward on Windows
 unless we have ready to use GDC/LDC executables (that one can
 download and install easily on Win platform) which would by-pass
 the DMD/GDB/Win problem then. Moreover, I don't like to code in



Have a look at this:

http://forum.dlang.org/thread/mailman.990.1370788529.13711.digitalmars-d-ldc puremagic.com

That post contains links to LDC binaries.

-- 
/Jacob Carlborg
Sep 02 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-01 22:47, Ludovit Lucenic wrote:


   1) only D1 version of majority of D code I could use, phobos vs. tango
 incompatibility, ... (valid for January 2013)


Tango for D2 is available here

https://github.com/SiegeLord/Tango-D2

It can be used side-by-side with Phobos without any problems. I use it 
like that.

-- 
/Jacob Carlborg
Sep 02 2013
parent "Ludovit Lucenic" <llucenic gmail.com> writes:
On Monday, 2 September 2013 at 12:29:29 UTC, Jacob Carlborg wrote:

 On 2013-09-01 22:47, Ludovit Lucenic wrote:


  1) only D1 version of majority of D code I could use, phobos 
 vs. tango
 incompatibility, ... (valid for January 2013)


 Tango for D2 is available here

 https://github.com/SiegeLord/Tango-D2

 It can be used side-by-side with Phobos without any problems. I 
 use it like that.


Jacob,

finally I did find this version of Tango. I have described here 
the whole process and it was not easy and straightforward for me 
at that time to figure out that Tango-D2 is the way to go. I 
pointed out all the obstacles, from the beginning on. Actually, 
the Tango-D2 library was the most problem-free part for my 
project so far, although not without any problems :-) But these 
were more or less language specific, so that I needed to adapt 
some code based on the changed DMD compiler in the meanwhile or 
so.

Kind regards,
Ludovit
Sep 02 2013