Re: Error calling geqrs function from lubeck package.

[chuoiit18 via Digitalmars-d-learn]

On Tuesday, 17 April 2018 at 03:30:45 UTC, Jamie wrote:

On Tuesday, 17 April 2018 at 03:26:25 UTC, Jamie wrote:


Sorry it's really an error calling geqrs function from 
mir-lapack package.


, This is a great article. It gave me a lot of useful 
information. thank you very much. Link profile: 
http://dakhoaauahcm.vn

Re: What's the latest news for calling D from python 3 using ctypes?

[chuoiit18 via Digitalmars-d-learn]

On Wednesday, 28 February 2018 at 03:08:05 UTC, chuoiit18 wrote:
On Wednesday, 28 February 2018 at 02:40:59 UTC, Nicholas Wilson 
wrote:
On Wednesday, 28 February 2018 at 01:19:25 UTC, Enjoys Math 
wrote:

[...]


For some reason, idk why, PyD is a dub source dependency (as 
opposed to a library). If you add \path\to\pyd to the include 
directory(?) dub variable (or -I\path\to\pyd to dmd/ldc/gdc) 
it should hopefully work.


, This is a great article. It gave me a lot of useful 
information. thank you very much. Link profile: 
http://phongkhamdakhoathegioi.vn/me-day-ve-noi-va-cach-chua-tri-hieu-qua.html


, This is a great article. It gave me a lot of useful 
information. thank you very much. Link profile: 
http://dakhoaauahcm.vn

Re: Better multithreading with D

[12345swordy via Digitalmars-d-learn]

On Saturday, 21 April 2018 at 02:08:24 UTC, solidstate1991 wrote:
In order to call a function multiple time at parallel 
(rendering function, very well parallelizable), but in order to 
push the CPU to it's limits I have to get some form of 
parallelization. Currently I'm using parallel foreach, which 
isn't very nice, and since it uses GC allocation that creates 
some performance impact from time to time.


Did you attempt to create a memory pool with the GC? Any memory 
allocation will take time, whatever it's CG or manual.

Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel

[karita via Digitalmars-d-announce]

On Wednesday, 18 April 2018 at 15:28:07 UTC, Atila Neves wrote:

http://code.dlang.org/packages/autowrap

This came out of the need at work to take existing D code and 
make it available for both Excel and Python.


[...]


Awesome. I'm also working on numpy.ndarray <-> mir.ndslice 
automatic wrapper


https://github.com/ShigekiKarita/mir-pybuffer

Better multithreading with D

[solidstate1991 via Digitalmars-d-learn]

In order to call a function multiple time at parallel (rendering 
function, very well parallelizable), but in order to push the CPU 
to it's limits I have to get some form of parallelization. 
Currently I'm using parallel foreach, which isn't very nice, and 
since it uses GC allocation that creates some performance impact 
from time to time.

Re: PixelPerfectEngine v0.9.4-alpha.2

[solidstate1991 via Digitalmars-d-announce]

On Monday, 16 April 2018 at 15:08:38 UTC, Chris Katko wrote:


Definitely add screen shots to the github. Screenshots = 
Downloads.


I know, currently I'm struggling with getting assets for this 
purpose, also with getting rid of the GC from the rendering 
pipeline.

Re: OT - Replacing strings with slices in C# - high performance improvement

[Jack Stouffer via Digitalmars-d]

On Friday, 20 April 2018 at 16:33:44 UTC, rumbu wrote:
.NET Core 2.1 was announced, with emphasis on using Span 
instead of classic String class all around the framework. For 
people not familiar with C#, Span is similar to a D array 
slice.


https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/


And we’re trying to move towards a string library type and away 
from raw slices :)

Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.

[Jonathan M Davis via Digitalmars-d]

On Friday, April 20, 2018 19:36:57 Steven Schveighoffer via Digitalmars-d 
wrote:
> On 4/20/18 5:40 PM, Jonathan M Davis wrote:
> > On Friday, April 20, 2018 16:35:43 Steven Schveighoffer via
> > Digitalmars-d
> >
> > wrote:
> >> On 4/17/18 4:49 PM, Steven Schveighoffer wrote:
> >>> On 4/17/18 12:18 PM, Nick Treleaven wrote:
>  Thanks for making this pull, I've thought about solving this before.
>  I
>  think the function needs to provide a way to tell if the value was
>  already present.
> >>>
> >>> Not as straightforward, but it can be done:
> >>>
> >>> bool inserted = false;
> >>> auto p = aa.getOrAdd("key", {inserted = true; return new Person; });
> >>
> >> Let me say I was surprised that this doesn't actually work. An in-line
> >> lambda will NOT work as a lazy parameter, even though that's EXACTLY
> >> what a lazy parameter is implemented as! And variadic lazy parameters
> >> are explicitly typed this way.
> >>
> >> Has that ever worked? I could have sworn it did...
> >
> > I'm not sure. I mucked around with lazy like this when I was originally
> > working on stuff like assertThrown and assertPred 7 or 8 years ago, but
> > I've done _very_ little with lazy since then. My gut reaction is that
> > it worked, but it might not have. If you add parens after it so that
> > you call it, it does work, since then the result is the correct type.
> > And if you ignore the exact details of how lazy is implemented and
> > consider that it's supposed to take an expression that evaluates to a
> > specific type, a lambda doesn't match that unless it's called. So, it
> > does make sense from that perspective and is likely why it works the
> > way it does.
>
> But, it *is* a delegate. literally, that's what gets implemented (and it
> has to be that way). I suppose if it's inlined, the compiler could take
> some leeway, but that is the same with a delegate literal passed to a
> function that takes a delegate anyway.

If we want to make the compiler accept it, then I'm not necessarily against
it, but arguably, the fact that it uses a delegate is an implementation
detail. In principle, what you're doing with a lazy parameter is just saying
that the expression being passed to it isn't immediately evaluated. Having
it then accept expressions that don't result in the type of the lazy
parameter is then pretty weird.

> The fact that lazy variadics are explicitly delegates makes this even
> more annoying. I wish we could have the best of both worlds (non-ugly
> calls inside the function, and easy binding to whatever you want at the
> call side). I'm not even sure why lazy variadics are the way they are, I
> can instantly think of a better syntax for them.

Well, this thread is the first that I've heard of "lazy variadics." Until I
saw your other post about them, I assumed that you meant something like

auto foo(Args...)(lazy Args args)
{
...
}

I would haven't have assumed that

void foo(int delegate()[] dgs...)
{
dgs[0]();
}

had anything to do with lazy, and the fact that it works with anything that
doesn't implictly convert to a delegate seems like a bug to me, especially
when

void foo(int delegate() dg)
{
dg();
}

doesn't compile when it's passed an int. IMHO, they should be consistent.

> > The compiler would basically have to
> > special-case delegates to accept stuff like lambdas when the type of the
> > lazy parameter is not a delegate. And if it _did_ special-case it, then
> > things might get interesting if you actually had a lazy parameter that
> > was a delegate.
>
> This is pretty easy, does your delegate return a delegate or an int? ;)
>
> This is a super-solvable problem, I'm just surprised it wasn't this way
> before, I could have sworn I've done this in the past.

Of course it's solvable, but that doesn't mean that it's ultimately a good
idea. It does have corner cases that may or may not be a problem. e.g.
something like

void foo(lazy int delegate() dg)
{
}

could be a problem if

void foo(lazy int i)
{
}

accepts delegates whose result is an int. I'm not necessarily against making
it possible, but I would consider the fact that lazy is implemented via a
delegate to be an implementation detail of lazy, and if lazy parameters
started accepting lambdas whose result was the right type, then that means
that

auto foo(string str) {...}

and

auto foo(lazy string str) {...}

would accept different arguments even though their parameters are the same
type, and I question that that's a good idea. I'm sure that it would work on
some level, and the corner cases probably wouldn't matter often, but it
seems much cleaner to me if lazy has no effect on what is accepted and just
has an effect on whether that code is run immediately.

> > So, I don't know if it should work or not, but the workaround is
> > pretty simple - just add parens to call it.
>
> This results in a double delegate call -- the compiler makes a delegate
> that calls your delegate. Not optimal, but yes it does work.

Sure, 

Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.

[Jonathan M Davis via Digitalmars-d]

On Friday, April 20, 2018 19:27:20 Steven Schveighoffer via Digitalmars-d 
wrote:
> On 4/20/18 6:46 PM, Giles Bathgate wrote:
> > On Friday, 20 April 2018 at 22:21:13 UTC, Jonathan M Davis wrote:
> >> Honestly, I think that it's a terrible idea to special-case it like
> >> that. If we want to argue for making it work in the language, that's
> >> fine, but if we special-case it like this, then it will work with some
> >> functions that have lazy parameters and not others, and the result
> >> will be confusing. Besides, all it takes to be able to pass a lamdba
> >> or delegate to a lazy parameter is to actually call it when passing
> >> it. So, if you add parens after the braces, it works. There's no need
> >> to go and add a special case for it to the function.
> >
> > Again lack of experience, so I presume you can just do:
> >
> > bool inserted = false;
> > auto p = aa.getOrAdd("key", {inserted = true; return new Person; }());
> >
> > I hadn't realised that until now. I enjoy your brutal honesty by the way
> > ;)
> The drawback here, of course, is that it's a lambda calling a lambda (if
> you end up using the value).
>
> But of course, your overload was the same thing.
>
> I'm just surprised it doesn't work, especially when this works:
>
> // lazy variadic
> void foo(int delegate()[] dgs...)
> {
> dgs[0]();
> }
>
> foo(1); // ok, same as { return 1; }
> foo({inserted = true; return 1;}); // ok
>
> Of course, it's not as nice syntax inside the function.

Honestly, I would have considered it a bug that it accepts 1, since that's
not a delegate or lambda or anything of the sort, and the function is
explicitly typed to take delegates.

- Jonathan M Davis

Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.

[Steven Schveighoffer via Digitalmars-d]

On 4/20/18 7:21 PM, Giles Bathgate wrote:

On Friday, 20 April 2018 at 23:13:58 UTC, Jonathan M Davis wrote:

Yes. That should work. e.g. this

import std.stdio;

void foo(lazy string l)
{
}

void main()
{
    foo({writeln("foo"); return "str";}());
}

compiles and runs just fine without printing anything, whereas you get 
a compilation error if you don't have the parens after the closing brace.


Ok cool. I've updated the PR since basically, I agree with your points 
about it being confusing to cater for the special case.





Yeah, I didn't mean for the special case to happen -- I thought it just 
worked!


I should have tested my original code... Sorry.

-Steve

Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.

[Steven Schveighoffer via Digitalmars-d]

On 4/20/18 5:40 PM, Jonathan M Davis wrote:

On Friday, April 20, 2018 16:35:43 Steven Schveighoffer via Digitalmars-d
wrote:

On 4/17/18 4:49 PM, Steven Schveighoffer wrote:

On 4/17/18 12:18 PM, Nick Treleaven wrote:

Thanks for making this pull, I've thought about solving this before. I
think the function needs to provide a way to tell if the value was
already present.


Not as straightforward, but it can be done:

bool inserted = false;
auto p = aa.getOrAdd("key", {inserted = true; return new Person; });


Let me say I was surprised that this doesn't actually work. An in-line
lambda will NOT work as a lazy parameter, even though that's EXACTLY
what a lazy parameter is implemented as! And variadic lazy parameters
are explicitly typed this way.

Has that ever worked? I could have sworn it did...


I'm not sure. I mucked around with lazy like this when I was originally
working on stuff like assertThrown and assertPred 7 or 8 years ago, but I've
done _very_ little with lazy since then. My gut reaction is that it worked,
but it might not have. If you add parens after it so that you call it, it
does work, since then the result is the correct type. And if you ignore the
exact details of how lazy is implemented and consider that it's supposed to
take an expression that evaluates to a specific type, a lambda doesn't match
that unless it's called. So, it does make sense from that perspective and is
likely why it works the way it does.


But, it *is* a delegate. literally, that's what gets implemented (and it 
has to be that way). I suppose if it's inlined, the compiler could take 
some leeway, but that is the same with a delegate literal passed to a 
function that takes a delegate anyway.


The fact that lazy variadics are explicitly delegates makes this even 
more annoying. I wish we could have the best of both worlds (non-ugly 
calls inside the function, and easy binding to whatever you want at the 
call side). I'm not even sure why lazy variadics are the way they are, I 
can instantly think of a better syntax for them.



The compiler would basically have to
special-case delegates to accept stuff like lambdas when the type of the
lazy parameter is not a delegate. And if it _did_ special-case it, then
things might get interesting if you actually had a lazy parameter that was a
delegate.


This is pretty easy, does your delegate return a delegate or an int? ;)

This is a super-solvable problem, I'm just surprised it wasn't this way 
before, I could have sworn I've done this in the past.



So, I don't know if it should work or not, but the workaround is
pretty simple - just add parens to call it.


This results in a double delegate call -- the compiler makes a delegate 
that calls your delegate. Not optimal, but yes it does work.


-Steve

Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.

[Steven Schveighoffer via Digitalmars-d]

On 4/20/18 6:46 PM, Giles Bathgate wrote:

On Friday, 20 April 2018 at 22:21:13 UTC, Jonathan M Davis wrote:
Honestly, I think that it's a terrible idea to special-case it like 
that. If we want to argue for making it work in the language, that's 
fine, but if we special-case it like this, then it will work with some 
functions that have lazy parameters and not others, and the result 
will be confusing. Besides, all it takes to be able to pass a lamdba 
or delegate to a lazy parameter is to actually call it when passing 
it. So, if you add parens after the braces, it works. There's no need 
to go and add a special case for it to the function.


Again lack of experience, so I presume you can just do:

bool inserted = false;
auto p = aa.getOrAdd("key", {inserted = true; return new Person; }());

I hadn't realised that until now. I enjoy your brutal honesty by the way ;)




The drawback here, of course, is that it's a lambda calling a lambda (if 
you end up using the value).


But of course, your overload was the same thing.

I'm just surprised it doesn't work, especially when this works:

// lazy variadic
void foo(int delegate()[] dgs...)
{
   dgs[0]();
}

foo(1); // ok, same as { return 1; }
foo({inserted = true; return 1;}); // ok

Of course, it's not as nice syntax inside the function.

-Steve

Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.

[Giles Bathgate via Digitalmars-d]

On Friday, 20 April 2018 at 23:13:58 UTC, Jonathan M Davis wrote:

Yes. That should work. e.g. this

import std.stdio;

void foo(lazy string l)
{
}

void main()
{
foo({writeln("foo"); return "str";}());
}

compiles and runs just fine without printing anything, whereas 
you get a compilation error if you don't have the parens after 
the closing brace.


Ok cool. I've updated the PR since basically, I agree with your 
points about it being confusing to cater for the special case.

Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.

[Jonathan M Davis via Digitalmars-d]

On Friday, April 20, 2018 22:46:54 Giles Bathgate via Digitalmars-d wrote:
> On Friday, 20 April 2018 at 22:21:13 UTC, Jonathan M Davis wrote:
> > Honestly, I think that it's a terrible idea to special-case it
> > like that. If we want to argue for making it work in the
> > language, that's fine, but if we special-case it like this,
> > then it will work with some functions that have lazy parameters
> > and not others, and the result will be confusing. Besides, all
> > it takes to be able to pass a lamdba or delegate to a lazy
> > parameter is to actually call it when passing it. So, if you
> > add parens after the braces, it works. There's no need to go
> > and add a special case for it to the function.
>
> Again lack of experience, so I presume you can just do:
>
> bool inserted = false;
> auto p = aa.getOrAdd("key", {inserted = true; return new Person;
> }());
>
> I hadn't realised that until now. I enjoy your brutal honesty by
> the way ;)

Yes. That should work. e.g. this

import std.stdio;

void foo(lazy string l)
{
}

void main()
{
foo({writeln("foo"); return "str";}());
}

compiles and runs just fine without printing anything, whereas you get a
compilation error if you don't have the parens after the closing brace.

- Jonathan M Davis

Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.

[Giles Bathgate via Digitalmars-d]

On Friday, 20 April 2018 at 22:21:13 UTC, Jonathan M Davis wrote:
Honestly, I think that it's a terrible idea to special-case it 
like that. If we want to argue for making it work in the 
language, that's fine, but if we special-case it like this, 
then it will work with some functions that have lazy parameters 
and not others, and the result will be confusing. Besides, all 
it takes to be able to pass a lamdba or delegate to a lazy 
parameter is to actually call it when passing it. So, if you 
add parens after the braces, it works. There's no need to go 
and add a special case for it to the function.


Again lack of experience, so I presume you can just do:

bool inserted = false;
auto p = aa.getOrAdd("key", {inserted = true; return new Person; 
}());


I hadn't realised that until now. I enjoy your brutal honesty by 
the way ;)

Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.

[Jonathan M Davis via Digitalmars-d]

On Friday, April 20, 2018 22:03:04 Giles Bathgate via Digitalmars-d wrote:
> On Friday, 20 April 2018 at 20:35:43 UTC, Steven Schveighoffer
>
> wrote:
> > Let me say I was surprised that this doesn't actually work. An
> > in-line lambda will NOT work as a lazy parameter, even though
> > that's EXACTLY what a lazy parameter is implemented as! And
> > variadic lazy parameters are explicitly typed this way.
>
> I kind of expected it to work too. However, I just created a
> template to allow this to work with my PR.
>
> https://github.com/dlang/druntime/pull/2162/files#diff-a68e58fcf0de5aa198f
> caceafe4e8cf9R2344
>
> Getting it right took a few head-scratchers, but I put that down
> to my lack of experience with D ;)

Honestly, I think that it's a terrible idea to special-case it like that. If
we want to argue for making it work in the language, that's fine, but if we
special-case it like this, then it will work with some functions that have
lazy parameters and not others, and the result will be confusing. Besides,
all it takes to be able to pass a lamdba or delegate to a lazy parameter is
to actually call it when passing it. So, if you add parens after the braces,
it works. There's no need to go and add a special case for it to the
function.

- Jonathan M Davis

Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.

[Giles Bathgate via Digitalmars-d]

On Friday, 20 April 2018 at 20:35:43 UTC, Steven Schveighoffer 
wrote:


Let me say I was surprised that this doesn't actually work. An 
in-line lambda will NOT work as a lazy parameter, even though 
that's EXACTLY what a lazy parameter is implemented as! And 
variadic lazy parameters are explicitly typed this way.


I kind of expected it to work too. However, I just created a 
template to allow this to work with my PR.


https://github.com/dlang/druntime/pull/2162/files#diff-a68e58fcf0de5aa198fcaceafe4e8cf9R2344

Getting it right took a few head-scratchers, but I put that down 
to my lack of experience with D ;)

Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.

[Jonathan M Davis via Digitalmars-d]

On Friday, April 20, 2018 16:35:43 Steven Schveighoffer via Digitalmars-d 
wrote:
> On 4/17/18 4:49 PM, Steven Schveighoffer wrote:
> > On 4/17/18 12:18 PM, Nick Treleaven wrote:
> >> Thanks for making this pull, I've thought about solving this before. I
> >> think the function needs to provide a way to tell if the value was
> >> already present.
> >
> > Not as straightforward, but it can be done:
> >
> > bool inserted = false;
> > auto p = aa.getOrAdd("key", {inserted = true; return new Person; });
>
> Let me say I was surprised that this doesn't actually work. An in-line
> lambda will NOT work as a lazy parameter, even though that's EXACTLY
> what a lazy parameter is implemented as! And variadic lazy parameters
> are explicitly typed this way.
>
> Has that ever worked? I could have sworn it did...

I'm not sure. I mucked around with lazy like this when I was originally
working on stuff like assertThrown and assertPred 7 or 8 years ago, but I've
done _very_ little with lazy since then. My gut reaction is that it worked,
but it might not have. If you add parens after it so that you call it, it
does work, since then the result is the correct type. And if you ignore the
exact details of how lazy is implemented and consider that it's supposed to
take an expression that evaluates to a specific type, a lambda doesn't match
that unless it's called. So, it does make sense from that perspective and is
likely why it works the way it does. The compiler would basically have to
special-case delegates to accept stuff like lambdas when the type of the
lazy parameter is not a delegate. And if it _did_ special-case it, then
things might get interesting if you actually had a lazy parameter that was a
delegate. So, I don't know if it should work or not, but the workaround is
pretty simple - just add parens to call it.

- Jonathan M Davis

Re: D vs nim

[jmh530 via Digitalmars-d]

On Friday, 20 April 2018 at 11:07:30 UTC, Russel Winder wrote:


Has anyone got Pony on their list of interesting languages?


I had spent some time looking over the reference capabilities 
[1], but I'm not sure I have the time to actually program in the 
language. The isolated type seemed like the most interesting 
take-away. I think someone on the D forums had been trying to get 
something similar.


[1] 
https://tutorial.ponylang.org/capabilities/reference-capabilities.html

[Issue 18735] all versions of find and canfind should identify usage of predicate

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

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

petrug  changed:

   What|Removed |Added

   Assignee|petru.guri...@gmail.com |nob...@puremagic.com

--

[Issue 18731] Link only with druntime for the runnable tests if Phobos isn't needed

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

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

petrug  changed:

   What|Removed |Added

   Assignee|petru.guri...@gmail.com |nob...@puremagic.com

--

[Issue 18735] all versions of find and canfind should identify usage of predicate

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

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

petrug  changed:

   What|Removed |Added

 CC||petru.guri...@gmail.com
   Assignee|nob...@puremagic.com|petru.guri...@gmail.com

--

[Issue 18731] Link only with druntime for the runnable tests if Phobos isn't needed

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

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

petrug  changed:

   What|Removed |Added

 CC||petru.guri...@gmail.com
   Assignee|nob...@puremagic.com|petru.guri...@gmail.com

--

[Issue 18728] std.math.fdim does not handle nan correctly

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

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

petrug  changed:

   What|Removed |Added

 CC||petru.guri...@gmail.com
   Assignee|nob...@puremagic.com|petru.guri...@gmail.com

--

[Issue 18727] std.math.fmin does not handle nan correctly

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

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

petrug  changed:

   What|Removed |Added

 CC||petru.guri...@gmail.com
   Assignee|nob...@puremagic.com|petru.guri...@gmail.com

--

[Issue 18786] AV program detects malware in windows download of DMD

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

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
This is a false positive. Please notify your Antivirus vendor and report their
false detection there. Thanks!

BTW dmd-2.063 is more than four years old. Are you sure you need such an old
release?

--

Re: Are Fibers just broken in D?

[Byron Moxie via Digitalmars-d-learn]

On Friday, 20 April 2018 at 20:46:20 UTC, Steven Schveighoffer 
wrote:

On 4/20/18 2:58 PM, Byron Moxie wrote:

[...]


It sounds like the problems may be due to Win32 and not the 
other pieces. Have you tried on a Win64 build? Even if that's 
not your target, at least it can help you discover whether that 
is the problem or not. The DMC runtime is the default on Win32, 
and it's not especially thread-safe in all places.


FWIW, I'm using vibe.d on Linux 64 bit with no problems (and 
I've NEVER heard of atomicLoad and atomicStore not working on 
any arch).


-Steve


I had move the data I wanted to sync with atomicLoad/Store into a 
shared struct and pass a pointer to this struct to the other 
fibers. Not sure if this was an issue with TLS messing with class 
object I was passing around.

Re: Are Fibers just broken in D?

[Steven Schveighoffer via Digitalmars-d-learn]

On 4/20/18 2:58 PM, Byron Moxie wrote:
I am working on an application that makes heavy use of Fibers pools that 
are processed by a thread pool.


In WIN32 it looks like its leaking memory then it segfaults (I am 
guessing its an OOM).


I am also trying to use Semaphores and/or Conditions on shared data 
between fibers, which results in segfaults as well.


atomicLoad and atomicStore are not working either.

Are Fibers usable at all?  Cause it doesn't seem like.  I already 
re-arched this application to remove vibe.d (was fighting all sorts of 
sync and event errors)


This application is turning into my last straw for D..  I spend about 
90% of my time fighting the compiler / library. I am really debating 
re-writing this application in c++ over the weekend (I have already lost 
money on this job after convincing by boss that D would be better).


It sounds like the problems may be due to Win32 and not the other 
pieces. Have you tried on a Win64 build? Even if that's not your target, 
at least it can help you discover whether that is the problem or not. 
The DMC runtime is the default on Win32, and it's not especially 
thread-safe in all places.


FWIW, I'm using vibe.d on Linux 64 bit with no problems (and I've NEVER 
heard of atomicLoad and atomicStore not working on any arch).


-Steve

Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.

[Steven Schveighoffer via Digitalmars-d]

On 4/17/18 4:49 PM, Steven Schveighoffer wrote:

On 4/17/18 12:18 PM, Nick Treleaven wrote:
Thanks for making this pull, I've thought about solving this before. I 
think the function needs to provide a way to tell if the value was 
already present.


Not as straightforward, but it can be done:

bool inserted = false;
auto p = aa.getOrAdd("key", {inserted = true; return new Person; });


Let me say I was surprised that this doesn't actually work. An in-line 
lambda will NOT work as a lazy parameter, even though that's EXACTLY 
what a lazy parameter is implemented as! And variadic lazy parameters 
are explicitly typed this way.


Has that ever worked? I could have sworn it did...

-Steve

Re: D vs nim

[Nordlöw via Digitalmars-d]

On Friday, 20 April 2018 at 11:07:30 UTC, Russel Winder wrote:
On Thu, 2018-04-19 at 16:50 +, Per Nordlöw via 
Digitalmars-d wrote:

On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote:
> P.S., the example on the language's frontpage is cool!
> 
> http://nim-lang.org/
> 
> Why should I be excited?

> Nim is the only language that leverages automated proof
> technology to perform a disjoint check for your parallel 
> code.

> Working on disjoint data means no locking is required and yet
> data races are impossible:

I believe Rust's rayon [1] can do this too...

[1] https://github.com/rayon-rs/rayon


Has anyone got Pony on their list of interesting languages?


Yep, I have. To bad about no curly braces, though.

Re: Issues with debugging GC-related crashes #2

[Matthias Klumpp via Digitalmars-d]

On Friday, 20 April 2018 at 18:30:30 UTC, Matthias Klumpp wrote:
On Friday, 20 April 2018 at 05:32:32 UTC, Dmitry Olshansky 
wrote:
On Friday, 20 April 2018 at 00:11:25 UTC, Matthias Klumpp 
wrote:

On Thursday, 19 April 2018 at 18:45:41 UTC, kinke wrote:

[...]

[...]


I think the order of operations is wrong, here is an example 
from containers:


allocator.dispose(buckets);
static if (useGC)
GC.removeRange(buckets.ptr);

If GC triggers between dispose and removeRange, it will likely 
segfault.


Indeed! It's also the only place where this is shuffled around, 
all other parts of the containers library do this properly.
The thing I wonder about is though, that the crash usually 
appeared in an explicit GC.collect() call when the application 
was not running multiple threads. At that point, the GC - as 
far as I know - couldn't have triggered after the buckets were 
disposed of and the ranges were removed. But maybe I am wrong 
with that assumption.

This crash would be explained perfectly by that bug.


Turns out that was indeed the case! I created a small testcase 
which managed to very reliably reproduce the issue on all 
machines that I tested it on. After reordering the 
dispose/removeRange, the crashes went away completely.
I submitted a pull request to the containers library to fix this 
issue: https://github.com/dlang-community/containers/pull/107


I will also try to get the patch into the components in Debian 
and Ubuntu, so we can maybe have a chance of updating the 
software center metadata for Ubuntu before 18.04 LTS releases 
next week.
Since asgen uses HashMaps for pretty much everything, an most of 
the time with GC-managed elements, this should improve the 
stability of the application greatly.


Thanks a lot for the help in debugging this, I learned a lot 
about DRuntime internals in the process. Also, it is no 
exaggeration to say that the appstream-generator project would 
not be written in D (there was a Rust prototype once...) and I 
would probably not be using D as much (or at all) without the 
helpful community around it.

Thank you :-)

Re: Are Fibers just broken in D?

[rikki cattermole via Digitalmars-d-learn]

On 21/04/2018 6:58 AM, Byron Moxie wrote:
I am working on an application that makes heavy use of Fibers pools that 
are processed by a thread pool.


In WIN32 it looks like its leaking memory then it segfaults (I am 
guessing its an OOM).


I am also trying to use Semaphores and/or Conditions on shared data 
between fibers, which results in segfaults as well.


atomicLoad and atomicStore are not working either.

Are Fibers usable at all?  Cause it doesn't seem like.  I already 
re-arched this application to remove vibe.d (was fighting all sorts of 
sync and event errors)


This application is turning into my last straw for D..  I spend about 
90% of my time fighting the compiler / library. I am really debating 
re-writing this application in c++ over the weekend (I have already lost 
money on this job after convincing by boss that D would be better).


atomicLoad and atomicStore, definitely are working.

It sounds like you have got some pretty big problems that may not be on 
D's end.


But we'll need code to be able to help you further than that.

Are Fibers just broken in D?

[Byron Moxie via Digitalmars-d-learn]

I am working on an application that makes heavy use of Fibers 
pools that are processed by a thread pool.


In WIN32 it looks like its leaking memory then it segfaults (I am 
guessing its an OOM).


I am also trying to use Semaphores and/or Conditions on shared 
data between fibers, which results in segfaults as well.


atomicLoad and atomicStore are not working either.

Are Fibers usable at all?  Cause it doesn't seem like.  I already 
re-arched this application to remove vibe.d (was fighting all 
sorts of sync and event errors)


This application is turning into my last straw for D..  I spend 
about 90% of my time fighting the compiler / library. I am really 
debating re-writing this application in c++ over the weekend (I 
have already lost money on this job after convincing by boss that 
D would be better).

Re: dxml 0.3.0 released

[Jonathan M Davis via Digitalmars-d-announce]

On Friday, April 20, 2018 16:07:06 Jesse Phillips via Digitalmars-d-announce 
wrote:
> On Friday, 20 April 2018 at 00:46:38 UTC, Jonathan M Davis wrote:
> > Yes. I would have thought that that was clear. It throws if any
> > of the characters or sequence of characters in the argument
> > aren't legal in the text portion of an XML document. Those
> > characters that can be legally present in encoded form but not
> > in their literal form can be encoded first with encodeText.
> > I'll try to make the documentation clearer.
>
> I think I just feel it is a little hidden under the exception
> list. A note in the general description about utilizing
> encodeText on text which needs encoding would be good.

Well, for better or worse, it now mentions it directly in the Throws
section.

- Jonathan M Davis

Re: Issues with debugging GC-related crashes #2

[Matthias Klumpp via Digitalmars-d]

On Friday, 20 April 2018 at 05:32:32 UTC, Dmitry Olshansky wrote:

On Friday, 20 April 2018 at 00:11:25 UTC, Matthias Klumpp wrote:

On Thursday, 19 April 2018 at 18:45:41 UTC, kinke wrote:

[...]


Jup, I did that already, it just took a really long time to 
run because when I made the change to print errno I also 
enabled detailed GC profiling (via the PRINTF* debug options). 
Enabling the INVARIANT option for the GC is completely broken 
by the way, I enforced the compile to work by casting to 
shared, with the result of the GC locking up forever at the 
start of the program.


[...]


I think the order of operations is wrong, here is an example 
from containers:


allocator.dispose(buckets);
static if (useGC)
GC.removeRange(buckets.ptr);

If GC triggers between dispose and removeRange, it will likely 
segfault.


Indeed! It's also the only place where this is shuffled around, 
all other parts of the containers library do this properly.
The thing I wonder about is though, that the crash usually 
appeared in an explicit GC.collect() call when the application 
was not running multiple threads. At that point, the GC - as far 
as I know - couldn't have triggered after the buckets were 
disposed of and the ranges were removed. But maybe I am wrong 
with that assumption.

This crash would be explained perfectly by that bug.

Re: GDB + ddemangle

[drug via Digitalmars-d-announce]

20.04.2018 20:55, Iain Buclaw пишет:


Using a compiler that implements 2.077 or later (IIRC) probably won't,
due to gdb being too old.  They broke ABI by introducing back
referencing, no release of gdb supports that yet.


I see. Thanks for clarification.

Aren't plugins for gdb like subj more simple way to extend dlang support 
in gdb then?

Re: GDB + ddemangle

[Iain Buclaw via Digitalmars-d-announce]

On 20 April 2018 at 17:40, drug via Digitalmars-d-announce
 wrote:
> 20.04.2018 16:49, Iain Buclaw пишет:
>>
>>
>> GDB auto-detects the language based on DW_LANG tag in the debug info.
>>
>> If you are starting up gdb without a program to debug, you can
>> explicitly switch with: set lang d
>> Then try something like: demangle _D3fooFiZv
>>
>> Or if you want it to start up in D mode: gdb -ex 'set lang d'
>>
> it works, thank you. But not in all cases. For example when gdb stops on
> breakpoint it demangle, but if I do `bt` - backtrace isn't demangled.

Using a compiler that implements 2.077 or later (IIRC) probably won't,
due to gdb being too old.  They broke ABI by introducing back
referencing, no release of gdb supports that yet.

Re: isInputRange is false for non-copyable types

[Uranuz via Digitalmars-d]

foreach(ref e; range)
{
}


On idea is to have `ref` foreach to say that you would like to 
iterate your range without copying. The syntax could be:


foreach(e; ref range)
{
}

or:
ref foreach(e; range)
{
}
At least it will not break existing code. But this means that in 
each case you should make a decision about `ref`/non ref.

OT - Replacing strings with slices in C# - high performance improvement

[rumbu via Digitalmars-d]

.NET Core 2.1 was announced, with emphasis on using Span 
instead of classic String class all around the framework. For 
people not familiar with C#, Span is similar to a D array 
slice.


https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/

Re: #dbugfix Issue 16486 200$

[jmh530 via Digitalmars-d]

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:

[snip]

They are used in mir-lapack [5]. The bug fix also required for 
mir (Sparse, CompressedTensor), and for the future Dlang image 
library.


I was experimenting with one of the open methods matrix examples 
[1] and trying to replace the virtual methods with templates. My 
example [3] does it statically and with structs so that it could 
be used with mir. However, the moment you try to make it a little 
bit more complicated and allow the type of the underlying matrix 
data to be templated, then it hits up against this issue and you 
can't rely on aliases any more.


I would support a DIP.

[1] 
https://github.com/jll63/openmethods.d/tree/master/examples/matrix/source


[2] 
http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html


[3] https://run.dlang.io/gist/9da210e321af95e1ce373b5a6621e4f8

Re: #dbugfix Issue 16486 200$

[jmh530 via Digitalmars-d]

On Friday, 20 April 2018 at 16:03:40 UTC, jmh530 wrote:

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:

[...]


I was experimenting with one of the open methods matrix 
examples [1] and trying to replace the virtual methods with 
templates. My example [3] does it statically and with structs 
so that it could be used with mir. However, the moment you try 
to make it a little bit more complicated and allow the type of 
the underlying matrix data to be templated, then it hits up 
against this issue and you can't rely on aliases any more.


I would support a DIP.

[1] 
https://github.com/jll63/openmethods.d/tree/master/examples/matrix/source


[2] 
http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html


[3] https://run.dlang.io/gist/9da210e321af95e1ce373b5a6621e4f8


Sorry, the stupid thing keeps telling me it's down for 
maintenance.

Re: dxml 0.3.0 released

[Jesse Phillips via Digitalmars-d-announce]

On Friday, 20 April 2018 at 00:46:38 UTC, Jonathan M Davis wrote:

Yes. I would have thought that that was clear. It throws if any 
of the characters or sequence of characters in the argument 
aren't legal in the text portion of an XML document. Those 
characters that can be legally present in encoded form but not 
in their literal form can be encoded first with encodeText. 
I'll try to make the documentation clearer.


- Jonathan M Davis


I think I just feel it is a little hidden under the exception 
list. A note in the general description about utilizing 
encodeText on text which needs encoding would be good.

Re: #dbugfix Issue 16486 200$

[jmh530 via Digitalmars-d]

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:

[snip]

They are used in mir-lapack [5]. The bug fix also required for 
mir (Sparse, CompressedTensor), and for the future Dlang image 
library.


I was experimenting with one of the open methods matrix examples 
[1] and trying to replace the virtual methods with templates. My 
example [3] does it statically and with structs so that it could 
be used with mir. However, the moment you try to make it a little 
bit more complicated and allow the type of the underlying matrix 
data to be templated, then it hits up against this issue and you 
can't rely on aliases any more.


I would support a DIP.

[1] 
https://github.com/jll63/openmethods.d/tree/master/examples/matrix/source


[2] 
http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html


[3] https://run.dlang.io/gist/9da210e321af95e1ce373b5a6621e4f8

Re: #dbugfix Issue 16486 200$

[jmh530 via Digitalmars-d]

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:

[snip]

They are used in mir-lapack [5]. The bug fix also required for 
mir (Sparse, CompressedTensor), and for the future Dlang image 
library.


I was experimenting with one of the open methods matrix examples 
[1] and trying to replace the virtual methods with templates. My 
example [3] does it statically and with structs so that it could 
be used with mir. However, the moment you try to make it a little 
bit more complicated and allow the type of the underlying matrix 
data to be templated, then it hits up against this issue and you 
can't rely on aliases any more.


I would support a DIP.

[1] 
https://github.com/jll63/openmethods.d/tree/master/examples/matrix/source


[2] 
http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html


[3] https://run.dlang.io/gist/9da210e321af95e1ce373b5a6621e4f8

Re: #dbugfix Issue 16486 200$

[jmh530 via Digitalmars-d]

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:

[snip]

They are used in mir-lapack [5]. The bug fix also required for 
mir (Sparse, CompressedTensor), and for the future Dlang image 
library.


I was experimenting with one of the open methods matrix examples 
[1] and trying to replace the virtual methods with templates. My 
example [3] does it statically and with structs so that it could 
be used with mir. However, the moment you try to make it a little 
bit more complicated and allow the type of the underlying matrix 
data to be templated, then it hits up against this issue and you 
can't rely on aliases any more.


I would support a DIP.

[1] 
https://github.com/jll63/openmethods.d/tree/master/examples/matrix/source


[2] 
http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html


[3] https://run.dlang.io/gist/9da210e321af95e1ce373b5a6621e4f8

Re: #dbugfix Issue 16486 200$

[jmh530 via Digitalmars-d]

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:

[snip]

They are used in mir-lapack [5]. The bug fix also required for 
mir (Sparse, CompressedTensor), and for the future Dlang image 
library.


I was experimenting with one of the open methods matrix examples 
[1] and trying to replace the virtual methods with templates. My 
example [3] does it statically and with structs so that it could 
be used with mir. However, the moment you try to make it a little 
bit more complicated and allow the type of the underlying matrix 
data to be templated, then it hits up against this issue and you 
can't rely on aliases any more.


I would support a DIP.

[1] 
https://github.com/jll63/openmethods.d/tree/master/examples/matrix/source


[2] 
http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html


[3] https://run.dlang.io/gist/9da210e321af95e1ce373b5a6621e4f8

Re: GDB + ddemangle

[drug via Digitalmars-d-announce]

20.04.2018 16:49, Iain Buclaw пишет:


GDB auto-detects the language based on DW_LANG tag in the debug info.

If you are starting up gdb without a program to debug, you can
explicitly switch with: set lang d
Then try something like: demangle _D3fooFiZv

Or if you want it to start up in D mode: gdb -ex 'set lang d'

it works, thank you. But not in all cases. For example when gdb stops on 
breakpoint it demangle, but if I do `bt` - backtrace isn't demangled.

Re: Feature to get or add value to an associative array.

[Uknown via Digitalmars-d]

On Friday, 20 April 2018 at 15:00:39 UTC, Steven Schveighoffer 
wrote:

On 4/20/18 10:34 AM, Uknown wrote:
On Friday, 20 April 2018 at 14:02:17 UTC, Steven Schveighoffer 
wrote:

On 4/20/18 4:24 AM, Nick Treleaven wrote:

On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:

[...]


Sorry, it was a typo. In my real code I have:

xp = &(foo(x));

That's what I get for hand-typing instead of copy-pasting :)

-Steve


It seems like a bug. Changing foo to take and return an `int *` 
works as expected

https://run.dlang.io/is/3NYXYv

Re: Feature to get or add value to an associative array.

[Steven Schveighoffer via Digitalmars-d]

On 4/20/18 10:34 AM, Uknown wrote:

On Friday, 20 April 2018 at 14:02:17 UTC, Steven Schveighoffer wrote:

On 4/20/18 4:24 AM, Nick Treleaven wrote:

On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:

You can get a pointer from the ref return:

    Value* p = ("key", { inserted = true; return Value.init; 
});


This is not @safe, even with -dip1000:

Error: cannot take address of ref return of f() in @safe function main


Hm... I would have expected it to work in dip1000.

Hard for me to understand what dip1000 is doing, but it seems like an 
omission:


@safe ref int foo(return ref int x) { return x; }

void main() @safe
{
   int x;
   scope int *xp =  // OK with dip1000
   xp = foo(x); // Error, even though it's exactly the same
}

And in this case, it doesn't even need to be scope, as it's GC data. 
How does one communicate that the ref return is of GC data and can be 
escaped as much as you want?




The error seems to be about type mismatching, it works if you use auto. 
I don't see how you could convert the `ref int` to `int *`

https://run.dlang.io/is/eIJMIK


Sorry, it was a typo. In my real code I have:

xp = &(foo(x));

That's what I get for hand-typing instead of copy-pasting :)

-Steve

[Issue 18787] New: ddoc crashes on static foreach

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

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

  Issue ID: 18787
   Summary: ddoc crashes on static foreach
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: snarwin+bugzi...@gmail.com

Attempting to generate documentation for the following code causes dmd to
segfault:

--- test.d
/**
 * The quick brown fox jumps over the lazy dog
 */
struct Test(Args...)
{
static foreach (T; Args) {}
}
---

$ dmd -D -main test.d
Segmentation fault
$ dmd --version
DMD64 D Compiler v2.079.1

--

Re: Feature to get or add value to an associative array.

[Uknown via Digitalmars-d]

On Friday, 20 April 2018 at 14:02:17 UTC, Steven Schveighoffer 
wrote:

On 4/20/18 4:24 AM, Nick Treleaven wrote:

On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:

You can get a pointer from the ref return:

    Value* p = ("key", { inserted = true; return 
Value.init; });


This is not @safe, even with -dip1000:

Error: cannot take address of ref return of f() in @safe 
function main


Hm... I would have expected it to work in dip1000.

Hard for me to understand what dip1000 is doing, but it seems 
like an omission:


@safe ref int foo(return ref int x) { return x; }

void main() @safe
{
   int x;
   scope int *xp =  // OK with dip1000
   xp = foo(x); // Error, even though it's exactly the same
}

And in this case, it doesn't even need to be scope, as it's GC 
data. How does one communicate that the ref return is of GC 
data and can be escaped as much as you want?


-Steve


The error seems to be about type mismatching, it works if you use 
auto. I don't see how you could convert the `ref int` to `int *`

https://run.dlang.io/is/eIJMIK

Re: Feature to get or add value to an associative array.

[Steven Schveighoffer via Digitalmars-d]

On 4/20/18 4:24 AM, Nick Treleaven wrote:

On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:

You can get a pointer from the ref return:

    Value* p = ("key", { inserted = true; return Value.init; });


This is not @safe, even with -dip1000:

Error: cannot take address of ref return of f() in @safe function main


Hm... I would have expected it to work in dip1000.

Hard for me to understand what dip1000 is doing, but it seems like an 
omission:


@safe ref int foo(return ref int x) { return x; }

void main() @safe
{
   int x;
   scope int *xp =  // OK with dip1000
   xp = foo(x); // Error, even though it's exactly the same
}

And in this case, it doesn't even need to be scope, as it's GC data. How 
does one communicate that the ref return is of GC data and can be 
escaped as much as you want?


-Steve

Re: Feature to get or add value to an associative array.

[Giles Bathgate via Digitalmars-d]

On Friday, 20 April 2018 at 02:12:37 UTC, Jonathan M Davis wrote:
Out of all of those, I _really_ hope that you don't go with 
require. It sounds like the sort of thing that you'd get in a 
library having to do with unit testing or contracts and gives 
no indication whatsoever as to what it does.


Yes I know. I gave up on trying to find a single verb or 
runTogetherWords that would describe exactly what it does, and 
instead opted for something that I like, and added documentation 
to describe what it does.


I don't think I will find a name that everybody likes. But I am 
open to more suggestions as its probably the easiest aspect of 
the PR to change.

Re: GDB + ddemangle

[Iain Buclaw via Digitalmars-d-announce]

On 20 April 2018 at 14:54, drug via Digitalmars-d-announce
 wrote:
> 20.04.2018 15:36, Mike Franklin пишет:
>
>> On Friday, 20 April 2018 at 10:36:25 UTC, drug wrote:
>>>
>>> 20.04.2018 13:03, Joakim пишет:


 You are aware that gdb has built-in support for demangling D for 3-4
 years now?

>>> But how to enable it? It doesn't work out of box at least for me.
>>
>>
>> I believe you enable it with `-demangle=dlang`
>>
>> The original announcement is here:
>> https://forum.dlang.org/post/rvoqllpimfskvlabp...@forum.dlang.org
>>
>> There are a few posts on the forum with some example usages:
>> https://forum.dlang.org/search?q=%22demangle%3Ddlang%22=1
>>
>> Mike
>
> thanks for reply! but gdb don't recognize this option - unknown option
> "--demangle=dlang"
>
> ```
> $gdb --version
> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> ...
> ```
>
> Or it is intended to work only using `objdump` etc?


GDB auto-detects the language based on DW_LANG tag in the debug info.

If you are starting up gdb without a program to debug, you can
explicitly switch with: set lang d
Then try something like: demangle _D3fooFiZv

Or if you want it to start up in D mode: gdb -ex 'set lang d'

Re: Feature to get or add value to an associative array.

[Giles Bathgate via Digitalmars-d]

On Friday, 20 April 2018 at 08:37:59 UTC, Nick Treleaven wrote:

Again, would the delegate calls always be inlined, in all cases?

I think having a low-level API in druntime is appropriate, it's 
a runtime library after all.


So the low-level API you are requesting is part of the pull 
request, the low-level API is called _aaGetX, whereas the 
previous API was _aaGetY, the new API adds a boolean out 
parameter `found` and if you really wanted to you could do this:


-
extern (C) void* _aaGetX(void** paa, const 
TypeInfo_AssociativeArray ti, in size_t valuesize, in void* pkey, 
out bool found) pure nothrow;


V* slot(K, V)(ref V[K] aa, K key, out bool found)
{
return cast(V*) _aaGetX(cast(void**), typeid(V[K]), 
V.sizeof, , found);

}
-

I am also benchmarking the `update` function I talked about 
previously.

https://gist.github.com/GilesBathgate/8409b5889ebb7b1302627c50f342a28b

The results seem to indicate that there isn't much in it 
performance wise.


test1 [56 ms, 377 µs, and 4 hnsecs]
test2 [56 ms, 262 µs, and 2 hnsecs]

I can't fathom why the delegates version is faster, but I am just 
putting it down to luck ;)

[Issue 18786] New: AV program detects malware in windows download of DMD

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

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

  Issue ID: 18786
   Summary: AV program detects malware in windows download of DMD
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: blocker
  Priority: P1
 Component: installer
  Assignee: nob...@puremagic.com
  Reporter: n...@suridx.com

Created attachment 1687
  --> https://issues.dlang.org/attachment.cgi?id=1687=edit
Output of AV program

When I ran DMD download (dmd-2.063.2) on the Virus total site I got the
following 2 detections

McAfee-GW-Edition

BehavesLike.Win32.Dropper.cc

VBA32

suspected of Trojan.Downloader.gen.h

Is this correct or false positives.  If correct can you direct me to a clean
version

Thanks

--

Re: GDB + ddemangle

[drug via Digitalmars-d-announce]

20.04.2018 15:36, Mike Franklin пишет:

On Friday, 20 April 2018 at 10:36:25 UTC, drug wrote:

20.04.2018 13:03, Joakim пишет:


You are aware that gdb has built-in support for demangling D for 3-4 
years now?



But how to enable it? It doesn't work out of box at least for me.


I believe you enable it with `-demangle=dlang`

The original announcement is here: 
https://forum.dlang.org/post/rvoqllpimfskvlabp...@forum.dlang.org


There are a few posts on the forum with some example usages: 
https://forum.dlang.org/search?q=%22demangle%3Ddlang%22=1


Mike
thanks for reply! but gdb don't recognize this option - unknown option 
"--demangle=dlang"


```
$gdb --version
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
...
```

Or it is intended to work only using `objdump` etc?

Re: GDB + ddemangle

[Basile B. via Digitalmars-d-announce]

On Friday, 20 April 2018 at 12:28:03 UTC, Basile B. wrote:

On Friday, 20 April 2018 at 11:06:47 UTC, Mike Wey wrote:

On 20-04-18 12:36, drug wrote:

20.04.2018 13:03, Joakim пишет:


You are aware that gdb has built-in support for demangling D 
for 3-4 years now?


But how to enable it? It doesn't work out of box at least for 
me.


It should be automatic when the executable is build with 
debugging info. `-g`


it is not, clearly ;)


The problem is that one also needs to process the compiler output 
in an IDE, so finally it doesn't change anything to anything

Re: GDB + ddemangle

[Mike Franklin via Digitalmars-d-announce]

On Friday, 20 April 2018 at 10:36:25 UTC, drug wrote:

20.04.2018 13:03, Joakim пишет:


You are aware that gdb has built-in support for demangling D 
for 3-4 years now?


But how to enable it? It doesn't work out of box at least for 
me.


I believe you enable it with `-demangle=dlang`

The original announcement is here:  
https://forum.dlang.org/post/rvoqllpimfskvlabp...@forum.dlang.org


There are a few posts on the forum with some example usages:  
https://forum.dlang.org/search?q=%22demangle%3Ddlang%22=1


Mike

Re: GDB + ddemangle

[Basile B. via Digitalmars-d-announce]

On Friday, 20 April 2018 at 11:06:47 UTC, Mike Wey wrote:

On 20-04-18 12:36, drug wrote:

20.04.2018 13:03, Joakim пишет:


You are aware that gdb has built-in support for demangling D 
for 3-4 years now?


But how to enable it? It doesn't work out of box at least for 
me.


It should be automatic when the executable is build with 
debugging info. `-g`


it is not, clearly ;)

May 1: Traditional Maibaumaufstellung (Maypole erection) in Munich

[Seb via Digitalmars-d]

Hi all,

to all the people who arrive a bit early in Munich.
In Southern Germany Maibäume (Maypoles) are an old tradition 
about which people make a big fuzz.
So on the May 1st in and around Munich there will be small 
festivities for their erection.
Munich's city portal has a few pointers and a video from last 
year:


http://www.muenchen.de/veranstaltungen/events/erster-mai.html

And there are a few other sites with a more extensive list:

http://www.ganz-muenchen.de/freizeitfitness/volksfeste/maibaum/1mai.html
https://www.maibaum-kalender.de/uebersicht

See you soon.

[Issue 15386] std.format.formatValue usage hangs

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

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

vladvi...@gmail.com changed:

   What|Removed |Added

   Assignee|vladvi...@gmail.com |nob...@puremagic.com

--

[Issue 18785] New: No way to get list of overloads for a given template

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

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

  Issue ID: 18785
   Summary: No way to get list of overloads for a given template
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: simen.kja...@gmail.com

__traits(getOverloads) only works on regular functions, and do not include
templated overloads. Simply adding them to getOverloads's result would be a
breaking change. I therefore propose adding a new trait - getAllOverloads -
that returns all symbols in an overload set, be they types, templates,
functions, or otherwise.

--

[Issue 18742] std.regex: Using CodePointSet in AAs breaks if reference count changes

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

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

vladvi...@gmail.com changed:

   What|Removed |Added

 CC||vladvi...@gmail.com
   Assignee|nob...@puremagic.com|vladvi...@gmail.com

--

[Issue 15386] std.format.formatValue usage hangs

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

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

vladvi...@gmail.com changed:

   What|Removed |Added

 CC||vladvi...@gmail.com
   Assignee|nob...@puremagic.com|vladvi...@gmail.com

--

Re: GDB + ddemangle

[drug via Digitalmars-d-announce]

20.04.2018 14:06, Mike Wey пишет:

On 20-04-18 12:36, drug wrote:

20.04.2018 13:03, Joakim пишет:


You are aware that gdb has built-in support for demangling D for 3-4 
years now?



But how to enable it? It doesn't work out of box at least for me.


It should be automatic when the executable is build with debugging info. 
`-g`


is there a way to check feature availability? What version gdb should 
have etc?

Re: GDB + ddemangle

[Mike Wey via Digitalmars-d-announce]

On 20-04-18 12:36, drug wrote:

20.04.2018 13:03, Joakim пишет:


You are aware that gdb has built-in support for demangling D for 3-4 
years now?



But how to enable it? It doesn't work out of box at least for me.


It should be automatic when the executable is build with debugging info. 
`-g`


--
Mike Wey

Re: D vs nim

[Russel Winder via Digitalmars-d]

On Thu, 2018-04-19 at 16:50 +, Per Nordlöw via Digitalmars-d wrote:
> On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote:
> > P.S., the example on the language's frontpage is cool!
> > 
> > http://nim-lang.org/
> > 
> > Why should I be excited?
> > Nim is the only language that leverages automated proof 
> > technology to perform a disjoint check for your parallel code. 
> > Working on disjoint data means no locking is required and yet 
> > data races are impossible:
> 
> I believe Rust's rayon [1] can do this too...
> 
> [1] https://github.com/rayon-rs/rayon

Has anyone got Pony on their list of interesting languages?

-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


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

Re: GDB + ddemangle

[drug via Digitalmars-d-announce]

20.04.2018 13:03, Joakim пишет:


You are aware that gdb has built-in support for demangling D for 3-4 
years now?



But how to enable it? It doesn't work out of box at least for me.

[Issue 18784] New: Segfault due to dmd codegen interfacing with C++

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

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

  Issue ID: 18784
   Summary: Segfault due to dmd codegen interfacing with C++
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: atila.ne...@gmail.com

The following two files when compiled and linked result in a segfault when
using dmd but not ldc2:

d.d:

extern(C++) {
struct Struct {
pragma(mangle, "_ZN6StructC1Ei") this(int);
pragma(mangle, "_ZN6StructC1EOS_") this(Struct*);

this(Struct other) {
this();
}
}
}

void main() {
auto s = Struct(Struct(7));
}


cpp.cpp:

#include 

struct Struct {
Struct(int);
Struct(Struct&&);
};


Struct::Struct(int) {
printf("Oops\n");
}

Struct::Struct(Struct&&) { }


To reproduce:

clang++ -g -c cpp.cpp
dmd -g d.d cpp.o -L-lstdc++   # ldc2 works fine
./d


Preliminary analysis:

Removing the printf from the C++ constructor prevents the segfault. In fact, it
seems that the return value of printf is used to deference a pointer. Without
the printf, rax has the value it had before and everything works.

The bug only manifests if a temporary is passed directly to the by-value D
constructor. Changing `auto s = Struct(Struct(7))` to:

auto tmp = Struct(7);
auto s = Struct(tmp);

Makes the bug disappear.

Using ldc2 works, suggesting that the issue is due to dmd's codegen, especially
given what happens to rax as stated above.

This issue is preventing "just works" C++ integration.

--

Re: GDB + ddemangle

[Basile B. via Digitalmars-d-announce]

On Friday, 20 April 2018 at 10:03:53 UTC, Joakim wrote:

On Thursday, 19 April 2018 at 12:43:36 UTC, ANtlord wrote:
Hello! I've written a piece of glue code that helps to debug D 
code using GDB. The code glues together GDB and ddmangle. 
Checkout the link https://github.com/ANtlord/gdb-ddemangle


PRs are welcome!


You are aware that gdb has built-in support for demangling D 
for 3-4 years now?


I've been told this too, not so long ago, but actually i still 
feed GDB output with ddemangle too (for Coedit 'GDB commander' 
widget).

Re: GDB + ddemangle

[Joakim via Digitalmars-d-announce]

On Thursday, 19 April 2018 at 12:43:36 UTC, ANtlord wrote:
Hello! I've written a piece of glue code that helps to debug D 
code using GDB. The code glues together GDB and ddmangle. 
Checkout the link https://github.com/ANtlord/gdb-ddemangle


PRs are welcome!


You are aware that gdb has built-in support for demangling D for 
3-4 years now?


http://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git=search=HEAD=commit=ibuclaw

I don't know if Iain got all his patches in, but it demangles a 
lot of symbols for me already. However, I just started using the 
new lldb package in Termux, and I do miss it there. Otherwise, 
lldb is very nice and much more stable for me on 64-bit ARM.

Re: Feature to get or add value to an associative array.

[ag0aep6g via Digitalmars-d]

On Friday, 20 April 2018 at 09:24:26 UTC, Jonathan M Davis wrote:
The compiler assumes that a pointer is valid when determining 
whether code is @safe.

[...]
Basically, it verifies the @safety of pointers when they're 
created and then assumes that they're @safe after that.


Can't it do the same for ref returns? Unsafe stuff like returning 
a ref to a local is already disallowed, just like returning a 
pointer to a local. So the compiler checks the safety on 
creation, at least in some cases.


So, passing around a pointer is perfectly @safe, whereas taking 
the address of a ref return value to get a pointer is not.


It's still not clear to me how taking the address of a ref return 
is necessarily less safe than using a returned pointer. Do you 
maybe have an example in code that shows the difference?


It seems to me that refs and pointers are very much equivalent. I 
should always be able to turn one into the other.

[Issue 11742] cannot inizialize void initialized static variable in static constructor.

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

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #1 from RazvanN  ---
PR : https://github.com/dlang/dmd/pull/8198

--

Re: Feature to get or add value to an associative array.

[Jonathan M Davis via Digitalmars-d]

On Friday, April 20, 2018 10:56:37 ag0aep6g via Digitalmars-d wrote:
> On 04/20/2018 10:24 AM, Nick Treleaven wrote:
> > On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:
> >> You can get a pointer from the ref return:
> >>
> >> Value* p = ("key", { inserted = true; return Value.init;
> >> });
> >
> > This is not @safe, even with -dip1000:
> >
> > Error: cannot take address of ref return of f() in @safe function main
>
> Hm. Do you know why that's not allowed? I can't see how it would be less
> safe than returning a pointer, and I can't find a mention of it in DIP
> 1000 [1]. Maybe it's just a case of incomplete/buggy implementation?
>
>
> [1] https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

The compiler assumes that a pointer is valid when determining whether code
is @safe. It then disallows operations that it can't guarantee are @safe
even if the pointer is valid, and it disallows taking the address in cases
where it can't guarantee that that's @safe. Basically, it verifies the
@safety of pointers when they're created and then assumes that they're @safe
after that. So, passing around a pointer is perfectly @safe, whereas taking
the address of a ref return value to get a pointer is not.

- Jonathan M Davis

Re: dxml 0.3.0 released

[Kagamin via Digitalmars-d-announce]

On Friday, 20 April 2018 at 08:45:45 UTC, Dejan Lekic wrote:
Jonathan, are the interfaces in the dom module generated from 
the IDL code from W3C?


It's not W3C DOM :)

Re: dxml 0.3.0 released

[Jonathan M Davis via Digitalmars-d-announce]

On Friday, April 20, 2018 08:45:45 Dejan Lekic via Digitalmars-d-announce 
wrote:
> On Thursday, 19 April 2018 at 14:40:58 UTC, Jonathan M Davis
>
> wrote:
> > Well, since I'm going to be talking about dxml at dconf, and
> > it's likely that I'll be talking about stuff that was not in
> > the 0.2.* releases, it seemed like I should get a new release
> > out before dconf. So, here it is.
> >
> > dxml 0.3.0 has now been released.
> >
> > I won't repeat everything that's in the changelog, but the
> > biggest changes are that writer support has now been added, and
> > it's now possible to configure how the parser handles
> > non-standard entity references.
> >
> > Please report any bugs that you find via github.
> >
> > Changelog: http://jmdavisprog.com/changelog/dxml/0.3.0.html
> > Documentation: http://jmdavisprog.com/docs/dxml/0.3.0/
> > Github: https://github.com/jmdavis/dxml/tree/v0.3.0
> > Dub: http://code.dlang.org/packages/dxml
> >
> > - Jonathan M Davis
>
> I am happy to see dxml moving on!
> Jonathan, are the interfaces in the dom module generated from the
> IDL code from W3C?

No, that's not something that I'm familiar with. I just made up the API
based on what made sense to me. I basically took the API that
EntityRange.Entity has and morphed it into what made sense for a tree
structure.

- Jonathan M Davis

Re: Feature to get or add value to an associative array.

[ag0aep6g via Digitalmars-d]

On 04/20/2018 10:24 AM, Nick Treleaven wrote:

On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:

You can get a pointer from the ref return:

    Value* p = ("key", { inserted = true; return Value.init; });


This is not @safe, even with -dip1000:

Error: cannot take address of ref return of f() in @safe function main


Hm. Do you know why that's not allowed? I can't see how it would be less 
safe than returning a pointer, and I can't find a mention of it in DIP 
1000 [1]. Maybe it's just a case of incomplete/buggy implementation?



[1] https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

Re: Feature to get or add value to an associative array.

[Dominikus Dittes Scherkl via Digitalmars-d]

On Thursday, 19 April 2018 at 08:20:02 UTC, Giles Bathgate wrote:
On Wednesday, 18 April 2018 at 21:04:53 UTC, Jordan Wilson 
wrote:
Thinking seems sound, although having a name starting with 
"get" does have the advantage of being more related to the 
existing get.


Ah yes, good point. I think now we've had the discussion about 
other use cases though that ultimately there might need to be 
an "atomic" AddOrUpdate style function too, which I was 
thinking could just be called 'update'. The necessity to keep 
them all starting with get seemed less important.


How about something like "forceGet" to make clear you will get 
it, even if it wasn't there before.

Re: dxml 0.3.0 released

[Dejan Lekic via Digitalmars-d-announce]

On Thursday, 19 April 2018 at 14:40:58 UTC, Jonathan M Davis 
wrote:
Well, since I'm going to be talking about dxml at dconf, and 
it's likely that I'll be talking about stuff that was not in 
the 0.2.* releases, it seemed like I should get a new release 
out before dconf. So, here it is.


dxml 0.3.0 has now been released.

I won't repeat everything that's in the changelog, but the 
biggest changes are that writer support has now been added, and 
it's now possible to configure how the parser handles 
non-standard entity references.


Please report any bugs that you find via github.

Changelog: http://jmdavisprog.com/changelog/dxml/0.3.0.html
Documentation: http://jmdavisprog.com/docs/dxml/0.3.0/
Github: https://github.com/jmdavis/dxml/tree/v0.3.0
Dub: http://code.dlang.org/packages/dxml

- Jonathan M Davis


I am happy to see dxml moving on!
Jonathan, are the interfaces in the dom module generated from the 
IDL code from W3C?

[Issue 7023] alias to overload set in template doesn't work

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

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

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||simen.kja...@gmail.com
 Resolution|--- |FIXED

--- Comment #3 from Simen Kjaeraas  ---
Works in 2.079.1, and according to comment 2 seems to have worked for 2.061.
Feel free to reopen if it's found to still be a problem.

--

Re: Feature to get or add value to an associative array.

[Nick Treleaven via Digitalmars-d]

On Wednesday, 18 April 2018 at 16:04:13 UTC, Giles Bathgate wrote:
I understand where you are coming from, but I am not sure it is 
appropriate to shoehorn every use case into one api.


It is not shoehorning, the difference here is just returning by 
ref vs pointer. I understand that, as the pointer address is not 
needed by the caller, it is cleaner to use ref. The problem is 
that local refs are not supported by D, and so I would need to do 
this (at least in safe code):


import std.functional : unaryFun;
bool ins;
aa.update("key", {ins = true; return 1;}).unaryFun!((v){ if (ins) 
v++; });


This seems pretty convoluted. It could be made a bit better if D 
supported UFCS for lambdas, then unaryFun wouldn't be needed.


BTW, I like the name `update`.

void createOrUpdate(K, V)(ref V[K] aa, K key, V delegate() 
create, void delegate(V*) update);


Again, would the delegate calls always be inlined, in all cases?

I think having a low-level API in druntime is appropriate, it's a 
runtime library after all.

Re: Issues with debugging GC-related crashes #2

[Kagamin via Digitalmars-d]

On Monday, 16 April 2018 at 16:36:48 UTC, Matthias Klumpp wrote:
#2  0x751341c8 in 
_D2rt4util9container5treap__T5TreapTS2gc11gcinterface5RangeZQBf7opApplyMFNbMDFNbKQBtZiZ9__lambda2MFNbKxSQCpQCpQCfZi (e=...) at treap.d:47
dg = {context = 0x7fffc140 "\320\065\206", funcptr 
= 0x75121d10 
<_D2gc4impl12conservativeQw3Gcx7markAllMFNbbZ14__foreachbody3MFNbKSQCm11gcinterface5RangeZi>}
#3  0x75134238 in 
_D2rt4util9container5treap__T5TreapTS2gc11gcinterface5RangeZQBf13opApplyHelperFNbxPSQDeQDeQDcQCv__TQCsTQCpZQDa4NodeMDFNbKxSQDiQDiQCyZiZi (node=0x7568700, dg=...) at treap.d:221


Indeed, this is iteration over Treap!Range used to store ranges 
added with addRange method.

https://github.com/ldc-developers/druntime/blob/ldc/src/gc/impl/conservative/gc.d#L2182

[Issue 18782] Documentation error: ProtectionAttributes should say Visibility Attributes

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

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

ag0aep6g  changed:

   What|Removed |Added

   Keywords||pull
 CC||ag0ae...@gmail.com
   Hardware|x86 |All
 OS|Mac OS X|All
   Severity|enhancement |minor

--- Comment #1 from ag0aep6g  ---
https://github.com/dlang/dlang.org/pull/2350

--

Re: Feature to get or add value to an associative array.

[Nick Treleaven via Digitalmars-d]

On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:

You can get a pointer from the ref return:

Value* p = ("key", { inserted = true; return 
Value.init; });


This is not @safe, even with -dip1000:

Error: cannot take address of ref return of f() in @safe function 
main

[Issue 4074] function overloading fails

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

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

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||simen.kja...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Simen Kjaeraas  ---
Cannot replicate this on 2.079.1 under Windows 10.

--

Re: wstring double quotes to string double quotes

[ag0aep6g via Digitalmars-d-learn]

On 04/20/2018 09:45 AM, Joel wrote:

On Friday, 20 April 2018 at 02:46:14 UTC, Jonathan M Davis wrote:

[...]

please create a bug report

[...]

Done.


For reference, that was .

But someone else was faster and filed 
 without giving notice here.

[Issue 18781] std.string.replace: RangeError when replacing with inconsistent string types

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

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

ag0aep6g  changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #2 from ag0aep6g  ---
Related forum thread:
https://forum.dlang.org/post/xlcdoarfkpehymihk...@forum.dlang.org

If you make a bug report for a forum post, please leave a link to the bug in
the forum thread, so that we don't get duplicates.

--

[Issue 18781] std.string.replace: RangeError when replacing with inconsistent string types

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

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

ag0aep6g  changed:

   What|Removed |Added

 CC||joel...@gmail.com

--- Comment #1 from ag0aep6g  ---
*** Issue 18783 has been marked as a duplicate of this issue. ***

--

[Issue 18783] crash with replace

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

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

ag0aep6g  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #1 from ag0aep6g  ---
Looks like someone else was faster: issue 18781.

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

--

Re: wstring double quotes to string double quotes

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, April 20, 2018 07:45:14 Joel via Digitalmars-d-learn wrote:
> On Friday, 20 April 2018 at 02:46:14 UTC, Jonathan M Davis wrote:
> > On Thursday, April 19, 2018 23:24:05 Joel via
> >
> > Digitalmars-d-learn wrote:
> >> On Thursday, 19 April 2018 at 21:57:28 UTC, Adam D. Ruppe
> >>
> >> wrote:
> >> > [...]
> >>
> >> That worked! Thanks Adam.
> >
> > Given that these functions really shouldn't be throw
> > RangeErrors, please create a bug report with example code that
> > can someone can just run to reproduce the issue (your example
> > isn't runnable as-is). That way, the bug can be fixed.
> > Otherwise, it's probably just going to be lost, and someone
> > else may hit it in the future. Thanks.
> >
> > https://issues.dlang.org
> >
> > - Jonathan M Davis
>
> Done.

Thanks!

- Jonathan M Davis

Re: wstring double quotes to string double quotes

[Joel via Digitalmars-d-learn]

On Friday, 20 April 2018 at 02:46:14 UTC, Jonathan M Davis wrote:
On Thursday, April 19, 2018 23:24:05 Joel via 
Digitalmars-d-learn wrote:
On Thursday, 19 April 2018 at 21:57:28 UTC, Adam D. Ruppe 
wrote:

> [...]

That worked! Thanks Adam.


Given that these functions really shouldn't be throw 
RangeErrors, please create a bug report with example code that 
can someone can just run to reproduce the issue (your example 
isn't runnable as-is). That way, the bug can be fixed. 
Otherwise, it's probably just going to be lost, and someone 
else may hit it in the future. Thanks.


https://issues.dlang.org

- Jonathan M Davis


Done.

[Issue 18783] New: crash with replace

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

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

  Issue ID: 18783
   Summary: crash with replace
   Product: D
   Version: D2
  Hardware: x86_64
OS: Mac OS X
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: joel...@gmail.com

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

"”"d.replace("”", `"`); // crashes with a range error (notice the other
double quotes)
}

//(this is my first ever bug report)

--

[Issue 18776] Internal error: dmd/backend/symbol.c 1043

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

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 2855] __traits: no way to get overloads and information for non-instance methods

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

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

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||simen.kja...@gmail.com
 Resolution|--- |FIXED

--- Comment #7 from Simen Kjaeraas  ---
Current DMD handles all cases in this issue, and has for a long time.
getStaticFunctions is not in DMD, but can easily be implemented in a library.

--

OST to PST Converter

[mariahcarey via Digitalmars-d]

There is a fast and effective OST to PST Converter tool which can 
export OST file to PST file format easily, without affecting the 
original information. You can work on the OST to PST Converter 
software without any hesitation because it does not require any 
extra technical skill to install and run this ATS OST to PST 
Converter software.


Get more details:  
http://www.bulkecommerce.com/store/ats-ost-to-pst-converter-software-159.html