Re: Is this rdmd bug or my fault ?

2016-01-09 Thread zabruk70 via Digitalmars-d-learn
On Friday, 8 January 2016 at 22:36:49 UTC, Tobi G. wrote: On Saturday, 9 January 2016 at 01:43:57 UTC, Ivan Kazmenko wrote: I get also a compilation error (with rdmd and -g). Thanks Tobi and Ivan. https://issues.dlang.org/show_bug.cgi?id=15533

Changing Name of a thread

2016-01-09 Thread Keywan Ghadami via Digitalmars-d-learn
Hello, i am trying to the set the name of thread with: import core.thread; auto thisThread = Thread.getThis(); thisThread.name = "kiwi"; but GDB prints the name of the programm ("helloworld") [Thread debugging using libthread_db enabled] Using host libthread_db library "/li

version in enum

2016-01-09 Thread Øivind via Digitalmars-d-learn
Hi, Why doesn't this work? Seems like it should: enum { A = 1, version(xx) { B = 2 } } void main() { } Compilation output: /d732/f174.d(5): Error: basic type expected, not version /d732/f174.d(5): Error: no identifier for declarator int /d732/f

Re: version in enum

2016-01-09 Thread Adam D. Ruppe via Digitalmars-d-learn
On Saturday, 9 January 2016 at 12:43:32 UTC, Øivind wrote: Why doesn't this work? Seems like it should: D defines version to only work on *complete* blocks. You're trying to use it on a partial block there. You'll have to try something else. Perhaps copying the whole enum in the different v

Re: version in enum

2016-01-09 Thread Basile B. via Digitalmars-d-learn
On Saturday, 9 January 2016 at 12:43:32 UTC, Øivind wrote: Hi, Why doesn't this work? Seems like it should: enum { A = 1, version(xx) { B = 2 } } It's not allowed in the grammar but I agree with you, it could be useful. Recent example where it could:

Re: Linking a DLL to a DLL with packages

2016-01-09 Thread Thalamus via Digitalmars-d-learn
On Friday, 8 January 2016 at 12:13:15 UTC, Benjamin Thaut wrote: On Thursday, 7 January 2016 at 19:29:43 UTC, Thalamus wrote: Hi everyone, First off, I've been working with D for a couple of weeks now and I think it's the bee's knees! :) Except for DLLs. thanks! :) Dlls don't currently wor

UFCS vs auto-completion support

2016-01-09 Thread Jay Norwood via Digitalmars-d-learn
I'm reading Jack Stouffer's documentation: http://jackstouffer.com/blog/nd_slice.html considering the UFCS example below and how it would impact auto-completion support. auto slice = sliced(iota(1000), 5, 5, 40); auto slice = 1000.iota.sliced(5, 5, 40); Seems like auto-complete support for t

Re: UFCS vs auto-completion support

2016-01-09 Thread cym13 via Digitalmars-d-learn
On Saturday, 9 January 2016 at 15:50:33 UTC, Jay Norwood wrote: I'm reading Jack Stouffer's documentation: http://jackstouffer.com/blog/nd_slice.html considering the UFCS example below and how it would impact auto-completion support. auto slice = sliced(iota(1000), 5, 5, 40); auto slice = 10

Re: Linking a DLL to a DLL with packages

2016-01-09 Thread tcak via Digitalmars-d-learn
On Friday, 8 January 2016 at 12:13:15 UTC, Benjamin Thaut wrote: On Thursday, 7 January 2016 at 19:29:43 UTC, Thalamus wrote: Hi everyone, First off, I've been working with D for a couple of weeks now and I think it's the bee's knees! :) Except for DLLs. thanks! :) Dlls don't currently wor

Re: Changing Name of a thread

2016-01-09 Thread tcak via Digitalmars-d-learn
On Saturday, 9 January 2016 at 11:02:53 UTC, Keywan Ghadami wrote: Hello, i am trying to the set the name of thread with: import core.thread; auto thisThread = Thread.getThis(); thisThread.name = "kiwi"; but GDB prints the name of the programm ("helloworld") [Thread debugging u

Re: UFCS vs auto-completion support

2016-01-09 Thread Jay Norwood via Digitalmars-d-learn
On Saturday, 9 January 2016 at 16:00:51 UTC, cym13 wrote: I may be very naive but how is the second form more complicated than the first? Pretending these were regular function implementations ... 1000. 1000.iota. 1000.iota.sliced( iota( sliced( sliced(iota( I wouldn't be surprised if

Re: Changing Name of a thread

2016-01-09 Thread Keywan Ghadami via Digitalmars-d-learn
On Saturday, 9 January 2016 at 17:30:47 UTC, tcak wrote: I tried your code with a little addition as follows: [code] import core.sys.posix.pthread; import std.string; import std.stdio; extern(C) int pthread_setname_np(pthread_t, const char*); void main(){ pthread_setname_np(pthread_self(),

assumeSorted can't access private function when compiling with -debug

2016-01-09 Thread FreeSlave via Digitalmars-d-learn
Here's code: private { import std.algorithm; import std.range; import std.typecons; alias Tuple!(int, string) Data; } private bool myCmp(Data a, Data b) { return a[0] < b[0]; } auto bar() { return [Data(1, "one"), Data(2, "two")].assumeSorted!myCmp; } void main() {

concurrency and standard logger of std.experimental.logger

2016-01-09 Thread sanjayss via Digitalmars-d-learn
Is there a way to include some form of thread-id in the standard logger log messages without resorting to the use of the 'f' functions to log this info too?

sliced().array compatibility with parallel?

2016-01-09 Thread Jay Norwood via Digitalmars-d-learn
I'm playing around with win32, v2.069.2 dmd and "dip80-ndslice": "~>0.8.8". If I convert the 2D slice with .array(), should that first dimension then be compatible with parallel foreach? I find that without using parallel, all the means get computed, but with parallel, only about half of the

Re: sliced().array compatibility with parallel?

2016-01-09 Thread Jay Norwood via Digitalmars-d-learn
for example, means[63] through means[251] are consistently all NaN when using parallel in this test, but are all computed double values when parallel is not used.

Re: sliced().array compatibility with parallel?

2016-01-09 Thread Ilya Yaroshenko via Digitalmars-d-learn
On Saturday, 9 January 2016 at 23:20:00 UTC, Jay Norwood wrote: I'm playing around with win32, v2.069.2 dmd and "dip80-ndslice": "~>0.8.8". If I convert the 2D slice with .array(), should that first dimension then be compatible with parallel foreach? [...] It is a bug (Slice or Parallel ?)

Re: sliced().array compatibility with parallel?

2016-01-09 Thread Jay Norwood via Digitalmars-d-learn
On Sunday, 10 January 2016 at 00:41:35 UTC, Ilya Yaroshenko wrote: It is a bug (Slice or Parallel ?). Please fill this issue. Slice should work with parallel, and array of slices should work with parallel. Ok, thanks, I'll submit it.

Re: sliced().array compatibility with parallel?

2016-01-09 Thread Ilya Yaroshenko via Digitalmars-d-learn
On Saturday, 9 January 2016 at 23:20:00 UTC, Jay Norwood wrote: I'm playing around with win32, v2.069.2 dmd and "dip80-ndslice": "~>0.8.8". If I convert the 2D slice with .array(), should that first dimension then be compatible with parallel foreach? I find that without using parallel, all t

Re: sliced().array compatibility with parallel?

2016-01-09 Thread Ilya Yaroshenko via Digitalmars-d-learn
On Saturday, 9 January 2016 at 23:20:00 UTC, Jay Norwood wrote: I'm playing around with win32, v2.069.2 dmd and "dip80-ndslice": "~>0.8.8". If I convert the 2D slice with .array(), should that first dimension then be compatible with parallel foreach? [...] Oh... there is no bug. means must

Re: sliced().array compatibility with parallel?

2016-01-09 Thread Jay Norwood via Digitalmars-d-learn
On Sunday, 10 January 2016 at 00:47:29 UTC, Ilya Yaroshenko wrote: This is a bug in std.parallelism :-) ok, thanks. I'm using your code and reduced it a bit. Looks like it has some interaction with executing vec.sum. If I substitute a simple assign of a double value, then all the values a

Re: sliced().array compatibility with parallel?

2016-01-09 Thread Jay Norwood via Digitalmars-d-learn
On Sunday, 10 January 2016 at 01:16:43 UTC, Ilya Yaroshenko wrote: On Saturday, 9 January 2016 at 23:20:00 UTC, Jay Norwood wrote: I'm playing around with win32, v2.069.2 dmd and "dip80-ndslice": "~>0.8.8". If I convert the 2D slice with .array(), should that first dimension then be compatible

Re: version in enum

2016-01-09 Thread Jonathan M Davis via Digitalmars-d-learn
On Saturday, January 09, 2016 13:32:49 Adam D. Ruppe via Digitalmars-d-learn wrote: > On Saturday, 9 January 2016 at 12:43:32 UTC, Øivind wrote: > > Why doesn't this work? Seems like it should: > > D defines version to only work on *complete* blocks. You're > trying to use it on a partial block th

Re: sliced().array compatibility with parallel?

2016-01-09 Thread Jay Norwood via Digitalmars-d-learn
On Sunday, 10 January 2016 at 01:54:18 UTC, Jay Norwood wrote: ok, thanks. That works. I'll go back to trying ndslice now. The parallel time for this case is about a 2x speed-up on my corei5 laptop, debug build in windows32, dmd. D:\ec_mars_ddt\workspace\nd8>nd8.exe parallel time msec:2495

issue porting C++/glm/openGL to D/gl3n/openGL

2016-01-09 Thread WhatMeWorry via Digitalmars-d-learn
Just translating some simple C++/glm/opengl tutorial code to D/gl3n/opengl and I'm coming across more friction than I expected. I've got a square centered at my window which is rotated by 45 degrees (counter clockwise) and then moved to the lower right quadrant. // C++ glm opengl code glm:

Re: sliced().array compatibility with parallel?

2016-01-09 Thread Ilya via Digitalmars-d-learn
On Sunday, 10 January 2016 at 02:43:05 UTC, Jay Norwood wrote: On Sunday, 10 January 2016 at 01:54:18 UTC, Jay Norwood wrote: [...] The parallel time for this case is about a 2x speed-up on my corei5 laptop, debug build in windows32, dmd. [...] I will add significantly faster pairwise sum

Re: issue porting C++/glm/openGL to D/gl3n/openGL

2016-01-09 Thread Mike Parker via Digitalmars-d-learn
On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Is gl3n not a direct replacement for glm? From the very top of the gl3n github page: "OpenGL Maths for D (not glm for D)." So, no, it is not. You might want to start with the glm documentaion [1]. [1] http://dav1dde.github

Re: issue porting C++/glm/openGL to D/gl3n/openGL

2016-01-09 Thread WhatMeWorry via Digitalmars-d-learn
On Sunday, 10 January 2016 at 04:37:43 UTC, Mike Parker wrote: On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Is gl3n not a direct replacement for glm? From the very top of the gl3n github page: "OpenGL Maths for D (not glm for D)." So, no, it is not. You might want to s

Re: issue porting C++/glm/openGL to D/gl3n/openGL

2016-01-09 Thread rsw0x via Digitalmars-d-learn
On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Just translating some simple C++/glm/opengl tutorial code to D/gl3n/opengl and I'm coming across more friction than I expected. I've got a square centered at my window which is rotated by 45 degrees (counter clockwise) and then m

Re: issue porting C++/glm/openGL to D/gl3n/openGL

2016-01-09 Thread WhatMeWorry via Digitalmars-d-learn
On Sunday, 10 January 2016 at 06:35:34 UTC, rsw0x wrote: On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Just translating some simple C++/glm/opengl tutorial code to D/gl3n/opengl and I'm coming across more friction than I expected. I've got a square centered at my window whic