Re: readonly member (but assignable at constructor time)
On Friday, 27 April 2018 at 02:59:16 UTC, Dr.No wrote:
In C# you can have a readonly member assignable either at
declaration or constructor time, like this:
class C
{
readonly myClass mc;
this()
{
mc = new myClass();
}
void doSomething()
{
mc = new myClass(); // wrong! result in compiler error, mc
is readonly
}
}
Does D have something like this natively or there's a way to do
so with traits/CTFE at runtime?
You can use std.experimenta.typecons.Final.
https://dlang.org/phobos/std_experimental_typecons.html#.Final
Re: E-mail attachment with unwanted characters
On Friday, 27 April 2018 at 17:57:26 UTC, Vino.B wrote:
headers.insert(to!string(Base64.encode(Content)) ~ ".\r\n");
headers.insert("--" ~ boundary ~ ".");
what are those random dots for?
E-mail attachment with unwanted characters
Hi All,
Request your help, the below code is working as expected, but
when I receive the attachment, the attachment contains the
orginal text plus some unwanted characters like below, can
someone help me how to remove these unwanted characters.
Unwanted characters
This is a test documentoÞ óÎ}ã¿xÛ]Zõ§ûwN¶÷ÆÝy·
Code:
import std.base64: Base64;
import std.container.array;
import std.conv : to;
import std.file: read;
import std.format : format;
import std.net.curl;
import std.path : baseName;
import std.uuid: randomUUID;
pragma(lib, "curl");
string Message(string To, string From, string Body, string
Subject, string Filename, ubyte[] Content) {
Array!string headers;
string cid, msg, boundary = randomUUID().toString(), Fname =
baseName(Filename);
const string crlf = "\r\n";
int Size = to!int(getSize(Filename));
headers.insert("From: " ~ From );
headers.insert("To: " ~ To );
headers.insert("Subject: " ~ "Subject" );
headers.insert("MIME-Version: 1.0");
headers.insert(format("Content-Type: multipart/mixed;
boundary=\"%s\"\r\n", boundary));
headers.insert("--" ~ boundary);
headers.insert("Content-Type: text/html; charset=utf-8");
headers.insert(crlf);
headers.insert(Body);
headers.insert(crlf);
headers.insert("--" ~ boundary);
headers.insert("Content-Type: text/plain");
headers ~ ((cid !is null) ? "Content-ID: <" ~ cid ~ ">" : "");
headers.insert("Content-Transfer-Encoding: base64");
headers.insert("Content-Disposition: attachment; filename=\""
~ Fname ~ "\"");
headers.insert(crlf);
headers.insert(to!string(Base64.encode(Content)) ~ ".\r\n");
headers.insert(crlf);
headers.insert("--" ~ boundary ~ ".");
msg.reserve(Size + Body.length);
foreach(header; headers) { msg ~= header ~ "\r\n"; }
if(msg.length > 0) { msg ~= "\r\n";}
return(msg);
}
void main () {
auto Filename = "C:\\Script\\New\\new.txt";
auto Con = cast(ubyte[])read(Filename);
auto smtp = SMTP("smtp://xxx.com");
smtp.mailTo = "u...@ask.com";
smtp.mailFrom = "ad...@ask.com";
smtp.message = Message("u...@ask.com", "ad...@ask.com", "Test",
"TestMail", Filename, Con);
smtp.perform();
}
From,
Vino.B
Re: Get files from directory sorted by name
On Friday, 27 April 2018 at 14:48:00 UTC, Jesse Phillips wrote: On Thursday, 26 April 2018 at 16:59:45 UTC, Dr.No wrote: On Wednesday, 25 April 2018 at 19:25:11 UTC, Jesse Phillips wrote: On Wednesday, 25 April 2018 at 17:34:41 UTC, Dr.No wrote: Is there something implemented already to get the files from directory by name using D or I'm on my own and I have to write it myself? I didn't find how do that with dirEntries() I want to add that sorting can be done, if you just call std.algorithm.sort you'll find that file names with numbers in them will be sorted as a well strings. Newfile1.txt Newfile10.txt Newfile2.txt I've had realized that then implemented natural sort Thats what it was called. Looks like Rosetta Code has an implementation. https://rosettacode.org/wiki/Natural_sorting#D I've tried here and that implmentation doesn't yield same result as Windows Explorer...
Re: Making an .exe that executes source file inside itself.
On Friday, 27 April 2018 at 14:57:34 UTC, BoQsc wrote: On Friday, 27 April 2018 at 04:30:32 UTC, IntegratedDimensions wrote: On Thursday, 26 April 2018 at 06:18:25 UTC, BoQsc wrote: On Wednesday, 25 April 2018 at 20:44:10 UTC, u0_a183 wrote: On Wednesday, 25 April 2018 at 19:54:26 UTC, BoQsc wrote: On Wednesday, 25 April 2018 at 19:43:31 UTC, Jonathan M Davis wrote: [...] Thank you Jonathan for a response. I was aware of this, and it certainly perfectly works where command line/terminal interface is the main tool to control the system, a good example would be linux/gnu distributions and macOS. However in Windows while installing D language, I noticed that .d source file extension is not associated with neither D compiler (dmd.exe) nor D script interpretator (rdmd.exe) So they can't be ran directly by clicking on those, nor they have any icons that show that these source codes are actually executable. This is a huge problem, because people that are not aware of D language migh be harder to understand that source script could be executable, at least - without help from some more experienced user. If the purpose is to make scripts run by clicking them you can assign a file type to .d files. On Windows 10. https://www.digitaltrends.com/computing/how-to-set-default-programs-and-file-types-in-windows-10/ Doing so would make the script engine the default program instead of a text editor so you might not want to. Or maybe assign .dxe and changing the filename before running. Executable has executable file type for a reason - it self-implies that the main function of the file - is to be executed. The problem with making source code files executable is that, source code files, might not always be monolithic executable code, but a part of a bigger interconnected program. That would lead to partily working program execution, and most of the times guess work of whether source code file was supposed to be executed. This is wrong. All code must be included. All library source code is included. If this is infeasible then simply the binaries are included. It would be no different than dynamic linking that already exists. It doesn't create any new problems. Sure certain things would need to be worked out properly to optimize the experience, but that is obvious. One can't make everything perfect though and one shouldn't expect it... The clear alternative would be: .exe file on which, if rightclicked - would open context menu showing posibility of "edit/improve this executable". Which would not create additional problem mentioned above. Yes, all the source code and required source code to make everything work must be included. And where would all the code mentioned before should be stored? It must be stored in a an single self extracting archive, self executing archive, that is self-implying that it is an executable code, which means it can't be .d file extension, but an .exe file extension. (or any other, if anyone come up with more common or self explaining extension name) If we use the same .d file extension on this self-executable, self-extracting archive, it would confused people weather it is executable or some novice programmer's written module/script. No, it would have to be an exe on windows. an exe is basically a self executing container. Almost all exe's only contain the binary but they can contain data. For example, zip files can be saved as self-unzipping executable. It is not a big deal to package the data in the exe and make it all work. Initially, it is not necessary to worry about. What happens is that the actual initial binary that will run will essentially decide what needs to be done and unpack everything and deal with it. You can think of the exe as a small file system that contains all the files necessary and a binary that handles whatever needs to be done which is run by the OS. Several binaries in the file would be things like the IDE/debugger and the compiled source code. If the user just wants to run the app like any normal app then the compiled source code would be extracted either to a temp exe file or to memory and ran. (so the initial process just does some unpacking and passes control) If debugging and modification is to be done then the initial process will have to do more work such as compile the source with debugging symbols, special hooks, and all that. The files would have to be extracted in memory or on disk. The ide would be ran, etc. For example, android apps are actually special zip files. All of this stuff is childs play. The real work is having a proper design that integrates everything well. Nothing would be technically challenging but just a lot of work to get everything done. I do think that apps that were designed to be used this way would need to be structured and designed in a way that makes it conducive to debugging and modifying easily and quickly.
Re: Making an .exe that executes source file inside itself.
On Friday, 27 April 2018 at 04:30:32 UTC, IntegratedDimensions wrote: On Thursday, 26 April 2018 at 06:18:25 UTC, BoQsc wrote: On Wednesday, 25 April 2018 at 20:44:10 UTC, u0_a183 wrote: On Wednesday, 25 April 2018 at 19:54:26 UTC, BoQsc wrote: On Wednesday, 25 April 2018 at 19:43:31 UTC, Jonathan M Davis wrote: [...] Thank you Jonathan for a response. I was aware of this, and it certainly perfectly works where command line/terminal interface is the main tool to control the system, a good example would be linux/gnu distributions and macOS. However in Windows while installing D language, I noticed that .d source file extension is not associated with neither D compiler (dmd.exe) nor D script interpretator (rdmd.exe) So they can't be ran directly by clicking on those, nor they have any icons that show that these source codes are actually executable. This is a huge problem, because people that are not aware of D language migh be harder to understand that source script could be executable, at least - without help from some more experienced user. If the purpose is to make scripts run by clicking them you can assign a file type to .d files. On Windows 10. https://www.digitaltrends.com/computing/how-to-set-default-programs-and-file-types-in-windows-10/ Doing so would make the script engine the default program instead of a text editor so you might not want to. Or maybe assign .dxe and changing the filename before running. Executable has executable file type for a reason - it self-implies that the main function of the file - is to be executed. The problem with making source code files executable is that, source code files, might not always be monolithic executable code, but a part of a bigger interconnected program. That would lead to partily working program execution, and most of the times guess work of whether source code file was supposed to be executed. This is wrong. All code must be included. All library source code is included. If this is infeasible then simply the binaries are included. It would be no different than dynamic linking that already exists. It doesn't create any new problems. Sure certain things would need to be worked out properly to optimize the experience, but that is obvious. One can't make everything perfect though and one shouldn't expect it... The clear alternative would be: .exe file on which, if rightclicked - would open context menu showing posibility of "edit/improve this executable". Which would not create additional problem mentioned above. Yes, all the source code and required source code to make everything work must be included. And where would all the code mentioned before should be stored? It must be stored in a an single self extracting archive, self executing archive, that is self-implying that it is an executable code, which means it can't be .d file extension, but an .exe file extension. (or any other, if anyone come up with more common or self explaining extension name) If we use the same .d file extension on this self-exectuable, self-extracting archive, it would confused people weather it is executable or some novice programmer's written module/script.
Re: Get files from directory sorted by name
On Thursday, 26 April 2018 at 16:59:45 UTC, Dr.No wrote: On Wednesday, 25 April 2018 at 19:25:11 UTC, Jesse Phillips wrote: On Wednesday, 25 April 2018 at 17:34:41 UTC, Dr.No wrote: Is there something implemented already to get the files from directory by name using D or I'm on my own and I have to write it myself? I didn't find how do that with dirEntries() I want to add that sorting can be done, if you just call std.algorithm.sort you'll find that file names with numbers in them will be sorted as a well strings. Newfile1.txt Newfile10.txt Newfile2.txt I've had realized that then implemented natural sort Thats what it was called. Looks like Rosetta Code has an implementation. https://rosettacode.org/wiki/Natural_sorting#D
Re: Template to retrieve compile-time enum member from run-time enum member?
On Friday, 27 April 2018 at 13:43:47 UTC, Timoses wrote: `instantiateWith` gets called in three variations (menum.A, menum.B and menum.C). This causes instantiateWith to return TempStruct for each case of Temp... However, I was under the impression that a templated function will exist multiple (in this case 3) times, so the return type should be allowed to be different?! I think, because the enum value is a runtime parameter for instantiateWith, only a single variation of it exists. And this cannot have different return types. So... "alias Fn" and "T" stay the same. The value of x varies. https://run.dlang.io/is/jX4Ybh states the same.
Re: Auto expiring cache library
On Friday, 27 April 2018 at 09:07:31 UTC, Pasqui23 wrote: I want a library that offers an in-memory data structure,such that I can write,for example: cache.insert(key,value,expiry) and I can retrieve the value with something like cache[key],unless it has passed expiry seconds. Can be done?What library should I use? Memcached
Re: Template to retrieve compile-time enum member from run-time enum member?
On Friday, 27 April 2018 at 13:39:22 UTC, Simen Kjærås wrote:
That's an unfortunate error message. The problem is TempStruct
is defined inside the Temp template. In the same way that
struct Foo(T) {} is different for Foo!int and Foo!string,
TempStruct is a different type for Temp!(menum.A) and
Temp!(menum.B).
The solution is to move TempStruct outside the template:
struct TempStruct { uint i; }
template Temp(menum e)
{
TempStruct Temp;
shared static this()
{
static if (e == menum.A)
Temp.i = 3;
}
}
--
Simen
Ty.
I figured that's the reason. I still can't quite get my head
around "Why?" though.
`instantiateWith` gets called in three variations (menum.A,
menum.B and menum.C). This causes instantiateWith to return
TempStruct for each case of Temp...
However, I was under the impression that a templated function
will exist multiple (in this case 3) times, so the return type
should be allowed to be different?!
Re: Template to retrieve compile-time enum member from run-time enum member?
On Friday, 27 April 2018 at 13:27:45 UTC, Timoses wrote:
Bumped across another problem : /
```
import std.stdio;
enum menum { A, B, C }
void main()
{
foo(menum.A);
}
void foo(menum e)
{
writeln(instantiateWith!Temp(e));
}
auto instantiateWith(alias Fn, T)(T x)
if (is(T == enum))
{
switch (x)
{
import std.traits : EnumMembers;
static foreach (e; EnumMembers!T)
case e:
return Fn!e;
default:
assert(false);
}
}
template Temp(menum e)
{
struct TempStruct { uint i; };
TempStruct Temp;
shared static this()
{
static if (e == menum.A)
Temp.i = 3;
}
}
```
now returns:
source\app.d(25,17): Error: mismatched function return type
inference of `TempStruct` and `TempStruct`
source\app.d(12,33): Error: template instance
`app.instantiateWith!(Temp, menum)` error instantiating
dmd failed with exit code 1.
It's the same return type... so why the error?
That's an unfortunate error message. The problem is TempStruct is
defined inside the Temp template. In the same way that struct
Foo(T) {} is different for Foo!int and Foo!string, TempStruct is
a different type for Temp!(menum.A) and Temp!(menum.B).
The solution is to move TempStruct outside the template:
struct TempStruct { uint i; }
template Temp(menum e)
{
TempStruct Temp;
shared static this()
{
static if (e == menum.A)
Temp.i = 3;
}
}
--
Simen
Re: Template to retrieve compile-time enum member from run-time enum member?
Bumped across another problem : /
```
import std.stdio;
enum menum { A, B, C }
void main()
{
foo(menum.A);
}
void foo(menum e)
{
writeln(instantiateWith!Temp(e));
}
auto instantiateWith(alias Fn, T)(T x)
if (is(T == enum))
{
switch (x)
{
import std.traits : EnumMembers;
static foreach (e; EnumMembers!T)
case e:
return Fn!e;
default:
assert(false);
}
}
template Temp(menum e)
{
struct TempStruct { uint i; };
TempStruct Temp;
shared static this()
{
static if (e == menum.A)
Temp.i = 3;
}
}
```
now returns:
source\app.d(25,17): Error: mismatched function return type
inference of `TempStruct` and `TempStruct`
source\app.d(12,33): Error: template instance
`app.instantiateWith!(Temp, menum)` error instantiating
dmd failed with exit code 1.
It's the same return type... so why the error?
Re: Idiomatic way to add examples to dub package
On Thursday, 26 April 2018 at 18:16:01 UTC, FreeSlave wrote: Most dub packages are libraries and should provide runnable examples. What's the current idiomatic way to add examples? IMO the most simple way (and the best too) is to put single file packages in the example folder, so that an example can just be run with DUB like that: `dub example1.d`. Other good point is that you can specify that the dependency to the main package is local, like here: https://github.com/BBasile/kheops/blob/master/runnable/actions_window.d#L5. And finally the example folder is neither polluted with sub-folders nor with sub.selection JSON, FTW.
Re: Idiomatic way to add examples to dub package
27.04.2018 13:58, Laurent Tréguier пишет: This is the way Rust packages handle their Cargo.lock file, if I'm not mistaken, and it seems reasonable to me Exactly
Re: Idiomatic way to add examples to dub package
On Friday, 27 April 2018 at 10:18:53 UTC, drug wrote: dub.selections.json shouldn't be included in case of library because it should be configured at import site. in case of application it has been configured and so dub.selections.json should be included. IMHO. This is the way Rust packages handle their Cargo.lock file, if I'm not mistaken, and it seems reasonable to me
Re: Template to retrieve compile-time enum member from run-time enum member?
On Thursday, 26 April 2018 at 16:46:11 UTC, Simen Kjærås wrote:
The only step you're missing is the template needs to be
instantiated inside the static foreach, like this:
auto instantiateWith(alias Fn, T)(T x)
if (is(T == enum))
{
import std.traits : EnumMembers;
switch (x)
{
static foreach (e; EnumMembers!T)
case e:
return Fn!e;
default:
assert(false);
}
}
enum menum { A, B, C }
template Temp(menum m)
{
enum Temp = m.stringof;
}
Ah thanks!!
I struggled a bit with finding out how to actually it in my use
case. I just didn't see the pattern:
```
instantiateWith!()
```
Thank you!
Re: Idiomatic way to add examples to dub package
26.04.2018 21:16, FreeSlave пишет: Most dub packages are libraries and should provide runnable examples. What's the current idiomatic way to add examples? I used sub-packages with dependency on the library and "*" as version and running them as dub run :examplename Now I've noticed vibed uses a different scheme - examples are like separate packages that are supposed to ran with --root option (if running from the library root directory) and specify the dependency with "path" property like here https://github.com/vibe-d/vibe.d/blob/master/examples/http_server/dub.json That involves more typing when running an example but keeps the main dub.json independent from examples (no need to specify sub-packages) Also I still don't understand if I need to include dub.selections.json in VCS repo. I read somewhere that it should be included but vibed examples don't have dub.selections.json. E.g. here https://github.com/dlang/dub/issues/829#issuecomment-215741874 jacob-carlborg said For applications the dub.selection.json files should be in version control, for libraries it should not be Examples are applications so I thought dub.selections.json should be included. But it may be an outdated information. If there're tutorials on both topics (how to include examples and when one should include dub.selections.json in VCS), I would like to read them. I could not find any useful info on code.dlang.org regarding these issues, while those look like basic issues that must be covered in manuals. I think that separate examples are better, it can of course depends on specific case, but in general independence simplifies at least maintenance. dub.selections.json shouldn't be included in case of library because it should be configured at import site. in case of application it has been configured and so dub.selections.json should be included. IMHO.
Auto expiring cache library
I want a library that offers an in-memory data structure,such that I can write,for example: cache.insert(key,value,expiry) and I can retrieve the value with something like cache[key],unless it has passed expiry seconds. Can be done?What library should I use?
Re: Making an .exe that executes source file inside itself.
On Thursday, 26 April 2018 at 10:06:57 UTC, JN wrote: On Wednesday, 25 April 2018 at 19:19:58 UTC, BoQsc wrote: Alternatively, I don't know about specifics how to implement it in D, but the key phrase you are looking for is "code hotswap" or "hot loading". It's being popularized right now in gamedev circles, to avoid slow complications of the code. The way to do it is push code into DLLs, then reload the DLL if the change is detected. Of course it's not that simple, because there are some tricky parts around DLL boundaries and you have to reload the entire state, but it is possible. In such case, rather than recompile the entire code, you can just recompile a small subset of functionality to a DLL. - content below is just my thoughts and may or may not have anything common with reality, don't take it as truth, forget after reading, proceed on your own risk The overall process is like this: 1) make a core app that basically serves as host (whether or not put domain logic here is open question) 2) when run, scan & plug-in[*] shared libs (they must must follow well defined plugin API, ideally providing information about their requirements/dependencies and their services) 3) when library should be hot reloaded, it first serializes 'shared' data, then re-loaded with same mechanism as in 2), and deserializes data back. [*] - it has implications depending on platform, on Windows for example don't just load the libs(executing one's is locked by OS), but copy to temporary executing location first, that way one can overwrite the original libs while (a copy of) it is still running and app can be notified about file changes to perform hot reload. (AFAIK UnrealEngine does this without temporary location, instead it relies on custom build system that checks whether app is running, which will then append incremental number to the name of the resulting binary, after build is done editor replaces old library with new one. I don't know the exact notification mechanism, it could be the build system itself or just FS event handled by engine which compares known running lib names for such incremental change, both ways makes it harder to manually replace library) The one of the major points of having such libraries, after all, to be able to swap implementation without full rebuild, and better, in run time. For example in case of game engine, let's say we want to switch rendering API(say DirectX to Vulkan), in this case there is even no need to serialize anything because most(if not any) of the stuff is implementation specific, such swap could be done *almost* in real time, I mean minor freeze for few frames doesn't makes a big difference here, and really I doubt anyone would do that in a middle of a game(not in menu or pause). There is still lots of question, after all this is just example in theory, in practice however I've never yet come close enough to the practical implementation of such thing in D. WARNING: ONLY WINDOWS-SPECIFIC STUFF BELOW But now the problem. Guess what? DLL support on Windows is simply isn't there yet! AHAHAHAH (imagine some epic evil laugh here) Sure thing, it is possible to make a bunch of loose functions that operates on built-in (value) types, but does this really provides the extensibility? I can hardly imagine usefulness of such approach in any but trivial cases, just imagine Unity or Unreal Engine, or complex software like 3ds Max or Maya... It is also to some extent possible to go shady with hacks and abuses, but this is something that should not be shipped as production ready, and there is even no guarantee it will work in a future. The last option probably is to implement whole mechanism from scratch, like COM objects, D is a system language after all, but I to be honest don't have the desire to fall that low, especially because on Linux it works for years... (side note: I actually tried few simple (hacky) test cases with passing classes cross-boundary and then unloading library, seems to work on Windows, not sure about memory leaks and consequnces in long runs though)
