On Wednesday, 28 June 2017 at 00:22:56 UTC, Mike Parker wrote:
On Wednesday, 28 June 2017 at 00:16:23 UTC, Mike Parker wrote:
On Tuesday, 27 June 2017 at 19:07:49 UTC,
You have to specify the appropriate linker option, e.g.
-L-option. For gcc, that happens to -L, so you get -L-L. For
optlink
I am behind a corporate firewall at work so I have to manually
install dub packages. This requires setting the version manually,
otherwise master is inferred. This was working great until I had
ended a dub run command early. Now dub seems to have forgotten
that the versions are in there. It's
On Wednesday, 28 June 2017 at 19:54:01 UTC, jmh530 wrote:
[snip]
Does not seem to be a problem for another project using dub with
dmd and similar dependencies...
On Wednesday, 28 June 2017 at 20:18:20 UTC, jmh530 wrote:
On Wednesday, 28 June 2017 at 19:54:01 UTC, jmh530 wrote:
[snip]
Does not seem to be a problem for another project using dub
with dmd and similar dependencies...
After spending some time looking through the dub issues, I found
that
According to the standard (http://dlang.org/spec/float.html), the
compiler is allowed to compute any floating-point statement in a
higher precision than specified. Is there a way to deactivate
this behaviour?
Context (reason why I need this): I am building a "double double"
type, which
On Wednesday, 28 June 2017 at 22:16:48 UTC, Simon Bürger wrote:
(If you are interested in the "double double" type, take a look
here:
https://github.com/BrianSwift/MetalQD
which includes a double-double and even quad-double
implementation in C/C++/Fortran)
Nice work can you re or dual
On Wednesday, 28 June 2017 at 23:56:42 UTC, Stefan Koch wrote:
As for your problems they can be worked around.
by assigning every temporary to a variable.
Which will enforce the discarding of precision.
Sorry for the misinformation!
I was using the newCTFE fork which fixes this.
Indeed you'll
On Wednesday, 28 June 2017 at 22:16:48 UTC, Simon Bürger wrote:
I am currently using LDC on 64-bit-Linux if that is relevant.
It is, as LDC on Windows/MSVC would use 64-bit compile-time
reals. ;)
Changing it to double on other platforms is trivial if you
compile LDC yourself. You'll want
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon as you use DerelictUtil for
example.
I thought I had (implicitly): B needs to be `@disable finalize`.
On Wednesday, 28 June 2017 at 09:22:07 UTC, Guillaume Piolat
wrote:
Deterministic destruction is a _solved_ problem in C++, and a
number of users to convert are now coming from C++.
It is also in D, as long as you don't use the GC (which is
inherently non-deterministic).
3. Suggest a
On Wednesday, 28 June 2017 at 02:13:10 UTC, Jonathan M Davis
wrote:
There are definitely cases where finalizers make sense. Case in
point: if you have a socket class, it makes perfect sense for
it to have a finalizer. Yes, it's better to close it manually,
but it will work just fine for the GC
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
On Wednesday, 28 June 2017 at 02:13:10 UTC, Jonathan M Davis
wrote:
There are definitely cases where finalizers make sense. Case
in point: if you have a socket class, it makes perfect sense
for it to have a finalizer. Yes,
On Wednesday, 28 June 2017 at 11:49:57 UTC, Balagopal Komarath
wrote:
Shouldn't the compiler be able to resolve foo!g(3) to the first
template foo?
import std.stdio;
import std.algorithm;
import std.range;
auto foo(F, T)(T x)
{
return x.foo(F);
}
auto foo(F, T)(T x, F f)
{
return
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon as you use DerelictUtil for
example.
What's the issue with DerelictUtil?
On Wednesday, 28 June 2017 at 11:21:07 UTC, Moritz Maxeiner wrote:
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon as you use DerelictUtil for
example.
I thought I had
On Wednesday, 28 June 2017 at 11:34:17 UTC, Moritz Maxeiner wrote:
Requirement: Do not allocate using the GC
Option 1) Use structs with `@disable this`, `@disable
this(this)`, and a destructor that checks whether the resource
reference is != invalid resource reference before trying to
On Wednesday, 28 June 2017 at 12:33:24 UTC, Guillaume Piolat
wrote:
On Wednesday, 28 June 2017 at 11:34:17 UTC, Moritz Maxeiner
wrote:
Requirement: Do not allocate using the GC
Option 1) Use structs with `@disable this`, `@disable
this(this)`, and a destructor that checks whether the resource
Shouldn't the compiler be able to resolve foo!g(3) to the first
template foo?
import std.stdio;
import std.algorithm;
import std.range;
auto foo(F, T)(T x)
{
return x.foo(F);
}
auto foo(F, T)(T x, F f)
{
return f(x);
}
int g(int x) { return x; }
void main()
{
foo(3, ); // 2nd
I can't understand why follow code is crushing:
string error = "503 Server error!";
int error_code = 503;
res.render!("error.dt", error, error_code);
on res string (last in code above) I am getting error:
CoreTaskFiber was terminated unexpectedly: Access Violation
error.dt
On Wednesday, 28 June 2017 at 12:28:28 UTC, Guillaume Piolat
wrote:
On Wednesday, 28 June 2017 at 11:21:07 UTC, Moritz Maxeiner
wrote:
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon
It's look like issue in another part of code...
On Wednesday, 28 June 2017 at 13:02:04 UTC, Mike Parker wrote:
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon as you use DerelictUtil for
example.
What's the issue with
On Wednesday, 28 June 2017 at 13:19:37 UTC, Guillaume Piolat
wrote:
https://forum.dlang.org/post/pmulowxpikjjffkrs...@forum.dlang.org
Not an issue with DerelictUtil, an issue with the strategy of
closing resources in GC with this case.
Derelict loaders work-around this by not unloading
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
I'm coming from a C++ background so I'm not too used to garbage
collection and it's implications. I have a function that
creates a std.socket.Socket using new and connects to a tcp
server, and writes some stuff to it. I then
On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
I'm coming from a C++ background so I'm not too used to garbage
collection and it's implications. I have a function that
creates a std.socket.Socket using new and connects to a tcp
server, and writes some stuff to it. I then
I want to call a method of the certain instance of "MyClass" from
certain widget.
Each widget should know its corresponding instance of "MyClass".
As far as I understood, delegates cannot do it.
On 2017-06-27 17:24, Steven Schveighoffer wrote:
Yes, Tango solved this by having a separate "finalize()" method. I wish
we had something like this.
Not sure if this is the same, but I remember that Tango had a separate
method called "dispose" that was called if a class was allocated on the
On 2017-06-27 11:54, John Burton wrote:
I'm coming from a C++ background so I'm not too used to garbage
collection and it's implications. I have a function that creates a
std.socket.Socket using new and connects to a tcp server, and writes
some stuff to it. I then explicitly close the socket,
28 matches
Mail list logo
