Re: Are templates with variadic value parameters possible?

On Friday, 15 July 2016 at 04:38:03 UTC, Basile B. wrote: two obvious: - recursive template. - staticIota in a foreach. (aliasSeqOf!(iota(1, T.length)) even better: template sameType(T...) { import std.meta; static if (!T.length) enum sameType = false; else enum

Re: Card on fire

On 7/9/2016 7:43 PM, Andrei Alexandrescu wrote: Got a text from Walter - his famous fanless graphics card caught fire along with the motherboard. He'll be outta commission for a few days. -- Andrei Back in business now with a new motherboard and new graphics card, which also wound up forcing

Re: dcompute is nearing minimal functionality

On Thursday, 14 July 2016 at 03:30:44 UTC, Nicholas Wilson wrote: DCompute is my effort to target CUDA and SPIR to enable hassle free native execution on the gpu. It is a D library +modification of LDC and is available at https://github.com/thewilsonator/ldc/tree/dcompute The compiler is

Re: Are templates with variadic value parameters possible?

On Friday, 15 July 2016 at 04:31:08 UTC, Devin Hill wrote: Thanks, that way of doing it does work. I guess that means there's no easy way to make sure all T are the same type without a template constraint? Yes, immediatly, now, I think that a contraint has to be used. But you have several

Re: Are templates with variadic value parameters possible?

On Friday, 15 July 2016 at 04:08:19 UTC, Basile B. wrote: With D style variadics it works, you can build the array from the list and have a static array: = void foo(T...)(T t) { T[0][T.length] tt = [t]; // T[0] is the type writeln(tt); // [1,2,3] static

[OT] Re: Card on fire

On Friday, 15 July 2016 at 00:17:35 UTC, Ali Çehreli wrote: On 07/09/2016 09:11 PM, A.B wrote: On Sunday, 10 July 2016 at 02:43:42 UTC, Andrei Alexandrescu wrote: Got a text from Walter - his famous fanless graphics card caught fire along with the motherboard. He'll be outta commission for a

Re: Are templates with variadic value parameters possible?

On Friday, 15 July 2016 at 03:43:49 UTC, Devin Hill wrote: Hi everyone, I have a struct template which takes an integer n, and then has a constructor taking that many arguments of type long, which looks like: struct Struct(int n) { this(long[n] nums...) { /* stuff */ } } This works and

Are templates with variadic value parameters possible?

Hi everyone, I have a struct template which takes an integer n, and then has a constructor taking that many arguments of type long, which looks like: struct Struct(int n) { this(long[n] nums...) { /* stuff */ } } This works and lets me change n for each instantiation, but I wanted to

Re: Taking D to GDC Europe - let's make this tight

On Tuesday, 12 July 2016 at 11:27:18 UTC, Ethan Watson wrote: http://schedule.gdceurope.com/session/d-using-an-emerging-language-in-quantum-break My proposal for a talk has been accepted, and I'll be in Cologne next month presenting to industry peers. Speaking of the binding system,

Re: persistence, serialization, history (run-to-run) in small self-contained program

On Thursday, 14 July 2016 at 08:28:56 UTC, Jacob Carlborg wrote: On 2016-07-14 07:18, dan wrote: I'm writing a small program (compiled with gdc on xubuntu 16.04). I would like it to remember a little data (a few kilobytes maybe). . My main concern is minimizing program complexity.

Type constructor with new size

How can I create a new type NT from type T that such that NT is compatible with T when reduced to the size of T, but has size n? Another way to see it is that I would like to construct a type at compile time that has the same layout as another type but padded exactly by n - T.sizeof bytes. It

Re: Card on fire

On 07/09/2016 09:11 PM, A.B wrote: On Sunday, 10 July 2016 at 02:43:42 UTC, Andrei Alexandrescu wrote: Got a text from Walter - his famous fanless graphics card caught fire along with the motherboard. He'll be outta commission for a few days. -- Andrei lol

Re: Card on fire

On 07/11/2016 02:11 PM, Walter Bright wrote: On 7/9/2016 9:11 PM, A.B wrote: https://www.youtube.com/watch?v=NOErZuzZpS8 You must be older than me to think of that song! Great music! I was thinking how dangerous that show was then I found this on Wikipedia: Brown quickly earned a

[Issue 15995] std.conv.text and friends can be made faster with std.array.appender

https://issues.dlang.org/show_bug.cgi?id=15995 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

Re: Vision for the D language - stabilizing complexity?

On 7/14/2016 6:26 AM, Chris wrote: Now, now. Where's your sense of humor? The thing is, he's just here to troll us. His posts all follow the same pattern of relentlessly finding nothing good whatsoever in D, and we're all idiots. There's no evidence he's ever written a line of D, his

[Issue 15995] std.conv.text and friends can be made faster with std.array.appender

https://issues.dlang.org/show_bug.cgi?id=15995 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/f678909768536ad8bdd3e4ee30c793b6d36bbaaa Fix Issue 15995: std.conv.text and friends can be made

Re: Why modules is so strongly limited?

On 7/14/2016 6:37 AM, jmh530 wrote: On Thursday, 14 July 2016 at 09:36:17 UTC, Jonathan M Davis wrote: On Wednesday, July 13, 2016 20:58:02 imbaFireFenix via Digitalmars-d wrote: If we didn't do it that way, then it would be a lot harder to figure out where all of the code for a given module

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 18:49:36 UTC, Steven Schveighoffer wrote: If what you wrote is UB (as it is in D), then the compiler can go ahead and assign 5 to y. In C++, the compiler has to reload x, because it may have changed. Someone explained this to me recently on the NG. -Steve

[Issue 16283] [Modules]

https://issues.dlang.org/show_bug.cgi?id=16283 --- Comment #4 from Henry Block --- To be honest, I might have opened a can of worms here. The spec also suggestion you can put abstract bool x; at module scope in a D file, which isn't quite right :-) I suppose I was

[Issue 16283] [Modules]

https://issues.dlang.org/show_bug.cgi?id=16283 --- Comment #3 from Henry Block --- (In reply to Steven Schveighoffer from comment #1) > I don't think this is an enhancement, it's a bug. I suppose that's a bug in the Report Bug button on the spec site then! :-) --

[Issue 16283] [Modules]

https://issues.dlang.org/show_bug.cgi?id=16283 --- Comment #2 from Steven Schveighoffer --- (In reply to Steven Schveighoffer from comment #1) > I don't think this is an enhancement, it's a bug. Clarification: it's not a bug in the compiler, it's a bug in the spec! --

[Issue 16283] [Modules]

https://issues.dlang.org/show_bug.cgi?id=16283 Steven Schveighoffer changed: What|Removed |Added Keywords||spec

[Issue 16283] New: [Modules]

https://issues.dlang.org/show_bug.cgi?id=16283 Issue ID: 16283 Summary: [Modules] Product: D Version: D2 Hardware: All URL: http://dlang.org/ OS: All Status: NEW Severity: enhancement

Re: Why modules is so strongly limited?

On Wednesday, 13 July 2016 at 20:58:02 UTC, imbaFireFenix wrote: Why modules is so strongly limited ? Because this are like that.

[Issue 16273] [REG 2.072a] dmd segfault with inheritance, templates, override

https://issues.dlang.org/show_bug.cgi?id=16273 --- Comment #1 from ag0ae...@gmail.com --- Digger says this was introduced by https://github.com/dlang/dmd/pull/5695 --

Re: DMD RPM

El 14/07/16 a les 21:57, Dicebot via Digitalmars-d ha escrit: > Great news! I haven't used d-apt version since 2.068 because we started to > package our own internal flavor at work but this will fix one of two big > annoyances. Another bit was x-window dependency needed for caling `dmd -man` >

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 20:09:26 UTC, Ola Fosheim Grøstad wrote: Excuses such as «system programming is complex therefore D must be this complex» is not a position that should be accepted. And please note that this horrible excuse is propagate in the C++ community too. Time and time

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 19:17:06 UTC, Chris wrote: I certainly don't impose my view on others. The only reason I was going ad hominem was to get you on board in a more substantial manner than engaging in random discussions on the forum. That won't change anything. It's not a man-hour

Re: Vision for the D language - stabilizing complexity?

On 7/14/2016 11:49 AM, Steven Schveighoffer wrote: In C++, the compiler has to reload x, because it may have changed. That's right. I learned that the hard way, when the original optimizer would assume that x hadn't changed. It broke a surprising amount of code. It also means that the

Re: Templates args

On Thursday, 14 July 2016 at 19:48:38 UTC, ag0aep6g wrote: Make F an alias parameter: struct Neurons_layer(T = float, size_t neurons_num = 0, alias F = Sigmoid) if(isFloatingPoint!T && is(typeof(F!T.Function))) { ... private: alias Function = F!T.Function; } unittest {

Re: DMD RPM

On Thursday, 14 July 2016 at 18:54:41 UTC, Jordi Sayol wrote: El 14/07/16 a les 17:13, Dicebot via Digitalmars-d ha escrit: Very likely it has same packaging mistake as DMD in d-apt, listing gcc-multilib dependencies as mandatory and not optional, even if you are never going to cross-compile

Re: Vision for the D language - stabilizing complexity?

On 7/13/2016 4:48 AM, John Colvin wrote: Pointer arithmetic in objects is really quite dangerous w.r.t. immutability/const. Right, and one reason why pointer arithmetic isn't allowed in @safe code.

Re: Templates args

On Thursday, 14 July 2016 at 19:48:20 UTC, Lodovico Giaretta wrote: You don't need Sigmoid!float at all. This will work: Neurons_layer!(float, 5) nf; as you provided a default value for the third argument. Yes, default init is present, but double, real types are desirable

Re: Templates args

On Thursday, 14 July 2016 at 19:28:23 UTC, Andrey wrote: On Thursday, 14 July 2016 at 19:27:14 UTC, Andrey wrote: [...] struct Sigmoid(T) { [...] } struct Neurons_layer(T = float, size_t neurons_num = 0, F = Sigmoid!T) if(isFloatingPoint!T && is(typeof(F.Function))) { [...]

Re: Templates args

On 7/14/16 3:28 PM, Andrey wrote: On Thursday, 14 July 2016 at 19:27:14 UTC, Andrey wrote: struct Neurons_layer(T = float, size_t neurons_num = 0, F = Sigmoid!T) if(isFloatingPoint!T && is(typeof(F.Function))) { private: static if(neurons_num > 0) T[neurons_num]

Re: Templates args

On Thursday, 14 July 2016 at 19:28:23 UTC, Andrey wrote: On Thursday, 14 July 2016 at 19:27:14 UTC, Andrey wrote: Hi guys! Help a newbie please. Playing with D and trying to understand some features. Here is my try to carry out my code from C++ project to D struct Sigmoid(T) { const T

Re: Templates args

On Thursday, 14 July 2016 at 19:27:14 UTC, Andrey wrote: Hi guys! Help a newbie please. Playing with D and trying to understand some features. Here is my try to carry out my code from C++ project to D struct Sigmoid(T) { const T Function(T value) { ... } const T

Templates args

Hi guys! Help a newbie please. Playing with D and trying to understand some features. Here is my try to carry out my code from C++ project to D struct Sigmoid(T) { const T Function(T value) { ... } const T DerivateFunction(const T value) { ... } } struct Neurons_layer(T =

[Issue 16282] New: Partial permutation/nextPermutation in std.algorithm

https://issues.dlang.org/show_bug.cgi?id=16282 Issue ID: 16282 Summary: Partial permutation/nextPermutation in std.algorithm Product: D Version: D2 Hardware: All URL: http://dlang.org/library/std/algorithm/sorting.html

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 18:36:26 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 18:23:54 UTC, Chris wrote: On Thursday, 14 July 2016 at 18:00:36 UTC, Ola Fosheim Grøstad wrote: You were going ad hominem for no good reason. Here is a pretty good rule: if you don't think

[Issue 16281] std.format.formattedRead should use ref instead of requiring pointers

https://issues.dlang.org/show_bug.cgi?id=16281 Jack Stouffer changed: What|Removed |Added Keywords||safe --

[Issue 16281] New: std.format.formattedRead should use ref instead of requiring pointers

https://issues.dlang.org/show_bug.cgi?id=16281 Issue ID: 16281 Summary: std.format.formattedRead should use ref instead of requiring pointers Product: D Version: D2 Hardware: All OS: All Status:

Re: DMD RPM

El 14/07/16 a les 17:13, Dicebot via Digitalmars-d ha escrit: > Very likely it has same packaging mistake as DMD in d-apt, listing > gcc-multilib dependencies as mandatory and not optional, even if you are > never going to cross-compile for i686 >From dmd v2.071.0, "gcc-multilib" dependency is

Re: Vision for the D language - stabilizing complexity?

On 7/14/16 1:46 PM, Jesse Phillips wrote: On Thursday, 14 July 2016 at 16:47:20 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 16:17:19 UTC, Jesse Phillips wrote: I still haven't found someone who can explain how C++ can define the behavior of modifying a variable after casting

[Issue 15660] break "immutable" with pure function and mutable reference params

https://issues.dlang.org/show_bug.cgi?id=15660 Iakh changed: What|Removed |Added Keywords||safe --

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 18:23:54 UTC, Chris wrote: On Thursday, 14 July 2016 at 18:00:36 UTC, Ola Fosheim Grøstad wrote: Please don't try to make yourself look like a martyr. Huh? Where is that coming from all of a sudden? Sorry, I don't see the point of this comment. You were going

Re: Taking D to GDC Europe - let's make this tight

On Tuesday, 12 July 2016 at 11:27:18 UTC, Ethan Watson wrote: http://schedule.gdceurope.com/session/d-using-an-emerging-language-in-quantum-break My proposal for a talk has been accepted, and I'll be in Cologne next month presenting to industry peers. Awesome ! I hope you can make good

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 18:00:36 UTC, Ola Fosheim Grøstad wrote: Please don't try to make yourself look like a martyr. Huh? Where is that coming from all of a sudden? Sorry, I don't see the point of this comment. A martyr for what? Martyrs are stupid people, they should have stayed at

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 17:36:59 UTC, Chris wrote: On Thursday, 14 July 2016 at 15:59:30 UTC, Ola Fosheim Grøstad wrote: Not sure what you mean by calling D multi-paradigm. As opposed to Java that is 100% OOP (well 99%). Which programming model is it that D supports that Java doesn't?

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 16:47:20 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 16:17:19 UTC, Jesse Phillips wrote: I still haven't found someone who can explain how C++ can define the behavior of modifying a variable after casting away const. C++ is locked down in a

Re: new cpuid is ready for comments

On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Please report your CPU (GitHub/Gist): Late 2015 MacBook Pro Intel i5 https://gist.github.com/JackStouffer/6870bde82788ae039afe0aaf0d7bf4ba

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 15:59:30 UTC, Ola Fosheim Grøstad wrote: It wasn't pure OOP, not sure what you mean by that either. Not sure what you mean by calling D multi-paradigm. As opposed to Java that is 100% OOP (well 99%). I still don't get the comparison. I don't buy a new

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 16:17:19 UTC, Jesse Phillips wrote: I still haven't found someone who can explain how C++ can define the behavior of modifying a variable after casting away const. C++ is locked down in a mine-field of backward compatibility issues and a need to interface with C

Re: new cpuid is ready for comments

Am Mon, 11 Jul 2016 16:30:44 + schrieb Ilya Yaroshenko : > Please report your CPU (GitHub/Gist): Instead of yet another Haswell/Broadwell, here is an oldie but goldie: A 16 year old Pentium-III-M from an IBM T23 notebook:

Re: Vision for the D language - stabilizing complexity?

On Tuesday, 12 July 2016 at 05:15:09 UTC, Shachar Shemesh wrote: C++ fully defines when it is okay to cast away constness, gives you aids so that you know that that's what you are doing, and nothing else, and gives you a method by which you can do it without a cast if the circumstances support

Re: Call to Action: making Phobos @safe

On Saturday, 25 June 2016 at 22:44:37 UTC, Walter Bright wrote: Andrei identified a key blocker for D adoption is the incomplete implementation of @safe. I'm working on the compiler end. But Phobos has a lot of code that is pointlessly not @safe, making it frustrating to write @safe code that

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 15:28:45 UTC, Chris wrote: I don't know much about Simula (your patriotic choice :), but it's pure OOP and as such cannot be compared to D either (which is multi-paradigm). It wasn't pure OOP, not sure what you mean by that either. Not sure what you mean by

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 14:46:50 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 14:11:25 UTC, Chris wrote: On Thursday, 14 July 2016 at 13:39:48 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote: Such a language will never see the light

Re: DMD RPM

On Thu, 2016-07-14 at 10:59 -0400, Steven Schveighoffer via Digitalmars-d wrote: > On 7/14/16 10:11 AM, Russel Winder via Digitalmars-d wrote: > > Is there any sound reason why the 64-bit DMD RPM file pulls in vast > > quantities of i686 packages on Fedora? I want 64-bit not 32-bit. > > > > I'm

Re: DMD Deb from d-apt [was DMD RPM]

On Thu, 2016-07-14 at 15:13 +, Dicebot via Digitalmars-d wrote: > On Thursday, 14 July 2016 at 14:11:12 UTC, Russel Winder wrote: > > Is there any sound reason why the 64-bit DMD RPM file pulls in  > > vast quantities of i686 packages on Fedora? I want 64-bit not  > > 32-bit. > > Very likely

Re: DMD RPM

On Thursday, 14 July 2016 at 14:11:12 UTC, Russel Winder wrote: Is there any sound reason why the 64-bit DMD RPM file pulls in vast quantities of i686 packages on Fedora? I want 64-bit not 32-bit. Very likely it has same packaging mistake as DMD in d-apt, listing gcc-multilib dependencies as

Re: DMD RPM

On 7/14/16 10:11 AM, Russel Winder via Digitalmars-d wrote: Is there any sound reason why the 64-bit DMD RPM file pulls in vast quantities of i686 packages on Fedora? I want 64-bit not 32-bit. I'm guessing because the DMD compiler is 32-bit, even though it generates 64-bit code? I think you

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 14:11:25 UTC, Chris wrote: On Thursday, 14 July 2016 at 13:39:48 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote: Such a language will never see the light of day. Many such languages exist. Didn't I say that I don't have

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 13:39:48 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote: Such a language will never see the light of day. Many such languages exist. Like? I mean languages that can be used in the real world. Certainly not Nim. It's not

DMD RPM

Is there any sound reason why the 64-bit DMD RPM file pulls in vast quantities of i686 packages on Fedora? I want 64-bit not 32-bit. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip:

Re: Best way to clear dynamic array for reuse

On 7/14/16 5:56 AM, Miguel L wrote: On Thursday, 14 July 2016 at 09:12:50 UTC, Jonathan M Davis wrote: So, whether you should be using Appender or assumeSafeAppend or neither depends entirely on what you're doing. However, in general, simply appending to dynamic arrays does not result in many

Re: Some asm help for the 'thiscall' calling convention?

On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote: Um, no, I revived it so that people searching for answers wouldn't be led astray by idiots who pretend to know everything. My word is not COM specification of course, there's the official documentation and tons of books about

Re: Is logical subsetting of an array possible ?

On 7/14/16 7:03 AM, Sahil wrote: On Thursday, 14 July 2016 at 10:51:33 UTC, Nicholas Wilson wrote: On Thursday, 14 July 2016 at 10:43:12 UTC, Sahil wrote: This is with reference to documentation about use of array in D (https://dlang.org/spec/arrays.html#array-setting). easily. The function

Re: dcompute is nearing minimal functionality

On Thursday, 14 July 2016 at 13:23:48 UTC, Nicholas Wilson wrote: On Thursday, 14 July 2016 at 13:06:05 UTC, Andrei Alexandrescu wrote: On 07/13/2016 11:53 PM, Nicholas Wilson wrote: I'd like to try to get this done by the start of august when I start my engineering honours thesis. Is your

[Issue 13055] @nogc std.string.sformat

https://issues.dlang.org/show_bug.cgi?id=13055 --- Comment #5 from Lodovico Giaretta --- Also, the current use of enforce inside sformat (which a comment states shall be removed) should be converted to an assert or something else that does not throw. --

Re: Vision document for H2 2016

On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu wrote: https://wiki.dlang.org/Vision/2016H2 -- Andrei Folks, One of the main obstacles I see to the adoption of a language is its ecosystem. Perhaps the vision should include a structure of frameworks we would like to see being

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote: Such a language will never see the light of day. Many such languages exist. What makes a language attractive is that you can actually use it - here and now. What makes a language attractive is that it has system support and provides

Re: Why modules is so strongly limited?

On Thursday, 14 July 2016 at 09:36:17 UTC, Jonathan M Davis wrote: On Wednesday, July 13, 2016 20:58:02 imbaFireFenix via Digitalmars-d wrote: If we didn't do it that way, then it would be a lot harder to figure out where all of the code for a given module was, I think that's really the

Re: dcompute is nearing minimal functionality

On Thursday, 14 July 2016 at 13:05:12 UTC, Andrei Alexandrescu wrote: On 07/13/2016 11:30 PM, Nicholas Wilson wrote: DCompute is my effort to target CUDA and SPIR to enable hassle free native execution on the gpu. It is a D library +modification of LDC and is available at

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 12:12:34 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 11:38:59 UTC, Chris wrote: On Wednesday, 13 July 2016 at 17:30:53 UTC, Kagamin wrote: Software design is an iterative process because one can't sort everything at once. Not true. Ola can. :)

Re: new cpuid is ready for comments

On Thursday, 14 July 2016 at 13:04:56 UTC, Kirill Babikhin wrote: Intel(R) Core(TM)2 CPU 4400 @ 2.00GHz https://gist.github.com/qsimpleq/78ed456a289f9cc418f69527298e3e9a#file-intel-r-core-tm-2-cpu-4400-2-00ghz

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 13:11:36 UTC, Kagamin wrote: On Thursday, 14 July 2016 at 12:57:06 UTC, Ola Fosheim Grøstad wrote: Huh? I need to explain the purpose of building prototypes? You mean your process describes building prototypes only? Yes? You cannot easily iterate over the

Re: I can has @nogc and throw Exceptions?

On Wednesday, 13 July 2016 at 22:42:36 UTC, Adam Sansier wrote: On Wednesday, 13 July 2016 at 21:27:16 UTC, Lodovico Giaretta wrote: At the end, all memory comes from one of these: GC heap, malloc, mmap, sbrk. All other allocators build on top of these (or on top of user supplied buffers,

Re: dcompute is nearing minimal functionality

On Thursday, 14 July 2016 at 13:06:05 UTC, Andrei Alexandrescu wrote: On 07/13/2016 11:53 PM, Nicholas Wilson wrote: I'd like to try to get this done by the start of august when I start my engineering honours thesis. Is your thesis related to this project in any way? -- Andrei No, it will

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 12:57:06 UTC, Ola Fosheim Grøstad wrote: Huh? I need to explain the purpose of building prototypes? You mean your process describes building prototypes only?

Re: dcompute is nearing minimal functionality

On 07/13/2016 11:53 PM, Nicholas Wilson wrote: I'd like to try to get this done by the start of august when I start my engineering honours thesis. Is your thesis related to this project in any way? -- Andrei

Re: dcompute is nearing minimal functionality

On 07/13/2016 11:30 PM, Nicholas Wilson wrote: DCompute is my effort to target CUDA and SPIR to enable hassle free native execution on the gpu. It is a D library +modification of LDC and is available at https://github.com/thewilsonator/ldc/tree/dcompute Whoa, now that's a sight for sore eyes.

Re: new cpuid is ready for comments

On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Please report your CPU (GitHub/Gist): AMD Phenom(tm) 9550 Quad-Core Processor https://gist.github.com/qsimpleq/78ed456a289f9cc418f69527298e3e9a

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 12:38:44 UTC, Kagamin wrote: What's the reason to implement what can't work even for you alone? Huh? I need to explain the purpose of building prototypes?

Re: Reserve on dynamic arrays

On Thursday, 14 July 2016 at 09:29:10 UTC, Jonathan M Davis wrote: On Thursday, July 14, 2016 07:20:46 cym13 via Digitalmars-d-learn wrote: [...] Whatever the profiler is telling you, it's clearly not actually telling you whether an allocation took place, and that's easy to test. For

[Issue 16280] -profile=gc wrongly reports allocation when using reserve on dynamic arrays

https://issues.dlang.org/show_bug.cgi?id=16280 --- Comment #1 from Cédric Picard --- I should mention that this was done with DMD32 2.071.1 on GNU/Linux --

Re: new cpuid is ready for comments

On Thursday, 14 July 2016 at 12:00:12 UTC, Brad Jones wrote: Very nicely done. Following Guillaume, I too have added the output of `cat /proc/cpuinfo`. Here's my contribution. cpuid for Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz on Intel NUC:

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 12:12:34 UTC, Ola Fosheim Grøstad wrote: I don't have time for a long rant on this... But if you are designing a truly new langauge (and D isn't), then you create prototypes, then you build a framework that is suitable for evolutionary design, then you spec it,

[Issue 16280] New: -profile=gc wrongly reports allocation when using reserve on dynamic arrays

https://issues.dlang.org/show_bug.cgi?id=16280 Issue ID: 16280 Summary: -profile=gc wrongly reports allocation when using reserve on dynamic arrays Product: D Version: D2 Hardware: x86 OS: Linux

Re: Why modules is so strongly limited?

On Wednesday, 13 July 2016 at 20:58:02 UTC, imbaFireFenix wrote: But for now for huge project need to do Huge projects are usually organized into packages, only small projects can fit in a couple of unorganized files.

Re: Confused about referencing in D

On Thursday, 14 July 2016 at 06:23:15 UTC, Gorge Jingale wrote: I think that the assignment in the first case is not assigning the reference returned by auto ref GetValue(). `ref` in D is shallow, it only applies to the thing it is specifically on and is lost across assignments. Once you

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 11:38:59 UTC, Chris wrote: On Wednesday, 13 July 2016 at 17:30:53 UTC, Kagamin wrote: Software design is an iterative process because one can't sort everything at once. Not true. Ola can. :) (I just couldn't resist ...) I don't have time for a long rant on

Re: new cpuid is ready for comments

On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Hello :-) `cpuid` package is core.cpuid analog. It would be used by future D BLAS implementation. Why it is better? See https://github.com/libmir/cpuid#api-features https://github.com/libmir/cpuid#implementation-features

Re: Vision for the D language - stabilizing complexity?

On Wednesday, 13 July 2016 at 17:30:53 UTC, Kagamin wrote: Software design is an iterative process because one can't sort everything at once. Not true. Ola can. :) (I just couldn't resist ...)

Problems with -fPIC, libraries and exceptions (in linux?)

Hi! I've stumbled across the following problem: when I raise an exception from a (statically linked) library that was compiled with -fPIC, I get a segmentation fault. Example: -- libfoo/dub.json { "name" : "foo", "description" : "Exception raising lib", "dflags" : [

Re: Is logical subsetting of an array possible ?

On Thursday, 14 July 2016 at 11:01:20 UTC, Nicholas Wilson wrote: On Thursday, 14 July 2016 at 10:51:33 UTC, Nicholas Wilson wrote: I should explain this a bit more if you are totally new to D. although filter looks like a method for an array type it is not it is a function. in D function

Re: Best way to clear dynamic array for reuse

On Thursday, July 14, 2016 09:56:02 Miguel L via Digitalmars-d-learn wrote: > Thank you Jonathan, that really cleared up a lot of things, I > read the article. But I still have this doubt: is > assumeSafeAppend() changing a property of the array as "this > array is never going to be referenced by

Re: Is logical subsetting of an array possible ?

On Thursday, 14 July 2016 at 10:51:33 UTC, Nicholas Wilson wrote: On Thursday, 14 July 2016 at 10:43:12 UTC, Sahil wrote: This is with reference to documentation about use of array in D (https://dlang.org/spec/arrays.html#array-setting). easily. The function you are looking for is called

Re: Is logical subsetting of an array possible ?

On Thursday, 14 July 2016 at 10:51:33 UTC, Nicholas Wilson wrote: On Thursday, 14 July 2016 at 10:43:12 UTC, Sahil wrote: (I am totally new to D) easily. The function you are looking for is called 'filter' import std.algorithm; import std.array; int[] a = [ 4,5,8,1,3,2,9,10]; auto b =

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 09:44:15 UTC, Chris wrote: If you look at the reviews that have less than four stars, the book doesn't seem to be very useful for people who are not beginners. I meant high-level knowledge about software design in chapter 5.

  1   2   >