Re: Hello, folks! Newbie to D, have some questions!

[Steve Biedermann via Digitalmars-d-learn]

On Tuesday, 21 February 2017 at 17:13:30 UTC, timmyjose wrote:
I would upvote you if I could! :-) ... that's not only an 
interesting read, but also fodder for mini-projects of my own!


If you need more details about a specific topic, just post it in 
the forum and we will try to help :)


If you want some sourcecode to look at you can write me a mail 
and I can give you access to some of my tools. The ones which are 
stored on bitbucket are pretty simple to understand, but not 
quite ready for public release (no polishing etc.).

Re: FEM library?

[Nicholas Wilson via Digitalmars-d-learn]

On Wednesday, 22 February 2017 at 00:51:46 UTC, XavierAP wrote:
Is there any D library for FEM (Finite Element Method, see 
Wikipedia) solving, meshing, etc... already existing somewhere?


I'm asking because I'm considering making something in that 
field as a personal learning project. Depending on what can be 
found I can jump at some point to use a serious enough library 
or contribute to it...


Not that I'm aware of. A good starting point for the linear 
algebra is

Mir's ndslice[0] and DlangScience's scid[1] for the calculus. scid
has some other things that may be of use. I'm sure that the
DlangScience people would be interested in this and would be
willing to help out with anything.

Good luck!

[0]: https://github.com/libmir mir, mir-glas,mir-algorithm
[1]: https://github.com/DlangScience/scid

Re: Threads not garbage collected ?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, February 22, 2017 05:28:17 Alex via Digitalmars-d wrote:
> import core.thread;
>
> class A
> {
>   Thread mThread;
>   bool mStopped;
>
>   this()
>   {
>   mThread = new Thread();
>   mThread.start();
>   }
>
>   void run()
>   {
>   while (!mStopped)
>   {
>   //do stuff
>   }
>   }
>   ~this()
>   {
>   mStopped = true;
>   mThread.join();
>   }
> }
>
>
>
> void main()
> {
>   auto a = new A;
>   delete a;   //need this or the program hangs
> }
>
> In both gdc and dmd I need to use manually delete this object or
> the program is blocked after main. Is by design ?
> It seems undesirable, as the thread can be many layers of
> encapsulation down, and they all need manual deletes.

There's never a guarantee that an object is going to be collected. The
program is free to not bother to collect any GC-allocated objects when it
exits. Normally, the GC only attempts to collect objects and free memory
when you call new, because that's when it needs more memory.

And because you put the join in a class finalizer, the thread won't be
joined unless the GC happens to decide to collect that class - which it will
never do, because new isn't being called, and the open thread keeps the
program running.

If you want deterministic or guaranteed destruction, you should use a
struct on the stack, not a class. In general, managing resources in a class
finalizer is just begging for them to never be released, and it should
really only be done as a backup for when the resources aren't explicitly
freed by the programmer.

In this particular case, the program would probably exit if you did

void main()
{
{
auto a = new A;
}

import core.memory;
GC.collect();
}

but really, relying on a class' finalizer to be called in order to join a
thread is begging for trouble.

- Jonathan M Davis

Re: Threads not garbage collected ?

[rikki cattermole via Digitalmars-d]

On 22/02/2017 6:28 PM, Alex wrote:

import core.thread;

class A
{
Thread mThread;
bool mStopped;

this()
{
mThread = new Thread();
mThread.start();
}

void run()
{
while (!mStopped)
{
//do stuff
}
}
~this()
{
mStopped = true;
mThread.join();
}
}



void main()
{
auto a = new A;
delete a;//need this or the program hangs
}

In both gdc and dmd I need to use manually delete this object or the
program is blocked after main. Is by design ?
It seems undesirable, as the thread can be many layers of encapsulation
down, and they all need manual deletes.


Well, you never told the program to stop without delete.

The thread that you start with (calls the main function) doesn't 
actually have to stay alive throughout the program running, surprise!


Anyway, if you do want something that will stop try:

import core.thread;
import core.time;
import std.stdio;

class Foo : Thread {
bool keepRunning;

this() {
keepRunning = true;
super();
}

private void run() {
while(keepRunning) {
sleep(1.seconds);
writeln("iterate");
}
}
}

void main() {
Foo foo = new Foo;
foo.start;

Thread.sleep(3.seconds);
foo.keepRunning = false;
}

Re: Threads not garbage collected ?

[Jerry via Digitalmars-d]

Not really by design so much as you can't really guarantee 
destruction because it is garbage collected. You can use a struct 
instead or scoped 
(https://dlang.org/library/std/typecons/scoped.html).

Threads not garbage collected ?

[Alex via Digitalmars-d]

import core.thread;

class A
{
Thread mThread;
bool mStopped;

this()
{
mThread = new Thread();
mThread.start();
}

void run()
{
while (!mStopped)
{
//do stuff
}
}
~this()
{
mStopped = true;
mThread.join();
}
}



void main()
{
auto a = new A;
delete a;   //need this or the program hangs
}

In both gdc and dmd I need to use manually delete this object or 
the program is blocked after main. Is by design ?
It seems undesirable, as the thread can be many layers of 
encapsulation down, and they all need manual deletes.

Re: How do I use CTFE to generate an immutable associative array at compile time?

[Era Scarecrow via Digitalmars-d-learn]

On Tuesday, 21 February 2017 at 22:34:57 UTC, Chad Joan wrote:
In this case the AA isn't actually coded into the executable; 
but at least the configuration from some_data.csv will be in 
the executable as a string.  The program will construct the AA 
at startup.  It's not as "cool", but it should get the job done.


 I have a partial static AA implementation that seems like it 
works, I mentioned this in a different thread.


https://github.com/rtcvb32/Side-Projects/blob/master/staticaa.d

Try it out, etc.

Usage:
Create your AA as an enum (for simplicity)

StaticAA!(KeyType, ValueType, getAALen(EnumAssosiativeArray), 
EnumAssosiativeArray.length)(EnumAssosiativeArray);


Afterwards use it as you normally would for the same thing.

Unittest example:

enum AA = ["one":1, "two":2, "three":3, "four":4, "five":5, 
"six":6, "seven":7, "eight":8, "nine":9, "zero":0];

auto SAA = StaticAA!(string, int, getAALen(AA), AA.length)(AA);

  //just verifies the keys/values match.
  foreach(k, v; AA) {
assert(SAA[k] == v);
  }


Note: getAALen basically tests the array expanding it out until 
none of the hashes overlap or causes problems. Trying to compile 
these into a single call I've had issues, so if anyone has a 
better solution I'd go for it.

[Issue 17215] ICE(cgcod.c:findreg) with SIMD and -O -inline

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17215

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
This is working for me on Windows 64. It's listed as "All" platforms. Which is
it failing on?

--

[Issue 17049] [scope] class references are not escape checked like pointers

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17049

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |INVALID

--- Comment #2 from Walter Bright  ---
The reason no error is detected is because there isn't one. The declaration:

   S s;

does not declare a pointer that points to the stack.

--

[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5813

j...@red.email.ne.jp changed:

   What|Removed |Added

 CC||j...@red.email.ne.jp

--- Comment #23 from j...@red.email.ne.jp ---
Summary: This is rather a DMD issue because the LDC's optimizer makes no
performance change.
OK?

--

Re: Hello, folks! Newbie to D, have some questions!

[timmyjose via Digitalmars-d-learn]

On Tuesday, 21 February 2017 at 19:55:37 UTC, Ali Çehreli wrote:

On 02/21/2017 09:13 AM, timmyjose wrote:
On Tuesday, 21 February 2017 at 14:17:39 UTC, Steve Biedermann 
wrote:
On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose 
wrote:

[...]


I'm using D for small tools for about a year now and I never 
had to
mess with GC. Most of the tools don't need to work on GBs of 
data and

performance has always been good enough.

[...]


I would upvote you if I could! :-) ... that's not only an 
interesting

read, but also fodder for mini-projects of my own!


Making sure that you've seen the link that sarn had posted 
earlier in this thread:


> https://forum.dlang.org/thread/o6c9tj$2bdp$1...@digitalmars.com
> (Silicon Valley D Meetup - January 26, 2017 - "High
Performance Tools in D" by Jon Degenhardt)

Jon Degenhardt has been writing multiple times faster running 
tools just by (almost) casual D coding. (Hopefully he will 
write a blog post about his experiences soon.)


Ali


I had a chance to get around to watching the video at last. Very 
interesting, and grand job on the interview. Things like these 
will definitely help increase the community. More and more people 
should start creating content (no matter how small or big), and 
that will pique people's curiosity! :-)

Re: Enough D to Make a Living?

[Chris Wright via Digitalmars-d]

On Tue, 21 Feb 2017 15:34:02 +, Paul wrote:
> I'm in between engineering jobs and exploring the idea of getting into
> programming for a living...specifically D.
> 1) Is there enough D demand for someone to make a living (bread and
> water :} ) at it?

There's enough for someone to do so, and maybe enough for several hundred 
to do it in the whole world. Sorry to say your odds aren't that great.

> 2) I've programmed industrial automation controllers using graphical and
> text-based languages and wrote a few small command line tools in D for
> myself. How long would it take to become "employable"?

If you start your own business, you're immediately employable.

If you go for portfolio-oriented work, then you will be employable once 
you've done something noteworthy in your field.

> 3) Is there much value in taking programming classes that don't deal
> with D?

You will want to learn SQL.

You need to learn the concepts behind asymptotic complexity, at least 
enough to recognize when you've got asymptotic complexity problems.

You need familiarity with common data structures.

If you are working in a particular field and there is a class on that, it 
is worthwhile. For instance, if you are doing computer vision, machine 
learning, or natural language processing, you will benefit from studying 
that specifically, regardless of what language you use.

You need practice programming to be effective, and that practice will 
largely be transferrable from other languages to D.

[Issue 17115] [404 Not Found] std.concurrencybase

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17115

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
pull: https://github.com/dlang/dlang.org/pull/1579

--

Re: How do I use CTFE to generate an immutable associative array at compile time?

[H. S. Teoh via Digitalmars-d-learn]

On Wed, Feb 22, 2017 at 12:38:47AM +, Chad Joan via Digitalmars-d-learn 
wrote:
[...]

Hmm. It's actually not necessary to manually write a foreach loop to
convert an array to an AA. We could, instead, change parseTwoColumnCsv()
to return an array of std.typecons.Tuple instead (which, incidentally,
means you can elide that foreach loop too!), then there's this handy
function std.array.assocArray that will do the transcription for us,
as follows.

(In fact, you can merge AA's without ever needing to write `foreach` at
all! See below.)

---
pure private auto parseTwoColumnCsv(string inputCsv)
{
import std.csv;
import std.typecons;
return csvReader!(Tuple!(string,string))(inputCsv);
}

immutable string[string] dataLookup;
immutable string[string] dataLookup1;
immutable string[string] dataLookup2;

static this()
{
import std.array : assocArray;
import std.range : chain;

// Force CTFE
immutable tuples1 = parseTwoColumnCsv("some_data1.csv");
immutable tuples2 = parseTwoColumnCsv("some_data2.csv");

dataLookup1 = tuples1.assocArray;   // Bam! :-P
dataLookup2 = tuples2.assocArray;   // Bam! :-P

// Bam, bam! - merge AA's in a single step!
dataLookup3 = chain(tuples1, tuples2).assocArray;
}
---


T

-- 
You have to expect the unexpected. -- RL

Re: Vibe.d: Listening to port 8080 on external device doesn't work

[krzaq via Digitalmars-d-learn]

On Wednesday, 22 February 2017 at 00:38:30 UTC, aberba wrote:
Using vibe.d, I bind to port 8080 at 127.0.0.1 but I can't 
access server on my phone through hotspot using the external IP 
from ip addr on Linux. But 127.0.0 running Apache server works.


Don't if its vibe.d or OS (ubuntu 14.04)

How do I reached my vibe.d server in this case on my phone?


Listen on "0.0.0.0".

FEM library?

[XavierAP via Digitalmars-d-learn]

Is there any D library for FEM (Finite Element Method, see 
Wikipedia) solving, meshing, etc... already existing somewhere?


I'm asking because I'm considering making something in that field 
as a personal learning project. Depending on what can be found I 
can jump at some point to use a serious enough library or 
contribute to it...

Re: How do I use CTFE to generate an immutable associative array at compile time?

[Chad Joan via Digitalmars-d-learn]

On Tuesday, 21 February 2017 at 23:30:52 UTC, Chad Joan wrote:

On Tuesday, 21 February 2017 at 22:43:15 UTC, H. S. Teoh wrote:


Parsing strings at program startup is ugly and slow.  What 
about parsing at compile-time with CTFE into an array literal 
and transforming that into an AA at startup, which should be a 
lot faster?


// Warning: untested code
pure string[2][] parseTwoColumnCsv(string inputCsv)
{
import std.csv;
import std.typecons;

string[2][] result;
		foreach (record; 
csvReader!(Tuple!(string,string))(inputCsv)) {

result ~= [record[0], record[1]];
}
return result;
}

immutable string[string] dataLookup;
static this()
{
		enum halfCookedData = 
parseTwoColumnCsv(import("some_data.csv"));

foreach (p; halfCookedData) {
dataLookup[p[0]] = p[1];
}
}


T


Hi,

That makes a lot of sense and it had crossed my mind.

In my case the data sets are super small, so I'm probably going 
to be lazy/productive and leave it the way it is.


Anyone else from the internet copying these examples: try to 
just do it H.S. Teoh's way from the start ;)


Thanks for the suggestion.
- Chad


OK I couldn't help it:

---
pure private string[][] parseTwoColumnCsv(string inputCsv)
{
import std.csv;
import std.typecons;

string[][] result;

foreach ( record; csvReader!(Tuple!(string,string))(inputCsv) )
result ~= [record[0],record[1]];

return result;
}

pure private string[string] twoColumnArrayToAA(const string[][] 
arr)

{
string[string] result;
foreach ( pair; arr )
result[pair[0]] = pair[1];
return result;
}

pure private string[string] importTwoColumnCsv(string csvFile)()
{
// Force the parse to happen at compile time.
	immutable string[][] tempArray = 
import(csvFile).parseTwoColumnCsv();


	// Convert the parsed array into a runtime Associative Array and 
return it.

return tempArray.twoColumnArrayToAA();
}

immutable string[string] dataLookup;
immutable string[string] dataLookup1;
immutable string[string] dataLookup2;

static this()
{
import std.range;
dataLookup1 = importTwoColumnCsv!"some_data1.csv";
dataLookup2 = importTwoColumnCsv!"some_data2.csv";
	foreach( pair; chain(dataLookup1.byKeyValue, 
dataLookup2.byKeyValue) )

dataLookup[pair.key] = pair.value;
}

void main()
{
import std.stdio;
writefln("dataLookup = %s", dataLookup);
}
---

This example also shows joining associative arrays.

Vibe.d: Listening to port 8080 on external device doesn't work

[aberba via Digitalmars-d-learn]

Using vibe.d, I bind to port 8080 at 127.0.0.1 but I can't access 
server on my phone through hotspot using the external IP from ip 
addr on Linux. But 127.0.0 running Apache server works.


Don't if its vibe.d or OS (ubuntu 14.04)

How do I reached my vibe.d server in this case on my phone?

Re: How do I use CTFE to generate an immutable associative array at compile time?

[Chad Joan via Digitalmars-d-learn]

On Tuesday, 21 February 2017 at 22:43:15 UTC, H. S. Teoh wrote:


Parsing strings at program startup is ugly and slow.  What 
about parsing at compile-time with CTFE into an array literal 
and transforming that into an AA at startup, which should be a 
lot faster?


// Warning: untested code
pure string[2][] parseTwoColumnCsv(string inputCsv)
{
import std.csv;
import std.typecons;

string[2][] result;
		foreach (record; csvReader!(Tuple!(string,string))(inputCsv)) 
{

result ~= [record[0], record[1]];
}
return result;
}

immutable string[string] dataLookup;
static this()
{
		enum halfCookedData = 
parseTwoColumnCsv(import("some_data.csv"));

foreach (p; halfCookedData) {
dataLookup[p[0]] = p[1];
}
}


T


Hi,

That makes a lot of sense and it had crossed my mind.

In my case the data sets are super small, so I'm probably going 
to be lazy/productive and leave it the way it is.


Anyone else from the internet copying these examples: try to just 
do it H.S. Teoh's way from the start ;)


Thanks for the suggestion.
- Chad

Re: Alexa Skill written in D

[Chris Turner via Digitalmars-d-announce]

On Wednesday, 11 January 2017 at 12:16:06 UTC, extrawurst wrote:


I wanted to ask you if you thought about using another platform 
but nodejs wrap the D exe in lambda. They support java and C# 
aswell. I was wondering if it is a performance difference to 
use them instead ?!

Looking forward to your input.

Cheers,
Stephan


I'm not sure about actual performance differences, but I found an 
interesting project for running Go in lambda, that uses the 
Python runtime, using C bindings. Might be a good fit here.


https://github.com/eawsy/aws-lambda-go-shim

Chris

Re: Class Order Style

[Seb via Digitalmars-d-learn]

On Monday, 20 February 2017 at 13:47:07 UTC, Jolly James wrote:

How to sort the members of a class?

like:

1. properties
then
2. private 3. methods
4. ctors

... and so on. are there any recommendations?


And what is better?


class A
{
private:
   int a;
   int b;
public:
   int c;
   int d;
}

or

class A
{
   private
   {
   int a;
   int b;
   }
   public
   {
   int c;
   int d;
   }
}


Two pointers towards two popular style guides, which could also 
help to answer future questions:


http://dlang.org/dstyle.html

https://vibed.org/style-guide

Re: Enough D to Make a Living?

[aberba via Digitalmars-d]

On Tuesday, 21 February 2017 at 15:34:02 UTC, Paul wrote:
I'm in between engineering jobs and exploring the idea of 
getting into programming for a living...specifically D.
1) Is there enough D demand for someone to make a living (bread 
and water :} ) at it?
Anything is possible. Aged companies are more government in their 
operations. Its way to get employed by startups.


2) I've programmed industrial automation controllers using 
graphical and text-based languages and wrote a few small 
command line tools in D for myself. How long would it take to 
become "employable"?
Web, IoT, cloud ... that's where employment is going. You know 
about embedded systems already (IoT). Don't know how much support 
D has in this area though, but seems LDC has good arm support.


3) Is there much value in taking programming classes that don't 
deal with D?
I will recommended studying the few D books, standard library 
(very important), language specification, and basic algorithms. 
Exercism.io is a good learning resource for D and Github D 
projects.



4) What is the best way to find D programming jobs online?

No one really knows. They have to have a reason to employ you 
which your genuine portfolio can help. Some companies look for 
certs whilst others look for capable talents/skills.


Startups are formed everyday.


I don't want to go into whether CS degree is a requirement or not.

Re: Class Order Style

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, February 21, 2017 22:41:40 Lenny Lowood via Digitalmars-d-learn 
wrote:
> On Monday, 20 February 2017 at 18:02:20 UTC, Jolly James wrote:
> > On Monday, 20 February 2017 at 13:50:26 UTC, ketmar wrote:
> >> just add ddoc documentation to 'em, and then it doesn't matter
> >> in which order they are declared: people will generate
> >> documentation to find out how to use your code. ;-)
> >
> > ah okay, thx
> >
> >
> > But what about this?
> >
> >>>class A
> >>>{
> >>>
> >>>private:
> >>>int a;
> >>>int b;
> >>>
> >>>public:
> >>>int c;
> >>>int d;
> >>>
> >>>}
> >>>
> >> or
> >>
> >>>class A
> >>>{
> >>>
> >>>private
> >>>{
> >>>
> >>>int a;
> >>>int b;
> >>>
> >>>}
> >>>public
> >>>{
> >>>
> >>>int c;
> >>>int d;
> >>>
> >>>}
> >>>
> >>>}
>
> Me as a beginner would like to know this, too ...

It's completely a stylistic preference. There are a number of different ways
to order your member variables and functions, and there are several
different ways to apply attributes to them.

As far as public and private go, I think that most folks either use the
labels like

private:
public:

or they put them directly on the members like

private int a;

I suspect that the folks who programmed a lot in C++ tend to do the former,
since that's the way you have to do it in C++, and I'd guess that the folks
who have programmed a lot in Java or C# typically do the latter, because
that's how you have to do it in those languages.

There is no right or wrong way. Personally, I use the labels like in C++ and
put the public stuff first in a class or struct and the private stuff last
(and I think that that's what Phobos mostly does), but you'll find plenty of
folks who do it differently.

- Jonathan M Davis

Re: New (page-per-artifact) standard library doc examples are now editable and runnable

[Seb via Digitalmars-d-announce]

On Sunday, 19 February 2017 at 02:27:41 UTC, Mike Parker wrote:

On Saturday, 18 February 2017 at 16:43:43 UTC, Seb wrote:



Excellent idea!
AFAIK reddit doesn't like self posts that much.
Would someone be so kind to post this once the improvements 
are in?


https://github.com/dlang/dlang.org/pull/1575

(this PR disables the `assert` transformation for now and also 
changes the output to pre.

It will automatically be deployed once merged)


I'll do it. But before I do, I'll want to know that everything 
is working as intended. Post here with a green light and I'll 
post it during one of the peak periods.


Thanks a lot!
FYI the PR fix has been merged.


Unfortunately it reverts the writeln magic as the false positive 
rate was too high - at some point we really should come up with 
something better :/
However the fact that ddoc and ddox emit different, fully built 
synax-highlighted HTML doesn't make it easier. Maybe the compiler 
can help out here (?) or we can run a libdparse-based formatter 
before running ddoc/ddox?
(at least for ddox there is also the intermediate json output of 
DMD, but for now it seems that the switch to ddox doesn't happen 
as soon as anticipated)

Re: How do I use CTFE to generate an immutable associative array at compile time?

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Feb 21, 2017 at 11:50:02PM +0100, Daniel Kozak via Digitalmars-d-learn 
wrote:
> I have similar issue and I beleive I was able to workaround that
> somehow, but it is so many years now :(. Have you tried enum
> dataLookup instead of immutable string[string] dataLookup

That may appear to work, but I would *strongly* recommend against it,
because what happens when you use enum with an AA, is that the AA will
be created *at runtime*, *every single time* it is referenced.  (It is
as if you copy-n-pasted the entire AA into the code each time you
reference the enum.)  Which will introduce ridiculous amounts of
redundant work at runtime and cause a big performance penalty.


T

-- 
What did the alien say to Schubert? "Take me to your lieder."

Re: How do I use CTFE to generate an immutable associative array at compile time?

[Daniel Kozak via Digitalmars-d-learn]

I have similar issue and I beleive I was able to workaround that 
somehow, but it is so many years now :(. Have you tried enum dataLookup 
instead of immutable string[string] dataLookup



Dne 21.2.2017 v 22:53 Chad Joan via Digitalmars-d-learn napsal(a):

Hello all,

I'm trying to make this work:

---
pure string[string] parseTwoColumnCsv(string inputCsv)
{
import std.csv;
import std.typecons;

string[string] result;

foreach ( record; csvReader!(Tuple!(string,string))(inputCsv) )
result[record[0]] = record[1];

return result;
}

immutable string[string] dataLookup = 
parseTwoColumnCsv(import("some_data.csv"));


void main()
{
import std.stdio;
writefln("dataLookup = %s", dataLookup);
}
---

But (with DMD 2.073.1) I am getting this error:
main.d(14): Error: non-constant expression [['a', 'b', 'c']:['x', 'y', 
'z'], ['1', '2', '3']:['4', '5', '6']]



The case with normal (non-associative) arrays seems to work fine, but 
is not what I needed:


---
pure string[][] parseTwoColumnCsv(string inputCsv)
{
import std.csv;
import std.typecons;

string[][] result;

foreach ( record; csvReader!(Tuple!(string,string))(inputCsv) )
result ~= [record[0],record[1]];

return result;
}

immutable string[][] dataLookup = 
parseTwoColumnCsv(import("some_data.csv"));


void main()
{
import std.stdio;
writefln("dataLookup = %s", dataLookup);
}
---

Any idea how I can get this working?

I have tried a couple other things, like having the parseTwoColumnCsv 
function return an immutable string[string] and casting 'result' to 
that in the return statement, and I also tried just casting the value 
returned from parseTwoColumnCsv as it appears in the declaration of 
'dataLookup'.  I tried std.exception's assumeUnique, but the 
function/template signature doesn't seem to support associative arrays.


Thanks.

Re: How do I use CTFE to generate an immutable associative array at compile time?

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Feb 21, 2017 at 10:34:57PM +, Chad Joan via Digitalmars-d-learn 
wrote:
> On Tuesday, 21 February 2017 at 22:26:01 UTC, Chad Joan wrote:
> > On Tuesday, 21 February 2017 at 21:58:07 UTC, Stefan Koch wrote:
> > > On Tuesday, 21 February 2017 at 21:53:23 UTC, Chad Joan wrote:
> > > > Hello all,
> > > > 
> > > > I'm trying to make this work:
> > > > 
> > > > [...]
> > > 
> > > You cannot create AA's at ctfe and carry them over to runtime use.
> > > You'd have to use a costum dictionary-type.
> > > I think the vibe.d project has one you could use.
> > 
> > I wondered if this might be the case.
> > 
> > Well, I won't worry about it then.  I'll have to find another way
> > around.
> > 
> > Thanks a bunch!
> 
> For the sake of the rest of the internet, here is what I'm probably going to
> stick with:
> 
> ---
> pure string[string] parseTwoColumnCsv(string inputCsv)
> {
>   import std.csv;
>   import std.typecons;
>   
>   string[string] result;
>   
>   foreach ( record; csvReader!(Tuple!(string,string))(inputCsv) )
>   result[record[0]] = record[1];
>   
>   return result;
> }
> 
> immutable string[string] dataLookup;
> 
> static this()
> {
>   dataLookup = parseTwoColumnCsv(import("some_data.csv"));
> }
> 
> void main()
> {
>   import std.stdio;
>   writefln("dataLookup = %s", dataLookup);
> }
> ---
> 
> In this case the AA isn't actually coded into the executable; but at least
> the configuration from some_data.csv will be in the executable as a string.
> The program will construct the AA at startup.  It's not as "cool", but it
> should get the job done.
[...]

Parsing strings at program startup is ugly and slow.  What about parsing
at compile-time with CTFE into an array literal and transforming that
into an AA at startup, which should be a lot faster?

// Warning: untested code
pure string[2][] parseTwoColumnCsv(string inputCsv)
{
import std.csv;
import std.typecons;

string[2][] result;
foreach (record; csvReader!(Tuple!(string,string))(inputCsv)) {
result ~= [record[0], record[1]];
}
return result;
}

immutable string[string] dataLookup;
static this()
{
enum halfCookedData = 
parseTwoColumnCsv(import("some_data.csv"));
foreach (p; halfCookedData) {
dataLookup[p[0]] = p[1];
}
}


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at 
it. -- Pete Bleackley

Re: Class Order Style

[Lenny Lowood via Digitalmars-d-learn]

On Monday, 20 February 2017 at 18:02:20 UTC, Jolly James wrote:

On Monday, 20 February 2017 at 13:50:26 UTC, ketmar wrote:
just add ddoc documentation to 'em, and then it doesn't matter 
in which order they are declared: people will generate 
documentation to find out how to use your code. ;-)


ah okay, thx


But what about this?


class A
{
private:
   int a;
   int b;
public:
   int c;
   int d;
}

or

class A
{
   private
   {
   int a;
   int b;
   }
   public
   {
   int c;
   int d;
   }
}



Me as a beginner would like to know this, too ...

Re: Moonshot: a DMD fork that outputs Lua

[Mithun Hunsur via Digitalmars-d-announce]

On Tuesday, 21 February 2017 at 16:18:44 UTC, Stefan Koch wrote:
On Tuesday, 21 February 2017 at 12:45:47 UTC, Mithun Hunsur 
wrote:

Hi all,

Introducing Moonshot (https://github.com/Philpax/moonshot)!


Hi Mithun,

Looking over the code for lua it seems that you use std.format 
a lot a ctfe.
I would advise against that as it needlessly increases compile 
times.
The built-in concat operator is supposed to be faster in many 
cases.


I am interested in how you handle complex types i.e. structs 
with pointers of the same struct type and the like.


I think moonshot is a worthwhile effort.
Congrats for getting something like this to work.


Hi Stefan,

I figured you'd have some thoughts on the matter! You're right, 
I've used `std.format` a fair bit out of convenience; I'll see 
what I can do about going back to regular old concat.


I'm not sure about how I'm going to support pointers/references 
yet, but I suspect the case you've suggested should be fairly 
simple. As Lua has reference semantics by default, I'm 
representing the struct as a table that gets copied on 
assignment; this means the representation of Struct* should be 
the same thing, but without the auto-copy.


(Ooh, there's a fun subtopic for a potential talk: representing 
value types with reference types.)


Thanks for the feedback!

Re: How do I use CTFE to generate an immutable associative array at compile time?

[Chad Joan via Digitalmars-d-learn]

On Tuesday, 21 February 2017 at 22:26:01 UTC, Chad Joan wrote:

On Tuesday, 21 February 2017 at 21:58:07 UTC, Stefan Koch wrote:

On Tuesday, 21 February 2017 at 21:53:23 UTC, Chad Joan wrote:

Hello all,

I'm trying to make this work:

[...]


You cannot create AA's at ctfe and carry them over to runtime 
use.

You'd have to use a costum dictionary-type.
I think the vibe.d project has one you could use.


I wondered if this might be the case.

Well, I won't worry about it then.  I'll have to find another 
way around.


Thanks a bunch!


For the sake of the rest of the internet, here is what I'm 
probably going to stick with:


---
pure string[string] parseTwoColumnCsv(string inputCsv)
{
import std.csv;
import std.typecons;

string[string] result;

foreach ( record; csvReader!(Tuple!(string,string))(inputCsv) )
result[record[0]] = record[1];

return result;
}

immutable string[string] dataLookup;

static this()
{
dataLookup = parseTwoColumnCsv(import("some_data.csv"));
}

void main()
{
import std.stdio;
writefln("dataLookup = %s", dataLookup);
}
---

In this case the AA isn't actually coded into the executable; but 
at least the configuration from some_data.csv will be in the 
executable as a string.  The program will construct the AA at 
startup.  It's not as "cool", but it should get the job done.


HTH.

Re: Type conversions in D

[Ali Çehreli via Digitalmars-d-learn]

On 02/21/2017 02:26 PM, Jean Cesar wrote:
> On Tuesday, 21 February 2017 at 22:09:11 UTC, Seb wrote:
>> On Tuesday, 21 February 2017 at 21:39:37 UTC, Jean Cesar wrote:
>>> I once saw an article that talked about type conversions using the D
>>> language.
>>>
>>> Type convert integer to exadecimal, binary, but I'm thinking of
>>> writing an article in my blog but I do not find the site I saw on to
>>> know more information of the same type as I did below.
>>>
>>> void main()
>>> {
>>>   int a=15;
>>>
>>>  writefln("O numero %s em binario é %b", a, a);
>>> }
>>
>> Note that what you are looking for is a library feature:
>>
>> https://dlang.org/phobos/std_conv.html
>>
>> In fact every type can implement its own specific format handling:
>>
>> https://dlang.org/phobos/std_format.html
>
> I'm not talking about it so I'm seeing what I've seen and I'm looking
> for things about the integer conversion operators for exa, from exa to
> integer etc ... I saw this once on the tutorialspoint site but I went
> there and I can not find any more I know if it was removed.

Just for clarification, what you've originally shown is formatting: no 
type conversion is involved.


For type conversions, this is a must read anyway:

  https://dlang.org/spec/type.html#integer-promotions

(And "Usual Arithmetic Conversions" there.)

However, I think you're talking about literal syntax:

  https://dlang.org/spec/lex.html#integerliteral

which I had attempted to rephrase here:

  http://ddili.org/ders/d.en/literals.html#ix_literals.literal

Ali

Re: Type conversions in D

[Jean Cesar via Digitalmars-d-learn]

On Tuesday, 21 February 2017 at 22:09:11 UTC, Seb wrote:

On Tuesday, 21 February 2017 at 21:39:37 UTC, Jean Cesar wrote:
I once saw an article that talked about type conversions using 
the D language.


Type convert integer to exadecimal, binary, but I'm thinking 
of writing an article in my blog but I do not find the site I 
saw on to know more information of the same type as I did 
below.


void main()
{
  int a=15;

 writefln("O numero %s em binario é %b", a, a);
}


Note that what you are looking for is a library feature:

https://dlang.org/phobos/std_conv.html

In fact every type can implement its own specific format 
handling:


https://dlang.org/phobos/std_format.html


I'm not talking about it so I'm seeing what I've seen and I'm 
looking for things about the integer conversion operators for 
exa, from exa to integer etc ... I saw this once on the 
tutorialspoint site but I went there and I can not find any more 
I know if it was removed.

Re: How do I use CTFE to generate an immutable associative array at compile time?

[Chad Joan via Digitalmars-d-learn]

On Tuesday, 21 February 2017 at 21:58:07 UTC, Stefan Koch wrote:

On Tuesday, 21 February 2017 at 21:53:23 UTC, Chad Joan wrote:

Hello all,

I'm trying to make this work:

[...]


You cannot create AA's at ctfe and carry them over to runtime 
use.

You'd have to use a costum dictionary-type.
I think the vibe.d project has one you could use.


I wondered if this might be the case.

Well, I won't worry about it then.  I'll have to find another way 
around.


Thanks a bunch!

Re: Type conversions in D

[Seb via Digitalmars-d-learn]

On Tuesday, 21 February 2017 at 21:39:37 UTC, Jean Cesar wrote:
I once saw an article that talked about type conversions using 
the D language.


Type convert integer to exadecimal, binary, but I'm thinking of 
writing an article in my blog but I do not find the site I saw 
on to know more information of the same type as I did below.


void main()
{
  int a=15;

 writefln("O numero %s em binario é %b", a, a);
}


Note that what you are looking for is a library feature:

https://dlang.org/phobos/std_conv.html

In fact every type can implement its own specific format handling:

https://dlang.org/phobos/std_format.html

Re: How do I use CTFE to generate an immutable associative array at compile time?

[Stefan Koch via Digitalmars-d-learn]

On Tuesday, 21 February 2017 at 21:53:23 UTC, Chad Joan wrote:

Hello all,

I'm trying to make this work:

[...]


You cannot create AA's at ctfe and carry them over to runtime use.
You'd have to use a costum dictionary-type.
I think the vibe.d project has one you could use.

How do I use CTFE to generate an immutable associative array at compile time?

[Chad Joan via Digitalmars-d-learn]

Hello all,

I'm trying to make this work:

---
pure string[string] parseTwoColumnCsv(string inputCsv)
{
import std.csv;
import std.typecons;

string[string] result;

foreach ( record; csvReader!(Tuple!(string,string))(inputCsv) )
result[record[0]] = record[1];

return result;
}

immutable string[string] dataLookup = 
parseTwoColumnCsv(import("some_data.csv"));


void main()
{
import std.stdio;
writefln("dataLookup = %s", dataLookup);
}
---

But (with DMD 2.073.1) I am getting this error:
main.d(14): Error: non-constant expression [['a', 'b', 'c']:['x', 
'y', 'z'], ['1', '2', '3']:['4', '5', '6']]



The case with normal (non-associative) arrays seems to work fine, 
but is not what I needed:


---
pure string[][] parseTwoColumnCsv(string inputCsv)
{
import std.csv;
import std.typecons;

string[][] result;

foreach ( record; csvReader!(Tuple!(string,string))(inputCsv) )
result ~= [record[0],record[1]];

return result;
}

immutable string[][] dataLookup = 
parseTwoColumnCsv(import("some_data.csv"));


void main()
{
import std.stdio;
writefln("dataLookup = %s", dataLookup);
}
---

Any idea how I can get this working?

I have tried a couple other things, like having the 
parseTwoColumnCsv function return an immutable string[string] and 
casting 'result' to that in the return statement, and I also 
tried just casting the value returned from parseTwoColumnCsv as 
it appears in the declaration of 'dataLookup'.  I tried 
std.exception's assumeUnique, but the function/template signature 
doesn't seem to support associative arrays.


Thanks.

Type conversions in D

[Jean Cesar via Digitalmars-d-learn]

I once saw an article that talked about type conversions using 
the D language.


Type convert integer to exadecimal, binary, but I'm thinking of 
writing an article in my blog but I do not find the site I saw on 
to know more information of the same type as I did below.


void main()
{
  int a=15;

 writefln("O numero %s em binario é %b", a, a);
}

Re: Moonshot: a DMD fork that outputs Lua

[pineapple via Digitalmars-d-announce]

On Tuesday, 21 February 2017 at 12:45:47 UTC, Mithun Hunsur wrote:

Hi all,

I've been working on a little project over the last month and a 
half, inspired by Adam's dtojs 
(https://github.com/adamdruppe/dtojs). I've always wanted a 
typed, powerful, embeddable scripting language, but found the 
contenders lacking - which is why I decided to hack up DMD to 
emit Lua.


This is awesome. Great work! Is there an easy way to see compiler 
output for some example programs?


I encourage you to submit a dconf talk - I know I'd like to hear 
more about this - just mind that the submission deadline is 
coming up in a few days.

Re: Enough D to Make a Living?

[pineapple via Digitalmars-d]

On Tuesday, 21 February 2017 at 18:32:22 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 02/21/2017 10:34 AM, Paul wrote:
3) Is there much value in taking programming classes that 
don't deal

with D?


Although HR folk never understand this, programming skills are 
highly transferable across languages. So yes, it's definitely 
worthwhile: Getting better with one language will help you be a 
better programmer in other languages.


Very much this. Companies are never impressed by my knowing any 
language in particular, they're impressed by the fact I've 
written code in so many different languages. Statically-typed 
languages, dynamic languages, scripting languages, JVM languages, 
assembly languages, etc. etc. etc. Definitely let yourself spend 
the most time on a language or two you enjoy most, because it's 
still important to demonstrate that you're able to know a 
language front-to-back. But experiment with as many other 
languages as you can, as much as you feel comfortable and then 
some, because that's how you gradually get to a place where the 
only thing separating you from proficiency with any programming 
language is a week or two of ramp-up time. And that alone makes 
you employable almost anywhere.


As for employability: These days, one of the absolute best things 
you can do is to have an active github account. Put your projects 
in public repositories, even the small ones, and any time you 
think of something interesting or you need a tool for yourself, 
commit code to the site while you're developing it. And never be 
afraid to submit PRs for improving other people's repos, because 
it's almost always welcome and it also looks great in terms of 
employability because it shows how comfortable you are working 
with other people's code.


The overwhelming majority of jobs these days involve writing C++, 
C#, Java, JavaScript, or Python. You will have a much easier time 
finding a job writing code mainly in one of those languages than 
one writing code in D - but that doesn't make learning D useless, 
or anything close to it. Everything you learn by writing D will 
be transferable to those other languages, especially C++. Just 
stay aware that it is well worth your time to familiarize 
yourself with other languages, too, and be open to the 
possibility of finding work that focuses on other languages.

Re: Enough D to Make a Living?

[Dukc via Digitalmars-d]

On Tuesday, 21 February 2017 at 15:34:02 UTC, Paul wrote:
I'm in between engineering jobs and exploring the idea of 
getting into programming for a living...specifically D.


Well, D is nowhere near the popularity of the most common 
languages so projects which use D are still rare. There are some, 
trough. However, if you get to choose your language, chances are 
probably good you can. I believe D is stable enough to function 
well in all but the biggest projects. And if you make your 
project, it won't be big enough to cause serious problems.


But even if you won't use D, it may be even the best choice to 
learn, because it handles so many programming styles and shares 
syntax with many common languages. That means that few languages 
are utterly alien for a D programmer. If you learned Pascal, you 
would likely find Haskell totally alien and vice-versa. But a D 
programmer will find some familiarity in both.


Take these with a grain of salt, I do not have much personal 
experience in things like this.

Re: Hello, folks! Newbie to D, have some questions!

[Ali Çehreli via Digitalmars-d-learn]

On 02/21/2017 09:13 AM, timmyjose wrote:

On Tuesday, 21 February 2017 at 14:17:39 UTC, Steve Biedermann wrote:

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

[...]


I'm using D for small tools for about a year now and I never had to
mess with GC. Most of the tools don't need to work on GBs of data and
performance has always been good enough.

[...]


I would upvote you if I could! :-) ... that's not only an interesting
read, but also fodder for mini-projects of my own!


Making sure that you've seen the link that sarn had posted earlier in 
this thread:


> https://forum.dlang.org/thread/o6c9tj$2bdp$1...@digitalmars.com
> (Silicon Valley D Meetup - January 26, 2017 - "High Performance Tools 
in D" by Jon Degenhardt)


Jon Degenhardt has been writing multiple times faster running tools just 
by (almost) casual D coding. (Hopefully he will write a blog post about 
his experiences soon.)


Ali

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Tuesday, 21 February 2017 at 01:57:21 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch 
wrote:




Currently I am having trouble caused by a bug in dmds inliner 
that only happens on when dmd is compiled as a 32bit 
executable until I have  isolated / fixed this development is 
slowed down.


I am slowly narrowing down on the source  of this bug.
Until it is fixed builds of newCTFE might not behave correctly, 
if they have been complied with -inline!


The culprit that introduced the bug seems to be :
 
https://github.com/dlang/dmd/commit/cd01efb4dd5e32277cb156c3cc2b451bdcb68b52


however more testing is needed before I can be sure.

[Issue 17217] std.net.isemail.isEmail doesn't work with non char arrays

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17217

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17217] std.net.isemail.isEmail doesn't work with non char arrays

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17217

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/a91b610ce18e0477ed9b9757e619797f93baaa77
Fix issue 17217 - std.net.isemail.isEmail doesn't work with non char arrays

https://github.com/dlang/phobos/commit/c32240a5fe1316972fb57c70ed1780f6bcbedc07
Merge pull request #5173 from JackStouffer/issue17217

Fix issue 17217 - std.net.isemail.isEmail doesn't work with non char …

--

Re: Enough D to Make a Living?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/21/2017 10:34 AM, Paul wrote:

3) Is there much value in taking programming classes that don't deal
with D?


Although HR folk never understand this, programming skills are highly 
transferable across languages. So yes, it's definitely worthwhile: 
Getting better with one language will help you be a better programmer in 
other languages.

Re: Enough D to Make a Living?

[Paul via Digitalmars-d]

Great. Thanks Jack.

Re: Is autodecoding being phased out?

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Feb 21, 2017 at 02:46:10PM +, Dukc via Digitalmars-d-learn wrote:
> I (finally) managed to build the development build of dmd, with
> libraries.  When testing if it compiles a Hello World program (it
> does, no problem) I got these messages:
> 
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2716,24): Deprecation:
> function std.utf.toUTF8 is deprecated - To be removed November 2017. Please
> use std.utf.encode instead.
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2716,24): Deprecation:
> function std.utf.toUTF8 is deprecated - To be removed November 2017. Please
> use std.utf.encode instead.
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2727,40): Deprecation:
> function std.utf.toUTF8 is deprecated - To be removed November 2017. Please
> use std.utf.encode instead.
> 
> If I output a dstring instead, those messages vanish. Does that mean
> we're getting rid of autodecoding?
> 
> If that's the case, have nothing against that. In fact it is nice to
> have that deprecation to catch bugs. I just thought, due to an earlier
> forum discussion, that it's not going to happen because it could break
> too much code. That's why I'm asking...

Do another git update.  This is a transitory issue where std.stdio got a
bit out-of-sync with std.utf, but this deprecation message should no
longer appear in the latest git HEAD.  (I also saw the same messages and
was about to submit a PR, but after updating my git repos they went
away.)


T

-- 
Unix was not designed to stop people from doing stupid things, because that 
would also stop them from doing clever things. -- Doug Gwyn

Re: Hello, folks! Newbie to D, have some questions!

[timmyjose via Digitalmars-d-learn]

On Monday, 20 February 2017 at 17:36:32 UTC, H. S. Teoh wrote:
On Mon, Feb 20, 2017 at 03:00:05PM +, timmyjose via 
Digitalmars-d-learn wrote: [...]
Just one question about the compilers though - I read on the 
Wiki that there are three main compiler distros - dmd, ldc, 
and gdc. I code primarily on a mac, and I have installed both 
dmd and ldc. A lot of the flags appears to be similar, and for 
my small programs, compilation and execution speed appeared to 
be almost identical. However, the book suggested using dmd for 
dev and probably ldc/gdc for releases. Is this really followed 
that much in practice, or should I prefer dmd?


Personally, I use dmd git HEAD for 90% of my D projects, 
because (1) I'm such a sucker for the latest and greatest 
features, bugfixes, language changes, etc., and (2) I 
occasionally contribute to the compiler toolchain (mainly 
Phobos, sometimes druntime or dmd itself) and it's much easier 
to debug something I use on a regular basis and not have to 
switch to a different version or waste time chasing down a 
compiler bug that's already been fixed in git HEAD.


Thank you, that's great to hear! I have installed both dmd and 
ldc on my mac box and am experimenting with both as well :-)


However, when I need performant code, I pull up my trusty, 
rusty old gdc (which, unfortunately, tends to be about a 
version or two behind the main dmd release -- I believe Iain is 
working on improving this, though). In spite of Walter being a 
renowned compiler genius, he simply has too many things on his 
plate and working on the optimizer hasn't been a high priority, 
so gdc's optimizer easily beats dmd (sometimes by a long 
stretch).  Don't get me wrong; for your average desktop 
application, dmd output is more than good enough. It only 
really matters when you're dealing with CPU-intensive 
performance-critical things like maintaining framerate in a 
complex game engine, or real-time software where somebody dies 
if the program fails to respond within a 10ms margin, or when 
you're trying to solve a PSPACE-complete exponential problem 
where a 20ms difference in inner loop performance could mean 
the difference between getting a result next week vs. next year 
(or next millenium).


That makes a whole lot of sense.

But if you're a stickler for high-performance code, gdc's 
optimizer far outstrips dmd's in just about every way that I 
can think of -- more aggressive inlining, better loop 
optimization, better codegen in general.  And reputedly ldc has 
comparable performance gains over dmd as well, so that's 
another option.  The only downside is that gdc releases are 
tied to the gcc release cycle, so it tends to be about a 
version or two behind mainline dmd, and ldc is about a version 
behind AFAIK.  But as far as the basics of D are concerned, 
that shouldn't make a big difference, unless you're unlucky 
enough to be bitten by a compiler bug that has no workaround 
and that's only fixed in the latest dmd release. Thankfully, 
though, compiler bugs of that sort have been quite rare (and 
getting rarer with recent releases).



One more thing I noticed when I looked into the executable 
file (using "nm -gU" on my mac) is that I found two 
interesting symbols - _main and _Dmain.  On Rust, for 
instance, the main function got turned into _main, so I 
couldn't use a main in the C code that I was trying to interop 
with from my Rust code. In this case, does the same 
restriction apply (I am still way too far from dabbling in 
interop in D as yet! :-)). I mean, suppose I write some sample 
code in C, and I have a local main function to test the code 
out locally, will I have to comment that out when invoking 
that library from D, or can I keep that as is?


_Dmain is the entry point of your D program, and is only 
emitted if you have a main() function in your D code.  In that 
case, you'll want the druntime version of _main (which does a 
bunch of setup necessary before _Dmain is called).


Ah, I see. Now I understand why those two symbols are there!

But if you're calling D from C code, i.e., the C code defines 
main(),
then you wouldn't also write a main() in D code (obviously -- I 
hope), though you *would* need to call a druntime hook to 
initialize some D runtime things needed before you call any D 
code. (Sorry, can't remember the exact calls off the top of my 
head, but it's a simple matter of calling an init routine or 
two at startup, before invoking any D code, then calling the 
cleanup routine at the end before the program exits. Pretty 
standard stuff.)



T


Got it! So you're saying that in case I want to call D code from 
C, then I do need to take care of some initialisation for the D 
runtime so that I can call the D library's code. That makes sense 
indeed.

Re: Hello, folks! Newbie to D, have some questions!

[timmyjose via Digitalmars-d-learn]

On Monday, 20 February 2017 at 17:43:22 UTC, Ali Çehreli wrote:

On 02/20/2017 07:00 AM, timmyjose wrote:

> slice can be spawned off into a brand new array upon
assigning data to
> it (in the book "Learning D", which I find very nice so far).

It's not assigning data to a slice, but adding elements to it: 
It *may* spawn off a new array. You can use .capacity to see 
whether that will be the case:


  http://ddili.org/ders/d.en/slices.html#ix_slices..capacity

Related to your earlier question on multi-dimensional array 
syntax, which you seem to find "brilliant": :)



http://ddili.org/ders/d.en/slices.html#ix_slices.multi-dimensional%20array

Also, there is the following article which explains the inner 
workings of slices:


  https://dlang.org/d-array-article.html

Ali


You're absolutely right! It was badly worded on my part.  And 
thanks for the links, they really do help! :-)

Re: Hello, folks! Newbie to D, have some questions!

[timmyjose via Digitalmars-d-learn]

On Tuesday, 21 February 2017 at 14:17:39 UTC, Steve Biedermann 
wrote:

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:

[...]


I'm using D for small tools for about a year now and I never 
had to mess with GC. Most of the tools don't need to work on 
GBs of data and performance has always been good enough.


[...]


I would upvote you if I could! :-) ... that's not only an 
interesting read, but also fodder for mini-projects of my own!

Re: Terminix 1.5.0 Released

[Chris via Digitalmars-d-announce]

On Monday, 20 February 2017 at 15:06:37 UTC, Gerald wrote:
I'm pleased to announce that Terminix 1.5.0 has been released. 
Terminix is a GTK3 tiling terminal emulator for Linux which 
follows the Gnome Human Interface Guidelines (HIG). More 
information about Terminix can be found here:


[...]


Thanks. Just cloned, compiled and installed it on Ubuntu 16LTS 
and it works out of the box.


~$ terminix --version
Versions
Terminix version: 1.5.0
VTE version: 0.42
GTK Version: 3.18.9

Nice new features. I'm sure they will come in handy.

[Issue 17210] DMD's Failure to Inline Calls in std.array.Appender.put Cause 3x Slowdown

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17210

ZombineDev  changed:

   What|Removed |Added

   Keywords||performance
 CC||petar.p.ki...@gmail.com

--

[Issue 17177] AutoImplement fails on function overload sets with "cannot infer type from overloaded function symbol"

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17177

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/085902b3d68fe692d020b6b0c31c63deb2a5d987
fix issue 17177.  AutoImplement fails on function overload sets with "cannot
infer type from overloaded function symbol".

https://github.com/dlang/phobos/commit/ef0dffab0d49ba7f069fd3c82173823310fda7ab
Merge pull request #5119 from aermicioi/issue_17177

fix issue 17177.  AutoImplement fails on function overload sets with …

--

Re: Moonshot: a DMD fork that outputs Lua

[Stefan Koch via Digitalmars-d-announce]

On Tuesday, 21 February 2017 at 12:45:47 UTC, Mithun Hunsur wrote:

Hi all,

Introducing Moonshot (https://github.com/Philpax/moonshot)!


Hi Mithun,

Looking over the code for lua it seems that you use std.format a 
lot a ctfe.
I would advise against that as it needlessly increases compile 
times.
The built-in concat operator is supposed to be faster in many 
cases.


I am interested in how you handle complex types i.e. structs with 
pointers of the same struct type and the like.


I think moonshot is a worthwhile effort.
Congrats for getting something like this to work.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

[Nick Treleaven via Digitalmars-d]

On Sunday, 19 February 2017 at 01:53:58 UTC, Timothee Cour wrote:

Doesn't add indentation:

with (module_!"std.stdio, std.traits")
void fun(T)(File input, T value)
if (isIntegral!T);


* what is the implementation of `module_` ? `from` defined 
earlier doesn't allow for multiple modules as in 
from!"std.stdio, std.traits"`. But let's assume it can be done 
for now.


I don't know how to implement it. Possibly with multiple alias 
this.



* when `with` covers multiple declarations, it adds indentation:
with(module_!"std.stdio"){
  declaration1;
  declaration2;
}

* when `with` covers a single one, it doesn't add indentation, 
but then `::` can be used instead, with arguably simpler syntax:


`void fun(T)(std.stdio::File input, T value);`
vs
`with (module_!"std.stdio") void fun(T)(File input, T value);`


What about when the 2nd argument uses File as well? That's the 
violation of DRY I meant.


with/module_ solves the UFCS member stand-in problem 
elegantly, how does your proposal solve it?:

with (module_!"std.range.primitives")
void func(alias pred, R)(R range)
if (isInputRange!R && is(typeof(pred(range.front)) == bool);

.front has to refer to *either* a member or an imported UFCS 
function.


UFCS equally affects the `::`  proposal and the 
`module_!""`-without-`with` proposal.


Besides the option of not using UFCS, we can actually use Alias 
for

this, as I've proposed a while ago in
http://forum.dlang.org/post/mailman.1002.1370829729.13711.digitalmars-d-le...@puremagic.com:

`with (module_!"std.range.primitives") ... pred(range.front)`
vs:
`... pred(range.Alias!(std.range.primitives::front))`

or, if a feature that I've proposed earlier in
http://forum.dlang.org/post/mailman.1453.1369099708.4724.digitalmar...@puremagic.com
(support UFCS with fully qualified function names) is accepted, 
it

becomes even simpler:

`... pred(range.(std.range.primitives::front))`


No, then front only refers to the std.range one, not R.front if 
it exists. The with() solution is like a lazy scoped import, 
affecting overloading, whereas using just from! or mod:: forces a 
lookup in that module scope only.

Re: Is autodecoding being phased out?

[Dukc via Digitalmars-d-learn]

On Tuesday, 21 February 2017 at 15:24:18 UTC, Jonathan M Davis 
wrote:

[snip]
- Jonathan M Davis


Thanks for the in-depth answer. Well, auto-decoding is an 
annoyance but not that bad, I can live with it.

[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5813

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |WONTFIX

--

Re: Enough D to Make a Living?

[Jack Stouffer via Digitalmars-d]

On Tuesday, 21 February 2017 at 15:34:02 UTC, Paul wrote:
1) Is there enough D demand for someone to make a living (bread 
and water :} ) at it?


You can scan this page for hiring companies: 
https://dlang.org/orgs-using-d.html


2) I've programmed industrial automation controllers using 
graphical and text-based languages and wrote a few small 
command line tools in D for myself. How long would it take to 
become "employable"?


Look up some programming interview questions and see if you can 
answer them. I would also suggesting having some programs you've 
written in a portfolio.


3) Is there much value in taking programming classes that don't 
deal with D?


Yes, a programmer without CS knowledge is the difference between 
a mechanic and an engineer.



4) What is the best way to find D programming jobs online?


Post here.

Enough D to Make a Living?

[Paul via Digitalmars-d]

I'm in between engineering jobs and exploring the idea of getting 
into programming for a living...specifically D.
1) Is there enough D demand for someone to make a living (bread 
and water :} ) at it?
2) I've programmed industrial automation controllers using 
graphical and text-based languages and wrote a few small command 
line tools in D for myself. How long would it take to become 
"employable"?
3) Is there much value in taking programming classes that don't 
deal with D?

4) What is the best way to find D programming jobs online?

Thanks for your time.

Re: Moonshot: a DMD fork that outputs Lua

[Meta via Digitalmars-d-announce]

On Tuesday, 21 February 2017 at 12:45:47 UTC, Mithun Hunsur wrote:

Hi all,

I've been working on a little project over the last month and a 
half, inspired by Adam's dtojs 
(https://github.com/adamdruppe/dtojs). I've always wanted a 
typed, powerful, embeddable scripting language, but found the 
contenders lacking - which is why I decided to hack up DMD to 
emit Lua.


Introducing Moonshot (https://github.com/Philpax/moonshot)!

Moonshot's based off an early DMD 2.074, and builds up a Lua 
AST from the D AST. It aims to compile a reasonable subset of 
@safe code, so that high-level D can be used in scripting 
environments (i.e. games, scriptable applications, and more.)


Because it's based upon the D frontend, it can already compile 
a lot of what we consider to be D - including foreach, the full 
power of metaprogramming, *ranges*, and more. There's an awful 
lot missing, as well (see the GitHub page for more 
information), but it's quite promising so far.


Of course, this is still a very early, very untested project - 
so it's going to break on 99.9% of D code. I'd like to gauge 
community reaction, but it's nowhere near ready to show off to 
the wider programming community.


This is really cool.

I'd also like to find out if anyone would be interested in me 
submitting a DConf talk about how Moonshot works, and the 
benefits of using D as a typed scripting language.


Cheers!

--


Absolutely. I'd love to hear you talk about this.

Re: Is autodecoding being phased out?

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, February 21, 2017 14:46:10 Dukc via Digitalmars-d-learn wrote:
> I (finally) managed to build the development build of dmd, with
> libraries. When testing if it compiles a Hello World program (it
> does, no problem) I got these messages:
>
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2716,24):
> Deprecation: function std.utf.toUTF8 is deprecated - To be
> removed November 2017. Please use std.utf.encode instead.
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2716,24):
> Deprecation: function std.utf.toUTF8 is deprecated - To be
> removed November 2017. Please use std.utf.encode instead.
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2727,40):
> Deprecation: function std.utf.toUTF8 is deprecated - To be
> removed November 2017. Please use std.utf.encode instead.
>
> If I output a dstring instead, those messages vanish. Does that
> mean we're getting rid of autodecoding?
>
> If that's the case, have nothing against that. In fact it is nice
> to have that deprecation to catch bugs. I just thought, due to an
> earlier forum discussion, that it's not going to happen because
> it could break too much code. That's why I'm asking...

Well, hello world shouldn't be printing deprecation messages, so something
needs to be fixed. But the only version of std.utf.toUTF8 that's being
deprecated is the version that takes a static array, because it does the
same thing as std.utf.encode. So, aside from the fact that something in
Phobos apparently needs to be updated to not use that overload of toUTF8, it
probably doesn't affect you.

Certainly, as it stands, auto-decoding is not going to be phased out - if
nothing else because we don't have a clean way to do it. The code is slowly
being improved so that it works with general character ranges, and stuff
like byCodeUnit has been added, so less in Phobos relies on autodecoding,
and we have better ways to avoid it, but to actually remove it such that
str.front and str.popFront don't auto-decode would break code, and no one
has come up with a way to make the necessary changes without breaking code.

Andrei wants to add RCString (or whatever it's going to be called) which
would then be a reference counted string with small string optimizations and
push for that to be used as the typical string type for code to use, and it
wouldn't do autodecoding. So, maybe at some point, a lot of strings being
used in D code won't autodecode, but as it stands, it's looking like we're
permanently screwed with regards to arrays of char and wchar.

Maybe once enough of Phobos has been fixed to work with arbitrary ranges of
characters, we can find a way to force the transition, but I doubt it.

- Jonathan M Davis

Re: Is autodecoding being phased out?

[Seb via Digitalmars-d-learn]

On Tuesday, 21 February 2017 at 14:46:10 UTC, Dukc wrote:
I (finally) managed to build the development build of dmd, with 
libraries. When testing if it compiles a Hello World program 
(it does, no problem) I got these messages:


C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2716,24): 
Deprecation: function std.utf.toUTF8 is deprecated - To be 
removed November 2017. Please use std.utf.encode instead.
C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2716,24): 
Deprecation: function std.utf.toUTF8 is deprecated - To be 
removed November 2017. Please use std.utf.encode instead.
C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2727,40): 
Deprecation: function std.utf.toUTF8 is deprecated - To be 
removed November 2017. Please use std.utf.encode instead.


If I output a dstring instead, those messages vanish. Does that 
mean we're getting rid of autodecoding?


Sadly no. Just of old pre auto-decoding code.

If that's the case, have nothing against that. In fact it is 
nice to have that deprecation to catch bugs. I just thought, 
due to an earlier forum discussion, that it's not going to 
happen because it could break too much code. That's why I'm 
asking...


No - this is just a deprecation of a specific overload of toUTF8.
See this PR for details:

https://github.com/dlang/phobos/pull/5083

However, this deprecation warning was fixed subsequently in:

https://github.com/dlang/phobos/pull/5143

So are you on LATEST? ;-)

Is autodecoding being phased out?

[Dukc via Digitalmars-d-learn]

I (finally) managed to build the development build of dmd, with 
libraries. When testing if it compiles a Hello World program (it 
does, no problem) I got these messages:


C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2716,24): 
Deprecation: function std.utf.toUTF8 is deprecated - To be 
removed November 2017. Please use std.utf.encode instead.
C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2716,24): 
Deprecation: function std.utf.toUTF8 is deprecated - To be 
removed November 2017. Please use std.utf.encode instead.
C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2727,40): 
Deprecation: function std.utf.toUTF8 is deprecated - To be 
removed November 2017. Please use std.utf.encode instead.


If I output a dstring instead, those messages vanish. Does that 
mean we're getting rid of autodecoding?


If that's the case, have nothing against that. In fact it is nice 
to have that deprecation to catch bugs. I just thought, due to an 
earlier forum discussion, that it's not going to happen because 
it could break too much code. That's why I'm asking...

[Issue 17217] New: std.net.isemail.isEmail doesn't work with non char arrays

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17217

  Issue ID: 17217
   Summary: std.net.isemail.isEmail doesn't work with non char
arrays
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 17217] std.net.isemail.isEmail doesn't work with non char arrays

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17217

--- Comment #1 from Jack Stouffer  ---
https://github.com/dlang/phobos/pull/5173

--

Re: Hello, folks! Newbie to D, have some questions!

[Steve Biedermann via Digitalmars-d-learn]

On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
2. I am more interested in learning D as a pure systems 
programming language so that I can develop my own tools (not 
looking to develop an OS, just some grep-scale tools to start 
off with). In that regard, I have a few concerns about the GC. 
My rudimentary knowledge of the D ecosystem tells me that there 
is a GC in D, but that can be turned off. Is this correct? 
Also, some threads online mention that if we do turn off GC, 
some of the core std libraries may not fully work. Is this 
presumption also correct?


In this regard, I am curious to know if I would face any issues 
(with my intent in mind), or will I do just fine? If you could 
share your experiences and domains of use, that would also be 
very helpful for me. Secondly, how stable is the language and 
how fast is the pace of development on D?


Again, sorry for my ignorance if I have been wrong-footed on 
some (or all) points.


I'm using D for small tools for about a year now and I never had 
to mess with GC. Most of the tools don't need to work on GBs of 
data and performance has always been good enough.


My "biggest" D tool is a custom scriptable code generator based 
on lua and sdl (sdlang.org) and even though it's implemented 
really badly, it performs good enough to be used in development 
(Currently we generate JSON serialization code for delphi with 
it).


I also wrote a simple parser for parsing delphi memory leak 
reports to show some statistics. Depending on how many leaks you 
have, these can get a bit larger, but I always got good enough 
performance with D.


Last tool I want to mention is a binary log file parser, which 
reads an proprietary log file and converts it into json. And even 
this is extremely fast.


So I don't think GC will be a big problem for smaller tools.

Re: Getting nice print of struct for debugging

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-02-20 17:04, Martin Tschierschke wrote:

Hello,
I have a little program where I am filling a struct with values from an
regex match.
Now I want to display the content of the struct for debugging purpose.

If struct is named MyStruct

I can print a list of the field names with:

foreach(fieldname;FieldNameTuple!MyStruct){writef("%s ",fieldname);}

If myvar is of type MyStruct how can I make a table like:

fieldname_1: value_1
fieldname_2: value_2
.
.
fieldname_n: value_n

Is there a way to do this with a single expression in D.

Similar to a ruby call myvar.send(fieldname) to get the value from
fieldname inside a loop?
write(myvar); sure is working directly but I want to get the field names
displayed, too.

(A work around might be work with the format("%s",myvar) string and
extract the values with an index?)


Yes, this works, I would say this is the simplest:

MyStruct s;

foreach (index, name ; FieldNameTuple!MyStruct)
writefln("%s: %s", name, s.tupleof[index]);

If you want something more close to "send" in Ruby, you need to use a 
string mixin, like this:


foreach (name ; FieldNameTuple!MyStruct)
writefln("%s: %s", name, mixin("s." ~ name));

The string mixin example works for methods, opDispatch and similar as 
well. The tupleof example, the first one, works only for fields.


--
/Jacob Carlborg

[Issue 17207] Annotate properties in phobos with 'const' or 'inout'

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17207

anonymous4  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---
Summary|Zero-parameter '@property'  |Annotate properties in
   |function should be marked   |phobos with 'const' or
   |'const', 'inout', or|'inout'
   |'immutable'.|

--- Comment #2 from anonymous4  ---
Ah, it's a request for only these types in phobos? Ok.

--

[Issue 17048] [REG 2.071] Synchronized class methods give warnings for RMW operations

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17048

--- Comment #2 from anonymous4  ---
Though it's a good illustration that hand-holding restrictions on shared types
make them more painful to use even though people complain that shared is
already difficult to use. More ceremony only make situation worse.

--

Moonshot: a DMD fork that outputs Lua

[Mithun Hunsur via Digitalmars-d-announce]

Hi all,

I've been working on a little project over the last month and a 
half, inspired by Adam's dtojs 
(https://github.com/adamdruppe/dtojs). I've always wanted a 
typed, powerful, embeddable scripting language, but found the 
contenders lacking - which is why I decided to hack up DMD to 
emit Lua.


Introducing Moonshot (https://github.com/Philpax/moonshot)!

Moonshot's based off an early DMD 2.074, and builds up a Lua AST 
from the D AST. It aims to compile a reasonable subset of @safe 
code, so that high-level D can be used in scripting environments 
(i.e. games, scriptable applications, and more.)


Because it's based upon the D frontend, it can already compile a 
lot of what we consider to be D - including foreach, the full 
power of metaprogramming, *ranges*, and more. There's an awful 
lot missing, as well (see the GitHub page for more information), 
but it's quite promising so far.


Of course, this is still a very early, very untested project - so 
it's going to break on 99.9% of D code. I'd like to gauge 
community reaction, but it's nowhere near ready to show off to 
the wider programming community.


I'd also like to find out if anyone would be interested in me 
submitting a DConf talk about how Moonshot works, and the 
benefits of using D as a typed scripting language.


Cheers!

--

P.S. It was incredibly exciting to see `10.iota.map!(a => a * 
a).filter!(a => a > 50).each!print;` work with unmodified Phobos. 
The less I have to modify Phobos, the better! :)

Re: Returning the address of a reference return value in @safe code - 2.072 regression?

[Dominikus Dittes Scherkl via Digitalmars-d-learn]

On Monday, 20 February 2017 at 21:05:17 UTC, Jack Stouffer wrote:
On Monday, 20 February 2017 at 20:54:31 UTC, Jack Stouffer 
wrote:
On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen 
wrote:

...


Yeah, this is another regression caused by DIP1000.

Christ.


For the record, the current list of regressions caused by 
DIP1000


https://issues.dlang.org/show_bug.cgi?id=17213
https://issues.dlang.org/show_bug.cgi?id=17188
https://issues.dlang.org/show_bug.cgi?id=17123
https://issues.dlang.org/show_bug.cgi?id=17117


17117 and 17123 are already fixed on HEAD, no?
So only two regressions remaining - I hope DIP1000 can be used to 
build new container libraries soon.

[Issue 17049] [scope] class references are not escape checked like pointers

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17049

--- Comment #1 from Martin Nowak  ---
No longer works (not even for int*) with dmd-master-2017-01-04 and -dip1000.

--

[Issue 17207] Zero-parameter '@property' function should be marked 'const', 'inout', or 'immutable'.

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17207

anonymous4  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Hardware|x86_64  |All
 Resolution|--- |INVALID
 OS|Linux   |All

--- Comment #1 from anonymous4  ---
This would disallow to generate the value on demand.

--

[Issue 17196] [Reg 2.074] isUnsigned!bool now true

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17196

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/58c91e1a2cbe0658a114bac87ebaed05fd630f88
Issue 17196 - [Reg 2.074] isUnsigned!bool now true

https://github.com/dlang/phobos/commit/166ae7dde3b0c4f38be9957943f3f63175803988
Merge pull request #5170 from wilzbach/fix-17196

Issue 17196 - [Reg 2.074] isUnsigned!bool now true
merged-on-behalf-of: Jack Stouffer 

--

Re: Force inline

[berni via Digitalmars-d-learn]

On Monday, 20 February 2017 at 13:48:30 UTC, ketmar wrote:
anyway, in my real-life code inlining never worth the MASSIVELY 
increased compile times: speedup is never actually noticeable. 
if "dmd -O" doesn't satisfy your needs, there is usually no 
reason to trying "-inline", it is better to switch to ldc/gdc.


Probably you're right. I'm using gdc anyway for non-developement 
compiles. I was just curious how much that -inline switch of dmd 
is worth. (Answer: Yet, almost nothing. And knowing, that it is 
buggy together with -O even less than that.)


When comparing dmd and gdc the results where both almost the 
same: 29 seconds. (As a reference: C++ is 22 seconds.) With gdc I 
got a good improvement when using -frelease additionally to -O3 
(now it's 24 seconds). The inline-pragma didn't change anything.


On Monday, 20 February 2017 at 17:12:59 UTC, H. S. Teoh wrote:

Having said all that, though, have you used a profiler to 
determine whether or not your performance bottleneck is really 
at the function in question?


Yes, I did. An well, yes I know: Good design is much more 
important, than speed optimization. And by obeying this, I found 
out, that by changing the order of the conditions used in that 
particular function, I could reduce the duration by 2 more 
seconds... (And in case you wonder, why I bother about 2 seconds: 
It's a small example for testing purpose. There are larger ones 
where this could easily be hours instead of seconds...)

Re: JustQuestion: Are 'D' had a browser library?

[dummy via Digitalmars-d-learn]

On Sunday, 19 February 2017 at 09:23:15 UTC, Mike Parker wrote:

On Sunday, 19 February 2017 at 08:01:56 UTC, dummy wrote:


* Derelict-CEF
Looks like dead and didn't have a document(or tutorial).


It's a binding to the C API of CEF, so you shouldn't expect 
much documentation or any tutorials with it beyond the binding 
specific functionality in the README. If you know how to use 
the CEF C API, then you know how to use Derelict-CEF.


I implemented it as an experiment. It hasn't been updated 
simply because I haven't had a use for it and no one has 
submitted any PRs. So I wouldn't call it dead, just unloved. 
That said, it worked last time I tried it. The CEF API may have 
changed since then, though. If someone wants to get it in 
shape, I'll happily do what I can to facilitate that.


Yes, you are right. Thx very much! :-)

[Issue 17189] Include byPair in the associative array document

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17189

greenify  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greeen...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from greenify  ---
The respective PR has been merged and is now online.

--

[Issue 17010] remove std.net.isemail

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17010

Jack Stouffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||j...@jackstouffer.com
 Resolution|--- |WONTFIX

--- Comment #1 from Jack Stouffer  ---
Neither of the two libraries listed have a way to validate a string for RFC
5321 compliance.

Let's not break people's code for no reason, especially for a module which
causes no one any trouble.

--

[Issue 17195] [Reg 2.074] isFloatingPoint!cfloat is now true

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17195

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/76dd6fe33baffb1ecfc14a192634f0ec51fb7345
Issue 17195 - [Reg 2.074] isFloatingPoint!cfloat is now true

https://github.com/dlang/phobos/commit/d67d487199a2340bd83326e4db5b0e1a5ea425de
Merge pull request #5171 from wilzbach/fix-17195

Issue 17195 - [Reg 2.074] isFloatingPoint!cfloat is now true
merged-on-behalf-of: Jack Stouffer 

--

Re: Force inline

[Daniel Kozak via Digitalmars-d-learn]

Dne 21.2.2017 v 08:41 Daniel Kozak napsal(a):


Dne 21.2.2017 v 08:31 Johan Engelen via Digitalmars-d-learn napsal(a):


On Monday, 20 February 2017 at 13:16:15 UTC, Jonathan M Davis wrote:
dmd is great for fast compilation and therefore it's great for 
development. However, while it produces decent binaries, and it may 
very well do certain optimizations better than the gcc or llvm 
backends do


This I find hard to believe. Do you have an example where DMD 
generates faster code than GDC or LDC ?


Thanks,
  Johan
I remember there has been some. One has been a problem with loop 
elimination, where ldc was not able to remove some of loops which does 
not do anything and dmd was, but I believe it has been fixed now.




http://forum.dlang.org/post/otlxsuticdpwqxzum...@forum.dlang.org
http://forum.dlang.org/post/qoxttndpotbpztwnq...@forum.dlang.org