www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is Anything Holding you back?

reply Yaser <yaserfahmed gmail.com> writes:
Are there any critical frameworks or libraries that are holding 
you back in fully investing in D? Obviously I think D is an 
awesome language, but some frameworks/libraries hold me back, 
wish I could do everything in D.
Oct 01 2015
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are holding 
 you back in fully investing in D?


Nope, if anything like that comes up, I'll just write it myself!
Oct 01 2015
parent reply Yaser <yaserfahmed gmail.com> writes:
On Friday, 2 October 2015 at 02:29:47 UTC, Adam D. Ruppe wrote:

 On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are 
 holding you back in fully investing in D?


 Nope, if anything like that comes up, I'll just write it myself!


That's the attitude, but do you think you can rewrite 10+ years * 
X man hours of software by yourself
Oct 01 2015
next sibling parent reply David DeWitt <dkdewitt gmail.com> writes:
On Friday, 2 October 2015 at 02:31:50 UTC, Yaser wrote:

 On Friday, 2 October 2015 at 02:29:47 UTC, Adam D. Ruppe wrote:

 On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are 
 holding you back in fully investing in D?


 Nope, if anything like that comes up, I'll just write it 
 myself!


 That's the attitude, but do you think you can rewrite 10+ years 
 * X man hours of software by yourself


Im sure he meant if he needs something thats not yet available 
then he'll just write it.  D is a community effort so obviously 
many ppl need to chip in.  I pretty much use the usual Python/JS 
combo professionally and there are a ton of battle tested 
libraries and frameworks but innovation always brings new 
techniques and libraries that eventually replace old stuff.  If 
the attitude was "well Java has X and countless others" then none 
of the newer languages would every get build.  Look at how React 
has pretty much taken over (well at least for me) that is new and 
so is the countless community driven projects evolving around 
React.

Like anything D does need more things like better Database 
support, web frameworks, etc but it will get there. Who knows in 
a couple years maybe you will be doing everything in D.
Oct 01 2015
parent Yaser <yaserfahmed gmail.com> writes:
On Friday, 2 October 2015 at 02:52:23 UTC, David DeWitt wrote:

 Im sure he meant if he needs something thats not yet available 
 then he'll just write it.  D is a community effort so obviously 
 many ppl need to chip in.  I pretty much use the usual 
 Python/JS combo professionally and there are a ton of battle 
 tested libraries and frameworks but innovation always brings 
 new techniques and libraries that eventually replace old stuff.
  If the attitude was "well Java has X and countless others" 
 then none of the newer languages would every get build.  Look 
 at how React has pretty much taken over (well at least for me) 
 that is new and so is the countless community driven projects 
 evolving around React.

 [...]


I knew what he meant, just the attitude of some OSS Devs can be 
asinine
Oct 01 2015
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 2 October 2015 at 02:31:50 UTC, Yaser wrote:

 That's the attitude, but do you think you can rewrite 10+ years 
 * X man hours of software by yourself


It doesn't actually take that long to write useful programs. (and 
btw, I've been writing D for 8+ years already, including a lot of 
support libs for my programs over that time.)


Moreover, and this is really important, D can already interact 
the majority of existing software out there. For example, when I 
needed crypto functions in D, I didn't rewrite it. I just 
copy/pasted a few function prototypes from a C library and called 
them.

When I needed to access a mysql database, I didn't rewrite the 
database. I didn't even implement the communication protocol 
(though that isn't really *that* hard either), I just called the 
official mysql C functions.

Those alone are enough to start doing real work after just a few 
hours of setup, and you can build up the rest from there as 
needed.

IMO part of fully investing in something is spending the time to 
adapt what it has to your needs and filling in the rest of the 
gaps as more needs come up.
Oct 01 2015
parent Chris <wendlec tcd.ie> writes:
On Friday, 2 October 2015 at 03:34:18 UTC, Adam D. Ruppe wrote:


 Moreover, and this is really important, D can already interact 
 the majority of existing software out there.


This is a very important point that is often forgotten. What has 
been done in C is also available to D. To work with D you don't 
need to have everything written in D. If that was the case, no 
new language could ever be used, because it's impossible to catch 
up with the wealth of libraries that already exist in C/C++.

And through C you can communicate with other languages too, 
Python, Lua etc. Look at PyD and LuaD for example or the 
DerelictD stuff.

One caveat though: if your software is GUI-centered, research the 
possibilities in D. If you wanna go mobile (ARM), check carefully 
what can be done already and what can't.
Oct 02 2015
prev sibling parent Daniel Kozak <kozzi dlang.cz> writes:
Yaser p=C3=AD=C5=A1e v P=C3=A1 02. 10. 2015 v 02:31 +0000:

 On Friday, 2 October 2015 at 02:29:47 UTC, Adam D. Ruppe wrote:

 On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are=20
 holding you back in fully investing in D?


=20
 Nope, if anything like that comes up, I'll just write it myself!


=20
 That's the attitude, but do you think you can rewrite 10+ years *=20
 X man hours of software by yourself


There is no need to use=C2=A010+ years * X man hours sw. You can just write
what you actually need, nothing more nothing less.
Oct 02 2015
prev sibling next sibling parent reply luminousone <rd.hunt gmail.com> writes:
On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are holding 
 you back in fully investing in D? Obviously I think D is an 
 awesome language, but some frameworks/libraries hold me back, 
 wish I could do everything in D.


vibe.d compatible sqlite, postgresql, and oracle sql drivers. dub 
support in visualD/mono-d, better container libraries in the 
standard library(granted this is coming now that the allocator 
library is just about here).

derelictGL has issues with AMD cards(issues that are AMD's fault 
granted) that has caused me to have to maintain a fork with a few 
things commented out.

I would kill for golang channel like types supported in the 
standard library.

other then some database support missing from vibe.d nothing 
really holds me back, just annoyances really.
Oct 01 2015
next sibling parent reply suliman <Evermind live.ru> writes:
On Friday, 2 October 2015 at 05:15:26 UTC, luminousone wrote:

 On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are 
 holding you back in fully investing in D? Obviously I think D 
 is an awesome language, but some frameworks/libraries hold me 
 back, wish I could do everything in D.


 vibe.d compatible sqlite, postgresql, and oracle sql drivers. 
 dub support in visualD/mono-d, better container libraries in 
 the standard library(granted this is coming now that the 
 allocator library is just about here).

 derelictGL has issues with AMD cards(issues that are AMD's 
 fault granted) that has caused me to have to maintain a fork 
 with a few things commented out.

 I would kill for golang channel like types supported in the 
 standard library.

 other then some database support missing from vibe.d nothing 
 really holds me back, just annoyances really.


and GUI lib with simple GUI builder
Oct 01 2015
parent karabuta <karabutaworld gmail.com> writes:
On Friday, 2 October 2015 at 05:28:23 UTC, suliman wrote:

 On Friday, 2 October 2015 at 05:15:26 UTC, luminousone wrote:

 On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are 
 holding you back in fully investing in D? Obviously I think D 
 is an awesome language, but some frameworks/libraries hold me 
 back, wish I could do everything in D.








 and GUI lib with simple GUI builder


That is what I want to hear.
Oct 03 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 2 October 2015 at 05:15:26 UTC, luminousone wrote:

 vibe.d compatible sqlite, postgresql, and oracle sql drivers.


An ODBC driver would be fine too, anything that can connect to a 
database.
Oct 02 2015
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 02-Oct-2015 10:49, Kagamin wrote:

 On Friday, 2 October 2015 at 05:15:26 UTC, luminousone wrote:

 vibe.d compatible sqlite, postgresql, and oracle sql drivers.


 An ODBC driver would be fine too, anything that can connect to a database.


http://dlang.org/phobos/etc_c_odbc_sql.html

-- 
Dmitry Olshansky
Oct 02 2015
parent reply Kagamin <spam here.lot> writes:
On Friday, 2 October 2015 at 08:03:03 UTC, Dmitry Olshansky wrote:

 On 02-Oct-2015 10:49, Kagamin wrote:

 On Friday, 2 October 2015 at 05:15:26 UTC, luminousone wrote:

 vibe.d compatible sqlite, postgresql, and oracle sql drivers.


 An ODBC driver would be fine too, anything that can connect to 
 a database.


 http://dlang.org/phobos/etc_c_odbc_sql.html


http://wiki.dlang.org/Libraries_and_Frameworks#Databases
Oct 02 2015
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
Am 02.10.2015 um 10:15 schrieb Kagamin:

 On Friday, 2 October 2015 at 08:03:03 UTC, Dmitry Olshansky wrote:

 On 02-Oct-2015 10:49, Kagamin wrote:

 On Friday, 2 October 2015 at 05:15:26 UTC, luminousone wrote:

 vibe.d compatible sqlite, postgresql, and oracle sql drivers.


 An ODBC driver would be fine too, anything that can connect to a
 database.


 http://dlang.org/phobos/etc_c_odbc_sql.html


 http://wiki.dlang.org/Libraries_and_Frameworks#Databases


http://code.dlang.org/?sort=name&category=library.database
Oct 02 2015
next sibling parent Kagamin <spam here.lot> writes:
On Friday, 2 October 2015 at 08:23:56 UTC, Sönke Ludwig wrote:

 http://code.dlang.org/?sort=name&category=library.database


Unfortunately not everybody is using sqlite and postgresql.
Oct 02 2015
prev sibling parent luminousone <rd.hunt gmail.com> writes:
On Friday, 2 October 2015 at 08:23:56 UTC, Sönke Ludwig wrote:

 Am 02.10.2015 um 10:15 schrieb Kagamin:

 On Friday, 2 October 2015 at 08:03:03 UTC, Dmitry Olshansky 
 wrote:

 On 02-Oct-2015 10:49, Kagamin wrote:

 On Friday, 2 October 2015 at 05:15:26 UTC, luminousone wrote:

 vibe.d compatible sqlite, postgresql, and oracle sql 
 drivers.


 An ODBC driver would be fine too, anything that can connect 
 to a
 database.


 http://dlang.org/phobos/etc_c_odbc_sql.html


 http://wiki.dlang.org/Libraries_and_Frameworks#Databases


 http://code.dlang.org/?sort=name&category=library.database


Looks like an async postgresql driver is in their, but i don't 
see sqlite supported in this fashion yet. I would love to use 
vibe.d(we currently use java/tomcat with spring framework) in 
some of the projects at work, but most of this would require 
connecting to an oracle server, I will re-examine the pgsql 
situation.

We have several projects coming up where we will get a dataset 
from the Utah department of environmental quality and we will 
build a small website around it for the public to query and look 
at the data in a user friendly fashion. Assuming pgsql support is 
up to snuff, I can get away with using vibe.d. And I believe 
anyway that I could finish the project faster with vibe.d then 
java/tomcat/spring.
Oct 02 2015
prev sibling next sibling parent crimaniak <crimaniak gmail.com> writes:
Full-featured PDF library (with JBIG2 and Jpeg2000 support and so 
on...)
Oct 01 2015
prev sibling next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are holding 
 you back in fully investing in D? Obviously I think D is an 
 awesome language, but some frameworks/libraries hold me back, 
 wish I could do everything in D.


Sadly, the preprocessor, and it just happened to me today. In 
C++, I include the header and I'm done. In D, I have to either 
manually duplicate the C declarations or use dstep. I'm more than 
ok with the latter option, but my environment is weird (doesn't 
use the system libc) and dstep didn't work. Doing it manually 
would be so much work that I gave up for this project in 
particular.

Mostly I write everything in D these days though.

Atila
Oct 02 2015
prev sibling next sibling parent reply ponce <contact gam3sfrommars.fr> writes:
On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are holding 
 you back in fully investing in D? Obviously I think D is an 
 awesome language, but some frameworks/libraries hold me back, 
 wish I could do everything in D.


I'd say kickass codegen from DMD but it seems it's getting 
improvements.

Nothing held me back :) Now writing D full-time.
Oct 02 2015
parent =?UTF-8?B?TcOhcmNpbw==?= Martins <marcioapm gmail.com> writes:
On Friday, 2 October 2015 at 09:44:00 UTC, ponce wrote:

 On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are 
 holding you back in fully investing in D? Obviously I think D 
 is an awesome language, but some frameworks/libraries hold me 
 back, wish I could do everything in D.


 I'd say kickass codegen from DMD but it seems it's getting 
 improvements.

 Nothing held me back :) Now writing D full-time.


That, and the very poor debugging experience.

Our web company is also 100% D, minus a few javascript and css 
tools that we currently use node.js for.
Oct 02 2015
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are holding 
 you back in fully investing in D? Obviously I think D is an 
 awesome language, but some frameworks/libraries hold me back, 
 wish I could do everything in D.


Yes: https://issues.dlang.org/show_bug.cgi?id=14927

This is honestly embarrassing for me when ever I mention D to 
someone.
Oct 02 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/02/2015 08:54 AM, Jack Stouffer wrote:

 On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are holding you
 back in fully investing in D? Obviously I think D is an awesome
 language, but some frameworks/libraries hold me back, wish I could do
 everything in D.


 Yes: https://issues.dlang.org/show_bug.cgi?id=14927


Do we have an attack on this problem? -- Andrei
Oct 02 2015
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Friday, 2 October 2015 at 12:54:30 UTC, Jack Stouffer wrote:

 On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are 
 holding you back in fully investing in D? Obviously I think D 
 is an awesome language, but some frameworks/libraries hold me 
 back, wish I could do everything in D.


 Yes: https://issues.dlang.org/show_bug.cgi?id=14927

 This is honestly embarrassing for me when ever I mention D to 
 someone.


This, and debug support in general. I have no idea how to get 
line number for stack traces on OSX, let alone run GDB or LLDB, 
but even on linux where the support is better, I need to use a 
specific set of linker flag + use command lines tools to get line 
number from stack traces.
Oct 02 2015
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 02-Oct-2015 05:25, Yaser wrote:

 Are there any critical frameworks or libraries that are holding you back
 in fully investing in D? Obviously I think D is an awesome language, but
 some frameworks/libraries hold me back, wish I could do everything in D.


My personal favorite (8+ years old OMG):
https://issues.dlang.org/show_bug.cgi?id=1238

Makes me want to laugh every time we discuss "problems" of D. Bugs are 
as usual at the top of problems in my book.

And couple more from the miserable line of basic encapsulation not working:

https://issues.dlang.org/show_bug.cgi?id=314
https://issues.dlang.org/show_bug.cgi?id=463

And there is even more to dig up.

-- 
Dmitry Olshansky
Oct 02 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/02/2015 09:11 AM, Dmitry Olshansky wrote:

 On 02-Oct-2015 05:25, Yaser wrote:

 Are there any critical frameworks or libraries that are holding you back
 in fully investing in D? Obviously I think D is an awesome language, but
 some frameworks/libraries hold me back, wish I could do everything in D.


 My personal favorite (8+ years old OMG):
 https://issues.dlang.org/show_bug.cgi?id=1238

 Makes me want to laugh every time we discuss "problems" of D. Bugs are
 as usual at the top of problems in my book.


I agree it's a hole in the module system, but it's not quite something 
that prevents work from being done.


 And couple more from the miserable line of basic encapsulation not working:

 https://issues.dlang.org/show_bug.cgi?id=314
 https://issues.dlang.org/show_bug.cgi?id=463


These seem in the same category. Not to say they aren't important.


Andrei
Oct 02 2015
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 2 October 2015 at 13:24:10 UTC, Andrei Alexandrescu 
wrote:

 On 10/02/2015 09:11 AM, Dmitry Olshansky wrote:

 On 02-Oct-2015 05:25, Yaser wrote:

 Are there any critical frameworks or libraries that are 
 holding you back
 in fully investing in D? Obviously I think D is an awesome 
 language, but
 some frameworks/libraries hold me back, wish I could do 
 everything in D.


 My personal favorite (8+ years old OMG):
 https://issues.dlang.org/show_bug.cgi?id=1238

 Makes me want to laugh every time we discuss "problems" of D. 
 Bugs are
 as usual at the top of problems in my book.


 I agree it's a hole in the module system, but it's not quite 
 something that prevents work from being done.


 And couple more from the miserable line of basic encapsulation 
 not working:

 https://issues.dlang.org/show_bug.cgi?id=314
 https://issues.dlang.org/show_bug.cgi?id=463


 These seem in the same category. Not to say they aren't 
 important.


Yeah. They do make it much easier to break other code when you 
make changes (including making changes in something like Phobos), 
but mostly, they don't prevent work getting done. They are pretty 
embarrassing though.

- Jonathan M Davis
Oct 02 2015
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10/02/2015 03:24 PM, Andrei Alexandrescu wrote:

 On 10/02/2015 09:11 AM, Dmitry Olshansky wrote:

 On 02-Oct-2015 05:25, Yaser wrote:

 Are there any critical frameworks or libraries that are holding you back
 in fully investing in D? Obviously I think D is an awesome language, but
 some frameworks/libraries hold me back, wish I could do everything in D.


 My personal favorite (8+ years old OMG):
 https://issues.dlang.org/show_bug.cgi?id=1238

 Makes me want to laugh every time we discuss "problems" of D. Bugs are
 as usual at the top of problems in my book.


 I agree it's a hole in the module system, but it's not quite something
 that prevents work from being done.


It slows it down. The most annoying part of it is that it introduces 
clashes with private aliases introduced for disambiguation. I.e., the 
mechanism that most conveniently deals with ambiguous symbols is 
basically defunct because of spurious ambiguous symbol errors.
Oct 02 2015
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are holding 
 you back in fully investing in D? Obviously I think D is an 
 awesome language, but some frameworks/libraries hold me back, 
 wish I could do everything in D.


Nothing is holding me back from using D on my personal projects. 
At this point, all of them are in D. The primary thing that I'm 
lacking is time to work on them.

Now, using D at work is another thing entirely, but that has more 
to do with there being existing codebases and it being very 
difficult to talk coworkers into using a new language or 
technology than there necessarily being any technical issues.

Sure, there are some things that would be easier to do if they 
were written in D or if we had better wrappers for existing C++ 
stuff (e.g. it would be great to be able to fully use Qt from D), 
but because it's trivial to call C functions, and even 
interacting with C++ is possible on some level, it's not really a 
blocker when something isn't in D - just annoying.

- Jonathan M Davis
Oct 02 2015
parent Wyatt <wyatt.epp gmail.com> writes:
On Friday, 2 October 2015 at 17:17:07 UTC, Jonathan M Davis wrote:

 Now, using D at work is another thing entirely, but that has 
 more to do with there being existing codebases and it being 
 very difficult to talk coworkers into using a new language or 
 technology than there necessarily being any technical issues.


Same boat here, only with the added pain that most of our current 
stuff is a terrifying tower of Java trash.  I'm not even sure 
what could be done to ease this situation.

-Wyatt
Oct 02 2015
prev sibling next sibling parent Jan Johansson <jan.johansson.mr gmail.com> writes:
On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are holding 
 you back in fully investing in D? Obviously I think D is an 
 awesome language, but some frameworks/libraries hold me back, 
 wish I could do everything in D.


I want a really good communication stack, doing SOAP (no - I 
don't want the dry old 'JSON' is best, 'SOAP' is bad argument - I 
got enough reasons to use SOAP in many solutions) and the one 
really good stack I've seen so far on SOAP is WCF.

It would be a dream to be able to define service contracts and 
data contracts in a smooth and slick way in D, but maybe it's too 
heavy. It took MS about 5 years to create.
Oct 02 2015
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are holding 
 you back in fully investing in D? Obviously I think D is an 
 awesome language, but some frameworks/libraries hold me back, 
 wish I could do everything in D.


1/ Debug support. It is truly bad. Does not work on OSX as far as 
I know how, and works tediously on linux (line numbers are often 
wrong in GDB and do not appear ins tack trace, need to use 
specific linkers flags for this to work at all).

2/ Null reference types. Seriously. Everything is null by 
default, you get an error where the pointer is used, not where 
the problem is (and these 2 points can be fairly remote) and, 
associated with 1) , hard to track. 99% of the time, the thing is 
null due to a stupid mistake and the compiler could have catched 
it.

3/ Templates error messages. Especially when you pass closures as 
alias and the compiler decide to dump them with fucked up 
indentation all in the middle of the error message. Probably good 
for these that enjoy Klingon opera, but my taste differs.

4/ There used to be a fair amount of codegen bugs in closures, 
but these seems mostly fixed at this stage. However, there is 
still a lot of weirdness going on with them. Symbol in enclosing 
scope will be resolved, but not alias this for instance. 
Sometime, the closure will refuse to capture something for 
unknown reasons and one need to rely on ugly hacks.

5/ mixins are not hygienic. It is often not possible to get the 
symbols you are interested in at the site where they are going to 
be resolved. For instance (toy example, but I have various real 
world example of this in my code) :

module a;

struct S {}

import b;
MixinFail!S mf;

module b;

struct MixinFail(T) {
     mixin(T.stringof ~ " t;");
}

This limitation, forces me jump through all kind of hoops, or 
make various part of phobos unusable at even moderate scale (the 
problem in already big in SDC, which is a bit more than 40 kLOC 
at this stage).

6/ This is not a specific problem, but the general attitude that 
consist in taking care of details without looking at the big 
picture. Or to quote a coworker about "One will take great care 
in a bakery to put presents cackes and sweets nicely, sell them 
in a pretty box to customers, but do not care that there is a 
dogshit on the pavement at the entrance".

The recent assert message thread is a good example of that. 6 
pages in 2 days about how to best analyze the expression in the 
assert to get a better error messages (the nice box), when we 
don't even have line number in the trace that lead to this assert 
(the dogshit).
Oct 02 2015
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 2 October 2015 at 18:56:32 UTC, deadalnix wrote:

 don't even have line number in the trace that lead to this 
 assert (the dogshit).


http://arsdnet.net/this-week-in-d/sep-20.html

https://github.com/D-Programming-Language/druntime/pull/1354

works on linux now, already worked on Windows, provided you had 
the debughelp libs installed from Microsoft.

idk about Mac though.
Oct 02 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Friday, 2 October 2015 at 19:12:08 UTC, Adam D. Ruppe wrote:

 On Friday, 2 October 2015 at 18:56:32 UTC, deadalnix wrote:

 don't even have line number in the trace that lead to this 
 assert (the dogshit).


 http://arsdnet.net/this-week-in-d/sep-20.html

 https://github.com/D-Programming-Language/druntime/pull/1354

 works on linux now, already worked on Windows, provided you had 
 the debughelp libs installed from Microsoft.

 idk about Mac though.


Do I need to use specific linker flags to have this work ?

Also, that's AWESOME !
Oct 02 2015
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 2 October 2015 at 19:17:24 UTC, deadalnix wrote:

 Do I need to use specific linker flags to have this work ?


--export-dynamic if you want function names (now done by default 
in dmd.conf anyway) and -g if you want file and line numbers; it 
pulls the info from the debug information.
Oct 02 2015
prev sibling parent reply ponce <contact gam3sfrommars.fr> writes:
On Friday, 2 October 2015 at 18:56:32 UTC, deadalnix wrote:

 On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are 
 holding you back in fully investing in D? Obviously I think D 
 is an awesome language, but some frameworks/libraries hold me 
 back, wish I could do everything in D.


 1/ Debug support. It is truly bad. Does not work on OSX as far 
 as I know how, and works tediously on linux (line numbers are 
 often wrong in GDB and do not appear ins tack trace, need to 
 use specific linkers flags for this to work at all).


On OSX I've used lldb + LDC and stack traces and line numbers are 
there.
Symbols are not demangled though.
Oct 03 2015
parent deadalnix <deadalnix gmail.com> writes:
On Saturday, 3 October 2015 at 09:02:52 UTC, ponce wrote:

 On Friday, 2 October 2015 at 18:56:32 UTC, deadalnix wrote:

 On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are 
 holding you back in fully investing in D? Obviously I think D 
 is an awesome language, but some frameworks/libraries hold me 
 back, wish I could do everything in D.


 1/ Debug support. It is truly bad. Does not work on OSX as far 
 as I know how, and works tediously on linux (line numbers are 
 often wrong in GDB and do not appear ins tack trace, need to 
 use specific linkers flags for this to work at all).


 On OSX I've used lldb + LDC and stack traces and line numbers 
 are there.
 Symbols are not demangled though.


LDC is not an option for me ATM as only the latest DMD is 
supported.
Oct 03 2015
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 October 2015 at 12:25, Yaser via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Are there any critical frameworks or libraries that are holding you back in
 fully investing in D? Obviously I think D is an awesome language, but some
 frameworks/libraries hold me back, wish I could do everything in D.


Emscripten, Qt, and to a lesser extent, NaCl.
Oct 03 2015
prev sibling next sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are holding 
 you back in fully investing in D? Obviously I think D is an 
 awesome language, but some frameworks/libraries hold me back, 
 wish I could do everything in D.


OpenCV would be nice.

I use it a lot at work, and every now and then I want to make a 
small testbed just to try something out. It would be nice to be 
able to use D for this.

It seems odd no one has ported it yet since... "D is for Data 
Science" :)

     Bit
Oct 04 2015
parent bitwise <bitwise.pvt gmail.com> writes:
On Sunday, 4 October 2015 at 17:39:26 UTC, bitwise wrote:

 On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are 
 holding you back in fully investing in D? Obviously I think D 
 is an awesome language, but some frameworks/libraries hold me 
 back, wish I could do everything in D.


 OpenCV would be nice.

 I use it a lot at work, and every now and then I want to make a 
 small testbed just to try something out. It would be nice to be 
 able to use D for this.

 It seems odd no one has ported it yet since... "D is for Data 
 Science" :)

     Bit


I should add that it would be even nicer to be able to use it for 
production code, but we target iOS.

     Bit
Oct 04 2015
prev sibling next sibling parent reply Jan Johansson <jan.johansson.mr gmail.com> writes:
On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are holding 
 you back in fully investing in D? Obviously I think D is an 
 awesome language, but some frameworks/libraries hold me back, 
 wish I could do everything in D.


I'd wish for attributes to be runtime available, not only 
compiler directives. It could then be used for a number of 
interesting use cases, as marshaling from and to different 
formats rather than through API. The attributes could then be 
supported by libraries.
Oct 04 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 5 October 2015 at 03:44, Jan Johansson via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are holding you back
 in fully investing in D? Obviously I think D is an awesome language, but
 some frameworks/libraries hold me back, wish I could do everything in D.



 I'd wish for attributes to be runtime available, not only compiler
 directives. It could then be used for a number of interesting use cases, as
 marshaling from and to different formats rather than through API. The
 attributes could then be supported by libraries.


Anything compile time can be made available at runtime if your system
calls for it.
Oct 04 2015
parent reply Jan Johansson <jan.johansson.mr gmail.com> writes:
On Sunday, 4 October 2015 at 23:55:42 UTC, Manu wrote:

 On 5 October 2015 at 03:44, Jan Johansson via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:

 On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are 
 holding you back in fully investing in D? Obviously I think D 
 is an awesome language, but some frameworks/libraries hold me 
 back, wish I could do everything in D.



 I'd wish for attributes to be runtime available, not only 
 compiler directives. It could then be used for a number of 
 interesting use cases, as marshaling from and to different 
 formats rather than through API. The attributes could then be 
 supported by libraries.


 Anything compile time can be made available at runtime if your 
 system calls for it.


Sure it can, but I want a dynamic behavior, not a static 
behavior. Attributes are compiler directives. They are not 
available at runtime according to the specification of D 
language. Now take the example at: 
http://ddili.org/ders/d.en/uda.html, and separate the code into 
one library that defines the attributes and "printAsXML", keep 
the consumer of the attributes (main function) and get the same 
slick functionality. It can't be done, because UDA is not runtime 
available.
Oct 04 2015
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 5 October 2015 at 14:02, Jan Johansson via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Sunday, 4 October 2015 at 23:55:42 UTC, Manu wrote:

 On 5 October 2015 at 03:44, Jan Johansson via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are holding you back
 in fully investing in D? Obviously I think D is an awesome language, but
 some frameworks/libraries hold me back, wish I could do everything in D.




 I'd wish for attributes to be runtime available, not only compiler
 directives. It could then be used for a number of interesting use cases, as
 marshaling from and to different formats rather than through API. The
 attributes could then be supported by libraries.



 Anything compile time can be made available at runtime if your system
 calls for it.



 Sure it can, but I want a dynamic behavior, not a static behavior.
 Attributes are compiler directives. They are not available at runtime
 according to the specification of D language. Now take the example at:
 http://ddili.org/ders/d.en/uda.html, and separate the code into one library
 that defines the attributes and "printAsXML", keep the consumer of the
 attributes (main function) and get the same slick functionality. It can't be
 done, because UDA is not runtime available.


You can easily make attributes effectively available at runtime by
building lists of attributed things at compile time.
I don't understand your problem. Describe the goal?

I was one of the main guys involved in the introduction of UDA's, and
I have managed to use them successfully for most of my needs.
Oct 04 2015
parent reply Jonas Drewsen <nospam4321 hotmail.com> writes:
On Monday, 5 October 2015 at 06:18:45 UTC, Manu wrote:

 You can easily make attributes effectively available at runtime 
 by
 building lists of attributed things at compile time.
 I don't understand your problem. Describe the goal?


This is all nice but still not as slick as could be. Say a want 
to have a central place to lookup all classes with the Foo() 
attribute on it. The classes can be in several files of course so 
there are two ways of registering them at compile time to be 
available for runtime lookups:

1, Add a static module contructor to each module that registers 
the Foo() attribut'ed classes. This constructor is probably 
generated at compile time and mixed into the module as a 
one-liner.

2, Add a "registration" module that imports all other modules in 
order to filter out Foo() attributed classes and register them 
for runtime usage.

The first method is bad because you need to mixin code manually 
for each module you have.

The second method is bad because you need to keep the 
"registration" file in sync with any modules 
added/renamed/removed.

A couple of months ago I was working on an extension to the 
string import() feature of D: It would simply treat a import(*) 
as returning the directory listing of the imports path. From that 
the list of .d file could be figured out and imported at compile 
time. Then the the runtime information could be extracted at 
compile time with no fuzz.

/Jonas
Oct 05 2015
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 5 October 2015 at 09:08:56 UTC, Jonas Drewsen wrote:

 Say a want to have a central place to lookup all classes with 
 the Foo() attribute on it.


You can also use the RTInfo hook in druntime's object.d to build 
that stuff in a central location.

Of course, since that's a centralized file, it can at best be 
changed on a per-project basis...

There's also only RTInfo for types, not functions and variables, 
but still, it'd work for the case of building a list of classes.
Oct 05 2015
parent Jonas Drewsen <nospam4321 hotmail.com> writes:
On Monday, 5 October 2015 at 13:38:43 UTC, Adam D. Ruppe wrote:

 On Monday, 5 October 2015 at 09:08:56 UTC, Jonas Drewsen wrote:

 Say a want to have a central place to lookup all classes with 
 the Foo() attribute on it.


 You can also use the RTInfo hook in druntime's object.d to 
 build that stuff in a central location.

 Of course, since that's a centralized file, it can at best be 
 changed on a per-project basis...


And it wouldn't work if you want to put your app on e.g. 
code.dlang.org for others to compile using their standard 
druntime. Furthermore RTInfo seems kind of reserved for GC atm.


 There's also only RTInfo for types, not functions and 
 variables, but still, it'd work for the case of building a list 
 of classes.


Types goes a long way for sure. Personally I need both types and 
functions.
Oct 05 2015
prev sibling next sibling parent Jan Johansson <jan.johansson.mr gmail.com> writes:
On Monday, 5 October 2015 at 09:08:56 UTC, Jonas Drewsen wrote:

 On Monday, 5 October 2015 at 06:18:45 UTC, Manu wrote:

 [...]


 This is all nice but still not as slick as could be. Say a want 
 to have a central place to lookup all classes with the Foo() 
 attribute on it. The classes can be in several files of course 
 so there are two ways of registering them at compile time to be 
 available for runtime lookups:

 [...]


Thanks Jonas, for your very good input.
Oct 05 2015
prev sibling parent reply extrawurst <stephan extrawurst.org> writes:
On Monday, 5 October 2015 at 09:08:56 UTC, Jonas Drewsen wrote:

 On Monday, 5 October 2015 at 06:18:45 UTC, Manu wrote:

 [...]


 [...]

 The first method is bad because you need to mixin code manually 
 for each module you have.

 The second method is bad because you need to keep the 
 "registration" file in sync with any modules 
 added/renamed/removed.

 [...]

 /Jonas


Method 1: Adding a static c'tor to every module does not work 
very long in practice (as experienced first handed) cause you are 
in "cyclic c'tor hell" very quick...

--Stephan
Oct 07 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 7 October 2015 at 07:08:39 UTC, extrawurst wrote:

 Method 1: Adding a static c'tor to every module does not work 
 very long in practice (as experienced first handed) cause you 
 are in "cyclic c'tor hell" very quick...


The cyclic dependency checking in druntime makes static 
constructors almost unusable. It's a case of being protected so 
much while trying to do something that you can't do what you're 
trying to do. There really should be some way IMHO to have 
something similar to  trusted where you tell the compiler/runtime 
that the order does not matter for a particular static 
constructor and that it should just trust the programmer on that, 
but Walter rejected the idea when it was brought up.

- Jonathan M Davis
Oct 07 2015
parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 07 Oct 2015 08:41:30 +0000
schrieb Jonathan M Davis <jmdavisProg gmx.com>:


 On Wednesday, 7 October 2015 at 07:08:39 UTC, extrawurst wrote:

 Method 1: Adding a static c'tor to every module does not work 
 very long in practice (as experienced first handed) cause you 
 are in "cyclic c'tor hell" very quick...


 
 The cyclic dependency checking in druntime makes static 
 constructors almost unusable. It's a case of being protected so 
 much while trying to do something that you can't do what you're 
 trying to do. There really should be some way IMHO to have 
 something similar to  trusted where you tell the compiler/runtime 
 that the order does not matter for a particular static 
 constructor and that it should just trust the programmer on that, 
 but Walter rejected the idea when it was brought up.
 
 - Jonathan M Davis


With LDC you can abuse the C constructor mechanism to do that. GDC does
not yet expose C constructors to D code but it's on my list and it's
easy to implement.
Oct 07 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 7 October 2015 at 10:03:11 UTC, Johannes Pfau wrote:

 Am Wed, 07 Oct 2015 08:41:30 +0000
 schrieb Jonathan M Davis <jmdavisProg gmx.com>:


 On Wednesday, 7 October 2015 at 07:08:39 UTC, extrawurst wrote:

 Method 1: Adding a static c'tor to every module does not 
 work very long in practice (as experienced first handed) 
 cause you are in "cyclic c'tor hell" very quick...


 
 The cyclic dependency checking in druntime makes static 
 constructors almost unusable. It's a case of being protected 
 so much while trying to do something that you can't do what 
 you're trying to do. There really should be some way IMHO to 
 have something similar to  trusted where you tell the 
 compiler/runtime that the order does not matter for a 
 particular static constructor and that it should just trust 
 the programmer on that, but Walter rejected the idea when it 
 was brought up.
 
 - Jonathan M Davis


 With LDC you can abuse the C constructor mechanism to do that. 
 GDC does not yet expose C constructors to D code but it's on my 
 list and it's easy to implement.


I'm not quite sure what you mean by C constructors, so I don't 
know how that works, but unless it's in all of the compilers, I 
don't think that it's really worth much ultimately. And we _do_ 
have workarounds already. std.stdio is an example of one such 
module where what is essentially its static constructor is called 
by another module in order to break the cycle. But then you lose 
out on the special benefits of static constructors with regards 
to initializing stuff like immutable objects, which can be a 
problem - particularly when stuff like pure gets involved.

Honestly, I think that if we don't want it to be considered 
borderline bad practice to use static constructors, I think that 
we need a solution for this that allows them to function normally 
without being concerned about circular dependencies (at least 
when the programmer marks them as such). And if the C constructor 
mechanism that you're talking about somehow does that, then 
great, but it needs to be standard D, or it's a pretty limited 
solution.

- Jonathan M Davis
Oct 07 2015
parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 07 Oct 2015 10:50:38 +0000
schrieb Jonathan M Davis <jmdavisProg gmx.com>:


 On Wednesday, 7 October 2015 at 10:03:11 UTC, Johannes Pfau wrote:

 Am Wed, 07 Oct 2015 08:41:30 +0000
 schrieb Jonathan M Davis <jmdavisProg gmx.com>:


 On Wednesday, 7 October 2015 at 07:08:39 UTC, extrawurst wrote:

 Method 1: Adding a static c'tor to every module does not 
 work very long in practice (as experienced first handed) 
 cause you are in "cyclic c'tor hell" very quick...


 
 The cyclic dependency checking in druntime makes static 
 constructors almost unusable. It's a case of being protected 
 so much while trying to do something that you can't do what 
 you're trying to do. There really should be some way IMHO to 
 have something similar to  trusted where you tell the 
 compiler/runtime that the order does not matter for a 
 particular static constructor and that it should just trust 
 the programmer on that, but Walter rejected the idea when it 
 was brought up.
 
 - Jonathan M Davis


 With LDC you can abuse the C constructor mechanism to do that. 
 GDC does not yet expose C constructors to D code but it's on my 
 list and it's easy to implement.


 
 I'm not quite sure what you mean by C constructors, so I don't 
 know how that works, but unless it's in all of the compilers, I 
 don't think that it's really worth much ultimately. 


Most C compilers support some __attribute(constructor)__ feature.
In LDC this translates to something like this:

import ldc.attribute;

 attribute("constructor") extern(C) void myConstructor()
{
}

and GDC will use basically the same syntax. It's not really meant for
end users though. We can use this to implement some parts of
the druntime shared DSO handling. And it's useful for betterC programs
or embedded systems, as the implementation in the (C) runtime is very
simple. But you're right, this is probably not a good / general purpose
solution. It just wanted to point out that there's another possible
workaround ;-)


 And we _do_ 
 have workarounds already. std.stdio is an example of one such 
 module where what is essentially its static constructor is called 
 by another module in order to break the cycle. But then you lose 
 out on the special benefits of static constructors with regards 
 to initializing stuff like immutable objects, which can be a 
 problem - particularly when stuff like pure gets involved.
 
 Honestly, I think that if we don't want it to be considered 
 borderline bad practice to use static constructors, I think that 
 we need a solution for this that allows them to function normally 
 without being concerned about circular dependencies (at least 
 when the programmer marks them as such).


I think it wouldn't be hard to implement a solution. I guess it's
mainly a political discussion :-(

An UDA which can be placed on functions with certain signatures would
be nice. And this allows having multiple static ctors per module
(Could be useful for constructors in mixins):

 constructor void myConstructor() //compiler enforces function signature
{
}


 And if the C constructor 
 mechanism that you're talking about somehow does that, then 
 great, but it needs to be standard D, or it's a pretty limited 
 solution.


If we can have a standard solution in DMD there are better ways than
relying on C constructors. The druntime has absolutely no control over
'C constructors' (they're called by the C runtime) which can lead to
problems in some corner cases. C constructors are mainly useful for low
level or embedded code. And they're useful as long as we don't have a
standard solution, as GDC/LDC can implement them without DMDs
approval ;-)
Oct 07 2015
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, 7 October 2015 at 14:59:37 UTC, Johannes Pfau wrote:

 I think it wouldn't be hard to implement a solution. I guess 
 it's mainly a political discussion :-(


It should be fairly easy to implement a solution - especially if 
it's simply marking the static constructor to say that it doesn't 
depend on any other module's static constructor having run 
(obviously, it gets far more complicated if you try and make it 
so that the programmer indicates which modules it doesn't depend 
on in order to have other cyclic dependencies caught if they 
creep into the code). druntime just needs to know that the order 
of that static constructor doesn't matter with regards to the 
others when it's deciding the order to run them in. I expect that 
actually making the change to druntime would be pretty simple.

The core problem is definitely that Walter objects to the idea 
(IIRC on the grounds that it's too easy for circular dependencies 
to creep in later and then not be caught). If he agreed to it, it 
could probably be implemented fairly quickly.

- Jonathan M Davis
Oct 07 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
On Monday, 5 October 2015 at 04:02:58 UTC, Jan Johansson wrote:

 Sure it can, but I want a dynamic behavior, not a static 
 behavior. Attributes are compiler directives. They are not 
 available at runtime according to the specification of D 
 language. Now take the example at: 
 http://ddili.org/ders/d.en/uda.html, and separate the code into 
 one library that defines the attributes and "printAsXML", keep 
 the consumer of the attributes (main function) and get the same 
 slick functionality. It can't be done, because UDA is not 
 runtime available.


printAsXML is templated on the input type and hence can access 
all its attributes at compile time. If you're familiar with WCF, 
you should know that all types going through a data contract are 
known at compile time.
Oct 05 2015
parent reply Jan Johansson <jan.johansson.mr gmail.com> writes:
On Monday, 5 October 2015 at 08:44:03 UTC, Kagamin wrote:

 On Monday, 5 October 2015 at 04:02:58 UTC, Jan Johansson wrote:

 Sure it can, but I want a dynamic behavior, not a static 
 behavior. Attributes are compiler directives. They are not 
 available at runtime according to the specification of D 
 language. Now take the example at: 
 http://ddili.org/ders/d.en/uda.html, and separate the code 
 into one library that defines the attributes and "printAsXML", 
 keep the consumer of the attributes (main function) and get 
 the same slick functionality. It can't be done, because UDA is 
 not runtime available.


 printAsXML is templated on the input type and hence can access 
 all its attributes at compile time. If you're familiar with 
 WCF, you should know that all types going through a data 
 contract are known at compile time.


Yes, I know WCF more than well, doing my own bindings, federated 
security bindings, you name it. I also know that WCF works with 
attribute values during runtime, through reflections and extract 
aspect oriented instructions on how to treat types. It would be 
slick to do the same in D.
Oct 05 2015
parent reply Kagamin <spam here.lot> writes:
On Monday, 5 October 2015 at 16:40:06 UTC, Jan Johansson wrote:

 Yes, I know WCF more than well, doing my own bindings, 
 federated security bindings, you name it. I also know that WCF 
 works with attribute values during runtime, through reflections 
 and extract aspect oriented instructions on how to treat types. 
 It would be slick to do the same in D.



doesn't mean WCF accepts arbitrary types in contracts: 
http://stackoverflow.com/questions/7444851/why-knowntypeattribute-need-in-wcf
Oct 06 2015
parent reply Jan Johansson <jan.johansson.mr gmail.com> writes:
On Tuesday, 6 October 2015 at 14:28:42 UTC, Kagamin wrote:

 On Monday, 5 October 2015 at 16:40:06 UTC, Jan Johansson wrote:

 Yes, I know WCF more than well, doing my own bindings, 
 federated security bindings, you name it. I also know that WCF 
 works with attribute values during runtime, through 
 reflections and extract aspect oriented instructions on how to 
 treat types. It would be slick to do the same in D.



 doesn't mean WCF accepts arbitrary types in contracts: 
 http://stackoverflow.com/questions/7444851/why-knowntypeattribute-need-in-wcf


I know about that too, the KnownType is applied to types that the 
DataContractSerializer (not the XmlSerializer) must be aware of 
before it can serialize the type (you enlist the type to the 
serializer). Thanks.
Oct 06 2015
parent reply Kagamin <spam here.lot> writes:
On Tuesday, 6 October 2015 at 16:38:06 UTC, Jan Johansson wrote:

 I know about that too, the KnownType is applied to types that 
 the DataContractSerializer (not the XmlSerializer) must be 
 aware of before it can serialize the type (you enlist the type 
 to the serializer). Thanks.


For a general purpose serialization it can make sense to support 
arbitrary types, but WCF is a communication technology that 
warrants contracts including and especially web-services that 
usually require full contract to be expressed in WSDL in order to 
be cross-platform.
Oct 07 2015
parent reply Jan Johansson <jan.johansson.mr gmail.com> writes:
On Wednesday, 7 October 2015 at 08:27:18 UTC, Kagamin wrote:

 On Tuesday, 6 October 2015 at 16:38:06 UTC, Jan Johansson wrote:

 I know about that too, the KnownType is applied to types that 
 the DataContractSerializer (not the XmlSerializer) must be 
 aware of before it can serialize the type (you enlist the type 
 to the serializer). Thanks.


 For a general purpose serialization it can make sense to 
 support arbitrary types, but WCF is a communication technology 
 that warrants contracts including and especially web-services 
 that usually require full contract to be expressed in WSDL in 
 order to be cross-platform.


Yepp, that's the point of SOA :-) We are in agreement.
Oct 07 2015
parent Kagamin <spam here.lot> writes:
On Wednesday, 7 October 2015 at 16:09:37 UTC, Jan Johansson wrote:

 Yepp, that's the point of SOA :-) We are in agreement.


:) Since the contract is known upfront, it can be processed at 

it can't do a thing at compile time.
Oct 08 2015
prev sibling parent reply krzaq <dlangmailinglist krzaq.cc> writes:
On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

 Are there any critical frameworks or libraries that are holding 
 you back in fully investing in D? Obviously I think D is an 
 awesome language, but some frameworks/libraries hold me back, 
 wish I could do everything in D.


Nothing major for me, just a plentitude of small problems.

For example: you can't rely on Clock.currTime.toString() (or ISO 
string overloads) to provide a reliable fixed-length 
representation for logging purposes and the class mysteriously 
lacks any kind of .format() function that's available pretty much 
everywhere else.

When I decide to write a small tool in D, I pretty ensure that, 
next to D's awesome features, I'll be exposed to some ugly warts 
of the language or its ecosystem. My experience with DUB packages 
(btw, there should be a word for it, like Ruby's gems) is that, 
at least on Windows, they are often out of date and require 
undocumented build steps to even build -- and that's before you 
try to use them and hit the wall of RTFS solutions to 
documentation.

TL;DR: instead of focusing on solving my problem, I have to focus 
on solving problems unknown in other languages. Saving time by 
using fantastic language features and then wasting twice as much 
reinventing the wheel is not what I want to do.
Oct 06 2015
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, 6 October 2015 at 13:31:25 UTC, krzaq wrote:

 For example: you can't rely on Clock.currTime.toString() (or 
 ISO string overloads) to provide a reliable fixed-length 
 representation for logging purposes and the class mysteriously 
 lacks any kind of .format() function that's available pretty 
 much everywhere else.


The ISO standard doesn't really say what to do with the number of 
decimal places, and it's usually cleanest to not have a bunch of 
trailing zeroes, which is why the to*String functions are the way 
they are. I was thinking about adding a way to tell it the number 
of digits though, since std.experimental.logger had to deal with 
that. It's not something that's generally come up though. I 
really should have gotten the custom formatting done before now, 
but it is on the todo list. For most stuff though, it's best to 
just use toISOExtString, since it's a standard format and quite 
legible (unlike straight ISO - I don't know why they even have 
the ISO format in addition to the extended ISO format; it's 
pretty much impossible to read).

- Jonathan M Davis
Oct 06 2015