Re: RC buffer

[Nicholas Wilson via Digitalmars-d]

On Wednesday, 2 November 2016 at 05:32:13 UTC, Nicholas Wilson 
wrote:
On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei 
Alexandrescu wrote:
I've eliminated all UTF nonsense from 
https://github.com/dlang/phobos/pull/4878 resulting in a bare 
reference counted buffer of (qualified) ubyte.


The goal is to get the buffer @safe and be able to have a 
reasonable explanation for each and every cast. (There are no 
safety annotations currently, but the code passes unittests 
and supports qualifiers.) No undefined behavior casts should 
be used (e.g. that cast away immutability), only simple 
adjustments for realities that the type system is unable to 
cover.


In order to make opAssign safe, a language change will be 
necessary.



Andrei


Shouldn't all those` assert(b ~ c == "bc".representation);`s be 
static asserts?


Derp. copied wrong line. I meant all the typeof asserts.

Re: RC buffer

[Nicholas Wilson via Digitalmars-d]

On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei 
Alexandrescu wrote:
I've eliminated all UTF nonsense from 
https://github.com/dlang/phobos/pull/4878 resulting in a bare 
reference counted buffer of (qualified) ubyte.


The goal is to get the buffer @safe and be able to have a 
reasonable explanation for each and every cast. (There are no 
safety annotations currently, but the code passes unittests and 
supports qualifiers.) No undefined behavior casts should be 
used (e.g. that cast away immutability), only simple 
adjustments for realities that the type system is unable to 
cover.


In order to make opAssign safe, a language change will be 
necessary.



Andrei


Shouldn't all those` assert(b ~ c == "bc".representation);`s be 
static asserts?

Globe cup producers of fifa 17 coins store

[fifa17rabbit via Digitalmars-d]

You can buy fifa globe cup car you want by a series of auto 
stores throughout fifa globe cup nation.Indian bicycle industry 
has witnessed an attack of last bicycle in fifa globe cup last 
couple of decades.


 From fifa globe cup producers of fifa 17 coins store popular 
Native indian bicycle. All fifase well-known manufacturers rolled 
out fifair best bicycle on Native indian streets.


 Strengfifaning of modern style, sporty look, newest gadgets, 
powerful motor and many features, fifa globe cup new launch 
motorbikes in Native indian have a big selection of all segments.

www.myfifa17coins.com

Re: https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays

[Era Scarecrow via Digitalmars-d]

On Wednesday, 2 November 2016 at 03:36:42 UTC, Andrei 
Alexandrescu wrote:

Cons:

* Built-in hashtables are a convenience facility more than a 
high-performance one, so providing an efficiency-oriented 
primitive seems a bit odd.


 I don't see why it would be odd.

 If I know my code is going to be working with 10,000,000 values, 
then telling/hinting so it could prepare appropriately up front 
rather than taking hits later seems useful. It's not like it 
couldn't work without it right?


 I'd hope for a few other features, like the AA could be 
pre-initialized and ready to go, for fixed/immutable lists.

RC buffer

[Andrei Alexandrescu via Digitalmars-d]

I've eliminated all UTF nonsense from 
https://github.com/dlang/phobos/pull/4878 resulting in a bare reference 
counted buffer of (qualified) ubyte.


The goal is to get the buffer @safe and be able to have a reasonable 
explanation for each and every cast. (There are no safety annotations 
currently, but the code passes unittests and supports qualifiers.) No 
undefined behavior casts should be used (e.g. that cast away 
immutability), only simple adjustments for realities that the type 
system is unable to cover.


In order to make opAssign safe, a language change will be necessary.


Andrei

Re: https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays

[Jonathan M Davis via Digitalmars-d]

On Tuesday, November 01, 2016 23:36:42 Andrei Alexandrescu via Digitalmars-d 
wrote:
> Please share your thoughts.

Hasn't Martin been working on a new, templatized AA implementation to
replace the current one? As I recall, he said something about postponing it
by a release to focus on something else (helping Walter with @safe issues
IIRC), but it sounded like it was close to ready. And if that's the case, I
really don't think that it makes sense to be doing anything major with the
current implementation.

But regardless of that, I think that the focus of the built-in AAs should be
to have something simple that works. It should be reasonably performant, but
anything involving performance tuning really should be in library type.
We've had quite a few problems with the built-in AAs over the years
(especially with stuff like user-defined key types - in part because it uses
void* internally IIRC), and while the new implementation will hopefully be
much better in that regard, I think that based on the issues with had with
the built-in AAs historically, doing anything that would make them more
complicated should be approached with extreme caution.

And anyone who really wants to do performance tuning is going to need better
facilities than we're going to be able to reasonably provide in the built-in
AAs anyway.

The only real downside to user-defined hash tables at this point is that you
can't use AA literals with them (which we should probably create a DIP for
at some point). Aside from that, there's no reason that a library AA can't
work as well or better than the built-in AAs, and it would be much easier to
have facilities for tuning performance with a library type than with
something built into the language.

I think that effort put towards containers would be much better served
working towards the std.container rewrite (though you would know where that
stands better than the rest of us as well as whether it makes any sense for
anyone to help you right now). Or maybe Martin could use some help in
finishing whatever he's done with the new, built-in AA implementation. I
don't know. But considering that adding reserve to the built-in AAs is not a
small task and that it'is debatable that it should be done at all, there
pretty much has to be something better for Alex to work on.

- Jonathan M Davis

https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays

[Andrei Alexandrescu via Digitalmars-d]

Our student Alex has been looking at this and I wanted to open the floor 
for a bit of discussion before we embark on an implementation.


Last time I looked our associative arrays were arrays of singly-linked 
lists. It follows that in order to implement reserve() we'd need a 
freelist allocator approach, which preallocates a bunch of nodes in a 
single contiguous block of memory.


Each hashtable would have its own freelist, or alternatively all 
hashtables of the same types share the same freelist.


So should we get into this? Pros:

* It provides a nice primitive to use with built-in hashtables

* Accelerates without much effort a variety of codes using hashtables

Cons:

* Built-in hashtables are a convenience facility more than a 
high-performance one, so providing an efficiency-oriented primitive 
seems a bit odd.


* We're considering a number of improvements and refactorings to 
built-in hashtables, which may obviate the freelist implementation or 
need extra effort to implement it. Basically defining reserve() limits 
our future implementation freedom.


* Implementation effort is nontrivial.

* The time needed to initialize the freelist in one contiguous block of 
memory is still O(n) (although the constant is small and special 
implementation techniques may make it O(1)).


* The implementation cannot use Phobos' allocator because it's in druntime.

Please share your thoughts.


Thanks,

Andrei

Re: is there "this"?

[Konstantin Kutsevalov via Digitalmars-d-learn]

On Wednesday, 2 November 2016 at 02:33:10 UTC, Konstantin 
Kutsevalov wrote:
On Wednesday, 2 November 2016 at 02:20:43 UTC, rikki cattermole 
wrote:

On 02/11/2016 3:17 PM, Konstantin Kutsevalov wrote:

The question is simple.

Is there something like "this" word for classes?

For example:

```
class CLS {

int numberValue;

public this(numberValue)
{
// how can I put the local numberValue to class 
property?

// in some prog language I can do like:
// this.numberValue = numberValue;
}

}
```


You forgot an int in the arguments but otherwise that would 
work fine with your line uncommented.


yes I missed "int", but it's just an example.
so if I'll write "this.property = value" it will work?


I tested already and it really works, thank you.
I asked that because I tried once to use "this" in past but I got 
error. So I asked on some forum "how to get property of class?" 
and peoples said that I may use just a name of property. So I 
thought that there isn't "this" word.

Re: is there "this"?

[Konstantin Kutsevalov via Digitalmars-d-learn]

On Wednesday, 2 November 2016 at 02:20:43 UTC, rikki cattermole 
wrote:

On 02/11/2016 3:17 PM, Konstantin Kutsevalov wrote:

The question is simple.

Is there something like "this" word for classes?

For example:

```
class CLS {

int numberValue;

public this(numberValue)
{
// how can I put the local numberValue to class 
property?

// in some prog language I can do like:
// this.numberValue = numberValue;
}

}
```


You forgot an int in the arguments but otherwise that would 
work fine with your line uncommented.


yes I missed "int", but it's just an example.
so if I'll write "this.property = value" it will work?

Re: is there "this"?

[rikki cattermole via Digitalmars-d-learn]

On 02/11/2016 3:17 PM, Konstantin Kutsevalov wrote:

The question is simple.

Is there something like "this" word for classes?

For example:

```
class CLS {

int numberValue;

public this(numberValue)
{
// how can I put the local numberValue to class property?
// in some prog language I can do like:
// this.numberValue = numberValue;
}

}
```


You forgot an int in the arguments but otherwise that would work fine 
with your line uncommented.

is there "this"?

[Konstantin Kutsevalov via Digitalmars-d-learn]

The question is simple.

Is there something like "this" word for classes?

For example:

```
class CLS {

int numberValue;

public this(numberValue)
{
// how can I put the local numberValue to class property?
// in some prog language I can do like:
// this.numberValue = numberValue;
}

}
```

Re: error

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, November 02, 2016 01:36:23 Concealment via Digitalmars-d-learn 
wrote:
> On Wednesday, 2 November 2016 at 01:32:27 UTC, Adam D. Ruppe
>
> wrote:
> > On Wednesday, 2 November 2016 at 01:27:32 UTC, Concealment
> >
> > wrote:
> >> can someone help me please?
> >
> > did you import anything? `import core.stdc.stdlib;` I think
> > will fix that one, but generally you need an import to use lib
> > functions.
>
> yea i did import core.stdc.stdlib; but it still gives me the same
> error

It's in core.stdc.time. The druntime modules are supposed to correspond to
the C header files, and time is in time.h, not stdlib.h.

- Jonathan M Davis

Re: error

[Concealment via Digitalmars-d-learn]

On Wednesday, 2 November 2016 at 01:32:27 UTC, Adam D. Ruppe 
wrote:
On Wednesday, 2 November 2016 at 01:27:32 UTC, Concealment 
wrote:

can someone help me please?


did you import anything? `import core.stdc.stdlib;` I think 
will fix that one, but generally you need an import to use lib 
functions.


yea i did import core.stdc.stdlib; but it still gives me the same 
error

Re: error

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 2 November 2016 at 01:27:32 UTC, Concealment wrote:

can someone help me please?


did you import anything? `import core.stdc.stdlib;` I think will 
fix that one, but generally you need an import to use lib 
functions.

error

[Concealment via Digitalmars-d-learn]

void main(string[] args)
{
srand(time(null));
int p1 = rand() % 7;
p1++;



i compiled this program i wrote... but it keeps giving me an error

main.d(17): Error: undefined identifier 'time'

can someone help me please?

Re: Function Proposal: std.algorithm.iteration : cumulativeSum

[jmh530 via Digitalmars-d]

On Tuesday, 1 November 2016 at 22:06:36 UTC, Ivan Kazmenko wrote:


DMD 2.072 just got cumulativeFold:

https://dlang.org/changelog/2.072.0.html#std-algorithm-iteration-cumulativeFold

https://dlang.org/phobos/std_algorithm_iteration.html#cumulativeFold


I was happy to see that.

I'm surprised there wasn't more angst about the name. 
cumulativeSum should be cumsum, which implies that cumulativeFold 
should be cumfold, IMO.

Re: Benchmarking Time Unit

[Stefan Koch via Digitalmars-d-learn]

On Tuesday, 1 November 2016 at 22:55:36 UTC, Nordlöw wrote:
On Tuesday, 1 November 2016 at 20:54:34 UTC, Steven 
Schveighoffer wrote:
MonoTime has about 5-10 % fluctuations on my laptop. Is this 
as good as

it gets?


This is not clear. What is this a percentage of?


It percentage of execution time.

15 ms +- 2 ms

That seems doesn't look like what you describe.

Benchmark code here:

https://github.com/nordlow/phobos-next/blob/master/src/benchmarkAppend.d


I supposed you could not have done it with less templates :)
Since you are hitting gc-code all the time it should be expected 
to have varing times.

Re: Benchmarking Time Unit

[Nordlöw via Digitalmars-d-learn]

On Tuesday, 1 November 2016 at 20:54:34 UTC, Steven Schveighoffer 
wrote:
MonoTime has about 5-10 % fluctuations on my laptop. Is this 
as good as

it gets?


This is not clear. What is this a percentage of?


It percentage of execution time.

15 ms +- 2 ms

That seems doesn't look like what you describe.

Benchmark code here:

https://github.com/nordlow/phobos-next/blob/master/src/benchmarkAppend.d

Re: Function Proposal: std.algorithm.iteration : cumulativeSum

[e-y-e via Digitalmars-d]

On Tuesday, 1 November 2016 at 22:22:17 UTC, Ivan Kazmenko wrote:

On Tuesday, 1 November 2016 at 22:13:29 UTC, e-y-e wrote:

...


Ouch, and I completely misread the TL;DR paragraph, sorry for 
the noise!


My fault, note to self: always re-read everything.



It's logical to have cumulativeSum specialized from 
cumulativeFold when sum is a specialization of fold.


I have yet to write a program which relies on Kahan summation, 
but I can imagine that being useful.


To be entirely honest, I haven't experienced any _problems_ with 
the accuracy of naive summation. But Kahan summation does improve 
accuracy in some cases and I want that assurance.


It does have its own inaccuracies though and I think (may be 
wrong, again, its late) a flag like -ffastmath would probably 
eliminate any accuracy gain.

[Issue 8087] Improve clarity of std.algorithm documentation

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/946a46774c58681036e12932858d0bb58f887448
Fix Issue 8087 - Improve clarity of std.algorithm documentation

https://github.com/dlang/phobos/commit/fd518eb310a9494cccf28c54892542b052c49669
Merge pull request #4883 from Darredevil/issue-8087

Fix Issue 8087 - Improve clarity of std.algorithm documentation

--

Re: Function Proposal: std.algorithm.iteration : cumulativeSum

[Ivan Kazmenko via Digitalmars-d]

On Tuesday, 1 November 2016 at 22:13:29 UTC, e-y-e wrote:

On Tuesday, 1 November 2016 at 22:09:50 UTC, e-y-e wrote:
On Tuesday, 1 November 2016 at 22:06:36 UTC, Ivan Kazmenko 
wrote:

...


damn, that was a typo [cumulativeFold -> cumulativeSum]


similarly, in the first para, cumulativeSum!((a, b) => a + 
b)(r, s) -> cumulativeFold!((a, b) => a + b)(r, s)


Ouch, and I completely misread the TL;DR paragraph, sorry for the 
noise!


It's logical to have cumulativeSum specialized from 
cumulativeFold when sum is a specialization of fold.


I have yet to write a program which relies on Kahan summation, 
but I can imagine that being useful.


Ivan Kazmenko.

[Issue 8087] Improve clarity of std.algorithm documentation

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 16614] [META] Each artifact in the standard library should have a meaningful example

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16614
Issue 16614 depends on issue 8087, which changed state.

Issue 8087 Summary: Improve clarity of std.algorithm documentation
https://issues.dlang.org/show_bug.cgi?id=8087

   What|Removed |Added

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

--

Re: Function Proposal: std.algorithm.iteration : cumulativeSum

[e-y-e via Digitalmars-d]

On Tuesday, 1 November 2016 at 22:09:50 UTC, e-y-e wrote:
On Tuesday, 1 November 2016 at 22:06:36 UTC, Ivan Kazmenko 
wrote:

...


damn, that was a typo [cumulativeFold -> cumulativeSum]


similarly, in the first para, cumulativeSum!((a, b) => a + b)(r, 
s) -> cumulativeFold!((a, b) => a + b)(r, s)

Re: Function Proposal: std.algorithm.iteration : cumulativeSum

[e-y-e via Digitalmars-d]

On Tuesday, 1 November 2016 at 22:06:36 UTC, Ivan Kazmenko wrote:

On Tuesday, 1 November 2016 at 21:52:40 UTC, e-y-e wrote:
I'd like to propose the function cumulativeFold as a new 
addition to std.algorithm.iteration. I have already opened a 
pull request [1] for this addition so the full implementation 
is available there. The function signatures are:


DMD 2.072 just got cumulativeFold:

https://dlang.org/changelog/2.072.0.html#std-algorithm-iteration-cumulativeFold

https://dlang.org/phobos/std_algorithm_iteration.html#cumulativeFold


damn, that was a typo [cumulativeFold -> cumulativeSum]

Re: Function Proposal: std.algorithm.iteration : cumulativeSum

[Ivan Kazmenko via Digitalmars-d]

On Tuesday, 1 November 2016 at 21:52:40 UTC, e-y-e wrote:
I'd like to propose the function cumulativeFold as a new 
addition to std.algorithm.iteration. I have already opened a 
pull request [1] for this addition so the full implementation 
is available there. The function signatures are:


DMD 2.072 just got cumulativeFold:

https://dlang.org/changelog/2.072.0.html#std-algorithm-iteration-cumulativeFold

https://dlang.org/phobos/std_algorithm_iteration.html#cumulativeFold

Re: Function Proposal: std.algorithm.iteration : cumulativeSum

[e-y-e via Digitalmars-d]

On Tuesday, 1 November 2016 at 21:52:40 UTC, e-y-e wrote:

...
this table:

  | Provides no intermediate results | Provides 
intermediate results
 
-|--|---

 Not  |  |
 specialized  |   fold   | 
cumulativeFold

 for accurate |  |
 summation|  |
 
-|--|---

 Specialized  |  |
 for accurate |sum   |
  X
 summation|  |

...


Apologies to those reading on mobile or in a non-monospace font 
for this table.

Assistance with DUB

[Alfred Newman via Digitalmars-d-learn]

Greetings,

I need some help with dub libraries.

Executing "dub list" in my machine, I got the following:

Packages present in the system and known to dub:
colorize ~master: 
C:\Users\Alfred\AppData\Roaming\dub\packages\colorize-master\colorize\

...
sqlite-d ~master: 
C:\Users\Alfred\AppData\Roaming\dub\packages\sqlite-d-master\sqlite-d\
x11 1.0.15: 
C:\Users\Alfred\AppData\Roaming\dub\packages\x11-1.0.15\x11\


*** Note that sqlite-d is listed there.

When I try to run the code in the end of this thread, I got the 
following error:


compiling C:...\Projects\temp2.d
C:\Users\Alfred\Dropbox\Dlang\Projects\temp2.d(8,8): Error: 
module sqlited is in file 'sqlited.d' which cannot be read (***)

import path[0] = C:\D\dmd2\src\phobos
import path[1] = C:\D\dmd2\src\druntime\import
import path[2] = 
C:\Users\Alfred\AppData\Roaming\dub\packages\colorize-master\colorize\source
import path[3] = 
C:\Users\Alfred\AppData\Roaming\dub\packages\sqlite-d-master\sqlite-d
import path[4] = 
C:\Users\Alfred\AppData\Roaming\dub\packages\d2sqlite3-master\d2sqlite3\source

import path[5] = C:\D\dmd2\windows\bin\src\phobos
import path[6] = C:\D\dmd2\windows\bin\src\druntime\import
error: the process (dmd) has returned the signal 1
C:...\Projects\temp2.d has not been compiled

I'm stucked. Please, can you help me out ?

Cheers, AN


module test;

//  Copyright Stefan Koch 2015 - 2018.
// Distributed under the Boost Software License, Version 1.0.
//(See accompanying file LICENSE.md or copy at
//  http://www.boost.org/LICENSE_1_0.txt)

import sqlited;
import misc;
import sqlstuff;

static immutable long_create_table =
q{CREATE TABLE `hey`INTEGER,
`Field2`INTEGER
)};
static immutable test_s3db = 
cast(immutable)Database(cast(immutable ubyte[]) 
import("test.s3db"));
static immutable Database.MasterTableSchema[] schemas = 
readRows!(r => 
r.deserialize!(Database.MasterTableSchema))(test_s3db.rootPage, 
test_s3db.pages);

static assert(schemas[2].sql==long_create_table);

import frail_sql_parser;

static assert (parseCreateTable(
q{CREATE TABLE spatial_ref_sys (
srid INTEGER NOT NULL PRIMARY KEY,
auth_name VARCHAR(256) NOT NULL,
auth_srid INTEGER NOT NULL,
ref_sys_name VARCHAR(256),
proj4text VARCHAR(2048) NOT NULL)}
) == TableInfo("spatial_ref_sys", [
ColumInfo("srid", "INTEGER", true, true),
ColumInfo("auth_name", "VARCHAR(256)", false, true),
ColumInfo("auth_srid", "INTEGER", false, true),
ColumInfo("ref_sys_name","VARCHAR(256)",false),
ColumInfo("proj4text","VARCHAR(2048)", false, true),
])
);
static assert(parseCreateTable(long_create_table) == 
TableInfo("hey", "INTEGER"), ColumInfo("Field2", "INTEGER")]));


static assert(parseCreateTable(
q{CREATE TABLE Towns (
PK_UID INTEGER PRIMARY KEY AUTOINCREMENT,
Name TEXT,
Peoples INTEGER,
LocalCounc INTEGER,
County INTEGER,
Region INTEGER, "Geometry" POINT)
}
) == TableInfo("Towns", [
ColumInfo("PK_UID", "INTEGER", true, false, false, true),
ColumInfo("Name", "TEXT"),
ColumInfo("Peoples", "INTEGER"),
ColumInfo("LocalCounc", "INTEGER"),
ColumInfo("County", "INTEGER"),
ColumInfo("Region", "INTEGER"),
ColumInfo("Geometry", "POINT")
])
);

Function Proposal: std.algorithm.iteration : cumulativeSum

[e-y-e via Digitalmars-d]

===

TL;DR:
The proposed function takes an input range and an optional seed 
and provides an input range containing the intermediate results 
of the summation of the given range. As of 2.072 this behaviour 
can be emulated by cumulativeSum!((a, b) => a + b)(r, s), but 
cumulativeSum involves a specialization for accurate summation of 
floating point values and redirects to cumulativeFold for 
non-floating point values. The proposed function would be useful 
for those doing basic statistical analysis on data sets, but 
would also have applications in other fields. Please let me know 
in this thread whether you would have a use for this function (or 
if you think it should/shouldn't be in phobos)


===


I'd like to propose the function cumulativeFold as a new addition 
to std.algorithm.iteration. I have already opened a pull request 
[1] for this addition so the full implementation is available 
there. The function signatures are:


auto cumulativeSum(Range)(Range r)
if (isInputRange!Range && __traits(compiles, r.front + 
r.front))


auto cumulativeSum(Range, Seed)(Range r, Seed s)
if (isInputRange!Range && __traits(compiles, s = s + r.front))

The function returns an input range that contains the 
intermediate results of a summation on all of the elements of a 
given range. For more details see Prefix Sum [2].



My motivation for adding this function to phobos was originally 
that I came across a need for it. I was looking into genetic 
algorithms and I wanted to implement some variation of the 
Stochastic Universal Sampling [3] selection method, which 
requires the fitness values of the population to be sorted and 
then selected based on the cumulative sum up to that point. 
Phobos was the first place I looked to for an implementation of 
cumulativeSum, as I knew that it had an implementation of sum, 
and cumulativeSum is a great use of D's ranges that I assumed 
would be in phobos. I couldn't find it, but found cumulativeFold 
instead. However, from reading the docs on sum, I knew that sum 
was a specialization of fold for accurate floating point 
summation, and given that I would be summing floating point 
values it would be better if the algorithm I used also involved 
this type of specialization.



With the knowledge that cumulativeFold is now in phobos, I 
realized that this presented quite an obvious gap in this area of 
summation and reduction. This gap is best illustrated by this 
table:


  | Provides no intermediate results | Provides 
intermediate results
 
-|--|---

 Not  |  |
 specialized  |   fold   | 
cumulativeFold

 for accurate |  |
 summation|  |
 
-|--|---

 Specialized  |  |
 for accurate |sum   |
X

 summation|  |


So now what would people other than me use this function for, or 
in other words, why should it be in phobos? Firstly, from a 
purely logical point of view, cumulative sums can be a useful way 
of analysing data. Once the data can be converted into a 
cumulative sum, then it is trivial to know what the current 
running total is when consuming the data. IE rather than keeping 
state like so [trivial example]:


void displayDataset(Data)(Data d, double total)
{
double sum = 0.0;

while (true)
{
if (d.empty) break;
sum += d.front;
if (sum > total) break;
writeln("Data point: ", d.front, ", sum: ", sum);
d.popFront;
}
}

Range based code can now be written with ease to perform the same 
job:


void displayDataset(Data)(Data d, double total)
{
d
.zip(d.cumulativeSum)
.until!(t => t[1] > total)
.each!(t => writeln("Data point: ", t[0], ", sum:", 
t[1]));

}

Some other useful applications are:
 - Graphing an integral of a range of y values without 
calculating the actual integral.
 - Computing a series summation with increasing accuracy (a la 
Fourier).

 - Keeping a running mean of incoming data.


Thanks for reading if you got this far, let me know whether you 
love/hate the idea.

P.S: its late here so I may only be able to read/respond tomorrow.

===

[1] https://github.com/dlang/phobos/pull/4881
[2] https://en.wikipedia.org/wiki/Prefix_sum
[3] https://en.wikipedia.org/wiki/Stochastic_universal_sampling

Re: strange -fPIC compilation error

[Lodovico Giaretta via Digitalmars-d-learn]

On Tuesday, 1 November 2016 at 18:13:32 UTC, TheGag96 wrote:
On Monday, 31 October 2016 at 07:16:50 UTC, Sebastien Alaiwan 
wrote:

Hello,
From GCC 6.2, -fpie is becoming the default setting at compile 
and at link time.
As dmd uses GCC to link, now the code needs to be compiled 
with a special option.
Which means you need, at the moment, to add the following 
options to your dmd.conf:

 -defaultlib=libphobos2.so -fPIC
(the change from GCC is related to security and address space 
randomization).


So does this mean it's now impossible to compile statically 
until this gets fixed?


It's impossible with the default `libphobos2.a`. I didn't try, 
but I'm quite confident that if you clone the Phobos repository 
and rebuild the library yourself with -fPIC, you can then link it 
statically to PIE executables.

Re: CTFE Status

[Nordlöw via Digitalmars-d]

On Tuesday, 1 November 2016 at 19:28:03 UTC, Stefan Koch wrote:

Now a phobos unittest miscompiles :(

Again passing the unittests does not mean too much.
I just means I bail out before I generate invalid code :)


Keep up!

[Issue 16651] atomicOp!"-="(ulong, uint) = wrong result/codegen

[via Digitalmars-d-bugs]

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

safety0ff.bugz  changed:

   What|Removed |Added

 CC||safety0ff.b...@gmail.com

--- Comment #2 from safety0ff.bugz  ---
(In reply to ag0aep6g from comment #1)
> 
> Looks like a bug in druntime code (core.atomic) rather than dmd.

Yup, atomicFetchSub [1] doesn't widen the modifier before negating it.
This is necessary when the modifier is unsigned and narrower than the value's
type.


[1] https://github.com/dlang/druntime/blob/master/src/core/atomic.d#L684

--

Re: Benchmarking Time Unit

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/1/16 4:19 PM, Nordlöw wrote:

On Tuesday, 1 November 2016 at 18:39:01 UTC, Jonathan M Davis wrote:

Alternatively, you can always do something like

immutable before = MonoTime.currTime();
// do stuf...
immutable after = MonoTime.currTime();
Duration timeSpent = after - before;


MonoTime has about 5-10 % fluctuations on my laptop. Is this as good as
it gets?


This is not clear. What is this a percentage of?

If you are hoping that you run code and the total time taken is going to 
be consistent within a few nanoseconds, then I'm sorry to say it's not 
going to happen. If you mean it's varying by 5-10 seconds, then this is 
a different story, but still could be expected.


MonoTime is going to be very accurate. What isn't true is that on a 
laptop being used with a non-realtime OS, you will have exactly 
consistent results for userspace programs.


As Jonathan mentioned, the way around this is to average several runs of 
the same test.


-Steve

[Issue 8799] Give example of Tuple mapped to a function

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/e0ca51f9f01cc2a089907b09f9e0ed3dd15df643
fix issue 8799

https://github.com/dlang/phobos/commit/c77869f22e61919a9f3d617d7d5d2254641aa7e4
Merge pull request #4882 from somzzz/issue_8799

fix issue 8799

--

Re: Linux Kernel in D?

[Wild via Digitalmars-d]

On Tuesday, 1 November 2016 at 20:11:13 UTC, Karabuta wrote:

On Tuesday, 1 November 2016 at 13:41:04 UTC, Wild wrote:

On Tuesday, 1 November 2016 at 12:12:29 UTC, Heisenberg wrote:
Just an idea. Do you think it would have any advantage 
compared to the one that is written in C?


It is better to instead design a new kernel from scratch, and 
structure everything
in a way that seems more logical for D code. This is what I 
target with my kernel
PowerNex (The current code structure is horrible, I'm 
currently planning to fix

it so it matches the D style).


Really excited to see that you plan to improve the code style 
to fit D's. I glanced through your code and that was the only 
killer issue (IMO).


I realized that it was too different from the code style that most
D people use and I don't really know if I liked that style.

Hopefully the new code style will fit the project better.
https://github.com/Vild/PowerNex/blob/master/Codestyle.org

Re: Benchmarking Time Unit

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, November 01, 2016 20:21:32 Nordlöw via Digitalmars-d-learn 
wrote:
> On Tuesday, 1 November 2016 at 20:19:31 UTC, Nordlöw wrote:
> > MonoTime has about 5-10 % fluctuations on my laptop. Is this as
> > good as it gets?
>
> Is
>
> https://dlang.org/phobos/core_time.html#.ClockType.threadCPUTime
>
> what I should use if I'm on Linux?

The default (ClockType.normal) unless you have a really good reason to do
otherwise. And if you're most worried about having high precision (as is
presumably the case if you're benchmarking), ClockType.normal is the best
you get on Linux. You can use ClockType.precise, but on Linux, it's the same
as ClockType.normal. It's just FreeBSD that has a more precise clock. And
really, ClockType.normal is plenty precise. IIRC, it's usually about a tick
per microsecond on Linux.

- Jonathan M Davis

Re: Benchmarking Time Unit

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, November 01, 2016 20:19:31 Nordlöw via Digitalmars-d-learn 
wrote:
> On Tuesday, 1 November 2016 at 18:39:01 UTC, Jonathan M Davis
>
> wrote:
> > Alternatively, you can always do something like
> >
> > immutable before = MonoTime.currTime();
> > // do stuf...
> > immutable after = MonoTime.currTime();
> > Duration timeSpent = after - before;
>
> MonoTime has about 5-10 % fluctuations on my laptop. Is this as
> good as it gets?

How precise it is depends on your system. MonoTime uses the system's
monotonic clock at whatever precision it has. And even if it's perfectly
precise, you're going to see fluctuations in how long it takes your code to
run, since it's not the only thing running on your computer. That's part of
why std.datetime.benchmark runs the function over and over again rather
than only running it only once. That way, you get the average performance
rather than the performance for a single run.

- Jonathan m Davis

Re: Benchmarking Time Unit

[Nordlöw via Digitalmars-d-learn]

On Tuesday, 1 November 2016 at 20:19:31 UTC, Nordlöw wrote:
MonoTime has about 5-10 % fluctuations on my laptop. Is this as 
good as it gets?


Is

https://dlang.org/phobos/core_time.html#.ClockType.threadCPUTime

what I should use if I'm on Linux?

Re: Benchmarking Time Unit

[Nordlöw via Digitalmars-d-learn]

On Tuesday, 1 November 2016 at 18:39:01 UTC, Jonathan M Davis 
wrote:

Alternatively, you can always do something like

immutable before = MonoTime.currTime();
// do stuf...
immutable after = MonoTime.currTime();
Duration timeSpent = after - before;


MonoTime has about 5-10 % fluctuations on my laptop. Is this as 
good as it gets?

Re: Linux Kernel in D?

[Karabuta via Digitalmars-d]

On Tuesday, 1 November 2016 at 13:41:04 UTC, Wild wrote:

On Tuesday, 1 November 2016 at 12:12:29 UTC, Heisenberg wrote:
Just an idea. Do you think it would have any advantage 
compared to the one that is written in C?


It is better to instead design a new kernel from scratch, and 
structure everything
in a way that seems more logical for D code. This is what I 
target with my kernel
PowerNex (The current code structure is horrible, I'm currently 
planning to fix

it so it matches the D style).


Really excited to see that you plan to improve the code style to 
fit D's. I glanced through your code and that was the only killer 
issue (IMO).

Re: strange -fPIC compilation error

[Charles Hixson via Digitalmars-d-learn]

On 11/01/2016 10:34 AM, bachmeier via Digitalmars-d-learn wrote:

On Tuesday, 1 November 2016 at 17:23:54 UTC, Charles Hixson wrote:

On 11/01/2016 12:52 AM, Nordlöw via Digitalmars-d-learn wrote:

On Tuesday, 1 November 2016 at 07:15:19 UTC, Mike Parker wrote:

but
dmd -defaultlib=libphobos2.so -fPIC test.d
works.  It shouldn't be required (as in the default /etc/dmd.conf 
should handle it correctly, but I can deal with it now.


Can this be fed as parameters to the DMD call (programmatically) 
instead of manual editing of dmd.conf?



I did feed it into the dmd call programmatically.  Thus:
 dmd -defaultlib=libphobos2.so -fPIC test.d

I'm reluctant to edit the dmd.conf file as I don't really understand 
the syntax...and I have to be root to do the editing.


https://dlang.org/dmd-linux.html#dmd-conf

You can copy dmd.conf to the current working directory and try out 
changes there. That will only affect the current program. Then you can 
move it to your home directory.


I'll probably do that eventually...but for now I'm just pasting a 
comment at the start of each file that tells how to compile it, e.g.:

//ldc2 -Dddocs -c msg.d<<--no documentation generated
//dmd -Dddocs -c msg.d
//rdmd -main -Dddocs -unittest -defaultlib=libphobos2.so -fPIC msg.d

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Tuesday, 1 November 2016 at 15:50:06 UTC, Stefan Koch wrote:


Very recent news:
 NEW CTFE PASSES THE DRUNTIME UNITESTS


Now a phobos unittest miscompiles :(

Again passing the unittests does not mean too much.
I just means I bail out before I generate invalid code :)

Re: Should I prefer immutable or const?

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, November 01, 2016 17:52:56 Nordlöw via Digitalmars-d-learn 
wrote:
> Should I always, when possible, prefer `immutable` over `const`?
>
> And does `immutable` increase the possibility of the compiler
> doing optimizations, such as common subexpression elimination?
>
> Or can the compiler infer `const` declarations to also be
> `immutable`?

That's not really something that can have a generally applicable answer.
const and immutable are similar but also very different, and which is
appropriate depends entirely on what you're doing.

If you're dealing with built-in value types, I would expect the code to be
100% identical, so whether you use const or immutable is a matter of
preference. I tend to use immutable, since it clearly indicates that the
value will never change, whereas for some types, const can change thanks to
another reference to the same data, but it doesn't actually matter for a
value type.

For reference types, if you want to use immutable, you're constructing the
object as immutable and using it as immutable everywhere. It's not a
temporary thing. In contrast, const could refer to either an immutable or
mutable object, so all you're really saying is that that code won't mutate
the object, not that its value won't change. It really doesn't make sense to
use const if you're intending that the object always be const. If you're
doing that, you might as well make it immutable, since you get implicit
sharing out of it, and the compiler can do optmizations based on immutable
that it can't do based on const, because it knows that the immutable object
will never change, whereas for a const reference to an object, it just knows
that _that_ code can't change it through _that_ reference. The same function
could very well be mutating that object via a mutable reference to the same
data.

Also, _very_ little in the way of optimizations can be done based on const,
so if you're looking to get the compiler to optimize stuff better, then
immutable is unquestionably better than const, but it does mean that that
data can never be mutated.

Really, const is for the cases where you want to accept mutable, const, and
immutable data without necessarily templatizing your function, and you don't
want the function to mutate the data. So, it's for passing off data to be
looked at but not mutated and not really for storing it. You _can_ store it
as const, but there's pretty much always going to be a mutable reference to
that data somewhere else, otherwise there wasn't much point in using const
over immutable.

Also, keep in mind that const is annoyingly restrictive in D, because it's
transitive and has no backdoors that aren't undefined behavior (unlike C++),
so slapping const on a lot of stuff is going to tend to prevent you from
doing useful things. In general, I'd expect stuff to be either mutable or
immutable and then primarily use templates to share code with const only
being used sparingly, but some folks do try and use const a fair bit -
especially when first coming from C++.

So, hopefully that's at least somewhat helpful, but to a great extent,
whether const makes any sense is highly dependent on what your code is
doing. And aside from specially designed types, immutable isn't likely to be
used much outside of value types of arrays, because not being able to ever
mutate under any circumstances doesn't usually work well with types unless
they were designed with that in mind.

- Jonathan M Davis

Re: Should I prefer immutable or const?

[ag0aep6g via Digitalmars-d-learn]

On 11/01/2016 06:52 PM, Nordlöw wrote:

Should I always, when possible, prefer `immutable` over `const`?


I'd say: prefer immutable.


And does `immutable` increase the possibility of the compiler doing
optimizations, such as common subexpression elimination?

Or can the compiler infer `const` declarations to also be `immutable`?


A `const int x = 42;` is effectively immutable, but its type is 
const(int), not immutable(int). A compiler may be smart enough to treat 
it as immutable with regards to optimizations, but I wouldn't expect dmd 
to be that smart, or only in very simple cases. ldc and gdc are probably 
better at it.


However, for function overloads and such the compiler must consider the 
type, not any additional information it has about the data. So if some 
function has an optimized overload for immutable, that can only be taken 
when you type out "immutable".

Re: Benchmarking Time Unit

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, November 01, 2016 16:53:51 Nordlöw via Digitalmars-d-learn 
wrote:
> Which way of measuring time in std.datetime should I used if I
> want to benchmark a function by the amount of time spent in the
> current thread, not wall-clock time?

That's what std.datetime.benchmark is for, though unfortunately, it still
uses core.time.TickDuration rather using core.time.MonoTime and
core.time.Duration.

Alternatively, you can always do something like

immutable before = MonoTime.currTime();
// do stuf...
immutable after = MonoTime.currTime();
Duration timeSpent = after - before;

though that just times how long something took rather than running it over
and over again like benchmark does.

I really need to get replacements for the TickDuration-related stuff in
std.datetime into std.experimental so that we can move towards replacing it
and finally getting rid of TickDuration, but I haven't gotten to it yet.

- Jonathan M Davis

Re: Can someone please explain why the following assertion fails?

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/1/16 10:08 AM, Steven Schveighoffer wrote:

On 10/31/16 3:24 PM, Ali Çehreli wrote:

Because it considers the .ptr property of arrays as well:



[snip]

return bytesHash(bytes.ptr, bytes.length, seed);// <-- HERE


bytesHash shouldn't use the pointer value in any way, it should just use
the pointer to look at the bytes.


And the issue is not there it is simpler than that. Here is the entire 
definition of hashOf 
(https://github.com/dlang/druntime/blob/master/src/object.d#L3176):


size_t hashOf(T)(auto ref T arg, size_t seed = 0)
{
import core.internal.hash;
return core.internal.hash.hashOf((cast(void*))[0 .. T.sizeof], 
seed);

}

Note that if arg is a string, then it's going to take the hash of the 
bytes that define the dynamic array pointer and length. Not at all what 
the user is expecting. Would be even more surprising for an object 
reference or pointer.


I'm not sure what the bug is here. It's quite possible the intention is 
to provide a low-level primitive that avoids all hashing customization.


However, to have it called hashOf, and then have another internal 
function called hashOf that does something different, is quite 
surprising and error prone. Indeed, I think Ali did not realize where 
the definition of hashOf was coming from.


At the very least, the documentation needs updating.

-Steve

Re: strange -fPIC compilation error

[TheGag96 via Digitalmars-d-learn]

On Monday, 31 October 2016 at 07:16:50 UTC, Sebastien Alaiwan 
wrote:

Hello,
From GCC 6.2, -fpie is becoming the default setting at compile 
and at link time.
As dmd uses GCC to link, now the code needs to be compiled with 
a special option.
Which means you need, at the moment, to add the following 
options to your dmd.conf:

 -defaultlib=libphobos2.so -fPIC
(the change from GCC is related to security and address space 
randomization).


So does this mean it's now impossible to compile statically until 
this gets fixed?

Re: newbie problem with nothrow

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/1/16 12:24 PM, Jonathan M Davis via Digitalmars-d-learn wrote:

On Tuesday, November 01, 2016 12:19:11 Steven Schveighoffer via Digitalmars-
d-learn wrote:

On 11/1/16 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote:

On Tuesday, November 01, 2016 10:57:38 Steven Schveighoffer via

Is there not some assumeNoThrow wrapper somewhere?


Someone added assemWontThrow to std.exception semi-recently, but I'd be
very surprised if it didn't incur performance overhead such that I'd
just as soon use an explicit try-catch and be done with it.


The function I'm imagining shouldn't add any overhead...


assumeWontThrow uses lazy to do what it does (and I'm not sure that there's
any other way to do it other than string mixins), and as I understand it,
lazy isn't exactly efficient. Given that it always calls the resulting
delegate though, the optimizer may be able to remove the extra cost.


I was thinking something like this:

auto assumeNoThrow(alias foo, Args...)(Args args) nothrow
{
   try
   {
  return foo(args);
   }
   catch(Exception e)
   {
  throw new Error("foo should not have done that!");
   }
}

-Steve

Re: Can someone please explain why the following assertion fails?

[Gary Willoughby via Digitalmars-d-learn]

On Tuesday, 1 November 2016 at 14:06:08 UTC, Steven Schveighoffer 
wrote:

On 10/31/16 3:08 PM, Gary Willoughby wrote:

Can someone please explain why the following assertion fails?

import std.stdio;
import std.conv;

void main(string[] args)
{
auto x = 1;

assert(hashOf(x.to!(string)) == hashOf(x.to!(string)));
}

Thanks.


IMO, it shouldn't. A string's "value" has nothing to do with 
it's location.


-Steve


It definitely is surprising. I'll raise an issue and see what 
others think.


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

[Issue 16654] New: hashOf returns different hashes for the same string value

[via Digitalmars-d-bugs]

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

  Issue ID: 16654
   Summary: hashOf returns different hashes for the same string
value
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: d...@nomad.so

The following assert fails:

import std.stdio;
import std.conv;

void main(string[] args)
{
auto x = 1;

assert(hashOf(x.to!(string)) == hashOf(x.to!(string)));
}

This is because numeric values of the pointers to the strings are being
included in the hash calculation.

Discussion: http://forum.dlang.org/post/gdtaqdooaknhsmcow...@forum.dlang.org

--

[Issue 16293] hashOf should be @nogc when it can be

[via Digitalmars-d-bugs]

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

Gary Willoughby  changed:

   What|Removed |Added

 CC||d...@nomad.so

--- Comment #1 from Gary Willoughby  ---
This seems to have been done here: https://github.com/dlang/druntime/pull/1624

--

Re: Got a post for the D Blog?

[bachmeier via Digitalmars-d-announce]

On Tuesday, 1 November 2016 at 06:36:15 UTC, Stefan Koch wrote:

On Tuesday, 1 November 2016 at 06:23:29 UTC, Mike Parker wrote:
On Monday, 31 October 2016 at 20:29:13 UTC, Jacob Carlborg 
wrote:




Would it be interesting to have a blog post about implement 
support for Objective-C in D? That would be very technical 
and quite low level.


Absolutely!


I could write something about the CTFE engine.
And how I plan to beat the llvm jit :)


I'd be very interested in such a post. And it would provide some 
good publicity for D.

Should I prefer immutable or const?

[Nordlöw via Digitalmars-d-learn]

Should I always, when possible, prefer `immutable` over `const`?

And does `immutable` increase the possibility of the compiler 
doing optimizations, such as common subexpression elimination?


Or can the compiler infer `const` declarations to also be 
`immutable`?

Re: Linux Kernel in D?

[bachmeier via Digitalmars-d]

On Tuesday, 1 November 2016 at 16:22:58 UTC, Andrei Alexandrescu 
wrote:


As an intellectual exercise, D's safety would help but at this 
point impart little advantage; the kernel has reached good 
stability and safety bugs are few and far across. This trend is 
likely for the foreseeable future.


It would not be unreasonable to write new code in D. It's not as 
though safety is the only advantage that D brings to the table. 
This would have to be a fork, and wouldn't likely be of much 
interest to most Linux users/developers, but maybe there is room 
to optimize the kernel for a specific application that is also 
written in D. Using D rather than C would greatly reduce the cost 
of getting into kernel development.

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Tuesday, 1 November 2016 at 16:44:14 UTC, Nordlöw wrote:

On Monday, 31 October 2016 at 13:29:01 UTC, Stefan Koch wrote:

These are the constructs that will work.

- foreach on static arrays strings and range-foreach  (those 
kinds (0 .. 64)).

- switches (even deeply nested ones)
- for and while loops
- ternary expressions (? :)
- if and else statements (as long as you don't use && and || )
- lables and gotos
- arithmetic expressions as well as post and pre increment and 
decrement


Constructs that will not work (but are actively worked on)

- assignment to static array cells
- long ulong arithmetic.
- function calls
- dynamic arrays and slices
- pointers
- structs
- && and ||
- sliceing

Constructs that will not work and are futher down the list.

- classes
- closures
- boundschecks
- asserts


Do all these work in current implementation?


Yes of they do!

There is a lot of work behind the implementation!
I intend to keep the current implemntation around as a fallback.
For things that are used rarely.
like floating point and others :)

Re: strange -fPIC compilation error

[bachmeier via Digitalmars-d-learn]

On Tuesday, 1 November 2016 at 17:23:54 UTC, Charles Hixson wrote:

On 11/01/2016 12:52 AM, Nordlöw via Digitalmars-d-learn wrote:

On Tuesday, 1 November 2016 at 07:15:19 UTC, Mike Parker wrote:

but
dmd -defaultlib=libphobos2.so -fPIC test.d
works.  It shouldn't be required (as in the default 
/etc/dmd.conf should handle it correctly, but I can deal 
with it now.


Can this be fed as parameters to the DMD call 
(programmatically) instead of manual editing of dmd.conf?



I did feed it into the dmd call programmatically.  Thus:
 dmd -defaultlib=libphobos2.so -fPIC test.d

I'm reluctant to edit the dmd.conf file as I don't really 
understand the syntax...and I have to be root to do the editing.


https://dlang.org/dmd-linux.html#dmd-conf

You can copy dmd.conf to the current working directory and try 
out changes there. That will only affect the current program. 
Then you can move it to your home directory.

[Issue 16419] issue with ndslice.slice toHash

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 16609] std.experimental.ndslice.slice issues warnings when building Phobos

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/00ce4ed3a114b42f9dd30015b20c4b795fd61360
Merge pull request #4865 from 9il/tohash

fix issue 16609

--

[Issue 16419] issue with ndslice.slice toHash

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/52767078ccd2544f6ae8a5def0f75eb569465f77
fix issue 16419

--

[Issue 16609] std.experimental.ndslice.slice issues warnings when building Phobos

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED

--

Re: strange -fPIC compilation error

[Charles Hixson via Digitalmars-d-learn]

On 11/01/2016 12:52 AM, Nordlöw via Digitalmars-d-learn wrote:

On Tuesday, 1 November 2016 at 07:15:19 UTC, Mike Parker wrote:

but
dmd -defaultlib=libphobos2.so -fPIC test.d
works.  It shouldn't be required (as in the default /etc/dmd.conf 
should handle it correctly, but I can deal with it now.


Can this be fed as parameters to the DMD call (programmatically) 
instead of manual editing of dmd.conf?



I did feed it into the dmd call programmatically.  Thus:
 dmd -defaultlib=libphobos2.so -fPIC test.d

I'm reluctant to edit the dmd.conf file as I don't really understand the 
syntax...and I have to be root to do the editing.

Re: SQLite

[Alfred Newman via Digitalmars-d-learn]

On Friday, 21 October 2016 at 10:50:30 UTC, Vadim Lopatin wrote:
On Wednesday, 19 October 2016 at 16:01:37 UTC, Alfred Newman 
wrote:

Hello,

I am trying to handle a SQLite3 table with D. During my 
researchs, I discovered the lib 
https://dlang.org/phobos/etc_c_sqlite3.html.


However, for any reason, there is no code snippets or sample 
codes available there. So, I am stucked.


I have the following sample structure table:
   sql = "INSERT INTO COMPANY (ID,NAME,AGE,ADDRESS,SALARY) "  \
 "VALUES (1, 'Paul', 32, 'California', 2.00 ); " \
 "INSERT INTO COMPANY (ID,NAME,AGE,ADDRESS,SALARY) "  \
 "VALUES (2, 'Allen', 25, 'Texas', 15000.00 ); " \
 "INSERT INTO COMPANY (ID,NAME,AGE,ADDRESS,SALARY)" \
 "VALUES (3, 'Teddy', 23, 'Norway', 2.00 );" \
 "INSERT INTO COMPANY (ID,NAME,AGE,ADDRESS,SALARY)" \
 "VALUES (4, 'Mark', 25, 'Rich-Mond ', 65000.00 );";

Can you pls provide a code snippet or some hints to the 
following job:

- Create a table with the layout above
- Iterate through the records given a basic SELECT WHERE Query

Thanks in advance, AN


Snippet how to do it using DDBC library 
https://github.com/buggins/ddbc


import ddbc;

string url = "sqlite:testdb.sqlite";
// creating Connection
auto conn = createConnection(url);
scope(exit) conn.close();
// creating Statement
auto stmt = conn.createStatement();
scope(exit) stmt.close();
// execute simple queries to create and fill table
stmt.executeUpdate("CREATE TABLE COMPANY (ID int, NAME 
varchar, AGE int,ADDRESS varchar, SALARY double)");

string[] statements = [
"INSERT INTO COMPANY (ID,NAME,AGE,ADDRESS,SALARY) 
VALUES (1, 'Paul', 32, 'California', 2.00 )",
"INSERT INTO COMPANY (ID,NAME,AGE,ADDRESS,SALARY) 
VALUES (2, 'Allen', 25, 'Texas', 15000.00 )",
"INSERT INTO COMPANY (ID,NAME,AGE,ADDRESS,SALARY) 
VALUES (3, 'Teddy', 23, 'Norway', 2.00 )"

];
foreach(sql; statements)
stmt.executeUpdate(sql);


Hello Vadim,

I used dub to register DDBC. After that, I tried to do some 
tests, but I received the following error:


Fetching ddbc ~master...
Placing ddbc ~master to 
C:\Users\Alfred\AppData\Roaming\dub\packages\...

Performing "release" build using dmd for x86.
ddbc ~master: building configuration "full"...
Copying files for ddbc...

compiling C:\...\Projects\stingray.d

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
sqlite3.lib
 Warning 2: File Not Found sqlite3.lib
C:\Users\Alfred\AppData\Roaming\dub\packages\ddbc-master\ddbc\lib\ddbc.lib(mysqlddbc)
 Error 42: Symbol Undefined _D5mysql10connection12__ModuleInfoZ
C:\Users\Alfred\AppData\Roaming\dub\packages\ddbc-master\ddbc\lib\ddbc.lib(pgsqlddbc)
 Error 42: Symbol Undefined _D8derelict2pq2pq12__ModuleInfoZ
C:\Users\Alfred\AppData\Roaming\dub\packages\ddbc-master\ddbc\lib\ddbc.lib(sqliteddbc)
 Error 42: Symbol Undefined _sqlite3_data_count
...
_D5mysql8protocol8commands7Command11__xopEqualsFKxS5mysql8protocol8commands7CommandKxS5mysql8protocol8commands7CommandZb
--- errorlevel 67
error: the process (dmd) has returned the signal 67
C:\...\Projects\stingray.d has not been compiled

Notice that sqlite3.lib is located at my folder 
C:\Users\Alfred\AppData\Roaming\dub\packages\ddbc-master\ddbc\libs\win64


What am I doing wrong ?

Cheers

Benchmarking Time Unit

[Nordlöw via Digitalmars-d-learn]

Which way of measuring time in std.datetime should I used if I 
want to benchmark a function by the amount of time spent in the 
current thread, not wall-clock time?

Re: CTFE Status

[Nordlöw via Digitalmars-d]

On Tuesday, 1 November 2016 at 15:50:06 UTC, Stefan Koch wrote:

Very recent news:
 NEW CTFE PASSES THE DRUNTIME UNITESTS


Great work!

Re: Release D 2.072.0

[Andrei Alexandrescu via Digitalmars-d-announce]

On 11/01/2016 11:41 AM, Johan Engelen wrote:

On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:

Glad to announce D 2.072.0.


DMD 2.072.0 miscompiles/uncovers a bug in LDC, so I switched back to DMD
2.071.2 for CI testing. :(


Is there somebody working on that bug? Thanks. -- Andrei

Re: CTFE Status

[Nordlöw via Digitalmars-d]

On Monday, 31 October 2016 at 13:29:01 UTC, Stefan Koch wrote:

These are the constructs that will work.

- foreach on static arrays strings and range-foreach  (those 
kinds (0 .. 64)).

- switches (even deeply nested ones)
- for and while loops
- ternary expressions (? :)
- if and else statements (as long as you don't use && and || )
- lables and gotos
- arithmetic expressions as well as post and pre increment and 
decrement


Constructs that will not work (but are actively worked on)

- assignment to static array cells
- long ulong arithmetic.
- function calls
- dynamic arrays and slices
- pointers
- structs
- && and ||
- sliceing

Constructs that will not work and are futher down the list.

- classes
- closures
- boundschecks
- asserts


Do all these work in current implementation?

Re: CTFE Status

[Daniel Kozak via Digitalmars-d]

Dne 1.11.2016 v 16:50 Stefan Koch via Digitalmars-d napsal(a):


On Monday, 31 October 2016 at 20:49:58 UTC, Steven Schveighoffer wrote:

On 10/31/16 9:29 AM, Stefan Koch wrote:

Hi Guys, since I got a few complaints about giving minor status updates
in the announce group, I am opening this thread.

I will start with giving an overview of what works and what does not 
work.


Awesome work, I can't wait for efficient streamlined CTFE.

Note to those not aware, Stefan is working on replacing the CTFE 
engine in D with a bytecode generated one. So although he mentions 
things that "don't work", he's talking about them in the context of 
the new CTFE engine. Many of these things already work in current 
CTFE implementation.


-Steve


All of them work in current CTFE which is why the mark is quite high.

I am glad to hear you guys appriciate my work.
It does help a ton to hear it from time to time.


---

Very recent news:
 NEW CTFE PASSES THE DRUNTIME UNITESTS


This is so awesome, really good work :)

Re: newbie problem with nothrow

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, November 01, 2016 12:19:11 Steven Schveighoffer via Digitalmars-
d-learn wrote:
> On 11/1/16 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
> > On Tuesday, November 01, 2016 10:57:38 Steven Schveighoffer via
> >> Is there not some assumeNoThrow wrapper somewhere?
> >
> > Someone added assemWontThrow to std.exception semi-recently, but I'd be
> > very surprised if it didn't incur performance overhead such that I'd
> > just as soon use an explicit try-catch and be done with it.
>
> The function I'm imagining shouldn't add any overhead...

assumeWontThrow uses lazy to do what it does (and I'm not sure that there's
any other way to do it other than string mixins), and as I understand it,
lazy isn't exactly efficient. Given that it always calls the resulting
delegate though, the optimizer may be able to remove the extra cost.

- Jonathan M Davis

Re: Linux Kernel in D?

[Andrei Alexandrescu via Digitalmars-d]

On 11/01/2016 09:41 AM, Wild wrote:

On Tuesday, 1 November 2016 at 12:12:29 UTC, Heisenberg wrote:

Just an idea. Do you think it would have any advantage compared to the
one that is written in C?


I think it wouldn't really be worth it.


I tend to think the same but for different reasons. Currently the Linux 
kernel is a large mature product that has its own evolution. It would be 
very difficult to reimplement it from first principles in any other 
language and get a competitive, timely product.


As an intellectual exercise, D's safety would help but at this point 
impart little advantage; the kernel has reached good stability and 
safety bugs are few and far across. This trend is likely for the 
foreseeable future.


One thing where D would be able to help quite a bit more is code size. D 
has better abstraction abilities than C (or C++) and using those would 
allow eliminating a lot of subtle duplication in kernel code. 
Consequently we'd be looking at a lower bug rate, better maintainability 
etc. I estimate that a 25% reduction in LOC is easily attainable. 
However, the dynamics of large projects makes even this relatively high 
reduction of little value. You'd not be looking at enjoying 25% savings, 
but instead at rebuilding 75% of the project. Because of that, you'd 
need a reduction of one order of magnitude to make the alternative 
appealing.



Andrei

Re: newbie problem with nothrow

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/1/16 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote:

On Tuesday, November 01, 2016 10:57:38 Steven Schveighoffer via Digitalmars-
d-learn wrote:

On 10/31/16 6:29 PM, Jonathan M Davis via Digitalmars-d-learn wrote:

assert(0, "format threw when it shouldn't be possible.");


This turns into a non-printing seg fault when compiled in release mode.


I'm well aware of that, and I don't see that as a problem. A message might
be nice, but the key thing is that it kills the program if there's a
problem, and given Mike's point about the C layer, having it segfault is
potentially preferable to throwing an Error to kill the program.


I disagree that avoiding the message printing is not a problem. I have 
had the unpleasant experience of having a program that dies on the order 
of 1-2 weeks with "SegFault", without any way of instrumenting the 
failure (debugging not an option, doesn't fail on dev machine). Just a 
tiny hint of what the problem is, can save weeks if not months of searching.


A little while ago, I added an internal tool to both abort a program, 
and print a message (including file and line number) to druntime. It's 
not exactly public, but may be useful to expose. It should be callable 
from any location, including signal handlers.


https://github.com/dlang/druntime/blob/master/src/core/internal/abort.d


Is there not some assumeNoThrow wrapper somewhere?


Someone added assemWontThrow to std.exception semi-recently, but I'd be very
surprised if it didn't incur performance overhead such that I'd just as soon
use an explicit try-catch and be done with it.


The function I'm imagining shouldn't add any overhead...

-Steve

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Monday, 31 October 2016 at 20:49:58 UTC, Steven Schveighoffer 
wrote:

On 10/31/16 9:29 AM, Stefan Koch wrote:
Hi Guys, since I got a few complaints about giving minor 
status updates

in the announce group, I am opening this thread.

I will start with giving an overview of what works and what 
does not work.


Awesome work, I can't wait for efficient streamlined CTFE.

Note to those not aware, Stefan is working on replacing the 
CTFE engine in D with a bytecode generated one. So although he 
mentions things that "don't work", he's talking about them in 
the context of the new CTFE engine. Many of these things 
already work in current CTFE implementation.


-Steve


All of them work in current CTFE which is why the mark is quite 
high.


I am glad to hear you guys appriciate my work.
It does help a ton to hear it from time to time.


---

Very recent news:
 NEW CTFE PASSES THE DRUNTIME UNITESTS

Re: newbie problem with nothrow

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, November 01, 2016 10:57:38 Steven Schveighoffer via Digitalmars-
d-learn wrote:
> On 10/31/16 6:29 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
> > On Monday, October 31, 2016 22:20:59 Kapps via Digitalmars-d-learn 
wrote:
> >> Assuming you're sure it'll never throw. To enforce this, use try
> >> { } catch { throw new Error("blah"); }. You can still throw
> >> errors, just not exceptions (as errors are not meant to be
> >> caught).
> >
> > I always use assert(0). e.g.
> >
> > try
> >
> > return format("%s", 42);
> >
> > catch(Exception)
> >
> > assert(0, "format threw when it shouldn't be possible.");
>
> This turns into a non-printing seg fault when compiled in release mode.

I'm well aware of that, and I don't see that as a problem. A message might
be nice, but the key thing is that it kills the program if there's a
problem, and given Mike's point about the C layer, having it segfault is
potentially preferable to throwing an Error to kill the program.

> Is there not some assumeNoThrow wrapper somewhere?

Someone added assemWontThrow to std.exception semi-recently, but I'd be very
surprised if it didn't incur performance overhead such that I'd just as soon
use an explicit try-catch and be done with it.

- Jonathan M Davis

Re: Release D 2.072.0

[Johan Engelen via Digitalmars-d-announce]

On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:

Glad to announce D 2.072.0.


DMD 2.072.0 miscompiles/uncovers a bug in LDC, so I switched back 
to DMD 2.071.2 for CI testing. :(


-Johan

Re: Ever want to compile D on your Android phone? Well, now you can!

[Daniel9 via Digitalmars-d-announce]

On Sunday, 24 January 2016 at 15:12:30 UTC, Joakim wrote:
An alpha release of ldc, the llvm-based D compiler, for Android 
devices is now available.  It is best used with the excellent 
Termux app 
(https://play.google.com/store/apps/details?id=com.termux=en) and a bluetooth keyboard. ;) Updated test runners, that run most tests from the standard library on any Android device, are also available (results have been reported for everything from a TomTom BRIDGE GPS navigation device to a Huawei Watch):


https://github.com/joakim-noah/android/releases/tag/polish

You can install a test runner app or run a command-line binary.
 Please report your results in this thread in the ldc forum, 
which requires no registration, with the info and format 
requested there, particularly for Android 4.1 or earlier:


https://forum.dlang.org/thread/bafrkjfwmoyriyhmq...@forum.dlang.org

If you try out the native compiler, take a look at the README 
that comes with it for instructions.


If you have a D/OpenGL app you'd like to port to Android and 
submit to the Play Store, let me know if I can help with that 
process.


great, thanks))

Re: newbie problem with nothrow

[Steven Schveighoffer via Digitalmars-d-learn]

On 10/31/16 6:29 PM, Jonathan M Davis via Digitalmars-d-learn wrote:

On Monday, October 31, 2016 22:20:59 Kapps via Digitalmars-d-learn wrote:

Assuming you're sure it'll never throw. To enforce this, use try
{ } catch { throw new Error("blah"); }. You can still throw
errors, just not exceptions (as errors are not meant to be
caught).


I always use assert(0). e.g.

try
return format("%s", 42);
catch(Exception)
assert(0, "format threw when it shouldn't be possible.");


This turns into a non-printing seg fault when compiled in release mode.

Is there not some assumeNoThrow wrapper somewhere?

-Steve

Re: newbie problem with nothrow

[Daniel9 via Digitalmars-d-learn]

On Monday, 31 October 2016 at 22:29:19 UTC, Jonathan M Davis 
wrote:
On Monday, October 31, 2016 22:20:59 Kapps via 
Digitalmars-d-learn wrote:
Assuming you're sure it'll never throw. To enforce this, use 
try

{ } catch { throw new Error("blah"); }. You can still throw
errors, just not exceptions (as errors are not meant to be
caught).


I always use assert(0). e.g.

try
return format("%s", 42);
catch(Exception)
assert(0, "format threw when it shouldn't be possible.");

- Jonathan M Davis


have the same problem

Re: Can someone please explain why the following assertion fails?

[Steven Schveighoffer via Digitalmars-d-learn]

On 10/31/16 3:24 PM, Ali Çehreli wrote:

On 10/31/2016 12:08 PM, Gary Willoughby wrote:

Can someone please explain why the following assertion fails?

import std.stdio;
import std.conv;

void main(string[] args)
{
auto x = 1;

assert(hashOf(x.to!(string)) == hashOf(x.to!(string)));
}

Thanks.


Because it considers the .ptr property of arrays as well:


https://github.com/dlang/druntime/blob/master/src/core/internal/hash.d#L61

//dynamic array hash
size_t hashOf(T)(auto ref T val, size_t seed = 0)
if (!is(T == enum) && !is(T : typeof(null)) && is(T S: S[]) &&
!__traits(isStaticArray, T)
&& !is(T == struct) && !is(T == class) && !is(T == union))
{
alias ElementType = typeof(val[0]);
static if (is(ElementType == interface) || is(ElementType == class) ||
   ((is(ElementType == struct) || is(ElementType == union))
   && is(typeof(val[0].toHash()) == size_t)))
//class or interface array or struct array with toHash(); CTFE
depend on toHash() method
{
size_t hash = seed;
foreach (o; val)
{
hash = hashOf(o, hash);
}
return hash;
}
else static if (is(typeof(toUbyte(val)) == const(ubyte)[]))
//ubyteble array (arithmetic types and structs without toHash) CTFE
ready for arithmetic types and structs without reference fields
{
auto bytes = toUbyte(val);
return bytesHash(bytes.ptr, bytes.length, seed);// <-- HERE


bytesHash shouldn't use the pointer value in any way, it should just use 
the pointer to look at the bytes.


-Steve

Re: Can someone please explain why the following assertion fails?

[Steven Schveighoffer via Digitalmars-d-learn]

On 10/31/16 3:08 PM, Gary Willoughby wrote:

Can someone please explain why the following assertion fails?

import std.stdio;
import std.conv;

void main(string[] args)
{
auto x = 1;

assert(hashOf(x.to!(string)) == hashOf(x.to!(string)));
}

Thanks.


IMO, it shouldn't. A string's "value" has nothing to do with it's location.

-Steve

[Issue 8799] Give example of Tuple mapped to a function

[via Digitalmars-d-bugs]

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

--- Comment #3 from Lucia Cojocaru  ---
pull https://github.com/dlang/phobos/pull/4882

--

[Issue 16583] Static module ctor semantic proposition

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #3 from Steven Schveighoffer  ---
module bad;

int x;

static this()
{
  x = 42;
}

struct Type
{
   int foo() { return x;}
}

--

Re: Linux Kernel in D?

[Wild via Digitalmars-d]

On Tuesday, 1 November 2016 at 12:12:29 UTC, Heisenberg wrote:
Just an idea. Do you think it would have any advantage compared 
to the one that is written in C?


I think it wouldn't really be worth it. You have to make a custom 
runtime and
a custom standard library. Because most of the awesome D features 
are for the

standard library and not directly from the language itself.
Porting the Linux kernel to D language to fix a few bugs isn't 
really worth it,

if you have to implement all the stuff I mentioned.

It is better to instead design a new kernel from scratch, and 
structure everything
in a way that seems more logical for D code. This is what I 
target with my kernel
PowerNex (The current code structure is horrible, I'm currently 
planning to fix

it so it matches the D style).

Conclusion: Yes D features could probably fix bugs in the Linux 
kernel and make it
more safe, but you need to implement a lot of extra code just to 
be able to use

basic D features. So it wouldn't be worth it.

- Dan

Re: Ever want to compile D on your Android phone? Well, now you can!

[Steven Schveighoffer via Digitalmars-d-announce]

On 10/29/16 8:55 PM, rikki cattermole wrote:

On 30/10/2016 10:47 AM, Mergul wrote:

Application always crash when I'm using android_app.savedState.

if (state.savedState != null) {
// We are starting with a previous saved state; restore from it.
engine.state = *cast(saved_state*)state.savedState; //crash!
}



Don't compare against null using =, compare using is.

if (state.savedState !is null) {


android_app.savedState appears to be defined here:

https://github.com/joakim-noah/android/blob/polish/android_native_app_glue.d#L56

It's a void *. So comparing against null with != is identical to !is.

There are actually cases where comparing against null with != is valid, 
and what you want exactly (e.g. comparing a string to null to check for 
empty string).


In this case, fixing the comparison is not the answer. What is happening 
is one of several things:


1. I don't know what type `engine` is, so if it's a pointer, then 
dereferencing the state member may be the culprit if engine is invalid.
2. If state is a pointer, then you could be crashing at the if statement 
(unlikely).

3. state or state.savedState isn't being properly initialized.
4. Something else (e.g. code generation error). Hope it's not this one.

-Steve

Re: Release vibe.d 0.7.30

[Sönke Ludwig via Digitalmars-d-announce]

Am 01.11.2016 um 14:29 schrieb John Colvin:

On Tuesday, 1 November 2016 at 12:47:13 UTC, Jacob Carlborg wrote:

On 2016-11-01 12:20, Saurabh Das wrote:


How can I find out more information about the 'runApplication' change?
What does "slowly fading out" mean?


I think it should say something like: "slowly fading out the default
main". Instead of having vibe.d define the main function and having a
shared module constructor with all the setup, you can define your own
main function with all the setup and then call runApplication, which
basically contains the same logic as the main function defined by vibe.d.


Is "phasing" the word that's being looked for here? I.e. "slowly phasing
out the default main".


Yes that sounds better. I'll change it and complete that partial sentence.

Re: Release vibe.d 0.7.30

[Sönke Ludwig via Digitalmars-d-announce]

Am 01.11.2016 um 12:20 schrieb Saurabh Das:

On Tuesday, 1 November 2016 at 09:09:05 UTC, Saurabh Das wrote:

On Monday, 31 October 2016 at 20:30:22 UTC, Sönke Ludwig wrote:

[...]


I'm going to try this out today! :)


How can I find out more information about the 'runApplication' change?
What does "slowly fading out" mean?


A summary would be:

runApplication does the same as runEventLoop, plus performing command 
line finalization and privilege lowering. This is the same that 
VibeDefaultMain otherwise does, with the only difference that it is 
invoked with an explicit function call.

Re: Release vibe.d 0.7.30

[John Colvin via Digitalmars-d-announce]

On Tuesday, 1 November 2016 at 12:47:13 UTC, Jacob Carlborg wrote:

On 2016-11-01 12:20, Saurabh Das wrote:

How can I find out more information about the 'runApplication' 
change?

What does "slowly fading out" mean?


I think it should say something like: "slowly fading out the 
default main". Instead of having vibe.d define the main 
function and having a shared module constructor with all the 
setup, you can define your own main function with all the setup 
and then call runApplication, which basically contains the same 
logic as the main function defined by vibe.d.


Is "phasing" the word that's being looked for here? I.e. "slowly 
phasing out the default main".

[Issue 16651] atomicOp!"-="(ulong, uint) = wrong result/codegen

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com
  Component|dmd |druntime
   Hardware|x86_64  |All
 OS|Windows |All

--- Comment #1 from ag0ae...@gmail.com ---
Same happens with -m32 and smaller types:


void main()
{
import std.stdio: writeln;
import core.atomic  : atomicOp;

shared uint foo = 2;
ubyte bar = 1;
atomicOp!"-="( foo, bar );
writeln( "foo = ", foo );// foo = 257
}


Also happens on Linux.

Looks like a bug in druntime code (core.atomic) rather than dmd. I think it
works with LDC because they've added a path of their own to druntime [1].


[1]
https://github.com/ldc-developers/druntime/blob/049b8efdf0daebcc1cfe690c5cf7585125c1ff72/src/core/atomic.d#L177

--

Re: Linux Kernel in D?

[Satoshi via Digitalmars-d]

On Tuesday, 1 November 2016 at 12:12:29 UTC, Heisenberg wrote:
Just an idea. Do you think it would have any advantage compared 
to the one that is written in C?


Look at https://github.com/Rikarin/Trinix for example

Re: Release vibe.d 0.7.30

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-11-01 13:47, Jacob Carlborg wrote:

On 2016-11-01 12:20, Saurabh Das wrote:


How can I find out more information about the 'runApplication' change?
What does "slowly fading out" mean?


I think it should say something like: "slowly fading out the default
main". Instead of having vibe.d define the main function and having a
shared module constructor with all the setup, you can define your own
main function with all the setup and then call runApplication, which
basically contains the same logic as the main function defined by vibe.d.


For reference, here's the commit that introduced the change: 
https://github.com/rejectedsoftware/vibe.d/commit/f7ba59a6c80dc85882654138087bad579480cadf


--
/Jacob Carlborg

Re: Release vibe.d 0.7.30

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-11-01 12:20, Saurabh Das wrote:


How can I find out more information about the 'runApplication' change?
What does "slowly fading out" mean?


I think it should say something like: "slowly fading out the default 
main". Instead of having vibe.d define the main function and having a 
shared module constructor with all the setup, you can define your own 
main function with all the setup and then call runApplication, which 
basically contains the same logic as the main function defined by vibe.d.


--
/Jacob Carlborg

Re: Linux Kernel in D?

[cym13 via Digitalmars-d]

On Tuesday, 1 November 2016 at 12:12:29 UTC, Heisenberg wrote:
Just an idea. Do you think it would have any advantage compared 
to the one that is written in C?


It would have advantages : most kernel vulnerabilities are due to 
buffer overflows, use-after-frees and such that are directly 
linked to the use of C. While it is possible to have these bugs 
in D they require that you go out of your way (using raw pointers 
instead of slices for example) which makes them less likely to 
happen.


On the other hand "normal D" cannot be used for the kernel as you 
need to grow a specific druntime that is able to manage memory 
allocations and such without depending on an existing kernel, so 
it's work.

Re: Linux Kernel in D?

[Daniel Kozak via Digitalmars-d]

Dne 1.11.2016 v 13:12 Heisenberg via Digitalmars-d napsal(a):

Just an idea. Do you think it would have any advantage compared to the 
one that is written in C?
Same as any other software written in C. C is unsafe so in D it should 
be more safe and easier to mantain

Re: Minimizing "reserved" words

[Daniel9 via Digitalmars-d]

On Monday, 31 October 2016 at 20:45:56 UTC, Jacob Carlborg wrote:
The "reserved" words I'm referring to are not necessarily 
keywords in the language but otherwise words that should be 
avoided, especially for defining methods in aggregates. I'm 
mostly thinking of built-in properties like .init, .classinfo, 
.sizeof, .outer and so on.


All of the above can be used as variable names. Some of the 
above names can be used as methods in aggregates but some 
cannot. Of the above names only "sizeof" cannot be used as a 
method name.


Would it be better to try to minimize these special words and 
instead use either compiler recognized functions/templates or 
something like __traits? If they were compiler recognized 
functions, defined somewhere in druntime, the normal language 
lookup rules could be used to disambiguate the compiler 
recognized functions from user defined functions. Or if a 
__trait is used, that would have it's own namespace and not 
cause any conflicts.


In the latest release of DMD (2.072.0) TypeInfo.init has been 
deprecate in favor of TypeInfo.initializer. That would not have 
been needed if .init wasn't a built-in property but instead a 
compiler recognized function.


Thoughts? Too late to change, to much could would break?


This information from Wiki, I hope it will be useful. That 
general reserved words and keywords need not coincide, but in 
most modern languages keywords are a subset of reserved words, as 
this makes parsing easier, since keywords cannot be confused with 
identifiers. In some languages, like C or Python, reserved words 
and keywords coincide, while in other languages, like Java, all 
keywords are reserved words, but some reserved words are not 
keywords – these are "reserved for future use". In yet other 
languages, such as the older languages ALGOL, FORTRAN and PL/I, 
there are keywords but no reserved words, with keywords being 
distinguished from identifiers by other means. This makes parsing 
more difficult with look-ahead parsers necessary.

Re: Linux Kernel in D?

[Edwin van Leeuwen via Digitalmars-d]

On Tuesday, 1 November 2016 at 12:12:29 UTC, Heisenberg wrote:
Just an idea. Do you think it would have any advantage compared 
to the one that is written in C?


There have been a number of projects working on this. For example:
https://github.com/Vild/PowerNex

Linux Kernel in D?

[Heisenberg via Digitalmars-d]

Just an idea. Do you think it would have any advantage compared 
to the one that is written in C?

[Issue 12655] foldRange

[via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

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

--

Re: Release D 2.072.0

[Nick Treleaven via Digitalmars-d-announce]

On Monday, 31 October 2016 at 07:27:50 UTC, Ali Çehreli wrote:
Is the only valid remaining use for the comma operator the 
'for' loop iteration?


for ( ; ; ++i, ++j) {
// ...
}

Are there other uses?


The changelog shows it can be used for an expression statement:

  // This is okay, the result is not used.
  if (!mc)
mc = new MyContainerClass, mc.append(new Entry);

I've made a pull to improve the comma examples, e.g. adding 
brackets (mc = ...), mc.append and removing unnecessary 
statements:


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

Would be good if someone could review and merge.

Re: Got a post for the D Blog?

[qznc via Digitalmars-d-announce]

On Monday, 31 October 2016 at 03:51:16 UTC, Mike Parker wrote:
I want to publish more posts like Andreas's 'Find Was Too Damn 
Slow, So We Fixed It` [1] (which, by the way, is the 
most-viewed post so far, just ahead of Joakim's interview with 
Walter [2]), or Steven's 'How to Write @trusted Code in D' [3], 
but I need help.


[1] 
http://dlang.org/blog/2016/06/16/find-was-too-damn-slow-so-we-fixed-it/
[2] 
http://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/
[3] 
http://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/


I take that as a compliment. Thanks! The rest of you, take that 
as a challenge. ;)


What I would like to read about would be LuaD [4] or ctRegex [5], 
because they are great demos of CTFE.


The auto-tester would be worth an article as well. Not about the 
implementation details, but about its features and the PR 
workflow.


Also, some embedded D use like kernel or freestanding stuff.

None of these are "I fixed something in D" though. Hm, Taking a 
look through the recent 072 changelog, I found two items which 
could be worth a story:


* std.range.padLeft and std.range.padRight were added (if someone 
can write comedy and wants to take some jabs at the Javascript 
leftPad story)
* std.range.generate fixed to be a proper range (I remember some 
heated discussion about the semantics of front)



[4] http://jakobovrum.github.io/LuaD/
[5] https://dlang.org/phobos/std_regex.html#.ctRegex

Re: Release vibe.d 0.7.30

[Saurabh Das via Digitalmars-d-announce]

On Tuesday, 1 November 2016 at 09:09:05 UTC, Saurabh Das wrote:

On Monday, 31 October 2016 at 20:30:22 UTC, Sönke Ludwig wrote:

[...]


I'm going to try this out today! :)


How can I find out more information about the 'runApplication' 
change? What does "slowly fading out" mean?

Re: splitter trouble

[John Colvin via Digitalmars-d-learn]

On Sunday, 30 October 2016 at 23:57:11 UTC, Ali Çehreli wrote:
While working on a solution for Alfred Newman's thread, I came 
up with the following interim solution, which compiled but 
failed:


auto parse(R, S)(R range, S separators) {
import std.algorithm : splitter, filter, canFind;
import std.range : empty;

static bool pred(E, S)(E e, S s) {
return s.canFind(e);
}

return range.splitter!pred(separators).filter!(token => 
!token.empty);

}

unittest {
import std.algorithm : equal;
import std.string : format;
auto parsed = parse("_My   input.string", " _,.");
assert(parsed.equal([ "My", "input", "string" ]), 
format("%s", parsed));

}

void main() {
}

The unit test fails and prints

["put", "ing"]

not the expected

["My", "input", "string"].

How is that happening? Am I unintentionally hitting a weird 
overload of splitter?


Ali


As usual, auto-decoding has plumbed the sewage line straight in 
to the drinking water...


Splitter needs to know how far to skip when it hits a match. 
Normally speaking - for the pred(r.front, s) overload that you're 
using here - the answer to that question is always 1. Except in 
the case of narrow strings, where it's whatever the encoded 
length of the separator is in the encoding of the source range 
(in this case utf-8), in order to skip e.g. a big dchar.* But in 
your case, your separator is more than one character, but you 
only want to skip forward one, because your separator isn't 
really a separator.


* see 
https://github.com/dlang/phobos/blob/d6572c2a44d69f449bfe2b07461b2f0a1d6503f9/std/algorithm/iteration.d#L3710


Basically, what you're doing isn't going to work. A separator is 
considered to be a separator, i.e. something to be skipped over 
and twisting the definition causes problems.


This will work, but I can't see any way to make it @nogc:

auto parse(R, S)(R range, S separators) {
import std.algorithm : splitter, filter, canFind;
import std.range : save, empty;

return range
.splitter!(e => separators.save.canFind(e))
.filter!(token => !token.empty);
}

Re: Minimizing "reserved" words

[Jonathan M Davis via Digitalmars-d]

On Tuesday, November 01, 2016 08:29:17 Jacob Carlborg via Digitalmars-d 
wrote:
> On 2016-10-31 23:25, Jonathan M Davis via Digitalmars-d wrote:
> > IMHO, it's just plain error-prone to allow for any of the built-in
> > properties to be overridden, and it should be disallowed in all cases.
> > We
> > need to be able to rely on stuff like .init of .sizeof being the
> > built-in
> > property, or you're just going to get bugs - especially in generic code.
>
> That might be the case. But why are they built-in properties from the
> beginning. Compiler recognized free functions or __traits would not have
> this problem.

In general, I don't think that it would make sense for them to be functions,
and they'd be uglier as traits. And for the most part, they aren't names
that anyone is really going to want to use for their own code anyway
(particularly with the typical D naming conventions). AFAIK, the only one
that's sometimes getting defined and causing problems is init, and that's
certainly used often enough that needing something like __traits to use it
would be rather annoying. But it's certainly true that they could have have
been implemented differently originally. However, it would break far too
much code at this point to change them even if we all agreed that the
current situation was less than ideal.

But the only built-in properties that I can think of which definitely
shouldn't have been built-in proprties are the ones specific to arrays such
as sort, and they've already been deprecated in favor of proper functions.
So, the ones that were obviously a bad idea have already been taken care of.

- Jonathan M Davis