Re: Beta D 2.070.0-b1

2016-01-12 Thread Jacob Carlborg via Digitalmars-d-announce

On 2016-01-12 01:54, Martin Nowak wrote:


Makes sense https://github.com/D-Programming-Language/dub/issues/747.
The compiler does check assertions in unittest blocks even in release
builds, right?


Yes, just verified. Actually, it doesn't matter where the assertion is 
placed, as long as -unittest is passed.


--
/Jacob Carlborg


Re: My LLVM talk @ FOSDEM'16

2016-01-12 Thread Kai Nacke via Digitalmars-d-announce

On Friday, 8 January 2016 at 03:13:22 UTC, Bubbasaur wrote:

It will be recorded or live?

Bubba.


The last 2 years there was a live stream and recording.

Regards,
Kai


Re: Beta D 2.070.0-b1

2016-01-12 Thread Guillaume Piolat via Digitalmars-d-announce

On Tuesday, 12 January 2016 at 08:12:58 UTC, Jacob Carlborg wrote:


Yes, just verified. Actually, it doesn't matter where the 
assertion is placed, as long as -unittest is passed.


Another surprise.


Re: Official Announcement: 'Learning D' is Released

2016-01-12 Thread jmh530 via Digitalmars-d-announce

On Tuesday, 12 January 2016 at 21:10:28 UTC, John Colvin wrote:


When you want to have control over the process of loading a 
library e.g. if you want it to be an optional dependency at 
runtime.


I've seen the example in the book. I'm just not sure why you 
would want an optional runtime dependency.


Re: Official Announcement: 'Learning D' is Released

2016-01-12 Thread John Colvin via Digitalmars-d-announce

On Tuesday, 12 January 2016 at 20:32:57 UTC, jmh530 wrote:

I'm not sure when you would want to use dynamic bindings.


When you want to have control over the process of loading a 
library e.g. if you want it to be an optional dependency at 
runtime.


Re: Official Announcement: 'Learning D' is Released

2016-01-12 Thread John Colvin via Digitalmars-d-announce

On Tuesday, 12 January 2016 at 22:00:32 UTC, jmh530 wrote:

On Tuesday, 12 January 2016 at 21:10:28 UTC, John Colvin wrote:


When you want to have control over the process of loading a 
library e.g. if you want it to be an optional dependency at 
runtime.


I've seen the example in the book. I'm just not sure why you 
would want an optional runtime dependency.


Anything in your application / library that relies on resources 
that may or may not be available on the user's system. E.g. 
plugins the user wants to load.


Re: Official Announcement: 'Learning D' is Released

2016-01-12 Thread jmh530 via Digitalmars-d-announce

On Sunday, 27 December 2015 at 17:21:24 UTC, Mike Parker wrote:


Thanks guys! That kind of feedback is a good Christmas present 
:)


I'm working through the book now. I'm liking it.

I'm on Chapter 9, which has the Connecting D with C material. At 
the beginning of the chapter you define some terms: dynamic vs. 
static linking, dynamic/static libraries, and dynamic/static 
binding. I think the way you explain these terms assumes that 
someone already has quite a bit of computing knowledge. I googled 
the dynamic/static library stuff and there are some simpler 
explanations online that I can understand. There's less material 
out there on dynamic/static bindings, the way you're talking 
about it. I think I get what you're saying about static bindings, 
but I'm not sure when you would want to use dynamic bindings.


Re: Official Announcement: 'Learning D' is Released

2016-01-12 Thread Mike Parker via Digitalmars-d-announce

On Tuesday, 12 January 2016 at 21:10:28 UTC, John Colvin wrote:

On Tuesday, 12 January 2016 at 20:32:57 UTC, jmh530 wrote:

I'm not sure when you would want to use dynamic bindings.


When you want to have control over the process of loading a 
library e.g. if you want it to be an optional dependency at 
runtime.


For me, the big benefit is that it eliminates the link-time 
dependency on the C library. I don't have to worry about whether 
the dev package is installed on Linux, or the COFF/OMF issues on 
Windows. Reducing dependencies like this makes avoids several 
potential build issues, something particularly good for open 
source projects. You can download the source for an SDL-based 
game, for example, and not worry about which version of the SDL 
development libraries you need to build it.


Another benefit is that the app doesn't need to fail if a 
particular version of a library is not available. For example, 
DerelictUtil, the library which provides the loader for all of 
the Derelict bindings, allows the ability to continue loading if 
certain functions are missing. You can choose to use those 
functions if present and fallback on something else if they 
aren't. If you've ever used OpenGL, you're probably already doing 
this. You can use version 4.x if it's available and fallback to 
3.x if it isn't; extensions are loaded on an as-needed and 
as-available basis. A dynamic binding allows this sort of 
behavior with any library.


One of the entries in, IIRC, Game Programming Gems 2, talked 
about solving the DLL Hell problem with dynamic loading. For me, 
it really just boils down to more convenient builds. I tend to 
prefer it over static or dynamic linking. In fact, dynamic 
linking doesn't even enter the picture for me in D. If I need a 
shared library, I'll just load it myself.