On Sunday, 6 January 2019 at 00:20:40 UTC, Samir wrote:
[1] https://news.ycombinator.com/item?id=18832155
[2] https://en.wikipedia.org/wiki/IEEE_754
Since you got your answer you may also like
http://dconf.org/2016/talks/clugston.html
On Sunday, 6 January 2019 at 02:23:20 UTC, H. S. Teoh wrote:
But something like Adam Ruppe's adrdox could possibly be the
basis for translating individual module symbols into manpages
perhaps?
The approach I'd take is actually converting my generated html to
text and just piping it through
On Sat, Jan 05, 2019 at 09:59:27PM +, kdevel via Digitalmars-d-learn wrote:
> For years I missed the man pages of the C++ standard library and now
> found out that some Linux distros provide them as extra package. The
> man pages are not generated by a default during a GCC bootstrap
> install
On Sunday, 6 January 2019 at 00:20:40 UTC, Samir wrote:
import std.stdio: writeln;
void main(){
writeln(cast(double).0-9998.0);
}
That's because it is done at compile time, since both are
compile-time constants. The compiler will evaluate it using the
maximum
I saw the following thread[1] today on Hacker News that discusses
an article that compares how various languages compute
.0 - 9998.0. A surprisingly large
number of languages return 2 as the answer. I ran the following
which returned 1:
import std.stdio:
I applied the head
commit ce249d880969111384d17f744687e427c843f1d4
Merge: 8a6b7a4 0e517e4
Author: Eugene Wissner
Date: Tue Apr 10 15:37:32 2018 +0200
Merge pull request #647 from belka-ew/gdc-49up
Merge branch gdc-5 into gdc-4.9
of branch gdc-4.9 on top of
For years I missed the man pages of the C++ standard library and
now found out that some Linux distros provide them as extra
package. The man pages are not generated by a default during a
GCC bootstrap install but need an explicit make doc-install-man
in the corresponding doc directory of
On Saturday, 5 January 2019 at 18:44:33 UTC, greatsam4sure wrote:
On Friday, 4 January 2019 at 09:56:14 UTC, bauss wrote:
On Friday, 4 January 2019 at 09:48:55 UTC, greatsam4sure wrote:
On Thursday, 3 January 2019 at 04:57:57 UTC, Me wrote:
On Thursday, 3 January 2019 at 00:23:50 UTC,
On Friday, 4 January 2019 at 09:56:14 UTC, bauss wrote:
On Friday, 4 January 2019 at 09:48:55 UTC, greatsam4sure wrote:
On Thursday, 3 January 2019 at 04:57:57 UTC, Me wrote:
On Thursday, 3 January 2019 at 00:23:50 UTC, greatsam4sure
wrote:
[...]
Windows 10 --- got it
VibeD project --- got
On Sat, 05 Jan 2019 17:44:27 +, Neia Neutuladh wrote:
> 2. Different build configurations. The same source code has two
> different build targets; the executable doesn't depend on the library.
> Or, with enough bludgeoning, you can make the executable depend on the
> library.
Hit 'send' too
On Sat, 05 Jan 2019 13:01:24 +, Russel Winder wrote:
> Dub seems to have the inbuilt assumption that libraries are dependencies
> that do not change except via a formal release when you developing an
> application.
> Clearly there is the workflow where you want to amend the library but
> not
On Friday, 4 January 2019 at 14:36:16 UTC, Mike Parker wrote:
v is a run-time value, not available at compile time.
Sorry about that, looks like if I edit the text in the
run.dlang.io editor, the link also gets updated. I was using
"void opAssign(T)(T v)" in the initial example, but it seems
On Saturday, 5 January 2019 at 15:17:28 UTC, Mike Parker wrote:
On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder
wrote:
Dub seems to have the inbuilt assumption that libraries are
dependencies that do not change except via a formal release
when you developing an application. Clearly
On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote:
Dub seems to have the inbuilt assumption that libraries are
dependencies that do not change except via a formal release
when you developing an application. Clearly there is the
workflow where you want to amend the library but
On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote:
Dub seems to have the inbuilt assumption that libraries are
dependencies that do not change except via a formal release
when you developing an application. Clearly there is the
workflow where you want to amend the library but
On Saturday, 5 January 2019 at 12:14:15 UTC, Russel Winder wrote:
Indeed. I should do that to see if I can reproduce the problem
to submit a proper bug report.
File_Ptr is wrapping a dvb_file * from libdvbv5 to try and make
things a bit for D and to ensure RAII. libdvbv5 is a C API with
On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote:
Dub seems to have the inbuilt assumption that libraries are
dependencies that do not change except via a formal release
when you developing an application. Clearly there is the
workflow where you want to amend the library but
Dub seems to have the inbuilt assumption that libraries are dependencies that
do not change except via a formal release when you developing an application.
Clearly there is the workflow where you want to amend the library but not
release as a part of developing an application. Does Dub have a way
On Sat, 2019-01-05 at 11:30 +, Nicholas Wilson via Digitalmars-d-learn
wrote:
>
[…]
> Could you post a minimised example? Its a bit hard to guess
> without one.
Indeed. I should do that to see if I can reproduce the problem to submit a
proper bug report.
[…]
> From the name, File_Ptr
On Saturday, 5 January 2019 at 10:52:48 UTC, Russel Winder wrote:
I found the problem and then two minutes later read your email
and bingo we have found the problem.
Well done.
Previously I had used File_Ptr* and on this occasion I was
using File_Ptr and there was no copy constructor because
On Sat, 2019-01-05 at 10:52 +, Russel Winder wrote:
> On Sat, 2019-01-05 at 10:31 +, Nicholas Wilson via Digitalmars-d-learn
> wrote:
> […]
> > Maybe it is a problem with copying a File_Ptr (e.g. missing a
> > increase of the reference count)? Like, `auto a = File_Ptr(); {
> > auto b =
On Sat, 2019-01-05 at 10:31 +, Nicholas Wilson via Digitalmars-d-learn
wrote:
[…]
>
> Maybe it is a problem with copying a File_Ptr (e.g. missing a
> increase of the reference count)? Like, `auto a = File_Ptr(); {
> auto b = a; }` and b calls the destructor on scope exit.
> That would be
On Saturday, 5 January 2019 at 07:34:17 UTC, Russel Winder wrote:
TransmitterData has a destructor defined but with no code in
it. This used to work fine – but I cannot be certain which
version of LDC that was.
The problem does seem to be in the construction of the
TransmitterData object
23 matches
Mail list logo
