Re: Remember the Vasa! by Bjarne Stroustrup
On Tuesday, 29 May 2018 at 20:37:38 UTC, Tony wrote: On Tuesday, 29 May 2018 at 20:19:09 UTC, bachmeier wrote: I don't think it's difficult to do that yourself. There's no need to have a formal split. One example is that it's really nice to have the GC available for part of the program and avoid it for another part. @nogc gives you a guarantee. Different variants of the language are a special case of this that is equivalent to annotating the entire program to restrict behavior. That's rarely desirable. What would be an example of a type of application (or maybe that should be "which type of domain" or "which type of developer") where you would want part of it to do garbage collection and the rest of it do not do garbage collection? I believe that's how the Weka guys say they use D for their distributed, parallel filesystem, so you can add it to the list of applications others gave you: https://www.youtube.com/watch?v=RVpaNM-f69s
Re: SecureD Futures (v2.0)
On 05/29/2018 11:29 AM, Brad Roberts wrote: On 5/29/2018 1:57 AM, Adam Wilson via Digitalmars-d wrote: One of the pillars of SecureD is that ONLY safe, well-known, algorithms are presented. If reasonable we will only present one algorithm for a specific purpose. If there is a good reason to add more than one algorithm, we will. One of the pillars of crypto is that eventually a problem will be found with every algorithm, it's just a matter of time. So, having just one available means that eventually the library will be horribly broken. The corollary here is that having a fallback is pretty essential. Sure. For example, TLS 1.3 supports AES, Camellia, ARIA, and ChaCha20-Poly1305 for symmetric ciphers. However, when you look at the best-practice recommendations, AES is the clear winner. And when you look at what actually gets used, it's AES. AES is the Gold Standard and it would take a fundamental breakthrough in cryptanalysis for that to change. But what happens to TLS1.3 if there is a fundamental breakthrough? - ARIA uses an AES derived substitution-permutation network. - Camellia uses the same S-box that AES does. (It was an AES contender) - Poly1305 for ChaCha20 directly uses AES in it's PRF. Which algorithm do you switch to? Anything that breaks AES can also be used against these other algorithms. In this case, ChaCha20 is probably the best answer, but only if you apply a different MAC to it. It's a good thing that a fundamental breakthrough in cryptanalysis is unlikely in the foreseeable future. Of course, that's what we told ourselves before 3DES and Differential Cryptanalysis. I don't disagree with you. But the overwhelming cacophony of choice presents it's own issues. (See: The Paradox of Choice) SecureD v2 could easily support these ciphers, and I don't really have a problem adding them for the purposes of compatibility. But the default is going to be AES for the forseeable future. The design premise of SecureD is to make the the safe defaults easy and everything else hard. In cases where there are known weaknesses SecureD does intend to support multiple algorithms, but usually only two, for example SHA2 potentially suffers from the same weaknesses as SHA1, and as a result SecureD v2 will be getting SHA3 support whenever OpenSSL 1.1.1 drops. But it's not going to add things like Whirlpool or Skein. Or RSA versus ECC. I am considering adding Curve25519 support to v2, but with NSA/NIST deprecating ECC altogether (as it is less resistant to quantum computing than RSA, see: https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Quantum_computing_attacks) it may be better to wait-and-see what comes of the work being done on quantum-resistant public-key cryptography. The new Supersingular Isogeny Diffie-Hellman (SIDH) looks like a strong contender, but nothing implements it, and it's way too new to put any trust in it yet. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Build interface from abstract class
On Wednesday, 30 May 2018 at 01:46:30 UTC, Chameleon wrote: On Monday, 28 May 2018 at 20:13:49 UTC, DigitalDesigns wrote: Here is my solution that does not solve problem 2: import std.stdio; [...] this is not programming. this is witchcraft! Just call me Dandalf the D Slayer! At least I finally got it to work. It's terrible that I have to use import and read the file in directly to do this ;/ It is working though.
Re: SmartRef： The Smart Pointer In D
On Friday, 13 January 2017 at 16:50:37 UTC, Dsby wrote: I write the ref count pointer and the scoped point in D. it just Like cpp's shared_ptr ， waek_ptr and unique_ptr . Now, it is Developing. I will write more test before the frist release. And the docs is null. It on github: https://github.com/huntlabs/SmartRef Very nice. Do you have a dub package for this?
Re: Build interface from abstract class
On Monday, 28 May 2018 at 20:13:49 UTC, DigitalDesigns wrote: Here is my solution that does not solve problem 2: import std.stdio; [...] this is not programming. this is witchcraft!
Re: Remember the Vasa! by Bjarne Stroustrup
On Tuesday, 29 May 2018 at 23:55:07 UTC, Dave Jones wrote: Which is ironic considering... Ken Thomson : " Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said “no” to no one. He put every feature in that language that ever existed. It wasn’t cleanly designed—it was just the union of everything that came along. And I think it suffered drastically from that." Donald Knuth : "Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said "OK, we'll do them both". So the language is too baroque for my taste." good old Ken and Don are from a generation where you could (typically) understand the whole langauge. those times have passed. no really.. they have...I'm not kidding... It is now just complete nonsense that one person should be able to understand a modern programming langauge. At best, they will understand some of it. These days, it must be about collaboration - which is something D suffers from not having, due to people believing that they should be able to understand it all, and therefore progress should stop when this no longer becomes possible. That is essentially a human-ego driven perspective, that holds back progress. Progress in modern times requires collaboration. People who know and understand parts, connecting and collaborating with people who know and understand other parts. That is the way the C++ design by committee works. It might not be perfect, but its much better than having a King that you cannot say 'no' too (ie Vasa), or a King that always says 'no' to the people. D needs more collaborators, and less kings.
[Issue 18913] New: Cannot move static array of non-copyable type
https://issues.dlang.org/show_bug.cgi?id=18913
Issue ID: 18913
Summary: Cannot move static array of non-copyable type
Product: D
Version: D2
Hardware: All
OS: Windows
Status: NEW
Severity: major
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
This code fails
struct NoCopy
{
int payload; // some payload
~this() { } // destructor to observe moving
@disable:
this(this); // make it non copyable
}
void f(NoCopy[2]) { }
void main()
{
import std.algorithm.mutation : move;
NoCopy[2] ncarray = [ NoCopy(1), NoCopy(2) ];
static assert(!__traits(compiles,
f(ncarray) // would copy
));
f(move(ncarray)); // fails
}
move wants to copy content.
This is not a dup of 8067.
--
Re: Tiny D suitable for embedded JIT
On 30/05/2018 11:59 AM, Dibyendu Majumdar wrote: On Thursday, 24 May 2018 at 22:14:50 UTC, Jonathan Marler wrote: Sad to hear. Was interested to see if this was feasible. I don't have much experience with the backend but if you're still up for the task, take a look at `dmd/glue.d`. I don't know how much of the glue layer this includes but it would be a good start. DMD does have a common "glue layer" shared by DMD, LDC and GDC, so you'd basically need to find the API to build this glue layer and that's what you would use. https://github.com/dlang/dmd/blob/master/src/dmd/glue.d Hi - not really as I don't know what this does. In any case my understanding is the interface between the front-end and GDC/LDC is at the level of ASTs. Regards The input is the AST, the output to the backend is some form of IR in essence. It just maps one understanding of the code to another form, that's all.
Re: Build interface from abstract class
On Tuesday, 29 May 2018 at 20:53:14 UTC, DigitalDesigns wrote:
On Tuesday, 29 May 2018 at 20:26:52 UTC, arturg wrote:
On Tuesday, 29 May 2018 at 19:06:24 UTC, DigitalDesigns wrote:
On Monday, 28 May 2018 at 22:15:40 UTC, arturg wrote:
this might help you,
https://dpaste.dzfl.pl/2cf844a11e3f
you can use them to generate the functions as strings.
Thanks,
So, the problem I'm having is that I cannot use the generated
interface for the abstract class because the abstract class
needs the interface defined. I need to be able to forward
define the interface then extend it.
D doesn't like this
main.d(10): Error: interface `main.B` base `A` is forward
referenced
interface A;
mixin(Generate!(B,A));
interface B : A
{
}
abstract class C : B
{
}
would it work if you define the interface but mixin the
members?
interface A
{
mixin(InterfaceFromClass!C);
}
Yes, I made a post about it but it didn't get through or I
forgot to send ;/
Doing it this way solves the original problems but creates a
new problem in that any class that inherits from an abstract
class that implements A doesn't work.
interface A
{
mixin(InterfaceFromClass!C);
}
abstract class B : A
{
A foo() { return this; }
int bar() { return 3; }
}
class C : B
{
// compiler says foo, bar not implemented
}
so, instead
interface A
{
mixin(InterfaceFromClass!C);
}
abstract class B
{
A foo() { return this; } // requires cast
int bar() { return 3; }
}
class C : B, A
{
}
works but requires casting this in B which happens to work in
C. So It is a fessible solution but I'm not sure why the
compiler things the first case doesn't implement the methods
when it clearly does. I think it looks at A and doesn't compute
the mixin first when parsing C because if I put the output of
the mixin directly it works. Probably a bug...
This method, which imports the source code and extracts the
members works but is very fragile and requires using -J:
// Directly copies the data to the interface with a few hacks to
fix the bug from the original, it excepts a well formatted input
template InterfaceFromClass(alias T)
{
string InterfaceFromClass(string file = __FILE_FULL_PATH__)()
{
string res;
import std.path, std.string, std.algorithm;
enum data = import(file.baseName);
enum mc = "abstract class "~T.stringof~" : ";
enum im = `@("InterfaceMembers")`;
int level = 0;
auto baseIndentLevel = -1;
int funcIndentLevel = -1;
foreach(v; data.splitLines)
{
string l = v;
auto indentLevel = l.length - l.stripLeft().length;
auto ll = l.strip();
if (ll.length == 0) continue;
//res ~= to!string(l.length) ~"\n" ~ l[0..min(mc.length,
l.length)] ~ "\n";
if (level == 0 && ll.length >= mc.length &&
ll[0..min(mc.length, ll.length)] == mc) { baseIndentLevel =
indentLevel; level = 1; continue; } // Finds "abstract class
: "
if (level == 1 && ll.length >= im.length &&
ll[0..min(im.length, ll.length)] == im) { level = 2; continue;
} // Finds "@("InterfaceMembers))" near by
if (level >= 2 && l == "}") break;
if (level == 2 && ll.length > 1)
{
if (funcIndentLevel < 0) funcIndentLevel =
indentLevel;
if (funcIndentLevel < indentLevel) continue;
// A simple function definition(ends with a
');')
if (!ll.canFind("=") && l.length > 2 && l[$-2..$] == ");") {
res ~= l ~ "\n"; continue; }
// ignore fields(assumes it has no {, } but
ends with a ';')
if (!ll.canFind("{") && l[$-1] == ';' && ll[$-2..$] != "};")
continue;
// ignore functions with inline blocks
if (ll.canFind(") {")) { l = l[0..$ - ll.find(") {").length]
~ ")"; }
// must get function signature only(ignore
body)
res ~= l ~ ((ll[$] != ';') ? ";" : "") ~ "\n";
}
}
return res;
}
}
Why the original code is being broke by using D's traits to build
the functions properly is beyond me. I'm pretty sure it is a bug
given the example I gave earlier.
Re: Tiny D suitable for embedded JIT
On Monday, 28 May 2018 at 19:24:58 UTC, MrSmith wrote: You may like the project of a compiler I am doing https://github.com/MrSmith33/tiny_jit TLDR: fully in D. No dependencies. Currently for amd64 + Win64 calling convension. Cool - I will keep an eye on it. Regards
Re: Tiny D suitable for embedded JIT
On Thursday, 24 May 2018 at 22:14:50 UTC, Jonathan Marler wrote: Sad to hear. Was interested to see if this was feasible. I don't have much experience with the backend but if you're still up for the task, take a look at `dmd/glue.d`. I don't know how much of the glue layer this includes but it would be a good start. DMD does have a common "glue layer" shared by DMD, LDC and GDC, so you'd basically need to find the API to build this glue layer and that's what you would use. https://github.com/dlang/dmd/blob/master/src/dmd/glue.d Hi - not really as I don't know what this does. In any case my understanding is the interface between the front-end and GDC/LDC is at the level of ASTs. Regards
Re: Remember the Vasa! by Bjarne Stroustrup
On Tuesday, 29 May 2018 at 05:29:00 UTC, Ali wrote: On Tuesday, 29 May 2018 at 03:56:05 UTC, Dmitry Olshansky wrote: It seems C++ is following the road of PL/I, which is growing language way beyond the point anyone can understand or implement all of it. A key line from this paper We now have about 150 cooks; that’s not a good way to get a tasty and balanced meal. I don't think Bjarne is against adding feature to C++, or even constantly adding feature he even admits to support some of the features he mention in his list I think he is worried about 1. the huge number of features being targeted at once 2. the features coming from different independent teams, making them less likely to be coherent Which is ironic considering... Ken Thomson : " Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said “no” to no one. He put every feature in that language that ever existed. It wasn’t cleanly designed—it was just the union of everything that came along. And I think it suffered drastically from that." Donald Knuth : "Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said "OK, we'll do them both". So the language is too baroque for my taste."
dub subpckages and how to depend on them internally
Hi, I'm trying to get dub working with subpackages and I just
can't quite seem to hit the nail on the head. Any help would be
greatly appreciated.
This is the current setup is like this, and there's a shared
source folder as well called "common" and "sub2" depends on
"sub1".
lib
|-- dub.json
|-- source/
| -- sub1/
| -- package.d
| -- dub.json
| -- sub2/
| -- package.d
| -- dub.json
| -- common/
lib/dub.json
{
"targetPath": "bin",
"targetType": "library",
"dependencies": {
"lib:sub1": "*",
"lib:sub2": "*",
},
"subPackages": [
"./source/sub1",
"./source/sub2"
]
}
And then sub1/dub.json and sub2/dub.json:
sub1:
{
"name": "sub1",
"targetType": "library",
"sourcePaths": ["./", "../common"],
"importPaths": ["./"],
"targetPath": "../bin"
}
sub2:
{
"name": "sub2",
"targetType": "library",
"dependencies": { "lib:sub1": "*" },
"sourcePaths": ["./", "../common", "../sub1"],
"importPaths": ["./"],
"targetPath": "../bin"
}
So with the current set up, running dub test lib:sub1 works and
dub test lib:sub2 works.
What doesn't work is if I try "import lib.sub1" from a test
project. So in test project dub.json I have:
"dependencies": {
"lib": {
"path": "../../lib"
}
}
I get error:
source/app.d(2,8): Error: module `sub1` is in file 'lib/sub1.d'
which cannot be read. The output from dub shows one of my import
paths is: import path[6] = ../../lib/source/sub1/. But I guess
I'm missing something, or doing something wrong.
I also tried:
"dependencies": {
"lib:sub1": {
"path": "../../lib"
}
}
But that gives me the same problem.
Halp!
Re: Remember the Vasa! by Bjarne Stroustrup
On Tuesday, 29 May 2018 at 21:06:52 UTC, Jonathan M Davis wrote: On Wednesday, May 30, 2018 08:43:33 rikki cattermole via Digitalmars-d wrote: On 30/05/2018 8:37 AM, Tony wrote: > On Tuesday, 29 May 2018 at 20:19:09 UTC, bachmeier wrote: >> I don't think it's difficult to do that yourself. There's >> no need to have a formal split. One example is that it's >> really nice to have the GC available for part of the >> program and avoid it for another part. @nogc gives you a >> guarantee. Different variants of the language are a special >> case of this that is equivalent to annotating the entire >> program to restrict behavior. That's rarely desirable. > > What would be an example of a type of application (or maybe > that should be "which type of domain" or "which type of > developer") where you would want part of it to do garbage > collection and the rest of it do not do garbage collection? GUI's, audio systems, language tooling, games, I'm sure somebody can come up with a much more longer list. Basically, stuff that can't afford to have the GC pause the program for more than a millisecond or two has to be careful with the GC, but your average program is going to be perfectly fine with it, and in many cases, it's just part of the program that can't afford the pause - e.g. a thread for an audio or video pipeline. The rest of the program can likely afford it just fine, but that thread or group of threads has to be at least close to realtime, so it can't use the GC. You cant call any code that might take a lock if you're doing real time audio, so that means no malloc/free either. That's standard practice. You either allocate everything up front or you do something like I do which is lock free queues ferrying things to and from the audio thread as needed. I mean the point is needing different memory management for different parts of the program is already a thing with real time audio, GC doesnt really change that.
Re: Getter an lvalue and cannot be modified
On 5/27/18 5:23 AM, IntegratedDimensions wrote:
C[] c;
@property C[] get() { return c; }
get ~= something;
errors out, yet
auto q = get;
q ~= something;
is fine.
It's "fine", but not doing what you may expect.
This appends an element to q, but does nothing to c.
While an array is not exactly a value type, it's also not exactly a
reference type. This is why the compiler complains -- your original code
will append an element and then throw that addition away.
Why is D thinking that ~= is being applied to get, the function, rather
than what it returns?
When I try this, it says "get() is not an lvalue and cannot be
modified", which seems to indicate that the expression get() (meaning
what it returns) is not an lvalue. While it's a bit ambiguous in this
case, a more complicated expression would be self-explanatory. Maybe the
error message could be prepended with 'the expression' to make it clearer.
When I converted a field in to a property, an AA, it is returning null
rather than being initialized by default.
AAs are initialized as null, not sure what you are expecting here? An
example may clear things up.
Seems like properties are
broke. I'd expect a property getter to behave, for all intents and
purposes as if it were field. I shouldn't have to have a temp variable
to be able to use it as such.
You don't normally, but if you want to treat it as an lvalue,
unfortunately, you do.
The workaround is to spell things out:
prop = prop + 1; // instead of prop += 1
But this doesn't work in all cases.
-Steve
Re: full path to source file __FILE__
On Tuesday, 29 May 2018 at 21:41:37 UTC, Ali Çehreli wrote:
On 05/29/2018 02:34 PM, DigitalDesigns wrote:
> auto x(string fp = __FULL_FILE_PATH__)()
{
pragma(msg, fp);
}
?
__FILE_FULL_PATH__
https://dlang.org/spec/expression#specialkeywords
Ali
Lol, thanks:
Re: full path to source file __FILE__
On 5/29/18 5:34 PM, DigitalDesigns wrote:
On Wednesday, 27 July 2016 at 13:58:22 UTC, Jonathan Marler wrote:
On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler wrote:
Is there a way to get the full path of the current source file?
Something like:
__FILE_FULL_PATH__
I'm asking because I'm rewriting a batch script in D, meant to be ran
with rdmd. However, the script needs to know it's own path. The
original batch script uses the %~dp0 variable for this, but I'm at a
loss on how to do this in D. Since rdmd compiles the executable to
the %TEMP% directory, thisExePath won't work.
BATCH
-
echo "Directory of this script is " %~dp0
DLANG
-
import std.stdio;
int main(string[] args) {
writeln("Directory of this script is ", ???);
}
For others who may see this thread, the __FULL_FILE_PATH__ special
trait was added to the dmd compiler with this PR:
https://github.com/dlang/dmd/pull/5959
At the time of this post, the latest released version of D is 2.071.1,
so this trait should be available on any release after that.
Except it doesn't?
auto x(string fp = __FULL_FILE_PATH__)()
{
pragma(msg, fp);
}
?
__FILE_FULL_PATH__, not __FULL_FILE_PATH__ (yes, it was wrong in the
post you quoted).
In addition, you must instantiate the template:
void main()
{
x();
}
-Steve
Re: full path to source file __FILE__
On 05/29/2018 02:34 PM, DigitalDesigns wrote:
> auto x(string fp = __FULL_FILE_PATH__)()
{
pragma(msg, fp);
}
?
__FILE_FULL_PATH__
https://dlang.org/spec/expression#specialkeywords
Ali
Re: full path to source file __FILE__
On Wednesday, 27 July 2016 at 13:58:22 UTC, Jonathan Marler wrote:
On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler
wrote:
Is there a way to get the full path of the current source
file? Something like:
__FILE_FULL_PATH__
I'm asking because I'm rewriting a batch script in D, meant to
be ran with rdmd. However, the script needs to know it's own
path. The original batch script uses the %~dp0 variable for
this, but I'm at a loss on how to do this in D. Since rdmd
compiles the executable to the %TEMP% directory, thisExePath
won't work.
BATCH
-
echo "Directory of this script is " %~dp0
DLANG
-
import std.stdio;
int main(string[] args) {
writeln("Directory of this script is ", ???);
}
For others who may see this thread, the __FULL_FILE_PATH__
special trait was added to the dmd compiler with this PR:
https://github.com/dlang/dmd/pull/5959
At the time of this post, the latest released version of D is
2.071.1, so this trait should be available on any release after
that.
Except it doesn't?
auto x(string fp = __FULL_FILE_PATH__)()
{
pragma(msg, fp);
}
?
string mixin output works when directly used but when generator is used D fails
https://dpaste.dzfl.pl/67691db19ce8
Just delete 9 to 29 for the code to work. Note that none of the
code effects the output but D gives strange errors. In my code it
says the interface members are not implemented(which they are)
foreach (member; __traits(allMembers, T))
{
static foreach (overload; MemberFunctionsTuple!(T,
member))
{
static if (__traits(getProtection, __traits(getMember, T,
member)) == "public")
{
foreach(a; __traits(getAttributes,
overload))
static if (is(typeof(a) == string) && a.length > 0 && a ==
"InterfaceMembers")
{
string q;
foreach(b;
__traits(getAttributes, overload))
static if (is(typeof(b) == string) && b.length > 0 && b
== "InterfaceMembers")
continue;
else
q ~=
"@("~b.stringof~") ";
//s ~=
"\t"~q~cloneFunction!(overload, T) ~ ";\n";
}
}
}
}
is somehow breaking the interface. It should have no effect on it
at all. Seems like a bug to me.
Re: Remember the Vasa! by Bjarne Stroustrup
On Wednesday, May 30, 2018 08:43:33 rikki cattermole via Digitalmars-d wrote: > On 30/05/2018 8:37 AM, Tony wrote: > > On Tuesday, 29 May 2018 at 20:19:09 UTC, bachmeier wrote: > >> I don't think it's difficult to do that yourself. There's no need to > >> have a formal split. One example is that it's really nice to have the > >> GC available for part of the program and avoid it for another part. > >> @nogc gives you a guarantee. Different variants of the language are a > >> special case of this that is equivalent to annotating the entire > >> program to restrict behavior. That's rarely desirable. > > > > What would be an example of a type of application (or maybe that should > > be "which type of domain" or "which type of developer") where you would > > want part of it to do garbage collection and the rest of it do not do > > garbage collection? > > GUI's, audio systems, language tooling, games, I'm sure somebody can > come up with a much more longer list. Basically, stuff that can't afford to have the GC pause the program for more than a millisecond or two has to be careful with the GC, but your average program is going to be perfectly fine with it, and in many cases, it's just part of the program that can't afford the pause - e.g. a thread for an audio or video pipeline. The rest of the program can likely afford it just fine, but that thread or group of threads has to be at least close to realtime, so it can't use the GC. It's kind of like @safe vs @system. It's not uncommon for most of your program to be able to be @safe just fine, but certain stuff just can't be. However, that's not necessarily a good reason to make it so that the entire program is @system. So, you make that piece @sytem and use @trusted appropriately. With the GC, you typically use it and then turn it off or avoid it in select pieces of code that can't afford it. In most cases, it should not be necessary to avoid it entirely even if you can't afford it in part of your program (though as with pretty much everything, there are bound to be exceptions). - Jonathan M Davis
Re: Build interface from abstract class
On Tuesday, 29 May 2018 at 20:26:52 UTC, arturg wrote:
On Tuesday, 29 May 2018 at 19:06:24 UTC, DigitalDesigns wrote:
On Monday, 28 May 2018 at 22:15:40 UTC, arturg wrote:
this might help you,
https://dpaste.dzfl.pl/2cf844a11e3f
you can use them to generate the functions as strings.
Thanks,
So, the problem I'm having is that I cannot use the generated
interface for the abstract class because the abstract class
needs the interface defined. I need to be able to forward
define the interface then extend it.
D doesn't like this
main.d(10): Error: interface `main.B` base `A` is forward
referenced
interface A;
mixin(Generate!(B,A));
interface B : A
{
}
abstract class C : B
{
}
would it work if you define the interface but mixin the members?
interface A
{
mixin(InterfaceFromClass!C);
}
Yes, I made a post about it but it didn't get through or I forgot
to send ;/
Doing it this way solves the original problems but creates a new
problem in that any class that inherits from an abstract class
that implements A doesn't work.
interface A
{
mixin(InterfaceFromClass!C);
}
abstract class B : A
{
A foo() { return this; }
int bar() { return 3; }
}
class C : B
{
// compiler says foo, bar not implemented
}
so, instead
interface A
{
mixin(InterfaceFromClass!C);
}
abstract class B
{
A foo() { return this; } // requires cast
int bar() { return 3; }
}
class C : B, A
{
}
works but requires casting this in B which happens to work in C.
So It is a fessible solution but I'm not sure why the compiler
things the first case doesn't implement the methods when it
clearly does. I think it looks at A and doesn't compute the mixin
first when parsing C because if I put the output of the mixin
directly it works. Probably a bug...
Re: Remember the Vasa! by Bjarne Stroustrup
On 30/05/2018 8:37 AM, Tony wrote: On Tuesday, 29 May 2018 at 20:19:09 UTC, bachmeier wrote: I don't think it's difficult to do that yourself. There's no need to have a formal split. One example is that it's really nice to have the GC available for part of the program and avoid it for another part. @nogc gives you a guarantee. Different variants of the language are a special case of this that is equivalent to annotating the entire program to restrict behavior. That's rarely desirable. What would be an example of a type of application (or maybe that should be "which type of domain" or "which type of developer") where you would want part of it to do garbage collection and the rest of it do not do garbage collection? GUI's, audio systems, language tooling, games, I'm sure somebody can come up with a much more longer list.
Re: Remember the Vasa! by Bjarne Stroustrup
On Tuesday, 29 May 2018 at 20:19:09 UTC, bachmeier wrote: I don't think it's difficult to do that yourself. There's no need to have a formal split. One example is that it's really nice to have the GC available for part of the program and avoid it for another part. @nogc gives you a guarantee. Different variants of the language are a special case of this that is equivalent to annotating the entire program to restrict behavior. That's rarely desirable. What would be an example of a type of application (or maybe that should be "which type of domain" or "which type of developer") where you would want part of it to do garbage collection and the rest of it do not do garbage collection?
Re: Build interface from abstract class
On Tuesday, 29 May 2018 at 19:06:24 UTC, DigitalDesigns wrote:
On Monday, 28 May 2018 at 22:15:40 UTC, arturg wrote:
this might help you,
https://dpaste.dzfl.pl/2cf844a11e3f
you can use them to generate the functions as strings.
Thanks,
So, the problem I'm having is that I cannot use the generated
interface for the abstract class because the abstract class
needs the interface defined. I need to be able to forward
define the interface then extend it.
D doesn't like this
main.d(10): Error: interface `main.B` base `A` is forward
referenced
interface A;
mixin(Generate!(B,A));
interface B : A
{
}
abstract class C : B
{
}
would it work if you define the interface but mixin the members?
interface A
{
mixin(InterfaceFromClass!C);
}
Re: Remember the Vasa! by Bjarne Stroustrup
On Tuesday, 29 May 2018 at 17:40:39 UTC, Tony wrote: On Tuesday, 29 May 2018 at 11:31:53 UTC, Guillaume Piolat wrote: On Tuesday, 29 May 2018 at 05:11:27 UTC, Dmitry Olshansky wrote: D is probably at the edge of what I can tollerate complexity-wise. And we’ll get to simplify a few things soon I believe. Within D, there is a bit smaller and cleaner language struggling to get out! Seems like it could be broken into two languages, one a garbage collected object-oriented language. The other, C with metaprogramming and other "betterC" type stuff. I don't think it's difficult to do that yourself. There's no need to have a formal split. One example is that it's really nice to have the GC available for part of the program and avoid it for another part. @nogc gives you a guarantee. Different variants of the language are a special case of this that is equivalent to annotating the entire program to restrict behavior. That's rarely desirable.
Re: Clash When Using Function as Template Value-Parameters?
On Tuesday, 29 May 2018 at 12:58:20 UTC, Yuxuan Shui wrote:
I believe that is the case. Normally that will be fine, because
you can't modify them. Type-deduced lambda is a very special
case, as in their parameter types are deduced on first use, so
in a sense, they are "modified" by the first instantiation.
BTW, I can't find the documentation about defining lambda with
their parameter types omitted anywhere.
I tried this again, this time completely ignoring lambdas and
completely specifying the desired type like so:
final class BTree(
ValueT,
KeyT = ValueT,
const(KeyT) function(ValueT) nothrow pure @nogc KeyF =
function KeyT(ValueT a) { return a; }) {
KeyT getKey(ValueT val) {
return KeyF(val);
}
}
But unfortunately, the following code still produces an error:
void main()
{
auto btree1 = new BTree!(char);
auto btree2 = new BTree!(int); // The error is on this line.
}
onlineapp.d(17): Error: template instance `BTree!int` does not
match template declaration `BTree(ValueT, KeyT = ValueT,
const(char) function(char) pure nothrow @nogc KeyF = function
KeyT(ValueT a)
{
return a;
}
)`
I think at this point this may be a bug in the compiler. What do
you think?
Re: How do I break from loop when using parallel()?
On Mon, 2018-05-28 at 21:04 +, Dr.No via Digitalmars-d-learn wrote:
> import std.parallelism : parallel;
> foreach(t; parallel(arr))
> {
> if(!doSomething(t)) {
> return false;
> }
> }
>
> It reuturns the run time error:
>
> > std.parallelism.ParallelForeachError@(0): Cannot break from a
> > parallel foreach loop using break, return, labeled
> > break/continue or goto statements.
>
> What's the proper way to break from loop?
It isn't a loop, it is a task scatter/gather, with each task running to
completion independent of all other tasks. Thus the concept of
break/return doesn't exist.
It could be argued that this is a bad use of foreach, but it is what it
is.
--
Russel.
===
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part
Re: Build interface from abstract class
On Monday, 28 May 2018 at 22:15:40 UTC, arturg wrote:
this might help you,
https://dpaste.dzfl.pl/2cf844a11e3f
you can use them to generate the functions as strings.
Thanks,
So, the problem I'm having is that I cannot use the generated
interface for the abstract class because the abstract class needs
the interface defined. I need to be able to forward define the
interface then extend it.
D doesn't like this
main.d(10): Error: interface `main.B` base `A` is forward
referenced
interface A;
mixin(Generate!(B,A));
interface B : A
{
}
abstract class C : B
{
}
I could see that D wants A so it can have the complete picture
for B, but this is one of those problems where it shouldn't
matter.
This requires hoops and ultimately does not solve the problem.
Any time A is used it will be treated as undefined by the
compiler and throw an error.
For example:
pragma(msg, InterfaceFromClass!(C, "A"));
mixin(InterfaceFromClass!(C, "A"));
interface B : A
{
}
abstract class C
{
@("InterfaceMembers")
{
int xe = 3;
@(3) void foo() { }
@property int x() { return 3; };
B bar() { return null; }
}
}
abstract class D : C, B
{
}
fails because C.bar returns a B, which has not yet fully been
defined because A has not yet fully been defined. Now, if I could
just get the function signature without using the type system,
this wouldn't be a problem. I don't really care if B is defined
yet, I just need to know it's name. I guess D tries to enforce
consistency at all steps, which is a problem here because C uses
a yet to be defined type, even though it will be defined soon
enough without problems.
One of the main culprits is isCallable which is what errors out
because of the yet to be defined B.
So, I guess some other method will have to work.
Re: SecureD Futures (v2.0)
On 5/29/2018 1:57 AM, Adam Wilson via Digitalmars-d wrote: One of the pillars of SecureD is that ONLY safe, well-known, algorithms are presented. If reasonable we will only present one algorithm for a specific purpose. If there is a good reason to add more than one algorithm, we will. One of the pillars of crypto is that eventually a problem will be found with every algorithm, it's just a matter of time. So, having just one available means that eventually the library will be horribly broken. The corollary here is that having a fallback is pretty essential.
[Issue 18905] [Reg 2.079] C++ classes can no longer be used with -betterC
https://issues.dlang.org/show_bug.cgi?id=18905 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18905] [Reg 2.079] C++ classes can no longer be used with -betterC
https://issues.dlang.org/show_bug.cgi?id=18905 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/a0dc0520d0a126291a51e28b234f41f9d9f6f678 fix Issue 18905 - [Reg 2.079] C++ classes can no longer be used with -betterC https://github.com/dlang/dmd/commit/3354a6b533a3d0274a737532d2b4382618846d38 Merge pull request #8304 from WalterBright/fix18905 fix Issue 18905 - [Reg 2.079] C++ classes can no longer be used with … merged-on-behalf-of: Walter Bright --
Re: Remember the Vasa! by Bjarne Stroustrup
On Tuesday, 29 May 2018 at 11:31:53 UTC, Guillaume Piolat wrote: On Tuesday, 29 May 2018 at 05:11:27 UTC, Dmitry Olshansky wrote: D is probably at the edge of what I can tollerate complexity-wise. And we’ll get to simplify a few things soon I believe. Within D, there is a bit smaller and cleaner language struggling to get out! Seems like it could be broken into two languages, one a garbage collected object-oriented language. The other, C with metaprogramming and other "betterC" type stuff.
[Issue 6063] Make cases where hiddenfuncerror would be thrown an error without -w
https://issues.dlang.org/show_bug.cgi?id=6063 Steven Schveighoffer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Steven Schveighoffer --- Here is a modernized link (Took me a bit to find this, as it seems the webnews link isn't working any more, it just shows the PHP script): https://forum.dlang.org/post/irokdr$24ci$1...@digitalmars.com That shows the example that Andrei tested. Compiling this now gives a compile-time error: https://run.dlang.io/is/ifJPgU Note that even back to 2.060, it was a compiler error with a deprecation. I also tested a local example that I had to test the same thing. It fails now, builds with 2.050 and throws the error. So I think this is fixed as of some version prior to 2.060. --
Re: Remember the Vasa! by Bjarne Stroustrup
On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote: A cautionary tale we should all keep in mind. http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/ https://news.ycombinator.com/item?id=17172057 Hmm reminds me of this Scott Meyers talk: https://www.youtube.com/watch?v=ltCgzYcpFUI=youtu.be
Re: Remember the Vasa! by Bjarne Stroustrup
On Tuesday, 29 May 2018 at 11:31:53 UTC, Guillaume Piolat wrote: On Tuesday, 29 May 2018 at 05:11:27 UTC, Dmitry Olshansky wrote: D is probably at the edge of what I can tollerate complexity-wise. And we’ll get to simplify a few things soon I believe. What are the things that you think will be simplified? I thought that D had some of the same issues about breaking backward compatibility that C++ had. Within D, there is a bit smaller and cleaner language struggling to get out! Ha, one of my favorite Stroustrup quotes about C++! One of the reasons I like the betterC switch is that it does simplify the language, perhaps too much, but preserves some of the best parts of D, like metaprogramming and modules.
[Issue 6589] is(int*==int*); and template X(T : int*=int*) should compile
https://issues.dlang.org/show_bug.cgi?id=6589 Dmitry Olshansky changed: What|Removed |Added Keywords||bootcamp --
[Issue 6589] is(int*==int*); and template X(T : int*=int*) should compile
https://issues.dlang.org/show_bug.cgi?id=6589 Dmitry Olshansky changed: What|Removed |Added CC||dmitry.o...@gmail.com --
[Issue 6447] iota(BigInt) too
https://issues.dlang.org/show_bug.cgi?id=6447 Dmitry Olshansky changed: What|Removed |Added Status|NEW |RESOLVED CC||dmitry.o...@gmail.com Resolution|--- |WORKSFORME --- Comment #16 from Dmitry Olshansky --- Works now. --
[Issue 18813] fromStringz should work with char, wchar and dchar
https://issues.dlang.org/show_bug.cgi?id=18813 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18813] fromStringz should work with char, wchar and dchar
https://issues.dlang.org/show_bug.cgi?id=18813 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/20efd72da7bc3a95b44e67807ad15b1ceb332114 fix Issue 18813 add wchar/dchar fromStringz template function This adds a wide string template functions to complement the existing fromStringz function. --
[Issue 6421] Require initialization of static arrays with array literals not to allocate
https://issues.dlang.org/show_bug.cgi?id=6421 Dmitry Olshansky changed: What|Removed |Added Keywords||performance CC||dmitry.o...@gmail.com --
[Issue 6350] Const array static usage optimization
https://issues.dlang.org/show_bug.cgi?id=6350 anonymous4 changed: What|Removed |Added OS|Windows |All --
[Issue 6371] Small improvements to aid auto-building DMD from git
https://issues.dlang.org/show_bug.cgi?id=6371 Dmitry Olshansky changed: What|Removed |Added Status|NEW |RESOLVED CC||dmitry.o...@gmail.com Resolution|--- |WORKSFORME --- Comment #5 from Dmitry Olshansky --- Far as I can tell sc.ini and dmd.conf are not required anymore to build. --
[Issue 18907] Support cross-compiling
https://issues.dlang.org/show_bug.cgi?id=18907 Andrea Fontana changed: What|Removed |Added CC||trik...@gmail.com --- Comment #4 from Andrea Fontana --- I always hoped this. And I hope someone will patch dmd. --
Re: Clash When Using Function as Template Value-Parameters?
On Tuesday, 29 May 2018 at 12:37:04 UTC, Vijay Nayar wrote: On Tuesday, 29 May 2018 at 11:36:11 UTC, Yuxuan Shui wrote: No, wait a second. (a)=>a is in default argument list, so it is in the global scope. And it was instantiated when you instantiate BTree with char. Could you explain that part a bit for me? Yes, (a) => a is a default value, but when you say it is in the global scope, are you saying that a single object "(a) => a" is created in the global scope and not created for each template argument list, e.g. "BTree!int" and "BTree!char"? I actually do not know in what scope such objects would be created, I had assumed it was per template-parameter list, but are you saying this is not the case? I believe that is the case. Normally that will be fine, because you can't modify them. Type-deduced lambda is a very special case, as in their parameter types are deduced on first use, so in a sense, they are "modified" by the first instantiation. BTW, I can't find the documentation about defining lambda with their parameter types omitted anywhere.
[Issue 18786] AV program detects malware in windows download of DMD
https://issues.dlang.org/show_bug.cgi?id=18786
--- Comment #9 from anonymous4 ---
(In reply to David M from comment #8)
> * I, as a new D user, do not have the knowledge and background to state to a
> vendor that it is truly virus free. If the runtime causes problems, I can't
> explain what and why. You can't ask I report it, because you're asking me
> to make statements to the vendor that I don't have the knowledge to back up.
> ("Can you take this package on board the airplane for me? No bombs,
> promise." Later, at security, "No, no bombs. Oh, no, it's not my package.
> No, I don't know what's in it. It's locked, I don't have the key. But no
> bombs. I'm sure.")
Don't worry, they won't believe you blindly :) virus analysts will check if
it's truly clean. You only need to report, the rest will be done for you, no
expertise is required from you at all.
> * This impacts your users. Currently, no-one on Windows 10 can install D
> because the installer is captured by Windows Defender.
I just downloaded dmd-2.080.0.exe and windows defender doesn't detect it as a
virus.
--
Re: Clash When Using Function as Template Value-Parameters?
On Tuesday, 29 May 2018 at 11:36:11 UTC, Yuxuan Shui wrote: No, wait a second. (a)=>a is in default argument list, so it is in the global scope. And it was instantiated when you instantiate BTree with char. Could you explain that part a bit for me? Yes, (a) => a is a default value, but when you say it is in the global scope, are you saying that a single object "(a) => a" is created in the global scope and not created for each template argument list, e.g. "BTree!int" and "BTree!char"? I actually do not know in what scope such objects would be created, I had assumed it was per template-parameter list, but are you saying this is not the case?
[Issue 6350] Const array static usage optimization
https://issues.dlang.org/show_bug.cgi?id=6350 Dmitry Olshansky changed: What|Removed |Added Keywords||performance CC||dmitry.o...@gmail.com --
[Issue 18884] getSymbolsByUDA fails on AliasSeq members
https://issues.dlang.org/show_bug.cgi?id=18884 --- Comment #3 from Simen Kjaeraas --- (In reply to Walter Bright from comment #2) > This has been pulled. Has this issue been resolved? Should be. The unittest in the PR is taken almost verbatim from here. Since it's a regression, it targets stable, and the bot only auto-closes issues when it makes its way to master, as I understand it. --
[Issue 6226] Switch with impossible cases
https://issues.dlang.org/show_bug.cgi?id=6226 Dmitry Olshansky changed: What|Removed |Added CC||dmitry.o...@gmail.com --
[Issue 6092] Can't cast primitive to same-sized static array
https://issues.dlang.org/show_bug.cgi?id=6092 Dmitry Olshansky changed: What|Removed |Added CC||dmitry.o...@gmail.com --
[Issue 6082] Constructors of templated types should be callable via IFTI
https://issues.dlang.org/show_bug.cgi?id=6082 Dmitry Olshansky changed: What|Removed |Added CC||dmitry.o...@gmail.com --
[Issue 6063] Make cases where hiddenfuncerror would be thrown an error without -w
https://issues.dlang.org/show_bug.cgi?id=6063 Dmitry Olshansky changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #2 from Dmitry Olshansky --- Steve, any chance to dig up that example code? --
[Issue 6060] Refuse wrong final switch
https://issues.dlang.org/show_bug.cgi?id=6060 Dmitry Olshansky changed: What|Removed |Added Keywords||bootcamp CC||dmitry.o...@gmail.com --
Re: Clash When Using Function as Template Value-Parameters?
On Tuesday, 29 May 2018 at 11:34:03 UTC, Yuxuan Shui wrote: On Saturday, 26 May 2018 at 11:56:30 UTC, Vijay Nayar wrote: I've been experimenting with code that uses std.functional : binaryFun and unaryFun, but I have found that using these methods makes it impossible to add function attributes like @safe, @nogc, pure, and nothrow, because no guarantee can be made about the functions created via a stream. For example, if you expect a comparator function like "a == b", someone can pass in "a.data--" instead. [...] This is probably a bug. BTree!char.lambda is clearly not the same as BTree!int.lambda, but the compiler seems to disagree? No, wait a second. (a)=>a is in default argument list, so it is in the global scope. And it was instantiated when you instantiate BTree with char.
Re: Clash When Using Function as Template Value-Parameters?
On Saturday, 26 May 2018 at 11:56:30 UTC, Vijay Nayar wrote: I've been experimenting with code that uses std.functional : binaryFun and unaryFun, but I have found that using these methods makes it impossible to add function attributes like @safe, @nogc, pure, and nothrow, because no guarantee can be made about the functions created via a stream. For example, if you expect a comparator function like "a == b", someone can pass in "a.data--" instead. [...] This is probably a bug. BTree!char.lambda is clearly not the same as BTree!int.lambda, but the compiler seems to disagree?
Re: Remember the Vasa! by Bjarne Stroustrup
On Tuesday, 29 May 2018 at 05:11:27 UTC, Dmitry Olshansky wrote: D is probably at the edge of what I can tollerate complexity-wise. And we’ll get to simplify a few things soon I believe. Within D, there is a bit smaller and cleaner language struggling to get out!
[Issue 18837] MMFile should have opDollar
https://issues.dlang.org/show_bug.cgi?id=18837 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18837] MMFile should have opDollar
https://issues.dlang.org/show_bug.cgi?id=18837 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/ba8134876b17550933e7212c526fa517eb8233fd [trivial] fix issue 18837 - MMFile should have opDollar https://github.com/dlang/phobos/commit/0df8d334a538e499ee30fbb57e7a0c46f3e1b0f2 Merge pull request #6521 from BBasile/issue-18837 [trivial] fix issue 18837 - MMFile should have opDollar merged-on-behalf-of: Nathan Sashihara --
OT: today in reddit ProgrammerHumor - The Evolution of C
https://www.reddit.com/r/ProgrammerHumor/comments/8mtfy5/the_evolution_of_c/
Re: SecureD Futures (v2.0)
On 05/28/2018 04:02 PM, sarn wrote: On Monday, 28 May 2018 at 07:52:43 UTC, Adam Wilson wrote: I understand that. Sorry, not for nothing, but you obviously don't. For starters, if you were familiar with the key derivation tools available 24hrs ago, you wouldn't have come up with PBKDF2 on PBKDF2. I suggest slowing down a little, and asking people on a crypto forum if you're still not sure. If you explain your problem from the start, they might even have some better ideas. When that RFC (correctly) recommends using a salt, it's talking about HKDF-Extract, which is a tool for taking a large amount of mostly-random data and turning it into an appropriate KDK. That's not the problem you have here. The problem you have is generating keys for different purposes from a KDK. That's a problem HKDF-Expand addresses, and it doesn't use a salt. Let me ask the question a different way. What is the reason NOT to use 2 different salts for the MAC and KEY generation steps? You might choose to not use extra salts for the same reason you've already chosen to not encrypt three times, or add extra HMACs for each individual block of ciphertext: it's not solving any problems. Ok, but I am not harming anything either. I asked specifically what would be reasons not to do something, you replied with "it's not solving any problems". In a technical sense you are correct. I am not solving any problems. However. I am not creating any either. Adding a salt to an HKDF does not hurt anything. Ever. As to the PBKDF2 comment. I'll concede that I am not perfect. Which is why I asked for input and I obviously "slowed down" enough to bother to ask. And when my mistake was pointed out I corrected it without further comment. We make all make mistakes sometimes, and cryptography is much harder than most to get right. So when we aren't sure we ask. And my statement was posed as a question. I was inviting feedback. One of the pillars of SecureD is that ONLY safe, well-known, algorithms are presented. If reasonable we will only present one algorithm for a specific purpose. If there is a good reason to add more than one algorithm, we will. For example, I am well aware of the BCrypt/SCrypt family as well as Argon2. At this point Argon2 appears to be the heir-apparent. Sadly, Argon2 is so new that neither Botan or OpenSSL implement it. So that one is ruled out for practical purposes, at least for now. I would also like to point out the OpenSSL will never implement BCrypt, but does implement SCrypt, and an Argon2 implementation is an open question due to it's use of threads. It turns out the key-stretching field is very active right now, and precisely what will become the de-facto standard is impossible to say. I don't feel comfortable trying to pick a winner to implement. For the moment, PBKDF2 is stable, broadly implemented, and most importantly, well-understood. SecureD v2 will default to 1,000,000 iterations which yields roughly 650ms on an Intel 8700K. As older hardware is unlikely to be as fast, times of over one second could be seen in production while still providing some buffer against the future. That said the default PBKDF2 method will be tune-able. I have long hoped for a reasonable replacement for PBKDF2, and with all the recent activity it is likely that something will shake out. But the attacks against Argon2 coming out so soon after it's release do not bode well for it in the future. And SCrypt requiring 16MB of RAM to achieve BCrypt's security makes it challenging to recommend for use on servers, especially in today's cloud environments where memory costs money. I know PBKDF2 is the conservative choice, but SecureD is all about conservative. For the moment, there aren't any great options, so conservative wins by default. SCrypt Memory Math: Assuming a 4GB VM in the cloud and we are willing to dedicate 1GB to SCrypt per second at BCrypt equivalent security. 1024/16=64 That's 64 connections per second, that is ... not great. And dedicating 1/4 of your systems RAM just for password hashing is being very generous. You're not going to see that in production because it is terribly expensive. As PBKDF2 and SCrypt are the only key-stretching algorithms available in both OpenSSL and Botan, and I cannot recommend SCrypt for cloud/server scenarios. PBKDF2 it is. To be perfectly honest, key-stretching is a mitigation. Weak passwords will be easily guessed no matter what algorithm is used. The real fix is to force better passwords. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Tiny D suitable for embedded JIT
On Monday, 28 May 2018 at 19:24:58 UTC, MrSmith wrote: On Wednesday, 23 May 2018 at 18:49:05 UTC, Dibyendu Majumdar wrote: [...] You may like the project of a compiler I am doing https://github.com/MrSmith33/tiny_jit TLDR: fully in D. No dependencies. Currently for amd64 + Win64 calling convension. P.S. Sorry for late response. I read your comment, I have a solution for you can take A help of https://dellsupports.org/ to solve the problem.
Re: Native PDB Error
On Tuesday, 29 May 2018 at 07:53:49 UTC, rikki cattermole wrote: On 29/05/2018 7:47 PM, Begah wrote: I have recently reinstalled a fresh version of Windows 10. I installed DMD 1.9.0 and compiled my code ( that was compiling before reinstalling Windows ). What? That is definitely not a valid dmd version for D2. Sorry, that was the dub version. I ment 2.080.0
Re: Native PDB Error
On 29/05/2018 7:47 PM, Begah wrote: I have recently reinstalled a fresh version of Windows 10. I installed DMD 1.9.0 and compiled my code ( that was compiling before reinstalling Windows ). What? That is definitely not a valid dmd version for D2.
Re: Remember the Vasa! by Bjarne Stroustrup
On Tuesday, 29 May 2018 at 07:25:39 UTC, Stefan Koch wrote: As a a compiler developer, I can guarantee that at some point you _need_ to understand all of the language. If you don't you will mis-compile code. Also the more complex the language gets the more special-case handling needs to be added to the compiler making it slower and more brittle. Unconstrained complexity growth is a pretty scary thing. Could this be more a problem of compiler 'architecture'? Or perhaps hardware architecture? Can we design better architecture (at all levels) to better accomodate inevitable change? Could it be a problem of not having enough compiler writers - where each knows some part(s), but together they know all the parts? Collaboration is good way to manage complexity. A compiler writer insisting they must know it all, (while understandable) is an unatural constraint. You'll end up like Scott Meyers - decades of effort learning, but can never understand it, because change is a moving target.
Native PDB Error
I have recently reinstalled a fresh version of Windows 10. I
installed DMD 1.9.0 and compiled my code ( that was compiling
before reinstalling Windows ).
I get this error at the linking phase :
Native PDB Error: The entry already exists. The specified module
already exists
I made a simplified project that gets the same error :
import imageformats;
import derelict.glfw3;
void main() {
IFImage i0;
}
and dub.json :
"dependencies": {
"derelict-glfw3": "4.0.0-beta.1",
"imageformats": "~>7.0.0"
}
Compiling for 32-bit works.
Compiling for 64-bit gives that error : dub --arch=x86_64
Changing imageformats version to 5.2.0 compiles but any higher
doesn't.
I tried compiling the code with and without admin privileges but
it doesn't do anything.
I know that PDB is used for debugging but I don't understand this
error.
Any ideas?
Re: Remember the Vasa! by Bjarne Stroustrup
On Tuesday, 29 May 2018 at 05:47:32 UTC, Let-It-Go wrote: On Tuesday, 29 May 2018 at 05:11:27 UTC, Dmitry Olshansky wrote: D is probably at the edge of what I can tollerate complexity-wise. And we’ll get to simplify a few things soon I believe. There is the core of the problem. Because you want to understand it all, therefore it must be simplified. This is not something that nature imposes on itself. It's entirely a product of the human mind. Why constrain ourselves in this way? Let it go, and let it grow ;-) As a a compiler developer, I can guarantee that at some point you _need_ to understand all of the language. If you don't you will mis-compile code. Also the more complex the language gets the more special-case handling needs to be added to the compiler making it slower and more brittle. Unconstrained complexity growth is a pretty scary thing.
