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
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
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
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
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.
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
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
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
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.
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.
//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
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
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
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
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
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
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
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
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.
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
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
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.
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.
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
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
not like this post you
could downvote it to oblivion).
Regards,
Sandeep Datta.
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
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
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
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
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
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
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
33 matches
Mail list logo
