Vibed + OpenSSL on Windows 10?
Does anybody have success with using vibed 0.8.4 with OpenSSL 1.0/1.1 on Windows? I tried all possible solutions without any result. I am getting linking error: Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html C:\Users\bubnenkov\AppData\Local\dub\packages\vibe-d-0.8.4\vibe-d\tls\.dub\build\openssl-release-windows-x86-dmd_2084-F1EDC8E792A20905C7802AF7FD58830B\vibe-d_tls.lib(openssl) Error 42: Symbol Undefined _TLS_server_method C:\Users\bubnenkov\AppData\Local\dub\packages\vibe-d-0.8.4\vibe-d\tls\.dub\build\openssl-release-windows-x86-dmd_2084-F1EDC8E792A20905C7802AF7FD58830B\vibe-d_tls.lib(openssl) Error 42: Symbol Undefined _TLS_client_method C:\Users\bubnenkov\AppData\Local\dub\packages\vibe-d-0.8.4\vibe-d\tls\.dub\build\openssl-release-windows-x86-dmd_2084-F1EDC8E792A20905C7802AF7FD58830B\vibe-d_tls.lib(openssl) Error 42: Symbol Undefined _BN_get_rfc3526_prime_2048 C:\Users\bubnenkov\AppData\Local\dub\packages\vibe-d-0.8.4\vibe-d\tls\.dub\build\openssl-release-windows-x86-dmd_2084-F1EDC8E792A20905C7802AF7FD58830B\vibe-d_tls.lib(openssl) Error 42: Symbol Undefined _OPENSSL_init_ssl Error: linker exited with status 4
Re: Implement Interface Using Super
On Monday, 28 January 2019 at 22:17:56 UTC, Steven Schveighoffer wrote: On 1/28/19 3:28 PM, Jonathan Levi wrote: On Sunday, 27 January 2019 at 09:31:46 UTC, bauss wrote: On Sunday, 27 January 2019 at 05:37:57 UTC, Jonathan Levi wrote: This works in LDC *but not* DMD? . . . Is this a bug in DMD *or* in LDC? There is no bug here. So... LDC is the one that is bugged? Yeah, that's odd. It should be the same result, as they both have the same semantics for the front end. I'll defer to an LDC developer to answer that, but in truth, it really should be the way LDC implements it, even if that's not how the language spec is. I think it would have been nice to have a way of explicitly use the super method to implement an interface without having to rewrite the whole signature. I thought I remember seeing a way once, but I must have been dreaming. I agree. BTW, the typeof(super) requirement is super-annoying. alias x = super.x; is clear, I don't see why we need to specify typeof(super) in this context at least. -Steev It's because aliases do not support context pointers, I'm pretty sure.
Re: Implement Interface Using Super
On 1/28/19 3:28 PM, Jonathan Levi wrote: On Sunday, 27 January 2019 at 09:31:46 UTC, bauss wrote: On Sunday, 27 January 2019 at 05:37:57 UTC, Jonathan Levi wrote: This works in LDC *but not* DMD? . . . Is this a bug in DMD *or* in LDC? There is no bug here. So... LDC is the one that is bugged? Yeah, that's odd. It should be the same result, as they both have the same semantics for the front end. I'll defer to an LDC developer to answer that, but in truth, it really should be the way LDC implements it, even if that's not how the language spec is. I think it would have been nice to have a way of explicitly use the super method to implement an interface without having to rewrite the whole signature. I thought I remember seeing a way once, but I must have been dreaming. I agree. BTW, the typeof(super) requirement is super-annoying. alias x = super.x; is clear, I don't see why we need to specify typeof(super) in this context at least. -Steev
Re: Should I prefix package names with the name of my program?
On 1/28/19 4:57 PM, Steven Schveighoffer wrote:
On 1/28/19 3:16 PM, H. S. Teoh wrote:
On Mon, Jan 28, 2019 at 02:54:23PM -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:
On 1/28/19 11:59 AM, Victor Porton wrote:
Should I prefix all module names with `xmlboiler.` (where XML Boiler
is the name of my program). These packages are expected to be used
internally by my program, not as an exported API (however there are
some little chances that in the future I will make a public API)
I use a package nearly every time because if you don't, you run into
weird quirks of the language for top-level modules.
Really? Such as? I've never heard of said quirks.
I'm trying to remember, but there are definitely conflicts with
top-level modules that do not happen when packages are involved. Someone
help me out here...
OK, so it's because top-level packages and modules imported are put into
the namespace. But modules under packages are not.
So for instance, if you have:
module a;
void a() {}
import a;
void main()
{
a(); // error can't call module a
}
whereas if a is changed to:
module pkg.a;
void a() {}
and the import changed to import pkg.a; then it works.
But this doesn't solve the problem of having a simple library/app with a
simple module name. What do you put it under? It can't be a.a, because
that doesn't help.
It really is a quirk of D that I don't like, the top level packages
should not conflict with other symbols in most cases.
-Steve
Re: Should I prefix package names with the name of my program?
On 1/28/19 3:16 PM, H. S. Teoh wrote: On Mon, Jan 28, 2019 at 02:54:23PM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote: On 1/28/19 11:59 AM, Victor Porton wrote: Should I prefix all module names with `xmlboiler.` (where XML Boiler is the name of my program). These packages are expected to be used internally by my program, not as an exported API (however there are some little chances that in the future I will make a public API) I use a package nearly every time because if you don't, you run into weird quirks of the language for top-level modules. Really? Such as? I've never heard of said quirks. I'm trying to remember, but there are definitely conflicts with top-level modules that do not happen when packages are involved. Someone help me out here... -Steve
Re: Should I prefix package names with the name of my program?
On Monday, 28 January 2019 at 16:59:22 UTC, Victor Porton wrote: Should I prefix all module names with `xmlboiler.` Yes. All module names should have at least two parts. If you don't, you will regret it later when you have to rename or see conflicts with other libraries.
Re: Implement Interface Using Super
On Sunday, 27 January 2019 at 09:31:46 UTC, bauss wrote: On Sunday, 27 January 2019 at 05:37:57 UTC, Jonathan Levi wrote: This works in LDC *but not* DMD? . . . Is this a bug in DMD *or* in LDC? There is no bug here. So... LDC is the one that is bugged? I think it would have been nice to have a way of explicitly use the super method to implement an interface without having to rewrite the whole signature. I thought I remember seeing a way once, but I must have been dreaming. Thanks Bauss. Jonathan
Re: Should I prefix package names with the name of my program?
On Mon, Jan 28, 2019 at 02:54:23PM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote: > On 1/28/19 11:59 AM, Victor Porton wrote: > > Should I prefix all module names with `xmlboiler.` (where XML Boiler > > is the name of my program). These packages are expected to be used > > internally by my program, not as an exported API (however there are > > some little chances that in the future I will make a public API) > > I use a package nearly every time because if you don't, you run into > weird quirks of the language for top-level modules. Really? Such as? I've never heard of said quirks. T -- Старый друг лучше новых двух.
Can't build vibed:tls project
If I am specifying (sic! TLS): dependency "vibe-d:tls" version="0.8.4" in my dub.sdl I am getting error when building simple project: module `vibe` is in file 'vibe\vibe.d' which cannot be read But I need to get vibed build with OpenSSL support
Re: Should I prefix package names with the name of my program?
On 1/28/19 11:59 AM, Victor Porton wrote: Should I prefix all module names with `xmlboiler.` (where XML Boiler is the name of my program). These packages are expected to be used internally by my program, not as an exported API (however there are some little chances that in the future I will make a public API) I use a package nearly every time because if you don't, you run into weird quirks of the language for top-level modules. You might use a short name, like `xmlb` or something. -Steve
Re: Why isn't intended class constructor called?
On Monday, 28 January 2019 at 19:24:21 UTC, Zak wrote: On Monday, 28 January 2019 at 19:15:04 UTC, Zak wrote: On Monday, 28 January 2019 at 18:50:18 UTC, Alex wrote: On Monday, 28 January 2019 at 18:34:44 UTC, Zak wrote: [...] As the error states: you are trying to append an int to a string array in the single parameter constructor. [...] Thanks for the response, Alex! But it's not clear to me why the first constructor is called at all. Since I called with two parameters, shouldn't it invoke the second constructor? I think I just realized the answer: this section of code is not called, it just fails compilation since it's not known that runtime doesn't do something like: auto myc = new MyClass!(int, string)([1,2,-3]); which "would" invoke this code block with type string. Yes. :)
Re: Why isn't intended class constructor called?
On Monday, 28 January 2019 at 19:15:04 UTC, Zak wrote: On Monday, 28 January 2019 at 18:50:18 UTC, Alex wrote: On Monday, 28 January 2019 at 18:34:44 UTC, Zak wrote: [...] As the error states: you are trying to append an int to a string array in the single parameter constructor. [...] Thanks for the response, Alex! But it's not clear to me why the first constructor is called at all. Since I called with two parameters, shouldn't it invoke the second constructor? I think I just realized the answer: this section of code is not called, it just fails compilation since it's not known that runtime doesn't do something like: auto myc = new MyClass!(int, string)([1,2,-3]); which "would" invoke this code block with type string.
Re: Why isn't intended class constructor called?
On Monday, 28 January 2019 at 18:50:18 UTC, Alex wrote: On Monday, 28 January 2019 at 18:34:44 UTC, Zak wrote: [...] As the error states: you are trying to append an int to a string array in the single parameter constructor. [...] Thanks for the response, Alex! But it's not clear to me why the first constructor is called at all. Since I called with two parameters, shouldn't it invoke the second constructor?
Re: Why isn't intended class constructor called?
On Monday, 28 January 2019 at 18:34:44 UTC, Zak wrote:
I have defined a class that's meant to represent a data series,
which has an index and a set of values. Sometimes the user
wants to specify a particular index of custom type, other times
they don't care and we want to default to an array of
contiguous "int" starting from 0.
I have attempted to create a class where the index type is a
parameter, but defaults to int. I also tried to create two
constructors: one for if the index values are not specified
(in which the constructor makes the array of ints); and one
where the user passes in a literal of values that match the
specified type.
However, it seems that only the first constructor is getting
called, even though I am passing in two parameters instead of
one. Why isn't the call matching the second constructor and
behaving as intended?
import std.stdio;
class MyClass(T, U = int) {
T[] values;
U[] index;
this(T[] values) {
this.values = values;
// Default index of contiguous ints
for (int i; i < values.length; i++) {
index ~= i;
}
}
this(T[] values, U[] index) {
this.values = values;
this.index = index;
}
}
void main() {
auto myc1 = new MyClass!(int)([1,2,-3]);
auto myc2 = new MyClass!(int, string)([1,2,-3], ["a", "b",
"c"]); // Error: cannot append type int to type string[]
}
As the error states:
you are trying to append an int to a string array in the single
parameter constructor.
This would work:
´´´
import std.stdio;
class MyClass(T, U = int) {
T[] values;
U[] index;
this(T[] values) {
this.values = values;
// Default index of contiguous ints
static if(is(U == int))
{
for (int i; i < values.length; i++) {
index ~= i;
}
}
}
this(T[] values, U[] index) {
this.values = values;
this.index = index;
}
}
void main() {
auto myc1 = new MyClass!(int)([1,2,-3]);
auto myc2 = new MyClass!(int, string)([1,2,-3], ["a", "b",
"c"]); // Error: cannot append type int to type string[]
}
´´´
If design matters, I would even to expand the static if above the
constructor. So, the single parameter constructor would exist iff
is(U == int)
´´´
static if(is(U == int))
{
this(T[] values) {
this.values = values;
// Default index of contiguous ints
for (int i; i < values.length; i++) {
index ~= i;
}
}
}
´´´
Why isn't intended class constructor called?
I have defined a class that's meant to represent a data series,
which has an index and a set of values. Sometimes the user wants
to specify a particular index of custom type, other times they
don't care and we want to default to an array of contiguous "int"
starting from 0.
I have attempted to create a class where the index type is a
parameter, but defaults to int. I also tried to create two
constructors: one for if the index values are not specified (in
which the constructor makes the array of ints); and one where the
user passes in a literal of values that match the specified type.
However, it seems that only the first constructor is getting
called, even though I am passing in two parameters instead of
one. Why isn't the call matching the second constructor and
behaving as intended?
import std.stdio;
class MyClass(T, U = int) {
T[] values;
U[] index;
this(T[] values) {
this.values = values;
// Default index of contiguous ints
for (int i; i < values.length; i++) {
index ~= i;
}
}
this(T[] values, U[] index) {
this.values = values;
this.index = index;
}
}
void main() {
auto myc1 = new MyClass!(int)([1,2,-3]);
auto myc2 = new MyClass!(int, string)([1,2,-3], ["a", "b",
"c"]); // Error: cannot append type int to type string[]
}
Re: Should I prefix package names with the name of my program?
On Mon, 28 Jan 2019 16:59:22 +, Victor Porton wrote: > Should I prefix all module names with `xmlboiler.` (where XML Boiler is > the name of my program). These packages are expected to be used > internally by my program, not as an exported API (however there are some > little chances that in the future I will make a public API) You do you. I put all my source files inside a package unless it's a one- file project mainly so that I can sort my import directives and have them organized nicely. But if you don't want to have to type `xmlboiler` five- ish times per source file, you can skip it.
Re: Ordered set container?
On Mon, Jan 28, 2019 at 05:18:52PM +, Victor Porton via Digitalmars-d-learn wrote: > I want "ordered set" container (like list or vector but with the > warranty of no duplicate elements). > > Which type can I use? Try std.container.rbtree.RedBlackTree. T -- That's not a bug; that's a feature!
Re: Ordered set container?
On Mon, 28 Jan 2019 17:18:52 +, Victor Porton wrote: > I want "ordered set" container (like list or vector but with the > warranty of no duplicate elements). > > Which type can I use? std.container.rbtree It has options to preserve or squash duplicates.
Re: Should I prefix package names with the name of my program?
On Mon, Jan 28, 2019 at 04:59:22PM +, Victor Porton via Digitalmars-d-learn wrote: > Should I prefix all module names with `xmlboiler.` (where XML Boiler > is the name of my program). These packages are expected to be used > internally by my program, not as an exported API (however there are > some little chances that in the future I will make a public API) I won't pretend to speak for anyone else, but personally, I don't even bother with packages until my code has grown past a certain size. It's just useless cruft and needless complexity for small to medium sized projects. It's only when you're planning to export a public API, or when your code has grown past a certain size, that it becomes useful to segregate the code into different packages. So IMO you don't need to bother. You can always refactor the code later to have a package name when you make a public API. T -- Famous last words: I wonder what will happen if I do *this*...
Ordered set container?
I want "ordered set" container (like list or vector but with the warranty of no duplicate elements). Which type can I use?
Should I prefix package names with the name of my program?
Should I prefix all module names with `xmlboiler.` (where XML Boiler is the name of my program). These packages are expected to be used internally by my program, not as an exported API (however there are some little chances that in the future I will make a public API)
Re: Is there something special required to use Appender.clear
On 1/28/19 7:39 AM, FeepingCreature wrote: On Friday, 25 January 2019 at 14:33:16 UTC, Steven Schveighoffer wrote: On 1/25/19 3:20 AM, FeepingCreature wrote: On Thursday, 24 January 2019 at 17:49:34 UTC, Ali Çehreli wrote: Aren't the semantics of .clear that it's invalid to access references to .data after calling .clear, period? And if not, then shouldn't they be? Consider if Appender managed its own memory and held on to previously-allocated arrays while you were appending, only to free them on .clear. That seems like something Appender should be allowed to do. If you don't want it, just reinitialize Appender instead of calling .clear. You are advised not to. But it's not unsafe, as the memory is still there. That's stupid. Why would you advise me not to, if there's no problem with it? Either it should be accepted or it should be forbidden, just like warnings. Just like this: int[] arr = [1,2,3,4,5]; auto slice = arr[0 .. 2]; slice.assumeSafeAppend; Now, you can use arr still, it's got elements in it beyond what slice has. You might have things change underneath you without expecting it. That's why it's advised not to do that. But if arr is immutable(int)[], then you are running into undefined behavior, it's a completely different problem. Without good reasons to change, I don't see why it would be accepted. Maybe you can describe your use case? My use case is simply the standard usecase of Appender: I want to build up an array in a way that reduces GC churn. Maybe it's an array of structs that contain const members that I'll serialize to JSON and send on a socket. In that case, I know for a fact that no references will hang around past the serialization. That's what clear _is for._ I don't see why this would be different with const or immutable data; if you hold references past .clear being called you're in trouble *anyways.* Right, this does seem like a big limitation. Keeping with the spirit of how slices don't own the memory in question, Appender is being conservative with what it doesn't know. I wonder if it may be more appropriate to instead of preventing clear() on immutable/const arrays, to make it @system. Or maybe call it something different "dangerousClear" or something ;) There definitely should be some way to fail if clear is called on an array that was passed into the constructor. But I'm still not sure we should allow overwriting immutable memory without a cast, even in @system code. I consider initializing Appender with an array referencing immutable data a borderline error anyways. The entire point of Appender is that it caches capacity data of GC managed memory, which is never immutable. On the first append to an immutable-memory array, it has to reallocate *anyways*. There is no benefit to initializing an Appender with immutable memory over just appending it first thing, unless you never plan to append to it ever. It will inspect the allocated length from the GC if the array is appendable from the beginning. So it's not always going to reallocate. e.g.: string x = "abc".idup; auto app = x.appender; app ~= "xyz"; // does not reallocate. -Steve
Re: Can LDC compile to supported legacy LLVM versions?
On Monday, 28 January 2019 at 13:04:08 UTC, Nicholas Wilson wrote: Do you mean bitcode, LLVM IR or something different? The LDC built against a given version of LLVM can link to bitcode/compile LLMV IR, of that version. Bitcode in this case, but I think your following answer applies to IR/assembly/binary too. Lowest LLVM it can be compiled against is 3.9. LDC's releases are compiled against 7.0.1, but that doesn't stop you downloading a release of the desired LLVM version and compiling LDC against that. All you need is a semi-recent CMake. Just git clone from our github and run cmake, you'll need to provide the location of the llvm-config binary as LLVM_CONFIG but thats it. Okay, that answers it. Thank you.
Re: Can LDC compile to supported legacy LLVM versions?
On Monday, 28 January 2019 at 11:37:56 UTC, Dukc wrote: I have recenty updated my LDC to the most recent version (1.14). The problem is that it compiles to LLVM code version 7.0.1, but I need it to compile to LLVM 6.x.x or LLVM 5.x.x. The last release note said that LLVM versions from 3.something.something are supported, but does this mean only linking to them, or also compiling to them? If it can be done, how? Thanks. Do you mean bitcode, LLVM IR or something different? The LDC built against a given version of LLVM can link to bitcode/compile LLMV IR, of that version. Lowest LLVM it can be compiled against is 3.9. LDC's releases are compiled against 7.0.1, but that doesn't stop you downloading a release of the desired LLVM version and compiling LDC against that. All you need is a semi-recent CMake. Just git clone from our github and run cmake, you'll need to provide the location of the llvm-config binary as LLVM_CONFIG but thats it.
Re: Is there something special required to use Appender.clear
On Friday, 25 January 2019 at 14:33:16 UTC, Steven Schveighoffer wrote: On 1/25/19 3:20 AM, FeepingCreature wrote: On Thursday, 24 January 2019 at 17:49:34 UTC, Ali Çehreli wrote: Aren't the semantics of .clear that it's invalid to access references to .data after calling .clear, period? And if not, then shouldn't they be? Consider if Appender managed its own memory and held on to previously-allocated arrays while you were appending, only to free them on .clear. That seems like something Appender should be allowed to do. If you don't want it, just reinitialize Appender instead of calling .clear. You are advised not to. But it's not unsafe, as the memory is still there. That's stupid. Why would you advise me not to, if there's no problem with it? Either it should be accepted or it should be forbidden, just like warnings. Any reason that the semantics of .clear should be different for a starting array? Anyway if so, I'd prefer to just make that a runtime error. Yes, because Appender doesn't know where that memory comes from. A string could be, for instance, passed to another thread and being used, you wouldn't want to overwrite it. In which case, you can't reuse the Appender and should not call `clear`! It seems like we're gimping functionality of a very basic tool for memory efficiency for the sake of not confusing users. This rarely pays off. Generally speaking, overwriting immutable data is UB in D anyway. Making it a runtime error would be possible, but there has to be a good reason to make it that way. I'm mostly fishing around if anyone has an objection to a PR to change this. Without good reasons to change, I don't see why it would be accepted. Maybe you can describe your use case? My use case is simply the standard usecase of Appender: I want to build up an array in a way that reduces GC churn. Maybe it's an array of structs that contain const members that I'll serialize to JSON and send on a socket. In that case, I know for a fact that no references will hang around past the serialization. That's what clear _is for._ I don't see why this would be different with const or immutable data; if you hold references past .clear being called you're in trouble *anyways.* I consider initializing Appender with an array referencing immutable data a borderline error anyways. The entire point of Appender is that it caches capacity data of GC managed memory, which is never immutable. On the first append to an immutable-memory array, it has to reallocate *anyways*. There is no benefit to initializing an Appender with immutable memory over just appending it first thing, unless you never plan to append to it ever.
Can LDC compile to supported legacy LLVM versions?
I have recenty updated my LDC to the most recent version (1.14). The problem is that it compiles to LLVM code version 7.0.1, but I need it to compile to LLVM 6.x.x or LLVM 5.x.x. The last release note said that LLVM versions from 3.something.something are supported, but does this mean only linking to them, or also compiling to them? If it can be done, how? Thanks.
Re: What is the alternative to the setlocale function of c in D? Thank you.
On Sunday, 27 January 2019 at 16:23:42 UTC, FrankLike wrote:
On Sunday, 27 January 2019 at 10:44:04 UTC, John Chapman wrote:
On Sunday, 27 January 2019 at 06:14:15 UTC, FrankLike wrote:
On Saturday, 26 January 2019 at 09:33:33 UTC, John Chapman
wrote:
What has that code got to do with setting the console's
font? So you need to add more code to accomplish that.
You don't need to set the font to achieve the goal, why not?
This should work:
const(char)[] toCodePage(const(char)[] s, uint codePage = 0) {
import core.sys.windows.winnls, std.utf;
foreach (char c; s) {
if (c >= 0x80) {
auto temp = s.toUTF16z();
char[] result;
if ((result.length = WideCharToMultiByte(codePage, 0,
temp, -1, null, 0, null, null)) != 0)
WideCharToMultiByte(codePage, 0, temp, -1, result.ptr,
cast(int)result.length, null, null);
return result;
}
}
return s;
}
void main() {
import core.sys.windows.wincon, std.stdio;
SetConsoleOutputCP(936); // Simplified Chinese codepage
writeln("字符".toCodePage(936));
}
Yes.
extern(C) int setlocale(int,char*);
static this()
{
import core.stdc.wchar_;
import core.stdc.stdio;
fwide(core.stdc.stdio.stdout,1);
setlocale(0,cast(char*)"china");
}
///
it's simple than yours,and don't need convert every string,why
not work after D2.0.78.1?
I've no idea, sorry. A quick scan of D's changelogs between those
versions doesn't reveal anything relevant. But I wonder how your
code ever worked - on Windows, calling setlocale with "china"
returns null, which means it's not a valid locale, so did nothing.
This does the right thing:
extern(C) int _cwprintf(const(wchar)*, ...);
void main() {
SetConsoleOutputCP(936);
_cwprintf("字符\n");
}
