Re: From the D Blog: A Pattern for Head-mutable Structures

[Johannes Pfau via Digitalmars-d-announce]

Am Fri, 26 Jun 2020 08:36:06 + schrieb Mike Parker:

> I suspect they track HTTP referrers and red flag multiple hits to the
> same link from the same referrer. However they do it, I would expect
> linking directly to search results is something they account for.

Can't we just set Referrer-Policy: no-referrer in the web interface? 
Mailing list and newsgroup shouldn't be affected anyway.



-- 
Johannes

Re: Rationale for accepting DIP 1028 as is

[Johannes Pfau via Digitalmars-d-announce]

Am Thu, 28 May 2020 12:28:16 + schrieb Sebastiaan Koppe:

> On Thursday, 28 May 2020 at 09:21:09 UTC, Jonathan M Davis wrote:
>> He did unfortunately manage to convince Atila, so the DIP has been
>> accepted, but based on the discussions, I think that you may be the
>> only person I've seen say anything positive about the DIP treating
>> extern(C) functions as @safe.
>>
>> - Jonathan M Davis
> 
> I think Walter had to make a tough call with many tradeoffs. The
> defining feature of engineering I would say.
> 
> Is he wrong? Maybe, I don't know. The obvious path is far from always
> being a winner.
> 
> If it does come back to haunt him, he can always add a DIP to make
> extern(!D) @system by default. It won't invalidate any work.

This would be another round of massively breaking user code. And this is 
going to be exactly the argument that will be used to dismiss any DIP 
trying to change the defaults later on.


-- 
Johannes

Re: Rationale for accepting DIP 1028 as is

[Johannes Pfau via Digitalmars-d-announce]

Am Thu, 28 May 2020 10:50:44 +0200 schrieb Daniel Kozak:

> On Thu, May 28, 2020 at 4:56 AM Jonathan M Davis via
> Digitalmars-d-announce  wrote:
>>
>> As far as I can tell, Walter understands the issues but fundamentally
>> disagrees with pretty much everyone else on the issue.
> 
> I do not think so, the issue is, that there could be more people who
> agree with Walter (like me),
> but because we agree we do not participate.

You can not really assume any opinion for people who did not participate, 
unless you can really prove why there's a bias. I did not participate 
either and I do not agree with Walter. So now we can say the opinions of 
those who did not participate in the discussion are split 50:50 ;-)

We could assume there's a slight bias of those agreeing with Walter not 
responding because they don't have to actively convince anyone, as the 
DIP has been accepted. But given how much negative feedbcak there is, it's 
also likely people would voice their opinion to support the decision. 
Really the best thing we can assume is that the opionions of those not 
participating are split in the same way as the ones of those who are 
participating. The strawpoll posted recently suggests that as well:
https://www.strawpoll.me/20184671/r

-- 
Johannes

Re: Release D 2.087.0

[Johannes Pfau via Digitalmars-d-announce]

Am Mon, 15 Jul 2019 20:39:14 + schrieb David Nadlinger:

> On Monday, 15 July 2019 at 20:27:16 UTC, Johannes Pfau wrote:
>> I guess this should be documented somewhere then.
> 
> See druntime/CONTRIBUTING.md:
> 
> ```
> In general, only modules in the 'core' package should be made public.
> The single exception is the 'object' module which is not in any package.
> 
> The convention is to put private modules in the 'rt' or 'gc' packages
> depending on what they do and only put public modules in 'core'.
> 
> Also, always avoid importing private modules in public modules. […]
> ```
> 

Well, this just opens the discussion on private vs. public modules again. 
The new array hooks are private as well, according to the definition 
above they would have to be in rt. And core.internal.* certainly aren't 
public modules.

I don't see how "should be made public" can be interpreted as "should be 
installed", especially considering that templates need source code 
installed (core.internal), but that's completely orthogonal to what 
functions should be private (core.internal) / public to users of druntime.

However, I'll open a PR to clarify that paragraph.



> This split has been in place since back in the D1/Tango days.

Sure, the core vs rt split did. But core.internal did not exist in D1.

-- 
Johannes

Re: Release D 2.087.0

[Johannes Pfau via Digitalmars-d-announce]

Am Mon, 15 Jul 2019 19:52:57 + schrieb David Nadlinger:

> On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote:
>>  My understanding is the `rt` is the language implementation
>> and `core` is the low level library for users.
> 
> This understanding would be mistaken. We haven't been shipping `rt` on
> the import path for a long time. `core.internal` exists precisely to
> fill this role, i.e. code that needs to be around at druntime import
> time, but isn't supposed to be accessed directly by users.
> 
>   — David

I guess this should be documented somewhere then. GDC has always shipped 
and still ships rt. and never had any problem with that.

-- 
Johannes

Re: Release D 2.087.0

[Johannes Pfau via Digitalmars-d-announce]

Am Mon, 15 Jul 2019 20:14:46 + schrieb David Nadlinger:

> On Monday, 15 July 2019 at 14:00:23 UTC, Mike Franklin wrote:
>> I'm sorry it broke digger, but digger is not how we typically build
>> DMD, druntime, and Phobos.
> 
> Either way, there is a simple resolution here: Put new template code or
> other artefacts that are actually used via import in core.* (e.g.
> core.internal.*). This also provides a natural boundary between legacy
> code and the new runtime interface. If more and more code gets
> template-ised, rt.* will slowly wither away, but there is nothing wrong
> with that. At some point, it will just cease to exist naturally.

Well, I guess if we all agree that rt. is basically deprecated, this may 
be a good way to move forward.


-- 
Johannes

Re: Release D 2.087.0

[Johannes Pfau via Digitalmars-d-announce]

Am Mon, 15 Jul 2019 17:59:25 + schrieb Seb:

> On Monday, 15 July 2019 at 14:00:23 UTC, Mike Franklin wrote:
>> On Monday, 15 July 2019 at 13:00:08 UTC, Vladimir Panteleev wrote:
>>
 We are trying to implement many of those `extern(C)` runtime hooks as
 templates.  Those templates need to be implicitly imported through
 object.d.  That means code that was in `rt` is converted to a
 template, and then moved to object.d. However, as we do more and more
 of them object.d becomes unwieldy.

 I took the initiative to prevent object.d from turning into a more of
 a monstrosity that it already is, and moved those runtime templates
 (which used to reside in `rt`) back into `rt`.
>>>
>>> This is not a problem, and not at all related to the issue we're
>>> discussing. The problem is that you chose to move them into `rt`
>>> instead of somewhere under `core`, which would respect existing
>>> conventions and avoid breakages like the ones we've seen reported in
>>> this thread.
>>
>> It is related.  If I follow your suggestion to move these
>> implementations to `core.internal` and continue with the objective of
>> converting all runtime hooks to templates, the vast majority of `rt`
>> will end up being moved to `core.internal`.  Is that what you're
>> suggesting?
>>
>> `rt` is the language implementation.  `core.internal` contains the
>> utilities used internally by druntime and "privately" imported by
>> Phobos.  Following that established convention, I made the right
>> decision.
>>
>> I'm sorry it broke digger, but digger is not how we typically build
>> DMD, druntime, and Phobos.
>>
>> Mike
> 
> The point is that we don't ship the sources of rt to the user. That's
> the separation. With templates sources must be made available to the
> user, s.t. the compiler can instantiate them. However, rt doesn't get
> shipped to the user as it is compiled only.
> 

But why is that? What's the benefit here? And do we skip to this 
convention forever, only for legacy reasons?
We always shipped rt in gdc btw. Nobody ever complained.


If we decide to move that code to core.internal, I'm with Mike that we 
should simply move all array code out of rt. In the long term, we may 
even end up moving anything out of rt: Modern D code is template heavy, 
template code needs the sources available. Inlining needs the sources as 
well. The more we get rid of TypeInfo and the more we modernize the 
compiler/runtime interface, this weill become an issue.

And duplicating extern(C) declarations, syncing them manually, ... is a 
safety liability and maintainance nightmare (see my other post). So in no 
way should we start to add more such functions interfacing rt to 
core.internal.


-- 
Johannes

Re: Release D 2.087.0

[Johannes Pfau via Digitalmars-d-announce]

Am Mon, 15 Jul 2019 14:00:23 + schrieb Mike Franklin:

> On Monday, 15 July 2019 at 13:00:08 UTC, Vladimir Panteleev wrote:
> 
>>> We are trying to implement many of those `extern(C)` runtime hooks as
>>> templates.  Those templates need to be implicitly imported through
>>> object.d.  That means code that was in `rt` is converted to a
>>> template, and then moved to object.d. However, as we do more and more
>>> of them object.d becomes unwieldy.
>>>
>>> I took the initiative to prevent object.d from turning into a more of
>>> a monstrosity that it already is, and moved those runtime templates
>>> (which used to reside in `rt`) back into `rt`.
>>
>> This is not a problem, and not at all related to the issue we're
>> discussing. The problem is that you chose to move them into `rt`
>> instead of somewhere under `core`, which would respect existing
>> conventions and avoid breakages like the ones we've seen reported in
>> this thread.
> 
> It is related.  If I follow your suggestion to move these
> implementations to `core.internal` and continue with the objective of
> converting all runtime hooks to templates, the vast majority of `rt`
> will end up being moved to `core.internal`.  Is that what you're
> suggesting?
> 
> `rt` is the language implementation.  `core.internal` contains the
> utilities used internally by druntime and "privately" imported by
> Phobos.  Following that established convention, I made the right
> decision.
> 
> I'm sorry it broke digger, but digger is not how we typically build DMD,
> druntime, and Phobos.
> 
> Mike

I agree here: rt is code deeply tied to the language / compiler. 
core.internal is largely code which is useful as standalone module 
(abort, convert, parts of dassert, lifetime, traits, string).

However, the structure is not really clear: rt.util (older than 
core.internal) should probably rather be part of core.internal and some 
code in core.internal (arrayop, assert) should be in rt.

Either way, dictating a code structure on druntime only because of build 
system aspects (these files are installed, these are not) seems to be a 
very bad idea. The code should be structured in a way to minimize cross-
module dependencies and to seperate compiler specific from generic code.

In addition, the build system shipped as part of druntime is the 
authoritative way to build the project. Even though digger is an 
important tool, we can't really compromise on code quality in druntime 
only to stay compatible to build systems using undocumented internals of 
the runtime build process.

-- 
Johannes

Re: Release D 2.087.0

[Johannes Pfau via Digitalmars-d-announce]

Am Mon, 15 Jul 2019 12:27:22 + schrieb Vladimir Panteleev:

> On Monday, 15 July 2019 at 12:14:16 UTC, Mike Franklin wrote:
>> Many of the implementations in `rt/array` require importing or
>> referencing other implementations in `rt` (e.g. `rt.lifetime`).
>>  If they were moved to `core.internal` they would require
>> importing `rt` or peeking into `rt` with various hacks, which exactly
>> what you've said should not be done.
> 
> This isn't exactly true. The restriction is that core should not
> *import* rt. Have a look at all the extern(C) definitions in Druntime -
> using extern(C) functions to communicate between the compiler and rt, as
> well as core and rt, is not a "hack", but an established mechanism to
> invoke the low-level implementations in Druntime.


Grepping for extern in core.internal yields one result outside of 
pareoptions.d. If you count parseoptions.d, 6 results.

I wonder how you can advertise this as a good idea: You have to manually 
keep declarations in sync, you have to be very careful to get the 
attributes right, module constructor evaluation order guarantees don't 
hold, no mangling (no type safety), you pollute the C namespace, no 
inlining, no templates.

This is an established workaround at best, in no way it's a good solution.

-- 
Johannes

Re: Release D 2.087.0

[Johannes Pfau via Digitalmars-d-announce]

Am Mon, 15 Jul 2019 12:40:50 + schrieb Vladimir Panteleev:

> On Monday, 15 July 2019 at 12:36:14 UTC, Mike Franklin wrote:
>> Many of the implementations in `rt/array` are templates, so the entire
>> implementation should be available through object.d, not just
>> declarations.
> 
> The amount of templated code is still finite, otherwise you would have
> needed to include all of rt into the set of files to be made importable.

Which is due to the limited time available in GSoC. Right now, the 
implementations simply call typeid and forward to the TypeInfo based 
implementations. But all of these implementations are ultimately meant to 
be fully templated, and then you'll need access to lots of rt functions.

So why should we we now move the functions to core, so that we can later 
move them back to rt?

> 
>> In `core.internal`, I see utilities that appear to be intended for use
>> only within runtime, or "privately" imported by Phobos.
>>  I do not see implementations for fundamental language features
>> as can be found in `rt`.  The code in `rt/array` implementations for
>> fundamental language features, not utilities to be used privately with
>> druntime.
> 
> Please have a closer look:
> 
> - core.internal.hash contains the implementation of hashing routines
> used for associative arrays.
> - core.internal.arrayop contains the implementation of array vector
> operations. This one doesn't seem to be too far from your work in
> question.
> 

Both don't have any real dependencies. Maybe all the array implementation 
stuff could be moved to core, but until that happens moving only parts of 
the implementation seems to be a bad idea. Especially considering this:

>> "rt can import core, but core can't import rt." makes it pretty clear
>> to me.


It's probably a mistake that we even have both rt and core.internal. 
core.internal seems to be a much more recent addition (2013), probably 
inspired by std.internal. It's no wonder there's duplication and no 
clearly defined scope for the packages.

And why would anyone think it's a good idea not to install the rt 
headers? What do you gain from this, except from a few KB saved disk 
space?

-- 
Johannes

Re: Release D 2.087.0

[Johannes Pfau via Digitalmars-d-announce]

Am Sun, 07 Jul 2019 08:06:57 + schrieb uranuz:

> After updating compiler to 2.087 I got a lot of deprecation warnings
> linked to std.json module. I have found all of the usages of deprecated
> symbols in my project and changed them to the new ones. All these
> warnings are about changing JSON_TYPE to JSONType JSON_TYPE.STRING to
> JSONType.string and etc...
> But after eleminating deprecated symbols from my project I still have
> deprecation warnings. Seems that these symbols being accessed from
> Phobos, because I am pretty sure that I don't have other external
> dependencies that use std.json. The problem it that because of this
> `spamming` messages I can miss `real` deprecation warnings. Is there
> some way to `fix` it? The is some part of compiler output (all of it is
> too long): /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum
> member `std.json.JSONType.INTEGER` is deprecated - Use .integer
> /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member


I think phobos does not explicitly use these deprecated symbols, but the 
reflection code in format triggers the deprecation messages:

import std.json, std.stdio;
void main()
{
JSONType c;
writefln("%s", c);
}

I'm not sure if this can be solved, maybe deprecated members can be 
explicitly ignored in format, but maybe the reflection code itself is 
triggering the deprecation (which would then probably be a DMD bug).

-- 
Johannes

Re: DConf 2019 Livestream

[Johannes Pfau via Digitalmars-d-announce]

Am Thu, 09 May 2019 09:27:13 -0700 schrieb H. S. Teoh:

> On Thu, May 09, 2019 at 01:54:31AM -0400, Nick Sabalausky (Abscissa) via
> Digitalmars-d-announce wrote:
> [...]
>> This sort of stuff happens literally EVERY year! At this point, you can
>> pretty much guarantee that for any Dconf, Day 1's keynote doesn't get
>> professionally livestreamed, if its recorded at all. At the very LEAST,
>> it makes us look bad.
>> 
>> Is there SOMETHING we can do about this moving forward? Maybe use
>> Dconf/Dfoundation funds to hire a proven video crew not reliant on
>> venue, or something...?
> 
> +1. This repeated unreliability of streaming/recording is embarrassing.
> We should just use our own video crew next DConf. *After* testing
> everything on-venue *before* the actual start of the conference, so that
> any issues are noticed and addressed beforehand.
> 
> 
> T

I guess we could contact the c3voc team, they organize streaming and VOD 
for various conferences (most notably the Chaos Communication Congress but 
also the SystemD (All Systems Go!), LinuxTag and various smaller events 
were handled by these guys). Apart from publishing (postprocessed) 
recordings and handling livestreams, they also have a reLive feature 
which allows you to watch the (not postprocessed) livestream recordings 
immediately after streaming ends. And they upload videos to youtube as 
well:
https://www.youtube.com/user/mediacccde/videos?app=desktop

https://c3voc.de/
https://c3voc.de/eventkalender
https://streaming.media.ccc.de/
https://media.ccc.de/a

Example: https://media.ccc.de/v/35c3-9783-the_mars_rover_on-board_computer
https://www.youtube.com/results?search_query=the+mars+rover+on-
board+computer

-- 
Johannes

Re: GDC with D frontend 2.081.2

[Johannes Pfau via Digitalmars-d-announce]

Am Tue, 28 Aug 2018 10:19:46 +0200 schrieb Daniel Kozak:

> On Tue, Aug 28, 2018 at 8:40 AM Eugene Wissner via
> Digitalmars-d-announce <
> digitalmars-d-announce@puremagic.com> wrote:
> 
>> On Tuesday, 28 August 2018 at 06:18:28 UTC, Daniel Kozak wrote:
>> > On Mon, Aug 27, 2018 at 7:55 PM Eugene Wissner via
>> > Digitalmars-d-announce < digitalmars-d-announce@puremagic.com>
>> > wrote:
>> >
>> >> On Monday, 27 August 2018 at 17:23:04 UTC, Arun Chandrasekaran
>> >> wrote:
>> >> > 1. It would be good to print the DMD frontend version with `gdc
>> >> > --version`. It is helpful in reporting bugs. LDC does this.
>> >> >
>> >> Unfortunately it doesn't seem to be possible. GCC doesn't allow to
>> >> change --version output:
>> >> https://bugzilla.gdcproject.org/show_bug.cgi?id=89
>> >>
>> >>
>> > This is not true, right now on archlinux if you type gdc --version it
>> > will display d frontend version
>> > https://bugzilla.gdcproject.org/show_bug.cgi?id=89#c1
>>
>> Is it set with --with-pkgversion? The same information will be
>> displayed for gcc and g++ then. It is not always desirable if you ship
>> the compiler as a whole (with libtool etc).
>>
>>
> Yes and no. It is set with  --with-pkgversion but it is only for gdc.

But this only works as you build gdc and gcc separately. I.e. for gdc, 
you build gcc+gdc, then throw away everything but gdc related 
executables. Then you compile gcc with different --with-pkgversion for 
the gcc package.

However, this has the problem that your gcc executable now does not 
properly forward .d files to gdc as that build did not have --enable-
languages=d. The supported way to do this is build all gcc based 
compilers at once. But then you can't use --with-pkgversion as it will 
apply to all compilers.

-- 
Johannes

Re: [OT] gdc status

[Johannes Pfau via Digitalmars-d-announce]

Am Wed, 11 Apr 2018 16:44:32 +0300 schrieb drug:

> 11.04.2018 16:26, Uknown пишет:
>> On Wednesday, 11 April 2018 at 13:17:23 UTC, drug wrote:
>>> 11.04.2018 15:22, bachmeier пишет:
 On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote:
 ... Given that GDC has been added to GCC...
>>> Is it true? I don't see anything like that here
>>> https://gcc.gnu.org/gcc-8/changes.html
>> 
>> Here's relevant news from Phoronix:
>> 
>> https://www.phoronix.com/scan.php?page=news_item=D-Frontend-For-GCC
>> 
>> Here's the relevant announcement:
>> https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html
> I've read it. Unfortunately it doesn't answer my question. I've heard
> there were some problems.

IIRC copyright stuff once again stalled further discussion and the 
relevant GCC guys are not responding:
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg186124.html


-- 
Johannes

Re: Visual Studio Code code-d serve-d beta release

[Johannes Pfau via Digitalmars-d-announce]

Am Tue, 08 Aug 2017 17:13:18 +
schrieb WebFreak001 :

> On Tuesday, 8 August 2017 at 08:03:05 UTC, Arjan wrote:
> > Small request: could the setting "d.stdlibPath" be inferred 
> > from the compiler in use? DMD and LDC both have a conf file in 
> > which the paths are already set.  
> 
> oh cool I didn't know that, is there a standard path to where 
> these conf files are though?

The D frontend (and therefore all compilers) already has code to print
the import paths. Unfortunately this code is only used when an import
is not found:
--
test.d:1:8: Fehler: module a is in file 'a.d' which cannot be read
 import a;
^
import path[0] = /usr/include/d
import path[1]
= /opt/gdc/lib/gcc/x86_64-unknown-linux-gnu/4.9.4/include/d
--

It should be trivial though to refactor this code and add a
command-line switch to dump the import path. See Module::read in
dmodule.c. If Walter opposes adding this to DMD (one more command line
switch!) we could probably still add it to GDC glue. This code is all
you need:

if (global.path)
{
for (size_t i = 0; i < global.path->dim; i++)
{
const char *p = (*global.path)[i];
fprintf(stderr, "import path[%llu] = %s\n", (ulonglong)i, p);
}
}


-- Johannes

Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye

[Johannes Pfau via Digitalmars-d-announce]

Am Mon, 31 Jul 2017 08:51:16 +
schrieb Mike :

> https://github.com/JinShil/svd_to_d
> 
> SVD_to_D is a command-line utility that generates D code from ARM 
> Cortex-M SVD files.
> 
> SVD files are XML files that describe, in great detail, the 
> memory layout and characteristics of registers in an ARM Cortex-M 
> microcontroller. See 
> https://github.com/posborne/cmsis-svd/tree/master/data for a 
> curated list of SVD files for many ARM Cortex-M microcontrollers 
> from various silicon vendeors.
> 
>  From the information in an SVD file, code for accessing the 
> microcontroller's memory-mapped-io registers can be automatically 
> generated, and SVD_to_D does exactly that.

Nice work! SVD seems to be an ARM standard / initiative? I wish there
was something similar for MSP/AVR/PIC controllers.


-- Johannes

Re: Life in the Fast Lane (@nogc blog post)

[Johannes Pfau via Digitalmars-d-announce]

Am Fri, 16 Jun 2017 13:51:18 +
schrieb Mike Parker :

> I've been meaning to get this done for weeks but have had a 
> severe case of writer's block. The fact that I had no other posts 
> ready to go this week and no time to write anything at all 
> motivated me to make time for it and get it done anyway. My wife 
> didn't complain when I told her I had to abandon our regular 
> bedtime Netflix time block (though she did extract a concession 
> that I have no vote in the next series we watch). Thanks to 
> Vladimir, Guillaume, and Steve, for their great feedback on such 
> short notice. Their assistance kept the blog from going quiet 
> this week.
> 
> The blog:
> https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/
> 
> Reddit:
> https://www.reddit.com/r/programming/comments/6hmlfq/life_in_the_fast_lane_using_d_without_the_gc/
> 
> 

Nice blog post!

> Let’s imagine a hypothetical programmer named J.P. who, for reasons
> he considers valid, has decided he would like to avoid garbage
> collection completely in his D program. He has two immediate options.

I think I might know that hypothetical programmer ;-)

-- Johannes

Re: DConf 2017 livestream

[Johannes Pfau via Digitalmars-d-announce]

On Thursday, 4 May 2017 at 08:02:22 UTC, Johannes Pfau wrote:

The DConf 2017 livestream is available here:
https://www.youtube.com/watch?v=MqrJZg6PgnM


Looks like the youtube video ID changes when the stream is 
stopped / restarted.
Look for the livestream on 
https://www.youtube.com/user/sociomantic/feed

or try https://www.youtube.com/user/sociomantic/live instead.

DConf 2017 livestream

[Johannes Pfau via Digitalmars-d-announce]

As nobody posted this in the announce group yet, I'll just repeat 
this information here:


The DConf 2017 livestream is available here:
https://www.youtube.com/watch?v=MqrJZg6PgnM


See the DLangConf twitter account for more information:
https://twitter.com/DLangConf

msgpack-ll: Low level @nogc, nothrow, @safe, pure, betterC MessagePack (de)serializer

[Johannes Pfau via Digitalmars-d-announce]

Hello list,

msgpack-ll is a new low-level @nogc, nothrow, @safe, pure and betterC
compatible MessagePack serializer and deserializer. The library was
designed to avoid any external dependencies and handle the low-level
protocol details only. It only depends the phobos bigEndianToNative and
nativeToBigEndian templates from std.bitmanip. It uses an optimized API
to avoid any runtime bounds checks and still be 100% memory safe.

The library doesn't have to do any error handling or buffer management
and never dynamically allocates memory. It's meant as a building block
for higher level serializers (e.g. vibeD data.serialization) or as
a high-speed serialization library. The github README shows a quick
overview of the generated ASM for serialization and deserialization.

dub: http://code.dlang.org/packages/msgpack-ll
github: https://github.com/jpf91/msgpack-ll
api: https://jpf91.github.io/msgpack-ll/msgpack_ll.html

-- Johannes

Re: dmd Backend converted to Boost License

[Johannes Pfau via Digitalmars-d-announce]

Am Fri, 7 Apr 2017 08:14:40 -0700
schrieb Walter Bright :

> https://github.com/dlang/dmd/pull/6680
> 
> Yes, this is for real! Symantec has given their permission to
> relicense it. Thank you, Symantec!

Great news! Maybe someone could notify http://phoronix.com . They've
blogged about D before and reach quite some linux users and developers.


-- Johannes

Re: Questionnaire

[Johannes Pfau via Digitalmars-d-announce]

Am Wed, 08 Feb 2017 21:41:24 +
schrieb Mike :

> On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
> wrote:
> > 1. Why your company uses  D?  
> 
> We don't use D.
> 
> > 2. Does your company uses C/C++, Java, Scala, Go, Rust?  
> 
> C/C++.  Currently exploring Rust.
> 
> > 3. If yes, what the reasons to do not use D instead?  
> 
> * The powers that be in my company are the kind of C programmers 
> that can't understand why anyone would want to use C++ (i.e. 
> Electrical engineers that write software).

I always felt like C is the better designed language when compared to
C++. Of course C misses many features of C++ and C also has some
badly designed features (preprocessor, header/include system, function
pointer syntax, array [n] not attached to the type but to the variable
identifier). But among some useful features C++ also adds much more
noise on top of the already existing C misfeatures: ugly template
syntax, iostreams/pipe syntax, operator overloading for controversial
operators, c++ namespaces, multiple inheritance, ...

Of course C has limited means for abstraction and therefore is not
suitable for certain projects. But the language feels 'cleaner' imho,
C++ sources files using templates and similar features are often hard to
read.

But OTOH I'm an electrical engineer as well ;-)

-- Johannes

Re: New GDC binaries: 2.068.2, shared library support, multilib support & a new gdmd tool

[Johannes Pfau via Digitalmars-d-announce]

On Tuesday, 27 December 2016 at 02:52:40 UTC, Martin Nowak wrote:
On Sunday, 25 December 2016 at 19:41:38 UTC, Johannes Pfau 
wrote:


* Shared library support: We added support for shared 
libraries to GDC


Great, might be time to revive 
https://github.com/dlang/druntime/pull/617 soon.


Sounds like a good idea :-)


* New mechanism to link system dependencies: All system 
libraries

  needed by phobos (-ldl, -lrt, -latomic) are detected in the
  phobos ./configure script. The required dependencies are 
added to a
  libgphobos.spec file and installed along with the 
libgphobos.so/.a
  libraries. GDC then reads this file to detect the required 
libraries,

  so the libraries are no longer hard coded in GDC. Note for
  distribution packagers: You must make sure to manually 
install this

  file if you do not use the standard make install command.


Sounds interesting for dmd as well.


You could also use DMD.conf or some nice, custom file format. We 
have to use the .spec format in GCC/GDC which is quite limited.

Re: New GDC binaries: 2.068.2, shared library support, multilib support & a new gdmd tool

[Johannes Pfau via Digitalmars-d-announce]

On Monday, 26 December 2016 at 16:43:51 UTC, brocolis wrote:
On Sunday, 25 December 2016 at 19:41:38 UTC, Johannes Pfau 
wrote:

Happy holidays everybody,

I'm happy to finally announce the release of new GDC binaries


Thank you for the hard work.
Any hope for the windows/mingw target?


I'll revive the mingw target at some point in time. But this 
requires changes in upstream druntime/phobos and as long as gdc 
and upstream are out of sync this requires some extra effort. So 
mingw support will have to wait till GDC is up to date again.


-- Johannes

Re: New GDC binaries: 2.068.2, shared library support, multilib support & a new gdmd tool

[Johannes Pfau via Digitalmars-d-announce]

Am Mon, 26 Dec 2016 16:26:55 +0200
schrieb Dicebot :

> On 12/25/2016 09:41 PM, Johannes Pfau wrote:
> > Happy holidays everybody,
> > 
> > I'm happy to finally announce the release of new GDC binaries at
> > https://gdcproject.org/downloads . GDC is the GNU D Compiler, a D
> > compiler using GCC as the compiler backend.  
> 
> A lot of great stuff! Got few questions when trying to update Arch
> Linux package though, could you please advice?
> 
> 1) There is `gdc_include_dir` variable now, what is intended way to
> override it to custom path? `gcc/configure
> gdc_include_dir=/usr/include/dlang/gdc` doesn't seem to work

IIRC it's not really meant to be customizable. You'll have to edit
libphobos/m4/druntime.m4. To regenerate the configure script you'll
then have to call ./setup-gcc.sh first, cd into the
gcc-x.y.z/libphobos directory and execute:

export AUTOCONF=/opt/autoconf/2.64/bin/autoconf
export ACLOCAL=/usr/bin/aclocal-1.11   
export AUTOM4TE=/opt/autoconf/2.64/bin/autom4te
export AUTOMAKE=/usr/bin/automake-1.11
/opt/autoconf/2.64/bin/autoreconf 


> 
> 2) As far as I can see phobos is now built as shared library by
> default. What flags affect it? I'd like to build either static one,
> or both at the same time if possible.
> 

The default configuration should build static and shared libraries. The
flags to enable/disable library types are
[--enable|--disable]-[shared|static]
 

-- Johannes

Re: New GDC binaries: 2.068.2, shared library support, multilib support & a new gdmd tool

[Johannes Pfau via Digitalmars-d-announce]

Am Mon, 26 Dec 2016 12:24:18 +
schrieb Russel Winder via Digitalmars-d-announce
:

> Has the problem of the Debian Sid GDC packages and LDC packages having
> conflicting file installs been sorted so that it is possible to have
> both installed and usable at the same time?

I think this has been fixed by the debian maintainers.

-- Johannes

New GDC binaries: 2.068.2, shared library support, multilib support & a new gdmd tool

[Johannes Pfau via Digitalmars-d-announce]

Happy holidays everybody,

I'm happy to finally announce the release of new GDC binaries at
https://gdcproject.org/downloads . GDC is the GNU D Compiler, a D
compiler using GCC as the compiler backend.

This release was delayed by massive internal changes in GDC in
preparation for the DDMD frontend and related regressions. We think GDC
is now sufficiently stable for a new release though. New features since
the last release include:

* D frontend updated to 2.068.2, the last C++ frontend version. We
  additionally include some backported changes (e.g. loading libcurl
  dynamically). Although this is of course still kind of outdated it
  should be a useful improvement compared to the last release (2.066.1).

* New GCC versions. The new binaries are based on these backend
  versions: 4.8.5, 4.9.4, 5.4.0, 6.3.0. We use new, customized build
  scripts for GCC to produce 40 different toolchains from 5
  configuration files.

* Multilib support: The new build scripts allow for building multilib
  compilers. This means there are now less compiler archives to choose
  from and one compiler can compile for different targets using -m
  flags. This includes the famous -m32/-m64 for x86 but we now also
  support -mfloat-abi=soft/softfp/hard for the ARM target.

* Shared library support: We added support for shared libraries to GDC
  and all toolchain binaries ship with static and shared libraries
  installed. GDC still defaults to static libraries so pass the
  -shared-libphobos flag to use the shared library instead.

* New mechanism to link system dependencies: All system libraries
  needed by phobos (-ldl, -lrt, -latomic) are detected in the
  phobos ./configure script. The required dependencies are added to a
  libgphobos.spec file and installed along with the libgphobos.so/.a
  libraries. GDC then reads this file to detect the required libraries,
  so the libraries are no longer hard coded in GDC. Note for
  distribution packagers: You must make sure to manually install this
  file if you do not use the standard make install command.

* New GDMD tool: We now ship a new gdmd binary which replaces the old
  perl script. It's written in D and up-to-date with the DMD 2.068.2
  interface. Compared to the old script gdmd now does not need any
  additional dependencies and supports more advanced DMD functions
  (e.g gdmd -main -run a.d --program-args).

Travis-CI should pick up the new release from now on. Packagers can use
the following git tags when creating packages: v2.068.2_gcc6
v2.068.2_gcc5 v2.068.2_gcc4.9 v2.068.2_gcc4.8


Regards,
Johannes

Re: Battle-plan for CTFE

[Johannes Pfau via Digitalmars-d-announce]

Am Tue, 30 Aug 2016 12:42:35 +0200
schrieb Johannes Pfau :

> @nogc is only meaningful at runtime. So this could work:
> 
> module foo;
> @nogc:
> [...]
> 
> string ctfeOnly(string name)
> {
> static assert(!__ctfe);

This should be
static assert(__ctfe);
of course.

Re: Battle-plan for CTFE

[Johannes Pfau via Digitalmars-d-announce]

Am Tue, 30 Aug 2016 08:35:20 +
schrieb Stefan Koch :

> I do not see how this could affect @nogc.

@nogc is only meaningful at runtime. So this could work:

module foo;
@nogc:
[...]

string ctfeOnly(string name)
{
static assert(!__ctfe);
// error: cannot use operator ~ in @nogc function
return "int " ~ name ~ ";";
}
mixin(ctfeOnly("foo"));

Re: Battle-plan for CTFE

[Johannes Pfau via Digitalmars-d-announce]

Am Tue, 30 Aug 2016 08:57:25 +0200
schrieb Jacob Carlborg :

> On 2016-08-29 10:39, Stefan Koch wrote:
> 
> > Thanks guys.
> >
> > I just came up with a nifty little patch that makes it possible to
> > ensure that a function is _only_ used at ctfe.
> > Or the opposite.
> >
> > static assert(__ctfe, "This function is not supposed to be called
> > outside of ctfe");
> > and static assert(!__ctfe, "This function is not supposed to be
> > called during ctfe");
> >
> > similarly you can use static if (__ctfe).
> >
> > Is it worth trying to get it into master ?  
> 
> Wow, absolutely :)
> 

There are some nice use cases for this:
* Do not enforce @nogc for CTFE only functions, so you can mark a
  complete module nogc: and CTFE only functions will get ignored
* Do not emit code for CTFE only functions. This is useful for bare
  metal programming: The CTFE only function can depend on druntime
  functions not available in the bare metal runtime.

These are common problems when using string mixins: The functions
to generate the mixed in code use string manipulation which is usually
not @nogc and might require runtime functions. But the code generation
function is exclusively used in CTFE.

Re: Vision document for H2 2016

[Johannes Pfau via Digitalmars-d-announce]

Am Thu, 7 Jul 2016 15:55:51 -0400
schrieb Andrei Alexandrescu :

> https://wiki.dlang.org/Vision/2016H2 -- Andrei


> Safety and Memory Management
 
Btw: You said #15951 (Inefficiencies in struct initialization) is a
blocker for RCStr. I've started some basic optimizations in GDC, but we
can't merge this code as long as the spec doesn't even mention = void
initialized fields.

Would be great if you and or Walter could take the time to add 3-4
sentences to the spec answering these questions
https://issues.dlang.org/show_bug.cgi?id=15951#c4

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: 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: d-vulkan, automatically generated D bindings for Vulkan

[Johannes Pfau via Digitalmars-d-announce]

Am Sat, 19 Mar 2016 01:12:08 +
schrieb Alex Parrill :

> https://github.com/ColonelThirtyTwo/dvulkan
> [...]
> 
> (Currently the Derelict loader only works in Windows because I 
> don't know the library names for Vulkan on Linux or OSX; if 
> anyone knows them, please tell me, and I'll add them)

For Archlinux:

usr/lib/libvulkan.so
usr/lib/libvulkan.so.1
usr/lib/libvulkan.so.1.0.5

(see https://www.archlinux.org/packages/extra/x86_64/vulkan-icd-loader/
and maybe https://www.archlinux.org/packages/extra/x86_64/vulkan-intel/
and click on "View the file list" on the bottom of the page)

Re: Argon: an alternative parser for command-line arguments

[Johannes Pfau via Digitalmars-d-announce]

Am Thu, 03 Mar 2016 09:09:38 +
schrieb Markus Laker :

> * It can open files specified at the command line.  It can do a 
> simplified version of what cat(1) does and many Perl programs so, 
> and open a file specified by the user or fall back to reading 
> from stdin.  There's also a convention that the user can type "-" 
> to mean stdin or stdout, depending on the open-mode you specify.

The rest of this list sounds quite good, but please reconsider
automatically opening files:
https://media.ccc.de/v/32c3-7130-the_perl_jam_2

I guess the scenario can't happen in D as our open file methods won't
execute programs (!) but still

Re: Writing a scalable chat room service in D

[Johannes Pfau via Digitalmars-d-announce]

Am Mon, 04 Jan 2016 17:15:36 +
schrieb Bubbasaur :

> On Monday, 4 January 2016 at 17:02:01 UTC, Sönke Ludwig wrote:
> > ...Maybe it's something specific to your OS/Chrome version?  
> 
> Well, I tried again on the same machine but using Firefox and it 
> worked, then I tried on my Tablet (Android/KitKat) using both 
> Chrome and Native Browser and worked too.
> 
> So I think It's something going wrong with Chrome here!
> 
> Bubba.

IIRC the letsencrypt people said in their 32c3 talk* that there might
still be some issues with chrome. (chrome is probably caching something
it shouldn't cache. Try clearing all caches)

[*]
https://media.ccc.de/v/32c3-7528-let_s_encrypt_--_what_launching_a_free_ca_looks_like

Re: Beta D 2.069.0-b1

[Johannes Pfau via Digitalmars-d-announce]

Am Sun, 11 Oct 2015 01:54:39 +
schrieb deadalnix :

> On Saturday, 10 October 2015 at 02:57:03 UTC, Meta wrote:
> > On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak 
> > wrote:
> >> That's what I meant, weird use-case, at best it's a callback 
> >> better/setter.
> >> I've never written such code, but even if you would, the 2 
> >> pairs of parens are only a tiny problem for generic code, 
> >> nothing to warrant the invasive language feature @property is.
> >
> > I don't know how much metaprogramming-heavy generic code you've 
> > written, but I can say from first-hand experience that there is 
> > such a thing as Hell, and it is called Optional Parens.
> >
> > Jokes aside, I've finally fixed (read: worked around using 
> > awful hacks) a bug where the compiler was complaining about 
> > either "Type.memberFunction is not callable with arguments ()" 
> > or "Need 'this' for Type.memberFunction". I love optional 
> > parens in regular code, especially range-based code (doesn't 
> > everybody?), but I desperately want a way to ensure that the 
> > symbol that I'm trying to pass to a template function won't be 
> > interpreted as a function call instead.
> 
> To the next person that is going to say this is overblown, I ran 
> into such bugs more than once in phobos.
> 
> So, unless we expect most D developer to be better than phobos 
> contributor, that is a problem.
> 

We even have such a problem in object.d:

https://github.com/D-Programming-Language/druntime/blob/master/src/object.d#L1461

I remember somebody asking in D.learn why his custom test runner did
not work. Problem was related to wrong parenthesis: The user wrote
mod.unitTest() instead of mod.unitTest()() IIRC. Unfortunately I can't
find the exact link right now.

Re: Go 1.5

[Johannes Pfau via Digitalmars-d-announce]

Am Mon, 21 Sep 2015 19:32:21 +
schrieb Ola Fosheim Grøstad :

> On Monday, 21 September 2015 at 18:28:19 UTC, jmh530 wrote:
> > My understanding is that the key benefit of Rust's system is 
> > that compile time checks don't have the runtime costs of smart 
> > pointers.
> 
> + aliasing information.
> 
> If the compiler can prove that two pointers point to 
> non-overlapping memory regions then the compiler can optimize 
> better. This is one of the reasons why Fortran compilers managed 
> to do better than C for a long time.
> 

Unfortunately we have even weaker optimizations than C regarding
aliasing information. There's code in druntime and phobos which breaks C
aliasing rules (usually pointer type casts) and this caused real issues
on ARM systems with GDC. As the D spec doesn't state anything about
aliasing we simply disable strict aliasing rules. I guess there's also
lots of D user code which isn't compatible with strict aliasing rules.

Re: D-Day for DMD is today!

[Johannes Pfau via Digitalmars-d-announce]

Am Fri, 28 Aug 2015 11:21:52 +1000
schrieb Daniel Murphy yebbliesnos...@gmail.com:

 Bruno Medeiros  wrote in message
 news:mrn30f$26ff$2...@digitalmars.com...
 
  Cool stuff!
 
 Yeah!
 
  What's the plan going forward, for those not so much up to date
  with what's going on? Is the next major release of DMD gonna be
  D-DMD based then? Which compiler is going to be used to compile
  D-DMD?
 
 The next major release (2.069) will use the D-based frontend.  We're 
 planning to use GDC and/or LDC releases based on the 2.067 frontend
 to compile DMD on most platforms. 
 

Current GDC master can compile DDMD, although it uses the 2.066.1
frontend. Iain backported the relevant C++ mangle changes:

https://github.com/D-Programming-Language/dmd/pull/4957

Re: Programming in D paper book is available for purchase

[Johannes Pfau via Digitalmars-d-announce]

Am Thu, 20 Aug 2015 10:09:53 -0700
schrieb Ali Çehreli acehr...@yahoo.com:

 On 08/20/2015 07:02 AM, Johannes Pfau wrote:
 
   BTW: For everybody searching on amazon.de: Use the full title
   Programming in D: Tutorial and Reference. If you only search for
   Programming in D it's not on the first few result pages...
 
 Thanks for the tip. I think Amazon's search engine is slowly learning 
 and perhaps the European site is a little behind.
 
 Just Programming in D with quotes were sufficient to find on the US 
 site right away. Today, it is on the first search page even when 
 searched without the quotes (still at the bottom though). (Of course, 
 the results may be customized for the logged in user; I don't know.)
 
 Ali
 

Programming in D with quotes seems to work on the german amazon.de
page as well. I first searched without quotes and erroneously assumed
it's not available from amazon.de. I guess this might improve once
enough copies have been sold, but this of course takes some more time on
the german amazon page ;-)

Re: Programming in D paper book is available for purchase

[Johannes Pfau via Digitalmars-d-announce]

Am Tue, 18 Aug 2015 17:57:31 -0700
schrieb Ali Çehreli acehr...@yahoo.com:

 I am very happy! :)
 
 It will be available on many other distribution channels like Amazon
 in a few days as well but the following is the link that pays me the
 most royalty:
 
https://www.createspace.com/5618128
 
 This revision has many corrections and improvements over the one on
 the web site, which was from December 2014. (Thank you, Luís Marques!)
 
 I am too excited to list the changes right now but I can say that it
 is up to date with 2.068. :D
 
 eBook formats will follow but here are two almost-production-ready 
 versions, which, hopefully apparent from their names, will disappear
 soon:
 
http://ddili.org/deleteme.epub
 
http://ddili.org/deleteme.azw3
 
 And the book will always be freely available as well but I haven't 
 updated the web site yet.
 
 Enjoy, and go buy some books! ;)
 
 Ali

Awesome!

BTW: For everybody searching on amazon.de: Use the full title
Programming in D: Tutorial and Reference. If you only search for
Programming in D it's not on the first few result pages...

Re: dfuse 0.3.0 - D Language bindings for Fuse

[Johannes Pfau via Digitalmars-d-announce]

Am Wed, 30 Jul 2014 17:05:20 +
schrieb David Soria Parra davi...@fb.com:

 Hi,
 
 We are happy to announce the release of 'dfuse', a high level D 
 language binding
 for fuse (http://fuse.sourceforge.net). It supports libfuse = 
 2.8 and works on
 both Linux and MacOS (osxfuse). You can find the project at:
 
  https://github.com/facebook/dfuse
 
 We at Facebook have been working on dfuse for the last weeks and 
 are actively
 using it in production. While the interface is still limited, we 
 hope to work
 towards a full featured fuse binding.
 
 If you want to get involved, feel free to sent pull requests, 
 submit issues and
 direct any questions about dfuse to the D mailinglist or ping 
 'dsop' on IRC.
 
 - David Soria Parra

Awesome!

Will this be added to code.dlang.org?
There's a question on reddit regarding performance. I'd guess
performance should be quite good in general, but the simple example
throws/allocates* Exceptions on missing files. Does this perform well
enough?

* I guess in this case you could 'cache' the exception in a
  global variable, but druntime still allocates the stack trace (only
  once though). Druntime uses some tricks to avoid these allocations
  for OutOfMemory errors and this trick should probably work for dfuse
  as well, but I still wonder if it isn't easier to simply return a
  result code from getattr and readdir. 

Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw

[Johannes Pfau via Digitalmars-d-announce]

Am Tue, 15 Jul 2014 11:59:42 +1000
schrieb Manu via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com:

 On 15 July 2014 00:32, Johannes Pfau via Digitalmars-d-announce 
 digitalmars-d-announce@puremagic.com wrote:
 
  Am Tue, 15 Jul 2014 00:15:01 +1000
  schrieb Manu via Digitalmars-d-announce
  digitalmars-d-announce@puremagic.com:
 
   I don't see that GDC/GDB will ever be useful in the Windows
   environment due to incompatible object and debug formats, but LLVM
   are making the push for full MSVC compatibility.
 
  Can you provide some more details about this? MinGW uses the
  standard PE object format, afaik. GCC-4.9 also supports SEH
  exceptions (on 64 bit, not sure about 32). The mingw 'runtime' is a
  small layer on top of the microsoft runtime, to provide C99
  functions and similar stuff. I don't think that should be a problem.
 
 
 http://clang.llvm.org/docs/MSVCCompatibility.html
 
 They emit line numbers so far apparently. But I understand the intent
 is to properly populate the object with cv8 debug data.
 The linker takes care of generating the pdb file.
 
 So, are you saying that GDC binaries will link successfully against
 the mscrt suite?
 I've used it in the past, and it never wanted to link against the ms
 libs. In addition, when I did try and link C and D code together, I
 got loads of CRT conflicts when trying to link glibc and mscrt
 together.

There's no glibc on windows, mingw links to msvcrt.dll. I think MS
toolchains link to msvcr110.dll, but it's also possible to make mingw
link against msvcr110.dll.
I didn't try to link mingw/msvc object files yet, but according to some
mingw discussions it should work. C DLLs should always work.

(That's only for C, C++ mingw/msvc are not compatible).

 
 I believe the goal for LLVM is to target the same runtime as MSC does,
 otherwise you're just asking for link trouble.
 
 The pdb debug format is not supported, AFAIK. But that format is not
  documented and I don't think you could add D extensions anyway.
  So does LLVM really support PDB?
 
 
 The linker outputs the pdb file, the objects are populated with cv8.
 Can GCC write cv8 output?
 

No it can't. cv2pdb claims to support converting from dwarf-pdb 
but I never tried that.

 MinGW can use dwarf debug info on windows and I guess you get all
  benefits of Iain's gdb work on windows. It is annoying if you get
  crashes in the microsoft C runtime or any other library compiled
  with microsoft tools though, as there's no dwarf debug info for
  these.
 
 
 I have had problems with the linker when trying to link GDC and MSC
 objects together.
 You lose the debug info for one or the other world. You can't have
 dwarf and cv8/pdb together.
 And to be useful, there would need to be some visual studio
 integration for dwarf debugging :/
 
 So overall I don't see why mingw should work fine on windows. Of
  course there's less incentive for GCC devs to support windows, but I
  doubt that's different for LLVM.
 
 
 I think there would be plenty of incentive if it worked.
 I haven't tried it out for a while. I'll give it a whirl and see
 what's changed, but while the dwarf/cv8 conflict remains, I can't see
 it being a practical solution.

I guess getting dwarf and cv8 to work together is almost impossible.
 
 There's also nobody working actively on the MinGW gdc port right now,
  afaik. We don't even know the test suite results for mingw. So if
  you want to contribute...
 
 
 This has indeed been my biggest issue with GDC in the past.
 

Re: DConf 2014 Day 2 Talk 7: Tiny, Ubiquitous Machines Powered by D by Michael D. Franklin

[Johannes Pfau via Digitalmars-d-announce]

Am Mon, 14 Jul 2014 11:17:26 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:

 http://www.reddit.com/r/programming/comments/2aoqov/dconf_2014_day_2_talk_7_tiny_ubiquitous_machines/
 
 https://www.facebook.com/dlang.org/posts/884725944874421
 
 https://twitter.com/D_Programming/status/488748669869780992
 
 
 Andrei

Nice talk!
I hope we'll see D on quadrocopters and similar devices soon ;-)

There are actually some cheap (15-30€) quadrocopters on ebay with a
reprogrammable Cortex M0:

http://www.mikrocontroller.net/topic/309185 (german)
http://www.mikrocontroller.net/articles/Hack-O-Copter (german)
http://www.rcgroups.com/forums/showthread.php?t=2174365
https://github.com/hackocopter (OSS firmware)

Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw

[Johannes Pfau via Digitalmars-d-announce]

Am Tue, 15 Jul 2014 00:15:01 +1000
schrieb Manu via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com:

 I don't see that GDC/GDB will ever be useful in the Windows
 environment due to incompatible object and debug formats, but LLVM
 are making the push for full MSVC compatibility. 

Can you provide some more details about this? MinGW uses the standard
PE object format, afaik. GCC-4.9 also supports SEH exceptions (on 64
bit, not sure about 32). The mingw 'runtime' is a small layer on top of
the microsoft runtime, to provide C99 functions and similar stuff. I
don't think that should be a problem.

The pdb debug format is not supported, AFAIK. But that format is not
documented and I don't think you could add D extensions anyway.
So does LLVM really support PDB?

MinGW can use dwarf debug info on windows and I guess you get all
benefits of Iain's gdb work on windows. It is annoying if you get
crashes in the microsoft C runtime or any other library compiled with
microsoft tools though, as there's no dwarf debug info for these.

So overall I don't see why mingw should work fine on windows. Of
course there's less incentive for GCC devs to support windows, but I
doubt that's different for LLVM.

There's also nobody working actively on the MinGW gdc port right now,
afaik. We don't even know the test suite results for mingw. So if you
want to contribute...

Re: GDC binaries updated

[Johannes Pfau via Digitalmars-d-announce]

Am Wed, 07 May 2014 14:38:32 +0100
schrieb Bruno Medeiros bruno.do.medeiros+...@gmail.com:

 On 04/05/2014 10:38, Johannes Pfau wrote:
  We've just uploaded new binary releases to
  http://gdcproject.org/downloads/
 
  ## GDC changes ##
 
  As we merged the first parts of Daniel Greens MinGW changes
  back into GDC we now also provide initial (automated) MinGW builds.
  These builds are mostly unsupported and will likely have many more
  bugs than the older releases posted by Daniel so don't expect too
  much.
 
 
 Glad to hear there is some progress here, but are there plans to make 
 this supported in the future?
 
 Also, what is the difference between Daniel Green's build, and the 
 native Standard Builds?
 
 

Daniels builds apply some more patches, see
https://github.com/venix1/MinGW-GDC for details.
The builds on gdcproject.org use the standard git sources of gdc which
only include the subset of these patches that's necessary to compile 
run a hello world program.

GDC binaries updated

[Johannes Pfau via Digitalmars-d-announce]

We've just uploaded new binary releases to
http://gdcproject.org/downloads/

## GDC changes ##

As we merged the first parts of Daniel Greens MinGW changes
back into GDC we now also provide initial (automated) MinGW builds.
These builds are mostly unsupported and will likely have many more bugs
than the older releases posted by Daniel so don't expect too much.

Other changes:
* Fixed gcc.attribute
* Added support for target attributes (import gcc.attribute;
  @attribute(naked))  http://wiki.dlang.org/GDC/Using_GDC#Attributes

See https://github.com/D-Programming-GDC/GDC/commits/master for more
details

## Toolchain changes ##
* Changed file permissions of toolchains to read/write
* Added READMEs to all toolchains
* Toolchain binaries ($TARGET-gdc) now show the build date,
  DMDFE version, and gdc git revision in --version output

## ARM changes ##
The arm native compilers should now run on older ARMv5 processors as
well. (Generated D code already worked on these processors, but the gdc
compiler did not run correctly on these systems)



There's also a new guide on the wiki showing how the filesystem of a
real machine can be used by cross-compilers. This way the
cross-compilers have access to all libraries installed on the machine.
http://wiki.dlang.org/GDC/Cross_Compiler/Existing_Sysroot#Sysroot_over_SSH