Re: D support in Exuberant Ctags 5.8 for Windows
On Tuesday, 11 November 2014 at 18:56:29 UTC, Sergei Nosov wrote: On Tuesday, 11 November 2014 at 18:44:23 UTC, ANtlord wrote: Wake up dead topic! :) On Tuesday, 25 September 2012 at 04:22:13 UTC, p.crimsonsphere wrote: Hi there. So, anyway, have you found any live link to download Ctags 5.8 working for D programming language? I found here http://pastie.org/971968 and applied it to http://dfrank.ru/ctags581 I downloaded compiler for Ctags, I mean, BCC32 and failed to compile it. If anyone has a Ctags 5.8 or 5.81 for D language, please~ Regards. If it is actually, you can use that https://github.com/snosov1/ctags-d. I wanted to suggest this link as well (snosov1 is me). It is ctags 5.8 with the aforementioned patch applied and few other fixes on top. It's not perfect, but works reasonable. I didn't use Dscanner for that functionality much, but I expect it to have better quality. I use your project right now, and I must say, that works very well. But it does not parse constructors. And it is important. I've created issue in your project about this. I think, it reasonable, talk about this on github.
Re: Connection Problems with forum.dlang.org
On Tuesday, 11 November 2014 at 18:50:15 UTC, Jonathan Marler wrote: I'm still having this issue, this is quite an annoyance. I also have issues with with https://, but with http:// it works fine. Mike
Re: On heap segregation, GC optimization and @nogc relaxing
On Wednesday, 12 November 2014 at 03:13:20 UTC, Rikki Cattermole wrote: [...] yes and no. The ideas is similar, but it is not doable at library level if we want to get safety and the full benefit out of it, as it would require for the compiler to introduce some call to the runtime at strategic places and it does interact with @nogc.
Re: On heap segregation, GC optimization and @nogc relaxing
On Wednesday, 12 November 2014 at 06:16:34 UTC, Walter Bright wrote: On 11/11/2014 6:34 PM, deadalnix wrote: > [...] Thanks for an excellent summary of the problem. I can't just read your solution and know it works, it'll take some time. That is quite difficult to explain with drawing. Maybe I can discuss that with Andrei when he has some time with a whiteboard around.
Re: On heap segregation, GC optimization and @nogc relaxing
On 11/11/2014 6:34 PM, deadalnix wrote: > [...] Thanks for an excellent summary of the problem. I can't just read your solution and know it works, it'll take some time.
Re: std.experimental.logger formal review round 3
On Tuesday, 11 November 2014 at 15:06:49 UTC, Dicebot wrote: https://github.com/Dicebot/phobos/tree/logger-safety I think that should be it for now I could have completely missed some details but I took sometime to look at the code after reading that the logger was holding a lock during the write operation. I noticed the following lines. One shared Logger: https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d#L1696 One global function that references that shared Logger: https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d#L292 And more importantly a Mutex that is always acquired when writing: https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d#L1035 Does this mean that if I use this library on a machine that has 32 cores, 100s of threads and 1000s of fiber only one thread/fiber can write at a time no matter the concrete implementation of my logger? Am I missing something or isn't this a non-starter? Thanks, -Jose
Re: GC: memory collected but destructors not called
On 11/11/14 22:41, Steven Schveighoffer wrote: At this point, I am not super-concerned about this. I cannot think of any bullet-proof way to ensure that struct dtors for structs that were meant only for stack variables can be called correctly from the GC. Isn't "structs meant only for stack variables" a semantic thing? The D compiler cannot possibly know. Shouldn't that be the programmer's choice? This pull doesn't change that, and it does have some nice new features that we do need for other reasons. In other words, putting a struct in the GC heap that was written to be scope-destroyed is an error before and after this pull. Before the pull, the dtor doesn't run, which is wrong, and after the pull the dtor may cause race issues, which is wrong. So either way, it's wrong :) I disagree. The first is wrong. The second is a corner case the programmer needs to be aware of, and account for. The difference is that, in the first case, the programmer is left with no tools to fix the problem, while in the second case this is simply a bug in the program (which, like I said in another email, also happens with the current implementation when the struct is inside a class). In other words, the second case exposes a second (more direct and more likely to be handled) path to an already existing problem, while the first puts the programmer up against a new problem with no work around. Shachar
Re: GC: memory collected but destructors not called
On 10/11/14 16:19, Steven Schveighoffer wrote: Only classes call dtors from the GC. Structs do not. There are many hairy issues with structs calling dtors from GC. Most struct dtors expect to be called synchronously, and are not expecting to deal with multithreading issues. Note that structs inside classes WILL call dtors. How is this any different? If one should not be allowed, how is the other okay? Shachar
Re: On heap segregation, GC optimization and @nogc relaxing
On 12/11/2014 3:34 p.m., deadalnix wrote: Hi all, I want to get back on the subject of ownership, lifetime and propose some solution, but before, propose to state the problem in a way that haven't seen before (even if I have no doubt some have came to the same conclusion in the past). The problem at hand is double: memory management and thread safety. Number one has been a hot topic for ages, and number 2 has become very over the past years, to the widespreading of multicores CPU. The problem at hand here is ownership of data. There are 3 roads you can go about it: - immutability and GC. Effectively, these 2 technique allow you to get rid of ownership. There are advantages and drawbacks i'm going to discuss later. - Being unsafe and rely on convention. This is the C++ road (and a possible road in D). It allow to implement almost any wanted scheme, but come at great cost for the developer. - Annotations. This is the Rust road. It also come a great cost for the developer, as some schemes may be non trivial to express granted the type system, but, contrary to the C++ road, is safe. These approach all have some very nice things going on for them, but also some killer scenarios. Immutability+GC allow to have safety while keeping interfaces simple. That is of great value. It also come with some nice goodies, in the sense that is it easy and safe to shared data without bookkeeping, allowing one to fit more in cache, and reduce the amount of garbage created. Most text processing apps fall into this category and this is why D is that good at them. Another big goodies is that many lock free algorithm become possible. Once you remove the need for bookkeeping of ownership many operations can be implemented in an atomic manner. Additionally, it is possible to implement various GC optimization on immutable heap, which make the GC generally more efficient. But the cost is also real. For some use case, this mean having a large amount of garbage generated (Carmack wrote a piece on haskell were he mention the disastrous effect that having a framebuffer immutable would have: you'd have to clone it everytime you draw in it, which is a no go). GC also tend to cause unpredictable runtime characteristics, which programs with real time constraint can have hard time to deal with. Relying on convention has the advantage that any scheme can be implemented without constraint, while keeping interface simple. The obvious drawback is that it is time consuming and error prone. It also make a lot of things unclear, and dev choose the better safe than sorry road. That mean excessive copying to make sure one own the data, which is wasteful (in term of work for the copy itself, garbage generation and cache pressure). If this must be an option locally for system code, it doesn't seems like this is the right option at program scale and we do it in C++ simply because we have to. Finally, annotations are a great way to combine safety and speed, but generally come at a great cost when implenting uncommon ownership strategies where you ends up having to express complex lifetime and ownership relations. Ideally, we want to map with what the hardware does. So what does the hardware do ? Multicore CPU have various cores, each of them having layers of cache. Cache is organized in cache line and each cache line can be in various modes. Actual system are quite complex and deal with problems we are not very interesting here (like writeback) but the general idea is that every cache line is owned with different modes. Either the cache line is owned by a single core and can be written to, or the cache line shared by several cores, each of them having a local copy of the line, but none of them can write to. There is an internal bus where cores can exchange cache line with each other and messages to acquire cache line in read or read/write mode. That mean CPU are good at thread local read/write, shared immutable and transfer of ownership from one core to the other. They are bad at shared writable data (as effectively, the cache line will have to bounce back and forth between cores, and all memory access will need to be serialized instead of performed out of order). In that world, D has a bizaro position were it use a combination of annotations (immutable, shared) and GC. Ultimately, this is a good solution. Using annotation for common cases, fallback on GC/unsafe code when these annotations fall short. Before going into why it is fallign short, a digression on GC and the benefits of segregating the heap. In D, the heap is almost segregated in 3 groups: thread local, shared and immutable. These group are very interesting for the GC: - Thread local heap can be collected while disturbing only one thread. It should be possible to use different strategy in different threads. - Immutable heap can be collected 100% concurrently without any synchronization with the program. - Shared heap is the only one that require disturbing the whole prog
Re: On heap segregation, GC optimization and @nogc relaxing
On Wednesday, 12 November 2014 at 02:34:55 UTC, deadalnix wrote: Hi all, I want to get back on the subject of ownership, lifetime and propose some solution, but before, propose to state the problem in a way that haven't seen before (even if I have no doubt some have came to the same conclusion in the past). The problem at hand is double: memory management and thread safety. Number one has been a hot topic for ages, and number 2 has become very over the past years, to the widespreading of multicores CPU. The problem at hand here is ownership of data. There are 3 roads you can go about it: - immutability and GC. Effectively, these 2 technique allow you to get rid of ownership. There are advantages and drawbacks i'm going to discuss later. - Being unsafe and rely on convention. This is the C++ road (and a possible road in D). It allow to implement almost any wanted scheme, but come at great cost for the developer. - Annotations. This is the Rust road. It also come a great cost for the developer, as some schemes may be non trivial to express granted the type system, but, contrary to the C++ road, is safe. These approach all have some very nice things going on for them, but also some killer scenarios. Immutability+GC allow to have safety while keeping interfaces simple. That is of great value. It also come with some nice goodies, in the sense that is it easy and safe to shared data without bookkeeping, allowing one to fit more in cache, and reduce the amount of garbage created. Most text processing apps fall into this category and this is why D is that good at them. Another big goodies is that many lock free algorithm become possible. Once you remove the need for bookkeeping of ownership many operations can be implemented in an atomic manner. Additionally, it is possible to implement various GC optimization on immutable heap, which make the GC generally more efficient. But the cost is also real. For some use case, this mean having a large amount of garbage generated (Carmack wrote a piece on haskell were he mention the disastrous effect that having a framebuffer immutable would have: you'd have to clone it everytime you draw in it, which is a no go). GC also tend to cause unpredictable runtime characteristics, which programs with real time constraint can have hard time to deal with. Relying on convention has the advantage that any scheme can be implemented without constraint, while keeping interface simple. The obvious drawback is that it is time consuming and error prone. It also make a lot of things unclear, and dev choose the better safe than sorry road. That mean excessive copying to make sure one own the data, which is wasteful (in term of work for the copy itself, garbage generation and cache pressure). If this must be an option locally for system code, it doesn't seems like this is the right option at program scale and we do it in C++ simply because we have to. Finally, annotations are a great way to combine safety and speed, but generally come at a great cost when implenting uncommon ownership strategies where you ends up having to express complex lifetime and ownership relations. Ideally, we want to map with what the hardware does. So what does the hardware do ? Multicore CPU have various cores, each of them having layers of cache. Cache is organized in cache line and each cache line can be in various modes. Actual system are quite complex and deal with problems we are not very interesting here (like writeback) but the general idea is that every cache line is owned with different modes. Either the cache line is owned by a single core and can be written to, or the cache line shared by several cores, each of them having a local copy of the line, but none of them can write to. There is an internal bus where cores can exchange cache line with each other and messages to acquire cache line in read or read/write mode. That mean CPU are good at thread local read/write, shared immutable and transfer of ownership from one core to the other. They are bad at shared writable data (as effectively, the cache line will have to bounce back and forth between cores, and all memory access will need to be serialized instead of performed out of order). In that world, D has a bizaro position were it use a combination of annotations (immutable, shared) and GC. Ultimately, this is a good solution. Using annotation for common cases, fallback on GC/unsafe code when these annotations fall short. Before going into why it is fallign short, a digression on GC and the benefits of segregating the heap. In D, the heap is almost segregated in 3 groups: thread local, shared and immutable. These group are very interesting for the GC: - Thread local heap can be collected while disturbing only one thread. It should be possible to use different strategy in different threads. - Immutable heap can be collected 100% concurrently without any sync
Re: C++ overloaded operators and D
On Tuesday, 11 November 2014 at 22:26:48 UTC, IgorStepanov wrote:
Now D provides very powerfull means to link C++ code with D.
However D doesn't allow to call C++ overloaded operators.
It's very annoying, because C++ code may don't provide
non-operator analogues.
What we know about C++ overloadable operators? Overloaded
operator in C++ is a trivial function/method with special name.
Thus operator[](int) differs from op_index(int) function only
by mangle.
C++ OO have a different behaviour from D OO (for example C++
allows different < and > operator overloads or static function
fro binary operators), thus we should avoud the temptation of
map C++ OOs to D OOs, or back.
Also D provides a pragma(mangle) which allows to redefine
symbol mangle. It takes a string argument and redefine mangle
to it:
pragma(mangle, "foo") void bar();//bar.mangleof == foo
I suggest to modify pragma(mangle) to support C++ operators.
If argument of this pragma is identifier (for example
cppOpAdd), the pragma applied to extern(C++) function or
method, compiler mangle the function in accordance with this
identifier.
//C++
struct Foo
{
int& operator[](int);
//another fields
};
//D
extern(C++) struct Foo
{
pragma(mangle, cppOpIndex) ref int op_index(int);
//another fields
}
//using:
Foo f;
f.op_index(1)++; //OK, op_index is linked with Foo::operator[]
f[1]++; //Error, no special behaviour for op_index
I think this approach is simple, doesn't modify the language,
can be easily implemented and usefull. Destroy!
Why would you want to go that road ? Souldn't extern(C++) struct
mangle this the right way by themselves ?
On heap segregation, GC optimization and @nogc relaxing
Hi all, I want to get back on the subject of ownership, lifetime and propose some solution, but before, propose to state the problem in a way that haven't seen before (even if I have no doubt some have came to the same conclusion in the past). The problem at hand is double: memory management and thread safety. Number one has been a hot topic for ages, and number 2 has become very over the past years, to the widespreading of multicores CPU. The problem at hand here is ownership of data. There are 3 roads you can go about it: - immutability and GC. Effectively, these 2 technique allow you to get rid of ownership. There are advantages and drawbacks i'm going to discuss later. - Being unsafe and rely on convention. This is the C++ road (and a possible road in D). It allow to implement almost any wanted scheme, but come at great cost for the developer. - Annotations. This is the Rust road. It also come a great cost for the developer, as some schemes may be non trivial to express granted the type system, but, contrary to the C++ road, is safe. These approach all have some very nice things going on for them, but also some killer scenarios. Immutability+GC allow to have safety while keeping interfaces simple. That is of great value. It also come with some nice goodies, in the sense that is it easy and safe to shared data without bookkeeping, allowing one to fit more in cache, and reduce the amount of garbage created. Most text processing apps fall into this category and this is why D is that good at them. Another big goodies is that many lock free algorithm become possible. Once you remove the need for bookkeeping of ownership many operations can be implemented in an atomic manner. Additionally, it is possible to implement various GC optimization on immutable heap, which make the GC generally more efficient. But the cost is also real. For some use case, this mean having a large amount of garbage generated (Carmack wrote a piece on haskell were he mention the disastrous effect that having a framebuffer immutable would have: you'd have to clone it everytime you draw in it, which is a no go). GC also tend to cause unpredictable runtime characteristics, which programs with real time constraint can have hard time to deal with. Relying on convention has the advantage that any scheme can be implemented without constraint, while keeping interface simple. The obvious drawback is that it is time consuming and error prone. It also make a lot of things unclear, and dev choose the better safe than sorry road. That mean excessive copying to make sure one own the data, which is wasteful (in term of work for the copy itself, garbage generation and cache pressure). If this must be an option locally for system code, it doesn't seems like this is the right option at program scale and we do it in C++ simply because we have to. Finally, annotations are a great way to combine safety and speed, but generally come at a great cost when implenting uncommon ownership strategies where you ends up having to express complex lifetime and ownership relations. Ideally, we want to map with what the hardware does. So what does the hardware do ? Multicore CPU have various cores, each of them having layers of cache. Cache is organized in cache line and each cache line can be in various modes. Actual system are quite complex and deal with problems we are not very interesting here (like writeback) but the general idea is that every cache line is owned with different modes. Either the cache line is owned by a single core and can be written to, or the cache line shared by several cores, each of them having a local copy of the line, but none of them can write to. There is an internal bus where cores can exchange cache line with each other and messages to acquire cache line in read or read/write mode. That mean CPU are good at thread local read/write, shared immutable and transfer of ownership from one core to the other. They are bad at shared writable data (as effectively, the cache line will have to bounce back and forth between cores, and all memory access will need to be serialized instead of performed out of order). In that world, D has a bizaro position were it use a combination of annotations (immutable, shared) and GC. Ultimately, this is a good solution. Using annotation for common cases, fallback on GC/unsafe code when these annotations fall short. Before going into why it is fallign short, a digression on GC and the benefits of segregating the heap. In D, the heap is almost segregated in 3 groups: thread local, shared and immutable. These group are very interesting for the GC: - Thread local heap can be collected while disturbing only one thread. It should be possible to use different strategy in different threads. - Immutable heap can be collected 100% concurrently without any synchronization with the program. - Shared heap is the only one that req
Re: X86 COFF format static libraries is very important for d, how to use them? -ms32coff?
You have to compile druntime and phobos with the x86 compiler aswell. Otherwise the C files in the library are built for the wrong architecture. So you should be fine if you use "x86" intead of "amd64" in the line above. Sorry,get the same error. will create a.lib and a.exp druntime32mscoff.lib(dmain2_560_47b.obj):error LNK2019:Unresolved external symbol _getErrno,the symbol is referenced in __d_run_main phobos32mscoff.lib(errno_229_226.obj):error LNK2001:Unresolved external symbol _getErrno a.exe:fatal error LNK1120:An unresolved external symbol.
C++ overloaded operators and D
Now D provides very powerfull means to link C++ code with D.
However D doesn't allow to call C++ overloaded operators.
It's very annoying, because C++ code may don't provide
non-operator analogues.
What we know about C++ overloadable operators? Overloaded
operator in C++ is a trivial function/method with special name.
Thus operator[](int) differs from op_index(int) function only by
mangle.
C++ OO have a different behaviour from D OO (for example C++
allows different < and > operator overloads or static function
fro binary operators), thus we should avoud the temptation of map
C++ OOs to D OOs, or back.
Also D provides a pragma(mangle) which allows to redefine symbol
mangle. It takes a string argument and redefine mangle to it:
pragma(mangle, "foo") void bar();//bar.mangleof == foo
I suggest to modify pragma(mangle) to support C++ operators.
If argument of this pragma is identifier (for example cppOpAdd),
the pragma applied to extern(C++) function or method, compiler
mangle the function in accordance with this identifier.
//C++
struct Foo
{
int& operator[](int);
//another fields
};
//D
extern(C++) struct Foo
{
pragma(mangle, cppOpIndex) ref int op_index(int);
//another fields
}
//using:
Foo f;
f.op_index(1)++; //OK, op_index is linked with Foo::operator[]
f[1]++; //Error, no special behaviour for op_index
I think this approach is simple, doesn't modify the language, can
be easily implemented and usefull. Destroy!
Re: GC: memory collected but destructors not called
On 11/11/14 2:46 PM, Rainer Schuetze wrote: On 10.11.2014 15:19, Steven Schveighoffer wrote: Now, imagine you wanted to put this on the GC heap, and the GC would call struct dtors. And let's say the program is multi-threaded. First, the memory referred to by t isn't guaranteed to be alive, it could have already been finalized and freed. Second, the thread that calls the destructor may not be the thread that owns t. This means that two threads could potentially be calling t.inc() or t.dec() at the same time, leading to race conditions. So, would you object to actually call the destructor for GC collected structs? I don't think that threading problems in the implmentation of the destructor should prohibit this. The reference count in your example also doesn't work for heap allocated structs that are never collected or for structs inside classes. I think in general, it's a problem of the expectation of where structs will live. It's obvious we know classes will be on the heap, so we can write those dtors accordingly. Most struct dtors are written for when the struct is on the stack. The way around this is to have 2 functions for destruction -- as Tango does. One is called during synchronous destruction (i.e. when a struct goes out of scope, or when destroy is called), and the other is called during both synchronous and asynchronous destruction (when the GC is collecting). But even that solution does not allow the struct that I wrote to properly deal with the GC. If the struct has a reference to GC memory, it CANNOT access it during GC destruction to decrement the count, as the memory may be gone. It is why all the claims that we can accomplish what we want with reference counting backed by the GC all never seem to satisfy my doubts. The pull request is almost ready to be merged, please chime in: https://github.com/D-Programming-Language/druntime/pull/864 At this point, I am not super-concerned about this. I cannot think of any bullet-proof way to ensure that struct dtors for structs that were meant only for stack variables can be called correctly from the GC. This pull doesn't change that, and it does have some nice new features that we do need for other reasons. In other words, putting a struct in the GC heap that was written to be scope-destroyed is an error before and after this pull. Before the pull, the dtor doesn't run, which is wrong, and after the pull the dtor may cause race issues, which is wrong. So either way, it's wrong :) I also am strapped for free cycles to review such PRs. I trust you guys know what you are doing :) -Steve
Re: Inspecting GC memory/stats
On 11.11.2014 08:36, Iain Buclaw wrote: Hi, I find myself wondering what do people use to inspect the GC on a running process? Last night, I had a look at a couple of vibe.d servers that had been running for a little over 100 days. But the same code, but one used less (or not at all). Given that the main app logic is rather simple, and things that may be otherwise held in memory (files) are offloaded onto a Redis server. I've have thought that it's consumption would have stayed pretty much stable. But to my surprise, I found that the server that is under more (but not heavy) use is consuming a whooping 200MB. Initially I had tried to see if this could be shrunk in some way or form. Attached gdb to the process, called gc_minimize(), gc_collect() - but it didn't have any effect. The GC allocates pools of memory in increasing size. It starts with 1 MB, then adds 3MB for every new pool. (Numbers might be slightly different depending on the druntime version). These pools are then used to service any allocation request. gc_minimize can only return memory to the system if all the allocation in a pool are collected, which is very unlikely. When I noticed gc_stats with an informative *experimental* warning, I thought "lets just run it anyway and see what happens"... SEGV. Wonderful. I suspect calling gc_stats from the debugger is "experimental" because it returns a struct. With a bit of casting, you might by able to call "_gc.getStats( *cast(GCStats*)some_mem_adr );" instead. As I'm probably going to have to wait 100 days for the apparent leak (I'm sure it is a leak though) to show itself again, does anyone have any nice suggestions whether or not to confirm this memory is just being held and never freed by the GC? Iain.
Re: GC: memory collected but destructors not called
On 10.11.2014 15:19, Steven Schveighoffer wrote: Now, imagine you wanted to put this on the GC heap, and the GC would call struct dtors. And let's say the program is multi-threaded. First, the memory referred to by t isn't guaranteed to be alive, it could have already been finalized and freed. Second, the thread that calls the destructor may not be the thread that owns t. This means that two threads could potentially be calling t.inc() or t.dec() at the same time, leading to race conditions. So, would you object to actually call the destructor for GC collected structs? I don't think that threading problems in the implmentation of the destructor should prohibit this. The reference count in your example also doesn't work for heap allocated structs that are never collected or for structs inside classes. The pull request is almost ready to be merged, please chime in: https://github.com/D-Programming-Language/druntime/pull/864
Re: X86 COFF format static libraries is very important for d,how to use them? -ms32coff?
On 11.11.2014 14:46, FrankLike wrote: I suspect you are compiling the druntime/phobos library with the 64-bit VC compiler. Make sure cl.exe is the compiler targeting 32-bit when running "make -fwin64.mak MODEL=m32mscoff". I've done it as you said:compiling the druntime/phobos library with the 64-bit VC compiler.and cl.exe is the compiler. OPEN:%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" amd64 You have to compile druntime and phobos with the x86 compiler aswell. Otherwise the C files in the library are built for the wrong architecture. So you should be fine if you use "x86" intead of "amd64" in the line above.
Re: D support in Exuberant Ctags 5.8 for Windows
On Tuesday, 11 November 2014 at 18:44:23 UTC, ANtlord wrote: Wake up dead topic! :) On Tuesday, 25 September 2012 at 04:22:13 UTC, p.crimsonsphere wrote: Hi there. So, anyway, have you found any live link to download Ctags 5.8 working for D programming language? I found here http://pastie.org/971968 and applied it to http://dfrank.ru/ctags581 I downloaded compiler for Ctags, I mean, BCC32 and failed to compile it. If anyone has a Ctags 5.8 or 5.81 for D language, please~ Regards. If it is actually, you can use that https://github.com/snosov1/ctags-d. I wanted to suggest this link as well (snosov1 is me). It is ctags 5.8 with the aforementioned patch applied and few other fixes on top. It's not perfect, but works reasonable. I didn't use Dscanner for that functionality much, but I expect it to have better quality.
Re: Connection Problems with forum.dlang.org
On Tuesday, 11 November 2014 at 00:59:59 UTC, Jonathan Marler wrote: I started having issues today connecting to forum.dlang.org from the proxy server we use at work (I work at HP). I've never had this problem before today. I can connect if I use a 3rd party proxy server (such as https://hide.me/en/proxy). I captured a wireshark trace and I'm just not getting any response from the initial HTTP request. I get the ACK from the request but never get any response. I've been trying it all day and it hasn't worked. I first tried using different proxy servers and it seems that all the HP proxy servers aren't working. So, my best guess is that the forum.dlang.org server might be blocking or limiting packets from ip addresses it gets too many requests from. We have a variety of proxies we can use to connect outside our private network, I've tried three of them and they all can't connect. Here's there host names and ip addresses: 1. proxy-txn.austin.hp.com (16.85.175.70) 2. proxy.houston.hp.com (16.85.88.10) 3. web-proxy.corp.hp.com (16.85.175.150) I don't know who manages the dlang servers, but if someone sees this could you grep the logs/error logs for these ip addresses and see if they are being blocked in some way? There are alot of machines behind these ip addresses so maybe the server thinks it might be getting DOS'd from these ip addresses, when in reality, it's just alot of machines using these ip addresses as proxy connections. Thanks. P.S. I didn't post this using my regular login because I don't want to login through the 3rd party proxy server I'm connecting through. I'm still having this issue, this is quite an annoyance. Can someone tell me who to contact for this? Feel free to send me an email at johnnymar...@gmail.com I'm looking to talk to whoever manages the dlang servers. This problem occurs on forum.dlang.org and wiki.dlang.org, it does not happen when connecting to dlang.org Thanks.
Re: D support in Exuberant Ctags 5.8 for Windows
Wake up dead topic! :) On Tuesday, 25 September 2012 at 04:22:13 UTC, p.crimsonsphere wrote: Hi there. So, anyway, have you found any live link to download Ctags 5.8 working for D programming language? I found here http://pastie.org/971968 and applied it to http://dfrank.ru/ctags581 I downloaded compiler for Ctags, I mean, BCC32 and failed to compile it. If anyone has a Ctags 5.8 or 5.81 for D language, please~ Regards. If it is actually, you can use that https://github.com/snosov1/ctags-d. I want to ask about Dscanner. Does it provide same formats as ctags. I use ctags with --excmd=pattern --fields=nksSa and output with them is different of Dscanner's output with key --ctags. Sorry, if my english is not clear.
Re: DIP68: Adding @nogc to types
On Tuesday, 11 November 2014 at 17:56:50 UTC, David Nadlinger wrote: On Tuesday, 11 November 2014 at 17:53:43 UTC, David Nadlinger wrote: Let's focus work on finally fixing bug 2834 instead. (https://issues.dlang.org/show_bug.cgi?id=2834 – "Struct Destructors are not called by the GC, but called on explicit delete". To me, this seems to be the proper fix for your problem.) I would prefer to move away from calling destructors from the GC, and introducing finalizers instead, to clean up the confusion.
Re: Why is `scope` planned for deprecation?
Dicebot: ixid: The ship will have sailed by the time it's ready to fly (gloriously mixed metaphors), this would seem like such a fundamental issue with a big knock-on effect on everything else that it should surely be prioritized higher than that? I am aware you're not the one setting priorities. =) It is going to take such long time not because no one considers it important but because designing and implementing such system is damn hard. Prioritization does not make a difference here. I agree it's a very important topic (more important/urgent than the GC, also because it reduces the need of the GC). But I think Walter thinks this kind of change introduces too much complexity in D (despite it may eventually become inevitable for D once Rust becomes more popular and programmers get used to that kind of static enforcement). Regarding the design and implementation difficulties, is it possible to ask for help to one of the persons that designed (or watched closely design) the similar thing for Rust? Bye, bearophile
Re: DIP68: Adding @nogc to types
On Tuesday, 11 November 2014 at 17:53:43 UTC, David Nadlinger wrote: Let's focus work on finally fixing bug 2834 instead. (https://issues.dlang.org/show_bug.cgi?id=2834 – "Struct Destructors are not called by the GC, but called on explicit delete". To me, this seems to be the proper fix for your problem.)
Re: Strengthening contract
On Tuesday, 11 November 2014 at 15:31:07 UTC, Kagamin wrote:
http://forum.dlang.org/post/jftnpqyahnwacgkms...@forum.dlang.org
c:\D\import\dfl\button.d(381): Error: function
dfl.button.Button.text cannot have
e an in contract when overriden function
dfl.control.Control.text
does not have an in contract
This is the line 381:
override void text(Dstring txt) // setter
in
{
if(txt.length)
assert(!this.image, "Button image with text not supported");
}
body
{
super.text = txt;
}
But if a button can't display image with text by design, it's
its contract, that text can't be set with image, while the base
class has no such restriction. What does it mean, DbC is
incompatible with inheritance?
Contracts are a tool for enforcing the Liskov substitution
principle(http://en.wikipedia.org/wiki/Liskov_substitution_principle).
What you are trying to do violates the LSP because I can't set
the text of a Control if what I have in hand happens to be it's
subclass, Button.
Now, I'm not saying that you shouldn't do that assert - I think
the best-practices work better as rules of thumb than as sacred
religious rules - but since contracts are modeled after the LSP
they are probably not the right tool for this job...
Re: DIP68: Adding @nogc to types
On Monday, 10 November 2014 at 12:59:14 UTC, Tomer Filiba wrote: http://wiki.dlang.org/DIP68 To be honest, I don't think that this DIP adds significant value to the language. Generally, you (as in a language/library implementor) need to assume that *any* struct with a non-trivial destructor relies on proper finalization anyway. Let's focus work on finally fixing bug 2834 instead. David
Re: shared libraries on OS X
On 2014-11-11 15:05, Jacob Carlborg wrote: The first step would be to implement native TLS, see this issue [1]. BTW, the reason to implement native TLS is because otherwise we need to implement basically what the dynamic linker is already doing for TLS our self. Since it would be nice to have native TLS support anyway I thought that was a better idea. -- /Jacob Carlborg
Re: Why is `scope` planned for deprecation?
On Tuesday, 11 November 2014 at 16:54:10 UTC, ixid wrote: On Tuesday, 11 November 2014 at 15:29:49 UTC, Dicebot wrote: But this is very complicated topic and may take years to fly. The ship will have sailed by the time it's ready to fly (gloriously mixed metaphors), this would seem like such a fundamental issue with a big knock-on effect on everything else that it should surely be prioritized higher than that? I am aware you're not the one setting priorities. =) It is going to take such long time not because no one considers it important but because designing and implementing such system is damn hard. Prioritization does not make a difference here.
Re: Why is `scope` planned for deprecation?
On Tuesday, 11 November 2014 at 15:29:49 UTC, Dicebot wrote: But this is very complicated topic and may take years to fly. The ship will have sailed by the time it's ready to fly (gloriously mixed metaphors), this would seem like such a fundamental issue with a big knock-on effect on everything else that it should surely be prioritized higher than that? I am aware you're not the one setting priorities. =)
Re: extern(C) in druntime
On 11/11/14 11:01 AM, Dicebot wrote: On Monday, 10 November 2014 at 23:22:00 UTC, Sean Kelly wrote: On Monday, 10 November 2014 at 23:08:55 UTC, Logan Capaldo wrote: So just to be clear, there are _some_ legitimate uses of extern (C) in druntime, yes? rt_init/rt_term, rt_loadLibrary, thread_init(? think this one can be bootstrapped from D code), ...? Yes. There are a few functions meant to be callable from C code: rt_init, rt_term, thread_attachThis, thread_detachThis, etc. These could either be exposed as wrappers on top of extern (D) functions or left as-is. Well this is exactly what makes somewhat uneasy about making the change myself - it isn't immediately obvious which functions are legitimately extern(C) and which have it only for mangling / forward declaration. I think make the PR, and we can debate which ones shouldn't be changed. I would also at least mark these ones that shouldn't be changed as "intended to be called from C/C++" with a comment to prevent accidental changes in the future. -Steve
Re: extern(C) in druntime
On Monday, 10 November 2014 at 23:22:00 UTC, Sean Kelly wrote: On Monday, 10 November 2014 at 23:08:55 UTC, Logan Capaldo wrote: So just to be clear, there are _some_ legitimate uses of extern (C) in druntime, yes? rt_init/rt_term, rt_loadLibrary, thread_init(? think this one can be bootstrapped from D code), ...? Yes. There are a few functions meant to be callable from C code: rt_init, rt_term, thread_attachThis, thread_detachThis, etc. These could either be exposed as wrappers on top of extern (D) functions or left as-is. Well this is exactly what makes somewhat uneasy about making the change myself - it isn't immediately obvious which functions are legitimately extern(C) and which have it only for mangling / forward declaration.
Re: DIP68: Adding @nogc to types
I don't see the merit of this DIP and it clearly introduces whole new meaning of @nogc attribute (which needs a really good justification to pull it off)
Re: D 2.066.1: Assertion failure: '0' on line 2022 in file 'mtype.c'
For the reference https://issues.dlang.org/show_bug.cgi?id=13714
Strengthening contract
http://forum.dlang.org/post/jftnpqyahnwacgkms...@forum.dlang.org
c:\D\import\dfl\button.d(381): Error: function
dfl.button.Button.text cannot have
e an in contract when overriden function dfl.control.Control.text
does not have an in contract
This is the line 381:
override void text(Dstring txt) // setter
in
{
if(txt.length)
assert(!this.image, "Button image with text not supported");
}
body
{
super.text = txt;
}
But if a button can't display image with text by design, it's its
contract, that text can't be set with image, while the base class
has no such restriction. What does it mean, DbC is incompatible
with inheritance?
Re: Why is `scope` planned for deprecation?
This is a bit complicated. Originally intention was to deprecate scope variables (scope var = new Class) completely and make people switch to std.typecons.scoped - primarily because of how fragile and inflexible its implementation was (can't have scope fields in aggregates for example) However it never actually got deprecated and still kind of works with no warnings printed by compiler. Also I remember Daniel mentioning that he uses it extensively in DDMD project which, unfortunately, makes full deprecation unlikely. There is however a long standing desire to re-purpose `scope` as qualifier for lifetime/ownership semantics which could have made current uses simply a subset of full `scope` implementation. But this is very complicated topic and may take years to fly.
Re: std.experimental.logger formal review round 3
On Monday, 10 November 2014 at 18:32:03 UTC, Robert burner Schadek wrote: On Monday, 10 November 2014 at 17:03:31 UTC, Dicebot wrote: There are also some more @safe changes need, I hope to provide another branch with those soon enough (~tomorrow) thank you https://github.com/Dicebot/phobos/tree/logger-safety I think that should be it for now
Re: DIP68: Adding @nogc to types
On 2014-11-11 14:19, Tomer Filiba wrote: __trait(getFunctionAttributes, F) -- but it returns flags that are applicable only to function attributes Hmm, yeah. Using that trait on a type might be a bit weird. -- /Jacob Carlborg
Re: shared libraries on OS X
On 2014-11-11 11:42, John Colvin wrote: what's the status? I tried building druntime with 'make -f posix.mak dll' and got src/rt/sections.d(52): Error: static assert (is(typeof(__error) == void* function())) is false I'd be happy to put in some work to improve the situation, but a brief overview of the status quo would be useful. The first step would be to implement native TLS, see this issue [1]. The next step that would probably be to look at the changes in druntime made for Linux to add support for shared libraries. I think a major part of that is in rt_sections.d or similar. There were some changes to the compiler as well, adding some hooks when a dynamic library is loaded. But that shouldn't be needed on OS X since the dynamic linker have native support for this. [1] https://issues.dlang.org/show_bug.cgi?id=9476 -- /Jacob Carlborg
Re: X86 COFF format static libraries is very important for d, how to use them? -ms32coff?
I suspect you are compiling the druntime/phobos library with the 64-bit VC compiler. Make sure cl.exe is the compiler targeting 32-bit when running "make -fwin64.mak MODEL=m32mscoff". I've done it as you said:compiling the druntime/phobos library with the 64-bit VC compiler.and cl.exe is the compiler. OPEN:%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" amd64 set DM_HOME=h:\D cd %DM_HOME%\dmd2\src\druntime make -fwin64.mak MODEL=32mscoff get the druntime32mscoff.lib and gcstub32mscoff.obj do that on phobos,and get the phobos32mscoff.lib. Then,I use it: OPEN:%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86 set DM_HOME=h:\D set path=%path%;%DM_HOME%\dmd2\windows\bin; set lib=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib;C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\lib;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib;h:\D\dmd2\windows\libms32coff dmd -c -m32mscoff a.d link /machine:x86 aUser32.lib shell32.lib ole32.lib oleAut32.lib gdi32.lib comctl32.lib comdlg32.lib advapi32.lib uuid.lib ws2_32.lib druntime32mscoff.lib gcstub32mscoff.obj phobos32mscoff.lib /LARGEADDRESSAWARE:NO but get the error as that ↑ Thank you.
Re: DIP68: Adding @nogc to types
No, a trait or template to find out if a function is @nogc. __trait(getFunctionAttributes, F) -- but it returns flags that are applicable only to function attributes -tomer
Re: DIP68: Adding @nogc to types
I'm not at all sure that how a type is allocated should be
part of the type itself. There are an infinite way things can
be allocated.
Nitpick: it's about memory _management_, not _allocation_.
Exactly. I don't care much *where* the object lives, as long as
it has deterministic properties.
But the DIP is also underspecified. E.g., is it allowed to
embed a @nogc type in a class? If not, what if that class again
is wrapped in std.typecons.Scoped?
I thought I covered it there, but just to be clear, @nogc should
be inherited by the containing type, so if a class has a @nogc
member, the class itself becomes @nogc. For example:
@nogc struct Handle {...}
class Mandle {Handle shmandle;}
auto m1 = new Mandle(); // does not compile
scoped!Mandle m2; // great success
-tomer
Re: The relationship of invariants and alias this
On 11/11/14 6:48 AM, ZombineDev wrote:
AFAIU, even if you had a getter in the alias this:
---
import std.stdio;
struct ValueRestrictedInteger(int lowerBound, int upperBound) {
int value;
auto ref get() { return value; }
alias get this;
this (int rhs) { value = rhs; }
invariant() {
assert (value >= lowerBound && value <= upperBound);
}
void forDemonstrationOnly() {}
}
---
It would still not work:
---
unittest {
ValueRestrictedInteger!(0, 100) x = 0;
x -= 100; //is probably lowered to something like this:
// 1) invariant();
// 2) int* __temp = &x.value; // this is what get() does
// 3) invariant();
// 4) *__temp = *temp - 100;
//...
}
---
Obviously, 4) will not trigger the invariant because it doesn't call any
public functions.
Correct, the only real solution is to wrap with the actual operators and
opDispatch.
-Steve
Re: Program logic bugs vs input/environmental errors
On Saturday, 1 November 2014 at 16:42:31 UTC, Walter Bright wrote: My ideas are what are implemented on airplanes. For components, not for a system. Nobody said a word against component design, it's systems that people want to be able to design, yet you prohibit it. I didn't originate these ideas, they come from the aviation industry. You're original in claiming it is the only working solution, but aviation industry proves error resilient systems are possible and successful, even though you claim their design is unsound and unusable. Yet you praise them, acknowledging their success, which makes your claims ever so ironical. Recall that I was employed as an engineer working on flight critical systems design for the 757. This is how problem decomposition works: you don't need to understand the whole system to work on a component. On Sunday, 2 November 2014 at 17:53:45 UTC, Walter Bright wrote: Kernel mode code is the responsibility of the OS system, not the app. Suddenly safety becomes not the top priority. If it can't always be the priority, there should be a choice of priorities, but you deny that choice. It's a matter of compliance with reality. Whatever way you design the language, can you change reality that way? I don't see why possibility of choice prevents anything.
Re: The relationship of invariants and alias this
AFAIU, even if you had a getter in the alias this:
---
import std.stdio;
struct ValueRestrictedInteger(int lowerBound, int upperBound) {
int value;
auto ref get() { return value; }
alias get this;
this (int rhs) { value = rhs; }
invariant() {
assert (value >= lowerBound && value <= upperBound);
}
void forDemonstrationOnly() {}
}
---
It would still not work:
---
unittest {
ValueRestrictedInteger!(0, 100) x = 0;
x -= 100; //is probably lowered to something like this:
// 1) invariant();
// 2) int* __temp = &x.value; // this is what get() does
// 3) invariant();
// 4) *__temp = *temp - 100;
//...
}
---
Obviously, 4) will not trigger the invariant because it doesn't
call any public functions.
Re: Wrong order of shared static dtors
Filed as: https://issues.dlang.org/show_bug.cgi?id=13712
shared libraries on OS X
what's the status? I tried building druntime with 'make -f posix.mak dll' and got src/rt/sections.d(52): Error: static assert (is(typeof(__error) == void* function())) is false I'd be happy to put in some work to improve the situation, but a brief overview of the status quo would be useful.
Re: Wrong order of shared static dtors
Am Mon, 10 Nov 2014 10:06:01 -0500 schrieb Steven Schveighoffer : > I don't know about your specific issue. But I do know how the runtime > calls static ctors/dtors because I rewrote that part a few years ago. > > First, any ctors/dtors in a specific module are called in the order they > appear in the file. > > Second, the compiler records 3 things about a module: > 1. Is it a standalone module? That is, does it not import any other modules. > 2. If not, what modules does it import. > 3. Does it have any dtors or ctors (it has a flag for each kind) > > When run, the runtime uses this information to build a graph of the > ordering to call the static ctors. If it detects any cycles in that > graph, where module A imports directly or indirectly module B, and > module B imports directly or indirectly module A, and both of them have > the *same kind* of static ctor or dtor, then it errors and refuses to > run the program (I'm sure all of you have seen this error). > > Now, if that doesn't happen, it has a list of modules, of what imports > whatever else. And it can call the static ctors in the order of that > graph making sure dependent modules are constructed first. It does this > separately for shared and unshared ctors/dtors. Standalone modules are > called first, and are not included in the search for cycles. > > On program/thread termination, it calls the dtors in the opposite order. > > Two things that it CANNOT detect: > > 1. If you circumvent the module system to call functions in static > ctor/dtors using extern(C). > 2. If you establish any dependencies during runtime, such as pushing > into module A's global array a reference to a module B global object, > without module A or B importing each other. It won't know to call module > A's dtor first. > > I'm guessing the latter is what you are having issues with. > > -Steve Thank you for the explanation. I guess I'm dealing with case 2. But then, how is D supposed to deal with this situation? Naturally the concepts of "external resources" and "singleton" are orthogonal and the two modules _should_ not know about each other. Granted, a D singleton class is never going to be part of an external system resource ;), but building on the idea, whenever we have static dtors in templates, we risk that the template arguments introduce a "hidden" dependency. The type is `T` and Singleton.d does not import the module that `T` came from, which would transitively import Resource.d and make sure static dtors in there are deferred until after Singleton.d's dtors were called. Effectively templated module dtors are crashes waiting to be triggered! The compiler must add any modules as dependencies that are passed in through template arguments as if the concrete type was directly used with any required import. -- Marco
Re: The relationship of invariants and alias this
On Tuesday, 11 November 2014 at 08:18:36 UTC, angel wrote: Wait ! "x.value -= 100;" would call the invariant ? Alias this only rewrites your expression: "x -= 100;" becomes "x.value -= 100;" No method is called. Then there is no reason (is there ?) to call the invariant. If you would create getter/setter properties ... Intriguing - thanks :). Looks like you found the reason for the current implementation; what you've written is the "lowering" of alias this. From a semantic perspective though, we are claiming that "value *is* this"; there is an IsA relationship and I'd argue that the invariant should still apply because we are modifying "this", in a way. I totally see where you're coming from though; that's why I wanted to open the floor for discussion as to what the more desirable behavior is.
Re: The relationship of invariants and alias this
Wait ! "x.value -= 100;" would call the invariant ? Alias this only rewrites your expression: "x -= 100;" becomes "x.value -= 100;" No method is called. Then there is no reason (is there ?) to call the invariant. If you would create getter/setter properties ...
