Re: LDC now supports Windows MSVC x86/x64 as first class targets

2016-03-21 Thread Manu via Digitalmars-d-announce
On 22 March 2016 at 03:12, Kagamin via Digitalmars-d-announce
 wrote:
> On Sunday, 20 March 2016 at 14:15:19 UTC, Manu wrote:
>>
>> MSVC debuginfo is very good; it has data such that variables
>> follow their registers around in fully optimised builds, making
>> release build debugging fast and effortless.
>
>
> That's backend feature, there are (usually) no registers on the frontend
> level.

Yes, that's why the C2 backend is useful; it populates the debuginfo
with very high quality data.


Re: LDC now supports Windows MSVC x86/x64 as first class targets

2016-03-21 Thread deadalnix via Digitalmars-d-announce
Got the news first hand by David Majnemer first hand not so long 
ago. Congrats guys :)


Re: LDC now supports Windows MSVC x86/x64 as first class targets

2016-03-21 Thread Kagamin via Digitalmars-d-announce

On Sunday, 20 March 2016 at 14:15:19 UTC, Manu wrote:

MSVC debuginfo is very good; it has data such that variables
follow their registers around in fully optimised builds, making
release build debugging fast and effortless.


That's backend feature, there are (usually) no registers on the 
frontend level.


Re: LDC now supports Windows MSVC x86/x64 as first class targets

2016-03-21 Thread Guillaume Piolat via Digitalmars-d-announce

On Saturday, 19 March 2016 at 13:23:48 UTC, kinke wrote:

Hey all,

I'm proud to announce that MSVC is fully supported now for LDC 
trunk. Rainer Schuetze has implemented MSVC-compatible 
exception handling (available since brand-new LLVM 3.8) for 
LDC, so that we have fully working exception chaining now on 
Win64. Along the way, he also added 32-bit MSVC support and a 
TLS alignment bugfix for Windows < 8.1 (a Windows 
bug/wontfix!). It requires a bleeding edge LLVM though, as 
Rainer's work has uncovered a few LLVM bugs which didn't make 
it into 3.8 final.
So a round of applause for Rainer and the LLVM devs, excellent 
job, thank you very much! Full PDB support for LLVM is also 
underway...





This is great, I don't have to write assembly anymore! Thanks LDC 
team.


mondo - a d library for mongodb

2016-03-21 Thread Andrea Fontana via Digitalmars-d-announce
I just released on behalf of the company I work for 
(http://lab.2night.it) "mondo", a library to work with mongodb.


Mondo is a collection of classes (and struct) built over 
mongo-c-driver. Low-level bindings are generated automatically 
using dstep + a small script to patch some issues with original 
source.


More info on github page. It obviusly depends on mongo-c-driver 
library (quite easy to compile).


GH: https://github.com/2night/mondo
Dub: http://code.dlang.org/packages/mondo

Comments are welcome.

Andrea Fontana


Re: d-vulkan, automatically generated D bindings for Vulkan

2016-03-21 Thread Manuel Maier via Digitalmars-d-announce

On Monday, 21 March 2016 at 09:27:35 UTC, Manuel Maier wrote:

On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:

https://github.com/ColonelThirtyTwo/dvulkan

[...]


@Alex Parrill: Thanks for sharing! Looks nice. I was just 
wondering... why did you write the generator in python and not 
in D? Just curious :)


I see now... The Vulkan docs provide python modules for easier 
integration already. Makes sense.


Re: d-vulkan, automatically generated D bindings for Vulkan

2016-03-21 Thread Manuel Maier via Digitalmars-d-announce

On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:

https://github.com/ColonelThirtyTwo/dvulkan

[...]


@Alex Parrill: Thanks for sharing! Looks nice. I was just 
wondering... why did you write the generator in python and not in 
D? Just curious :)


Re: d-vulkan, automatically generated D bindings for Vulkan

2016-03-21 Thread burjui via Digitalmars-d-announce

On Sunday, 20 March 2016 at 00:52:48 UTC, Alex Parrill wrote:

If I import a xcb_connection_t from some bindings,
it ties d-vulkan to those bindings, which I'd rather not do.


By the magic of D:

version (Linux)
{
import xcb.xcb;
}

...

version (Linux)
{
xcb_connection_t* con;
}

Also you can make xcb-d dependency optional in DUB.