Re: Error calling geqrs function from lubeck package.

2018-04-20 Thread 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?

2018-04-20 Thread 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

2018-04-20 Thread 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.

Better multithreading with D

2018-04-20 Thread 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: Are Fibers just broken in D?

2018-04-20 Thread 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?

2018-04-20 Thread 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

Re: Are Fibers just broken in D?

2018-04-20 Thread 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?

2018-04-20 Thread 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: wstring double quotes to string double quotes

2018-04-20 Thread 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.

Re: wstring double quotes to string double quotes

2018-04-20 Thread 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

2018-04-20 Thread 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.