Re: It makes me sick!
On Friday, 28 July 2017 at 01:10:03 UTC, Mike Parker wrote: On Friday, 28 July 2017 at 00:28:52 UTC, FoxyBrown wrote: You are not being very logical. The zip file as N files in it. No matter what those files are, it should be a closed system. That is, if I insert or add(not replace) M file to the directory structure it should not break D, period! That's *not* what happened here. Jonathan explained it quite well. std.datetime was refactored into a package, its contents split into new modules. When you import a module foo, dmd looks for: 1. foo.di 2. foo.d 3. foo/package.d When it finds one, it stops looking. It's not an error for all three to exist. Your error came because it found std/datetime.d, but you linked to a library that included symbols for std/datatetime/package.d. It's not the compiler's responsibility to error in that case. It's your responsibility to properly install. Sorry, wrong. Why? Because NO file in the zip should be referencing any file not in the zip unless it is designed to behave that way(e.g., an external lib or whatever). If an old external program is referencing a file in dmd2 that isn't in the new zip it should err. Why? Because suppose you have an old program that references some old file in dmd2 dir and you upgrade dmd2 by extracting the zip. The program MAY still work and use broke functionality that will go undetected but be harmful. Why? Because dmd.exe is reference a file it shouldn't and it should know it shouldn't yet it does so anyways. It really has nothing to do with the file being in the dir but that dmd is being stupid because no one bothered to sanity checks because they are too lazy/think it's irrelevant because it doesn't effect them. That's unreasonable. Nope, your unreasonable expecting the end user to clean up the mess "you" leave. I should be able to put any extra files anywhere in the dmd2 dir structure and it should NOT break dmd. There are numerous applications out there that can break if you simply overwrite a directory with a newer version of the app. DMD is not alone with this. You should always delete the directory first. It's precisely why the compiler does so. Nope. Virtually all apps, at least on windows, work fine if you replace their contents with new versions. Generally, only generated files such as settings and such could break the apps... but this is not the problem here. If dmd breaks in strange and unpredictable ways IT IS DMD's fault! No exceptions, no matter what you believe, what you say, what lawyer you pay to create a law for you to make you think you are legally correct! You can make any claim you want like: "The end user should install in to a clean dir so that DMD doesn't get confused and load a module that doesn't actually have any implementation" but that's just your opinion. At the end of the day it only makes you and dmd look bad when it doesn't work because of some lame minor issue that could be easily fixed. It suggests laziness["Oh, there's a fix but I'm too lazy to add it"], arrogance["Oh, it's the end users fault, let them deal with it"], and a bit of ignorance. In the long run, mentalities like yours are hurting D rather than helping it. Sure, you might contribute significantly to D's infrastructure, but if no one uses because there are so many "insignificant" issues then you've just wasted an significant portion of your life for absolutely nothing. So, I'd suggest you rethink your position and the nearsighted rhetoric that you use. You can keep the mentality of kicking the can down the road and blaming the end user but it will ultimately get you no where.
Re: DDox and filters.
yup figured it out - module documentation needs to go *above* the module declaration or you get nothing. On Fri, Jul 28, 2017 at 11:53 AM, Soulsbane via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > On Thursday, 27 July 2017 at 03:01:50 UTC, Danni Coy wrote: > >> I am trying to build my projects documentation via the ddox system via >> dub. It seems that my modules are being documented and then filtered out. >> >> Ironically for a documentation system there isn't a lot of documentation. >> What is the minimum I need in order for documentation to show up? >> how do I control the filter options. >> > > I think I had this problem and solved it by adding a comment block at the > top describing the module. >
Re: DDox and filters.
On Thursday, 27 July 2017 at 03:01:50 UTC, Danni Coy wrote: I am trying to build my projects documentation via the ddox system via dub. It seems that my modules are being documented and then filtered out. Ironically for a documentation system there isn't a lot of documentation. What is the minimum I need in order for documentation to show up? how do I control the filter options. I think I had this problem and solved it by adding a comment block at the top describing the module.
Re: using DCompute
On Friday, 28 July 2017 at 01:30:58 UTC, Nicholas Wilson wrote: Yes, although I'll have to add an attribute shim layer for the dcompute druntime symbols to be accessible for DMD. When you compile LDC will produce .ptx and .spv files in the object file directory which will be able to be used in any project. The only thing that will be more fragile is lambda kernels as they are mangled numerically (`__lambda1`, `__lambda1` and so on). I imagine that using dcompute this way with DMD for development would be popular. For instance, the GPU part might be only a small part of a project so you wouldn't want to be forced to use LDC the moment the tiniest GPU code is in it. Once you've ensured everything is working correctly, you might add something about this to the wiki, or whatever.
Re: using DCompute
On Friday, 28 July 2017 at 00:39:43 UTC, James Dean wrote: On Friday, 28 July 2017 at 00:23:35 UTC, Nicholas Wilson wrote: On Thursday, 27 July 2017 at 21:33:29 UTC, James Dean wrote: I'm interested in trying it out, says it's just for ldc. Can we simply compile it using ldc then import it and use dmd, ldc, or gdc afterwards? The ability to write kernels is limited to LDC, though there is no practical reason that, once compiled, you couldn't use resulting generated files with GDC or DMD (as long as the mangling matches, which it should). This is not a priority to get working, since the assumption is if you're trying to use the GPU to boost your computing power, then you like care enough to use LDC, as opposed to DMD (GDC is still a bit behind DMD so I don't consider it) to get good optimisations in the first place. Yes, but dmd is still good for development since LDC sometimes has problems. If you have problems please tell us! Can we compile kernels in LDC and import them in to a D project seamlessly? Basically keep an LDC project that deals with the kernels while using dmd for the bulk of the program. I mean, is it a simple import/export type of issue? Yes, although I'll have to add an attribute shim layer for the dcompute druntime symbols to be accessible for DMD. When you compile LDC will produce .ptx and .spv files in the object file directory which will be able to be used in any project. The only thing that will be more fragile is lambda kernels as they are mangled numerically (`__lambda1`, `__lambda1` and so on).
Re: It makes me sick!
On Friday, 28 July 2017 at 00:28:52 UTC, FoxyBrown wrote: You are not being very logical. The zip file as N files in it. No matter what those files are, it should be a closed system. That is, if I insert or add(not replace) M file to the directory structure it should not break D, period! That's *not* what happened here. Jonathan explained it quite well. std.datetime was refactored into a package, its contents split into new modules. When you import a module foo, dmd looks for: 1. foo.di 2. foo.d 3. foo/package.d When it finds one, it stops looking. It's not an error for all three to exist. Your error came because it found std/datetime.d, but you linked to a library that included symbols for std/datatetime/package.d. It's not the compiler's responsibility to error in that case. It's your responsibility to properly install. Why? Because NO file in the zip should be referencing any file not in the zip unless it is designed to behave that way(e.g., an external lib or whatever). If an old external program is referencing a file in dmd2 that isn't in the new zip it should err. Why? Because suppose you have an old program that references some old file in dmd2 dir and you upgrade dmd2 by extracting the zip. The program MAY still work and use broke functionality that will go undetected but be harmful. Why? Because dmd.exe is reference a file it shouldn't and it should know it shouldn't yet it does so anyways. It really has nothing to do with the file being in the dir but that dmd is being stupid because no one bothered to sanity checks because they are too lazy/think it's irrelevant because it doesn't effect them. That's unreasonable. I should be able to put any extra files anywhere in the dmd2 dir structure and it should NOT break dmd. There are numerous applications out there that can break if you simply overwrite a directory with a newer version of the app. DMD is not alone with this. You should always delete the directory first. It's precisely why the compiler does so.
Re: using DCompute
On Friday, 28 July 2017 at 00:23:35 UTC, Nicholas Wilson wrote: On Thursday, 27 July 2017 at 21:33:29 UTC, James Dean wrote: I'm interested in trying it out, says it's just for ldc. Can we simply compile it using ldc then import it and use dmd, ldc, or gdc afterwards? The ability to write kernels is limited to LDC, though there is no practical reason that, once compiled, you couldn't use resulting generated files with GDC or DMD (as long as the mangling matches, which it should). This is not a priority to get working, since the assumption is if you're trying to use the GPU to boost your computing power, then you like care enough to use LDC, as opposed to DMD (GDC is still a bit behind DMD so I don't consider it) to get good optimisations in the first place. Yes, but dmd is still good for development since LDC sometimes has problems. Can we compile kernels in LDC and import them in to a D project seamlessly? Basically keep an LDC project that deals with the kernels while using dmd for the bulk of the program. I mean, is it a simple import/export type of issue?
Re: It makes me sick!
On Thursday, 27 July 2017 at 23:37:41 UTC, Jonathan M Davis wrote: On Thursday, July 27, 2017 11:55:21 Ali Çehreli via Digitalmars-d-learn wrote: On 07/27/2017 11:47 AM, Adam D. Ruppe wrote: > On Thursday, 27 July 2017 at 18:35:02 UTC, FoxyBrown wrote: >> But the issue was about missing symbols, not anything >> "extra". If datatime.d is there but nothing is using it, >> why should it matter? > > YOU were using it with an `import std.datetime;` line. With > the file still there, it sees it referenced from your code > and loads the file... but since it is no longer used > upstream, the .lib doesn't contain it and thus missing > symbol. So, the actual problem is that given both datetime/package.d and datetime.d, the import statement prefers the file. It could produce a compilation error. If we don't want that extra check by the compiler, it would be better to keep datetime.d with a warning in it about the change. The warning could say "please remove this file". :) I think that this should obviously be a compilation error as should any case where you've basically declared the same module twice. And really, I don't see any reason to support extracting the new zip on the old folder. We've never said that that would work, and if you think it through, it really isn't all that reasonable to expect that it would work. The list of files changes from release to release (even if removals are rare), and the layout of the directories could change. So long as the sc.ini or dmd.conf does ther right thing, then that really isn't a problem. Obviously, it's more of a pain if folks are making manual changes, but we've never promised that the directory structure of each release would be identical or that copying one compiler release on top of another would work. - Jonathan M Davis You are not being very logical. The zip file as N files in it. No matter what those files are, it should be a closed system. That is, if I insert or add(not replace) M file to the directory structure it should not break D, period! Why? Because NO file in the zip should be referencing any file not in the zip unless it is designed to behave that way(e.g., an external lib or whatever). If an old external program is referencing a file in dmd2 that isn't in the new zip it should err. Why? Because suppose you have an old program that references some old file in dmd2 dir and you upgrade dmd2 by extracting the zip. The program MAY still work and use broke functionality that will go undetected but be harmful. Why? Because dmd.exe is reference a file it shouldn't and it should know it shouldn't yet it does so anyways. It really has nothing to do with the file being in the dir but that dmd is being stupid because no one bothered to sanity checks because they are too lazy/think it's irrelevant because it doesn't effect them. I should be able to put any extra files anywhere in the dmd2 dir structure and it should NOT break dmd. It's like if I put a text file in some OS directory and the OS decides to use that file and crash the OS and not boot... it could happen, but it shouldn't. In fact, all of phobos should be versioned. Each module should have a version id embedded in it. Each release all the versions are updated before shipping.
Re: using DCompute
On Thursday, 27 July 2017 at 21:33:29 UTC, James Dean wrote: I'm interested in trying it out, says it's just for ldc. Can we simply compile it using ldc then import it and use dmd, ldc, or gdc afterwards? The ability to write kernels is limited to LDC, though there is no practical reason that, once compiled, you couldn't use resulting generated files with GDC or DMD (as long as the mangling matches, which it should). This is not a priority to get working, since the assumption is if you're trying to use the GPU to boost your computing power, then you like care enough to use LDC, as opposed to DMD (GDC is still a bit behind DMD so I don't consider it) to get good optimisations in the first place. --- a SPIRV capable LLVM (available here to build ldc to to support SPIRV (required for OpenCL)). or LDC built with any LLVM 3.9.1 or greater that has the NVPTX backend enabled, to support CUDA. --- Is the LDC from the download pages have these enabled? I dont think so, although future releases will likely have the NVPTX backend enabled. Also, can DCompute or any GPU stuff efficiently render stuff because it is already on the GPU or does one sort of have to jump through hoops to, say, render a buffer? There are memory sharing extensions that allow you to give access to and from OpenGL/DirectX so you shouldn't suffer a perf penalty for doing so. e.g., suppose I want to compute a 3D mathematical function and visualize it's volume. Do I go in to the GPU, do the compute, back out to cpu, then to the graphics system(opengl/directX) or can I just essentially do it all from the gpu? there should be no I/O overhead.
Re: It makes me sick!
On Thursday, July 27, 2017 11:55:21 Ali Çehreli via Digitalmars-d-learn wrote: > On 07/27/2017 11:47 AM, Adam D. Ruppe wrote: > > On Thursday, 27 July 2017 at 18:35:02 UTC, FoxyBrown wrote: > >> But the issue was about missing symbols, not anything "extra". If > >> datatime.d is there but nothing is using it, why should it matter? > > > > YOU were using it with an `import std.datetime;` line. With the file > > still there, it sees it referenced from your code and loads the file... > > but since it is no longer used upstream, the .lib doesn't contain it and > > thus missing symbol. > > So, the actual problem is that given both > >datetime/package.d and >datetime.d, > > the import statement prefers the file. It could produce a compilation > error. > > If we don't want that extra check by the compiler, it would be better to > keep datetime.d with a warning in it about the change. The warning could > say "please remove this file". :) I think that this should obviously be a compilation error as should any case where you've basically declared the same module twice. And really, I don't see any reason to support extracting the new zip on the old folder. We've never said that that would work, and if you think it through, it really isn't all that reasonable to expect that it would work. The list of files changes from release to release (even if removals are rare), and the layout of the directories could change. So long as the sc.ini or dmd.conf does ther right thing, then that really isn't a problem. Obviously, it's more of a pain if folks are making manual changes, but we've never promised that the directory structure of each release would be identical or that copying one compiler release on top of another would work. - Jonathan M Davis
Re: Pass range to a function
On 07/27/2017 02:16 PM, Chris wrote:
> What is the value of `???` in the following program:
> void categorize(??? toks) {
> foreach (t; toks) {
> writeln(t);
> }
> }
The easiest solution is to make it a template (R is a suitable template
variable name for a range type):
void categorize(R)(R toks) {
foreach (t; toks) {
writeln(t);
}
}
Your function will work with any type that can be iterated with foreach
and can be passed to writeln. However, you can use template constraints
to limit its usage, document its usage, or produce better compilation
errors when it's called with an incompatible type (the error message
would point at the call site as opposed to the body of categorize):
import std.range;
import std.traits;
void categorize(R)(R toks)
if (isInputRange!R && isSomeString!(ElementType!R)) {
foreach (t; toks) {
writeln(t);
}
}
Ali
using DCompute
I'm interested in trying it out, says it's just for ldc. Can we simply compile it using ldc then import it and use dmd, ldc, or gdc afterwards? --- a SPIRV capable LLVM (available here to build ldc to to support SPIRV (required for OpenCL)). or LDC built with any LLVM 3.9.1 or greater that has the NVPTX backend enabled, to support CUDA. --- Is the LDC from the download pages have these enabled? Also, can DCompute or any GPU stuff efficiently render stuff because it is already on the GPU or does one sort of have to jump through hoops to, say, render a buffer? e.g., suppose I want to compute a 3D mathematical function and visualize it's volume. Do I go in to the GPU, do the compute, back out to cpu, then to the graphics system(opengl/directX) or can I just essentially do it all from the gpu?
Pass range to a function
I'm using regex `matchAll`, and mapping it to get a sequence of
strings. I then want to pass that sequence to a function. What is
the general "sequence of strings" type declaration I'd need to
use?
In C#, it'd be `IEnumerable`. I'd rather not do a
to-array on the sequence, if possible. (e.g. It'd be nice to just
pass the lazy sequence into my categorize function.)
What is the value of `???` in the following program:
```
import std.stdio, std.regex, std.string, std.algorithm.iteration;
auto regexToStrSeq(RegexMatch!string toks) {
return toks.map!(t => t[0].strip());
}
void categorize(??? toks) {
foreach (t; toks) {
writeln(t);
}
}
void main()
{
auto reg =
regex("[\\s,]*(~@|[\\[\\]{\\}()'`~^@]|\"(?:.|[^\"])*\"|;.*|[^\\s\\[\\]{}('\"`,;)]*)");
auto line = "(+ 1 (* 2 32))";
auto baz = matchAll(line, reg);
categorize(regexToStrSeq(baz).array);
}
```
Re: Problem with dtor behavior
On Thursday, 27 July 2017 at 19:19:27 UTC, SrMordred wrote:
//D-CODE
struct MyStruct{
int id;
this(int id){
writeln("ctor");
}
~this(){
writeln("dtor");
}
}
MyStruct* obj;
void push(T)(auto ref T value){
obj[0] = value;
}
void main()
{
obj = cast(MyStruct*)malloc( MyStruct.sizeof );
push(MyStruct(1));
}
OUTPUT:
ctor
dtor
dtor
I didnt expected to see two dtors in D (this destroy any
attempt to free resources properly on the destructor).
AFAICT it's because opAssign (`obj[0] = value` is an opAssign)
creates a temporary struct object (you can see it being destroyed
by printing the value of `cast(void*) ` in the destructor).
Can someone explain why is this happening and how to achieve
the same behavior as c++?
Use std.conv.emplace:
---
import std.conv : emplace;
void push(T)(auto ref T value){
emplace(obj, value);
}
---
Randomed/encoded code
I would like to encode code in such a way that each compilation produces "random" code as compared to what the previous compilation produced, but ultimately the same code is ran each time(same effect). Basically we can code a function that does a job X in many different ways. Each way looks different in binary but does the same job(Same effect). I'd like a way to sort of randomly sample/generate the different functions that do the same job. The easiest way to wrap your head around this is to realize that certain instructions and groups of instructions can be rearranged, producing a binary that is different but the effect is the same. Probably, ultimately, that is all that can be done(certain other tricks could possibly be added to increase the sampling coverage such as nop like instructions, dummy instructions, etc). The main issue is how to take an actual D function and transform it in to a new D function, which, when ran, ultimately does the same thing as the original but is not the same "binary". Encrypting is a subset of this problem as we can take any string and use it to encode the code then decrypt it. And this may be usable, but then the encryption and decryption instructions must somehow be randomizable, else we are back at square one. It might be easier though, to use the encryption method to randomize the original function since the encryption routine is known while the original function is not(as it could be any function). I'm not looking for a mathematical solution, just something that works well in practice. i.e., The most skilled human reading the disassembly would find it very difficult to interpret what is going on. He might be able to figure out one encryption routine, say, but when he sees the "same code"(same effect) he will have to start from scratch to understand it because its been "randomized". The best way I can see how to do this is to have a list of well known encoding routines that take an arbitrary function, encrypt it. Each routine can be "randomized" by using various techniques to disguise it such as those mentioned earlier. This expands the list of functions tremendously. If there are N functions and M different ways to alter each of those functions then there are N*M total functions that we can use to encrypt the original function. If we further allow function composition of these functions, then we can get several orders of magnitude of complexity with such as a few N. The goal though, is to do this efficiently and effectively in a way that can be amended. It will be useful in copy protection and used with other techniques to make it much more effective. Ultimately the weak point with the encryption techniques is decryption the functions but by composing encryption routines makes it stronger. Any ideas how to achieve this in D nicely?
Re: It makes me sick!
On Thursday, 27 July 2017 at 03:34:19 UTC, FoxyBrown wrote: Knowing that every time I upgrade to the latest "official" D compiler I run in to trouble: I recompiled gtkD with the new compiler, same result. My code was working before the upgrade just fine and I did not change anything. I've had to delete my previous install at least 2 times before. It is an infrequent headache I hit because I'm not following appropriate install steps. I cannot expect upstream to support a DMD folder which has additional files from what they have provided. Here is my attempt to explain the problem. * std/datetime.d has a different mangled name than std/datetime/package.d. * The phobos.lib contains the std.datetime.package module and no longer contains the std.datetime module. * When the compiler is reading your code it sees imports for std.datetime and looks at the import location /install/directory/dmd2/src/std and it writes a reference to the std/datetime.d file. * The linker takes over, loads up phobos.lib and barfs since the referenced symbol was not compiled into your obj file nor the released phobos.lib. More recently the headache I've been hitting with upgrades is improvements to @safe and such. The bug fixes around this cause libraries I'm using to fail compilation. Even this isn't so bad, but the library that files is a dependent of a dub package I'm using. This means I have to wait for the dependent package to update and release followed by the dub package I'm actually referencing. So even if I create the needed patches, I have to wait at each step for the author to merge and tag their release. (or create a branch of the project and throw it in dub so I can control all the updates)
Re: It makes me sick!
On 07/27/2017 12:24 PM, Steven Schveighoffer wrote: On 7/27/17 3:00 PM, Ali Çehreli wrote: On 07/27/2017 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote: > You ended up with two versions of std.datetime. One was the module, and the > other was the package. I don't know how many people install from the zip file but I think the zip file should include a datetime.d file with the following statement in it: static assert(false, "std.datetime is now a package; please remove this file"); If std/datetime.d is there, how does one import std/datetime/package.d? -Steve Currently not possible. (Thank you for the bug report. :) ) I tried to find a band aid to the issue. Otherwise, I agree that the compiler should issue an error. Ali
Re: It makes me sick!
On 7/27/17 3:00 PM, Ali Çehreli wrote: On 07/27/2017 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote: > You ended up with two versions of std.datetime. One was the module, and the > other was the package. I don't know how many people install from the zip file but I think the zip file should include a datetime.d file with the following statement in it: static assert(false, "std.datetime is now a package; please remove this file"); If std/datetime.d is there, how does one import std/datetime/package.d? -Steve
Problem with dtor behavior
//D-CODE
struct MyStruct{
int id;
this(int id){
writeln("ctor");
}
~this(){
writeln("dtor");
}
}
MyStruct* obj;
void push(T)(auto ref T value){
obj[0] = value;
}
void main()
{
obj = cast(MyStruct*)malloc( MyStruct.sizeof );
push(MyStruct(1));
}
OUTPUT:
ctor
dtor
dtor
//C++ CODE
#include
#include
using namespace std;
void writeln(string s){ cout << s << '\n'; }
struct MyStruct{
int id;
MyStruct(int id){
writeln("ctor");
}
~MyStruct(){
writeln("dtor");
}
};
MyStruct* obj;
template
void push(T&& value){
obj[0] = value;
}
int main()
{
obj = (MyStruct*)malloc( sizeof(MyStruct) );
push(MyStruct(1));
return 0;
}
OUTPUT:
ctor
dtor
I didnt expected to see two dtors in D (this destroy any attempt
to free resources properly on the destructor).
Can someone explain why is this happening and how to achieve the
same behavior as c++?
Thanks :)
Re: It makes me sick!
On 7/27/17 2:54 PM, Jonathan M Davis via Digitalmars-d-learn wrote: You ended up with two versions of std.datetime. One was the module, and the other was the package. importing std.datetime could have imported either of them. dmd _should_ generate an error in that case, but I don't know if it does or not. It does not (obviously, we are discussing it :) https://issues.dlang.org/show_bug.cgi?id=17699 -Steve
Re: It makes me sick!
On 07/27/2017 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote: > You ended up with two versions of std.datetime. One was the module, and the > other was the package. I don't know how many people install from the zip file but I think the zip file should include a datetime.d file with the following statement in it: static assert(false, "std.datetime is now a package; please remove this file"); Of course the problem is, the user would have to remove the file every time they unzipped potentially a later release. :/ We need more prominent information about the change I guess. Ali
Re: It makes me sick!
On 07/27/2017 11:47 AM, Adam D. Ruppe wrote: On Thursday, 27 July 2017 at 18:35:02 UTC, FoxyBrown wrote: But the issue was about missing symbols, not anything "extra". If datatime.d is there but nothing is using it, why should it matter? YOU were using it with an `import std.datetime;` line. With the file still there, it sees it referenced from your code and loads the file... but since it is no longer used upstream, the .lib doesn't contain it and thus missing symbol. So, the actual problem is that given both datetime/package.d and datetime.d, the import statement prefers the file. It could produce a compilation error. If we don't want that extra check by the compiler, it would be better to keep datetime.d with a warning in it about the change. The warning could say "please remove this file". :) Ali
Re: It makes me sick!
On 7/27/17 2:35 PM, FoxyBrown wrote: On Thursday, 27 July 2017 at 18:14:52 UTC, Steven Schveighoffer wrote: On 7/27/17 1:58 PM, FoxyBrown wrote: On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis wrote: On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via Digitalmars-d-learn wrote: On 07/26/2017 09:20 PM, FoxyBrown wrote: >> Somebody else had the same problem which they solved by removing >> >> "entire dmd": >> http://forum.dlang.org/thread/ejybuwermnentslcy...@forum.dlang.org >> >> Ali > > Thanks, that was it. So I guess I have to delete the original dmd2 dir > before I install each time... didn't use to have to do that. Normally, it shouldn't be necessary. The splitting of the datetime package[1] had this effect but I'm not sure why the installation process can't take care of it. Ali [1] http://dlang.org/changelog/2.075.0.html#split-std-datetime It _should_ take care of it. The fact that multiple people have run into this problem and that the solution was to remove dmd and then reinstall it implies that there's a bug in the installer. - Jonathan M Davis I do not use the installer, I use the zip file. I assumed that everything would be overwritten and any old stuff would simply go unused.. but it seems it doesn't. If the other person used the installer then it is a problem with dmd itself not designed properly and using files that it shouldn't. I simply unzip the zip file in to the dmd2 dir and replace sc.ini... that has been my MO for since I've been trying out dmd2 and only recently has it had a problem. If you extracted the zip file over the original install, then it didn't get rid of std/datetime.d (as extracting a zipfile doesn't remove items that exist on the current filesystem but aren't in the zipfile). So I can totally see this happening. I don't know of a good way to solve this except to tell people, don't do that. But the issue was about missing symbols, not anything "extra". If datatime.d is there but nothing is using it, why should it matter? Why would it have any effect on the compilation process and create errors with D telling me something is being used that isn't? dmd shouldn't be picking up extraneous and non-connected files just for the fun of it. They aren't non-connected. If you import std.datetime, the compiler is first going to look for std/datetime.d. Not finding that, it will look for std/datetime/package.d. The latter is what is supported and built into the library for 2.075. The former is a ghost of the original installation, but it's what *your* code is importing. You might not even import std.datetime, but rather something else that imports it. Either way, the compiler generates the wrong mangled names, and they don't match up with the ones in the library. -Steve
Re: It makes me sick!
On Thursday, July 27, 2017 18:35:02 FoxyBrown via Digitalmars-d-learn wrote: > On Thursday, 27 July 2017 at 18:14:52 UTC, Steven Schveighoffer > > wrote: > > On 7/27/17 1:58 PM, FoxyBrown wrote: > >> On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis > >> > >> wrote: > >>> On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via > >>> > >>> Digitalmars-d-learn wrote: > On 07/26/2017 09:20 PM, FoxyBrown wrote: > >> Somebody else had the same problem which they solved by > > removing > > >> "entire dmd": > http://forum.dlang.org/thread/ejybuwermnentslcy...@forum.dlang.org > > >> Ali > > > > Thanks, that was it. So I guess I have to delete the > > original dmd2 dir > > > before I install each time... didn't use to have to do > > that. > > Normally, it shouldn't be necessary. The splitting of the > datetime package[1] had this effect but I'm not sure why the > installation process can't take care of it. > > Ali > > [1] > http://dlang.org/changelog/2.075.0.html#split-std-datetime > >>> > >>> It _should_ take care of it. The fact that multiple people > >>> have run into this problem and that the solution was to > >>> remove dmd and then reinstall it implies that there's a bug > >>> in the installer. > >>> > >>> - Jonathan M Davis > >> > >> I do not use the installer, I use the zip file. I assumed that > >> everything would be overwritten and any old stuff would simply > >> go unused.. but it seems it doesn't. If the other person used > >> the installer then it is a problem with dmd itself not > >> designed properly and using files that it shouldn't. I simply > >> unzip the zip file in to the dmd2 dir and replace sc.ini... > >> that has been my MO for since I've been trying out dmd2 and > >> only recently has it had a problem. > > > > If you extracted the zip file over the original install, then > > it didn't get rid of std/datetime.d (as extracting a zipfile > > doesn't remove items that exist on the current filesystem but > > aren't in the zipfile). So I can totally see this happening. > > > > I don't know of a good way to solve this except to tell people, > > don't do that. > > > > -Steve > > But the issue was about missing symbols, not anything "extra". If > datatime.d is there but nothing is using it, why should it > matter? Why would it have any effect on the compilation process > and create errors with D telling me something is being used that > isn't? > > dmd shouldn't be picking up extraneous and non-connected files > just for the fun of it. > > Basically, if no "references" escape out side of the D ecosystem, > then there shouldn't be a problem. You ended up with two versions of std.datetime. One was the module, and the other was the package. importing std.datetime could have imported either of them. dmd _should_ generate an error in that case, but I don't know if it does or not. And depending on what you were doing, if you were dealing with previously generated object files rather than fully building your project from scratch, they would have depended on symbols that did not exist anymore, because they were moved to other modules. And in that case, dmd would not have generated an error about conflicting symbols, because the code that was using the symbols had already been compiled. It would have just complained about the missing symbols - which is what you saw. If you'd just make sure that you uninstall the previous version before installing the new one, you wouldn't have to worry about any such problems. The installer would take care of that for you, but if you want to use the zip file, then you're going to have to do it manually, and deleting the directory and then unzipping instead of just unzipping on top of it would take you less time than you've spent complaining about how it should have worked. - Jonathan M Davis
Re: It makes me sick!
On Thursday, 27 July 2017 at 18:47:57 UTC, Adam D. Ruppe wrote: YOU were using it with an `import std.datetime;` line Of course, it is also possible that import was through a dependency of something you used, possibly including the standard library.
Re: It makes me sick!
On Thursday, 27 July 2017 at 18:14:52 UTC, Steven Schveighoffer wrote: On 7/27/17 1:58 PM, FoxyBrown wrote: On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis wrote: On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via Digitalmars-d-learn wrote: On 07/26/2017 09:20 PM, FoxyBrown wrote: >> Somebody else had the same problem which they solved by removing >> >> "entire dmd": >> http://forum.dlang.org/thread/ejybuwermnentslcy...@forum.dlang.org >> >> Ali > > Thanks, that was it. So I guess I have to delete the original dmd2 dir > before I install each time... didn't use to have to do that. Normally, it shouldn't be necessary. The splitting of the datetime package[1] had this effect but I'm not sure why the installation process can't take care of it. Ali [1] http://dlang.org/changelog/2.075.0.html#split-std-datetime It _should_ take care of it. The fact that multiple people have run into this problem and that the solution was to remove dmd and then reinstall it implies that there's a bug in the installer. - Jonathan M Davis I do not use the installer, I use the zip file. I assumed that everything would be overwritten and any old stuff would simply go unused.. but it seems it doesn't. If the other person used the installer then it is a problem with dmd itself not designed properly and using files that it shouldn't. I simply unzip the zip file in to the dmd2 dir and replace sc.ini... that has been my MO for since I've been trying out dmd2 and only recently has it had a problem. If you extracted the zip file over the original install, then it didn't get rid of std/datetime.d (as extracting a zipfile doesn't remove items that exist on the current filesystem but aren't in the zipfile). So I can totally see this happening. I don't know of a good way to solve this except to tell people, don't do that. -Steve But the issue was about missing symbols, not anything "extra". If datatime.d is there but nothing is using it, why should it matter? Why would it have any effect on the compilation process and create errors with D telling me something is being used that isn't? dmd shouldn't be picking up extraneous and non-connected files just for the fun of it. Basically, if no "references" escape out side of the D ecosystem, then there shouldn't be a problem.
Re: It makes me sick!
On Thursday, July 27, 2017 14:14:52 Steven Schveighoffer via Digitalmars-d- learn wrote: > On 7/27/17 1:58 PM, FoxyBrown wrote: > > I do not use the installer, I use the zip file. I assumed that > > everything would be overwritten and any old stuff would simply go > > unused.. but it seems it doesn't. If the other person used the installer > > then it is a problem with dmd itself not designed properly and using > > files that it shouldn't. I simply unzip the zip file in to the dmd2 dir > > and replace sc.ini... that has been my MO for since I've been trying out > > dmd2 and only recently has it had a problem. > > If you extracted the zip file over the original install, then it didn't > get rid of std/datetime.d (as extracting a zipfile doesn't remove items > that exist on the current filesystem but aren't in the zipfile). So I > can totally see this happening. > > I don't know of a good way to solve this except to tell people, don't do > that. Yeah, there are plenty of releases where nothing gets removed, but files do get removed from time to time, so simply extracting the zip on top of the old directory will cause problems at least occasionally. Also, in the case of Linux, an .so is generated with a specific version number in it, so every release has different files. I don't think that Windows currently has anything like that, but it could in the future. So, if you want to use the zip, then you should always remove the old version and not simply overwrite it. - Jonathan M Davis
Re: It makes me sick!
On 7/27/17 1:58 PM, FoxyBrown wrote: On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis wrote: On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via Digitalmars-d-learn wrote: On 07/26/2017 09:20 PM, FoxyBrown wrote: >> Somebody else had the same problem which they solved by removing >> >> "entire dmd": >> http://forum.dlang.org/thread/ejybuwermnentslcy...@forum.dlang.org >> >> Ali > > Thanks, that was it. So I guess I have to delete the original dmd2 dir > before I install each time... didn't use to have to do that. Normally, it shouldn't be necessary. The splitting of the datetime package[1] had this effect but I'm not sure why the installation process can't take care of it. Ali [1] http://dlang.org/changelog/2.075.0.html#split-std-datetime It _should_ take care of it. The fact that multiple people have run into this problem and that the solution was to remove dmd and then reinstall it implies that there's a bug in the installer. - Jonathan M Davis I do not use the installer, I use the zip file. I assumed that everything would be overwritten and any old stuff would simply go unused.. but it seems it doesn't. If the other person used the installer then it is a problem with dmd itself not designed properly and using files that it shouldn't. I simply unzip the zip file in to the dmd2 dir and replace sc.ini... that has been my MO for since I've been trying out dmd2 and only recently has it had a problem. If you extracted the zip file over the original install, then it didn't get rid of std/datetime.d (as extracting a zipfile doesn't remove items that exist on the current filesystem but aren't in the zipfile). So I can totally see this happening. I don't know of a good way to solve this except to tell people, don't do that. -Steve
Re: It makes me sick!
On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis wrote: On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via Digitalmars-d-learn wrote: On 07/26/2017 09:20 PM, FoxyBrown wrote: >> Somebody else had the same problem which they solved by removing >> >> "entire dmd": >> http://forum.dlang.org/thread/ejybuwermnentslcy...@forum.dlang.org >> >> Ali > > Thanks, that was it. So I guess I have to delete the original dmd2 dir > before I install each time... didn't use to have to do that. Normally, it shouldn't be necessary. The splitting of the datetime package[1] had this effect but I'm not sure why the installation process can't take care of it. Ali [1] http://dlang.org/changelog/2.075.0.html#split-std-datetime It _should_ take care of it. The fact that multiple people have run into this problem and that the solution was to remove dmd and then reinstall it implies that there's a bug in the installer. - Jonathan M Davis I do not use the installer, I use the zip file. I assumed that everything would be overwritten and any old stuff would simply go unused.. but it seems it doesn't. If the other person used the installer then it is a problem with dmd itself not designed properly and using files that it shouldn't. I simply unzip the zip file in to the dmd2 dir and replace sc.ini... that has been my MO for since I've been trying out dmd2 and only recently has it had a problem.
Re: Hacking the compiler: Get Scope after some line of function
On Thursday, 27 July 2017 at 11:59:51 UTC, unDEFER wrote: So how to get scope e.g. after line "B b;"? I have found. That in scopes was found symbols from declarations, you must iterate by declarations (DeclarationExp) and add symbols by sc.insert(decexp.declaration);
Re: Profiling after exit()
On Thursday, 27 July 2017 at 14:44:31 UTC, Temtaime wrote: Also there was an issue that profiling doesn't work with multi-threaded apps and leads to a crash. Don't know if it is fixed. Was fixed two years ago: http://forum.dlang.org/post/mia2kf$djb$1...@digitalmars.com
Re: Profiling after exit()
On Thursday, 27 July 2017 at 14:52:18 UTC, Stefan Koch wrote: On Thursday, 27 July 2017 at 14:30:33 UTC, Eugene Wissner wrote: I have a multi-threaded application, whose threads normally run forever. But I need to profile this program, so I compile the code with -profile, send a SIGTERM and call exit(0) from my signal handler to exit the program. The problem is that I get the profiling information only from the main thread, but not from the other ones. [...] You will need to run it single threaded. If you want to use the builtin-profiler. Are there profilers that work well with dmd? valgrind? OProfile?
Re: Profiling after exit()
On Thursday, 27 July 2017 at 14:30:33 UTC, Eugene Wissner wrote: I have a multi-threaded application, whose threads normally run forever. But I need to profile this program, so I compile the code with -profile, send a SIGTERM and call exit(0) from my signal handler to exit the program. The problem is that I get the profiling information only from the main thread, but not from the other ones. [...] You will need to run it single threaded. If you want to use the builtin-profiler.
Re: Profiling after exit()
Also there was an issue that profiling doesn't work with multi-threaded apps and leads to a crash. Don't know if it is fixed.
Re: Profiling after exit()
Exit is not "normal exit" for D programs so, do not use it. Your threads should stop at some point to make able the app exit successfully. There's a "join" method. You can use it with your "done" variable.
Profiling after exit()
I have a multi-threaded application, whose threads normally run
forever. But I need to profile this program, so I compile the
code with -profile, send a SIGTERM and call exit(0) from my
signal handler to exit the program. The problem is that I get the
profiling information only from the main thread, but not from the
other ones.
Is there a way to get the profiling information from all threads
before terminating the program? Maybe some way to finish the
threads gracefully? or manully call "write trace.log"-function
for a thread?
Here is a small example that demonstrates the problem:
import core.thread;
import core.stdc.stdlib;
shared bool done = false;
void run()
{
while (!done)
{
foo;
}
}
void foo()
{
new Object;
}
void main()
{
auto thread = new Thread();
thread.start;
Thread.sleep(3.seconds);
exit(0); // Replace with "done = true;" to get the expected
behaviour.
}
There is already an issue:
https://issues.dlang.org/show_bug.cgi?id=971
The hack was to call trace_term() in internal/trace. call_term()
doesn't exist anymore, I tried to export the static destructor
from druntime/src/rt/trace.d with:
extern (C) void _staticDtor449() @nogc nothrow;
(on my system) and call it manually. I get some more information
this way, but the numbers in the profiling report are still wrong.
Re: It makes me sick!
On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via Digitalmars-d-learn wrote: > On 07/26/2017 09:20 PM, FoxyBrown wrote: > >> Somebody else had the same problem which they solved by removing > >> > >> "entire dmd": > >> http://forum.dlang.org/thread/ejybuwermnentslcy...@forum.dlang.org > >> > >> Ali > > > > Thanks, that was it. So I guess I have to delete the original dmd2 dir > > before I install each time... didn't use to have to do that. > > Normally, it shouldn't be necessary. The splitting of the datetime > package[1] had this effect but I'm not sure why the installation process > can't take care of it. > > Ali > > [1] http://dlang.org/changelog/2.075.0.html#split-std-datetime It _should_ take care of it. The fact that multiple people have run into this problem and that the solution was to remove dmd and then reinstall it implies that there's a bug in the installer. - Jonathan M Davis
Re: unittest blocks not being run inside of class and struct templates
On Tuesday, July 25, 2017 09:31:28 Steven Schveighoffer via Digitalmars-d- learn wrote: > The unfortunate thing is that if you want to have non-templated unit > tests, you have to put them outside the struct itself. This sucks for > documented unit tests, and for tests being close to the thing being > tested. I'd love to have a way to specify that a unit test is really > outside the struct, but still have it written inside. I'm not sure if it > would be accepted though. When there was a discussion that previously (earlier this year, I think), I was talking about updating the DIP on this that I'd created, and Andrei basically said that it was a waste of my time to do so and that it would be rejected. I don't know what Walter's position on it is (though previous discussions on the topic imply that Walter doesn't think that the issue is a big deal), and I don't know what it would take to talk Andrei into it, but I expect that it would require a _very_ well written DIP with very good reasons as to why a language feature was better than the pain of doing something like you did with RedBlackTree. But Andrei certainly seemed to think that doing what you did with RedBlackTree was perfectly acceptable as opposed to disgustingly ugly, albeit better than just letting the tests sit there and get compiled into every instantiation. The DIP I wrote previously suggested using static on the unittest blocks to indicate that they weren't really part of the template, which seemed perfectly reasonable to me, but Timon had a decent argument as to why reusing static didn't make sense. So, we'd need some other sort of attribute to do it, but regardless, IMHO having an attribute of some kind to solve this problem would be light years better than what we have now. Unfortunately, previous discussions on the topic indicate that any DIP on the subject is likely to get rejected, which pisses me off given how ugly the workaround is, but I don't know what to do about it except maybe wait awhile before creating the DIP in the hopes that putting some time between the DIP being proposed and Andrei basically saying that any such DIP would be rejected would make it less likely that he'd remember that and more likely that he'd be receptive to it. However, without something more that shows that it's a serious problem, I question that we stand much chance of convincing him. But maybe I just suck at explaining why this issue is bad enough to merit a language fix and someone else could explain it in a way that would convince him. - Jonathan M Davis
Hacking the compiler: Get Scope after some line of function
Hello! I'm trying to do some strange thing: compile some
Statement (do semantic3 phase) in the scope of other function.
Other function is for example:
auto megafunction()
{
B b;
uint a = 25;
return b;
}
AST of this code looks like:
FuncDeclaration
{
fbody = CompoundStatement
{
ExpStatement
{
exp = DeclarationExp
}
ExpStatement
{
exp = DeclarationExp
}
ReturnStatement;
}
}
So if I'm trying to take fbody._scope, all works correctly (other
functions and templates from this module are declared), but
neither a nor b are declared in this scope.
But exp.declaration._scope is null.
So how to get scope e.g. after line "B b;"?
