Re: Win10 defender still sees dmd.exe and rdmd.exe as malicious

[Matt via Digitalmars-d]

On Wednesday, 28 June 2017 at 14:21:24 UTC, Mike Parker wrote:

On Monday, 26 June 2017 at 02:55:17 UTC, Matt wrote:
Which version of the compiler? Which version of Windows? I'm 
on Windows 10 with 2.074.1 currently and never seen it with 
any version of DMD.


DMD is 2.074.1, windows10 pro (10.0.14393)


Is it the same issue as the one reported at [1]? If so, please 
add a comment there specifying which download you used (the 
installer or the zip). If not, please file a new issue.


[1] https://issues.dlang.org/show_bug.cgi?id=16405


The windows defender report goes:

Trojan:Win32/Fuery.B!cl

Which ran in /AppData/Local/Temp/.rdmd/rdmd-tst.d-[LONG 
STRING]/tst.exe

Re: Deprecate real

[Walter Bright via Digitalmars-d]

On 6/30/2017 5:20 AM, jmh530 wrote:

I've never found real confusing.

However, I do see some people confused by the fact that floating point 
operations may do intermediate steps at higher precision. Walter has provided 
the reasoning before and I think I agree with it. However, I think a case could 
be made for having an option to disable it and force intermediate calculations 
to be done at the precision of the type. I would consider it to be something of 
low importance, but other people might value it more.


https://github.com/dlang/druntime/pull/1621

Re: Phobos PR in need of review/merge

[Meta via Digitalmars-d]

On Tuesday, 27 June 2017 at 01:49:52 UTC, Meta wrote:
Another PR that somebody in IRC mentioned: 
https://github.com/dlang/phobos/pull/5004


This one hasn't had any response for awhile either.


The first PR has been reviewed and merged thanks to Jack Stouffer 
and Wilzbach. Can anyone familiar with std.concurrency review 
this one?

Re: Contribution to portuguese translation of D documentation

[Daniel Vieira via Digitalmars-d]

On Friday, 30 June 2017 at 17:25:53 UTC, Seb wrote:

On Friday, 30 June 2017 at 16:42:17 UTC, Daniel Vieira wrote:

[...]


That's great to hear!
I guess you are talking about the DLang Tour? 
(https://tour.dlang.org)

Either click on "edit" at the Portuguese translation:

https://tour.dlang.org/tour/pt/welcome/welcome-to-d

Or collaborate on GitHub directly:

https://github.com/dlang-tour/portuguese


Thanks for the information guys, I didn't notice that!

I'll start contributing!

Re: ReadProcessMemory + address from ollydbg

[bauss via Digitalmars-d-learn]

On Saturday, 1 July 2017 at 00:40:11 UTC, ag0aep6g wrote:

On 07/01/2017 02:30 AM, bauss wrote:

On Saturday, 1 July 2017 at 00:23:36 UTC, ag0aep6g wrote:

On 07/01/2017 01:41 AM, bauss wrote:

[...]

   if (!ReadProcessMemory(process,
 cast(PCVOID)address, cast(PVOID),


The second cast still looks suspicious. PVOID is void*, 
right? Then any mutable pointer type should implicitly 
convert to PVOID and you shouldn't need the cast.

[...]
Well the address is not a pointer. It's DWORD which is uint, 
so the cast is necessary since it stores the address.


Not that one. The other one. This one: `cast(PVOID)`.

I don't expect it to be related to your problem, but it 
shouldn't be necessary as far as I see.


Yeah, the cast was unnecessary.

So this is my code after the changes:
string ReadWinString(HANDLE process, DWORD address, size_t 
stringSize, string defaultValue = "") {

  if (!process || !address) {
return defaultValue;
  }

  SIZE_T bytesRead;
  char[1024] data;

  if (!ReadProcessMemory(process,
cast(LPCVOID)address, ,
stringSize, )) {
return defaultValue;
  }

  auto s = cast(string)data[0 .. stringSize].idup;

  return s ? s : defaultValue;
}

Results are still garbage data, correct length in bytesRead 
however.


I tried to pass the address with the main module's base address 
because I saw some posts online suggesting you might need to do 
that.


If I do that however I just get error 299 (ERROR_PARTIAL_COPY), 
so I don't think I needed the base address, but still can't 
figure out what exactly is wrong with my code and why I can't 
read the string from the address I give it, when it's a static 
address. Every time I look with ollydbg the address is the same 
and ollydbg can find the string just fine.

Re: ReadProcessMemory + address from ollydbg

[ag0aep6g via Digitalmars-d-learn]

On 07/01/2017 02:30 AM, bauss wrote:

On Saturday, 1 July 2017 at 00:23:36 UTC, ag0aep6g wrote:

On 07/01/2017 01:41 AM, bauss wrote:

[...]

   if (!ReadProcessMemory(process,
 cast(PCVOID)address, cast(PVOID),


The second cast still looks suspicious. PVOID is void*, right? Then 
any mutable pointer type should implicitly convert to PVOID and you 
shouldn't need the cast.

[...]
Well the address is not a pointer. It's DWORD which is uint, so the cast 
is necessary since it stores the address.


Not that one. The other one. This one: `cast(PVOID)`.

I don't expect it to be related to your problem, but it shouldn't be 
necessary as far as I see.

Re: ReadProcessMemory + address from ollydbg

[bauss via Digitalmars-d-learn]

On Saturday, 1 July 2017 at 00:23:36 UTC, ag0aep6g wrote:

On 07/01/2017 01:41 AM, bauss wrote:
string ReadWinString(HANDLE process, DWORD address, size_t 
stringSize, string defaultValue = "") {

   if (!process || !address) {
 return defaultValue;
   }

   SIZE_T bytesRead;
   char[1024] data;

   if (!ReadProcessMemory(process,
 cast(PCVOID)address, cast(PVOID),


The second cast still looks suspicious. PVOID is void*, right? 
Then any mutable pointer type should implicitly convert to 
PVOID and you shouldn't need the cast.



 stringSize, )) {
 return defaultValue;
   }

   auto s = cast(string)data[0 .. stringSize];

   return s ? s : defaultValue;


Here's an error that produces garbage.

`data` is a fixed-sized array, so the values are on the stack. 
That means `s` points to the stack. You can't return a pointer 
to the stack. It becomes invalid when the function returns. You 
can put it on the heap instead: `auto s = data[0 .. 
stringSize].idup;`.



}


Using ".idup" makes no difference in the result. I was under the 
impression the cast would already do that though, guess not. 
However the result is the same. I also tried to check "data" 
directly and it's already garbage there.


Well the address is not a pointer. It's DWORD which is uint, so 
the cast is necessary since it stores the address.

Re: ReadProcessMemory + address from ollydbg

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

On Sat, Jul 01, 2017 at 02:23:36AM +0200, ag0aep6g via Digitalmars-d-learn 
wrote:
> On 07/01/2017 01:41 AM, bauss wrote:
[...]
> >  stringSize, )) {
> >  return defaultValue;
> >}
> > 
> >auto s = cast(string)data[0 .. stringSize];
> > 
> >return s ? s : defaultValue;
> 
> Here's an error that produces garbage.
> 
> `data` is a fixed-sized array, so the values are on the stack. That
> means `s` points to the stack. You can't return a pointer to the
> stack. It becomes invalid when the function returns. You can put it on
> the heap instead: `auto s = data[0 .. stringSize].idup;`.
[...]

The compiler is supposed to catch errors like these with -dip1000.
Recently there was a DIP1000-related fix checked in that fixed some of
the problems with -dip1000 (specifically, a linker error I was running
into), so you may want to consider compiling with -dip1000 if you're
running the latest compiler.


T

-- 
Klein bottle for rent ... inquire within. -- Stephen Mulraney

Re: ReadProcessMemory + address from ollydbg

[ag0aep6g via Digitalmars-d-learn]

On 07/01/2017 01:41 AM, bauss wrote:
string ReadWinString(HANDLE process, DWORD address, size_t stringSize, 
string defaultValue = "") {

   if (!process || !address) {
 return defaultValue;
   }

   SIZE_T bytesRead;
   char[1024] data;

   if (!ReadProcessMemory(process,
 cast(PCVOID)address, cast(PVOID),


The second cast still looks suspicious. PVOID is void*, right? Then any 
mutable pointer type should implicitly convert to PVOID and you 
shouldn't need the cast.



 stringSize, )) {
 return defaultValue;
   }

   auto s = cast(string)data[0 .. stringSize];

   return s ? s : defaultValue;


Here's an error that produces garbage.

`data` is a fixed-sized array, so the values are on the stack. That 
means `s` points to the stack. You can't return a pointer to the stack. 
It becomes invalid when the function returns. You can put it on the heap 
instead: `auto s = data[0 .. stringSize].idup;`.



}

Re: ReadProcessMemory + address from ollydbg

[bauss via Digitalmars-d-learn]

On Friday, 30 June 2017 at 23:56:10 UTC, Stefan Koch wrote:

On Friday, 30 June 2017 at 23:53:19 UTC, bauss wrote:


I suspect the address is wrong, but it's the static address I 
picked up from ollydbg, so I'm kinda lost as for how ollydbg 
can get the correct string and I get the wrong one using same 
address.


You are aware that processes life in different memory spaces ?


Well it's a static address I'm trying to read from, so it 
shouldn't matter if I have the write handle to the process and 
the static address, should it?

Re: ReadProcessMemory + address from ollydbg

[Stefan Koch via Digitalmars-d-learn]

On Friday, 30 June 2017 at 23:53:19 UTC, bauss wrote:


I suspect the address is wrong, but it's the static address I 
picked up from ollydbg, so I'm kinda lost as for how ollydbg 
can get the correct string and I get the wrong one using same 
address.


You are aware that processes life in different memory spaces ?

Re: ReadProcessMemory + address from ollydbg

[bauss via Digitalmars-d-learn]

On Friday, 30 June 2017 at 23:41:19 UTC, bauss wrote:

On Friday, 30 June 2017 at 21:36:25 UTC, ag0aep6g wrote:

On Friday, 30 June 2017 at 20:14:15 UTC, bauss wrote:

[...]


I guess the first cast is necessary when `address` isn't typed 
as a pointer yet. But the other casts shouldn't be needed. If 
you get errors without them, those errors might give a hint on 
what's wrong.



[...]


bytesRead is a SIZE_T, no? Or maybe a DWORD.


It's the same.

This is my read function:
string ReadWinString(HANDLE process, DWORD address, size_t 
stringSize, string defaultValue = "") {

  if (!process || !address) {
return defaultValue;
  }

  SIZE_T bytesRead;
  char[1024] data;

  if (!ReadProcessMemory(process,
cast(PCVOID)address, cast(PVOID),
stringSize, )) {
return defaultValue;
  }

  auto s = cast(string)data[0 .. stringSize];

  return s ? s : defaultValue;
}

And this is how I call it:
auto text = ReadWinString(handleFromOpenProcess, 0x000, 16, 
"defaultString...");


where 0x000 is the address obviously.

If you can spot what I'm doing wrong it would be appreciated.


I mean I get data, it's not like the call fails or gives an 
error. It's just not the data I'm expecting.


I suspect the address is wrong, but it's the static address I 
picked up from ollydbg, so I'm kinda lost as for how ollydbg can 
get the correct string and I get the wrong one using same address.

Re: ReadProcessMemory + address from ollydbg

[bauss via Digitalmars-d-learn]

On Friday, 30 June 2017 at 21:36:25 UTC, ag0aep6g wrote:

On Friday, 30 June 2017 at 20:14:15 UTC, bauss wrote:

This is my definition:
BOOL ReadProcessMemory(HANDLE hProcess, LPCVOID lpBaseAddress, 
LPVOID lpBuffer, SIZE_T nSize, SIZE_T *lpNumberOfBytesRead);


And I'm reading it like this:
if (!ReadProcessMemory(process,
  cast(PCVOID)address, cast(PVOID),
  cast(DWORD)stringSize, cast(PDWORD))) {
  return defaultValue;
}


I guess the first cast is necessary when `address` isn't typed 
as a pointer yet. But the other casts shouldn't be needed. If 
you get errors without them, those errors might give a hint on 
what's wrong.



process is a HANDLE that I got from OpenProcess()
address is a DWORD
data is char[1024]
stringSize is size_t
bytesRead is PDWORD


bytesRead is a SIZE_T, no? Or maybe a DWORD.


It's the same.

This is my read function:
string ReadWinString(HANDLE process, DWORD address, size_t 
stringSize, string defaultValue = "") {

  if (!process || !address) {
return defaultValue;
  }

  SIZE_T bytesRead;
  char[1024] data;

  if (!ReadProcessMemory(process,
cast(PCVOID)address, cast(PVOID),
stringSize, )) {
return defaultValue;
  }

  auto s = cast(string)data[0 .. stringSize];

  return s ? s : defaultValue;
}

And this is how I call it:
auto text = ReadWinString(handleFromOpenProcess, 0x000, 16, 
"defaultString...");


where 0x000 is the address obviously.

If you can spot what I'm doing wrong it would be appreciated.

[Issue 17578] Propagate the common qualifier of fields to the containing type

[via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan M Davis  ---
This seems reasonable, though I expect that it would be of limited usefulness.
Certanily, I normally recommend to people that they not make any members in a
struct const or immutable if they can help it, because it gets in the way of
basic operations like copying and assignment (e.g. not being able to assign to
a mutable struct is the sort of thing that causes confusion, but that's exactly
what happens when you have a const member variable). So, I doubt that this
change would affect much, but I see no conceptual reason why it would be a
problem, and given that you've created this enhancement, I expect that you've
found at least one use case where it makes sense.

--

Re: regressions

[H. S. Teoh via Digitalmars-d]

On Sat, Jul 01, 2017 at 12:57:35AM +0200, ag0aep6g via Digitalmars-d wrote:
> On 06/30/2017 02:48 PM, Martin Krejcirik wrote:
> > DMD, Phobos and Druntime open regressions over time:
> > 
> > http://bid.iline.cz/~mk/tmp/regs.png
> > 
> > Used to be stable, but seems to be getting worse since 2016.
> 
> It's probably no coincidence that Kenji's last commits have been in
> 2016:
> 
> https://github.com/dlang/dmd/commits/master?author=9rnsr

Whatever happened to Kenji?  He just kinda went missing without any
notice... and then popped in after a few months saying he's back, but
then he disappeared again and we never heard from him again.


T

-- 
Right now I'm having amnesia and deja vu at the same time. I think I've 
forgotten this before.

[Issue 17577] 20%+ Performance degradation in std.conv.to due to 'import std.getopt'

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 17563] gc_inFinalizer should be public

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 16657] alias this interacts with generated opCmp and opEquals

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 17578] Propagate the common qualifier of fields to the containing type

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

Re: regressions

[ag0aep6g via Digitalmars-d]

On 06/30/2017 02:48 PM, Martin Krejcirik wrote:

DMD, Phobos and Druntime open regressions over time:

http://bid.iline.cz/~mk/tmp/regs.png

Used to be stable, but seems to be getting worse since 2016.


It's probably no coincidence that Kenji's last commits have been in 2016:

https://github.com/dlang/dmd/commits/master?author=9rnsr

Re: mysql-native + vibe.d example

[crimaniak via Digitalmars-d-learn]

On Friday, 30 June 2017 at 16:18:33 UTC, tetyys wrote:

On Friday, 30 June 2017 at 00:52:28 UTC, crimaniak wrote:

Hi!
Moving my project from mysql-lited to mysql-native I faced the 
problem with null pointer error inside of mysql-native:




seems like it's already fixed 
https://github.com/mysql-d/mysql-native/commit/477636ad92a15d504308d1893f987685cd71


Yes, this is relevant fix. Thanks!

Re: Documentation licence

[Seb via Digitalmars-d]

On Friday, 30 June 2017 at 11:14:32 UTC, ANtlord wrote:

On Friday, 30 June 2017 at 10:24:34 UTC, tetyys wrote:

On Friday, 30 June 2017 at 10:10:14 UTC, ANtlord wrote:
Hello! I use service devdocs.io for some technologies. And I 
think that I able to add D to this service. I've read the 
project's wiki 
(https://github.com/Thibaut/devdocs/blob/master/CONTRIBUTING.md) and see the next:


Important: the documentation's license must permit 
alteration, redistribution and commercial use, and the 
documented software must be released under an open source 
license.


Due to this I get the question. Do the licence of D's 
documentaion and the licence of D allow to add the D's 
library documentation to devdocs.io?


Thanks. Sorry if my english is not clear.


Well as phobos source code comments is the documentation for 
standard library and it's licensed under Boost license 
(https://github.com/dlang/phobos/blob/master/LICENSE_1_0.txt), 
I think yes.


Ok. Also I see it on the page 
https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses


I hope it will not block me to contribute D's docs. Thanks a 
lot!


The Boost license is actually quite readable by humans (see 
below).


Please let us know if you run into any problems with the 
integration. Devdocs integration is on our radar [1], but time is 
inherently limited :/
-> thanks a lot for pushing this and we are more than happy to 
help if you run into troubles.


[1] https://trello.com/c/kbB0yIdE/112-devdocsio-integration

---

Boost Software License - Version 1.0 - August 17th, 2003

Permission is hereby granted, free of charge, to any person or 
organization
obtaining a copy of the software and accompanying documentation 
covered by
this license (the "Software") to use, reproduce, display, 
distribute,
execute, and transmit the Software, and to prepare derivative 
works of the
Software, and to permit third-parties to whom the Software is 
furnished to

do so, all subject to the following:

The copyright notices in the Software and this entire statement, 
including
the above license grant, this restriction and the following 
disclaimer,
must be included in all copies of the Software, in whole or in 
part, and
all derivative works of the Software, unless such copies or 
derivative
works are solely in the form of machine-executable object code 
generated by

a source language processor.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN 
NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE 
BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR 
OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE 
USE OR OTHER

DEALINGS IN THE SOFTWARE.

Re: Graph rendering on dlang.org

[Brian Schott via Digitalmars-d]

On Friday, 30 June 2017 at 21:55:34 UTC, Andrei Alexandrescu 
wrote:
Whoa, pretty nice: http://erdani.com/conversions.svg. How do I 
place the whole thing upside down? Thanks! -- Andrei


digraph "conversion" {
   rankdir="BT";
   ...
}

Re: Graph rendering on dlang.org

[H. S. Teoh via Digitalmars-d]

On Fri, Jun 30, 2017 at 05:55:34PM -0400, Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 06/30/2017 05:52 PM, Brian Schott wrote:
> > On Friday, 30 June 2017 at 21:40:05 UTC, Andrei Alexandrescu wrote:
> > > What would be a nice tool to render this DAG online? Who'd want to
> > > work on inserting this? Ideally it would be some vector rendering.
> > 
> > Graphviz's "dot" tool can output svg.
> > 
> > 
> > digraph "conversions" {
> >  "mutable" -> "const";
> >  "inout const" -> "const";
> >  "inout" -> "inout const";
> >  "immutable" -> "inout const";
> >  "immutable" -> "inout shared const";
> >  "inout shared" -> "inout shared const";
> >  "shared" -> "shared const";
> >  "inout shared const" -> "shared const";
> > }
> > 
> > dot -Tsvg conversions.dot > conversions.svg
> 
> Whoa, pretty nice: http://erdani.com/conversions.svg. How do I place the
> whole thing upside down? Thanks! -- Andrei

Like this:

digraph {
edge[dir="back"];
const;
const -> mutable;
const -> "inout const";
const -> inout;
"inout const" -> immutable;
"inout shared const" -> immutable;
"inout shared const" -> "inout shared";
"shared const" -> "inout shared const";
"shared const" -> shared;
}


T

-- 
Freedom: (n.) Man's self-given right to be enslaved by his own depravity.

Re: Graph rendering on dlang.org

[Andrei Alexandrescu via Digitalmars-d]

On 06/30/2017 05:52 PM, Brian Schott wrote:

On Friday, 30 June 2017 at 21:40:05 UTC, Andrei Alexandrescu wrote:
What would be a nice tool to render this DAG online? Who'd want to 
work on inserting this? Ideally it would be some vector rendering.


Graphviz's "dot" tool can output svg.


digraph "conversions" {
 "mutable" -> "const";
 "inout const" -> "const";
 "inout" -> "inout const";
 "immutable" -> "inout const";
 "immutable" -> "inout shared const";
 "inout shared" -> "inout shared const";
 "shared" -> "shared const";
 "inout shared const" -> "shared const";
}

dot -Tsvg conversions.dot > conversions.svg


Whoa, pretty nice: http://erdani.com/conversions.svg. How do I place the 
whole thing upside down? Thanks! -- Andrei

Re: Graph rendering on dlang.org

[Brian Schott via Digitalmars-d]

On Friday, 30 June 2017 at 21:40:05 UTC, Andrei Alexandrescu 
wrote:
What would be a nice tool to render this DAG online? Who'd want 
to work on inserting this? Ideally it would be some vector 
rendering.


Graphviz's "dot" tool can output svg.


digraph "conversions" {
"mutable" -> "const";
"inout const" -> "const";
"inout" -> "inout const";
"immutable" -> "inout const";
"immutable" -> "inout shared const";
"inout shared" -> "inout shared const";
"shared" -> "shared const";
"inout shared const" -> "shared const";
}

dot -Tsvg conversions.dot > conversions.svg

Re: Strange Bug in LDC vs DMD

[FoxyBrown via Digitalmars-d-learn]

On Friday, 30 June 2017 at 20:13:37 UTC, H. S. Teoh wrote:
On Fri, Jun 30, 2017 at 07:57:22PM +, FoxyBrown via 
Digitalmars-d-learn wrote: [...]

[...]


Um... the docs explicit say that dirEntries is lazy, did you 
not see that?


[...]


It is possible that dmd has the same problem but I did not see 
it. What I did was develop it using dmd then once it was working 
went to release ldc and saw that it immediately did not have the 
same results and the results were wrong.
Since I was debugging it the whole time and it was working fine 
with dmd, I simply assumed dmd was working.


Since it is a lazy range, I'm sure that is the problem.

Graph rendering on dlang.org

[Andrei Alexandrescu via Digitalmars-d]

Currently we have a nice table at 
https://dlang.org/spec/const3.html#implicit_conversions documenting how 
implicit conversions work across qualifiers. While complete and 
informative, it doesn't quickly give an intuition.


A DAG like the sketch at http://imgur.com/a/VuxLT would be easy to 
follow - all paths are possible conversions.


What would be a nice tool to render this DAG online? Who'd want to work 
on inserting this? Ideally it would be some vector rendering.



Thanks,

Andrei

Re: ReadProcessMemory + address from ollydbg

[ag0aep6g via Digitalmars-d-learn]

On Friday, 30 June 2017 at 20:14:15 UTC, bauss wrote:

This is my definition:
BOOL ReadProcessMemory(HANDLE hProcess, LPCVOID lpBaseAddress, 
LPVOID lpBuffer, SIZE_T nSize, SIZE_T *lpNumberOfBytesRead);


And I'm reading it like this:
if (!ReadProcessMemory(process,
  cast(PCVOID)address, cast(PVOID),
  cast(DWORD)stringSize, cast(PDWORD))) {
  return defaultValue;
}


I guess the first cast is necessary when `address` isn't typed as 
a pointer yet. But the other casts shouldn't be needed. If you 
get errors without them, those errors might give a hint on what's 
wrong.



process is a HANDLE that I got from OpenProcess()
address is a DWORD
data is char[1024]
stringSize is size_t
bytesRead is PDWORD


bytesRead is a SIZE_T, no? Or maybe a DWORD.

Propagate the common qualifier of fields to the containing type

[Andrei Alexandrescu via Digitalmars-d]

This should make life a lot easier for things like shared allocators and 
qualified types in general:


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

Andrei

[Issue 17578] New: Propagate the common qualifier of fields to the containing type

[via Digitalmars-d-bugs]

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

  Issue ID: 17578
   Summary: Propagate the common qualifier of fields to the
containing type
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

This is a language enhancement that simplifies the use of qualifiers and
eliminates the necessity of boilerplate code.

Consider:

struct Widget
{
// state {
immutable int a;
immutable double b;
// } state
void fun() { ... }
void gun() immutable { ... }
}

The important tidbit is that all fields have the immutable qualifier. Now fun
can only be called against a mutable Widget, whereas gun can only be called
against an immutable Widget. However, note that the difference between Widget
and immutable(Widget) is artificial because fun and gun have the same exact
constraints. Even though type Widget is de jure "mutable", no mutation can be
done within it.

This proposes that Widget and immutable(Widget) are the same type, i.e. the
artificial distinction between the two types is removed. That means the two may
be use interchangeably, same as e.g. applying immutable(T) to a template
parameter T that already was immutable yields T.

This enhancement relaxes constraints on qualified functions (both free and
methods) and eliminate the need for copies, casts, and boilerplate to vacuously
adjust qualifiers.

There is generalization to all qualifiers and also to combinations of
qualifiers. Consider:

struct Midget
{
// state {
immutable int a;
const double b;
// } state
...
}

In this case, the common qualifier of const and immutable is const, so Midget
and const(Midget) are the same type.

The rules for figuring the common qualifier of all fields in an object are
derived from https://dlang.org/spec/const3.html#implicit_conversions.

--

[Issue 17574] Range violation in std.getopt:getopt AA parsing

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/bb0340766b4810fd72f92d2a55981aba8006396e
Fix issue 17574 - Avoid range error by checking the result of indexOf

https://github.com/dlang/phobos/commit/700d44da1d104c03b5553cb9f636433b9be3434d
Merge pull request #5525 from Hackerpilot/issue-17574

Fix issue 17574 - Avoid range error by checking the result of indexOf
merged-on-behalf-of: H. S. Teoh 

--

[Issue 17574] Range violation in std.getopt:getopt AA parsing

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Go 1.9

[bachmeier via Digitalmars-d]

On Tuesday, 27 June 2017 at 02:40:37 UTC, jmh530 wrote:

On Tuesday, 27 June 2017 at 02:38:31 UTC, bachmeier wrote:


I'll post here after updating and testing the embedr package.


Great. I'll give it a go again when it's ready.


An update. It looks like I will be able to get all of my research 
programs to work on Windows. It might be easier to use D in R 
packages on Windows than to use C/C++/Fortran because there is no 
need to mess with R tools, which many end users find confusing. 
The final piece of the puzzle would be an LDC installer for 
Windows that puts it in the path. Then it would definitely be 
easier to use D than C/C++/Fortran.

Re: Strange Bug in LDC vs DMD

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

On Fri, Jun 30, 2017 at 07:57:22PM +, FoxyBrown via Digitalmars-d-learn 
wrote:
[...]
> The only way this can happen is if the rename command is somehow
> feeding back in to the algorithm. Since the problem goes away when I
> pre-compute dirEntries, it suggests that dirEntries is being lazily
> computed.

Um... the docs explicit say that dirEntries is lazy, did you not see
that?

https://dlang.org/phobos/std_file#dirEntries

"Returns an input range of DirEntry that *lazily* iterates a given
directory, ..." [emphasis mine]


[...]
> I'm pretty sure that the analysis above is correct, that is,
> dirEntries is lazy and ends up picking up the renamed file. This is
> sort of like removing an element in an array while iterating over the
> array.

This is certainly what it looks like; however, it doesn't explain a
couple of things:

1) Why the DMD version appears to be unaffected, since as far as I can
tell from the code, it is also a lazy iteration;

2) On Linux at least, renaming a file does not move the location of the
entry in the directory, so whether dirEntries is lazy or not shouldn't
even matter in the first place.

Does Windows reorder the directory when you rename files? E.g., if you
set the folder to sort alphabetically, does it actually sort the
directory, or does it only sort the GUI output?  My guess is that the
sort order only affects the GUI output, as it would be grossly
inefficient to actually sort the directory. But you never know with
Windows...  In any case, if Windows *does* physically sort the folder,
that could explain how rename() affects dirEntries.  However, this still
doesn't explain the discrepancy between DMD and LDC.

Actually, now that I think of it... Linux may do the same thing if the
new filename is longer and doesn't fit in the old slot. So that could
explain (2).  However, why the difference between DMD and LDC?  It
doesn't make sense to me, if you tested both on the same OS.

Here's a way to rule out (2): instead of using the current working
directory, change the code to create a fresh copy of the directory each
time.  Does DMD / LDC still show a difference?  The idea here is that it
may have been a coincidence that you saw LDC having the problem and DMD
not, since whether or not a renamed file gets moved depends on how big
the current slot for its name is in the directory, and if you've already
done a bunch of operations on the directory, some slots will be bigger
and some will be smaller, so some renames will happen in-place whereas
others will cause a reordering.  It could be you just got unlucky with
LDC and caused a reordering, whereas you got lucky with DMD and the
existing slots were already big enough so the problem isn't visible.

OTOH, this still doesn't explain why calling the OS functions directly
fixes the problem.  If there is a bug in LDC's version of dirEntries
somewhere, we'd like to know about it so that we can fix it.


T

-- 
Without outlines, life would be pointless.

ReadProcessMemory + address from ollydbg

[bauss via Digitalmars-d-learn]

I'm currently getting garbage data when using ReadProcessMemory 
to read from another process.


This is my definition:
BOOL ReadProcessMemory(HANDLE hProcess, LPCVOID lpBaseAddress, 
LPVOID lpBuffer, SIZE_T nSize, SIZE_T *lpNumberOfBytesRead);


And I'm reading it like this:
if (!ReadProcessMemory(process,
  cast(PCVOID)address, cast(PVOID),
  cast(DWORD)stringSize, cast(PDWORD))) {
  return defaultValue;
}

process is a HANDLE that I got from OpenProcess()
address is a DWORD
data is char[1024]
stringSize is size_t
bytesRead is PDWORD

The address I obtained was from Ollydbg and it's a static 
address. I'm not sure if I however need some kind of offset etc.


I tried to search and found you might have to use 
GetModuleHandleA() but I tried that and I still get garbage data 
with the offset from that.


What am I doing wrong?

Natural Sort optimzation

[FoxyBrown via Digitalmars-d-learn]

Spent the last hour trying to get a natural sort. Ended up having 
to create my own(not sure if it's 100% correct though but works 
in practice). The Rosetta one is not correct.


Here is my implementation, anyone care to perfect it?

// Compares the strings a and b numerically, e.g., "04038284" and 
"02"  returns 1, the first is larger.

int compareStringNum(string a, string b)
{
// Remove leading 0's
a = a.stripLeft('0');
b = b.stripLeft('0');
if (a.length > b.length) return 1;
if (a.length < b.length) return -1;
auto m = a.length;
for(int i = 0; i < m; i++)
{
auto qqx = a[i];
auto qqy = b[i];
// Assume ascii comparision holds, i.e., '0' < '1' < ... < '9'
if (a[i] > b[i]) return 1;
if (a[i] < b[i]) return -1;
}

return 0;
}

string[] naturalSort(string[] arr) /*pure @safe*/
{
alias myComp = (x, y) {
auto ml = min(x.length, y.length)-1;
auto ofsx = -1; auto ofsy = -1;
auto numx_found = -1;
auto numy_found = -1;
for(int i = 0; i < ml; i++)
{
ofsx++;
ofsy++;

			// If we have not found any numbers(that are not the same) and 
we have a difference, the strings must be different, fall back on 
standard character comparer
			if (!isDigit(x[ofsx]) && !isDigit(y[ofsy]) && x[ofsx] != 
y[ofsy] && numx_found < 0 && numy_found < 0)

return x[ofsx] > y[ofsy];

			// We are at a position in the string where either we are at 
the end of a digit sequence or the characters have been identical 
up to this point

if (isDigit(x[ofsx]) && numx_found < 0) numx_found = 
ofsx;
if (isDigit(y[ofsy]) && numy_found < 0) numy_found = 
ofsy;

			if (!isDigit(x[ofsx]) && !isDigit(y[ofsy]) && numx_found >= 0 
&& numy_found >= 0)

{
auto numx = x[numx_found..ofsx];
auto numy = y[numy_found..ofsy];
auto res = compareStringNum(numx, numy);

if (res != 0) return (res != 1);
}

if (!isDigit(x[ofsx]) && !isDigit(y[ofsy]))
{
numx_found = -1;
numy_found = -1;
} else
{
if (!isDigit(x[ofsx]) && numx_found >= 0) 
ofsx--;
if (!isDigit(y[ofsy]) && numy_found >= 0) 
ofsy--;
}


}

return x > y;
};

auto x = arr.sort!(myComp).release;
return x;
}

Re: Strange Bug in LDC vs DMD

[FoxyBrown via Digitalmars-d-learn]

On Friday, 30 June 2017 at 17:32:33 UTC, H. S. Teoh wrote:
On Fri, Jun 30, 2017 at 12:50:24PM +, FoxyBrown via 
Digitalmars-d-learn wrote:

I am using dirEntries to iterate over files to rename them.

I am renaming them in a loop(will change but added code for 
testing).



In DMD the renaming works but in LDC the renaming fails. It 
fails in a way that I can't quite tell and I cannot debug 
because visual D is not working properly for LDC.


The code essentially look like the following:


auto dFiles = dirEntries(loc, mask, _mode);

foreach (d; dFiles)
{

   auto newName = Recompute(d.name)
   writeln(newName);
   rename(d.name, newName);
}

but when I comment out rename, it works under LDC.

The funny thing is, newName is printed wrong so Recompute is 
effected by the rename.


This shouldn't occur.

[...]

This sounds very strange.  What exactly do you mean by "newName 
is printed wrong"? Do you mean that somehow it's getting 
affected by the *subsequent* rename()?  That would be truly 
strange.  Or do you mean that newName doesn't match what you 
expect Recompute to do given d.name? Perhaps you should also 
print out d.name along with newName just to be sure?


Do you have a reduced code example that's compilable/runnable?  
It's rather hard to tell what's wrong based on your incomplete 
snippet.



T


No, if I simply comment out the rename line, then the writeln 
output changes. Simple as that. No other logic changes in the 
code.


This means that the rename is affecting the output. The recompute 
code gets the filename, does a computation on it, then returns 
it.. prints it out, then renames that file to the newly computed 
file name.


The only way this can happen is if the rename command is somehow 
feeding back in to the algorithm. Since the problem goes away 
when I pre-compute dirEntries, it suggests that dirEntries is 
being lazily computed. If that is the case, then the problem is 
easily understood: The file gets renamed, dirEntries reiterates 
over the file, then it gets recomputed again, but this time the 
result is bogus because it is a double recompute, which is 
meaningless in this program.


I'm pretty sure that the analysis above is correct, that is, 
dirEntries is lazy and ends up picking up the renamed file. This 
is sort of like removing an element in an array while iterating 
over the array.


The odd thing is, is that DMD does not produce the same result. I 
do not know if there is a different in the LDC vs DMD dirEntries 
code(or lazily evaluated code in general) or if it has to do with 
speed(possibly the renames are cached and do not show up 
immediately to dirEntries with the slower DMD?).


I do not have any simplified code and I'm moving on from here. It 
should be easy to mock something up. The main thing to do is to 
rename the files based on something in the file name.


e.g., suppose you have the files 1,2,3,4,5 (that is there names)

and extract and multiply the filenames by 10. (that is your 
recompute function).


You should end up with 10,20,30,40,50.

But if the cause of issue I'm describing is in fact true, one 
don't necessarily get that because some files will be iterated 
more than once. e.g., maybe 10, 100, 1000, 20, 200, 30, 40, 50, 
500.


I am doing it over a lot of files btw, but that is essentially 
what is going on.  The example above should be easy to do since 
one can simply to!int the filename and then multiply it by 10 and 
then rename that.


I have moved on to avoid dirEntries completely and simply use the 
os directory listing function manually to extract the data but 
this should be investigated as it if it the behavior is what I am 
describing, a serious bug exists somewhere. (if someone could 
confirm that dirEntries is a lazy range, then it would explain 
the problem, but not necessarily why dmd and ldc differ, (dmd 
seeming to function as expected)).

Re: Always false float comparisons

[Ecstatic Coder via Digitalmars-d]

So what you really want is: signed array lengths. You only have 
a use for the sloppy conversion, because D doesn't have signed 
array lengths.


Yes and no. Signed safety is better, but the current behavior 
works too.


Honestly I don't care if the bit maniacs want 8 million terabytes 
more for their strings, as long as I can safely ignore that 
implementation detail.

Re: Win10 defender still sees dmd.exe and rdmd.exe as malicious

[asdf jkl via Digitalmars-d]

On Monday, 26 June 2017 at 01:58:02 UTC, Era Scarecrow wrote:

On Monday, 26 June 2017 at 01:55:56 UTC, Matt wrote:
New user here. I know the first 5 minutes experience is 
important, just to note that rdmd.exe and executables created 
with dmd.exe are flagged as malicious by windows defender. 
It's easy to create an exception in the windows defender 
settings, but I thought I would let you know.


I wouldn't be surprised if in the near future Microsoft marks 
all software 'malicious' unless it's digitally signed...


Sidenote: avast!'s CyberCapture also detects DCD-server as 
suspecious after each update

Re: What are your hopes for the future D GC

[Dmitry Olshansky via Digitalmars-d]

On 6/30/2017 5:18 PM, TheGag96 wrote:

On Thursday, 29 June 2017 at 19:19:47 UTC, Random D user wrote:

*snip*


I was actually about to make a thread about this comment:
https://www.reddit.com/r/programming/comments/2g03af/ds_garbage_collector_problem/ckent8c/


Did Andrei ever end up doing this GC rewrite, or did all of this work go
into the custom allocators? I suppose my hope for the GC is for it to be
so darn fast next to nobody complains about it. :V


My efforts are live here:
https://github.com/DmitryOlshansky/druntime/tree/vulture-gc

--
Dmitry Olshansky

Re: What are your hopes for the future D GC

[Random D user via Digitalmars-d]

On Friday, 30 June 2017 at 06:14:41 UTC, Dmitry Olshansky wrote:

On 6/29/2017 10:19 PM, Random D user wrote:
2. Composable custom memory block GC. The ability to mallocate 
128MB
memory block and create a new GC instance to manage that 
block. It would
only need to scan that 128MB block and not worry about rest of 
memory
and resources (with complex destruction orders) in 16GB heap. 
This way
you probably could guarantee good collection times for some 
subsystems

in your program and use your favorite allocator for others.



Not sure what benefit this has compared to just limiting GC 
heap to 128Mb.




More flexibility, control and tools for doing mixed memory 
management.


I was thinking that you could have multiple of these (thread 
local or single threaded, edge cases/safety would be user 
responsibility).
Basically turning gc into similar custom allocator as "bump the 
pointer" allocators or object pools. This way few of these GCs 
could be used as poor man's incremental GC.


I think it could be useful for applications that have tight 
memory and timing budgets.
For example, in games, you typically have couple bigger 
subsytems. Some game architectures preallocate all the memory 
they need and distribute it to each subsystem using custom 
allocators.
Maybe some systems with lot of small allocations could use 
"memory block local GC" and be fast enough. For example, some 
sort of a scripting or debug console subsytem could be fine with 
32MB, but you wouldn't need care about releasing your temp 
objects. Small heap size would guarantee fast collections.
And for some sort of incremental emulation you could manually 
trigger the collections and cycle between different local GC per 
frame or timestep. Also if any of the would pause for too long, 
you could easily just see which one and fix it.

[Issue 16657] alias this interacts with generated opCmp and opEquals

[via Digitalmars-d-bugs]

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

--- Comment #7 from Eyal  ---
Awesome, thanks!

--

Re: How to partially apply member functions?

[Ali Çehreli via Digitalmars-d-learn]

On 06/30/2017 01:43 AM, ct wrote:

> entry_.addOnNextMatch(partial!(, true));

Just to note, member function pointers are delegates in D, which 
combines the 'this' pointer of the object and a context pointer. Since 
the object is available at run time, such a delegate cannot be used as a 
template parameter.


partial is designed to work with free standing functions. It uses the 
second template argument as the first parameter to the function. So, 
there is no consideration for member function calls. Perhaps partial can 
be improved to handle that case but I don't know whether the 'this' 
pointer can be added to the delegate easily or at all.


Ali

Re: What are your hopes for the future D GC

[Dmitry Olshansky via Digitalmars-d]

On 6/30/2017 7:54 PM, H. S. Teoh via Digitalmars-d wrote:

On Fri, Jun 30, 2017 at 09:14:41AM +0300, Dmitry Olshansky via Digitalmars-d 
wrote:

On 6/29/2017 10:19 PM, Random D user wrote:

I just got curious, after reading the GC analysis blog post. What
kind of features people generally would want for the GC (in the
distant murky future of 1999)?

Here's some of my nice to haves:

1. Thread local GCs. D is by default thread local, so it kind of
would make sense and goodbye stop everything GC.


Yes, yes and yes. The moment we fix the spec and code that casts
shared to TLS at will.


Hmm.  I'm not familiar with the intricacies of shared; could you
elaborate on how casting from shared causes problems with a thread-local
GC?  Or is the problem casting *from* shared?


T


Seems like my first post went into aether, sorry if double posting.

The problem is generally with transfer of things from one thread to 
another. Currently this is done with good natured casts such as 
assumeUnique. The GC needs to be in the know of what is transferred to who.



--
Dmitry Olshansky

Re: Force usage of double (instead of higher precision)

[kinke via Digitalmars-d-learn]

On Friday, 30 June 2017 at 16:39:16 UTC, Stefan Koch wrote:

On Friday, 30 June 2017 at 16:29:22 UTC, kinke wrote:

On Friday, 30 June 2017 at 16:21:18 UTC, kinke wrote:
CTFE only (incl. parsing of literals). Just make sure you 
don't happen to call a std.math function only accepting 
reals; I don't know how many of those are still around.


Oh, apparently most still are. There are even some mean 
overloads for double/float only casting and forwarding to the 
`real` implementation.


That is not a problem.
The only problem is that the excess is not discarded at the 
end. Which is because of the design of the constant-folder.


I was referring to runtime performance, as that was what Luis was 
concerned about.

Re: Strange Bug in LDC vs DMD

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

On Fri, Jun 30, 2017 at 12:50:24PM +, FoxyBrown via Digitalmars-d-learn 
wrote:
> I am using dirEntries to iterate over files to rename them.
> 
> I am renaming them in a loop(will change but added code for testing).
> 
> 
> In DMD the renaming works but in LDC the renaming fails. It fails in a
> way that I can't quite tell and I cannot debug because visual D is not
> working properly for LDC.
> 
> The code essentially look like the following:
> 
> 
>   auto dFiles = dirEntries(loc, mask, _mode);
>   
>   foreach (d; dFiles)
>   {   
> 
>auto newName = Recompute(d.name)
>writeln(newName);
>rename(d.name, newName);
> }
> 
> but when I comment out rename, it works under LDC.
> 
> The funny thing is, newName is printed wrong so Recompute is effected
> by the rename.
> 
> This shouldn't occur.
[...]

This sounds very strange.  What exactly do you mean by "newName is
printed wrong"? Do you mean that somehow it's getting affected by the
*subsequent* rename()?  That would be truly strange.  Or do you mean
that newName doesn't match what you expect Recompute to do given d.name?
Perhaps you should also print out d.name along with newName just to be
sure?

Do you have a reduced code example that's compilable/runnable?  It's
rather hard to tell what's wrong based on your incomplete snippet.


T

-- 
An imaginary friend squared is a real enemy.

Re: Contribution to portuguese translation of D documentation

[Seb via Digitalmars-d]

On Friday, 30 June 2017 at 16:42:17 UTC, Daniel Vieira wrote:

Hello Fellows, how are you?

I was browsing through the D site and I saw there is an ongoing 
effort to translate D documentation to several languages (Learn 
section of the website).


I couldn't help to notice there are some minor mistakes in the 
Brazilian Portuguese translation, as well most of the material 
is not translated yet.


How may I collaborate with the translation?

I live in São Paulo, Brazil and I'd love to collaborate!


That's great to hear!
I guess you are talking about the DLang Tour? 
(https://tour.dlang.org)

Either click on "edit" at the Portuguese translation:

https://tour.dlang.org/tour/pt/welcome/welcome-to-d

Or collaborate on GitHub directly:

https://github.com/dlang-tour/portuguese

Re: regressions

[jmh530 via Digitalmars-d]

On Friday, 30 June 2017 at 16:44:54 UTC, Seb wrote:


Btw, in case anyone wants to prevent regressions for their 
project(s). There are two easy ways:


1) Add it to the Project-Tester which is run on _every_ PR for 
{dmd,druntime,phobos} (-> make a PR to dlang/ci)
2) Enable daily crons [1] and add `dlang-nightly` to your list 
of D compilers on Travis



[1] https://blog.travis-ci.com/2016-12-06-the-crons-are-here


Blog post worthy?

Re: [WIP] A Big O notation and algebra for D

[Mark via Digitalmars-d]

On Friday, 30 June 2017 at 16:28:18 UTC, Andrei Alexandrescu 
wrote:

On 06/30/2017 12:01 PM, Mark wrote:
On Sunday, 18 December 2016 at 18:26:27 UTC, Andrei 
Alexandrescu wrote:
Article: http://erdani.com/d/bigo.html (do not publish; 
should do it with Mike)


Code (preliminary): https://github.com/dlang/phobos/pull/4965


Andrei


Was this project abandoned? It's no longer in std/experimental.


I'll get to it. -- Andrei


No hurry. It just seemed really interesting. :)

Re: What are your hopes for the future D GC

[H. S. Teoh via Digitalmars-d]

On Fri, Jun 30, 2017 at 09:14:41AM +0300, Dmitry Olshansky via Digitalmars-d 
wrote:
> On 6/29/2017 10:19 PM, Random D user wrote:
> > I just got curious, after reading the GC analysis blog post. What
> > kind of features people generally would want for the GC (in the
> > distant murky future of 1999)?
> > 
> > Here's some of my nice to haves:
> > 
> > 1. Thread local GCs. D is by default thread local, so it kind of
> > would make sense and goodbye stop everything GC.
> 
> Yes, yes and yes. The moment we fix the spec and code that casts
> shared to TLS at will.

Hmm.  I'm not familiar with the intricacies of shared; could you
elaborate on how casting from shared causes problems with a thread-local
GC?  Or is the problem casting *from* shared?


T

-- 
Gone Chopin. Bach in a minuet.

[Issue 16657] alias this interacts with generated opCmp and opEquals

[via Digitalmars-d-bugs]

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

--- Comment #6 from Andrei Alexandrescu  ---
Upon further consideration we need to fix this. Requiring people who use the
"alias this" feature to also remember to define "opEquals" is the kind of
long-distance dependency that is the subject of "Effective D" tidbits of advice
of the exact kind we do our best to avoid.

--

Re: Contribution to portuguese translation of D documentation

[bachmeier via Digitalmars-d]

On Friday, 30 June 2017 at 16:42:17 UTC, Daniel Vieira wrote:

Hello Fellows, how are you?

I was browsing through the D site and I saw there is an ongoing 
effort to translate D documentation to several languages (Learn 
section of the website).


I couldn't help to notice there are some minor mistakes in the 
Brazilian Portuguese translation, as well most of the material 
is not translated yet.


How may I collaborate with the translation?

I live in São Paulo, Brazil and I'd love to collaborate!


There's a little edit icon next to the code box. If you want to 
make minor changes, that is much easier.

Re: Get Function Body

[bauss via Digitalmars-d-learn]

On Friday, 30 June 2017 at 16:43:33 UTC, Stefan Koch wrote:

On Friday, 30 June 2017 at 16:38:45 UTC, bauss wrote:

Is there a way to retrieve the body of a function as a string?

Scenario.

I want to pass a function to a mixin template and just mixin 
the body of the function.


Ex.

mixin template Foo(alias fun) {
void bar() {
mixin(getBodyOfFun(fun));
}
}

I'm aware that I can pass a string like mixin Foo!"a > b" but 
I would really like to avoid that.


I also can't just call "fun" as normal, unless it can be 
forced to be inline within the mixin template. The reason is 
if I mixin two mixin templates with the same function passed 
it must exist as two different function bodies executed, even 
tho they do the same.


Which means the following must have two "different" baz and 
not the actual baz.


void baz() { ... }

mixin Foo!baz;
mixin Foo!baz;

I don't know if it'll be possible without some sort of 
"parsing" the function or even without "string function 
bodies".


You need to function body as a string.
There is no way of retriving a functionBodyString from the 
compiler.

And I suspect it would be a bad idea to be able to do so.
Since the compiler may mutate the body while 
processing/optimizing.


Well in my case I don't want optimization or anything like that, 
in fact the original function wouldn't matter at all. I guess 
I'll go with the string way then though.


I'm aware this is probably not a scenario day-to-day code will 
need, but in my case I need to make my program as obscure as 
possible.

Re: regressions

[Seb via Digitalmars-d]

On Friday, 30 June 2017 at 12:48:12 UTC, Martin Krejcirik wrote:

DMD, Phobos and Druntime open regressions over time:

http://bid.iline.cz/~mk/tmp/regs.png

Used to be stable, but seems to be getting worse since 2016.


I think this depends on your PoV. Thanks to the growing community 
and more automation (Project-Tester, Martin's nightly build and 
finally daily crons on Travis [1]), it's a lot easier to detect 
regressions.


Btw, in case anyone wants to prevent regressions for their 
project(s). There are two easy ways:


1) Add it to the Project-Tester which is run on _every_ PR for 
{dmd,druntime,phobos} (-> make a PR to dlang/ci)
2) Enable daily crons [1] and add `dlang-nightly` to your list of 
D compilers on Travis



[1] https://blog.travis-ci.com/2016-12-06-the-crons-are-here

Contribution to portuguese translation of D documentation

[Daniel Vieira via Digitalmars-d]

Hello Fellows, how are you?

I was browsing through the D site and I saw there is an ongoing 
effort to translate D documentation to several languages (Learn 
section of the website).


I couldn't help to notice there are some minor mistakes in the 
Brazilian Portuguese translation, as well most of the material is 
not translated yet.


How may I collaborate with the translation?

I live in São Paulo, Brazil and I'd love to collaborate!

Re: Get Function Body

[Stefan Koch via Digitalmars-d-learn]

On Friday, 30 June 2017 at 16:38:45 UTC, bauss wrote:

Is there a way to retrieve the body of a function as a string?

Scenario.

I want to pass a function to a mixin template and just mixin 
the body of the function.


Ex.

mixin template Foo(alias fun) {
void bar() {
mixin(getBodyOfFun(fun));
}
}

I'm aware that I can pass a string like mixin Foo!"a > b" but I 
would really like to avoid that.


I also can't just call "fun" as normal, unless it can be forced 
to be inline within the mixin template. The reason is if I 
mixin two mixin templates with the same function passed it must 
exist as two different function bodies executed, even tho they 
do the same.


Which means the following must have two "different" baz and not 
the actual baz.


void baz() { ... }

mixin Foo!baz;
mixin Foo!baz;

I don't know if it'll be possible without some sort of 
"parsing" the function or even without "string function bodies".


You need to function body as a string.
There is no way of retriving a functionBodyString from the 
compiler.

And I suspect it would be a bad idea to be able to do so.
Since the compiler may mutate the body while 
processing/optimizing.

Re: Force usage of double (instead of higher precision)

[Stefan Koch via Digitalmars-d-learn]

On Friday, 30 June 2017 at 16:29:22 UTC, kinke wrote:

On Friday, 30 June 2017 at 16:21:18 UTC, kinke wrote:
CTFE only (incl. parsing of literals). Just make sure you 
don't happen to call a std.math function only accepting reals; 
I don't know how many of those are still around.


Oh, apparently most still are. There are even some mean 
overloads for double/float only casting and forwarding to the 
`real` implementation.


That is not a problem.
The only problem is that the excess is not discarded at the end. 
Which is because of the design of the constant-folder.

Get Function Body

[bauss via Digitalmars-d-learn]

Is there a way to retrieve the body of a function as a string?

Scenario.

I want to pass a function to a mixin template and just mixin the 
body of the function.


Ex.

mixin template Foo(alias fun) {
void bar() {
mixin(getBodyOfFun(fun));
}
}

I'm aware that I can pass a string like mixin Foo!"a > b" but I 
would really like to avoid that.


I also can't just call "fun" as normal, unless it can be forced 
to be inline within the mixin template. The reason is if I mixin 
two mixin templates with the same function passed it must exist 
as two different function bodies executed, even tho they do the 
same.


Which means the following must have two "different" baz and not 
the actual baz.


void baz() { ... }

mixin Foo!baz;
mixin Foo!baz;

I don't know if it'll be possible without some sort of "parsing" 
the function or even without "string function bodies".

Re: [WIP] A Big O notation and algebra for D

[Andrei Alexandrescu via Digitalmars-d]

On 06/30/2017 12:01 PM, Mark wrote:

On Sunday, 18 December 2016 at 18:26:27 UTC, Andrei Alexandrescu wrote:
Article: http://erdani.com/d/bigo.html (do not publish; should do it 
with Mike)


Code (preliminary): https://github.com/dlang/phobos/pull/4965


Andrei


Was this project abandoned? It's no longer in std/experimental.


I'll get to it. -- Andrei

Re: Force usage of double (instead of higher precision)

[kinke via Digitalmars-d-learn]

On Friday, 30 June 2017 at 16:21:18 UTC, kinke wrote:
CTFE only (incl. parsing of literals). Just make sure you don't 
happen to call a std.math function only accepting reals; I 
don't know how many of those are still around.


Oh, apparently most still are. There are even some mean overloads 
for double/float only casting and forwarding to the `real` 
implementation.

Re: Force usage of double (instead of higher precision)

[kinke via Digitalmars-d-learn]

On Friday, 30 June 2017 at 11:42:39 UTC, Luis wrote:

On Thursday, 29 June 2017 at 12:00:53 UTC, Simon Bürger wrote:

Thanks a lot for your comments.

On Wednesday, 28 June 2017 at 23:56:42 UTC, Stefan Koch wrote:

[...]



This is only happening on CTFE ? Enforcing to use the old 8086 
FPU for any float/double operation would give a lot performance 
penalty on any modern CPU.


CTFE only (incl. parsing of literals). Just make sure you don't 
happen to call a std.math function only accepting reals; I don't 
know how many of those are still around.

Re: mysql-native + vibe.d example

[tetyys via Digitalmars-d-learn]

On Friday, 30 June 2017 at 00:52:28 UTC, crimaniak wrote:

Hi!
Moving my project from mysql-lited to mysql-native I faced the 
problem with null pointer error inside of mysql-native:




seems like it's already fixed 
https://github.com/mysql-d/mysql-native/commit/477636ad92a15d504308d1893f987685cd71

Re: [WIP] A Big O notation and algebra for D

[Mark via Digitalmars-d]

On Sunday, 18 December 2016 at 18:26:27 UTC, Andrei Alexandrescu 
wrote:
Article: http://erdani.com/d/bigo.html (do not publish; should 
do it with Mike)


Code (preliminary): https://github.com/dlang/phobos/pull/4965


Andrei


Was this project abandoned? It's no longer in std/experimental.

Re: Strange Bug in LDC vs DMD

[FoxyBrown via Digitalmars-d-learn]

On Friday, 30 June 2017 at 15:07:29 UTC, Murzistor wrote:

On Friday, 30 June 2017 at 12:50:24 UTC, FoxyBrown wrote:

The funny thing is, newName is printed wrong so Recompute is 
effected by the rename.

Does LDC use Unicode?
Or, maybe, standard library under LDC does not support Unicode 
- then it is a serious bug.

Do you use any non-ASCII symbols?
Maybe, the Recompute() function returns a non-unicode string 
under LDC?


None of these reasons make sense. They do not take in to account 
that simply pre-evaluating dirEntries causes it to work nor the 
fact that I said that commenting the rename out also works.

Re: Strange Bug in LDC vs DMD

[Murzistor via Digitalmars-d-learn]

On Friday, 30 June 2017 at 12:50:24 UTC, FoxyBrown wrote:

The funny thing is, newName is printed wrong so Recompute is 
effected by the rename.

Does LDC use Unicode?
Or, maybe, standard library under LDC does not support Unicode - 
then it is a serious bug.

Do you use any non-ASCII symbols?
Maybe, the Recompute() function returns a non-unicode string 
under LDC?

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Mark via Digitalmars-d]

On Thursday, 29 June 2017 at 01:37:17 UTC, H. S. Teoh wrote:

(1) DbC contracts pertain to *runtime* argument values, so while
checking for simple cases at compile-time is nice, it isn't 
really in

the charter of (D's implementation of) DbC.


T


That's a good point.

I guess UDAs combined with static assert is the right way to 
implement compile-time checkable contracts. This seems to be the 
approach taken by Andrei in his Big O notation library [1].


Anyway, contracts are still useful for documentation purposes, as 
was pointed out. Personally I like them because they encourage me 
to think carefully about the preconditions and postconditions of 
the functions I write.


[1] 
http://forum.dlang.org/post/mailman.898.1482091540.9448.digitalmar...@puremagic.com

Re: What are your hopes for the future D GC

[TheGag96 via Digitalmars-d]

On Thursday, 29 June 2017 at 19:19:47 UTC, Random D user wrote:

*snip*


I was actually about to make a thread about this comment: 
https://www.reddit.com/r/programming/comments/2g03af/ds_garbage_collector_problem/ckent8c/


Did Andrei ever end up doing this GC rewrite, or did all of this 
work go into the custom allocators? I suppose my hope for the GC 
is for it to be so darn fast next to nobody complains about it. :V

[Issue 17563] gc_inFinalizer should be public

[via Digitalmars-d-bugs]

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

--- Comment #2 from Steven Schveighoffer  ---
ponce, it's not a slight against your mechanism. It's a problem with the API.
There is no reason you should have to go through the hoops of attempting to
allocate memory and catching an Error, just to check the value of a global
boolean. Especially when there is already a function that does just that.

--

Re: Deprecate real

[Steven Schveighoffer via Digitalmars-d]

On 6/30/17 6:49 AM, Stefan Koch wrote:

On Friday, 30 June 2017 at 10:44:41 UTC, ixid wrote:

On Friday, 30 June 2017 at 10:26:03 UTC, Nicholas Wilson wrote:

On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote:
Are there any reasons not to put real on the path to removal? The 
hardware is deprecated by both Intel and AMD and it seems like an 
unnecessary source of confusion.


Don't forget that real is only fp80 on x86. On AArch64(?) it 
is/should be fp128 which _is_ supported, there is also PowerPC double 
double.


Isn't it an objective of D to move away from such confusing types and 
have defined widths?


D does have well defined floating point types.
float and double.

real is a special type for people who know what they are dong.
And not to be removed.


Not agreeing with the OP, but annoyingly you are forced to deal with it 
even if you don't know, as all FP operations are promoted to real, even 
double + double. It's a constant source of confusion.


-Steve

Strange Bug in LDC vs DMD

[FoxyBrown via Digitalmars-d-learn]

I am using dirEntries to iterate over files to rename them.

I am renaming them in a loop(will change but added code for 
testing).



In DMD the renaming works but in LDC the renaming fails. It fails 
in a way that I can't quite tell and I cannot debug because 
visual D is not working properly for LDC.


The code essentially look like the following:


auto dFiles = dirEntries(loc, mask, _mode);

foreach (d; dFiles)
{   

   auto newName = Recompute(d.name)
   writeln(newName);
   rename(d.name, newName);
}

but when I comment out rename, it works under LDC.

The funny thing is, newName is printed wrong so Recompute is 
effected by the rename.


This shouldn't occur.

Now, dirEntries is a range, so I'm curious if the recomputation 
is occurring after the rename(if it did then the recomputation 
would be invalid and produce the results it is producing)?


When I forcably convert dirEntries in to an array(manually, 
unfortunately, as I can't seem to use array() on dirEntries), 
everything works).



struct file { public string name; }

auto dFiles = dirEntries(loc, mask, _mode);

file[] files;

foreach (d; dFiles)
{
file f;
f.name = d.name;
files ~= f;
}

foreach (d; files)
{   

   auto newName = Recompute(d.name)
   writeln(newName);
   rename(d.name, newName);
}

While it works, the main issue is that a different behavior is 
observed between DMD and LDC in the first case.


It would be nice to know how to simplify the code though so 
"lazy" evaluation of dirEntries did not occur.

regressions

[Martin Krejcirik via Digitalmars-d]

DMD, Phobos and Druntime open regressions over time:

http://bid.iline.cz/~mk/tmp/regs.png

Used to be stable, but seems to be getting worse since 2016.

Re: Deprecate real

[jmh530 via Digitalmars-d]

On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote:
Are there any reasons not to put real on the path to removal? 
The hardware is deprecated by both Intel and AMD and it seems 
like an unnecessary source of confusion.


I've never found real confusing.

However, I do see some people confused by the fact that floating 
point operations may do intermediate steps at higher precision. 
Walter has provided the reasoning before and I think I agree with 
it. However, I think a case could be made for having an option to 
disable it and force intermediate calculations to be done at the 
precision of the type. I would consider it to be something of low 
importance, but other people might value it more.

Re: Force usage of double (instead of higher precision)

[Luis via Digitalmars-d-learn]

On Thursday, 29 June 2017 at 12:00:53 UTC, Simon Bürger wrote:

Thanks a lot for your comments.

On Wednesday, 28 June 2017 at 23:56:42 UTC, Stefan Koch wrote:

[...]



This is only happening on CTFE ? Enforcing to use the old 8086 
FPU for any float/double operation would give a lot performance 
penalty on any modern CPU.

Re: Always false float comparisons

[ag0aep6g via Digitalmars-d]

On 06/30/2017 07:38 AM, Ecstatic Coder wrote:
I'm just against putting it on by default, so that the current behavior 
is kept, because I don't see where is the language improvement in having 
to put these ugly manual conversion everywhere just because the 
string/array length was made unsigned.


So what you really want is: signed array lengths. You only have a use 
for the sloppy conversion, because D doesn't have signed array lengths.


I always use signed integers for string/array indices because unsigned 
indices become dangerous as soon as your algorithm starts to decrement 
it...


I guess they're "dangerous" because you get ulong.max instead of (a 
signed) -1? But that's exactly what happens with the implicit 
conversion, too.


At some point you have to think of that. Either when adding/subtracting 
or when comparing signed with unsigned. With a warning/error on the 
implicit conversion, you'd get a nice reminder.


By the way, std.experimental.checkedint may interesting:


import std.experimental.checkedint: checked, ProperCompare,
Saturate;

/* If negative values should not occur, throw an error on wrap
around: */
auto x = checked(size_t(0));
--x; /* error */

/* Or stop at 0: */
auto y = checked!Saturate(size_t(0));
--y; /* does nothing */
assert(y == 0); /* passes */

/* If negative values are valid, you can use proper comparisons
without sloppy implicit conversions or verbose manual ones: */
auto z = checked!ProperCompare(int(-1));
auto array = [1, 2, 3];
assert(z < array.length); /* passes */

Re: Deprecate real

[Patrick Schluter via Digitalmars-d]

On Friday, 30 June 2017 at 10:58:50 UTC, ixid wrote:

On Friday, 30 June 2017 at 10:49:19 UTC, Stefan Koch wrote:

On Friday, 30 June 2017 at 10:44:41 UTC, ixid wrote:
On Friday, 30 June 2017 at 10:26:03 UTC, Nicholas Wilson 
wrote:

On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote:
Are there any reasons not to put real on the path to 
removal? The hardware is deprecated by both Intel and AMD 
and it seems like an unnecessary source of confusion.


Don't forget that real is only fp80 on x86. On AArch64(?) it 
is/should be fp128 which _is_ supported, there is also 
PowerPC double double.


Isn't it an objective of D to move away from such confusing 
types and have defined widths?


D does have well defined floating point types.
float and double.

real is a special type for people who know what they are dong.
And not to be removed.


In that case should it not be defined to be something other 
than 80 bit doubles on x86?


The real type is defined as the highest precision a platform 
gives.
This is the legacy x87 format on x86 platform. If ever AMD or 
Intel introduced a 128bit SSEx format, real would be changed to 
use this hypothetical new format.

Re: Documentation licence

[ANtlord via Digitalmars-d]

On Friday, 30 June 2017 at 10:24:34 UTC, tetyys wrote:

On Friday, 30 June 2017 at 10:10:14 UTC, ANtlord wrote:
Hello! I use service devdocs.io for some technologies. And I 
think that I able to add D to this service. I've read the 
project's wiki 
(https://github.com/Thibaut/devdocs/blob/master/CONTRIBUTING.md) and see the next:


Important: the documentation's license must permit alteration, 
redistribution and commercial use, and the documented software 
must be released under an open source license.


Due to this I get the question. Do the licence of D's 
documentaion and the licence of D allow to add the D's library 
documentation to devdocs.io?


Thanks. Sorry if my english is not clear.


Well as phobos source code comments is the documentation for 
standard library and it's licensed under Boost license 
(https://github.com/dlang/phobos/blob/master/LICENSE_1_0.txt), 
I think yes.


Ok. Also I see it on the page 
https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses


I hope it will not block me to contribute D's docs. Thanks a lot!

Re: Deprecate real

[ixid via Digitalmars-d]

On Friday, 30 June 2017 at 10:49:19 UTC, Stefan Koch wrote:

On Friday, 30 June 2017 at 10:44:41 UTC, ixid wrote:

On Friday, 30 June 2017 at 10:26:03 UTC, Nicholas Wilson wrote:

On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote:
Are there any reasons not to put real on the path to 
removal? The hardware is deprecated by both Intel and AMD 
and it seems like an unnecessary source of confusion.


Don't forget that real is only fp80 on x86. On AArch64(?) it 
is/should be fp128 which _is_ supported, there is also 
PowerPC double double.


Isn't it an objective of D to move away from such confusing 
types and have defined widths?


D does have well defined floating point types.
float and double.

real is a special type for people who know what they are dong.
And not to be removed.


In that case should it not be defined to be something other than 
80 bit doubles on x86?

Re: Deprecate real

[Stefan Koch via Digitalmars-d]

On Friday, 30 June 2017 at 10:44:41 UTC, ixid wrote:

On Friday, 30 June 2017 at 10:26:03 UTC, Nicholas Wilson wrote:

On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote:
Are there any reasons not to put real on the path to removal? 
The hardware is deprecated by both Intel and AMD and it seems 
like an unnecessary source of confusion.


Don't forget that real is only fp80 on x86. On AArch64(?) it 
is/should be fp128 which _is_ supported, there is also PowerPC 
double double.


Isn't it an objective of D to move away from such confusing 
types and have defined widths?


D does have well defined floating point types.
float and double.

real is a special type for people who know what they are dong.
And not to be removed.

Re: Deprecate real

[ixid via Digitalmars-d]

On Friday, 30 June 2017 at 10:26:03 UTC, Nicholas Wilson wrote:

On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote:
Are there any reasons not to put real on the path to removal? 
The hardware is deprecated by both Intel and AMD and it seems 
like an unnecessary source of confusion.


Don't forget that real is only fp80 on x86. On AArch64(?) it 
is/should be fp128 which _is_ supported, there is also PowerPC 
double double.


Isn't it an objective of D to move away from such confusing types 
and have defined widths?

Re: Deprecate real

[Nicholas Wilson via Digitalmars-d]

On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote:
Are there any reasons not to put real on the path to removal? 
The hardware is deprecated by both Intel and AMD and it seems 
like an unnecessary source of confusion.


Don't forget that real is only fp80 on x86. On AArch64(?) it 
is/should be fp128 which _is_ supported, there is also PowerPC 
double double.

Re: Documentation licence

[tetyys via Digitalmars-d]

On Friday, 30 June 2017 at 10:10:14 UTC, ANtlord wrote:
Hello! I use service devdocs.io for some technologies. And I 
think that I able to add D to this service. I've read the 
project's wiki 
(https://github.com/Thibaut/devdocs/blob/master/CONTRIBUTING.md) and see the next:


Important: the documentation's license must permit alteration, 
redistribution and commercial use, and the documented software 
must be released under an open source license.


Due to this I get the question. Do the licence of D's 
documentaion and the licence of D allow to add the D's library 
documentation to devdocs.io?


Thanks. Sorry if my english is not clear.


Well as phobos source code comments is the documentation for 
standard library and it's licensed under Boost license 
(https://github.com/dlang/phobos/blob/master/LICENSE_1_0.txt), I 
think yes.

Documentation licence

[ANtlord via Digitalmars-d]

Hello! I use service devdocs.io for some technologies. And I 
think that I able to add D to this service. I've read the 
project's wiki 
(https://github.com/Thibaut/devdocs/blob/master/CONTRIBUTING.md) 
and see the next:


Important: the documentation's license must permit alteration, 
redistribution and commercial use, and the documented software 
must be released under an open source license.


Due to this I get the question. Do the licence of D's 
documentaion and the licence of D allow to add the D's library 
documentation to devdocs.io?


Thanks. Sorry if my english is not clear.

Deprecate real

[ixid via Digitalmars-d]

Are there any reasons not to put real on the path to removal? The 
hardware is deprecated by both Intel and AMD and it seems like an 
unnecessary source of confusion.

Re: My simple implementation of PHP strip_tags()

[Márcio Martins via Digitalmars-d]

On Wednesday, 28 June 2017 at 18:08:12 UTC, aberba wrote:
I wanted strip_tags() for sanitization in vibe.d and I set out 
for algorithms on how to do it and came across this JavaScript 
library at 
https://github.com/ericnorris/striptags/blob/master/src/striptags.js which is quite popular judging by the number of likes and forks. As a looked through, I didn't like the cumbersome approach it used so I tried to implement it in my own way. This is what I lazily did. It turns out to be so simple that I thought I could use some opinion. Notice I didn't add `tag_replacement` param but that's just like one line of code.


[...]


I wrote this a while ago, not sure if it's useful for your 
purposes, but it has been working quite well so far: 
http://code.dlang.org/packages/plain

[Issue 17577] 20%+ Performance degradation in std.conv.to due to 'import std.getopt'

[via Digitalmars-d-bugs]

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

Jon Degenhardt  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #6 from Jon Degenhardt  ---
Re-opened, as suggested. It is reproducible in DMD. Also, code structure in
Phobos could be a contributing factor.

--

Re: How to partially apply member functions?

[ct via Digitalmars-d-learn]

On Thursday, 29 June 2017 at 14:30:19 UTC, Andrea Fontana wrote:

On Thursday, 29 June 2017 at 13:01:10 UTC, ct wrote:

I was only able to do it this way:

auto on_next_previous = 
entry_.addOnNextMatch(!(on_next_previous, true));
entry_.addOnPreviousMatch(!(on_next_previous, 
false));


I think you should provide a better example in order to get 
some help.

We neither know what argument .addOnNextMatch() expects.

Usually a full example on https://dpaste.dzfl.pl or other 
websites is more useful :)


Andrea


Sorry. Please check this DPaste: 
https://dpaste.dzfl.pl/6379944510b8


addOnNextMatch() is gtk.SearchEntry.addOnNextMatch() 
[https://api.gtkd.org/gtkd/gtk/SearchEntry.html] which has the 
signature:


gulong addOnNextMatch (void delegate(SearchEntry) dlg, 
ConnectFlags connectFlags = cast(ConnectFlags)0);


So basically, it needs a

void delegate(SearchEntry)

as an argument.

I wanted to create a single callback member function to handle 
both addOnNextMatch() and addOnPreviousMatch() by binding a bool 
value (true for next_match, false for previous_match) so that the 
callback knows which case it is handling.


It compiled when I wrote:

auto on_next_previous = 
entry_.addOnNextMatch(!(on_next_previous, true));
entry_.addOnPreviousMatch(!(on_next_previous, false));

But not when I wrote:

entry_.addOnNextMatch(partial!(, true));

Or

entry_.addOnNextMatch(partial!(, 
true));


Error: value of 'this' is not known at compile time

[Issue 17577] 20%+ Performance degradation in std.conv.to due to 'import std.getopt'

[via Digitalmars-d-bugs]

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

--- Comment #5 from Vladimir Panteleev  ---
But... it's reproducible with DMD...

--

Re: mysql-native + vibe.d example

[Martin Tschierschke via Digitalmars-d-learn]

On Friday, 30 June 2017 at 00:52:28 UTC, crimaniak wrote:

Hi!
Moving my project from mysql-lited to mysql-native I faced the 
problem with null pointer error inside of mysql-native:



[...]
It seems I am doing something wrong so myself-native fails to 
detect it in isValid(). So I search for example how to use 
mysql-native in real multi-threaded vibe.d application with 
usage of MySQLPool. Please do not point me to basic example 
provided with package because it is single thread.

Thanks.
Sorry, can not help, but would be very interested to learn how to 
do a


 real multi-threaded vibe.d with mysql

So if you find a solution, please make an simplified example for 
vibe.d documentation!

Sönke might include it into vibe.d docs.

Most convenient way to write a loop with fixed length and no need for the index?

[Martin Tschierschke via Digitalmars-d-learn]

What do I have to do, to make this work?

iota(number).each!...command_x(a...);command_y(b...);command_z(c..))
 ^?
how to write the lambda?

Similar to the ruby (1..number).each{ commands...}

Don't want to write the following, because the index i is not 
used inside the loop

and this should be clear when reading it:

  for (i=0;i

Re: What are your hopes for the future D GC

[Dmitry Olshansky via Digitalmars-d]

On 6/29/2017 10:19 PM, Random D user wrote:

I just got curious, after reading the GC analysis blog post. What kind
of features people generally would want for the GC (in the distant murky
future of 1999)?

Here's some of my nice to haves:

1. Thread local GCs. D is by default thread local, so it kind of would
make sense and goodbye stop everything GC.


Yes, yes and yes. The moment we fix the spec and code that casts shared 
to TLS at will.




2. Composable custom memory block GC. The ability to mallocate 128MB
memory block and create a new GC instance to manage that block. It would
only need to scan that 128MB block and not worry about rest of memory
and resources (with complex destruction orders) in 16GB heap. This way
you probably could guarantee good collection times for some subsystems
in your program and use your favorite allocator for others.



Not sure what benefit this has compared to just limiting GC heap to 128Mb.


3. Callbacks to GC operations. I have timeline profiler implemented for
my project. It would be quite cool to have GC collection starts and
stops record a timestamp for the timeline.
(Can this be done already? Hopefully without recompiling the GC. I tried
to look but I couldn't find any hooks in the docs.)


Hooks for statistics sounds nice. You can do poll style check 
periodically right now.



4. Incremental GC with collection time limit. Is this even viable for D?


Concurrent is more likely then incremental without barriers.

--
Dmitry Olshansky

Re: Overloading funtion templates.

[Balagopal Komarath via Digitalmars-d-learn]

On Friday, 30 June 2017 at 04:51:23 UTC, vit wrote:

import std.traits : isCallable;

auto foo(alias F, T)(T x)
if(isCallable!F)//this line is optional
{
return F(x);
}



Thanks. That works.