Re: Goldie Parsing System v0.4 Released - Now for D2
Am 15.04.2011 09:50, schrieb Nick Sabalausky: Since you're talking about C, you'll probably want to run your original C code through the preprocess-only option of a real C compiler. (I *think* DMC will do that.) Then parse the resulting preprocessed C files with Goldie. (Although if your goal is an HTOD-like tool, maybe you would need to deal with the original un-preprocessed source directly. Why? Just call the preprocessor from your tool or from a wrapping script and go on with the preprocessed C code. Should be much easier and more compatible because C compilers ought to know how to preprocess correctly. For GCC the option you're looking for is -E, btw. If Golde's grammar langauge doesn't seem quite up to the task, it probably wouldn't bee too hard to just manually make a basic C preprocessor.) Cheers, - Daniel
Re: Goldie Parsing System v0.4 Released - Now for D2
Daniel Gibson metalcae...@gmail.com wrote in message news:io8u12$132q$1...@digitalmars.com... Am 15.04.2011 09:50, schrieb Nick Sabalausky: Since you're talking about C, you'll probably want to run your original C code through the preprocess-only option of a real C compiler. (I *think* DMC will do that.) Then parse the resulting preprocessed C files with Goldie. (Although if your goal is an HTOD-like tool, maybe you would need to deal with the original un-preprocessed source directly. Why? Just call the preprocessor from your tool or from a wrapping script and go on with the preprocessed C code. Should be much easier and more compatible because C compilers ought to know how to preprocess correctly. For GCC the option you're looking for is -E, btw. If by your tool mean a program that uses Goldie to process C code, then yea, that's what I meant. If you meant that Goldie should invoke a C preprocessor directly, that's a bit tricky: Goldie is a generalized parsing tool (sort of like ANTLR or Spirit), so it doesn't really know Ok, this is supposed to be C. It just parses according to whatever grammar it's given. Of course, it's not entirely out of the question to have some sort of system for specifying that a source should have XYZ tool (such as C preprocessor) invoked on it first, etc, but it's probably easiest if programs using Goldie just invoke whatever other tools they need by themselves. (Sorry if I've stil misunderstood - it's late over here ;) )
Re: Goldie Parsing System v0.4 Released - Now for D2
Am 15.04.2011 10:13, schrieb Nick Sabalausky: Daniel Gibson metalcae...@gmail.com wrote in message news:io8u12$132q$1...@digitalmars.com... Am 15.04.2011 09:50, schrieb Nick Sabalausky: Since you're talking about C, you'll probably want to run your original C code through the preprocess-only option of a real C compiler. (I *think* DMC will do that.) Then parse the resulting preprocessed C files with Goldie. (Although if your goal is an HTOD-like tool, maybe you would need to deal with the original un-preprocessed source directly. Why? Just call the preprocessor from your tool or from a wrapping script and go on with the preprocessed C code. Should be much easier and more compatible because C compilers ought to know how to preprocess correctly. For GCC the option you're looking for is -E, btw. If by your tool mean a program that uses Goldie to process C code, then yea, that's what I meant. I meant Andrej's hypothetical tool using Goldie to process C code :-)
Re: Goldie Parsing System v0.4 Released - Now for D2
I've used your tool yesterday. I used it on a simple C file with the ANSI C grammar from the gold website. It does seem to work fine, but yeah I have to preprocess a C file first (I've spent so much time with D that I almost completely forgot about the C preprocessor in the first place). I've tried a file with your ParseAnything sample. It works ok as long as all the types are defined. If not I usually get a Token exception of some sort. Is this considered the semantic pass stage? Btw, is there a grammar file for C99? What about C++, I haven't seen a grammar on the Gold website? (well, C++ is a monster, I know..). I'm also trying to figure out whether to go with the static or dynamic approach (I've looked at your docs). The static examples seem quite complex, but perhaps they're more reliable. I think I'll do a few tryouts with dynamic style since it looks much easier to do. If I get anything done you'll know about it. :)
Re: Goldie Parsing System v0.4 Released - Now for D2
Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.3531.1302884207.4748.digitalmars-d-annou...@puremagic.com... I've used your tool yesterday. I used it on a simple C file with the ANSI C grammar from the gold website. It does seem to work fine, but yeah I have to preprocess a C file first (I've spent so much time with D that I almost completely forgot about the C preprocessor in the first place). I've tried a file with your ParseAnything sample. It works ok as long as all the types are defined. If not I usually get a Token exception of some sort. Is this considered the semantic pass stage? Like any generalized parsing tool (AFAIK), Goldie doesn't really have a semantic stage (because language semantics isn't something that's easily formalized). Probably the C grammar just considers something in your source to be either a syntax or grammatical error. (This could be a bug or limitation in the C grammar.) Goldie currently handles syntax/grammatical errors by throwing a ParseException when it detects all the errors it can find. The message of the exception is the filename(line:col): Error: Description of error message that you'd normally expect a compiler to output. Most of the apps in Goldie catch this exception and just output the message, but I guess I didn't do that in ParseAnything. Of course, it could also be a bug in either ParseAnything or Goldie. Can you send one of the C files that's getting an error? I'll take a look and see what's going on. You may want to try goldie-parse instead of goldie-parseAnything (I really should rename one of them, it's probably confusing). goldie-parseAnything is mainly intended as an example of how to use Goldie (like the Calculator examples). goldie-parse is the one that outputs JSON. Btw, is there a grammar file for C99? What about C++, I haven't seen a grammar on the Gold website? (well, C++ is a monster, I know..). Not that I'm aware of. But if you know the differences between ANSI C and C99 you should be able to modify the ANSI C grammar and turn it into a C99. The grammar description language should be very easy to understand if you're familiar with BNF and regex (In fact, the grammar definition langauge doesn't even use the barely-readable Perl regex syntax - it uses a far more readable equivalent instead). BTW, Tip on the grammar language: Everything enclosed in angle brackets is a nonterminal. And yea, C++ is a beast. And one of C++'s biggest issues is that, not only does it have the preprocessor, but what's worse: the parsing is dependent on the semantics pass. I'd say that any generalized parsing tool that can do C++ properly is doing an *incredibly* damn good job. I'm also trying to figure out whether to go with the static or dynamic approach (I've looked at your docs). The static examples seem quite complex, but perhaps they're more reliable. I think I'll do a few tryouts with dynamic style since it looks much easier to do. The general recommendation is to use static whenever you just have one specific grammar you're trying to deal with (because it provides better protection against mistakes). But you're right, the dynamic style may be an easier way to learn Goldie. If you haven't already, you may wat to look at the source for the calculator examples. They're both the exact same program, but one does it the static way, and the other does it the dynamic way. If I get anything done you'll know about it. :) Cool, appreciated :)
Re: Goldie Parsing System v0.4 Released - Now for D2
Andrej Mitrovic Wrote:
What I meant was that code like this will throw if MyType isn't
defined anywhere:
int main(int x)
{
MyType var;
}
goldie.exception.UnexpectedTokenException@src\goldie\exception.d(35):
test.c(3:12): Unexpected Id: 'var'
It looks like valid C /syntax/, except that MyType isn't defined. But
this will work:
struct MyType {
int field;
};
int main(int x)
{
struct MyType var;
}
So either Goldie or ParseAnything needs to have all types defined.
Maybe this is obvious, but I wouldn't know since I've never used a
parser before. :p
Oddly enough, this one will throw:
typedef struct {
int field;
} MyType;
int main(int x)
{
MyType var;
}
goldie.exception.UnexpectedTokenException@src\goldie\exception.d(35):
test.c(7:12): Unexpected Id: 'var'
This one will throw as well:
struct SomeStruct {
int field;
};
typedef struct SomeStruct MyType;
int main(int x)
{
MyType var;
}
goldie.exception.UnexpectedTokenException@src\goldie\exception.d(35):
test.c(13:12): Unexpected Id: 'myvar'
Isn't typedef a part of ANSI C?
I'm not at my computer right now, so I can't check, but it sounds like the
grammar follows the really old C-style of requiring structs to be declared with
struct StructName varName. Apperently it doesn't take into account the
possibility of typedefs being used to eliminate that. When I get home, I'll
check, I think it may be an easy change to the grammar.
Re: Distinction of null and empty [was Re: Ceylon language]
Nick Sabalausky Wrote:
I've thought about that and I don't know how I feel about it. On one hand, I
can certainly image cases where the distiction between null and empty would
be useful. But OTOH, after having to put up with the nightmare of VB6's One
million distinct ways to have a string that doesn't contain anything, I'm
hesitent at embracing extra ways to have ain't nuthin' here.
In our project we use
if(string.IsNullOrEmpty(str)){...}
almost everywhere
only in two places null matters.
T__T
Re: question to Walter - about the GUI library
== Forward by Jesse Phillips (jessekphillip...@gmail.com) == Posted at 2011/04/14 10:31 to digitalmars.D David Wang Wrote: Dear Walter Bright, I would like to know that what GUI library you would like to use for D Language ? Have you ever considered the GTK+ 3.0? or other library? or you will produce a new D library of GUI? wainting for your kindly feedback. Best regards. David. Walter has dropped the idea of endorsing a GUI/any library. There was once a statement that DWT was the official library for D, development promptly stopped afterwards. Not trying to claim there was causation here. Why stopped ? What's the causation ? Or the D community and Walter himself considering other library(s)? (If DWT be choosen as the official GUI library, I would like to start to learn it.) Best regards. David.
Re: Ceylon language
On 04/15/2011 03:23 AM, Nick Sabalausky wrote: I'm not certain either, but I *think* partial application is just like currying except there's some sort of arbitrary limitaion on what combination(s) of paramaters you can choose to specify or not specify. And that limitation is based purely on what order the function defines its parameters. So basically, my understanding is that partial application is an arbitrarily-gimped currying. In my understanding they are, while related, distinct like so: int foo(int x, int y, int z); int delegate(int, int) p = partiallyApply(foo, 3); int delegate(int) delegate(int) delegate(int) c = curry(foo); assert (p(4,5) == foo(3,4,5)); assert (c(3)(4)(5) == foo(3,4,5));
Re: question to Walter - about the GUI library
On 2011-04-15 15:13, David Wang wrote: == Forward by Jesse Phillips (jessekphillip...@gmail.com) == Posted at 2011/04/14 10:31 to digitalmars.D David Wang Wrote: Dear Walter Bright, I would like to know that what GUI library you would like to use for D Language ? Have you ever considered the GTK+ 3.0? or other library? or you will produce a new D library of GUI? wainting for your kindly feedback. Best regards. David. Walter has dropped the idea of endorsing a GUI/any library. There was once a statement that DWT was the official library for D, development promptly stopped afterwards. Not trying to claim there was causation here. Why stopped ? What's the causation ? DWT is in development again. Or the D community and Walter himself considering other library(s)? (If DWT be choosen as the official GUI library, I would like to start to learn it.) Best regards. David. -- /Jacob Carlborg
Re: Try it now
On 2011-04-14 18:48, Andrei Alexandrescu wrote: On 4/14/11 9:03 AM, Steven Schveighoffer wrote: Sometimes, I worry that my unit tests or asserts aren't running. Every once in a while, I have to change one to fail to make sure that code is compiling (this is especially true when I'm doing version statements or templates). It would be nice if there was a -assertprint mode which showed asserts actually running (only for the module compiled with that switch, of course). Could this be achieved within the language? Andrei Don't know exactly how he wants it to behave but I have have a look one of my earlier posts: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.Dartnum=134796 -- /Jacob Carlborg
Re: question to Walter - about the GUI library
On 2011-04-14 20:59, Walter Bright wrote: On 4/14/2011 7:31 AM, Jesse Phillips wrote: Walter has dropped the idea of endorsing a GUI/any library. There was once a statement that DWT was the official library for D, development promptly stopped afterwards. Not trying to claim there was causation here. I'm not making that mistake again! Just for the record, it's in development and now supports D2. -- /Jacob Carlborg
Re: [OT] Partial-reparsing thory?
Nick Sabalausky wrote: spir denis.s...@gmail.com wrote in message news:mailman.3527.1302824019.4748.digitalmar...@puremagic.com... On 04/15/2011 12:51 AM, Nick Sabalausky wrote: Is anyone aware of any (formal or informal) theory/information/research/articles/etc. that's already been done on the idea of reparsing *part* of an already-parsed source? Either lexing, parsing or both together. Preferably LR, but LL might be helpful, too. (I'd imagine it may be notably more difficult with LR. May need to keep track of all the parsing steps taken the first time around, and may need to continue re-parsing to the end of the source.) I'd imagine lex-only would be a lot easier. Sure it is. Visual D uses the Visual Studio approach for highlighting, keeping a 32-bit integer per line, indicating the state of the lexer. This state keeps track of token type, nesting level, etc. The state is calculated lazily, so you only have to scan the file until the last visible line. In addition, Visual D has a very simple parser to highlight version/debug conditionals, mostly just meant to figure out to what conditional an else belongs to (simpleparser.d). It keeps track of the text span that is covered by a parse tree node. If the text is modified, all parse tree nodes after the editing point are discarded, while the nodes including the edit point are restored to a state including the nodes before the span. The parser stack is reconstructed from the remaining parse tree and parsing can restart from a point very close to the actual editing point. As this parser only runs up to the last visible line, it has only a very small impact on performance and runs together with the lexer while the lines are drawn. The next version of Visual D will have a D2 parser (currently only used to highlight syntax errors), and I was hoping that a similar approach would be possible, but the state to keep is way more complicated. So it is running in a background thread for now, parsing the complete source.
Re: Ceylon language
I've recently made an attempt to make a curry alternative which can take any number of parameters (currently the curry implementation only works with 1 parameter). I've put my implementation in bugzilla, it is extremely simple (and maybe buggy :p) http://d.puremagic.com/issues/show_bug.cgi?id=5829. I've also tried to create a some sort of 'bind' function which could let you bind arguments to specific parameters of a function. If I had it working it would really help (me) out in coding for e.g. the Windows API. For example you might have a WinAPI function such as (I'm pseudocoding here): CreateWindow(int x, int y, int w, int h, int* opt1, int* opt2, int* opt3, char* name); And if you want to create a certain type of window with some parameters which are always the same, you could create an alias that binds certain arguments to this function: alias bind!CreateWindow(void, void, width, height, null, null, null, void) myWindow; Here 'void' would designate arguments that you would have to fill in when calling myWindow. You would call it like: myWindow(posX, posY, MyWindowName); which would translate the call to: CreateWindow(posX, posY, width, height, null, null, null, MyWindowName); WinAPI is full of functions which take optional parameters which need to be set to null if they're not to be used, so this kind of 'bind' function could be pretty useful. But I've had zero luck with CTFE and templates. Perhaps Don's upcoming CTFE revamp could make this possible.
Re: question to Walter - about the GUI library
On 4/15/2011 7:20 AM, Jacob Carlborg wrote: Just for the record, it's in development and now supports D2. That's most excellent!
Re: Ceylon language
Andrej Mitrovic:
alias bind!CreateWindow(void, void, width, height, null, null, null,
void) myWindow;
How do you give a void argument to a function, in D2? This doesn't work,
despite having templated void arguments seems potentially useful:
void foo(T)(T x) {}
void bar() {}
void main() {
foo(bar());
}
But I've had zero luck with CTFE and
templates. Perhaps Don's upcoming CTFE revamp could make this
possible.
Don has changed mostly how CT functions manage their memory.
Bye,
bearophile
Re: Ceylon language
Here's a hardcoded example: http://codepad.org/klr8S1hi I've tried numerous ways of automatically creating the appropriate call to fun in the bind template, but I've been unsuccessful. Maybe using some form of string mixin would work.. My biggest issue is that I can't modify variables at compile time. I wish there was some special CTFE int type which is only visible at compile-time and which we can use however we want. That way I could keep count of things, for example I could generate a list of indexes that can then be mixed in as a string.
Re: LLVM Coding Standards
On 04/15/2011 01:10 PM, Spacen Jasset wrote: As other posters have pointed out, it seems to me, at least, that having a way to express your model/idea or view of a problem directly is the most useful thing a language can give you. This is my definition of a good language :-) Denis -- _ vita es estrany spir.wikidot.com
Re: Ceylon language
Oh and the reason I used a struct and opCall inside the template is because this somehow allowed me to use foreach for some things. I dunno, CTFE overall seems like a buggy thing where I have to guess whether something will work or not. It's very stress-inducing.
Re: Ceylon language
On Apr 16, 11 00:29, Andrej Mitrovic wrote:
I've also tried to create a some sort of 'bind' function which could
let you bind arguments to specific parameters of a function. If I had
it working it would really help (me) out in coding for e.g. the
Windows API. For example you might have a WinAPI function such as (I'm
pseudocoding here):
CreateWindow(int x, int y, int w, int h, int* opt1, int* opt2, int*
opt3, char* name);
And if you want to create a certain type of window with some
parameters which are always the same, you could create an alias that
binds certain arguments to this function:
alias bind!CreateWindow(void, void, width, height, null, null, null,
void) myWindow;
Here 'void' would designate arguments that you would have to fill in
when calling myWindow.
You would call it like:
myWindow(posX, posY, MyWindowName);
which would translate the call to:
CreateWindow(posX, posY, width, height, null, null, null, MyWindowName);
I don't see the point reviving the std.bind module*. In your case a new
function name 'myWindow' needs to be defined, which makes it easier to
just create a wrapper function
auto myWindow(int x, int y, char* name) {
return CreateWindow(x, y, width, height, null, null, null, name);
}
*: http://www.digitalmars.com/d/2.0/phobos/std_bind.html
Re: Ceylon language
On 15.04.2011 22:24, KennyTM~ wrote:
On Apr 16, 11 00:29, Andrej Mitrovic wrote:
I've also tried to create a some sort of 'bind' function which could
let you bind arguments to specific parameters of a function. If I had
it working it would really help (me) out in coding for e.g. the
Windows API. For example you might have a WinAPI function such as (I'm
pseudocoding here):
CreateWindow(int x, int y, int w, int h, int* opt1, int* opt2, int*
opt3, char* name);
And if you want to create a certain type of window with some
parameters which are always the same, you could create an alias that
binds certain arguments to this function:
alias bind!CreateWindow(void, void, width, height, null, null, null,
void) myWindow;
Here 'void' would designate arguments that you would have to fill in
when calling myWindow.
You would call it like:
myWindow(posX, posY, MyWindowName);
which would translate the call to:
CreateWindow(posX, posY, width, height, null, null, null,
MyWindowName);
I don't see the point reviving the std.bind module*. In your case a
new function name 'myWindow' needs to be defined, which makes it
easier to just create a wrapper function
auto myWindow(int x, int y, char* name) {
return CreateWindow(x, y, width, height, null, null, null, name);
}
*: http://www.digitalmars.com/d/2.0/phobos/std_bind.html
I absolutely agree, also creating delegate in place solves pretty much
all of std.bind use cases.
--
Dmitry Olshansky
GC for pure functions -- implementation ideas
I noticed a lively discussion in Bugzilla about the GC, with speculation
about the impact of a precise GC on speed.
But it seems to me that a dedicated GC for pure functions has enormous
unexplored potential, and might be relatively easy to implement.
LEAKY FUNCTIONS
Define a 'leaky' pure function as a pure function which can return
heap-allocated memory to the caller, ie, where the return value or a
parameter passed by reference has at least one pointer or reference
type. This can be determined simply by inspecting the signature. (Note
that the function does not need to be immutably pure).
The interesting thing is that heap allocation inside non-leaky pure
functions behaves like stack allocation. When you return from that
function, *all* those variables are unreachable, and can be discarded en
masse. Here's an idea of how to exploit this.
THE PURE HEAP
Create a pure heap for each thread. This is a heap which can only be
used by pure functions. I present some simplistic code, with the
simplest possible implementation: just a big block of memory with a
thread local 'stack pointer' which points to the first free slot.
static ubyte *heap; // initialized to big chunk of RAM.
static size_t stackptr = 0;
static size_t savedstackptr = 0;
For *non-leaky* pure functions: if any of the functions it calls are
leaky, or if it makes any memory allocations, then call a HeapEnter
function (in the druntime) at the start, and a HeapExit function at the
end. Leaky pure functions don't get this prologue and epilogue code.
Non-leaky pure functions that don't do memory allocation are simply
ignored. (Note that the compiler can determine if a function makes any
memory allocations, simply by inspecting its body -- it isn't any more
difficult than checking if it is nothrow).
void pureHeapEnter()
{
cast(ubyte *)(heap + stackptr) = savedstackptr;
savedstackptr = stackptr;
stackptr += size_t.sizeof;
}
void pureHeapExit()
{
stackptr = savedstackptr; // instant GC!!
savedstackptr = cast(ubyte *)(heap +stackptr);
}
The pureHeapExit function has the effect of instantly (and precisely!)
collecting all of the memory allocated in the non-leaky pure function
and in every leaky function that it called.
In any pure function, leaky or non-leaky, when memory is allocated, call
pureMalloc instead of gcMalloc when allocating. (Non-leaky pure
functions will of course always allocate on the pure heap.).
void *pureMalloc(int nbytes)
{
if (!stackptr)
return gcMalloc(nbytes); // we're leaky, do a normal malloc
// we can use the pure heap
auto r = heap + stackptr;
stackptr += nbytes;
return r;
}
REFINEMENTS
We can make this scheme more generally applicable. If there is a leaky
return value which is cheap to copy, then we can pretend the function is
non-leaky: at exit, if we were called with stackptr == 0, then we copy
(deepdup) the return value to the gc heap, before calling pureHeapExit.
If stackptr was non-zero, we don't need to copy it.
COMPLICATIONS
Classes with finalizers are an annoying complication. But again, we can
look at all the functions we call, and all the 'new' operations we
perform, to see if any finalizers exist. Maybe we could even have a
separate finalizer heap?
Exceptions are the biggest nuisance, since they can also leak
heap-allocated memory. A catch handler in a non-pure function would need
to check to see if the pure heap 'stackpointer' is non-zero, and if so,
it would need to do a deep dup of the exception, then clear the pure
heap. Any pure function (leaky or not) which contains a catch handler
would need to record the value of the savedstackptr at entry to the
function, and the catch handler would need to unwind the pure heap until
we get back to it.
In reality, things are going to be a bit more complicated than this. But
it seems to me that conceptually, something like this could still stay
fairly simple and be very, very fast. With no changes required to the
language, and not even any changes required to existing code.
Re: GC for pure functions -- implementation ideas
On 4/15/2011 1:12 PM, Don wrote: In reality, things are going to be a bit more complicated than this. But it seems to me that conceptually, something like this could still stay fairly simple and be very, very fast. With no changes required to the language, and not even any changes required to existing code. I think it's a good idea.
Re: Try it now
== Quote from Jacob Carlborg (d...@me.com)'s article On 2011-04-14 18:48, Andrei Alexandrescu wrote: On 4/14/11 9:03 AM, Steven Schveighoffer wrote: Sometimes, I worry that my unit tests or asserts aren't running. Every once in a while, I have to change one to fail to make sure that code is compiling (this is especially true when I'm doing version statements or templates). It would be nice if there was a -assertprint mode which showed asserts actually running (only for the module compiled with that switch, of course). Could this be achieved within the language? Andrei Don't know exactly how he wants it to behave but I have have a look one of my earlier posts: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.Dartnum=134796 I'm somewhat shifting the topic, but it seems strange that unit tests are run when you run an executable. Wouldn't it make sense to run them immediately after compilation? I mean, what would be the use case where you would want to re-run a unit test on the code that's already compiled and tested? This could also solve the problem with messages on success, since you can output a success message after compilation. Sorry if I'm missing some obvious issue with this suggestion.
Re: GC for pure functions -- implementation ideas
On Apr 15, 2011, at 1:12 PM, Don wrote: Create a pure heap for each thread. This is a heap which can only be used by pure functions. I present some simplistic code, with the simplest possible implementation: just a big block of memory with a thread local 'stack pointer' which points to the first free slot. It's a good idea. dsimcha was already going to polish his TempAlloc, wasn't he? Seems like this is nearly the same thing.
Re: Backporting Tango runtime enhancements to druntime
We could also rewrite tango.core.Thread so that it extends core.thread. But keep the old interface/API. Some of the tango special feature might be wrapped in this case. In my mind it's more important that tango.core.Atomic gets deprecated, because it doesn't work well on my maschine. I have outcommented nearly half of it to get it run at a minimum. - mta`chrono
Re: GC for pure functions -- implementation ideas
Don: But it seems to me that a dedicated GC for pure functions has enormous unexplored potential, and might be relatively easy to implement. - In D we have not even started to exploit the full potential of purity and pure functions. - In D reducing the work of the normal GC is a very good thing (because of problems caused by not moving GC, its not precise nature, its not advanced implementation, and because D is a complex system language). - CommonLisp programmers and designers know that's it's good to give some hints to the the GC. Optional information that help the GC do its work more efficiently. The D1 scope attribute for class allocations was a not well designedimplemented example of this. (Note that the compiler can determine if a function makes any memory allocations, simply by inspecting its body -- it isn't any more difficult than checking if it is nothrow). Time ago I have suggested a @noheap that makes sure a function tree doesn't allocate memory. What you say makes me think that here user code may just desire to know what the compiler knows: a __traits that given a function name returns a true if the function performs heap allocation. With no changes required to the language, and not even any changes required to existing code. Phobos and other many small things (D too, like some form to express conditional purity, etc) need to change to allow D programmers to use purity more widely in their programs. This in turn will make your pure GC more and more useful. Bye, bearophile
Re: Temporarily disable all purity for debug prints
On 4/11/11 11:27 PM, bearophile wrote: From what I am seeing, in a D2 program if I have many (tens or more) pure functions that call to each other, and I want to add (or activate) a printf/writeln inside one (or few) of those functions to debug it, I may need to temporarily comment out the pure attribute of many functions (because printing can't be allowed in pure functions). Related news: https://github.com/D-Programming-Language/dmd/commit/ed8068f5036f88fff1603d98ebe96bb6659bceed David
Re: GC for pure functions -- implementation ideas
Sean Kelly wrote: On Apr 15, 2011, at 1:12 PM, Don wrote: Create a pure heap for each thread. This is a heap which can only be used by pure functions. I present some simplistic code, with the simplest possible implementation: just a big block of memory with a thread local 'stack pointer' which points to the first free slot. It's a good idea. dsimcha was already going to polish his TempAlloc, wasn't he? Seems like this is nearly the same thing. Yes. You could think of it as a way the compiler could automatically convert 'new' into a use of TempAlloc, in many useful cases.
Re: Temporarily disable all purity for debug prints
David Nadlinger: Related news: https://github.com/D-Programming-Language/dmd/commit/ed8068f5036f88fff1603d98ebe96bb6659bceed It's a bit disconcerting to see how important things I'm asking and arguing for for three years or more gets ignored, while this that I have barely noted gets worked on already :-) But I am not very good at reading DMD code, so is someone able to translate to me the effects of those changes, and how to use them? I presume this front end change is not following my suggestion (of adding a switch to disable purity), but adds a dirty hack that allows impure debug code inside pure functions. If this is true, then let's now find the bad side effects of this change. Bye, bearophile
Re: Temporarily disable all purity for debug prints
Related news: https://github.com/D-Programming-Language/dmd/commit/ed8068f5036f88fff1603d98ebe96bb6659bceed I have forgotten to add something: thank you Walter. Sorry for criticizing before actually trying out the change. Bye, bearophile
Re: GC for pure functions -- implementation ideas
Don napisał: LEAKY FUNCTIONS Define a 'leaky' pure function as a pure function which can return heap-allocated memory to the caller, ie, where the return value or a parameter passed by reference has at least one pointer or reference type. This can be determined simply by inspecting the signature. (Note that the function does not need to be immutably pure). The interesting thing is that heap allocation inside non-leaky pure functions behaves like stack allocation. When you return from that function, *all* those variables are unreachable, and can be discarded en masse. Here's an idea of how to exploit this. THE PURE HEAP [snip] I'm far from being a GC expert but I think Java having identified such cases with escape analysis just puts locally allocated objects on the stack. Couldn't we too? Your mark release pure heap scheme looks alright but this seems simpler. The notion of non-leaky functions can be useful either way. -- Tomek
Stroustrup on C++0x + JSF++ coding standard
Recent slides by Stroustrup on C++0x:
http://www.arcos.inf.uc3m.es/~jdaniel/sem-cpp-11/Madrid-bs.pdf
The Reddit thread:
http://www.reddit.com/r/programming/comments/gqwei/
The graph at page 20 (about list Vs vector) seems a bit too much good to be
true. There is no link to the benchmarking code. This benchmark by Stroustrup
is much worse than the ones I used to show here.
The primary value of a programming language is in the applications written in
it
The main value of certain languages, like Algol (or even Simula), was to lead
the way and help the development of widely used languages.
Make C++ easier to teach and learn Through increased uniformity, stronger
guarantees, and facilities supportive of novices (there will always be more
novices than experts)
C++0x adds useful things, but it's more complex than C++, there is more stuff
to learn.
C++0x [...] Every feature is implemented somewhere
Really?
Example: Strongly-typed enumerations
enum class Color { red, blue, green };
int x = Color::red; // error: no Color-int conversion
Color y = 7; // error: no int-Color conversion
Color z = red; // error: red not in scope
Color c = Color::red; // fine
Good. I'd like D2 to do something similar.
--
The Stroustrup slides also cite (page 38) the JSF++ (C++) coding standard,
that's interesting. I leave the discussion of those rules to another time, but
in the meantime I have found a higher level description of this coding standard:
http://www.ldra.com/nologindownload.asp?id=134
Language Selection: C++ or Ada95?
Ada95 has some problems, like less tools and compilers, but you don't want
safety-critical software written in a language that has hundreds of known traps.
This kind of programs are a small niche of the whole amount of programmers that
may want to use D2, but I think it's good to take a look at what those people
like or don't want from C++.
Ban features with behaviors that are not 100% predictable (from a performance
perspective)
Free store allocation (operators new and delete)
Exception handling (operator throw)
C++ provides safer alternatives to many dangerous C constructs
E.g. polymorphism rather than switch statements
Maybe there are ways to improve D2 final switches further (like covering all 8
cases if the final switch is done on a n%8, or with class instances).
C-Style casts == C++-style casts
JSF++ strongly encourages elimination of casts
AV Rule 48: Identifiers will not differ by:
- Only a mixture of case
- The presence/absence of the underscore character
- The interchange of the letter O, with the number 0 or the letter D
- The interchange of the letter I, with the number 1 or the letter l
- The interchange of the letter S with the number 5
- The interchange of the letter Z with the number 2
- The interchange of the letter n with the letter h.
Rationale: Readability.
This is interesting, and seems good.
prohibit dependence on evaluation order and side-effects.
manage memory layout issues (unions, bit-fields, casts, etc.)
address overflow issues
prohibit mixed-mode arithmetic and comparisons
Good.
Public and protected data should only be used in structs -- not classes.
AV Rule 101: Templates shall be reviewed as follows:
1. with respect to the template in isolation considering assumptions or
requirements placed on its arguments.
2. with respect to all functions instantiated by actual arguments.
Note: The compiler should be configured to generate the list of actual
template instantiations.
Rationale: Since many instantiations of a template can be generated, any
review should consider all actual instantiations as well as any assumptions
or requirements placed on arguments of instantiations.
In DMD there is no switch to see a list of actual template instantiations.
Where possible tools will be used to automate coding standard enforcement.
A first good tool to avoid similar bugs is the compiler itself.
Bye,
bearophile
Re: GC for pure functions -- implementation ideas
Tomek Sowiñski: I'm far from being a GC expert but I think Java having identified such cases with escape analysis just puts locally allocated objects on the stack. Escape analysis will be useful for D compilers too (I think LDC-LLVM is not doing this much yet), but if the amount of non-escaping memory allocated is large, you don't want to put it on the stack, a special heap is better. Bye, bearophile
Re: Temporarily disable all purity for debug prints
On 4/15/2011 3:00 PM, bearophile wrote: I presume this front end change is not following my suggestion (of adding a switch to disable purity), but adds a dirty hack that allows impure debug code inside pure functions. If this is true, then let's now find the bad side effects of this change. On the contrary, I think it is the right solution. After all, the reason people want to put impure code in a pure function is for debugging. By putting it under the debug conditional, any logging or printing code can be there without needing the compiler to be aware of what they do.
Re: GC for pure functions -- implementation ideas
On 4/15/2011 5:01 PM, Sean Kelly wrote:
On Apr 15, 2011, at 1:12 PM, Don wrote:
Create a pure heap for each thread. This is a heap which can only be
used by pure functions. I present some simplistic code, with the
simplest possible implementation: just a big block of memory with a thread
local 'stack pointer' which points to the first free slot.
It's a good idea. dsimcha was already going to polish his TempAlloc, wasn't
he? Seems like this is nearly the same thing.
Yeah, I never formalized it at all, but that's roughly what TempAlloc
accomplishes. My other concern is, what happens in the case of the
following code:
uint nonLeaky() pure {
foreach(i; 0..42) {
auto arr = new uint[666];
// do stuff
}
return 8675309;
}
In this case the arr instance from every loop iteration is retained
until nonLeaky() returns, whether it's referenced or not. Granted, this
is a silly example, but I imagine there are cases where stuff like this
happens in practice.
Re: Temporarily disable all purity for debug prints
Walter:
On the contrary, I think it is the right solution. After all, the reason
people
want to put impure code in a pure function is for debugging. By putting it
under
the debug conditional, any logging or printing code can be there without
needing
the compiler to be aware of what they do.
(Extra note: logging not fully related to debugging. Large programs often keep
logs even in release mode.)
There is something I don't understand. If your last change allows code like
this, isn't it breaking the safety of pure functions in debug mode? Do you
think this loss of safety is not important?
int some_global;
void loggit(int x) {
some_global++;
writeln(x);
}
pure nothrow int sqr(in int x) {
debug loggit(x);
return x * x;
}
Bye,
bearophile
Re: Temporarily disable all purity for debug prints
On 4/15/2011 7:06 PM, bearophile wrote: There is something I don't understand. If your last change allows code like this, isn't it breaking the safety of pure functions in debug mode? Do you think this loss of safety is not important? Yes, it allows one to break the purity of the function. The alternative is to use casts (which also breaks the purity) or another compiler switch (which also breaks the purity). Any escape from the language rules requires the programmer to know what they're doing, as the compiler can't check it for them. D is a systems programming language, and so it does allow escapes from the rules. It's very useful to allow an I-know-what-I'm-doing escape from the purity rules.
Floating Point + Threads?
I'm trying to debug an extremely strange bug whose symptoms appear in a std.parallelism example, though I'm not at all sure the root cause is in std.parallelism. The bug report is at https://github.com/dsimcha/std.parallelism/issues/1#issuecomment-1011717 . Basically, the example in question sums up all the elements of a lazy range (actually, std.algorithm.map) in parallel. It uses taskPool.reduce, which divides the summation into work units to be executed in parallel. When executed in parallel, the results of the summation are non-deterministic after about the 12th decimal place, even though all of the following properties are true: 1. The work is divided into work units in a deterministic fashion. 2. Within each work unit, the summation happens in a deterministic order. 3. The final summation of the results of all the work units is done in a deterministic order. 4. The smallest term in the summation is about 5e-10. This means the difference across runs is about two orders of magnitude smaller than the smallest term. It can't be a concurrency bug where some terms sometimes get skipped. 5. The results for the individual tasks, not just the final summation, differ in the low-order bits. Each task is executed in a single thread. 6. The rounding mode is apparently the same in all of the threads. 7. The bug appears even on machines with only one core, as long as the number of task pool threads is manually set to 0. Since it's a single core machine, it can't be a low level memory model issue. What could possibly cause such small, non-deterministic differences in floating point results, given everything above? I'm just looking for suggestions here, as I don't even know where to start hunting for a bug like this.
Re: Floating Point + Threads?
On 4/15/11 10:22 PM, dsimcha wrote: I'm trying to debug an extremely strange bug whose symptoms appear in a std.parallelism example, though I'm not at all sure the root cause is in std.parallelism. The bug report is at https://github.com/dsimcha/std.parallelism/issues/1#issuecomment-1011717 . Does the scheduling affect the summation order? Andrei
Re: GC for pure functions -- implementation ideas
Tomek Sowiński wrote: Don napisał: LEAKY FUNCTIONS Define a 'leaky' pure function as a pure function which can return heap-allocated memory to the caller, ie, where the return value or a parameter passed by reference has at least one pointer or reference type. This can be determined simply by inspecting the signature. (Note that the function does not need to be immutably pure). The interesting thing is that heap allocation inside non-leaky pure functions behaves like stack allocation. When you return from that function, *all* those variables are unreachable, and can be discarded en masse. Here's an idea of how to exploit this. THE PURE HEAP [snip] I'm far from being a GC expert but I think Java having identified such cases with escape analysis just puts locally allocated objects on the stack. That works for the non-leaky function itself, but it doesn't help for the functions it calls. Couldn't we too? Your mark release pure heap scheme looks alright but this seems simpler. The notion of non-leaky functions can be useful either way.
Re: GC for pure functions -- implementation ideas
dsimcha wrote:
On 4/15/2011 5:01 PM, Sean Kelly wrote:
On Apr 15, 2011, at 1:12 PM, Don wrote:
Create a pure heap for each thread. This is a heap which can only be
used by pure functions. I present some simplistic code, with the
simplest possible implementation: just a big block of memory with a
thread local 'stack pointer' which points to the first free slot.
It's a good idea. dsimcha was already going to polish his TempAlloc,
wasn't he? Seems like this is nearly the same thing.
Yeah, I never formalized it at all, but that's roughly what TempAlloc
accomplishes. My other concern is, what happens in the case of the
following code:
uint nonLeaky() pure {
foreach(i; 0..42) {
auto arr = new uint[666];
// do stuff
}
return 8675309;
}
In this case the arr instance from every loop iteration is retained
until nonLeaky() returns, whether it's referenced or not. Granted, this
is a silly example, but I imagine there are cases where stuff like this
happens in practice.
Yes. I'm not sure what the best strategy is if you run out of memory
inside purealloc.
The simple strategy would just be switch to the normal heap once the
pure heap is full. Then, the gc would have to check for a full pure
heap. If the pure heap is full, it should scan everything from the last
heapptr to the end of the pure heap, as well as everything else it
scans. But you still get the entire size of the pure heap as an
instant-gc region.
Re: GSoC 2011 update: we have 3 slots
On 4/15/11 9:05 AM, Ishan Thilina wrote: Are you still going to interview every applicant or only the applicants from the project that you think have high priority and success rate? Thank you...! Due to the few slots we received, we got we must be very conservative. We'll interview the applicants we believe have good chances at completing projects. There was a concern about students on a semester system that GSoC work would interfere with their coursework. Feel free to discuss this further on your application page. Thanks, Andrei
Re: Try it now
== Quote from Jacob Carlborg (d...@me.com)'s article On 2011-04-14 18:48, Andrei Alexandrescu wrote: On 4/14/11 9:03 AM, Steven Schveighoffer wrote: Sometimes, I worry that my unit tests or asserts aren't running. Every once in a while, I have to change one to fail to make sure that code is compiling (this is especially true when I'm doing version statements or templates). It would be nice if there was a -assertprint mode which showed asserts actually running (only for the module compiled with that switch, of course). Could this be achieved within the language? Andrei Don't know exactly how he wants it to behave but I have have a look one of my earlier posts: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup =digitalmars.Dartnum=134796 I'm somewhat shifting the topic, but it seems strange that unit tests are run when you run an executable. Wouldn't it make sense to run them immediately after compilation? I mean, what would be the use case where you would want to re-run a unit test on the code that's already compiled and tested? This could also solve the problem with messages on success, since you can output a success message after compilation. Sorry if I'm missing some obvious issue with this suggestion. You essentially need an executable to run the unit tests. It doesn't technically have to be an altered version of the normal executable, but you need an executable. It was probably just simplest to alter the normal executable so that it included the unit tests. Code coverage works the same way. Also, it could be desirable to build the unit tests without actually running them, at least some of the time, so separating the unit test build from actually running the unit tests can be beneficial. Regardless, the way it works works quite well overall. What is typically done, I believe is create a module with an empty main specifically for running the unit tests. So, building with -unittest isn't usually done with the normal executable, and you don't typically run your normal executable with the unit tests included in it. And as for the lack of messages on success, the whole idea is that there be no messages on success. You don't normally care about the unit tests unless they fail, so messages on success are just useless cruft in most cases, and it's _much_ easier to verify that the unit tests past programmatically if the output on success is nothing. Besides, if you really want to output success for each unit test, all you have to do is add writeln calls to the end of all your tests (annoying perhaps, but not hard). It would certainly be possible to add a flag to dmd that made it so that each test printed out on success for those who wanted it, but the value is questionable, and Walter and the other compiler devs have much more critical issues to work on. - Jonathan M Davis
Re: Using D libs in C
AFAIK 'int' in D is always a 32-bit value. But in C, 'int' could be 64bit on 64bit platforms. You could try printing sizeof(int) in C and compare that to int.sizeof in D and see if they match. You probably know this, but make sure your exported D function is annotated with extern(C).
TickDuration.ticksPerSec why would it be zero?
The documentation[1] states one should check if the value is zero to see if they can use it. For me this value is 0, Windows XP. So why would it be 0 and what do I use when it is? On a related note, anyone know of a UUID generator? I'm using a possible incorrect translation of the example in RFC 4122[2]. 1. http://digitalmars.com/d/2.0/phobos/core_time.html#TickDuration 2. http://www.ietf.org/rfc/rfc4122.txt
Re: Using D libs in C
They both return 4, and both short and int16_t return 2. Also, I've noticed that if I use a struct (of four ints) instead, the same thing happens, the parameters are not correct. And yes, of course they are extern already.
Re: TickDuration.ticksPerSec why would it be zero?
The documentation[1] states one should check if the value is zero to see if they can use it. For me this value is 0, Windows XP. So why would it be 0 and what do I use when it is? It means that QueryPerformanceFrequency failed: http://msdn.microsoft.com/en-us/library/ms644905(VS.85).aspx Looking at the doc page for it, it looks like it means that your hardware doesn't support a high-resolution performance counter. I should probably improve TickDuration's docs on that. On a related note, anyone know of a UUID generator? I'm using a possible incorrect translation of the example in RFC 4122[2]. 1. http://digitalmars.com/d/2.0/phobos/core_time.html#TickDuration 2. http://www.ietf.org/rfc/rfc4122.txt If all you need to do is generate one, and you're on Linux, then uuidgen would do it, and I guess that you'd use libuuid if you wanted to do it programatically. But I have noe idea what you'd do on Windows. - Jonathan M Davis
question about AutoImplement_Helper (and a couple of others)
I'm a bit new with the D programming language, so I figured this
would be the right place to ask a few questions that have been
piling up.
So let's start. First, I recently found the AutoImplement class
while I was trying to build a Proxy object. It seemed like an
interesting thing to try, though it may not be a good way to manage
asynchronously created resources (which is what I was planning to
use it for).
At any rate, since AutoImplement is a class already, and I have this
thing about not deriving from concrete classes, I decided use
AutoImplement_Helper instead. I needed a proxied object, after all,
so I needed to be able to manipulate the class definition. It was
only after doing so that I noticed it was marked private, and thus
presumably not intended for public consumption (and I have no idea
why it even compiles).
private shared class Proxy(InterfaceType) if (is (InterfaceType ==
interface)) : public InterfaceType
{
private alias AutoImplement_Helper!(autoImplement_helper_,
InterfaceType, InterfaceType, GeneratePassthroughMethod,
isAbstractFunction) autoImplement_helper_;
public mixin(autoImplement_helper_.code);
public shared static this()
{
s_proxy = new BlackHole!(InterfaceType);
}
public this()
{
m_instance = s_proxy;
}
public void setProxiedInstance(shared(InterfaceType)
instance)
{
m_instance = instance;
}
private static shared(InterfaceType) s_proxy;
private InterfaceType m_instance;
}
private template GeneratePassthroughMethod(InterfaceType, method...)
{
public const(string) GeneratePassthroughMethod =
__traits(getMember, this.m_instance, __traits(identifier, self))
(args);;
}
Is there another way (that I just haven't seen) to do what I'm
trying to do? I could just bite the bullet and derive my proxy from
AutoImplement, but I thought I'd ask first.
Next, you may have noticed that it's a shared class. I wanted to
make sure that the assignment I'm doing in the setProxiedInstance()
method will be atomic, and that reading the variable will also be
atomic.
My third question is about attributes. As far as I can tell, D has
no user defined attributes, correct? I was making myself a unit
test framework (with simple reporting, encapsulation of unit tests
as methods, and assertion tools). I was hoping to perform automatic
registration of the individual unit tests, but the best I could
manage was compile-time detection of methods starting with test,
and this feels like a hack. I would prefer to mark the methods
explicitly in some way. Does anyone know of a way to do this?
Thanks for your time.
Re: question about AutoImplement_Helper (and a couple of others)
Read Bixby: (and I have no idea why it even compiles). If it's in the same module then it compiles because everything in a module is public to each other. If it's in another module then it's a compiler bug. My third question is about attributes. As far as I can tell, D has no user defined attributes, correct? Right. But I think they will be added someday. We have discussed this many times, despite I think there is no concrete proposal yet. I was making myself a unit test framework (with simple reporting, encapsulation of unit tests as methods, and assertion tools). I was hoping to perform automatic registration of the individual unit tests, but the best I could manage was compile-time detection of methods starting with test, and this feels like a hack. I would prefer to mark the methods explicitly in some way. Does anyone know of a way to do this? A unit test module will be soon added to Phobos. Currently the unittest hooks and D introspection capabilities aren't so strong. More people need to ask for this basic capabilities in the main D newsgroup to eventually let the D devs know that here there is a need. Bye, bearophile
Re: A use case for fromStringz
Hmm.. now I need a function that converts a wchar* to a wchar[] or
wstring. There doesn't seem to be anything in Phobos for this type of
conversion. Or maybe I haven't looked hard enough?
I don't know whether this is safe since I'm not sure how the null
terminator is represented in utf16, but it does seem to work ok from a
few test cases:
wstring fromWStringz(wchar* value)
{
if (value is null)
return ;
auto oldPos = value;
uint nullPos;
while (*value++ != '\0')
{
nullPos++;
}
if (nullPos == 0)
return ;
return to!wstring(oldPos[0..nullPos]);
}
I thought we would pay more attention to interfacing with C code.
Since D is supposed to work side-by-side with C, we should have more
functions that convert common data types between the two languages.
Re: A use case for fromStringz
Microsoft has some of the most ridiculous functions. This one
(GetEnvironmentStrings) returns a pointer to a block of
null-terminated strings, with no information on the count of strings
returned. Each string ends with a null-terminator, standard stuff. But
only when you find two null terminators in succession you'll know that
you've reached the end of the entire block of strings.
So from some example code I've seen, people usually create a count
variable and increment it for every null terminator in the block until
they find a double null terminator. And then they have to loop all
over again when constructing a list of strings.
Talk about inefficient designs.. There's also a wchar* edition of this
function, I don't want to even touch it. Here's what the example code
looks like:
char *l_EnvStr;
l_EnvStr = GetEnvironmentStrings();
LPTSTR l_str = l_EnvStr;
int count = 0;
while (true)
{
if (*l_str == 0)
break;
while (*l_str != 0)
l_str++;
l_str++;
count++;
}
for (int i = 0; i count; i++)
{
printf(%s\n, l_EnvStr);
while(*l_EnvStr != '\0')
l_EnvStr++;
l_EnvStr++;
}
FreeEnvironmentStrings(l_EnvStr);
I wonder.. in all these years.. have they ever thought about using a
convention in C where the length is embedded as a 32/64bit value at
the pointed location of a pointer, followed by the array contents?
I mean something like the following (I'm pseudocoding here, this is
not valid C code, and it's 7 AM.):
// allocate memory for the length field + character count
char* mystring = malloc(sizeof(size_t) + sizeof(char)*length);
*(cast(size_t*)mystring) = length; // embed the length
// call a function expecting a char*
printString(mystring);
// void printString(char* string)
{
size_t length = *(cast(size_t*)string);
(cast(size_t*)string)++; // skip count to reach first char
// now print all chars one by one
for (size_t i; i length; i++)
{
printChar(*string++);
}
}
Well, they can always use an extra parameter in a function that has
the length, but it seems many people are too lazy to even do that. I
guess C programmers just *love* their nulls. :p
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 Jacob Carlborg d...@me.com changed: What|Removed |Added CC||d...@me.com --- Comment #126 from Jacob Carlborg d...@me.com 2011-04-15 00:27:53 PDT --- Why not just add an additional garbage collector with this new implementation and leave the old one as it is and then developers can choose which one to use at link time. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 Sean Cavanaugh worksonmymach...@gmail.com changed: What|Removed |Added CC||worksonmymach...@gmail.com --- Comment #127 from Sean Cavanaugh worksonmymach...@gmail.com 2011-04-15 01:40:35 PDT --- (In reply to comment #120) (In reply to comment #118) True, and it works tolerably well. To do a moving gc, however, you need more precise information. I don't want a moving GC. I want a fast GC. (I in this context means D users with the same requirements, mainly video game developers.) I understand the advantages of a moving GC - heap compaction allowing for an overall smaller managed heap etc., but I hope you understand that sacrificing speed for these goals is not an unilateral improvement for everyone. I am a game developer, and this thread is fairly fascinating to me, as memory management and good support for Intel SSE2(and AVX) or PowerPC VMX are two of the biggest issues to me when considering alternative languages or the question of 'will this language be suitable in the future'. The SSE problem seems workable with extern C'd C++ DLLs code to handle the heavy math, which leaves the GC as a big 'what does this mean' when evaluating the landscape. The reality is a lot of game engines allocate a surprising amount of memory at run time. The speed of malloc itself is rarely an issue as most searches take reasonably similar amount of time. The real problems with heavy use of malloc are thread lock contention in the allocator, and fragmentation. Fragmentation causes two problems: large allocation failures when memory is low (say 1 MB allocation when 30 MB is 'free'), and virtual pages are unable to be reclaimed due to a stray allocation or two within the page. Lock contention is solved by making separate heaps. Fragmentation is fought also fought by separating the heaps, but organizing the allocations coherently either time-wise or by allocation type where like sized objects pooled into a special pool for objects of that size. As a bonus fixed size object pools have const time for allocation, except when the pool has to grow, but we try real hard to pre-size these to the worst case values. On my last project we had about 8 dlmalloc based heaps and 15 fixed sized allocator pools, to solve these problems. I would greatly prefer a GC to compact the heap to keep the peak memory down, because in embeded (console) environments memory is a constant but time is fungible. VM might be available on the environments, but it isn't going to be backed by disk. Instead the idea of the VM is that it is a tool to fight fragmentation of the underlying physical pages, and to help you get contiguous space to work with. There is also pressure to use larger (64k, 1MB, 4MB pages) pages to keep the TLB lookups fast, which hurts even more with fragmentation. Tiny allocations holding onto these big pages prevents them from being reclaimed, which makes getting those allocations moved somewhere better pretty important. Now the good news is a huge amount of resources in a game do not need to be allocated into a garbage collected space. For the most part anything you send to the GPU data is far better off being written into its memory system and left alone. Physics data and Audio data have similar behaviors for the most part and can be allocated through malloc or aligned forms of malloc (for SSE friendlies). So from a game's developers point of I need to know when the GC will run either by configuration or by manually driving it. Both allow me to run a frame with most of the AI and physics disabled to give more of the time to the collector. A panic execution GC pass that I wasn't expecting is acceptable, provided I get notified of it, as I would expect this to be an indicator memory is getting tight to the point an Out of Memory is imminent. A panic GC is a QA problem as we can tell them where and how often the are occurring and they can in turn tell the designers making the art/levels that they need to start trimming the memory usage a bit. Ideally the GC would be able to run in less time than a single frame (say 10-15ms for a 30fps game). Taking away some amount of time every frame is also acceptable. For example spending 1ms of every frame to do 1ms worth of data movement or analysis for compacting would be a reasonable thing to allow, even if it was in addition to the multi-millisecond spikes at some time interval (30 frames, 30 seconds whatever). Making the whole thing friendly to having lots of CPU cores wouldn't hurt either. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5465] AA.keys with char keys
http://d.puremagic.com/issues/show_bug.cgi?id=5465 Pedro Rodrigues pdfrodrig...@gmail.com changed: What|Removed |Added CC||pdfrodrig...@gmail.com --- Comment #2 from Pedro Rodrigues pdfrodrig...@gmail.com 2011-04-15 06:31:27 PDT --- I've tested with version 2.052 and obtained the following output: th xpliaems So it's probably fixed now. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5438] Thread.sleep doesn't sleep
http://d.puremagic.com/issues/show_bug.cgi?id=5438 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED CC||schvei...@yahoo.com Resolution||WORKSFORME --- Comment #2 from Steven Schveighoffer schvei...@yahoo.com 2011-04-15 07:43:16 PDT --- This bug needs more details, as to exactly what is expected to happen. Not having any details, I can't tell what exactly you expect should happen. I'm closing this, if you feel it was closed in error, please reopen with more details. Specifically, you should outline what the behavior currently is, and what behavior you expect. Also, any evidence showing the erroneous behavior would be appreciated. As a tip, Thread.sleep now accepts a core.time.Duration struct, which can be initialized with units other than hnsecs. e.g. Thread.sleep(dur!seconds(5)); // sleep for 5 seconds -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5465] AA.keys with char keys
http://d.puremagic.com/issues/show_bug.cgi?id=5465 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2841] char[] incorrectly accepted as a template value argument in D2
http://d.puremagic.com/issues/show_bug.cgi?id=2841 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Don clugd...@yahoo.com.au 2011-04-15 21:22:04 PDT --- The example in comment 2 is fixed in this commit. https://github.com/donc/dmd/commit/fc67046cf1e66182d959309fb15ef9e2d4c266b9 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1386] string expected when using allMembers-element in __traits(getMember, ...)
http://d.puremagic.com/issues/show_bug.cgi?id=1386 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #9 from Don clugd...@yahoo.com.au 2011-04-15 21:33:24 PDT --- The error message is: test2.d(22): Error: no property '__T4TempTkZ' for type 'test2.Asdf' Some kind of junk tuple members are being included in allMembers. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5678] new enum struct re-allocated at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=5678 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||FIXED --- Comment #1 from Don clugd...@yahoo.com.au 2011-04-15 22:34:17 PDT --- Fixed https://github.com/D-Programming-Language/dmd/commit/47d46bf1364c63df5bb01406db4098c771d701dd -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
