Re: Synchronized classes have no public members

[flamencofantasy via Digitalmars-d]

On Tuesday, 13 October 2015 at 19:05:31 UTC, Dicebot wrote:

On Tuesday, 13 October 2015 at 18:28:23 UTC, Marco Leise wrote:

Guys, sorry to break into your wishful thinking, but

   synchronized(mutex) {}

already works as you want it to since as long as I can think. 
Yes, it takes a parameter, yes it calls lock/unlock on the 
mutex. :)


Yes, and I am saying that it doesn't justify presence of 
`synchronized` keyword in the language at all, being historical 
legacy misfeature.


+1

Please remove synchronized all together. It's an abomination 
which should have never been in D in the first place.

It encourages sloppiness and lobotomizes programmers!
The greatest good you can do to all the D code out there that 
makes use of synchronized is to kill synchronized.
Then they'll have to think and hopefully learn how to properly 
synchronize sections of code instead of locking everything 
everywhere all the time.

[Issue 15141] Object.factory allows the creation of derived abstract classes

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

  Component|druntime|dmd
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #2 from Kenji Hara  ---
(In reply to Andrej Mitrovic from comment #1)
> Seems fixed in v2.068.2. Can you confirm?

Still happens with git-head.

https://github.com/D-Programming-Language/dmd/pull/5193

--

Re: Class, constructor and inherance.

[Rikki Cattermole via Digitalmars-d-learn]

On 13/10/15 5:17 PM, holo wrote:

On Tuesday, 13 October 2015 at 02:03:46 UTC, Rikki Cattermole wrote:

On 13/10/15 5:56 AM, holo wrote:

@Rikki:


If you didn't need to make it easily changeable I would say not even
bother with OOP at all.


Basically that what i had was enough for me and on top of that i could
build my app. It need to just periodically check for new instances and
if they are started or stopped and count "up and running time" for
billing purpose. But like i said i want to learn programming in D and
basically OOP too so i want to make it "proper way".

BTW: i think right now i understand what tuple is, but still don't know
for what to duplicate struct functionalities :). Those Templates still
don't understand but i hope that will came naturally with time and
practice. eg.. they are very similar to normal functions but you can
call it with types not only attributes.. strange ;)

I red yours advises and try to create according to it my own first
class.

I moved time functions and variables to method "go" they need to be
current as possible when im sending request, if wont authorization could
not pass.. so i think they shouldn't be in constructor.

I moved some other variables too, and created interface.

 From all that things came out such monster which is working and doing
its job :)

module sigawsv4;

import std.stdio, std.process;
import std.digest.sha, std.digest.hmac;
import std.string;
import std.conv;
import std.datetime;
import std.net.curl;

interface credential
{
 int go();
}

class sigv4 : credential
{
 //could be changed to take some structure as parameter instead of
such ammount of attributes

 this(string methodStr = "GET", string serviceStr = "ec2", string
hostStr = "ec2.amazonaws.com", string regionStr = "us-east-1", string
endpointStr = "https://ec2.amazonaws.com;, string payloadStr = "",
string parmStr = "Action=DescribeInstances=2013-10-15")
 {

 this.method = methodStr;
 this.service = serviceStr;
 this.host = hostStr;
 this.region = regionStr;
 this.endpoint = endpointStr;
 this.payload = payloadStr;
 this.request_parameters = parmStr;

 this.accessKey = environment.get("AWS_ACCESS_KEY");
 this.secretKey = environment.get("AWS_SECRET_KEY");
 }

 public:
 string method;
 string service;
 string host;
 string region;
 string endpoint;
 string payload;
 string request_parameters;


 int go()
 {
 //time need to be set when we are sending request not
before
 auto currentClock = Clock.currTime(UTC());
 auto currentDate = cast(Date)currentClock;
 auto curDateStr = currentDate.toISOString;
 auto currentTime = cast(TimeOfDay)currentClock;
 auto curTimeStr = currentTime.toISOString;
 auto xamztime = curDateStr ~ "T" ~ curTimeStr ~ "Z";

 canonicalURI = "/";
 canonicalQueryString = request_parameters;
 canonicalHeadersString =  "host:" ~ this.host ~ "\n" ~
"x-amz-date:" ~ xamztime ~ "\n";
 signedHeaders = "host;x-amz-date";

 auto canonicalRequest = getCanonicalRequest(canonicalURI,
canonicalQueryString, canonicalHeadersString, signedHeaders);

 string credentialScope = curDateStr ~ "/" ~ region ~ "/" ~
service ~ "/" ~ "aws4_request";

 string stringToSign = algorithm ~ "\n" ~ xamztime ~ "\n" ~
credentialScope ~ "\n" ~ sha256Of(canonicalRequest).toHexString.toLower;

 auto signingKey = getSignatureKey(secretKey, curDateStr,
region, service);

 string signature = hmac!SHA256(stringToSign.representation,
signingKey).toHexString.toLower;

 string authorizationHeader = algorithm ~ " " ~
"Credential=" ~ accessKey ~ "/" ~ credentialScope ~ ", " ~
"SignedHeaders=" ~ signedHeaders ~ ", " ~ "Signature=" ~ signature;


 auto client = HTTP(endpoint ~ "?" ~ canonicalQueryString);
 client.method = HTTP.Method.get;
 client.addRequestHeader("x-amz-date", xamztime);
 client.addRequestHeader("Authorization",
authorizationHeader);
 auto content = client.perform();

 return content;
 }

 private:
 const algorithm = "AWS4-HMAC-SHA256";

 string accessKey;
 string secretKey;

 string currentClock;
 string currentDate;
 string curDateStr;
 string currentTime;
 string curTimeStr;
 string xamztime;

 string canonicalURI;
 string canonicalQueryString;
string canonicalHeadersString;
string signedHeaders;



 alias sign = hmac!SHA256;

 auto getSignatureKey(string key, string dateStamp, string
regionName, string serviceName)
 {
 auto kString = ("AWS4" ~ key).representation;
 auto kDate = 

Re: OT: why do people use python when it is slow?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Tuesday, 13 October 2015 at 23:26:14 UTC, Laeeth Isharc wrote:

https://www.quora.com/Why-is-Python-so-popular-despite-being-so-slow
Andrei suggested posting more widely.


That's flaimbait:

«Many really popular websites use Python. But why is that? 
Doesn't it affect the performance of the website?»


No. Really popular websites use pre-generated content / front end 
caches / CDNs or wait for network traffic from distributed 
databases.

Re: Synchronized classes have no public members

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 13 October 2015 at 06:58:28 UTC, Andrei Alexandrescu 
wrote:
https://github.com/D-Programming-Language/dmd/pull/5188 
implements a rule defined in TDPL: synchronized classes shall 
have no public members.


The motivation behind this limitation is that member accesses 
in synchronized objects should not occur without some handshake 
occurring. Public members would make that possible and easy.


Walter and I are on board with this change. However, it is a 
breaking change so we want to gather a level of community 
support before we push the button.


Well, as I understand it, technically, synchronized classes don't 
even exist in D at the moment - just synchronized functions (much 
as TDPL talks about D having synchronized classes and not 
synchronized functions). So, if that change only affects classes 
marked with synchronized and doesn't do anything to functions 
marked as synchronized, then the breakage is likely to be pretty 
small (pretty much just cases where someone didn't want to bother 
putting synchronized on every method individually). On the other 
hand, if it basically adds synchronized classes and disallows 
synchronized functions and actually moves us to what TDPL 
describes (or close to it), then it's basically going to break 
all uses of synchronized in classes aside from simply using 
synchronized blocks inside of a member function. If it's the 
latter, we definitely need an appropriate transition period.


Ultimately, I think that we're better off with TDPL's definition 
of synchronized classes than the synchronized functions that we 
have now, so I do think that the change should be made. However, 
I also think that synchronized classes as TDPL describes are 
limited enough to be of questionable usefulness. Stripping off 
the outer layer of shared is unlikely to be sufficient in all but 
basic cases (and synchronized classes can't do any better than 
that, I don't think), meaning that you're likely going to have to 
cast away shared to do much with shared anyway, in which case, 
having a synchronized class loses at least some of its value. It 
can still encapsulate shared (which is good), but it doesn't 
necessarily make it much easier or safer to use.


- Jonathan M Davis

Ready for testing: vibe.d 0.7.26-alpha.3

[Sönke Ludwig via Digitalmars-d]

Despite it's name, this release should be considered a beta release. PR 
#1268[1] will potentially still make it in, but otherwise only bug 
fixing will happen at this point. As with the previous versions, the 
final release will happen at the same time as DMD 2.069.0. Please use 
the chance to test for any remaining issues (simply run `dub upgrade 
--prerelease` on your project(s)).


Changes in this release:
https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md

[1]: https://github.com/rejectedsoftware/vibe.d/pull/1268

Re: Synchronized classes have no public members

[Nemanja Boric via Digitalmars-d]

On Tuesday, 13 October 2015 at 06:58:28 UTC, Andrei Alexandrescu 
wrote:
https://github.com/D-Programming-Language/dmd/pull/5188 
implements a rule defined in TDPL: synchronized classes shall 
have no public members.


The motivation behind this limitation is that member accesses 
in synchronized objects should not occur without some handshake 
occurring. Public members would make that possible and easy.


Walter and I are on board with this change. However, it is a 
breaking change so we want to gather a level of community 
support before we push the button.



Thanks,

Andrei


While we're talking about this, what about this:

http://www.digitalmars.com/d/archives/digitalmars/D/Module_access_to_private_members_of_synchronized_classes_228775.html


In the TDPL, on page 419:
"Not so for synchronized classes, which obey the following 
rules:
- Access to private members is restricted to methods of the 
class."


I could rework commits from my experimental branch and submit a 
PR?

Re: Synchronized classes have no public members

[Benjamin Thaut via Digitalmars-d]

On Tuesday, 13 October 2015 at 07:17:20 UTC, Jonathan M Davis 
wrote:


Ultimately, I think that we're better off with TDPL's 
definition of synchronized classes than the synchronized 
functions that we have now, so I do think that the change 
should be made. However, I also think that synchronized classes 
as TDPL describes are limited enough to be of questionable 
usefulness. Stripping off the outer layer of shared is unlikely 
to be sufficient in all but basic cases (and synchronized 
classes can't do any better than that, I don't think), meaning 
that you're likely going to have to cast away shared to do much 
with shared anyway, in which case, having a synchronized class 
loses at least some of its value. It can still encapsulate 
shared (which is good), but it doesn't necessarily make it much 
easier or safer to use.


- Jonathan M Davis


I have to agree here. I think synchronized classes are of very 
little use, especially because they don't "cast away" shared in a 
useful way. It still has to be done manually. I think we should 
remove them. Synchronized methods should also be removed in my 
eyes. Making each and every object bigger by one pointer just for 
the sake of a few synchronized methods doesn't seem to be a good 
trade off to me. The entire synchronized methods give the user 
the feeling that he simply slaps synchronized on his class / 
method and then its thread safe and he doesn't have to care about 
threads anymore. In the real world this is far from true however. 
So synchronized methods and classes just give a false sense of 
thread safety and should rather be removed.

Synchronized classes have no public members

[Andrei Alexandrescu via Digitalmars-d]

https://github.com/D-Programming-Language/dmd/pull/5188 implements a 
rule defined in TDPL: synchronized classes shall have no public members.


The motivation behind this limitation is that member accesses in 
synchronized objects should not occur without some handshake occurring. 
Public members would make that possible and easy.


Walter and I are on board with this change. However, it is a breaking 
change so we want to gather a level of community support before we push 
the button.



Thanks,

Andrei

Re: how to do iota(0,256) with ubytes ? (cf need for iotaInclusive)

[John Colvin via Digitalmars-d]

On Monday, 12 October 2015 at 13:17:32 UTC, Timon Gehr wrote:

On 10/09/2015 04:41 AM, Timothee Cour via Digitalmars-d wrote:


Could we have a function with iota_inclusive that has 
inclusive bounds

for 'end' parameter ?



iota!"[]" ?


Yes please.

DoxyPress support for D

[Ali Çehreli via Digitalmars-d]

Barbara Geller and Ansel Sermersheim's CppCon 2015 talk has a very brief 
mention of D:



https://www.youtube.com/watch?feature=player_detailpage=hQphBQMwk7s#t=2440

They ported Doxygen to C++11 with great effort and named the result 
DoxyPress.


- Since D already has ddoc, do we need DoxyPress support as well?

- If so, who would like to help Barbara and Ansel? :)

Ali

Re: Synchronized classes have no public members

[Chris via Digitalmars-d]

On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut wrote:


I have to agree here. I think synchronized classes are of very 
little use, especially because they don't "cast away" shared in 
a useful way. It still has to be done manually. I think we 
should remove them. Synchronized methods should also be removed 
in my eyes. Making each and every object bigger by one pointer 
just for the sake of a few synchronized methods doesn't seem to 
be a good trade off to me. The entire synchronized methods give 
the user the feeling that he simply slaps synchronized on his 
class / method and then its thread safe and he doesn't have to 
care about threads anymore. In the real world this is far from 
true however. So synchronized methods and classes just give a 
false sense of thread safety and should rather be removed.


Actually, I once fell foul of this wrong impression of thread 
safety via 'synchronized'. I found a different solution and 
dropped synchronized.

[Issue 481] Letting compiler determine length for fixed-length arrays

[via Digitalmars-d-bugs]

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

--- Comment #39 from Ketmar Dark  ---
tbh, i don't really care, as i've integrated this patch into my private dmd
build long time ago and i'm happy with it. so i have no opinion here (yes, i
know that "my D" is incompatible with "official D", so what? :-).

--

[Issue 481] Letting compiler determine length for fixed-length arrays

[via Digitalmars-d-bugs]

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

--- Comment #38 from Shriramana Sharma  ---
Hmmm. I read through the thread starting at
http://forum.dlang.org/post/mag5hp$105a$1...@digitalmars.com. I think I sorta 
see
the point of the developers here.

While I still think [$] is a cool little tidbit, I also have to agree with the
comment which said "let's not add every little tidbit to the language". The
title of the request is "letting compiler determine length for fixed-length
arrays", not specifically to add [$]. Having the compiler determine the length
can be done in many ways, and given that I already have to go to the library
for a lot of commonly used stuff like writeln and to!, this one doesn't seem
too much more. Although it *does* seem like something you should have out of
the box, so do stuff like print()... :-)

The one thing the library solution probably cannot address would be the
convoluted examples like a fixed-size array of a dynamic array of fixed-size
arrays, but let's face it: those are really contrived examples and not worth
introducing a language feature for...

I'm leaving my votes in since I do want *something* to be done to address the
actual request, since any such library solution is ATM still sitting over at
http://dpaste.dzfl.pl/f49a97e35974 and not actually included in Phobos.

BTW I don't think it should be named just 's' in the std.array module, but
something more meaningful, like fixedLengthArray (yikes, yes I know, but I'm
open to suggestions) and one can always do something like:

import std.array: f = fixedLengthArray;

--

Re: Synchronized classes have no public members

[Marco Leise via Digitalmars-d]

Am Tue, 13 Oct 2015 09:36:22 +
schrieb ponce :

> On Tuesday, 13 October 2015 at 09:07:54 UTC, Chris wrote:
> > On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut 
> > wrote:
> >>
> >> […] The entire synchronized methods give the user the feeling
> >> that he simply slaps synchronized on his class / method and
> >> then its thread safe and he doesn't have to care about threads
> >> anymore. In the real world this is far from true however. So
> >> synchronized methods and classes just give a false sense of
> >> thread safety and should rather be removed.
> >
> > Actually, I once fell foul of this wrong impression of thread 
> > safety via 'synchronized'. I found a different solution and 
> > dropped synchronized.
> 
> I also dropped synchronized and use @nogc mutexes instead. I also 
> think synchronized methods should be removed. It's also difficult 
> to explain: what is a "monitor"? when you write a synchronized { 
> } block, which monitor is taken?

Yep, I prefer to think it sets of variables that need mutex
protection. And these are not generally the set of member
fields in a class. When other mutexes need the same variables
they must be a strict superset or subset of the other with the
mutex with smaller scope always being locked first.

That's all folks. 100% safety. :)
(The catch is you need to get a fix on the variables.)

-- 
Marco

[Issue 14070] Letting compiler determine length for fixed-length arrays in foreach

[via Digitalmars-d-bugs]

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

Shriramana Sharma  changed:

   What|Removed |Added

 CC||samj...@gmail.com

--

[Issue 481] Letting compiler determine length for fixed-length arrays

[via Digitalmars-d-bugs]

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

rswhi...@gmail.com changed:

   What|Removed |Added

 CC||rswhi...@gmail.com

--- Comment #40 from rswhi...@gmail.com ---
(In reply to Shriramana Sharma from comment #38)
> Hmmm. I read through the thread starting at
> http://forum.dlang.org/post/mag5hp$105a$1...@digitalmars.com. I think I sorta
> see the point of the developers here.
> 
> While I still think [$] is a cool little tidbit, I also have to agree with
> the comment which said "let's not add every little tidbit to the language".
> The title of the request is "letting compiler determine length for
> fixed-length arrays", not specifically to add [$]. Having the compiler
> determine the length can be done in many ways, and given that I already have
> to go to the library for a lot of commonly used stuff like writeln and to!,
> this one doesn't seem too much more. Although it *does* seem like something
> you should have out of the box, so do stuff like print()... :-)
> 
> The one thing the library solution probably cannot address would be the
> convoluted examples like a fixed-size array of a dynamic array of fixed-size
> arrays, but let's face it: those are really contrived examples and not worth
> introducing a language feature for...
> 
> I'm leaving my votes in since I do want *something* to be done to address
> the actual request, since any such library solution is ATM still sitting
> over at http://dpaste.dzfl.pl/f49a97e35974 and not actually included in
> Phobos.
> 
> BTW I don't think it should be named just 's' in the std.array module, but
> something more meaningful, like fixedLengthArray (yikes, yes I know, but I'm
> open to suggestions) and one can always do something like:
> 
> import std.array: f = fixedLengthArray;

There is a better way:

import std.stdio;

pragma(inline, true);
auto s(T, size_t n)(auto ref T[n] arr) {
return arr;
}

void main() {
auto arr = [1, 2, 3].s;
writeln(typeof(arr).stringof);
}
---

--

[Issue 15200] New: [REG2.068.2] ICE(glue.c) when compiling with -inline

[via Digitalmars-d-bugs]

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

  Issue ID: 15200
   Summary: [REG2.068.2] ICE(glue.c) when compiling with -inline
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Keywords: ice
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: j...@red.email.ne.jp

This code works with 2.068.1.
But ICE with 2.068.2.

dmd -c -inline test.d

test.d:
import func;

void test()
{
f();
}

func.d:
import std.algorithm;

auto f() // not void
{
sub([0], false);
}
void sub(R)(R list, bool b)
{
foreach (i; list.filter!(delegate(e)=>b) ) { }
}

OUTPUT:
Assertion failure: '!v->csym' on line 1069 in file 'glue.c'

NOTE:
My actual project does not compile separately(-c), but the problem comes.

--

Re: Synchronized classes have no public members

[ponce via Digitalmars-d]

On Tuesday, 13 October 2015 at 09:07:54 UTC, Chris wrote:
On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut 
wrote:


I have to agree here. I think synchronized classes are of very 
little use, especially because they don't "cast away" shared 
in a useful way. It still has to be done manually. I think we 
should remove them. Synchronized methods should also be 
removed in my eyes. Making each and every object bigger by one 
pointer just for the sake of a few synchronized methods 
doesn't seem to be a good trade off to me. The entire 
synchronized methods give the user the feeling that he simply 
slaps synchronized on his class / method and then its thread 
safe and he doesn't have to care about threads anymore. In the 
real world this is far from true however. So synchronized 
methods and classes just give a false sense of thread safety 
and should rather be removed.


Actually, I once fell foul of this wrong impression of thread 
safety via 'synchronized'. I found a different solution and 
dropped synchronized.


I also dropped synchronized and use @nogc mutexes instead. I also 
think synchronized methods should be removed. It's also difficult 
to explain: what is a "monitor"? when you write a synchronized { 
} block, which monitor is taken?

Re: Regarding std.array.Appender

[Suliman via Digitalmars-d-learn]

On Monday, 5 March 2012 at 15:35:59 UTC, Steven Schveighoffer 
wrote:
On Wed, 29 Feb 2012 20:25:35 -0500, bearophile 
 wrote:


Do you know why std.array.Appender defines a "put" method 
instead of overloading the "~=" operator?


It should (in addition to put).  I see you have already filed 
an enhancement.


http://d.puremagic.com/issues/show_bug.cgi?id=4287

-Steve


Can I use Appender to add at end of every string my symbol?

foreach (pointsfile; pointsFiles)
{
File file = File(pointsfile, "r");
		string content = file.byLine; // I need to add "+" at at end of 
every string

}

Re: Regarding std.array.Appender

[John Colvin via Digitalmars-d-learn]

On Tuesday, 13 October 2015 at 13:21:54 UTC, Suliman wrote:
I tried to use map! but it's look like it do not work with 
string, becouse I got error: Error: no property 'map' for type 
'ByLine!(char, char)'


I suspect you don't have it imported.

import std.algorithm;

or

import std.algorithm : map;

Re: Regarding std.array.Appender

[Suliman via Digitalmars-d-learn]

On Tuesday, 13 October 2015 at 13:34:02 UTC, John Colvin wrote:

On Tuesday, 13 October 2015 at 13:21:54 UTC, Suliman wrote:
I tried to use map! but it's look like it do not work with 
string, becouse I got error: Error: no property 'map' for type 
'ByLine!(char, char)'


I suspect you don't have it imported.

import std.algorithm;

or

import std.algorithm : map;


Thanks, you are right! Can I add with map some element before and 
after string? map!(a=> a~=" +") work fine, but how to add before 
at same time?

Re: Beta D 2.069.0-b1

[Meta via Digitalmars-d-announce]

On Tuesday, 13 October 2015 at 13:18:36 UTC, Kagamin wrote:
Well, in order to pass the result of a function call to a 
template parameter means that the function must be evaluated at 
compile time, which is not always possible, so it probably 
doesn't make sense to call a function when passed as a template 
argument.


You'd be surprised what DMD thinks is a function call and what 
isn't.

Re: Regarding std.array.Appender

[anonymous via Digitalmars-d-learn]

On Tuesday 13 October 2015 15:47, Suliman wrote:

> something like: auto content = file.byLine.map!("start " ~ a=>a ~ 
> " end");

That's not how it works at all. Maybe stick to the examples of whatever 
resource you're learning from, for now.

[Issue 15185] [REG2.069.0-b1] Not possible to create instance of TypeInfo

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #5 from Steven Schveighoffer  ---
Why not "typeid(const(Object))" and "(const(Object)).classinfo" ?

--

Re: Beta D 2.069.0-b1

[Kagamin via Digitalmars-d-announce]

On Sunday, 11 October 2015 at 09:54:04 UTC, Jacob Carlborg wrote:
That would be me :) [1]. I think the biggest issue was that 
something that worked before stopped working, because a field 
was changed to a method and the method returned a function 
pointer.


[1] 
http://forum.dlang.org/thread/kaara7$dog$1...@digitalmars.com#post-kaara7:24dog:241:40digitalmars.com


That refactoring is exactly the (only) use case for strict 
properties, they shouldn't be used in other cases.

Re: Regarding std.array.Appender

[Suliman via Digitalmars-d-learn]

I tried to use map! but it's look like it do not work with 
string, becouse I got error: Error: no property 'map' for type 
'ByLine!(char, char)'

Re: Regarding std.array.Appender

[anonymous via Digitalmars-d-learn]

On Tuesday 13 October 2015 15:42, Suliman wrote:

> map!(a=> a~=" +") work fine, but how to add before 
> at same time?

Use ~ instead of ~=, like so: map!(a => "+" ~ a ~ "+")

Berlin D Meetup October 2015

[Ben Palmer via Digitalmars-d-announce]

Hi All,

The next Berlin D Meetup will be happening at 19:30 on Friday 
October the 16th at Berlin Co-Op (http://co-up.de/) on the fifth 
floor.


This time we have one lightning talk lined up followed by an open 
hackathon. If anyone has another lightning talk they would like 
to present or even just a topic for discussion feel free to bring 
it along.


Details are also on the meetup page here: 
http://www.meetup.com/Berlin-D-Programmers/


Thanks,
Ben.

Re: Regarding std.array.Appender

[Suliman via Digitalmars-d-learn]

something like: auto content = file.byLine.map!("start " ~ a=>a ~ 
" end");

[OT] LLVM Community Code of Conduct

[Daniel Kozak via Digitalmars-d]

lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

Maybe we could have something similar in D community

[Issue 12421] Allow simpler syntax for lambda template declarations

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Regarding std.array.Appender

[Suliman via Digitalmars-d-learn]

On Tuesday, 13 October 2015 at 13:55:07 UTC, anonymous wrote:

On Tuesday 13 October 2015 15:47, Suliman wrote:

something like: auto content = file.byLine.map!("start " ~ 
a=>a ~ " end");


That's not how it works at all. Maybe stick to the examples of 
whatever resource you're learning from, for now.


Yes, I understand that it's not work exactly like I try to use 
it, but which function can solve my problem?

Re: DIP74 - where is at?

[Jacob via Digitalmars-d]

On Monday, 12 October 2015 at 19:35:33 UTC, Ice Cream Overload 
wrote:

On Monday, 12 October 2015 at 16:56:27 UTC, Jacob wrote:
I've noticed that you seem to be quite arrogant. Usually it is 
a result of ignorance. Your statement basically proves that.


Maybe you should take a break from programming for a while and 
work on your attitude?


While you have no proof of this, If you do a little soul 
searching you'll find that the world doesn't revolve around 
you. Put down your toys and get out of the sandbox and you 
might learn something!


Dude you are kind of being a jerk. He's just arguing against, 
rather passionately, a design decision he thinks is poor. It 
values no one if individuals remain quiet and conform. 
Certainly not the leadership. What you see as arrogance is 
really just passion.


Passion or not,

"If you are wondering why I'm inflammatory, here you go. You are 
pulling me the old prove a negative trick. You have good evidence 
that DIP25 is good design ? Good, because I have none. And that's 
my proof. As long as I have no evidence that DIP25 is good, DIP25 
is bad."


That statement shows a lot of arrogance.

It he not really just saying "I have no clue if X is true, but 
since I don't know, I'll just assume it's false and assume you 
are wrong.".


That's not very logical. Why wouldn't he just as well assume X is 
true?


The fact is, he can't and shouldn't make such statements about X 
if he has no "evidence" about it.


Instead, wouldn't the proper approach be to discuss, learn, and 
share what one things in a positive way so everyone can learn 
about X and reach a more intelligent understanding of it?


Hilter was very passionate too, are you saying he was right?

Re: Synchronized classes have no public members

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 13 October 2015 at 09:36:23 UTC, ponce wrote:

It's also difficult to explain: what is a "monitor"?


Not difficult? A monitor is facade/object which only allows one 
method to execute concurrently.


It can work out ok if synchronization/lockfree mechanisms are 
built into the language so that the compiler can optimize away 
overhead.

Re: Synchronized classes have no public members

[Dicebot via Digitalmars-d]

On Tuesday, 13 October 2015 at 06:58:28 UTC, Andrei Alexandrescu 
wrote:
https://github.com/D-Programming-Language/dmd/pull/5188 
implements a rule defined in TDPL: synchronized classes shall 
have no public members.


The motivation behind this limitation is that member accesses 
in synchronized objects should not occur without some handshake 
occurring. Public members would make that possible and easy.


Walter and I are on board with this change. However, it is a 
breaking change so we want to gather a level of community 
support before we push the button.



Thanks,

Andrei


I still have no idea why I would ever use `synchronized` (any 
automatic thread synchronization is harmful in my opinion) so 
change itself is irrelevant. But it may break quite some old 
Java-liked 3d party code for no benefit and that would be 
annoying.

Re: DIP74 - where is at?

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 13 October 2015 at 12:40:46 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 12 October 2015 at 19:35:34 UTC, Marco Leise wrote:

Wouldn't it be great if everyone took notes of the currently
perceived shortcomings of shared so that there is a pile of
use- and corner-cases to look at for a redesign?


The problem with shared is that shared should not be constant 
over time, it should be related to behavioural typing/type 
state.


Synchronization is a temporal factor not a static typing factor.


That said, if you have:

1. writer-ownership as a feature
2. mark variables as "only writable by one owner"

Then the compiler can drop some read locks for the _owning_ 
thread.


But D does not have ownership as a feature beyond "thread local 
memory"?

Re: Synchronized classes have no public members

[ponce via Digitalmars-d]

On Tuesday, 13 October 2015 at 10:57:55 UTC, Marco Leise wrote:


Yep, I prefer to think it sets of variables that need mutex 
protection. And these are not generally the set of member 
fields in a class.


Exactly. And that makes things using synchronized prone to longer 
and more frequent locks.

Re: Synchronized classes have no public members

[Minas Mina via Digitalmars-d]

On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut wrote:
On Tuesday, 13 October 2015 at 07:17:20 UTC, Jonathan M Davis 
wrote:


Ultimately, I think that we're better off with TDPL's 
definition of synchronized classes than the synchronized 
functions that we have now, so I do think that the change 
should be made. However, I also think that synchronized 
classes as TDPL describes are limited enough to be of 
questionable usefulness. Stripping off the outer layer of 
shared is unlikely to be sufficient in all but basic cases 
(and synchronized classes can't do any better than that, I 
don't think), meaning that you're likely going to have to cast 
away shared to do much with shared anyway, in which case, 
having a synchronized class loses at least some of its value. 
It can still encapsulate shared (which is good), but it 
doesn't necessarily make it much easier or safer to use.


- Jonathan M Davis


I have to agree here. I think synchronized classes are of very 
little use, especially because they don't "cast away" shared in 
a useful way. It still has to be done manually. I think we 
should remove them. Synchronized methods should also be removed 
in my eyes. Making each and every object bigger by one pointer 
just for the sake of a few synchronized methods doesn't seem to 
be a good trade off to me. The entire synchronized methods give 
the user the feeling that he simply slaps synchronized on his 
class / method and then its thread safe and he doesn't have to 
care about threads anymore. In the real world this is far from 
true however. So synchronized methods and classes just give a 
false sense of thread safety and should rather be removed.


I agree that synchronized classes / functions that not that 
useful.


But synchronized statements, to me, make the intention of locking 
explicit.


Maybe the internal monitor could be removed (with synchronized 
classes / functions as well), and allow synchronized() {} to be 
called on Lock objects, that essentially locks them at the 
beginning and unlocks them at the end.

Re: DIP74 - where is at?

[John Colvin via Digitalmars-d]

On Tuesday, 13 October 2015 at 12:16:26 UTC, Jacob wrote:
On Monday, 12 October 2015 at 19:35:33 UTC, Ice Cream Overload 
wrote:

On Monday, 12 October 2015 at 16:56:27 UTC, Jacob wrote:
I've noticed that you seem to be quite arrogant. Usually it 
is a result of ignorance. Your statement basically proves 
that.


Maybe you should take a break from programming for a while 
and work on your attitude?


While you have no proof of this, If you do a little soul 
searching you'll find that the world doesn't revolve around 
you. Put down your toys and get out of the sandbox and you 
might learn something!


Dude you are kind of being a jerk. He's just arguing against, 
rather passionately, a design decision he thinks is poor. It 
values no one if individuals remain quiet and conform. 
Certainly not the leadership. What you see as arrogance is 
really just passion.


Passion or not,

"If you are wondering why I'm inflammatory, here you go. You 
are pulling me the old prove a negative trick. You have good 
evidence that DIP25 is good design ? Good, because I have none. 
And that's my proof. As long as I have no evidence that DIP25 
is good, DIP25 is bad."


That statement shows a lot of arrogance.

It he not really just saying "I have no clue if X is true, but 
since I don't know, I'll just assume it's false and assume you 
are wrong.".


That's not very logical. Why wouldn't he just as well assume X 
is true?


The context is that all additions have an intrinsic cost because 
they increase complexity and restrict future design choices, 
therefore the onus is on any change/addition to justify its value 
in order to overcome that cost.


I think you are completely misreading the situation, or trolling. 
This is just

Re: DIP74 - where is at?

[Joseph Rushton Wakeling via Digitalmars-d]

On Monday, 12 October 2015 at 08:10:44 UTC, deadalnix wrote:

Ok, I'll write a DIP.


That would be great to see.  N.B. it's not only about Walter and 
Andrei: with a detailed, written-up proposal in place, the rest 
of us can examine it and, assuming we like it, lend our vocal 
support to the idea.

Re: Synchronized classes have no public members

[Benjamin Thaut via Digitalmars-d]

On Tuesday, 13 October 2015 at 12:20:17 UTC, Minas Mina wrote:


I agree that synchronized classes / functions that not that 
useful.


But synchronized statements, to me, make the intention of 
locking explicit.


Synchronized statements are fine and serve a good purpose, no 
need to delete them in my opinion.




Maybe the internal monitor could be removed (with synchronized 
classes / functions as well), and allow synchronized() {} to be 
called on Lock objects, that essentially locks them at the 
beginning and unlocks them at the end.


Yes, I would love that.

Re: Synchronized classes have no public members

[Dicebot via Digitalmars-d]

On Tuesday, 13 October 2015 at 12:51:14 UTC, Benjamin Thaut wrote:

On Tuesday, 13 October 2015 at 12:20:17 UTC, Minas Mina wrote:


I agree that synchronized classes / functions that not that 
useful.


But synchronized statements, to me, make the intention of 
locking explicit.


Synchronized statements are fine and serve a good purpose, no 
need to delete them in my opinion.




Maybe the internal monitor could be removed (with synchronized 
classes / functions as well), and allow synchronized() {} to 
be called on Lock objects, that essentially locks them at the 
beginning and unlocks them at the end.


Yes, I would love that.


Isn't dedicated language feature a bit too much for a glorified 
mutex scope guard?

Re: DIP74 - where is at?

[Manu via Digitalmars-d]

On 12 October 2015 at 16:02, Andrei Alexandrescu via Digitalmars-d
 wrote:
>
> DIP69 is obviously known to me because my name is on it.

What is the problem with DIP69? It looks like a great direction to me.
It's almost exactly what I've been begging for for years!
As long as methods can overload on scope, then it can be used to
implement efficient RC. Also many other situations are improved in
general.

The only thing there that's not clear to me from DIP69 is:
  scope ref T func(scope ref T x) { return x; }

This needs to work, or you can't chain... but it doesn't look like
it's addressed?

[Issue 12421] Allow simpler syntax for lambda template declarations

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/dmd/commit/445e1734f450f8e4a5c2f38b5ad0dfe2c937f897
fix Issue 12421 - Allow simpler syntax for lambda template declarations

https://github.com/D-Programming-Language/dmd/commit/78820390932309c1c5503770ebcaec338bd69b88
Merge pull request #3638 from 9rnsr/fix12421

Issue 12421 - Allow simpler syntax for lambda template declarations

--

Re: DIP74 - where is at?

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 12 October 2015 at 19:35:34 UTC, Marco Leise wrote:

Wouldn't it be great if everyone took notes of the currently
perceived shortcomings of shared so that there is a pile of
use- and corner-cases to look at for a redesign?


The problem with shared is that shared should not be constant 
over time, it should be related to behavioural typing/type state.


Synchronization is a temporal factor not a static typing factor.

Re: Regarding std.array.Appender

[Suliman via Digitalmars-d-learn]

On Tuesday, 13 October 2015 at 13:51:50 UTC, anonymous wrote:

On Tuesday 13 October 2015 15:42, Suliman wrote:

map!(a=> a~=" +") work fine, but how to add before at same 
time?


Use ~ instead of ~=, like so: map!(a => "+" ~ a ~ "+")


Thanks!

dynamic get from variantArray() data table

[data pulverizer via Digitalmars-d-learn]

Hi,

I am trying to use variantArray() as a data table object to hold 
columns each of which is an array of a specific type. I need to 
be able to get values from data table but I am having problems ...



import std.stdio; // i/o
import std.variant; // type variations

void main(){
  // Columns of the table
  string[] names = ["walter", "paul", "jeff", "andrie"];
  int[] age = [55, 62, 27, 52];
  string[] language = ["D", "Haskell", "Julia", "D"];
  Variant[] dt = variantArray(names, age, language);

  foreach(col; dt){
foreach(el; col){
  // here I try a kind of dynamic cast operator
  auto x = el.get!(type(el)); // gives error
  write(x);
}
write("\n");
  }
}

data_table.d(37): Error: cannot infer type for el
data_table.d(38): Error: undefined identifier 'el'

Help

DP

[Issue 15200] [REG2.068.2] ICE(glue.c) when compiling with -inline

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull
   Hardware|x86_64  |All
 OS|Windows |All

--- Comment #1 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5192

--

Re: dynamic get from variantArray() data table

[Alex Parrill via Digitalmars-d-learn]

On Tuesday, 13 October 2015 at 15:17:15 UTC, data pulverizer 
wrote:

Hi,

I am trying to use variantArray() as a data table object to 
hold columns each of which is an array of a specific type. I 
need to be able to get values from data table but I am having 
problems ...



import std.stdio; // i/o
import std.variant; // type variations

void main(){
  // Columns of the table
  string[] names = ["walter", "paul", "jeff", "andrie"];
  int[] age = [55, 62, 27, 52];
  string[] language = ["D", "Haskell", "Julia", "D"];
  Variant[] dt = variantArray(names, age, language);

  foreach(col; dt){
foreach(el; col){
  // here I try a kind of dynamic cast operator
  auto x = el.get!(type(el)); // gives error
  write(x);
}
write("\n");
  }
}

data_table.d(37): Error: cannot infer type for el
data_table.d(38): Error: undefined identifier 'el'

Help

DP


You're trying to iterate over a `Variant`, which isn't 
implemented.


You don't want to use a variant here anyway; you should use a 
struct or tuple for each entry in the table.




import std.typecons;

alias Entry = Tuple!(string, int, string);

void main() {
auto table = [Entry("walter", 55, "D"), Entry("paul", 62, 
"Haskell"), ... ]; // complete array

foreach(entry; table) {
writeln(entry.expand);
}
}

[Issue 15185] [REG2.069.0-b1] Not possible to create instance of TypeInfo

[via Digitalmars-d-bugs]

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

--- Comment #6 from Jacob Carlborg  ---
(In reply to Steven Schveighoffer from comment #5)
> Why not "typeid(const(Object))" and "(const(Object)).classinfo" ?

The existing code will evaluate to "const(TypeInfo)". Your suggestion evaluates
to "TypeInfo_Const". I guess I could hard code "const(TypeInfo)", but then I
need put the whole alias declaration in a string mixin.

It's not like I don't know how work around the change. It broke my code so I
reported an issue.

--

Re: Hash-Table-Based Multiple Arguments Replacement

[Per Nordlöw via Digitalmars-d-learn]

On Sunday, 11 October 2015 at 11:17:29 UTC, Nordlöw wrote:

Here's a solution:
https://github.com/nordlow/justd/blob/f8519e8a1af68bc25cc00c6ef12d13efa791250c/comparison_ex.d


Latest version contains a few fixes:

https://github.com/nordlow/justd/blob/master/comparison_ex.d

Re: DIP74 - where is at?

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 13 October 2015 at 13:02:43 UTC, Ola Fosheim Grøstad 
wrote:

That said, if you have:

1. writer-ownership as a feature
2. mark variables as "only writable by one owner"

Then the compiler can drop some read locks for the _owning_ 
thread.


But D does not have ownership as a feature beyond "thread local 
memory"?


I think the D designers should take a long and hard look at Pony:

isolated: deny global read/write, deny local read/write
transition: deny global read/write, deny local write
reference: deny global read/write
value: deny global write, deny local write
box: deny global write aliases
tag: allow all aliases

_loosely_ translated:

isolated: void*
transition: const T*
reference: T*
value: immutable T*
box: globally as shared const T*, locally as shared T*
tag: shared T*

So D lacks some way to express the "box" type?

Re: Beta D 2.069.0-b1

[Kagamin via Digitalmars-d-announce]

On Tuesday, 13 October 2015 at 13:57:15 UTC, Meta wrote:

On Tuesday, 13 October 2015 at 13:18:36 UTC, Kagamin wrote:
Well, in order to pass the result of a function call to a 
template parameter means that the function must be evaluated 
at compile time, which is not always possible, so it probably 
doesn't make sense to call a function when passed as a 
template argument.


You'd be surprised what DMD thinks is a function call and what 
isn't.


What doesn't work for you?

extern int f();
struct T(F){}
T!f t; //Error: template instance T!(f) does not match template 
declaration T(F)

struct A(alias F){}
A!f a; //works

[Issue 15185] [REG2.069.0-b1] Not possible to create instance of TypeInfo

[via Digitalmars-d-bugs]

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

--- Comment #7 from Steven Schveighoffer  ---
(In reply to Jacob Carlborg from comment #6)
> 
> The existing code will evaluate to "const(TypeInfo)". Your suggestion
> evaluates to "TypeInfo_Const". I guess I could hard code "const(TypeInfo)",
> but then I need put the whole alias declaration in a string mixin.

OK, I see now.

Honestly, I don't see this as a regression. TypeInfo was not meant to be
instantiated by user code. The fact that it worked I don't think was intended,
just an accident (The runtime obviously never instantiates a direct TypeInfo,
it's always a subclass).

I recommend employing a workaround and closing this bug.

--

Re: Ternary if and ~ does not work quite well

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, October 11, 2015 22:21:55 H. S. Teoh via Digitalmars-d-learn wrote:
> It's best to parenthesize when mixing other operators with ?, because ?
> has a pretty low precedence and may "steal" arguments from surrounding
> operators that you don't intend.  My suspicion is that what you wrote is
> being parsed as:
>
>   writeln(("foo " ~ true) ? "bar" : "baz");
>
> which is why you're getting unexpected output. Write instead:
>
>   writeln("foo " ~ (true ? "bar" : "baz"));
>
> If anything, it also helps readers of your code understand what it does
> without needing to consult the precedence table.

The ternary operator is on the next to bottom rung on the same level with
the various assigment operators. The _only_ operator with lower precedence
than the ternary operator is the comma (be it the comma operator or the
comma as an argument separator). So, if you're doing something like

auto i = foo == bar ? "hello" : "world";

or

foo(arg1, foo == bar ? "hello" : "world", arg3);

then the ternary is done before the stuff around it, but other than that,
everything around it is going to be done first. So, whether you need parens
are not is actually pretty straightforward. It pretty much boils down to if
you want the ternary to be done before anything else around it, use parens.
If you want the ternary operator to be done last, then you don't need them.

I actually think that the ternary operator is very easy to get right because
it's pretty much at one end of the operator precedence table rather than in
the middle where you have to remember what goes before and what comes after.
But for some reason, a lot of folks seem to assume that it has different
precedence than it has and have trouble with it.

- Jonathan M Davis

Re: dynamic get from variantArray() data table

[Alex Parrill via Digitalmars-d-learn]

On Tuesday, 13 October 2015 at 16:22:36 UTC, data pulverizer 
wrote:
Thanks for the suggestion Alex, however I need the dynamic 
behaviour properties of variantArray(), writing a struct each 
time would be undesirable.


Perhaps I could boil down the question to something like, is 
there a way of writing


auto x = dt[0][0];
auto y = x.get!(x.type - or whatever); // to get the actual 
value of x rather than .VariantN! ... type


For some kind of auto cast back to basic type.


The problem is that you can't do `x.get!(x.type)`, because the 
type of the expression must be known at compile time, but 
`x.type` is a runtime value. You'd have to create a branch for 
each type that `x.type` might be.


But again, unless you are dealing with a truly dynamic layout 
(and not a bunch of fixed layouts), there's better options. For 
example, you can use `std.range.zip` to iterate through each 
column array in lockstep, returning tuples for each element.



foreach(entry; zip(names, ages, languages)) {
write(entry.expand);
}

[Issue 14835] Statement is not reachable doesn't play along generic code

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #2 from Steven Schveighoffer  ---
Why can't the "hack" variable be eliminated by enclosing the rest of the
function in the else branch?

And what about this solution for the group comparison (copied from my post in
Issue 15166):

private bool compare(alias Group1, alias Group2)()
{
foreach (index, element; Group!(Group1.expand, void).expand)
{
static if(index == Group1.expand.length)
return true;
else static if (!is(Group1.expand[index] == Group2.expand[index]))
return false;
}
}

Neither requires recursion.

--

Re: [OT] LLVM Community Code of Conduct

[Walter Bright via Digitalmars-d]

On 10/13/2015 6:36 AM, Daniel Kozak wrote:

lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

Maybe we could have something similar in D community


No. People who need to be told what decent behavior is won't pay 
attention to such a document.

[Issue 15200] [REG2.068.2] ICE(glue.c) when compiling with -inline

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Beta D 2.069.0-b1

[Rainer Schuetze via Digitalmars-d-announce]

On 13.10.2015 21:44, ZombineDev wrote:

On Tuesday, 13 October 2015 at 19:17:27 UTC, ZombineDev wrote:

On Tuesday, 13 October 2015 at 19:14:51 UTC, ZombineDev wrote:
[...]


Is the problem related to the new CRT in VS2015? Previously I thought
that the problem is 64-bit only, but it seams like it is for both 32-bit
and 64-bit MSCOFF.


The library issues are the same for 32-bit and 64-bit.



With the VS2015 x64 Native Tools Command Prompt I did:
cl main.cpp C:\D\dmd2\windows\lib64\phobos64.lib

And got:

main.cpp
phobos64.lib(sections_win64_6c9_5a5.obj) : error LNK2019: unresolved
external sy
mbol _minfo_beg referenced in function
_D2rt14sections_win6414getModuleInfosFZAy
PS6object10ModuleInfo
phobos64.lib(sections_win64_6c9_5a5.obj) : error LNK2019: unresolved
external sy
mbol _minfo_end referenced in function
_D2rt14sections_win6414getModuleInfosFZAy
PS6object10ModuleInfo
phobos64.lib(sections_win64_6c3_4e2.obj) : error LNK2019: unresolved
external sy
mbol _deh_beg referenced in function
_D2rt14sections_win6412SectionGroup8ehTable
sMxFNdZAyS2rt15deh_win64_posix9FuncTable
phobos64.lib(sections_win64_6c3_4e2.obj) : error LNK2019: unresolved
external sy
mbol _deh_end referenced in function
_D2rt14sections_win6412SectionGroup8ehTable
sMxFNdZAyS2rt15deh_win64_posix9FuncTable
phobos64.lib(config_48f_452.obj) : error LNK2019: unresolved external
symbol snp
rintf referenced in function
_D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb
phobos64.lib(config_48f_452.obj) : error LNK2019: unresolved external
symbol ssc
anf referenced in function
_D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb
main.exe : fatal error LNK1120: 6 unresolved externals

AFAIR, the support for VS2015 CRT was merged and is included in this
release, correct?


Yes, but there is some magic involved when linking against the VS2015 
CRT. To use symbols like snprintf and sscanf, you must also pass 
legacy_stdio_definitions.lib to the linker, which is done automatically 
if you use dmd as a frontend to the linker, but not cl.


Symbols _minfo_beg, _minfo_end, _deh_beg and _deh_end are only emitted 
by the compiler if you compile main, WinMain or DllMain. Unfortunately, 
compiling D's main also generates a C-style main, so it's not so easy to 
get these symbols if you need main in C/C++.


I would currently recommend to write main in D, and call into C/C++ from 
there.

[Issue 14835] Statement is not reachable doesn't play along generic code

[via Digitalmars-d-bugs]

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

--- Comment #4 from Steven Schveighoffer  ---
What the compiler is doing here is giving you information that code you wrote
will not get executed.

The problem is that the code in question is only one *particular* execution (or
instantiation) of that code.

To your example, isEven!1 will execute the line of code that is deemed to be
unreachable.

The issue here is that the compiler can't "try all possibilities" to see if it
will be able to find a path to that code (halting problem).

So probably we should turn off that feature when the code has taken a branch
based on a template constant or a static if. The compiler should assume the
other branch could be executed for a different instantiation, and so not
complain for this one.

I don't think there's a "right" way to handle this. The error in question is
truly a function of optimization and folding, but the user sees things in terms
of lines of code. To say a line of code may not be executed if you call it one
way is an error, even though it will be executed if you call it another way,
doesn't make a lot of sense. If we are going to be "helpful", we should at
least be accurate.

This is coming from someone who doesn't know how the compiler is implemented,
or doesn't even know how compilers are implemented. So perhaps this is too
difficult a task?

BTW, I was also saying that you *could* fix the problem without dummy variables
or recursion, but I agree that the compiler is being unhelpful here.

--

Re: [OT] LLVM Community Code of Conduct

[Chris via Digitalmars-d]

On Tuesday, 13 October 2015 at 19:13:07 UTC, Walter Bright wrote:

On 10/13/2015 6:36 AM, Daniel Kozak wrote:

lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

Maybe we could have something similar in D community


No. People who need to be told what decent behavior is won't 
pay attention to such a document.


:-)

Re: [OT] LLVM Community Code of Conduct

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 13 October 2015 at 19:13:07 UTC, Walter Bright wrote:

On 10/13/2015 6:36 AM, Daniel Kozak wrote:

lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html

Maybe we could have something similar in D community


No. People who need to be told what decent behavior is won't 
pay attention to such a document.


I was considering saying that we shouldn't add one unless the 
need presents itself, and for the most part, our community has 
been well-behaved, but your response is spot-on. About the only 
reason that I can think of why we might really benefit from such 
a document would be if we did have a problem, and we needed a way 
to fairly justify kicking people out of the newsgroup or from 
other official D channels, then we'd have a set of rules to point 
to that the person had violated rather than it just being the 
say-so of someone in charge. But fortunately, we haven't 
generally had problems like that. Occasionally, we've had a bad 
apple show up and cause problems, but none have stayed around 
long term, and things are normally pretty civil around here.


- Jonathan M Davis

[Issue 15184] Wrongly shaped array accepted as matrix initializer

[via Digitalmars-d-bugs]

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

Wyatt  changed:

   What|Removed |Added

 CC||wyatt@gmail.com

--- Comment #1 from Wyatt  ---
The documentation on Arrays states that a static matrix declaration is
contiguous in memory so I'd guess this is actually intentional?  Or at least
tacitly approved as a holdover from C?  D doesn't really seem to have a strong
concept of rank or shape and, from what I could decipher of the grammar, this
scenario isn't really covered.

Does this also indicate the need for a rho or reshape function?

--

[Issue 15200] [REG2.068.2] ICE(glue.c) when compiling with -inline

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/204df57a5ab578423dc655be6d4a2a733caa0362
fix Issue 15200 - ICE(glue.c) when compiling with -inline

Even if a function is expanded by inlining, the function itself don't have to
put in object file. In short, adjusting `ti.minst` in `inline.d` is not
correct.

The unspeculation in `expandInline` was added in the PR #4944, but sadly it was
just a hack and inherently unneeded. The changes in
`TemplateInstance.appendToModuleMember` and `needsCodegen` those were added
since 2.068.1-b1, now correctly handle codegen of nested template instances.

https://github.com/D-Programming-Language/dmd/commit/1e5d3b0427cc77199c1d03607256ff8518adf1e9
Merge pull request #5192 from 9rnsr/fix15200

[REG2.068.2] Issue 15200 - ICE(glue.c) when compiling with -inline

--

Re: Synchronized classes have no public members

[Dicebot via Digitalmars-d]

On Tuesday, 13 October 2015 at 18:28:23 UTC, Marco Leise wrote:

Guys, sorry to break into your wishful thinking, but

   synchronized(mutex) {}

already works as you want it to since as long as I can think. 
Yes, it takes a parameter, yes it calls lock/unlock on the 
mutex. :)


Yes, and I am saying that it doesn't justify presence of 
`synchronized` keyword in the language at all, being historical 
legacy misfeature.

Re: Beta D 2.069.0-b1

[ZombineDev via Digitalmars-d-announce]

On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

First beta for the 2.069.0 release.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.069.0.html


Please report any bugs at https://issues.dlang.org

-Martin


I decided to try the newly included mscoff 32 Phobos. For this 
purpouse I create a D struct, whose members I call in C++. This 
works in Linux, so any issues should be windows specific.


My directory has the following files:
test_struct.d
main.cpp

I did the following:
1) Installed DMD v2.069.0-b1 with the installer
2) Started VS2015 x86 Native Tools Command Prompt
3) Executed the following commands:
dmd -c -m32mscoff test_struct.d
cl main.cpp test_struct.obj 
C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib


And got the following error:
main.cpp
phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: 
unresolved exter
nal symbol __minfo_beg referenced in function 
_D2rt14sections_win6414getModuleIn

fosFZAyPS6object10ModuleInfo
phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: 
unresolved exter
nal symbol __minfo_end referenced in function 
_D2rt14sections_win6414getModuleIn

fosFZAyPS6object10ModuleInfo
phobos32mscoff.lib(config_48f_452.obj) : error LNK2019: 
unresolved external symb
ol _snprintf referenced in function 
_D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAx

aKfZb
phobos32mscoff.lib(config_48f_452.obj) : error LNK2019: 
unresolved external symb
ol _sscanf referenced in function 
_D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaK

fZb
hw0_cpp.exe : fatal error LNK1120: 4 unresolved externals

I have declared the druntime hooks like this:
extern "C" int rt_init();
extern "C" void rt_term();

P.S. I decided to try something simpler:
A single .cpp file that calls rt_init() and rt_term() and nothing 
else. I tried the following:

cl main.cpp C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib
And I got the same error message.

Any idea what's going wrong?

Re: Synchronized classes have no public members

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 13 October 2015 at 19:05:31 UTC, Dicebot wrote:

On Tuesday, 13 October 2015 at 18:28:23 UTC, Marco Leise wrote:

Guys, sorry to break into your wishful thinking, but

   synchronized(mutex) {}

already works as you want it to since as long as I can think. 
Yes, it takes a parameter, yes it calls lock/unlock on the 
mutex. :)


Yes, and I am saying that it doesn't justify presence of 
`synchronized` keyword in the language at all, being historical 
legacy misfeature.


The same can be done trivially with a guard/autolock object, 
because we have RAII. It can also be done with scope statements, 
though that's more verbose. I suspect that C# has it primarily 
because they don't have RAII.


I don't know that it really hurts D to have synchronized 
statements, but I do agree that they really don't add much in the 
way of value. And it's not like it's hard to come up with cases 
where they don't even work, whereas a guard/autolock could (e.g. 
having to unlock the mutex partway through a block, possibly 
relocking it later in the block, possibly not).


- Jonathan M Davis

Re: Synchronized classes have no public members

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 13 October 2015 at 18:27:43 UTC, Jonathan M Davis 
wrote:
they should be creating multiple mutexes. Having a single mutex 
for a class is usually overly broad - regardless of whether all 
of the functions in a class are synchronized or only select 
ones are. And when you _do_ use a single mutex for an entire 
class, I've found that it's often the case that the mutex


Monitor classes is a high level convenience feature that one has 
to put work into if it is to be good. It is however much less 
error prone than mutexes and semaphores.


The point is that you create a robust encapsulated facade and 
only weaken the facade after static analysis has proven that 
locks are superfluous. Doing this manually is error prone.


One can also add high level concurrency mechanisms like 
guarantees for obtaining a set of resources before obtaining the 
lock, e.g. the caller supplies a predicate like "user Eric and 
user Lisa is available" and is suspended until the predicate is 
satisfiable.


But it needs more high level features than D has today.

[Issue 15166] [REG2.069-devel] spurious statement not reachable warning in static foreach loop

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #6 from Steven Schveighoffer  ---
(In reply to Martin Nowak from comment #4)
> A workaround is to use a variable.

I think this may be the right answer.

It boils down to this:

static if(someCondition) return false;
return true;

Which you would normally write with else, but it's not so simple in this case,
because the "else" would be part of the loop.

I'm curious why the return short-circuits the loop. In other words, why aren't
all the "return false" statements besides the first one flagged for
unreachability? Is it because the compiler stops generating the statements? I
mean, if you rewrote as a bunch of static ifs, then wouldn't you have the same
problem?

Another possible answer is to do this:

private bool compare(alias Group1, alias Group2)()
{
foreach (index, element; Group!(Group1.expand, void).expand)
{
static if(index == Group1.expand.length)
return true;
else static if (!is(Group1.expand[index] == Group2.expand[index]))
return false;
}
}

--

Re: dynamic get from variantArray() data table

[data pulverizer via Digitalmars-d-learn]

Thanks for the suggestion Alex, however I need the dynamic 
behaviour properties of variantArray(), writing a struct each 
time would be undesirable.


Perhaps I could boil down the question to something like, is 
there a way of writing


auto x = dt[0][0];
auto y = x.get!(x.type - or whatever); // to get the actual value 
of x rather than .VariantN! ... type


For some kind of auto cast back to basic type.

On Tuesday, 13 October 2015 at 15:51:40 UTC, Alex Parrill wrote:
On Tuesday, 13 October 2015 at 15:17:15 UTC, data pulverizer 
wrote:

Hi,

I am trying to use variantArray() as a data table object to 
hold columns each of which is an array of a specific type. I 
need to be able to get values from data table but I am having 
problems ...



import std.stdio; // i/o
import std.variant; // type variations

void main(){
  // Columns of the table
  string[] names = ["walter", "paul", "jeff", "andrie"];
  int[] age = [55, 62, 27, 52];
  string[] language = ["D", "Haskell", "Julia", "D"];
  Variant[] dt = variantArray(names, age, language);

  foreach(col; dt){
foreach(el; col){
  // here I try a kind of dynamic cast operator
  auto x = el.get!(type(el)); // gives error
  write(x);
}
write("\n");
  }
}

data_table.d(37): Error: cannot infer type for el
data_table.d(38): Error: undefined identifier 'el'

Help

DP


You're trying to iterate over a `Variant`, which isn't 
implemented.


You don't want to use a variant here anyway; you should use a 
struct or tuple for each entry in the table.




import std.typecons;

alias Entry = Tuple!(string, int, string);

void main() {
auto table = [Entry("walter", 55, "D"), Entry("paul", 62, 
"Haskell"), ... ]; // complete array

foreach(entry; table) {
writeln(entry.expand);
}
}

Re: DIP74 - where is at?

[Robert burner Schadek via Digitalmars-d]

On Tuesday, 13 October 2015 at 17:59:28 UTC, deadalnix wrote:

Hilter was very passionate too, are you saying he was right?


ICH BIN EIN POLYNOMIAL!


As this thread has run it course starting with the Hitler 
comparison, and is therefor OT.

You have to explain to me, why your are a polynomial :-)

Re: Synchronized classes have no public members

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut wrote:
I have to agree here. I think synchronized classes are of very 
little use, especially because they don't "cast away" shared in 
a useful way. It still has to be done manually. I think we 
should remove them. Synchronized methods should also be removed 
in my eyes. Making each and every object bigger by one pointer 
just for the sake of a few synchronized methods doesn't seem to 
be a good trade off to me. The entire synchronized methods give 
the user the feeling that he simply slaps synchronized on his 
class / method and then its thread safe and he doesn't have to 
care about threads anymore. In the real world this is far from 
true however. So synchronized methods and classes just give a 
false sense of thread safety and should rather be removed.


I'm fine with having synchronized classes, and I'm fine with 
having synchronized classes removed from the language entirely.


I think that synchronized functions provide almost no value over 
simply using mutexes, and they give the false impression that 
slapping synchronized on it solves the concurrency problem, 
whereas it's often far more complicated than that. In most cases, 
it's better to have mutexes be for a specific variable or group 
of variables, in which case, having a single mutex for the object 
just risks folks reusing that mutex when they should be creating 
multiple mutexes. Having a single mutex for a class is usually 
overly broad - regardless of whether all of the functions in a 
class are synchronized or only select ones are. And when you _do_ 
use a single mutex for an entire class, I've found that it's 
often the case that the mutex shouldn't be part of the class, 
because you need to lock it with some other piece of data at the 
same time (e.g. lock a linked list variable and another, related, 
variable via a lock external to them rather than having the 
linked list manage its own lock and then need another lock around 
both of those variables). synchronized on functions/classes is 
just not a good replacement for explicit mutexes, and it 
encourages bad practices IMHO.


The primary advantage that I see to synchronized classes is that 
they can safely, implicitly strip off the outer layer of shared - 
and that's the only way that we've come up with thus far that we 
can safely, implicitly strip off shared at all. However, because 
it's only the outer layer, I'm not sure that it's worth it. And 
creating whole classes just to encapsulate shared seems like 
overkill to me, especially if you end up having to cast away 
shared inside the class anyway. But even then, I would think that 
a synchronized class makes more sense as a small wrapper around a 
group of variables that need to be protected by a single mutex 
than it does to slap synchronized on a class like LinkedList, and 
I expect that there are going to be plenty of programmers looking 
to just slap synchronized on a class and have it magically fix 
their shared problems for them (and then getting annoyed when 
they still have shared problems inside of the class, because only 
the outer layer of shared was stripped off).


So, if we have synchronized on classes or functions, I think that 
we should have synchronized classes, not individually 
synchronized functions. But I'm not convinced that having either 
synchronized classes or functions is actually a good idea. So, if 
we were to decide to deprecate the synchronized attribute 
altogether, it wouldn't hurt my feelings any. It's a misfeature 
from Java IMHO. But at least synchronized classes are a valiant 
attempt to get some value out of it.


- Jonathan M Davis

Re: Synchronized classes have no public members

[Marco Leise via Digitalmars-d]

Am Tue, 13 Oct 2015 12:52:55 +
schrieb Dicebot :

> On Tuesday, 13 October 2015 at 12:51:14 UTC, Benjamin Thaut wrote:
> > On Tuesday, 13 October 2015 at 12:20:17 UTC, Minas Mina wrote:
> >>
> >> I agree that synchronized classes / functions that not that 
> >> useful.
> >>
> >> But synchronized statements, to me, make the intention of 
> >> locking explicit.
> >
> > Synchronized statements are fine and serve a good purpose, no 
> > need to delete them in my opinion.
> >
> >>
> >> Maybe the internal monitor could be removed (with synchronized 
> >> classes / functions as well), and allow synchronized() {} to 
> >> be called on Lock objects, that essentially locks them at the 
> >> beginning and unlocks them at the end.
> >
> > Yes, I would love that.
> 
> Isn't dedicated language feature a bit too much for a glorified 
> mutex scope guard?

Guys, sorry to break into your wishful thinking, but

   synchronized(mutex) {}

already works as you want it to since as long as I can think.
Yes, it takes a parameter, yes it calls lock/unlock on the
mutex. :)

-- 
Marco

Re: DIP74 - where is at?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 13 October 2015 at 18:23:05 UTC, Marco Leise wrote:
Ok, so here we arrived in d.religion. Today: "Agnostic vs. 
atheist, who is right." And: "Testimony: I tried to change the 
world but God didn't give me the source code."


Well, I talk about D-ifying code sometimes, but saying that out 
loud is problematic...


- Jonathan M Davis

Re: DIP74 - where is at?

[Robert burner Schadek via Digitalmars-d]

On Tuesday, 13 October 2015 at 18:24:13 UTC, deadalnix wrote:

That's a reference to The Oatmeal : 
http://theoatmeal.com/comics/atheism


thanks

Re: DIP74 - where is at?

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 13 October 2015 at 16:04:07 UTC, Ola Fosheim Grøstad 
wrote:

_loosely_ translated:

isolated: void*
transition: const T*
reference: T*
value: immutable T*
box: globally as shared const T*, locally as shared T*
tag: shared T*


The above turned out rather allegorical (and possibly confusing), 
the following is a lockfree interpretation that is a little bit 
more useful and somewhat more accurate:


ISOLATED: Unique!T
referable as void*, shared void*
transferrable to other threads

TRANSITION: Unique!T
referable as const T*, void*, shared void*
convertible to immutable T*

REFERENCE: T*
referable as T*, const T*, void*, shared void*

VALUE: immutable T*
referable as immutable T*, const T*, shared const T*, void*, 
shared void*

shareable with other threads

BOX: const T*
referable as const T*, void*, shared void*
aliasing with T*, immutable T*

TAG: void T* or shared void*
referable as void T*, shared void*
aliasing with all types as it is a pure identity


Then we can do a new interpretation with locking/synchronization 
and get something like:


LOCKED BOX: shared const T*
referable as shared const T*, void*, shared void*
aliasing with shared T*, immutable T*

LOCKED TAG: shared T*
referable as shared T*, shared const T*, void T*, shared void*

More or less...

Re: DIP74 - where is at?

[deadalnix via Digitalmars-d]

On Tuesday, 13 October 2015 at 12:16:26 UTC, Jacob wrote:
On Monday, 12 October 2015 at 19:35:33 UTC, Ice Cream Overload 
wrote:

On Monday, 12 October 2015 at 16:56:27 UTC, Jacob wrote:
I've noticed that you seem to be quite arrogant. Usually it 
is a result of ignorance. Your statement basically proves 
that.


Maybe you should take a break from programming for a while 
and work on your attitude?


While you have no proof of this, If you do a little soul 
searching you'll find that the world doesn't revolve around 
you. Put down your toys and get out of the sandbox and you 
might learn something!


Dude you are kind of being a jerk. He's just arguing against, 
rather passionately, a design decision he thinks is poor. It 
values no one if individuals remain quiet and conform. 
Certainly not the leadership. What you see as arrogance is 
really just passion.


Passion or not,

"If you are wondering why I'm inflammatory, here you go. You 
are pulling me the old prove a negative trick. You have good 
evidence that DIP25 is good design ? Good, because I have none. 
And that's my proof. As long as I have no evidence that DIP25 
is good, DIP25 is bad."


That statement shows a lot of arrogance.

It he not really just saying "I have no clue if X is true, but 
since I don't know, I'll just assume it's false and assume you 
are wrong.".


That's not very logical. Why wouldn't he just as well assume X 
is true?




Because people with half a brain know that's not how it works.

Proves me that unicorn do not exists. I'm waiting. And remember, 
having no evidence that they do exists doesn't mean they do not !



Hilter was very passionate too, are you saying he was right?


ICH BIN EIN POLYNOMIAL!

Re: DIP74 - where is at?

[Ice Cream Overload via Digitalmars-d]

On Tuesday, 13 October 2015 at 12:16:26 UTC, Jacob wrote:
On Monday, 12 October 2015 at 19:35:33 UTC, Ice Cream Overload 
wrote:

[...]


Passion or not,

"If you are wondering why I'm inflammatory, here you go. You 
are pulling me the old prove a negative trick. You have good 
evidence that DIP25 is good design ? Good, because I have none. 
And that's my proof. As long as I have no evidence that DIP25 
is good, DIP25 is bad."


That statement shows a lot of arrogance.

It he not really just saying "I have no clue if X is true, but 
since I don't know, I'll just assume it's false and assume you 
are wrong.".


That's not very logical. Why wouldn't he just as well assume X 
is true?


The fact is, he can't and shouldn't make such statements about 
X if he has no "evidence" about it.


Instead, wouldn't the proper approach be to discuss, learn, and 
share what one things in a positive way so everyone can learn 
about X and reach a more intelligent understanding of it?


Hilter was very passionate too, are you saying he was right?


Since you brought up the Hilter reference, it's useful to mention 
that he was successful because people blindly followed him and 
his actions...


But really...do we always have to resort to Hitler references 
when discussing disagreements? Seems very cliche.

Re: DIP74 - where is at?

[deadalnix via Digitalmars-d]

On Tuesday, 13 October 2015 at 18:18:46 UTC, Robert burner 
Schadek wrote:

On Tuesday, 13 October 2015 at 17:59:28 UTC, deadalnix wrote:

Hilter was very passionate too, are you saying he was right?


ICH BIN EIN POLYNOMIAL!


As this thread has run it course starting with the Hitler 
comparison, and is therefor OT.

You have to explain to me, why your are a polynomial :-)


That's a reference to The Oatmeal : 
http://theoatmeal.com/comics/atheism

Re: DIP74 - where is at?

[Marco Leise via Digitalmars-d]

Am Tue, 13 Oct 2015 17:59:26 +
schrieb deadalnix :

> > It he not really just saying "I have no clue if X is true, but 
> > since I don't know, I'll just assume it's false and assume you 
> > are wrong.".
> >
> > That's not very logical. Why wouldn't he just as well assume X 
> > is true?
> >
> 
> Because people with half a brain know that's not how it works.
> 
> Proves me that unicorn do not exists. I'm waiting. And remember, 
> having no evidence that they do exists doesn't mean they do not !

Ok, so here we arrived in d.religion. Today: "Agnostic vs.
atheist, who is right." And: "Testimony: I tried to change the
world but God didn't give me the source code."

-- 
Marco

[Issue 14835] Statement is not reachable doesn't play along generic code

[via Digitalmars-d-bugs]

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

--- Comment #3 from Mathias LANG  ---
Note that with this implementation you get an error (missing return) in
2.068.0, but 2.069.0-b1 fixed that.

But the point is not about the actual implementation, but the effect of this
warning. It makes meta code much harder to write that it's needed, and way less
natural. Will you accept a language where every `if` statement has to be
followed by an `else` statement ?

--

Struct toString works but not std.conv.to!string

[Nordlöw via Digitalmars-d-learn]

I have defined a struct UTCOffset in

https://github.com/nordlow/justd/blob/master/datetime_ex.d

Everything works as desired except for

import std.conv : to;
assert(UTCOffset(+14, 0).to!string == "UTC+14:00");

which fails as

/usr/include/dmd/phobos/std/conv.d(293,14): Error: template 
instance isRawStaticArray!() does not match template declaration 
isRawStaticArray(T, A...)
datetime_ex.d(129,29): Error: cannot resolve type for 
UTCOffset(cast(ubyte)0u).this(cast(byte)14, 
cast(ubyte)0u).to!string


I don't understand what's wrong.

Re: DIP74 - where is at?

[I SCREAM for ICECream via Digitalmars-d]

On Tuesday, 13 October 2015 at 21:17:43 UTC, Jacob wrote:
On Tuesday, 13 October 2015 at 18:13:33 UTC, Ice Cream Overload 
wrote:

On Tuesday, 13 October 2015 at 12:16:26 UTC, Jacob wrote:
On Monday, 12 October 2015 at 19:35:33 UTC, Ice Cream 
Overload wrote:

[...]


Passion or not,

"If you are wondering why I'm inflammatory, here you go. You 
are pulling me the old prove a negative trick. You have good 
evidence that DIP25 is good design ? Good, because I have 
none. And that's my proof. As long as I have no evidence that 
DIP25 is good, DIP25 is bad."


That statement shows a lot of arrogance.

It he not really just saying "I have no clue if X is true, 
but since I don't know, I'll just assume it's false and 
assume you are wrong.".


That's not very logical. Why wouldn't he just as well assume 
X is true?


The fact is, he can't and shouldn't make such statements 
about X if he has no "evidence" about it.


Instead, wouldn't the proper approach be to discuss, learn, 
and share what one things in a positive way so everyone can 
learn about X and reach a more intelligent understanding of 
it?


Hilter was very passionate too, are you saying he was right?


Since you brought up the Hilter reference, it's useful to 
mention that he was successful because people blindly followed 
him and his actions...


But really...do we always have to resort to Hitler references 
when discussing disagreements? Seems very cliche.


It's only cliche if you aren't interested in the truth. It 
doesn't matter if I used Hilter or any other person that was 
"passionate" but wrong.


Hilter is just the greatest example and most obvious example. 
If you actually understand the issue, you would realize it has 
nothing to do with Hilter.


I don't know. Whenever someone runs out of arguments and is 
forced to go on the attack, Hitler seems to be the first insult 
people reach for. Thus once I see Hitler references pop up, I 
throw out that individual's credibility. Solves bandwidth 
problems of who is worth listening to.


Some soul searching for you, is I'd refrain from such references 
as it only hurts your credibility. Not the one you sling it at.

Re: DIP74 - where is at?

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 13 October 2015 at 21:46:22 UTC, H. S. Teoh wrote:
Godwin's Law[1] has been invoked, boys and girls.  The game is 
now over. Thanks for playing.  You may go home now.  Have a 
nice day.


Neh, Godwin's law only states that as time progresses the 
probability of invoking "Hitler" as an example increases, but it 
says nothing about whether the comparison was useful or not.

[Issue 15184] Wrongly shaped array accepted as matrix initializer

[via Digitalmars-d-bugs]

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

--- Comment #2 from bearophile_h...@eml.cc ---
(In reply to Wyatt from comment #1)
> The documentation on Arrays states that a static matrix declaration is
> contiguous in memory so I'd guess this is actually intentional?

A serious language needs should not be sloppy.

--

Re: DIP74 - where is at?

[Jacob via Digitalmars-d]

On Tuesday, 13 October 2015 at 18:13:33 UTC, Ice Cream Overload 
wrote:

On Tuesday, 13 October 2015 at 12:16:26 UTC, Jacob wrote:
On Monday, 12 October 2015 at 19:35:33 UTC, Ice Cream Overload 
wrote:

[...]


Passion or not,

"If you are wondering why I'm inflammatory, here you go. You 
are pulling me the old prove a negative trick. You have good 
evidence that DIP25 is good design ? Good, because I have 
none. And that's my proof. As long as I have no evidence that 
DIP25 is good, DIP25 is bad."


That statement shows a lot of arrogance.

It he not really just saying "I have no clue if X is true, but 
since I don't know, I'll just assume it's false and assume you 
are wrong.".


That's not very logical. Why wouldn't he just as well assume X 
is true?


The fact is, he can't and shouldn't make such statements about 
X if he has no "evidence" about it.


Instead, wouldn't the proper approach be to discuss, learn, 
and share what one things in a positive way so everyone can 
learn about X and reach a more intelligent understanding of it?


Hilter was very passionate too, are you saying he was right?


Since you brought up the Hilter reference, it's useful to 
mention that he was successful because people blindly followed 
him and his actions...


But really...do we always have to resort to Hitler references 
when discussing disagreements? Seems very cliche.


It's only cliche if you aren't interested in the truth. It 
doesn't matter if I used Hilter or any other person that was 
"passionate" but wrong.


Hilter is just the greatest example and most obvious example. If 
you actually understand the issue, you would realize it has 
nothing to do with Hilter.

Re: DIP74 - where is at?

[H. S. Teoh via Digitalmars-d]

On Tue, Oct 13, 2015 at 09:37:27PM +, I SCREAM for ICECream via 
Digitalmars-d wrote:
> On Tuesday, 13 October 2015 at 21:17:43 UTC, Jacob wrote:
> >On Tuesday, 13 October 2015 at 18:13:33 UTC, Ice Cream Overload wrote:
> >>On Tuesday, 13 October 2015 at 12:16:26 UTC, Jacob wrote:
> >>>On Monday, 12 October 2015 at 19:35:33 UTC, Ice Cream Overload wrote:
> [...]
> >>>
> >>>Passion or not,
> >>>
> >>>"If you are wondering why I'm inflammatory, here you go. You are
> >>>pulling me the old prove a negative trick. You have good evidence
> >>>that DIP25 is good design ? Good, because I have none. And that's
> >>>my proof.  As long as I have no evidence that DIP25 is good, DIP25
> >>>is bad."
> >>>
> >>>That statement shows a lot of arrogance.
> >>>
> >>>It he not really just saying "I have no clue if X is true, but
> >>>since I don't know, I'll just assume it's false and assume you are
> >>>wrong.".
> >>>
> >>>That's not very logical. Why wouldn't he just as well assume X is
> >>>true?
> >>>
> >>>The fact is, he can't and shouldn't make such statements about X if
> >>>he has no "evidence" about it.
> >>>
> >>>Instead, wouldn't the proper approach be to discuss, learn, and
> >>>share what one things in a positive way so everyone can learn about
> >>>X and reach a more intelligent understanding of it?
> >>>
> >>>Hilter was very passionate too, are you saying he was right?
> >>
> >>Since you brought up the Hilter reference, it's useful to mention
> >>that he was successful because people blindly followed him and his
> >>actions...
> >>
> >>But really...do we always have to resort to Hitler references when
> >>discussing disagreements? Seems very cliche.
> >
> >It's only cliche if you aren't interested in the truth. It doesn't
> >matter if I used Hilter or any other person that was "passionate" but
> >wrong.
> >
> >Hilter is just the greatest example and most obvious example. If you
> >actually understand the issue, you would realize it has nothing to do
> >with Hilter.
> 
> I don't know. Whenever someone runs out of arguments and is forced to
> go on the attack, Hitler seems to be the first insult people reach
> for. Thus once I see Hitler references pop up, I throw out that
> individual's credibility.  Solves bandwidth problems of who is worth
> listening to.
> 
> Some soul searching for you, is I'd refrain from such references as it
> only hurts your credibility. Not the one you sling it at.

Godwin's Law[1] has been invoked, boys and girls.  The game is now over.
Thanks for playing.  You may go home now.  Have a nice day.

[1] https://en.wikipedia.org/wiki/Godwin's_law


T

-- 
"I'm not childish; I'm just in touch with the child within!" - RL

Re: Struct toString works but not std.conv.to!string

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, October 13, 2015 21:07:07 Nordlöw via Digitalmars-d-learn wrote:
> I have defined a struct UTCOffset in
>
> https://github.com/nordlow/justd/blob/master/datetime_ex.d
>
> Everything works as desired except for
>
>  import std.conv : to;
>  assert(UTCOffset(+14, 0).to!string == "UTC+14:00");
>
> which fails as
>
> /usr/include/dmd/phobos/std/conv.d(293,14): Error: template
> instance isRawStaticArray!() does not match template declaration
> isRawStaticArray(T, A...)
> datetime_ex.d(129,29): Error: cannot resolve type for
> UTCOffset(cast(ubyte)0u).this(cast(byte)14,
> cast(ubyte)0u).to!string
>
> I don't understand what's wrong.

Just glancing at your code, you've marked toString with @property, which is
kind of a weird thing to do, nd if we ever make @property enforce that it's
not called with parens, then that code won't work. So, you might try moving
that @property: to after toString and see if that fixes your problem. But
given the error, my guess is that the problem relates to the fact that you
templatized the constructor, which is often problematic, and whatever type
introspection std.conv.to is doing could be choking on that. So, you should
probably try making it so that the constructor isn't templatized and see if
that fixes the problem.

- Jonathan M Davis

Re: DIP74 - where is at?

[Give me the Ice Cream of the World via Digitalmars-d]

On Tuesday, 13 October 2015 at 21:46:22 UTC, H. S. Teoh wrote:
On Tue, Oct 13, 2015 at 09:37:27PM +, I SCREAM for ICECream 
via Digitalmars-d wrote:

On Tuesday, 13 October 2015 at 21:17:43 UTC, Jacob wrote:
>[...]

I don't know. Whenever someone runs out of arguments and is 
forced to go on the attack, Hitler seems to be the first 
insult people reach for. Thus once I see Hitler references pop 
up, I throw out that individual's credibility.  Solves 
bandwidth problems of who is worth listening to.


Some soul searching for you, is I'd refrain from such 
references as it only hurts your credibility. Not the one you 
sling it at.


Godwin's Law[1] has been invoked, boys and girls.  The game is 
now over. Thanks for playing.  You may go home now.  Have a 
nice day.


[1] https://en.wikipedia.org/wiki/Godwin's_law


T


Amazingly true :D

Re: DIP74 - where is at?

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 13 October 2015 at 21:17:43 UTC, Jacob wrote:
It's only cliche if you aren't interested in the truth. It 
doesn't matter if I used Hilter or any other person that was 
"passionate" but wrong.


You are right, but Andrei and Walter often go into "passionate 
but wrong" mode too... It's a curse of D and probably will keep 
it from reaching a mature state. DIP25 is no exception.


In language design it is better to have a small set of features  
in the core language that are easy to reason about as a whole. D 
has many simple features, but the combinatorial explosion is 
quite high.


For instance, how is DIP25 going to work with coroutines that 
yield? So you transfer a refererence by "return ref", then what 
you call yields and the object is destructed. When the coroutine 
is later resumed the object no longer exists, so you have a 
memory unsafe situation. So then you have to add the requirement 
that "return ref" functions cannot call anything that yields... 
After some time you realize that it is possible to pass in a 
lambda that can destroy the object. Then you forbid passing in 
lambdas...


What one should have realized is that if reasoning about 
correctness isn't obvious then you need proofs. There is no 
obvious memory safety in D and there are no proofs.


Meaning, you would be better off using a general static analyzer 
because you get more flexibility and the same level of memory 
safety.

Re: DIP74 - where is at?

[rsw0x via Digitalmars-d]

On Tuesday, 13 October 2015 at 22:20:02 UTC, Jonathan M Davis 
wrote:
On Tuesday, 13 October 2015 at 22:10:30 UTC, Ice Cream Madness 
wrote:

The D language, does have a 'feature' creep problem.


Maybe, but at this point, I think that C++ is actually getting 
features faster than D is. We talk about adding features or 
tweaking existing features to fix problems, but we're long past 
the point where we're frequently adding features. If anything, 
the typical complaint now is that we're _not_ making changes, 
even when we've been discussing them (e.g. this very thread was 
started to ask what the deal with a proposed change is, because 
it hasn't gone anywhere yet, and it's a change proposed by 
Walter and Andrei no less).


- Jonathan M Davis


DIP74 is also just an alternative solution to a problem that has 
a long history, and nothing is being done about it.

Re: Struct toString works but not std.conv.to!string

[Ali Çehreli via Digitalmars-d-learn]

On 10/13/2015 02:07 PM, Nordlöw wrote:

I have defined a struct UTCOffset in

https://github.com/nordlow/justd/blob/master/datetime_ex.d

Everything works as desired except for

 import std.conv : to;
 assert(UTCOffset(+14, 0).to!string == "UTC+14:00");

which fails as

/usr/include/dmd/phobos/std/conv.d(293,14): Error: template instance
isRawStaticArray!() does not match template declaration
isRawStaticArray(T, A...)
datetime_ex.d(129,29): Error: cannot resolve type for
UTCOffset(cast(ubyte)0u).this(cast(byte)14, cast(ubyte)0u).to!string

I don't understand what's wrong.


Reduced with a workaround:

struct UTCOffset
{
import std.conv : to;// Move to module scope to compile

string toString() const
{
return "hello";
}
}

void main() {
import std.conv : to;
UTCOffset().to!string;
}

This is an issue that I know to be known. :) I think it is about private 
definitions (isRawStaticArray) of modules not working outside? or when 
in inner scopes? Something like that...


Ali

[Issue 15201] New: Segfault __memcpy_sse2_unaligned on Throwable.toString()

[via Digitalmars-d-bugs]

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

  Issue ID: 15201
   Summary: Segfault __memcpy_sse2_unaligned on
Throwable.toString()
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: lluce...@gmail.com

I receive a segfault in my program when I am trying to print out information on
Throwable instance in a catch block.

The GDB backtrace:

Program received signal SIGSEGV, Segmentation fault.
__memcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:35
35../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: Adresár alebo súbor
neexistuje.
(gdb) bt full
#0  __memcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:35
No locals.
#1  0x00c2880f in _d_arraysetlengthiT ()
No symbol table info available.
#2  0x00c70cf9 in
core.demangle.Demangle.__T10doDemangleS48_D4core8demangle8Demangle16parseMangledNameMFmZvZ.doDemangle()
()
No symbol table info available.
#3  0x00c1fbb0 in core.runtime.defaultTraceHandler() ()
No symbol table info available.
#4  0x00c1f94b in core.runtime.defaultTraceHandler() ()
No symbol table info available.
#5  0x00c1f85c in core.runtime.defaultTraceHandler() ()
No symbol table info available.
#6  0x00c1e403 in object.Throwable.toString() ()
No symbol table info available.
#7  0x00c1e298 in object.Throwable.toString() ()
No symbol table info available.
#8  0x00a5d483 in les.ast.CommandCall.eval() (this=0x73734330) at
src/les/ast.d:988
No locals.
...

The code 'src/les/ast.d' where the exception is caught and printed is (line
988, code 't.toString()') here:

981try {
982return runBuiltInCommand(execEnv, dCode, parameterTree);
983}
984catch (Throwable t) {
985execEnv.context.callLocation.srcCode = STRING_EMPTY;
986debug (echoToConsole) logError("EXCEPTION %s THROWN in BIC %s in
method: %s\n%s",
987  t.classinfo.name, bicName[getBicNamePrefix().length+1..$],
988 >>>  execEnv.context, t.toString().indent().chomp());
989execEnv.requestLog.logError("EXCEPTION %s THROWN in BIC %s in
method: %s\n%s",
990  t.classinfo.name, bicName[getBicNamePrefix().length+1..$],
991  execEnv.context.toString!true(), t.toString().indent().chomp());
992}

-
The system is Debian Wheezy, 64bit.
ldd (Debian GLIBC 2.19-18) 2.19
DMD64 v2.068.2

What more information is needed?

--

Re: Struct toString works but not std.conv.to!string

[anonymous via Digitalmars-d-learn]

On Tuesday, 13 October 2015 at 22:21:43 UTC, Ali Çehreli wrote:

Reduced with a workaround:

struct UTCOffset
{
import std.conv : to;// Move to module scope to compile


This introduces UTCOffset.to as an alias to std.conv.to.


string toString() const
{
return "hello";
}
}

void main() {
import std.conv : to;


This ends up being ignored, because UTCOffset has a member called 
`to`.



UTCOffset().to!string;


This does not do call std.conv.to through UFCS. Instead, it calls 
UTCOffset's static alias of std.conv.to without an argument.


That is: `UTCOffset().to!string;` = `UTCOffset.to!string;` = 
`std.conv.to!string;`



}

Re: Struct toString works but not std.conv.to!string

[Nordlöw via Digitalmars-d-learn]

On Tuesday, 13 October 2015 at 21:50:54 UTC, Jonathan M Davis 
wrote:
Just glancing at your code, you've marked toString with 
@property, which is kind of a weird thing to do, nd if we ever 
make @property enforce that it's not called with parens, then 
that code won't work. So, you might try moving that @property: 
to after toString and see if that fixes your problem. But given 
the error, my guess is that the problem relates to the fact 
that you templatized the constructor, which is often 
problematic, and whatever type introspection std.conv.to is 
doing could be choking on that. So, you should probably try 
making it so that the constructor isn't templatized and see if 
that fixes the problem.


- Jonathan M Davis


None of you advice helped.

Fortunately I found a solution:

If I move

import std.conv : to;

into the function scopes

the problem goes away.

Thanks, anyway, for you time.

Re: DIP74 - where is at?

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 13 October 2015 at 22:20:02 UTC, Jonathan M Davis 
wrote:
Maybe, but at this point, I think that C++ is actually getting 
features faster than D is.


And as a result advanced c++ analyzers work on lowlevel IR, not 
at the language level.


That has many consequences, one is time consumption, another is 
accuracy.


We talk about adding features or tweaking existing features to 
fix problems, but we're long past the point where we're 
frequently adding features.


More syntax sugar is not problematic. It is what you have left 
when you factor out everything that is expressible by other 
mechanisms that matters.

OT: why do people use python when it is slow?

[Laeeth Isharc via Digitalmars-d-learn]

https://www.quora.com/Why-is-Python-so-popular-despite-being-so-slow
Andrei suggested posting more widely.

Re: DIP74 - where is at?

[deadalnix via Digitalmars-d]

On Tuesday, 13 October 2015 at 22:21:24 UTC, Ice Cream Desserter 
wrote:
On Tuesday, 13 October 2015 at 22:20:02 UTC, Jonathan M Davis 
wrote:
On Tuesday, 13 October 2015 at 22:10:30 UTC, Ice Cream Madness 
wrote:

The D language, does have a 'feature' creep problem.


Maybe, but at this point, I think that C++ is actually getting 
features faster than D is. We talk about adding features or 
tweaking existing features to fix problems, but we're long 
past the point where we're frequently adding features. If 
anything, the typical complaint now is that we're _not_ making 
changes, even when we've been discussing them (e.g. this very 
thread was started to ask what the deal with a proposed change 
is, because it hasn't gone anywhere yet, and it's a change 
proposed by Walter and Andrei no less).


- Jonathan M Davis


C++ also has a 'feature' creep problem.


If I may the problem is not that much how feature rich the 
language is, but how orthogonal these feature are. The less 
orthogonal they are, the more special cases you get when they 
interact with each other.