Re: Relative lflag paths in dub on Windows
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 it's +something and for the MS linker it's /something. I'm on my phone else I'd look it up. Optlink instructions at [1]: -L+path\ MS linker [2]: -L/LIBPATH:path [1] https://wiki.dlang.org/Compiling_and_linking_with_DMD_on_Windows [2] https://docs.microsoft.com/en-us/cpp/build/reference/libpath-additional-libpath I appreciate you posting this. I had found the /LIBPATH, but dub randomly crapped out on me before I was about to test it, so I'm going to start another thread just on that...
dub seems to have forgotten my versions
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 weird because dub list has
them.
C:\ProgrammingFiles\DFiles\testing\testing_mir_glas>dub list
Packages present in the system and known to dub:
nlopt 0.1.0: C:\ProgrammingFiles\DFiles\nlopt\
mir-algorithm 0.6.6:
C:\ProgrammingFiles\DFiles\dubFolder\mir-algorithm-0.6.6\
lubeck 0.0.3: C:\ProgrammingFiles\DFiles\dubFolder\lubeck-0.0.3\
[snip]
and the local-packages.json has entries like
{
"name": "nlopt",
"version": "0.1.0",
"path": "C:\\ProgrammingFiles\\DFiles\\nlopt\\"
},
but trying to build it cannot determine the version and assumes
master (below). My sense is that I need to remove dub and
local.packages.json and re-install everything. This process would
be faster if dub weren't spending all this time trying and
failing to download files. I wish I could tell it not to bother
going online.
C:\ProgrammingFiles\DFiles\testing\testing_mir_glas>dub build
--compiler=ldmd2 -
-verbose
Using dub registry url 'http://code.dlang.org/'
Refreshing local packages (refresh existing: true)...
Looking for local package map at
C:\ProgramData\dub\packages\local-packages.json
Looking for local package map at
C:\Users\[user]\AppData\Roaming\dub\packages\l
ocal-packages.json
Try to load local package map at
C:\Users\[user]\AppData\Roaming\dub\packages\l
ocal-packages.json
Note: Failed to determine version of package mir-algorithm at ..
Assuming ~maste
r.
Note: Failed to determine version of package lubeck at ..
Assuming ~master.
Note: Failed to determine version of package mir-cpuid at ..
Assuming ~master.
Note: Failed to determine version of package mir-glas at ..
Assuming ~master.
Note: Failed to determine version of package mir-lapack at ..
Assuming ~master.
Note: Failed to determine version of package mir-random at ..
Assuming ~master.
Note: Failed to determine version of package scid at .. Assuming
~master.
Note: Failed to determine version of package cblas at .. Assuming
~master.
Note: Failed to determine version of package lapack at ..
Assuming ~master.
Note: Failed to determine version of package numir at .. Assuming
~master.
Note: Failed to determine version of package drepl at .. Assuming
~master.
Note: Failed to determine version of package colorize at ..
Assuming ~master.
Note: Failed to determine version of package libdparse at ..
Assuming ~master.
Note: Failed to determine version of package linenoise at ..
Assuming ~master.
Note: Failed to determine version of package drepl at .. Assuming
~master.
Note: Failed to determine version of package mir-blas at ..
Assuming ~master.
Note: Failed to determine version of package rdub at .. Assuming
~master.
Note: Failed to determine version of package testing_mir_glas at
.. Assuming ~ma
ster.
The determined compiler type "ldc" doesn't match the expected
type "dmd". This w
ill probably result in build errors.
Refreshing local packages (refresh existing: false)...
Looking for local package map at
C:\ProgramData\dub\packages\local-packages.json
Looking for local package map at
C:\Users\[user]\AppData\Roaming\dub\packages\l
ocal-packages.json
Try to load local package map at
C:\Users\[user]\AppData\Roaming\dub\packages\l
ocal-packages.json
Note: Failed to determine version of package mir-algorithm at ..
Assuming ~maste
r.
Note: Failed to determine version of package lubeck at ..
Assuming ~master.
Note: Failed to determine version of package mir-cpuid at ..
Assuming ~master.
Note: Failed to determine version of package mir-glas at ..
Assuming ~master.
Note: Failed to determine version of package mir-lapack at ..
Assuming ~master.
Note: Failed to determine version of package mir-random at ..
Assuming ~master.
Note: Failed to determine version of package scid at .. Assuming
~master.
Note: Failed to determine version of package cblas at .. Assuming
~master.
Note: Failed to determine version of package lapack at ..
Assuming ~master.
Note: Failed to determine version of package numir at .. Assuming
~master.
Note: Failed to determine version of package drepl at .. Assuming
~master.
Note: Failed to determine version of package colorize at ..
Assuming ~master.
Note: Failed to determine version of package libdparse at ..
Assuming ~master.
Note: Failed to determine version of package linenoise at ..
Assuming ~master.
Note: Failed to determine version of package drepl at .. Assuming
~master.
Note: Failed to determine version of package mir-blas at ..
Assuming ~master.
Note: Failed to determine version of package rdub at .. Assuming
~master.
Note: Failed to determine version of package testing_mir_glas at
.. Assuming ~ma
ster.
Found dependency
Re: dub seems to have forgotten my versions
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...
Re: dub seems to have forgotten my versions
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 you can use the option --nodeps effectively as an offline mode. The code compiles with --nodeps, but still fails without it.
Force usage of double (instead of higher precision)
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 essentially takes two 64-bit double-precision numbers
to emulate a (nearly) quadruple-precision number. A simplified
version looks something like this:
struct ddouble
{
double high;
double low;
invariant
{
assert(high + low == high);
}
// ...implemententations of arithmetic operations...
}
Everything works fine at run-time, but if I declare a
compile-time constant like
enum pi = ddouble(3.141592653589793116e+00,
1.224646799147353207e-16);
the invariant fails because it is evaluated using 80-bit
"extended precision" during CTFE. All arithmetic operations rely
on IEEE-conform double-precision, so everything breaks down if
the compiler decides to replace them with higher precision. I am
currently using LDC on 64-bit-Linux if that is relevant.
(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)
Re: Force usage of double (instead of higher precision)
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 license under the boost license ? I'd like to incorporate the qd type into newCTFE. As for your problems they can be worked around. by assigning every temporary to a variable. Which will enforce the discarding of precision.
Re: Force usage of double (instead of higher precision)
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 have no way to get rid of the excess precision except for creating a function per sub-expression.
Re: Force usage of double (instead of higher precision)
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 to use this alias: https://github.com/ldc-developers/ldc/blob/master/ddmd/root/ctfloat.d#L19, https://github.com/ldc-developers/ldc/blob/master/ddmd/root/ctfloat.h#L19
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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`.
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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 systematic, always working, workaround (or language change such as "GC doesn't call ~this). C++ users have no difficulty having an object graph with detailed ownership schemes, that's what they do day in day out. It's important to have a _simple_ story about resource release, else we will talk about "GC" every day, and hearing about "GC" is bad for marketing. 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 release. Option 2) Use classes with simple constructor/destructor layout. If you want to integrate a check that the requirement holds (with either class or struct), put `if (gc_inFinalizer) throw SomeError` into the class/struct destructor
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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 to close it when finalizing the class object so long as you don't use so many sockets that you run out before the GC collects them. So, having a finalizer is a good backup to ensure that the socket resource doesn't leak. - Jonathan M Davis So far everyone is ignoring my example when A needs B to be destroyed. This happens as soon as you use DerelictUtil for example.
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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, it's better to close it manually, but it will work just fine for the GC to close it when finalizing the class object so long as you don't use so many sockets that you run out before the GC collects them. So, having a finalizer is a good backup to ensure that the socket resource doesn't leak. - Jonathan M Davis So far everyone is ignoring my example when A needs B to be destroyed. This happens as soon as you use DerelictUtil for example. And I'm gonna rant a little bit more. Deterministic destruction is a _solved_ problem in C++, and a number of users to convert are now coming from C++. We should: 1. be honest and tell things as they are: it's more complicated than in C++, but also liberating when you know to juggle between GC and deterministic 2. Avoid making bogus suggestions which don't always work, such as close() methods, releasing resource with GC, . They only work for _some_ resources. 3. Suggest a systematic, always working, workaround (or language change such as "GC doesn't call ~this). C++ users have no difficulty having an object graph with detailed ownership schemes, that's what they do day in day out. It's important to have a _simple_ story about resource release, else we will talk about "GC" every day, and hearing about "GC" is bad for marketing.
Re: Overloading funtion templates.
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 f(x);
}
int g(int x) { return x; }
void main()
{
foo(3, ); // 2nd foo
foo!g(3); // error
}
I get the error message.
onlineapp.d(20): Error: template onlineapp.foo cannot deduce
function from argument types !(g)(int), candidates are:
onlineapp.d(5): onlineapp.foo(F, T)(T x)
onlineapp.d(10):onlineapp.foo(F, T)(T x, F f)
symbol 'g' isn't type.
auto foo(alias F, T)(T x)
{
return x.foo();
}
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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?
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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 (implicitly): B needs to be `@disable finalize`. So in the current language, doesn't exist?
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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 release. Option 2) Use classes with simple constructor/destructor layout. If you want to integrate a check that the requirement holds (with either class or struct), put `if (gc_inFinalizer) throw SomeError` into the class/struct destructor I don't get it. It's completely possible to use the full power of GC and be deterministic. I'm out of this very _confused_ discussion.
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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
reference is != invalid resource reference before trying to
release.
Option 2) Use classes with simple constructor/destructor
layout.
If you want to integrate a check that the requirement holds
(with either class or struct), put `if (gc_inFinalizer) throw
SomeError` into the class/struct destructor
I don't get it.
You asked for a "_simple_ story about resource release" and the
above two options provide that IMHO.
It's completely possible to use the full power of GC and be
deterministic.
Sure, but it's not "simple". With D's GC as the memory allocator
you can currently have
(1) non-deterministic memory management and non-deterministic
object lifetimes:
Use `new` or
`std.experimental.allocator.make!(std.experimental.allocator.gc_allocator.GCAllocator)` for allocation
The GC will finalize objects with no pointers to them
non-deterministically and deallocate the memory after their
respective finalization.
(2) non-deterministic memory management and deterministic object
lifetimes:
Construct the objects as with (1), but destruct them by
calling `destroy` on them outside of a collection cycle (i.e.
when they, and all their members are still considered "live" by
the GC).
The GC will collect the memory non-deterministically after
there are no more pointers to it.
Warning: You are responsible for ensuring that the GC will
never see an undestroyed object in the collection cycle, because
it might try to finalize (call its `~this`) it.
You can protect yourself against such finalization
attempts by putting `if (gc_inFinalizer) throw Error("Bug! I
forgot to destruct!")` in the objects' respective destructors.
(3) deterministic memory management and deterministic object
lifetimes:
Construct the objects as with (1), but destruct
them by calling
`std.experimental.allocator.dispose!(std.experimental.allocator.gc_allocator.GCAllocator)`on them outside of a collection cycle.
The GC will not do anything for those objects.
Same warning as (2) applies.
I'm out of this very _confused_ discussion.
I'm honestly not sure what's confusing about it.
Overloading funtion templates.
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 foo
foo!g(3); // error
}
I get the error message.
onlineapp.d(20): Error: template onlineapp.foo cannot deduce
function from argument types !(g)(int), candidates are:
onlineapp.d(5): onlineapp.foo(F, T)(T x)
onlineapp.d(10):onlineapp.foo(F, T)(T x, F f)
Diet template is crush
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 http://paste.code123.org/91ea2dc1-7396
If delete part:
div.errorPageText #{error}
div.errorPageImg
- if (error_code == 404)
img(src='img/error_404.png')
- else
img(src='img/error_503.png')
All work fine. It's seems that something wrong with args `error,
error_code`.
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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 as you use DerelictUtil for example. I thought I had (implicitly): B needs to be `@disable finalize`. So in the current language, doesn't exist? I thought that was the premise of the discussion? That the GC *currently* invokes the "destructors" as finalizers and that *currently* the only way to avoid that is calling `destroy` on them manually beforehand (since destructors won't be called twice on a single object).
Re: Diet template is crush
It's look like issue in another part of code...
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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 DerelictUtil? 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 shared libraries so the GC won't unload shared libs before the resources related to the shared library are freed. https://github.com/DerelictOrg/DerelictAL/blob/master/source/derelict/openal/dynload.d#L366
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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 shared libraries so the GC won't unload shared libs before the resources related to the shared library are freed. https://github.com/DerelictOrg/DerelictAL/blob/master/source/derelict/openal/dynload.d#L366 Yeah, the loaders all used to needlessly unload the shared libraries in a static destructor. The fact that they don't anymore isn't to avoid any GC/destructor issues, but because there's no point in unloading the libraries when the system is going to do it anyway.
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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 explicitly close the socket, and the socket object goes out of scope. Am I doing this right? Or is there a better way to do this in D? Thanks. For my use case here, I'm increasingly thinking that just calling the underlying 'C' socket and send calls is better. No need for anything complicated at all for my actual program :)
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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 explicitly close the socket, and the socket object goes out of scope. [...] May be you can see yu: https://github.com/dushibaiyu/yu
What is best way to link DlangUI widget and program logic?
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.
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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 stack, i.e. with the "scope" keyword. -- /Jacob Carlborg
Re: Advice wanted on garbage collection of sockets for c++ programmer using D
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, and the socket object goes out of scope. Yes. You can use "scope (exit)", unless you're already doing so. Now the issue is that I now need to call this function more than once every second. I worry that it will create large amounts of uncollected "garbage" which will eventually lead to problems. Sounds like you need a connection pool. The vibe.d [1] framework contains connection pools. It's also possible to manually disable the GC for a while and then enable it again. [1] http://vibed.org -- /Jacob Carlborg
