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.
Yes, but that's only because C# doesn't support DbI, it also 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.
Yes, but that's only because C# doesn't support DbI, it also 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 compile time and D can do it. C# has to do it at run time because 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