Re: D is for Data Science
On Tuesday, 25 November 2014 at 01:10:56 UTC, Walter Bright wrote: On 11/24/2014 4:50 PM, Adam D. Ruppe wrote: On Tuesday, 25 November 2014 at 00:34:30 UTC, Walter Bright wrote: Thought I'd post this as a counterpoint to the recent please break our code thread. I would caution against putting very much weight in Reddit opinions - there's people who will never use D and just look for excuses to justify their prejudice and there's people who think they want something, but don't really have any idea (this is common in feature requests, as I'm sure you know) That comment, in particular, seems very questionable to me. dstats at least compiles out of the box and has github activity within the last few months. It has a lot of templates, so maybe actually using it would reveal compilation problems, but at quick glance it seems to work. I know it's a tough call. But I do see these sorts of comments regularly, and it is a fact that there are too many D libraries gone to seed that won't compile anymore, and that makes us look bad. If that it's the problem, it's time to go ahead with an explicit support for the work done in dfix, no? It's not a silver bullet, but it's a clear indication to the potential adopters that there's a plan, and actively indicate that definitely we care about that particular issue, common to every language. --- /Paolo
Re: D is for Data Science
On Tuesday, 25 November 2014 at 01:10:56 UTC, Walter Bright wrote: I know it's a tough call. But I do see these sorts of comments regularly, and it is a fact that there are too many D libraries gone to seed that won't compile anymore, and that makes us look bad. Or this: https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac It was the endless std.logger bikeshedding that finally did me in. Even if they get it into std.experimental in the next release, I'm finally done. I cancelled my projects and pulled them off dub. Is this a much better reason?
Separate compilation of Temple templates
Also, because long compile times due to template compilation are a pain for both Vibe's Diet and Temple, I've put together a repo demonstrating how to do separate compilation with Temple templates: https://github.com/dymk/temple-separate-compilation The idea is to put views in separate Dub submodules, so if the views don't change, the submodule isn't recompiled with the rest of the application.
Re: D is for Data Science
weaselcat: I see array.sort is planned for future deprecation, what does future fall under? For us that activate warnings in dmd (because for a design mistake they are disabled on default, but hopefully this will be fixed in future) in the latest github version of the compiler it gives a warning if you use the built-in sort and reverse. Unfortunately the library reverse still needs to be fixed to return the array as the built-in reverse. Bye, bearophile
Re: D is for Data Science
On Mon, 24 Nov 2014 17:10:25 -0800 Walter Bright via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: I know it's a tough call. But I do see these sorts of comments regularly, and it is a fact that there are too many D libraries gone to seed that won't compile anymore, and that makes us look bad. but D wins in overall. being one of the architects in my bussiness i was eagerly pushing D as our main development language. it's good that this thing (and some other too) happens before i succeeded. now we keep going with C++, as it fscks safety too, fscks principle of least astonishment, almost never fixes inconsistencies, but it has alot more libraries and i can hire alot more programmers with it. i'm still using D as a language for my hobbyst throw-away projects though, and D is great for such things. D wins, 'cause i *almost* stopped ranting (not only in this NG) and just accepting it as is. well, almost as is, i'm applying alot of patches over vanilla D. this, of course, makes my code incompatible with every other D compiler out here, but luckily this is not a concern anymore. signature.asc Description: PGP signature
Re: dfix 0.2.0
On Mon, 24 Nov 2014 19:22:51 +
Brian Schott via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
dfix is a tool for automatically upgrading the syntax of D source
code.
Changes since 0.1.1:
* #1 dfix will now rewrite const int foo() {} to int foo()
const {}
* #6 The C-style array syntax fix is no longer incorrectly
applied to
certain ASM statements.
* #9 You can now provide directory names as arguments to dfix in
case
you're too lazy to run find and xargs. (And really, who isn't?)
* #11 dfix is now registered on code.dlang.org.
http://code.dlang.org/packages/dfix
* Added tests.
can it detect top-level @properties and @properties with args? this
would be very valuable addition for property enforcing patch. std.file,
for example, declared top-level `isFile()`, `isDir()` and some other
functions as @properties, which is meaningless, as we have UFCS. and
this breaks with Kenji's PR 2305, for example.
signature.asc
Description: PGP signature
Re: dfix 0.2.0
On Monday, 24 November 2014 at 19:22:52 UTC, Brian Schott wrote:
dfix is a tool for automatically upgrading the syntax of D
source code.
Changes since 0.1.1:
* #1 dfix will now rewrite const int foo() {} to int foo()
const {}
* #6 The C-style array syntax fix is no longer incorrectly
applied to
certain ASM statements.
* #9 You can now provide directory names as arguments to dfix
in case
you're too lazy to run find and xargs. (And really, who
isn't?)
* #11 dfix is now registered on code.dlang.org.
http://code.dlang.org/packages/dfix
* Added tests.
When trying to build dfix with dmd git master as
dub -v
I get
Generate target libdparse (staticLibrary
/home/per/.dub/packages/libdparse-0.1.1 libdparse)
Target
'/home/per/.dub/packages/libdparse-0.1.1/.dub/build/library-debug-linux.posix-x86_64-dmd_2067-BB8147F4EBDBE336D187810BFAA258B4/liblibdparse.a'
doesn't exist, need rebuild.
Building libdparse 0.1.1 configuration library, build type
debug.
Running dmd...
dmd -lib
-of../../.dub/packages/libdparse-0.1.1/.dub/build/library-debug-linux.posix-x86_64-dmd_2067-BB8147F4EBDBE336D187810BFAA258B4/liblibdparse.a
-debug -g -w -version=Have_libdparse
-I../../.dub/packages/libdparse-0.1.1/src
-I../../.dub/packages/libdparse-0.1.1/src/
../../.dub/packages/libdparse-0.1.1/src/std/allocator.d
../../.dub/packages/libdparse-0.1.1/src/std/d/ast.d
../../.dub/packages/libdparse-0.1.1/src/std/d/entities.d
../../.dub/packages/libdparse-0.1.1/src/std/d/formatter.d
../../.dub/packages/libdparse-0.1.1/src/std/d/lexer.d
../../.dub/packages/libdparse-0.1.1/src/std/d/parser.d
../../.dub/packages/libdparse-0.1.1/src/std/lexer.d
../../.dub/packages/libdparse-0.1.1/src/std/allocator.d(4229):
Warning: instead of C-style syntax, use D-style syntax
'Allocator[(max - (min - 1)) / step] buckets'
FAIL
../../.dub/packages/libdparse-0.1.1/.dub/build/library-debug-linux.posix-x86_64-dmd_2067-BB8147F4EBDBE336D187810BFAA258B4/
libdparse staticLibrary
Error executing command run:
Why?
I guess one solution would be to make warnings non-errors right
but that seems dumb concerning what dfix can do for us regarding
auto-converting C-style arrays syntax to D-style :)
Re: dfix 0.2.0
On Tuesday, 25 November 2014 at 23:45:17 UTC, Nordlöw wrote: I guess one solution would be to make warnings non-errors right but that seems dumb concerning what dfix can do for us regarding auto-converting C-style arrays syntax to D-style :) BTW: How do I specify that a dependency package (libdparse) should be compiled with -wi instead of -w?
Re: dfix 0.2.0
On Tuesday, 25 November 2014 at 23:47:07 UTC, Nordlöw wrote: On Tuesday, 25 November 2014 at 23:45:17 UTC, Nordlöw wrote: I guess one solution would be to make warnings non-errors right but that seems dumb concerning what dfix can do for us regarding auto-converting C-style arrays syntax to D-style :) The issue trackers for dfix and libdparse are on github. BTW: How do I specify that a dependency package (libdparse) should be compiled with -wi instead of -w? You can read DUB's documentation here: http://code.dlang.org/package-format
Re: dfix 0.2.0
On Monday, 24 November 2014 at 19:22:52 UTC, Brian Schott wrote:
dfix is a tool for automatically upgrading the syntax of D
source code.
Changes since 0.1.1:
* #1 dfix will now rewrite const int foo() {} to int foo()
const {}
* #6 The C-style array syntax fix is no longer incorrectly
applied to
certain ASM statements.
* #9 You can now provide directory names as arguments to dfix
in case
you're too lazy to run find and xargs. (And really, who
isn't?)
* #11 dfix is now registered on code.dlang.org.
http://code.dlang.org/packages/dfix
* Added tests.
very good.
