[Issue 17495] __traits(getParameterStorageClasses) doesn't work with tuples as parameters

https://issues.dlang.org/show_bug.cgi?id=17495 --- Comment #1 from Walter Bright --- https://github.com/dlang/dmd/pull/6897 --

[Issue 17495] New: __traits(getParameterStorageClasses) doesn't work with tuples as parameters

https://issues.dlang.org/show_bug.cgi?id=17495 Issue ID: 17495 Summary: __traits(getParameterStorageClasses) doesn't work with tuples as parameters Product: D Version: D2 Hardware: All OS: All

Re: One for experts in std.parallelism

On Sunday, 11 June 2017 at 19:06:48 UTC, Andrei Alexandrescu wrote: I tried to eliminate the static shared ~this as follows: https://github.com/dlang/phobos/pull/5470/commits/a4b2323f035b663727349d390719509d0e3247ba However, unittesting fails at src/core/thread.d(2042). I suspect it's because

[Issue 17488] Platform-inconsistent behavior from getTempDir()

https://issues.dlang.org/show_bug.cgi?id=17488 Vladimir Panteleev changed: What|Removed |Added Keywords||pull ---

Re: Is there a good lib out there to handle large integer of know size ?

On Sunday, 11 June 2017 at 21:52:40 UTC, Era Scarecrow wrote: Doing a 10240bit int I ran though 1,000 factorials in 6 seconds (this includes printing the values out). I got to about 400 in 16 minutes using the generic code. Got the compatible/generic code to run far faster, about 7 times

Re: O(1) sum

On Monday, 12 June 2017 at 01:02:58 UTC, helxi wrote: Is it possible to sum an array in O(1)? No. If you want to sum the elements you have to at-least look at all the elements. So it'll always be O(N). it's the best you can do.

O(1) sum

Is it possible to sum an array in O(1)?

Re: Expressing range constraints in CNF form

On Monday, 12 June 2017 at 00:13:46 UTC, Adam D. Ruppe wrote: On Sunday, 11 June 2017 at 00:28:58 UTC, Andrei Alexandrescu wrote: // Also possible (no change to the language) enum bool isInputRange(R) = is(typeof((ref R r) => r)) && msg("must be copyable") Or how about enum bool

Re: Makefile experts, unite!

On Sunday, June 11, 2017 16:47:30 Ali Çehreli via Digitalmars-d wrote: > On 06/11/2017 12:27 PM, ketmar wrote: > > p.s.: or replacing make-based build system with D-based. as we need > > working D compiler to compile dmd anyway, i see no reason to not use it > > more. > > I had the pleasure of

[Issue 17493] nothrow constructor may throw

https://issues.dlang.org/show_bug.cgi?id=17493 --- Comment #1 from Walter Bright --- https://github.com/dlang/dmd/pull/6896 --

Re: Expressing range constraints in CNF form

On Sunday, 11 June 2017 at 00:28:58 UTC, Andrei Alexandrescu wrote: // Also possible (no change to the language) enum bool isInputRange(R) = is(typeof((ref R r) => r)) && msg("must be copyable") Or how about enum bool isInputRange(R) = isCopyable!R && supportsBoolEmpty!R &&

Re: Makefile experts, unite!

Ali Çehreli wrote: On 06/11/2017 12:27 PM, ketmar wrote: p.s.: or replacing make-based build system with D-based. as we need working D compiler to compile dmd anyway, i see no reason to not use it more. I had the pleasure of working with Eyal Lotem, main author of buildsome. The buildsome

[Issue 17494] Do not execute scope(...) if an Error exception has been thrown

https://issues.dlang.org/show_bug.cgi?id=17494 Walter Bright changed: What|Removed |Added See Also|

[Issue 17493] nothrow constructor may throw

https://issues.dlang.org/show_bug.cgi?id=17493 Walter Bright changed: What|Removed |Added See Also|

Re: Expressing range constraints in CNF form

On 6/11/17 12:35 PM, Stanislav Blinov wrote: On Sunday, 11 June 2017 at 16:28:23 UTC, Timon Gehr wrote: I'd prefer bool msg(bool constraint, string message){ return constraint; } This does not require the compiler to dive into a branch it wouldn't consider otherwise, and the pairing of

[Issue 17494] New: Do not execute scope(...) if an Error exception has been thrown

https://issues.dlang.org/show_bug.cgi?id=17494 Issue ID: 17494 Summary: Do not execute scope(...) if an Error exception has been thrown Product: D Version: D2 Hardware: All OS: All Status: NEW

Re: Makefile experts, unite!

On 06/11/2017 12:27 PM, ketmar wrote: > p.s.: or replacing make-based build system with D-based. as we need > working D compiler to compile dmd anyway, i see no reason to not use it > more. I had the pleasure of working with Eyal Lotem, main author of buildsome. The buildsome team are aware of

Re: Isn't it about time for D3?

solidstate1991 wrote: E already exists (https://en.wikipedia.org/wiki/E_(programming_language) + AmigaE), two things having the same name often doom one of them into obscurity (see SDLang, which originally was called SDL). and there were several "D"s too. ;-) There were already a few changes

Re: brew install dmd

On Sunday, 11 June 2017 at 04:08:56 UTC, Seb wrote: But I'm not sure about doing this. This is a copy of the __official__ D installer as advertised on dlang.org (http://dlang.org/download.html): curl -fsS https://dlang.org/install.sh | bash -s dmd (the releases are signed) i.dlang.io is

Re: Is there a good lib out there to handle large integer of know size ?

On Sunday, 11 June 2017 at 21:52:40 UTC, Era Scarecrow wrote: Also got Cent working (mostly). It's complete, more or less now. I just a matter of filling in any missing methods that I haven't programmed for, and probably adding filler/forwarding functions from ScaledInt to UScaledInt.

Re: Isn't it about time for D3?

On Sunday, 11 June 2017 at 22:53:44 UTC, ketmar wrote: so what? "nearly destroyed" != "destroyed". as i said, D is alive and ok, nothing fatal happens. backing fear of changes with "last time it almost destroyed us" won't do any good in the long term: it will ultimately end with having no

[Issue 17492] [REG 2.066] [ICE] AssertError@ddmd/dclass.d(1007): Assertion failure

https://issues.dlang.org/show_bug.cgi?id=17492 Vladimir Panteleev changed: What|Removed |Added CC|

[Issue 17493] New: nothrow constructor may throw

https://issues.dlang.org/show_bug.cgi?id=17493 Issue ID: 17493 Summary: nothrow constructor may throw Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority: P1

[Issue 17488] Platform-inconsistent behavior from getTempDir()

https://issues.dlang.org/show_bug.cgi?id=17488 --- Comment #4 from Vladimir Panteleev --- OK, I see a rationale in the pull request discussion (https://github.com/dlang/phobos/pull/2150) (should've been in the commit message, BTW): > Android doesn't have a global temp

Re: Isn't it about time for D3?

Guillaume Piolat wrote: On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote: Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D. as you can see, D is alive and kicking, and nothing disasterous or fatal happens.

[Issue 17488] Platform-inconsistent behavior from getTempDir()

https://issues.dlang.org/show_bug.cgi?id=17488 Vladimir Panteleev changed: What|Removed |Added CC|

[Issue 17488] Platform-inconsistent behavior from getTempDir()

https://issues.dlang.org/show_bug.cgi?id=17488 --- Comment #2 from dl...@ryanjframe.com --- According the the tempDir documentation: On all platforms, tempDir returns "." on failure, representing the current working directory. On failure, the value of getcwd() is returned; on my test (Windows

Re: Isn't it about time for D3?

On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote: Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D. as you can see, D is alive and kicking, and nothing disasterous or fatal happens.

[Issue 17492] [REG 2.066] [ICE] AssertError@ddmd/dclass.d(1007): Assertion failure

https://issues.dlang.org/show_bug.cgi?id=17492 Iain Buclaw changed: What|Removed |Added Severity|major |regression --

[Issue 17492] [REG 2.066] [ICE] AssertError@ddmd/dclass.d(1007): Assertion failure

https://issues.dlang.org/show_bug.cgi?id=17492 --- Comment #1 from Iain Buclaw --- According to asm.dlang.org, this ICE did not happen in 2.065. https://goo.gl/nQe22z It however is present in version 2.066 -> 2.068 releases, as well as the nightly build.

[Issue 17492] [REG 2.066] [ICE] AssertError@ddmd/dclass.d(1007): Assertion failure

https://issues.dlang.org/show_bug.cgi?id=17492 Iain Buclaw changed: What|Removed |Added Summary|[ICE] |[REG 2.066] [ICE]

[Issue 17492] New: [ICE] AssertError@ddmd/dclass.d(1007): Assertion failure

https://issues.dlang.org/show_bug.cgi?id=17492 Issue ID: 17492 Summary: [ICE] AssertError@ddmd/dclass.d(1007): Assertion failure Product: D Version: D2 Hardware: All OS: All Status: NEW

[Issue 17492] [ICE] AssertError@ddmd/dclass.d(1007): Assertion failure

https://issues.dlang.org/show_bug.cgi?id=17492 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org

First time user of LDC and getting newbie problems.

Just trying to compile a "Hello World" using dub and ldc2. The 32 bit works fine: generic@generic-ThinkPad-T61:~/Desktop/test$ dub run --compiler=ldc2 --arch=x86 Performing "debug" build using ldc2 for x86. test ~master: target for configuration "application" is up to date. To force a

Re: Is there a good lib out there to handle large integer of know size ?

On Sunday, 11 June 2017 at 18:01:41 UTC, Era Scarecrow wrote: And what timing, I just finished getting it working with assembly and compatible versions. Seems 5x slower rather than the dreaded 50, but that's from testing factorial up to 100 (200ms vs 1,200ms). Doing a 10240bit int I ran

[Issue 16615] std.process is missing functionality for child processes

https://issues.dlang.org/show_bug.cgi?id=16615 Vladimir Panteleev changed: What|Removed |Added CC|

[Issue 17479] Public constructor for std.process.Pid

https://issues.dlang.org/show_bug.cgi?id=17479 Vladimir Panteleev changed: What|Removed |Added Status|NEW |RESOLVED

Re: Expressing range constraints in CNF form

On Sunday, 11 June 2017 at 19:51:11 UTC, ketmar wrote: i think, that something like `__constraint(condition, "message")` is ok, and it should be built-in, just like `__traits()`. so compiler can collect those messages, and only show 'em if the matcher is failed to find anything. yeah,

Re: Isn't it about time for D3?

On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: D is a language with much promise, but it still has many problems that prevent it from being the great replacement for C++ that it was always meant to be. There have been many changes suggested over time to improve the

Re: Makefile experts, unite!

On Sunday, 11 June 2017 at 19:17:36 UTC, Andrei Alexandrescu wrote: Instead of an error, I get a no-op result that looks like success. How can that situation be converted to an error? That makefile target is poorly written. It was probably intended to have a dependency on the directory

Re: Expressing range constraints in CNF form

On 6/11/17 3:45 PM, Walter Bright wrote: On 6/10/2017 5:28 PM, Andrei Alexandrescu wrote: && is(typeof(lvalueOf!R.popFront)) && msg("must support back"); Wouldn't it work better as: && (is(typeof(lvalueOf!R.popFront)) || msg("must support back")); bool msg(string) { return

Re: Expressing range constraints in CNF form

On Sunday, 11 June 2017 at 00:28:58 UTC, Andrei Alexandrescu wrote: // Also possible (no change to the language) enum bool isInputRange(R) = is(typeof((ref R r) => r)) && msg("must be copyable") && is(ReturnType!((R r) => r.empty) == bool) && msg("must support bool empty") &&

Re: Expressing range constraints in CNF form

On Sunday, 11 June 2017 at 19:51:11 UTC, ketmar wrote: Walter Bright wrote: [...] i think, that something like `__constraint(condition, "message")` is ok, and it should be built-in, just like `__traits()`. so compiler can collect those messages, and only show 'em if the matcher is failed

Re: Expressing range constraints in CNF form

On Sunday, 11 June 2017 at 19:45:37 UTC, Walter Bright wrote: On 6/10/2017 5:28 PM, Andrei Alexandrescu wrote: && is(typeof(lvalueOf!R.popFront)) && msg("must support back"); Wouldn't it work better as: && (is(typeof(lvalueOf!R.popFront)) || msg("must support back")); bool

[Issue 17490] std.path.buildPath on Windows returns incorrect paths

https://issues.dlang.org/show_bug.cgi?id=17490 dl...@ryanjframe.com changed: What|Removed |Added Status|RESOLVED|CLOSED Resolution|WONTFIX

[Issue 17479] Public constructor for std.process.Pid

https://issues.dlang.org/show_bug.cgi?id=17479 --- Comment #3 from Chris Wright --- You can wait for a process that you called ptrace for: PTRACE_O_TRACEEXIT (since Linux 2.5.60) Stop the tracee at exit. A waitpid(2) by the tracer will return a status value such that...

Re: Expressing range constraints in CNF form

Walter Bright wrote: On 6/11/2017 8:25 AM, Andrei Alexandrescu wrote: Ostensibly the function is trivial: bool msg(string) { return true; } It doesn't change the semantics. The compiler would recognize it as an intrinsic and would print the message if the clause to its left has failed.

Re: Expressing range constraints in CNF form

Walter Bright wrote: On 6/11/2017 8:25 AM, Andrei Alexandrescu wrote: Ostensibly the function is trivial: bool msg(string) { return true; } It doesn't change the semantics. The compiler would recognize it as an intrinsic and would print the message if the clause to its left has failed.

Re: Expressing range constraints in CNF form

On 6/11/2017 12:07 PM, crimaniak wrote: Regardless of the implementation method, this will require the previously proposed Phobos refactoring. Independent special definitions have to be reduced to general ones and use "static if" to select the algorithm. Otherwise, each failed independent

Re: Expressing range constraints in CNF form

On 6/10/2017 5:28 PM, Andrei Alexandrescu wrote: && is(typeof(lvalueOf!R.popFront)) && msg("must support back"); Wouldn't it work better as: && (is(typeof(lvalueOf!R.popFront)) || msg("must support back")); bool msg(string) { return false; } ? Then msg() is only called if the

Re: Expressing range constraints in CNF form

On 6/11/2017 8:25 AM, Andrei Alexandrescu wrote: Ostensibly the function is trivial: bool msg(string) { return true; } It doesn't change the semantics. The compiler would recognize it as an intrinsic and would print the message if the clause to its left has failed. There was a proposal a

Re: Expressing range constraints in CNF form

On Sunday, 11 June 2017 at 15:25:11 UTC, Andrei Alexandrescu wrote: // Also possible (no change to the language) enum bool isInputRange(R) = is(typeof((ref R r) => r)) && msg("must be copyable") && is(ReturnType!((R r) => r.empty) == bool) && msg("must support bool empty") &&

Re: Makefile experts, unite!

Andrei Alexandrescu wrote: Phobos' posix.mak offers the ability to only run unittests for one module: make std/range/primitives.test BUILD=debug -j8 ... or package: make std/range.test BUILD=debug -j8 It runs module tests in parallel and everything. This is definitely awesome. But say I

Re: Makefile experts, unite!

Andrei Alexandrescu wrote: Phobos' posix.mak offers the ability to only run unittests for one module: make std/range/primitives.test BUILD=debug -j8 ... or package: make std/range.test BUILD=debug -j8 It runs module tests in parallel and everything. This is definitely awesome. But say I

Makefile experts, unite!

Phobos' posix.mak offers the ability to only run unittests for one module: make std/range/primitives.test BUILD=debug -j8 ... or package: make std/range.test BUILD=debug -j8 It runs module tests in parallel and everything. This is definitely awesome. But say I misspell things by using a dot

Re: Expressing range constraints in CNF form

On Sunday, 11 June 2017 at 00:28:58 UTC, Andrei Alexandrescu wrote: enum bool isInputRange(R) = is(typeof((ref R r) => r)) && "must be copyable" Regardless of the implementation method, this will require the previously proposed Phobos refactoring. Independent special definitions have to

One for experts in std.parallelism

I tried to eliminate the static shared ~this as follows: https://github.com/dlang/phobos/pull/5470/commits/a4b2323f035b663727349d390719509d0e3247ba However, unittesting fails at src/core/thread.d(2042). I suspect it's because the atexit call occurs too late, after the shared static this in

Re: Is there a good lib out there to handle large integer of know size ?

On Sunday, 11 June 2017 at 18:01:41 UTC, Era Scarecrow wrote: Anyways, here's how it is currently, most features are avaliable, need more tests and find occurrences where it doesn't work. I should probably mention that's only for UCent, Cent isn't fully tested or implemented yet.

Re: Isn't it about time for D3?

Mike B Johnson wrote: On Sunday, 11 June 2017 at 06:14:43 UTC, ketmar wrote: Mike B Johnson wrote: Yeah, sounds good, because to make progress, progress has to be made. Most people are very shortsighted and live in a fear based mentality. Mention any type of change and they nearly shit

Re: Is there a good lib out there to handle large integer of know size ?

On Sunday, 11 June 2017 at 08:52:37 UTC, deadalnix wrote: I ended up doing my own. There are just no way to do it well without cent/ucent . Weka is running into the same problem for error correction. And what timing, I just finished getting it working with assembly and compatible versions.

Re: Isn't it about time for D3?

Guillaume Piolat wrote: On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Well, no thanks. The very same strategy halved the community for D1/D2 split and almost

Re: Isn't it about time for D3?

Ola Fosheim Grøstad wrote: On Sunday, 11 June 2017 at 05:24:25 UTC, ketmar wrote: and D1.5 too. sure it should be forked from D2, and then it should be made *smaller*. which, essentially, makes it D1.5, not D3. besides, it will be very fun explaining people that we D--? Out of curiosity;

[Issue 17489] ICE in ddmd/argtypes.d

https://issues.dlang.org/show_bug.cgi?id=17489 greensunn...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #3 from

Re: Expressing range constraints in CNF form

On Sunday, 11 June 2017 at 15:25:11 UTC, Andrei Alexandrescu wrote: On 6/11/17 11:11 AM, Nick Treleaven wrote: On Sunday, 11 June 2017 at 00:28:58 UTC, Andrei Alexandrescu wrote: [...] Great! Thanks. [...] I'm not getting how this works. Ostensibly the function is trivial: bool

Re: Expressing range constraints in CNF form

On 6/11/17 12:15 PM, Stefan Koch wrote: Exposing magic functions which are recognized by name strikes me as being worse then proper compiler intrinsics. This is brainstorming. Let's follow up with better ideas in addition to pointing out flaws in the ideas on the table. To this point: .msg

Re: Expressing range constraints in CNF form

On 6/11/17 12:28 PM, Timon Gehr wrote: bool msg(bool constraint, string message){ return constraint; } That'd be nice to consider, too, thanks. -- Andrei

Re: Expressing range constraints in CNF form

On Sunday, 11 June 2017 at 16:28:23 UTC, Timon Gehr wrote: I'd prefer bool msg(bool constraint, string message){ return constraint; } This does not require the compiler to dive into a branch it wouldn't consider otherwise, and the pairing of constraint to message is less ad-hoc. Where

Re: Expressing range constraints in CNF form

On 11.06.2017 17:25, Andrei Alexandrescu wrote: On 6/11/17 11:11 AM, Nick Treleaven wrote: On Sunday, 11 June 2017 at 00:28:58 UTC, Andrei Alexandrescu wrote: https://github.com/dlang/phobos/pull/5461 There's many good advantages to this. The immediate one is the constraint is better

[Issue 17491] Compiles on invalid: * is not an lvalue

https://issues.dlang.org/show_bug.cgi?id=17491 Iain Buclaw changed: What|Removed |Added Assignee|nob...@puremagic.com|ibuc...@gdcproject.org

[Issue 17491] Compiles on invalid: * is not an lvalue

https://issues.dlang.org/show_bug.cgi?id=17491 Iain Buclaw changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment

Re: How to implement opCmp?

On Sunday, 11 June 2017 at 15:40:42 UTC, Honey wrote: On Sunday, 11 June 2017 at 15:24:30 UTC, Honey wrote: Doesn't it make sense to introduce another overload of cmp similar to Steve's doCmp [2] right at that spot? Moreover, it seems that std.algorithm.cmp should employ three way comparison

Re: Expressing range constraints in CNF form

On Sunday, 11 June 2017 at 15:25:11 UTC, Andrei Alexandrescu wrote: On 6/11/17 11:11 AM, Nick Treleaven wrote: On Sunday, 11 June 2017 at 00:28:58 UTC, Andrei Alexandrescu wrote: https://github.com/dlang/phobos/pull/5461 There's many good advantages to this. The immediate one is the

Re: Generalized Linear Models and Stochastic Gradient Descent in D

On Sunday, 11 June 2017 at 12:04:36 UTC, data pulverizer wrote: On Sunday, 11 June 2017 at 01:59:37 UTC, 9il wrote: Why not to use ndslice and Lubeck [1] libraries instead? [1] https://github.com/kaleidicassociates/lubeck Ilya It is already has hight level ndslice interface for inv

Re: Generalized Linear Models and Stochastic Gradient Descent in D

On Sunday, 11 June 2017 at 13:36:09 UTC, jmh530 wrote: On Sunday, 11 June 2017 at 12:36:19 UTC, 9il wrote: I ported few large complex Matlab scripts using Lubeck and Mir-Algorithm (closed source). It works perfectly and results are the same as Matlab original! All functions from Lubeck was

Re: How to implement opCmp?

On Sunday, 11 June 2017 at 15:24:30 UTC, Honey wrote: Doesn't it make sense to introduce another overload of cmp similar to Steve's doCmp [2] right at that spot? Moreover, it seems that std.algorithm.cmp should employ three way comparison as well. The current implementation int cmp(alias

TypestateLite for safe copy/destroy of RC Slice

Just another idea. So as I understand https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#owning-containers there is problem with safe assignment of slices. But the problem is actual only if some element has scope ref. 1. Lets introduce type state "referred". ``` //safe code

Re: Expressing range constraints in CNF form

On 6/11/17 11:11 AM, Nick Treleaven wrote: On Sunday, 11 June 2017 at 00:28:58 UTC, Andrei Alexandrescu wrote: https://github.com/dlang/phobos/pull/5461 There's many good advantages to this. The immediate one is the constraint is better structured and easier to understand. Then, the compiler

Re: How to implement opCmp?

On Friday, 9 June 2017 at 17:50:28 UTC, Honey wrote: Looking at the implementation of Tuple.opCmp, I'm not sure I'd bet on existence of opCmp for fundamental types: int opCmp(R)(R rhs) if (areCompatibleTuples!(typeof(this), R, "<")) { foreach (i, Unused;

Re: Expressing range constraints in CNF form

On Sunday, 11 June 2017 at 00:28:58 UTC, Andrei Alexandrescu wrote: https://github.com/dlang/phobos/pull/5461 There's many good advantages to this. The immediate one is the constraint is better structured and easier to understand. Then, the compiler can print the exact clause that failed,

[Issue 17491] Compiles on invalid: * is not an lvalue

https://issues.dlang.org/show_bug.cgi?id=17491 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org

Re: Isn't it about time for D3?

On Sunday, 11 June 2017 at 05:24:25 UTC, ketmar wrote: and D1.5 too. sure it should be forked from D2, and then it should be made *smaller*. which, essentially, makes it D1.5, not D3. besides, it will be very fun explaining people that we D--? Out of curiosity; wouldn't it be better to start

Re: byLine(n)?

On 06/11/2017 03:00 PM, helxi wrote: I would also be really humbled if you demonstrate a faster approach of achieving the goal of the program :) (without explicitly using loops and conditions) Do you have a reason to believe that your version is slow? I don't see why it would be.

[Issue 17491] New: Compiles on invalid: * is not an lvalue

https://issues.dlang.org/show_bug.cgi?id=17491 Issue ID: 17491 Summary: Compiles on invalid: * is not an lvalue Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority:

[Issue 17490] std.path.buildPath on Windows returns incorrect paths

https://issues.dlang.org/show_bug.cgi?id=17490 Vladimir Panteleev changed: What|Removed |Added Status|NEW |RESOLVED

Re: Generalized Linear Models and Stochastic Gradient Descent in D

On Sunday, 11 June 2017 at 12:36:19 UTC, 9il wrote: I ported few large complex Matlab scripts using Lubeck and Mir-Algorithm (closed source). It works perfectly and results are the same as Matlab original! All functions from Lubeck was used in this work. Mir Algorithm has over then 2K

[Issue 17490] New: std.path.buildPath on Windows returns incorrect paths

https://issues.dlang.org/show_bug.cgi?id=17490 Issue ID: 17490 Summary: std.path.buildPath on Windows returns incorrect paths Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity:

Re: std.path.buildPath

On Sunday, 4 June 2017 at 18:15:36 UTC, Russel Winder wrote: On Sun, 2017-06-04 at 17:56 +0200, Jacob Carlborg via Digitalmars-d- learn wrote: On 2017-06-04 07:44, Jesse Phillips wrote: > What is your expected behavior? Throw an exception? You can't > really > append an absolute path to

There is a new test runner in town

I'm pleased to announce the first release of `trial`. Trial is a test runner that aims for flexibility. I made this runner because I could not find a flexible test runner for D, to extend it with various features, like reporters and test discoveries. This runner extends `dub test` command and

Re: byLine(n)?

On Sunday, 11 June 2017 at 12:49:51 UTC, Cym13 wrote: print each line byLine doesn't reall all input at once. Using byline and take you are effectively reading only the right amount of lines and not reading the rest. You already have what you want, what makes you think the contrary? Oh it

Re: Isn't it about time for D3?

On Sunday, 11 June 2017 at 12:22:02 UTC, Andrei Alexandrescu wrote: On 6/11/17 5:14 AM, Cym13 wrote: Building on that: 82% of patches for Mozilla Firefox are accepted at first sight. Thanks for referring the paper, I'll read it on the plane. Facebook's rate would be probably comparable. An

Re: byLine(n)?

On Sunday, 11 June 2017 at 12:44:05 UTC, helxi wrote: On Sunday, 11 June 2017 at 06:28:18 UTC, Stanislav Blinov wrote: On Sunday, 11 June 2017 at 05:36:08 UTC, helxi wrote: [...] You need only the nth line? Then you'd need to `drop` the preceding ones: void main(string[] args) {

Re: byLine(n)?

On Sunday, 11 June 2017 at 06:28:18 UTC, Stanislav Blinov wrote: On Sunday, 11 June 2017 at 05:36:08 UTC, helxi wrote: I was writing a program that reads and prints the first nth lines to the stdout: import std.stdio; void main(string[] args) { import std.algorithm, std.range; import

Re: Generalized Linear Models and Stochastic Gradient Descent in D

On Sunday, 11 June 2017 at 11:10:38 UTC, data pulverizer wrote: On Sunday, 11 June 2017 at 01:57:52 UTC, 9il wrote: [...] You are right - I realised this as I was writing the script but I address this point later ... [...] Thank you for mentioning the Lubeck package, I did not know

Re: Isn't it about time for D3?

On Sunday, 11 June 2017 at 12:22:02 UTC, Andrei Alexandrescu wrote: On 6/11/17 5:14 AM, Cym13 wrote: Building on that: 82% of patches for Mozilla Firefox are accepted at first sight. Thanks for referring the paper, I'll read it on the plane. Facebook's rate would be probably comparable. An

Re: Isn't it about time for D3?

On 6/11/17 5:14 AM, Cym13 wrote: Building on that: 82% of patches for Mozilla Firefox are accepted at first sight. Thanks for referring the paper, I'll read it on the plane. Facebook's rate would be probably comparable. An important detail: is that the rate for internal developers or public

Re: Generalized Linear Models and Stochastic Gradient Descent in D

On Sunday, 11 June 2017 at 11:30:03 UTC, Nicholas Wilson wrote: An additional takeaway for me was that I also found the use of array operations like a[] = b[]*c[] or d[] -= e[] -f created odd effects in my calculations the outputs were wrong and for ages I didn't know why but later ended

Re: Generalized Linear Models and Stochastic Gradient Descent in D

On Sunday, 11 June 2017 at 01:59:37 UTC, 9il wrote: Why not to use ndslice and Lubeck [1] libraries instead? [1] https://github.com/kaleidicassociates/lubeck Ilya It is already has hight level ndslice interface for inv (inverse) and mtimes (matmul). p.p.s Okay, I can see how writing an

Re: Isn't it about time for D3?

On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Putting the breaking changes in a separate branch ensures that DM won't lose current clients as they can just

Re: Generalized Linear Models and Stochastic Gradient Descent in D

On Sunday, 11 June 2017 at 10:21:03 UTC, data pulverizer wrote: Speaking of not losing your audience: give a link to the NRA and/or a brief explanation of how it generalises to higher dimensions (graph or animation for the 2D case would be good, perhaps take something from wikipedia) NRA?

Re: DIP 1008 Preliminary Review Round 1

On Friday, 26 May 2017 at 21:31:20 UTC, Steven Schveighoffer wrote: Part of this may mean clarifying what @nogc actually means. Does it mean no interaction with the GC system, or does it mean "cannot run a collection cycle"? I was pleased to find GC.addRange is now @nogc, so it seems

  1   2   >