Re: LDC 1.0.0 has been released!

[Kai Nacke via Digitalmars-d-announce]

On Monday, 13 June 2016 at 12:35:57 UTC, Gerald wrote:
Awesome news, just noticed a blurb on the Linux news site 
Phoronix about this as well:


http://www.phoronix.com/scan.php?page=news_item=LDC-1.0-Released


Yes, we are in the press. :-)

http://llvmweekly.org/issue/128

Regards,
Kai

Re: Bug in Rdmd?

[Jonathan Marler via Digitalmars-d-learn]

On Tuesday, 14 June 2016 at 03:40:01 UTC, Adam D. Ruppe wrote:

On Tuesday, 14 June 2016 at 03:15:04 UTC, Jonathan Marler wrote:

It actually is a free function


no, it isn't, it is on File.

Your code doesn't compile on my dmd (and indeed it shouldn't on 
yours either unless you have a version mismatch. rdmd just 
calls dmd, it doesn't produce its own errors)


Shoot stupid mistake.  You were right Jeremy and Adam.  Thanks 
for replying and showing me my silly error.  I could have sworn 
byLine was a template and calling it with file was just 
UFCS...and I don't know how I was able to compile that with 
DMD...must have made a mistake somewhere.  Thanks again.

Re: I'd love to see DScript one day ...

[dewitt via Digitalmars-d]

On Tuesday, 14 June 2016 at 03:31:10 UTC, H. S. Teoh wrote:
On Tue, Jun 14, 2016 at 01:36:48AM +, Yuxuan Shui via 
Digitalmars-d wrote:

On Tuesday, 14 June 2016 at 00:55:52 UTC, Walter Bright wrote:
> On 6/13/2016 5:13 PM, H. S. Teoh via Digitalmars-d wrote:
> > My *real* dream is for D (or some suitable subset thereof) 
> > to replace Javascript in browsers.  But that's a very 
> > distant, if at all even possible, dream. :-D
> 
> It's a great dream!


Don't we have a pretty efficient JIT javascript implementation 
in D already?


https://github.com/higgsjs/Higgs


I know that. What I meant was that instead of writing 
javascript we'd write D instead, in our webpages. Or at least, 
some subset of D that's safe for the web. I.e., instead of:




...

you'd write



...

It's unlikely to happen in the near future, though, if at all. 
But one can dream.  :-)



T


I know its a dream but really whats wrong with JS in the browser? 
 Now with no need for JQuery and ES6 its not really that bad.  
Better to use it for a scripting lang and other things.  My 
opinion only..  If were dreamin Id rather see the next Kafka or 
Elasticsearch big idea written in D...

Re: Bug in Rdmd?

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

On Tuesday, 14 June 2016 at 03:15:04 UTC, Jonathan Marler wrote:

It actually is a free function


no, it isn't, it is on File.

Your code doesn't compile on my dmd (and indeed it shouldn't on 
yours either unless you have a version mismatch. rdmd just calls 
dmd, it doesn't produce its own errors)

Re: I'd love to see DScript one day ...

[H. S. Teoh via Digitalmars-d]

On Tue, Jun 14, 2016 at 01:36:48AM +, Yuxuan Shui via Digitalmars-d wrote:
> On Tuesday, 14 June 2016 at 00:55:52 UTC, Walter Bright wrote:
> > On 6/13/2016 5:13 PM, H. S. Teoh via Digitalmars-d wrote:
> > > My *real* dream is for D (or some suitable subset thereof) to
> > > replace Javascript in browsers.  But that's a very distant, if at
> > > all even possible, dream. :-D
> > 
> > It's a great dream!
> 
> Don't we have a pretty efficient JIT javascript implementation in D
> already?
> 
> https://github.com/higgsjs/Higgs

I know that. What I meant was that instead of writing javascript we'd
write D instead, in our webpages. Or at least, some subset of D that's
safe for the web. I.e., instead of:



...

you'd write



...

It's unlikely to happen in the near future, though, if at all. But one
can dream.  :-)


T

-- 
Computers shouldn't beep through the keyhole.

Re: Bug in Rdmd?

[Jonathan Marler via Digitalmars-d-learn]

On Tuesday, 14 June 2016 at 01:35:32 UTC, Jeremy DeHaan wrote:

On Tuesday, 14 June 2016 at 01:05:46 UTC, Jonathan Marler wrote:

This code doesn't seem to work with rdmd.  Is this a bug?

  import std.stdio : byLine;
  int main(string[] args)
  {
foreach(line; stdin.byLine) {
}
return 0;
  }

Compiler Output:
  Error: module std.stdio import 'byLine' not found


Try removing the 'byLine' from the import statement. The error 
message looks like it can't find the function 'byLine' in the 
std.stdio module. It isn't a free function, but one of File's 
methods.


It actually is a free function (not a method on the File object). 
 This works if you compile it with dmd, just not with rdmd.

[Issue 15498] Unhelpful error message "destructors, postblits and invariants are not allowed in overlapping fields"

[via Digitalmars-d-bugs]

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

joeyemm...@yahoo.com changed:

   What|Removed |Added

 CC||joeyemm...@yahoo.com

--- Comment #8 from joeyemm...@yahoo.com ---
I am getting this too, definitely don't have any unions. My issue seems to be
caused by some kind of import ordering problem, reordering some of my imports
makes it go away. Making a minimized reproduction might be hard.

--

Re: Fixed date to move to ddox for Phobos documentation

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 14 June 2016 at 01:42:26 UTC, Vladimir Panteleev 
wrote:
Correct me if I'm wrong but the above consideration excludes 
the people who are capable of answering questions.


Yeah, I'm not likely to ever use disqus but if it went through 
the same n.g./mailing list interface at least I'd consider 
talking at times (though I personally think comments in 
documentation should typically be used to just go back and 
improve the documentation rather than making readers actually 
wade through the out-of-date and repetitive comment thread...)

Re: Fixed date to move to ddox for Phobos documentation

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 14 June 2016 at 00:27:21 UTC, Andrei Alexandrescu 
wrote:
How would we estimate the intersection between folks who do 
want to ask a question, and folks who are ideologically opposed 
to signing up with disqus? Also, we need to be careful about 
the influence of our personal beliefs on the core contributors 
and the community. -- Andrei


Correct me if I'm wrong but the above consideration excludes the 
people who are capable of answering questions.

Re: Fixed date to move to ddox for Phobos documentation

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 14 June 2016 at 00:31:56 UTC, Andrei Alexandrescu 
wrote:
Walter or Jan should be able to do that. But I'm confused as to 
how NNTP groups would help here.


It would allow people to subscribe and reply to comments using 
their newsreader (or by email, if it's also associated with a 
mailing list on Brad's server). It's one of the bigger reasons to 
consider using DFeed.

Re: I'd love to see DScript one day ...

[Yuxuan Shui via Digitalmars-d]

On Tuesday, 14 June 2016 at 00:55:52 UTC, Walter Bright wrote:

On 6/13/2016 5:13 PM, H. S. Teoh via Digitalmars-d wrote:
My *real* dream is for D (or some suitable subset thereof) to 
replace
Javascript in browsers.  But that's a very distant, if at all 
even

possible, dream. :-D


It's a great dream!


Don't we have a pretty efficient JIT javascript implementation in 
D already?


https://github.com/higgsjs/Higgs

Bug in Rdmd?

[Jonathan Marler via Digitalmars-d-learn]

This code doesn't seem to work with rdmd.  Is this a bug?

  import std.stdio : byLine;
  int main(string[] args)
  {
foreach(line; stdin.byLine) {
}
return 0;
  }

Compiler Output:
  Error: module std.stdio import 'byLine' not found

Re: I'd love to see DScript one day ...

[Walter Bright via Digitalmars-d]

On 6/13/2016 5:13 PM, H. S. Teoh via Digitalmars-d wrote:

My *real* dream is for D (or some suitable subset thereof) to replace
Javascript in browsers.  But that's a very distant, if at all even
possible, dream. :-D


It's a great dream!

Re: Fixed date to move to ddox for Phobos documentation

[Andrei Alexandrescu via Digitalmars-d]

On 06/11/2016 03:28 PM, Vladimir Panteleev wrote:

On Saturday, 11 June 2016 at 19:20:56 UTC, Andrei Alexandrescu wrote:

On 6/11/16 12:31 PM, Jonathan M Davis via Digitalmars-d wrote:

Are_you_  going to spend time going through every single page in the
documentation, looking to see whether someone asked a question and then
reply to them if they did?


I get notified by disqus for new posts. The basic idea is if we don't
prime it we'll never have it. -- Andrei


I think it wouldn't be too hard to embed DFeed as a comment system. What
do you think? Then anyone can subscribe to new comments through the
usual means. The same solution can be applied to the blog.


I'm thinking the line between good dogfooding and NIH is thin. The real 
questions we should be asking ourselves is how well does disqus serve 
our purpose, how good a future it has, and how many folks see it as an 
unpleasant association. Also, how long it would take to adapt DFeed and 
what advantages/liabilities it has.



I understand that the current bottleneck is someone adding new groups to
the NNTP server. Can that be resolved?


Walter or Jan should be able to do that. But I'm confused as to how NNTP 
groups would help here.



Andrei

Re: Fixed date to move to ddox for Phobos documentation

[Andrei Alexandrescu via Digitalmars-d]

On 06/11/2016 09:02 AM, Martin Nowak wrote:

On 06/10/2016 07:33 PM, Andrei Alexandrescu wrote:

I'm a bit bummed about that. I like it. Is my understanding incorrect
that disqus is fairly established by now?


You need to create an account with a pay-by-data company to even post
something.


How would we estimate the intersection between folks who do want to ask 
a question, and folks who are ideologically opposed to signing up with 
disqus? Also, we need to be careful about the influence of our personal 
beliefs on the core contributors and the community. -- Andrei

Re: I'd love to see DScript one day ...

[H. S. Teoh via Digitalmars-d]

On Mon, Jun 13, 2016 at 04:47:40PM -0700, Walter Bright via Digitalmars-d wrote:
> On 6/13/2016 2:13 PM, ketmar wrote:
> > it heavily depends of what exactly one want and how. by the time
> > i'll fully understand DMDScript code, i'd complete my own
> > implementation of dynamic scripting language with JIT.
> 
> Remember you also have to write the documentation for your own
> language, and write your own test suite. With Javascript you can rely
> on existing documentation and test suites, which are enormous time
> savers.

My *real* dream is for D (or some suitable subset thereof) to replace
Javascript in browsers.  But that's a very distant, if at all even
possible, dream. :-D


T

-- 
I am not young enough to know everything. -- Oscar Wilde

Re: Transient ranges

[Andrei Alexandrescu via Digitalmars-d]

On 06/12/2016 04:46 AM, Dicebot wrote:

That is matter of design philosophy. For me such basic library
primitives warrant C++ attitude of "don't pay for what you don't ask
for" - and everything else, including actual feature completeness, is of
negligible importance compared to that.


C++'s input iterator model also predicates multiple accesses to the 
current value by means of *it.



If keeping random access for map requires either caching or multiple
evaluations of predicate, I want it to be banned by default and
enabled explicitly (not sure what could be good API for that though).


In the initial implementation, map did cache the current element. That 
made some folks unhappy, so it was removed. In lieu, a function "cache" 
was introduced. Apparently this setup makes other folks unhappy.


It seems to me, sometimes if I went by what this forum agrees upon I'd 
write one thousand lines of code one day and remove it the next.



Phobos indeed doesn't seem to make such priorities right now and that is
one of reasons I am growing increasingly unhappy with it.


What steps do you think we could take with Phobos to make it better 
without breaking backward compatibility?



Andrei

Re: Work in Amsterdam

[Ali Çehreli via Digitalmars-d-announce]

On 06/13/2016 04:48 PM, Walter Bright wrote:

On 6/13/2016 4:00 PM, Ali Çehreli wrote:

On 06/13/2016 03:45 PM, Márcio Martins wrote:

Forgive me if this is not the best place for this sort of posts, but we
are looking for experienced developers willing to learn D to join our
development team in Amsterdam. We are a fast-growing travel e-commerce
startup focused on themed vacation packages.

You'll be part of our small and agile development team, working with
D/vibe.d on a daily basis, with the occasional javascript for the
client-side of things.

Learn more on https://www.linkedin.com/jobs2/view/140710158


Just a reminder to everybody else that we have the following page:

  http://dlang.org/orgs-using-d.html

(Tripaneer is already there with a "Hiring" link.)

Ali



An announcement here is still ok, with a followup to that page.


Of course! I didn't mean otherwise. Just making that relatively-recent 
page known by more people. :)


Ali

Re: I'd love to see DScript one day ...

[Walter Bright via Digitalmars-d]

On 6/13/2016 2:13 PM, ketmar wrote:

it heavily depends of what exactly one want and how. by the time i'll fully
understand DMDScript code, i'd complete my own implementation of dynamic
scripting language with JIT.


Remember you also have to write the documentation for your own language, and 
write your own test suite. With Javascript you can rely on existing 
documentation and test suites, which are enormous time savers.

Re: Work in Amsterdam

[Walter Bright via Digitalmars-d-announce]

On 6/13/2016 4:00 PM, Ali Çehreli wrote:

On 06/13/2016 03:45 PM, Márcio Martins wrote:

Forgive me if this is not the best place for this sort of posts, but we
are looking for experienced developers willing to learn D to join our
development team in Amsterdam. We are a fast-growing travel e-commerce
startup focused on themed vacation packages.

You'll be part of our small and agile development team, working with
D/vibe.d on a daily basis, with the occasional javascript for the
client-side of things.

Learn more on https://www.linkedin.com/jobs2/view/140710158


Just a reminder to everybody else that we have the following page:

  http://dlang.org/orgs-using-d.html

(Tripaneer is already there with a "Hiring" link.)

Ali



An announcement here is still ok, with a followup to that page.

[Issue 16169] nWayUnion assertion failure

[via Digitalmars-d-bugs]

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

--- Comment #1 from Justin Whear  ---
The suggested fix in my previous comment actually just hides the issue in some
situations.  Changing one of the `iota(1,3)` lines in the test cases causes a
popFront on an empty iota range.

--

Re: Work in Amsterdam

[Ali Çehreli via Digitalmars-d-announce]

On 06/13/2016 03:45 PM, Márcio Martins wrote:

Forgive me if this is not the best place for this sort of posts, but we
are looking for experienced developers willing to learn D to join our
development team in Amsterdam. We are a fast-growing travel e-commerce
startup focused on themed vacation packages.

You'll be part of our small and agile development team, working with
D/vibe.d on a daily basis, with the occasional javascript for the
client-side of things.

Learn more on https://www.linkedin.com/jobs2/view/140710158


Just a reminder to everybody else that we have the following page:

  http://dlang.org/orgs-using-d.html

(Tripaneer is already there with a "Hiring" link.)

Ali

Work in Amsterdam

[Márcio Martins via Digitalmars-d-announce]

Forgive me if this is not the best place for this sort of posts, 
but we are looking for experienced developers willing to learn D 
to join our development team in Amsterdam. We are a fast-growing 
travel e-commerce startup focused on themed vacation packages.


You'll be part of our small and agile development team, working 
with D/vibe.d on a daily basis, with the occasional javascript 
for the client-side of things.


Learn more on https://www.linkedin.com/jobs2/view/140710158

nested inout return type

[Simon Bürger via Digitalmars-d-learn]

I'm writing a custom (originally multi-dimensional) Slice-type, 
analogous to the builtin T[], and stumbled upon the problem that 
the following code won't compile. The workaround is simple: just 
write the function three times for mutable/const/immutable. But 
as "inout" was invented to make that unneccessary I was wondering 
if there is a clever way to make this work.



struct Slice(T)
{
T* ptr;
size_t length;

Slice!(inout(T)) opSlice(size_t a, size_t b) inout
{
return Slice!(inout(T))(ptr+a, b-a);
}
}

how to get rid of "cannot deduce function from argument types" elegantly

[Christian Köstlin via Digitalmars-d-learn]

I made a small (could be reduced further) example that creates and walks
a templated binary tree. The tree also gets a factory function to use
type deduction to conveniently construct a tree. Unfortunately this does
not compile, if I remove the three ugly methods between /* these should
go */ comments.

```
fibertest.d(49): Error: template fibertest.tree cannot deduce function
from argument types !()(int, typeof(null), typeof(null)), candidates are:
fibertest.d(41):fibertest.tree(T)(T node, Tree!T left, Tree!T right)
```

Is there a more elegant way to fix this?

Another fix would be to provide 4 factory functions like this (still not
really nice):
```
tree(Tree!T left, T node, Tree!T right) {...}
tree(T node, Tree!T right) {...}
tree(Tree!T left, T node) {...}
tree(T node) {...}
```

```d
import std.concurrency, std.stdio, std.range;

class Tree(T) {
  Tree!T left;
  T node;
  Tree!T right;

  this(Tree!T left, T node, Tree!T right) {
this.left = left;
this.node = node;
this.right = right;
  }

  auto inorder() {
return new Generator!T(() => yieldAll(this));
  }

  private void yieldAll(Tree!T t) {
if (t is null) return;

yieldAll(t.left);
yield(t.node);
yieldAll(t.right);
  }
}

/* these should go */

Tree!T tree(T)(typeof(null) left, T node, typeof(null) right) {
  return new Tree!T(null, node, null);
}
Tree!T tree(T)(Tree!T left, T node, typeof(null) right) {
  return new Tree!T(left, node, null);
}
Tree!T tree(T)(typeof(null) left, T node, Tree!T right) {
  return new Tree!T(null, node, right);
}

/* these should go */

Tree!T tree(T)(Tree!T left, T node, Tree!T right) {
  return new Tree!T(left, node, right);
}

void main(string[] args) {
  // /3
  //   /2
  //  1
  auto t1 = tree(tree(tree(null, 1, null), 2, null), 3, null);
  // 1
  //  \2
  //\3
  auto t2 = tree(null, 1, tree(null, 2, tree(null, 3, null)));
  writeln(t1.inorder());
  writeln(t2.inorder());
  writeln(t1.inorder().array == t2.inorder().array);
}
```

Re: Gotchas for returning values from blocks

[Era Scarecrow via Digitalmars-d-learn]

On Monday, 13 June 2016 at 14:16:58 UTC, jmh530 wrote:
So returning a reference to something on the stack is a bad 
idea, but copying the value would be fine.


 This is easy enough to get wrong elsewhere too. I recall having 
an issue with a foreach, until I added a 'ref' to it. Looking at 
the addresses all pointing to the same spot (the temporary) which 
can add curiously subtle bugs, or blatantly obvious ones.

Re: D grammar

[Brian Schott via Digitalmars-d]

On Sunday, 12 June 2016 at 06:45:58 UTC, Russel Winder wrote:

I should know this, but…

Is there an official D grammar (EBNF or otherwise) or is the 
language

defined by the DMD parser?

I am looking to continue Kingsley's DLanguage IntelliJ IDEA 
plugin and for that it is necessary to have a grammar 
specification. Kingsley has been working on one, but there may 
be differences between it and 2.071. Given the compilers and 
all the supporting tools either there is one language 
specification they all work with or there is a lot of 
fragmented viewpoints as to what D actually is. I am hoping the 
latter is not the case.


If you attempt to give the language specification to a parser 
generator like ANTLR you will quickly discover that the spec is 
reverse-engineered from the implementation, and that the spec is 
ambiguous in many places. The spec, being derived from the 
implementation is not really aware of the existence of the 
ambiguities, and doesn't say how to resolve them.

Re: Interest in Paris area D meetups?

[Guillaume Chatelet via Digitalmars-d]

On Thursday, 9 June 2016 at 09:11:05 UTC, Guillaume Chatelet 
wrote:

On Wednesday, 8 June 2016 at 16:40:53 UTC, Claude wrote:
On Wednesday, 1 June 2016 at 20:33:40 UTC, Guillaume Chatelet 
wrote:

On Wednesday, 1 June 2016 at 19:25:13 UTC, Claude wrote:

[...]


Two sounds like a good start ^__^
We can start with a beer somewhere :)


Yeah great! I'm up for a beer.
I work near Gare de l'Est. We can have a drink after work-time 
(I'm available around 19h), and share about what we think 
about that evil auto-decode.

Is it ok for you ?


Sounds good to me.
How about next Wednesday (15th) at "Bière et Malt" (4 rue 
Poissonnière

in the 2nd district) at say 19:00?


In case someone else wants to join. This has been postponed to 
next week. Wednesday 22nd same place, same time.

Re: Parse File at compile time, but not embedded

[ketmar via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 01:39:11 UTC, Joerg Joergonson wrote:
This doesn't seem to be the case though in more complex 
examples ;/


it is.


My code is almost identical do what you have written


your code is *completely* different. that's why there are no 
traces of CTFE values in my sample. it's not that hard to find 
out that my code has no functions at all, so no code for 'em can 
be generated.

[Issue 15704] @safe code should not allow copying of void[]

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||ntrel-...@mybtinternet.com

--- Comment #1 from Nick Treleaven  ---
Shouldn't we just disallow all writes to a void[] in safe code?

--

Re: I'd love to see DScript one day ...

[ketmar via Digitalmars-d]

On Monday, 13 June 2016 at 20:19:37 UTC, Walter Bright wrote:
Regardless, you're way ahead with DMDScript than starting from 
scratch.


it heavily depends of what exactly one want and how. by the time 
i'll fully understand DMDScript code, i'd complete my own 
implementation of dynamic scripting language with JIT.

[Issue 12822] Delegate .ptr assignment considered @safe

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/73301fec8727569aedd6f9f94a2217a38a525d24
Actually test compiler output for issue 12822

This is a fix-up for pull #5851.

https://github.com/dlang/dmd/commit/f7d88d54d8f499ed05a9ecd3b28c819c8ecdf8bb
Merge pull request #5865 from denis-sh/patch-2

Actually test compiler output for issue 12822

--

Re: The Problem With DIPs

[Walter Bright via Digitalmars-d]

On 6/13/2016 3:33 AM, Ola Fosheim Grøstad wrote:

But would it really have an effect if I wrote a DIP on getting predictable
floating point behaviour? If there is a chance that it would, then I might
consider it :-).


I encourage you to consider it.

Re: What's up with GDC?

[Joerg Joergonson via Digitalmars-d-learn]

On Monday, 13 June 2016 at 16:46:38 UTC, Adam D. Ruppe wrote:

On Sunday, 12 June 2016 at 14:22:54 UTC, Joerg Joergonson wrote:
Error: undefined identifier 'Sleep' in module 'core.thread', 
did you mean function 'Sleep'?


It is supposed to be `Thread.sleep(1.seconds);`

I'm pretty sure the capital Sleep() is supposed to be private 
(that is the OS-specific Windows api call).




Ok, I tried both and Sleep was the one that worked for some odd 
ball reason.  Then it seemed to stop working I think(I tried it 
in a different spot)... maybe user error.


Basically keeping the event loop uses around 12% cpu and 12MB 
of memory.


That's weird, it just sleeps until a message comes in from the 
OS. On my computer, programs sit at 0% like you'd expect, and 
my guitest program (which has text areas, buttons, menu, etc) 
eats ~1.7 MB, both 32 and 64 bit versions.


Are you running some other program that might be sending a lot 
of broadcast messages?




Not that I know of. I haven't tried running it outside VS though 
so it might be doing something weird. I'll investigate further 
when I get a chance and get further down the road.


About the WM size thing, I haven't had a problem with it except 
for the weird vertical shifting. It doesn't use any more cpu when 
constantly resizing.

Re: Version identifier for PS4

[Walter Bright via Digitalmars-d]

On 6/13/2016 12:56 PM, Jonathan M Davis via Digitalmars-d wrote:

I wouldn't have expected any doubt about what PS4 meant. What else would it
mean other than Playstation 4?


The TLA space is pretty limited.


I would have thought that that would be
obvious, and Playstation4 would be overly verbose in comparison (not to
mention, it stands feeling weird without a space when it's all spelled out
like that).


It's not like anyone is going to run out of disk/memory space having 
"PlayStation4" strings in it. :-)


My general stylistic opinion is that global names should be a bit verbose, and 
local names should be short. (Yes, you can find counterexamples in the code I've 
written.) Instead of having a naming convention grammar for globals vs locals, I 
find the length to be quite effective.

Re: I'd love to see DScript one day ...

[Walter Bright via Digitalmars-d]

On 6/13/2016 2:21 AM, Chris wrote:

Seems like it's a dead race. DMDScript has been in the attic for too long.
Trying to play catch up with Google, an Internet company, seems hardly worth the
effort.


For making your own browser, probably right. For adding scripting support to an 
IDE, anything with plugins, etc., it's quite good for the job.


Regardless, you're way ahead with DMDScript than starting from scratch.

Re: Automatic linking of PR and bugzilla issue?

[Walter Bright via Digitalmars-d]

On 6/13/2016 4:29 AM, Jacob Carlborg wrote:

On 2016-06-13 10:33, Walter Bright wrote:


No, have to do that manually.


I'm pretty sure I've seen something that looks automated. Could that be for when
a PR is merged?


When it's merged, it auto-resolves the issue and posts the commit message.

Re: Button: A fast, correct, and elegantly simple build system.

[Walter Bright via Digitalmars-d-announce]

On 6/12/2016 4:27 PM, Jason White wrote:

I don't understand this dependency-phobia.


It's the "first 5 minutes" thing. Every hiccup there costs us maybe half the 
people who just want to try it out.


Even the makefiles have hiccups. I've had builds fail with the dmd system 
because I had the wrong version of make installed. And it doesn't fail with "you 
have the wrong make program installed" messages, it fails with some weird error 
message pointing into the middle of the makefile.


The makefiles, especially posix.mak, have grown into horrific snarls of 
who-knows-what-is-happening. I hate makefiles that call other makefiles. 
Sometimes I feel like chucking them all and replacing them with a batch file 
that is nothing more than an explicit list of commands:


dmd -c file1.d
dmd -c file2.d

etc. :-)

Re: Access private member

[Jacob Carlborg via Digitalmars-d-learn]

On 2016-06-13 17:00, Basile B. wrote:


Unless It's you Jacob who have proposed Orange to phobos in 2012. And
then since refused it's not developed at all. IIRC it's even not
possible to compile it with DUB.


Yes, I've written Orange and proposed it to Phobos. Not sure what you 
mean with "refused" and "not developed".


Orange is a part of Mambo [1] which is avilable using Dub [2].

[1] https://github.com/jacob-carlborg/mambo/tree/master/mambo/serialization

[2] http://code.dlang.org/packages/mambo

--
/Jacob Carlborg

Re: Version identifier for PS4

[Jonathan M Davis via Digitalmars-d]

On Saturday, June 11, 2016 23:29:08 Walter Bright via Digitalmars-d wrote:
> On 6/9/2016 5:30 AM, Johan Engelen wrote:
> > Hi all,
> >
> >   PR 5850 is proposing to add a predefined (reserved) version identifier
> >   for the>
> > PS4 OS: "PS4" [1].
> > Thanks for your comment (preferably with an alternative suggestion in case
> > you don't like "PS4").
> >
> > Thanks,
> >
> >   Johan
> >
> > [1] https://github.com/dlang/dmd/pull/5850
>
> As others suggested, me kinda prefer "PlayStation4" as there's little doubt
> what that refers to.

I wouldn't have expected any doubt about what PS4 meant. What else would it
mean other than Playstation 4? I would have thought that that would be
obvious, and Playstation4 would be overly verbose in comparison (not to
mention, it stands feeling weird without a space when it's all spelled out
like that). But I won't be writing any code involving any gaming consoles,
so I don't exactly have much of a horse in this race.

- Jonathan M Davis

Re: Accessing COM Objects

[Incognito via Digitalmars-d-learn]

On Monday, 13 June 2016 at 19:11:59 UTC, John wrote:

On Monday, 13 June 2016 at 17:38:41 UTC, Incognito wrote:
Cool. Oleview gives me the idl files. How to convert the idl 
files to d or possibly c?


Would I just use them in place of IUnknown once I have the 
interface?


In OleView you can save the IDL file, then run another tool, 
midl.exe, on the IDL file. That will generate the C headers. 
But you'd then have to translate that to D by hand.


I have written a tool that takes a COM type library and 
automatically converts it to a D source file. I could finish it 
off over the next few days and put the source on GitHub if 
you're interested.


That would be great! With it I might be able to put a nice 
wrapper around Photoshop for use with D. Others mind find it 
useful too as other programs still use COM.

Re: Recursion Idea for functions

[Steven Schveighoffer via Digitalmars-d]

On 6/13/16 3:21 PM, Incognito wrote:

I've been using recursion a lot lately and having to create multiple
functions to deal with multiple paths can be a pain visually.

Instead, how bout a simpler syntax. This is just an idea, could be improved

void Recurse()
{
scope(first)
{
 `BLOCK`
}
scope(last)
{
 `BLOCK`
}

Recurse();
}

which would be equivalent to

void Recurse2()
{
Recurse2();
}

void Recurse()
{
`BLOCK`
Recurse2();
`BLOCK`
}

doubling of functions starts to create a source mess.



Why not just:

void Recurse()
{
   static void Recurse2()
   {
  Recurse2();
   }

   `BLOCK`
   Recurse2()
   `BLOCK`
}

-Steve

Recursion Idea for functions

[Incognito via Digitalmars-d]

I've been using recursion a lot lately and having to create 
multiple functions to deal with multiple paths can be a pain 
visually.


Instead, how bout a simpler syntax. This is just an idea, could 
be improved


void Recurse()
{
scope(first)
{
 `BLOCK`
}
scope(last)
{
 `BLOCK`
}

Recurse();
}

which would be equivalent to

void Recurse2()
{
Recurse2();
}

void Recurse()
{
`BLOCK`
Recurse2();
`BLOCK`
}

doubling of functions starts to create a source mess.

Re: Accessing COM Objects

[John via Digitalmars-d-learn]

On Monday, 13 June 2016 at 17:38:41 UTC, Incognito wrote:
Cool. Oleview gives me the idl files. How to convert the idl 
files to d or possibly c?


Would I just use them in place of IUnknown once I have the 
interface?


In OleView you can save the IDL file, then run another tool, 
midl.exe, on the IDL file. That will generate the C headers. But 
you'd then have to translate that to D by hand.


I have written a tool that takes a COM type library and 
automatically converts it to a D source file. I could finish it 
off over the next few days and put the source on GitHub if you're 
interested.

Re: Garbage Collection, Untraceable Errors...

[Vladimir Panteleev via Digitalmars-d]

On Monday, 13 June 2016 at 16:43:57 UTC, cy wrote:
On Monday, 13 June 2016 at 08:58:40 UTC, Vladimir Panteleev 
wrote:


FWIW: http://wiki.dlang.org/InvalidMemoryOperationError


Yeah... I did forget that the GC was not re-entrant. But the 
"stop collecting inside the destructor, moron" error is exactly 
the same as "something allocated in the destructor... moron" 
error.


"The GC is not re-entrant" applies to all of its parts, not only 
the actual part doing the GC and reclaiming memory - i.e. calling 
any GC function (allocation or an explicit free) while a GC 
function is running is not supported. In practice, this only 
applies to allocation/free from a destructor invoked by a GC 
sweep though.


I'd think we could just allocate space for a potential stack 
trace before starting garbage collection, but I guess not?


The problem is certainly solvable, but, well, a GC cycle is 
initiated precisely when the runtime runs out of memory.

Re: What's up with GDC?

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

On Saturday, 11 June 2016 at 04:20:38 UTC, Joerg Joergonson wrote:

BTW I make your code a bit better with resizing

case WM_SIZING:
goto size_changed;
break;


I left that out intentionally because it lagged on my computer... 
so I wanted it to stay blank.


Maybe it can be made more efficient though.

Re: Berlin D Meetup June 2016

[Stefan Koch via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 16:31:47 UTC, Ben Palmer wrote:

Hi All,

The June Berlin D Meetup will be happening at 20:00 (note new 
time) on Friday the 17th of June at Berlin Co-Op 
(http://co-up.de/) on the fifth floor.


Danny Arends will be giving a more detailed version of his 
lightning talk he gave at the D conference on his web server, 
"DaNode".


Both alcoholic and non-alcoholic drinks will be available.

More details and an abstract of the talk are available on the 
meetup page here: 
http://www.meetup.com/Berlin-D-Programmers/events/231746496/


Thanks,
Ben.


Will there be time for a quick discussion about auto-decode ?

[Issue 15900] [REG 2.071] (Import deprecation) Public import ignored when using fully qualified name

[via Digitalmars-d-bugs]

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

--- Comment #2 from Timothee Cour  ---
(In reply to Timothee Cour from comment #1)
> (In reply to Vladimir Panteleev from comment #0)
> > / test.d /
> > import std.datetime;
> > 
> > unittest
> > {
> > cast(void)core.time.hnsecs(1);
> > }
> > //
> > 
> > $ dmd -w -unittest -o- test.d 
> > test.d(5): Deprecation: module core.time is not accessible here, perhaps add
> > 'static import core.time;'
> > 
> > However, std.datetime publicly imports core.time, so the warning is
> > spurious. The code compiles fine when NOT using the fully-qualified name.
> 
> still there in 2.071.1 beta 2

this is also broken:

fun.d:
public import std.string
public static import std.string

main.d:
import fun;
void main(){
  auto a=std.string.isNumeric("12"); 
  // module std.string is not accessible here, perhaps add 'static import
std.string;'
}

--

[Issue 15900] [REG 2.071] (Import deprecation) Public import ignored when using fully qualified name

[via Digitalmars-d-bugs]

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com

--- Comment #1 from Timothee Cour  ---
(In reply to Vladimir Panteleev from comment #0)
> / test.d /
> import std.datetime;
> 
> unittest
> {
> cast(void)core.time.hnsecs(1);
> }
> //
> 
> $ dmd -w -unittest -o- test.d 
> test.d(5): Deprecation: module core.time is not accessible here, perhaps add
> 'static import core.time;'
> 
> However, std.datetime publicly imports core.time, so the warning is
> spurious. The code compiles fine when NOT using the fully-qualified name.

still there in 2.071.1 beta 2

--

Re: Announcing TinyRedis v2.1.0

[Adil Baig via Digitalmars-d-announce]

On Mon, Jun 13, 2016 at 2:50 PM, Martin Tschierschke via
Digitalmars-d-announce  wrote:

> On Saturday, 11 June 2016 at 18:44:43 UTC, Adil wrote:
>
>> It's been a while since i announced a TinyRedis release. So here goes.
>>
>> TinyRedis is a fast and simple Redis(http://redis.io) driver for D. It
>> has no dependencies and makes working with Redis trivial.
>>
> [...]
>
>> Download : https://github.com/adilbaig/Tiny-Redis/releases
>> GitHub : https://github.com/adilbaig/Tiny-Redis
>> Docs : http://adilbaig.github.io/Tiny-Redis/
>>
> Just a newbee question, is the Redis support included in Vibe.d a
> completely different thing or is there a cross-fertilisation of ideas?
>
>
They're both independent codebases.

Re: Recursive SymbolNames solved.

[Basile B. via Digitalmars-d-announce]

On Wednesday, 8 June 2016 at 20:15:57 UTC, FlatBareRunner wrote:

On Wednesday, 8 June 2016 at 19:41:49 UTC, deadalnix wrote:

On Wednesday, 8 June 2016 at 13:28:19 UTC, Stefan Koch wrote:

Hi, I solved the issue.
PR is coming shortly.


Dude come on, that isn't an announce. There is No PR, there is 
no description of the solution, there is nothing.


Hey guys, I cured cancer and solved world hunger. PR coming 
soon.


Lol ! My turn:

I'm a genious but I haven't done anything genial yet...


Writer here. Not yet published but working hard on the first 
one...

Re: Accessing COM Objects

[Incognito via Digitalmars-d-learn]

On Monday, 13 June 2016 at 07:40:09 UTC, John wrote:

On Monday, 13 June 2016 at 01:22:33 UTC, Incognito wrote:
I've been reading over D's com and can't find anything useful. 
It seems there are different ways:


http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf

which is of no help and requires an idl file, which I don't 
have.


Then theres this

http://wiki.dlang.org/COM_Programming

which is also of no help:

import std.stdio;

import std.stdio, core.sys.windows.com, 
core.sys.windows.windows, std.exception, std.meta, std.traits;
import std.utf, core.stdc.stdlib, core.sys.windows.objidl, 
core.sys.windows.ole2;

pragma(lib, "ole32.lib");


GUID Guid(string str)()
{
static assert(str.length==36, "Guid string must be 36 
chars long");
enum GUIDstring = "GUID(0x" ~ str[0..8] ~ ", 0x" ~ 
str[9..13] ~ ", 0x" ~ str[14..18] ~
", [0x" ~ str[19..21] ~ ", 0x" ~ str[21..23] ~ ", 0x" 
~ str[24..26] ~ ", 0x" ~ str[26..28]
~ ", 0x" ~ str[28..30] ~ ", 0x" ~ str[30..32] ~ ", 0x" 
~ str[32..34] ~ ", 0x" ~ str[34..36] ~ "])";

return mixin(GUIDstring);
}

int main(string[] argv)
{

	// Adobe Photoshop App 9.0 CLSID 
{c09f153e-dff7-4eff-a570-af82c1a5a2a8}
	// Adobe Photoshop App 9.1 CLSID 
{6DECC242-87EF-11cf-86B4-44455354}


	auto CLSID_DOMDocument60 = 
Guid!("6DECC242-87EF-11cf-86B4-44455354");

auto iid = IID_IUnknown;

void* pUnk;
	auto hr = CoCreateInstance(_DOMDocument60, null, 
CLSCTX_ALL, , );

if (FAILED(hr))
throw new Exception("Error!");

writeln("Hello D-World!");
return 0;
}

Maybe my CLSID's are wrong. Got them from the registry. The 
exception triggers each time. Even if it worked, I wouldn't 
know how to use it.


I can do this stuff in C# by simply dragging and dropping a 
dll into the references and it works fine but is a bit slow. I 
was hoping I could speed things up using D but it seems like 
COM isn't really supported, despite what several references 
say.


COM is supported in D. The difference is that C# hides all the 
plumbing behind nice classes.


You're going to need Photoshop's COM interface to do anything 
with it. If you don't have a C header that you can translate 
into D, you could use a tool included in the Windows SDK called 
OleView. It will peek inside COM  libraries and give you the 
interface definitions.


As to why CoCreateInstance isn't working, make sure you're 
calling CoInitialize or CoInitializeEx beforehand. If it's 
still failing, use std.windows.syserror.sysErrorString(hr) to 
see if it gives you a reason. Otherwise, CLSCTX_ALL might be 
the culprit - try using CLSCTX_SERVER instead.



Cool. Oleview gives me the idl files. How to convert the idl 
files to d or possibly c?


Would I just use them in place of IUnknown once I have the 
interface?

Re: Access private member

[Basile B. via Digitalmars-d-learn]

On Monday, 13 June 2016 at 15:00:06 UTC, Basile B. wrote:

On Monday, 13 June 2016 at 14:30:13 UTC, Basile B. wrote:

On Monday, 13 June 2016 at 11:27:31 UTC, Jacob Carlborg wrote:

On 2016-06-13 09:54, Pierre wrote:

Thank you i will try it.


You don't need to involve the constructor. You can use 
.tupleof, as I mentioned [1] [2].


[1] http://forum.dlang.org/post/njlohq$1n99$1...@digitalmars.com
[2] http://forum.dlang.org/post/njlop0$1ngk$1...@digitalmars.com


I understand that web devels needs to dump 47 bytes and send 
them at 8759 miles in 200 ms, but this serialization scheme is 
not good for object streaming, e.g store a full GUI in a 
resource file. Nobody will ever use flatbuffer or message pack 
to store a GUI...lol.


oops I think I've replied to another thread on another board :/

Unless It's you Jacob who have proposed Orange to phobos in 
2012. And then since refused it's not developed at all. IIRC 
it's even not possible to compile it with DUB.


https://www.youtube.com/watch?v=YJO4-aa6PCI=PLuhnsen8iS5ltHofd21TWBx-bqmR9V8RU=14=False

now you know the origin of the hat ;)

Re: What's up with GDC?

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

On Sunday, 12 June 2016 at 14:22:54 UTC, Joerg Joergonson wrote:
Error: undefined identifier 'Sleep' in module 'core.thread', 
did you mean function 'Sleep'?


It is supposed to be `Thread.sleep(1.seconds);`

I'm pretty sure the capital Sleep() is supposed to be private 
(that is the OS-specific Windows api call).



Basically keeping the event loop uses around 12% cpu and 12MB 
of memory.


That's weird, it just sleeps until a message comes in from the 
OS. On my computer, programs sit at 0% like you'd expect, and my 
guitest program (which has text areas, buttons, menu, etc) eats 
~1.7 MB, both 32 and 64 bit versions.


Are you running some other program that might be sending a lot of 
broadcast messages?


Do you know if there is a way to get the largest used memory 
chunks and what is using them? That might tell the story!


idk

Re: I'd love to see DScript one day ...

[Dmitry Olshansky via Digitalmars-d]

On 11-Jun-2016 13:07, yawniek wrote:

On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:

On 6/10/2016 3:55 AM, Chris wrote:
> Cool. I'd love to see `DScript` one day - and replace JS once
and for all ...
> well ... just day dreaming ...

Dreams are reality:

https://github.com/DigitalMars/DMDScript


unfortunately this is unmaintained, has no docs and isn't working on
linux/os x.
having an ecma script implementation that is able to access D data would
be very usefull
for performant scripting.


The only problem I'm aware of is that it's that 64bit are not supported yet.

--
Dmitry Olshansky

Re: Garbage Collection, Untraceable Errors...

[cy via Digitalmars-d]

On Monday, 13 June 2016 at 08:58:40 UTC, Vladimir Panteleev wrote:


FWIW: http://wiki.dlang.org/InvalidMemoryOperationError


Yeah... I did forget that the GC was not re-entrant. But the 
"stop collecting inside the destructor, moron" error is exactly 
the same as "something allocated in the destructor... moron" 
error. I'd think we could just allocate space for a potential 
stack trace before starting garbage collection, but I guess not?

Re: Garbage Collection, Untraceable Errors...

[cy via Digitalmars-d]

On Monday, 13 June 2016 at 08:49:55 UTC, Guillaume Piolat wrote:

This thing helps with getting rid of such bugs.


I suppose. The real cause of the bugs is not destructors I think, 
but memory corruption. Since frees (and double-frees) are 
deferred so long, it's just impossible to even guess at where the 
double destruction happened, or when you dereferenced a null 
pointer and D didn't catch that... again.


For those bugs, it would really help to know which objects are 
being freed, so you can check whether you accidentally forgot to 
initialize them or whatnot. Debugging their destructors is not 
the issue, and if it were I could just add a break inside the 
destructor itself.


Having a non-trivial destructor called by the GC, and relying 
on it, is imho an error at best, should always be manual.


I'd tend to agree. The reason I was using destructors at all is 
because I was using an SQL database. Those things like to act 
like whole global environments, where it's cheaper for you to 
create two tables within the same database than to have two 
databases open simultaneously, so usually when working with SQL I 
will make the database a global object, initialized on demand. 
Since there is *always* a database object, you can write code 
that can be optimized at compile-time, instead of code that runs 
conditionally at runtime, on the worthless check of whether it 
gets passed a database object or not.


So, the only problem is if the database is guaranteed to be open 
and usable anywhere in your code, when do you close it?


What I do is explicitly close it, then add a close() in the 
destructor with a warning. And then I run into GC errors... 
despite the only destructor in my entire program finishing 
without error.

Re: Access private member

[Basile B. via Digitalmars-d-learn]

On Monday, 13 June 2016 at 14:30:13 UTC, Basile B. wrote:

On Monday, 13 June 2016 at 11:27:31 UTC, Jacob Carlborg wrote:

On 2016-06-13 09:54, Pierre wrote:

Thank you i will try it.


You don't need to involve the constructor. You can use 
.tupleof, as I mentioned [1] [2].


[1] http://forum.dlang.org/post/njlohq$1n99$1...@digitalmars.com
[2] http://forum.dlang.org/post/njlop0$1ngk$1...@digitalmars.com


I understand that web devels needs to dump 47 bytes and send 
them at 8759 miles in 200 ms, but this serialization scheme is 
not good for object streaming, e.g store a full GUI in a 
resource file. Nobody will ever use flatbuffer or message pack 
to store a GUI...lol.


oops I think I've replied to another thread on another board :/

Unless It's you Jacob who have proposed Orange to phobos in 2012. 
And then since refused it's not developed at all. IIRC it's even 
not possible to compile it with DUB.

Re: Transient ranges

[John Colvin via Digitalmars-d]

On Monday, 13 June 2016 at 13:59:06 UTC, Steven Schveighoffer 
wrote:
No, it's not. My advice is to understand the limitations and 
expectations of the range wrappers you are using (i.e. read the 
docs [1]). If you need caching for your purposes, then do that 
by plopping cache at the end of your use case. The user must 
have to understand that providing a mapping function that does 
random things (or even varying things on each call) is going to 
result in unexpected behavior. The compiler cannot foresee the 
purpose of your lambda code.


You just said only pay for what you ask for. I don't want to 
pay for caching for map if I don't need it. I'd be pissed if 
map cached for something like map!(x => x * 2). If you want 
caching, then ask for it.


There was a talk by Herb Sutter on atomic operations on various 
platforms. His general rule was, as long as you don't write 
race conditions, and use only provided atomics, your code will 
do what you think. We can apply a similar rule here: as long as 
you write a lambda which for a given input will provide the 
same result, map will do what you expect. When you try odd 
things like your random call, we don't guarantee things will 
work like you expect. You may utilize the knowledge of how map 
works, and how the things that are using the map work to write 
something clever that breaks the rules. But no guarantees.


-Steve

[1] I admit, the map docs aren't explicit about this, and 
should be.


I see three levels of function used with map:

pure: everything is as expected, consider caching if expensive.

idempotent side-effects: remember map is lazy and you'll be ok.

non-idempotent side-effects: probably not what you want.

[Issue 15538] final switch statement raises an exception even though all cases are covered under certain conditions

[via Digitalmars-d-bugs]

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

Johannes Loher  changed:

   What|Removed |Added

   Attachment #1573|0   |1
is obsolete||

--- Comment #1 from Johannes Loher  ---
Created attachment 1600
  --> https://issues.dlang.org/attachment.cgi?id=1600=edit
new code example

--

Re: Access private member

[Basile B. via Digitalmars-d-learn]

On Monday, 13 June 2016 at 11:27:31 UTC, Jacob Carlborg wrote:

On 2016-06-13 09:54, Pierre wrote:

Thank you i will try it.


You don't need to involve the constructor. You can use 
.tupleof, as I mentioned [1] [2].


[1] http://forum.dlang.org/post/njlohq$1n99$1...@digitalmars.com
[2] http://forum.dlang.org/post/njlop0$1ngk$1...@digitalmars.com


I understand that web devels needs to dump 47 bytes and send them 
at 8759 miles in 200 ms, but this serialization scheme is not 
good for object streaming, e.g store a full GUI in a resource 
file. Nobody will ever use flatbuffer or message pack to store a 
GUI...lol.

Re: Gotchas for returning values from blocks

[jmh530 via Digitalmars-d-learn]

On Monday, 13 June 2016 at 01:41:07 UTC, Mike Parker wrote:


Everything works fine in your example because 'new' always 
allocates on the heap. Anything allocated on the stack is not 
guaranteed to be valid after the scope exits:


struct Foo
{
int baz;
~this() { baz = 1; }
}

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

Foo* foo;
{
Foo bar = Foo(10);
foo = 
}
//bar is now out of scope
assert(foo.baz == 10);
}

Struct constructors are always run when exiting a scope. More 
importantly, the pointer to bar is only valid until the stack 
address where it lives is overwritten by another stack 
allocation. In this example, there's no chance for that to 
happen before I access it, but it could happen at any time.


So returning a reference to something on the stack is a bad idea, 
but copying the value would be fine.

Re: Andrei's list of barriers to D adoption

[Bruno Medeiros via Digitalmars-d]

On 06/06/2016 09:15, Russel Winder via Digitalmars-d wrote:

* Tooling is immature and of poorer quality compared to the
> competition.

This is true.

We have too many half-finished attempt at things, basically because
everything is volunteer, not directly associated with work, activity.
Nothing wrong with this per se, but an obvious explanation why it is
so. Unless an oirganization or seven put some work-oriented effort into
the tooling, nothinkg will change.

I would suggest three ways forward:

1. Get effort on the IntelliJ IDEA and CLion plugin. Kingsley has made
a start. I suggest using his work as a basis and doing a new version
written in Kotlin instead of Java. Kotlin will be easier than Java for
D people to work with and easy for Java people to work with.

2. Get effort on the DDT Eclipse plugin. Bruno has declared it
finished, which is fine, but I would say it should not be treated that
way.

3. Have one lightweight D realized cross platform IDE. Qt us probably
the best widget set to use for this. My model here is LiteIDE which is
a Qt-based Go IDE realized in C++. It should of course be realized in
Go, but there are no Qt bindings for Go, only QML ones.



If anything is to be done about improving the IDE tooling, it should be 
work on a tool like D Completion Daemon (DCD) - that is, an IDE-agnostic 
tool for code completion and other language analysis functionality 
(find-references, refactor, etc.)


The IDE space is just too fragmented - there are now even more popular 
IDEs that than say 5 years ago - like VS Code, Atom, etc.. Even 
SublimeText is a relatively recent player.  As such it's not feasible to 
be focusing a work on just a few IDEs. You have to make the core of IDE 
functionality available in an IDE-agnostic tool.


VSCode for example has even defined a language-agnostic protocol for 
such language servers: 
https://github.com/Microsoft/vscode-languageserver-protocol/ , and there 
is work in a few other IDEs to adopt that protocol as well, and write 
their own IDE client implementation (Eclipse for example, but it's all 
very early stages).



In any case, this is all of secondary importance, IMO. The GC issue is 
much more critical. If people think D has a worthwhile future for 
building apps in real world scenarios, then the tooling will get there 
eventually, it will catch up. But if people think other languages will 
work much better for their needs (like Rust or others), no amout of 
exceptional tooling will make a difference.



BTW, "finished" is not the right word to describe the state of DDT, if 
anything it's now in maintenance mode. (actually not that different from 
what it has been in the last 1 year or so)


--
Bruno Medeiros
https://twitter.com/brunodomedeiros

Re: The Problem With DIPs

[Steven Schveighoffer via Digitalmars-d]

On 6/12/16 3:48 PM, Walter Bright wrote:

On 6/12/2016 11:50 AM, Dicebot wrote:

Your are very correct about importance of link stability though. What
comes to my mind immediately is to store all DIPs in same folder but
keep Approved/Implementec/etc as folders containing symlinks to the
merged one (git stores symlinks just fine).


I like Bugzilla's method of tagging issues, which allows arbitrary
crosscuts to be made.


Github has tags too:

https://github.com/dlang/druntime/pulls?q=is%3Aopen+is%3Apr+label%3AGC

But only on PRs and issues I would guess. Not sure how we could utilize 
this for files themselves.


-Steve

Re: Transient ranges

[Steven Schveighoffer via Digitalmars-d]

On 6/12/16 4:46 AM, Dicebot wrote:

On Friday, 3 June 2016 at 12:03:26 UTC, Steven Schveighoffer wrote:



Yes, I can see good reason why you would want this. Hm... a set of
adapters which reduce a range to its lesser API would be useful here:

array.asInput.map

But an expectation for map should be that you want it to be exactly
the same as the original, but with a transformation applied to each
fetch of an element. I think it needs to provide random access if
random access is provided to it.


That is matter of design philosophy. For me such basic library
primitives warrant C++ attitude of "don't pay for what you don't ask
for" - and everything else, including actual feature completeness, is of
negligible importance compared to that. If keeping random access for map
requires either caching or multiple evaluations of predicate, I want it
to be banned by default and enabled explicitly (not sure what could be
good API for that though).


So what it seems like you want is somerange.map(...).front to evaluate 
the lambda only once, without caching. This doesn't fit into the 
definition of ranges, which require the ability to access the same front 
more than once.


What you really want is a new kind of construct. It's not a range.

Given that front must be accessible more than once, map has to make a 
choice, caching or reevaluating. Not doing one of those two things is 
not an option for ranges.


Note that this has nothing to do with random access.


Phobos indeed doesn't seem to make such priorities right now and that is
one of reasons I am growing increasingly unhappy with it.


It's not so much that Phobos attempts to give you kitchen sink support 
at all costs, it's that if the sink being passed in has all the faucets, 
it'll forward them for free if possible.



Then it's not a bug? It's going to work just fine how you specified
it. I just don't consider it a valid "range" for general purposes.

You can do this if you want caching:

only(0).map!(x => uniform(0, 10)).cache


Good advice. Don't want bugs with non-stable results and accidental
double I/O in your long idiomatic range pipeline? Just put "cache" calls
everywhere just to be safe, defensive programming for the win!


Strawman, not what I said.


But that is what your answer meant in context of my original question :)
My complaint was about existing semantics are being error-prone and hard
to spot - you proposed it by adding more _manual_ fixup, which kills the
whole point.


No, it's not. My advice is to understand the limitations and 
expectations of the range wrappers you are using (i.e. read the docs 
[1]). If you need caching for your purposes, then do that by plopping 
cache at the end of your use case. The user must have to understand that 
providing a mapping function that does random things (or even varying 
things on each call) is going to result in unexpected behavior. The 
compiler cannot foresee the purpose of your lambda code.


You just said only pay for what you ask for. I don't want to pay for 
caching for map if I don't need it. I'd be pissed if map cached for 
something like map!(x => x * 2). If you want caching, then ask for it.


There was a talk by Herb Sutter on atomic operations on various 
platforms. His general rule was, as long as you don't write race 
conditions, and use only provided atomics, your code will do what you 
think. We can apply a similar rule here: as long as you write a lambda 
which for a given input will provide the same result, map will do what 
you expect. When you try odd things like your random call, we don't 
guarantee things will work like you expect. You may utilize the 
knowledge of how map works, and how the things that are using the map 
work to write something clever that breaks the rules. But no guarantees.


-Steve

[1] I admit, the map docs aren't explicit about this, and should be.

[Issue 16168] New: isCopyable trait for value types

[via Digitalmars-d-bugs]

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

  Issue ID: 16168
   Summary: isCopyable trait for value types
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

We have hasElaborateCopyConstructor, but we don't have something that tells us
if copying is disabled or not.

--

Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?

[FrankLike via Digitalmars-d]

On Friday, 10 June 2016 at 15:04:52 UTC, Ali Çehreli wrote:

Thank you,we are in the same organization 
'https://github.com/DlangRen'.


If you clone that repository and 'make' everything, there 
should be the following files generated:


  src/ders/d.cn/编程在D.print.pdf
  src/ders/d.cn/编程在D.pdf
  public_html_test/ders/d.cn/*


Here D编程 or 《Programming In D》 中文版 is better.

Frank

Re: dlang-requests 0.1.7 released

[ikod via Digitalmars-d-announce]

On Monday, 13 June 2016 at 08:29:28 UTC, Alexander Milushev wrote:

On Monday, 13 June 2016 at 00:09:12 UTC, ikod wrote:
On Sunday, 12 June 2016 at 22:37:34 UTC, Alexander Milushev 
wrote:

On Saturday, 11 June 2016 at 23:03:52 UTC, ikod wrote:

[...]


Hi, this is great project, but what about vibe.d 
compatibility?


This project doesn't depend on vibe.d, and I'm not sure if it 
can be directly used from inside vibe.d application, as it use 
blocked socket io.


Yeah, I understood, but is it possible to add support of vibe.d 
sockets too?


If you want to use requests from vibe.d application then this 
probably can be done using 
https://github.com/rejectedsoftware/vibe.d/wiki#integrating-non-vibed-io
But this require writing some wrapper. I can investigate this in 
the future.


Thanks!

[Issue 16150] Rework overview of D's features page

[via Digitalmars-d-bugs]

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

--- Comment #2 from greensunn...@gmail.com ---
I just created the issue as a reminder of Andrei's recent comment:

> "overview of special features of D" -> "overview of D's differentiating 
> features". That page needs to be redone...

(at https://github.com/dlang/dlang.org/pull/1314)

--

Re: Beta release DUB 1.0.0-beta.1

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

Am 13.06.2016 um 11:21 schrieb Andre Pany:

On Thursday, 9 June 2016 at 12:15:24 UTC, Sönke Ludwig wrote:

You need to use the --single switch:

dub build --single=app.d --build=release

For the commandline that you have used, the arguments "build
--build=release" will be passed to the compiled app.d executable
instead. I'll deploy proper documentation together with the release.


It is still not working. I have an easy example:

 file app.d ---

/+ dub.sdl:
  name "app"
+/

void main()
{
 import std.stdio;
 writeln("ABC");
}
 file app.d ---

While executing command:
dub --single=app.d

there is the error:
Error processing arguments: Can't parse string: bool should be
case-insensitive 'true' or 'false'

Is this a bug?

Kind regards
André


Oh sorry, I misremembered the type of the --single switch. Should be 
"dub --single app.d" instead, because it's actually a boolean switch.


BTW, it would be nice if std.getopt.getopt() would print the name of the 
argument in the error message.

[Issue 16150] Rework overview of D's features page

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com

--- Comment #1 from Jack Stouffer  ---
What about it specifically is outdated? I went through it about six months ago
and cleaned everything up.

--

Re: LDC 1.0.0 has been released!

[Gerald via Digitalmars-d-announce]

Awesome news, just noticed a blurb on the Linux news site 
Phoronix about this as well:


http://www.phoronix.com/scan.php?page=news_item=LDC-1.0-Released

[Issue 16019] Implement a way to check GC usage stats from application

[via Digitalmars-d-bugs]

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

--- Comment #1 from Dicebot  ---
https://github.com/dlang/druntime/pull/1591

--

[Issue 16149] foreach_reverse can't handle index variable of type int

[via Digitalmars-d-bugs]

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

--- Comment #7 from Steven Schveighoffer  ---
(In reply to Ketmar Dark from comment #6)
> (In reply to Steven Schveighoffer from comment #5)
> > int x = a.length would continue to be invalid (on 64-bit CPU). It's just for
> > foreach_reverse.
> 
> then i'll inevitably ask why `int x = a.length;` is invalid, but
> `foreach_reverse (int x, v; a)` is valid. that `foreach` obviously does the
> assign under the hood (at least this is the most practical way to imagine
> it).

foreach_reverse could be implemented like this:

for(size_t __idx = a.length; __idx; --__idx)
{
   int x = cast(int)(__idx - 1);
   auto v = a[__idx-1];
   ... // your code
}

In fact, if foreach was implemented similarly (always using hidden size_t to
iterate and assigning to your chosen variable as the index), it wouldn't get
into an infinite loop.

> the only way to skip that "hidden assign" is to redefive `foreach_reverse`
> completely — by still using increasing index in it, so x will go from 0 upto
> limit. otherwise you just introducing a random pseudo-solution by randomly
> breaking the rules.

The definition of foreach_reverse on an array is that it works exactly like
foreach, but visits the elements in reverse. There is no definition of how it
does this, so my implementation is valid. (in fact, the spec says the index
must be int, uint, or size_t, but I think this is a relic from 32-bit, non VRP
days).

The fact that the implementation rejects it is an implementation detail
leaking. It's not a *bad* thing, but clearly this is the case of the compiler
being too cautious, because it's OK with you being stupid in foreach.

--

Re: The Problem With DIPs

[Dicebot via Digitalmars-d]

On 06/12/2016 09:58 PM, Vladimir Panteleev wrote:
> On Sunday, 12 June 2016 at 18:50:06 UTC, Dicebot wrote:
>> Your are very correct about importance of link stability though. What
>> comes to my mind immediately is to store all DIPs in same folder but
>> keep Approved/Implementec/etc as folders containing symlinks to the
>> merged one (git stores symlinks just fine).
> 
> This might not be the case on Windows.
> 
> Does GitHub present symlinks in a nice way (i.e. as a redirect)?

I will look into auto-generating overview table sorted by categories
instead.

Re: Beta release DUB 1.0.0-beta.1

[Kagamin via Digitalmars-d-announce]

On Friday, 10 June 2016 at 17:45:54 UTC, Nick Sabalausky wrote:

On 06/08/2016 11:04 AM, Kagamin wrote:

BTW do people find nested comments particularly useful?


God yes. It's the *only* block comment I ever use. Non-nesting 
comment blocks are a worthless PITA with no real benefit: You 
can't comment out a block if the block already contains a block 
comment.


Block comments are low-level: the commented code changes its 
lexical structure completely, but you probably don't expect it 
and want it to behave and be properly commented at a higher 
level, which is provided by version statement.

Re: Access private member

[Jacob Carlborg via Digitalmars-d-learn]

On 2016-06-13 09:54, Pierre wrote:

Thank you i will try it.


You don't need to involve the constructor. You can use .tupleof, as I 
mentioned [1] [2].


[1] http://forum.dlang.org/post/njlohq$1n99$1...@digitalmars.com
[2] http://forum.dlang.org/post/njlop0$1ngk$1...@digitalmars.com

--
/Jacob Carlborg

Re: Automatic linking of PR and bugzilla issue?

[Jacob Carlborg via Digitalmars-d]

On 2016-06-13 10:33, Walter Bright wrote:


No, have to do that manually.


I'm pretty sure I've seen something that looks automated. Could that be 
for when a PR is merged?


--
/Jacob Carlborg

Re: Beta release DUB 1.0.0-beta.1

[Saurabh Das via Digitalmars-d-announce]

On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
support for single-file packages, which can be used to write 
shebang-style scripts on Posix systems:


[...]


That is really useful! Thanks again for all the work you put into 
dub and Vibe.

Re: The Problem With DIPs

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 12 June 2016 at 19:51:02 UTC, Walter Bright wrote:
Consider: would you ever have noticed a n.g. posting written by 
Alex in 2012?


But would it really have an effect if I wrote a DIP on getting 
predictable floating point behaviour? If there is a chance that 
it would, then I might consider it :-).

Re: Monads in D

[Atila Neves via Digitalmars-d]

On Saturday, 11 June 2016 at 18:27:19 UTC, deadalnix wrote:

On Saturday, 11 June 2016 at 14:26:20 UTC, Atila Neves wrote:

[...]


Honestly, the whole bind/return is just a giant NIH. >>> and
>>[...]
jack shit about monad even after 10s of tutorial when they 
aren't even hard in any way: because haskell and alike have 
made all that is in their power to obfuscate what is a monad.


I could go on, but this guy already did it way better that I 
can:

https://www.infoq.com/presentations/functional-pros-cons

The part about monad starts 25mins in.


That was awesome.

I didn't mean to imply I think monads are great and that `>>=` 
and `return` are great names. I just wanted to see how far I 
could take in D. For the lulz.


Atila

Re: I'd love to see DScript one day ...

[Chris via Digitalmars-d]

On Sunday, 12 June 2016 at 21:32:18 UTC, Ola Fosheim Grøstad 
wrote:

On Sunday, 12 June 2016 at 12:42:23 UTC, Adam D. Ruppe wrote:
The standard has moved on, the bar on performance has raised, 
and dmdscript hasn't even kept up with changes in D.


Not too worried about the performance, but EcmaScript 6 has 
increased the feature set so much that the spec is over twice 
as large as for EcmaScript 5... And Chrome 52 is apparently 
shipping with both ES6 and some ES7, so it will be hard to keep 
up.


Seems like it's a dead race. DMDScript has been in the attic for 
too long. Trying to play catch up with Google, an Internet 
company, seems hardly worth the effort.

Re: Beta release DUB 1.0.0-beta.1

[Andre Pany via Digitalmars-d-announce]

On Thursday, 9 June 2016 at 12:15:24 UTC, Sönke Ludwig wrote:

You need to use the --single switch:

dub build --single=app.d --build=release

For the commandline that you have used, the arguments "build 
--build=release" will be passed to the compiled app.d 
executable instead. I'll deploy proper documentation together 
with the release.


It is still not working. I have an easy example:

 file app.d ---

/+ dub.sdl:
 name "app"
+/

void main()
{
import std.stdio;
writeln("ABC");
}
 file app.d ---

While executing command:
dub --single=app.d

there is the error:
Error processing arguments: Can't parse string: bool should be 
case-insensitive 'true' or 'false'


Is this a bug?

Kind regards
André

Re: Announcing TinyRedis v2.1.0

[Martin Tschierschke via Digitalmars-d-announce]

On Saturday, 11 June 2016 at 18:44:43 UTC, Adil wrote:
It's been a while since i announced a TinyRedis release. So 
here goes.


TinyRedis is a fast and simple Redis(http://redis.io) driver 
for D. It has no dependencies and makes working with Redis 
trivial.

[...]

Download : https://github.com/adilbaig/Tiny-Redis/releases
GitHub : https://github.com/adilbaig/Tiny-Redis
Docs : http://adilbaig.github.io/Tiny-Redis/
Just a newbee question, is the Redis support included in Vibe.d a 
completely different thing or is there a cross-fertilisation of 
ideas?

Re: Garbage Collection, Untraceable Errors...

[Vladimir Panteleev via Digitalmars-d]

On Monday, 13 June 2016 at 08:26:34 UTC, cy wrote:

core.exception.InvalidMemoryOperationError@src/core/exception.d(693): Invalid 
memory operation


FWIW: http://wiki.dlang.org/InvalidMemoryOperationError

Re: Garbage Collection, Untraceable Errors...

[Guillaume Piolat via Digitalmars-d]

On Monday, 13 June 2016 at 08:26:34 UTC, cy wrote:


So... that's my complaint about the D garbage collection. It's 
frustratingly opaque, impossible to debug, and provides no help 
whatsoever in its error messages to understanding what went 
wrong. Garbage collection causes errors after the program has 
entirely finished, and calling GC.collect() inside a destructor 
will not only cause the error, it'll completely terminate the 
program before it finishes the destructor. Speed is great, but 
debugging with garbage collection is pretty much an endless 
fount of misery and frustration for me.



see what objects are being destructed
Well you can detect in a destructor if you are called by the GC: 
https://p0nce.github.io/d-idioms/#GC-proof-resource-class


This thing helps with getting rid of such bugs.
Having a non-trivial destructor called by the GC, and relying on 
it, is imho an error at best, should always be manual.

Re: Garbage Collection, Untraceable Errors...

[Mike Parker via Digitalmars-d]

On Monday, 13 June 2016 at 08:26:34 UTC, cy wrote:

So... that's my complaint about the D garbage collection. It's 
frustratingly opaque, impossible to debug, and provides no help 
whatsoever in its error messages to understanding what went 
wrong. Garbage collection causes errors after the program has 
entirely finished, and calling GC.collect() inside a destructor 
will not only cause the error, it'll completely terminate the 
program before it finishes the destructor. Speed is great, but 
debugging with garbage collection is pretty much an endless 
fount of misery and frustration for me.


While it would be nice to have the location of the error, you can 
be sure that the problem lies in a destructor somewhere. It is 
invalid for destructors of GC-managed objects to touch the GC. 
This is precisely the error you get when it happens.


Compiling with -vgc will tell you the source and line number of 
every place your code touches the GC. If your project is big, 
that may be more helpful than eyeballing all of you destructors.

Re: Automatic linking of PR and bugzilla issue?

[Walter Bright via Digitalmars-d]

On 6/13/2016 1:18 AM, Jacob Carlborg wrote:

When a PR i submitted for a bugzilla issue and the correct naming convention is
used for the PR title/commit message a link to the issue is posted in the PR.
Don't we have the other direction as well, posting a link to the PR in the 
issue?



No, have to do that manually.

Garbage Collection, Untraceable Errors...

[cy via Digitalmars-d]

Most people complain about garbage collection slowing things 
down, or causing moments of program hang, but lately D's 
performance has been pretty awesome in that regard, IMO. No, the 
problem I have with garbage collection is untraceable errors...


GC.collect() is just this opaque... black box thing, that you 
have to trust to magically find all the garbage and collect it. 
When it does, it's awesome. But when it doesn't... you're just 
screwed. You can't trace through garbage collection, can't debug 
it, can't examine its inner structures, see what objects are 
being destructed, or anything as far as I can tell.


So I get something like the following output:
All unit tests have been run successfully.
finalize
core.exception.InvalidMemoryOperationError@src/core/exception.d(693): Invalid 
memory operation


...and the program exits with status 1. No stack trace, no error 
reported. Somewhere I've got a null dereference or something, 
some failure of everything to initialize in the expected order. 
But I have no way of finding it outside of staring at the code 
for another 2 hours trying to see anything funny looking.


Trying to break on "exit" with gdb doesn't work either, since D 
unwinds the stack before exiting in a GC error. Tracing through 
finalization, the deepest I can get is something called rt_term 
before there is no more debugging information (despite 
BUILD=debug being specified). Reading the source in rt/dmain.d 
myself, I can divine that rt_term calls gc_term, and in gc_term 
the error is raised. But what functions gc_term calls, you can't 
even set a breakpoint for. GC.fullCollect() just isn't available. 
(And gdb doesn't let you do tab completion in D, so I can't list 
all possible functions similar to that one.)


So... that's my complaint about the D garbage collection. It's 
frustratingly opaque, impossible to debug, and provides no help 
whatsoever in its error messages to understanding what went 
wrong. Garbage collection causes errors after the program has 
entirely finished, and calling GC.collect() inside a destructor 
will not only cause the error, it'll completely terminate the 
program before it finishes the destructor. Speed is great, but 
debugging with garbage collection is pretty much an endless fount 
of misery and frustration for me.

Re: dlang-requests 0.1.7 released

[Alexander Milushev via Digitalmars-d-announce]

On Monday, 13 June 2016 at 00:09:12 UTC, ikod wrote:
On Sunday, 12 June 2016 at 22:37:34 UTC, Alexander Milushev 
wrote:

On Saturday, 11 June 2016 at 23:03:52 UTC, ikod wrote:

[...]


Hi, this is great project, but what about vibe.d compatibility?


This project doesn't depend on vibe.d, and I'm not sure if it 
can be directly used from inside vibe.d application, as it use 
blocked socket io.


Yeah, I understood, but is it possible to add support of vibe.d 
sockets too?

Re: Access private member

[Basile B. via Digitalmars-d-learn]

On Monday, 13 June 2016 at 07:53:08 UTC, Jacob Carlborg wrote:

On 2016-06-13 09:49, Jacob Carlborg wrote:


For fields, used .tupleof, for other symbols, use a pointer.


Here's an example [1] of accessing a field using the name of 
the field as a string. It will bypass private.


That module [1] contains some generic functionality for working 
with fields which you would need for serialization. Or you can 
use the whole serialization library directly [2] ;)


[1] 
https://github.com/jacob-carlborg/orange/blob/master/orange/util/Reflection.d#L123


[2] https://github.com/jacob-carlborg/orange


There's also the IZ serializer. It's based on accessors (called 
property descriptor) to read and write private or protected 
fields. Actually it's never a good idea to directly access them. 
Usually they're not hidden for anything (e.g the count of items 
in a list, the setter update the list...)


pd: 
https://github.com/BBasile/iz/blob/master/import/iz/properties.d
ser: 
https://github.com/BBasile/iz/blob/master/import/iz/serializer.d

Automatic linking of PR and bugzilla issue?

[Jacob Carlborg via Digitalmars-d]

When a PR i submitted for a bugzilla issue and the correct naming 
convention is used for the PR title/commit message a link to the issue 
is posted in the PR. Don't we have the other direction as well, posting 
a link to the PR in the issue?


--
/Jacob Carlborg

[Issue 16096] Linking to static library: can't parse __DATA/__objc_imageinfo

[via Digitalmars-d-bugs]

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

--- Comment #3 from Jacob Carlborg  ---
https://github.com/dlang/dmd/pull/5862

--

Re: Access private member

[Jacob Carlborg via Digitalmars-d-learn]

On 2016-06-13 09:49, Jacob Carlborg wrote:


For fields, used .tupleof, for other symbols, use a pointer.


Here's an example [1] of accessing a field using the name of the field 
as a string. It will bypass private.


That module [1] contains some generic functionality for working with 
fields which you would need for serialization. Or you can use the whole 
serialization library directly [2] ;)


[1] 
https://github.com/jacob-carlborg/orange/blob/master/orange/util/Reflection.d#L123


[2] https://github.com/jacob-carlborg/orange

--
/Jacob Carlborg

Re: Access private member

[Pierre via Digitalmars-d-learn]

Thank you i will try it.

Re: Access private member

[Jacob Carlborg via Digitalmars-d-learn]

On 2016-06-13 09:43, Pierre wrote:

Hi,
I would like to know how can i access private member of class from
outside ?
I think about serialization for instance, serializer must have access to
protected attributes. How this is done ?
Thank you.


For fields, used .tupleof, for other symbols, use a pointer.

--
/Jacob Carlborg

Re: Access private member

[Basile B. via Digitalmars-d-learn]

On Monday, 13 June 2016 at 07:43:09 UTC, Pierre wrote:

Hi,
I would like to know how can i access private member of class 
from outside ?
I think about serialization for instance, serializer must have 
access to protected attributes. How this is done ?

Thank you.


You can perform the introspection in the class itself, e .g in 
the __ctor.

Access private member

[Pierre via Digitalmars-d-learn]

Hi,
I would like to know how can i access private member of class 
from outside ?
I think about serialization for instance, serializer must have 
access to protected attributes. How this is done ?

Thank you.

Re: Accessing COM Objects

[John via Digitalmars-d-learn]

On Monday, 13 June 2016 at 01:22:33 UTC, Incognito wrote:
I've been reading over D's com and can't find anything useful. 
It seems there are different ways:


http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf

which is of no help and requires an idl file, which I don't 
have.


Then theres this

http://wiki.dlang.org/COM_Programming

which is also of no help:

import std.stdio;

import std.stdio, core.sys.windows.com, 
core.sys.windows.windows, std.exception, std.meta, std.traits;
import std.utf, core.stdc.stdlib, core.sys.windows.objidl, 
core.sys.windows.ole2;

pragma(lib, "ole32.lib");


GUID Guid(string str)()
{
static assert(str.length==36, "Guid string must be 36 chars 
long");
enum GUIDstring = "GUID(0x" ~ str[0..8] ~ ", 0x" ~ 
str[9..13] ~ ", 0x" ~ str[14..18] ~
", [0x" ~ str[19..21] ~ ", 0x" ~ str[21..23] ~ ", 0x" ~ 
str[24..26] ~ ", 0x" ~ str[26..28]
~ ", 0x" ~ str[28..30] ~ ", 0x" ~ str[30..32] ~ ", 0x" 
~ str[32..34] ~ ", 0x" ~ str[34..36] ~ "])";

return mixin(GUIDstring);
}

int main(string[] argv)
{

	// Adobe Photoshop App 9.0 CLSID 
{c09f153e-dff7-4eff-a570-af82c1a5a2a8}
	// Adobe Photoshop App 9.1 CLSID 
{6DECC242-87EF-11cf-86B4-44455354}


	auto CLSID_DOMDocument60 = 
Guid!("6DECC242-87EF-11cf-86B4-44455354");

auto iid = IID_IUnknown;

void* pUnk;
	auto hr = CoCreateInstance(_DOMDocument60, null, 
CLSCTX_ALL, , );

if (FAILED(hr))
throw new Exception("Error!");

writeln("Hello D-World!");
return 0;
}

Maybe my CLSID's are wrong. Got them from the registry. The 
exception triggers each time. Even if it worked, I wouldn't 
know how to use it.


I can do this stuff in C# by simply dragging and dropping a dll 
into the references and it works fine but is a bit slow. I was 
hoping I could speed things up using D but it seems like COM 
isn't really supported, despite what several references say.


COM is supported in D. The difference is that C# hides all the 
plumbing behind nice classes.


You're going to need Photoshop's COM interface to do anything 
with it. If you don't have a C header that you can translate into 
D, you could use a tool included in the Windows SDK called 
OleView. It will peek inside COM  libraries and give you the 
interface definitions.


As to why CoCreateInstance isn't working, make sure you're 
calling CoInitialize or CoInitializeEx beforehand. If it's still 
failing, use std.windows.syserror.sysErrorString(hr) to see if it 
gives you a reason. Otherwise, CLSCTX_ALL might be the culprit - 
try using CLSCTX_SERVER instead.

Re: Andrei's list of barriers to D adoption

[Olivier via Digitalmars-d]

On Tuesday, 7 June 2016 at 08:09:49 UTC, Ethan Watson wrote:

On Tuesday, 7 June 2016 at 07:57:09 UTC, Walter Bright wrote:

C++ still suffers from:

http://www.digitalmars.com/articles/b44.html

and probably always will.


template< size_t size > void function( char (  )[ size ] 
);


It's horrible syntax (no surprise), and being a templated 
function means it's recompiled N times... but there's at least 
something for it now.


There is array_view and string_view that have been proposed (and 
I even think  accepted) for C++17.


But if you want a fat pointer, you can just write one yourself:

template< typename T >
struct FatPtr
{
   template< std::size_t N >
   FatPtr( T ()[N] )
  : p (a)
  , n (N)
   { }

   T *p;
   std::size_t n;
};

void function( FatPtr a );

int main( )
{
   char a[128];
   function(a);

   function("foo");
}