Re: How do I convert a LPVOID (void*) to string?

[Nieto via Digitalmars-d-learn]

Thanks for all answers guys.

If you're using this solely for Windows error messages, the 
std.windows.syserror module has a function, sysErrorString, 
which wraps it up for you. It also provides a WindowsException 
you can throw which, given an Windows error code, will contain 
a formatted system error message.


https://dlang.org/phobos/std_windows_syserror.html


Yep, I was using solely for Windows error messages. In fact, I 
was trying to reinvent the wheel of wenforce(). Thanks for point 
out this. I should have asked if there was a native function for 
this rather go on and write one myself...

Re: [OT] Generative C++

[Joakim via Digitalmars-d]

On Friday, 28 July 2017 at 07:49:02 UTC, Yuxuan Shui wrote:
Someone made an interesting proposal to C++: 
https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf


Thoughts?


Sutter gave a longer presentation on his proposal at CppCon, 
which was posted online late last month and is the most-viewed 
talk from the conference after Bjarne's keynote:


https://www.youtube.com/watch?v=4AfRAVcThyA

I enjoyed watching Regehr's talk on undefined behavior, 
particularly since I hit that shift UB issue in D some time back:


https://www.youtube.com/watch?v=v1COuU2vU_w
https://www.youtube.com/watch?v=TPyLrJED0zQ
http://forum.dlang.org/thread/xxqdnjscsdtbbwkma...@forum.dlang.org

D for microservices

[Joakim via Digitalmars-d]

I just read the following two week-old comment on the ldc issue 
tracker, when someone tried to run D on Alpine linux:


"For now everything works(?) but I think the process could be 
improved.. Would be really cool to have LDC easily building 
alpine containers + static D binaries for microservice and 
tooling development. I'm pretty tired of reading Go code :)"

https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550

It strikes me that microservices are a great way for new 
programming languages like D to get tried and gain some uptake, 
but that D might not be that easy to deploy to that scenario yet.


So this is a question for those deploying microservices, as I'm 
not in that field, what can the D devs do to make it as easy as 
possible to get D microservices up and running, make some Docker 
and Alpine containers with ldc/dub/vibe.d preinstalled publicly 
available?  What else, what kinds of libraries do you normally 
use?


This is a niche that D and all newer languages should target.  
How do we do it?

Re: Silicon Valley D Meetup - October 26, 2017 - "D Fibers" by Ali Çehreli

[Ali Çehreli via Digitalmars-d-announce]

On 10/21/2017 04:57 PM, Mengu wrote:
> On Saturday, 21 October 2017 at 18:20:13 UTC, Ali Çehreli wrote:
>> [We're at a very convenient location again this time: Downtown
>> Mountain View.]
>>
>> [...]
>
>
> allahiniz varsa kaydedersiniz. :)

[Mengü is wishing that we will manage to record the meeting.]

Related, we tried to use the very fancy equipment that's in the exact 
meeting room that we will be using. The audio was on and off, with about 
50% success rate. We fixed it by powering down one of the fancy 
microphone thingies. To repeat, in my experience, recording meetings is 
not a solved problem yet. :)


Ali

Re: So why double to float conversion is implicit ?

[codephantom via Digitalmars-d]

On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote:
Interestingly enough, I realized that atan() returns double (in 
this case) but wait, it's assigned to a float variable! 
Compiler didn't even emit warnings, let alone errors.




There a few lessons here.

(1) D is not Java ;-)
(2) Know what types are being returned from your calls, before 
you call them.
(3) Know what the language spec says about conversions (and their 
order):

- https://dlang.org/spec/type.html
(4) If unsure, test it:
- 
https://dlang.org/phobos/std_traits.html#isImplicitlyConvertible


Only then should you start coding ;-)

oh...and...

(5) Don't waste time arguing with the spec ;-)
(6) Don't expect the compiler to not comply with the spec

Re: My two cents

[EntangledQuanta via Digitalmars-d]

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:

Hi,
I had been using D for almost 6 years and I want to share my 
opinion with you.
I don't want to blame anyone but I'll focus more on bad things 
and possible improvements.

And this is just how I see D from my perspective.
(Sorry for my English, I'm too lazy to take the lessons).


First, D started as a great new language with the best from all 
languages. But now D seems more and more conservative. New 
syntactic sugars aren't added just because they can be found in 
phobos. (this was Walter's answer when I asked for maybe monad 
syntactic sugar).


OK, what I'm missing in D and what I think is wrong?

syntactic sugar for:
tuples
maybe monad (why we cannot have same syntax as in C#?)
conditional dereferencing and stuff about that (same as in C#)
foo?.bar;
foo?[bar];
return foo ?? null;

async/await (vibe.d is nice but useless in comparison to C# or 
js async/await idiom)
I want to create function returning Promise/Task and await 
where I want to.

e.g.
auto result = device.start(foo, bar); // This is RPC to remote 
server returning Task!Bar

// do some important stuff
return await result; // wait for RPC finish, then return it's 
result


I want to do this and not any ugly workaround about that.


@trusted, @safe, @system - why we have 3 keywords instead of 
one? And why it's so complicated to use?


First, we should have one 'unsafe' keyword.
Second, everything should be safe by default.
3rd, if we want to declare @system func, use 'void foo() 
unsafe;'

if we want to declare @trusted func, use
void foo() {
unsafe {

}
}

This fulfills the D's idiom in better way, because we should be 
defining unsafe sections as small as possible.



C# properties instead of existing ones.
function and property should be two different things.
Calling function without () or assigning to it by = is a ugly 
behavior and should be avoided.


implement this thing from C# (just because it's cool)
new Foo() {
  property1 = 42,
  property2 = "bar"
};


Reference counting when we cannot use GC...


Commercial usage, shared libraries and stuff
There isn't any handy tool to download, manage and publish 
closed source stuff.
dub is great for simple solutions but useless in big projects 
with multiple targets, configurations, etc.
Everything is primary focused on opensource development (but 
everyone here wants to see D as a next successor of C++ in 
commercial sphere).



Still cannot easily develop closed source dlls on Windows. On 
Linux every symbol is public by default, but on Windows not so 
it's needed to export them manually.



Unable to publish closed source library without workaround and 
ugly PIMPL design.


Add dll/so usage without header files
(export enums, templates and stuff right into dll/so and let D 
compiler to import these stuff from it)




For me, it seems like Walter is solving edge case problems like 
return ref parameters and return functions but is unable to add 
some basic stuff.





These guys are old now and don't have the drive they used to 
have. It happens, part of life. Unfortunately they do not realize 
this and do not want to pass the torch. I wouldn't expect 
anything major for D any more unless something significant 
changes in the management. D is stagnate, unfortunately and will 
almost surely never be a major player. It's unfortunate but D has 
a lot of problems. It is not commercially viable for the mass 
market. D is a hobby language and will remain that way for the 
majority of it's users. This is almost entirely due to the mind 
set you have. It's a lot of work to bring D up to par with the 
other languages and there seems very little interest in actually 
making that happen.


Walter only see's what he wants. He looks at D and does not see 
the flaws like  mother looking at her ugly baby. If one always 
looks at the pros and ignores the cons then anything looks good. 
D has a lot of great things but also a lot of bad things... until 
those bad things are fixed D won't go anywhere... it would be 
nice, at least, if the management would be objective about the 
bad things instead of sweeping them under the rug.  Faking it 
until you make it is not an option here.

[Issue 17925] [Contract Programming]

[d-bugmail--- via Digitalmars-d-bugs]

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

Rob  changed:

   What|Removed |Added

   Keywords||contracts

--

Re: Silicon Valley D Meetup - October 26, 2017 - "D Fibers" by Ali Çehreli

[Mengu via Digitalmars-d-announce]

On Saturday, 21 October 2017 at 18:20:13 UTC, Ali Çehreli wrote:
[We're at a very convenient location again this time: Downtown 
Mountain View.]


[...]



allahiniz varsa kaydedersiniz. :)

[Issue 17925] New: [Contract Programming]

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 17925
   Summary: [Contract Programming]
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: resmi...@outlook.com

This page has changed "body" to "do" and removed all references to "body" even
though "body" still works with DMD and the current versions of LDC and GDC only
know about "body" and people with older versions of DMD would also require
"body". 

Solution: add back "body" and tell what version of DMD began allowing "do" and
note that for now, "body" also works.

--

Re: Unit Testing in Action

[Walter Bright via Digitalmars-d-announce]

On 10/21/2017 6:14 AM, Martin Nowak wrote:

On Friday, 20 October 2017 at 21:26:35 UTC, qznc wrote:
* coverage is not sufficiently solved. The author suggests to reformat code so 
short-circuit evaluations become multiple lines?


If you can use gdc or ldc, branch coverage should be supported out of the box.
Other tools support regions to be marked as unreachable, e.g 
GCOVR_EXCL_START/GCOVR_EXCL_STOP.
I'd also err on the side that unittests themselves should not be part of 
coverage, but an option in druntime and more metadata from dmd might solve this.


Filed under https://issues.dlang.org/show_bug.cgi?id=17923.


Not sure what is meant by branch coverage.

Consider:

 x = 2;
 if (x == 1 || x == 2)

Coverage would give:

1|x = 2;
2|if (x == 1 || x == 2)

I.e. the second line gets an execution count of 2. By contrast,

1|x = 1;
1|if (x == 1 || x == 2)

What's happening here is each of the operands of || are considered to be 
separate statements as far as coverage analysis goes. It becomes clearer if it 
is reformatted as:


1|x = 2;
1|if (x == 1 ||
1|x == 2)

or:

3|x = 2; if (x == 1 || x == 2)

It's usually possible to trivially suss out the coverage of the clauses by 
looking at the preceding and succeeding line counts. Putting the clauses on 
separate lines also works. If there's a better way to display the various 
counts, please add it to the bugzilla report.

[Issue 17922] SysTime.to

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from Jonathan M Davis  ---
Yeah, unfortunately, there are a number of time zones that don't line up on the
hour (usually they then line up on the half hour, but IIRC, not even that is
always the case).

--

Re: My two cents

[user1234 via Digitalmars-d]

On Saturday, 21 October 2017 at 21:45:11 UTC, Adam D. Ruppe wrote:

On Saturday, 21 October 2017 at 20:02:28 UTC, user1234 wrote:
I'm not sure that people talked much about the elvis operator 
(which was introduced in the topic by M.Nowak). In the first 
message were mentioned the null coalescence operator "??"


What's the difference between `?:` and `??`?

As far as I can tell, they'd do the same thing in most cases.


Elvis operator returns LHS if LHS is true, otherwise RHS
Null coalescing operator returns LHS if LHS is not null, 
otherwise RHS


But since in D nullable values can be interpreted as booleans 
you're right "?:" would do the same as "??" and even more. 
Actually "?:" is preferable (which i didn't realize in first 
place :/).

Re: My two cents

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 21 October 2017 at 20:02:28 UTC, user1234 wrote:
I'm not sure that people talked much about the elvis operator 
(which was introduced in the topic by M.Nowak). In the first 
message were mentioned the null coalescence operator "??"


What's the difference between `?:` and `??`?

As far as I can tell, they'd do the same thing in most cases.

Re: My two cents

[Walter Bright via Digitalmars-d]

On 10/21/2017 1:40 PM, Adam Wilson wrote:
Walter has stated numerous times both here and at conferences that Async/Await 
is definitely a goal. However, it's not as high a priority as the @safe/@nogc 
work so it hasn't made it to any official vision statement. Also I just talked 
to him offline about it, and he would need some serious help with it. He doesn't 
know how to do the compiler rewrite, and there a number of tricky situations one 
has to deal with. As much as I like Async/Await, I agree that the current plan 
has higher priority.


I'll probably start poking around Async/Await when I can clear the decks a bit 
of paid work. But that could be a while. :(


Async/Await can be implemented by rewriting ("lowering") the code to simpler D 
code. Implementing it awaits (!) figuring out just what those rewrite rules are.

Re: Unit Testing in Action

[Mario Kröplin via Digitalmars-d-announce]

On Friday, 20 October 2017 at 21:26:35 UTC, qznc wrote:
* fluent-asserts is considered the best expectations library. 
Syntax is `(x + y).should.equal(42).because("of test 
reasons");` and it gives nice output with code snippets.


The code snippets were the prominent feature from the 
announcement of fluent-asserts. But this feature was the reason 
why I originally dismissed the library. In my opinion, the goal 
is that the failure message describes the issue without the need 
to look at the test implementation.


The diff of lengthy strings is, what I was always looking for. 
Back then, I wrote a lightweight kind of diff for dunit. In 
writing the blog post, I rechecked code.dlang.org. To my 
surprise, Sönke Ludwig ported google-diff-match-patch to D in 
2014. (The status is "build: error", but there is hope that it's 
only corner cases that don't work.) Further investigation 
revealed that fluent-asserts uses this port. So, it's this 
"hidden feature" that currently makes fluent-asserts my favorite.

Re: My two cents

[Adam Wilson via Digitalmars-d]

On 10/21/17 11:52, bitwise wrote:

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:


async/await (vibe.d is nice but useless in comparison to C# or js
async/await idiom)




Reference counting when we cannot use GC...



If I understand correctly, both of these depend on implementation of
'scope' which is being worked on right now.

I think reference counting needs 'scope' to be made safe. RC also
benefits from scope in that many of the increments/decrements of the ref
count can be elided. The performance gain can be significant, and even
more so when you use atomic reference counting (like C++ shared_ptr) for
thread safety.

Async/Await needs to allocate state for the function's local variables.
When it's detected that the function's state/enumerator won't escape
it's current scope, it can be put on the stack, which is a pretty big
optimization.

I should also note that, RC has been formally acknowledged as a future
goal of D, but as far as I know, async/await has not.



Walter has stated numerous times both here and at conferences that 
Async/Await is definitely a goal. However, it's not as high a priority 
as the @safe/@nogc work so it hasn't made it to any official vision 
statement. Also I just talked to him offline about it, and he would need 
some serious help with it. He doesn't know how to do the compiler 
rewrite, and there a number of tricky situations one has to deal with. 
As much as I like Async/Await, I agree that the current plan has higher 
priority.


I'll probably start poking around Async/Await when I can clear the decks 
a bit of paid work. But that could be a while. :(


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

Re: So why double to float conversion is implicit ?

[user1234 via Digitalmars-d]

On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote:
I was working on some sort of math library for use in graphical 
computing and I wrote something like this:


const float PiOver2 = (atan(1.0) * 4) / 2;

Interestingly enough, I realized that atan() returns double (in 
this case) but wait, it's assigned to a float variable! 
Compiler didn't even emit warnings, let alone errors.


I see no reason as to why would this be legal in this century, 
especially in D.

So can someone tell me what's the argument against this?
Why type conversions differ between integral and floating types?
Why can't I assign a long to an int but it's fine when 
assigning double to float?


I think this is a serious topic and needs clarification.


D is compliant with C++ in this case (see 
http://en.cppreference.com/w/cpp/language/implicit_conversion) so 
the question is rather why does C++ allow this conversion. When 
you convert a double to a float you're more likely to have a 
precision loss while when you convert an ulong to an int you risk 
a most serious data loss.

Re: My first experience as a D Newbie

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 21 October 2017 at 09:51:41 UTC, Mark wrote:
Honestly, I do not believe that an open-source project, beyond 
a certain scale, can sustain itself without a consistent income 
stream.


It is possible, but you need a very modular architecture. The 
main problem for large open source projects is 
restructuring/refactoring, which can kill the project.


One example of large open source volunteer based projects are 
MUDs, but they tend to be very modular in nature.

So why double to float conversion is implicit ?

[NX via Digitalmars-d]

I was working on some sort of math library for use in graphical 
computing and I wrote something like this:


const float PiOver2 = (atan(1.0) * 4) / 2;

Interestingly enough, I realized that atan() returns double (in 
this case) but wait, it's assigned to a float variable! Compiler 
didn't even emit warnings, let alone errors.


I see no reason as to why would this be legal in this century, 
especially in D.

So can someone tell me what's the argument against this?
Why type conversions differ between integral and floating types?
Why can't I assign a long to an int but it's fine when assigning 
double to float?


I think this is a serious topic and needs clarification.

Re: My two cents

[user1234 via Digitalmars-d]

On Saturday, 21 October 2017 at 19:39:31 UTC, Andrei Alexandrescu 
wrote:

[...]
Using the topic of the Elvis operator as a running example, a 
good DIP would contain motivation such as:


* Present evidence of the successful use of ?: in other 
languages


I'm not sure that people talked much about the elvis operator 
(which was introduced in the topic by M.Nowak). In the first 
message were mentioned the null coalescence operator "??" and the 
safe navigation one "?." . The later was more discussed.

Re: Static if on release build

[Guillaume Piolat via Digitalmars-d-learn]

On Friday, 20 October 2017 at 02:36:37 UTC, Fra Mecca wrote:
I can't find any documentation regarding conditional 
compilation in release and debug mode.


I have read the page regarding the topicon dlang.org but adding 
the snippet below makes no difference when compiling with dub 
-b release

{
version(full) {
 //do something
} else {
//do something else
}

How can I produce a release version with different parameters 
from debug using dub and static if's?


Note thatwith D compilers -debug and -release are not opposed to 
each other. A program can have both flags, or none.

Re: My two cents

[Andrei Alexandrescu via Digitalmars-d]

On 10/21/17 9:47 AM, Martin Nowak wrote:

On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe wrote:

On Friday, 20 October 2017 at 16:36:28 UTC, jmh530 wrote:
It might help to have some sense of how the main devs time on D is 
being used.


Definitely, I currently have no clue what they are on.


Tried that, didn't resonate that much, and is also quite some work.
So we mostly stick to internal discussions atm.
https://forum.dlang.org/post/o2g7mg$12oa$1...@digitalmars.com

Timelines and planning also don't work too well with volunteering.


Martin's levelheaded answers are much appreciated. (For what it's worth 
I've been traveling a fair amount recently which brings money in 
Foundation's coffers and more attention to the D language. I am coping 
with the unpleasant reality I haven't written real code in months.)


The matter discussed in this thread seems to have been suddenly rendered 
political, which is why I find it opportune to intervene - in all 
likelihood, improving nothing :o).


Sticking to technical points, some of the original points are easy to 
explain as misunderstandings (e.g. safe/system/trusted - yes all three 
are needed), whereas others can be converted productively into real 
steps forward for the language.


Using the topic of the Elvis operator as a running example, a good DIP 
would contain motivation such as:


* Present evidence of the successful use of ?: in other languages

* Present evidence of workarounds being used in D such as orElse, 
lazyElse etc.


* Present evidence of the usefulness of the ?: operator in gcc, see 
https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Conditionals.html


* Show how production code fragments in dmd, phobos, or other codebases 
would be significantly improved by the use of the operator


Yes, there's no guarantee that such a DIP would be approved. But the 
"need a relationship with the cabal to get things in" angle is very 
damaging to our community. So is the framing of the language 
enhancements topic as a fight against arbitrary prejudice. These kind of 
allegation discourage people from putting good work in, which is all 
that's needed.



Andrei

Re: My two cents

[bitwise via Digitalmars-d]

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:

async/await (vibe.d is nice but useless in comparison to C# or 
js async/await idiom)




Reference counting when we cannot use GC...



If I understand correctly, both of these depend on implementation 
of 'scope' which is being worked on right now.


I think reference counting needs 'scope' to be made safe. RC also 
benefits from scope in that many of the increments/decrements of 
the ref count can be elided. The performance gain can be 
significant, and even more so when you use atomic reference 
counting (like C++ shared_ptr) for thread safety.


Async/Await needs to allocate state for the function's local 
variables. When it's detected that the function's 
state/enumerator won't escape it's current scope, it can be put 
on the stack, which is a pretty big optimization.


I should also note that, RC has been formally acknowledged as a 
future goal of D, but as far as I know, async/await has not.

Silicon Valley D Meetup - October 26, 2017 - "D Fibers" by Ali Çehreli

[Ali Çehreli via Digitalmars-d-announce]

[We're at a very convenient location again this time: Downtown Mountain 
View.]


  https://www.meetup.com/D-Lang-Silicon-Valley/events/243120102/

D Fibers

Ali will present a shorter version of his DConf 2016 talk:

  http://dconf.org/2016/talks/cehreli.html

D's fibers (coroutines in other languages) are not a part of the 
language but a feature implemented by the D runtime.


This talk should be fairly accessible to new programmers even without a 
CS background as it will explain the function call stack as well as 
context registers, concepts necessary to understand how fibers are 
useful at all.


As always, bring all other D questions and comments...

Ali Çehreli has been working with C, C++, and D in Silicon Valley since 
1996. He is the author of the book "Programming in D", a board member of 
The D Language Foundation, and an organizer of DLang and ACCU meetup 
groups in Silicon Valley.


Ali

Re: is(this : myClass)

[Patrick via Digitalmars-d-learn]

But with the current compiler you would never write

is(typeOf(myC) : typeof(c))

if in your mind "c" is actually a class "C" because if that is 
in your mind you would just write


is(typeof(myC) : c)

which would get you the error. You only need typeof(variable) 
to get to the type, there is no point in doing typeof(type), 
you just write type and C is a type. Right?


But what value is evaluating a class type to a primitive type? It 
will never be true? There has to be a reasonable chance for the 
evaulation to be true for the 'is' operator to provide value. The 
compiler should reject this 'is' statement or at minimum issue a 
warning of incompatible types. This is nonsense creep of unusable 
code (being able to write code that has no meaning and value).


This is equivalent to writing code like the following. It is just 
more obfuscated:


if(false)
{
 ...
}
else
{
 ...
}

Patrick

Re: My two cents

[Martin Nowak via Digitalmars-d]

On Friday, 20 October 2017 at 22:25:20 UTC, Adam Wilson wrote:
For example, ?? and ?. are ridiculously common idioms that we 
all perform every day in our D code. And as Mr. Ruppe rightly 
pointed out, it'd probably take about an hour each to knock 
together a complete PR for these features.


Well, ignoring communication doesn't make it unnecessary.
It just means that the communication has to happen after throwing 
a drive-by PR at us.


Would be great if we could adequately capture arguments to 
facilitate those discussions.
Seems like there wasn't even an ER for that 
https://issues.dlang.org/show_bug.cgi?id=17924.

[Issue 17924] New: allow to omit middle operator in ternary condition (a.k.a. add ?: Elvis operator)

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 17924
   Summary: allow to omit middle operator in ternary condition
(a.k.a. add ?: Elvis operator)
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

https://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Conditionals.html#Conditionals
https://en.wikipedia.org/wiki/Elvis_operator

--

Re: My two cents

[Martin Nowak via Digitalmars-d]

On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe wrote:

On Friday, 20 October 2017 at 16:36:28 UTC, jmh530 wrote:
It might help to have some sense of how the main devs time on 
D is being used.


Definitely, I currently have no clue what they are on.


Tried that, didn't resonate that much, and is also quite some 
work.

So we mostly stick to internal discussions atm.
https://forum.dlang.org/post/o2g7mg$12oa$1...@digitalmars.com

Timelines and planning also don't work too well with volunteering.

Re: My two cents

[Martin Nowak via Digitalmars-d]

On Friday, 20 October 2017 at 20:05:51 UTC, jmh530 wrote:
Interesting proposals, but IMHO, the only ESSENTIAL feature 
missing in D is the possibility to program in D using a 
built-in reference-counting based variant of the standard 
library.




Look at the goals for H2 2017
https://wiki.dlang.org/Vision/2017H2
The top three things: 1) @safety, 2) @nogc, 3) betterC. Under 
#2, it specifically says safe reference counting. It's getting 
worked on...


Yes, it's being worked on, but it's also a huge topic to come up 
with @safe memory management approach. It's literally about 
eradicating one of the biggest security bug classes, 
use-after-free.


Currently I'm working towards an ORM library starting at I/O 
(https://github.com/MartinNowak/io) to better inform the 
necessary design.


We already found couple of interesting litmus tests, like the 
window in iopipe.


auto window = iopipe.window;
iopipe.extend(512); // invalidates window :/
window[0]; // use after-free

Another thing that Walter previously found out is that exceptions 
are a major hassle for @nogc. I don't like the RC Exception 
solution much though, as it's a fairly specific workaround 
(https://github.com/dlang/druntime/pull/1804).


Towards that goal, making exception nesting optional and 
providing access to the current Exception in flight would allow 
to use the staticError approach in most places.

https://github.com/dlang/druntime/blob/bc832b18430ce1c85bf2dded07bbcfe348ff0813/src/core/exception.d#L683

Recently I wondered why we cannot semantically transform 
exceptions to the equivalent of function calls.


- throw Uniq!Exception; // ctor, some struct that's implicitly 
convertible to a Throwable


- catch (scope Exception e) // handler 1
{
throw e; // basically continue to unwind
}

- catch (scope Exception e) {} // handler 2

- done unwinding, destroy thrown value

We still support gotos in catch handlers, but should be possible 
to call destructors in catch handlers anyhow.

https://github.com/dlang/druntime/pull/1804/files#diff-f3953348bb302c27a8cea926c62c02e6R69

Re: Unit Testing in Action

[Martin Nowak via Digitalmars-d-announce]

On Friday, 20 October 2017 at 21:26:35 UTC, qznc wrote:
* coverage is not sufficiently solved. The author suggests to 
reformat code so short-circuit evaluations become multiple 
lines?


If you can use gdc or ldc, branch coverage should be supported 
out of the box.
Other tools support regions to be marked as unreachable, e.g 
GCOVR_EXCL_START/GCOVR_EXCL_STOP.
I'd also err on the side that unittests themselves should not be 
part of coverage, but an option in druntime and more metadata 
from dmd might solve this.


Filed under https://issues.dlang.org/show_bug.cgi?id=17923.

[Issue 17923] New: code coverage improvements

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 17923
   Summary: code coverage improvements
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

- branch coverage support

  There might be more than one expression on a single line, better coverage
tools support branch coverage.

- count unittests as non-code or at least offer an option

- allow to mark regions as non-reachable via // COV_EXCL_START/STOP comments

--

Re: My two cents

[Mark via Digitalmars-d]

On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:

Hi,
I had been using D for almost 6 years and I want to share my 
opinion with you.
I don't want to blame anyone but I'll focus more on bad things 
and possible improvements.

And this is just how I see D from my perspective.
(Sorry for my English, I'm too lazy to take the lessons).

[...]

Thanks for your time.
- Satoshi


I'm surprised that you didn't mention pattern matching. I really 
like it in Rust.

Re: DCompute target: Intel to Introduce New CPU-FPGA Hybrid Chip Supported by Acceleration Stack

[Nicholas Wilson via Digitalmars-d-announce]

On Friday, 20 October 2017 at 20:41:24 UTC, Nordlöw wrote:
Ever since I first tried programming in VHDL and realized that 
it, at that time, was far too unproductive for my taste, I've 
been waiting for the software and FPGA programming models to 
unite...


What kinds of simplifications (over OpenCL) can and will 
DCompute offer in this regard?


Over OpenCL: Same benefits it does over standard C
* a not completely insane interface
* generality and parameterisation
* reusability
* ...

As to how much of the total power of the FPGA you can use from D 
compared to VHDL remains to be seen, although it will be 
interesting to see how well this can cooperate with Luís' DHDL.

Re: DCompute target: Intel to Introduce New CPU-FPGA Hybrid Chip Supported by Acceleration Stack

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

But I also get this feeling that Intel do this as an 
anti-competitive monopolistic. Basically preventing ARM and AMD 
from partnering with Altera. So it could be more hostile than 
friendly…


The buy up might not make sense business wise in terms of new 
products. But it could make a lot of sense to keep other 
competing products off the table to keep the pricing of Xeons up… 
A pessimistic view, perhaps… but Intel has a history…

Re: DCompute target: Intel to Introduce New CPU-FPGA Hybrid Chip Supported by Acceleration Stack

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

On Friday, 20 October 2017 at 20:41:24 UTC, Nordlöw wrote:
Ever since I first tried programming in VHDL and realized that 
it, at that time, was far too unproductive for my taste, I've 
been waiting for the software and FPGA programming models to 
unite...


What kinds of simplifications (over OpenCL) can and will 
DCompute offer in this regard?


I don't know. It is an interesting development, but I've got a 
feeling that you have to address the hardware very specifically 
to get worthwhile performance. My gut feeling is that 
abstractions would be a bad idea…


So maybe this will be best suited for very narrow domains where 
you can rely on third party libraries (e.g. statistical signal 
processing and other fields) or narrow applications that can 
afford to tune very carefully to the underlying hardware.

Some tasks in D app

[Orkhan via Digitalmars-d-announce]

Hello. I have an app for multiplayer game website. I am Facing an 
issue about stacking terminal. Also the app does not save the 
logs which is supposed to.  I need someone who can fix this. Will 
send the app to developer.


in total The tasks are :
1) Fix stacking issue in the terminal,
2) Fix saving logs
3) Fix the reconnection issue (during the game if one of the 
opponent has left the game then another opponent sees the pop up 
window which says  "please wait while your opponent reconnect". 
But the problem is server does not reconnects the disconnected 
user when he comes back.
4) The same username can be logged in the server. we need to 
prevent this case. if the user is already in the server, then it 
shouldnt be allowed him to login again.


We have allocated budget for all these tasks. In total we are 
going to pay 250-300$.

Please contact me by email if you are interested :
a.mammad...@liverpool.ac.uk

Regards

[Issue 17922] SysTime.to

[d-bugmail--- via Digitalmars-d-bugs]

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

Uranuz  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Uranuz  ---
It seems that it was just misunderstanding that it's a minute part in timezone
offset. I should post this question at dlang forum first before issuing an
error. So there is no problem here.

--

[Issue 13911] rename std.stdio to std.io

[d-bugmail--- via Digitalmars-d-bugs]

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

Shriramana Sharma  changed:

   What|Removed |Added

 CC||samj...@gmail.com

--

[Issue 17907] Can't automatically resolve to function with same name as module

[d-bugmail--- via Digitalmars-d-bugs]

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

Shriramana Sharma  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---

--- Comment #4 from Shriramana Sharma  ---
(In reply to Martin Nowak from comment #2)
> Yes, there is little chance to support functions, as the same symbol would
> need to be resolved differently, e.g. in `.fun.fun` it's the module, but in
> `.fun()` it's supposed to be the function.

Come on people, what is the problem here? When it is followed by a () it is a
function, or if it is in another context such as a function argument list where
a function is expected then it is a function. Otherwise, it is a module. The
compiler, especially the *D* compiler, knows *everything*. It can do this.

> While the type resolution seems inconsistent, it is a common Java idiom to
> name source files after the main class/type, and it's widely used in (older)
> D libraries.

If by this you are saying that you have provided support for types to be named
the same as modules because it is the practice so in Java, kindly note that the
following Python standard library modules are named the same as their main
function:

https://docs.python.org/3/library/bisect.html#bisect.bisect
https://docs.python.org/3/library/copy.html#copy.copy
https://docs.python.org/3/library/fnmatch.html#fnmatch.fnmatch
https://docs.python.org/3/library/getopt.html#getopt.getopt
https://docs.python.org/3/library/getpass.html#getpass.getpass
https://docs.python.org/3/library/gettext.html#gettext.gettext
https://docs.python.org/3/library/glob.html#glob.glob
https://docs.python.org/3/library/pprint.html#pprint.pprint
https://docs.python.org/3/library/select.html#select.select
https://docs.python.org/3/library/signal.html#signal.signal

I can't begin to survey how many third-part Python libraries follow this
pattern as well.

Obviously, I'm coming to D after some years in Python for the speed factor.
Given that it is technically possible for the D compiler to resolve to a
function, marking the bug as WONTFIX seems to be closing one's mind to users'
convenience and expectations.

If you aren't able to allot this sufficient priority to spend time on it, at
least leave it open until someone can.

--

Re: iopipe alpha 0.0.1 version

[Martin Nowak via Digitalmars-d-announce]

On 10/19/2017 03:12 PM, Steven Schveighoffer wrote:
> On 10/19/17 7:13 AM, Martin Nowak wrote:
>> On 10/13/2017 08:39 PM, Steven Schveighoffer wrote:
>>> What would be nice is a mechanism to detect this situation, since the
>>> above is both un-@safe and incorrect code.
>>>
>>> Possibly you could instrument a window with a mechanism to check to see
>>> if it's still correct on every access, to be used when compiled in
>>> non-release mode for checking program correctness.
>>>
>>> But in terms of @safe code in release mode, I think the only option is
>>> really to rely on the GC or reference counting to allow the window to
>>> still exist.
>>
>> We should definitely find a @nogc solution to this, but it's a good
>> litmus test for the RC compiler support I'll work on.
>> Why do IOPipe have to hand over the window to the caller?
>> They could just implement the RandomAccessRange interface themselves.
>>
>> Instead of
>> ```d
>> auto w = f.window();
>> f.extend(random());
>> w[0];
>> ```
>> you could only do
>> ```d
>> f[0];
>> f.extend(random());
>> f[0]; // bug, but no memory corruption
>> ```
> 
> So the idea here (If I understand correctly) is to encapsulate the
> window into the pipe, such that you don't need to access the buffer
> separately? I'm not quite sure because of that last comment. If f[0] is
> equivalent to previous code f.window[0], then the second f[0] is not a
> bug, it's valid, and accessing the first element of the window (which
> may have moved).

The above sample with the window is a bug and memory corruption because
of iterator/window invalidation by extend.
If you didn't thought of the invalidation, then the latter example would
still be a bug to you, but not a memory corruption.

>> This problem seems to be very similar to the Range vs. Iterators
>> difference, the former can perform bounds checks on indexing, the later
>> are inherently unsafe (with expensive runtime debug checks e.g. in VC++).
> 
> But ranges have this same problem.
> 
> For instance:
> const(char[])[] lines = stdin.byLine.array;
> 
> Here, since byLine uses GC buffering, it's @safe (but wrong). If non-GC
> buffers are used, then it's not @safe.
> 
> I think as long as the windows are backed by GC data, it should be
> @safe. In this sense, your choice of buffering scheme can make something
> @safe or not @safe. I'm OK with that, as long as iopipes can be @safe in
> some way (and that happens to be the default).
> 
>> Similarly always accessing the buffer through IOPipe would allow cheap
>> bounds checking, and sure you could still offer IOPipe.ptr for unsafe
>> code.
> 
> It's an interesting idea to simply make the iopipe the window, not just
> for @safety reasons:
> 
> 1. this means the iopipe itself *is* a random access range, allowing it
> to automatically fit into existing algorithms.
> 2. Existing random-access ranges can be easily shoehorned into being
> ranges (I already did it with arrays, and it's not much harder with
> popFrontN). Alternatively, code that uses iopipes can simply check for
> the existence of iopipe-like methods, and use them if they are present.
> 3. Less verbose usage, and more uniform access. For instance if an
> iopipe defines opIndex, then iopipe.window[0] and iopipe[0] are possibly
> different things, which would be confusing.
> 
> Some downsides however:
> 
> 1. iopipes can be complex and windows are not. They were a fixed view of
> the current buffer. The idea that I can fetch a window of data from an
> iopipe and then deal simply with that part of the data was attractive.

You could still have a window internally and just forward to that.

> 2. The iopipe is generally not copyable once usage begins. In other
> words, the feature of ranges that you can copy them and they just work,
> would be difficult to replicate in iopipe.

That's a general problem. Unique ownership is really useful, but most
phobos range methods don't care, and assume copying is implicit saving.
Not too nice and I guess this will bite us again with RC/Unique/Weak.

The current workaround for this is `refRange`.

> A possible way forward could be:
> 
> * iopipe is a random-access range (not necessarily a forward range).
> * iopipe.window returns a non-extendable window of the buffer itself,
> which is a forward/random-access range. If backed by the GC or some form
> of RC, everything is @safe.
> * Functions which now take iopipes could be adjusted to take
> random-access ranges, and if they are also iopipes, could use the extend
> features to get more data.
> * iopipe.release(size_t) could be hooked by popFrontN. I don't like the
> idea of supporting slicing on iopipes, for the non-forward aspect of
> iopipe. Much better to have an internal hook that modifies the range
> in-place.
> 
> This would make iopipes fit right into the range hierarchy, and
> therefore could be integrated easily into Phobos.

I made an interesting experiment with buffered input ranges quite a
while ago.

Re: Beta 2.077.0

[Martin Nowak via Digitalmars-d-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/16/2017 06:45 PM, Martin Nowak wrote:
> First beta for the 2.077.0 release.

Second beta live now. This adds a missing core.sys.linux.netinet.in_
header which is used by vibe.d.

Happy Testing
- -Martin
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlnrHSIACgkQsnOBFhK7
GTlarA/5AQgG+A+QWTGx0BcokTjlS98N05qRailHUX27uL3lqeUrAWAoNa0iSS6a
j/hmPXWWJpRUWg6eTMh+zGyHsDjaqjVVgnoodJdPqRh2qWC/X3DYHGOXI+Im3vsA
XMjT/+AhKDebGnUIH+SCx06r/LjUvgIVqQnj2M89vh0NyACoDHLqYTngiaZnvvem
L+b3xsArzThrold9h/pe2o6jk9vg914zxpIhu9R59VC8d30nzYWjW64RqNXrJn+B
tC/ViI2/De4DQbUhty5QMtAK6hhbC4DksEhih1/kTGjobml4pFamE+sk9DDRBcjI
cbPyCz+vX7n9U6OKuRB0jgGPoi7uUdL/ded2FwOshktTV6hD7YWS7n40EJ/Kug/w
BYYfe4jepCVwEhBPmlziiPUmRKwflErSniSFwki6VD8Nyc7KGOrvaRC5+aRqfU0Z
CUsNc+0WpB1HdKZ8jNzGuKgf28pheb/IHV/oCMeVqSIJE639KdQvunMV+0Zet3B3
BhZ1AwMyQnpGPjR1V1vlT+1oEiDPpyw71B15lk8Hve9VJhAeAd0L7xwL7Vm1czpY
cFbW0Wq+zcUBRVvfTWsseqLH7LlSelBf/W48taxsHC7FpyKbibxyGM50wiWUxOXX
WEgx2rLwS+EilIhWIaHGiMmxq1jkmFceWgVtbfr4WL0l6Hi6QD8=
=/5x6
-END PGP SIGNATURE-

[Issue 17922] SysTime.to

[d-bugmail--- via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #1 from Jonathan M Davis  ---
So, what's the bug? toISOString does incorrectly put a colon in the timezone,
which is bug

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

But the others are supposed to put a colon there. Were you expecting that there
wouldn't be a :00 on the end because you passed a string without it to
fromISOExtString? It's not like the SysTime keeps track of how it was created.
Or did you expect that the :00 would be stripped off just because it's zeroes?
Or is it something else? to*String never strips out zeroes from the time zone
if that's what you're looking for.

--

[Issue 17922] New: SysTime.to

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 17922
   Summary: SysTime.to
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: neura...@gmail.com

The following example prints unexpected `:00` at the end of formated date
string.

import std.datetime;
import std.stdio;

void main()
{
SysTime dt = SysTime.fromISOExtString(`2017-10-21T12:59:34.196246+04`);
writeln(dt);
writeln(dt.toISOExtString());
writeln(dt.toISOString());
}

Application output:
2017-Oct-21 12:59:34.196246+04:00
2017-10-21T12:59:34.196246+04:00
20171021T125934.196246+04:00

--

Re: My first experience as a D Newbie

[Mark via Digitalmars-d]

On Saturday, 21 October 2017 at 01:45:40 UTC, codephantom wrote:
The real challenge (and ultimate goal) for any  open-source 
project (especially a volunteer based one), is finding 
equilibria.


Honestly, I do not believe that an open-source project, beyond a 
certain scale, can sustain itself without a consistent income 
stream.

Re: is(this : myClass)

[Igor via Digitalmars-d-learn]

On Friday, 20 October 2017 at 23:24:17 UTC, Patrick wrote:
On Friday, 20 October 2017 at 23:01:25 UTC, Steven 
Schveighoffer wrote:

On 10/20/17 6:23 PM, Patrick wrote:
On Friday, 20 October 2017 at 22:15:36 UTC, Steven 
Schveighoffer wrote:

On 10/20/17 5:55 PM, Patrick wrote:
Due to the very specific nature of the 'is' operator, why 
wouldn't the compiler know to implicitly query the class 
types? Why must it be explicitly written, typeof(this)?


The compiler generally doesn't "fix" errors for you, it 
tells you there is a problem, and then you have to fix it. 
You have to be clear and unambiguous to the compiler. 
Otherwise debugging would be hell.



Not asking the compiler to fix my errors.

When would
is(this, myClass) not mean: is(typeof(this) : 
typeof(myClass))?


class C
{
}

int c;

C myC;

is(myC : c);

oops, forgot to capitalize. But compiler says "I know, you 
really meant is(typeof(myC) : typeof(c)) -> false.


-Steve


If I explicitly wrote: is(typeof(myC) : typeof(c)) the outcome 
would still be false and it would still require debugging. So 
your example demonstrates nothing other then a type-o was made. 
Try again...


In this unique case, the compiler should identify the class and 
primitive types are incompatible and should issue an error 
instead (and not return false).


Patrick


But with the current compiler you would never write

is(typeOf(myC) : typeof(c))

if in your mind "c" is actually a class "C" because if that is in 
your mind you would just write


is(typeof(myC) : c)

which would get you the error. You only need typeof(variable) to 
get to the type, there is no point in doing typeof(type), you 
just write type and C is a type. Right?

Re: Writing some built-in functions for Bash, possible?

[Ky-Anh Huynh via Digitalmars-d-learn]

On Wednesday, 18 October 2017 at 08:15:53 UTC, evilrat wrote:

[...]

This isn't the actual code but should give you a hint, the rest 
is up to you.


Woh Thanks a ton. I can have some working code after a few hours 
:D


https://github.com/icy/dusybox/blob/master/lib/dusybox/bash_builtin_hello/package.d

(A screenshot: 
https://github.com/icy/dusybox#a-bash-builtin-command)


I got problem with type conversion. I had to use inline 
declaration for `long_doc`:


```
extern(C) static builtin dz_hello_struct =
{
  name: cast (char*) "dz_hello",
  func: _hello_builtin,
  flags: BUILTIN_ENABLED,
  long_doc: [
"Hello, it's from Dlang.",
"",
"A Hello builtin command written in Dlang."
  ],
  short_doc: cast (char*) "dz_hello",
  handle: null
};
```

otherwise the compiler reports that some variable is not be read 
at compile time, or kind of `cannot use non-constant CTFE pointer 
in an initializer`.


There are many things I need to study from your post. So far it's 
good :)


Thanks again

Re: Deimos X11 bindings license question

[vondes via Digitalmars-d]

How we can use it in https://mobile-phone-tracker.org mobile 
recorder on Android?

Re: D for Android

[vondes via Digitalmars-d]

How we can use it in [url=https://mobile-phone-tracker.org]mobile 
tracker[/url] on Android?