Re: Hello, folks! Newbie to D, have some questions!
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?
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: How do I use CTFE to generate an immutable associative array at compile time?
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.
Re: Hello, folks! Newbie to D, have some questions!
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: How do I use CTFE to generate an immutable associative array at compile time?
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
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?
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?
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
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?
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: Class Order Style
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: Class Order Style
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: How do I use CTFE to generate an immutable associative array at compile time?
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?
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?
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
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: How do I use CTFE to generate an immutable associative array at compile time?
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
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
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?
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
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?
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?
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
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: Hello, folks! Newbie to D, have some questions!
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: Is autodecoding being phased out?
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!
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!
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!
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: Is autodecoding being phased out?
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.
Re: Is autodecoding being phased out?
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?
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?
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...
Re: Hello, folks! Newbie to D, have some questions!
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
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
Re: Returning the address of a reference return value in @safe code - 2.072 regression?
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.
Re: Force inline
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?
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! :-)
Re: Force inline
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
