Suggestion for an external GC library.
Considering the fact that the D garbage collector still has a lot of room left for improvement. Have we ever considered taking a look at Memory Pool (http://www.ravenbrook.com/project/mps/version/1.111/manual/html/index.html)? The authors claim it is an industrial strength garbage collector/memory pool in use since 1994. Is the license compatible with D?
Re: It's always something
You should keep a record of those anomalies somewhere, it might prove useful as a starting point to investigating problems future problems that might arise. You are right. I think it is a good thing Walter took the time out to write about this. In the absence of better documentation this post might come in handy (we can always use Google).
Re: Is the address-of operator () really needed?
I would add that fptr = function; makes it _clear_ what is going on there, otherwise I would have to go and find what function is... There are two contradictory issues at work here which need to be balanced with each other... 1. While writing code we expect the compiler to understand what we want to do without writing a lot of code. Compiler inference is a boon here. D has some features supporting this (like auto). 2. While reading code and while trying to reason about the program we want the program to be self documenting and simple. Often as is the case with natural languages some redundancy is required to accomplish this. This makes a language verbose and increases the difficulty / effort required for writing programs. We don't have many tools which can help us with item #1 but we do have tools which can help significantly with item #2 (eg. IDEs, static code analyzers etc) so IMHO we should design our languages to help us with item #1. Removing the ampersand is one small step in this direction. Though I agree upfront I have not mastered all the nuances of D to even know if this is possible at all at this point of time.
Re: Is the address-of operator () really needed?
1. It's needed so that you can call it when calling C code. Why can't we just use information from the C function signature to determine when an address needs to be passed? Why is manual intervention required here? 2. Just because ref is often better than a pointer doesn't mean that it's never valuable to be able to pass a pointer to a variable. Passing a pointer may be useful but IMO we should restrict such things to the unsafe context. 3. ref doesn't work with variadic templates very well. Take a look a std.getopt.getopt. It takes pointers, not refs, and there isn't a way to make it take refs. Is it because getopt() is a C function? If it is see my reply to your point #1. I'll admit I do not know enough D to understand what you are saying, some explanation will be helpful. 4. is useful for getting function pointers. What does the function name represent when not used with an ampersand? If it doesn't represent anything then I think the language can be changed to yield an address directly without an ampersand.
Re: Is the address-of operator () really needed?
import std.stdio;
@property f() { writeln(oops); return 0; }
void main() { auto p = f; }
artur
I understand what you are trying to say but I hear parens will
become mandatory soon. This may not be a problem then.
Re: Is the address-of operator () really needed?
On Friday, 1 June 2012 at 15:58:04 UTC, Andrej Mitrovic wrote: On 5/31/12, Jonathan M Davis jmdavisp...@gmx.com wrote: 2. Just because ref is often better than a pointer doesn't mean that it's never valuable to be able to pass a pointer to a variable. 5. And '' documents code better at the call site. I personally refuse to use out/ref arguments because the call site makes it ambiguous whether an argument is passed by reference or not. Please see http://forum.dlang.org/post/ycwrmmvnpdwkonjwo...@forum.dlang.org
Re: Is the address-of operator () really needed?
On Friday, 1 June 2012 at 18:07:12 UTC, Artur Skawina wrote:
On 06/01/12 19:41, Sandeep Datta wrote:
import std.stdio;
@property f() { writeln(oops); return 0; }
void main() { auto p = f; }
artur
I understand what you are trying to say but I hear parens will
become mandatory soon. This may not be a problem then.
No, it's the other way around - parens are accepted now, but
shouldn't be.
The whole point of properties is to behave as fields.
Ok, I overlooked the @property declaration. Sorry about that.
While writing code we expect the compiler to understand what
we want to do without writing a lot of code.
Do you really consider '' to be a lot of code?
Actually no I don't consider it to be a lot of code but I think
it is an annoyance nevertheless...one which I can live with.
Re: Is the address-of operator () really needed?
On Friday, 1 June 2012 at 18:07:12 UTC, Artur Skawina wrote:
On 06/01/12 19:41, Sandeep Datta wrote:
import std.stdio;
@property f() { writeln(oops); return 0; }
void main() { auto p = f; }
artur
I understand what you are trying to say but I hear parens will
become mandatory soon. This may not be a problem then.
No, it's the other way around - parens are accepted now, but
shouldn't be.
The whole point of properties is to behave as fields.
Ok, I overlooked the @property declaration. Sorry about that.
While writing code we expect the compiler to understand what
we want to do without writing a lot of code.
Do you really consider '' to be a lot of code?
Actually no I don't consider it to be a lot of code but I think
it is an annoyance nevertheless...one which I can live with.
Is the address-of operator () really needed?
Hi, I was going through some sample code online and came across the following code fragment... listenHttp(settings, handleRequest); //Where handleRequest is a function My question to you is (as the title says) is the address-of operator () really needed here? Wouldn't it be better to consider handleRequest to be a reference to the actual function? I think this will make the system consistent with the way variables work in D. IMO this will bring functions/delegates closer to being first class objects in D. What do you think? Regards, Sandeep Datta.
Re: XOMB operating system
Yes true...if some one is interested here is a link (https://github.com/SDX2000/helios) to some sample code. Just build by changing to the src directory and running make. It builds a hello world program which can be run in qemu.
Re: Is the address-of operator () really needed?
//fptr = handleRequest; // will not work, because it is understdood as: // fptr = handleRequest(); But do we really need this feature? Typing () does not seem to be too much work besides we can use properties if we really need to drop the brackets. And given the fact that properties have well understood use cases (see http://msdn.microsoft.com/en-us/library/bzwdh01d(VS.71).aspx#cpconpropertyusageguidelinesanchor1) I am not sure using functions as properties is such a good idea. fptr = handleRequest; // This will work if we have only one handleRequest(); // If you uncomment the first one, you are in trouble Can't we use auto-inferencing here to select the right method since fptr has the required type information?
Re: Is the address-of operator () really needed?
On Thursday, 31 May 2012 at 09:58:42 UTC, simendsjo wrote: On Thu, 31 May 2012 11:36:47 +0200, Sandeep Datta datta.sand...@gmail.com wrote: Hi, I was going through some sample code online and came across the following code fragment... listenHttp(settings, handleRequest); //Where handleRequest is a function My question to you is (as the title says) is the address-of operator () really needed here? Wouldn't it be better to consider handleRequest to be a reference to the actual function? I think this will make the system consistent with the way variables work in D. IMO this will bring functions/delegates closer to being first class objects in D. What do you think? It might be because of historical reasons. A long time ago, D allowed calling functions without (), so what if handleRequest returns a function? Should the passed reference be handleRequest or handleRequest()? This issue is still valid for properties as they can be called without (). Thanks for the information! But I think we should use real properties when we need to do that and stop using functions as improvised properties. Please see my response to Dejan Lekic for my argument supporting this claim.
Re: ZeroBUGS debugger for D
I have tried their .deb distribution (x64_86) but I had to upgrade from Ubuntu 11.04 to get it working (because my libc was dated) I am currently using Ubuntu 12.04 (with MATE) FYI. On Wednesday, 30 May 2012 at 16:00:09 UTC, 1100110 wrote: On Fri, 11 May 2012 16:51:59 -0500, SomeDude lovelyd...@mailmetrash.com wrote: On Tuesday, 8 May 2012 at 08:23:38 UTC, Denis Shelomovskij wrote: 08.05.2012 3:50, Walter Bright написал: http://www.reddit.com/r/cpp/comments/tbouj/zerobugs_modular_debugger_for_ccd_including_gui/ Poor ZeroBUGS developer... Looks like he failed to sell his great debugger and decided to make it free. Proof: http://www.zero-bugs.com/2.0/download.html Does anyone have it compiled for Linux 32 bits ? It looks like compiling it is going to be a PITA, as compilation fails almost instantly on my machine... I have never managed to get this to compile correctly. They offered .deb downloads for a while and even that didn't work on any system I tried it on... Does anyone have any experience/advice for getting this to work?
Re: Is the address-of operator () really needed?
But the only reason any of this is happening at all is because of a specific ambiguity that was discovered with the old empty parens are optional approach. Hmm interesting (esp since it works out in favor of what I wanted :) ) but TBH I do not have a problem with leaving the parens out if it does not meddle with the way I'd prefer to use the language. But it seems you can't have the cake and eat it too. Having said that, what is your opinion on dropping the ampersand? To me it looks antiquated and out of place especially since it conjures up images of unsafe pointers in C/C++.
Re: Is the address-of operator () really needed?
If we removed the requirement for the ampersand, along with
requiring parentheses for non-property functions, code which
expected to call the function without parentheses would
silently compile, but not do what was intended.
Consider this...
float handleRequest() {
return 1.0f;
}
float x = handleRequest; //compilation error
or
auto x = handleRequest;
writefln(%f, x); //compilation error
I think we'd get a compile time error for most cases without
significant changes to the compiler. But the edge cases if any
can probably be detected at compile time with modifications to
the compiler.
Here is an edge case (for reference)...
writefln(x);// will now print the address of the function
Re: Is the address-of operator () really needed?
What about: handleRequest; -Steve Yes I have considered that but that should be pretty easy to detect and flag for correction, isn't it? I mean the compiler already knows it is supposed to be a call to the handleRequest function (if it doesn't how will it generate code for it?) so it should just let the user know this syntax is not supported anymore.
Re: Is the address-of operator () really needed?
Nope, i specifically made this example because D makes no difference between two or more functions with different return types. Are you talking about co-variance? Could you please explain what you mean when you say D does not distinguish between return types (possibly by pointing to contexts in which this happens)? If yes then I think this a different case all together. In this case it seems picking the right function is doable, co-variance notwithstanding. Note I am not saying this can be done without making any changes to the compiler/language but whatever changes are required IMO will be small.
Re: Possible bug in the D compiler w.r.t x86_64 ABI calling convention
On Sunday, 20 May 2012 at 11:40:35 UTC, Jacob Carlborg wrote: On 2012-05-19 20:41, Sandeep Datta wrote: Hmm, are there any known work arounds? I am in a fix as I need to use the demios/libclang wrapper but it has several functions which return structs. There are bindings that are more up to date in my DStep project. It also contains some useful wrappers: https://github.com/jacob-carlborg/dstep/tree/master/clang The bindings are in the c directory. Thanks but will your bindings work in 64bit mode? It seems to me some functions are still returning a struct. I think I will have to rebuild llvm+clang in 32bit, right?
Possible bug in the D compiler w.r.t x86_64 ABI calling convention
Hi, I seem to have discovered a bug in the D compiler which is causing it to emit incompatible code with gcc on Ubuntu 11.04 x86_64. I have minimised the code required to reproduce this problem and uploaded it to github, here is the link https://github.com/SDX2000/CFromDTest1. Once you have downloaded it run build to generate the executables. You'll see that the output produced by the d program is different from the output produced by the equivalent c code. I have spent some time on analysing the generated assembly. You'll find annotated assembly code main.d etc highlighting the problem. Basically the problem is that dmd generates code which is not compatible with gcc when a C function returns a struct. Please do let me know if this is a legitimate bug and if I need to file a bug report. Regards, Sandeep Datta.
Re: Possible bug in the D compiler w.r.t x86_64 ABI calling convention
On Saturday, 19 May 2012 at 18:37:20 UTC, David Nadlinger wrote: On Saturday, 19 May 2012 at 18:31:45 UTC, Sandeep Datta wrote: Please do let me know if this is a legitimate bug and if I need to file a bug report. x86_64 struct ABI differences are a known problem and being worked on, a fix will likely be included with the next release. David Hmm, are there any known work arounds? I am in a fix as I need to use the demios/libclang wrapper but it has several functions which return structs.
Re: Possible bug in the D compiler w.r.t x86_64 ABI calling convention
On Saturday, 19 May 2012 at 18:41:28 UTC, Sandeep Datta wrote: On Saturday, 19 May 2012 at 18:37:20 UTC, David Nadlinger wrote: On Saturday, 19 May 2012 at 18:31:45 UTC, Sandeep Datta wrote: Please do let me know if this is a legitimate bug and if I need to file a bug report. x86_64 struct ABI differences are a known problem and being worked on, a fix will likely be included with the next release. David Hmm, are there any known work arounds? I am in a fix as I need to use the demios/libclang wrapper but it has several functions which return structs. Oops...hit send a little too early...I guess building with -m32 should fix this problem, no?
How do I view assembly?
Hi, Is there a way by which I can see the assembly code generated by the D compiler similar to the -S etc switches on GCC? Regards, Sandeep Datta.
Re: How do I view assembly?
Ok, I just saw this http://stackoverflow.com/questions/3592587/digital-mars-d-compiler-acquiring-asm-output But please do let me know if it is still relevant.
Re: How do I view assembly?
On Friday, 18 May 2012 at 14:48:07 UTC, Alex Rønne Petersen wrote: On 18-05-2012 16:46, Sandeep Datta wrote: Hi, Is there a way by which I can see the assembly code generated by the D compiler similar to the -S etc switches on GCC? Regards, Sandeep Datta. Not with DMD. What you have to do is disassemble the file with objdump -D foo.o (add -M intel to maintain your sanity) On Windows, there's a dump tool called dumpobj shipped with DMD IIRC. Wow, that was fast! Many thanks Alex Rønne Petersen.
Re: dereferencing null
No hardware support for them, so no choice. I am just going to leave this here... *Fast Bounds Checking Using Debug Register* http://www.ecsl.cs.sunysb.edu/tr/TR225.pdf
A better way to manage discussions?
Hi Guys, I just wanted to say I am pretty impressed with the revamped D forums. TBH I tried to join in on the conversion many times before the change but the ancient NNTP based approach was just not palatable enough. But needless to say we have come a long way from that. Having said that I have a question for the veterans...have you at any point considered using a publicly hosted discussion forum (like reddit)? I miss the ability to edit and monitor my posts (without spamming my inbox). Also the upvote and downvote buttons can come in handy sometimes too (for example if you did not like this post you could downvote it to oblivion). Regards, Sandeep Datta.
Re: dereferencing null
I would recommend doing what Microsoft does in this case, use SEH (Structured exception handling) on windows i.e. use OS facilities to trap and convert hardware exceptions into software exceptions. See the /EHa flag in the Microsoft C++ compiler. I hope Linux has something similar, then we are all set! ref: http://msdn.microsoft.com/en-us/library/1deeycx5(v=vs.80).aspx On Saturday, 3 March 2012 at 02:51:41 UTC, Walter Bright wrote: On 3/1/2012 8:51 PM, Jonathan M Davis wrote: It's defined. The operating system protects you. Not exactly. It's a feature of the hardware. You get this for free, and your code runs at full speed. Adding in software checks for null pointers will dramatically slow things down.
Re: dereferencing null
It's been there for 10 years, and turns out to be a solution looking for a problem. I beg to differ, the ability to catch and respond to such asynchronous exceptions is vital to the stable operation of long running software. It is not hard to see how this can be useful in programs which depend on plugins to extend functionality (e.g. IIS, Visual Studio, OS with drivers as plugins etc). A misbehaving plugin has the potential to bring down the whole house if hardware exceptions cannot be safely handled within the host application. Thus the inability of handling such exceptions undermines D's ability to support dynamically loaded modules of any kind and greatly impairs modularity. Also note hardware exceptions are not limited to segfaults there are other exceptions like division by zero, invalid operation, floating point exceptions (overflow, underflow) etc. Plus by using this approach (SEH) you can eliminate the software null checks and avoid taking a hit on performance. So in conclusion I think it will be worth our while to supply something like a NullReferenceException (and maybe NullPointerException for raw pointers) which will provide more context than a simple segfault (and that too without a core dump). Additional information may include things like a stacktrace (like Vladimir said in another post) with line numbers, file/module names etc. Please take a look at C#'s exception hierarchy for some inspiration (not that you need any but it's nice to have some consistency across languages too). I am just a beginner in D but I hope D has something like exception chaining in C# using which we can chain exceptions as we go to capture the chain of events which led to failure.
Re: dereferencing null
You can catch it in D (on Windows): This is great. All we have to do now is provide a more specific exception (say NullReferenceException) so that the programmer has the ability to provide a specific exception handler for NullReferenceException etc. I gave it a try on Linux but unfortunately it leads to a segfault (DMD 2.056, x86-64).
Re: dereferencing null
A misbehaving plugin could easily corrupt your process. Destroying data is always much worse than crashing. At this point I usually say memory corruption is not an option for type safe languages but D doesn't really provide runtime type safety guarantees, or does it? I think in the future (D 4.0 or something) we could seriously consider something like proof carrying code etc to take memory/type safety to the next level. People interested in this will be aware of Google's effort in this direction NaCl ( http://code.google.com/p/nativeclient/ )
Re: dereferencing null
1. SEH isn't portable. There's no way to make it work under non-Windows systems. Ok after some digging around it appears (prima facie) that Linux doesn't have anything close to SEH. I am aware of POSIX signals but I am not sure if they work for individual threads in a process. Last I checked the whole process has to be hosed when you receive a segfault and there isn't much you can do about it. I am a Linux newbie but I am almost seriously considering implementing SEH for linux (in the kernel). Any Linux Gurus here who think this is a good idea?
Re: dereferencing null
If you're dealing with plugins from an unknown source, it's a good design to separate plugins and such as entirely separate processes. Then, when one goes down, it cannot bring down anyone else, since there is no shared address space. They can communicate with the OS-supplied interprocess communications API. Yes I think this is a good idea in general but the process/IPC overhead can be substantial if you have a lot of (small) plugins. I think Google chrome uses this trick (among others) to good effect in providing fault tolerance ( http://www.geekosystem.com/google-chrome-hacking-prize/ ).
Re: DWT in Google Summer of Code?
I thing a stable GUI library is very important for D. +1 to that. But I think using using SWT as inspiration for a GUI library may not be the best possible choice. I would like to see an API which uses D well. Small things like using properties instead of getters and setters come to the mind first. I haven't looked at the DWT source code but I suspect it may suffer from some of the same short comings as SWT. I have been looking for a good cross platform GUI library but the choices available so far (Qt, wxWidgets, GTK+) all come from the C++ world (where garbage collection is almost absent) thus entangling memory management issues with the GUI API and its architecture in general. I would love to hear some recommendations on terse and powerful GUI libraries even if they are not cross platform. I'd seriously consider contributing to such a project. On Saturday, 3 March 2012 at 19:54:56 UTC, Mr. Anonymous wrote: Hello, How about improving DWT as part of Google Summer of Code? I thing a stable GUI library is very important for D. What do you think?
