Re: Some feedback on the website.

[Jacob Carlborg via Digitalmars-d]

On 2015-12-17 23:40, Andrei Alexandrescu wrote:


We are already using vibe.d for the Phobos page-per-name documentation.
As far as I can tell the initiative has been a qualified success.


What's left/stopping us from using this as the default documentation?


The main problem there is that there are not enough folks to maintain
the vibe-related artifacts. Basically when Sönke is busy with something
else, any issue may wait indefinitely. (I haven't followed that lately,
possibly things have improved as of late.)

In order to make the use of vibe.d entirely successful across dlang.org
and dconf.org, we need to show robust gains from using it for Phobos. As
virtually the sole maintainer of dconf.org, I'd feel definitely
motivated to use vibe.d if there was good evidence of thriving
collaboration around the use of it on http://dlang.org/library.

Jacob, are you willing to ramp up you contribution to the vibe.d-related
parts of Phobos? That would go a long way toward convincing everyone of
the productivity gains of using it instead of ddoc (or others).


I would like to but I'm very busy as well. In addition to that I have 
basically no knowledge of the internals of the vibe.d related parts. I 
had a look at some PR's for Dub (I think) that Sönke called out for help 
with. I didn't feel I could add much help to that.


Is there anything more specific you're thinking about?

--
/Jacob Carlborg

Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

[ZombineDev via Digitalmars-d]

On Thursday, 17 December 2015 at 19:56:32 UTC, Jakob Jenkov wrote:

Hi guys,

I read from some of the other forum threads that D is being 
criticized for not being usable for real time / low latency 
systems because it has a GC.


First of all, such system are already being written in Java. 
Google "Martin Thompson" and LMAX and you will see. Or Aeron 
(also Java and Martin Thompson).


Second, when Java has been used to develop such systems, the GC 
has been avoided as much as possible - which is even easier to 
do with D than Java.


So, it's a load of BS that D's GC should somehow make it 
impossible to make real time / low latency software.


While developing a real-time system with a GC maybe possible, I 
think D makes things much easier by:
+ Having deterministic GC - the GC will only run if your code 
triggers it. If you don't want to use the GC, don't write code 
that triggers it.
+ Being usable without the GC - that way turning into a better C 
/ C++. You can manage all resources yourself, just like you would 
if you were using C/C++.
+ It's not that hard to write your own GC for D. The hard part is 
making it high-performance which is intrinsic to the problem 
domain and not to D specifically.
+ Another good strategy is to start with a GC and when you reach 
the point where you know (e.g. by profiling) where are your 
performance critical parts of your system you can rewrite them 
with high-performance D code (taking advantage of the 
understanding of the problem domain that you've gained in the 
process).
A general advice is to prefer free functions to OOP heirarchies, 
because OOP inheritance often leads to needles coupling. Use 
static polymorphism instead of dynamic dispatch, where possible. 
Often classical OOP polymorphism is unneeded. And in the few 
places where you need to take runtime decisions, switch 
statements are easier to debug. Reduce mutable shared state - 
ranges, functional programming and the 'shared' atrribute really 
help with that.


Bottom line is, if you are competent enough, you can be 
successfull with D, just like you would be if you were using 
C/C++. D's superior compile-time meta programming allows you to 
express zero cost abstractions give you the edge that makes 
things more enjoyable.


There are several open-source kernels written in D that are proof 
of the above:

https://github.com/Vild/PowerNex
https://github.com/Bloodmanovski/Trinix
https://github.com/xomboverlord/xomb
Adam Ruppe has a chapter about bare-metal programming with D in 
his Cookbook.

Re: Wishlist for D

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 18 December 2015 at 02:22:48 UTC, Yota wrote:
My biggest wish is to see the design phase of D3 kick off.  
Ideally, with a big fat label on it saying "Will not be ready 
for production for at least 5 or 10 years.  Your code WILL be 
broken sooner than later."  I feel like D is in a rut with all 
the best things being shot down because of breaking code. (I 
understand why we can't break code at this point, but that 
doesn't make it any less frustrating.)


Exactly.

Re: D float types operations vs C++ ones

[Ola Fosheim Gr via Digitalmars-d-learn]

On Friday, 18 December 2015 at 07:30:52 UTC, drug wrote:

What I mean about order of operations is that if you go
  a = b*a+c*c + e;
the compiler is free to rewrite that as
float __tmp0 = a*b;
float __tmp1 = c*c;
and then do either of
float __tmp2 = __tmp0+__tmp1;
a = __tmp2 + e;
OR
float __tmp2 = __tmp0+e;
a = __tmp2+__tmp1;


I see, thanks to all!


I don't think this can be right, unless you use some kind of 
fast-math optimizer.


But:

Modern C++ compilers try to support ieee754-2008, which is needed 
to get reproducible results. D is based on the older 1985 
version, and there is no announced effort to make it modern.

Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

[Ola Fosheim Grøstad via Digitalmars-d]

On Thursday, 17 December 2015 at 19:56:32 UTC, Jakob Jenkov wrote:
So, it's a load of BS that D's GC should somehow make it 
impossible to make real time / low latency software.


D supports most of C (but not all), so it is obviously possible. 
That's never been the argument. D's low performance global 
hog-the-world mark-sweep GC is simply too costly for soft real 
time. In hard real time you cannot even use malloc and have to 
turn off swapping for the memory ranges you stream from, so 
that's a different topic.


It is currently less work to use C++, overall. People won't move 
from C++ unless the new language is better throughout. That's the 
point. You have to be significantly better than C++, Rust and 
Swift to be considered.


And C++, Rust and Swift are improving. So, if D is to be 
considered then changes to D semantics not only has to compete 
with these languages as they are today. Improvements to D is 
competing with where C++, Rust and Swift will be in 2-3 years.

Re: Some feedback on the website.

[John Colvin via Digitalmars-d]

On Thursday, 17 December 2015 at 20:21:00 UTC, Adam D. Ruppe 
wrote:
On Thursday, 17 December 2015 at 19:51:19 UTC, Walter Bright 
wrote:
That has nothing to do with Ddoc, and is more about the 
organization of the files on github. Switching to another 
framework does nothing for that.


Well, I basically agree with that.

I know it is hard to keep track of whose position is what in a 
thread like this, but my problem isn't with ddoc per se, it is 
more that the current process is very complicated and pretty 
opaque.


Yes. This. And tbh it's the opaqueness that's the biggest problem.

Re: D could catch this wave: web assembly

[Ola Fosheim Grøstad via Digitalmars-d]

On Thursday, 17 December 2015 at 20:22:41 UTC, yawniek wrote:

https://hacks.mozilla.org/2015/12/compiling-to-webassembly-its-happening/


Thanks for sharing! This looks promising.

Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

[Claude via Digitalmars-d]

Bottom line is, if you are competent enough, you can be 
successfull with D, just like you would be if you were using 
C/C++. D's superior compile-time meta programming allows you to 
express zero cost abstractions give you the edge that makes 
things more enjoyable.


There are several open-source kernels written in D that are 
proof of the above:

https://github.com/Vild/PowerNex
https://github.com/Bloodmanovski/Trinix
https://github.com/xomboverlord/xomb
Adam Ruppe has a chapter about bare-metal programming with D in 
his Cookbook.


I do think D may be a perfectly valid real-time language. And 
indeed, I believe that the GC is not an issue (you can disable 
it, question solved).


However, is D a proper Embedded System language? I'm not pretty 
sure it's there yet.
Plain C rules the world of embedded systems. All the RTES 
programmers I've met are reluctant to even use C++.


If you cannot program a 16-bit PIC in D, then D will not replace 
C at all (but is it meant to?).


The open-source kernels above are targeted at PC architecture.
I know some work have been done to make bare-metal OS targeted at 
ARM. I don't know what's the state of those projects, and I'd 
love to make my own once I have time (based on Rasberry Pi for 
instance).


To validate D as a proper Real-Time Embedded System, one would 
have to make a proper bare-metal OS a ARMv5 chip (for example). 
Write your Interrupt Service Routines in assembly calling D 
functions, program the MMU, the different hardware blocks (UART, 
INTC, USB etc).
And the API of such an OS would benefit of the expressiveness 
power of D (templates, traits UDA etc) and not just be a C-style 
clone, with an efficiency similar to C (at least same CPU load).

Re: DlangIDE - initial GDB debugger support

[Vadim Lopatin via Digitalmars-d-announce]

On Thursday, 17 December 2015 at 08:27:05 UTC, ZombineDev wrote:

Initial GDB debugging support is implemented.

You can start / stop debugging, set breakpoints, step 
in/out/over, continue.


TODO: stack trace & local variables display


As well, following features implemented:
- bookmarks in source files (toggle, go to next/prev)
- recent workspace list


Exellent progress! Congrats!


GDB support improvements: stack and local variables windows added.

Re: Some feedback on the website.

[Walter Bright via Digitalmars-d]

On 12/17/2015 11:47 PM, Jacob Carlborg wrote:

Well, see for yourself [1]. None of the comments are related to the content. The
content is the easy part.

[1] https://github.com/D-Programming-Language/dlang.org/pull/1039


I did have a look. Most of the PR is code and content, not markup. And most of 
the markup that is there is straightforward, like marking pages with $(P ... ).


I've written quite a bit of the dlang site.

Re: Wishlist for D

[rsw0x via Digitalmars-d]

On Friday, 18 December 2015 at 02:22:48 UTC, Yota wrote:
On Wednesday, 16 December 2015 at 12:06:17 UTC, Ola Fosheim 
Grøstad wrote:
On Wednesday, 16 December 2015 at 07:41:45 UTC, tsbockman 
wrote:

[...]


Good to see that there is some support for a nextgen version 
of D. :)


My biggest wish is to see the design phase of D3 kick off.  
Ideally, with a big fat label on it saying "Will not be ready 
for production for at least 5 or 10 years.  Your code WILL be 
broken sooner than later."  I feel like D is in a rut with all 
the best things being shot down because of breaking code. (I 
understand why we can't break code at this point, but that 
doesn't make it any less frustrating.)


I love almost all of your wishes. =p


nearly every D release has at least one breaking change already

Re: Wishlist for D

[Jonas Drewsen via Digitalmars-d]

On Tuesday, 1 December 2015 at 16:43:55 UTC, Ozan wrote:

Hi

We all have experience with several programming languages and 
the great ideas implemented there. It is close to Xmas 


The one wish I have is to be able to call stuff directly without 
needing to import the module (like you can in c#):


std.stdio.writeln("foo")

and not

import std.stdio;
writeln("foo");

Simple thing - but used regularly enough to be quite annoying not 
to have.


I wonder if there are some kind of parsing/semantic issues with 
supporting it?

Re: Trying to build dlang.org - what am I doing wrong

[Sönke Ludwig via Digitalmars-d]

Am 17.12.2015 um 09:48 schrieb wobbles:

So - the conversation about the website/documentation piqued my interest
a bit and I decided to have a go at making the documentation more readable.

However, reading the instructions from:
http://wiki.dlang.org/Starting_as_a_Contributor#Fetch_and_build_dlang.org

It should be a simple matter of:
```bash
mkdir -p ~/code; cd ~/code
git clone https://github.com/D-Programming-Language/dlang.org
cd dlang.org
make -f posix.mak LATEST=2069.2
```

However, I get a std.net.curl error during compilation of dub (luckily
dlang.org doesn't depend on dub, so it doesn't particularly matter and I
can carry on with my tinkering).

http://pastebin.com/q41AnJyr

I assume theres a problem with the makefiles here - or is it stupid user
syndrome?


This is supposedly an issue in DUB's build.sh that has recently been 
fixed on GIT master [1]. The problem is caused by the uncommon 
definition of the $DC variable in posix.mak that resulted in build.sh 
not recognizing it as DMD and skipping the necessary linker workaround 
(libphobos2 needs to be passed after libcurl, but by default libphobos2 
always gets passed first).


Workaround is to edit posix.mak and change
  DC="$(abspath ${STABLE_DMD}) -conf=$(abspath ${STABLE_DMD_CONF})"
to
  DC=dmd

in the "${DUB}:" target.

[1]: https://github.com/D-Programming-Language/dub/pull/726

Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

[bachmeier via Digitalmars-d]

On Friday, 18 December 2015 at 09:19:29 UTC, Ola Fosheim Grøstad 
wrote:


Improvements to D is competing with where C++, Rust and Swift 
will be in 2-3 years.


You have to pick your battles. Right now, fixing the 
documentation, improving third-party libraries and documentation, 
C++ interoperability, a GC-free standard library, Android 
support, and various other things are all of greater importance.

Re: Some feedback on the website.

[H. S. Teoh via Digitalmars-d]

On Thu, Dec 17, 2015 at 06:50:34PM -0500, Andrei Alexandrescu via Digitalmars-d 
wrote:
[...]
> * "Examples:" is a historical error. All instances should be "Example:".
> Just one diff making that change throughout would be a meaningful
> contribution.
[...]

I'm pretty sure ddoc'd unittests show up as "Examples:". Or was this
changed recently?


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit 
forever.

Simple step to making Ddoc better

[Andrei Alexandrescu via Digitalmars-d]

There's no better way to find awkwardnesses in a design than trying to 
explain it to someone.


Could someone destroy https://issues.dlang.org/show_bug.cgi?id=15460? 
Should take minutes.



Thanks,

Andrei

Re: Silicon Valley D Meetup December 17, 2015

[Andrei Alexandrescu via Digitalmars-d-announce]

On 12/17/2015 10:07 PM, Ali Cehreli wrote:

On Thursday, 17 December 2015 at 17:41:30 UTC, Ali Çehreli wrote:

On 12/12/2015 05:03 PM, Ali Çehreli wrote:

Our guest speaker is Steven Schveighoffer. He will present "Mutability
wildcards in D":

http://www.meetup.com/D-Lang-Silicon-Valley/events/226112281/

Ali


We still have a few spots available. See you there! :)

Ali


We are live now:

https://plus.google.com/hangouts/_/zl5ahu3rfadi5niynsqcqzldqma?hl=en=0


Ali


How was it? -- Andrei

Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 18 December 2015 at 15:01:44 UTC, bachmeier wrote:

You have to pick your battles.


Exactly.

Right now, fixing the documentation, improving third-party 
libraries and documentation, C++ interoperability, a GC-free 
standard library, Android support, and various other things are 
all of greater importance.


Mmm... not so sure about that strategy. Focusing on an 
application area that has low coverage in competing languages is 
essential for fast growth. Which is why a language like Julia is 
growing.


Libraries come when the core is competitive.

Re: Some feedback on the website.

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 18 December 2015 at 13:15:54 UTC, Andrei Alexandrescu 
wrote:
As I said: a growing number of people able and willing to 
maintain and improve it. -- Andrei


Which would grow "tremendously" if it was using an online 
interface backed by a database.

Re: We need a good code font for the function signatures on dlang.org

[Sebastiaan Koppe via Digitalmars-d]

On Thursday, 17 December 2015 at 21:30:21 UTC, Eric Scrivner 
wrote:
In the interest of "Show Don't Tell", here's what the homepage 
looks like using the following font string:


font-family: Consolas, "Liberation Mono", Courier, monospace


Consolas + 1. Hack is too vertical to my taste.

Re: Some feedback on the website.

[Andrei Alexandrescu via Digitalmars-d]

On 12/18/2015 10:19 AM, H. S. Teoh via Digitalmars-d wrote:

On Thu, Dec 17, 2015 at 06:50:34PM -0500, Andrei Alexandrescu via Digitalmars-d 
wrote:
[...]

* "Examples:" is a historical error. All instances should be "Example:".
Just one diff making that change throughout would be a meaningful
contribution.

[...]

I'm pretty sure ddoc'd unittests show up as "Examples:". Or was this
changed recently?


It should get changed to singular because it's grammatically incorrect. 
Most examples shown feature exactly one instance of using the 
demonstrated artifact. So it's incorrect to write "Examples:" followed 
by one example.


Conversely, if there are multiple uses of the discussed artifact, then 
"Example:" is not incorrect - it's one example featuring several uses.



Andrei

Re: Some feedback on the website.

[Andrei Alexandrescu via Digitalmars-d]

On 12/18/15 3:06 AM, Jacob Carlborg wrote:

On 2015-12-17 23:40, Andrei Alexandrescu wrote:


We are already using vibe.d for the Phobos page-per-name documentation.
As far as I can tell the initiative has been a qualified success.


What's left/stopping us from using this as the default documentation?


As I said: a growing number of people able and willing to maintain and 
improve it. -- Andrei

Re: Some feedback on the website.

[Dragos Carp via Digitalmars-d]

On Friday, 18 December 2015 at 13:15:54 UTC, Andrei Alexandrescu 
wrote:

On 12/18/15 3:06 AM, Jacob Carlborg wrote:

On 2015-12-17 23:40, Andrei Alexandrescu wrote:

We are already using vibe.d for the Phobos page-per-name 
documentation.
As far as I can tell the initiative has been a qualified 
success.


What's left/stopping us from using this as the default 
documentation?


As I said: a growing number of people able and willing to 
maintain and improve it. -- Andrei


Two issues with the ddox generated documentation:

1. `static if` code is not shown [1]
2. probably some aliases are too early "resolved"
  Look for the type of sz that would be wrong on 32-bit:
http://dlang.org/phobos-prerelease/core_memory.html#.GC.malloc
http://dlang.org/library-prerelease/core/memory/gc.malloc.html

[1] https://github.com/rejectedsoftware/ddox/issues/86

Unions and CTFE

[Gianni Pisetta via Digitalmars-d]

Hi all,
i'm coding a parametrized crc implementation that can support 
most of the standards. I want to make it work with CTFE and i 
stumbled upon a difficulty when using 
std.bitmanip.nativeToLittleEndian and 
std.bitmanip.nativeToBigEndian.
The code below is the concept used by EndianSwapper and it does 
not compile because of unions and CTFE. Also as the error message 
is very obscure, is it intended behaviour or a bug?


module testunionctfe;

import std.traits;

auto f(T)(T data) {
  union DataBytes {
Unqual!T data;
ubyte[T.sizeof] bytes;
  };

  DataBytes tmp;
  tmp.data = data;
  return tmp.bytes;
}

void main(){
  auto a = f( 0x01020304 );
  enum b = f( 0x01020304 ); //testunionctfe.d(18): Error: 
uninitialized variable 'data' cannot be returned from CTFE

  assert( a == b );
}

If it is intended behaviour, i think i come up with an 
alternative implementation for these two functions with shifts 
and masks to be used only in ctfe(union implementation is faster) 
when the type is uint and ushort(and maybe ulong), that i will 
prepare in a pull request.

Otherwise if it is a bug i will file a bugreport instead.

WIP: http://wiki.dlang.org/Contributing_to_dlang.org#Editing_Content

[Andrei Alexandrescu via Digitalmars-d]

I've started http://wiki.dlang.org/Contributing_to_dlang.org. Is this 
the kind of content that people are looking for? Destroy! -- Andrei

Re: DlangUI

[Suliman via Digitalmars-d-announce]

On Thursday, 17 December 2015 at 17:25:09 UTC, Vadim Lopatin 
wrote:
On Thursday, 17 December 2015 at 16:21:58 UTC, John Colvin 
wrote:
DlangUI will never use native controls. It draws all widgets 
itself.

But look and feel can be changed by providing custom theme.
You can create theme (set of .xml and .png files) to get 
DlangUI app looking exactly like native one.


In general I don't care about that sort of thing, but there is 
one exception: the main application menu. Unity and Aqua (OS 
X) both end up feeling odd if you don't use the system one.


Completely agree.
Once Cocoa backend is ready I'm going to implement native OSX 
menus.


Would it be possible to add native menu for Windows? I think all 
font-related stuff is should be look native or use native 
controls. Because Apps that can't handle non standard system DPI 
looks very bad.

Re: DlangUI

[Vadim Lopatin via Digitalmars-d-announce]

On Friday, 18 December 2015 at 13:56:00 UTC, Suliman wrote:
In general I don't care about that sort of thing, but there 
is one exception: the main application menu. Unity and Aqua 
(OS X) both end up feeling odd if you don't use the system 
one.


Completely agree.
Once Cocoa backend is ready I'm going to implement native OSX 
menus.


Would it be possible to add native menu for Windows? I think 
all font-related stuff is should be look native or use native 
controls. Because Apps that can't handle non standard system 
DPI looks very bad.


I see no point in implementing native Windows menus.
For high DPI, DlangUI supports loading different drawables for 
different resources, and you can specify font sizes and control 
dimensions in points or millimeters instead of pixels.

(It's similar to Android)

Re: Testing Nightly Build Service

[steven kladitis via Digitalmars-d-announce]

On Monday, 14 December 2015 at 08:36:27 UTC, Andrea Fontana wrote:
On Saturday, 12 December 2015 at 12:08:50 UTC, Martin Nowak 
wrote:
As you might already know from the last sprint review 
(http://forum.dlang.org/post/56592679.3010604@dawg.), we've 
setup a server to build nightlies. The service is still in a 
test phase but seems to work steadily.


You can try it using the install script

curl -fsSL https://builds.dawg.eu/install.sh | bash -s 
dmd-nightly


or by simply downloading the latest archive for your platform.

https://builds.dawg.eu/dmd-nightly/


That's a good news!


It looks lie it is building lots of C code, I thought D was 
written in 'D' now. Also looks like it is compiling 2.067?

Re: Simple step to making Ddoc better

[Adam D. Ruppe via Digitalmars-d]

On Friday, 18 December 2015 at 16:09:43 UTC, Andrei Alexandrescu 
wrote:
Could someone destroy 
https://issues.dlang.org/show_bug.cgi?id=15460? Should take 
minutes.



I kinda want to toy with cross referencing too. I have an idea: a 
magic macro that expands like Object in specified DDoc contexts to


$(D_SYMBOL_NAME object Object)

yes, it outputs the full name, but not as dots - as different 
macro arguments. Then we can make a recursive macro to put it 
back together as like phobos/object_Object or something. idk yet, 
but I think we can do something.


And we need crosslinking somehow. Even just putting the dotted 
name that we can process in another list (my dpldocs.info for 
example can find a page) is better than nothing.



I have so much stuff to do but blargh, I'll look at all this.

Re: Silicon Valley D Meetup December 17, 2015

[Steven Schveighoffer via Digitalmars-d-announce]

On 12/18/15 11:01 AM, Andrei Alexandrescu wrote:

On 12/17/2015 10:07 PM, Ali Cehreli wrote:

On Thursday, 17 December 2015 at 17:41:30 UTC, Ali Çehreli wrote:

On 12/12/2015 05:03 PM, Ali Çehreli wrote:

Our guest speaker is Steven Schveighoffer. He will present "Mutability
wildcards in D":

http://www.meetup.com/D-Lang-Silicon-Valley/events/226112281/

Ali


We still have a few spots available. See you there! :)

Ali


We are live now:

https://plus.google.com/hangouts/_/zl5ahu3rfadi5niynsqcqzldqma?hl=en=0



Ali


How was it? -- Andrei


From a speaker perspective, it went very well. The audience was very 
thoughtful and asked great questions. My first presentation ever, actually.


I'm not sure if it was recorded, but perhaps it will show up on youtube 
at some point.


I'm working on an article on the same subject, hope to have that done soon.

-Steve

Re: Simple step to making Ddoc better

[Adam D. Ruppe via Digitalmars-d]

On Friday, 18 December 2015 at 16:28:31 UTC, Andrei Alexandrescu 
wrote:

What's needed here is to wrap all raw text in DDOC_RAWTEXT as I



BTW I think this is easy and backward compatible, I might just do 
it anyway, but I don't think it will help here.

Re: Simple step to making Ddoc better

[Sönke Ludwig via Digitalmars-d]

Am 18.12.2015 um 17:28 schrieb Andrei Alexandrescu:

On 12/18/2015 11:20 AM, Adam D. Ruppe wrote:

On Friday, 18 December 2015 at 16:09:43 UTC, Andrei Alexandrescu wrote:

Could someone destroy https://issues.dlang.org/show_bug.cgi?id=15460?
Should take minutes.



I kinda want to toy with cross referencing too. I have an idea: a magic
macro that expands like Object in specified DDoc contexts to

$(D_SYMBOL_NAME object Object)

yes, it outputs the full name, but not as dots - as different macro
arguments. Then we can make a recursive macro to put it back together as
like phobos/object_Object or something. idk yet, but I think we can do
something.

And we need crosslinking somehow. Even just putting the dotted name that
we can process in another list (my dpldocs.info for example can find a
page) is better than nothing.


I have so much stuff to do but blargh, I'll look at all this.


What's needed here is to wrap all raw text in DDOC_RAWTEXT as I proposed
a few days ago. Then external tooling makes cross referencing trivial.
Wanna work on that? -- Andrei


Just a quick reminder: https://dlang.org/library/ already has automatic 
cross-referencing*. If we agree to pursue this as a replacement to the 
current documentation, I suggest to focus efforts on that. I can work on 
the generator itself, but I lack the time to go through all of Phobos to 
fix custom-macro related glitches, such as [1], so some help is required.


* Currently it looks at all words in a text to find symbols, but once 
the documentation is adjusted accordingly, it would be switched to just 
look within `code` or $(D code) parts.


[1]: https://issues.dlang.org/show_bug.cgi?id=14403

[Issue 15460] Ddoc: merge the opening comment "" into the default definition of DDOC

[via Digitalmars-d-bugs]

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

--- Comment #3 from Adam D. Ruppe  ---
$ make -f posix.mak
make -C src -f posix.mak
no cpu specified, assuming X86
make[1]: Entering directory `/home/me/d/pull-request-stuff/dmd/src'
make[1]: *** No rule to make target `lexer.h', needed by `s2ir.o'.  Stop.

This pisses me off. A three minute change... but five minutes to get the git
crap set up, and now it doesn't even work.

Unbelievable.

--

Re: Simple step to making Ddoc better

[Andrei Alexandrescu via Digitalmars-d]

On 12/18/2015 11:20 AM, Adam D. Ruppe wrote:

On Friday, 18 December 2015 at 16:09:43 UTC, Andrei Alexandrescu wrote:

Could someone destroy https://issues.dlang.org/show_bug.cgi?id=15460?
Should take minutes.



I kinda want to toy with cross referencing too. I have an idea: a magic
macro that expands like Object in specified DDoc contexts to

$(D_SYMBOL_NAME object Object)

yes, it outputs the full name, but not as dots - as different macro
arguments. Then we can make a recursive macro to put it back together as
like phobos/object_Object or something. idk yet, but I think we can do
something.

And we need crosslinking somehow. Even just putting the dotted name that
we can process in another list (my dpldocs.info for example can find a
page) is better than nothing.


I have so much stuff to do but blargh, I'll look at all this.


What's needed here is to wrap all raw text in DDOC_RAWTEXT as I proposed 
a few days ago. Then external tooling makes cross referencing trivial. 
Wanna work on that? -- Andrei

[Issue 15460] Ddoc: merge the opening comment "" into the default definition of DDOC

[via Digitalmars-d-bugs]

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

Adam D. Ruppe  changed:

   What|Removed |Added

 CC||destructiona...@gmail.com

--- Comment #1 from Adam D. Ruppe  ---
This is the code that does it:

buf.printf("$(DDOC_COMMENT Generated by Ddoc from %s)\n", m.srcfile.
toChars());


You could just define `DDOC_COMMENT=` to strip all comments from the generated
code, since plain text doesn't have a comment facility anyway...

--

[Issue 15460] Ddoc: merge the opening comment "" into the default definition of DDOC

[via Digitalmars-d-bugs]

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

--- Comment #2 from Andrei Alexandrescu  ---
(In reply to Adam D. Ruppe from comment #1)
> This is the code that does it:
> 
> buf.printf("$(DDOC_COMMENT Generated by Ddoc from %s)\n", m.srcfile.
> toChars());
> 
> 
> You could just define `DDOC_COMMENT=` to strip all comments from the
> generated code, since plain text doesn't have a comment facility anyway...

Just do it!

--

Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

[bachmeier via Digitalmars-d]

On Friday, 18 December 2015 at 15:09:05 UTC, Ola Fosheim Grøstad 
wrote:


Focusing on an application area that has low coverage in 
competing languages is essential for fast growth. Which is why 
a language like Julia is growing.


That's why I'm working on embedding R inside D (almost done). 
I've suffered for years with all the problems that are making 
Julia popular. I just felt D was a better choice.


On the other hand, D for embedded devices is a big project with a 
small probability of success, at least from what I've read.

Re: Silicon Valley D Meetup December 17, 2015

[Ali Çehreli via Digitalmars-d-announce]

On 12/18/2015 08:01 AM, Andrei Alexandrescu wrote:

 Our guest speaker is Steven Schveighoffer. He will present "Mutability
 wildcards in D":

 http://www.meetup.com/D-Lang-Silicon-Valley/events/226112281/

> How was it? -- Andrei

It was excellent! We learned what inout actually is :) from the expert 
himself. (Thank you Steve; what a treat!) Steve showed many interesting 
corner cases about its use.


Ali

[Issue 15460] Ddoc: merge the opening comment "" into the default definition of DDOC

[via Digitalmars-d-bugs]

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

--- Comment #5 from Andrei Alexandrescu  ---
(In reply to Adam D. Ruppe from comment #4)
> well looks like i had to make clean because I had stuff left over from when
> it was still C++ for last time I did a ddoc PR.
> 
> But still, ugh.

I guess it's one of those things that are nobody's fault. Thanks for looking
into the ddoc matter!

--

[Issue 14608] Enum members should be formatted as a table

[via Digitalmars-d-bugs]

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

Sönke Ludwig  changed:

   What|Removed |Added

 CC||slud...@outerproduct.org

--- Comment #3 from Sönke Ludwig  ---
Note that while the DDOX based documentation has a per-item page, it also has
an overview table:
http://dlang.org/library/std/algorithm/searching/open_right.html

So it's a matter of simply skipping the generation of the per-item pages.
However, sometimes there might be more than a one-liner description, so the
table would have to be able to display that, too (e.g. like
https://msdn.microsoft.com/en-us/library/windows/desktop/ff700543%28v=vs.85%29.aspx).

--

Re: Simple step to making Ddoc better

[Sönke Ludwig via Digitalmars-d]

Am 18.12.2015 um 17:48 schrieb Adam D. Ruppe:

On Friday, 18 December 2015 at 16:42:14 UTC, Sönke Ludwig wrote:

* Currently it looks at all words in a text to find symbols, but once
the documentation is adjusted accordingly, it would be switched to
just look within `code` or $(D code) parts.


What about examples and prototypes?


It does that, too, forgot to mention that.


That reminds me, formatting the prototypes I think is high value too.
DDox does ok:

https://dlang.org/library/std/algorithm/comparison/levenshtein_distance.html


But I still think we can do a lot better.


Agreed, do you have concrete ideas? One thing that could also be 
interesting (and easy to do) would be to add parameter names in the 
"Functions" overview tables, so that levenshteinDistance gets listed as 
levenshteinDistance(equals, s, t). That could replace the manually 
authored cheat sheet in many cases.

Re: Simple step to making Ddoc better

[Andrei Alexandrescu via Digitalmars-d]

On 12/18/2015 11:44 AM, Adam D. Ruppe wrote:

On Friday, 18 December 2015 at 16:28:31 UTC, Andrei Alexandrescu wrote:

What's needed here is to wrap all raw text in DDOC_RAWTEXT as I



BTW I think this is easy and backward compatible, I might just do it
anyway, but I don't think it will help here.


You are correct, I was being confused about your point. And yes 
DDOC_RAWTEXT is backward compatible and useful. Thanks!! -- Andrei

Re: Unions and CTFE

[Jimmy Cao via Digitalmars-d]

On Friday, 18 December 2015 at 14:30:25 UTC, Gianni Pisetta wrote:

Hi all,
i'm coding a parametrized crc implementation that can support 
most of the standards. I want to make it work with CTFE and i 
stumbled upon a difficulty when using 
std.bitmanip.nativeToLittleEndian and 
std.bitmanip.nativeToBigEndian.
The code below is the concept used by EndianSwapper and it does 
not compile because of unions and CTFE. Also as the error 
message is very obscure, is it intended behaviour or a bug?


I think it's intended behavior.  According to 
http://dlang.org/changelog/2.065.0.html#ctfe-overlapped-field


"Bit image reinterpretation by using two overlapped union fields 
is not allowed during CTFE."

[Issue 15460] Ddoc: merge the opening comment "" into the default definition of DDOC

[via Digitalmars-d-bugs]

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

--- Comment #7 from Adam D. Ruppe  ---
The auto tester cares about the exact bytes ddoc puts out?!?! Looks like it is
failing because there's a space... but I didn't change the spaces... must be
the change of new lines. This is ridiculous. Spaces don't even affect HTML.

I fear going through and improving the default macros because of these over
specific tests. If I change a default macro to include a class name, the auto
tester is going to fail it!

See, this is the big lie about low hanging fruit. A minor, obviously trivial
change (just moving a useless comment!), means spending hours fighting with the
tester too. If it was easy to use and catching legitimate bugs, I'd be OK with
it... but it isn't easy to use (the Starting as a contributor page doesn't even
*mention* dmd tests, and what it says about the Phobos one reveals yet another
dmd makefile bug) and this isn't catching actual bugs. It is whining about
spaces in HTML... which are ignored in HTML.




Friction like this just kills my momentum and spends time that I could have
spent doing actually valuable stuff on chasing down an irrelevant whitespace
"problem" that apparently appeared out of nowhere. (Seriously, look at the
diff. The spaces were already there. Why is it only now complaining about it?
But the tester failed before and is passing now so apparently it makes a
difference. Illogical.)

--

Re: Simple step to making Ddoc better

[Adam D. Ruppe via Digitalmars-d]

On Friday, 18 December 2015 at 16:28:31 UTC, Andrei Alexandrescu 
wrote:
What's needed here is to wrap all raw text in DDOC_RAWTEXT as I 
proposed a few days ago. Then external tooling makes cross 
referencing trivial. Wanna work on that? -- Andrei


I don't agree that would help - what I want is when a code 
example is like:


---
import std.stdio;
void foo(File f);
---

I want DDoc to look up what File means (that it is from std.stdio 
and not from some other module, for example) and tell me that in 
the generated code somehow.


So this is already being syntax highlighted, I want it to look up 
more.


A big potential problem there is that not all examples are 
complete programs that will compile, so it won't always work. But 
we can cross that bridge when we come to it.

Re: Simple step to making Ddoc better

[Adam D. Ruppe via Digitalmars-d]

On Friday, 18 December 2015 at 16:42:14 UTC, Sönke Ludwig wrote:
* Currently it looks at all words in a text to find symbols, 
but once the documentation is adjusted accordingly, it would be 
switched to just look within `code` or $(D code) parts.


What about examples and prototypes?


That reminds me, formatting the prototypes I think is high value 
too. DDox does ok:


https://dlang.org/library/std/algorithm/comparison/levenshtein_distance.html

But I still think we can do a lot better.

Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

[Jakob Jenkov via Digitalmars-d]

Thanks for the comments everyone! I learn a lot from this D forum 
alone. I have been encaged in the Java world for too long. Great 
to get some input from other languages / eco systems. Not that 
I'll drop Java immediately, but I can definitely see how D can 
supplement Java in our systems.

[Issue 15460] Ddoc: merge the opening comment "" into the default definition of DDOC

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #8 from Vladimir Panteleev  ---
(In reply to Adam D. Ruppe from comment #7)
> [trim pointless rant]

Some of the tests are only there to make sure the output doesn't change by
accident. If the change is intentional, update the tests to match.

--

[Issue 15460] Ddoc: merge the opening comment "" into the default definition of DDOC

[via Digitalmars-d-bugs]

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

--- Comment #6 from Adam D. Ruppe  ---
https://github.com/D-Programming-Language/dmd/pull/5313

BTW for anyone reading this, the ddoc generator is actually pretty simple code.

--

[Issue 15460] Ddoc: merge the opening comment "" into the default definition of DDOC

[via Digitalmars-d-bugs]

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

--- Comment #4 from Adam D. Ruppe  ---
well looks like i had to make clean because I had stuff left over from when it
was still C++ for last time I did a ddoc PR.

But still, ugh.

--

[Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Hardware|x86_64  |All
 OS|Linux   |All
   Severity|normal  |major

--

[Issue 15459] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--- Comment #1 from ZombineDev  ---
When you're iterating any kind of string (char, wchar or dchar based) the
element type is always dchar. This special case for narrow strings (UTF-8 and
UTF-16) is also known as UTF autodecoding. You can see this for yourself if you
change `somefunc` into a template and add a pragma statement to make the
compiler emit an information message about the type of `c` for each
instantiation of the function:

auto somefunc(C)(C c)
{
pragma (msg, C);
return c;
}

See also: http://dlang.org/phobos/std_range_primitives.html#.ElementType,
http://dlang.org/phobos/std_range_primitives.html#.front and
http://dlang.org/glossary.html#narrow strings

This is still a valid bug report, because the compiler should refuse to compile
this code.

--

Re: View Expanded Templates?

[Ali Çehreli via Digitalmars-d-learn]

On 12/18/2015 10:54 AM, Taylor Hillegeist wrote:

>   pragma(msg, code_generation_function())
>
>
> simple + awesome.

Yes, and perhaps unittest blocks:

unittest
{
assert(makeCode("foo") == "int foo = 42;");
}

Unfortunately, neither works with template mixins or regular templates.

Ali

Re: Testing Nightly Build Service

[John Colvin via Digitalmars-d-announce]

On Friday, 18 December 2015 at 15:42:32 UTC, steven kladitis 
wrote:
On Monday, 14 December 2015 at 08:36:27 UTC, Andrea Fontana 
wrote:
On Saturday, 12 December 2015 at 12:08:50 UTC, Martin Nowak 
wrote:
As you might already know from the last sprint review 
(http://forum.dlang.org/post/56592679.3010604@dawg.), we've 
setup a server to build nightlies. The service is still in a 
test phase but seems to work steadily.


You can try it using the install script

curl -fsSL https://builds.dawg.eu/install.sh | bash -s 
dmd-nightly


or by simply downloading the latest archive for your platform.

https://builds.dawg.eu/dmd-nightly/


That's a good news!


It looks lie it is building lots of C code, I thought D was 
written in 'D' now. Also looks like it is compiling 2.067?


The backend is still in C++. 2.067 was fully C++ is probably 
built for bootstrapping.

Re: Simple step to making Ddoc better

[Adam D. Ruppe via Digitalmars-d]

On Friday, 18 December 2015 at 16:55:58 UTC, Andrei Alexandrescu 
wrote:
You are correct, I was being confused about your point. And yes 
DDOC_RAWTEXT is backward compatible and useful. Thanks!! -- 
Andrei


Eh, it isn't as easy as I thought though because everything in 
ddoc is inside a macro at some level. It would have to be 
something like a proprocessor on the user input that skips 
balanced parens.


Still doable, but not as simple.

Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 18 December 2015 at 16:59:54 UTC, bachmeier wrote:
That's why I'm working on embedding R inside D (almost done). 
I've suffered for years with all the problems that are making 
Julia popular. I just felt D was a better choice.


I think the draw towards Julia is long term rather than 
productivity right now. If scientific programmers interested in 
interactive dataset exploration gravitate towards Julia then at 
some point they will have tailored solutions using the GPU...


On the other hand, D for embedded devices is a big project with 
a small probability of success, at least from what I've read.


Most people probably don't want to write an interactive 
application entirely in a language like C++, D, Rust or Go, even 
if it was a supported option with full GUI library support!


But making the engine of the app portable is important. So, being 
able to compile libraries to llvm-bit code, WebAssembly, ARM, x86 
etc is very important.

Re: Unions and CTFE

[Gianni Pisetta via Digitalmars-d]

On Friday, 18 December 2015 at 17:21:39 UTC, Jimmy Cao wrote:
On Friday, 18 December 2015 at 14:30:25 UTC, Gianni Pisetta 
wrote:

Hi all,
i'm coding a parametrized crc implementation that can support 
most of the standards. I want to make it work with CTFE and i 
stumbled upon a difficulty when using 
std.bitmanip.nativeToLittleEndian and 
std.bitmanip.nativeToBigEndian.
The code below is the concept used by EndianSwapper and it 
does not compile because of unions and CTFE. Also as the error 
message is very obscure, is it intended behaviour or a bug?


I think it's intended behavior.  According to 
http://dlang.org/changelog/2.065.0.html#ctfe-overlapped-field


"Bit image reinterpretation by using two overlapped union 
fields is not allowed during CTFE."


Yeah, i supposed it. But the error message was misleading, 
because 'data' is initialized and 'bytes' is the actual 
uninitialized part. I guess the error message can be improved. 
Anyway thanks

View Expanded Templates?

[Taylor Hillegeist via Digitalmars-d-learn]

Is it possible to view the expanded form of templates or perhaps 
view the post-ctfe pre-compiled d code? I couldn't find any 
information on this topic but I think it would be useful. 
sometimes I use templates/mixins to write code for me but, 
sometimes i would rather have the expanded functions in the final 
versions.

Re: Simple step to making Ddoc better

[Adam D. Ruppe via Digitalmars-d]

On Friday, 18 December 2015 at 16:57:44 UTC, Sönke Ludwig wrote:

Agreed, do you have concrete ideas?


I think white space in the declaration would make a huge 
difference, and your page does that already somewhat, putting the 
params on separate lines.


Here's the ddoc definition for levenshteinDistance:

http://dlang.org/phobos/std_algorithm_comparison.html#.levenshteinDistance

---
size_t levenshteinDistance(alias equals = (a, b) => a == b, 
Range1, Range2)(Range1 s, Range2 t) if (isForwardRange!Range1 && 
isForwardRange!Range2);

---

Here's the ddox definition:

https://dlang.org/library/std/algorithm/comparison/levenshtein_distance.html

---
 size_t levenshteinDistance(alias equals, Range1, Range2)(
  Range1 s,
  Range2 t
)
if (isForwardRange!Range1 && isForwardRange!Range2);
---


I think the second one is nicer looking, but it also didn't show 
the default argument and the template args could be broken more.



I think I'd write it:

---
size_t
levenshteinDistance
(
   alias equals = (a, b) => a == b,
   Range1,
   Range2
)
(
   Range1 s,
   Range2 t
)
if (
   isForwardRange!Range1 &&
   isForwardRange!Range2
);
---


Or something like that. Plus syntax highlighting and linking of 
recognized things. The parameters should link to details in the 
Params: section, if present. `isForwardRange` should link back to 
that definition. Heck, I wouldn't mind if `size_t` was a link too.


You know, I wouldn't even hate it if hovering over `Range1` in 
the constraint or either param list highlighted it in the other 
places it is mentioned too. A bit of script required but it can 
help to visually tie it all in.


We can't rearrange the constraint to put them right next to each 
other like `Range1, // isForwardRange!Range1` in the CT param 
list since template constraints can be arbitrarily complex, but 
some dynamic highlighting can achieve a similar effect.



One item per line might seem like overkill here, but I think it 
pays off on complex types, specializations, or default values.


`(alias equals = (a, b) => a == b, Range1, Range2)` is kinda a 
handful already and not even all that complex. Though, if the 
names and types were highlighted it might mitigate this more than 
plain text can allow.



I just really strongly feel that white space is our friend here 
and we ought to be using it. Color and dynamic highlighting is 
gravy on top of it.


One thing that could also be interesting (and easy to do) would 
be to add parameter names in the "Functions" overview tables, 
so that levenshteinDistance gets listed as 
levenshteinDistance(equals, s, t). That could replace the 
manually authored cheat sheet in many cases.


Yes, indeed.

Re: View Expanded Templates?

[Adam D. Ruppe via Digitalmars-d-learn]

On Friday, 18 December 2015 at 18:25:03 UTC, Taylor Hillegeist 
wrote:
Is it possible to view the expanded form of templates or 
perhaps view the post-ctfe pre-compiled d code? I couldn't find 
any information on this topic but I think it would be useful. 
sometimes I use templates/mixins to write code for me but, 
sometimes i would rather have the expanded functions in the 
final versions.


Check out my tip of the week from last month:

http://arsdnet.net/this-week-in-d/nov-22.html


If you just write out the string yourself instead of mixing it 
in, you can get a lot of progress on it.

Error message improvement ideas

[Adam D. Ruppe via Digitalmars-d]

I really want the compiler to be more specific about what worked 
and what didn't in error messages. Check this out.


---
void foo(int a, string b) {}
void foo(string b) {}

void main() {
foo(10.2, "foo");
}
---

k.d(5): Error: None of the overloads of 'foo' are callable using 
argument types (double, string), candidates are:

k.d(1):k.foo(int a, string b)
k.d(2):k.foo(string b)


A relevant piece is (double, string), what I passed to it, but it 
is kinda mixed into the rest of the line. Moreover, what one 
didn't match?


We already highlight the word "Error:". I propose we also 
highlight stuff in the details lines, like this (pretending the 
color tags actually came through)


k.d(1):k.foo(int a, string b)
k.d(2):k.foo(string b)


The first arg I passed never fit the first arg of the options, 
they get red color. My string did pass one though, so it gets 
green to highlight a partial match.




Doing this on template constraints too (along with formatting 
them with some whitespace) would be huge toward making those 
std.algorithm errors be readable as well.




Moreover, I wouldn't mind if the compiler had an error output 
format that could spit out xml or something for computer 
consumption, with the same level of detail (if not more). If I 
were overhauling it all, I'd make all error messages inside the 
compiler be marked up to the max, then the top layer prints them 
appropriately for the device it is talking to (so disabling color 
on pipes, pretty printing for users, etc)



But the specifics aren't as important as having the compiler just 
somehow make it obvious at a glance what worked and what didn't. 
It could also do:


k.d(1):k.foo(int a, string b)
 ^^^++
k.d(2):k.foo(string b)
 ^^

or whatever instead of (or addition to, let's not forget a lot of 
people can't see color and the contrast on terminals may be quite 
poor) color.

Re: Silicon Valley D Meetup December 17, 2015

[Ali Çehreli via Digitalmars-d-announce]

On 12/18/2015 11:15 AM, Jon D wrote:
> On Friday, 18 December 2015 at 16:01:48 UTC, Andrei Alexandrescu wrote:
>> On 12/17/2015 10:07 PM, Ali Cehreli wrote:
>>> On Thursday, 17 December 2015 at 17:41:30 UTC, Ali Çehreli wrote:
 On 12/12/2015 05:03 PM, Ali Çehreli wrote:
> Our guest speaker is Steven Schveighoffer. He will present 
"Mutability

> wildcards in D":
>>
>> How was it? -- Andrei
>
>  From a newcomer's perspective (my 2nd meet-up) - Excellent. Steve's
> presentation improved my understanding of the language, and the
> opportunity for discussions with core members of the D community is
> fantastic. Thanks to Steve, Ali, and Truedat for putting this together.

You are most welcome but of course this is a scheme to lure you in as a 
future speaker. ;)


Ali

Re: Silicon Valley D Meetup December 17, 2015

[Jon D via Digitalmars-d-announce]

On Friday, 18 December 2015 at 16:01:48 UTC, Andrei Alexandrescu 
wrote:

On 12/17/2015 10:07 PM, Ali Cehreli wrote:
On Thursday, 17 December 2015 at 17:41:30 UTC, Ali Çehreli 
wrote:

On 12/12/2015 05:03 PM, Ali Çehreli wrote:
Our guest speaker is Steven Schveighoffer. He will present 
"Mutability

wildcards in D":


How was it? -- Andrei


From a newcomer's perspective (my 2nd meet-up) - Excellent. 
Steve's presentation improved my understanding of the language, 
and the opportunity for discussions with core members of the D 
community is fantastic. Thanks to Steve, Ali, and Truedat for 
putting this together.


--Jon

Re: D float types operations vs C++ ones

[Ali Çehreli via Digitalmars-d-learn]

On 12/18/2015 12:19 AM, Ola Fosheim Gr wrote:

On Friday, 18 December 2015 at 07:30:52 UTC, drug wrote:

What I mean about order of operations is that if you go
  a = b*a+c*c + e;
the compiler is free to rewrite that as
float __tmp0 = a*b;
float __tmp1 = c*c;
and then do either of
float __tmp2 = __tmp0+__tmp1;
a = __tmp2 + e;
OR
float __tmp2 = __tmp0+e;
a = __tmp2+__tmp1;


I see, thanks to all!


I don't think this can be right, unless you use some kind of fast-math
optimizer.

But:

Modern C++ compilers try to support ieee754-2008, which is needed to get
reproducible results. D is based on the older 1985 version, and there is
no announced effort to make it modern.



Thank you for the reference. If the Wikipedia article is precise in 
language, it is just a recommendation:


"Clause 10: Expression evaluation

This clause is new; it recommends how language standards should specify 
the semantics of sequences of operations, and points out the subtleties 
of literal meanings and optimizations that change the value of a result."



https://en.wikipedia.org/wiki/IEEE_754_revision#Clause_10:_Expression_evaluation

Ali

Re: Silicon Valley D Meetup December 17, 2015

[Steven Schveighoffer via Digitalmars-d-announce]

On 12/18/15 2:15 PM, Jon D wrote:

On Friday, 18 December 2015 at 16:01:48 UTC, Andrei Alexandrescu wrote:

On 12/17/2015 10:07 PM, Ali Cehreli wrote:

On Thursday, 17 December 2015 at 17:41:30 UTC, Ali Çehreli wrote:

On 12/12/2015 05:03 PM, Ali Çehreli wrote:

Our guest speaker is Steven Schveighoffer. He will present "Mutability
wildcards in D":


How was it? -- Andrei


 From a newcomer's perspective (my 2nd meet-up) - Excellent. Steve's
presentation improved my understanding of the language, and the
opportunity for discussions with core members of the D community is
fantastic. Thanks to Steve, Ali, and Truedat for putting this together.

--Jon



Thanks, it was great to "meet" everyone there!

-Steve

"Programming in D" hardcover edition

[Ali Çehreli via Digitalmars-d-announce]

Thanks to Steven E., an Amazon commenter on the paperback book[1], now 
the hardcover is available under ISBN 978-0-692-59943-3. As of this 
writing, there is just one Google hit but the following site (no 
affiliation) finds it at several stores:



http://www.bookfinder4u.com/IsbnSearch.aspx?isbn=9780692599433=direct

However, IngramSpark has notified me that "December is turning out to be 
a record-shattering month for hard cover production", so you may have to 
wait for shipment.


Ali

P.S. "Programming in D": The book that keeps on announcing. :p (I am 
tired of it myself and hopefully this is the last one.)


P.P.S. Main page: http://ddili.org/ders/d.en/

[1] 
http://www.amazon.com/Programming-Tutorial-Reference-Ali-Cehreli/dp/1515074609/ref=sr_1_1?ie=UTF8=1450467388=8-1=%22programming+in+d%22

Re: Some feedback on the website.

[JohnCK via Digitalmars-d]

On Friday, 18 December 2015 at 01:17:26 UTC, JohnCK wrote:

On Friday, 18 December 2015 at 00:43:11 UTC, H. S. Teoh wrote:
... I find the online forum interface klunky and inefficient 
to use (though most would disagree),


One thing that bothers me sometimes is the waste of space, as  
you can see in this SS, there are 2 versions, the original with 
highlights and the other that I modified.


http://i.imgur.com/lx2qA7d.png

JohnCK.


Maybe what I said above sound silly, but I'd like to take and say 
that I forgot to explain that space is very important on tiny 
screens like Tablets, in my case Galaxy Tab 3 - 7" inches.


And I'd to take the opportunity to point out another problem that 
I've found in some pages like:


1) On the menu -> resources -> New Library reference preview, 
some links are not working, example:


https://dlang.org/library/std/algorithm/comparison.html  <- In 
the top of the page there is:  This is submodule of 
"std.algorithm" <- Wrong link.


And the same thing is happening for the other pages like: 
https://dlang.org/library/std/algorithm/iteration.html and goes 
on...


2) Finally, in this page: 
https://dlang.org/phobos/std_algorithm.html, someone use align 
text set as "JUSTIFY", see how beautiful is in my Tablet:


http://i.imgur.com/bJKy6p7.png  (I highlighted in red).

JohnCK.

[Issue 15460] Ddoc: merge the opening comment "" into the default definition of DDOC

[via Digitalmars-d-bugs]

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

--- Comment #10 from Adam D. Ruppe  ---
Please document the test system and link it from here:
http://wiki.dlang.org/Starting_as_a_Contributor


This change was not intentional btw, I don't understand why the test ever
passed since the spaces it was complaining about have been there for years.

But whatever, it passed now.
https://github.com/D-Programming-Language/dmd/pull/5313

--

[Issue 15460] Ddoc: merge the opening comment "" into the default definition of DDOC

[via Digitalmars-d-bugs]

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

--- Comment #9 from Andrei Alexandrescu  ---
(In reply to Vladimir Panteleev from comment #8)
> (In reply to Adam D. Ruppe from comment #7)
> > [trim pointless rant]
> 
> Some of the tests are only there to make sure the output doesn't change by
> accident. If the change is intentional, update the tests to match.

I agree with Vladimir sans the "pointless" part. Let's be nice to each other,
y'all.

--

Re: View Expanded Templates?

[Taylor Hillegeist via Digitalmars-d-learn]

On Friday, 18 December 2015 at 18:35:40 UTC, Adam D. Ruppe wrote:
On Friday, 18 December 2015 at 18:25:03 UTC, Taylor Hillegeist 
wrote:
Is it possible to view the expanded form of templates or 
perhaps view the post-ctfe pre-compiled d code? I couldn't 
find any information on this topic but I think it would be 
useful. sometimes I use templates/mixins to write code for me 
but, sometimes i would rather have the expanded functions in 
the final versions.


Check out my tip of the week from last month:

http://arsdnet.net/this-week-in-d/nov-22.html


If you just write out the string yourself instead of mixing it 
in, you can get a lot of progress on it.


 pragma(msg, code_generation_function())


simple + awesome.

:)

[Issue 15461] New: std.stdio.File ctor that accepts `FILE*` should not be hidden

[via Digitalmars-d-bugs]

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

  Issue ID: 15461
   Summary: std.stdio.File ctor that accepts `FILE*` should not be
hidden
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ket...@ketmar.no-ip.org

glibc has a great `fopencookie(3)` call, which can be used to build `FILE*`
objects for arbitrary data sources. yet there is no way to init
`std.stdio.File` with that `FILE*`, which cuts alot of possibilities.

there should be a way to create `std.stdio.File` from existing `FILE*` at least
on systems where `fopencookie(3)` is available.

--

[Issue 15461] std.stdio.File ctor that accepts `FILE*` should not be hidden

[via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

[Barry L. via Digitalmars-d]

On Thursday, 17 December 2015 at 19:56:32 UTC, Jakob Jenkov wrote:

Hi guys,

I read from some of the other forum threads that D is being 
criticized for not being usable for real time / low latency 
systems because it has a GC.


First of all, such system are already being written in Java. 
Google "Martin Thompson" and LMAX and you will see. Or Aeron 
(also Java and Martin Thompson).


Second, when Java has been used to develop such systems, the GC 
has been avoided as much as possible - which is even easier to 
do with D than Java.


So, it's a load of BS that D's GC should somehow make it 
impossible to make real time / low latency software.


Yes, it is a load of BS.

Andy Smith's talk from DConf 2015:  
https://www.youtube.com/watch?v=0KBhb0iWsWQ


Summary - modern financial trading apps use multi-core machines 
and shared memory via memory mapped files, and multi-core boxes 
to achieve nanosecond latency.  Compare to pre-2000 systems that 
used single core and Tibco/RV networking.  Remove the network, 
remove the bottleneck.


Java does it using Chronicle (google Peter Lawrey).  The other 
twist is to reuse allocated flyweights to avoid triggering the GC.


Andy (unless I misheard) worked with/for Peter and has 
reimplemented the same thing using D with comparable (or better?) 
performance.


Even if D's entirely optional GC was on, its trigger could (I 
would think) be avoid be similarly allocating once, and reusing 
the object.

Re: We need a good code font for the function signatures on dlang.org

[Jack Stouffer via Digitalmars-d]

On Wednesday, 16 December 2015 at 23:25:01 UTC, Andrei 
Alexandrescu wrote:
On that note: Andrei, how do I get in contact with whoever 
runs the

server to get that going?


Jan Knepper is our webmaster. You can find his contact info at 
https://www.janknepper.com/.


It seems his email server is down. Do you know of any other way 
to contact him?

Scope of D packages

[Jakob Jenkov via Digitalmars-d-learn]

I'm coming from Java where "packages" are not that much more than 
directories. Each class can be exposed or hidden inside a package 
etc.


In Java it is common that an API consists of many packages and 
subpackages. All classes are simply wrapped up in a JAR (Zip) 
file, and then they can be used as a library.


What is common in D?

Does a library have all its classes inside the same package (same 
directory) ? Or can you have multiple packages / subpackages 
inside the same library *and* same source root?

Re: D programming video tutorial

[Stefan Koch via Digitalmars-d-learn]

I have a few videos on about D on YT.
But those are ... well suboptimal.

I will probably talk a bit about SDC... when time permits

Re: Scope of D packages

[Jakob Jenkov via Digitalmars-d-learn]

To be exact it doesn't need the sources, it needs the function 
signatures and type definitions so the equivalent of C header 
files. If you don't want to share the full sources with your 
library you can generate those header files automatically using 
the -H flag in dmd. It will produce a "D interface" file with a 
"di" extension.


But - if the library was open source, it would be better to just 
share the sources than a compiled file? (In Java we share/use the 
zipped JAR file with compiled classes).

Re: Scope of D packages

[cym13 via Digitalmars-d-learn]

On Saturday, 19 December 2015 at 00:52:40 UTC, Jakob Jenkov wrote:
To be exact it doesn't need the sources, it needs the function 
signatures and type definitions so the equivalent of C header 
files. If you don't want to share the full sources with your 
library you can generate those header files automatically 
using the -H flag in dmd. It will produce a "D interface" file 
with a "di" extension.


But - if the library was open source, it would be better to 
just share the sources than a compiled file? (In Java we 
share/use the zipped JAR file with compiled classes).


If it's open source it's better to share the sources, sure. As 
the compiler is able to do more optimization when it has all the 
sources at hand it is customary to limit the use of shared 
libraries and just compile everything at once (although you can 
quickly run into things like memory limitations as it demands 
quite a lot of resources). Typically you'd segment your 
compilation by module if needed.


If you are to give the sources (with or without a standalone lib) 
then you allow your users to benefit from such optimizations if 
they want to, so it's better to give the sources when possible. D 
Interface files are there mostly (only?) to answer the 
problematic of closed source libraries.

[Issue 15460] Ddoc: merge the opening comment "" into the default definition of DDOC

[via Digitalmars-d-bugs]

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

Ali Cehreli  changed:

   What|Removed |Added

 CC||acehr...@yahoo.com

--- Comment #12 from Ali Cehreli  ---
Ha ha. :) I'm caught red-handed. I actually rely on that comment:

 
https://bitbucket.org/acehreli/ddili/src/9e3339d1574bd7974548fe74b62fcb9ce0ed0bb5/src/anchorgen.d?at=master=file-view-default#anchorgen.d-76

I guess, I will have to find a better way of determining the name of the
original file.

--

Re: We need a good code font for the function signatures on dlang.org

[Walter Bright via Digitalmars-d]

On 12/16/2015 3:22 PM, Andrei Alexandrescu wrote:

Preferably a nice one. -- Andrei


I prefer bad ones. -- Walter

Re: We need a good code font for the function signatures on dlang.org

[Walter Bright via Digitalmars-d]

On 12/16/2015 1:05 PM, Andrei Alexandrescu wrote:

I was looking at https://github.com/D-Programming-Language/dlang.org/pull/1169
and that bold sans serif proportional text for the code is just... well let's
say it's time to replace it.


I've always hated proportional fonts for code, so much that I read a book on 
Modula II in the 80's and irrationally disliked it because it used a 
proportional font for the code and looked so ugly. I never got that bad taste 
for M2 out of my mouth.

Re: Problems with string literals and etc.c.odbc.sql functions

[Fer22f via Digitalmars-d-learn]

On Friday, 18 December 2015 at 22:18:34 UTC, Adam D. Ruppe wrote:
That's what the examples on MSDN do too though, a cast. At 
first I thought the binding was missing a const, but the ODBC 
docs don't specify it as const either and cast.


The ODBC functions also have a size parameter for string 
parameters. You can set it to SQL_NTS to use the 0 terminated C 
standard. Might justify on why it's char* instead of const char*.


It looks like it's alright, then. Just one implementation detail 
I didn't notice before.

Re: Scope of D packages

[cym13 via Digitalmars-d-learn]

On Saturday, 19 December 2015 at 00:09:16 UTC, Basile B. wrote:

On Friday, 18 December 2015 at 23:20:34 UTC, Jakob Jenkov wrote:
I'm coming from Java where "packages" are not that much more 
than directories. Each class can be exposed or hidden inside a 
package etc.


In Java it is common that an API consists of many packages and 
subpackages. All classes are simply wrapped up in a JAR (Zip) 
file, and then they can be used as a library.


What is common in D?

Does a library have all its classes inside the same package 
(same directory) ? Or can you have multiple packages / 
subpackages inside the same library *and* same source root?


each sub directory in a package is also a package

lib/package.d : allow to put all the lib modules as public 
import

lib/module1.d : this is module 1 from package lib
lib/module2.d : this is module 2 from package lib
lib/sub1/package.d : allow to put all the lib.sub1 modules as 
public import

lib/sub1/module1: this is module 1 from package lib.sub1
lib/sub1/module2: this is module 2 from package lib.sub1

but when you compile 'lib' library it's a monolithic *.a or 
*.lib file, which still requires the sources.


look at https://github.com/gecko0307/dlib/tree/master/dlib 
structure for example.


To be exact it doesn't need the sources, it needs the function 
signatures and type definitions so the equivalent of C header 
files. If you don't want to share the full sources with your 
library you can generate those header files automatically using 
the -H flag in dmd. It will produce a "D interface" file with a 
"di" extension.

Re: WIP: http://wiki.dlang.org/Contributing_to_dlang.org#Editing_Content

[Andrei Alexandrescu via Digitalmars-d]

On 12/18/15 10:51 AM, Andrei Alexandrescu wrote:

I've started http://wiki.dlang.org/Contributing_to_dlang.org. Is this
the kind of content that people are looking for? Destroy! -- Andrei


OK, it's in reviewable form now. DEFILE IT!

http://wiki.dlang.org/Contributing_to_dlang.org


Andrei

[Issue 15460] New: Ddoc: merge the opening comment "" into the default definition of DDOC

[via Digitalmars-d-bugs]

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

  Issue ID: 15460
   Summary: Ddoc: merge the opening comment "" into the default definition
of DDOC
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

In order to e.g. generate plaintext with Ddoc, the macro DDOC needs to be
$(BODY) so there's no additional adornments. That's nice and simple. However,
the annoying comment



is still emitted. There's no good reason to emit it separately - make it part
of the DDOC default definition.

--

Re: Scope of D packages

[Basile B. via Digitalmars-d-learn]

On Friday, 18 December 2015 at 23:20:34 UTC, Jakob Jenkov wrote:
I'm coming from Java where "packages" are not that much more 
than directories. Each class can be exposed or hidden inside a 
package etc.


In Java it is common that an API consists of many packages and 
subpackages. All classes are simply wrapped up in a JAR (Zip) 
file, and then they can be used as a library.


What is common in D?

Does a library have all its classes inside the same package 
(same directory) ? Or can you have multiple packages / 
subpackages inside the same library *and* same source root?


each sub directory in a package is also a package

lib/package.d : allow to put all the lib modules as public import
lib/module1.d : this is module 1 from package lib
lib/module2.d : this is module 2 from package lib
lib/sub1/package.d : allow to put all the lib.sub1 modules as 
public import

lib/sub1/module1: this is module 1 from package lib.sub1
lib/sub1/module2: this is module 2 from package lib.sub1

but when you compile 'lib' library it's a monolithic *.a or *.lib 
file, which still requires the sources.


look at https://github.com/gecko0307/dlib/tree/master/dlib 
structure for example.

Re: Problems with string literals and etc.c.odbc.sql functions

[Fer22f via Digitalmars-d-learn]

On Friday, 18 December 2015 at 22:35:04 UTC, anonymous wrote:
If the parameter is de facto const, then the cast is ok. 
Though, maybe it should be marked const then.


I'm just worried about casts because I read somewhere that 
strings start with the number of characters inside them (probably 
in slices documentation), and not with actual content (though 
string literals probably act different in this case).


Documentation on casts say:

Casting a pointer type to and from a class type is done as a type 
paint (i.e. a reinterpret cast).


Reinterpretation is rather dangerous if strings are stored 
differently.


But this test gives me a good hope on this case:

writeln(*(cast(char*) "Test"));

Casting is what I'm going with. .dup.ptr is less clear in this 
case.

Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

[Carl Sturtivant via Digitalmars-d]

On Friday, 18 December 2015 at 16:59:54 UTC, bachmeier wrote:
On Friday, 18 December 2015 at 15:09:05 UTC, Ola Fosheim 
Grøstad wrote:


That's why I'm working on embedding R inside D (almost done).


Very interesting, I've been considering the same recently, so I'm 
happy to hear about this. Is any of this visible or usable by an 
outsider like me?

Re: View Expanded Templates?

[Stefan Koch via Digitalmars-d-learn]

On Friday, 18 December 2015 at 18:25:03 UTC, Taylor Hillegeist 
wrote:
Is it possible to view the expanded form of templates or 
perhaps view the post-ctfe pre-compiled d code? I couldn't find 
any information on this topic but I think it would be useful. 
sometimes I use templates/mixins to write code for me but, 
sometimes i would rather have the expanded functions in the 
final versions.


I am builing a tool based on SDC that will allow just that :)

Re: We need a good code font for the function signatures on dlang.org

[Andrei Alexandrescu via Digitalmars-d]

On 12/18/2015 04:06 PM, Jack Stouffer wrote:

On Thursday, 17 December 2015 at 13:59:14 UTC, Andrei Alexandrescu wrote:

On 12/17/2015 03:07 AM, Mike Parker wrote:

On Wednesday, 16 December 2015 at 21:05:27 UTC, Andrei Alexandrescu
wrote:



What would be a good code font to use for those?



http://sourcefoundry.org/hack/


Could someone please round up this and other proposals into pull
requests? Then we can see them displayed in Vladimir's rig. Thanks! --
Andrei


https://github.com/D-Programming-Language/dlang.org/pull/1170
https://github.com/D-Programming-Language/dlang.org/pull/1171
https://github.com/D-Programming-Language/dlang.org/pull/1172
https://github.com/D-Programming-Language/dlang.org/pull/1173

Despite people's requests, Consolas is a premium font owned by
Microsoft, so it cannot be used. Inconsolas was included instead.


Cool, thanks! Shall we take one of them rigged referendums? -- Andrei

Re: We need a good code font for the function signatures on dlang.org

[Jack Stouffer via Digitalmars-d]

On Friday, 18 December 2015 at 21:15:48 UTC, Andrei Alexandrescu 
wrote:

rigged referendums


Huh?

DUB config format: SDLang or JSON?

[Jakob Jenkov via Digitalmars-d-learn]

I am just looking at DUB and I can read that there are two config 
formats: SDLang and JSON. Which one is the "new" format? Which 
one is the "future" of DUB?

Re: DUB config format: SDLang or JSON?

[Brad Anderson via Digitalmars-d-learn]

On Friday, 18 December 2015 at 22:30:00 UTC, Jakob Jenkov wrote:
I am just looking at DUB and I can read that there are two 
config formats: SDLang and JSON. Which one is the "new" format? 
Which one is the "future" of DUB?


SDLang is the new one. JSON will remain supported. Use whichever 
you like better.

Re: D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

[bachmeier via Digitalmars-d]

On Friday, 18 December 2015 at 21:26:16 UTC, Carl Sturtivant 
wrote:

On Friday, 18 December 2015 at 16:59:54 UTC, bachmeier wrote:
On Friday, 18 December 2015 at 15:09:05 UTC, Ola Fosheim 
Grøstad wrote:


That's why I'm working on embedding R inside D (almost done).


Very interesting, I've been considering the same recently, so 
I'm happy to hear about this. Is any of this visible or usable 
by an outsider like me?


Send me an email at the address found here: 
http://www.k-state.edu/economics/staff/bios/bachmeier.html


It's very much usable now. I am finishing the documentation, 
interoperability with R data, and practical functionality like 
linear algebra. Without those, embedding isn't particularly 
helpful. I just don't want to make my work publicly available 
until it's worth the time for others to use it.

Re: We need a good code font for the function signatures on dlang.org

[Andrei Alexandrescu via Digitalmars-d]

On 12/18/15 4:19 PM, Jack Stouffer wrote:

On Friday, 18 December 2015 at 21:15:48 UTC, Andrei Alexandrescu wrote:

rigged referendums


Huh?


Forgot the smiley - you know, all that online voting that swung wildly 
which every way. -- Andrei

Problems with string literals and etc.c.odbc.sql functions

[Fer22f via Digitalmars-d-learn]

By the use of this tutorial 
(http://www.easysoft.com/developer/languages/c/odbc_tutorial.html), I thought it would be very straightforward to use etc.c.odbc.sqlext and etc.c.odbc.sql to create a simple odbc application. But as soon as I started, I noticed a quirk:


SQLRETURN ret;
SQLHDBC dbc;
ret = SQLDriverConnect(dbc, null, "DNS=*mydns*;", SQL_NTS,
null, 0, null, SQL_DRIVER_COMPLETE);

This gives me an error: function 
etc.c.odbc.sqlext.SQLDriverConnect (void* hdbc, void* hwnd, char* 
szConnStrIn, short cbConnStrIn, char* szConnStrOut, short 
cbConnStrOutMax, short* pcbConnStrOut, ushort fDriverCompletion) 
is not callable using argument types (void*, typeof(null), 
string, int, typeof(null), int, typeof(null), int)


After some casting, I found out it's all related to the string 
literal. I thought it would work straight off the box, after 
reading the "Interfacing to C" spec 
(http://dlang.org/spec/interfaceToC.html).


When I remove the string literal and replace it with null, it 
compiles. .ptr and .toStringz both give immutable char* 
references, and don't work. A "cast(char *)"DNS=*maydns*;"" 
works, but it feels a lot like a hack that will not work in the 
long run.

Re: Problems with string literals and etc.c.odbc.sql functions

[anonymous via Digitalmars-d-learn]

On 18.12.2015 23:14, Fer22f wrote:

By the use of this tutorial
(http://www.easysoft.com/developer/languages/c/odbc_tutorial.html), I
thought it would be very straightforward to use etc.c.odbc.sqlext and
etc.c.odbc.sql to create a simple odbc application. But as soon as I
started, I noticed a quirk:

 SQLRETURN ret;
 SQLHDBC dbc;
 ret = SQLDriverConnect(dbc, null, "DNS=*mydns*;", SQL_NTS,
 null, 0, null, SQL_DRIVER_COMPLETE);

This gives me an error: function etc.c.odbc.sqlext.SQLDriverConnect
(void* hdbc, void* hwnd, char* szConnStrIn, short cbConnStrIn, char*
szConnStrOut, short cbConnStrOutMax, short* pcbConnStrOut, ushort
fDriverCompletion) is not callable using argument types (void*,
typeof(null), string, int, typeof(null), int, typeof(null), int)

After some casting, I found out it's all related to the string literal.
I thought it would work straight off the box, after reading the
"Interfacing to C" spec (http://dlang.org/spec/interfaceToC.html).

When I remove the string literal and replace it with null, it compiles.
.ptr and .toStringz both give immutable char* references, and don't
work. A "cast(char *)"DNS=*maydns*;"" works, but it feels a lot like a
hack that will not work in the long run.


If the parameter is de facto const, then the cast is ok. Though, maybe 
it should be marked const then.


If the parameter is really not const, i.e. the function may mutate the 
argument, then the cast is not ok. You can use `.dup.ptr` instead to get 
a proper char* from a string.


Also, remember that D's GC doesn't scan foreign memory. So if the 
function keeps the string around, and that's the only reference, then 
the GC would collect it. The function probably doesn't keep the string 
around, though.

Re: D programming video tutorial

[Jakob Jenkov via Digitalmars-d-learn]

I have written more than 750 tutorials about Java


... and web development and other related stuff. Not only Java.

Re: D programming video tutorial

[Jakob Jenkov via Digitalmars-d-learn]

On Sunday, 13 December 2015 at 20:29:47 UTC, Pederator wrote:
Hi. Does anybody who is familair with D consider to make a 
comprehensive D programming video tutorial / training / course? 
This could be encouraging and helpful for people to start with 
D. It could also help in promoting D programming language. This 
is a question for all the community, please comment what do you 
think about this idea, we will know if there is an interest in 
such a training video, or is it just me.


Hi,

I have written more than 750 tutorials about Java, and made 19 
videos. My experience is, that once I have the written tutorial 
then I also have the TOC for the corresponding video. I can 
usually record a screencast in about 0,5 to 2 hours, and then it 
takes about the same time to put the screencast parts together 
into a coherent video. Someone else can normally do that, though.


I have been thinking about writing about D too. Maybe make a few 
videos. But I don't know... I don't know how big the interest is 
in total.

Re: We need a good code font for the function signatures on dlang.org

[Jack Stouffer via Digitalmars-d]

On Thursday, 17 December 2015 at 13:59:14 UTC, Andrei 
Alexandrescu wrote:

On 12/17/2015 03:07 AM, Mike Parker wrote:
On Wednesday, 16 December 2015 at 21:05:27 UTC, Andrei 
Alexandrescu wrote:




What would be a good code font to use for those?



http://sourcefoundry.org/hack/


Could someone please round up this and other proposals into 
pull requests? Then we can see them displayed in Vladimir's 
rig. Thanks! -- Andrei


https://github.com/D-Programming-Language/dlang.org/pull/1170
https://github.com/D-Programming-Language/dlang.org/pull/1171
https://github.com/D-Programming-Language/dlang.org/pull/1172
https://github.com/D-Programming-Language/dlang.org/pull/1173

Despite people's requests, Consolas is a premium font owned by 
Microsoft, so it cannot be used. Inconsolas was included instead.