Re: Terminix Stable 1.2.0 Released

[Matthias Klumpp via Digitalmars-d-announce]

On Saturday, 23 July 2016 at 17:00:45 UTC, Iain Buclaw wrote:
On 23 July 2016 at 16:24, Matthias Klumpp via 
Digitalmars-d-announce  
wrote:


3) Making LDC available for more architectures, or making GDC 
support a
higher version of the Phobos standard library and build shared 
libraries.
At time, LDC is the better fit because of shared library 
support and higher
Phobos version. Current D projects are hard to compile with 
GDC because of

the latter reason.
More architectures are not per-se essential, but would be 
awesome to have.
This feature request summarizes the status of arch support for 
D in free

compilers: https://github.com/ldc-developers/ldc/issues/1636



Well, as GDC is supporting the last C++ release, the only next 
logical step would be to get bootstrapping from 2.068 to 2.071 
or whatever version of the frontend has sufficiently ironed out 
all compatibility regressions.


I would love to use GDC for Debian, but a compiler is really 
useless if it doesn't compile 90% of the interesting D projects 
out there...

LDC however, can do that.

This means that backporting compiler fixes and the standard 
library from upstream is acceptably on the cards.  It's just 
that the feature-set will remain the same as 2.068.


API/ABI breaks in Phobos are really, really annoying - but GDC 
having an ancient Phobos version is even more annoying, since 
this basically ties us to using LDC.
GDC doesn't compile the majority of D projects ot there, and for 
my own I need to explicitly add support for it, e.g. by 
backporting standard library bits and shipping them with the 
source code.




5) Have hardening supported for the D compilers: 
https://wiki.debian.org/HardeningWalkthrough




As per the wiki, if you use GDC then there's nothing for you to 
do.


Since the normal toolchain of Linux distributions is GCC based 
and GCC has a pretty good backend with all the features we need, 
using GDC would be a good choice.
But LDCs shared-library support is a pretty big deal for distros, 
and together with the fact that GDC doesn't compile most of the 
interesting new projects, LDC is the way to go.


Furthermore, since GDC is out-of-tree, some distributions like 
Fedora don't have it / can't easily add it.


I would love to see this resolved - is this a manpower problem? 
Or are there other blockers?

Re: Codebuilder with line info insertion

[Jesse Phillips via Digitalmars-d-announce]

On Sunday, 24 July 2016 at 19:36:50 UTC, Dicebot wrote:
How much of compile-time overhead does it add compared to naive 
string concatenation?


I would expect fairly large, It only increases the amount of 
memory used and concatenation operations. It stores each 
requested string into array of structures, that later are used 
for concatenating together.


I don't have any performance numbers, nor do I have a large 
amount of code generation to try and tax compile-time work. I ran 
ProtocolBuffer with -profile and it should the call to 
finalize(), ~9000 microseconds per call (runtime).


I'd be happy to accept performance improvements (including 
breaking changes), but if you've already got long compile times 
due to CTFE I can't recommend using it.

Re: Codebuilder with line info insertion

[Dicebot via Digitalmars-d-announce]

How much of compile-time overhead does it add compared to naive 
string concatenation?

Re: Codebuilder with line info insertion

[Jesse Phillips via Digitalmars-d-announce]

On Tuesday, 10 May 2016 at 15:42:00 UTC, Jesse Phillips wrote:


1. http://code.dlang.org/packages/protocolbuffer
2. http://code.dlang.org/packages/codebuilder
3. 
https://github.com/JesseKPhillips/ProtocolBuffer/blob/master/conversion/dlang.d


I wish to announce version 1.0.0 of CodeBuilder. As the code 
originally came from ProtocolBuffer I've now eat some dog food by 
utilizing the library within ProtocolBuffer. I've also put in 
unittests and a readme.


The Dub package provides two configurations, one for mixins and 
one as a file writer. When using the file writer it is of no 
interest to modify the line numbers as you'll actually have a D 
source file to look at.


http://code.dlang.org/packages/codebuilder

Change Highlights

* Reduced complexity. Originally I was trying to store generated 
code in to many different places, There was the current state, 
the stack that held items which would later be popped into the 
current state, a build so code could be structured before putting 
it on the stack, and the current state could be returned by 
asking for it's memory. All that goes away and instead another 
CodeBuilder can be put or pushed into another.


* The string used for indentation can be specified (but is global 
for all code builders.


* The code string isn't created while putting the string into the 
builder. Instead it is stored as an operation that is used to 
generate the string when calling finalize(). This makes 
indentation consistent when putting one CodeBuilder into another.


I'd also like to note that Google's Protocol Buffer source has a 
similar need, but I like my API better :)



https://github.com/google/protobuf/blob/master/src/google/protobuf/io/printer.cc

https://github.com/google/protobuf/blob/master/src/google/protobuf/compiler/cpp/cpp_file.cc

Re: D-Man culture

[simd via Digitalmars-d-announce]

On Thursday, 21 July 2016 at 07:16:53 UTC, Ali Çehreli wrote:

On 07/20/2016 11:24 PM, Ali Çehreli wrote:

On 06/20/2016 07:14 AM, Martin Tschierschke wrote:


I found this link useful: http://dlangcomicstrips.tumblr.com/



D-Man sticks back! (D-Man stickers.)

   https://store.line.me/stickershop/product/1299646

Ali



Can you make a better ASCII D-Man drawing.

o   o
|\
 \ ___   /
  |,-oo\\
  ||||
  ||||
  ||   //
  ||__//
  '---
   \  \
   /  /
   ^  ^

Ali


I made D-man ASCII Art last year.

https://gist.github.com/simdnyan/20e8fa2a2736c315e2c1

  _   _
 (_) (_)
/__ \
\\(O(O \/
 | | | |
 | |_| |
/__/
  <   >
 (_) (_)


You may also like dl-command (like sl joke command) by ueshita.
https://github.com/ueshita/dl-cmd
https://twitter.com/ueshita/status/675510743769288704