date:20140705

On Fri, 2014-07-04 at 20:25 +, Chris Cain via Digitalmars-d wrote:
[…]
 The big problem with that is C++ style memory management 
 implies we're going to have new/delete which AFAIK delete is 
 depreciated and new is currently hardcoded to use the GC.
[…]

All the C++ folk are saying that with C++14 is you are using any heap at
all you are more than likely doing it wrong. Modern C++ idiom is for
completely new/delete free code.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: std.math performance (SSE vs. real)

On Fri, 2014-07-04 at 12:48 +, via Digitalmars-d wrote:
[…]
 I pick the most stable tool for the job. Meaning I usually end up 
 with C, conservative use of C++, Python 2.7, Javascript, SQL or 
[…]

That should, of course, have read Python 3.4!

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: Languages for servers (Go, D, and more)


Chris Cain:


http://dlang.org/phobos/std_typecons.html#.Unique


I'd like to read a little tutorial for the usage of that Unuque 
in D.


Bye,
bearophile

Re: std.math performance (SSE vs. real)

On Saturday, 5 July 2014 at 06:48:23 UTC, Russel Winder via 
Digitalmars-d wrote:


That should, of course, have read Python 3.4!


Most of my code has to run on App Engine, so I stick to whatever 
version Google use for all my Python stuff. They had Guido do 
their db-api a couple of years back so they probably stick with 
2.7 for a good reason? Sometimes stable means with known bugs 
and known work-arounds. ;)

Re: std.math performance (SSE vs. real)

2014-07-05 Thread Paolo Invernizzi via Digitalmars-d


On Friday, 4 July 2014 at 21:49:33 UTC, Ola Fosheim Grøstad wrote:

On Friday, 4 July 2014 at 21:08:27 UTC, Walter Bright wrote:

Sadly, this also implies that there are no computer languages 
you believe in. You set an impossible standard. How can you 
possibly say you prefer C++, a classic design by committee 
language?


I don't prefer it. I think it sucks, but it is the only viable 
choice if you want to create a scalable game or virtual world 
server.


Again, outside, in the real business world, reality is a little
different: take this monster, look, no C++!

http://www.robg3d.com/2014/01/why-ccp-is-still-using-python-2/
http://www.pcgamer.com/2013/06/15/eve-online/

What I loved about D, from the real beginning, was this:
pragmatism, pragmatism!

And after the love, what moved us as a company to adopt it was
Walter: He is a deeply pragmatic guy!
Pragmatism is an invaluable asset in business (btw, THAT should
be stressed in the logo/identity/redesign looong thread)

---
Paolo

Re: std.math performance (SSE vs. real)


On Saturday, 5 July 2014 at 09:39:10 UTC, Paolo Invernizzi wrote:

Again, outside, in the real business world, reality is a little
different: take this monster, look, no C++!

http://www.robg3d.com/2014/01/why-ccp-is-still-using-python-2/
http://www.pcgamer.com/2013/06/15/eve-online/


I don't play Eve, but in general the challenge in virtual worlds
is that you need to do full veracity checking on the server to
reduce cheating. You should also hide parts of the model so that
only the server knows it. Basically, you have to run the entire
sim on the server and only run parts of it on the client for
display purposes if you want to reduce cheating without
introducing draconian measures that basically takes over the
machine (which cannot work if the client runs in the browser).

Anyway, at the end of the day, for a freemium game you need to
cut server costs because you cannot estimate correctly how much
money you make per online user. With a subscription model you are
better off and can spend more on hardware.

What you can or cannot do, depends on the business model, the
market and the game design…


What I loved about D, from the real beginning, was this:
pragmatism, pragmatism!


I am pragmatic about this. I have stuff planned that can run on
Python on top of Google Datastore on the server and use
Dart+WebGL on the client. But if you want a physics based model,
user building and fast travelling you have to consider the worst
case scenario and you cannot do it in Python or using a disk
based database.  You need a in-memory database and hit the
hardware so that you can take the peaks without ending up with
molasses of latency.


And after the love, what moved us as a company to adopt it was
Walter: He is a deeply pragmatic guy!
Pragmatism is an invaluable asset in business (btw, THAT should
be stressed in the logo/identity/redesign looong thread)


The most valuable factor in business is predictability,
opportunities and being better at cutting costs than the
competition. Google are pragmatic, they dump IE9 on most of their
platforms. Unfortunately for businesses using Google tech that
means loss of predictability, lost opportunities and increased
costs.

Pragmatism in the context of D is community building. Sure, being
pragmatic about the logo is important, you should encourage
people using it in different ways because it is a community
building tool (among many). Like the penguin in Linux being used
in games etc. Community building means encouraging participation
and setting direction. If you don't set direction, people will
sit on the fence waiting for something to happen. Communities
don't build skeletons, they add meat to the bones.

DMD 2.066.0-b1 feedback

2014-07-05 Thread Tove via Digitalmars-d

The beta works great this far, just sharing some few initial 
surprises.


1) The lookup rules for namespaces seem overly permissive:

extern (C++, A.B.C):
void cpp() { }

All these work:
A.cpp
B.cpp
C.cpp
A.B.cpp
B.C.cpp
A.B.C.cpp

2) We have std.traits.functionLinkage, but no corresponding trait 
to get the namespace?

Re: Languages for servers (Go, D, and more)

2014-07-05 Thread ponce via Digitalmars-d

On Saturday, 5 July 2014 at 06:43:31 UTC, Russel Winder via 
Digitalmars-d wrote:


All the C++ folk are saying that with C++14 is you are using 
any heap at
all you are more than likely doing it wrong. Modern C++ idiom 
is for

completely new/delete free code.


Minor nitpick, it is indeed devoid of delete.
But in modern C++ but the _heap_ is still used an awful lot, 
everytime a std::vector is copied, everytime a std::string is 
concatenated, etc. And it's very much silent. Modern C++ is a 
style that makes resource release timely and painless, but still 
let a lot of allocations go unchecked.

Re: Cryptography and D

2014-07-05 Thread Kagamin via Digitalmars-d


On Sunday, 29 June 2014 at 19:25:30 UTC, Chris Cain wrote:
Of course, following all of those suggestions isn't trivial to 
begin with. Technically, you're right, but because what you 
said isn't easy to follow to begin with, it doesn't support the 
argument of you can implement a crypto algorithm.


Following those guidelines don't require knowledge in 
cryptography. And D automtically provides good level of pedantism 
of bound checking, so this part should be easier.


Basically, if you have data you must have secured (the reason 
why you'd use a crypto algorithm to begin with), you must go 
beyond a sane level of pedantry. The only acceptable insane 
level of pedantry I know of is only possible with people that 
have doctorates in cryptography. :)


Plus, add what Xinok said. That's showing the level of pedantry 
we're talking about with crypto where you have to cover things 
like timing attacks and power analysis (or, admit that your 
crypto library isn't suitable for covering those attacks).


That's not to say you shouldn't ever do it, but you really need 
to truly understand what it is you're doing when you implement 
any crypto. Even using crypto requires a certain (often 
ignored) level of knowledge or you introduce issues.


There was a study, showing that most security vulnerabilities are 
caused by client code rather than cryptographic library code. For 
example, how would you prevent client code from generating weak 
encryption keys or from using weak algorithm for hash comparison, 
or how would you force it to do what's not required to get the 
code compiled? How would you do that with the quality of library 
code? Even if you can do that, it's still not a cryptographic 
task, but a general programming task, the standard only hints you 
that those things are necessary.

Re: std.math performance (SSE vs. real)

2014-07-05 Thread Paolo Invernizzi via Digitalmars-d


On Saturday, 5 July 2014 at 11:14:40 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 5 July 2014 at 09:39:10 UTC, Paolo Invernizzi 
wrote:

Again, outside, in the real business world, reality is a little
different: take this monster, look, no C++!

http://www.robg3d.com/2014/01/why-ccp-is-still-using-python-2/
http://www.pcgamer.com/2013/06/15/eve-online/


I don't play Eve, but in general the challenge in virtual worlds
is that you need to do full veracity checking on the server to
reduce cheating. You should also hide parts of the model so that
only the server knows it. Basically, you have to run the entire
sim on the server and only run parts of it on the client for
display purposes if you want to reduce cheating without
introducing draconian measures that basically takes over the
machine (which cannot work if the client runs in the browser).

Anyway, at the end of the day, for a freemium game you need to
cut server costs because you cannot estimate correctly how much
money you make per online user. With a subscription model you 
are

better off and can spend more on hardware.

What you can or cannot do, depends on the business model, the
market and the game design…


I agree, but keep this is mind: a business model is not carved in
stone, it keeps changing, as the market is not a static thing.
And this is true also in the programming language field, as the
IT universe is not a static thing.

I liked the Lang.NEXT panel, especially when Bjarne talked about
the real world pressure over C++...


What I loved about D, from the real beginning, was this:
pragmatism, pragmatism!


I am pragmatic about this. I have stuff planned that can run on
Python on top of Google Datastore on the server and use
Dart+WebGL on the client. But if you want a physics based model,
user building and fast travelling you have to consider the worst
case scenario and you cannot do it in Python or using a disk
based database.  You need a in-memory database and hit the
hardware so that you can take the peaks without ending up with
molasses of latency.


If you read carefully, EVE was not designed for the actual number
of concurrent users: they was forced to keep changing, to survive
the challenges. The worst case scenario is the today worst case
scenario.

You can't design now for what you think will be the needs in a
too much distance future, that's will put your product in the
Longhorn cemetery. Things need to be done now, to get the current
business opportunity window.


And after the love, what moved us as a company to adopt it was
Walter: He is a deeply pragmatic guy!
Pragmatism is an invaluable asset in business (btw, THAT should
be stressed in the logo/identity/redesign looong thread)


The most valuable factor in business is predictability,
opportunities and being better at cutting costs than the
competition.


Thinks are a little more complicated than that, but well, at the
end, business is all about satisfying the needs of someone else
who is free to choose among alternatives.

So, turning back into the floating point issue of the thread,
what's the most pragmatic move D can take about that floating
point performance issue?

Take the road that satisfy better the most demanded need asked
nowadays by D user base, so speed by default.
Satisfy the precision demand with real, but keep this need in an
explicit language domain corner: there's no silver bullet.

Pragmatism in the context of D is community building. Sure, 
being

pragmatic about the logo is important, you should encourage
people using it in different ways because it is a community
building tool (among many). Like the penguin in Linux being used
in games etc. Community building means encouraging participation
and setting direction. If you don't set direction, people will
sit on the fence waiting for something to happen. Communities
don't build skeletons, they add meat to the bones.


What I was meaning: a pragmatic language is a beautiful
business claim, let's stress it: it worked very well for me!

---
Paolo

Re: Optimizing Java using D

2014-07-05 Thread Wanderer via Digitalmars-d


On Friday, 4 July 2014 at 12:18:54 UTC, Daniel Murphy wrote:
Yes they do.  
http://en.wikipedia.org/wiki/Database_index#Clustered


You can obviously only do that for one index.


Ugh, and what happens in such hypothetical database if you update 
its first row so it becomes 1 byte longer than before? Total 
reordering of the whole database just to maintain that index? 
That's very similar to the issue I posted above - wasteful 
shuffling of big amounts of memory only because D's structs don't 
support indirection by their nature, and you can't swap two 
elements without copying their whole contents.


John Colvin said above that structs can be useful, even together 
with sorting (and similar algorithms), if they are relatively 
small. This is true, but this design is not scalable. As soon as 
your program evolves and your struct grows with more and more 
fields, D's sort on it becomes slower and slower, proportionally 
to the struct's size. That's not the best behavior IMHO.

Re: std.math performance (SSE vs. real)


On Saturday, 5 July 2014 at 13:16:28 UTC, Paolo Invernizzi wrote:
I agree, but keep this is mind: a business model is not carved 
in stone, it keeps changing, as the market is not a static 
thing.


Ok, but for the virtual world side I am more driven by (artistic) 
model needs than the business side. So I am looking for a 
solution that fits the requirements.



And this is true also in the programming language field, as the
IT universe is not a static thing.


No, but for contractual work I need to be able to add small 
enhancements 12 months after deployment without adding transition 
costs. So a static dev environment matters a lot. If a customer 
expect that an enhancement takes 10 hours to add, I cannot charge 
for 50 hours. So if the dev environment incurs a transition cost 
I have to accept the enhancement request at a loss.


(App Engine is pretty stable and has a 12 months guarantee, which 
is on the low side IMO. I think 24 months would be more 
appropriate.).


If you read carefully, EVE was not designed for the actual 
number of concurrent users:


I only glossed over it. I read external analyses of EVE 10 years 
ago when I studied online worlds. I believe they had some 
significant performance problems back. But the game model is not 
really low latency based.



You can't design now for what you think will be the needs in a
too much distance future, that's will put your product in the
Longhorn cemetery. Things need to be done now, to get the 
current business opportunity window.


I'm not interested in virtual worlds for the business, but for 
the art of it. So my basic ideas are 10-20 years old and 
basically just waiting for the technology to catch up. ;^)


If I have to nudge the tech to make the last mile, ok, then I 
might have to do so…



So, turning back into the floating point issue of the thread,
what's the most pragmatic move D can take about that floating
point performance issue?


Provide the tools to specify the constraints, like you do for 
nogc/safe, but with version support.


But I think D should be specified, not by the implementation, but 
in a paper. And I think the language should be cleaned up a bit, 
on paper, without thinking about the implementation cost for a 
specific compiler. Because if the resulting language is a true 
beauty, then more hands will come to add meat to the bones.


I'm not complaining about requiring strict IEEE 754 compliance, I 
am complaining about requiring it and then saying that it does 
not matter what the compiler devs do. Because it is obvious that 
on many platforms you don't get full compliance for special cases 
without some kind of software emulation/handling.



What I was meaning: a pragmatic language is a beautiful
business claim, let's stress it: it worked very well for me!


Python is a very pragmatic language, I don't like the dynamic 
aspects, but it is one of the most pragmatic languages out there.


The way I see it now, the most pragmatic solution would be to 
fork D, clean up the syntax a bit and make it work well for the 
domain of game servers. I don't need the libraries. Only UDP/TCP. 
Whether that is cost efficient compared to just using C++, I 
dunno. But the more I follow the discussions on the D forums, the 
more I feel that forking will be more productive than spending 
effort on affecting the current direction (which most probably 
will not get me what I want).

Re: Optimizing Java using D

2014-07-05 Thread Dmitry Olshansky via Digitalmars-d


05-Jul-2014 18:02, Wanderer пишет:

On Friday, 4 July 2014 at 12:18:54 UTC, Daniel Murphy wrote:

Yes they do. http://en.wikipedia.org/wiki/Database_index#Clustered

You can obviously only do that for one index.


Ugh, and what happens in such hypothetical database if you update its
first row so it becomes 1 byte longer than before?


Provision some extra space in each record. DBs do this all the time, 
regardless of layout.



Total reordering of
the whole database just to maintain that index? That's very similar to
the issue I posted above - wasteful shuffling of big amounts of memory
only because D's structs don't support indirection by their nature, and
you can't swap two elements without copying their whole contents.


It's funny to see how an _ability_ to avoid indirection can be framed as 
a problem. Nothing prevents having an array of pointers to structs or 
just using classes if desired.


On the contrary sorting an array of pairs of integers in say Java is 
shamefully inefficient. No wonder packed objects (=value types)  are 
coming to Java, to address these sorts of need.


http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120


John Colvin said above that structs can be useful, even together with
sorting (and similar algorithms), if they are relatively small. This is
true, but this design is not scalable. As soon as your program evolves
and your struct grows with more and more fields, D's sort on it becomes
slower and slower, proportionally to the struct's size. That's not the
best behavior IMHO.


Ehm. One can always redesign struct layout to push stuff out through an 
indirection. And it's not like structs grow organically on their own ;)


In the same vane design of ref-to-instance is not scalable with millions 
of items scattered across the memory causing awful cache miss rate (as 
the indirection got to be crossed to compare things), not to mention the 
memory wasted per each object.


--
Dmitry Olshansky

Re: Languages for servers (Go, D, and more)

On Sat, 2014-07-05 at 11:46 +, ponce via Digitalmars-d wrote:
 On Saturday, 5 July 2014 at 06:43:31 UTC, Russel Winder via 
 Digitalmars-d wrote:
 
  All the C++ folk are saying that with C++14 is you are using 
  any heap at
  all you are more than likely doing it wrong. Modern C++ idiom 
  is for
  completely new/delete free code.
 
 Minor nitpick, it is indeed devoid of delete.
 But in modern C++ but the _heap_ is still used an awful lot, 
 everytime a std::vector is copied, everytime a std::string is 
 concatenated, etc. And it's very much silent. Modern C++ is a 
 style that makes resource release timely and painless, but still 
 let a lot of allocations go unchecked.

Not a minor nitpick, an error on my part: I should have included the
term explicitly. Thanks for picking me up on this.  As others have
pointed out in the interim, modern C++ still uses unique_ptr, etc. and
RAII so there is heap use, just no unconstrained use.
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: std.math performance (SSE vs. real)

2014-07-05 Thread Iain Buclaw via Digitalmars-d

On 5 July 2014 15:20, via Digitalmars-d digitalmars-d@puremagic.com wrote:
 On Saturday, 5 July 2014 at 13:16:28 UTC, Paolo Invernizzi wrote:

 I agree, but keep this is mind: a business model is not carved in stone,
 it keeps changing, as the market is not a static thing.


 Ok, but for the virtual world side I am more driven by (artistic) model
 needs than the business side. So I am looking for a solution that fits the
 requirements.


 And this is true also in the programming language field, as the
 IT universe is not a static thing.


 No, but for contractual work I need to be able to add small enhancements 12
 months after deployment without adding transition costs. So a static dev
 environment matters a lot. If a customer expect that an enhancement takes 10
 hours to add, I cannot charge for 50 hours. So if the dev environment incurs
 a transition cost I have to accept the enhancement request at a loss.

 (App Engine is pretty stable and has a 12 months guarantee, which is on the
 low side IMO. I think 24 months would be more appropriate.).


 If you read carefully, EVE was not designed for the actual number of
 concurrent users:


 I only glossed over it. I read external analyses of EVE 10 years ago when I
 studied online worlds. I believe they had some significant performance
 problems back. But the game model is not really low latency based.


 You can't design now for what you think will be the needs in a
 too much distance future, that's will put your product in the
 Longhorn cemetery. Things need to be done now, to get the current business
 opportunity window.


 I'm not interested in virtual worlds for the business, but for the art of
 it. So my basic ideas are 10-20 years old and basically just waiting for the
 technology to catch up. ;^)

 If I have to nudge the tech to make the last mile, ok, then I might have to
 do so…


 So, turning back into the floating point issue of the thread,
 what's the most pragmatic move D can take about that floating
 point performance issue?


 Provide the tools to specify the constraints, like you do for nogc/safe, but
 with version support.

 But I think D should be specified, not by the implementation, but in a
 paper. And I think the language should be cleaned up a bit, on paper,
 without thinking about the implementation cost for a specific compiler.
 Because if the resulting language is a true beauty, then more hands will
 come to add meat to the bones.

 I'm not complaining about requiring strict IEEE 754 compliance, I am
 complaining about requiring it and then saying that it does not matter what
 the compiler devs do. Because it is obvious that on many platforms you don't
 get full compliance for special cases without some kind of software
 emulation/handling.


This is a library problem, not a language problem.  In this case
std.math uses real everywhere when perhaps it shouldn't.


 What I was meaning: a pragmatic language is a beautiful
 business claim, let's stress it: it worked very well for me!


 Python is a very pragmatic language, I don't like the dynamic aspects, but
 it is one of the most pragmatic languages out there.


http://pyd.dsource.org


 The way I see it now, the most pragmatic solution would be to fork D, clean
 up the syntax a bit and make it work well for the domain of game servers. I
 don't need the libraries. Only UDP/TCP. Whether that is cost efficient
 compared to just using C++, I dunno. But the more I follow the discussions
 on the D forums, the more I feel that forking will be more productive than
 spending effort on affecting the current direction (which most probably will
 not get me what I want).

You mean, MiniD?  Someone has already done that, years ago

http://jfbillingsley.com/croc/wiki/Lang/GettingStarted

Re: Optimizing Java using D

2014-07-05 Thread Wanderer via Digitalmars-d


On Saturday, 5 July 2014 at 14:20:33 UTC, Dmitry Olshansky wrote:
Provision some extra space in each record. DBs do this all the 
time, regardless of layout.


Which means waste of space you complained about just below.

Besides, you understand this is not a solution: one byte more 
than that reserve can provide, and the reordering should be done. 
Stuff like FAT was created exactly because linear storages are 
terribly inefficient unless they are read-only.


It's funny to see how an _ability_ to avoid indirection can be 
framed as a problem. Nothing prevents having an array of 
pointers to structs or just using classes if desired.


Pointers to structs? Manually add indirection for sorting? That's 
reinventing the wheel. Indeed better (and simpler) using classes 
instead. They provide the same functionality and without using 
unsafe features.


On the contrary sorting an array of pairs of integers in say 
Java is shamefully inefficient. No wonder packed objects 
(=value types)  are coming to Java, to address these sorts of 
need.


For pair of integers, you can use long and sort an array of 
longs. But if your structure is any more complex (or has 
nontrivial comparison algorithm), one should really consider 
using classes first.


Ehm. One can always redesign struct layout to push stuff out 
through an indirection. And it's not like structs grow 
organically on their own ;)


You mean structs with pointers? That violates the whole principle 
of structs IMHO. Ideally, when you assign/copy a struct, you 
assign/copy a *value*. Usage of pointers would add undue aliasing 
to the copy process, leading to bugs.


In the same vane design of ref-to-instance is not scalable with 
millions of items scattered across the memory causing awful 
cache miss rate (as the indirection got to be crossed to 
compare things), not to mention the memory wasted per each 
object.


It depends. With classes, you have to read and write only small 
portions of memory - read only fields to compare, write only 
references to swap. Even with cache misses, this is still very 
small and efficient operations. With structs, you have to read 
and write much bigger regions of memory - to swap two items, you 
have to read both of them fully, then write both of them fully 
into new locations - which would make caching totally useless, 
whether structs are located sequentially or not. It's like 
copying a large file - the cache gets exhausted instantly, and 
doesn't speed things up at all.

Re: std.math performance (SSE vs. real)

On Saturday, 5 July 2014 at 15:09:28 UTC, Iain Buclaw via 
Digitalmars-d wrote:

This is a library problem, not a language problem.  In this case
std.math uses real everywhere when perhaps it shouldn't.


If x/y leads to a division by zero trap when it should not, then 
it isn't a library problem.



You mean, MiniD?  Someone has already done that, years ago


No, I meant forking D.

Kitchen Design Lancashire Reviews

2014-07-05 Thread jancukers via Digitalmars-d


Kitchen Design Lancashire in my mind are the best value kitchens
by far.



[url=http://www.lancashireinteriorhomedesigns.co.uk/]Kitchen
Design Lancashire Reviews[/url]

Re: std.math performance (SSE vs. real)


Ola Fosheim Grøstad:


No, I meant forking D.


There is already Delight and FeepingCreature has created a D-like 
language. If you fork D you will have lot of fun :-) Keep us 
updated.


Bye,
bearophile

Re: Tuples printing

2014-07-05 Thread FrankLike via Digitalmars-d


[（1, 2, 3), (4, 5, 6), (7, 8, 9)]
Good idea.
And shoud easy to be used by foreach.

Frank

Re: std.math performance (SSE vs. real)


On Saturday, 5 July 2014 at 15:28:00 UTC, bearophile wrote:
There is already Delight and FeepingCreature has created a 
D-like language. If you fork D you will have lot of fun :-)


Thanks :)

Both Delight and FeepingCreature appears to be alive. I guess 
that is a good sign.

Re: Optimizing Java using D

2014-07-05 Thread Dmitry Olshansky via Digitalmars-d


05-Jul-2014 19:08, Wanderer пишет:

On Saturday, 5 July 2014 at 14:20:33 UTC, Dmitry Olshansky wrote:

Provision some extra space in each record. DBs do this all the time,
regardless of layout.


Which means waste of space you complained about just below.


There are trade-offs. The world is not black and white and I don't 
follow 'one rule everywhere'.



Besides, you understand this is not a solution: one byte more than that
reserve can provide, and the reordering should be done.


Which is what happens at a times, regardless of how DB was organized.


Stuff like FAT
was created exactly because linear storages are terribly inefficient
unless they are read-only.


Frankly FAT is junk. But in any case file maintenance problem is all 
about balancing wasting some memory on gaps with the need defragment 
linked chains. There is no silver bullet you seem to imply.



It's funny to see how an _ability_ to avoid indirection can be framed
as a problem. Nothing prevents having an array of pointers to structs
or just using classes if desired.


Pointers to structs? Manually add indirection for sorting? That's
reinventing the wheel. Indeed better (and simpler) using classes
instead. They provide the same functionality and without using unsafe
features.


Pointers are perfectly fine as long as there is no pointer arithmetic.
Also there is no problem just constructing a sorted index (e.g. there is 
function for that in Phobos) for the array of big structs, and voila - 
the same reference to the item, but the stuff is neatly packed in a 
contiguous array.



On the contrary sorting an array of pairs of integers in say Java is
shamefully inefficient. No wonder packed objects (=value types)  are
coming to Java, to address these sorts of need.


For pair of integers, you can use long and sort an array of longs.


Which is hopelessly admitting defeat. A pair may have non-trivial 
comparator. And a minor step beyond that such as a pair of double and 
integer and it fails completely.



But
if your structure is any more complex (or has nontrivial comparison
algorithm), one should really consider using classes first.


And there Java-style indirection-happy classes shine. For instance 
modeling any complex stuff with classes alone would lead to things like:

House--reference-Bedroom---reference--Bed--reference--Pillow

Which is incredible waste of memory and speed on something so simple.


Ehm. One can always redesign struct layout to push stuff out through
an indirection. And it's not like structs grow organically on their
own ;)


You mean structs with pointers? That violates the whole principle of
structs IMHO.


What? But again it seems to be the general direction of you post - 
puristic one size fits all. The idea that there is true holy way, is 
very much province of OOP language proponents.



Ideally, when you assign/copy a struct, you assign/copy a
*value*. Usage of pointers would add undue aliasing to the copy process,
leading to bugs.


Copy constructors or in D parlance postblits. There is also CoW and 
whatnot. In fact swap doesn't create a copy in D, it just does a bitwise 
swap in-place.



In the same vane design of ref-to-instance is not scalable with
millions of items scattered across the memory causing awful cache miss
rate (as the indirection got to be crossed to compare things), not to
mention the memory wasted per each object.


It depends. With classes, you have to read and write only small portions
of memory - read only fields to compare


Strictly more then with structs to be precise as long as it's just 
compare we talk about. A reference + fields vs just fields. Also the 
cost of extra indirection is very much non-negligible.



write only references to swap.


That much is true.


Even with cache misses, this is still very small and efficient
operations.


Disagree - the moment a cache line is loaded it doesn't matter how much 
you read in this line. Even a tiny read missing a cache is paid in full.



With structs, you have to read and write much bigger regions
of memory - to swap two items, you have to read both of them fully, then

 write both of them fully into new locations -

I bet compare will load the whole thing into cache anyway, plus 
contiguous structs may fit into a single line. Sequential storage has 
advantages.



which would make caching
totally useless, whether structs are located sequentially or not.


How's that?


It's
like copying a large file - the cache gets exhausted instantly, and
doesn't speed things up at all.


And the only thing worse then copying a large file is copying a large 
file fragmented in tiny splinters.


--
Dmitry Olshansky

Re: std.math performance (SSE vs. real)

2014-07-05 Thread Iain Buclaw via Digitalmars-d

On 5 July 2014 16:13, via Digitalmars-d digitalmars-d@puremagic.com wrote:
 On Saturday, 5 July 2014 at 15:09:28 UTC, Iain Buclaw via Digitalmars-d
 wrote:

 This is a library problem, not a language problem.  In this case
 std.math uses real everywhere when perhaps it shouldn't.


 If x/y leads to a division by zero trap when it should not, then it isn't a
 library problem.


Right, it's a quirk of the CPU.

Re: Languages for servers (Go, D, and more)

2014-07-05 Thread Brian Rogoff via Digitalmars-d


On Friday, 4 July 2014 at 19:46:40 UTC, Remo wrote:

On Friday, 4 July 2014 at 16:16:35 UTC, Meta wrote:
With @nogc and the -vgc compiler switch, I think it would 
fairly easy now to do C-style memory management and know that 
there are no hidden GC allocations in your program. Whether 
you would want to do this in D is another story.



Who want to use C-style memory management today ?


Lots of interesting programs and libraries are written 
specifically in C, not C++, even today. But, as others have 
pointed out, you can use RAII in D and as time goes on even more 
advanced memory management libraries will become available.


But my point was merely that D is somewhat hamstrung by virtue of 
being a garbage collected language with a not so great GC, and 
some complexities around not using it. Not an insurmountable 
problem if you're committed to using D, but when you are making a 
decision about what to use, it is a factor. For writing various 
server programs, if you want to work with a GC'ed, compiled to 
native code language, Go may be a much better choice than D right 
now.


This is a problem with being such a wide spectrum language: D has 
to compete with high level GC'ed languages and will also need to 
compete with low level languages without GCs. That's a tough row 
to hoe!

Re: Languages for servers (Go, D, and more)

2014-07-05 Thread Dicebot via Digitalmars-d


On Friday, 4 July 2014 at 21:15:00 UTC, Chris Cain wrote:

On Friday, 4 July 2014 at 21:09:05 UTC, Remo wrote:
By C++ style memory management I do not mean naked 
new/delete or malloc/free.

What I mean is RAII, smart pointers and destructor's.
What is the proper replacement for std::unique_ptr and 
std::shared_ptr in D2 ?

Of course with move support for unique_ptr :)


Ah, I see what you mean now. D has that:

http://dlang.org/phobos/std_typecons.html#.Unique
http://dlang.org/phobos/std_typecons.html#.RefCounted

But they probably need some decent updating for use with @nogc 
and more modern D style, though.


Also the Unique pointer also works with std.algorithm.move (in 
addition to its release method which could be deprecated, I 
think... not sure why it needs it when we have 
std.algorithm.move).


This is what I have been referring to in my earlier comment. 
These utilities provide RAII experience very similar to one in 
C++ and work pretty good if you stick to certain style of 
programming. But they are implemented by using struct wrappers 
and all polymorphic traits are lost.


C++ does not have this strong distinction between structs and 
classes resulting in a bit more flexible RAII application. 
Writing applications in C++ style is certainly possible but may 
require some rather advanced knowledge of what can and what can't 
be done. @nogc helps here a lot.

Re: std.math performance (SSE vs. real)

On Saturday, 5 July 2014 at 16:24:28 UTC, Iain Buclaw via 
Digitalmars-d wrote:

Right, it's a quirk of the CPU.


It's a precision quirk of floating point that has to be defined, 
and different CPUs follow different definitions. Within IEEE754 
it can of course also differ, since it does not prevent higher 
precision than specified.


http://en.wikipedia.org/wiki/Denormal_number

SCons and D

SCons 2.3.2 has been released which has the revamped D tooling.

I appreciate Dub is becoming the build system of choice for new D
projects, so I will maintain the D support in SCons but definitely in
maintenance mode rather than development mode. 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: Optimizing Java using D

2014-07-05 Thread Daniel Murphy via Digitalmars-d


Wanderer  wrote in message news:jbvbufgyhbjrkpukr...@forum.dlang.org...


For pair of integers, you can use long and sort an array of longs.


Awesome, now your sort order depends on processor endianness!

Storing structs in contiguous memory is sometimes better for some things. 
The fact that sometimes it isn't better doesn't change this, but for some 
reason you've pointed out disadvantages...  What point are you trying to 
make?

Re: Cryptography and D

2014-07-05 Thread Nick Sabalausky via Digitalmars-d


On 7/5/2014 8:23 AM, Kagamin wrote:


There was a study, showing that most security vulnerabilities are caused
by client code rather than cryptographic library code.


Interesting. Link?


For example, how
would you prevent client code from generating weak encryption keys or
from using weak algorithm for hash comparison, or how would you force it
to do what's not required to get the code compiled? How would you do
that with the quality of library code? Even if you can do that, it's
still not a cryptographic task, but a general programming task, the
standard only hints you that those things are necessary.


FWIW, DAuth (pending a possible name change, to prevent confusion with 
the completely unrelated OAuth) maintains a list of non-recommended algos:


  https://github.com/Abscissa/DAuth/blob/master/src/dauth/core.d#L109

And, by default, it will error out (at compile-time whenever possible) 
if the application code attempts to use any such algorithm:


  https://github.com/Abscissa/DAuth/blob/master/src/dauth/core.d#L169

Getting around the error requires acknowledging your intent via 
-version=DAuth_AllowWeakSecurity


Also, DAuth encourages passwords to be stored in a special structure:

  https://github.com/Abscissa/DAuth/blob/master/src/dauth/core.d#L311

which attempts to zero-out the password from memory as early as it can 
(and encourages the user to populate it via char[] not string to avoid 
having an un-wipable immutable plain-text copy in memory. See 
'toPassword' vs 'dupPassword'). I'm certain the implementation can be 
improved. And I'd kinda like to make it scoped if I can, instead of 
refcounted. But it's something.


Obviously there are natural limits to these measures, so it can't 
*guarantee* anything, only help guide the application developer. And it 
doesn't/can't address all possible issues. But it's at least something.

Re: Optimizing Java using D

2014-07-05 Thread Timon Gehr via Digitalmars-d


On 07/05/2014 07:07 PM, Daniel Murphy wrote:

Wanderer  wrote in message news:jbvbufgyhbjrkpukr...@forum.dlang.org...


For pair of integers, you can use long and sort an array of longs.


Awesome, now your sort order depends on processor endianness!


?

k=i32|j, i=k32, j=k(1L32)-1.

Re: Cryptography and D


On Sunday, 29 June 2014 at 07:19:49 UTC, Adam Wilson wrote:
On Sat, 28 Jun 2014 23:08:51 -0700, Charles 
charles.hoskin...@gmail.com wrote:



Is there a native D crypto library like Crypto++?


No. And for good reason. Building a cryptography library is an 
extremely dificult proposition. Even after you've completed the 
build, you still face a trust problem. You need to convince 
people that your library is not subject to a myriad of 
side-channel attacks. The only way to do that is to battle-test 
is, which requires that people use it in the first place. The 
philosophy of the D community is to binding to more trusted and 
tested libraries.




I used to think th

Re: Cryptography and D


On Sunday, 29 June 2014 at 07:19:49 UTC, Adam Wilson wrote:
On Sat, 28 Jun 2014 23:08:51 -0700, Charles 
charles.hoskin...@gmail.com wrote:



Is there a native D crypto library like Crypto++?


No. And for good reason. Building a cryptography library is an 
extremely dificult proposition. Even after you've completed the 
build, you still face a trust problem. You need to convince 
people that your library is not subject to a myriad of 
side-channel attacks. The only way to do that is to battle-test 
is, which requires that people use it in the first place. The 
philosophy of the D community is to binding to more trusted and 
tested libraries.




I used to think that. A few years ago, I looked into OpenSSL, 
noticed several horrors. Several of them mentioned here:


https://www.youtube.com/watch?v=GnBbhXBDmwU

I had the same reasoning: crytpo is hard and these guys know much 
more than I do.


They don't. The simple fact they are are using C to build 
security related basic block show that they have no idea what 
they are doing. No bound check, no memory safety, integer 
overflow is undefined behavior (which mean that even if you 
remember to check for it, you are not checking for it).

Re: Cryptography and D


On Sunday, 29 June 2014 at 18:47:56 UTC, Xinok wrote:
Proper cryptographic libraries are written in such a way to 
mitigate these types of attacks. It's a complex field of study 
and something best left to the experts.


Current crypto libs, aren't capable of doing bound checking 
properly, that should raise in you some doubt about how they 
handle side channels.

Re: SCons and D

2014-07-05 Thread H. S. Teoh via Digitalmars-d

On Sat, Jul 05, 2014 at 06:00:40PM +0100, Russel Winder via Digitalmars-d wrote:
 SCons 2.3.2 has been released which has the revamped D tooling.
 
 I appreciate Dub is becoming the build system of choice for new D
 projects, so I will maintain the D support in SCons but definitely in
 maintenance mode rather than development mode. 
[...]

I still use SCons for my personal projects, so I really appreciate the
maintenance, even if it's no longer actively developed.


T

-- 
The problem with the world is that everybody else is stupid.

Re: Cryptography and D

2014-07-05 Thread Walter Bright via Digitalmars-d


On 6/29/2014 1:12 AM, Brad Roberts via Digitalmars-d wrote:

A safe rule of thumb with crypto code / libraries:  If the thought of writing
that type of code doesn't scare you for at least a dozen or so reasons, you
don't know enough to tread in that playground.  Or you're one of the damned few
people on the planet qualified and are already working on one.


In a way, it's a bit like writing FP math functions. If using a college calculus 
book as an implementation guide, the results will be algorithmically correct but 
quite wrong, as FP doesn't behave like math. Getting them right is something 
that PhD's in comp sci do.


Crypto takes that and squares the difficulty.

If someone wants to learn about crypto by writing crypto libraries in D, I'm all 
for it.


But I'm not willing to make those part of the official D repository, with its 
implicit endorsement that people could rely on them for critical applications 
such as, say, banking transactions.


What we can do is simply provide a D interface to existing, vetted C crypto 
libraries. The Deimos project is a fine place for those.

Re: Cryptography and D

2014-07-05 Thread Nick Sabalausky via Digitalmars-d


On 7/5/2014 5:10 PM, Walter Bright wrote:

On 6/29/2014 1:12 AM, Brad Roberts via Digitalmars-d wrote:

A safe rule of thumb with crypto code / libraries:  If the thought of
writing
that type of code doesn't scare you for at least a dozen or so
reasons, you
don't know enough to tread in that playground.  Or you're one of the
damned few
people on the planet qualified and are already working on one.


In a way, it's a bit like writing FP math functions. If using a college
calculus book as an implementation guide, the results will be
algorithmically correct but quite wrong, as FP doesn't behave like math.
Getting them right is something that PhD's in comp sci do.

Crypto takes that and squares the difficulty.



Inaccurate comparison.

First of all, FP math is an approximation of true real-number 
mathematics. But crypto algorithms (at least any of the ones I've seen, 
and definitely the ones I've implemented) are based on the same discrete 
integer math used by computers and low-level code. NIST's docs even go 
out of their way to formally describe all the nuances of the operations 
their algos use which, surprise, are identical to CPU integer arithmetic 
(at least x86 anyway, I'm not well-versed on ARM but I'd be very 
surprised if it's really *that* different).


Secondly, if the difficulty you're referring to is all the various 
side-channel attacks (like buffer overflows, timing attack, etc), then 
you're conflating crypto and security. The two are certainly related, 
but they are NOT the same. These side-channel attack issues are NOT 
something specific to crypto code, they are equally applicable to *all* 
code that has security-related implications, which includes FAR more 
than just crypto. It goes all the way up through application-level code, 
and even into system administration. Implementing a crypto algorithm is 
(comparatively speaking, of course) the easy part.



If someone wants to learn about crypto by writing crypto libraries in D,
I'm all for it.

But I'm not willing to make those part of the official D repository,
with its implicit endorsement that people could rely on them for
critical applications such as, say, banking transactions.


 What we can do is simply provide a D interface to existing, vetted C
 crypto libraries. The Deimos project is a fine place for those.

With respect: Oh hell no. No, no, no no no.

1. As others have already said, C is terrible for security libs. Even if 
D isn't ideal, it's still vastly better.


2. Just because a C-based crypto lib is popular and well-regarded 
doesn't mean it's as secure and reliable as people think. See what 
others here have said about OpenSSL (hint: Heartbleed is just *one* of 
the issues).


3. Too late anyway: See std.digest. Besides, if anything, std.digest is 
arguably *worse* because (until 2.066) it only provides the worst 
choices. std.random isn't much better. Granted, it doesn't claim to be 
crypto-grade, but it doesn't clearly state that it *isn't* and that's 
just as bad: People are going to to decide (incorrectly) they can use it 
to generate salts or tokens or whatever, and they will do so. Heck, 
*I've* even done it, and *I'm* someone who actually knows better.

redundant storage class 'const

2014-07-05 Thread Paul D Anderson via Digitalmars-d

The getValueX functions below differ only in the number and 
placing of the keyword 'const'.


The compiler rejects the first (with 'const const' prefix), as 
expected (Error: redundant storage class 'const').


The second (with prefix 'const', suffix 'const') is accepted. It 
looks strange but is apparently valid code (cf Bugs 4070  9020).


The fourth (with multiple 'const' suffixed) does not generate an 
error. This looks like a bug to me. Is it?


public class cls {
private int _value;

this(int value) {
_value = value;
}

//	public const const int getValue1() {  // Error: redundant 
storage class 'const'

//  return _value;
//  }
public const int getValue2() const {  // No error
return _value;
}
public int getValue3() const {  // No error
return _value;
}
public int getValue4() const const const {  // No error
return _value;
}
}

As a side note, the error message on the first function is 
succinct and comprehensible. We can probably close Bug 9422.

Re: redundant storage class 'const


Paul D Anderson:

The fourth (with multiple 'const' suffixed) does not generate 
an error. This looks like a bug to me. Is it?


The situation with accepting or not accepting those tags attached 
to functions is a terrible mess since several years, at 
ridiculous levels. Fixing that mess will cause lot of D code to 
break, assuming someone someday will want to fix that awful mess, 
but I can't assume that any more.


Look at this Issue 
https://d.puremagic.com/issues/show_bug.cgi?id=3934 for some 
humorous examples fit more for the Monty Python and the Flying 
Circus than a serious language.


Bye,
bearophile

Re: redundant storage class 'const

2014-07-05 Thread Timon Gehr via Digitalmars-d


On 07/06/2014 12:39 AM, bearophile wrote:


Look at this Issue https://d.puremagic.com/issues/show_bug.cgi?id=3934
for some humorous examples fit more for the Monty Python and the Flying
Circus than a serious language.


While there are some oddities there, many (most?) reports in that issue 
are invalid. I'd have preferred separate issues for unrelated cases.

Re: redundant storage class 'const


Timon Gehr:


I'd have preferred separate issues for unrelated cases.


Take a look at the report date, Timon: 2010-03-11, in the 
meantime I have learnt a thing or two regarding reporting 
compiler bugs :-)


Bye,
bearophile

Re: Cryptography and D

2014-07-05 Thread Dmitry Olshansky via Digitalmars-d


05-Jul-2014 23:33, deadalnix пишет:

On Sunday, 29 June 2014 at 07:19:49 UTC, Adam Wilson wrote:

On Sat, 28 Jun 2014 23:08:51 -0700, Charles
charles.hoskin...@gmail.com wrote:


Is there a native D crypto library like Crypto++?


No. And for good reason. Building a cryptography library is an
extremely dificult proposition. Even after you've completed the build,
you still face a trust problem. You need to convince people that your
library is not subject to a myriad of side-channel attacks. The only
way to do that is to battle-test is, which requires that people use it
in the first place. The philosophy of the D community is to binding to
more trusted and tested libraries.



I used to think that. A few years ago, I looked into OpenSSL, noticed
several horrors. Several of them mentioned here:

https://www.youtube.com/watch?v=GnBbhXBDmwU

I had the same reasoning: crytpo is hard and these guys know much more
than I do.


Indeed a common misconception and I would recommend for anybody thinking 
otherwise to actually go ahead and read e.g. that damn OpenSSL source 
code. Huge and old C libraries are a security problem in their own 
right, without even looking further for potential theoretical faults.



They don't. The simple fact they are are using C to build security
related basic block show that they have no idea what they are doing. No
bound check, no memory safety, integer overflow is undefined behavior
(which mean that even if you remember to check for it, you are not
checking for it).



--
Dmitry Olshansky

Re: Cryptography and D

2014-07-05 Thread Xinok via Digitalmars-d


On Saturday, 5 July 2014 at 19:33:31 UTC, deadalnix wrote:
I used to think that. A few years ago, I looked into OpenSSL, 
noticed several horrors. Several of them mentioned here:


https://www.youtube.com/watch?v=GnBbhXBDmwU

I had the same reasoning: crytpo is hard and these guys know 
much more than I do.


They don't. The simple fact they are are using C to build 
security related basic block show that they have no idea what 
they are doing. No bound check, no memory safety, integer 
overflow is undefined behavior (which mean that even if you 
remember to check for it, you are not checking for it).


If you don't trust OpenSSL, nobody said you have to use it. There 
are plenty of alternatives available. The fact still remains, 
implementing your own crypto is a very bad idea.


Why implement a crypto lib in C?

(1) Maximum exposure - If a programming language has more than 
100 users, chances are, there's an OpenSSL binding available for 
that language. C is an ideal language to make something available 
for as many platforms and environments as possible.


(2) Determinism - If your intention is to implement crypto that 
is impervious to side-channel attacks, you need a language that's 
close to the metal and will behave how you expect it to. For 
example, Java would be a poor choice because things like garbage 
collection and JITing makes code highly non-deterministic.

Re: Cryptography and D

2014-07-05 Thread Walter Bright via Digitalmars-d


On 7/5/2014 12:33 PM, deadalnix wrote:

I used to think that. A few years ago, I looked into OpenSSL, noticed several
horrors. Several of them mentioned here:

https://www.youtube.com/watch?v=GnBbhXBDmwU

I had the same reasoning: crytpo is hard and these guys know much more than I 
do.

They don't. The simple fact they are are using C to build security related basic
block show that they have no idea what they are doing. No bound check, no memory
safety, integer overflow is undefined behavior (which mean that even if you
remember to check for it, you are not checking for it).


Sure, but nobody is going to blame us for it :-) whereas they will for an 
official D implementation.

Re: SCons and D

2014-07-05 Thread Andy Smith via Digitalmars-d


On Saturday, 5 July 2014 at 20:54:25 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sat, Jul 05, 2014 at 06:00:40PM +0100, Russel Winder via 
Digitalmars-d wrote:

SCons 2.3.2 has been released which has the revamped D tooling.

I appreciate Dub is becoming the build system of choice for 
new D
projects, so I will maintain the D support in SCons but 
definitely in

maintenance mode rather than development mode.

[...]

I still use SCons for my personal projects, so I really 
appreciate the

maintenance, even if it's no longer actively developed.


T


Yeah ditto for me still use scons for some mixed D/C devel 
work.


Cheers,

A

Re: Cryptography and D


On Saturday, 5 July 2014 at 23:45:47 UTC, Xinok wrote:
If you don't trust OpenSSL, nobody said you have to use it. 
There are plenty of alternatives available. The fact still 
remains, implementing your own crypto is a very bad idea.




It seems to be the consensus. In the meantime, people like Mark 
Karpeles build their own implementation of SSH in PHP, and 
proceed to run a multimillion dollar exchange ( MtGox ).


Building your own crypto is a bad idea. And you know who ignore 
bad idea ? Bad programmers. As a results, they are the one 
building crypto libs. And you know what is a worse idea than 
making your own crypto lib ? Letting Dunning-Kruger lemmings do 
it for you.



Why implement a crypto lib in C?

(1) Maximum exposure - If a programming language has more than 
100 users, chances are, there's an OpenSSL binding available 
for that language. C is an ideal language to make something 
available for as many platforms and environments as possible.




This is very true. However, as each plateform has its own 
characteristics, you ends up not being able to port that simply, 
and worse, you can break security without knowing it doing so.


I understand the social aspect of it, but from a security POV, 
this is a neat loss.


I'm not sure if another approach is possible. It is clear that 
nobody care about security until catastrophes happens. At least, 
the recent event waked up many people on how bad the state of 
affair is, and how clueless the people handling it right now are.


(2) Determinism - If your intention is to implement crypto that 
is impervious to side-channel attacks, you need a language 
that's close to the metal and will behave how you expect it 
to. For example, Java would be a poor choice because things 
like garbage collection and JITing makes code highly 
non-deterministic.


D is an option here. Anything that isn't system related obviously 
isn't, as you must ensure that you clean the memory behind you.

Re: Cryptography and D


On Sunday, 6 July 2014 at 00:18:19 UTC, Walter Bright wrote:

On 7/5/2014 12:33 PM, deadalnix wrote:
I used to think that. A few years ago, I looked into OpenSSL, 
noticed several

horrors. Several of them mentioned here:

https://www.youtube.com/watch?v=GnBbhXBDmwU

I had the same reasoning: crytpo is hard and these guys know 
much more than I do.


They don't. The simple fact they are are using C to build 
security related basic
block show that they have no idea what they are doing. No 
bound check, no memory
safety, integer overflow is undefined behavior (which mean 
that even if you

remember to check for it, you are not checking for it).


Sure, but nobody is going to blame us for it :-) whereas they 
will for an official D implementation.


I understand. That is reasonable position. The CS guy in me is 
crying, but we got to pick our battle.

Re: Cryptography and D

2014-07-05 Thread Walter Bright via Digitalmars-d


On 7/5/2014 6:54 PM, deadalnix wrote:

On Sunday, 6 July 2014 at 00:18:19 UTC, Walter Bright wrote:

On 7/5/2014 12:33 PM, deadalnix wrote:

I used to think that. A few years ago, I looked into OpenSSL, noticed several
horrors. Several of them mentioned here:

https://www.youtube.com/watch?v=GnBbhXBDmwU

I had the same reasoning: crytpo is hard and these guys know much more than I
do.

They don't. The simple fact they are are using C to build security related basic
block show that they have no idea what they are doing. No bound check, no memory
safety, integer overflow is undefined behavior (which mean that even if you
remember to check for it, you are not checking for it).


Sure, but nobody is going to blame us for it :-) whereas they will for an
official D implementation.


I understand. That is reasonable position. The CS guy in me is crying, but we
got to pick our battle.


Yeah I know, I'd like to roll our own, too!

Re: Optimizing Java using D

2014-07-05 Thread Wanderer via Digitalmars-d


On Saturday, 5 July 2014 at 16:03:17 UTC, Dmitry Olshansky wrote:
There are trade-offs. The world is not black and white and I 
don't follow 'one rule everywhere'.


This is not a trade-off at all. You suggested to keep database 
records linearly, with space gaps between records to support 
tiny updates. Without serious updates, this is major waste of 
space. With them, your design won't save the day, because any gap 
will be eventually consumed and without fragmentation/reordering, 
the storage will fail.


FYI, nowaday popular databases aren't designed this way, exactly 
for the reasons I described above. All databases I worked with 
(MySQL, Oracle and Firebird) hold records in very compact way, 
without a single byte gaps, with ability of fragmentation, and 
without total physical ordering. So at least designers of these 
DBMS have agreed that your design is not practical.


Pointers are perfectly fine as long as there is no pointer 
arithmetic.


Wrong. Merely holding a pointer (i.e. a physical address) is 
unsafe already. Non-deep serialization, or any other 
preservation of such a struct and GC is unable to keep the 
track of pointers. GC moves the object around or deletes it, and 
you have a tiny black hole in your app.


Which is hopelessly admitting defeat. A pair may have 
non-trivial comparator. And a minor step beyond that such as a 
pair of double and integer and it fails completely.


I said above: in any non-trivial case, use classes instead of 
overly-clever structures. And if you really, really need 
premature optimization, there is java.nio and buffers. Create 
ByteBuffer (direct one if you need super optimized solution) and 
treat slices of it as structs. That's possible and easy to 
implement, but really not needed in practice because all you get 
is 0.1% of memory saving and no gain in speed.


And there Java-style indirection-happy classes shine. For 
instance modeling any complex stuff with classes alone would 
lead to things like:

House--reference-Bedroom---reference--Bed--reference--Pillow

Which is incredible waste of memory and speed on something so 
simple.


That's not complex. That's very simple. It would become slightly 
more complex if all house parts implemented the same root 
interface and basic operations, like examining what's around and 
finding an object given by its path or properties, or throwing an 
extra pillow or two onto the same bed. All that is just a dream 
for structs.


Copy constructors or in D parlance postblits. There is also CoW 
and whatnot. In fact swap doesn't create a copy in D, it just 
does a bitwise swap in-place.


And here we have a tough choice for structs with pulled subdata 
for efficiency: either assignment operator copies that data too 
(making routines like sort to perform horribly slow), or they 
perform only shallow copy, causing undue sharing of data and 
violating the whole struct value philosophy.


Disagree - the moment a cache line is loaded it doesn't matter 
how much you read in this line. Even a tiny read missing a 
cache is paid in full.


But the amount of these missed reads is low, so less amount of 
cache is invalidated. CPU cache is not a single page that gets 
invalidated as a whole, it's more like many small subpages, each 
of them is treaten individually.


If you're really into the low-level mumbo jumbo, here are two 
more aspects for you to consider.


1. Since indirection does not require the object contents to be 
moved around while sorting, these objects can be read into cache 
once and never invalidated later - unlike right in place 
structs which invalidate CPU cache each time a swap is performed. 
That is a huge cache win already.


2. Don't forget that new objects are created in eden space in 
Java - which is essentially the stack area. Very fast, compact, 
sequential memory. If your array fits in eden (and that's surely 
true for the forest problem this thread has started from), then 
allocating array of objects is essentially the same as allocating 
array of structs: object contents aren't scattered in memory 
but are located one-after-one without gaps between them. That 
greatly aids caching as well. The main difference between eden 
and array of structs is that the allocation of the former never 
fails (assuming there's enough memory), only gets slightly slower 
in the worst case, and allocation of the latter can fail because 
stack overflow error or too much memory fragmentation oops, 
even if there's enough free memory.


And the only thing worse then copying a large file is copying a 
large file fragmented in tiny splinters.


You surely meant reading here, not copying. Copying large 
fragmented file is as slow as copying large unfragmented file, 
because writing operations are the bottleneck here.

Re: Optimizing Java using D

2014-07-05 Thread Timon Gehr via Digitalmars-d


On 07/06/2014 05:19 AM, Wanderer wrote:

On Saturday, 5 July 2014 at 16:03:17 UTC, Dmitry Olshansky wrote:

...
Pointers are perfectly fine as long as there is no pointer arithmetic.


Wrong. Merely holding a pointer (i.e. a physical address) is unsafe
already. Non-deep serialization, or any other preservation of such a
struct and GC is unable to keep the track of pointers. GC moves the
object around or deletes it, and you have a tiny black hole in your app.
...


That's not 'merely holding a pointer' and it applies to class references 
just as much.



...

If you're really into the low-level mumbo jumbo, here are two more
aspects for you to consider.

1. Since indirection does not require the object contents to be moved
around while sorting, these objects can be read into cache once and
never invalidated later  - unlike right in place structs which
invalidate CPU cache each time a swap is performed. That is a huge cache
win already.
...


This is just random nonsense.

Re: GC behavior and Allocators

2014-07-05 Thread Brian Schott via Digitalmars-d


On Friday, 4 July 2014 at 17:05:32 UTC, David Nadlinger wrote:

On Friday, 4 July 2014 at 14:47:12 UTC, Chris Cain wrote:

Is there a way to lock the GC currently?


There are critical regions in core.thread. While in such a 
region, your thread will never be suspended, effectively also 
precluding the GC from running. They are a rather dangerous 
tool though, use them only if absolutely required and on small, 
controlled pieces of code.


David


So something like this would work?

void* GCAwareRealloc(void* ptr, size_t size)
{
  import core.thread;
  void* r;
  thread_enterCriticalRegion();
  scope (exit) thread_exitCriticalRegion();
  r = realloc(ptr, size);
  // Assuming that addRange performs an update of size
  GC.addRange(r, size);
  return r;
}

Re: Cryptography and D

2014-07-05 Thread Rikki Cattermole via Digitalmars-d

On 6/07/2014 6:06 a.m., Nick Sabalausky wrote:

On 7/5/2014 8:23 AM, Kagamin wrote:

There was a study, showing that most security vulnerabilities are caused
by client code rather than cryptographic library code.

Interesting. Link?

For example, how
would you prevent client code from generating weak encryption keys or
from using weak algorithm for hash comparison, or how would you force it
to do what's not required to get the code compiled? How would you do
that with the quality of library code? Even if you can do that, it's
still not a cryptographic task, but a general programming task, the
standard only hints you that those things are necessary.

FWIW, DAuth (pending a possible name change, to prevent confusion with
the completely unrelated OAuth) maintains a list of non-recommended algos:

https://github.com/Abscissa/DAuth/blob/master/src/dauth/core.d#L109

And, by default, it will error out (at compile-time whenever possible)
if the application code attempts to use any such algorithm:

https://github.com/Abscissa/DAuth/blob/master/src/dauth/core.d#L169

Getting around the error requires acknowledging your intent via
-version=DAuth_AllowWeakSecurity

Also, DAuth encourages passwords to be stored in a special structure:

https://github.com/Abscissa/DAuth/blob/master/src/dauth/core.d#L311

which attempts to zero-out the password from memory as early as it can
(and encourages the user to populate it via char[] not string to avoid
having an un-wipable immutable plain-text copy in memory. See
'toPassword' vs 'dupPassword'). I'm certain the implementation can be
improved. And I'd kinda like to make it scoped if I can, instead of
refcounted. But it's something.

Obviously there are natural limits to these measures, so it can't
*guarantee* anything, only help guide the application developer. And it
doesn't/can't address all possible issues. But it's at least something.

For reference, Cmsed's password authentication that is built in will
automatically hash passwords and will not store in any way the plain
text version [0].
Also supports upgrading hashes as needed. From older algorithms to newer
preferred ones.

[0]
https://github.com/rikkimax/Cmsed/blob/master/source/user/cmsed/user/models/userauth.d#L57

Re: SCons and D

2014-07-05 Thread Vlad Levenfeld via Digitalmars-d-learn

On Sun, 2014-07-06 at 01:36 +, Andy Smith via Digitalmars-d wrote:
 On Saturday, 5 July 2014 at 20:54:25 UTC, H. S. Teoh via
 Digitalmars-d wrote:
  On Sat, Jul 05, 2014 at 06:00:40PM +0100, Russel Winder via 
  Digitalmars-d wrote:
  SCons 2.3.2 has been released which has the revamped D tooling.
  
  I appreciate Dub is becoming the build system of choice for 
  new D
  projects, so I will maintain the D support in SCons but 
  definitely in
  maintenance mode rather than development mode.
  [...]
 
  I still use SCons for my personal projects, so I really 
  appreciate the
  maintenance, even if it's no longer actively developed.
 
 
  T
 
 Yeah ditto for me still use scons for some mixed D/C devel 
 work.

Thanks for letting me know there is a demand :-)

Now that the new D support structure is in place in the SCons mainline,
all bug reports and enhancement requests can be dealt with and the
results appear in the next release as the normal workflow. So feel free
to make reports.

Sadly SCons is still using Tigris for bug management as it is not clear
what the better alternative is, nor how to transfer all the extant
reports to a new system. It is being worked on though. 

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: Problem Linking Phobos git master

2014-07-05 Thread Nordlöw


On Saturday, 5 July 2014 at 02:13:39 UTC, Kapps wrote:
Possibly something related to: 
https://github.com/D-Programming-Language/dmd/pull/3715


Have you tried updating to git master today?


Yes, unfortunately with the same problem (with ld.bfd).

With ld.gold I get a huge amount of errors:

../dmd/src/dmd 
-I/home/per/opt/x86_64-unknown-linux-gnu/dmd/include/d2 -shared 
-debuglib= -defaultlib= 
-ofgenerated/linux/release/64/libphobos2.so.0.66.0 
-L-soname=libphobos2.so.0.66 
../druntime/lib/libdruntime-linux64so.a -L-ldl 
-Lgenerated/linux/release/64/libcurl_stub.so std/algorithm.d 
std/array.d std/ascii.d std/base64.d std/bigint.d std/bitmanip.d 
std/compiler.d std/complex.d std/concurrency.d std/conv.d 
std/cstream.d std/csv.d std/datetime.d std/demangle.d 
std/encoding.d std/exception.d std/file.d std/format.d 
std/functional.d std/getopt.d std/json.d std/math.d 
std/mathspecial.d std/mmfile.d std/numeric.d std/outbuffer.d 
std/parallelism.d std/path.d std/process.d std/random.d 
std/range.d std/regex.d std/signals.d std/socket.d 
std/socketstream.d std/stdint.d std/stdio.d std/stdiobase.d 
std/stream.d std/string.d std/syserror.d std/system.d 
std/traits.d std/typecons.d std/typetuple.d std/uni.d std/uri.d 
std/utf.d std/uuid.d std/variant.d std/xml.d std/zip.d std/zlib.d 
std/c/linux/linux.d std/c/linux/socket.d etc/c/curl.d 
etc/c/sqlite3.d etc/c/zlib.d std/c/fenv.d std/c/locale.d 
std/c/math.d std/c/process.d std/c/stdarg.d std/c/stddef.d 
std/c/stdio.d std/c/stdlib.d std/c/string.d std/c/time.d 
std/c/wcharh.d std/internal/digest/sha_SSSE3.d 
std/internal/math/biguintcore.d std/internal/math/biguintnoasm.d 
std/internal/math/biguintx86.d std/internal/math/gammafunction.d 
std/internal/math/errorfunction.d std/internal/processinit.d 
std/internal/unicode_tables.d std/internal/scopebuffer.d 
std/internal/unicode_comp.d std/internal/unicode_decomp.d 
std/internal/unicode_grapheme.d std/internal/unicode_norm.d 
std/net/isemail.d std/net/curl.d std/digest/digest.d 
std/digest/crc.d std/digest/md.d std/digest/ripemd.d 
std/digest/sha.d std/container/package.d std/container/array.d 
std/container/binaryheap.d std/container/dlist.d 
std/container/rbtree.d std/container/slist.d std/container/util.d 
generated/linux/release/64/etc/c/zlib/adler32.o 
generated/linux/release/64/etc/c/zlib/compress.o 
generated/linux/release/64/etc/c/zlib/crc32.o 
generated/linux/release/64/etc/c/zlib/deflate.o 
generated/linux/release/64/etc/c/zlib/gzclose.o 
generated/linux/release/64/etc/c/zlib/gzlib.o 
generated/linux/release/64/etc/c/zlib/gzread.o 
generated/linux/release/64/etc/c/zlib/gzwrite.o 
generated/linux/release/64/etc/c/zlib/infback.o 
generated/linux/release/64/etc/c/zlib/inffast.o 
generated/linux/release/64/etc/c/zlib/inflate.o 
generated/linux/release/64/etc/c/zlib/inftrees.o 
generated/linux/release/64/etc/c/zlib/trees.o 
generated/linux/release/64/etc/c/zlib/uncompr.o 
generated/linux/release/64/etc/c/zlib/zutil.o
std/mmfile.d(344): Deprecation: alias 
core.sys.posix.sys.mman.MAP_ANON is deprecated - Please use 
core.sys.linux.sys.mman for non-POSIX extensions
std/mmfile.d(344): Deprecation: alias 
core.sys.posix.sys.mman.MAP_ANON is deprecated - Please use 
core.sys.linux.sys.mman for non-POSIX extensions
/usr/bin/ld: error: 
generated/linux/release/64/libphobos2.so.0.66.o: requires dynamic 
R_X86_64_PC32 reloc against 
'_D6object23__T11_trustedDupTxaTyaZ11_trustedDupFNaNbNeAxaZAya' 
which may overflow at runtime; recompile with -fPIC
/usr/bin/ld: error: 
generated/linux/release/64/libphobos2.so.0.66.o: requires dynamic 
R_X86_64_PC32 reloc against 
'_D6object15__T4_dupTxaTyaZ4_dupFNaNbAxaZAya' which may overflow 
at runtime; recompile with -fPIC
/usr/bin/ld: error: 
generated/linux/release/64/libphobos2.so.0.66.o: requires dynamic 
R_X86_64_PC32 reloc against 
'_D6object14__T7_rawDupTaZ7_rawDupFNaNbANgaZANga' which may 
overflow at runtime; recompile with -fPIC
/usr/bin/ld: error: 
generated/linux/release/64/libphobos2.so.0.66.o: requires dynamic 
R_X86_64_PC32 reloc against '_D11TypeInfo_ya6__initZ' which may 
overflow at runtime; recompile with -fPIC
/usr/bin/ld: error: 
generated/linux/release/64/libphobos2.so.0.66.o: requires dynamic 
R_X86_64_PC32 reloc against 
'_D6object22__T11_trustedDupTxaTaZ11_trustedDupFNaNbNeAxaZAa' 
which may overflow at runtime; recompile with -fPIC
/usr/bin/ld: error: 
generated/linux/release/64/libphobos2.so.0.66.o: requires dynamic 
R_X86_64_PC32 reloc against 
'_D6object14__T4_dupTxaTaZ4_dupFNaNbAxaZAa' which may overflow at 
runtime; recompile with -fPIC
/usr/bin/ld: error: 
generated/linux/release/64/libphobos2.so.0.66.o: requires dynamic 
R_X86_64_PC32 reloc against 
'_D6object14__T7_rawDupTaZ7_rawDupFNaNbANgaZANga' which may 
overflow at runtime; recompile with -fPIC
/usr/bin/ld: error: 
generated/linux/release/64/libphobos2.so.0.66.o: requires dynamic 
R_X86_64_PC32 reloc against 
'_D6object22__T11_trustedDupTxmTmZ11_trustedDupFNaNbNeAxmZAm' 
which may overflow at

Re: Problem Linking Phobos git master

2014-07-05 Thread Nordlöw


On Saturday, 5 July 2014 at 09:54:21 UTC, Nordlöw wrote:

On Saturday, 5 July 2014 at 02:13:39 UTC, Kapps wrote:
Possibly something related to: 
https://github.com/D-Programming-Language/dmd/pull/3715


Have you tried updating to git master today?


Yes, unfortunately with the same problem (with ld.bfd).


There's something wrong with build script that triggers the 
error. I'm looking into it...


/Per

Re: Problem Linking Phobos git master

2014-07-05 Thread Mike Wey via Digitalmars-d-learn


On 07/05/2014 12:13 AM, Nordlöw wrote:

On Ubuntu 14.04 my git master build script for phobos now fails as below.

Why? Help please.

/usr/bin/ld points to /usr/bin/ld.bfd on my system

Terminal echo and error message follows:

../dmd/src/dmd -I/home/per/opt/x86_64-unknown-linux-gnu/dmd/include/d2
-shared -debuglib= -defaultlib= ...


Do you have an DFLAGS environment variable set on your system?

It looks like the environment variable is used instead of the make file 
variable while compiling.


--
Mike Wey

Slow compilation using a lib with template methods

2014-07-05 Thread ParticlePeter via Digitalmars-d-learn


Hello community,

here is a post with multiple questions regarding compile times, 
or rather the optimization of the compile and link process. I 
work with VisualD and am interested in optimizing my projects 
with this utility, hence there will be a similar topic linking 
here, where I explain my solution an projects setup.
One of the advertised advantages of D is compiler speed. Hence I 
think that I do some mistakes, as my ( hobby ) projects consist 
of a quite small code base. The more I learn about the language, 
the more features I use, the more my compile times increase. I 
guess my usage of these features, template in particular, are not 
well designed.


Question 1)
How can I profile my compile times ? I have some guesses, but 
they might be wrong.


Question 2)
Is there a good read about the intermediate files dmd creates 
(e.g. *.obj, *.def), and how they might be utilized to improve 
compile times ( incremental compilation? ) ?


Next I need to explain some details about my codebase:
I use a lib, lets call it MyLib, which consists of about 15 
modules, each 300 lines of code in average. Most of the modules 
consist of one class and some of these classes have one or two 
template methods. I link this lib statically to another ( one ) 
lib I created from some DerelictOrg modules. Projects which use 
MyLib consist of about five modules which have aprox 200 lines of 
code in average. I would say this is a small codebase.
I use MyLib all of these projects, and about the time I 
introduced template methods in MyLib I noticed a slow down in 
compiling and linking ( but I cannot tell for sure that the 
compile time is related to the template method, however lets 
assume it is ). Before that my projects used to build in five 
seconds max, now it is more like 30 seconds, and most of the time 
is spend in building MyLib. My guess is that MyLib is completely 
rebuild when I use it in a projects with differently typed calls 
to the template methods.


Question 3)
How smart is dmd in separating template from non-template code, 
in particular if both codeblocks are defined in the same module / 
class ?
How can I assist dmd in determining and/or keeping files 
necessary for incremental compilation and linking ?


One step deeper into MyLib. All the template methods have only 
one type parameter. I use arbitrary typed Arrays, generate some 
information about the type with compile time reflection ( 
primitive and struct types ), and call a non-template method 
which takes a void[] array and the extracted type information. 
That made me think about GOF Decorator pattern via UFCS. 
Unfortunately, I guess due to the restrictions mentioned in the 
docs for UFCS ( , I do not get it to work. Here is my approach:


/// file LibModule.d
module LibModule;

struct TypeDescriptor { ... }

class NonTemplate {
	void nonTemplateMethod( void[] array , TypeDescriptor 
typeDescriptor )

{ ... }
}

void templateFunction(T)( NonTemplate nonTemplate , T[] array ) {
auto typeDescriptor =  ... /// mindblowing compile-time magic
nonTemplate.nonTemplateMethod( array , typeDescriptor );
}

...

/// Usage in file MainModule.d
module MainModule;

import LibModule;

float[100] floatArray;
auto nonTemplate = new NonTemplate;
nonTemplate.templateFunction( floatArray );
...


Question 4)
This does not work, how can I make it work ?
It also did not work with a separate module TemplateModule for 
templateFunction, tried to import TemplateModule in LibModule as 
well as in MainModule.


Question 5)
Would this improve my compilation speed at all ?
How would I compile and link only non template modules/classes in 
my lib and still be able to use templateFunction in the described 
UFCS way ?


The following question is valid if only I get answer like: Not 
possible due to UFCS restrictions
Specification of UFCS is presented with an example explaining the 
restrictions, which quite confuses me:


Question 6)
The example given as reasoning to UFCS restrictions, isn't that 
using symbol shadowing, which is deprecated ?
How could Walter and Andrei be asked politely to loosen these 
restrictions, as the gain in functionality is significant 
compared to the ( unlikely ? ) example scenario ?


Thanks in advance for any advice.

Cheers, ParticlePeter

Visual D: Settings to Improve compil and link process

2014-07-05 Thread ParticlePeter via Digitalmars-d-learn


Hello Community,

I thought there's a separate forum for VisualD. It did exist when 
VisualD was on DSource, so why not add it here as well? Or am I 
to blind to see?


Anyway, this thread is an addition to my previous one in this 
forum:

http://forum.dlang.org/thread/wkkuvzkzeupyfdpwe...@forum.dlang.org

I noticed increasing compile times in my projects. As I use only 
VisualD I would like to understand how I would shorten compile 
time with this tool.
Brief description to my setup, more details can be fond in the 
other post.
I have one Lib, called MyLib consisting of around 15 modules, one 
class per module, zero to two template methods per class with one 
type parameter each.
All my projects use MyLib, and call the template methods with 
different types. Most of the compile time of any of theses 
projects is spent in rebuilding MyLib.
I am not sure why and where so much time is spent, but is there a 
way to profile my COMPILE time with VisualD?


There are several VisualD project properties which I do not 
understand fully, but hope that they might help, namely:


Configuration Properties - General - Files to clean
Configuration Properties - Compiler - Output - Multiple Object 
Files
Configuration Properties - Compiler - Output - Keep Path From 
Source File


Could not cleaning some files improve compilation ?
Could Multiple Object Files be used to separately compile 
non-template and template code blocks ?

What does Keep Path From Source File do at all ?

It is possible to remove the template methods from my classes, 
create free functions instead and use them in a UFCS way.
Unfortunately I have not figured out UFCS properly, as my 
approaches do not work ( guess due to UFCS restrictions ).


Anyway, would it help ( and is it possible at all ) to put the 
template functions in a separate module so that only the 
corresponding object file requires a recompile ?

I am asking in the context of the Multiple Object Files setting.

I tried to not build MyLib at all, and use the sources directly, 
but the project setup is kind of confusing. Again, there is a 
setting which I seem to not understand fully. So one project, 
lets say MyProject, has only its own module files added to the 
VisualD project. I want the compiler to also use the MyLib source 
files, but do not want to add them to MyProject, reasoning 
bellow. There is one entry in the project properties, which 
should make this behavior possible, but it doses not. Why ?


Configuration Properties - Compiler - General - Additional Imports

As far as I understand this setting, I am supposed to enter 
module search paths. But I do get linker errors when I do not add 
either MyLib.lib to the linker settings or all the source files 
of MyLib to MyProject.


Reasoning why I do not want to do this: I have one solution file 
with the MyLib project and ten projects like MyProject using 
MyLib. I would need to add all the source files to all the 
projects, they would be reachable and editable at 11 different 
location within my solution file. This does not not seem to be a 
clean way to set it up.


Any advice to any or all the thoughts and issues ?

Thanks in advance.

Cheers, ParticlePeter

Re: break on assertion in GDB?

The reason it worked one time and not the other was because the 
other time was an exception, not an assertion. How do I break on 
exceptions?


(ps. is there a guide anywhere to using GDB with D?)

std.algorithm.map with multiple lambdas (2.066.0-b1) (does not compile)

2014-07-05 Thread klasbo via Digitalmars-d-learn


  void main(){
  import std.algorithm, std.stdio;
  auto arr = [1,2,3];
  arr.map!(a + a, a * a).writeln;  //compiles
  arr.map!(a = a + a, a = a * a).writeln; //does not
  }


If I define two functions outside main, it works:


  void main(){
  import std.algorithm, std.stdio;
  auto arr = [1,2,3];
  arr.map!(twoTimes, square).writeln;
  }
  int square(int i){ return i*i; }
  int twoTimes(int i){ return i+i; }


However, if `twoTimes` and `square` are nested inside of main(), 
it fails.


[...]\typetuple.d(550): Error: template instance F!(twoTimes) 
cannot use local 'twoTimes' as parameter to non-global template 
AppliedReturnType(alias f)
[...]\typetuple.d(556): Error: template instance 
maptest.main.staticMap!(AppliedReturnType, twoTimes) error 
instantiating
[...]\algorithm.d(415):instantiated from here: 
staticMap!(AppliedReturnType, twoTimes, square)

.\maptest.d(8):instantiated from here: map!(int[])

The alias declaration
`alias AppliedReturnType(alias f) = typeof(f(r.front));`
... is something I have never seen before.

So I hardcoded/expanded this line:
`alias ReturnTypes = TypeTuple!(AppliedReturnType!(_funs[0]), 
AppliedReturnType!(_funs[1]));`
... which gives me the same error (cannot use local as parameter 
to non-global). So I threw it in a pragma(msg, [...]):
`pragma(msg, TypeTuple!(AppliedReturnType!(_funs[0]), 
AppliedReturnType!(_funs[1])));`
... which printed `(int, int)`, as expected. And also the same 
error.


Wat.

What exactly module in D means?

2014-07-05 Thread Andre Tampubolon via Digitalmars-d-learn

I've been reading the newsgroup for a while, and it seems that one of 
the reason folks like D is because it supports module.


My question is: what does module mean?
A quick google pointed my this page: http://dlang.org/module.html.
Still cannot understand it, though :)

How does it differ from the old C's #include?

For example, consider the hello world in C.

#include stdio.h

int main(void){
printf(%s\n, Hello world...);
return 0;
}

The C preprocessor while replace the line #include stdio.h with the 
content of stdio.h itself.


While in D:

import std.stdio;

void main(){
writeln(Hello world...);
}

Does that mean the compiler take the definition of writeln itself from 
stdio.d and paste it into my program? Pardon my ignorance, because I'm 
not versed in compiler theory.

Trouble initializing a templated class

I'm going through Adam Wilson's talk 'C# to D' and I've gotten 
hung up by one of his examples regarding generic programming in 
D. Specifically, I'm trying to implement the code example found 
here: http://youtu.be/6_xdfSVRrKo?t=16m44s.


I created a templateExp.d file that looks like this:

public class BaseClass {}
public class OtherClass : BaseClass {}

class SomeClass(T : BaseClass)
{
public T[] values;
public void add(T input) { values ~= input; }
}

void main()
{
auto sc = new SomeClass();
OtherClass oc1 = new OtherClass();
OtherClass oc2 = new OtherClass();

sc.add(oc1);
sc.add(oc2);

import std.stdio;
writefln(value count, sc.values.length);
}

When I run the dmd compiler, I get this error:

dmd templateExp.d
	teamplteExp.d(12): Error: class teamplteExp.SomeClass(T : 
BaseClass) is used as a type


How can I initialize this class correctly?

Re: Trouble initializing a templated class

2014-07-05 Thread Vlad Levenfeld via Digitalmars-d-learn


When I run the dmd compiler, I get this error:

dmd templateExp.d
	teamplteExp.d(12): Error: class teamplteExp.SomeClass(T : 
BaseClass) is used as a type




This is actually:
	templateExp.d(12): Error: class templateExp.SomeClass(T : 
BaseClass) is used as a type

Re: Trouble initializing a templated class


On Saturday, 5 July 2014 at 16:47:32 UTC, quakkels wrote:
I'm going through Adam Wilson's talk 'C# to D' and I've gotten 
hung up by one of his examples regarding generic programming in 
D. Specifically, I'm trying to implement the code example found 
here: http://youtu.be/6_xdfSVRrKo?t=16m44s.


I created a templateExp.d file that looks like this:

public class BaseClass {}
public class OtherClass : BaseClass {}

class SomeClass(T : BaseClass)
{
public T[] values;
public void add(T input) { values ~= input; }
}

void main()
{
auto sc = new SomeClass();
OtherClass oc1 = new OtherClass();
OtherClass oc2 = new OtherClass();

sc.add(oc1);
sc.add(oc2);

import std.stdio;
writefln(value count, sc.values.length);
}

When I run the dmd compiler, I get this error:

dmd templateExp.d
	teamplteExp.d(12): Error: class teamplteExp.SomeClass(T : 
BaseClass) is used as a type


How can I initialize this class correctly?


try SomeClass (T): BaseClass

Re: What exactly module in D means?

2014-07-05 Thread Olivier Pisano via Digitalmars-d-learn


No, import is different from include. It does not stupidly copy
and paste its content but tells the compiler to take the module
into account for name resolution. The result may seem similar,
but is much more efficient.

A D module is also a unit of encapsulation (a private declaration
in a module is only accessible from this module, and not from
another one importing it).

Re: Trouble initializing a templated class

2014-07-05 Thread Vlad Levenfeld via Digitalmars-d-learn


On Saturday, 5 July 2014 at 17:17:03 UTC, quakkels wrote:

try SomeClass (T): BaseClass


Not sure which line you want me to change. I don't want 
SomeClass to inherit from BaseClass. Rather, I want T to be 
restricted to classes that inherit from BaseClass.


When I change `class SomeClass(T : BaseClass)` to `class 
SomeClass(T) : BaseClass` I still get the class 
templateExp.SomeClass(T) is used as a type error.


ah, sorry, I misunderstood. It looks like you need to change the 
lin


auto sc = new SomeClass ();

to

auto sc = new SomeClass!BaseClass ();

The compiler complains because SomeClass is a template when you 
call SomeClass() without !() template parameters. It only becomes 
a type once instantiated with parameters.

Re: Trouble initializing a templated class

2014-07-05 Thread Francesco Cattoglio via Digitalmars-d-learn


try SomeClass (T): BaseClass


Not sure which line you want me to change. I don't want SomeClass 
to inherit from BaseClass. Rather, I want T to be restricted to 
classes that inherit from BaseClass.


When I change `class SomeClass(T : BaseClass)` to `class 
SomeClass(T) : BaseClass` I still get the class 
templateExp.SomeClass(T) is used as a type error.

Re: std.algorithm.map with multiple lambdas (2.066.0-b1) (does not compile)

2014-07-05 Thread via Digitalmars-d-learn


This is an instance of these bugs:

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

But seeing that `map` works with a single lambda/local function, 
it should be possible to make it work with several ones too.


For the time being, a simple workaround is to make the local 
functions static:


void main() {
static int square(int i) { return i*i; }
static int twoTimes(int i) { return i+i; }
import std.algorithm, std.stdio;
auto arr = [1,2,3];
arr.map!(twoTimes, square).writeln;
}

Re: What exactly module in D means?


On Saturday, 5 July 2014 at 17:08:01 UTC, Olivier Pisano wrote:

No, import is different from include. It does not stupidly copy
and paste its content but tells the compiler to take the module
into account for name resolution. The result may seem similar,
but is much more efficient.


In fact, try to write the following C code:

int main() {
#include stdio.h
   [whatever else you want]
}

and look at those lovely error messages from the compiler :P

Re: Trouble initializing a templated class

2014-07-05 Thread Marco Cosentino via Digitalmars-d-learn

ah, sorry, I misunderstood. It looks like you need to change 
the lin


auto sc = new SomeClass ();

to

auto sc = new SomeClass!BaseClass ();

The compiler complains because SomeClass is a template when you 
call SomeClass() without !() template parameters. It only 
becomes a type once instantiated with parameters.


Thanks. That did it.

Here's my working program.

public class BaseClass {}
public class OtherClass : BaseClass {}

class SomeClass(T : BaseClass)
{
public T[] values;
public void add(T input) { values ~= input; }
}

void main()
{
auto sc = new SomeClass!BaseClass();
OtherClass oc1 = new OtherClass();
OtherClass oc2 = new OtherClass();

sc.add(oc1);
sc.add(oc2);

import std.stdio;
writefln(value count: %d, sc.values.length);
}

File needs to be closed on Windows but not on Posix, bug?

2014-07-05 Thread Joakim via Digitalmars-d-learn

I ran into this when trying to fix the Phobos unit tests and have 
reduced it down to this test file:


import std.stdio, std.file;

void main() {
auto f = File(test.txt, w);
//f.close();
std.file.remove(test.txt);
}

This compiles and runs fine on linux and the autotester shows 
that it works on all the tested Posix platforms, but it fails on 
Windows with


std.file.FileException@std\file.d(433): test.txt: The process 
cannot access the file because it is being used by another 
process.


Uncommenting the f.close() gets it to work fine on all supported 
platforms, no doubt it has to do with the different OS APIs that 
are being called.


This seems like inconsistent behavior: should I file a bug?

Re: What exactly module in D means?

2014-07-05 Thread Joakim via Digitalmars-d-learn


On Saturday, 5 July 2014 at 16:35:31 UTC, Andre Tampubolon wrote:
I've been reading the newsgroup for a while, and it seems that 
one of the reason folks like D is because it supports module.


My question is: what does module mean?
A quick google pointed my this page: 
http://dlang.org/module.html.

Still cannot understand it, though :)

How does it differ from the old C's #include?

For example, consider the hello world in C.

#include stdio.h

int main(void){
printf(%s\n, Hello world...);
return 0;
}

The C preprocessor while replace the line #include stdio.h 
with the content of stdio.h itself.


While in D:

import std.stdio;

void main(){
writeln(Hello world...);
}

Does that mean the compiler take the definition of writeln 
itself from stdio.d and paste it into my program? Pardon my 
ignorance, because I'm not versed in compiler theory.


You might find the clang docs on C++ modules worthwhile, though 
they do it somewhat differently from D:


http://clang.llvm.org/docs/Modules.html

An #include simply copies and pastes the entire contents of the 
C/C++ header into your source, which can happen over and over 
again in a large project with no include guards, while modules 
are a more sophisticated way of separating code.

Re: File needs to be closed on Windows but not on Posix, bug?

2014-07-05 Thread Adam D. Ruppe via Digitalmars-d-learn


On Saturday, 5 July 2014 at 20:23:03 UTC, Joakim wrote:

This seems like inconsistent behavior: should I file a bug?


This is because the operating systems do it differently; I think 
D is doing the right thing by being a pretty thin wrapper around 
that functionality.


If anything, I'd just say deleting an open file may not be 
permitted in the docs, implying that the user should always close 
it themselves before deleting it.

Re: std.algorithm.map with multiple lambdas (2.066.0-b1) (does not compile)

2014-07-05 Thread klasbo via Digitalmars-d-learn


On Saturday, 5 July 2014 at 19:31:24 UTC, Marc Schütz wrote:

This is an instance of these bugs:

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

But seeing that `map` works with a single lambda/local 
function, it should be possible to make it work with several 
ones too.


For the time being, a simple workaround is to make the local 
functions static:


This problem was introduced when std.algorithm.map was made to 
refuse void functions. But map already did fail void when it gets 
multiple functions, because std.typecons.tuple refuses variables 
of type void (though the error message is cryptic, sure):


Error: variable std.typecons.Tuple!void.Tuple._expand_field_0 
variables cannot be of type void


The only thing map didn't fail was single argument void. This was 
fixed, so why not re-use the same fix for multiple arguments? The 
example below works fine, and gives the new and sensible-er error 
message:



template map(fun...) if (fun.length = 1)
{
auto map(Range)(Range r) if (isInputRange!(Unqual!Range))
{
alias AppliedReturnType(alias f) = typeof(f(r.front));

static if (fun.length  1)
{
import std.functional : adjoin;

import std.typetuple : staticIndexOf;

alias _funs = staticMap!(unaryFun, fun);
alias _fun = adjoin!_funs;

// Attack of the copy-paste and poorly chosen variable name:
foreach(_f; _funs){
static assert(!is(AppliedReturnType!_f == void),
  All mapping functions must not return 
void.);

}
}
else
{
alias _fun = unaryFun!fun;

static assert(!is(AppliedReturnType!_fun == void),
  Mapping function must not return 
void.);


}

return MapResult!(_fun, Range)(r);
}
}


Am I missing something?

Re: implib and system dlls, oh my

2014-07-05 Thread Joakim via Digitalmars-d-learn


On Tuesday, 24 June 2014 at 12:56:28 UTC, Jason King wrote:


I don't know enough about implib to explain it.
But another method that I believe should work is to use linker 
definition files.

It'll allow optlink to work.
Just add it to dmd, actually I believe it needs to be passed 
to Optlink (so -L it).


Another fix, might be to use 64bit, but shouldn't be required.

[0] 
http://www.dsource.org/projects/bindings/wiki/DefFiles/OleAut32


Rikki,
Thank you for your kind attention.  I spewed to the newsgroup 
and googled for an answer in the wrong order.  It appears the 
solution to this problem is the combination of coffimplib + 
windows SDK.  After using those on the SDK's oleaut32.lib I got 
a library with the properly decorated _VarCmp@16.


Not your job, but this could probably be made simpler.


You may want to spearhead the effort to get Win32 support of MSVC 
into D, if you care enough about it.  Rainer has done most of the 
work, you'd just have to turn his patches into pull requests, 
shepherd them through the review process, and maybe add some 
polish:


http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmar...@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com

Compile time definitions

2014-07-05 Thread Brenton via Digitalmars-d-learn



Is there a way to define a compile time constant/enum with dmd?  
For example, inserting the svn revision number into my code?  In 
C...


#include stdio.h
#ifndef SOMETHING
#define SOMETHING bar
#endif
int main() {
printf(hello world:  SOMETHING  \n);
return 0;
}



gcc main.c  ./a.out

hello world: bar

gcc -DSOMETHING=\foo\ main.c  ./a.out

hello world: foo


How would you recommend I do something like this with D?

Re: Compile time definitions

2014-07-05 Thread bearophile via Digitalmars-d-learn


Brenton:


How would you recommend I do something like this with D?


In D compile-time constants are introduced using the enum 
keyword.


You can also use the -version=... compiler switch to compile 
your D code according to some version, that can be a number or 
identifier.


In D there isn't the -D switch of gcc, so you can do something 
similar putting your string into a little textual file, and 
importing it inside the module using 
mixin(import(myfilename.txt)) statement plus the -Imypathname 
compiler switch.


Bye,
bearophile

Re: Using a delegate when interfacing with C

2014-07-05 Thread Adam D. Ruppe via Digitalmars-d-learn


On Saturday, 5 July 2014 at 22:18:56 UTC, Marco Cosentino wrote:

   auto client = *(cast(ClientImplementation*) data);


Try just

auto client = cast(ClientImplementation) data;


and

 this.setProcessCallback(callback, cast(void *) this);

setProcessCallback(callback, cast(void*) this);


Can somebody help me in figuring out why this happens?



The reason is a class this in D is already a pointer (just a 
hidden one) so when you do this in a class, it is like a 
ClientImplementation** in C - a pointer to a (temporary) pointer. 
So by the time the callback runs, it is pointing to nonsense.


In general, remember any class reference in D is already 
equivalent to a pointer in C or C++ and can be casted straight to 
void* without needing to take its address.

Re: Using a delegate when interfacing with C


On Saturday, 5 July 2014 at 22:28:48 UTC, Adam D. Ruppe wrote:

In general, remember any class reference in D is already 
equivalent to a pointer in C or C++ and can be casted straight 
to void* without needing to take its address.


Thanks Adam,
you're a life saver ;). It works like a charme.

Re: Compile time definitions

2014-07-05 Thread Brenton via Digitalmars-d-learn


On Saturday, 5 July 2014 at 22:08:52 UTC, bearophile wrote:

Brenton:


How would you recommend I do something like this with D?


In D compile-time constants are introduced using the enum 
keyword.


You can also use the -version=... compiler switch to compile 
your D code according to some version, that can be a number or 
identifier.


In D there isn't the -D switch of gcc, so you can do 
something similar putting your string into a little textual 
file, and importing it inside the module using 
mixin(import(myfilename.txt)) statement plus the -Imypathname 
compiler switch.


Bye,
bearophile


Thanks bearophile, using mixin(import(myfilename.txt)) works 
great.

Re: How to test templates for equality?

2014-07-05 Thread Uranuz via Digitalmars-d-learn

I have another question about testing if given symbol is instance 
of the given template and geting it's template arguments. I'm 
talking about raw template symbols, but not struct or class 
templates. For case with struct or class template 
std.traits.isInstanceOf is working well. But using *raw* template 
is not possible for it. There is an example.


import std.stdio, std.traits;


template WrapperTemplate(T)
{}

void main()
{
writeln( isInstanceOf!(WrapperTemplate, WrapperTemplate!(int)) );
}

Because isInstanceOf implemented as *is* expression it expects 
type arguments, but template is not type at all. So this is not 
working. As we have __traits(isSame, ...) we could make such a 
test, but I need to have tuple of template arguments. But I don't 
understand how to get them


template isMyInstanceOf(alias Templ, alias Inst)
{

}

Re: How to test templates for equality?

2014-07-05 Thread Uranuz via Digitalmars-d-learn


Suddenly posted. I don't know why it's happened))

template isMyInstanceOf(alias Templ, alias Inst)
{
alias Args = ???; //I don't have idea how to get it

enum bool isMyInstanceOf = __traits(isSame, Templ!(Args), 
Inst);

}

Do you have any idea how to solve this? May be standad library 
could be improved with such type of test for template instance?

[Issue 12140] SortedRange as associative array keys

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

Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Kenji Hara k.hara...@gmail.com ---


*** This issue has been marked as a duplicate of issue 11037 ***

--

[Issue 11037] [AA] AA's totally broken for struct keys with indirection

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

--- Comment #4 from Kenji Hara k.hara...@gmail.com ---
*** Issue 12140 has been marked as a duplicate of this issue. ***

--

[Issue 13015] std.json.JSONValue's toString is not const

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

--- Comment #1 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/d97dc15d827b79bc9b318b39a67ac1add3bc260c
Merge pull request #2292 from markisaa/constToString

Issue 13015 - std.json.JSONValue's toString is now const

--

[Issue 2834] Struct Destructors are not called by the GC, but called on explicit delete.

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

Dmitry Olshansky dmitry.o...@gmail.com changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com

--- Comment #20 from Dmitry Olshansky dmitry.o...@gmail.com ---
(In reply to Orvid King from comment #19)
 We still wouldn't be able to call the destructors in structs for arrays even 
 with precise heap scanning, because we can't know that each value in the
 array 
 is actually valid. Take for instance an array of File's, it's not valid to
 call 
 the destructor of File.init, so we could compare the value of an element of
 an 
 array of structs to it's init value, but who's to say that element was ever 
 initialized in the first place? How would we detect that?

It's perfectly valid to call destructor on T.init. In fact compiler will always
do so with stack-allocated instances.

--

[Issue 2834] Struct Destructors are not called by the GC, but called on explicit delete.

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

Rainer Schuetze r.sagita...@gmx.de changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #21 from Rainer Schuetze r.sagita...@gmx.de ---
(In reply to Orvid King from comment #19)
 We still wouldn't be able to call the destructors in structs for arrays even 
 with precise heap scanning
[...]
 How would we detect that?

The array handling in lifetime.d should supply a type info with a destructor
that iterates over the elements and calls their destructor. You might have to
generate that typeinfo at runtime, though.

--

[Issue 13035] Cherry-picks for v2.066.0-b2

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

--- Comment #3 from Andrew Edwards edwards...@gmail.com ---
(In reply to Andrew Edwards from comment #0)
 Identify all commits required to be cherry-picked for v2.066.0-b2. If there
 are no cherry picks identified on this ticket by 0700 UTC ( PDT), the
 issue will be close and v2.066.0-rc1 will be created and published.

Meant to say by 0700 UTC ( PDT) on 7 July.

--

[Issue 13036] Cherry-picks for v2.065.1-b1

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

--- Comment #1 from Andrew Edwards edwards...@gmail.com ---
(In reply to Andrew Edwards from comment #0)
 Identify all commits required to be cherry-picked for v2.065.1-b1. If there
 are no cherry picks identified on this ticket by 0700 UTC ( PDT), the
 issue will be close and no future attempt will be made at a point release
 for the v2.065.

Meant to say by 0700 UTC ( PDT) on 7 July.

--

[Issue 879] support for --gc-sections

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

--- Comment #18 from Martin Nowak c...@dawg.eu ---
(In reply to David Nadlinger from comment #17)
 I was under the impression that --gc-sections indeed does this when linking
 an executable. Default visibility on its own is not enough to keep a symbol
 (and thus its section) alive, unless it is required to resolve an undefined
 symbol from a linked shared object. Maybe we have a different understanding
 of what an exported symbol is, though.

Right, gc-sections doesn't care about visibility, but the ModuleInfos are not
emitted to individual sections (.rodata or .text) so they won't get removed
unless they are the only symbols in .rodata/.text.

 (In reply to Martin Nowak from comment #16)
  Another problem that I have is that ld.gold with --gc-sections doesn't copy 
  the .minfo_beg/.minfo_end sections from an archive object, so it breaks the 
  section brackets even when all .minfo* sections are pinned.
 
 What precisely do you refer to as archive object? An object file pulled in
 from a static library?

Yes, object files from an archive. It's probably the same for normal objects.
With --gc-sections the ld.gold linker seems to only copy sections that contain
referenced symbols. I can also reference .minfo_beg/.minfo/.minfo_end in each
ctor, but for some reason the order for the output sections isn't preserved.

 On Linux x86_64, our static release-mode binaries
 are on average 1/4 the size of DMD's for small programs now

Interesting, dmd uses a section per function by default, but for unknown
reasons --gc-sections doesn't have a huge effect.
https://github.com/D-Programming-Language/dmd/pull/3597#issuecomment-44671223

I'd like to give the linker as good information as possible. For example when a
functions isn't used the linker should strip the associated EH data. Likewise
ModuleInfo is needed only when any data or function of a module end up in a
DSO.

--

[Issue 879] support for --gc-sections

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

--- Comment #19 from Martin Nowak c...@dawg.eu ---
(In reply to Martin Nowak from comment #18)
 I can also reference .minfo_beg/.minfo/.minfo_end in each ctor.

Actually this doesn't work with ld.gold because dmd only uses a single ctor per
DSO (COMDAT) and ld.gold will merge the ctors before checking their references.
So I only end up with the .minfo* sections of the first object file.

--

[Issue 13049] New: in template arguments the compiler fails to parse scope for function pointers arguments

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

  Issue ID: 13049
   Summary: in template arguments the compiler fails to parse
scope for function pointers arguments
   Product: D
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: DMD
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

It's not possible to declare a function pointer type with scope arguments
within a template argument list.

enum mangle(T) = T.mangleof;
alias Func = void function(scope int);  // OK
pragma(msg, mangle!Func);   // OK
pragma(msg, mangle!(void function(int)));   // OK
pragma(msg, mangle!(void function(scope int))); // NG

--

[Issue 13050] New: pragma mangle breaks homonym template aliasing

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

  Issue ID: 13050
   Summary: pragma mangle breaks homonym template aliasing
   Product: D
   Version: unspecified
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: DMD
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

void foo();
template decl(Arg)
{
void decl(Arg);
}
template bug(Arg)
{
pragma(mangle, foobar)
void bug(Arg);
}
template workaround(Arg)
{
pragma(mangle, foobar)
void func(Arg);
alias workaround = func;
}

pragma(msg, typeof(foo));
pragma(msg, typeof(decl!int));
pragma(msg, typeof(bug!int));
pragma(msg, typeof(workaround!int));


void()
void(int)
void   // NG - homonym aliasing doesn't work for mangled function
void(int)


--

[Issue 12455] [uni][reg] Bad lowercase mapping for 'LATIN CAPITAL LETTER I WITH DOT ABOVE'

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

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

https://github.com/D-Programming-Language/phobos/commit/c131da58341b5af00feedd3dc535f2915cbdae0e
Fix issue 12455 [reg]Bad lowercase mapping for 'LATIN CAPITAL LETTER I WITH DOT
ABOVE'

Also as part of a fix restores a test case in string.d
to exactly match older behaviour.

Some extended greek is not upper but title case, yet changes on toUpper.

https://github.com/D-Programming-Language/phobos/commit/ced559888f8d244c13bcd93ef5c8412ce92ece82
Merge pull request #2304 from DmitryOlshansky/issue-12455

[REG]Fix issue 12455 Bad lowercase mapping for 'LATIN CAPITAL LETTER I W...

--

[Issue 12455] [uni][reg] Bad lowercase mapping for 'LATIN CAPITAL LETTER I WITH DOT ABOVE'

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

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

   What|Removed |Added

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

--

[Issue 13051] New: Cannot use function literal inside struct initializer

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

  Issue ID: 13051
   Summary: Cannot use function literal inside struct initializer
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: DMD
  Assignee: nob...@puremagic.com
  Reporter: johnnymar...@gmail.com

It appears that function literals cannot be used within struct initializers. It
seems to result in a syntax error if then function literal contains any code. 
I've provided the following code to demonstrate the issue.

void main()
{
  struct UseConstructor
  {
void function() fp;
this(void function() fp) {
  this.fp = fp;
}
  }

  // Compiles fine
  UseConstructor s1 = UseConstructor((){int a = 1;a += 24;});

  struct UseInitializer
  {
void function() fp;
  }

  // Compiles fine
  void function() fp1 = (){int a = 1;a = a * 7;};
  UseInitializer s2 = {fp:fp1};

  // Compiles fine
  UseInitializer fs3 = {fp:(){}};

  // Fails
  UseInitializer fs4 = {fp:(){int a = 1;}};
  // It seems that the code inside the function literal is causing a syntax
error
}

The error messages from compilation appear as:
Error: found '}' when expecting ';' following statement
Error: semicolon expected, not 'EOF'
Error: found 'EOF' when expecting '}' following compound statement

--

[Issue 13045] TypeInfo.getHash should return consistent result with object equality by default

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/a5c8c3afc84cad8ef62c119c4101acb8e6de3140
fix Issue 13045 - TypeInfo.getHash should return consistent result with object
equality by default

If struct member field has toHash method, or has non-bitwise equality, generate
__xtoHash implicitly to guarantee `a != b || typeid(S).getHash(a) ==
typeid(S).getHash(b)`.

--

[Issue 13043] Redundant linking to TypeInfo in non-root module