Re: manual memory management
On 1/8/2013 11:42 PM, Mehrdad wrote: (True, it wouldn't give you the power of a systems language, but that's quite obviouly not my point -- the point is that it's a _perfectly possible_ memory-safe language which we made, so I don't understand Walter's comment about a GC being "required" for a memory-safe language.) The misunderstanding is you are not considering reference counting as a form of GC. It is.
Re: manual memory management
On Wednesday, 9 January 2013 at 08:14:35 UTC, Walter Bright wrote: On 1/8/2013 11:42 PM, Mehrdad wrote: (True, it wouldn't give you the power of a systems language, but that's quite obviouly not my point -- the point is that it's a _perfectly possible_ memory-safe language which we made, so I don't understand Walter's comment about a GC being "required" for a memory-safe language.) The misunderstanding is you are not considering reference counting as a form of GC. It is. So you would say that C++ code (which uses reference counting) uses garbage collection?
Re: manual memory management
On Wednesday, 9 January 2013 at 02:49:34 UTC, Rob T wrote: On Tuesday, 8 January 2013 at 23:30:34 UTC, David Nadlinger wrote: On Tuesday, 8 January 2013 at 23:12:43 UTC, Rob T wrote: The only major thing that concerns me is the lack of proper shared library support. I hope this omission is resolved soon. What do you need it for? Runtime loading of D shared objects? Or just linking to them (i.e. binding by ld/dyld at load time)? I'm trying to collect data on real-world use cases resp. expectations right now. David I *really* need runtime loading of plug-in code for a server application. This allows the server code to remain untouched while allowing extensions to be added on by a 3rd party. Runtime linked shared libs are also nice to have for the simple reason that shared libraries can be updated (to a point) without having to rebuild and relink all applications that make use of the libraries. There are pros and cons to static vs dynamic linking, but definitely both are useful to have. I'm very surprised that not too many people have been screaming for dynamic linking and runtime loading. It's very hard for me to imagine not having the feature because it's so darn useful and an essential feature if your strategy is to allow 3rd parties to extend an application without hacking at the source code. If there's another better way, I'd sure like to know about it! --rt You can write plugins without dynamic loading, they just are a bit more cumbersome to write. Like I used to do back in the late 90's, by making use of UNIX's IPC. The IPC to use (shared memory, pipes, mailbox, sockets) depends on what is required from the plugin. With shared memory being the closest to what dynamic loading achieves. Of course this raises another set of issues like: - Take care what happens when a plugin dies - Too many loaded plugins can stress the scheduler - You might have synchronization issues when using shared memory - It is a bit more painful to code for This is the school of thought of the Plan9/Go guys and most operating system micro-kernel architectures. -- Paulo
Re: manual memory management
Am 09.01.2013 02:59, schrieb H. S. Teoh: On Wed, Jan 09, 2013 at 12:21:05AM +0100, deadalnix wrote: On Tuesday, 8 January 2013 at 16:12:41 UTC, Benjamin Thaut wrote: My impression so far: No one who is writing a tripple A gaming title or engine is only remotly interested in using a GC. Game engine programmers almost do anything to get better performance on a certain plattform. There are really elaborate taks beeing done just to get 1% more performance. And because of that, a GC is the very first thing every serious game engine programmer will kick. You have to keep in mind that most games run at 30 FPS. That means you only have 33 ms to do everything. Rendering, simulating physics, doing the game logic, handling network input, playing sounds, streaming data, and so on. Some games even try to get 60 FPS which makes it even harder as you only have 16 ms to compute everything. Everything is performance critical if you try to achive that. That is a real misrepresentation of the reality. Such people avoid the GC, but simply because they avoid all kind of allocation altogether, preferring allocating up-front. Interesting, that sounds like the heapless programming of the old, old days where you map out everything beforehand, and limit yourself to use only what is there. Y'know, with fixed-sized arrays, stacks, etc., fixed maximum number of objects, etc.. Not a bad approach if you want to tightly control everything. Well, except that you do have preallocation, presumably during runtime at startup (and between game levels, perhaps?), so it's not as rigid, but during gameplay itself this is pretty much what it amounts to, right? T No its not heapless programming. You just try to avoid allocations during gameplay. But they are done if needed (or if there is no time to do it the "clean" way) Kind Regards Benjamin Thaut
Re: manual memory management
Am 09.01.2013 00:21, schrieb deadalnix: That is a real misrepresentation of the reality. Such people avoid the GC, but simply because they avoid all kind of allocation altogether, preferring allocating up-front. But in the end they still don't want a GC, correct? Kind Regards Benjamin Thaut
Re: manual memory management
On Wednesday, 9 January 2013 at 08:28:44 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 08:14:35 UTC, Walter Bright wrote: On 1/8/2013 11:42 PM, Mehrdad wrote: (True, it wouldn't give you the power of a systems language, but that's quite obviouly not my point -- the point is that it's a _perfectly possible_ memory-safe language which we made, so I don't understand Walter's comment about a GC being "required" for a memory-safe language.) The misunderstanding is you are not considering reference counting as a form of GC. It is. So you would say that C++ code (which uses reference counting) uses garbage collection? Yes. Reference counting is a poor man's form of garbage collection and almost every book about garbage collection starts by introducing reference counting, before moving on to mark-and-sweep and all the remaining algorithms. Both fall under the umbrella of automatic memory management. Oh, a bit off topic but are you aware that C++11 has a GC API? -- Paulo
Re: manual memory management
On Wednesday, 9 January 2013 at 08:51:47 UTC, Paulo Pinto wrote: On Wednesday, 9 January 2013 at 08:28:44 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 08:14:35 UTC, Walter Bright wrote: On 1/8/2013 11:42 PM, Mehrdad wrote: (True, it wouldn't give you the power of a systems language, but that's quite obviouly not my point -- the point is that it's a _perfectly possible_ memory-safe language which we made, so I don't understand Walter's comment about a GC being "required" for a memory-safe language.) The misunderstanding is you are not considering reference counting as a form of GC. It is. So you would say that C++ code (which uses reference counting) uses garbage collection? Yes. You (or Walter I guess) are the first person I've seen who calls C++ garbage collected. Oh, a bit off topic but are you aware that C++11 has a GC API? Yes, but I'm not aware of any code which claims to have written a GC for it. -- Paulo
Re: manual memory management
On Wednesday, January 09, 2013 00:30:32 David Nadlinger wrote: > On Tuesday, 8 January 2013 at 23:12:43 UTC, Rob T wrote: > > The only major thing that concerns me is the lack of proper > > shared library support. I hope this omission is resolved soon. > > What do you need it for? Runtime loading of D shared objects? Or > just linking to them (i.e. binding by ld/dyld at load time)? I'm > trying to collect data on real-world use cases resp. expectations > right now. You pretty much need shared libraries for plugins (so, runtime loading of shared libraries), whereas all dynamic linking really does is save disk space. So, I'd consider the loading of shared libraries at runtime to be a necessity for some types of projects whereas for pretty much anything other than embedded systems (which will probably want to use C anyway), the saved disk space part is fairly useless. With the stuff I work on at work, I couldn't use D precisely because we require plugins (think of trying to do something like gstreamer but without plugins - it doesn't work very well). Now, much as I love D, I wouldn't try and get the stuff that I'm doing at work moved over to D, because it's a large, existing, C++ code base which works quite well, and I don't think that switching to D would be worth it, but anyone looking to do similar projects in D would be out of luck right now. - Jonathan M Davis
Re: manual memory management
On Wednesday, 9 January 2013 at 08:54:11 UTC, Mehrdad wrote: Yes, but I'm not aware of any code which claims to have written a GC for it. A precise* GC that is, not a conservative one.
Re: manual memory management
On Wednesday, January 09, 2013 09:54:10 Mehrdad wrote: > You (or Walter I guess) are the first person I've seen who calls > C++ garbage collected. I sure wouldn't call that garbage collection - not when there's no garbage collector. But Walter has certainly called it that from time to time. I think that the other term that Paulo just used - automatic memory management - is far more accurate. - Jonathan M Davis
Re: manual memory management
On 1/9/2013 1:00 AM, Jonathan M Davis wrote: > On Wednesday, January 09, 2013 09:54:10 Mehrdad wrote: >> You (or Walter I guess) are the first person I've seen who calls >> C++ garbage collected. > > I sure wouldn't call that garbage collection - not when there's no garbage > collector. But Walter has certainly called it that from time to time. There's a collector, it's in the refcount decrement (a little simplified): if (refcount == 0) free(obj); Granted, it's terribly simple, but it's there.
Re: manual memory management
09-Jan-2013 12:54, Mehrdad пишет: On Wednesday, 9 January 2013 at 08:51:47 UTC, Paulo Pinto wrote: On Wednesday, 9 January 2013 at 08:28:44 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 08:14:35 UTC, Walter Bright wrote: On 1/8/2013 11:42 PM, Mehrdad wrote: (True, it wouldn't give you the power of a systems language, but that's quite obviouly not my point -- the point is that it's a _perfectly possible_ memory-safe language which we made, so I don't understand Walter's comment about a GC being "required" for a memory-safe language.) The misunderstanding is you are not considering reference counting as a form of GC. It is. So you would say that C++ code (which uses reference counting) uses garbage collection? Yes. You (or Walter I guess) are the first person I've seen who calls C++ garbage collected. That's a stretch - IMHO I'd call the language garbage collected iff it is the default way language-wise (e.g. if C++ new was ref-counted I'd call C++ garbage collected). This way D is garbage collected language because the language default is GC. -- Dmitry Olshansky
Re: manual memory management
On Wednesday, 9 January 2013 at 09:08:40 UTC, Brad Roberts wrote: On 1/9/2013 1:00 AM, Jonathan M Davis wrote: On Wednesday, January 09, 2013 09:54:10 Mehrdad wrote: You (or Walter I guess) are the first person I've seen who calls C++ garbage collected. I sure wouldn't call that garbage collection - not when there's no garbage collector. But Walter has certainly called it that from time to time. There's a collector, it's in the refcount decrement (a little simplified): if (refcount == 0) free(obj); Granted, it's terribly simple, but it's there. Sure, it's there. The problem I have with it is that this line of reasoning makes no sense of what Walter said, which was: "A GC is *required* if you want to have a language that guarantees memory safety." No matter how he defines the word GC, I _STILL_ don't see how this is true. I can perfectly well imagine a language which allows you to use integers as _handles_ to objects (perfectly _manual_ management of _everything_), and which gives you access to their fields via external functions. The language need not give you any direct access to memory, making everything perfectly safe. I really don't think Walter's statement made any sense whatsoever.
Re: manual memory management
On Wednesday, 9 January 2013 at 09:30:41 UTC, deadalnix wrote: On Wednesday, 9 January 2013 at 07:33:24 UTC, Rob T wrote: On Wednesday, 9 January 2013 at 07:23:57 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 07:22:51 UTC, deadalnix wrote: Well, you CAN indeed, create a dumbed down language that is memory safe and don't require a GC. Yeah, that's 1 of my 2 points. The other one you still ignored: the GC doesn't bring much to the table. (Re C# Java etc.) There is a point being made here that is perfectly valid. There is a form of memory leak that a GC can never catch, such as when when memory is allocated and simply never deallocated by mistake due to a persistent "in use" pointer that should have been nulled but wasn't. As long as you have the pointer around, the memory leak is not GC's. "The _leak_ is not GC'd"? In addition, the GC itself may fail to deallocated freed memory or even free live memory by mistake. I've seen bugs described to that effect. There simply is no panacea to the memory leak problem. What a GC does do, is free the programmer from a ton of tedium, and even allow for constructs that would normally not be practical to implement, but it can never guarantee anything more than that. False pointer are mostly solved by using 64bits pointers. See : http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using-non-precise-gc/ Re-read what he wrote, you completely missed what we're saying.
Re: manual memory management
On Wednesday, 9 January 2013 at 07:33:24 UTC, Rob T wrote: On Wednesday, 9 January 2013 at 07:23:57 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 07:22:51 UTC, deadalnix wrote: Well, you CAN indeed, create a dumbed down language that is memory safe and don't require a GC. Yeah, that's 1 of my 2 points. The other one you still ignored: the GC doesn't bring much to the table. (Re C# Java etc.) There is a point being made here that is perfectly valid. There is a form of memory leak that a GC can never catch, such as when when memory is allocated and simply never deallocated by mistake due to a persistent "in use" pointer that should have been nulled but wasn't. As long as you have the pointer around, the memory leak is not GC's. In addition, the GC itself may fail to deallocated freed memory or even free live memory by mistake. I've seen bugs described to that effect. There simply is no panacea to the memory leak problem. What a GC does do, is free the programmer from a ton of tedium, and even allow for constructs that would normally not be practical to implement, but it can never guarantee anything more than that. False pointer are mostly solved by using 64bits pointers. See : http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using-non-precise-gc/
Re: manual memory management
On Wednesday, 9 January 2013 at 07:42:39 UTC, Mehrdad wrote: Also might mention, we implemented a compiler for a subdialect of Python (including full closures) for our compilers course, which the compiler subsequently translated to C++. GC wasn't required (we were allowed to never deallocate), but since I didn't feel like doing that I added reference counting using a lot of shared_ptr's and intrusive_ptr's. I also added a GC just for the sake of catching cyclic references, but it was just that -- everything was reference counted, so if you never had cyclic references, the GC _never_ kicked in, period. This is a very valid way to manage things in D as well, remember that you have GC.free available.
Re: manual memory management
On Wednesday, 9 January 2013 at 08:46:20 UTC, Paulo Pinto wrote: You can write plugins without dynamic loading, they just are a bit more cumbersome to write. Like I used to do back in the late 90's, by making use of UNIX's IPC. The IPC to use (shared memory, pipes, mailbox, sockets) depends on what is required from the plugin. With shared memory being the closest to what dynamic loading achieves. Of course this raises another set of issues like: - Take care what happens when a plugin dies - Too many loaded plugins can stress the scheduler - You might have synchronization issues when using shared memory - It is a bit more painful to code for This is the school of thought of the Plan9/Go guys and most operating system micro-kernel architectures. Such a solution cause the same kind of issue for the runtime. For instance, how to handle the garbage collection of the shared memory ? What do happen if I get the typeid of an object of a type that only exists in the plugin in the core app ? It quite don't solve problems we have.
Re: Updating other compiler frontends [was D 1.076 and 2.061 release]
On 8 January 2013 23:15, Walter Bright wrote: > On 1/8/2013 5:49 AM, Iain Buclaw wrote: > >> Would a target.h header be fine for this? Or do you have somewhere else >> in mind. >> > > I think a target.h/target.c would be a good addition. In general, I'd like > to see all #ifdef's removed from the main dmd source code. Host and target > specific behaviors should be abstracted out, like what root/port.h attempts > to do. > > OK, well I've started it off with Target::typesize, ::typealign, ::fieldalign. Maybe also ::fieldoffset, though gdc currently uses the D frontend code to get that that with no known issues (only way to find out is when we start expanding D2 to more targets). And left it with the comment: This file contains a data structure that describes a back-end target. At present it is incomplete, but in future it should grow to contain most or all target machine and target O/S specific information. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: manual memory management
On Wednesday, 9 January 2013 at 09:01:46 UTC, Jonathan M Davis wrote: On Wednesday, January 09, 2013 09:54:10 Mehrdad wrote: You (or Walter I guess) are the first person I've seen who calls C++ garbage collected. I sure wouldn't call that garbage collection - not when there's no garbage collector. But Walter has certainly called it that from time to time. I think that the other term that Paulo just used - automatic memory management - is far more accurate. - Jonathan M Davis I used to think that. But I was convinced otherwise when considering carefully the cost and benefit involved. I so no interest in make the difference anymore. The technical solution you choose for GC imply some tradeoff, and it amazing to see how the fact that you refcount or trace don't matter that much. If you want a tracing collector to behave more like reference counting, you'll need to add barriers, so you ends up with the same cost to get the same benefit. Same goes for variations around reference counting, or any mix of both.
Re: manual memory management
On Wednesday, 9 January 2013 at 09:43:01 UTC, deadalnix wrote: The technical solution you choose for GC imply some tradeoff, and it amazing to see how the fact that you refcount or trace don't matter that much. If you want a tracing collector to behave more like reference counting, you'll need to add barriers, so you ends up with the same cost to get the same benefit. A single 100-ms pause is not equivalent to 10,000 0.1-ms pauses for all apps. Just because they have the "same cost" doesn't necessarily imply they're equal.
Re: manual memory management
On Wednesday, 9 January 2013 at 09:50:25 UTC, Mehrdad wrote: A single 100-ms pause is not equivalent to 10,000 0.1-ms pauses for all apps. Just because they have the "same cost" doesn't necessarily imply they're equal. You can have pauseless tracing GC, at the price of barrier + more floating garbage. Reference counting tend to create big pauses when deallocating as objects tends to dies in group. You can solve that issue by delaying cascading deallocation, which cause more floating garbage.
Re: manual memory management
On Wednesday, 9 January 2013 at 10:07:42 UTC, deadalnix wrote: Reference counting tend to create big pauses when deallocating as objects tends to dies in group. I don't get it... it's slower to deallocate a bunch of objects together with refcounting than to deallocate all of them individually over a longer period of time?
Re: manual memory management
Am 09.01.2013 11:09, schrieb Mehrdad: On Wednesday, 9 January 2013 at 10:07:42 UTC, deadalnix wrote: Reference counting tend to create big pauses when deallocating as objects tends to dies in group. I don't get it... it's slower to deallocate a bunch of objects together with refcounting than to deallocate all of them individually over a longer period of time? could be - think of an large hierarchy of objects which tends to take some time to deconstruct ... a background gc could be better for your application speed in this situation - by the cost of smaller pause and more resource usage or better - what is the real reason for Java and C# for using garbage collectors if ref-counting will be always better (except cyclic stuff)?
Re: manual memory management
On Wednesday, 9 January 2013 at 10:09:42 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 10:07:42 UTC, deadalnix wrote: Reference counting tend to create big pauses when deallocating as objects tends to dies in group. I don't get it... it's slower to deallocate a bunch of objects together with refcounting than to deallocate all of them individually over a longer period of time? *YOU* mentionned pause time. In regard of pause time, yes, it is very different.
Re: manual memory management
On Wednesday, 9 January 2013 at 10:13:03 UTC, deadalnix wrote: On Wednesday, 9 January 2013 at 10:09:42 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 10:07:42 UTC, deadalnix wrote: Reference counting tend to create big pauses when deallocating as objects tends to dies in group. I don't get it... it's slower to deallocate a bunch of objects together with refcounting than to deallocate all of them individually over a longer period of time? *YOU* mentionned pause time. In regard of pause time, yes, it is very different. Yes I did, but I didn't realize you were talking about a background GC, sorry. Yeah, if you can have a background GC that can keep up with your needs, then the world is great. Trouble is, I don't see how that can be true for a intensive applications like games.
Re: manual memory management
On Wednesday, 9 January 2013 at 10:14:07 UTC, dennis luehring wrote: Am 09.01.2013 11:09, schrieb Mehrdad: On Wednesday, 9 January 2013 at 10:07:42 UTC, deadalnix wrote: Reference counting tend to create big pauses when deallocating as objects tends to dies in group. I don't get it... it's slower to deallocate a bunch of objects together with refcounting than to deallocate all of them individually over a longer period of time? could be - think of an large hierarchy of objects which tends to take some time to deconstruct ... a background gc could be better for your application speed in this situation - by the cost of smaller pause and more resource usage Come to think of it, C++ allocators are meant for exactly this: throwing away an entire batch of objects in 1 go. Beats GCs any day. or better - what is the real reason for Java and C# for using garbage collectors if ref-counting will be always better (except cyclic stuff)? Pretty sure the only reason C#/Java use a GC _is_ for cyclic stuff, and that's it. If you have any other reasons please show me a benchmark that shows a GC being faster than the equivalent refcounted code (I've seen lots of talks in theory about how it _COULD_ be different but never seen any examples in practice; would love to see one).
Re: manual memory management
On Wednesday, 9 January 2013 at 10:21:29 UTC, Mehrdad wrote: Come to think of it, C++ allocators are meant for exactly this s/are meant for/are used for/
Re: manual memory management
On Wednesday, 9 January 2013 at 10:19:24 UTC, Mehrdad wrote: Yes I did, but I didn't realize you were talking about a background GC, sorry. Yeah, if you can have a background GC that can keep up with your needs, then the world is great. Trouble is, I don't see how that can be true for a intensive applications like games. You are changing the subject discussed every 2 posts. I'm loosing my time here, that will be my last answer to you. For a game, latency is more important than actual performance. You prefers very much to guarantee 60fps than to have 100fps but with some frame that may take 200ms to compute. At this game, stop the world GC and reference counting are very bad as both causes large pauses. A concurrent GC is a viable option, granteed you don't generate an insane amount of garbage (which is problematic whatever the memory management used anyway). It is even a good way to increase parralelism in the program and to better exploit the resource of a multicore machine. In fact, most code critical in video games avoid memory allocation altogether.
Re: dlangspec.pdf?
On Wed, Jan 9, 2013 at 2:05 AM, Walter Bright wrote: > I'd still like to see it done as a phobos module. Maybe an enhancement > request? So, this should: - take a .ddoc file for macro definition, or a [name, code] range of pairs. - read an input range - this range can be a standard D file, a .dd or whatever. That means parsing D comments... - find any macro definition - find any $(NAME Args,) call, expand it recursively. Repeat until nothing changes anymore. This should be done lazily (through the input range interface), in case the user want to stop before the end. - output the result as a range. What I'm not clear about, is: if the input is a D source file, should the expander strip any D code from it? Should this return a full-fledged documentation (ie, find the documented symbols...) or just blindly expand DDoc macros.
Re: dlangspec.pdf?
On Wed, Jan 9, 2013 at 12:57 AM, Andrei Alexandrescu
wrote:
> Yah, though note that these macros were only necessary because I was doing
> unusual stuff subheadings for TABLE_3ROWS and multiline paragraph for
> TABLE_2ROWS. If special stuff is not required you can use TABLE2 for up to
> 10 columns.
Oh, I did not see that, that's good to know. This should cover most needs.
>> I also like your use of the `listings` package. How did you 'disable'
>> the automatic colouring DMD insert in code samples?
>
>
> I defined these guys:
>
> D_COMMENT=$0
> D_STRING=$0
> D_KEYWORD=$0
Simple and elegant :)
You introduce `listings`as a dependency. I guess it's a very common
package, that should not cause problems. Maybe syntax highlighting can
be disabled if LaTeX does not find listings.
> I reached a sort of weird conclusion that ddoc is a redoubtable
> documentation source format. (I'm not sure whether it's better than Markdown
> or not as I'm not very fluent with Markdown.) One great thing about ddoc is
> that macros are infinitely flexible, and the expansion rules are not as
> weird as other macro systems such as M4.
The thing is, markdown is just a mark-up language: it's 'passive': no
function, no expansion. I agree having some 'programmability' is nice.
LaTeX is showing its age there. Ddoc has the merit of being
wonderfully simple concerning its macro expansion algorithm.
But markdown is widely used, if only for sites like Github or StackOverflow.
I have code somewhere to produce a document using D only. That gave me
access to the entire D power, so it's the other part of the spectrum.
auto doc = document( title("A title"),
section(...),
section(...),
section(...)
);
string latex = doc.as!"LaTeX";
string html = doc.as!"HTML";
and so on. Still embryonic and not a priority for me right now.
And, I'm slowly assembling small D parsers for markdown, xml, (a very
limited subset of) LaTeX for a project I call Dialect, that would
offer limited source-to-source translation for markup languages. Ddoc
is also a target, but you just showed it can fend for itself quite
well :)
> The table use case is telling - as soon as I needed a special table form I
> could just encode that as a macro. I think with Markdown you get to generate
> one kind of table but if you want to fine-tune any particular table you just
> can't.
Exactly. It's not a programming language. Maybe people use templates for that.
Re: Official DMD compiler written in D
On 01/08/2013 10:06 PM, Philippe Sigaud wrote:
...
Isn't SDC also in D? (Bernard Helyer and friends)
https://github.com/bhelyer/SDC
Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the
past, but did not provide any link to it.
Yes, it is in D. Nothing is released yet. It needs to be polished a
little so that there are no known embarrassing shortcomings anymore.
(eg. the parser cannot parse extern(...) declarations in alias
declarations yet, and I need to finish making a minor tweak to how
template instances are analyzed in order to get circular dependency
detection to work reliably. Furthermore, examples like the following are
currently rejected, while I want it to work:
enum x = "enum xx = q{int y = 0;};";
struct S{
mixin(xx);
mixin(x);
}
:1:6: error: declaration of 'xx' smells suspiciously fishy
enum xx = q{int y = 0;};
^~
mxin.d:4:11: note: this lookup should have succeeded if it was valid
mixin(xx);
^~
It shouldn't be a too large change, as eg. this already works:
struct S{
enum z = y;
enum x = "enum xx = q{immutable y = 123;};";
mixin(xx);
mixin(x);
static assert(z == 123);
}
(DMD chokes on both.)
Furthermore, I need to implement exceptions, modules, and some parts of
compile time reflection + tons of really small features. (Where all
ambiguities and contradictions are detected according to well-defined
rules instead of resolved or choked on randomly as DMD likes to do.)
Also, it obviously needs a repl. :-)
CTFE is basically done (as a portable byte code interpreter, but other
strategies, such as JIT, could be easily plugged). This is a snippet of
my regression test suite:
auto dynRangePrimes(){
DynRange!int impl(int start)=>
dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1);
return impl(2);
}
static assert(array(take(dynRangePrimes(), 20)) ==
[2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);
)
I also need to decide on a licence. I assume that the alpha will be out
in late spring. (I am busy until early spring.)
But, to answer the OP question: no, there are no plan to switch to D for
the reference compiler in the near future, as far as I can tell.
Re: manual memory management
On Wednesday, 9 January 2013 at 10:31:51 UTC, deadalnix wrote: On Wednesday, 9 January 2013 at 10:19:24 UTC, Mehrdad wrote: Yes I did, but I didn't realize you were talking about a background GC, sorry. Yeah, if you can have a background GC that can keep up with your needs, then the world is great. Trouble is, I don't see how that can be true for a intensive applications like games. You are changing the subject discussed every 2 posts. I'm loosing my time here, that will be my last answer to you. That wasn't my intention, but the subject suddenly changed to background GCs which I didn't expect to be talking about either... but if you don't have the time to continue then I'll avoid responding too.
Re: manual memory management
Am 09.01.2013 11:21, schrieb Mehrdad: Come to think of it, C++ allocators are meant for exactly this: throwing away an entire batch of objects in 1 go. Beats GCs any day. but a gc is much more generic then a specialized allocator redefine you scenario please: are we talking about many,any or special program situations? for my understanding there is no one-for-all-perfect-solution but many perfect-solution-for-excatly-this-case that is the reason for having ref-counting & GCs around
Re: manual memory management
On Wednesday, 9 January 2013 at 11:10:40 UTC, dennis luehring wrote: Am 09.01.2013 11:21, schrieb Mehrdad: Come to think of it, C++ allocators are meant for exactly this: throwing away an entire batch of objects in 1 go. Beats GCs any day. but a gc is much more generic then a specialized allocator redefine you scenario please: are we talking about many,any or special program situations? We're talking about a language that should be able to handle any realistic situation. for my understanding there is no one-for-all-perfect-solution but many perfect-solution-for-excatly-this-case that is the reason for having ref-counting & GCs around Yeah we agree on that, no discussion there. Speaking of which, I have a feeling what I said didn't send the message I meant: I didn't mean we should reference-count EVERYTHING. Allocators, etc. have their places too -- and they all under manual (or automatic, whatever you wish to call it) memory management. My entire point during this discussion has been that you _don't_ _require_ a GC for anything, unlike what Walter said. Manual (/automatic/whatever you want to call it) memory management can take its place just fine.
Re: manual memory management
On Wednesday, January 09, 2013 12:16:46 Mehrdad wrote: > My entire point during this discussion has been that you _don't_ > _require_ a GC for anything, unlike what Walter said. Manual > (/automatic/whatever you want to call it) memory management can > take its place just fine. Walter wasn't arguing that there wasn't a place for manual memory management. He was arguing that you can't guarantee memory safety if you're using manual memory management - hence why malloc and free are @system. @system code is not memory safe like @safe code is, but it still very much has it's place. - Jonathan M Davis
Re: manual memory management
On 01/09/2013 09:54 AM, Mehrdad wrote: You (or Walter I guess) are the first person I've seen who calls C++ garbage collected. Maybe not GC in the truest sense, but one of the first realizations I had when I started teaching myself C++ (having originally learned C) was, "Oh, gosh, I don't have to manually handle memory allocation/deallocation any more." Of course, that's an overstatement in reality, but I still find that for almost all of the C++ code I've ever had to write, I've been able to avoid manual memory management.
Re: manual memory management
On Wednesday, 9 January 2013 at 02:49:34 UTC, Rob T wrote: I'm very surprised that not too many people have been screaming for dynamic linking and runtime loading. It's very hard for me to imagine not having the feature because it's so darn useful and an essential feature if your strategy is to allow 3rd parties to extend an application without hacking at the source code. If there's another better way, I'd sure like to know about it! --rt There were many people screaming about it. Just there is nobody who could make it work. Walter claimed that compiler is shared-lib ready, it is just druntime that is lacking. And he hasn't got knowledge to make it work on his own. Sean Kelly is out - he was Walter's bet to make it work. My hope was Martin Nowak, he was working on it but seems that he also got busy with other stuff
Re: ref is unsafe
On Wednesday, 9 January 2013 at 04:33:21 UTC, Zach the Mystic
wrote:
I felt confident enough about my proposal to submit it as
enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=9283
I like it. One issue though, like you also indicated by putting
question marks on it:
ref T get(T)()
{
T local;
return cast(out) local; // This shouldn't compile
}
Because, wouldn't returning a local variable as a reference be a
dangling reference in all cases? No matter if the programmer
claims it's correct by saying cast(out)... it just can't be
correct.
And T can be a type that has reference semantics or value
semantics, it doesn't matter. That function would always return a
dangling reference, were it allowed to compile.
Re: ref is unsafe
On Wednesday, 9 January 2013 at 04:33:21 UTC, Zach the Mystic wrote: I felt confident enough about my proposal to submit it as enhancement request: http://d.puremagic.com/issues/show_bug.cgi?id=9283 By the way, what do you propose is the correct placement of this "new" out keyword: #1: out ref int get(ref int a); #2: ref out int get(ref int a); #3: ref int get(ref int a) out; I wouldn't allow #3.
Re: Official DMD compiler written in D
On 2013-01-09 12:05, Timon Gehr wrote: Yes, it is in D. Nothing is released yet. It needs to be polished a little so that there are no known embarrassing shortcomings anymore. I've might have missed this front end. Any links ? -- /Jacob Carlborg
Re: Official DMD compiler written in D
On Wed, Jan 9, 2013 at 12:05 PM, Timon Gehr wrote:
> Yes, it is in D. Nothing is released yet. It needs to be polished a little
> so that there are no known embarrassing shortcomings anymore.
What? That's FOSS, release early, release often!
> (DMD chokes on both.)
>
> Furthermore, I need to implement exceptions, modules, and some parts of
> compile time reflection + tons of really small features. (Where all
> ambiguities and contradictions are detected according to well-defined rules
> instead of resolved or choked on randomly as DMD likes to do.)
Makes me salivate.
> Also, it obviously needs a repl. :-)
Obviously.
And direct programmatic access to the lexer and the parser. I'm coding
a macro system for D right now, as an over-layer above DMD (like rdmd)
and having to create the AST by myself to transform them according to
the user-defined macros is a pain.
> CTFE is basically done (as a portable byte code interpreter, but other
> strategies, such as JIT, could be easily plugged).
Great!
> This is a snippet of my regression test suite:
>
> auto dynRangePrimes(){
> DynRange!int impl(int start)=>
>
> dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1);
> return impl(2);
> }
>
> static assert(array(take(dynRangePrimes(), 20)) ==
> [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);
Lazy recursive range, right? As the usual Haskell definition for a
prime generator. Nice!
> I also need to decide on a licence.
Unless you've reason not to, I'd advise using the same as Phobos: Boost.
> I assume that the alpha will be out in late spring. (I am busy until early
> spring.)
You can count me in to test it (I gather to prefer to code this as you
see fit, right now). You could also present it at the D conf.
In any cases, congratulations for what seems to be a elegantly done D
implementation.
Re: manual memory management
Am 09.01.2013 12:39, schrieb nazriel: On Wednesday, 9 January 2013 at 02:49:34 UTC, Rob T wrote: I'm very surprised that not too many people have been screaming for dynamic linking and runtime loading. It's very hard for me to imagine not having the feature because it's so darn useful and an essential feature if your strategy is to allow 3rd parties to extend an application without hacking at the source code. If there's another better way, I'd sure like to know about it! --rt There were many people screaming about it. Just there is nobody who could make it work. Walter claimed that compiler is shared-lib ready, it is just druntime that is lacking. And he hasn't got knowledge to make it work on his own. Sean Kelly is out - he was Walter's bet to make it work. My hope was Martin Nowak, he was working on it but seems that he also got busy with other stuff The compiler is not shared-lib ready. At least not on windows. It does not support exporting data symbols. E.g. export uint g_myGlobal; This is mostly a problem for "hidden" data symbols, like vtables, module info objects, type info objects and other stuff D relies on. Druntime on windows does already handle everything else pefectly (e.g. threads and TLS) Kind Regards Benjamin Thaut
Re: manual memory management
On Wednesday, 9 January 2013 at 09:17:35 UTC, Dmitry Olshansky wrote: 09-Jan-2013 12:54, Mehrdad пишет: On Wednesday, 9 January 2013 at 08:51:47 UTC, Paulo Pinto wrote: On Wednesday, 9 January 2013 at 08:28:44 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 08:14:35 UTC, Walter Bright wrote: On 1/8/2013 11:42 PM, Mehrdad wrote: (True, it wouldn't give you the power of a systems language, but that's quite obviouly not my point -- the point is that it's a _perfectly possible_ memory-safe language which we made, so I don't understand Walter's comment about a GC being "required" for a memory-safe language.) The misunderstanding is you are not considering reference counting as a form of GC. It is. So you would say that C++ code (which uses reference counting) uses garbage collection? Yes. You (or Walter I guess) are the first person I've seen who calls C++ garbage collected. That's a stretch - IMHO I'd call the language garbage collected iff it is the default way language-wise (e.g. if C++ new was ref-counted I'd call C++ garbage collected). This way D is garbage collected language because the language default is GC. I was being provocative on purpose. Having said that, a C++ application where *_ptr<> + STL types are used everywhere can make C++ almost a safe language. Unfortunately most C++ libraries make use of naked pointers. .. Paulo
Re: manual memory management
On Wednesday, 9 January 2013 at 10:21:29 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 10:14:07 UTC, dennis luehring wrote: Am 09.01.2013 11:09, schrieb Mehrdad: On Wednesday, 9 January 2013 at 10:07:42 UTC, deadalnix wrote: Reference counting tend to create big pauses when deallocating as objects tends to dies in group. I don't get it... it's slower to deallocate a bunch of objects together with refcounting than to deallocate all of them individually over a longer period of time? could be - think of an large hierarchy of objects which tends to take some time to deconstruct ... a background gc could be better for your application speed in this situation - by the cost of smaller pause and more resource usage Come to think of it, C++ allocators are meant for exactly this: throwing away an entire batch of objects in 1 go. Beats GCs any day. or better - what is the real reason for Java and C# for using garbage collectors if ref-counting will be always better (except cyclic stuff)? Pretty sure the only reason C#/Java use a GC _is_ for cyclic stuff, and that's it. If you have any other reasons please show me a benchmark that shows a GC being faster than the equivalent refcounted code (I've seen lots of talks in theory about how it _COULD_ be different but never seen any examples in practice; would love to see one). Reference counting always implies extra booking code per memory access, I fail to see how it can be made faster than any parallel GC. The Aonix VM for example is used in military scenarios like missile radar systems and battleship gun's control systems, beats any game timing requirements, I would say. -- Paulo
Re: Official DMD compiler written in D
On Wednesday, 9 January 2013 at 11:05:56 UTC, Timon Gehr wrote: I also need to decide on a licence. I assume that the alpha will be out in late spring. (I am busy until early spring.) I'm not really a specialist in terms of license, but it'd be nice if it is compatible with SDC's.
Re: Official DMD compiler written in D
On 2013-01-09 13:54, deadalnix wrote: I'm not really a specialist in terms of license, but it'd be nice if it is compatible with SDC's. SDC uses the MIT license. -- /Jacob Carlborg
Re: Official DMD compiler written in D
On Wed, Jan 9, 2013 at 1:58 PM, Jacob Carlborg wrote: > On 2013-01-09 13:54, deadalnix wrote: > >> I'm not really a specialist in terms of license, but it'd be nice if it >> is compatible with SDC's. > > > SDC uses the MIT license. Well, I'd use (and hack) any D compiler written in D, whatever the license. Let Timon code it, when the only left is the license, all will be well and good.
small idea
Disclaimer: I do not ask for anything, it is just an idea, do not blame me (too much). One thing that I really like about a function is to know quite clearly which of its parameters are for input, which for output and, yes, which one are for carrying (input/output parameters). In D, this is signalled by the in/out/inout keywords. However, these are only visible at the moment of function declaration, not calling. In C, you usually can distinguish since parameters intended to be modified are passed through address (pointers), and you see that at use time: void make_a_equal_to_b(&a,b); In D, it would be: void make_a_equal_to_b(a,b); Yes, the name of the function can convey the intention. But, in C, the calling, too. It is a kind of a double check. Now, what about accepting a quick and optional (to not break existing code) annotation at the time of the call: void make_a_equal_to_b(??a,!!b); //I give you "b", give me "a" so that in, out and inout could be replaced by !!, ?? and !? Alternatives could be: >>, <<, >< but that's more complex. Non-concordance between !!/!?/?? use and in/out/inout declaration could be sanctioned with a warning or an error, or explicitely ignored through a compiler flag.
Re: small idea
This is actually one of the things I miss. In C# you have to
specify what direction the variables are traveling in the calling
function.
int a,b=2;
a_eq_b(a,b); // works..
a_eq_b(out a,b); // this would be nice
a_times2(ref a); // same here
void a_eq_b(out int a, int b)
{
a = b;
}
void a_times2(ref int a)
{
a *= 2;
}
Re: small idea
eles: void make_a_equal_to_b(??a,!!b); //I give you "b", give me "a" A saner syntax is just to use the same in/out/inout keywords at the call point, This is essentially what C# does (with one exception for COM): make_a_equal_to_b(ref a, in b) This feature was discussed several times in past for D. The advantage is more readability for the code and less surprises. The disadvantages are more typing, some code breakage of D2 code (because even if at the beginning it's a warning, and later a deprecation, you will eventually need to enforce it with an error). One more small D-specific problem is what to do if the first argument is a ref and you want to use UCFS. In the end it's one of those features that are borderline, they have both advantages and disadvantages. I generally like languages that are clear and avoid surprises. Bye, bearophile
Re: Official DMD compiler written in D
On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote: We *could* write a cross-compiler, of course, but it still requires that you first target the D compiler (written in D) to the new platform, and then cross-compile itself to that platform. Whereas with DMD, you just use the target platform's C++ compiler and you're up and running. T I think LDC 2.0 or GDC 2.0 might be able to serve this purpose.
Re: small idea
On Wednesday, 9 January 2013 at 15:10:47 UTC, bearophile wrote: eles: make_a_equal_to_b(ref a, in b) This feature was discussed several times in past for D. The advantage is more readability for the code and less surprises. The disadvantages are more typing, some code breakage of D2 code (because even if at the beginning it's a warning, and later a deprecation, you will eventually need to enforce it with an error). Why make it a requirement or give a warning. Just allow the programmer to do it in version 2.x or 3.x. If it catches on, then start with a warning in version 4.x or whatever. Note: I would not add this feature if it creates a lot of work for the compiler writers.
Re: small idea
Tim Krimm: Why make it a requirement or give a warning. If it's not enforced I think it becomes a not useful enough feature. Note: I would not add this feature if it creates a lot of work for the compiler writers. I don't think this is a significant problem. Bye, bearophile
Re: small idea
Yes this has been requested a few times. I just want to point out that while I like the idea (seeing how well it works in C#), I also think it should be optionally how it is now. There are times when you want to pass and object as ref for optimization only, and aren't actually modifying the value (like Matrix Multiplication for example). In these cases, the way D works right now is nice, because it hides that detail from the end user. Still, I think 'ref'/'out' should be require at call-site by default, to avoid any gotchas. I also don't see any problem with UFCS really. I mean, using that syntax is pseudo-OOP and implies the first parameter might be modified in the function.
Re: manual memory management
On 1/9/13 4:25 AM, Benjamin Thaut wrote: The compiler is not shared-lib ready. At least not on windows. It does not support exporting data symbols. E.g. export uint g_myGlobal; This is mostly a problem for "hidden" data symbols, like vtables, module info objects, type info objects and other stuff D relies on. Are there bugzilla entries for this? Andrei
Re: Official DMD compiler written in D
O Yes, it is in D. Nothing is released yet. It needs to be polished a little so that there are no known embarrassing shortcomings anymore. (eg. the parser cannot parse extern(...) declarations in alias declarations yet, and I need to finish making a minor tweak to how template instances are analyzed in order to get circular dependency detection to work reliably. How are you implementing the code generating back-end for the compiler? In your design, I would recommend keeping the front-end separate from the back-end so that maybe the front-end can be connected to the LDC or GDC back-ends.
Re: small idea
On Wednesday, 9 January 2013 at 14:28:32 UTC, eles wrote: In D, this is signalled by the in/out/inout keywords. Just FYI: This may not be accurate. For starters, inout has *nothing* to do with in or out. It is used as a wild qualifier: http://dlang.org/function.html#Inout_Functions "in" means not only that you will read the variable, but that it will be both const and scope. const is *very* restrictive in D. "out" parameters are first init initialized. This means that if you want to pass a parameter, that the function is supposed to modify, but not necessarily read (such as an appender), then "out" won't work (it will clobber your out parameter first). So the "general" case where you pass something by value, but mutate it (for example, passing range), then neither "in" nor "out" will work (nor "inout").
Re: Official DMD compiler written in D
On 1/9/13 5:10 AM, Philippe Sigaud wrote: On Wed, Jan 9, 2013 at 1:58 PM, Jacob Carlborg wrote: On 2013-01-09 13:54, deadalnix wrote: I'm not really a specialist in terms of license, but it'd be nice if it is compatible with SDC's. SDC uses the MIT license. Well, I'd use (and hack) any D compiler written in D, whatever the license. Let Timon code it, when the only left is the license, all will be well and good. Once http://d.puremagic.com/issues/show_bug.cgi?id=9285 is done we'll have a realistic means to progressively port dmd's official front end into D by translating one module at a time and linking together C++ and D code. dtoh would serve as the bridge generator and would allow us to avoid maintaining duplicate declarations. Andrei
Re: small idea
On Wednesday, 9 January 2013 at 14:28:32 UTC, eles wrote: In D, this is signalled by the in/out/inout keywords. This should be »in/out/ref«, inout only had that meaning in D1. David
Re: small idea
On Wednesday, 9 January 2013 at 15:10:47 UTC, bearophile wrote: eles: void make_a_equal_to_b(??a,!!b); //I give you "b", give me "a" A saner syntax is just to use the same in/out/inout keywords True. I was worried that it would be too long to type it. However, if those are made optional, maybe is not a so bad choice, as typing them is not required. More, they are typed only if the programmer feels the need, somehow like a self-documentation. One that can be checked by the compiler, though.
Re: small idea
On Wednesday, 9 January 2013 at 15:36:21 UTC, Tim Krimm wrote: On Wednesday, 9 January 2013 at 15:10:47 UTC, bearophile wrote: eles: make_a_equal_to_b(ref a, in b) This feature was discussed several times in past for D. The advantage is more readability for the code and less surprises. The disadvantages are more typing, some code breakage of D2 code (because even if at the beginning it's a warning, and later a deprecation, you will eventually need to enforce it with an error). Why make it a requirement or give a warning. My feeling about such feature is that it is an annotation (read: "intention"), rather than a warning (read: potential misuse) and error (read: "obvious misuse"). I would go for having annotations somewhere on the scale error/warning/annotation/correct in between the warning and correct. That is, a stand-alone language/compile feature and even flag.
Re: small idea
On Wednesday, 9 January 2013 at 15:10:47 UTC, bearophile wrote: eles: void make_a_equal_to_b(??a,!!b); //I give you "b", give me "a" A saner syntax is just to use the same in/out/inout keywords at the call point, This is essentially what C# does (with one exception for COM): make_a_equal_to_b(ref a, in b) This feature was discussed several times in past for D. The advantage is more readability for the code and less surprises. The disadvantages are more typing, some code breakage of D2 code (because even if at the beginning it's a warning, and later a deprecation, you will eventually need to enforce it with an error). Assuming that annotation-breaking is on a separate level of errorness than errors and regular warnings will avoid that problem. It will remain at the level "annotation", no need to migrate to "warning" or "error". Code will not break as long as typying "inout" &co. will be optional. If the programmer feels it is better, he puts it there.
Re: small idea
On Wednesday, 9 January 2013 at 15:43:09 UTC, bearophile wrote: Tim Krimm: Why make it a requirement or give a warning. If it's not enforced I think it becomes a not useful enough feature. Let's cut it at half: if "inout" &co. are specified, then non-concordance with function declaration will be a requirement. If "inout" & co. are not specified, then they are simply not required. Code breakage will be avoided.
Re: small idea
On Wednesday, 9 January 2013 at 16:04:06 UTC, David Nadlinger wrote: On Wednesday, 9 January 2013 at 14:28:32 UTC, eles wrote: In D, this is signalled by the in/out/inout keywords. This should be »in/out/ref«, inout only had that meaning in D1. OK&Thanks. Please read "ref" in my other posts, instead of "inout".
Re: small idea
On Wednesday, 9 January 2013 at 15:10:47 UTC, bearophile wrote: eles: void make_a_equal_to_b(??a,!!b); //I give you "b", give me "a" A saner syntax is just to use the same in/out/inout keywords at the call point, This is essentially what C# does (with one exception for COM): make_a_equal_to_b(ref a, in b) This feature was discussed several times in past for D. The advantage is more readability for the code and less surprises. The disadvantages are more typing, some code breakage of D2 code (because even if at the beginning it's a warning, and later a deprecation, you will eventually need to enforce it with an error). The same thing happens every time this is discussed: some people insist "ref" and "out" should be REQUIRED or else it should not be ALLOWED. Others don't want to break backward compatibility so they insist it can't be required. There is no common ground so it never gets to the "allowed" stage. In C++ I actually use call site ref for & params even with no checking at all: #define IN #define OUT in fact these are defined in a Microsoft header. I find them useful for documentation. Again, my proposal is that the compiler should allow ref/out and not warn when it is missing; if users want a warning/error for missing ref/out, they can ask for it per-module with a pragma (or something). One more small D-specific problem is what to do if the first argument is a ref and you want to use UCFS. In the past I suggested allowing implicit ref for structs (but probably not for classes) with UFCS, because the "this" parameter of a member function of a struct is passed by ref already.
Re: small idea
I am responding before reading the rest of the thread. On 01/09/2013 06:28 AM, eles wrote: > In D, this is signalled by the in/out/inout keywords. You mean ref, not inout. > However, these are > only visible at the moment of function declaration, not calling. > > In C, you usually can distinguish since parameters intended to be > modified are passed through address (pointers), and you see that at use > time: > > void make_a_equal_to_b(&a,b); And in C++ it is again impossible because the ref parameter is a reference. I've heard this proposal before. It is an interesting idea but I've been coding in C and C++ for years. I have never had an issue related to this topic. I always knew what a function call did. I don't remember a single bug that was caused by this. I don't even prepend "ptr" to pointer variable names. So I don't see the benefit. Ali
Re: manual memory management
On Wednesday, 9 January 2013 at 08:59:01 UTC, Jonathan M Davis wrote: [...] whereas all dynamic linking really does is save disk space. Saving on disk space is a minor advantage. The main advantage is allowing shared libs to be distributed without having to re-link then in manually. For example, if a bug is fixed in a shared lib, all applications automatically get the bug fix, but with statically linked libs, you have to re-link all the apps that use the lib to gain access to the bug fix. With static linking you also have no easy way to ensure that your apps are all using the most up-to-date version of a shared lib. Effectively, without dynamic linking, collections of applications, such as operating systems would be very difficult to deploy and maintain to the point of being impractical. D is simply a whole lot less useful without full dynamic runtime linking. --rt
Re: manual memory management
On Wednesday, 9 January 2013 at 11:24:32 UTC, Jonathan M Davis wrote: Walter wasn't arguing that there wasn't a place for manual memory management. He was arguing that you can't guarantee memory safety if you're using manual memory management - hence why malloc and free are @system. @system code is not memory safe like @safe code is, but it still very much has it's place. - Jonathan M Davis You cannot guarantee memory safety with a GC either, depending on the definition of "memory safety". For example, you can still access deallocated memory by mistake, run out of memory due to accumulating persistent pointers left around by mistake, or free memory that was not supposed to be freed by mistake. The GC implementation may fail due to bugs, deallocating live memory or failing to deallocate inactive memory. The only thing a GC can do for you, is free up the programmer from the tedium of managing memory. It also allows constructs that otherwise would be very difficult or impractical to implement. The effect can be very positive, but there are no guarantees of memory safety. I also doubt that a "one size fits" all approach to garbage collection will ever satisfy everyone. What's needed is the ability to both manage memory manually and automatically (D allows this which is good), but also allow for the automated methods to be easily replaced (plug-ins come to mind), and if possible allow sections of code to be managed by completely different garbage collector implementations that are designed to serve different purposes (this may or may not be practical to do). --rt
Re: github release procedure
On Thursday, 3 January 2013 at 17:56:05 UTC, Johannes Pfau wrote: What changes? All changes should be made in master, then applied to staging via cherry picking. So there should never be changes in staging that are not in master so there's nothing that could be overwritten? I strongly disagree here. We want pull requests to be made against the oldest supported/relevant branch. This could be merged to both staging and master (which can simply be done by merging staging into master) there is no need to complicate things with cherry picking. As for history, I think that clearly shows what the history is, staging gets fixes and master gets staging that is what we want.
Re: manual memory management
On Wed, Jan 09, 2013 at 08:33:23AM +0100, Rob T wrote: [...] > There is a point being made here that is perfectly valid. There is a > form of memory leak that a GC can never catch, such as when when > memory is allocated and simply never deallocated by mistake due to a > persistent "in use" pointer that should have been nulled but wasn't. No form of memory management will be immune to programmer error. That's plain impossible. You can write broken code in any language, under any kind of memory management system. Short of going heapless, nothing is going to help you here. (Actually, even going heapless won't help you -- think of what happens if you have a fixed-sized stack and forget to pop used-up elements. Yes such a bug is way more obvious than a pointer that didn't get nulled, but both are still just bugs.) > In addition, the GC itself may fail to deallocated freed memory or > even free live memory by mistake. I've seen bugs described to that > effect. I thought the idea was to make it so that SafeD is free from this kind of problem (short of a bug in the GC itself) -- AFAIK, the GC freeing live memory is caused by having XOR'ed pointers or other such tricks that cause the GC to fail to detect the pointer to the memory. In theory, SafeD should prevent this by not allowing unsafe operations on pointers like XOR'ing. SafeD still has a long ways to go, though. > There simply is no panacea to the memory leak problem. What > a GC does do, is free the programmer from a ton of tedium, and even > allow for constructs that would normally not be practical to > implement, but it can never guarantee anything more than that. [...] Yes. I don't think there are many things in the programming world that can be guaranteed. The compiler would have to be clairvoyant (not merely pass the Turing test) to catch these sorts of errors. T -- To provoke is to call someone stupid; to argue is to call each other stupid.
Re: github release procedure
On Friday, 4 January 2013 at 20:10:33 UTC, Rob T wrote: If you look at the download page, the .0 is missing on some of the packages, but shows up as a -0 on some of the others, and that is simply confusing and totally unnecessary. If it is necessary for some reason, then it needs to be explained. The -0 is a packaging version, if you repackage 2.63 (fixing dependencies) then the package is 2.63-1.
Re: manual memory management
On Wed, Jan 09, 2013 at 06:26:55PM +0100, Rob T wrote: > On Wednesday, 9 January 2013 at 11:24:32 UTC, Jonathan M Davis > wrote: > >Walter wasn't arguing that there wasn't a place for manual memory > >management. He was arguing that you can't guarantee memory safety if > >you're using manual memory management - hence why malloc and free are > >@system. @system code is not memory safe like @safe code is, but it > >still very much has it's place. > > > >- Jonathan M Davis > > You cannot guarantee memory safety with a GC either, depending on > the definition of "memory safety". > > For example, you can still access deallocated memory by mistake, Are you sure about this? Short of doing pointer arithmetic (which is unsafe by definition), I don't see how you can do this. Where would you get the pointer to that memory from? It has to be stored somewhere, meaning the GC will not deallocate the memory pointed to. > run out of memory due to accumulating persistent pointers left around > by mistake, That is not unsafe. That just means you run out of memory and get an OutOfMemory exception or the OS kills your process. No safety issue there. > or free memory that was not supposed to be freed by mistake. How? The GC, by definition, doesn't free the memory unless nothing is pointing to it. > The GC implementation may fail due to bugs, deallocating live memory > or failing to deallocate inactive memory. You're conflating the theory of GCs and its implementation, which is prone to bugs. By that argument, you might as well say that there is no such thing as memory safety, because implementations are always prone to bugs. Your RAM could catch fire, for example. There's nothing you can do in software to prevent that. That's not a helpful argument, though. The question at hand is, given a GC, which presumably has been thoroughly debugged, does it guarantee memory safety? I think it does, because as long as there's a pointer to the memory left, the GC will not collect it, and so you can't use the pointer to access invalid memory. If there are no more pointers to that memory, then by definition you have nothing to access that memory with. Like I said, you have to get the pointer from *somewhere*. As long as the pointer is somewhere, the GC will find it, and mark the memory as used, so it won't be collected. If there are no pointers left, you also have no way to access that memory anymore. So you can never access invalid memory. It's very straightforward. This memory safety can be broken only if you allow pointer arithmetic and casts to/from pointers. But everyone knows that pointer arithmetic is unsafe by definition; I don't think we're talking about that here. [...] > I also doubt that a "one size fits" all approach to garbage > collection will ever satisfy everyone. Of course not. That's why the game devs on this list have been doing GC-less D programming. :-) But that also means they have to either preallocate everything, or they have to manually manage the memory (with malloc/free or equivalent), which is unsafe, because it's very easy to free some memory while there are still pointers to it left. > What's needed is the ability to both manage memory manually and > automatically (D allows this which is good), but also allow for the > automated methods to be easily replaced (plug-ins come to mind), and > if possible allow sections of code to be managed by completely > different garbage collector implementations that are designed to serve > different purposes (this may or may not be practical to do). [...] I don't know about the practicality of using multiple GCs in a single app, but certainly the ability to choose from a number of alternative GC implementations at compile-time would be very welcome. You could have a GC that has high throughput but introduces intermittent long pauses, and another GC that has lower throughput but has no pauses longer than, say, 0.1 seconds. Then at compile-time you choose one, depending on what you need. An interactive app will choose the second, but a batch processing app will benefit from the first. T -- Why waste time learning, when ignorance is instantaneous? -- Hobbes, from Calvin & Hobbes
Re: manual memory management
On 1/9/2013 12:28 AM, Mehrdad wrote: On Wednesday, 9 January 2013 at 08:14:35 UTC, Walter Bright wrote: On 1/8/2013 11:42 PM, Mehrdad wrote: (True, it wouldn't give you the power of a systems language, but that's quite obviouly not my point -- the point is that it's a _perfectly possible_ memory-safe language which we made, so I don't understand Walter's comment about a GC being "required" for a memory-safe language.) The misunderstanding is you are not considering reference counting as a form of GC. It is. So you would say that C++ code (which uses reference counting) uses garbage collection? Yes, but it is not memory safe as C++ allows escapes from it.
Re: Official DMD compiler written in D
On Wed, Jan 09, 2013 at 12:05:55PM +0100, Timon Gehr wrote:
> On 01/08/2013 10:06 PM, Philippe Sigaud wrote:
[...]
> >Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the
> >past, but did not provide any link to it.
> >
>
> Yes, it is in D. Nothing is released yet. It needs to be polished a
> little so that there are no known embarrassing shortcomings anymore.
[...]
> CTFE is basically done (as a portable byte code interpreter, but
> other strategies, such as JIT, could be easily plugged). This is a
> snippet of my regression test suite:
>
> auto dynRangePrimes(){
> DynRange!int impl(int start)=>
>
> dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1);
> return impl(2);
> }
>
> static assert(array(take(dynRangePrimes(), 20)) ==
> [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);
>
> )
Whoa!!! Now you really caught my interest!
Can it handle CTFE-computed mixins that declare and reference variables?
If it can, I will finally be able to write a library AA implementation
that allows static AA literals (no runtime init/allocation needed)!
T
--
Meat: euphemism for dead animal. -- Flora
Re: manual memory management
On 1/9/2013 9:26 AM, Rob T wrote: You cannot guarantee memory safety with a GC either, depending on the definition of "memory safety". GC is a necessary requirement for memory safety, but not sufficient. For example, you can still access deallocated memory by mistake, If you're not playing with pointers, then this is a buggy GC. run out of memory due to accumulating persistent pointers left around by mistake, Memory safety does not imply never running out of memory. or free memory that was not supposed to be freed by mistake. Then it's a buggy GC. The GC implementation may fail due to bugs, deallocating live memory or failing to deallocate inactive memory. Of course memory safety presumes a correctly implemented GC. The only thing a GC can do for you, is free up the programmer from the tedium of managing memory. It also allows constructs that otherwise would be very difficult or impractical to implement. The effect can be very positive, but there are no guarantees of memory safety. This is incorrect - see above. A bug free GC, and not "cheating" in using it, guarantees memory safety. This is a big deal.
Re: manual memory management
On 1/9/2013 10:32 AM, H. S. Teoh wrote: > does it guarantee memory safety? I think it does, A GC is a necessary, but not sufficient, condition for memory safety.
Re: manual memory management
On 1/9/2013 1:24 AM, Mehrdad wrote: The language need not give you any direct access to memory, making everything perfectly safe. You can add a runtime check for every "pointer" access (much like what valgrind does), and abort on an invalid access. But that is not what memory safety is.
Re: manual memory management
Am 09.01.2013 16:49, schrieb Andrei Alexandrescu: On 1/9/13 4:25 AM, Benjamin Thaut wrote: The compiler is not shared-lib ready. At least not on windows. It does not support exporting data symbols. E.g. export uint g_myGlobal; This is mostly a problem for "hidden" data symbols, like vtables, module info objects, type info objects and other stuff D relies on. Are there bugzilla entries for this? Andrei Yes its pretty old too. If you read through the discussion in the ticket and through the code Rainer Schuetze provided you will have a list of all the issues that need to be fixed for shared dlls to work: http://d.puremagic.com/issues/show_bug.cgi?id=4071 In the following patch: http://d.puremagic.com/issues/attachment.cgi?id=601&action=edit Rainer Schuetze does manual patching for data symbols. But this is hardcoded to only work for his phobos shared dll. The function it is done in is called dll_patchImportRelocations. If I understand DLLs correctly this should usually be done by the import library that is created by the compiler for a shared dll. Maybe Rainer can shed some mor light on this. Kind Regards Benjamin Thaut
Re: small idea
On Wed, 09 Jan 2013 15:28:31 +0100 "eles" wrote: > Disclaimer: I do not ask for anything, it is just an idea, do not > blame me (too much). > > One thing that I really like about a function is to know quite > clearly which of its parameters are for input, which for output > and, yes, which one are for carrying (input/output parameters). > > In D, this is signalled by the in/out/inout keywords. However, > these are only visible at the moment of function declaration, not > calling. > > In C, you usually can distinguish since parameters intended to be > modified are passed through address (pointers), and you see that > at use time: > > void make_a_equal_to_b(&a,b); > > In D, it would be: > > void make_a_equal_to_b(a,b); > > Yes, the name of the function can convey the intention. But, in > C, the calling, too. It is a kind of a double check. > > Now, what about accepting a quick and optional (to not break > existing code) annotation at the time of the call: > > void make_a_equal_to_b(??a,!!b); //I give you "b", give me "a" > > so that in, out and inout could be replaced by !!, ?? and !? > > Alternatives could be: >>, <<, >< but that's more complex. > > Non-concordance between !!/!?/?? use and in/out/inout declaration > could be sanctioned with a warning or an error, or explicitely > ignored through a compiler flag. Yea, that's one thing I do like about C#.
Re: dlangspec.pdf?
On 1/9/2013 2:40 AM, Philippe Sigaud wrote: On Wed, Jan 9, 2013 at 2:05 AM, Walter Bright wrote: I'd still like to see it done as a phobos module. Maybe an enhancement request? So, this should: - take a .ddoc file for macro definition, or a [name, code] range of pairs. - read an input range - this range can be a standard D file, a .dd or whatever. That means parsing D comments... - find any macro definition - find any $(NAME Args,) call, expand it recursively. Repeat until nothing changes anymore. This should be done lazily (through the input range interface), in case the user want to stop before the end. - output the result as a range. What I'm not clear about, is: if the input is a D source file, should the expander strip any D code from it? Should this return a full-fledged documentation (ie, find the documented symbols...) or just blindly expand DDoc macros. No no no. The module gets its input from an InputRange. Not a file. It gets its macro definitions, which are NAME=VALUE pairs, from an associative array of them.
Re: manual memory management
On Wednesday, 9 January 2013 at 18:46:53 UTC, Walter Bright wrote: GC is a necessary requirement for memory safety, but not sufficient. Walter, would you mind explaining WHY it's "necessary"? I just spent so many comments explaining why NO form of automatic memory management is required for guaranteeing memory safety () and then you reply and say "GC is a necessary requirement" and leave it at that. See my comment here regarding handles, etc.: http://forum.dlang.org/thread/mailman.232.1357570887.22503.digitalmar...@puremagic.com?page=7#post-jimseaovuxmribkqbict:40forum.dlang.org
Re: dlangspec.pdf?
On Wed, Jan 09, 2013 at 11:01:32AM -0800, Walter Bright wrote:
> On 1/9/2013 2:40 AM, Philippe Sigaud wrote:
> >On Wed, Jan 9, 2013 at 2:05 AM, Walter Bright
> > wrote:
> >
> >>I'd still like to see it done as a phobos module. Maybe an
> >>enhancement request?
> >
> >So, this should:
> >
> >- take a .ddoc file for macro definition, or a [name, code] range of
> > pairs.
> >- read an input range
> > - this range can be a standard D file, a .dd or whatever. That
> > means parsing D comments...
> >- find any macro definition
> >- find any $(NAME Args,) call, expand it recursively. Repeat until
> > nothing changes anymore. This should be done lazily (through the
> > input range interface), in case the user want to stop before the
> > end.
> >- output the result as a range.
> >
> >What I'm not clear about, is: if the input is a D source file, should
> >the expander strip any D code from it? Should this return a
> >full-fledged documentation (ie, find the documented symbols...) or
> >just blindly expand DDoc macros.
> >
>
> No no no. The module gets its input from an InputRange. Not a file.
> It gets its macro definitions, which are NAME=VALUE pairs, from an
> associative array of them.
I agree, the interface should be as generic as possible. I think it
would be nice to have a separate function for parsing macro definitions.
So the API should look something like this:
Result expandDdocMacros(I,Result)(I inputRange,
string[string] macroDefs)
if (isInputRange!I && isSomeChar!(ElementType!I))
{ ... }
string[string] parseMacroDefs(I)(I inputRange)
if (isInputRange!I && isSomeChar!(ElementType!I))
{ ... }
Then you can use it something like this:
void main() {
auto macrodefs = File(macroFile);
auto inputfile = File(ddocFile);
auto expanded = expandDdocMacros(inputfile.byChar(),
macrodefs.byChar());
static assert(isInputRange!(typeof(expanded)));
stdout.write(expanded);
}
You can also feed it all sorts of stuff, like network input:
string[string] builtinMacros = ...;
// Online Ddoc expander!
void myCgiApp(HttpRequest req, ref HttpResponse resp) {
static assert(isInputRange!(typeof(req.data)) &&
isSomeChar!(ElementType!(typeof(req.data;
auto result = expandDdocMacros(req.data, builtinMacros);
resp.put(result);
}
Etc., etc.. D ranges are an extremely powerful concept.
T
--
Без труда не выловишь и рыбку из пруда.
Re: manual memory management
On 1/9/13 11:18 AM, Mehrdad wrote: On Wednesday, 9 January 2013 at 18:46:53 UTC, Walter Bright wrote: GC is a necessary requirement for memory safety, but not sufficient. Walter, would you mind explaining WHY it's "necessary"? I just spent so many comments explaining why NO form of automatic memory management is required for guaranteeing memory safety () and then you reply and say "GC is a necessary requirement" and leave it at that. See my comment here regarding handles, etc.: http://forum.dlang.org/thread/mailman.232.1357570887.22503.digitalmar...@puremagic.com?page=7#post-jimseaovuxmribkqbict:40forum.dlang.org This is true but uninteresting. Entire classes of languages can be made memory-safe without garbage collection, such as many Turing incomplete languages, languages without referential structures, languages that don't expose pointers (such as your example) and more. At the end of the day if references are part of the language and programs can build arbitrary reference topologies, safety entails GC. Andrei
Re: small idea
On Wed, Jan 09, 2013 at 01:57:14PM -0500, Nick Sabalausky wrote:
> On Wed, 09 Jan 2013 15:28:31 +0100
> "eles" wrote:
[...]
> > One thing that I really like about a function is to know quite
> > clearly which of its parameters are for input, which for output
> > and, yes, which one are for carrying (input/output parameters).
> >
> > In D, this is signalled by the in/out/inout keywords. However,
> > these are only visible at the moment of function declaration, not
> > calling.
[...]
> > Now, what about accepting a quick and optional (to not break
> > existing code) annotation at the time of the call:
> >
> > void make_a_equal_to_b(??a,!!b); //I give you "b", give me "a"
> >
> > so that in, out and inout could be replaced by !!, ?? and !?
[...]
Why replace them? Why not just reuse them:
void func(in int parmA, out int parmB) { ... }
void main() {
int x, y;
func(in x, out y); // self-documenting
func(out x, out y); // compile error
func(in x, in y); // compile error
}
T
--
Only boring people get bored. -- JM
Re: manual memory management
On Wednesday, 9 January 2013 at 18:46:53 UTC, Walter Bright wrote: On 1/9/2013 9:26 AM, Rob T wrote: For example, you can still access deallocated memory by mistake, If you're not playing with pointers, then this is a buggy GC. Yes you are correct. I was thinking of nullable references when I made that comment. When you dereference on a nulled reference, I suppose that's not really referencing deallocated memory. I'm not sure what exactly happens behind the scenes when you dereference a null pointer, but obviously bad things happen and it's not safe, also it is a memory related problem. run out of memory due to accumulating persistent pointers left around by mistake, Memory safety does not imply never running out of memory. I did qualify what I said by mentioning that it depends on the definition of memory safety. According to my definition of memory safety, a memory leak is still a memory leak no matter how it happens. I can however see an alternate definition which is likely what you are suggesting, where so long as you are not accessing memory that is not allocated, you are memory safe. There must be more to it than that, so if you can supply a more correct definition, that would be welcome. or free memory that was not supposed to be freed by mistake. Then it's a buggy GC. Yes. The point however is that a GC can be buggy, so by having one kicking around guarantees nothing unless you can prove that the implementation is 100% correct. I am reminded of the back up system that is less reliable than the medium it is supposed to be protecting, or the power backup supply that is less reliable than the main power grid. My guess is that no one knows how good or bad a GC is relative to what a manual system can do. The claims are likely the result of anecdotal evidence alone. Has anyone actually done a scientifically valid study that shows that a GC implementation is statistically more reliable than a manual implementation? Of course I understand that the lack of a scientific study proves nothing either way, I'm simply pointing out that we're likely making assumptions without any proof to back them up. The GC implementation may fail due to bugs, deallocating live memory or failing to deallocate inactive memory. Of course memory safety presumes a correctly implemented GC. Yes, of course, but this is a bit of a wild card since we probably have no proof that any given GC implementation will be correct. The only thing a GC can do for you, is free up the programmer from the tedium of managing memory. It also allows constructs that otherwise would be very difficult or impractical to implement. The effect can be very positive, but there are no guarantees of memory safety. This is incorrect - see above. A bug free GC, and not "cheating" in using it, guarantees memory safety. This is a big deal. Yes and no. Yes if the definition excludes the ability to "leak memory" due to programmer error, meaning allocating but failing to deallocate - a GC cannot prevent this, only a programmer can. I figure your definition excludes this kind of programmer error, and that's OK with me. I do however wonder about the ability to dereference null pointers, specifically pointers that are considered to be references. In D references are nullable, and I believe this is considered safe. -rt
Re: manual memory management
On Wednesday, 9 January 2013 at 12:25:08 UTC, Benjamin Thaut wrote: Walter claimed that compiler is shared-lib ready, it is just druntime that is lacking. And he hasn't got knowledge to make it work on his own. Sean Kelly is out - he was Walter's bet to make it work. My hope was Martin Nowak, he was working on it but seems that he also got busy with other stuff The compiler is not shared-lib ready. At least not on windows. It does not support exporting data symbols. E.g. export uint g_myGlobal; This is mostly a problem for "hidden" data symbols, like vtables, module info objects, type info objects and other stuff D relies on. Druntime on windows does already handle everything else pefectly (e.g. threads and TLS) Kind Regards Benjamin Thaut http://dlang.org/phobos/core_runtime.html I see library load and unload functions, although the required "dlsym" feature is absent. What's the status, does any of it actually work? --rt
Re: dlangspec.pdf?
On Wed, Jan 9, 2013 at 8:01 PM, Walter Bright wrote: >> What I'm not clear about, is: if the input is a D source file, should >> the expander strip any D code from it? Should this return a >> full-fledged documentation (ie, find the documented symbols...) or >> just blindly expand DDoc macros. >> > > No no no. The module gets its input from an InputRange. Not a file. It gets > its macro definitions, which are NAME=VALUE pairs, from an associative array > of them. That's not what I'm talking about, sorry for not being clear. I don't care for the origin of the data, obviously. I meant a D module, not a file specifically. My question was if the data is a D module (code + comments), should it just expand macros? Or should it generate a documentation? >From this and your other comments, I suppose the module does not filter out comments specifically: it simply iterate until it finds a $( pattern.
Re: manual memory management
On Wednesday, 9 January 2013 at 03:05:34 UTC, H. S. Teoh wrote: I haven't been screaming yet because (so far) I haven't gotten to writing applications that need dynamic loading in D. But I did tell myself that I will be screaming when I do get to it, because it's a pain to have to recompile the entire application just to add a single addon. Unfortunately for me, I'm getting to that point. If there's another better way, I'd sure like to know about it! [...] Another way, yes. Better, I don't know. You *could* load plugins as separate processes and communicate via some kind of IPC mechanism, like Unix pipes. But that's a royal pain (requires serialization / deserialization, with the associated overhead, and a network stack or equivalent, just to interface with each other). T The messaging concept does have some advantages. For example, if your external "plugin" fails for any reason (for example due to a segfault), the rest of your main application can continue operating just fine. There are other advantages, such as distributed processing, but if you can benefit from those advantages depends entirely on what you are attempting to achieve. The simplest use case that gives you a good subset of the main advantages, is through runtime loaded plugins. In my case, I will making use of both methods, but I really prefer having the plug-in capability to start with. --rt
Re: manual memory management
On Tuesday, 8 January 2013 at 23:04:48 UTC, Paulo Pinto wrote: Besides Web applications, I also took part in projects that ported high performance C++ daemons to Java. Curious as to why? What was to be gained/overcome? These were servers doing millions of data processing manipulations per second of telecommunication data used in mobile networks. Did it prove a worthwhile move? Did the move relieve any issues with C++? Was GC an issue in the end? Thanks, Dan
Re: manual memory management
On Wednesday, 9 January 2013 at 19:34:19 UTC, Andrei Alexandrescu wrote: At the end of the day if references are part of the language and programs can build arbitrary reference topologies, safety entails GC. It looks like a non sequitur to me... wouldn't this work? A language X has a built-in data type called Reference, and no classes. The only thing you can do with it are using these functions: Reference CreateObject(Reference typename); Reference DeleteValue(Reference object, Reference field); Reference GetValue(Reference object, Reference field); Reference SetValue(Reference object, Reference field, Reference value); Given _just_ these functions you can build _any_ arbitrary reference topology whatsoever. There's no need for a GC to be running, and it's completely manual memory management. It's memory-safe too. What am I missing here?
Re: manual memory management
On 1/9/2013 11:40 AM, Rob T wrote: Yes you are correct. I was thinking of nullable references when I made that comment. When you dereference on a nulled reference, I suppose that's not really referencing deallocated memory. I'm not sure what exactly happens behind the scenes when you dereference a null pointer, but obviously bad things happen and it's not safe, also it is a memory related problem. Null pointer faults are not a memory safety issue. Memory safety is not defined as "no bugs", it is defined as "no bugs that corrupt memory". I did qualify what I said by mentioning that it depends on the definition of memory safety. According to my definition of memory safety, a memory leak is still a memory leak no matter how it happens. If we each define our own meanings for words, we cannot understand each other. Memory safety is a standard piece of jargon, with a standard definition.
Re: dlangspec.pdf?
On 1/9/2013 12:03 PM, Philippe Sigaud wrote: That's not what I'm talking about, sorry for not being clear. I don't care for the origin of the data, obviously. I meant a D module, not a file specifically. My question was if the data is a D module (code + comments), should it just expand macros? Or should it generate a documentation? The current ddoc macro system does recognize D code. This should be removed from a generic macro system.
Re: dlangspec.pdf?
On 1/9/2013 11:31 AM, H. S. Teoh wrote: I think it would be nice to have a separate function for parsing macro definitions. No. Where the macro definitions come from is a completely separate problem, and the two should not be conflated.
Re: manual memory management
On Wednesday, 9 January 2013 at 09:35:28 UTC, deadalnix wrote: On Wednesday, 9 January 2013 at 08:46:20 UTC, Paulo Pinto wrote: You can write plugins without dynamic loading, they just are a bit more cumbersome to write. Like I used to do back in the late 90's, by making use of UNIX's IPC. The IPC to use (shared memory, pipes, mailbox, sockets) depends on what is required from the plugin. With shared memory being the closest to what dynamic loading achieves. Of course this raises another set of issues like: - Take care what happens when a plugin dies - Too many loaded plugins can stress the scheduler - You might have synchronization issues when using shared memory - It is a bit more painful to code for This is the school of thought of the Plan9/Go guys and most operating system micro-kernel architectures. Such a solution cause the same kind of issue for the runtime. For instance, how to handle the garbage collection of the shared memory ? What do happen if I get the typeid of an object of a type that only exists in the plugin in the core app ? It quite don't solve problems we have. Usually you serialize the data into the shared memory when using stronger type languages and only use public types defined in the common interface between the main application and plugins. -- Paulo
Re: manual memory management
On 1/9/13 12:09 PM, Mehrdad wrote: On Wednesday, 9 January 2013 at 19:34:19 UTC, Andrei Alexandrescu wrote: At the end of the day if references are part of the language and programs can build arbitrary reference topologies, safety entails GC. It looks like a non sequitur to me... wouldn't this work? A language X has a built-in data type called Reference, and no classes. The only thing you can do with it are using these functions: Reference CreateObject(Reference typename); Reference DeleteValue(Reference object, Reference field); Reference GetValue(Reference object, Reference field); Reference SetValue(Reference object, Reference field, Reference value); Given _just_ these functions you can build _any_ arbitrary reference topology whatsoever. There's no need for a GC to be running, and it's completely manual memory management. It's memory-safe too. What am I missing here? What you're missing is that you define a store that doesn't model object references with object addresses. That's what I meant by "references are part of the language". If store is modeled by actual memory (i.e. accessing an object handle takes you to the object), you must have GC for the language to be safe. If store is actually indirected and gives up on the notion of address, then sure you can implement safety checks. The thing is everybody wants for references to model actual object addresses; indirect handles as the core abstraction are uninteresting. Andrei
Re: dlangspec.pdf?
On 1/9/13 12:13 PM, Walter Bright wrote: On 1/9/2013 12:03 PM, Philippe Sigaud wrote: That's not what I'm talking about, sorry for not being clear. I don't care for the origin of the data, obviously. I meant a D module, not a file specifically. My question was if the data is a D module (code + comments), should it just expand macros? Or should it generate a documentation? The current ddoc macro system does recognize D code. This should be removed from a generic macro system. Yah, the "" etc. I was thinking it would be nice to have some of that functionality, too. Andrei
Re: Transitioning to the new Release Process
On Wednesday, 9 January 2013 at 17:12:15 UTC, Jesse Phillips wrote: The new process introduces a new branch called staging. This is _not_ used as one would first think. staging is created/updated _after_ release. This means a delay in changes in master (breaking changes/new additions) and release (a good thing). It also means that we have to do some awkward delaying to get some useful changes into staging so that it is different from this last release. According to the wiki, this is not what is supposed to happen, staging should have existed prior to the version branch release: --- version branches: Once we determine it's time to do a new release, a version branch is made by branching from the staging branch. A version branch will not receive any new features, only regression fixes. To determine to which version branch regression fixes should go, see #Regression fix. Version branches are used to support the version for an extended period of time to enable updated minor releases which fix regressions. --- I think what you mean, is that the 2.061 release was done improperly, and that we need to find a solution to fix whatever problems are being caused by the improper release. Correct? --rt
Re: manual memory management
On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright wrote: Interestingly, carefully written code using a GC can be *faster* than manual memory management, for a number of rather subtle reasons. One being calling the OS to allocate memory is an expensive operation (freeing as well?). I would think a smart GC once it identifies a free memory block may not free it to the OS but hold onto it, then give it to another process when asked for memory, thereby skipping the OS step.
Re: manual memory management
On Wednesday, 9 January 2013 at 20:00:28 UTC, Dan wrote: On Tuesday, 8 January 2013 at 23:04:48 UTC, Paulo Pinto wrote: Besides Web applications, I also took part in projects that ported high performance C++ daemons to Java. Curious as to why? What was to be gained/overcome? The architects decided it was cool to replace server code done in a mixture of C++/CORBA/SNMP/Perl by simple Java based servers. These were servers doing millions of data processing manipulations per second of telecommunication data used in mobile networks. Did it prove a worthwhile move? It was a lengthy process with quite some victims along the way, but it did improve the overall quality in the end. - Way shorter build times; - Better tooling infrastructure; - Thanks to the JVM, the application monitoring improved - Unit tests, code coverage and static analysis tools are much better - Better support of the operating systems in use without #ifdefs everywhere To be honest, it would have been better to refactor the C++ code to improve the overall quality, but there was another issue related with the language change, as you can read in the next answer. Did the move relieve any issues with C++? Yes, because in 300+ team projects not everyone is a C++ guru and you end up chasing language issues and pointer problems all the time. Not fun when you get a mobile operator complaining that their customers cannot do proper calls. So moving to Java allowed to improve overall code quality at the time, although I must say it also allowed them to easily outsource parts of the applications to replaceable developers a few years later. Was GC an issue in the end? In the beginning, yes. Most developers did not understand that in GC aware languages you need to change the way you code. So that was a learning process for many of them. But the JVM has lots of nice monitoring tools to help you track down the issues, which allowed us to refactor the places that were giving problems. Just some small parts were later also written in C, for deployment into network elements that were not capable to run a JVM with the desired hardware requirements. So depending on where in the globe you're located, your phone calls data might be processed by those applications. Thanks, Dan
Re: manual memory management
On Monday, 7 January 2013 at 15:01:27 UTC, Gor Gyolchanyan wrote:
Hello, folks!
I'm on to a project, which requires manual memory management
using custom allocators, but I can't seem to get dynamic arrays
and associative arrays to work.
The std.conv.emplace only allocates the pointer and the size of
the dynamic array and pointer to the associative array, which
is half the issue.
I can work around the dynamic array by manually allocating the
elements of the array and returning a slice to the result
(although I'd be really glad if I could directly use arrays
with my custom allocators).
I got to Page 3 but I really wanted to comment on some of this;
perhaps a step in the non-GC portion.
A thought coming to mind is to modify the existing D language to
include custom allocator/deallocator. The idea of sorta borrowing
from java will do the job. So 'new' can be a function which's
only purpose is to allocate memory, renew can be resizing
(appending?), and release is to handle deallocation.
struct S {
//similar to java's 'new' (C++ as well?) function.
//'this' referencing the struct's current storage/pointer
location.
new(this, int size = S.sizeof) {
assert(size >= S.sizeof);
this = cast(S) GC.malloc(size);
//ctor's called after new ends
}
//array (multidimentional?) allocation handling.
//new[] or newArray?. Probably no ctor afterwards
new(this, int size, int[] multiDimentional ...);
//handles deallocation (if applicable), with GC it's probably
empty
//coinsides with already used releasing of memory.
void release();
//handles resizing (in place?), probably arrays,
//could be realloc() and referring to the current object
already...?
//void realloc(int newSize);
renew(this, int newSize) {
S old = this.ptr;
this.ptr = GC.realloc(this.ptr, newSize);
if (old !is this.ptr)
{} //reallocated not appended
}
//potentially above new could be used for reallocation as
well... So
//rewritten instead as:
new(this, int size = S.sizeof) {
assert(size >= S.sizeof);
this = cast(S) GC.realloc(this, size);
//ctor's called after new ends
}
}
Just a thrown together gist. It's kinda how I remember with
zlib's setup where you could specify the allocator/deallocator,
and if you didn't it used the default. I know it's got problems
as it is, but that doesn't mean it can't be used for
brainstorming to handle alternate memory management.
