Re: [howto] Serve ddox documentation on github.io deployed by Travis CI
On Saturday, 13 January 2018 at 04:59:25 UTC, Martin Nowak wrote: On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote: [...] What do you mean with "taking care of it"? It's a bit of a hen and egg problem, first you need a project before you can register it with code.dlang.org. So that seems like a sub-optimal place to help with project setup. [...] Citing Sönke: The whole dub init -t feature is planned to be replaced by a more general approach, so it would be rather wasteful to invest more time than necessary in this. The new approach basically would simply look for a ":example" (or similar) sub package for the first dependency specified to dub init, uses that as the base for the newly created package, and would then just adjust the recipe according to the remaining init parameters. https://github.com/dlang/dub/pull/1326#issuecomment-357233196
Re: [howto] Serve ddox documentation on github.io deployed by Travis CI
On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote: Maybe worthwile to add this scaffolding to dub or some other tool? Anyone volunteering? This could be a good idea. Probably even better is to let code.dlang.org take care of it, which would make the whole token issue and setup obsolete. What do you mean with "taking care of it"? It's a bit of a hen and egg problem, first you need a project before you can register it with code.dlang.org. So that seems like a sub-optimal place to help with project setup. Dub init would be much better suited. We should figure out to make the existing init templates extensible anyhow.
Re: Another take on decimal data types
On Friday, 12 January 2018 at 13:09:42 UTC, kdevel wrote: $ dmd nosine.d decimal.git/libdecimal.a decimal/package.d(10505): Error: undefined identifier decimalCapAngle Sorry, broke some code when I made the split. Now it's working.
Re: Release D 2.078.0
On Friday, 12 January 2018 at 18:25:37 UTC, Rainer Schuetze wrote: IMO removing the detected entries from sc.ini should be good enough: https://github.com/dlang/dmd/pull/7686. The linker path is built from the other VC variables. I've based it on stable in the hope it will make it into 2.078.1. The more involved changes I mentioned are https://github.com/dlang/installer/pull/281 and https://github.com/dlang/dmd/pull/7500. Thanks for your great work! Kind regards Andre
Re: Release D 2.078.0
On 12.01.2018 12:42, Andre Pany wrote: On Monday, 8 January 2018 at 22:41:31 UTC, Rainer Schuetze wrote: Unfortunately the corresponding installer PRs didn't make it into the release, so you still have to remove most options of section Environment64 from sc.ini yourself. This should be enough [Environment64] LIB=%@P%\..\lib64 DFLAGS=%DFLAGS% -L/OPT:NOICF When using the 7z dmd file, the most harmful setting is LINKCMD, that doesn't work for VS2017. Any chance to get the corresponding PR with 2.078.1 point release? I also tried it with the Build Tools for Visual Studio 2017 and it neither works. I think the link path could be easily retrieved. You could check whether the first element of %PATH% contains a file link.exe and use this one if the file path also starts with %VCINSTALLDIR%. Example: Path=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64;... VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\ Kind regards André IMO removing the detected entries from sc.ini should be good enough: https://github.com/dlang/dmd/pull/7686. The linker path is built from the other VC variables. I've based it on stable in the hope it will make it into 2.078.1. The more involved changes I mentioned are https://github.com/dlang/installer/pull/281 and https://github.com/dlang/dmd/pull/7500.
Re: Proposal for a standard Decimal type in alpha
On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer wrote: ... While I believe my library has certain API advantages, I'm really not interested in duplicating a bunch of work when rumbu's version is pretty much complete, so I'm dropping this.
Re: Another take on decimal data types
On Thursday, 11 January 2018 at 22:07:42 UTC, H. S. Teoh wrote:
On Thu, Jan 11, 2018 at 04:38:57PM -0500, Steven Schveighoffer
via Digitalmars-d-announce wrote:
On 1/11/18 4:12 PM, kdevel wrote:
> On Thursday, 11 January 2018 at 20:40:01 UTC, Dmitry
> Olshansky wrote:
> > What did you expect?
>
> To be honest: A compile time error. Modern C compilers can
> check such format strings. Example: GCC 6:
But dmd isn't a C compiler, nor does it have to worry about
the problems C has (namely, untyped varargs). To dmd, printf
is just another function, there's nothing special about it.
[...]
Yeah, checking C-style printf formats isn't dmd's problem.
The Phobos equivalent of printf, however, *does* support
compile-time format checking in the latest version:
writefln!"%s %d %d"("abc", 1); // "Orphan format specifier: %d"
writefln!"%s %d"("abc", 1, 2); // "Orphan format arguments:
args[2..3]"
writefln!"%s %d"(1, "abc");// "Incorrect format specifier
for range: %d"
writefln!"%f"(1); // "incompatible format
character for integral argument: %f"
Best of all, this is all done via CTFE in the library code, no
hard-coding in the compiler necessary. You can implement your
own compile-time checker for your own DSLs in the same way,
without needing to hack the compiler.
Interesting, guess this was added last April with dmd 2.074?
https://dlang.org/changelog/2.074.0.html#std-format-formattedWrite
You or someone should write up a blog post about this, with both
this example and expanding on how D enables this kind of
functionality in general.
Re: Another take on decimal data types
On Monday, 8 January 2018 at 22:16:25 UTC, rumbu wrote:
- all std.math functions implemented (even logarithms and
trigonometry);
nosine.d
```
import std.stdio;
// import std.math;
import decimal;
void nosine (T) ()
{
T d = T(1.1);
writeln (sin(d));
}
void main ()
{
nosine!decimal32;
nosine!decimal64;
nosine!decimal128;
}
```
$ dmd nosine.d decimal.git/libdecimal.a
decimal/package.d(10505): Error: undefined identifier
decimalCapAngle
decimal/package.d(5364): Error: template instance
decimal.decimalSin!(Decimal!32) error instantiating
nosine.d(8):instantiated from here: sin!(Decimal!32)
nosine.d(13):instantiated from here: nosine!(Decimal!32)
decimal/package.d(10505): Error: undefined identifier
decimalCapAngle
decimal/package.d(5364): Error: template instance
decimal.decimalSin!(Decimal!64) error instantiating
nosine.d(8):instantiated from here: sin!(Decimal!64)
nosine.d(14):instantiated from here: nosine!(Decimal!64)
decimal/package.d(10505): Error: undefined identifier
decimalCapAngle
decimal/package.d(5364): Error: template instance
decimal.decimalSin!(Decimal!128) error instantiating
nosine.d(8):instantiated from here: sin!(Decimal!128)
nosine.d(15):instantiated from here: nosine!(Decimal!128)
Re: Another take on decimal data types
On Friday, 12 January 2018 at 05:18:15 UTC, rumbu wrote: On Thursday, 11 January 2018 at 23:57:29 UTC, kdevel wrote: What about the failed comparison: You are right in fact, there is also a failed comparison. Now corrected. Works. Thanks for the changes!
Re: Release D 2.078.0
On Monday, 8 January 2018 at 22:41:31 UTC, Rainer Schuetze wrote: Unfortunately the corresponding installer PRs didn't make it into the release, so you still have to remove most options of section Environment64 from sc.ini yourself. This should be enough [Environment64] LIB=%@P%\..\lib64 DFLAGS=%DFLAGS% -L/OPT:NOICF When using the 7z dmd file, the most harmful setting is LINKCMD, that doesn't work for VS2017. Any chance to get the corresponding PR with 2.078.1 point release? I also tried it with the Build Tools for Visual Studio 2017 and it neither works. I think the link path could be easily retrieved. You could check whether the first element of %PATH% contains a file link.exe and use this one if the file path also starts with %VCINSTALLDIR%. Example: Path=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64;... VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\ Kind regards André
Re: Release D 2.078.0
On Friday, 12 January 2018 at 10:13:13 UTC, Leandro Lucarella wrote: From what I saw in the code, I think what it does is just override where the code was actually placed when you compiled, so tools to visualize the coverage can show you the source code. * https://dlang.org/code_coverage.html#switchsrcpath * https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L83-L84 * https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L211 BTW, to just report coverage of certain files you can just compile with `-cov` those files. I guess that should work (maybe? :). Thanks for the clarification. Kind regards André
Re: Release D 2.078.0
On Wednesday, 10 January 2018 at 05:35:05 UTC, Andre Pany wrote: On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote: Glad to announce D 2.078.0. This release comes with runtime detection of Visual Studio installation paths, an integral promotion transition for unary operations on byte and short sized integers, more -betterC features, and a couple of language and library tweaks. Thanks to everyone involved in this https://dlang.org/contributors.html. http://downloads.dlang.org/releases/2.x/2.078.0/ http://dlang.org/changelog/2.078.0.html - -Martin What is the purpose of the coverage option "srcpath"? In my scenario I have a folder "dependencies" and a folder "source". I want to generate code coverage only for the files in folder "source". dmd -unittest -cov source/app.d dependencies/dep.d app.exe --DRT-covopt="srcpath:./source dstpath:./cov" By specifying "srcpath" there are 2 empty files created in folder cov: source-app.lst dependencies-dep.lst I thought by specifying "srcpath" I limit the code coverage generation to the files located in folder source... From what I saw in the code, I think what it does is just override where the code was actually placed when you compiled, so tools to visualize the coverage can show you the source code. * https://dlang.org/code_coverage.html#switchsrcpath * https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L83-L84 * https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L211 BTW, to just report coverage of certain files you can just compile with `-cov` those files. I guess that should work (maybe? :).
