Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Thursday, 14 April 2016 at 17:46:55 UTC, Johannes Pfau wrote:

[...]

(1) Interface files

We have .di interface files as a replacement for C/C++ headers 
(although the .di extension is only a convention, you can also 
use the .d extension). These files do not contain function 
bodies, but they still need the complete source code for 
templates. The compilers can generate interface files from 
normal source code.


https://dlang.org/dmd-linux.html#interface-files


Looks like a pretty good choice for handling the 
interface-with-library issue.


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.



(2) Linking against installed libraries

The compilers can of course link against pre-compiled D 
libraries. IIRC dub does not have integrated support for this. 
The real problem is the D compilers are not ABI compatible.


Urgh...

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.


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).

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

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").

Re: Official dub packages for Debian and Ubuntu

[Jordi Sayol via Digitalmars-d-announce]

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:
>> El 12/04/16 a les 14:26, Matthias Klumpp via Digitalmars-d-announce ha 
>> escrit:
 I assume that the DMD package from dlang, or better d-apt, sets the d- 
 compiler property. Should dmd be prefered if it is present?
>>>
>>> I think so, since when installing it from non-free 3rd-party sources, the 
>>> user made an explicit choice for DMD.
>>> In terms of packaging, the packaging doesn't really care, any D compiler 
>>> will satisfy the requirements of the dub package.
>>
>>
>> No, dmd deb packages from dlang and d-apt do not set any d-compiler 
>> property. Where should it be set?
> 
> 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?

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

[Ali Çehreli via Digitalmars-d-announce]

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

Re: Official dub packages for Debian and Ubuntu

[Johannes Pfau via Digitalmars-d-announce]

Am Thu, 14 Apr 2016 16:29:31 +
schrieb Matthias Klumpp :

> On Thursday, 14 April 2016 at 16:05:04 UTC, Matthias Klumpp wrote:
> > On Tuesday, 12 April 2016 at 16:57:41 UTC, Joseph Rushton 
> > Wakeling wrote:  
> >> On Tuesday, 12 April 2016 at 01:58:13 UTC, Matthias Klumpp 
> >> wrote:  
> >>> On Monday, 11 April 2016 at 21:58:55 UTC, Joseph Rushton [...]
> >>> I can ask, but given that the Xenial final freeze is on 24. 
> >>> April (release on 26.) and changing compiler versions that 
> >>> late in the cycle is potentially dangerous, I guess there is 
> >>> only a slim chance of success... On the pro-side is that 
> >>> having a beta compiler in the LTS release is undesirable, but 
> >>> even then I need to find an Ubuntu developer who does have 
> >>> time to do the sync and get the feature-freeze-exception. LDC 
> >>> FTBFSing on armel in Debian (and not entering testing due to 
> >>> that at time) is also an issue :-/  
> >>
> >> Ouch :-(  Well, if you are happy to look into it, that would 
> >> be great -- no pressure, though. :-)  
> 
> FTR, I filed 
> https://bugs.launchpad.net/ubuntu/+source/ldc/+bug/1570006 - if 
> we are lucky, this still has a chance to go in.
> 
> As for further dub stuff, it is important that 
> https://github.com/D-Programming-Language/dub/issues/811 is 
> addressed, so we can build software using dub without downloading 
> stuff from the internet.
> Btw, since D doesn't know traditional headers like C/C++, how 
> would I link against a library without having the full sourcecode 
> present somewhere?
> 

(1) Interface files

We have .di interface files as a replacement for C/C++ headers (although
the .di extension is only a convention, you can also use the .d
extension). These files do not contain function bodies, but they still
need the complete source code for templates. The compilers can generate
interface files from normal source code.

https://dlang.org/dmd-linux.html#interface-files

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.


(2) Linking against installed libraries

The compilers can of course link against pre-compiled D libraries. IIRC
dub does not have integrated support for this. The real problem is the
D compilers are not ABI compatible. 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).

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Thursday, 14 April 2016 at 16:05:04 UTC, Matthias Klumpp wrote:
On Tuesday, 12 April 2016 at 16:57:41 UTC, Joseph Rushton 
Wakeling wrote:
On Tuesday, 12 April 2016 at 01:58:13 UTC, Matthias Klumpp 
wrote:

On Monday, 11 April 2016 at 21:58:55 UTC, Joseph Rushton [...]
I can ask, but given that the Xenial final freeze is on 24. 
April (release on 26.) and changing compiler versions that 
late in the cycle is potentially dangerous, I guess there is 
only a slim chance of success... On the pro-side is that 
having a beta compiler in the LTS release is undesirable, but 
even then I need to find an Ubuntu developer who does have 
time to do the sync and get the feature-freeze-exception. LDC 
FTBFSing on armel in Debian (and not entering testing due to 
that at time) is also an issue :-/


Ouch :-(  Well, if you are happy to look into it, that would 
be great -- no pressure, though. :-)


FTR, I filed 
https://bugs.launchpad.net/ubuntu/+source/ldc/+bug/1570006 - if 
we are lucky, this still has a chance to go in.


As for further dub stuff, it is important that 
https://github.com/D-Programming-Language/dub/issues/811 is 
addressed, so we can build software using dub without downloading 
stuff from the internet.
Btw, since D doesn't know traditional headers like C/C++, how 
would I link against a library without having the full sourcecode 
present somewhere?


Ideally, we would compile something like mustache-d[1] when 
building a .deb package for it, then have a dependency on that 
library pick up the prebuilt static library (or dynamic library, 
ideally, if there is one) and link against it (so we don't 
rebuild the code over and over again).
There doesn't seem to be a way though to export the interfaces a 
D library provides to link against a D library at time, so we 
likely would need to ship the full source additionally to the D 
library in the -dev package, and have dub figure out the details 
(make it pick up the existing binary instead of recompiling the 
module)...
These issues need to be solved for any distro, not only Debian, 
before packaging D code that is using dub becomes easily possible 
(ideally, a solution exists already, that I just don't know about 
yet ^^).


[1]: https://github.com/repeatedly/mustache-d

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Tuesday, 12 April 2016 at 16:57:41 UTC, Joseph Rushton 
Wakeling wrote:
On Tuesday, 12 April 2016 at 01:58:13 UTC, Matthias Klumpp 
wrote:
On Monday, 11 April 2016 at 21:58:55 UTC, Joseph Rushton 
Wakeling wrote:
Related note: I see the lcd version in xenial is 0.17.0~beta2 
-- I don't suppose there's any chance of upgrading that to 
the stable 0.17.1 release ... ?  (Not asking you to do it 
personally, just wondering if that's something that could be 
achieved.)


I can ask, but given that the Xenial final freeze is on 24. 
April (release on 26.) and changing compiler versions that 
late in the cycle is potentially dangerous, I guess there is 
only a slim chance of success... On the pro-side is that 
having a beta compiler in the LTS release is undesirable, but 
even then I need to find an Ubuntu developer who does have 
time to do the sync and get the feature-freeze-exception. LDC 
FTBFSing on armel in Debian (and not entering testing due to 
that at time) is also an issue :-/


Ouch :-(  Well, if you are happy to look into it, that would be 
great -- no pressure, though. :-)


I get the point about not updating compilers late in the 
development cycle, but this update is likely to produce a 
better package and I can't see it triggering any other package 
rebuilds beyond the LDC phobos/druntime packages.


BTW, the package description for ldc, in both Debian and 
Ubuntu, is insanely out of date: it reads,


   LDC already compiles a lot of D code, but should still be
   considered beta quality. Take a look at the tickets to get
   a better impression on what still needs to be implemented.

... which AFAICT is unchanged from something like 5+ years ago, 
when the ldc packaged in Debian/Ubuntu was a D1-only compiler 
still in heavy development.


There is no real policy, at least I have found none. But from 
my tests, ldc simply crashed right away when trying to 
compile, later it wasn't able to process some code gdc had no 
problems with (I haven't tried the upcoming release). Since 
the GNU Compiler Collection is Debian's default compiler, I 
have set the compiler dependency of dub to gdc | ldc | 
d-compiler, so gdc is preferred, but replacing it with any 
other compiler will work too.


That's very odd.  What were you trying to build ... ?


This is likely a packaging issue - I tried this again on Xenial, 
and got

```
Warning: failed to locate the configuration file ldc2.conf
Error: cannot find source code for runtime library file 'object.d'
   ldc2 might not be correctly installed.
```
So yeah, this doesn't look like an upstream issue. I'll play 
around with LDC a bit more (and update it to a non-beta version, 
and maybe to Git master), maybe this evening - I really want 
std.concurrency.Generator, which GDC doesn't provide and which I 
currently embed in my code. The better std.getopt in newer 
standard library versions would also be nice (not sure how recent 
that is in LDC).


I didn't touch that, since dub seems to automatically find the 
right compiler. The preference seems to be dmd >> gdc >> ldc2, 
which looks sane to me.


Yea, sounds good.

Related note: would it be viable in principle to get dmd itself 
into Debian and Ubuntu repositories via (respectively) non-free 
and multiverse ... ?  Again, not asking you to do the work, but 
just curious based on your experience of being a Debian 
packager.


For non-free/multiverse: Maybe. Proprietary compilers are 
generally something not liked very much in the Debian community, 
and pushing the free compilers would be seen as the much better 
approach.
That being said, if someone wants to do the work and do proper 
packaging of dmd, nobody would stop that work being done either.


For Debian Stretch I assume the situation will be much better 
though :-) (given the state of the LDC and GDC Git repos).


Looking forward to it :-)  And, thank you again!


:-)

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

[Chris via Digitalmars-d-announce]

On Wednesday, 13 April 2016 at 19:09:46 UTC, Andre Polykanine 
wrote:

Hello Chris,

CvDda> Just to inform you that we successfully use D and vibe.d 
for two CvDda> things:


This is just overwhelming!
How do you make bindings to NVDA API which is in Python?
I'm  not  an  NVDA  user (I'm using JAWS, if it matters), but 
I'm still

very interested in the technology.


Andre.


Hi Andre,

What is CvDda>? There are loads of different results in my search 
engine.


To answer your question: in Python you can load DLLs via Python's 
ctypes. You just load the DLL via `CDLL()` or 
`cdll.LoadLibrary()`. It's relatively easy to make a Windows DLL 
in D. To make it accessible for Python's C-types, just expose 
your functions like so


extern (C) {
 export void myFunction(){}
}

Of course, any arguments (at least on Windows) or return types 
should be C-style, i.e. `const char*` instead of `string`. To 
Python it all looks like C, it doesn't know about D. I've seen a 
plug-in written in Scheme and it is also loaded via Python's 
`CDLL()`.


To bind a Python function to your DLL just do something like this 
(assuming you're in a class):


// Load
self.myDLL = CDLL("path/to/dll")

If your function is void, just call it using

// call void function in DLL
self.myDLL.myFunciton();

If it returns something, you should first define the return value:

// assign return type to function in Python
self.myDLL.getError.restype = c_char_p

To pass arguments, it's best to convert Python to C-types like so:

// pass argument as C-type
self.myDLL.myFunction(c_char_p("text"))

It's all in the Python docs at 
https://docs.python.org/2/library/ctypes.html.

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

[Johan Engelen via Digitalmars-d-announce]

On Wednesday, 13 April 2016 at 13:08:30 UTC, Andrei Alexandrescu 
wrote:


Noice.

https://twitter.com/D_Programming/status/720236648034877440

https://www.facebook.com/dlang.org/posts/1275322695814742

https://www.reddit.com/r/programming/comments/4elfok/profile_guided_optimization_optimizing_ds_virtual/

http://hackerne.ws


Thanks for posting these!

-Johan