I forgot to add that bindings to a UI framework would open the door
for D in a lot more projects. Qt is the option that sucks the least by
a significant margin.
force-inline would also be useful.

On Sunday, 31 May 2015 at 03:03:22 UTC, Danni Coy wrote:
> so is std.xml the exception? How many other parts of the standard
> library are like that?

A few, but not many. Mostly, it's stuff that was done for D1 or very early D2 which hasn't been removed or replaced yet. std.xml, std.json, and std.stream are what come to mind. There may be a few others, but most of the stuff in Phobos is more recent and is properly maintained. Mostly, it's a question of what hasn't been added to the standard library yet rather than what needs to be replaced.

- Jonathan M Davis

On Wednesday, 3 June 2015 at 03:15:32 UTC, Jonathan M Davis wrote:
> On Sunday, 31 May 2015 at 03:03:22 UTC, Danni Coy wrote:
>> so is std.xml the exception? How many other parts of the standard
>> library are like that?
>
> A few, but not many. Mostly, it's stuff that was done for D1 or very early D2 which hasn't been removed or replaced yet. std.xml, std.json, and std.stream are what come to mind. There may be a few others, but most of the stuff in Phobos is more recent and is properly maintained. Mostly, it's a question of what hasn't been added to the standard library yet rather than what needs to be replaced.
>
> - Jonathan M Davis

std.signals

For a small amount of software at work I'm able to use D. Most recently, I used D & vibe.d to communicate with a conveyor belt system for a warehouse. I'd use it more but most of our code and data is tied into a proprietary ecosystem (language, database, etc.). Slowly, we're moving away from this ecosystem toward the JVM, but I will use D where native code makes sense.

Thanks,
Kelet

On 3/06/2015 3:35 p.m., Kelet wrote:
> For a small amount of software at work I'm able to use D. Most recently,
> I used D & vibe.d to communicate with a conveyor belt system for a
> warehouse. I'd use it more but most of our code and data is tied into a
> proprietary ecosystem (language, database, etc.). Slowly, we're moving
> away from this ecosystem toward the JVM, but I will use D where native
> code makes sense.
>
> Thanks,
> Kelet

Okay, just so I know you haven't had to deal with one of the worst languages ever. It's not jade is it?

On Wed, 03 Jun 2015 11:24:33 +1000, Danni Coy via Digitalmars-d wrote:

> I forgot to add that bindings to a UI framework would open the door for D in a lot more projects. Qt is the option that sucks the least by a significant margin.

it was like that until Qt5. now it suxalot.

anyway, while Qt bindings still must be created, GtkD is already here.

On Wed, 03 Jun 2015 03:27:35 +0000, weaselcat wrote:

> On Wednesday, 3 June 2015 at 03:15:32 UTC, Jonathan M Davis wrote:
>> On Sunday, 31 May 2015 at 03:03:22 UTC, Danni Coy wrote:
>>> so is std.xml the exception? How many other parts of the standard library are like that?
>>
>> A few, but not many. Mostly, it's stuff that was done for D1 or very early D2 which hasn't been removed or replaced yet. std.xml, std.json, and std.stream are what come to mind. There may be a few others, but most of the stuff in Phobos is more recent and is properly maintained. Mostly, it's a question of what hasn't been added to the standard library yet rather than what needs to be replaced.
>>
>> - Jonathan M Davis
> 
> std.signals

and there is an excellect replacement[1]!

[1] https://github.com/phobos-x/phobosx/blob/master/source/phobosx/ signal.d

On Wednesday, 3 June 2015 at 03:47:00 UTC, Rikki Cattermole wrote:
> On 3/06/2015 3:35 p.m., Kelet wrote:
>> For a small amount of software at work I'm able to use D. Most recently,
>> I used D & vibe.d to communicate with a conveyor belt system for a
>> warehouse. I'd use it more but most of our code and data is tied into a
>> proprietary ecosystem (language, database, etc.). Slowly, we're moving
>> away from this ecosystem toward the JVM, but I will use D where native
>> code makes sense.
>>
>> Thanks,
>> Kelet
>
> Okay, just so I know you haven't had to deal with one of the worst languages ever. It's not jade is it?

No, our ecosystem revolves around a proprietary and archaic dialect of COBOL.

Thanks,
Kelet

On 3/06/2015 5:22 p.m., Kelet wrote:
> On Wednesday, 3 June 2015 at 03:47:00 UTC, Rikki Cattermole wrote:
>> On 3/06/2015 3:35 p.m., Kelet wrote:
>>> For a small amount of software at work I'm able to use D. Most recently,
>>> I used D & vibe.d to communicate with a conveyor belt system for a
>>> warehouse. I'd use it more but most of our code and data is tied into a
>>> proprietary ecosystem (language, database, etc.). Slowly, we're moving
>>> away from this ecosystem toward the JVM, but I will use D where native
>>> code makes sense.
>>>
>>> Thanks,
>>> Kelet
>>
>> Okay, just so I know you haven't had to deal with one of the worst
>> languages ever. It's not jade is it?
>
> No, our ecosystem revolves around a proprietary and archaic dialect of
> COBOL.
>
> Thanks,
> Kelet

Thank goodness. Nothing spew worthy.

Jacob Carlborg <doob@me.com> writes:

> On 2015-06-01 18:38, Dan Olson wrote:
>
>> Yeah, we need to work on getting iOS support into LDC main offering. For now there is a stumbling block (at least perceived by me) of requiring a patched LLVM to support TLS on iOS.
>
> How you tried contributing that back to LLVM? And in that case, what's the status?

Not yet.  I greedily work on puzzles I think I can solve..  On the other hand, a Rust dev last year was able to use the iOS TLS patch to LLVM and perhaps made some progress.  Or found another way.

http://vhbit.net/blog/2014/04/12/rust-on-ios/

Reports good progress beginning of this year too.

http://vhbit.net/blog/2015/01/18/rust-for-ios-status-update/

I've lately been work on unwinding SjLj exception in Fibers, because until the 2.067, there weren't any unittests to show it off.  It was funny seeing an exception thrown in one Fiber being caught by another Fiber! Luckily I've got that solved now.
-- 
Dan