Re: Official dub packages for Debian and Ubuntu

[Jordi Sayol via Digitalmars-d-announce]

El 15/04/16 a les 19:52, Andrei Alexandrescu via Digitalmars-d-announce ha 
escrit:
> Awesomne, Jordi. I recently got a notice that the dmd compiler has been 
> updated by Ubuntu's package manager. Clicked, got it, all went smoothly. 
> Should I take it we owe all of that to you? -- Andrei

I think so :-)
Many thanks Andrei, and all d-apt users.

Re: Official dub packages for Debian and Ubuntu

[Andrei Alexandrescu via Digitalmars-d-announce]

On 04/15/2016 01:34 PM, Jordi Sayol via Digitalmars-d-announce wrote:

I'll include "Provides: d-compiler" on dlang dmd deb package and d-apt dmd-bin 
deb too. Many thanks!


Awesomne, Jordi. I recently got a notice that the dmd compiler has been 
updated by Ubuntu's package manager. Clicked, got it, all went smoothly. 
Should I take it we owe all of that to you? -- Andrei

Re: Official dub packages for Debian and Ubuntu

[Jordi Sayol via Digitalmars-d-announce]

El 15/04/16 a les 01:09, Matthias Klumpp via Digitalmars-d-announce ha escrit:
> On Thursday, 14 April 2016 at 18:42:49 UTC, Jordi Sayol wrote:
>> El 14/04/16 a les 17:54, Matthias Klumpp via Digitalmars-d-announce ha 
>> escrit:
>>> On Tuesday, 12 April 2016 at 13:28:29 UTC, Jordi Sayol wrote:
>>> [...]
>>> I think with "property" you mean "virtual package". See 
>>> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
>>> Basically, the dmd package needs a "Provides: d-compiler" line, then it 
>>> should be able to satisfy the dependencies of the dub package.
>>
>> Thanks. What happen is multiple packages, all of them not installed, sets 
>> "Provides: d-compiler"? Which one is installed?
> 
> I think in that case the (alphabetically) first real package is installed. 
> This is an uncommon case though, usually when virtual packages are used, a 
> default dependency is provided (so you have "default | virtual").
> 

I'll include "Provides: d-compiler" on dlang dmd deb package and d-apt dmd-bin 
deb too. Many thanks!

Re: TTS Synthesis: D and vibe.d in Action

[Chris via Digitalmars-d-announce]

On Thursday, 14 April 2016 at 17:55:40 UTC, Ali Çehreli wrote:

On 04/14/2016 03:57 AM, Chris wrote:


What is CvDda>?


Abbreviation of your name by Andre's email program: "Chris via 
Digitalmars-d-announce". :)


Ali


Oh deary me! That was a tough one for me :) Type CvDda into your 
search engine, the results are confusing.

Re: Official dub packages for Debian and Ubuntu

[Johannes Pfau via Digitalmars-d-announce]

Am Thu, 14 Apr 2016 23:16:49 +
schrieb Matthias Klumpp :

> On Thursday, 14 April 2016 at 17:46:55 UTC, Johannes Pfau wrote:
> > OSS projects do not use interface files though: It prevents 
> > inlining of functions and there's no real benefit for OSS 
> > projects. Interface files are (theoretically) useful for closed 
> > source libraries if you don't want to ship the source code.  
> 
> I think those would also be useful for FLOSS projects, if you 
> ship a compiled binary and don't want to recompile the code.
> This is the case for example for very huge projects which take 
> long to compile (think in WebKit or Eigen3 dimensions), or for 
> Linux distributions which want to separate as much code as 
> possible and prevent code duplication and statically linked stuff 
> to make security uploads easier and faster.
> 

I totally agree it makes sense to ship precompiled libraries. But even
with precompiled libraries you can still ship the full source code
instead of header files. An example:

a/foo.d:

module foo;
int fooFunc() {return 42;}


=> dmd -H a/foo.d => b/foo.di

// D import file generated from 'foo.d'
module foo;
int fooFunc();


dmd -lib a/foo.d -oflibfoo.a

main.d

import foo;
void main(){fooFunc()}


// We need foo.di or foo.d in the import path
dmd main.d -L-L. -L-lfoo
main.d(1): Error: module foo is in file 'foo.d' which cannot be read

// This uses the foo.di header
dmd main.d -L-L. -L-lfoo -Ib

// This uses foo.d as a header, but does _not_ compile foo.d
dmd main.d -L-L. -L-lfoo -Ia


The important point here is that you can use the normal source code as
headers. The source code of a library is not recompiled, it's only used
to parse function definitions and similar stuff. The compilation speed
should be very similar for .d and .di files as well. The benefit of
shipping the complete source code is that fooFunc can be inlined into
main.d with the foo.d source, but not with foo.di.

Shipping .di files only makes sense if you have to hide the source
code.

> > If you built a library with GDC you can't use it with LDC or 
> > DMD. This is one reason why dub compiles everything from 
> > source. (Even different frontend versions can sometimes break 
> > ABI compatibility).  
> 
> Is there any way this can be fixed? 
> https://dlang.org/spec/abi.html gave me the impression D has a 
> defined ABI the compilers adhere too (which would be a great 
> advantage over C++).
> Fixing this would be pretty useful, not only for the distro 
> usecase, I think.

The ABI is partially standardized:
* Name mangling is the same for all compilers.
* D has a special calling convention on X86 windows, but all other
  architectures and all other OS use the C calling convention. The
  compilers should be compatible, but this is something which needs
  some testing. 

* Exception handling: DMD recently implemented DWARF exception
  handling, so the compilers could be compatible but the personality
  functions are not. I'm not sure if the implementations are
  compatible, but not even the function names match
  (__dmd_personality_v0 / __gdc_personality_v0)
* The biggest problem is druntime: we need to make sure that the
  druntime libraries used by different compilers have a compatible ABI.

> Thanks for the explanations, this is useful to know and helps me 
> to work around some of the issues short-term (long-term we would 
> really need a solution for these issues, since this will become a 
> huge issue if/when more D code makes it into distros).

I agree having a common ABI should be prioritized. It's really
annoying for distributions (E.g. archlinux installs druntime/phobos into
different directories /usr/include/dlang/{gdc,dmd,ldc} and never
installs compiled libraries). Shared D libraries are useless in
practice because of this issue.

This needs coordinated work from all compiler teams though. For GDC
I'll finally have to finish shared library support first... 

Re: Blog post: PGO: Optimizing D's virtual calls

[Johan Engelen via Digitalmars-d-announce]

On Wednesday, 13 April 2016 at 11:34:26 UTC, Johan Engelen wrote:

Hi all,
  I've written an article about how I implemented 
profile-guided optimization (PGO) of virtual calls to direct 
calls (a micro-micro-optimization, expected performance gain of 
just a few percent if any!).


I've updated the article with performance measurements of just 
the D code of LDC: the improvement with PGO is about 7% !

Re: Graylog Extended Log Format (GELF) for D

[Laeeth Isharc via Digitalmars-d-announce]

On Saturday, 9 April 2016 at 20:06:01 UTC, angel wrote:

But what about this ?
https://forum.dlang.org/thread/eryphpbznrrovjvxj...@forum.dlang.org


That arose out of a project that we are working on where it is 
convenient to be able to integrate with std.experimental.logger.  
Internal work that has been opensourced, rather than written with 
the primary target of open source, and if we had more time I 
would have suggested basing off Adil's work.  As it is, it was 
just a write from scratch by Ilya.  I thank Adil for making me 
aware of Graylog and Gelf format, as I wouldn't have known about 
it otherwise.


Main benefit for us is to be able to reap the benefits of 
std.experimental.logger - very easy to switch logging source, and 
I think runtime cost of trace statements should be zero if turned 
off.  Little fiddly state machines with a few things that need to 
be ironed out that only show up now and then, so writeflns and 
debugging in an IDE don't cut it.


Graylog is a bit of a monster that uses Mongo, elasticsearch and 
who knows what else - for some things might be easier to use the 
Gelf format with a D back end.  But it's a very nice way to think 
about the problem.