pointer not aligned

[Joel via Digitalmars-d-learn]

Linking...
ld: warning: pointer not aligned at address 0x10017A4C9 
(_D30TypeInfo_AxS3std4file8DirEntry6__initZ + 16 from 
.dub/build/application-debug-posix.osx-x86_64-dmd_2072-EFDCDF4D45F944F7A9B1AEA5C32F81ED/spellit.o)

...

and this goes on forever!

Re: CT aggregate computations

[drug via Digitalmars-d-learn]

30.03.2017 21:59, H. S. Teoh via Digitalmars-d-learn пишет:


http://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time


Really useful link, thank you very much!

Re: Reading on D safety?

[Walter Bright via Digitalmars-d]

On 3/30/2017 5:48 AM, qznc wrote:

The topic of safety is an important one imho. It comes up again and again. D has
a good story to tell about being easier than Rust and safer than C++. How should
this be addressed? A blog article?



I'll be presenting on the topic at DConf and will be following up with an 
article. I agree as to the importance of the topic.

[your code here]

[April Dale via Digitalmars-d]

I need some informations on what this is

Re: The nail in the coffin of C++ or why don't GO there...

[Dmitry Olshansky via Digitalmars-d]

On 3/30/17 1:03 PM, Ervin Bosenbacher wrote:

On Thursday, 30 March 2017 at 10:28:01 UTC, dennis luehring wrote:

Am 30.03.2017 um 08:58 schrieb Ervin Bosenbacher:

That is the same, that came as a shock to me.


most compilers (for many languages) can optimize your super-trivial
example down to nothing - for at least the last 10 years or more

so whats the point? you're talkin about "performance is critical for me"
but missing even minor knowledge about todays compiler powers?

for a benchmark you need:
-loops, running millions of times, preventing IO and do now fall into
the completely-optimized-to-nothing-trap etc.


Tried again, threw in summing up a number 10 million times and repeat
the arrays 10 million times, I have used arrays on the stack for the D
version. And when I am talking about performance I am curious about CPU
bound stuff.

The D version:

import std.stdio;

void main()
{
long sum = 0;
foreach (long i; 0 .. 1000) {
int[12] months = [ 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30,
31 ];
int[3] first = months[0 .. 3];
int[3] second = months[3 .. 6];
int[3] third = months[6 .. 9];
int[3] fourth = months[9 .. 12];



Most of this code may be easily eliminated by dead-code removal. So you 
probably just measure the summing loop alone. To be certain look at 
disassembly.


---
Dmitry Olshansky

Re: 64-bit DMD

[Daniel Kozak via Digitalmars-d-learn]

Dne 31.3.2017 v 00:41 Inquie via Digitalmars-d-learn napsal(a):

Is there a 64-bit DMD compiler that doesn't have the 2GB memory 
limitations that the 32-bit one has? I am not talking about compiling 
64-bit programs but the dmd binary itself.

I belive it is 4GB ok maybe 3GB :)
https://forum.dlang.org/post/kkqysqgvytdzcwglx...@forum.dlang.org

Vim has got D-Scanner support.

[ANtlord via Digitalmars-d-announce]

Hello! I've done integration of D-Scanner in Vim plugin Syntastic 
(https://github.com/vim-syntastic/syntastic/pull/1995). Vim users 
are able to check his code using D-Scanner.


Links:

D-Scanner (https://github.com/Hackerpilot/Dscanner)

Syntastic (https://github.com/vim-syntastic/syntastic)

Vim (http://www.vim.org/)

Thanks.

64-bit DMD

[Inquie via Digitalmars-d-learn]

Is there a 64-bit DMD compiler that doesn't have the 2GB memory 
limitations that the 32-bit one has? I am not talking about 
compiling 64-bit programs but the dmd binary itself.

[Issue 17287] [ICE] backend/cgcod.c 255: zero length static arrays

[via Digitalmars-d-bugs]

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

--- Comment #5 from ki...@gmx.net ---
(In reply to Илья Ярошенко from comment #4)
> (In reply to hsteoh from comment #3)
> > I've used zero-length static arrays at the end of structs before, and they
> > work, for the most part.  I'm surprised having a zero-length member in the
> > middle of a struct causes an ICE, though. Or is it the zero-length ctor
> > parameter that's causing the problem?
> 
> It is all factors together. No one line can be removed to reduce this
> example.

We've had the same issue with LDC. Zero-length static arrays are so special
because they are the only type with a size of 0. Empty structs have a size of
1. If I recall correctly, we ended up ignoring zero-sized aggregate fields in
the backend and passing/returning them as byte (analogous to empty structs).

--

Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?

[Dukc via Digitalmars-d]

On Thursday, 30 March 2017 at 17:22:20 UTC, Stefan Koch wrote:

SDC has the goal to be more principled.
And Not to be Mr. fast and loose, right ?
If a file parses it'd better be syntactically correct!
All of it.


Just an idea, but could the solution for SDC be to enable 
unittests by default, disabling them would be explicit? That 
would sure make using it alot more principled that dmd, 
regardless whether it syntax checks unittests when they are 
disabled.

[Issue 17287] [ICE] backend/cgcod.c 255: zero length static arrays

[via Digitalmars-d-bugs]

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

--- Comment #4 from Илья Ярошенко  ---
(In reply to hsteoh from comment #3)
> I've used zero-length static arrays at the end of structs before, and they
> work, for the most part.  I'm surprised having a zero-length member in the
> middle of a struct causes an ICE, though. Or is it the zero-length ctor
> parameter that's causing the problem?

It is all factors together. No one line can be removed to reduce this example.

--

[Issue 17287] [ICE] backend/cgcod.c 255: zero length static arrays

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #3 from hst...@quickfur.ath.cx ---
I've used zero-length static arrays at the end of structs before, and they
work, for the most part.  I'm surprised having a zero-length member in the
middle of a struct causes an ICE, though. Or is it the zero-length ctor
parameter that's causing the problem?

--

Re: CT aggregate computations

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

On Thu, Mar 30, 2017 at 06:21:43PM +, Enigma via Digitalmars-d-learn wrote:
> Is it possible to compute at compile time computations on a manifest
> constant that contains values(in a somewhat complex way, but that
> shouldn't matter)?

Yes, see below.


> I am using foreach and it seems to be done dynamically as I can step
> through the code for each value and see them change. This tells me it
> is not done at compile time like it should be.

If you want something done at compile time, you have to ask for it. The
usual way is to use something like `enum` that must be known at
compile-time to force the compiler to run the computation through CTFE.


> I might have something like
> 
> 
> import std.meta, std.algorithm, std.stdio;
> void main()
> {
>   enum X = [1,2,3,4,5];
>   int y = 0;  
>   foreach(x; X) // or foreach(x; aliasSeqOf!X), both iterate over y at run
> time according to the debugger.
>  y = max(x, y);
>   
>   writeln(y);
>   
> }

Here is how to do it:

auto computeY(int[] data)
{
int y = 0;
foreach (x; data)
y = max(x,y);
return y;
}

void main()
{
enum X = [1,2,3,4,5];
enum y = computeY(X);   // N.B.: enum forces CTFE
writeln(y);
}


> But I want it to be effectively the same as
> 
> 
> import std.meta, std.algorithm, std.stdio;
> void main()
> {
>   enum X = [1,2,3,4,5];
>   int y = 5;  
>   writeln(y); 
> }
> 
> so y is computed at compile time. I'd rather not having to create some
> complex templates to handle it, which I think could be done using
> template recursion.
[...]

You don't need template recursion unless you're doing something at the
AST level.  For most computations you want done at "compile-time", you
can just use CTFE.

Again, I see the term "compile-time" is misleading people. You may want
to read the following (it's still a draft, but what's there should
help clear things up):

http://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time


T

-- 
Caffeine underflow. Brain dumped.

Re: CT aggregate computations

[Ali Çehreli via Digitalmars-d-learn]

On 03/30/2017 11:21 AM, Enigma wrote:
> Is it possible to compute at compile time computations on a manifest
> constant that contains values(in a somewhat complex way, but that
> shouldn't matter)?

You can do anything that you want as long as it's available at compile 
time. For example, you cannot interact with a user.


> I am using foreach and it seems to be done dynamically as I can step
> through the code for each value and see them change. This tells me it is
> not done at compile time like it should be.

D does not have an explicit way of requesting compile-time execution. 
It's done when it's needed at compile time:


- enum values

- static const values

- Template arguments

- Mixin code

In order to prove yourself that something is computed at compile time, 
just use pragma(msg).


> import std.meta, std.algorithm, std.stdio;
> void main()
> {
> enum X = [1,2,3,4,5];

One big gotcha with enum arrays is that every place that you refer to X, 
a temporary array will be created dynamically. Only the manifest value 
of the array is computed at compile time. Try the following code and be 
surprised that it prints two different addresses:


writeln(X.ptr);
writeln(X.ptr);

(This issue does not apply to strings.)

So, what you want to do is to create an enum like the above, but use it 
only once at runtime to initialize another array, likely immutable, for 
your actual use.


// This is what the program will actually use
immutable int[] X;

auto calculateArray() {
return [1,2,3,4,5];
}

// This is used only once to initialize X
private enum X_ = calculateArray();
pragma(msg, "Known at compile time: ", X_);

import std.algorithm: maxElement;
enum y = maxElement(X_);

shared static this() {
X = X_;
}

void main() {
pragma(msg, "Known at compile time: ", y);
}

Ali

Re: CT aggregate computations

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

On Thursday, 30 March 2017 at 18:21:43 UTC, Enigma wrote:
I am using foreach and it seems to be done dynamically as I can 
step through the code for each value and see them change. This 
tells me it is not done at compile time like it should be.


Remember two facts:

1) CTFE is never done unless it specifically must be done

and

2) D does not have static foreach, it is just regular foreach


And a third warning:

* enum foo = [1,2,3]; makes foo work just like an array 
literal... which means it actually does a runtime allocation 
every time you reference it. Rarely what you actually want!



The answer is simple though: write an ordinary function that does 
your calculation and pass it an ordinary array, but set it to a 
static immutable array to force CTFE.


int getMax(int[] X) {
  int y = 0;
  foreach(x; X)
 y = max(x, y);
  return y;
}

void main() {
   enum y = getMax([1,2,3,4,5]); // safe for int
   static immutable y = getMax(...); // use that if return array
}



So you need to do a regular loop in a regular function, then 
assign the result of that regular function to enum or static.

CT aggregate computations

[Enigma via Digitalmars-d-learn]

Is it possible to compute at compile time computations on a 
manifest constant that contains values(in a somewhat complex way, 
but that shouldn't matter)?


I am using foreach and it seems to be done dynamically as I can 
step through the code for each value and see them change. This 
tells me it is not done at compile time like it should be.


I might have something like


import std.meta, std.algorithm, std.stdio;
void main()
{
enum X = [1,2,3,4,5];
int y = 0;  
	foreach(x; X) // or foreach(x; aliasSeqOf!X), both iterate over 
y at run time according to the debugger.

   y = max(x, y);

writeln(y);

}

But I want it to be effectively the same as


import std.meta, std.algorithm, std.stdio;
void main()
{
enum X = [1,2,3,4,5];
int y = 5;  
writeln(y); 
}

so y is computed at compile time. I'd rather not having to create 
some complex templates to handle it, which I think could be done 
using template recursion. I know of Map and such but will these 
compute completely at compile time or will be essentially be the 
same as the foreach loop?

Re: Memory Allocation

[Enigma via Digitalmars-d-learn]

On Thursday, 30 March 2017 at 11:22:05 UTC, Gary Willoughby wrote:

On Wednesday, 29 March 2017 at 19:19:48 UTC, Enigma wrote:
I have a memory buffer allocated using different methods. It 
is simply a pointer and a size.


I would like to be able to manage this buffer by treating it 
as a memory pool or heap. I think I can use allocators to do 
this but not sure how.


You can re-task the GC to use an arena if that's suitable:

https://bitbucket.org/infognition/dstuff/src/1dca752af1021ed5998bb041004465674695113f/gcarena.d?fileviewer=file-view-default


cool. thanks.

Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?

[XavierAP via Digitalmars-d]

On Thursday, 30 March 2017 at 09:04:28 UTC, ixid wrote:

On Thursday, 30 March 2017 at 06:53:47 UTC, XavierAP wrote:


I would consider this harmful... The spec already states this 
about unit tests, so I'd guess the decision was taken in the 
past conscientiously.


If you're worried about compilation time, you can always 
define your unit tests in separate files that are included for 
compilation only when needed.


Why is it harmful (actually asking, not telling you you're 
wrong)? I thought we were going to use a pay for what you use 
philosophy, if a unit test is not run then why is it paid for?


rjframe and Stefan have said it better than I could. I do 
understand the more I think about it how people could be worried 
about the downsides. Priorities depends on user cases and some 
personal inclination. But with the stated arguments I would think 
it's a bit of a slippery slope. And moreover for people so 
concerned with compilation time there are easy clean workarounds 
such as separate files. Compilers could implement something 
analogous to pre-compiled headers for this case.

Re: The nail in the coffin of C++ or why don't GO there...

[Jon Degenhardt via Digitalmars-d]

On Thursday, 30 March 2017 at 11:03:03 UTC, Ervin Bosenbacher 
wrote:
Tried again, threw in summing up a number 10 million times and 
repeat the arrays 10 million times, I have used arrays on the 
stack for the D version. And when I am talking about 
performance I am curious about CPU bound stuff.


[...benchmarks snipped...]

I am still convinced that D is awesome.

Nice! You might also find these benchmarks I did recently 
interesting:  
https://github.com/eBay/tsv-utils-dlang/blob/master/docs/Performance.md


--Jon

Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?

[Stefan Koch via Digitalmars-d]

On Thursday, 30 March 2017 at 14:28:41 UTC, deadalnix wrote:
On Wednesday, 29 March 2017 at 19:32:50 UTC, Vladimir Panteleev 
wrote:

Sorry, is this not already the case?

$ dmd test.d
$ cat test.d
void main()
{
import std.stdio;
writeln("Hello, world!");
}


unittest
{
foo bar {} baz more-syntax!errors)blah
}
$ dmd test.d
$ ./test
Hello, world!


Alright then, it looks like it is :)

I was asking for SDC.


SDC has the goal to be more principled.
And Not to be Mr. fast and loose, right ?
If a file parses it'd better be syntactically correct!
All of it.

Re: Memory Allocation

[Enigma via Digitalmars-d-learn]

On Wednesday, 29 March 2017 at 23:26:04 UTC, H. S. Teoh wrote:
On Wed, Mar 29, 2017 at 11:01:12PM +, Enigma via 
Digitalmars-d-learn wrote:
On Wednesday, 29 March 2017 at 21:36:14 UTC, Petar Kirov 
[ZombineDev] wrote:

> [...]

But these seem to require passing a mallocator. I simply want 
to pass an already allocated region/block/buffer and have the 
allocators use it. I will allocate and free on my own.


Huh?  Where does it say that a mallocator is required?

As far as I can tell, you could simply do this:

void[] myBuffer = ...;
auto allocator = Region!()(myBuffer);
auto p = allocator.allocate(...);

The default parent allocator is NullAllocator, which does 
nothing, so that leaves the management of myBuffer entirely up 
to you.



T


Thanks. All the examples show using a size rather than an array 
so I assumed that was the case.

[Issue 17288] formattedWrite error when width/precision provided and no value to format

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

URL||https://github.com/dlang/ph
   ||obos/pull/5314

--

[Issue 17288] New: formattedWrite error when width/precision provided and no value to format

[via Digitalmars-d-bugs]

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

  Issue ID: 17288
   Summary: formattedWrite error when width/precision provided and
no value to format
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: n...@geany.org

The following calls have a missing integer, the first is used for precision
(same happens for %*.d width too):

import std.format;
unittest
{
enum f = format("%.*d", 5); // Compile error: "n = 1"
auto s = format("%.*d", 5); // throws RangeError
}

Instead, format should throw FormatError. PR to follow.

--

[your code here]

[Justin Brown via Digitalmars-d]

8
4

Re: Why is this legal?

[bauss via Digitalmars-d-learn]

On Wednesday, 29 March 2017 at 10:08:02 UTC, abad wrote:
Related question, it seems that final methods are allowed in 
interfaces. Obviously you can't implement them anywhere, so is 
this also on purpose and on what rationale? :)


That is not necessarily true. Final doesn't imply it can't be 
implemented. It implies that it cannot be override.

Re: Beta 2.074.0-b1

[Martin Nowak via Digitalmars-d-announce]

On Tuesday, 28 March 2017 at 09:49:59 UTC, Andrej Mitrovic wrote:

On Friday, 24 March 2017 at 17:35:58 UTC, Martin Nowak wrote:
Very cool about the new format!() feature. What about extending 
this to writef(ln)?


Wow, that should've been top of the changelog!

Re: Beta 2.074.0-b1

[Martin Nowak via Digitalmars-d-announce]

On Monday, 27 March 2017 at 21:56:27 UTC, steven kladitis wrote:

You can use the install.sh script for now.
  curl -fsS https://dlang.org/install.sh | bash -s dmd-beta


-- windows does not know what curl is also bash , I think :)


Indeed we should have a single-line Powershell install.ps1 as 
well, will you be the one to write it?

Re: The nail in the coffin of C++ or why don't GO there...

[Swoorup Joshi via Digitalmars-d]

On Thursday, 30 March 2017 at 13:59:45 UTC, bachmeier wrote:
On Thursday, 30 March 2017 at 12:27:33 UTC, Ervin Bosenbacher 
wrote:

On Thursday, 30 March 2017 at 11:41:46 UTC, rjframe wrote:

On Thu, 30 Mar 2017 11:15:10 +, Ervin Bosenbacher wrote:


[...]


You can integrate D and Python with pyd.

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

--Ryan


Brilliant, thank you. Will help to leverage my python code. 
Also I might be able to convince others around me to use D 
instead of C extending Python.


Would be nice for you to blog your learning too (nothing fancy, 
just a quick report from time to time) because many others are 
in your current situation.


I went back to C++ cause integration with existing packages was a 
pain and a implicit gc

[Issue 17286] A function for comparing two digests securely

[via Digitalmars-d-bugs]

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

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

--

[Issue 8290] DMD git-master segfaults if outputfile exists as directory

[via Digitalmars-d-bugs]

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

Martin Krejcirik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Martin Krejcirik  ---
Not reproducible.

--

[Issue 17287] [ICE] backend/cgcod.c 255: zero length static arrays

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

   Keywords|accepts-invalid |ice-on-valid-code
 CC||petar.p.ki...@gmail.com
   Hardware|x86 |All

--- Comment #2 from ZombineDev  ---
@Stefan It easily comes up in generic code when length is based on some
calculation and/or code generation via string mixins For reference see
http://docs.algorithm.dlang.io/latest/mir_ndslice_slice.html#Slice
and browse through the source code (https://github.com/libmir/mir-algorithm).

T[0] is pretty normal if you think about it as struct S { }. If passing around
structs without any members works, why wouldn't zero-sized static arrays be ok?
Structs without members are invalid in C, but on the contrary are quite common
in C++ and similarly D allows them for a reason. See also
http://en.cppreference.com/w/cpp/language/ebo,
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html and
http://dlang.org/spec/arrays.html:

> A static array with a dimension of 0 is allowed, but no space is allocated 
> for it. It's useful as the last member of a variable length struct, or as the 
> degenerate case of a template expansion.

--

Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?

[deadalnix via Digitalmars-d]

On Wednesday, 29 March 2017 at 19:32:50 UTC, Vladimir Panteleev 
wrote:

Sorry, is this not already the case?

$ dmd test.d
$ cat test.d
void main()
{
import std.stdio;
writeln("Hello, world!");
}


unittest
{
foo bar {} baz more-syntax!errors)blah
}
$ dmd test.d
$ ./test
Hello, world!


Alright then, it looks like it is :)

I was asking for SDC.

Re: The nail in the coffin of C++ or why don't GO there...

[bachmeier via Digitalmars-d]

On Thursday, 30 March 2017 at 12:27:33 UTC, Ervin Bosenbacher 
wrote:

On Thursday, 30 March 2017 at 11:41:46 UTC, rjframe wrote:

On Thu, 30 Mar 2017 11:15:10 +, Ervin Bosenbacher wrote:


I have already accepted the fact that if
I want to optimize my Python code in certain situations, not 
all because
you can use better algos, data structures, etc then I have to 
drop down

to C++ or C using say pybind11. Instead of that D.


You can integrate D and Python with pyd.

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

--Ryan


Brilliant, thank you. Will help to leverage my python code. 
Also I might be able to convince others around me to use D 
instead of C extending Python.


Would be nice for you to blog your learning too (nothing fancy, 
just a quick report from time to time) because many others are in 
your current situation.

Re: The nail in the coffin of C++ or why don't GO there...

[Shachar Shemesh via Digitalmars-d]

On 30/03/17 09:58, Ervin Bosenbacher wrote:


Performance test:
rvinMacBookProLimegg:source ervinbosenbacher$ time ./app
[31, 28, 31]
[30, 31, 30]
[31, 31, 30]
[31, 30, 31]

real0m0.004s
user0m0.001s
sys0m0.001s

ErvinMacBookProLimegg:source ervinbosenbacher$ time ./a.out
[31, 28, 31]
[30, 31, 30]
[31, 31, 30]
[31, 30, 31]

real0m0.004s
user0m0.001s
sys0m0.002s

That is the same, that came as a shock to me.

Happy coding al!


I just finished implementing RAID parity calculations. I don't remember 
the precise numbers, but I saved a non-insignificant amount of run time 
(order of 10-20%) by casting from ranges to pointers before running the 
XORs.


Be sure to benchmark.

Shachar

Reading on D safety?

[qznc via Digitalmars-d]

Safety of C has been in the (hacker) news lately [0]. When I 
tried to tell people about D, I had no good link to share on the 
topic.


The spec for @safe [1] is not comprehensive.

The article of SafeD [2] is fluffy and without much meat.

The C to D comparison is too much irrelevant stuff.

I found nothing on the blog.

The topic of safety is an important one imho. It comes up again 
and again. D has a good story to tell about being easier than 
Rust and safer than C++. How should this be addressed? A blog 
article?


[0] https://news.ycombinator.com/item?id=13966241
[1] https://dlang.org/spec/function.html#function-safety
[2] https://dlang.org/safed.html

Re: The nail in the coffin of C++ or why don't GO there...

[Ervin Bosenbacher via Digitalmars-d]

On Thursday, 30 March 2017 at 11:41:46 UTC, rjframe wrote:

On Thu, 30 Mar 2017 11:15:10 +, Ervin Bosenbacher wrote:


I have already accepted the fact that if
I want to optimize my Python code in certain situations, not 
all because
you can use better algos, data structures, etc then I have to 
drop down

to C++ or C using say pybind11. Instead of that D.


You can integrate D and Python with pyd.

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

--Ryan


Brilliant, thank you. Will help to leverage my python code. Also 
I might be able to convince others around me to use D instead of 
C extending Python.

Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?

[drug via Digitalmars-d]

30.03.2017 14:47, rjframe пишет:

On Thu, 30 Mar 2017 09:04:28 +, ixid wrote:


Why is it harmful (actually asking, not telling you you're wrong)? I
thought we were going to use a pay for what you use philosophy, if a
unit test is not run then why is it paid for?


A person that doesn't run `dmd -unittest` (or `dub test`) prior to
committing code could commit broken tests. In my mind if you write tests
but don't run them, they're broken anyway.

--Ryan

Broken test could be parsable, but still broken. You need to run it to 
check if it is (not) broken anyway.

Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?

[rjframe via Digitalmars-d]

On Thu, 30 Mar 2017 09:04:28 +, ixid wrote:

> Why is it harmful (actually asking, not telling you you're wrong)? I
> thought we were going to use a pay for what you use philosophy, if a
> unit test is not run then why is it paid for?

A person that doesn't run `dmd -unittest` (or `dub test`) prior to 
committing code could commit broken tests. In my mind if you write tests 
but don't run them, they're broken anyway.

--Ryan

Re: The nail in the coffin of C++ or why don't GO there...

[rjframe via Digitalmars-d]

On Thu, 30 Mar 2017 11:15:10 +, Ervin Bosenbacher wrote:

> I have already accepted the fact that if
> I want to optimize my Python code in certain situations, not all because
> you can use better algos, data structures, etc then I have to drop down
> to C++ or C using say pybind11. Instead of that D.

You can integrate D and Python with pyd.

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

--Ryan

Re: Memory Allocation

[Gary Willoughby via Digitalmars-d-learn]

On Wednesday, 29 March 2017 at 19:19:48 UTC, Enigma wrote:
I have a memory buffer allocated using different methods. It is 
simply a pointer and a size.


I would like to be able to manage this buffer by treating it as 
a memory pool or heap. I think I can use allocators to do this 
but not sure how.


You can re-task the GC to use an arena if that's suitable:

https://bitbucket.org/infognition/dstuff/src/1dca752af1021ed5998bb041004465674695113f/gcarena.d?fileviewer=file-view-default

Re: The nail in the coffin of C++ or why don't GO there...

[H. S. Teoh via Digitalmars-d]

On Thu, Mar 30, 2017 at 11:15:10AM +, Ervin Bosenbacher via Digitalmars-d 
wrote:
[...]
> I am happy with D.

Welcome aboard!


T

-- 
The richest man is not he who has the most, but he who needs the least.

Re: The nail in the coffin of C++ or why don't GO there...

[Ervin Bosenbacher via Digitalmars-d]

On Thursday, 30 March 2017 at 10:28:01 UTC, dennis luehring wrote:

Am 30.03.2017 um 08:58 schrieb Ervin Bosenbacher:

That is the same, that came as a shock to me.


most compilers (for many languages) can optimize your 
super-trivial example down to nothing - for at least the last 
10 years or more


so whats the point? you're talkin about "performance is 
critical for me"

but missing even minor knowledge about todays compiler powers?

for a benchmark you need:
-loops, running millions of times, preventing IO and do now 
fall into the completely-optimized-to-nothing-trap etc.


I understand what you are saying, it wasn't a thorough all 
encompassing analysis just wanted a quick POC and convince myself 
whether D lang is sufficient enough for my case. I have already 
accepted the fact that if I want to optimize my Python code in 
certain situations, not all because you can use better algos, 
data structures, etc then I have to drop down to C++ or C using 
say pybind11. Instead of that D. And then if I am not happy with 
something I can drop to C or C++ anyway because its ABI 
compatible with C and with limitations with C++, right? After I 
have accepted the fact that I have to use various tools to solve 
various problems its not much of an issue. But with D i have to 
less code which is always better. Less code, less complexity, 
less bugs... etc I am not going to go down this vortex. :)


Yes I have much less knowledge of compilers probably than you do 
but I am happy with these results.


On another note my first choice was rust, and I have tried and 
tried, rejecting it multiple times. I am happy with D.

Re: The nail in the coffin of C++ or why don't GO there...

[Ervin Bosenbacher via Digitalmars-d]

On Thursday, 30 March 2017 at 10:28:01 UTC, dennis luehring wrote:

Am 30.03.2017 um 08:58 schrieb Ervin Bosenbacher:

That is the same, that came as a shock to me.


most compilers (for many languages) can optimize your 
super-trivial example down to nothing - for at least the last 
10 years or more


so whats the point? you're talkin about "performance is 
critical for me"

but missing even minor knowledge about todays compiler powers?

for a benchmark you need:
-loops, running millions of times, preventing IO and do now 
fall into the completely-optimized-to-nothing-trap etc.


Tried again, threw in summing up a number 10 million times and 
repeat the arrays 10 million times, I have used arrays on the 
stack for the D version. And when I am talking about performance 
I am curious about CPU bound stuff.


The D version:

import std.stdio;

void main()
{
long sum = 0;
foreach (long i; 0 .. 1000) {
int[12] months = [ 31, 28, 31, 30, 31, 30, 31, 31, 30, 
31, 30, 31 ];

int[3] first = months[0 .. 3];
int[3] second = months[3 .. 6];
int[3] third = months[6 .. 9];
int[3] fourth = months[9 .. 12];

sum += i;
}
writeln(sum);
}

The C++11 version:

#include 
#include 
#include 

using namespace std;

template
X CopyArray(const Y& src, const size_t start, const size_t end)
{
X dst;
std::copy(src.begin() + start, src.begin() + end, 
dst.begin());

return dst;
}

template 
ostream& operator<<(ostream& o, const array& arr)
{
std::cout << "[";
for (auto& elem : arr) {
std::cout << elem;
if ( != ()) printf(", ");
}
std::cout << "]";
return o;
}

int main() {

long sum = 0;
for (long i = 0; i < 1000; i++) {
array _arr = { 31, 28, 31, 30, 31, 30, 
31, 31, 30, 31, 30, 31 };
array first = 
CopyArray(_arr, 0, 3);
array second = 
CopyArray(_arr, 3, 6);
array third = 
CopyArray(_arr, 6, 9);
array fourth = 
CopyArray(_arr, 9, 12);


sum += i;
}

cout << sum << endl;
/*cout << first << endl;
cout << second << endl;
cout << third << endl;
cout << fourth << endl; */
}

Test

With DMD

$ dmd app.d -O
$ time ./app
499500

real0m0.290s
user0m0.282s
sys 0m0.003s


With LDC

$ ldc2 app.d -O
$ time ./app
499500

real0m0.004s
user0m0.001s
sys 0m0.002s


And then the C++
$ g++ app.cpp -O3 -o app_cpp
$ time ./app_cpp
499500

real0m0.004s
user0m0.001s
sys 0m0.002s

I am still convinced that D is awesome.

Happy coding!

[Issue 17287] [ICE] backend/cgcod.c 255: zero length static arrays

[via Digitalmars-d-bugs]

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

Stefan Koch  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |accepts-invalid
 CC||uplink.co...@gmail.com
   Severity|major   |normal

--- Comment #1 from Stefan Koch  ---
Apparently no one has written such code.
until now, otherwise this issue would have surfaced sooner.

any length zero array is non-nonsensical in D.

--

Re: The nail in the coffin of C++ or why don't GO there...

[Ervin Bosenbacher via Digitalmars-d]

On Thursday, 30 March 2017 at 10:28:01 UTC, dennis luehring wrote:

Am 30.03.2017 um 08:58 schrieb Ervin Bosenbacher:

That is the same, that came as a shock to me.


most compilers (for many languages) can optimize your 
super-trivial example down to nothing - for at least the last 
10 years or more


so whats the point? you're talkin about "performance is 
critical for me"

but missing even minor knowledge about todays compiler powers?

for a benchmark you need:
-loops, running millions of times, preventing IO and do now 
fall into the completely-optimized-to-nothing-trap etc.


yes it was a quick hack. I try it again. Optimizations were 
turned on -O3 in case of gcc -O i case of dmd. But I am convinced 
that D language and is sufficiently good case for myself. First I 
wanted to go with C++/C/Python trio but that I ca replace with 
one language getting rid of additional complexities and other 
stuff. I agree compilers are not my thing so I will have a look 
deeper. Thx for the comment.


Happy coding!

Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?

[Claude via Digitalmars-d]

On Wednesday, 29 March 2017 at 19:43:52 UTC, Vladimir Panteleev 
wrote:
On Wednesday, 29 March 2017 at 19:32:50 UTC, Vladimir Panteleev 
wrote:

On Wednesday, 29 March 2017 at 11:16:28 UTC, deadalnix wrote:
I was wondering. When uniitests aren't going to run, it may 
be desirable to skip parsing altogether, just lexing and 
counting braces until the matching closing brace is found.


Sorry, is this not already the case?


https://github.com/dlang/dmd/pull/4704


To quote Walter Bright from that PR, unittest can contain invalid 
code ONLY if you never compile with -unittest (obviously), -D or 
-H.


It looks consistent to me: just don't parse it in release mode.

Re: The nail in the coffin of C++ or why don't GO there...

[dennis luehring via Digitalmars-d]

Am 30.03.2017 um 08:58 schrieb Ervin Bosenbacher:

That is the same, that came as a shock to me.


most compilers (for many languages) can optimize your super-trivial 
example down to nothing - for at least the last 10 years or more


so whats the point? you're talkin about "performance is critical for me"
but missing even minor knowledge about todays compiler powers?

for a benchmark you need:
-loops, running millions of times, preventing IO and do now fall into 
the completely-optimized-to-nothing-trap etc.

Re: Can vibed be fast as Go or Python?

[Martin Nowak via Digitalmars-d]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/28/2017 09:32 AM, Suliman wrote:
> I found very interesting Python async framework japronto 
> https://github.com/squeaky-pl/japronto
> 
> Test show that in some cases japronto may work as fast as Go.
> 
> Can vibed be competitor (or even better) than Go and Python for 
> micro-services?

The answer is clearly yes, it's possible to build services that are
significantly faster in D than in most other languages.
The only thing that could be avoided w/ vibe.d, at the cost of a
horrible callback based API, is the tiny stack switching overhead of
Fibers (which go uses as well). Usually none of that matters as
services are either I/O or processing bound.

For the processing D has a lot of means to avoid additional memory
allocations and indirections necessary in go or Java (not to speak of
dynamic languages), it also offers easy access to SIMD powered array
operations, and can go as low-level as assembly (though you'll
unlikely ever need that).
https://github.com/libmir/mir-glas
https://github.com/kostya/benchmarks

Vibe.d currently undergoes a major rewrite of it's internals that
should result in even better performance figures
(http://dlang.org/blog/2017/03/01/project-highlight-vibe-d/,
https://github.com/vibe-d/vibe-core).

Truth to be told, while people in the D community tend to write very
fast code by default, sometimes almost obsessively, a lot more
engineering power went into other projects, e.g. go has a fairly
complex and optimized Fiber scheduler.

Yet the fact that small D projects are capable to hold their grounds
against major projects w/ dozens of engineers is indicative of the
sweet spot D hits combining performance + productivity.

You might find Liran's talk helpful
http://dconf.org/2016/talks/zvibel.html, basically you can get a
competitive advantage out of choosing D, but should be prepared to
contribute back to the ecosystem and community.

Why not let us know a bit more about what Microservice you have in
mind, so that we can give you a much more specific answer?

- -Martin
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJY3NYIAAoJELJzgRYSuxk5pvgP/iPBlVWJl58+ooH94xU3JAiW
GeKsPDATGlEM9HCwRGUaoH3v/+lj1DaNX4g12q6o/uUNc8uhc2rapJ2Bbxp58y2c
H3gcV1lA6EJbsVi1M+FipNoUpvfq1AvBb1+knpX7adgNiD7DGe9tUd116XlQqhRN
heUD6VUodgbJYAa8g+48Buu1stIMKx0qoNRZYePzYtVBlxJcOyee5Qq1XvEGkyF4
VcsuLLkm6lh5WfVDk6QSeUtL7OCGKjYVBmkOxua5lojbCYhvlPjzO54dxQ9CgJ8R
xV922RIl2WMHW+A6vBN/n63Z0alM2WTe0kIGuDsB4MUA9A59/nCbMdt9QCRRsIUk
hiPBAan3DUQoyAEwl10tzWATIIXa9RNjWV8RAbH1Q/fS31rI6IeC/1SZ1/2Z+2gk
0XLv6clZfk1oj9eL80Ba2kH/Rr5Db2j5KcFDXgewwlhP+x9ajUdMkXw/3Wawa8ye
cS6haKcUpkCLdxfKDpmuCMPMdn3uVNC7Xd/5wsphPXWGzvwfjIh1MKC+Tr4qfh9r
IgTZu0Y/raFW7s4ef7UXAjfc9F8+1oLJQE4wA7xbZiXuboE5iyIIGaj7NQZF18CP
aKV21LDnkX4Q+2fF8vA0TqxMMd6QbCe4WBrinKvid0E1FTcUT6Ed4zGKS3nmQAak
o6ubj1zt0VsEEBFbXaeC
=Upyx
-END PGP SIGNATURE-

Re: Can vibed be fast as Go or Python?

[Martin Nowak via Digitalmars-d]

On 03/28/2017 08:16 PM, Jacob Carlborg wrote:
> I create a test at work, compared an existing Ruby implementation
> of an API end point to a Go implementation and a D implementation.
> The D implementation was five times faster. Unfortunately my
> colleagues paid more attention to the result that showed that the
> Ruby implementation was twice as fast as the Go implementation.

Just a matter of proper plotting ;).
In German, but very funny http://katjadittrich.de/, pies of truth :).

But seriously I can highly recommend to learn ggplot2, makes nice
plotting easy and is actually worthwhile to learn.
There is even a D version http://code.dlang.org/packages/ggplotd, though
that one could use some string mixin DSL to reach R's brevity.

-Martin

Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?

[ixid via Digitalmars-d]

On Thursday, 30 March 2017 at 06:53:47 UTC, XavierAP wrote:

On Wednesday, 29 March 2017 at 11:16:28 UTC, deadalnix wrote:


Is that an acceptable tradeof ?


I would consider this harmful... The spec already states this 
about unit tests, so I'd guess the decision was taken in the 
past conscientiously.


If you're worried about compilation time, you can always define 
your unit tests in separate files that are included for 
compilation only when needed.


Why is it harmful (actually asking, not telling you you're 
wrong)? I thought we were going to use a pay for what you use 
philosophy, if a unit test is not run then why is it paid for?

[Issue 17287] [ICE] backend/cgcod.c 255: zero length static arrays

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--

[Issue 17287] New: [ICE] backend/cgcod.c 255: zero length static arrays

[via Digitalmars-d-bugs]

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

  Issue ID: 17287
   Summary: [ICE] backend/cgcod.c 255: zero length static arrays
   Product: D
   Version: D2
  Hardware: x86
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

struct Sl
{
size_t a;
ptrdiff_t[0] str;
size_t b;

this(ptrdiff_t[0] str)
{
}

auto opIndex()
{
auto c = b;
auto ret = Sl(str);
}
}

dmd -m32

Internal error: backend/cgcod.c 255

--

Re: DConf Hackathon

[Nicholas Wilson via Digitalmars-d]

On Thursday, 30 March 2017 at 07:28:12 UTC, Adam Wilson wrote:

Hello fellow DConfers!

In the spirit of "the DConf 2017 hackathon isn't a hackathon in 
the traditional sense as most of the time and focus will 
hopefully be spent discussing, planning and developing future D 
projects"; I was thinking that it might be beneficial to pull 
together a list of areas in the D ecosystem that DConf 
attendees would be interested in hacking on. These areas could 
then be used to create a number of "hacking groups" where 
like-minded colleagues could sit together, discuss, and even 
hack on that topic if they wish.


Please reply with your vote and whether or not you are willing 
to organize those groups.


I would be interested in participating in the following areas:
Security Libraries   (Morning)- Willing to Organize
Database Interfaces  (Afternoon)  - Willing to Organize

I am looking forward to seeing everyone there!


I was thinking of doing something to coordinate the development 
of DCompute. So I'd be up for Organising a high performance / 
numeric group.

DConf Hackathon

[Adam Wilson via Digitalmars-d]

Hello fellow DConfers!

In the spirit of "the DConf 2017 hackathon isn't a hackathon in the 
traditional sense as most of the time and focus will hopefully be spent 
discussing, planning and developing future D projects"; I was thinking 
that it might be beneficial to pull together a list of areas in the D 
ecosystem that DConf attendees would be interested in hacking on. These 
areas could then be used to create a number of "hacking groups" where 
like-minded colleagues could sit together, discuss, and even hack on 
that topic if they wish.


Please reply with your vote and whether or not you are willing to 
organize those groups.


I would be interested in participating in the following areas:
Security Libraries   (Morning)- Willing to Organize
Database Interfaces  (Afternoon)  - Willing to Organize

I am looking forward to seeing everyone there!

--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: The nail in the coffin of C++ or why don't GO there...

[XavierAP via Digitalmars-d]

On Thursday, 30 March 2017 at 06:58:30 UTC, Ervin Bosenbacher 
wrote:


That is the same, that came as a shock to me.


I believe for this slicing D might be even faster for a larger 
example/megaloop, because slicing does not necessarily copy 
unless needed.


As you say the key is being able to write better, shorter code.

Happy coding!

The nail in the coffin of C++ or why don't GO there...

[Ervin Bosenbacher via Digitalmars-d]

Just would like to share something. For months I couldn't decide 
what language to use for my pet project, analysed dozens of 
languages from rust to go and I always fell back to C++ 
(performance is critical for me). After rust I had a look at 
DLang but as a C++ veteran I had my (wrong) feelings, prejudices 
etc but I got infected and started to go down a long route of 
trying to accept it and trying to love it. I am a slow learner 
but forced to open my mind. I am also a Python dev so I kinda 
liked the syntax and the simplicity of the language, the speed of 
compilation and execution was also appealing but still... But 
then something has happened which basically helped to make up my 
mind and to go with D finally.


From the  Programming in D book i  typed in the below code, I use 
Sublime.


```
import std.stdio : writeln;

void main()
{
int[12] months = [ 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 
30, 31 ];

int[] first = months[0 .. 3];
int[] second = months[3 .. 6];
int[] third = months[6 .. 9];
int[] fourth = months[9 .. 12];
writeln(first);
writeln(second);
writeln(third);
writeln(fourth);
}
```

Then I have decided to reimplement this in C++. The code is not 
perfect hacked it together on the train. The length and the 
complexity is already on the negative side.


#include 
#include 
#include 

using namespace std;

template
X slice(const Y& src, const size_t start, const size_t end)
{
X dst;
std::copy(src.begin() + start, src.begin() + end, 
dst.begin());

return dst;
}

template 
ostream& operator<<(ostream& o, const array& arr)
{
std::cout << "[";
for (auto& elem : arr) {
std::cout << elem;
if ( != ()) printf(", ");
}
std::cout << "]";
return o;
}

int main() {

array _arr = { 31, 28, 31, 30, 31, 30, 31, 31, 
30, 31, 30, 31 };

array first = slice(_arr, 0, 3);
array second = slice(_arr, 3, 
6);

array third = slice(_arr, 6, 9);
array fourth = slice(_arr, 9, 
12);


cout << first << endl;
cout << second << endl;
cout << third << endl;
cout << fourth << endl;
}

Then  came the performance test, here we go:

Performance test:
rvinMacBookProLimegg:source ervinbosenbacher$ time ./app
[31, 28, 31]
[30, 31, 30]
[31, 31, 30]
[31, 30, 31]

real0m0.004s
user0m0.001s
sys 0m0.001s

ErvinMacBookProLimegg:source ervinbosenbacher$ time ./a.out
[31, 28, 31]
[30, 31, 30]
[31, 31, 30]
[31, 30, 31]

real0m0.004s
user0m0.001s
sys 0m0.002s

That is the same, that came as a shock to me.

Happy coding al!

Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?

[XavierAP via Digitalmars-d]

On Wednesday, 29 March 2017 at 11:16:28 UTC, deadalnix wrote:


Is that an acceptable tradeof ?


I would consider this harmful... The spec already states this 
about unit tests, so I'd guess the decision was taken in the past 
conscientiously.


If you're worried about compilation time, you can always define 
your unit tests in separate files that are included for 
compilation only when needed.

Re: Why is this legal?

[XavierAP via Digitalmars-d-learn]

On Wednesday, 29 March 2017 at 09:50:10 UTC, abad wrote:


Is this on purpose and what's the rationale?


In Andrei's book, chapter 6.9.1 "the non virtual interface (NVI) 
idiom" answers your question. It cites this article by Herb 
Sutter as the originator of the idea:


http://www.gotw.ca/publications/mill18.htm