Am Tue, 02 May 2017 20:53:50 +0000
schrieb Moritz Maxeiner <moritz@ucworks.org>:

> On Tuesday, 2 May 2017 at 19:34:44 UTC, Marco Leise wrote:
> >
> > I see what you're doing there, but your last point is wishful thinking. Dynamically linked binaries can share megabytes of code. Even Phobos - although heavily templated - has proven to be very amenable to sharing. For example, a "Hello world!" program using `writeln()` has these sizes when compiled with `dmd -O -release -inline`:
> >
> >      static Phobos2 : 806968 bytes
> >     dynamic Phobos2 :  18552 bytes
> >
> > That's about 770 KiB to share or 97.7% of its total size! Awesome!
> 
> Is all of that active code, or is some of that (statically knowable) never getting executed (as in could've been removed at compile/link time)?

I guess David gave you the answer. So it's just 95.4% of its
total size. :p
By the way, is the fully dynamic linking version possible with
ldc2 now as well ?

-- 
Marco

On Tuesday, 2 May 2017 at 23:27:28 UTC, Marco Leise wrote:
> Am Tue, 02 May 2017 20:53:50 +0000
> schrieb Moritz Maxeiner <moritz@ucworks.org>:
>
>> On Tuesday, 2 May 2017 at 19:34:44 UTC, Marco Leise wrote:
>> >
>> > I see what you're doing there, but your last point is wishful thinking. Dynamically linked binaries can share megabytes of code. Even Phobos - although heavily templated - has proven to be very amenable to sharing. For example, a "Hello world!" program using `writeln()` has these sizes when compiled with `dmd -O -release -inline`:
>> >
>> >      static Phobos2 : 806968 bytes
>> >     dynamic Phobos2 :  18552 bytes
>> >
>> > That's about 770 KiB to share or 97.7% of its total size! Awesome!
>> 
>> Is all of that active code, or is some of that (statically knowable) never getting executed (as in could've been removed at compile/link time)?
>
> I guess David gave you the answer. So it's just 95.4% of its
> total size. :p

Under the assumption that ldc2 produces no dead code in the output; is that a reasonable assumption (I'm not sure)?

> By the way, is the fully dynamic linking version possible with
> ldc2 now as well ?

I did have a modified ebuild to try that out a while back and it seemed to work fine in my limited testing scope. Since I quite often change installed d compilers and don't want my programs (like tilix) to stop working (or have old d compiler versions being kept installed *just* because some programs were built with them), I generally link against phobos statically, anyway, so I my tests weren't exhaustive. The cmake flag to to use in the ebuild would be BUILD_SHARED [1].

[1] https://github.com/ldc-developers/ldc/blob/v1.2.0/CMakeLists.txt#L522

Am Wed, 03 May 2017 01:02:38 +0000
schrieb Moritz Maxeiner <moritz@ucworks.org>:

> On Tuesday, 2 May 2017 at 23:27:28 UTC, Marco Leise wrote:
> > Am Tue, 02 May 2017 20:53:50 +0000
> > schrieb Moritz Maxeiner <moritz@ucworks.org>:
> > 
> >> On Tuesday, 2 May 2017 at 19:34:44 UTC, Marco Leise wrote:
> >> >
> >> > I see what you're doing there, but your last point is wishful thinking. Dynamically linked binaries can share megabytes of code. Even Phobos - although heavily templated - has proven to be very amenable to sharing. For example, a "Hello world!" program using `writeln()` has these sizes when compiled with `dmd -O -release -inline`:
> >> >
> >> >      static Phobos2 : 806968 bytes
> >> >     dynamic Phobos2 :  18552 bytes
> >> >
> >> > That's about 770 KiB to share or 97.7% of its total size! Awesome!
> >> 
> >> Is all of that active code, or is some of that (statically knowable) never getting executed (as in could've been removed at compile/link time)?
> >
> > I guess David gave you the answer. So it's just 95.4% of its total size. :p
> 
> Under the assumption that ldc2 produces no dead code in the output; is that a reasonable assumption (I'm not sure)?
> 
> > By the way, is the fully dynamic linking version possible with ldc2 now as well ?
> 
> I did have a modified ebuild to try that out a while back and it seemed to work fine in my limited testing scope. Since I quite often change installed d compilers and don't want my programs (like tilix) to stop working (or have old d compiler versions being kept installed *just* because some programs were built with them), I generally link against phobos statically, anyway, so I my tests weren't exhaustive. The cmake flag to to use in the ebuild would be BUILD_SHARED [1].
> 
> [1] https://github.com/ldc-developers/ldc/blob/v1.2.0/CMakeLists.txt#L522

I remember seeing this line and thinking "aww .. no way to build both versions?". I.e. enable the "static-libs" USE flag to _also_ build static libraries accompanying the shared ones. I'll create an issue asking about that.

-- 
Marco

On Tuesday, 11 April 2017 at 00:47:34 UTC, Jonathan M Davis wrote:

Hi folks,

> Also, what are we even looking to distribute in debian? I would have thought that the normal thing to do would be to build with dub, in which case, having the compiler and dub be debian packages makes sense but not really anything else.

Are you only targeting manually operated inhouse applications
where operator = developer ?

I haven't done any serious D programming yet - the language itself
looks quite interesting to me, eg. for embedded systems.

Unfortunately, the current situation makes it pretty unusable to me.

> but then if you just statically link it, the ABI compatibility problem goes away as does any need to package any D library dependencies.

Technically correct, but then the maintainers of individual packages
have to keep an eye on each single package in the dependency chain,
eg. on security issues and rebuild in those cases - basically defeating
one of the major goals of the concept of distros.


--mtx

On Tuesday, 11 April 2017 at 12:56:59 UTC, Jonathan M Davis wrote:

> But if we just use dub - which _is_ the official packaging and build tool - then we avoid these issues. Ideally, the compiler and dub would be part of the distro, but libraries don't need to be.

But that would defeat a primary goal of distros: reproducable
builds, w/o depending on downloading anything from the internet.

Distros are doing that for good reasons: saves operators from
uncountable working hours (one of *the* major reason of Linux'
success).

> And it sounds like that's basically how the Go and Rust folks want to function as well.

Right. Exactly why we completely banned Go from a project
just a few days ago.


--mtx

On Tuesday, 11 April 2017 at 12:36:41 UTC, Russel Winder wrote:

> Most programming languages are going this route, used programming language tools and libraries are decreasingly packaged by the OS.

Exactly the reason why we banned Go quite recently.
Just far too expensive, especially w/ crosscompile.

> Given things like Anaconda and PyPI, all the Fedora and Debian Python packaging is increasingly wasted – except for those packages used by the distribution itself.

Not at all. These folks just completely ignore the whole purpose
of binary distros. And I regularily see that at operating costs.
One of the major reasons why Windows operating is so expensive is
the lack of proper package management and distro infrastructures.

Few years ago, I've introduced apt-based package management for
Zimbra extensions (for some solution provider who also develops
lots of own extensions and customizations). Cut down deployment
costs to less than 10%.

> So I can see Fedora and Debian packaging Python and some bits
> and pieces, but otherwise it's not needed. Same is true for Ruby, Go, Groovy, Java, etc.

With ruby, just given up completely - the community has shown
itself really hostile against distros, as well as any kind of
decent release engineering, which makes TOC very very expensive.

Python and Java are manageable (thanks to the hard work of distro
folks). No idea about Groovy.

Go is horrible - banned it from all projects.

> Debian and Fedora really do need to reassess their packaging strategy with respect to software development.

Software developers should reassess their methodologies with
respect to distros and operating - these are the folks who make
the software actually usable for the arbitrary user, and they
get all the basting if something goes wrong again.

> Far too much effort is going into packaging when rolling release
> is far better handled by language specific systems.

Far too much effort is going into proprietary / language specific
homebrewn tools, by people who believe their own little subspace
bubble was the whole universe and have no idea what matters in
professional operating.

Much of my professional work is being HoD - the interface between
development, operating and PMO - or training development teams.
The numbers on my table tell a clear story.

> I suggest getting the compilers onto the distributions as a marketing thing not as a real use thing.

Why should Distros like Debian do any marketing ?
Selling stuff isn't any of their objectives.

> For me the way Rust works by having it's own shell-based installer
> is the right way of installing languages.

For me (as HoD, release manager, auditor, embedded engineer, software
architect, etc) such things are an complete showstopper - reproducable
build and deployment is a hard requirement - anything else is just
dangerous and expensive.


--mtx